Re: StrongARM tactics

[Bill Allombert]

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 current folks "you aren't taking the right amount of pleasure
> in this -- better let me do it", you get there by working with the current

You wrote in this list in <[EMAIL PROTECTED]>:

  Clone yourself and make yourself a slave to the buildds for 7 or 8
  architectures, so that the release team doesn't have to.  Neither the
  release team nor the FTP team is interested in being responsible for keeping
  all of these architectures afloat.

Given the intersection of {FTP team} and {buildd admins} is not empty
so this seems more an issue than just 'right amount of pleasure'.

In fact when a volunteer state they are no more interested to perform
a task, it is better to assign the tack to someone else before the
volunteer stop doing it, either progressively or at once.

In a thousand people project we simply cannot ignore social issue.

> folks and building a relationship with them and showing that you know what
> you're doing.  Sorry, with a project that's a thousand strong, if they *do*
> care about the task, not too many people are going to turn it over to
> someone they don't know without first assuring themselves that they can
> handle it; and note that I never suggested the current buildd maintainers
> don't *care* about the ports they're helping with, they just don't have
> unlimited amounts of time to spend on single-handedly ensuring that ports
> keep up.

In a project a thousand strong, surely finding someone that can handle
it should not be too hard ?

Probably the best way for someone to show capacities would be to act as
an unofficial buildd admin. This can work nicely for new,
not-yet-official ports that need an unofficial buildd anyway,  but it is
rather unconvenient for official ports because this means to duplicate
needlessly the buildd infrastructure. This might even be taken in bad
part.

> BTW, I have no reason to believe that buildd maintenance in general is any
> more exciting or intrinsically rewarding than filing bugs on failed
> packages (and providing fixes for the same); so if people are going to balk
> at the latter task even though this is an area of porting that definitely
> (in some cases desperately) needs attention, what reason is there to think
> they're well-suited to being buildd maintainers either?

I have no reason to believe either, why should have ?

I certainly did not intent to make any claims that buildd maintenance
was exciting or rewarding, only that it was a necessary responsibity
for a port. 

> > 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.
> 
> It seems like you're assuming that "buildd admins" and "porters" are two
> non-overlapping sets.  On 6 of 11 architectures, at least one buildd admin
> is also a porter for that arch under the release requalification guidelines;
> on 7 of 11 architectures, at least one of the porters has wanna-build access
> for that arch.

Which means that on 5 architectures, the buildd admin is not interested
enough to be a porter.  

> So it's certainly not the case that no porters are trusted to do binNMUs.

So there are 4 architectures where no porters have wanna-build access ?
For theses architectures, no porters are trusted to do binNMUs. What
happens on the other platforms is irrelevant to them, that only make them
at a disanvantage;

> If what you're arguing is that *all* porters should have wanna-build/buildd
> access (which is the best way to do binNMUs so that we get log files and
> consistent build envs), then I disagree.  There's a heck of a lot of other
> work that porters would be better off spending their time on -- like, for
> instance, the unresolved build failures of perl on arm.  I mean, it's
> possible you're right that porters are going to feel slighted if they don't
> have buildd access; but shouldn't porters' primary motivation be to make
> sure etch releases with a kick-ass Debian port for their architecture of
> choice?  Should this really be about who holds the keys to the buildds?
> Isn't being a Debian porter already something to take pride in?

I did not mention motivation either. The issue is one of responsibility not
motivation.

I am only arguing that is it inefficient to have buildd admins that are
not porters. Reasonnable people avoid working under inefficient schemes
and move to other venues. Debian is so large that it is uncommon to be
motivated to do only one thing.

> All I really see here is that you've asserted that other (unspecified)
> porters should be given access to buildds that they don't necessarily want
> or need.  Is this t

Re: StrongARM tactics

[Thomas Viehmann]

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 build-depends test and
m86k's Needs-Build [1], this will likely affect gnomesword bibletime
knoda asterisk k3d loop-aes-modules or are these already caught by the
buildds?

Inaccuracies are caused (at least) by debcheck only using packages
unstable (not incoming etc.) and not treating conflicts.
The latter also leads to the list of packages that could be retried
(i.e. failed for insatisfiable dependencies but this isn't the case
anymore) [2] to be not useful yet, as gnucash shows.

Kind regards

T.

1. http://people.debian.org/~tviehmann/fail-predictions.txt
   (NOT automatically updated though, scripts in my ~ on p.d.o)
2. http://people.debian.org/~tviehmann/couldretry.txt
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Thomas Viehmann]

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 build-depends test and
m86k's Needs-Build [1], this will likely affect gnomesword bibletime
knoda asterisk k3d loop-aes-modules or are these already caught by the
buildds?

Inaccuracies are caused (at least) by debcheck only using packages
unstable (not incoming etc.) and not treating conflicts.
The latter also leads to the list of packages that could be retried
(i.e. failed for insatisfiable dependencies but this isn't the case
anymore) [2] to be not useful yet, see e.g. gnucash.

Kind regards

T.

1. http://people.debian.org/~tviehmann/fail-predictions.txt
   (NOT automatically updated though, scripts in my ~ on p.d.o)
2. http://people.debian.org/~tviehmann/couldretry.txt
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Wouter Verhelst]

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 sbuild fail before the Build-Depends?

Yes. A typical output is something like:

Automatic build of _ on  by sbuild/ 
Build started at -
**
Checking available source versions...
Fetching source files...
Reading Package Lists...
Building Dependency Tree...
Need to get 192kB of source archives.
Get:1 http://incoming.debian.org(dsc) [586B]
Get:2 http://incoming.debian.org(tar) [154kB]
Get:3 http://incoming.debian.org(diff) [37.8kB]
: not in architecture list: i386 -- skipping
**
Finished at -
Build needed 00:00:00, 0k disk space

for a package that has Architecture: i386

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.

> Scratch those then.)

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Ingo Juergensmann]

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 building for 10 hours+). Something like a database entry
> or a database of either previous build times or last build time. As a
> way to not have a buildd tied up with an obvious build issue and thus
> allow the issue to be address sooner thus alowing more buildd
> throughput.

You mean something like the stats on http://www.buildd.net/ - for example:
http://buildd.net/cgi/ptracker.cgi?unstable_pkg=aptitude&searchtype=m68k

I intend to give some sort of "build is overdue" warning when I have enough
data to calculate on when a build is overdue ;)

-- 
Ciao...//Fon: 0381-2744150 
  Ingo   \X/ SIP: [EMAIL PROTECTED]

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc


signature.asc
Description: Digital signature

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

[Kurt Roeckx]

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 should have enough surplus buildd power that retrying
> > everything once in a while doesn't hurt.
> 
> > The major benefit is though to make it apparant for porters what to look
> > into, without all the 'noise' in between of maybe-transient failures.
> > One could also make sure that the FTBFS bugs are tagged (user-tagged)
> > with [EMAIL PROTECTED] (etc) for example (or [EMAIL PROTECTED] There
> > doesn't exist a [EMAIL PROTECTED] for example...), so that one can get a
> > nice overview of all the porting bugs. It'd make sense to synchronise
> > this across all architectures, so that it is consistent.
> 
> http://lists.debian.org/debian-alpha/2005/12/msg00028.html

I have a long list of bug affecting amd64, but I haven't started
with usertags for it.

The (FTBFS) bugs I encouter (as buildd admin) are:
- General bugs affecting all arches.
- General bugs affecting 64 bit arches.
- Bugs affecting some arches (like not using -fPIC)
- Bugs only affecting amd64.

And the later really is the minorty of the problems.

Note that this does not cover runtime problems or something like
that, but they're very simular.

Do we need to have a special usertag for the first kind?  This is
basicly something everybody can look at.  The only reason I can think
of that it requires some tag is that it's better then looking at
those that don't have a tag.

So, I'm open for suggestions on how to tag the first 3 of those.


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Steve Langasek]

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 all, to have the package listed as "Failed", this is just a
> > convenience for folks sifting through the build failures (like the rarely
> > used "confirmed" BTS tag is for maintainers).  In the long-term, one of two
> > things needs to happen with each of these build failures: the package needs
> > to be added to P-a-s so the arch no longer tries to build it, or the package
> > needs to be fixed -- via porter NMU if necessary.

> > So as you have the list of these packages, as a porter you can proceed with
> > figuring out which of the two categories each falls into, and take the
> > necessary action without worrying about the "Failed" state, yes?

> 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 should have enough surplus buildd power that retrying
> everything once in a while doesn't hurt.

> The major benefit is though to make it apparant for porters what to look
> into, without all the 'noise' in between of maybe-transient failures.
> One could also make sure that the FTBFS bugs are tagged (user-tagged)
> with [EMAIL PROTECTED] (etc) for example (or [EMAIL PROTECTED] There
> doesn't exist a [EMAIL PROTECTED] for example...), so that one can get a
> nice overview of all the porting bugs. It'd make sense to synchronise
> this across all architectures, so that it is consistent.

http://lists.debian.org/debian-alpha/2005/12/msg00028.html

Our porters can beat up your porters.

;)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

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

[Jeroen van Wolffelaar]

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 folks sifting through the build failures (like the rarely
> used "confirmed" BTS tag is for maintainers).  In the long-term, one of two
> things needs to happen with each of these build failures: the package needs
> to be added to P-a-s so the arch no longer tries to build it, or the package
> needs to be fixed -- via porter NMU if necessary.
> 
> So as you have the list of these packages, as a porter you can proceed with
> figuring out which of the two categories each falls into, and take the
> necessary action without worrying about the "Failed" state, yes?

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 should have enough surplus buildd power that retrying
everything once in a while doesn't hurt.

The major benefit is though to make it apparant for porters what to look
into, without all the 'noise' in between of maybe-transient failures.
One could also make sure that the FTBFS bugs are tagged (user-tagged)
with [EMAIL PROTECTED] (etc) for example (or [EMAIL PROTECTED] There
doesn't exist a [EMAIL PROTECTED] for example...), so that one can get a
nice overview of all the porting bugs. It'd make sense to synchronise
this across all architectures, so that it is consistent.

If that is done, and there would be some way for porters to easily tag
the build failures themselves on what bug they correspond with, or not,
and especially, what failures are new and are yet to be tagged, there'd
be an easy and clear workflow for porters to work on failures. I don't
think there has really been such a defined porter workflow for build
failures, and nobody so far has built/defined one to the best of my
knowledge. And this touches one of the core points Vancouver is intended
to solve: *porters* need to work on *porting*, and help actively and
actually fixing porting issues in the archive. If creating a better
interface for people to work on this is a part of achieving it, so be
it. I'll see whether I can hack up something together for this,
extending buildd.d.o/~jeroen/status.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Kevin Mark]

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.  You'll need to find
> >> someone willing to communicate with access to the buildd queues before
> >> the porters can do anything.
> >
> >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 list below.
> 
> >If the porters do this effectively, there's really not much need at all for
> >telling the buildd maintainers about transient build failures, because
> >they'll be pretty obvious (and account for the majority of failures, as it
> >should be).
> 
> Just because it is obvious does not mean that the buildd adminstrator
> does the correct thing.  kq was "uploaded" 51 days ago, trustedqsl was
> "uploaded" 25 days ago, neither is in the archive.
> 
> openoffice.org has been "building" for 8 days, it only took 57 hours
> on my slower than any current sparc buildd pbuilder.  kexi has been
> "building" for 6 days, it took less than 2 hours.
Hi Blars et al.,
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 building for 10 hours+). Something like a database entry
or a database of either previous build times or last build time. As a
way to not have a buildd tied up with an obvious build issue and thus
allow the issue to be address sooner thus alowing more buildd
throughput. I'd help but I have neither the skill nor the access to
buildd infrastrure (as I'm not a DD or a buildd admin) but try to give
ideas that I feel are helpful.
Anyway, hope those buildd (and thier admins) are humming along smoothly!
Cheers,
Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!
  `$' $' 
   $  $  _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$ $ $$g$ $ $ $ ,$P""  $ $$
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$
 `Y$$P'$. `YP $$$P"' ,$. `Y$$P'$ $.  ,$.


signature.asc
Description: Digital signature

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

[Steve Langasek]

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

Changes to the P-a-s list should be sent to the contacts listed at the top
of this file (http://buildd.debian.org/quinn-diff/Packages-arch-specific).

> >If the porters do this effectively, there's really not much need at all for
> >telling the buildd maintainers about transient build failures, because
> >they'll be pretty obvious (and account for the majority of failures, as it
> >should be).

> Just because it is obvious does not mean that the buildd adminstrator
> does the correct thing.  kq was "uploaded" 51 days ago, trustedqsl was
> "uploaded" 25 days ago, neither is in the archive.

Well, release-wise, the practical impact here is quite small; for packages
that aren't needed in order to fix RC bugs, for my part I'm quite content to
have the buildd admins manage such give-backs on their own schedule.  Being
more responsive to give-back requests may generally make people happier, but
there's also a context-switch cost associated with such status polling; in
the non-RC cases, does it really hurt anything to *not* have these packages
given back quickly?  If not, isn't a better solution for people to be
understanding of this?

kq and pointless given back now, btw (not trustedqsl, which is "Failed"
rather than "Uploaded").

> openoffice.org has been "building" for 8 days, it only took 57 hours
> on my slower than any current sparc buildd pbuilder.  kexi has been
> "building" for 6 days, it took less than 2 hours.

openoffice.org is listed as "building" because the buildd crashed mid-build.
Ryan Murray and the package maintainer discussed this on IRC when it
happened; it was not immediately given back because of concerns over whether
the build might take down a *second* buildd while there was still a
significant backlog due to the c2a transition.  No, this isn't perfectly
transparent; but yes, it should be acceptable.  There's almost never a
reason to fret over builds-gone-missing for at least, say, a week and a
half, which is about how long it would take for the package to be eligible
for testing.  In OOo's case, try adding another couple of weeks to that for
the current c2a transition that it blocks on...

> The sparc buildd mainainter has in the past left transient build
> failures lie for over 6 months.  For the past year he's been requeuing
> all maybe-failed packages every 1-3 months.

Well, a) we now have auto-dep-wait, so this is even less of a problem now
than it might have been before; b) in the general case, it's not much of a
problem.

> REQUEUE
> qterm   0.4.0pre3-2+b1  342381

Consider that this was a bug in a *toolchain* package, so more than a simple
give-back is required:  gcc-4.0 needs to be upgraded on the buildds for this
to work.  Given that this was caused by a stray \ in the source that didn't
belong, it would be advisable for the package maintainer to defensively
correct this as well.

> DEP-WAIT
> galago-sharp  libmono-dev
> dmraidlibklibc-dev
> motv  ibzvbi0 (= 0.2.17-3.0.1)
> qmailadminvpopmail-bin
> wvstreams libxplc0.3.13-dev
> sylpheed-claws-gtk2   libclamv-dev
> digikam   libartsl-dev (>=1.4.2)
> tulip mesa-common-dev (= 6.2.1-7)
> liferea   libdbus-glib-1-dev
> kwave kdemultimedia-dev
> ivtools   libace-dev
> fwbuilder libfwbuilder-dev
> gtksharp2 libmono-dev
> libavglibavcodeccvs-dev
> gnucash   slib
> memepack  r-base-dev
> r-cran-bayesm r-base-dev

Um, at least some of these dep-waits are completely wrong; r-base-dev and
slib are arch: all packages, and it's not useful to set a dep-wait on a
package that *is* available.  Could you please revise this list accordingly?

Also, setting an (= $version) dep-wait isn't particularly helpful, sometimes
newer source versions will be uploaded before binaries are uploaded for the
current version.  So please clarify whether these are meant to be >= or
something else.

> 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 folks sifting through the build failures (like the rarely
used "confirmed" BTS tag is for maintainers).  In the long-term, one of two
things needs to happen with each of these build failures: the package needs
to be added to P-a-s so the arch no longer tries to build it, or the package
needs to be fixed -- via porter NMU if necessary.

So as you have the list of these packages, as a porter you can proceed with
figuring out which of the two

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

[Christoph Hellwig]

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.  Obviously this is only the case for architectures that
support numa. I've actually tested it on ppc64, although not on debian.

> libaio

this should build on all architectures.  Currently it needs a tiny bit
of architecture-specific code, but that could be avoided by using proper
syscall macros instead of trying to do it's own.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Sparc build failure analysis (was Re: StrongARM tactics)

[Blars Blarson]

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 buildd queues before
>> the porters can do anything.
>
>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 list below.

>If the porters do this effectively, there's really not much need at all for
>telling the buildd maintainers about transient build failures, because
>they'll be pretty obvious (and account for the majority of failures, as it
>should be).

Just because it is obvious does not mean that the buildd adminstrator
does the correct thing.  kq was "uploaded" 51 days ago, trustedqsl was
"uploaded" 25 days ago, neither is in the archive.

openoffice.org has been "building" for 8 days, it only took 57 hours
on my slower than any current sparc buildd pbuilder.  kexi has been
"building" for 6 days, it took less than 2 hours.

The sparc buildd mainainter has in the past left transient build
failures lie for over 6 months.  For the past year he's been requeuing
all maybe-failed packages every 1-3 months.



I've gone through the list of "maybe-failed" packages on sparc again.
The first sections is the packages that shouldn't be attempted on
sparc.  Two packages need requeued now that bugs in other packages are
fixed.  Several packages need to be put in dep-wait, and of course
there is a large list that should be moved to failed.  If nothing
useful is done with this list, don't expect me to repeat the work
again.


NOT-FOR-US

numactl
only supports i386 amd64 ia64
appears to assume intel-style stuff, would need major redesign
for other architectures
vm
only supports all, not any
see bug 342185
wmkbd
gsnes9x
pistachio
needs arch-specific code
acpidump
kexec-tools
bug 338846
redboot
bug 152911
rsbac-admin
hdaps-utils
lcd4linux
bug 336017
vnstat
hotkey-setup
gwp
snes9express
contrib, needs snes9x-x
libaio
adeos
defrag
ree
odyssey
nvidia-cg-toolkit
atokx2
xmms-openspc
lcrash
grub2
php4-maxdb
libpam-encfs
915resolution
pcsx
acpica-unix


REQUEUE
mcvs1.0.13-12   341850
qterm   0.4.0pre3-2+b1  342381


DEP-WAIT
galago-sharplibmono-dev
dmraid  libklibc-dev
motvibzvbi0 (= 0.2.17-3.0.1)
qmailadmin  vpopmail-bin
wvstreams   libxplc0.3.13-dev
sylpheed-claws-gtk2 libclamv-dev
digikam libartsl-dev (>=1.4.2)
tulip   mesa-common-dev (= 6.2.1-7)
liferea libdbus-glib-1-dev
kwave   kdemultimedia-dev
ivtools libace-dev
fwbuilder   libfwbuilder-dev
gtksharp2   libmono-dev
libavg  libavcodeccvs-dev
gnucash slib
memepackr-base-dev
r-cran-bayesm   r-base-dev


FAILED
bazaar  1.4.2-2 334320
palo1.9 320284
raidutils   0.0.4-7 326922
icon9.4.2-2.3   322972
erlang  1:10.b.7-1  326031
ispell-fi   0.7-16  326025
gmpc0.12.0-1333711
cursel  0.2.2-3.1   267900
supercollider   20050624-1  290339
qprof   0.5.1-6 323094
silc-toolkit0.9.12-4.1  326924
libgstreamer-perl   0.04-1  328051
jmagick 6.0.4-0-1   329104
mesa-lagacy 6.2.1-8 327637
xsim0.3.9.4-6   221453
haskell-http0.4.20050430-1  315333
rhyme   0.9-5   269371
ultrapossum-slapd   0.0.4+2.2.20sb3-1   304092
wmtune  1.1-1   269718
siptoolbox  0.3.99rc2alpha3-2   332526
slate   0.3.4.3-2   323126
postgis 1.0.0-1 323120
php4-vpopmail   4.3.4-5.4.4+2   309556
babel   0.10.2-2.1  309272
stalin  0.9+0.10alpha2-2337169
klibc   1.1.1-4 330191
libopenspc  0.3.99a-2   322979
iproute 20041019-4  336675
swish-e 2.4.3-2 339343
rcalc   0.5.0-1 339103
insight 6.3.50+cvs.2005.11.16-1 339723
gpsd2.30-1  340852
glibc

Re: StrongARM tactics

[Goswin von Brederlow]

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 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 should be "i386 amd64". In
>> >> general anything with "Arch: i386" should add amd64.
>
>> > And is that certain to give a working 64-bit binary on amd64, or are you
>> > suggesting that we ship extra copies of 32-bit binaries for both i386 and
>> > amd64?
>
>> The later if the former is not working. Since we have no multiarch yet
>> and acceptance of patches leading up to it is going very slowly it
>> looks like etch will remain without multiarch. So we need the extra
>> copy to have something working.
>
> And for this you want to add hackish patches to console emulator packages?
> I think the amd64 port can live for a while without a Playstation emulator
> while we sort out how to cope with cross-installing of i386 packages.

What about it is hackish? It can be as simple as just adding "-m32" to
CFLAGS on amd64 (and ia64) and adding the right Build-Depends on the
32bit devel libs (ia32-libs-dev). We already have this for lilo, grub,
some other bootloader I can never remember. Other packages for this
sort of thing are wine and if you want to go crazy even OOo.

But again, what about it is hackish?

>> >> Also pcsx should not be in P-A-S (and isn't on cvs.d.o) because:
>> ...
>> >> wanna-build already filters the Architecture field of sources.
>
>> Small correction, quinn-diff does the actual filtering (here).
>
>> > No, it does not.  It goes to the buildds with every sourceful upload, and
>> > fails when sbuild checks the architecture list.
>
>> Hmm, must be just me then. Here quinn-diff already filters it out so
>> it doesn't reaches wanna-build itself. But that might just be one of
>> the several small differences to the official buildd suite.
>
>> [EMAIL PROTECTED]:~/t% quinn-diff 2>&1 | grep pcsx
>> [quinn-diff]: ignoring: pcsx has an architecture field of "i386" which
>> doesn't include amd64.
>
> Right; it is quinn-diff that does the filtering; and the quinn-diff on
> buildd.d.o does not filter on the package-provided Architecture: list.
>
>> Makes no sense to include a source not for this arch.
>
> On the contrary, I think it's a bad idea for quinn-diff to look at package
> Architecture: fields directly, just like it would be a bad idea for dak to
> let maintainers change Section: values directly.  You want porter oversight
> of the list of packages that are being excluded on an arch, and having these
> show up as build failures gives you that oversight.

The quinn diff warning suites that fine. Just let the cron job report
any differences in its stderr output.

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 sbuild fail before the Build-Depends? Scratch
those then.)

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Steve Langasek]

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

> >> > AFAICT, this is only because its Linux/Makefile forces CPU to ix86
> >> > unconditionally.

> >> Write patch. At a minimum the package should be "i386 amd64". In
> >> general anything with "Arch: i386" should add amd64.

> > And is that certain to give a working 64-bit binary on amd64, or are you
> > suggesting that we ship extra copies of 32-bit binaries for both i386 and
> > amd64?

> The later if the former is not working. Since we have no multiarch yet
> and acceptance of patches leading up to it is going very slowly it
> looks like etch will remain without multiarch. So we need the extra
> copy to have something working.

And for this you want to add hackish patches to console emulator packages?
I think the amd64 port can live for a while without a Playstation emulator
while we sort out how to cope with cross-installing of i386 packages.

> >> Also pcsx should not be in P-A-S (and isn't on cvs.d.o) because:
> ...
> >> wanna-build already filters the Architecture field of sources.

> Small correction, quinn-diff does the actual filtering (here).

> > No, it does not.  It goes to the buildds with every sourceful upload, and
> > fails when sbuild checks the architecture list.

> Hmm, must be just me then. Here quinn-diff already filters it out so
> it doesn't reaches wanna-build itself. But that might just be one of
> the several small differences to the official buildd suite.

> [EMAIL PROTECTED]:~/t% quinn-diff 2>&1 | grep pcsx
> [quinn-diff]: ignoring: pcsx has an architecture field of "i386" which
> doesn't include amd64.

Right; it is quinn-diff that does the filtering; and the quinn-diff on
buildd.d.o does not filter on the package-provided Architecture: list.

> Makes no sense to include a source not for this arch.

On the contrary, I think it's a bad idea for quinn-diff to look at package
Architecture: fields directly, just like it would be a bad idea for dak to
let maintainers change Section: values directly.  You want porter oversight
of the list of packages that are being excluded on an arch, and having these
show up as build failures gives you that oversight.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: StrongARM tactics

[Goswin von Brederlow]

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 because its Linux/Makefile forces CPU to ix86
>> > unconditionally.
>>
>> Write patch. At a minimum the package should be "i386 amd64". In
>> general anything with "Arch: i386" should add amd64.
>
> 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 -- I'll change it if someone can confirm that it will 
> build and work.

They will if you do it right. Look at lilo, grub or that other
bootloader amd64 has.

Basicaly you just have to use "gcc -m32" for the C/asm code you
compile with gcc. nasm should always make 32bit code I think.

You will need any libs you use (apart from libc6, zlib and a few more
X libs that ia32-libs has already) as 32bit version though, if any. It
probably will need some work to get it to build but it would be worth
it. Ask on debian-amd64 for someone to help porting if you are willing
to support this in the future.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Ryan Schultz]

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 build on amd64, so I'm
> > assuming that the same is true here -- I'll change it if someone can
> > confirm that it will build and work.
>
> It built on my AMD64 system with a crude patch (attached, along with
> the resulting log) that drops the CPU setting unconditionally, but I
> haven't actually tested the result -- I built it mainly because I'm a
> packrat. ;-)

I can't get a clean pdebuild[1] on i386 with that setting dropped, which seems 
unusual -- it fails during linking. I'll hack something up for the rules 
file, in any case, and contact my sponsor; I have a new upload ready anyway.

[1]
../PsxMem.o: In function `psxMemWrite8':PsxMem.c:(.text+0x530): undefined 
reference to `psxRecLUT'
../PsxMem.o: In function `psxMemWrite16':PsxMem.c:(.text+0x5b1): undefined 
reference to `psxRecLUT'
../PsxMem.o: In function `psxMemWrite32':PsxMem.c:(.text+0x656): undefined 
reference to `psxRecLUT'
:PsxMem.c:(.text+0x691): undefined reference to `psxRecLUT'
../Misc.o: In function `RecvPcsxInfo':Misc.c:(.text+0x1856): undefined 
reference to `psxRec'
../R3000A.o: In function `psxInit':R3000A.c:(.text+0x1c): undefined reference 
to `psxRec'
Gtk2Gui.o: In function `OnCpu_Ok':Gtk2Gui.c:(.text+0x1af6): undefined 
reference to `psxRec'

-- 
Ryan Schultz
YOU RPN LOVE IF THEN HONK


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Aaron M. Ucko]

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 -- I'll change it if someone can confirm that it will 
> build and work.

It built on my AMD64 system with a crude patch (attached, along with
the resulting log) that drops the CPU setting unconditionally, but I
haven't actually tested the result -- I built it mainly because I'm a
packrat. ;-)

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.

diff -u pcsx-1.6df/debian/control pcsx-1.6df/debian/control
--- pcsx-1.6df/debian/control
+++ pcsx-1.6df/debian/control
@@ -6,7 +6,7 @@
 Standards-Version: 3.6.2
 
 Package: pcsx
-Architecture: i386
+Architecture: any
 Depends: ${shlibs:Depends}
 Recommends: psemu-sound, psemu-input, psemu-drive, psemu-video
 Description: Sony PlayStation emulator
diff -u pcsx-1.6df/debian/changelog pcsx-1.6df/debian/changelog
--- pcsx-1.6df/debian/changelog
+++ pcsx-1.6df/debian/changelog
@@ -1,3 +1,12 @@
+pcsx (1.6df-1.0) unstable; urgency=low
+
+  * NMU of sorts (though no actual upload intended.)
+  * debian/control: Change architecture from i386 to any.
+  * Linux/Makefile: don't force CPU to ix86 (should be done conditionally
+in debian/rules).
+
+ -- Aaron M. Ucko <[EMAIL PROTECTED]>  Mon, 28 Nov 2005 10:42:36 -0500
+
 pcsx (1.6df-1) unstable; urgency=low
 
   * Initial release Closes: #137355
only in patch2:
unchanged:
--- pcsx-1.6df.orig/Linux/Makefile
+++ pcsx-1.6df/Linux/Makefile
@@ -7,7 +7,7 @@
 
 all: pcsx
 
-CPU = ix86
+# CPU = ix86
 
 OPTIMIZE = -O2 -fomit-frame-pointer -finline-functions -ffast-math
 FLAGS = -D__LINUX__ -DPCSX_VERSION=\"${VERSION}\" -DPACKAGE=\"pcsx\"
dpkg-buildpackage: source package is pcsx
dpkg-buildpackage: source version is 1.6df-1.0
dpkg-buildpackage: source changed by Aaron M. Ucko <[EMAIL PROTECTED]>
dpkg-buildpackage: host architecture amd64
 fakeroot debian/rules clean
dh_testdir
# Add here commands to configure the package.
cd /home/amu/src/pcsx/pcsx-1.6df/Linux && ./configure --bindir=/usr/games
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for strip... strip
checking for rm... rm
checking for rmdir... rmdir
checking gtk+2... checking for pkg-config... /usr/bin/pkg-config
checking for gtk+-2.0 > 2.0.0... yes
checking GTK_CFLAGS... -DXTHREADS -I/usr/include/gtk-2.0 
-I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 
-I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include  
checking GTK_LIBS... -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm 
-lpangoxft-1.0 -lpangox-1.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 
-lgmodule-2.0 -ldl -lglib-2.0  
configure: creating ./config.status
config.status: creating Makefile.cfg
touch configure-stamp
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
# Add here commands to clean up after the build process.
cd /home/amu/src/pcsx/pcsx-1.6df/Linux && /usr/bin/make clean
make[1]: Entering directory `/home/amu/src/pcsx/pcsx-1.6df/Linux'
rm -f Makefile.cfg
rm -f *.o ../*.o ..//*.o pcsx
rm -f config.*
make[1]: Leaving directory `/home/amu/src/pcsx/pcsx-1.6df/Linux'
dh_clean 
 dpkg-source -i -b pcsx-1.6df
dpkg-source: building pcsx using existing pcsx_1.6df.orig.tar.gz
dpkg-source: building pcsx in pcsx_1.6df-1.0.diff.gz
dpkg-source: building pcsx in pcsx_1.6df-1.0.dsc
 debian/rules build
dh_testdir
# Add here commands to configure the package.
cd /home/amu/src/pcsx/pcsx-1.6df/Linux && ./configure --bindir=/usr/games
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking f

Re: StrongARM tactics

[Ryan Schultz]

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 ix86
> > unconditionally.
>
> Write patch. At a minimum the package should be "i386 amd64". In
> general anything with "Arch: i386" should add amd64.

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 -- I'll change it if someone can confirm that it will 
build and work.

-- 
Ryan Schultz
YOU RPN LOVE IF THEN HONK


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Martijn van Oosterhout]

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 @ buildd.debian.net that took simple commands like:

give-back  

It could accept any email signed by a debian maintainer. Basic stuff
like this is doesn't need to be restricted to just a few people.

Re: buildd administration [was Re: StrongARM tactics]

[Thomas Viehmann]

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 see that you think P-a-s entries are somebody
| else's problem that should be "handled centrally".

and containing a few reports similar to Thiemo's

| FWIW, I started to send mips patches for P-a-s, following the
| procedure outlined at the top of this file. There was neither a
| response nor any other discernable action.

could have contributed to the "buildd administration" complaints?

The reaction to my (admittedly less than optimal) attempt at an analysis
that followed was not "oh, do check these with porters and maintainers
and then get back to me" from someone who could then change the file,
but half dozen people saying something to the effect "I'm a
porter/maintainer and were utterly unsucessful at my attempts to get
anything done".
I do appreciate your comments of proposed P-a-s additions that you think
problematic but the rest of the thread rather spells "don't bother".

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Goswin von Brederlow]

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
>
>> > AFAICT, this is only because its Linux/Makefile forces CPU to ix86
>> > unconditionally.
>
>> Write patch. At a minimum the package should be "i386 amd64". In
>> general anything with "Arch: i386" should add amd64.
>
> And is that certain to give a working 64-bit binary on amd64, or are you
> suggesting that we ship extra copies of 32-bit binaries for both i386 and
> amd64?

The later if the former is not working. Since we have no multiarch yet
and acceptance of patches leading up to it is going very slowly it
looks like etch will remain without multiarch. So we need the extra
copy to have something working.

>> Also pcsx should not be in P-A-S (and isn't on cvs.d.o) because:
...
>> wanna-build already filters the Architecture field of sources.

Small correction, quinn-diff does the actual filtering (here).

> No, it does not.  It goes to the buildds with every sourceful upload, and
> fails when sbuild checks the architecture list.

Hmm, must be just me then. Here quinn-diff already filters it out so
it doesn't reaches wanna-build itself. But that might just be one of
the several small differences to the official buildd suite.

[EMAIL PROTECTED]:~/t% quinn-diff 2>&1 | grep pcsx
[quinn-diff]: ignoring: pcsx has an architecture field of "i386" which
doesn't include amd64.

Makes no sense to include a source not for this arch.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: buildd administration [was Re: StrongARM tactics]

[Richard Fojta]

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, 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,
>
> How do you know this is true? (Hint: I know it's not.)
>
> > and people aren't skilled enough because they aren't allowed to help.
>
> 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*.  This is a concrete and specific task which needs
> attention, which doesn't require special access in order to work on, and by
> means of which developers can demonstrate their trustworthiness to buildd
> maintainers.  Instead, people are telling me this is the buildd maintainer's
> job, and that no one is going to volunteer to do any porting work unless
> they are given the keys to the buildds in the process.
>
> The buildd maintainers are stopping people from helping?  Like, WTF?
>
> > I started my implication in the project four years ago. For four years,
> > there have been problems with keyring maintenance and buildd
> > administration.
>
> What problems are there today with buildd administration, please?
>
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> [EMAIL PROTECTED]   http://www.debian.org/
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFDmB/jKN6ufymYLloRAsn/AKChEi2vi3Kr1GbDEhwZbqVa19kbiACfeZxy
> KAWdD+XhpAEVMfS7G/rfdKU=
> =f1o5
> -END PGP SIGNATURE-
>
>
>

Re: buildd administration [was Re: StrongARM tactics]

[Steve Langasek]

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,

How do you know this is true? (Hint: I know it's not.)

> and people aren't skilled enough because they aren't allowed to help.

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*.  This is a concrete and specific task which needs
attention, which doesn't require special access in order to work on, and by
means of which developers can demonstrate their trustworthiness to buildd
maintainers.  Instead, people are telling me this is the buildd maintainer's
job, and that no one is going to volunteer to do any porting work unless
they are given the keys to the buildds in the process.

The buildd maintainers are stopping people from helping?  Like, WTF?

> I started my implication in the project four years ago. For four years,
> there have been problems with keyring maintenance and buildd
> administration.

What problems are there today with buildd administration, please?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

buildd administration [was Re: StrongARM tactics]

[Josselin Mouette]

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 doesn't seem to offer
> much as a practical recommendation; you don't get to be a buildd maintainer
> by telling the current folks "you aren't taking the right amount of pleasure
> in this -- better let me do it", you get there by working with the current
> folks and building a relationship with them and showing that you know what
> you're doing.  Sorry, with a project that's a thousand strong, if they *do*
> care about the task, not too many people are going to turn it over to
> someone they don't know without first assuring themselves that they can
> handle it; and note that I never suggested the current buildd maintainers
> don't *care* about the ports they're helping with, they just don't have
> unlimited amounts of time to spend on single-handedly ensuring that ports
> keep up.

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, and people aren't skilled enough because they
aren't allowed to help.

I started my implication in the project four years ago. For four years,
there have been problems with keyring maintenance and buildd
administration. For four years, people responsible for these tasks have
refused help on these matters. For four years, everything that was
suggested on these topics haven't lead to any result, because these same
people have simply ignored the suggestions. Can someone tell me when
this nightmare is going to end?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: StrongARM tactics

[Steve Langasek]

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 Linux/Makefile forces CPU to ix86
> > unconditionally.

> Write patch. At a minimum the package should be "i386 amd64". In
> general anything with "Arch: i386" should add amd64.

And is that certain to give a working 64-bit binary on amd64, or are you
suggesting that we ship extra copies of 32-bit binaries for both i386 and
amd64?

> Also pcsx should not be in P-A-S (and isn't on cvs.d.o) because:

> [EMAIL PROTECTED]:~% zcat
> /mnt/mirror/debian/dists/sid/contrib/source/Sources.gz| grep-dctrl
> pcsx
> Package: pcsx
> Binary: pcsx
> Version: 1.6df-1
> Priority: optional
> Section: contrib/games
> Maintainer: Ryan Schultz <[EMAIL PROTECTED]>
> Build-Depends: debhelper (>= 4.0.0), x11proto-core-dev | x-dev,
> libgtk2.0-dev, zlib1g-dev | libz-dev
> Architecture: i386
> Standards-Version: 3.6.2
> Format: 1.0
> Directory: pool/contrib/p/pcsx
> Files:
>  972b029160bdc0a1c6316d27280fe7ec 619 pcsx_1.6df-1.dsc
>  c688e5da5ee3aa6a1b2377545d97a4e1 317340 pcsx_1.6df.orig.tar.gz
>  006f2f71b0dcc24ec2c76821504f03ec 2540 pcsx_1.6df-1.diff.gz

> wanna-build already filters the Architecture field of sources.

No, it does not.  It goes to the buildds with every sourceful upload, and
fails when sbuild checks the architecture list.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: StrongARM tactics

[Steve Langasek]

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 Vancouver proposal sought to address, where two or three
> > people end up carrying all the ports, and all their time is eaten up by
> > maintaining the buildds and giving back failed packages with no time for
> > following through on the permanent failures (which, even though they
> > sometimes represent a minority of Maybe-Failed packages usually account for
> > a majority of the actual work needing done).

> This go against the two basic rules for a volunteer organisation.

> 1) Volunteers doing the job should be people interested in doing it.
> 2) Responsibility should go to people that are going to do the job.

> 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 doesn't seem to offer
much as a practical recommendation; you don't get to be a buildd maintainer
by telling the current folks "you aren't taking the right amount of pleasure
in this -- better let me do it", you get there by working with the current
folks and building a relationship with them and showing that you know what
you're doing.  Sorry, with a project that's a thousand strong, if they *do*
care about the task, not too many people are going to turn it over to
someone they don't know without first assuring themselves that they can
handle it; and note that I never suggested the current buildd maintainers
don't *care* about the ports they're helping with, they just don't have
unlimited amounts of time to spend on single-handedly ensuring that ports
keep up.

BTW, I have no reason to believe that buildd maintenance in general is any
more exciting or intrinsically rewarding than filing bugs on failed
packages (and providing fixes for the same); so if people are going to balk
at the latter task even though this is an area of porting that definitely
(in some cases desperately) needs attention, what reason is there to think
they're well-suited to being buildd maintainers either?

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

It seems like you're assuming that "buildd admins" and "porters" are two
non-overlapping sets.  On 6 of 11 architectures, at least one buildd admin
is also a porter for that arch under the release requalification guidelines;
on 7 of 11 architectures, at least one of the porters has wanna-build access
for that arch.

So it's certainly not the case that no porters are trusted to do binNMUs.
If what you're arguing is that *all* porters should have wanna-build/buildd
access (which is the best way to do binNMUs so that we get log files and
consistent build envs), then I disagree.  There's a heck of a lot of other
work that porters would be better off spending their time on -- like, for
instance, the unresolved build failures of perl on arm.  I mean, it's
possible you're right that porters are going to feel slighted if they don't
have buildd access; but shouldn't porters' primary motivation be to make
sure etch releases with a kick-ass Debian port for their architecture of
choice?  Should this really be about who holds the keys to the buildds?
Isn't being a Debian porter already something to take pride in?

> If the Vancouver proposal is the constatation that the old model did not
> work the solution is to change the model, not to expect that people will
> suddenly accept it. Unless you are just looking at an excuse to remove 
> ports, obviously. Fortunately there are no external organisations forcing
> the old model upon us, so there is no reason not to change it.

All I really see here is that you've asserted that other (unspecified)
porters should be given access to buildds that they don't necessarily want
or need.  Is this the new model you're referring to, or have I missed
something?  To be honest, it doesn't seem like much of a new model to me,
just new people in the same roles.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: StrongARM tactics

[Goswin von Brederlow]

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
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Goswin von Brederlow]

[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 should be "i386 amd64". In
general anything with "Arch: i386" should add amd64.

Also pcsx should not be in P-A-S (and isn't on cvs.d.o) because:

[EMAIL PROTECTED]:~% zcat
/mnt/mirror/debian/dists/sid/contrib/source/Sources.gz| grep-dctrl
pcsx
Package: pcsx
Binary: pcsx
Version: 1.6df-1
Priority: optional
Section: contrib/games
Maintainer: Ryan Schultz <[EMAIL PROTECTED]>
Build-Depends: debhelper (>= 4.0.0), x11proto-core-dev | x-dev,
libgtk2.0-dev, zlib1g-dev | libz-dev
Architecture: i386
Standards-Version: 3.6.2
Format: 1.0
Directory: pool/contrib/p/pcsx
Files:
 972b029160bdc0a1c6316d27280fe7ec 619 pcsx_1.6df-1.dsc
 c688e5da5ee3aa6a1b2377545d97a4e1 317340 pcsx_1.6df.orig.tar.gz
 006f2f71b0dcc24ec2c76821504f03ec 2540 pcsx_1.6df-1.diff.gz

wanna-build already filters the Architecture field of sources. The
package will automaticaly only appear on i386. When more archs (or
any) appear there wanna-build will pick it up for those archs
automatically.

MfG
Goswin

PS: policy dictates that where possible all archs has to be supported


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Goswin von Brederlow]

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
> time so you can trivially demonstrate how big a benefit there would be
> if people would start paying attention.
>
> If you're using the BTS (by filing, analysing or fixing FTBFS bugs, eg),
> tracking the bugs with a usertag might be convenient and useful.
>
> (I don't know what the actual/perceived problem here is to give more
> detailed suggestions, sorry)
>
> Cheers,
> aj

What is required is a

buildd-give-back package_version

(or whatever you called the alias for wanna-build --give-back).

The buildd admin won't look at a webpage listing packages that need to
be handled any more than he is looking at the list of packages
left dangling without action.


There is a big difference between packages that fail with some error
and packages that fail with missing depends. I realy don't think users
can do anything productive for the later unlike the real FTBFS errors
where one can debug the problem, write a patch, submitt a bugreport
and so on.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Anthony Towns]

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 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 demonstrate how big a benefit there would
> > be if people would start paying attention.
> Is it just me, or does it seem entirely one sided and
>  thankless effort, where one goes off and  does a boatload of work,
>  and petritions for the powers on high to maybe deign to notice all
>  the diligence being put in? 

*shrug* I doubt it's just you; I only suggest it because it's worked for
me in the past -- for britney, for the BTS CGIs, for archiving old bugs
for the BTS, possibly some others.

> This kind of thing can rapidly suck the fun out of most things.

Yeah, well, there's all sorts of ways of sucking the fun out of things.

Cheers,
aj



signature.asc
Description: Digital signature

Re: StrongARM tactics

[Thomas Bushnell BSG]

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 if you don't find
>> someone who'll give you an immediate response, track the issues over
>> time so you can trivially demonstrate how big a benefit there would
>> be if people would start paying attention.
>
> Is it just me, or does it seem entirely one sided and
>  thankless effort, where one goes off and  does a boatload of work,
>  and petritions for the powers on high to maybe deign to notice all
>  the diligence being put in? This kind of thing can rapidly suck the
>  fun out of most things.

It's not just you.

I think we need some kind of performance review for key "only one
person can do it" jobs in Debian, so that we can evaluate the
performance of those tasks, and then recruit new volunteers to take
them over if the project as a whole is dissatisfied with the
performance of them.

We already have mechanisms to do this for package maintenance; now
it's time to have mechanisms for other jobs too.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Manoj Srivastava]

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 response, track the issues over
> time so you can trivially demonstrate how big a benefit there would
> be if people would start paying attention.

Is it just me, or does it seem entirely one sided and
 thankless effort, where one goes off and  does a boatload of work,
 and petritions for the powers on high to maybe deign to notice all
 the diligence being put in? This kind of thing can rapidly suck the
 fun out of most things.

manoj
-- 
Support Mental Health.  Or I'll kill you.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Bill Allombert]

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 up carrying all the ports, and all their time is eaten up by
> maintaining the buildds and giving back failed packages with no time for
> following through on the permanent failures (which, even though they
> sometimes represent a minority of Maybe-Failed packages usually account for
> a majority of the actual work needing done).

This go against the two basic rules for a volunteer organisation.

1) Volunteers doing the job should be people interested in doing it.
2) Responsibility should go to people that are going to do the job.

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.

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.
If the Vancouver proposal is the constatation that the old model did not
work the solution is to change the model, not to expect that people will
suddenly accept it. Unless you are just looking at an excuse to remove 
ports, obviously. Fortunately there are no external organisations forcing
the old model upon us, so there is no reason not to change it.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.

Whoever decided to make elvis the default editor on master is not color-blind.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Ryan Schultz]

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

I've tried to contact the maintainers (listed in the file) of the 
packages-arch-specific file for two of my packages in your patch, 
xmms-openspc and libopenspc, and have never received a response -- my sponsor 
said that the maints were very busy, so I've not mailed them since. Neither 
of these packages are going to work on non-i386 in the future, so certainly 
feel free to add them!

I'm also the maintainer of PCSX and its associated plugins, which will all 
likely go Arch: i386 in my sponsor's next upload of them. They *might* all 
build on other arches, but whether they will *work* is questionable. PCSX has 
terrifying code (to me), and I'm not sure which C routines dropping the ASM 
would reactivate, which could cause it to have even more random segfaults -- 
I have most of those on i386 fixed, but I can't test on other arches. Having 
said that, I'd prefer that it not be added to p-a-s yet, because I intend to 
somehow ensure that it works on other arches soon, and then I'll redo the 
Arch line.

Summary: please add xmms-openspc and libopenspc, but not yet pcsx or psemu-*, 
if you can.

-- 
Ryan Schultz
YOU RPN LOVE IF THEN HONK


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Aaron M. Ucko]

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 PROTECTED] (NOT a valid e-mail address) for more info.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Anthony Towns]

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 demonstrate how big a benefit there would be
if people would start paying attention.

If you're using the BTS (by filing, analysing or fixing FTBFS bugs, eg),
tracking the bugs with a usertag might be convenient and useful.

(I don't know what the actual/perceived problem here is to give more
detailed suggestions, sorry)

Cheers,
aj



signature.asc
Description: Digital signature

Re: StrongARM tactics

[Steve Langasek]

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 [?]

> Is a P-a-s entry some sort of a final verdict?

No, but it's a fairly long-term one; when people are concerned about
response time of the folks managing P-a-s, increasing churn certainly isn't
advisable, and having a package in P-a-s that shouldn't be has much more of
an impact than not having one listed that should be. :)

> I don't think it makes sense to attempt builds of a package for some years
> when it is known to fail. (Years might not be true for grub2, an example
> which comes to mind is gwydion-dylan.)

Agreed.  I think grub2 is a bit different, because upstream is (AIUI)
explicitly working on porting it to other architectures, so it bears
checking with the porters first.

> [snip]
> > > +ree: i386 amd64 ia64 kfreebsd-i386 hurd-i386   # 
> > > reads ROM from /dev/mem, i386/amd64/ia64-specific

> > The description says this package "can also extract font data from video
> > card ROMs."  Are we certain this is specific to i386/amd64/ia64?

> At least for mips/mipsel reading /dev/mem with a PC-like hardcoded
> offset won't yield anything useful.

Sure; but the root of this thread is a post talking about arm boards with
VGA BIOS emulation, so... :)  Again, worth checking with porters on.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: StrongARM tactics

[Steve Langasek]

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 buildd admins alone should bear the
> >responsibility for figuring out whether a permanent build failure should be
> >fixed or ignored.  (Maintainers probably need to be involved in this
> >process, but usually maintainers don't have the requisite knowledge about
> >all our ports to make informed decisions on their own.)

> 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 buildd queues before
> the porters can do anything.

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.

If the porters do this effectively, there's really not much need at all for
telling the buildd maintainers about transient build failures, because
they'll be pretty obvious (and account for the majority of failures, as it
should be).

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: StrongARM tactics

[Blars Blarson]

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 whether a permanent build failure should be
>fixed or ignored.  (Maintainers probably need to be involved in this
>process, but usually maintainers don't have the requisite knowledge about
>all our ports to make informed decisions on their own.)

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 buildd queues before
the porters can do anything.

>Wonderful.  Nice to see that you think P-a-s entries are somebody else's
>problem that should be "handled centrally".

The buildd administrators have made it clear that's the way they want it.
-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Bill Allombert]

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 "maybe-failed" packages [1]. To get back into testing, we
> need some developer help to debug and fix these problems.

Hello Vincent,

What would much help is one or more reasonably fast and reliable ARM
machines accessible to developpers, whether they are in *.debian.org or
not.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Kurt Roeckx]

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 other arches.  It's not because something
doesn't build now it it that it should get added to P-a-s.

> libpam-encfs: isn't arch-specific, see #340575. Maybe random arch
>   disabling should be RC...

Also see the release policy about this:
http://release.debian.org/etch_rc_policy.txt

> prj2make-sharp: i386 powerpc s390
>   # amd64: #314517 without maintainer comment
>   # ia64 arm unknown, others disabled in P-a-s

It's a mono packages, and that currently only supports a limited
number of arches.  P-a-s is correct in it that it should attempt
to build it on all of those, there is no reason to think it
shouldn't work on those.



Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Thiemo Seufer]

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
sense to attempt builds of a package for some years when it is known
to fail. (Years might not be true for grub2, an example which comes to
mind is gwydion-dylan.)

[snip]
> > +ree: i386 amd64 ia64 kfreebsd-i386 hurd-i386 # 
> > reads ROM from /dev/mem, i386/amd64/ia64-specific
> 
> The description says this package "can also extract font data from video
> card ROMs."  Are we certain this is specific to i386/amd64/ia64?

At least for mips/mipsel reading /dev/mem with a PC-like hardcoded
offset won't yield anything useful.

> > +rootskel-gtk: alpha amd64 i386 powerpc sparc # 
> > [ANAIS] udeb for graphical debian-installer
> 
> Just because it's only built for these archs now doesn't mean this has to be
> true long-term.

Agreed.


Thiemo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Thiemo Seufer]

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...
> 
> >>+dfsbuild: i386 alpha powerpc amd64   # [ANAIS] 
> >>debian from scratch installer
> > Seems like it should be portable without too much trouble to other
> > architectures, if there was porter interest?
> Yes, OTOH it clearly needs to be adapted to whatever it's ported to, and
> there haven't been any arch additions for well over a year, so it seems
> interest is limited.
> 
> For ree:
> How portable is scaning /dev/mem between position 0xc and 0xf in
> 512 byte blocks for some magic number as a concept?

Not so much. On mips/mipsel it will read some part of the running
Linux kernel that way.


Thiemo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Lennert Buytenhek]

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.  (Admittedly, this is due to a kernel bug --
specifically, valid_phys_addr_range() not being implemented for ARM.)

xdm has a similar issue:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336220


--L


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Thomas Viehmann]

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 # [ANAIS] 
>>debian from scratch installer
> Seems like it should be portable without too much trouble to other
> architectures, if there was porter interest?
Yes, OTOH it clearly needs to be adapted to whatever it's ported to, and
there haven't been any arch additions for well over a year, so it seems
interest is limited.

For ree:
How portable is scaning /dev/mem between position 0xc and 0xf in
512 byte blocks for some magic number as a concept?
The code probably compiles on anything, after all an implementation as a
shell script plus unix utils is provided along with the c implementation.

> Just because it's only built for these archs now doesn't mean this has to be
> true long-term.
So, how long term should something be to be included?
It looks like the file is changed every two weeks or so. My guess was
that then if changes are submitted in bulk, declaring something seeing
no porter attention for a year is OK to list in P-a-s.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Steve Langasek]

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
> > responsibility for figuring out whether a permanent build failure should be
> > fixed or ignored.  (Maintainers probably need to be involved in this
> > process, but usually maintainers don't have the requisite knowledge about
> > all our ports to make informed decisions on their own.)

> Sorry, then I must have misunderstood the nature of the P-a-s file.
> But then, I always thought of it as a relict that probably should be
> gotten rid of once one believes that porters and maintainers can sort it
> out by themselves.

It's the file that controls whether wanna-build feeds a given package to the
buildds for that architecture, and it's also used in calculating the
statistics on how an architecture is keeping up -- so figures directly into
whether an arch is a release candidate.

> As for "somebody else": Attached is a patch for the build stuff that I
> think I have figured out.

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

> +dfsbuild: i386 alpha powerpc amd64 # [ANAIS] 
> debian from scratch installer

Seems like it should be portable without too much trouble to other
architectures, if there was porter interest?

> -grub2: !hppa !ia64 m68k# 
> bootloader
> +grub2: !hppa !ia64 !m68k !alpha !mips !mipsel !s390 !sparc # 
> bootloader for i386/powerpc [?]

The medium-term goal is for grub2 to be portable to a range of platforms,
AIUI; I wouldn't close the door on this yet...

> +%helix-player: i386 powerpc sparc  # [ANAIS]

Seems like this is a candidate for porting.

> +ree: i386 amd64 ia64 kfreebsd-i386 hurd-i386   # reads 
> ROM from /dev/mem, i386/amd64/ia64-specific

