On Thu, Dec 08, 2005 at 02:03:27AM -0800, Steve Langasek wrote:
On Wed, Dec 07, 2005 at 04:48:24PM -0600, Bill Allombert wrote:
Which is great as a statement of principle, but it doesn't seem to offer
much as a practical recommendation; you don't get to be a buildd maintainer
by telling the
Wouter Verhelst wrote:
That's still a bit of time wasted, but it's not really bad. The really
problematic version is when a package is downloaded, build-deps are
installed, and /then/ sbuild figures out that some version isn't recent
enough.
According to the intersection of the debcheck
Wouter Verhelst wrote:
That's still a bit of time wasted, but it's not really bad. The really
problematic version is when a package is downloaded, build-deps are
installed, and /then/ sbuild figures out that some version isn't recent
enough.
According to the intersection of the debcheck
On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote:
I said that deciding which packages should belong in P-a-s is porter work;
as is filing bugs on failed packages that shouldn't, providing patches, and
doing porter NMUs if necessary.
Again: what can I do with such a list? See the
On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote:
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes:
On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote:
I can do the analyzing, but what should I do with the results?
[EMAIL PROTECTED] seems to be a black hole.
On Sun, Dec 11, 2005 at 12:35:26AM -0800, Steve Langasek wrote:
On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote:
FAILED
But FAILED is an advisory state anyway; it doesn't directly benefit the
port, at all, to have the package listed as Failed, this is just a
convenience for
On Sun, Dec 11, 2005 at 02:38:35PM +0100, Jeroen van Wolffelaar wrote:
On Sun, Dec 11, 2005 at 12:35:26AM -0800, Steve Langasek wrote:
On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote:
FAILED
But FAILED is an advisory state anyway; it doesn't directly benefit the
port, at
On Sun, Dec 11, 2005 at 05:55:23AM -0800, Steve Langasek wrote:
Indeed, for practical buildd maintainance purposes, the distinction is
not that important -- though 'Failed' is known to not benefit of a
requeue, while 'Building:Maybe-Failed' might or might not, it's unkown,
most archs
On Sun, Dec 11, 2005 at 05:30:24AM -0500, Kevin Mark wrote:
has anyone every considered a check in the buildd infrastructure to
alert someone (buildd admin and/or others) if a build is taking too long
(eg openoffice usually takes between 2-3 hours to build and the current
build has been
On Fri, Dec 09, 2005 at 04:17:28PM +0100, Goswin von Brederlow wrote:
I fail to see how downloading the source, extracting the source,
downloading and installing all Build-Depends, seeing there is nothing
to do and cleaning it all up again is doing anything but waste
valuable time. (Or does
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes:
On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote:
I can do the analyzing, but what should I do with the results?
[EMAIL PROTECTED] seems to be a black hole. You'll need to find
someone willing to communicate with access to the
On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote:
numactl
only supports i386 amd64 ia64
appears to assume intel-style stuff, would need major redesign
for other architectures
There's nothing intel-specific in here, rather it assumes NUMA support
in the kernel.
Steve Langasek [EMAIL PROTECTED] writes:
On Thu, Dec 08, 2005 at 01:52:51PM +0100, Goswin von Brederlow wrote:
Steve Langasek [EMAIL PROTECTED] writes:
On Thu, Dec 08, 2005 at 10:41:51AM +0100, Goswin von Brederlow wrote:
[EMAIL PROTECTED] (Aaron M. Ucko) writes:
Thomas Viehmann [EMAIL
Anthony Towns aj@azure.humbug.org.au writes:
On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote:
I can do the analyzing, but what should I do with the results?
Put them on a webpage so anyone can see them, and if you don't find
someone who'll give you an immediate response, track
[EMAIL PROTECTED] (Aaron M. Ucko) writes:
Thomas Viehmann [EMAIL PROTECTED] writes:
+pcsx: i386 # i386
assembly
AFAICT, this is only because its Linux/Makefile forces CPU to ix86
unconditionally.
Write patch. At a minimum the package
Bill Allombert [EMAIL PROTECTED] writes:
Making buildd admin a purely administrative task while porters are
not even trusted to do a binary upload is not going to work because you
will never find volunteers accepting to work under theses terms.
Thanks. My sentiment exactly.
MfG
On Wed, Dec 07, 2005 at 04:48:24PM -0600, Bill Allombert wrote:
On Tue, Dec 06, 2005 at 01:14:00AM -0800, Steve Langasek wrote:
Saying that's the buildd admin's job about tasks that don't *need* to be
done by the buildd admin is a pretty effective way of encouraging the
problems that the
On Thu, Dec 08, 2005 at 10:41:51AM +0100, Goswin von Brederlow wrote:
[EMAIL PROTECTED] (Aaron M. Ucko) writes:
Thomas Viehmann [EMAIL PROTECTED] writes:
+pcsx: i386 #
i386 assembly
AFAICT, this is only because its
Le jeudi 08 décembre 2005 à 02:03 -0800, Steve Langasek a écrit :
Which translates here to:
1) Buildd admin should be people interested in supporting the port.
2) People that are going to support the port must get the responsibility.
Which is great as a statement of principle, but it
On Thu, Dec 08, 2005 at 11:40:17AM +0100, Josselin Mouette wrote:
As a result, no one can help with buildd maintenance as the current
buildd admins won't let anyone help them, however overloaded they can
be. They refuse to delegate any part of their powers because people
aren't skilled enough,
I don't know what's wrong but I think there is on principle, which
shouldn't be forgotten. Try to understand first and then to be
understood. I'd like to help, but may be I can't. Read Stephen Covey
books.
2005/12/8, Steve Langasek [EMAIL PROTECTED]:
On Thu, Dec 08, 2005 at 11:40:17AM +0100,
Steve Langasek [EMAIL PROTECTED] writes:
On Thu, Dec 08, 2005 at 10:41:51AM +0100, Goswin von Brederlow wrote:
[EMAIL PROTECTED] (Aaron M. Ucko) writes:
Thomas Viehmann [EMAIL PROTECTED] writes:
+pcsx: i386#
i386 assembly
Steve Langasek wrote:
Er, did you even *read* this thread? We got on the topic of buildds because
*someone refused to help diagnose build failures because they consider it the
buildd admin's job*.
Maybe it's not entirely impossible that the other subthread starting at
| Wonderful. Nice to
2005/12/8, Goswin von Brederlow [EMAIL PROTECTED]:
Anthony Towns aj@azure.humbug.org.au writes:What is required is abuildd-give-back package_version(or whatever you called the alias for wanna-build --give-back).
Following this train of thought, wouldn't it be reasonable to have a control @
On Thursday 08 December 2005 04:41 am, you wrote:
[EMAIL PROTECTED] (Aaron M. Ucko) writes:
Thomas Viehmann [EMAIL PROTECTED] writes:
+pcsx: i386 #
i386 assembly
AFAICT, this is only because its Linux/Makefile forces CPU to
Ryan Schultz [EMAIL PROTECTED] writes:
PCSX 1.6 does not compile with GCC4 when the ix86 flag is not specified, even
on i386. I don't know about amd64, but my other partially-ASM (using NASM
like PCSX) package (libopenspc) will not build on amd64, so I'm assuming that
the same is true here
On Thursday 08 December 2005 01:44 pm, Aaron M. Ucko wrote:
Ryan Schultz [EMAIL PROTECTED] writes:
PCSX 1.6 does not compile with GCC4 when the ix86 flag is not specified,
even on i386. I don't know about amd64, but my other partially-ASM (using
NASM like PCSX) package (libopenspc) will not
Ryan Schultz [EMAIL PROTECTED] writes:
On Thursday 08 December 2005 04:41 am, you wrote:
[EMAIL PROTECTED] (Aaron M. Ucko) writes:
Thomas Viehmann [EMAIL PROTECTED] writes:
+pcsx: i386#
i386 assembly
AFAICT, this is only
On Thu, Dec 08, 2005 at 01:52:51PM +0100, Goswin von Brederlow wrote:
Steve Langasek [EMAIL PROTECTED] writes:
On Thu, Dec 08, 2005 at 10:41:51AM +0100, Goswin von Brederlow wrote:
[EMAIL PROTECTED] (Aaron M. Ucko) writes:
Thomas Viehmann [EMAIL PROTECTED] writes:
+pcsx: i386
On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote:
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes:
Um... no. This is *porter* work; one does not have to be a buildd admin to
analyze a build failure to see whether the package belongs in P-a-s, and
there's no reason that the
On Tue, Dec 06, 2005 at 02:33:34PM +0100, Thiemo Seufer wrote:
Steve Langasek wrote:
[snip]
-grub2: !hppa !ia64 m68k#
bootloader
+grub2: !hppa !ia64 !m68k !alpha !mips !mipsel !s390 !sparc #
bootloader for i386/powerpc [?]
On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote:
I can do the analyzing, but what should I do with the results?
Put them on a webpage so anyone can see them, and if you don't find
someone who'll give you an immediate response, track the issues over
time so you can trivially
Thomas Viehmann [EMAIL PROTECTED] writes:
+pcsx: i386# i386
assembly
AFAICT, this is only because its Linux/Makefile forces CPU to ix86
unconditionally.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL
On Tuesday 06 December 2005 05:51 am, Thomas Viehmann wrote:
+%libopenspc: i386 kfreebsd-i386
# i386 assembler
+%xmms-openspc: i386 kfreebsd-i386# i386
dependency (libopenspc)
+pcsx: i386
On Tue, Dec 06, 2005 at 01:14:00AM -0800, Steve Langasek wrote:
Saying that's the buildd admin's job about tasks that don't *need* to be
done by the buildd admin is a pretty effective way of encouraging the
problems that the Vancouver proposal sought to address, where two or three
people end
On Wed, 7 Dec 2005 23:46:07 +1000, Anthony Towns aj@azure.humbug.org.au said:
On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote:
I can do the analyzing, but what should I do with the results?
Put them on a webpage so anyone can see them, and if you don't find
someone who'll give
Manoj Srivastava [EMAIL PROTECTED] writes:
On Wed, 7 Dec 2005 23:46:07 +1000, Anthony Towns aj@azure.humbug.org.au
said:
On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote:
I can do the analyzing, but what should I do with the results?
Put them on a webpage so anyone can see
On Wed, Dec 07, 2005 at 07:51:20PM -0600, Manoj Srivastava wrote:
On Wed, 7 Dec 2005 23:46:07 +1000, Anthony Towns aj@azure.humbug.org.au
said:
On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote:
I can do the analyzing, but what should I do with the results?
Put them on a
Kurt Roeckx wrote:
twinkle: requeue (probably libccrtp was stuck in NEW)
The problem is that libccrtp1-1.3-0 is still linked to
libcommoncpp2-1.3c2 instead of libcommoncpp2-1.3c2a.
Hm. Sorry.
wvstreams: Dep-Wait (libxplc0.3.13-dev) - dep in new queue, see #340696
xchm: retry (needed libchm-dev)
On Tue, Dec 06, 2005 at 09:02:23AM +0100, Thomas Viehmann wrote:
Kurt Roeckx wrote:
twinkle: requeue (probably libccrtp was stuck in NEW)
The problem is that libccrtp1-1.3-0 is still linked to
libcommoncpp2-1.3c2 instead of libcommoncpp2-1.3c2a.
Hm. Sorry.
wvstreams: Dep-Wait
Steve Langasek wrote:
[snip]
So those should get added to P-a-s instead.
Well, but that'd be something for the buildd-admin to collect.
(Or maintainers of the packages, but that doesn't seem to fashionable
nowadays...)
Um... no. This is *porter* work; one does not have to be a buildd
Hi,
[Steve's comments seem to suggest that patches to P-a-s might be OK, so
I'm CCing Lamont and Adam who seem to have done the last couple of
commits to P-a-s.]
Steve Langasek wrote:
Well, but that'd be something for the buildd-admin to collect.
(Or maintainers of the packages, but that doesn't
On Tue, Dec 06, 2005 at 11:03:40AM +0100, Thiemo Seufer wrote:
Steve Langasek wrote:
[snip]
So those should get added to P-a-s instead.
Well, but that'd be something for the buildd-admin to collect.
(Or maintainers of the packages, but that doesn't seem to fashionable
nowadays...)
On Tue, Dec 06, 2005 at 11:51:00AM +0100, Thomas Viehmann wrote:
Um... no. This is *porter* work; one does not have to be a buildd admin to
analyze a build failure to see whether the package belongs in P-a-s, and
there's no reason that the buildd admins alone should bear the
Hi Steve,
Steve Langasek wrote:
Ok. Here's some feedback on some that I either disagree with, or don't see
enough rationale for. (This is why, ideally, the process should involve the
porters and the maintainers...)
Thanks. Doesn't hurt do get educated...
+dfsbuild: i386 alpha powerpc amd64
On Tue, Dec 06, 2005 at 01:00:40PM +0100, Thomas Viehmann wrote:
For ree:
How portable is scaning /dev/mem between position 0xc and 0xf in
512 byte blocks for some magic number as a concept?
This will kernel oops on ARM platforms that don't have RAM starting at
physical address zero.
Thomas Viehmann wrote:
Hi Steve,
Steve Langasek wrote:
Ok. Here's some feedback on some that I either disagree with, or don't see
enough rationale for. (This is why, ideally, the process should involve the
porters and the maintainers...)
Thanks. Doesn't hurt do get educated...
Steve Langasek wrote:
[snip]
-grub2: !hppa !ia64 m68k #
bootloader
+grub2: !hppa !ia64 !m68k !alpha !mips !mipsel !s390 !sparc #
bootloader for i386/powerpc [?]
Is a P-a-s entry some sort of a final verdict? I don't think it makes
On Tue, Dec 06, 2005 at 11:51:00AM +0100, Thomas Viehmann wrote:
Hi,
hotkey-setup: might also work on amd64 ia64 (depends on dmidecode)
OTOH, maintainer usually seems to know what he's doing...
Also see #331280. Afaik, there is no reason this couldn't be
changed to work on
On Mon, Dec 05, 2005 at 06:22:29PM +, Vincent Sanders wrote:
Greetings,
However, we are in need of assistance! Recently ARM was separated
from testing as it is believed it was not keeping up. In fact, the ARM
buildds are generally keeping up well - the problem now is a large
pile of 131
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes:
Um... no. This is *porter* work; one does not have to be a buildd admin to
analyze a build failure to see whether the package belongs in P-a-s, and
there's no reason that the buildd admins alone should bear the
responsibility for figuring out
Vincent Sanders [EMAIL PROTECTED] writes:
However, we are in need of assistance! Recently ARM was separated
from testing as it is believed it was not keeping up. In fact, the ARM
buildds are generally keeping up well - the problem now is a large
pile of 131 maybe-failed packages [1]. To get
* Thomas Bushnell BSG [Mon, 05 Dec 2005 10:28:43 -0800]:
Well golly gee. When I sent mail to [EMAIL PROTECTED], saying
that packages had failed due to temporarily missing build
dependencies, it was apparently ignored for weeks. It took the
release manager's involvement to get the build
Adeodato Simó [EMAIL PROTECTED] writes:
* Thomas Bushnell BSG [Mon, 05 Dec 2005 10:28:43 -0800]:
Well golly gee. When I sent mail to [EMAIL PROTECTED], saying
that packages had failed due to temporarily missing build
dependencies, it was apparently ignored for weeks. It took the
release
This one time, at band camp, Thomas Bushnell BSG said:
Adeodato Simó [EMAIL PROTECTED] writes:
* Thomas Bushnell BSG [Mon, 05 Dec 2005 10:28:43 -0800]:
Well golly gee. When I sent mail to [EMAIL PROTECTED], saying
that packages had failed due to temporarily missing build
Stephen Gran [EMAIL PROTECTED] writes:
Instead, you could hold a grudge and complain. That would be in keeping
with the Debian tradition, after all.
Not really holding a grudge; the problem was only just resolved
yesterday. In a week, it would be forgotten. It was just ironic.
Note: I am
The buildd maintainer is one of the 'notoriously difficult to reach'
people in Debian. If you were interested in trying, contacting the
mailing list for the port is the obvious next step.
What can the people on such a mailing list do about buildd issues?
--
To UNSUBSCRIBE, email to [EMAIL
Hi,
Vincent Sanders wrote:
[1] http://buildd.debian.org/~jeroen/status/architecture.php?a=arm
taking a random (end of alphabet) sample from maybe-failed:
twinkle: requeue (probably libccrtp was stuck in NEW)
wvstreams: Dep-Wait (libxplc0.3.13-dev) - dep in new queue, see #340696
xchm: retry
On Mon, Dec 05, 2005 at 10:43:15PM +0100, Thomas Viehmann wrote:
Hi,
Vincent Sanders wrote:
[1] http://buildd.debian.org/~jeroen/status/architecture.php?a=arm
taking a random (end of alphabet) sample from maybe-failed:
twinkle: requeue (probably libccrtp was stuck in NEW)
Just try to
Thomas Viehmann wrote:
Hi,
Vincent Sanders wrote:
[1] http://buildd.debian.org/~jeroen/status/architecture.php?a=arm
taking a random (end of alphabet) sample from maybe-failed:
twinkle: requeue (probably libccrtp was stuck in NEW)
wvstreams: Dep-Wait (libxplc0.3.13-dev) - dep in new
Le lundi 05 décembre 2005 à 16:19 -0500, Clint Adams a écrit :
The buildd maintainer is one of the 'notoriously difficult to reach'
people in Debian. If you were interested in trying, contacting the
mailing list for the port is the obvious next step.
What can the people on such a mailing
Josselin Mouette [EMAIL PROTECTED] writes:
Le lundi 05 décembre 2005 à 16:19 -0500, Clint Adams a écrit :
The buildd maintainer is one of the 'notoriously difficult to reach'
people in Debian. If you were interested in trying, contacting the
mailing list for the port is the obvious next
62 matches
Mail list logo
