since ARM is running late, maybe it would be wise to not remove build-dependencies at the end of a run, (and check for any build conflict before starting, and just remove that)
for example, to compile my package , sbuild had to install things as gettext, libtool autotools-dev debhelper xlibs-dev libxaw7-dev xutils texinfo I propose to keep them installed for some time..
moreover my package depends on libgtk2.0-dev: I guess there are many packages that has the same dependency
a.
Steve Langasek wrote:
On Mon, Apr 11, 2005 at 09:25:56AM +0200, A Mennucc wrote:
reading the latest message on the status of the release
http://lists.debian.org/debian-devel-announce/2005/04/msg00003.html
I understood that the release was near, and that, given good progress with d-i and
testing-security, the main showstopper was the arm buildds trouble. (*)
Yesterday I have uploaded two packages, with low priority, and the arm buildds
compiled them after only 4 hours.
So I am curious : what is stopping the freeze now? testing-security?
What's stopping the freeze is all the people uploading their low-priority packages and keeping the arm autobuilders from ever catching up on the ones that are actually medium and high priority. ARM is *not* OK; we still have only two buildds on-line instead of the usual four, and the build queue is getting longer, not shorter.
That, and still waiting for the glibc upload to roll in, and for testing-security to be 100% on-line.
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]