hi, first: i've temporarily disabled testing usrmerge variation last night as this broke our builds, because the .buildinfo files vary (usrmerge installed or not), causing basically all builds to fail.
second: this has been happening since a few weeks, I still don't
get why this suddenly stopped working as we have varied usrmerge
since 2020.
third: the code which was in use (since then) was varying usrmerge
everywhere except buster & bullseye!
that said...
On Thu, Jun 15, 2023 at 09:55:38AM -0700, Vagrant Cascadian wrote:
> On 2023-06-15, Chris Lamb wrote:
> > Thanks for taking this to the list. For 100% clarity, I understand
> > Holger's "at all" suffix to mean, "shall we disable the usrmerge
> > variation for bookworm as well as trixie?"
yes.
> > Assuming that's the correct interpretation, from the perspective of
> > someone patching packages to make them reproducible, it no longer
> > makes sense to prepare patches that address any usrmerge issues. At
> > the very least, they will not be prioritised by package maintainers.
yes
> I still see usrmerge as a real-world (even if technically unsupported in
> Debian) variation that detects real bugs... though I think even for the
> bookworm release cycle, maintainers were hesitant to apply usrmerge
> related patches.
>
> Most of the usrmerge bugs I encounter often feel a bit like busywork,
> but they are also usually fairly trivial to fix.
yes
> Off the top of my head, I do not know how many, but definitely some of
> the usrmerge related bugs I have found will successfully build in a
> usrmerge environment, but in a way that quietly breaks the package
> (e.g. junk in manpages or other documentation, entirely missing
> documentation, embedding an entirely sensical path, etc.). It would be
> hard to systematically find these bugs without testing builds in
> usrmerge and non-usrmerge environments. And I am not sure any other
> project makes any more sense to do that sort of testing.
as said originally: we are the reproducible builds project, not the
Debian QA project trying to find as many issues as we can.
I'd rather have us focus on real reproducibility issues, than issues
with a variation we, Debian, don't care about.
> > I'm less clear about whether we should cease testing bookworm. It
> > doesn't seem right for the CI to claim that various [bookworm]
> > packages are "reproducible in bookworm", when the presence of usrmerge
> > (or lack thereof) in bookworm means that they can still vary.
bookworm wasn't build with usrmerge variation, but rather usrmerge
was explicitly disabled on the builds.
so one can also say that it doesnt seem right to introduce a variation
which never occured.
> I find it a bit weird to change the variations after the release, as
> then the stats will gradually change as packages get retested, without
> any actual work done to change them... feels a bit too much like moving
> the goalposts retroactively.
iirc the amount of affected packages is something like 50, so hardly 0.1%,
so hardly noticable.
also we are not testing against what was released anyway, but rather
doing CI tests with arbitrary variations. bookworm also wasnt built in 2024,
yet we are testing exactlty this right now. ;)
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
Religion has been more harmful to humanity than cigarettes.
signature.asc
Description: PGP signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
