Re: [GR] DD should be allowed to perform binary-only uploads

[Wouter Verhelst]

On Sat, Feb 10, 2007 at 03:27:25PM +0100, Frank Küster wrote:
> - it's not easy to see what's going on there, and why.  For example, I
>   don't know where I can read what dep-wait means and why and how a
>   package is put in this state.

http://www.debian.org/devel/buildd/wanna-build-states#dep-wait

> Of course it's difficult to change that.  Someone should write a nice
> page about it, and "someone" is, as usual, a synonym for "not me".

Correct. In this case, "someone" is a synonym for "me".

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Re: BREAKING NEWS: Debian developers aren't trusted

[Kalle Kivimaa]

Josselin Mouette <[EMAIL PROTECTED]> writes:
>> Personally, I don't like either of the checks, but I've seen zero
>> effort from Aurelian and friends to demonstrate they can be trusted,

Quoting partial sentences without disclosing the original source is
what usually only the yellow press does. I don't trust the "news" they
report.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


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

Debian Project Leader Elections 2007: Second call for nominations

[Debian Project Secretary]

Hi,

We are one week into the nomination period for candidates for
 the position of the Debian Project Leader.

According to the constitution (5.2. Appointment), project
 leader elections should begin "nine weeks before the leadership post
 becomes vacant, or (if it is too late already) immediately."

The new project leader term starts on April 17th, and that
 sets the time line:
 Nomination period:  Feb 4th  00:00:01 UTC -- Feb 25th 00:00:00 UTC
 Campaigning period: Feb 25th 00:00:01 UTC -- Mar 18th 00:00:00 UTC
   Voting period:Mar 18th 00:00:01 UTC -- Apr  8th 00:00:00 UTC

Prospective leaders should be familiar with the constitution,
 but, just to review: there's a three week period when interested
 developers nominate themselves, followed by a three week period with
 no nominations [intended for campaigning], followed by three weeks
 for the election itself.

I intend to collect platform statements from the candidates,
 and publish them on a known location (somewhere under
 www.debian.org/vote) at the end of the nomination period and the
 beginning of the campaign.

I suggest that the candidates send the platform, preferably in
 HTML/SGML, to the secretary at least a couple of days before the
 publication date.

This should give the candidates enough time to craft their
 platforms, I should think. The format of the web page is open to
 discussion, but I suggest there be at least three sections:
  a) Introduction/Biography
  b) Major Goal/ Meat of the platform,
  c) Rebuttal.

After the publication, there share be a one week period for
 each candidate to create a rebuttal, and the rebuttals shall be
 published on Mar 4th, 2007.

   In the past, we have conducted DPL debates on a special IRC
 channel set up for the purpose. Don Armstrong has volunteered to head
 this effort.  I would like to invite people to help him with this
 effort.  The debate should be held on IRC, and the time to do so
 would be after the rebuttals have been posted by the candidates, and
 the campaigns have been well established, and people have had time to
 think up questions, and before the voting starts, at the convenience
 of the candidates, and the panelists (which kinda puts it roughly in
 the nones or the ides of March, I think).

I would like to hand off the actual selection of other
 panelists (who may or may not be debian developers) and running the
 debate to the chair, Don Armstrong, (to minimize any hint of
 collusion with current office holders, including me).  I hereby
 invite volunteers for the debate chair and panelists; these
 volunteers shall be responsible for setting the rules for the debate
 and selecting the questions for the candidates.

Please make sure that nominations are sent to (or cc:'d to)
 debian-vote, and are cryptographically signed.

Thanks,

manoj

-- 
... the MYSTERIANS are in here with my CORDUROY SOAP DISH!!
Debian Project Secretary <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


pgpxlcJI24eUq.pgp
Description: PGP signature

Re: [GR] DD should be allowed to perform binary-only uploads

[Andreas Barth]

* Julien BLACHE ([EMAIL PROTECTED]) [070210 21:17]:
> Clint Adams <[EMAIL PROTECTED]> wrote:
> 
> > Debian infrastructure and portions thereof are not analogous to
> > packages.  As many have pointed out already, packages can be NMUed.
> 
> Note that if you can get SPI to transfer the debian.org zone to other
> DNS servers than the current ones, you can NMU the infrastructure.

I heavily disagree to that. The current servers are owned by Debian or
sponsored to Debian by some people. So Debian does have a say what
happens on them or not. (Please note that this doesn't contain any
approval or disapproval of any action on our servers, but just a
disapproval to this concept.)


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

sparc uploads

[Lionel Elie Mamane]

On Fri, Feb 09, 2007 at 08:23:54AM -0700, Wesley J. Landaker wrote:

> If I had a sparc machine, I'd probably upload my packages as
> src+sparc every once in a while just for fun and profit.

I'd be happy to give you access to a sparc machine just for that
purpose. Tell me what build dependencies you need, a signed request
(with the key in the Debian keyring), a ssh key.

-- 
Lionel


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

Re: [GR] DD should be allowed to perform binary-only uploads

[Hamish Moffatt]

On Sat, Feb 10, 2007 at 12:02:57AM +, Stephen Gran wrote:
> I am sure qemu is very good at what it does, but I do not have faith
> that it can stand in for a real CPU in all the corner cases.  If

Do you think it's likely that it can boot the kernel and run the build
environment without crashing, but produce broken binaries?


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Registration at BBS plethysmography

[Reinaldo]

Dear QfPn9

An account has been created for you at jeres's helpdesk.
Your details are:

username : 8s2m
password : yZw6k
site: www *dot* 120pills *dot* com
(Just type this link in your browser! Enjoy!)

When we talked yesterday, you said you'd seen a man in a sheep suit Without you 
I'll be flung out to the far corners of the universe “The soldier knows where 
Appsala is and can lead us there tFwaP


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

Re: [GR] DD should be allowed to perform binary-only uploads

[Julien BLACHE]

Clint Adams <[EMAIL PROTECTED]> wrote:

> Debian infrastructure and portions thereof are not analogous to
> packages.  As many have pointed out already, packages can be NMUed.

Note that if you can get SPI to transfer the debian.org zone to other
DNS servers than the current ones, you can NMU the infrastructure.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


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

Re: [GR] DD should be allowed to perform binary-only uploads

[Clint Adams]

> It is actually pretty relevant to your packages. I do not
>  expect you to add co-maintainers to zsh packages whom you do not
>  trust.  It is pretty irrelevant to areas you are not responsible
>  for. 

Debian infrastructure and portions thereof are not analogous to
packages.  As many have pointed out already, packages can be NMUed.


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

BREAKING NEWS: Debian developers aren't trusted

[Josselin Mouette]

e samedi 10 février 2007 à 13:05 +1000, Anthony Towns a écrit :
> Personally, I don't like either of the checks, but I've seen zero
> effort from Aurelian and friends to demonstrate they can be trusted,

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


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

New General resolution proposed

[Debian Project Secretary]

Hi,

This is a notification of a general resolution proposed on the
 debian-vote mailing list. On the 8th of February, in a message  with
  Message-ID: <[EMAIL PROTECTED]>
 Bill Allombert <[EMAIL PROTECTED]> proposed:
---

The Debian project resolves that Debian developers allowed to perform
combined source and binary packages uploads should be allowed to perform
binary-only packages uploads for the same set of architectures.

---
It has been seconded by:
 Mike Hommey <[EMAIL PROTECTED]>
 Sam Hocevar <[EMAIL PROTECTED]>
 Julien Danjou <[EMAIL PROTECTED]>
 Aurelien Jarno <[EMAIL PROTECTED]>
 Pierre Machard <[EMAIL PROTECTED]>

which makes for the required number of seconds. According to
 my count, the requisite second was received on Fri, 9 Feb 2007

manoj
-- 
"A reasonable doubt for a reasonable fee" Motto of Hunter S. Thompson's lawyer
Debian Project Secretary <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


pgpnZigzG3POI.pgp
Description: PGP signature

Re: [GR] DD should be allowed to perform binary-only uploads

[Debian Project Secretary]

On Thu, 8 Feb 2007 10:41:29 -0700, Wesley J Landaker
<[EMAIL PROTECTED]> said, in:  
 Message-Id: <[EMAIL PROTECTED]>

> Seconded.

I can not verify the signature on this message.

manoj

Bad signature from F0A98A4C4CD6E3D2 Wesley J. Landaker <[EMAIL PROTECTED]>
-- 
You get what you pay for. Gabriel Biel
Debian Project Secretary <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


pgpgn4bBIId3p.pgp
Description: PGP signature

Re: Debian Project Leader Elections 2007: Aigars Mahinovs (resent)

[martin f krafft]

also sprach  <> [2007.02.10.1522 +]:
> I hereby nominate myself for the position of Debian Project Leader in
> the DPL elections of 2007.

Are you trying to tell us something by leaving out the From header?

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
to err is human - to moo, bovine


signature.asc
Description: Digital signature (GPG/PGP)

Re: [GR] DD should be allowed to perform binary-only uploads

[Manoj Srivastava]

On Sat, 10 Feb 2007 11:00:28 -0500, Clint Adams <[EMAIL PROTECTED]> said: 

>> http://www.beyondintractability.org/essay/trust_building/> 
>> Might be a good start. I'm sure Google can find you other things.

That's a pretty decent essay. I found myself mostly in
 agreement. 

>> Implying that the people whom you'd like to trust you are
>> unreasonable probably isn't a good start.

> Great.  I don't trust you to do the right thing as DPL.  I don't
> trust you to do the right thing as ftpmaster.  I don't trust you to
> maintain your packages at an acceptable level.

> I assume you think all of this is irrelevant,

It is actually pretty relevant to your packages. I do not
 expect you to add co-maintainers to zsh packages whom you do not
 trust.  It is pretty irrelevant to areas you are not responsible
 for. 

> just as I think whom you/James/Ryan trust is irrelevant as well.

That is pretty irrelevant for, say, zsh, yes. But not
 irrelevant for areas they are responsible for.

manoj

-- 
One man tells a falsehood, a hundred repeat it as true.
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]

Debian Project Leader Elections 2007: Aigars Mahinovs (resent)

[bounce-debian-vote=archive=mail-archive . com]

I hereby nominate myself for the position of Debian Project Leader in
the DPL elections of 2007.

(Sending this again usind a proper email client as GMail messed up the 
text in the first email and a message to the blog is not enough.)

--
Best regards,
   Aigars Mahinovsmailto:[EMAIL PROTECTED]
 #--#
 | .''`. Debian GNU/Linux  LAKA |
 |: :' :  http://www.debian.org  &  http://www.laka.lv  |
 |`. `' |
 |  `-  |
 #--#


signature.asc
Description: Digital signature

Re: [GR] DD should be allowed to perform binary-only uploads

[Kurt Roeckx]

On Sat, Feb 10, 2007 at 03:27:25PM +0100, Frank Küster wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
> 
> > The error rate on requeue requests that reach me is significant, even from
> > people who are well-informed and involved in the process (e.g., fellow
> > release-team members).  Maybe they're less cautious because they know I vet
> > all requests, but I would expect that opening dep-waits/requeues up to the
> > general dev population would result in a *lot* of unnecessary rebuild tries,
> > stuck packages holding up transitions, etc., because the average developer
> > simply isn't clued in on this stuff.
> >
> > Heck, before m68k was dropped as a factor in package propagation into
> > testing, I was routinely finding bogus dep-waits set by the m68k buildd
> > maintainers themselves, and that's only about a half-dozen people.
> 
> I can name you the reasons why I don't have much of a clue about this (I
> think): 
> 
> - it wasn't part of the NM T&S process, IIRC; all the technical details
>   of testing propagation, freeze/unblock/, and general release team work
>   were a bit meager maybe.

In the NM process, you're not expected to learn about everything in
Debian.  It's about what you as a normal DD need to know.

If you want to do release team work, that's something you'll have to
learn, and it's actually not that hard to learn.  

> - it's not easy to see what's going on there, and why.  For example, I
>   don't know where I can read what dep-wait means and why and how a
>   package is put in this state.  I think I know what it means and why it
>   needs to be put there (manually), but that's just because it seems
>   logical.  And although I'm not the most involved developer, at least I
>   once setup a buildd and read about wanna-build (about two years ago,
>   forgot all...).

So you do know that there exist documentation about wanna-build.  It 

Anyway, it's all at:
http://www.debian.org/devel/buildd

And the states itself:
http://www.debian.org/devel/buildd/wanna-build-states

> - What's the contact point for asking for dep-wait or requeue?  I guess
>   it's that famous bunch of addresses that's also known for getting no
>   response, and when you want to learn something, an occasional "thanks,
>   it seems you've grasped the principle" or "Thanks, but you missed the
>   following" is very helpful.

I think in most cases you don't request dep-waits and let the buildd admin
deal with that itself.  It's probably easier to just wait until the
dependencies are available and then request it to be requeued.  But
[EMAIL PROTECTED] is the right place for any such requests.

> Of course it's difficult to change that.  Someone should write a nice
> page about it, and "someone" is, as usual, a synonym for "not me".

So, which parts do you think aren't documented properly?


Kurt


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

Re: [GR] DD should be allowed to perform binary-only uploads

[Adam D. Barratt]

On Sat, 2007-02-10 at 15:27 +0100, Frank Küster wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
[...]
> > Heck, before m68k was dropped as a factor in package propagation into
> > testing, I was routinely finding bogus dep-waits set by the m68k buildd
> > maintainers themselves, and that's only about a half-dozen people.
> 
> I can name you the reasons why I don't have much of a clue about this (I
> think): 
[...]
> - it's not easy to see what's going on there, and why.  For example, I
>   don't know where I can read what dep-wait means and why and how a
>   package is put in this state.
[...]
> Of course it's difficult to change that.  Someone should write a nice
> page about it, and "someone" is, as usual, a synonym for "not me".

Someone already did, at least for the buildd side -
http://www.debian.org/devel/buildd/ (with specific reference to
http://www.debian.org/devel/buildd/wanna-build-states).

It's linked from http://www.debian.org/devel/, under "Projects",
"Autobuilder network".

There's also, e.g., http://buildd.debian.org/~jeroen/status/ but I'm not
sure if that's directly linked from anywhere.

Adam

Re: [GR] DD should be allowed to perform binary-only uploads

[Clint Adams]

> http://www.beyondintractability.org/essay/trust_building/
> 
> Might be a good start. I'm sure Google can find you other things.
> 
> Implying that the people whom you'd like to trust you are unreasonable
> probably isn't a good start.

Great.  I don't trust you to do the right thing as DPL.  I don't trust
you to do the right thing as ftpmaster.  I don't trust you to maintain
your packages at an acceptable level.

I assume you think all of this is irrelevant, just as I think whom
you/James/Ryan trust is irrelevant as well.


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

Re: [GR] DD should be allowed to perform binary-only uploads

[Anthony Towns]

On Sat, Feb 10, 2007 at 10:34:34AM +0100, Julien Danjou wrote:
> At 1171076719 time_t, Anthony Towns wrote:
> > Personally, I don't like either of the checks, but I've seen zero
> > effort from Aurelian and friends to demonstrate they can be trusted,
> > and this GR just seems to be continuing the whole adversarial approach,
> > so as far as I'm concerned the last sentence in [0] still holds...
> Please explain me how people can make effort to be trusted,
> while trust is based on feelings and not on reason.

http://www.beyondintractability.org/essay/trust_building/

Might be a good start. I'm sure Google can find you other things.

Implying that the people whom you'd like to trust you are unreasonable
probably isn't a good start.

Cheers,
aj



signature.asc
Description: Digital signature

Re: [GR] DD should be allowed to perform binary-only uploads

[Frank Küster]

Andreas Barth <[EMAIL PROTECTED]> wrote:

> * Manoj Srivastava ([EMAIL PROTECTED]) [070210 04:44]:
>>  However, a buildd
>>  operator using qemu is not responsible for bugs filed on the packages
>>  created on his set up -- He is not performing an NMU.
>
> I disagree on this statement. If I e.g. upload an package to unstable
> linking to an experimental version of a library it is certainly my
> responsibility to fix it, independend whether I uploaded that package
> together with the source or not.

ACK.  Additionally, I got the feeling at times that the buildd admins do
not take enough of responsibility with the packages they build: If
something goes wrong, either because builds fail, or because packages
don't work on some architectures, or (a combination) builds fail because
always the same package on that arch doesn't behave well on their
buildd, I think the buildd admins should feel responsible.  And help
debugging at least when asked.  My experience with that is very bad.

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: [GR] DD should be allowed to perform binary-only uploads

[Frank Küster]

Steve Langasek <[EMAIL PROTECTED]> wrote:

> The error rate on requeue requests that reach me is significant, even from
> people who are well-informed and involved in the process (e.g., fellow
> release-team members).  Maybe they're less cautious because they know I vet
> all requests, but I would expect that opening dep-waits/requeues up to the
> general dev population would result in a *lot* of unnecessary rebuild tries,
> stuck packages holding up transitions, etc., because the average developer
> simply isn't clued in on this stuff.
>
> Heck, before m68k was dropped as a factor in package propagation into
> testing, I was routinely finding bogus dep-waits set by the m68k buildd
> maintainers themselves, and that's only about a half-dozen people.

I can name you the reasons why I don't have much of a clue about this (I
think): 

- it wasn't part of the NM T&S process, IIRC; all the technical details
  of testing propagation, freeze/unblock/, and general release team work
  were a bit meager maybe.

- it's not easy to see what's going on there, and why.  For example, I
  don't know where I can read what dep-wait means and why and how a
  package is put in this state.  I think I know what it means and why it
  needs to be put there (manually), but that's just because it seems
  logical.  And although I'm not the most involved developer, at least I
  once setup a buildd and read about wanna-build (about two years ago,
  forgot all...).

- What's the contact point for asking for dep-wait or requeue?  I guess
  it's that famous bunch of addresses that's also known for getting no
  response, and when you want to learn something, an occasional "thanks,
  it seems you've grasped the principle" or "Thanks, but you missed the
  following" is very helpful.

Of course it's difficult to change that.  Someone should write a nice
page about it, and "someone" is, as usual, a synonym for "not me".

> Aurélien got the first
> part of this back in December by keeping tabs on missing builds on arm and
> feeding this to James, but then he proceeded to set up a rogue autobuilder
> when he decided things weren't working to his satisfaction, so it's kinda
> hard to look at that and say yes, this is someone we should bring in to
> collaborate directly on w-b stuff for that arch.

I won't express an opinion here on what Aurélien did, but maybe he is
"someone"? 

> (No, I have no idea what this has to do with -vote.)

For my part, it's because a) I'm lazy, b) I'm currently not subscribed
to -project or -devel (so please Cc me if you move).

Regards, Frank

-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: [GR] DD should be allowed to perform binary-only uploads

[Julien Danjou]

At 1171076719 time_t, Anthony Towns wrote:
> Personally, I don't like either of the checks, but I've seen zero
> effort from Aurelian and friends to demonstrate they can be trusted,
> and this GR just seems to be continuing the whole adversarial approach,
> so as far as I'm concerned the last sentence in [0] still holds...

Please explain me how people can make effort to be trusted,
while trust is based on feelings and not on reason.

Cheers,
-- 
Julien Danjou
.''`.  Debian Developer
: :' : http://julien.danjou.info
`. `'  http://people.debian.org/~acid
  `-   9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD


signature.asc
Description: Digital signature

Re: [GR] DD should be allowed to perform binary-only uploads

[Sune Vuorela]

On 2007-02-10, Anthony Towns  wrote:
> Personally, I don't like either of the checks, but I've seen zero
> effort from Aurelian and friends to demonstrate they can be trusted,

if we have DDs that can't be trusted, don't we have major problem?

AJ: if you really mean they are untrusted, please start a expulsion
process.
Having the DPL and ftp-master saying specific people are not truster are
really not good.

> and this GR just seems to be continuing the whole adversarial approach,
> so as far as I'm concerned the last sentence in [0] still holds...

the last sentence in that mail hopefully don't stand if the developers
decide otherwise.


/Sune
 - not a DD so my opinions don't count [3]


[3]  http://lists.debian.org/debian-project/2006/08/msg00157.html


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