Planet Gentoo

Diego E. Pettenò: The neverending fun of debugging a debugger

Diego E. Pettenò (flameeyes) — Sat, 04 Jul 2009 00:20:08 +0000

In the previous post of mine I’ve noted that I found some issues with the Mono-implemented software monosim. Luckily upstream understood the problem and he’s working on it. In the mean time I’ve had my share of fun because mono-debugger (mdb) does not seem to work properly for me. Since I also need Mono for a job task I’m working on, I’ve decided to work on fixing the issue.

So considering my knowledge of Mono is above the average user, but still not that high, I decided to ask on #mono (on gimpnet). With all due respect, the developers could really try to be friendly, especially with a fellow Free Software enthusiast that is just looking for help to fix the issue himself:

<miguel> thread_db is a libc feature I think to do debugging
 Chances are, you are no an "interesting" Linux distro
 One of those with "Roll your own optimization flags" that tend to break libc
 miguel_ miguel
<Flameeyes> miguel, yes using gentoo but libc and debugging with gdb are fine...
<miguel> I knew it ;-)
 Yup, most stuff will appear to work
 But it breaks things in subtle ways
<Flameeyes> and I can debug the problem libc side if needed, I just need to understand what's happening mono-side
<miguel> You need to complain to the GDB maintainers on your distro
 All the source code is available, grep for the error message
<miguel> Perhaps libthread_db is not availabel on your system
<Flameeyes> it is available, already ruled the simple part out :)
 and yes, I have been looking at the code, but I'm not really that an expert on the mono side so I'm having an hard time to follow exactly what is trying to do

As you can see, even if Miguel started already with the snarky comments, I tried keeping it pretty lightweight; after all, Lennart does have his cheap shots at Gentoo, but I find him a pretty decent guy after all…

Somebody else, instead, was able to piss me off in a single phrase:

<directhex> i thought the point with gentoo was that if you watch make output scrolling, you can call yourself a dev ;)

Now, maybe if Mr Shields were to actually not piss other developers off without reason, he wouldn’t be badmouthed so much for his blogs. And I’m not one of those badmouthing him, the Mono project or anything else related to that up to now. I actually already stated that I like the language, and find the idea pretty useful, if with a few technical limitations.

Now, let’s get back to what the problem is: the not-very-descriptive error message that I get from the mono debugger (that thread_db, the debug library provided by glibc, couldn’t be initialised) is due to the fact that glibc tries to check if the NPTL thread library is loaded first, and to do that it tries to reach the (static!) variable nptl_version. Since it’s a static variable, nm(1) won’t be able to see it, although I can’t seem to find it with pfunct either; to be precise, it’ll be checking that the version corresponds too, but the problem is that it’s not found in the first place.

Debugging this is pretty difficult: the mono-debugger code does not throw an exception for the particular reason that thread_db couldn’t be initialised, but simply states the obvious. From there, you have to backtrace manually in the code (manually at first because mono-debugger ignored all the user-provided CFLAGS, included my -ggdb to get debug information!), and the sequence call is C# → C (mono-develop) → C (thread_db) → C (mono-develop) → C# → C (internal libbfd). Indeed it jumps around with similarly-called functions and other fun stuff that really drove me crazy at first.

Right now I cut the chase at knowing that libbfd was unable to find the libpthread.so library. The reason for that is still unknown to me, but to reduce the amount of code that is actually being used, I’ve decided to remove the internal libbfd version in favour of the system one; while the ABI is not stable (and thus you would end up rebuilding anything using libbfd at any binutils bump), the API doesn’t usually change tremendously, and there usually is enough time to fix it up if needed; indeed from the internal copy to the system copy, the only API breakage is one struct’s member name, which I fixed with a bit of autotools mojo. The patches are not yet available but I’ll be submitting them soon; the difference with an without the included libbfd is quite nice:

flame@yamato mono-debugger-2.4.2 % qsize mono-debugger
dev-util/mono-debugger-2.4.2: 25 files, 21 non-files, 4944.144 KB
flame@yamato mono-debugger-2.4.2 % qsize mono-debugger
dev-util/mono-debugger-2.4.2: 25 files, 21 non-files, 2020.972 KB

In the package there is also an internal copy of libedit; I guess because it’s not often found in distributions, but we have it, and on Gentoo/FreeBSD it’s also part of the system, so…

Now, no doubt that this hasn’t brought me yet to find what the problem is, and it’s quite likely that the problem is Gentoo specific since it seems to be working fine both on my Fedora and other systems. But is the right move for the Mono team to diss off a (major, I’ll have to say) developer of a distribution that isn’t considering removing Mono from their repository?

Alex Legler: LinuxTag: Booth Review

Alex Legler (a3li) — Fri, 03 Jul 2009 17:52:46 +0000

Today: CentOS

I like it though, except the poster at the back on the ground :-/
Gravity always prevails…

(from http://lists.centos.org/pipermail/centos-promo/2009-July/000529.html)

Greetings to our booth neighbours

Diego E. Pettenò: In the land of smartcards

Diego E. Pettenò (flameeyes) — Fri, 03 Jul 2009 11:49:26 +0000

Even though I did post that I wanted to get onto hardware signatures I ended up getting an USB smartcard reader for a job that requires me to deal with some kind of smartcards; I cannot go much further on the matter right now though, so I’ll skip over most of the notes here.

Now, since I got the reader, but not yet most of the specifics I need to actually go on with the job, I’ve been playing with actually getting the reader to work with my system. Interestingly enough, as usual, the first problem is very Gentoo-specific: the init script does not work properly, and I’m now working on fixing that up.

But then the problem is to actually find a smart card to test with; in my haste I forgot about getting at least one or two smartcards to play with when I ordered the device, and now it’d be stupidly expensive to order them. Of course I’ll go around this time and get myself the Italian electronic ID card (CIE), but even that does not come cheap (€25, and a full morning wasted), and I cannot just do that right now.

So I went around to see what I had at home with a smartcard chip, after discarding my old, expired MasterCard (even though I thought about it before, I was warned against trying that), I decided to try with a GSM SIM card, which I had laying around (I had to get a new one to switch my current phone plan to a business subscriber plan; before I was using a consumer pre-paid plan).

Now, although I was able to test that the reader detects and initialises the card correctly (although it is not in the pcsc-tools database!), I wanted to see if it was actually possible to access it fully; luckily the page of a Gentoo user sent me to some software, written by an Italian programmer, that should do just that: monosim which, as you’d expect, is written in C# and Mono, which is good given I’m currently doing the same for another customer of mine.

Unfortunately, it seems like the mono problem comes up again: upstream never considered the fact that the libpcsclite.so ABI changes between different architectures, even on the same operating system. Not that I find that a good idea in general, since I always try to stick with properly-sized parameters (thanks stdint.h), but it happens, and we should get ready to actually resolve the problems when they appear.

Now, I really don’t even want to get started with all the mess that RMS have uncovered lately; just like I did a few years back, I replace the idealistic problems from Stallman with technical limitations, see for instance my post about “the java crap” (which – by the way – hasn’t finished being a problem, outlasting the idealistic problems).

And I’m still waiting for Berkeley DB to finish its testsuite, after more than twelve (12!) hours, on an eight core system, with parallel processes (I get five TCL processes to hog up the same amount of cores at almost any time). I don’t even want to think how long it would take on a single-core system. Once that’s done, I can turn the system down for some extraordinary maintenance.

Diego E. Pettenò: How _not_ to fix GCC 4.4 bugs

Diego E. Pettenò (flameeyes) — Thu, 02 Jul 2009 22:53:16 +0000

So with GCC 4.4 and glibc 2.10, C++ support went, once again, stricter. Now, leaving aside all my possible comments on a language for which there is still an absolute vacuum of actual implementations years after publishing, let just look at what the problem is this time around.

The main issue, in which glibc 2.10 is also related, is that the C-style string functions now return pointers with the same constant modifier as they are given; so if you look for a characters in a constant string, it’ll return a constant string pointer, and vice-versa if you give it a variable string, it’ll return you a variable string pointer (more here if you’re bored).

This means that the following code will build fine with either GCC 4.3 or glibc 2.10 but will fail when both of those (or more recent) versions are used:

#include <cstring>

int main() {
  char *foo = strchr("ciao", 'a');
}

% g++-4.3.3 test-const.cc -o test-const    
% g++-4.4.0 test-const.cc -o test-const 
test-const.cc: In function ‘int main()’:
test-const.cc:4: error: invalid conversion from ‘const char*’ to ‘char*’

The error from the compiler is quite real: you’re mixing up different type of variables, although in this particular instance you’re not doing anything wrong with it, but for instance take the following code rather than the one shown earlier:

#include <cstring>

int main() {
  char *foo = strchr("ciao", 'a');
  *foo = 'e';
}

This code is trying to change something that it shouldn’t; in particular, given the pointer is now pointing inside a literal, which is then inside the .rodata section of the ELF and in a shared, non-writeable area of memory, when executed this will cause a segmentation fault (a crash, for those not used to this terminology). But it can get less obvious and more sneaky, since instead of a literal, you could have a parameter, declared constant.

Of course, whenever you have a variable or a parameter that is declared constant, but is not actually residing in read-only memory areas (like .rodata), you’re just a cast away from having it non-constant. But then you’d be seeing the cast, and that would be like a yellow light sign. On the other hand, with the old method of just having the function cast away the constant modifier, it was less obvious at first sight.

Okay so we know what the problem is, why the error was introduced, let’s go down to business with what the problem is. I have seen more than a few patches out there that, to make software build on GCC 4.4/glibc 2.10 simply cast away the constant modifier, C-style:

#include <cstring>

int main() {
  char *foo = (char*)strchr("ciao", 'a');
}

This is wrong. You should not do that. Why? Because you’re hiding a problem; in more than half the cases, the solution is simply to change the declaration of the variable:

#include <cstring>

int main() {
  const char *foo = strchr("ciao", 'a');
}

Of course, this does not cover all the cases; there are a few when the pointer is actually used to change memory areas. In those cases, since fixing the issue might be overkill, I’d highly suggest a different syntax:

#include <cstring>

int main() {
  char *foo = const_cast<char*>(strchr("ciao", 'a'));
  *foo = 'e';
}

This uses the explicit const_cast keyword from C++, and the very fact that it’s an eyesore in the code should be enough to scream “Workaround!”, which is what it is in truth.

So please, don’t just cast it away C-style, give it a bit more thoughts, please!

Luca Barbato: New Council - Expectations?

Luca Barbato (lu_zero) — Thu, 02 Jul 2009 17:23:24 +0000

Ok, we got a new council, I'm still there so thank you for renewing the trust on me =)

Looks like that less people found me or what I did that compelling to make me into the council, so surely I did something wrong. Solar got the first place so his cleanly cut ways are perceived better.

I started polling people about what they feel about Gentoo and what they'd like. The first thing I noticed is that people are sick of endless discussions on marginal stuff and even more sick of outside projects trying to push it's agenda on Gentoo using the shovel-in-throat way.

Second item is about trying to make the place nicer for everybody and better involve our large userbase. We used to be the nicest distribution regarding attitude towards newcomers and slow learner, now other distributions are better. We could re-learn from them.

That's what I perceived so far. As I said before I see the council just as the last resort to get something decided if we, developers, cannot find a large agreement. Solar likes more to be proactive in my opinion. You liked him so I guess we as council should try to push people express themselves and get new&interesting stuff done instead of discussing which is the new way to define a quantity next to infinity or why embedding information somewhere is right or wrong in theory.

That said, how wrong I am so far and how we could get Gentoo to improve even more?

Original post blogged on b2evolution.

Christian Faulhammer: Writing a user guide for GNU Emacs

Christian Faulhammer (fauli) — Thu, 02 Jul 2009 09:12:51 +0000

Some time ago a user approached us and asked about a user guide...we told that it was a good idea and he should start writing it as we weren't too motivated to get that started. Marc Murphy provided a basic guide and extended it over the months to come but the Emacs team did not move to review it or whatever. Today I quit being a slacker, updated the guide a bit and added it to our official Emacs repository for everyone to see. It is not publishable but a good start and if something is missing or wrong, please point that out via Bugzilla or by direct email to the Emacs team. If you can provide patches we would be lucky, but also some unformatted text is welcome, we can integrate it into the GuideXML document.

Edit: There is a HTML version to make proof-reading easier. Yes, I know the image is missing and yes a lot of information is also still missing.

Diego E. Pettenò: Does as needed link make software faster?

Diego E. Pettenò (flameeyes) — Wed, 01 Jul 2009 23:48:43 +0000

Christian Ruppert (idl0r) asked me today whether --as-needed makes software faster or smaller. I guess this is one of the most confusing points about --as-needed; focus of tons of hearsay, and with different assertions all around the place. So I’ll do my best to explain this once and for all.

In perfect conditions, that is, if --as-needed were not doing anything at all, then it wouldn’t be changing anything. The flag is not magical, it does not optimise the output at all. The same exact result you would have if libtool wasn’t pushing all crap down the line, and if all the build systems only requested the correct dependencies.

When it does matter is when overlink is present. To understand what the term overlink refers to check my old post that explains a bit what --as-needed does, and shows the overlink case, the perfect link case, and what really happens.

Now, of course you’ll find reports of users saying that --as-needed makes software faster or smaller. Is this true, or false? It’s not easy to answer one straight answer because it depends on what it’s happening with and without the flag. If with the flag there are libraries loaded, directly and indirectly, that are not used (neither directly nor indirectly), then the process spawned from the executable will have less libraries loaded in the address space, and thus both be faster to load (no need to read, map in memory, and relocate those libraries) and smaller in memory (some libraries are “free” in memory, but most will have relocations, especially if immediate bindings (“now” bindings) are used, like happens for setuid executables.

Indeed, the biggest improvements you can have when comparing the with and without cases in a system, or in software, that uses immediate bindings. In that case, all the symbols from shared objects are bound at load, instead than at runtime, so the startup time for the processes are cut down sensibly. This does not only involve hardened systems, or setuid binaries, but also applications using plugins, that may be requesting immediate bindings (to reject the plugin, rather than aborting at runtime, in case of missing symbols).

Sune Kloppenborg Jeppesen: MMC card and suspend problems

Sune Kloppenborg Jeppesen (jaervosz) — Wed, 01 Jul 2009 06:01:14 +0000

After having encrypted my home partition as described here I encountered a strange problem. After each time I suspend to RAM all partitions on the MMC card are gone.

I'm running Gentoo sources 2.6.29-r5. I also tried Tuxonice sources 2.6.24-r9 but it has the same special effect. My MMC controller is the Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter. Perhaps suspend is just broken for it or something with my config is not right:(

So for now I'll just have to live without suspend to RAM and ensure that it doesn't do suspend to RAM as a powersaving measure.

Gilles Dartiguelongue: How to ease maintainance a bit

Gilles Dartiguelongue (eva) — Mon, 29 Jun 2009 22:38:02 +0000

A foreword, this post is mainly aimed at fellow devs or people doing a lot of ebuild work.

As many of you might know, bumping ebuilds is often not the hardest thing to do but to ensure a good QA, a number of little things have to be checked. There are various ways to go with QA, in no specific order:

build with stricter package manager settings than usual (think FEATURES="test stricter")
carefully read/grep throug build.log (a lot more tedious)
verifying some files don't contain known bugs (gtk-doc, intltool)
check that the user just gets the locales s/he asked for
check that no lib is using a built-in when it should use a system lib
check that RDEPEND/DEPEND actually match what the ebuild needs

and there is obviously a lot more that could go wrong that you don't always think about. Sure that's what ~arch and the infamous tinderboxes are for, some might say, but what if you could check for most of this with no extra cost for you than renaming the ebuild and trying to build it. Here comes the portage hooks (don't know if other PM supports this).

Let's take a real world example, recently intltool had a seriously buggy release (filled as gentoo bug #577133) and now most upstreams using intltool are shipping tarballs with these broken rules. With portage hooks, I wrote a little snipped that would tell me if there was not enough or actually too much locales installed for a given LINGUAS setting (ok that's not exactly it, but let's say it works this way). Then collected a list of md5sum of problematic files and wrote the following in /etc/portage/bashrc:

#!/bin/bash post_src_prepare() { if [ ! -e "${S}/po/Makefile.in.in" ]; then return 0 fi checksum=$(md5sum "${S}/po/Makefile.in.in" | cut -f1 -d' ') tempfile=$(tempfile) cat >> $tempfile <<EOF 26d0fa167a5a49e7f2b57b99d08c6586 f81285d13b63167be6981aad0e1a2038 955fb57559c7d112f749e185fc34e07f EOF if grep -q "$checksum" $tempfile; then eerror "Bad intltool rules detected" die "Bad intltool rules detected" fi }

And then any package using those bad rules will just die after src_prepare. No wasted time building broken stuff anymore. This example is obviously not perfect, yadi yada, but it's just here to show a lot can be achieved without touching portage code directly. Actually interesting tests would probably be gladly integrated into a PM so don't hide it if you write some. I'll try to drop a rewrite of this using my git hooks model in my dev space if there is interest in it.

Original post blogged on b2evolution.

Robert Buchholz: LinuxTag kudos!

Robert Buchholz (rbu) — Mon, 29 Jun 2009 07:30:29 +0000

LinuxTag 2009 is over. I slept 12 hours after that, slightly less than the total of sleep I got throughout the four days. But it was amazing. There’s so many people I have to thank that made this a unique experience. Here’s my attempt at a partial list. Thanks to…

All visitors for keeping us busy through discussions, compiling buttons together, and by accepting all our sneaky attempts to hand out flyers.
Gentoo e.V. for covering the costs for printing flyers, buttons, banner, sweets and drinks.
Alex Legler for designing the flyers, the banner, making sure they get printed in time, and manning the booth.
Sebastian Pipping for designing both the t-shirts and word cloud with me, and giving valuable of feedback on the booth presentation. He also organized sweets and the diner table of Tuesday evening.
Christian Faulhammer for manning the booth longer than anybody else; he helped out throughout all four days, from the first minute until his train left.
Tobias Scherbaum for approving all our funding requests; being there even at a busy time and organising the two Gentoo book samples.
Wernfried Haas and Claudia, for creating and hanging up the great Larry prints again. What would a Gentoo booth be without them?
Sebastian Dyroff for driving all the boxes to the exhibition grounds and back to my place, and staying at the booth for quite a while.
Luca Barbato for being around every now and then, while not busy at the ffmpeg booth.
Florian Streibelt for fixing the presentation machine, providing some hardware on short notice and his booth service.
Daniel Sturm for lending the button machine and buying all supplies, and manning the booth.
Fabian Groffen for taking the long drive from the Netherlands, and work the booth despite partying.
Valentin Haenel for being at the booth on Saturday.
Torsten Schmits for manning the booth on Friday. (Hope you get better soon!)
Björn Tropf for preparing the flyer with Alex and being there two days.
Gordon Malm for proof-reading and improving the flyer.
Tobias Kral and an unknown messenger for getting the stickers and mouse pad to the event.
Benedikt Böhm, Christian Parpart, and Hanno Boeck for stopping by at the booth and saying hello.
All LinuxTag helpers for all the work they did, including full-time catering. Special thanks to Daniel, Sebastian Pipping and Fabian for participating in that.
All corporate sponsors of the event, they paid for catering and parts of the Social Event.
Fedora for the free pizza on Friday.
Ubuntu Berlin for the barbeque on Saturday.
All those who offered help for next year. We will come back to you, LinuxTag 2010 is June 9 to 12.

Let me finish with a few bytes of statistics. There were more than 10 000 visitors, we sold 39 t-shirts, drank 34 bottles of Mate and 10 bottles of water, and ate 3 kg of sweets. Ohh, and here’s us again:

Last row, from the left: rbu, grobian, sping, fauli behind dertobi123, a3li, Claudia and amne. Front row: Florian, Sebastian Dyroff, Dan Levin.

Nathan Zachary: OpenBox3 HOWTO goes "official"

Nathan Zachary (kalos) — Sun, 28 Jun 2009 20:23:35 +0000

I just received word from Josh that the OpenBox3 HOWTO that I started writing quite a while back is now in the official Gentoo documentation repository! Josh went through and made some changes to the draft version, and as far as I can tell, they were:

Commented out ~arch applications in order to stick with the stable branch
Removed the notes about mixing stable/unstable branches
Some syntactical changes to my XML

So, if you have a desire to try a really neat window manager with few dependencies and that offers a huge amount of customisability, feel free to read the OpenBox Guide

Thank you Josh!

|:| Zach |:|

Luca Barbato: LinuxTag - day after

Luca Barbato (lu_zero) — Sun, 28 Jun 2009 14:41:07 +0000

I'm eventually back home, I'm dead tired, the c-base party was great in many ways (people, food, place) and ending the night (actually starting the morning) playing Go with beer and music was _quite_ fun (thanks again for the games =))

I'll try to wrap up everything in a short post before falling asleep completely: the LinuxTag had been a wonderful experience I had been more there as FFmpeg developer and less as Gentoo developer (mostly because I had to man the FFmpeg booth mostly since we aren't that many and that I failed to chat in a proficuous with the gentoo people even if we spent the evening in the same place most of the time =| In the end I had a refreshing conversation about Gentoo with rbu luckily and I managed to chat a bit more with fauli just before he was leaving...)

Was quite fun going at the end of the event to the fsfe stand to do explain the FFmpeg stance about patents, Theora (more will follow) and why, in our humble opinion at least, isn't correct to propose^Wactually shove down to the web users throat such codec just because of some claims that are yet to be validated...

The discussion was quite pleasant mostly because to my surprise fsfe people there weren't zealots, so the whole discussion discussion even evolved to touch more interesting topics, like reverse engineering, making sure our license is respected and actually multimedia, with a brief discussion on containers, codec and streaming (that part actually started from an explanation why Theora isn't that perfect fruit of opensource that is claimed and why Ogg has many
shortcomings as container and why in multimedia you do not have one-size-fit-all solutions... )

