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

[Holger Levsen]

Hi,

On Samstag, 5. November 2011, Dave Steele wrote:
> > dropping the cc: to debian-qa at ...
> Sorry about that.

no problem... :) (Are you subscribed or do you need/want cc:s?)
 
> OK, so errors of that type clear after a maximum of about 6 months.
> I'm wondering about how many of these retries pass, and from that,
> what an optimum retry interval would be, but I can let that lie.

/me nods. I don't think these are many, usually package move from fail to pass 
because a new version was uploaded, fixing things. I does happen that bugs in 
depends are fixed (libgtk2.0) but then this is often pointed out to me and I 
reschedule those packages manually. 

The rescheduling is also there to find packages that _become_ buggy, btw :)
 
> >> Similarly, the latest release of my
> >> package (gnome-gmail 1.8.2-1) is failing piuparts upgrade in wheezy,
> >> because of an install bug in the previous release (1.8.1-1).
> > 
> > whats the # of that bug?
> 
> LP #878494 -
> https://bugs.launchpad.net/ubuntu/+source/gnome-gmail/+bug/878494
> 
> The failure was from a local test. I won't know if the server will
> fail it till it hits in 7 days. I only bring it up as a possible
> example of a situation where a good package can stay in a failed
> state.
> 
> > is it worth fixing in stable?
> 
> Luckily (I guess), it didn't make it to stable.

so the failure in upgrading to wheezy is "not relevant" for the scenario 
piuparts.debian.org is running for foremost: Debian stable and it's upgrades.

I mean it's great if other types of bugs are detected, but there are just so 
many we can deal with, thats why I see piuparts.d.o with the above focus.
 
> > if packages depend on buggy packages, those packages _should be_ in the
> > waiting queue. buggy packages must be fixed, thats the only way forward.
> 
> OK, but the examples were about possible cases where good packages
> block others. I wouldn't have had a failure in wheezy if I had seen it
> fail in sid (local testing was not working right back then).
> 
> The real answer, I guess, is to concentrate on the lib-gtk's and
> readlines of the world. 

Yes, the real answer is to fix bugs :-) (And not to work around these bugs so 
that packages who depend on those buggy packages can be tested anyway.)

> Some status:

> dependency failed -  2199
> failed testing -  253
> 
> blocking free cum  package
>  453      39  2160 sgml-data     -
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647473
>  434       3  1770 docbook-xsl     -
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647575

thanks for filing these bugs! and even more thanks for also sending patches! 
:-)


cheers,
	Holger