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) packages must b
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
Hi,
Quoting Ansgar Burchardt (2014-08-01 12:25:05)
> > I want to understand purpose and syntax of this new field.
>
> The 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 ar
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 conditions are met:
>
> *
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:
> [...]
>
> whoooh! Yay! Thanks a lot
Package: debian-policy
Severity: wishlist
Version: 3.9.5.0
Le Fri, Aug 01, 2014 at 12:25:05PM +0200, Ansgar Burchardt a écrit :
> On 08/01/2014 12:17, martin f krafft wrote:
> > also sprach Paul Wise [2014-08-01 11:33 +0200]:
> * The source package includes a Package-List field that also ha
* 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
> > > source-only uploads provided the f
Thanks a lot; this is great news!
Richard
Sent by mobile; excuse my brevity.
On 08/01/2014 12:17, martin f krafft wrote:
> 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
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!
chee
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 includes a
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 an
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 b
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:a
43 matches
Mail list logo
