FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 03-27-2011, 11:27 AM
Roger Leigh
 
Default Meeting Minutes, FTPMaster meeting March 2011

On Sun, Mar 27, 2011 at 10:56:28AM +0200, Joerg Jaspert wrote:

Just wanted to say congratulations to you all for for getting so much
great stuff done in such a short time, and many thanks for all your
hard work; it's much appreciated!

> - The long standing project of enabling autosigning for the buildds also
> got finished. That means that packages successfully built can now be
> uploaded automatically, without waiting for the buildd admin to wake
> up/come back from holiday/whatever.

Fantastic news. What's the expected turnaround time between building
and having it available in incoming/the main archive?

> - Added binary-all dists files. This was after discussion with buildd
> people (Phil) regarding how "Architecture: all" autobuilding might be
> able to work in future. We've let it go onto the main mirror network
> in case other people have use for the information. The rationale is
> that the arch-dependent packages files sometimes lag in their .all deb
> versions in order to maintain installability of packages which are
> waiting for architecture specific debs. The binary-all metadata will
> always contain the latest versions of the .all packages, thus allowing
> wanna-build to work out what needs doing. This is, of course, just a
> first step towards being able to build .all debs on the buildds.

Is there any prospect for phasing out Architecture: all packages in
binary-foo Packages in favour of binary-all Packages use by apt-get/
aptitude?

I would also have a use of binary-all dist in sbuild-db (an experimental
wanna-build replacement using PostgreSQL 9.0), just for the record.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 03-27-2011, 11:49 AM
Carsten Hey
 
Default Meeting Minutes, FTPMaster meeting March 2011

Hi,

are there any news about leaf packages and the new field "mainpackage:"?
If so, will Wheezy contain packages using this new field?


Did you decide about throwing away DD built binaries?


* Joerg Jaspert [2011-03-27 10:56 +0200]:
> - We had some discussion about accepting ddebs into the archive but it
> needs major changes to dak. We might accept them into experimental as
> a first step for early testing but there is no code yet to support
> this.

I assume you strongly prefer implementing ddebs the way it was worked on
during a Google summer of code 2009 project (which was the only sane
long-term solution for Debian before throwing away uploaded binary
packages was discussed) over the way Ubuntu generates ddebs since a few
years. Is this correct?


The related questions Emil Langrock asked in [1] are still open:
| What is the direction we should follow for Wheezy[5]? Should we remove
| our special -dbg packages or at least stop to create new -dbg
| packages?


Regards
Carsten

[1] http://lists.debian.org/debian-devel/2011/03/msg00376.html


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110327114938.GA25409@furrball.stateful.de">http://lists.debian.org/20110327114938.GA25409@furrball.stateful.de
 
Old 03-27-2011, 12:44 PM
Philipp Kern
 
Default Meeting Minutes, FTPMaster meeting March 2011

On 2011-03-27, Roger Leigh <rleigh@codelibre.net> wrote:
>> - The long standing project of enabling autosigning for the buildds also
>> got finished. That means that packages successfully built can now be
>> uploaded automatically, without waiting for the buildd admin to wake
>> up/come back from holiday/whatever.
> Fantastic news. What's the expected turnaround time between building
> and having it available in incoming/the main archive?

Builds will be signed automatically post-build and moved to the buildd-local
upload queue, which is processed every 15 minutes. process-unchecked
runs every 15 minutes, too, as far as I know, so they should be available
within 30 minutes for other package builds if the package isn't insanely
large. Maybe an hour at worst, if we hit the queue during dinstall.

> Is there any prospect for phasing out Architecture: all packages in
> binary-foo Packages in favour of binary-all Packages use by apt-get/
> aptitude?

That doesn't make sense. The current set of arch:all packages in binary-foo is
there for a reason. (In fact certain older arch:all binaries are held
availabl/held backe in it if the new package isn't built yet for an
architecture. Which is also the reason why we need binary-all after all, it's
not guaranteed that we see all arch:all packages in the union of the Packages
files of all architectures.)

Kind regards
Philipp Kern


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrniouc9c.vkj.trash@kelgar.0x539.de">http://lists.debian.org/slrniouc9c.vkj.trash@kelgar.0x539.de


Sun Mar 27 15:30:02 2011
Return-path: <gentoo-dev+bounces-45018-tom=linux-archive.org@lists.gentoo.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Sun, 27 Mar 2011 14:34:25 +0300
Received: from pigeon.gentoo.org ([208.92.234.80]:35804 helo=lists.gentoo.org)
by s2.java-tips.org with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.69)
(envelope-from <gentoo-dev+bounces-45018-tom=linux-archive.org@lists.gentoo.org>)
id 1Q3oEj-0002fX-D4
for tom@linux-archive.org; Sun, 27 Mar 2011 14:34:25 +0300
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 7B98BE080A;
Sun, 27 Mar 2011 12:48:46 +0000 (UTC)
X-Original-To: gentoo-dev@lists.gentoo.org
Delivered-To: gentoo-dev@lists.gentoo.org
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
by pigeon.gentoo.org (Postfix) with ESMTP id 320C6E06F4
for <gentoo-dev@lists.gentoo.org>; Sun, 27 Mar 2011 12:47:03 +0000 (UTC)
Received: from [192.168.178.58] (e178092056.adsl.alicedsl.de [85.178.92.56])
(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
(No client certificate requested)
(Authenticated sender: chithanh)
by smtp.gentoo.org (Postfix) with ESMTPSA id 37EC21B401D
for <gentoo-dev@lists.gentoo.org>; Sun, 27 Mar 2011 12:47:02 +0000 (UTC)
Message-ID: <4D8F31B5.2040708@gentoo.org>
Date: Sun, 27 Mar 2011 14:46:45 +0200
From: =?UTF-8?B?Q2jDrS1UaGFuaCBDaHJpc3RvcGhlciBOZ3V54buFbg==?=
<chithanh@gentoo.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.17) Gecko/20110312 Gentoo/2.0.12 SeaMonkey/2.0.12
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] FYI: USE="hal" masked in base/use.mask and related
References: <4D8EF6F0.8040500@gentoo.org>
In-Reply-To: <4D8EF6F0.8040500@gentoo.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Samuli Suominen schrieb:
> Also, both udisks and upower now have blockers for sys-apps/hal to
> prevent overlapping features.
> =20

The result of this is that KDE and Gnome are now not installable at the=20
same time on a stable system.


Best regards,
Ch=C3=AD-Thanh Christopher Nguy=E1=BB=85n
 
Old 03-27-2011, 12:59 PM
Kurt Roeckx
 
Default Meeting Minutes, FTPMaster meeting March 2011

On Sun, Mar 27, 2011 at 12:27:15PM +0100, Roger Leigh wrote:
> On Sun, Mar 27, 2011 at 10:56:28AM +0200, Joerg Jaspert wrote:
> > - The long standing project of enabling autosigning for the buildds also
> > got finished. That means that packages successfully built can now be
> > uploaded automatically, without waiting for the buildd admin to wake
> > up/come back from holiday/whatever.
>
> Fantastic news. What's the expected turnaround time between building
> and having it available in incoming/the main archive?

It gets moved to the upload directory directly after it has been
built and signed. Every 15 minutes the buildd-uploader is run
from cron. From there on, it's the same time for all uploads.

After it's uploaded the queue deamon needs to process
the upload to move it from the upload queue to unchecked, as far
as I know this happens every 5 minutes. Then every 15 minutes
unchecked gets processed and it's accepted (or rejected, moved to NEW).
This unchecked processing doesn't happen while dinstall is
running.

Once it's accepted it's visible on incoming.debian.org, and the
buildds will also have access to it. You'll have to wait for
the next dinstall and mirror pushes before it's on your mirror.


Kurt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110327125954.GA29414@roeckx.be">http://lists.debian.org/20110327125954.GA29414@roeckx.be
 
Old 03-28-2011, 09:25 AM
Wouter Verhelst
 
Default Meeting Minutes, FTPMaster meeting March 2011

On Sun, Mar 27, 2011 at 10:56:28AM +0200, Joerg Jaspert wrote:
> - The long standing project of enabling autosigning for the buildds also
> got finished. That means that packages successfully built can now be
> uploaded automatically, without waiting for the buildd admin to wake
> up/come back from holiday/whatever. The rules for this are simple
> * the buildd host must be maintained by DSA and have restricted access
> * the key must have a size of 4096 or higher and the private part
> must never leave the buildd
> * the key expires within 120 days
> * there are not more than 2 keys per buildd (so they can do a key
> rollover)
> * no network access during build time/for the build part
>
> We maintain a set of keyrings, one per architecture, together with a
> shell script which allows the wanna-build admins to add and remove
> keys as necessary.

So, AIUI, only members of the wbadm GID can change keys, not any random
buildd admin.

If I'm supposed to be maintaining a buildd host, I should be able to
update the key allowed for signing, or I can't do my job properly. We've
had a situation where only a limited group of people could activate
buildd machines in the past, and it was broken; I have no desire to get
back to that situation.

Please fix this by doing one of
- Adding me (and other buildd admins) to the wbadm group,
- Creating a new GID to which all buildd admins are added (I'd suggest
'builddadm' for that, but apparently that's already taken and is 100%
the same as wbadm; if that isn't used, however, it could make sense)
which would limit who can update keys
- Changing the GID to "Debian", rather than anything else (I don't think
you lose much by doing that, but I guess there might be reasons not
to, and it's not my call anyway)
- Finding someone else to maintain praetorius and voltaire

For clarity, the last option is *not* my preference. However, if none of
the other three are done, I'm no longer interested in spending my time
doing something I can't do properly anyway. I've been forced to work
around not being able to fix issues with connectivity between my buildd
host and the rest of the Debian infrastructure in the past, and I won't
stand for it anymore.

Thanks,

--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html
 
Old 03-28-2011, 09:54 AM
Stefano Zacchiroli
 
Default Meeting Minutes, FTPMaster meeting March 2011

On Sun, Mar 27, 2011 at 10:56:28AM +0200, Joerg Jaspert wrote:
> Hello world,
>
> as previously announced[1] we had a FTPMaster meeting in the
> LinuxHotel[2] in Essen during the week from March 21st till 27th. While
> there have been[3] quite[4] a number[5] of blog[6] posts[7] about this
> meeting[8], a more formal set of minutes seems to be called for, so here
> we go.

Hello FTP {masters,assistants,fanboys}, DSA, buildd admins, etc.,
thanks for your frenetic hacking week and for the way in which you've
kept the rest of the Debian community up to date with what was going on.

For even more transparency, and its durability in time, I've updated the
sprint wiki page http://wiki.debian.org/Sprints/2011/FtpMasterSprint
with pointers to your agenda, reports, blog posts, etc. Please review it
to check I haven't overlooked anything.

(Shameless plug: sprints and their transparency are very important for
Debian to get work done and avoid the risks of cabal-ish
meetings. That's why I routinely ask sprint participants to help me out
in maintaining the information at http://wiki.debian.org/Sprints
current. It's working well, but it still is quite an amount of work. If
anyone out there is willing to help in sprint organization and
documentation, I would *love* that. Please mail me at <leader@d.o> if
you'd like to *volunteer* as a little sprint organization helper.)

> And before we finally bore you with the details of our work, let us tell
> you that there is again a good reason to send condolences to one of our
> team members. Similar to our last meeting where we took the opportunity
> to welcome a new FTPMaster, we are now torturing Ansgar Burchardt,
> having made him FTP Assistant. And like our last promotion - he also
> didn't run away screaming.

Condolences^W Welcome on board, Ansgar!

> If you want to access the database on ries, use psql service=projectb,
> it will do the right thing for you. Should you use projectb access for
> one of your own projects, to gather whatever data it provides, keep in
> mind that we do not guarantee any kind of schema stability there. But if
> you can specify your needs we can always think about creating a view for
> you - or exporting the data in a defined format like
> RFC822/Yaml/whatever if it makes more sense or a direct projectb access
> is impractical. Just talk to us.

As I routinely end participating in discussions with DDs saying
"ProjectB-what?", I've mentioned this at http://wiki.debian.org/ProjectB
and linked it from the FTPMaster wiki page. If you have suggestions on
where to better document it please let me know or, better, provide
patches!

> This is, of course, just a first step towards being able to build
> .all debs on the buildds.

Related to this, in your agendas you did mention the topic of "throwaway
DD built .debs". I understand from the minutes that no specific hacking
on that has been done (understandably given how much other stuff has
been going on!), but have you advanced on the design of that? I believe
it's a very important technical advancement we need to guarantee all
packages are built equally. Do you have any other news to share about
that?

> - A dak package to upload into unstable. Although that's coming Real
> Soon Now, honest (especially as one of the ftpteam needs it...).

Neat!

Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
 
Old 03-28-2011, 11:26 AM
"Joerg Jaspert"
 
Default Meeting Minutes, FTPMaster meeting March 2011

Hi

>> - The long standing project of enabling autosigning for the buildds also
>> got finished. That means that packages successfully built can now be
>> uploaded automatically, without waiting for the buildd admin to wake
>> up/come back from holiday/whatever. The rules for this are simple
>> * the buildd host must be maintained by DSA and have restricted
>> access
>> * the key must have a size of 4096 or higher and the private part
>> must never leave the buildd
>> * the key expires within 120 days
>> * there are not more than 2 keys per buildd (so they can do a key
>> rollover)
>> * no network access during build time/for the build part
>> We maintain a set of keyrings, one per architecture, together with a
>> shell script which allows the wanna-build admins to add and remove
>> keys as necessary.
> So, AIUI, only members of the wbadm GID can change keys, not any random
> buildd admin.

Correct.

> If I'm supposed to be maintaining a buildd host, I should be able to
> update the key allowed for signing, or I can't do my job properly. We've
> had a situation where only a limited group of people could activate
> buildd machines in the past, and it was broken; I have no desire to get
> back to that situation.

You can do your job properly and you can activate buildd machines. What
you can
not get is an added feature on top slightly easing the workload. I don't
think
this can seriously be called "unable to do the job properly".

Now, this feature does require a whole set of people to do work before
(for example DSA to have the machine DSA maintained and secured up, getting
the ssh keys and w-b access for the buildd, getting access to incoming to
build
stuff from there), and so I really fail to see where "When asking for
ssh/incoming/w-b access, get them to prepare the autosign key" is much of
added trouble?

> Please fix this by doing one of
> - Adding me (and other buildd admins) to the wbadm group,

None of ftpteams call.

> - Creating a new GID to which all buildd admins are added (I'd suggest
> 'builddadm' for that, but apparently that's already taken and is 100%
> the same as wbadm; if that isn't used, however, it could make sense)
> which would limit who can update keys

Also none of ftpteams call, we dont change other peoples groups.

> - Changing the GID to "Debian", rather than anything else (I don't think
> you lose much by doing that, but I guess there might be reasons not
> to, and it's not my call anyway)

Now this won't happen.

> - Finding someone else to maintain praetorius and voltaire

Not my call either, even though I do think that putting it onto this single
feature is a bit over the top.

Basically this is something the people on the buildd site have to fight out
between. What we on the ftp side want is a *limited* set of people who can do
keychanges, that isn't changing too often. wbadm does seem to be a perfect
fit
for this.

> For clarity, the last option is *not* my preference. However, if none of
> the other three are done, I'm no longer interested in spending my time
> doing something I can't do properly anyway. I've been forced to work
> around not being able to fix issues with connectivity between my buildd
> host and the rest of the Debian infrastructure in the past, and I won't
> stand for it anymore.

See above. This is an *additional* thing, any buildd will be able to run even
without this (and someone mentioned you don't like this feature anyways?),
and so you can do your work as properly as you have been able until now,
so suddenly going this high up seems a bit heavy to me. (Especially since
any
serious buildd does need more other bits added and allowed before)

Anyways, as written above, this is mainly an issue for a team I have
nothing in,
deal with them. What ftpmaster wants to have we have stated. How we want
the keys
submitted is a technical issue already dealt with too, so the rest seems to
be a social issue that should be solveable in whatever way.

--
bye Joerg



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 469b12079792e7c91286bd1953a073e2.squirrel@mail.gan neff.de">http://lists.debian.org/469b12079792e7c91286bd1953a073e2.squirrel@mail.gan neff.de
 
Old 03-28-2011, 01:08 PM
Philipp Kern
 
Default Meeting Minutes, FTPMaster meeting March 2011

On Mon, Mar 28, 2011 at 11:25:13AM +0200, Wouter Verhelst wrote:
> On Sun, Mar 27, 2011 at 10:56:28AM +0200, Joerg Jaspert wrote:
> > - The long standing project of enabling autosigning for the buildds also
> > got finished. That means that packages successfully built can now be
> > uploaded automatically, without waiting for the buildd admin to wake
> > up/come back from holiday/whatever. The rules for this are simple
> > * the buildd host must be maintained by DSA and have restricted access
> > * the key must have a size of 4096 or higher and the private part
> > must never leave the buildd
> > * the key expires within 120 days
> > * there are not more than 2 keys per buildd (so they can do a key
> > rollover)
> > * no network access during build time/for the build part
> >
> > We maintain a set of keyrings, one per architecture, together with a
> > shell script which allows the wanna-build admins to add and remove
> > keys as necessary.
> So, AIUI, only members of the wbadm GID can change keys, not any random
> buildd admin.
>
> If I'm supposed to be maintaining a buildd host, I should be able to
> update the key allowed for signing, or I can't do my job properly. We've
> had a situation where only a limited group of people could activate
> buildd machines in the past, and it was broken; I have no desire to get
> back to that situation.

AFAIR you were against autosigning on your buildds. So nothing will change
for you anyway, unless you allow it.

As Joerg said, we still have that problem because only gid=wbadm can
change the ssh keys on grieg. And only gid=ftp-master can change the
list for the hosts allowed to access incoming. (To be fair: DSA now
exports a list of d.o buildds to ftp-master to automatically allow
access to ftp-master's incoming directory and to security-master.)
And you need the machine installed with the buildd profile by DSA in the
first place.

> Please fix this by doing one of
> - Adding me (and other buildd admins) to the wbadm group,
> - Creating a new GID to which all buildd admins are added (I'd suggest
> 'builddadm' for that, but apparently that's already taken and is 100%
> the same as wbadm; if that isn't used, however, it could make sense)
> which would limit who can update keys
> - Changing the GID to "Debian", rather than anything else (I don't think
> you lose much by doing that, but I guess there might be reasons not
> to, and it's not my call anyway)
> - Finding someone else to maintain praetorius and voltaire

The purpose of the wbadm group is the maintainance of the central
wanna-build host. We also control who accesses our infrastructure and
how. That's already the case since years. Do you have any complaint
about the request turnaround time there?

The builddadm group is a group that's allowed to log in to all buildds
and thus is root-equivalent for quite some machines. Thus the two
groups are separated.

The whole key management thing isn't really limited to gid=wbadm by
design, it's just that you need to be able to access ftp-master and
have the key signing key in the admin keyring.

The idea is that we could even do the key rotation bit for you, which
means less work for the buildd admin.

> For clarity, the last option is *not* my preference. However, if none of
> the other three are done, I'm no longer interested in spending my time
> doing something I can't do properly anyway. I've been forced to work
> around not being able to fix issues with connectivity between my buildd
> host and the rest of the Debian infrastructure in the past, and I won't
> stand for it anymore.

I'm not sure why it's more of a problem than it used to be. I'd be sad
to lose you as a buildd admin. I'm not actually sure why you threaten
us with it, though.

Kind regards
Philipp Kern
 
Old 03-28-2011, 02:37 PM
Mark Hymers
 
Default Meeting Minutes, FTPMaster meeting March 2011

On Mon, 28, Mar, 2011 at 11:54:29AM +0200, Stefano Zacchiroli spoke thus..
> Related to this, in your agendas you did mention the topic of "throwaway
> DD built .debs". I understand from the minutes that no specific hacking
> on that has been done (understandably given how much other stuff has
> been going on!), but have you advanced on the design of that? I believe
> it's a very important technical advancement we need to guarantee all
> packages are built equally. Do you have any other news to share about
> that?

Ok, the situation here is the following:

The technical point of view is that source-only uploads are trivially
turned on. Indeed, it's actually possible (as quite a few people know)
to upload only src+all debs now but not src only if your package doesn't
provide an all deb. That's a bit of a discrepancy. As for throwing
away non-all debs, the infrastructure is there, it just needs a
relatively small amount of code to make it happen (it's a config
setting which at the moment just causes a reject with the message "This
code still to be written".

The main decision which needs to be made is whether, as a project, we
want source only uploads or to throw away DD built non-all debs.
There's not entire agreement amongst the ftpmasters about this (I err on
the side of the source-only uploads to avoid making people waste time
and bandwidth but that's not the only opinion). One objection to
source-only is the perception that people will throw untested things at
the buildds and see what sticks. That strikes me as a social problem,
but as a project we probably want to think how to handle it.

Once a decision is made, implementation is easy, but I'd like some form
of consensus before we go down that route.

Oh, and at the moment we'd still need .all debs uploaded and kept,
although as was said in the minutes, Phil Kern was looking into that and
some backend work in dak and dpkg was done to help with it.

Thanks,

Mark

--
Mark Hymers <mhy at debian dot org>

"I never make predictions. I never have and I never will."
Tony Blair
 
Old 03-28-2011, 04:28 PM
Bernd Zeimetz
 
Default Meeting Minutes, FTPMaster meeting March 2011

On 03/28/2011 04:37 PM, Mark Hymers wrote:
> The main decision which needs to be made is whether, as a project, we
> want source only uploads or to throw away DD built non-all debs.
> There's not entire agreement amongst the ftpmasters about this (I err on
> the side of the source-only uploads to avoid making people waste time
> and bandwidth but that's not the only opinion). One objection to
> source-only is the perception that people will throw untested things at
> the buildds and see what sticks. That strikes me as a social problem,
> but as a project we probably want to think how to handle it.

Due to the problem of uploading untested stuff, accidentally or not
accidentally I'd suggest to require uploads of all binary packages
together with the source and throw away the arch:any binary packages
(after passing NEW if necessary).
Also I'd be in favour of throwing away DD built arch:all debs as soon as
soon as building them on the buildds is implemented.

Cheers,

Bernd
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D90B715.8020103@bzed.de">http://lists.debian.org/4D90B715.8020103@bzed.de
 

Thread Tools




All times are GMT. The time now is 09:40 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org