[Piuparts-devel] Piuparts state-dependency-failed-testing analysis

[Scott Schaefer]

On 10/31/2011 03:20 PM, Holger Levsen wrote:
> Hi Scott, Dave,
>
> first of all, Dave, thanks for your bug report and also the state-dependency-
> failed-testing analysis - I will reply to that hopefully soon. Just one short
> remark: I wrote such a script too, just haven't had time to polish it and
> include in the website results :)
>
> Anyway...
>
> On Sonntag, 30. Oktober 2011, Scott Schaefer wrote:
>    
>> Wow.   ** IF ** I am analyzing this correctly, there is really nothing
>> wrong with dependencies of libreadline6; this is in fact a "bug" in
>> piuparts (or more appropriately, a "bug" in the operational policies of
>> how piuparts is run) ...
>>      
> yeah. though it's rather hard to determine automatically, when a base.tgz
> needs updating...
>
> And so far, I have refrained from doing this often, as often the recreation
> failed (just because sid was broken that day...) and piuparts was without a
> usable base.tgz.
>
> Now there is code to savely recreate the base.tgz and I have changed the
> configuration to recreate the base.tgz's every seven days... and noticed:
>
> the code to trigger recreation is buggy, the base.tgz's are 5 months old..!!!
>
> For now I've deleted them manually, thus forcing recreation.
>
> I've also deleted 163 failed logs (containing the string "libtinfo5") in sid,
> thus forcing re-tests of them.
>
>    

Um .... I wrote that code :-(

I get the piatti logs on a daily  basis, but only those run from cron 
and output from piuparts-report.

Since the code was working here, and seemingly works when you delete the 
file manually, I think whomever attempts to troubleshoot this will need 
access to the piuparts-slave log.  I volunteer to do it; I just need 
access to the log(s); either past or future in addition to current.  If 
you want to have a quick look before trying to send or otherwise make 
available, the key will be log entries of either:

"too old.  Renaming to force re-creation"

and/or

"Failed to create ... reverting to old"

On "normally-operating" system, you should see the first every 'n' 
seconds (7 days per above).  The second would indicate that the 
re-create failed, after which you should see the first on a far more 
frequent basis.  Seems that one of following is true:

1) not ever attempting to recreate; i.e. no first message
2) "continually" failing; i.e. LOTS of second message
3) bad config, or program error causing it not to retry after initial 
failure

>> 3) piuparts did not execute dpkg --remove/--purge libreadline6 because
>> it was already installed in the original chroot.tar.gz image file [per
>> original dpkg --get-selections].  However, the version in the
>> chroot.tar.gz was 6.2.2, which had no Depends ->  libtinfo5.  Thus,
>> libtinfo5 was not in the chroot.tar.gz image -- it was thus installed,
>> and an attempt was made to remove/purge it as part of testing of the
>> libreadline6 package.
>>      
> Thats correct.
>
>    
>> In summary, this is really a consequence of the operational tradeoff of
>> the frequency of regenerating the chroot.tar.gz image.   I think
>> piuparts.d.o has this set to 30 days; perhaps this should be changed to
>> 7 or even 3-4 ??
>>      
> Yeah, maybe less than seven.
>
>
> cheers,
> 	Holger
>