On Thu, Feb 07, 2013 at 11:11:22PM -0400, Joey Hess wrote:
> Ben Hutchings wrote:
> > What I mean is that a changes file for a sourceful upload has
> > 'source' (and maybe some real architecture names) in the Architecture
> > field. Therefore 'source' cannot be assigned as the name of a real
> > a
Am 17.02.2013 20:41, schrieb Philipp Kern:
> On Mon, Feb 11, 2013 at 12:41:26AM +0100, Matthias Klose wrote:
>> Am 10.02.2013 23:31, schrieb Philipp Kern:
>>> On Sun, Feb 10, 2013 at 03:01:21PM +0100, Matthias Klose wrote:
But it is ok to insist on using the exact binary version for
buil
On Mon, Feb 11, 2013 at 12:41:26AM +0100, Matthias Klose wrote:
> Am 10.02.2013 23:31, schrieb Philipp Kern:
> > On Sun, Feb 10, 2013 at 03:01:21PM +0100, Matthias Klose wrote:
> >> But it is ok to insist on using the exact binary version for
> >> build-depending on source packages when it's not ne
Cyril Brulebois dixit:
>In the meantime, dear Thorsten Glaser, please do figure out that
>mailing debian-devel@ is *not* the way to reach buildd admins.
I know, and it wasn’t the goal of that mail. I already contacted
those in question once.
bye,
//mirabilos
--
„nein: BerliOS und Sourceforge si
Thorsten Glaser (17/02/2013):
> So please brainstorm on a fix. In the meantime, dear fellow
> buildd admins, please do run apt-get dist-upgrade (following
> an apt-get update if you don’t persist those) in *all* of your
> buildd chroots frequently and handle those REJECTs caused by
> Built-Using b
Matthias Klose debian.org> writes:
> maybe it's a coincidence, however creduce was formerly rejected for not having
> a Built-Using attribute, and gcj-4.8, gnat-4.7 and gnat-4.8 are still in NEW.
There’s another REJECT issue in the other direction:
Some buildds do not keep their chroots up to d
On Sat, Feb 09, 2013 at 03:42:38AM +0100, Andreas Beckmann wrote:
> Can't we just annotate the foo-source binary package in some way - it
> should be pretty clear to the maintainer that he produces such a
> "special" package. Then for building other packages B-D-ing on the
> "special" package we co
Am 10.02.2013 23:31, schrieb Philipp Kern:
> On Sun, Feb 10, 2013 at 03:01:21PM +0100, Matthias Klose wrote:
>> But it is ok to insist on using the exact binary version for
>> build-depending on source packages when it's not needed? This only seems
>> to be driven by the current dak implementation.
On Sun, Feb 10, 2013 at 03:01:21PM +0100, Matthias Klose wrote:
> But it is ok to insist on using the exact binary version for build-depending
> on source packages when it's not needed? This only seems to be driven by the
> current dak implementation.
That doesn't make sense to me. Where did someb
Matthias Klose writes:
> But it is ok to insist on using the exact binary version for
> build-depending on source packages when it's not needed? This only seems
> to be driven by the current dak implementation.
That does matter if the included source is GPL, and I suspect part of the
problem is
Am 09.02.2013 19:01, schrieb Philipp Kern:
> On Sat, Feb 09, 2013 at 11:16:30PM +0800, Chow Loong Jin wrote:
>> On 09/02/2013 08:38, Russ Allbery wrote:
>>> The proposal made in the Policy bug, which seems quite reasonable to
>>> me, is that we should only annotate packages with Built-Using if ther
On Sat, Feb 09, 2013 at 11:16:30PM +0800, Chow Loong Jin wrote:
> On 09/02/2013 08:38, Russ Allbery wrote:
> > The proposal made in the Policy bug, which seems quite reasonable to me,
> > is that we should only annotate packages with Built-Using if there are
> > license implications to the inclusio
On Sat, Feb 09, 2013 at 11:16:30PM +0800, Chow Loong Jin wrote:
> On 09/02/2013 08:38, Russ Allbery wrote:
> > The proposal made in the Policy bug, which seems quite reasonable to me,
> > is that we should only annotate packages with Built-Using if there are
> > license implications to the inclusio
On 09/02/2013 08:38, Russ Allbery wrote:
> The proposal made in the Policy bug, which seems quite reasonable to me,
> is that we should only annotate packages with Built-Using if there are
> license implications to the inclusion of the source. Documenting things
> like libgcc.a that have explicit,
Andreas Beckmann wrote:
> Can't we just annotate the foo-source binary package in some way - it
> should be pretty clear to the maintainer that he produces such a
> "special" package.
No, because it's not just foo-source packages.
One example of a package that needs to use built-using is
debian-
On 2013-02-09 01:38, Russ Allbery wrote:
> Peter Samuelson writes:
>> I'm a bit confused. Given that perhaps 99% of Built-Using would be for
>> trivial things like crt1.o and libgcc.a, which are concentrated into a
>> relatively tiny number of packages, it seems to make more sense to
>> annotate
Peter Samuelson writes:
> [Joachim Breitner]
>> this seems to be a good disk-space for human-time trade to me as well:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699333
> I'm a bit confused. Given that perhaps 99% of Built-Using would be for
> trivial things like crt1.o and libgcc.a, w
[Joachim Breitner]
> this seems to be a good disk-space for human-time trade to me as well:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699333
I'm a bit confused. Given that perhaps 99% of Built-Using would be for
trivial things like crt1.o and libgcc.a, which are concentrated into a
rela
Hi,
Am Donnerstag, den 07.02.2013, 20:51 -0400 schrieb Joey Hess:
> Did occur to me later that another option would be to just generate
> Built-Using for all build dependnecies when the field is turned on in a
> package. This would list too much, but perhaps that wouldn't matter.
> OTOH, perhaps t
Johannes Schauer writes:
> There are apparently currently 67 .*-source.* packages in Debian Sid:
> $ grep-dctrl -P --pattern "-source" -c < Packages
> 67
A bunch of those are kernel module source packages for module-assistant,
so aren't as interesting for this particular purpose. Eyeballing th
Hi,
On Fri, Feb 08, 2013 at 08:36:56AM +0100, Raphael Hertzog wrote:
> On Thu, 07 Feb 2013, Joey Hess wrote:
> > Ben Hutchings wrote:
> > > What I mean is that a changes file for a sourceful upload has
> > > 'source' (and maybe some real architecture names) in the Architecture
> > > field. Theref
On Thu, 07 Feb 2013, Joey Hess wrote:
> Ben Hutchings wrote:
> > What I mean is that a changes file for a sourceful upload has
> > 'source' (and maybe some real architecture names) in the Architecture
> > field. Therefore 'source' cannot be assigned as the name of a real
> > architecture.
>
> Ah,
Ben Hutchings wrote:
> What I mean is that a changes file for a sourceful upload has
> 'source' (and maybe some real architecture names) in the Architecture
> field. Therefore 'source' cannot be assigned as the name of a real
> architecture.
Ah, sure.
However, "source" in Build-Depends could be
On Thu, 2013-02-07 at 20:51 -0400, Joey Hess wrote:
> Ben Hutchings wrote:
> > Or 'source', short for 'the build-dependency's source code should be
> > treated as part of my source code'. This is already reserved as a
> > special architecture name for use in changes file.
>
> Hmm, if it's reserve
Ben Hutchings wrote:
> Or 'source', short for 'the build-dependency's source code should be
> treated as part of my source code'. This is already reserved as a
> special architecture name for use in changes file.
Hmm, if it's reserved, what use it is reserved for? Wouldn't want to
step on toes. I
On Thu, 2013-02-07 at 15:09 -0400, Joey Hess wrote:
> The Built-Using field required[1] by recent policy results in some
> problems for maintainers:
>
> 1. It needs to indicate the exact version of the source package used in
>the build. So this has to be kept up-to-date, or dynamically
>ge
Le Thu, Feb 07, 2013 at 03:09:07PM -0400, Joey Hess a écrit :
> The Built-Using field required[1] by recent policy results in some
> problems for maintainers:
> [1] Or at least encouraged, depending on how policy and the intent of
> policy is interpreted.
Hi Joey,
in section 5.3, that lists
Joey Hess writes:
> We can take advantage of the architecture specification in Build-Depends
> being fairly wide-open. So this should not break existing parsers:
>
> Build-Depends: foo [any built-using], bar [i386 amd64 built-using]
[...]
>
> Alternatively, a package named built-using could be upl
The Built-Using field required[1] by recent policy results in some
problems for maintainers:
1. It needs to indicate the exact version of the source package used in
the build. So this has to be kept up-to-date, or dynamically
generated. Updating it manually is busywork and won't reflect
v
29 matches
Mail list logo
