On Thu, May 14, 2009 at 10:13:43AM +0300, Peter Eisentraut wrote:
On Wednesday 13 May 2009 21:55:00 Guillem Jover wrote:
So, there's missing support in sbuild (#501230), which arguably is
a pretty recent bug report, but AFAIR I sent a mail to Ryan long time
ago when drafting the wildcard
On Fri, May 15, 2009 at 12:28:07PM +0300, Riku Voipio wrote:
On Thu, May 14, 2009 at 10:13:43AM +0300, Peter Eisentraut wrote:
On Wednesday 13 May 2009 21:55:00 Guillem Jover wrote:
So, there's missing support in sbuild (#501230), which arguably is
a pretty recent bug report, but AFAIR I
On Friday 15 May 2009 12:28:07 Riku Voipio wrote:
a release goal is IMHO something that needs fixes in a sweep of
packages in archive before release. This change OTOH just needs fixes
to sbuild and then some infrastructure work (deploying new sbuild/buildd
everywhere).
Per upstream, this
On Wednesday 13 May 2009 21:55:00 Guillem Jover wrote:
So, there's missing support in sbuild (#501230), which arguably is
a pretty recent bug report, but AFAIR I sent a mail to Ryan long time
ago when drafting the wildcard support and never heard back, but then
I never insisted again, so
[Philipp Kern]
Which reminds me: could we please get similar possibilities for the
Architecture line in debian/control? I see more and more expanded
architecture lists because a package is not, say, able to build
on hppa.
I thought in that case we were supposed to use 'any' and add an entry
On Thu, May 14, 2009 at 09:02:52AM -0500, Peter Samuelson wrote:
I thought in that case we were supposed to use 'any' and add an entry
to Packages-arch-specific. Or, if it's just one binary package from a
larger source package, use 'any' and decide in debian/rules whether to
build that binary
brian m. carlson sand...@crustytoothpaste.ath.cx (14/05/2009):
I've worked on FTBFS-with-new-GCC bugs before, and realized only after
putting significant work into the bug that the package didn't build on
amd64, only on i386. Therefore, I think that the package should have
a proper list of
Since etch, dpkg has supported architecture wildcards such as linux-any and
any-powerpc, which can, among other things, be used to express Linux-only
build dependencies like this:
Build-Depends: libcap2-dev [linux-any]
instead of one of the previous approaches:
Build-Depends: libcap2-dev |
On 2009-05-13, Peter Eisentraut pet...@debian.org wrote:
Since etch, dpkg has supported architecture wildcards such as linux-any and
any-powerpc, which can, among other things, be used to express Linux-only
build dependencies like this:
Which reminds me: could we please get similar
Peter Eisentraut pet...@debian.org (13/05/2009):
The latter two approaches have obvious flaws, but it seems that no one is
using
the built-in dpkg approach. Is there anything wrong with it? Are people
just
not aware of it?
People might be using the following, which is slightly better
Cyril Brulebois k...@debian.org (13/05/2009):
dpkg folks haven't been advocating their use, either.
Ah, Phil just mentioned what I had troubles remembering: the fact that
Build-Depends and Architecture can't be handled in a similar fashion.
Mraw,
KiBi.
signature.asc
Description: Digital
Hi!
On Wed, 2009-05-13 at 12:50:03 +0300, Peter Eisentraut wrote:
Since etch, dpkg has supported architecture wildcards such as linux-any and
any-powerpc, which can, among other things, be used to express Linux-only
build dependencies like this:
Build-Depends: libcap2-dev [linux-any]
+ Guillem Jover (Wed, 13 May 2009 20:55:00 +0200):
The wildcards on the binary stanza Architecture fields have also been
supported since the beginning.
What wildcards? The linux-any and powerpc-any ones you mean? AFAIK,
Phil was inquiring about good-old Build-Depends expressions like:
13 matches
Mail list logo
