Gentoo Logo
Gentoo Logo Side
Gentoo Spaceship

Contributors:
. Alec Warner
. Alex Alexander
. Alex Legler
. Alexis Ballier
. Andreas Proschofsky
. Andrew Gaffney
. Arun Raghavan
. Ben de Groot
. Bernard Cafarelli
. Bjarke Istrup Pedersen
. Brent Baude
. Caleb Tennis
. Christian Faulhammer
. Christian Zoffoli
. Damien Krotkine
. Daniel Drake
. Daniel Gryniewicz
. Daniel Ostrow
. David Abbott
. David Shakaryan
. Davide Italiano
. Denis Dupeyron
. Diego E. Pettenò
. Donnie Berkholz
. Doug Goldstein
. Gentoo Haskell Herd
. Gentoo News
. Gilles Dartiguelongue
. Greg KH
. Gunnar Wrobel
. Gustavo Felisberto
. Hanno Böck
. Hans de Graaff
. Ioannis Aslanidis
. Jan Kundrát
. Jeffrey Gardner
. Jeremy Olexa
. Joe Peterson
. Jonathan Callen
. Jonathan Smith
. Jorge Manuel B. S. Vicetto
. Joseph Jezak
. Josh Saddler
. José Alberto Suárez López
. Kenneth Prugh
. Krzysiek Pawlik
. Lance Albertson
. Luca Barbato
. Luis Francisco Araujo
. Marcus Hanwell
. Mark Kowarsky
. Mark Loeser
. Markos Chandras
. Markus Ullmann
. Mart Raudsepp
. Matthias Geerdsen
. Michael Marineau
. Michal Januszewski
. Mike Doty
. Mike Pagano
. Mounir Lamouri
. Nathan Zachary
. Ned Ludd
. Nirbheek Chauhan
. Olivier Crête
. Patrick Kursawe
. Patrick Lauer
. Patrick McLean
. Paul de Vrieze
. Peter Weller
. Petteri Räty
. Piotr Jaroszyński
. Remi Cardona
. Renat Lumpau
. Rob Cakebread
. Robert Buchholz
. Robin Johnson
. Romain Perier
. Ryan Hill
. Sebastian Pipping
. Serkan Kaba
. Shyam Mani
. Steev Klimaszewski
. Stefan Schweizer
. Steve Dibb
. Stuart Longland
. Sune Kloppenborg Jeppesen
. Sven Wegener
. Thilo Bangert
. Thomas Anderson
. Timothy Redaelli
. Tiziano Müller
. Tobias Klausmann
. Tobias Scherbaum
. Yuval Yaari
. Zack Medico
. Zhang Le

Last updated:
October 28, 2009, 23:03 UTC

Disclaimer:
Views expressed in the content published here do not necessarily represent the views of Gentoo Linux or the Gentoo Foundation.


Bugs? Comments? Suggestions? Contact us: planet@gentoo.org

Powered by:
Planet Venus

Welcome to Planet Gentoo, an aggregation of Gentoo-related weblog articles written by Gentoo developers. For a broader range of topics, you might be interested in Gentoo Universe.

October 27, 2009
Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)
Blog posts are no replacement for documentation (October 27, 2009, 22:23 UTC)

Since I was asked in a previous post I’d like to make some notes about why I “document by blog post” in so many occasions.

I know perfectly well that my blog posts are no replacement for proper documentation; code, procedures and policies need to be properly documented, and tied to the project they are supposed to document. Documentation by blog post is difficult to write, manage and search, and can be indeed useless for the most art.

So why do I write it? Well, most of the time I start a blog post with some ideas in mind, write down it, and then depending on the feedback I either continue the topic or drop it entirely. I guess the most prominent counter-example is the For A Parallel World (which I know I haven’t updated in a while).

Writing proper documentation is important, and I know that pretty well, I have written and ranted about that before as well. And it’s knowing that, that I started the Autotools Mythbuster project which, to be honest, has given me mixed feedback, and satisfaction. The problem is: writing a blog takes just a modicum of effort, because I don’t have any obligation about form, or grammar, or language; I might soft-swear from time to time in a post, I might rant, I might have some smaller mistakes around, both in grammar and content, and so on. I don’t go updating blog posts to fix grammar and style and so on. Writing complex and organized documentation requires a lot more work, and when I say a lot I mean quite a lot more. Of course the result is also of much higher quality, because of that.

I have tried finding alternative routes to get the good results out without having to just apply that much effort in my (unpaid) free time; the first option was LWN, which actually helped me paying for a good part of Yamato’s hardware. Unfortunately LWN is not a perfect solution for me; partly because my topics tend to be quite low-level, too low-level for the LWN readers I’m afraid, and too distant from the Kernel as well (which is probably the only low-level area that LWN really writes a lot about); the other problem is that LWN is still something similar to a magazine, a journal, and thus does not allow an easy way to organised documentation; like autotools-mythbuster is. It would still be a puzzle of entries; of higher quality than a blog, but still a puzzle.

The classical form for organised documentation is that of a book; in today’s age, ebooks are also quite often used, to avoid the whole mass-production and distribution trouble for topics that might not be of enough interest (interestingly enough, that’s not true still for a lot of books, so lately I actually had to by more paper books because I couldn’t find PDFs of them to use with the Reader). Now, this also have troubles; as you might remember I already tried looking for a publisher for Autotools Mythbuster, before going with the open project it’s now.

The idea behind that would have been putting as much effort as possible into that single piece of documentation, complete it as much as possible and get it out in some complete form. There you go: high-quality results, paid effort, and organised up. Unfortunately, finding a publisher is never an easy task, and for that topic in particular, I ended up hitting a stone wall: O’Reilly already had somebody working on the topic, and the book is out now I think (I haven’t read it). This actually was ignoring a problem with classical books: they cannot easily be updated; and documentation often has to be, to correct mistakes, grammar, style, and especially to be kept up to date with what they document. For instance, Autotools Mythbuster has a specific section on forward porting (which I’ll probably keep updating for the future versions as well).

So the final option was making it an open book; again, the effort is not ignorable, so my first solution was to write on it on a donation basis: would have covered the effort I needed to put into it, and would still have been able to be there for everybody. I didn’t count in the fact that the topic is too developer-oriented to actually be of any use to people who would be donating. Indeed, I wish to thank the last two donors (in terms of time), Thomas Egger (who sent me a good mouse to replace the stupid Mighty Mouse, you’ll soon see results about that, by the way), and Joseph Booker (who sent me some books, I started with The Brief Wondrous Life of OScar Wao because I was meaning to read it for almost two years now, but the useful one will soon prove useful, I’m sure). But they, like most others, never explicitly named the guide. And so I’m trying to find more time for the general postings than that in particular.

Just a note before you start wondering about the guide; yes I haven’t updated it in a while. Why? Because I sincerely feel like it’s not useful any more. As I said it requires a positive amount of effort to be extended; there is, true, some interest on it, but not enough to actually have moved anyone to ever try funding its extension. With O’Reilly now publishing a complete book on the matter, I don’t think it’s worth my time keeping it up. I might still extend it if I have to correct some build system, or if I discover something new, but not going to keep extending it by my own will without such a need.

Bottom-line: I could probably write more extensive, organised, and precise documentation about lots of stuff, especially the stuff I write about on the blog from time to time, but the problem is always the same: it requires time and effort; and both are precious commodity; most of my time is already committed to paid work nowadays, and Gentoo is getting more and more to the third place (first is work, second health). Documenting what I can with the blog is, in my opinion, still better than nothing, so I’ll keep doing that.

Josh Saddler a.k.a. nightmorph (homepage, stats, bugs)
Intel graphics and gaming, Abiword 2.8.0 (October 27, 2009, 19:07 UTC)

Last night I installed UT2004 on my laptop, after not playing it since June. The laptop in question is an older ThinkPad R61i, with an Intel X3100 graphics chip. I know -- not the best for gaming. However, most online reports I found indicate that it's acceptable for such an old game as UT2004, so I figured it'd be worth a shot. The Intel graphics drivers have made a lot of progress in the last two years, especially on the 3D front, right? Right?

Kinda. After reducing all settings to "low" and dialing back the resolution to 1024x768 (native is 1280x800), the game is playable, but with very uneven framerates. Looking toward the middle of a map, or anyplace with a lot of action, introduces a good stutterfest; frames are down to between 8 and 18FPS. I enabled a few extra options such as pixel shaders and VBOs in UT2004.ini to add a bit more performance, but it's still marginal.

I'm rather disappointed. I'm not having nearly as great an experience as other Linux users, and certainly not as good as the Windows gamers who've benchmarked Unreal on this hardware. However, I did also catch the huge xorg-server 1.7 update as well, so maybe there have been some performance regressions since 1.6. It makes it a little hard to determine the areas that could use tweaking. I don't have anything special in my xorg.conf, just a default resolution. It's possible there's a setting I'm missing.

I'd like to try UT2004 on my desktop workstation, which has a RadeonHD 4550 card, but all reports indicate that even the latest git checkouts of the open-source drivers still don't work with Unreal. Apparently the game can't even launch, much less run at playable speeds. But as rapidly as the drivers are maturing, I'm hoping this'll be fixed in a month or so. Call me optimistic. :)

* * *

It looks like Abiword 2.8.0 was released today, so I wrote an ebuild and made it available in my devspace. I've been hand-writing these things for awhile. It took quite a bit of research to determine what went into the 2.7 betas, and now I'll have to do another overhaul of the 2.8 ebuild to account for the new plugin system. There's no longer a separate abiword-plugins package; they're all distributed in the base 2.8.0 archive. This means there will be a lot more tricky configure checks and USE flags, which sucks from a flexibility standpoint. Keeping the plugins in an external package was much simpler, so I'm a bit disappointed by this upstream decision.

Still, right now you can download and install Abiword 2.8.0 using my ebuild. While it needs a few cleanups, it will get you set up with a fully functioning basic Abiword install, though the only available plugin (as shown in the "Plugins" dialog) is .odt support.

This new version launches much quicker than 2.7.10, and it seems to have fixed all the rendering errors and even the crashes that happened with basic operations. Basically, you can click stuff now without worrying. :)

Cleaning up my ebuild is a long task, thanks to those darned plugins. Patches welcome, or I suppose you could always just wait and see what ends up in Bugzilla.

Steve Dibb a.k.a. beandog (homepage, stats, bugs)
my blu-ray ripping trial run (October 27, 2009, 15:47 UTC)

Yesterday, I wanted to see if I could rip a Blu-Ray disc using my PS3.  I really want to get a BD-ROM drive, but they are so expensive still, and since I can install Linux on my PS3, I figured maybe I'd try and save myself some money and see if I could manage to get one ripped and decrypted.  It actually worked, which surprised me.  Ripping the disc was the simplest thing in the world, but the key on the movie I tried (Willy Wonka and the Chocolate Factory) was too new, and currently only AnyDVD has support for it.  I'd love to buy a copy of that, but it only runs in Windows, and it's really expensive.  Instead, I'll just have to wait for the keys to pop up eventually on the doom9 forums.

The first step, though, was getting the PS3 to run Linux.  I took the shamelessly easy way out (and I don't regret it either) and installed Xubuntu.  I won't go into details about how I got Linux on my PS3 since that's well documented.  I will say that I remember quite vividly now why I can't stand binary distros.  Bleh.

The BD filesystem is UDF.  Providing you have a recent kernel (2.6.20, I think) with UDF v2.5 support, you are good to go.  I mounted a remote share and just dumped the disc to an ISO file onto my desktop.

$ cat /media/cdrom0 wonka.iso

That was the easy part.

The hard part was trying to get it decrypted.  I had to use Java tools (bleh) to get to the source.  There are three applications you need.  And if you hate digging through forums and using download services, then I've got direct links for yah:

For Gentoo, you'll need to install the JDK to build the aacskeys library and binary.  I just emerged dev-java/sun-jdk and it worked for me (I know absolutely nothing about Java, but my stabbing in the dark miraculously worked).  You'll also need a runtime environment to actually execute the stuff, and I emerged dev-java/sun-jre-bin and that worked fine, too on my amd64 box.

For aacskeys and Gentoo, you'll need to apply this patch that I cobbled together from what I found on the doom9 forums to get it to compile.  It just fixes the Java include directorys for the Makefile.

Now, I'm still a bit fuzzy about what each program does, and whether you need all of them or not, so I won't go into a lot of detail.  What you want to use, though, is the dumphd program.  But to use it, you'll need to copy the aacskeys library and a file from the bdvmdbg package as well into the path or same directory as the dumphd program.

Once you have that, you can just run dumphd.sh and it'll fire up a simple little GUI telling you if it has all the libraries it needs.  Then you just specify the source and destination, and aacskeys will see if it has a working key to access the disc.

I can't really give much more detail than that, since I'm so new to this.  Suffice it to say, if you read the accompanying README doc that comes with each one, you'll get along just fine.

It took me a long time last night to get just one disc ripped and transferred over my subnet to try it out, and by the time I managed to get it mounted (mount -o loop -t udf wonka.iso /mnt/udf) and access it, it was pretty late.  The keys I had didn't work for my disc, and I didn't want to try the whole procedure over to try another disc.

Anyway, good luck if you try it.  One thing that impressed me is how much simpler it was than I thought it'd be, but what a pain it was trying to figure out where things went wrong.  The doom9 forums are a good resource, but not exactly the best place to find clear, concise information for a beginner.  That part was frustrating.

Personally, I don't think it's worth the hassle right now, the way I did it.  I'll get a BD-ROM sooner or later so I don't have to transfer the content over the network and can instead just test it directly.  But, I started out to see if I could at least get a copy of the ISO and get the tools running all without Windows, and I can.  So, that's progress right there.

October 26, 2009
Remi Cardona a.k.a. remi (homepage, stats, bugs)
Xorg-server 1.7 in ~arch (October 26, 2009, 21:50 UTC)

It's out there now, available in ~arch. Like always, you'll need to rebuild your drivers, just look-up the command given by the server's ebuild (use eread if you've lost the output).

This release took a little longer to unmask not because of the server (it's a nice change). It's because a lot of headers were moved around from library packages to proto packages and vice versa. The ABI of X libraries has not changed, but I'm pretty sure there will be compile errors in some packages.

If that's the case, please file bugs in bugzilla.

Thanks for reading this public service announcement.

Edit: There will not be a package.keywords list for stable users. Xorg-server 1.7 is intended for ~arch users only, at this moment. And all bugs from stable users will be closed INVALID. We will start creating lists when we want to stabilize it.

Steve Dibb a.k.a. beandog (homepage, stats, bugs)
new feeds (October 26, 2009, 17:46 UTC)

I've been having a slew of issues running Apache on my Linode VPS, which I'm still trying to pin down, so in an attempt to offload some of the usage, I'm now going to use Feedburner to provide the RSS feed for Planet Larry.

I know I've played with Feedburner in the past, and kind of flip-flopped on whether to use it or not, but this time I'm sure I'm gonna stick with it.  It's better for users, since they will always have a feed available (whether I have issues or not), and it's better for me since I can offload that part of the network traffic, which is actually quite a lot.

I've already updated the feeds and my apache config to do a permanent redirect, but if you want the feed URLs directly, here they are:

Sorry for the inconvenience.  It seems like everytime I post about Planet it's bad news or maintenance.  Believe me when I say that it aggravates me far more than it does you.

Specifically, the issues I'm having is that Apache is sucking up all the available RAM, of which I only have 360 megs on my account.  It's then rolling over to using all the swap space as well, which only slows things down even more.  I've just started playing with tweaking the MPM configuration a bit, and I'm still trying to find a reasonable solution for my configuration.

In the past, the Linode had been seizing up occassionally, and I'd normally just reboot it and get on with my life.  Recently, I installed monit (an awesome app), and pinpointed that the issue seems to always be with apache.  Now, I'm just trying to narrow it down even  more from there, but offloading the RSS feeds seems like a good step to take anyway ... I get gigabytes of traffic per month just on that, believe it or not.

I'm toying with the idea of setting up lighthttpd instead, but I really prefer apache, and would rather set it up to behave in a low memory environment instead.  So, for any downtime in the near future, chances are it's just me tweaking something.  At least now, thanks to monit, I have a much better idea of when something goes wrong.

Oh, one other tweak I've made is that the planet script itself is more robust as well.  That thing used to run out of control, but I've made some changes that will ensure that if it runs away, at least it won't bring down the system.  I also started playing around with the idea of writing my own feed parser to replace the Planet software completely, and it looks like it's going to be much simpler than I imagine.  I haven't actually started down that path yet, since I have bigger projects to complete, but I'm actually enthusiastic that it'd be far, far simpler than I imagined.

Doug Goldstein a.k.a. cardoe (homepage, stats, bugs)

Right now at work we’re currently having an issue with branch offices and SVN. We’ve got a machine with some decent power with decent disk space handling our SVN repos. We’re running a 1.6 version repo that was dumped and reloaded with 1.6 so its using the newer format fully. However we still have employees at branch offices that often complain about the poor speed of SVN. Oddly the biggest complainers were Windows based devs and people using obscure (at least to me) GUI SVN tools. Currently our branch offices are all linked back to our main office over a VPN link with a dedicated 1.5mbit up and down to each remote office, with a possibility to burst up to 80% of total VPN bandwidth. A few complaints were attributed to poorly coded SVN clients (i.e. one employee’s client would perform an ’svn log’ on the top level of the repo and filter out the correct level of messages on the client side). However the complaints have remained constant.

To mitigate this I had our IT guy configure SVN hotcopied repos at the branch office servers that allow everyone to get their data off those SVN servers (repo UUIDs were sync’d) and then commit back to the main office. Obviously I noticed a significant decline in the number of commits from remote office employees which I was not pleased with (larger commits are always harder to debug and larger commits means code stays remote and not running in our BuildBots longer).

To remedy this I’ve created a new capability in SVN trunk. I’ve called it ‘commit-redir’. Basically a branch office employee can now checkout their code from a local SVN repo and commit as they normally would to that server instead of having to go through the time consuming steps of switching back to the main office repo. Transparent to them, the client advertises the ‘commit-redir’ capability to their local server, which then sees that its a read only mirror and replies back with the correct URL they should present the commit to. The client takes this response and re-submits the commit back to the main office. Net result, employees can enjoy the full speed of having a local mirror of SVN except when committing. They don’t have to jump through loops to use that local mirror and commit back.

Now I’ve still got some bugs in the code and some touch ups to do. We’re also not actually running the code at the office yet due to the afore mentioned bugs but I’m hoping this week to submit the code upstream and to start running it at our offices.

MythTV 0.22 & the database problem (October 26, 2009, 04:14 UTC)

Shortly everyone will start seeing MythTV 0.22 Release Candidate packages (you won’t see Release Candidate 1 but a newer revision) appearing in the tree available to ~arch. Gentoo users need to know that the upgrade path won’t be smooth sailing. Unfortunately, the MythTV developers incorrectly use MySQL which results in data corruption which must be manually fixed. The steps to fix this are available on their website at, http://wiki.mythtv.org/wiki/Fixing_Corrupt_Database_Encoding.

Now you might say to yourself, “hey! That page blames distros specifically Gentoo for the data corruption!” I’ve discussed the issue in length with several developers in the #mythtv-dev channel and unfortunately I can’t change their tune. So all I can do is explain the issue to you, the reader, and let you be better informed.

MythTV originated as a project created by a US based developer and such it only needed to support the needs of the basic US English language set. As time wore on the project gained overseas attention and needed to support non-English character sets and data. A wise decision was made to switch to UTF-8 string handling in all of MythTV so that it would work no matter the language. However, the change was implemented poorly. The MythTV developers implemented UTF-8 conversion within MythTV while leaving their database encoding the same. This wasn’t a problem technically at first because MySQL pre-5.0 defaulted to latin1 encoding (this change was made when MySQL 3.23 was all the rage, especially for the MythTV devs who were overwhelmingly Debian based devs at the time). Fast forward a few years when MySQL released 5.0 and finally acknowledged they need to support UTF-8 out of the box. Gentoo followed upstream’s wishes and shipped their MySQL with UTF-8 as the default and worked with many package maintainers to resolve issues. Several distros (Red Hat, Fedora, Debian, Ubuntu) chose to remain at latin1 as their default so they wouldn’t have to deal with any package issues. Fast forward a few more years (hey let’s be realistic, MythTV releases take forever to come out) and MythTV finally switches to Qt4 (cause its only been almost a year and half since Qt3 was completely end of life’d) and their data conversion code needs to go through some changes. Unfortunately, this changed the on disk representation which is where we’re left now.

The real fix would have been for the developers to read the MySQL Character Set Support page and properly use the database to store the data its suppose to store instead of assuming everyone’s MySQL database would always be hard coded to latin1. And not just the database, but the server, the client libraries, the database and the connection. When they’re in fact sending UTF-8 data.

As a follow-up for those that will ask, no forcing MySQL to be recompiled with latin1 before the MythTV 0.22 upgrade will not fix the issue. In fact it will make it worse since MythTV 0.22 will error if it detects your connection character set is UTF-8 but if you recompile MySQL with latin1, then it won’t know that your database may be corrupt. I recommend following their instructions to fix the issue.

Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)
Proprietaryware all around us (October 26, 2009, 00:15 UTC)

In a guest post at Boycott Boycott Novell I’ve written about my frustration with so-called “Free Software Fundamentalists”. My main problem with them is that they keep insisting in not using proprietaryware, at all, rather than improving Free Software till it actually becomes the norm.

Now, one thing that might be difficult to understand is that, no matter how hard you try, it’s near impossible to not use any kind of proprietary software nowadays. And while I’m one who fights with all his force to make sure that we have Free Software alternatives in such a state that it can be used in as many things as possible, I don’t try to fight the presence of the other kind of software. I might argue which one between their and my methods is the one that can reach the goal better, but that’s not what I wanted to write about right now.

For now I just wanted to note how impossible it is to not rely at least in part in proprietary, closed-source software (this also ties with an older post of mine about updates):

  • do you have a cellphone? unless you’re running stuff like OpenMoko, I doubt you have it pure free software, since even Nokia’s N900 has quite a few proprietary components;
  • okay so cellphones are evil, but do you have a standard phone? remember: if it has an address book it has a firmware on it (and even if it doesn’t it might have a firmware to manage some functions);
  • do you have a VCR? a DVD player? a DivX player? Is any of that running on a free software firmware?
  • cable or satellite TV? Sky (UK and Italy) definitely have firmware in their decoders (there is also some documentation about GPL violations in satellite decoders);
  • not even that, a simple TV? You know, not only they have firmware now, but they also come with an upgradable firmware (at least, my Sony Bravia does); some TVs also have free software on them (Sharp I happen to remember), although I highly doubt they have no proprietary bits in them; heck, remote controls have firmware as well, at least the programmable ones;
  • any game console? none that I know run on pure free software;
  • computers usually have proprietary BIOS, but coreboot is working to replace that; and at the same time we know of many projects working on replacing firmware for wifi cards (although I still can’t understand; why replacing a wifi card’s firmware, but not the SATA controller firmware?); laptops, on the other hand have a lot of components with firmware on them; for instance I remember Lenovo laptops having firmware to control the fans and similar subsystems; and I’m pretty sure “smart batteries” have firmware as well; UPSes have firmware; external drive enclosures have firmware (and there, replacing the firmware with some free software would definitely be useful, given how many bugs the Genesys Logic firmware has!); even keyboards have firmware, at least Apple’s and probably Logitech’s as well; bluetooth dongles have firmware; harddrives and SSDs have firmware;
  • so okay, you use no external hard drive, a motherboard supported by coreboot and so on, your computer is fine; what about the monitor connected to it?
  • and finally, if you’re not using computers (so what are you doing advocating free software?); are you using a modern microwave oven, dishwasher or washing machine? While there are still lots of those appliances that use no computer-like parts, and thus no firmware, quite a lot of the new ones use firmware which is proprietary; I actually find those quite obnoxious because, for instance, you cannot self-repair your washing machine if the mainboard fries up; the firmware (proprietary) has to be flashed in; and to make it even more impossible, they have to flash it with a special dongle, and a special phone, with UMTS connection;

