On 03.11.19 16:24, Holger Levsen wrote:
On Sun, Nov 03, 2019 at 03:14:38PM +0100, Matthias Klose wrote:
As part of general QA we did some test rebuilds during the last release
cycle, and filing the ftbfs reports as RC issues. Afaics there were no such
test rebuilds and RC filing for bullseye after the release of buster.
FWIW (and I mean that very literally), reproducible.debian.net does
continous rebuilds of experimental, sid and bullseye. And some people
even file bugs based on this.
(Contrary to some people's outdated beliefs) there are also no modified
packages involved. (We just test with usrmerge installed in one build
and not the other. And with the other (legit) variations described in
https://tests.reproducible-builds.org/debian/index_variations.html )
it would be nice to make this information more exposed, especially because you
are covering four architectures, and not just one which is usually rebuilt for a
test rebuild in Debian.
Now looking at
https://tracker.debian.org/pkg/linbox
https://tracker.debian.org/pkg/python-xarray
I have difficulties finding a build log showing the build failure. The link to
the tracker leads to a page with (for me) non-obvious information. For the
purpose of tracking build failures I'd like to see a direct link to a build log
of a failing build on tracker.debian.org, however even looking at
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/linbox.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-xarray.html
I have difficulties finding the log of the failed build. Also please note that
the linbox ftbfs is non-amd64, so the tracker link is misleading.
It would also be nice to generate a list of
<source> <version> <arch> <buildog>
for builds that ftbfs and don't have any RC issues yet in the BTS, so that could
be used for QA people to file not-yet-filed ftbfs issues.
For comparative test rebuilds, would it be possible to add another configuration
(you already have experimental, sid, ...) to use a new GCC version? I assume
the LLVM maintainers also would be interested to test the LLVM toolchain the
same way.
Matthias