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 <alex@polverini.org> 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
Attachment:
signature.asc
Description: PGP signature