noob 2 noob help

[dRop]

I recently installed Gentoo Portage for Mac OS X, and I think the information I have compiled will be helpful to other new users, as well as answering some recent posts.

Useful links:
http://www.metadistribution.org/macos/The download and the two links to instructions are all you need to get running. Sounds like it has been down recently.
http://packages.gentoo.org/archs/ppc-macos/stable/ Partial list of packages that are stable under OS X (ppc-macos)

First, to make a key point clear, there are two different types of 'Gentoo' that run on Apple hardware. Gentoo PPC is a version of the Linux operating system modified running on apple hardware. It is an alternative to Apple's OS X operating system and you would have to reinstall over OS X to run it (unless you can dual boot?). Gentoo Mac OS X is the Portage package management system that runs under OS X. Like Fink and DarwinPorts it allows you to install many free UNIX programs that will run under Mac OS X.

Packages, Masks
To answer vivanno's post, There are *much* fewer packages that are stable under Gentoo Mac OS X than Gentoo PPC. Those that are not stable are listed as MASKED when running 'emerge --search some_prog' or have a '-' or '~' under the 'ppc-macos' column on the Gentoo Package site. I wish I knew how to list only the Unmasked packages. NocturnalCoffeeMan's list seemed like a summary of good packages until I found that all of those packages are masked and not even in testing on 'ppc-macos'.

Packages that work on the Gentoo PPC distribution can be installed. However, pindar comments that this might not work well.

Do you mean if it's stable to have ~ppc as your keyword while running portage under OS X? Quite a few of the packages without the ppc-macos keyword will compile, most won't.

One can unmask any package, but this is another topic entirely. If you are interested, check the last page of 'man emerge' and run 'emerge --info' to check your ACCEPT_KEYWORDS variable. The USE variable might also be involved. These are not system/shell variables (ie 'echo $USE' produces nothing), but something Portage specific. Don't know where or how to set them. Note that there are *two* ways a package can be masked, KEYWORDS and the '/usr/portage/profiles/package.mask' file.

Uninstalling
In response to Korr.ban's post, the wiki has another method. I haven't tried it, but probably will soon.

Gentoo Portage OS X looks sweet, but unless I can install some stable packages from it, it isn't very useful (to me). Can somebody please post a method to list only the ppc-macos unmasked packages, preferably in some useful categories? The ~20 packages listed here is not all that is currently available, but the wiki list is many months old.

Hope this helps somebody.

[pindar]

Very good post. Lemme just add some details:

1. If you are new to portage and want to just give it a try on OS X, your first stop should be the docs, both the official and the "unofficial" sites. Gentoo has excellent documentation that will make your life easier.

2. For the sake of convenience, let's say there are three categories of packages:
- packages with the "ppc-macos" keyword pure and simple. These should simply compile "out of the box," to quote this overused expression. They are not numerous at this point in time.
- packages with the "~ppc-macos" keyword. These are not considered quite mature and stable, but in my own experience, many of them work without a hitch, and the ~ in front of the keyword just means that not enough users have tested them and confirmed that they're stable. Occasionally, you may run into a package that won't compile, but so what? It won't break anything on your system.
- packages lacking the "ppc-macos" keyword. In a sense, these are the most important ones: since OS X is a particular brand of UNIX, in some regards not too unlike linux (please refrain from commenting this), many of them will compile and work. Every once in a while, it could be a good thing to just try one of those if it's of interest to you. Follow the instructions in the documentation to add the keyword to the file and just let portage do its magic. If the package compiles and works, send a bug report so the maintainers of said package can see whether the keyword should be added. So in a way, WE are responsible for adding more packages. Of course, those who can code are even more important: maybe you can contribute a patch to one of the packages that don't build or work properly on OS X.

3. Finally, one of the most important features of gentoo on OS X is collision protection, which means that emerging packages the "normal" way will not modify your OS X system files, so you should be on the safe side. Nevertheless, there is also a poblem with this feature: let's assume you see there's a new version on portage of something that is icluded with OS X -- let's say a utility like grep or find. You would like to see if it works and if it brings any advantages. If you do so with one of the other tools that bring UNIX ports to OS X (like fink or darwinports), they will install this utility into their own directory (/sw for fink, /opt for darwinports). If it doesn't work, you just remove it, and that takes care of that. portage is a bit more "imperialistic," it wants to control your entire system (which is a wonderful thing in itself). So at first, it will refuse to install the new utility because of collision protection. You can, however, force it to install by adding FEATURES="-collision-protect" to this emerge. That means that portage will overwrite your old "grep" binary, and if you weren't clever enough to make a copy somewhere in a safe place or have a backup of your entire system somehwere, there is no way to return to the former status. This is a problem that has been discussed here, and I think the developers are thinking about a solution.

So to sum up: please try some packages to make gentoo on OS X a lively place. The portage system is, IMHO, superior to fink (I never tried darwinports), and the more people try out packages, the more packages will be available!

[dRop]

Makes sense, if there are going to be a lot of stable packages somebody has to test them. I'll give it a shot with wtf, a very simple program that translates acronyms into plain text.

