On 26.10.2012 01:13, Peter Miller wrote:
It may be possible to address both concerns in a different way.
1. Implement PPAs. The code is open source, get it working first,
and
enhance it later.
2. DDs and DMs upload source-only to their individual PPA(s). The
PPA
build farm builds the pack
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Le 26/10/2012 02:13, Peter Miller a écrit :
> It may be possible to address both concerns in a different way.
>
> 1. Implement PPAs. The code is open source, get it working first,
> and enhance it later.
>
> 2. DDs and DMs upload source-only to th
It may be possible to address both concerns in a different way.
1. Implement PPAs. The code is open source, get it working first, and
enhance it later.
2. DDs and DMs upload source-only to their individual PPA(s). The PPA
build farm builds the package on all the architectures Debian cares
about
On Sat, 2012-10-20 at 20:10 +0200, Joerg Jaspert wrote:
> > But my point was: if we're going to be dropping the uploaded binary
> in the first
> > place, why do we have to upload it? Source-only uploads would make
> so much more
> > sense.
>
> Only theoretical. Practical it would mean we will have
Le Sun, Oct 21, 2012 at 10:20:39AM +0200, olivier sallou a écrit :
>
> But I really like the idea of sending a binary build that is dropped by the
> build system. It would avoid sending "accidently" (or not) a package that
> does not build at all and uses resources (servers, ...) effortless.
Hi O
Arno Töll debian.org> writes:
> Pretending we had a working concept to throw away binaries and how to
> deal with arch:all packages, why don't we introduce a control/changes
> file flag similar in spirit to "XS-Autobuild: yes" instructing dak not
> to throw away binaries upon explicit request - s
* Joerg Jaspert:
> The most important is being able to deal with arch all packages. And
> worse - arch all packages able to build only on certain
> architectures.
Could we instruct the buildd for the upload architecture to build
arch-all packages, and let the others operate as before? This shoul
* Steve Langasek:
> I am aware that other such packages exist. I just don't think we should
> support them if they can't be bootstrapped properly.
Ocaml is in this category as well, and it addresses it by
bootstrapping off an upstream-provided binary blob. I'm not sure if
this is the right appr
On Sun, Oct 21, 2012 at 10:16:24AM +0800, Chow Loong Jin wrote:
> > There are two main arguments: "why should we upload binaries if they will
> > be discarded anyway" and "if we allow source-only uploads people will
> > upload packages that weren't tested to be buildable".
> > Please don't repeat t
On Sat, Oct 20, 2012 at 06:29:50PM +0200, Bernhard R. Link wrote:
> * Chow Loong Jin [121020 18:10]:
> > The only argument I have seen for binary uploads is to ensure that DDs have
> > built the package prior to uploading it. But as someone else pointed out
> > earlier
> > in the thread, we seem
On 21/10/2012 05:17, Andrey Rahmatullin wrote:
> On Sun, Oct 21, 2012 at 12:10:02AM +0800, Chow Loong Jin wrote:
>> I also think allowing source-only uploads makes for easier contributions,
>> and thus hopefully more contributions.
> Why would it be easier? Surely we still want people
On 21/10/2012 02:10, Joerg Jaspert wrote:
>
> For some more deep insight you might want to talk to Ubuntu people. They
> do allow source-only uploads, and I seem to remember them having written
> that it lead to lots of useless uploads that just can't have been tested.[2]
I am an Ubuntu developer
Le Sat, Oct 20, 2012 at 06:29:50PM +0200, Bernhard R. Link a écrit :
> * Chow Loong Jin [121020 18:10]:
> > The only argument I have seen for binary uploads is to ensure that DDs have
> > built the package prior to uploading it. But as someone else pointed out
> > earlier
> > in the thread, we se
On Sun, Oct 21, 2012 at 12:10:02AM +0800, Chow Loong Jin wrote:
> I also think allowing source-only uploads makes for easier contributions,
> and thus hopefully more contributions.
> >>> Why would it be easier? Surely we still want people to build packages
> >>> first to
> >>> ensure th
* Joerg Jaspert , 2012-10-20, 20:10:
For some more deep insight you might want to talk to Ubuntu people.
They do allow source-only uploads, and I seem to remember them having
written that it lead to lots of useless uploads that just can't have
been tested.
http://lists.debian.org/200911160129
> But my point was: if we're going to be dropping the uploaded binary in the
> first
> place, why do we have to upload it? Source-only uploads would make so much
> more
> sense.
Only theoretical. Practical it would mean we will have many more build
failures.
> The only argument I have seen for
* Chow Loong Jin [121020 18:10]:
> The only argument I have seen for binary uploads is to ensure that DDs have
> built the package prior to uploading it. But as someone else pointed out
> earlier
> in the thread, we seem to be trusting DDs a lot in other aspects, so why not
> trust that they test
On 20/10/2012 22:38, Thomas Goirand wrote:
> On 10/17/2012 09:56 AM, Chow Loong Jin wrote:
>> On 17/10/2012 08:36, Russell Coker wrote:
>>> On Wed, 17 Oct 2012, Barry Warsaw wrote:
I also think allowing source-only uploads makes for easier contributions,
and thus hopefully more contribut
On 10/17/2012 09:56 AM, Chow Loong Jin wrote:
On 17/10/2012 08:36, Russell Coker wrote:
On Wed, 17 Oct 2012, Barry Warsaw wrote:
I also think allowing source-only uploads makes for easier contributions,
and thus hopefully more contributions.
Why would it be easier? Surely we still want peopl
On Thu, 2012-10-18 at 21:30:25 -0500, Peter Samuelson wrote:
> [Joerg Jaspert]
> > As one thing to keep in mind - we have an acl structure in dak.
> > Currently it reads something like
> >
> > all DD keys are allowed all uploads.
> > all DM keys are allowed their own uploads according to DM rights
Peter Samuelson writes:
>> This preserves the ability to upload a manual binNMU, which is not
>> common, but is useful and sometimes necessary. (And not only for
>> bootstrapping an arch or a compiler.)
> ...and I forgot to add that something like this is required by the GR
> http://www.debian.
> This preserves the ability to upload a manual binNMU, which is not
> common, but is useful and sometimes necessary. (And not only for
> bootstrapping an arch or a compiler.)
...and I forgot to add that something like this is required by the GR
http://www.debian.org/vote/2007/vote_002, or at le
[Joerg Jaspert]
> As one thing to keep in mind - we have an acl structure in dak.
> Currently it reads something like
>
> all DD keys are allowed all uploads.
> all DM keys are allowed their own uploads according to DM rights.
> all buildd keys are allowed binary only uploads for their arch.
>
>
On Wed, Oct 17, 2012 at 2:56 AM, Joerg Jaspert wrote:
> On 13001 March 1977, Michael Gilbert wrote:
>
>> So, are we ready to do this?
>
> No.
> Its for after wheezy, definitely.
> Also, there are some open issues to be solved for this to happen.
> The most important is being able to deal with arch
❦ 18 octobre 2012 11:29 CEST, Arno Töll :
> why don't we just let people decide themselves? We already grant every
> DD very liberal upload permissions to the archives because we trust them
> and their capabilities. Hence, I do not think we would like something
> like this despite of dak's suppo
On Thu, 18 Oct 2012, Arno Töll wrote:
> On 18.10.2012 04:29, Paul Wise wrote:
> > On Thu, Oct 18, 2012 at 10:20 AM, Russell Coker wrote:
> >> We could have a lintian warning for any occurance of the string "/home" in
> >> a
> >> packaged file and have error conditions for "/build" and the current
Hi,
On 18.10.2012 10:50, Joerg Jaspert wrote:
> some DDs may upload $listofpackages including binaries.
> all DDs may upload $listofpackages including binaries.
>
> where listofpackages is those insane "needthemself" ones.
> And could be by DD.
>
> However far we want to drive this, we can.
why
> So yes, this is something that should be accounted for if Debian moves to a
> model where binary uploads are discarded and rebuilt. However, I suspect
> that for all the sensible cases, the proposal to add staged-build metadata
> (for bootstrapping circular build-dependencies on new ports) woul
Hi,
On 18.10.2012 04:29, Paul Wise wrote:
> On Thu, Oct 18, 2012 at 10:20 AM, Russell Coker wrote:
>
>> We could have a lintian warning for any occurance of the string "/home" in a
>> packaged file and have error conditions for "/build" and the current value of
>> $HOME for the account running li
On 17-10-12 23:48, Matthias Klose wrote:
> On 17.10.2012 21:49, Steve Langasek wrote:
>> On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote:
>>> Also remeber, there are packages like cmucl that can only be built by the
>>> same upstream release of itself and can currently survive in De
On Thu, Oct 18, 2012 at 10:37 AM, Russell Coker wrote:
> For a warning it doesn't matter much if we have a few false-positives. For
> the error conditions that I suggest for /build and $HOME I find it difficult
> to
> imagine false-positives except the case where a DD uses their own home
> direc
On Thu, 18 Oct 2012, Paul Wise wrote:
> On Thu, Oct 18, 2012 at 10:20 AM, Russell Coker wrote:
> > We could have a lintian warning for any occurance of the string "/home"
> > in a packaged file and have error conditions for "/build" and the
> > current value of $HOME for the account running lintia
On Thu, Oct 18, 2012 at 10:20 AM, Russell Coker wrote:
> We could have a lintian warning for any occurance of the string "/home" in a
> packaged file and have error conditions for "/build" and the current value of
> $HOME for the account running lintian.
Based on a quick grep of /usr/bin on my la
On Thu, 18 Oct 2012, Michael Gilbert wrote:
> Maybe someone would be interested in writing a lintian check for these
> issues? Something a bit more advanced than this
>
> $ strings /sbin/dhclient | grep ^PATH
> PATH=/home/zero79/source/git/isc-dhcp/debian/tmp/usr/sbin:/sbin:/bin:/usr/s
> bin:/us
On Wed, Oct 17, 2012 at 11:48:17PM +0200, Matthias Klose wrote:
> On 17.10.2012 21:49, Steve Langasek wrote:
> > On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote:
> >> Joerg Jaspert writes:
> >>> Its for after wheezy, definitely. Also, there are some open issues to
> >>> be solved f
On 17.10.2012 21:49, Steve Langasek wrote:
> On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote:
>> Joerg Jaspert writes:
>>> Its for after wheezy, definitely. Also, there are some open issues to
>>> be solved for this to happen. The most important is being able to deal
>>> with arch
On Wed, Oct 17, 2012 at 08:56:56AM +0200, Joerg Jaspert wrote:
> Its for after wheezy, definitely.
> Also, there are some open issues to be solved for this to happen.
> The most important is being able to deal with arch all packages. And
> worse - arch all packages able to build only on certain arc
On Wed, Oct 17, 2012 at 05:23:22PM -0400, Michael Gilbert wrote:
> if there is a build path sanitization issue, then if the
> user chooses to rebuild the package they will get their own rogue
> paths. So, yes, we should always fix those issues when they're found,
> but at least for people using bu
On Wed, Oct 17, 2012 at 5:23 PM, Michael Gilbert wrote:
> That is true: if there is a build path sanitization issue, then if the
> user chooses to rebuild the package they will get their own rogue
> paths. So, yes, we should always fix those issues when they're found,
> but at least for people usi
On Wed, Oct 17, 2012 at 4:55 PM, Bernhard R. Link wrote:
> * Michael Gilbert [121017 22:19]:
>> Anyway, reading again, I not sure that your reply actually considers
>> build path sanitization problems, which is what my statement was
>> about.
>
> I'm stating that doing all the builds on buildds wi
* Michael Gilbert [121017 22:19]:
> Anyway, reading again, I not sure that your reply actually considers
> build path sanitization problems, which is what my statement was
> about.
I'm stating that doing all the builds on buildds will not avoid the
need to fix the package. (Unless you are arguing
On Wed, Oct 17, 2012 at 4:07 PM, Bernhard R. Link wrote:
> * Michael Gilbert [121016 04:59]:
>> Anyway, all of these build system path sanitization issues can be
>> eliminated by using the buildds for all architectures, since paths
>> will start with at least /build that requires root-level actio
Paul Tagliamonte writes:
> On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote:
>> Joerg Jaspert writes:
>> > Its for after wheezy, definitely.
>> > Also, there are some open issues to be solved for this to happen.
>> > The most important is being able to deal with arch all packages.
* Michael Gilbert [121016 04:59]:
> Anyway, all of these build system path sanitization issues can be
> eliminated by using the buildds for all architectures, since paths
> will start with at least /build that requires root-level action to
> exist on users' systems.
They are not eliminated by usi
On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote:
> Hi!
>
> Joerg Jaspert writes:
> > Its for after wheezy, definitely.
> > Also, there are some open issues to be solved for this to happen.
> > The most important is being able to deal with arch all packages. And
> > worse - arch al
On 17 October 2012 19:30, Christoph Egger wrote:
> Hi!
>
> Joerg Jaspert writes:
>> Its for after wheezy, definitely.
>> Also, there are some open issues to be solved for this to happen.
>> The most important is being able to deal with arch all packages. And
>> worse - arch all packages able to b
On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote:
> Joerg Jaspert writes:
> > Its for after wheezy, definitely.
> > Also, there are some open issues to be solved for this to happen.
> > The most important is being able to deal with arch all packages. And
> > worse - arch all package
Hi!
Joerg Jaspert writes:
> Its for after wheezy, definitely.
> Also, there are some open issues to be solved for this to happen.
> The most important is being able to deal with arch all packages. And
> worse - arch all packages able to build only on certain architectures.
> But thats outside dak
On Wednesday, October 17, 2012 12:45:14, Wouter Verhelst wrote:
> On Wed, Oct 17, 2012 at 12:28:14PM -0400, Chris Knadle wrote:
> > On Tuesday, October 16, 2012 05:04:55, martin f krafft wrote:
> > > also sprach Holger Levsen [2012.10.16.0945
+0200]:
> > > > > We have not cared enough for almost
On Wed, Oct 17, 2012 at 12:28:14PM -0400, Chris Knadle wrote:
> On Tuesday, October 16, 2012 05:04:55, martin f krafft wrote:
> > also sprach Holger Levsen [2012.10.16.0945 +0200]:
> > > > We have not cared enough for almost 20 years that 9 out of 10 binary
> > > > packages in use (i386 until 2005
On Wed, 17 Oct 2012 12:28:14 -0400
Chris Knadle wrote:
> Out of curiosity, how would a user /know/ whether a package has been built
> via
> a buildd rather than on a DD's local machine?
Check the wannabuild logs for the package. A listing of Installed
without a build log means that the binari
On Tuesday, October 16, 2012 05:04:55, martin f krafft wrote:
> also sprach Holger Levsen [2012.10.16.0945 +0200]:
> > > We have not cared enough for almost 20 years that 9 out of 10 binary
> > > packages in use (i386 until 2005, amd64 since then) are built on
> > > machines that are individually
On 13001 March 1977, Michael Gilbert wrote:
> So, are we ready to do this?
No.
Its for after wheezy, definitely.
Also, there are some open issues to be solved for this to happen.
The most important is being able to deal with arch all packages. And
worse - arch all packages able to build only on c
On 17/10/2012 08:36, Russell Coker wrote:
> On Wed, 17 Oct 2012, Barry Warsaw wrote:
>> I also think allowing source-only uploads makes for easier contributions,
>> and thus hopefully more contributions.
>
> Why would it be easier? Surely we still want people to build packages first
> to
> ens
On Wed, 17 Oct 2012, Barry Warsaw wrote:
> I also think allowing source-only uploads makes for easier contributions,
> and thus hopefully more contributions.
Why would it be easier? Surely we still want people to build packages first to
ensure that we don't needlessly get FTBFS bugs.
--
My Ma
On Oct 16, 2012, at 03:54 PM, Tollef Fog Heen wrote:
>]] Jakub Wilk
>
>> What makes a buildd more secure than a machine of J. Random Developer?
>
>It has a smaller attack surface due to few users, firewalls, few
>packages installed, nobody using it for browsing the web, etc.
I also think allowin
Tollef Fog Heen writes:
> ]] Jakub Wilk
>
>> What makes a buildd more secure than a machine of J. Random Developer?
>
> It has a smaller attack surface due to few users, firewalls, few
> packages installed, nobody using it for browsing the web, etc.
We seem to be forgetting, that the real advan
]] Jakub Wilk
> What makes a buildd more secure than a machine of J. Random Developer?
It has a smaller attack surface due to few users, firewalls, few
packages installed, nobody using it for browsing the web, etc.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends
On Tue, 16 Oct 2012, Arno Töll wrote:
> On 16.10.2012 14:00, Russell Coker wrote:
> > There are a fairly small number of Debian servers. So even if the
> > probability of system compromise for a Debian server was the same as for
> > a laptop owned by a random DD the fact that DD workstations outn
Hi,
On 16.10.2012 14:00, Russell Coker wrote:
> There are a fairly small number of Debian servers. So even if the
> probability
> of system compromise for a Debian server was the same as for a laptop owned
> by
> a random DD the fact that DD workstations outnumber Debian servers by at
> leas
On Tue, 16 Oct 2012, Jakub Wilk wrote:
> * martin f krafft , 2012-10-16, 08:21:
> >>This is my opinion but I admit I have not followed previous
> >>discussions on the subject
> >
> >http://lists.debian.org/debian-security/2004/09/msg00014.html
> >
> >We have not cared enough for almost 20 year
* martin f krafft , 2012-10-16, 08:21:
This is my opinion but I admit I have not followed previous
discussions on the subject
http://lists.debian.org/debian-security/2004/09/msg00014.html
We have not cared enough for almost 20 years that 9 out of 10 binary
packages in use (i386 until 2005
also sprach Holger Levsen [2012.10.16.0945 +0200]:
> > We have not cared enough for almost 20 years that 9 out of 10 binary
> > packages in use (i386 until 2005, amd64 since then) are built on
> > machines that are individually maintained according to widely
> > varying security standards to do an
On Mon, Oct 15, 2012 at 10:59:27PM -0400, Michael Gilbert wrote:
> I know this subject has been discussed on and off in the past, but
> there's new evidence that it's simply the right thing to do.
Nice, although it's not new evidence we need :). The state of last
discussion on the matter is that t
Hi,
On Dienstag, 16. Oktober 2012, martin f krafft wrote:
> We have not cared enough for almost 20 years that 9 out of 10 binary
> packages in use (i386 until 2005, amd64 since then) are built on
> machines that are individually maintained according to widely
> varying security standards to do any
also sprach olivier sallou [2012.10.16.0752 +0200]:
> This is my opinion but I admit I have not followed previous discussions on
> the subject
http://lists.debian.org/debian-security/2004/09/msg00014.html
We have not cared enough for almost 20 years that 9 out of 10 binary
packages in use (i
Le 16 oct. 2012 04:59, "Michael Gilbert" a écrit :
>
> I know this subject has been discussed on and off in the past, but
> there's new evidence that it's simply the right thing to do.
>
> Due to changes in upstream's build system, isc-dhcp recently started
> including build system paths in dhclie
I know this subject has been discussed on and off in the past, but
there's new evidence that it's simply the right thing to do.
Due to changes in upstream's build system, isc-dhcp recently started
including build system paths in dhclient's search path. This got a
security identifier, and we've fi
68 matches
Mail list logo
