On Thu, Jun 27, 2024 at 11:30:20AM -0400, Nicholas D Steeves wrote: > 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? I didn't had the chance to announce that yet or link it to the official website, but Helmut kindfully documented the glorious details about time_t64 and backports. I did not review the document yet, but Helmut has a lot of more knowledge than me about that topic. Therefore consider as kind of policy. https://wiki.debian.org/BuildingFormalBackports#bookworm-backports Alexander
Attachment:
signature.asc
Description: PGP signature