So really, are you using any proprietaryware at all? If so, stop harassing my freedom of choice for a supposedly higher freedom.

October 25, 2009
Gnome 2.28.1 is there (October 25, 2009, 23:32 UTC)

http://dev.gentoo.org/~eva/gnome/gnome-2.28.0.html

Just added gnome-2.28.1 ebuild to the overlay, only had to keep two dependencies down. Since we are now finished with gnome-2.28 core, time to squash bugs, there is quite a number of them already, if you want to participate, just visit the overlay status/TODO or status/BUGS files, or visit gnome 2.28 official release tracker bug

Played with gnome-shell, kind of nice but still needs applet work done as I can't use gnome-globalmenu applet anymore and I'd like to keep to vertical space real estate. Plus I don't like the actual replacements for notification area and clock applet, they do less. I bit worried about speed in activities menu as well, it's damn slow on my Core2@2.2Ghz which I can't understand.

Also worked on some other ebuilds like geoclue, emerillion and seed, not easy on downstream packaging so delayed until further notice.

Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)
A shared library by any other name (October 25, 2009, 19:18 UTC)

One interesting but little known fact among users and developers alike is the reason why shared libraries are installed on systems with multiple file names. This ties a bit into the problem of .la files, but that’s not my topic here.

Shared libraries, especially when built and installed through libtool, usually get installed with one file, and two symlinks: libfoo.so, libfoo.so.X and libfoo.so.X.Y.Z. The reasoning for this is not always clear, so I’ll try to shed some light on the matter, for future reference, maybe it can help solving trouble for others in the future:

  • first of all, the real file is the one with the full version: libfoo.so.X.Y.Z: this because libtool uses some crazy-minded versioning scheme that should make it consistent to add or remove interfaces… in truth it usually just drives developers crazy when they start wondering which value they have to increase (hint: no, the three values you set into libtool flags are not the same three you get in the filename);
  • the presence of the other two names are due to the presence of two linker programs: the build-time linker (or link editor) and the runtime (or dynamic) linker: ld and ld.so; each one uses a different name for the library;
  • the link editor (ld) when linking a library by short name (-lfoo) isn’t in the known about which version you’re speaking of, so it tries its best to find the library transforming it to libfoo.so, without any version specification; so that’s why the link with the unversioned name is there;
  • the dynamic linker, when looking up the libraries to load, uses the NEEDED entries in the .dynamic section of the ELF file; those entries are created based on the SONAME entry (in the same section) of the linked library; since the link editor found the library as libfoo.so it wouldn’t be able to use the filename properly; the SONAME also serves to indicate the ABI compatibility, so it is usually versioned (with one or more version components depending on the operating system’s convention — in Gentoo systems, both Linux and FreeBSD, the convention is one component, but exceptions exist); in this case, it’d be libfoo.so.X; so this is what the dynamic linker looks up, it’s also not in the known about the full version specification.

Now there are a few things to say about this whole situation with file names: while libtool takes care of creating the symlinks by itself, not all build systems do so; one very common reason for that is that they have no experience of non-GNU systems (here the idea of “GNU system” is that of any system that uses the GNU C library). The thing is, ldconfig on GNU systems does not limit itself at regenerating the ld.so cache, but it also ensures that all the libraries are well symlinked (I sincerely forgot whether it takes care of .so symlinks as well or just SONAME-based symlinks, but I’d expect only the latter). A few packages have been found before explicitly relied on ldconfig to do that using a GNU-specific parameter (a GNU lock-in — might sound strange but there are those as well) that takes care of fixing the links without changing the ld.so cache.

And there our beloved .la files come back in the scene. One of the things that .la files do is provide an alternative to the -lfoolibfoo.so translation for the linkers that don’t do that by themselves (mostly very old linkers, or non-ELF based linkers). And once again this is not useful to us, at least in main tree, since all our supported OSes (Linux, FreeBSD, with all three the supported C libraries) are new enough to properly take care of that by themselves.

Nirbheek Chauhan a.k.a. nirbheek (homepage, stats, bugs)
What's missing in Btrfs (October 25, 2009, 16:33 UTC)

So, after being completely betrayed[1] by Ext4 not once, but twice, I decided to evaluate my FS options for /home .

  • FAT* are not an option, neither is NTFS.
  • Ext2 is primitive and HFS/HFS+ is just not Linux.
  • JFS is nice, but (atleast parted) doesn't support grow/shrink.
  • I've used XFS before, and found it to be more reliable than Ext4. However, deleting dirs with thousands of small files is too slow (a common operation when compiling)
  • ZFS would've been an option if my earlier experiences with ZFS-FUSE weren't so horrid.
  • Did not even consider NILFS. It's too new, and I don't know much about it.

It ended up being a choice between the reliable Ext3, or the new-fangled Btrfs. Why Btrfs? Because I've been using it as my Gentoo Distfiles and Portage tmpdir since v0.16, and found it to be the /most/ resilient to power failures of all my partitions.

I ended up selecting Ext3 for /home, but let's see why.

What's missing in Btrfs:

  1. Growing the filesystem to the "left" of the partition. The error message when you try this is cryptic (common in btrfs-progs). However, since for other FSes this essentially involves "move to left and grow to right", I suppose the "move" part is what's missing in btrfsctl.
  2. Pathetic ENOSPC handling. It either throws an ENOSPC at around 75% or when the metadata space fills up. Not sure which, but it's supposedly fixed for 2.6.32.
  3. Volumes once created cannot be deleted. Again, fixed in 2.6.32.
  4. Parted doesn't support editing/creating Btrfs partitions. Support for detecting it was proposed recently; but, I still don't see it in either "master" or "next". This is not a Btrfs problem, but certainly affects whether I'd use it.
  5. There were other minor irritants (with btrfs-progs, mostly), but those will go away with time

Ext3 might have bad performance (especially w.r.t fsync), but atleast it's more reliable. In conclusion, I'll use Ext3 in data=ordered mode for /home till 2.6.33 is out; and then I'll convert my Ext3 partition to Btrfs and forever be happy :}

1. betrayed == sending everything into /lost+found after a forced fsck due to an earlier fsck after a power failure

Stuart Longland a.k.a. redhatter (homepage, stats, bugs)
Dusting off the MIPS boxes (October 25, 2009, 12:06 UTC)

Well… it has been a while… No, I haven’t gone AWOL, just been busy with other things for the past few months.

I’m now in the process of updating my MIPS boxes so that I can resume testing packages. I now have a stable kernel on my O2 (I nicked Debian’s kernel image… to install you just run ar x on the .deb, then unpack the data.tar.gz created into your /) and can seriously look at the userland.

First priority will be developer-related tools that I know well and can test quickly… Subversion is one that I’ll probably tackle, since the version we currently have keyworded is masked. Ditto for git. I’m sure I’ll find other things to get started on, but those two will make doing everyhing else easier.

I’ve also started on some new profiles. People can have a look at http://git.longlandclan.yi.org/?p=gentoo-mips-profiles.git or clone the repository at git://git.longlandclan.yi.org/gentoo-mips-profiles.git to give them a try. When I’ve given them a good thrashing and am satisfied, I’ll look at merging them into the tree, but for now, this is my staging area.

Hopefully with a stable base system upcoming, and new profiles, then I’ll look at new stages, and get this show back on the road.

Testers wanted for x86 (October 25, 2009, 11:15 UTC)

You are running a stable x86 system (at least almost, and for the core components like kernel, system set and X)? Great, we are looking for your help. If you want to try out the following packages and report back (even if everything is running smooth) to me (fauli AT gentoo.org) or the team (x86 AT gentoo.org), we would be happy. Stabilising so many core compontents that might render you system unusable is a big thing, so a lot of testing is appreciated. The packages in detail:

Thanks in advance to everyone who cares

Gentoo Ten Live DVD 10.1 Release (October 25, 2009, 04:02 UTC)

Attention Gentoo Community,

After numerous bug fixes and enhancements the Ten Team would like to encourage everyone to try out the 10.1 release.

A FAQ is available to assist you. We have also started a thread in our Forum. Please post any BUGS you encounter.

Please download the latest testing release for your architecture Gentoo Ten Live DVD 10.1 x86 | Gentoo Ten Live DVD 10.1 amd64.

Thanks for your continued support,

The Gentoo-Ten Project

David Abbott contributed to the draft for this announcement.

October 24, 2009
Tobias Klausmann a.k.a. klausman (homepage, stats, bugs)
Working together (October 24, 2009, 15:33 UTC)

Recently, I've noticed some behaviour by package maintainers that really annoys me. I'm talking about the way stabilization requests are made. Normally, a package maintainer opens a stabilization request bug (STABLEREQ) detailing which version(s) of which package(s) he wants the arch teams to test and stabilize.

Another closely related request which suffers from the same problems I'll detail below are keyword requests. Those are pretty much the same as STABLEREQ, but for "~arch" instead of "arch". Also, the testing required usually is not as strict as that for STABLEREQ for obvious reasons.

For simple packages, neither usually causes problems. For complex packages, this may mean that dependencies need testing and keywording, in some cases five to ten packages on top of the one requested. Unfortunately, some package maintainers have taken up the habit of just dumping the request for their package in bugzilla without checking what dependencies might be needed. Checking the dependencies also involves which versions of the dependencies actually work, which ones are stable (yes, this might mean talking to other package maintainers!).

Another related gripe I have is being pushy with time frames when stuff should be tested and stable and when trouble comes up (test suite fails etc), completely ignoring the bug report the arch team files for half a year or longer.

This kind of added workload (of rather dreary work, to boot) is what makes arch testing so tedious sometimes. Not to mention the burn-out it causes. Not getting any positive feedback (from either users or other devs) doesn't help, either.

Guess I'm turning into a grumpy old dev. But still, try to be a bit nicer to the arch testers, mkay?

PS: Note that there are very positive counterexamples, too: the emacs guys always provide test plans, the security guys are always nice to work with, too. And of course several individuals who are just nice to work with.

October 23, 2009
Marcus Hanwell a.k.a. cryos (homepage, stats, bugs)
Avogadro 1.0.0 Released! (October 23, 2009, 22:02 UTC)

It is with great pleasure that I announce the release of Avogadro 1.0.0. After many years of work we have released what we consider to be a stable Avogadro release on Mole Day, which seems appropriate given the projects's name. There are still some rough edges, but I think this is a good release. With your help we can fix bugs in the release while working on new features in trunk.

Avogadro - Code Swarm from Marcus Hanwell on Vimeo.

What better time to look back to the beginnings of Avogadro. There was a blog post made today by Sourceforge about Avogadro detailing a little of that history. I have also made a code_swarm movie visualizing the history of the Avogadro project. There have been quite some changes in that time both at a project level and a personal level.

