Towards an Xfce Foundation?
Jannis Pohlmann announced two days ago on the Xfce mailing lists that he started the paperwork needed to register Xfce as a non-profit organization under the German law which would be nice because, I quote:
The benefits are obvious: Xfce would become a legal entity with an official board of directors and we could raise funds in the form of donations and via supporting members in order to organize hackfests etc.
The current draft is available on gitorious. Expect more news on this in the following days and feel free to comment on our mailing lists.
Experiments, adventures, and consequences
I've been doing a fair amount of experimentation on my machines. Been playing with XBMC, Boxee, Ubuntu, and bleeding-edge Xfce and Freedesktop software stacks on Gentoo.
HTPC
First, I tinkered with the HTPC. It's a Zotac MAG, dual-core Atom 330 with nVidia ION graphics. It's just the thing for at 1080p media center. It was running an experimental community-built version of XBMC, installed back in January or February. While it was nice because it was extremely minimal, with just enough operating system to boot straight into XBMC, it was very buggy, and definitely alpha-quality.
So I wiped the disk and installed straight-up Ubuntu 10.04.1, and then installed XBMC and Boxee. I'm still tinkering with it; I need to setup the remote control I just bought, and I need to configure it to load a media center on boot, rather than the Gnome desktop. There have been a few hardware growing pains, mostly related to getting HDMI sound working correctly, and forcing 1080p output -- detected my TV as a 720p device, so I had to fiddle with the nVidia utility to fix that. Also had to do a lot of tweaking in XBMC and especially Boxee to output sound over HDMI.
I'm somewhat familiar with XBMC, but I've wanted to try Boxee for awhile now. It's supposed to be more user-friendly than XBMC, offering a simplified interface based on the XBMC code. It also has that whole "social media" aspect, whatever that's about. Its real attraction is the user-friendliness; I hate having to do so much manual configuration in XBMC. I need something that my wife and I can just pick up and use; no hassle, no tinkering.
Initial XBMC impressions
It works somewhat better than the version I used several months ago. However, most of the video plugins are buggy and/or completely broken, as are some of the helper programs and utilities. All that's supposed to change, though, with the next XBMC release. Supposedly there's an entirely new architecture, so maybe I'll finally get to watch my favorite shows and stream local media a bit easier, with better content scraper integration.
There are some things that don't work -- nothing on SyFy, and all too often the existing network TV plugins don't work for all advertised shows. Mythbusters in particular is very buggy, offering only partial listings for 5 or 6 seasons, and those are extremely low-quality Flash streamed from some third-party download site. Still, my wife can watch her crime shows and 80s favorites, while I can get a fair amount of Mythbusters and other Discovery shows.
Initial Boxee impressions
Useless. Slow. Hard to configure. Totally not what I thought it'd be like. Boxee didn't offer any of the easy internet TV watching I thought it'd have, instead offering a couple hundred useless channels for things I've never heard of. I expected it to have better integration with regular network TV, the same ones I can watch in a web browser. I expected a nice presentation of content, with the video wrapped in a full-screen Boxee experience. I expected hi-def streaming content; instead, the few shows I'm interested in are only available in stuttering low-quality Flash. Why bother, when I can watch The Guild in gorgeous 1080p on my Xbox?
At least XBMC has somewhat working plugins for several networks. Apparently XBMC plugins don't work that well (or at all) on Boxee. I gave up trying to make 'em work. All too often the shows are streamed from stuttering, blocky Flash videos. I tried using the integrated Boxee web browser to watch things like Hulu, but that turned out to be an even slower, laggier disaster.
On the hardware side, it was harder to get HDMI sound working on Boxee than on XBMC. And even though I have all the right VDPAU libraries installed, and I'm using the latest nVidia driver (195.x), nothing on Boxee seems to be accelerated. Even 720p content streamed from my LAN stutters, with the audio occasionally lagging the video. XBMC doesn't have this problem, so I know it's not the graphics stack.
Boxee is definitely beta. Maybe everything will work fantastically on the Boxee Box, but I don't want to spend another $200+ dollars on essentially the exact same hardware. I want to like Boxee, I really do. But at this point, XBMC works where Boxee fails, and even though its user interface is more cumbersome, it still lets me watch videos and play music.
Initial Ubuntu impressions
Slick. Very slick. Installation from a USB key went very well. While I tried to do everything from the commandline in Gentoo, using syslinux and whatnot, none of the Ubuntu guides on creating LiveUSB media worked. I ended up just compiling Unetbootin and Qt4 on my Xfce laptop. Unetbootin worked perfectly on the first time, giving me a bootable 4GB USB stick loaded with Ubuntu 10.04.1.
Installation was simple and straightforward, with minimal user interaction. I did a bit more, because I wanted to create a custom partition layout, but otherwise the end-user part of the process was done in just a minute. The rest of the install proceeded automatically, booting me into a bright, shiny Gnome desktop. After a minute or so a few notifications popped up, advising me to install the proprietary nVidia driver and install some software updates. That took just a couple of clicks. Sweet! Oh, the joys of binary package management.
Even though the HTPC only runs a lowly 1.6ghz dual-core Atom chip with a mere 2GB RAM, the desktop still feels pretty responsive. Firefox starts up as fast or faster than my 1.5ghz Core2Duo laptop with twice the RAM. In my experience, Gnome is always pretty heavy, feeling fairly clunky and somewhat slow even when backed by speedy CPUs and gobs of RAM. Nautilus and Evolution windows always seem to load much slower than Thunar and Claws Mail, or even PCManFM and Thunderbird. Still, despite the anemic hardware, my Gnome experience in Ubuntu is surprisingly pleasant. Nothing seems particularly slow to start on a fresh login. The boot process itself could be faster, though; it takes more'n'a minute to get logged in. I need to cut that down to 10 seconds or less to get a true HTPC "instant-on" experience.
There are some quirks in most ION devices related to suspend and USB wakeups, and my Zotac MAG is no exception. I need to do some commandline hacking to get the computer to suspend every time, and to wake only when a button is pushed on the remote. And configuring LIRC is a whole 'nother deal.
But still, I'm liking what I see. Ubuntu 10.10 will be released next month, and it promises even more improvements and nifty app integration than 10.04.
Laptop
In fact, I liked my brief experience with Ubuntu 10.04 enough to download a daily LiveCD beta of 10.10, "Maverick Meerkat." I plan to create a LiveUSB and install it on my "Linux playground" partition. I've gotten just a taste of how Ubuntu works when using it as a special-purpose media center; now I want to see how it works as a mobile desktop OS.
The last time I had Ubuntu on my laptop, it was Ubuntu Studio 8.04 a few years ago. It lacked polish, lacked the cohesive desktop experience Ubuntu is known for. Its sole advantages were that it was optimized for media production, featuring a low-latency kernel and tons of preinstalled music software, with easy access to much more. I experienced numerous issues with JACK and my USB-to-MIDI adapter, though, so my plans for tinkering with music were shelved.
I'll see how vanilla Ubuntu works on my laptop, and if it goes well, I may look into converting it into a low-latency/realtime audio production environment. I'm very interested in being able to quickly, easily use this machine to create tunes and link up with my piano. There's been a lot of progress in the Linux audio world in two years.
Gentoo
I turned my Gentoo install into a bleeding-edge hardmasked/~arch/stable Xfce testbed. I decided to dump HAL and setup PolicyKit, ConsoleKit, udisks, upower, udev, that whole stack. Originally I wanted just to try out the experimental PackageKit features for Portage, which was a recent GSoC project. I knew that would require most of the aforementioned software stack, so I thought, "As long as it has to be installed anyway, why not dump HAL, too?"
One thing led to another, and pretty soon I had upgraded to Xserver 1.9, disabled HAL, rebuilt world a few times for USE flag changes, and pretty well screwed my system. Reconfiguring my input devices for xorg.conf.d took awhile, and I've been besieged by other difficulties. That's the problem with a source-based distro, and the problem of running Xfce in particular: nothing is especially integrated, and in a lighter environment like Xfce (compared to Gnome), there isn't much code that's designed for a HAL-less system. Apps written for *Kit/udisks/upower are either only available in git, or still unported. A binary distro like Ubuntu would integrate all that stuff forcibly, by writing their own code if need be, so that various actions that require PolicyKit authentication would pop-up windows, prompting for passwords. None of that happens on my Gentoo system.
I ended up adding the Xfce overlay and adding several hardmasked 4.7/live versions of packages just to get udisks/upower support, which helped some. However, several bits of Xfce and other daily applications just don't have the right code yet. So xfdesktop doesn't display icons when drives are plugged, cameras won't always mount and make their photos available, and not all power management options work, even when the user has the right PolicyKit credentials. That's on top of having to reconfigure pretty much my entire working environment due to changes between 4.6 and 4.7 -- everything from panel applets and their configs, to Thunar and window manager preferences. Despite USE="sound" installing libcanberra for event support, and adding sound-theme-freedesktop, event sounds cannot be enabled in the appropriate dialog, because Xfce doesn't believe libcanberra is installed. It's the same for Pidgin -- it doesn't believe there's a working sound framework, either. I have to give it commands like "aplay /some/dir/foo.wav" for each kind of event.
The whole thing, is, quite frankly, a bloody mess. And all because I wanted to get some experimental Portage toys from an overlay. It's my fault, I admit, and even after 8 hours of hacking at it, I'm probably nowhere near finished, assuming it's even possible to get all the bleeding-edge pieces to play nicely together.
(Side note: I would like to thank my fellow Gentoo developer Samuli for taking the time to answer my numerous Xfce-related questions and do a bit of troubleshooting along the way. Thanks, man!)
So, what's to learn from my adventures? First, trying to put everything back to its previous state would take another two days of work, if it's even possible! Second, the price for living on the bleeding edge of *Kit integration is too high. I don't mind running the occasional ~arch package, or using git X11 driver stacks like xf86-video-*, Mesa, and libdrm. But basic hardware abstraction stuff is nothing to be fooling around with. Not being able to use pluggable devices, enable Bluetooth, or properly adjust power management on a laptop is too high a price for being forward-thinking. I wish I'd stayed with my boring HAL system. While deprecated and a pain to configure, at least it worked reliably. More important, maintenance was nonexistent; it was simply a matter of copying several .fdi files into the right directory when I first compiled and installed my desktop. After that, I didn't have to touch a thing.
The HAL-less desktop is supposed to be the future for every Linux distribution out there. I can only hope it is still some ways off, to give upstream coders more time to get their applications in order, so that distributions don't have to do much patching or extensive repackaging and integration, and so that the end-users don't have to spend hours configuring everything to their liking.
Experiments, adventures, and consequences
I’ve been doing a fair amount of experimentation on my machines. Been playing with XBMC, Boxee, Ubuntu, and bleeding-edge Xfce and Freedesktop software stacks on Gentoo.
HTPC
First, I tinkered with the HTPC. It’s a Zotac MAG, dual-core Atom 330 with nVidia ION graphics. It’s just the thing for at 1080p media center. It was running an experimental community-built version of XBMC, installed back in January or February. While it was nice because it was extremely minimal, with just enough operating system to boot straight into XBMC, it was very buggy, and definitely alpha-quality.
So I wiped the disk and installed straight-up Ubuntu 10.04.1, and then installed XBMC and Boxee. I’m still tinkering with it; I need to setup the remote control I just bought, and I need to configure it to load a media center on boot, rather than the Gnome desktop. There have been a few hardware growing pains, mostly related to getting HDMI sound working correctly, and forcing 1080p output — detected my TV as a 720p device, so I had to fiddle with the nVidia utility to fix that. Also had to do a lot of tweaking in XBMC and especially Boxee to output sound over HDMI.
I’m somewhat familiar with XBMC, but I’ve wanted to try Boxee for awhile now. It’s supposed to be more user-friendly than XBMC, offering a simplified interface based on the XBMC code. It also has that whole “social media” aspect, whatever that’s about. Its real attraction is the user-friendliness; I hate having to do so much manual configuration in XBMC. I need something that my wife and I can just pick up and use; no hassle, no tinkering.
Initial XBMC impressions
It works somewhat better than the version I used several months ago. However, most of the video plugins are buggy and/or completely broken, as are some of the helper programs and utilities. All that’s supposed to change, though, with the next XBMC release. Supposedly there’s an entirely new architecture, so maybe I’ll finally get to watch my favorite shows and stream local media a bit easier, with better content scraper integration.
There are some things that don’t work — nothing on SyFy, and all too often the existing network TV plugins don’t work for all advertised shows. Mythbusters in particular is very buggy, offering only partial listings for 5 or 6 seasons, and those are extremely low-quality Flash streamed from some third-party download site. Still, my wife can watch her crime shows and 80s favorites, while I can get a fair amount of Mythbusters and other Discovery shows.
Initial Boxee impressions
Useless. Slow. Hard to configure. Totally not what I thought it’d be like. Boxee didn’t offer any of the easy internet TV watching I thought it’d have, instead offering a couple hundred useless channels for things I’ve never heard of. I expected it to have better integration with regular network TV, the same ones I can watch in a web browser. I expected a nice presentation of content, with the video wrapped in a full-screen Boxee experience. I expected hi-def streaming content; instead, the few shows I’m interested in are only available in stuttering low-quality Flash. Why bother, when I can watch The Guild in gorgeous 1080p on my Xbox?
At least XBMC has somewhat working plugins for several networks. Apparently XBMC plugins don’t work that well (or at all) on Boxee. I gave up trying to make ‘em work. All too often the shows are streamed from stuttering, blocky Flash videos. I tried using the integrated Boxee web browser to watch things like Hulu, but that turned out to be an even slower, laggier disaster.
On the hardware side, it was harder to get HDMI sound working on Boxee than on XBMC. And even though I have all the right VDPAU libraries installed, and I’m using the latest nVidia driver (195.x), nothing on Boxee seems to be accelerated. Even 720p content streamed from my LAN stutters, with the audio occasionally lagging the video. XBMC doesn’t have this problem, so I know it’s not the graphics stack.
Boxee is definitely beta. Maybe everything will work fantastically on the Boxee Box, but I don’t want to spend another $200+ dollars on essentially the exact same hardware. I want to like Boxee, I really do. But at this point, XBMC works where Boxee fails, and even though its user interface is more cumbersome, it still lets me watch videos and play music.
Initial Ubuntu impressions
Slick. Very slick. Installation from a USB key went very well. While I tried to do everything from the commandline in Gentoo, using syslinux and whatnot, none of the Ubuntu guides on creating LiveUSB media worked. I ended up just compiling Unetbootin and Qt4 on my Xfce laptop. Unetbootin worked perfectly on the first time, giving me a bootable 4GB USB stick loaded with Ubuntu 10.04.1.
Installation was simple and straightforward, with minimal user interaction. I did a bit more, because I wanted to create a custom partition layout, but otherwise the end-user part of the process was done in just a minute. The rest of the install proceeded automatically, booting me into a bright, shiny Gnome desktop. After a minute or so a few notifications popped up, advising me to install the proprietary nVidia driver and install some software updates. That took just a couple of clicks. Sweet! Oh, the joys of binary package management.
Even though the HTPC only runs a lowly 1.6ghz dual-core Atom chip with a mere 2GB RAM, the desktop still feels pretty responsive. Firefox starts up as fast or faster than my 1.5ghz Core2Duo laptop with twice the RAM. In my experience, Gnome is always pretty heavy, feeling fairly clunky and somewhat slow even when backed by speedy CPUs and gobs of RAM. Nautilus and Evolution windows always seem to load much slower than Thunar and Claws Mail, or even PCManFM and Thunderbird. Still, despite the anemic hardware, my Gnome experience in Ubuntu is surprisingly pleasant. Nothing seems particularly slow to start on a fresh login. The boot process itself could be faster, though; it takes more’n'a minute to get logged in. I need to cut that down to 10 seconds or less to get a true HTPC “instant-on” experience.
There are some quirks in most ION devices related to suspend and USB wakeups, and my Zotac MAG is no exception. I need to do some commandline hacking to get the computer to suspend every time, and to wake only when a button is pushed on the remote. And configuring LIRC is a whole ‘nother deal.
But still, I’m liking what I see. Ubuntu 10.10 will be released next month, and it promises even more improvements and nifty app integration than 10.04.
Laptop
In fact, I liked my brief experience with Ubuntu 10.04 enough to download a daily LiveCD beta of 10.10, “Maverick Meerkat.” I plan to create a LiveUSB and install it on my “Linux playground” partition. I’ve gotten just a taste of how Ubuntu works when using it as a special-purpose media center; now I want to see how it works as a mobile desktop OS.
The last time I had Ubuntu on my laptop, it was Ubuntu Studio 8.04 a few years ago. It lacked polish, lacked the cohesive desktop experience Ubuntu is known for. Its sole advantages were that it was optimized for media production, featuring a low-latency kernel and tons of preinstalled music software, with easy access to much more. I experienced numerous issues with JACK and my USB-to-MIDI adapter, though, so my plans for tinkering with music were shelved.
I’ll see how vanilla Ubuntu works on my laptop, and if it goes well, I may look into converting it into a low-latency/realtime audio production environment. I’m very interested in being able to quickly, easily use this machine to create tunes and link up with my piano. There’s been a lot of progress in the Linux audio world in two years.
Gentoo
I turned my Gentoo install into a bleeding-edge hardmasked/~arch/stable Xfce testbed. I decided to dump HAL and setup PolicyKit, ConsoleKit, udisks, upower, udev, that whole stack. Originally I wanted just to try out the experimental PackageKit features for Portage, which was a recent GSoC project. I knew that would require most of the aforementioned software stack, so I thought, “As long as it has to be installed anyway, why not dump HAL, too?”
One thing led to another, and pretty soon I had upgraded to Xserver 1.9, disabled HAL, rebuilt world a few times for USE flag changes, and pretty well screwed my system. Reconfiguring my input devices for xorg.conf.d took awhile, and I’ve been besieged by other difficulties. That’s the problem with a source-based distro, and the problem of running Xfce in particular: nothing is especially integrated, and in a lighter environment like Xfce (compared to Gnome), there isn’t much code that’s designed for a HAL-less system. Apps written for *Kit/udisks/upower are either only available in git, or still unported. A binary distro like Ubuntu would integrate all that stuff forcibly, by writing their own code if need be, so that various actions that require PolicyKit authentication would pop-up windows, prompting for passwords. None of that happens on my Gentoo system.
I ended up adding the Xfce overlay and adding several hardmasked 4.7/live versions of packages just to get udisks/upower support, which helped some. However, several bits of Xfce and other daily applications just don’t have the right code yet. So xfdesktop doesn’t display icons when drives are plugged, cameras won’t always mount and make their photos available, and not all power management options work, even when the user has the right PolicyKit credentials. That’s on top of having to reconfigure pretty much my entire working environment due to changes between 4.6 and 4.7 — everything from panel applets and their configs, to Thunar and window manager preferences. Despite USE="sound" installing libcanberra for event support, and adding sound-theme-freedesktop, event sounds cannot be enabled in the appropriate dialog, because Xfce doesn’t believe libcanberra is installed. It’s the same for Pidgin — it doesn’t believe there’s a working sound framework, either. I have to give it commands like “aplay /some/dir/foo.wav” for each kind of event.
The whole thing, is, quite frankly, a bloody mess. And all because I wanted to get some experimental Portage toys from an overlay. It’s my fault, I admit, and even after 8 hours of hacking at it, I’m probably nowhere near finished, assuming it’s even possible to get all the bleeding-edge pieces to play nicely together.
(Side note: I would like to thank my fellow Gentoo developer Samuli for taking the time to answer my numerous Xfce-related questions and do a bit of troubleshooting along the way. Thanks, man!)
So, what’s to learn from my adventures? First, trying to put everything back to its previous state would take another two days of work, if it’s even possible! Second, the price for living on the bleeding edge of *Kit integration is too high. I don’t mind running the occasional ~arch package, or using git X11 driver stacks like xf86-video-*, Mesa, and libdrm. But basic hardware abstraction stuff is nothing to be fooling around with. Not being able to use pluggable devices, enable Bluetooth, or properly adjust power management on a laptop is too high a price for being forward-thinking. I wish I’d stayed with my boring HAL system. While deprecated and a pain to configure, at least it worked reliably. More important, maintenance was nonexistent; it was simply a matter of copying several .fdi files into the right directory when I first compiled and installed my desktop. After that, I didn’t have to touch a thing.
The HAL-less desktop is supposed to be the future for every Linux distribution out there. I can only hope it is still some ways off, to give upstream coders more time to get their applications in order, so that distributions don’t have to do much patching or extensive repackaging and integration, and so that the end-users don’t have to spend hours configuring everything to their liking.
CLI tool to review PO files
If there is something annoying about reviewing PO files is that it is impossible. When there are two hundred messages in a PO file, how are you going to know which messages changed? Well, that's the way it works currently for Transifex but there are very good news, first a review board is already available which is a good step forward but second it is going to get some good kick to make it awesome. But until this happens, I have written two scripts to make such a review.A shell script msgdiff.sh
Pros: tools available on every systemCons: ugly output, needs template file
#!/bin/sh
PO_ORIG=$1
PO_REVIEW=$2
PO_TEMPL=$3
MSGMERGE=msgmerge
DIFF=diff
PAGER=more
RM=/bin/rm
MKTEMP=mktemp
# Usage
if test "$1" = "" -o "$2" = "" -o "$3" = ""; then
echo Usage: $0 orig.po review.po template.pot
exit 1
fi
# Merge
TMP_ORIG=`$MKTEMP po-orig.XXX`
TMP_REVIEW=`$MKTEMP po-review.XXX`
$MSGMERGE $PO_ORIG $PO_TEMPL > $TMP_ORIG 2> /dev/null
$MSGMERGE $PO_REVIEW $PO_TEMPL > $TMP_REVIEW 2> /dev/null
# Diff
$DIFF -u $TMP_ORIG $TMP_REVIEW | $PAGER
# Clean up files
$RM $TMP_ORIG $TMP_REVIEW
Example:
$ ./msgdiff.sh fr.po fr.review.po thunar.pot
[...]
#: ../thunar-vcs-plugin/tvp-git-action.c:265
-#, fuzzy
msgid "Menu|Bisect"
-msgstr "Différences détaillées"
+msgstr "Menu|Couper en deux"
#: ../thunar-vcs-plugin/tvp-git-action.c:265
msgid "Bisect"
-msgstr ""
+msgstr "Couper en deux"
[...]
A Python script podiff.py
The script depends on polib that can be installed with the setuptools scripts. Make sure setuptools is installed and than run the command
sudo easy_install polib.#!/usr/bin/env python
import polib
def podiff(path_po_orig, path_po_review):
po_orig = polib.pofile(path_po_orig)
po_review = polib.pofile(path_po_review)
po_diff = polib.POFile()
po_diff.header = "PO Diff Header"
for entry in po_review:
orig_entry = po_orig.find(entry.msgid)
if not entry.obsolete and (orig_entry.msgstr != entry.msgstr \
or ("fuzzy" in orig_entry.flags) != ("fuzzy" in entry.flags)):
po_diff.append(entry)
return po_diff
if __name__ == "__main__":
import sys
import os.path
# Usage
if len(sys.argv) != 3 \
or not os.path.isfile(sys.argv[1]) \
or not os.path.isfile(sys.argv[2]):
print "Usage: %s orig.po review.po" % sys.argv[0]
sys.exit(1)
# Retrieve diff
path_po_orig = sys.argv[1]
path_po_review = sys.argv[2]
po_diff = podiff(path_po_orig, path_po_review)
# Print out orig v. review messages
po = polib.pofile(path_po_orig)
for entry in po_diff:
orig_entry = po.find(entry.msgid)
orig_fuzzy = review_fuzzy = "fuzzy"
if "fuzzy" not in orig_entry.flags:
orig_fuzzy = "not fuzzy"
if "fuzzy" not in entry.flags:
review_fuzzy = "not fuzzy"
print "'%s' was %s is %s\n\tOriginal => '%s'\n\tReviewed => '%s'\n" % (entry.msgid, orig_fuzzy, review_fuzzy, orig_entry.msgstr, entry.msgstr)
Example:
$ ./podiff.py fr.po fr.review.po
'Menu|Bisect' was fuzzy is not fuzzy
Original => 'Différences détaillées'
Reviewed => 'Menu|Couper en deux'
'Bisect' was not fuzzy is not fuzzy
Original => ''
Reviewed => 'Couper en deux'
[...]
Searching the desktop with Pinot and Catfish
I was looking around for desktop search frameworks today, specifically something with a gtk frontend and that required the fewest resources to run.
I discovered Pinot, a dbus-based file index/monitor/search tool. It even comes with a minimal gtk+ interface. I found few reviews on Pinot, and even fewer recent reviews comparing it to other search frameworks like Strigi, Tracker, and Beagle. I also discovered Catfish, a lightweight frontend to several different search services. There's not much out there on integrating Catfish and Pinot, so I forged ahead and wrote my own code, then did some trial-and-error experiments.
All ebuilds are available on my overnight overlay. Instructions for adding the overlay are on the wiki.
Writing the ebuilds
The only ebuild I found for Pinot is sadly out-of-date, and is completely incorrect. Also, it depends on libtextcat, and I never found an ebuild for that.
So, I wrote my own ebuilds for the latest versions of Pinot and libtextcat.
Not content with Pinot's minimal gtk+ interface, I decided to try Catfish, a PyGtk frontend for several different search engines, including Pinot. Catfish is made by the same developer of Midori, a well-respected lightweight WebKit browser. While Catfish's development has been stalled for two years, I figured it was worth a shot, since its user interface is friendlier than Pinot's.
Catfish, like Pinot and libtextcat, is not in Portage, but there is an open bug for its inclusion. However, the ebuild for the latest version needed updating, as it didn't include Strigi or Pinot. So I rewrote it and added descriptive metadata.xml entries for Catfish's and Pinot's USE flags.
There's still a bit of work left on the Catfish ebuild, since there's a QA warning about not leaving precompiled Python object files in /usr/share/catfish. However, the application itself works perfectly. Just need to clean up the install process so that the bytecode doesn't clutter up the filesystem.
Pinot
On first run, Pinot will take a long time to index your files. I pointed it at my user's /home/ directory, which contains 51,000+ files, totaling 9.3GB on a Reiser3 filesystem with tail enabled. That operation took probably half an hour, and that's on a fast SSD! All of Pinot's indexes and databases take up 455MB, bringing my total /home/ usage to about 9.7GB. Pinot typically used about 50% of my CPU while doing so, sometimes dropping down to the 20s and 40s.
However, since Pinot is on a fast SSD, and it's running off a 2.3Ghz dual-core Athlon backed by 4GB RAM, I didn't notice any performance hit while indexing. I'm not running any special kernels or schedulers (like BFS) either; just vanilla-source-2.6.35.4. There was no noticeable lag or slowdown, despite viewing two Thunar windows, working with four terminals, and browsing nine Firefox tabs. My system was only laggy when compiling Pinot and its dependencies.
Once my /home/ was indexed, I searched around. Queries were pretty much instantaneous. There's no easy way to measure the speed of each query, since it's much too fast to time with a stopwatch. That's probably mostly because of the SSD -- as it is, without a desktop indexer/search app, most similar queries take less than a second. Once the initial filesystem index is complete, Pinot drops back to just monitoring directories if you've told it to do so, relying on the inotify feature in the kernel. That drops CPU and memory usage to zero, as near as I can tell. Nice!
Pinot's greatest advantage on my system, at least, is not its speed, but its usefulness for easily finding deeply buried files and folders.
Interestingly, even though Pinot by default is not supposed to index Git, CVS, or SVN repositories, it seems to ignore that setting. Searching for "catfish" turns up a document named catfish tricks and all the ebuilds and git logs that have "catfish" in the title. Apparently Pinot's regex filter isn't very reliable. I probably need to add in another asterisk to disable searching or indexing of any files within a git directory.
Catfish
Catfish mostly works as expected, though it defaults to using "find" rather than "pinot" as its search engine. I haven't yet found a way to set it to use Pinot as the default search provider. Catfish is quick to load, and its layout is fairly intuitive. Sometimes, however, it will just stop working with Pinot, and even though Pinot has indexed my entire home directory, Catfish won't return any search results, though I can get those results by using Pinot's interface. The rest of the time it works great.
Besides offering a friendlier UI for searches, Catfish's real strengths are its useful options, both for presentation and for tying in with my desktop's filemanager. With a couple of commandline switches, Catfish can display thumbnails of various filetypes, use larger icons in search results, use various wrappers for opening and working with files, or even use powerful regex search methods. No, it won't have the awesome preview capabilities of Gloobus, but you also don't have to install all of Gnome to get similar features.
Right out of the box, Catfish will allow you to open files and folders obtained from your search results just by clicking them. I don't know if that works for all filemanagers, but it works with Thunar, which is all I ask.
I like to use Catfish in combination with another powerful feature of Thunar: custom actions. Since Thunar lacks a built-in search bar (aside from a rudimentary go-to alphabetical list when you press a key), how do you integrate a search utility? One way is by adding search functions to the right-click menu.
- Open a Thunar window, and go to Edit -> Configure custom actions.
- Click the plus icon: +. Give the action a helpful title, description, and icon. "Search" is pretty standard among icon sets, so there should always be one available even when you change themes.
- Add the action command:
catfish --path=%F - Now go to the Appearance Conditions tab. I left the file pattern as * and checked all boxes, so that no matter where I browse or click, I can launch a Catfish search.
- Save the new action and exit Thunar. The next Thunar window you launch will let you right-click anywhere in the browser to open a Catfish search.
You can add any commandline switch you like to the catfish command; just run catfish --help to see the available options.
Thunar's custom action feature is pretty nifty; there are all kinds of things you can put in the context menu. It comes with an example to open a terminal in the current directory. You can create actions to launch applications with a root prompt, convert one image type into another, play media, print or email documents, and more. If you can script it, you can write a trigger for it and stick it in the context menu. Just read the custom actions documentation for many more examples of what you can do with Thunar. Neat!
Looking forward
So, will I keep using Pinot and Catfish? Possibly. While I am leery of any process like Pinot that writes so often to my SSD, and I'm not at all happy with its database size compared to my actual directory size, I do like that it's fast, and responsive. It doesn't seem to have the huge memory leaks or lag that Strigi/Nepomuk do in KDE. In fairness, KDE is trying to get us to believe in the power of the "semantic desktop," while Pinot and Catfish just want to create an easy frontend for finding stuff, without worrying about associating them with various files or activities.
As long as the database doesn't get too much larger, or the indexing/monitoring services use too many resources, I'll keep it around. I've got five+ years of accumulated files in various folders, with more constantly being loaded to and from offline backups. Pinot and Catfish can help with my hard drive spring cleaning, and help me locate stuff that I've just plain forgotten about. The older you get, the less you remember, right?
What I'd really like is a search bar built-in to Thunar, maybe in the upper right corner, backed by Pinot. That'd place everything I need right up front, without having to drill down through right-click menus.
* * *
Speaking of Thunar:
Do you use Thunar? Do you use Dropbox? Xfce developer Mike Massonnet posted a message to the xfce-dev list this morning with a link to a new project: Thunar Dropbox. It integrates the Dropbox service right into your favorite lightweight filemanager. No longer do you have to run Nautilus just to use Dropbox easily. Now you can use it within Thunar.
Searching the desktop with Pinot and Catfish
I was looking around for desktop search frameworks today, specifically something with a gtk frontend and that required the fewest resources to run.
I discovered Pinot, a dbus-based file index/monitor/search tool. It even comes with a minimal gtk+ interface. I found few reviews on Pinot, and even fewer recent reviews comparing it to other search frameworks like Strigi, Tracker, and Beagle. I also discovered Catfish, a lightweight frontend to several different search services. There’s not much out there on integrating Catfish and Pinot, so I forged ahead and wrote my own code, then did some trial-and-error experiments.
All ebuilds are available on my overnight overlay. Instructions for adding the overlay are on the wiki.
Writing the ebuilds
The only ebuild I found for Pinot is sadly out-of-date, and is completely incorrect. Also, it depends on libtextcat, and I never found an ebuild for that.
So, I wrote my own ebuilds for the latest versions of Pinot and libtextcat.
Not content with Pinot’s minimal gtk+ interface, I decided to try Catfish, a PyGtk frontend for several different search engines, including Pinot. Catfish is made by the same developer of Midori, a well-respected lightweight WebKit browser. While Catfish’s development has been stalled for two years, I figured it was worth a shot, since its user interface is friendlier than Pinot’s.
Catfish, like Pinot and libtextcat, is not in Portage, but there is an open bug for its inclusion. However, the ebuild for the latest version needed updating, as it didn’t include Strigi or Pinot. So I rewrote it and added descriptive metadata.xml entries for Catfish’s and Pinot’s USE flags.
There’s still a bit of work left on the Catfish ebuild, since there’s a QA warning about not leaving precompiled Python object files in /usr/share/catfish. However, the application itself works perfectly. Just need to clean up the install process so that the bytecode doesn’t clutter up the filesystem.
Pinot
On first run, Pinot will take a long time to index your files. I pointed it at my user’s /home/ directory, which contains 51,000+ files, totaling 9.3GB on a Reiser3 filesystem with tail enabled. That operation took probably half an hour, and that’s on a fast SSD! All of Pinot’s indexes and databases take up 455MB, bringing my total /home/ usage to about 9.7GB. Pinot typically used about 50% of my CPU while doing so, sometimes dropping down to the 20s and 40s.
However, since Pinot is on a fast SSD, and it’s running off a 2.3Ghz dual-core Athlon backed by 4GB RAM, I didn’t notice any performance hit while indexing. I’m not running any special kernels or schedulers (like BFS) either; just vanilla-source-2.6.35.4. There was no noticeable lag or slowdown, despite viewing two Thunar windows, working with four terminals, and browsing nine Firefox tabs. My system was only laggy when compiling Pinot and its dependencies.
Once my /home/ was indexed, I searched around. Queries were pretty much instantaneous. There’s no easy way to measure the speed of each query, since it’s much too fast to time with a stopwatch. That’s probably mostly because of the SSD — as it is, without a desktop indexer/search app, most similar queries take less than a second. Once the initial filesystem index is complete, Pinot drops back to just monitoring directories if you’ve told it to do so, relying on the inotify feature in the kernel. That drops CPU and memory usage to zero, as near as I can tell. Nice!
Pinot’s greatest advantage on my system, at least, is not its speed, but its usefulness for easily finding deeply buried files and folders.
Interestingly, even though Pinot by default is not supposed to index Git, CVS, or SVN repositories, it seems to ignore that setting. Searching for “catfish” turns up a document named catfish tricks and all the ebuilds and git logs that have “catfish” in the title. Apparently Pinot’s regex filter isn’t very reliable. I probably need to add in another asterisk to disable searching or indexing of any files within a git directory.
Catfish
Catfish mostly works as expected, though it defaults to using “find” rather than “pinot” as its search engine. I haven’t yet found a way to set it to use Pinot as the default search provider. Catfish is quick to load, and its layout is fairly intuitive. Sometimes, however, it will just stop working with Pinot, and even though Pinot has indexed my entire home directory, Catfish won’t return any search results, though I can get those results by using Pinot’s interface. The rest of the time it works great.
Besides offering a friendlier UI for searches, Catfish’s real strengths are its useful options, both for presentation and for tying in with my desktop’s filemanager. With a couple of commandline switches, Catfish can display thumbnails of various filetypes, use larger icons in search results, use various wrappers for opening and working with files, or even use powerful regex search methods. No, it won’t have the awesome preview capabilities of Gloobus, but you also don’t have to install all of Gnome to get similar features.
Right out of the box, Catfish will allow you to open files and folders obtained from your search results just by clicking them. I don’t know if that works for all filemanagers, but it works with Thunar, which is all I ask.
I like to use Catfish in combination with another powerful feature of Thunar: custom actions. Since Thunar lacks a built-in search bar (aside from a rudimentary go-to alphabetical list when you press a key), how do you integrate a search utility? One way is by adding search functions to the right-click menu.
- Open a Thunar window, and go to Edit -> Configure custom actions.
- Click the plus icon: +. Give the action a helpful title, description, and icon. “Search” is pretty standard among icon sets, so there should always be one available even when you change themes.
- Add the action command:
catfish --path=%F - Now go to the Appearance Conditions tab. I left the file pattern as * and checked all boxes, so that no matter where I browse or click, I can launch a Catfish search.
- Save the new action and exit Thunar. The next Thunar window you launch will let you right-click anywhere in the browser to open a Catfish search.
You can add any commandline switch you like to the catfish command; just run catfish --help to see the available options.
Thunar’s custom action feature is pretty nifty; there are all kinds of things you can put in the context menu. It comes with an example to open a terminal in the current directory. You can create actions to launch applications with a root prompt, convert one image type into another, play media, print or email documents, and more. If you can script it, you can write a trigger for it and stick it in the context menu. Just read the custom actions documentation for many more examples of what you can do with Thunar. Neat!
Looking forward
So, will I keep using Pinot and Catfish? Possibly. While I am leery of any process like Pinot that writes so often to my SSD, and I’m not at all happy with its database size compared to my actual directory size, I do like that it’s fast, and responsive. It doesn’t seem to have the huge memory leaks or lag that Strigi/Nepomuk do in KDE. In fairness, KDE is trying to get us to believe in the power of the “semantic desktop,” while Pinot and Catfish just want to create an easy frontend for finding stuff, without worrying about associating them with various files or activities.
As long as the database doesn’t get too much larger, or the indexing/monitoring services use too many resources, I’ll keep it around. I’ve got five+ years of accumulated files in various folders, with more constantly being loaded to and from offline backups. Pinot and Catfish can help with my hard drive spring cleaning, and help me locate stuff that I’ve just plain forgotten about. The older you get, the less you remember, right?
What I’d really like is a search bar built-in to Thunar, maybe in the upper right corner, backed by Pinot. That’d place everything I need right up front, without having to drill down through right-click menus.
* * *
Speaking of Thunar:
Do you use Thunar? Do you use Dropbox? Xfce developer Mike Massonnet posted a message to the xfce-dev list this morning with a link to a new project: Thunar Dropbox. It integrates the Dropbox service right into your favorite lightweight filemanager. No longer do you have to run Nautilus just to use Dropbox easily. Now you can use it within Thunar.
August Xfce desktop
This month's Xfce desktop:
icons: awoken
gtk+: axiomd
xfwm4: axiomd
background: The Crown of the Sun
cursor: Obsidian xcursors
The uncluttered version that shows off the wallpaper and conky configuration:
I built my environment around the wallpaper, an image of a solar eclipse, bringing out the haunting beauty of the sun's corona. I cropped this photo from APOD to fit my screen dimensions.
With such a beautiful cosmic backdrop, I had to search for matching theme elements. I used the same window manager and gtk+ theme, axiomd. It's nice and dark, with moon dust highlights.
It's been a long, long time since I last installed conky. I decided to give it another go, now that it's capable of doing beautiful things with Cairo and Lua. I was especially impressed by this configuration I found on the Arch Linux forums.
I made a few modifications to the ring meter scripts for conky. The end result is pretty decent, considering I haven't done much heavy tweaking yet. You'll need to emerge conky with the lua-cairo and lua-imlib USE flags set, or else the scripts won't function.
The rings frame the corona, with just a touch of transparency to blend it into the deeper space backdrop. From left to right, the rings measure: CPU core 2 load, memory usage, /usr/portage, /, and CPU core 1 load. Adding, removing, shrinking, or expanding rings is pretty easy. The ring scripts are well-commented. The biggest obstacle I've run into so far is adapting the configs to my screen size, ensuring that items are placed just right. I could tweak the ring's curvature to precisely match the eclipse, but it's close enough as it is.
I picked up the icon set because it's very attractive for both dark and light environments. It's very flexible, with numerous alternative icon versions, extra standalone icons, many distribution logos, and a number of helpful scripts inside the tarball. I used one of the included Gentoo logos as my Xfce menu icon.
The mouse cursor theme is glossy and dark, yet it has a few blue animations to add a splash of color. To get it, run emerge obsidian-xcursors.
Applications
In the foreground, Decibel Audio Player is running in the "mini" mode, playing a beautiful track by Planet Boelex.
Thunar is the filemanager open in the background. An Xfce terminal displays an eix-sync operation.
Running in the panel are an assortment of application launchers, including customized dropdown menus for frequently used programs.
After the Xfce menu, launchers, and taskbar, the notification area holds the tray icon for Decibel Audio Player. Then a genmon applet that runs my lastsync.sh Portage script. After genmon, there are plugins for volume control, the Orage clock, and local weather.
Now that I'm using conky, I can probably find a way to integrate the weather, clock, and Portage sync script with the existing ring meters, or even run it in another instance off to the side. Anything to reduce my crowded top panel.
August Xfce desktop
This month’s Xfce desktop:
icons: awoken
gtk+: axiomd
xfwm4: axiomd
background: The Crown of the Sun
cursor: Obsidian xcursors
The uncluttered version that shows off the wallpaper and conky configuration:
I built my environment around the wallpaper, an image of a solar eclipse, bringing out the haunting beauty of the sun’s corona. I cropped this photo from APOD to fit my screen dimensions.
With such a beautiful cosmic backdrop, I had to search for matching theme elements. I used the same window manager and gtk+ theme, axiomd. It’s nice and dark, with moon dust highlights.
It’s been a long, long time since I last installed conky. I decided to give it another go, now that it’s capable of doing beautiful things with Cairo and Lua. I was especially impressed by this configuration I found on the Arch Linux forums.
I made a few modifications to the ring meter scripts for conky. The end result is pretty decent, considering I haven’t done much heavy tweaking yet. You’ll need to emerge conky with the lua-cairo and lua-imlib USE flags set, or else the scripts won’t function.
The rings frame the corona, with just a touch of transparency to blend it into the deeper space backdrop. From left to right, the rings measure: CPU core 2 load, memory usage, /usr/portage, /, and CPU core 1 load. Adding, removing, shrinking, or expanding rings is pretty easy. The ring scripts are well-commented. The biggest obstacle I’ve run into so far is adapting the configs to my screen size, ensuring that items are placed just right. I could tweak the ring’s curvature to precisely match the eclipse, but it’s close enough as it is.
I picked up the icon set because it’s very attractive for both dark and light environments. It’s very flexible, with numerous alternative icon versions, extra standalone icons, many distribution logos, and a number of helpful scripts inside the tarball. I used one of the included Gentoo logos as my Xfce menu icon.
The mouse cursor theme is glossy and dark, yet it has a few blue animations to add a splash of color. To get it, run emerge obsidian-xcursors.
Applications
In the foreground, Decibel Audio Player is running in the “mini” mode, playing a beautiful track by Planet Boelex.
Thunar is the filemanager open in the background. An Xfce terminal displays an eix-sync operation.
Running in the panel are an assortment of application launchers, including customized dropdown menus for frequently used programs.
After the Xfce menu, launchers, and taskbar, the notification area holds the tray icon for Decibel Audio Player. Then a genmon applet that runs my lastsync.sh Portage script. After genmon, there are plugins for volume control, the Orage clock, and local weather.
Now that I’m using conky, I can probably find a way to integrate the weather, clock, and Portage sync script with the existing ring meters, or even run it in another instance off to the side. Anything to reduce my crowded top panel.
Documentation status report, part 2
Been meaning to provide a follow-up to the last documentation report for a few days now, as well as a couple other news items.
Gentoo in the press
LWN ran an article on Linux distributions for PowerPC machines. Gentoo gets the top mention.
Package maintenance
I had the treecleaner team remove a package I maintain, WhaawMP. I hadn't used it in a long time and was no longer interested in maintaining it. Upstream seemed to be dead, and there were several user interface bugs and crashers in daily use. Also, I didn't want to put in the work on trying to make the ebuild comply with the stupid Python3 stabilization forced on all our users. Thanks to Jeremy for punting it. If you're looking for a lightweight video player alternative, please read the comment I left on the bug. bug 315067
Documentation status
Now, down to the docs work I've done, mostly on the 21st and 22nd, after the last status report. The biggest news is that I finished rewriting the handbooks for the autobuilds. In two days, I did four architecture handbooks. I put in some long hours, but it felt good to finally have them all done.
Handbook updates
- Sparc: updated the handbook for the autobuilds. Also fixed the kernel config "conditionals" by adding in version strings to the handbook index code, so that the latest stable version magically appears in the guide. Truly XSL is an awesome thing. The former GDP lead once said that writing for the handbook is almost like programming it. The code is designed to take variables, drop them in place for given conditions, and to test for those conditions depending on the presence of other variables (which we call "keys"), which architecture you're viewing, etc, and then drop those variables in to the rendered page. Once the XSL framework is in place, though, maintaining the GuideXML in the handbooks is much easier. We just drop the newest variable for LiveCD ISO size into the appropriate arch index, and it shows up as "115 MB" in that handbook. You can see some of our keys and how we use them.
- PPC: updated handbook for the autobuilds. bug 260403, bug 292726, bug 234310
- PPC: fixed the abstracts in the index. There was a lot of abstracts in the toplevel index. Abstracts are supposed to be in each chapter, so that the index just picks them up and includes them in the rendered page. Our XSL is frickin' amazing.
- PPC: removed the warning and kernel config for voluntary preemption. I asked the PPC team if this old warning was still valid, and it turns out that the preempt code in the kernel actually works okay. Thanks to Joe for investigating.
- PPC64: updated handbook for the autobuilds. bug 260403, bug 292726, bug 234310
- MIPS: updated handbook. MIPS still doesn't have weekly stages or LiveCDs. Because MIPS media dates back to 2008, there are some things I can't fix in the handbook, like using
eselectfor profile management. If it's not in the stages or CDs, I can't document it. The profiles in particular have been significantly reworked for 10.0, and like everything else, will require some heavy rewrites in the handbook. The team is aware of how ancient their releases are, and are working to put out new media for more recent MIPS chips. bug 260403, bug 292726, bug 234310 - AMD64: fixed a broken link to the AMD64 FAQ
Desktop doc updates
- Xfce guide: updated the
firefoxpackage name. I was watching #gentoo-commits and happened to notice that nirbheek changed the name frommozilla-firefoxto justfirefox.
Other doc updates
- OpenRC migration: added a note on kernel module variables and how OpenRC assigns priority. bug 269349
- vpnc guide: updated the kernel configuration and adjusted the GuideXML to match coding standards. Thanks to tanderson for reporting via IRC. Also changed the text on vpnc overwriting
/etc/resolv.conf. Old versions didn't overwrite it, but recent releases do. bug 330345 - Optimization guide: I updated the GCC documentation links to point at the 4.4 series, since it's been stable for awhile now. The links were pointing to the old 4.3 series.
Project page updates
Website updates
- Where: removed the last reference to 2008.0 media, as the handbooks have all been switched to the autobuilds. Only HPPA still referred to the 2008.0 LiveCD, since that's the last available release. That information has been in the HPPA handbooks for a long time.
- Contact: added another note saying that PR does not provide user support. We've been getting a lot of emails asking us for support, so I've been adding notes to our project page and the toplevel contact page.
- Lists: updated the list of mailing lists with information on closed and inactive list. Thanks to Jeremy for the patch. bug 291860
Documentation status report, part 2
Been meaning to provide a follow-up to the last documentation report for a few days now, as well as a couple other news items.
Gentoo in the press
LWN ran an article on Linux distributions for PowerPC machines. Gentoo gets the top mention.
Package maintenance
I had the treecleaner team remove a package I maintain, WhaawMP. I hadn’t used it in a long time and was no longer interested in maintaining it. Upstream seemed to be dead, and there were several user interface bugs and crashers in daily use. Also, I didn’t want to put in the work on trying to make the ebuild comply with the stupid Python3 stabilization forced on all our users. Thanks to Jeremy for punting it. If you’re looking for a lightweight video player alternative, please read the comment I left on the bug. bug 315067
Documentation status
Now, down to the docs work I’ve done, mostly on the 21st and 22nd, after the last status report. The biggest news is that I finished rewriting the handbooks for the autobuilds. In two days, I did four architecture handbooks. I put in some long hours, but it felt good to finally have them all done.
Handbook updates
- Sparc: updated the handbook for the autobuilds. Also fixed the kernel config “conditionals” by adding in version strings to the handbook index code, so that the latest stable version magically appears in the guide. Truly XSL is an awesome thing. The former GDP lead once said that writing for the handbook is almost like programming it. The code is designed to take variables, drop them in place for given conditions, and to test for those conditions depending on the presence of other variables (which we call “keys”), which architecture you’re viewing, etc, and then drop those variables in to the rendered page. Once the XSL framework is in place, though, maintaining the GuideXML in the handbooks is much easier. We just drop the newest variable for LiveCD ISO size into the appropriate arch index, and it shows up as “115 MB” in that handbook. You can see some of our keys and how we use them.
- PPC: updated handbook for the autobuilds. bug 260403, bug 292726, bug 234310
- PPC: fixed the abstracts in the index. There was a lot of abstracts in the toplevel index. Abstracts are supposed to be in each chapter, so that the index just picks them up and includes them in the rendered page. Our XSL is frickin’ amazing.
- PPC: removed the warning and kernel config for voluntary preemption. I asked the PPC team if this old warning was still valid, and it turns out that the preempt code in the kernel actually works okay. Thanks to Joe for investigating.
- PPC64: updated handbook for the autobuilds. bug 260403, bug 292726, bug 234310
- MIPS: updated handbook. MIPS still doesn’t have weekly stages or LiveCDs. Because MIPS media dates back to 2008, there are some things I can’t fix in the handbook, like using
eselectfor profile management. If it’s not in the stages or CDs, I can’t document it. The profiles in particular have been significantly reworked for 10.0, and like everything else, will require some heavy rewrites in the handbook. The team is aware of how ancient their releases are, and are working to put out new media for more recent MIPS chips. bug 260403, bug 292726, bug 234310 - AMD64: fixed a broken link to the AMD64 FAQ
Desktop doc updates
- Xfce guide: updated the
firefoxpackage name. I was watching #gentoo-commits and happened to notice that nirbheek changed the name frommozilla-firefoxto justfirefox.
Other doc updates
- OpenRC migration: added a note on kernel module variables and how OpenRC assigns priority. bug 269349
- vpnc guide: updated the kernel configuration and adjusted the GuideXML to match coding standards. Thanks to tanderson for reporting via IRC. Also changed the text on vpnc overwriting
/etc/resolv.conf. Old versions didn’t overwrite it, but recent releases do. bug 330345 - Optimization guide: I updated the GCC documentation links to point at the 4.4 series, since it’s been stable for awhile now. The links were pointing to the old 4.3 series.
Project page updates
Website updates
- Where: removed the last reference to 2008.0 media, as the handbooks have all been switched to the autobuilds. Only HPPA still referred to the 2008.0 LiveCD, since that’s the last available release. That information has been in the HPPA handbooks for a long time.
- Contact: added another note saying that PR does not provide user support. We’ve been getting a lot of emails asking us for support, so I’ve been adding notes to our project page and the toplevel contact page.
- Lists: updated the list of mailing lists with information on closed and inactive list. Thanks to Jeremy for the patch. bug 291860