[Please CC as I am not subscribed.] Hi Guys, I am the maintainer of the IVTV driver packages. The IVTV upstream have a scheme where the 0.6.x releases are for use with the 2.6.16 kernels, 0.7.x goes with 2.6.17 etc. There is an older 0.4.x series which works with 2.6.15 and earlier. I have unfortunately allowed the 0.6.x package to propagate into Etch, which currently has a 2.6.15 kernel that the IVTV packages cannot work with[0]. It seems that 2.6.16 will not be going into Etch anytime soon due to the freeze[1], is that correct? Given that 2.6.16 won't be going in I think the best thing for me to do would be to file a bug asking for the current IVTV package to be removed from testing. However, does anyone know a more elegant way than filing an RC bug to stop the 0.6.x package propagating again (and the same problem occurring in the 2.6.17/0.7.x time-frame)? I don't think there is a kernel package I can sensibly depend on since people may build from upstream source. Would a build-depends make sense, even though it isn't strictly true? Thanks for any advice, Ian. [0] See bug #375613 if you are interested. [1] From http://packages.qa.debian.org/l/linux-2.6.html -- Ian Campbell BOFH excuse #375: Root name servers corrupted.
Attachment:
signature.asc
Description: This is a digitally signed message part