[gentoo-dev] News item: sys-apps/s6 ftrig ABI change

[Luis Ressel]

Hello,

here's a draft for a news item I'd like to publish before bumping
sys-apps/s6 to 2.8.0.0:


Title: sys-apps/s6 2.8 ftrig ABI change 

   
Author: Luis Ressel

   
Posted: 2019-03-??  

   
Revision: 1 

   
News-Item-Format: 2.0   

   
Display-If-Installed: 

[gentoo-dev] Package up for grab: dev-util/rebar

[Luis Ressel]

Hello everyone,

I'm stepping down as the maintainer of dev-util/rebar, since I haven't
been using it for quite a while. I already pointed this
out on this very list a couple of months ago (when djc dropped erlang),
but since noone else showed interest, I've dropped it to m-n now.

rebar itself is EOL, but it can't be lastrited yet due to a number of
revdeps. There's a successor being developed at
https://github.com/erlang/rebar3, but it's not 100% compatible, so it
should probably be added to the tree as a new ebuild or a new slot.
Apart from a request to do this, there are no open bugs.

@aidecoe: CC'ing you as the maintainer of rebar.eclass.


Cheers,
Luis Ressel

Re: [gentoo-dev] The status of grsecurity upstream and hardened-sources downstream

[Luis Ressel]

On Sun, 25 Jun 2017 23:47:48 -0400
Joshua Kinard <ku...@gentoo.org> wrote:

> Safe for now to just switch to gentoo-sources while retaining hardened
> toolchain?  Or would there be a few additional steps needed?  I only
> use PaX for mprotect() and the ALSR capabilities, though I suspect
> those might be in the standard sauce by now.  As such, I haven't had
> to deal with userland issues and PaX too much over the years.

A full rebuild shouldn't be neccessary after a switch to gentoo-sources
or vanilla-sources. At least, I can't think of any reason why it would,
and I haven't encountered any problems after switching on my own hosts.

Just keep in mind that vanilla-sources doesn't support the PaX xattrs
properly (AFAIR), so if you ever want to switch *back* from vanilla to
hardened, some pax markings will be missing. This shouldn't be an issue
for gentoo-sources, though.

Cheers,
Luis Ressel


pgpNbGvSbzkd0.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Luis Ressel]

On Sun, 21 May 2017 10:46:25 -0700
Raymond Jennings <shent...@gmail.com> wrote:

> Just out of curiosity, and for the curious:
> 
> 1.  How often do cache updates happen?
> 2.  How long do they take?
> 3.  Is there any downside to only having one such update running at a
> time and just skipping them if there's already an update pending?

I'm generating metadata locally. There are changes to some of the more
important eclasses roughly every other week; and after such a change,
the regen takes 10-25 minutes on my hardware.

I don't understand your question (3).

Regards,
Luis Ressel


pgpnERfyAGpjK.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [RFC] News item: GCC 6 defaults to USE="pie ssp"

[Luis Ressel]

On Wed, 10 May 2017 07:28:15 + (UTC)
Martin Vaeth <mar...@mvath.de> wrote:

> For instance, you cannot even compile the kernel without special
> patches (which disable pie) if you use a gcc which default-enables
> pie.

Now I'm curious. Wouldn't that also affect the hardened gcc? I've never
had any issues compiling vanilla-sources with my hardened gcc.

Regards,
Luis Ressel


pgpcIzUTAKWA0.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs

[Luis Ressel]

On Thu, 27 Apr 2017 12:58:23 +0200
Dirkjan Ochtman  wrote:

> I also want to drop the following:
> 
> - dev-lang/erlang

It'd be great if whoever takes over maintainership of erlang could also
take care of dev-util/rebar. Dirkjan is currently proxying it for me,
but I don't use it anymore. (In fact, I'd totally forgotten I'm still
the maintainer; djc has handled the updates for the past few years.
Sorry about that, Dirkjan!)

Regards,
Luis


