Bug#1095604: sddm: no way to disable the virtual keyboard

Package: sddm Version: 0.21.0+git20241213.4a9aa2e-1 Severity: normal Since upgrading to the latest version of sddm and kde on Debian testing, on reboot, the sddm is showing a very large, anoying virtual keyboard. Google searches indicate that the root causing is that InputMethod=qtvirtualkeytobar

Bug#1091483: (no subject)

I confirm this bug on sid. For the time being, I managed to restore kile functionality by manually downgrading okular to 23.08.1-2+b2 from testing. I did that by manually downloading and installing the following 4 packages: libkf5pty5_5.115.0-2+b1_amd64.deb libkf5pty-data_5.115.0-2_all.deb

Bug#1088960: fsarchiver: potential incompatibility with e2fsprogs 1.47.2

On Wed, Dec 04, 2024 at 01:24:39PM +0100, Michael Biebl wrote: > Patching fsarchiver to use -E revision=0 (or rather try both as I can't > assume I have a new e2fsprogs) could be an option if someone provided a > patch. Are you willing to work on such a patch? This patch compiles, but has not been

Bug#1088960: fsarchiver: potential incompatibility with e2fsprogs 1.47.2

On Wed, Dec 04, 2024 at 01:24:39PM +0100, Michael Biebl wrote: > > Assume a user has a file system that was created a long time ago using > rev=0. This doesn't necessarily mean that he is using a 30-year old Linux > kernel! > They have made continuous backups of that file system. With this change

Bug#1088960: fsarchiver: potential incompatibility with e2fsprogs 1.47.2

On Tue, Dec 03, 2024 at 08:22:49PM +0100, Michael Biebl wrote: > > Just to clarify: The failing test uses -r 1, not 0: > > fs_ext2.c#383,extfs_mkfs(): command [mke2fs -q -F -b 1024 -L 'Test' -U > 31ec6c69-80a1-4ed6-9642-f2b78f798bff -I 256 -r 1 -O > has_journal,ext_attr,resize_inode,dir_i

Bug#1088960: fsarchiver: potential incompatibility with e2fsprogs 1.47.2

On Tue, Dec 03, 2024 at 04:23:39PM +0100, Michael Biebl wrote: > > B) Revert e2fsprogs's change to address bug 1086603 and not worry about > > leaving an exposed, sharp edge to careless users. > > Personally I would prefer B, all the other options don't sound really > appealing. The problem w

Bug#1088960: fsarchiver: potential incompatibility with e2fsprogs 1.47.2

Package: fsarchiver Version: 0.8.7-1+b1 Severity: normal Debian CI testing has uncovered an incompatibility with e2fsprogs 1.47.2-rc1, as can be seen here[1]. The root cause of the failure of the test backup-and-restore-ext4.sh is that the -r option of mke2fs has been removed and replaced with "-

Bug#1078693: e2fsprogs: introduced a bootstrap dependency cycle with libarchive

; "be able to process tarballs")); diff --git a/debian/control b/debian/control index bc582cd8..2d1cfd88 100644 --- a/debian/control +++ b/debian/control @@ -2,7 +2,7 @@ Source: e2fsprogs Section: admin Priority: required Maintainer: Theodore Y. Ts'o -Build-Depen

Bug#1086861: e2fsprogs: filesystem repair at boot fails

On Mon, Nov 25, 2024 at 05:59:20PM -0500, Anees Ahmad wrote: > On Mon, Nov 25, 2024, 5:49 p.m. Theodore Ts'o wrote: > > Ah, ok, thanks for pointing this out. If this is indeed the same bug, > > it should be fixed in the e2fsprogs git tree. Are you in a position > >

Bug#1088731: vcswatch confusion: e2fsprogs does not exceeds 500 MiB

Package: qa.debian.org Severity: normal Per https://qa.debian.org/cgi-bin/vcswatch?package=e2fsprogs The e2fsprogs repository is blocked because: Repository size 537583616 exceeds 500 MiB, blocking it However, this is very clearly not the case: % git clone https://git.kernel.org/pub/

Bug#1082500: /usr/include/ext2fs/ext2fs.h [-Wunused-parameter] warning: unused parameter ‘seconds’ ‘extra’

8:41 2024 +0200 libext2fs: fix unused parameter warnings/errors This fixes building dependent packages that use -Werror. Signed-off-by: Alyssa Ross Link: https://lore.kernel.org/r/20240528131841.576999-1...@alyssa.is Signed-off-by: Theodore Ts'o It will be in the n

Bug#1087898: tune2fs.8: Some remarks and editorial changes for this man page

On Wed, Nov 20, 2024 at 01:03:59AM +, Bjarni Ingi Gislason wrote: > Package: e2fsprogs > Version: 1.47.1-1+b1 > Severity: minor > Tags: patch > > Checking for defects with > > test-[g|n]roff -mandoc -t -K utf8 -rF0 -rHY=0 -ww -b -z < "man page" > > General remarks and further material

Bug#1086861: e2fsprogs: filesystem repair at boot fails

On Mon, Nov 25, 2024 at 03:53:19PM -0500, Anees Ahmad wrote: > I noticed this very similar redhat bug, I think it matches this one. Maybe > it will provide some more information. > > https://bugzilla.redhat.com/show_bug.cgi?id=2318710 Ah, ok, thanks for pointing this out. If this is indeed the

Bug#1086861: e2fsprogs: filesystem repair at boot fails

On Thu, Nov 07, 2024 at 11:08:19AM -0500, Anees Ahmad wrote: > Hello Ted, > > I have tried on 4 different computers and it is reproducible on all of them > on unclean shutdown. Well, I can't reproduce it for on my Debian Trixie. I'm running on a Dell Precision 3640 Tower, with an NVMe SSD. Kern

Bug#1086861: e2fsprogs: filesystem repair at boot fails

On Wed, Nov 06, 2024 at 01:23:01PM -0500, Anees Ahmad wrote: > Hello, > > The issue described initially does not happen when both packages > *e2fsprogs_1.47.0-2.4_amd64.deb* > > and

Bug#1086603: tune2fs, dumpe2fs: sometimes do not show the inode size

On Tue, Nov 05, 2024 at 05:22:57AM +0100, Thorsten Glaser wrote: > > So, why does 5.10.208-xfstests warn but 5.10.226-1 doesn’t? > > (It *does* warn about r1 128-byte-inode ones.) No idea... % cd /usr/projects/linux/ext4-5.10 % git checkout v5.10.226 % install-kconfig % kbuild % kvm-xfstests sh

Bug#1086603: tune2fs, dumpe2fs: sometimes do not show the inode size

On Tue, Nov 05, 2024 at 12:11:24AM +0100, Thorsten Glaser wrote: > if [[ $dat = *"$nl"'Filesystem revision #:'*([ ])0* ]]; then > let ++p > print -ru2 "W: $vis has Y2038 problem and is a revision 0 > filesystem" > print -ru2 'N: you must recreate

Bug#1086603: tune2fs, dumpe2fs: sometimes do not show the inode size

On Tue, Nov 05, 2024 at 12:10:25AM +0100, Thorsten Glaser wrote: > On Mon, 4 Nov 2024, Theodore Ts'o wrote: > > >> (I had tune2fs -r in the back of my head.) > > > >I've aways used mke2fs -m and tune2fs -m, myself. I personally very > >rarely using -m 0

Bug#1086603: tune2fs, dumpe2fs: sometimes do not show the inode size

On Sun, Nov 03, 2024 at 12:36:10AM +0100, Thorsten Glaser wrote: > From syslog, I apparently did: > > sudo /sbin/mkfs.ext4 -r 0 -L fs-pbuilder /dev/vg-cafe/lv-vcpb Ah, OK, so that explains it. > (I had tune2fs -r in the back of my head.) I've aways used mke2fs -m and tune2fs -m, myself. I pers

Bug#1086603: tune2fs, dumpe2fs: sometimes do not show the inode size

Can you send the full output of dumpe2fs -h? I suspect what happens is that you might be testing a revision 0 file system. >From e2fsprogs/lib/e2p/ls.c: fprintf(f, "Filesystem revision #:%d", sb->s_rev_level); if (sb->s_rev_level == EXT2_GOOD_OLD_REV) { fprint

Bug#1084085: tzc uploaded to delayed=10

On Wed, Oct 30, 2024 at 10:47:58PM +0100, Andreas Tille wrote: > > I admit I have no personal interest in this package and I do not use it. > My interest was to make some package that was NMUed a couple of times, > and thus obviously gained some interest by several people, more easily > accessible

Bug#1084085: tzc uploaded to delayed=10

On Mon, Oct 28, 2024 at 07:41:22AM +0100, Andreas Tille wrote: > Control: tags -1 pending > Thanks > > Hi, > > as per ITS bug I have uploaded tzc to delayed=10. Do you have access to a Zephyr messaing system so you can test tzc? And are you using the emacs zephyr-mode? Which might be a good ide

Bug#1078693: e2fsprogs: introduced a bootstrap dependency cycle with libarchive

On Wed, Aug 14, 2024 at 01:50:24PM +0200, Helmut Grohne wrote: > How about separating the availability of libarchive from the interest in > supporting libarchive? Since it is runtime-loaded using dlopen, > e2fsprogs already carries the prototypes for most libarchive functions > and doesn't actually

Bug#1078591: linux-image-6.10.3-amd64, regression, fails boot while fsck (undefined symbol: ext2fs_list_backups)

On Tue, Aug 13, 2024 at 03:18:02PM +0200, Giuseppe Sacco wrote: > Hello Santiago, > > Il giorno mar, 13/08/2024 alle 12.34 +0200, Santiago Vila ha scritto: > [...] > > Hello. This looks like a problem with fsck.ext4 to me. > > > > Does the problem go away if you regenerate the initrd of the kerne

Bug#1072566: mke2fs: should not enable metadata_csum_seed and orphan_file by default in bookworm-backports

severity 1072566 minor thanks On Thu, Jun 06, 2024 at 12:19:39PM +0200, Fabio Fantoni wrote: > You wrote about metadata_csum but the issue is not with it, included > also in the root filesystem that don't have issue with backup but with > metadata_csum_seed that is different and newer, anyway seem

Bug#1072566: mke2fs: should not enable metadata_csum_seed and orphan_file by default in bookworm-backports

On Tue, Jun 04, 2024 at 02:33:27PM +0200, Fabio Fantoni wrote: > Package: e2fsprogs > Version: 1.47.1~rc2-1~bpo12+1 > Severity: important > > Dear Maintainer, > > After a debug of a issue with backup I spotted that the cause was > metadata_csum_seed and orphan_file enabled by default in e2fsprog

Bug#1070358: clang-16: -fsanitize=fuzzer not working on trixie (but working on bookworm)

Package: clang-16 Version: 1:16.0.6-26 Severity: normal Dear Maintainer, I was trying to track down a regression reported by the ClusterFuzz service, and when I try to build the fuzzing reproducer on trixie, it fails. However, it works on Bookworm. So while I can work around the problem by usin

Bug#1070042: libarchive: archive_entry_stat returns zero size on mips64el with _FILE_OFFSET_BITS=64

reassign 1070042 e2fsprogs 1.47.1~rc1-1 retitle mke2fs -d foo.tar is broken on mips64el thanks On Tue, Apr 30, 2024 at 11:12:36AM +0300, Peter Pentchev wrote: > > AC_SYS_LARGEFILE was added to e2fsprogs configure.ac 2 years ago, > > therefore manual > > #define _FILE_OFFSET_BITS 64 > > #defin

Bug#1070042: libarchive: archive_entry_stat returns zero size on mips64el with _FILE_OFFSET_BITS=64

;ver=1.47.1%7Erc1-1&stamp=1714294103&raw=0 Cheers, - Ted commit 018cd6e9a659917ac1374775f5a60b1cf0be182c Author: Theodore Ts'o Date: Mon Apr 29 16:31:14 2024 -0400 debian: don't build with libarchive on mips64el The libarchive functionality i

Bug#1060221: linux-image-6.5.0-5-arm64: gcc13 crashes in parallel builds; fixed with the 6.6.9 kernel

Package: src:linux Version: 6.5.13-1 Severity: normal Dear Maintainer, I am running Debian testing in a Parallels VM (6 cores, 8GB memory) running on Macbook Air M2 15" (10 cores, 24GB memory). gcc13 is sig faulting when building xfsprogs or the Linux kernel when using make -j6. Building xfsprog

Bug#1056145: e2fsprogs: FTBFS on hurd-i386

ed. - Ted commit 795dcc264f48098ca5b214bba7d1b94189b2e491 Author: Theodore Ts'o Date: Sun Nov 19 21:06:12 2023 -0500 tune2fs.c: define PATH_MAX if it is not defined by the system headers This is needed to compile on GNU/Hurd. Addres

Bug#1055808: fsck at boot always skipped due to APM_EMULATION kernel option

On Sat, Nov 11, 2023 at 10:22:21PM +0100, Christoph Biedl wrote: > Package: e2fsprogs > Version: 1.47.0-2+b1 > Severity: normal > Tags: upstream > X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de > > Greetings, > > Summary: If the APM_EMULATION kernel option is enabled (and built-in), > fsck during b

Bug#1053111: e2fsprogs FTBFS when systemd.pc changes systemdsystemunitdir

On Tue, Sep 26, 2023 at 10:31:41PM +0200, Helmut Grohne wrote: > Source: e2fsprogs > Version: 1.47.0-2 > Tags: ftbfs patch > User: helm...@debian.org > Usertags: dep17m2 > > We want to change the value of systemdsystemunitdir in systemd.pc to > point below /usr. e2fsprogs' upstream build system co

Bug#1034000: snapshot.debian.org: Unusual number of 503s on snapshot.d.o

Package: snapshot.debian.org Followup-For: Bug #1034000 I'm seeing similar failures for a number for the last three snapshots listed at: http://snapshot.debian.org/archive/debian/?year=2023&month=8 Namely for: * 2023-08-06 09:19:12 * 2023-08-07 15:08:23 * 2023-08-09 03:23:42 As noted in [1]

Bug#1040622: systemd-sysv: reboot doesn't honor the grub-reboot settings; reboot -f does

Package: systemd-sysv Version: 252.6-1 Severity: normal Dear Maintainer, * What led up to the situation? I was updating the gce-xfstests[1] test appliance to Debian Bookworm from Debian Bullseye. [1] https://thunk.org/gce-xfstests * What exactly did you do (or not do) that was effective

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

severity 1035543 normal retitle 1035543 e2fsprogs: on an upgrade from bullseye e2scrub-reap.service may be wanted by default.target instead of multi-user.target thanks On Thu, Jun 01, 2023 at 07:40:25PM +0100, James Addison wrote: > > So it's not a big deal; is that correct so this patch is not w

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

In addition to Bookworm being hard frozen, I question the importance of this patch, the bug priority, and whether the title is correct. After all, at least with respect to e2fsprogs systemd unit *will* still be enabled. It will just be enabled using ../multi-user.target/wanted instead of ../defaul

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

On Sat, May 27, 2023 at 11:09:32PM +0200, Helmut Grohne wrote: > Hi, > > I sat down with Jochen in Hamburg to try and fix this. > > On Sun, May 14, 2023 at 03:21:24PM -0400, Theodore Ts'o wrote: > > Can someone send the instructions on how to fix this? > > We wis

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

On Sun, May 14, 2023 at 06:03:59PM +0200, Michael Biebl wrote: > > Please reassign it there together with instructions how to fix it, i.e. > > what should be done in the maintainer scripts. Can someone send the instructions on how to fix this? I'm always amused by people who claim systemd is "sim

Bug#1034746: Bug: mk2efs/mkfs.ext4 does not create the correct amount of inodes if -i is specified with 640k to 832k

On Sun, Apr 23, 2023 at 09:34:39AM +0200, The MH wrote: > Package: e2fsprogs > Version: 1.46.5 > Severity: minor > > I did not find this bug in the patchnotes for the latest versions on > e2fsprogs.sourceforge.net/e2fsprogs-release.html, so I assume it is > still present. > > I stumbled upon this

Bug#1031640: Bug#1030940: e2fsprogs: generates filesystems that grub-install doesn't recognize

On Tue, Feb 21, 2023 at 12:17:20PM +, Christopher Obbard wrote: > Control: severity -1 important > Control: retitle -1 e2fsprogs generates filesystems which cannot be > mounted on systems with older e2fsprogs > > It turns out for debos the situation is a bit different. Since debos > uses packa

Bug#1031622: d-i regression since bookworm alpha 1: creates a filesystem with FEATURE_C12 unsupported by the installed e2fsck

On Sun, Feb 19, 2023 at 01:23:19PM +, Simon McVittie wrote: > > I think this could be caused by debian-installer having udebs from > e2fsprogs 1.47.0-1 in the installation environment, so that the version > used to create the root filesystem has newer feature flags than the > installed version

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

On Fri, Feb 17, 2023 at 10:34:29PM +0200, Adrian Bunk wrote: > > The same general problem applies in various "building non-Debian > embedded Linux filesystem on Debian" situations where the target > chroot does not contain mkfs.ext4. In practice, if the root file system is using ext4, the target

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

On Fri, Feb 17, 2023 at 12:43:01PM -0700, Sam Hartman wrote: > > I am not entirely convinced that using current rather than guest > tools for image building is an anti-pattern. You've been working on > filesystems for a long time; I've been working on various image > building projects since my fi

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

On Fri, Feb 17, 2023 at 02:08:28PM -0500, Theodore Ts'o wrote: > So enabling what may be > convenient, but ultimately an anti-pattern is something that hopefully > in the long-term Debian should be striving towards. Sigh, I managed to invert the sense of what I was trying to say

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

On Fri, Feb 17, 2023 at 08:51:33AM -0800, Russ Allbery wrote: > Adrian Bunk writes: > > > The image creators could just set the features they enable to what they > > copied from /etc/mke2fs.conf from the target distribution, a label with > > a timestamp wouldn'tbring much benefit here. > > That'

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

On Thu, Feb 16, 2023 at 11:45:23AM -0800, Russ Allbery wrote: > > Yes, I'm probably understating the difficulty of making this change in > practice inside image building software as it's currently constructed. > > My concern about changing mkfs options is that I worry that this would be > a const

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

On Wed, Feb 15, 2023 at 07:39:28PM -0800, Russ Allbery wrote: > It had never occurred to me before that the version of the system on which > I run mke2fs would matter as long as I didn't pick a newer file system > type (ext5 or something). Now I know! Until today, I had no idea ext4 > even *had*

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

On Wed, Feb 15, 2023 at 04:06:55PM -0700, Sam Hartman wrote: > > You argue about shared libraries for non-packaged binaries. > I think we mostly don't care about that, and again, I think that's at > least a generally recognized thing that came out of our focus on > packages and package dependencie

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

On Wed, Feb 15, 2023 at 01:17:38PM -0700, Sam Hartman wrote: > > I.E. I think your question of "for how long" has a very simple answer > based on our history: if we care about stability in this instance it's > for +/-1 Debian release. > > I'm struggling trying to figure out whether we should comm

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

On Wed, Feb 15, 2023 at 11:47:08AM +0200, Adrian Bunk wrote: > > For normal library dependencies > Depends: libc6 (>= 2.34) > will do the right thing automatically. Sure, but dependencies only apply if you are using building packages. If you are not building packages, but just moving binaries b

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

There is more about this in the referenced bugs, but I dispute Daniel's characterization of the issue. I will draw the analogy of building a program which links against glibc for Bookworm resulting in a binary that will not run on Buster. We expect that, and we tell people to use build chroots. T

Bug#1030846: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

On Tue, Feb 14, 2023 at 07:35:51PM +0100, Daniel Leidert wrote: > > As soon as this version hits testing, you have successfully disabled > the last working environment to use vmdb2 to create images of Ubuntu > and Debian. As soon as this version hits Testing, one then can no > longer build images

Bug#1030846: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

There is another issue with vmdb2 if you are using XFS. Starting with xfsprogs 5.15 (which is already in testing), bigtime is enabled by default, so that newly created XFS file systems won't be subject to timestamp overflow in 2038. Grub didn't land support for this feature until 8b1e5d1936ff ("f

Bug#1030846: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

On Tue, Feb 14, 2023 at 01:01:38AM +0100, Daniel Leidert wrote: > Hi Steve, > > I believe that your fix to grub2 in Sid is not enough to handle > #1030939/#1030846. > > This problem breaks e.g. vmdb2. I can no longer create a Bullseye > system image with vmdb2 on Sid, because the grub-install ste

Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

On Fri, Feb 10, 2023 at 08:31:04AM +0100, Cyril Brulebois wrote: > > Holding back file system development because grub2 uptsream is super > > slow doesn't seem like a reasonable way forward, so I really don't > > want to set this precedent. > > The Bookworm freeze has started, we need to be able t

Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

On Thu, Feb 09, 2023 at 06:55:08PM +0100, Sven Joachim wrote: > >> > >> Thanks from me as well :-). To prevent e2fsprogs from migrating to > >> testing before grub2 and breaking d-i, I am reassigning a copy of this > >> bug back to e2fsprogs. It may be closed once grub2 2.06-8 enters > >> Bookwor

Bug#1030846: e2fsprogs: generates filesystems that grub-install doesn't recognize

On Thu, Feb 09, 2023 at 06:04:23PM +0100, Sven Joachim wrote: > > Thanks from me as well :-). To prevent e2fsprogs from migrating to > testing before grub2 and breaking d-i, I am reassigning a copy of this > bug back to e2fsprogs. It may be closed once grub2 2.06-8 enters > Bookworm. Perhaps i

Bug#1030846: e2fsprogs: generates filesystems that grub-install doesn't recognize

On Wed, Feb 08, 2023 at 09:12:05PM +, Steve McIntyre wrote: > > I've just queued these up in our repo for the next grub upload, due in > a few days. Many thanks, Steve! - Ted

Bug#1030846: e2fsprogs: generates filesystems that grub-install doesn't recognize

ome grub2 patches, may also make a plug for this one, which is also in the upstream grub2 git repo: commit 2e9fa73a040462b81bfbfe56c0bc7ad2d30b446b Author: Theodore Ts'o Date: Tue Aug 30 22:41:59 2022 -0400 fs/ext2: Ignore the large_dir incompat feature Recently, ext4 added t

Bug#1022096: e2fsprogs: debian: make the copyright file machine readable

On Wed, Oct 19, 2022 at 11:45:22PM +0200, Bastian Germann wrote: > Source: e2fsprogs > Severity: serious > Tags: patch > Version: 1.46.6~rc1-1 > > Hi Theodore, > > There are several distribution licenses and copyright information not > mentioned, which are required by

Bug#1025791: fsck.f2fs is unable to check mounted FS

OK, I've done some final fixups (there was something weird with the spelling patch that caused dgit to have heartburt) and have done a "dgit push-source" and pushed git tree to salsa. Thanks again for your help. Since you are investigating using f2fs, I thought I would let you know that there are

Bug#1025791: fsck.f2fs is unable to check mounted FS

On Mon, Dec 12, 2022 at 09:41:38AM +0300, Michael Tokarev wrote: > > I pushed "mjt" branch yesterday to the repository (without pristine-tar > and upstream pieces so far) which updates f2fs to 1.15 and adds minor > cleanups to d/rules. Please take a look. Thanks! The main thing I will note is th

Bug#1025791: fsck.f2fs is unable to check mounted FS

On Sun, Dec 11, 2022 at 09:55:48AM +0300, Michael Tokarev wrote: > > Hmm. I'm a bit afraid it will be similar to my experience with samba. > I come across a (data corruption) bug, discovered it's been fixed upstream > a few years ago, tried to push the fix to debian, and ended up becoming a > sin

Bug#1025791: fsck.f2fs is unable to check mounted FS

On Fri, Dec 09, 2022 at 11:16:46AM +0300, Michael Tokarev wrote: > Package: f2fs-tools > Version: 1.14.0-2 > Severity: important > > When running an fsck.f2fs on a readonly-mounted filesystem (root filesystem > for example, which obviously can not be unmounted), fsck.f2fs always fails: > > I don'

Bug#1023450: e2fsprogs - Does not agree with kernel on clean state

I'm working to improve the testing so this would have gotten caught earlier. - Ted commit 9a8c5b0d061554fedd7dbe894e63aa34d0bac7c4 Author: Theodore Ts'o Date: Thu Oct 27 16:04:36 2022 -0400 ext4: update the backup superblock's at th

Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab

On Fri, Oct 14, 2022 at 03:37:29PM +0200, Marco d'Itri wrote: > On Oct 14, Vincent Lefevre wrote: > > > > This is obviously convenient on Guillem's part, but we have to optimize > > > systems by default for the general case and not just for dpkg -i. > > This dpkg FAQ says that this is not benefi

Bug#1021250: libcom-err2: sudo apt install wine32 fail to install

On Tue, Oct 04, 2022 at 01:45:31PM +0200, David Gonzalo Rodriguez wrote: > Package: libcom-err2 > Version: 1.46.5-2~bpo11+2 > Severity: important > Tags: upstream > X-Debbugs-Cc: z80u...@gmail.com What is the error message when you run "sudo apt install wine32"? What is the reason for believing t

Bug#1016675: This is already fixed upstream

On Thu, Aug 11, 2022 at 08:02:15PM +1200, Alex King wrote: > We are using Direct IO to slow mkfs and therefore lower I/O load. I'm not > aware of a way to directly ask mkfs to reduce the I/O load or work more > slowly. Using ionice at idle priority would be ideal, but we are using the > mq-deadli

Bug#1016675: This is already fixed upstream

I'm just curious --- what is your use case for wanting to use Direct I/O in mke2fs? In general, using buffered I/O is much faster, and the historically, Direct I/O option was primarily used as a workaround for kernels (long ago) that were buggy with respect to write throttling, and userspace progr

Bug#1010263: CVE-2022-1304

Applied upstream as commit: ab51d587

Bug#1010264: Bug#1010263: Bug#1010264: CVE-2022-28391

On Thu, Apr 28, 2022 at 09:30:45AM +0200, Salvatore Bonaccorso wrote: > > Theodore, btw the BTS reference for the e2fsprogs issue is #1010263 > and the CVE id CVE-2022-1304. Yes, I've noted that already. > #1010264 and CVE-2022-28391 is respectively for busybox. the bug >

Bug#1010264: CVE-2022-28391

On Wed, Apr 27, 2022 at 01:55:27PM +0200, Moritz Muehlenhoff wrote: > Package: e2fsprogs > Version: 1.46.5-2 > Severity: important > > This issue was found by Alpine: > https://gitlab.alpinelinux.org/alpine/aports/-/issues/13661 > > Details and the patches they used are in the report above, but t

Bug#1008107: "mke2fs -E android_sparse" yields: "Unimplemented ext2 library function while setting up superblock" (not built against libsparse?)

On Tue, Mar 22, 2022 at 11:59:49AM -0400, Daniel Kahn Gillmor wrote: > Package: libext2fs2 > Version: 1.46.5-2 > Control: affects -1 + fastboot android-sdk-platform-tools > > The -E android_sparse option for mke2fs fails because libext2fs2 reports > EXT2_ET_UNIMPLEMENTED, presumably because libext

Bug#1006253: iwd is crashing with a segfault

Hi Jonas, I was checking Debian Bug tracker to make sure the bug metadata was correct after closing it, and I realized that you had replied on Tuesday, February 22nd (Message #10). My apologies, for some reason that message never arrived at my inbox (and I checked the spam filter as well). So I

Bug#1006253: iwd is crashing with a segfault

Package: iwd Version: 1.24-1 Severity: important Dear Maintainer, After upgrading to iwd 1.24-1, it is crashing on my system. (Dell XPS-13 with an ath10k/QCA6174/hw3.0 wireless card.) Downgrading to iwd 1.21-3 allows things to work. Restalling iwd 1.24-1 causes it crash again. If I run /usr/l

Bug#1003583: e2fsprogs and libext2fs2 in bullseye-backports missing dependency

found 1003583 e2fsprogs/1.46.5-2~bpo11+1 notfound 1003583 e2fsprogs/1.46.2-2 thanks > Dear Maintainer, > >* e2fsprogs and libext2fs2 version 1.46.5-2~bpo11+1 are in the > bullseye-backports repository >* both depend on libc6 (>= 2.33) for amd64 >* libc6 versions 2.33 and higher do not

Bug#992469: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system

On Thu, Aug 19, 2021 at 11:46:21AM +0200, Michael Biebl wrote: > Am 19.08.21 um 08:27 schrieb Michael Biebl: > > I'll check later today, if i-s-h (init-system-helpers) does properly > > handle this new path. If so, I'd say the bug should be reassigned to > > lintian and we should start transitionin

Bug#992469: debhelper: dh_installsystemd installs services in /usr/lib/systemd/system/

Package: debhelper Version: 13.4+nmu1 Followup-For: Bug #992469 I can confirm Samuel's analysis. When I tried debugging why building e2fsprogs was causing a new lintian error: E: e2fsprogs: systemd-service-file-outside-lib usr/lib/systemd/system/e2scrub@.service N: E: systemd-service-file-outsi

Bug#992094: e2fsprogs: mke2fs fails to create file system

tags 992094 +pending thanks On Wed, Aug 11, 2021 at 02:56:06PM +0200, Heinrich Schuchardt wrote: > > https://ci.debian.net/data/autopkgtest/unstable/amd64/e/e2fsprogs/14285096/log.gz > > shows the following errors for debian/tests/fuse2fs: > > mke2fs: > No such file or directory while trying to

Bug#991922: FTBFS on s390x: Tests failed: f_baddotdir

to reproduce it on a porter box. (Note: the bug doesn't exist in 1.46.2, which is fortuante since things are locked down for the upcoming stable release.) Thanks for the bug report. I'm glad to report that this is already fixed upstream: commit 225e5d093b519f9dbe9fcaacd995426f0e519

Bug#986332: lsattr on certiain files in /dev results in "stack smashing detected"

tags 986332 +pending thanks The following commit should fix things; it will be in the next release of e2fsprogs. - Ted commit a3f844da91f0c01209a5d778a5af57fabe245332 Author: Theodore Ts'o Date: Fri Jul 16 22:31:26 2021 -0400 libe2p

Bug#989612: mke2fs -E offset=N still warns about existing partition table at the beginning

tags 989612 +pending thanks Thanks for reporting this bug. The following commit should fix the issue. - Ted commit 942b00cb9d2f2b52f4c58877d523145ee59a89b0 Author: Theodore Ts'o Date: Wed Jul 21 15:46:09 2021 -0400 mke2fs: do not

Bug#989630: mke2fs with size limit and default discard will discard data after size limit

ng on. The patch to fix this is attached below. - Ted commit 6568ba325e54a2ae1d2617c5175936c819ab4c8c Author: Theodore Ts'o Date: Sun Jul 18 09:15:28 2021 -0400 mke2fs: only try discarding a single block to test if discard works

Bug#989612: mke2fs -E offset=N still warns about existing partition table at the beginning

On Thu, Jun 17, 2021 at 10:39:20AM +0200, Paul Gevers wrote: > Control: block 988830 by -1 > > Hi Josh, Theodore, > > On Tue, 08 Jun 2021 09:14:41 -0700 Josh Triplett > wrote: > > mke2fs with -E offset=N does not seem to take the offset into account > > when ch

Bug#989630: mke2fs with size limit and default discard will discard data after size limit

On Sat, Jun 19, 2021 at 08:44:52PM -0700, Josh Triplett wrote: > On Thu, Jun 17, 2021 at 10:36:48AM +0200, Paul Gevers wrote: > > On Tue, 08 Jun 2021 20:22:39 -0700 Josh Triplett > > wrote: > > > Package: e2fsprogs > > > Version: 1.46.2-2 > > > Severity: important > > > X-Debbugs-Cc: j...@joshtrip

Bug#988830: [pre-approval] unblock e2fsprogs [Was: Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel]

ch don't allow non-aligned pointer dereferences (for example, on a +sparc64 system). + * Fix a missing mutex unlock on an error path which can cause e2fsck +to hang on I/O errors. + * Clean up and improve the man page for e2image + + -- Theodore Y. Ts'o Mon, 07 Jun 2021 07:27:

Bug#987641: Bug#988830: [pre-approval] unblock e2fsprogs [Was: Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel]

On Thu, May 20, 2021 at 05:55:34PM +0200, Cyril Brulebois wrote: > Paul Gevers (2021-05-20): > > On 20-05-2021 00:11, Theodore Y. Ts'o wrote: > > > > Unfortunately, there was no release.debian.org bug to track this. Due > > to the current high volume to our li

Bug#987641: [PING to debian-release] Re: Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel

real bug, and it is fixed upstream already. But do you want me to upload a fix *now*, during the hard freeze, given the impact on the installer, et. al.? Thanks! - Ted On Mon, May 03, 2021 at 06:24:54PM -0400, Theodore Ts'o wrote: > On Mon, May 03,

Bug#987353: CVE-2020-8903 CVE-2020-8907 CVE-2020-8933

On Thu, May 13, 2021 at 09:56:53PM +0100, Marcin Kulisz wrote: > > I hope that we're be able to change it, but for me fundamental > question is if Google is interested in participating in effort to > keep those packages in Debian main and if so what resources can be > committed to do so. From my

Bug#987069: document which file systems support cgroupv2 I/O controller

On Thu, May 13, 2021 at 11:04:14PM -0400, Theodore Ts'o wrote: > I'll give you another example that we learned the hard way. Depending > on how tight you make your memory cgroups and how tight you constrain > your I/O controller, it's possible for write throttling --- whe

Bug#987069: document which file systems support cgroupv2 I/O controller

so has tradeoffs: "A crash+recovery can cause incorrect data to appear in files which were written shortly before the crash." - https://www.kernel.org/doc/html/latest/admin-guide/ext4.html#data-mode > I'm also not sure, because everywhere I've looked appears to docu

Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel

On Mon, May 03, 2021 at 11:00:37PM +0200, Aurelien Jarno wrote: > > Maybe I should give a bit of context here. First of all, there is one armhf > buildd, arm-arm-01, setup as an arm64 machine with a 32-bit armhf chroot. It > has been setup following [1] a study from Steve McIntyre [1]. It appears

Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel

date for Bullseye at this point in time before I prepare an update and file a formal unblock request. Or we can do this after the initial Bullseye release, if that would be more convenient for the release process. What say ye? Many thanks, - Ted commit bc8

Bug#986332: lsattr on certiain files in /dev results in "stack smashing detected"

On Mon, Apr 05, 2021 at 12:46:48AM +0200, Chris Hofstaedtler wrote: > > AFAICT, for /dev/dri/card0 the ioctl ends up in the kernel's > drm_ioctl [2], which will blindly call copy_to_user assuming the > output size is the same as the input size (8 bytes). This is wrong > for FS_IOC_GETFLAGS, at lea

Bug#984472: [PATCH 2/2] resize2fs: close the file system on errors or early exits

When resize2fs exits early, perhaps because of an error, we should free the file system so that if MMP is in use, the MMP block is reset. This also releases the memory to avoid memory leak reports. Addresses-Debian-Bug: #984472 Signed-off-by: Theodore Ts'o --- resize/main.c

Bug#984472: [PATCH 1/2] resize2fs: avoid allocating over the MMP block

e bad. Prevent this from happening by reserving the MMP block as a file system metadata block (which it is) in resize2fs's accounting. Addresses-Debian-Bug: #984472 Signed-off-by: Theodore Ts'o --- resize/resize2fs.c | 5 + 1 file changed, 5 insertions(+) diff --git a/resize/resiz

Bug#984472: e2fsprogs: resize2fs on inconsistent filesystem (in a way that e2fsck doesn't detect) completely corrupts MMP data (in a way e2fsck can't recover from)

On Fri, Mar 05, 2021 at 09:48:50PM -0500, Theodore Ts'o wrote: > I can't reproduce the problem given your file system image. Given > your description, this is almost certainly operator error. OK, I was finally able to reproduce the problem, but not using your reproduction

Bug#984472: e2fsprogs: resize2fs on inconsistent filesystem (in a way that e2fsck doesn't detect) completely corrupts MMP data (in a way e2fsck can't recover from)

I can't reproduce the problem given your file system image. Given your description, this is almost certainly operator error. > $ e2fsck -f /dev/zvol/filling/store/nabijaczleweli/e2test > e2fsck 1.46.2 (28-Feb-2021) > e2fsck: MMP: e2fsck being run while checking MMP block > MMP check failed: If

Bug#926130: e2fsck returns 1 which makes e2scrub fails

tag 926130 +moreinfo thanks On Sat, May 25, 2019 at 06:54:57PM -0400, Theodore Ts'o wrote: > On Tue, May 14, 2019 at 09:42:58AM +0200, Laurent Bigonville wrote: > > > > I've attached the requested logs. I don't see anything weird here. > > Yeah, I'

  1   2   3   4   5   6   7   8   9   >