Re: buildd administration

[Frank Küster]

Ingo Juergensmann <[EMAIL PROTECTED]> wrote:

> On Thu, Dec 08, 2005 at 10:32:40PM +0100, Frank Küster wrote:
>
>> > Feature requests and other things are always welcome! I can't know what you
>> > want until you tell it to me. ;)
>> Nothing - these the questions I was mainly interested in regarding
>> buildd's:
>> - is my package already built everywhere, so that it can go into
>>   testing? 
>> - did it FTBFS, and do the logs give indication why?
>> - How can I get information from "inside" a buildd, e.g. temporary files
>>   created during a failed build.
>> The first two can be answered without buildd.net (and actually I never
>> was very much interested in "so when will it be built"?), the latter
>> needs, well, a buildd admin must contact me...
>
> A buildd admin doesn't see much more than what you can see in the build
> logs. Basically the build logs is all a buildd admin see. 

But the buildd admin for sure has read access to /tmp in the build
chroot?  Assuming that /tmp isn't cleared after each build, but just
every couple of hours/days/whatever.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: State of gcc 2.95 use in Debian unstable

[Heiko Müller]

Dear Thiemo,
we very much appreciate your work on the gcc-2.95 debian package.
For us - and probably also for other users in the scientific 
community - the "old" compiler version is still of great value.

We use gcc-2.95 to compile C/C++ code with very large mathematical 
expressions generated by computer algebra software. This involves 
very long (several thousand lines of code) functions to evaluate 
multi-variable polynomial expression resulting from perturbation 
theoretical solutions of physical problems. 

We found that gcc-2.95 -Os produces object code of acceptable quality 
within reasonable compilation times. gcc >=3 is less efficient w.r.t.
compilation time and memory consumption and in many cases even fails 
to compile our codes due to the very long expressions. The C/C++ codes
generated from the computer algebra software are perhaps unusual but 
not broken.

Since what we are doing is not so unusual in theoretical physics we are
probably not alone with these kind problems. Please consider that even 
if no other debian packages would depend on gcc-2.95 many users may 
very much require it.  

Best regards,
Heiko
 
-- 
Dr. Heiko Mueller  Englerstr. 28   Tel: +49 6221 89467-21
CEOS GmbH  D-69126 Heidelberg  Fax: +49 6221 89467-29
   Germany http://www.ceos-gmbh.de


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

Re: buildd administration

[Jeroen van Wolffelaar]

On Fri, Dec 09, 2005 at 09:43:36AM +0100, Frank Küster wrote:
> Ingo Juergensmann <[EMAIL PROTECTED]> wrote:
> 
> > On Thu, Dec 08, 2005 at 10:32:40PM +0100, Frank Küster wrote:
> >
> >> > Feature requests and other things are always welcome! I can't know what 
> >> > you
> >> > want until you tell it to me. ;)
> >> Nothing - these the questions I was mainly interested in regarding
> >> buildd's:
> >> - is my package already built everywhere, so that it can go into
> >>   testing? 
> >> - did it FTBFS, and do the logs give indication why?
> >> - How can I get information from "inside" a buildd, e.g. temporary files
> >>   created during a failed build.
> >> The first two can be answered without buildd.net (and actually I never
> >> was very much interested in "so when will it be built"?), the latter
> >> needs, well, a buildd admin must contact me...
> >
> > A buildd admin doesn't see much more than what you can see in the build
> > logs. Basically the build logs is all a buildd admin see. 
> 
> But the buildd admin for sure has read access to /tmp in the build
> chroot?  Assuming that /tmp isn't cleared after each build, but just
> every couple of hours/days/whatever.

Due to disk shoreage on a significant amount of buildd's, to the best of
my knowledge, the build tree is removed quite immediately after the
build finishes, and only a rebuild would be able to give you more info.

But surely, a porter owns the hardware in question too, and can simply
test-built it himself? *That* is work that any interested porter can do, 
in the process, debugging the problem, and ultimately filing a useful
bugreport, hopefully with patch -- and maybe do a porter NMU later, even
-- prefereable still with i386 or so so that it is verified that this
time around, the buildd indeed is capable of building the package.

Yes, there can be hardware or software (kernel) differences between
the porter's machine and the buildd. If that is the case, indeed one
should contact the buildd administrator in question if more info is
needed, but generally, I'd expect porters to be able to know their
hardware well enough to find out what the issue is anyway.

--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: buildd administration

[Frank Küster]

Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote:

> On Fri, Dec 09, 2005 at 09:43:36AM +0100, Frank Küster wrote:
>> Ingo Juergensmann <[EMAIL PROTECTED]> wrote:
>> >
>> > A buildd admin doesn't see much more than what you can see in the build
>> > logs. Basically the build logs is all a buildd admin see. 
>> 
>> But the buildd admin for sure has read access to /tmp in the build
>> chroot?  Assuming that /tmp isn't cleared after each build, but just
>> every couple of hours/days/whatever.
>
> Due to disk shoreage on a significant amount of buildd's, to the best of
> my knowledge, the build tree is removed quite immediately after the
> build finishes, and only a rebuild would be able to give you more info.

What do you mean with "build tree"?  I assume it's the tree where the
sources of the package are unpacked and dpkg-buildpackage is called?
This is not what I want.  In the case I am talking about, tetex-bin was
installed as a build-dependency, but failed in its postinst.  The other
package FTBFS, and a bug was filed against tetex-bin.  When tetex-bin's
postinst fails as it did there, it leaves a temporary file in /tmp, and
this file I wanted to investigate.  Even if /tmp had been cleaned
between the failed build and me sending the mail, the buildd admin could
have remembered this when he found the next package FTBFS the same way
(which happened in fact a couple of days later).

Since I didn't know a contact address, I wrote to debian-admin, and for
sure they would have been able to at least look into /var/debbuild/tmp/
and check whether our file was still there, but I didn't get a reply
from them, either.  And I still don't know whether there's a strange
corner case where tetex-bin fails to configure, or it was just a fcked
up /var/debbuild, or hardware problems on sarti.

> But surely, a porter owns the hardware in question too, and can simply
> test-built it himself? *That* is work that any interested porter can do, 
> in the process, debugging the problem, and ultimately filing a useful
> bugreport, hopefully with patch -- and maybe do a porter NMU later, even
> -- prefereable still with i386 or so so that it is verified that this
> time around, the buildd indeed is capable of building the package.

Since the package had been configured on hppa without problems
previously, it wasn't a simple architecture problem, and simply
installing it on hppa would not have revealed the bug.  Either there is
a bug, then it was a consequence of the specific order of installs,
removals, purges, and upgrades in the sarti debbuild environment; in
this case only looking at this environment could help to debug.  Or
sarti suffers from hardware problems.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Need pain pills?reply/ [EMAIL PROTECTED]

[Adrienne]

Re: buildd administration

[Anthony Towns]

On Thu, Dec 08, 2005 at 10:16:37PM -0800, Thomas Bushnell BSG wrote:
> Anthony Towns  writes:
> > That's non-sensical. Everything the buildds do is logged pretty much
> > immediately onto http://buildd.debian.org/, which also provides long
> > running statistics on how effective the buildds are, and even a schedule
> > of what the buildds will be working on next.
> That tells us what the buildds are doing.  It doesn't tell us anything
> about what the buildd admins are doing.

It tells you what the buildd admins are doing with the buildds.

It doesn't tell you why they're doing that, of course, but if that's
what you want to know you're better off creating an environment where
folks are interested in talking to you.

> > Well, the question is "are things wrong" ? AFAICS, they aren't -- and
> > when I suggested building a webpage tracking the complaints, the only
> > response was "ha, what a waste of time".
> Can you explain then why my recent request went unanswered for a
> month?

No, because I've no idea what your request was or what its importance
was compared to other pressing issues. If there was a page tracking such
issues that I could follow -- like the one Jeroen set up for tracking
and diagnosing removals needed from the archive prior to his inclusion
in the ftpteam -- I might be able to do so, but I understand you're
dismissive of that approach.

> > Ingo's burnt a fair number of bridges wrt buildd issues; I'm sorry,
> > but I don't really care if volunteers decline to work with people who're
> > obnoxious and rude.
> I do.  

That's your choice.

> > That's not a productive attitude. If they don't have time to answer
> > questions, they almost certainly don't have time to ask for help,
> > either. 
> Hogwash.  What seems to be absent from the mind of the people
> responsible is that when they don't have time, they can say "I don't
> have time to do this job anymore; I'm sorry, but I really would like
> to step down."  

Not at all. Indeed, that's happened in the past -- Joey and James
tried to close new-maintainer in July 1999 insisting they needed help,
and n-m continued in a crap state until October when James quit from
new-maintainer outright. It nevertheless took until April 2000 before
new maintainers began being accepted. And new-maintainer's not without
it's continuing problems even after that process. I don't think that's
a model that bears repeating, personally. You're welcome to your own
opinion of course.

> It is clear that some of the fiefdoms are run by people who adopt this
> attitude: "If you criticize me publicly, then I will slow-pedal your
> requests."  

Perhaps you should talk to Nathaniel, who seems to think public criticism
is effective in today's Debian, and work out some consensus reality.

> This is an infantile and counterproductive attempt to
> maintain control and a sense of superiority.  

I don't believe this is the case. If you believe you know the people
involved better than I do, and your judgement is thus better informed,
you are, again, welcome to it.

How many more years are we going to waste time with this hysteria before
realising it doesn't achieve anything but "rapidly sucking the fun out
of things"?

(BTW, I see #335981 and #336371 haven't received a response since late
October; or has raptor been down that entire time, so that you haven't been
able to diagnose it further -- it certainly seems down now?)

Cheers,
aj



signature.asc
Description: Digital signature

FYI, current mirror sizes

[Goswin von Brederlow]

Hi,

I got a bugreport requesting exected mirror sizes to be added to the
debmirror documentation and I thought some of you might be intrested
in them too. So heres the stats:

Mirror size for a singe arch and binary only (in MiB):

 | sarge | etch |  sid  |  all
-+---+--+---+---
main | 8816  | 9126 | 10777 | 20577
contrib  |  126  |  118 |   291 |   363
non-free |  282  |  345 |   464 |   666
d-i  |   44  |   28 |31 |78
all  | 9187  | 9536 | 11476 | 21502

Mirror size per arch (in MiB):

 | sarge | etch |  sid  |  all