Original post blogged on b2evolution.

Tobias Klausmann: New stuff, good stuff

Tobias Klausmann (klausman) — Sun, 28 Jun 2009 11:54:50 +0000

Recently, a few larger packages on alpha have seen major updates. There are caveats here and there. Thus, I'll point them out in this post.

xorg-x11-7.4 and xorg-server-1.5

After long last, we've stabilized xorg-server-1.5 and xorg-x11-7.4 (plus their dependencies, naturally). The largest blocker for this was the lack of kernel support for PCI accesses on alpha. Since 2.6.30 fixed that and due to the pressure from the X11 guys to get rid of old versions (and sundry other packages), we moved to 2.6.30 as stable vanilla kernel and .29-r5 as stable gentoo-sources.

However, not everything is peachy. The glint driver, which is used for the Permedia cards that came with many earlier PCI-only Alphas (like the 500au and XP1000) does not work. There's a bug report (freedesktop bug #21546, referenced from g.o bug #268626) but no X11 dev has seen fit to react to it. I've been told that the failure is the result of a changing API and a lack of update to the glint driver. If you do use such a card and want to use recent X11 I suggest bugging the X11 people about it; ideally, via the report mentioned above.

Regarding Kernel 2.6.30, there have been reports of SMP compile failures on LKML, but I have been unable to reproduce those. Feel free to bug me if you encounter them.

glibc 2.9

A few minutes ago, I stabilized glibc-2.9_p20081201-r2 for Alpha. It has been running on all of my alphas for a while now, without any noticeable flukes (besides one, which I'll detail below). Armin76 has rebuilt his testing chroot with it and found no errors either, so I'm quite sure this'll work out nicely.

The one caveat isn't a bug in glibc per se but actually one in Netfilter. Under certain circumstances, a race condition can be triggered in Netfilter which results in a silently dropped DNS packet which in turn results in a timeout when connecting. I noticed this a few months ago and hunted it down.

The main ingredients are: a machine running a glibc of the 2.9 series, an SMP Netfilter machine and low latency between the two. What happens is that newer glibc resolvers rapid-fire the two requests (ipv4 and ipv6/A and AAAA) that are triggered by gethostbyname(). Due to the specifics this sometimes triggers a race condition in the Netfilter code it traverses on your router/firewall. The easiest solution right now is to add "options single-request" to your resolv.conf. This will make lookups slower but not perceptibly so unless you do a really large number of them per second. If you occasionally experience delays when connecting (typically with SSH) and it's not a delay on the other side, you might want to try the fix described above. Details on the bug can be found in my post to net-devel.

The fix to Netfilter is very much the opposite of trivial, I am told. And even if it were fixed tomorrow, it would take quite a while to phase out the old code.

Sebastian Pipping: Gentoo t-shirts: the black one

Sebastian Pipping () — Sat, 27 Jun 2009 23:45:34 +0000

For LinuxTag 2009 we had three t-shirts for sale:

White
Black
Larry

Robert’s blog post shows Larry and White. Here’s a front shot of the black one to complete the collection:

Nathan Zachary: OpenBox HOWTO updated

Nathan Zachary (kalos) — Sat, 27 Jun 2009 20:40:11 +0000

Since I had a little bit of extra time today, I decided that I would make some minor changes to my OpenBox3 HOWTO. Though it has not yet been committed to the official documentation repository, I do think it is finally in a "publishable" state. The changes that were made to this third draft from the second one were:

Fixed some grammatical errors
Updated package list information
Added note about keywording/unmasking packages
Changed xorg-x11 references to xorg-server
Added a nicer example of menu.xml entries

I'm still wanting to add some links to the relevant portions of the Handbook for the sections on keywording and unmasking packages. However, when I try to link to the Gentoo Handbook which is broken down in specific chapters and sections ("perfect for online viewing"), I get XML parsing errors regarding the equal signs contained in the links. For instance, the URL for keywording section is:

gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=3#doc_chap2

Also, I should note that the draft on my Gentoo Developer page is NOT current. I will update it as soon as I can, but I don't have my keys on this work laptop.

That's all for now, and I hope you all have a wonderful day!

|:| Zach |:|

P.S. Just for reference, the previous drafts and the progress of my OpenBox3 HOWTO can be found in Gentoo Bug #256693.

Ben de Groot: Qt 4.5.2 changes

Ben de Groot (yngwin) — Sat, 27 Jun 2009 18:48:01 +0000

This is basically a heads-up for Qt users on Gentoo. We are about to add the new 4.5.2 release to portage. With this release we have changed a few things. We no longer have certain useflags enabled by default that are already enabled by the desktop profile. This means that if you are not using the desktop profile, you should look if any useflags have changed and decide which ones you want to enable. Or otherwise, that you no longer need to disable them if you want a minimal install.

We also have removed the need for the libX11 dependency in qt-core and a couple of other non-gui modules. So you can now for example have a server-only install of quassel with minimal dependencies. The libX11 dependency is now only pulled by packages that really need it.

Another thing that changed is that we dropped the custom-cxxflags useflag. After a long period of testing we haven’t come across any problems with “advanced” cxxflags in Qt 4.5, so now we always let the Qt modules be built with the user-specified flags. As this is an eclass level change, this means also users of the stable branch will see this change. An emerge --newuse world will trigger a recompile of Qt, but this means you will get better optimizations.

Diego E. Pettenò: PulseAudio and quirks

Diego E. Pettenò (flameeyes) — Fri, 26 Jun 2009 10:04:37 +0000

Seems like even my previous post about PulseAudio got one of the PA-bashers to think I’m a nuisance for their “cause”, whatever that is. For this reason I’d like to try to explain some of the quirks regarding PulseAudio, distributions, quirks and so on. Let’s call this a bit of a backstage analysis of what’s going on about Linux and audio, from somebody that has little vested interested in trying to roll the thing for PulseAudio.

The first problem to address relates to the comments that KDE people find PulseAudio a problem; I guess this has to be decomposed in a series of multiple problems: Lennart is a GTK/GNOME guy, so he obviously provided the original tools for GTK/GNOME. For a while I was interested in writing the equivalents for KDE (3) but I never had the time; now that I also moved to GNOME independently, I sincerely have no intention to write KDE tools for PA… but one has to wonder why nobody in KDE went out of his/her way to try doing this before. It’s not like it had to be part of KDE proper, it would have been okay to be an unofficial standalone application.

There is also another problem: most of the KDE guys who do see problems with PulseAudio are most likely using Phonon with xine-lib backend, configured to use the PulseAudio output plugin. Given I’m the one I wrote most of it originally, I can say that it sucks big time. Unfortunately I have had no time to work on that lately, I hope I might have that time in the future, but the two years I spent between hospitals seriously indebted me to the point I’m doing about 18 hours of work a day on average. For those who do want to use xine-lib with Pulse, I’d like to suggest the long route: set up the ALSA Pulse plugin, and then let xine just use ALSA.

There is of course another problem for KDE: while GNOME historically had no problem with force in dependencies that are Linux-specific or that work most of the time just on Linux (think about HAL adoption for instance), and relied on the actual vendors to do the eventual porting, KDE strives to work most of the time on multiple operating systems, including as of KDE 4 also Mac OS X and Windows. Now you might like this or not, but it’s their choice; and the problem is that while there is some kind of PulseAudio support for Windows, at least OSX is pretty badly shaped (also on my radar).

For what concerns distribution support, it is true that Lennart usually just care about Fedora; you have to accept this as part of the deal given RedHat is – as far as I know at least, Lennart feel free to correct me if I’m wrong – the one vendor paying his bills. Now of course we’d all love to support all the distributions at the same time, but the only way that’s possible is if multiple maintainers do coordinate; I’ve been doing my best to pass all the patches upstream when I’ve added them to Gentoo, and I see Colin Guthrie from Mandriva doing the same. One thing I can “blame” Lennart for (and I told this to him before, too!) is not creating a GIT branch with the cherry-picked patches he applies on the Fedora packaging for us to pick up… and the fact that he doesn’t like neither making releases or leaving access to others to do so.

To be honest, there is little different in this from what other projects do with distributions like Ubuntu when they are paid by Canonical. I think this is obvious, everybody looks at their little garden first. But this is not something that should concern us I guess. Gentoo has been quite out of the loop for what concerns PulseAudio, and I’m sorry, that was mostly my fault. I’m doing my best to let us update as soon as possible, but it’s not just that simple, as I already explained .

Then let me just say something about Lennart’s refusal to support system mode (which is available and advertised in Gentoo since PulseAudio entered the tree): I can’t blame him for that. First, his design for PulseAudio is based on providing something that works for the desktop use case. Something along the lines of Windows’s or OSX’s audio subsystems, neither of which provide anything akin to system mode. And indeed PulseAudio, by design, can handle the same situations, including multi-user setups with fast user switching. The fact that a system mode exists at all is due to the fact that I for one needed something like it on my setup, hacked it around for Gentoo, and then Lennart made my life easier implementing some extra bits on PulseAudio proper, but it was certainly not his idea.

What people complain about usually is the need for an X session (not strictly true, PulseAudio will start just fine in SSH — it would probably be possible to even fix it up so that it would tunnel audio just like you can tunnel X!), and the fact that audio does not continue to work when X exits (also not strictly true, if your audio player is running in screen it would be working just fine; it’s the fact that the media player crashes that makes your audio stop). Additionally people complain about the security problem of wanting to have all the processes to run under the same user, rather than allowing them to be on different users, like mpd.

Well, some complains are valid, other are not: it is true that PulseAudio does not work in multi-seat-multi-user environments, at least not with a single audio device, it is unfortunate and I don’t know if it’ll ever do work in that situation without a system mode. It is also true that running processes as different users for privileges separation does not work without system mode. But both these options are walking quite away from the the desktop design that PulseAudio is implementing; sure they are valid use cases, just like embedded systems (Palm Pre uses PulseAudio if you didn’t notice that before), but they are not what Lennart is interested in himself; at the same time I don’t think he’d be stopping anyone to improve the system mode support for those, as long as it wouldn’t require the desktop setup to make compromises.

Because the idea is, as usual in any software design, the one that you have to take compromises; Lennart wants the best experience for what concern desktop systems, and he compromises that system mode is not part of his plan, and it shouldn’t be hindering him. At the same time, while he does get upset when people ask for support about it, and he wrote why it’s not supported he hasn’t removed it (yet — if I was him, at this point I could have just removed it out of spite!). So colouring him as the master of evil does not seem the very best idea — and especially that makes me picture him in the part of Warren in the Trio, from Buffy’s season six.

Oh and a final note: it doesn’t have to surprise that Lennart and Fedora don’t care about running mpd and other services as different users, there are probably quite a few reasons for this. I cannot speak for Fedora, given I’m not involved in it, but my suppositions are that firstly the ALSA dmix plugin is somewhat scary from a security point of view (for me too) because it uses shared memory between processes from different users to do the mixing, and the second is that Fedora does a lot to use SElinux even on standard desktops. This is much tighter than separating privileges with different users since it forces the processes to behave as instructed. Unfortunately on Gentoo the SElinux support seems to have gone for good, at least to me.

Alex Legler: LinuxTag: Day 3

Alex Legler (a3li) — Fri, 26 Jun 2009 09:59:27 +0000

Time flies and so here we already are on Day 3 at LinuxTag in Berlin. We are almost sold out on T-Shirts, lots of people are running around with a Gentoo button on their shirt and we are sitting in “Larry’s Hackcenter”, stabilizing packages and wrangling Security bugs.

Some pictures:

Fauli and sping approve of Gentoo

Windows Server 2008 running Gentoo Prefix, yay!

How did Knurt the Flying Saucer get there?

Robert (rbu) operating the button machine.

The view from Larry's Hackcenter to the rest of the world.

Christian Faulhammer: We are looking for distfiles

Christian Faulhammer (fauli) — Thu, 25 Jun 2009 10:40:31 +0000

The Emacs team is collecting ancient and normally obsolete tarballs we once provided. We collected a lot of them already but are still missing some. So if you have one of the following in your DISTDIR, please mail them to us (emacs@g.o):

~~ebuild-mode-1.0.tar.gz~~
~~ebuild-mode-1.1.tar.gz~~

If you by any chance used the Emacs overlay and installed some packages from there, we are still looking for:

~~ebuild-mode-1.4.tar.bz2~~
~~emacs-daemon-0.3.tar.bz2~~
~~emacs-daemon-0.4.tar.bz2~~
~~emacs-daemon-0.5.tar.bz2~~
~~emacs-daemon-0.6.tar.bz2~~
~~eselect-emacs-0.1.tar.bz2~~
~~eselect-emacs-0.2.tar.bz2~~
~~eselect-emacs-0.3.tar.bz2~~

Thanks to flameeyes and Frank Krömmelbein for providing all of them.

Diego E. Pettenò: How to improve releases quality: working on PulseAudio 0.9.16

Diego E. Pettenò (flameeyes) — Thu, 25 Jun 2009 10:13:15 +0000

Just when I said that I was resuming my work as a PulseAudio maintainer in Gentoo, Lennart released a 0.9.16-test1 tarball. This was my cue to enter the scene upstream: the first test at packaging this in Gentoo failed, for a series of different reasons, some of which are internal (we don’t have the latest version of udev available yet, I hope we will by the time PulseAudio 0.9.16 final is releasd), but most are due to upstream changes that didn’t take into consideration some corner cases that Gentoo, as usual, gets to deal with.

So you won’t see the test1 (rc1) ebuild in the tree at all, you’ll probably have to wait for test2, and even that will require some work. For now I’ve fixed all the build- and run-time issues I’ve seen in the released tarball and git repository; plus I’ve been able to get it to properly build fully on both (Gentoo/)FreeBSD and OpenSolaris (with Prefix). I haven’t been able to experiment with actually having it playing yet, but it’ll come there at one point.

Unfortunately there are still a few shady details that I or someone else has to take care of. For instance, the tests still fail consistently: last time I tried them I got two failures on Yamato, one related to IPv6 enabled in PulseAudio build, but not enabled for the kernel, resulting in the IP ACL test asseting out (now I’ve fixed it, by warning of the case, and ignoring it as a failure); the other is the mixing test, which fails for everybody because it doesn’t know anything about the 24-bit and 24-bit-in-32-bit sample types; this I extended to support 24-bit, but was unable to do anything about the 24-bit-in-32-bit because I couldn’t grok it properly.

On non-Linux operating systems (FreeBSD and OpenSolaris), I had to work on a few more issues, like implicit declarations (there still is one in OpenSolaris), shadowed names, and of course there is some slight porting to be done, which I have nowhere near finished yet: the shm (Shared Memory) support in FreeBSD is imperfect, and for neither operating systems I’ve implemented the “get process name” function.

Okay I’m not able to provide a 100% porting to all the operating systems out there, but I still think I can do a bit to help out by making sure that PulseAudio won’t need to be extensively patched by all the porters out there. And until Lennart actually gets around merging my patches, you can find all them at gitorious so you can test them.

Christian Faulhammer: LinuxTag 2009

Christian Faulhammer (fauli) — Thu, 25 Jun 2009 10:12:20 +0000

After Robert posted the first photos yesterday, I have to do some status report: We have

a MacBook showing an installation screencast
an Intel machine with a Gentoo installation running Windows in a virtual machine...and in there a Gentoo Prefix
Compile Your Own Gentoo Button, we have all materials and different designs
inspection copies of both German Gentoo books
T-shirts for sale, and they sell great. If you live in Germany you can write an email to rbu, maybe we reorder after the exhibition

We were just filmed by German Linux Magazin, so you can hear rbu and myself talk about our stand a bit (only two questions though) as soon as it goes online. If you are near Berlin come visit us.

Patrick Kursawe: sane-backends 1.0.20, finally.

Patrick Kursawe (phosphan) — Wed, 24 Jun 2009 22:37:41 +0000

Almost two months after sane-backends-1.0.20 appeared upstream I finally managed to complete the first ebuild attempt.

It took me so long because

there were a few internal changes with the new version and I wanted to check if the ebuild is still OK
I made SANE_BACKENDS a USE_EXPAND variable now. So you can see which backends are available and enabled without reading the ebuild or the SANE homepage. Well, and it gets a lot harder to attempt building non-existant backends as some people tried in the past for understandable reasons.
I can't complain about too much spare time and I hardly ever get to do anything that takes more than an hour or two, and I was new to the USE_EXPAND business.

Some frontends (including sane-frontends xscanimage) fail(ed) to compile with this version because a hardly ever needed flag named SANE_CAP_ALWAYS_SETTABLE which was not part of the official API (though in sane.h) has been removed. If you run into problems because of this please let the maintainer of the frontend know, it is not really sane-backends' fault.

Original post blogged on b2evolution.

Robert Buchholz: LinuxTag setup and first day

Robert Buchholz (rbu) — Wed, 24 Jun 2009 14:20:14 +0000

So the first day of the four days of Gentoo at LinuxTag is almost over. It’s a very exciting event, talking to users, visitors, and devs, and in the end we could even convince some unhappy Ubuntu users to try Gentoo. Here’s some pictures of what happened so far.

Pictures were taken by Florian, amne and fauli. The word cloud poster is by sping and me.

Luca Barbato: LinuxTag - day 1

Luca Barbato (lu_zero) — Wed, 24 Jun 2009 09:20:13 +0000

After about 4 years I eventually managed to get there! Today is the first day and I'm actually sort of manning the FFmpeg Booth and from time to time I could happen to be in the Gentoo one as well.

In the FFmpeg stand we are showing BBB high res in a big LCD screen from a small beagleboard. The operating system image is obviously Gentoo as well the other system present showing some jumpy Japanese idol video (not my idea).

See you! (Pictures will come later)

Original post blogged on b2evolution.

Marcus Hanwell: Avogadro Nominated for SourceForge Community Choice Awards

Marcus Hanwell (cryos) — Wed, 24 Jun 2009 03:23:00 +0000

I am very pleased to announce that Avogadro has been nominated as a finalist in the SourceForge community choice awards this year. We are in the "Best Project for Academia" category, and I would like to encourage you to vote for Avogadro.

This is a real honour for all of us, and I appreciate all of you who nominated Avogadro. We are all pushing very hard on polishing Avogadro, getting ready for our 1.0 release. It would be absolutely amazing to see Avogadro win this award, so please vote for us.

There are also some other really nice projects in there too, such as Lancelot, ClamAV, phpMyAdmin and RepRap. So please take a few moments to place your vote, and tell your friends!

Update: You can vote even without a SourceForge account - just enter your email address and verify your vote.

Sebastian Pipping: Gentoo word cloud poster

Sebastian Pipping () — Tue, 23 Jun 2009 00:19:45 +0000

Robert (rbu@gentoo) and I have started playing with wordle.net yesterday and created this Gentoo word cloud with it:

Here’s the SVG source file (licensed under CC-BY-SA 3.0).

We made a 120×70 cm² poster from that for LinuxTag, cutting and glueing pieces together ourselves today. Please excuse the image quality.

3D excerpt view:

Full view, on table:

Gentoo wordle and Robert/rbu:

I’ll try to provide some kind of “sources” (for reproduction of variations at least) next:
Worldle text input

ACCEPTLKEYWORDS ACCEPTLKEYWORDS ccache choice choice choice community community community compilation compilation control customization customization debug distcc documentation documentation ebuilds ebuilds ebuilds empowerment eselect eselect flame~wars FreeBSD GCC GCC Gentoo Gentoo Gentoo Gentoo Gentoo Gentoo Gentoo Larry Layman Linux Linux make.conf make.conf OpenRC optimization overlays overlays overlays package.mask Paludis perfection pkgcore portability portability Portage Portage Portage Portage~Prefix slots source~code source~code source~code speed speed USE USE USE USE USE USE USE USE volunteer~developers webapp-config webapp-config world~file Forums Wiki Summer~of~Code Summer~of~Code Bugzilla repoman USELEXPAND you kernel wireless stage server bash unicode rsync GRUB Foundation sunrise free~software free~software open~source open~source handbook catalyst gentoolkit colors colors baselayout sandbox genkernel etc-update crossdev

Note, that we produces underscores from big “L”s and cutting them down with Inkscape. No, really.

Further wordle settings were:

Font = Meloche RG Bold
Layout = Straight Edges + Mostly Horizontal
Color = Ghostly + A little variance

With a small “patch” for net-print/poster we made it produce pages that overlapped strongly:

--- poster-20050907/poster.c
+++ poster-20050907/poster.c
@@ -949,7 +949,7 @@
            "/posteryb %d def\n"
            "/do_turn %s def\n"
            "/strg 10 string def\n"
-           "/clipmargin 6 def\n"
+           "/clipmargin 150 def\n"
            "/labelsize 9 def\n"
            "/tiledict 250 dict def\n"
            "tiledict begin\n"

For normal posters that’s no use but for our case with words scattered on a white background it allowed flexible cutting of pages so we had to hurt no letters, in hope to produce a higher quality result.

Come by at the booth to see it with your own eyes

Patrick Lauer: Working on stuff

Patrick Lauer (bonsaikitten) — Mon, 22 Jun 2009 18:58:41 +0000

In the last weeks I've picked up a few packages mostly because someone pointed me at them and there were lots of open bugs. I've "inherited" virtualbox like that (although Jokey and X-Drum are still doing an awesome job whenever they have the time), I've mostly taken over xen for now (even though I don't use it at the moment and test it in *ahem* VirtualBox).
Samba is another one of those packages that many people use, but few devs maintain. But it's a lot harder to test, so I mostly leave it alone for now.

So I'm beginning to wonder - what packages are "orphaned", where did users provide and test patches and no dev is around?
How can we improve our response time to users so that they are happy and keep helping us, and how do we notice that a package doesn't get the love it deserves?
My current mechanism for that is quite crude and biased - if I notice enough people complaining I have a look, and if the build system doesn't make me want to get drunk I start playing around with it until a few bugs are closed.
Maybe we need a "Package Fix" team of users and devs?
The users could cooperate on collecting bugs for a "topic" like samba and test them, and the devs can give assistance and then commit the fixes. It would most likely be quite fun to cooperate like this, might be a theme for a bugday - but who has the time for that?