The description says this package "can also extract font data from video
card ROMs."  Are we certain this is specific to i386/amd64/ia64?

> +rootskel-gtk: alpha amd64 i386 powerpc sparc   # [ANAIS] 
> udeb for graphical debian-installer

Just because it's only built for these archs now doesn't mean this has to be
true long-term.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: StrongARM tactics

[Steve Langasek]

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

> > 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 whether a permanent build failure should be
> > fixed or ignored.  (Maintainers probably need to be involved in this
> > process, but usually maintainers don't have the requisite knowledge about
> > all our ports to make informed decisions on their own.)

> FWIW, I started to send mips patches for P-a-s, following the procedure
> outlined at the top of this file. There was neither a response nor any
> other discernable action.

> > 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 up carrying all the ports, and all their time is eaten up by
> > maintaining the buildds and giving back failed packages with no time for
> > following through on the permanent failures (which, even though they
> > sometimes represent a minority of Maybe-Failed packages usually account for
> > a majority of the actual work needing done).

> A while later, and rather by accident, Ryan Murray told me on IRC
> (paraphrased) "Of course they were ignored, you aren't a buildd admin.
> Send them to me." So I did. Ryan acknowledged to have received them with
> (again paraphrased) "Well, it's not so urgent." This was about 6 weeks ago.

Well, a few comments:

- Ryan is not himself one of the people listed as contacts for P-a-s; he may
  consider it best to send such changes through the buildd admins, but that
  doesn't mean that's the only way for them to be accepted.
- I know for a fact that changes *have* been accepted from non-buildd folks
  (myself included).
- Even without it being a policy, there's some truth to the idea that
  changes are going to be accepted more readily from folks that are trusted
  to get it right, because there's less need for review on the part of the
  P-a-s maintainers.  And buildd folks are going to be at the top of the
  list wrt knowing what's going on with P-a-s; but feeding the changes to a
  very busy buildd admin instead of a very busy P-a-s maintainer isn't an
  obvious win. :)  Much better that the porters show themselves to be
  competent wrt P-a-s, so that over time their changes *will* be trusted
  without lengthy delays while someone finds time to review them.
- He's right, it's not urgent. :)  So don't sweat the delays too much.
- I just checked with Adam Conrad on IRC, who was recently added as a third
  P-a-s maintainer because three busy contacts are better than two.  He asks
  that you please forward your changes to him.

> > > >>weechat: don't know, error on dh-strip on 5 archs, no bug filed

> > > >>That's 2 out of 7 which need actual debugging, both not arm-specific.

> > > > And only 1/7 where some action of the buildd maintainer is needed
> > > > at this time to get something build.
> > > The dep-wait is well inside the "some action of the buildd maintainer is
> > > needed". The needed P-a-s entries could be handeled centrally if the
> > > problem description is "pile of maybe-failed packages".

> > Wonderful.  Nice to see that you think P-a-s entries are somebody else's
> > problem that should be "handled centrally".

> It appears to be the idea of the people with write access to P-a-s.

Oh, well... appearances *can* be deceiving.  Never attribute to malice that
which can be adequately explained by people wearing a whole buncha hats. :)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: StrongARM tactics

[Thomas Viehmann]

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 seem to fashionable
>>nowadays...)

> 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 whether a permanent build failure should be
> fixed or ignored.  (Maintainers probably need to be involved in this
> process, but usually maintainers don't have the requisite knowledge about
> all our ports to make informed decisions on their own.)

Sorry, then I must have misunderstood the nature of the P-a-s file.
But then, I always thought of it as a relict that probably should be
gotten rid of once one believes that porters and maintainers can sort it
out by themselves.

>>The dep-wait is well inside the "some action of the buildd maintainer is
>>needed". The needed P-a-s entries could be handeled centrally if the
>>problem description is "pile of maybe-failed packages".

> Wonderful.  Nice to see that you think P-a-s entries are somebody else's
> problem that should be "handled centrally".
Well, that certainly is the impression I get. After all, sombody has to
commit the changes.
As for "somebody else": Attached is a patch for the build stuff that I
think I have figured out.

Thinks I don't know:

helix-player: don't know.
hotkey-setup: might also work on amd64 ia64 (depends on dmidecode)
  OTOH, maintainer usually seems to know what he's doing...
libpam-encfs: isn't arch-specific, see #340575. Maybe random arch
  disabling should be RC...
%ogre-contrib: i386 amd64 # don't know, in contrib
prj2make-sharp: i386 powerpc s390
  # amd64: #314517 without maintainer comment
  # ia64 arm unknown, others disabled in P-a-s

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/
--- Packages-arch-specific.orig 2005-12-06 10:25:15.0 +0100
+++ Packages-arch-specific  2005-12-06 11:37:06.0 +0100
@@ -23,11 +23,14 @@
 
 3c5x9utils: i386 # PC 
hardware specific
 855resolution: i386  # i386 
chipset specific
+915resolution: i386 amd64 kfreebsd-i386  # 
[?] *-i386? i386/amd64 chipset specific
 aboot: alpha # alpha 
boot loader
 %aboot-installer: alpha  # 
alpha boot loader installer 
 acpi: i386 ia64amd64 # 
acpi is i386/ia64 specific
 %acpi-support: i386 amd64 ia64   # [ANAIS]
+%acpica-unix: i386 ia64 amd64 kfreebsd-i386  # [?] 
*-i386?  acpi is i386/ia64 specific
 acpid: i386 ia64 amd64   # acpi is 
i386/ia64 specific
+acpidump: i386 ia64 amd64# [?] 
*-i386?  acpi is i386/ia64 specific
 %afbinit: sparc  # 
Sparc gfx card firmware loader
 %alleyoop: i386 amd64# [ANAIS] 
- Depends valgrind
 %alsadriver: i386 # i386 
specifc
@@ -92,6 +95,7 @@
 %cvsup: i386 # i386 
specifc (needs modula-3 )
 %detect: alpha i386  # 
build-depend on isapnptools binary
 %delo-installer: mipsel  # 
mipsel specific
+dfsbuild: i386 alpha powerpc amd64   # [ANAIS] 
debian from scratch installer
 %dmidecode: i386 ia64 amd64  # [ANAIS]
 %drdsl: i386 amd64   # [ANAIS]
 %drscheme: alpha amd64 hppa i386 m68k mips mipsel powerpc sparc  # 
[ANAIS]
@@ -151,12 +155,15 @@
 %gpart: i386 hurd-i386 ia64 alpha arm mipsel amd64   # little 
endian specific
 gprolog: i386 mips mipsel sparc alpha powerpc# from 
source
 %grub: i386 hurd-i386 amd64   # i386 
boot loader
-grub2: !hppa !ia64 m68k  # 
bootloader
+grub2: !hppa !ia64 !m68k !alpha !mips !mipsel !s390 !sparc   # 
bootloader for i386/powerpc [?]
 grubconf: i386 hurd-i386 freebsd-i386 netbsd-i386# i386 
boot loader
 grub-installer: i386 amd64 hurd-i386  # only 
useful if you have grub
 gspy: i3

Re: StrongARM tactics

[Thiemo Seufer]

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 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 whether a permanent build failure should be
> fixed or ignored.  (Maintainers probably need to be involved in this
> process, but usually maintainers don't have the requisite knowledge about
> all our ports to make informed decisions on their own.)

FWIW, I started to send mips patches for P-a-s, following the procedure
outlined at the top of this file. There was neither a response nor any
other discernable action.

> 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 up carrying all the ports, and all their time is eaten up by
> maintaining the buildds and giving back failed packages with no time for
> following through on the permanent failures (which, even though they
> sometimes represent a minority of Maybe-Failed packages usually account for
> a majority of the actual work needing done).

A while later, and rather by accident, Ryan Murray told me on IRC
(paraphrased) "Of course they were ignored, you aren't a buildd admin.
Send them to me." So I did. Ryan acknowledged to have received them with
(again paraphrased) "Well, it's not so urgent." This was about 6 weeks ago.

> > >>weechat: don't know, error on dh-strip on 5 archs, no bug filed
> 
> > >>That's 2 out of 7 which need actual debugging, both not arm-specific.
> 
> > > And only 1/7 where some action of the buildd maintainer is needed
> > > at this time to get something build.
> > The dep-wait is well inside the "some action of the buildd maintainer is
> > needed". The needed P-a-s entries could be handeled centrally if the
> > problem description is "pile of maybe-failed packages".
> 
> Wonderful.  Nice to see that you think P-a-s entries are somebody else's
> problem that should be "handled centrally".

It appears to be the idea of the people with write access to P-a-s.


Thiemo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Steve Langasek]

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 (libxplc0.3.13-dev) - dep in new queue, see #340696
> >>xchm: retry (needed libchm-dev)

> > This can probably be requeued indeed.  But it would help if the
> > maintainer uploaded xchm after libchm was in installed state
> > on all arches, so buildd admins don't have to look at this.
> Yeah. That would help. But so there's a lot of packages that need
> attention by buildd-admins.

> >>xmms-openspc: arch specific (says maintainer in control)
> >>zinc-compiler: arch specific dependency (ghc6)

> > 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 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 whether a permanent build failure should be
fixed or ignored.  (Maintainers probably need to be involved in this
process, but usually maintainers don't have the requisite knowledge about
all our ports to make informed decisions on their own.)

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 up carrying all the ports, and all their time is eaten up by
maintaining the buildds and giving back failed packages with no time for
following through on the permanent failures (which, even though they
sometimes represent a minority of Maybe-Failed packages usually account for
a majority of the actual work needing done).

> >>weechat: don't know, error on dh-strip on 5 archs, no bug filed

> >>That's 2 out of 7 which need actual debugging, both not arm-specific.

> > And only 1/7 where some action of the buildd maintainer is needed
> > at this time to get something build.
> The dep-wait is well inside the "some action of the buildd maintainer is
> needed". The needed P-a-s entries could be handeled centrally if the
> problem description is "pile of maybe-failed packages".

Wonderful.  Nice to see that you think P-a-s entries are somebody else's
problem that should be "handled centrally".

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: StrongARM tactics

[Thomas Viehmann]

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)

> This can probably be requeued indeed.  But it would help if the
> maintainer uploaded xchm after libchm was in installed state
> on all arches, so buildd admins don't have to look at this.
Yeah. That would help. But so there's a lot of packages that need
attention by buildd-admins.

>>xmms-openspc: arch specific (says maintainer in control)
>>zinc-compiler: arch specific dependency (ghc6)

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

>>visualboyadvance: buggy, could requeue to get #334727
> What's the point to requeue if this bug isn't fixed?
There isn't, thats why it says "buggy, could requeue", not "needs
retry". Also if you had a lot of cycles to spare, the last build log
would actually reflect the current problem...

>>weechat: don't know, error on dh-strip on 5 archs, no bug filed

>>That's 2 out of 7 which need actual debugging, both not arm-specific.

> And only 1/7 where some action of the buildd maintainer is needed
> at this time to get something build.
The dep-wait is well inside the "some action of the buildd maintainer is
needed". The needed P-a-s entries could be handeled centrally if the
problem description is "pile of maybe-failed packages".

OTOH above sample is biased: There's only ~57 Packages where apt-get
fails or dpkg complains about wrong arch.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Thomas Bushnell BSG]

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 step.
>> 
>> What can the people on such a mailing list do about buildd issues?
>
> Set up an alternate buildd network. This may be the only option is the
> only buildd administrator isn't able to process requests and still isn't
> willing to accept help.

Since they seem to be aware already of the problem, one wonders why
they haven't done this yet.

Re: StrongARM tactics

[Josselin Mouette]

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 list do about buildd issues?

Set up an alternate buildd network. This may be the only option is the
only buildd administrator isn't able to process requests and still isn't
willing to accept help.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: StrongARM tactics

[Thiemo Seufer]

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 queue, see #340696
> xchm: retry (needed libchm-dev)
> 
> xmms-openspc: arch specific (says maintainer in control)
> zinc-compiler: arch specific dependency (ghc6)
> 
> visualboyadvance: buggy, could requeue to get #334727
> weechat: don't know, error on dh-strip on 5 archs, no bug filed
> 
> That's 2 out of 7 which need actual debugging, both not arm-specific.
> 
> If you're deperate for people looking at build-failures, that's OK, but
> only few of them seem really arm-specific.

The number of Maybe-Failed packages doesn't tell much. A while ago I
went through it for mips and found that the vast majority consists of

- Packages which should be in P-a-s
- Packages which should be in state Dep-Wait
- Packages which are broken in the same obvious way for several
  architectures


Thiemo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Kurt Roeckx]

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 install the build dependencies for it on any arch.  They
are not available.  There is a reason this has failed on all
arches.

The problem is that libccrtp1-1.3-0 is still linked to
libcommoncpp2-1.3c2 instead of libcommoncpp2-1.3c2a.

> wvstreams: Dep-Wait (libxplc0.3.13-dev) - dep in new queue, see #340696
> xchm: retry (needed libchm-dev)

This can probably be requeued indeed.  But it would help if the
maintainer uploaded xchm after libchm was in installed state
on all arches, so buildd admins don't have to look at this.

> xmms-openspc: arch specific (says maintainer in control)
> zinc-compiler: arch specific dependency (ghc6)

So those should get added to P-a-s instead.

> visualboyadvance: buggy, could requeue to get #334727

What's the point to requeue if this bug isn't fixed?

> weechat: don't know, error on dh-strip on 5 archs, no bug filed
> 
> That's 2 out of 7 which need actual debugging, both not arm-specific.

And only 1/7 where some action of the buildd maintainer is needed
at this time to get something build.


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Thomas Viehmann]

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 (needed libchm-dev)

xmms-openspc: arch specific (says maintainer in control)
zinc-compiler: arch specific dependency (ghc6)

visualboyadvance: buggy, could requeue to get #334727
weechat: don't know, error on dh-strip on 5 archs, no bug filed

That's 2 out of 7 which need actual debugging, both not arm-specific.

If you're deperate for people looking at build-failures, that's OK, but
only few of them seem really arm-specific.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Clint Adams]

> 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 PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Thomas Bushnell BSG]

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 not pretending o be personally involved in the ARM port in
> any way, and have no strong feelings about it one way or the other.
> While it would be sad to lose it, I have to say I haven't been working
> on it.  It's just that resonding to a "we need help, and are willing to
> take a loss to provide porter hardware in order to get that help" email 
> with "some guy didn't answer my email, so screw that port" seems a bit
> silly and overblown.

I'm not saying "screw the port"; I'm saying "help sorting through the
failed-build packages may well be wasted work."

There may be plenty of other things that are not wasted work.  But
until the port maintainers figure out a way to not toss work, is it
really churlish of me to say I'm not so much interested in doing that
work myself?

I don't want to see a hundred Debian developers each process two of
these packages, and have all that labor wasted.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Stephen Gran]

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
> >> dependencies, it was apparently ignored for weeks.  It took the
> >> release manager's involvement to get the build processed.
> >
> >> So no, I frankly don't believe the "what we need is developer help to
> >> debug and fix."  
> >
> >   Sigh. "All the trouble that _I_ ever had with the ARM port was that
> >   the buildd maintainer didn't process my request, so it is BLATANTLY
> >   OBVIOUS that no other problems with the ARM port exist. I mean, come
> >   on, I've never been in a situation where more developer help would
> >   have been useful, so I 'frankly believe' such situations do not
> >   exist."
> >
> > -- Thomas Bushnell BSG.
> 
> The mail said "there are lots of packages in maybe-failed state, we
> need help sorting through them."
> 
> So I thought back to recent history, when packages I maintain were in
> maybe-failed state on arm, and had sorted through them, identified the
> problem, and sent email.
> 
> The email was apparently entirely ignored, for weeks.
> 
> So when I hear, "we need people to do task X!" and I did a piece of
> task X, and was simply ignored, I become hesitant to volunteer my time
> to do more of task X.

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.

Instead, you could hold a grudge and complain.  That would be in keeping
with the Debian tradition, after all.

Note: I am not pretending o be personally involved in the ARM port in
any way, and have no strong feelings about it one way or the other.
While it would be sad to lose it, I have to say I haven't been working
on it.  It's just that resonding to a "we need help, and are willing to
take a loss to provide porter hardware in order to get that help" email 
with "some guy didn't answer my email, so screw that port" seems a bit
silly and overblown.

Take care,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: StrongARM tactics

[Thomas Bushnell BSG]

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 manager's involvement to get the build processed.
>
>> So no, I frankly don't believe the "what we need is developer help to
>> debug and fix."  
>
>   Sigh. "All the trouble that _I_ ever had with the ARM port was that
>   the buildd maintainer didn't process my request, so it is BLATANTLY
>   OBVIOUS that no other problems with the ARM port exist. I mean, come
>   on, I've never been in a situation where more developer help would
>   have been useful, so I 'frankly believe' such situations do not
>   exist."
>
> -- Thomas Bushnell BSG.

The mail said "there are lots of packages in maybe-failed state, we
need help sorting through them."

So I thought back to recent history, when packages I maintain were in
maybe-failed state on arm, and had sorted through them, identified the
problem, and sent email.

The email was apparently entirely ignored, for weeks.

So when I hear, "we need people to do task X!" and I did a piece of
task X, and was simply ignored, I become hesitant to volunteer my time
to do more of task X.

Thomas

Re: StrongARM tactics

[Adeodato Simó]

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

> So no, I frankly don't believe the "what we need is developer help to
> debug and fix."  

  Sigh. "All the trouble that _I_ ever had with the ARM port was that
  the buildd maintainer didn't process my request, so it is BLATANTLY
  OBVIOUS that no other problems with the ARM port exist. I mean, come
  on, I've never been in a situation where more developer help would
  have been useful, so I 'frankly believe' such situations do not
  exist."

-- Thomas Bushnell BSG.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
A celebrity is a person who works hard all his life to become well known,
then wears dark glasses to avoid being recognized.
-- Fred Allen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Thomas Bushnell BSG]

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 back into testing, we
> need some developer help to debug and fix these problems.

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

So no, I frankly don't believe the "what we need is developer help to
debug and fix."  

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]