[Piuparts-devel] Piuparts cannot-be-tested - perl related?

[Andreas Beckmann]

On 2017-01-19 07:46, Adrian Bunk wrote:
> testing migration of sdb is blocked by
>   https://piuparts.debian.org/sid/source/s/sdb.html
> 
> My theory is that this might have been a spurious error due to the amd64 
> perl packages being in unstable before the -all packages were in unstable
> (the apt error message is not really helpful in such cases).
> 
> Can you reschedule sdb?
> 
> Other testing migration blockers that look like the same root cause:
> https://piuparts.debian.org/sid/source/d/dbconfig-common.html
> https://piuparts.debian.org/sid/source/m/mon.html
> https://piuparts.debian.org/sid/source/m/mysql-defaults.html
> https://piuparts.debian.org/sid/source/p/pbuilder.html
> https://piuparts.debian.org/sid/source/libf/libfinance-qif-perl.html

These logs will be rescheduled by piuparts automatically at the age of 3
days, that will happen today at 22:30 unless Hoger does it manually
first. Should we decrease that to 2 days? Especially since we do it only
once per day?

So up to date test results should even now be available at the end of
the regular 5 day window even if the first test failed due to a glitch
(arch:all vs. arch:any mismatch for a single mirror push cycle in sid) ...

A temporary perl uninstallability probably affects many packages, I'd
expect the impact of other packages causing this to be much smaller.

> Does it actually make sense to treat cannot-be-tested as blocker for 
> testing migration? Looking at [1] the valid cases are dependency 
> problems that are anyway blocking testing migration since being
> able to install the package is what britney already checks.

We don't want to let in buggy package B into testing just because it
depends on A and A temporarily failed the piuparts test due to such a
glitch. Its not about B having a dependency problem (these should
primarily be caught by britney as you said), but a real failure.

Andreas