On May 11, 2013, at 11:15 AM, Scott Kitterman wrote:
Close. Because there is no aging requirement it moves much more quickly and
as a result, there's much less risk of multiple transitions getting entangled
and delayed.
Ubuntu explicitly defines the $ RELEASE-proposed pocket as 'not meant for
Hi,
Am Freitag, den 10.05.2013, 16:05 -0400 schrieb Barry Warsaw:
For the 13.04 release, Ubuntu made a change to its procedure whereby
source-only uploads to the development release (e.g. raring) actually go to
e.g. raring-proposed first. The builds are attempted and only if they
succeed,
Hi!
Barry Warsaw ba...@python.org writes:
For the 13.04 release, Ubuntu made a change to its procedure whereby
source-only uploads to the development release (e.g. raring) actually go to
e.g. raring-proposed first. The builds are attempted and only if they
succeed, pass their autopkgtests,
Hi,
Am Samstag, den 11.05.2013, 12:00 +0200 schrieb Christoph Egger:
Barry Warsaw ba...@python.org writes:
For the 13.04 release, Ubuntu made a change to its procedure whereby
source-only uploads to the development release (e.g. raring) actually go to
e.g. raring-proposed first. The
Joachim Breitner nome...@debian.org wrote:
Hi,
Am Freitag, den 10.05.2013, 16:05 -0400 schrieb Barry Warsaw:
For the 13.04 release, Ubuntu made a change to its procedure whereby
source-only uploads to the development release (e.g. raring) actually
go to
e.g. raring-proposed first. The
Christoph Egger christ...@debian.org wrote:
Hi!
Barry Warsaw ba...@python.org writes:
For the 13.04 release, Ubuntu made a change to its procedure whereby
source-only uploads to the development release (e.g. raring) actually
go to
e.g. raring-proposed first. The builds are attempted and
On May 03, 2013, at 04:38 PM, Josselin Mouette wrote:
- source-only uploads
They are pushed to the buildds, and the produced binaries
(including arch:all) are put in a staging area (much like
incoming.d.o). These binaries can be downloaded, but
the .changes cannot
On May 05, 2013, at 01:12 AM, Roger Leigh wrote:
There's definitely an open bug for adding this, and I'll be happy
for it to be added. It shouldn't be too hard to implement, though
we would probably want to make it configurable whether the repeat
build failing should fail the build as a whole.
On Fri, May 03, 2013 at 04:38:40PM +0200, Josselin Mouette wrote:
Le vendredi 03 mai 2013 à 09:18 +0800, Chow Loong Jin a écrit :
While we're at it, can we also have source-only uploads? Uploading
potentially
huge binary packages that just go to /dev/null seems like a pointless waste
On Fri, May 03, 2013 at 07:11:35PM +0200, Bernhard R. Link wrote:
* Holger Levsen hol...@layer-acht.org [130502 12:28]:
People do this all the time: upload packages built against local packages,
experimental or even on Ubuntu to Debian sid.
/me shivers. This hurts. There is no reason
On Sun, May 05, 2013 at 12:18:44AM +0100, Wookey wrote:
The harder question is how/when to do that QA.
The time to do QA is now and always. Otherwise it just collects and
becomes too much.
I resisted making the
suggestion of doing it by default on all builds as that seemed a step
too far,
* Goswin von Brederlow goswin-...@web.de, 2013-05-08, 11:53:
We already know we can't trust all maintainers to build binaries in a
clean chroot. Nor can we trust them to test binaries they upload. What
makes you think maintainers will not simply blindly create changes
files for buildd build
On Sat, May 04, 2013 at 09:33:14PM +0200, Helmut Grohne wrote:
On Fri, May 03, 2013 at 04:53:59PM +0800, Thomas Goirand wrote:
I think there's a consensus, the problem is who's going
to do the work for automating dropping of binaries and
rebuild.
Not implying that I am the one doing this
On 05/05/2013 03:33 AM, Helmut Grohne wrote:
what needs to be touched to achieve aspects of the following
features: (Again not implying that they are all desired.)
* Permitting source-only uploads.
While there is a consensus about dropping binaries, there is
none about permitting source-only
On Mon, May 06, 2013 at 11:40:50PM +0800, Thomas Goirand wrote:
what needs to be touched to achieve aspects of the following
features: (Again not implying that they are all desired.)
* Permitting source-only uploads.
While there is a consensus about dropping binaries, there is
none about
On 05/04/2013 05:10 PM, Wookey wrote:
This is a result of maintainer's workflows never
doing this, I presume.
Yeah! Probably git-buidpackage getting more adoption
has something to do with it too.
Thomas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
On Mon, May 06, 2013 at 09:49:33PM +0600, Andrey Rahmatullin wrote:
On Mon, May 06, 2013 at 11:40:50PM +0800, Thomas Goirand wrote:
what needs to be touched to achieve aspects of the following
features: (Again not implying that they are all desired.)
* Permitting source-only uploads.
Hi,
On Montag, 6. Mai 2013, Thomas Goirand wrote:
While there is a consensus about dropping binaries, there is
none about permitting source-only uploads (and I'm not in
the favor of it myself, not because I don't trust others, but
because I think it should be possible to add some more QA
Hi,
Am Montag, den 06.05.2013, 16:57 +0200 schrieb Goswin von Brederlow:
Maybe as an intermediate and imediate step we could switch to
uploading only arch:all debs for mixed packages. That is already
supported by DAK and the buildds and would drop a lot of locally build
debs.
sounds
Jakub Wilk jw...@debian.org writes:
* Arto Jantunen vi...@debian.org, 2013-05-03, 11:12:
Source only uploads were banned many years ago, mainly due to problems with
maintainers not even build testing their packages.
[citation needed]
Indeed. I was fairly certain that a policy decision about
+++ brian m. carlson [2013-05-03 21:39 +]:
On Sat, May 04, 2013 at 12:10:25AM +0300, Timo Juhani Lindfors wrote:
Bernhard R. Link brl...@debian.org writes:
Once we drop that and only give people the right to modify the
software we distribute but no longer the possiblity to do so
on
On 04.05.2013 11:10, Wookey wrote:
I am huge fan of both building in clean environments _and_ being able
to build twice. I don't think there is any solution to this other than
testing it in an automated fashion. An sbuild or pbuilder option for
--build-twice would make testing a very simple
* Wookey woo...@wookware.org, 2013-05-04, 10:10:
I am huge fan of both building in clean environments _and_ being able
to build twice. I don't think there is any solution to this other than
testing it in an automated fashion. An sbuild or pbuilder option for
--build-twice would make testing a
Hi,
On 04/05/13 at 10:10 +0100, Wookey wrote:
+++ brian m. carlson [2013-05-03 21:39 +]:
On Sat, May 04, 2013 at 12:10:25AM +0300, Timo Juhani Lindfors wrote:
Bernhard R. Link brl...@debian.org writes:
Once we drop that and only give people the right to modify the
software we
Le 02/05/2013 20:12, Russ Allbery a écrit :
Yes, speaking as someone who has, on several occasions, uploaded arch: all
binary packages with source package problems and not discovered that until
months later via a FTBFS bug from an archive rebuild, I think we should
rebuild all arch: all
Le 04/05/2013 15:37, Xavier Roche a écrit :
something that you can not detect unless you setup a complete chrooted
build environment, which is a bit cumbersome to do)
Replying to myself - I should have pointed out that pbuilder was
actually a really straightforward way to do that (sudo pbuilder
On Sat, May 4, 2013 at 6:09 AM, Jakub Wilk wrote:
We've always treated FTBFS if built twice in a row bugs as important:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;tag=qa-doublebuild
The real question is whether or not there is a consensus within the
project
On Sat, May 4, 2013 at 11:48 AM, Michael Gilbert wrote:
On Sat, May 4, 2013 at 6:09 AM, Jakub Wilk wrote:
We've always treated FTBFS if built twice in a row bugs as important:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;tag=qa-doublebuild
The real question is
On Sat, May 04, 2013 at 11:53:04AM -0400, Michael Gilbert wrote:
We've always treated FTBFS if built twice in a row bugs as important:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;tag=qa-doublebuild
The real question is whether or not there is a consensus
On Sat, May 4, 2013 at 11:58 AM, Andrey Rahmatullin wrote:
On Sat, May 04, 2013 at 11:53:04AM -0400, Michael Gilbert wrote:
We've always treated FTBFS if built twice in a row bugs as important:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;tag=qa-doublebuild
On Sat, May 04, 2013 at 12:05:06PM -0400, Michael Gilbert wrote:
Again, as Thijs argued somewhat eloquently already earlier in this
thread, computational time is not the scarce resource to worry about;
human time is.
The one thing Debian is comfortable about spending money on is
hardware,
On Sat, May 4, 2013 at 12:14 PM, Andrey Rahmatullin wrote:
On Sat, May 04, 2013 at 12:05:06PM -0400, Michael Gilbert wrote:
Again, as Thijs argued somewhat eloquently already earlier in this
thread, computational time is not the scarce resource to worry about;
human time is.
The one thing
]] Michael Gilbert
The one thing Debian is comfortable about spending money on is
hardware, so if we expect to see double build times, then there should
be an associated doubling-down on buildd hardware.
One thing is the cost to buy the hardware. Other costs (monetary or
otherwise) are
On Sb, 04 mai 13, 00:30:00, Ben Hutchings wrote:
I assume you're concerned that there may be undeclared build-
conflicts. But testing in the maintainer's development system is not
a particularly good way to find those. Testing in a maximal
environment (everything with priority = optional,
On Fri, May 03, 2013 at 09:18:36AM +0800, Chow Loong Jin wrote:
While we're at it, can we also have source-only uploads? Uploading
potentially huge binary packages that just go to /dev/null seems like
a pointless waste of bandwidth to me, and the only for argument I've
heard (which I don't
On 04-05-13 17:53, Michael Gilbert wrote:
And/or on the technical side, make the buildds always build twice.
Not Going To Happen[tm] on my buildd hosts.
--
This end should point toward the ground if you want to go to space.
If it starts pointing toward space you are having a bad problem and
On Fri, May 03, 2013 at 04:53:59PM +0800, Thomas Goirand wrote:
I think there's a consensus, the problem is who's going
to do the work for automating dropping of binaries and
rebuild.
Not implying that I am the one doing this work, I would like to learn
more about what needs to be touched to
* Ryan Kavanagh r...@debian.org, 2013-05-04, 13:48:
If Debian and its users trust developers with that kind of
responsibility, it should also be able to trust developers to follow a
basic guideline of Please test-build your package and check the
resulting binary before doing a source-only
+++ Julian Taylor [2013-05-04 11:48 +0200]:
On 04.05.2013 11:10, Wookey wrote:
I am huge fan of both building in clean environments _and_ being able
to build twice. I don't think there is any solution to this other than
testing it in an automated fashion. An sbuild or pbuilder option for
On Sun, May 05, 2013 at 12:18:44AM +0100, Wookey wrote:
+++ Julian Taylor [2013-05-04 11:48 +0200]:
On 04.05.2013 11:10, Wookey wrote:
I am huge fan of both building in clean environments _and_ being able
to build twice. I don't think there is any solution to this other than
On 04/05/13 at 12:27 -0400, Michael Gilbert wrote:
On Sat, May 4, 2013 at 12:14 PM, Andrey Rahmatullin wrote:
On Sat, May 04, 2013 at 12:05:06PM -0400, Michael Gilbert wrote:
Again, as Thijs argued somewhat eloquently already earlier in this
thread, computational time is not the scarce
Andrey Rahmatullin wrote:
Michael Gilbert wrote:
We've always treated FTBFS if built twice in a row bugs as important:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;tag=qa-doublebuild
The real question is whether or not there is a consensus within the
On 05/03/2013 03:18 AM, Chow Loong Jin wrote:
On 02/05/2013 18:48, Neil Williams wrote:
After Wheezy is released, we can talk about throwing away all binary
uploads again... if we can't prevent people doing the wrong thing, we
might have to send bits of what gets uploaded to /dev/null.
On 03/05/2013 15:01, Emilio Pozuelo Monfort wrote:
Isn't that already possible?
It is? I should try that out with my next upload.
--
Kind regards,
Loong Jin
signature.asc
Description: OpenPGP digital signature
Chow Loong Jin hyper...@debian.org writes:
On 03/05/2013 15:01, Emilio Pozuelo Monfort wrote:
Isn't that already possible?
It is? I should try that out with my next upload.
No, it's not. Source only uploads were banned many years ago, mainly due
to problems with maintainers not even build
On 03/05/2013 16:12, Arto Jantunen wrote:
Chow Loong Jin hyper...@debian.org writes:
On 03/05/2013 15:01, Emilio Pozuelo Monfort wrote:
Isn't that already possible?
It is? I should try that out with my next upload.
No, it's not. Source only uploads were banned many years ago, mainly due
On Fri, May 3, 2013 at 09:01:51 +0200, Emilio Pozuelo Monfort wrote:
On 05/03/2013 03:18 AM, Chow Loong Jin wrote:
While we're at it, can we also have source-only uploads? Uploading
potentially
huge binary packages that just go to /dev/null seems like a pointless waste
of
bandwidth
On Fri, May 03, 2013 at 09:01:51AM +0200, Emilio Pozuelo Monfort wrote:
After Wheezy is released, we can talk about throwing away all binary
uploads again... if we can't prevent people doing the wrong thing, we
might have to send bits of what gets uploaded to /dev/null.
While we're at
On 05/03/2013 02:12 AM, Russ Allbery wrote:
Yes, speaking as someone who has, on several occasions, uploaded arch: all
binary packages with source package problems and not discovered that until
months later via a FTBFS bug from an archive rebuild, I think we should
rebuild all arch: all
On 03-05-13 10:25, Chow Loong Jin wrote:
On 03/05/2013 16:12, Arto Jantunen wrote:
Chow Loong Jin hyper...@debian.org writes:
On 03/05/2013 15:01, Emilio Pozuelo Monfort wrote:
Isn't that already possible?
It is? I should try that out with my next upload.
No, it's not. Source only
On Fri, May 3, 2013 15:09, Wouter Verhelst wrote:
No, it's not. Source only uploads were banned many years ago, mainly
due
to problems with maintainers not even build testing their packages.
They do. They just ignore the issue; they can do that because it's a
scalability issue that,
Le vendredi 03 mai 2013 à 09:18 +0800, Chow Loong Jin a écrit :
While we're at it, can we also have source-only uploads? Uploading potentially
huge binary packages that just go to /dev/null seems like a pointless waste of
bandwidth to me, and the only for argument I've heard (which I don't
* Holger Levsen hol...@layer-acht.org [130502 12:28]:
People do this all the time: upload packages built against local packages,
experimental or even on Ubuntu to Debian sid.
/me shivers. This hurts. There is no reason not to rebuild in sane
environments. Can we please fix this for the
2013/5/3 Josselin Mouette j...@debian.org:
There is a solution to both the upload bandwidth problem and the the
problem that buildd binaries are untested, but I’m afraid it implies
changes to dak.
This means configuring dak to accepting only two types of uploads:
- source-only uploads
Bernhard R. Link brl...@debian.org writes:
Once we drop that and only give people the right to modify the
software we distribute but no longer the possiblity to do so
on their own, the Free we are so proud on gets mood.
Doesn't pbuilder make it easy enough for anyone to modify and build the
On Sat, May 04, 2013 at 12:10:25AM +0300, Timo Juhani Lindfors wrote:
Bernhard R. Link brl...@debian.org writes:
Once we drop that and only give people the right to modify the
software we distribute but no longer the possiblity to do so
on their own, the Free we are so proud on gets mood.
Hi,
Am Samstag, den 04.05.2013, 00:10 +0300 schrieb Timo Juhani Lindfors:
Bernhard R. Link brl...@debian.org writes:
Once we drop that and only give people the right to modify the
software we distribute but no longer the possiblity to do so
on their own, the Free we are so proud on gets
brian m. carlson sand...@crustytoothpaste.net writes:
The issue with sterile build environments is not just for building
packages for normal use. If I'm fixing a bug in a package, I may need
to build that package several times, testing different fixes. If
everyone assumes that packages will
* Russ Allbery r...@debian.org [130504 00:32]:
The way to ensure that builds in non-clean environments work properly is
to devise a method for testing them, and to do those tests on a regular
basis and turn test failures into bugs.
Noone is speaking about non-clean environments, but only about
* Arto Jantunen vi...@debian.org, 2013-05-03, 11:12:
Source only uploads were banned many years ago, mainly due to problems
with maintainers not even build testing their packages.
[citation needed]
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
Bernhard R. Link brl...@debian.org writes:
* Russ Allbery r...@debian.org [130504 00:32]:
The way to ensure that builds in non-clean environments work properly
is to devise a method for testing them, and to do those tests on a
regular basis and turn test failures into bugs.
Noone is
On Sat, May 04, 2013 at 01:05:06AM +0200, Bernhard R. Link wrote:
* Russ Allbery r...@debian.org [130504 00:32]:
The way to ensure that builds in non-clean environments work properly is
to devise a method for testing them, and to do those tests on a regular
basis and turn test failures into
On Fri, May 3, 2013 at 9:25 AM, Thijs Kinkhorst wrote:
On Fri, May 3, 2013 15:09, Wouter Verhelst wrote:
No, it's not. Source only uploads were banned many years ago, mainly
due
to problems with maintainers not even build testing their packages.
They do. They just ignore the issue; they
Holger Levsen hol...@layer-acht.org (02/05/2013):
On Donnerstag, 2. Mai 2013, Andreas Beckmann wrote:
People do this all the time: upload packages built against local
packages, experimental or even on Ubuntu to Debian sid.
/me shivers. This hurts. There is no reason not to rebuild in sane
On Thu, 2 May 2013 12:27:32 +0200
Holger Levsen hol...@layer-acht.org wrote:
Hi,
On Donnerstag, 2. Mai 2013, Andreas Beckmann wrote:
People do this all the time: upload packages built against local packages,
experimental or even on Ubuntu to Debian sid.
/me shivers. This hurts. There
Cyril Brulebois k...@debian.org writes:
Holger Levsen hol...@layer-acht.org (02/05/2013):
On Donnerstag, 2. Mai 2013, Andreas Beckmann wrote:
People do this all the time: upload packages built against local
packages, experimental or even on Ubuntu to Debian sid.
/me shivers. This hurts.
On Thu, May 02, 2013 at 11:00:09AM -0700, Russ Allbery wrote:
People do this all the time: upload packages built against local
packages, experimental or even on Ubuntu to Debian sid.
/me shivers. This hurts. There is no reason not to rebuild in sane
environments. Can we please fix this
Andrey Rahmatullin w...@wrar.name writes:
On Thu, May 02, 2013 at 11:00:09AM -0700, Russ Allbery wrote:
We can by rebuilding all packages from source, including on the
uploaded architecture. Then at worst they will be consistently broken
across all architectures. :)
Don't forget arch:all
On 02/05/2013 18:48, Neil Williams wrote:
After Wheezy is released, we can talk about throwing away all binary
uploads again... if we can't prevent people doing the wrong thing, we
might have to send bits of what gets uploaded to /dev/null.
While we're at it, can we also have source-only
69 matches
Mail list logo
