This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 0.144


> 05.01.2010 04:47, Roland McGrath wrote:
> > The others I think are positively fixed.  I put a bug in ASSIGNED state (vs
> > NEW) when I think it's covered by something already in elfutils.git.
> > (Perhaps I should use MODIFIED, but that is meant for when there is an rpm
> > built I think.)
> 
> Isn't MODIFIED for in CVS, not yet built?

For in Fedora /cvs/pkgs, right.  I'm not sure if it's meant to imply there
is an rpm build or not.  A bug doesn't leave MODIFIED state until the rpm
is actually pushed out in an update (when you can have bodhi auto-close the
bug).  For us, there is never really a pkgs commit without an immediate rpm
build.  And there is usually never a pkgs commit until an upstream release
is made--i.e., "a pending fix" usually means we've fixed it upstream but
not yet made the new release/pkgs-commit/rpm-build/update-push.

> I did, the fix works.  I wonder whether to cut a testcase from that, the 
> debugedit sources have ~2K lines.

Thanks for testing that.  If you can cons up a simple contrived test case
that reproduces the essential issue of libelf usage pattern that tickled
the bug, then add that.  Don't do anything that copies any big chunks of
code from debugedit.c, nor anything that requires some random binary as its
test data (all our test files are either .o's from elfutils itself or are
from trivial source that is public domain--otherwise we raise GPL issues
with distributing those binaries even just as test data files).  If it
takes too much time to cons up a test for the suite, just don't bother.


Thanks,
Roland

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]