I have just committed gentoo-sources-2.6.32-r4 to the tree.

This kernel uses genpatches-2.6.32-5 and includes the following:

linux 2.6.32.1
linux 2.6.32.1
linux 2.6.32.2
linux 2.6.32.3
linux 2.6.32.4
linux 2.6.32.5
linux 2.6.32.6
linux 2.6.32.7
linux 2.6.32.8
A transmit hang fix for broadcom 5906

And the normal patches we always carry over such as fbcondecor, etc.

So, for the first time in my life, if we exclude the local Linux Day events, I attended a conference! FOSDEM 2010 has been my first time properly meeting other developers out there. It actually was a bit more travel than just Bruxelles, for me; I actually took a long way to get there. Since I was still afraid of planes, I didn’t want to go up there alone. Add to that, the fact that I’m neither used to Bruxelles area, nor I speak any decent French any more (I studied it in middle-school, so I could at least ask for, and listen to, directions, but in over ten years not using it, it really just went away), so I got there with Luca who lives in Turin (in the other side of Italy).

The end result looks something like this: I left Mestre (the Venice inland city, which is where I actually live) by train, I changed in Milan, then arrived in Turin; I went to dinner with some friends I only met online before (colleagues and fellow Ultima OnLine players), and slept at Alessandro’s – from lscube – flat. In the morning me and Luca took the plane for Rome, then changed to the one for Bruxelles. Our luggage decided to take a later plane (d’oh!). The same travel (minus the luggage nuisance, fortunately) applied to the way back. This resulted in something like five trains (one from the Bruxelles Airport to the Gare du Nord — we took a cab to go back), and four planes. I think my fear of planes was totally cured this time.

FOSDEM itself was lots fun! I finally met lots of other Gentoo developers (including Luca for the first time), the other FFmpeg guys, some of the VLC guys, and quite a few users who knew me, even though I didn’t know them before, which I have to say has a nice feeling to it. And I even met with a Mono team delegation, and with the one guy that I had a rough start with – Jo Shields, “directhex” – I should report every misunderstanding is cleared. I was also able to (very briefly) meet Lennart, but that was when me and Luca really had to hurry to catch our plane back.

I really would have liked to stay the whole Sunday and leave on Monday, but Luca was actually due to be back in Turin for other reasons, so we had to live early on Sunday to get back to Italy before all planes stopped flying.

Now, during FOSDEM I picked up a few extra tasks other than all the stuff that I’ve had already planned, and this means that the next few days will get me almost no time to breath, to take a break, or to go out with friends. That’s fine, I had four days that relaxed me quite a bit, so this is not too bad to do. Just so I can name some of the tasks that I’m looking forward for, beside the key signing (that was a “cool” party… even though it was maybe too cold), is writing something more about release notifications as it seems like I’m not the only person having a problem with that, trying to write some more about upstreaming patches, and packaging SIP Communicator – a demo of which was available next to the FFmpeg stand in the AW building… looked very promising, and getting an hash table implementation in libavutil for FFmpeg, so that we can use it on feng and libnemesi and thus get a good parser, finally!

Anyway this is enough for today, hope the other people at FOSDEM found it at least as fun, for me is time to hit (finally, my) bed.

Some of you who follow me on twitter might remember something I tweeted about on Feb 6th:

Crap. Bought the wrong book on Infibeam and there's no way to cancel after making payment. Worse, I already have this book x-( #fail

This is essentially what happens when you buy stuff on the Internet at 5am after not sleeping all night preparing for an exam. I selected the (wrong) book, paid for it using Paypal, and soon afterwards, realised that I wanted the second part of this book (Foundation Analysis). Checked their FAQ to find to my dismay that they don't support cancellation of orders after payment has been made.

Needless to say, I'm a student, and students are poor(er). So I was sitting around semi-depressed wondering how to sell the book off at a minimal cost loss after I get it. On a whim, I decided to tweet about it (I generally don't tweet much; mostly passive reading).

After giving my exam, I noticed two missed calls on my phone from a strange number. I decided to wait for them (whoever they were) to call me again. A couple of hours later, I get another phone call; but this time it gets cut before I can pick it up. A few minutes later I get the following email:

Dear Nirbheek Chauhan ,

Order Id : [REMOVED]

Title : [REMOVED BOOK TITLE]

We have received your request for cancellation of above order through twitter.com. So we are offering you your ordered amount as prepaid credit to your Infibeam account which can be used for next purchase.

Please allow us for the same. So we can credit your account accordingly.

We also tried to reach you through given no. [REMOVED MOBILE NO.], but could not get response.

Thank you for shopping with us! You can contact us anytime using http://www.infibeam.com/ContactUs.action

Sincerely,

Infibeam.com Customer Service
Fresh Way to Buy, Sell and Rent

My reaction -- :O :D :O :D

Yesterday evening, they cancelled my order and refunded the amount I had paid as prepaid-credit which I can now use to buy the other book that I wanted to buy!

I don't know about you, but I'm very impressed by their customer service. The fact that they took the initiative to monitor twitter for tweets mentioning "Infibeam" for any problems that users face is a strong indication that they aren't just some random E-Store. They have definitely made permanent customer out of me!

On a related note, I've found that their book prices are usually less than or equal to those on flipkart.com . Another reason to use them ;)

After reading a lot about interesting stuff happening at this years FOSDEM, I decided very short term to go there. The FOSDEM in Brussels is probably one of the biggest (if not the biggest at all) meetings of free software developers. Unlike similar events (like several Linuxtag-events in Germany), it's focus is mainly on developers, so the talks are more high level.

My impressions from FOSDEM so far: There are much more people compared when I was here a few years ago, so it seems the number of free software developers is inceasing (which is great). The interest focus seems to be to extend free software to other areas. Embedded devices, the BIOS, open hardware (lot's of interest in 3D-printers).

Yesterday morning, there was a quite interesting talk by Richard Clayton about Phishing, Scam etc. with lots of statistics and info about the supposed business models behind it. Afterwards I had a nice chat with some developers from OpenInkpot. There was a big interest in the Coreboot-talk, so I (and many others) just didn't get in because it was full.

Later Gentoo-developer Petteri Räty gave a talk about "How to be a good upstream" and I'd suggest every free software developer to have a look on that (I'll put the link here later).

I've just attended a rather interesting talk about 3D-printers like RepRap and MakerBot.

In this podcast comprookie talks about learning Python as a group, and his Gentoo unslacking.

Slacker
The term slacker is commonly used to refer to a person who avoids work (especially British English), or (primarily in North American English) an educated person who is viewed as an underachiever. Slackers, understood mostly as males in their twenties and thirties, or older may be regarded as belonging to an antimaterialistic counterculture, though in many cases their behavior may merely be due to apathy or laziness.

LINKS:
Slacker
http://en.wikipedia.org/wiki/Slacker

Fedora Bugzilla
http://fedoraproject.org/wiki/Bugzilla

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

Hey, stop slacking!

Since I moved to Linux OS ( 5-6 years ago ) I use KDE as my main DE. This wasn’t a random choice, since I ‘ve tried or at least seen all the others main DEs such as xfce and Gnome. KDE is so much beautiful and convenient that I never bothered searching for something else. This is because my main activity on computers was purely based on multimedia entertainment despite the fact that I had to deal with a heavy load of University projects. Since I finished University , and dedicate most of my free time on Gentoo and other Open Source activities, I started to use more and more utilities designed for such things, such as Qt-creator, version control systems, ssh connections to various servers etc.

It is pretty clear that a eye-candy desktop enviromment couldn’t be as much beneficial as I wanted. Hence I had to search for an alternative. A minimalistic desktop or WM allowing me to take advantage of every single pixel of my 19” monitor and don’t waste them with various widgets and stuff would be ideal.

I tried fluxbox at first but I wasn’t too fond of it because it looked kinda ugly by default and I just couldn’t get along with it. So next thing to try was Openbox. I was quite surprised to see that I could tweak it and tune it up by simply editing 3 files located at ~/.config/openbox

Having created my shiny menu.xml and autostart.sh files, I emerged obconf in order to perform that last tweak on my new enviromment.

I plan to migrate my laptop to openbox as well since it looks and feel quite fast and light . Exactly what I was searching for my “tired” laptop

To conclude with, I added fluxbox-9999 and obconf-9999 packages to gentoo tree since I wanted to try the latest version of those two packages and I guess our users will like that as well.

So, enjoy

Refs:

Gentoo Openbox Documentation

Gentoo Openbox wiki

Now that the latest bugfixes have received a positive response it’s time to share them with a wider audience, i.e. with you: layman 1.3.1 out now. Thanks go to Dmitry Karasik and Jimmy Jazz.

Summary

layman-1.3.1 is a bugfix release: Adding/deleting/syncing overlays did not work in all cases.

Details

