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.
>
>
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
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
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,
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
>>>
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,
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!
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
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
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,
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,
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.org/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 derogation
mechan
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 least
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 packages
Hello,
2014-08-15 16:04 GMT+02:00 Ondřej Surý ond...@sury.org:
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
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
On Tue, 19 Aug 2014, Hector Oron wrote:
2014-08-15 16:04 GMT+02:00 Ondřej Surý ond...@sury.org:
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
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
Hello,
2014-08-13 22:59 GMT+02:00 Philipp Kern pk...@debian.org:
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
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 but on
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.
I
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 too
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
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 ans...@debian.org:
We will allow not including arch:all packages in
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,
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 build
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 so
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=-g
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
Hello,
2014-08-01 9:37 GMT+02:00 Ansgar Burchardt ans...@debian.org:
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 -.. . -... .. .- -. -.. . ...- . .-.. ---
Hi,
On 08/12/2014 12:33, Hector Oron wrote:
2014-08-01 9:37 GMT+02:00 Ansgar Burchardt ans...@debian.org:
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
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 an
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
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 ?
Ansgar Burchardt ans...@debian.org (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 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 ans...@debian.org:
Hi,
as a first step towards source-only uploads, the archive will now accept
source-only uploads provided the following conditions
].
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 name, type, section and priority
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 and
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 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:
[...]
whoooh! Yay! Thanks a lot to those
Hi,
Kurt Roeckx k...@roeckx.be 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
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,
On Sun, Aug 3, 2014 at 8:13 PM, Joey Hess jo...@debian.org 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,
with bootstrapping, but it turns out that I also want this
for source-only uploads to catch uploads introducing NEW binary packages.
Hi Ansgar, Martin, and Policy Editors,
here is a proposed update for the description of the Package-List field
in the Policy's section 5.6.27. (patch attached
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.
* Architecture-independent (arch:all
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 NEW and does not build NEW binaries
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:
* The source package is not NEW and does
also sprach Ansgar Burchardt ans...@debian.org [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
On Fri, Aug 1, 2014 at 4:38 PM, martin f krafft wrote:
also sprach Ansgar Burchardt ans...@debian.org [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
also sprach Paul Wise p...@debian.org [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
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*
news
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 this
for source-only uploads to catch uploads introducing NEW binary packages.
Ansgar
[1
Thanks a lot; this is great news!
Richard
Sent by mobile; excuse my brevity.
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
source-only uploads provided the following
* Kurt Roeckx k...@roeckx.be, 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
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 should be building locally
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 more
]] 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 being
a DSA
Thomas Goirand zigo at 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
On 25/11/12 00:00, Thorsten Glaser wrote:
Thomas Goirandzigoat 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
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, can we have this as a
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 or
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.asc
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 w...@wrar.name 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
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 w...@wrar.name wrote:
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 release
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?
Both.
On 20 November 2012 12:23, Henrique de Moraes Holschuh h...@debian.org 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
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 host running Debian's kernel
On 20 November 2012 11:14, Andrey Rahmatullin w...@wrar.name 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 currently do not have facilities to build
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-only
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.
source+all 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 to be followed by binNMU, some others not to be followed by
binNMU.
Best regards,
--
Héctor
* 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. [Are
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, but they
* 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 mentioned.
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 DD built non-all debs.
There's
On 2011-06-06, Guillem Jover guil...@debian.org 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
On Mon, 2011-06-06 at 09:03:00 +, Philipp Kern wrote:
On 2011-06-06, Guillem Jover guil...@debian.org 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
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
want source only uploads or to throw
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
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
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 this (I err
on the side
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
.
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 mechanically fetch
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
potential
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 insist that the .debs have
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 to very few people and the
vast majority
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-all debs.
There's
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 balance between wasting buildd
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
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. We
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 rather than
Paul Wise p...@debian.org 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 requires an explicit
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
1 - 100 of 193 matches
Mail list logo
