[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