NEWS.Debian abuse

[Jesus Climent]

Please, try to avoid messages which are not directed to the end user under
NEWS.Debian:

  * Removed patch 057_pppoe-interface-change which was refused by the
upstream maintainer. Now users must arrange for the ethernet
interface used for PPPoE to be up.
  * The PPPoA plugin does not require anymore the libatm1 package to be
installed.

The information presented above is a candidate for changelog, not for News.

Thanks

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

- ... todos necesitamos creer en algo.
- Si, yo también creo... Creo... que me voy a tomar una cerveza.
--Sor Trini (Año Mariano)


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

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Steve Langasek]

On Mon, Mar 21, 2005 at 12:35:28AM +0100, Wouter Verhelst wrote:
> On Fri, Mar 18, 2005 at 11:43:48PM -0800, Steve Langasek wrote:
> > the "more" or "less" aspect of the urgency is relevant here.  We
> > obviously have a system for classifying the severity of bugs in
> > packages, and it's possible to relate these bug severities to the
> > urgency field in uploads; even assuming it does get abused by
> > maintainers,

> I don't think the possibility of something like that being abused is as
> strange as you seem to imply. As proof of that statement, I faintly
> remember someone doing a gratuitous source upload just to provoke the
> buildds...

On the contrary, I do expect there would be a certain amount of abuse of
such a system -- I just can't imagine such abuse reaching a level where it
constitutes a worse failure scenario than the one we currently have. 
*Particularly* if we apply appropriate social pressures against abusers.

> > how would considering urgency for package build ordering be worse than
> > what we have now given that it should only be an issue in either case
> > when the buildds are not working the way they should?

> It would be worse in that it would increase the impact of a re-upload.
> Not only would it trigger a rebuild on all architectures, it would now
> suddenly also throw the build ordering around, possibly worsening the
> problem that prompted the gratuitous upload in the first place by not
> building urgent (in build-dependency order) packages first.

But, uploads impact the ordering of Needs-Build all the time; I don't see
why that would generally be any worse than the status quo.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: NEW handling ...

[Anthony Towns]

Sven Luther wrote:
And what do you say of aj denying there is a NEW problem on the debian-vote
threads ? 
I don't know what Steve says, but I say: Cite.
I don't believe I said any such thing -- NEW processing has been a 
problem for some months now, which is why we were working on adding a 
couple of new people to process NEW.

That said, I believe you and others have been ridiculously hyperbolic in 
how large a problem it's been.

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

Re: my thoughts on the Vancouver Prospectus

[Christian Perrier]

Quoting Andreas Barth ([EMAIL PROTECTED]):
> * Thiemo Seufer ([EMAIL PROTECTED]) [050320 12:15]:
> > I don't regard my mips/mipsel porting work as just a hobby.
> 
> You're definitly doing a very professional job with mips*. In fact, I'm


Which indeed does not change my statement. All this (our Debian work)
is only one part of our lives. Often a big part for some of us,
sometimes the very biggest part for a few.but nearly always a part
of our lives.

So, Thiemo, this was certainly not a negative comment about your work
or any other work inside Debian.

My point was : well, when the climate gets too much on our nerves, we should
really consider a break off, even for a few hours, rather than
constantly trying to push out our point and making things degenerate.

Such behaviour *is* a professionnal behaviour. Constant flame and
systematic opposition is not. Trying to see your contradictor's point
from his/her own reference is the basis of any social behaviour and I
hate seeing my fellow Debian colleagues forget about this.

We are all (or nearly all) electronic communication oldtimers. We
should know that arguments by mail always end up this way (even in
professionnal environments, by the way).

This is not saying "people who flame or have an argument, go
away". Most of the people currently flaming out in lists and IRC are
good people, all needed by Debian. This is just saying "you all know
that constant flames do more damage to the project than the topics
which have created them, please remember this".

Yesterday, I've seen Peter answering Steve quite rudely. Today, I read
Steve calling Sven a twit. All of them being people I personnally give
high credit. This makes me believe that we crossed the line, that's
all.



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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Sven Luther]

On Sun, Mar 20, 2005 at 12:13:13PM -0500, David Nusinow wrote:
> On Sun, Mar 20, 2005 at 10:05:15AM +0100, Sven Luther wrote:
> > On Fri, Mar 18, 2005 at 12:06:15PM -0500, David Nusinow wrote:
> > > On Fri, Mar 18, 2005 at 05:43:26PM +0100, Adrian Bunk wrote:
> > > > [1] The installer might be a point, but since all sarge architectures
> > > > will have a working installer and I hope there's not another
> > > > installer rewrite planned for etch this shouldn't be a big issue.
> > > 
> > > This is still an issue. Joey Hess's mails have indicated very clearly 
> > > that it's
> > > difficult to get an installer release out even when all arches are already
> > > supported.
> > 
> > This is a non-issue. The main problem was the kernel situation, which will 
> > be
> > streamlined for etch into a single package, and maybe build issues, which
> > could be solved by a separate build queue or priority for d-i issues.
> 
> You know, you keep saying this and I have a really hard time
> believing it, although I don't follow the kernel list so please
> enlighten me if I'm wrong. 

Ok.

> If you have a single source package for 12 different architectures
> that's great, because when you have a security fix you can take
> care of that more easily. That's awesome.

Indeed. And better yet, you build the .udebs from the same package, so you
don't need to build the kernel and then build the .udebs.

> But then you'll be trading off for the same problems that every
> single other packge faces: namely that if a kernel on a single arch
> has an RC bug then it affects the kernels on every arch. This strikes
> me as being very problematic, and the only way I see around it is
> to downgrade actual RC bugs, which isn't really a solution at all.

Then we rebuild. This has some implications for slower arches, and this is
post-sarge issue anyway, so there is time for it, but the only solution for
this is to do partial rebuilds, and have a testing override for kernels on
slower arches.

Still, my claim is that delays like the ones joeyh complained about would
mostly dissapear. A bit of context about them :

  1) a security fix causes an abi change.

  2) a new kernel-source gets uploaded.

  3) all arches need to individually upload kernel-images.

  4) since there was an abi change, the package name gets modified, and thus 
 has to wait in NEW for NEW processing.

  5) .udeb packages have to be built (usually by the debian-boot team), and
 uploaded. (don't know if this implicates a second NEW processing).

  6) the .udebs and .debs have to move into testing simultaneously to avoid
 GPL violation, and general messy dependency and rebuild issues.

  7) the debian-installer daily images need to be built out of SVN using the
 above .udebs and tested.

  8) the debian-installer package is upgraded in sarge, and uploaded.

  9) each individual autobuilders need to process this package, which may or
 may not be fast dependending on the actual auto-builder situation.

Doing this for all arches, with unsynchronized (and maybe off for a couple of
days) per-arch kernel/debian-boot maintainer causes no end of trouble,
especially with the additional delay the NEW processing imposes, is what
causes upto two month upgrade times which joeyh speaks about.

having a common kernel package will greatly simplify the parts of this process
which involve the kernel-team, and let you just do the security fix, build and
upload (either auto-built or hand-built), and then pass the baby to the
debian-boot people to handle as usual.

Hope this clarifies things a bit.


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Sven Luther]

On Mon, Mar 21, 2005 at 04:31:57AM +0100, Thiemo Seufer wrote:
> David Nusinow wrote:
> [snip]
> > > > If you have a single source package for 12 different architectures
> > > > that's great, because when you have a security fix you can take
> > > > care of that more easily. That's awesome.
> > > 
> > > We have that already.
> > 
> > Great to hear. Then what is this new plan that the kernel team
> > has? I'm definitely confused.
> 
> For sarge, kernels are built in a two-stage process. First is to create
> a dsfg-free .deb from the upstream source which contains a source
> tarball, second is to build kernel images from another (arch-specific)
> .deb which build-depends on the source .deb. In the second stage,
> arch-specific patches can be added.

You forgot the third stage of the .udebs built.

> Post-sarge, it will be a one-stage process, which builds all kernel
> images from a single package.
> 
> > > > But then you'll be trading off for the same problems that every
> > > > single other packge faces: namely that if a kernel on a single arch
> > > > has an RC bug then it affects the kernels on every arch. This strikes
> > > > me as being very problematic, and the only way I see around it is
> > > > to downgrade actual RC bugs, which isn't really a solution at all.
> > > 
> > > Most kernel security bugs hit either generic code, or all architectures
> > > equally.
> > 
> > Yeah, but I'm talking about non-security RC bugs. From what
> > little Sven has described I feel like the new kernel plan will
> > make it so these platform-specific bugs are problematic for all
> > architectures. Does the new integration from upstream take care
> > of this and if not, how does the kernel team plan to deal with
> > this issue?
> 
> Those bugs are felt to be seldom enough, especially for already
> released kernels. For active development, there's a constant stream
> of fixes anyway, platform-specific things won't make much difference.

And a kernel-team with people from each architecture will make resolving of
them easier than a single maintainer in his corner who may or may not have the
knowledge for this actual fix, and may or not have time/whatever to fix it.

Friendly,

Sven Luther


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Anthony Towns]

Steve Langasek wrote:
One _might_ consider to have ports.d.o with the full package pool,
whereas ftp.d.o only consists the most wanted architectures. As a mirror
operator, you can than choose to either just have the most wanted
architectures, all or both.
Why not go the full way? What I've outlined in [1] is too obvious to
never have been thought before, but what is the reason not to do it
that way?
I have no idea one way or another; neither Andi nor I are involved in the
mirror implementation details.
There's no particular reason not to do it that way; and indeed it might 
well end up being done that way. Or it might end up being done a 
slightly different way again. I don't think any of those details are 
crucial or complicated enough to need to be nutted out months in advance.

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

Re: A new arch support proposal, hopefully consensual (?)

[Tapio Lehtonen]

On Sun, Mar 20, 2005 at 12:45:33PM +0100, Sven Luther wrote:
> discussion forward in such a way that we can get a resonable discussion at the
> helsinski debconf'05 meeting.
> 

That's Helsinki, you ignoramus, you. 
http://www.helsinki.fi/eng/index.html

-- 
Tapio Lehtonen
[EMAIL PROTECTED]
GPG public key from http://www.iki.fi/Tapio.Lehtonen


signature.asc
Description: Digital signature

Re: NEWS.Debian abuse

[Henrique de Moraes Holschuh]

On Mon, 21 Mar 2005, Jesus Climent wrote:

> upstream maintainer. Now users must arrange for the ethernet
> interface used for PPPoE to be up.

The rest of the technical details should not really be in NEWS.Debian, BUT
"Now users must arrange for the ethernet interface used for PPPoE to be up"
is *definately* NEWS.Debian material.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: A new arch support proposal, hopefully consensual (?)

[foo_bar_baz_boo-deb]

It's not so fair to perpetrate a straw man attack against Sven's whole
proposal just because he can't spell perfectly. Give the man credit
where it's due for trying to better Debian.

BTW, Sven and the Vancouver crew, I appreciate your collective thinking
about what's right for Debian and the minor arches, being a SPARC user
with a production Debian system.

--- Tapio Lehtonen <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 20, 2005 at 12:45:33PM +0100, Sven Luther wrote:
> > discussion forward in such a way that we can get a resonable
> discussion at the
> > helsinski debconf'05 meeting.
> > 
> 
> That's Helsinki, you ignoramus, you.


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

ubuntu!

[Kevin Mark]

Hi tired and weary folks,
after such long and heated dicussions, I, ironically, think Debian needs
UBUNTU (at least the african concept of humanity towards others and
reconciliation)!
Lets work towards a solution together and help all of our users and all
of our porters and all of our maintainers, etc. find common ground and
have a round of virtual beer!
Cheers,
Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!
_,   _,  ,'`.
  `$$' `$$' `.  ,'
   $$   $$`'
   $$   $$ _,   _
 ,d$$$g$$  ,d$$$b.  $$,d$$$b.`$$' g$b.`$$,d$$b.
,$P'  `$$ ,$P' `Y$. $$$'  `$$ $$  "'   `$$ $$$' `$$
$$'$$ $$'   `$$ $$'$$ $$  ,g$$ $$'   $$
$$ $$ $$g$$ $$ $$ $$ ,$P"   $$ $$$$
$$,$$ $$.   $$,$P $$ $$'   ,$$ $$$$
`$g. ,$$$ `$$._ _., $$ _,g$P' $$ `$b. ,$$$ $$$$
 `Y$$P'$$. `YP',P"'  ,$$. `Y$$P'$$.$$.  ,$$.


signature.asc
Description: Digital signature

Re: NEWS.Debian abuse

[Marco d'Itri]

On Mar 21, Jesus Climent <[EMAIL PROTECTED]> wrote:

> Please, try to avoid messages which are not directed to the end user under
> NEWS.Debian:
They *are* directed to end users and document two changes which may need
their attention and require configuration changes.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: How to pin certain packages from experimental?

[Marc Haber]

On Mon, 21 Mar 2005 08:47:22 +0100, Adeodato Simó <[EMAIL PROTECTED]>
wrote:
>* Marc Haber [Mon, 21 Mar 2005 08:03:21 +0100]:
>> |  Version Table:
>> | 4.50-4 555
>> |500 http://debian.debian.zugschlus.de sid/main Packages
>> | *** 4.50-1 555
>> |100 /var/lib/dpkg/status
>> | 4.44-2 555
>> |500 http://debian.debian.zugschlus.de sarge/main Packages
>> |[2/[EMAIL PROTECTED]:~$   
>
>> available versions (4.44-2, 4.50-1 and 4.50-4) are pinned to priority
>> 555.
>
>> And I see that the pin is somewhat wrong, as the 555 pin should only
>> apply to packages available from the experimental distribution and not
>> to sarge and sid.
>
>  The priority of each version/location is the number at the left of it,
>  in this case, 500, 100, 500. Those numbers are correct.

So you're basically saying that my pin doesn't work at all?

How got 4.50-1 installed then in the first place?

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: NEWS.Debian abuse

[Jesus Climent]

On Mon, Mar 21, 2005 at 12:27:49PM +0100, Marco d'Itri wrote:
> On Mar 21, Jesus Climent <[EMAIL PROTECTED]> wrote:
> 
> > Please, try to avoid messages which are not directed to the end user under
> > NEWS.Debian:
> They *are* directed to end users and document two changes which may need
> their attention and require configuration changes.

So then rephrase them so that end users can understand what effect those
changes have in their configuration.

I dont see how

  Removed patch 057_pppoe-interface-change which was refused by the upstream
  maintainer.

has much to do with end users, whether

  NOTICE!
  Now users must arrange for the ethernet interface used for PPPoE to be up.
  To do so, please, follow the following instructions: blah blah blah

has, but I failed to see a proper description on how to solve a possible
problem in the end user's configuration.

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

Emily, I have a confession to make. I really am a horse doctor. But marry me,
and I'll never look at another horse.
--Dr. Hackenbush (A Day at the Races)


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

Re: Logs from the DPL debate posted, and a draft ballot

[Helen Faulkner]

Hi Everyone,
There is an error in the currently posted transcript for part 1 of the 
debate [1].  The following section, in "Managing DPL Duties and Life":

 AngusLees:
I consider travelling as an extremely important factor of being 
DPL. Before nominating, I carefully considered the time I will have 
available and I am confident that I can do what is required and it will 
not impact on my existing (minimal) Debian duties. I think that I 
established very well that i prepared and planned ahead for this not to 
happen: i can work on Debian and DPL issues during work hours and have 
the DPL-team to fall back on. Even with flames and critizim, which can 
hurt individuals and demotivate them severely, the team can help by 
offering moral support.

Should read:
 AngusLees:
I consider travelling as an extremely important factor of being 
DPL. Before nominating, I carefully considered the time I will have 
available and I am confident that I can do what is required and it will 
not impact on my existing (minimal) Debian duties.

AndreasSchuldei:
I think that I established very well that i prepared and planned 
ahead for this not to happen: i can work on Debian and DPL issues during 
work hours and have the DPL-team to fall back on. Even with flames and 
critizim, which can hurt individuals and demotivate them severely, the 
team can help by offering moral support.


The error was mine, and I am sorry for any confusion this may have 
caused.  The corrected transcript will be uploaded to [1] as soon as 
possible.

Helen
1.  http://www.debian.org/vote/2005/Log-debian-dpl-debate
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Ubuntu Patches

[Thomas Hood]

> http://people.ubuntu.com/~scott/patches/

Thanks, that is very useful.

I see that Ubuntu has done a lot of work to make initscripts send output
through lsb printing functions.  Are there any plans for Debian to adopt
these changes?

-- 
Thomas Hood


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

Re: my thoughts on the Vancouver Prospectus

[Steve Langasek]

On Sat, Mar 19, 2005 at 04:10:51AM +, Matthew Garrett wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:

> > - While neither of the above concerns is overriding on its own (the
> >   ftpmasters have obviously allowed these ports to persist on
> >   ftp-master.debian.org, and they will be released with sarge), there is a
> >   general feeling that twelve architectures is too many to try to keep in
> >   sync for a release without resulting in severe schedule slippage.
> >   Pre-sarge, I don't think it's possible to quantify "slippage that's
> >   preventible by having more active porter teams" vs. "slippage that's
> >   due to unavoidable overhead"; but if we do need to reduce our count of
> >   release archs, and I believe we do, then all other things being equal, we
> >   should take issues like the above into consideration.

> This, uh, sounds very much like "We need to drop architectures, and so
> we have come up with these criteria that will result in us dropping
> architectures". Which is a reasonable standpoint to take, but which also
> seems to imply that if 12 architectures manage to fulfil all the
> criteria, we'll need to come up with some new criteria to ensure that
> the number drops below 12 again. 

> If this is the case, I think that needs to be made clearer to avoid
> situations where people work to meet the criteria but are vetoed by the
> release team because there are already too many architectures. I'm not
> massively keen on this - it ends up sounding a bit too much like dead
> man's shoes.

If we do find ourselves in a situation where the number of architectures
meeting the stated requirements for etch is high enough that it causes
problems per se for the release process, I'm willing to commit to sticking
it out without thinking up new criteria for the purpose of cutting down the
architecture count.  OTOH, if we find that a particular port isn't in a
releasable state for reasons we didn't think of, I believe the release team
still needs a free hand to veto that port's inclusion in the release.

I think we'll be in trouble again in terms of release cycle predictability
if we end up with 12 architectures for etch, but hopefully not *much*
trouble.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Ubuntu Patches

[Marco d'Itri]

On Mar 21, Thomas Hood <[EMAIL PROTECTED]> wrote:

> I see that Ubuntu has done a lot of work to make initscripts send output
> through lsb printing functions.  Are there any plans for Debian to adopt
> these changes?
The first step would be for somebody to make a debian lsb-base package,
possibly with a default "theme" which matches the current style of boot
time messages.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: NEW handling ...

[Matthias Urlichs]

Hi, Kyle McMartin wrote:

> If you had actually _looked_ before you opened your dumb mouth,

There's at least one word in this sentence which is uncalled-for.

Please don't further escalate this already-heated debate by insulting
people.

Thank you.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]



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

Re: Ubuntu Patches

[Colin Watson]

On Mon, Mar 21, 2005 at 01:03:17PM +0100, Marco d'Itri wrote:
> On Mar 21, Thomas Hood <[EMAIL PROTECTED]> wrote:
> > I see that Ubuntu has done a lot of work to make initscripts send output
> > through lsb printing functions.  Are there any plans for Debian to adopt
> > these changes?
> 
> The first step would be for somebody to make a debian lsb-base package,
> possibly with a default "theme" which matches the current style of boot
> time messages.

Certainly one problem with the current Ubuntu approach is that it isn't
properly "themeable", i.e. the display style is in code in /lib so you
can't customise it locally without having it trashed on upgrade, and so
on. Fixing that would be good.

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: NEW handling ...

[David Schmitt]

On Monday 21 March 2005 02:19, Kyle McMartin wrote:
> On Sun, Mar 20, 2005 at 08:20:40PM +0100, David Schmitt wrote:
> > kernel-latest-2.6-hppa 2.6.8-1
> >  source hppa unstable
> >  1 month Kyle McMartin
> >
> > debian-kernel managed kernel-image tracker packages seem to be called
> > kernel-image-$ver-$subarch (e.g. kernel-image-2.6-686). Debian should
> > strive to unify this as much as possible. REJECT. No wait, REJECTing this
> > out of hand would lead to a pissed maintainer filling FMs mailbox. FMs
> > are not debian-mentor, just let it rot, perhaps someone can clue him
> > in...
>
> Excuse me?

Sorry Kyle, I owe you an apology and $DRINK on my tab.

You were right, I was very confused by looking for binary packages when 
new.html listed sources packages.



Regards, David
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: Emulated buildds (for SCC architectures)?

[Stephen Frost]

* Anthony Towns (aj@azure.humbug.org.au) wrote:
> >Apparently the feeling wrt distcc is somewhat different and is likely to
> >be a more generally accepted solution to the slow-at-compiling issue.
> 
> I like distcc -- heck I went to high school with the author -- and I 
> think it's cool. I don't know that it'd be enough to get ports like m68k 
>  working quickly enough to meet the 1 or 2 buildds requirement, and it 
> doesn't solve the other issues that arise at all. But hey, I wouldn't 
> have a problem with an m68k+distcc/i386 pairing as a buildd, if all the 
> other requirements were also being dealt with properly. That's also more 
> a DSA/buildd issue though, neither of which are hats of mine.

Alright, perhaps I misunderstood the responsibilities a bit.  buildds
are run by DSA (Which I'm guessing is the 'System Administration' group
on w.d.o/intro/organization)?  Is access to wanna-build also managed by
that group?  That's mainly what I was driving at really- will an
emulated/distcc buildd be allowed to access wanna-build & co. and be
acceptable to meet the release criteria?  I thought the general feeling
was 'emulated - no, distcc - perhaps' but now I've got no idea since it
seems the appropriate people havn't commented.

Speaking of which, if DSA are the appropriate people, who in that group
are active in that role, esp. wrt the buildds?  That group has 5 people
but I only know of two (James Troup & Ryan Murray) who have been active
wrt buildds.  I'm still a bit confused though since I really thought the
buildds fell more under the perview of ftpmasters for whatever reason...

Stephen


signature.asc
Description: Digital signature

Re: mess in BTS

[Kevin B. McCarty]

Hi Andrea,

Andrea Mennucc wrote:

> my source package has this web page in BTS 
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libppd where you see
> there are 4 bugs listed (resolved)
> 
> 
> but then there is this web page 
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libppd

[snip]

> -) where it says  ``refer to the libppd package page'' there is an
> useless linkhttp://packages.debian.org/libppd

This is indeed true and someone ought to remove the useless link, or
maybe instead point it to http://packages.qa.debian.org/libppd .

[snip]

> what is the meaning of this latter web page?

I guess it gives porters a place to file bugs like FTBFS that aren't
specific to a binary package, only to the source package.  (This is IMO
since I've never seen a discussion on this before.)

> how come some bugs (such as the FTBFS bug) are appended to this page?
>  and some other bugs are not?

Because the bugs went to the package page against which they were filed?
Apparently if you have a source package "foo" producing binary packages
"bar" and "baz", the BTS recognizes "Package: foo" as well as the latter
two.

> (this is the gravest fact of all: people checking 
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libppd would fail to
> see bugs on their source packages)

That's why you should instead check
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libppd  :-)

> (*) ps: currently 
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=snmpkit and 
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=snmpkit show
> identical lists; I had not time to investigate how many other
> packages suffer from the same situation; if someone reads this e-mail
> and knows of a source package that has no binary package by the same
> name, please check it

Probably this "situation" is the case for all source packages that do
not produce a binary package of the same name, but for which porters
have filed bugs against the source package.  It was true for my
multi-binary source package cernlib (before I introduced a "cernlib"
binary meta-package).

regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG public key ID: 4F83C751 Princeton, NJ 08544


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

Re: The 98% and N<=2 criteria

[Wouter Verhelst]

On Sun, Mar 20, 2005 at 03:16:08PM +0100, Andreas Barth wrote:
> * Henning Makholm ([EMAIL PROTECTED]) [050319 22:05]:
> > Scripsit David Weinehall <[EMAIL PROTECTED]>
> 
> > > That said, I'm a firm believer of the suggestion posed by Jesus
> > > Climent[1], that we should have base set of software (where base is
> > > probably a bit bigger than our current base) released for all
> > > architectures that have a working installer, and then only have full
> > > official releases for a limited set of architectures.
>  
> > Such a base set of software would surely include a compiler toolchain,
> > wouldn't it? If sounds plausible that the toolchain is the collection
> > of software where architecture-specific bugs are _most_ likely to turn
> > up, so would we actually have gained anything then?
> 
> Well, the toolchain is perhaps not the part where they turn up most
> likely, but it's the part that creates most of the workload and delays.

Uh. Most porting bugs that require attention fall in one of the
following areas:
* Toolchain problems (Internal Compiler Errors, mostly)
* Mistakes made by the packager. Quite easy to fix, usually.
* Incorrect assumptions in the source code. These are becoming
  increasingly rare these days, IME.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: The 98% and N<=2 criteria

[Andreas Barth]

* Wouter Verhelst ([EMAIL PROTECTED]) [050321 15:05]:
> On Sun, Mar 20, 2005 at 03:16:08PM +0100, Andreas Barth wrote:
> > Well, the toolchain is perhaps not the part where they turn up most
> > likely, but it's the part that creates most of the workload and delays.

> Uh. Most porting bugs that require attention fall in one of the
> following areas:
> * Toolchain problems (Internal Compiler Errors, mostly)
> * Mistakes made by the packager. Quite easy to fix, usually.
> * Incorrect assumptions in the source code. These are becoming
>   increasingly rare these days, IME.

Exactly. And if you s/workload/workload for the release team/, than the
first one is the usual spot for issues for us. The middle one is fixed
mostly by the maintainer (or just in the next BSP), and the last one is
really rare today in new software (and especially doesn't hit a large
part of the archive out of nothing at all).


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Jeroen van Wolffelaar]

[ Please followup to the right list depending on the contents of your
reply. Be aware I'm not subscribed to -kernel, so Cc me if needed ]

On Mon, Mar 21, 2005 at 08:14:37AM +0100, Sven Luther wrote:
> [huge rant about NEW and hurting kernel stuff etc etc]

Three remarks:

> Rejecting those would lead in a pissed kernel maintainer team i would say.

Please be aware that NEW processing is human work. There's quite a big
backlog (currently still over 300 while I feel a lot got done already),
and I at least try to err on the side of caution. This means, and yes,
it already happenen, that it will occasionally happen we will reject an
upload by mistake. If this happens to you, just reply to the mail (as
its footer says, if you don't understand the reject, reply) and it will
looked into. Of course, if we decide it was a mistake and your package
should be accepted, we'll process it out-of-order (The mistake I
rectified yesterday was in NEW for 70 seconds, surely a record). Taking
it as offence and acting accordingly could have negative effects on
swift reprocessing.

> I think i would have warranted at least a reply on this case, don't
> you think ? 

Maybe, if one would reply to all mails you send out, one wouldn't have
time for ANY other Debian work. For example, you contributed 75 mails[1]
within 24 hours to the Vancouver thread, consisting (excluding quoted
text) of about 7522 words in 43kB of hand-written text[2]. I'm sorry,
but you think it's weird people can't resist accidentally hitting the 'd'
key when seeing an incoming mail from you?


 
Anyway, regarding kernels: I can imagine sometimes, especially with the
backlog we have currently, a swift processing of some kernel package
might be warranted and help Sarge. If there is such a case, it would
help if someone other than yourself from the kernel team contact the
right email address[3] about it, I had a hard time distilling from your
mails if and which packages would genuinly benefit sarge if they were
processed swiftly, of course together with a short and factual
explanation. You can also try to make a release-team-person ask, but
they are also busy people, so why bother them?

Thanks,
--Jeroen

[1] http://lists.debian.org/~jeroen/sven-vancouver-24h.mbox
[2] wget -qO- http://lists.debian.org/~jeroen/sven-vancouver-24h.body \
grep -v '^>' | wc
[3] http://www.debian.org/intro/organization

-- 
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: Bits (Nybbles?) from the Vancouver release team meeting

[Thiemo Seufer]

Sven Luther wrote:
[snip]
> > For sarge, kernels are built in a two-stage process. First is to create
> > a dsfg-free .deb from the upstream source which contains a source
> > tarball, second is to build kernel images from another (arch-specific)
> > .deb which build-depends on the source .deb. In the second stage,
> > arch-specific patches can be added.
> 
> You forgot the third stage of the .udebs built.

They can be "built" immediately after the kernel images were accepted,
there's little potential for a delay.


Thiemo


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

Re: Required firewall support

[Wouter Verhelst]

On Thu, Mar 17, 2005 at 01:09:33PM +0100, Marc Haber wrote:
> On Wed, 16 Mar 2005 20:39:48 -0700, Joel Aelwyn <[EMAIL PROTECTED]>
> wrote:
> >* The first rule of securing a machine exposed to the wilds is "Deny by
> >  default, allow by need".
> 
> Which is pretty well accomplished by only running needed services.

Note that some packages, directly or indirectly, build-depend on
packages containing daemons that will be started by default if
installed. In that light, a firewall really is required to keep things
safe.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Sven Luther]

On Mon, Mar 21, 2005 at 03:11:06PM +0100, Jeroen van Wolffelaar wrote:
> [ Please followup to the right list depending on the contents of your
> reply. Be aware I'm not subscribed to -kernel, so Cc me if needed ]
> 
> On Mon, Mar 21, 2005 at 08:14:37AM +0100, Sven Luther wrote:
> > [huge rant about NEW and hurting kernel stuff etc etc]
> 
> Three remarks:
> 
> > Rejecting those would lead in a pissed kernel maintainer team i would say.
> 
> Please be aware that NEW processing is human work. There's quite a big

which is my main grip with the subpart of it which could be automated. For
example, kernel-source-2.6.11 was just uploaded today, which means a plethora
of uploads all needing NEW processing. Can you give me any reason why this
really needs NEW processing, and why you don't thrust the kernel-team on this ?

> backlog (currently still over 300 while I feel a lot got done already),
> and I at least try to err on the side of caution. This means, and yes,
> it already happenen, that it will occasionally happen we will reject an

the problem is not the reject, is the no news in weeks and no communication
channel open. But again, i think and hope that this will become better now.

> upload by mistake. If this happens to you, just reply to the mail (as
> its footer says, if you don't understand the reject, reply) and it will
> looked into. Of course, if we decide it was a mistake and your package
> should be accepted, we'll process it out-of-order (The mistake I
> rectified yesterday was in NEW for 70 seconds, surely a record). Taking
> it as offence and acting accordingly could have negative effects on
> swift reprocessing.

There was no real swift processing in the past. Also, i believe that if
packages are being considered and have some problems, it would be best to
include the maintainer having made the upload into this process as early as
possible.

> > I think i would have warranted at least a reply on this case, don't
> > you think ? 
> 
> Maybe, if one would reply to all mails you send out, one wouldn't have
> time for ANY other Debian work. For example, you contributed 75 mails[1]
> within 24 hours to the Vancouver thread, consisting (excluding quoted
> text) of about 7522 words in 43kB of hand-written text[2]. I'm sorry,
> but you think it's weird people can't resist accidentally hitting the 'd'
> key when seeing an incoming mail from you?

Well, sending email to a discussion forum like debian-devel, and sending email
to a debian-role like ftp-master is not comparable, and i think it shows a
profund lack of responsability on your part even suggesting this. How would
you feel about a developer ignoring bug report from a certain person just
because he has posted a big amount of emails to debian-devel ? And a
falling-in-his-duties DD has at least the QA team and the MIA check to watch
over him, while the ftp-masters can have any uncontrolled whim and we have no
choice but to abide by them.

Furthermore i see a serious failing in your logic, in the fact that the emails
you quote are posterior to the failure of reply from the ftp-master's office,
and can thus not be used to excuse it.

> Anyway, regarding kernels: I can imagine sometimes, especially with the
> backlog we have currently, a swift processing of some kernel package
> might be warranted and help Sarge. If there is such a case, it would
> help if someone other than yourself from the kernel team contact the
> right email address[3] about it, I had a hard time distilling from your

Why not me ? I would very much like a reason for that, am i in some way
blacklisted ? and if so for what reason ? And is this reason an acceptable
one, i seriously doubt so. I am part of the kernel team, and i did work on my
other packages which are more or less in good state, as well as actively
participated in the debian-installer work. Why should you not threat a
question on my part as from any other developer ? And if you do not, would it
not be understandable that i feel irritated by this inacceptable behavior that
has a blocking effect on my own participation to debian.

> mails if and which packages would genuinly benefit sarge if they were
> processed swiftly, of course together with a short and factual
> explanation. You can also try to make a release-team-person ask, but
> they are also busy people, so why bother them?

Whatever. I believe that your response to email send to ftp-master's role in
debian should not be influenced by any personal negative opinion you may have
on me, even if it may be warranted. We all work together to make the debian
release as great and swift as possible, and this kind of blacklisting of some
of our developers is inacceptable, and a severe failure in the ftp-master's
role responsability against the project.

Friendly,

Sven Luther


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

Re: Required firewall support

[Sebastian Ley]

* Wouter Verhelst wrote:

> Note that some packages, directly or indirectly, build-depend on
> packages containing daemons that will be started by default if
> installed. In that light, a firewall really is required to keep things
> safe.

IMO most notably, because many users will hit that:
KDE -> famd -> portmapper

While I would not judge on portmappers security, it is certainly not a service 
which most users need to have exposed to the internet, and so it shouldn't be 
by default.

Of course, the proper solution would be to a) do not make fam depend on 
portmapper or b) alter portmapper to listen for local connections only, 
neither of both has been implemented for some time now...

Sebastian

-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6


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

Re: Ubuntu Patches

[Norbert Tretkowski]

* Scott James Remnant wrote:
> Ubuntu developers have been asking for patches to be updated when a
> new Ubuntu upload is made, not just when a new Debian upload is
> made.
> 
> Hand me that rock, I've a couple of birds to kill ...
> 
> http://people.ubuntu.com/~scott/patches/
> 
> At this URL, you will find the current Debian->Ubuntu patch for all
> packages in Ubuntu main and universe; updated daily.

That helps a lot, thanks Scott! What about offering a way to subscribe
to packages, so you'll get informed by mail if a package in Ubuntu is
changed, maybe with an interdiff applied to that mail?

Norbert


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Matthias Urlichs]

Hi, Thomas Bushnell BSG wrote:

> Matthias Urlichs <[EMAIL PROTECTED]> writes:
> 
>> We can't. AFAIK: One or two rsync commands, and *that's*it*.
>> 
>> Any required fanciness need to be done on the master server.
> 
> But that's your choice.
> [ Rather silly dialogue deleted ]

The choice is to either restrict the required client-side fanciness to
what most of our mirrors are willing to accept, or go without mirrors 
(OK, OK ... fewer mirrors anyway), which is something I don't think we'd
want.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]



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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Wouter Verhelst]

On Fri, Mar 18, 2005 at 12:06:08PM +1000, Anthony Towns wrote:
> So, I'd just like to re-emphasise this, because I still haven't seen 
> anything that counts as useful. I'm thinking something like "We use s390 
> to host 6231 scientific users on Debian in a manner compatible to the 
> workstations they use; the software we use is ; we rely on having 
> security support from Debian because we need to be on the interweb 2; 
> ...". At the moment, the only use cases I'm confident exist are:
> 
>   m68k, mips, mipsel, hppa: I've got one in the basement, and I like 
>   to brag that I run Debian on it; also I occassionally get some work out 
> of 
> it, but it'd be trivial to replace with i386.

Aren't the first three of these also actively being used in embedded
applications? (not sure about that one; I'm not /that/ much involved
with embedded stuff)

I can also imagine some hppa boxes being used as test or development
platform in the enterprise. Note that they were still being sold as new
only a few years ago.

>   sparc, alpha: We've bought some of these a while ago, they're useful 
> running Debian, we'd really rather not have to stress with switching to 
> i386, but whatever.
> 
>   arm: We're developing some embedded boxes, that won't run Debian 
> proper, but it's really convenient to have Debian there to bootstrap 
> them trivially.

Also note that having a supported port to a processor which is mainly
being used in embedded situations is useful even to people who don't
necessarily use Debian themselves, in that it ensures a level of quality
in the kernel, the toolchain, and Free Software running on that
platform.

This is what I would call 'indirect use': people not directly using
Debian, but still benefitting from Debian's efforts on supporting that
architecture. Dropping such architectures would likely result in
GNU/Linux losing popularity in the embedded area -- one of the areas
where GNU/Linux has a great momentum currently.

>   s390: Hey, it's got spare cycles, why not?

I honestly think it's more than that. s390 systems are way too expensive
for the average hobbyist; only large corporations can afford its price
and power consumption. I would be genuinely surprised if there weren't
one of those enterprises running their website off a Debian VM running
apache, or so.

> None of those are enough to justify effort maintaining a separate 
> testing-esque suite for them; but surely someone has some better 
> examples they can post...

Testing is never interesting for people in many of the above scenarios,
but that doesn't mean we have to drop it.

Debian stable usually /is/ interesting for people in the above
scenarios; but the only way Debian stable can currently reach the
quality it is known for, is by using testing.

Unless you have a different view. And no, unstable snapshots isn't a
workable alternative, IMO.

> The questions that need to be answered by the use case are "what useful 
> things are being done with the arch" and "why not just replace this with 
> i386/amd64 hardware when support for sarge is dropped, which won't be 
> for at least 12-18 months (minimum planned etch release cycle) plus 12 
> months (expected support for sarge as oldstable)". Knowing why you're 
> using Debian and not another distribution or OS would be interesting too.

 lists many of them.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: How to pin certain packages from experimental?

[Paul Hampson]

On Mon, Mar 21, 2005 at 12:36:52PM +0100, Marc Haber wrote:
> On Mon, 21 Mar 2005 08:47:22 +0100, Adeodato Simó <[EMAIL PROTECTED]>
> wrote:
> >* Marc Haber [Mon, 21 Mar 2005 08:03:21 +0100]:
> >> |  Version Table:
> >> | 4.50-4 555
> >> |500 http://debian.debian.zugschlus.de sid/main Packages
> >> | *** 4.50-1 555
> >> |100 /var/lib/dpkg/status
> >> | 4.44-2 555
> >> |500 http://debian.debian.zugschlus.de sarge/main Packages
> >> |[2/[EMAIL PROTECTED]:~$   
> >
> >> available versions (4.44-2, 4.50-1 and 4.50-4) are pinned to priority
> >> 555.

> >> And I see that the pin is somewhat wrong, as the 555 pin should only
> >> apply to packages available from the experimental distribution and not
> >> to sarge and sid.

> >  The priority of each version/location is the number at the left of it,
> >  in this case, 500, 100, 500. Those numbers are correct.

> So you're basically saying that my pin doesn't work at all?

Well, the above output doesn't show a version in experimental...

"How APT Interprets Priorities" in apt-preferences(5) seems to suggest
that a '500' priority won't be upgraded automatically, that's the
priority assigned to non-target distribution packages:

"causes a version to be installed unless there is a version available
belonging to some other distribution or the installed version is more
recent"

Try setting sid (or sarge) as your target distribution, and 4.50-4
should rise to 990, and be auto-upgraded. However, this means your
experimental pin for this package is too low, and needs to be "990 < P
<=1000" to get the effect of "If there's a newer one in experimental,
grab it".

> How got 4.50-1 installed then in the first place?

That would depend on the policy state when it was instslled.

From what you said earlier, I'd guess that 4.50-1 was installed when it
was in experimental, and the priority was therefore 500 < x <= 990,
which means it'll be installed if there's no version belonging to the
target release. And the above policy output shows there _is_ no target
release set.

The upshot here (and the same lesson I learnt futzing with apt-pinning)
is: Set a target release, or it won't do what you expect. ^_^

Or at the very least, (if for example you use other archives that
also claim to be unstable, and you only want to fall back on them
if Debian/unstable doesn't have what you need:)

Package: *
Pin: release o=Debian,a=Unstable,c=main
Pin-Priority: 990

Which is roughly the same as picking a target release, but doesn't
give 990 to non-Debian archives marked Unstable.

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: Emulated buildds (for SCC architectures)?

[Wouter Verhelst]

On Mon, Mar 21, 2005 at 08:47:41AM -0500, Stephen Frost wrote:
> * Anthony Towns (aj@azure.humbug.org.au) wrote:
> > >Apparently the feeling wrt distcc is somewhat different and is likely to
> > >be a more generally accepted solution to the slow-at-compiling issue.
> > 
> > I like distcc -- heck I went to high school with the author -- and I 
> > think it's cool. I don't know that it'd be enough to get ports like m68k 
> >  working quickly enough to meet the 1 or 2 buildds requirement, and it 
> > doesn't solve the other issues that arise at all. But hey, I wouldn't 
> > have a problem with an m68k+distcc/i386 pairing as a buildd, if all the 
> > other requirements were also being dealt with properly. That's also more 
> > a DSA/buildd issue though, neither of which are hats of mine.
> 
> Alright, perhaps I misunderstood the responsibilities a bit.  buildds
> are run by DSA 

No. There's some overlap between the groups of 'buildd admins' and
'DSA', but they are by far not the same.

> (Which I'm guessing is the 'System Administration' group
> on w.d.o/intro/organization)?

Yes.

> Is access to wanna-build also managed by that group?

Access to wanna-build is managed by James Troup and Ryan Murray.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: *** SPAM *** Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Sven Luther]

On Mon, Mar 21, 2005 at 03:10:34PM +, Matthew Wilcox wrote:
> On Mon, Mar 21, 2005 at 03:20:29PM +0100, Sven Luther wrote:
> > > Anyway, regarding kernels: I can imagine sometimes, especially with the
> > > backlog we have currently, a swift processing of some kernel package
> > > might be warranted and help Sarge. If there is such a case, it would
> > > help if someone other than yourself from the kernel team contact the
> > > right email address[3] about it, I had a hard time distilling from your
> > 
> > Why not me ? I would very much like a reason for that, am i in some way
> 
> Because you are impossible to deal with.  I think this mail from you shows
> all the characteristics which make you such a pain in the fucking arse.
> See a psychologist.  Really.

Thanks. Maybe i should resign from my debian duties then since i am not
wanted. Do you volunteer to take over my packages ? Please handle parted for
which i am searching a co-maintainer since > 6 month, and take over the
powerpc kernels as well as do my job in the debian kernel team, as well as the
support of powerpc issues in d-i and the maintainance of a big part of the
ocaml subset.

Until you are ready to do that, it is not acceptable to imply that the
ftp-masters can be made to fail their job and threat developers like dirt just
because they have no counter power to them, and i should support every abuse
of them.

Not friendly anymore and expecting excuses from you Matthew and the whole
ftp-master team for their discrimination of me.

Sven Luther


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Wouter Verhelst]

On Sun, Mar 20, 2005 at 12:00:23PM +1000, Anthony Towns wrote:
> Darren Salt wrote:
> >I demand that Anthony Towns may or may not have written...
> >>Put them behind a firewall on a trusted LAN, use them to develop software
> >>for arm chips, and then just follow unstable or run non-security-supported
> >>snapshots. Apart from writing software for embedded arm things, I can't 
> >>see
> >>the value
> >"Linux desktop box" comes to mind...
> 
> But why would you spend over 1000 pounds on an arm Linux desktop box 
> instead of a few hundred pounds on a random i386 desktop box?

Because it's cool. In both senses of the word (have you ever had to
measure the temperature of an i386 box?)

My current laptop is not a powerpc-based one because it's cheap as
compared to equally fast i386-based hardware...

> A reasonable answer is because you're developing for arm's for embedded 
> applications; but if so, what's the big deal with using unstable or 
> snapshots, and running your public servers on other boxes?

Because you want to focus on fixing bugs in /your/ software rather than
in the toolchain that breaks it in different ways with every upgrade?

> >>-- and if an arch is just going to be used for development, does it really
> >>need all the support we give stable in order to make it useful for servers
> >>and such?
> >Probably not, but ISTM that you'll first have to ascertain that it *is* 
> >only
> >being used for development before you can say that that support definitely
> >isn't needed.
> 
> Uh, you've got that round the wrong way: you don't do something because 
> you can't say support definitely isn't needed, you do something because 
> you *can* say support definitely *is* needed.

Joey Schulze has already said that doing security support for two
architectures is exactly as hard as doing security support for twenty
architectures, so the point about supporting stable is kindof moot. The
same isn't true for testing, obviously.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: A new arch support proposal, hopefully consensual (?)

[Sven Luther]

On Mon, Mar 21, 2005 at 12:26:13AM -0800, [EMAIL PROTECTED] wrote:
> It's not so fair to perpetrate a straw man attack against Sven's whole
> proposal just because he can't spell perfectly. Give the man credit
> where it's due for trying to better Debian.

Hehe, no offense taken, and i can understand Tapio's dislike of seing his
capital mispeled :)

> BTW, Sven and the Vancouver crew, I appreciate your collective thinking
> about what's right for Debian and the minor arches, being a SPARC user
> with a production Debian system.

No feedback from the vancouver team though, me guess they will do their stuff
in their corner, let's just hope that it will benefit everyone.

> --- Tapio Lehtonen <[EMAIL PROTECTED]> wrote:
> > On Sun, Mar 20, 2005 at 12:45:33PM +0100, Sven Luther wrote:
> > > discussion forward in such a way that we can get a resonable
> > discussion at the
> > > helsinski debconf'05 meeting.
> > > 
> > 
> > That's Helsinki, you ignoramus, you.

Yep, my bad, i ask apology for the mispelling. Actually i should have followed
my first instuition and say onyl debconf'05.

Friendly,

Sven Luther


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Bill Allombert]

On Sun, Mar 20, 2005 at 06:17:10PM -0800, Steve Langasek wrote:
> The primary alpha buildd last summer, lully.d.o, went off-line due to
> hardware failures and we were left with an under-powered backup, escher,
> that was unable to keep up with the package load.  This persisted for more
> than a month, IIRC, until goedel.d.o could be brought on-line to replace
> lully.  Goedel has been down for a moderate period of time at least once
> since then.
> 
> For sparc, a second buildd was brought on-line on auric this year because
> (IIRC) vore was not keeping up with the upload volume at the time; this
> required effort on DSA's part to clear enough disk space to be able to run a
> buildd, until which time sparc was holding some RC bugfixes out of testing.
> If sparc had had a buildd in reserve, this would not have affected the flow
> of development for sarge.  Auric is now off-line, as noted.
> 
> ARM, mips, and mipsel have each repeatedly had problems keeping up with
> unstable due to hardware failures.  (Sometimes compound hardware failures,
> which are obviously going to be statistically more common when you need more
> pieces of hardware to keep up in the first place...)

Each time, we were told these incident would not impact the release
become the buildd had plenty of time to catch up, and that the situation
was under control and that the help proposed in term of new hardware and
manpower was not needed at that stage.  

Suddenly, this is so much a problem we are considering dropping 8
architectures ? In that case, isn't it time to first reconsider all the
offers ?

> These incidents have come to my attention precisely because they've impacted
> my work as release manager.  I do not want to spend my time during the etch
> release cycle cajoling porters into getting buildd hardware back on-line --
> I have spent too much time already waiting on buildds for sarge to be
> willing to do that again.  Buildds for release architectures need to be
> keeping up on an ongoing basis, not just when everything's working right;
> because the odds are very much against everything working right, on all
> release architectures, for the duration of a release cycle unless there's
> redundancy in place.  I'm not willing to accept an architecture as a release
> candidate for etch unless there is redundancy in place -- if a port is not
> willing to provide enough buildd hardware to prevent hardware failures from
> causing my work to pile up, then I'm not willing to release manage that
> port.

Of course they need to, but so far we were told everything was working
fine which does not provide a big incentive toward improving the buildd
network, especially when the w-b admins are designing the new w-b
infrastructure and had probably less time to deal with the offers.

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

Imagine a large red swirl here.


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

Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Andreas Barth]

Dear, all,

> [...]

I'm quite unhappy that this thread has turned so bad.  Please, all of us
who are part of this thread, can we please try to get the heat out.

I think we all are happy that ftp-masters and -assistents are currently
working on reducing the NEW queue to a reasonable size.  This will have
some good effect not only on the kernel, but also on every other package
in Debian.  I also think that we should be thankful for their hard work.

Also, I think we all know that keeping the kernel in sync is currently a
not too easy job.  So, for very similar reasons, we all should be happy
with the steady progress we're having on the kernel.  If we consider
woody's situation, we have by far too many kernel packages - a problem
that was solved by the kernel team for sarge.


So, we all are doing a hard job, and life is sometimes just stressing.
It would be really great if we can manage to keep the heat out, that
would help us all to do a better (and more enjoyable) job.


Thanks for your attention,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Wouter Verhelst]

On Wed, Mar 16, 2005 at 08:34:44PM -0800, Thomas Bushnell BSG wrote:
> One of my hopes for the new ftp/scc criteria is that buildds will be
> much better maintained than they are currently, with a single set of
> clear standards, which every single buildd is required to follow, and
> with extra buildd capacity.

Given that the FTP/SCC criteria have (also) been created by those who
are currently being bashed the most for not being very responsive
regarding buildd maintenance, I doubt this will actually help.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: *** SPAM *** Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Andreas Barth]

* Matthew Wilcox ([EMAIL PROTECTED]) [050321 17:05]:
> I'm not going to volunteer for them as I intend to leave Debian
> shortly after sarge releases.

Why do you intend to leave Debian?


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: The 98% and N<=2 criteria

[Peter 'p2' De Schrijver]

On Mon, Mar 21, 2005 at 03:09:26PM +0100, Andreas Barth wrote:
> * Wouter Verhelst ([EMAIL PROTECTED]) [050321 15:05]:
> > On Sun, Mar 20, 2005 at 03:16:08PM +0100, Andreas Barth wrote:
> > > Well, the toolchain is perhaps not the part where they turn up most
> > > likely, but it's the part that creates most of the workload and delays.
> 
> > Uh. Most porting bugs that require attention fall in one of the
> > following areas:
> > * Toolchain problems (Internal Compiler Errors, mostly)
> > * Mistakes made by the packager. Quite easy to fix, usually.
> > * Incorrect assumptions in the source code. These are becoming
> >   increasingly rare these days, IME.
> 
> Exactly. And if you s/workload/workload for the release team/, than the
> first one is the usual spot for issues for us. The middle one is fixed

No. Because you can always consider to leave the package out for that
specific architecture (except if it would be a really important one).
That would be far more acceptable then throwing out the complete archive
for that architecture, that would be 'het kind weggooien met het
badwater'.

Cheers,

Peter (p2).




signature.asc
Description: Digital signature

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Wouter Verhelst]

On Sun, Mar 20, 2005 at 02:36:12PM -0800, Thomas Bushnell BSG wrote:
> Ben Collins <[EMAIL PROTECTED]> writes:
> 
> > I think they are designed too stringently. Guidelines should describe the
> > level of stability an arch is required to meet, and let the implementation
> > be whatever is needed, on a per arch basis, to meet those requirements.
> 
> I think a reasonable requirement is "will not stop entirely due to the
> destruction of any single building by fire."

Setting up a second buildd host takes as much as 'install the box,
install buildd, create chroot, configure sbuild, configure buildd, test,
setup link to wanna-build'. On reasonably fast hardware and with anyone
experienced in buildd, this takes half a day -- less, if the 'install
the box' part has already been done.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: NEW handling ...

[Sven Luther]

On Mon, Mar 21, 2005 at 07:42:11PM +1000, Anthony Towns wrote:
> Sven Luther wrote:
> >And what do you say of aj denying there is a NEW problem on the debian-vote
> >threads ? 
> 
> I don't know what Steve says, but I say: Cite.

I don't care what you say, i am out of this anyway, there is no way i can
continue spending my free time in debian if it can be ignored just because
some people are to proud or whatever to even recognize they have made an
error, and force a hate-campaign on anyone who may just open his mouth and
critizice.

> I don't believe I said any such thing -- NEW processing has been a 
> problem for some months now, which is why we were working on adding a 
> couple of new people to process NEW.

No ? look at your replies on -vote ? 

> That said, I believe you and others have been ridiculously hyperbolic in 
> how large a problem it's been.

And i believe you and others have been hyperbolic in how you ignore the other
DD, just because you are in power and can do as you please with the project.

Really hurt by this treatment,

Sven Luther


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Wouter Verhelst]

On Sat, Mar 19, 2005 at 01:48:42AM -0800, Steve Langasek wrote:
> On Tue, Mar 15, 2005 at 02:10:47PM -0500, Greg Folkert wrote:
> > I am currently in the process of acquiring rotated out of production
> > machines for 3 of the 5 architectures I support. I make a run to the
> > right-coast of the US once every 2 months and pickup sometimes 10 - 4-16
> > processor machines with disk and typically a dozen of GB of memory and
> > gaggles of disk. I rebuild/recondition most of these machines and
> > distribute them to NPOs that need this kind of horsepower but can't
> > afford current stuff or even used stuff from those same suppliers. I put
> > Debian on them and this makes a huge investment in the long term health
> > of these Orgs.
> 
> > If these machines are no longer fully supported by Debian... how can I
> > continue to do this.

Of course I can't speak for Greg, but let me answer these questions how I
think they will have to be answered for most m68k users:

> What does "fully supported" mean to you?

'there is a stable with security updates for the architecture, that is
in sync with the rest of Debian'

> What are the use cases for these machines?

Hobbyists playing with old hardware; people running home servers on
them; people running firewalls on them; possibly also embedded
development.

> Which aspects of stable are required by these users?

The low amount of updates that are produced by an average daily 'apt-get
update; apt-get upgrade'. The fact that you can test and develop your
scripts on your more modern hardware before installing them on the old
machines, without having to modify them to run on the different versions
of the software available for the old hardware.

> > How much is the difference between Debian running on "Humidifier in the
> > Basement" reputation, and a "We release more often than Ubuntu"
> > reputation?
> 
> > But, serious, how much do you think Debian will be hurt with:
> 
> > Compare these:
> > 1. Debian the "Universal OS"
> > 2. Debian the "Almost-Sorta-Kinda-used-to-be Universal OS"
> 
> > 3. "Old as fossilized dinosaur poo, and as stable, but runs on
> > everything including the humidifier in the basement"
> > 4. "Very recent, since it doesn't really support NON-big 4
> > processors anyway, so why not run Fedora Core"
> 
> > Personally, I like 1 and 3. They are the 2nd and 3rd most important
> > technical reasons I chose Debian. 1st technical reason is the Debian's
> > maintainability. Please oh please let us not change my mind for me.
> 
> I'm assuming your humidifier isn't connected to the public Internet, and
> doesn't need ongoing security support...?

'domotics system'. Some of those /are/ connected to the Internet (but
then again, usually you have a firewall in between).

> We're also constantly hearing from users who are using Debian in settings
> where they *would* benefit from security support, but are running testing
> or unstable because woody's fossilization factor is too high for them.  How
> would you suggest that we balance these users' needs for a more frequent
> stable release, against the needs of users like yourself who need broader
> arch coverage?

I'm not yet convinced that the only way to reach a higher release
frequency is to drop support for 80% of our architectures...

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: *** SPAM *** Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Sven Luther]

On Mon, Mar 21, 2005 at 03:45:10PM +, Matthew Wilcox wrote:
> On Mon, Mar 21, 2005 at 04:08:19PM +0100, Sven Luther wrote:
> > Thanks. Maybe i should resign from my debian duties then since i am not
> > wanted. Do you volunteer to take over my packages ? Please handle parted for
> > which i am searching a co-maintainer since > 6 month, and take over the
> > powerpc kernels as well as do my job in the debian kernel team, as well as 
> > the
> > support of powerpc issues in d-i and the maintainance of a big part of the
> > ocaml subset.
> 
> I think Debian would be better finding someone else to do those tasks,
> yes.  I'm not going to volunteer for them as I intend to leave Debian
> shortly after sarge releases.  I can't believe Debian is so short on
> skills that it needs you.

DON'T EVER ADDRESS ME IN THE FUTUR AND GET YOURSELF LOST.

Anyway, i am out of this and you and Jeroen have managed to do it, and all
those self-rigtheous ftp-master and other release team, who think someone
complaining just whines, and don't care that they do exactly the same, or
those who like to complain about being the recipient of flamewars, and then
doing the exact same thing to others.

Sven


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

Re: Ubuntu Patches

[Matt Zimmerman]

On Mon, Mar 21, 2005 at 12:36:42PM +0100, Norbert Tretkowski wrote:

> That helps a lot, thanks Scott! What about offering a way to subscribe
> to packages, so you'll get informed by mail if a package in Ubuntu is
> changed, maybe with an interdiff applied to that mail?

This isn't possible yet, but we are working on it.

-- 
 - mdz


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Wouter Verhelst]

On Sat, Mar 19, 2005 at 04:19:03AM -0800, Steve Langasek wrote:
> On Fri, Mar 18, 2005 at 05:43:26PM +0100, Adrian Bunk wrote:
> > I do still doubt that testing actually is an improvement compared to the 
> > former method of freezing unstable, and even more do I doubt it's worth 
> > sacrificing 8 architectures.
> 
> If the proposal already gives porters the option to freeze ("snapshot")
> unstable to do their own releases, in what sense is this "sacrificing"
> architectures?

Have you seen one porter who believes that taking an unstable snapshot
and make a release off of that will actually be enough? Those porters
that I've seen participating in this thread actually said it would be
entirely useless. Even more so, Joey Schulze told us that this idea
would not work in terms of supporting it from his part, so it's a
bad idea in general.

Obviously the porters could all do their own releases, but then you're
duplicating work that does not need duplication in a single project; you
could just as well ask us to go to sourceforge.net and release there,
because the net effect would be the same.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: NEW handling ...

[Tollef Fog Heen]

* Matthew Palmer 

| You'd also have to modify fernanda to check whether sys.stdout is a
| TTY, and not invoke less if it isn't, since at the moment it automatically
| pipes it's output through less.  The colour codes might also be an issue, so
| fernanda may need extra help not to screw that up.

: [EMAIL PROTECTED] ~ > head -5 /etc/passwd | less| cat
root:x:0:0:root:/root:/bin/bash
sashroot:x:0:0:root:/root:/bin/sash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh

less DTRT if output isn't a tty and acts like cat(1) (except I think
it still does the LESSOPEN magic).

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Re: The 98% and N<=2 criteria (was: Vancouver meeting - clarifications)

[Wouter Verhelst]

On Fri, Mar 18, 2005 at 11:32:08PM -0800, Steve Langasek wrote:
> As pointed out in a recent thread, most of the core hardware portability
> issues are picked up just by building on "the big three" -- i386, powerpc,
> amd64.  If we know the software isn't going to be used, is it actually
> useful to build it as a "QA measure"?

A QA measure for kernel/toolchain issues, sure. Many compiler bugs are
identified by compiling 10G worth of software for an architecture;
perhaps we should have a better way of tracking these, but it surely is
a class of problems that /cannot/ be identified by just building on the
big N architectures.

> What value is there, in fact, in checking for bugs that will only be
> tripped while building software that isn't going to be used?

Many, many more software than just the one that Debian distributes
exists; and many developers may attempt to build their software using
gcc on exotic hardware.

By building 10G worth of software for an architecture, it is /very/
likely that most ICE bugs have been found, and at least some, if not
many, of them fixed, by the time Debian releases. This helps people
developing software for that hardware platform -- and not just if they
happen to be Debian users. This is of extreme value to the Free Software
community as a whole.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: The 98% and N<=2 criteria (was: Vancouver meeting - clarifications)

[Wouter Verhelst]

On Sat, Mar 19, 2005 at 09:52:18AM -0600, Gunnar Wolf wrote:
> As you say, _most_ of the issues are triggered by one of those three
> chips, not all. And, by not making a hard requirement to compile the
> packages which will not be used, you are not holding the project back
> waiting for m68k's KDE. Probably m68k will _never_ compile KDE, as I
> doubt their buildds are ever idle

kiivi.cyber.ee, the unstable m68k buildd that I maintain, is usually
idle for about 30% of the time. /Of course/ we build KDE, there's no
point in not doing that.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: NEW handling: About rejects, and kernels

[Petter Reinholdtsen]

[Sven Luther]
> the problem is not the reject, is the no news in weeks and no
> communication channel open. But again, i think and hope that this
> will become better now.

I agree.  Complete silence and no feedback is a real problem when it
happen, and only worse if it is an official debian role failing to
communicate.  But I believe things are improving a lot when it comes
to the ftpmaster role, and have great hopes that Jeroen is part of the
solution. :)

>> Maybe, if one would reply to all mails you send out, one wouldn't
>> have time for ANY other Debian work.

No-one is asking anyone to reply to the wast flod of emails coming
from Sven the last few days.  But emails sent to the official debian
role ftpmaster should get some kind of response.

> Well, sending email to a discussion forum like debian-devel, and
> sending email to a debian-role like ftp-master is not comparable,
> and i think it shows a profund lack of responsability on your part
> even suggesting this.

I believe Joroen tried to express that mistakes do happen, and that
the ftpmasters can delete email by mistake when their mailbox is
filling up.

Perhaps this could be solved with some kind of ticket system handling
email to the official roles in debian?  I'm not sure if BTS is the
best option to handle emails to ftpmaster, leader and others.  Perhaps
request-tracker is a better option?  We use it at work, and it seem to
do request handling quite well (at least when we added the email
administration interface. :).

What surprises me is the energy and hostality Matthew Wilcox
demonstrates by attacking you in later private emails.  A good thing
he isn't part of the ftpmaster team (as far as I can see).  The
ftpmasters seem to have a professional attitude towards the role they
have in the project.  I wish we could expect that from all the
participants in the project.

(But you are right, Sven.  No-one should have to accept abuse for the
work one does as a volunteer in the Debian project.  That applies for
both you, the ftpmasters, the release managers, all the debian
developers and the users.  Those unable to behave sivilised against
their fellow volunteers should be ashamed of themselves.)


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

Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Sven Luther]

On Mon, Mar 21, 2005 at 03:11:06PM +0100, Jeroen van Wolffelaar wrote:
> Maybe, if one would reply to all mails you send out, one wouldn't have
> time for ANY other Debian work. For example, you contributed 75 mails[1]
> within 24 hours to the Vancouver thread, consisting (excluding quoted
> text) of about 7522 words in 43kB of hand-written text[2]. I'm sorry,
> but you think it's weird people can't resist accidentally hitting the 'd'
> key when seeing an incoming mail from you?

And what about the email i sent to remove some erroneously ACCEPTED and then
REJECTED kernel package from the REJECT queue ? I had to mail twice about
this, and nothing ever happened for almost a month of so, all the while you
where spamming all of debian-kernel daily with said bogus reject message ?

Hurt, 

Sven Luther


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

Re: NEW handling: About rejects, and kernels

[Sven Luther]

On Mon, Mar 21, 2005 at 05:40:44PM +0100, Petter Reinholdtsen wrote:
> [Sven Luther]
> > the problem is not the reject, is the no news in weeks and no
> > communication channel open. But again, i think and hope that this
> > will become better now.
> 
> I agree.  Complete silence and no feedback is a real problem when it
> happen, and only worse if it is an official debian role failing to
> communicate.  But I believe things are improving a lot when it comes
> to the ftpmaster role, and have great hopes that Jeroen is part of the
> solution. :)

No, he is not, as far as i am concerned, unless he presents his apologies
first.

> > Well, sending email to a discussion forum like debian-devel, and
> > sending email to a debian-role like ftp-master is not comparable,
> > and i think it shows a profund lack of responsability on your part
> > even suggesting this.
> 
> I believe Joroen tried to express that mistakes do happen, and that
> the ftpmasters can delete email by mistake when their mailbox is
> filling up.

No, that is not acceptable, and probably not the right reason for this. Until
evidence proves otherwise, it is just because they don't care to read those
emails, and that that email address is simply forwarded to /dev/null.

> Perhaps this could be solved with some kind of ticket system handling
> email to the official roles in debian?  I'm not sure if BTS is the
> best option to handle emails to ftpmaster, leader and others.  Perhaps
> request-tracker is a better option?  We use it at work, and it seem to
> do request handling quite well (at least when we added the email
> administration interface. :).

That would be a solution. But then are the ftp-masters ready to get the
problems they receive publicly visible ?

> What surprises me is the energy and hostality Matthew Wilcox
> demonstrates by attacking you in later private emails.  A good thing
> he isn't part of the ftpmaster team (as far as I can see).  The
> ftpmasters seem to have a professional attitude towards the role they
> have in the project.  I wish we could expect that from all the
> participants in the project.

No, a professional attitude would have them reply to the people they are
working with.

> (But you are right, Sven.  No-one should have to accept abuse for the
> work one does as a volunteer in the Debian project.  That applies for
> both you, the ftpmasters, the release managers, all the debian
> developers and the users.  Those unable to behave sivilised against
> their fellow volunteers should be ashamed of themselves.)

but this have become the norm these past couple month, and Steve's 'proposal'
was the last straw.

Hurt,

Sven Luther


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

It's also not something that would totally destroy an architecture's
ability to release. Yes, it would be bad, but not the end of the world.

On Sun, Mar 20, 2005 at 02:36:12PM -0800, Thomas Bushnell BSG wrote:
> Ben Collins <[EMAIL PROTECTED]> writes:
> 
> > I think they are designed too stringently. Guidelines should describe the
> > level of stability an arch is required to meet, and let the implementation
> > be whatever is needed, on a per arch basis, to meet those requirements.
> 
> I think a reasonable requirement is "will not stop entirely due to the
> destruction of any single building by fire."  Remember: this has
> happened to Debian before, it's not some kind of fantasy scenario.
> 
> Thomas

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

> For sparc, a second buildd was brought on-line on auric this year because
> (IIRC) vore was not keeping up with the upload volume at the time; this
> required effort on DSA's part to clear enough disk space to be able to run a
> buildd, until which time sparc was holding some RC bugfixes out of testing.
> If sparc had had a buildd in reserve, this would not have affected the flow
> of development for sarge.  Auric is now off-line, as noted.


My point exactly, though. It was a problem with CPU, not a problem with
machine availability. Your alpha example is a case of hardware
availability. I recall that same event, and no one had a spare alpha, or
didn't have a place to host it. Alpha's a dead platform.

If this e3500 dies, I can get another machine within days to replace it.
I'll keep this Ultra2 (2x400mhz, 1gig ram) on standby in the event that
something happens to it, so it can be used in the interim until I get a
suitable replacement.

How's that?

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


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

Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Matthew Wilcox]

On Mon, Mar 21, 2005 at 03:20:29PM +0100, Sven Luther wrote:
> > Anyway, regarding kernels: I can imagine sometimes, especially with the
> > backlog we have currently, a swift processing of some kernel package
> > might be warranted and help Sarge. If there is such a case, it would
> > help if someone other than yourself from the kernel team contact the
> > right email address[3] about it, I had a hard time distilling from your
> 
> Why not me ? I would very much like a reason for that, am i in some way

Because you are impossible to deal with.  I think this mail from you shows
all the characteristics which make you such a pain in the fucking arse.
See a psychologist.  Really.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain


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

Re: Required firewall support

[David Weinehall]

On Sun, Mar 20, 2005 at 11:22:48AM -0600, Steve Greenland wrote:
> On 19-Mar-05, 10:00 (CST), Matthias Urlichs <[EMAIL PROTECTED]> wrote: 
> > 
> > Umm, rp_filter is for rejecting packets whose *source* address is from the
> > wrong network.
> 
> Right. I know this. But what Joel was originally talking about was
> rejection of packets on interface A that are destined for an address on
> interface B; Joel seemed to be claiming that if this didn't happen by
> default, then the OS was a "toy"; I was pointing out that Linux itself
> fails this. 
> 
> > If you want to block accepting your own address as the *destination*, then
> > no, there's no config parameter for that. Use iptables rules. :-/
> 
> And that's what we do. But some other OSs (Solaris) do support strict
> multihoming with a config parameter, it would be nice if Linux did.

netdev@oss.sgi.com <--- patches goes that way.
linux-kernel@vger.kernel.org <--- or possibly that way.


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Thiemo Seufer]

Wouter Verhelst wrote:
[snip]
> > m68k, mips, mipsel, hppa: I've got one in the basement, and I like 
> > to brag that I run Debian on it; also I occassionally get some work out 
> > of 
> > it, but it'd be trivial to replace with i386.
> 
> Aren't the first three of these also actively being used in embedded
> applications? (not sure about that one; I'm not /that/ much involved
> with embedded stuff)

Just to throw another URL in, http://www.linuxdevices.com/ is a good
starting point to find out what's currently used with embedded linux.


Thiemo


signature.asc
Description: Digital signature

Re: Alternative: Source-Centric Approach [w/code]

[Wouter Verhelst]

On Fri, Mar 18, 2005 at 07:39:06PM -0600, Gunnar Wolf wrote:
> Matthias Urlichs dijo [Tue, Mar 15, 2005 at 11:14:50PM +0100]:
> > It won't work that well for slower architectures, for the very simple
> > reason that compiling everything would take a long time.
> > 
> > m68k (as the admittedly extreme example) doesn't have ten buildd boxes
> > just because we feel like it. :-)
> 
> Being m68k among the prime candidates for SCC, why shouldn't we ponder
> using emulated autobuilders? We have some quite decent and reliable
> emulators in our archive for some architectures (i.e., basilisk2 for
> m68k [in contrib because of the needed Mac ROMs], hercules for s390),
> and they do work reliably. 

It's bad enough already that the toolchain (which usually does work
reliably) breaks from time to time; having an emulator which might break
in not immediately obvious ways doesn't sound like a particularly
appealing idea to me.

There is no problem whatsoever for us m68k buildd maintainers in
supporting a dozen or so buildd machines -- or more, if required. It
works like a charm.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: *** SPAM *** Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Matthew Wilcox]

On Mon, Mar 21, 2005 at 04:08:19PM +0100, Sven Luther wrote:
> Thanks. Maybe i should resign from my debian duties then since i am not
> wanted. Do you volunteer to take over my packages ? Please handle parted for
> which i am searching a co-maintainer since > 6 month, and take over the
> powerpc kernels as well as do my job in the debian kernel team, as well as the
> support of powerpc issues in d-i and the maintainance of a big part of the
> ocaml subset.

I think Debian would be better finding someone else to do those tasks,
yes.  I'm not going to volunteer for them as I intend to leave Debian
shortly after sarge releases.  I can't believe Debian is so short on
skills that it needs you.

> Not friendly anymore and expecting excuses from you Matthew and the whole
> ftp-master team for their discrimination of me.

Your emails have never had a friendly tone, despite the way you put
"friendly" at the bottom of every one of them.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain


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

Re: NEW handling: About rejects, and kernels

[Petter Reinholdtsen]

[Petter Reinholdtsen]
> in later private emails.

This was a misunderstanding on my part, due to the fact that I
received the replies from Sven before I received the replies from
Matthew.  The fact that the replies were done on public lists and not
in private email do not change how I react to their content.


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Anthony Towns]

Wouter Verhelst wrote:
Joey Schulze has already said that doing security support for two
architectures is exactly as hard as doing security support for twenty
architectures, so the point about supporting stable is kindof moot. The
same isn't true for testing, obviously.
Joey gets to say this because others have done all the work to handle 
that support for him and the security team.

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

Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Christian Perrier]

> I'm quite unhappy that this thread has turned so bad.  Please, all of us
> who are part of this thread, can we please try to get the heat out.


I can't agree more. What I have seen up to now is make me very
sad. Seeing Sven considering to resign is sad news for me.

I won't play the "others started first" game, I leave this to my kids
(well, probably even the youngest of them wouldn't play this game
anymore).

Up to now, I have seen very rude and unacceptable mails addressed
directly to Sven Luther. There has been other rude mails sent to other
people as well which is obviously unacceptable as well (no, Sven, not
necessary from you). And I certainly missed a lot of other crap
because I have read about 5% of these threads.

The most difficult thing to do, especially by mail, is just
recognizing that one went too far or just that you are wrong. Several
people went too far in this thread. I think all should really consider
doing what adult and mature people would do : just apologize, take a
break and avoid definitive statementsand continue working in this
project, because sometimes our arguments are not only out weakness but
our strength.

I don't agree with several things written by Sven here or there. I
probably agree with a lot of others...and I just don't understand
another bunch of such things. 

I have seen serious attempts to make proposals which seems quite
constructive to me. I also have seen probably far too much mails
(sorry, Sven, but IMHO you really should have slowed your contribution
to all threads but, well, "ce qui est fait est fait")

But even what I may not agree with does not prevent me to consider
that losing his valuable input is not good for this project, just like
losing the work of any individual involved here would be bad.

OK, people, as far as I have seen we are all supposed to be adult
people herenot in a kind of kindergarten.

So, who starts and just makes one or two steps backward. And, please
no "He should do so first" answerfor $deity's sake, please be
adult.



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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Sven Luther]

On Mon, Mar 21, 2005 at 12:17:45PM +0100, Thiemo Seufer wrote:
> Sven Luther wrote:
> [snip]
> > > For sarge, kernels are built in a two-stage process. First is to create
> > > a dsfg-free .deb from the upstream source which contains a source
> > > tarball, second is to build kernel images from another (arch-specific)
> > > .deb which build-depends on the source .deb. In the second stage,
> > > arch-specific patches can be added.
> > 
> > You forgot the third stage of the .udebs built.
> 
> They can be "built" immediately after the kernel images were accepted,
> there's little potential for a delay.

Only if they get forgotten to build, which happens from time to time.

Sven Luther


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

Re: *** SPAM *** Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Matthew Wilcox]

On Mon, Mar 21, 2005 at 05:10:12PM +0100, Andreas Barth wrote:
> * Matthew Wilcox ([EMAIL PROTECTED]) [050321 17:05]:
> > I'm not going to volunteer for them as I intend to leave Debian
> > shortly after sarge releases.
> 
> Why do you intend to leave Debian?

The Vancouver meeting summary upset me, not because of the proposals
to drop architectures, but because it contained a reminder of the
Social Contract changes.  The project is moving to what I believe to
be a ridiculously extremist position.  I can't support the new Social
Contract, and wouldn't sign up for it if I were going through NM right
now.  So the only honourable thing for me to do is resign at the point
when it come into effect.

It saddens me greatly that we've come to this situation.  I've been
proud to be a Debian Developer for the past 6 years.  I'd like to say,
as others have when resigning, that I will continue to run Debian on my
machines, but I can't.  Moving documentation to non-free makes Debian
a less suitable distribution for me.  I shall have to look around and
see what other distributions suit my needs.

I'd like to thank my friends in Debian who've made it worth working on.
Those who've been involved in the PA-RISC port (which I first joined
Debian to work on).  The Apache team have done a fantastic job, and I'm
proud of how that worked out.

I didn't realise how emotionally attached I was until I came to write
this mail.  I really wish things could have worked out better.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Thomas Bushnell BSG]

Matthias Urlichs <[EMAIL PROTECTED]> writes:

> The choice is to either restrict the required client-side fanciness to
> what most of our mirrors are willing to accept, or go without mirrors 
> (OK, OK ... fewer mirrors anyway), which is something I don't think we'd
> want.

The whole point of SCC was to go without mirrors.


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

Re: NEW handling: About rejects, and kernels

[Christian Perrier]

> I am truly sorry for loosing you.  You have done a good job helping
> Debian progress the state of free software, and it is sad that you
> decide to throw in the towel because of hard language from a fellow
> Debian volunteer. :(


I personnally can't stop thinking that Sven can reconsider his too
quick decision. Doing so would be a great sign of maturity and
relativisation (sorry, I'm falling outside my English skills and could
certainly express this better in French to Sven).



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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Wouter Verhelst]

On Wed, Mar 16, 2005 at 08:14:59PM -0800, Steve Langasek wrote:
> This proposal is, first and foremost, about setting concrete criteria that
> we can hold the ports to for etch, to get away from wishy-washy, "one more
> week for kernel updates on $arch", "$arch2 isn't doing so well, maybe we
> should drop it from testing" problems that the release team is currently
> suffering from.  The idea of setting criteria should not be controversial,
> though I can understand that specific criteria we've suggested may be.

True. The specific criteria as have been suggested are most certainly
controversial; but setting criteria for ports to keep up with should not
necessarily be.

It may be a bad idea to suddenly set a whole bunch of criteria at once;
big and controversial changes are not how Free Software in the 'bazaar'
model generally works.

For that reason, why not reduce the whole proposal to...

* The separate mirror stuff is implemented (I don't think anyone has any
  problems with that, except for its name which should be 'nybbles'
  IMO)
* All ports need to
  * build packages within (to be defined) days, on average, of them
getting in the 'Needs-Build' state (this may require applying the
patch by Matthias Ulrichs to wanna-build)
  * have some basic UNIX functionality, such as resolving DNS names,
firewall capacity, and some (to be defined) subset of POSIX.

...and address any problems after that as they come up?

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: NEW handling: About rejects, and kernels

[Petter Reinholdtsen]

[Sven Luther]
> No, he is not, as far as i am concerned, unless he presents his
> apologies first.

For what?  Commenting on your wast amount of email posted the last few
days, and his suggestion that the amount of email could make the
ftpmasters delete mails by mistake?  I can not really believe that is
your problem, so please enlighten me.

> No, that is not acceptable, and probably not the right reason for
> this. Until evidence proves otherwise, it is just because they don't
> care to read those emails, and that that email address is simply
> forwarded to /dev/null.

I didn't say it was acceptable.  I tried to put it in perspective.
I'm well aware of at least some of the communication issues with the
ftpmasters, but truly believe these problems are because the
ftpmasters are overworked, not because they are evil.  And I believe
this even though one of the ftpmasters told me on IRC to stop wasting
his time when I wanted to discuss making the list of packages in NEW
public.  I put it on the account of misjudgement during stress, not
evil will.

I suspect you would be better off if you accepted that misjudgement
and mistakes happen also for the ftpmasters.  After all, your emails
haven't been the perfect examples of rational and clear speek either
(though not as hostile as others on the list. :).  I do not hold that
against you, and wish you didn't hold such miscommunications and and
misjudgements against the other volunteers in Debian.

> That would be a solution. But then are the ftp-masters ready to get
> the problems they receive publicly visible ?

I didn't propose to make it all public.  request-tracker is capable of
fine grained access control.

> No, a professional attitude would have them reply to the people they
> are working with.

Again, I agree that the ftpmaster role should reply to all requests.
But if the volunteers filling this role are very busy, it does not
help to shout at them and send even more email.  A different solution
must be found, and I hope and believe we are on our way to a solution
to the problems the project is facing.

> but this have become the norm these past couple month, and Steve's
> 'proposal' was the last straw.

I guess I do not read the proposal the way you read it.  I read it as
a document describing the problems the release team and the ftpmaster
experiences with the release process, and their ideas on how to
improve the situation.  But first and formost, I read the proposal as
a good step forward for the release of sarge.  After all, the ideas
for reorganizing the process for etch wasn't the most important part
of the "vancouver" announcement.  The most important part was that the
release managers and the ftpmasters are coordinated in their work to
release Sarge.

Since the meeting 189 packages have been processed from the NEW queue.
I believe this is the result of the meeting, where the ftpmasters was
able to meet with prospective ftpmaster assistant.  I also believe the
increased effort to release sarge is a result of this meeting.

Well, this email is already getting fairly long.  Enough hot air from
me this time, I believe.

I am truly sorry for loosing you.  You have done a good job helping
Debian progress the state of free software, and it is sad that you
decide to throw in the towel because of hard language from a fellow
Debian volunteer. :(


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

Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Sven Luther]

On Mon, Mar 21, 2005 at 06:34:00PM +0100, Christian Perrier wrote:
> > I'm quite unhappy that this thread has turned so bad.  Please, all of us
> > who are part of this thread, can we please try to get the heat out.
> 
> 
> I can't agree more. What I have seen up to now is make me very
> sad. Seeing Sven considering to resign is sad news for me.

...

Thanks for this, it is hearthening (or however you say that in english).

I should really not have participated in that thread (and i resent a bit to
Steve for it), and i am probably better of not following debian-devel, as i
had not done for ages before. 

Still i believe i have made some constructive proposals, and even if my first
posts may have been a bit too aggressive, for which i apologize, or too many,
i think it is also a prove of the passion which lies on this issue. Something
which has the potential to affect many of what we believe debian is, and which
is handled by utter contempt, at least in the initial posting.

Still hurt though,

Sven Luther


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Wouter Verhelst]

On Thu, Mar 17, 2005 at 07:22:37PM -0800, Steve Langasek wrote:
> There would definitely be duplication of arch:all between ftp.debian.org
> and ports.debian.org (let's call it ports), as well as duplication of the
> source.

I don't think this is a good idea. I'm thinking something like this
could work:

deb http://$MIRROR/debian stable main
deb-src http://$MIRROR/debian-source stable main

or (if you're on a minority architecture)

deb http://$MIRROR/debian-nybbles stable main
deb-src http://$MIRROR/debian-source stable main

with a requirement for mirror operators to always have debian-source if
they want to have either of debian-nybbles or plain 'debian'.

This doesn't address _all yet; but I guess it could be done in the same
way.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: Ubuntu Patches

[Colin Watson]

On Mon, Mar 21, 2005 at 08:46:25AM -0800, Matt Zimmerman wrote:
> On Mon, Mar 21, 2005 at 12:36:42PM +0100, Norbert Tretkowski wrote:
> > That helps a lot, thanks Scott! What about offering a way to subscribe
> > to packages, so you'll get informed by mail if a package in Ubuntu is
> > changed, maybe with an interdiff applied to that mail?
> 
> This isn't possible yet, but we are working on it.

(In the meantime, some kind of client-side filtering of the Ubuntu
*-changes mailing lists might be possible, if admittedly awkward.
*-changes are generally low-traffic enough to be readable anyway.)

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: NEW handling: About rejects, and kernels

[Sven Luther]

On Mon, Mar 21, 2005 at 08:40:11PM +0100, Christian Perrier wrote:
> > I am truly sorry for loosing you.  You have done a good job helping
> > Debian progress the state of free software, and it is sad that you
> > decide to throw in the towel because of hard language from a fellow
> > Debian volunteer. :(
> 
> 
> I personnally can't stop thinking that Sven can reconsider his too
> quick decision. Doing so would be a great sign of maturity and
> relativisation (sorry, I'm falling outside my English skills and could
> certainly express this better in French to Sven).

Yep, when sarge is safely out of the way in a couple of month or whatever.

Hurt,

Sven Luther


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

Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting

[Wouter Verhelst]

On Wed, Mar 16, 2005 at 04:49:48PM +0100, Bastian Blank wrote:
> On Wed, Mar 16, 2005 at 04:11:21PM +0100, Wouter Verhelst wrote:
> > > How many *.debian.org machines are actually *owned* by the project or DDs?
> > All of them. Otherwise they wouldn't be *.debian.org.
> 
> Please define "owned".

Okay, I see where you're coming from. That wouldn't work; forget what I
said.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: NEW handling: About rejects, and kernels

[Sven Luther]

On Mon, Mar 21, 2005 at 08:28:44PM +0100, Petter Reinholdtsen wrote:
> [Sven Luther]
> > No, he is not, as far as i am concerned, unless he presents his
> > apologies first.
> 
> For what?  Commenting on your wast amount of email posted the last few
> days, and his suggestion that the amount of email could make the
> ftpmasters delete mails by mistake?  I can not really believe that is
> your problem, so please enlighten me.

Sorry, but if they are not able to properly filter mails sent to the canonical
ftp-master address from the rest of their personal mail, i don't think they
are fit to do the job.

Also, his hints that futur mail from me will be ignored is unaceptable as
well, and i cannot work with people who don't take their responsabilities
seriously.

> > No, that is not acceptable, and probably not the right reason for
> > this. Until evidence proves otherwise, it is just because they don't
> > care to read those emails, and that that email address is simply
> > forwarded to /dev/null.
> 
> I didn't say it was acceptable.  I tried to put it in perspective.
> I'm well aware of at least some of the communication issues with the
> ftpmasters, but truly believe these problems are because the
> ftpmasters are overworked, not because they are evil.  And I believe

The real problem is that they deny there is a problem, how do you hope to get
it fixed then ? 

> this even though one of the ftpmasters told me on IRC to stop wasting
> his time when I wanted to discuss making the list of packages in NEW
> public.  I put it on the account of misjudgement during stress, not
> evil will.
> 
> I suspect you would be better off if you accepted that misjudgement
> and mistakes happen also for the ftpmasters.  After all, your emails

So, but then i expect the same courtesy to go both ways, which it does not,
and furthermore they have the ultimate power to hinder my work and make my
live difficult, while the otherway is not true. With great power comes great
responsability, and the lest of them is to be civil, and reply to emails sent
by developers to the ftp-master role address.

> haven't been the perfect examples of rational and clear speek either
> (though not as hostile as others on the list. :).  I do not hold that
> against you, and wish you didn't hold such miscommunications and and
> misjudgements against the other volunteers in Debian.

No, but they plainly refuse to admit there is a problem, what hope do you see
to it ever been fixed then ? 

> > That would be a solution. But then are the ftp-masters ready to get
> > the problems they receive publicly visible ?
> 
> I didn't propose to make it all public.  request-tracker is capable of
> fine grained access control.
> 
> > No, a professional attitude would have them reply to the people they
> > are working with.
> 
> Again, I agree that the ftpmaster role should reply to all requests.
> But if the volunteers filling this role are very busy, it does not
> help to shout at them and send even more email.  A different solution

I sent perhaps 3-4 or in any case less than 10 emails to them, over the past
two years. A couple of those was to have them clean up the reject queue which
was spaming debian-kernel daily, this hardly is shouting and sending even more
emails, isn't it. I sent one mail, and waited, and in the email spam case a
second or third a couple of weeks later if i remember well.

Someone who has not the time to reply to 3-4 civil emails in 2 years, well, he
should probably reconsider his involvement or whatever.

> must be found, and I hope and believe we are on our way to a solution
> to the problems the project is facing.

Let's hope so, but i have some doubts.

> > but this have become the norm these past couple month, and Steve's
> > 'proposal' was the last straw.
> 
> I guess I do not read the proposal the way you read it.  I read it as
> a document describing the problems the release team and the ftpmaster
> experiences with the release process, and their ideas on how to
> improve the situation.  But first and formost, I read the proposal as
> a good step forward for the release of sarge.  After all, the ideas
> for reorganizing the process for etch wasn't the most important part
> of the "vancouver" announcement.  The most important part was that the
> release managers and the ftpmasters are coordinated in their work to
> release Sarge.
> 
> Since the meeting 189 packages have been processed from the NEW queue.
> I believe this is the result of the meeting, where the ftpmasters was
> able to meet with prospective ftpmaster assistant.  I also believe the
> increased effort to release sarge is a result of this meeting.

What increasing effort, start a giant flamewar by being utterly contemptuous
of our porters ? They could have published that part separatedly and post
sarge or whatever. And i didn't see a single line of apology or recognition
that they may have been wrong.

> I am truly sorry for loosing you.  You have done a good job helping

Re: The 98% and N<=2 criteria (was: Vancouver meeting - clarifications)

[Peter 'p2' De Schrijver]

> A QA measure for kernel/toolchain issues, sure. Many compiler bugs are
> identified by compiling 10G worth of software for an architecture;
> perhaps we should have a better way of tracking these, but it surely is
> a class of problems that /cannot/ be identified by just building on the
> big N architectures.
> 

Indeed. Some of the issues I think of right now :

- wrong assumptions on sizeof base types 
- unaligned accesses
- dependency on stack growth direction

Cheers,

Peter (p2).


signature.asc
Description: Digital signature

Re: Buildd redundancy (was Re: Bits (Nybbles?) from the Vancouver...)

[Wouter Verhelst]

On Sat, Mar 19, 2005 at 03:17:33AM -0800, Steve Langasek wrote:
> > - at least two buildd administrators
> 
> > This allows the buildd administrator to take vacations, etc.
> 
> This is at odds with what I've heard from some buildd maintainers that
> having multiple buildd maintainers makes it hard to avoid stepping on one
> another's feet,

That is the opinion of the !m68k buildd admins. However, as we have
proven by now, that isn't really a problem; all it requires is some
level of coordination, which is easily achieved by having a buildd
maintainers' mailinglist (or just eachother's email addresses, if the
team is sufficiently small).

Indeed, the m68k buildd team currently consists of seven people -- Adam
Conrad, Christian Steigies, Matthias Ulrichs, Michael Schmitz, Roman
Hodek, Stephen Marenka, and myself -- yet we don't usually "step on one
another's feet".

It is, however, true that both approaches to buildd maintenance have
their advantages and disadvantages; e.g., one of the disadvantages to
our approach is that rare but still recurring problems aren't easily
identified. I still think the advantages to our approach (there's
someone to take over temporarily if I go to $far_away for three weeks,
to name just one) by far outweighs the disadvantages, however.

I should note that I would be happy to help set up a team for one or
more of the currently singly-maintained architectures, if the people
that currently maintain it are willing to either join the team or give
up maintenance of that architecture; I'm quite sure it would prove to be
a workable alternative.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: NEW handling: About rejects, and kernels

[Matthew Garrett]

Sven Luther <[EMAIL PROTECTED]> wrote:

> No, that is not acceptable, and probably not the right reason for this. Until
> evidence proves otherwise, it is just because they don't care to read those
> emails, and that that email address is simply forwarded to /dev/null.

This assertion isn't justifiable. I appreciate that you're upset about
the amount of feedback you're getting from ftp-masters, but that doesn't
mean you should take the opportunity to abuse them further. Doing so
helps nobody, and certainly doesn't encourage them to send you more
email.

Problems with communication come from both sides. If you're rude to
people, they become less likely to do useful stuff for you.
-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: Buildd redundancy (was Re: Bits (Nybbles?) from the Vancouver...)

[Wouter Verhelst]

On Sat, Mar 19, 2005 at 02:12:50PM -0800, Steve Langasek wrote:
> TTBOMK, even m68k has one buildd admin per buildd

False. There are some of us who currently don't maintain more than one
buildd host, but with the exception of Roman, we all have (or have had)
more than one buildd host under our responsability.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

How to define a release architecture

[Matthew Garrett]

Ok. I've written this based on the original d-d-a posting from Steve,
and from information cribbed from various other posts. The idea is to
focus consideration on the problems that the release team view as
needing to be solved, rather than just criticising the conclusions
reached.

To start with, here are the original criteria required for an
architecture to be considered releasable, followed by the justification
for each:

FOR AN ARCHITECTURE TO BE RELEASED

* it must first be part of (or at the very least, meet the criteria for)
  scc.debian.org (see below)

Sets the base level of technical requirements. If an architecture can't
reach the scc (ports, whatever) requirements, it shouldn't be considered
releasable.

* the release architecture must be publicly available to buy new

Avoids a situation where Debian is keeping an architecture alive. This
isn't intended to result in an architecture being dropped part way
through a release cycle or once it becomes hard to obtain new hardware.

* the release architecture must have N+1 buildds where N is the number
  required to keep up with the volume of uploaded packages

This is to ensure that all unstable packages are built in a timely
manner, and that there is adequate redundancy to prevent a single buildd
failure from delaying packages.

* the value of N above must not be > 2

This effectively sets an upper limit on the length of time a single
package may take to build, which helps ensure that doing things like
security fixes for Openoffice doesn't become a problem.

* the release architecture must have successfully compiled 98% of the
  archive's source (excluding architecture-specific packages)

A fairly arbitrary figure, but intended to prevent situations where 
packages are held back from testing by an architecture not being able to
build them. 

* the release architecture must have a working, tested installer

It's not acceptable to release without a working installer, for fairly
obvious reasons.

* the Security Team must be willing to provide long-term support for
  the architecture

All releases require security updates, again for obvious reasons.

* the Debian System Administrators (DSA) must be willing to support
  debian.org machine(s) of that architecture

This is in order to ensure that developer-accessible machines exist.

* the Release Team can veto the architecture's inclusion if they have
  overwhelming concerns regarding the architecture's impact on the
  release quality or the release cycle length

A get out clause - it must be possible for something to be refused if it
would break the release, even if it meets all the other criteria.

* there must be a developer-accessible debian.org machine for the
  architecture.

Developers must be able to test their code on a machine running that 
architecture.

So, we can effectively rephrase that in terms of a set of basic issues
that need to be addressed:

1) A single architecture must not be allowed to hold back other
architectures by being unable to keep up with building unstable, or
taking too long to build individual packages.

2) The benefit to Debian for supporting the architecture must outweigh
the costs to Debian.

3) Releases must be supportable over the course of a release.

4) It must be possible for developers to be able to test and debug code
on every release architecture.

5) If it would cause other problems, it must be possible to prevent an
otherwise conforming architecture from becoming a release candidate.

6) ? (I /think/ I've covered everything - if there are other fundamental
issues then please add them here)

The Vancouver proposals satisfy all of these, potentially at the cost of
removing some architectures from the set released by Debian. If we want
to avoid that cost, can we come up with another proposal that solves the
same problems in a way that satisfies the release team? 
-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: How to define a release architecture

[Falk Hueffner]

Matthew Garrett <[EMAIL PROTECTED]> writes:

> * the release architecture must be publicly available to buy new
>
> Avoids a situation where Debian is keeping an architecture alive.

I don't understand this. What is the problem with Debian is keeping an
architecture alive? What problem are you trying to solve here?

> * the value of N above must not be > 2
>
> This effectively sets an upper limit on the length of time a single
> package may take to build, which helps ensure that doing things like
> security fixes for Openoffice doesn't become a problem.

If the point is to set an upper limit on the length of time a single
package may take to build, why not take that directly as a criterion?
It is even more objective. It might also encourage people to split
unreasonably large packages.

-- 
Falk


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

Re: Required firewall support

[Joel Aelwyn]

On Sun, Mar 20, 2005 at 11:22:48AM -0600, Steve Greenland wrote:
> On 19-Mar-05, 10:00 (CST), Matthias Urlichs <[EMAIL PROTECTED]> wrote: 
> > 
> > Umm, rp_filter is for rejecting packets whose *source* address is from the
> > wrong network.
> 
> Right. I know this. But what Joel was originally talking about was
> rejection of packets on interface A that are destined for an address on
> interface B; Joel seemed to be claiming that if this didn't happen by
> default, then the OS was a "toy"; I was pointing out that Linux itself
> fails this. 

Not precisely accurate; I claimed that having a way to *make it* a default
was a fairly important factor. Linux does fail it, which is part of why I
think the Linux network stack blows goats in a few ways (there are others,
not the topic of this conversation). Nor does it have to be on-by-default;
there are sane (to some views) reasons to have the Linux behavior, for
example, even if I don't agree with them as a default, but being able to
flip a switch so that it was the case would suffice.

Of course, since it has been claimed that the Hurd basically supports all
of the listed criteria anyway (or, at the very least, as many as Linux
does), I'm not sure why this thread is even still going. Either someone
cares enough to write (or adapt) the management tools and it gets included,
or they don't and it doesn't because nobody in their right mind would
deploy it in any widespread fashion.
-- 
Joel Aelwyn <[EMAIL PROTECTED]>   ,''`.
 : :' :
 `. `'
   `-


signature.asc
Description: Digital signature

Re: procmail and Large File Support

[Ola Lundqvist]

On Sat, Mar 19, 2005 at 09:54:09AM -0600, Gunnar Wolf wrote:
> Ola Lundqvist dijo [Wed, Mar 16, 2005 at 09:18:33PM +0100]:
> > Hello
> > 
> > On Fri, Feb 25, 2005 at 07:45:47PM -0600, Ron Johnson wrote:
> > > On Sat, 2005-02-26 at 00:53 +0100, Santiago Vila wrote:
> > > > Hello.
> > > > 
> > > > I have several reports saying procmail does not support mbox folders
> > > > larger than 2GB. Questions:
> > > 
> > > OT here, but WTF are people smoking, to have 2GB mbox files?
> > 
> > Some people tend to have really large inboxes. I have had a number of
> > customers that have several GB inbox. They tend to get quite a lot
> > of attachments (reports etc) and do not have the time to delete mail.
> > It will grow quite fast.
> 
> Ummm... And wouldn't it make more sense for them to switch to maildir
> instead of mbox? I wouldn't like to search for new mails in there.

Of course. We use maildir for all accounts. I was just commenting
on the fact that 2 GB mailboxes is needed, and quite often.

Regards,

// Ola

> -- 
> Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450
> PGP key 1024D/8BB527AF 2001-10-23
> Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF
> 

-- 
 --- Ola Lundqvist systemkonsult --- M Sc in IT Engineering 
/  [EMAIL PROTECTED]   Annebergsslingan 37\
|  [EMAIL PROTECTED]   654 65 KARLSTAD|
|  http://www.opal.dhs.org   Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---


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

Re: The 98% and N<=2 criteria

[Andreas Barth]

* Peter 'p2' De Schrijver ([EMAIL PROTECTED]) [050321 16:55]:
> On Mon, Mar 21, 2005 at 03:09:26PM +0100, Andreas Barth wrote:
> > * Wouter Verhelst ([EMAIL PROTECTED]) [050321 15:05]:
> > > On Sun, Mar 20, 2005 at 03:16:08PM +0100, Andreas Barth wrote:
> > > > Well, the toolchain is perhaps not the part where they turn up most
> > > > likely, but it's the part that creates most of the workload and delays.
> > 
> > > Uh. Most porting bugs that require attention fall in one of the
> > > following areas:
> > > * Toolchain problems (Internal Compiler Errors, mostly)
> > > * Mistakes made by the packager. Quite easy to fix, usually.
> > > * Incorrect assumptions in the source code. These are becoming
> > >   increasingly rare these days, IME.

> > Exactly. And if you s/workload/workload for the release team/, than the
> > first one is the usual spot for issues for us. The middle one is fixed
 
> No. Because you can always consider to leave the package out for that
> specific architecture (except if it would be a really important one).

I don't get why you write "No" here. :)

Frankly speaking, if some arch decides to have no XServer (like s390),
I don't really care. The toolchain issues are the one where I care
because they either delay all archs, or lead to removing one arch more
or less in total (or to any combination of both). Also, toolchain issues
usually requires much more attention to remove a random binary package
on a certain arch.



Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: NEW handling: About rejects, and kernels

[Sven Luther]

On Mon, Mar 21, 2005 at 05:23:12PM +, Matthew Garrett wrote:
> Sven Luther <[EMAIL PROTECTED]> wrote:
> 
> > No, that is not acceptable, and probably not the right reason for this. 
> > Until
> > evidence proves otherwise, it is just because they don't care to read those
> > emails, and that that email address is simply forwarded to /dev/null.
> 
> This assertion isn't justifiable. I appreciate that you're upset about
> the amount of feedback you're getting from ftp-masters, but that doesn't
> mean you should take the opportunity to abuse them further. Doing so
> helps nobody, and certainly doesn't encourage them to send you more
> email.

I only state my own experience. I got nil reply, so what do you expect ?

> Problems with communication come from both sides. If you're rude to
> people, they become less likely to do useful stuff for you.

So ? And when i am asked to pass time on stuff because this or that need ot
the release, i should just do it ? What would you say of a maintainer who acts
like this ? QA would take over i believe since long time.

Hurt,

Sven Luther


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

Re: How to define a release architecture

[Peter 'p2' De Schrijver]

> * the release architecture must be publicly available to buy new
> 
> Avoids a situation where Debian is keeping an architecture alive. This
> isn't intended to result in an architecture being dropped part way
> through a release cycle or once it becomes hard to obtain new hardware.
> 

What problem does this rule solve ?

> * the release architecture must have N+1 buildds where N is the number
>   required to keep up with the volume of uploaded packages
> 
> This is to ensure that all unstable packages are built in a timely
> manner, and that there is adequate redundancy to prevent a single buildd
> failure from delaying packages.
> 
> * the value of N above must not be > 2
> 
> This effectively sets an upper limit on the length of time a single
> package may take to build, which helps ensure that doing things like
> security fixes for Openoffice doesn't become a problem.
> 

A far more acceptable alternative would be to not have openoffice on those 
archs.

> * the release architecture must have successfully compiled 98% of the
>   archive's source (excluding architecture-specific packages)
> 
> A fairly arbitrary figure, but intended to prevent situations where 
> packages are held back from testing by an architecture not being able to
> build them. 
> 

In which case those packages can simply be not available for the
architecture in question.

> * the release architecture must have a working, tested installer
> 
> It's not acceptable to release without a working installer, for fairly
> obvious reasons.
> 
> * the Security Team must be willing to provide long-term support for
>   the architecture
> 
> All releases require security updates, again for obvious reasons.
> 

This requirement can be satisfied by stating that some one must be
willing to support the security team.

> * the Debian System Administrators (DSA) must be willing to support
>   debian.org machine(s) of that architecture
> 
> This is in order to ensure that developer-accessible machines exist.
> 

This requirement can be satisfied by stating that some one must be
willing to support debian.org machine(s) of that architecture.

> * the Release Team can veto the architecture's inclusion if they have
>   overwhelming concerns regarding the architecture's impact on the
>   release quality or the release cycle length
> 
> A get out clause - it must be possible for something to be refused if it
> would break the release, even if it meets all the other criteria.
> 

This is unacceptable. It would for example allow archs to be refused
because their names starts with an 'A'.

> * there must be a developer-accessible debian.org machine for the
>   architecture.
> 
> Developers must be able to test their code on a machine running that 
> architecture.
> 
> 
> The Vancouver proposals satisfy all of these, potentially at the cost of
> removing some architectures from the set released by Debian. If we want
> to avoid that cost, can we come up with another proposal that solves the
> same problems in a way that satisfies the release team? 

Yes. See above. Most problems can be solved by other means then just
throwing out lots of people's work. Some are actually not a problem but
are probably invented to articifially limit the amount of archs.

Cheers,

Peter (p2).


signature.asc
Description: Digital signature

Re: The 98% and N<=2 criteria

[Peter 'p2' De Schrijver]

> 

Because it should not be reason to throw out an entire architecture. Ie.
if the package can not be compiled on $arch and the toolchain can not be
fixed in time, then release $arch without the package instead of
throwing out the whole arch.

Cheers,

Peter (p2).


signature.asc
Description: Digital signature

Re: Required firewall support

[Thomas Bushnell BSG]

Joel Aelwyn <[EMAIL PROTECTED]> writes:

> Either someone
> cares enough to write (or adapt) the management tools and it gets included,
> or they don't and it doesn't because nobody in their right mind would
> deploy it in any widespread fashion.

But the latter is already true, and irrelevant.


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

Re: The 98% and N<=2 criteria

[Andreas Barth]

* Peter 'p2' De Schrijver ([EMAIL PROTECTED]) [050321 22:30]:
> Because it should not be reason to throw out an entire architecture. Ie.
> if the package can not be compiled on $arch and the toolchain can not be
> fixed in time, then release $arch without the package instead of
> throwing out the whole arch.

That has happened, but that are not the really bad problems with the
toolchain. The really bad problems is if e.g. a class of packages starts
to fail to build from source. Or some new required kernel version forces
all to upgrade some autoconf-scripts.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: The 98% and N<=2 criteria

[Peter 'p2' De Schrijver]

> That has happened, but that are not the really bad problems with the
> toolchain. The really bad problems is if e.g. a class of packages starts
> to fail to build from source. Or some new required kernel version forces
> all to upgrade some autoconf-scripts.
> 

Both problems are easy to solve compared to hitting an obscure
toolchain bug.

Cheers,

Peter (p2).


signature.asc
Description: Digital signature

Re: [RFC] OpenLDAP automatic upgrade

[Torsten Landschoff]

Hi Quanah, 

On Thu, Mar 17, 2005 at 03:39:09PM -0800, Quanah Gibson-Mount wrote:
> > Is there a way to enforce this without editing DB_CONFIG? I'd rather set
> > an environment variable or something like that. Writing that into
> > DB_CONFIG in the maintainer scripts always poses the risk that it'll
> > stay.
> 
> Well This will be available in OpenLDAP 2.3 via the "-q" option to
> slapadd.  I have my own backported patch to OpenLDAP 2.2 that enables the
> "-q" option.

Care to share that patch? :)

Greetings

Torsten


signature.asc
Description: Digital signature

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Andreas Barth]

* Wouter Verhelst ([EMAIL PROTECTED]) [050321 00:25]:
> On Thu, Mar 17, 2005 at 10:40:43AM +0100, Andreas Barth wrote:
> > If we don't wait for an arch, it gets out-of-sync quite soon, and due to
> > e.g. legal requirements, we can't release that arch. (In other words, if
> > an arch is too long ignored for testing, we should remove it, as we
> > can't release it in any case.)

> Is that statement based on experience of current behaviour, or rather on
> expected behaviour?

It's based on experience.

> (Currently, architectures only get ignored if they're lagging behind
> anyway, so then the above statement is obviously true. When
> architectures are being ignored for other reasons, the above isn't as
> obvious anymore)

It's probably true that an arch that is always ignored doesn't get out
of sync as bad as an ignored arch now. However, every arch is sometimes
a bit out-of-sync on one or another package, and I doubt that it will
really work. But well, of course this could be tried out if it seems to
be the best solution.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: my thoughts on the Vancouver Prospectus

[Wouter Verhelst]

On Fri, Mar 18, 2005 at 06:44:46PM -0800, Steve Langasek wrote:
> On Mon, Mar 14, 2005 at 10:48:10PM -0500, Branden Robinson wrote:
> > The next stage in the process is to actually sell the proposed changes for
> > etch to the developers at large[2].  There are several points which can and
> > should be discussed; I myself am not certain what the motivations for some
> > criteria are, and it would be good to have those documented so that we can
> > tell if an when they no longer apply.
> 
> > Let me offer some examples:
> 
> > * Why is the permitted number of buildds for an architecture restricted to
> >   2 or 3?
> 
> - Architectures which need more than 2 buildds to keep up with package
>   uploads on an ongoing basis are very slow indeed; while slower,
>   low-powered chips are indeed useful in certain applications, they are
>   a) unlikely to be able to usefully run much of the software we currently
>   expect our ports to build,

Please leave it to our users to define what is useful.

>   and b) definitely too slow in terms of
>   single-package build times to avoid inevitably delaying high-priority
>   package fixes for RC bugs.

I would not have any problem with multi-staged security announcements,
for example.

> - If an architecture requires more than 3 buildds to be on-line to keep up
>   with packages, we are accordingly spreading thin our trust network for
>   binary packages.  I'm sure I'll get flamed for even mentioning it, but
>   one concrete example of this is that the m68k port, today, is partially
>   dependent on build daemons maintained by individuals who have chosen not
>   to go through Debian's New Maintainer process.

This is absolutely not the case. It is true that some of our buildd
machines have a local admin that are not developers or at least in NM;
but
* That is equally true for the buildd hosts of some of the other
  architectures (e.g., s390, or sparc)
* Nobody has ever been offered to maintain a buildd host who was not at
  least in NM. I did train Matthias Ulrichs and Goswin von Brederlow
  when they were, but Goswin's machines were disconnected from w-b even
  before he was rejected. I'm also quite sure today I won't do that
  again, precisely because Goswin was rejected and I don't want to think
  of what might've happened had he been able to upload trojanized
  binaries (not that I think he would have done so).

I'm interested in what your base for the above assertion is.

>   Whether or not these
>   particular individuals should be trusted, the truth is that when you have
>   to have 10 buildds running to keep up with unstable, it's very difficult
>   to get a big-picture view of the security of your binary uploads.
>   Security is only as strong as the weakest link.

True; but these concerns can be better addressed by spelling out some
security requirements (and somehow ensuring they are being followed)
rather than imposing some random, unrelated, limit to the number of
hosts in use.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: How to define a release architecture

[Henrique de Moraes Holschuh]

On Mon, 21 Mar 2005, Peter 'p2' De Schrijver wrote:
> > * the release architecture must be publicly available to buy new
> > 
> > Avoids a situation where Debian is keeping an architecture alive. This
> > isn't intended to result in an architecture being dropped part way
> > through a release cycle or once it becomes hard to obtain new hardware.
> 
> What problem does this rule solve ?

IMHO, if one cannot buy one new, it is a mostly stale architecture that is
taking effort from the post-release teams (security, release manager,
DSA...).  This is *not* an acceptable criteria for not-to-be-released(-yet)?
arches ("scc"), but it certainly makes a lot of sense for release ones.

If Debian is keeping an arch alive so much that one can still buy it new, I
certainly can't see why we should not continue releasing for that arch,
however.  So I'd say Matthew's explanation is not perfect.  But the
reasoning behind it is not difficult to spot.

Throwing out this requirement makes sense, if and only if there is another
way to get sure a released arch will not be left stranded.  So, let's work
on these alternate ways, so that this rule can be removed.

> > * the release architecture must have N+1 buildds where N is the number
> >   required to keep up with the volume of uploaded packages
> > 
> > This is to ensure that all unstable packages are built in a timely
> > manner, and that there is adequate redundancy to prevent a single buildd
> > failure from delaying packages.
> > 
> > * the value of N above must not be > 2
> > 
> > This effectively sets an upper limit on the length of time a single
> > package may take to build, which helps ensure that doing things like
> > security fixes for Openoffice doesn't become a problem.
> > 
> 
> A far more acceptable alternative would be to not have openoffice on those 
> archs.

IMHO you are quite right.  If we can agree on that one, we should make it so
that packages that are effectively blocked from an arch count as an
arch-specific (of another arch) for that arch. I.e., they do not lower the
number-of-packages-built rating.  So, they do not bother that arch at all.

Add a hard limit that at least the entire set of non-arch-specific standard,
required and essential packages have to be supported (or a minimum of 90% of
them, maybe?), plus at least 50% of optional and 50% of extra (again,
non-arch-specific) to avoid abuse, and that would do it.

DO note that we could also decide to accept that a buildd is something that
has the latencies of a [fast enough] single unit, so, e.g., a distcc farm
would count as one buildd.  Makes a lot of sense to me, since it addresses
the latency problem...  but you WOULD need N+1 *farms* in different
locations, etc. to address the reliability problem.

Let the porter teams release an *official* list of not-for-us packages for
their arch, which get permanently excluded from that arch's release, and
does not cause any sort of problems *at* *all* for the maintainer of said
packages (such as annoying problems with the testing scripts if the arch
drops the package after it had made it to testing for that arch), and I
don't see how that could be a bad thing.

> > packages are held back from testing by an architecture not being able to
> > build them. 
>
> In which case those packages can simply be not available for the
> architecture in question.

Yes, IMHO.  This would take care of it, as long as we have the proper
infrastructure in place to make it easy to manage.

> > * the Security Team must be willing to provide long-term support for
> >   the architecture
> > 
> > All releases require security updates, again for obvious reasons.
> 
> This requirement can be satisfied by stating that some one must be
> willing to support the security team.

No.  This requirement can be satisfied by having someone IN THE SECURITY
team willing to support the arch.  There are various ways to make sure the
security team is willing to support one arch, and I believe the most
effective one is to get your hands dirty and go help them like crazy right
now, so that they trust they will have help for that arch should they need
it.

I'd suppose a damn good way to start is to make sure there are at least two
porters of every arch (and I *do* count i386, amd64, powerpc and other
popular arches here) *active* in the testing security team.

> > * the Debian System Administrators (DSA) must be willing to support
> >   debian.org machine(s) of that architecture
> > 
> > This is in order to ensure that developer-accessible machines exist.
> 
> This requirement can be satisfied by stating that some one must be
> willing to support debian.org machine(s) of that architecture.

My guess is that it would need to be a machine under the DSA control to make
sure the security team and stable maintainership is never left out in the
cold.

Is this actually a problem for any current arch (either released or not)?

> > * the Release Team can veto the architecture's inclusion if they have
> >  

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Mike Fedyk]

Andreas Barth wrote:
* Wouter Verhelst ([EMAIL PROTECTED]) [050321 00:25]:
 

On Thu, Mar 17, 2005 at 10:40:43AM +0100, Andreas Barth wrote:
   

If we don't wait for an arch, it gets out-of-sync quite soon, and due to
e.g. legal requirements, we can't release that arch. (In other words, if
an arch is too long ignored for testing, we should remove it, as we
can't release it in any case.)
 

Why not include diffs of the source for the arches that required porting 
before the packages would compile and work properly for that arch to 
comply with this legal requirement?  This would allow for Tier2 arches 
to be released with a later point release or some other schedule.

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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Wouter Verhelst]

On Tue, Mar 22, 2005 at 02:04:35AM +1000, Anthony Towns wrote:
> Wouter Verhelst wrote:
> >Joey Schulze has already said that doing security support for two
> >architectures is exactly as hard as doing security support for twenty
> >architectures, so the point about supporting stable is kindof moot. The
> >same isn't true for testing, obviously.
> 
> Joey gets to say this because others have done all the work to handle 
> that support for him and the security team.

Yes, which is why I said "kindof" and "the same isn't true for testing".

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: Emulated buildds (for SCC architectures)?

[Tollef Fog Heen]

* Riku Voipio 

| Incidentally the first problem should be solvable with the multiarch
| proposal, and the toolchains need to be polished anyway.

The multiarch proposals out there deal with how to run binaries for
multiple architectures, not how to cross-build.  That's one of the
roads which would be interesting to explore more, but it's not a high
priority ATM.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Re: The 98% and N<=2 criteria (was: Vancouver meeting - clarifications)

[Wouter Verhelst]

On Mon, Mar 21, 2005 at 06:15:11PM +0100, Peter 'p2' De Schrijver wrote:
> 
> > A QA measure for kernel/toolchain issues, sure. Many compiler bugs are
> > identified by compiling 10G worth of software for an architecture;
> > perhaps we should have a better way of tracking these, but it surely is
> > a class of problems that /cannot/ be identified by just building on the
> > big N architectures.
> > 
> 
> Indeed. Some of the issues I think of right now :
> 
> - wrong assumptions on sizeof base types 
> - unaligned accesses
> - dependency on stack growth direction

Unless you mean stuff like this happening in the compiler, I don't think
we're talking about the same thing.

What I mean are the cases where the compiler barfs "Internal Compiler
Error in foo, please submit a full bug report, (...)" and exits, such as
in


-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature