Aw: Re: [gentoo-user] Updating portage, continued

2019-06-03 Thread n952162
Fundamentally, autounmask seems like something I don't want to do, at all.   
What happens if I just remove zz-autounmask?  What do I have to emerge to find 
out?

I currently have:

$ cat /etc/portage/package.use/zz-autounmask
>=dev-lang/python-2.7.14-r1:2.7 sqlite
>=sys-libs/zlib-1.2.11-r1 minizip

And, I thought unmasking was related to keywords - allowing or not allowing 
experimental versions ... why is that in /etc/portage/package.use?



> Gesendet: Dienstag, 04. Juni 2019 um 00:09 Uhr
> Von: n952...@web.de
> An: gentoo-user@lists.gentoo.org
> Betreff: Aw: Re: [gentoo-user] Updating portage, continued
>
> I'm sorry, I'm not getting this yet.  What if I just don't update these 
> configuration files?
>
> dispatch-conf tells me, for  /etc/portage/package.accept_keywords:
>
> --- /etc/portage/package.use/zz-autounmask  2018-03-12 21:56:49.172491972 
> +0100
> +++ /etc/portage/package.use/._cfg0015_zz-autounmask2018-07-28 
> 11:08:23.725995803 +0200
> @@ -1,2 +1,5 @@
>  >=dev-lang/python-2.7.14-r1:2.7 sqlite
>  >=sys-libs/zlib-1.2.11-r1 minizip
> +# required by www-misc/monitorix-3.9.0::gentoo
> +# required by monitorix (argument)
> +>=net-analyzer/rrdtool-1.6.0-r1 perl graph
>
> I can zap it or merge it or skip it.   It looks like the emerge was 
> successful, so, why should I do anything?
>
> $ rrdtool
> RRDtool 1.6.01.6.0  Copyright by Tobias Oetiker 
>
>
> I would have thought that emerge would pend until I'd agreed to the override. 
>  But, it apparently went ahead and installed.
> So what's required still?  What will be different once I make the merge to 
> zz-autounmask?
>
>
>
>
> > Gesendet: Donnerstag, 30. Mai 2019 um 14:33 Uhr
> > Von: "Rich Freeman" 
> > An: gentoo-user@lists.gentoo.org
> > Betreff: Re: [gentoo-user] Updating portage, continued
> >
> > On Wed, May 29, 2019 at 6:37 PM  wrote:
> > >
> > > The next section of the response to my attempt to update portage is a 
> > > long list of packages, each terminated with a "(masked by: something or 
> > > other)".
> > >
> > > What does that tell me.  If it's masked, it shouldn't be available, 
> > > right?  But, I've got it:
> > >
> > > - virtual/perl-parent-0.234.0-r1::gentoo (masked by: package.mask)
> > >
> > > ls virtual/perl-parent/perl-parent-0.234.0-r1.ebuild
> > > virtual/perl-parent/perl-parent-0.234.0-r1.ebuild
> > >
> > > Can I get rid of it?  Is perl-parent always masked?
> > >
> >
> > I think one of the issues here is that you might be running a bit with
> > scissors.
> >
> > It seems like you might be using package.keywords, and now you're
> > dealing with package masks.
> >
> > Portage will let you override just about anything, but those default
> > behaviors all exist for a reason and you can easily end up painting
> > yourself into a corner.  Overriding keywords is something that isn't
> > too unsafe to do once you know what you're doing, but if you're doing
> > it a lot it can get out of hand (adding keywords for one package can
> > require 3 more, and if you keep that up it can really get out of
> > hand).  If you're overriding keywords frequently perhaps you should be
> > running the testing branch in the first place, etc.
> >
> > Overriding masks is something that should only be done if you REALLY
> > know what you're doing.  If something is masked it might contain
> > security vulnerabilities, or it might be going away.  The consequences
> > of the former are obvious.  If it is going away then you're going to
> > be fighting to keep things working because the next step will be
> > removal and other packages will start being modified to not work with
> > the old approach.
> >
> > Basically, any setting you put in /etc/portage is something you're
> > going to have to work to maintain, so you should be doing whatever you
> > can to minimize this.  By all means speak up on the list about "I'm
> > trying to accomplish this, and is there a better way to go about it?"
> > If you're creating a ton of entries in /etc/portage you might be
> > fighting the package manager more than necessary.  There is nothing
> > wrong with customizing things (that is basically what Gentoo is for),
> > but you definitely need to learn how to manage that so that you don't
> > make life hard on yourself.
> >
> > --
> > Rich
> >
> >
>
>



Aw: Re: [gentoo-user] Updating portage, continued

2019-06-03 Thread n952162
I'm sorry, I'm not getting this yet.  What if I just don't update these 
configuration files?

dispatch-conf tells me, for  /etc/portage/package.accept_keywords:

--- /etc/portage/package.use/zz-autounmask  2018-03-12 21:56:49.172491972 
+0100
+++ /etc/portage/package.use/._cfg0015_zz-autounmask2018-07-28 
11:08:23.725995803 +0200
@@ -1,2 +1,5 @@
 >=dev-lang/python-2.7.14-r1:2.7 sqlite
 >=sys-libs/zlib-1.2.11-r1 minizip
+# required by www-misc/monitorix-3.9.0::gentoo
+# required by monitorix (argument)
+>=net-analyzer/rrdtool-1.6.0-r1 perl graph

I can zap it or merge it or skip it.   It looks like the emerge was successful, 
so, why should I do anything?

$ rrdtool
RRDtool 1.6.01.6.0  Copyright by Tobias Oetiker 


I would have thought that emerge would pend until I'd agreed to the override.  
But, it apparently went ahead and installed.
So what's required still?  What will be different once I make the merge to 
zz-autounmask?




> Gesendet: Donnerstag, 30. Mai 2019 um 14:33 Uhr
> Von: "Rich Freeman" 
> An: gentoo-user@lists.gentoo.org
> Betreff: Re: [gentoo-user] Updating portage, continued
>
> On Wed, May 29, 2019 at 6:37 PM  wrote:
> >
> > The next section of the response to my attempt to update portage is a long 
> > list of packages, each terminated with a "(masked by: something or other)".
> >
> > What does that tell me.  If it's masked, it shouldn't be available, right?  
> > But, I've got it:
> >
> > - virtual/perl-parent-0.234.0-r1::gentoo (masked by: package.mask)
> >
> > ls virtual/perl-parent/perl-parent-0.234.0-r1.ebuild
> > virtual/perl-parent/perl-parent-0.234.0-r1.ebuild
> >
> > Can I get rid of it?  Is perl-parent always masked?
> >
>
> I think one of the issues here is that you might be running a bit with
> scissors.
>
> It seems like you might be using package.keywords, and now you're
> dealing with package masks.
>
> Portage will let you override just about anything, but those default
> behaviors all exist for a reason and you can easily end up painting
> yourself into a corner.  Overriding keywords is something that isn't
> too unsafe to do once you know what you're doing, but if you're doing
> it a lot it can get out of hand (adding keywords for one package can
> require 3 more, and if you keep that up it can really get out of
> hand).  If you're overriding keywords frequently perhaps you should be
> running the testing branch in the first place, etc.
>
> Overriding masks is something that should only be done if you REALLY
> know what you're doing.  If something is masked it might contain
> security vulnerabilities, or it might be going away.  The consequences
> of the former are obvious.  If it is going away then you're going to
> be fighting to keep things working because the next step will be
> removal and other packages will start being modified to not work with
> the old approach.
>
> Basically, any setting you put in /etc/portage is something you're
> going to have to work to maintain, so you should be doing whatever you
> can to minimize this.  By all means speak up on the list about "I'm
> trying to accomplish this, and is there a better way to go about it?"
> If you're creating a ton of entries in /etc/portage you might be
> fighting the package manager more than necessary.  There is nothing
> wrong with customizing things (that is basically what Gentoo is for),
> but you definitely need to learn how to manage that so that you don't
> make life hard on yourself.
>
> --
> Rich
>
>



[gentoo-user] runc, docker and musl

2019-06-03 Thread Petr Vaněk
Hi,

I am wondering why we have so strict dependency to
~app-emulation/runc-1.0.0_rc6_p20190216[apparmor?,seccomp?]
in docker ebuilds?

I cannot build runc-1.0.0_rc6_p20190216 against musl libc since musl
does not implement secure_getenv function. However, I forced
installation of docker with runc-1.0.0_rc6_p20181203-r1 and everything
seems to work correctly.

Cheers
Petr