Re: Package xxx has broken dep on yyy: normal?

Dan Jacobson <[EMAIL PROTECTED]> writes: > Well OK, but please be aware of the cases where a kid leaves his > village for a trip to the big city and his single chance to do an > apt-get dist-upgrade. He can't just try again tomorrow if things > don't work out. I'm inclined to think that people s

Re: Package xxx has broken dep on yyy: normal?

Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Dan Jacobson <[EMAIL PROTECTED]> writes: > > > Well OK, but please be aware of the cases where a kid leaves his > > village for a trip to the big city and his single chance to do an > > apt-get dist-upgrade. He can't just try again tomorrow if t

help needed with mips build failure

Can someone with mips and/or libtool expertise examine the build failure for gnucash below, and see if they can diagnose the problem? http://buildd.debian.org/fetch.php?&pkg=gnucash&ver=1.8.10-5&arch=mips&stamp=1107337123&file=log&as=raw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a su

Re: help needed with mips build failure

Steve Langasek <[EMAIL PROTECTED]> writes: > You're using an old (and broken) version of libtool. C.f. > for > Ryan's boilerplate explanation for fixing this problem. Thanks a bunch, this is surely the problem, but applying the s

Re: help needed with mips build failure

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Steve Langasek <[EMAIL PROTECTED]> writes: > > > You're using an old (and broken) version of libtool. C.f. > > <http://lists.debian.org/debian-qa-packages/2003/09/msg00023.html> for > > Ryan&#x

Re: help needed with mips build failure

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > On Wed, 16 Feb 2005, Thomas Bushnell BSG wrote: > > Now, it should be noted, upstream uses autoconf 2.13, and libtool > > 1.4c. So these errors should not be happening, and seem to imply > > problems i

Re: help needed with mips build failure

Steve Langasek <[EMAIL PROTECTED]> writes: > Clearly not, or it wouldn't have failed to build on mips and mipsel. There > is nothing "perfectly working" about that version of libtool, and moreover, > its effects are not limited to the mips architectures -- as the obscenely > long list of library

Re: help needed with mips build failure

Steve Langasek <[EMAIL PROTECTED]> writes: > Considering Debian is the only mainstream desktop distribution with a mips > port, and gnucash upstream has in the past disavowed all responsibility for > compatibility with non-i386 archs, this seems laughably false. Also, > there's the fact that we'v

Re: help needed with mips build failure

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > As for it being complicated, well, I believe you. But you need not be > upstream to change the build system, I have done that three or four times > already. It is not the most gratifying work in the world, at all... but the > result is fa

Re: help needed with mips build failure

Steve Langasek <[EMAIL PROTECTED]> writes: > That would be RC bug #295175 in the xfree86-common package. I don't imagine > gnucash would've fared any better under these circumstances without the > libtool update, either. Ah, ok! I'm glad you are up on these things; I would not have guessde to l

Re: help needed with mips build failure

Steve Langasek <[EMAIL PROTECTED]> writes: > Note that it's not sufficient for the fixed package to reach unstable, the > buildd admins also (and more importantly) need to clean up the build chroots > by manually reconciling the status of the xfree86-common package. Yeah, I'd like to think it's n

Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org

I have found the exim-4 packages to be extremely well organized and handy. I used to use the "one-file" method, and was simply delighted when I found how easy it was to switch and tweak the individual files that I needed to when I had to create a more complicated mail server. Thomas -- To UNS

Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org

Steve Greenland <[EMAIL PROTECTED]> writes: > Jesus H. Christ. Read the original post to this thread. It was a > complaint about how the upstream docs were not consistent with the > debian config. Huh? The original post AFAICT of this thread consisted of Marc Haber complaining that it was inappr

Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org

Steve Greenland <[EMAIL PROTECTED]> writes: > > And the fact exim4 diverges from upstream has *absolutely nothing* to do > > in a debconf note. Debconf is here to promt users, not to document > > changes. > > But how would it hurt to say that choice A is more standard? What is "more standard"?

Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org

William Ballard <[EMAIL PROTECTED]> writes: > Good lord, what are we arguing about then :-) > Do people who edit their exim config (I never do on my desktop) > really have a hard time grasping #include files? You've missed the point of the many-small-files config. As a happy user, let me explain

Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org

William Ballard <[EMAIL PROTECTED]> writes: > Please spare me your moralizing when you don't even read my post very > closely and I was already in favor of the current way Debian handles it. I wasn't moralizing; I'm sorry if I misunderstood your note. Many people here have failed to understand

Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org

Henning Makholm <[EMAIL PROTECTED]> writes: > Scripsit Thomas Bushnell BSG <[EMAIL PROTECTED]> > > > The point is that I want to massage some parts of the configuration > > and not others. I want the others to continue to get updated by the > > normal pack

Bug 295175 followup

Bug 295175, the grave xfree86-common bug that was blocking many autobuilds has now had its fix uploaded to the archive. Unfortunately, the xfree86 build with the fix is failing, and looking at the build logs, I think it's because the buildd chroots are still corrupted with the damage that the bug

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > Our chances of actually releasing one day could only increase if we > dropped arches such as mipsel, s390, m68k, ... and concentrated on > those that actually mattered: i386, powerpc, amd64 -- and I'll > gladly add a few more. But a total of eleven

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > But to the best of my knowledge, Marco's (blog) post from a few months > ago which showed download from ftp.it.debian.org by architecture stands > undisputed: essentially all users are on i386 clearly dominating all other > arches, with a fractio

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > I was quoting a post with actual download numbers that actually demonstrate > that the vast majority of users are on i386: see http://blog.bofh.it/id_66. But that doesn't show what you said you believe, which is that supporting other archs slows th

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

Marc Singer <[EMAIL PROTECTED]> writes: > It does seem prudent to find a way to permit a release on x86 and > ppc before all architectures are complete. Especially if this > tactic will give Debian the ability to release more often. Is it so > bad to allow the smaller architectures to lag as lon

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > Thanks for cutting and completely ignoring the part where I demonstrated > the lack of usage beyond i386 and maybe four or five other arches. "lack of usage" here means "much rarer usage" of course. .001 is not zero. And your point was supposedly

Re: Cross-compiling and dist-cc (Was: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]))

[EMAIL PROTECTED] (Paul Hampson) writes: > Or have I missed something important? Yes. There are a jillion different machine code programs that do the same thing and a compiler could generate any one of them in response to the same source. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a s

Re: Cross-compiling and dist-cc

John Hasler <[EMAIL PROTECTED]> writes: > Wouter Verhelst wrote: > > And a hell of a lot of work. You can't just create checksums of the > > resulting binaries and compare those; it's not as if any difference > > between the two compiled binaries would constitute an error... > > The idea is to cr

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

Steve McIntyre <[EMAIL PROTECTED]> writes: > Well, I'll say differently. I've produced the last several sets of > woody point release CD and DVD images. Each arch produced takes > time. Reducing the sets produced would make it much easier/faster to > get this done. Does this delay release? --

the ongoing xfree86 buildd saga

