Re: Please reschedule libgnomesu 0.9.5-3 on ARM
Hi,
On Thu, Aug 10, 2006, Andreas Metzler wrote:
> and therefore makes the whole thing uninstallable on all
> not yet built architectures on every upload.
Ah you too find it depressing?
> Dear gnome-maintainers I think I cannot do this. I have now seen
> libgnomesu FTBFS on arm three times in row during two months due to
> some temporary breakage. Could you please advise me what I can do to
> get libgnomesu built on ARM?
This is not a problem of the GNOME maintainers, it happens with all
arch: all / arch: any combo.
The real problem is in the archive software which does not keep all
versions of arch: all packages still referenced by some binary package.
Take for example xulrunner, it is very hard to build, and even if an
older version of libxul-dev / libxul0d would be acceptable to build
other packages, this is not possible because the older version of
libxul-dev (arch: all, 3.5 MB) isn't available so libxul0d MUST be
rebuilt before anything else can be built (gnome-panel, totem,
evolution-*, epiphany-browser, devhelp, galeon, gnome-python-extras,
yelp...) and with time the full GNOME stack is missing.
Last successful build on arm was on:
1.8.0.1-11 (arm) (latest build at May 21 12:04: maybe-successful
Next xulrunner upload was on:
[2006-06-15] Accepted 1.8.0.4-1 in unstable (high) (Mike Hommey)
It failed on the buildds, so Mike requested a build:
http://lists.debian.org/debian-arm/2006/06/msg00067.html
It was built manually by someone and installed the 3rd of july (18 days
uninstallable).
Next upload of xulrunner was on:
[2006-07-08] Accepted 1.8.0.4-2 in unstable (low) (Mike Hommey)
And xulrunner never built since then, nor was manually built (1 month
uninstallable).
> Could you perhaps give me a thumbs up "Gnome development will
> probably be installable on ARM from X-Y", so I can stop waisting (not
> only my) time?
No. If you're a Debian Developper, you can build stuff yourself and
bin NMU it to Debian. I'm not sure the arm buildd admins would like
it, but you might help unlock some problems.
You can also build stuff which failed to build manually on your side
and install it in your private repository.
You can of course track only stable or testing, and you should see
less holes in dependencies.
Finally, you can help fixing the root build failures by providing
patches or diagnosing them.
All of this has nothing to do with GNOME. It's not specific to arm
either, but I guess it is exacerbated under ARM probably because of
slower buildds, lack of porters and buildd admins time.
Bye,
--
Loïc Minier <lool@dooz.org>
Reply to: