So here’s the deal, I upgraded to F9, and things are just kind of funky right now in XFCE. Wanted to go back and check out the new stuff in Gnome anyway, so this was an opportunity to do so.

Unfortunately, Gnome was totally instable for me. Going through the menus would cause X to crash.. and note, no fancy desktop graphics going on or anything.

Now, in the past, I’ve had some degree of luck using smart‘s “reinstall” option to fix things like this.

I also should note that I don’t have the entire “GNOME Desktop Environment” group installed, nor do I want it.

Finally, note that, for some reason, instead of using an “.$ARCH” extension, smart breaks architectures down using “@$ARCH”.

So basically, I want to install a bunch of vaguely gnome-esque packages, but not one at a time, sequentially, lest I run into dependency issues which would lead to the possiblity of downloading multiple packages over and over again. Also, just an “rpm -qa” piped to smart won’t work either due to the $ARCH grouping silliness.

Came up with this crufty bit which seems to do the trick.

First I created a random foo directory and changed dir to there.

Then:

for i in `rpm -qa --queryformat "%{name}\n"|grep "gnome-"`; do touch $i; done ; yes|smart reinstall `echo *`


Although I am sure there are way more efficient ways to do it, this seems to work amazingly well.

Well, I never used desktop effects a whole lot in Fedora 7, but when I did, they worked nearly flawlessly. I decided to check ‘em out again in F8, though, and, well, they were bustificated again.

Well, to be more accurate — if i run compiz-manager, everything comes up just roses. However, if I try to use gnome-compiz-preferences to enable them, i get no desktop decorations.

Running the gnome prefs app in a window, I started noticing messages akin to

[corey@ramen compiz]$ gnome-compiz-preferences
** (gnome-compiz-preferences:12673): WARNING **: plugin decoration isn't installed

** (gnome-compiz-preferences:12673): WARNING **: plugin place isn't installed

** (gnome-compiz-preferences:12673): WARNING **: plugin scale isn't installed

** (gnome-compiz-preferences:12673): WARNING **: plugin switcher isn't installed

** (gnome-compiz-preferences:12673): WARNING **: plugin water isn't installed

** (gnome-compiz-preferences:12673): CRITICAL **: gcm_gl_plugin_get_option: assertion `self != NULL' failed

** (gnome-compiz-preferences:12673): CRITICAL **: gcm_gl_option_set_string: assertion `self != NULL' failed

** (gnome-compiz-preferences:12673): WARNING **: plugin decoration isn't installed

** (gnome-compiz-preferences:12673): WARNING **: plugin png isn't installed

** (gnome-compiz-preferences:12673): WARNING **: plugin svg isn't installed

** (gnome-compiz-preferences:12673): WARNING **: plugin annotate isn't installed

** (gnome-compiz-preferences:12673): WARNING **: plugin scale isn't installed

** (gnome-compiz-preferences:12673): WARNING **: plugin cube isn't installed

** (gnome-compiz-preferences:12673): WARNING **: plugin decoration isn't installed

I thought that was interesting. Looking for the location of, say, crashhandler, I found it:

/usr/lib64/compiz/libcrashhandler.so

I found this even more interesting. Testing a theory, I created a directory (noting it didn’t exist), /usr/lib/compiz. From within this directory, I ran the following command:

for i in `ls /usr/lib64/compiz/*`; do ln -s $i `basename $i`; done

At this point, I re-ran gnome-compiz-preferences, and voila, I had window decorations.

Note that some things still seem busted – for example, I know I have wobbly windows enabled, and I am not seeing those. However, other indications let me know that compiz is indeed running, not least of all, ps:

13143 pts/1 S 0:00 /usr/bin/compiz-tray-icon
13190 ? S 0:03 /usr/bin/python /usr/bin/ccsm
13290 pts/1 S 0:00 /usr/bin/gtk-window-decorator --replace
13322 pts/1 S 0:03 /usr/bin/compiz --indirect-rendering --replace gconf


Basically, however, what we now know is that there’s a bug in gnome-compiz-preferences that isn’t taking into account the /lib vs. /lib64 differentiation on x86_64/multilib systems. I’ll bug it if it hasn’t been done already.

Also note that the full bash command above isn’t necessary — one can just as easily symlink /usr/lib64/compiz to /usr/lib/compiz


[root@ramen ~]# cd /usr/lib
[root@ramen lib]# ln -s /usr/lib64/compiz compiz

Update: bz #388511. Also, I realised although I did have the wobbly windows plugin loaded, I missed it in the most obvious place — in the gnome-compiz-preferences UI itself. Seems just fine now.

I’m usually kind of hesitant to upgrade Fedora releases immediately after the come out… I like to make sure most of the bugs are ironed out so that I don’t hose something. However, I simply couldn’t resist this time, and over a span of 24 hours, I upgraded both my home-built desktop and T43 laptop from F7 to F8.

Now, being an Xfce user (for the time being anyway), I don’t get to experience a lot of the bells and whistles arriving in F8, such as pulseaudio and the neato changing background stuff that Máirín worked on. However, I was interested in doing the install from a pure usability standpoint. A linux user since 1996, a jack of all trades but master of none, I am always interested to see how thing improve/regress from the perspective of someone who’s neither n00b nor r00t..

As always, there is good, bad and ugly. Generally speaking, the upgrade went quite well — albeit i took a path slightly less traveled, opting to take a stab at it with smart, versus yum. But anyway, I did run into the same --noscripts (resolvable) issue as dgoodwin, as well as some other packages — so that’s something that definitely should be added to the FedoraFaq wiki. Also, it seems that the f8 kernel gets installed, but never makes its way into grub.conf — odd, and I now know I’m not the only one to have seen this. Anyway uninstalling it and reinstalling seems to be the easiest fix.

Generally speaking though, it didn’t seem like I had a lot of problems… home system upgraded like a champ… then hit the laptop… rebooted…

… and then I was stymied and still am. After rebooting, my monitor begins to display a message about the frequencies being out of range. WTF? Worse still, it seems that to get any working resolutions at all on my laptop display that are above 1024×768, i have no options other than widescreen-esque ratios. Attempting to fix these issues with system-config-display was a futile effort for two reasons — one, because every time I tried to change the monitor setting, it would say it was saved, but actually wouldn’t… and then when I jerry-rigged the xorg.conf to give me the resolution i wanted, X still wouldn’t cooperate — either causing my monitor to display the frequency error again, or popping up in the right resolution — say, 1280×1024 — for a brief moment before resetting to something odd like 1280×768.

I still don’t know what is/was causing it, but later on I noticed that I didn’t get it in GNOME, or KDE… only in Xfce — but I don’t know WTF the window manager would have to do with changing the resolution.

Anyway, after seeing that, I went kamikaze on my dot-setting directories, figuring I could just wipe everything out and get it to work — and that did indeed do the trick, albeit at the expense of some of my desktop settings. That said, I’m still not at all convinced that things are quite right with my Xserver.

Oh, and due in part to all of this — and in part to all the cool new GNOME stuff — i considered switching back to GNOME, if only for a time, as an alternative to a busted resolution. However, trying to make my first changes or two and getting segfaults all over the place with gnome-appearance-properties, i changed my mind pretty quickly. Maybe this will get cleared up (out there|on my box) eventually and I can reevaluate.

Generally speaking, though, I was pretty happy with the install experience — I just for the life of me can’t figure out what the hell is/was going wrong on the X end of things.

Update: Well, I noticed that livna once again (and most conveniently) has fglrx drivers. I know there had been issues in the past few months, and I am not sure when they finally fixed that — but in any case, i installed them, and my issue seems to have resolved itself. The plot thickens…

So, I dunno if this happened to anyone else, but after grabbing my latest batch of updates from Fedora, which included rss-glx and rss-glx-screensaver, I noticed that my screensaver no longer kicked in. Looking closer, it indeed was one of the rss-glx screensavers, Lattice. I also noticed that downgrading did in turn return the screensavers to me.

Now, according to the Changelog I found, they renamed the rss-glx screensavers, appending such text to each filename, i.e., rss-glx-lattice. Well, I figured that this was dumb, I was surprised that this hadn’t been taken into account w/ the hacks file. Such thoughts were immediately followed by the realisation that no, it was probably something on my end.

After much examination and having nearly entered a bug, I figured it out.

Long story short: my ~/.xscreensaver was still pointing to the old name. I thought about manually editing the file, but decided that it was easier just to wipe the thing out and let it be regenerated.

So you out there, if you come across this weblog entry, trying to get your rss-glx screensavers back, in your Fedora 7 install…just wipe out your local config and be done with it. I guess you probably could edit the file too and s/lattice/rss-glx-lattice — but you’d probably have to do it for all your rss-glx screensavers. Not worth it.

Well, the love affair with KDE was torrid, full of passion, but it was short-lived, and in the end, wasn’t meant to be.

I liked it… and still kind of do… but it was like, I dunno… too much whipped cream on your pumpkin pie? Too rich an environment, Too many menu items, even when I slimmed stuff down, just… “Too.”

Also, I got annoyed at how often I would end up inadvertently closing an applet by right-clicking too fast or something, and having KDE think I wanted to close it. Little thing I guess, but it started to rub at me.

So anyway, I decided to check out Xfce, and I think I really have found what I’m looking for (cue Bono). Zippy as hell and has the right balance of customisation without all the confusion. After the initial hiccups of trying to get functional menus — although I still haven’t found a way to make them autopopulate and I don’t think such a feature yet exists — I was up and running.

There are still a few glitches. I run several Gnome applets and the occasional KDE applet still, and the KDE applets will, on occasion, end up in the corner of my screen versus the system tray when I restart the a session. Oh, and I had to build xfce4-smartpm-plugin from scratch since it doesn’t (yet?) seem to be available in Fedora. Also, the menu editor won’t allow me to move a launcher outside its current grouping to another. For example, I’ve got a few things that are, to me anyway, miscategorized. I can’t move something from, say, “Accessories” to “System”. without just rewriting an entry from scratch.

Overall, however, I think Xfce is the way to go, especially if you want something that’s lightweight. My system isn’t particularly slow at all, but Xfce feels a lot more responsive; I can only imagine the improvement on a slower system. In fact, I know it’s better — my first stab at Xfce was on a vmware image, now that I think about it, a decision which was specifically made due to the nature of the beast.

A few weeks back, I installed Amarok on my home desktop, and thought it was a pretty nifty program — this, despite being a “dreaded KDE application”. Maybe it planted a seed in my head.

So today, something — I can’t remember what — made me decide to check out KDE again. Last time I used it was about 3 years ago, when I ran it on a lab machine because Gnome was too CPU-intensive for this hunk o’ junk. I really couldn’t stand it too much, but at that point KDE was the easiest to configure and was better than nothing at all.

In any case, I’ve configured my laptop to use KDE, and after a little bit of growing pain, I think… I really like it! It’s fast, slick, intuitive and stuff seems to work (so far).

A few holdovers I’m thus far maintaining:

• Thunderbird and Firefox, because I’m not a KDE zealot, and I like those apps. Of course, doing so means one should install gtk-qt-engine so that the fonts and stuff used by these (and other) GTK apps match your font selections in KDE reasonably well.
• add a shell script for nm-applet to the ~/.kde/Autostart directory because I also like the Gnome NetworkManager applet.
• … maybe more things later, I’ll continue to update this entry.

I can’t remember where I ran across this in the first place — maybe I just saw it in yumex yesterday — but tilda is pretty cool. I never use(d) the console too much in FPS games, but it’s nonetheless handy in X to be able to pop that little term window down when needed.

I ran into a few little bugs, but so far no show-stoppers. The one thing it needs to be really useful is to execute upon window manager startup. I manually configured this, but having it do so upon install would be better, if possible.

Late last night, I submitted my first patch ever for an open source project. It was a language string fix for yumex.

It was a very minor change, and in fact probably would’ve been easier just to say, “this bug exists in files A, B, C, D, E and F”, and would have taken less net time for discovery and ensuing fix by the developer than for me to find it, learn how to create patch files, assure that those patches work…. and then scratch the itch which made me figure out how to concatenate them (easy) and test the process all over again. However, I look at the latter part thereof as a learning experience. Now that i know how to do this, I won’t necessarily be so intimidated at submitting patches in the future.

I don’t know that he’ll use my patch — this being my first time, I still don’t really even know if it will work outside my home box, although I don’t see any reason why it shouldn’t. In any case, even such a minor bit of participation like this, it feels good.

So I’ve been spending parts of the last two evenings trying to get a xen guest installed. First thing that annoyed me right off is the necessity to use an http, ftp or nfs point as the source tree, versus a standard directory. Why, oh why?

Anyway, so I sez to myself, “ok, well, I’m running a webserver on this machine, I will just mount an iso over loop, within my webspace, and bingo!”

Right? WRONG… SELinux — which I have been trying to rationalise as that pile of veggies on your plate as a kid that you hate but have been told are good for you — won’t allow arbitrary directories to be accessed from within httpd. No, you need to run restorecon… and you can’t do so to a read-only volume!

With that, I temporarily set SELinux to Permissive, rebooted, and started trying to install my Xen guest.

Once again, no luck. Regardless of what tool I use — virt-manager or virt-install, I kept getting ‘Invalid Argument’ errors thrown back at me.

So after searching google for various, convoluted references to spammy errors, I simplified my search to ‘fedora xen “invalid argument’, which took me to something I wish I had seen all along, the Fedora Xen Quickstart FC6 page. SURELY this would save me!

Alas, my hopes were dashed and turned to petty rage when I read this:

Q. When creating a guest the message “Invalid argument” is displayed.
A. This usually indicates that the kernel image you are trying to boot is incompatible with the hypervisor. This will be seen if trying to run a FC5 (non-PAE) kernel on FC6 (which is PAE only), or if trying to run a bare metal kernel.

Ahem.

[root@ramen ~]# uname -r
2.6.18-1.2849.fc6xen

I re-read the page again. I grepped all the /proc info. I am cool there — not that I would expect otherwise, running a dual core AMD. Everything else matches, so I dunno what this Wiki is implying.

