Hi,
My condolences for "too many non-bug bug-reports" :-)
I have no objection to have some mention for the multiarch in
release-notes.
But relaistically, users who do not read NEWS.Debian (very long) will
likely not to read long release-notes :-( So documenting here will have
minimal impact for
On Thu, Dec 11, 2014 at 07:00:34PM +, Steve McIntyre wrote:
> Hi folks,
>
> I'm thinking it might be useful to set up a specific debian-efi
> mailing list to help as a central space for discussion about (U)EFI
> issues and support in Debian.
This sounds very useful to me.
> There's been quit
Package: wnpp
Owner: Axel Beckert
Severity: wishlist
* Package name: libapp-stacktrace-perl
Version : 0.09
Upstream Author : Josh Jore
* URL or Web page : https://metacpan.org/release/App-Stacktrace
* License : Artistic or GPL-1+
Description : Create stack traces of
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 s
On 12/12/14 11:48, Johannes Schauer wrote:
> Debian build profiles can express what USE flags do for Gentoo.
They're not quite the same purpose, because we build one binary package
per architecture, not one set of installed binaries per installation.
Continuing the db5.3 example, we should continu
On Fri, 2014-12-12 10:41:50 +0100, Salvatore Bonaccorso wrote:
> Hi,
>
> On Thu, Dec 11, 2014 at 07:15:17AM +0100, Moritz Muehlenhoff wrote:
>> Package: cpio
>> Severity: grave
>> Tags: security
>>
>> Hi,
>> please see http://seclists.org/fulldisclosure/2014/Nov/74
>> for the original report.
>>
+++ 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
+++ 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 wrote:
> >> On 11.12.2014 19:08, Leif Lindholm wrote:
> >>
> >>> If we could transition this to be able to specify efi-all (or
> >>> whatever) ins
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 debu
On 12/12/14 11:09, Simon McVittie wrote:
> but I'd rather have
>
> Build-Depends: ..., valgrind , ...
Looking at BuildProfileSpec again, that would actually have to be
valgrind
to express (arch-where-valgrind-exists && !stage1). The idea is the same
though.
S
--
To UNSUBSCRIBE, email
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
>
> That way on non-efi implementing architectures the package will get
> stuck in a dep-wait state.
I wou
On 12/12/14 10:40, Johannes Schauer wrote:
> Secondly, what you are expressing with:
>
> valgrind-dev
>
> 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 that's exac
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.
> https://buildd.debian.org/status/package.php?p=gtk-s
Leif Lindholm (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 adding entries for
> If
14 matches
Mail list logo