pgpVYsgPDVd3d.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Commit signing for metadata/* repos

[Luis Ressel]

On Sun, 8 Jan 2017 10:40:15 -0500
Mike Gilbert <flop...@gentoo.org> wrote:

> The content of gentoo-news.git should already be covered by the
> detached signatures that are required to be present for each file.
> What is the benefit to requiring the commits themselves be signed?

Oh, I didn't know about those file signatures. But I think signing the
commits would make sense nonetheless, as this offers some advantages:

* Commit signatures are easy to verify: Everyone who is interested in
  verifying their /usr/portage image will already have an infrastructure
  in place to verify commit signatures, because that's how things are
  done for repo/gentoo.git.

* The detached news signatures are nontrivial to verify (in an
  automated fashion): Just looping over all news files in the repo and
  verifying their signatures is not an option, because some of the
  signatures on older news items can't be verified anymore (expired
  keys, signatures by retired devs, etc.). Hence, one will have to
  write some code to verify just the new news items introduced after a
  git pull.

* Commit signatures have slightly better security guarantees: If we
  only verify the detached signatures, attackers can still mess around
  with the commit graph; in particular, an MITM attacker could silently
  drop some of the news during a pull. With commit signatures, the only
  way for the attacker to achieve this is to pretend there aren't any
  new commits at all (something the user would probably notice after a
  while).

At the same time, I don't see any disadvantages to requiring commit
signatures; does anyone else?

Regards,
Luis Ressel

[gentoo-dev] Commit signing for metadata/* repos

[Luis Ressel]

Hello,

there are some additional git repositories which need to be added to
metadata/ subdirectories to make the 'gentoo' git repository usable
for /usr/portage. Specifically, those are dtd, glsa, news and
xml-schema.

It'd be great if developers could sign their commits in these repos,
too. (I don't really care about dtd and xml-schema, but for the other
two, I think this would make much sense.)

Currently, it looks like commits to xml-schema aren't signed at all,
all commits to glsa are signed, and commits to the other two repos are
partly signed.

Regards,
Luis Ressel

Re: [gentoo-dev] Proposal for changes for the next EAPI version

[Luis Ressel]

On Tue, 17 May 2016 13:07:43 +0530
Pallav Agarwal <pallavagarwa...@gmail.com> wrote:

> Tests run in src_test are provided by upstream, and does not
> guarantee that a package that has been merged will actually run on
> the system. If the maintainer could add a couple small scripts to
> check basic functionality of the merged package, it would make
> testing for arch testers much easier and reliable.

Automated post-merge tests sound kinda dangerous to me. And I don't
think there's any stipulation about src_test() only running
upstream-provided test suites. IMHO, src_test() would be a good place
for most of the maintainter-provided tests you have in mind.

Of course, there are some possible tests for which the src_test()
environment isn't suitable (because they're either interactive or
really need to run post-merge), I just don't expect there'd be many of
them. Therefore, I think we'd be better off providing such tests
out-of-band (test plans in the wiki), or perhaps stuffing them into
pkg_config().

Don't get me wrong, I'm not at all opposed to your idea of easing the
ATs' life, I'm just not convinced of the neccessity of EAPI changes. :)


-- 
Regards,
Luis Ressel

Luis Ressel <ara...@aixah.de>
GPG fpr: F08D 2AF6 655E 25DE 52BC  E53D 08F5 7F90 3029 B5BD

Re: [gentoo-dev] Proposal for changes for the next EAPI version

[Luis Ressel]

On Mon, 16 May 2016 18:13:33 +0530
Pallav Agarwal <pallavagarwa...@gmail.com> wrote:

> What I'm suggesting is to add a new function post_install_test. The
> function will run only if the build is being run for stabilization
> (either as a part of automated stabilization, or manual) which can be
> controlled by a USE flag. The function would also require independent
> dependencies in case it uses external applications to test the one
> being built.

Could you please elaborate on this? We already have src_test() for
automated tests. Why would we want to run additional tests after the
package has been merged?

-- 
Regards,
Luis Ressel

Luis Ressel <ara...@aixah.de>
GPG fpr: F08D 2AF6 655E 25DE 52BC  E53D 08F5 7F90 3029 B5BD


pgpBC7jG9HFAG.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?

[Luis Ressel]

On Wed, 24 Feb 2016 11:18:55 -0800
Raymond Jennings <shent...@gmail.com> wrote:

> As far as changelog generation, what about causing the changelogs to
> be autogenerated by the end user's computer?  Divide and conquer.

That would require a local git clone. And that's exactly what those who
still want Changelogs are trying to avoid.

-- 
Regards,
Luis Ressel


pgpq6zs8rkL_V.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Luis Ressel]

On Tue, 9 Feb 2016 07:37:10 +0100
Patrick Lauer <patr...@gentoo.org> wrote:

> And now I can't figure out what I need to enable to have "rewrite"
> work. Good job!
> 
> The names match the internal module names, which is what I care about.
> Figuring out if I need USE="zlib" or USE="compress" or even a combo
> is a lot more effort and frustrating than having to enable the
> useflag that has the name of the module.
> 
> It might not be 'pure' or very aesthetical, but we try to get stuff
> done here.
> 
> 

I agree concering rewrite, USE=rewrite would be better suited for that.
But zlib is a very obvious choice of USE flag, and most of the other
flags I listed had (nearly) verbatim the same names as upstream's
modules anyway (perl, geoip, auth_pam -> pam, auth_ldap -> ldap).

I think the fact that we can use global USE's this way matters very
much. If enable geoip or ldap in my make.conf, I expect packages with
optional geoip/ldap support to enable this support.

Also, if you wish to document this mapping in more detail, that's
exactly what we have the  tags in metadata.xml for. You can even
write whole sentences in there! :)

Regards,
Luis Ressel

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Luis Ressel]

On Tue, 9 Feb 2016 11:34:12 +1300
Kent Fredric <kentfred...@gmail.com> wrote:

> nginx_modules_http_geoip? ( dev-libs/geoip )
> nginx_modules_http_gunzip? ( sys-libs/zlib )
> nginx_modules_http_gzip? ( sys-libs/zlib )
> nginx_modules_http_gzip_static? ( sys-libs/zlib )
> nginx_modules_http_image_filter? ( media-libs/gd[jpeg,png] )
> nginx_modules_http_perl? ( >=dev-lang/perl-5.8 )
> nginx_modules_http_rewrite? ( >=dev-libs/libpcre-4.2 )
> nginx_modules_http_secure_link? (
> userland_GNU? (
> !libressl? ( dev-libs/openssl:0= )
> libressl? ( dev-libs/libressl:= )
> )
> )
> nginx_modules_http_xslt? ( dev-libs/libxml2 dev-libs/libxslt )
> nginx_modules_http_lua? ( !luajit? ( dev-lang/lua:0= ) luajit?
> ( dev-lang/luajit:2= ) )
> nginx_modules_http_auth_pam? ( virtual/pam )
> nginx_modules_http_metrics? ( dev-libs/yajl )
> nginx_modules_http_dav_ext? ( dev-libs/expat )
> nginx_modules_http_security? ( >=dev-libs/libxml2-2.7.8
> dev-libs/apr-util www-servers/apache )
> nginx_modules_http_auth_ldap? ( net-nds/openldap[ssl?] )
> 

Thanks for citing this, I think it demonstrates mgorny's point rather
nicely; we have global USE flags for many of those modules:

* nginx_modules_http_perl -> perl
* nginx_modules_http_auth_pam -> pam
* nginx_modules_http_auth_ldap -> ldap
* nginx_modules_http_geoip -> geoip
* nginx_modules_http_g(un)zip -> zlib
* nginx_modules_http_secure_link -> ssl

The following two ones aren't quite as obvious, but could also be
changed:
* nginx_modules_http_rewrite -> pcre
* nginx_modules_http_image_filter -> gd

Introduce new USE flags for the remaining few modules -- voilà, there
you go, no need for a new USE_EXPAND and the users will even get a
useful set of default modules enabled based on their global USE flags.

-- 
Luis Ressel

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Luis Ressel]

On Tue, 9 Feb 2016 12:22:51 +1300
Kent Fredric <kentfred...@gmail.com> wrote:

> The only way you could make that scheme better is having an early
> stage in NGINX that shows which module are going to be built /based
> on/ the USE flag combinations, and then something with savedconfig
> could potentially bar building certain modules.
> 
> > Dependency control : USE flags representing the dep
> > Feature control: SavedConfig  
> 
> And then the "Feature control" could be tightened up/managed with USE
> flags used more sparingly when things depended on them.
> 

That might be useful, if the maintainer is willing to implement it. :)

> The biggest downside of this is the disconnect for a user between
> "What I want" and "What do I have to select to get what I want" ( For
> instance, USE=pcre turning on rewrite support is weird ,
> 

Sure, that's why I said these two (image_filter and rewrite) were less
obvious. I agree it'd be better to use a local 'rewrite' USE for the
rewrite module.

> While mgorny is more focused on "Why do I have this dependency" not
> "What feature do I want"
> 
> And this of course does nothing for us in regards to the large
> collection of USE controlled SRC_URIs .
> 

Yes, but we have those in other ebuilds, too, most of which don't use
USE_EXPAND. And this thread is supposed to be about the usage of
USE_EXPAND in nginx, right?

> Because NGINX is monolithic, but its sources are aggregated from a
> bunch of different authors for some fun reason, sort of like having a
> `linux-kernel` ebuild with a SRC_URI for every single vendor name (
> *barf* )
> 
> I really do not envy the nginx maintainer.
> 

Me neither. @mrueg or whoever's the maintainer: Thanks for sparing the
rest of us from this insanity. :)

Regards,
Luis Ressel

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Luis Ressel]

On Tue, 9 Feb 2016 11:34:12 +1300
Kent Fredric  wrote:

> nginx_modules_http_lua? ( !luajit? ( dev-lang/lua:0= ) luajit?
> ( dev-lang/luajit:2= ) )

This should of course also be changed to the global 'lua' useflag.
Currently, you're even mixing NGINX_MODULES and normal USE flags here
for maximum confusion.

-- 
aranea

Re: [gentoo-dev] GLEP 67 is in, please update your metadata.dtd!

[Luis Ressel]

On Mon, 25 Jan 2016 10:37:15 +0100
Michał Górny <mgo...@gentoo.org> wrote:

> Hello, everyone.
> 
> I've finished the GLEP 67 transition last night, and it officially
> applies to all metadata.xml files now.
> 

Great!

> In order to have repoman apply it correct (and not throw errors on new
> metadata.xml files), it needs to refetch metadata.dtd. Sadly, this
> currently happens once a week, so it's better to remove the file
> manually to force refetch:
> 
>   rm "$(portageq envvar DISTDIR)"/metadata.dtd
> 

I might be asking this for a second time, but why does repoman download
the metadata.dtd at all? If one fetches from
git://../gentoo-mirror/gentoo (or via rsync, afaik) it is included
in /usr/portage/metadata/dtd/.

For me, it's in fact very annoying when repoman wants to download
metatdata.dtd, as my "normal" unix user isn't a member of the portage
group.

By the way, the herds.xml file is still available at
https://api.gentoo.org/packages/herds.xml and can probably be removed
from there as well.


-- 
Regards,
Luis Ressel

Re: [gentoo-dev] Herd up for grabs: gpe

[Luis Ressel]

On Sun, 17 Jan 2016 20:39:18 +0100
Michał Górny <mgo...@gentoo.org> wrote:

> On Sun, 17 Jan 2016 19:25:33 +
> James Le Cuirot <ch...@gentoo.org> wrote:
> 
> > On Sun, 17 Jan 2016 19:35:55 +0100
> > Michał Górny <mgo...@gentoo.org> wrote:
> >   
> > > The only maintainer of gpe herd is MIA for some time, and this
> > > pretty much renders the whole thing maintainer-needed.
> > > 
> > > Is anyone interested in keeping the herd as-is and maintaining all
> > > packages in it? If I get no reply till 2016-01-24, I will
> > > effectively remove the herd and announce the packages that landed
> > > in maintainer- -needed as a result.
> > 
> > All that stuff got masked for removal by Pacho recently anyway.  
> 
> If you mean the matchbox set, it doesn't cover all of those packages.
> Unless they were masked separately.
> 

Only x11-libs/libfakekey and x11-libs/libxsettings-client are still
unmasked; both of them have additional maintainers, so nothing will
have to go to maintainer-neeeded@ when the GPE herd is disbanded.

By the way, x11-libs/libxsettings-client doesn't have any revdeps and
looks like it could be removed along with the other GPE stuff.
libfakekey still has some revdeps, though.

-- 
Luis Ressel

Re: [gentoo-dev] ChangeLogs: Digest verification failed

[Luis Ressel]

On Thu, 12 Nov 2015 18:25:23 +
"Robin H. Johnson" <robb...@gentoo.org> wrote:

> This is being tracked in bug #565574;
> 
> egencache it turns out updates the Manifest BEFORE writing the
> ChangeLog; with predictable results if the ChangeLog is updated.
> 
> I have put a workaround in place of forcing a regen of the Manifests
> after the ChangeLogs for the moment.
> 

Why on earth are the ChangeLogs tracked in the Manifest at all? Aren't
they auto-generated by the rsync mirrors these days anyway? Manifests
are nice for DIST files, but tracking ChangeLogs seems a bit useless to
me.

Regards,
Luis Ressel

Re: [gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo

[Luis Ressel]

On Fri, 30 Oct 2015 23:40:28 +0100
hasufell <hasuf...@gentoo.org> wrote:

> On 10/30/2015 10:16 PM, Anthony G. Basile wrote:
> > On 10/30/15 3:35 PM, hasufell wrote:  
> >> On 10/30/2015 06:55 PM, Michał Górny wrote:  
> >>> We have no way of saying 'I prefer polarssl, then gnutls, then
> >>> libressl, and never openssl'.  
> >> I don't think this is something that can be reasonably supported
> >> and it sounds awfully automagic. And I don't see how this is
> >> possible right now, so I'm not really sure what you expect to get
> >> worse.
> >>
> >> E.g. -gnutls pulling in dev-libs/openssl is not really something
> >> you'd expect. If we go for provider USE flags, then things become
> >> consistent, explicit and unambiguous. The only problem is our
> >> crappy implementation of providers USE flags via REQUIRED_USE.
> >>  
> > I'm not sure what mgorny has in mind, but the problem I see with
> > saying I want just X to be my provider system wide is that some
> > pkgs build with X others don't, other pkgs might need a different
> > provider.  So it might make sense to order them in terms of
> > preference: X1 > X2 > X3 ... and then when emerging a package, the
> > first provider in the preference list that works is pulled in for
> > that package. 
> 
> Isn't that basically what the proposal B already was, except that we
> don't use REQUIRED_USE for it but some sort of pkg_setup/pkg_pretend
> function? I don't see how those ideas even conflict.
> 

Well, not exactly. If I understood them right, mgorny and blueness are
asking for a user-supplied preference list (e.g. "I want packages to
link with libressl if possible, gnutls otherwise"), not an
ebuild-supplied preference list ("This package prefers gnutls, but
openssl is also supported").

Side note: These ebuild-side preferences are used by some ebuilds (e.g.
cyrus-sasl, it uses gdbm if both gdbm and berkdb use flags are
enabled), but for ssl, we might want to specify "REQUIRED_USE = ^^
(..)" so it's possible to use USE dependencies in order to avoid
namespace conflicts. If there's no REQUIRED_USE,
"somelibrary[libressl]" might be satisfied even though somelibrary is
actually linked to openssl.


-- 
Regards,
Luis Ressel

[gentoo-dev] Non-fast-forward push to gentoo repository

[Luis Ressel]

On Wednesday, someone seems to have done a --force'd push to the gentoo
repository. The commits
* 5e04009 sci-mathematics/minisat: rev-bump and build fixes for latest,
  QA cleanup
* 9c9fce9 media-libs/urt: build fixes, QA cleanups, new shared lib
  build, SRC_URI

are now missing from the repo, they were overwritten by
  cbb7cfa sys-kernel/tuxonice-sources: Version bumps.

Was this intended? If not, @nerdboy: You might want to commit these
changes again.

Regards,
Luis Ressel

Re: [gentoo-dev] Policies for games dirs, new group gamestat for sgid binaries

[Luis Ressel]

On Sun, 22 Feb 2015 18:17:00 +1300
Kent Fredric kentfred...@gmail.com wrote:

 For instance, perhaps a sysadmin simply wants to lock up GCC and make,
 having a straight forward way do to that in bashrc would help them
 achieve that, without them having to dish out a full ACL/LDAP setup,
 and without then needing to retouch the perms manually every install.
 

And why would anyone want to lock up GCC? If an attacker can execute
files he's created himself, he'll always find a way to get a compiler
(or at least an assembler) up and running.

And if he can't (which *would* be a sensible security feature for which
implementations are available, for example grSecurity's TPE) -- well,
then the GCC won't be of any help for the attacker, because he can't
execute the compiled binary.

Not that it matters. :)

-- 
Luis Ressel ara...@aixah.de
GPG fpr: F08D 2AF6 655E 25DE 52BC  E53D 08F5 7F90 3029 B5BD


pgpXbFXj0pClM.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-02-22 23:59 UTC

[Luis Ressel]

On Mon, 23 Feb 2015 00:05:19 +
Robin H. Johnson robb...@gentoo.org wrote:

 The attached list notes all of the packages that were added or removed
 from the tree, for the week ending 2015-02-22 23:59 UTC.
 
 Additions:
 sys-firmware/iwl7265-ucode   2015-02-22 04:06:56 prometheanfire

IIRC, just one or two months ago several of the sys-firmware/iwl*-ucode
packages were lastrited with the recommendation of using
sys-kernel/linux-firmware instead. So why are we adding new firmware
ebuilds now? The iwl7625 firmware seems to be in linux-firmware, too.


Regards,
Luis Ressel


-- 
Luis Ressel ara...@aixah.de
GPG fpr: F08D 2AF6 655E 25DE 52BC  E53D 08F5 7F90 3029 B5BD


pgpjS6jv4sP92.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: app-emulation/fig

[Luis Ressel]

On Thu, 26 Feb 2015 10:13:14 -0600
Alex Brandt alund...@gentoo.org wrote:

 # Alex Brandt alund...@gentoo.org (21 Feb 2015)
 # Upstream renamed to docker-compose for all future releases
 app-emulation/fig
 

Wouldn't a pkgmove be the better way to handle this?


-- 
Luis Ressel ara...@aixah.de
GPG fpr: F08D 2AF6 655E 25DE 52BC  E53D 08F5 7F90 3029 B5BD

Re: [gentoo-dev] Figuring out the solution to in-network-sandbox distcc

[Luis Ressel]

On Wed, 21 Jan 2015 10:38:20 -0500
Rich Freeman ri...@gentoo.org wrote:

 On Wed, Jan 21, 2015 at 10:00 AM, Alexis Ballier
 aball...@gentoo.org wrote:
  On Wed, 21 Jan 2015 11:05:34 +0100
  Michał Górny mgo...@gentoo.org wrote:
 
  Hello, developers.
 
  As you may recall, the main blocker for wide-establishment of
  FEATURES=network-sandbox prohibiting network access within the
  build environment is distcc. Since all connectivity is disabled,
  distcc can no longer reach other distcc servers and build
  efficiently. I therefore find it important to figure out a
  solution.
 
  I see two generic approaches possible here:
 
  1. proxying distcc from within the build environment, or
 
  2. moving distcc-spawned processes back to parent's namespace.
 
 
  I haven't followed this at all, so this might be very stupid:
  Isn't it possible to whitelist distcc hosts ?
 
 That would only work with a proxy of some kind.
 
 A process running in a separate network namespace doesn't see any
 network interfaces.  It can't even get as far as iptables/etc for some
 kind of filtering.  Now, you could define an interface in the new
 namespace, and then bridge that to the host network, and then apply
 iptables rules to it.
 

Your last sentence mentions a nice possibility:
1) Connect the sandbox network namespace to the global namespace (using
   a veth pair?)
2) Enable forwarding (if I understand it right, it's even possible to
   do this for individual interfaces instead of globally, using
   /proc/sys/net/ipv{4,6}/conf/veth0 )
3) Set up suitable rules in the netfiler FORWARD chain to ensure only
   distcc gets through
4) Set up SNAT or MASQUERADE in netfilter's nat table
5) There you go!

This is beautiful because is doesn't require any userland proxies, but
of course, it would be difficult to set up in an automated fashion. So
my proposal would be just to stay with the status quo, and document the
above in the wiki for those who really want to use both network-sandbox
and distcc despite the hassle.


Regards,
Luis Ressel

Re: [gentoo-dev] Re: qa last rites -- long list

[Luis Ressel]

On Thu, 8 Jan 2015 09:16:36 -0600
William Hubbs willi...@gentoo.org wrote:

 Rich is correct, maintainers are no longer bound by the games team
 policy.
 

I didn't know this. If that's the case, I'd like to proxy-maintain
nethack. I'll try and prepare the neccessary ebuild changes.


Luis Ressel


pgpDC_qIfUsBS.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

[Luis Ressel]

On Wed, 30 Jul 2014 09:38:16 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:

 In the context of that policy and a content-touchless-bump goal, I 
 suppose I'd script the bump, pulling keywords from the highest
 previous version, prepending the ~ as necessary and inserting them in
 the keywords line after copying the file from the live-ebuild .  That
 wouldn't be content-touchless, but the touch would be automated so as
 to avoid mistakes and unnecessary work.

That proposed script reminds me of http://xkcd.com/1319/. ;)

I think I'd rather go with the original workflow. Okay, perhaps
package.masking - is a bit uncommon and clutters package.mask, but
it's not all *that* bad and it eases the workflow.


Regards,
Luis Ressel


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

[Luis Ressel]

On Wed, 30 Jul 2014 15:33:19 +0300
Samuli Suominen ssuomi...@gentoo.org wrote:

 There is no need to package.mask if proper if -logic is used, like,
 for example,
 
 if [[ ${PV} == * ]]; then
 inherit git-r3
 KEYWORDS=
 else
 KEYWORDS=~amd64 ~arm ~arm64 ~x86
 fi
 
 Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
 the KEYWORDS
 ready, and 1.2.3 and  ebuilds can be identical
 
 That's what this thread was originally about... That's how x265's
 ebuild work, just like eg.
 media-libs/xine-lib or sys-fs/udev ebuilds does
 
 (It just seemed this was unclear to some replying in this thread.)
 
 - Samuli
 
 

Thanks for the clarification. This approach seems to be the optimum.


Regards,
Luis Ressel


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined

[Luis Ressel]

I guess that would solve some of the issues we've had with virtuals in
the past. I support the idea, however, I'm not sure of the technical
consequences it might have.

I would leave the REQUIRED_USE out. It's a hassle to write, and if an
user decides to set multiple use flags on such a virtual, why not just
let him do it?


Regards,
Luis Ressel


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined

[Luis Ressel]

On Fri, 25 Jul 2014 15:23:47 -0400
Ian Stakenvicius a...@gentoo.org wrote:

 This is something that should only be done on a case-by-case basis, as
 needed -- for instance, with virtual/krb5 only one provider can be
 installed at a time as they block eachother.
 
 We could leave it up to portage to error on mit-krb5 and heimdal being
 forced into the installation despite blocking eachother, but i think
 portage would have a better chance telling end-users about the
 conflict (and maybe helping to resolve it better via --autounmask?) if
 there was a REQUIRED_USE.

Okay, I didn't think of that. I'm not sure if the blocker deps or the
REQUIRED_USE would be more helpful for Portage, but generally I think
that the REQUIRED_USE error message is quite hard to understand for
unexperienced users -- much more so than the error generated by a
blocker dep.


   The following REQUIRED_USE flag constraints are unsatisfied:
heimdal? ( !mit-krb5 ) mit-krb5? ( !heimdal )

might be a bit confusing to some people, and remember that constraint
string would grow much longer if there were more providers, as grows
quadratically.


Regards,
Luis Ressel


signature.asc
Description: PGP signature

Re: [gentoo-dev] local repo kernel ebuild search for tar.bz2 instead of tar.xz

[Luis Ressel]

The kernel-2.eclass calls epatch_user, so AFAIK you don't have to
create a local ebuild copy in order to patch the kernel, just drop your
patches in /etc/portage/patches/sys-kernel/hardened-sources/.


Regards,
Luis Ressel


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default

[Luis Ressel]

On Thu, 15 May 2014 16:48:24 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 Sandboxing isn't about security. It's about catching mistakes.

Ciaran has a point here. Thomas, you assumed that network-sandbox is
the only thing stopping an ebuild from accessing local services or the
internet. However, even with network-sandbox being enabled such
behaviour would still constitue a major bug which would be fixed by the
devs.

So yes, network-sandbox (and same goes for ipc-sandbox) is mainly a
debugging aid for developers which will help them spot such problems
more easily.


--
Regards,
Luis Ressel


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default

[Luis Ressel]

On Mon, 12 May 2014 19:39:09 +0200
Michał Górny mgo...@gentoo.org wrote:

 I don't know postgresql well enough but does the test db reside
 in temporary build directory? That is, can you guarantee that:
 
 1) it will never ever collide with user's database,
 
 2) it will be properly cleaned up even if the test suite terminates
 unexpectedly?

The closest thing you could do would be to create a separate tablespace
residing in the build directory. I wouldn't consider this a good idea
however, as you'd need postgres superuser permissions, it would have
some unintented side effects (like breaking on SELinux machines), you'd
have to patch the test suites and it still wouldn't ensure an automatic
cleanup -- on unexpected test suite terminations the dir in which the
tablespace resides would vanish, but postgres would still expect one
there, which might even create further problems (especially on
re-emerge). I wouldn't recommend using this approach even when
accessing the host postgres.

On top of that, many postgres installations with reasonably secure
configuration wouldn't grant portage access anyway.

As it isn't hard at all to run a separate postgres instance (upstream
is explicitly supporting it), I'd strongly recommend doing so even with
network-sandbox being disabled.


--
Regards,
Luis Ressel


signature.asc
Description: PGP signature

Re: [gentoo-dev] Packages up for grabs

[Luis Ressel]

On Wed, 09 Apr 2014 22:34:07 +0200
Pacho Ramos pa...@gentoo.org wrote:

 mail-filter/bogofilter

If no dev wants it, I'll proxy-maintain it.


Regards,
Luis Ressel


signature.asc
Description: PGP signature

Re: [gentoo-dev] Packages up for grabs

[Luis Ressel]

On Wed, 9 Apr 2014 22:48:55 +0200
Luis Ressel ara...@aixah.de wrote:

 On Wed, 09 Apr 2014 22:34:07 +0200
 Pacho Ramos pa...@gentoo.org wrote:
 
  mail-filter/bogofilter
 
 If no dev wants it, I'll proxy-maintain it.

Okay, that's obsolete now that johu stepped up...


Regards,
Luis Ressel


signature.asc
Description: PGP signature

[gentoo-dev] [PATCH] gnome2-utils.eclass: Fix SELinux labeling issue in gnome2_gdk_pixbuf_update()

[Luis Ressel]

The internals of gnome2-utils.eclass' gnome2_gdk_pixbuf_update(), which
is responsable for updating x11-libs/gdk-pixbuf's loaders.cache,
unfortunately cause problems with SELinux, as the mentioned file
doesn't get a correct context and is therefore inaccessible by
applications.

The trivial patch which I've proposed on b.g.o (#499636) has already been
acknowledged by the SELinux and GNOME herds, however the latter asked
me to send a mail to this ML as well. So, does anyone have objections
about this change?


--- gnome2-utils.eclass 2014-01-28 23:14:31.419135392 +0100
+++ gnome2-utils.eclass 2014-01-28 23:17:06.569269202 +0100
@@ -436,7 +436,8 @@ 
local tmp_file=$(mktemp -t tmp.XX_gdkpixbuf)
${updater} 1 ${tmp_file} 
chmod 0644 ${tmp_file} 
-   mv -f ${tmp_file} 
${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache
+   cp -f ${tmp_file} 
${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache 
+   rm ${tmp_file} # don't replace this with mv, required for SELinux 
support
eend $?
 }
 


--
Luis Ressel ara...@aixah.de
GPG fpr: F08D 2AF6 655E 25DE 52BC  E53D 08F5 7F90 3029 B5BD


signature.asc
Description: PGP signature

Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)

[Luis Ressel]

On Mon, 13 Jan 2014 15:58:13 +0100
Tom Wijsman tom...@gentoo.org wrote:

 On Mon, 13 Jan 2014 10:31:56 +0100
 Fabio Erculiani lx...@gentoo.org wrote:
 
  Portage can still take *minutes* to calculate the merge queue of a
  pkg with all its deps satisfied.
 
 Half a minute if you disable backtracking which you don't need. :)

Which sadly also means that some updates get skipped silently. (Those
which would trigger rebuilds of other packages because of sub-slot
deps, had that case yesterday).

  Ironically, launching the same emerge command twice, will take more
  or less the same time.
 
 Determinism results in more or less the same time, that's correct;
 proper benchmarks would show you a similar result.

I guess he means that the (according to the file sizes) extensive
caching doesn't seem to be of much use.


-- 
Luis Ressel ara...@aixah.de
GPG fpr: F08D 2AF6 655E 25DE 52BC  E53D 08F5 7F90 3029 B5BD


signature.asc
Description: PGP signature

Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)

[Luis Ressel]

On Mon, 13 Jan 2014 16:46:08 +0100
Tom Wijsman tom...@gentoo.org wrote:

 On Mon, 13 Jan 2014 16:38:59 +0100
 Luis Ressel ara...@aixah.de wrote:
 
  On Mon, 13 Jan 2014 15:58:13 +0100
  Tom Wijsman tom...@gentoo.org wrote:
  
   Half a minute if you disable backtracking which you don't need. :)
  
  Which sadly also means that some updates get skipped silently.
  (Those which would trigger rebuilds of other packages because of
  sub-slot deps, had that case yesterday).
 
 Can you give an example of that?
 
 Rebuilds don't cause a different solution in the graph afaik; so, I
 wouldn't see how that would form a big problem. I also think this
 would still be covered by preserved-rebuild and/or revdep-rebuild
 afterwards.

No, the problem wasn't that rebuilds weren't done (btw: this is not
about @preserved-rebuilds, but about subslot dependencies), but that
updates which would trigger such rebuilds are silently ignored. This
happened to me yesterday while trying --backtrack=0. The available
update to dev-haskell/parsec simply didn't show up (haskell ebuilds
make heavy use of subslot deps), I only noticed this because I knew
there was in fact an update available (thanks to eix-diff). Only after
enabling backtracking Portage found the update.

This might well be a bug, perhaps I'll examine the situation when I've
got more time.


-- 
Luis Ressel ara...@aixah.de
GPG fpr: F08D 2AF6 655E 25DE 52BC  E53D 08F5 7F90 3029 B5BD


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: storing predefined INSTALL_MASK directory lists in repos

[Luis Ressel]

I've got an additional proposal: It would be interesting if this
feature could also make use of the LINGUAS var for selectively
filtering /usr/share/man and and /usr/share/locale, as most ebuilds
don't respect this variable natively.

-- 
Luis Ressel ara...@aixah.de
GPG fpr: F08D 2AF6 655E 25DE 52BC  E53D 08F5 7F90 3029 B5BD


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: storing predefined INSTALL_MASK directory lists in repos

[Luis Ressel]

On Sat, 11 Jan 2014 17:01:34 +0100
Michał Górny mgo...@gentoo.org wrote:

 That's a side goal.
 
 I was thinking of something like:
 
   INSTALL_MASK=linguas -linguas_XX
 
 that would remove all linguas except for language XX.

That would be enough for me. A bit of a duplication of information,
but if it eases the implementation, that shouldn't be much of a problem.

But imho it'd be nice if this approach didn't require a separate config
entry for each language (that'd be 233 entries).


-- 
Luis Ressel ara...@aixah.de
GPG fpr: F08D 2AF6 655E 25DE 52BC  E53D 08F5 7F90 3029 B5BD


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: RFC: new global USE flag srcdist

[Luis Ressel]

On Thu, 02 Jan 2014 11:10:54 -0500
Ian Stakenvicius a...@gentoo.org wrote:

 ..or we could just do this, using the existing RESTRICT=mirror
 that's already in ebuilds -- have a DISTDIR and a NODISTCACHEDIR,
 NODISTCACHEDIR defaults to DISTDIR; if RESTRICT=mirror then
 distfiles are saved to NODISTCACHEDIR, otherwise are saved to DISTDIR.

IMHO, this is the best solution proposed so far. It doesn't need a new
USE flag duplicating information which is already in RESTRICT (or am I
missing some corner cases here?), and it doesn't bother those who don't
care about this issue with new distfiles-*/ dirs, as with Kent's
proposal.

@Kent: Why do you think another distinction for RESTRICT=fetch is
neccessary? If it really is, it could also be integrated into this
solution, but I don't get the point -- either you're allowed to
redistribute it, or you're not. RESTRICT=fetch just signals Portage
that it won't be *technically* able to download the distfiles.


Luis


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: RFC: new global USE flag srcdist

[Luis Ressel]

On Fri, 3 Jan 2014 05:37:33 +1300
Kent Fredric kentfred...@gmail.com wrote:

 Fair point. I was more seeing a pattern emerging and exploring where
 that might lead.
 
 Though I figure it a useful distinction for convenience sake.
 
 Consider if you wanted to archive some files to make a subsequent
 gentoo installation easier.
 
 It would be optimal to backup and replicate the nofetch directory for
 the subsequent installation, because that's the only directory that
 portage would be unable to populate itself from upstream sources.
 
 so it becomes:
 
 /distfiles  # Gentoo Replicated and Fetchable from upstream
 /distfiles-normirror # Fetch from upstream only
 /distfiles-nofetch  # manual fetching only
 
 So it was more a practical benefit than a legal one =).
 
 ( Also if you were tight on space, you'd obliterate  distfiles/ first,
 distfiles-nomirror/ second, and distfiles-nofetch/ last )

These are good arguments. Just to be clear: Would you favor if the
default setup did this separation? I personally also like the idea, but
I'd prefer to leave the default at one distdir for *, and just make
it configurable via the proposed variables.


