Bug#582275: ext3 filesystem corruption on md RAID1 device
On Jun 18, 2010, at 3:12 AM, Buehl, Reiner wrote: Hi Jan, I tried for a while with alternate hardware and the original controller but the error did never happen again. I think your idea of a bug in e2fsck's handling of multiply claimed blocks is the only explanation: Maybe during a corruption long ago a number of multiply claimed blocks existed and where reduced with each reboot. Is this possible? How can this be fixed? It could be an e2fsck bug, or it could be a hardware issue. In my experience, every time I've tried digging into problems with e2fsck -fy not fixing all problems in a single pass, it's been a hardware problem. That being said, multiply claimed blocks is something that isn't exercised that much, so it's *possible* that it is an e2fsck bug. I really would need a reproducible test case before I could do anything though. -- Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582275: ext3 filesystem corruption on md RAID1 device
On Jun 18, 2010, at 7:09 AM, Theodore Tso wrote: It could be an e2fsck bug, or it could be a hardware issue. In my experience, every time I've tried digging into problems with e2fsck -fy not fixing all problems in a single pass, it's been a hardware problem. That being said, multiply claimed blocks is something that isn't exercised that much, so it's *possible* that it is an e2fsck bug. I really would need a reproducible test case before I could do anything though. And reviewing the thread, the fact that you are reliably getting directory corruption every single time you're booting, and the reliability of the hardware has been called into question (forgive me for being a little suspicious of people trying to do reliable storage using IDE devices). -- Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583910: e2fsprogs: bogus dependency on libblkid1 due to shlibs.local
On Jun 3, 2010, at 8:53 PM, beat.n...@stagecoach-wireless.com wrote: there appears to be a package version mis-match. squeeze/ testing: e2fs(libs, progs) are version 2.17.xx and mount and util-linux are version 2.16.2-0. If you grab the e2fs(libs, progs) packages version 2.16.2-0 from stable/ lenny then it may work. Fix is already uploaded to unstable -- Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552934: e2fsprogs: FTBFS: install: cannot stat `/build/user-e2fsprogs_1.41.9-1-amd64-pJJNFw/e2fsprogs-1.41.9/debian /BUILD-STD/doc/libext2fs/*.html': No such file or directory
On Wed, Oct 28, 2009 at 11:50:54AM +0100, Lucas Nussbaum wrote: Source: e2fsprogs Version: 1.41.9-1 Severity: serious User: debian...@lists.debian.org Usertags: qa-ftbfs-20091028 qa-ftbfs Justification: FTBFS on amd64 During a rebuild of all packages in sid, your package failed to build on amd64. Argh, this was caused by a gratuitous change[1] in the behavior of texi2html. [1] http://www.mail-archive.com/debian-de...@lists.debian.org/msg277902.html I'll put in a workaround to support both the old and new behavior of texi2html, since it looks like uptream likes the change things randomly. :-( - Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551795: e2fsprogs: /sbin/fsck lost on partial upgrades
On Sun, Oct 25, 2009 at 07:37:43AM +0100, Sven Joachim wrote:
On 2009-10-24 21:06 +0200, Theodore Tso wrote:
diff --git a/debian/control.in b/debian/control.in
index 5d5142c..842d5d0 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -228,7 +228,11 @@ Description: ext2/ext3/ext4 file system libraries -
headers and static libraries
Package: e2fsprogs
Essential: yes
-Pre-Depends: ${shlibs:Depends}, ${misc:Depends}
+ifdef(`UTIL_LINUX_NG',
+``Pre-Depends: ${shlibs:Depends}, ${misc:Depends}, util-linux (
2.15~rc1-1)
^^
That seems to be a typo, surely you mean = instead of ?
Yeah, very stupid typo. Thanks for catching it!
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551795: e2fsprogs: /sbin/fsck lost on partial upgrades
tags 551795 +pending
thanks
On Tue, Oct 20, 2009 at 08:32:32PM +0200, Sven Joachim wrote:
Package: e2fsprogs
Version: 1.41.9-1
Severity: serious
Recently, the /sbin/fsck binary has moved from e2fsprogs to util-linux.
While this is certainly correct in itself, e2fsprogs needs to
(pre-)depend on a version of util-linux that contains the fsck program,
otherwise it might get lost on partial upgrades breaking the system.
Looking at the util-linux changelog, 2.15~rc1-1 appears to be the first
version to ship /sbin/fsck.
Thanks for pointing this out. I've checked the following into my
source tree.
commit 06807d9fa62fe31525143b36fcff8f223e18829c
Author: Theodore Ts'o ty...@mit.edu
Date: Sat Oct 24 15:04:54 2009 -0400
debian: Add pre-depends for util-linux for util-linux-ng builds
Addresses-Debian-Bug: #551795
Signed-off-by: Theodore Ts'o ty...@mit.edu
diff --git a/debian/control.in b/debian/control.in
index 5d5142c..842d5d0 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -228,7 +228,11 @@ Description: ext2/ext3/ext4 file system libraries -
headers and static libraries
Package: e2fsprogs
Essential: yes
-Pre-Depends: ${shlibs:Depends}, ${misc:Depends}
+ifdef(`UTIL_LINUX_NG',
+``Pre-Depends: ${shlibs:Depends}, ${misc:Depends}, util-linux ( 2.15~rc1-1)
+'',
+``Pre-Depends: ${shlibs:Depends}, ${misc:Depends}
+'')dnl
Suggests: gpart, parted, e2fsck-static
Conflicts: dump ( 0.4b4-4), quota ( 1.55-8.1), initscripts ( 2.85-4),
sysvinit ( 2.85-4)
Replaces: hurd (= 20040301-1), libblkid1 ( 1.38+1.39-WIP-2005.12.10-2),
libuuid1 ( 1.38+1.39-WIP-2005.12.10-2)
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539100: libblkid1: Broken/loose dependencies
On Wed, Jul 29, 2009 at 06:30:36AM +0200, Michael Biebl wrote: Package: libblkid1 Version: 2.16-2 Severity: serious Justification: wrong dependencies Hi, libblkdi1 has a generated dependency on libuuid1 1.40.3-1. When I compile hal 0.5.13 against libblkid-dev in a minimal chroot, this installs libblkid-dev 2.16-2 uuid-dev 1.2-1.41.8-2 libblkid1 1.41.8-2 The build fails: libtool: link: cc -g -O2 -g -Wall -O2 -Wchar-subscripts -Wmissing-declarations -Wnested-externs -Wpointer-arith -Wcast-align -Wsign-compare -Wl,--as-needed -o .libs/hald-probe-storage probe-storage.o linux_dvd_rw_utils.o util_helper.o logger.o /usr/lib/libblkid.so ../../../libhal/.libs/libhal.so ../../../partutil/.libs/libpartutil.a -ldbus-glib-1 -ldbus-1 -lpthread -lrt /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so -lsmbios /usr/lib/libblkid.so: undefined reference to `uuid_unpa...@uuid_1.0' collect2: ld returned 1 exit status make[6]: *** [hald-probe-storage] Error 1 make[6]: Leaving directory `/tmp/buildd/hal-0.5.13/hald/linux/probing' libblkid1 version 2.16-2 is in experimental, and is generated from sources in util-linux-ng (aka util-linux version 2.16), and no longer from e2fsprogs. I don't think (in fact I'm pretty sure) the BTS isn't smart enough to send this report to the util-linux maintainers instead of the e2fsprogs maintainer (me). Scott, LaMont, could you subscribe to this bug, and handle it, please? As Michael pointed out in a subsequent e-mail to this bug, it's a failure in the shlibs file. The libblkid 1.x packages do not provide any symbols with the @UUID_1.0 symbol version, and so the shlibs file needs to be adjusted to point this out. Thanks, regards, - Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539100: libblkid1: Broken/loose dependencies
On Wed, Jul 29, 2009 at 09:11:30PM +0200, Michael Biebl wrote: Theodore Tso wrote: Scott, LaMont, could you subscribe to this bug, and handle it, please? As Michael pointed out in a subsequent e-mail to this bug, it's a failure in the shlibs file. The libblkid 1.x packages do not provide any symbols with the @UUID_1.0 symbol version, and so the shlibs file needs to be adjusted to point this out. Why is the shlibs.local file needed at all? If the symbols files are updated properly, that should be sufficient to generate correct dependencies. Agreed. At least for e2fsprogs, the shlibs.local file predated my adding the symbols file, and I never got around to deleting the shlibs.local file. I already talked to Scott and LaMont briefly about this. Imho the symbols files should not be updated/generated automatically, but manually, so you can actually track ABI breakages much more easily. Also, the debian revision should be stripped away (unless a symbol was added by a Debian revision specific patch), to make e.g. backports easier. Yes, I agree. I'll make the change in e2fsprogs for libraries that are still shipping as part of e2fsprogs, but it's up to Scott and LaMont to make changes to the util-linux package in experimental. Thank you for noticing this problem before it was moved to unstable and/or testing!! - Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538052: tzc: uninstallable in unstable
On Wed, Jul 22, 2009 at 01:55:58PM -0400, Sam Hartman wrote: package: tzc severity: grave version: 2.6.15-5 Hi. tzc depends on libzephyr3 which is no longer present in unstable. This is blocking the zephyr transition, which is blocking the removal of libkrb53 from testing. I plan to schedule an NMU for 4 days from now using the delayed queue. I'll attach an NMU diff here; you can either upload before my NMU hits incoming, cancel my NMU, or do nothing and the NMU should go through. Thanks were you going to send a diff later, or were you planning on attach a diff and just forgotten to hit the include button? - Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#502541: e2fsprogs: blkid returns true even if device is non-existent
On Fri, Oct 17, 2008 at 06:39:55PM +0400, Kondrat Pushkarev wrote: Package: e2fsprogs Version: 1.41.2-1 Severity: critical Justification: breaks unrelated software blkid returns true even if specified device does not exist (it should return 2). This appears to be a new bug in lenny, as the behavior was normal in etch. What software does it break? - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502541: e2fsprogs: blkid returns true even if device is non-existent
severity 502541 normal thanks On Fri, Oct 17, 2008 at 10:14:41PM +0400, Peter Bray wrote: Hi Ted, Well, it broke one of my custom boot scripts which relied on the return value to determine if a usb device was up or not. That script broke when I upgraded to lenny, leaving my system temporarily unbootable. Whether it breaks anything in the Debian distribution I don't know, but it seems to me the program ought to behave as documented. Sure, that makes it a bug, and I'll fix it. But breaks unrelated software is not an adequate justification make the bug be severity critical, and certainly not some random boot script. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498942: /sbin/fsck.ext3: Tries to open filesystem with O_EXCL multiple times
priority 498942 important
thanks
Justification for lowering the priority: e2fsck works for most people;
this failure only happens for badly corrupted filesystems --- and
there is a workaround. You need to specfy the blocksize. i.e.,
e2fsck -b 8193 -B 1024 /dev/
or
e2fsck -b 32768 -B 4096 /dev/
A fix for this problem was checked into the e2fsprogs git repository
last week. The problem was found by some Ubuntu users a few months
ago, but unfortunately no one saw fit to either (a) report it to via
Ubuntu's Launchpad, (b) report it to me via any of the other bug
trackers (Source Forge, Debian BTS, etc.), or (c) e-mail me about it
and ask me, until last week.
This will be in the next version of the e2fsprogs maint branch. It
would be nice to get this fix into Lenny, but I'm hesitant to suggest
anything that might further delay Lenny.
- Ted
commit 52771ab59145d66b50399a8b953b8181cb2d5b04
Author: Theodore Ts'o [EMAIL PROTECTED]
Date: Tue Sep 9 15:02:24 2008 -0400
e2fsck: Fix e2fsck automatic blocksize detetion
This fixes a regression that was introduced in commit dcc91e10 (it
showed up first in e2fsprogs 1.40.7). Since we weren't freeing the
filesystem handle, ext2fs_open2() was returning EBUSY, and so this
caused a failure in the code that would automatically determine the
filesystem block size when only the superblock number was specified by
the user.
This was discussed in http://ubuntuforums.org/showthread.php?t=789323,
and Matthias Bannach pointed this out to me, for which I am very
grateful.
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
diff --git a/e2fsck/unix.c b/e2fsck/unix.c
index 94938a4..64faebe 100644
--- a/e2fsck/unix.c
+++ b/e2fsck/unix.c
@@ -971,6 +971,8 @@ restart:
int blocksize;
for (blocksize = EXT2_MIN_BLOCK_SIZE;
blocksize = EXT2_MAX_BLOCK_SIZE; blocksize *= 2) {
+ if (fs)
+ ext2fs_free(fs);
retval = ext2fs_open2(ctx-filesystem_name,
ctx-io_options, flags,
ctx-superblock, blocksize,
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497619: netinst: fail to create ext3 file systems
On Thu, Sep 04, 2008 at 04:33:20PM +0200, Frans Pop wrote: Looking at the diff between the Lenny and Sid versions, I wonder at the dropped build dependencies on libdevmapper/libselinux1. From the release notes: The blkid library is now much more efficiently handling devicemapper devices, mainly by no longer using the devicemapper library. This can speed up access for systems with a large number of device mapper devices. I also now notice the build dependency on dietlibc, which is a complete unknown for D-I. I wonder if the real reason for the broken dependencies may be there. D-I uses libc... No, dietlibc is only used when building e2fsck.static, to further shrink the size of the generated binary. The udeb's don't use e2fsck.static at all; it's only used for the e2fsck-static package. Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497619: netinst: fail to create ext3 file systems
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. Reassigning to that package. Ted: please fix with highest urgency as this completely breaks all daily builds of the Debian Installer which are essential for pre-release testing. TIA. I will, although I'm travelling at the moment so I probably won't be able to upload new packages until tomorrow night or Friday morning. I'll get to it as soon as I can. 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. - Ted 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. (and a whole bunch of ext4-related fixes, which are important to people trying out ext4, but not that relevant to most Debian stable users.) 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. That's why I was a bit surprised that the d-i was depending on the e2fsprogs in unstable. If I had known about that, maybe I would have uploaded the 1.41.1 releases into experimental. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496956: e2fsprogs: e2fsck does not complete check and reboots system
severity 496956 normal thanks Sounds like your kernel is crashing when a certain part of the disk is being accessed. If a userspace program can cause a system crash, by definition that's a kernel bug, not a userspace bug. The fact that the system is crashing on you any way if you abort e2fsck with ctrl-c, drop into maintenance mode, and then type ctrl-d to continue rebooting without checking the filesystem shows this isn't an e2fsprogs problem. If it's not crashing when you boot a Knoppix CD, yes, it could be because you're using a much older version of e2fsprogs --- but remember, the Knoppix CD is also using a significantly older kernel, too. I don't know if this is caused by some kind of hardware fault which the kernel isn't handling properly, or this is a kernel bug which was introduced when you upgraded to a newer kernel, but that is what I would suspect. 1) What kernel version are you running? 2) What kind of disk drive are you using for your filesystem? What kind of disk controller are you using? Is it SCSI, IDE, SATA, etc.? 3) What happens if you run this command from maintenance mode: dd if=/dev/hda5 of=/dev/null bs=32k In case 3), e2fsck start showing triplets of data (using -C 1 option) starting from 1 1 734 and it always reboots shortly after the triplet 1 64 734 as showed below: The fact that it always reboots around the time when e2fsck is checking block group #64 (out of the 734 block groups on that filesystem) strongly suggests some kind of hardware fault. The hardware is returning some kind of error, which the kernel can't handle and it is causing it to panic and reboot. That's why I suggested the dd command above; it would demontrate the problem without any use of e2fsprogs. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493216: labeled mounts break with recent udev
On Fri, Aug 01, 2008 at 02:13:31PM +0200, Marco d'Itri wrote: On Aug 01, Guido Günther [EMAIL PROTECTED] wrote: Reason is that findfs and friends query /etc/blkid.tab to find the device matching the UUID. Since blkid.tab has things like /dev/.static/dev/hda7 (no idea why blkid picked that one in favour of /dev/hda7) this breaks the mount. I am sorry to hear that blkid has been broken for a long time. Can you someone explain to me what the heck the /dev/.static/dev/hda7 hack is all about? I don't get those crazy names in my /etc/blkid.tab file... - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493216: labeled mounts break with recent udev
severity 493216 important thanks On Fri, Aug 01, 2008 at 08:24:38AM -0400, Theodore Tso wrote: On Fri, Aug 01, 2008 at 02:13:31PM +0200, Marco d'Itri wrote: On Aug 01, Guido Günther [EMAIL PROTECTED] wrote: Reason is that findfs and friends query /etc/blkid.tab to find the device matching the UUID. Since blkid.tab has things like /dev/.static/dev/hda7 (no idea why blkid picked that one in favour of /dev/hda7) this breaks the mount. I am sorry to hear that blkid has been broken for a long time. Can you someone explain to me what the heck the /dev/.static/dev/hda7 hack is all about? OK, now I know what /dev/.static is, but I still don't get those names in my /etc/blkid.tab file, and I'm not sure how they got into yours. It certainly isn't the name which is used by default, so I'm not sure how they would have gotten into the blkid file at all in the first place. All I can think of is that at some point someone accidentally typed the command blkid /dev/.static/dev/sda7 while running as root, and this errant got stuck in your /etc/blkid.tab file. I see (and will fix) the bug which causes blkid to not fix this problem automatically, but this is something which I've never seen show up in peoples /etc/blkid.tab files in the normal course of events. If you run the command the command blkid -g as root the errant /dev/.static entry will go away. cp /dev/null /etc/blkid.tab will also make the problem go away, and I haven't been able to find a way to make blkid put those names into /etc/blkid.tab unless forced via explicit human intervention. Am I right in assuming that udev 0.125 is not something that you guys are planning on trying to slide into Lenny? - Ted P.S. The huge bug with libvolumeid is that it relies on /dev/disk/by-*, which only gets updated at boot-time. So freshly created filesystems, swap spaces, etc., won't be foud by libvolumeid until after you reboot. That is so hugely windows-eque that I'm amazed users of libvolumeid put up with it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487675: e2fsprogs_1.41~WIP-2008-06-17-1(mips/experimental): FTBFS: No rule to make target `ss_err.h', needed by `extent.o'
tags 487675 +pending thanks On Mon, Jun 23, 2008 at 04:36:07PM +0200, Frank Lichtenheld wrote: Package: e2fsprogs Version: 1.41~WIP-2008-06-17-1 Severity: serious your package failed to build from source. The following fix has been checked into e2fsprogs's git repository. (This was a MIPS specific build problem, BTW). Thanks for reporting it! - Ted From 92e94afe4cc52deeef120941e6ac4d8ca4cda55e Mon Sep 17 00:00:00 2001 From: Theodore Ts'o [EMAIL PROTECTED] Date: Mon, 23 Jun 2008 14:10:43 -0400 Subject: [PATCH] libext2fs: Don't include ss/ss.h except when debugging extent.c should only try to include ss/ssh.h when it is compiled with -DDEBUG. Otherwise it's not necessary and it breaks the Debian MIPS build (and the Debian MIPS build only) because it tries to build libext2fs without building libss as part of a MIPS-specific build rule. Addresses-Debian-Bug: #487675 Signed-off-by: Theodore Ts'o [EMAIL PROTECTED] --- lib/ext2fs/extent.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/lib/ext2fs/extent.c b/lib/ext2fs/extent.c index 78c605f..d24d457 100644 --- a/lib/ext2fs/extent.c +++ b/lib/ext2fs/extent.c @@ -27,7 +27,6 @@ #include ext2_fs.h #include ext2fsP.h #include e2image.h -#include ss/ss.h /* * Definitions to be dropped in lib/ext2fs/ext2fs.h @@ -1355,6 +1354,8 @@ errcode_t ext2fs_extent_get_info(ext2_extent_handle_t handle, #ifdef DEBUG +#include ss/ss.h + #include debugfs.h /* -- 1.5.6.rc3.1.g36b7.dirty -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487758: /sbin/blkid: blkid shows not anymore connected devices, even after reboot
severity 487758 normal thanks On Tue, Jun 24, 2008 at 12:10:35AM +0200, Holger Fischer wrote: Package: e2fsprogs Version: 1.40.11-1 Severity: critical File: /sbin/blkid Justification: causes serious data loss Normally my root device is /dev/sda6. When I connect an ext. sata before next boot my root device becomes /dev/sdb6 and the ext. sata is sda, because the external is connected to sata port 1 on the mainboard and the system disk is connected to sata port 4 on the mainboard. But not today: sda is obvious the external disk and sdb the internal, but mount tells me that sda6 is my root device. gparted tells me that there is no sda6, because my external disk doesn't contain a 6th partition Mount sometimes lies; if /etc/mtab has the wrong information, it's going report the wrong information. blkid tells me that there is a sda6 and a sdb6 with the same uuid (there should only be sdb6) What could it be related to? Where is that salad from? blkid deliberately doesn't delete cached information for non-existent devices. Since /dev/sda6 doesn't exist, it didn't remove it from the blkid cache. If /dev/sda6 existed as a device, it would tried to validate it, and removed the cache entry if the validation failed. In the case where a device is missing, this is not a problem. In the case where device names are bouncing around, it can mean that that the when you lookup a device by LABEL or UUID, you will get multiple names, and when using the lookup, you can get the wrong (i.e., stale) device name. This will cause a mount to fail, but it won't necessarily lead to serious data loss, unless the script is seriously fragile (i.e., not checking error returns, etc.,). By your usage, it *could* possibly lead to serious data loss if a script depends on the program in some bad/wierd way, any bug could be classified as critical. Blkid isn't itself causing serious data loss, so it's not critical. It is a bug in that we should return a validated device in preference to the non-validated device, and I'll work to fix it quickly. But I don't consider this a RC bug. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481248: libuuid1 greps /etc/passwd instead of calling getent
On Wed, May 14, 2008 at 09:33:36PM +0200, Matthias Klose wrote: Package: libuuid1 Version: 1.40.8-2 Severity: serious from the postinst: if ! grep -q libuuid /etc/passwd; then directly grepping /etc/passwd looks suspicious. OK, but why is this a serious bug? Grepping /etc/passwd isn't a violation of policy Using getent instead of grepping /etc/passwd would suppress adding a local group if libuuid were defined in Yellow Pages, I suppose. But having an extra entry in /etc/passwd is hardly the end of the world. why isn't the call to groupadd guarded as well? If the user id already exists in /etc/passwd, useradd will exit with an error, causing the post-install script to fail. Groupadd doesn't fail with an error if the group already exists. Hence, it was not necessary to guard the call to groupadd. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466929: libuuid1: uses reserved UID and GID
severity 466929 normal thanks On Thu, Feb 21, 2008 at 10:35:27PM +0100, Jiří Paleček wrote: Package: libuuid1 Version: 1.40.2-1+lenny1 Severity: serious Tags: patch Justification: Policy 9.2.1 according to the policy, UIDs and GIDs in the range 1-100 are reserved to be globally allocated by the base-passwd package. libuuid1 allocates a dynamic UID and GID from this range. This is a violation of the policy, and it means that libuuid's user will be deleted on upgrades of the base-passwd package. Actually, adduser and addgroup automatically avoids the range 1-99, even if UID_MIN and/or GID_MIN is set to 1. It's better for script clarity set UID_MIN to 100, but it doesn't actually result in a behavioural change. Still it's good to fix this; it just doesn't warrant a severity of SERIOUS. - Ted
Bug#463058: Patch
tags 463058 +pending thanks Duploaded to anonymous-ftp-master. Thanks for doing the research and the legwork on this. I've been travelling on business so I've only had time to look into this late at night (and early in the morning) from a hotel room! - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463058: should be using a custom substvar instead of ${binary:Version}
On Tue, Jan 29, 2008 at 04:30:20PM -0800, Don Armstrong wrote:
Switching to using a custom substvar for comer-dev, uuid-dev, et al.
will fix this, ala:
Depends: libc6-dev | libc-dev, libcomerr2 (= ${mainbinary})
in control and
DH_OPTIONS= dh_gencontrol -pcomerr-dev \
-u '-v${COMERR_VERSION}-${MAIN_VERSION} -Vmainbinary=${MAIN_VERSION}'
in the rules. [I haven't tested this though, so if someone besides Ted
runs with this, you should do that first.]
Can someone explain why this is necessary, and why it had been working
for years without this? I inherited this setup from my predessor
maintainer --- was this just always buggy and worked by chance, or was
this a non-backwards change in debhelper? I just want to understand
what happened and why it suddenly started to fail.
Thanks!!
- Ted
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463058: Patch
On Tue, Jan 29, 2008 at 11:11:23PM -0200, Margarita Manterola wrote: Tags 463058 +patch Thanks Based on Don's input, here's a patch that fixes the problem. (I'm attaching the whole .diff.gz, since the original one is empty) I have built the packages and tested that this works properly. Please, please, please, apply and upload. In case you can't, I can do the NMU. I will as soon as I understand *why* the patch is needed and why it was working before without this change. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459614: e2fsprogs: FTBFS on amd64: llseek.c breaks under dietlibc
tags 459614 +pending thanks Thanks for the patch. I've applied it and it will be in the next release of e2fsprogs. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461415: xzgv: broken after xorg update
severity 461415 normal thanks On Fri, Jan 18, 2008 at 12:25:13PM +0100, [EMAIL PROTECTED] wrote: Package: xzgv Version: 0.8-5.1 Severity: grave Justification: renders package unusable I just tried to preview a png screenshot with xzgv, but xzgv just returned this error message: Gdk-ERROR **: BadAlloc (insufficient resources for operation) serial 233 error_code 11 request_code 144 minor_code 5 Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter) serial 234 error_code 9 request_code 55 minor_code 0 OK, so it doesn't work for you. But there are tons of files where it works just fine. That makes it a bug, but not a grave-on-my-gosh-the package-is-totally-broken grave severity. In order for it to be grave it has to not work for *everyone*. Otherwise pretty much every single bug could be considered grave, since almost anyone could say, this makes it unsuable for *me*! I just created a 1024x768 screenshot, and xzgv worked just fine for me. Would it be possible for you to send me a copy of the screenshot which is failing for you? Thanks!! - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459403: libuuid1: missing depends on non-essential package passwd
tags 459403 +pending thanks Thanks, i've checked in a fix into the e2fsprogs repository. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432300: e2fsprogs: fstab with unknown label makes fsck hang
On Mon, Jul 09, 2007 at 11:41:09AM +0200, t wrote: Package: e2fsprogs Version: 1.40-1 Severity: critical Justification: breaks the whole system I added the following line for a dm-crypt partition to my fstab: LABEL=crypt_office /office ext3 defaults 0 0 Can you retest with e2fsprogs 1.40.1-1, which was just uploaded? I'm 99% sure this problem is fixed with in the latest upload, and is a dup of bug #432052. Thanks, regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426147: mkfs.ext3 mkfs.ext2 etc all failing with floating point exception
reopen 426147 severity 426147 normal thanks (Oops, I didn't mean to close the bug, so I'm reopening it for now.) On Mon, May 28, 2007 at 12:54:35PM -0400, Andrew Paprocki wrote: The config is attached to this msg. This is the config for the kernel supplied on the Debian installer disc, which is what I was using. This issue is even more strange.. after I finally got the system booted by doing the partitioning/formatting on another box the mkfs.* binaries work fine on the installed system. They only seem to generate a floating point error when booted in the installation kernel off the DVD. (I got the error by running the binaries by hand in busybox). OK, so there are a couple of things going on here. First of all, the kernel which is suppled with the Debian cd/dvd for installation purposes isn't necessarily the same as the kernel which is booted by the install CD. Do you have the dmesg command available in the boot environment? If so, check to see if the kernel is emitting the following in the dmesg log: math-emulation not enabled and no coprocessor found. Whe the math emualation codeis not enabled, it will print the above message and then send a floating point exception to the program. The device I am using is a Geode LX 800, detailed here: http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_9863_13022%5E13058,00.html Integrated FPU that supports the Intel MMX(r) and AMD 3DNow!™ Technology instruction sets OK, earlier you said GX3, and from some google searches it seems that a number of GX3's don't have FPU's. And apparently some GX3's have broken error reporting, so the use of the integrated FPU is sometimes disabled, at least on NetBSD. So I am a bit paranoid about the FPU. Hence, please humor me in checking the dmesg log, would you? If the busybox binaries are a different build, then it looks like that is a place to look, as the normal package installed binaries work fine. what do you mean by busybox binaries ? Do you mean the busybox pre version 1.40 that had parts of e2fsprogs built in? Or did you mean running e2fsck from a busybox shell? In any case, if the issue is that it doesn't work in the installer enviroment, it's almost certainly an interaller bug of some kind; either in the kernel, or C libraries provided in the installation environment. And where did was this part of the Debian installation DVD, or somewhere other bootable rescue CD/DVD? - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413661: libblkid1: leaks memory like crazy
On Tue, Mar 06, 2007 at 02:08:43PM +0100, Steinar H. Gunderson wrote: Package: libblkid1 Version: 1.39+1.40-WIP-2006.11.14+dfsg-1 Severity: grave Tags: patch (RMs: I'm unsure if this should be fixed for etch or not, given that I do not know of anything in etch that actually uses this library enough for it to leak. Feel free to downgrade or tag etch-ignore, of course.) nfs-kernel-server 1.0.12 has started using libblkid, and leaks absurd amounts of memory (in the order of several megabytes per minute). Tracing using Omega (which is not yet in Debian, but nevertheless really useful) tracked the leaks down to libblkid. I've attached a diff that fixes the issues for me, and allows me to run nfs-kernel-server with only minor leaks (which I'll take with nfs-utils upstream, as they are not libblkid1 related). Yikes, what blkid function is rpc.mountd calling all the time which is causing this kind of memory leakage? Sounds like a bad thing from a power/CPU utilization standpoint (note to self; shut down rpc.mountd when I'm running on batteries on my laptop). I'm also curious why we only discovered the problem this late in the freeze Oh, I see, because nfs-kernel-server 1.0.10 is in testing, and 1.0.12 is in unstable. I assume it's unlikely that nfs-kernel-server 1.0.12 is going to migrate to testing? OK, release managers, the memory leak primarily occurs in the device mapper probing code, and an additional leak when there is a partition which does not have a valid filesystem known to blkid. rpc.mountd is, as far as I know, the first long-lived daemon using blkid, and it's apparently using it in a somewhat interesting way which is the system to constantly reprobe the disk information (if it is leaking megabytes per minute). The patch looks reasonably sane and low risk based on a on-paper examination of the code changes --- but if nfs-kernel-server 1.0.12 isn't going into etch, I'd say it's borderline whether or not we include this patch into the e2fsprogs upload I was about to do. What say ye? - Ted P.S. I really want to look at the sources of nfs-kernel-server 1.0.12 and see what it's *doing* that could be provoking a memory leak of the rate that you are describing. The memory leak is clearly blkid's fault, but the rate at which memory is leaking smells very fishy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413661: libblkid1: leaks memory like crazy
On Tue, Mar 06, 2007 at 04:54:41PM +0100, Steinar H. Gunderson wrote: On Tue, Mar 06, 2007 at 10:44:55AM -0500, Theodore Tso wrote: Yikes, what blkid function is rpc.mountd calling all the time which is causing this kind of memory leakage? blkid_probe_all_new() seems to be the one. It happens at every mount and umount, I believe; it's not like it's being called all the time (it leaks much faster on busy systems than on almost idle systems, AFAICS), it's that it leaks so _much_ memory all the time. Well, the amount of memory leaked depends on how many device mapper volumes you have, and how many of them contain unitialized volumes. And I guess this must have been on a system with a lot of mounts and unmounts. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413208: Bug#413057: nfs-kernel-server: Exports dont work any more
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]
Bug#413208: Bug#413057: nfs-kernel-server: Exports dont work any more
On Sun, Mar 04, 2007 at 02:08:01PM +0100, Frans Pop wrote: In this case it is not a problem because, AFAICT, none of the udebs built with e2fsprogs are included in any D-I initrd. I will reply separately to d-release with my reasons why I feel it would be a bad idea if it *had* been included in any initrd. So are the e2fsprogs udebs being used at all at this point? I thought the reason why we created the udebs was for D-I's initrd? - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413208: Bug#413057: nfs-kernel-server: Exports dont work any more
On Sat, Mar 03, 2007 at 08:57:40PM +0100, Steinar H. Gunderson wrote: I talked to the release team -- they'd approve a freeze exception for fixing the shlibs entry. To the Debian-Release team, Could you please confirm that you'd approve a freeze exception to fix the shlibs entry for libblkid1? It would require respinning the debian-installer images, so I want to make sure it would be acceptable before I upload a new set of e2fsprogs packages. The downside if we don't fix this bug is that someone who has sarge installed and then upgrades to nfs-kernel-server without upgrading libblkid1, will suffer bug#413057. The fix is low risk; a one-line fix in debian/rules. Thanks, regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396449: e2defrag - Unable to allocate buffer for inode priorities
Package: defrag Version: 0.73pjm1-8 Severity: grave On Wed, Nov 01, 2006 at 01:10:50AM +0800, Andreas Dilger wrote: So now it was time to defrag, I used this command: thor:~# e2defrag -r /dev/vgraid/data This program is dangerous to use and any attempts to use it should be stopped. It hasn't been updated in such a long time that it doesn't even KNOW that it is dangerous (i.e. it doesn't check the filesystem version number or feature flags). In fact we need to create a Debian bug report indicating that this package should *NOT* be included when the Debian etch distribution releases. Goswin, I am setting the severity to grave (a release-critical severity) because defrag right now is almost guaranteed to corrupt the filesystem if used with modern ext3 filesystems leading to data loss, and this satisfies the definition of grave. I believe the correct answer is either to (a) make defrag refuse to run if any filesystem features are enabled (at the very least, resize_inode, but some of the other newer ext3 filesystem features make me nervous with respect to e2defrag, or (b) since (a) would make e2defrag mostly useless especially since filesystems with resize inodes are created by default in etch, and as far as I know upstream abandoned defrag a long time ago, that we should simply remove e2defrag from etch and probably from Debian altogether. If you are interested in doing a huge amount of auditing and testing of e2defrag with modern ext3 (and soon ext4) filesystems, that's great, but I suspect that will not at all be trivial, and even making sure e2defrag won't scramble users' data probably can't be achievable before etch releases. Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388718: Bug#393680: e2fsprogs: FTBFS (amd64): /libselinux-1.30.28/src/setrans_client.c:210: undefined reference to `pthread_mutex_lock'
On Thu, Oct 19, 2006 at 11:22:36PM -0700, Steve Langasek wrote: Well, after tracking it down, I'd call it the same bug. I'm not sure why the problem now only manifests on amd64, but the issue is that the latest change has -lpthread listed on the linker commandline before the static libs that need it, leading to the undefined references. Doh!Thanks for tracking this down! - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393680: e2fsprogs: FTBFS (amd64): /libselinux-1.30.28/src/setrans_client.c:210: undefined reference to `pthread_mutex_lock'
On Tue, Oct 17, 2006 at 03:29:16PM -0700, Steve Langasek wrote: reopen 388718 merge 393680 388718 tags 388718 -fixed thanks On Tue, Oct 17, 2006 at 01:48:55PM +0200, Andreas Jochens wrote: when building 'e2fsprogs' on amd64/unstable, I get the following error: Duplicate of bug #388718. Fixing up the status on that bug so it shows up where it's supposed to. This problem used to exist on x86, and I fixed it using a suggested patch as found in bug #388718. I can no longer replicate it on the x86 platform. I tried building it on pergolesi.debian.org, so I could try to debug why it is apparently still failing on x86_64, but unfortunately the unstable chroot is missing the following packages: texi2html (= 1.76) dc libsepol1-dev libdevmapper-dev libselinux1-dev Could someone on debian-admin install these packages in the unstable chroot on pergolesi, please? I looked into using pbuilder, but that also requires root privileges. Since the problem was fixed on x86 using the suggested patch for #388718, I believe that 393680 and 388718 are actually different bugs, although they may have similar symptoms. Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390664: closed by [EMAIL PROTECTED] (Theodore Y. Ts'o) (Bug#390664: fixed in e2fsprogs 1.39+1.40-WIP-2006.10.02+dfsg-1)
On Wed, Oct 04, 2006 at 01:54:06PM +0200, Simon Josefsson wrote: Btw, the draft in question has been revised and published as RFC 4120. Adding the URL to it in README.Debian or somewhere might be helpful. RFC 4120 is The Kerberos Network Authentication Service (V5) and has nothing to do with UUID's... I've done some looking and it looks like you mean RFC 4122. Thanks for pointing that out. I wasn't aware that the specification had been published, after something like a ten-year hiatus! - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390664: closed by [EMAIL PROTECTED] (Theodore Y. Ts'o) (Bug#390664: fixed in e2fsprogs 1.39+1.40-WIP-2006.10.02-1)
On Tue, Oct 03, 2006 at 03:02:32PM +0200, Simon Josefsson wrote: Thanks for dealing with the bug so fast! The source package appear to contain the same file: http://ftp.debian.org/debian/pool/main/e/e2fsprogs/e2fsprogs_1.39.orig.tar.gz e2fsprogs-1.39/doc/draft-leach-uuids-guids-01.txt Steve Langasek suggested on debian-legal that asking for permission from the document authors would be preferable to removing the file. According to the file, the authors are Paul J. Leach [EMAIL PROTECTED] and Rich Salz [EMAIL PROTECTED], but the document suggests others may own the document too: It is legal to distribute the source file, so leaving the I-D in the source should not be an issue. Debian Policy merely says that the packages must be DFSG compliant, but as far as I know, the controlling guidelines for the source files are: (1) it is highly desirable that the file be identical to the upstream, and (2) it must be legal for our FTP mirrors to distribute. Both conditions are currently satisified, so I don't see a justification for diverging with the upstream source file just to remove the I-D. Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390664: closed by [EMAIL PROTECTED] (Theodore Y. Ts'o) (Bug#390664: fixed in e2fsprogs 1.39+1.40-WIP-2006.10.02-1)
On Tue, Oct 03, 2006 at 04:52:59PM +0200, Simon Josefsson wrote: There is DFSG #4: 'Integrity of The Author's Source Code: The license may restrict source-code from being distributed in modified form _only_ if the license allows the distribution of patch files with the source code for the purpose of modifying the program at build time.' http://www.debian.org/social_contract#guidelines That's not completely explicit, but it does suggest that source-code should be modifiable. Documentation != source code, especially given the context of DFSG #4 which states for the purpose of modifying the program at build time. The binaries don't depend on the I-D at all. Actually, until now, I haven't looked in source code packages for DFSG-nonfree material, and I should probably find a better reference to why source packages has to be DFSG-free, if that is actually the case at all (I'm not sure on that). I'll ask on debian-legal. This is out of scope of debian-legal, I think, because it's not a matter of interpreting the DFSG or a license. It's really matter for the FTP masters and the Release manager, I think. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390664: [EMAIL PROTECTED]: Re: Bug#390664: closed by [EMAIL PROTECTED] (Theodore Y. Ts'o) (Bug#390664: fixed in e2fsprogs 1.39+1.40-WIP-2006.10.02-1)]
I would appreciate any comments from the Debian Release Managers and Debian Masters about whether or not it is required to remove any files which are legal for us to redistribute (such as RFC's and I-D's), but which are not DFSG-compliant from source tarballs (but which are not included in any of packages which are part of 'main' or 'contrib'). I can find no statement in Debian Policy which requires this, and there is an admonition to try to not to deviate from the upstream source tar file whenever possible. If any comments could be made to bug #390664, it would be much appreciated. Regards, - Ted ---BeginMessage--- On Tue, Oct 03, 2006 at 03:02:32PM +0200, Simon Josefsson wrote: Thanks for dealing with the bug so fast! The source package appear to contain the same file: http://ftp.debian.org/debian/pool/main/e/e2fsprogs/e2fsprogs_1.39.orig.tar.gz e2fsprogs-1.39/doc/draft-leach-uuids-guids-01.txt Steve Langasek suggested on debian-legal that asking for permission from the document authors would be preferable to removing the file. According to the file, the authors are Paul J. Leach [EMAIL PROTECTED] and Rich Salz [EMAIL PROTECTED], but the document suggests others may own the document too: It is legal to distribute the source file, so leaving the I-D in the source should not be an issue. Debian Policy merely says that the packages must be DFSG compliant, but as far as I know, the controlling guidelines for the source files are: (1) it is highly desirable that the file be identical to the upstream, and (2) it must be legal for our FTP mirrors to distribute. Both conditions are currently satisified, so I don't see a justification for diverging with the upstream source file just to remove the I-D. Regards, - Ted ---End Message---
Bug#388718: e2fsprogs: FTBFS: Link error in e2fsck.static
On Sat, Sep 30, 2006 at 12:10:33PM +0100, Ben Hutchings wrote: I can see Steve's point. I'm attaching another version of the patch that appears to remove the spurious direct dependencies. I intend to NMU this with the trivial short-term fix, though. This doesn't fix the problem, though, I think. It looks like it doesn't include -lpthread: [EMAIL PROTECTED]:~/e2fsprogs/e2fsprogs-1.39$ pkg-config --libs devmapper -L/lib -ldevmapper [EMAIL PROTECTED]:~/e2fsprogs/e2fsprogs-1.39$ pkg-config --libs --static devmapper -L/lib -ldevmapper -lselinux -lsepol Am I missing something? - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
