Am Samstag, dem 22.06.2024 um 00:39 +0200 schrieb Benjamin Drung: > > 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. > > tl;dr: Backport with the 64-bit time_t transition changes reverted > > Long answer: In case you backport a package, it will build with the > old > dpkg/debhelper and therefore will not enable 64-bit time_t. So in > case > your backport would include the 64-bit time_t changes, these changes > would be wrong.
Hi, I don't mind any reiserfsprogs backport. But I can't upload it, due to backports-NEW and I'm just a DM. I haven't followed much developing of btrfs-convert but some time ago it would be definitely better to just use mkfs.btrfs instead of convert. Regards Felix
