Re: [Reproducible-builds] Blacklist packages for armhf
Hi Vagrant, On Sun, Apr 17, 2016 at 01:05:23PM -0700, Vagrant Cascadian wrote: > Doing some sql queires and a bit of eyeball heuristics, I've determined > the packages listed below frequently FTBFS due to timeout on armhf. cool, thanks! though… ;-) [...] … I've taken this and changed the timeouts for maintenance scripts so that I could change the 1st builders timeout to 18h and the 2nd builders to 24h timeout. So I guess it's rather time to unblacklist some packages, definitly on armhf but probably even on amd64/i386? Could you maybe come up with such a list? Probably just "all which are not blacklisted on amd64"… :) > My rough process went like so: It's great to have this documented now, even if only on the list. But I guess thats good enough for now… > I excluded packages from the submitted that had a recent completed build > (reproducible or unreproducible), or where the FTBFS usually didn't take > more than 12 hours. It maybe wasn't a perfect process, but hopefully > will allow for better coverage of most of the rest of the archive. seems reasonable, yes. > It would be really helpful if we could mark failures due to timeouts > separately from "normal" FTBFS thanks for this suggestion, noted. > and then packages could be rescheduled > differently (e.g. an incremental delay for rescheduling, or not at > all). Alternately or additionally, if the FTBFS rescheduling could > adjust the frequency based on number of times a package has (recently) > FTBFS, that might help too. I'm not convinced the scheduled should be much more complicated than it already is. KISS is good. (btw, I think depwaits should be scheduled more often…) > I think Holger at one point mentioned increasing the timeouts higher > (currently 12h for 1st build, and 18h for 2nd build?), although > with all the suites tested, some builds are over 45 days old, so I'm not > sure if that would be ideal. as said, this has been implemented now. The build network can definitly catch up easily with new uploads *and* we will get more arm hw this year, so… :) -- cheers, Holger signature.asc Description: Digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Blacklist packages for armhf
Doing some sql queires and a bit of eyeball heuristics, I've determined the packages listed below frequently FTBFS due to timeout on armhf. I was hoping we could drop blacklisting altogether as the build network grew, but I'm not sure that's realistic with the current infrastructure. Please blacklist the following packages in all suites for armhf (some may already be blacklisted on particular suites, but I think it makes sense to just blacklist them on all suites): agda aptdaemon ceph chromium-browser debci doc-linux-fr eclipse firefox firefox-esr freedict gazebo gcc-5 gcc-6 gcc-mingw-w64 ghc gnat-mingw-w64 gnucash-docs gnuchess-book gradle iceweasel kicad libapache-poi-java libint2 libitext5-java lilypond llvm-toolchain-3.8 lucene2 lucene-solr madness mlton mongodb nwchem openjdk-6 openjdk-7 openjdk-9 openms openturns pcl python-2.7 tomcat8 ufoai-maps witty My rough process went like so: Get the names of packages: sqlite3 reproducible.db \ 'select name from stats_build where architecture is "armhf" and status is "FTBFS" and cast(build_duration as integer) >=43200 and cast(build_duration as integer) <= 45000 and build_date >= "2016-03-01 00:00"' Which I then visually compared against: printf 'select * from stats_build where architecture is "armhf" and name is "%s" and build_date >= "2016-01-01 00:00";' $name | sqlite3 reproducible.db I excluded packages from the submitted that had a recent completed build (reproducible or unreproducible), or where the FTBFS usually didn't take more than 12 hours. It maybe wasn't a perfect process, but hopefully will allow for better coverage of most of the rest of the archive. Might have been wise for me to figure out how to do more of that programatically (my SQL isn't too solid)... It would be really helpful if we could mark failures due to timeouts separately from "normal" FTBFS, and then packages could be rescheduled differently (e.g. an incremental delay for rescheduling, or not at all). Alternately or additionally, if the FTBFS rescheduling could adjust the frequency based on number of times a package has (recently) FTBFS, that might help too. I think Holger at one point mentioned increasing the timeouts higher (currently 12h for 1st build, and 18h for 2nd build?), although with all the suites tested, some builds are over 45 days old, so I'm not sure if that would be ideal. live well, vagrant signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
