Laptop fails to suspend: fileshare related?

After initial teething problems with suspend & resume, it seemed to be working fine.  Every so often, though, it would just fail to suspend and return to the desktop.  Then, I think it went away, probably because I was using acpid to control the laptop lid button and was manually stopping netmount first.  After I upgraded to KDE4, I returned control to KDE because acpid's logging spam is quite annoying.  (There is another way to hook into the suspend action via scripts even when KDE is activating it, which I should look into.)  I think that I have finally found the cause: unreachable file shares.  I need to do some more testing, but my suspicion is strong.

Testing hassles: stable now

A month or so ago, both my desktop and laptop had independent heart attacks, so I downgraded them from testing to stable.  Was a pity to lose that cutting-edge and slightly unstable toy to play with, but a relief to now be able to get other things done.

The desktop still has a number of testing and bleeding edge packages installed, namely mesa and related ebuilds.

The laptop was exhibiting some weird behaviour--both Firefox and Amarok weren't working--so I reformatted it.  :)  It works fine now.

I guess I'm going to focus more on the stable experience of Gentoo from here on!

OpenOffice 3, KDE and GTK themes

For a while, OpenOffice integrated quite nicely with KDE.  Something happened recently that's causing missing captions in dialogues, PDF export failures and save-filename extensions to go missing in OO 3.1 (not sure about 3.0), details of which are here.  Pretty annoying for what is probably the most popular open-source office suite.  The Gentoo developers solved these issues by masking the "kde" flag.  I'm not sure what all the effects of that flag are, but visual integration with the desktop is the most salient: OO looks either very ugly (Raleigh theme) or screwed without that integration.  (The OO toolbars are essentially blank when using the default KDE theme.) The solution: x11-themes/gtk-engines-*, as mentioned in the official Gentoo KDE Guide.
The disappointing thing here is that the "GTK Styles and Fonts" settings item does not appear by default in the Appearance panel of KDE-4's System Settings.  It only appears after you install certain packages such as gtk-engines-qt, but not gtk-engines-qtcurve.  So if you go looking in System Settings first, you won't find anything that suggests that a solution even exists, and you may have themes installed that you can't select.  I think it makes more sense if the GTK settings item was enabled by the installation of gtk+.
The GTK settings item is installed by gtk-engines-qt as /usr/share/kde4/services/kcmgtk4.desktop, so the most straightforward solution would be to switch installation of that file to gtk+(+kde).  (By which I mean, when the kde USE flag is enabled.)  A crude stopgap measure could be to make all GTK themes depend on gtk-engines-qt if USE="kde", but that sounds messy and like it would just create more problems.  Something should change, though, because the way it currently works doesn't make sense.

Wireless LED

Somewhere around 2.6.25, a new option was added to Networking support: RF switch subsystem support.  I didn't notice it or didn't realise its significance at the time, but if I'd paid more attention to it, I probably would have realised that it was connected with the simultaneous failure of the wireless LED to work anymore.  The options are disabled by default and, as you can guess by the name, provide support for the 'RF kill switch'. This in turn affects the wireless LED.  It finally came to my attention when somehow, something enabled the RF kill switch and of course pressing it didn't disable it.  Just today I discovered that there is another kernel option that the wireless LED depends on in Networking support-->Wireless: Wireless extensions sysfs files (itself a sub-option of "Wireless extensions", which is forced on).

open-source radeon driver

If you've ever used the proprietary ATI fglrx driver, then you probably know what a pain it can be.  (Or could be, I haven't tried 9.x where at least the dependency on libstdc++ has gone.)  However, if you have a modern Radeon HD card, the open-source driver didn't offer much in the way of OpenGL support, which was very disappointing.  Then there came the exciting news that ATI was going to release a significant amount of detail about the Radeon HD hardware to open-source driver programmers.  I don't believe that any of the code has made it into mainline as of this writing, but a number of us have been using the bleeding-edge git sources for libdrm, x11-drm, xf86-video-ati and mesa to test out the forthcoming support.  Just recently, the new drivers and supporting ebuilds became stable enough for me to enable desktop effects in KDE4 and they sure look nice.  (And haven't crashed yet.)  Of course we're looking forward to support for OpenGL 2.0, but this is where things stand at the moment:

prison ~ # glxinfo |grep OpenGL
IRQ's not enabled, falling back to busy waits: 2 0
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: Mesa DRI R600 (RV770 9442) 20090101  TCL
OpenGL version string: 1.4 Mesa 7.7-devel

You can find how to try out the code yourself at this forum thread.

euse: TNG

Jared Hancock and I are working on a next-gen euse (from gentoolkit). It provides much more detailed information about USE flags, right down to the ebuild. The current euse shows local flags per package, which is often quite inaccurate, as local flags come and go. Some flags are turned on globally but then turned off in the ebuild, and then turned back on by the user in /etc/portage/package.use. The new euse will show all this. You can follow our progress at bugs.gentoo.org.

Linux 2.6.31 breakages

A number of packages including lm_sensors and x11-drm fail to compile against Linux 2.6.31.  This is not surprising. It's the old version 2 generation of lm_sensors that fails and apparently the x11-drm package is out of date too. I'm not sure what's going on with stabilizing version 3 but I hope this issue speeds it up. I unmasked it a few weeks ago on my desktop and there are some problems with fancontrol/pwmconfig, but I haven't investigated in detail and the fan appears to be working as normal anyway.

A troubling issue I've noticed is that my laptop has a blank screen when it resumes from sleep. Something to do with the new forced enabling of the framebuffer? I'd been running vanilla-sources on my desktop for a couple of weeks in order to support the bleeding-edge radeon driver but had no problems there, presumably because I'm using a customized x11-drm package through the x11 overlay and so the framebuffer is not enabled. Hmm, should try enabling it and see what happens. For now I am sticking with 2.6.30 on the laptop. I have fought many battles to get suspend+resume working on the laptop, so I'll be looking into the cause of this problem soon.

Portage and eix cache

I recently changed my desktop's Portage and eix cache from the default to sqlite using this guide. Haven't noticed any speed improvements running emerge or equery d, but eix-update is now lightning fast. However, not all overlays support an sqlite eix cache. So I don't recommend turning on the sqlite eix cache for overlays unless you're only using ones that support it. So far I've noticed that x11 does whereas sunrise doesn't.