If you have an open bug with a fix that hasn't been committed feel free to Mail Me or drop by in #gentoo-bugs on irc.freenode.net. I can't promise much, my time is limited and sometimes things just don't work out as expected, but still I try. And maybe it gets a few old bugs killed - that would be worth it :)

Diego E. Pettenò: Planning for PulseAudio

Diego E. Pettenò (flameeyes) — Mon, 22 Jun 2009 18:42:28 +0000

Thanks to Betelgeuse I finally have audio again on Yamato (again, thanks! — on a different note, this actually made me find out that there absolutely is a bug in ALSA that causes mmap to kill PulseAudio both with the ICE1712 and the HDA drivers), so I’m resuming my duty as PulseAudio maintainer. This is the reason why PulseAudio jumped to version 0.9.15-r50 in ~arch. So what’s up with that?

My current plans in respect to PulseAudio are trying to get 0.9.15 in stable to replace the ancient 0.9.9. What has stopped PulseAudio to go stable up to this point has been exactly two dependencies: OpenRC and libtool 2.2. Originally, the idea was to keep PulseAudio only compatible with OpenRC and no longer with baselayout 1; it was supposed to go stable pretty soon and the baselayout 1 init script was so scarily incomplete that we simply preferred not have to support it.

Unfortunately, there is still no date for OpenRC to go stable, if it’ll go at all in its current form. At the same time, Lennart has seriously warned against system wide mode (even though there are still valid use cases for which Gentoo often is used!) so keeping the new versions off from stable for a “minor” feature that is not even recommended to be used sounds like a bad plan.

For this reason I’ve now split the ebuild in two versions: one will keep the system mode support, with the system mode warnings, the init script and all the niceties, and the other won’t, and won’t depend on OpenRC at all; the latter is what is supposed to go stable and what stable users should locally unmask if they want PulseAudio.

Let me state again: if you want newer PulseAudio and you’re in stable explicitly request the -r1 version, not the -r50!.

Unfortunately while I should be able to ask for stable right away for what concerns time and bugs, there are a few dependencies, which include libtool 2.2 which is not stable yet (and I think it should be, the tinderbox haven’t found many libtool 2.2 bugs lately and quite a few packages started requiring that, rather than just a generic libtool that 1.5 is compatible with).

I still have no real plans for the realtime support; while Lennart released rtkit (does anybody find it concerning that Linux started having packages with names vaguely similar to those from Apple’s OS X?), it needs a patched kernel, which means I should probably be pestering our kernel team to get those patches included before we can actually provide it, even optionally.

This week I hope to be able to work on mpd too, so that the Gentoo packaging plays nice with PulseAudio (right now the fact that you have to run it with a different user forces you to use a systemwide instance).

Daniel Drake: OLPC Paraguay report & more

Daniel Drake (dsd) — Sun, 21 Jun 2009 22:20:02 +0000

I wrote up a summary of my experience in Paraguay, you can read it on the OLPC wiki.

Last week, I gave a presentation about OLPC in the field at an OLPC UK meeting. It went well and it was nice to meet everyone for the first time. They are planning an exciting pilot deployment in a London school. I’ll leave them to announce the details as things progress.

The development of the XO-1.5 software release is progressing nicely. We have automated builds that work reasonably well.

And now would also be a good time to mention my upcoming plans; on July 18th I will be flying out to Nepal to spend 12 weeks as a volunteer for Open Learning Exchange Nepal, the organisation implementing One Laptop per Child in that country. Exciting!

Diego E. Pettenò: Slimming down the portage tree

Diego E. Pettenò (flameeyes) — Sun, 21 Jun 2009 00:37:45 +0000

So while I’ve got the tinderbox turned off I’ve been taking care of a few different QA duties that I’m probably not supposed to do but I’m sure to help Gentoo. I’m actually pretty sure that this kind of tasks might actually be even more interesting for users than what I’ve been doing with the tinderbox.

While the tinderbox’s main goal is to be able to find the broken software that is in the tree, this usually produces just a lot of work for other developers (bugs to fix) and a few extra side-effects like identifying smaller QA violations and some very broken package that I have been last riting and that will be removed over the course of the next two months.

On the other hand, the manual analysis I’ve been doing tonight aims to check the actual stuff that is added to the tree, like binary files or big files directories. For those wondering why I’m on a crusade against binary files in the tree, I have to say that first of all, CVS makes it difficult to handle binary files, and this makes them unsuitable for being added to the tree. Additionally, binary files in the tree often mean there is something else broken with the packages: compressed big patches (that still keep big) and huge, messed up files directory with unused content, and stuff like that.

I’ve been able to shave a few kilobytes off the tree by moving a few files on the mirrors and removing the big files from the tree; but I’ve also started sending last rites for the packages that have this kind of issues and I don’t see as being ready to be fixed sometime soon. Interestingly enough, it turns out like there is enough cross-over between the packages that fail, that have QA issues and that are polluting the tree with too-big files directories and so on.

So please don’t get mad at me again if I masked for removal a package you use: if you want to keep it in the tree, please get it fixed.

Petteri Räty: Council election manifesto

Petteri Räty (betelgeuse) — Sat, 20 Jun 2009 20:31:44 +0000

As I am running again and finally had some free time and motivation to write some stuff up I wrote an initial manifesto for the on going council elections. It can be found here: http://dev.gentoo.org/~betelgeuse/manifesto-2009.html I will probably continue updating it during the election period if things come to mind.

Original post blogged on b2evolution.

Diego E. Pettenò: New Linux-PAM and pambase

Diego E. Pettenò (flameeyes) — Sat, 20 Jun 2009 19:32:40 +0000

So I noticed tonight that yesterday a new Linux-PAM (in portage as a generic sys-libs/pam, even though I want to change it one day) was released: 1.1.0. I actually was scared that it was a big overhaul, it seems instead to be little more than a feature release of the previous release, so it’s fine.

All my patches from pre-1.0 (as well as the one to disable NIS support when not found) are still outstanding and they still apply cleanly. I guess I’ll have to harass upstream more about them and see that they are applied, maybe for 1.1.1 or something.

At any rate, the new release does have a few interesting changes, like a new pam_tally module that is now wordsize-independent (that is, it works the same way both in 32- and 64- bit configurations), for this reason I’m now preparing a new pambase to make use of it instead of the old one by default if present. Unfortunately I’m finding a couple of issues that make it not easy to solve.

There is another change that might be worth nothing: I have already blogged about the sha512 support that Linux-PAM 1.0.1 has provided us with. Well, with this new release, together with sha512, sha256 and md5 hashing… there’s blowfish!

But pambase is not going to provide a way to enable it. It’s not that I don’t want people to use blowfish, but rather that upstream relies on the crypt() function provided by the C library: when it supports the above algorithms, then pam_unix will support them as well, otherwise, you’re out of luck. Since Gentoo does not provide a blowfish-patched glibc, then it won’t support the blowfish method. Until that time, this post will serve as an answer for those interested in the matter, who think that by just using “blowfish” you can gain stronger hashing.

Since this is a minor version bump (compared to the previous 1.0), I’ve also decided to change a bit the ebuild too; I’ve removed the warnings for pam_userdb and other modules that have been moved in separate packages, since they were only checked for when updating from pre-1.0 versions. I’m almost tempted to remove the safechecks for pam_stack, pam_pwdb, and pam_console; the pam_timestamp checks have been dropped because that particular module, initially present in our older versions of PAM which applied RedHat-supplied patches, is now present upstream.

I’m going to try mediating with Kukuk about the patches we apply, dropping a few, merging a few more. It’s more time spent on stuff I don’t care much about (PAM is something people detest and I don’t really have a good use for it myself), but I guess it’s something that Gentoo needs. As usual, kudos and gifts are very welcome (the latter in particular because with the recent expenses I’ve had to take care of my leisure budget reduced considerably).

Time to get going to work then, I’m afraid I’ll have to bump the pambase version to 20090621, I don’t think I can fix it before night!

Doug Goldstein: Ideas for dm-crypt support

Doug Goldstein (cardoe) — Sat, 20 Jun 2009 07:30:52 +0000

In an attempt to improve cross-distro support, I have been considering for some time now reworking the way the current dm-crypt setup in Gentoo works and making it work more like Debian, Ubuntu, Red Hat, Fedora, and CentOS do. Effectively the syntax they use is that of fstab, however its in a new file called /etc/crypttab. This file is formated in the following style:

/dev/VolGroup00/data    crypt-data    none           luks # Password style LUKS
/dev/VolGroup00/tmp     crypt-tmp     /dev/random    tmp  # sets up /tmp for each boot having a fresh key
/dev/VolGroup00/swap    crypt-swap    /dev/random    swap # sets up swap for each boot having a fresh key
/dev/VolGroup00/other   crypt-other   /dev/sda       luks # uses /dev/sda as the key source

The partitions above would all be referenced by /dev/mapper/crypt-NAME. As you can probably guess the above configuration is not an exhaustive iteration of all the configuration possibilities. I am merely trying to investigate if this is something that people would be interested in before I code it. I’ve had this idea kicking around in my head for over 3 months now (in fact I e-mailed the other base-system maintainers about it at the start of March) but I’m terrible at keeping up with my blog. In fact, I’ve still got some parts of my original council platform from LAST year’s election still sitting there as draft posts.

But back to dm-crypt. For more information, look at the Red Hat crypttab(5) man page. While it says there are no options for LUKS, they have added automatically added checking for LUKS and using that instead of the pre-LUKS crypt bits. That being said, the Debian based version apppears to map bettter for us since it has a lot more options, Debian based crypto crypttab(5). Let me know what you think.

Gentoo News: Gentoo at LinuxTag 2009 in Berlin

Gentoo News () — Sat, 20 Jun 2009 02:02:09 +0000

LinuxTag 2009 runs from June 24th to June 27th in Berlin, Germany. With almost 12,000 visitors last year, it is one of the biggest Linux and open source events in Europe.

You will find the Gentoo booth at Hall 7.2a, Booth 101a, right next to the entrance. Come and visit us! You will meet many of our developers and users, talk with us, plus get some of the Gentoo merchandise you have always wanted.

Discuss this!

Robert Buchholz and Alex Legler contributed the draft for this announcement.

Diego E. Pettenò: Tinderbox suspension for a few days

Diego E. Pettenò (flameeyes) — Fri, 19 Jun 2009 19:21:56 +0000

If you’re following me on bugzilla, or looking at the feed of new bugs reported, or just are watching the trackers for the bugs I usually report most often (gcc 4.4 and glibc 2.10 failures mostly), you might have noticed that I haven’t been opening new bugs for a few days already. Please note that this is not a stable situation, it’s just a temporary setback, caused by – you guess – an hardware failure (you could answer this more quickly if you were following me on identi.ca since I have been writing about it).

