Bug#1106897: unblock: btrfs-compsize/1.5-1.1
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: btrfs-compsize@packages.debian.org, sten@debian.org
Control: affects -1 + src:btrfs-compsize
Please unblock package btrfs-compsize
[ Reason ]
The maintainer of this package seems to have abandoned it both
upstream and in Debian, and I only learned that this had occurred on
the 16 May. The package had already fallen out of testing due to the
ftbfs documented at #1091561, so I made an NMU without delay and
immediately uploaded it. I hope that the release team will recognise
that the disappearance of a maintainer is an extenuating circumstance.
[ Impact ]
If this unblock isn't granted then btrfs-compsize won't be part of
trixie, and Debian will be the only major distribution that doesn't
have a tool that is essential for btrfs adopters who use inline
compression. I had never used the tool before but assumed it would be
in the archive--just as one assumes standard optional utilities like
netcat will be.
[ Tests ]
I used my NMU deb to test if the inline compression-related mount
options that I was adding to a proof-of-concept MR for
debian-installer were working correctly, and I confirmed that
btrfs-compsize works correctly and performs its function flawlessly.
[ Risks ]
Extremely low, because the patch to fix the ftbfs has already been
tested for several months by multiple other distributions. It is the
correct solution until kilobyte resumes upstream maintenance, or until
someone forks the project.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the last non-NMU of the package
<#part type="application/octet-stream" filename="/scratch/1.5-1_to_1.5-1.1_bin.debdiff" disposition=attachment>
<#/part>
<#part type="application/octet-stream" filename="/scratch/1.5-1_to_1.5-1.1_dsc.debdiff" disposition=attachment>
<#/part>
I spent well over an hour trying to regenerate kilobyte's
"single-debian-patch"-style header using every method I could think of
or find documentation for; after that, my hypothesis became that it
may be normal for a "single-debian-patch" to have useless headers when
it represents multiple commits on a patches-applied dgit repo. I
would prefer to fix the patch handling to output DEP3-compliant quilt
patches, but that's prohibited in a minimal NMU.
Thank you for your consideration,
Best,
Nicholas
unblock btrfs-compsize/1.5-1.1
Reply to: