Problems in the buildd network (was: Re: s390 not currently projected releasable)

[David Schmitt]

On Wednesday 16 March 2005 06:20, Thomas Bushnell BSG wrote:
> Blars Blarson <[EMAIL PROTECTED]> writes:
> > Another architecure that isn't keeping up to the 98% mark has a buildd
> > mainainter who insists (to the point of threating) that I don't build
> > and upload packages to help the build with its backlog and lack of
> > requeueing.
>
> So?  A buildd maintainer doesn't have a veto over other people
> uploading binary builds of packages.  W-b and buildd's do not have a
> monopoly over binary NMUs; the procedures are well documented in the
> Developer's Reference.  Seems to me that either the package maintainer
> or the porting team should be consulted, but given that, the buildd
> has no special status or authority.  It's a nice thing, but it's not
> the only way to upload binary NMUs.

Additionally, this hints at hidden problems of this architecture which - in 
the worst case - might lead to Debians sudden inability to support a 
really-stable release on this architecture. Regardless of the outcome of the 
post-Vancouver fallout, this is a problem that should be tackled before 
blessing that arch as "stable".



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 from the CD team, 2005-03-16

[Matthew Palmer]

On Wed, Mar 16, 2005 at 08:13:25AM +0100, Sven Luther wrote:
> On Wed, Mar 16, 2005 at 01:27:37AM +, Steve McIntyre wrote:
> > Thus, for sarge, we plan to offer officially:
> > 
> >  * ISO images for business card and netinst CDs (for all architectures)
> >  * ISO images for normal install CDs (for all architectures)
> >  * ISO images for install DVDs (i386-only planned)
> 
> May i ask for powerpc DVD images too ? 

From the next section that you snipped, I think they're going to be made
available as jigdo files and you build them yourself.  I missed that one
first time, too, and thought "what, no other arches have DVD readers?", but
a re-read put me straight.

- Matt


signature.asc
Description: Digital signature

Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Andres Salomon]

On Wed, 16 Mar 2005 01:38:48 -0500, Andres Salomon wrote:

> On Tue, 15 Mar 2005 10:35:19 +0100, Sven Luther wrote:
> 
>> On Tue, Mar 15, 2005 at 04:21:21AM -0500, Joey Hess wrote:
>>> Sven Luther wrote:
> [...]
>>> > 
>>> > This is not a ubuntu related problem though, and the help the ubuntu
>>> > kernel/security team has provided us was invaluable, but it should maybe 
>>> > not
>>> > be necessary if the information was not unrightfully hold from us in the 
>>> > first
>>> > time.
>>> 
>>> You seem to be implying that ubuntu is providing you with confidential
>>> prior warning about kernel security holes, but I really doubt this,
>> 
> 
> Actually, that was the case for a while (before ubuntu's kernel team went
> on vacation, and I went on vacation).  However, w/ all the vacations
> that have been happening, it hasn't been the case for a few months.
> 
> 

Rather, I was mistaken; they were things that had already been made
public.




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

Re: Bits from the CD team, 2005-03-16

[Sven Luther]

On Wed, Mar 16, 2005 at 01:27:37AM +, Steve McIntyre wrote:
> Thus, for sarge, we plan to offer officially:
> 
>  * ISO images for business card and netinst CDs (for all architectures)
>  * ISO images for normal install CDs (for all architectures)
>  * ISO images for install DVDs (i386-only planned)

May i ask for powerpc DVD images too ? 

Friendly,

Sven Luther


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

Re: Another load of typos

[Kenneth Pronovici]

On Wed, Mar 16, 2005 at 05:11:39PM +1100, Paul Hampson wrote:
> On Tue, Mar 15, 2005 at 05:32:10AM +0100, Florian Zumbiehl wrote:
> > HPGL
> > HTML
> > HTTPS
> 
> These three vary because the letter H is pronounced starting with either
> a 'h' (haich) or an 'a' (aich). This is _probably_ a distinction between
> American and British English, although it was originally a distinction
> between social class of the speaker of British English.  (cf. Pygmalion,
> I believe) But I don't know which one's which.
> 
> For me, "An aich-pee printer" sounds just as good as "a haich-pee
> printer".

I would say that in my experience (in American English, and I'm from the
Midwest), one would typically use "an" in front of a pronounced "H", but
"a" in front of words beginning with "H".  So, "an HTML page", "a helper
page".

I don't think that this sort of thing is worth standardizing, given that
there might be differences between typical British and American usage.
We don't seem to standardize one way or the other on British vs.
American spellings, like with "color" and "colour".  In fact, believe it
or not, the short description for the gimp-dimage-color package uses
"colour" rather than "color"...

> I just wanted to mention it, and also because this way I can have "pee"
> associated with the Debian mailing lists in google. ^_^

Heh.  That'll be funny until we get mail from the first person asking us
to remove pee from their computer.  (Damn!  That probably made it worse.)

KEN

-- 
Kenneth J. Pronovici <[EMAIL PROTECTED]>


pgpszcdiWZhiv.pgp
Description: PGP signature

Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Andres Salomon]

On Tue, 15 Mar 2005 10:35:19 +0100, Sven Luther wrote:

> On Tue, Mar 15, 2005 at 04:21:21AM -0500, Joey Hess wrote:
>> Sven Luther wrote:
[...]
>> > 
>> > This is not a ubuntu related problem though, and the help the ubuntu
>> > kernel/security team has provided us was invaluable, but it should maybe 
>> > not
>> > be necessary if the information was not unrightfully hold from us in the 
>> > first
>> > time.
>> 
>> You seem to be implying that ubuntu is providing you with confidential
>> prior warning about kernel security holes, but I really doubt this,
> 

Actually, that was the case for a while (before ubuntu's kernel team went
on vacation, and I went on vacation).  However, w/ all the vacations
that have been happening, it hasn't been the case for a few months.


> Nope, but i was at one time
hinted that i should wait a couple of days
> before starting a 12 hours build.
> 
>> since many of the ubuntu secutity advisories that I've backchecked
>> against the debian kernels have turned out to still be unfixed in the
>> kernel teams's svn weeks later.
> 
> There is nobody actively doing debian security for unstable kernels
> right now, well, not consistently, and not with the kind of advance
> warning that is needed. This is rather a disapointement, i believe. But
> i understand that our security team doesn't want or can care about
> unstable/testing security updates.

Unfortunately, we don't have any real database of vulnerabilties to ensure
that they're fixed.  I've been using
http://people.ubuntu.com/~pitti/ubuntu-cve.html, but that's about it.  The
official CAN database is close to useless, as the CAN descriptions are
generally not publically available for weeks after the vulnerability is
publically known.  As well, each kernel release is quite a pain due to the
time involved in building and coordination across architectures (I've had
my releases tagged and then backed out, for example); so, that combined w/
the rate of kernel vulnerability generally means we stick to a
release schedule of once or twice a month for each kernel (which ranges
from 2 or 3, since we have to track 2.6.8 specifically for sarge, as well
as the latest 2.6.x kernel, plus 2.6.x-1 if 2.6.x is rotting in NEW).  We
end up having anywhere from 5-10 security-related patches in each release.

For example, I just released kernel-source 2.6.8-14, but have not bothered
to build a kernel-image for i386 yet, as horms committed another security
fix to SVN for -15 about a day after I released.  Instead, I guess I'll
make sure he doesn't have any further commits, check ubuntu's latest
kernel advisories, talk to pitti to make sure he doesn't have anything
pending, release -15, and try for an i386 image at that point.  This i386
image will, of course, have to sit around in NEW for a bit, as the ABINAME
needs to be bumped by at least 2 different security related patches in -14.
After that, I'll try some sparc kernel-images for 2.6.8 and 2.6.10.  And
after that, I may even get the chance to look at 2.6.11, but I doubt it;
I'll probably leave that to svenl or something.



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

Bug#299754: ITP: NanoBlogger -- small weblog engine for the UNIX command line

[William Vera]

Package: wnpp
Severity: wishlist
Owner: William Vera <[EMAIL PROTECTED]>


* Package name: NanoBlogger
  Version : 3.1
  Upstream Author : Kevin Wood <[EMAIL PROTECTED]>
  
* URL : http://nanoblogger.sourceforge.net/
* License : (GPL)
  Description : small weblog engine for the UNIX command line

NanoBlogger is a small weblog engine written in Bash for the command
line. It uses common UNIX tools such as cat, grep and sed. It's free to
use and modify under the GNU General Public License.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.11-[Lab]
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Andres Salomon]

On Tue, 15 Mar 2005 08:51:30 -0800, Matt Zimmerman wrote:

> On Tue, Mar 15, 2005 at 09:50:22AM +0100, Sven Luther wrote:
[...]
> 
>> To have proper security-in-testing-or-unstable for the kernel, the
>> debian-kernel security team, or at least a few members of it, need to be made
>> aware of the embargoed security holes, and get a chance to fix them in
>> advance, maybe with a private or security non-public copy of our svn tree
>> (using svk maybe).
> 
> Herbert Xu used to fill this role.  After he resigned, William Lee Irwin (I
> believe) volunteered to be the point of contact for security issues.  If
> William is not active in this role, the kernel team should nominate someone
> else who can be trusted by the security team to work on sensitive issues,
> and have them contact the security team.

I have contacted Joey about this.  He said he would try and keep me in the
loop when he remembers, which is not quite what I was hoping for.



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

Re: Another load of typos

[Paul Hampson]

On Tue, Mar 15, 2005 at 05:32:10AM +0100, Florian Zumbiehl wrote:
> HPGL
> HTML
> HTTPS

These three vary because the letter H is pronounced starting with either
a 'h' (haich) or an 'a' (aich). This is _probably_ a distinction between
American and British English, although it was originally a distinction
between social class of the speaker of British English.  (cf. Pygmalion,
I believe) But I don't know which one's which.

For me, "An aich-pee printer" sounds just as good as "a haich-pee
printer".

I just wanted to mention it, and also because this way I can have "pee"
associated with the Debian mailing lists in google. ^_^

-- 
---
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: is xprint still used by mozilla, etc?

[Marc Wilson]

On Tue, Mar 15, 2005 at 05:30:50AM +0100, Jonas Gall wrote:
> On Mon, 14 Mar 2005 14:04:40 -0800, Marc Wilson <[EMAIL PROTECTED]> wrote:
> > Apparently you missed the flamage when Mozilla's maintainer went insane and
> > started requiring it. :)
> That were the days of Xprint release 008 which was not a kicker - but
> in the meantime both Xprint server (now at version 1.0) and Mozilla
> client were improved a lot.

So what you're saying is that now xprint breaks in slightly more obscure
ways rather than the incredibly obvious way it did previously?

-- 
 Marc Wilson | "Dump the condiments.  If we are to be eaten, we
 [EMAIL PROTECTED] | don't need to taste good."  -- "Visionaries" cartoon


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

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

[Thomas Bushnell BSG]

Anthony Towns  writes:

> The reason for the N = {1,2} requirement is so that the buildds can be
> maintained by Debian, which means that they can be promptly fixed for
> system-wide problems, and which means access to them can be
> controlled, rather than opening up users of that architecture to
> exploits should a random disgruntled non-developer have access to the
> machine and decide to abuse it, eg.

Ah, I had not considered this, and it makes excellent sense.  I can
see why having to manage more than three machines would be a hassle,
and I agree completely with the interest in keeping them more under
control.

I hope this would be coupled with a willingness to spend cash on
hardware.  :)  We have the cash and computers are cheap these days.

Thomas


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

Re: The sarge release disaster - some thoughts

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> So if it has taken us 6 months to get the problems with testing-security
> sorted out, what do you suppose we would have done for security support if
> we had frozen and released six months ago, without first sorting out these
> problems?  Gone six months without being able to provide security support
> for stable?  Dropped security support for oldstable without any warning?

I don't think Matthias Urlich was saying we should have released
without autobuilders; he's saying "why don't we have autobuilders,
given that the solutions obvious to me are easy."

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

[Thomas Bushnell BSG]

Anthony Towns  writes:

> Here's one way. Let's say you're hacking on the Hurd. You've been in
> the archive for a while on scc.d.o as a non-release candidate, and
> just the other day you've finally managed to get it to run "ls" again,
> and in the euphoria from that moment, over a single 48h hacking
> session you've gotten it secure, network capable, got it building
> everything, made it efficient, fixed the toolchain to work perfectly,
> and in your madcap adventures, attracted dozens of other developers
> and thousands of users to join in.

Now now, "ls" has been working for a long time.  We had bash running
before the system could even boot.  

I thank you for the scenario; it helps me understand the basic idea
you had in mind for how things would migrate.

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

[Thomas Bushnell BSG]

Anthony Towns  writes:

> AFAICS creating a "proposed-updates"-like tree called "snapshot-s390"
> for preparing a snapshot would be straightforward, if it would be
> useful; and the snapshotting feature already discussed counts somewhat
> as infrastructure support.

One suggestion here then is for the final form of this to indicate a
willingness on the part of archive administrators to help non-released
archs with such archives.  (Of course, where lots of coding is needed,
you can't be expected to promise that; I'm speaking more of set-up and
infrastructure support.)

Thomas


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

Re: s390 not currently projected releasable (was: Re: Dropping from mirror network vs dropping from tier-1)

[Thomas Bushnell BSG]

Blars Blarson <[EMAIL PROTECTED]> writes:

> Another architecure that isn't keeping up to the 98% mark has a buildd
> mainainter who insists (to the point of threating) that I don't build
> and upload packages to help the build with its backlog and lack of
> requeueing.

So?  A buildd maintainer doesn't have a veto over other people
uploading binary builds of packages.  W-b and buildd's do not have a
monopoly over binary NMUs; the procedures are well documented in the
Developer's Reference.  Seems to me that either the package maintainer
or the porting team should be consulted, but given that, the buildd
has no special status or authority.  It's a nice thing, but it's not
the only way to upload binary NMUs.

Thomas


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

Re: status of buildds?

[Thomas Bushnell BSG]

Ian Lynagh <[EMAIL PROTECTED]> writes:

> On Mon, Mar 14, 2005 at 10:51:23PM -0800, Thomas Bushnell BSG wrote:
> > 
> > The s390 porting team can perfectly well do what the hurd-i386 porting
> > team does: build them themselves.  I mean, umm, you don't have to be
> > hooked into w-b to upload packages.
> 
> I believe the wanna-build admins don't want builds that have neither
> been suitably tested (such as the build that accompanies the source in
> the maintainer's upload) nor built by one of the official buildds to be
> uploaded.

So what?  I'm not asking why w-b isn't adding them.  I'm saying, if
w-b has these concerns, and you don't, you can build, sign, and upload
packages.  Ignore w-b, and just do the work yourself.  And do it
correctly, of course.  I make plenty of foolish mistakes, and I'm
grateful for those who have been patient with me and I try not to make
them again.

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

[Daniel Jacobowitz]

On Tue, Mar 15, 2005 at 04:00:13PM -0800, Steve Langasek wrote:
> Once you start talking about having divergent packages between
> architectures, a lot of the reasons I'm hearing from people about why
> they want Debian to *do* releases for these archs seem to dissipate,
> because they no longer have assurances that the OS is "the same" on
> different hardware.  If unstable-only ports aren't enough, and the
> sources aren't going to match in the testing/stable versions, maybe we
> start to think about wanting to implement parallel infrastructure for
> these other ports, as well -- and maybe it's under the Debian umbrella,
> and maybe it isn't; I think it's better if it *is* still "Debian", but I
> think we need to be realistic about the fact that once we have to trim
> those architectures from the list of architectures being released in
> lockstep, we've removed the pressure that keeps the sources in sync and
> it's no longer going to match the stable Debian that we're providing on
> other architectures.

I don't buy the first half of this paragraph.  For me, the killer
features of Debian stable releases are:

  - Been through some amount of settling-in time, either via a freeze
or testing.  This acts as an effective quality floor.
  - Support (medium-term, I know first hand that long-term is less than
doable) from the security team.
  - "Is Debian".  Even if it isn't the same versions of everything as
some other Debian box in that other place, it's still going to work
basically the same.  I work on woody, sarge, and sid boxes; they
all share the fuzzy Is-Debian feeling.

Unstable-only ports don't do the first two.  Stable ports, even if they
diverge somewhat from other Debian stable releases, do all three.  The
more infrastructure we can provide to allow porters to take advantage
of Debian's fewer-arch stabilization, the better quality the port
releases will be.

I've suggested (briefly) a slaved testing which tries to enforce sync
with the main testing archive.  Similar things could be done for
stable.  It's been a long time since I was on the front lines of a
port, so I don't know how much manpower the ports have to work with
nowadays; but I bet they could manage this much.


-- 
Daniel Jacobowitz
CodeSourcery, LLC


-- 
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 Tue, Mar 15, 2005 at 03:47:24PM -0800, Adam McKenna wrote:
> On Tue, Mar 15, 2005 at 01:25:59PM -0800, Brian Nelson wrote:
> > Can we *please* ban Ingo from d-d?  He's been a huge pain in the ass on
> > this list for months now, has absolutely nothing constructive to
> > contribute, and is actively trying to subvert the project.
> 
> How do you propose to 'ban' someone from d-d?

Never stopped Bruce Perens. He had people on 'digest' mode, where their
entire day's posts got sent as one big digest to debian-devel. Quite
useful at times.

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

[Andres Salomon]

On Tue, 15 Mar 2005 18:02:07 +0100, Marc 'HE' Brockschmidt wrote:
[...]
> This would be a lot like the current amd64 effort, but with more
> formalized procedures. If the porters can't do it, their arch won't
> block the release process, but if they work hard enough, they can
> release together with the main architectures - and on the same code
> base, which would easen security support.
> 

I certainly like the idea of updating the main distribution w/ porter
fixes at some point; whether it's before the release (which could put a
strain on RMs, introduce potentially destabilizing changes during a
freeze, etc), or after a release (debian 3.2 is released, followed by
3.2r1, which includes security fixes as well as a bunch of changes needed
by porters for various architectures; well tested fixes, as well, for
people using stable w/ stable-proposed-updates in their sources.list doing
the testing).



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

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

[Blars Blarson]

In article <[EMAIL PROTECTED]> 
[EMAIL PROTECTED] writes:
>> According to db.d.o:
>
>The complete URL is http://db.debian.org/machines.cgi just for
>reference.
>
>>  - auric: RAID is dead (and auric is basically demilitarized since the
>>compromise -- not even running a buildd, although I'm not sure
>>about that)
>
>As I understand it, the plan was to convert auric into a buildd but
>the RAID needs to be fixed.  

auric has been a buildd on and off.  Apparently it's off again.  From
what I understand the raid needs solaris to configure, it might be
better to switch to conventional disks with software raid since this
seems to be a reliability issue.

I've also offered a machine I have to run as a sparc buildd, hosting
and maintaining it myself.

>Ben Collins was looking into this but I
>don't know about the status.  I've also heard discussions several
>months ago about using one of Ben's really fast machines.

>If we do need auric and if we need resources to fix the RAID, Debian
>can make funding available.
>
>>  - kubrick: disk is dead

I've also volenteered disks if needed.

-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.


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

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

[Adeodato Simó]

* Thomas Bushnell BSG [Mon, 14 Mar 2005 17:20:02 -0800]:
> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:

> > The only differentiating requirement for scc, as opposed to the other
> > "part of Debian" architectures, seems to be download share.  That won't
> > suddenly change.

> You are incorrect,

  No, he is not.

> and my example remains, and I'm wondering how the
> procedure would work.  The proposal does not require SCC archs to have
> developer machines, and only requires the existence of a single
> buildd.

  Please, have a look at the Proposal and notice that there are three
  _lists_ of requirements, each of them referring to one of the three
  possible categories for an arch. In the order they appear in the mail,
  these lists are:

- one of 10 entries, listing what is needed to be a "release arch"

- one of only one entry, stating what is "roughly needed" to be on
  ftp.debian.org and thus, be mirrored by all mirrors

- one of 9 entries, listing what is needed for the arch to be
  accepted in Debian at all, that is, to be in ports.debian.org

  The confusion comes because is not crystal clear that "not all release
  architectures are in ftp.debian.org, but that some of them will live
  in ports.debian.org". For example, as per the proposal, ia64 and
  powerpc are release architectures but are not in ftp.debian.org, thus
  not mirrored everywhere.

  So, to clearly answer your question from your previous mail:

> All the stuff is on scc; how do we transfer it back?  Will it be easy,
> or a major obstacle?

  There is no transfer needed at all, IOW the capability to do releases
  from ports.debian.org exists (and is a very good thing, as Colin
  Watson points out in <[EMAIL PROTECTED]>).

  Still, the Release Managers should comment on their willingness to
  make a certain scc arch a release architecture at an advanced stage in
  the preparation of a release. In my view, this is one of the few
  scenarios that I can think of them exercising their veto power: "Yes,
  you meet all the requirements, but as we're 2 months away from
  releasing we veto its inclusion _right now_.  We put it first on our
  list of goals for the next release."

  HTH,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
You cannot achieve the impossible without attempting the absurd.


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

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

[Blars Blarson]

In article <[EMAIL PROTECTED]> you write:
>I have an e3500 to replace both auric and vore (and the raid), but I
>haven't gotten an ok from James to do so yet.

That would cut the number of sparc buildds down to one, when two are
required for RC archtectures under the new proposal.



-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.


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

Re: The sarge release disaster - some thoughts

[Steve Langasek]

On Wed, Mar 16, 2005 at 02:06:01AM +0100, Matthias Urlichs wrote:
> Hi, Joey Hess wrote:

> > testing-proposed-updates is _still_ missing autobuilders.

> May I respectfully ask why that's been a problem for half a year now, IIRC?

> It's not THAT difficult to set up an autobuilder. People have volunteered
> to work on this problem, including several who have already demonstrated
> their basic ability to do so; all Somebody Else would have had to
> contribute is to add a key to the system's root SSH keyring and send a
> "here's the box, go do it" email.

So if it has taken us 6 months to get the problems with testing-security
sorted out, what do you suppose we would have done for security support if
we had frozen and released six months ago, without first sorting out these
problems?  Gone six months without being able to provide security support
for stable?  Dropped security support for oldstable without any warning?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Bug#299724: ITP: groach -- pests such as roaches hide under your windows (xroach clone)

[Roberto C. Sanchez]

Wesley J Landaker wrote:
On Tuesday, 15 March 2005 18:50, sean finney wrote:
On Tue, Mar 15, 2005 at 06:18:43PM -0700, Wesley J. Landaker wrote:
groach is a clone of the classic xroach program, but with multiple
themes, more modern code, and a free license.
why would anyone want to use this program? it's so... full... of...
bugs...
(/me goes and hides under an xterm)

Hey if all you have is critism, you can... bug off. ;)
OK.  Let's squish this thread.  It's making me squeamish. :-)
-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr


signature.asc
Description: OpenPGP digital signature

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

[John Goerzen]

On Wed, Mar 16, 2005 at 12:09:08PM +1000, Anthony Towns wrote:
> >>- the Debian System Administrators (DSA) must be willing to support
> >> debian.org machine(s) of that architecture
> >I assume people can help with this too, or?
> 
> Doing DSA work involves more than having root on a random box on the 
> internet. It's a specific task, not something that every developer is 
> already doing under a different title.

I would say that it would also be more than telling people why they
can't do it.  Perhaps it would be better to tell people what these tasks
are, so they know whether or not they'd be qualified, and could gain
experience?

-- John


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

Re: Bug#299724: ITP: groach -- pests such as roaches hide under your windows (xroach clone)

[Wesley J Landaker]

On Tuesday, 15 March 2005 18:50, sean finney wrote:
> On Tue, Mar 15, 2005 at 06:18:43PM -0700, Wesley J. Landaker wrote:
> > groach is a clone of the classic xroach program, but with multiple
> > themes, more modern code, and a free license.
>
> why would anyone want to use this program? it's so... full... of... 
> bugs...
>
>
> (/me goes and hides under an xterm)

Hey if all you have is critism, you can... bug off. ;)

-- 
Wesley J. Landaker <[EMAIL PROTECTED]>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2



pgpwVnea46rna.pgp
Description: PGP signature

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

[Steve Langasek]

On Mon, Mar 14, 2005 at 10:54:33AM +, Henning Makholm wrote:

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

It doesn't necessarily mean there's only one binary at a time for the arch;
it does mean that keeping (stable,testing,unstable) binaries+sources around
for architectures that are not being kept in sync is seen as (needlessly?)
taxing on the infrastructure.  It's worth looking for better configurations
that meet porters' needs while making more efficient use of resources.

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

There's nothing in place today that would clean up binary packages from
testing when they no longer correspond to the source needed by the release
architectures.  Anything put in place to do this would mean the "testing"
suite for these architectures would have large numbers of uninstallable
packages, and wouldn't resemble testing for the release candidate
architectures at all.

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

But removing (automatically or not) binary packages for these architectures
from testing when they expire is still no guarantee that the packages left
behind will be useful, installable, etc.

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

If this is what's needed, then as long as it doesn't interfere with the
release by resource-starving ftp-master, I think it's a fine idea.  It might
mean that it has to go on a separate piece of hardware, in order to avoid
resource-starving the release -- just as SCC will put infrequently
downloaded archs on a separate mirror network to avoid negatively impacting
our ability to get mirrors for FCC archs.  I'm not volunteering to maintain
the hardware for this second testing.

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

In that case, what value is there in using it as the basis for a stable
release?

For that matter, why is it necessary to follow testing on an ongoing basis,
instead of just building against everything in stable once it's released?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

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

[Anthony Towns]

Henning Makholm wrote:
So how can an architecture ever become releaseworthy? It will not get
release-certified before it has a a debian.org machine, and it cannot
get a machine in debian.org before it has a stable version with
security support, and it's not allowed to create a stable version and
provide security support for it before it has been release-certified.
Here's one way. Let's say you're hacking on the Hurd. You've been in the 
archive for a while on scc.d.o as a non-release candidate, and just the 
other day you've finally managed to get it to run "ls" again, and in the 
euphoria from that moment, over a single 48h hacking session you've 
gotten it secure, network capable, got it building everything, made it 
efficient, fixed the toolchain to work perfectly, and in your madcap 
adventures, attracted dozens of other developers and thousands of users 
to join in.

At this point you go "YAY" and do a snapshot release of everything 
you've done, which you call "Debian GNU/Hurd -- The Stampede". You burn 
CDs that people hand out at tradeshows, everyone tells you how much it 
rocks, you install some machines with it and start using them as web 
servers and so forth.

You talk to the security team and arrange someway to do limited support 
for security updates; via security.d.o, via some random suite in 
scc.d.o, on people.d.o or elsewhere. You talk to maintainers and make 
sure any special patches you used when releasing your snapshot are 
applied in unstable, and work through any concerns that arise. You keep 
your buildd working. You keep the hurd.debian.net developer box you 
installed and setup functioning and secure. You demonstrate you and your 
co-porters are competent and effective and will pay attention to 
problems raised by the release team. You address any other concerns DSA, 
the release team, the security team, ftpmaster, or others have, like the 
responsible, professional amateurs you are.

You and the release team and others then all say "Okay, we're ready for 
Hurd to become a real release arch", at which point you make sure you're 
properly integrated into the buildd network, convert your 
hurd.debian.net box to a hurd.debian.org box, and get added to testing.

The last paragraph won't all happen in the same microsecond, but I don't 
think it's much of a problem to have them all happen more or less together.

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

Re: s390 not currently projected releasable (was: Re: Dropping from mirror network vs dropping from tier-1)

[Blars Blarson]

In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>Bastian Blank <[EMAIL PROTECTED]> writes:
>Why don't you start building packages yourselves?  You do have access
>to the hardware, right?  It's supposed to be blindingly fast, right?

Another architecure that isn't keeping up to the 98% mark has a buildd
mainainter who insists (to the point of threating) that I don't build
and upload packages to help the build with its backlog and lack of
requeueing.

As far as I can tell, only the 98% mark and the second buildd being
down are keeping this arcitecture in the release architecture list.
(I also volenteered my own machine as a buildd, but that was refused.)


-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.


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

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

[Anthony Towns]

Frank Küster wrote:
Would the task of setting up an archive for the fixed up sources, and
the resulting binary packages, be on the shoulder of the porters alone,
or would there be support by the ftpmasters, and especially by the
system administrators?  Will it at least be possible to host such an
archive on a debian.org machine?
It depends what's actually desirable for the ports; I can't imagine 
accepting builds from non-developers anywhere on ftp.d.o or scc.d.o or 
similar, but maybe for some ports that's more important than 
infrastructure support within Debian.

AFAICS creating a "proposed-updates"-like tree called "snapshot-s390" 
for preparing a snapshot would be straightforward, if it would be 
useful; and the snapshotting feature already discussed counts somewhat 
as infrastructure support.

[This I think should be the case]
The real question is how it would be used and what support would be 
useful. I haven't finished going through all my unread -devel mail yet, 
but I haven't seen much discussion of that from affected porters yet.

Will it be possible to get the fixed-up sources reintegrated in point
releases of stable?
[don't know whether this is desirable]
All things are *possible*. What's desirable is the question.
Cheers,
aj
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Stephen Frost]

* Anthony Towns (aj@azure.humbug.org.au) wrote:
> The reason for the N = {1,2} requirement is so that the buildds can be 
> maintained by Debian, which means that they can be promptly fixed for 
> system-wide problems, and which means access to them can be controlled, 
> rather than opening up users of that architecture to exploits should a 
> random disgruntled non-developer have access to the machine and decide 
> to abuse it, eg.
> 
> >>- the Debian System Administrators (DSA) must be willing to support
> >> debian.org machine(s) of that architecture
> >I assume people can help with this too, or?
> 
> Doing DSA work involves more than having root on a random box on the 
> internet. It's a specific task, not something that every developer is 
> already doing under a different title.

These two conflict to some extent I think.  Is there a reason to
disallow the possibility of having a DD who is part of DSA only to admin
a specific box and has no access on any others?  Perhaps 'DSA' wouldn't
be the appropriate term for that and the entry bar would be a bit lower.
I think there might be more willingness by otherwise busy people to help
out in this regard if they just have to worry about *their* machine.  I
think there'd be an increased sense of committment there too.

Stephen


signature.asc
Description: Digital signature

Re: The 98% and N<=2 criteria

[Anthony Towns]

Frank Küster wrote:
For the porters to a specific architecture, this means they have an easy
way to get nearer to the 98% and the N<=2 criteria: Just convince the
maintainers of heavy-loaded desktop stuff, of big self-bootstrapping
numbercrunching applications, and whatever, to take your architecture
out of the Architecture field.
Err, it's even easier than that: they can mark the package as 
"not-for-us", and just not try to build it even if it's arch:any.

And this is not "cheating".  If KDE is of no use on m68k or for most
mips applications; or if 98% of sparc users[1] don't need a desktop, then
it's not unjust if those are simply excluded.  Remember, in the old days
before Vancouver ;-) it was mainly compiled for the benefit of the
_other_ arches.
>
And for the 2% of sparc users that do use KDE, it would probably be okay
to have a separate archive for such stuff.  
If the package is going to be built, build it, upload it, and keep it 
maintained. If you're already willing to just send people off to random 
other sources, then you're not thinking "debian stable level quality" 
anyway, and the non-release-track / snapshotting approach is likely fine 
anyway.

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

Re: Back to basic (was: Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting

[Stephen Frost]

* Thijs Kinkhorst ([EMAIL PROTECTED]) wrote:
> Example minimal quality standards:
> - it should have a large part of the packages built
> - there should be enough buildds to keep up with security and new uploads
>   within reasonable time.
> - there should be some minimal team to support this architecture
> Any arch / porting team that satisfies our demands can be included.
> 
> I honestly think that we (almost) all agree that putting these kind of
> demands in place is not too much to ask. What exactly the thresholds
> should be, that's a point of discussion. Let's first start to see whether
> we agree that putting these demands on an arch this is neccessary to
> remain our overall quality. we could then, if we do, start working on
> drafting up the exact demands and parameters.

These don't seem bad.  It doesn't solve some of the problems I believe
the proposal was intended to solve though:

The release team doesn't think it can handle any more than X archs where
X seems to be 4 or 5.  I also understand it to be the case that the
release team doesn't think additional people (or anything?) would help.
Personally I can understand this in some regards, toolchain problems,
d-i issues, etc that can't really be parallelized.  I'm not convinced
that this is the real driving factor with some of these requirements
though and that this would be impossible to improve.

As far as I can tell, without any actual word from them, I believe the
ftpmasters/DSA feel that there's a certain number of machines (including
things like buildds and whatnot) that they can support.  In this case it
doesn't seem like adding people could *not* help so I'm guessing the
concern there is that there aren't enough trusted people willing to join
ftpmasters/DSA to increase the number of machines capable of being
maintained much.

As I understand it, there wasn't anyone who's active on the security
team who was at the meeting to help draw up the proposal but I believe
it's been said that they also have an idea as to the max number of
architectures they can support.  It's not clear if that's got anything
to do w/ the number of people or just the general quality of buildds and
in some cases maintainers (kernel at least?).  Personally I tend to
think it's probably some of both- manpower and buildd infrastructure
stability.

There are some other technical issues having to do with the way
wanna-build works and that having testing for all architectures will
overload a very nice system with ssh connections.  There is work being
done to fix this already by using ssh connection cacheing.  I'd hope for
a more in-depth look and possible rewrite/rearchitecting of wanna-build,
this limitation is somewhat concerning.  Another technical issue is
mirror space but I think that's handled just fine by only mirroring
certain architectures, as I understand the plan is, and I think there
will still be some mirrors who will mirror everything so I think that'll
be alright in general.

These are just my speculations and guesses, I'd love for those involved
to step up and correct me.  If I'm right it'd be nice to get some
validation.

Stephen


signature.asc
Description: Digital signature

Re: Release sarge now, or discuss etch issues?

[Anthony Towns]

Frank Küster wrote:
I think all this discussion about etch should be delayed until sarge is
out.  Of course we would need a statement from the Nybbles team that
they do not intend to make decicions, and not to settle facts before a
thorough discussion has taken place - after the release.
Meanwhile, there have been statements on -vote, e.g. by aj in
http://lists.debian.org/debian-vote/2005/03/msg00626.html
Err, from the announcement:
"This is a very large step, and while we've discussed it fairly 
thoroughly and think we've got most of the bugs worked out, we'd 
appreciate hearing any comments you might have."

For example, "I think this is a bad idea, because afaics it will make 
doing ... much more difficult -- and that's important because of ... -- 
 and I can't see any way around that." is a comment.

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

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

[Uwe A. P. Wuerdinger]

Mark Brown schrieb:
On Tue, Mar 15, 2005 at 11:01:06PM +0100, Adrian Bunk wrote:

On some mirrors?
-> Not all mirrors have to mirror all ports.

The mirroring part of the proposal is effectively just a proposal to
rearrange the archive in order to make this easy for mirror admins.
[-snip-]
[EMAIL PROTECTED]:/root/scripts$ cat anonftpsync
#! /bin/sh
set -e
# This script originates from http://www.debian.org/mirror/anonftpsync
# Note: You MUST have rsync 2.0.16-1 or newer, which is available in slink
# and all newer Debian releases, or at http://rsync.samba.org/
# Set the variables below to fit your site. You can then use cron to have
# this script run daily to automatically update your copy of the archive.
# Don't forget:
# chmod 744 anonftpsync
# TO is the destination for the base of the Debian mirror directory
# (the dir that holds dists/ and ls-lR).
TO=/home/mirrors/debian
# RSYNC_HOST is the site you have chosen from the mirrors file.
# (http://www.debian.org/mirror/mirrors_full)
RSYNC_HOST=mastermirror.stayout.int
# RSYNC_DIR is the directory given in the "Packages over rsync:" line of
# the mirrors file for the site you have chosen to mirror.
RSYNC_DIR=debian/
# EXCLUDE is a list of parameters listing patterns that rsync will exclude.
# With a blank EXCLUDE you will mirror the entire archive.
EXCLUDE="\
  --exclude binary-alpha --exclude binary-arm \
  --exclude binary-m68k \
  --exclude binary-ia64 --exclude binary-mips* --exclude binary-hppa 
--exclude binary-sh \
  --exclude *_hurd-i386.deb --exclude *_mipsel.deb \
  --exclude *_s390.deb \
  --exclude *_alpha.deb --exclude *_arm.deb \
  --exclude *_m68k.deb \
  --exclude *_ia64.deb --exclude *_hppa.deb --exclude *_mips.deb 
--exclude *_sh.deb \
  --exclude slink --exclude slink-proposed-updates \
"

# There should be no need to edit anything below this point, unless
[-snip-]
Were's the problem?
greets Uwe
--
Jetzt will man das Internet nicht einfach ein paar Leuten wie der IETF
überlassen, die wissen, was sie tun. Es ist zu wichtig geworden. - Scott 
Bradner
http://www.highspeed-firewall.de/adamantix/
http://www.x-tec.de

Re: status of buildds?

[Ian Lynagh]

On Mon, Mar 14, 2005 at 10:51:23PM -0800, Thomas Bushnell BSG wrote:
> 
> The s390 porting team can perfectly well do what the hurd-i386 porting
> team does: build them themselves.  I mean, umm, you don't have to be
> hooked into w-b to upload packages.

I believe the wanna-build admins don't want builds that have neither
been suitably tested (such as the build that accompanies the source in
the maintainer's upload) nor built by one of the official buildds to be
uploaded.

The main reason, AIUI, is that such builds tend to result in a higher
proportion of broken packages, partly because the people doing such
builds tend to be less up on problems in the tool chain for the arch.

That said, I don't believe I've seen a public, first-hand statement to
that effect. I think such a statement would be very useful to clear up
the confusion on the subject.


Thanks
Ian


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

about Nybbles : how to keep all those archs releasable complying with the Vancouver Project

[luna]

|* To: debian-devel-announce@lists.debian.org
|* Subject: Bits (Nybbles?) from the Vancouver release team meeting
|* From: Steve Langasek <[EMAIL PROTECTED]>
|* Date: Sun, 13 Mar 2005 20:45:09 -0800
We all have seen this proposal for "dropping architecture" and a lot
of us are crying because their favourite pet architecture will be
dropped.
But, I think the real question to ask and answer is not
"why do you want to drop my favourite arch?"
but
"what must be done in order to my favourite arch not to be dropped?".
Let us see what is exactly the proposal.
|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.
|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.
Ok, they say they want to drop your $arch because they are fed-up with 
it, it slow the release, et caetera


|This is a very large step, and while we've discussed it fairly
|thoroughly and think we've got most of the bugs worked out, we'd
|appreciate hearing any comments you might have.
But now we wille see the *real* guidelines to choose which release
|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.
it exist a plan in order to define second class citizen archs (scc)
not distributed by main debian ftp but accessible from some 
scc.debian.org ftp.

|Note that this plan makes no changes to the set of supported release
|with the result that [the post-release] testing will
|contain a greatly reduced set of architectures, according to the
|following objective criteria:
there is four sort of arch I number those groups 1a 1b 2 and 3
I will begin with number 3 :
in number 3 group, there are archs not supported at all by the Debian 
project.
Debian don't *know* about those archs.

In order to go into the second group, archs must comply with those 
requirements :

|- the architecture must be freely usable (i.e., without NDAs)
It seems to me reasonable thing, we don't support platform
we cannot release software developed on.
|
|- the architecture must be able to run a buildd 24/7 sustained
|  (without crashing)
|
|- the architecture must have an actual, running, working buildd
reasonable too, we must be able to build the binary package for.
|
|- the port must include basic unix functionality, e.g resolving
|  DNS names and firewalling
technical reason, we must access the buildd on Internet
|
|- binary packages must be built from the unmodified Debian source
|  (required, among other reasons, for license compliance)
no more to say
|- binaries for the proposed architecture must have been built and signed
|  by official Debian developers
seems ok to me
|
|- the architecture must have successfully compiled 50% of the archive's
|  source (excluding architecture-specific packages)
normal, an architecture which don't compile debian packages cannot 
pretend to be included with debian.

|
|- 5 developers who will use or work on the port must send in
|  signed requests for its addition
we must have developers for this arch
|
|- the port must demonstrate that they have at least 50 users
if there is no users there is no point to work on a distribution
the architectures which pass those 9 points are now in the group 2 (scc) 
i.e. debian distribute some compiled software for it but there is no 
official testing and stable-security support.
I think, it do not prohibit the porters to implement to some stage these 
feature and to use the debian infrastructure to do it, just as (I think) 
non-free do.


Next, in order to be fully supported by Debian (the group number 1),
archs must comply with some more requirements :
|- the release architecture must be publicly available to buy new
it's the point which is the most problematic to me, if I understand
why we can't support non-existant archs, I think that even old but
largely deployed archs should go to stage 1.
|- the release architecture must have N+1 buildds where N is the number
|  required to keep up with the volume of uploaded packages
If we want to have a real-life testing and stable-security build working
this is a requirement. We can't distribute security-update if we
can't build it, the "+1" is the minimum redundancy.
|- the value of N above must not be > 2
I don't understand this statement. Does this mean that "N don't *have* 
to be >2" or that "N must be <2" (my english is too poor)

|

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

[Anthony Towns]

Ola Lundqvist wrote:
- the release architecture must have N+1 buildds where N is the number
 required to keep up with the volume of uploaded packages
Sane.
- the value of N above must not be > 2
Testing related. I do not really understand why this is a problem but
somebody may be able to tell.
Uh, no, it's not testing related at all. By the time packages are 
considered for testing, it's completely irrelevant how or where they 
were built.

The reason for the N = {1,2} requirement is so that the buildds can be 
maintained by Debian, which means that they can be promptly fixed for 
system-wide problems, and which means access to them can be controlled, 
rather than opening up users of that architecture to exploits should a 
random disgruntled non-developer have access to the machine and decide 
to abuse it, eg.

- the Debian System Administrators (DSA) must be willing to support
 debian.org machine(s) of that architecture
I assume people can help with this too, or?
Doing DSA work involves more than having root on a random box on the 
internet. It's a specific task, not something that every developer is 
already doing under a different title.

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).
I'm missing sparc here, but that is only me... But even if that one is
included the drop will probably help some.
Personally, I'd like to see sparc, alpha and/or potentially arm and s390 
stick around as release architectures too; mostly that would require 
them to be actively maintaining their architecture and trying to compete 
with i386 for being better supported, which isn't something I've seen 
happen for years now. Which is disappointing, because sparc at least was 
beating the pants off everyone else (though still behind i386) a while ago.

I haven't seen much evidence of hppa, mips, mipsel or m68k coming 
anywhere near balancing the cost/benefit tradeoff for sticking around in 
the release; but there are listed criteria now, if they're the 
architectures are that valuable, I don't see any reasons for porters to 
be complaining instead of demonstrating they can meet or surpass all of 
them, or mitigate any concerns anyone might have for the others.

- there must be a sufficient user base to justify inclusion on all
 mirrors, defined as 10% of downloads over a sampled set of mirrors
This as stated before, probably a too tight limit. I think 10% of the
downloads if i386 is excluded is a better metric. :)
10% of downloads if i386 is excluded is about 0.5% of downloads. So, uh, 
no. powerpc's pretty consistently around 2%, ia64 and others are at 1% 
or below.

- binary packages must be built from the unmodified Debian source
 (required, among other reasons, for license compliance)
This is a bit vauge. Is porting uploads possible?
I don't understand why people are confused on this. If you want to 
upload a binary to the archive, you upload the source you used to build 
it as well. If you needed to modify the upstream source, your patch is 
included in the .diff.gz. If the package was already in the archive, you 
mail the patch to the maintainer, and if it's urgent, do an NMU.

It's not anything subtle.
With these comments I will happily second this proposal.
IMO, intelligent comments are far more useful than seconds.
Cheers,
aj
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#299713: ITP: cvsfs -- Translator for transparent access to cvs repositories

[Glenn Maynard]

On Wed, Mar 16, 2005 at 01:52:11AM +0100, Michael Banck wrote:
> cvsfs is a Hurd translator providing transparent (read-only for now)
> access to CVS repositories by virtualizing the remote repository in the
> local file system.  Once translated, the user can browse around in
> directories and view file contents by the means of standard GNU tools.
> Contrary to a usual cvs checkout, cvsfs only transmits the necessary
> data and not the whole source tree.

By my vague (secondhand) understanding of Hurd translators, it shows up
as a regular filesystem tree--so any tools can be used, not just GNU tools.
s/GNU //?

(Putting "GNU" there reminds me vaguely of the back of a shampoo container:
"After shampooing with Pantene(tm) Shampoo, follow up with Pantene(tm)
Conditioner, Pantene(tm) skin cleanser, ...")

-- 
Glenn Maynard


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

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

[Uwe A. P. Wuerdinger]

Greg Folkert schrieb:
On Tue, 2005-03-15 at 00:58 -0800, Steve Langasek wrote:
Hi Aurélien,
On Mon, Mar 14, 2005 at 10:56:51AM +0100, Aurélien Jarno wrote:
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?
I think this has already been answered, by someone who knows better than
I.
[snip]
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.
Since non-RC (release candidate) architectures are going to be in the
same unstable tree as the RC architectures (uploads to ftp-master,
etc.), I don't see any reason that this would be disallowed.

- 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.
Of the architectures currently in sarge, that's correct.  It's assumed
that amd64 will easily meet this 10% mark for etch.  (If it doesn't,
then the cut-off probably has to be re-thought, since it doesn't make
much sense to have a 1/11 split between ftp.d.o and scc.d.o,
*particularly* when the 11 archs together *would* most likely account
for > 10%.)

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?
This isn't being used to measure the use of the architecture; it's being
used to measure the *download frequency* for the architecture, which is
precisely the criterion that should be used in deciding how to structure
the mirror network.

Okay, I have to comment here, seeing that I personally have at two
separate locations, two complete mirrors, that I use nearly everyday.
They only update when a change in the archive is detected. That means
*MY* $PRETTY_BIG_NUMBER of usages of my own mirrors in each locale will
mean nothing. I do my own mirror(s) so as to reduce the load on the
Debian network. I actually scaled back what I use, now only having 5
arches I support, SPARC(and UltraSPARC), Alpha, HPPA-RISC, PowerPC and
x86(Intel and otherwise). I dropped IA64 a while ago and will pickup
X86_AMD64 when it become part of Sid Proper.
How would you address the fact the bulk of my usage is not even seen by
your network.

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?
experimental would also be available.

architecture requirements:
I would add as for the core set architecture:
- there must be a developer-accessible debian.org machine for the 
architecture.
This gets a little tricky for non-RC architectures, because if it's not
already (or currently) a released architecture, we have no stable distro
that can be installed on it, which means we have no security support for
it; without security support, DSA isn't willing to maintain it, which
means they probably aren't going to want to put a "debian.org" name on
it, either -- and they certainly won't want to give it privileged access
to LDAP.
You could say that "there must be a developer-accessible machine for the
architecture" without specifying "debian.org"; but I'm not sure that we
should *require* this, either.  Particularly for ports that are waning
and are not expected to become RC architectures in the future, I think
porters should be free to decide whether to spend the effort on
maintaining such a machine since its absence only hurts that port, not
the release.

I am currently in the process of acquiring rotated out of production
machines for 3 of the 5 architectures I support. I make a run to the
right-coast of the US once every 2 months and pickup sometimes 10 - 4-16
processor machines with disk and typically a dozen of GB of memory and
gaggles of disk. I rebuild/recondition most of these machines and
distribute them to NPOs that need this kind of horsepower but can't
afford current stuff or

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

[Henning Makholm]

Scripsit Steve Langasek <[EMAIL PROTECTED]>
> On Tue, Mar 15, 2005 at 11:54:24AM +, Henning Makholm wrote:

>> There is no visible reason why the solution has to include a ban on
>> making any stable release for a minor architecture at all.

> The question is, if we're not going to be releasing in tandem, and the
> source packages aren't going to be kept in sync (various people have
> already implied that any "stable" release for these archs is going to
> require separate/patched sources, which isn't really a good thing), and
> the existing release team is not going to be managing that process, is
> it actually still a *good thing* to tie it to our existing Debian
> infrastructure in other ways?

That remains to be determined, as the various porting teams decide
which kinds of release they think they'll be able to do.

I think it is clearly a *bad thing* if this future determination has
to be carried out under ground rules that says that *no* Debian
infrastructure, existing or not, must ever be used in preparing
releases for the lesser architectures. My reason for being in this
thread is to convince you and the rest of the Vancouver people to
revise the rules to make them stop saying that.

> If unstable-only ports aren't enough, and the sources aren't going
> to match in the testing/stable versions, maybe we start to think
> about wanting to implement parallel infrastructure for these other
> ports, as well -- and maybe it's under the Debian umbrella, and
> maybe it isn't; I think it's better if it *is* still "Debian",

So you would be supportive of changing the Vancouver rules to allow
such infrastructure to be within Debian?

-- 
Henning Makholm   "Larry wants to replicate all the time ... ah, no,
   all I meant was that he likes to have a bang everywhere."


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

Re: Bug#299724: ITP: groach -- pests such as roaches hide under your windows (xroach clone)

[sean finney]

On Tue, Mar 15, 2005 at 06:18:43PM -0700, Wesley J. Landaker wrote:
> groach is a clone of the classic xroach program, but with multiple
> themes, more modern code, and a free license.

why would anyone want to use this program? it's so... full... of...  bugs...


(/me goes and hides under an xterm)

sean

-- 


signature.asc
Description: Digital signature

Another "mere user" comment on the non-released architectures proposal

[Baptiste Carvello]

Hello,
this is my Very Humble (TM) opinion, as I do not have a significant 
contribution to Debian.

First I have to say I understand the general spirit of the proposal. 
Releasing on an architecture means making promises to the users, for 
example that a significant portion of the packages in the archive will 
be available, or that there will be timely security fixes. It's plain 
normal to make sure these promises are realistic. I'll leave discussion 
of the exact criteria to more knowledgeable people.

However, there are to points about which I feel very strongly:
1) that the portability bugs won't be serious anymore:
While shifting work to the porters does not necessarily mean dropping 
the arch, not being able to build from a common source does for sure. 
Common sources is what holds Debian together. An arch with their own 
patches would be a different project already.
I understand that all bugs should be fixed eventually, but 
discriminating the severity of portability bugs according to the arch is 
clearly the wrong signal.

I would rather do something like this:
a) severity could still be serious, but only if a patch is provided. 
This would put the responsability on the porters to work on the bug, but 
make sure their work is not wasted.
b) if the maintainer fears the proposed solution might lead to breakage, 
he could tag the bug etch-ignore. That way, arch-specific bugs don't 
hinder the release, but by requiring an action from the maintainer, we 
make sure the broken package doesn't enter testing when the maintainer 
just needs one more week to test the patch, or when he is MIA.

2) that the is no clear "upwards" path:
For the sake of fairness (and ultimately freedom), it should be possible 
for a group of sufficiently motivated porters to move their arch into 
tier 2, and then into tier 1. While I understand that this part of the 
proposal needs more maturation, I think it is important that clear 
guidelines on how to do that are provided. This will help avoid 
demotivation of the porters and draw the path for constructive work. It 
will also avoid abuse of unrelated infrastructure, as seems to have 
happened with the amd64 port.

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

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

[Joel Aelwyn]

On Tue, Mar 15, 2005 at 04:35:24PM -0800, Thomas Bushnell BSG wrote:
>   Ports:I assume each is its own beastie.

Each one is, but the one consistant thing I've seen across the various ones
I've worked with is that they tend to be decentralized (that is, there
is rarely if ever a 'port leader' except by virtue of being someone that
people defer to, generally due to experience with that port). 'Joining' is
usually as simple as signing up for the mailing lists; if you're a non-DD,
there may be some additional hurdles to surmount (since it isn't often all
that useful to try to get a sponsor, for 'mature' ports; less mature ones
are even more of a free-for-all than the rest).

Triumph tends to go to those who can produce working code, and there is no
immunity to the "endless discussion" pitfalls found elsewhere; just read
the debian-bsd archives for proof of that. :)
-- 
Joel Aelwyn <[EMAIL PROTECTED]>   ,''`.
 : :' :
 `. `'
   `-


signature.asc
Description: Digital signature

Re: The sarge release disaster - some thoughts

[Eduard Bloch]

#include 
* Joey Hess [Tue, Mar 15 2005, 07:40:09PM]:

> > But considering the choice between releaseing Debian 3.1 with the new 
> > installer in 2005 or releasing Debian 3.1 with boot-floppies in 2003, it 
> > might have been possible finding some Debian developers hacking 
> > boot-floppies to use them for Debian 3.1 .
> > 
> > The new installer would have been ready in time for Debian 3.2 .
> 
> IIRC when we did this for potato, getting the woody boot-floppies
> updated to work with the new kernel and potato took something on the
> order of 6 months. Do not make the mistake of thinking the boot-floppies
> were maintainable. Expecting them to be ready in two months would be
> impractical.

I disagree. You want to see them six feet under and I understand that.
But don't compare the Woody release of b-fs with the previous ones. It
had already i18n and was based on debootstrap, read: it was able to
scale well enough. The installer part was not very smart (for things
like LVM integration without cludges), or kernel 2.6, but we talk about
year 2003!

> Also, bear in mind that if we'd have done that, then we would still be
> where we are right now, but would not have the debian installer ready to
> release with sarge.

Maybe. But AFAICS there are only few developers that have worked on
both, b-f and d-i. So how would keeping b-f have damaged d-i? Maybe it
would give less motivation and so not attract enough new developers, but
from my point of view, it just has been the other way round. d-i people
took over debian-boot overnight and most previous b-f people
disappeared because of feeling beeing replaced.

I know that initial d-i developers and those from the "new generation"
see it differently, saying that d-i has already been there, was designed
before, etc.pp. But it was a fresh toy and we have seen how long the
development did take. 

I wonder how you seriously can assume that burning the bridges was a
great idea.

Regards,
Eduard.
-- 
 oh
 NOTFALL!
*** yath ([EMAIL PROTECTED]) has left channel #Debian.DE ("besuch
*ausreiß*")
 yath hatte es aber eilig... Frauenbesuch und die Wäsche nebst
Pizzaschachteln noch überall verstreut?


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

Bug#299724: ITP: groach -- pests such as roaches hide under your windows (xroach clone)

[Wesley J. Landaker]

Package: wnpp
Severity: wishlist
Owner: "Wesley J. Landaker" <[EMAIL PROTECTED]>

* Package name: groach
  Version : 0.4.0
  Upstream Author : INOUE Seiichiro <[EMAIL PROTECTED]>
* URL : 

* License : GPL
  Description : pests such as roaches hide under your X windows (xroach 
clone)

groach is a clone of the classic xroach program, but with multiple
themes, more modern code, and a free license.

Since xroach has license issues (bug #189122), groach is a great
alternative.


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

Re: The sarge release disaster - some thoughts

[Adrian Bunk]

On Tue, Mar 15, 2005 at 07:40:09PM -0500, Joey Hess wrote:
> Adrian Bunk wrote:
> > Not after October 1st 2003 it sould have been clear that the progress 
> > of the installer wasn't as good as expected. This was 2 months before 
> > the announced release date.
> > 
> > What would have been a second plan?
> > Nobody likes boot-floppies.
> > But considering the choice between releaseing Debian 3.1 with the new 
> > installer in 2005 or releasing Debian 3.1 with boot-floppies in 2003, it 
> > might have been possible finding some Debian developers hacking 
> > boot-floppies to use them for Debian 3.1 .
> > 
> > The new installer would have been ready in time for Debian 3.2 .
> 
> IIRC when we did this for potato, getting the woody boot-floppies
> updated to work with the new kernel and potato took something on the
> order of 6 months. Do not make the mistake of thinking the boot-floppies
> were maintainable. Expecting them to be ready in two months would be
> impractical.

Someone of the installer people must have promised ajt that the 
installer was ready at the dates in the release announcement (or ajt 
wouldn't have announced these dates) - and it should have been clear two 
months before the announced release date that this wouldn't work.

Let me give the worst possible second plan:
Release with the original potato boot floppies.

I'm not talking about elegant solutions.
I'm talking about hacks to not let the delays in the installer after the 
release announcement delay the whole release by a year or more.

> Also, bear in mind that if we'd have done that, then we would still be
> where we are right now, but would not have the debian installer ready to
> release with sarge.

It might have delayed the work on the new installer.

But delaying Debian 3.2 by a few months if this would have enabled a 
release of Debian 3.1 in 2003 doesn't sound like a very bad tradeoff for 
your users.

> > What would have been a second plan?
> > Use testing-proposed-updates.
> 
> testing-proposed-updates is _still_ missing autobuilders.

Please correct me if I'm misunderstanding things:

t-s required some infrastructure changes that took at about half a year.

Getting missing autobuilders for t-p-u is a task that requires manpower 
and perhaps even money, but if it's _the_ showstopper, it should be 
resolvable within a few weeks or even days.

So this might have reduced a half a year delay to a few weeks delay.

> > Consider a MUA maintained by a MIA developer with the following bugs:
> > - #1 missing build dependency (RC)
> > - #2 MUA segfaults twice a day (not RC)
> > 
> > Consider the two possible solutions:
> > 1. a NMU fixing #1
> > 2. - ensure that the maintainer is MIA
> >- orphan all packages of the MIA maintainer
> >- new maintainer adopts MUA
> >- new maintainer fixes both bugs
> > 
> > The first solution has a quick positive effect on the "RC bug count" 
> > metric.
> > The second solution looks worse in this metric, but it's actually better 
> > for the users of Debian.
> 
> I doubt that many people NMU for RC bugs without also looking at the
> recent release history of the package and checking to see what other bad
> bugs the package may have.

The first example that comes into my mind is the info package where the 
two NMUs didn't fix the many open segfault bugs (e.g. #259561 contained 
a trivial patch ACK'ed by upstream being one and a half months in the 
BTS before the latest NMU - note that this NMU was even done by a 
Release Assistant).

This shouldn't be a personal offense against the person who did this 
particular NMU - it's simply the first example coming into my mind.

> see shy jo

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: [RFC] OpenLDAP automatic upgrade

[Quanah Gibson-Mount]

sean finney <[EMAIL PROTECTED]> writes:

>> The first. Basically upstream changes the database format quite often.
>> I am even not entirely sure if the database format stays compatible in
>> the 2.1 or 2.2 line but I'd expect it to. The 2.2.23 Debian packages
>> uses libdb4.3 instead of libdb4.2 as used in 2.1.x so the reload has to
>> be done in any case.

Just to be very clear on this again.  You do *not* want to run OpenLDAP
against BDB 4.3.  Releasing Debian with its OpenLDAP compiled against BDB
4.3 would be a serious mistake.

--Quanah

-- 
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html


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

Re: The sarge release disaster - some thoughts

[Matthias Urlichs]

Hi, Joey Hess wrote:

> testing-proposed-updates is _still_ missing autobuilders.

May I respectfully ask why that's been a problem for half a year now, IIRC?

It's not THAT difficult to set up an autobuilder. People have volunteered
to work on this problem, including several who have already demonstrated
their basic ability to do so; all Somebody Else would have had to
contribute is to add a key to the system's root SSH keyring and send a
"here's the box, go do it" email.

-- 
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: Key management using a USB key

[sean finney]

hi,

On Wed, Mar 16, 2005 at 01:39:44AM +0100, Matthias Urlichs wrote:
> > also, what about the library issue?
> > 
> Which library issue? AFAIK the packages co-exist nicely.

istr trying to build gpg-agent from the upstream source but the
configure script would fail because i didn't have the appropriate
version of one of the gpg-related libraries.  the source package
seems to build debs okay though, so at least i have something
to play with...

however, don't you think it's a little pre-emptive to have a gnupg2
binary package when they haven't yet released gnupg version 2?  this
smacks of the infamous redhat gcc release...

> > assuming james is okay with it and there isn't some kind of library
> > dependency issue, i'd gladly sponsor a gpg-agent.
> > 
> Umm, s/sponsor/push it through NEW already, dammit/  ;-)

ah, sorry, can't help there.  


sean


-- 


signature.asc
Description: Digital signature

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

[Matthias Urlichs]

Hi, Marc Haber wrote:

> Since we're about Free Speech

We're about free software. That's a subset of free speech.
Disruptive speech is also a subset of free speech. That doesn't make
disruptive speech appropriate in a forum which is about free software.

One of the classic examples forced down the throats of aspiring lawyers
(yelling "Fire" in a crowded theater) is also free speech. That doesn't
make it OK by any stretch of the imagination.

NB: I am not expressing an opinion about whether I consider Ingo's
messages to be disruptive.

-- 
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: Switchconf: Orphaning or removing?

[Jose Manuel dos Santos Calhariz]

On Thu, Jan 06, 2005 at 01:01:15AM -0600, Gunnar Wolf wrote:
> Hi,
> 
> Some time ago, I adopted switchconf, a very simple bash script used to
> simply switch between configurations, planned for use on mobile
> systems, but perfectly usable on the desktop as well.
> 
> Now, switchconf is too simple. It does very little, but does not do it
> very well. I originally intended to work with it to make it much more
> robust... But in the end, I didn't get around to do it.
> 
> The original upstream author was also a DD (Sebastien Gross), but he
> orphaned the package and stopped its development. I am not working on
> it anymore, so I thought on orphaning it... But, as the package has
> never been in a stable release and it is pretty obvious, I think it
> should be removed.
> 
> ...So this message is just to ask: Does anybody care about it, or
> should I just file the removal bug?

I have taken the last available sources from snapshot and made a new
version.  It is on my personal page in the University.  Even if the
page is on portuguese, should be easy to find the links.

http://web.tagus.ist.utl.pt/~jose.calhariz/

> 
> Greetings,
> 
> -- 
> Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450

Jose Calhariz


-- 

Há três coisas certas na vida: a morte, o erro e o imprevisto

--Daniel Dantas


signature.asc
Description: Digital signature

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

[Brian Nelson]

Marc Haber <[EMAIL PROTECTED]> writes:

> On Tue, 15 Mar 2005 23:15:46 +0100, Romain Francoise
> <[EMAIL PROTECTED]> wrote:
>>Brian Nelson <[EMAIL PROTECTED]> writes:
>>> Can we *please* ban Ingo from d-d?  He's been a huge pain in the ass on
>>> this list for months now, has absolutely nothing constructive to
>>> contribute, and is actively trying to subvert the project.
>>
>>For what it's worth, I second this request.
>
> Since we're about Free Speech, kindly use your kill file. Banning
> people from the mailing list is not doing the project any favour.

Funny.  I thought we were about creating a free operating system; not
about providing a soap box for any random idiot to stand on.

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.


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

Joey Hess <[EMAIL PROTECTED]> writes:

> Colin, Steve, and I became release assistants when AJ posted a mail to
> -devel asking "who wants to be a release assistant" and then gave us a
> set of grunt-work tasks of increasing difficulty to do until he judged
> we basically knew what we were doing.

That's an excellent strategy, and it matches my memory of the
history.  So that answers one question of fifty; the remainder are as
follows.  

Now one major question is: are these chosen by self-perpetuating work,
or are they chosen by the DPL, or by someone else?  Does the DPL have
the power (where the Constitution doesn't say otherwise) to appoint
additional people to perform these tasks (even over the objection of
the incumbents) or remove people from them?

Thomas



Officers:
  DPL:  Ably described by the Constitution
  Technical Committee:  Ably described by the Constitution
  Secretary:Ably described by the Constitution

Distribution
  ftpmaster:Can just anyone join?
  release-manager:  Ably described by Joey Hess.  
  release-assistants:   Ably described by Joey Hess.
  QA:   Ably described on qa.debian.org
  CD-images:Can just anyone join?
  Documentation:Can just anyone join?
  APT "team":   Can just anyone join?
  Ports:I assume each is its own beastie.

Publicity:
  Press Contact:Chosen how?
  Partner Program:  Chosen how?

Support:
  BTS:  Can just anyone join?
  Mailing lists:Can just anyone join?
  NM Front Desk:Can just anyone join?
  DAM:  Ably described by the Constitution
  Security: Self-appointed (www.debian.org/security/faq)
  Security Audit:   Ably described by www.debian.org/security/audit/faq
  Web pages:Can just anyone join?
  Consultants Page: Can just anyone join?
  Policy:   Can just anyone join?
  System Admin: Can just anyone join?
  LDAP Admin:   Chosen how?
  Mirrors:  Can just anyone join?
  DNS:  Chosen how?
  PTS:  Can just anyone join?
  Key-signing:  Can just anyone join?
  Hardware donation;Can just anyone join?
  Accountant:   Chosen how?


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

Re: Vancouver meeting - clarifications

[Joey Hess]

Marc Haber wrote:
> The architectures you plan to release have a working installer,
> anaconda, for years. d-i was developed to allow release of all
> architectures. You are dropping that requirement, flushing all d-i
> efforts down the drain.

I didn't design d-i, begin to implement it, or lead the d-i project
because anaconda lacked support for architecture $FOO. I did so because
I saw the need for a unique installer to be developed for Debian that
met all of its needs. Supporting many architectures is only perhaps 10%
of those needs.

Also, the d-i team has no plans to drop d-i support for any
architectures whether they're in SCC or not.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Key management using a USB key

[Matthias Urlichs]

Hi,

sean finney:
> > That has been agreed to.
> 
> i didn't see anything to that regard in the wnpp bug... do you have
> a pointer to somewhere that i could verify that?

I talked with elmo about it in Barcelona, last December.

He basically said that, as long as it's understood that he gets the
package back once gnupg2 is released, he has no problem with it.

FWIW, Ubuntu already has the package, in essentially the same form I've
been uploading it to Debian last week. Guess who Ubuntu's ftpmaster is...

> also, what about the library issue?
> 
Which library issue? AFAIK the packages co-exist nicely.

> assuming james is okay with it and there isn't some kind of library
> dependency issue, i'd gladly sponsor a gpg-agent.
> 
Umm, s/sponsor/push it through NEW already, dammit/  ;-)

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


signature.asc
Description: Digital signature

Re: The sarge release disaster - some thoughts

[Joey Hess]

Martin Zobel-Helas wrote:
> Also i hoped the release team and the ftp-masters would have worked on
> the current release instead of planing for the next on. Having all these
> people together sitting in one room working on the current release would
> have been much more prodcutive.
> 
> Perhaps they did. But they didn't told us. Also some lack of
> communication.

More like a lack of reading comprehansion. Quoting the very top of
Steve's annoucement:

| First, the news for sarge.  As mentioned in the last release team
| update[1], deploying the testing-security queues has been held up
| pending some infrastructure enhancements, without which
| ftp-master.debian.org cannot handle the load of the added wanna-build
| queues for testing-security.  This week, Andreas Barth and Ryan Murray
| have been applying the finishing touches to allow the needed upgrade of
| ftp-master.debian.org's openssh to a version that supports connection
| caching, which is needed before the current ftp-master host will scale
| to handle the addition of testing-security queues.  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.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Back to basic (was: Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting

[Petri Latvala]

On Tue, Mar 15, 2005 at 11:28:29PM +0100, Thijs Kinkhorst wrote:
> On Tue, March 15, 2005 22:50, Stephen Frost said:
> > I'm not sure that we've entirely missed the point as much as we like to
> > think there's a better solution than dropping all but 4 archs.
> 
> Here's where things go wrong in this discussion. I think the original
> proposal was (in retrospect) worded too definitive and too detailed. Many
> people are falling over the fact that the proposal asserts that only 4
> archs remain and most people keep repeating that "we are dropping 8 archs"
> like that's the key of the proposal .

Exactly that. Here's my thoughts of the proposal:

The proposal is a nicely crafted troll, designed to make an end once
and for all to those nice "drop archs to speed releasing!"
threads. With clear-cut rules when an arch drops, there is no
speculation, and everyone knows when that happens.

Now, what will happen is that Etch will release with 11 archs. I bet
one or two might drop, but there's one or two to replace those. Here's
the proof, that in my mind covers every possibility.

1) There are enough resources for the arch

   A) Vancouver meeting was a devious conspiracy

  The porters play against the conspiracy by their own rules. With
  enough resources, they have 100% of packages built with minimal
  amount of buildds, and they have the manpower to spew those
  patches to packages that FTBFS.

   B) Vancouver meeting was not a devious conspiracy

  Non-issue, trivial, etc. The release team sees that the arch can
  release, and that happens.

2) There are not enough resources for the arch

   A trivial case. Not enough resources => shouldn't release. But
   that's not the case for everyone's pet arch, from what I've been
   reading on the list. So much posts about "suddenly dropping
   so-and-so many users and machines and whatnot" cannot mean
   anything else.



-- 
Petri Latvala


signature.asc
Description: Digital signature

Re: The sarge release disaster - some thoughts

[Joey Hess]

Adrian Bunk wrote:
> Not after October 1st 2003 it sould have been clear that the progress 
> of the installer wasn't as good as expected. This was 2 months before 
> the announced release date.
> 
> What would have been a second plan?
> Nobody likes boot-floppies.
> But considering the choice between releaseing Debian 3.1 with the new 
> installer in 2005 or releasing Debian 3.1 with boot-floppies in 2003, it 
> might have been possible finding some Debian developers hacking 
> boot-floppies to use them for Debian 3.1 .
> 
> The new installer would have been ready in time for Debian 3.2 .

IIRC when we did this for potato, getting the woody boot-floppies
updated to work with the new kernel and potato took something on the
order of 6 months. Do not make the mistake of thinking the boot-floppies
were maintainable. Expecting them to be ready in two months would be
impractical.

Also, bear in mind that if we'd have done that, then we would still be
where we are right now, but would not have the debian installer ready to
release with sarge.

> What would have been a second plan?
> Use testing-proposed-updates.

testing-proposed-updates is _still_ missing autobuilders.

> Consider a MUA maintained by a MIA developer with the following bugs:
> - #1 missing build dependency (RC)
> - #2 MUA segfaults twice a day (not RC)
> 
> Consider the two possible solutions:
> 1. a NMU fixing #1
> 2. - ensure that the maintainer is MIA
>- orphan all packages of the MIA maintainer
>- new maintainer adopts MUA
>- new maintainer fixes both bugs
> 
> The first solution has a quick positive effect on the "RC bug count" 
> metric.
> The second solution looks worse in this metric, but it's actually better 
> for the users of Debian.

I doubt that many people NMU for RC bugs without also looking at the
recent release history of the package and checking to see what other bad
bugs the package may have.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#299715: ITP: php-pear-info -- PHP library that show information about current PEAR install

[Polkan Garcia]

Package: wnpp
Severity: wishlist
Owner: Polkan Garcia <[EMAIL PROTECTED]>


* Package name: php-pear-info
  Version : 1.6.0
  Upstream Author : Davey Shafik <[EMAIL PROTECTED]>
* URL : http://pear.php.net/package/PEAR_Info
* License : PHP
  Description : PHP library that show information about current PEAR install

PHP library that show Information about your PEAR install and its packages.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (100, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.9pagarcia
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Bug#299714: ITP: php-db-ldap -- Pear DB compliant interface to LDAP servers

[Polkan Garcia]

Package: wnpp
Severity: wishlist
Owner: Polkan Garcia <[EMAIL PROTECTED]>


* Package name: php-db-ldap
  Version : 1.1.0
  Upstream Author : Ludovico Magnocavallo <[EMAIL PROTECTED]>
* URL : http://pear.php.net/package/DB_ldap
* License : LGPL
  Description : Pear DB compliant interface to LDAP servers

The PEAR::DB_ldap class provides a DB compliant interface to LDAP
servers.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (100, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.9pagarcia
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Bug#299713: ITP: cvsfs -- Translator for transparent access to cvs repositories

[Michael Banck]

Package: wnpp
Severity: wishlist


* Package name: cvsfs
  Version : 0.1
  Upstream Author : Stefan Siegl <[EMAIL PROTECTED]>
* URL : http://cvsfs4hurd.berlios.de/cvsfs.html
* License : GPL
  Description : Translator for transparent access to CVS repositories

cvsfs is a Hurd translator providing transparent (read-only for now)
access to CVS repositories by virtualizing the remote repository in the
local file system.  Once translated, the user can browse around in
directories and view file contents by the means of standard GNU tools.
Contrary to a usual cvs checkout, cvsfs only transmits the necessary
data and not the whole source tree.

This is somewhat similar to the cvsfs (http://cvsfs.sourceforge.net/)
project for Linux using FUSE, modulo the usual differences.  The binary
package name is yet to be decided, pending a Hurd translator naming
convention decision.


enjoy,

Michael


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

Thomas Bushnell BSG wrote:
> How does one become an ftpmaster or release manager?  How were the
> current ones chosen?  Do they simply choose their successors?

Colin, Steve, and I became release assistants when AJ posted a mail to
-devel asking "who wants to be a release assistant" and then gave us a
set of grunt-work tasks of increasing difficulty to do until he judged
we basically knew what we were doing.

I belive that the other RA's became release assistants in similar ways.

Colin, Steve, (but not me) became release managers after doing so much
work as release assistants that they were clearly ready for it and more
involved in it than AJ. 

This is all a matter of public record. See the list archives.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Key management using a USB key

[sean finney]

hi matthias,

On Tue, Mar 15, 2005 at 08:02:34AM +0100, Matthias Urlichs wrote:
> > - when gnupg releases an official version 2, james uploads a new gnupg
> >   that replaces the previous source package (or would it have to have
> >   the same name?), and generates all binary packages.
> > 
> That has been agreed to.

i didn't see anything to that regard in the wnpp bug... do you have
a pointer to somewhere that i could verify that?  also, what about the
library issue?

assuming james is okay with it and there isn't some kind of library
dependency issue, i'd gladly sponsor a gpg-agent.


sean

-- 


signature.asc
Description: Digital signature

Re: [RFC] OpenLDAP automatic upgrade

[sean finney]

hey,

On Tue, Mar 15, 2005 at 10:02:23PM +0100, Torsten Landschoff wrote:
> As far as I can see your are mostly targetting packages /using/ a
> database? Good work so far looking at your text. The few database using
> packages I tried to install did not work as good as I'd have expected...

this is true, though more precisely it's packages needing to manage
databases, which i think applies to this case.

> The first. Basically upstream changes the database format quite often.
> I am even not entirely sure if the database format stays compatible in
> the 2.1 or 2.2 line but I'd expect it to. The 2.2.23 Debian packages
> uses libdb4.3 instead of libdb4.2 as used in 2.1.x so the reload has to
> be done in any case.

that sucks.

> > if it is a change to the db format, will the new server work with the
> > old format (even if less optimally)?  if so it might make a better
> 
> No way.

double sucks.

> > might want pipe that through gzip/bzip2 :)
> 
> Hmm, good question. On a slow system this will hit really hard for big
> databases. On the other hand who will run a big LDAP server on a slow
> machine...

yeah, i'm wondering whether or not that actually makes sense to do, now
that i'm thinking about it.  you make a valid point though... i would
hope there aren't any directory services running on 386's, heh.

> > > c) the postinst checks if an ldif file is available from the old version
> > 
> > if this is an upgrade that will always need to happen in between 2.0/2.1
> > and 2.2, you should rely on the version numbers provided by dpkg instead.
> 
> Instead of what? I am using the version numbers from dpkg currently.

i think i misread your statement that "if postinst finds a dump file to
act on it", as opposed to "if the version changes suggest it should check
for a dump file".

> > that's really scary sounding.  remember that some people have some
> > Important Data in these servers.  at the *very* least you'll want to
> > give them a big scary debconf warning and the ability to quit the install.
> 
> That kind of contradicts seamless upgrades. And at install time (in
> postinst) it is already too late in the game. They'd need to reinstall
> the old package anyway.

if you warn them and give the ability to opt-out in the config, you'll
get all the folks who use apt (which preconfigures the packages before
unpacking them).  if your maintscripts automatically stop slapd during the
upgrade, even failing based on their response after unpacking would be
okay, as they could back up to an old version before slapd started and
mangled their data.

> > reading back in from a corrected ldif, could you do the following?
> > 
> > - dump the data in ldif format through a pipe
> > - pipe it through your syntax/schema checker, outputting all the
> >   violations, perhaps even as ldap modify commands
> 
> Way to complicated. In fact I don't even know the exact list of
> incompatibilities.

okay, just a thought.

> > - if there are no violations, continue with the upgrade
> 
> The old Debian configuration created a directory that does not pass the
> schemacheck of the new packages so it is almost guaranteed there are
> violations.

d'oh.

> > > This sounds simple. There are a lot of problems so:
> > 
> > no it doesn't :)
> 
> It is mostly working already at least for simple setups. And I did not
> get that many reports about upgrade problems.

that's definitely reassuring.

> > somewhere under /var/cache would be appropriate, though you might want
> > to give the admin the option via debconf to put it somewhere else.
> 
> /var/cache? I'd rather not put it there. Quoting the FHS:

i think /var/cache is the a sensible default location.  the only other
location that fits within the fhs is /var/tmp or /tmp, which has even
more liberal (the admin should be able to delete anything) requirements.
plus, the data can arguably be reconstituted by dumping the ldap database
again, assuming nothing goes wrong :)

> > if you really have to move the databases, i'd recommend against hard
> > coding where you put it.  give the admin the option of where to put it.
> > he/she will know much more about where there's free space to put it.
> 
> Yes, another debconf question :((

you could do something like

- use low priority to prompt for the location (so most folks won't see it)
- dump the database
- if failure dumping, display a debconf note saying why the dump failed
  (full disk), and that setting debconf priority to low and reinstalling
  the package will give the option of where to dump.


sean

-- 


signature.asc
Description: Digital signature

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

[Adam McKenna]

On Tue, Mar 15, 2005 at 01:25:59PM -0800, Brian Nelson wrote:
> Can we *please* ban Ingo from d-d?  He's been a huge pain in the ass on
> this list for months now, has absolutely nothing constructive to
> contribute, and is actively trying to subvert the project.

How do you propose to 'ban' someone from d-d?

--Adam
-- 
Adam McKenna  <[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

[Marc Haber]

On Tue, 15 Mar 2005 23:41:33 +, Henning Makholm
<[EMAIL PROTECTED]> wrote:
>Scripsit Marc Haber <[EMAIL PROTECTED]>
>> You should resign from a job that only has a limited number of people
>> able to do it. As a random developer, you're easily replaceable. As
>> ftpmaster or security team member, you're not.
>
>Is there a limit to the number of members in the ftpmaster or security
>teams?

No, but "we have four people on the security team", or "we have seven
listmasters" is a good excuse for not allowing new people in, while
both teams have a significantly lower number of people actually
working on it.

Greetings
Marc

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

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

[Thomas Bushnell BSG]

Matthew Palmer <[EMAIL PROTECTED]> writes:

> There's no fixed number of slots associated with a job (apart from a couple
> of constitutionally-mandated ones, but they have strict ways of getting the
> job, too, so they're not predicated on "free time").  Nobody has to retire
> in order for someone else to start working on something.

This is true, but it is also unclear how one would go about
volunteering for the jobs in question.  Indeed, it's not clear who
chooses who does these jobs.  I know how one becomes the maintainer of
a package.  There are several ways, all well documented and easily
applied.

How does one become an ftpmaster or release manager?  How were the
current ones chosen?  Do they simply choose their successors?

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

[Steve Langasek]

On Tue, Mar 15, 2005 at 11:54:24AM +, Henning Makholm wrote:
> Scripsit Steve Langasek <[EMAIL PROTECTED]>

> >> I would add as for the core set architecture:
> >> - there must be a developer-accessible debian.org machine for the 
> >> architecture.

> > This gets a little tricky for non-RC architectures, because if it's not
> > already (or currently) a released architecture, we have no stable distro
> > that can be installed on it, which means we have no security support for
> > it; without security support, DSA isn't willing to maintain it, which
> > means they probably aren't going to want to put a "debian.org" name on
> > it, either -- and they certainly won't want to give it privileged access
> > to LDAP.

> So how can an architecture ever become releaseworthy? It will not get
> release-certified before it has a a debian.org machine, and it cannot
> get a machine in debian.org before it has a stable version with
> security support, and it's not allowed to create a stable version and
> provide security support for it before it has been release-certified.

Yes, this is a bootstrapping problem in the proposal, which was
recognized by the ftpmasters at the meeting.  Is it ok to assume that
DSA will come up with a reasonable solution for this logic hole, or do
you think this needs to be discussed further?

My assumption is that, for *new* RC architectures, the requirements "the
DSA must be willing to support debian.org machine(s) of that
architecture" and "there must be a developer-accessible debian.org
machine for the architecture" are requirements that go into effect once
the architecture has been released as stable, but that everyone needs to
agree to complying with *before* it is considered an RC arch.

> > Well, if we wanted to make the decision without the input of developers,
> > announcing it on d-d-a in advance of implementation isn't a very
> > effective way to make that happen, is it?

> If you wanted to make the decision _with_ the input of developers, why
> did all the powers that be vehemently deny that the number of
> architectures was a problem for the release schedule, right until
> everyone turned on a platter and presented this fait accompli?

Assuming "powers that be" means "the release team" here, we did not make
any such claim, vehemently or not.  Joey Hess has already talked,
repeatedly, about the personal time investment he's made getting d-i
ported to all architectures; the preceding release announcement
mentioned the fact that some architectures were short on kernel
developers and needed more help to get the turnaround time for security
fixes down to an acceptable level; and per-architecture problems on one
architecture or another have been a frequent topic in release team
announcements over the past year.

There have been some attempts to dispel FUD about *why* having a high
arch count is bad for the release, but that's not the same thing.

> > but I *do* know that stable support for all of these architectures
> > costs us in terms of the release cycle.

> The solution to that is to decouple the secondary architectures from
> the release cycle of the main architecture. There is no visible reason
> why the solution has to include a ban on making any stable release for
> a minor architecture at all.

The question is, if we're not going to be releasing in tandem, and the
source packages aren't going to be kept in sync (various people have
already implied that any "stable" release for these archs is going to
require separate/patched sources, which isn't really a good thing), and
the existing release team is not going to be managing that process, is
it actually still a *good thing* to tie it to our existing Debian
infrastructure in other ways?

Once you start talking about having divergent packages between
architectures, a lot of the reasons I'm hearing from people about why
they want Debian to *do* releases for these archs seem to dissipate,
because they no longer have assurances that the OS is "the same" on
different hardware.  If unstable-only ports aren't enough, and the
sources aren't going to match in the testing/stable versions, maybe we
start to think about wanting to implement parallel infrastructure for
these other ports, as well -- and maybe it's under the Debian umbrella,
and maybe it isn't; I think it's better if it *is* still "Debian", but I
think we need to be realistic about the fact that once we have to trim
those architectures from the list of architectures being released in
lockstep, we've removed the pressure that keeps the sources in sync and
it's no longer going to match the stable Debian that we're providing on
other architectures.

I'd love for this discussion to result in a plan that gives porters the
resources they need to do the stable Debian releases they want, without
putting the burden on the non-parallelizable release team to make it
happen.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

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

[Henning Makholm]

Scripsit Marc Haber <[EMAIL PROTECTED]>
> On Tue, 15 Mar 2005 18:31:03 +, Henning Makholm

>>My job is keeping me from working on Debian as much as I'd like.
>>Should I resign as a DD?

> You should resign from a job that only has a limited number of people
> able to do it. As a random developer, you're easily replaceable. As
> ftpmaster or security team member, you're not.

Is there a limit to the number of members in the ftpmaster or security
teams?

-- 
Henning Makholm  "The spirits will have to knit like
banshees, but with enough spirits it *can* be done!"


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

On Tue, Mar 15, 2005 at 07:59:00PM +0100, Ingo Juergensmann wrote:
> On Tue, Mar 15, 2005 at 06:31:03PM +, Henning Makholm wrote:
> 
> > > If his job is keeping him from working on Debian, he should step down
> > > from his post.
> > My job is keeping me from working on Debian as much as I'd like.
> > Should I resign as a DD?
> > Do you think that only people who are either unemployed, retired, or
> > employed solely to do Debian work should be allowed to have positions
> > in Debian?
> 
> "like" != "need to"
> 
> If you like to work more on Debian, this is great because it shows that are
> full of enthusiasm and power.
> If you swamped with work load, so you can't fulfill your needed duties of
> your position within Debian, you should retire from that job within Debian
> to let someone else with more spare time do the job. 

There's no fixed number of slots associated with a job (apart from a couple
of constitutionally-mandated ones, but they have strict ways of getting the
job, too, so they're not predicated on "free time").  Nobody has to retire
in order for someone else to start working on something.

- Matt


signature.asc
Description: Digital signature

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

[Matthew Palmer]

On Tue, Mar 15, 2005 at 11:04:09AM +0100, Julien BLACHE wrote:
> Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> >> How could we know ? We know nothing about Ubuntu, nothing about
> >> Canonical, nothing about the goals, nothing about how everything was
> >> done to begin with, nothing about who works or doesn't work there.
> >
> > Details about Ubuntu and its goals can be found on the website.  In many
> > respects there is more information available about Ubuntu activity, and the
> > goals of the project, than about organizations which provide you with the
> > essentials of life.  Yet, you seem to trust them by default, while you
> > assume that Ubuntu seeks to cause you harm.  Why?
> 
> Because Ubuntu appeared behind a screen of smoke. And smoke hasn't
> dissipated yet. Debian Developers were not informed in an appropriate
> manner of what was going on there.

Please define an appropriate manner in which Canonical could have informed
all Debian developers.  I'll give you a big bonus, too -- you get the
benefit of hindsight.

- Matt


signature.asc
Description: Digital signature

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

[Matthew Palmer]

On Tue, Mar 15, 2005 at 11:32:16AM +0100, Julien BLACHE wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
> 
> > | How could we know ? We know nothing about Ubuntu, nothing about
> > | Canonical, nothing about the goals, nothing about how everything was
> > | done to begin with, nothing about who works or doesn't work there.
> >
> > That, sir, would be entirely the fault of yourself.  It's three clicks
> > from the front page of canonical.com what the goals of Ubuntu is.
> > It's well documented on the www.ubuntu.com pages.  About who works or
> > doesn't work there, well, though it's not secret, it's not like the
> > company roster is publically available.  A lot of the names should be
> > easy to pick out, though.
> 
> For $DEITY's sake. Will you please understand that the Ubuntu folks
> totally failed to inform their fellows about what was going on ? And

Why should they have?  Considering the amount of crap that gets piled on
them now, I think their decision not to send constant "so-and-so just went
to the toilet" messages to d-d-a was pretty reasonable.

> I think we deserved a better explanation.

I think we all deserved a pony.

> > I don't think accusing the Ubuntu developers of hiding information is
> 
> At the time of no-name-yet, they *were* hiding information.

Like what?  The fact that one of them turned up in the office one day with a
hangover?  That's not hiding, that's just not telling you something.  And
no, you do not have a right to know *anything* about Ubuntu, so it's
difficult to make charges of information hiding stick.

- Matt


signature.asc
Description: Digital signature

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

[Marc Haber]

On Tue, 15 Mar 2005 13:31:34 -0500, David Nusinow
<[EMAIL PROTECTED]> wrote:
>My interpretation of the announcement, and this also comes from talking with
>some of the people involved, is that this affords ports with the flexibility to
>do as they please without slowing down the rest of the project.

That is an interpretation that I cannot follow regarding the wording
of the Vancouver Paper.

>For *years*,
>I've heard porters complain about ftpmaster and such. Well, now every port has
>the full ability to take matters in to their own hands. They still upload to
>unstable, just like always. Autobuilders for those arches still run, just like
>always. These arches still have a host or number of hosts with sufficient drive
>space to manage their port, just like always (although the url will be changed
>to something as of yet undetermined).

Well, DSA refuses to do system administration for machines running
anything other than Debian stable. So, when there is no Debian stable
for $ARCH any more, who will take care of the $ARCH developer boxes?

>The differences? Port packages don't go in to Debian mainline testing. However,
>this does not preclude them from setting up a separate testing if they like.

Really? The Vancouver Paper says something very different.

>The people involved with the Vancouver document know what they're doing, and
>they've said (more than once when I've heard) that the unstable snapshot method
>is better than setting up a separate testing, and I believe them.

Well, I know some attendants of the Vancouver Meeting personally, and
I even call one of them a friend. However, the Vancouver Meeting was
also attended by some people that have worked hard to earn my utmost
distrust, so I am kind of undecided what to think. Currently, I still
think that the Vancouver Paper is mainly to ease the work load on
ftpmaster, while not forcing them to accept any help, and to allow
them to continue holding the project hostage while claiming that they
do not owe anything.

>This does not preclude porters from making a stable release.

Well, the Vancouver Paper says different.

> In fact, all the
>talk I've heard assumes that they will (via the snapshot method).

Snapshots of unstable will be _very_ different from testing/stable,
and so any snapshot-based release will not be what Debian stable is,
resulting in a bunch of uncoordinated independent distributions. This
is not what we owe to our users. We claim to make "The Universal
Operating System", and we are currently working hard on making that
claim an outright lie.

> Their ability
>to work is no longer hampered by overloaded RM's/ftpmasters/whatever. I think
>that when a port makes a stable release it'll be thought of as an actual Debian
>release, especially when it sync's up with the mainline stable release.

How can a distribution that is forced to be based on an unstable
snapshot be synced with mainline stable?


> - David Nusinow

A true politician. Congratulations.

Greetings
Marc

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

Re: The sarge release disaster - some thoughts

[Matthew Garrett]

Bas Zoetekouw <[EMAIL PROTECTED]> wrote:

> I definately agree with you on this.  The way this discussion is going
> atm is in the direction of finding solutions while the underlying
> problems aren't at all clear[1].
> 
> [1] At least not to the developers at large.

Andreas Barth has posted a good description of the problems that the
release team face, and how the proposal would help. I'm hoping that
something similary will be forthcoming from the ftp-masters.

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

[Marc Haber]

On Tue, 15 Mar 2005 18:31:03 +, Henning Makholm
<[EMAIL PROTECTED]> wrote:
>Scripsit Marc Haber <[EMAIL PROTECTED]>
>> On Tue, 15 Mar 2005 11:17:25 -0500, David Nusinow
>>>We didn't "lose" him to Ubuntu. The man got a job and is busy. It would have
>>>been the same with any other job that keeps one busy. There's no grand
>>>Canonical Conspiracy [tm] to keep him from working on Debian. 
>
>> If his job is keeping him from working on Debian, he should step down
>> from his post.
>
>My job is keeping me from working on Debian as much as I'd like.
>Should I resign as a DD?

You should resign from a job that only has a limited number of people
able to do it. As a random developer, you're easily replaceable. As
ftpmaster or security team member, you're not.

Greetings
Marc

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

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

[Marc Haber]

On Tue, 15 Mar 2005 23:15:46 +0100, Romain Francoise
<[EMAIL PROTECTED]> wrote:
>Brian Nelson <[EMAIL PROTECTED]> writes:
>> Can we *please* ban Ingo from d-d?  He's been a huge pain in the ass on
>> this list for months now, has absolutely nothing constructive to
>> contribute, and is actively trying to subvert the project.
>
>For what it's worth, I second this request.

Since we're about Free Speech, kindly use your kill file. Banning
people from the mailing list is not doing the project any favour.

Greetings
Marc

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

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

[Ingo Juergensmann]

On Tue, Mar 15, 2005 at 11:54:31PM +0100, Adrian Bunk wrote:

> > 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"
> A: Wait. Thank god, it's supported by Gentoo.

Bingo! You got it!

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


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

Re: The sarge release disaster - some thoughts

[Bas Zoetekouw]

Hi Pierre!

You wrote:

> btw, I think that before making very huge plans, maybe an exhaustive 
> problems that have blocked the sarge release (like Adrian did) *is* the 
> way to go.

I definately agree with you on this.  The way this discussion is going
atm is in the direction of finding solutions while the underlying
problems aren't at all clear[1].

[1] At least not to the developers at large.

-- 
Kind regards,
++
| Bas Zoetekouw  | GPG key: 0644fab7 |
|| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] |  a2b1 2bae e41f 0644 fab7 |
++ 


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

On Mon, Mar 14, 2005 at 01:17:03PM +0100, Ingo Juergensmann wrote:
>...
> > 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"

A: Wait. Thank god, it's supported by Gentoo.

> Ciao...  // 
>   Ingo \X/

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

* Reinhard Tartler 

| On Mon, 14 Mar 2005 15:11:01 +0100, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
| > * Hamish Moffatt
| > 
| > | 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.)
| > 
| > [EMAIL PROTECTED]:~# uname -a
| > Linux eetha 2.4.29 #1 Fri Mar 4 02:35:42 EST 2005 mips unknown
| > 
| > This was bought about a week ago; a linksys WRT54GS.
| 
| Please be serious. Did you really manage to get debian running on that
| hardware?

Not yet, but I intend to.  A friend of mine runs Gentoo on his Linksys
Network Storage Link, but it has an USB interface so it doesn't have
storage limitations the way the WRT54GS has.

(My post was answering the question «can you get hardware for those
arches new?», not «and will Debian run on them»)

| I also bought that hardware, and find it quite useful, but NOT for
| running debian on it. The wrt hardware is too restricted for a
| fullblown glibc :(

NFS root for the Debian system ought to work just fine.  (So using
both OpenWRT and Debian.)

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

Back to basic (was: Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting

[Thijs Kinkhorst]

On Tue, March 15, 2005 22:50, Stephen Frost said:
> I'm not sure that we've entirely missed the point as much as we like to
> think there's a better solution than dropping all but 4 archs.

Here's where things go wrong in this discussion. I think the original
proposal was (in retrospect) worded too definitive and too detailed. Many
people are falling over the fact that the proposal asserts that only 4
archs remain and most people keep repeating that "we are dropping 8 archs"
like that's the key of the proposal .

It would have been much better if the proposal was more basic and not as
worked out with concrete percentages and archs falling out. Let's reduce
it to its essence.

The proposal actually is that the Debian project needs to put some demands
in place for any architecture to be a part of the release. Now this is not
really the case, so if an architecture keeps lagging behind for some
reason, it delays everything. We need some minimal quality standards for
an arch to be included.

Example minimal quality standards:
- it should have a large part of the packages built
- there should be enough buildds to keep up with security and new uploads
  within reasonable time.
- there should be some minimal team to support this architecture
Any arch / porting team that satisfies our demands can be included.

I honestly think that we (almost) all agree that putting these kind of
demands in place is not too much to ask. What exactly the thresholds
should be, that's a point of discussion. Let's first start to see whether
we agree that putting these demands on an arch this is neccessary to
remain our overall quality. we could then, if we do, start working on
drafting up the exact demands and parameters.


Thijs


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

Re: Security support for tier-2

[Matthias Urlichs]

Hi, Brian Nelson wrote:

> If they come to a
> conclusion that it's impossible to make timely releases and keep all of
> these architectures in a single archive, then that's their decision to
> make.

True. *If*. However, AFAIK they haven't done that yet.

> If you care enough about a particular SSC arch, go create
> your own stable releases on it based on the official Debian release.

I'd like to find a middle ground between "nothing changes" (bad, according
to the FTP and security people) and "$ARCH is completely on its own" (bad,
according to some other people).

The reasoning of both groups has been amply exhibited in this thread.

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

[cobaco (aka Bart Cornelis)]

On Tuesday 15 March 2005 22:42, Brian Nelson wrote:
> On Tue, Mar 15, 2005 at 10:26:58PM +0100, Ola Lundqvist wrote:
> > Hello
> >
> > As most people in this threas have expressed lot of bad feelings about
> > this. I must tell that I think this proposal is a good step toward
> > quicker releases etc.
> >
> > With the clarifications (see the new thread) I must say that this
> > is a very sane proposal.
> >
> > Some people tend to think the worst of everything. If you look at this
> > proposal as a proposal and with the intention to make things working
> > in a good way, I think this proposal is one of the best ones in a
> > very long time.
>
> I agree.  It's become quite evident that Debian is barely able to make
> releases at all with the status quo.  
what status quo? We went from:
- 1 RM to a release team
- lots of kernel source package to 1 kernel source package (per 
kernel-version)
- kernel being maintained by lone maintainer to kernel being maintained by 
team
- unmaintanable installer that nobody wanted to work on, to great new 
installer with lots of people working on it 
- we updated some of the infrastructre were that was necessary

All of these are considerable improvements, that should I think help us make 
new releases easier, things are improving
 
> And, given a choice between having 
> no stable releases at all and having stable releases of a significantly
> reduced number of arches, I'd gladly choose the latter.
Do we have scalability problems -> yes 

Is it clear that those problems are fundamentally unsolvable (and hence we'd 
need to limit the number of architectures) -> not at all

> What baffles me is why so many seem to miss this point and instead have
> decided to turn it into a religious flame war.
we haven't missed the point:
- namely we need to release in a somewhat predictable time frame (only 
releasing once every 2, (or even 3) years is not the main problem, the 
problem is that we spend over a year saying we'll release RSN and )

-> lots of people just disagree that with how the Vancouver proposal goes 
about solving the problem
-- 
Cheers, cobaco (aka Bart Cornelis)
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)


pgpE1suGU0BZz.pgp
Description: PGP signature

Re: SCC proposal (was: Re: Questions for the DPL candidates)

[Adrian Bunk]

On Mon, Mar 14, 2005 at 04:06:35PM -0800, Thomas Bushnell BSG wrote:
> 
> I am of the opinion that the testing distribution has been a great
> help in releasing.
>...

Is this just a personal opinion or backed by any objective evaluation?

I'm asking because as I've already expressed my impression is that if 
testing was completely dumped, many of the issues leading to this 
dropping of several architectures wouldn't exist.

> Thomas

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Brian Nelson <[EMAIL PROTECTED]> writes:

> Can we *please* ban Ingo from d-d?  He's been a huge pain in the ass on
> this list for months now, has absolutely nothing constructive to
> contribute, and is actively trying to subvert the project.

For what it's worth, I second this request.

-- 
  ,''`.
 : :' :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: Alternative: Source-Centric Approach [w/code]

[John Goerzen]

On Tue, Mar 15, 2005 at 11:14:50PM +0100, Matthias Urlichs wrote:
> Hi, John Goerzen wrote:
> 
> >  This specific proposal, for instance, is meant to
> > provide us with a way forward that addresses the main concerns while
> > still producing a quality, usable result for our users.
> 
> It won't work that well for slower architectures, for the very simple
> reason that compiling everything would take a long time.

It may be that m68k is one arch that should ship with .debs, for this
very reason.

-- John


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

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

[Matthias Urlichs]

Hi, John Goerzen wrote:

>  This specific proposal, for instance, is meant to
> provide us with a way forward that addresses the main concerns while
> still producing a quality, usable result for our users.

It won't work that well for slower architectures, for the very simple
reason that compiling everything would take a long time.

m68k (as the admittedly extreme example) doesn't have ten buildd boxes
just because we feel like it. :-)

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

Vancouver hierarchy - proposed terminology

[Henning Makholm]

The debate is being hard to follow, with tiers, classes of citizenship
and several other distinctions being tossed about, and not always
clearly mapped to a particular one of the two divisions in the plan.
I propose the following terminology (also paraphrasing the outline of
the plan according to my understanding):

1. A MEMBER architecture is one that the upload queue scripts knows
   what to do about. The criteria for being a MEMBER are
 - must provide basic Unix functionality
 - must have a working buildd
 - must have X users, Y of which must be DDs
 - (et cetera)

2. MEMBER architectures are divided into IRREGULAR and REGULAR
   architectures. REGULAR architectures make stable releases in
   lock-step; thus problems on one REGULAR architecture can block
   the release of all others. The release process for REGULAR
   architectures is controlled by the DPL-appointed release team,
   currently using the "testing" suite as a common staging area.
   The criteria for being REGULAR are
 - must be a MEMBER
 - must have a working installer
 - must have redundant buildd capacity
 - (et cetera)

   An IRREGULAR architecture either does not make releases, or release
   according to a schedule that does not match the REGULAR one. (One
   possible instance of this is "we'll try to parallel the REGULAR
   release, but they are not going to wait for us if we blow a tyre
   along the way"). The porters must provide their own release
   management and staging area (management).

3. Certain REGULAR architectures are sufficiently in demand that they
   will distributed through the entire official mirror network. They
   are WIDESPREAD architectures.
   The criteria for being WIDESPREAD is that the ftpmasters judge that
   there is sufficient demand for download bandwidth to justify
   mirroring (either by the 10% rule or something else).
   
   Architectures that are not found on primary mirrors are
   NARROWSPREAD ones. They have aptable repositories somewhere in
   *.debian.org and are mirrored only by freak idealists with too much
   disk space for their own good. They can be either REGULAR or
   IRREGULAR.

   Neither users nor developers will notice much difference between
   WIDESPREAD and REGULAR NARROWSPREAD architectures once they have
   pointed their sources.list to an appropriate server.



(Or, as alternative alternative terminology:
  Widespread   -> "utlanning"
  Narrowspread regular -> "framling"
  Irregular-> "ramen"
  Other unix-like OSes -> "varelse"
  Microsoft Windows-> "djur"
)

-- 
Henning Makholm "Jeg forstår mig på at anvende sådanne midler på
   folks legemer, at jeg kan varme eller afkøle dem,
som jeg vil, og få dem til at kaste op, hvis det er det,
  jeg vil, eller give afføring og meget andet af den slags."


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

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

[Stephen Gran]

This one time, at band camp, Stephen Frost said:
> * Stephen Gran ([EMAIL PROTECTED]) wrote:
> > This one time, at band camp, Stephen Frost said:
> 
> > The clarification made it fairly clear to me that if this is
> > achieved by the porter team running clusters with distcc and magic
> > smoke, and has a back bedroom full of spare parts, that should
> > satisfy the criteria.  The point was that Debian's core
> > infrastructure shouldn't be responsible for limping along a dead
> > architecture that is essentially unavailable, and that security
> > fixes and the like have to be done in a more timely manner.
> 
> Ah, now here's a new one that I'm going to have to ask you to clarify:
> What is "Debian's core infrastructure"?  Is that wanna-build access?
> Is that all the buildds?  Only buildds for some archs, what archs, why
> those archs?  I think wanna-build access and the ability to upload
> packages are important things an arch needs to be able to do.  I think
> having testing and stable is important too.  I can understand *some*
> criteria for getting access to these resources (5 DDs willing to sign
> off on the arch, at least 2 buildds, whatever) but not those outlined
> above...

I interpreted 'core infrastructure' to mean something more like 'RM
brainspace' or something.  The actual technical side of it is something
we have historically been good at solving, as others have pointed out.
If we _are_ that good (and I think in general we are), and we're still
having a hard time, a line has to be drawn somewhere, and that somewhere
is apparently being drawn at the point of admin overload.  It doesn't
seem like an unreasonable line to me.

If there is a basically doorstop architecture, say a Wang word
processor, that someone wants to run Debian on, then feel free.  Just
don't expect the release team to coordinate security uploads,
continuously massage buildd's and testing runs and so forth for you, was
my interpretation.  It seems like the people who came up with this
proposal have been saying over and over that if the porter teams have
their act together, they can release like everyone else, and they use
amd64 of what they would like to see over and over.  If the amd64 crew
can pull it off, I think an established port should have an easier time
maintaining itself.

> > I see no reason why a team of interested individuals can't make this
> > happen - magic smoke is cheap, after all :)
> 
> It's still not entirely clear that distcc is the solution to the
> problem here.  Additionally, I'd rather have DSAs for things as they
> become available than forcing us to wait till all archs are done to
> make a DSA, in general.  If that takes care of the N <= 2 requirement,
> then great.

I don't think that is very helpful to those who run production machines
on sparc or alpha or $arch, though, and that is the point of this whole
discussion.  What architectures are going to do a good enough job that
they can be supported in the manner that users deserve to be supported?
I would love to see all the architectures currently supported, and a
whole host of others that I have never heard of, get shipped with etch.
It can happen, it will just take some work.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


pgpnYvtHeRxsM.pgp
Description: PGP signature

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

[Mark Brown]

On Tue, Mar 15, 2005 at 11:01:06PM +0100, Adrian Bunk wrote:

> On some mirrors?
> -> Not all mirrors have to mirror all ports.

The mirroring part of the proposal is effectively just a proposal to
rearrange the archive in order to make this easy for mirror admins.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

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

[John Goerzen]

On Tue, Mar 15, 2005 at 10:45:45PM +0100, Ola Lundqvist wrote:
> Hello
> 
> > distribute for a SO arch).  Anything past that is there just for QA
> > purposes -- to make sure packages are buildable on these archs, and
> > would be optional.
> 
> This is the problem. How do you make sure that the package is buildable
> on the architecture without building it? And if you have built it why not

Well, how do you make sure that the package is runnable on the
architecture without running it?

Yes, it's a bit less testing, but OTOH, if nobody notices that the
package can't be installed, that says something.

> > The problem of syncing with testing is also reduced; now we need only
> > make sure base is synced across archs.
> 
> What you really are saying that for some arches we only support base
> and essential (and some more). Everything else is provided as source debs
> and not supported, even if it might work. I mean the source is available
> currently and the only thing you say is that we should only build some
> parts of that port.

No, I'm not commenting on suport.  I'm just commenting on what .debs are
out there and autobuilt.  I want everything else to stay the same.

However, the job of supporting n archs for things like security updates
is reduced to the job of supporting 1 source package.

> >  * Difficulty of dealing with dependency loops
> >(possible solution: include one .deb from each loop in the dist)
> >  
> >  * Disk space requirements to build packages
> 
>  * Not possible to tell if a package is buildable on a specific arch or not.
 ^ in advance

Yes, that is a downside.

> > So, what do you think?  Could this work?
> 
> Nice idea, but I do not really see the benefit, more than on ftp disk space
> and security update speed.

Also with the testing synchronization.  But then, these three are the
main problems we've been told about, right? :-)

-- John


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

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

[Marc Singer]

On Tue, Mar 15, 2005 at 10:45:45PM +0100, Ola Lundqvist wrote:
> > The speed of buildd systems mostly becomes irrelevant.  They will
> > still have to keep up with base (the set of .debs that we do
> > distribute for a SO arch).  Anything past that is there just for QA
> > purposes -- to make sure packages are buildable on these archs, and
> > would be optional.
> 
> This is the problem. How do you make sure that the package is buildable
> on the architecture without building it? And if you have built it why not
> just add it to the archives. :) So you still need a buildd. :(

Not necessarily.  I think if we make it easy for end users to perform
selective builds we have a chance of making it work.

> > So, what do you think?  Could this work?
> 
> Nice idea, but I do not really see the benefit, more than on ftp disk space
> and security update speed.

While I would like to *not* see a change to the build structure, I
agree that removing lesser used arch's from the testing & guaranteed
support infrastructure gives room for higher frequency releases.
IMHO, the disk space issue is a red herring.  Security updates, too,
are not the primary concern, it's getting all of the cats out the door
with some frequency.


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

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

[Adrian Bunk]

On Tue, Mar 15, 2005 at 04:55:08PM -0500, Alec Berryman wrote:
> Ola Lundqvist on 2005-03-15 22:45:45 +0100:
> 
> > This is the problem. How do you make sure that the package is
> > buildable on the architecture without building it? And if you have
> > built it why not just add it to the archives. :) So you still need a
> > buildd. :(
> 
> Why not add it to the archives?  Because there isn't enough disk space.

Where exactly isn't enough space?

On Debian servers?
-> There'd be enough money for new disks or even new servers.

On some mirrors?
-> Not all mirrors have to mirror all ports.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

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

[Alec Berryman]

Ola Lundqvist on 2005-03-15 22:45:45 +0100:

> This is the problem. How do you make sure that the package is
> buildable on the architecture without building it? And if you have
> built it why not just add it to the archives. :) So you still need a
> buildd. :(

Why not add it to the archives?  Because there isn't enough disk space.



pgpbzpDrgpQQb.pgp
Description: PGP signature

Social pressure on mailing lists (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Matthew Garrett]

Norbert Tretkowski <[EMAIL PROTECTED]> wrote:
> * Ingo Juergensmann wrote:
>> Your wording is not on a level I would expect from a DD. 
> 
> And especially not on a level I would expect from someone who runs for
> DPL.

Ok. It's probably the case that I went too far there, and I do apologise
for that. However, I /do/ think we need to be more willing to apply
social pressure against people whose sole contribution to mailing lists
is to disrupt them. The status-quo is plainly not desperately helpful,
and I'm not a fan of using technical or policy measures as anything
other than an absolutely final resort.

(m-f-t -project - this isn't a technical discussion)
-- 
Matthew Garrett | [EMAIL PROTECTED]


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

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

[Stephen Frost]

* Brian Nelson ([EMAIL PROTECTED]) wrote:
> I agree.  It's become quite evident that Debian is barely able to make
> releases at all with the status quo.  And, given a choice between having
> no stable releases at all and having stable releases of a significantly
> reduced number of arches, I'd gladly choose the latter.
> 
> What baffles me is why so many seem to miss this point and instead have
> decided to turn it into a religious flame war.

I'm not sure that we've entirely missed the point as much as we like to
think there's a better solution than dropping all but 4 archs.  We're
then frustrated that instead of being given reasons for the change we
were given rules.  It's difficult to come up with a solution to a rule.

Stephen


signature.asc
Description: Digital signature

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

[Ola Lundqvist]

Hello

On Tue, Mar 15, 2005 at 11:25:23AM -0600, John Goerzen wrote:
> As I have been reading the discussions about the SCC proposal for
> etch, it seems that these are the main problems:
> 
> 1) Difficulty with, and speed of, buildd systems
> 
> 2) Difficulty of syncing testing across all archs given #1
> 
> 3) Difficulty getting security releases out in time, given slow archs
> 
> 4) Space constraints on mirrors
> 
> I'm throwing out a different idea, and I'm backing it up with code.  I
> have thought about it some, maybe there are huge holes, but let's see.
> 
> I propose that we split things along these lines: binary+source (B+S)
> archs and source-only (SO) archs.

As you probably know it has been expressed before.

> B+S archs will be essentially like we have now -- .debs and sources
> for every package in Debian are available.
> 
> SO archs will be handled exactly like we do now, EXCEPT that we will
> not distribute .debs for most packages.  I expect that we will
> distribute .debs for base and build-essential, mainly -- the minimum
> someone needs to install a working system and build more packages.

Might be a good alternative, but see below.

> What will that mean for our problems?
> 
> The speed of buildd systems mostly becomes irrelevant.  They will
> still have to keep up with base (the set of .debs that we do
> distribute for a SO arch).  Anything past that is there just for QA
> purposes -- to make sure packages are buildable on these archs, and
> would be optional.

This is the problem. How do you make sure that the package is buildable
on the architecture without building it? And if you have built it why not
just add it to the archives. :) So you still need a buildd. :(

> The problem of syncing with testing is also reduced; now we need only
> make sure base is synced across archs.

What you really are saying that for some arches we only support base
and essential (and some more). Everything else is provided as source debs
and not supported, even if it might work. I mean the source is available
currently and the only thing you say is that we should only build some
parts of that port.

> The problem of getting security releases out in time is also reduced;
> source packages are enough for these archs.  If there's a hole in a
> base package, we'd want to provide .debs for everyone, but these
> packages aren't going to be the KDE-style mammoth ones.

This will help yes.

> And finally, this would be a huge win for mirrors.  We would have far
> fewer space constraints, and adding a new arch would be easier.
> 
> What would this mean for users?
> 
> Basically, packages install slower on these archs.  I have developed a
> demonstration tool called srcinst, available from
> http://people.debian.org/~jgoerzen/srcinst/.  srcinst is capable of
> filling all of a package's dependencies and build-depencies solely
> from source.  It will use apt-get -b source to build .debs, then
> evaluate (and build, if necessary) their deps, then install them with
> dpkg -i.  In short, very similar to apt-get install, except it never
> downloads a .deb from anywhere for any reason.  (Most other tools
> don't go this far, and still require .deb downloads for build-deps, or
> don't handle deps at all)

Nice.

> This gives us the benefits of smaller mirror infrastructure that
> projects like Gentoo have, while still maintaining all the advantages
> of dpkg/apt.
> 
> What are some downsides?
> 
> I can see a few:
> 
>  * Longer package install times, obviously
> 
>  * Difficulty of dealing with dependency loops
>(possible solution: include one .deb from each loop in the dist)
>  
>  * Disk space requirements to build packages

 * Not possible to tell if a package is buildable on a specific arch or not.

> More on srcinst:
> 
> Here's an example for epic4, which looks like this:
> 
> Depends: libc6 (>= 2.3.2.ds1-4), libncurses5 (>= 5.4-1), libssl0.9.7,
> epic4-help (>= 1:1.1.7.20020907)
> Build-Depends: debhelper (>= 3.4.8), libncurses5-dev, libssl-dev
> 
> Let's assume I have libssl-dev installed and libc6 installed, but no
> ncurses5.
> 
> So, I run "srcinst install epic4".  Here's what it does:
> 
> 1. Looks at the build-depends, sees that we are missing
>libncurses5-dev.  So:
>a. Grab and build the source package corresponding to
>   libncurses5-dev.
>b. Examine the deps in libncurses5-dev.deb.  Notice that it deps
>   on libncurses5 (which we just built), so dkpg -i libncurses5
>   and then dpkg -i libncurses5-dev.
> 2. Build epic4 itself.
> 3. Look at the deps in the epic4 .deb.  Notice that it deps on
>epic4-help.
> 4. Build and install epic4-help.
> 5. Install epic4.
> 
> The srcinst code is very hackish, ugly, and quick.  I just wrote it
> since yesterday as a proof of concept.  So:
> 
>  * Make sure yuo rnu it as root (no support for fakeroot/sudo yet)
> 
>  * It can't resolve dep loops
> 
>  * It can't handle !arch strings in deps accurately
> 
>  * It spews debugging info to st

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

[Sebastian Ley]

* Steve Langasek wrote:

> The much larger consequence of this meeting, however, has been the
> crafting of a prospective release plan for etch.

Thanks to the team for your work on that. I support the direction of the 
proposal itself (modulo minor issues) and I hope that Debian reckognizes that 
it is not a shame if such things are worked out in a small team. 

It is plainly impossible to work out such a plan in a reasonable time when 
each and every of our thousand developers wants a say in it. I happily 
delegate my voice to a small team for quick and high quality decisions.

While I believe that Debians distributed packaging model with the packagers 
being the more or less ultimate authority over decisions regarding the 
package, I like to see a more structured approach when it comes to making 
overall decisions.

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


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

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

[Brian Nelson]

On Tue, Mar 15, 2005 at 10:26:58PM +0100, Ola Lundqvist wrote:
> Hello
> 
> As most people in this threas have expressed lot of bad feelings about
> this. I must tell that I think this proposal is a good step toward
> quicker releases etc.
> 
> With the clarifications (see the new thread) I must say that this
> is a very sane proposal.
> 
> Some people tend to think the worst of everything. If you look at this
> proposal as a proposal and with the intention to make things working
> in a good way, I think this proposal is one of the best ones in a
> very long time.

I agree.  It's become quite evident that Debian is barely able to make
releases at all with the status quo.  And, given a choice between having
no stable releases at all and having stable releases of a significantly
reduced number of arches, I'd gladly choose the latter.

What baffles me is why so many seem to miss this point and instead have
decided to turn it into a religious flame war.

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.


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