Hello,
On Thu 03 Mar 2022 at 08:44PM +01, Andreas Tille wrote:
> Am Thu, Mar 03, 2022 at 09:57:26AM -0700 schrieb Sean Whitton:
>> > PS: I'm currently considering writing up some summary of the bunch
>> > of threads that was born out of my initial mail.
>> >
>> > [1] https://lists.debian.org/
Am Thu, Mar 03, 2022 at 09:57:26AM -0700 schrieb Sean Whitton:
> > PS: I'm currently considering writing up some summary of the bunch
> > of threads that was born out of my initial mail.
> >
> > [1] https://lists.debian.org/debian-devel/2022/01/msg00226.html
>
> Assuming I'm not misreading, th
Hello,
On Thu 03 Mar 2022 at 07:36am +01, Andreas Tille wrote:
> Hi Sean,
>
> Am Wed, Mar 02, 2022 at 08:33:35AM -0700 schrieb Sean Whitton:
>>
>> I'm sorry to be responding only a month later, but I think there are
>> some reasons why binNEW is not the worst place to be doing these extra
>> chec
Hi Sean,
Am Wed, Mar 02, 2022 at 08:33:35AM -0700 schrieb Sean Whitton:
>
> I'm sorry to be responding only a month later, but I think there are
> some reasons why binNEW is not the worst place to be doing these extra
> checks: packages with SONAME bumps are typically C or C++ projects and
> thes
sible, as the FTP
> team have to manage the namespace of the packages in the archive. But the
> application of license/copyright review by the FTP team for existing
> source packages as part of binary NEW processing /and at no other time/ is
> arbitrary. It is, at best, a historical ac
that the FTP team applies license/copyright review as part of their
review of source packages has grounding in a number of goals of Debian as a
project. The existence of a binary NEW queue is also sensible, as the FTP
team have to manage the namespace of the packages in the archive. But the
On February 8, 2022 2:38:48 AM UTC, Holger Levsen wrote:
>On Mon, Feb 07, 2022 at 09:28:16PM -0500, Theodore Ts'o wrote:
>> The argument why a package which has an upstream-induced shared
>> library version bump, has to go through the entire NEW gauntlet [...]
>
>I hear your frustration but don
On Mon, Feb 07, 2022 at 09:28:16PM -0500, Theodore Ts'o wrote:
> The argument why a package which has an upstream-induced shared
> library version bump, has to go through the entire NEW gauntlet [...]
I hear your frustration but don't you think that language like "gauntlet"
makes it, uhm, very har
On Mon, Feb 07, 2022 at 07:05:59PM -0700, Sean Whitton wrote:
> Hello,
>
> On Mon 07 Feb 2022 at 12:00PM -05, Theodore Ts'o wrote:
>
> > On Mon, Feb 07, 2022 at 12:06:24AM -0700, Sean Whitton wrote:
> >>
> >> When we treat any of the above just like other RC bugs, we are accepting
> >> a lower li
Hello,
On Mon 07 Feb 2022 at 12:00PM -05, Theodore Ts'o wrote:
> On Mon, Feb 07, 2022 at 12:06:24AM -0700, Sean Whitton wrote:
>>
>> When we treat any of the above just like other RC bugs, we are accepting
>> a lower likelihood that the bugs will be found, and also that they will
>> be fixed
On February 7, 2022 6:00:16 PM UTC, John Goerzen wrote:
>
>On Mon, Feb 07 2022, Theodore Ts'o wrote:
>
>> If we can't do anything else, I suspect we can reduce project a
>> friction a lot of we only subject packages to copyright hazing when it
>> is a NEW source package, and not when there is a
On Mon, Feb 07 2022, Theodore Ts'o wrote:
> If we can't do anything else, I suspect we can reduce project a
> friction a lot of we only subject packages to copyright hazing when it
> is a NEW source package, and not when there is a NEW binary package
> caused by some usptream maintainers not bei
On Mon, Feb 07, 2022 at 12:06:24AM -0700, Sean Whitton wrote:
>
> When we treat any of the above just like other RC bugs, we are accepting
> a lower likelihood that the bugs will be found, and also that they will
> be fixed
Another part of this discussion which shouldn't be lost is the
probab
have gone away. Are we working from
> legal advice telling us that this pre-screening is required for some legal
> purpose? If so, is it effective for the legal purpose at which it is
> aimed? Is this system left over from old advice? Have we checked our
> assumptions recently?
>
&g
On 16200 March 1977, Michael Lustfield wrote:
I do recall that the FTP masters would've been generally open to have
such an auto-approver (but maybe I'm wrong), but that no-one stepped
up
yet to code it up?
A few of us came up with some proof of concept designs/models, but we
ultimately dropp
On Wed, 14 Jul 2021 18:48:24 +0200
Philipp Kern wrote:
> On 14.07.21 13:47, Michael Biebl wrote:
> > Am 14.07.21 um 12:59 schrieb Simon McVittie:
> I do recall that the FTP masters would've been generally open to have
> such an auto-approver (but maybe I'm wrong), but that no-one stepped up
>
the archive ASAP.
If something fully automated like this would be implemented, I would
have much less concerns with this option.
As it stands today, NEW processing is simply to unpredictable. It can
range from taking a a few hours/days to several months.
And yet it should not dictate technical
Am 14.07.21 um 13:47 schrieb Michael Biebl:
Am 14.07.21 um 12:59 schrieb Simon McVittie:
Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and
auto-accept
packages from the given source package that match the regex, as
automated like this would be implemented, I would
have much less concerns with this option.
As it stands today, NEW processing is simply to unpredictable. It can
range from taking a a few hours/days to several months.
Regards,
Michael
OpenPGP_signature
Description: OpenPGP digital signature
On 12/29/19 10:51 PM, Sebastiaan Couwenberg wrote:
> On 12/29/19 3:53 PM, Theodore Y. Ts'o wrote:
>> On Sun, Dec 29, 2019 at 09:52:44AM +0100, Enrico Zini wrote:
>>> some time ago I uploaded a new version of dballe, which went through NEW
>>> because of a change in binary package names (SONAME bump
On Sun, Dec 29, 2019 at 10:51:36PM +0100, Sebastiaan Couwenberg wrote:
> > Wow, two weeks? I uploaded a new version of f2fs-tools back in July,
> > with the same issue (SONAME bump), and it's still not gotten through
> > NEW.
> >
> > I had assumed everyone was waiting 5-6+ months to get through N
On 12/29/19 3:53 PM, Theodore Y. Ts'o wrote:
> On Sun, Dec 29, 2019 at 09:52:44AM +0100, Enrico Zini wrote:
>> some time ago I uploaded a new version of dballe, which went through NEW
>> because of a change in binary package names (SONAME bump, IIRC). It took
>> two weeks to go through NEW and I tu
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
You can prepare and sign the upload at any time after
> > all. Only the upload itself needs to be timed to the NEW processing.
>
> That will only work if the "delayed" package adds a versioned B-D on the
> NEW package (so it comes with an explicit dep-wait), otherwise it wil
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
o be
handled by the release team.
> Maybe this calls for an upload manager or a dependency based delayed
> upload queue. You can prepare and sign the upload at any time after
> all. Only the upload itself needs to be timed to the NEW processing.
That will only work if the "delayed" p
cy bar of package foo along with the new version
> >> of foo (instead of uploading bar first, wait for NEW processing and only
> >
> > I think you shouldn???t do that anyway.
> >
> > After all, to do that, you???d have to manually install the new version
> &
On 23/04/2013 23:15, Thorsten Glaser wrote:
> Joachim Breitner debian.org> writes:
>
>> The (luxury) problem is that I got used to it and began uploading the
>> new (and NEW) dependency bar of package foo along with the new version
>> of foo (instead of upload
Joachim Breitner writes:
> sounds good in theory, but in practice, when I want to upgrade foo,
> which happens to have a new dependency on bar, which needs baz, which
> needs qux, then I really want to get this done in one rush, and not wait
> for three NEW processings in between.
I go through t
that this process is,
at least after NEW processing, fine.
Greetings,
Joachim
--
Joachim "nomeata" Breitner
Debian Developer
nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata
signature.asc
Description:
Joachim Breitner debian.org> writes:
> The (luxury) problem is that I got used to it and began uploading the
> new (and NEW) dependency bar of package foo along with the new version
> of foo (instead of uploading bar first, wait for NEW processing and only
I think you shouldn’t do
On Wed, Apr 10, 2013 at 02:52:20AM +0800, Thomas Goirand wrote:
> If I upload new packages A and B, that A depends and B, and
> that A gets approved, but B doesn't, then we end up with
> package A being in Debian, but never installable.
Has this ever happened? I believe the FTP masters do look at
1 - 100 of 302 matches
Mail list logo