So the new xfree86 has been built on most archs, but is still not built on sparc, mips, and m68k. The sparc and mips failures look like their buildd chroots are still corrupted. The m68k build ran out of disk space: ar clq libglx.a glx/?*.o ar: libglx.a: No space left on device make[6

Re: the ongoing xfree86 buildd saga

Adeodato Simà <[EMAIL PROTECTED]> writes: > * Thomas Bushnell BSG [Wed, 23 Feb 2005 12:13:42 -0800]: > > > Do the buildd people read this list? How do we get this cleaned up? > > That's not relevant, really. What matters is if they read their logs, > and th

Re: the ongoing xfree86 buildd saga

Ingo Juergensmann <[EMAIL PROTECTED]> writes: > On Wed, Feb 23, 2005 at 12:13:42PM -0800, Thomas Bushnell BSG wrote: > > > Do the buildd people read this list? How do we get this cleaned up? > > As far as I can tell you: the m68k buildd people will have noticed that >

Re: the ongoing xfree86 buildd saga

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > I'm not trying to grind an axe or complain, I'm seeking information > and to move the process along expeditiously because it's blocking a > lot more than just an xfree86 upgrade. For example, once this is

Re: the ongoing xfree86 buildd saga

Wouter Verhelst <[EMAIL PROTECTED]> writes: > On Wed, Feb 23, 2005 at 12:22:59PM -0800, Thomas Bushnell BSG wrote: > > Moreover, because it seems to be extremely difficult to know who > > manages which buildd's and get responses from them, > > Have you tried

Re: the ongoing xfree86 buildd saga

Ingo Juergensmann <[EMAIL PROTECTED]> writes: > See why the current buildd system is obsolete? I've never disagreed with the fact that the current buildd system is creaking. What would it take for multibuild to succeed? or something else? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with

Re: the ongoing xfree86 buildd saga

Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Screwing up in the postrm of a package in Build-Depends is about the > worst you can do to the current buildd. It is pretty sure to cripple > them all. The inability of buildds to rebuild their chroots from > scratch doesn't help. Shit happens, st

Re: the ongoing xfree86 buildd saga

Wouter Verhelst <[EMAIL PROTECTED]> writes: > On Wed, Feb 23, 2005 at 12:41:46PM -0800, Thomas Bushnell BSG wrote: > > Wouter Verhelst <[EMAIL PROTECTED]> writes: > > > That won't help, especially not in this case. Those who manage the > > >

Re: the ongoing xfree86 buildd saga

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > ONCE IT'S CLEANED UP, what should I do to get the package rebuilt? > Seems to me, I should requeue it. Nothing else is an advertised or > reliable way. Even the @buildd.debian.org I'm now told is not > reliable.

Re: the ongoing xfree86 buildd saga

Steve Langasek <[EMAIL PROTECTED]> writes: > I don't think it would hurt if maintainers whose packages are in this state > would email the relevant @buildd.debian.org addresses and cc: > debian-release on the message -- now, rather than waiting for the buildds to > be fixed. Hopefully, this would

Re: Let's remove mips, mipsel, s390 ... [or have strict arch: control? ]

Rudy Godoy <[EMAIL PROTECTED]> writes: > Regarding this issue I was thinking about it since I've faced in a > situation where a package[0] I maintain does have "high" hardware > requirements, which led me to think if it is really wise to have it > with "arch: any" since probably in some arches it

help with bug 296693

Bug 296693 is a grave bug which reports a catastrophic guile crash in gnucash. However, it doesn't happen for me. The user told me that it did happen even for other machines of his. Yet, nobody else has reported it. Can a user with an i386 attempt to reproduce the bug and report back? Also, I

Re: mipsel drop / buildd situation Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]

Florian Lohoff <[EMAIL PROTECTED]> writes: > mipsel is a little wrong in this list. We had some hardware problems on > the 2 mipsel buildds (Same Machine, Same Manuf. Date, Same time PSU > defect) and it took a while to get at least one up. The short-after > death of one of the machines went past

Re: Do not make gratuitous source uploads just to provoke the buildds!

Steve Langasek <[EMAIL PROTECTED]> writes: > Re-uploading a package to provoke a buildd response is counterproductive, > *particularly* when the package is already in Needs-Build on the missing > architectures. Re-uploading doesn't change its position in the queue, but > it *does* force buildds f

Re: Do not make gratuitous source uploads just to provoke the buildds!

Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > On Fri, Mar 11, 2005 at 05:03:55PM -0800, Thomas Bushnell BSG wrote: > > If, perhaps, there was a clear indication of the buildd ordering > > policy, then it could be properly used. Until then, I go on the basis > &g

