[gentoo-dev] Last rites: dev-ruby/ruby-webkit-gtk and dev-ruby/ruby-webkit-gtk2
# Hans de Graaff (03 Mar 2017) # Masked for removal in 30 days. # Bindings for old webkit versions that have open security # issues. No reverse dependencies. Bug #608608 dev-ruby/ruby-webkit-gtk dev-ruby/ruby-webkit-gtk2 signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: media-video/lives
# Andreas Sturmlechner (03 Mar 2017) # Masked for removal in 30 days. Reported to be broken; # QA issues, fails to build with GCC-5, ffmpeg-3 # Bugs #608408, #569958, #610746 media-video/lives
[gentoo-dev] Last-rites: x11-misc/andromeda
# Andreas Sturmlechner (03 Mar 2017) # Masked for removal in 30 days. Dead upstream, Qt4Webkit, # fails to build. Bug #602260 x11-misc/andromeda
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Thu, 2 Mar 2017 17:36:16 -0500 Michael Orlitzky wrote: > On 03/02/2017 04:53 PM, Alexis Ballier wrote: > >> > >> Back on topic: > >> > >> What kind of dependency do we need, anyway? William, are you saying > >> that if I upgrade dev-lang/go, then things will break, but if I > >> delete dev-lang/go, everything is fine? > > > > It's likely like ocaml: you link your programs ~ statically but > > everything you link needs to be built with the same compiler. So > > that'd be some kind of "build against"-RDEPEND. > > > > The tiny practical part of me thinks it's probably better to add > dev-lang/go:= to RDEPEND than it is to create an entirely new class of > dependencies to handle this. That's what I do with ocaml, it works pretty well :) My rationale is that for size-constrained installs (embedded, containers, etc.) you'd have to remove everything you don't need anyway (/usr/include, gcc, etc.) so one more or one less does not make a difference. And for normal gentoo installs, you'd want to upgrade, so better not waste your time uninstalling and reinstalling it every time. Nevertheless, build-against deps are still useful. Think of a lib #including eigen in its public headers. Is eigen a build or run depend ? It's in-between: build-against :) Alexis.
Re: [gentoo-dev] Suggested sync method/Portage config for devs on ~arch?
On Tue, 28 Feb 2017 11:14:47 +0100 Thomas Deutschmann wrote: > On 2017-02-28 10:52, James Le Cuirot wrote: > > I use hasufell's repo too. I'm surprised we haven't made it more > > official. > > The public Gentoo git mirror is > > https://github.com/gentoo-mirror/gentoo Please note that this is _mirror_. Gentoo infra provides official synchronization friendly git repository: https://gitweb.gentoo.org/repo/sync/gentoo.git/ It contains all caches and metadata pregenerated each ~20 min interval and allows our users to easily use Gentoo without any dependency on proprietary Github solution. Best regards, Andrew Savchenko pgp0COruda1qF.pgp Description: PGP signature
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 04:53 PM, Alexis Ballier wrote: >> >> Back on topic: >> >> What kind of dependency do we need, anyway? William, are you saying >> that if I upgrade dev-lang/go, then things will break, but if I delete >> dev-lang/go, everything is fine? > > It's likely like ocaml: you link your programs ~ statically but > everything you link needs to be built with the same compiler. So > that'd be some kind of "build against"-RDEPEND. > The tiny practical part of me thinks it's probably better to add dev-lang/go:= to RDEPEND than it is to create an entirely new class of dependencies to handle this.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Thu, 2 Mar 2017 16:46:22 -0500 Michael Orlitzky wrote: > On 03/02/2017 04:30 PM, Ciaran McCreesh wrote: > > > > The point is to specify dependencies declaratively. A dependency > > expresses a dependency, not an action. If you can't express the > > kind of dependency you need, then we need either labels or another > > *DEPEND variable to take care of it, not a bodge. > > > > In the meantime, if you give people an official bodge-maker, they'll > use it. > > Back on topic: > > What kind of dependency do we need, anyway? William, are you saying > that if I upgrade dev-lang/go, then things will break, but if I delete > dev-lang/go, everything is fine? It's likely like ocaml: you link your programs ~ statically but everything you link needs to be built with the same compiler. So that'd be some kind of "build against"-RDEPEND.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 04:30 PM, Ciaran McCreesh wrote: > > The point is to specify dependencies declaratively. A dependency > expresses a dependency, not an action. If you can't express the kind of > dependency you need, then we need either labels or another *DEPEND > variable to take care of it, not a bodge. > In the meantime, if you give people an official bodge-maker, they'll use it. Back on topic: What kind of dependency do we need, anyway? William, are you saying that if I upgrade dev-lang/go, then things will break, but if I delete dev-lang/go, everything is fine?
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Thu, 2 Mar 2017 13:06:45 -0800 Zac Medico wrote: > On 03/02/2017 11:24 AM, Michael Orlitzky wrote: > > On 03/02/2017 02:05 PM, Zac Medico wrote: > >>> > >>> This is why we can't have nice things. > >> > >> For those that are interested, I'm planning to to make --with-bdeps > >> automatically enabled when possible: > >> > > > > > > I agree with this ^ but I don't think portage should rebuild for > > DEPEND at all. It creates one more dangerous "it works in portage!" > > situation that will plague users of other package managers. > > > > (I'm not saying it couldn't be useful, but it should go in the next > > EAPI if we're gonna do it.) > > PMS doesn't specify when rebuilds are supposed to be triggered. You > can consider the rebuilds as a means to satisfy the dependencies. > Saying that the package manager should not make an effort to satisfy > dependencies would be silly. And then have a nice ref. implementation for next EAPI. Having barely tested (*) features set in stone at each EAPI bump is even more dangerous than the "it works in portage!" situations IMHO. (*) I'm not saying features are not tested, but those that have been thrown at users for years are much more mature than the brand new ones in comparison.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Thu, 2 Mar 2017 16:25:54 -0500 Michael Orlitzky wrote: > On 03/02/2017 04:06 PM, Zac Medico wrote: > >> > >> I agree with this ^ but I don't think portage should rebuild for > >> DEPEND at all. It creates one more dangerous "it works in > >> portage!" situation that will plague users of other package > >> managers. > >> > >> (I'm not saying it couldn't be useful, but it should go in the > >> next EAPI if we're gonna do it.) > > > > PMS doesn't specify when rebuilds are supposed to be triggered. You > > can consider the rebuilds as a means to satisfy the dependencies. > > Saying that the package manager should not make an effort to satisfy > > dependencies would be silly. > > It doesn't violate the PMS to do the extra rebuilds, but the PMS also > doesn't say that they should happen. > > Hypothetical situation: a developer notices that Go packages need to > be rebuilt when the compiler changes, so he adds subslot operators to > DEPEND and everything looks fine. Until someone with a different > package manager tries to use it, that is; the rebuilds aren't > triggered unless you're using portage. The point is to specify dependencies declaratively. A dependency expresses a dependency, not an action. If you can't express the kind of dependency you need, then we need either labels or another *DEPEND variable to take care of it, not a bodge. -- Ciaran McCreesh
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 04:06 PM, Zac Medico wrote: >> >> I agree with this ^ but I don't think portage should rebuild for DEPEND >> at all. It creates one more dangerous "it works in portage!" situation >> that will plague users of other package managers. >> >> (I'm not saying it couldn't be useful, but it should go in the next EAPI >> if we're gonna do it.) > > PMS doesn't specify when rebuilds are supposed to be triggered. You can > consider the rebuilds as a means to satisfy the dependencies. Saying > that the package manager should not make an effort to satisfy > dependencies would be silly. It doesn't violate the PMS to do the extra rebuilds, but the PMS also doesn't say that they should happen. Hypothetical situation: a developer notices that Go packages need to be rebuilt when the compiler changes, so he adds subslot operators to DEPEND and everything looks fine. Until someone with a different package manager tries to use it, that is; the rebuilds aren't triggered unless you're using portage.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 11:24 AM, Michael Orlitzky wrote: > On 03/02/2017 02:05 PM, Zac Medico wrote: >>> >>> This is why we can't have nice things. >> >> For those that are interested, I'm planning to to make --with-bdeps >> automatically enabled when possible: >> > > > I agree with this ^ but I don't think portage should rebuild for DEPEND > at all. It creates one more dangerous "it works in portage!" situation > that will plague users of other package managers. > > (I'm not saying it couldn't be useful, but it should go in the next EAPI > if we're gonna do it.) PMS doesn't specify when rebuilds are supposed to be triggered. You can consider the rebuilds as a means to satisfy the dependencies. Saying that the package manager should not make an effort to satisfy dependencies would be silly. -- Thanks, Zac
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 02:05 PM, Zac Medico wrote: >> >> This is why we can't have nice things. > > For those that are interested, I'm planning to to make --with-bdeps > automatically enabled when possible: > I agree with this ^ but I don't think portage should rebuild for DEPEND at all. It creates one more dangerous "it works in portage!" situation that will plague users of other package managers. (I'm not saying it couldn't be useful, but it should go in the next EAPI if we're gonna do it.)
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 06:47 AM, Michael Orlitzky wrote:
> On 03/02/2017 09:24 AM, Mike Gilbert wrote:
>>>
>>> In other words, the ":=" only does something special in RDEPEND. That
>>> makes sense when you think of it as meaning "the thing will break"
>>> rather than "I want to do a rebuild." The only reason it's not an error
>>> to put them in DEPEND is because it would annoy everyone doing
>>> DEPEND="${RDEPEND}".
>>
>> Portage has interesting behavior for ":=" in DEPEND: it varies
>> depending on your "with-bdeps" setting.
>>
>
> This is why we can't have nice things.
For those that are interested, I'm planning to to make --with-bdeps
automatically enabled when possible:
https://bugs.gentoo.org/show_bug.cgi?id=598444#c4
I hope to implement this very soon, to be included in the next portage
release.
--
Thanks,
Zac
Re: [gentoo-dev] profiles/arch/amd64/no-multilib cleanup WAS: [PATCH 1/8] profiles/hardened: Include base amd64-multilib profile in subprofile
W dniu 02.03.2017, czw o godzinie 15∶09 +0100, użytkownik Michael Haubenwallner napisał: > On 01/21/2017 11:59 PM, Michał Górny wrote: > > Include arch/amd64/no-multilib in the hardened no-multilib amd64 > > variant. Confirmed with profile-dumper that it does not currently change > > anything. > > --- > > profiles/hardened/linux/amd64/no-multilib/parent | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/profiles/hardened/linux/amd64/no-multilib/parent > > b/profiles/hardened/linux/amd64/no-multilib/parent > > index 8305c3556463..0defac31415d 100644 > > --- a/profiles/hardened/linux/amd64/no-multilib/parent > > +++ b/profiles/hardened/linux/amd64/no-multilib/parent > > @@ -1,2 +1,3 @@ > > +../../../../arch/amd64/no-multilib > > .. > > > > As hardened/linux/amd64 does inherit arch/amd64, this way arch/amd64 > always overrides arch/amd64/no-multilib, rendering the latter useless. > > Instead, profiles/hardened/linux/amd64/no-multilib/parent should read: > .. > ../../../../arch/amd64/no-multilib > > Beyond that: > While arch/amd64/no-multilib of course _is_ an override to arch/amd64, > question is whether it also should _perform_ the override by itself. > > Currently it does perform the override, causing lots of subsequent profiles > to end up with arch/amd64 inherited multiple times - most prominent is the > default/linux/amd64/13.0/no-multilib profile. > > So removing arch/amd64/no-multilib/parent would simplify things here. > > Thoughts? I was considering that as well but I didn't really have time to look into it properly. If it doesn't break anything, it's fine with me. You may want to talk with arch team first, though. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Thu, 2 Mar 2017 14:56:37 +
Ciaran McCreesh wrote:
> On Thu, 2 Mar 2017 09:47:35 -0500
> Michael Orlitzky wrote:
> > On 03/02/2017 09:24 AM, Mike Gilbert wrote:
> > >>
> > >> In other words, the ":=" only does something special in RDEPEND.
> > >> That makes sense when you think of it as meaning "the thing will
> > >> break" rather than "I want to do a rebuild." The only reason it's
> > >> not an error to put them in DEPEND is because it would annoy
> > >> everyone doing DEPEND="${RDEPEND}".
> > >
> > > Portage has interesting behavior for ":=" in DEPEND: it varies
> > > depending on your "with-bdeps" setting.
> > >
> >
> > This is why we can't have nice things.
>
> Actually you can't have nice things because the labels proposal was
> voted down for "being invented by the wrong people".
Don't get too much into conspiracy theories, I think it has been
dismissed because it would require rewriting every dependency and
there has not been any portage implementation afaik.
Instead of that, people seem to prefer having [A-Z]DEPEND :)
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Thu, 2 Mar 2017 09:47:35 -0500
Michael Orlitzky wrote:
> On 03/02/2017 09:24 AM, Mike Gilbert wrote:
> >>
> >> In other words, the ":=" only does something special in RDEPEND.
> >> That makes sense when you think of it as meaning "the thing will
> >> break" rather than "I want to do a rebuild." The only reason it's
> >> not an error to put them in DEPEND is because it would annoy
> >> everyone doing DEPEND="${RDEPEND}".
> >
> > Portage has interesting behavior for ":=" in DEPEND: it varies
> > depending on your "with-bdeps" setting.
> >
>
> This is why we can't have nice things.
Actually you can't have nice things because the labels proposal was
voted down for "being invented by the wrong people".
--
Ciaran McCreesh
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 09:24 AM, Mike Gilbert wrote:
>>
>> In other words, the ":=" only does something special in RDEPEND. That
>> makes sense when you think of it as meaning "the thing will break"
>> rather than "I want to do a rebuild." The only reason it's not an error
>> to put them in DEPEND is because it would annoy everyone doing
>> DEPEND="${RDEPEND}".
>
> Portage has interesting behavior for ":=" in DEPEND: it varies
> depending on your "with-bdeps" setting.
>
This is why we can't have nice things.
From recruiting-simplifies+bncbczi37v74ejrbhpb4dcqkgqevmgh...@googlegroups.com
Thu Mar 02 06:48:21 2017
Return-path:
Envelope-to: arch...@mail-archive.com
Delivery-date: Thu, 02 Mar 2017 06:48:21 -0800
Received: from c7-b.mxthunder.net ([208.53.48.218])
by mail-archive.com with esmtp (Exim 4.76)
(envelope-from
)
id 1cjS1l-0004Mw-J8
for arch...@mail-archive.com; Thu, 02 Mar 2017 06:48:21 -0800
Received: by bolt10b.mxthunder.net (Postfix, from userid 12345)
id 3vYwCz12fsz1x6S9; Thu, 2 Mar 2017 06:48:03 -0800 (PST)
Received: from mail-ot0-f185.google.com (mail-ot0-f185.google.com
[74.125.82.185])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by bolt10b.mxthunder.net (Postfix) with ESMTPS id 3vYwCf50k0z1w6cq
for ; Thu, 2 Mar 2017 06:47:58 -0800 (PST)
Received: by mail-ot0-f185.google.com with SMTP id i1sf42597331ota.0
for ; Thu, 02 Mar 2017 06:47:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20161025;
h=sender:message-id:date:subject:from:reply-to:mime-version
:content-transfer-encoding:feedback-id:x-original-sender
:x-original-authentication-results:precedence:mailing-list:list-id
:x-spam-checked-in-group:list-post:list-help:list-archive
:list-unsubscribe;
bh=uzvc0Q02asumLIIfovb8DCn3aEcZPE52kTwHSzf5HgM=;
b=LrohXxoiE/IS0VIzh1kiidCKSdQH5/ltxfaHDjfnhj4OhpTGSKnDWLhijp0zYieErP
G8efzJZBbR3q+i4ynrbGGlGLdtrZlau3ePYfHFWt3B7i3xwvdgO5g6rPHfKxkieWJyyc
CptEmLEUxscTmpc2zMVBjZcXBTqGDh7aBYbzFjbtiKq4563dl5LIpNGMOdjmgvu1DagE
vgxCngrAdowlAwm+clMHsvnqzsMfWeS3UF3NCZ1y+F1CU8zvLZtel4utqT4caEcn7f73
x0WZPUSce/4GF+/TlPsLVhpNg29e45c90g8i3do9FcLOg0u9qKdOLV8m6sWY158yMWob
iipQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=sender:x-gm-message-state:message-id:date:subject:from:reply-to
:mime-version:content-transfer-encoding:feedback-id
:x-original-sender:x-original-authentication-results:precedence
:mailing-list:list-id:x-spam-checked-in-group:list-post:list-help
:list-archive:list-unsubscribe;
bh=uzvc0Q02asumLIIfovb8DCn3aEcZPE52kTwHSzf5HgM=;
b=CRGSKoKvisS5r6a3Tg9AdzSi8JuvUrH3YO/iQgxigotVNGwU1ka9OB6qQCBmrPFTZ6
+wRaFulb/NI8c+qDIqxq2YGHFeuHSEgqnAsH1F06UEXUwZZdZFdhqQHdy3qvRNbiVFsr
dD7IDZW3xVJVeUs65oFGUBXgPGht8a4rWtYzlLQ1vLbWJXKQ6DxsxmHVpML5vtPgsns2
t9L7zhIqvV+oBr/kZByZLjMbIkp+H/M01Hu/bDBiX0qwcQVFpStTx6+7cUSApUZXUsPF
mv+pLBhVVJ+iy0eBoT6ze3AoEdHFnFvbAUKBs296ZTEu5JWgF35sXyNHuENqcQKf4E9u
PfAQ==
Sender: recruiting-simplif...@googlegroups.com
X-Gm-Message-State:
AMke39mzTJPQ8HlkO4TvxDIFEaJE+EM/G5GdlrBEcI7wFP06h/n3Bp0NheTOHKJYnyaJqQ==
X-Received: by 10.36.25.140 with SMTP id b134mr749103itb.6.1488466078157;
Thu, 02 Mar 2017 06:47:58 -0800 (PST)
X-BeenThere: recruiting-simplif...@googlegroups.com
Received: by 10.107.134.99 with SMTP id i96ls2076467iod.1.gmail; Thu, 02 Mar
2017 06:47:57 -0800 (PST)
X-Received: by 10.107.47.2 with SMTP id j2mr2693169ioo.74.1488466077742;
Thu, 02 Mar 2017 06:47:57 -0800 (PST)
Received: from a10-127.smtp-out.amazonses.com (a10-127.smtp-out.amazonses.com.
[54.240.10.127])
by gmr-mx.google.com with ESMTPS id r6si907363ywb.6.2017.03.02.06.47.57
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Thu, 02 Mar 2017 06:47:57 -0800 (PST)
Received-SPF: pass (google.com: domain of
0100015a8f7de508-59f183c1-021f-4d2c-bcff-9b4935b43c6d-000...@amazonses.com
designates 54.240.10.127 as permitted sender) client-ip=54.240.10.127;
Message-ID:
<0100015a8f7de508-59f183c1-021f-4d2c-bcff-9b4935b43c6d-000...@email.amazonses.com>
Date: Thu, 2 Mar 2017 14:47:56 +
Subject: Recruiting-Simplifies Required: UX Designer with Java Script,
Wireframe experience at Ann Arbor, Michigan - Contract
From: Vamsheedhar
Reply-To: vams...@svktechinc.com
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-SES-Outgoing: 2017.03.02-54.240.10.127
Feedback-ID: 1.us-east-1.BO8466vaYeUUNkpWGH0T2SyjKobAnSC2l7VlzcJ44uA=:AmazonSES
X-Original-Sender: grou...@rekruiteasy.com
X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass
header.i=@amazonses.com; spf=pass (google.com: domain of
01
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Thu, Mar 2, 2017 at 9:03 AM, Michael Orlitzky wrote:
> On 03/02/2017 04:58 AM, Alexis Ballier wrote:
>>
>> Is it really abusing ?
>> := deps in DEPEND only would also make sense for e.g. code generators
>>
>
> Slot operator dependencies are ignored in DEPEND:
>
> Indicates that any slot value is acceptable. In addition, for runtime
> dependencies, indicates that the package will break unless a matching
> package with slot and sub-slot equal to the slot and sub-slot of the
> best installed version at the time the package was built is available.
>
> In other words, the ":=" only does something special in RDEPEND. That
> makes sense when you think of it as meaning "the thing will break"
> rather than "I want to do a rebuild." The only reason it's not an error
> to put them in DEPEND is because it would annoy everyone doing
> DEPEND="${RDEPEND}".
Portage has interesting behavior for ":=" in DEPEND: it varies
depending on your "with-bdeps" setting.
floppym@naomi ~ % emerge -uDpv --with-bdeps=n @world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] dev-lang/go-1.8:0/1.8::gentoo [1.7.5:0/1.7.5::gentoo]
USE="-gccgo" 0 KiB
Total: 1 package (1 upgrade), Size of downloads: 0 KiB
floppym@naomi ~ % emerge -uDpv --with-bdeps=y @world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild r U ] dev-lang/go-1.8:0/1.8::gentoo [1.7.5:0/1.7.5::gentoo]
USE="-gccgo" 0 KiB
[ebuild rR] app-admin/cli53-0.8.7::gentoo 0 KiB
Total: 2 packages (1 upgrade, 1 reinstall), Size of downloads: 0 KiB
The following packages are causing rebuilds:
(dev-lang/go-1.8:0/1.8::gentoo, ebuild scheduled for merge) causes
rebuilds for:
(app-admin/cli53-0.8.7:0/0::gentoo, ebuild scheduled for merge)
[gentoo-dev] profiles/arch/amd64/no-multilib cleanup WAS: [PATCH 1/8] profiles/hardened: Include base amd64-multilib profile in subprofile
On 01/21/2017 11:59 PM, Michał Górny wrote: > Include arch/amd64/no-multilib in the hardened no-multilib amd64 > variant. Confirmed with profile-dumper that it does not currently change > anything. > --- > profiles/hardened/linux/amd64/no-multilib/parent | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/profiles/hardened/linux/amd64/no-multilib/parent > b/profiles/hardened/linux/amd64/no-multilib/parent > index 8305c3556463..0defac31415d 100644 > --- a/profiles/hardened/linux/amd64/no-multilib/parent > +++ b/profiles/hardened/linux/amd64/no-multilib/parent > @@ -1,2 +1,3 @@ > +../../../../arch/amd64/no-multilib > .. > As hardened/linux/amd64 does inherit arch/amd64, this way arch/amd64 always overrides arch/amd64/no-multilib, rendering the latter useless. Instead, profiles/hardened/linux/amd64/no-multilib/parent should read: .. ../../../../arch/amd64/no-multilib Beyond that: While arch/amd64/no-multilib of course _is_ an override to arch/amd64, question is whether it also should _perform_ the override by itself. Currently it does perform the override, causing lots of subsequent profiles to end up with arch/amd64 inherited multiple times - most prominent is the default/linux/amd64/13.0/no-multilib profile. So removing arch/amd64/no-multilib/parent would simplify things here. Thoughts? /haubi/ From 9457fd8eb330a94a15bb91decec522fe1c027986 Mon Sep 17 00:00:00 2001 From: Michael Haubenwallner Date: Thu, 2 Mar 2017 13:52:58 +0100 Subject: [PATCH] profiles/hardened/linux/amd64/no-multilib: inherit arch/amd64/no-multilib late Whether arch/amd64/no-multilib does _inherit_ arch/amd64 or not, arch/amd64/no-multilib does _extend_ arch/amd64 anyway. So inheriting arch/amd64/no-multilib before arch/amd64 always will reset the arch/amd64/no-multilib to the arch/amd64 values. --- profiles/hardened/linux/amd64/no-multilib/parent | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/profiles/hardened/linux/amd64/no-multilib/parent b/profiles/hardened/linux/amd64/no-multilib/parent index 2909df6..9bf59c5 100644 --- a/profiles/hardened/linux/amd64/no-multilib/parent +++ b/profiles/hardened/linux/amd64/no-multilib/parent @@ -1,2 +1,2 @@ -../../../../arch/amd64/no-multilib .. +../../../../arch/amd64/no-multilib -- 2.10.2 From 3f8eb7869937d6da2f79b0a6eeb448f6eedea7b3 Mon Sep 17 00:00:00 2001 From: Michael Haubenwallner Date: Thu, 2 Mar 2017 14:45:16 +0100 Subject: [PATCH] profiles/arch/amd64/no-multilib: do not inherit arch/amd64 While arch/amd64/no-multilib of course _is_ an override to arch/amd64, is should not _perform_ the override by itself, as that causes lots of subsequent profiles to end up with arch/amd64 inherited multiple times, most prominent is the default/linux/amd64/13.0/no-multilib profile. --- profiles/arch/amd64/no-multilib/parent | 1 - 1 file changed, 1 deletion(-) delete mode 100644 profiles/arch/amd64/no-multilib/parent diff --git a/profiles/arch/amd64/no-multilib/parent b/profiles/arch/amd64/no-multilib/parent deleted file mode 100644 index f3229c5.. --- a/profiles/arch/amd64/no-multilib/parent +++ /dev/null @@ -1 +0,0 @@ -.. -- 2.10.2
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 04:58 AM, Alexis Ballier wrote:
>
> Is it really abusing ?
> := deps in DEPEND only would also make sense for e.g. code generators
>
Slot operator dependencies are ignored in DEPEND:
Indicates that any slot value is acceptable. In addition, for runtime
dependencies, indicates that the package will break unless a matching
package with slot and sub-slot equal to the slot and sub-slot of the
best installed version at the time the package was built is available.
In other words, the ":=" only does something special in RDEPEND. That
makes sense when you think of it as meaning "the thing will break"
rather than "I want to do a rebuild." The only reason it's not an error
to put them in DEPEND is because it would annoy everyone doing
DEPEND="${RDEPEND}".
[gentoo-dev] Re: [PATCH 1/4] profiles/prefix: Add arch/base to parent
On 02/13/2017 03:40 PM, Michał Górny wrote: > --- > profiles/prefix/parent | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/profiles/prefix/parent b/profiles/prefix/parent > index 8f0e9fd7471d..3eaf2c441360 100644 > --- a/profiles/prefix/parent > +++ b/profiles/prefix/parent > @@ -1 +1,2 @@ > +../arch/base > ../features/prefix/rpath > This causes duplicate inheritance of arch/base for prefix/linux/* profiles, as they get arch/base via default/linux/* anyway. Fixed in https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3bf75385caac73e1ffb7035b37add91ef57583fe /haubi/
Re: [gentoo-dev] [PATCH 1/1] eclass/kernel-2: Add additional help text when K_SECURITY_UNSUPPORTED is set
On Thu, Mar 2, 2017 at 9:09 AM, Mike Pagano wrote:
> This patch will add some additional text to bring some additional notice
> to users
> about the security considerations of a specific kernel and direct them
> to the
> upstream website for further information. See bug #599454
>
> Signed-off-by: Mike Pagano
> ---
> eclass/kernel-2.eclass | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index e95ec07..2aaab58 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -1054,6 +1054,12 @@ postinst_sources() {
> # And now the general message.
> if [[ -n ${K_SECURITY_UNSUPPORTED} ]]; then
> ewarn "This means that it is likely to be vulnerable to recent
> security issues."
> + echo
> + ewarn "Upstream kernel developers recommend always running
> the latest "
> + ewarn "release of any current long term supported Linux
> kernel version."
> + ewarn "To see a list of these versions, their most current
> release and "
> + ewarn "long term support status, please go to
> https://www.kernel.org ."
> + echo
> ewarn "For specific information on why this kernel is
> unsupported,
> please read:"
> ewarn "https://wiki.gentoo.org/wiki/Project:Kernel_Security";
> fi
> --
> 2.10.2
>
>
looks like a nice idea.
+1
--
アリス フェッラッツィ
Alice Ferrazzi
Gentoo Kernel Project Leader
Mail: Alice Ferrazzi
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Wed, 1 Mar 2017 18:18:01 -0600 William Hubbs wrote: > To avoid abusing slot dependencies for dev-lang/go since it is not > needed at runtime I need to do the following. Is it really abusing ? := deps in DEPEND only would also make sense for e.g. code generators
