OddFox
Apprentice
Joined: 28 Nov 2002
Posts: 270
Location: Spokane, WA
|
 Posted: Sat May 28, 2005 8:38 am Post subject: Muine Guide for AMD64 -- Been Made Yet? |
 |
|
I whipped up a guide just a little bit ago on how to get Muine installed on an AMD64 box running the unstable branch of portage, did a search of the Gentoo on AMD64 forums and didn't find much in the way of a guide for this process, saw some success stories, and a post or two recommending a path or two that didn't really sit well with me, personally. I already put it up at my blog at my site and thought hey, why not share it with the Gentoo forums as well? So here it is in all it's glory, intro and all (Straight from my blog), and please, feel free to flame me if there's something stupid going on in my directions.
So a couple of weeks ago I decided that I had seen enough screenshots of how awesome the Muine user interface looks and how it seems to be, in general, quite an interesting music player. Not only that, but it's based on Mono, which to most people doesn't really mean a whole lot of anything, but to me, it means a chance to evaluate even more of what can be done with the development tools I am in the process of learning about, and to see just how much can be done when Mono is, really, still in it's infancy (When it gets full support for AMD64, which seems to be very very close, and also fully supports Windows.Forms, I'll probably change my idea about it). Remember, this project was only begun in 2001, and already has a nice assortment of applications built upon it that have truly innovated in their approaches to the problems they are meant to solve. Case in point -- the Beagle search tool, and my new favorite, Muine, which has an intuitive interface that I have not ever seen in any other application thus far. Let us not forget, either, the F-Spot image management application, which I have yet to try out, but it already looks like a great program, with the absence of PixiePlus development (If anyone can let me know where PixiePlus development went, by all means, I am quite eager to locate it). F-Spot has received numerous reviews which praise it, and it even won a spot in the shipping version of SuSE 9.3.
Anyways, enough about Mono and C# projects, down to the dirty business of Muine on my AMD64 in Gentoo. Now, anyone who's been in one of these environments knows that Gentoo, at this time, has hard-masked many Mono packages, many packages for gtk-sharp, etc, all of which are dependencies for pretty much any of these applications previously mentioned. Imagine my woe at finding that even though there are so many new versions of these packages in the portage tree, they're not available for usage because they're not deemed stable enough (Which, personally, I don't care for, I run the unstable branch for a reason, but I digress back to my main purpose of the post). This is indeed quite true, they are not stable enough, as far as I'm concerned. At least, not the packages that were available when the whole masking process was begun. Things have come a long way, there are newer versions of all the problem packages and they installed very smoothly when I went through the trouble of unmasking the packages, using a local repository to address any issues with ebuilds needing modification, and all that good stuff. Here's a quick overview of how to get Muine installed on your AMD64 if you run in the unstable branch (I make no guarantee or claim of these steps working on your stable branch system, nor unstable, for that matter, computers are weird in that they don't always act the same).
Firstly, the contents of my /etc/portage/package.unmask file, irrelevant entries removed, of course:
| Quote: |
>=dev-dotnet/gtk-sharp-1.0.8
>=media-sound/muine-0.8.2
>=dev-dotnet/gconf-sharp-2.5.5
>=dev-dotnet/art-sharp-2.5.5
>=dev-dotnet/gnome-sharp-2.5.5
>=dev-dotnet/glade-sharp-2.5.5
>=dev-dotnet/gnomevfs-sharp-2.5.5
|
Second, I must stress that for pretty much all of these packages, you will need to enable a local portage overlay, and for the sake of keeping this post simple, I will link to a Gentoo-Wiki article which does a fantastic job of explaining that process. It is located here. All you need to find from there is how to setup the portage overlay and edit your make.conf, you don't have to do anything with those additional software repositories which I found useless for myself, personally.
Next, we copy the latest version of these packages over to our new local portage overlay, where I put in /usr/local/portage, the sane default. If you'd like, you can download the tarball I've made, otherwise, you should only have to do this with the muine ebuild itself. This is not that big of a deal because once you add those entries to your /etc/portage/package.unmask file, any attempt to emerge those packages will notify you, hey, buddy, there's a missing keyword! The solution to that is to find the offending ebuild in /usr/portage/, note which category the ebuild is in, and then mkdir /usr/local/portage/cat-egory. Most of the time for this, it will be dev-dotnet/packagename so you shouldn't need to do too many mkdir operations. 
After you've got the ebuilds copied over, you'll edit the files with your favorite text editor and locate a line similar to the following line in each ebuild, around the beginning of the file:
| Quote: |
KEYWORDS="~x86 ~ppc ~ppc"
|
You'll want to change it to also have ~amd64, meaning you're designating that build as being fit for the unstable branch of the amd64 port. This is important to note because even if you do this, you still have to be in the unstable branch. You're more than welcome to add simply amd64 without the tilde, but I do not recommend this simply because I have no way to tell if it's safe. So here's the updated lines:
| Quote: |
KEYWORDS="~x86 ~ppc ~ppc ~amd64"
or
KEYWORDS="~x86 ~ppc ~ppc amd64"
|
After you get that done for each package, it should be smooth sailing until you reach the point where you emerge the muine package itself. Gentoo's AMD64 maintainers have decided to mask the mono USE flag, much the same that the mmx, 3dnow, and sse flags are disabled by default in AMD64. For their explaination, a simple cat /usr/portage/profiles/default-linux/amd64/use.mask | grep mono shows the following on my computer (Before my modification):
| Quote: |
# Optional mono support will never work until we have a stable mono compiler
# Will work with mono 1.1.6, waiting on that to be stabilised.
mono
|
This is all well and good for the time it was put there but it doesn't seem to be applicable anymore, especially with the mono version in portage reaching 1.1.8.3 at the time of this latest update. Should be entirely safe to comment that line and get down to business.
Now, the reason why muine's ebuild complains is that your installation of sys-apps/dbus will NOT have been installed with the mono USE flag (Which I have in my /etc/make.conf file). At this point you have a couple of options as to how to enable the mono USE flag. Either put it in /etc/make.conf or edit your /etc/portage/package.keywords file to include the following:
| Quote: |
>=sys-apps/dbus-0.23.4 mono
|
But you're not done once you do that, as I stated, the mono USE flag is disabled by default on AMD64. The solution I have found thus far is to edit your /usr/portage/profiles/default-linux/amd64/use.mask file and comment out the line which has mono on it. It should read like this once you're done:
| Quote: |
# Optional mono support will never work until we have a stable mono compiler
# Will work with mono 1.1.6, waiting on that to be stabilised.
# mono
|
NOTE THAT THESE CHANGES WILL BE UNDONE WHEN YOU RUN YOUR NEXT emerge --sync. PLEASE BE AWARE THAT YOU WILL NEED TO EDIT YOUR USE.MASK FILE AFTER ANY SYNCS TO COMMENT OUT THE MONO LINE ONCE AGAIN.
After this, re-merge your sys-apps/dbus, making sure that it has the mono flag enabled. You can check this before doing the merge with a simple emerge -pv --deep --newuse dbus:
| Quote: |
[ebuild R ] sys-apps/dbus-0.23.4 +X -debug +gtk +mono +python +qt +xml2 0 kB
|
After verifying that the mono flag is enabled and merging dbus again, you should be able to compile muine just fine. The problem that I ran into, however, was that I would always get this message when trying to start muine, and no window would appear:
| Quote: |
oddfox@forest ~ $ muine
The program 'muine' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
(Details: serial 329 error_code 2 request_code 25 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
|
Needless to say, I was quite disappointed that after all this time and effort, muine refused to run even though it compiled cleanly, which can be the case at times, a program compiling fine isn't the same as a program running fine, and I do overclock my system, so maybe something was b0rked. Anyways, I took the rest of the night off and hit the hay. The next day I try to run the program again after emerging dbus and muine again. Same problem when starting the program, so I says what the hell, this is ludicrous, I'm going to see if that --sync command will help me at all. Surprise surprise, that's exactly what the doctor ordered. To launch muine after all this effort, you must run it with the --sync option, that seems to prevent it from complaining. If you have any other error messages pop up or for some reason the program won't run for you, please let me know so I can see if maybe I can't find out what's causing the message.
This little guide here could do with some touch-ups, I think, but I'll leave that for another day, as I have covered pretty much everything. For proof of all this, here you go. Good luck!
UPDATE: I tweaked the post to fix a syntax error I had missed and also noted that the process has changed, no longer should one have to copy/edit all involved ebuilds, when I just did this on my system I had a few less steps to take. Also, I don't have the problem with having to run muine with the --sync option lest the program crash itself, everything seems to be working excellently.
_________________
Now the rainy season reminds me of Maria
The way she danced, the color of her hair
Now I'm locked inside a stall at the cantina
Eating the bananas and the cocaine off the mirror
Looking for a ticket to take me away from here |
|
Gentoo on AMD64
