[Piuparts-devel] retesting failed packages more often

Andreas Beckmann debian at abeckmann.de
Sun Nov 20 20:25:14 UTC 2011


On 2011-11-20 16:40, Holger Levsen wrote:
> But I'd rather spend my time improving filing bugs based on piuparts runs, as 
> this is IMO the biggest problem currently: there are too few bugs filed, thus 
> bugs are not fixed.

I tried to look into this yesterday - reporting is not that easy. I
reported 2 or three and usertagged around 8 existing ones ...
Eventually I put too much work into making these reports - rebuilding in
clean current sid, checking the experimental package if any ... just to
make sure the bug is still there and really in that package.

> I'm happy if other people work on other things, the problem here is that I'm 
> currently the only active maintainer of piuparts on piatti.debian.org. That 
> shouldn't block you from developing your ideas on another machine though! 

I currently have a setup based on piatti.git running to put stress
testing on all my patches. It was initialized with the pass logs from
piatti (just taking the directory listing and touching the files with
correct timestamp so that old log recycling works properly) and now
processes the changes in the archive.
So far I'm running sid/main, sid/contrib, sid/non-free,
experimental/main, squeeze/main, squeeze/contrib, squeeze/non-free, but
I'll add wheezy later on, too.

Anyway I noticed that I collected quite a few false positive failures
from the perl transition as packages were transiently uninstallable.

Therefore I'd really recommend to recheck failed packages more
regularily as any transition may cause such problems.

A rm sid/fail/*-perl_*.log should retrigger most of the currently
problematic packages.

To solve the perl failure in sid you'll have to recreate the tarball
(libtext-iconv-perl (prio required) in sid is fixed and drops the
incorrect dependency on perl (prio standard)) and retest perl.

Andreas



More information about the Piuparts-devel mailing list