Compiling help

[pejsaboy]

Those blocked pacakges should have shown when you did emerge -pe world the first time.

You may have to go through and start "emerge -C"'ing the blockers one by one. KDE is modular now. The old version, however, divides things differently into package names. Go through and remove anything that has KDE in the name that is from the older version of KDE.

You'll have to work on the command line for a bit, which isn't really a big handicap... if you need browser access in the mantime, do it all through knoppix.

So, does that mean I can log in and take over emerge -C'ing from knoppix, or just to use knoppix for browsing so that I'm not being tainted by the use of windows? It shouldn't take too long to unmerge the packages *hopes like hell*... but having the internet to keep me occupied would be nice.

 

[MRD]

You can start up knoppix, mount your root gentoo partition and boot if you have one, as well as usr, var, lib, or any others you use a separate partition for. Then mount proc and dev, chroot, env-update, source /etc/profile, and you're essentially in a terminal that functions like your gentoo box and you can do emerges from there. You can also then run a browser window that will be running under knoppix (you won't have bookmarks and the like from gentoo).

Chrooting instructions are the same as for installing (i.e. what you'd find in the gentoo manual.)

I can't give you exact commands without knowing your partition layout.

 

[pejsaboy]

hehee... sounds a little over my head still at this point.. i'll just work at it as is until its fixed.

 

[telexen]

hehee... sounds a little over my head still at this point.. i'll just work at it as is until its fixed.

Actually it's almost the same thing you did to install Gentoo if you used the Handbook.

Did you previously install KDE via individual packages (such as emerging 'kdesktop' or 'konqueror', or even 'kde-meta')? Are you now trying to use the kde-base/kde monolithic package?

 

[MRD]

It might be that KDE transitioned from monolithic to modular in a version change?

 

[MRD]

It's not that hard to chroot btw, but another solution (which I'd consider harder but you might not) if you want to browse while you build is to simply emerge fluxbox or icewm. It's tiny and takes about 2 minutes. Set that as your window manager until you get kde rebuilt (change the XSESSION variable in /etc/rc.conf).

 

[splat]

i thought there was a way to "emerge -C kde-meta" (or kde-base, whatever you used to install first) then somehow run emerge to remove the dependencies.

at any rate, i was quickly browsing thru the documentation and found this: http://www.gentoo.org/doc/en/kde-split-ebuilds.xml

 

[MRD]

You may be right. I always emerge kde so I have it on my system, but I never use it, I'm a Gnome user normally, with a bit of fluxbox or icewm on slower systems.

 

[telexen]

i thought there was a way to "emerge -C kde-meta" (or kde-base, whatever you used to install first) then somehow run emerge to remove the dependencies.

at any rate, i was quickly browsing thru the documentation and found this: http://www.gentoo.org/doc/en/kde-split-ebuilds.xml

I think the only problem you would run into is whatever packages were added to the world file...they won't be removed by 'emerge --depclean'...

Like MRD said I would emerge something like fluxbox so you have a GUI quickly, then maybe you can go through your world file (/var/lib/portage/world) and remove all KDE packages from the list so emerge --depclean will clean KDE up easily for you.

 

[pejsaboy]

I've still got enlightenment working, so I'll work on editing the kde packages from the world file next chance I get. Thanks for the help so far!

 

[splat]

I think the only problem you would run into is whatever packages were added to the world file...they won't be removed by 'emerge --depclean'...

Like MRD said I would emerge something like fluxbox so you have a GUI quickly, then maybe you can go through your world file (/var/lib/portage/world) and remove all KDE packages from the list so emerge --depclean will clean KDE up easily for you.

ahhhh. i had no idea it wouldn't remove packages in the world file. if you emerge with --oneshot so that the files don't get added to the world file, then 'emerge world' won't grab those packages, right?

 

[telexen]

ahhhh. i had no idea it wouldn't remove packages in the world file. if you emerge with --oneshot so that the files don't get added to the world file, then 'emerge world' won't grab those packages, right?

Right. The only way emerging 'world' will pick up a package is if it's in the world file or a dependency of another package in the world file.

 

[Captain Newbie]

After doing that, I'd also do an "emerge -e world" and rebuild everything to the correct chost values and using the same compiler. Switching gcc versions from 3 to 4 without a full reinstall tends to break a lot of stuff.

emerge -e world is _strongly_ recommended after changing CHOST.

 

[MRD]

Changing one system from i486 to i686 AND changing compiler versions from 3.x to 4.x is a recipe for bugginess.

 

[splat]

i think that when you change gcc versions, you need to recompile gcc using the new version and recompile binutils. I know when i upgraded from 4.1.1 to 4.1.2, which isn't supposed to create any errors due to the minor version change, I started running in to odd errors that were only resolved by re-emergeing gcc and binutils.

so, i'd suggest "emerge gcc binutils" then "emerge -e world"

 

[MRD]

If I change from gcc 3.x to 4.x, I do a full reinstall. IMO it's not worth screwing around with.

I keep no important files on my workstations, all data is on my file server. Workstations can be formatted and reinstalled in a few hours.

I also use the "buildpkg" option in gentoo, so I build all the backages and save them as binaries on one computer, and then I can install them without building them on the others with the -k option. This requires a shared portage directory though, which I do via NFS on my file server, which does a portage sync every day automatically on the cron.

I also realized once that I had built a system based on an i386 chost... not sure how I managed that, I guess I wasn't paying attention when I set up make.conf. I just wiped the drive and redid it all with i686.

Interesting that there is still nothing past i686 for chosts. That instruction set came out with the Pentium Pro in 1995.

 

[telexen]

I'm picky, but if I'm going to upgrade gcc I always emerge it, then re-emerge binutils, glibc, and finally gcc again, then emerge -e world.

I also use the "buildpkg" option in gentoo, so I build all the backages and save them as binaries on one computer, and then I can install them without building them on the others with the -k option. This requires a shared portage directory though, which I do via NFS on my file server, which does a portage sync every day automatically on the cron.

Ditto. A shared portage dir makes everything so easy with Gentoo.

 

[MRD]

I used to keep separate portage directories, and then I tried to create a shared portage directory via samba, but that didn't work well at all because the permissions aren't supported correctly with CIFS. So I gave up for a while, then realized that NFS would work perfectly for this.

I can't imagine going back. I used to manually emerge --sync before each emerge. Now I never have to emerge --sync and I always have an up to date portage tree.

Plus download times are much better. I have 9 comps running Gentoo. If you download once into the shared portage directory, it just sits there in /usr/portage/distfiles, and the next comp to use it doesn't have to download it (and I may even use the binary, depending on useflags and architectures and such).

It would be nice to have all the same useflags and architectures on all PC's, but that's probably a pipe dream. I still have to compile sometimes... I optimize with SSE useflags for my Athlon XP's, which matters a lot for media stuff, but makes apps not run on the tbirds.

 

[telexen]

I used to keep separate portage directories, and then I tried to create a shared portage directory via samba, but that didn't work well at all because the permissions aren't supported correctly with CIFS. So I gave up for a while, then realized that NFS would work perfectly for this.

I can't imagine going back. I used to manually emerge --sync before each emerge. Now I never have to emerge --sync and I always have an up to date portage tree.

Plus download times are much better. I have 9 comps running Gentoo. If you download once into the shared portage directory, it just sits there in /usr/portage/distfiles, and the next comp to use it doesn't have to download it (and I may even use the binary, depending on useflags and architectures and such).

It would be nice to have all the same useflags and architectures on all PC's, but that's probably a pipe dream. I still have to compile sometimes... I optimize with SSE useflags for my Athlon XP's, which matters a lot for media stuff, but makes apps not run on the tbirds.

I know we're getting off topic here, but maybe you could try setting your make.conf to something like this to split between microarchs:

CFLAGS="-march=${MARCH} ${OPTS}"
MARCH="athlon-xp ...or...athlon-tbird"
OPTS="your other optimizations"

PKGDIR="/usr/portage/packages/${MARCH}"

I don't know if that would really work since I'm not that familiar with python...but from things I've seen people do in their make.conf, especially with USE flags, I don't see why not.

 

[splat]

i'm not sure if you'd be able to do that with your make.conf, i think you'd have to do something more along the lines of cross compiling: http://www.gentoo.org/proj/en/base/embedded/cross-development.xml