-+---+--+---+---
source   |  9339 | 9419 | 11495 | 30252
all  |  4478 | 5047 |  6160 | 10459
alpha|  4256 | 3906 |  4732 |  9708
amd64|  3644 | 3635 |  4877 |  9152
arm  |  3445 | 3193 |  3933 |  7845
hppa |  4112 | 3713 |  4541 |  9167
i386 |  4422 | 3979 |  5005 | 10477
ia64 |  4709 | 4489 |  5316 | 11043
m68k |  3372 | 3072 |  3664 |  7139
mips |  3631 | 3364 |  4099 |  8237
mipsel   |  3560 | 3319 |  4049 |  8106
powerpc  |  4208 | 3967 |  4742 |  9915
s390 |  3673 | 3452 |  4144 |  8489
sparc|  3761 | 3585 |  4390 |  8893

All numbers reflect the state of 2005 Dec 9th.

MfG
Goswin


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

Re: buildd administration

[Goswin von Brederlow]

Anthony Towns  writes:

> On Thu, Dec 08, 2005 at 04:52:31PM -0500, Nathanael Nerode wrote:
>> To respond preemptively to one expected reply: "I don't have time to answer 
>> these questions" is not a reasonable excuse, because if they don't have 
>> time, 
>> they need to ask for help.
>
> That's not a productive attitude. If they don't have time to answer
> questions, they almost certainly don't have time to ask for help,
> either. When that cirucmstance has arisen, the only way out is for others
> to work out what help's actually needed and wanted and to provide it.
> That's kinda hard, but no one promised taking over the world would
> be easy.

And that is exactly what is wrong with Debian. This crash and burn
attitude. Never ask for help even if you work yourself to death and
have to ignore 50% of the problems.

You have to ask for help before everything blows up. You have to ask
for help at a time when you still have some spare resources to train
extra help. Frankly for several key positions it seems way over due
for a scream for more volunteers.

On a practical side how should other people work out what help is
needed if they are untrained and unable to even grasp what the actualy
problems are? You can't help with a problem enclosed in a shroud of
mystery. People are blindly guessing that something is wrong and all
you are saying is: "No that's not it, he said so. Guess again."

>> >I also see the keyring's been updated 
>> >earlier this week, including both a replacement key for Horms from late
>> >last month, and Chip's requested updates.
>> Indeed, complaining on debian-devel appears to get results, doesn't it?
>
> No, it doesn't.
>
>> At least, that's the conclusion that a rational outside observer would come 
>> to.
>
> No, it's the conclusion a simplistic outside observer would come to,
> who failed to consider the possibility that the results may have come
> due to independent processes in spite of the hysterical complaints
> on debian-devel.
>
> It may be rational to note that that conclusion is being irrationally
> drawn, and start responding to hysterical complaints by delaying
> activities that'd otherwise be undertaken, of course. I'm idealistic
> enough to dislike that conclusion, but, well *shrug*.

Black Box science: Put X in, Y comes out.  --> conclusion: Doing X
produces Y.

Take the lid of the box so people can see what it is actualy
doing. ==> Transparency.

> Cheers,
> aj

MfG
Goswin


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

Re: buildd administration

[Daniel Jacobowitz]

On Fri, Dec 09, 2005 at 11:49:05PM +1000, Anthony Towns wrote:
> On Thu, Dec 08, 2005 at 10:16:37PM -0800, Thomas Bushnell BSG wrote:
> > Anthony Towns  writes:
> > > That's non-sensical. Everything the buildds do is logged pretty much
> > > immediately onto http://buildd.debian.org/, which also provides long
> > > running statistics on how effective the buildds are, and even a schedule
> > > of what the buildds will be working on next.
> > That tells us what the buildds are doing.  It doesn't tell us anything
> > about what the buildd admins are doing.
> 
> It tells you what the buildd admins are doing with the buildds.

No, sorry, it tells you what the admins are doing with the build logs.
I'm sure there's less of it nowadays than there used to be, but there's
always been a certain amount of handholding in the buildd system
configuration, et cetera.

I'm not saying that this all needs to be publicly logged.  I don't give
a rat's ass whether it is or not.  But please don't stand there saying
that the process is completely transparent.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


-- 
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 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: circular (source) dependencies!?

[Goswin von Brederlow]

Turbo Fredriksson <[EMAIL PROTECTED]> writes:

> I'm trying to build autoconf/automake on my semi woody...
>
> But that isn't going to well (to say the least). I really
> hate these two programs. It's always a mess to build them
> if you don't follow the latest and greatest (probably no
> faults to the maintainers though!)...
>
> Any idea how to get around this (easily)? Can this be fixed
> in the packages?

Use prebuild debs possibly with --force-depends.

Alternatively build them manualy. Possibly even configure them on a
sarge/etch/sid system and then compile on your semi woody. Once you
have them in /usr/local force the build-depends.

MfG
Goswin


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

Bug#342691: ITP: freetalk -- Freetalk is a console based Jabber client. It features a readline interface with completion of buddy names, commands and even ordinary English words! Freetalk is extensibl

[Baishampayan Ghose]

Package: wnpp
Severity: wishlist


* Package name: freetalk
  Version : 0.5
  Upstream Author : Anand Avati <[EMAIL PROTECTED]>, et al.
* URL : http://freetalk.nongnu.org
* License : GPL
  Description : Freetalk is a console based Jabber client.

Freetalk is a console based Jabber client. It features a readline
interface with completion of buddy names, commands and even ordinary
English words! Freetalk is extensible, configurable and scriptable
through a Guile interface.


-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.27
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: State of gcc 2.95 use in Debian unstable

[Goswin von Brederlow]

Heiko Müller <[EMAIL PROTECTED]> writes:

> We found that gcc-2.95 -Os produces object code of acceptable quality 
> within reasonable compilation times. gcc >=3 is less efficient w.r.t.
> compilation time and memory consumption and in many cases even fails 
> to compile our codes due to the very long expressions. The C/C++ codes
> generated from the computer algebra software are perhaps unusual but 
> not broken.

Can you send in a few (hopefully short) examples that fail as
bugreports?

There is probably nothing to do about compile time and memory
consuption but it should at least work. Maybe the compiled result is
even faster.

MfG
Goswin


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

Re: buildd administration

[Michael Banck]

On Thu, Dec 08, 2005 at 04:52:31PM -0500, Nathanael Nerode wrote:
> >I also see the keyring's been updated earlier this week, including
> >both a replacement key for Horms from late last month, and Chip's
> >requested updates.

> Indeed, complaining on debian-devel appears to get results, doesn't
> it?  At least, that's the conclusion that a rational outside observer
> would come to.  

Where should I best complain for your NM application to be cancelled?


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

Bug#342700: ITP: freehoo -- Freehoo is a free console based Yahoo! Messenger client.

[Baishampayan Ghose]

Package: wnpp
Severity: wishlist
Owner: Baishampayan Ghose <[EMAIL PROTECTED]>


* Package name: freehoo
  Version : 3.4.1
  Upstream Author : Anand Babu <[EMAIL PROTECTED]>, et al.
* URL : http://freehoo.nongnu.org
* License : GPL
  Description : Freehoo is a free console based Yahoo! Messenger client.

Freehoo is a freely available GNU messenger for Yahoo! protocol. It is
console based application with geeky "readline" and "guile"
interfaces.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686-smp
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)


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

Re: FYI, current mirror sizes

[Florian Weimer]

* Goswin von Brederlow:

> Mirror size per arch (in MiB):
>
>  | sarge | etch |  sid  |  all
> -+---+--+---+---
> source   |  9339 | 9419 | 11495 | 30252

This looks suspicious.  I expected that the total number would be
significantly less than the sum of the suites because some of the
quite a few of the .orig.tar.gz files are shared.


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

Re: buildd administration

[Josselin Mouette]

Le vendredi 09 décembre 2005 à 16:27 +0100, Michael Banck a écrit :
> On Thu, Dec 08, 2005 at 04:52:31PM -0500, Nathanael Nerode wrote:
> > Indeed, complaining on debian-devel appears to get results, doesn't
> > it?  At least, that's the conclusion that a rational outside observer
> > would come to.  
> 
> Where should I best complain for your NM application to be cancelled?

On what grounds?

Oh, and this kind of threat makes me sick. It just feels like, for you,
non-DD contributions are second-class contributions.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: buildd administration

[Josselin Mouette]

Le vendredi 09 décembre 2005 à 12:07 +1000, Anthony Towns a écrit :
> That's non-sensical. Everything the buildds do is logged pretty much
> immediately onto http://buildd.debian.org/, which also provides long
> running statistics on how effective the buildds are, and even a schedule
> of what the buildds will be working on next.

There is absolutely zero documentation on how the buildd network works.
You know, the things you have to be aware of if you want to give a hand.

> > When things go wrong, there is no useful contact address for the buildd 
> > maintainers or admins. 
> 
> Well, the question is "are things wrong" ? AFAICS, they aren't -- and
> when I suggested building a webpage tracking the complaints, the only
> response was "ha, what a waste of time".
> 
> I don't really understand the viewpoint that says fixing the problem
> isn't a "response" to pointing out a problem.

It isn't a response, because a problem you report isn't really fixed
until you've been warned it has been fixed. How do you know when you can
rely on the problem being fixed? How do you know whether the problem has
just vanished - meaning in can appear again - or has been dealt with?
How do you know whether your request has just been throwned to /dev/null
or delayed for a few days? I have to wonder all these things every time
I send an email to [EMAIL PROTECTED]

> > Meanwhile, buildd.debian.org *still* isn't using Ingo Juergesmann's 
> 
> Ingo's burnt a fair number of bridges wrt buildd issues; I'm sorry,
> but I don't really care if volunteers decline to work with people who're
> obnoxious and rude.

Why would it make his work not good for our use? The buildd.net software
is obviously much superior to buildd.debian.org, but it hasn't been
integrated; the fact his author is Ingo Juergesmann shouldn't matter.

> That's not a productive attitude. If they don't have time to answer
> questions, they almost certainly don't have time to ask for help,
> either. When that cirucmstance has arisen, the only way out is for others
> to work out what help's actually needed and wanted and to provide it.
> That's kinda hard, but no one promised taking over the world would
> be easy.

Sorry, but it's simply not possible. When you don't have the required
credentials, you can't do anything with the buildd network. When you
don't know personally its internals, which are not documented, you don't
even know where to start. I don't believe it's that easy to dig into
them.

> > Indeed, complaining on debian-devel appears to get results, doesn't it?
> 
> No, it doesn't.
> 
> > At least, that's the conclusion that a rational outside observer would come 
> > to.
> 
> No, it's the conclusion a simplistic outside observer would come to,
> who failed to consider the possibility that the results may have come
> due to independent processes in spite of the hysterical complaints
> on debian-devel.

Then, will someone explain what happened to get things fixed? You seem
to be fairly affirmative about this, so you probably know. Maybe you can
take a few minutes of your precious time to explain what was done and by
whom to the pitiful other developers. It could save a lot of time later,
if people ask things correctly and to the right person instead of
complaining and trolling in this mailing list.

