Bug#295422: e2fsprogs for Sarge
On Thu, Apr 07, 2005 at 12:33:53PM +0900, Horms wrote:
> Normally this would just be a matter of waiting for the new versions
> to filter down to testing, but as part of the attempts to get sarge
> released, testing was fozen a little while ago, so changes aren't
> propogating, while unstable marches on (bit of a process problem is
> an understatement, but lets save that discussion for another day).
Indeed, the real problem, but what can we do? Nothing, for the sarge
release...
> The real problem for Debian is that we need a to update e2fsprogs in
> testing, but we are unsure of the best version to use. I notice that the
> version in testing is quite a lot newer, e2fsprogs 1.37-1. This presents
> two issues, firstly I've been advised by Steve Langasek that small
> incremental changes are quite desirable at this point. And secondly,
> there is a pending issue with e2fsprogs 1.37-1 wherby mke2fs fails on
> ia64, bug 302200.
Correct, although that patch is really minor (it's a one line patch to
add #include <stdlib.h>), and I will be uploading it shortly. I've
just been completely swamped the past few weeks trying to get
everything done before I head off to Annaheim for Usenix Annual Tech
in 3 days and then from there, to Linux.conf.au....
> In short, we are looking for your advice on which version of e2fsprogs
> to include in sarge. My understanding is that appart from this issue,
> 0.35-6 seems to be quite fine. Here are some ideas that I have. I am
> not sure of the versining gymnastics that need to occur to make this
> happen, perhaps none, Steve Langasek can advise.
>
> * Inculde 0.35-7 verbatim in sarge
> * Include 0.35-8 verbatim in sarge
> * Include 0.35-6 + just the fix for 302200 in sarge
> * Include 1.37-2 (as yet unreleased) in sarge
> this would require some considerable review and is thus
> likely the slowest option.
There are a whole bunch of changes besides this one that probably
ought to be merged into 0.35-6, and I was assuming that the Release
Team wouldn't permit anything other than backporting fixes into
0.35-6, because of the "small fixes" requirements. The problem is
that there more than a few rather critical bug fixes and/or
improvements that have taken place since 0.35-6. Some of the ones
which I'd most like to get into e2fsprogs 0.35-6 include:
* Fix a double-free problem in resize2fs. (Red Hat Bugzilla #132707)
* Make sure e2fsck doesn't crash if /proc/acpi/ac_adapter does not
exist
* Add -s option to e2image which scrambles directory entries when making
raw image files
* Add support for online resizing via the resize inode, including allowing
e2fsck to work correctly on filesystems created on Fedora Core 3
or RHEL 4 systems.
* Make sure that we don't write garbage when writing a large inode.
The first two are bugs that result in core dumps in resize2fs and
e2fsck, respectively, with the second guaranting a crash and
preventing a system from booting if /proc is not mounted. The 3rd is
makes it a lot easier from a suppor standpoint since it allows me to
get compressed, metadata-only e2image dumps from users when debugging
a problem, since in some cases the directory names might reveal what
kind of p0rn they might be collecitng, which might make them
uncomfortable. And the 4th is important for interoperability with
newer Linux distributions. (But the changes to support this are quite
a bit larger than the other patches).
Other potential patches to consider including are:
* Fixed a bug in e2fsck so it would notice if a file with an extended
attribute block was exactly 2**32 blocks, such that i_blocks wrapped
to zero.
* Force compile_et and mk_cmds to use /usr/bin/awk so that we will work
on any Debian system regardless of which version of awk is installed.
(Closes: #299341) (Otherwise you can't build packages that depend
on compile_et, such as Kerberos and Zephyr on platforms that use
a different version of awk than the one used to build the
e2fsprogs .debs, because of autoconf issues)
I just haven't had the time to backport the patches into 0.35-6 yet,
and then more importantly, test and build an dpkg on a testing system
and then upload it to T-P-U.
So what needs to be done?
1. Extract the necessasry changes out of my Bitkeeper repository
2. Run the proposed changes by the release team to make sure
they are OK with them.
3. Integrate them with e2fsprogs 0.35-6.1 (probably using a
set of quilt-managed patches that are applied via dpatch)
4. Build on a testing system to avoid accidental dependencies
on sid.
Anyone interested in helping me, since it's clear I don't have time to
do this until after I get back from Linux.conf.au and a vacation in
New Zealand? (i.e., in early May).
I can do step #1, and if someone is willing to do the rest of the
steps, that would be great. I'd ask whoever did this to send me the
quilt-managed patches and the series file after step 3 so I can do a
quick QA pass on my end, but other than that I would be ecstatic if I
could delegate the rest to someone with a bit more time.
Alternatively, getting 1.37-2 into sarge would fix a bunch of other
minor bugs and a make number of new features available to our users.
(See the Release Notes or debian/changelog for more details.) The
downside is the increased risk of breakage, which I do understand,
especially since e2fsprogs is in base, which was frozen aeons ago. So
while from a developer's point of view that would be a very good
thing, from release team's point of view I have always assumed that
idea was a complete and total non-starter.
- Ted
Reply to: