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
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
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. Th
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.
>
>
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
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*
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
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
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
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.
7f92fa430e Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o
+Date: Mon, 3 May 2021 15:37:33 -0400
+Subject: [PATCH 1/5] e2fsck: fix portability problems caused by unaligned
+ accesses
+
+The on-disk format for the ext4 journal can have unaigned 32-bit
+integers. This can happen when replaying a journal
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
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 bc8e4e56fcdd2a9e65cc87f6303d
On Fri, Feb 03, 2017 at 10:34:09PM +0100, Emilio Pozuelo Monfort wrote:
>
> This seems fine to me, unblocked. Cc'ing debian-boot@/Cyril for the udeb
> unblock.
>
Hi, I've since found a regression that I would like to fix via a
cherry pick from upstream. The e2fsprogs/1.43.4-2 package hasn't
On Tue, Dec 27, 2016 at 07:56:36PM +, Adam D. Barratt wrote:
> Thankfully none of that worked. I say thankfully, because you'd have
> given release.d.o an allegedly RC bug (it may be RC for e2fsprogs, it's
> certainly not so for release.d.o) and removed the original bug from
> where it
500, Theodore Ts'o wrote:
> > I noticed you reopened this and marked this as still being a problem
> > in e2fsprogs/1.42.12-2 (it actually _is_ fixed in e2fsprogs/1.43.3-1).
> > Is it worth trying to fix this in Debian Stable? Especially given
> > that existence of snapsh
On Sat, Nov 19, 2016 at 01:34:56PM +0100, Santiago Vila wrote:
> On Sat, Nov 19, 2016 at 07:14:39AM -0500, Theodore Ts'o wrote:
>
> > Why do you care? It's an extremely minor bug, and it's really not
> > worth the effort to fix things for just a really minor bugfix like
>
On Tue, Jun 07, 2016 at 07:30:33PM +0100, Adam D. Barratt wrote:
>
> It's on my to-do list to review.
>
> fwiw there's not been any need to formally acknowledge NMUs via closing
> bugs in the changelog since the BTS gained version-tracking some years
> ago, so long as the changelog for the
Could I get some direction from the release team what you would
prefer? I can remove the Hurd diff if you like. I guess if you want
me to re-upload, since I uploaded first, would you need to reject the
current upload so it exits the queue and then I can re-upload, with
the preferred version
On Sat, Jun 04, 2016 at 06:28:27PM +0200, Emilio Pozuelo Monfort wrote:
> There's no hurd in jessie, so I think it'd be better to leave that out. But
> IANASRM.
One observation is that the bugfix is not just for e2fsck running on
Hurd (although admittedly that's the most likely situation where
ated for
+Linux. This lead to e2fsck constantly complaining about certain
+nodes:
+
+i_file_acl_hi for inode XXX (/dev/console) is 32, should be zero.
+
+By "correcting" this problem, e2fsck would clobber the field
+osd2.hurd2.h_i_mode_high.
+
+Properly guard access to the OS dependent fi
On Mon, Aug 12, 2013 at 12:48:36AM -0700, Jonathan Nieder wrote:
Odd --- wouldn't building e2fsprogs in a wheezy chroot avoid trouble,
since libc in wheezy doesn't have that bug?
Sorry, my mistake. I thought my Wheezy system had a pristine build
environment, and I didn't realize that I had
On Sat, Aug 10, 2013 at 06:39:33PM +0100, Adam D. Barratt wrote:
On Thu, 2013-06-27 at 14:01 -0400, Theodore Ts'o wrote:
It's a bit more than that. The full patch is here:
https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?h=maintid=3df6014a3d216d19be7d2286de24e8ee106f18ad
On Tue, Jun 25, 2013 at 08:54:50PM +0100, Adam D. Barratt wrote:
On Tue, 2013-06-25 at 16:23 +0200, Peter Palfrader wrote:
On Fri, 21 Jun 2013, Debian Bug Tracking System wrote:
* Work around Debian Bug #712530 (Closes: #708307)
Thanks! Is that work-around suitable for a stable
On Mon, May 27, 2013 at 02:00:12PM +0100, Adam D. Barratt wrote:
However, in this case, that's somewhat complicated by the fact that
libunwind in unstable doesn't actually build libunwind7 any more, which
makes updating it somewhat tricky. If the maintainers do agree that
Peter's solution is
Just to give a bit more color commentary, the reason for this is
because e2fsck is now using the backtrace(3) function, which is part
of libc on x86. It's using backtrace() to provide better
debuggability should there be a bug in e2fsck; see the code in
e2fsck/sigcatcher.c. It's a great way of
On Sat, Mar 23, 2013 at 11:34:31AM +, Dmitrijs Ledkovs wrote:
I'm not sure if the installer team would want to reroll the images or
not, since there is no code changes to the udebs.
But the fix will benefit to be present in the CD's pool to anyone who
upgrades from CDs without internet
On Thu, Mar 21, 2013 at 02:09:44AM +, Dmitrijs Ledkovs wrote:
I was about to file unblock request and ping the installer team coordinators.
Sorry, if this is the wrong way around with respect to an upload to unstable.
Well, normally, I'd ask the Release team first whether they would be
On Thu, Mar 21, 2013 at 01:02:55AM +, Debian FTP Masters wrote:
e2fsprogs (1.42.5-1.1) unstable; urgency=low
.
* Non-maintainer upload.
* e2fsck-static, e2fsprogs: let preinst remove a symbolic link in
/usr/share/doc, that should have been replaced with a directory since
On Thu, Jan 24, 2013 at 08:41:38PM +0100, Guillem Jover wrote:
[ Sven, thanks for the investigation on e2fsck-static! ]
Please see the bug log for further details and logs, it's a split of a
conglomerate bug, but the gist of it (should) be quoted below.
I've still set the severity to
On Tue, Jul 31, 2012 at 10:28:54AM +0200, Niels Thykier wrote:
Also (in answer to your other email), I believe it is fine with
requesting them already now so we are aware of them. :)
Since udeb's have been held, I guess this point is moot in any case. :-)
Just for the record, none of these
Note: I only uploaded e2fsprogs/1.42.5-1 today, so of course there
might be some problems that might be discovered would lead us to not
want to unblock it.
But I figured it was better to file this bug just to give the release
team a heads up. If you'd prefer that I close this bug until
Hi all,
Since the freeze is supposed to be coming any day now, I thought I
would mention that I've just uploaded e2fsprogs 1.42.4-1 to unstable.
This has a number of bug fixes that I would really like to get into the
stable release, including a couple of bugs that could cause e2fsck to
corrupt
Hi there,
I've uploaded to unstable packages for e2fsprogs_1.41.12-3. It is
intentionally a very selective bugfix-only update for
e2fsprogs_1.41.12-2:
* Fix signed vs. unsigned char bug in getopt in e2fsprogs which
afflicts systems with default unsigned char
* Fix bug in e2fsck where it
Yes, there is a 1.40.4-1 which is currently awaiting the ftp-masters'
approval (since there is a new binary package, uuid-runtime, involved),
but in the meantime, 1.40.3-1 has been in testing for 26 days, and there
is a minor security fix (CVE-2007-5497) involved. So I'd very much like
to have
Hi, I just uploaded e2fsprogs 1.39+1.40-WIP-2006.11.14+dfsg-1 to
unstable, and while we still need to wait for the settling time, I
thought I should mention now that I'd like to have this package version
considered for etch. A list of changes in this package version that
justifies why I believe
On Mon, Aug 22, 2005 at 10:30:09AM +0200, Martin Schulze wrote:
Steve Langasek wrote:
On Sun, Aug 21, 2005 at 11:20:49PM -0400, Theodore Ts'o wrote:
I would like to upload the following release to sarge to fix a grave bug
(#318463), and taking the opportunity to fix a few other
I would like to upload the following release to sarge to fix a grave bug
(#318463), and taking the opportunity to fix a few other potential
core-dumping inducing bugs. All of these are cherry picked from the
e2fsprogs development tree.
Should I go ahead and upload the following to
On Tue, May 24, 2005 at 07:01:52PM +0200, Jeroen van Wolffelaar wrote:
Indeed, unfortunately, since then, a new version was uploaded to
unstable without the udeb's yet synced :-(.
Therefore, a no-changes upload to testing is needed for 1.37-2, best
named 1.37-2sarge1. Will you perform this
I'm getting a half-dozen or so of these messages every 24 hours. It
sounds like something is continuously trying to resubmit the
1.35-8sarge1 versions of e2fsprogs into sarge. Could you either
remove them, or tell me who I need to talk to in order to get these
erroneously NMU'ed binary packages
On Mon, May 02, 2005 at 05:04:42AM +0200, Jeroen van Wolffelaar wrote:
Hi,
In order to get debian-installer and normal tools sources in sync for
sarge, which is a requirement, I'm going to upload 1.35-8 as
1.35-8sarge1 into testing. You don't need to do anyting. If this upload
fails for
On Sat, Mar 26, 2005 at 09:39:41AM -0700, LaMont Jones wrote:
On Fri, Mar 25, 2005 at 05:16:14PM -0800, Steve Langasek wrote:
Additional con:
- depends on a newer version of e2fsprogs than we currently have in
testing, which requires updating roughly a half dozen frozen libraries
Hrm,
On Tue, Jan 13, 2004 at 10:53:28AM +0100, Bas Zoetekouw wrote: 1) I
think that the democratical election of codenames is essential and
it should were part of the political of debian. How much
democratic or in what way it's democratic are things that you (the
organization and developers of
43 matches
Mail list logo
