Alan McKinnon wrote:
> I'm not sure what to make of this. portage lists the packages
> correctly and has the SLOTs correct, but emerge seems to be launched
> incorrectly. It's all very odd, and looks like bug-report material. To
> be useful you are going to need data. Could you quickpkg the current
> and previous versions of both SLOTs? That will make it easy to upgrade
> and downgrade packages, then run emerge world over and over to see
> what it does without it taking 40 minutes each time.
Well, here is this:
[-P-] [ ] sys-apps/portage-2.1.11.63:0
[-P-] [ ] sys-apps/portage-2.2.0_alpha173:0
[IP-] [ ] sys-apps/portage-2.2.0_alpha174:0
This is the portage update info. I use genlop -t to do this. I know
there is a better way but can't remember the command. lol I think it
was one of the q thingys.
Fri Apr 5 12:49:29 2013 >>> sys-apps/portage-2.2.0_alpha171
merge time: 27 seconds.
Sat Apr 6 11:00:10 2013 >>> sys-apps/portage-2.2.0_alpha171
merge time: 26 seconds.
Mon Apr 15 08:33:49 2013 >>> sys-apps/portage-2.2.0_alpha173
merge time: 31 seconds.
Mon May 6 22:36:15 2013 >>> sys-apps/portage-2.2.0_alpha174
merge time: 30 seconds.
Based on that, I would say it started about the time *173 hit. I can't
go back to the *171 since it is no longer in the tree.
I'm not sure I know enough about debugging to help much but it sure is
weird. Should have known something weird like this would hit me. :/
I'm sort of pretty active on this thing right now since I do some
volunteer mod work on a site. I'd rather not get myself to a spot where
my rig aini't working. I'm not even doing upgrades like I used to.
Well, not as often anyway. I just have to plan stuff to make sure I'm
up and running.
I checked for roach reports and didn't see this reported anywhere. I
wonder if a USE flag is triggering this? This is interesting:
root@fireball / # emerge -pv =sys-devel/gcc-4.4.7 =sys-devel/gcc-4.5.4
=sys-devel/gcc-4.6.3
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] sys-devel/gcc-4.6.3:4.6 USE="gtk mudflap (multilib)
nls nptl openmp (-altivec) -cxx* -doc (-fixed-point) -fortran* -gcj
-graphite (-hardened) (-libssp) -multislot -nopie -nossp -objc -objc++
-objc-gc {-test} -vanilla" 24 kB
[ebuild R ] sys-devel/gcc-4.4.7:4.4 USE="gtk mudflap (multilib)
nls nptl openmp (-altivec) -cxx -doc (-fixed-point) -fortran -gcj
(-hardened) (-libssp) -multislot -nopie -nossp -objc -objc++ -objc-gc
{-test} -vanilla (-graphite%)" 0 kB
[ebuild R ] sys-devel/gcc-4.5.4:4.5 USE="gtk mudflap (multilib)
nls nptl openmp (-altivec) -cxx -doc (-fixed-point) -fortran -gcj
(-hardened) (-libssp) -lto -multislot -nopie -nossp -objc -objc++
-objc-gc {-test} -vanilla" 0 kB
Total: 3 packages (3 reinstalls), Size of downloads: 24 kB
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
sys-devel/gcc:4.6
(sys-devel/gcc-4.6.3::gentoo, ebuild scheduled for merge) pulled in by
(no parents that aren't satisfied by other packages in this slot)
(sys-devel/gcc-4.6.3::gentoo, installed) pulled in by
sys-devel/gcc[fortran,openmp?] required by
(virtual/fortran-0::gentoo, installed)
>=sys-devel/gcc-4.2[cxx] required by
(sci-geosciences/googleearth-6.2.2.6613::gentoo, installed)
!!! Enabling --newuse and --update might solve this conflict.
!!! If not, it might help emerge to give a more specific suggestion.
root@fireball / #
I may need to make sense of this now. May not be the problem but
still. I don't have anything related to gcc in package.use either. I'm
not sure about the USE flag being changed on two but not the other.
When I logoff as mod, I'm going to try to recompile that older version.
Thoughts? Could that be the cause?
Dale
:-) :-)
--
I am only responsible for what I said ... Not for what you understood or how
you interpreted my words!
