[Reproducible-builds] Blacklist packages for armhf

[Vagrant Cascadian]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20160417/8746c44d/attachment.sig>