You might need to do an emerge rsync since the KDE 3.1 ebuild files were updated very recently with the ~sparc keyword. It's odd that gnome is masked for you though because I emerged gnome without any problems as long as I had ~sparc added to the ACCEPT_KEYWORDS variable in make.conf.

Okay,
I manged to figure out that an "emerge qt" worked, so I'm waiting for that to compile. Seems to be taking most of the day so far (and still going) So when thats done, I'll do an rsync and see whats going on as far as denpancies.

It looks as if I can do a emerge arts as well as the --pretend options shows it will install these:
Calculating dependencies ...done!
[ebuild N ] x11-libs/xft-2.0.1-r1
[ebuild N ] x11-libs/qt-3.1.0-r3
[ebuild N ] kde-base/kde-env-3-r2
[ebuild N ] kde-base/arts-1.1.0
:-/
What else the rest of kde is dependant on I haven't the slightest clue...

First, instead of trying to merge the entire KDE suite, try only the minimal install by issuing "emerge -p kdebase".

At minimum, that needs kdebase-3.1-r1 and kdelibs-3.1-r1. arts-1.1.0 plus any other dependencies it looks like already merge.

The kdebase is by far the most minimalistic you can get with KDE, and on my sun blade, it still took close to 18-24 hours to build, although this did have factored in the Qt-3.1.1 package (You'll probably get Qt-3.1.0, I had to tweak 3.1.1 a bit to compile it).

Even an "emerge kdebase" yields the same exact errors. Trying to "emerge kdelibs" shows that it can't satisfy the depenancies for alsa-driver, and trying to emerge alsa-driver just says it can't satsify the dependacies for itself. I looked at the ebuild for it and it doesn't look as if there is anything there that I don't already have....

Ahhh, well, I removed alsa from my USE variable in make.conf. emerge kdebase still failed complaining about dependancies failing for kdelibs, but doing an "emerge kdelibs" seems to have worked now. So I have begun the installation process for those now. I fear now that I may not have sound. Do you need Alsa for kde sounds to work?

If you built the modules for sparc audio, you should be able to get sound. I'm not sure if it works with arts in KDE, but the audio driver built with the kernel plays mp3s with XMMS and it works with ESD in gnome.

okay. yeah, I know the kernel sound modules work... they load happy and stuff on kernel boot. I was able to emerge arts as well, so maybe I'll be alright. Not exactly sure what alsa does. I kinda thought it was some sound deamon thing for kde.

Alsa is just an alternate set of soundcard drivers. Most x86 machines running linux migrated to alsa because OSS development had stopped. If you can get sound out of your sparc, you don't need to compile alsa.

Okay, this is getting crazy. So after waiting all night, I find that my system finally finished compiling the kdelibs source, and all its dependancies. So now, at the prompt I type:

# emerge kdebase

Only to get that darn message "all ebuild that could satisfy ~kde-base/kdelibs-3.1" have been masked (dependancy required by ~kde-base/kdebase-3.1 [ebuild])"

I already have kdelibs installed. I can't figure out for the life of me why its saying that. I've done an emerge sync, and I still have the same problem. doing an emerge -p kdelibs after the sync only shows it as already installed and up to date. Does anyone have any idea how I can tell what dependancy its failing on?

Basically, to hunt down dependencies, look at the kdebase ebuild, look at the DEPEND= section. For every package you see there, find the ebuild of the latest version of that package and look at it. Does it have "~sparc" or "sparc" in it's keywords? Is it masked in the package.mask file?

Do this for each package, eventually, you should have determined which packages are blocking you. I'm sure there is an easier way, perhaps by using qpkg, and maybe a future addition to portage wouldn't die when it encounters a masked package, but rather still shows the list and shows what is masked.

If I did an emerge -s kdebase, it would show that it could install kdebase-3.1

If I did an emerge -s kdelibs, it showed that it would only install kdelibs-3.1_rc6. I checked in the kdelibs ebuild directory and verfied that the kdelibs-3.1.ebuild existed, and it had the ~sparc keyword. I just couldn't get it to install. 3.1 for the life of me. I ended up doing the following to reslove it.

# ACCEPT_KEYWORDS='x86' emerge -p kde

which showed all the dependancies. I then made sure each of those had a ~sparc entry in it (which it did) and then ran the command without the pretend option to start the build. Its still going. I have no idea why the lib version problem was happening.

Actually, kdebase-3.1-r1 and kdelibs-3.1-r1 are out, I would merge those instead of the original 3.1's. Not sure what the bugfix is that required -r1 packages, but they appeared about a day after the originals, so they musta fixed something.

So I'd say they exist....Might want to rsync your tree just to double check. Although, with there being a kdelibs-3.1-r2 now, I'd expect a kdebase-3.1-r2 as well, so it looks like I'll be recompiling everything shortly as well.

It's not a bug, it's just KDE has a long list of dependencies. If even one of these dependencies are masked, the whole thing dies and tells you as such, this is why I'd like --pretend (-p) to still output the ebuilds in the colored format, but create a new letter field for masked ebuilds, something like this:

Quote:

[ebuild MU ] kde-base/kdelibs-3.1-r1 [3.1-r0][Masked]

I think that would be more viable output regarding masked packages. You'll just have to trace the dependency tree, much I will have to do when I decide to rebuild kdelibs, and kdebase again.

The thing that is wierd about the whole dependancy though is that ebuild says it can't resolve the dependancies for kdelibs-3.1 when I try to install kdebase. So when I do a --pretend on the actual kdelibs-3.1.ebuild file (or r1 for that matter) it says it will install fine, and can resolve all dependancies. Thats whats confusing me.

I ran an emerge -u system and world last night. That ended up upgrading my version of X. After a reboot this morning, I can no longer get into X, as my config is broken, and I ran XFree86 -configure and the initial file works fine, but I can't get it to go to any resultion highter than 640-480 But that's off topic of this thread... Anway

In an attempt to see if another version of X was out, I noticed that a new version of portage was released, upgrading portage seemed to have fixed my kde emerge problems, as doing an emerge -p kde finally show all the proper packings that it would install.