64-bit time_t transition question, and Re: Backport request for btrfs-progs

Nicholas D Steeves <[email protected]> Fri, 21 Jun 2024 16:14:02 -0400

Newsgroups	gmane.linux.debian.backports.general
Message-ID	<[email protected]>

Hi,

Apologies for CCing everyone involved, but I haven't been able to find
anything about how the 64-bit time_t transition affects backports.

Alessandro Polverini <[email protected]> writes:

> Hello,
> we have a backported kernel 6.8 (btw, thanks!), but we miss a 
> corresponding btrfs-progs, is it possible to have a backport?
> Right now there is only v. 6.0.x
>
> Thanks in any case!
> Alex

Thank you for the request, and yes, I'd be happy to resume backporting
btrfs-progs.  Please note, however, that Debian sid/unstable has not yet
had newer than 6.6.3 imported, so if you'd like 6.8 than you'll need to
'reportbug btrfs-progs' and request an up-to-date release for
sid/unstable.  I would backport 6.6.3 while waiting for this.

One thing I'm not sure about is how the 64-bit time_t transition affects
backports: A no-change backport of btrfs-progs would normally require a
no-change backport of reiserfsprogs, but I feel like reiserfsprogs'
64-bit time_t transition could break things for bookworm users.  The
three options appear to be:

  1. No-change backports everywhere (and risk breakage).
  2. Disable support for reiserfs in btrfs-convert (my preference).
  3. Backport reiserfsprogs without the 64-bit time_t transition.

I don't yet trust or recommend the use of btrfs-convert, but "ReiserFS
has been deprecated upstream and scheduled for removal 2025"
(reiserfsprogs/debian/changelog), so I can understand why people might
want support for this to migrate in-place now...  That said, backup and
restore to a filesystem created with mkfs (rather than btrfs-convert) is
the safest route, and I'd prefer if users used trixie to experiment with
in-place conversion.

Looking forward to hearing everyone's position,
Nicholas

signature.asc (application/pgp-signature, 857 B)