This time the problem is the UPS’s battery that have consumed after two and a half years (which actually explains pretty well how it was that this year I won two APC gadgets, after years of filing in questionnaires). As soon as the load reaches 40%, the battery charge result to last for 1 to 3 minutes max, which is not right and certainly not enough to shut Yamato down from a tinderboxing run. I have also to note that the power load on the UPS varies between 27% almost idle, and 60% during full-blown build of all the cores which is what the tinderbox does.

I’ve called my supplier on Wednesday night to order the battery, it’ll arrive to the shop next Monday, but I’ll only be able to pick it up on Tuesday (since I have a work appointment and I’ll be around that place). During this time, I’m trying to keep the load on the UPS to the minimum so that it has at least a few minutes to stop everything down; this obviously includes not having the tinderbox running full time.

Myself, trying not to load the box with my own usage, I’m trying to take a few days to work on my paid job (that requires me to use Merrimac instead, which is on a different UPS, which as far as I can tell, is for now still keeping up), reading and watching a few films I’ve gotten lately and haven’t had time to watch, maybe I’ll be able to play a bit too, but I’m not counting on it much, I have already a full weekend with my job tasks.

In the past ten days I was able to read from cover to cover John Grisham’s The Rainmaker – I don’t particularly like lawyers; I don’t particularly dislike them either. I don’t know why I tent to devour Grisham’s books this way (the first I read, in Italian, The King of Torts, I finished during a whole night!). At any rat eI’m trying to resume my average reading, in 2007 I read 19 books, last year just seven; while of course the reason why I read so many more in 2007 is tied to the 42 days of hospital I went through, and the months that it took for me to recover, I’d like to at least reach 13 books this year. It’s also a sort of way to try cooling off before I burn out.

Anyway, will be back soon.

Thomas Anderson: A Manifesto for the council

Thomas Anderson (gentoofan23) — Fri, 19 Jun 2009 13:24:04 +0000

As you may (or may not) know, I(tanderson/gentoofan23) am running for the Gentoo Council. Like all good kiddies I’ve written up a manifesto which is present on my devspace: here. I explain my vision and hopefully give some people an idea of what I would do on the council. You should of course know by now(if you’ve been a good boy and read -dev, -council, or -dev-announce) that I’ve been the secretary for the council for the past 8 months or so, and I’ve done a lot of the footwork(following up on council decisions and documenting them in developer documentation) so I have a fair idea how the council should operate.

Thanks for reading, and see you around.

Patrick Lauer: A Manifesto

Patrick Lauer (bonsaikitten) — Thu, 18 Jun 2009 18:33:03 +0000

Following everyone else writing a manifesto for the current Council elections I've finally found the time to write one too. You can find it here

I hope that motivates more people to vote. As long as you vote it's good ... come on, it takes all of 5 minutes to vote (and if you really don't care leave the candidates in the random order given by the votify script).

Just to repeat myself, http://dev.gentoo.org/~patrick/Manifesto.html

Tiziano Müller: Manifest

Tiziano Müller (dev-zero) — Tue, 16 Jun 2009 20:25:16 +0000

Since the voting period started, I’d like to give people a bit of information why they should vote for me and those who already consider it an impression of what my plans would be.

The past election period

One of my first proposals was to have a Secretary. Initially I advocated a rotating scheme where every council gets the Secretary job once in a while but since tanderson was kind enough to volunteer we got a “full-time” Secretary who made sure that the summary is available a couple of days after the meeting and who also made sure that decisions where clearly phrased (like the deprecation of eclasses).

From the technical side EAPI-3 was probably the biggest topic I worked on. Thanks to a lot of help from others we finally managed to get the specifications done and are now waiting for the implementation.
Some are surely disappointed that features they advocated for or proposed didn’t get included. The reason is that a line has to be drawn at some point and since we don’t have an EAPI development process the “feature freeze” might have come suddenly for some. Which brings me directly to the plans I have, should the developers trust me once more:

What I would do in the next election period

First I’d push forward the development of an EAPI development process to make the development more transparent. And guessing from the amount of mails concerning new features we shouldn’t wait too long for a new EAPI-4 as well.

From the organizational side I’d like to continue my work on the re-organization GLEP Calchan and I are working on since I believe that a better structure also leads to more fun in development.

In short terms

Vote for me if you want someone who knows how to organize meetings, how to push technical and organizational innovations and actively shapes the future of Gentoo.

Sebastian Pipping: oswatershed.org: One more case for PackageMap

Sebastian Pipping () — Sat, 13 Jun 2009 20:07:38 +0000

At Open Source Watershed Scott Shawcroft is comparing 9 major GNU/Linux distributions for “package freshness” in several dimensions. He compares how software flows down from upstream (say the kernel team) to downstream (say Gentoo) across distributions. To do so there is package mapping in place. Surprise!

His current approach maps certain package names onto others and the rest to itself:

foo3-dev -> foo3
foo3-doc -> foo3
foo3 -> NULL -> foo3

Like packagemap it also involves manual editing. We’re at discussing collaboration details. Stay tuned.

Sebastian Pipping: 1000+ Gentoo packages in PackageMap

Sebastian Pipping () — Sat, 13 Jun 2009 18:46:14 +0000

I count 1011 Gentoo packages in the packagemap repository now. I’m seriuous about packagemap.

Through an extra script it got a little bit easier today for you to join in: To add an entry for package “dev-libs/icu” to the map you

do a quick research about the package’s vendor (and find “ibm”)

decide for a product name (”libicu” here, “lib” prefix for all libraries)

run a script:

cd code/gentoo
./map-package-to-vendor.sh dev-libs/icu ibm libicu

That script creates a packagemap file “database/ibm/libicu.xml” for you, that’s it. The third parameter (the product name) is optional: The package name (”icu” here) would have been chosen without it.

Please consider adding your own Gentoo packages to packagemap yourself this way. I just cannot do it all alone.
Thank you!

Alex Legler: Gentoo at LinuxTag 2009 — Win free tickets!

Alex Legler (a3li) — Fri, 12 Jun 2009 20:31:15 +0000

From June 24 – June 27 there will be the LinuxTag in Berlin, one of the biggest Linux and Open Source events in Europe. Last year, almost 12.000 visitors came to the show, and for this year we hope that even more people will come.

Of course, you’ll find Gentoo on the exhibitors list, special thanks to our main coordinator, Robert Buchholz (rbu) for organizing our presence.

Come visit the Gentoo folks in Hall 7.2a, Booth 101a
(that is right next to the entrance!)

Bring your friends and maybe a little gift for the hard working Gentoo devs. We are looking forward to interesting conversations!

To make the decision whether to come to LinuxTag even easier, here is a chance to…

Win free tickets! *

Here’s the deal: Send an e-mail to a3li <at> gentoo <dot> org with the reason why you should get one of our 5 free tickets.
Mabye you fixed a bug the other day or help our users a lot on IRC, be sure to include that reference.

We will pick the 5 submissions who we think have deserved it most. The competition ends Wednesday, June 17 at 2000 UTC.

The winners will be announced on Planet Gentoo and will receive an email with further instructions to claim the free tickets.

Nochmal auf Deutsch

Gentoo auf dem LinuxTag, vom 24. bis 27. Juni 2009. Ihr findet uns in Halle 7.2a, Stand 101a (gleich am Eingang).

Dazu verlosen wir 5 Freikarten, schreib eine E-Mail an a3li <at> gentoo <punkt> org und sag uns, warum gerade Du ein kostenloses Ticket verdient hast (vielleicht weil Du einen Bug gefixt hast oder anderen Benutzern häufig im IRC hilfst). Die fünf „fleißigsten” kriegen von uns Tickets. * Einsendeschluss ist Mittwoch, der 17. Juni 22.00 Uhr deutscher Zeit.

* There is no right of appeal. / Rechtsweg ausgeschlossen.

Sebastian Pipping: Inviting you to project “PackageMap”

Sebastian Pipping () — Fri, 12 Jun 2009 07:42:50 +0000

Quick (re-)introduction: My task for Gentoo/Google Summer of Code 2009 is to give Gentoo a Debian popcon equivalent, a tool to collect statistics on “what package is installed how often”. To achieve this goal I’m extending Smolt (a tool currently doing similar things with hardware information) by fine-tunable software stats gathering.

The plan we have for Smolt is to make it cross-distro, not just fit Gentoo or Fedora. One point where the consequences and benefits of such an approach can be seen clearly is with

counting packages from different distros into the same buckets.

What do I mean by that? Debian’s Git counts for Gentoo’s Git counts for Fedora’s, you know the list. With packages counted from accross distros we can suddenly answer questions that we currently cannot answer, among them

What globally popular packages are missing in distro X? Let’s say we don’t have a package for product P. Do other distros have one? They do, maybe we need one, too? They don’t, maybe P is not that important then?

How many Linux users are approximately using program X in total? Not just on Ubuntu or Arch - all across Linux, BSD, Solaris!

Does distro X have 10 times the packages of Y or is it just different splitting?

To count into the same bucket we use global identifiers for the “products” that fall out of a package. Gentoo package “dev-util/git” can produce product “cpe://a:git:git”, Debian’s “git-core” can, too. That string before is a CPE name, a concept close to package naming in Java. This “intermediate language” allows us to relate package names from distro X with those of distro Y and answer various questions from that data.

To do such mapping we need code (or a “service”) that does the mapping for us and base of collected data that the service can operate on. Both of these is project “PackageMap”.

I have started populating the database with packages (currently 312 in number) made from information extracted from the Gentoo tree and the National Vulnerability Database. Latter holds many CPEs. Let me state clearly that packagemap is not about Gentoo in particular. Sure, the initial data has lots of Gentoo in it but the whole point of the project is to get information and people from different distros together.

To see what these 312 packages maps look like at the moment you best do a few clicks through the database folder yourself:
http://git.goodpoint.de/?p=packagemap.git;a=tree;f=database

Also, there are Relax NG schema and DTD for validation, more documentation than I usually write and a few scripts:
http://git.goodpoint.de/?p=packagemap.git;a=tree

By now I hope you have gained interest in what this can become.
Your active participation is highly appreciated.
A few minutes from everyone can make a huge difference here.
If you want write access to the repo - mail me: sebastian@pipping.org.

Please have a look at the Git repository and ask questions.

Thanks for reading up to this point.

PS: I’m aware “hartwork.org” might not make a good longterm location for DTDs, XML namespaces and such for a cross-distro project. Any ideas where to put them best?

Sebastian Pipping: Gentoo, GSoC, Smolt, PackageMap

Sebastian Pipping () — Fri, 12 Jun 2009 05:22:46 +0000

One more about GSoC porgress. This won’t be complete or so, just a few more bytes.

I’m in close contact with my mentor (rbu) and Smolt upstream.
A few tiny patches have been accepted by latter already.
I have a smolt server (called “smoon”) running on my local machine that I can submit to.
The Daft Punk live disc “Alive” (2007) rocks, again and again. Okay, not too on-topic.
I have started working on fine configuration of “what you submit” and will continue working on that once sub project “packagemap” reaches a point where it moves without me.
Project “packagemap” needs an extra post as well as a few mails including one to gentoo-dev. Stay tuned.

Sebastian Pipping: TurboGears 2 and Gentoo

