Bug#848063: fixed in ri-li 2.0.1+ds-4
I have now built the package 99 more times and this has been the result: Tried 100 times. Failed 97 times. Approximate failure rate: 97%. I've put the 100 build logs here for you to see: https://people.debian.org/~sanvila/ri-li/ The builds were made on different autobuilders. The Release Managers are considering a threshold for FTBFS which happen randomly. Where would you put the threshold in your opinion? Do we need a failure rate of 98% to be RC, so that this package is still under the threshold? IMO, any such threshold over 10% would be too high. Thanks.
Bug#848063: fixed in ri-li 2.0.1+ds-4
On Sat, Dec 24, 2016 at 03:05:54PM +0100, Markus Koschany wrote: > Thanks for working on the reproducible build project. Please note that I'm not filing this bug in the name of the reproducible builds project. The build log I attached was created with sbuild in my own autobuilder. Autobuilders in the reproducible builds project use pbuilder. > However this is > not a release critical issue because the last version builds fine on all > release architectures. [1] Sorry, but the theory that a bug is "not RC if it didn't happen in buildd.debian.org" may simply not be true. We have already discussed about this in the past. As an example, packages which rely on gnupg or tzdata being present during the build must declare them in the build-depends. Failure to do so is RC even if those packages are installed by default in the official buildds. So please stop saying that a bug needs to happen in buildd.debian.org to be RC. This example clearly invalidates such theory. In this case, the failure happens in the reproducible builds autobuilders: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ri-li.html but also (randomly) in my own autobuilders, which are completely independent. > It would be useful to know in which way the reproducible builds > environments differs from the official buildd servers. Apparently the > build cannot open a display server but xvfb-run should ensure that they > are automatically found and used. So this is probably a regression in > xvfb-run or some kind of race condition because nothing has changed in > ri-li for a long time. Yes, it would be indeed useful to know how my building environment differs from yours. I was asked about this in another bug report so I wrote this: https://people.debian.org/~sanvila/my-building-environment.txt Please try to use sbuild in a single-CPU virtual machine as I do. Maybe then this package will FTBFS (randomly) for you as well. Thanks.
Bug#848063: fixed in ri-li 2.0.1+ds-4
Control: severity -1 important On 24.12.2016 11:50, Santiago Vila wrote: > found 848063 2.0.1+ds-4 > thanks > > Hello. Sorry for the reopening but this issue is still happening in > this version. > > (Also, sorry for not noticing it before, I usually build packages in > testing because there are too many broken packages in unstable). > > This time I only built it once, and it failed. Build log attached. Thanks for working on the reproducible build project. However this is not a release critical issue because the last version builds fine on all release architectures. [1] It would be useful to know in which way the reproducible builds environments differs from the official buildd servers. Apparently the build cannot open a display server but xvfb-run should ensure that they are automatically found and used. So this is probably a regression in xvfb-run or some kind of race condition because nothing has changed in ri-li for a long time. [1] https://buildd.debian.org/status/package.php?p=ri-li=unstable signature.asc Description: OpenPGP digital signature
Bug#848063: fixed in ri-li 2.0.1+ds-4
found 848063 2.0.1+ds-4 thanks Hello. Sorry for the reopening but this issue is still happening in this version. (Also, sorry for not noticing it before, I usually build packages in testing because there are too many broken packages in unstable). This time I only built it once, and it failed. Build log attached. Thanks. ri-li_2.0.1+ds-4_amd64-20161224T061519Z.gz Description: application/gzip
