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
Description: PGP signature
_______________________________________________ Reproducible-builds mailing list Reproducibleemail@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds