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

[Dave Steele]

On Tue, Nov 8, 2011 at 12:13 AM, Scott Schaefer
<saschaefer at neurodiverse.org> wrote:
> On 11/07/2011 09:38 PM, Dave Steele wrote:
>>
...
>>
>> # ./piublocker
>> dependency failed -  2047
>> failed testing -  222
>>
>> blocking free cum  rdeps package
>>  458      39  2008   497 sgml-data
>>  439       3  1613   477 docbook-xsl
>>  278     202  1411   706 ca-certificates-java
>>  199     182  1221   205 texlive-base
>>  119     119  1102   163 iceweasel
>>   91      13  1088   121 menu
>>   88      29  1059    93 gnustep-base-common
>>   69       1   990    69 blends-common
>>   59       0   931    60 gnustep-back0.20
>>   58      10   896    85 antlr
>>   55      36   857   714 libhttp-date-perl
>>   55       5   825   124 libcommons-httpclient-java
>>   47      13   802   118 libcommons-beanutils-java
>>   45      23   778   117 openssh-client
>>   36      15   749    36 gforge-common
>>   35      34   714    35 gosa
>>   33      33   681    33 liquidsoap
>>   30       3   678    30 libspring-core-java
>>   28       1   656    28 libatinject-jsr330-api-java
>>   26      26   630    27 drupal6
>> ...
>
> Really quick hack shows that the majority of these have not yet been
> re-tested since tar.gz file was recreated (31 Oct ???) ...  I'm looking
> forward to next week's figures.
>
> ==> antlr_2.7.7+dfsg-1.log <==
> Start: 2011-09-30 08:03:58 UTC
...


Here's the latest on the dependency-failed testing queue. No
significant changes overall.

I get no errors from texlive-base and libhttp-date-perl. Would they
pass if retried?

ca-certificates-java shows, for my test, the leftover files
.system.lock and .systemRootModFile. These files are maintained by
openjdk-6-jre-headless. The two packages are dependent on each other.
openjdk-6-jre-headless is currently in dependency-failed-testing,
because of the ca-certificates-java failure. Shouldn't they both be in
circular-dependency?

The 4 patches and 2 retest requests below should clear about 700
packages from the dependency-failed-testing queue.
ca-certificates-java represents another couple hundred.

One of the packages is orphaned. Any takers on the patch?

# ./piublocker
dependency failed -  2001
failed testing -  214

blocking free cum  rdeps package
 443      25  1976   497 sgml-data

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647473
                           sgml-data is orphaned
 438       3  1581   477 docbook-xsl

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647575
 307     215  1344   718 ca-certificates-java
                           up from 155 on 10/22 - 3 weeks
                           circular dependency with openjdk-6-jre-headless
 196     179  1157   205 texlive-base
                           log fails on postinstall 'tcfmgr.map not found'
                           file is self-owned
                           passes for me - rerun?
 119     118  1039   163 iceweasel

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648541
  90      12  1026   121 menu

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648268
  88      29   997    93 gnustep-base-common
  69       1   928    69 blends-common
  64      45   880   714 libhttp-date-perl
                           log fails on libc-bin upgrade
                           passes for me - rerun?
  59       0   821    60 gnustep-back0.20
  54       5   790   124 libcommons-httpclient-java
  47      14   767   118 libcommons-beanutils-java
  36      27   738    36 gforge-common
  35      34   703    35 gosa
  33      33   670    33 liquidsoap
  30       3   667    30 libspring-core-java
  28       1   645    28 libatinject-jsr330-api-java
  26      26   619    27 drupal6
  24      24   595    24 cyrus-common
  21      17   576    41 libgcj-bc
...


Nearly all of the block'ees of sgml-data and docbook-xsl took a day
trip to circular-dependency on Tuesday, and another to
waiting-for-dependency-to-be-tested on Friday, but they are back now.

Newly failed packages accumulate blocked packages at the rate of about
10-20% of their reverse-dependency count per month
(ca-certificates-java is pushing 30%). It looks like the long-term
strategy for managing dependency-failed-testing is to monitor the
reverse dependency count in failed-testing. That would make it
possible to catch the (future) large offenders before they transition
to wheezy.