fidzu : Gentoo

- That drink was individually tailored to meet your nutritional requirements and pleasure.
- So I'm a masochist on a diet!

Arthur Dent and the Nutramatic Machine; The Hitchhiker's Guide To the Galaxy - Secondary Phase

One of the reasons given for Free Software popularity among geeks and other technical people is that it consists, for many, of a simple way to scratch their own itches; it's probably the same reason why I keep using Gentoo: it allows me to scratch my own issues pretty easily. Since people scratch their own issues, they do the things the way they best like, and that turns out to be successful because both great minds and lots of geeks think alike.

At the same time, there is a very strong drive to give Free Software to the masses… this drive is ethical for some, commercial for others, but the bottomline can be generally summarised in "Free Software needs to be done the right way". This includes many aspects of Free Software: from code quality, to maintainability, to usability of the interfaces. And once again, to be able to have results you have to accept that you're going to have rules, standards and common practises to accept. The problem is: how do you forge them? And how much they should distance the "older" versions?

Now, for once don't let me get into the technicalities of code practises, QA and so on so forth… I'll focus on something that I have to admit I have near to no working knowledge of: interface usability. I'm a developer, and as many developers, I suck at designing interfaces that are not programming interfaces: websites, GUIs, CLIs… you name it, I suck at it. Thus why I do find it very helpful that there are usability experts out there that works hard to make software interfaces better to use for the average user and (possibly) for me as well.

- The ventilation system; you had a go at me yesterday.
- Yes, because you keep filling the air with cheap perfume.
- You like scented air, it's fresh and invigorating.

Arthur Dent and the Heart of Gold ventilation system; The Hitchhiker's Guide To the Galaxy - Secondary Phase

Unfortunately, I'm afraid stuff like that soon gets overboard, because people start to take a liking into dictating how other people should use their computer. This is among the other things one of the most common criticism directed toward Apple, as they tend to only allow you certain degree of use of both their hardware and their software; and the obvious challenge is to get their hardware (at least) to do something it wasn't deigned for (second hard-drive on MacBooks, XBMC on AppleTV, iPhone Jailbreak…).

Now, sometimes the dictats on how to do something turn out for the best, and people are hooked into the new interfaces and paradigms (let's take as example the original iMac's lack of a floppy disk drive; I wouldn't be surprised if Apple were at some point to drop optical drives on all their line of computers and then ship OSX on read-only USB media). This might create a trend that is followed by other developers, or manufacturers, as well. Without entering the merits of the iPhone in the sparks of Android phones, just think of when Apple pushed iTunes with their iPods: the average Windows user used WinAMP before, and iTunes has a completely different interface, on Linux, XMMS first and Audacious after was the norm, both using the same interface as WinAMP. After iTunes, and for Linux especially after Amarok, around version 1.3, we have a number of playlist-centric players instead.

Now, once upon a time, the KDE users and developers laughed at GNOME's purported usability studies that hid all the settings, and caused Nautilus to become "spatial" (I remember one commenter on the issue, supporting the then-new spatial Nautilus by saying that tabbed browsing wasn't usable because it would have been the same as glueing together newspapers to read them… now that was a silly thing to say, especially in that context). With time the situation reversed, for a while at least with KDE deciding to "move for usability" and "new concepts" with KDE 4… and breaking the shit out of it all, for many people, me included. I think a very iconic point here would be some of the complains I heard about the latest Amarok development in #gentoo-it, about the application is supposedly "more usable" by changing so many things around that even long-time users can't feel at home any longer.

While Amarok always had this edgy feeling that it could screw up your mechanics by simply deciding that something is better done in the opposite way that it was before, it worked out because the ideas caught on pretty quickly: people moaned and ranted, but after a month or two, near everybody was enthusiast, and wondered why the other players didn't do the same. This trend has changed with Amarok 2 it seems, as I heard almost only rants, and very few enthusiasts outside of the core developers. And I'm not speaking about the technical side of things here (like the usage of MySQL Embedded - which in my opinion has been a very bad move… mostly because MySQLe was definitely not ready at the time, as Jorge might tell you).

