Re: StrongARM tactics

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

Re: StrongARM tactics

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 bui

Re: StrongARM tactics

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 bui

Re: StrongARM tactics

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

Re: Sparc build failure analysis (was Re: StrongARM tactics)

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 bu

Re: Sparc build failure analysis (was Re: StrongARM tactics)

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 a

Re: Sparc build failure analysis (was Re: StrongARM tactics)

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 > > p

Re: Sparc build failure analysis (was Re: StrongARM tactics)

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 > convenien

Re: Sparc build failure analysis (was Re: StrongARM tactics)

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

Re: Sparc build failure analysis (was Re: StrongARM tactics)

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? S

Re: Sparc build failure analysis (was Re: StrongARM tactics)

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

Sparc build failure analysis (was Re: StrongARM tactics)

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 acces

Re: StrongARM tactics

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: > >> >> > Th

Re: StrongARM tactics

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: > >> >> +

Re: StrongARM tactics

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 >> > >> > A

Re: StrongARM tactics

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)

Re: StrongARM tactics

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

Re: StrongARM tactics

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 fo

Re: StrongARM tactics

2005/12/8, Goswin von Brederlow <[EMAIL PROTECTED]>: Anthony Towns 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 @ bui

Re: buildd administration [was Re: StrongARM tactics]

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

Re: StrongARM tactics

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# >> >>

Re: buildd administration [was Re: StrongARM tactics]

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, J

Re: buildd administration [was Re: StrongARM tactics]

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 enou

buildd administration [was Re: StrongARM tactics]

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

Re: StrongARM tactics

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 it

Re: StrongARM tactics

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 tha

Re: StrongARM tactics

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

Re: StrongARM tactics

[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 th

Re: StrongARM tactics

Anthony Towns 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 the issues over >

Re: StrongARM tactics

On Wed, Dec 07, 2005 at 07:51:20PM -0600, Manoj Srivastava wrote: > On Wed, 7 Dec 2005 23:46:07 +1000, Anthony Towns > 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

Re: StrongARM tactics

Manoj Srivastava <[EMAIL PROTECTED]> writes: > On Wed, 7 Dec 2005 23:46:07 +1000, Anthony Towns > 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 i

Re: StrongARM tactics

On Wed, 7 Dec 2005 23:46:07 +1000, Anthony Towns 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 you an immediate

Re: StrongARM tactics

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

Re: StrongARM tactics

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

Re: StrongARM tactics

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 [EMAI

Re: StrongARM tactics

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 demonst

Re: StrongARM tactics

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 i38

Re: StrongARM tactics

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 t

Re: StrongARM tactics

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 figurin

Re: StrongARM tactics

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

Re: StrongARM tactics

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

Re: StrongARM tactics

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

Re: StrongARM tactics

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..

Re: StrongARM tactics

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

Re: StrongARM tactics

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 am

Re: StrongARM tactics

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 > > respon

Re: StrongARM tactics

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 > > >

Re: StrongARM tactics

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 does

Re: StrongARM tactics

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

Re: StrongARM tactics

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 (

Re: StrongARM tactics

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 libc

Re: StrongARM tactics

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 obv

Re: StrongARM tactics

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

Re: StrongARM tactics

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) - d

Re: StrongARM tactics

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) Ju

Re: StrongARM tactics

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

Re: StrongARM tactics

> 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 [EMAI

Re: StrongARM tactics

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

Re: StrongARM tactics

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 >

Re: StrongARM tactics

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 >

Re: StrongARM tactics

* 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 p

Re: StrongARM tactics

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].