Re: Do not make gratuitous source uploads just to provoke the buildds!

Steve Langasek <[EMAIL PROTECTED]> writes: > The queue ordering is entirely automatic, and AIUI the queue(s) is (are) > sorted by: > > - target suite > - package priority > - package section > - package name > > I personally believe it would be beneficial to prioritize by upload urge

Re: Do not make gratuitous source uploads just to provoke the buildds!

Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Remember that the buildd queue is not FIFO at all. The queue has a > completly static order. Any changes to the queue are just packages > hiding because they are not "needs-build". I consider that the biggest > flaw of all in wanna-build. This is

Re: Do not make gratuitous source uploads just to provoke the buildds!

Steve Langasek <[EMAIL PROTECTED]> writes: > Er, packages *do* eventually get built; they just don't get built in any > kind of FIFO order. This is not true. The current system has an unbounded wait time. For example, the effect of the Bug Squashing Party, which causes a bunch of uploads to b

Re: Do not make gratuitous source uploads just to provoke the buildds!

Matthew Palmer <[EMAIL PROTECTED]> writes: > Practically, buildd admins can notice a longer-than-usual queue and throw > hardware at the problem, and that seems to work well enough, and we could > reduce the rate of package inflow through various means, but the problem > still remains -- the queue

Re: buildd queue starvation (Was: Re: Do not make gratuitous source uploads just to provoke the buildds!)

Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > If the queue is non-zero for a longer time, there is a problem in buildd > machine power, and the wanna-build admin has choosen to in this case > allocate the buildd power that remains to the building of packages that > are of higher priority, re

Re: Do not make gratuitous source uploads just to provoke the buildds!

Andreas Barth <[EMAIL PROTECTED]> writes: > Because we want packages in base to be preferred, as well as packages in > libs. I think that is a given, but it's not uploads to base and libs that are hosing the recompilation of gnucash at present. I think it's worth looking at the perverse incentiv

Re: Is Anthony Fok MIA?

Martin Michlmayr <[EMAIL PROTECTED]> writes: > > We are a bit concerned with old LilyPond packages, and a potential > > new maintainer (Pedro Kroger) with his sponsor going mia. > > Who was going to sponsor him? I use lilypond all the time, so I'm happy to adopt it if necessary. I'm a bad mentor

Re: Do not make gratuitous source uploads just to provoke the buildds!

Hamish Moffatt <[EMAIL PROTECTED]> writes: > Given how low hamradio (and the like) are prioritised, I suggest that we > get smarter about 'tesing' and omit some sections on some architectures. I don't think those sections are causing the problem. There are also not so many uploads for them. The

Re: Bits (Nybbles?) from the Vancouver release team meeting

Steve Langasek <[EMAIL PROTECTED]> writes: > Some maintainers have already opted to move their GFDL documentation > to non-free for sarge, but the vast remainder will need to be dealt > with soon after sarge's release to keep us on track for etch. I assume you mean that the documentation will nee

Re: Bits (Nybbles?) from the Vancouver release team meeting

Steve Langasek <[EMAIL PROTECTED]> writes: > The sh and hurd-i386 ports don't currently meet the SCC requirements, as > neither has a running autobuilder or is keeping up with new packages. It is impossible for any port under development to meet the SCC requirements. We need a place for such por

Re: Do not make gratuitous source uploads just to provoke the buildds!

Wouter Verhelst <[EMAIL PROTECTED]> writes: > > It means that when one is told "just wait, your package will get > > rebuilt"; it is not necessarily true at all. There is no upper bound > > at all on time to wait for building, and that's a disaster. > > This paragraph assumes nobody ever looks t

Re: Do not make gratuitous source uploads just to provoke the buildds!

Wouter Verhelst <[EMAIL PROTECTED]> writes: > I agree with the w-b maintainers. The queue order is only interesting in > the case where there is a backlog; in other cases, packages are usually > built rather fast. In the case where there is a backlog, those trying to > fix the architecture (usuall

Re: buildd queue starvation (Was: Re: Do not make gratuitous source uploads just to provoke the buildds!)

Wouter Verhelst <[EMAIL PROTECTED]> writes: > None of the documentation calls it a 'queue', in fact; only people not > really involved in buildd stuff do. Does that include you? In two recent messages, you referred to it as a queue. > > I can see excellent reasons why age in the list shouldn't

Re: Bits (Nybbles?) from the Vancouver release team meeting

Steve Langasek <[EMAIL PROTECTED]> writes: > On Sun, Mar 13, 2005 at 10:47:15PM -0800, Thomas Bushnell BSG wrote: > > Steve Langasek <[EMAIL PROTECTED]> writes: > > > > The sh and hurd-i386 ports don't currently meet the SCC requirements, as > > >

Re: Bits (Nybbles?) from the Vancouver release team meeting

Steve Langasek <[EMAIL PROTECTED]> writes: > The point is that the ftpmasters don't want to play host to various > ports that *aren't* yet matured to the point of usability, where "being > able to run a buildd" is regarded as a key element of usability in the > port bootstrapping process. The amd

Re: Bits (Nybbles?) from the Vancouver release team meeting

Sven Luther <[EMAIL PROTECTED]> writes: > BTW, how much of the human intervention needed for buildd signing > plays in the delays you see, and did you discuss the possibiliity of > a fully autobuilder setup, like ubuntu does and i advocated years > ago ? I can't answer for Steve, but it seems to

Re: Is Anthony Fok MIA?

Jan Nieuwenhuizen <[EMAIL PROTECTED]> writes: > Thanks for the offer! I'm not sure however how adopting a package > works, I guess you'll have to sort with Anthony and Pedro. I know how to take care of the package. But Anthony Fok is currently the maintainer, so he needs to either orphan it or

Re: Not every package should enter Debian (was: Re: Who cares about NEW when there are bigger issues? (was Re: Is NEW processing on hold? (was: Question for candidate Towns)))

Matthias Urlichs <[EMAIL PROTECTED]> writes: > That being said, sources which just sprout new binary packages really > should be passed through NEW automagically. I made a foolish mistake not too long ago that would never have been caught by this mechanism; I was most grateful for Anthony Towns w

Re: Bits (Nybbles?) from the Vancouver release team meeting

Sven Luther <[EMAIL PROTECTED]> writes: > > Where human delay did come into play was in getting the xfree86 mess > > cleaned; in theory it should have taken one or two days, but in > > practice it took much longer. > > Why not fully eliminate the human factor ? Ubuntu does automated build from >

Re: Bits (Nybbles?) from the Vancouver release team meeting

Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > > Steve Langasek <[EMAIL PROTECTED]> writes: > > > >> The point is that the ftpmasters don't want to play host to various > >> ports

Re: Is Anthony Fok MIA?

Martin Michlmayr <[EMAIL PROTECTED]> writes: > * Thomas Bushnell BSG <[EMAIL PROTECTED]> [2005-03-14 02:14]: > > I know how to take care of the package. But Anthony Fok is currently > > the maintainer, so he needs to either orphan it or offer it for > > a

Re: Bits (Nybbles?) from the Vancouver release team meeting

Steve Langasek <[EMAIL PROTECTED]> writes: > Removing unimportant buggy packages from testing is *easy* -- much > easier than trying to craft guidelines for declaring a set of "core" > packages. Getting all of the packages that are considered too important > to release without is *hard*. Hand-ho

Re: Bits (Nybbles?) from the Vancouver release team meeting

Matthew Garrett <[EMAIL PROTECTED]> writes: > It's not clear that an FTP site really satisfies that, and it's also the > case that this is the FSF's interpretation rather than being the one > that all GPL copyright holders hold. I'd worry that we might fall foul > of some (seemingly valid) GPL int

Re: Bits (Nybbles?) from the Vancouver release team meeting

"Brian M. Carlson" <[EMAIL PROTECTED]> writes: > This is a problem. No one will fix the portability bugs that plague, for > example, sparc (memory alignment SIGBUS) without them being severity > serious. Can the porters fix such bugs? Do the porters promise me a machine running unstable so that

Re: Bits (Nybbles?) from the Vancouver release team meeting

Matthew Garrett <[EMAIL PROTECTED]> writes: > Remember that the relevant tools include arbitrary ftp clients. Yes, but it's easy to put the README file telling people the location for the source. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact

Re: Questions for the DPL candidates

Anthony Towns writes: > Hopefully the above provides some useful specifics for people to talk about. And the below as well. Thanks for the clear explanation of the process; I hope that the flamage on debian-devel doesn't prevent the signal there also from being taken into account as the final r

Re: SCC proposal (was: Re: Questions for the DPL candidates)

Anthony Towns writes: > Halting unstable autobuilding, fixing remaining bugs in an > arch-specific freeze, then making a snapshot allows you to produce a > release. It may or may not correspond with Debian stable. I am of the opinion that the testing distribution has been a great help in releasi

Re: Bits (Nybbles?) from the Vancouver release team meeting

Steve Langasek <[EMAIL PROTECTED]> writes: > The inclusion of ia64 in the release count is a projection, based on > where I believe things are today. Nothing the release team is doing > ensures that ia64 is going to be a viable port, a year from now when > we're trying to release etch; and nothin

Re: Bits (Nybbles?) from the Vancouver release team meeting

Matthew Palmer <[EMAIL PROTECTED]> writes: > On Mon, Mar 14, 2005 at 02:14:52PM -0800, Thomas Bushnell BSG wrote: > > "Brian M. Carlson" <[EMAIL PROTECTED]> writes: > > > > > This is a problem. No one will fix the portability bugs that plague, for

Re: Bits (Nybbles?) from the Vancouver release team meeting

Steve Langasek <[EMAIL PROTECTED]> writes: > > How can they be, since they will be off in another archive? You can't > > decide now to put an arch in scc and at the same time say you won't > > know whether it's in tier1 or tier2 until etch is close to release. > > Please re-read the proposal. N

Re: Bits (Nybbles?) from the Vancouver release team meeting

Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > The only differentiating requirement for scc, as opposed to the other > "part of Debian" architectures, seems to be download share. That won't > suddenly change. You are incorrect, and my example remains, and I'm wondering how the procedure would w

Re: Bits (Nybbles?) from the Vancouver release team meeting

Anthony Towns writes: > Thomas Bushnell BSG wrote: > > Ok, I think I understand. Suppose that we have an arch that does have > > enough download share, and meets every requirement but the existence > > of sufficient buildds to keep up and developer machines, and that only

Re: Bits (Nybbles?) from the Vancouver release team meeting

Anthony Towns writes: > If there was an arch that was five times more popular than powerpc, > and no one was able to just donate boxes, I'd expect we'd buy > some. We'd already need to have /some/, just to have built the > packages that people are downloading. Oh, right, of course! I was just s

status of buildds?

http://buildd.debian.org/stats/graph-week-big.png For the past week, mipsel has been chugging mightily and made huge progress. But s390 has slipped worse and worse, with only a single machine building packages. Meanwhile, arm made a brief, but valiant attempt, but has been plummeting, and is no

Re: Another load of typos

Joey Hess <[EMAIL PROTECTED]> writes: > Would you mind giving a reference to a manual of style or something > about these? I always only use "an" before an acronym if the expansion > of the acronym would need an "an" in front. "An FAQ" sounds wrong to my > ears. It depends on how you expand it.

Re: Another load of typos

Florian Zumbiehl <[EMAIL PROTECTED]> writes: > The rule I am following is that "a" vs. "an" is decided by pronounciation > only - i.e., it's "an eff ey kju", but "a FAT file system". After all, > that's how the exact letters are most easily read (without expanding > acronyms or such). Your rule i

Re: status of buildds?

Ingo Juergensmann <[EMAIL PROTECTED]> writes: > On Mon, Mar 14, 2005 at 08:43:40PM -0800, Thomas Bushnell BSG wrote: > > > For s390 and sparc, it appears that only one machine is in place > > building these archs. > > As Bastian Blank said yesterday on IRC, w-b a

Re: status of buildds?

Marc Haber <[EMAIL PROTECTED]> writes: > >The s390 porting team can perfectly well do what the hurd-i386 porting > >team does: build them themselves. I mean, umm, you don't have to be > >hooked into w-b to upload packages. > > Why are some architectures refused the same service that others get?

Re: status of buildds?

Goswin von Brederlow <[EMAIL PROTECTED]> writes: > We did that last year for m68k, mips, mipsel and alpha and it produced > a great flame since some machines where hosted by non DDs and none of > them were approved by the debian admin team. The opinions (including > an RM too) expressed in that fl

Re: status of buildds?

Ingo Juergensmann <[EMAIL PROTECTED]> writes: > It's the job of w-b admins to add new buildds in a timely manner. If they > don't do that, they simply fail (one significant part of) their job. > This not only happens to s390 now but already happened in the past to m68k > for example. Ok, let's

Re: status of buildds?

Ingo Juergensmann <[EMAIL PROTECTED]> writes: > On Tue, Mar 15, 2005 at 09:07:46AM -0800, Thomas Bushnell BSG wrote: > > > > It's the job of w-b admins to add new buildds in a timely manner. If they > > > don't do that, they simply fail (one significant

Re: status of buildds?

Ingo Juergensmann <[EMAIL PROTECTED]> writes: > On Tue, Mar 15, 2005 at 10:44:03AM -0800, Thomas Bushnell BSG wrote: > > > > > > It's the job of w-b admins to add new buildds in a timely manner. If > > > > > they > > > > > don&#

Re: Vancouver meeting - clarifications

Andreas Barth <[EMAIL PROTECTED]> writes: > | - the release architecture must have N+1 buildds where N is the number > | required to keep up with the volume of uploaded packages > The reason for this proposal should be instantly clear to everyone who > ever suffered from buildd backlogs. :) I n

Re: s390 not currently projected releasable (was: Re: Dropping from mirror network vs dropping from tier-1)

Bastian Blank <[EMAIL PROTECTED]> writes: > On Tue, Mar 15, 2005 at 04:12:51PM +0100, David Schmitt wrote: > > Looking at the stats[1], the amount of compiled packages seems to be a > > blocker: 250-300 need-build packages. At approximatly 9000 source packages, > > around 8820 must be built to s

Re: s390 not currently projected releasable

Bastian Blank <[EMAIL PROTECTED]> writes: > It is possible, either you setup you own w-b or do it by hand, the later > is a time consuming process. And you will generate a lot of noise with > rejected packages. Yes, it's better to do nothing than to do only part of the job. -- To UNSUBSCRIBE,

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

Martin Michlmayr <[EMAIL PROTECTED]> writes: > We can move services to supported architectures, but there is of > course one major problem: DSA is only willing to host stable .d.o > boxes but if many architectures don't have stable releases, they will > not be able to offer developer accessible po

Re: s390 not currently projected releasable (was: Re: Dropping from mirror network vs dropping from tier-1)

Bastian Blank <[EMAIL PROTECTED]> writes: > On Tue, Mar 15, 2005 at 11:17:23AM -0800, Thomas Bushnell BSG wrote: > > > Yes, it was a broken autobuilder, the only autobuilder, the others are > > > blocked by the w-b admins. > > Why don't you start building pa

Re: s390 not currently projected releasable

Bastian Blank <[EMAIL PROTECTED]> writes: > On Tue, Mar 15, 2005 at 11:18:11AM -0800, Thomas Bushnell BSG wrote: > > Bastian Blank <[EMAIL PROTECTED]> writes: > > > It is possible, either you setup you own w-b or do it by hand, the later > > > is a time con

Re: Bits (Nybbles?) from the Vancouver release team meeting

Matthew Palmer <[EMAIL PROTECTED]> writes: > There's no fixed number of slots associated with a job (apart from a couple > of constitutionally-mandated ones, but they have strict ways of getting the > job, too, so they're not predicated on "free time"). Nobody has to retire > in order for someone

