Adding d-release as this looks like this issue may impact release planning. On Thursday 04 September 2008, Theodore Tso wrote: > On Thu, Sep 04, 2008 at 12:55:23AM +0200, Frans Pop wrote: > > > The Depends on e2fsprogs-udeb are "e2fslibs (>= 1.41.0), libblkid1 > > > (>= 1.37), libc6 (>= 2.7-1), libcomerr2 (>= 1.37), libuuid1 (>= > > > 1.37)" > > > > The e2fsprogs-udeb used to depend on just libblkid1-udeb and libc6, > > all the other dependencies are completely new. Looks like the > > dependencies have randomly changed because of a serious packaging > > error with the most recent upload(s) of the latest upstream of > > e2fsprogs. > > This was caused by the introduction of the use dpkg-gensymbols in > 1.41.1-2, I suspect. I'll fix the control file to manually specify > the dependencies for the udeb packages. That is a very ugly solution to be honest and likely to cause random breakages in the future if the executables for some reason do depend on additional libraries. Letting debhelper/dpkg take care of it is very much to be preferred, especially as it worked correctly in the old version. > Stupid question, though --- I thought D-I would be doing builds > against testing, not unstable? As much as I would like to get the > quite large number of bug fixes that are in the 1.41.1 maintenance > release into Lenny, I thought the Lenny Freeze ship had sailed long > ago (to horribly Vita-Mix a metaphor). Lenny currently has e2fsprogs > 1.41.0-3, which would not have this problem. > > I'm a bit surprised that Debian Installer would be doing daily builds > against what is currently in unstable. There are very good reasons why D-I is still taking udebs from unstable (it does of course _install_ lenny). I'm currently not in the mood for an elaborate explanation of those reasons though. Note also that with your upload you have violated one of the basic "freeze" rules anyway: to only upload changes to unstable that are targeted for Lenny, _especially_ for "core" (library) packages. Anything else should either be kept back or uploaded to experimental. Main reason behind that rule is that you have now made it effectively impossible to upload urgent bug fixes for Lenny, based on the current Lenny version, through unstable. Another reason is to avoid exactly the kind of issues in this BR. > P.S. Here are some of the bug fixes which are in 1.41.1 that are not > in 1.41.0 that might be especially relevant: > > * Fix "dumpe2fs -i" and "debugfs -i". (Closes: #495830) > * Fix blkid cache validation and some possible blkid crashes > (Closes: #493216) > * Fix filefrag's ideal extent calculation (Closes: #458306) > * Fix resize2fs incorrectly managing directory in-use counts when > shrinking filesystems and directory inodes need to be moved. Not sure what the point of mentioning these is as with your last uploads you've effectively blocked any chance of doing an upload targeted at Lenny with only these fixes. > But in any case, I had not planned to try to ask for a Freeze > exception, precisely because I didn't want to cause problems for some > of its downstream dependencies, such as the d-i. My thought was to > wait until a future update of Lenny, and backport just the most > critical non-ext4 related bugs at that time --- especially if Lenny is > releasing in September. Some observations: - Lenny is not releasing in September - any such changes would have to satisfy the rules for "stable updates", which by the sound of it they may not... One option to consider at this point would be to re-upload the lenny version to unstable with an added epoch, but I will leave that decision to you and possibly the release team. Cheers, FJP
Attachment:
signature.asc
Description: This is a digitally signed message part.