On Thu, Dec 11, 2014 at 08:49:55PM +, Simon McVittie wrote:
On 11/12/14 18:08, Leif Lindholm wrote:
The point is, when we add support for another architecture which
supports UEFI, there are a number of packages that you will want to
enable for that architecture.
I've occasionally
Hello,
On 12 December 2014 at 11:48, Johannes Schauer j.scha...@email.de wrote:
Hi,
Quoting Simon McVittie (2014-12-12 12:09:05)
Yes, but I think that's exactly what I want for dbus' use-case? I want
to build-depend on valgrind (I thought it was valgrind-dev, but it's
actually valgrind) on
Quoting Joachim Breitner (2014-12-12 13:55:24)
Am Freitag, den 12.12.2014, 12:07 + schrieb Wookey:
+++ Sebastian Reichel [2014-12-11 21:25 +0100]:
How about building for arch: any and adding a build dependency on
a new efi-support package, that is only available for
architectures with
Leif Lindholm leif.lindh...@linaro.org (2014-12-11):
The point is, when we add support for another architecture which
supports UEFI, there are a number of packages that you will want to
enable for that architecture. Currently, this means trawling through
all of the packages and explicitly
Hi,
Quoting Simon McVittie (2014-12-11 21:49:55)
At a source package granularity, you can fake it by having a (possibly
spurious) Build-Depends on the required package, which will put the
requiring package in BD-Uninstallable state (e.g.
On 12/12/14 10:40, Johannes Schauer wrote:
Secondly, what you are expressing with:
valgrind-dev archfeature.valgrind
is that you do or do not depend on the package valgrind-dev depending on
whether or not archfeature.valgrind evaluates to true (however this is
resolved).
Yes, but I think
Hi,
Quoting Dimitri John Ledkov (2014-12-11 22:28:07)
And it will require a long time to be used. Imho this smells more like
a build profile e.g.
BuildDepends: does-not-implement-efi !efi
That way on non-efi implementing architectures the package will get
stuck in a dep-wait state.
I
On 12/12/14 11:09, Simon McVittie wrote:
but I'd rather have
Build-Depends: ..., valgrind arch-where-valgrind-exists !stage1, ...
Looking at BuildProfileSpec again, that would actually have to be
valgrind arch-where-valgrind-exists !stage1
to express (arch-where-valgrind-exists !stage1).
Hi,
Quoting Simon McVittie (2014-12-12 12:09:05)
Yes, but I think that's exactly what I want for dbus' use-case? I want
to build-depend on valgrind (I thought it was valgrind-dev, but it's
actually valgrind) on exactly those architectures to which valgrind has
been ported, so that the debug
+++ Jonas Smedegaard [2014-12-11 21:38 +0100]:
Quoting Neil Williams (2014-12-11 21:07:15)
On Thu, 11 Dec 2014 19:36:19 +0100
Simon Richter s...@debian.org wrote:
On 11.12.2014 19:08, Leif Lindholm wrote:
If we could transition this to be able to specify efi-all (or
whatever)
+++ Sebastian Reichel [2014-12-11 21:25 +0100]:
Hi,
How about building for arch: any and adding a build dependency
on a new efi-support package, that is only available for
architectures with efi available?
That is a sensible suggestion. It keeps the ecosystem of 'efi stuff'
more
Hi,
Am Freitag, den 12.12.2014, 12:07 + schrieb Wookey:
+++ Sebastian Reichel [2014-12-11 21:25 +0100]:
How about building for arch: any and adding a build dependency
on a new efi-support package, that is only available for
architectures with efi available?
I was about to suggest the
When working on UEFI kernel support, for both armhf and arm64, we came
across packages (in several distributions) that were manually set to
build for architectures where UEFI was available - and so would not be
built for the ARM architectures.
These are some obvious utilites such as:
- efibootmgr
Hi Leif,
On 11.12.2014 19:08, Leif Lindholm wrote:
If we could transition this to be able to specify efi-all (or
whatever) instead of an explicit list of certain architectures, this
would be a lot more straightforward operation.
Would this be useful, desirable, an accident waiting to
Simon Richter wrote:
Hi Leif,
On 11.12.2014 19:08, Leif Lindholm wrote:
If we could transition this to be able to specify efi-all (or
whatever) instead of an explicit list of certain architectures, this
would be a lot more straightforward operation.
Would this be useful, desirable, an
Quoting Simon Richter (2014-12-11 19:36:19)
On 11.12.2014 19:08, Leif Lindholm wrote:
If we could transition this to be able to specify efi-all (or
whatever) instead of an explicit list of certain architectures, this
would be a lot more straightforward operation.
Would this be useful,
On Thu, 11 Dec 2014 19:36:19 +0100
Simon Richter s...@debian.org wrote:
Hi Leif,
On 11.12.2014 19:08, Leif Lindholm wrote:
If we could transition this to be able to specify efi-all (or
whatever) instead of an explicit list of certain architectures, this
would be a lot more
Hi,
On Thu, Dec 11, 2014 at 06:08:58PM +, Leif Lindholm wrote:
When working on UEFI kernel support, for both armhf and arm64, we came
across packages (in several distributions) that were manually set to
build for architectures where UEFI was available - and so would not be
built for the
Quoting Neil Williams (2014-12-11 21:07:15)
On Thu, 11 Dec 2014 19:36:19 +0100
Simon Richter s...@debian.org wrote:
On 11.12.2014 19:08, Leif Lindholm wrote:
If we could transition this to be able to specify efi-all (or
whatever) instead of an explicit list of certain architectures, this
On 11/12/14 18:08, Leif Lindholm wrote:
The point is, when we add support for another architecture which
supports UEFI, there are a number of packages that you will want to
enable for that architecture.
I've occasionally wished we had a way to make a requiring package
conditionally built
On 11 December 2014 at 20:07, Neil Williams codeh...@debian.org wrote:
On Thu, 11 Dec 2014 19:36:19 +0100
Simon Richter s...@debian.org wrote:
Hi Leif,
On 11.12.2014 19:08, Leif Lindholm wrote:
If we could transition this to be able to specify efi-all (or
whatever) instead of an
21 matches
Mail list logo
