[gentoo-user] Re: depclean stopped working
On 17/04/12 18:10, Alan McKinnon wrote:
On Tue, 17 Apr 2012 18:01:43 +0300
Nikos Chantziarasrea...@gmail.com wrote:
emerge --depclean seems to have bugged out for me:
* Dependencies could not be completely resolved due to
* the following required packages not being installed:
*
* =dev-libs/openssl-0.9.8* pulled in by:
* app-emulation/vmware-workstation-8.0.2.591240
*
* dev-libs/openssl:0.9.8 pulled in by:
* www-client/google-chrome-19.0.1084.24_beta131971
It says to do a emerge --update --newuse --deep --with-bdeps=y
@world. Which is what I just did to begin with (and running it again
doesn't result in anything getting emerged.)
It also says:
* Also, note that it may be necessary to manually uninstall
* packages that no longer exist in the portage tree, since it may
* not be possible to satisfy their dependencies.
However, dev-libs/openssl is installed and seems to be in the tree:
$ eix -e dev-libs/openssl
[I] dev-libs/openssl
Available versions:
(0.9.8) 0.9.8r (~)0.9.8s 0.9.8s-r1 0.9.8t 0.9.8u
(0) 1.0.0d 1.0.0e (~)1.0.0e-r1 (~)1.0.0f 1.0.0f-r1
1.0.0g 1.0.0h **1.0.1
{{bindist gmp kerberos rfc3779 sse2 static-libs test vanilla
zlib}} Installed versions: 0.9.8u(0.9.8)(22:32:12 12/03/12)(sse2
zlib -bindist -gmp -kerberos -test) 1.0.0h(22:33:20 12/03/12)(sse2
zlib -bindist -gmp -kerberos -rfc3779 -static-libs -test)
I think you should file a bug against www-client/google-chrome
It wants the exact version dev-libs/openssl:0.9.8 but the oldest in
portage is dev-libs/openssl:0.9.8r
Chances are the dev simply left off the version suffix by accident
That can't be it. There's a wildcard at the end:
=dev-libs/openssl-0.9.8*
which should match 0.9.8u.
[gentoo-user] Re: depclean stopped working
On 17/04/12 18:34, Nikos Chantziaras wrote:
On 17/04/12 18:10, Alan McKinnon wrote:
On Tue, 17 Apr 2012 18:01:43 +0300
Nikos Chantziarasrea...@gmail.com wrote:
emerge --depclean seems to have bugged out for me:
* Dependencies could not be completely resolved due to
* the following required packages not being installed:
*
* =dev-libs/openssl-0.9.8* pulled in by:
* app-emulation/vmware-workstation-8.0.2.591240
*
* dev-libs/openssl:0.9.8 pulled in by:
* www-client/google-chrome-19.0.1084.24_beta131971
It says to do a emerge --update --newuse --deep --with-bdeps=y
@world. Which is what I just did to begin with (and running it again
doesn't result in anything getting emerged.)
It also says:
* Also, note that it may be necessary to manually uninstall
* packages that no longer exist in the portage tree, since it may
* not be possible to satisfy their dependencies.
However, dev-libs/openssl is installed and seems to be in the tree:
$ eix -e dev-libs/openssl
[I] dev-libs/openssl
Available versions:
(0.9.8) 0.9.8r (~)0.9.8s 0.9.8s-r1 0.9.8t 0.9.8u
(0) 1.0.0d 1.0.0e (~)1.0.0e-r1 (~)1.0.0f 1.0.0f-r1
1.0.0g 1.0.0h **1.0.1
{{bindist gmp kerberos rfc3779 sse2 static-libs test vanilla
zlib}} Installed versions: 0.9.8u(0.9.8)(22:32:12 12/03/12)(sse2
zlib -bindist -gmp -kerberos -test) 1.0.0h(22:33:20 12/03/12)(sse2
zlib -bindist -gmp -kerberos -rfc3779 -static-libs -test)
I think you should file a bug against www-client/google-chrome
It wants the exact version dev-libs/openssl:0.9.8 but the oldest in
portage is dev-libs/openssl:0.9.8r
Chances are the dev simply left off the version suffix by accident
That can't be it. There's a wildcard at the end:
=dev-libs/openssl-0.9.8*
which should match 0.9.8u.
No wait, that's vmware. The chrome ebuild pulls a slot:
dev-libs/openssl:0.9.8
This also matches correctly. The 0.9.8 slot matches all those versions.
So no problem with that either.
Re: [gentoo-user] Re: depclean stopped working
On Tue, 17 Apr 2012 18:41:55 +0300
Nikos Chantziaras rea...@gmail.com wrote:
On 17/04/12 18:34, Nikos Chantziaras wrote:
On 17/04/12 18:10, Alan McKinnon wrote:
On Tue, 17 Apr 2012 18:01:43 +0300
Nikos Chantziarasrea...@gmail.com wrote:
emerge --depclean seems to have bugged out for me:
* Dependencies could not be completely resolved due to
* the following required packages not being installed:
*
* =dev-libs/openssl-0.9.8* pulled in by:
* app-emulation/vmware-workstation-8.0.2.591240
*
* dev-libs/openssl:0.9.8 pulled in by:
* www-client/google-chrome-19.0.1084.24_beta131971
It says to do a emerge --update --newuse --deep --with-bdeps=y
@world. Which is what I just did to begin with (and running it
again doesn't result in anything getting emerged.)
It also says:
* Also, note that it may be necessary to manually uninstall
* packages that no longer exist in the portage tree, since it may
* not be possible to satisfy their dependencies.
However, dev-libs/openssl is installed and seems to be in the
tree:
$ eix -e dev-libs/openssl
[I] dev-libs/openssl
Available versions:
(0.9.8) 0.9.8r (~)0.9.8s 0.9.8s-r1 0.9.8t 0.9.8u
(0) 1.0.0d 1.0.0e (~)1.0.0e-r1 (~)1.0.0f 1.0.0f-r1
1.0.0g 1.0.0h **1.0.1
{{bindist gmp kerberos rfc3779 sse2 static-libs test vanilla
zlib}} Installed versions: 0.9.8u(0.9.8)(22:32:12 12/03/12)(sse2
zlib -bindist -gmp -kerberos -test) 1.0.0h(22:33:20 12/03/12)(sse2
zlib -bindist -gmp -kerberos -rfc3779 -static-libs -test)
I think you should file a bug against www-client/google-chrome
It wants the exact version dev-libs/openssl:0.9.8 but the oldest in
portage is dev-libs/openssl:0.9.8r
Chances are the dev simply left off the version suffix by accident
That can't be it. There's a wildcard at the end:
=dev-libs/openssl-0.9.8*
which should match 0.9.8u.
No wait, that's vmware. The chrome ebuild pulls a slot:
dev-libs/openssl:0.9.8
This also matches correctly. The 0.9.8 slot matches all those
versions. So no problem with that either.
I missed that colon for the slot.
So this certainly looks buggy on the part of depclean. Now to find out
what's going on.
One thing that strikes me as a possibility is that the highest numbered
version has the lower slot number (0). I know that SLOT names are
just names and not supposed to be treated like they form an order, but
I've seen odd things like this before. I think KDE did it to me once.
What happens if you emerge openssl:0.9.8, let it go into world, then
run depclean? The build takes 2 minutes and you can easily remove it
from world later.
--
Alan McKinnnon
alan.mckin...@gmail.com
[gentoo-user] Re: depclean stopped working
On 17/04/12 19:39, Alan McKinnon wrote: On Tue, 17 Apr 2012 18:41:55 +0300 Nikos Chantziarasrea...@gmail.com wrote: On 17/04/12 18:34, Nikos Chantziaras wrote: On 17/04/12 18:10, Alan McKinnon wrote: On Tue, 17 Apr 2012 18:01:43 +0300 Nikos Chantziarasrea...@gmail.com wrote: emerge --depclean seems to have bugged out for me: * Dependencies could not be completely resolved due to * the following required packages not being installed: * * =dev-libs/openssl-0.9.8* pulled in by: * app-emulation/vmware-workstation-8.0.2.591240 * * dev-libs/openssl:0.9.8 pulled in by: * www-client/google-chrome-19.0.1084.24_beta131971 It says to do a emerge --update --newuse --deep --with-bdeps=y @world. Which is what I just did to begin with (and running it again doesn't result in anything getting emerged.) [...] One thing that strikes me as a possibility is that the highest numbered version has the lower slot number (0). I know that SLOT names are just names and not supposed to be treated like they form an order, but I've seen odd things like this before. I think KDE did it to me once. What happens if you emerge openssl:0.9.8, let it go into world, then run depclean? The build takes 2 minutes and you can easily remove it from world later. Nope, nothing changed.
[gentoo-user] Re: depclean stopped working
On 17/04/12 18:01, Nikos Chantziaras wrote: emerge --depclean seems to have bugged out for me: * Dependencies could not be completely resolved due to * the following required packages not being installed: * * =dev-libs/openssl-0.9.8* pulled in by: * app-emulation/vmware-workstation-8.0.2.591240 * * dev-libs/openssl:0.9.8 pulled in by: * www-client/google-chrome-19.0.1084.24_beta131971 It says to do a emerge --update --newuse --deep --with-bdeps=y @world. Which is what I just did to begin with (and running it again doesn't result in anything getting emerged.) I filed a bug about this: https://bugs.gentoo.org/show_bug.cgi?id=412391 If someone wants to try and reproduce this: emerge www-client/google-chrome emerge -a --depclean
Re: [gentoo-user] Re: depclean stopped working
On Tue, Apr 17, 2012 at 1:13 PM, Nikos Chantziaras rea...@gmail.com wrote: On 17/04/12 18:01, Nikos Chantziaras wrote: emerge --depclean seems to have bugged out for me: * Dependencies could not be completely resolved due to * the following required packages not being installed: * * =dev-libs/openssl-0.9.8* pulled in by: * app-emulation/vmware-workstation-8.0.2.591240 * * dev-libs/openssl:0.9.8 pulled in by: * www-client/google-chrome-19.0.1084.24_beta131971 It says to do a emerge --update --newuse --deep --with-bdeps=y @world. Which is what I just did to begin with (and running it again doesn't result in anything getting emerged.) I filed a bug about this: https://bugs.gentoo.org/show_bug.cgi?id=412391 If someone wants to try and reproduce this: emerge www-client/google-chrome emerge -a --depclean FWIW I have google-chrome and vmware-workstation (same versions quoted above) installed and don't see this issue (~amd64 box). My installed openssl are version 0.9.8u and 1.0.0h.
