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 <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
