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 fo
Christoph Egger wrote:
>Hi!
>
>Barry Warsaw 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, pas
Joachim Breitner 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 builds are at
Hi,
Am Samstag, den 11.05.2013, 12:00 +0200 schrieb Christoph Egger:
> Barry Warsaw 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 atte
Hi!
Barry Warsaw 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, *and* don't ma
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,
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 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 can
* Goswin von Brederlow , 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 binaries and upload
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,
On Fri, May 03, 2013 at 07:11:35PM +0200, Bernhard R. Link wrote:
> * Holger Levsen [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 rebui
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 wast
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 inter
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
>
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 up
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 "uns
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
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 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 do
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 consen
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 sca
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 tha
+++ 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 op
* Ryan Kavanagh , 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 upload."
No, that
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
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 y
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 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 <= optio
]] 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 ge
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 on
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
> hardwa
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-doub
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
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 que
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
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 pbuilde
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 pac
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" writes:
> > > > Once we drop that and only give people the right to modify the
> > > > software we dist
* Wookey , 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 very simple matter.
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 sim
+++ 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" 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 the
Jakub Wilk writes:
> * Arto Jantunen , 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 this was made
at some poi
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
On Sat, May 04, 2013 at 01:05:06AM +0200, Bernhard R. Link wrote:
> * Russ Allbery [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.
>
"Bernhard R. Link" writes:
> * Russ Allbery [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 envir
* Arto Jantunen , 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 subject of "unsubscribe
* Russ Allbery [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
non-minimal,
"brian m. carlson" 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 be built in a sterile
Hi,
Am Samstag, den 04.05.2013, 00:10 +0300 schrieb Timo Juhani Lindfors:
> "Bernhard R. Link" 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.
>
On Sat, May 04, 2013 at 12:10:25AM +0300, Timo Juhani Lindfors wrote:
> "Bernhard R. Link" 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.
>
> Doe
"Bernhard R. Link" 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
software on t
2013/5/3 Josselin Mouette :
> 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
> They a
* Holger Levsen [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 next release?!
I
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 b
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 tha
On 03-05-13 10:25, Chow Loong Jin wrote:
> On 03/05/2013 16:12, Arto Jantunen wrote:
> > Chow Loong Jin 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 on
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 p
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.
> >
> > Whil
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
> >
On 03/05/2013 16:12, Arto Jantunen wrote:
> Chow Loong Jin 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 pr
Chow Loong Jin 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 testing their pac
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
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 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 upl
Andrey Rahmatullin 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
Yes, s
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 ple
Cyril Brulebois writes:
> Holger Levsen (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 reb
On Thu, 2 May 2013 12:27:32 +0200
Holger Levsen 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 is no reason n
Holger Levsen (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
> environments.
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 is no reason not to rebuild in sane
environments. Can we please fix this for the nex
70 matches
Mail list logo