But my safe haven of GNOME start to feel disturbed; while I've read good things about the "Usabiltiy Hackfest" that happened a couple of weeks ago in London, sponsored among others by Canonical if I recall correctly, some of the posts coming from there looked positively worrisome. In particular, Seth Nickell's posts about "Task Pooper" (maybe I'm biased but projects choosing such names feel like a very bad start to me) reminded me a lot of Seigo's posts about Plasma, and while I hear most people happy with it as implemented currently, I also remember the huge rants in the first iterations where the whole interaction was designed out of thin air… I'll quote the Ars Technica article (which title is in my opinion a bit too forceful):

Despite his protest that the new design isn't "handwavy," I had a hard time seeing how all the pieces fit together after reading the initial document. [snip]

Actually, I think Nickell's went to say that his design was not exactly what he made it to be, as it stands now. Going all the way to declare the New Majestic Paradigm Of Desktops is the first bad move if you want something good, I think. Not only it'll add a lot of expectation to a project that is for now just designed out of thin air, but it also make him sound way too convinced about his stuff. I like it much better when the designers are not convinced about their stuff as that means they'll think about it a lot more… it's a challenge of second-guessing oneself and improving step by step. If you think you reached the top already, you're going to stop thinking about it.

At any rate, the point I wanted to make was simply that people need to complain and need to rant about things, if you want them to be good. So please don't take my rants always as negative, I do rant, and sometimes I rant a lot but I usually do that because I want to improve the situation.

P.S.: if GNOME 3 turns out to break as many things as KDE 4.0 I might consider to try the latest version of KDE at that time. Unfortunately I have heard too many bad things about KMail and eating email… so I'm still a bit wary. I really like the idea of GNOME developers working on 3.0 already, even though 2.30 is still to be released… branching is good!

12 Mar 2010 12:41pm GMT

Building packages on a Gentoo System starts with package description files called ebuilds. They're basically shell scripts. Along the way, you specify from where to get the source tarball. When you build, Portage downloads the source and then proceeds to unpack and compile it. Because they're shell scripts, they can use shell variables to great effect.

LINKS:

Southeast LinuxFest
http://www.southeastlinuxfest.org/

Texas Linux Fest
http://www.texaslinuxfest.org/

TechCast.us
http://techcast.us/

PythonGroup Wiki
http://asterisklinks.com/wiki/doku.php?id=core:start

PythonGroup Forum
http://asterisklinks.com/python/index.php?board=4.0

Gentoo (dabbott)
http://dev.gentoo.org/~dabbott/

irc network freenode channel #linuxcrazy

Download

11 Mar 2010 4:40pm GMT

Chemnitzer Linux-Tage 2010 is almost here, and Gentoo will be there!

This years Chemnitzer Linux-Tage on March 13th and 14th is another great chance to:

• get in touch with Gentoo developers
• buy Gentoo shirts (be quick, first come first serve)
• chat, discuss, start with ebuilds and overlays, you name it

The "Chemnitz Linux Days" is a conference that deals with Linux and Open Source Software . It is open for everyone, novices and experts alike. This event is organized by IN Chemnitz, CLUG, Computing Center and Faculty of Computer Science of Chemnitz University of Technology, and many volunteers.

See you there!

Sebastian Pipping contributed to the draft for this announcement.

10 Mar 2010 2:02pm GMT

So, this post is not really technical, but I'm posting it to the Gentoo planet anyway because it applies to the social part of Gentoo. I see a lot of people making the same mistakes that I once did, or saw people make while interacting socially within Gentoo. This post is not in response to someone in particular; more like in response to the "feeling" I get.

Communication Problems (technical): when communicating over inefficient media such as email or IRC, keep in mind that the other person has no way of knowing what you meant, or felt, when you said something. Due to this, it is easy to cause insult, and even easier to be misunderstood or misquoted. No one knows your mood when you type on the net.
Solution: Make ample usage of smileys; make it clear what you mean, in as few words as reasonable. When on the receiving end, give the other person the benefit of doubt. It's quite easy to misunderstand what someone said. When in doubt, re-read and re-interpret.

Communication Problems (social): I've personally found that the root cause of 110% of arguments that escalate is a severe and dire lack of proper and clear communication. People are just unable to express what they mean, what they want, and what they are thinking in clear, easy-to-understand terms. Part of the problem is that "clear, easy-to-understand terms" vary among people. The other part is that different people think in different ways, and English is usually not their native language.
Solution: To be able to communicate effectively with someone, you need to understand how they think first. This is obviously too much work to do with everyone you meet, but if you're going to be working with or around someone; take the time out to empathize with their world-view. If you want to convince someone of your opinion, put yourself in their shoes and see it through their eyes.

Communication Problems (length): This is one problem that seems to plague people a lot, and often they don't even know it. Writing 4 paragraphs when 1 would've sufficed is a bigger problem than just writing one cryptic word. A lot of analogies are coming to my mind right now to explain this, but I'm going to go with this: 'tl;dr'.
Solution: When you write something, keep in mind that time is a precious commodity, and by writing a long mail/response, you will waste their time if they choose to read it. And hence, most people will not read it. If you want them to read it; spend some of your time and make it easier to read. Make it short.

Communication Problems (rage): E-mails written and IRC conversations conducted in anger. You read an email, see someone make a commit, or just something they said on IRC; and you go into RAGE mode. It makes you furious. You don't understand how the guy can be so bloody stupid. Maybe it's the last frickin' straw. You flip off and start shouting. The other side may be oblivious to your distress; or worse, they flip off as well. When the dust settles, pandas and kittens make sad faces at your blood pressure and the decisions you made.
Solution I've been on both the rage-side and the rage-causing side, and I can tell you this: It doesn't help anyone. If you get angry at someone on the internet, stop. Stop and get off the computer. Come back later. If you cause someone to get angry, pause. Pause and figure out why. Think to yourself; maybe you're wrong, maybe they misunderstood you, maybe they had a bad day. But first off, calm the other guy down. Stop arguing, and take a walk. Come back later and try to reconcile your differences. Fact: 149% of arguments lead to burnout and heart disease.

Now, I don't expect people to keep all this in mind all the time. Hell, I'm writing this now, but I know I'll never be able to stick to this 100%. The point I'm trying to make is that You're Fallible. Everyone is. Just keep that in mind all the time, and just remember the above things vaguely (you can bookmark it for reference!). I'm sure we can all do better than we're doing right now.

10 Mar 2010 12:41am GMT

I have ranted on about the purported support for Gentoo in Amazon EC2; I would like to slightly defend Amazon on this matter saying something that some people might find inflammatory but, I think, we should acknowledge if we strive to improve: Gentoo suck as a guest OS! Now that I pointed at the elephant in the room, let me try to qualify and explain this statement, trying to see what we can do about it.

The first obvious problem is that the standard baselayout we ship with has no idea how to work with vservers and other virtualised environments; we have baselayout-vserver, but last I knew it was a bit behind in features. Actually, we have a very good support for guests in baselayout, version 2, based on OpenRC. Indeed one of the features that the new baselayout brought to the mix was supporting out of the box many different VPS implementations (xen, vserver proper, OpenVZ, and, lately, LXC thanks to Andrian). Unfortunately, almost two years after the addition of OpenRC to the tree, and over three and a half years after the introduction of the first alpha of what became the current situation, we still don't have it stable, although we're nearing that date, hopefully.

  02 Oct 2006; Roy Marples <uberlord@gentoo.org>
  +baselayout-1.13.0_alpha1.ebuild:
  First alpha cut from the 1.13 branch with BSD and VServer support.
  svcdir is now forced - you cannot change it&aposs location.
  If you downgrade back to 1.12 you&aposll have to copy /lib/rcscripts/init.d
  to your svcdir (/var/lib/init.d by default) and run depscan.sh -u

Even discounting this problem (I actually use OpenRC on all my production systems, and never, or almost never, got problems with that), there are still problems with a number of scripts and configurations that assume presence or work of various real-hardware components that (obviously) we don't have.

For instance, take the default syslog-ng configuration: it uses the /dev/tty12 device for logging… it doesn't check whether the device exists before opening it for write, and the end result is that it can create a standard file with the log printed on it if you don't remember to disable it after install (yes I noticed this just the other day after months of having the vservers running, shame on me!). On the other hand, metalog (which requires an option to run in vservers, since it will fail to start if it cannot access the kernel, and it obviously cannot do that within a vserver - and only the currently-unstable version has the option to do that) uses /dev/tty10 by the default configuration… just to show that we can't even agree on the devices to use!

And of course there is the one big issue: our system set is too big! This means we end up bringing in a lot of stuff that is definitely not useful on vservers by default (like the kernel sources) just because we need them for the default case of real hardware. I guess one solution here would be to reduce the system set and then use the additional sets available in Portage 2.2 to handle the real-hardware cases (in the default stage… and from that an emerge -C &x40;hwboot would give you a virtualizable-system)… but alas that's something that never got enough momentum to become reality.

In general, though, Gentoo could become a much better OS to work as guest… we should all try to work on improving that step by step, bit by bit… remember: report whatever you feel is wrong with Gentoo packaging on our bugzilla after making sure there isn't a report already. Don't assume somebody else will see your problem, don't assume that you'll be the only one with that problem, please report it… just try to keep an open mind that maybe it'll be marked as an invalid bug because you should have done some extra configuration… on the other hand, we really should make it easier to use Gentoo as a guest operating system.

09 Mar 2010 9:57pm GMT

So SCALE 8x went okay.

I was interviewed by the SCALE Public Relations team; you can see the video here.

Gentoo@SCALE

I'd say we had the most diverse assortment of machines at any booth -- something like 10 different machines on 5 architectures. Certainly we had a bunch of developers; we haven't had a showing like this since SCALE 5x.

Everyone loves event pictures, so here's the Gentoo team:

Left to right: vapier, nightmorph, antarus, nerdboy, wormo, omp, halcy0n, solar
Not pictured: blackace (he took the picture)

And now, the hardware running Gentoo! On the table, from left to right:

1. Beagleboard running E17 on the huge monitor
2. Hammer/Nail board by Tin Can Tools (in the clear orange-capped tube)
3. Blackfin development board (hooked up to the middle keyboard, and with a touchscreen running Doom)
4. deployed Blackfin module (that 2-inch square to the left of the wireless mouse)
5. my Core2 Thinkpad running KDE4
6. a mini-notebook
7. OLPC XO (green/white, on top)
8. PowerPC Walnut board (in the K'Nex case). Barely visible behind it is the laptop that's tied in via serial port.

There were a few other Gentoo-powered laptops, subnotebooks, and smartphones demoed throughout the conference, but not all of 'em are visible in this picture.

I mostly demoed KDE 4.3 on my laptop, since the desktop effects and eye candy proved to be a good draw, especially the "falling snowflakes" animation. Man, I love that thing! It's a built-in KWin effect, so there's nothing special to install. Now all I want is a "falling raindrops" effect on my desktop, without resorting to Compiz.

I did occasionally switch the laptop to Xfce when I wanted to save power, or just to showcase Gentoo's flexibility. I got a good draw not when showing a standard Gentoo wallpaper, but when I showed off a desktop rather like this (clean version here). There were a buncha little kids that stopped by and oohed and ahhed over that for a bit.

Sessions@SCALE

The talks were rather disappointing this year. Several of my fellow devs stated that they "just plain sucked." Basically, none of us attended because of the talks. There just weren't any powerful draws. I was only vaguely interested in attending a couple of sessions, the ones on startup-up/embedded improvements and building a featherweight desktop. Didn't actually get to see those, as the timing and draw was just kinda "meh."

Instead, I found myself at the Mindstorms talk, which was very lackluster. I expected to see lots of toys in action, and videos, and whatnot. The speaker wasn't at all engaging, and the single Lego robot was impossible to see, and it wasn't working correctly for the entire presentation. I stopped by another session or two, but nothing grabbed my interest. I spent most of my time on the show floor, helping in the booth or wandering the floor. Speaking of which . ..

KDE@SCALE

I stopped by the KDE booth to see the newest 4.4 and 4.5 stuff being demoed, and I also tried to help one of the devs figure out the build dependencies for one of the latest libraries. Man, source building on Ubuntu sucks. There's some really, really nifty Plasma desktop stuff going on for small screens. The newspaper-like activity flow is something I wouldn't mind using day-to-day on my workstation.

Another neat bit of 4.4/4.5 is the ability to switch your Plasma desktop widgets while still keeping your applications open in front of you. It's sort of the opposite of workspace switchers, where each application group is on a separate virtual workspace, while the desktop remains fixed. I never bother with more than one workspace, but I do like the idea of switching the widgets behind whatever it is I'm working on.

The 4.4 improvements and upcoming 4.5 features are definitely enough to keep me interested in KDE, so I'll leave it on my laptop and look forward to the day 4.4 is stabilized in Gentoo.

Elsewhere@SCALE

The Gnome and XBMC booths were just across the alley from our booth, but I didn't get a chance to check out either. The Gnome guys blasted pounding techno music the whole conference, which gave all of us--even the ones without hangovers--good-sized headaches. The XBMC folks were running some pretty impressive demos on their Zotac MAG, but unfortunately I didn't get a chance to go over and chat with 'em.

In the last few days, I've decided to put together a living room HTPC built around an Acer Aspire Revo and XBMC Live, and it woulda been good to see the thing properly demoed a couple of weeks ago. Still, from what I saw from the Gentoo booth, XBMC is one heck of an awesome app.

Our booth was fairly well trafficked, but overall it felt like attendance (and interest in Gentoo) was down from previous years. Take that with a huge grain of salt, though -- while I felt like SCALE was more sparsely attended and the talks sucked, the actual numbers tell a different story. The event organizers say attendance was up more than 10% and there were more standing-room-only talks than ever before. So make of that what you will -- but I might not go back next year if it's going to be anything like my experience this year. There need to be more sessions that are relevant to my interests.

One of the high points of SCALE was meeting the folks interested in Gentoo, and definitely talking with our existing users, like the ever-loyal calculus from IRC. Thanks for coming by, folks!

07 Mar 2010 9:52pm GMT

Yesterday Robin (robbat2), our Gentoo MySQL maintainer notified me that there has been a patch in MySQL 5.1, also approved by upstream developers, that fixed the akonadi crashes. Robin worked very close with the upstream developers and helped a lot for this. The patch in Gentoo is in dev-db/mysql-5.1.44-r1. At first it didn't work, but recompiling x11-libs/qt-sql did the trick (which is the split sql module of the Qt package - Gentoo provides split Qt packages). As far as I know, other distros already shipped it. For those who didn't, more information can be found in the following bug reports:

• MySQL bug
• KDE bug
• Red Hat bug

… and the patch is here

=-=-=-=-=
Powered by Blogilo

07 Mar 2010 7:29pm GMT

I've been playing with matplotlib and Gentoo bug numbers from the last ~6 month to be able to see how we are performing at fixing bugs lately. This is the current output:

While I am surprised how many bugs we fix each day I am also shocked that each month almost 70 bugs go on top of the current pile.
What else can we read from that graph? It seems Gentoo's users are willing to report bugs (which is cool) but its contributors cannot fully keep up with fixing them (which is less cool).

I am presenting this graph today to suggest that:

• Bugzilla stats have interesting things to tell
• Fixing bugs could use more attention, manpower and a better process in Gentoo
• The planned re-write of bugday.gentoo.org could play a keys role with improving the process
• A Gentoo Google Summer of Code project could work on software to continuously extract detailed bug statistics for us
• You can do neat plots using Python and matplotlib

[EDIT] The source code to produce above graph is now available.

07 Mar 2010 9:31am GMT

Just a very quick call:

Today, Saturdays 6th is a Gentoo bugday.

Users and developers get together at #gentoo-bugs on Freenode IRC to cooperate on fixing bugs: ideally all at once but a few thousands per participant makes a good start, too. It makes a difference, it's fun, it's a great way of contributing to Gentoo.

See you there!

(Actually I need a few hours of sleep first…)

06 Mar 2010 6:06am GMT

In my immediately previous post I have thrown in a couple of nods to two particularly nasty issues related to shared object plugins; I have written extensively, or even excessively, about the issue so I'm not going to write more about the presentation of shared objects (or dynamic libraries if you prefer the Microsoft term for the same concept), and I'd rather go on with the two current problems at hand, which I'll try to cover in a proper manner.

Shared objects as plugins

When building shared objects for plugin usage, like the case for NSS I noted, PAM plugins or extensions for languages like Ruby, Python, Perl, Java… you don't need static libraries at all, so a shared object is enough!

While some of those system do support statically linking engine and plugins in an application, this rarely works out as intended; for instance FreeBSD (used to?) support statically linked PAM, but that worked only for the default modules, and if you configured your service authentication chain to use non-default modules you have a non-working setup. So the net result is definitely against having to support statically-linked PAM, or any other statically linked system.

Since you cannot link this stuff statically in, you can easily see that there is no need to install (nor build!) the static archive version of those things; this is usually done properly by both custom-tailored build system (as upstream likely tries to minimise the effort) and by the language-specific buildsystems (like the various incarnation of mkmf and rake-compiler in Ruby, distutils in Python, ant for Java, and so on so forth). On the other hand, especially with autotools-based build system, most people seem to forget that there is a nasty overhead in building both version, beside the waste of installing the extra file.

Indeed, since libtool will prefer building PIC objects for the shared objects (as it's required for AMD64 and most of non-x86 architectures), and non-PIC objects for static archives (to reduce overhead); since you cannot build once for both (nor you can pre-process once, as you can have __PIC__ conditional code!) you end up having to call the compiler twice for each source file. To reduce this overhead you can usually default to disable static libraries (or disable it through ./configure invocation) or you can disable it altogether as instructed so that it only ever builds the shared object version, and not the static one. Unfortunately this does not stop libtool from installing a pointless .la file but that's a different story.

While there is a safety check in Portage proper to check for .la and .a files in /lib, there is no such check for Ruby, Python, Perl, Java extensions. My tinderbox has an extra check for that and is usually able to find them; I also have a bug report template that tries explaining the maintainers involved why I report to them that a .la file is pointless and that they might want to fix the eventual static archives at the same time as well. Unfortunately, sometimes people decide it's too much of a hassle to prepare the patch to send upstream and apply that in Gentoo, so you end up with ebuilds that avoid using make install to avoid installing the already built archives, or just delete them after install (works okay for .la files, since they are usually small and it's definitely not trivial to avoid installing them), causing the double-build to still be performed.

Boot-critical programs and shared objects

Different page, correlated issue happens with boot-critical programs: things that need to be started before you mount all your local filesystems (maybe because they are needed to mount such filesystems, like lvm) need to have all their shared objects being available at that time. This becomes a problem when you end up needing libraries installed in /usr/lib and you split out /usr (similarly to what I said about /boot I don't think the general case should be for splitting it out; sure there are cases where it's needed for various reasons, but it shouldn't be by default!), as they wouldn't be able to run.

To solve this problem you either move the libraries (and all their dependencies) to /lib, or you have to statically link applications. The former creates a chain reaction that makes the whole point of splitting /usr mostly moot; the latter problem actually moves the problem down to the user: since Gentoo policy is to never force static linking on the user, as shared object linking has many many advantages, this is usually made conditional to the static USE flag; such a flag will build the software with static linking, and will thus require the dependent libraries to be available in static archive form (which is why rather than Portage features or whatever else, static libraries are usually made optional via an USE flag: it can be depended upon).

Mix the two! Shared object plugins for boot-critical programs!

And here is the reason why I merged the two problems, as they might seem just barely related: there is a case where you actually need a static archive to build a shared object plugin; that's the case for PAM plugins that need libraries, such as pam_userdb uses Berkeley DB library for storage.

It's not an easy case to solve, because of course you'd be looking to have the library available as static archive, but at the same time it has to be PIC to work properly… up to the 0.99 version, the solution was to build an internal copy of Berkeley DB within the PAM ebuild; without counting the additional problems with security, we ended up with a very complex ebuild, a lot more complex than it would be needed for PAM alone. I discarded that solution when I took over PAM, and split the Berkeley DB support in its own ebuild… doing the same thing as before. That ebuild has been, up to now, pretty much untouched, and the result is that we have a stale ebuild in tree using a stale version of Berkeley DB. I don't like that situation at all.

Sincerely, after thinking about it I think the best solution at this point is simply to get rid of the stale ebuild, and decide that even though PAM is installed in /lib, it does not warrant total coverage: we won't be moving, or building statically, things like PostgreSQL, LDAP, MySQL and so on so forth, and yes, those are all possible providers for the PAM modules. I guess we should just add one very simple statement: don't use external-dependent modules for authenticating users and services that are boot-critical.

If I'll still be a Gentoo developer next month, after I free myself up from my current work tasks, I'll be merging back sys-auth/pam_userdb into sys-libs/pam, and then take care of getting the new PAM stable, and the old ebuild removed. This should solve quite a few of our problems and set a better precedent than what we have right now.

05 Mar 2010 11:03pm GMT

You have probably seen the Host Virtual advertisements on the sidebar of gentoo.org website.

I ran into a weird clocksource issue on my VPS that I haven't seen elsewhere. This issue was that my time would progressively get worse and worse and eventually NTP could not keep up because the clock was so far out of date. This happened on a pretty quick interval, about 1-2 days until I had to manually reset it. I opened up a support case with Host Virtual and the suggestion was to change the kernel's clocksource to jiffies, from tsc, or vice versa. (or use a newer kernel, but I was already at the latest 2.6.32.x kernel at the time) My kernel's clocksource was at the default and I had to research the issue some more because I haven't heard of this before.

In the kernel's Documentation directory, I found some info. (Documentation/kernel-parameters.txt). There is quite some details in there, but the summary is that the default clocksource was 'tsc' on x86. I changed my kernel's clocksource by the clocksource=jiffies kernel parameter. Rebooted the virtual machine and NTP has been able to keep time since.

I don't really know the difference here and don't care to research much more. It is fixed and maybe this info will help someone else someday.

05 Mar 2010 5:28pm GMT

I'm in the metro of Paris, testing Typepad :

• new beta account I just subscribed to
• new mobile version of the blog
• Iphone App
• automatic Twitter posting
• per category feeds

Typepad is Based on Movable Type, the best blog system ouuta there. It's Perl based. It rocks.

05 Mar 2010 12:18pm GMT

In the last KDE and Qt meetings, there have been many and important changes, so I decided to blog about them to keep users up-to-date. The summaries and logs are available in each project's site (http://kde.gentoo.org and http://qt.gentoo.org). Both projects have regular meetings, every third Thursday of the month (unless announced otherwise), and very often they have a common one. The channel that hosts us is #gentoo-meetings in Freenode, and everyone is welcome to join us. I will mention only the most remarkable issues that were discussed/decided, which seem to be a lot:

Qt meeting, 19 February 2010

This was delayed one day, so I missed it. I really hate it when I miss Gentoo meetings, as every time they are very fun and challenging, and I like very much interacting with so many Gentoo developers and contributors at the same time. Before proceeding, I'd like to point out that the Qt Project was very recently founded as a separate project, because the Qt Team (sub-herd of the KDE Project) has grown too much and had too many non-KDE issues. The Qt members are doing an awesome work. And here are some of the important issues:

1. We now have an "unofficial" channel in IRC, and a new shiny Qt Subdomain! So from now on you can find us in #gentoo-qt on Freenode, and our documentation resides in http://qt.gentoo.org (thanks to Robin (robbat2) for setting that up). Of course we will still be available in #gentoo-kde or #gentoo-desktop.
2. Raster USE flag is going to be on by default. Μάρκος (hwoarang) already blogged about this asking for testing.
3. Qt 3 has been masked for removal from the tree, along with all Qt 3 packages and the qt3 USE flag. The only blocker for this task was MythTV, which now has a stable Qt 4 replacement in Gentoo. Also, Ben (yngwin) informed the kde-sunset maintainers about this, but so far I didn't see anyone committing those apps there, so if you want to do it (or do general qt3 and kde3 work), consult this document. (Reminder: kde-sunset is user-maintained overlay, anyone interested can ask for access there, so if you are still interested in Qt 3 and/or KDE 3 packages, please ask for commit access instead of complaining to the Gentoo developers).

KDE meeting, 25 February 2010

This was delayed one week, which was a request by me, so it won't be during my exams. There hasn't been a KDE meeting in January, so there were plenty of topics to discuss. I was also the moderator of this one, which made it double fun. In most of the issues there has been some progress, so let's begin:

1. We now have a new leader, Tomáš Chvátal aka scarabeus. After a year of Jorge Manuel B.S. Vicetto's (jmbsvicetto) absolutely perfect leadership, we had the annual elections, were scarabeus was voted by pretty much everyone. He is admittedly very skilled and very active in Gentoo community in general, as a member of QA, X11 and KDE Teams and also a recent council member. I'd also like to give props to my former "boss" Jorge, especially for taking over that old nasty mysql/amarok issue and creating the libmysqld.so patch.
2. KDE SC 4.3.5 is stable in tree now, and the newly released KDE SC 4.4.1 is available in tree as testing. There have been many problems with 4.4.0 (mostly crashes), so it won't be a stable candidate for sure. We'll see how 4.4.1 goes and accordingly decide if this is going to be a stable candidate, or wait for 4.4.2.
3. Amarok and MySQL 5.1 suffer from the same old libmysqld.so issue. Thus, we strongly recommend to remove the embedded USE flag from both Amarok and MySQL. In fact, it is not anymore enabled by default in the ebuilds. As a side note about MySQL, Akonadi seems to break in some machines with >MySQL-5.1.42. The problem is known to upstream developers, and there have been some workarounds in KDE forum, but I didn't have time to test any of them yet.
4. KDEPIM in trunk KDE is currently broken (really just kmail). This is because kmail's mail storage is being ported to akonadi, so IMAP (I don't know about the other protocols for sure) doesn't work at all at the moment. Sput (Quassel developer) proposed to use the enterprise KDEPIM branch, which is supposed to work, as it is being paid by companies. I sent an email asking for help in gentoo-desktop mailing list, with no answers so far. Please see the thread archive (available here) for more info. I would also like to inform you that the KDE Team decided not to provide the usual trunk snapshots until version 4.4.70 (which is going to be the first alphas), because of this KDEPIM issue.
5. KOffice 2.1.1 is released a month ago, but it is not available to users yet. Actually, it is in tree hardmasked, as it needs a close depedency checking in ebuilds. I was held responsible for this, and I hope till the weekend it will be done, if I get enough help from scarabeus which was the former KOffice ebuilds maintainer, or by anyone else from the KDE Team (there are plenty of people in the Team, I'm sure I'll find someone to help me). By the way, this is my only KDE todo thing left.
6. KNetworkManager is now in tree, but also hardmasked. This was in upstream's kdereview branch, which contains packages that stay there for review by the developers for wider testing, before they move to their final KDE module or extragear branch (take a look at KDE's SVN repo to get the picture). It was supposed to be released along with KDE 4.4, but it didn't make it. So, I created a snapshot of the current SVN repository, which seems to have many problems, like crashes, missing features etc. So I guess it will remain hardmasked for a while, and I will continue to update the snapshot once every two weeks.
7. The KDE Documentation is also one of my playgrounds. I recently updated the guide, and with a quick look I did the following: closed all three bugs regarding the KDE Installation Guide, added more items in Hints and Troubleshooting section, completely removed the kdeprefix reference, replaced the snapshots installation guide with a note that we won't provide them for now, and done a bunch of small fixes (mostly version corrections and typos).
8. I raised the issue of kde-meta (and accordingly @kde-* sets) not including all KDE modules. It currently excludes the developer-specific modules like KDESDK and KDEbindings (although it does contain KDEWebDev), and proposed either to include them all in kde-meta or to introduce a developer or sdk USE flag in kde-meta. Some developers were opposed on this, proposing to have a new meta package, like kdefull-meta, an idea which I actually hated. Our final word on this was to open a new discussion thread in gentoo-desktop mailing list, which I did, and review the issue in the next meeting.
9. Finally, I'd like the attention of everybody here, as the following issue is very very important. In a previous meeting we discussed the split of the desktop profile in gnome/ and kde/ subprofiles. We raised the idea in gentoo-dev mailing list for review, and we had a positive feedback in general. Other DE's refused to have a special subprofile, so they will stick to the basic desktop profile. What this means is that the desktop profile from now on will not contain GNOME or KDE-specific USE flags, which are transfered to the according subprofile. For users that want both DE's (or just both DE-specific USE flags) can enable them manually in their make.conf (they are not many after all). The major advantage from the user-side of view is that many unwanted dependencies get stripped off automatically, and from the developer-side of view is that from now on we'll have a more separate approach when packaging. The patches are ready and sent for review in gentoo-dev mailing list. Currently the result can be seen in the kde-crazy overlay, and here you can see the relevant thread. A news item will also be made before committing, and I hope that the final move will happen next week. I'd like to thank Maciej (reavertm), Ben (yngwin) and Samuli (ssuominen) for their precious help on this. (P.S. This is one of the very few moments that I felt I did some Gentoo development instead of KDE packaging, if you know what I mean )

Qt Team meeting Log and Summary
KDE Team meeting Log and Summary

=-=-=-=-=
Powered by Blogilo

04 Mar 2010 9:36pm GMT

We're introducing a new category dev-vcs keeping version control focused utilities today and will be moving packages (like Subversion, Git and the like) over step by step. Moving packages involves quite a few steps and has high potential to break things so please give us some time to complete this.

If you happen to run into trouble due to the ongoing move please file a bug and make #56967 depend on that one. Thank you!

04 Mar 2010 8:17pm GMT

There is quite some stir right now in the gentoo-dev mailing list following a mass-masking and for removal of packages for QA and security reasons; I think that Alec nailed down most of the issues with his comments:

> This thread is yet another proof that we need to introduce a "Upcoming
> masking" for unmaintained packages.

<sarcasm>

Shall I file those forms in triplicate and fax them to the main office sir?

</sarcasm>

Since amazingly I actually started the Treecleaners project; the
intent was actually to fix problems with packages. Part of the
problem is that there are hundreds of packages in the tree and the
fixes vary in complexity so it is difficult to create hard-and-fast
rules on when to keep a package versus when to toss it. One of the
things I like about masking is that it quickly gets people who
actually care about the package up to bat to fix it instead of leaving
it broken for months. I realize maintainers do not exactly enjoy this
kind of poking, however when things have been left for long enough I
believe our options become a bit more limited (in this case, masking
for removal due to unfixed sec bugs.)

Now, this is one issue I already partly addressed in my post about the five minutes fix myth but I'd like to remind again that even though we can easily spot some blatant problems with packages, having a package that compiles and that passes the obvious, programmatic QA checks does not really tell you much about the health status of the package; indeed, you won't know whether the package works at all for the final users. Tying to another post of mine (incidentally, someone complained about my self-reference to posts… should I stop giving pointers and context?), I have to admit that sometimes it's impossible to have a 100% coverage of packages, among other reasons because some packages need particular hardware, or particular software components set up, to be able to test them effectively. On the other hand, when such a complex setup isn't strictly needed, we should expect some level of testing when making changes, minor or otherwise.

Sometimes, the mistakes are in the messages logged by the ebuild, at other times, the problem is that some important part of the package is missing, for example because the install phase is manually written in the ebuild, and upstream has added some extra utility that is installed by make install but is obviously ignored by the ebuild (and this actually is one of the points that Donnie brought up when I suggested to override upstream build systems with an eclass: we'd have to triple-check the new releases to make sure that no further source files or objects or libraries were added from the previously-packaged version). All these things are almost impossible to identify in a nice, programmatic scripted way, and need knowledge of a package, checking the release notes having an idea how to test the package.

For instance, I've been looking into sys-libs/libnss-pgsql today, as I have an interest on it; the ebuild installs the shared library manually (skipping libtool's relinking phase, by the way); why did it do that? It takes four steps rather than the one needed for make install… well, the reason was obvious (but not commented upon!) after changing it to use make install: a post-install check actually aborted the merge: the problem was that the package installed the Name Service Switch library in /lib, but also installed the static archive and the libtool .la file, both of which are definitely not needed in /lib. The handwritten install solution solves the symptoms but not the following problems:

• it will still build the static archive (non-PIC) version, causing twice the number of compiler calls;
• it won't tell upstream that they forgot one thing in their Makefile.am;
• it's still wrong because the libraries it links to are not available in /lib: it won't be working before mounting /usr if /usr is on a different partition (who does still do that, nowadays?!) - it should be in /usr itself, at this point (and yes, you can do that: both GNU libc and FreeBSD - which has a different NSS interface by the way - check both /usr and /usr/lib).

Incidentally, why does glibc's default nsswitch.con use db files for services, protocols, svc and ethers? Their presence in there means that each time you call into glibc to resolve a port name, it makes eight open() syscalls trying to find the file. It doesn't sound too right.

I have patches, and I have a new ebuild, I'll see to send them upstream and get it committed (by someone else, or by picking maintainership for it) in the next day or so. In the mean time I have to get back to my work.

04 Mar 2010 7:12pm GMT

Well, today I am gonna focus on two different types of packages. Those who never had a maintainer and those abandoned by their initial maintainers.

Looking through bugzilla, you might notice that some of the bus are assigned to maintainer-wanted herd. This means that those packages are seeking for a gentoo developer or a gentoo-user ( acting as proxy-maintainer ) to take care of them and push them on tree or Sunrise. So if you file a bug for a new ebuild, we will probably assign it to that herd and wait until somebody picks it. Personally, I go through that list once a while and pick up interesting packages but I don't know if the rest of the devs are in the same path. If you feel like a package is really cool and we should really have it on tree, feel free to write an ebuild for it and then commit it on Sunrise or poke me and I will commit it on tree (after we review it) and I will add you as proxy-maintainer

The maintainer-needed packages are orphan packages on tree. This is because their initial developer got bored taking care of them or because this developer has been retired. Hence nobody is taking care of them, nobody bumps them, nobody fixes the various bugs which pop up from time to time. Again, I go through that list and either remove them on behalf of treecleaner project or fix them on behalf of QA project. So the question is:

Can you help? If you file a bug on a maintainer-needed package, most likely nobody will fix it. But if you attach a patch that actually fixes the problem, then a guy from treecleaners/QA project will probably pop up and commit your patch. Congruts, you saved a package from being removed. Simple?

In order to help you, I will give you the two URLs from gentoo bugzilla I use to track maintainer-needed and -wanted bugs

* maintainer-needed

* maintainer-wanted

Happy bug fixing

04 Mar 2010 7:32am GMT