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

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