[Piuparts-devel] 01/01: reschedule packages also on testing2sid

Andreas Beckmann anbe at debian.org
Sat Feb 8 14:33:27 UTC 2014


On 2014-02-08 15:04, Holger Levsen wrote:
>> Andreas Beckmann (1):
>>       p-m: log connect/disconnect with timestamp
> 
> thats in for-holger?

yes

>>> if there is no upgrade to test, I think thats fine ;)
>> But I think the logfile is more valueable if it contains the actual
>> upgrade, not a no-op ...
> 
> well, if the logfile is in a failed state and blogs other packages from being 

Failed logs shouldn't write blogs. :-)

*Failed logs get recycled* ... just increase the reschedule-fail-count
to not run into such "deadlocks" regularily, maybe from 25 to 50 and
reduce expire-fail-days from 25 to 15, I have experienced this myself
for sid-bl only that has a huge number of failures.

> tested, there is harmm done. also its not really useful to keep a log (whether 
> buggy or not) if the actual upgrade path tested in it doesnt exist any more.

but passed real-upgrade logs may still contain interesting artefacts
that didn't cause a failure, (I don't have a good example here right now
..) retesting them with a no-op upgrade will destroy them.

Hmm, should we have a --reinstall switch that does apt-get install
--reinstall immediately after installation?

>> Wait, you have 20 logfiles in recycle/ that probably could not be tested
>> due to dependencies, so they need to wait for extra expire-fail-days ...
> 
> delete them?

ignore, since you deletes fail/* they will be reprocessed or cleaned up
automatically

> I like your fancy recycling stuff, but sometimes "force" is easier...

and maybe *thinking...* I got an idea to ensure rescheduling progress
for fail even if the queue is full :-)


Andreas




More information about the Piuparts-devel mailing list