[Reproducible-builds] Blacklist packages for armhf

[Holger Levsen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20160419/3462b002/attachment.sig>