Sebastian Pipping () — Fri, 12 Jun 2009 05:07:17 +0000

This is the first post about my progress on GSoC’09 for Gentoo. Also, disclaimer: I’m tired (07:08 here), think for yourself

As a “side product” of my earlier Gentoo GSoC’09 activities a hopefully complete TurboGears 2.x stack has grown in my “sping” overlay. I can understand now why the Python herd has not packaged TG 2.x before:

The unpackaged portion of dependency tree is quite large (see here: dev-python and net-zope)
Many people probably run TurboGears in a virtual env and don’t install it system-wide
g-pypi is a huge help but no way near auto-pilot
<rants about changing upstream tarballs here>

(Talking of g-pypi: an update to app-portage/g-pypi-9999 (sping overlay) brings post-0.2.1 bugfixes!)

To check out the current state of TG2 this is what you might want to do:

sudo layman -a sping
sudo layman -a python-testing
sudo autounmask dev-python/turbogears-meta-2.0
sudo emerge -av dev-python/turbogears-meta

If all goes well that meta package enables you to create and run the quickstart app right away.

But: With so many packages involved something more or less has to be broken for you. Please contact me about it, I’ll be happy to fix what’s needed or pull from you.

Josh Saddler: Benchmarks: gtk+ engines revisited

Josh Saddler (nightmorph) — Fri, 12 Jun 2009 02:47:16 +0000

Six months ago I posted some benchmarks of popular gtk+ engines. It's time to revisit those benchmarks and test the engines again, this time using FOSS drivers for my new hardware.

Today I installed my brand-spankin' new graphics card, an ATI RadeonHD 4550, by Sapphire. Getting working 2D acceleration with EXA was a cinch, now that the 2.6.30 kernel is out. Doesn't require anything special in terms of packages; nothing from overlays or bleeding-edge git checkouts. Only needs three ~arch packages: gentoo-sources, libdrm, and mesa.

For this updated round of testing, I used the same gtk+ engines, but also added some new ones. These can all be obtained by installing the following packages: gtk-engines, gnome-themes, gtk-engines-aurora, gtk-engines-candido, gtk-engines-rezlooks, and gtk-engines-xfce. New to the testing list are the Crux, ThinIce, HighContrast, and Redmond95 engines.

Once again, gtkperf-0.40 was used to obtain these benchmarks. With the exception of the graphics hardware and driver, the testing environment is mostly the same. Xfce has been updated to 4.6.1.

Let's see how all these engines perform on my Xfce workstation, eh?

Notes on the hardware:

CPU: Athlon 64 X2 4600+
Graphics: ATI RadeonHD 4550, DVI 1440x900 @ 60Hz
RAM: 4GB DDR2-667
Mobo: ASUS M3N78-VM

Notes on the testing environment:

OS: Gentoo Linux (duh)
Kernel: Linux 2.6.30-gentoo-r1 #1 SMP PREEMPT x86_64
xf86-video-ati: 6.12.1-r1
CFLAGS: -march=athlon64-sse3 -O2 -fomit-frame-pointer
DE: Xfce 4.6.1
- Xfwm4 with Composite enabled, effects: drop shadows & transparency
- Open applications: 2 instances of x11-terms/terminal

Custom themes are noted with *. These are personal themes I've made, nothing more than simple color modifications of an existing freely available theme. No additional images are used, so rendering time should not be affected.

All tests were conducted 3 times, using a Test Round setting of 100. I picked the best score of the 3, as I was looking for best-case usage conditions. The results are ranked in order from fastest to slowest.

Engine: HighContrast
Theme: HighContrast

GtkEntry - time: 0.03
GtkComboBox - time: 0.63
GtkComboBoxEntry - time: 0.46
GtkSpinButton - time: 0.04
GtkProgressBar - time: 0.02
GtkToggleButton - time: 0.04
GtkCheckButton - time: 0.03
GtkRadioButton - time: 0.06
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.08
GtkDrawingArea - Lines - time: 0.91
GtkDrawingArea - Circles - time: 1.21
GtkDrawingArea - Text - time: 0.89
GtkDrawingArea - Pixbufs - time: 0.11
---
Total time: 4.70

Engine: Rezlooks
Theme: Rezlooks Blue Ink*

GtkEntry - time: 0.05
GtkComboBox - time: 0.61
GtkComboBoxEntry - time: 0.41
GtkSpinButton - time: 0.05
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.06
GtkCheckButton - time: 0.04
GtkRadioButton - time: 0.11
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.07
GtkDrawingArea - Lines - time: 0.94
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.89
GtkDrawingArea - Pixbufs - time: 0.11
---
Total time: 4.72

Engine: Mist
Theme: Mist

GtkEntry - time: 0.03
GtkComboBox - time: 0.65
GtkComboBoxEntry - time: 0.45
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.05
GtkCheckButton - time: 0.04
GtkRadioButton - time: 0.10
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.07
GtkDrawingArea - Lines - time: 0.87
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.91
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 4.72

Engine: ThinIce
Theme: ThinIce

GtkEntry - time: 0.03
GtkComboBox - time: 0.65
GtkComboBoxEntry - time: 0.42
GtkSpinButton - time: 0.07
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.05
GtkCheckButton - time: 0.03
GtkRadioButton - time: 0.07
GtkTextView - Add text - time: 0.19
GtkTextView - Scroll - time: 0.09
GtkDrawingArea - Lines - time: 0.91
GtkDrawingArea - Circles - time: 1.16
GtkDrawingArea - Text - time: 0.88
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 4.72

Engine: Glide
Theme: Glider

GtkEntry - time: 0.06
GtkComboBox - time: 0.65
GtkComboBoxEntry - time: 0.49
GtkSpinButton - time: 0.08
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.05
GtkCheckButton - time: 0.05
GtkRadioButton - time: 0.14
GtkTextView - Add text - time: 0.20
GtkTextView - Scroll - time: 0.09
GtkDrawingArea - Lines - time: 0.85
GtkDrawingArea - Circles - time: 1.20
GtkDrawingArea - Text - time: 0.87
GtkDrawingArea - Pixbufs - time: 0.14
---
Total time: 4.90

Engine: Redmond95
Theme: Redmond

GtkEntry - time: 0.04
GtkComboBox - time: 0.76
GtkComboBoxEntry - time: 0.57
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.02
GtkToggleButton - time: 0.10
GtkCheckButton - time: 0.12
GtkRadioButton - time: 0.13
GtkTextView - Add text - time: 0.19
GtkTextView - Scroll - time: 0.08
GtkDrawingArea - Lines - time: 0.90
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.90
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 5.16

Engine: Clearlooks
Theme: Glossy

GtkEntry - time: 0.02
GtkComboBox - time: 0.77
GtkComboBoxEntry - time: 0.56
GtkSpinButton - time: 0.19
GtkProgressBar - time: 0.12
GtkToggleButton - time: 0.12
GtkCheckButton - time: 0.08
GtkRadioButton - time: 0.11
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.10
GtkDrawingArea - Lines - time: 0.95
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.91
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 5.40

Engine: Crux
Theme: Crux

GtkEntry - time: 0.03
GtkComboBox - time: 0.89
GtkComboBoxEntry - time: 0.75
GtkSpinButton - time: 0.14
GtkProgressBar - time: 0.04
GtkToggleButton - time: 0.05
GtkCheckButton - time: 0.06
GtkRadioButton - time: 0.10
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.12
GtkDrawingArea - Lines - time: 0.90
GtkDrawingArea - Circles - time: 1.16
GtkDrawingArea - Text - time: 0.90
GtkDrawingArea - Pixbufs - time: 0.13
---
Total time: 5.46

Engine: Industrial
Theme: Industrial

GtkEntry - time: 0.05
GtkComboBox - time: 1.13
GtkComboBoxEntry - time: 0.54
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.05
GtkToggleButton - time: 0.15
GtkCheckButton - time: 0.06
GtkRadioButton - time: 0.07
GtkTextView - Add text - time: 0.19
GtkTextView - Scroll - time: 0.15
GtkDrawingArea - Lines - time: 0.89
GtkDrawingArea - Circles - time: 1.16
GtkDrawingArea - Text - time: 0.91
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 5.54

Engine: Aurora
Theme: Aurora

GtkEntry - time: 0.05
GtkComboBox - time: 1.10
GtkComboBoxEntry - time: 0.90
GtkSpinButton - time: 0.20
GtkProgressBar - time: 0.06
GtkToggleButton - time: 0.12
GtkCheckButton - time: 0.08
GtkRadioButton - time: 0.16
GtkTextView - Add text - time: 0.19
GtkTextView - Scroll - time: 0.13
GtkDrawingArea - Lines - time: 0.92
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.89
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 6.08

Engine: Pixmap
Theme: Elegant Autumn*

GtkEntry - time: 0.04
GtkComboBox - time: 1.00
GtkComboBoxEntry - time: 0.80
GtkSpinButton - time: 0.15
GtkProgressBar - time: 0.15
GtkToggleButton - time: 0.22
GtkCheckButton - time: 0.06
GtkRadioButton - time: 0.11
GtkTextView - Add text - time: 0.23
GtkTextView - Scroll - time: 0.23
GtkDrawingArea - Lines - time: 0.98
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.92
GtkDrawingArea - Pixbufs - time: 0.13
---
Total time: 6.19

Engine: Candido
Theme: Graphite Light

GtkEntry - time: 0.05
GtkComboBox - time: 1.94
GtkComboBoxEntry - time: 1.36
GtkSpinButton - time: 0.08
GtkProgressBar - time: 0.17
GtkToggleButton - time: 0.22
GtkCheckButton - time: 0.07
GtkRadioButton - time: 0.09
GtkTextView - Add text - time: 0.22
GtkTextView - Scroll - time: 0.16
GtkDrawingArea - Lines - time: 0.89
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.91
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 7.45

Interesting. Six months (and one new graphics card and driver) later, there's been a bit of a shuffle. All engines tested are clustered much closer together. There used to be a 12-second gap between the fastest and slowest engines. Now it's only 3 seconds. Part of that disparity comes from new versions of the engines. Aurora in particular has made phenomenal improvements since 1.4; the numbers you see here are from version 1.5.1. It's no longer at the back of the pack -- last place now belongs to Candido, which is still rather slow, especially in the ComboBox tests.

Curiously, although the completion times are stacked very closely, there seemed to be a general slowdown. While the older gtk+ engines still turn in respectable times, they're not always at the front of the pack. In particular, the Pixmap engine, which has historically had a speedy reputation, is now trailing most other engines. The theme used is extremely simple. I'm not sure what's causing the slowdown here. Perhaps its reputation for speed is no longer deserved; even six months ago it wasn't a standout.

There's no longer an engine that can turn in 3-second completion times; in fact, the four fastest engines all tied at 4.7 seconds. Of the four, Rezlooks is without a doubt the prettiest. Many of the screenshots in my devspace feature Rezlooks themes.

Two of the engines added for this round of benchmarks, Crux and Redmond95, end up in the middle of the pack. They're not particularly fast, nor are they pleasing to the eye. The other two newcomers, ThinIce and HighContrast, distinguish themselves by jumping to the very top of the charts. HighContrast is undoubtedly the ugliest engine presented here, while ThinIce's appearance rather resembles Mist. It's tolerable, but nothing I'd use, personally.