Re: Bits (Nybbles?) from the Vancouver release team meeting

Joey Hess <[EMAIL PROTECTED]> writes: > Colin, Steve, and I became release assistants when AJ posted a mail to > -devel asking "who wants to be a release assistant" and then gave us a > set of grunt-work tasks of increasing difficulty to do until he judged > we basically knew what we were doing.

Re: status of buildds?

Ian Lynagh <[EMAIL PROTECTED]> writes: > On Mon, Mar 14, 2005 at 10:51:23PM -0800, Thomas Bushnell BSG wrote: > > > > The s390 porting team can perfectly well do what the hurd-i386 porting > > team does: build them themselves. I mean, umm, you don't have to

Re: s390 not currently projected releasable (was: Re: Dropping from mirror network vs dropping from tier-1)

Blars Blarson <[EMAIL PROTECTED]> writes: > Another architecure that isn't keeping up to the 98% mark has a buildd > mainainter who insists (to the point of threating) that I don't build > and upload packages to help the build with its backlog and lack of > requeueing. So? A buildd maintainer do

Re: Bits (Nybbles?) from the Vancouver release team meeting

Anthony Towns writes: > AFAICS creating a "proposed-updates"-like tree called "snapshot-s390" > for preparing a snapshot would be straightforward, if it would be > useful; and the snapshotting feature already discussed counts somewhat > as infrastructure support. One suggestion here then is for

