-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 their
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
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 many
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
On Sat, Oct 20, 2012 at 06:29:50PM +0200, Bernhard R. Link wrote:
* Chow Loong Jin hyper...@debian.org [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
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 these
* 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
* 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 should
Arno Töll arno at 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 -
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
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 Warsawba...@python.org wrote:
I also think allowing source-only uploads makes for easier contributions,
and thus hopefully more contributions.
Why would it be easier? Surely we
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 Warsawba...@python.org wrote:
I also think allowing source-only uploads makes for easier contributions,
and thus hopefully more
* Chow Loong Jin hyper...@debian.org [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
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
* Joerg Jaspert jo...@debian.org, 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.
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 that we don't
Le Sat, Oct 20, 2012 at 06:29:50PM +0200, Bernhard R. Link a écrit :
* Chow Loong Jin hyper...@debian.org [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
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
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 to build packages
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 Debian
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 lintian.
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) would
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 don't
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 value
of
❦ 18 octobre 2012 11:29 CEST, Arno Töll a...@debian.org :
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
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 all
[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.
It is
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
Peter Samuelson pe...@p12n.org 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
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.
all
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
On Tuesday, October 16, 2012 05:04:55, martin f krafft wrote:
also sprach Holger Levsen hol...@layer-acht.org [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
On Wed, 17 Oct 2012 12:28:14 -0400
Chris Knadle chris.kna...@coredump.us 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
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 hol...@layer-acht.org [2012.10.16.0945 +0200]:
We have not cared enough for almost 20 years that 9 out of 10 binary
packages in use (i386
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 hol...@layer-acht.org [2012.10.16.0945
+0200]:
We have not cared enough
Hi!
Joerg Jaspert jo...@debian.org 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
On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote:
Joerg Jaspert jo...@debian.org 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
On 17 October 2012 19:30, Christoph Egger christ...@debian.org wrote:
Hi!
Joerg Jaspert jo...@debian.org 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 -
On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote:
Hi!
Joerg Jaspert jo...@debian.org 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 -
* Michael Gilbert mgilb...@debian.org [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
Paul Tagliamonte paul...@debian.org writes:
On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote:
Joerg Jaspert jo...@debian.org 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
On Wed, Oct 17, 2012 at 4:07 PM, Bernhard R. Link brl...@debian.org wrote:
* Michael Gilbert mgilb...@debian.org [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
* Michael Gilbert mgilb...@debian.org [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.
On Wed, Oct 17, 2012 at 4:55 PM, Bernhard R. Link wrote:
* Michael Gilbert mgilb...@debian.org [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
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 using
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
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
On 17.10.2012 21:49, Steve Langasek wrote:
On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote:
Joerg Jaspert jo...@debian.org 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
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 jo...@debian.org writes:
Its for after wheezy, definitely. Also, there are some open issues to
be
On Thu, 18 Oct 2012, Michael Gilbert mgilb...@debian.org 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
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 laptop,
On Thu, 18 Oct 2012, Paul Wise p...@debian.org 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
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
directory
also sprach olivier sallou olivier.sal...@gmail.com [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
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
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
also sprach Holger Levsen hol...@layer-acht.org [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
* martin f krafft madd...@debian.org, 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
On Tue, 16 Oct 2012, Jakub Wilk jw...@debian.org wrote:
* martin f krafft madd...@debian.org, 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
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
least
On Tue, 16 Oct 2012, Arno Töll a...@debian.org 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
]] 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
Tollef Fog Heen tfh...@err.no 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
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 allowing
On Wed, 17 Oct 2012, Barry Warsaw ba...@python.org 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
On 17/10/2012 08:36, Russell Coker wrote:
On Wed, 17 Oct 2012, Barry Warsaw ba...@python.org 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
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
Le 16 oct. 2012 04:59, Michael Gilbert mgilb...@debian.org 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
68 matches
Mail list logo
