Frans Pop wrote: > Andreas Barth wrote: >> As an current exmaple, take the libcdio-transition. This transition >> needs to have updated packages xmms2, xmp and vlc. However, the >> packages are out-of-date on hppa, and for this reason cannot enter >> testing (and they depend on an old library that will go away with the >> transition). > > I'm not an hppa porter and also have not looked at the current general > state of hppa build failures, but are you sure this is a good example?
It's a good example of why having a suboptimal working architecture can delay more and more things which makes it either harder for everyone or harder for the port. > 1) vlc is also not yet built on mips/mipsel, so hppa is not *the* blocking > arch. The build failure for mips/mipsel is due to a bug in iceape which is solved upstream. > 2) The current build was tried 3 times and failed three times with > different errors; it also needed 3 tries on powerpc and required binNMUs > on 2 arches. So, there *has* been action by the porters (retries) and > clearly there are also problems with the package itself or its > dependencies. Note that these retries for hppa have been done by me. The first failure was because of a broken hppa chroot due to a non arch specific issue. The second failure was because of a broken chroot due to another non arch specific issue. The third one is due to an uncoordinated transition of libogg. The reason it takes long to fix these issues is mainly because of the recurring segfaults which delay having fixed packages to be able to fix the chroot or rebuild the dependencies that need to be rebuilt first. Also the other retries and the binNMUs had nothing to do with the package quality. > Is it realistic to require porters to spend a lot of time or give priority > to such an apparently fragile package? Isn't there some obligation on the > maintainer of the package too? So this is not applicable. > Or are you simply asking the hppa porters to be more active in filing > FTBFS bugs against packages after build failures? Looking at build logs is indeed not a bad idea, though not only to file bug reports against the failing to build package, but also to notice chroot issues or other reasons the build failed. So the issues can be solved or reproduced earlier. Cheers Luk -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