I would like to thank Google for sponsoring me for a GSoC project in the summer of 2007. Also Geoff Hutchison for giving me the opportunity to work with him at the University of Pittsburgh on interesting computational and visualization projects. Then there is my new employer, Kitware, who have provided me with an exciting opportunity to push scientific visualization and cross platform development to its limits.

To finish off a great day, my wife has informed me my new espresso machine has arrived! I am going to Camp KDE in January too!

October 22, 2009
Ryan Hill a.k.a. dirtyepic (homepage, stats, bugs)
Machinarium on 64bit Gentoo Linux (October 22, 2009, 03:32 UTC)

I had to spend a few hours trying to get Machinarium(flash required) running on my laptop the other night. Turns out the solution was too easy:

  # USE=32bit emerge -av www-plugins/adobe-flash

Damn.

PS. if you like old-school adventure games, puzzles, or desolate post-apocalyptic cityscapes populated by melancholy anthropomorphized robots (yay), you could do worse than support Linux gaming by dropping 20 bucks on this fine piece of work.

October 21, 2009
... Is This Thing On? (October 21, 2009, 21:41 UTC)

Well, I finally broke down and created a blog. I’ll mainly be posting Gentoo-related stuff here, assuming I remember to update it.

Romain Perier a.k.a. mrpouet (homepage, stats, bugs)

That's not the first post about elog, previously Gilles (eva) posted an excellent entry about that (he was a slightly angry probably :p). All these entries are published in order to warn users and they have its importance...So based on that fact it would be really nice if users start reading them :D

Last week, I did read at least 4 bugs about a problem due the newer version of shared-mime-info (which includes a new database format)... If you as users would read your elogs, guess what? Yes you would find the solution in elog messages.

Important...why ?

When a developer has a important message to deliver to a set of users for a given package, usually he uses elog (elog is logged => no excuses..).
Consider the previous example with shared-mime-info, you will have a lot of problems when you try to open some files (typically gnome/kde startup) which would have not happened if you have a look at your logs.

awesome... but how I can read them ?

That's seriously simple :

  1. If you're a geek who loves GTK+ based applications (like me :p) have a look at elogviewer
  2. Use eread (c.f: man eread)

But for our sanity and peace in our souls "READ THEM" before you post a bug :) .
That will help us a lot, by implicitly reducing the number of useless bugs, and in this way, we will not have to repeat things 50 times.

have fun with gentoo ;)

edit: many thanks to scarab for typos & grammar ;)

Supressing repeating log messages with Syslog-ng (October 21, 2009, 17:57 UTC)

Again today I was hit by Stunnel's excessive logging behaviour, causing my log files to grow rapidly with messages like:

stunnel: warning: can't get client address: Bad file descriptor

Which is caused by my Wifi going offline, I fail to see why Stunnel should log hundreds of lines each second if the network is unavailable....

In my five minute search I couldn't really see how I could get Stunnel to change logging behaviour, without disable logging alltogether.

However I finally figured out how to suppress repeat messages with Syslog-ng, like Metalog did back in the old days when I used that. Stunnel from 2.1.1 and up has a suppress(X) option that is not documented very good. With the suppress option Syslog-ng will apparently suppress repeat messages in X second intervals. You can use it simply like this:

destination messages { file("/var/log/messages" suppress(30)); };

So with a bit of luck I should not be hit by Stunnel logging again.

October 19, 2009
Ryan Hill a.k.a. dirtyepic (homepage, stats, bugs)

Yeah, this bug is back again. Turns out the code that fixes the paths in gcc's own .la files was broken on new version installs. This means that everyone in stable that updated to gcc-4.3.4 and anyone in unstable that updated to 4.4.2 in the last week or so should resync their portage tree and rebuild gcc now.

See https://bugs.gentoo.org/283761 for the poop.

We won't be doing a revbump because this wasn't version specific. It just sucks that no one noticed the problem until a new version was released.