Re: Bits (Nybbles?) from the Vancouver release team meeting

Anthony Towns writes: > Here's one way. Let's say you're hacking on the Hurd. You've been in > the archive for a while on scc.d.o as a non-release candidate, and > just the other day you've finally managed to get it to run "ls" again, > and in the euphoria from that moment, over a single 48h hack

Re: The sarge release disaster - some thoughts

Steve Langasek <[EMAIL PROTECTED]> writes: > So if it has taken us 6 months to get the problems with testing-security > sorted out, what do you suppose we would have done for security support if > we had frozen and released six months ago, without first sorting out these > problems? Gone six mont

Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting

Anthony Towns writes: > The reason for the N = {1,2} requirement is so that the buildds can be > maintained by Debian, which means that they can be promptly fixed for > system-wide problems, and which means access to them can be > controlled, rather than opening up users of that architecture to >

How to join a team

Tollef Fog Heen <[EMAIL PROTECTED]> writes: > Most of the teams here work by the principle of Âsubmit working > patches and be usefulÂ. I don't think having a formalised process to > join the CD-image team (randomly chosen) is very useful. BTW, I hope to be able to make a web page that explains

Running bash before the system boots

Tollef Fog Heen <[EMAIL PROTECTED]> writes: > * Thomas Bushnell BSG > > | Now now, "ls" has been working for a long time. We had bash running > | before the system could even boot. > > Amazing. How do you make bash run on a non-booted system? It > cert

Re: status of buildds?

Goswin von Brederlow <[EMAIL PROTECTED]> writes: > > So do it on machines that *are* hosted by DDs. Geez. > > Still not debian admin approved. The Developer's Reference contains the procedures for binary NMUs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Tro

<    1   2   3   4   5   6   7   8   9   10   >