Luis


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: RFC: new global USE flag srcdist

[Luis Ressel]

On Thu, 2 Jan 2014 17:53:45 +0100
Ulrich Mueller u...@gentoo.org wrote:

 RESTRICT is somewhat complementary to LICENSE and cannot provide as
 much information. Especially, RESTRICT=mirror doesn't say under
 what license the restricted pieces are, and doesn't allow for
 ACCEPT_LICENSE filtering.

But is this detailed information really neccessary? The use-case is
ensuring the legality of distfiles mirroring -- you're either allowed to
do it nor not, the exact license doesn't matter here.


Luis


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: RFC: new global USE flag srcdist

[Luis Ressel]

On Thu, 02 Jan 2014 12:13:47 -0500
Ian Stakenvicius a...@gentoo.org wrote:

 RESTRICT=fetch requires the user to do their own fetching; since
 they're doing that, it should be pretty obvious that the distfile is
 restricted somehow.  Of course, they are still able to do whatever
 they want, but I expect anyone that is keeping DISTDIR and
 NODISTCACHEDIR as separate targets would know to not place the fetched
 distfile in their self-distributing directory, or at least know to
 read the license restrictions already present in the listed LICENSEs

Yes, I totally forgot that. Portage doesn't download these files, so
there's no point in creating a variable telling it where to put them...


Luis


signature.asc
Description: PGP signature

Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up

[Luis Ressel]

On Sat, 14 Dec 2013 15:57:04 -0600
William Hubbs willi...@gentoo.org wrote:

 On Sat, Dec 14, 2013 at 08:47:01PM +, Jorge Manuel B. S. Vicetto
 wrote:
  OK, I see what you mean.
  To be clear, I'm not ready to have a stage3 without netifrc. If /
  when we update catalyst so that the new stage3 is the sum of
  @system and additional packages, we can move netifrc to that list.
 
 Actually I'm not even sure how necessary that kind of update is.
 
 I didn't quite follow what the reasoning against my second proposal
 was.
 
 Once openrc-0.12.4 is stable everywhere it is going to go stable, I
 want to add virtual/network-manager to the tree. This would contain a
 list of network manager providers.
 
 I think adding it to the tree is good, because we have other virtuals
 for multiple packages that perform the same function --
 virtual/logger, virtual/mta, etc.
 
 Once that is done, we could easily add it to @system then I would drop
 the netifrc use flag. That would take care of the situation if netifrc
 was the default provider.
 
 Then, if you decide to add the function you are talking about to
 catalyst, we could look into dropping virtual/network-manager from
 @system.
 
 I'll attach the ebuild below so everyone sees it.
 
 William
 

IMHO this virtual shouldn't be added. It would be a pure meta package
for the user. That case is not directly comparable with virtual/mta:
We've got this for other packages to depend on it, at least that is my
understanding. In a case like this, a handbook entry should suffice.


Luis Ressel


signature.asc
Description: PGP signature

Re: [gentoo-dev] Packages up for grabs

[Luis Ressel]

On Sat, 23 Mar 2013 10:52:00 +0100
Martin Dummer martin.dum...@gmx.net wrote:

 If I manage one day to achieve the gentoo dev status then I am willing
 to pick up maintainership of
 
  app-laptop/nvidiabl
 
 but until then?

What about proxy-maintainership?


Luis


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Luis Ressel]

On Tue, 26 Feb 2013 17:10:56 +0700 (NOVT)
gro...@gentoo.org wrote:

 Hello *,
 I am stuck and have many questions.
 [In the process of becoming a dev, I've generated a gpg key, of course. It 
 vwas on an old notebook. When I switched to a newer notebook, I forgot to 
 copy it, because I don't use gpg regularly. No risk that it became known - 
 the disk was re-partitioned and re-formatted. Probably, that key has expired 
 anyway.]
 1. So, I start
 gpg --gen-key
 It creates ~/.gnupg/ and some files in it. Should I press ctrl-C, then edit 
 ~/.gnupg/gpg.conf, and then re-start gpg --gen-key? Or editing gpg.conf can 
 be done later?

Editing the conf should be done first, some of the preferences (e.g.
personal-digest-preference and cert-digest-algo) affect the creation of
keys.

 2. Then I choose 1, 3y, y, then my name and the @gentoo.org email address. 
 After that,
 gpg --list-keys
 says
 /home/username/.gnupg/pubring.gpg
 ---
 pub   4096R/0x16_hex_digits_1 2013-02-26 [expires: 2016-02-26]
 uid [ultimate] my_name my_gentoo_email_address sub   
 4096R/0x16_hex_digits_2 2013-02-26 [expires: 2016-02-26]
 So, my key id is 0x16_hex_digits_1, right?

Yep, but why did you bother to replace the information?

 3. Now I do
 gpg --edit-key 0x16_hex_digits_1
 addkey
 Then I choose
 (4) RSA (sign only)
 right? Then I choose 4096, 1y, y, y, save. Now
 gpg --list-keys
 gives
 /home/username/.gnupg/pubring.gpg
 ---
 pub   4096R/0x16_hex_digits_1 2013-02-26 [expires: 2016-02-26]
 uid [ultimate] my_name my_gentoo_email_address
 sub   4096R/0x16_hex_digits_2 2013-02-26 [expires: 2016-02-26]
 sub   4096R/0x16_hex_digits_3 2013-02-26 [expires: 2014-02-26]
 4. I do
 gpg --output revoke.asc --gen-revoke 0x16_hex_digits_1
 and choose 1.

That's all correct.

  6. Encrypted backup of your secret keys.
 I don't understand this.

It'd make sense to have an backup of your keys (~/.gnupg/secring.gpg)
stored in a safe place, just as with everything else... If you want,
you can protect it by another layer of encryption, but it's not that
important, because the keys are already protected by your passphrase.

  7. In your gpg.conf:
# include an unambiguous indicator of which key made a signature:
# (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234)
sig-notation issuer-...@notations.openpgp.fifthhorseman.net=%g
 I don't understand this.

Neither do I (I know what it does, but I don't see what it's good for) –
just leave it out, it's not necessary.

 5. I do
 gpg --keyserver subkeys.pgp.net --send-key 0x16_hex_digits_1
 6. On dev.gentoo.org, I am supposed to do
 perl_ldap -b user -M gpgkey gpg-id user
 perl_ldap -b user -M gpgfingerprint gpg-fingerprint user
 Is gpg-id 0x16_hex_digits_1? Or 0x16_hex_digits_3? What is 
 gpg-fingerprint and how do I get it? Is user my username on 
 dev.gentoo.org?
 What's even more important, perl_ldap asks my ldap password. I suppose I 
 haven't got one. My usual Gentoo password (used in bugzilla, forums) does not 
 work. How do I get an ldap password?

I can't help you with that, as I don't have access to any gentoo
infrastructure. But IIRC, that's the password you once set on d.g.o
with passwd.

 7. If I'll ever complete all the above, I'll add sign to FEATURES in 
 /etc/portage/make.conf, and
 PORTAGE_GPG_DIR=/home/username/.gnupg
 and also
 PORTAGE_GPG_KEY=0x16_hex_digits_3!
 Is this correct? Is it 16_hex_digits_3, and not, say, 16_hex_digits_1? 
 Should I add ! at the end, as suggested by mgorny?

16_hex_digits_3 (the one you added later via addkey) is the correct
one. And adding a ! is absolutely necessary.

 During the time I'm reading all these instructions, I could bump 10 packages. 
 Very complicated for a person who does not use gpg and knows next to nothing 
 about it.

Security can be hard to grasp at times. Sadly...


HTH,
Luis


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Luis Ressel]

On Mon, 18 Feb 2013 23:27:46 +
Robin H. Johnson robb...@gentoo.org wrote:


 3. Dedicated Gentoo signing subkey

What's the point of this, btw?


Luis


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Luis Ressel]

On Wed, 20 Feb 2013 21:37:38 +
Robin H. Johnson robb...@gentoo.org wrote:

 Ideally keeping your primary key offline to increase security.
 
 However, the original theory was that if there was some attack that
 required a large amount of ciphertext or a targeted plaintext input,
 you would be limiting the ciphertext to only gentoo-specific content,
 and could trivially rotate the subkey without any impact on your
 primary key.

I totally agree with the idea of having a separate subkey for signing
purposes, but look at my key, for example: I already have a separate
subkey for signing, the primary key is only used for certifications
(and is actually kept offline ;). If I was a Gentoo dev, it wouldn't
seem that logical to have to create yet another signing subkey.

Therefore, I'd propose to remove the Gentoo part from Dedicated
Gentoo signing subkey.

Luis


signature.asc
Description: PGP signature