Bug#295422: e2fsprogs for Sarge
On Fri, Apr 08, 2005 at 02:36:58PM +0900, Horms wrote: Hi Ted, It seems that I missunderstood the preferences expressed by Steve Langasek in my discussions with him. As it turns out he feels that it would be best to get 0.37-2 ready, as 0.37-1 is currently in sarge and has been beaten upon by users quite a bit. This should mittigate most of the need for review. And hopefully make your life a bit easier too. OK, I've just uploaded e2fsprogs 1.37-2. It is more than just the IA-64 core dump fix, but they are all extremely low-risk bugfixes: * Fix filefrag so that it works non ext2/3 filesystems again. (Closes: #303509) * Make sure we include stdlib.h to fix a core dump bug in mke2fs on the IA64 architecture (or other platforms where sizeof(ptr) sizeof(int)) (Closes: #302200) * Add missing return values so that we don't return garbage in certain error cases in ext2fs_write_new_inode() and ext2fs_read_int_block(). * Fix minor spelling typo in the mke2fs man page * Avoid doing the LOW_DTIME checks if the superblock last mount time indicates that the system clock may not be set correctly. * Add further paranoia checks to the blkid, ext2fs, and ss libraries to make them safe to call from setuid or setgid applications. The diff file is quite small and easy to sanity check. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295422: e2fsprogs for Sarge
On Fri, Apr 08, 2005 at 02:36:58PM +0900, Horms wrote: Hi Ted, It seems that I missunderstood the preferences expressed by Steve Langasek in my discussions with him. As it turns out he feels that it would be best to get 0.37-2 ready, as 0.37-1 is currently in sarge and has been beaten upon s/sarge/sid/ by users quite a bit. This should mittigate most of the need for review. And hopefully make your life a bit easier too. But yes, the number of fixes that seem to be worth considering for sarge makes t-p-u an unpleasant prospect, because t-p-u gets no user testing before it hits testing, whereas the version already in unstable has been beaten on (in various forms) for some time. If there could be a 1.37-2 that includes just the ia64 fix, it could be pushed into testing fairly quickly (i.e., with just the usual 10-day wait). -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
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
Bug#295422: e2fsprogs for Sarge
Hi Ted, It seems that I missunderstood the preferences expressed by Steve Langasek in my discussions with him. As it turns out he feels that it would be best to get 0.37-2 ready, as 0.37-1 is currently in sarge and has been beaten upon by users quite a bit. This should mittigate most of the need for review. And hopefully make your life a bit easier too. So, my question for the day is, what do you think needs to be done to release a sarge-worthy 0.37-2? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295422: e2fsprogs for Sarge
Hi Ted, I hope that all is well. I am writing to you about an old problem with the e2fsprogs that has unfortunately resurfaced in testing and I am looking for some advice on the best way forward. In a nutshell the problem is bug 295422. You fixed this in e2fsprogs 0.35-7, a versioned dependancy was added to kernel-image-amd64 2.6.8-12 and the bug was closed. So far, so good. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=295422 Unfortunately the version of kernel-image-amd64 in testing is 2.6.8-11, so the versioned dependancy is not there. We also have e2fsprogs 0.35-6 in testing, which means that bug 295422 manifests in testing. 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). 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. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=302200 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. You probably have other ideas, which is why we are here. Best wishes -- Horms Appendix For reference, so everything is in one place, Testing has kernel-image-2.6.8-amd64 2.6.8-11 which is built against kernel-tree-2.6.8-13 which is also in testing. Unstable has kernel-image-2.6.8-amd64 2.6.8-12 which is built against kernel-tree-2.6.8-14 which is not available in testing. And before you ask, ues this packaging is going to be unified, but much to some people's chagirn, probably not until after sarge (we are frozen, right?). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