• Fix handling of CVS overlays (bug #301689)
• Fix handling of non-existing overlays (bug #301612)
• Now delete empty overlay directories (bug #301612) ..
  • on deletion of a non-existing overlay and
  • after failed addition of an overlay.

How to upgrade

1. Unmask =app-portage/layman-1.3.1 if you’re on stable
2. sudo emerge -av =app-portage/layman-1.3.1
3. sudo etc-update
   

I was thinking about my earlier blog post about my ideas for the new packages site I'm still working on, and I realized that to a lot of people it must seem like I sure promise a lot of stuff, but then never get around to really completing it.  I wanted to address that a bit, since I imagine that at times I'm either confusing or frustrating some people.

First of all, I get a lot of ideas to do a lot of projects.  There's lots of cool stuff I want to do, and I have a hard time saying to myself "I have enough projects already in the works to finish, better not start another one," but I do anyway.  I tend to quickly overload myself sometimes that way, which can be bad for everything.  However, one thing I'm getting more strict on is only picking up projects that I'm sure I want to complete, that I'll see through until the end.  I very rarely, if ever, completely drop a project that I've started.  I will tend to put them on hold for a while -- sometimes years -- but I'll eventually revisit the idea (heck, the packages website is a perfect example of that).

I have a ton of projects I'm "working on," though.  So many, that I'm honestly afraid to write them all down for fear of being totally overwhelmed by the responsibility I put on myself for them.  I do, however, plan on getting them all done, and they circle around in my head on a regular basis, and often times I think of ways to integrate two projects (for example, adding an option to search gentoo planet(s) from the packages site).  I get a lot of interesting ideas all the time, but I really have to be careful not to overextend myself.

One thing I've been trying to do recently (as in the past year) is slowly shutter off some of the support I've been providing for the Gentoo tree directly, and ebuilds / herds I've in the past taken close care of.  It occurred to me way back when that it'd be a more efficient use of my time if I built out some project websites (like the packages one) rather than trawling the tree looking for ebuilds to fix, bump and repair (for example).  Not that I mind doing that, mind you, in fact I find it rather relaxing at times, but what's happened is that I've overextended my responsibilities again, and I'm trying to cut back.  Basically, my thought is that while I want to still work on Gentoo for a while, I don't want to make a career out of it.

Oddly enough, though, part of the reason I'm doing these community projects is so that I can more efficiently do other ones.  For example, at times I like to go through the multimedia packages and just check them to make sure we aren't missing version bumps, and go fix small bugs that I can take care of and just little stuff that isn't really important (in a sense of package popularity) but still relevant to a few users.  Those are fun.  But it'd make my life easier if I could more quickly track what has been neglected, more easily see what available version bumps are available (I still wanna hook into GnomeFiles and track their changes, for example), and stuff like that.  A lot of the tree-fixing stuff in Gentoo development is just monotonous, which is why it's hard to find volunteers to do it.  There's a good chunk of it that is just boring work!  And I'd like to help streamline that a bit.  That's one of my big goals.

With that goal in mind, a huge reason for doing the packages site was just so I can have a simple interface to get all the information I need, and finally a standardized set of data for categories, packages and versions.  That's mostly done, or at least the framework is, so now I can get going on the *really* cool stuff.  What I've done so far is really just the tip of the iceberg.

Anyway, I didn't wanna talk about just the packages site.  There's lots of other stuff I have going on.  It's interesting, even to me, to see which ones I'll want to juggle at a time.  I switch between them on a regular basis.  Sometimes I'll be working on the packages site, then my DVD ripper, then my scriptures stuff, then I'll work on theology ebuilds, then sound ones, then I'll look after ALSA, then mplayer, then I'll go back to tweaking MythVideo a bit, and round and round and round it goes.  I'm always working on *some* project, that's for sure.  It might do me some good to try and get a bit more organized, but I don't even do a good job of keeping track of bugs in my own projects.  I just track them internally for the most part.

So, I apologize for the epic behind status that I'm always in.  I'm starting to recognize more and more how much I'm holding people up on some projects, so I'm doing my best to gracefully exit those areas so someone else can come in and take over.  I'm still fumbling a bit at the best way to do that, but at this point in my life I have at least recognized the few areas that I'm sure I'm not passionate about anymore, and shouldn't be lazing around just pretending to commit once in a while -- of which, there are actually really few.  In fact, I can only think of one off the top of my head.

One thing that might be cool that I just thought of -- have a status indicator on my blog or something that displays the current project I'm working on.  That'd be fun.   Sounds like work, though.  I'm gonna go watch a movie.

So, I was working on Znurt this morning (I woke up unusually early, and didn't wanna go back to sleep).  I'm getting close to opening the codebase, but before doing that, there's some really obvious glaring deficiencies that I want to clean up first.

The big thing I've been working on with the packages site now is making it more efficient.  The first step in that has been gathering some data on how often certain things are being called to see where optimizations are most needed.  So, the other day, I added a counter to the constructor of each class that would just tally each time the class was instantiated, and then I'd dump out the counter at the end of an import run.

One thing that surprised me is how often one particular class was being called -- PortageTree.  It's a really simple class, and all it does is set down some really simple variables that aren't going to change at all once they are declared, such as the location of the portage tree and it's metadata cache on the filesystem.  Pretty much used across the board on a lot of other classes that need to know the filesystem location of files (PortageCategory, PortagePackage, etc.).

Well, being still pretty new and fuzzy to the OOP approach, I thought it made sense to just extend the PortageTree class on PortageCategory and call the parent constructor to get the variables set.  That ended up in that class being created a huge magnitude of times,  all for the same pretty much unchanging variables.

So, I switched it this morning to use a singleton instance instead, so the class is only being created once and referenced thousands of times each import.  Much nicer already.

It's stuff like that that makes me wish I knew more about OOP.  I am studying it on and off, but there's still some concepts that I just can't wrap my brain around at times, like exceptions.  In my procedurally-attuned programming frame of mind, every time someone explains them to me, I think ... "Well, if something *breaks* why don't you just work with the return codes and work around that?"  So, yah.  Some stuff is still lost on me.  I'm trying to figure it out though.  Maybe it's one of those things that doesn't make sense so much when you apply it to PHP and it's general usage of websites.  A lot of the stuff I read about, I think how it would make much more sense if it were an actual application running.

Anyway.

On a totally different note, one thing I want to look at getting into the packages website is tracking a changelog of all the package's keywording history.  Right now, the import process is pretty simple -- if the content of the ebuild has changed, then the old one is marked for removal and an entirely new ebuild record is created in the database.  The reason for that is because that is far easier to do than it would be to examine all the myriad of data that is associated with one ebuild, track the changes, and then flag those.  Instead, I just dump the old one and treat the new one as a completely new record.

There's a tradeoff in the compromise, though, because instead of tracking ebuild modifications, I have to do all this coding to flag packages and ebuilds that things have changed and to treat them as an update instead of a new one.  That was tricky to get setup right, and getting that stuff in there in fact was one of the main things that pushed the initial launch back.  It was just one of those things that I couldn't run into the bugs until I started actually doing  a sequence of import runs, since they wouldn't show up until then anyway.

But, I'd like to start at least tracking the ebuild keyword status changes.  The reason is because that is really valuable data that can provide an excellent set of reports.  For instance, we can see which categories / packages / herds are getting ignored historically as far as stabilization.  Plus you can do cool stuff like import results from a statistics tracker as far as what people have installed, and you can start to see where maybe the tree could use a little more love.  And, it would help contributors who want to help out, but are overwhelmed by the enormity of bugs and packages and issues that need to be addressed.  I could see it being helpful saying, "here's an area that is suffering from neglect *and* is popular."  That would be cool.  And that's my goal.  In fact, that's *been* my goal for years.  I'm just now getting to the point where it's becoming possible, though.

Fun stuff.  I gotta hone my coding skills as I go, though.

Yes, I am going.

As the Android kernel code is now gone from the Linux kernel, as of the 2.6.33 kernel release, I'm starting to get a lot of questions about what happened, and what to do next with regards to Android. So here's my opinion on the whole matter...

See more ...

I migrated the packages website to a new server this weekend, and so far I'm really glad with the setup. I originally planned on having the whole thing setup in a short time, but I went with a different web server setup this time around. Instead of using lighttpd for the server, I went back to apache, but this time with mod_fastcgi to run PHP. From what I've read, PHP doesn't like threading too much, so running at as CGI instead should avoid any possible headaches. We'll see. So far, the site is far more responsive than everything else I've tried, so I'm happy.

I feel bad about how things have gone so terrible since the initial launch of the site. I really was not ready for the massive load, and my interim solutions were just slow and clunky. Hopefully things should be much happier now.

There's still a lot of silly bugs in the code that I need to fix. I just found another one this morning where the caching is breaking if you change your architecture selection around. Oy. I'd like to get to them, but I've been pretty swamped for time lately, between starting a new job this month and dividing my remaining time doing consulting work for two other companies.

Having a break from it though has been kind of good. I've already thought of a few optimizations that I can throw in there that are kind of like, "well, duh" type stuff I can't believe I didn't think of. For example, one way that I check to see if an ebuild is new is to see if the file mtime has changed. I don't know why it never occurred to me to just read the Manifest file and see if any of the hash sums have changed. That'd save me a lot of time.

I've been poked a few times about getting the code in a live repo somewhere, too. I guess that's coming soon, assuming I can get around to it. Personally, I don't like the idea of doing it when I *know* my code is in some ugly stages, but whatever. I need to learn how to setup a git repo anyway.

Oh yes, that reminds me. I also moved all the Planet Larry stuff onto the same server. Everytime I poke at the site, all I can think about is how much of an overhaul the whole thing needs. I'm totally embarrassed that I haven't even switched over to using Gravatar yet.

My goal is to ditch the planet software and write my own software to pull in the feeds, drop them in a database, and have the whole thing searchable. Then build a user admin section as well so users can manage their feeds themselves, and stop waiting on me. I'm planning on making that my next project, once Znurt gets to a better stage of stability.

Right now, though, I just did some minor tweaks. I got rid of the subdomains, and all the other projects on the site that I let atrophy, so planet is just available now at http://larrythecow.org/

At least since 2005 it's well known that the cryptographic hash function SHA1 is seriously flawed and it's only a matter of time until it will be broken. However, it's still widely used and it can be expected that it'll be used long enough to allow real world attacks (as it happened with MD5 before). The NIST (the US National Institute of Standards and Technology) suggests not to use SHA1 after 2010, the german BSI (Bundesamt für Sicherheit in der Informationstechnik) says they should've been fadet out by the end of 2009.

The probably most widely used encryption protocol is SSL. It is a protocol that can operate on top of many other internet protocols and is for example widely used for banking accounts.

As SSL is a pretty complex protocol, it needs hash functions at various places, here I'm just looking at one of them. The signatures created by the certificate authorities. Every SSL certificate is signed by a CA, even if you generate SSL certificates yourself, they are self-signed, meaning that the certificate itself is it's own CA. From what I know, despite the suggestions mentioned above no big CA will give you certificates signed with anything better than SHA1. You can check this with:
openssl x509 -text -in [your ssl certificate]
Look for "Signature Algorithm". It'll most likely say sha1WithRSAEncryption. If your CA is good, it'll show sha256WithRSAEncryption. If your CA is really bad, it may show md5WithRSAEncryption.

When asking for SHA256 support, you often get the answer that the software still has problems, it's not ready yet. When asking for more information I never got answers. So I tried it myself. On an up-to-date apache webserver with mod_ssl, it was no problem to install a SHA256 signed certificate based on a SHA256 signed test CA. All browsers I've tried (Firefox 3.6, Konqueror 4.3.5, Opera 10.10, IE8 and even IE6) had no problem with it. You can check it out at https://sha2.hboeck.de/. You will get a certificate warning (obviously, as it's signed by my own test CA), but you'll be able to view the page. If you want to test it without warnings, you can also import the CA certificate.

I'd be interested if this causes any problems (on server or on client side), so please leave a comment if you are aware of any incompatibilities.

Update: By request in the comments, I've also created a SHA512 testcase.

Update 2: StartSSL wrote me that they tried providing SHA256-certificates about a year ago and had too many problems - it wasn't very specific but they mentioned that earlier Windows XP and Windows 2003 Server versions may have problems.

This year’s FOSDEM is just around the corner! (February 6th/7th, Brussels, Belgium)

A lot of interesting talks and presentations will take place and I’m pretty sure there’s going to be a lot of beer too! ^_^

Many Gentoo Developers will be there for the whole weekend, including me

See you all there

In the early hours of this morning, a spammer managed to get the IP of the Gentoo list server on the NiX Spam RBL... simply by spamming the subscribe address :-(. This caused approximately 2000 deliveries of normal list mail to be rejected while the server was present on the RBL.

Notice the subscribe request, line 0004. (whitespace added)

0001 Feb  1 00:15:56 pigeon postfix/smtpd[29314]: 52278E0778: client=unknown[210.212.220.106]
0002 Feb  1 00:15:57 pigeon postfix/cleanup[31589]: 52278E0778:
  message-id=<01caa301$d307f7d0$b173a8c0@ambachglasfaser>
0003 Feb  1 00:15:58 pigeon postfix/qmgr[12260]: 52278E0778:
  from=<ambachglasfaser@test.mailnet.dyndns.biz>,
  size=59874, nrcpt=3 (queue active)
0004 Feb  1 00:15:58 pigeon postfix/local[31581]: 52278E0778:
  to=<gentoo-embedded+subscribe@lists.gentoo.org>,
  orig_to=<gentoo-embedded-subscribe@lists.gentoo.org>,
  relay=local, delay=2.4, delays=2.4/0/0/0.01, dsn=2.0.0, status=sent (delivered to command: ....)
0005 Feb  1 00:15:58 pigeon postfix/local[31716]: 52278E0778:
  to=<gentoo-user-id@lists.gentoo.org>,
  relay=local, delay=2.4, delays=2.4/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to command: ....)
0006 Feb  1 00:15:58 pigeon postfix/local[31509]: 52278E0778:
  to=<gentoo-gwn@lists.gentoo.org>,
  relay=local, delay=2.4, delays=2.4/0.01/0/0.02, dsn=2.0.0, status=sent (delivered to command: ....)
0007 Feb  1 00:15:58 pigeon postfix/qmgr[12260]: 52278E0778: removed

Assuming that the it's a real subscribe request, we send a confirmation request, and promptly get blacklisted for being a good citizen. Line 0013.

0010 Feb  1 00:15:58 pigeon postfix/smtpd[31587]: B6FA9E0778: client=localhost[127.0.0.1]
0011 Feb  1 00:15:58 pigeon postfix/cleanup[31589]: B6FA9E0778:
  message-id=<1264983358-31717-mlmmj-3905840d@lists.gentoo.org>
0012 Feb  1 00:15:58 pigeon postfix/qmgr[12260]: B6FA9E0778:
  from=<gentoo-embedded+bounces-confsub-32dfa15d1a18a7a9-ambachglasfaser=test.mailnet.dyndns.biz@lists.gentoo.org>,
  size=1345, nrcpt=1 (queue active)
0013 Feb  1 00:16:29 pigeon postfix/smtp[31603]: B6FA9E0778:
  to=<ambachglasfaser@test.mailnet.dyndns.biz>,
  relay=mx.dyndns.biz[217.11.54.110]:25, delay=31, delays=0.06/0/30/0.41, dsn=5.7.1,
  status=bounced (host mx.dyndns.biz[217.11.54.110] said:
    554 5.7.1 Service unavailable; Your spam message has been received.
    You will be blacklisted. Thank you (in reply to end of DATA command))
0014 Feb  1 00:16:29 pigeon postfix/bounce[31637]: B6FA9E0778: sender non-delivery notification: B8AE9E089A
0015 Feb  1 00:16:29 pigeon postfix/qmgr[12260]: B6FA9E0778: removed

Why did this happen? I do agree on the importance of spamtrap accounts, but they MUST check the content of their messages. A list confirmation message MUST NOT be considered as spam.

The original subscribe request came from what seems to be a compromised server in Secunderabad, India. So it wouldn't have been detected by RBL focused on modem/dialup addresses.

Short of raising the bar to subscribe (with a specific token that needs to be included, and then it's only a matter of time till spammers include it too), there isn't much we can do to block stuff like this at the list-server level. There is no way to detect than an address is a spamtrap. There cannot be by definition, as the spammers would avoid it themselves otherwise.

You might have noticed that I started moving (renaming) Ruby packages, both with old and new ebuilds, to drop the ruby- prefix from packages such as ruby-mmap, ruby-bz2 and ruby-fcgi. My reason to proceed in this way is not only to avoid duplication, but to have an extra safety that the name of the ebuild is going to correspond (minus casing, most of the time) with the gem’s name. This gets even more important since the fakegem eclass will default to use the ${PN} variable to do its magic tricks for fakegem handling.

But the tipping point for this set of changes (which aren’t really easy, nor transparent) has been the dev-ruby/ruby-fcgi package we used to ship. Even Alex assumed that the gem it referred to was ruby-fcgi that exists, but in truth it has always simply been fcgi which is a different gem. To avoid these possible collisions in the future, the rule is going to be “use the original naming, don’t add prefixes!”. Obviously there are and there will be exceptions, such as the jruby-debug-base package that installs a gem named ruby-debug-base (this is to sidestep the dependency tracking in the original ruby-debug to let it load the JRuby specific code instead).

This post is not, though, about the naming scheme, but rather should give you an idea why we still haven’t unleashed Ruby 1.9 not even as a secondary Ruby implementation (while JRuby is). You can easily read around the net that “@$package@ now supports Ruby 1.9”… sometimes it’s true, sometimes it definitely is not. For instance when they say that Rails 2.3.5 supports Ruby 1.9 officially, they fail to tell you that builder (which is bundled by activesupport — and slightly patched, but we’re going to count the patched version anyway) looks pretty broken on Ruby 1.9, assuming its testsuite works as intended, which is what appears to me. And the rest of the code does not seem to be much better: tmail fails its tests, among many.

In the case of fcgi (which used to be mandatory dependency of rails 2.3.5 in Gentoo, although I’ve dropped it in the ruby-ng port, as it’s not really that needed, and the gem itself does not depend on it), the original code (version 0.8.7) does not work on Ruby 1.9. And we knew that, Alex added a 1.9 compatibility patch in Gentoo before: it built, and we shipped it, but… was it tested? Nope, since the old eclasses had no support for testing. Actually, I hit this problem when, a few months ago, I added a further safety check for Ruby 1.9: the linked extensions are built with --no-undefined so that eventual undefined symbols won’t cause Ruby to abort at runtime (which happened to me before). Indeed, even though the extension “compiled”, it left the undefined symbols, so it could never be loaded properly at runtime, because the function it used are Ruby 1.8-only and not defined in 1.9 at all. At the end – both on the in-tree ebuild, and in the testing overlay for the new eclasses – I ended up disabling the native extension for anything that is not Ruby 1.8 (there is a pure ruby, slower implementation that works even on Ruby 1.9 and JRuby).

But that’s for the “old” fcgi gem, let’s look at the description from the new one (emphasis mine; grammar quoted):

FastCGI is a language independent, scalable, open extension to CGI that provides high performance without the limitations of server specific APIs. For more information, see http://www.fastcgi.com/. This is the fork of fcgi implementation for ruby but with ruby1.9 – ruby1.9.1 compability

So this should actually have the extension working correctly with Ruby 1.9, you’d say. After all, the previous pure Ruby extension worked fine already, nothing to do there. Okay, so let’s build it (after fixing a three years old bug):

make -j12 -s 
fcgi.c: In function ‘fcgi_stream_puts_ary’:
fcgi.c:285: warning: implicit declaration of function ‘rb_inspecting_p’ [-Wimplicit-function-declaration]
fcgi.c: In function ‘fcgi_stream_puts’:
fcgi.c:309: warning: implicit declaration of function ‘rb_protect_inspect’ [-Wimplicit-function-declaration]
fcgi.o: In function `fcgi_stream_puts&apos:
/var/tmp/portage/dev-ruby/ruby-fcgi-0.8.9/work/ruby19/ruby-fcgi-0.8.9/ext/fcgi/fcgi.c:309: undefined reference to `rb_protect_inspect&apos
fcgi.o: In function `fcgi_stream_puts_ary&apos:
/var/tmp/portage/dev-ruby/ruby-fcgi-0.8.9/work/ruby19/ruby-fcgi-0.8.9/ext/fcgi/fcgi.c:285: undefined reference to `rb_inspecting_p&apos
/var/tmp/portage/dev-ruby/ruby-fcgi-0.8.9/work/ruby19/ruby-fcgi-0.8.9/ext/fcgi/fcgi.c:285: undefined reference to `rb_inspecting_p&apos
collect2: ld returned 1 exit status
make: *** [fcgi.so] Error 1

Guess what? that’s the same problem that the old fcgi had with Alex’s patch. It only fails at build time with the Gentoo version of Ruby 1.9 as we’re forcing --no-undefined, on other Ruby 1.9 packaging, you’ll get this to build… and then kill your Ruby process at runtime. So no, this gem is definitely not compatible with Ruby 1.9 even though it is stated so.

Now, there is another fork of the classic fcgi gem, with version 0.8.8, what does change in that? Well the first problem is that the content of the gem has not changed the version at all:

flame@yamato fcgi % egrep &apos0\.8\.[78]&apos . -r
./README:Version 0.8.7

Is this enough to mutter “boooooring”? Maybe, but to be fair, let’s try building for Ruby 1.9:

flame@yamato fcgi % ruby19 extconf.rb 
checking for fcgiapp.h... yes
checking for FCGX_Accept() in -lfcgi... yes
creating Makefile
flame@yamato fcgi % make
x86_64-pc-linux-gnu-gcc -I. -I/usr/include/ruby19-1.9.1/x86_64-linux -I/usr/include/ruby19-1.9.1/ruby/backward -I/usr/include/ruby19-1.9.1 -I. -DHAVE_FCGIAPP_H    -fPIC -march=barcelona -O2 -ftracer -pipe -ftree-vectorize -floop-block -g -ggdb -Wstrict-aliasing=2 -Wno-format-zero-length -Wformat=2 -Wno-error -Wno-pointer-sign -fdiagnostics-show-option -fno-strict-aliasing -O2 -g -Wall -Wno-parentheses  -fPIC  -o fcgi.o -c fcgi.c
fcgi.c: In function ‘fcgi_stream_puts_ary’:
fcgi.c:276: warning: implicit declaration of function ‘rb_inspecting_p’ [-Wimplicit-function-declaration]
fcgi.c: In function ‘fcgi_stream_puts’:
fcgi.c:300: warning: implicit declaration of function ‘rb_protect_inspect’ [-Wimplicit-function-declaration]
x86_64-pc-linux-gnu-gcc -shared -o fcgi.so fcgi.o -L. -L/usr/lib64 -Wl,-R/usr/lib64 -L. -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--sort-common -rdynamic -Wl,-export-dynamic -Wl,--no-undefined    -Wl,-R -Wl,/usr/lib64 -L/usr/lib64 -lruby19 -lfcgi  -lpthread -lrt -ldl -lcrypt -lm   -lc
fcgi.o: In function `fcgi_stream_puts&apos:
/home/flame/mytmpfs/fcgi/ext/fcgi/fcgi.c:300: undefined reference to `rb_protect_inspect&apos
fcgi.o: In function `fcgi_stream_puts_ary&apos:
/home/flame/mytmpfs/fcgi/ext/fcgi/fcgi.c:276: undefined reference to `rb_inspecting_p&apos
/home/flame/mytmpfs/fcgi/ext/fcgi/fcgi.c:276: undefined reference to `rb_inspecting_p&apos
collect2: ld returned 1 exit status
make: *** [fcgi.so] Error 1

Okay so we’re back to the same problem, even this version which is supposed to be fixed to work with Ruby 1.9… is simply not, it’s a bundling together of the old code and some patch, the same patch that Alex used, maybe even picked up from Gentoo in the first place. Now, I can’t just reduce from this that all the compatibility with 1.9 is done this way, but it sure should tell you a lot about what “Ruby 1.9-compatible” might mean.

Sigh!

I’m still working hard on my free time on the conversion of Ruby packages to the new eclasses as well as improving JRuby support over the place – for this reason I might do another shameless plug – and in particular, between yesterday and today, I ended up working on a set of packages for packaging bones in Gentoo.

Why is that a set of packages? Well, I had to commit together four different packages: bones, bones-extra, loquacious and little-plugger; a subset of them wasn’t possible at all. There are two interesting things to say about these, if you care about Ruby development. The first is that I wouldn’t actually count bad for it, as what it does is mandating an interface for Gems going a step further than Hoe, Echoe and Jeweler as it encompasses testing, documentation and packaging tasks. The second thing is that it comes from the codeforpeople project which consists of what can only be called a fuckload of different and almost unrelated packages, and as far as I know it used to be manned by a single person. Not even the most friendly of the blokes, to be honest: when I asked him a couple of questions about another project – session – the one-line reply I got was a link to a (newly created) GitHub repository.

Dependency graph for Bones

So what is the problem here? Well, check out the depgraph on this page. I spoke about four packages before, but it lists four, one is not packaged and I’ll probably just package it if I’ll end up using Bones myself. Of the four packages, one is the “interface” one and is Bones itself, two are dependencies, and are generic libraries, the other two are “plugins” (extras and git) that provide optional functionalities; or at least sort-of-extra functionalities. Indeed, the extras plugin provides RSpec testing and RubyForge publishing support, which should probably be considered optional functionalities… on the other hand, if your package uses Bones, and defines the configuration keys for either, it will fail if the extras package is not installed. So much for the extras, then.

The runtime dependencies are actually quite linear: Bones needs the two libraries, and the two plugins need Bones, which is quite logical and very easy to deal with. But when you start considering the build-time dependencies you are way out of luck. All the packages including Bones itself would depend on Bones, and on the extras package (because all of them define the RubyForge project, and almost all use RSpec), for both documentation and testing purposes. Obviously, if you try to install Bones with USE=doc or FEATURES=test, Portage will bail out because of the cyclic dependencies. And I don’t think I can fix it in any way for now. To be honest, this would have been much easier if Bones itself contained what is in the extras, as at that point you would have everything in the same package, which wouldn’t then require itself.

Or would it? To be honest if you look at the development dependencies as listed within the gems, all of the Bones-managed gems will require Bones, and that is true… for Bones as well! Indeed, in the image above, the dotted lines represent the officially-listed dependencies which we’re not following (for some strange, but welcome, reason, the bones-git package is truly optional).

Somehow, it seems like many multi-package projects decided to go with similar ways of handling dependencies. For instance, take prawn, a PDF-writing gem: when I added it to Portage (as dependency of a webapp I worked on last summer), it was a single gem, depending on another gem by the same author for its testing. Now, it’s actually a simple wrapper gem for three split gems… and you most likely will need all of them for doing most non-trivial stuff. Or a much more common gem: Rails! The activerecord, actionpack, activesupport and actionmailer gems are so interdependent that I’m not surprised most projects just bundle Rails in their own sources (albeit this is very bad from the quality point of view).

During summer I got interested in GPS and mapping and bought myself a mtkII based device. For these there is a java app called bt747 in the tree. However I couldn't get it to work - bt747 would not accept the device name I tried to convince it of using.

Turns out that older devices where using a USB to serial converter to provide the USB interface: these show up as /dev/ttyUSBx - with x being an integer. The device I bought is a newer generation who appear to have an on-chip USB port, which will show up as /dev/ttyACMx (x again being an integer). So, support for ttyACMx type devices is needed in BT747. See bug #281888.

It turns out BT747, being a java app, uses rxtx to provide support for serial device communication. So lets fix rxtx - see bug #301126.

Meanwhile there is also mtkbabel in portage, which is not so picky about the device names.

So I finally added lxc 0.6.5 to the tree for all of the Gentoo users to try it if they care; on the bright side, the lxc.mount option seem to finally work fine, and I also found the problem I complained about a few days ago. It is this latter problem that made me feel like writing this half-rant post.

Half-rant because I can see they are going to great extents to improve it from release to release, but still a rant because I think it should have been less chaotic to begin with. On the other hand, I could probably be more constructive if I went on to provide patches… I’ll probably do that in the future if I free myself, but if you follow my blog you know I’m quite swamped already between different things.

Starting from the 0.6.4 release, they dropped the “initialisation” task, and just let you run lxc-start with the config file. It was definitely a nice way to do it, as the init command wasn’t doing anything heavy that shouldn’t be done on first startup anyway. It was, though, a bit of a problem for scripts that used the old method as the simple lxc-start -n myguest (the init step wouldn’t be needed after a restart of the host) would mess up your system badly, as it would spawn a new container using / as the new root… overriding your own system bootup. Thankfully, Andrian quickly added a check that refused to proceed if a configuration file was not given. This does not save you from being able to explicitly mess your system up by using / as your new root, but at least avoids possible mistakes when using the old-style calls.

So what about the 0.6.5 problem? Well the problem came to be because 0.6.5 actually implements a nice feature (contributed by a non-core developer it seems): root pivoting. The idea is to drop access to the old root, so that the guest cannot in any way access the host’s filesystem unless given access to. It’s a very good idea, but there are two problems with it: it doesn’t really do it systematically, but rather with a “try and hope” approach, and it failed under certain conditions, saying that the original root is still busy (note here, since this happens within the cgroup’s mount namespace, it doesn’t matter to the rest of the system).

At the end, last night I was able to identify the problem: I had this line in the fstab file used by lxc itself:

none /tmp tmpfs size=200m 0 0

What’s wrong with it? The mountpoint. The fstab (and lxc.mount commands) are used without previous validation or handling, so this is not mounting the /tmp for the guest, but the /tmp for the host, within the guest’s mount namespace. The result is that /tmp gets mounted twice (once inherited by the base mount namespace, once within the guest’s namespace, but it’s only unmounted once (as the unmount list keeps each mount point exactly once). This is quite an obvious error on my part, I should have used /media/chroots/tinderbox/tmp as mountpoint, but LXC being unable to catch the mistake in mountpoint (at least warning about it) is a definite problem.

Another thing that makes me feel like LXC really needs some polishing is that you cannot just run the commands from the source directory: the build system uses autoconf and automake, but the authors explicitly backed away from libtool as it’s “Linux-only” (which really doesn’t say much about the usefulness of libtool in this case). given I’m not even sure whether the liblxc library is supposed to be ABI stable or not (they have never bumped the soname, but that is suspicious), it might really be better if they used libtool and learnt out to handle it. Also, it uses badly recursive Makefiles, it would probably take just a second to build if I remade the build system as a standard non-recursive autotools package, like udev.

Oh well, let’s hope for the future releases to improve polishing, bit by bit!

One of the problems that we definitely need to hash out before we start marking as stable the ebuilds based on the new Ruby eclasses is the handling of the current “binwrappers”. I dislike the name sincerely — while they are obviously in the bin directory for the gems, they are definitely not binaries, but rather executable scripts. Sigh, let it be for now though.

RubyGems already creates a wrapper by itself, so that it calls the correct (latest) binary for a given gem. On the other hand we don’t use that wrapper, but a different one that can be generated by the ebuild with much more stable targets. The end result is generally pleasing, as we can use the same wrapper for any implementation the gem is installed for. But here start the trouble.

Right now, this works all fine only if the gem is installed for every implementation, or at least every installed implementation. This again is mostly correct for most users as they will only have Ruby 1.8 installed. It starts being a bit different for JRuby, as not all of those scripts can be launched through that (but on the other hand, since we cannot set JRuby up as default Ruby implementation with eselect, it shouldn’t be much of a problem). It will be come a problem when we’re going to have Ruby 1.9 fully supported in Gentoo, as setting it up as default Ruby provider for the system will cause most of the scripts, installed only for Ruby 1.8, to fail.

The problem described above is to be intended when a package lacks an implementation, but conversely the problem applies when a package is available only for an implementation. Take for instance the (for now unpackaged) Duby — a strongly-typed Ruby-inspired scripting language developed by JRuby developer Charles Nutter. It will only ever be available for JRuby (minus possible reimplementations) as it generates Java Bytecode that JRuby can execute. It also has a duby script, but the ebuild I have here installs a broken wrapper: it calls into /usr/bin/ruby, but of course that cannot ever be JRuby, problems ensures.

Another problem is what Hans tried to solve some time ago: when multiple slots of the same gem are installed, and they all install the same named commands, how do you choose between them? Most of the times, you install them slotted, so you got cmd-${SLOT} named commands around, but you also need to have a way to just call cmd and have it work. Hans worked on eselect-gem for that reason: it’s a generic approach to the same thing that eselect-rails does. Right now, we’re not integrating well with that, so we might need to find a way to handle that.

One of the reasons why I’m now writing all this about the wrappers, is that I’d love for people to comment (after looking at the implementation, possibly, as I’d seriously love to avoid noise due to users wishing ponies, or detractors just saying that RubyGems is perfect — it’s not), with possible approaches we can take. So, comments welcome! And you might want to use the typo:code HTMLish tag to submit code via the comments, so that it won’t be screwed up by the formatting. You can also use at-symbols for inline code keywords, like I’ve done in the post.

This is a merry time for the Gentoo Ruby team, and for the users and developers of Ruby in Gentoo! As of last night, I have confirmed that there are more ebuilds in tree using the new Ruby-NG eclasses (ruby-ng.eclass and ruby-fakegem.eclass) than there are using the old style ones (ruby.eclass, gems.eclass)! This is thanks to Alex and Hans who have been doing overtime to work on bumping the new packages.

Proportion of eclasses usage as of 2010/01/29

Presence of Ruby targets in ebuilds as of 2010/01/29

Feel free to compare to the original charts even though they are of different types.

I have sampled the past nine days, at the end of each day, to get some more interesting charts. The first thing that might be obvious by those is that the amount of Ruby ebuilds in tree is increasing with the new eclasses: it’s mostly related to our need for new dependencies, usually for tests (since we never run them before, those dependencies often were ignored altogether), but it doesn’t stop there, as I for instance have added a few more for my own consumption.

The other graph also shows a pretty interesting situation: JRuby support is reaching Ruby 1.9! While all the packages using compiled C extensions are to be left alone (unless, of course, they have an equivalent Java extension), there are more than a couple of packages that fail with Ruby 1.9 because of the changes in the syntax but work with the current JRuby — since it defaults to 1.8… I’m not sure how I’m going to work this around when the default will be 1.9, nor I have no idea how to properly support the fact that it can switch the two implementations, for now… maybe we’ll end up having jruby18 and jruby19 targets at some point).

Now, if headius were to give me a working Duby, I would be able to add at least three packages that are JRuby specific, and with the current situation, that would mean more JRuby packages than Ruby 1.9 packages, as easy as that. And by the way there is one thing that I would like to point out, regarding JRuby support. The way we implemented Ruby-NG in Gentoo, it means that we’re not bound by gems declarations, dependencies, or whatever else, as we can sidestep all of it, eventually patching the code (as I did before for shotgun not to require launchy). The end result is that these instructions on how to set up ruby-debug on JRuby, are not relevant to us: RUBY_TARGETS=jruby emerge ruby-debug will take care of everything for you, including installing the alternative gem! And similarly, we’ll never hit the problems with ActiveRecord as the various implementations are separate.

So anyway, back to work to make Gentoo even better for Ruby development and use!

It really shouldn’t be a surprise for those reading this post that I’ve been tinkering with Amazon EC2 in the past few days, the reason for that is that you can find it out by either looking at my identi.ca stream or at my commit feed and noticing how I ranted about EC2 and bumped the tools’ packages in Gentoo.

As a first experience with EC2, I have to say it does not really come out very nice… Now, the whole idea of EC2, doesn’t look half as bad. And on the whole I do think the implementation is also not too bad. What is a problem is the Gentoo EC2 guest support: while Amazon “boasts” support for Gentoo as a guest operating system, there is no real support for that out of the box.

Incidentally, there is another problem: the AWS Web Console that Amazon make available killed my Firefox 3.6 (ground to a halt). I ended up installing Chromium even though it stinks (it stinks less than Opera, at least). It seems pretty much faster, but it’s lacking things like the Delicious sidebar, still. Seems like my previous post wasn’t totally far off. Sure there are extensions now, but as far as I can tell, the only one available for Delicious does not allow you to use Delicious as it was your bookmarks.

The first problem you might have to affront is finding an image (AMI) to use Gentoo.. I could only find one (at least in the European availability zone), which is … a stage3. Yes a standard Gentoo stage3, without configured network, without SSH, without passwords, … Of course it won’t start. I spent the best part of three hours last night trying to get it to work, and at the end I was told that the only way to work that around is to install using Ubuntu as it was a live CD installing Gentoo on a real system. Fun.

So start up Ubuntu, create an EBS (stable storage) for the Gentoo install, install it as it was a normal chroot, create the snapshot and… here is one strange behaviour of Amazon: when you connect a new EBS volume to an instance, it is created as a block device (say, sdb). When you use a snapshot of that volume to register a machine (AMI), it becomes a partition (sda1). If, like me, you didn’t consider this when setting it up for install, and partitioned it normally, you’ll end up with an unbootable snapshot. Fun ensures.

By the way, to be able to register the machine, you have to do that through recent API tools, more recent than those that were available in Portage today. Hoping that Caleb won’t mind, I bumped them, and also made a couple of changes to the new API/AMI tools ebuilds: they now don’t require you to re-source the environment every time there’s an upgrade, and the avoid polluting /usr/bin full of symlinks.

So you finally complete the install and re-create the AMI, start an instance and… how the heck is it supposed to know your public key? That’s definitely a good question: right now there in Gentoo there is no way for the settings coming from Amazon to e picked up by Gentoo. It’s not difficult, and it seems to be documented as well, but as it is it’s not possible to do that. As I don’t currently need the ability to generate base images, I haven’t gone further pursuing that objective, on the other hand, I have some code that I might commit soonish.

Anyway, if you got interest in having better Gentoo experience on EC2, I might start looking into that more, in the future, as part of my general involvement, so let your voice be heard!

Gentoo has turned up in lots of interesting places before, but Michael from Misa Digital has put Gentoo to work in something entirely different: a unique instrument he invented, a MIDI guitar that uses a touchpad and digital keys instead of strings!

Behold the Misa Digital Guitar:

The Misa runs Gentoo Linux on an AMD Geode processor, using the Linux kernel version 2.6.31. It sports MIDI and Ethernet ports for connectivity.

I had the chance to ask Michael some questions about the guitar and his preferred choice of operating system:

Why Gentoo?

Since the guitar is an embedded system, I needed a really minimal distribution that would boot fast and had a small footprint. After investigating Linux From Scratch, I realised I did not have the time to invest in building a complete system. I was told that the minimal install of Gentoo is like Linux From Scratch with a package manager. I probably made you cringe with that simplistic analogy but essentially it was right for me. Once I had the install up it took me no time to recompile the kernel and streamline it as much as possible. I'm not a Linux expert though, so I reckon someone else could shrink it even more.

Yes, there are other solutions out there but they are surprisingly inaccessable. And the "live-CD" style distributions do not allow you to change the actual workings of the system. I figured it was best if I just used Gentoo because I have full control.

What were the two biggest challenges in crafting this instrument?

I would say the two biggest challenges are: 1) manufacturing and tooling the actual parts; and 2) sourcing components.

When you are a lone developer with no company, trying to keep the idea "secret", no one wants to cooperate with you. For example if you need a particular electrical like a screen, ordering "one" of something is surprisingly difficult - and you can expect it in 4 to 6 weeks - really slow! And then when you get it, you realise it is not suitable, so you have to repeat the process. The only exception is a website called Digikey, which will have the parts at my doorstep in 1 week guaranteed. But they don't have everything.

Working with Gentoo was a breeze, the Linux community in general is extremely helpful.

What can you tell us about the hardware?

There is no signal processing, it outputs digital signals via a MIDI connection. I had toyed with having an onboard sound generator but ultimately you limit the sound possibilities. By using MIDI, you are guaranteed support with practically every sequencer, synthesizer etc on the market - it is a standard that has been around for over 20 years.

[The touchpad] is a 5 wire resistive touch sensor. These are the most durable screens available on the market. The LCD behind it is OEM and ordered from China.

What changes to Gentoo (as a distribution) would make it easier for you to run it on the guitar?

I thought Gentoo was a breeze to work with. And can I just say, the Gentoo x86 install handbook? BRILLIANT. I used it so much that I think I actually know it off by heart now.

What's in store for the future?

I'd just like to see these instruments hit TV :)

Thanks for your time, Michael, and for crafting such a unique instrument! Be sure to watch a demonstration video of the Misa Guitar in action.

I interviewed the creator of the Misa Digital Guitar.

I put it up on the front page of http://www.gentoo.org for your viewing pleasure.

I actually did the interview a week or so ago, but was out of town until today. In the time it took me to transcribe the interview and post it, some PC magazine or another ran their article ahead of mine. Dangit.

Still, I hope you enjoy the interview.

I currently am tackling a new job, details of which I’m not going to disclose, but one of the steps on my “pre-work setup” task was to create a new LXC-based guest, reason for which is quite easy to guess: I wanted a clean slate to work on rather than my messed up live workstation.

I could have gone to use Fedora or Ubuntu in a KVM, or even a Gentoo install in KVM, but I still like a lot the idea of using LXC, it’s a very nice “virtualisation” technology that does not consume a huge amount of resources, nor it requires special kernel support (it’s working mostly fine with vanilla kernels). And as I’m one of the maintainers for it in Gentoo, I also wanted to check if I could improve the situation.

Thanks to Adrian Nord, I’ve been able to learn quite a bit of things about LXC even without having to follow the upstream mailing lists. Unfortunately, the documentation about using LXC is scattered and sometimes messed up, so it took me a while to get this to work as intended. So here a few notes that might come useful to other people wanting to use it:

I’ve currently not packaged lxc-0.6.5 that was released earlier this week; my reason to avoid it is that I cannot get it to work, at least I couldn’t when it was released; once I can find what the heck is wrong with it, I’ll make sure to add it; unfortunately I cannot look into it as long as I’m using the lxc guests to do real work. On a similar, and maybe related note, I couldn’t get 0.6.4 to work on the 2.6.33 release candidates, so it might be a problem of version-specificity.

You cannot rely on udev, neither to have /dev filled in, nor to have a working detection of hardware; I guess that might be obvious given that we’re talking about virtual environments, but there is a trick: by default if you just bind-mount /dev (like I was used to do on chroots) you end up with the guest having full access to the devices in the host. You need to set up an access control list on the device nodes that are allowed to be accessed for that to work.

The easiest way to handle the problem with /dev, as Adrian pointed me to, is to use a static /dev; this does not mean using the static-dev package as that installs a huge amount of extra stuff we will probably never need, and at the same time it does not install some other devices, such as random on my system. My solution? This tarball – not even compressed as it’s just metadata! – creates the subset of devices that seem to actually be used by this stuff.

You don’t want to bind-mount /dev or /dev/pts, but you want instead for LXC to take care of the latter for you: not only it’ll mount a new instance of the PTS filesystem, but it’ll also bind the tty* devices to pseudo-terminals, allowing you to access the various virtual consoles through the lxc-console command. To do that you need a bit of configuration in the file:

lxc.tty = 12
lxc.pts = 128

Note the numbers there: the second one, referring to lxc.pts is, as of 0.6.4, unused, and just needs to be non-zero so that the new /dev/pts instance is created properly. The former instead is important: that’s the number of TTYs that LXC will be wrapping around to pseudo-terminals. You want that to be at least 12 for Gentoo-based guests. The reason is that consolefonts and keymaps scripts will be accessing tty1 through tty12 during the “start-up” and will then mess up you system badly if they are not wrapped. There are two extra catches: the first is that if the devices don’t exist, the init scripts will create regular files with those names (and that might sound quite strange when you go debugging you problems), the second is that you need to have the files for the given number of ttys around: LXC will silently fail if it cannot find the file to bind at the device path. Which also takes a while to debug.

I still haven’t finished making sure that the cgroup device access functions work as intended, so for now I won’t post anything about those just yet. But you might want to look into lxc.cgroup.devices.access to whitelist the device nodes that I have in the tarball, with the exclusion of the 4:* range (which is the real TTYs.

Now, maybe I’ll be able to add an init script with the next release of LXC I’m going to package!

I've spent my whole weekend on this but it was well worth it. All known bugs in Neverwinter Nights are now fixed. That includes nwmouse and nwmovies being outdated and not always working, the elusive movie bug on amd64, some file collisions, and others that I can't remember.

For those who don't know the NWN ebuilds are rather hairy. The reason is we support a lot of things out of the box that are not even supposed to exist. Some are no more than the implementation of hacks available out there i.e. the hardware mouse and in-game movies, thanks to David Holland (see the ebuild for the url of his web site). But we also have multilingual installations from any language media. If you're like me and are in an environment where more than one language is used then this is a handy feature. I'd usually play in english but my son prefers french, so I can have both versions installed from indifferently english or french CDs or DVDs. All is needed is to set the proper LINGUAS. I have to have quite a few different versions of the game to maintain the ebuild but for the normal international user it's a real money saver. Oh and we have per-user directories too. So more than one person can play the game on a shared machine and have his/her own settings, saved games and languages (yes, each user can play with more than one language).

So do yourself a favor and get a copy of NWN. I bought yet another copy of the Diamond edition which contains everything ever available commercially for $13 a couple of months ago. Then simply emerge nwn, nwmouse (the hardware mouse, you absolutely want it) and nwmovies (nice for the commercial solo campaigns as the movies add a lot to the stories). Note that Bioware didn't translate the latest version (1.69) so if you want at least one language that isn't english then you'll have to stick to 1.68. Don't worry though, both versions are supposed to stay in the tree concurrently. Make sure you have the cdinstall and nowin USE flags and the ebuild will prompt you to insert the first disk and will recognize what edition you have. You should also add the hou and sou USE flags unless you have the original edition without the addons.

Finally, I have added two third-party campaigns: Penultima and Penultima Rerolled. Just emerge nwn-penultima and nwn-penultimarerolled. They're epic parody campaigns and among the best available. I also have ebuilds for the Tortured Hearts series but they need updating. Those are two mega-campaigns for the hardcore role-player which have the potential to keep you busy for about 100 hours each. If you want more of those feel free to let me know. Many of these third-party modules are a pain though because they contain built-in versions of widely available hak packs which end up colliding. But it never hurts asking. As usual, the best way to get the package you want into the tree is to send a ready-to-use and not-half-baked ebuild.

Poppler has a CMake ebuild now. Given how poppler is used it seems to me quite a bad move, poppler is small and used in system that may not have cmake already installed.

I run some numbers when wesnoth moved to cmake and claimed that it took about twice for me to build wesnoth+cmake on a phenom and building wesnoth alone took nearly the same time. Later a friend of mine wanted to play with me with wesnoth and given her pc is a _bit_ old, took ages to build an up to date wesnoth, about twice the time you may consider bearable thanks to the cmake switch.

Let's see what means switching poppler to CMake now, after the previous post I got some news of nice improvements, hopefully it improved even more while I wasn't watching.

Now some numbers:

I have my system in need to update poppler, still the phenom I used the other time, it is doing nothing right now:

cat /proc/cpuinfo | grep model_name
model name : AMD Phenom(tm) 9500 Quad-Core Processor

first: I need cmake

cmake ebuild tell me that I need xmlrpc-c with curl and curl with a kind of ssl support. I don't see the point of having an xmlrpc library and two xml libraries for a make system, well let's set the right useflags and trigger emerge cmake

time says

real 8m9.854s
user 13m8.121s
sys 3m7.664s

qlop on the cut down emerge.log says

domino ~ # qlop -t cmake -f mylog
cmake: 207 seconds average for 1 merges
domino ~ # qlop -t curl -f mylog
curl: 233 seconds average for 1 merges
domino ~ # qlop -t xmlrpc-c -f mylog
xmlrpc-c: 40 seconds average for 1 merges

So cmake is taking about the time of curl and it's indeed faster to build that before (it alone), still autoconf+autotools take less than 60s here, and if we factor in the deps then we still have large margin for improvements (please make xmlrpc-c, curl, libxml and expat optional)

app-text/poppler

takes about 37-40 seconds

Hacking a bare ebuild w/out touching poppler configure.ac makes it take about 60-66 seconds

So if you are having cmake already installed this poppler ebuild is _quite_ an huge improvement. If you are wondering why that happens I could guess that given that poppler is quite small the cmake quicker configure step gives this large boost, probably not having libtool in the way helps as well.

To sum up:
- the cmake poppler builds quite faster than autotools poppler.
- CMake improved a lot its build time, yet is largely bloated and could enjoy a trim.
- Poppler configure.ac probably could be improved to be in line with the cmake times.

Since we have eapi-2 use dependencies now (and have had them for a while…), there is no longer any need to split the poppler package (a popular PDF library). As first major step in the reunification of the split poppler packages, I just committed a new ‘monolithic’ ebuild, app-text/poppler-0.12.3, to our testing branch in portage. This ebuild was developed by Maciej Mrozowski from our KDE team, and uses the cmake buildsystem, which is actually preferred by upstream.

You should have no problem migrating to the new monolithic poppler, as portage should be able to solve the blockers automatically. As a second step we will adjust the dependencies in packages that need poppler, to no longer depend on the virtual ebuilds, but on app-text/poppler directly, with the correct useflag dependencies. This work will be done gradually over the coming days.

Version 0.12.3 is also our stable candidate, and a stable request will be filed soon. Then all old versions of poppler and the split packages, as well as the virtuals, will be removed for security reasons. Feel free to come by #gentoo-kde on Freenode if you have any questions.

Hello there! Long time no see, I know. (At least on this blog.) For our LXDE users out there, I want to point you to the fact that Victor Ostorga has provided us with some updated packages, and we now have lxde-meta-0.5.0 in portage, in the testing branch. So go ahead and test these updated packages out, and report any bugs you find!

So as you might remember one of the reasons for my restructuring of Ruby eclasses has been the chance of getting “proper” support for JRuby in Gentoo. With proper I mean that the packages are declared to support specifically JRuby, and at the same time get tested so that they actually work with it. For this to work out properly it also requires that the testsuites for the packages were written in such a way to work fine when run through JRuby. But I already ranted about that so I won’t go into those details again now.

Instead of writing about the Ruby-NG side of the fence, I’d like now to talk about the (to me, much more unknown) Java side of the fence. Now, I know near to nothing about Java packaging. I know my way around the Java language, sort of, but not much about the packaging side of it: ant is mostly black magic, and the whole mess with Jar files, manifests, and dependencies are huge question marks in my view.

So the first problem, is that while JRuby has been in tree for a while, there was near to no way to make sure that it worked as intended, before. This resulted in pretty erratic behaviour with it (like the FFI-based libraries not working at all); with the root causes hidden by sub-projects as well (in this case, jffi was being installed without the needed JNI library). This is also often tied with the way JRuby is developed: it’s modularised, but the projects are sometimes only used by JRuby itself, so without it working, it’s almost impossible to tell if the rest is working as intended either.

There is also the problem of packaging what was not available before; for instance I found out that JRuby now needs a Java implementation of a YAML parser, yecht written by a JRUby developer Ola Bini, which is bundled by JRuby itself, but we should have been packaging ourselves. Thanks to Fabiano “elbryan”, I got an ebuild for yecht itself… the problem is that the version shipped with JRuby also contains the classes needed for the JRuby bindings, which aren’t available when building the Jar standalone. D’uh!

Other problems are really tied to the projects standalone: as I said above, we had some trouble with JFFI and the fact that we didn’t install the JNI library (an ELF shared object) that it needs to work. Now we do, but… every time we start jruby, whether we’re going to use FFI or not, we’ve got to call into java-config (which is a bash call into a Python script), to ask it where the jffi library is so that we can set a property… it doesn’t sound right! And the same applies to dev-java/jna (which seem to provide similar features, by the way). The problem with both is that they really should have a way to tell at build time were their native libraries should be found, and then leave the property as a way to override it… Unfortunately it seems like there is no way to do that. I reported a feature request for JFFI and we’ll see how it’s going to turn out.

Unfortunately, the problems don’t stop here. Another problem happens with the OpenSSL-compatibility extension provided by dev-ruby/jruby-openssl; the idea is to provide the same interface of Ruby with the OpenSSL extension, but using Java libraries instead. Since the standard JRE does not provide all the needed interface, this extension uses BouncyCastle to do the work, and that does not work fine here at all: not only the extension bundles a copy of bcprov and bcmail (even in the very git repository!), which by the way don’t seem to work right for me, maybe because they are the JDK 1.4 versions, while we use at least Java5, if not 6 altogether, but more importantly our already-present bcprov/bcmail packages fail badly. The issue here is that bcprov can be loaded as a JCE provider; JCE providers need to be signed, and obviously our rebuilt Jar file is not signed. This is a huge problem that the Java team should most likely look into and something I really cannot look into myself.

On the bright side, though, tonight I’m going to commit a new JRuby ebuild with a much simplified launcher script (and no more symlinks around!). This basically cuts all the conditionals for cygwin, as well as for dynamic discovery of JAVA_HOME path and replace them with assumptions about the Gentoo setup (JAVA_HOME is filled in during install phase) and calls into java-config. Hopefully, this should reduce both possibility of mistakes, and reduce the time needed to process the script. Unfortunately, the script as it is, uses bash, that we all know is far from the fastest shell out there. Porting it to use pure sh is definitely not possible — although one could argue that Java’s own startup is definitely going to take up more time than using bash).

Oh well, we’ll see how it goes from here.

As you can see in http://bugs.gentoo.org/show_bug.cgi?id=301928, new emul set should be stabilized soon, then, if you want to contribute, you can simply install new versions on your stable system for testing and reporting every bugs you find.

The set that should go to stable is:
app-emulation/emul-linux-x86-gtklibs-20091231
app-emulation/emul-linux-x86-baselibs-20091231
app-emulation/emul-linux-x86-medialibs-20091231
app-emulation/emul-linux-x86-sdl-20091231
app-emulation/emul-linux-x86-xlibs-20091231
app-emulation/emul-linux-x86-qtlibs-20091231
app-emulation/emul-linux-x86-compat-20091231-r1
app-emulation/emul-linux-x86-soundlibs-20091231

Thanks a lot

So I drive back home, open reddit, and what do I see?

US Supreme Court ruling comes down - Corporations are people with free speech and have the protected right to bribe politicians

The story currently has 5,200 upvotes, and 2,744 comments.

MSNBC says:

In a landmark ruling, the U.S. Supreme Court on Thursday struck down laws that banned corporations from using their own money to support or oppose candidates for public office.

Nice, let's go have some cake.

Folks, this is another example of a place where the concept of "Free Speech" is not applicable.

No, it does not mean you can say whatever you want, whenever you want, to whoever you want. Nor does it mean that everyone has to allow you to do any of that.

Free speech means that your (democratic, republic, or whatever) government should not restrict your right to criticize them, organisations, people, practices, or society in general.

Things not covered in Free Speech (open for debate):

• Slander
• What rules you impose in your house
• What companies impose on employees
• What comments you allow on your blog
• etc.

A parting gift for the German Conspiracy,

Gunnar Wrobel recently acquired the rights for his own book about Gentoo, and it has now been published under a free license and is available for download. The latex source for the book is also included. Gunnar's intentions in publishing the latex source was to encourage translations... it would be neat if that really happens. Please take the time to thank Gunnar for all the excellent work he has done for Gentoo.

Stephanie J. Lockwood-Childs contributed to the draft for this announcement.

In this podcast comprookie interviews Colin Guthrie, Colin develops / contributes to Mandriva Linux, PulseAudio, and Trac.

LINKS:
PulseAudio People
http://pulseaudio.org/wiki/Community#People

Sound on Linux is Confusing
http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part...
http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part...

PulseAudio fixes and workarounds
http://fedorasolved.org/Members/fenris02/pulseaudio-fixes-and-workaround...

Broken Sound Drivers
http://pulseaudio.org/wiki/BrokenSoundDrivers

Mandriva Linux: Colin Guthrie
http://blog.mandriva.com/2009/09/04/mandriva-linux-community-words-colin...

irc network freenode channel #linuxcrazy

Download

If you would rather read the interview, Colin provided a transcript;
Colin Guthrie Interview

With the introduction of the new (but nowadays not so new) Ruby eclasses, Gentoo started supporting JRuby as a proper option. This means, among other things, that the libraries installed for JRuby and Ruby 1.8 (MRI18 in the future of this post and others) are now separated (before JRuby “sucked in” the libraries from MRI18), and that you can decide whether to install for MRI18, JRuby, or both of them. It’s also a nice testbed for the future working with MRI19.

Now, supporting JRuby is, to be honest, not an easy task, and I’m doing it mostly alone. Why is it not so easy? The main reason is that I’m striving for a higher ground than we had before: I want what we install for JRuby to be sure of working! And this means, mostly, that I have to make sure that tests work. This gets tricky for not just a couple of reasons; among them, Rails tests require you have the SQlite3 bindings for ActiveRecord, which in turn rely on SQLite3-Ruby. This is a problem because, simply put, SQLite3 is broken beyond repair, I’m afraid.

The problem with SQLite3-Ruby is that it relies on SQLite3 itself, which is a native library. To access it you have two options: you can use a native Ruby extension that provides MRI18 and MRI19 bindings for SQLite3, or you can use the dl-based driver that uses the dl.rb library to open the library and access the functions. Not only the tests currently fail on MRI18 and MRI19 with the native extension, but they fail to work at all with the dl-based driver! Let’s not even go to wonder how it works with JRuby.

Other problems with JRuby involve both bugs in JRuby itself (fakefs, and thus rspec’s testsuite, is kept down by that), and by incompatible design (racc is giving headius a bit of trouble for instance), like using fork (which does not work on JRuby at all, nor it seems on Windows). Thankfully, headius (Charles Nutter) is helping me out by checking the code of various extension, and coming up with possible workarounds.

Now, as I said I’m doing the support for JRuby mostly alone in Gentoo, as Hans is focused on just Ruby 1.8 and Alex looks at both 1.8 and 1.9. I try to focus more on Ruby 1.8 and JRuby. My interest in JRuby is vested: for my Ruby-Elf project I could really use threading, and Ruby 1.9 is not really providing anything useful to me (it only allows thread to work in parallel if they are not holding the global interpreter lock, which basically reduces to only having sense when calling into a blocking operation or to an extension outside of the Ruby language, like an extension ­— this is probably good for network-based software but not for CPU-intensive processing like Ruby-Elf).

Anyway, to understand how the current porting is taking place, I’ll add two graphs for now; I know pie chart are bad yadda yadda yadda, but since I haven’t sampled this yet (I’ll do my best to sample it daily for a while and then chart it properly with an area graph), it’ll have to do. It also shows well one thing: we have to get rid of the old eclasses usage and that’s going to take a while still. The second chart instead shows how many ebuilds are available for a given target; I have to note that for now there are exactly two ebuilds that are not available to Ruby 1.8 implementation: test-unit and jruby-openssl. In the future this is likely going to increase, especially for JRuby, as I’ll probably add a couple more JRuby-specific extensions that I’m interested directly or indirectly about. As for the other graph, I’ll start sampling the data from now on, to see how these values increase in the future (and if they’ll ever decrease).

Proportion of eclasses usage

Presence of Ruby targets in ebuilds

A huge thank-you has to go to Zac for providing me with a script to be able to get this data (ironically, in Python):

#!/usr/bin/python

import sys
import os
import portage

def main():
  bins = ('ruby', 'ruby-ng', 'ruby_targets_ruby18', 'ruby_targets_ruby19', 'ruby_targets_jruby')
  stats = {}
  for k in bins:
    stats[k] = set()

  portdb = portage.portdb
  portdb.porttrees = [portdb.porttree_root] # exclude overlays
  for cp in portdb.cp_all():
    slot_dict = {}
    for cpv in portdb.cp_list(cp):
      slot, iuse, inherited = portdb.aux_get(cpv, ['SLOT', 'IUSE', 'INHERITED'])
      slot_dict.setdefault(slot, {})[cpv] = (iuse, inherited)
    for slot, cpv_dict in slot_dict.items():
      cpv = portage.best(list(cpv_dict))
      if cpv:
        iuse, inherited = cpv_dict[cpv]
        iuse = set(iuse.split())
        inherited = set(inherited.split())
        if 'ruby' in inherited:
          stats['ruby'].add(cpv)
        if 'ruby-ng' in inherited:
          stats['ruby-ng'].add(cpv)
          if 'ruby_targets_ruby18' in iuse:
            stats['ruby_targets_ruby18'].add(cpv)
          if 'ruby_targets_ruby19' in iuse:
            stats['ruby_targets_ruby19'].add(cpv)
          if 'ruby_targets_jruby' in iuse:
            stats['ruby_targets_jruby'].add(cpv)

  for k in sorted(stats):
    sys.stdout.write("%s\t%s\n" % (k, len(stats[k])))

if __name__ == '__main__':
  main()

Time to collect bugfixes to 1.3.0_rc1 for a new release…

Summary

layman-1.3.0 fixes expected rough edges from 1.3.0_rc1. Thanks to everyone reporting bugs, i.e. thanks to Piotr Mitas, Albert W. Hopkins and tman/cornicx.

Details

• Move storage default from /usr/local/portage/layman to /var/lib/layman (fixes bug #253725)
• Syncing failed for overlays that no longer exist in the remote lists without need to (bug #301174)
• No longer treat sync warnings like errors (bug #301327)
• Fix faults introduced at refactoring (bug #301253)

How to upgrade

1. Unmask =app-portage/layman-1.3.0 if you’re on stable
2. sudo emerge -av =app-portage/layman-1.3.0
3. sudo etc-update
   

Gentoo is dy-what?

Here's the state of the -stable kernel trees, as of January 18, 2010.

2.6.27-stable

The 2.6.27-stable kernel tree is still living on, as a "long-term" stable release. But, I do have to warn users of this tree, the older it gets, the less viable it becomes. Not all bugfixes are being backported to this kernel version due to massive code changes in the over 2 years since this kernel has been released. I am doing my best to backport fixes that I become aware of, and I encourage anyone who does fix any types of bugs in the main kernel tree to let me know if the change should be applied to this older kernel version.

I'll probably keep maintaining it for at least 6-8 more months, but after that, I can not guarantee it's viability. Note, one other developer has volunteered to pick up the tree after I am finished with it, but I can not speak for him at this time.

2.6.31-stable

Today the last 2.6.31-stable kernel was released, all users of this kernel series are strongly encouraged to switch to the 2.6.32 kernel series, as there will not be any more updates for this branch in the future.

2.6.32-stable

I'd like to announce that the 2.6.32-stable tree is also going to be maintained as a "long-term" stable release, living for 2-3 years, like the 2.6.27 kernel is. This is because a number (i.e. more than 2) Linux distributions are basing their "enterprise" releases on this kernel version, and it will make their lives easier if I keep it alive.

Note, the viability of me keeping this tree alive for such a length of time relies on the developers working for those distros to keep me informed of patches that need to be backported and applied to it. Without their help, I will have no problem in stopping the maintenance of the tree.

Submitting patches for stable trees

Again, the easiest way to get your patch into a -stable tree is to merely add the line:

Cc: stable <stable@kernel.org>

to the Signed-off-by: area of your patch. When the patch goes into Linus's tree, it will be automatically sent to the stable address, and I will know to apply it to the trees. If I have any problem applying it at that time, I will email the author and reviewers of the patch about it.

If you forgot to add this line to the patch, or you have found a patch written by someone else that you wish to have applied to the stable trees, email the git commit id of the patch as it shows up in Linus's tree to the stable@kernel.org email address. Any stable correspondence sent to my personal accounts has the chance of being lost in the shuffle, so please try to not do that.

If a patch needs to be backported to one of the stable trees because it does not apply directly, please send the backported patch, along with the git commit id of the original patch, to the stable@kernel.org address, with a description of which kernel tree it should be applied to.

If anyone has any other questions about stable releases, please let me know.

It is no surprise that Gentoo Prefix works fine on arm-linux given the great work being done in Gentoo Linux by the ARM team (armin76, maekke, et al).

For the Genesi Efika MX (unboxing), I now have a binpkg repo setup (for Gentoo Prefix only). This was mainly a fun proof-of-concept that I did. I went from installing 70 packages in about 18 hours, to about 30 minutes using binpkgs.

What does this mean:
Given the relatively small set of arm users and the highly specific use cases for arm hardware, well, there isn't a very big percentage of users that will keep Ubuntu on their Efika MX when they get it. But, if they do, that means that they can get a complete toolchain and Gentoo Linux userland (including portage package manager) on the host in less than an hour. Of course, they could also get the same packages from the Ubuntu package manager but that isn't as cool

How to install/get working:
Follow this easy guide that I wrote, here. All 70 packages will occupy about 580MB of space. Then you will have the toolchain and portage (emerge) at your disposal to use on your Ubuntu ARM (cortex-a8, armv7) system.

Have fun.

Currently 12464 votes are assigned to 1027 open bugreports.

The Top 10 most-voted bugreports and maintainer-wanted requests are taking a break this week.

Top 10 oldest open bugs:

Top 10 open bugs with biggest votes changes since last week:

Top 10 most-voted bugs resolved since last week:

Check the votes page for daily updated tables.

I've been on the hunt for Qt/KDE applications that do the job of the gtk+ equivalents I use.

That's a tall order, as I'm used to the way my gtk+ applications look, feel, and behave in Xfce. Trying to learn something that may do things completely differently can be very frustrating. Heck, it can be annoying even when 98% of the time the app does just what you want it to. That last 2% can push you over the edge.

Part of learning the ropes with KDE4 is finding which application does what. Yes, I could just keep using all my existing gtk+ applications with little or no difference in look'n'feel, thanks to QtCurve. But that would deprive me of the chance to try out the many, many other apps available in the FOSS world. I'd miss out on all the fun if I focused on applications written for just one toolkit. This post examines the differences between certain gtk+ and Qt programs.

Obviously, these are my subjective experiences. Everyone has their own preferences. Using and writing about all these different applications has really helped me take a look at what exactly I like to see in an application. What I expect it to do out-of-the-box, and what kind of tweaks it offers so that I can tailor it to my needs. Actually, reviewing Qt apps has helped me in my search for gtk+ equivalents, too. I've been spending more time examining user interfaces on their own merits, instead of discarding apps from consideration based solely on their widget toolkit.

The applications listed here all work equally well in Xfce and KDE, so if it operates in one environment, it operates in the other. If it fails in one, it fails in the other. It's a fairly level playing field, except that I'm coming from an Xfce background, which means I'm just not used to how some things are done on the "other side of the tracks." I've tried to keep that in mind as I jump from app to app.

Multimedia

For audio playback, in Xfce I use Decibel. Its playlist support isn't all that great, and it can't do additions by genre (or suggest/smart-add tracks) but overall it's fast and easy to use. I've tried other gtk+ apps like Rhythmbox and Exaile, but while I like the ideas behind them, their user interfaces are just a bit too busy to be useful. Players like Listen or Songbird are also too complicated (and dependency-bloated).

I need some kind of happy medium between the sparse simplicity of Decibel and the clutter that is Rhythmbox, Banshee, Exaile, et al. Bluemindo, Consonance, and some of the MPD front-ends come close, but don't quite make the connection for me.

Speaking of MPD: while it has many, many front-ends, I totally dislike the whole client-server model. I don't stream anything over the network, so setting up a server on a single box, with all the weird configuration that entails, is just too much. Plus MPD still can't play audio CDs, so I don't bother with anything that uses it, whether gtk+ or Qt.

Elsewhere in the player spectrum, there's XMMS and its derivatives. I used Audacious for a long time until it quit working a few years ago, then moved to Decibel and haven't looked back. However, as much as it's a pain to add tracks in the Winamp lookalikes, I can use them fairly quickly and find where everything's located, since I used Winamp for years back in my Windows days.

It's hard for me to find a player that feels usable on a day-to-day basis. Both when I just quickly want to throw some tracks in the queue and when I want to spend some time arranging a playlist. Those are the two big tests of a player's usefulness. There are lots of KDE/Qt media players available, so I've started sampling them.

JuK: Meh. I don't like the UI. None of the modes are intuitive, even after days of playing with it. That left sidebar is killing me. Totally unhelpful.

Amarok: Yup, the heavyweight. The program that's gone through polarizing changes to its UI and features in the 1.x/2.x release series. Can't say I care for it -- it was far too complicated. Felt like it took the worst UI design aspects of Listen, Songbird, Banshee, and slapped 'em together. Plus it was slow. I don't have a large collection of music on my laptop; less than ten albums. The library is tiny, but Amarok is always pig-slow to startup and search through my files. Plus Amarok required many libraries that take a long time to compile. Not worth it. Akarok just isn't right for me.

QMMP: This is familiar to an old winamp/xmms/audacious user, but very dated. I don't like the idea of skins anymore. I want applications to smoothly integrate with my desktop theme -- using native widgets, whether gtk+ or Qt. There's no "default to native Qt widgets" setting, unfortunately. But it plays media as expected. There's a wealth of built-in plugins that offer everything I need for playback and information display. Just like the good ol' days of Winamp, XMMS, and Audacious.

QMMP is the player I'll stick with for the time being, as I can't find anything with a UI that's not too simple or too complex. What I'd like is a Qt app with a couple of configurable panes and album cover support -- something like Decibel or Consonance, but capable of more than just adding music by album or artist.

Kmix: an applet for volume control. It has the quick functionality that I'm accustomed to in Xfce4's volume control, in that I can hover over the applet and scroll the mousewheel to change volume without needing to click. Very handy. However, the icon and "sound wave" meter are so tiny it's very hard to tell the volume has been changed without clicking to check the level. When opening Kmix as a standalone application, it's the most confusing frontend I've ever seen to alsamixer. Seriously, its UI is crap, even after adjusting the display options to minimize the clutter.

That screenshot in the above link represents a best-case scenario, and even that's totally unintuitive. The icons also don't always make sense -- take that first one at the top of the "Master" control. It's a mini slider switch. Looks like it should do something, right? Yeah, just keep grabbing at it, then realizing that it won't actually do something. I could go on, but I'll stop there. There are some icons I just have to ignore.

Fortunately, my needs are simple; I don't need many displayed controls. I don't even use the laptop's builtin microphone, and only rarely use headphones. "Master" and "PCM" are the only things I really care about.

On the positive side, sometime after installing Kmix (so it's possibly related) I now have an on-screen volume indicator when I use my laptop volume buttons! The last time I saw this was in an ancient version of Ubuntu, so it's quite a treat to have the buttons actually work and get integrated into my desktop. Love it!

Now I just need a working on-screen display for my LCD brightness level. I do get a popup, but it doesn't always move the level meter when I adjust brightness, in KDE and Xfce. At least I'm halfway there: things appear on the screen when I push buttons. Good start.

Utilities

Ark. In Xfce, I use Xarchiver to work with tarballs, zipfiles, etc. I've also played with Squeeze in the past, but found it rather unstable. Back in my Gnome days I used the ubiquitous file roller. There are a few different gtk+ archive managers I've used, and generally liked their UIs.

Ark seems to be the standard (possibly only) Qt archive manager in Portage. Sadly, it would not work: it said it did not have the necessary permissions to create archives in my own home folder! This was a show-stopper, so after a few half-hearted debugging attemps I unmerged it and went back to Xarchiver. Under KDE, Xarchiver sorts the archive in reverse, with files at the top and folders at the end, but this is a minor change to expected functionality. It still does everything else it's supposed to.

Plasma-emergelog: a plasmoid I found on the official KDE overlay. Prints emerge.log output from the last few merges; can be pretty useful. It's even written by a fellow Gentoo developer.

Dolphin: as filemanagers go, this one is okay. Once I disabled some of the hover mojo, enabled double-click activation, and added an "Up" arrow, it works like any other FM I've used. That is, with one key exception: the unending annoyance that is the location bar! I like having an editable location; it's much faster for me to type the location than it is to keep clicking backwards and forwards though the filesystem. However, the location bar doesn't seem to be persistent. Every time I open a new Dolphin window, I always have to click View -> Navigation Bar -> Editable location. My setting is never permanently saved. Is this a bug or a feature? It's driving me crazy!

The search bar is interesting, but useless. I intend to remove resource and space-sucking hogs like Nepomuk, Strigi, and anything else that uses the "semantic desktop." Maybe one of these days the semantic desktop will matter, and our tools for using it will improve, but for me, that day is a long way off.

I can't find one good desktop search framework for any environment, KDE, Xfce, or Gnome. Beagle, tracker, Strigi, you name it. In my experience they're just too slow and bloated.

Konsole: an acceptable terminal, though I may be going back to Xfce Terminal soon. Konsole does everything I need it to except make use of middle-click functionality. I can't middle click a URL to have it open up in a new Firefox tab, for example. This is something I do constantly -- whenever I run an eix query, I usually open up the application's homepage, which just needs a middle click in Xfce Terminal. It's a two step process in Konsole; I first have to right-click the URL, then choose "Open Link." I miss the middle-click so much I'll probably go back to Terminal. Now that my gtk+ widgets all look like native Qt apps, it's not like I'd notice a difference. The color schemes are the same, the fonts, are the same, they can both do tabs . . .

Networking

Kbluetooth: Bluetooth manager for KDE. In Xfce, I use Blueman, which gets the job done. It mostly has a unified user interface. But I can't actually browse my phone in a filemanager, since Thunar lacks support for that. Even using Gigolo isn't enough -- I'd have to install various FUSE packages to get support for opening the obex:/// location from Blueman, or use Nautilus. Neither are acceptable.

I can't browse my phone using Kbluetooth, either. I can send and receive pictures, but sending (from the phone) requires a laborious, slow process of selecting each file and stepping through several menus. Sending items to the phone from the laptop is much faster, as I can use the normal file picker.

Also, I couldn't get a unified preference/usage window to popup for Kbluetooth. I had to do lots of right clicking on the panel applet, and every setting requires a new window. Rather annoying.

One other annoyance was the fact that every time I wanted to receive a file from my phone, Kbluetooth opened KWallet. Can't it just read my PIN from secure location in the filesystem? I think that's what Blueman does, maybe someplace in /etc/, just like wicd and wpa_supplicant do for WLAN passwords.

I still need a good Bluetooth client that lets me browse my phone directly in a file manager of some kind.

WiFi: turns out that by reemerging solid with +wicd, it enables support for wicd, which I already have installed. I haven't seen how this works, though. Wicd was already listed in the program autostart menu; I just had to change the command so that it launches the tray applet and doesn't just run the background daemon.

Regardless of any special Solid integration, however that works, since wicd operates normally, it may remove
the need to install some other network connection manager. I'm quite comfortable with wicd, and it'd be nice if I didn't have to setup a new configuration for a new app every time I switch desktop environments.

Writing

Kblogger: client that supports multiple blogging APIs, including LiveJournal support. I found this client in the kde overlay. However, it doesn't actually work with LJ. It can't add post tags, nor can it retrieve existing tags. Trying to do so kills the application. Very buggy. I gave up and unmerged it.

Blokkal: another multi-blogging client with LiveJournal support. Does everything I want it to for LiveJournal. Minor annoyance: I can't just type my LiveJournal password into Blokkal, but instead have to first enter the password for KWallet. But that's probably a more secure method of storing it locally, right? Still, it's an extra step that I don't have to take when using gtk+ clients like Drivel or LogJam.

Office

The next big writing application to find is a word processor: something that's fast, easy-to-use, and doesn't require hours of downloading and compiling. KWord seems to be the most well-known office application, but the reviews I've read so far indicate that it tends to run a bit slow, though not as bad as OpenOffice. That's a positive sign, so I'll give KWord a shot.

On the lighter side, FocusWriter seems to be a Qt clone of PyRoom, which is a free gtk+ version of WriteRoom for the Mac. I wrote an ebuild for PyRoom a year ago; it's been one of my very favorite and most useful applications. I do need a distraction-free writing environment, so I'm glad to see that there's an equivalent application for KDE/Qt.

Other office software I need to investigate: spreadsheets, finance trackers, and email clients.

And another thing . . .

I notice that it can take a long time for newly installed applications to show up in the Kicker menu, or to disappear after I've uninstalled them. Why is that? Is something not scanning /usr/share/applications when it needs to? I usually have to logout if I want to see the menu updated.

New features this time: here is Layman 1.3.0_rc1. Let me try to summarize:

Summary

layman-1.3.0_rc1 introduces support for several sources per overlay. Also, layman -i overlay now makes full use of metadata that arrived with the migration from layman-global.txt to the repositories.xml format.

Details

• Add support for several sources per overlay (also fixes #280472)
  When adding an overlay all sources will be probed until a working one is found. This should help Layman through some firewalls.
• Display related directory when deleting overlays
• Improve overlay info display (i.e. layman -i):
  • Add quality indicator (keep in mind: no guarantee)
  • Add feed URIs
  • Fix whitespace handling for description field
  • Improve layman usage display

How to upgrade

1. Unmask =app-portage/layman-1.3.0_rc1 if you’re on stable
2. sudo emerge -av =app-portage/layman-1.3.0_rc1
3. sudo etc-update

What else?

• Please report bugs!
• Using layman and proxies, programming Python?
  Feel like doing James a favor with bug #300651?

Gentoo is dying? Says who?!

In some places like forums, there are a lot of different ways to shrink portage tree. The way I finally chose was to simply create a separate partition using ReiserFS and, of course, not using "notail" option with it ;-)

This is how does its fstab entry look:
/dev/sda6 /usr/portage reiserfs defaults,noatime,nolog 0 0

And this is df -h output for it:
/dev/sda6 353M 292M 62M 83% /usr/portage

It includes full portage tree+sunrise+suka overlays

Best regards

I have been in the process of learning Python for the past year and sometimes start slacking. On my Podcast I mentioned I was interested in reading and doing the exercises in Core Python Programming by Wesley Chun.

I have received a good response and we will be starting the book on Feb 01. If you would like to join us please visit Wiki Start Page for all the information, hope to hear from you.

Today I faced an interesting Linux problem that made me learn a couple of things I'd like to share. At first, we found an issue on a Thinkpad X301 notebook that was fixed in a newer BIOS version. So we wanted to do a BIOS update. Lenovo provides BIOS updates either for Windows or as bootable ISO CD-images. But the device had no CD-drive and only Linux installed. First we tried unetbootin, a tool to create bootable USB sticks out of ISO-Images. That didn't work.
So I had a deeper look at the ISO. What puzzled me was that when mounting it as a loopback device, there were no files on it. After some research I learned that there are different ways to create bootable CDs and one of them is the El Torito extension. It places an image of a harddisk on the CD, when booting, the image is loaded into memory and an OS can be executed (this probably only works for quite simple OSes like DOS, the Lenovo BIOS Upgrade disk is based on PC-DOS). There's a small PERL-script called geteltorito that is able to extract such images from ISO files.
It's possible to boot such harddisk images with grub and memdisk (part of syslinux). Install syslinux, place the file memdisk into /boot (found in /usr/lib/syslinux/ or /usr/share/syslinux/) and add something like this to your grub config:

This poped up recently @ -dev ML [1]. It turns out that is little ( or not at all ) documentation about this, which is quite unfortunate since it is one of the most easy and important ways a user can use to assist us on development. A couple of months ago I blogged about Sunrise Overlay[2] as a good way for users to extend their knowledge on ebuild writting and contribute their own ebuilds on an official gentoo overlay. This of course requires a significant amount of time and effort which is hard to find nowadays.
There is another way for you to help us put your shiny ebuilds on portage. You can become proxy-maintainer of any package you like as long as it doesn’t have a Gentoo developer as maintainer.

How does this work?

Since there are no official documentation available, these are the rules you should follow to become proxy-maintainer:

1) Open a bug for your package

2) Attach your ebuild and state that you want to be proxy maintainer for this

3) Assing or CC the bug to the more appropriate herd[3]

4) Wait for a developer to pop up and accept your offer

As proxy-maintainer you should do all the required work to ensure your package is fully working and up2date. This may requires to follow upstream changes and mailing lists and visit occasionally the bugzilla to find out if there are open bugs for your package. This is an excellent opportunity to become an active member of Gentoo developer community and a big step for improving this great distro. Furthermore, you can always jump the gap and become developer[4] if you think you are willing to contribute in regular basis

I really hope this post will clarify this “unknown” term and motivate you to become proxy-maintainer

[1] http://archives.gentoo.org/gentoo-dev/msg_8c710130ea7281f9815ef84fdd2216a9.xml

[2]http://hwoarang.silverarrow.org/?p=385

[3]http://www.gentoo.org/proj/en/metastructure/herds/herds.xml

[4]http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=2

In spirit of release-early-and-without-reason: here is Layman 1.2.6. Let me try to summarize:

Summary

layman-1.2.6 introduces support for tar overlays that are compressed with an algorithm other than gzip or bzip2. That, plus minor fixes.

Details

• Warn on lack of write permissions (fixes #260218)
• Migrate to GNU tar’s compression format auto-detection which adds potential support for more types of compressed tar archives (LZMA, xz or Z) as a side-effect
  (Requires GNU tar 1.15 or later, released in 2005)
• Drop support for broken tar overlays with missing category level (and missing profiles/repo_name as a consequence)
• Make missing overlay directory not fail removal of that overlay from the local list
• Start shipping doc sources and release notes with release archives
• Start shipping test suite files missing from the 1.2.5 release

How to upgrade

1. Unmask =app-portage/layman-1.2.6 if you’re on stable
2. sudo emerge -av =app-portage/layman-1.2.6
3. sudo etc-update

What else?

• Please report bugs!
• Using layman and proxies, programming Python?
  Feel like doing James a favor with bug #300651?

Gentoo is dying? Says who?!