[gentoo-user] update world problem (looks like slot confusion on my part)

[gentoo-user] update world problem (looks like slot confusion on my part)

[gottlieb]

(I am in the months long process of converting from testing to stable,
using the bothwick "going stable" method; but I don't believe that is
related to the question I am asking.)

I was away for several days and have a number of problem with my
normally-daily update world.  Some may be due to the testing-->stable
conversion but some I just don't understand at all.

The first complaint is

  Conflict: 2 blocks (1 unsatisfied)

  !!! Multiple package instances within a single package slot have been pulled
  !!! into the dependency graph, resulting in a slot conflict:

  dev-libs/openssl:0

    (dev-libs/openssl-1.0.1h-r1::gentoo, installed) pulled in by
      (no parents that aren't satisfied by other packages in this slot)

    (dev-libs/openssl-1.0.1h-r2::gentoo, ebuild scheduled for merge) pulled in by
      >=dev-libs/openssl-1.0.1h-r2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (net-nds/openldap-2.4.38-r2::gentoo, installed)

I assume that the "no parents that aren't satisfied ..." means that
portage could handle this one.

There are a few more again with "no parents ...".  Then comes one that I
can't understand

  virtual/libintl:0

    (virtual/libintl-0-r1::gentoo, ebuild scheduled for merge) pulled in by
      >=virtual/libintl-0-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (net-libs/gnutls-3.3.4::gentoo, ebuild scheduled for merge)

    (virtual/libintl-0::gentoo, installed) pulled in by
      =virtual/libintl-0 required by (net-analyzer/nmap-6.25::gentoo, installed)
      (and 31 more with the same problem)

This seems to say that nmap-6.25 requires specifically
virtual/libintl-0.  But I went to net-analyzer/nmap-6.25.ebuild and the
only occurrence of libintl is 
  	nls? ( virtual/libintl )
in RDEPEND

Why does this require specifically virtual/libintl-0 and not permit
virtual/libintl-0-r1?

Any help would be appreciated.
allan

Re: [gentoo-user] update world problem (looks like slot confusion on my part)

[Alan McKinnon]

On 19/06/2014 21:17, gottlieb@nyu.edu wrote:
> (I am in the months long process of converting from testing to stable,
> using the bothwick "going stable" method; but I don't believe that is
> related to the question I am asking.)
> 
> I was away for several days and have a number of problem with my
> normally-daily update world.  Some may be due to the testing-->stable
> conversion but some I just don't understand at all.


First thing: I understand why you want to go testing -> stable, but at
least leave portage unstable. A *lot* of ancient stuff has been fixed in
~arch, it's perfectly safe and robust, and most especially all that
stupid "no parents that aren't satisfied by other packages in this slot"
has gone away, replaced with something that a) works and b) makes sense
and c) does not reduce the poor sysadmin (i.e you) to tears


> 
> The first complaint is
> 
>   Conflict: 2 blocks (1 unsatisfied)
> 
>   !!! Multiple package instances within a single package slot have been pulled
>   !!! into the dependency graph, resulting in a slot conflict:
> 
>   dev-libs/openssl:0
> 
>     (dev-libs/openssl-1.0.1h-r1::gentoo, installed) pulled in by
>       (no parents that aren't satisfied by other packages in this slot)
> 
>     (dev-libs/openssl-1.0.1h-r2::gentoo, ebuild scheduled for merge) pulled in by
>       >=dev-libs/openssl-1.0.1h-r2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (net-nds/openldap-2.4.38-r2::gentoo, installed)
> 
> I assume that the "no parents that aren't satisfied ..." means that
> portage could handle this one.

Yes, I believe that's how it worked. Portage was being unneccessarily
verbose. If you need to you can always "emerge -1 openssl" to get past
the messages

> 
> There are a few more again with "no parents ...".  Then comes one that I
> can't understand
> 
>   virtual/libintl:0
> 
>     (virtual/libintl-0-r1::gentoo, ebuild scheduled for merge) pulled in by
>       >=virtual/libintl-0-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (net-libs/gnutls-3.3.4::gentoo, ebuild scheduled for merge)
> 
>     (virtual/libintl-0::gentoo, installed) pulled in by
>       =virtual/libintl-0 required by (net-analyzer/nmap-6.25::gentoo, installed)
>       (and 31 more with the same problem)
> 
> This seems to say that nmap-6.25 requires specifically
> virtual/libintl-0.  But I went to net-analyzer/nmap-6.25.ebuild and the
> only occurrence of libintl is 
>   	nls? ( virtual/libintl )
> in RDEPEND
> 
> Why does this require specifically virtual/libintl-0 and not permit
> virtual/libintl-0-r1?

It's not nmap doing it, it is gnutls. Look again at the first line (for
the -r1 version). Your gnutls is still ~arch and stable hasn't caught up
yet. Run this

