Re: [gentoo-user] Confusing emerge output
On 02/03/2013 04:00 PM, Alan McKinnon wrote: http://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators I'd already found much the same info in devmanual by the time I got and read your reply. So let's see if I understand this now: Beats me. I know what they're supposed to do, but haven't bothered to figure out how they work yet.
Re: [gentoo-user] Confusing emerge output
Alan McKinnon wrote: emerge -e --keep-going @world shows output like this when a build fails: * One or more packages are either masked or have missing dependencies: * * =dev-libs/icu-49:0/50= pulled in by: * (x11-libs/qt-core-4.8.4-r1::gentoo, installed) I can't parse that. What kind of SLOT is 0/50= ? So far this has happened twice. The packages that failed prior are not important, what is important is that when the depgraph is *recalculated*, I get that error. It's always that specific atom for icu causing issues and it's always pulled in by qt-something Anyone know what that atom means and if it's a bug or not? This system is ~amd64 and portage is latest masked 2.2.0_alpha161. Active python is 2.7 LOL I'll give this a go, sort of. I get this for icu: root@fireball / # equery l -p icu * Searching for icu ... [IP-] [ ] dev-libs/icu-49.1.2:0 [-P-] [ ~] dev-libs/icu-50.1-r1:0/50.1 [-P-] [ ~] dev-libs/icu-50.1-r2:0/50.1 [-P-] [ ~] dev-libs/icu-50.1.1:0/50.1.1 root@fireball / # So, does it maybe want icu-50.* instead of the 49 that is installed? That would be equal to or greater than what you likely have. I might add, the 50 and above are keyworded. I took a stab at it but not sure what I hit. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Confusing emerge output
On 02/03/2013 01:51 PM, Alan McKinnon wrote: emerge -e --keep-going @world shows output like this when a build fails: * One or more packages are either masked or have missing dependencies: * * =dev-libs/icu-49:0/50= pulled in by: * (x11-libs/qt-core-4.8.4-r1::gentoo, installed) I can't parse that. What kind of SLOT is 0/50= ? So far this has happened twice. The packages that failed prior are not important, what is important is that when the depgraph is *recalculated*, I get that error. It's always that specific atom for icu causing issues and it's always pulled in by qt-something Anyone know what that atom means and if it's a bug or not? http://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators
Re: [gentoo-user] Confusing emerge output
On 03/02/2013 21:28, Michael Orlitzky wrote:
On 02/03/2013 01:51 PM, Alan McKinnon wrote:
emerge -e --keep-going @world
shows output like this when a build fails:
* One or more packages are either masked or have missing dependencies:
*
* =dev-libs/icu-49:0/50= pulled in by:
* (x11-libs/qt-core-4.8.4-r1::gentoo, installed)
I can't parse that. What kind of SLOT is 0/50= ?
So far this has happened twice. The packages that failed prior are not
important,
what is important is that when the depgraph is *recalculated*, I get
that error.
It's always that specific atom for icu causing issues and it's always
pulled in
by qt-something
Anyone know what that atom means and if it's a bug or not?
http://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators
I'd already found much the same info in devmanual by the time I got and
read your reply. So let's see if I understand this now:
qt-core has this DEPEND:
icu? ( =dev-libs/icu-49:= )
My Qt is linked to this icu version:
libicuuc.so.50 = /usr/lib64/libicuuc.so.50 (0x7fa3a952c000)
But no version of icu in the tree provides that soname, as shown by eix:
Available versions: 49.1.2 (~)50.1-r1(0/50.1) (~)50.1-r2(0/50.1)
(~)50.1.1(0/50.1.1) {debug doc examples static-libs}
Installed versions: 50.1.1(09:40:50 15/01/2013)(-debug -doc
-examples -static-libs)
So, rebuilding Qt should trigger a rebuild of icu. Well, it doesn't
according to emerge -pv, but no matter. An emerge -e --keep-going @world
presumably will build icu-50.1.1, but when a package fails and the graph
is recalculated, something goes wrong.
Hmmm. bgo time.
https://bugs.gentoo.org/show_bug.cgi?id=455344
--
alan.mckin...@gmail.com
Re: [gentoo-user] Confusing emerge output
On 03/02/2013 21:09, Dale wrote: Alan McKinnon wrote: emerge -e --keep-going @world shows output like this when a build fails: * One or more packages are either masked or have missing dependencies: * * =dev-libs/icu-49:0/50= pulled in by: * (x11-libs/qt-core-4.8.4-r1::gentoo, installed) I can't parse that. What kind of SLOT is 0/50= ? So far this has happened twice. The packages that failed prior are not important, what is important is that when the depgraph is *recalculated*, I get that error. It's always that specific atom for icu causing issues and it's always pulled in by qt-something Anyone know what that atom means and if it's a bug or not? This system is ~amd64 and portage is latest masked 2.2.0_alpha161. Active python is 2.7 LOL I'll give this a go, sort of. I get this for icu: root@fireball / # equery l -p icu * Searching for icu ... [IP-] [ ] dev-libs/icu-49.1.2:0 [-P-] [ ~] dev-libs/icu-50.1-r1:0/50.1 [-P-] [ ~] dev-libs/icu-50.1-r2:0/50.1 [-P-] [ ~] dev-libs/icu-50.1.1:0/50.1.1 root@fireball / # So, does it maybe want icu-50.* instead of the 49 that is installed? That would be equal to or greater than what you likely have. I might add, the 50 and above are keyworded. I took a stab at it but not sure what I hit. ;-) It's confusing, lemme see if I can describe it, using the URL that Michel O posted. Your eix shows 4 versions of icu. Everything there up to the / chars is normal and what you've been using for ages. The / is sub-slots, introduced in EAPI=5. icu-49 uses a lesser EAPI so it has no sub-slots. Each icu version =50 is in SLOT 0, and it will install .so files with the version after the /. So take my icu for example, it's version 50.1.1 and equery files reveals it installs: /usr/lib64/libicui18n.so.50.1.1 /usr/lib64/libicuio.so.50.1.1 /usr/lib64/libicule.so.50.1.1 Well whaddaya know, the .so version matches what eix claims (meaning the icu ebuild is correctly declaring what it will provide). That's one half of the story, the other half is with packages that DEPEND on icu. qt-core for example has this: icu? ( =dev-libs/icu-49:= ) Now what that means is qt-core DEPENDS on any version of icu 49, plus the following: (this is the bit that's gonna bake your noodle) If icu is re-emerged and that new version has a different .so version to what the current version provides, then qt-core will break at run-time. That's what the trailing = means, ie. qt-core depends on an icu that has an soname equal to the one it has right now. In my case that is 50.1.1. If I upgrade icu to a version with a different soname, then qt-core has to be rebuilt, and now portage knows that. There's another operator that can go where the = is and it's *. Which basically means any. So if I have some package using EAPI=5 and it has this line in DEPENDS: icu? ( =dev-libs/icu-49:* ) Then that would mean it depends on icu-49 and the soname doesn't matter as it can be any version. Presumably the devs did their homework and figured out what their packages depend on, then put the right info in their ebuilds. (I fear this last might be a tall order, but hey, we're discussing syntax here, not human ability) Is this all starting to sound maybe just a little bit like some magic that will make @preserved-rebuild and revdep-rebuild redundant? We need those tools because portage does not know what so versions will work fine with what, and these sub-slots are supposed to give portage that info. Whoopee. ;-) Clear as mud now? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Confusing emerge output
Alan McKinnon wrote: On 03/02/2013 21:09, Dale wrote: Alan McKinnon wrote: emerge -e --keep-going @world shows output like this when a build fails: * One or more packages are either masked or have missing dependencies: * * =dev-libs/icu-49:0/50= pulled in by: * (x11-libs/qt-core-4.8.4-r1::gentoo, installed) I can't parse that. What kind of SLOT is 0/50= ? So far this has happened twice. The packages that failed prior are not important, what is important is that when the depgraph is *recalculated*, I get that error. It's always that specific atom for icu causing issues and it's always pulled in by qt-something Anyone know what that atom means and if it's a bug or not? This system is ~amd64 and portage is latest masked 2.2.0_alpha161. Active python is 2.7 LOL I'll give this a go, sort of. I get this for icu: root@fireball / # equery l -p icu * Searching for icu ... [IP-] [ ] dev-libs/icu-49.1.2:0 [-P-] [ ~] dev-libs/icu-50.1-r1:0/50.1 [-P-] [ ~] dev-libs/icu-50.1-r2:0/50.1 [-P-] [ ~] dev-libs/icu-50.1.1:0/50.1.1 root@fireball / # So, does it maybe want icu-50.* instead of the 49 that is installed? That would be equal to or greater than what you likely have. I might add, the 50 and above are keyworded. I took a stab at it but not sure what I hit. ;-) It's confusing, lemme see if I can describe it, using the URL that Michel O posted. Your eix shows 4 versions of icu. Everything there up to the / chars is normal and what you've been using for ages. The / is sub-slots, introduced in EAPI=5. icu-49 uses a lesser EAPI so it has no sub-slots. Each icu version =50 is in SLOT 0, and it will install .so files with the version after the /. So take my icu for example, it's version 50.1.1 and equery files reveals it installs: /usr/lib64/libicui18n.so.50.1.1 /usr/lib64/libicuio.so.50.1.1 /usr/lib64/libicule.so.50.1.1 Well whaddaya know, the .so version matches what eix claims (meaning the icu ebuild is correctly declaring what it will provide). That's one half of the story, the other half is with packages that DEPEND on icu. qt-core for example has this: icu? ( =dev-libs/icu-49:= ) Now what that means is qt-core DEPENDS on any version of icu 49, plus the following: (this is the bit that's gonna bake your noodle) If icu is re-emerged and that new version has a different .so version to what the current version provides, then qt-core will break at run-time. That's what the trailing = means, ie. qt-core depends on an icu that has an soname equal to the one it has right now. In my case that is 50.1.1. If I upgrade icu to a version with a different soname, then qt-core has to be rebuilt, and now portage knows that. There's another operator that can go where the = is and it's *. Which basically means any. So if I have some package using EAPI=5 and it has this line in DEPENDS: icu? ( =dev-libs/icu-49:* ) Then that would mean it depends on icu-49 and the soname doesn't matter as it can be any version. Presumably the devs did their homework and figured out what their packages depend on, then put the right info in their ebuilds. (I fear this last might be a tall order, but hey, we're discussing syntax here, not human ability) Is this all starting to sound maybe just a little bit like some magic that will make @preserved-rebuild and revdep-rebuild redundant? We need those tools because portage does not know what so versions will work fine with what, and these sub-slots are supposed to give portage that info. Whoopee. ;-) Clear as mud now? Dale scratches head H, that mud is pretty thick. May have to let that one sit for a bit to settle out. ^-^ So, portage is getting smarter about breakages then? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Confusing emerge output
On 04/02/2013 01:22, Dale wrote: Is this all starting to sound maybe just a little bit like some magic that will make @preserved-rebuild and revdep-rebuild redundant? We need those tools because portage does not know what so versions will work fine with what, and these sub-slots are supposed to give portage that info. Whoopee. ;-) Clear as mud now? Dale scratches head H, that mud is pretty thick. May have to let that one sit for a bit to settle out. ^-^ So, portage is getting smarter about breakages then? I'm a cynical old fart who's seen it all (more than once) before si I'm inclined to reply with yes, portage is getting smarter about breakages and append to that by fixing one problem - revdep-rebuild - and introducing a vast slew of new! shiny! improved! wonderful bugs that will make your life more miserable than revdep-rebuild ever could! :-) Now you go and have yourself a nice day, y'hear? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Confusing emerge output
Alan McKinnon wrote: I'm a cynical old fart who's seen it all (more than once) before si I'm inclined to reply with yes, portage is getting smarter about breakages and append to that by fixing one problem - revdep-rebuild - and introducing a vast slew of new! shiny! improved! wonderful bugs that will make your life more miserable than revdep-rebuild ever could! :-) Now you go and have yourself a nice day, y'hear? Oh crap. Now I see. Oh boy. This could be interesting, in a bad way. Is this breakage going to be like the udev thread that meant systems could not boot after the upgrade? One of those that sneaks up and kicks you in the back of the knees? Back to my hole. I may be there a while. :/ Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] confusing emerge output
Is this saying that it can't update django without pulling in an unstable eselect-python? yes, but you're already using an unstable version of django. -- Crístian Deives dos Santos Viana [aka CD1]
Re: [gentoo-user] confusing emerge output
On 25/08/09 Crístian Viana said: yes, but you're already using an unstable version of django. Not according to the Django developers. :) Anywho, I'll uninstall it for now. Mike signature.asc Description: Digital signature
Re: [gentoo-user] confusing emerge output
On Wednesday 23 April 2008, Allan Gottlieb wrote:
# emerge --verbose --ask --deep --update --newuse --tree world
gives just a few packages with dev-java/rhino the last one (first to
be merged).
But
# emerge --oneshot --ask rhino
Gives a bunch of packages with rhino the last one (last to build).
Could someone explain?
snip
[ebuild N] dev-java/rhino-1.5.5-r4 USE=doc -source 1,506 kB
snip
[ebuild N] dev-java/rhino-1.6.5 USE=doc -examples -source
See the difference? One is v1.5 the other is v1.6. The explanation is in
the full output of what rhino is and the openoffice ebuild:
[EMAIL PROTECTED] ~ $ eix rhino
* dev-java/rhino
Available versions:
(1.5) 1.5.5-r4
(1.6) 1.6.5
{doc elibc_FreeBSD examples source}
Homepage:http://www.mozilla.org/rhino/
Description: An open-source implementation of JavaScript
written in Java.
From openoffice-2.4.0.ebuild:
COMMON_DEPEND=
java? ( =dev-java/bsh-2.0_beta4
=dev-java/xalan-2.7
=dev-java/xalan-serializer-2.7
=dev-java/xerces-2.7
=dev-java/xml-commons-external-1.3*
=dev-db/hsqldb-1.8.0.9
=dev-java/rhino-1.5* )
There are two SLOTs for rhino - 1.5 and 1.6
OpenOffice explicitly DEPENDS on the 1.5 SLOT for rhino if you
have java in USE. You probably have that so a deep world emerge will
pull rhino-1.5* in.
You don't currently have rhino installed so when you issue emerge
rhino, portage will check for the latest one and install it. It just
so happens that in this case, the latest is not the same SLOT that OOo
wants.
--
Alan McKinnon
alan dot mckinnon at gmail dot com
--
gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] confusing emerge output
At Wed, 23 Apr 2008 09:33:05 +0200 Alan McKinnon [EMAIL PROTECTED] wrote:
On Wednesday 23 April 2008, Allan Gottlieb wrote:
# emerge --verbose --ask --deep --update --newuse --tree world
gives just a few packages with dev-java/rhino the last one (first to
be merged).
But
# emerge --oneshot --ask rhino
Gives a bunch of packages with rhino the last one (last to build).
Could someone explain?
snip
[ebuild N] dev-java/rhino-1.5.5-r4 USE=doc -source 1,506 kB
snip
[ebuild N] dev-java/rhino-1.6.5 USE=doc -examples -source
See the difference? One is v1.5 the other is v1.6. The explanation is in
the full output of what rhino is and the openoffice ebuild:
[EMAIL PROTECTED] ~ $ eix rhino
* dev-java/rhino
Available versions:
(1.5) 1.5.5-r4
(1.6) 1.6.5
{doc elibc_FreeBSD examples source}
Homepage:http://www.mozilla.org/rhino/
Description: An open-source implementation of JavaScript
written in Java.
From openoffice-2.4.0.ebuild:
COMMON_DEPEND=
java? ( =dev-java/bsh-2.0_beta4
=dev-java/xalan-2.7
=dev-java/xalan-serializer-2.7
=dev-java/xerces-2.7
=dev-java/xml-commons-external-1.3*
=dev-db/hsqldb-1.8.0.9
=dev-java/rhino-1.5* )
There are two SLOTs for rhino - 1.5 and 1.6
OpenOffice explicitly DEPENDS on the 1.5 SLOT for rhino if you
have java in USE. You probably have that so a deep world emerge will
pull rhino-1.5* in.
You don't currently have rhino installed so when you issue emerge
rhino, portage will check for the latest one and install it. It just
so happens that in this case, the latest is not the same SLOT that OOo
wants.
Crystal clear. Thanks for the lucid and careful explanation.
allan
--
gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] confusing emerge output
On Wednesday 23 April 2008, Allan Gottlieb wrote: You don't currently have rhino installed so when you issue emerge rhino, portage will check for the latest one and install it. It just so happens that in this case, the latest is not the same SLOT that OOo wants. Crystal clear. Thanks for the lucid and careful explanation. You're very welcome - emerge output can be ... um ... less than obvious at times. I figure that the three years of blood, sweat and tears I spent figuring it out isn't worth very much if it all stays in my head and never gets out. I'm also building up karma credits for the hundreds of questions I'll be unleashing on the paludis user community one fine day very soon :-) -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
