Re: open issues with the hppa port
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
Reply to: