On 2021-01-04 at 04:27, Adrian Bunk wrote:
> On Thu, Dec 31, 2020 at 02:16:23PM +0100, Bernd Zeimetz wrote:
>
>> Although the high number of packages makes me wonder, if at least a
>> quick MIA check of the maintainers is warranted, or - if those packages
>> are needed in bullseye at all.
>
> Ma
On Thu, Dec 31, 2020 at 02:16:23PM +0100, Bernd Zeimetz wrote:
>...
> Although the high number of packages makes me wonder, if at least a
> quick MIA check of the maintainers is warranted, or - if those packages
> are needed in bullseye at all.
>...
Maintainership status is a very poor indicator w
On Thu, Dec 31, 2020 at 08:14:20PM +0100, Eduard Bloch wrote:
> You might want to update your database and rerun that analysis. At least
> one of the packages was updated following the current rules a few days
> ago.
> https://tracker.debian.org/pkg/mail-expire
well, the list is correct from the P
Hi Holger,
On 31/12/2020 13:50, Holger Levsen wrote:
> hi,
>
> as described in Message-ID: <20201231124509.gb3...@layer-acht.org>
> or
> http://layer-acht.org/thinking/blog/20201231-no-source-change-source-uploads/
> I plan to do 3000 NMUs soon.
>
> Attached is the list of affected packages, m
Hello Holger,
I will do my part myself ASAP
Kind regards
Mechtilde
Am 31.12.20 um 14:21 schrieb Holger Levsen:
> Hi Bernd,
>
> On Thu, Dec 31, 2020 at 02:16:23PM +0100, Bernd Zeimetz wrote:
>>> as described in Message-ID: <20201231124509.gb3...@layer-acht.org>
>>> or
>>> http://layer-acht.org
Hallo,
* Holger Levsen [Thu, Dec 31 2020, 12:50:30PM]:
> as described in Message-ID: <20201231124509.gb3...@layer-acht.org>
> or
> http://layer-acht.org/thinking/blog/20201231-no-source-change-source-uploads/
> I plan to do 3000 NMUs soon.
>
> Attached is the list of affected packages, maintain
Hi Bernd,
On Thu, Dec 31, 2020 at 02:16:23PM +0100, Bernd Zeimetz wrote:
> > as described in Message-ID: <20201231124509.gb3...@layer-acht.org>
> > or
> > http://layer-acht.org/thinking/blog/20201231-no-source-change-source-uploads/
> > I plan to do 3000 NMUs soon.
> Thanks for your work!
thank
Hi Holger,
>
> as described in Message-ID: <20201231124509.gb3...@layer-acht.org>
> or
> http://layer-acht.org/thinking/blog/20201231-no-source-change-source-uploads/
> I plan to do 3000 NMUs soon.
Thanks for your work!
Although the high number of packages makes me wonder, if at least a
quick
Le jeudi, 31 décembre 2020, 13.50:30 h CET Holger Levsen a écrit :
> hi,
>
> as described in Message-ID: <20201231124509.gb3...@layer-acht.org>
> or
> http://layer-acht.org/thinking/blog/20201231-no-source-change-source-upload
> s/ I plan to do 3000 NMUs soon.
Fantastic job, thanks a lot for doin
Holger Levsen, le jeu. 31 déc. 2020 12:45:09 +, a ecrit:
> I'll post the list of packages (sorted by ddlist) to debian-devel@lists.d.o
> shortly and will then amend this blog post to link to that mail.
I was about to ask for such a list :D
I'll gladly upload my long-no-upload packages, probab
hi,
as described in Message-ID: <20201231124509.gb3...@layer-acht.org>
or http://layer-acht.org/thinking/blog/20201231-no-source-change-source-uploads/
I plan to do 3000 NMUs soon.
Attached is the list of affected packages, maintainers and uploaders. Please
check
if you are on it and if so, ple
540 no-source-change source-only uploads in two weeks
So I've been doing 540 no-source-change source-only uploads in the last two
weeks
and am planning to do 3000 more in January 2021. We'll see how that goes ;)
Let me explain what I have been doing and why.
So, https://lists.debian.
Andrey Rahmatullin writes ("Re: source-only uploads"):
> On Fri, Sep 01, 2017 at 12:47:41PM +0200, Emmanuel Bourg wrote:
> > Just yesterday I completely broke a key package used to build
> > many Java packages, and I couldn't even rebuild it to fix the issue.
>
&
On Fri, Sep 01, 2017 at 07:18:58PM +0100, Ian Jackson wrote:
> Andrey Rahmatullin writes ("Re: source-only uploads"):
> > On Fri, Sep 01, 2017 at 12:47:41PM +0200, Emmanuel Bourg wrote:
> > > Just yesterday I completely broke a key package used to build
> > &g
Andrey Rahmatullin writes ("Re: source-only uploads"):
> On Fri, Sep 01, 2017 at 12:47:41PM +0200, Emmanuel Bourg wrote:
> > Just yesterday I completely broke a key package used to build
> > many Java packages, and I couldn't even rebuild it to fix the issue.
>
&
On Fri, Sep 01, 2017 at 12:47:41PM +0200, Emmanuel Bourg wrote:
> Just yesterday I completely broke a key package used to build
> many Java packages, and I couldn't even rebuild it to fix the issue.
Why? Does it B-D on itself?
--
WBR, wRAR
signature.asc
Description: PGP signature
> and after someone
> has implemented a solution for that there is no blocker left for
> allowing only source-only uploads from maintainers.
I'm all for source-only uploads and I adopted them recently, but I hope
this restriction won't happen, or at least not without a derogat
On Wed, Aug 13, 2014, at 14:02, Guillem Jover wrote:
> Hi!
>
> On Mon, 2014-08-04 at 02:35:46 -0400, Joey Hess wrote:
> > #756975 dpkg-dev: dpkg-genchanges option to only include arch:all debs
>
> This is now available in dpkg 1.17.11, and as mentioned on the bug
> report, you can use it in at le
On Fri, 2014-08-15 at 11:27:00 +0200, Johannes Schauer wrote:
> Quoting Guillem Jover (2014-08-13 13:48:11)
> > On Tue, 2014-08-12 at 13:27:38 +0200, Ansgar Burchardt wrote:
> > > There are also other problems that need to be eventually addressed: as far
> > > as I know there are some source packag
On Tue, 19 Aug 2014, Hector Oron wrote:
> 2014-08-15 16:04 GMT+02:00 Ondřej Surý :
> > I have encountered a situation where the FTBFS bug was caused
> > by segfault in other package. This has forced me to split opendnssec-doc
> > to arch:all package (which was good thing anyway), so there are cases
On Tue, 19 Aug 2014, Hector Oron wrote:
> If amd64 was to be picked, what would happen to packages producing
> arch:all packages that do not build on such architecture?
They would get a FTBFS bug and they would get fixed. Or, if it's not a bug,
the package would be uploaded by the maintainer himse
Hello,
2014-08-15 16:04 GMT+02:00 Ondřej Surý :
> I have encountered a situation where the FTBFS bug was caused
> by segfault in other package. This has forced me to split opendnssec-doc
> to arch:all package (which was good thing anyway), so there are cases
> where you want to build the arch:all
On Fri, 15 Aug 2014, Ondřej Surý wrote:
> On Fri, Aug 15, 2014, at 15:37, Henrique de Moraes Holschuh wrote:
> > And any package that cannot build arch:all on a released arch for which
> > it produces binary packages potentially has a FTBFS bug, anyway, which
> > can be reported by any interested p
On Fri, Aug 15, 2014, at 15:37, Henrique de Moraes Holschuh wrote:
> And any package that cannot build arch:all on a released arch for which
> it produces binary packages potentially has a FTBFS bug, anyway, which
> can be reported by any interested parties. Exceptions would be arches
> that are t
On Fri, 15 Aug 2014, Raphael Hertzog wrote:
> On Fri, 15 Aug 2014, Hector Oron wrote:
> > Even building arch:all packages in one architecture might solve the
> > issue, I do not like that approach, as it holds other arches from
> > building until that "primary" arch has built arch:all packages.
>
On Fri, 15 Aug 2014, Hector Oron wrote:
> Even building arch:all packages in one architecture might solve the
> issue, I do not like that approach, as it holds other arches from
> building until that "primary" arch has built arch:all packages.
I understand the concern at the philosophical level bu
Hello,
2014-08-13 22:59 GMT+02:00 Philipp Kern :
> On 2014-08-13 14:34, Raphael Hertzog wrote:
>> On Wed, 13 Aug 2014, Colin Watson wrote:
>>> I don't think there's a good reason to build them separately, and some
>>> good reasons not to (for example, it would waste a good deal of buildd
>>> time
Hi,
Quoting Guillem Jover (2014-08-13 13:48:11)
> On Tue, 2014-08-12 at 13:27:38 +0200, Ansgar Burchardt wrote:
> > There are also other problems that need to be eventually addressed: as far
> > as I know there are some source packages producing arch:all binaries that
> > cannot be built on all ar
On 2014-08-13 14:34, Raphael Hertzog wrote:
On Wed, 13 Aug 2014, Colin Watson wrote:
I don't think there's a good reason to build them separately, and some
good reasons not to (for example, it would waste a good deal of buildd
time for a number of packages without very hygienic separation of
th
On Wed, 2014-08-13 at 12:24:49 -0700, Josh Triplett wrote:
> Guillem Jover wrote:
> > # Full build, but filter the generated .changes file to only inlcude
> > # source and possibly arch-indep binaries, will not fail if the
> > # latter are missing.
> > $ dpkg-buildpackage --changes-option=-
Guillem Jover wrote:
> # Full build, but filter the generated .changes file to only inlcude
> # source and possibly arch-indep binaries, will not fail if the
> # latter are missing.
> $ dpkg-buildpackage --changes-option=-g
>
> The advantage of the second is that the package is fully built
Hi,
On Tue, 12 Aug 2014, Ansgar Burchardt wrote:
> First, w-b has to recognize that arch:all packages need to be built.
> And they need to be scheduled on a buildd which builds the arch:all
> packages (and only the arch:all packages?).
>
> For the latter I assume sbuild would need an option to bu
Hi!
On Mon, 2014-08-04 at 02:35:46 -0400, Joey Hess wrote:
> #756975 dpkg-dev: dpkg-genchanges option to only include arch:all debs
This is now available in dpkg 1.17.11, and as mentioned on the bug
report, you can use it in at least these ways:
# Source and arch-indep only build, will fail if
Hi!
[ I had a note to reply to the previous thread, but never got to it. ]
On Tue, 2014-08-12 at 13:27:38 +0200, Ansgar Burchardt wrote:
> On 08/12/2014 12:33, Hector Oron wrote:
> > 2014-08-01 9:37 GMT+02:00 Ansgar Burchardt :
> >> We will allow not including arch:all packages in uploads once we
On Tue, Aug 12, 2014 at 01:27:38PM +0200, Ansgar Burchardt wrote:
> First, w-b has to recognize that arch:all packages need to be built.
> And they need to be scheduled on a buildd which builds the arch:all
> packages (and only the arch:all packages?).
>
> For the latter I assume sbuild would need
Hi,
On 08/12/2014 12:33, Hector Oron wrote:
> 2014-08-01 9:37 GMT+02:00 Ansgar Burchardt :
>> We will allow not including arch:all packages in uploads once we have
>> sorted out how to get them built.
>
> Has it been already discussed? If so, where?
Not the part to actually implement it. But fr
Hello,
2014-08-01 9:37 GMT+02:00 Ansgar Burchardt :
> We will allow not including arch:all packages in uploads once we have
> sorted out how to get them built.
Has it been already discussed? If so, where?
Regards,
--
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
--
To
Hi,
Quoting Matthias Urlichs (2014-08-07 07:54:26)
> Also, "build profiles" are not explained anywhere in Policy (unless that's
> been added after 3.9.5), so how would I discover which values are allowed /
> make sense?
right. For the purpose of documenting the Package-List its usage for build
pr
Ansgar Burchardt (2014-08-01):
> as a first step towards source-only uploads, the archive will now accept
> source-only uploads provided the following conditions are met:
>
> * The source package is not NEW and does not build NEW binaries.
> * Architecture-independent (arch:all
Hi,
Quoting Charles Plessy (2014-08-06 07:41:40)
> what do you think about the patch I sent to the Policy, for describing the
> syntax of the current optional fields of the Packages-List field ? Do you
> think that modifications are needed ? Would you second it ?
>
> https://bugs.debian.org
Control: retitle -1 Extension of the syntax of the Packages-List field.
Le Wed, Aug 06, 2014 at 07:16:37AM +0200, Johannes Schauer a écrit :
>
> The field started out with the binary package name, type, section and
> priority.
> For bootstrapping it is necessary to know for which architectures a
linux[1].
>
> The architecture information was only (re)introduced later, as far as I
> know to help with bootstrapping, but it turns out that I also want this
> for source-only uploads to catch uploads introducing NEW binary packages.
The field started out with the binary package na
hi can you please take this adress off the list ? many thanks!
LG
Von meinem iPod gesendet
Am 01.08.2014 um 09:37 schrieb Ansgar Burchardt :
> Hi,
>
> as a first step towards source-only uploads, the archive will now accept
> source-only uploads provided the following condit
Filed a few bug reports on this:
#756975 dpkg-dev: dpkg-genchanges option to only include arch:all debs
#756978 dgit: .tar-less push
The possibility of the second one is .. pretty amazing!
--
see shy jo
signature.asc
Description: Digital signature
On Sun, Aug 3, 2014 at 8:13 PM, Joey Hess wrote:
> Ansgar Burchardt wrote:
>> * Architecture-independent (arch:all) packages must be included in
>>uploads.
>
> That can be read 2 different ways.. I hope it means:
> If you have an arch:all, you have to upload it, but if there is none,
> you ca
Ansgar Burchardt wrote:
> * Architecture-independent (arch:all) packages must be included in
>uploads.
That can be read 2 different ways.. I hope it means:
If you have an arch:all, you have to upload it, but if there is none,
you can upload with no .debs. Is that correct?
--
see shy jo, sti
Hi,
Kurt Roeckx writes:
> Please also make sure you rename the changes files to not conflict
> with the .changes files the buildd is going to use.
As of today, that's no longer required. :)
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscrib
On 08/01/2014 06:15 PM, Holger Levsen wrote:
> Hi Ansgar,
>
> On Freitag, 1. August 2014, Ansgar Burchardt wrote:
>> as a first step towards source-only uploads, the archive will now accept
>> source-only uploads provided the following conditions are met:
> [...]
>
es that build arch-specific binaries
> such as src:linux[1].
>
> The architecture information was only (re)introduced later, as far as I
> know to help with bootstrapping, but it turns out that I also want this
> for source-only uploads to catch uploads introducing NEW binary pac
* Kurt Roeckx , 2014-08-01, 22:58:
Build binary packages as usual, but sed-out _(amd64|i386).deb from
resulting .changes before signing it.
Please also make sure you rename the changes files to not conflict with
the .changes files the buildd is going to use.
Can we fix dak not to care about
On Fri, Aug 01, 2014 at 10:16:12AM +0200, Ondrej Surý wrote:
> On Fri, Aug 1, 2014, at 09:54, Michael Tokarev wrote:
> > 01.08.2014 11:37, Ansgar Burchardt wrote:
> > > Hi,
> > >
> > > as a first step towards source-only uploads, the archive will now accept
&g
Thanks a lot; this is great news!
Richard
Sent by mobile; excuse my brevity.
he field was originally discussed in https://bugs.debian.org/619131 to
allow easier processing of packages that build arch-specific binaries
such as src:linux[1].
The architecture information was only (re)introduced later, as far as I
know to help with bootstrapping, but it turns out that I also want thi
Hi Ansgar,
On Freitag, 1. August 2014, Ansgar Burchardt wrote:
> as a first step towards source-only uploads, the archive will now accept
> source-only uploads provided the following conditions are met:
[...]
whoooh! Yay! Thanks a lot to those who made this real! This is *great*
also sprach Paul Wise [2014-08-01 11:33 +0200]:
> >> * The source package includes a Package-List field that also has
> >>an arch=* column. dpkg (>= 1.17.7) will include this.
> >
> > Can we read up more on this somewhere?
>
> It is the default if you are using dpkg-dev from jessie and you d
On Fri, Aug 1, 2014 at 4:38 PM, martin f krafft wrote:
> also sprach Ansgar Burchardt [2014-08-01 09:37 +0200]:
>> * The source package includes a Package-List field that also has
>>an arch=* column. dpkg (>= 1.17.7) will include this.
>
> Can we read up more on this somewhere?
It is the def
also sprach Ansgar Burchardt [2014-08-01 09:37 +0200]:
> as a first step towards source-only uploads, the archive will now accept
> source-only uploads provided the following conditions are met:
Wow. This is great news! Thank you so much for your perseverance.
> * The source package i
On Fri, Aug 1, 2014, at 09:54, Michael Tokarev wrote:
> 01.08.2014 11:37, Ansgar Burchardt wrote:
> > Hi,
> >
> > as a first step towards source-only uploads, the archive will now accept
> > source-only uploads provided the following conditions are met:
> >
>
On Fri, 01 Aug 2014, Michael Tokarev wrote:
> 01.08.2014 11:37, Ansgar Burchardt wrote:
> > as a first step towards source-only uploads, the archive will now accept
> > source-only uploads provided the following conditions are met:
> >
> > * The source package is not
01.08.2014 11:37, Ansgar Burchardt wrote:
> Hi,
>
> as a first step towards source-only uploads, the archive will now accept
> source-only uploads provided the following conditions are met:
>
> * The source package is not NEW and does not build NEW binaries.
> * Arc
On Sun, Nov 25, 2012 at 01:32:16PM -0500, Barry Warsaw wrote:
> On Nov 23, 2012, at 03:06 PM, YunQiang Su wrote:
> >you always need to build for one arch and test, then why not upload it?
>
> I think there are a lot of good reasons to do source-only uploads, even when
> you
On Nov 23, 2012, at 03:06 PM, YunQiang Su wrote:
>you always need to build for one arch and test, then why not upload it?
I think there are a lot of good reasons to do source-only uploads, even when
you should be building locally for testing purposes.
* Reproducibility - buildds provide a m
On 25/11/12 00:00, Thorsten Glaser wrote:
Thomas Goirand debian.org> writes:
Though I'm in the favor of dropping binaries rather than source-only,
This could even help the cases of packages that need itself
to be built.
When a packager does a source+binary upload of foo (= 1.2-1),
it would
Thomas Goirand debian.org> writes:
> Though I'm in the favor of dropping binaries rather than source-only,
This could even help the cases of packages that need itself
to be built.
When a packager does a source+binary upload of foo (= 1.2-1),
it would be built in a clean, minimal chroot (yes, I’
]] Gunnar Wolf
> Didier Raboud dijo [Wed, Nov 21, 2012 at 09:21:19PM +0100]:
> > Actually, I like that way to put it as it leaves us with multiple ways
> > forward:
> >
> > * accept source-only;
> > * drop uploaded binaries;
>
> I would join this camp as well. Without the working knowledge of
On 11/24/2012 12:30 AM, Gunnar Wolf wrote:
> I would join this camp as well. Without the working knowledge of being
> a DSA or buildd-admin, I cannot assure how much would this increase
> our workload, but it would probably just mean rebuilding for the most
> popular architectures (that is, AMD64 o
Didier Raboud dijo [Wed, Nov 21, 2012 at 09:21:19PM +0100]:
> > > > I am asking why, when I had a reason to do so, was not able to do a
> > > > source-only upload.
> > > > Is this a feature of dak, or a policy enforcement?
> > >
> > > Both.
> >
> > I'd argue that it's a bug in both.
> >
> > BTW,
On Fri, Nov 23, 2012 at 03:06:22PM +0800, YunQiang Su wrote:
> you always need to build for one arch and test, then why not upload it?
How is that related to my question? Also, please don't top-post and dont
send me copies.
> On Thu, Nov 22, 2012 at 4:33 PM, Andrey Rahmatullin wrote:
>
> > On We
you always need to build for one arch and test, then why not upload it?
On Thu, Nov 22, 2012 at 4:33 PM, Andrey Rahmatullin wrote:
> On Wed, Nov 21, 2012 at 09:21:19PM +0100, Didier Raboud wrote:
> > What is yet unclear is if we want to build all (as in arch:any+all) or
> all (as
> > in arch:an
On Wed, Nov 21, 2012 at 09:21:19PM +0100, Didier Raboud wrote:
> What is yet unclear is if we want to build all (as in arch:any+all) or all
> (as
> in arch:any) packages on buildds.
Are there any reasons to not built arch:all on buildds aside from
technical problems?
--
WBR, wRAR
signature.as
On 20 November 2012 12:23, Henrique de Moraes Holschuh wrote:
> On Tue, 20 Nov 2012, Dmitrijs Ledkovs wrote:
>> I am sorry, if I was not clear. I am aware of the "last iteration",
>> but I am not enquiring about the default policy within debian as to
>> how we should upload by default.
>> I am ask
Le mercredi, 21 novembre 2012 20.59:02, Holger Levsen a écrit :
> Hi,
>
> On Dienstag, 20. November 2012, Henrique de Moraes Holschuh wrote:
> > > I am asking why, when I had a reason to do so, was not able to do a
> > > source-only upload.
> > > Is this a feature of dak, or a policy enforcement?
Hi,
On Dienstag, 20. November 2012, Henrique de Moraes Holschuh wrote:
> > I am asking why, when I had a reason to do so, was not able to do a
> > source-only upload.
> > Is this a feature of dak, or a policy enforcement?
> Both.
I'd argue that it's a bug in both.
BTW, can we have this as a rele
On Tue, Nov 20, 2012 at 12:08:13PM +, Dmitrijs Ledkovs wrote:
> If it's a policy enforcement, I am ok with it. Otherwise, I'd would
> like to see dak accept those. I have a vague recollection of a UDD
> presentations which did list count of DDs doing source-only uploads.
On Tue, 20 Nov 2012, Dmitrijs Ledkovs wrote:
> I am sorry, if I was not clear. I am aware of the "last iteration",
> but I am not enquiring about the default policy within debian as to
> how we should upload by default.
> I am asking why, when I had a reason to do so, was not able to do a
> source-
On 20 November 2012 11:14, Andrey Rahmatullin wrote:
> On Tue, Nov 20, 2012 at 11:10:37AM +, Dmitrijs Ledkovs wrote:
>> "Source-only uploads are not allowed."
>> Why not? May I request a binNMU for the architecture (amd64) I upload?
>>
>> I currentl
On Tue, Nov 20, 2012 at 11:10:37AM +, Dmitrijs Ledkovs wrote:
> "Source-only uploads are not allowed."
> Why not? May I request a binNMU for the architecture (amd64) I upload?
>
> I currently do not have facilities to build the package in question
> with the hos
frastructure is quite
good, but still there are several corner cases where manual uploads
are needed and there is nothing bad about it, even policy is not
against that. If ever consider source-only uploads, please make an
exception to the rule to allow corner cases like the ones discussed,
some
* Don Armstrong (d...@debian.org) [110607 18:11]:
> On Tue, 07 Jun 2011, Andreas Barth wrote:
> > * Don Armstrong (d...@debian.org) [110607 04:25]:
> > > On Mon, 06 Jun 2011, Philipp Kern wrote:
> > > > I.e. I think we should still allow non-buildd binaries, e.g. for
> > > > those cases you mention
On Tue, 07 Jun 2011, Andreas Barth wrote:
> * Don Armstrong (d...@debian.org) [110607 04:25]:
> > On Mon, 06 Jun 2011, Philipp Kern wrote:
> > > I.e. I think we should still allow non-buildd binaries, e.g. for
> > > those cases you mentioned.
> >
> > Non-buildd binaries should still be allowed, bu
* Don Armstrong (d...@debian.org) [110607 04:25]:
> On Mon, 06 Jun 2011, Philipp Kern wrote:
> > I.e. I think we should still allow non-buildd binaries, e.g. for
> > those cases you mentioned.
>
> Non-buildd binaries should still be allowed, but they should be
> followed immediately by a binNMU. [
On Mon, 06 Jun 2011, Philipp Kern wrote:
> I.e. I think we should still allow non-buildd binaries, e.g. for
> those cases you mentioned.
Non-buildd binaries should still be allowed, but they should be
followed immediately by a binNMU. [Are there any cases where we
wouldn't want to rebuild the pack
On Mon, 2011-06-06 at 19:38:03 +0200, Luk Claes wrote:
> Are you saying they cannot be bootstrapped with older versions (which
> are already in the archive)??!
By definition if they need to be manually bootstrapped it's because
their build dependencies are not available. The usual cases for that
a
On 06/06/2011 10:16 AM, Guillem Jover wrote:
> Hi!
>
> On Sun, 2011-04-17 at 11:20:07 +0200, Stefano Zacchiroli wrote:
>> On Wed, Mar 30, 2011 at 04:18:34PM +0200, Stefano Zacchiroli wrote:
>>>> The main decision which needs to be made is whether, as a project, we
>&
On Mon, 2011-06-06 at 09:03:00 +, Philipp Kern wrote:
> On 2011-06-06, Guillem Jover wrote:
> > I think this was mentioned in some previous incarnation of this
> > discussion, but throwing away debs unconditionally, or at least w/o
> > having a way to specify they must not be thrown away is go
On 2011-06-06, Guillem Jover wrote:
>> - There seems to be consensus to go ahead with throw-away debs; they
>> require a bit of work though so either be patient or, better,
>> volunteer with FTP masters to help out with the implementation of the
>> remaining bits.
> I think this was mentione
Hi!
On Sun, 2011-04-17 at 11:20:07 +0200, Stefano Zacchiroli wrote:
> On Wed, Mar 30, 2011 at 04:18:34PM +0200, Stefano Zacchiroli wrote:
> > > The main decision which needs to be made is whether, as a project, we
> > > want source only uploads or to throw away
remaining bits.
will this infrastructure then also be able to do archAllBinNMUs, for
cases when problems in arch:all packages can be fixed by simply
rebuilding without source changes? That would be nice to have.
Although it would come almost for free with source-only-uploads, as then
one can
On Thu, Apr 07, 2011 at 04:55:12PM +0200, Stefano Zacchiroli wrote:
> - going ahead with throw away debs seems to be largely uncontroversial;
> can we haz zem please? :-)
Will that throw away Arch: all packages as well? If there are no
technical issues/implementation missing with this (somebody
On Wed, Mar 30, 2011 at 04:18:34PM +0200, Stefano Zacchiroli wrote:
> > The main decision which needs to be made is whether, as a project, we
> > want source only uploads or to throw away DD built non-all debs.
> > There's not entire agreement amongst the ftpmasters about
s all possible
source-based solutions, are suboptimal. In other words, people seem to
really need per-upload, or even per-batch upload, white listing.
FWIW, I wouldn't like much the idea of introducing yet another list of
people which are allowed to do source only uploads as that would be a
Hi,
Am Mittwoch, den 30.03.2011, 16:18 +0200 schrieb Stefano Zacchiroli:
> The main use case I've seen mentioned on list to favor source only
> uploads over throw away debs is that of "low bandwidth" or "bandwidth
> limits". Most likely, that use case applies
Lars Wirzenius writes ("Re: throw away debs and source only uploads"):
> Most uploads are done using dput or dupload. We could add code to them
> to verify that there's binaries corresponding to the source that is
> about to be built.
We could have the archive scripts in
Le Wed, Mar 30, 2011 at 04:18:34PM +0200, Stefano Zacchiroli a écrit :
>
> Regarding source only upload, well, it's tricky. There is the usual
> tension about the principle desire of trusting every DD to do the right
> thing and the reality-check observation that enabling people to upload
> only s
Paul Wise writes:
> I definitely agree we want to throw away developer-built debs (arch all
> & arch any) in almost all situations.
> I don't think I would want the lintian solution for source-only uploads,
> I would prefer something on a per-upload basis that require
I definitely agree we want to throw away developer-built debs (arch
all & arch any) in almost all situations.
I don't think I would want the lintian solution for source-only
uploads, I would prefer something on a per-upload basis that requires
an explicit human decision per-upload ra
On ke, 2011-03-30 at 17:33 +0100, Ben Hutchings wrote:
> Someone (I forget who) previously suggested that a source-only changes
> file should have to be accompanied by a build log. This would need a
> bit of infrastructure to file the build log away.
Most uploads are done using dput or dupload. W
On Wed, Mar 30, 2011 at 04:18:34PM +0200, Stefano Zacchiroli wrote:
[...]
> Regarding source only upload, well, it's tricky. There is the usual
> tension about the principle desire of trusting every DD to do the right
> thing and the reality-check observation that enabling people to upload
> only s
s of yesteryear).
One possible compromise which I think was already mentioned in one
of the earlier discussions (but now I can't find a reference) was to
initially attempt builds of source-only uploads on one arch and
delay building on the rest until it was proven not to FTBFS. This
strikes a bal
On Mon, Mar 28, 2011 at 03:37:05PM +0100, Mark Hymers wrote:
> Ok, the situation here is the following:
Thanks a lot for taking the time of clarifying.
> The main decision which needs to be made is whether, as a project, we
> want source only uploads or to throw away DD built non
1 - 100 of 192 matches
Mail list logo
