Re: open issues with the hppa port
* Andreas Barth (firstname.lastname@example.org) [090730 16:51]:
> As from release team point of view, it is necessary that there is a plan
> how hppa can and will return in the forseeable future to normal mode of
> operation, i.e. there are not many issues with e.g. architecture specific
> build failures.
I have seen some activity from your side. Thank you for that.
However, it would be really good if we could get some written down
plan with maximum amount of time it takes till we are in normale
Let me try to explain what we mean with that:
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
Of course, this happens with any architecture from time to time. But
hppa is quite often hit there.
Forcing the transition as of now breaks these packages on hppa:
libvlc-dev, libvlc2, libvlccore-dev, libvlccore2, mozilla-plugin-vlc, vlc,
vlc-dbg, vlc-nox, vlc-plugin-ggi, vlc-plugin-jack, vlc-plugin-pulse,
vlc-plugin-sdl, xmp, xmp-audacious
It is very tempting for me to just put hppa to the list of broken
For us as release team it is necessary that an architecture is not
outstanding often hit by "out of date"-packages in an transition. If
you look at https://buildd.debian.org/stats/graph2-week-big.png you
can see that hppa has issues to keep up.
I see that issues that are brought up here are most often resolved
quite fast, but this forces us to manually dig for issues. I would
like that we can relay on the fact that packages (unless a specific
bug exists in the package of course) are normally built within a few
days, and that build failures are investigated by the porters and
fixed if these are port-specific issues (falling kernel, whatever).
If you need help in setting up infrastructure for that, please let us