emerge -1 gnutls

then continue with your regular world update.

In summary, when you get these weird blockers, always check if the
higher number version is being pulled in by something ~arch. Then
downgrade that offender manually.



I would also advise you speed this along by doing this:

emerge -av1 @system
followed by a full @preserved-rebuild, depclean, revdep-rebuild (don't
skimp on these 3, you want to check everything

The system set updates slowly and can take forever for stable to catch
up. Better to just get your critical base packages onto stable asap.

Then the same for perl and python followed by the usual perl-cleaner and
python-updater. It should be safe to let the rest of world update at
it's own speed

> 
> Any help would be appreciated.
> allan
> 
> 
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] update world problem (looks like slot confusion on my part)

[Rich Freeman]

On Thu, Jun 19, 2014 at 5:10 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> First thing: I understand why you want to go testing -> stable, but at
> least leave portage unstable. A *lot* of ancient stuff has been fixed in
> ~arch, it's perfectly safe and robust, and most especially all that
> stupid "no parents that aren't satisfied by other packages in this slot"
> has gone away, replaced with something that a) works and b) makes sense
> and c) does not reduce the poor sysadmin (i.e you) to tears

Stable is only three months older than ~arch, though it may very well
be much better (can't say I've used the ~arch version).  Portage has
fortunately been keeping up much better on stable of late.

If there are packages that simply aren't acceptable in their stable
versions, I'd call that a bug...

Rich

Re: [gentoo-user] update world problem (looks like slot confusion on my part)

[Alan McKinnon]

On 19/06/2014 23:20, Rich Freeman wrote:
> On Thu, Jun 19, 2014 at 5:10 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> First thing: I understand why you want to go testing -> stable, but at
>> least leave portage unstable. A *lot* of ancient stuff has been fixed in
>> ~arch, it's perfectly safe and robust, and most especially all that
>> stupid "no parents that aren't satisfied by other packages in this slot"
>> has gone away, replaced with something that a) works and b) makes sense
>> and c) does not reduce the poor sysadmin (i.e you) to tears
> 
> Stable is only three months older than ~arch, though it may very well
> be much better (can't say I've used the ~arch version).  Portage has
> fortunately been keeping up much better on stable of late.

Yes, that is true. It's also the one package we Gentoo'ers use more
often than anything else, so any non-optimumness shows up very quickly,
and gets noticed.


> If there are packages that simply aren't acceptable in their stable
> versions, I'd call that a bug...

I wouldn't go that far :-)

Stable portage gets the job done (after all, the stable code was in
unstable for a long time and we all dealt with it OK).

As I see it, it's a simple question of effectively communicating the
information that portage has to the user. If the dev wants to rate this
as a bug then it's already fixed in ~arch and the next step is to
stabilize that code

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] update world problem (looks like slot confusion on my part)

[gottlieb]

On Thu, Jun 19 2014, Alan McKinnon wrote:

> On 19/06/2014 21:17, gottlieb@nyu.edu wrote:
>> 
>> There are a few more again with "no parents ...".  Then comes one that I
>> can't understand
>> 
>>   virtual/libintl:0
>> 
>>     (virtual/libintl-0-r1::gentoo, ebuild scheduled for merge) pulled in by
>>       >=virtual/libintl-0-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
>>       > required by (net-libs/gnutls-3.3.4::gentoo, ebuild scheduled
>>       > for merge)
>> 
>>     (virtual/libintl-0::gentoo, installed) pulled in by
>>       =virtual/libintl-0 required by (net-analyzer/nmap-6.25::gentoo, installed)
>>       (and 31 more with the same problem)
>> 
>> This seems to say that nmap-6.25 requires specifically
>> virtual/libintl-0.  But I went to net-analyzer/nmap-6.25.ebuild and the
>> only occurrence of libintl is 
>>   	nls? ( virtual/libintl )
>> in RDEPEND
>> 
>> Why does this require specifically virtual/libintl-0 and not permit
>> virtual/libintl-0-r1?
>
> It's not nmap doing it, it is gnutls. Look again at the first line (for
> the -r1 version). Your gnutls is still ~arch and stable hasn't caught up
> yet. Run this
>
> emerge -1 gnutls
>
> then continue with your regular world update.
>
> In summary, when you get these weird blockers, always check if the
> higher number version is being pulled in by something ~arch. Then
> downgrade that offender manually.

I am trying to understand this but having difficulty.  Perhaps the whole
problem is caused by later complaints from portage asking me to keyword
items.

I understand that gnutls-3.3.4 needs the -r1 version of
virtual/libintl-0.  I don't understand why the other packages (nmap-6.25
and 31 others) are not happy with the -r1.  Maybe this is just bad
wording on portage's part and the real problem is that the -r1 version is
keyworded and I am "going stable" without virtual/libintl in
package.accept-keywords.

I don't think that emerge -1 gnutls will help since it simply re-installs
the stable 2.12.23-r6.

The question is why do I need the testing gnutls-3.3.4 ?  The answer
according to portage (further down in the error messages) is

  The following keyword changes are necessary to proceed:
   (see "package.accept_keywords" in the portage(5) man page for more details)
  # required by net-im/empathy-3.10.3
  # required by gnome-base/gnome-core-apps-3.10.0
  # required by gnome-base/gnome-3.10.0
  # required by @selected
  # required by @world (argument)
  =net-libs/gnutls-3.3.4 ~amd64

However I currently have empathy-3.10.3 and the ebuild for stable
net-im/empathy-3.10.3 has in COMMON_DEPEND
	>=net-libs/gnutls-2.8.5:=

My current gnutls is 2.12.23-r6.  Is the problem the := ?  Anyway I
don't believe STABLE empathy should require TESTING gnutls.

thanks again for helping and thanks in advance for clearing up my
confusion.

allan

Re: [gentoo-user] update world problem (looks like slot confusion on my part)

[Alan McKinnon]

On 20/06/2014 00:22, gottlieb@nyu.edu wrote:
> On Thu, Jun 19 2014, Alan McKinnon wrote:
> 
>> On 19/06/2014 21:17, gottlieb@nyu.edu wrote:
>>>
>>> There are a few more again with "no parents ...".  Then comes one that I
>>> can't understand
>>>
>>>   virtual/libintl:0
>>>
>>>     (virtual/libintl-0-r1::gentoo, ebuild scheduled for merge) pulled in by
>>>       >=virtual/libintl-0-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
>>>       > required by (net-libs/gnutls-3.3.4::gentoo, ebuild scheduled
>>>       > for merge)
>>>
>>>     (virtual/libintl-0::gentoo, installed) pulled in by
>>>       =virtual/libintl-0 required by (net-analyzer/nmap-6.25::gentoo, installed)
>>>       (and 31 more with the same problem)
>>>
>>> This seems to say that nmap-6.25 requires specifically
>>> virtual/libintl-0.  But I went to net-analyzer/nmap-6.25.ebuild and the
>>> only occurrence of libintl is 
>>>   	nls? ( virtual/libintl )
>>> in RDEPEND
>>>
>>> Why does this require specifically virtual/libintl-0 and not permit
>>> virtual/libintl-0-r1?
>>
>> It's not nmap doing it, it is gnutls. Look again at the first line (for
>> the -r1 version). Your gnutls is still ~arch and stable hasn't caught up
>> yet. Run this
>>
>> emerge -1 gnutls
>>
>> then continue with your regular world update.
>>
>> In summary, when you get these weird blockers, always check if the
>> higher number version is being pulled in by something ~arch. Then
>> downgrade that offender manually.
> 
> I am trying to understand this but having difficulty.  Perhaps the whole
> problem is caused by later complaints from portage asking me to keyword
> items.
> 
> I understand that gnutls-3.3.4 needs the -r1 version of
> virtual/libintl-0.  I don't understand why the other packages (nmap-6.25
> and 31 others) are not happy with the -r1.  Maybe this is just bad
> wording on portage's part and the real problem is that the -r1 version is
> keyworded and I am "going stable" without virtual/libintl in
> package.accept-keywords.
> 
> I don't think that emerge -1 gnutls will help since it simply re-installs
> the stable 2.12.23-r6.

Ah, I see what it is. libintl is being pulled in by gnutls, which is
being pulled in by something else (gnutls is scheduled for emerge). To
find out what that something is, use emerge with -t

These dependency chains can get long and complex, so best is usually to
look at the whole thing and see exactly what is going on. Most often you
have something in world that is keyworded, or the current version is
still ~arch


> 
> The question is why do I need the testing gnutls-3.3.4 ?  The answer
> according to portage (further down in the error messages) is
> 
>   The following keyword changes are necessary to proceed:
>    (see "package.accept_keywords" in the portage(5) man page for more details)
>   # required by net-im/empathy-3.10.3
>   # required by gnome-base/gnome-core-apps-3.10.0
>   # required by gnome-base/gnome-3.10.0
>   # required by @selected
>   # required by @world (argument)
>   =net-libs/gnutls-3.3.4 ~amd64
> 
> However I currently have empathy-3.10.3 and the ebuild for stable
> net-im/empathy-3.10.3 has in COMMON_DEPEND
> 	>=net-libs/gnutls-2.8.5:=
> 
> My current gnutls is 2.12.23-r6.  Is the problem the := ?  Anyway I
> don't believe STABLE empathy should require TESTING gnutls.

You are right, that output doesn't make sense, possibly you have some
local config that is making it happen? Again -t will help sort out the
chain.

Something I find useful for these situations, take gnutls as an example:

grep -ir gnutls /etc/portage

finds everything I added to package.* and forgot about :-)
My make.conf is in /etc/portage, if yours is still in /etc/ you'll have
to grep that file as well




> 
> thanks again for helping and thanks in advance for clearing up my
> confusion.
> 
> allan
> 
> 
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] update world problem (looks like slot confusion on my part)

[Alan McKinnon]

On 20/06/2014 00:22, gottlieb@nyu.edu wrote:
> On Thu, Jun 19 2014, Alan McKinnon wrote:
> 
>> On 19/06/2014 21:17, gottlieb@nyu.edu wrote:
>>>
>>> There are a few more again with "no parents ...".  Then comes one that I
>>> can't understand
>>>
>>>   virtual/libintl:0
>>>
>>>     (virtual/libintl-0-r1::gentoo, ebuild scheduled for merge) pulled in by
>>>       >=virtual/libintl-0-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
>>>       > required by (net-libs/gnutls-3.3.4::gentoo, ebuild scheduled
>>>       > for merge)
>>>
>>>     (virtual/libintl-0::gentoo, installed) pulled in by
>>>       =virtual/libintl-0 required by (net-analyzer/nmap-6.25::gentoo, installed)
>>>       (and 31 more with the same problem)
>>>
>>> This seems to say that nmap-6.25 requires specifically
>>> virtual/libintl-0.  But I went to net-analyzer/nmap-6.25.ebuild and the
>>> only occurrence of libintl is 
>>>   	nls? ( virtual/libintl )
>>> in RDEPEND
>>>
>>> Why does this require specifically virtual/libintl-0 and not permit
>>> virtual/libintl-0-r1?
>>
>> It's not nmap doing it, it is gnutls. Look again at the first line (for
>> the -r1 version). Your gnutls is still ~arch and stable hasn't caught up
>> yet. Run this
>>
>> emerge -1 gnutls
>>
>> then continue with your regular world update.
>>
>> In summary, when you get these weird blockers, always check if the
>> higher number version is being pulled in by something ~arch. Then
>> downgrade that offender manually.
> 
> I am trying to understand this but having difficulty.  Perhaps the whole
> problem is caused by later complaints from portage asking me to keyword
> items.
> 
> I understand that gnutls-3.3.4 needs the -r1 version of
> virtual/libintl-0.  I don't understand why the other packages (nmap-6.25
> and 31 others) are not happy with the -r1.  Maybe this is just bad
> wording on portage's part and the real problem is that the -r1 version is
> keyworded and I am "going stable" without virtual/libintl in
> package.accept-keywords.
> 
> I don't think that emerge -1 gnutls will help since it simply re-installs
> the stable 2.12.23-r6.

Ah, I see what it is. libintl is being pulled in by gnutls, which is
being pulled in by something else (gnutls is scheduled for emerge). To
find out what that something is, use emerge with -t

These dependency chains can get long and complex, so best is usually to
look at the whole thing and see exactly what is going on. Most often you
have something in world that is keyworded, or the current version is
still ~arch


> 
> The question is why do I need the testing gnutls-3.3.4 ?  The answer
> according to portage (further down in the error messages) is
> 
>   The following keyword changes are necessary to proceed:
>    (see "package.accept_keywords" in the portage(5) man page for more details)
>   # required by net-im/empathy-3.10.3
>   # required by gnome-base/gnome-core-apps-3.10.0
>   # required by gnome-base/gnome-3.10.0
>   # required by @selected
>   # required by @world (argument)
>   =net-libs/gnutls-3.3.4 ~amd64
> 
> However I currently have empathy-3.10.3 and the ebuild for stable
> net-im/empathy-3.10.3 has in COMMON_DEPEND
> 	>=net-libs/gnutls-2.8.5:=
> 
> My current gnutls is 2.12.23-r6.  Is the problem the := ?  Anyway I
> don't believe STABLE empathy should require TESTING gnutls.

You are right, that output doesn't make sense, possibly you have some
local config that is making it happen? Again -t will help sort out the
chain.

Something I find useful for these situations, take gnutls as an example:

grep -ir gnutls /etc/portage

finds everything I added to package.* and forgot about :-)
My make.conf is in /etc/portage, if yours is still in /etc/ you'll have
to grep that file as well




> 
> thanks again for helping and thanks in advance for clearing up my
> confusion.
> 
> allan
> 
> 
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] update world problem (looks like slot confusion on my part)

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

On Fri, 20 Jun 2014 13:33:26 +0200, Alan McKinnon wrote:

> These dependency chains can get long and complex, so best is usually to
> look at the whole thing and see exactly what is going on. Most often you
> have something in world that is keyworded, or the current version is
> still ~arch

Another problem with this method of switching to stable gradually is that
it sometimes want to downgrade a package.Say foo-1.0 is stable and
foo-1.1 is testing and you have ~foo-1.1 in package.accept_keywords. Then
foo-1.1.1 is added to ~arch and the 1.1 ebuild is removed, having never
been stabilised. Portage will then try to downgrade to 1.0, possibly
messing with your dependencies.

The moral is always look for portage trying to downgrade packages and add
the appropriate keyword entries when using this approach.


-- 
Neil Bothwick

Earlier, I didn't have time to finish anything. This time I w

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] update world problem (looks like slot confusion on my part)

[Rich Freeman]

On Fri, Jun 20, 2014 at 3:39 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
>
> The moral is always look for portage trying to downgrade packages and add
> the appropriate keyword entries when using this approach.
>

The only issue with this is that you never get back to stable that way.

What I usually do if I am tracking testing on a package and want to
get back to stable is one of two things:
1.  Mask all versions less than what I have.  Then I won't get downgraded.
2.  Keyword all versions less than the next big release.  Then I'll
keep getting bugfixes in ~arch but won't get promoted to the next big
release, and hopefully at that point stable catches up.

In general moving from testing to stable is a bit of a pain though -
I've never actually done it for a whole system.  It is enough of a
pain when you get ahead on one package and want to drop back.

Rich

Re: [gentoo-user] update world problem (looks like slot confusion on my part)

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

On Fri, 20 Jun 2014 21:20:52 -0400, Rich Freeman wrote:

> > The moral is always look for portage trying to downgrade packages and
> > add the appropriate keyword entries when using this approach.
> >  
> 
> The only issue with this is that you never get back to stable that way.

You will, it just takes a few steps with the odd package. The situation
only arises where a release is pulled before ever going stable,
generally because testing did its job and found a problem. Most packages
do not need this attention.


-- 
Neil Bothwick

Vital papers will demonstrate their vitality by moving to where you
can't find them.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] update world problem (looks like slot confusion on my part)

[gottlieb]

On Sat, Jun 21 2014, Neil Bothwick wrote:

> On Fri, 20 Jun 2014 21:20:52 -0400, Rich Freeman wrote:
>
>> > The moral is always look for portage trying to downgrade packages and
>> > add the appropriate keyword entries when using this approach.
>> >  
>> 
>> The only issue with this is that you never get back to stable that way.
>
> You will, it just takes a few steps with the odd package. The situation
> only arises where a release is pulled before ever going stable,
> generally because testing did its job and found a problem. Most packages
> do not need this attention.

I see.  During my "going stable" period I had this occur a few times.
Some times I let portage downgrade other times and added the keyword
entries other times (for me the second case involved updating not adding
keyword entries)

This time I am being asked to add keyword entries.  I will follow your
advice and not consider downgrading to the highest stable version.

thanks for the advice.
allan