Why is package X not in testing yet?

Checking libxine1

binary package libxine1 is part of source package xine-lib
- xine-lib has the same version in unstable and testing (1.1.21-1)

Dependency analysis (including build-depends; i386 only):

xine-lib depends on libcam-dev which is not available in testing
- binary package libcam-dev is part of source package freebsd-libs
  - freebsd-libs has the same version in unstable and testing (9.0+ds1-4)
- freebsd-libs depends on freebsd-buildutils >= 9.0-3~ but testing has 9.0-11 (unstable has 9.0-11)
  - freebsd-buildutils has the same version in unstable and testing (9.0-11)
  - info: freebsd-buildutils has a version in experimental (10~svn251967-1)
- freebsd-libs depends on libc0.1-dev >= 2.13-31, which is not available in testing
  - binary package libc0.1-dev is part of source package eglibc
    - trying to update eglibc from 2.17-5 to 2.17-6 (candidate is 1 days old)
    - eglibc is only 1 days old. It must be 10 days old to go in.
    - eglibc is not yet built on amd64: 2.17-5 vs 2.17-6 (missing 20 binaries)
    - eglibc is not yet built on armel: 2.17-5 vs 2.17-6 (missing 16 binaries)
    - eglibc is not yet built on ia64: 2.17-5 vs 2.17-6 (missing 16 binaries)
    - info: eglibc has a version in experimental (2.17-5)
  - eglibc depends on hurd-dev >= 20120520-2~, which is not available in testing
    - binary package hurd-dev is part of source package hurd
      - hurd has no old version in testing (trying to add, not update)
      - hurd is only 0 days old. It must be 10 days old to go in.
    - hurd depends on libc0.3-dev >= 2.13-38~, which is not available in testing
      - binary package libc0.3-dev is part of source package eglibc
        
        trying to update eglibc from 2.17-5 to 2.17-6 (candidate is 1 days old)
        eglibc is only 1 days old. It must be 10 days old to go in.
        eglibc is not yet built on amd64: 2.17-5 vs 2.17-6 (missing 20 binaries)
        eglibc is not yet built on armel: 2.17-5 vs 2.17-6 (missing 16 binaries)
        eglibc is not yet built on ia64: 2.17-5 vs 2.17-6 (missing 16 binaries)
        info: eglibc has a version in experimental (2.17-5)
  - eglibc depends on linux-libc-dev >= 3.4 but testing has 3.2.46-1 (unstable has 3.9.6-1)
    - binary package linux-libc-dev is part of source package linux
      - trying to update linux from 3.2.46-1 to 3.9.6-1 (candidate is 4 days old)
      - linux is not yet built on kfreebsd-amd64: 3.8.13-1 vs 3.9.6-1 (missing 4 binaries: linux-doc-3.8, linux-manual-3.8, linux-source-3.8, linux-support-3.8-2)
      - linux no longer provides binary linux-support-3.8-2. ftpmaster needs to remove it.
      - linux is not yet built on kfreebsd-i386: 3.8.13-1 vs 3.9.6-1 (missing 4 binaries: linux-doc-3.8, linux-manual-3.8, linux-source-3.8, linux-support-3.8-2)
      - linux is waiting for linux-tools
        
        Updating linux-tools makes 4 depending packages uninstallable on i386: linux-headers-3.2.0-4-all, linux-headers-486, linux-headers-686-pae, linux-headers-amd64
        Updating linux-tools makes 24 non-depending packages uninstallable on i386: blcr-dkms, blktap-dkms, blktap-utils, linux-headers-2.6-486, linux-headers-2.6-686-pae, linux-headers-2.6-amd64, linux-headers-3.2.0-4-486, linux-headers-3.2.0-4-686-pae, linux-headers-3.2.0-4-all-i386, linux-headers-3.2.0-4-amd64, linux-headers-3.2.0-4-rt-686-pae, linux-headers-rt-686-pae, linux-tools, linux-tools-2.6, nova-xcp-network, nova-xcp-plugins, oss4-dkms, sl-modem-dkms, sl-modem-source, west-chamber-dkms, xcp-guest-templates, xcp-storage-managers, xcp-xapi, xcp-xapi-debug
      - info: linux has a version in experimental (3.10~rc5-1~exp1)
    - linux depends on binutils-hppa64 which is not available in testing
      - binary package binutils-hppa64 is part of source package binutils
        
        trying to update binutils from 2.22-8 to 2.23.52.20130612-1 (candidate is 7 days old)
        binutils is only 7 days old. It must be 10 days old to go in.
    - linux depends on gcc-4.4-hppa64 which is not available in testing
      - binary package gcc-4.4-hppa64 is part of source package gcc-4.4
        
        trying to update gcc-4.4 from 4.4.7-3 to 4.4.7-4 (candidate is 41 days old)
        gcc-4.4 is not yet built on mipsel: 4.4.7-3 vs 4.4.7-4 (missing 18 binaries)
      - gcc-4.4 depends on binutils-hppa64 >= 2.20.1-15~, which is not available in testing
        binary package binutils-hppa64 is part of source package binutils
        
        trying to update binutils from 2.22-8 to 2.23.52.20130612-1 (candidate is 7 days old)
        binutils is only 7 days old. It must be 10 days old to go in.
      - gcc-4.4 depends on binutils-spu >= 2.20.1-15~, which is not available in testing
        binary package binutils-spu is part of source package binutils (explained above)
      - gcc-4.4 depends on lib32gcc1 which is not available in testing
        binary package lib32gcc1 is part of source package gcc-4.8
        
        trying to update gcc-4.8 from 4.8.1-2 to 4.8.1-3 (candidate is 7 days old)
        gcc-4.8 is only 7 days old. It must be 10 days old to go in.
        gcc-4.8 is not yet built on s390: 4.8.1-2 vs 4.8.1-3 (missing 1 binary: gdc-4.8)
        gcc-4.8 no longer provides binary gdc-4.8. ftpmaster needs to remove it.
        gcc-4.8 is waiting for binutils
        binutils is explained above
        
        All 2 alternatives failed: binutils (>= 2.23.52) | binutils-multiarch (>= 2.23.52)
        alternative 1/2: gcc-4.8 depends on binutils >= 2.23.52 but testing has 2.22-8 (unstable has 2.23.52.20130612-1)
        
        trying to update binutils from 2.22-8 to 2.23.52.20130612-1 (candidate is 7 days old)
        binutils is only 7 days old. It must be 10 days old to go in.
        
        alternative 2/2: gcc-4.8 depends on binutils-multiarch >= 2.23.52 but testing has 2.22-8 (unstable has 2.23.52.20130612-1)
        binary package binutils-multiarch is part of source package binutils
        
        trying to update binutils from 2.22-8 to 2.23.52.20130612-1 (candidate is 7 days old)
        binutils is only 7 days old. It must be 10 days old to go in.
        
        gcc-4.8 depends on binutils >= 2.23.52.20130612 but testing has 2.22-8 (unstable has 2.23.52.20130612-1)
        binutils is explained above
        
        gcc-4.8 depends on binutils-hppa64 >= 2.22, which is not available in testing
        binary package binutils-hppa64 is part of source package binutils (explained above)
        
        gcc-4.8 depends on binutils-hppa64 >= 2.23.52, which is not available in testing
        binary package binutils-hppa64 is part of source package binutils (explained above)
        
        gcc-4.8 depends on kfreebsd-kernel-headers >= 0.84 but testing has 0.83 (unstable has 0.84)
        
        trying to update kfreebsd-kernel-headers from 0.83 to 0.84 (candidate is 8 days old)
        kfreebsd-kernel-headers is only 8 days old. It must be 10 days old to go in.
        info: kfreebsd-kernel-headers has a version in experimental (9.0-1)
        
        gcc-4.8 depends on libc0.1-dev-i386 which is not available in testing
        binary package libc0.1-dev-i386 is part of source package eglibc
        
        trying to update eglibc from 2.17-5 to 2.17-6 (candidate is 1 days old)
        eglibc is only 1 days old. It must be 10 days old to go in.
        eglibc is not yet built on amd64: 2.17-5 vs 2.17-6 (missing 20 binaries)
        eglibc is not yet built on armel: 2.17-5 vs 2.17-6 (missing 16 binaries)
        eglibc is not yet built on ia64: 2.17-5 vs 2.17-6 (missing 16 binaries)
        info: eglibc has a version in experimental (2.17-5)
        
        gcc-4.8 depends on libc6-dev-i386 which is not available in testing
        binary package libc6-dev-i386 is part of source package eglibc (explained above)
        
        gcc-4.8 depends on libc6-dev-mips64 which is not available in testing
        binary package libc6-dev-mips64 is part of source package eglibc (explained above)
        
        gcc-4.8 depends on libc6-dev-mipsn32 which is not available in testing
        binary package libc6-dev-mipsn32 is part of source package eglibc (explained above)
        
        gcc-4.8 depends on libc6-dev-powerpc which is not available in testing
        binary package libc6-dev-powerpc is part of source package eglibc (explained above)
        
        gcc-4.8 depends on libc6-dev-ppc64 which is not available in testing
        binary package libc6-dev-ppc64 is part of source package eglibc (explained above)
        
        gcc-4.8 depends on libc6-dev-s390 which is not available in testing
        binary package libc6-dev-s390 is part of source package eglibc (explained above)
        
        gcc-4.8 depends on libc6-dev-s390x which is not available in testing
        binary package libc6-dev-s390x is part of source package eglibc (explained above)
        
        gcc-4.8 depends on libc6-dev-sparc64 which is not available in testing
        binary package libc6-dev-sparc64 is part of source package eglibc (explained above)
      - gcc-4.4 depends on libc0.1-dev-i386 which is not available in testing
        binary package libc0.1-dev-i386 is part of source package eglibc (explained above)
      - gcc-4.4 depends on libc6-dev-i386 which is not available in testing
        binary package libc6-dev-i386 is part of source package eglibc (explained above)
      - gcc-4.4 depends on libc6-dev-mips64 which is not available in testing
        binary package libc6-dev-mips64 is part of source package eglibc (explained above)
      - gcc-4.4 depends on libc6-dev-mipsn32 which is not available in testing
        binary package libc6-dev-mipsn32 is part of source package eglibc (explained above)
      - gcc-4.4 depends on libc6-dev-powerpc which is not available in testing
        binary package libc6-dev-powerpc is part of source package eglibc (explained above)
      - gcc-4.4 depends on libc6-dev-ppc64 which is not available in testing
        binary package libc6-dev-ppc64 is part of source package eglibc (explained above)
      - gcc-4.4 depends on libc6-dev-s390 which is not available in testing
        binary package libc6-dev-s390 is part of source package eglibc (explained above)
      - gcc-4.4 depends on libc6-dev-s390x which is not available in testing
        binary package libc6-dev-s390x is part of source package eglibc (explained above)
      - gcc-4.4 depends on libc6-dev-sparc64 which is not available in testing
        binary package libc6-dev-sparc64 is part of source package eglibc (explained above)
      - gcc-4.4 depends on newlib-spu >= 1.16.0, which is not available in testing
        binary package newlib-spu is part of source package newlib
        
        newlib has the same version in unstable and testing (1.18.0-6.2)
        
        newlib depends on binutils-spu which is not available in testing
        binary package binutils-spu is part of source package binutils (explained above)
        
        newlib depends on gcc-spu which is not available in testing
        binary package gcc-spu is part of source package gcc-defaults
        
        trying to update gcc-defaults from 1.120 to 1.121 (candidate is 6 days old)
        gcc-defaults is only 6 days old. It must be 10 days old to go in.
        gcc-defaults is not yet built on i386: 1.120 vs 1.121 (missing 1 binary: gdc-v1)
        gcc-defaults is not yet built on amd64: 1.120 vs 1.121 (missing 1 binary: gdc-v1)
        gcc-defaults is not yet built on armel: 1.120 vs 1.121 (missing 1 binary: gdc-v1)
        gcc-defaults is not yet built on armhf: 1.120 vs 1.121 (missing 1 binary: gdc-v1)
        gcc-defaults is not yet built on ia64: 1.120 vs 1.121 (missing 1 binary: gdc-v1)
        gcc-defaults is not yet built on kfreebsd-amd64: 1.120 vs 1.121 (missing 1 binary: gdc-v1)
        gcc-defaults is not yet built on kfreebsd-i386: 1.120 vs 1.121 (missing 1 binary: gdc-v1)
        gcc-defaults is not yet built on mips: 1.120 vs 1.121 (missing 1 binary: gdc-v1)
        gcc-defaults is not yet built on mipsel: 1.120 vs 1.121 (missing 1 binary: gdc-v1)
        gcc-defaults is not yet built on powerpc: 1.120 vs 1.121 (missing 1 binary: gdc-v1)
        gcc-defaults is not yet built on s390: 1.120 vs 1.121 (missing 1 binary: gdc-v1)
        gcc-defaults is not yet built on s390x: 1.120 vs 1.121 (missing 1 binary: gdc-v1)
        gcc-defaults is not yet built on sparc: 1.120 vs 1.121 (missing 1 binary: gdc-v1)
        
        gcc-defaults depends on gcc-4.8-base >= 4.8.1-2~ but testing has 4.8.1-2 (unstable has 4.8.1-3)
        binary package gcc-4.8-base is part of source package gcc-4.8
        
        trying to update gcc-4.8 from 4.8.1-2 to 4.8.1-3 (candidate is 7 days old)
        gcc-4.8 is only 7 days old. It must be 10 days old to go in.
        gcc-4.8 is not yet built on s390: 4.8.1-2 vs 4.8.1-3 (missing 1 binary: gdc-4.8)
        gcc-4.8 no longer provides binary gdc-4.8. ftpmaster needs to remove it.
        gcc-4.8 is waiting for binutils
        binutils is explained above

[Show all dependencies · expand uninstallable packages · pkgs waiting for libxine1 · pkgs stalled by libxine1 · libxine1 on packages.qa.d.o · bugs in libxine1]

2252 packages are trying to enter testing. 16 packages are trying to be removed. 1 packages are going in/out today.
dependency toplist · oldest candidates · highscore · top stalls (no new, only ready) · versioned conflicts · old dependencies · obsolete binaries

Explanations:

1. Sometimes packages have seemingly recursive dependencies (adding X makes Y uninstallable, Y is waiting for X). This means the new version of X will break the old version of Y, but there's also a new version of Y that needs the new version of X. As soon as all other dependencies are solved, the two packages can be hinted to go in together.

2. Platforms are tested in alphabetical order, but only the first that breaks is displayed. That's why many packages are reported as uninstallable on alpha. Actually they are most likely uninstallable on many other platforms too, but only the result for alpha is displayed.

written by Bj�rn Stenberg · script source code

Data is synced with ftp-master.debian.org hourly.
Latest update: Thu, 20 Jun 2013 05:00:10 GMT