On Sat, Mar 03, 2007 at 09:06:23PM -0800, Steve Langasek wrote:
> It's acceptable to me; the final d-i images haven't been spun yet for etch,
> and anyway a one-line change for a shlibs fix isn't exactly a big delta so I
> don't see a reason to respin even if we did have version skew. (I.e., the
> source requirements are still satisfied for d-i as much as they are for any
> random other package that might happen to be built against a previous
> version of libblkid1, no?)
Yes, very true.
Which I guess brings me to another question, and I'll *completely*
understand if the release team says NO. If I'm going to do an uplod,
and if the d-i images are going to be respun anyway, would you mind if
I also slipstream in the following very low-risk patch:
http://thunk.org/hg/e2fsprogs/?cs=1619c81226d1
It's a four-line addition to debugfs to prevent a core-dump if
"dump_unused" is run while a filesystem is not open:
sor:~ # debugfs
debugfs 1.39 (29-May-2006)
debugfs: dump_unused
Segmentation fault
Basically the fix involves adding an error check to detect this case
so it's a very low-risk change. It represents the only other bug
which has been fixed in my source tree since the version of e2fsprogs
currently in testing. But this would cause the source requirements
for d-i to require the d-i images to be respun, and the bug that it
fixes is relatively low-priority, so if the answer is please don't,
I'll completely understand and only upload the one-line change to
debian/control:
http://thunk.org/hg/e2fsprogs/?cs=69a666bd25f5
After all, the function of release managers is to counteract
developers' natural desire to fix "one last bug" or add "one last
feature" when it might end up delaying the release, no? :-)
Regards,
- Ted
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
