Re: automake/autoconf in build-dependencies

[Paul Hampson]

On Mon, Mar 14, 2005 at 01:18:12AM -0500, Kurt B. Kaiser wrote:
> Machine generated files (e.g. configure) constructed by autotools
> should not be in CVS.

> However, these files (as generated by the Debian maintainer's autotools
> run before the upload) should be included in the source package via the
> .diff.gz. so that the user doesn't need autotools.

> Therefore, the Debian maintainer should run autotools using current
> config.{sub,guess} before the diff.gz file is generated, possibly via
> an 'autogen.sh' script.

I think you got this last big backwards. config.{sub,guess} are used by
the configure script, not autoconf. So you can run autoconf at
package-source creation-time, and still gain the benefits of current
config.{sub,guess} at package (re)build-time. In fact, I believe that
was the original motivation for autotools-dev, since config.{sub,guess}
needed to be updated due to the fluidity of some ports (I think the
mips, sh and BSD ports were/are the most common "FTBFS: Update
config.{sub,guess}", but I could be wrong.)

-- 
---
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: Bug#299242: ITP: ha-prosper -- improved LaTeX class for writing transparencies

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> schrieb:

> Le dimanche 13 mars 2005 à 23:10 +0100, Michael Prokop a écrit :
>
>> And TeXciting might never be released, quoting Hendri - the author
>> of ha-prosper:
>> 
>> | I have reconsidered whether it will be possible
>> | to finish this project. Taking into account also
>> | the work that I'm doing on other packages and
>> | my involvement in LaTeX3, I conclude that it will
>> | unfortunately be very unlikely, that I will ever
>> | finish that project.
>> 
>> See his posting on ha-prosper-mailinglist for more details:
>> http://listserv.surfnet.nl/scripts/wa.exe?A2=ind0503&L=ha-prosper&F=&S=&P=777
>> 
>> So in my opinion it would be useful to provide a debian package of
>> ha-prosper.
>
> If TeXciting isn't likely to be released soon, that makes the point of
> making a separate package from prosper moot, doesn't it?

One way or the other, the old prosper style files should be available in
Debian, be it because ha-propser has its own package, or because both
prosper and ha-prosper can be shipped in one updated package.  None of
them is in teTeX in sarge, nor in teTeX-3.0.

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

Bug#299446: RFH: vim -- Vi IMproved - enhanced vi editor

[Norbert Tretkowski]

Package: wnpp
Severity: normal

I'm looking for someone who wants to co-maintain vim, since I realized
that I'm currently unable to take care of the package alone. There are
a lot of open bugs that should be fixed, and there's also the upcoming
vim 7.0 package which is a complete rewrite of the packaging. It
should be easy to work on the package together, there's a project on
alioth using subversion already.

Drop me a mail if you're interested.

The package description is:
 Vim is an almost compatible version of the UNIX editor Vi.  Many new
 features have been added: multi level undo, syntax highlighting,
 command line history, on-line help, filename completion, block operations,
 folding, Unicode support, etc.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-1-686
Locale: LANG=POSIX, LC_CTYPE=de_DE (charmap=ISO-8859-1)


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

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

[Adrian von Bidder]

On Monday 14 March 2005 05.45, Steve Langasek wrote:
> Architectures that are no longer being considered for stable releases
> are not going to be left out in the cold. ÂThe SCC infrastructure is
> intended as a long-term option for these other architectures, and the
> ftpmasters also intend to provide porter teams with the option of
> releasing periodic (or not-so-periodic) per-architecture snapshots of
> unstable.

[I'm a pure x86 user atm, so if this is a non-issue, I'll gladly be 
educated]

Why only unstable?  In other words: will it be possible for scc arches to 
have a testing distribution?  Obviously, this testing/arch will not 
influence the release candidate arch testing, but will allow real releases 
of scc-arches if a RM/release team steps up.

cheers
-- vbi

-- 
Available for key signing in ZÃrich and Basel, Switzerland
(what's this? Look at http://fortytwo.ch/gpg/intro)


pgpw3p1LcGLkZ.pgp
Description: PGP signature

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

[Steve Langasek]

On Sun, Mar 13, 2005 at 11:36:39PM +0100, Wouter Verhelst wrote:
> Op vr, 11-03-2005 te 19:14 -0800, schreef Steve Langasek:
> > The queue ordering is entirely automatic, and AIUI the queue(s) is (are)
> > sorted by:

> > - target suite
>- previous compilation state (already built packages are prioritized
> above packages never built for the target architecture)

Yep, remembered that one after I sent the message.

> >   - package priority
> > - package section
> >   - package name

> > I personally believe it would be beneficial to prioritize by upload urgency
> > as well (probably as a sort criterion between package priority and package
> > section), but the w-b maintainers disagree.

> I agree with the w-b maintainers. The queue order is only interesting in
> the case where there is a backlog; in other cases, packages are usually
> built rather fast. In the case where there is a backlog, those trying to
> fix the architecture (usually those that are working on it) should be in
> charge of deciding what package gets built first, not the maintainer of
> a random package -- /all/ package builds are urgent if there's a
> backlog.

Well, my objection is basically the same as Thomas's here -- all package
builds are *not* equally urgent, and in fact, we have an "urgency" field
in uploads that expresses this fact quite clearly.  Certainly there's
some danger of abuse by uploaders, but there are dozens of other things
that maintainers *could* abuse right now and are only stopped from doing
because they *shouldn't* do them.

I wouldn't be bothered by porters choosing how to order builds, if the
ordering they chose more closely corresponded to what the release team
(and britney) want it to be. :)

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

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

[Lionel Elie Mamane]

On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:

> Therefore, we're planning on not releasing most of the minor architectures
> starting with etch.

> Architectures that are no longer being considered for stable
> releases are not going to be left out in the cold.  The SCC
> infrastructure is intended as a long-term option for these other
> architectures, and the ftpmasters also intend to provide porter
> teams with the option of releasing periodic (or not-so-periodic)
> per-architecture snapshots of unstable.

Why don't we give non-release architectures a per-arch testing?

-- 
Lionel


signature.asc
Description: Digital signature

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

[Steve Langasek]

On Sun, Mar 13, 2005 at 11:21:29PM -0800, Thomas Bushnell BSG wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:

> > On Sun, Mar 13, 2005 at 10:47:15PM -0800, Thomas Bushnell BSG wrote:
> > > Steve Langasek <[EMAIL PROTECTED]> writes:

> > > > The sh and hurd-i386 ports don't currently meet the SCC requirements, as
> > > > neither has a running autobuilder or is keeping up with new packages.

> > > It is impossible for any port under development to meet the SCC
> > > requirements.  We need a place for such ports.  Where will it be?

> > On the contrary, the amd64 port does, and is currently maintained
> > completely outside official debian.org infrastructure.

> The amd64 port did not always.  Ports under development take time; the
> amb64 port is at a late state in its development.  I don't understand
> why autobuilding is important to SCC; maybe if you could explain that
> I would understand.

The point is that the ftpmasters don't want to play host to various
ports that *aren't* yet matured to the point of usability, where "being
able to run a buildd" is regarded as a key element of usability in the
port bootstrapping process.  The amd64 team have certainly shown that
it's possible to get to that point without being distributed from the
main debian.org mirror network.

I don't know if the ftpmasters have any specific plans to drop
hurd-i386, if that's what you're asking, I was just pointing out that
the hurd port doesn't presently meet the stated requirements.  If
anything, though, having a port that's not actively keeping up with
unstable is *worse* that having a port that just hasn't built anything,
because it bloats the size of the archive with stale sources that have
to be kept around as long as the binary packages are.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

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

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> The point is that the ftpmasters don't want to play host to various
> ports that *aren't* yet matured to the point of usability, where "being
> able to run a buildd" is regarded as a key element of usability in the
> port bootstrapping process.  The amd64 team have certainly shown that
> it's possible to get to that point without being distributed from the
> main debian.org mirror network.

Speaking of the mirror network is a red-herring.  Mirrors are not
forced to distribute every arch; they can and should eliminate archs
they aren't interested in distributing.

> I don't know if the ftpmasters have any specific plans to drop
> hurd-i386, if that's what you're asking, I was just pointing out that
> the hurd port doesn't presently meet the stated requirements.  If
> anything, though, having a port that's not actively keeping up with
> unstable is *worse* that having a port that just hasn't built anything,
> because it bloats the size of the archive with stale sources that have
> to be kept around as long as the binary packages are.

That's a different issue.  There are two reasons a package might not
be built: because there is no autobuilder and it hasn't been rebuilt
by hand, or because it's never been built for the arch.

In the latter case, which is by far the normal one for ports like
hurd-i386, there is no need to keep old sources around.

It would be valuable here for us all to have some hard statistics
rather than operating from guesswork about it, however.  Just how much
bloat *are* we talking about?  

Thomas


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

Re: Key management using a USB key

[Matthias Urlichs]

Hi, David HÃrdeman wrote:

> o gpg-agent support in the same manner as ssh-agent would be neat. I 
>   understand that this requires gnupg 2.0 though.

While gpg-agent is built from the gnupg 2.0 sources (a development
snapshot of which is currently sitting in the NEW queue ...), the agent
itself is perfectly useable with gnupg 1.2.

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

[Romain Francoise]

Steve Langasek <[EMAIL PROTECTED]> writes:

> The following people in Debian leadership roles have also expressed
> their support:

>   Andreas Schuldei (DPL candidate)
>   Angus Lees (DPL candidate)
>   Branden Robinson (DPL candidate)
>   Jonathan Walther (DPL candidate)

How exactly is DPL candidate a leadership role?  I can understand that
the aforementioned people are under the spotlights right now because of
the election, but it does not qualify as leadership.

Also, our current DPL isn't listed in the supporters of this plan, does
it mean that he wasn't consulted?  Or does it mean that he was
consulted, but disagreed?  If so, may I ask why?

Joey Schulze, our most active Security Officer, is also missing from the
list.  Same questions.

Thanks,

-- 
  ,''`.
 : :' :Romain Francoise <[EMAIL PROTECTED]>
 `. `' http://people.debian.org/~rfrancoise/
   `-


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

Re: Restrictive SMTP server

[Tollef Fog Heen]

* Matthew Palmer 

| I'm willing to provide an OpenVPN tunnel to an SMTP server for any
| DD who is unable to find alternate lodgings, and I'm pretty sure I'm
| not the only one.

http://freerelay.err.no/

-- 
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: Do not make gratuitous source uploads just to provoke the buildds!

[Bastian Blank]

On Mon, Mar 14, 2005 at 11:43:54AM +1100, Hamish Moffatt wrote:
> s390 is also rising steeply.

gcc problems and non-responding ftp-masters for the new buildd.

Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown


signature.asc
Description: Digital signature

Re: automake/autoconf in build-dependencies

[Tollef Fog Heen]

* Henning Makholm 

| When I provide a configure script in the source package it means, on
| the contrary, that I *have* tried it and therefore has some kind of
| evidence that it will probably work for other people too.

You have probably only tried it on one architecture.

A lot of the bugs I see as a porter are of the type «something in
$foo's configure script didn't pick up $bar, which breaks
spectacularly somewhere later».  Stuff like #175491 which made
evolution(!) with a SIGFPE before main or _init.

To a certain degree, those would have been fixed if people
build-depended on auto*, as they would have picked up fixed versions
of the .m4 files.

-- 
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: Not every package should enter Debian (was: Re: Who cares about NEW when there are bigger issues? (was Re: Is NEW processing on hold? (was: Question for candidate Towns)))

[Matthias Urlichs]

Hi, Adrian von Bidder wrote:

> In that light, fully automatic NEW processing will not hurt at all

Umm...
- Submit package with copyrighted stuff
- wait a few days
- watch the pants being sued off SPI/Debian

Likely? I don't know. Too dangerous? IMHO yes.

That being said, sources which just sprout new binary packages really
should be passed through NEW automagically.

-- 
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: Is Anthony Fok MIA?

[Jan Nieuwenhuizen]

Thomas Bushnell writes:

[fixed lilypond list address: not snipping]
>> > We are a bit concerned with old LilyPond packages, and a potential
>> > new maintainer (Pedro Kroger) with his sponsor going mia.
>> 
>> Who was going to sponsor him?
>
> I use lilypond all the time, so I'm happy to adopt it if necessary.
> I'm a bad mentor/sponsor however.

Thanks for the offer!  I'm not sure however how adopting a package
works, I guess you'll have to sort with Anthony and  Pedro.

Pedro has been preparing unofficial packages of the stable and
development branches (lilypond/lilypond-snapshot) for sid/sarge,

http://www.pedrokroeger.net/lilypond/lilypond.html

it would be great to have up to date lilypond packages in Debian, once
again.

Jan.

-- 
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien   | http://www.lilypond.org


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

Re: buildd queue starvation (Was: Re: Do not make gratuitous source uploads just to provoke the buildds!)

[Wouter Verhelst]

On Sun, Mar 13, 2005 at 11:07:29PM -0800, Thomas Bushnell BSG wrote:
> Wouter Verhelst <[EMAIL PROTECTED]> writes:
> 
> > None of the documentation calls it a 'queue', in fact; only people not
> > really involved in buildd stuff do.
> 
> Does that include you?  In two recent messages, you referred to it as
> a queue.

Yes, that's correct; I shouldn't have. Sorry :-)

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

[Sven Luther]

On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:
> The much larger consequence of this meeting, however, has been the
> crafting of a prospective release plan for etch.  The release team and
> the ftpmasters are mutually agreed that it is not sustainable to
> continue making coordinated releases for as many architectures as sarge
> currently contains, let alone for as many new proposed architectures as
> are waiting in the wings.  The reality is that keeping eleven
> architectures in a releasable state has been a major source of work for
> the release team, the d-i team, and the kernel team over the past year;
> not to mention the time spent by the DSA/buildd admins and the security
> team.  It's also not clear how much benefit there is from doing stable
> releases for all of these architectures, because they aren't necessarily
> useful to the communities surrounding those ports.

Will minutes of the meeting be made available ? This is a rather drastic step
to be taken, and it comes as rather a big surprise, so i believe that full
minutes of the meeting having taken that decision should be in order. I also
wonder about the absense of porter representative in said meeting and said
taking of decision, not mentioning the rest of the project. Speak about
communication and transparency.

I don't think this will be a good PR move though, we will probably see a
slashdot thread about "Debian dropping all architectures except the main 4" or
something such soon.

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

[Ingo Juergensmann]

On Mon, Mar 14, 2005 at 07:37:51AM +0100, Andreas Tille wrote:

> In general I would like to say that supporting a lot of architectures was
> an important difference between Debian and other distributions.  I know the

In fact it was one of the 2 main reasons for my choice. apt-get was the other
main reason. 

> drawbacks of this but I just do not want to hide my opinion that I do not
> like the idea of reducing the number of supported architectures that 
> drastical.
> IMHO the effect would be that people will start forking Debian for porting
> issues and we will loose the power of those porters while they will spend
> time for things they would not have to do else.

And the userbase will get smaller. It's not unlikey that I will power off
all non-supported archs then and migrate to another distribution that has
not those internal problems like Debian. And I think that I won't be the
only one.
IMHO scc.d.o will result in focussing on those archs, making it worse and
worse for the other archs. Implementing scc.d.o is equally to dropping those
older archs in my eyes. It's just another wording. 

> I think we should at least vote about such a drastic change.

A voting about total nonsense? I think we had that already with that SC
editorial changes vote last year, which showed that Debian is very good at
harming itself. 
And furthermore: the support of all those DPL candidates really saddens me. 
All the work and support over all those years by all those users and porters
will be vanished with that stupid idea, imho. 
It would be better when the project would be honest and state that it want
to become a x86-compatible only distribution (with the small tribute to
powerpc users) than this braindead thingie. 

Sorry for using "stupid", "braindead" and others. But there are no other
words for crap like this, imho. 

-- 
Ciao...  // 
  Ingo \X/


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

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

[Steve Langasek]

On Mon, Mar 14, 2005 at 09:09:09AM +0100, Adrian von Bidder wrote:
> On Monday 14 March 2005 05.45, Steve Langasek wrote:
> > Architectures that are no longer being considered for stable releases
> > are not going to be left out in the cold.  The SCC infrastructure is
> > intended as a long-term option for these other architectures, and the
> > ftpmasters also intend to provide porter teams with the option of
> > releasing periodic (or not-so-periodic) per-architecture snapshots of
> > unstable.

> [I'm a pure x86 user atm, so if this is a non-issue, I'll gladly be 
> educated]

> Why only unstable?  In other words: will it be possible for scc arches to 
> have a testing distribution?  Obviously, this testing/arch will not 
> influence the release candidate arch testing, but will allow real releases 
> of scc-arches if a RM/release team steps up.

(A popular question...)

There are a few problems with trying to run testing for architectures
that aren't being kept in sync.  First, if they're not being kept in
sync, it increases the number of matching source packages that we need
to keep around (which, as has been discussed, is already a problem);
second, if you want to update using the testing scripts, you either have
to run a separate copy of britney for each arch (time consuming,
resource-intensive) or continue processing it as part of the main
britney run (we already tread the line in terms of how many archs
britney can handle, and using a single britney check for archs that
aren't keeping up doesn't give very good results); and third, if
failures on non-release archs are not release-critical bugs (which
they're not), you don't have any sane measure of bugginess for britney
to use in deciding which packages to keep out.

For these reasons, I think the snapshotting approach is a better option,
because it puts the package selection choices directly in the hands of
the porters rather than trying to munge the existing testing scripts
into something that will make reasonable package selections for you.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

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

[Hamish Moffatt]

On Sun, Mar 13, 2005 at 08:15:13PM -0800, Thomas Bushnell BSG wrote:
> Hamish Moffatt <[EMAIL PROTECTED]> writes:
> 
> > Given how low hamradio (and the like) are prioritised, I suggest that we
> > get smarter about 'tesing' and omit some sections on some architectures.
> 
> I don't think those sections are causing the problem.  There are also
> not so many uploads for them.  The problem from my perspective is that

True, but that isn't making my electronics packages build any faster.

> "optional" packages all have to be built before any "extra" packages
> get considered.  That's what's hosing gnucash.

hamradio is only one notch above "extra" in the pecking order anyway.

I'm very pleased to hear this will be less important for etch anyway.

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


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

mplayer 1.0pre6a-4 for i386 and PowerPC and sparc

[A Mennucc]

you may find  source, i386 and powerpc and sparc binaries
of mplayer  1.0pre6a-4  in your friendly repository

http://tonelli.sns.it/pub/mplayer/sarge

with special thanks to  David Moreno Garza  for the sparc binary
and Simon McVittie for powerpc

a.

-- 
Andrea Mennucc
 "Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef"


signature.asc
Description: Digital signature

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

[Robert Millan]

On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:
> 
> To be eligible for inclusion in the archive at all, even in the
> (unstable-only) SCC archive, ftpmasters have specified the following
> architecture requirements:
> 
> [...]
> 
> - binary packages must be built from the unmodified Debian source
>   (required, among other reasons, for license compliance)

Is this a simple sanity requirement (i.e. no hacked crap being uploaded to the
archive), or does it imply that all packages in base (or base + build-essential)
need to be buildable from unmodified source?

> - the port must demonstrate that they have at least 50 users

How do you demonstrate that?  Via popularity-contest?

Thanks.

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'http://www.debian.org/ports/kfreebsd-gnu
  `-


-- 
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 14, 2005 at 12:23:12AM -0800, Steve Langasek wrote:
> On Sun, Mar 13, 2005 at 11:21:29PM -0800, Thomas Bushnell BSG wrote:
> > Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > > On Sun, Mar 13, 2005 at 10:47:15PM -0800, Thomas Bushnell BSG wrote:
> > > > Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > > > > The sh and hurd-i386 ports don't currently meet the SCC requirements, 
> > > > > as
> > > > > neither has a running autobuilder or is keeping up with new packages.
> 
> > > > It is impossible for any port under development to meet the SCC
> > > > requirements.  We need a place for such ports.  Where will it be?
> 
> > > On the contrary, the amd64 port does, and is currently maintained
> > > completely outside official debian.org infrastructure.
> 
> > The amd64 port did not always.  Ports under development take time; the
> > amb64 port is at a late state in its development.  I don't understand
> > why autobuilding is important to SCC; maybe if you could explain that
> > I would understand.
> 
> The point is that the ftpmasters don't want to play host to various
> ports that *aren't* yet matured to the point of usability, where "being
> able to run a buildd" is regarded as a key element of usability in the
> port bootstrapping process.  The amd64 team have certainly shown that
> it's possible to get to that point without being distributed from the
> main debian.org mirror network.

I don't really understand that point though, since the plan is to drop mirror
support for all minor arches, what does it cost to have a 3 level archive
support : 

  1) tier 1 arches, fully mirrored and released.

  2) tier 2 arches, mostly those that we are dropping, maybe mirrored from
  scc.debian.org in a secondary mirror network. (why not ftp.debian.org/scc
  though ?).

  3) tier 3 arches, or in development arches, available on
  ftp.debian.org/in-devel or something.

I don't see how having the in-devel arches be hosted on alioth instead on the
official debian ftp server would cause a problem.

Also, i don't understand why scc.debian.org is better than ftp.debian.org/scc,
really, ideally we could have /debian, /debian-scc, and /debian-devel or
something such. Is it really a physical problem fro ftp-master to held all
these roles ? What is it exactly that ftp-masters want to drop all these
arches for ? 

Mirrors could then chose to go with 1) only (most of them will), or also
mirror 2) and/or 3).

Friendly,

Sven Luther


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

[Hamish Moffatt]

On Mon, Mar 14, 2005 at 07:37:56AM +0100, Ingo Juergensmann wrote:
> On Mon, Mar 14, 2005 at 11:49:34AM +1100, Hamish Moffatt wrote:
> 
> > Given how low hamradio (and the like) are prioritised, I suggest that we
> > get smarter about 'tesing' and omit some sections on some architectures.
> > Frankly there are not likely to be any users for hamradio on s390, mips*
> > arm, or m68k. Nor electronics. Instead those architectures just prevent
> > the migration to testing for those packages, for no good reason.
> 
> How can archs prevent the migration when the software is already uptodate,
> f.e. ax25-tools?
> http://unstable.buildd.net/cgi/package_status?unstable_all_pkg=ax25-tools&searchtype=go

Yes. So I haven't uploaded any of those lately. I have one ready but
don't want to confuse the issue for sarge.

How about geda-gschem? Waiting on arm for a couple of weeks now.
Holding up migration of all of geda* on all architectures.

I couldn't work out where wanna-build CVS is hosted so I couldn't
actually check the order to see where electronics fits in.

> Instead of considering dropping archs or excluding archs from building, you
> should consider improving the buildd process. The current wanna-build is
> known to have many drawbacks. It's an ancient program that doesn't fit any
> longer on todays needs. Patching it to death doesn't help much, imho. 

But right now, arm (for example) just cannot build all the packages that
need building. Changing the order won't help. Only adding machines or
removing packages will help.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[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

[Tollef Fog Heen]

* Steve Langasek 

| If you are planning any other transitions that will affect a lot of
| packages, please let us know in advance.  We will need to complete the
| larger transitions as fast as possible, to get testing back into a
| nearly releasable state quickly again after the release.

Multiarch.

-- 
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: Not every package should enter Debian

[Tollef Fog Heen]

* Matthias Urlichs 

| Hi, Adrian von Bidder wrote:
| 
| > In that light, fully automatic NEW processing will not hurt at all
| 
| Umm...
| - Submit package with copyrighted stuff
| - wait a few days
| - watch the pants being sued off SPI/Debian
| 
| Likely? I don't know. Too dangerous? IMHO yes.

More or less all the material in Debian is copyrighted, I think you
mean «proprietary, non-redistributable stuff»

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

[Steve Langasek]

On Mon, Mar 14, 2005 at 09:31:44AM +0100, Romain Francoise wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:

> > The following people in Debian leadership roles have also expressed
> > their support:

> >   Andreas Schuldei (DPL candidate)
> >   Angus Lees (DPL candidate)
> >   Branden Robinson (DPL candidate)
> >   Jonathan Walther (DPL candidate)

> How exactly is DPL candidate a leadership role?  I can understand that
> the aforementioned people are under the spotlights right now because of
> the election, but it does not qualify as leadership.

> Also, our current DPL isn't listed in the supporters of this plan, does
> it mean that he wasn't consulted?  Or does it mean that he was
> consulted, but disagreed?  If so, may I ask why?

Yes, we did consult Martin as well, and he had some concerns about the
proposal that prevented him from signing on to it as-is.  That's fine;
and many of those concerns are being discussed now in this thread.  I
felt a little silly listing the DPL candidates as supporting it without
also listing the current DPL, but we'd already asked the DPL candidates
about it before Martin got back to us, so I was bound to feel a little
silly either way. ;)

> Joey Schulze, our most active Security Officer, is also missing from the
> list.  Same questions.

I was a dumbass and forgot to send it to him for review like I was
supposed to (sorry, Joey!).  He was originally invited to join us in
Vancouver, but wasn't able to make it; I'm still very much interested in
knowing what his thoughts are on this idea.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

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

[Sven Luther]

On Sun, Mar 13, 2005 at 11:36:47PM -0800, Steve Langasek wrote:
> For the specific case of sparc, it's worth noting that this architecture
> was tied for last place (with arm) in terms of getting the ABI-changing
> security updates for the kernel; it took over 2 months to get all
> kernel-image packages updated for both 2.4 and 2.6 (which is a fairly
> realistic scenario, since woody also shipped with both 2.2 and 2.4),
> which is just way too unresponsive.  The call for sparc/arm kernel folks
> in the last release update was intended to address this; correct me if
> I'm wrong, but to my knowledge, no one else has stepped forward to help
> the kernel team manage the sparc kernels.

Notice that post-sarge, we will have one kernel-package only which will build
for all arches, like the ubuntu guys do, and that this problem with kernel
security updates may go away for all arches.

BTW, how much of the human intervention needed for buildd signing plays in the
delays you see, and did you discuss the possibiliity of a fully autobuilder
setup, like ubuntu does and i advocated years ago ? 

> Well, sparc is not in any danger of being dropped from SCC. :)  As I
> said, none of the current sarge candidate architectures are.

But there will be no stable scc release, if i understand the plane well ? Is
this really what you wanted or did i misunderstood ? What would be the problem
on adding scc stable release for later point releases ? We did that already in
the past if i remembed well.

> > In general I would like to say that supporting a lot of architectures was
> > an important difference between Debian and other distributions.  I know the
> > drawbacks of this but I just do not want to hide my opinion that I do not
> > like the idea of reducing the number of supported architectures that 
> > drastical.
> > IMHO the effect would be that people will start forking Debian for porting
> > issues and we will loose the power of those porters while they will spend
> > time for things they would not have to do else.
> 
> I certainly agree that portability is one of Debian's selling points,
> and I also have a "pet" architecture that doesn't appear to make the
> cut for etch; but I don't think it's a coincidence that the release
> cycle got longer when we doubled the arch count between potato and
> woody, and I *know* it's not a coincidence that we have a long release
> cycle for sarge while trying to wrangle those same 11 architectures.

He, and most of the DPL candidate just posted that they didn't believe the
release delay will drop if we drop arches. I also remember that ia64 was one
of the most problematic to autobuild the ocaml packages in august or so, and
it was worse off than m68k, mips or arm if i remember well.

Friendly,

Sven Luther


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

[Andreas Barth]

* Hamish Moffatt ([EMAIL PROTECTED]) [050314 01:45]:
> On Sun, Mar 13, 2005 at 11:16:56PM +0100, Andreas Barth wrote:
> > Our goal is that the queue gets empty from time to time, and so,
> > priority shouldn't prevent a package from being built.
> 
> How often should the queue be emptied, or when will an architecture be
> declarared not-keeping-up?

In light of
http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html
  the release architecture must have N+1 buildds where N is the number
  required to keep up with the volume of uploaded packages
at least once per day for etch.

> According to
> http://people.debian.org/~igloo/needs-build-graph/index.php?days=30
> arm hasn't been empty in over 3 weeks, and it's getting worse still.
> s390 is also rising steeply.

It is not only a question of days, but also, what expectations we have
for the architecture. If we e.g. know that in the next days a buildd
will be switched on again (as the buildd crashed, and the local admin is
away), we are of course a bit more tolerant. Also, vacations are
accepted.


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: Do not make gratuitous source uploads just to provoke the buildds!

[Andreas Barth]

* Hamish Moffatt ([EMAIL PROTECTED]) [050314 01:55]:
> On Mon, Mar 14, 2005 at 12:01:59AM +0100, Andreas Barth wrote:
> > It is a highly ordered list, more or less libs+base first, than devel, 
> > shells,
> > perl, python. After that graphics, admin, utils. Just to look at the
> > other side of the sorting order, at the end of the list is hamradio,
> > non-US and embedded. The large ones like gnome and kde are in the middle
> > of the list. Please see wanna-builds source for the full list.
 
> Given how low hamradio (and the like) are prioritised, I suggest that we
> get smarter about 'tesing' and omit some sections on some architectures.

We won't omit some sections on some architectures, but all sections on
some architectures :)


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

[Sven Luther]

On Mon, Mar 14, 2005 at 10:10:32AM +0100, Ingo Juergensmann wrote:
> On Mon, Mar 14, 2005 at 07:37:51AM +0100, Andreas Tille wrote:
> 
> > In general I would like to say that supporting a lot of architectures was
> > an important difference between Debian and other distributions.  I know the
> 
> In fact it was one of the 2 main reasons for my choice. apt-get was the other
> main reason. 
> 
> > drawbacks of this but I just do not want to hide my opinion that I do not
> > like the idea of reducing the number of supported architectures that 
> > drastical.
> > IMHO the effect would be that people will start forking Debian for porting
> > issues and we will loose the power of those porters while they will spend
> > time for things they would not have to do else.
> 
> And the userbase will get smaller. It's not unlikey that I will power off
> all non-supported archs then and migrate to another distribution that has
> not those internal problems like Debian. And I think that I won't be the
> only one.
> IMHO scc.d.o will result in focussing on those archs, making it worse and
> worse for the other archs. Implementing scc.d.o is equally to dropping those
> older archs in my eyes. It's just another wording. 

Notice, that there is really a unclarity of what the problem is, and the
wording of the announcement really didn't help on this.

If the main problem is the mirror network, i think it does make sense to drop
some arches from the mirror network. After all, ir could well be that for some
arches we have more mirrors than users, and a single, or smaller group of
mirrors for those arches could well be worth it. It could probably be done at
the DNS level that ftp..debian.org automagically points to the right
place and such, and should be transparent.

But again, i feel that the announcement was one thing, but that it lacks much
information about the reason which pushed the decision, and the individual
technical problems to be overcome. Are the minutes of the release-team meeting
publically available ? 

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

[Thijs Kinkhorst]

On Mon, March 14, 2005 10:10, Ingo Juergensmann said:
> It would be better when the project would be honest and state that it want
> to become a x86-compatible only distribution (with the small tribute to
> powerpc users) than this braindead thingie.

The problems associated with carrying many archs have been well
demonstrated. This proposal is a way to address these problems. If you
want to keep all archs as a part of the central architecture, you have to
come up with a way to tackle the given problems (and not just shout that
you want to keep them - just continuing without changing anything is not
realistic). If you disagree, please come up with an alternative plan
yourself (preferably a worked out plan like this one).

To me this decision sounds like a very good idea. Catering to some very
specialised architectures can be good, but should not be a great burden on
the total project. Trying to include everything in one big distribution is
inherently not working (as has been shown with sarge). It is very well
possible to maintain high quality ports of Debian, and infrastructure is
provided for that, without making the release dependant on it.

At the SquirrelMail project, we include things that are of general use
into the main distribution. Someone who requires something that's only of
interest to a very specific group can create and maintain that as a
plugin. That seems a very logical way to deal with specialtistic features,
and you see that approach in many different projects.


Regards,

Thijs Kinkhorst


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

[Ingo Juergensmann]

On Mon, Mar 14, 2005 at 08:50:15PM +1100, Hamish Moffatt wrote:

> How about geda-gschem? Waiting on arm for a couple of weeks now.
> Holding up migration of all of geda* on all architectures.
> I couldn't work out where wanna-build CVS is hosted so I couldn't
> actually check the order to see where electronics fits in.

Yes, it's not easy to find and sometimes it migrates from host to host
even... Maybe it's at newraff or at db.d.o?

> > Instead of considering dropping archs or excluding archs from building, you
> > should consider improving the buildd process. The current wanna-build is
> > known to have many drawbacks. It's an ancient program that doesn't fit any
> > longer on todays needs. Patching it to death doesn't help much, imho. 
> But right now, arm (for example) just cannot build all the packages that
> need building. Changing the order won't help. Only adding machines or
> removing packages will help.

Yes, adding machines will help, but this becomes a problem, when the
in-person union of wanna-build and buildd admin for that arch don't want you
to play in his Sandkasten... That's a human problem, not a hardware or arch
specific problem. 

-- 
Ciao...  // 
  Ingo \X/


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

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

[Rene Engelhard]

Hi,

Am Montag, 14. MÃrz 2005 08:36 schrieb Steve Langasek:
> wanna-build stats:
>   i386: 99.83% up-to-date,  99.83% if also counting uploaded pkgs
>   ia64: 97.39% up-to-date,  97.41% if also counting uploaded pkgs
>   powerpc:  97.99% up-to-date,  98.00% if also counting uploaded pkgs
>
> [curious that ia64 is lower than some others right now -- when we looked
> last week, it was above 98%, so maybe etch would have a *different* 4
> architectures. ;)]

where we see that two of the most important archs in that list (i386, ppc).

pcc is barely at 98%. I don't think that barrier should be that high. We 
*should* at last release with the tree most important archs: i386, amd64, 
powerpc.

Regards,

Rene
-- 
 .''`.  Renà Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73

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

[Aurélien Jarno]

Steve Langasek a écrit :
The much larger consequence of this meeting, however, has been the
crafting of a prospective release plan for etch.  The release team and
the ftpmasters are mutually agreed that it is not sustainable to
continue making coordinated releases for as many architectures as sarge
currently contains, let alone for as many new proposed architectures as
are waiting in the wings.  
Would it be possible to have a list of such proposed architectures?
This change has superseded the previous SCC (second-class citizen
architecture) plan that had already been proposed to reduce the amount of
data Debian mirrors are required to carry; prior to the release of sarge,
the ftpmasters plan to bring scc.debian.org on-line and begin making
non-release-candidate architectures available from scc.debian.org for
unstable.
If scc.debian.org is not mirrored, it would be possible to have much 
more place than now. Does it means that more architecture could be 
supported? I am thinking of the SH port that would need to separate
tree, if I remember correctly.

> Note that this plan makes no changes to the set of supported release
> architectures for sarge, but will take effect for testing and unstable
> immediately after sarge's release with the result that testing will
> contain a greatly reduced set of architectures, according to the
> following objective criteria:
I would add:
- there should be at least 2N buildd admins for this architecture. A lot 
of problems with buildds are caused by buildd admins unavailable at the 
same time for a given arch.

Architectures that are no longer being considered for stable releases
are not going to be left out in the cold.  The SCC infrastructure is
intended as a long-term option for these other architectures, and the
ftpmasters also intend to provide porter teams with the option of
releasing periodic (or not-so-periodic) per-architecture snapshots of
unstable.
My primary desktop machine is an i386, but it was sometimes ago and for 
a limited period of time and hppa machine, because my i386 had problems. 
It allowed me to continue my work on Debian packages. In the case this 
new infrastructure is set up, does upload from a SCC architecture to 
unstable would still be allowed? If no, source only upload must be 
allowed again.

- there must be a sufficient user base to justify inclusion on all
  mirrors, defined as 10% of downloads over a sampled set of mirrors
AFAIK, only i386 currently meet this criterion.
BTW, I am not sure this is really a good way to measure the use of an 
architecture, mainly because users could use a local mirror if they have 
a lot of machines of the same architecture. How about using popcon *in 
addition* to that?

To be eligible for inclusion in the archive at all, even in the
(unstable-only) SCC archive, ftpmasters have specified the following
What about experimental?
architecture requirements:
I would add as for the core set architecture:
- there must be a developer-accessible debian.org machine for the 
architecture.

This is important if you want the developers could fix bugs on their 
package for SCC architecture. This is currently not the case of the 
alpha port, and that sucks.

That let me raise a problem I see with such an infrastructure. Imagine 
an FTBFS on an SCC architecture (let's say arch X needs an autotools 
update). If it is not possible to have a high severity for this bug 
(because it is "only" an SCC arch) , I am almost sure that it would be 
ignored by a lot of developers. That would say that all SCC 
architectures will be quickly unusable...

These objective requirements would be applied both to the other eight
architectures being released with sarge that are not currently regarded
as candidates for release with etch, and also to any porter requests
asking for new architectures to be added to the archive.
This plan has been signed off on by:
  Steve Langasek (Release Manager)
  Colin Watson (Release Manager)
  Andreas Barth (Release Assistant)
  Joey Hess (Release Assistant)
  Frank Lichtenheld (Release Assistant)
  James Troup (ftpmaster)
  Ryan Murray (ftpmaster)
  Anthony Towns (ftpmaster)
I think that supporting a lot of architectures is an important 
difference between Debian and other distributions. Changing that could 
have a dramatically influence of what users think of Debian. IMHO, such 
an important decision should not be taken by a few developers. Maybe a 
vote is need...

Bye,
Aurelien
--
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian GNU/Linux developer | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net
--
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]

Sven Luther <[EMAIL PROTECTED]> writes:

> BTW, how much of the human intervention needed for buildd signing
> plays in the delays you see, and did you discuss the possibiliity of
> a fully autobuilder setup, like ubuntu does and i advocated years
> ago ?

I can't answer for Steve, but it seems to me that signing isn't the
problem.  There is not a big delay in getting packages signed; the
delay is much more frequently getting them actually built.

Where human delay did come into play was in getting the xfree86 mess
cleaned; in theory it should have taken one or two days, but in
practice it took much longer.


Thomas


-- 
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 14, 2005 at 01:14:47AM -0800, Steve Langasek wrote:
> On Mon, Mar 14, 2005 at 09:09:09AM +0100, Adrian von Bidder wrote:
> > On Monday 14 March 2005 05.45, Steve Langasek wrote:
> > > Architectures that are no longer being considered for stable releases
> > > are not going to be left out in the cold.  The SCC infrastructure is
> > > intended as a long-term option for these other architectures, and the
> > > ftpmasters also intend to provide porter teams with the option of
> > > releasing periodic (or not-so-periodic) per-architecture snapshots of
> > > unstable.
> 
> > [I'm a pure x86 user atm, so if this is a non-issue, I'll gladly be 
> > educated]
> 
> > Why only unstable?  In other words: will it be possible for scc arches to 
> > have a testing distribution?  Obviously, this testing/arch will not 
> > influence the release candidate arch testing, but will allow real releases 
> > of scc-arches if a RM/release team steps up.
> 
> (A popular question...)
> 
> There are a few problems with trying to run testing for architectures
> that aren't being kept in sync.  First, if they're not being kept in
> sync, it increases the number of matching source packages that we need
> to keep around (which, as has been discussed, is already a problem);
> second, if you want to update using the testing scripts, you either have
> to run a separate copy of britney for each arch (time consuming,
> resource-intensive) or continue processing it as part of the main
> britney run (we already tread the line in terms of how many archs
> britney can handle, and using a single britney check for archs that
> aren't keeping up doesn't give very good results); and third, if
> failures on non-release archs are not release-critical bugs (which
> they're not), you don't have any sane measure of bugginess for britney
> to use in deciding which packages to keep out.

What about building the scc (or tier 2 as i would say) arches from testing and
not unstable ? this way you would have the main benefit of testing (no RC
bugs, no breakage of the day kind of problems). Obviously this means you would
need some kind of override for per-arch fixes, but preferably these fixes will
be applied twice, once to the per-arch repo, and then to a new unstable upload
which fixes the problem. Uploading only to unstable may cause undue delays.

Ideally, all-source-packages-in-svn or whatever and
source-only-full-autobuilds would help greatly with this. Allowing to do a
branch of the repo to upload to the per-arch archive, and have the fix
automatically picked up by the next unstable release.

> For these reasons, I think the snapshotting approach is a better option,
> because it puts the package selection choices directly in the hands of
> the porters rather than trying to munge the existing testing scripts
> into something that will make reasonable package selections for you.

So, why don't you do snapshoting for testing ? Do you not think handling all
those thousands of packages manually without the automated testing thinhy
would be not an over-burden for those guys ? 

You are really just saying that the testing scipts don't scale well, and
instead of finding a solution to this, you say let's drop a bunch of 
architecture,
and make it another-one's problem.

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

[Andreas Barth]

* Robert Millan ([EMAIL PROTECTED]) [050314 10:50]:
> On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:
> > 
> > To be eligible for inclusion in the archive at all, even in the
> > (unstable-only) SCC archive, ftpmasters have specified the following
> > architecture requirements:
> > 
> > [...]
> > 
> > - binary packages must be built from the unmodified Debian source
> >   (required, among other reasons, for license compliance)

> Is this a simple sanity requirement (i.e. no hacked crap being uploaded to the
> archive), or does it imply that all packages in base (or base + 
> build-essential)
> need to be buildable from unmodified source?

This is a legal/DFSG requirement: We can't distribute binaries without source.


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: Is Anthony Fok MIA?

[Thomas Bushnell BSG]

Jan Nieuwenhuizen <[EMAIL PROTECTED]> writes:

> Thanks for the offer!  I'm not sure however how adopting a package
> works, I guess you'll have to sort with Anthony and  Pedro.

I know how to take care of the package.  But Anthony Fok is currently
the maintainer, so he needs to either orphan it or offer it for
adoption.  I can't speak about the question of making that happen; I'm
just saying that if it should be in that state, and then someone says
"will you please take this over", I will probably say "yes".  We
aren't at that point yet, however.

Thomas


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

Re: Not every package should enter Debian (was: Re: Who cares about NEW when there are bigger issues? (was Re: Is NEW processing on hold? (was: Question for candidate Towns)))

[Thomas Bushnell BSG]

Matthias Urlichs <[EMAIL PROTECTED]> writes:

> That being said, sources which just sprout new binary packages really
> should be passed through NEW automagically.

I made a foolish mistake not too long ago that would never have been
caught by this mechanism; I was most grateful for Anthony Towns
working with me to do it correctly.

Thomas


-- 
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 14, 2005 at 10:49:20AM +0100, Thijs Kinkhorst wrote:
> On Mon, March 14, 2005 10:10, Ingo Juergensmann said:
> > It would be better when the project would be honest and state that it want
> > to become a x86-compatible only distribution (with the small tribute to
> > powerpc users) than this braindead thingie.
> 
> The problems associated with carrying many archs have been well
> demonstrated. This proposal is a way to address these problems. If you
> want to keep all archs as a part of the central architecture, you have to
> come up with a way to tackle the given problems (and not just shout that
> you want to keep them - just continuing without changing anything is not
> realistic). If you disagree, please come up with an alternative plan
> yourself (preferably a worked out plan like this one).

The main problem with this proposal is that it vaguely hints at a couple of
technical details, hide the discussion that happened about it, and then lists
a huge list of strong remedies without analysing the detailed problems one by
one, and without stating what problems the remedy do aim to fix, thus making
help coming from porters and other third parties more difficult to focus.

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

[Martin Michlmayr]

* Aurélien Jarno <[EMAIL PROTECTED]> [2005-03-14 10:56]:
> Would it be possible to have a list of such proposed architectures?

amd64, s390z, powerpc64, netbsd-i386 and other variants, sh3/sh4, m32r
-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
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 14, 2005 at 01:59:02AM -0800, Steve Langasek wrote:
> On Mon, Mar 14, 2005 at 09:31:44AM +0100, Romain Francoise wrote:
> > Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > > The following people in Debian leadership roles have also expressed
> > > their support:
> 
> > >   Andreas Schuldei (DPL candidate)
> > >   Angus Lees (DPL candidate)
> > >   Branden Robinson (DPL candidate)
> > >   Jonathan Walther (DPL candidate)
> 
> > How exactly is DPL candidate a leadership role?  I can understand that
> > the aforementioned people are under the spotlights right now because of
> > the election, but it does not qualify as leadership.
> 
> > Also, our current DPL isn't listed in the supporters of this plan, does
> > it mean that he wasn't consulted?  Or does it mean that he was
> > consulted, but disagreed?  If so, may I ask why?
> 
> Yes, we did consult Martin as well, and he had some concerns about the
> proposal that prevented him from signing on to it as-is.  That's fine;
> and many of those concerns are being discussed now in this thread.  I
> felt a little silly listing the DPL candidates as supporting it without
> also listing the current DPL, but we'd already asked the DPL candidates
> about it before Martin got back to us, so I was bound to feel a little
> silly either way. ;)

And how do you reconcile the fact that most of those told us recently on
debian-vote that they believed that dropping an architecture will not help
with the delay of the release ? And giving the times of the posts, they
probably knew about this plan previously to replying that, especially those of
the scud team. Pure demagogy then ? 

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

[Sven Luther]

On Mon, Mar 14, 2005 at 10:39:24AM +0100, Robert Millan wrote:
> On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:
> > 
> > To be eligible for inclusion in the archive at all, even in the
> > (unstable-only) SCC archive, ftpmasters have specified the following
> > architecture requirements:
> > 
> > [...]
> > 
> > - binary packages must be built from the unmodified Debian source
> >   (required, among other reasons, for license compliance)
> 
> Is this a simple sanity requirement (i.e. no hacked crap being uploaded to the
> archive), or does it imply that all packages in base (or base + 
> build-essential)
> need to be buildable from unmodified source?
> 
> > - the port must demonstrate that they have at least 50 users
> 
> How do you demonstrate that?  Via popularity-contest?

But then, popularity-contest installation per default was dropped for
debian-installer rc3, so ...

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

[Andreas Barth]

* Tollef Fog Heen ([EMAIL PROTECTED]) [050314 10:55]:
> * Steve Langasek 
> 
> | If you are planning any other transitions that will affect a lot of
> | packages, please let us know in advance.  We will need to complete the
> | larger transitions as fast as possible, to get testing back into a
> | nearly releasable state quickly again after the release.

> Multiarch.

I have yet to see a proposal how to do multiarch in the right way.
This might be partly related to the fact that I don't follow all lists
around, but well - this needs to be done.

However, given the timeframe, I seriously doubt that we can do multiarch
in time for etch.

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: mplayer 1.0pre6a-4 for i386 and PowerPC and sparc

[Sven Luther]

On Mon, Mar 14, 2005 at 10:40:55AM +0100, A Mennucc wrote:
> you may find  source, i386 and powerpc and sparc binaries
> of mplayer  1.0pre6a-4  in your friendly repository
> 
> http://tonelli.sns.it/pub/mplayer/sarge
> 
> with special thanks to  David Moreno Garza  for the sparc binary
> and Simon McVittie for powerpc

BTW, what is the current status of inclusion of this in debian ? It seems that
even ubuntu now carries a mplayer binary, so there is really no reason at all
for not having one in debian. Especially as many of those who opposed mplayer
back then are now working for ubuntu.

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

[Sven Luther]

On Mon, Mar 14, 2005 at 02:12:48AM -0800, Thomas Bushnell BSG wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > BTW, how much of the human intervention needed for buildd signing
> > plays in the delays you see, and did you discuss the possibiliity of
> > a fully autobuilder setup, like ubuntu does and i advocated years
> > ago ?
> 
> I can't answer for Steve, but it seems to me that signing isn't the
> problem.  There is not a big delay in getting packages signed; the
> delay is much more frequently getting them actually built.

Well, i will disagree. It is only needed for the signer to go out to
vacations, and uploads break for a couple of days or weeks, which immediately
break builds of packages dependent on said packages, and cause delay in the
build queue, especially on slower arches. This is not theoretical, it happened
to me already in the past.

> Where human delay did come into play was in getting the xfree86 mess
> cleaned; in theory it should have taken one or two days, but in
> practice it took much longer.

Why not fully eliminate the human factor ? Ubuntu does automated build from
source only uploads, the package sources are built and signed by a developer,
autobuilt on all arches, and i don't believe they are individually signed
after that.

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

[Andreas Barth]

* Sven Luther ([EMAIL PROTECTED]) [050314 11:20]:
> On Mon, Mar 14, 2005 at 10:39:24AM +0100, Robert Millan wrote:
> > On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:
> > > - the port must demonstrate that they have at least 50 users

> > How do you demonstrate that?  Via popularity-contest?
 
> But then, popularity-contest installation per default was dropped for
> debian-installer rc3, so ...

We don't say "it needs 50 entries in popularity-contest", but just: 50
users. How this is demonstrated, may be different. Enough traffic on the
porter list might also be enough - or enough bug reports coming from
that arch. Or whatever. I don't expect that to be the blocking critieria
for any 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: mplayer 1.0pre6a-4 for i386 and PowerPC and sparc

[A Mennucc]

On Mon, Mar 14, 2005 at 11:09:27AM +0100, Sven Luther wrote:
> On Mon, Mar 14, 2005 at 10:40:55AM +0100, A Mennucc wrote:
> > you may find  source, i386 and powerpc and sparc binaries
> > of mplayer  1.0pre6a-4  in your friendly repository
> > 
> > http://tonelli.sns.it/pub/mplayer/sarge
> > 
> > with special thanks to  David Moreno Garza  for the sparc binary
> > and Simon McVittie for powerpc
> 
>BTW, what is the current status of inclusion of this in debian ? It seems that
> even ubuntu now carries a mplayer binary, so there is really no reason at all
> for not having one in debian. Especially as many of those who opposed mplayer
> back then are now working for ubuntu.


I am waiting from anybody in the ftp master team to say anything

(I would be happy even to hear them say 
"sorry we are too busy now, but we will look at the package in 3 weeks")

a. 

-- 
Andrea Mennucc
 "Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef"


signature.asc
Description: Digital signature

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

[Sven Luther]

On Mon, Mar 14, 2005 at 10:16:20AM +, Martin Michlmayr wrote:
> * Aurélien Jarno <[EMAIL PROTECTED]> [2005-03-14 10:56]:
> > Would it be possible to have a list of such proposed architectures?
> 
> amd64, s390z, powerpc64, netbsd-i386 and other variants, sh3/sh4, m32r

ppc64 is not currently a candidate for a separate arch, the path to go is a
biarch solution, much like the current amd64 solution in sarge, as word from
the main ppc64 developers is that a pure64 solution will be a measurable
performance hit on power (unlike amd64, which is saddled with a weaker
instruction set to start with).

One could add per-subarch optimized builds and mirrors too though. 

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

[Thomas Bushnell BSG]

Sven Luther <[EMAIL PROTECTED]> writes:

> > Where human delay did come into play was in getting the xfree86 mess
> > cleaned; in theory it should have taken one or two days, but in
> > practice it took much longer.
> 
> Why not fully eliminate the human factor ? Ubuntu does automated build from
> source only uploads, the package sources are built and signed by a developer,
> autobuilt on all arches, and i don't believe they are individually signed
> after that.

In this case, it was a bug that required human intervention, a package
upload that accidentally would hose a chroot, which required the
chroot to be repaired for each affected buildd.

Thomas


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

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

[Andreas Schuldei]

On Mon, Mar 14, 2005 at 11:05:16AM +0100, Sven Luther wrote:
> And how do you reconcile the fact that most of those told us recently on
> debian-vote that they believed that dropping an architecture will not help
> with the delay of the release ? And giving the times of the posts, they
> probably knew about this plan previously to replying that, especially those of
> the scud team. Pure demagogy then ? 

To my best knowledge Branden did not know about the proposal at
the time of the LWN interview. So from him it was no demagogy but
his own honest, private oppinion. I and AJ knew about it since we
were involved in the meeting. We both sidestepped the question
since the proposal was still not ready at that time.

btw: the results of that interview were not posted to -vote.


-- 
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 14, 2005 at 11:26:07AM +0100, Andreas Barth wrote:
> * Sven Luther ([EMAIL PROTECTED]) [050314 11:20]:
> > On Mon, Mar 14, 2005 at 10:39:24AM +0100, Robert Millan wrote:
> > > On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:
> > > > - the port must demonstrate that they have at least 50 users
> 
> > > How do you demonstrate that?  Via popularity-contest?
>  
> > But then, popularity-contest installation per default was dropped for
> > debian-installer rc3, so ...
> 
> We don't say "it needs 50 entries in popularity-contest", but just: 50
> users. How this is demonstrated, may be different. Enough traffic on the
> porter list might also be enough - or enough bug reports coming from
> that arch. Or whatever. I don't expect that to be the blocking critieria
> for any arch.

Well, but wouldn't reenabling the popularity-contest by default for sarge help
a lot on that ? 

Friendly,

Sven Luther


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

Re: mplayer 1.0pre6a-4 for i386 and PowerPC and sparc

[Sven Luther]

On Mon, Mar 14, 2005 at 11:26:27AM +0100, A Mennucc wrote:
> On Mon, Mar 14, 2005 at 11:09:27AM +0100, Sven Luther wrote:
> > On Mon, Mar 14, 2005 at 10:40:55AM +0100, A Mennucc wrote:
> > > you may find  source, i386 and powerpc and sparc binaries
> > > of mplayer  1.0pre6a-4  in your friendly repository
> > > 
> > > http://tonelli.sns.it/pub/mplayer/sarge
> > > 
> > > with special thanks to  David Moreno Garza  for the sparc binary
> > > and Simon McVittie for powerpc
> > 
> >BTW, what is the current status of inclusion of this in debian ? It seems 
> >that
> > even ubuntu now carries a mplayer binary, so there is really no reason at 
> > all
> > for not having one in debian. Especially as many of those who opposed 
> > mplayer
> > back then are now working for ubuntu.
> 
> 
> I am waiting from anybody in the ftp master team to say anything

Like said, since ubuntu has mplayer, there is really no reason to stale it for
debian now.

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

[Sven Luther]

On Mon, Mar 14, 2005 at 11:28:08AM +0100, Andreas Schuldei wrote:
> On Mon, Mar 14, 2005 at 11:05:16AM +0100, Sven Luther wrote:
> > And how do you reconcile the fact that most of those told us recently on
> > debian-vote that they believed that dropping an architecture will not help
> > with the delay of the release ? And giving the times of the posts, they
> > probably knew about this plan previously to replying that, especially those 
> > of
> > the scud team. Pure demagogy then ? 
> 
> To my best knowledge Branden did not know about the proposal at
> the time of the LWN interview. So from him it was no demagogy but
> his own honest, private oppinion. I and AJ knew about it since we
> were involved in the meeting. We both sidestepped the question
> since the proposal was still not ready at that time.

Ok.

> btw: the results of that interview were not posted to -vote.

Maybe it should have at that.

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

[Andreas Barth]

* Sven Luther ([EMAIL PROTECTED]) [050314 11:35]:
> Well, but wouldn't reenabling the popularity-contest by default for sarge help
> a lot on that ? 

There was a technical reason why it was removed - more or less, if you
want this changed, you need to submit a patch (but it might be too late
now, as RC3 should be more or less building).


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

[Robert Lemmen]

On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:
> Therefore, we're planning on not releasing most of the minor architectures
> starting with etch.  They will be released with sarge, with all that
> implies (including security support until sarge is archived), but they
> would no longer be included in testing.
> [...]

i feel very,very bad about this, but perhaps it's what is needed. i have two
*big* concerns though:

- maintainers will start to downgrade or ignore bugs that are
  arch-specififc if that arch is not in "the" archive. we should have at
  least the requirement that a package must be functional in "the"
  archive + scc to be fit for testing (apart from really arch-specific
  packages of course)
- there must be a way for a scc arch to get a stable release. why don't
  we either keep testing for scc archs but not do releases, so the
  porters can do their own stable releases of their arch or have
  per-arch testing? (the latter might lead to a source package explosion
  i think)

cu  robert  

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

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

[Sven Luther]

On Mon, Mar 14, 2005 at 11:38:57AM +0100, Andreas Barth wrote:
> * Sven Luther ([EMAIL PROTECTED]) [050314 11:35]:
> > Well, but wouldn't reenabling the popularity-contest by default for sarge 
> > help
> > a lot on that ? 
> 
> There was a technical reason why it was removed - more or less, if you

Yes, it asked one question during the install, wasn't it ? One potentially
confusing question to the poor user.

> want this changed, you need to submit a patch (but it might be too late
> now, as RC3 should be more or less building).

It was too late a month ago already.

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

[Henning Makholm]

Scripsit Steve Langasek <[EMAIL PROTECTED]>

> For these reasons, I think the snapshotting approach is a better option,
> because it puts the package selection choices directly in the hands of
> the porters rather than trying to munge the existing testing scripts
> into something that will make reasonable package selections for you.

What is "the snapshotting approach"?  I understood the announcement
such that the lesser architectures are only ever allowed to have a
single version of each .deb distributed by the project, namely the
lastest one built at any given time.

I think that would be vastly to the non-benefit of such an
architecture's users, and I don't see how other architectures
can be harmed by allowing the lesser architectures to distribute
whatever .debs they manage to build corresponding to the official
testing and stable distributions.

Especially, if I somehow dug a Foomatic 664 with punched-tape main
memory out of a dumpster and wanted to run Debian on it (assuming
somebody had ported it), then for my own sanity I would like to have
to option of running the same software versions as I'm running on the
stable x86 box. If lesser architectures are _required_ to run the
bleeding edge, then Debian are significanly degrading the user
experience, and with no real gain that I can see.

> First, if they're not being kept in sync, it increases the number of
> matching source packages that we need to keep around (which, as has
> been discussed, is already a problem);

There could be a rule specifying that only versions that _are_ being
kept in sync can be in the archive, with some reasonable time limit to
let the arch build the newest version when it migrates to testing.

> second, if you want to update using the testing scripts, you either have
> to run a separate copy of britney for each arch (time consuming,
> resource-intensive)

But if the arch's porters are willing to do that, why shouldn't they
be allowed to?

> third, if failures on non-release archs are not release-critical
> bugs (which they're not), you don't have any sane measure of
> bugginess for britney to use in deciding which packages to keep out.

A lesser architecture's concept of testing could just be, "we're
trying our best to keep up with the package versions in the official
testing, regardless of bug counts".

-- 
Henning Makholm   "Jeg mener, at der eksisterer et hemmeligt
 selskab med forgreninger i hele verden, som
 arbejder i det skjulte for at udsprede det rygte at
  der eksisterer en verdensomspændende sammensværgelse."

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

[Wouter Verhelst]

Op ma, 14-03-2005 te 00:10 -0800, schreef Steve Langasek:
> Well, my objection is basically the same as Thomas's here -- all package
> builds are *not* equally urgent, 

Of course not, that is exactly my point.

But from the POV of a package's maintainer, all fixes are more or less
urgent. If some fixes weren't necessary, the upload wouldn't have been
there in the first place.

> and in fact, we have an "urgency" field
> in uploads that expresses this fact quite clearly.  Certainly there's
> some danger of abuse by uploaders, but there are dozens of other things
> that maintainers *could* abuse right now and are only stopped from doing
> because they *shouldn't* do them.
> 
> I wouldn't be bothered by porters choosing how to order builds, if the
> ordering they chose more closely corresponded to what the release team
> (and britney) want it to be. :)

I from my side wouldn't mind if someone from the release team would ask
me to prioritize a build[1] if necessary; but I feel irky at the thought
of allowing other people to prioritize their packages' builds over
others, because that *will* make sure that eventually, those people that
do what is actually the right thing will have to wait for all eternity
for their packages to be built.

[1] this is technically possible, but only in a kindof hackish way, by
manually adding the package to a buildd's REDO file and (also manually)
setting it to 'building' by that host.

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

[Joey Hess]

Sven Luther wrote:
> Yes, it asked one question during the install, wasn't it ? One potentially
> confusing question to the poor user.

That's almost as innacurate as your earlier statement that
popularity-contest was dropped from d-i for rc3 (it was dropped before
rc1). Please refer to [EMAIL PROTECTED] for the facts of
the matter.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: automake/autoconf in build-dependencies

[Henning Makholm]

Scripsit Tollef Fog Heen <[EMAIL PROTECTED]>
> * Henning Makholm 

> | When I provide a configure script in the source package it means, on
> | the contrary, that I *have* tried it and therefore has some kind of
> | evidence that it will probably work for other people too.

> You have probably only tried it on one architecture.

Which is why I wrote "some kind of evidence that it will probably
work" instead of "know that it will work".

> To a certain degree, those would have been fixed if people
> build-depended on auto*, as they would have picked up fixed versions
> of the .m4 files.

But that has to be offset against the huge number of bugs that would
occur if we ran auto* at run time and had everything break everytime
the target moves.

-- 
Henning Makholm "Nemo enim fere saltat sobrius, nisi forte insanit."


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

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

[Ingo Juergensmann]

On Mon, Mar 14, 2005 at 10:50:41AM +0100, Sven Luther wrote:

> > IMHO scc.d.o will result in focussing on those archs, making it worse and
> > worse for the other archs. Implementing scc.d.o is equally to dropping those
> > older archs in my eyes. It's just another wording. 
> Notice, that there is really a unclarity of what the problem is, and the
> wording of the announcement really didn't help on this.

There were many discussions about the buildds in the past. None really
showed that the buildds itself are causing much harm to the release. 
Dropping archs (which this proposal actually is in my eyes) therefore just
scratches on the surface, not solving the real problems.  

> If the main problem is the mirror network, i think it does make sense to drop
> some arches from the mirror network. After all, ir could well be that for some
> arches we have more mirrors than users, and a single, or smaller group of
> mirrors for those arches could well be worth it. It could probably be done at
> the DNS level that ftp..debian.org automagically points to the right
> place and such, and should be transparent.

Yes. I don't understand the mirror problem either. I'm using my personal
either and have included just those archs and things I want to mirror. 
And I would have no problem when the lesser used archs would be available on
just a few mirrors. This proposal is just plain the wrong thing.  
 
> But again, i feel that the announcement was one thing, but that it lacks much
> information about the reason which pushed the decision, and the individual
> technical problems to be overcome. Are the minutes of the release-team meeting
> publically available ? 

I personally don't feel this proposal as an invitation for a discussion but
as an announcement what will happen, regardless of what is being discussed
in here. Just smaller adjustments will happen like lowering the 98% barriere
to 97 or 96% or so, but in fact this is already a decission being made by
just a handful of people without asking those who will be affected by that
decision. 

-- 
Ciao...  // 
  Ingo \X/


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

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

[Andreas Tille]

On Mon, 14 Mar 2005, Ingo Juergensmann wrote:
Sorry for using "stupid", "braindead" and others. But there are no other
words for crap like this, imho.
Hmm, while I'm in principle share your point of keeping the architectures
it does not sound very sane to be that harsh.  If a group of volunteers
faces the situation that they are not able to continue the work they did
with the expected quality, they have to face real world and draw a
decision.  Normally everything what needed to be done was done and thus
if enough people stand up and care for fitting the criteria (98% compiled
packages, security for the arch, supporting the kernel).  If there are
no such people who do the work talking about "stupid" decisions makes
no sense.
Kind regards
  Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Ingo Juergensmann]

On Mon, Mar 14, 2005 at 10:49:20AM +0100, Thijs Kinkhorst wrote:
> On Mon, March 14, 2005 10:10, Ingo Juergensmann said:
> > It would be better when the project would be honest and state that it want
> > to become a x86-compatible only distribution (with the small tribute to
> > powerpc users) than this braindead thingie.
> The problems associated with carrying many archs have been well
> demonstrated.

Where?
Joeyhs wiki page about d-i problems? Oh well... 

> This proposal is a way to address these problems. If you
> want to keep all archs as a part of the central architecture, you have to
> come up with a way to tackle the given problems (and not just shout that
> you want to keep them - just continuing without changing anything is not
> realistic). If you disagree, please come up with an alternative plan
> yourself (preferably a worked out plan like this one).

I already did this in the past. Read the archives for that please. 
 
> To me this decision sounds like a very good idea. Catering to some very
> specialised architectures can be good, but should not be a great burden on
> the total project. Trying to include everything in one big distribution is
> inherently not working (as has been shown with sarge). It is very well
> possible to maintain high quality ports of Debian, and infrastructure is
> provided for that, without making the release dependant on it.

But the number of archs is not that huge problem that some people want to
make us believe. 
I think the main problem is the general size of the distribution in number
of packages. You can't get 10.000 packages into a stable shape for a
release, quite simple. Therefore reduce the number of packages by
introducing a set of core packages and let the subprojects to sub-releases
when they will those are necessary. 
 
> At the SquirrelMail project, we include things that are of general use
> into the main distribution. Someone who requires something that's only of
> interest to a very specific group can create and maintain that as a
> plugin. That seems a very logical way to deal with specialtistic features,
> and you see that approach in many different projects.

This is quite similar to my "proposal" above, where I concentrate on package
sets and not on archs. 

-- 
Ciao...  // 
  Ingo \X/


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

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

[Aurélien Jarno]

Robert Lemmen a écrit :
i feel very,very bad about this, but perhaps it's what is needed. i have two
*big* concerns though:
- maintainers will start to downgrade or ignore bugs that are
  arch-specififc if that arch is not in "the" archive. we should have at
  least the requirement that a package must be functional in "the"
  archive + scc to be fit for testing (apart from really arch-specific
  packages of course)
Agreed, this is a very important point if we want to keep scc 
architectures useable.

--
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian GNU/Linux developer | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net
--
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]

Op zo, 13-03-2005 te 23:36 -0800, schreef Steve Langasek:
> Personally, I'd love to see our porter teams rise to the occasion and
> prove that we can release etch in 18 months with 8 architectures meeting
> these criteria instead of 4; but the first step is to shift the burden
> onto the porters, which is not where I believe it is today.

Note that I *have* offered to help out maintaining buildd hosts for
architectures currently maintained by other people who are also in other
roles in the project, and that this help was turned down; and given the
fact that I've maintained a varying number of buildd hosts (but at least
one) ever since july 2001, I would say that I'm more than qualified to
do this.

While I did (and still do) understand the reasons for not accepting that
help, it's not really fair now to suddenly say that the burden "isn't on
the porters today".

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

[Ingo Juergensmann]

On Mon, Mar 14, 2005 at 10:56:51AM +0100, Aurélien Jarno wrote:

> That let me raise a problem I see with such an infrastructure. Imagine 
> an FTBFS on an SCC architecture (let's say arch X needs an autotools 
> update). If it is not possible to have a high severity for this bug 
> (because it is "only" an SCC arch) , I am almost sure that it would be 
> ignored by a lot of developers. That would say that all SCC 
> architectures will be quickly unusable...

Which will be a de facto drop of that archs, yes. 

Many serious bugs on some archs are already ignored by maintainers for a
long time - until a release is coming and they realizes that their package
is being held back from migrating to testing by those archs. Then the
maintainer usually whines about those fscking slow and unused archs being a
showstopper for the release.  

-- 
Ciao...  // 
  Ingo \X/


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

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

[Robert Millan]

On Mon, Mar 14, 2005 at 11:26:07AM +0100, Andreas Barth wrote:
> * Sven Luther ([EMAIL PROTECTED]) [050314 11:20]:
> > On Mon, Mar 14, 2005 at 10:39:24AM +0100, Robert Millan wrote:
> > > On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:
> > > > - the port must demonstrate that they have at least 50 users
> 
> > > How do you demonstrate that?  Via popularity-contest?
>  
> > But then, popularity-contest installation per default was dropped for
> > debian-installer rc3, so ...
> 
> We don't say "it needs 50 entries in popularity-contest", but just: 50
> users. How this is demonstrated, may be different. Enough traffic on the
> porter list might also be enough - or enough bug reports coming from
> that arch. Or whatever. I don't expect that to be the blocking critieria
> for any arch.

I believe that kfreebsd-gnu matches all the mentioned requirements [1] except
this one.  There are quite many bug reports for this system (hundreds) but
most of them come from me ;).  If you could be more specific, that'd be much
appreciated.

[1] Of course, we don't have the DD signatures yet, but there are more than 5
DDs working on this so there's no problem collecting them.

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'http://www.debian.org/ports/kfreebsd-gnu
  `-


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

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

[David Schmitt]

On Monday 14 March 2005 11:28, Thomas Bushnell BSG wrote:
> In this case, it was a bug that required human intervention, a package
> upload that accidentally would hose a chroot, which required the
> chroot to be repaired for each affected buildd.

Even that can be mitigated by debootstrapping the chroot once a day 
automatically.

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

[David Schmitt]

On Monday 14 March 2005 11:10, Rene Engelhard wrote:
> pcc is barely at 98%. I don't think that barrier should be that high. We
> *should* at last release with the tree most important archs: i386, amd64,
> powerpc.

Please, 98% is not high. It is just a call to porters to get their act 
together.

I don't believe that any (sane) maintainer would refuse FTBFS fixing patches 
(see hurd-i386 and k{net,free}-bsd stuff). These criterions are just a IMHO 
necessary step to put the load on those people who want to use the arch 
instead of those who maintain central infrastructure.


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

[Steve McIntyre]

On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:
>
>Once this happens,
>the testing-security configuration should itself be completed for all
>architectures in quick succession, with the result that testing-security
>and testing-proposed-updates will be fully operational in the space of
>two weeks.

Cool. It's good to see progress on this.

[snip]

>Note that this plan makes no changes to the set of supported release
>architectures for sarge, but will take effect for testing and unstable
>immediately after sarge's release with the result that testing will
>contain a greatly reduced set of architectures, according to the
>following objective criteria:
>
>- it must first be part of (or at the very least, meet the criteria for)
>  scc.debian.org (see below)
>
>- the release architecture must be publicly available to buy new
>
>- the release architecture must have N+1 buildds where N is the number
>  required to keep up with the volume of uploaded packages
>
>- the value of N above must not be > 2
>
>- the release architecture must have successfully compiled 98% of the
>  archive's source (excluding architecture-specific packages)
>
>- the release architecture must have a working, tested installer
>
>- the Security Team must be willing to provide long-term support for
>  the architecture
>
>- the Debian System Administrators (DSA) 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
>
>- there must be a developer-accessible debian.org machine for the
>  architecture.
>
>We project that applying these rules for etch will reduce the set of
>candidate architectures from 11 to approximately 4 (i386, powerpc, ia64
>and amd64 -- which will be added after sarge's release when mirror space
>is freed up by moving the other architectures to scc.debian.org).
>This will drastically reduce the architecture coordination required in
>testing, giving us a more limber release process and (it is hoped) a
>much shorter release cycle on the order of 12-18 months.

When you say "N+1" buildds for a release architecture, do you mean
_exactly_ N+1, or _at least_ N+1?

Also, a common complaint I've heard recently is that several of the
SCC architecture buildd problems were being caused by lack of
time. Not machines, not offered effort, but lack of time to do buildd
setup/maintenance work by central buildd admins. Note: I'm NOT
attributing this to malice or incompetence - people need to sleep and
have some semblance of a life outside Debian, after all! m68k has
shown that a larger team of buildd admins and machines can work
effectively, allowing the least powerful of our architectures to keep
up admirably well in recent months. Is the plan for etch to still
continue to run with centrally-controlled buildds, or will it be
opened up?

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.


signature.asc
Description: Digital signature

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

[Wouter Verhelst]

Op ma, 14-03-2005 te 12:38 +0100, schreef David Schmitt:
> On Monday 14 March 2005 11:28, Thomas Bushnell BSG wrote:
> > In this case, it was a bug that required human intervention, a package
> > upload that accidentally would hose a chroot, which required the
> > chroot to be repaired for each affected buildd.
> 
> Even that can be mitigated by debootstrapping the chroot once a day 
> automatically.

Not really. You are severely underestimating the time it takes to do
that on the slower 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: Do not make gratuitous source uploads just to provoke the buildds!

[Hamish Moffatt]

On Mon, Mar 14, 2005 at 11:00:52AM +0100, Andreas Barth wrote:
> * Hamish Moffatt ([EMAIL PROTECTED]) [050314 01:55]:
> > Given how low hamradio (and the like) are prioritised, I suggest that we
> > get smarter about 'tesing' and omit some sections on some architectures.
> 
> We won't omit some sections on some architectures, but all sections on
> some architectures :)

That's a solution too!

Well done to the release and ftpmaster teams for the plan for etch.
You made some tough and possibly unpopular decisions, but I think
they were the right decisions for the project.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[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

[David Schmitt]

On Monday 14 March 2005 12:21, Ingo Juergensmann wrote:
[...]
> but in fact this is already a decission being
> made by just a handful of people without asking those who will be affected
> by that decision.

I always thought those who do the work, also get to make the decisions.



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

[Sven Luther]

On Mon, Mar 14, 2005 at 12:41:18PM +0100, David Schmitt wrote:
> On Monday 14 March 2005 11:10, Rene Engelhard wrote:
> > pcc is barely at 98%. I don't think that barrier should be that high. We
> > *should* at last release with the tree most important archs: i386, amd64,
> > powerpc.
> 
> Please, 98% is not high. It is just a call to porters to get their act 
> together.
> 
> I don't believe that any (sane) maintainer would refuse FTBFS fixing patches 
> (see hurd-i386 and k{net,free}-bsd stuff). These criterions are just a IMHO 
> necessary step to put the load on those people who want to use the arch 
> instead of those who maintain central infrastructure.

Like the arm autobuilders for example ? Mmm, but then the arm buildd
maintainer is also our main ftp-master, right ? 

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

[Hamish Moffatt]

On Mon, Mar 14, 2005 at 11:21:53AM +0100, Andreas Barth wrote:
> * Tollef Fog Heen ([EMAIL PROTECTED]) [050314 10:55]:
> > Multiarch.
> 
> I have yet to see a proposal how to do multiarch in the right way.

Is there even a demonstrated need?


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[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

[Sven Luther]

On Mon, Mar 14, 2005 at 12:47:20PM +0100, David Schmitt wrote:
> On Monday 14 March 2005 12:21, Ingo Juergensmann wrote:
> [...]
> > but in fact this is already a decission being
> > made by just a handful of people without asking those who will be affected
> > by that decision.
> 
> I always thought those who do the work, also get to make the decisions.

Not really, unless you want to fork the whole debian infrastructure that is.

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

[Roland Mas]

Sven Luther, 2005-03-14 10:50:13 +0100 :

> I don't see how having the in-devel arches be hosted on alioth
> instead on the official debian ftp server would cause a problem.

The amd64 archive on Alioth has been (and still is) the major cause of
many many problems.  In a few words: it eats space, which disrupts all
Alioth projects using CVS (for a start).

Roland.
-- 
Roland Mas

C   c ee lm  re q   j  l   a l  l  iè e  .
  -- Signatures à collectionner, série n°1, partie 3/3.


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

Re: Not every package should enter Debian (was: Re: Who cares about NEW when there are bigger issues? (was Re: Is NEW processing on hold? (was: Question for candidate Towns)))

[Lionel Elie Mamane]

On Mon, Mar 14, 2005 at 02:15:54AM -0800, Thomas Bushnell BSG wrote:
> Matthias Urlichs <[EMAIL PROTECTED]> writes:

>> That being said, sources which just sprout new binary packages
>> really should be passed through NEW automagically.

> I made a foolish mistake not too long ago that would never have been
> caught by this mechanism; I was most grateful for Anthony Towns
> working with me to do it correctly.

Other maintainers have made "foolish mistakes" in the past that
haven't been caught because nobody checked their upload (new version
of existing packages) before it entered Debian. So ftp-master should
check *all* uploads? I don't think so.

-- 
Lionel


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

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

[Hamish Moffatt]

On Mon, Mar 14, 2005 at 10:10:32AM +0100, Ingo Juergensmann wrote:
> All the work and support over all those years by all those users and porters
> will be vanished with that stupid idea, imho. 

Ingo, obviously you are pissed off. But really, is there much benefit in
making *releases* for the SCC architectures? 

The packages will still be built and d-i maintained as long as there are
porters interested in doing that work for the architecture. The only
difference is that those architectures won't influence testing and they
won't be officially released.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[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

[David Schmitt]

On Monday 14 March 2005 11:00, Sven Luther wrote:
> On Mon, Mar 14, 2005 at 01:14:47AM -0800, Steve Langasek wrote:
> > There are a few problems with trying to run testing for architectures
> > that aren't being kept in sync.  First, if they're not being kept in
> > sync, it increases the number of matching source packages that we need
> > to keep around (which, as has been discussed, is already a problem);
> > second, if you want to update using the testing scripts, you either have
> > to run a separate copy of britney for each arch (time consuming,
> > resource-intensive) or continue processing it as part of the main
> > britney run (we already tread the line in terms of how many archs
> > britney can handle, and using a single britney check for archs that
> > aren't keeping up doesn't give very good results); and third, if
> > failures on non-release archs are not release-critical bugs (which
> > they're not), you don't have any sane measure of bugginess for britney
> > to use in deciding which packages to keep out.
>
> What about building the scc (or tier 2 as i would say) arches from testing
> and not unstable ? this way you would have the main benefit of testing (no
> RC bugs, no breakage of the day kind of problems).

I'm only guessing: because keeping those archs in testing didn't work out and 
is (broadly) the cause dropping them in the first place?

> > For these reasons, I think the snapshotting approach is a better option,
> > because it puts the package selection choices directly in the hands of
> > the porters rather than trying to munge the existing testing scripts
> > into something that will make reasonable package selections for you.
>
> So, why don't you do snapshoting for testing ? Do you not think handling
> all those thousands of packages manually without the automated testing
> thinhy would be not an over-burden for those guys ?

Obviously britney/dak is available from cvs.d.o and meanwhile also as debian 
package. So the question for me (administrating two sparc boxes) is why _we_ 
don't setup our own testing when obviously the ftp-masters and core release 
masters are not willing to do the work for us? 

My answer is that I don't care enough for tow out of 15 boxes for the hassle, 
I will update them to sarge, be grateful for the gracetime given and - iff 
nobody steps up to do the necessary porting and security work - donate them 
to Debian when etchs release leaves my current nameserver without security 
updates.

What would you say, if I asked you to provide security support for sparc 
because _I_ need it for my nameservers? 

> You are really just saying that the testing scipts don't scale well, and
> instead of finding a solution to this, you say let's drop a bunch of
> architecture, and make it another-one's problem.

I think you have hit the point of this reorganisation head on: the people who 
did the work until now, feel that they cannot do the work with the expected 
quality _and_ the current number of arches. Thus they make the hard decision 
to put down hard, objective and verifyable rules where everyone can decide 
whether an arch deserves use of central Debian resources like mirrorspace on 
the central network.



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

[Julien BLACHE]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve Langasek <[EMAIL PROTECTED]> wrote:

Hi,

> We project that applying these rules for etch will reduce the set of
> candidate architectures from 11 to approximately 4 (i386, powerpc, ia64
> and amd64 -- which will be added after sarge's release when mirror space
> is freed up by moving the other architectures to scc.debian.org).
> This will drastically reduce the architecture coordination required in
> testing, giving us a more limber release process and (it is hoped) a
> much shorter release cycle on the order of 12-18 months.

This is radically different from what has been discussed over the past
months, ie a new mirroring scheme that would let our mirrors choose
the architectures they want to carry.

Basically, you're just leaving a number of Debian users out in the
cold. Users who choose Debian because we were the only distribution
out of there to provide serious support for the architectures they
care for, for various reasons.

Moreover, the criterias given in your mail are just so oriented
towards/against some architectures, that it's a bad joke (I was going
to write "disgusting", really).

If this plan gets applied as described here, we're putting years of
hard work to the trash, which is a real shame. This looks like the end
of "Debian, the universal OS", and that makes me feel sad.

I joined the Project because there was no core team to decide what was
to be done in an authoritative manner. Today, we have such a core
team, and I'm not sure I agree with that anymore (some would rather
say it's a cabal, well, their call).


Given the list of DPL candidates supporting this new "thing" (don't
know how to call that, really), I think I'm just going to vote for
"None of the above". I knew I should have run, but obviously, I do not
have the time required to be a good DPL.

I feel sad today, I feel it is a sad day for the Project.

Congrats, folks, you've got what you've been after for several years
now. Great job. "Doorstop architectures", EXIT this way  ---> []

JB.

- -- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCNXmfzWFP1/XWUWkRAjuYAJ9RPH3z9X18wP6OxqK64CeixRuhAQCg4THC
NN5c2C8baup/YEB1eHum9Rs=
=LjRj
-END PGP SIGNATURE-


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

Re: Switchconf: Orphaning or removing?

[Florian Möllers]

Jose Manuel dos Santos Calhariz schrieb:

> I have 6 labs in the University with about 60 computers, dual
> booting Windows XP and linux.  This computers will be used by the
> students to do work for the classes and as desktop for general work
> and leisure.

I have no great experience with Windows, but if I remember correctly
someone (Holger Levsen, was it you?) used FAI to install XP as well. He
did not use an image, but a reference maschiene / installation and
copied the full directory structure to the install client.


> This year I made one Debian installation with the software for the
> classes using Linux plus GNOME and KDE. 

great!

> I don't know how much time it takes installing 10 computers at same
> time using FAI or how much work is need  to setup cfengine2.

the time you need for the installation depends a little bit on your
network speed and if the install server is in the same local net, but
mainly on the hardware in the install client. here are some times from
the fai poster on http://www.informatik.uni-koeln.de/fai/

P4 2,8 GHz, 1GB RAM, IDE, 948MB Software installed => 5 Minutes
Athlon XP 1433 MHz, 896 MB RAM, SCSI, 1GB Software => 6 Minutes
P3 850 MHz, 256 MB RAM, IDE, 820 MB Software => 12 Minutes
P3 850 MHz, 256 MB RAM, IDE, 180 MB Software => 3 Minutes

When performing several installations at the same time the installation
time per machine is nearly the same.

It will take some time to setup FAI for your needs, but I am sure it can
be done.

> So I believe is better to have one reference machine that is copied to
> the 60 computers,

FAI uses a reference installation rather than a reference machiene. This
is best described by

"Plan your installation with FAI, and FAI install your plan"

Obviously you need one machiene to test the installation, but after that
it does not matter how often or when you want to perform the
installation. You can keep an existing fai setup and perfom an identical
installation whenever you want.

> after the first deployment is normal to produce two or more updates.

there is more than one way to do this (in fai). I would recommend to
perform a new installation, because
* it does not take long time
* you can offer your users a fresh and clean system, even if some
students tried to screw it up / installed spyware, or whatever. (I am a
student and I know what we sometimes do ...)

> Possibly I will use other way to update only the Linux, because this
> year Windows XP alread finished and I have more work to do on the
> Linux part.  

FAI can preserve partitions, so you can install windows once and fai
will not touch it's partition(s).

> May bet is going to use ramind, I use it to update a lab
I don't know this one.

I would really recommend to just try FAI out, take two PCs , download
the fai-iso image from http://www.informatik.uni-koeln.de/fai/ and
install the first PC with it. This will show you how fast a FAI
installation can be.
Then use that PC as you FAI server, configure it as described in the
manual and install the second PC. If you have any problems doing this,
don't hesitate to contact us!

Have Fun,
Florian



smime.p7s
Description: S/MIME Cryptographic Signature

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

[Ingo Juergensmann]

On Mon, Mar 14, 2005 at 12:25:13PM +0100, Andreas Tille wrote:

> >Sorry for using "stupid", "braindead" and others. But there are no other
> >words for crap like this, imho.
> Hmm, while I'm in principle share your point of keeping the architectures
> it does not sound very sane to be that harsh.  If a group of volunteers
> faces the situation that they are not able to continue the work they did
> with the expected quality, they have to face real world and draw a
> decision.  Normally everything what needed to be done was done and thus
> if enough people stand up and care for fitting the criteria (98% compiled
> packages, security for the arch, supporting the kernel).  If there are
> no such people who do the work talking about "stupid" decisions makes
> no sense.

There were offers of help in man power and machines for archs that had
problems in keeping up. Those were rejected. Punishing those archs for the
mistakes of those buildd admins rejecting helping hands is just plain
stupid. The user is the one who will suffer from that "decision". 

-- 
Ciao...  // 
  Ingo \X/


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

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

[Martin Michlmayr]

* Hamish Moffatt <[EMAIL PROTECTED]> [2005-03-14 23:00]:
> But really, is there much benefit in making *releases* for the SCC
> architectures?

For some SSC arches, it *might* not make a difference (possibly m68k)
but others (e.g. s390 and mipsel) are typically used for servers
or gateways, and you don't really want to run unstable in such
environments.  testing+security updates might be a compromise, but
unstable is clearly not an option for a S390 box or a mipsel Cobalt
gateway.
-- 
Martin Michlmayr
http://www.cyrius.com/


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

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

[Frank Küster]

David Schmitt <[EMAIL PROTECTED]> schrieb:

> On Monday 14 March 2005 12:21, Ingo Juergensmann wrote:
> [...]
>> but in fact this is already a decission being
>> made by just a handful of people without asking those who will be affected
>> by that decision.
>
> I always thought those who do the work, also get to make the decisions.

If the outcome of that meeting was "a decision", than many of the people
affected, *an* who do the work, where not involved in making it: The
porter teams.

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

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

[Tollef Fog Heen]

* Andreas Barth 

(Please don't send me Ccs; I read the lists I post to, else I would
have set mail-followup-to.  And please don't set your mail-followup-to
to include me.)

| * Tollef Fog Heen ([EMAIL PROTECTED]) [050314 10:55]:
| > * Steve Langasek 
| > 
| > | If you are planning any other transitions that will affect a lot of
| > | packages, please let us know in advance.  We will need to complete the
| > | larger transitions as fast as possible, to get testing back into a
| > | nearly releasable state quickly again after the release.
| 
| > Multiarch.
| 
| I have yet to see a proposal how to do multiarch in the right way.

What is lacking in the proposals out there?

| However, given the timeframe, I seriously doubt that we can do multiarch
| in time for etch.

You are wrong.  :)

glibc has multiarch support in sarge already; I have patches for gcc
to get multiarch support and a mostly-working implementation of it for
libogg, libvorbis and alsaplayer.  Currently working on fixing the
dpkg multiarch support, based on patches by Hugo Mills.

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

[Ingo Juergensmann]

On Mon, Mar 14, 2005 at 12:47:20PM +0100, David Schmitt wrote:
> On Monday 14 March 2005 12:21, Ingo Juergensmann wrote:
> [...]
> > but in fact this is already a decission being
> > made by just a handful of people without asking those who will be affected
> > by that decision.
> I always thought those who do the work, also get to make the decisions.

Who made you think that way? 
People often enough did the work and had no power to decide anything in the
project - or even about the stuff they worked on.

-- 
Ciao...  // 
  Ingo \X/


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

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

[Matthew Garrett]

Andreas Schuldei <[EMAIL PROTECTED]> wrote:

> To my best knowledge Branden did not know about the proposal at
> the time of the LWN interview. So from him it was no demagogy but
> his own honest, private oppinion. I and AJ knew about it since we
> were involved in the meeting. We both sidestepped the question
> since the proposal was still not ready at that time.

Uhm. You knew that conclusions from that meeting would be likely to
contradict the answers from other DPL candidates, but you did nothing to
make them aware of this before they had those answers published to a
large audience?

-- 
Matthew Garrett | [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

[Ingo Juergensmann]

On Mon, Mar 14, 2005 at 11:00:22PM +1100, Hamish Moffatt wrote:
> On Mon, Mar 14, 2005 at 10:10:32AM +0100, Ingo Juergensmann wrote:
> > All the work and support over all those years by all those users and porters
> > will be vanished with that stupid idea, imho. 
> Ingo, obviously you are pissed off.

Indeed I am.

> But really, is there much benefit in
> making *releases* for the SCC architectures? 
> The packages will still be built and d-i maintained as long as there are
> porters interested in doing that work for the architecture. The only
> difference is that those architectures won't influence testing and they
> won't be officially released.

What will happen is something like this: 

A: "Oh, let's see what we got here a nice Alpha server..."
B: "Let us install Debian on it!"
*browsing the web*
A: "Oh, no release of Debian for Alpha... it's unsupported..."
B: "Sad... it's a nice machine, but without a working Linux on it, we're gonna
throw it away"

-- 
Ciao...  // 
  Ingo \X/


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

Edge and multi-arch (was Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Martin Michlmayr]

* Tollef Fog Heen <[EMAIL PROTECTED]> [2005-03-14 13:10]:
> | I have yet to see a proposal how to do multiarch in the right way.
> What is lacking in the proposals out there?

The following is what I (as DPL) sent to the release people in January
to get them to discuss these issues.  I didn't post this to a list
because what I wrote is kinda rough and I wanted the release people to
clarify and post it.  Since this hasn't happened yet, I might just as
well post my original message.  But please note that some important
things might be missing in it.


Basically, there has been a lot of discussions about multi-arch and
some people seem to think that after sarge we'll _obviously_ move to
multi-arch.  Well, this is not so obvious to me.  In particular, I see
no consensus among ftpmaster/archive people, release people, toolchain
people, porters, and basically everyone else that this is the way to
go.  If we decide to go with multi-arch, we need:

  - agreement of all these people
  - a _clear_ plan about this migration (and have this plan before
sarge is out), including a clear timeplan (announcement on day X,
maintainers have Y months to upload, if they don't do it in Y
months, we'll have a time of Z people who'll NMU the packages by
G).
  - a proof of concept (this may exist already)
  - agreement with some upstream LSB people that it's a good idea for
Debian to pioneer this in the hope that others will follow suite
(rather than a way of Debian to make itself incompatible with
the rest of the world).  [Chris Yeoh and taggart are the people
to talk to.]

There may be a few other things missing, but basically the multi-arch
people have to show a clear plan _now_ how and why this migration is
supposed to happen.

Can one of you take what I said just, put this in some more coherent
form and post it to -devel?


-- 
Martin Michlmayr
http://www.cyrius.com/


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

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

[Ingo Juergensmann]

On Mon, Mar 14, 2005 at 12:47:58PM +0100, Julien BLACHE wrote:

> Basically, you're just leaving a number of Debian users out in the
> cold. Users who choose Debian because we were the only distribution
> out of there to provide serious support for the architectures they
> care for, for various reasons.

*seconded*

> Moreover, the criterias given in your mail are just so oriented
> towards/against some architectures, that it's a bad joke (I was going
> to write "disgusting", really).

It's a total change of direction: from "as long as there are people who
care, we will release those arch" to "no matter if there are people who
care, we just release mainstream archs". :-(
 
> If this plan gets applied as described here, we're putting years of
> hard work to the trash, which is a real shame. This looks like the end
> of "Debian, the universal OS", and that makes me feel sad.

Yes, think the same... :-(

> I joined the Project because there was no core team to decide what was
> to be done in an authoritative manner. Today, we have such a core
> team, and I'm not sure I agree with that anymore (some would rather
> say it's a cabal, well, their call).

And yet no chance to replace the cabal nor elect other people instead of
them, which is more like a problem for the project than just a few archs,
imho. 

> I feel sad today, I feel it is a sad day for the Project.
> 
> Congrats, folks, you've got what you've been after for several years
> now. Great job. "Doorstop architectures", EXIT this way  ---> []

This proposal is really doing harm to Debians good reputation and I'm not
sure if Debian is surviving this at all. 

-- 
Ciao...  // 
  Ingo \X/


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

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

[Hamish Moffatt]

On Mon, Mar 14, 2005 at 12:06:18PM +, Martin Michlmayr wrote:
> * Hamish Moffatt <[EMAIL PROTECTED]> [2005-03-14 23:00]:
> > But really, is there much benefit in making *releases* for the SCC
> > architectures?
> 
> For some SSC arches, it *might* not make a difference (possibly m68k)
> but others (e.g. s390 and mipsel) are typically used for servers
> or gateways, and you don't really want to run unstable in such
> environments.  testing+security updates might be a compromise, but
> unstable is clearly not an option for a S390 box or a mipsel Cobalt
> gateway.

OK, that makes sense. Can you buy those architectures new? (Surely yes
in the case of s390 at least, probably mipsel also as the mips CPU
manufacturers are alive and well.)

If those architectures meet the criteria, they would be included in
the release. The announcement anticipated 4 arches meeting the criteria
for etch but didn't set that as a limit.

I guess the <= 2 buildds requirement might be an issue for the embedded
CPUs like mips as unstable continues to grow.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[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

[Alastair McKinstry]

>* Steve Langasek 
>
>| If you are planning any other transitions that will affect a lot of
>| packages, please let us know in advance.  We will need to complete the
>| larger transitions as fast as possible, to get testing back into a
>| nearly releasable state quickly again after the release.
>

Whats a large transition? I'm working on slang1->slang2 in a private repository;
around 20 or so packages depending on it.

Currently slang2 is in pre-release; I'm working with upstream to merge Debian
patches into it, and building all slang1
dependencies against it.

Expect patches in BTS two weeks after sarge releases.

Also, I am planning on obsoleting console-tools and console-data and 
transitioning
to kbd; again, small but base change; see code  ASAP to test for breakages.


Regards
Alastair McKinstry  <[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

[Alexander Zangerl]

On Mon, 14 Mar 2005 12:06:18 GMT, Martin Michlmayr writes:
>* Hamish Moffatt <[EMAIL PROTECTED]> [2005-03-14 23:00]:
>> But really, is there much benefit in making *releases* for the SCC
>> architectures?
>
>For some SSC arches, it *might* not make a difference (possibly m68k)
>but others (e.g. s390 and mipsel) are typically used for servers
>or gateways, and you don't really want to run unstable in such
>environments.  testing+security updates might be a compromise, but
>unstable is clearly not an option for a S390 box or a mipsel Cobalt
>gateway.

...and as the proposal/fiat/whatever-it-is specifies that there
will be no testing for the lowlies it makes any server-use of 
sparcs, mipses, alphas or s390s moot. if no releases to base 
your environment on are available, then you need at least
some resemblence of "time tested" packages to consider running 
stuff on a server.

"the universal os" my ass :-(

az


-- 
+ Alexander Zangerl + DSA 42BD645D + (RSA 5B586291)
Fachbegriffe der Informatik, Admin: Die wo machen, daß das Internet geht,
aber die man nicht fragen darf, wenn es um ein klemmendes Word geht, da
sonst das Internet an meinem Rechner wieder nicht geht, weil die dann
stinkewütend werden. -- Bernd Jürgens


pgpHfgSaGp4ln.pgp
Description: PGP signature

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

[Hamish Moffatt]

On Mon, Mar 14, 2005 at 01:17:03PM +0100, Ingo Juergensmann wrote:
> On Mon, Mar 14, 2005 at 11:00:22PM +1100, Hamish Moffatt wrote:
> > But really, is there much benefit in
> > making *releases* for the SCC architectures? 
> 
> What will happen is something like this: 
> 
> A: "Oh, let's see what we got here a nice Alpha server..."
> B: "Let us install Debian on it!"
> *browsing the web*
> A: "Oh, no release of Debian for Alpha... it's unsupported..."
> B: "Sad... it's a nice machine, but without a working Linux on it, we're gonna
> throw it away"

It's unsupported officially, but unstable is still available.

The porters could do their own release if they wished.

It would be interesting to hear how NetBSD/OpenBSD handles this
situation, as they have a lot of ports. (Of course they have far fewer
packages than we do so their problem is on a much smaller scale.)
Do they release new versions on all ports at once?


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[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

[David Schmitt]

On Monday 14 March 2005 11:05, Sven Luther wrote:
> > > >   Andreas Schuldei (DPL candidate)
> > > >   Angus Lees (DPL candidate)
> > > >   Branden Robinson (DPL candidate)
> > > >   Jonathan Walther (DPL candidate)

[...]

> And how do you reconcile the fact that most of those told us recently on
> debian-vote that they believed that dropping an architecture will not help
> with the delay of the release ? And giving the times of the posts, they
> probably knew about this plan previously to replying that, especially those
> of the scud team. Pure demagogy then ?

I cannot remember[0] a question to the candidates regarding 
architecture-dropping. The only question pertaining the release[1], was only 
answered by Matthew Garret, saying that "it would be helpful if (in future) 
the release team would communicate their list of release criteria well in 
advance of their estimated time of release." Which obviously happened now.

Please point me to the posts, so I can add it to my page[2]

Regards, David

[0] And I should know, I maintain [2]
[1] http://debian.edv-bus.at/vote-2005/release-strategy.html
[2] http://debian.edv-bus.at/vote-2005/
-- 
- 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: Bits (Nybbles?) from the Vancouver release team meeting

[Thiemo Seufer]

Hamish Moffatt wrote:
> On Mon, Mar 14, 2005 at 10:10:32AM +0100, Ingo Juergensmann wrote:
> > All the work and support over all those years by all those users and porters
> > will be vanished with that stupid idea, imho. 
> 
> Ingo, obviously you are pissed off. But really, is there much benefit in
> making *releases* for the SCC architectures? 

For anyone who uses Debian as base of a commercial solution it is a
requirement. Grabing some random unstable snapshot is a non-starter.


Thiemo


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

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

[Tollef Fog Heen]

* Hamish Moffatt 

| Is there even a demonstrated need?

It solves the sparc64/powerpc64 issue in the right way as well as
giving us a nice set of other benefits such as the ability to do ABI
migrations similar to what for instance MIPS wants to do (migrate from
o32 to n32 + n64).

A complete migration is not needed for etch, but I would very much
like to have at least the basic tools needed in there.

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