First step is to unmask the package. The idea behind masks is to allow you to only install stable packages by default, so to install testing grade packages, they must be unmasked. A package can be masked by being listed in the /usr/portage/profiles/package.mask file or by having keywords in its /usr/portage/<category>/<package>/<package>.ebuild file not match the the ACCEPT_KEYWORDS setting. The 2nd masking method is all I have experimented with so far, and there are a number of different ways to get around it.

1. ekeyword: This utility will change the keywords in an individual .ebuild file See the documentation to install and use this utility. The drawback occurs if the package you want to install has dependencies that are also masked.

2. Use the following command when emerging your package.
#ACCEPT_KEYWORDS="ppc" emerge <pkgname>
This will temporarily overide the allowable keywords setting so you can install this one package. May or may not have the drawback of #1.

3. The Big Hammer. Change the ACCEPT_KEYWORDS line in /etc/make.conf (NOT the 'ARCH' line). You will probably want to add 'ppc' (meaning any package stable on the linux port) or '~ppc-macos' (meaning packages that are in testing on the OS X port). 'ppc-macos' seems to remain in ACCEPT_KEYWORDS no matter what. This changes what ebuild file keywords portage will allow to be installed, so it works across all packages.

Now emerge the package.

Code: Select all

sudo emerge wtf

Everything compiles ok, but I have to find the install location and then alter some permissions. Digging back through the emerge output, I find wtf is in /usr/games/bin/. However, I cannot run it because I don't have the proper permissions. The 'emerge' output told me that my user must be a member of the games group, so I'll try doing that. Two ways of doing it, the OS X GUI way through Applications/Utilities/NetInfo Manager, or the command line (Tip grabbed from here) Note that /etc/group is only used in single-user mode.

Code: Select all

sudo dscl . merge /groups/games users Me

Still getting 'permission denied', so I check the actual file permissions.

Code: Select all

ls -al /usr/games/bin
total 8
drwxr-x---  3 root  games   102 27 Dec 10:26 .
drwxr-x---  3 root  games   102 27 Dec 10:26 ..
-rwxr-x---  1 root  wheel  1109 27 Dec 10:26 wtf

ok, all I need to to is change the group ownership on the 'wtf' file to 'games'

Code: Select all

sudo chgrp games /usr/games/bin/wtf

The acronyms database has a similar problem and solution

Code: Select all

ls -al /usr/share/games/wtf/        
total 16
drwxr-xr-x  3 root  wheel   102 27 Dec 10:26 .
drwxr-x---  3 root  games   102 27 Dec 10:26 ..
-rw-r-----  1 root  wheel  6070 27 Dec 10:26 acronyms

sudo chgrp games /usr/share/games/wtf/acronyms

Now the program can be run

Code: Select all

/usr/games/bin/wtf IMHO
IMHO: in my humble opinion

Question: Should those permissions have been set by portage, did I do something wrong or are these issues normal? I would hate to track down and modify all the files required for a really large package. Also, does portage clean up nicely after packages that fail to compile?

Now I guess the proper thing to do is report that the package works to bugzilla so it can be moved towards 'ppc-macos' testing and eventually stable.
umm, I think I did this right....

Here is a new one for the acronym database: IDHTFTS - I don't have time for this stuff Too bad the holidays are over and I won't have much more time to play around with portage, but it was interesting tinkering with it. I especially liked the installation guide, that is good documentation. I do have some coding skills from university, but it seems like a monster cliff of a learning curve to get into real world open source debugging. Are there any good tutorials/help out there on how to get started? Most of the stuff in the ppc stable branch *should* need only minor tweaking to work on ppc-macos, right? I guess I'm saying I might be able to fix simple stuff, but never again want to dig through 100s of lines of code to find subtle bugs or missing semi-colons.

[JoseJX]

You really shouldn't change your accept keywords from either ppc-macos or ~ppc-macos. Using ~ppc or ppc for your keywords will introduce subtle problems including ebuilds that don't work any longer because ppc-macos fixes aren't used (portage will think you are running a ppc-linux install).

The best way to test a package is to use ekeyword to keyword the package in your portage tree (it would be even better to do it in your portage overlay so your changes are preserved over a sync) ppc-macos. Once the package is marked ppc-macos, you will be able to just use the emerge command to try and install the package. Yes, this requires your to mark package dependencies ppc-macos, but it is really the best way to test things.

Fixes for the games issues are already in bugzilla, it's just a matter of getting them into portage. As for other packages, most problems are different than missing semi-colons etc. The packages already compile on other arches, problems tend to be related to the assumptions the authors make about the the underlying OS. For instance, if a package requires a kernel header that isn't in a standard location, the package won't compile.

Development for Gentoo for OSX, has slowed lately, the biggest problem lies with perl. We can't replace the perl binary distributed with OSX, but the Gentoo perl group won't support non Gentoo versions of perl. This isn't a good thing. :)

We're waiting for pathspec to be implemented in portage, but other solutions are in the works. Make a bug if you've found packages that can be installed with the system currently in place.

Thanks!