Once again, I'll stick with Rezlooks-based themes, as well as the occasional standout Pixmap or Clearlooks theme such as ClearLUX. ClearLUX in particular is extremely easy on the eyes when doing late-night computer work.

But where are the Xfce engine results? Let's take a look . . .

The Xfce engine results baffled me. The completion times varied wildly, everywhere from middle-of-the-road to flat-out fast to back-of-the-pack. So I intermittently benchmarked the Xfce engine for an hour, under varying degrees of desktop activity. Everything from lots of different applications open to a completely blank desktop. I couldn't generate consistent results. So, I decided to close down all applications and run a final series of three tests. Presented here are the slowest and fastest times logged for this series.

Engine: Xfce
Theme: Xfce

Slowest times
GtkEntry - time: 0.06
GtkComboBox - time: 1.18
GtkComboBoxEntry - time: 0.50
GtkSpinButton - time: 0.08
GtkProgressBar - time: 0.07
GtkToggleButton - time: 0.08
GtkCheckButton - time: 0.03
GtkRadioButton - time: 0.06
GtkTextView - Add text - time: 0.20
GtkTextView - Scroll - time: 0.14
GtkDrawingArea - Lines - time: 0.90
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.94
GtkDrawingArea - Pixbufs - time: 0.15
---
Total time: 5.56

Fastest times
GtkEntry - time: 0.02
GtkComboBox - time: 0.55
GtkComboBoxEntry - time: 0.43
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.06
GtkToggleButton - time: 0.06
GtkCheckButton - time: 0.03
GtkRadioButton - time: 0.04
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.12
GtkDrawingArea - Lines - time: 0.86
GtkDrawingArea - Circles - time: 1.19
GtkDrawingArea - Text - time: 0.90
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 4.63

Look at that. A completion time of 4.63 seconds, well ahead of any other engine. That's best-case though; it can be almost as slow as the Aurora engine, which is notoriously heavy. The DrawingArea and TextView numbers are fairly static in both sets. Everything else tends to vary widely. No idea why. Perhaps the developers have made some changes under the hood between Xfce 4.4 and 4.6?

Original post from Planet Gentoo.

Sune Kloppenborg Jeppesen: 24 hours with the HTC Magic Android phone

Sune Kloppenborg Jeppesen (jaervosz) — Thu, 11 Jun 2009 19:55:37 +0000

When I returned home tuesday I happily discovered that while I'd been away in Africa the HTC Magic had landed here in Denmark. Only at the 3 operator for the first few days but soon followed by TDC, Callme and Telmore. So yesterday I ran to the local 3 shop when it opened and they still had some HTC Magic phones in stock so I bought one right away! The first batch sold by 3 are not branded and they are supposedly not SIM locked either.

The phone itself is nicely proportioned and the build quality seems far better than my old SE 960i. Everything in the kit including the charger and sleeve pouch is white. The sleeve pouch and the headphones seems to be of a bit lesser build quility than the phone itself. The volume control on the headphones is positioned very close to the cable split which for me means that it is almost right below my chin and it's nearly impossible to see it. Also it doesn't use a standard mini jack connector which would have been nice. Thirdly I like the SE style plastic earpieces better than the ones supplied with the HTC Magic. Well enough bickering about the HW itself. Let's get to the Android SW.

To start out with I just played around with some of the supplied apps. The basic Mail app worked fine with my IMAPS mail account, though it only watches the inbox and I use Sieve to sort my mails to one of many subfolders, so the mail notifier is not really that useful. I tried k9mail instead and it's folder support seems better, but it doesn't support IMAP subfolders and it could be useful to have notifications for other folders than the Inbox.

The Browser works as expected, the only thing I really miss is some adblocking options. I tried browser based streaming TV from the national TV provider DR, but that didn't quite work.

The Music app have almost all features I'd like to use. Though cover download and lyrics support like Amarok would be nice:)

The Youtube app is also nice, though the "watch in high quality" option is a bit too well hidden. Playback of HQ music videos worked like a charm.

The Maps app and GPS is working great. I did a field test with it today while riding the train and it worked like a charm. Though it's a bit odd to sit in the train staring at a small flashing blue dot moving on the screen, like you always see in the movies:) I also used the Maps app to navigate the last few houndred meters on foot after disembarking the train. It would be nice though if the map could rotate according to which direction you were heading, like the Sky Map app.

Speaking of the Sky Map app this really rocks! Unfortunately it's been overcast here the last few days so I haven't had a chance to really compare it to the real thing. But just holding up the phone over your head and see the pictured night sky rotate as you rotate the phone is just awesome!

But the best app of them all must actually be the Market app. Not the app itself but the possibility to download countless apps free of charge! I've always loved to play around with the barcode scanners in various supermarkets so I quickly downloaded Barcode Scanner to play around with. So I used some time like a ten year old scanning all barcodes I could find:)

Next up was the ConnectBot to do my first SSH login using the HTC Magic. That felt nice too!

Eventhough there is no official FB app for the Android I tried one of the unoffical ones and it's reasonly useful to update status and keep track of your wall. It seems like several alternatives are being developed, so the situation will hopefully get better. But for now you can at least pretend you have a life on FB with the HTC Magic.

Today I've been toying a little with KDEPIM integration with Google Calendar and Contacts. I've previously used Gcaldaemon for synchronizing Korganizer calendar and Google Calendar, but it's not really a nice solution with a running Java daemon that tends to eat up all memory on the server. Instead I've tried out the Googledata Akonadi plugins that is demoed on Youtube. So far I've only experienced limited success. Creation of events in Korganizer seems to not be properly uploaded, but new events are downloaded to Korganizer (at least after a restart). For Kaddressbook I've tried moving contacts from the traditional Kaddressbook storage to the Akonadi plugin, but they fail to pop up in Google Contacts. I hope the state of KDEPIM Google integration will soon improve.

I think I got carried away while writing and it all got a bit longer than initially planned, but let's just say that after a bit over 24 hours I'm more than happy with my HTC Magic phone! The Android interface is very snappy and application switching is blazingly fast compared to my previous SE 960i. The onscreen "Cupcake" keyboard takes a bit of time getting used to and I haven't even had the time to try out the Camera and Camcorder yet. The only really bad thing about Google Android so far is that it is yet another way for Big Brother Google to gather tons of personal data. And now back to playing with the HTC Magic and let's see how long it goes before I have too root it:)

Daniel Drake: XO-1.5 development underway

Daniel Drake (dsd) — Thu, 11 Jun 2009 19:04:59 +0000

The OLPC tech team recently flew out to Quanta in Taiwan to bring up the first handful of test boards for the next generation XO laptop, known as the XO-1.5. The new laptop is basically a refresh to solve the difficulties that occur when you continue to try and source 2-year-old technologies in bulk, but will result in core improvements at the same time.

The Geode processor from the XO-1 has been end-of-lifed; the new laptop uses a VIA C7 CPU with the brand-new VX855 chipset. The flash storage and RAM have been quadrupled, providing 4GB and 1GB respectively.

I’m now joining the efforts for a few weeks, helping out on the software. We’re aiming to make a new “deployment quality” software release, including the newer version of Sugar and a generally more-up-to-date system based on Fedora 11. I received my A-test board today, it is already booting into Sugar and is quite functional.

Daniel Drake: OLPC UK Pilot planning underway

Daniel Drake (dsd) — Wed, 10 Jun 2009 18:12:30 +0000

A while ago, I created an OLPC UK page on the OLPC wiki, and a mailing list alongside it with the hope of linking together the various people who were interested in organising various kinds of UK-based One Laptop per Child activities.

These small efforts have proven fruitful; a number of people from various backgrounds have teamed up and are organising a pilot programme for deploying a small number of XO laptops in a UK school.

I’m back in the UK for a little while and am excited to get involved where I can.

Their next meeting is June 17th in central London. I will be giving a presentation about my experiences with OLPC to date. More details here (RSVP requested). I hope to see you there!

Markos Chandras: New sip/PyQt{,4}/qscintilla{,python} on portage

Markos Chandras (hwoarang) — Tue, 09 Jun 2009 19:23:16 +0000

I haven’t written anything for a while due to real life obligations. I am writing my Thesis, plus I am in the middle of my (final?) exam period.

Anyway, I just committed the following packages on portage tree:

dev-python/sip-4.8
dev-python/PyQt4-4.5
dev-python/PyQt-3.18
dev-python/qscintilla-python-2.4
x11-libs/qscintilla-2.4

We have been testing them on qting-edge overlay for a while and since we didn’t encounter any breakages, we decided to push them on tree. I ‘d like to thank Ben de Groot(yngwin) and Davide Pesavento(Pesa) for cleaning up and testing the ebuilds during this period.

Even though we tested as many PyQt applications as possible, to verify that nothing breaks with the new packages, there might be some breakages. If you find any, please let us know by filling a bug

Enjoy your shiny new packages

Updated: 11-06-2009

New pykde4 committed which solves compatibility issues with PyQt4-4.5

Nirbheek Chauhan: I don't understand this

Nirbheek Chauhan (nirbheek) — Tue, 09 Jun 2009 08:13:46 +0000

And the fun part is, that I can't understand it. Why? Because even though I'm in college, I can't read or understand Physics papers. The learning curve is too steep.

Learning curve for physics too steep? Just pick up a book about it and read it!

Sure, and to understand the physics involved from the basics, I must learn the math involved. And once I've gone through 3 books for the math, I'd still not be able to understand peer-reviewed physics papers.

What's left? What more do you need to know?

To dive into a peer-reviewed paper, I need to be familiar with the language and syntax that they use. It's almost unreadable to a newcomer to the field. Is it just this paper or does every paper use such convoluted language and bury the facts in irrelevant claims, fancy language and dramatic bold text?

If I somehow get used to that stuff, I need to be familiar every paper of the 5 kazillion or so that it references. Especially so when it references other papers by the same author.

Bah. Anyway, I was trying to read some of the papers published by the ~~people~~ guy at Black Light Power. To see for myself what kind of credence to associate with his claims.

And they're just impossible to read.

I do not like hand-waving, and I do not like pretty pictures or videos. I would like my questions to be answered, or given the means to answer them myself. Papers are supposed to be a way to do that, and I can't. So I don't know what to make of his extraordinary claims.

In case you were wondering what his claims were, he's just about claiming that 40 years of QM is inaccurate because they cannot reconcile with some of his experimental observations (which have been published in peer-reviewed papers, not that I trust anything unless I can see the arguments for myself). Now, this would be something revolutionary, but there's too much such stuff going around, and it's difficult to differentiate the physicists from the crackpots.

All in all, I don't have a clue. He's right that people have a hard time getting away from their dearest theories, and I have been embarrassed by the fact that QM is one thing that no one learns, but rather "Accepts" in school and through college since the Math involved isn't taught at that level.

But really, the only way to challenge something as widely-accepted as HUP, you need a mountain of evidence (Occam's Razor and all that).