edit: if you're still getting errors when building, such as

  /bin/grep: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/libgomp.la: No such file or directory
  /bin/sed: can't read /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/libgomp.la: No such file or directory
  libtool: link: `/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/libgomp.la' is not a valid libtool archive

where "4.4.1" is the previous version of gcc you upgraded from, run

  # fix_libtool_files.sh
<old gcc version>


app-(x)emacs/gentoo-syntax 1.15 is out (October 19, 2009, 00:03 UTC)

The last news I wrote about the Ebuild mode for both GNU Emacs and XEmacs is some days old and covered version 1.10. Meanwhile we added some functionality that will greatly improve your user experience. All detailed changes are to be found in the shipped ChangeLog file, but I want to give a rough overview about the most important features and the main contributor.

  • faster and more elegant code (ulm)
  • a manual in Info format (fauli), see C-h i under section Gentoo or Emacs, needs fine-tuning, patches welcome
  • support for GLEP 42 news items (ulm)
  • add skeleton support for ebuilds/news items from scratch (ulm)
  • keep eselect mode in sync with eselect features (ulm)
  • keep keywords in sync with eclasses and adding new ones, like mono and kde4 (fauli)
  • reinstate compatability with GNU Emacs 21 (ulm)
  • support for eblit files (ulm)

Now I want to move the spotlight onto the skeleton modes: Pressing C-c C-n in an empty file with ebuild extension, or whose file name matches the GLEP 42 requirements for a news file, will guide you through the creation of a new ebuild. You are asked for the needed items and with the tab key you can often choose from a list with sane entries. Especially news item creation gets easier as this is a seldom task for developers and thus error-prone while being a good measure to communicate important changes to users.

October 18, 2009
The unending tale (October 18, 2009, 23:03 UTC)

Ok guys, buckle up, I've finished reviewing Gnome 2.28 ebuilds except for the gnome-shell stuff. Now Gnome 2.28.1 is expected on wednesday so we can start bumping like crazy to be half-decently on time this time (feels like we'll never be done with the catch-up). There are still quite a few problems with packages as noted in my papers and files under status/ in overlay but upgrade experience should be smoother.

If you are about to test the overlay, please keep us posted on your problems (or your non-problems too) by contacting us on #gentoo-desktop or by filling bug reports. Thanks again to everyone who kept the overlay updated during 2.27 cycle.

edit: fix typo thanks to remi.

Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)
Tip of the day: if Samba 3.4 fails to work… (October 18, 2009, 12:18 UTC)

I fought with this today… if you are running Gentoo ~arch you probably noticed that the current Samba support is “definitely suboptimal” (to use the words of the current maintainer) and indeed it failed to work on me once again (third time; the first was a broken init script; the second was missing USE deps so I was quite upset). If you find yourself unable to log-in Samba, you need to consider two possible problems.

First problem: the Samba password system seems to have either changed or moved so you have to re-apply the password to your user (and re-add the user as well!). To do so you have to use the smbpasswd command. Unfortunately this will fail to work when the system has IPv6 configured. And here comes the next problem.

Samba is likely having trouble upstream to deal with IPv6; indeed it comes down to having the smbpasswd command trying to connect to 127.0.0.1 (IPv4), but the smbd daemon is only opening :: (IPv6), so it’ll fail to connect and won’t let you set your password. To fix this, you have to change the /etc/samba/smb.conf file, and make sure that the old IPv4 addresses are listened to explicitly. If you got static IPs this is pretty simple, but if you don’t, you’ll have a little more complex situation and you’ll be forced to restart samba each time the network interface changes IP, I’m afraid (I haven’t been able to test that yet).

[global]
interfaces = 127.0.0.1 wlan0 br0
bind interfaces only = yes

As you can see we’re asking for some explicit interfaces (and the localhost address) to be used for listening; since samba uses the IPv4 localhost address for the admin utilities you explicit that to make sure it listens to that. For some reason I cannot understand, when doing this explicitly, samba knows to open different sockets for both IPv4 and IPv6, otherwise it’ll open it for IPv6 only.

I’m not even going to fight with upstream about this, I’m tired and I’m tracking down a bug in Gtk#; a nasty one that crashes the app when using custom cell renderers, and I already fixed iSCSI Target for kernel 2.6.32 (as well as version-bumped it).

October 17, 2009
Show desktop (or minimize all) in KDE 4 (October 17, 2009, 12:36 UTC)

Disclaimer: Please correct me if you know better. Thank you.

Back in KDE 3 I’ve been using WIN+D repeatedly to minimize all open windows (”show desktop”). In KDE 4 the “show desktop” feature seems to have been replaced by “show dashboard” (CTRL+F12), which is quite a different thing and not what I want.

As missing the minimize-all hotkey started really bugging me I invested a little time to find out if this is really the end. Luckily it’s not though I can only present a workaround rather than a “real solution”.

The easiest (only?) way to assign global hotkeys to programs in KDE 4 is adding an item to the KDE menu. So if we had a program/command to trigger a toggle on “show desktop” we were done. I found a tiny Bash script to do that:

#!/bin/sh
target=on
if xprop -root  _NET_SHOWING_DESKTOP | fgrep '= 1' ; then
    target=off
fi
wmctrl -k ${target}

(requires xprop and wmctrl, i.e. x11-apps/xprop and x11-misc/wmctrl in Gentoo)

Put that in a file called toggle-show-desktop.sh or so, make it executable and add a KDE menu entry for it:
(The Menu Editor can be found in the contect menue of the “KDE button” also know as Application Launcher Menu.)


Now assign a hotkey in the “Advanced” tab, done.

For comparison/completeness in KDE 3 it’s here:
.. and in XFCE here:

My next post/rant on KDE4 will probably be about the removal of vertical gradiants as desktop backgrounds. No, I don’t wat to do that with Gimp. Seems like I’m the only one ever having used it. Anyway…

Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)

Since today I’m pretty busy, I have no time for a complete post, but rather will give you a tip, if you’re using F-Spot and plan on moving your photos collection. Changing the location of the collection from the preferences not only won’t move your existing photos, but it won’t update the references in the DB either. This gets pretty bad if, like me, you’re forced to move the photo around between different filesystems (or in my case, disk entirely).

To solve that problem, I wrote this little Ruby script using sqlite3-ruby, that takes care of all that’s needed to move the photos:

#!/usr/bin/env ruby

require 'sqlite3'

db = SQLite3::Database.new(ARGV[0])

db.execute("SELECT DISTINCT base_uri FROM photos") do |row|
  newuri = row[0].gsub(ARGV[1], ARGV[2])
  db.execute("UPDATE photos SET base_uri = '#{newuri}' WHERE base_uri = '#{row[0]}'")
  db.execute("UPDATE photo_versions SET base_uri = '#{newuri}' WHERE base_uri = '#{row[0]}'")
end

It takes three parameters: the path to the SQLite database for F-Spot (generally ~/.config/f-spot/photos.db), the old path and the new path. Since the substitution is applied as-is, you need to use two slashes to make sure to start from the real root directory (like //media/photos).

Oh and for the Gentoo users reading this, what I wanted to write about was already written by Robin with better examples that I might have done. Kudos to Robin, and long live for the “old” networking scripts!

Robin Johnson a.k.a. robbat2 (homepage, stats, bugs)

I've been prodding at the concept of the new network script in OpenRC-0.5, and I'm at a loss to try and see why Roy has decided to toss the old network config system away. The new system doesn't have a lot of capabilities, and most significantly totally loses the ability to restart a single interface without affecting the rest of the system. If it's just for a rewrite, then I'm not too worried, but unless all the functionality is still there, I'm worried we are going to move backwards with it.

At the same time, I don't think many people are aware of how powerful the "old" network configuration mechanism is. The net.examples file is only the start, once you start mixing in the pre/post calls, there's a lot of power. It's capable of some feats that I don't see used even in certain parts of the Gentoo documentation[1]. I've put together some of my gems of conf.d/net, and if you have some, I'd love to hear them. Leave a comment or email me the scripts, along with a description.

Configurations available
  • Easy to maintain HE.net (Hurricane Electric) IPv6 tunnels - Download
  • Running two ISPs at home (basic multi-homing) - Download
  • "Enterprise" multi-homing setup, with 4 paths to the Internet - Download
Hosting

I've also started a bit of storage in my Gentoo webspace for these collected works of network configuration, with a bit more documentation.

Notes
  1. The Gentoo docs have this for IPv6: Gentoo IPv6 Router Guide, Tunnel Configuration. You could bring it up manually, or you could just take the IPv6 config above and use it straight with your variables filled in. Volunteers welcome to help merge that config into the Gentoo IPv6 documentation.

October 15, 2009
Markos Chandras a.k.a. hwoarang (homepage, stats, bugs)
zen-sources again on Gentoo (October 15, 2009, 08:50 UTC)

Having been a crazy ‘zen-sources’ user,  I really miss those kernel patches nowadays. So I took up the bug 288512 and zen-sources are again available for all Gentoo users[1]
I haven’t committed them yet on portage tree because I want to ensure that they are safe enough for everyday usage. So until then, you can get them via a new overlay hosted on github

  • git clone git://github.com/hwoarang/zen-sources.git

or via layman

  • layman -a zen-sources

Special thanks to Brandon Berhent for providing the initial Gentoo ebuilds, and for developing the zen-sources :)

Thanks Brandon :)

Have fun with your brand new kernel sources[2]

[1] http://github.com/hwoarang/zen-sources

[2] http://www.zen-kernel.org

October 14, 2009
Tobias Scherbaum a.k.a. dertobi123 (homepage, stats, bugs)

Vor rund 14 Tagen schrieb ich über die anstehende Auflösung des Förderverein Gentoo e.V. – nun 14 Tage später sieht erst einmal vieles danach aus, als wenn auf der kommenden Mitgliederversammlung ein neuer Vorstand gewählt werden kann und zumindest die Auflösung (vorerst?) vom Tisch ist. Die angedachte Mitgliederversammlung am Wochenende 07./08.11. in Bottrop findet ebenso nicht statt. Anstelle dessen wird voraussichtlich im Rahmen des 26C3 in Berlin (vermutlich am 27.12.) eine außerordentliche Mitgliederversammlung stattfinden. Alle Mitglieder des Vereins werden selbstverständlich zeitig hierzu eingeladen.

Ich möchte mich ausdrücklich bei denen entschuldigen, die mir in den vergangenen Wochen Mails mit Hilfsangeboten etc. zukommen lassen haben – ich konnte nicht alle Mails beantworten, aber es tut durchaus gut, zu sehen, dass auch andere noch ein Interesse am Verein haben. Dafür Danke!

Möglichst kurzfristig soll die Webseite des Vereins ein Facelift erhalten und ab dann im Idealfall regelmäßig mit frischen Informationen versorgt werden.

October 12, 2009
To sleep or not to sleep (October 12, 2009, 23:23 UTC)

It's over 1AM again, and I'm still not finished with Gnome 2.28 review. I've spent quite some time this weekend and tonight looking at what was wrong with gnote, gnome-system-monitor, gparted and a few other c++ apps suddendly starting to crash after I updated glib on Friday. Turns out something in the mm stack is doing something wrong so I filled Gnome bug #598209.

Updated to epiphany-2.28 since I got sick of epiphany-2.26 crashing when I wanted to make it remember a new password. Turns out it's not as nice as I would have thought a nearly two years efforts would be. Lots of problems where loading of a page would stop in the middle of the process. I had to install firefox to fill bug reports and access the pages that fails. That's quite a regression but upstream is now aware of it through Gnome bug #598115. Hopefully it'll be fixed for Gnome 2.28.1.

I also spent some time cleaning up unneeded revisions in tree since I had to occupy myself when building all those c++ bindings. So where are we now, a bit less than 41 packages to go for review and about 80% of completeness on my gnome 2.28 status page.

Gunnar Wrobel a.k.a. wrobel (homepage, stats, bugs)
layman moves from subversion to git (October 12, 2009, 13:49 UTC)

In preparation for layman-1.2.4 the repository has been converted from subversion to git. The new repository can be found at git://layman.git.sourceforge.net/gitroot/layman/layman

October 10, 2009
Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)
And finally, the Portage Tree overhead data (October 10, 2009, 17:35 UTC)

I’m sorry it took so long but I had more stuff to write about in the mean time, and I’m really posting stuff as it comes with some pretty randomly ordered things.

In the post about the Portage Tree size I blandly and incompletely separate the overhead due to the filesystem block allocation from the rest of size of the components themselves. Since the whole data was gathered a night I was bored and trying to fixing up my kernel to have both Radeon’s KMS and the Atheros drivers working, it really didn’t strike as a complete work, and indeed it was just to give some sense of proportion on what is actually using up the space (and as you might have noticed, almost all people involved do find the size, and amount, of ChangeLogs a problem). Robin then asked for some more interesting statistics to look at, in particular the trend of the overhead depending on the size of the filesystem blocks.

This post, which comes after quite some angst is going to illustrate the results, although they do tend to be quite easy to see with the involved graphs. I hope this time the graphs do work for everybody out of the box; last time I used Google Docs to produce the output and linked it directly, this saved a lot of traffic on my side, but didn’t work for everybody. This time I’m going to use my blog’s server to publish all the results, hoping it won’t create any stir on it…

First of all, the data; I’m going to publish all the data I collected here, so that you can make use of it in any way you’d like; please note that it might not be perfect, knowledge about filesystems isn’t my favourite subject, so while it should be pretty consistent, there might be side-effects I didn’t consider; for instance, I’m not sure on whether directories have always the same size, and whether that size is the same for any filesystem out there; I assume both of these to be truths, so if I did any mistake you might have to adapt a bit the data.

I also hasn’t gone considering the amount of inodes used for each different configuration, and this is because I really don’t know for certainty how that behaves, and how to find how much space is used by the filesystem structures that handle inodes’ and files’ data. If somebody with better knowledge of that can get me some data, I might be able to improve the results. I’m afraid this is actually pretty critical to have a proper comparison of efficiency between differently-sized blocks because, well, the smaller the block the more blocks you need, and if you need more blocks, you end up with more data associated to that. So if you know more about filesystems than me and want to suggest how to improve this, I’ll be grateful.

I’m attaching the original spreadsheet as well as the tweaked charts (and the PDF of them for those not having OpenOffice at hand).

Overhead of the Gentoo Tree Size

This first graph should give an idea about the storage efficiency of the Gentoo tree changes depending on the size block size: on the far left you got the theoretical point: 100% efficiency, where only the actual files that are in the tree are stored; on the far right an extreme case, a filesystem with 64KiB blocks… for those who wonder, the only way I found to actually have such a filesystem working on Linux is using HFS+ (which is actually interesting to know, I should probably put in such a filesystem the video files I have…); while XFS supports that in the specs, the Linux implementation doesn’t: it only supports blocks of the same size of a page, or smaller (so less than or equal to 4KiB) — I’m not sure why that’s the case, it seems kinda silly since at least HFS+ seems to work fine with bigger sizes.

With the “default” size of 4KiB (page size) the efficiency of the tree seems to be definitely reduced: it goes down to 30%, which is really not good. This really should suggest everybody who care about storage efficiency to move to 1KiB blocks for the Portage tree (and most likely, not just that).

Distribution of the Gentoo Tree Size

This instead should show you how the data inside the tree is distributed; note that I dropped the 64KiB-blocks case, this because the graph would have been unreadable: on such a filesystem, the grand total amounts of just a bit shy of 9GB. This is also why I didn’t go one step further and simulated all the various filesystems to compare the actual used/free space in them, and in the number of inodes.

This is actually interesting, the fact that I wanted to comment on the chart, not leaving them to speak for themselves, let me find out that I did a huge mistake and was charting the complete size and the overhead instead of the theoretical size and the overhead in this chart. But it also says that it’s easier to note these things in graphical form rather than just looking at the numbers.

So how do we interpret this data? Well, first of all, as I said, on a 4KiB-sized filesystem, Portage is pretty inefficient: there are too many small files: here the problem is not with ChangeLog (who still has a non-trivial overhead), but rather with the metadata.xml files (most of them are quite small), the ebuilds themselves, and the support files (patches, config files, and so on). The highest offender of overhead in such a configuration is, though, the generated portage metadata: the files are very small, and I don’t think any of them is using more than one block. We also have a huge amount of directories.

Now, the obvious solution to this kind of problems, is, quite reasonably actually, using smaller block sizes. From the reliability chart you can see already that without going for the very-efficient 512 bytes blocks size (which might starve at inode numbers), 1 KiB blocks size yields a 70% efficiency, which is not bad, after all, for a compromise. On the other hand, there is one problem with accepting that as the main approach: the default for almost all filesystems is 4KiB blocks (and actually, I think that for modern filesystems that’s also quite a bad choice, since most of the files that a normal desktop user would be handling nowadays are much bigger, which means that maybe even 128KiB blocks would prove much efficient), so if there is anything we can do to reduce the overhead for that case, without hindering the performance on 512 bytes-sized blocks, I think we should look into it.

As other have said, “throwing more disks at it” is not always the proper solution (mostly because while you can easily find how to add more disk space, it’s hard to get reliable disk space. I just added two external WD disks to have a two-level backup for my data…

So comments, ideas about what to try, ideas about how to make the data gathering more accurate and so on are definitely welcome! And so are links to this post on sites like Reddit which seems to have happened in the past few days, judging from the traffic on my webserver.

Robin Johnson a.k.a. robbat2 (homepage, stats, bugs)

solar was asking about release statistics, so I grabbed the current data from Bouncer. The nearly 34k releases for 10.0 is just in the 5 days that it's been out. I included the various architetures that were part of each released 'product', to make some degree of comparision possible.

WhatHitsArches
2005.1
installcd-minimum 228561alpha,amd64,hppa,ia64,ppc,ppc64,sparc64,x86
installcd-universal 374388alpha,amd64,hppa,ppc,sparc64,x86
packagecd 162537alpha,amd64,ppc,ppc64,sparc64,x86

2006.0
livecd 242422x86
minimal 287496alpha,amd64,hppa,ia64,ppc,ppc64,sparc64,x86
packagecd 42572amd64,ppc-g4,ppc-ppc,sparc64
packagecd-32ul 10909ppc64
packagecd-64ul 2981ppc64
universal 111359alpha,amd64,hppa,ppc,ppc64,sparc64

2006.1
livecd 307481amd64,x86
minimal 330505alpha,amd64,hppa,ia64,ppc,ppc64,sparc64,x86
packagecd 39118ppc,ppc-g3,ppc-g4,ppc64,ppc64-g5
universal 122280alpha,hppa,ppc,ppc64,sparc64

2007.0
bt-http-seed 72980ALL
livecd 411958amd64,x86
minimal 496943alpha,amd64,hppa,ia64,ppc,ppc64,sparc64,x86
packagecd 27593ppc-g4,sparc64
universal 137554hppa,ppc,ppc64,sparc64

2008.0_beta1
livecd 19426amd64,ppc64,x86
livedvd 4amd64,x86
minimal 14069alpha,amd64,hppa,ia64,ppc64,sparc64,x86
universal 1745ppc64,sparc64

2008.0_beta2
livecd 37771amd64,x86
livedvd 17842amd64,x86
minimal 55745alpha,amd64,hppa,ia64,ppc,sparc64,x86
universal 3142ppc,sparc64

2008.0
livecd 477934amd64,x86
minimal 406531alpha,amd64,hppa,ia64,ppc,sparc64,x86
packagecd 12308sparc64
universal 83600hppa,ppc,sparc64

10.0_pre20090926-1952
livedvd 4870amd64,x86

10.0
livedvd 33703amd64,x86

10.1
livedvd 0amd64,x86

Notes
  • 2008.* has the LiveDVD's pulled from mirrors due to size complaints.
  • bt-http-seed was an (failed) experiment with a set of mirror URLs for trying to load-balance Bittorrent's HTTP seeding
  • Bouncer really needs replacing, but there's nothing really good to do so that I'm aware of. mod_sentry isn't nice. Other suggestions welcome. Should support products, architectures within products, seperate check/serve URLs, detailed hit recording for analysis.

David Abbott a.k.a. dabbott (homepage, stats, bugs)
Gentoo Ten Live DVD 10.1 (New Release) (October 10, 2009, 01:41 UTC)

After numerous bug fixes and enhancements the Ten Team would like everyone to try out the 10.1 release.
Downloads
Gentoo Ten Live DVD 10.1 x86
Gentoo Ten Live DVD 10.1 amd64

A FAQ is available to assist you. We have also started a thread in our Forum. Please post any BUGS you encounter.

Thank you for your support.

October 08, 2009
Steve Dibb a.k.a. beandog (homepage, stats, bugs)
utosc: distro round table (October 08, 2009, 15:18 UTC)

Assuming all goes well today (I don't fall into an alternate universe), I'll be taking part in the Utah Open Source Conference a bit.  There is going to be a *nix Distribution Round Table discussion, and I'll be representing Gentoo Linux.  Yeehaw.

Please be sure to hold your applause until the end.

Acutally, to be honest, I'm a bit nervous, since I have no clue what I'm going to say, and I don't do well with crowds.  Should be interesting.  Maybe it'd be a good time to pitch Ubeantoo.

October 07, 2009
Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)
How special PAM supports gets added to Gentoo (October 07, 2009, 16:24 UTC)

You might wonder why the PAM support for special authentication method is somewhat lacking in Gentoo; the reason is that, mostly, I maintain PAM alone, which means that you get to use whatever I use myself most of the time. One of the things that I was very upset we didn’t support properly was the Smartcard/Token based authentication; unfortunately, while I got two smartcard readers in the past months to do some work, I hadn’t fetched a smartcard yet, and tokens seem to be quite difficult to find for end users like me.

Thanks to Gilles (Eva), I now have a token to play with, and that means I’m looking to write up proper support for token-based authentication (and thus, smartcard-based as well). This already started well, because I was able to get one patch (split in three) merged in pam_pkcs11 upstream (available in the gentoo 0.6.1-r1 ebuild), as well as cleaning up the ebuild to work just like it’s supposed to as a PAM ebuild (for instance not installing the .la files which are not used at all).

But since this is not yet ready to use, it’s easier if I show you how it works after a day or two of tweaking:

Yes today I was quite bored.

Please note that this is not really “production ready” in my opinion:

  • the pam_pkcs11 module uses the /etc/pam_pkcs11 directory for configuration, but almost all PAM modules use /etc/security for their configuration;
  • the pkcs11_eventmgr daemon has to be started by the user manually, but it uses a single, system-wide configuration file (/etc/pam_pkcs11/pkcs11_eventmgr.conf), this does not really seem to be the right way to handle it for me, but I’ll have to discuss that with upstream;
  • most likely we want to provide, based on USE flag or in a different ebuild, some scripts to handle the event manager more easily, for instance making it start on each X and console login, and making sure that the login is locked as soon as the key is removed;
  • the event manager polls for the card, which is using CPU and power for no real good reason; a proper way to handle this would require for udev to send signals on plug and remove so that the event manager can handle that; since the exact key needed is unlikely to be known at rules-generation time, this might require adding a central daemon monitoring all the smartcards and tokens and passing the information to registered event managers.

This mostly means that there’s going to be a long way to go before this is ready, and I’m pretty sure I’ll have to write a complete documentation on how to set it up, rather than just a blog post with a video, but at least it’s going to be feasible, at one point.

Please feel free to comment on whether the video is useful at all or not; I’m trying to experiment with less boring methods of explaining stuff related to Gentoo and free software in general, but I have no clue whether it’s working or not, yet.

October 06, 2009
Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)
This is crazy, man! (October 06, 2009, 09:43 UTC)

And here, the term “man” refers to the manual page software.

I already noted that I was working on fixing man-db to work with heirloom-doctools but I didn’t go in much details about the problems I faced. So let me try to explain it a bit in more detail, if you’re interested.

The first problem is, we have two different man implementations in portage: sys-apps/man and sys-apps/man-db. The former is the “classical” one used by default, while the latter is a newer implementation, which is supposedly active and maintained. I say supposedly because it seems to me like it’s not really actively maintained, nor tested, at all.

The “classic” implementation is often despised because, among other things, it’s not designed with UTF-8 in mind at all, and even its own output, for locales where ASCII is not enough, is broken. For instance, in Italian, it outputs a latin1 bytestreams even when the locale is set to use UTF-8. Confusion ensures. The new implementation should also improve the caching by not using flat-files for the already-processed man pages, but rather using db files (berkeley or gdbm).

So what’s the problem with man-db, the new implementation? It supports UTF-8 natively, so that’s good, but the other problem is that it’s only ever tested coupled with groff (GNU implementation of the (n)roff utility), and with nothing else. How should this matter? Well, there are a few features in groff that are not found anywhere else, this includes, for instance, the HTML output (eh? no I don’t get it either, I can tell that the nroff format isn’t exactly nice, and I guess that having the man pages available as HTML makes them more readable for users, but why adding that to groff, and especially to the man command? no clue), as well as some X-specific output. Both those features are not available in heirloom, but as far as I can see they are so rarely used that it really makes little sense to depend on groff just because of those; and the way man-db is designed, when a nroff implementation different from groff is found, the relative options are not even parsed or considered; which is good to reduce the size of the code, but also requires to at least compile-test the software with a non-groff implementation, something that upstream is not currently doing it seems.

More to the point, not only the code uses broken (as in, incomplete) groff-conditionals, but the build system does depend on groff as well: the code to build the manual called groff directly, instead of using whatever the configure script found, and the testsuite relied on the “warnings” feature that is only enabled with groff (there was one more point to that: previously it returned error when the --warnings option was passed, so I had to fix it so that it is, instead, ignored).

But it doesn’t go much better from here on: not only man-db tries to use two output terminals that are no defined by the heirloom nroff (so I hacked that around temporarily on heirloom itself, the proper fix would be having a configuration option for man-db), but it also has problems handling line and page lengths. This is quite interesting actually, since it took me a long time (and some understanding of how nroff works, which is nowhere near nice, or human).

Both nroff and groff (obviously) are designed to work with paged documents (although troff is the one that is usually used to print, since that produces PostScript documents); for this reason, by default, their output is restricted width-wise, and has pagebreaks, with footers and headers, every given number of lines. Since the man page specification (command, man section, source, …) are present in the header and footer, the page breaks can be seen as spurious man page data in-between paragraphs of documentation. This is what you read on most operating systems, included Solaris, where the man program and the nroff program are not well combined. To avoid this problem, both the man implementations set line and page breaks depending on the terminal: the line break is set to something less than the width of the terminal, to fill it with content; the page break is set as high as possible to allow smooth scrolling in the text.

Unfortunately, we got another “groff versus the world” situation here: while the classic nroff implementation sets the two values with the .ll and .pl roff commands (no, really you don’t want to learn about roff commands unless you’re definitely masochist!), groff uses the LL register (again… roff… no thanks), and thus can be set with the command-line parameter -rLL=$width; this syntax is not compatible with heirloom’s nroff, but I’m pretty sure you already guessed that.

The classic man implementation, then, uses both the command and the register approach, but without option switches; instead it prepends to the manpage sources the roff commands (.ll and .nr LL that sets the register from within the roff language), and then gets the whole output processed; this makes it well compatible with the heirloom tools. On the other hand, man-db uses the command-line approach which makes it less compatible; indeed when using man-db with the heirloom-doctools, you’re left with a very different man output, which looks like an heirloom in itself, badly formatted and not filling the terminal.

Now we’re in quite a strange situation: from one side, the classic man implementation sucks at UTF-8 (in its own right), but it works mostly fine with heirloom-doctools (that supports UTF-8 natively); from the other side we got a newer, cleaner (in theory) implementation, that should support UTF-8 natively (but requiring a Debian-patched groff), but has lock-ins on groff (which definitely sucks with UTF-8). The obvious solution here would be to cross-pollinate the two implementations to get a single pair of programs that work well together and has native UTF-8; but it really is not easy.

And at the end… I really wish the roff language for man pages could die in flames, it really shows that it was designed for a long-forgotten technology. I have no difficulty to understand why GNU wanted to find a new approach to documentation with info pages (okay the info program suck; the documentation itself doesn’t suck as much, you can use either pinfo or emacs to browse it decently). Myself, though, I would have gone to plain and simple HTML: using docbook or some other format, it’s easy to generate html documentation (actually, docbook supports features that allows for the same documentation page to become both a roff-written man page, and an HTML page), and with lynx, links, and graphical viewers, the documentation would be quite accessible.

October 05, 2009
Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)

I say “default editor” in quotes because Gentoo really does not have a default editor, but rather a fallback-editor for whenever the users hadn’t chosen one themselves. And this is why stuff like the stage3, sudo, openrc and so on default to that when $EDITOR is unreliable (that is, until we can move to a full-fledged wrapper script).

Paul, in the previous post explained it quite well, albeit briefly, but since some other people asked me about that again, I’ll quote him and then go in a bit more of details:

… Third nano was kept as the default because it is small, straightforward, and easy to get out of when you don’t know it (let’s face it neither vi(m) nor (x)emacs is that easy to get out of). Fourth, by having the EDITOR/VISUAL variables point to nano (which is installed by stage2 as well as stage3) things would be working (although probably not optimal) out of the box. …

Indeed Paul speaks well: neither vi (or vim) nor emacs (or xemacs) is going to work. Why is that? Some people even goes as far to say that “it’s called *vi*sudo“ and “vi is the default Unix editor”. At the same time, I wouldn’t be surprised to hear “Emacs is the default GNU editor”. Well, let’s decompose it in two different problems.

Technical problem: the system set is messy already (and this is also “thanks” to my own pambase creation — which is, though, a solution to a previous problem). The packages that do enter the system set should be, whenever possible, small and with little dependencies. This includes, obviously, USE-optional dependencies, since when they are enabled, the dependencies also become part of the system set (like it happens with gnome and pambase). The dependency tree of nano is near invisible, while those of both vim and emacs are quite long (sure there are things like elvis, nvi, zile and jove, but this will bring us to the next point…).

Reality problem (or flame-retardant method): there is no way on Earth that any average number of people will be accepting to use the same editor as default, when taken from the list of “most popular” editors. Hey we cannot even find consensus among the three developers of lscube (I’m using Emacs – yeah I’m an Emacs user, burn me – and my colleagues using VIM and Eclipse). If we were to choose vim, all Emacsen users will complain, if we were to use GNU Emacs, both vim and XEmacs users will complain, and so on so forth. So we use nano, which is likely to make unhappy the most people, but all in the equal amount.

There’s a corollary to the reality problem above: if we were to choose any of the lightweight variants that I named above, or more of them, most likely the problem would be more or less the same, since almost all people would be pretty unhappy with the choice and would then unmerge that and install their editor of choice. But it would most likely upset the two “main factions” unequally, which would make one feel discriminated against.

Newbie problem: finally, there is another note: both Emacs and VI (and respective clones) aren’t exactly the most user-friendly editors. A newbie user who has no clue how to work in Gentoo is unlikely to guess at first sight how to use either of them, while nano is pretty much the easiest thing you might find around. You can fight as much as you want about powerfulness (Emacs and VI are obviously much more powerful than nano) and you can fight about relative easiness of use (:w versus C-x C-w) but nano is going to win over both of them in that regard.

So no, we’re not going to change the default anytime soon.

Gentoo Linux - Ten Years Compiling: 1999 - 2009 (October 05, 2009, 01:02 UTC)

Happy Tenth Birthday, Gentoo!

Gentoo Linux is proud to announce the immediate availability of a new, special edition LiveDVD to celebrate this monumental occasion. The LiveDVD features a superb list of packages, some of which are listed below.

  • System packages include: Linux Kernel 2.6.30 (with gentoo patches), Accessibility Support with Speakup 3.1.3, BASH 4.0, GLIBC 2.9, GCC 4.3.2. Binutils 2.18, Python 2.6.2, Perl 5.8.8, and more.
  • Desktop Environments and window managers include: KDE 4.3.1, GNOME 2.26.3, Xfce 4.6.1, Enlightenment 0.16.8.15, Openbox 3.4.7.2, Fluxbox 1.1.1, TWM 1.0.4, and more.
  • Office, graphics, and productivity applications include: OpenOffice 3.1.1, G/Vim 7.2.182, Abiword 2.6.4, GNUCash 2.2.9, Scribus 1.3.3.11, GIMP 2.6.4, Inkscape 0.46, Blender 2.49a, XSane 0.996, and much more.
  • Web browsers include: Mozilla Firefox (Minefield) 3.5.3, Arora 0.7.11, Opera 10.0, Epiphany 2.26.3, Galeon 2.0.4, Seamonkey 1.1.17, and other favorites.
  • Communication tools include: Pidgin 2.5.9, Quassel 0.5, Mozilla Thunderbird 2.0.23, Claws Mail 3.7.2, Ekiga 2.0.12, Qtwitter 0.7.1, irssi 0.8.13, and many more.
  • Multimedia applications include: Amarok 2.1.1, MPlayer 1.0_rc4, DvdAuthor 0.6.14, LAME 3.98.2, FFMPEG 0.5_p19928, GNOME-MPlayer 0.9.7, SMPlayer 0.6.6, and several others.

The Gentoo-Ten LiveDVD is available in two flavors, a hybrid x86/x86_64 version, and an x86_64-only version. The livedvd-x86-amd64-32ul-10.0 will work on x86 or x86_64. If your arch is x86, then boot with the default gentoo kernel. If your arch is amd64 boot with the gentoo64 kernel. This means you can boot a 64bit kernel and install a customized 64bit userland while using the provided 32bit userland. The livedvd-amd64-multilib-10.0 version is for x86_64 only.

Please select your architecture to be redirected to a mirror for download: x86amd64

A FAQ is available to assist you. We have also started a thread in our Forum. Please post any bugs you encounter.

In addition, we have some exceptional new artwork from Ben Stedman, and Gentoo Developer Alex Legler.

Thank you for your continued support,

Gentoo Linux Developers, The Gentoo Linux Foundation, and The Gentoo-Ten Project

October 04, 2009
Review progress (October 04, 2009, 22:39 UTC)

In overlay news, we are currently at 75% of completeness for the 2.28 release. Currently reviewed 46 ebuilds, at bit less than 55 to go.

In other news, if you get strange gnupg related failures, head over to bug #275291. We will apply patch when someone from gnome herd has a chance to get around it.

Update: fix typo

Mounir Lamouri a.k.a. volkmar (homepage, stats, bugs)
Gentoo/PPC needs you ! (October 04, 2009, 21:41 UTC)

Gentoo/PPC team is here to make sure packages are marked stable and are keyworded as soon as possible and without breaking the tree. Unfortunately, we can't manage the flow of bugs coming and the list is growing too quickly.
Stabilizing and keywording is a big work. Fauli have explained it a few weeks ago in a blog entry.

So if you have a PowerPC and you want to help, you can and we will appreciate it !
First of all, look at the Gentoo/PPC testing doc. Some things may be outdated, consider essentially the procedures.

I've made some bug lists to make the life of everybody easier:
- stabilization requests
- keyword requests
- security bugs

Please, refer to the Gentoo/PPC testing doc if you want to help on one of these bugs.

Do not hesitate to come see us on #gentoo-powerpc on freenode.

2009 Gentoo 10 Screenshot Winners (October 04, 2009, 18:02 UTC)

Woot! Happy Birthday Gentoo. As part of the Birthday party today we announce the winning screenshots.

Thanks to everyone who entered the contest. There were 54 entries using 5 different window managers / desktop environments.

The Winners
  1. Quick23t Compiz Fusion
  2. ashtophet Fvwm 2.5.27
  3. Integer Fluxbox

For all the specifications and cool details please visit the winners page.

discuss this!

Diego E. Pettenò a.k.a. flameeyes (homepage, stats, bugs)
Explaining the sudo crapfest (October 04, 2009, 17:45 UTC)

Some of you might have noticed that I’ve been attacked in the past few days over a feature change bug (now unrestricted so you all can judge it for what it was) with sudo.

Let’s try to explain what the problem seems to have been with that bug: the sudo ebuild, since a long time ago, when it was maintained by Tavis Ormandy (taviso, of, among other things, ocert fame), changed the default editor used to nano. The reasoning for this is that you have to have a valid default editor in sudo, and that, after all, is what we ship in the stage3 as default editor, and what OpenRC sets as default editor if the user sets nothing else. I kept the same setting because, well, I could see the point in it; and I’m not a nano user, I don’t have a single nano executable on my main running systems: I use GNU Emacs for all my “heavy” editing, and zile (of which I’m a minuscule contributor from time to time) for the smaller stuff.

This is just the default editor used by sudo, but by no definition the only one. Indeed it’s mostly used in two places: visudo and sudoedit. The former, respects the EDITOR variable, with the usual rules, so if your root user has the EDITOR variable set to anything it’ll be used (this is also not a default, we pass explicitly the --with-env-editor option at ./configure); the only place where it’s not used, by default that is, is if you invoke sudo visudo, but not because we set the default to nano, but rather because sudo by default resets the environment. For what concerns sudoedit, it honours the EDITOR variable by default without us doing anything about it.

Why did we ask sudo to explicitly honour the EDITOR variable? Isn’t that unsafe? Well, not really. First of all, sudoedit is a special command that takes care of allowing an user to edit a file without running anything as root user, so the EDITOR will always be fired up with the same permission as the user running it (pretty cool stuff); and for what concerns visudo… if you allow an user to run visudo, they can easily set up their user to do anything at all, so the permission under which EDITOR runs is pretty much moot.

So why did I refuse to use the EDITOR variable in the ebuild? Well the reason is that I hate that particular dirty hack (because a dirty hack it is). Other ebuilds, like fcron, have been doing it, and I don’t like its use there either. The reason is that it makes package building relying on a variable that is not by default saved anywhere, and that might not really be the same between the build and host machines (just as a further example, I have different EDITOR settings between root and my user… if I were to build sudo right now_, with solar’s changes, with my usual method – sudo emerge with envkeep – I would get a build error: EDITOR="emacsclient -c"). If this is really a big concern, the proper solution is to have a proper virtual implementation of the editor: a /usr/libexec/gentoo-editor script that accepts just one parameter (a filename) and relies the call to the currently-selected editor via the EDITOR environment variable. Something like this:

#!/bin/sh

if [ $# != 1 ]; then
    echo "$0 accepts exactly one parameter." >/dev/stderr
    return 1
fi

if [ "x$EDITOR" = "x" ]; then
    echo "The EDITOR variable must be set." >/dev/stderr
    return 1
fi

exec "$EDITOR" "$1"

Note: I wrote this snippet right at my blog, I haven’t tested, checked, re-read it at all.

This would allow ebuilds to properly set a default (or even a forced default!) in their configuration stages, without getting in the way of users’ choices.

Now, this is going to require a bit of work; the reason for that is that you have to make sure that it works standalone, that it works with the packages that would like to use it, and most likely you want to make available a “safe-editor” script as well, to enable eventual safe modes where shell-escape (as well as opening random files) is disabled, for those applications that do open the editor as a different user. Since I have never seen much point in pushing this further (I have a long TODO list of stuff much more important for QA, Gentoo and users as a whole), I haven’t done anything about it before, and I didn’t want to start that. But hey if somebody wanted to contribute it, I would have been the first one making use of it.

Now, how much in the way of users I have been by passing --with-editor=/bin/nano in the ebuild? I would sincerely say very little. Do you want to change the default at build time? Take your “How Gentoo Works” handbook out and look up in the index the topic EXTRA_ECONF. It’s a variable. It allows you to pass further options to econf. Options to ./configure (which is what econf wraps around) are positional: the last one passed is the one that “wins”.

Too much work to use EXTRA_ECONF each time you merge sudo?

# mkdir -p /etc/portage/env/app-admin
# echo 'EXTRA_ECONF=\'$EXTRA_ECONF --with-editor="${EDITOR}"\'' >> /etc/portage/env/app-admin/sudo

It really isn’t that dificult, is it?

And what really ticked me off is users, which, as precious as they are, are still just users (in this case not even a well-known power user) telling me what the “Gentoo way” is… I think I know pretty well the Gentoo way, given I’ve been a major developer for the most part of the past five years, I’m one of those trying his best to keep everything up to date and maintained, I’m the one who’s running his own workstation to make sure that Gentoo packages do build out of the box.

Josh Saddler a.k.a. nightmorph (homepage, stats, bugs)
R700, KMS, 3D, SSD, and other hardware (October 04, 2009, 08:37 UTC)

Gosh, just look at all the buzzwords in the title!

As you may have guessed, I'll be talking a bit about the recent developments on the FOSS drivers for RadeonHD cards, specifically for R700 cards. And some other hardware stuff.

Radeon

Yesterday, October 3, I made some big ol' changes to my workstation.

I decided to try out the new video driver stack that all the kids have been talking about. Kernel Mode Setting, git Mesa/xf86-video-ati/libdrm, git kernel 2.6.32_rc1-git3. All that jazz. I wanted to see if the 3D and KMS features were really working on my RadeonHD 4550 or not. I normally run a stable graphics stack, with ~arch Mesa/x86-video-ati/libdrm where necessary to keep up on 2D acceleration and features.

This was a big leap for me. So I first consulted some of the X11 team members, remi and nirbheek, who were quite helpful. I installed the latest git-sources kernel, which at the time was 2.6.32_rc1-git3. Mike Pagano has since added -git5. Next, I downloaded the individual -9999 ebuilds for the git master packages from the X11 overlay, stuck 'em in my local overlay, and merged 'em. Only thing left to do was reboot.

Lemme tell ya -- KMS in action is awesome. The console output is just beautiful, and there's no more flickering when SLiM and Xfce load.

I did notice some minor graphical corruption of the default mouse pointer. However, the corruption isn't present when using any pointer but the default "arrow", and it also isn't seen when hovering inside a Firefox window. I was told this is because Firefox uses its own cursors. Anyway, I reported the bug upstream.

Disclaimer: I know glxgears isn't a benchmark. But folks always want to know its results anyway. I tried running glxgears, which gave me a result of over 1300FPS with desktop compositing activated. My window manager is xfwm4, so all compositing is via Xrender, not OpenGL. Disabling compositing resulted in a 500FPS boost to over 1800FPS. What's this mean? Who knows. Probably nothing. Moving on.

I took the advice of my fellow developers on IRC and installed quake3-demo. Couldn't run it, though. It blanked the screen, then a message from my LCD firmware appeared, some kind of "input not supported" or "input not detected" error. It slowly repeated the window, drawiing it from center to the top right. I had to Ctrl-Alt-Bksp to get to the console. It also locked up SLiM in the background, pegging one of my CPU cores at 100%. At this point, I rebooted just to test that KMS was still working, then called it a night.

Today, I revisited my pointer corruption bug tried the workarounds posted by Alex Deucher. To my surprise, each one worked! Booting with radeon.modeset=0 removes the glitch, though it makes each boot extremely ugly, of course. Specifying EXANoDownloadFromScreen "true" in /etc/X11/xorg.conf also fixes the corrupted pointer, though it may also be slowing down all screen drawing operations by the tiniest bit. The jury's still out on that one; it may just be my imagination. I decided to keep this second fix, as KMS is just too glorious to throw out. I like pretty boots.

I also revisited quake3-demo, since I found some pointers on the Phoronix forums that had a workaround, which is to run OpenGL applications prefixed by LIBGL_ALWAYS_INDIRECT=1. To my surprise, this worked nicely. I tested resolution has high as 900-something by 720. My screen is 1440x900, but I haven't felt like pushing it that far, yet. The game is fluid and playable. I need to figure out how to display FPS so I can properly record what I'm seeing.

With the success of Q3demo, I remembered that QuakeLive has recently added Linux support. I installed the add-on for Firefox and tried it out. Works nicely, though I'm also running Firefox with LIBGL_ALWAYS_INDIRECT=1 just to be sure. As Alex Deucher and John Bridgman have pointed out on the Phoronix forums, that variable really isn't the safest thing to do, since if something crashes it can take down the whole X server, not just the application. However, it's also the only way I get working 3D games.

QuakeLive is pretty playable, though the framerates in a few places aren't smooth -- I can't tell if this is because of my card's capabilities, or the driver stack, or the whole weird idea of playing a 3D first-person shooter inside a web browser. :) The big problem with QuakeLive is that the sound is terribly distorted: the voices are greatly drawn-out and slowed down, like playing an old tape recorder at 1/4 speed. There are some solutions on the QL forums, but they're mainly for Ubuntu/Pulseaudio users. I haven't found anything that works for me, yet. The effects and music are okay; it's just the voices that lag horribly.

I've also installed the latest Nexuiz, version 2.5.2, in anticipation of future testing. One of these days I'll reinstall UT2004, but I haven't read any succesful reports of that game on R700 cards. There's a lot of testing to do in the future!

Overall, I'm thrilled with the new driver hotness for my ATI card. I bought it specifically because I knew the 2D support at the time was excellent, and because there would be so many good things coming down the way for other features, including 3D acceleration. (Yes, just like the latest XKCD strip. I swear, it's like that guy listens to everything I say and watches everything I do. It's really spooky!)

Hats off to all the developers for making it happen. Many thanks!

SSD

After August's fiasco with a defective SSD, I decided to use my refund from the RMA and order a different SSD a few days ago. This time I've settled on a SanDisk enterprise SSD from an HP blade server. Only cost $49, no shipping charges. Brand new. eBay for the win.

It packs 16GB of SLC flash, which makes it perfect for mounting /usr/portage and /var on it. This way I can feel free to sync whenever I want, instead of only once a week or more. My system drive uses MLC flash, so I've been trying to ease the write load on it, which means putting the high-write activity on a dedicated disk.

The SanDisk SSD "only" has sustained reads/writes at 60MB/sec, but that's plenty for syncing Portage, as the real limiter is not how fast data can be dumped to the disk, but how fast the rsync servers can send it to my box. Same for /var writes -- it's mostly just log files and some tiny temp things, as /var/tmp is already mounted on a RAMdisk. No large files that need >100MB/sec bandwidth. I'm lookin' forward to shovin' it in my box!

More hardware

Since September 28 was my birthday and all, I've been treating myself to various bits of cheap hardware. Like a replacement AC adapter for my DC PicoPSU. The current AC brick is rated at 102W, which is way more than I need, but the problem is that it spins up its tiny fan at only 50%-75% load. This means that opening up a bunch of tabs, compiling packages, playing Quake, watching large-sized Hulu videos and whatnot turns on the fan right away. And it's the world's most annoying fan. It's loud, whiny, it hisses, and it blows the bad smell of very hot electronics out into the room. Lemme tell you, hot plastic and PSU guts do not smell good.

I just ordered a replacement fanless adapter. This thing is high-quality, designed to run very cool. And it's rated at 150W output, meaning it can match my 150W PicoPSU. My max system draw is maybe 60W, but I'll have overhead room in case I ever feel like upgrading a key component somewhere.

I also bought a $40 wireless router, an Asus WL-520gU. I already have a WL-500gP v2, which I hacked and flashed with DD-WRT a long time ago. This new router is so that I can hook up my Xbox 360 to the network without having to run 50 feet of cable across the carpet. I chose the 520gU instead of the gC because the gU supports Xlink Kai, which seems prett cool to me, as I don't have a Gold Live account. Yay for tricky internets. Apparently it's pretty common to buy a cheap wireless router and put it into client mode, rather than buying the $100 official USB dongle . . . which doesn't even support WPA2-AES or any decent security. Asus routers are known for excellent open-source support, and I've had nary a complaint about my current one. Yay for Linux on routers! Yay for online gaming!

* * *

Oh yes, and before I forget, this month's Xfce desktop:

Space ice!

It's October, but my current desktop is so pretty (gallery link) I haven't felt the need to switch for the last couple of weeks. There's another clean version that just shows off the wallpaper in my devspace.

David Abbott a.k.a. dabbott (homepage, stats, bugs)
Podcast 64 The Making Of Gentoo Ten LiveDVD (October 04, 2009, 01:14 UTC)

Happy Birthday Gentoo
livedvd
The 10th anniversary Gentoo LiveDVD was made by the community for the community. It was created with the help of Gentoo developers from around the world and users alike. In this podcast I talk about some of the people and a brief discussion on how it came together.

Full Screenshot
Join us on freenode irc channel #gentoo-ten

LINKS:
Gentoo Ten Team
http://dev.gentoo.org/~dabbott/pr/gentoo-ten-team.txt
Gentoo Ten LiveDVD FAQ
http://www.gentoo.org/proj/en/pr/releases/10.0/faq.xml
Forum Post
http://forums.gentoo.org/viewtopic-t-793820.html
Gentoo Ten Wallpapers
http://www.gentoo.org/proj/en/pr/releases/10.0/graphics.xml

irc network freenode channel #linuxcrazy

LiveDVD (released Oct 4, 2009)
http://www.gentoo.org/main/en/where.xml

Download

ogg

mp3

specs

October 03, 2009
Jeremy Olexa a.k.a. darkside (homepage, stats, bugs)
Re-locating a linode installation (October 03, 2009, 23:02 UTC)

I recently had a bit of downtime on my linode. If you are wondering what a 'linode' is, check out my review or the website. And a big thank you to the folks that used my referral code when they got setup with linode themselves, you guys rock!

So, about my recent 1/2 day downtime. It was self-inflicted because I wanted to move to a different datacenter. I moved my linode from Newark, NJ to Dallas, TX. It is quite a long story, but it boils down to a problem with my ISP (Comcast). I was only able to pull 100K/s from the Newark datacenter and 2-3M/s from the others. This was unacceptable. I tried to get it escalated past Comcast's frontline support but they kept asking me questions like "Do you use a router? If so, each computer only gets 1/2 the speed" & "Every computer is different. I'm glad that you can get 3M/s from another host, that is really good" Sigh.

At least Linode's customer server was helpful and allowed me to work around the ISP. The steps to move a linode are as follows:

  1. File a support request. (My initial request was answered in 11 minutes)
  2. Shutdown your linode
  3. Hit the 'migrate' button, after support sets up your migration
  4. Wait for the transfer. My total transfer time was ~43 minutes (~6G to transfer). This was pretty fast throughput, in my opinion
  5. Meanwhile, update your DNS for your new IP.
  6. Since you can queue up a boot job, I just let it go and checked in on it a couple hours later. Magic, it was online. :)

So, to finish the story off. Linode++, Comcast--. I wish I didn't need to do something like this, I wish my ISP was...I don't know...smart?

Patrick Lauer a.k.a. bonsaikitten (homepage, stats, bugs)
Update: Gentoo in commercial environments (October 03, 2009, 18:28 UTC)

I've been busy collecting some really great stories from people using Gentoo in places that I really didn't expect. Some of them want to remain anonymous, which I have no issue with. But there are some gems like this one:

==========
Hey, I'm the CTO of a small company in Sweden, and this is our short 'success story' :-)

blogg.se is a Swedish blogging platform which generate 130 000 new entries, 150 000 comments and 2 500 new accounts on a daily basis. We currently (September 25th, 2009) have a reach of 2,2M unique visitors per week.

Gentoo has always been the preferred OS choice for us. We (the developers) were all attracted by its 'sane' defaults and clean approach to software deployment.

Here at blogg.se we use Gentoo for all our staging, testing and production environments. We have about 30 running instances on 32-bit, 64-bit and KVM-virtualized hardware.

Gentoo (and its wide ecosystem of utils) has been very helpful in helping us plan our environment. We use layman to distribute our own software, Metro for building custom images and a wide range of apps for maintaining our installs.

The collaborative efforts of Gentoo is inspiring and something you want to be a part of. I'm already involved through the Sunrise-overlay and hopefully qualifying as a Gentoo developer some time soon.

Johan Bergström
CTO blogg.se
===========

That's quite awesome on multiple levels, and I thank Johan for sharing this short glimpse at how people leverage Gentoo. I hope to publish a few more stories soon, so stay tuned and feel free to mail me your story!

Last-minute reminder: Today is Gentoo bugday**! (October 03, 2009, 15:42 UTC)

**fixing bugs with both users and devs together.

Join us in #gentoo-bugs on Freenode, please!

October 01, 2009
News from the front (October 01, 2009, 23:04 UTC)

For those that might have been wondering where was that guy speaking about imminent stabilization of gnome 2.26, well I was taking some time off (sort of). The Gnome 2.26 situation got a bit better in the last weeks as due to the production of a release media, a lot of dependencies we were waiting on are finally getting stabilized. You can still see progress on bug #263083, closer than ever !

Since I can't stand working on Gnome 2.26 anymore and since upstream has been kind enough to drop their new almost shiny 2.28, I started doing some QA on ebuilds in overlay before allowing them to move to the tree. Over 92 ebuilds, all of which are not necessarily interesting for gnome 2.28, I've currently reviewed 25 and that's with current 65% of completeness of the ebuild bumps, so there is still quite some work, and don't expect the overlay to be safe for use just yet.

One last word on 2.26, there will be a migration guide, it's still getting a few modifications before it all goes public with stabilization but I'm spreading the word in the hope that we won't see any new bugs concerning what has been documented.

Remi Cardona a.k.a. remi (homepage, stats, bugs)

Turned out that xorg-server 1.6 is pretty much ready for stabilization, as only a handful of bugs were reported over the testing period since last week, and they only concerned the stabilization list.

Without further ado, I've asked our faithful Arch Teams (pretty much all of 'em) to stabilize xorg-server 1.6 and friends. amd64 was the first one to the finish line with a stabilization done in under a day!

Gentoo is again back in business for X. Woo!

Now to all stable users, don't forget to read the upgrade guides we wrote :

Don't forget, please file bugs in bugzilla.