Mike Fedyk [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
I was thinking of having support in the buildd to fetch source, check
a local patch archive for fixes, patch source, build package, add
patch to each debs /usr/share/doc/package/.
Would that satisfy the GPL or other DFSG
On Mon, Mar 21, 2005 at 12:35:28AM +0100, Wouter Verhelst wrote:
On Fri, Mar 18, 2005 at 11:43:48PM -0800, Steve Langasek wrote:
the more or less aspect of the urgency is relevant here. We
obviously have a system for classifying the severity of bugs in
packages, and it's possible to relate
* Wouter Verhelst ([EMAIL PROTECTED]) [050321 00:25]:
On Thu, Mar 17, 2005 at 10:40:43AM +0100, Andreas Barth wrote:
If we don't wait for an arch, it gets out-of-sync quite soon, and due to
e.g. legal requirements, we can't release that arch. (In other words, if
an arch is too long ignored
Andreas Barth wrote:
* Wouter Verhelst ([EMAIL PROTECTED]) [050321 00:25]:
On Thu, Mar 17, 2005 at 10:40:43AM +0100, Andreas Barth wrote:
If we don't wait for an arch, it gets out-of-sync quite soon, and due to
e.g. legal requirements, we can't release that arch. (In other words, if
an
Mike Fedyk [EMAIL PROTECTED] writes:
Andreas Barth wrote:
* Wouter Verhelst ([EMAIL PROTECTED]) [050321 00:25]:
On Thu, Mar 17, 2005 at 10:40:43AM +0100, Andreas Barth wrote:
If we don't wait for an arch, it gets out-of-sync quite soon, and due to
e.g. legal requirements, we can't release
Goswin von Brederlow wrote:
Mike Fedyk [EMAIL PROTECTED] writes:
Andreas Barth wrote:
* Wouter Verhelst ([EMAIL PROTECTED]) [050321 00:25]:
On Thu, Mar 17, 2005 at 10:40:43AM +0100, Andreas Barth wrote:
If we
On Thu, Mar 17, 2005 at 10:40:43AM +0100, Andreas Barth wrote:
If we don't wait for an arch, it gets out-of-sync quite soon, and due to
e.g. legal requirements, we can't release that arch. (In other words, if
an arch is too long ignored for testing, we should remove it, as we
can't release it
On Fri, Mar 18, 2005 at 11:43:48PM -0800, Steve Langasek wrote:
the more or less aspect of the urgency is relevant here. We
obviously have a system for classifying the severity of bugs in
packages, and it's possible to relate these bug severities to the
urgency field in uploads; even assuming
Wouter Verhelst [EMAIL PROTECTED] writes:
I don't think the possibility of something like that being abused is as
strange as you seem to imply. As proof of that statement, I faintly
remember someone doing a gratuitous source upload just to provoke the
buildds...
Of course, there was no abuse
On Tue, Mar 15, 2005 at 09:56:10AM +0100, Goswin von Brederlow wrote:
I would like to see some stats showing on how many days in the last
year an arch reached 0 needs-build. I highly doubt that any arch
managed to do it every day troughout the last year.
You know why goals are important?
Except the possibility to profit from the release team's efforts,
and to create an actually supported release. It is not reasonable
to believe a small porter team can do security updates for a
unstable snapshot when a task of similiar size already overloads
the stable security team.
No. As
Porters who have worked on getting an arch to REGUALR status are in a much
better position (demonstrated commitment, technical aptness and
experiencewise) to solve those problems than random-joe-developer.
I have no idea what you're trying to say here.
Always remember that the main
Peter 'p2' De Schrijver [EMAIL PROTECTED] writes:
Except the possibility to profit from the release team's efforts,
and to create an actually supported release. It is not reasonable
to believe a small porter team can do security updates for a
unstable snapshot when a task of similiar size
On Friday 18 March 2005 11:35, Peter 'p2' De Schrijver wrote:
Porters who have worked on getting an arch to REGUALR status are in a
much better position (demonstrated commitment, technical aptness and
experiencewise) to solve those problems than random-joe-developer.
I have no idea what
On Mon, Mar 14, 2005 at 12:19:15PM +0100, Wouter Verhelst wrote:
Op ma, 14-03-2005 te 00:10 -0800, schreef Steve Langasek:
Well, my objection is basically the same as Thomas's here -- all package
builds are *not* equally urgent,
Of course not, that is exactly my point.
But from the POV
* Mike Fedyk ([EMAIL PROTECTED]) [050316 20:55]:
Andreas Barth wrote:
If that happens for a too long period, we might consider such an
architecture to be too slow to keep up, and will eventually discuss
about kicking it out of the architectures we wait for testing migration
at all, or even
On Wed, 16 Mar 2005 14:44:34 +0100, Wouter Verhelst [EMAIL PROTECTED] wrote:
Op di, 15-03-2005 te 16:19 -0500, schreef Anthony DeRobertis:
Wouter Verhelst wrote:
| You misunderstood. I don't fight generic changes to the order; I just
| don't think it would be a good thing that any random
Andreas Barth wrote:
* Mike Fedyk ([EMAIL PROTECTED]) [050316 20:55]:
Andreas Barth wrote:
If that happens for a too long period, we might consider such an
architecture to be too slow to keep up, and will eventually discuss
about kicking it out of the architectures we wait for testing
Andreas Barth wrote:
* Mike Fedyk ([EMAIL PROTECTED]) [050316 20:55]:
Andreas Barth wrote:
If that happens for a too long period, we might consider such an
architecture to be too slow to keep up, and will eventually discuss
about kicking it out of the architectures
Andreas Barth [EMAIL PROTECTED] writes:
* Mike Fedyk ([EMAIL PROTECTED]) [050316 20:55]:
Andreas Barth wrote:
If that happens for a too long period, we might consider such an
architecture to be too slow to keep up, and will eventually discuss
about kicking it out of the architectures we wait
On Thursday 17 March 2005 20:22, Goswin von Brederlow wrote:
[very sensible suggestions removed]
Any problems with that?
Not with the procedure in itself. I just want to chip in, that it is (not
only) my opinion, that a REGULAR Debian release cannot allow delaying
security updates and there
On Thu, Mar 17, 2005 at 08:22:04PM +0100, Goswin von Brederlow wrote:
Andreas Barth [EMAIL PROTECTED] writes:
* Mike Fedyk ([EMAIL PROTECTED]) [050316 20:55]:
Andreas Barth wrote:
If that happens for a too long period, we might consider such an
architecture to be too slow to keep up,
* Mike Fedyk ([EMAIL PROTECTED]) [050317 19:30]:
Andreas Barth wrote:
If we don't wait for an arch, it gets out-of-sync quite soon, and due to
e.g. legal requirements, we can't release that arch. (In other words, if
an arch is too long ignored for testing, we should remove it, as we
can't
Peter 'p2' De Schrijver wrote:
[snip]
Why would a port release after the main release ?
Probably to fix up a few remaining arch-specific bugs.
Why, if debian doesn't
care about the non-release archs, would the porters even bother to
follow the release arch sources and not just release
On Thursday 17 March 2005 23:44, Peter 'p2' De Schrijver wrote:
On Thu, Mar 17, 2005 at 08:22:04PM +0100, Goswin von Brederlow wrote:
Andreas Barth [EMAIL PROTECTED] writes:
* Mike Fedyk ([EMAIL PROTECTED]) [050316 20:55]:
Andreas Barth wrote:
If that happens for a too long period, we
Op di, 15-03-2005 te 16:19 -0500, schreef Anthony DeRobertis:
Wouter Verhelst wrote:
| You misunderstood. I don't fight generic changes to the order; I just
| don't think it would be a good thing that any random developer could
| prioritize his pet package.
|
Any random developer already
Hello Wouter
On 2005-03-16 Wouter Verhelst wrote:
That's not to say that a request to prioritize a package is to be
ignored; however, the power of deciding which packages get built first
should be with those that actually build the packages, rather than with
those who want their packages to
Wouter Verhelst wrote:
That's not to say that a request to prioritize a package is to be
ignored; however, the power of deciding which packages get built first
should be with those that actually build the packages, rather than with
those who want their packages to be built. The former are expected
Hi, Matthew Palmer wrote:
I think the queue
needs to be as FIFO as possible for fairness and principle of least
surprise sake.
See my patch on d-d (also mailed to the ftpmasters), which inserts age in
queue (actually, timestamp of last status change, but that's
more-or-less equivalent) right
Andreas Barth wrote:
* Matthew Palmer ([EMAIL PROTECTED]) [050313 01:05]:
On Sat, Mar 12, 2005 at 03:12:12PM -0800, Steve Langasek wrote:
Er, packages *do* eventually get built; they just don't get built in any
kind of FIFO order.
Er,
Andreas Barth [EMAIL PROTECTED] writes:
* Goswin von Brederlow ([EMAIL PROTECTED]) [050314 15:35]:
Andreas Barth [EMAIL PROTECTED] writes:
* Hamish Moffatt ([EMAIL PROTECTED]) [050314 01:45]:
On Sun, Mar 13, 2005 at 11:16:56PM +0100, Andreas Barth wrote:
Our goal is that the queue gets
Wouter Verhelst [EMAIL PROTECTED] writes:
Op ma, 14-03-2005 te 17:59 +0100, schreef Goswin von Brederlow:
Wouter Verhelst [EMAIL PROTECTED] writes:
Op vr, 11-03-2005 te 19:14 -0800, schreef Steve Langasek:
The queue ordering is entirely automatic, and AIUI the queue(s) is (are)
sorted
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wouter Verhelst wrote:
| You misunderstood. I don't fight generic changes to the order; I just
| don't think it would be a good thing that any random developer could
| prioritize his pet package.
|
Any random developer already has root on X thousand
On Sun, Mar 13, 2005 at 11:36:39PM +0100, Wouter Verhelst wrote:
Op vr, 11-03-2005 te 19:14 -0800, schreef Steve Langasek:
The queue ordering is entirely automatic, and AIUI the queue(s) is (are)
sorted by:
- target suite
- previous compilation state (already built packages are
On Mon, Mar 14, 2005 at 11:43:54AM +1100, Hamish Moffatt wrote:
s390 is also rising steeply.
gcc problems and non-responding ftp-masters for the new buildd.
Bastian
--
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, Day of the Dove,
On Sun, Mar 13, 2005 at 11:07:29PM -0800, Thomas Bushnell BSG wrote:
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
On Sun, Mar 13, 2005 at 08:15:13PM -0800, Thomas Bushnell BSG wrote:
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
On Mon, Mar 14, 2005 at 07:37:56AM +0100, Ingo Juergensmann wrote:
On Mon, Mar 14, 2005 at 11:49:34AM +1100, Hamish Moffatt wrote:
Given how low hamradio (and the like) are prioritised, I suggest that we
get smarter about 'tesing' and omit some sections on some architectures.
Frankly
* Hamish Moffatt ([EMAIL PROTECTED]) [050314 01:45]:
On Sun, Mar 13, 2005 at 11:16:56PM +0100, Andreas Barth wrote:
Our goal is that the queue gets empty from time to time, and so,
priority shouldn't prevent a package from being built.
How often should the queue be emptied, or when will an
* Hamish Moffatt ([EMAIL PROTECTED]) [050314 01:55]:
On Mon, Mar 14, 2005 at 12:01:59AM +0100, Andreas Barth wrote:
It is a highly ordered list, more or less libs+base first, than devel,
shells,
perl, python. After that graphics, admin, utils. Just to look at the
other side of the
On Mon, Mar 14, 2005 at 08:50:15PM +1100, Hamish Moffatt wrote:
How about geda-gschem? Waiting on arm for a couple of weeks now.
Holding up migration of all of geda* on all architectures.
I couldn't work out where wanna-build CVS is hosted so I couldn't
actually check the order to see where
Op ma, 14-03-2005 te 00:10 -0800, schreef Steve Langasek:
Well, my objection is basically the same as Thomas's here -- all package
builds are *not* equally urgent,
Of course not, that is exactly my point.
But from the POV of a package's maintainer, all fixes are more or less
urgent. If some
On Mon, Mar 14, 2005 at 11:00:52AM +0100, Andreas Barth wrote:
* Hamish Moffatt ([EMAIL PROTECTED]) [050314 01:55]:
Given how low hamradio (and the like) are prioritised, I suggest that we
get smarter about 'tesing' and omit some sections on some architectures.
We won't omit some sections
Wouter Verhelst [EMAIL PROTECTED] writes:
Op za, 12-03-2005 te 15:01 -0800, schreef Thomas Bushnell BSG:
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
Andreas Barth [EMAIL PROTECTED] writes:
* Hamish Moffatt ([EMAIL PROTECTED]) [050314 01:45]:
On Sun, Mar 13, 2005 at 11:16:56PM +0100, Andreas Barth wrote:
Our goal is that the queue gets empty from time to time, and so,
priority shouldn't prevent a package from being built.
How often
On Mon, March 14, 2005 15:09, Goswin von Brederlow said:
People
should stop repeating the fiction then that just wait means your
package will eventually get built.
It usualy is. It might not be. And it can be an awfully long wait.
The last one is the problem. The first two not.
This could
[debian-release dropped]
Goswin von Brederlow [EMAIL PROTECTED] writes:
But do you notice when the same packages keep showing up at the end of
the queue for weeks? The queue can be as small as 1 package inbetween
and that 1 package could still never get build.
Just out of curiosity, what is
* Goswin von Brederlow ([EMAIL PROTECTED]) [050314 15:35]:
Andreas Barth [EMAIL PROTECTED] writes:
* Hamish Moffatt ([EMAIL PROTECTED]) [050314 01:45]:
On Sun, Mar 13, 2005 at 11:16:56PM +0100, Andreas Barth wrote:
Our goal is that the queue gets empty from time to time, and so,
On Monday 14 March 2005 15:31, Goswin von Brederlow wrote:
Andreas Barth [EMAIL PROTECTED] writes:
* Hamish Moffatt ([EMAIL PROTECTED]) [050314 01:45]:
On Sun, Mar 13, 2005 at 11:16:56PM +0100, Andreas Barth wrote:
Our goal is that the queue gets empty from time to time, and so,
Wouter Verhelst [EMAIL PROTECTED] writes:
Op vr, 11-03-2005 te 19:14 -0800, schreef Steve Langasek:
The queue ordering is entirely automatic, and AIUI the queue(s) is (are)
sorted by:
- target suite
- previous compilation state (already built packages are prioritized
above packages
Op ma, 14-03-2005 te 17:59 +0100, schreef Goswin von Brederlow:
Wouter Verhelst [EMAIL PROTECTED] writes:
Op vr, 11-03-2005 te 19:14 -0800, schreef Steve Langasek:
The queue ordering is entirely automatic, and AIUI the queue(s) is (are)
sorted by:
- target suite
- previous
On Sat, 12 Mar 2005 14:42:33 +0100, Ingo Juergensmann
[EMAIL PROTECTED] wrote:
Been there, done that.
The short answer: We don't want anyone else to play in our playground!
The longer answer: More machines mean more work for the the buildd admin.
Additional buildd admins for those archs are
[remove -release, nothing they can do about it]
Steve Langasek [EMAIL PROTECTED] writes:
On Sat, Mar 12, 2005 at 03:01:28PM -0800, Thomas Bushnell BSG wrote:
Goswin von Brederlow [EMAIL PROTECTED] writes:
Remember that the buildd queue is not FIFO at all. The queue has a
completly static
On Sun, Mar 13, 2005 at 05:19:25PM +0100, Goswin von Brederlow wrote:
And last I feel the sorting by name is actualy harmfull. That should
be exchanged with the time of upload, i.e. FIFO if the rest matches.
We all know FIFO isn't the best but it is simple, fair, predictable
and does not
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [050312 02:05]:
Since the all but one of the other arch buildd's have empty
needs-build queues, it is harmless to force them to execute a
recompile and costs no scarce resources. I did check this before
uploading.
Even in the case the buildds
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [050312 04:25]:
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
* Matthew Palmer ([EMAIL PROTECTED]) [050312 05:25]:
On Fri, Mar 11, 2005 at 07:14:35PM -0800, Steve Langasek wrote:
The queue ordering is entirely automatic, and AIUI the queue(s) is (are)
sorted by:
- target suite
- package priority
- package section
- package name
* Ingo Juergensmann ([EMAIL PROTECTED]) [050312 14:15]:
On Sat, Mar 12, 2005 at 02:06:24PM +0100, Martin Zobel-Helas wrote:
As it has been said earlier, the machines are back, but just need to
catch up. So just waiting might be the easiest thing to do.
More machines can catch up faster
On Sun, Mar 13, 2005 at 11:25:33PM +0100, Andreas Barth wrote:
More machines can catch up faster than few can do.
When one machine out of a dozen machines is unavailable, it has less impact
than one machine failure out of two machines, although the chances will
raise that a machine will
* Matthew Palmer ([EMAIL PROTECTED]) [050313 01:05]:
On Sat, Mar 12, 2005 at 03:12:12PM -0800, Steve Langasek wrote:
Er, packages *do* eventually get built; they just don't get built in any
kind of FIFO order.
Er, no. Unless there's some sort of aging process (not yet described in the
On Sun, Mar 13, 2005 at 11:17:52PM +0100, Andreas Barth wrote:
* Matthew Palmer ([EMAIL PROTECTED]) [050312 05:25]:
On Fri, Mar 11, 2005 at 07:14:35PM -0800, Steve Langasek wrote:
The queue ordering is entirely automatic, and AIUI the queue(s) is (are)
sorted by:
- target suite
On Mon, Mar 14, 2005 at 09:44:33AM +1100, Matthew Palmer wrote:
On Sun, Mar 13, 2005 at 11:17:52PM +0100, Andreas Barth wrote:
Because we want packages in base to be preferred, as well as packages in
libs.
I think I slightly misunderstood the ordering by section bit -- I was
assuming an
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 incentives
* Andreas Barth ([EMAIL PROTECTED]) [050313 23:15]:
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [050312 02:05]:
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
of guesswork.
The ordering applied is (in
* Matthew Palmer ([EMAIL PROTECTED]) [050313 23:50]:
I think I slightly misunderstood the ordering by section bit -- I was
assuming an alphabetical ordering by section. So once base and libs have
had their priority building, what's the ordering after that? Alphabetical
by section, or does it
On Sun, Mar 13, 2005 at 11:16:56PM +0100, Andreas Barth wrote:
Our goal is that the queue gets empty from time to time, and so,
priority shouldn't prevent a package from being built.
How often should the queue be emptied, or when will an architecture be
declarared not-keeping-up?
According to
On Mon, Mar 14, 2005 at 12:01:59AM +0100, Andreas Barth wrote:
It is a highly ordered list, more or less libs+base first, than devel, shells,
perl, python. After that graphics, admin, utils. Just to look at the
other side of the sorting order, at the end of the list is hamradio,
non-US and
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
On Mon, Mar 14, 2005 at 11:49:34AM +1100, Hamish Moffatt wrote:
Given how low hamradio (and the like) are prioritised, I suggest that we
get smarter about 'tesing' and omit some sections on some architectures.
Frankly there are not likely to be any users for hamradio on s390, mips*
arm, or
Op za, 12-03-2005 te 16:24 -0800, schreef Thomas Bushnell BSG:
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
Op za, 12-03-2005 te 15:01 -0800, schreef Thomas Bushnell BSG:
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
Op za, 12-03-2005 te 15:19 +1100, schreef Matthew Palmer:
I'm trying to work out why package *section* matters at all.
This is simply an attempt to avoid as much
needs-build-building-dep-wait cycles as possible; packages that are
usually build-dependencies are built before packages that are
Op vr, 11-03-2005 te 17:03 -0800, schreef Thomas Bushnell BSG:
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
Op vr, 11-03-2005 te 19:14 -0800, schreef Steve Langasek:
The queue ordering is entirely automatic, and AIUI the queue(s) is (are)
sorted by:
- target suite
- previous compilation state (already built packages are prioritized
above packages never built for the target architecture)
-
Op za, 12-03-2005 te 21:12 -0800, schreef Thomas Bushnell BSG:
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
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 the length
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 (usually
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
[please don't cc: me on this thread, one copy is plenty, thanks; and
please don't cc: debian-release unless there's a specific reason it's
on-topic there, which explaining wanna-build is not. ;)]
On Sun, Mar 13, 2005 at 11:30:45PM +0100, Wouter Verhelst wrote:
Op vr, 11-03-2005 te 17:03 -0800,
On Fri, Mar 11, 2005 at 09:03:16PM -0800, Steve Langasek wrote:
On Sat, Mar 12, 2005 at 03:19:23PM +1100, Matthew Palmer wrote:
I'm trying to work out why package *section* matters at all. Package name
is a bit odd, too, but including the section in there is just totally
whack.
Hi Hamish,
On Saturday, 12 Mar 2005, you wrote:
Is there anything that can be done to help with arm/mipsel?
ironic
Not uploading any new packages *g*
/ironic
As it has been said earlier, the machines are back, but just need to
catch up. So just waiting might be the easiest thing to do.
On Sat, Mar 12, 2005 at 02:06:24PM +0100, Martin Zobel-Helas wrote:
As it has been said earlier, the machines are back, but just need to
catch up. So just waiting might be the easiest thing to do.
More machines can catch up faster than few can do.
When one machine out of a dozen machines is
Hi Ingo,
On Saturday, 12 Mar 2005, you wrote:
On Sat, Mar 12, 2005 at 02:06:24PM +0100, Martin Zobel-Helas wrote:
As it has been said earlier, the machines are back, but just need to
catch up. So just waiting might be the easiest thing to do.
More machines can catch up faster than few
On Sat, Mar 12, 2005 at 02:26:43PM +0100, Martin Zobel-Helas wrote:
As it has been said earlier, the machines are back, but just need to
catch up. So just waiting might be the easiest thing to do.
More machines can catch up faster than few can do.
When one machine out of a dozen
Steve Langasek [EMAIL PROTECTED] writes:
On Sat, Mar 12, 2005 at 03:19:23PM +1100, Matthew Palmer wrote:
[Probably going a bit off track for -release; MFT to -devel]
On Fri, Mar 11, 2005 at 07:14:35PM -0800, Steve Langasek wrote:
The queue ordering is entirely automatic, and AIUI the
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 news
On Sat, Mar 12, 2005 at 03:01:28PM -0800, Thomas Bushnell BSG wrote:
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.
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 be
On Sat, Mar 12, 2005 at 03:12:12PM -0800, Steve Langasek wrote:
On Sat, Mar 12, 2005 at 03:01:28PM -0800, Thomas Bushnell BSG wrote:
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
On Sat, Mar 12, 2005 at 02:06:24PM +0100, Martin Zobel-Helas wrote:
Hi Hamish,
On Saturday, 12 Mar 2005, you wrote:
Is there anything that can be done to help with arm/mipsel?
As it has been said earlier, the machines are back, but just need to
catch up. So just waiting might be the
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
On Sat, Mar 12, 2005 at 04:24:35PM -0800, Thomas Bushnell BSG wrote:
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
On Sun, Mar 13, 2005 at 11:43:41AM +1100, Matthew Palmer wrote:
On Sat, Mar 12, 2005 at 04:24:35PM -0800, Thomas Bushnell BSG wrote:
What are these relatively effective workarounds?
Not being a buildd admin, I have no idea as to the specifics, but I infer
the existence of these workarounds
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,
Changelog entry from a package that has just arrived in incoming:
gnucash (1.8.10-8) unstable; urgency=high
.
* high urgency upload because the fix for critical bug 291632 didn't get
into testing because of recompilation bugs, those later fixes were
uploaded with urgency low, and
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 for
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
of guesswork.
You were *told*[1] to wait. Do not fall back to guesswork when someone
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
of guesswork.
You were *told*[1]
On Fri, Mar 11, 2005 at 05:03:55PM -0800, Thomas Bushnell BSG wrote:
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
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 urgency
as
1 - 100 of 103 matches
Mail list logo