> It may be rational to note that that conclusion is being irrationally
> drawn, and start responding to hysterical complaints by delaying
> activities that'd otherwise be undertaken, of course. I'm idealistic
> enough to dislike that conclusion, but, well *shrug*.

Oh right, there is no problem with waiting for 2 months for a keyring
update. "Tout va très bien, Madame la marquise." Haven't you noticed
that while there can be obnoxious persons, most people start to complain
only when things become really unbearable? And believe me or not, but
the way some buildd administrators are treating email requests is not
something acceptable, even for volunteers.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: buildd administration

[Josselin Mouette]

Le vendredi 09 décembre 2005 à 23:49 +1000, Anthony Towns a écrit :
> How many more years are we going to waste time with this hysteria before
> realising it doesn't achieve anything but "rapidly sucking the fun out
> of things"?

How many developer resignations will you need to understand inaction
from people at key positions sucks the fun out of things in a worse way?

If the responsibility position isn't fun enough for the work to be done,
the person holding that position should resign. It probably required
some courage from you do resign from being release manager, and you
deserve credits for doing it instead of letting things rot.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: buildd administration

[Erinn Clark]

* Josselin Mouette <[EMAIL PROTECTED]> [2005:12:09 17:48 +0100]: 
> Le vendredi 09 d?cembre 2005 ? 12:07 +1000, Anthony Towns a ?crit :
> > Ingo's burnt a fair number of bridges wrt buildd issues; I'm sorry,
> > but I don't really care if volunteers decline to work with people who're
> > obnoxious and rude.
> 
> Why would it make his work not good for our use? The buildd.net software
> is obviously much superior to buildd.debian.org, but it hasn't been
> integrated; the fact his author is Ingo Juergesmann shouldn't matter.

Where is the buildd.net software located? I poked around on the site but
I couldn't find it except for the update-buildd.net script.

-- 
off the chain like a rebellious guanine nucleotide


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

Re: buildd administration

[Goswin von Brederlow]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> Le vendredi 09 décembre 2005 à 12:07 +1000, Anthony Towns a écrit :
>> That's non-sensical. Everything the buildds do is logged pretty much
>> immediately onto http://buildd.debian.org/, which also provides long
>> running statistics on how effective the buildds are, and even a schedule
>> of what the buildds will be working on next.
>
> There is absolutely zero documentation on how the buildd network works.
> You know, the things you have to be aware of if you want to give a hand.

There is documentation. Just not where you would normaly look. Try

http://buildd.net/

>> That's not a productive attitude. If they don't have time to answer
>> questions, they almost certainly don't have time to ask for help,
>> either. When that cirucmstance has arisen, the only way out is for others
>> to work out what help's actually needed and wanted and to provide it.
>> That's kinda hard, but no one promised taking over the world would
>> be easy.
>
> Sorry, but it's simply not possible. When you don't have the required
> credentials, you can't do anything with the buildd network. When you
> don't know personally its internals, which are not documented, you don't
> even know where to start. I don't believe it's that easy to dig into
> them.

And when you try you get screamed at and flamed as witnessed in the
huge buildd flame fest the last time. Iirc some 3000 packages were
build outside the official buildd network across the involved archs at
that time.

MfG
Goswin


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

Re: FYI, current mirror sizes

[Goswin von Brederlow]

Florian Weimer <[EMAIL PROTECTED]> writes:

> * Goswin von Brederlow:
>
>> Mirror size per arch (in MiB):
>>
>>  | sarge | etch |  sid  |  all
>> -+---+--+---+---
>> source   |  9339 | 9419 | 11495 | 30252
>
> This looks suspicious.  I expected that the total number would be
> significantly less than the sum of the suites because some of the
> quite a few of the .orig.tar.gz files are shared.

Right. Thanks for noticing. According to du -m it takes 18409 MiB.
The number comes from debmirror itself so there is something wrong
adding up the amount of downloads. Another bug to hunt.

MfG
Goswin


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

Re: buildd administration

[Manoj Srivastava]

On Fri, 9 Dec 2005 12:07:11 +1000, Anthony Towns  said: 

> That's not a productive attitude. If they don't have time to answer
> questions, they almost certainly don't have time to ask for help,
> either. When that cirucmstance has arisen, the only way out is for
> others to work out what help's actually needed and wanted and to
> provide it.  That's kinda hard, but no one promised taking over the
> world would be easy.

If they are too busy to ask for help (!!), then certainly the
 work they are tasked with is probably suffering as well; I mean, if
 they are too busy to ask for help, they are also likely to be too
 busy to do a good job.

Add to that the situations where people can not very easily
 help all by themselves (for example, if critical information required
 to perform the task is unavailable to the unwashed masses), it seems
 to me that this is the purvey of the DPL, who ought to be looking to
 add people to the delegate team. Indeed, this is solidly one of the
 major tasks of the DPL, to ensure that the delegates are able to
 perform their delegated tasks, and to provide additional help when
 they are burning out are far too busy.

Branden, isn't this issue of delegation one of the foundations
 of your platform?

manoj
-- 
"A complex system that works is invariably found to have evolved from
a simple system that worked." -- John Gall, _Systemantics_
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: buildd administration

[Manoj Srivastava]

On Fri, 9 Dec 2005 16:27:10 +0100, Michael Banck <[EMAIL PROTECTED]> said: 

> On Thu, Dec 08, 2005 at 04:52:31PM -0500, Nathanael Nerode wrote:
>> >I also see the keyring's been updated earlier this week, including
>> >both a replacement key for Horms from late last month, and Chip's
>> >requested updates.

>> Indeed, complaining on debian-devel appears to get results, doesn't
>> it?  At least, that's the conclusion that a rational outside
>> observer would come to.

> Where should I best complain for your NM application to be
> cancelled?

Err, so if a NM candidate speaks as openly as some DD's do,
 they get threatened with  having their applications cancelled because
 of them speaking their minds? What is this, a munich beer hall in
 1933?

manoj
 disgusted
-- 
Miguel Cervantes wrote Donkey Hote.  Milton wrote Paradise Lost, then
his wife died and he wrote Paradise Regained.
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: buildd administration

[Erinn Clark]

* Manoj Srivastava <[EMAIL PROTECTED]> [2005:12:09 12:47 -0600]: 
> Err, so if a NM candidate speaks as openly as some DD's do,
>  they get threatened with  having their applications cancelled because
>  of them speaking their minds? What is this, a munich beer hall in
>  1933?

Isn't the point of NM to "weed out" people before they become
problematic DDs? My impression was that this applied to overall
personality / how well you play with others, as well as technical
ability. Surely flaming people on mailing lists as a way to get things
done is not something people want to encourage in NMs... right? Wouldn't
Debian want to find people who can think of new and inventive ways to
achieve goals rather than resorting to these measures? Especially since
they *don't work*.

-- 
off the chain like a rebellious guanine nucleotide


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

Re: buildd administration

[Jeroen van Wolffelaar]

On Fri, Dec 09, 2005 at 05:48:13PM +0100, Josselin Mouette wrote:
> Le vendredi 09 décembre 2005 à 12:07 +1000, Anthony Towns a écrit :
> > That's non-sensical. Everything the buildds do is logged pretty much
> > immediately onto http://buildd.debian.org/, which also provides long
> > running statistics on how effective the buildds are, and even a schedule
> > of what the buildds will be working on next.
> 
> There is absolutely zero documentation on how the buildd network works.
> You know, the things you have to be aware of if you want to give a hand.

http://www.debian.org/devel/buildd/

The 3 html pages above contain about 3500 words of explanation about the
buildd network. Plus there is the source, and quite a number of people
with pretty good insight -- insight you too can become if you're
starting to read up about what it is, reading various sources, talk to
various people about it, etc. Ryan Murray didn't tell me much if
anything about the buildd network when I was trying to understand it,
because I had no reason to go ask him -- yes, documentation is certainly
not perfect, but that's a general issue of most of the things in the
free software world. Numerous people have shown that if you just try,
you'll find plenty of information.

What indeed really could be improved, and Frank Küster helpfully filed a
wishlist bug for that on www.d.o, is listing somewhere contact addresses
for the buildd admins in case there is a buildd-system related issue.
Isn't it more productive anyway that if there's percieved lack of
documentation to simply actively work on that, rather than complaining
loudly? Or that if you think the process itself has flaws or is
understaffed, to help productively, like Anthony Towns notes[1]?
Because, hey, Anthony is right there.

Let me tell you story of http://buildd.debian.org/~jeroen/status/ -- I
noticed that sometimes due to system crashes, network downtime, or
whatnot, a few packages might end up in state 'Building' for a prolonged
time, and that there was no automated mechanism to unstuck it -- it
needed someone to note that, and then the buildd admin requeued it.
Instead of complaining loudly about that on the lists, I asked myself
how this could be resolved. The first thing needed for that was
detection of the issue itself, so I wrote the above-mentioned page.
And I noted that the problem was much less than I thought. Anyway,
Steve Langasek picked up actually looking at it regularly, and feeding
back give-back suggestions to the buildd admins when needed. And after a
while he was granted full wanna-build access to do it himself, because
he has shown to understand how it works.

A similar issue I noted in the past is the big number of build failures
that don't get tagged 'Failed'. I tried working on classifying them, but
got bored so increadibly fast that I gave up, and decided for myself
this should be something the porters should rather look into. And thus I
mailed in June about that[2]. I don't believe anyone picked up that, but
I might be wrong, of course, my mail was hidden in a big thread about
various stuff, just like this very mail is... Someone interested in
porting (actually, I personally am myself not interested at all), should
maybe mail to all arch-specific lists some request similar to Vince
Sanders' request[3] regarding classifying arm failures.

--Jeroen

[1] http://lists.debian.org/debian-devel/2005/12/msg00323.html
[2] http://lists.debian.org/debian-devel/2005/06/msg00674.html
[3] http://lists.debian.org/debian-devel-announce/2005/12/msg2.html

-- 
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: buildd administration

[Thijs Kinkhorst]

On Fri, December 9, 2005 20:02, Erinn Clark wrote:
> Surely flaming people on mailing lists as a way to get things done
> is not something people want to encourage in NMs... right? Wouldn't Debian
> want to find people who can think of new and inventive ways to achieve
> goals rather than resorting to these measures? Especially since they
> *don't work*.

I'm not really convinced that such an approach would have a significant
effect as long as you're not measuring existing DD's to the same
standards. Which, as far as I can see, does not happen.


Thijs


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

Re: buildd administration

[Manoj Srivastava]

On Fri, 9 Dec 2005 14:02:17 -0500, Erinn Clark <[EMAIL PROTECTED]> said: 

> * Manoj Srivastava <[EMAIL PROTECTED]> [2005:12:09 12:47 -0600]:
>> Err, so if a NM candidate speaks as openly as some DD's do, they
>> get threatened with having their applications cancelled because of
>> them speaking their minds? What is this, a munich beer hall in
>> 1933?

> Isn't the point of NM to "weed out" people before they become
> problematic DDs? My impression was that this applied to overall
> personality / how well you play with others, as well as technical
> ability. Surely flaming people on mailing lists as a way to get
> things done is not something people want to encourage in
> NMs... right? Wouldn't Debian want to find people who can think of
> new and inventive ways to achieve goals rather than resorting to
> these measures? Especially since they *don't work*.

I'm surprised you think raising ones voice civilly in concern
 about a problem area in Debian is not  playing nicely with others. Is
 your contention that some volunteers are so much more equal than
 others that no voices may ever be raised in concern about their (lack
 of) performance ever again?

Nathaniel Nerode's postings have never been uncivil, they have
 never called anyone names, has never failed to respond in a manner
 which rises above civil discourse (at least, in the mails I have
 looked at, which were just this last 10 days or so) -- so I am forced
 to come to the conclusion that you must equate any dissent as not
 playing nice. In that light, how do you view your dissent with a
 member of the tech ctte and a senior debian developer? Would people
 be correctly justified in asking for you application to be rescinded
 as well?  (;-), for the humour impaired).

manoj
-- 
The big cities of America are becoming Third World countries. Nora
Ephron
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: buildd administration

[Erinn Clark]

* Manoj Srivastava <[EMAIL PROTECTED]> [2005:12:09 13:27 -0600]: 
> I'm surprised you think raising ones voice civilly in concern
>  about a problem area in Debian is not  playing nicely with others. Is
>  your contention that some volunteers are so much more equal than
>  others that no voices may ever be raised in concern about their (lack
>  of) performance ever again?

I just don't think encouraging flames is going to result in clever
solutions, which are, to me, far more interesting. One can voice their
concerns all day long and at the end of the day that is all they will
have achieved. Whooptee doo. But no, I am not trying to regulate free
speech, if that's what you mean. :)

>  so I am forced to come to the conclusion that you must equate any dissent 
>  as not playing nice. 

Aww.

-- 
off the chain like a rebellious guanine nucleotide


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

Re: buildd administration

[Manoj Srivastava]

On Fri, 9 Dec 2005 15:06:26 -0500, Erinn Clark <[EMAIL PROTECTED]> said: 

> * Manoj Srivastava <[EMAIL PROTECTED]> [2005:12:09 13:27 -0600]:
>> I'm surprised you think raising ones voice civilly in concern about
>> a problem area in Debian is not playing nicely with others. Is your
>> contention that some volunteers are so much more equal than others
>> that no voices may ever be raised in concern about their (lack of)
>> performance ever again?

> I just don't think encouraging flames is going to result in clever
> solutions, which are, to me, far more interesting.

Who was encouraging flames? Nathanael said:
On  Thu, 8 Dec 2005 16:52:31 -0500, Nathanael Nerode
<[EMAIL PROTECTED]> 
> Indeed, complaining on debian-devel appears to get results, doesn't
> it?  At least, that's the conclusion that a rational outside
> observer would come  to.  If that's an inaccurate conclusion, it
> indicates that there's something seriously wrong in the transparency
> of the processes. 

This is a qualified observation, not an encouragment -- unless
 you buy the observation, and subscribe to that approach -- in any
 case, implying that  Nathanael encouraged flaming is specious,
 slanderous, and incorrect.

> One can voice their concerns all day long and at the end of the day
> that is all they will have achieved. Whooptee doo. But no, I am not
> trying to regulate free speech, if that's what you mean. :)

No, however, you do seem to be slandering a fellow NM
 candidate. Please desist. Or provide some proof of your claim he is
 "encouraging flames".

manoj

-- 
Human industry, if left to itself, will naturally find its way to the
most useful and profitable employment.  -- Adam Smith
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: buildd administration

[Blars Blarson]

In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:

>- How can I get information from "inside" a buildd, e.g. temporary files
>  created during a failed build.

First pass answer: you can't.  sbuild (tries to) clean up after builds.

Alternate: try to get a porter to redo the build and give you the desired
info.

Best: rewrite your build script to put the desired info into the build log.
Instead of:
foo >/tmp/foo 2>&1
use:
if foo >/tmp/foo 2>&1 ; then : ; else cat /tmp/foo ; exit 1 ; fi






-- 
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: buildd administration

[Blars Blarson]

In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>Setting up a buildd system do not require extra privileges from the
>Debian project, as far as I know.  Any Debian developer with his
>public key in the keyring can sign uploads.

and get threats from the current buildd administrator to "make sure
you don't do that".  (Who could abuse his power as part of other teams
to do that.)  Been there, done that.

-- 
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: buildd administration

[Erinn Clark]

* Erinn Clark <[EMAIL PROTECTED]> [2005:12:09 12:45 -0500]: 
> * Josselin Mouette <[EMAIL PROTECTED]> [2005:12:09 17:48 +0100]: 
> > Le vendredi 09 d?cembre 2005 ? 12:07 +1000, Anthony Towns a ?crit :
> > > Ingo's burnt a fair number of bridges wrt buildd issues; I'm sorry,
> > > but I don't really care if volunteers decline to work with people who're
> > > obnoxious and rude.
> > 
> > Why would it make his work not good for our use? The buildd.net software
> > is obviously much superior to buildd.debian.org, but it hasn't been
> > integrated; the fact his author is Ingo Juergesmann shouldn't matter.
> 
> Where is the buildd.net software located? I poked around on the site but
> I couldn't find it except for the update-buildd.net script.

(Replying to myself after getting an answer on IRC from Ingo...)

The short summary to my answer is that buildd.net software is not
publicly available, which may explain at least part of the reason it's
not integrated. This was apparently explained in some other buildd
thread, but I'm not sure which one or where to look.

-- 
off the chain like a rebellious guanine nucleotide


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

Re: buildd administration

[Ingo Juergensmann]

On Fri, Dec 09, 2005 at 04:08:55PM -0500, Erinn Clark wrote:

> > Where is the buildd.net software located? I poked around on the site but
> > I couldn't find it except for the update-buildd.net script.
> (Replying to myself after getting an answer on IRC from Ingo...)
> The short summary to my answer is that buildd.net software is not
> publicly available, which may explain at least part of the reason it's
> not integrated. This was apparently explained in some other buildd
> thread, but I'm not sure which one or where to look.

Please stop assuming wrong facts. 
As I already stated several times before: Ryan was offered to integrate the
buildd.net software. He declined with the argument that all information is
already available on buildd.d.o. That's a clear sign that he doesn't want to
integrate it. Blame him, not me. And where is the source for
buildd.debian.org? 

-- 
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: Intel notebooks for needy developers in developing countries

[Andy Teijelo Pérez]

El Jueves, 8 de Diciembre de 2005 7:14, Andreas Schuldei escribió:
> ...
> i can try to come up with a list of countries if it helps.

For some reason I don't understand, hitting reply on most messages in the list 
brings up the new message window with the correct To: address 
(debian-devel@lists.debian.org), but hitting it on yours did not last night. 
Not until tody I realized about that. So I'm resending the message to the 
correct address:

Does a country considered by the U.S. government as terrorist, or with which 
having commercial relationships is forbidden for american companies, apply 
for this offering?
I'm far from being interested in these computers, but I think it's worth 
asking. Note the country in my email address.

Regards,
Andy.

Re: buildd administration

[Russ Allbery]

Ingo Juergensmann <[EMAIL PROTECTED]> writes:

> Please stop assuming wrong facts.

> As I already stated several times before: Ryan was offered to integrate
> the buildd.net software. He declined with the argument that all
> information is already available on buildd.d.o. That's a clear sign that
> he doesn't want to integrate it. Blame him, not me. And where is the
> source for buildd.debian.org?

If you want to replace an existing infrastructure, you have to clearly
demonstrate that the new stuff is better.  Saying that it's okay that the
new stuff isn't publically available because the old stuff isn't either
doesn't help the cause any.

Also, it's somewhat ironic that, in a thread where much has been made of
how overloaded the existing buildd administrators are, the offer of the
buildd software was made privately to one of those overloaded individuals.
(And were they then allowed to make it public?)

C'mon, this is a free software project.  The obvious first step for
providing better infrastructure would be to make that infrastructure
publically available for anyone to download, play with, hack on, or
otherwise evaluate, whether the existing infrastructure component is
similarly available or not.  I'd think this would just be common sense.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Intel notebooks for needy developers in developing countries

[Alejandro Bonilla]

On Fri, 9 Dec 2005 11:52:07 -0500, Andy Teijelo Pérez wrote
> El Jueves, 8 de Diciembre de 2005 7:14, Andreas Schuldei escribió:
> > ...
> > i can try to come up with a list of countries if it helps.
> 
> For some reason I don't understand, hitting reply on most messages 
> in the list brings up the new message window with the correct To: 
> address 
> (debian-devel@lists.debian.org), but hitting it on yours did not 
> last night. Not until tody I realized about that. So I'm resending 
> the message to the correct address:
> 
> Does a country considered by the U.S. government as terrorist, or 
> with which having commercial relationships is forbidden for american 
> companies, apply for this offering? I'm far from being interested in 
> these computers, but I think it's worth asking. Note the country in 
> my email address.

I can almost bet that Cuba is not getting any.

.Alejandro

> 
> Regards,
> Andy.



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

Re: Intel notebooks for needy developers in developing countries

[Andreas Schuldei]

* Andy Teijelo Pérez <[EMAIL PROTECTED]> [2005-12-09 11:52:07]:
> Does a country considered by the U.S. government as terrorist, or with which 
> having commercial relationships is forbidden for american companies, apply 
> for this offering?

I got some wise advice about not to make the contry the ulitmate
critera (and to NOT give a list of countries).

So if there would live a person in cuba working hard on debian
and being unable to afford a computer, I would not exclude him
because the US government does not like cuba. (I come from the
old europe myself, after all. :-)

I am not the one makeing the ulitmate decision, though. I just
put together the list.




signature.asc
Description: Digital signature

ALSA packager needed

[Thomas Hood]

The ALSA packaging team needs help.  We really need someone with expertise
in programming for the ALSA library.  If you are able to help us, please
contact us at [EMAIL PROTECTED]

-- 
Thomas Hood


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

Re: State of gcc 2.95 use in Debian unstable

[Matthias Klose]

Heiko Müller writes:
> We found that gcc-2.95 -Os produces object code of acceptable quality 
> within reasonable compilation times. gcc >=3 is less efficient w.r.t.

please be more precise. Debian currently uses 4.0, and has a 4.1
prerelease in the archives (gcc-snapshot). such regressions are best
filed as bug reports with a self-contained example.

thanks, Matthias

Co-maintainers sought

[Thomas Hood]

I seek co-maintainers for:

mwavem
thinkpad, tpctl
resolvconf

-- 
Thomas Hood


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

Re: Intel notebooks for needy developers in developing countries

[Alejandro Bonilla Beeche]

Andreas Schuldei wrote:


* Andy Teijelo Pérez <[EMAIL PROTECTED]> [2005-12-09 11:52:07]:
 

Does a country considered by the U.S. government as terrorist, or with which 
having commercial relationships is forbidden for american companies, apply 
for this offering?
   



I got some wise advice about not to make the contry the ulitmate
critera (and to NOT give a list of countries).

So if there would live a person in cuba working hard on debian
and being unable to afford a computer, I would not exclude him
because the US government does not like cuba. (I come from the
old europe myself, after all. :-)
 

I couldn't care less about the US government. Is just the fact that if 
the PC is done in any of the associated countries, they are not allowed 
to distribute to those countrys. In other words, MIT, Intel, AMD or 
whoever OEM that is actually part of the US would never be allowed to 
ship to Cuba. Never. It would have to be all done by some Japan company 
or so.


.Alejandro


I am not the one makeing the ulitmate decision, though. I just
put together the list.


 




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

Re: Intel notebooks for needy developers in developing countries

[Bartosz Fenski aka fEnIo]

On Sat, Dec 10, 2005 at 12:14:59AM +0100, Andreas Schuldei wrote:
> > having commercial relationships is forbidden for american companies, apply 
> > for this offering?
> 
> I got some wise advice about not to make the contry the ulitmate
> critera (and to NOT give a list of countries).
> 
> So if there would live a person in cuba working hard on debian
> and being unable to afford a computer, I would not exclude him
> because the US government does not like cuba. (I come from the
> old europe myself, after all. :-)
> 
> I am not the one makeing the ulitmate decision, though. I just
> put together the list.

Yeah that would be a real pain to exlude countries because of stupid
political 'correctness'. All in all in Free Software movement we don't know
what the borders are, do we?

regards
fEnIo
-- 
  ,''`.  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo
 : :' :   32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland
 `. `'   phone:+48602383548 | proud Debian maintainer and user
   `-  http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001


signature.asc
Description: Digital signature

Re: buildd administration

[John Hasler]

Erinn Clark writes:
> Surely flaming people on mailing lists as a way to get things done is not
> something people want to encourage in NMs... right?

Right.  After all, as we all know, no DD would ever do such a thing.
-- 
John Hasler


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

Re: buildd administration

[Anthony Towns]

On Fri, Dec 09, 2005 at 10:19:46AM -0500, Daniel Jacobowitz wrote:
> I'm not saying that this all needs to be publicly logged.  I don't give
> a rat's ass whether it is or not.  But please don't stand there saying
> that the process is completely transparent.

I don't believe I said that. I don't believe it's remotely fair to set
the standard at the unreachable level of perfection, either.

The major task of buildd maintenance (aiui) is handlings logs though,
and that's certainly what was being complained about earlier. I'd
be interested to see you name an area that's had anything like the
transparency w-p provides the build process though. I guess there's
britney, which gives public logs of what's going on, but also requires
a degree of handholding every now and then that isn't particularly logged.

Cheers,
aj



signature.asc
Description: Digital signature

Re: buildd administration

[Anthony Towns]

On Fri, Dec 09, 2005 at 05:56:24PM +0100, Josselin Mouette wrote:
> Le vendredi 09 décembre 2005 à 23:49 +1000, Anthony Towns a écrit :
> > How many more years are we going to waste time with this hysteria before
> > realising it doesn't achieve anything but "rapidly sucking the fun out
> > of things"?
> How many developer resignations will you need to understand inaction
> from people at key positions sucks the fun out of things in a worse way?

Yeah, threatening resignations, that sure is fun!

> If the responsibility position isn't fun enough for the work to be done,
> the person holding that position should resign. It probably required
> some courage from you do resign from being release manager, and you
> deserve credits for doing it instead of letting things rot.

Actually it required complete disinterest in the entire process; I made
the decision when the "Let's force in amd64 in spite of what anyone
says" GR got proposed. What required time, skill, planning and energy
was the process of actually teaching other folks the skills they needed
to help out; of the five volunteers only two worked out. At least by
now I'm only amused that your best characterisation of my time as RM is
"letting things rot".

Cheers,
aj



signature.asc
Description: Digital signature

Re: buildd administration

[Anthony Towns]

On Fri, Dec 09, 2005 at 04:27:10PM +0100, Michael Banck wrote:
> On Thu, Dec 08, 2005 at 04:52:31PM -0500, Nathanael Nerode wrote:
> > >I also see the keyring's been updated earlier this week, including
> > >both a replacement key for Horms from late last month, and Chip's
> > >requested updates.
> > Indeed, complaining on debian-devel appears to get results, doesn't
> > it?  At least, that's the conclusion that a rational outside observer
> > would come to.  
> Where should I best complain for your NM application to be cancelled?

You can direct concerns about candidates to [EMAIL PROTECTED], which
will be taken into account when the AM's report is being evaluated. I
presume it takes quite a few comments from different developers before
those would override the AM's recommendation though.

Positive comments can also be sent there (as an additional "advocate"
round, I guess), and are AIUI particularly appreciated, since that gives
more support to accepting a candidate, which is, after all, what almost
always happens at that point.

Cheers,
aj



signature.asc
Description: Digital signature

Re: buildd administration

[Anthony Towns]

On Fri, Dec 09, 2005 at 05:48:13PM +0100, Josselin Mouette wrote:
> There is absolutely zero documentation on how the buildd network works.

If the documentation's insufficient, ask politely for help.
buildd.debian.org points you at wanna-build and its svn repo, which has
some reasonably extensive READMEs as well as all the source.

> You know, the things you have to be aware of if you want to give a hand.

$ lynx -dump http://bugs.debian.org/release-critical/other/all.html | 
> grep FTBFS | wc
4174195   31201

> > I don't really understand the viewpoint that says fixing the problem
> > isn't a "response" to pointing out a problem.
> It isn't a response, because a problem you report isn't really fixed
> until you've been warned it has been fixed.

*shrug* Sure, there are better possible responses. At some point you have
to accept that resolving your uncertanties isn't as important as other
things people could be doing. If you actually want to get that better
result, the way your going about advocating for it is *precisely* wrong.

> Sorry, but it's simply not possible. When you don't have the required
> credentials, you can't do anything with the buildd network.  When you
> don't know personally its internals, which are not documented, you don't
> even know where to start. I don't believe it's that easy to dig into
> them.

I've never run a buildd; I've never invoked sbuild; I don't think I have
login access on any buildds, though I might be wrong.

That hasn't stopped me getting access to the w-b groups on buildd.d.o
(which was to enable britney to do better stats), and I even got to sign
my first build log the other day to test the security stuff I've been
working on. My strategy for this is to work around not having access,
recognise other people have different priorities to me and that they're
only going to do what I want when our priorities match, and be polite
about it all.

I think it says something when that strategy, which afaics has proven
successful repeatedly, is dismissed as "too hard".

> Then, will someone explain what happened to get things fixed? You seem
> to be fairly affirmative about this, so you probably know. 

There were some private conversations that, AIUI, it'd be "unethical and
possibly illegal" for me to quote, and I doubt you'd accept any summary I
might make. The DPL has the same information I do, though, as a response
to his querying what was going on, and I believe his position is "with
a single elected DPL, there is still someplace for "the buck to stop",
as a U.S. idiom puts it.", so maybe it's worth asking him.

> It could save a lot of time later,
> if people ask things correctly and to the right person instead of
> complaining and trolling in this mailing list.

If you follow the advice above, you won't have any problems.

> Oh right, there is no problem with waiting for 2 months for a keyring
> update. 

An update for a key that was confiscated as part of a police raid months
beforehand? I don't think there's a really major problem, no.

> Haven't you noticed
> that while there can be obnoxious persons, most people start to complain
> only when things become really unbearable? 

No, I haven't noticed that at all.

Well, let me rephrase. I've noticed most people don't start to complain
at all, whether things are bearable or not. Most of the complaints,
meanwhile, are from people who'll complain no matter what (more or less),
and don't give a damn whether their complaints are effective or not.

Obviously, YMMV.

Cheers,
aj



signature.asc
Description: Digital signature

Re: buildd administration

[Matthew Garrett]

Josselin Mouette <[EMAIL PROTECTED]> wrote:
> Le vendredi 09 décembre 2005 à 23:49 +1000, Anthony Towns a écrit :
>> How many more years are we going to waste time with this hysteria before
>> realising it doesn't achieve anything but "rapidly sucking the fun out
>> of things"?
> 
> How many developer resignations will you need to understand inaction
> from people at key positions sucks the fun out of things in a worse way?

Reading these threads makes me want to resign. WILL YOU NOT THINK OF THE
CHILDREN?

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: buildd administration

[Matthew Garrett]

Thijs Kinkhorst <[EMAIL PROTECTED]> wrote:

> I'm not really convinced that such an approach would have a significant
> effect as long as you're not measuring existing DD's to the same
> standards. Which, as far as I can see, does not happen.

A procedure is in place for developers to be ejected from the project.
If you feel that anyone is behaving in a way that would not have allowed
them to get through NM, then please do invoke it.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: buildd administration

[Daniel Jacobowitz]

On Sat, Dec 10, 2005 at 11:46:50AM +1000, Anthony Towns wrote:
> On Fri, Dec 09, 2005 at 10:19:46AM -0500, Daniel Jacobowitz wrote:
> > I'm not saying that this all needs to be publicly logged.  I don't give
> > a rat's ass whether it is or not.  But please don't stand there saying
> > that the process is completely transparent.
> 
> I don't believe I said that. I don't believe it's remotely fair to set
> the standard at the unreachable level of perfection, either.

You said that the logs tell you what the buildd admins are doing with
the buildd.  I disagree.

> The major task of buildd maintenance (aiui) is handlings logs though,
> and that's certainly what was being complained about earlier. I'd
> be interested to see you name an area that's had anything like the
> transparency w-p provides the build process though. I guess there's
> britney, which gives public logs of what's going on, but also requires
> a degree of handholding every now and then that isn't particularly logged.

The majority of "handling" logs is monkeywork - very easy, mostly
automated.  The main jobs of the buildd admin are to (A) provide a
human sanity check on what's getting built successfully; I am and
always have been somewhat dubious of the value of this, even when I was
doing it; and (B) doing something about the failures.

What buildd.debian.org logs is the output of the sbuild runs.  We
have great visibility into what _sbuild_ is doing.  But what the
_buildd admin_ is doing is, by and large, taking care of the failures:
whether that means dep-waiting them, filing bugs because of them,
poking anything obscure that caused the buildd environment to get
broken (e.g. when a package fails to uninstall, or a broken package
fills the disk with logs).  This stuff doesn't get logged, nor would it
be particularly easy to log.

The current buildd admins don't seem to be very responsive about filing
bugs for the failures; they tend to sit for rather a long time unless
porters, or package maintainers, go out and stare at the logs on their
own.  But my sample size for this last bit is small, so take it with a
grain of salt.

I don't think that the human step of signing the successful logs has
any value nowadays.  The closest a human can go to checking the volume
of mail a buildd produces is running it through some clever procmail
filters, anyway.  Or reading through any logs that strike them as
particularly interesting.  I don't have handy stats about the volume of
mail produced by the buildd anymore, but voltaire's currently pumping
out about eighty thousand lines a day over the last week and a half, if
I'm looking at the right logs.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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

Re: buildd administration

[Thomas Bushnell BSG]

Anthony Towns  writes:

> On Thu, Dec 08, 2005 at 10:16:37PM -0800, Thomas Bushnell BSG wrote:
>> Anthony Towns  writes:
>> > That's non-sensical. Everything the buildds do is logged pretty much
>> > immediately onto http://buildd.debian.org/, which also provides long
>> > running statistics on how effective the buildds are, and even a schedule
>> > of what the buildds will be working on next.
>> That tells us what the buildds are doing.  It doesn't tell us anything
>> about what the buildd admins are doing.
>
> It tells you what the buildd admins are doing with the buildds.

No.  It tells us some of what they are doing.  It does not tell us
everything; sometimes there are problems which are hard to diagnose
without more specific information.

> It doesn't tell you why they're doing that, of course, but if that's
> what you want to know you're better off creating an environment where
> folks are interested in talking to you.

I see.  Can we please post a list of the Debian developers who have
blacklists like this, and exclude them from single-point-of-failure
jobs?  Is it ok for me to decide to ignore bug reports from people,
merely on the grounds that I am not interested in talking to someone?

> No, because I've no idea what your request was or what its importance
> was compared to other pressing issues. 

It was poisted on debian-release.

> If there was a page tracking such
> issues that I could follow -- like the one Jeroen set up for tracking
> and diagnosing removals needed from the archive prior to his inclusion
> in the ftpteam -- I might be able to do so, but I understand you're
> dismissive of that approach.

No, not in the least.  That's a good start, but for it to be an
excellent start, it needs to work like the BTS, and be something that
the relevant volunteers themselves read and pay attention to.

> Not at all. Indeed, that's happened in the past -- Joey and James
> tried to close new-maintainer in July 1999 insisting they needed help,
> and n-m continued in a crap state until October when James quit from
> new-maintainer outright. It nevertheless took until April 2000 before
> new maintainers began being accepted. And new-maintainer's not without
> it's continuing problems even after that process. I don't think that's
> a model that bears repeating, personally. You're welcome to your own
> opinion of course.

I'm not sure I understand.  Joey and James tried to *close*, which is
not at all the same thing.  Indeed, my recollection was that they
resisted any actual help, they insisted that their role was absolutely
essential, and both refused to process applications and refused to let
anyone else take over the work.  Finally James stopped, and things
began to slowly improve.

>> It is clear that some of the fiefdoms are run by people who adopt this
>> attitude: "If you criticize me publicly, then I will slow-pedal your
>> requests."  
>
> Perhaps you should talk to Nathaniel, who seems to think public criticism
> is effective in today's Debian, and work out some consensus reality.

No, I don't think it's effective.  I think it's counter-productive.
But that does *not* mean that it's not *equally* counter-productive to
maintain blacklists, ignore email, refuse to post status reports or
discuss issues, and the like.  Indeed, I think those things are ever
more counter-productive.

Moreover, if those things are done, the public criticism tends to
get massively reduced pretty quickly, because if it's misplaced,
everyone can clearly see.

An excellent example of this is the publication of the NEW queue.  Now
that everyone can see the NEW queue, I don't see any of the big public
criticism about slow processing.

>> This is an infantile and counterproductive attempt to
>> maintain control and a sense of superiority.  
>
> I don't believe this is the case. If you believe you know the people
> involved better than I do, and your judgement is thus better informed,
> you are, again, welcome to it.

Actually, we don't know who the people are at all.  One cannot even
find out the *names* of the people doing this work.

> (BTW, I see #335981 and #336371 haven't received a response since late
> October; or has raptor been down that entire time, so that you haven't been
> able to diagnose it further -- it certainly seems down now?)

Upstream is working on #335981 and #336371.  In fact, scm has *never*
supported s390; when I took over maintenance of the package I opened
the bugs so that it could be more effectively tracked.

And since I am the one who opened #335981, I don't really think a
reply to myself is all that necessary.  #336371 was opened as a result
of a normal build failure, by someone who performs the useful task of
opening FTBFS bugs when appropriate; a personal reply does not seem
necessary.

Certainly if I received a question about the bugs, I would reply as
soon as practicable.

Thomas


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

Re: buildd administration

[Thomas Bushnell BSG]

Anthony Towns  writes:

> The major task of buildd maintenance (aiui) is handlings logs though,
> and that's certainly what was being complained about earlier. 

No.  What I was complaining about was totally ignoring of requeue
requests sent to the @buildd.debian.org advertised addresses.

Thomas


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

Re: buildd administration

[Goswin von Brederlow]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Ingo Juergensmann <[EMAIL PROTECTED]> writes:
>
>> Please stop assuming wrong facts.
>
>> As I already stated several times before: Ryan was offered to integrate
>> the buildd.net software. He declined with the argument that all
>> information is already available on buildd.d.o. That's a clear sign that
>> he doesn't want to integrate it. Blame him, not me. And where is the
>> source for buildd.debian.org?
>
> If you want to replace an existing infrastructure, you have to clearly
> demonstrate that the new stuff is better.  Saying that it's okay that the
> new stuff isn't publically available because the old stuff isn't either
> doesn't help the cause any.
>
> Also, it's somewhat ironic that, in a thread where much has been made of
> how overloaded the existing buildd administrators are, the offer of the
> buildd software was made privately to one of those overloaded individuals.
> (And were they then allowed to make it public?)

He is the only contact address mentioned. Who else should get an offer?

> C'mon, this is a free software project.  The obvious first step for
> providing better infrastructure would be to make that infrastructure
> publically available for anyone to download, play with, hack on, or
> otherwise evaluate, whether the existing infrastructure component is
> similarly available or not.  I'd think this would just be common sense.

You can test and play around with buildd.net all you want and easily
see "its superiority". You can also contact Ingo and ask him for the
scripts, as I have done, and you may recieve them. Something that I
found impossible for buildd.d.o.

Ingo is offering a service and paying for it. That he isn't throwing
the source at anyone casualy stumbling accross his site should hinder
anyone intrested.

MfG
Goswin


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

Re: buildd administration

[Goswin von Brederlow]

Anthony Towns  writes:

> On Fri, Dec 09, 2005 at 10:19:46AM -0500, Daniel Jacobowitz wrote:
>> I'm not saying that this all needs to be publicly logged.  I don't give
>> a rat's ass whether it is or not.  But please don't stand there saying
>> that the process is completely transparent.
>
> I don't believe I said that. I don't believe it's remotely fair to set
> the standard at the unreachable level of perfection, either.
>
> The major task of buildd maintenance (aiui) is handlings logs though,
> and that's certainly what was being complained about earlier. I'd
> be interested to see you name an area that's had anything like the
> transparency w-p provides the build process though. I guess there's
> britney, which gives public logs of what's going on, but also requires
> a degree of handholding every now and then that isn't particularly logged.
>
> Cheers,
> aj

Which in no way provides any transparency to @buildd.d.o, which
was being complained about earlier.

MfG
Goswin


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

Re: buildd administration

[Russ Allbery]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:

>> C'mon, this is a free software project.  The obvious first step for
>> providing better infrastructure would be to make that infrastructure
>> publically available for anyone to download, play with, hack on, or
>> otherwise evaluate, whether the existing infrastructure component is
>> similarly available or not.  I'd think this would just be common sense.

> You can test and play around with buildd.net all you want and easily see
> "its superiority". You can also contact Ingo and ask him for the
> scripts, as I have done, and you may recieve them. Something that I
> found impossible for buildd.d.o.

> Ingo is offering a service and paying for it. That he isn't throwing the
> source at anyone casualy stumbling accross his site should hinder anyone
> intrested.

I wholeheartedly approve of the decision to decline to use the software of
people with this attitude towards free software as part of the core Debian
infrastructure.  It's one thing to have the source diverge due to lack of
time, but the above rings TONS of MAJOR warning bells for me.  It sounds
very much like the sort of conversation that I get into with vendors who
are trying to say they do "open source" without actually doing anything of
the sort.

Much of what we do here is *exactly* about throwing the source at anyone
casually stumbling across our site.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: buildd administration

[Anthony Towns]

On Fri, Dec 09, 2005 at 07:24:00PM -0800, Thomas Bushnell BSG wrote:
> An excellent example of this is the publication of the NEW queue.  Now
> that everyone can see the NEW queue, I don't see any of the big public
> criticism about slow processing.

Well, that's not very interesting, because the processing isn't slow
anymore which could well be the cause. 

Fortunately we can differentiate those two explanations, because there
was a time when the NEW queue was visible and processing remained slow,
between 17th Feb 2005 [0] and 18th March 2005 [1] or so. If transparency
were the fix, then there shouldn't've been any "big public criticism
about slow processing" in that time. Unfortunately for that theory,
there was, see [2]. Really, that theory was screwed from the beginning,
since that information has *always* been available, although not in as
nice a form as it currently is.

That sort of information is helpful to tell you when there is a problem,
but that's only the first step. ATM, the corresponding thing would
be to (gosh!) setup a webpage tracking whatever issue you don't think
is receiving enough attention, so people can see if it is actually a
problem. The way to then go about solving it is *politely* working *with*
the people who're currently involved.

Okay, I guess I've made that point enough for this round. See y'all
again next month! What are we up for next anyway? N-M?

Cheers,
aj

[0] http://lists.debian.org/debian-devel/2005/02/msg00795.html
[1] http://lists.debian.org/debian-project/2005/03/msg00142.html
[2] http://lists.debian.org/debian-devel/2005/03/msg00291.html


signature.asc
Description: Digital signature

Re: buildd administration

[Anthony Towns]

On Fri, Dec 09, 2005 at 07:25:14PM -0800, Thomas Bushnell BSG wrote:
> Anthony Towns  writes:
> > The major task of buildd maintenance (aiui) is handlings logs though,
> > and that's certainly what was being complained about earlier. 
> No.  What I was complaining about was totally ignoring of requeue
> requests sent to the @buildd.debian.org advertised addresses.

Requeue requests are part of handling logs... You get a failed log, you
analyse it to say "oh, that's a transient error due to other things"
then you requeue it... If that analysis comes from reading a mail,
great.

Cheers,
aj



signature.asc
Description: Digital signature

Re: buildd administration

[Anthony Towns]

On Fri, Dec 09, 2005 at 10:11:12PM -0500, Daniel Jacobowitz wrote:
> The majority of "handling" logs is monkeywork - very easy, mostly
> automated.  The main jobs of the buildd admin are to

The job of the buildd admin is to make sure packages are built. Mostly
that's automated, which is great, which means the buildd admin's job is
mostly to keep the automation working.

>   (A) provide a
> human sanity check on what's getting built successfully; I am and
> always have been somewhat dubious of the value of this, even when I was
> doing it; and (B) doing something about the failures.

By and large its the porters that need to do something about failures;
which is to say, working out the problem and uploading a fix. The
buildds job wrt failures is to make sure they're not caused by
brokenness in the build setup, which is one place the human sanity check
comes in. Likewise when the RMs are trying to coordinate transitions,
and packages need to not be autobuild on old libraries, or need to be
mass-binNMUed.

> What buildd.debian.org logs is the output of the sbuild runs.  We
> have great visibility into what _sbuild_ is doing.  But what the
> _buildd admin_ is doing is, by and large, taking care of the failures:

I don't think that's a valid way of splitting things up. The job is to
build packages; if that's being done mostly well, that's great. If the
other bits could be done better, well, fine.

> The current buildd admins don't seem to be very responsive about filing
> bugs for the failures; 

That's been the case for quite a while now from what I've seen; but OTOH,
there are plenty of FTBFS bugs that just don't get attention anyway. It's
also something competent porters can take over fairly trivially -- simply
by looking through the buildd.d.o logs and analysing the failures that
they can reproduce themselves.

> I don't think that the human step of signing the successful logs has
> any value nowadays.  

The value it has is that the key doesn't get put on a machine that's
running random scripts day-in/day-out. Delaying signing 'til the end of
the day gives you some chance to learn of problems that might apply to
successful builds too. Someone with a particular interest might like
to analyse this, but I don't think signing successful logs is much of
a problem.

> I don't have handy stats about the volume of
> mail produced by the buildd anymore, but voltaire's currently pumping
> out about eighty thousand lines a day over the last week and a half, if
> I'm looking at the right logs.

The number of lines isn't terribly interesting; you don't read build
logs like a book, you grep through them like an encyclopaedia at most.

Cheers,
aj



signature.asc
Description: Digital signature

Re: buildd administration

[Clint Adams]

> The job of the buildd admin is to make sure packages are built. Mostly
> that's automated, which is great, which means the buildd admin's job is
> mostly to keep the automation working.

Dan was a really good buildd admin.  Maybe he knows what he's talking
about.


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

Re: buildd administration

[Anthony Towns]

On Fri, Dec 09, 2005 at 07:24:00PM -0800, Thomas Bushnell BSG wrote:
> No, not in the least.  That's a good start, but for it to be an
> excellent start, it needs to work like the BTS, and be something that
> the relevant volunteers themselves read and pay attention to.

It doesn't actually need anyone else to pay attention to it; it just
needs to exist so people *can* pay attention to it.

> I'm not sure I understand.  Joey and James tried to *close*, which is
> not at all the same thing.  Indeed, my recollection was that they
> resisted any actual help, they insisted that their role was absolutely
> essential, and both refused to process applications and refused to let
> anyone else take over the work.  Finally James stopped, and things
> began to slowly improve.

Your recollection's mistaken. It's in the -private archives though, so
you can correct if if you like. Trivially though, you can note simply
from public information that things only actually improved -- in that
people got processed again -- when James *started* again, which is the
exact opposite of your mischaracterisation above.

> >> This is an infantile and counterproductive attempt to
> >> maintain control and a sense of superiority.  
> > I don't believe this is the case. If you believe you know the people
> > involved better than I do, and your judgement is thus better informed,
> > you are, again, welcome to it.
> Actually, we don't know who the people are at all.  One cannot even
> find out the *names* of the people doing this work.

Sure you can -- at the very least you just need to check the signatures
of autobuilt packages. If you're too lazy to do that (and hey, who
isn't?) you can check the qualification pages on the wiki, which has
most of that information too.

> > (BTW, I see #335981 and #336371 haven't received a response since late
> > October; or has raptor been down that entire time, so that you haven't been
> > able to diagnose it further -- it certainly seems down now?)
> Upstream is working on #335981 and #336371.  In fact, scm has *never*
> supported s390; 

   scm |5d9-4.1 |  unstable | s390

> when I took over maintenance of the package I opened
> the bugs so that it could be more effectively tracked.

RC bugs need to be *fixed*, not merely tracked.

Cheers,
aj



signature.asc
Description: Digital signature

Re: buildd administration

[Thomas Bushnell BSG]

Anthony Towns  writes:

> On Fri, Dec 09, 2005 at 07:25:14PM -0800, Thomas Bushnell BSG wrote:
>> Anthony Towns  writes:
>> > The major task of buildd maintenance (aiui) is handlings logs though,
>> > and that's certainly what was being complained about earlier. 
>> No.  What I was complaining about was totally ignoring of requeue
>> requests sent to the @buildd.debian.org advertised addresses.
>
> Requeue requests are part of handling logs... You get a failed log, you
> analyse it to say "oh, that's a transient error due to other things"
> then you requeue it... If that analysis comes from reading a mail,
> great.

So why was the request ignored for a month?  Why did my email result
in no action, twice, not even a response?

Perhaps you don't know the answer to these questions.  But then how
can you so surely assert that there is no problem?


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

Re: buildd administration

[Thomas Bushnell BSG]

Anthony Towns  writes:

> The job of the buildd admin is to make sure packages are built. Mostly
> that's automated, which is great, which means the buildd admin's job is
> mostly to keep the automation working.

So when the build admin is not doing that job, what should we do?


Thomas


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

Re: buildd administration

[Thomas Bushnell BSG]

Anthony Towns  writes:

>> Upstream is working on #335981 and #336371.  In fact, scm has *never*
>> supported s390; 
>
>scm |5d9-4.1 |  unstable | s390

And yet, it didn't actually run successfully on s390.  Support is not
just a matter of compiling.

>> when I took over maintenance of the package I opened
>> the bugs so that it could be more effectively tracked.
>
> RC bugs need to be *fixed*, not merely tracked.

Yes, and I'm working with upstream.  Supporting scheme on these
architectures is very tricky, because it needs to copy the stack and
do all kinds of cleverness, and Aubrey didn't have the hardware to do
it.  It cannot be done through generic code.  My involvement has been
to work on the porting itself, and more importantly, to hook Aubrey up
with the Debian porters in the hope of working on the problems and
improving support.  Worst case, I'll have to decide that s390 should
be removed from the supported list, but I'm not giving up yet.

Before you scold me further about the ONE release-critical bug in
packages I maintain, shall we start examining yours?

Moreover, please notice how despite a hostile and uncomprehending
question, I have answered your question as fully and completely as I
can.  I did not say, "Anthony is being a jerk, so I will ignore him."
I did not say, "From now on, I'll ignore Anthony."

Now, you'll be happy to do the same, right?

Thomas



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

Re: buildd administration

[Anthony Towns]

On Fri, Dec 09, 2005 at 09:40:11PM -0800, Thomas Bushnell BSG wrote:
> Anthony Towns  writes:
> > Requeue requests are part of handling logs... You get a failed log, you
> > analyse it to say "oh, that's a transient error due to other things"
> > then you requeue it... If that analysis comes from reading a mail,
> > great.
> So why was the request ignored for a month?  Why did my email result
> in no action, twice, not even a response?

I've told you what I'd need to answer that question already.

> Perhaps you don't know the answer to these questions.  But then how
> can you so surely assert that there is no problem?

Easy: the best tools we've got to judge whether buildds are keeping up
are the buildd graphs which indicate that with the exception of m68k
and arm (hrm, and possibly hppa), all our ports are doing extremely well.

Although I guess that's different from saying there's "no problem" if
you're being pedantically literal. I have no interest in that sort of
discussion though. *shrug*

Cheers,
aj



signature.asc
Description: Digital signature

Re: buildd administration

[Anthony Towns]

On Fri, Dec 09, 2005 at 09:44:59PM -0800, Thomas Bushnell BSG wrote:
> Anthony Towns  writes:
> >> Upstream is working on #335981 and #336371.  In fact, scm has *never*
> >> supported s390; 
> >scm |5d9-4.1 |  unstable | s390
> And yet, it didn't actually run successfully on s390.  Support is not
> just a matter of compiling.

Support's a matter of many things. One of those is ensuring you don't
have RC bugs. 

If a package is failing to build or to function on some architecture,
your job as that package's maintainer is see if it can be fixed (talking
to porters and/or upstream if it's beyond your skills), and if it can't
be fixed trivially, to note that it's not currently supported on that
architecture by both ensuring that non-working packages fail to build
(by editing the Architecture: line or adding appropriate test suites), and
passing that information on to others. In this case that means not having
a control file that explicitly declares s390 is a supported architecture,
and filing a bug against ftp.debian.org indicating that the s390 build
is broken and should be removed. That then warrants downgrading the s390
FTBFS bugs to important or wishlist.

As far as transparency goes; I'll note you didn't add anything to either
bug report indicating you're working with upstream. It's the silence
and the uncertainty over whether anything's actually being done to fix
anything that's the real issue, you know?

> >> when I took over maintenance of the package I opened
> >> the bugs so that it could be more effectively tracked.
> > RC bugs need to be *fixed*, not merely tracked.
> Yes, and I'm working with upstream.  

RC bugs need to be fixed as a matter of *urgency*, not over a matter of
months.

> Before you scold me further about the ONE release-critical bug in
> packages I maintain, shall we start examining yours?

I don't believe I have any open RC bugs, or any open FTBFS bugs, so
I don't see the relevance. But hey, if it'll make you feel better to
convince yourself that it's everyone else's fault and there's nothing
you can do, go ahead.

> Moreover, please notice how despite a hostile and uncomprehending
> question, 

It's amazing how it's always "hostile and uncomprehending" when it's
you that's being questioned, yet when you're doing the questioning they
tend consistently towards "concerned and incisive".

Given your apparent discomfort with that question, perhaps you'd care
to consider how much more "hostile and uncomprehending" it might seem
if instead of making the question as part of a conversation between us,
I'd instead posted to d-d-a about it, or simply raised it as a general
conversation piece about how people in your position should be reviewed
for replacement as a matter of urgency.

Cheers,
aj



signature.asc
Description: Digital signature

Re: buildd administration

[Thomas Bushnell BSG]

Anthony Towns  writes:

>> So why was the request ignored for a month?  Why did my email result
>> in no action, twice, not even a response?
>
> I've told you what I'd need to answer that question already.
>
>> Perhaps you don't know the answer to these questions.  But then how
>> can you so surely assert that there is no problem?
>
> Easy: the best tools we've got to judge whether buildds are keeping up
> are the buildd graphs which indicate that with the exception of m68k
> and arm (hrm, and possibly hppa), all our ports are doing extremely well.

This is the only metric?  How about long delays on particular
packages?  The average amount built is not the only consideration.


Thomas


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

Re: Intel notebooks for needy developers in developing countries

[Christian Perrier]

> Yeah that would be a real pain to exlude countries because of stupid
> political 'correctness'. All in all in Free Software movement we don't know
> what the borders are, do we?


We (Debian developers and contributors) certainly all agree on this
(or, at least, the vast majority of us).

However, the donator here is a US company which may be restricted by
the laws of the United States of America. Whether we like them or not
is not really relevant. If Intel cannot donate a computer to a Cuban
citizen, there's not much we can do about it, except by asking the same
donation to a company that wouldn't be restricted to these exportation
laws (such as a Japanese company, maybe...which I'm not even sure of).

This certainly does not prevent Andreas to record the name of a Cuban
citizen in his list and propose it to Intel which is what I would
recommend doing if a Cuban citizen really qualifies for the donation.

But we should wait until we know there is *really* someone qualifying
for the donation in Cuba, before turning this into a rhetorical case,
no?

(removing CC to Andreas who certainly reads this list)




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

Re: buildd administration

[Thomas Bushnell BSG]

Anthony Towns  writes:

> On Fri, Dec 09, 2005 at 09:44:59PM -0800, Thomas Bushnell BSG wrote:
>> Anthony Towns  writes:
>> >> Upstream is working on #335981 and #336371.  In fact, scm has *never*
>> >> supported s390; 
>> >scm |5d9-4.1 |  unstable | s390
>> And yet, it didn't actually run successfully on s390.  Support is not
>> just a matter of compiling.
>
> Support's a matter of many things. One of those is ensuring you don't
> have RC bugs. 

What I said was that scm has never supported s390, but it is intended
to.  In my current judgment, it is not ready for testing until it does
support s390.  That judgment may change.  I was using the word
"support" to refer to a package supporting an arch.

Now you are referring to a very different usage of "support"; that is,
a developer supporting a package.  For a package which is not part of
debian stable or testing, it seems to me that support amounts to
actually working on getting it ready for testing and ultimately
stable.

> If a package is failing to build or to function on some architecture,
> your job as that package's maintainer is see if it can be fixed (talking
> to porters and/or upstream if it's beyond your skills), and if it can't
> be fixed trivially, to note that it's not currently supported on that
> architecture by both ensuring that non-working packages fail to build
> (by editing the Architecture: line or adding appropriate test suites), and
> passing that information on to others. 

This is in fact exactly what is happening.

> In this case that means not having
> a control file that explicitly declares s390 is a supported architecture,
> and filing a bug against ftp.debian.org indicating that the s390 build
> is broken and should be removed. That then warrants downgrading the s390
> FTBFS bugs to important or wishlist.

Yes, because actually *making it work* on the architecture is
unimportant.  Well, as the maintainer, I disagree.

> As far as transparency goes; I'll note you didn't add anything to either
> bug report indicating you're working with upstream. It's the silence
> and the uncertainty over whether anything's actually being done to fix
> anything that's the real issue, you know?

I'm sorry, were there people who were worried about this?  Were you
wishing that scm worked on your s390 box?  I am happy to answer
queries, but I have received none.

In addition, I would point out that your method of "supporting" the
package amounts to documenting its inadequacy and then doing nothing.
My method (described below) is much more focused on actually
furthering development and the usefulness of the package.

> RC bugs need to be fixed as a matter of *urgency*, not over a matter of
> months.

The package in question is not in testing, and was not released in
sarge.  The RC bug does not affect any users at all.  It holds the
package out of testing, which I think is currently appropriate.

Is there some *problem* here?  Or are you concerned about a
bookkeeping issue?  What is the particular urgency with which you are
concerned?  How would it help things if I did as you suggest, and then
opened a new RC bug indicating my judgment that the package is not yet
ready for stable?

What seems patently clear is that you chose to make this the place
upon which to take your stand and criticize me, without having done
the basic research to find out these facts.

Still, you having chosen to do this, my responsiblity as a developer
certainly includes that I should answer your emails as fully and
completely as I can.  Are you willing to commit to do the same, and
expect the same of the developers you are so busy defending?

> I don't believe I have any open RC bugs, or any open FTBFS bugs, so
> I don't see the relevance. But hey, if it'll make you feel better to
> convince yourself that it's everyone else's fault and there's nothing
> you can do, go ahead.

Where did I blame anyone?  I am addressing the bug in question.
(Actually, you have six open RC bugs, because you "maintain" packages
by ignoring them and relying on others to fix your bugs for you, and
then not acknowleding the NMUs.  I fail to see how this is better.)

Nor did I say there is nothing I can do.  Instead, what I did was:

1) Adopt the package, since I saw it was having trouble and the
   previous maintainer did not seem able to give it the attention it
   needed. 
2) Work with upstream to figure out what archs really worked and what
   didn't.
3) Start addressing the missing archs by helping to get upstream in
   contact with experts on those archs, and making sure he had access
   to suitable hardware.
4) Lend some expertise as time was available to help with the actual
   porting task.
5) Arrange to have the BTS correctly document the state of the
   package.
6) Answer even unfriendly questions from a fellow developer who
   doesn't even care about the particular issue.

>> Moreover, please notice how despite a hostile and uncomprehending
>> question, 
>
> It's amazing 

Re: buildd administration

[Anthony Towns]

On Fri, Dec 09, 2005 at 10:37:08PM -0800, Thomas Bushnell BSG wrote:
> Anthony Towns  writes:
> > Easy: the best tools we've got to judge whether buildds are keeping up
> > are the buildd graphs which indicate that with the exception of m68k
> > and arm (hrm, and possibly hppa), all our ports are doing extremely well.
> This is the only metric?  How about long delays on particular
> packages?  The average amount built is not the only consideration.

No, not the only, the best. It is mostly the responsibility of the
maintainer to resolve package specific issues though; which usually amount
to three things: FTBFS bugs, problems with toolchains and build-depends
that only affect one package or a few, and problems with P-a-s not
being accurate.

Toolchain issues usually, which seem to be your concern, take some time
to resolve, and are often fixed by "mass give-backs" once related issues
have worked their way through the build system. Sometimes the related
problems take a while to resolve, of course.

FTBFS issues are the most common though, as well as the easiest to
resolve; your point would carry more weight if you took the time to fix
yours first. (Looking through -private, I saw someone remark that 1000
bugs was too many -- we have got 1400 _RC_ bugs at the moment...)

(Also, those graphs do not indicate the "average" amount by any measure,
so your characterisation is again completely wrong. Please take more
care)

Cheers,
aj


signature.asc
Description: Digital signature

Re: buildd administration

[Anthony Towns]

On Fri, Dec 09, 2005 at 10:54:59PM -0800, Thomas Bushnell BSG wrote:
> In addition, I would point out that your method of "supporting" the
> package amounts to documenting its inadequacy and then doing nothing.

No, the issue is one of resolving RC issues: in this case by:

  (a) seeing if the FTBFS can be fixed immediately, and finding it can't
  (b) documenting (this is the transparent bit, so pay attention) that
  fact by not having s390 incorrectly listed as a supported arch in
  the source and ensuring it does not incorrectly indicate a known
  broken build is successful as it did in the past
  (c) informing ftpmaster that the build currently in the archive is
  broken by filing a bug requesting the broken build be removed
  (you know, communicating with people)
  (d) downgrading the bug so that it is not incorrectly listed as
  a RC issue that the RM and QA teams have to attend to
  (e) as maintainer, work with upstream and porters to fix the
  downgraded but still open bug we were just talking about

I'm sorry that you think important bugs equate to "doing nothing". But
either way, this is the way things are done, it's not something you get to
"disagree" with.

Since this point obviously needs to be made clearer, I guess it's time
to have some more rounds of removing packages that have long outstanding
RC bugs. I guess I'll coordinate with the RM team to do this sometime
over Christmas/New Year.

> (Actually, you have six open RC bugs, because you "maintain" packages
> by ignoring them and relying on others to fix your bugs for you, and
> then not acknowleding the NMUs.  I fail to see how this is better.)

There is nothing wrong with NMUs. Honestly, if you fail to see how a
bug fixed in an NMU is better than an open RC bug and a package in the
archive that doesn't work at all, I don't understand how you passed n-m.

> 6) Answer even unfriendly questions from a fellow developer who
>doesn't even care about the particular issue.

Ah, "unfriendly", "doesn't even care". There we go.

As it happens I do care about that bug, as it's an RC issue that stops
people from using the package and makes both quality assurance and the
release process harder.

> > Given your apparent discomfort with that question, perhaps you'd care
> > to consider how much more "hostile and uncomprehending" it might seem
> > if instead of making the question as part of a conversation between us,
> > I'd instead posted to d-d-a about it, or simply raised it as a general
> > conversation piece about how people in your position should be reviewed
> > for replacement as a matter of urgency.
> If someone believes that they would do a better job maintaining scm,
> I'm entirely happy to hand over maintenance of it.  Are you
> volunteering?

Somehow I didn't think you'd care to consider it.

Cheers,
aj



signature.asc
Description: Digital signature

Re: buildd administration

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> If a package is failing to build or to function on some architecture,
> your job as that package's maintainer is see if it can be fixed (talking
> to porters and/or upstream if it's beyond your skills)

BTW: is there a way to get build failures by mail? especially from the
architectures which are not visible on buildd.debian.org/PTS like hurd and
bsd. Took me two days to find a build failure, and I guess it would have
taken weeks before i would get a FTBFS bug report (asuming those are
manual).

Gruss
Bernd


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