As a last gasp, I then decided that maybe I should try running against a real anaconda-friendly distribution tree, so I chose the mirror at Duke. Kicked off my install… it didn’t kick back an error right away… are we set this time?

No. As it turns out, I got the same error as before — it just took longer because I was accessing a site over the internet.

So, long story short, I am utterly out of ideas. Xen should be easy to configure — and it seems darn well like it’s been designed as such. Nonetheless, I’m a bit at the end of my rope with this thing.

Last night I spent three hours of my life trying to figure something out. Three hours that I’ll never get back. Three hours on something that should’ve only taken five minutes.

Simply put: I tried to get network printing to work via CUPS. I did finally figure the finicky thing out… and hopefully people who are having the same problems that I did will see this and it’ll help em.
The Background: A few months ago, I took the printer connected to my wife’s old desktop and connected it to my Fedora Core 5 linux box. No problems there — printing worked just fine. I was unable to share it, however…. trying to connect to the printer across the network failed. I tried for a little while, to no avail. Meanwhile, I knew that years ago, at the old company, I had set up CUPS to access our network printers, and never had any problems… So last night, with new resolve, I tried again.

So tracing back, I thought of everything I had done. I made my changes to /etc/cups/cupsd.conf to allow remote connections… everything seemed kosher there. First thing I thought of doing that I know I didn’t do before was to open up a port on my local firewall. Specifically, port 631. To do this in FC5, I went to “System | Administration | Security Level and Firewall” in the user menu. At the UI, I went to “Other ports” dropdown and added “631″ TCP and UDP.

Such a simple issue — I surely thought I had resolved my problem. Trying to print returned nothing however — no jobs appearing in the queue. Looking at my error log, I found something akin to the following appearing everytime I tried to print from the remote computer:

Hint: Do you have the raw file printing rules enabled?

I no longer have the full error message readily available (it seems my CUPS log has already been truncated), but that’s the gist of it. So I looked up the message above on Google and found this page posted by an equally-frustrated person. I took his suggestions and made them on my own system. So, (Hint #1) make the following changes:

In /etc/cups/mime.convs, Uncomment…

application/octet-stream     application/vnd.cups-raw        0       -

In /etc/cups/mime.types, Uncomment…

mime.types:application/octet-stream

Fix them, and restart cups:

/etc/rc.d/init.d/cups restart

I actually made a mistake in here, but for continuity’s sake, I will indicate it at the end. You probably won’t make the same mistake and following the above steps may resolve your issue. But read on, regardless — there’s some other stuff you will want to know…

In any case, so I made the changes… still got the same error. So I start fiddling with the settings in CUPS. Running out of options, I decide to check out the Gnome printer configuration tool… and there’s what we will call Mistake #1: As I read elsewhere, find a tool and stick with it. If you use CUPS, don’t use the UI tool. They conflict with each other. Seriously – don’t mix this stuff at all. Before I knew it, my local sample print page output was nothing but one big black inky box, and everytime i tried to print anything, I got the same thing. Also, my print driver would never stay correct. So, in fact — I will recommend using yum (or yumex — it’s easier) to (Hint #2) completely remove the package system-config-printer. That is, remove that if you’re going to use CUPS all the time. If you use something else, you’re on your own. Also, if you’ve been promiscuous with your printer tools, you may find some of those uncommented lines recommented again. Fix them and restart CUPS.

Now — if you’ve gone and made the same dumb mistakes that I have, you’ll probably find that your print setup is in an overall pretty confused state. I resolved this by also (Hint #3) removing the foomatic package and reinstalling it. I was going to remove CUPS and reinstall it if I had to, but I didn’t — and thank God — CUPS is tied to way too much stuff in FC5 to easily remove it, although I guess you could manually rpm –force it. Regardless, uninstalling and reinstalling foomatic did the trick. Once again, you may check those files above to make sure they are uncommented, because while I don’t think foomatic messed with those, I can’t be sure right now. Anyway, you know the drill.

So at this point I am pretty damned sure I have things fixed. I go to the other computer, send a test page and… same error.

I was stymied and a bit frustrated. I began looking at all my stuff again, and then found the biggest idiocy of the whole issue. I had made Mistake #2: When you uncomment, be sure you actually uncomment. What I mean is — when I removed the ‘#’ I had somehow slipped a single leading space character amidst the newly fixed line in mime.convs.

One. Single. Space. I removed the space, restarted CUPS, and three hours later down the road, had out the issue resolved.

So there you have it. What should’ve been a simple configuration took several hours due to both mistakes on my part and idiosyncracies in Linux printing. I should also note, as a postscript, that while retracing my steps, somewhere along the way, the lines where I opened up in my firewall for printing got changed from referencing the port number (“631″) to the actual service itself (“ipp” – internet printing protocol). I am guessing this occurred during the foomatic fix..?