Benjamin Drung <bdrung@debian.org> writes: > On Fri, 2024-06-21 at 16:14 -0400, Nicholas D Steeves wrote: >> >> 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. Belated thank your reply! Ah, so it seems no-change uploads will often not be possible this cycle, and the checklist would be: 1. Revert 64-bit time_t transition changes 2. Downgrade dpkg-dev requirement (related to #1) The Debhelper bpo reverts movetousr, but it really required to use bookworm's dh? Not having (>= 13.11.5~) will reintroduce up to three bugs to affected packages, and as the next year progresses the delta will grow. Thus 3. Downgrade debhelper requirement? Is this documented anywhere yet? Best, Nicholas
Attachment:
signature.asc
Description: PGP signature