[Just a few bits, don't expect completeness here.]

We had that big blue banner (first presented on Linux Tag 2009) with us again: it did a great job on promoting our table and on easing up finding the way back. Neighborhood to the Debian table seemed to be peaceful to my impression, though we didn’t exchange many patches either.

People came by to talk, getting support (like fixing graphical login), getting started with Subversion live ebuilds and to thank us for “the great work” Gentoo people do.  The gentoo-users mailing list was praised, too. Quite a few flyers were given out, stickers were asked for and given out repeatedly. Also, Christian Groschupp and me teamed up on a bit of hacking on Layman which was fun, too. Impatient people are welcome to give the Layman live ebuild (app-portage/layman-9999) a spin before the next release is coming out.

Looking back I would say it was a good event Gentoo-wise.

Auf der außerordentlichen Mitgliederversammlung am 27.12.2009 ist ein neuer Vorstand gewählt worden; das Thema “Auflösung” ist damit vom Tisch.

Finally GNU Emacs upstream switched its version control system from CVS to Bazaar and development takes now place in a new repository with whole history. For Gentoo users of the live ebuild app-editors/emacs-cvs we did a package move to app-editors/emacs-vcs, which will update all your configuration files accordingly. We chose the version control system agnostic -vcs suffix because VCS is the term used in Emacs and we can avoid another package move on the next switch (whenever that will be). There were some discussions on bugzilla and forums why we keep a separate package for the live version, please don't bring it up separately, but read the entries there.

For normal users there is no change, only the /usr/portage/distfiles/cvs-src/ directory can have some clean-up as you won't need the Emacs related entries there anymore. Users of overlay live ebuilds are on the safe side, as long as they stick to the Emacs overlay. Thanks to Ulrich Müller (ulm), who took care of the whole transition. By the way, make sure, you use a Bazaar (dev-util/bzr) version from 1.18 onwards, because the repository format is only compatible with versions equal or above that, on most architectures version 2.0.1 is the current stable.

Doing stabilisations and keywording of packages is an essential part of keeping the quality of the distribution. This needs some dedicated people who check that packages work on a given architecture. Most in Gentoo are kept working by a small group of persons, some even have only one active developer on it (true for ppc64, hppa or m68k). Many people don't care about those three because users are scarce out there, but two architectures are essential, because they are wide-spread: amd64 and x86. The first had some issues in the last three years, but now the support is going well, because of some new additions to the team or regained motivation (ssuominen, maekke, hwoarang and pacho to name a few).

x86 on the other hand is handled by maekke and myself, armin76 sometimes helps out. About a year ago, we were down to 30 to 50 open stabilisation/keywording requests, while now we are lucky if we get down to 60, usually we are above 100. This is not a good situation, because of lost overview critical stabilisations may not done in a timely manner. There are several causes of this problem: Firstly, at least I cannot dedicate as much time as I would like. Secondly, some teams and developers think that every minor revision of a package needs to be stabilised after 30 days, no matter if the previous version has just been gone to the stable tree. Stabilising a package is not just a compile-check! At least the problem can be avoided by just ignoring those requests for a while until the next requests comes in and invalidates the older one.

Why I wrote all this? In the long-run the x86 needs some fresh blood. Although the architecture will die out, it is still heavily used and netbooks are new consumers of it. Also there is the embedded world which sees some old processors still around. So we are looking for new members, being it existing developers who wish to join or users willing to help. We are open for recruitment if you prove reliable or you stay an architecture tester who reports on stabilisation requests that the package works as expected on x86. We don't expect that you do stabilisations for ten hours every day, but regularly and over a long time-frame, so this is an excellent opportunity to enter the Gentoo developer community. For all the glory details, see our FAQ, ask me directly be email or peek into the IRC channel #gentoo-x86 on Freenode.

Yes, yes, I know this post is a tad late, but hey, it’s still the right year. ;)

As Srini had announced, Dec 5th was GNOME Day at FOSS.IN this year. We kicked the day off with Shreyas giving a developer’s introduction to GNOME 3.0. This was followed by another well-received talk by Srini on the Mobiln2 UI and Clutter.

By the end of lunch, it turned out our already packed schedule had got some new additions from the other enthusiastic GNOME folks around! The afternoon session was kicked off by Arun ‘vimzard’ Chaganty introducing what newbies need to know to dive into GNOME development. Tobias Mueller followed with a talk about GNOME Bugsquadding. Sayamindu and Dimitris then took the stage for a short L10n talk. Next up was a talk about Anjal by Puthali. Olivier then gave a hackers’ introduction to Empathy/Telepathy, Srinidhi and Bharath did a quick introduction to using the OpenSUSE Build Service.

Wait, I’m not done yet. :) The final session on GNOME Performance was a 4-hit combo with me giving a quick introduction to Sysprof, Lennart introducing mutrace, Krishnan giving a pretty wow introduction to using DTrace to profile GNOME, and Dhaval giving a short introduction to how cgroups could help make GNOME more responsive.

Phew! That was a long and awesome day, with some icing on the cake in the form of stickers and T-shirts. The last were possible thanks to the GNOME Foundation, so a huge thanks to them!

Sponsored by GNOME!

At least not too much. Some might know that I live in a rural area in Germany, where fast internet acces is a bit hard to find. In our home we neither have a telephone line nor internet access, so for my Gentoo related work I have to cross the street to use the (really slow) DSL line over at the company. That's why my desktop computer gets hardly used and my laptop does most of the work.

Anyway, being rural also means that no fast wireless connection is available, but now a new antenna near us at least provides EDGE access for several internet-challenged villages around the area...if they had installed UMTS I am sure that some dozens new customers would have appeared. Indoor signal strength is excellent, so I bought a small surf stick (Huawei E161) from my favourite provider with a prepaid on-demand contract. It is used for quick look-ups and email checks, where we always were too lazy to step outside.

Getting this to work was a bit tricky, as usb_modeswitch refused to work and so only the mass storage part is recognized. As most tutorials were for older kernels or »stale« distributions like Debian or Ubuntu, I could not figure out the correct way. Essential is of course the integration of the correct device drivers in the kernel, which are found in »Device Drivers/USB support/USB Serial Converter support«: CONFIG_USB_SERIAL_GENERIC (USB Generic Serial Driver) and CONFIG_USB_SERIAL_OPTION (USB driver for GSM and CDMA modems). To enable the modem along-side the mass storage you need to emerge sys-fs/udev with USE=extras, which installs the modem-modeswitch utility, which will automagically activate the modem on plug-in.

Connection happens with ppp, that needs enabled support in the kernel in »Device Drivers/Network device support/«: CONFIG_PPP (PPP (point-to-point protocol support) and CONFIG_PPP_ASYNC (PPP support for async serial ports). Install the following script as /etc/ppp/chat.provider (or choose another name, you have to adjust the other script then). It assumes disabled PIN and you have to fill in your APN.

ABORT BUSY
ABORT 'NO CARRIER'
ABORT VOICE
ABORT 'NO DIALTONE'
ABORT 'NO DIAL TONE'
ABORT 'NO ANSWER'
ABORT DELAYED
# modeminit
'' 'ATZ'
TIMEOUT 5
OK AT+CPIN?
'READY-AT+CPIN=-' ''
TIMEOUT 20
'OK' 'AT+cgdcont=1,"ip",""'
'OK' 'ATDT*99***1#'
CONNECT \d\c
# end of pppconfig stuff 

The next one is placed as /etc/ppp/peers/provider assuming that no authentication is needed (true for my provider).

hide-password
noauth
connect "/usr/sbin/chat -f /etc/ppp/chat.provider"
debug
/dev/ttyUSB0
460800
defaultroute
noipdefault
noccp
nobsdcomp
novj
user ""
password ""
usepeerdns
connect-delay 10000

Now you can connect with /usr/sbin/pon provider and disconnect with /usr/sbin/poff. All output is logged via syslog (virtual console 12) or you use a dial tool of your choice.

One of the complains I often get for my QA work (which I have to say is vocally not appreciated even by the other devs), is that I could just go on and fix the issues I find rather than opening but for them because “it just takes five minutes from bug to commit” to fix the problem.

No it does not take five minutes to fix something, I can assure you!

Of course people will continue to say that it just takes a few minutes to find the problem and come up with a patch; the problem is that most of the time, for the kind of bugs I report myself, to fix them properly takes much, much more.

Most of the time that some developer decides that some single problem does not warrant to remove a package, even if it doesn’t have anybody looking after it, the same packages re-enter my radar at the next round of tinderboxing, or in the best of cases, a few months later.

The problem is, when a package has a maintainer, that maintainer is supposed to keep the package in line with the development policies; if you don’t maintain a package but commit a five-minutes-fix you’re not ensuring it complies with the policy but you’re fixing the single symptom I reported, which most likely is just the one that I hit first.

When I (and I’m not boasting here, but just stating how it is) fix a package, I do things like removing older versions, making sure it complies with all the policies, check all the bugs the package has open, check for things that there aren’t bugs for, like CFLAGS and LDFLAGS being respected, the files not being pre-stripped, features that might be missing, version bumps requirement, correct dependencies, and so on so forth. It’s not a five-minutes work! It’s often a multiple hours work instead!

What is upsetting me, to return to the fact that Gentoo’s QA problem is with developers is that some developers think it’s fine to remove a package from the QA removal queue just because they fixed the last bug I filed. I’m sincerely considering the idea of making it policy that if you wish to save a package from QA you got to fix all the problems with it, and take maintainership of it if it breaks again. And for those ignoring these, we should definitely enforce some kind of penalty in form of not being able to “save” a package from removal any longer.

After some of the comments on the previous post explaining the tinderbox I’ve been thinking more about the idea of moving it to a dedicated server, or even better making it an ensemble of dedicated servers, maybe trying to tackle more than just one architecture, as user99 suggested.

This brings up the problem of costs, and the worth of the effort itself. Let’s start from the specifics: right now the tinderbox is running on Yamato, which is my main workstation, it’s a bi-quad Opteron, total 8×2.0GHz CPUs, 16GB of registered ECC RAM, and over 2TB of storage, connected to the net from my own DSL line which is not that stable nor fast. As I said the main bottleneck is the I/O, rather than the CPUs, although when packages have proper parallel build systems, the multiple CPUs work quite well. Not all resources are dedicated to the tinderbox effort as they are: storage space especially is just partially given to the tinderbox as it doesn’t need it that much. I use this box for other things beside Tinderboxing, some related to Gentoo, other to Free Software in general, and others finally related to my work or my leisure.

That said, looking through the offers of OVH (which is what Mauro suggested me before, and seem to have most friendly staff and good prices), a dedicated server that has more or less the same specifics as Yamato costs around €1800/year. It’s definitely too much for me to invest to the sole Tinderbox project, but it’s not definitely too much (getting the hardware would cost me more, and this is outsourcing all the hardware maintenance problems). Considering two boxes, so the out-of-tinderbox resources could also be shared (one box to hold the distfiles and tree, the other to deal with the logs), it would be €3600/year, and the ability to deal with both x86 and amd64 problems. Again, too much for me alone, but not absolutely too much.

Let me consider how resources are actually used right now, one by one.

The disk on-disk space used by the Tinderbox is relatively difficult to properly evaluate: I use separated but shared partitions for the distfiles, the build directories and the installed system. For what concerns the distfiles, and the tree, I could get some partial result from the mirrors’ statistics; right now I can tell you that 127GB is the size of the distfiles directory on Yamato. The installed system is instead 73GB (right now) while the space needed for the build directories never went over 80GB (which is the maximum size of the partition I use), with the nasty exception of qemu, as it fills the directory entirely. So in general, it doesn’t need that much hard disk space.

Network traffic is not much of a problem either I’d say: beside the first round of fetching all the needed distfiles, I don’t usually fetch more than 1GB/sync (unless big stuff like a new KDE4 release is handled). This would also be vastly made moot if the internal network had its own Gentoo mirror (not sure if that’s the case for OVH, but I’ll get to that later).

So the only problem is CPU and I/O usage, which is what a dedicated server is all about, no problem there I guess at all, so whoever would end up hosting the (let’s assume) two tinderboxes would only have to mind the inter-box traffic, which is usually also not a problem if they are physically on the same network. I looked into OVH because that’s what I was suggested; I also checked out the prices for Bytemark which is already a Gentoo sponsor, but at least the price to the public is entirely another league. Ideally, given it’s going to be me to invest the man-hours to run the tinderbox, I’d like for the boxes to be located in Europe rather than in America, where as far as I know most of Gentoo’s current infrastructure is; if you have any other possible option you can share, I’d very much like to compare first of all the prices to the public for various providers, given a configuration in this range: LXC-compatible kernel, bi-quad CPU, with large cache, 16G RAM minimum, 500GB RAID1 storage (backup is not necessary).

Now, I said that I cannot afford even to pay for one single dedicated server for the tinderbox, why am I pondering about this? Well, as many asked before “Why is this not on official Gentoo infra?“ is a question I’m not sure how to answer, last I knew infra wasn’t interested in this kind of work. On the other hand even if it’s not proper infra, I’d very much like to have some numbers, to propose the Gentoo Foundation for paying for the efforts. This would allow to extend the reach of the tinderbox, without having me praying for help every other day (I would most likely not stop using Yamato for tinderboxing, but two more instances would probably help).

Also, even if the Foundation wouldn’t have directly the kind of money to sustain this for a long period, it might still be better to have them to pay for it sustained by users’ donations. I cannot get that kind of money clearing through my books directly, but the Gentoo Foundation might help for that.

So it is important, in my opinion, to have a clear figure, and objective, on the kind of money that it’d be costing. It would also help to have some kind of status “Tinderboxes covered to run for X months, keep them running”.

And before somebody wonders: this is all my crazy idea, I haven’t even tried to talk with the Foundation yet, I’ll do so once I can at least present some data to them.

Beware : non-Gentoo post ahead, feel free to skip if you don't care, I won't hold a grudge against you.

By all measures, I can safely say I'm not really a Christmas-y fellow. I hate Christmas shopping because I'm really bad at it (or is it the other way around?), I give the rest of my family a hard time at Christmas since I never know what I want and I'm really hard to shop for (took me 3 years to find an MP3 player that matched with my needs).

And usually, just a few days before Christmas, I'll turn into the Grinch: people on the subway carry even bigger bags than usual, people on the streets are way more careless than usual, ads and commercials everywhere overload my senses with Christmas references, etc.

So there, Christmas is not my favorite time of year.

However, there is something I love about Christmas: food. Point in case, I just had left-over foie gras along with a glass of Sauternes.

I'll just say that after my light lunch, I positively love Christmas.

Edit: To all the people who are trying to ruin my Christmas left-overs by trying to make me feel guilty about how foie gras is produced: take a step to realize that all industrialized agriculture works like this (especially eggs), not just foie gras. So unless you are 100% vegan, don't even try. If you are vegan, then just forget I even talked about the foie gras and have a glass of Sauternes, I'll happily share the rest of my bottle.

As I said before, I’m doing a lot of work to port Ruby packages in Gentoo to the new eclasses so that the gems can integrate better with Portage. Integrating better in this case means respecting the build phases we have in ebuilds (unpack, prepare, compile, test, install, merge to live filesystem), respecting the dependency tree as provided by Gentoo (including split dependencies for Ruby 1.8, 1.9 and JRuby) and the doc USE flag to build or not the API documentation.

Unfortunately, this is not really such an easy task sometimes, for at least two main reasons. The first is the lack of ebuilds for the packages needed for the tests to work; the second is the lack of proper dependency information in gems.

Missing ebuilds are due to the fact that, earlier, we never ran tests so we never had the need for some of the test-specific dependencies. At the same time we never cared much about documentation, so also the dependencies needed for documentation building were never worked on. There is quite a cross-over between the two of these classes of dependencies, and those are the dependencies for the Rakefile directly (both tests and documentation generation are handled by rake for most packages).

The other problem is that the gems themselves, while having a syntax to provide the dependency information (also split between runtime and development dependencies, the equivalent of our RDEPEND and DEPEND), they are rarely complete, at least for what concerns development dependencies (which is what we care about for documentation and, even more importantly, tests). Without this kind of information, making sure that tests work is often a matter of try-and-see: you run the tests and add the dependencies if they are not installed.

Unfortunately while usually adding a new ebuild does not lead to extreme trouble, Ruby gems make it quite a hassle, especially for the problems mentioned above. You cannot rely on the specification-provided information, since as I said is often incomplete. And at the same time, the sheer amount of packages that are possibly used for tests is definitely high (there are some different documentation tools as well but not near as many), which sometimes mean that to fix the tests for one single package, you end up having to package about a dozen, sometimes with interleaved, looping dependencies.

Now, the reason why I’m blogging about this right now s that I have to ask you, the users, to help me out with this. Please try to run tests on the Ruby ebuilds, and report if the any dependency is missing. Having now dozens of installed Ruby gems, both via fakegem and the old-style ebuilds, I don’t “feel” the dependencies as much; while I do tend to check the require directives, they often are confused enough that I might not notice entirely.

So pretty please, help me help you, and check for missing dependencies together ith me and the rest of the developers, thanks!

Yes, we will be there! Compiling all the way ... ,

Gentoo will be present at the 26th Chaos Communication Congress (26C3), from December 27th to 30th in Berlin, Germany. The annual conference of the Chaos Computer Club takes place at the Berliner Congress Center (bcc) in Berlin, Germany. Enjoy our ebuild hacking sessions, bug filing workshops, get some merchandise and use our local rsync/http mirror. You will find the Gentoo table on the upper floor.

Hope to see you there!

Robert Buchholz contributed to the draft for this announcement.

Damn, there's a lot of confusion, contradicting statements, idiocy, corruption, and lolwut around this topic. Now, I've done an Environmental Engineering course. Hence as an expert who is expertly placed, you can trust me to wade through this muck and give you the right answer.

Let's start from the top. The Greenhouse Effect. No, you won't need Wikipedia for this one. It's simple.

Most things in this world are opaque. Which means they don't allow light to pass through them. The wavelengths of visible light they don't absorb gives them their color.

Gases are mostly transparent due to their low density. This is different from colourless, which means that most gases do not absorb visible light. But when you have a huge amount of air, such as an atmosphere, "transparent" becomes irrelevant.

Different gases in the atmosphere absorb different wavelengths of light. What happens when they absorb it? They re-emit it in a different direction, and often with a different wavelength. Water Vapour, CO₂, Methane, Ozone are the major players in this. They absorb visible light and infrared light, and re-emit it as infrared. This is called the Greenhouse effect.

This is a good thing. Without the greenhouse effect, we could not survive. Temperatures on our planet would be extreme, with the average temperature being sub-zero. The major contributor to our survival is water vapour, which keeps a large amount of thermal radiation around Earth.

Disaster strikes when someone decides to pump a bazillion litres of CO₂ into the atmosphere every year. What does this do? It's complicated. Complicated enough that we don't know for sure the dynamics of everything it does. It's not as simple as rocking a cradle. The global climate is a chaotic system. Even tiny changes in the initial conditions magnify exponentially and change the result completely. This is why BBC doesn't show more than a week's forecast in weather.

We never just say "OK, T°C increase in global temperature in X years" "Polar ice caps will melt in Y years". That's what uninformed news outlets say. They try to dumb the results and predictions down for the general public, and in the process make them incomplete, inaccurate, or wrong.

This is also why scientists' predictions concerning climate change seem to be "wrong" most of the time. This leads the naive public to assume that we're talking out of our collective arses, and that Climate Change is bogus. And when we try to explain what we meant, people go "NYA NYA NYA, YOU'RE WRONG, NOW STOP MAKING EXCUSES AND SHUT UP". And that's what we do. Because we know we're right. That's the thing about science. It doesn't matter what you think, the truth will stay the truth.

Here's the truth. We don't know exactly what's happening (yes dears, present tense) thanks to our shortsightedness. But we're all bloody damn sure about one thing. Whatever's happening isn't good for us. That's why it's called "Anthropogenic Climate Change" (man-made and not-good-for-man).

Now that I'm done being all dramatic and apocalyptic, I notice I forgot to mention all that stuff about Albedo, Positive feedback loops, Quasi-static equilibrium, cyclic climate change, frog in boiling water, etc. Oh well. Maybe if everyone paid attention in college, I wouldn't have to start from the top and get bogged down in the basics before getting to the interesting stuff.

In this podcast comprookie bash's pulseaudio, plus talks about learning Bash. Stop by linuxcrazy.com for more info or say hi on irc server freenode channel #linuxcrazy

LINKS:
EASI-READER
http://xrl.us/bgq5x3 (Link to www.amazon.com)
DSP-500
http://xrl.us/bgq5ze (Link to www.plantronics.com)
Pro Bash Programming
http://xrl.us/bgq5zi (Link to www.apress.com)
Linux Command Line Bible
http://xrl.us/bgq5zr (Link to www.amazon.com)

irc network freenode channel #linuxcrazy

Download

This was originally sent to the linux-kernel and driver-devel mailing lists. Might as well post it here to get a wider audience as the last report was received well.

Here's a summary of the state of the drivers/staging/ tree, basically what will be coming in the 2.6.33 merge, and what the status of the different drivers are so far.

Sorry it's late (after the merge), but hey, better late than never.

Again, drivers/staging/ is NOT a dumping ground for dead code. If no one steps up to maintain and work to get the code merged into the main portion of the kernel, the drivers will be removed.

Also, drivers can now be merged from mainling into the staging directory, providing a path out of the kernel for some obsolete and/or broken drivers.

So, here's some drivers that will be removed in the 2.6.33 kernel:

• android drivers. Google and no one else stepped up to maintain them, so they will be dropped. So sad...

• dst The developer isn't working on this anymore and recommended that it be removed as no one is using it.

Here is some new drivers that will show up in .33:

• arlan, netwave, strip, wavelan - wireless drivers that are on their way out of the kernel. If anyone is actually using this old, obsolete hardware, speak up soon, otherwise they will be removed in a few kernel releases.

• ramzswap - a compressed ram driver

• rtl8192u - yet another wireless driver

• samsung-laptop - laptop for the N128 Samsung laptop

• batman-adv - a network protocol

• dt3155 - a frame grabber driver

• sm7xx - another frame buffer driver

Here's the list of drivers that have had work done on them that will show up in the .33 release:

• comedi - lots of development effort happened here, mostly all cleanups, but there are some logic changes. More is needed, and it's moving along nicely.

• line6 - lots of work happening, very nice to see

• rt* - loads of cleanups and other merges. Will be obsolete soon due to a "real" wireless driver being worked on, but it's still nice to have these be a working alternative until then.

• rtl* - more wireless driver work, horrible code, but it seems to work for the users. Hopefully more development time can be spent here in the new year.

• dream - here's the platform specific code for the Android G1 platform. This might be the way the android code sneaks back into the kernel, as there is developers trying to get this to work. Of course, it's all happening without Google's help. {sigh}

• et131x - loads of cleanups, more left to do. Good solid progress happening here.

• iio - a new driver added to this subsystem, along with other fixes and cleanups. Looking nice.

• poch - still some work happening, nice to see it pick back up.

• panel - minor cleanups.

• vme - cleanups and minor tweaks, still alive and kicking

• vt66* - more wireless drivers, will be obsoleted by a "real" driver again.

• wlags49 - more cleanup work as well.

Here's some drivers not listed so far, that have had work done recently, after the 2.6.33-rc1 merge happened, so it has to wait for the .34 kernel release:

• wlan-ng

• slicoss

• mimo

• asus_oled

• udlfb

• w35und

Hm, so, what's up with all of the other staging drivers, and why have they not had any development? What is the status of them? They are now on the short list to be deleted in 2 kernel releases, unless some real development happens on them.

This means, unless someone steps up and starts doing real work (not trivial spelling fixes) on the following drivers, they will be removed in the future kernel releases.

• arlan, netwave, strip, wavelan - wireless drivers mentioned above that are on the way out. Slated for removal in 2.6.35

• hv - Microsoft Hyper V drivers. The developers again seem to have disappeared, this is getting old. Slated for removal in 2.6.35

• p9auth - this will be removed in .34 unless someone steps up.

• frontier - slated for removal in .35. Will be easy for someone to pick up if they want to (hint, hint, hint)

• altpciechdma - this will be removed in .34 unless someone steps up.

• b3dfg - this will be removed in .34 unless someone steps up.

• pohmelfs - filesystem under development out of tree, would be nice to get the patches merged back into here

• quatechusb2 and serqtusb2 - usb to serial drivers that need to get merged into mainline.

• rar and sep - Intel needs to step up here and get this code cleaned up properly, or it too will be removed in .34

Again, if someone is looking for some kernel development work to do, picking any of the above drivers up to get them merged into mainline, would be a great thing to do.

And, on a final, and sadder note, I'd like to announce the failure of the driver project to complete a driver for a company that requested it. This was totally my fault, and I would publically like to apologize about my lack of getting a SCSI driver written in time for a company that had asked for it. So, while the Linux driver project is doing great work for a large number of companies, every once in a while we do fail, we are only human.

I know that quite a bit of people are still unsure on what a tinderbox is, on what it does, and especially on why they should care enough that I’m bothering them every other day about it on my blog (and by extension on Planet Gentoo and the Gentoo.org homepage which syndicate it). So I’m now trying to write a long-breathed article that hopefully will cover all the important details.

What is “a” tinderbox

The term tinderbox, as reported by Wikipedia has been extended to the general use starting from the software, developed by Mozilla, designed to perform continuous integration over a given software project. This doesn’t really help that much because the term “continuous integration“ might still not say anything to users. So I’ll try to explain that from scratch as well.

Gentoo users, especially those running the unstable branch, are unfortunately used to breakage caused by build failures after a library update or other environment changes like that. This problem is increasingly present also during the development phase of any complex software. It gets even worse because while developers might not see any build failure on their machine, they can introduce “buggy“ code that breaks on others, as not all distributions have the same environment, the same libraries, the same filesystem layout and so on so forth.

And this is just by limiting the scope of our consideration to a single operating system – Linux in this case – and not considering the further problems caused by the presence of other software platforms, such as FreeBSD (which is still a Unix system), Mac OS X, and Windows. This is one of the biggest problems with multi-platform development that make it definitely non-trivial to write software that works correctly between these systems. I could write more about that topic but I’ll leave that to another time.

To make it possible for the developers not to have to manually get their code on multiple machines with various combination of operating systems and versions to ensure that the code does build properly after every change is merged, the smart approach was to invent the concept of continuous integration. To sum it up, think about what I just said – getting the code on multiple machines, with different operating systems, or versions of operating systems, build and eventually execute it – but done by a software rather than having an human doing it.

Mozilla’s software for continuous integration is called Tinderbox and for whatever reason, the name has stuck in Gentoo to refer to the various tries we have had at setting up some continuous integration testing. I’m not sure on the reasons why the name stuck in the Gentoo development team, but so it is, and so I’m keeping it.

Why is it “my” tinderbox

As I just said, Gentoo has had in the past more than one try at making continuous integration a major player in its development model. I think at least four people separately have worked on various “tinderboxes“ in the past five years, both as proper Gentoo projects and as outside, autonomous efforts. So I cannot call it “the Tinderbox”, but rather “my tinderbox”, to qualify which one among those that were and are.

Right now, we have three actively maintainer continuous integration efforts called tinderboxes: my own is the latest one joining the party, before that we already had Patrick’s and before that the Gentoo tinderbox which runs on proper Gentoo infrastructure boxes.

As I already rambled on about this “duplication“ of efforts is not a problem, as the three current systems have different procedures, and different targets. In particular, the “infra“ Tinderbox is mostly there to ensure the packages in the system set work for most major architectures, to provide reverse dependency information, and to make available binary packages useful for system recovery in case of major screw-up. On the other hand, me and Patrick are using our tinderboxes to identify bugs and report them to developers who might have not known about them otherwise.

What my Tinderbox does

I’ve written more or less how it works although that was really going in the detail of what I do to have it working. For what concern users, those details are mostly unimportant.

What my Tinderbox does, put it simply, is building the whole Portage tree, at least that’s the theoretical target. Unfortunately, as many noted before, it’s a target that no one box in the world can likely reach in our lifetime, let alone continuously. Continuous integration tools are designed to take away from the developers the time-consuming task of trying their code on different platforms (software or hardware, it doesn’t matter); even though I’m now limiting the scope of them to testing Gentoo, the possible field of variations is limitless.

Not only we support at least two operating systems (Linux and FreeBSD), a number of architectures (over a dozen), two branches (stable and unstable), but for the very essence of Gentoo, each installed system is never identical to another one: USE flags, CFLAGS, package sets, accepted packages from the unstable branches, overlays… Testing all these variables is impossible, so my tinderbox reduces (a lot) the scope, while still trying to be as broadly applicable as possible.

It runs over the unstable x86-keyworded branch of the tree (~x86 keyword), along with some packages that are not available by default and are rather unmasked (mostly toolchain-related). It uses vary bland CFLAGS, forced --as-needed and some common USE flag setup. It runs tests but it doesn’t let their failure stop the merge. It enables USE flag (for dependencies) as needed to have as many packages installed as possible.

The big part of the work is done by a single loop that tries to install, one by one, all the packages that haven’t been tested in the past two and a half months. Portage is left to remove conflicting packages as it finds fit. Sometimes packages are rejected for various reasons (they collide with another package, there is a conflict in the needed USE flag settings between different packages, or they require very old software versions that would in turn cause other problems), so instead of having the full Portage tree available for ~x86, I can only get a subset, the biggest subset I can at least.

The results

Of course, to understand why the Tinderbox is an important project, and why I’m investing so much time on it, and looking for other people to invest part of their time (or resources) to help me, is necessary to look at what the by-products of its execution are.

I’m not making my binpkgs available to the public (like the infra-based tinderbox has), mostly because I’m not allowed to: firstly I don’t enable the bindist USE flag, which means I’m allowing build configurations that are non-redistributable, because of licenses or trademarks, secondly because that’s not my target at all, and they may very well not be functional, in some parts.

The accomplishments coming from my efforts are, generally speaking, bug reports. Not only I scan through the failure logs for those ebuilds that fail to build in this environment, but I also scan for failing test procedures, and other similar quality issues. But again, this is not the result final users are looking for, as bug reports don’t mean anything for them.

Results that are good for users are, instead, the fixes for these bug reports: you can be safe to have documentation installed in the right place where you expect it; you can be safe that if you need to debug a problem, you only need to follow the guide without the build system of the package coming in your way; you can be safe that a package that will report itself as installed is indeed installed and it does work.

While, obviously, there are still problems that my Tinderbox effort won’t be finding anytime soon (for instance the problem of missing dependencies, which is instead the speciality of Patrick’s Tinderbox), and test procedures are rarely that well thought, designed and realised that they don’t leave possible runtime problems to be found, I think that keeping it running, continuously integrating as many ebuilds as it can, is definitely going to be of help for Gentoo’s general quality and stability.

And there is another thing that users are most likely interested in: testing of the future toolchain. As I said before, beside using the ~x86 visible ebuilds, my Tinderbox is also running some masked packages, which include, nowadays, gcc-4.4 and autoconf-2.65. Using these versions, not yet available to the general public of users, allows me to find failure cases related to them before they are made available. This serves the double role of assessing the impact that any given change might have on the users (by knowing how many packages will be broken if the package is unmasked), and correcting those problems before they have the chance of wasting users’ time.

Helping

Continuous integration can’t be said to be a “boring” task, in the sense that every day you might stumble into a new problem, for which you’ll have to devise a solution. On the other hand, it’s an heavy duty, for both the machines performing the job and the people that have to look through the logs. Even the sole task of filing the bugs is time-consuming, and that’s without adding the problems dealing with the human factor which often take you much more time.

Furthermore there are a number of practical issues tied into running this kind of continuous integration: the time needed to build packages conditions the amount of packages they can test over a given time frame, and unfortunately to reduce that time often you have to push for higher end machines (a lot of the work is I/O bound, and not all the software can build or execute tests in parallel), which tend to have high price tags, as well as consuming more power (and thus costing more over the long term) than your average machine.

For this reason both me and Patrick tend to ask for material help: we are taking the costs of these efforts directly.

It has been suggested a number of time to host the Tinderboxes over Gentoo infrastructure hardware, but there have been problems before about this. On the other hand, I think that the way I’m currently proceeding, for my effort at least, could open the possibility for that to happen. The one big issue for which I don’t really feel comfortable with running the tinderbox remotely is easy access to the logs for identifying problems and, especially, to attach them to bug reports. I’m currently thinking how to close that gap but it needs another kind of help in the form of available developers.

And one kind of help that costs very little on users, but can help a lot our work is commenting (and criticising if needed) our design choices, our code, our methods. Constructive criticism of course: telling us that our method sucks and not giving any suggestion on how to make them better is not going to help anybody, and can actually lower our morale quite a bit.

So please, the greatest favour you can do me is continuing to listen my ramblings about QA, tests, Tinderbox and log analysis; and if you are still unsure how something works in this system, feel free to ask.

A few words to say that even though I've been busy irl, gnome 2.28.2 is almost completely in tree (about 10 packages left). Also, I finally killed tracker 0.6 from the tree, it was rusty and deserved some rest. Tracker 0.7 has been added and although it's API/ABI changed, it already is integrated to nautilus 2.28. I still have to get the totem patch for it and we will be back to what was supported with 0.6. I've also updated the live ebuild and I'll make sure it stays in sync with last release.

Anyone in Nuremberg? ;)

Activity : Linux Kernel Internals and Crash Dump Analysis
Activity Code : Linux-IHC-001
Type : Internally Held Classroom
From : 01/26/2010
To : 01/28/2010
Facility: EMEA - Nuernberg, DEU

So I’m again trying to find a solution to the log analysis problem; the main issue at this point is that the tinderbox is generating something along the lines of 200MB of logs a week — probably also because thanks to Zac it’s much much more efficient than it was before. With such an amount of data to shuffle through, the grep command from within Emacs is no longer feasible.

What I’m considering using now is to store most of the data directly inside a database (PostgreSQL since that’s what I’m using already here) and then take it out from that, in a simple (web) interface. The reason why I’m going for a web interface is that it’s likely what takes less time to design, to quickly report and copy content.

On the storage side, the main question for me is whether the database should also contain specific details of the problem or just the presence of such a problem and a pointer to the log file. In the former case, the web application could easily be extended to something more than a glorified grep, but it’d have to store a non-trivial amount of data. Some log files are well over the 10MB, so it gets a bit tricky to handle those properly.

Thinking a bit further on the interface, it should really be a way to report bugs directly: if the application can find that the merge found ELF files in /usr/share, filing the bug directly is just a matter of finding who exactly maintains a particular package (which is quite easy), and it wouldn’t even require copy-pasting if the data is available directly in the database, already parsed. Obviously, it would still require manual confirmation before opening the bug, and before doing so, it should also implement an easy search function to show possible duplicates.

While my first guess was to write a stupid CGI (or using the Ruby integrated webservers in a script) to have on the browser the results from the database, I’m now more interested in the idea of having some more complete application to deal with this. Pavel also suggested for allowing other developers to access the interface to report the bugs, so that even if I’m not around to do the filing someone else can. Unfortunately that also bring up a problem: if I were to allow developers to file bugs with their account I’d have to make them give their login information to the tinderbox (and I don’t like that not even if it’s me running it); on the other hand I’d rather not make them file bugs with my own account, so I guess it’d require to set up a no-mail account for the tinderbox (no-mail since it’d be pointless to have mail coming for a tinderbox account), and then make the users CC their own address by default.

Now comes the problem: I can probably start working on such an interface myself, using Ruby on Rails, which is something I’m somewhat fluent in; on the other hand, I know of no Ruby interface for the Bugzilla RPC protocol, but there is a well-tested pybugz extension for Python (which I’m definitely not fluent in). Before I start hacking anything at all (since that’s going to change quite some bits of the interface; if I were to use Ruby on Rails, the ORM will most likely call for an abstracted interface to the database, which is good for some things but not for everything), I really need to see if somebody could help me with such a task in the long run.

If somebody is up to writing the interface in Python to my specs, using pybugz, that’d be fine, otherwise I’d like to see if somebody already worked in a pybugz-like interface for Ruby instead. At worse I could settle for just opening the bug with pre-filled fields, and then attach the build log afterwards (to attach the log I need to know the bug number of the just filed bug), and that’s not feasible by just providing a link to the pre-filled bug (although it should be still be quite an improvement to my workflow, if I had that!).

So, anybody can provide any insight or volunteer to help me out?

Recently I joined Gentoo AMD64 team. I always wanted to become an archer and bring the stable branch in a more sane condition. Fortunately, amd64 members are already doing an amazing work, and amd64 stable branch is in a pretty well state. So how do I plan to do the keywording and stabilization?

I am going to use two different ways. First, I will use my old Athlon AMD64 single core / 1,5GB@333Mhz of RAM as a stable platform to do the stabilizations of small packages. This is a quite old CPU so I can’t do much there. On the other hand, I owe a new Phenom X3 machine with 2GB@800Mhz of RAM. However, this machine is running testing Gentoo with plenty of masked packages as well ^_^

So the only choice I had to take advantage of this is to build a stable chroot

Those are the steps I followed ( Might be wrong, but hey, they worked for me :p )

————————————————————————————

1 ) mkdir /mnt/gentoo-stable

2 ) Download the latest autobuild from your preferred mirror.

    wget http://files.gentoo.gr/releases/amd64/autobuilds/current-stage3/

3 ) mv stage3-amd64-20091217.tar.bz2 /mnt/gentoo-stable

4 ) cd /mnt/gentoo-stable && tar xvjpf stage3-amd64-20091217.tar.bz2

5 ) cp -L /etc/resolv.conf /mnt/gentoo-stable/etc && cp -L /etc/passwd /mnt/gentoo-stable/etc && cp -L /etc/shadow /mnt/gentoo-stable/etc
6 ) Adjusted my make.conf
7 ) Created a custom init script for the host machine
8 ) rc-update add gentoo-stable on my host machine
9 ) Done

-------------------------------------------------------------------

Now all you need to do is to run

chroot /mnt/gentoo-stable /bin/bash && source /etc/profile && env-update

See? It wont take more than 5′ to have a brand new stable Gentoo

ps: As you may have notitced, I am binding my cvs checkout of portage to /mnt/gentoo-stable/usr/portage. This means that the chroot is using my cvs portage to build the packages. Of course, you can always bind your rsync clone of portage by using/

mount -o bind /usr/portage /mn/gentoo/usr/portage  :)

Trivial procedure but I had to mention it

Disclaimer: I used 32bit chroot guide from Gentoo docs as a tutorial reference

Well, after a lot of hacking GPytage 0.3.0 RC1 is finally ready to be released. This version underwent nearly a complete rewrite to make coding it much easier and of course improve the end users experience of editing Portage’s config files. Notable features of this release include:

• Supports recursive directory support now, where the old release was limited to one depth of a package.foo directory
• Improved creation, deletion, and renaming of files. You can now rightclick in the leftpanel on the desired file and get these options as well
• Copy and Paste support now implemented
• When editing an entry you can now hit tab to save the change and move to the next editable field.
• When adding a new file, reverting, deleting, or a similar operation is executed the folder you were currently in is now reselected after GPytage reloads its database

GPytage should be hitting the Portage tree in the next few hours. A simple

should net you package for testing. It will be keyworded ~arch, so stable users will need to add an entry to package.keywords to install it.

While this is a release candidate, there should not be any bugs floating around. If you find any bugs or want to suggest an improvement don’t hesitate to either post it here or at https://gna.org/projects/gpytage/

GPytage-0.3.0 RC1

Looking forward to hearing everyone’s feedback.

Since few weeks I was really busy due to my studies :

1. I was preparing exams
2. I got a lot of projects to finish

during this period, gentoo was outside of my priorities (eva: sorry for gnome ).
I'm back now, and I intend to fix a lot of bugs .

Gentoo, I missed you

I have written before about some of our soft spots for what concerns Gentoo’s quality. Today I’m writing a quite inflammatory piece that most likely will cause me to take a bit of flak, but which I’m pretty sure it’s going to the point.

The main weakness in Gentoo’s Quality Assurance is developers not giving a shit about quality.

Let me try to explain: there are many problems with Gentoo’s QA team, like the lack of proper coordination most of the time, the lack of a real Gentoo-based effort for continuous integration testing (the tinderboxes are mostly direct pet projects of the people running them, which means for the QA standpoint Patrick and me), and the lack of an absolute rulebook of “dos ad don’ts” for what concerns ebuilds.

Of the few accepted rules, there are a few that I’m trying to enforce via the tinderbox and by opening bugs, one of these is installing documentation in the /usr/share/doc/${PF} path (where ${PF} is the full name and version of the package, including the revision number — yes I know that it would have been better to use ${CATEGORY}/${PF} but let’s not go there for now). To do so you either use the Portage-provided dodoc and dohtml helpers, or you have to tell the configure script or the install makefiles to change the directory they install their documentation into; the defaults are never right because at the worst case they don’t take the version into consideration and at the best have no idea about the Gentoo-specific revision.

It doesn’t seem like a controversial rule to enforce, does it?

Well it seems like some developer (whom I’m not going to out just yet) doesn’t like that idea, and even if it’s now very well known that the bugs I’m opening from the tinderbox are vastly on behalf of QA decided to close two of my bugs as WONTFIX. And yes that pisses the hell out of me. Even more because the packages installing in the wrong directory do so because their upstream-provided source packages has been voluntarily split to provide a temporary counter-measure to the lack of proper USE dependencies (and this has caused more than a little grief I’d say).

But it’s not the first time I get responses on this line; for instance some developers find too bothersome to explicitly list the upstream-provided precompiled (sometimes proprietary sometimes not) files that fail important QA/security checks like RPATHs and TEXTRELs, and thus prefer simply restricting binary checks entirely (note: binchecks also fixes vulnerable and wrong RPATHs such as empty entries or current-work-directory).

We got all the “let’s take shortcuts” developers who prefer to commit half-thought stuff without masking it or without experimenting with it for a while to flesh out eventual requirements. While importing a huge amount of code that was developed outside of tree is always a risk (as the Ruby-NG effort is showing pretty well), simply pushing eclasses that support new versions of a language without allowing the user to disable them or without checking for proper reverse dependencies is a pretty bad idea.

Further on the problem comes with developers that drop patches without checking whether they are needed, and without warning that the problem might re-surface (for instance I know that I half-blindly dropped some patches from Linux-PAM; on the other hand I’m currently working on making it work on uClibc again).

So in general, yes, the problem with Gentoo’s QA is mostly developers, and yes, I know wee should come up with some rulebook that is “there or nothing”, I’ll see what I can do about that with the time I got.

You probably are used to me sending last rites for packages on behalf of QA, and thus removing packages (or in the past just removing packages, without the QA part). It often seems like my final contribution to Gentoo will be negative, in the sense that I remove more than I add.

Right now, though, I’ve been adding quite a few packages to the tree, so I’d like to say that no, I’m not one of those people who just like to remove stuff and who would like you to have a minimal system!

So with some self-advertisement (and a shameless plug while I’m at it…) I’d like to point out some of the things I’ve been working on.

The first package I’d like to separate is the newly-added app-emacs/nxml-libvirt-schemas: as I ranted on I wanted to be able to have syntax completion for the libvirt (a)XML configuration files (I still maintain they should have had either a namespace, a doctype or a libvirt-explicit document element name), so now that me and Daniel got the schemas to a point where they can be used to validate the current configuration files, I’ve added the package. It uses the source tarball of libvirt, with the intent of not depending on it, I’m wondering if it’d be better to use the system-installed Relax-NG files to create the specific Relax-NG Compact files, but that’ll have to wait for 0.7.5 anyway (which means, hopefully next week).

The second set of packages is obviously tied in with the Ruby-NG work and consists of a few new Ruby packages; some are brought in from the testing overlay I’ve built to try out the new packages, others have been brought in as dependency of packages being ported to the new eclasses, one instead (addressable) is a dependency of Typo that I didn’t install through Portage lately. I should probably add that I’m testing the new ebuilds “live” on this blog, so if you find problems with it, I’d be happy to receive a line about that.

The third set of packages instead relates to a work I’m currently doing for a long-time customer of mine, a company developing embedded systems; I won’t disclose much about the project, but I’m currently helping them build a new firmware, and I’m doing most of my job through the use of Portage and Gentoo’s own ebuilds. For this reason I have already added an ebuild for gdbserver (the small program that allows for remote debugging) that makes it trivial to cross-compile it for a different architecture, and I’m currently working on a gcc-runtime ebuild (which would also be pretty useful, if I get it right, for remote servers, like my own, to void having to install the full-blown GCC, but still have the libraries needed).

And tied to that same work you’ll probably find a few changes for cross-compilation both in and out of Gentoo, and some other similar changes; I have some GCC patches that I have to send upstream, and some changes for the toolchain eclass (right now you cannot really merge a GCJ cross-compiler, or even build one for non-EABI ARM).

So this is what I’m currently adding to the tree myself, I’m also trying to help the newly-cleaned up virtualization team to handle libvirt (and its backports) as well as the GUI programs, and I should be helping Pavel getting gearmand into shape if I had more time (I know, I know). And this is to the obvious side of the tinderbox work which is still going on and on (and identi.ca proves it since the script is denting away the status continuously), or the maintainer work for things like PAM (which I bumped recently and I need to double-check for uclibc).

So now, can you see why I might forget about things from time to time?

Because of course we all have pains in the neck and nowhere else. And let me warn you: the timeframe in this post is messed up because I wrote it in the past week or so trying to avoid ranting every day; so when I say “today” or “yesterday” it’s quite relative

So I’m still going on with the ports to ruby-ng of the dev-ruby ebuilds; I gave priority to the packages that are needed for Typo (which is the software I use for this blog) so I could also test them properly first hand. The results aren’t excessively bad I’d say, actually the space wasted on my server was reduced; I had to make a fix to my remove-3rdparty Typo branch to be able to use the new will_paginate gem (since the new version in gemcutter does not have the mislav- prefix like the one from github had), but the result is, after all, not bad at all.

As I said before there are quite a few common problems with gems that I’d like to point out, so that future Ruby Gem developers will try to avoid repeating such mistakes:

• missing licensing information, or too much licensing information: while Gentoo is definitely not Debian, nor we’re Fedora, and thus we tend to have a much more “relaxed” approach in term of licensing for all the packages falling out of the system set (since we don’t redistribute binaries but only sources), it’s not really that nice when a package is lacking all kind of licensing information, or where the LICENSE file and the README file provide conflicting licensing information;
• missing tests, specs, or missing data files: I found quite a few gems that don’t package their tests (or specs if they use rspec), or that package the spec files but not the datafiles they use; this is quite a problem since it makes the package unverifiable; this gets even more nasty when the files are not even in the upstream repository!;
• bogus build-time dependencies: this almost happened today with addressable (even though, kudos to its author, addressable itself is quite nice to work with!), as gemcutter reports a build-time dependency over launchy … and indeed it’s there, in declaration; on the other hand the only thing it’s used for is opening the rcov output in a browser, and that’s not even needed to run the Rakefile; the bottom-line is that I didn’t need to push launchy and configuration in the main tree (both had the previous noted problems) even though the gems declare them as needed — this is one reason why I don’t think we should “auto-generate” ebuilds;
• single version dependencies: if you only allow a precise version of another gem to be used with yours, you’re going to play catch-up ad infinitum to make sure that your gem is usable; Hans was bitten by this with cucumber, and I sidestepped it in activewebservice for Typo, since the gem required Rails 2.3.3 (or 2.3.4 depending on the version) while I wanted to run the last secure one (2.3.5);
• fork the code like bunnies: this is probably caused by the bad habit of GitHub to propose forking code continuously; the already-mentioned actionwebservice is quite problematic from that point of view: 2.3.3 version was released by datanoise, 2.3.4 by dougbarth and we now got two possible gems for 2.3.5;
• use a not maintained documentation system: while RDoc is almost standard in the Ruby world, I found two packages last night (sinatra and rack-test) that use an alternative system based on haml: Hanna which unfortunately only works with an older version of RDoc; for this reason, the documentation for neither is built and installed.

There are probably more common mistakes that you have to look forward for in the future, but this at least is the first list, although it’s probably rehashing most of the stuff I have ranted about in the past.

And one important announcement here: if you care about Ruby 1.9, you should know that we’re currently in a huge mess: a lot of code fails tests with Ruby 1.9 so I’ve been dropping support for it everywhere it cannot be tested. Similarly it happens for JRuby, even though for different reasons often. And to test all the packages to re-add Ruby 1.9 when needed is going to take quite a bit of time. For this reason, you really should either try to help out by testing it yourself, or find a way to support us through the job (I can be hired for the task).

For the tinderbox I’ve been adding quite a few tests that are not currently handled by Portage; some of these tests as I said before are taxing, and all of them are linear, serial, which means that even with the huge amount of power Yamato they take quite some time (here the only thing that does help is the memory that allows for more files to be kept in cache).

But even more difficult than implementing the tests is to come up with them. As I said, they are not in Portage for one reason or another: too specific, too taxing, possibly disruptive and so on. Not all of them are my ideas, some are actually suggestions by other developers for particular cases, or by users.

For instance, while I added the tests for /usr/man, /usr/doc and /usr/local directories, the one for the misplaced Perl modules (site dir rather than vendor dir) is something that tove came up with (and I’m filing bugs about that to help him transition site_dir away); and the make “cheat” to call parallel build anyway is something Kevin Pyle came up with.

I came up with the “ELF file in /usr/share” because I had seen Portage stripping some in those path which I knew shouldn’t be there; and from that, I started wondering about the binchecks restriction, so I added the (very slow!) test that ensures that bincheck-restricted packages don’t install ELF files at all (actually it seems like all Linux kernel sources do install some ELF files, I need to track down if it’s a Gentoo problem or if upstream packages them up like that).

The test for bundled libs is very shallow (and leads to false positive on the packages that do provide those libraries of course) but it tries to identify the most common offenders, which is something quite important given that a nasty weakness was found on libtool’s libltdl which is among those most often bundled with software.

The notice on setXid files is something that Robert (rbu) asked me to add so that it would be possible to get a list of setXid executables in Gentoo (just getting them off the livefs of the tinderbox is not possible because you never ever cannot get all packages merged in the same system).

Recently I’ve added one check for libtool .la files so that I can find at least some certainly unhelpful ones (installed with Ruby, Python and Perl extensions: none of those use ltdl to load them so none of those will need the extra file beside the shared object).

If you got any idea for QA tests that you think the tinderbox should be running, you can either mail them to me or leave them as a comment here, just remember that they need to have a fair balance so that I don’t get one out of three to be a false positive, and they need to be efficiently executed over all the packages in the tree.

I decided to do a screencast of how I apply patches to the Linux stable tree to give people an idea of my patch workflow.

The video is here:

HOWTO - apply a Linux kernel patch to the stable tree.

If anyone has any questions about it, let me know. If there is interest in how I do a stable kernel release from these patches, or anything else, let me know.

The new Gentoo packages website is coming along quite nicely, and the old one was taken down (again).  The feedback from the testers so far has been invaluable, and I wanted to publicly thank them for their help.  The craziest part of it is that I've gotten so many good ideas and feature requests, that taking the site live is going to be pushed back a bit while I implement all the new changes.  I had originally hoped to have it online last weekend, but now, I have no idea!  I'm thinking it might take all this week just to get the new stuff in there.

The new design is in place, though, and it looks awesome, in my opinion.  I can't wait to show it off.   Right now, only the testers get to see it -- if you'd like to do some as well, just lemme know.  In the meantime, here's a little preview:

Now who is that little guy?

I've also got a Twitter feed set up now where I'm sending updates about the site progress, if you're interested in following.

I would cover a list of new features again, but this time I think it's embarassingly short since I've been just fixing bugs for the past few days.  I did get really basic RSS feeds added, but that's about it.

Here's some of the planned new features, though:

• display changelog with syntax highlighting
• display ebuild source inline
• show use flags, dependencies, reverse deps on ebuilds
• show open bugs on ebuilds (thanks to Mike for his help on this one)
• RSS feeds: new packages, version bumps
• Compact, verbose views
• Text-friendly design, for CLI browsers (elinks, etc.)

Like I said, no idea how long this stuff is gonna take, but it should make the site much more friendly and usable.  Yee-har.  Lemme know if there's something else you'd like to see, and I'll fit it in if I can, and it's reasonable.  Thanks, guys.

So thanks to Alex and Hans, who handled the review and commit in tree of the new eclasses we finally got them available, and the new Ruby packages added from now on are going to be based off those.

Just so you know that without having to go reading all the older posts, this results in the following good things:

• we can package gems without using the rubygems code in the ebuild; this means that we follow Gentoo procedure for unpacking, preparing, compiling and installing the code;
• we don’t blindly install the contents of gems: no more double-installation of compiled extensions, or object files, or tests, or any other shit that the gem has been picking up during the packaging step;
• we don’t install a “cache” copy of the old gem either;
• we can run test during the test phase of the ebuild, to make sure that the code we’re going to install is working to a degree;
• we can fully support installation for multiple Ruby implementations, including user choice of implementations and full dependency tree support for them;
• this means that we’ll soon be able to properly support JRuby as a first-class citizen in Gentoo (I need to talk to the Java guys since I need a couple of changes to the JRuby ebuild for that).

Unfortunately the porting is far from simple for a long list of reasons; there are gems that don’t package tests, others that don’t package in the gem enough files to regenerate the documentation. There are gems that require new dependencies for the tests, which means that we’re dropping keywords one after the other and that’s going to be bothersome for the arch teams. There are gems that fail their own tests by default (and that’s not just with Ruby 1.9 or JRuby that can be considered still “niche” implementations).

But probably the worst issue is with the cyclic dependencies, for instance between json and rubyforge, or with the cucumber dependencies. In those cases, when you do want to run tests, you need first to install every dependency without tests, and then you should be able to try them out. And that means spending quite a bit of time for them to work.

So please don’t blame us for not having completed the transition already; rather try to support us during this timeframe!

I just managed to reboot one of the Xen servers I still admin, just by creating another domain:-/

Running with old versions of xen-sources results in problems as seen above and with newer udev versions. For reference to the Gentoo Xen users out there I'm posting this.

If you see errors like:

* Mounting proc at /proc ... [ ok ]
* Mounting sysfs at /sys ... [ ok ]
* Your kernel is too old to work with this version of udev.
* Current udev only supports Linux kernel 2.6.25 and newer.
* Could not create /dev/pts!
* Checking root filesystem ...Failed to open the device '/dev/sda1': No such file or directory



* Filesystem couldn't be fixed :(
[ !! ]
Give root password for maintenance
(or type Control-D to continue):


You've probably upgraded to a version of udev that actively refuses to boot with your old Xen kernel. Normally my workaround is to mask all udev versions greater than 141 (the fix being a migration to a supported supported virtualization technology).

Also make sure that you have the old version of /etc/init.d/udev-mount, otherwise your system will refuse to boot. Perhaps it's possible to just hack around this limitation in the udev-mount init script but I haven't really bothered to check. There might be a better official fix that I haven't found yet though....

Since Koon stopped maintaining GNAP I've been building updated tarballs for personal use a couple of times each year.

One thing that has continously bugged me is that everything works out alright with Catalyst 2.0.1 and manual chroots but using later versions (at least 2.0.3_pre3 and 2.0.6) it fails to properly detect compiler settings. Ie. building busybox bails out with:


/var/tmp/portage/sys-apps/busybox-1.14.2/work/busybox-1.14.2/scripts/gcc-version.sh: line 11: i386-pc-linux-gnu-gcc: command not found


Obviously it should look after i386-gentoo-linux-uclibc-gcc but somehow the build scripts messes up the settings.

Enabling ccache just causes things to break sooner, ncurses then bails out with:

checking for i386-pc-linux-gnu-gcc... i386-pc-linux-gnu-gcc
checking for C compiler default output... configure: error: C compiler cannot create executables


Without Catalyst it seems like the problem is a broken binutils installation, but both with Catalyst 2.0.1 and with a manual chroot everything is working fine. This only happens when I update Catalyst, so it seems like either recent Catalyst is broken or more likely somehow my stage3 tarball is broken:/

In portage-2.1.7.14 and 2.2_rc59 there is support for EAPI 3_pre2, which adds support for installation prefix variables (ED, EPREFIX, and EROOT) and support for unpack of *.xz compressed files. Bug 296700 tracks EAPI 3 support in portage, and bug 273620 is for the EAPI 4 stuff that used to be in EAPI 3 but got delayed.

Four days ago, Mozilla Messaging made an announcement about the release of Thunderbird 3.0. This release has been a very long time in the making, and brings with it a very impressive list of features. Thanks to the work of Jory A. Pratt (anarchy), we Gentoo users have a quality ebuild for mail-client/mozilla-thunderbird-3.0 in the tree (committed the same day as the release itself)! It is, for obvious reasons, only available in the testing (~arch) repositories at this time, but if you would like to try some bright and shiny new software, I urge you to add it to your /etc/portage/package.keywords file. If you were already using Thunderbird 2.x, then I believe the only additional package that will require keywording is >=x11-plugins/enigmail-1.0.

After I have used this new release for some time, I will report back on my experiences. I hope that some of you Thunderbird users will do the same, and file bugs if necessary.

|:| Zach |:|

So, the word on the street is I'm jobless ... and that's true.  I got unexpectedly laid off last Friday along with a bunch of other people at work.  In looking for work now (systems admin and/or web development, here's my resume), I decided the best place to start was to get my portfolio back online so I can actually show companies that I'm capable of doing.  What that means is, the packages website!  Whee!

I have been working on this thing almost non-stop all week, because this site is by far the most complex one I have going for me.  Well, that's a personal project, at least.  I forgot how much work goes into this thing, as I've still got small laundry list of to do items.  But!  The good news is it should be ready and online really, really soon now.  Hopefully this weekend if I can squeeze more blood out of me.

I got to see the new design this morning, and I gotta say, I am absolutely floored by how amazing it is.  My brother-in-law was kind enough to do an original design for the rewrite, and I gotta say ... it's just spanky.  I love it.   He also redid the design for Planet Larry if you want an idea of his skill level.  Thanks, David!

Anyway, I'm not gonna open up the site just yet, but I do wanna start getting a list compiled of people who are interested in doing some beta testing for me.  Just send me an email if you'd like to help out.  It's not really a big deal if you wanna do it -- I just need you to poke around, use it like you normally would, but (and this is important) actually send me feedback about any bugs you find or suggestions you have.  Lemme know.

There was alot of of talk/flames on the LKML about devtmpfs. Looks like a big push for this was for embedded devices, android, etc. Since I read that it may give a boot time speed up, I was slightly intrigued. http://lkml.org/lkml/2009/4/30/182, yes...it is an old topic but it finally was released in stable .32 kernel.

So, bootcharts:
bootchart-2.6.31.6.png 39 seconds
bootchart-2.6.32-no-devtmpfs.png 37 seconds
bootchart-2.6.32-devtmpfs.png 37 seconds
bootchart-2.6.32-openrc.png 26 seconds (devtmpfs)

So, where is the real win here? Well, as I wrote before, use openrc.

I just had an old Gentoo install to upgrade and quickly realized that it was easier said than done. There is no supported upgrade path for very old Portage versions.

I quickly found darkside's blog post Gentoo: Tips to upgrade your really old installation.

My install was x86 so I had to modify it a bit, and without thinking I had upgraded to bash-4, which needs a recent glibc, so this pretty much hosed the complete system.

Though a quich chroot allowed me to pull glibc from tinderbox and luckily it worked. After that I rebuild the complete system. The following is more or less the COMPLETELY UNSUPPORTED procedure I used:


#!/bin/bash

ARCH="x86"
PYTHONVER="2.6.2-r1"
BASHVER="4.0_p28"
PORTAGEVER="2.1.6.13"
GLIBCVER="2.9_p20081201-r2"

wget http://tinderbox.dev.gentoo.org/default-linux/${ARCH}/dev-lang/python-${PYTHONVER}.tbz2
wget http://tinderbox.dev.gentoo.org/default-linux/${ARCH}/app-shells/bash-${BASHVER}.tbz2
wget http://tinderbox.dev.gentoo.org/default-linux/${ARCH}/sys-apps/portage-${PORTAGEVER}.tbz2
wget http://tinderbox.dev.gentoo.org/default-linux/${ARCH}/sys-libs/glibc-${GLIBCVER}.tbz2

cd /
tar xfpj root/python-${PYTHONVER}.tbz2
tar xfpj root/glibc-${GLIBCVER}.tbz2
tar xfpj root/bash-${BASHVER}.tbz2
tar xfpj root/portage-${PORTAGEVER}.tbz2

emerge -va portage --nodeps
emerge -Cva man-pages
rm /etc/locales.build
emerge -va e2fsprogs
emerge -Cva mktemp && emerge -va sys-apps/coreutils
. /etc/profile
emerge -eva system
XZ_OPT="--memory=128M" emerge -eva world


Had to use the XZ_OPT hack since my system had only 128mb of RAM.

After rebuilding the complete system I haven't found any problems with it yet...

As you've probably already heard from one of your favourite sites (slashdot, phoronix, ...), Google has just released the first beta-quality version of Google Chrome for Linux. I figured this was as good a time as another to collect and answers a few questions frequently asked on it, or rather on chromium which is the open-source version available in portage

• What's the difference between Google Chrome and Chromium? Well, chromium web site has a nice page summing it up here. So emerging chromium will get you a browser very close to Google Chrome, except the log and a few Google specific report links (the sandbox is enabled in gentoo chromium)
• Why does it depend on ffmpeg (and a recent version of it)? For HTML5 audio/video tags support. There is now a USE-flag to disable this dependency if you are on a stable system and do not need this
• Where do the source tarballs come from? Are they official ones? I create them manually, based on the SVN dependencies listed for each revision here. And it does take some time (checking out their huge tree, trying to get rid of as much bundled sourcecode as possible, ...) For now, I track the developer releases, but may switch to beta releases some time. Especially now that upstream is finally considering making source tarballs available Bug report is here. There is also another bugreport interested people can track, number 28287, which lists all bugs that would make our life easier, "our" as in distrib packagers, read this recent rant by the Fedora packager for chromium. Also interesting to read is Evan's answer, digging into what is exactly there in the 3rd party folder.
• I want to debug/run gdb on it: again the chromium wiki has a nice page on it. The usual recommendations apply of course
• Will google-chrome-bin get in the tree? This is bug #272805. Right now we have chromium-bin, installed from snapshots generated by chromium test farms, with SVN revisions close to the from-source packages. Right now I don't see a lot of benefits between chromium-bin and official google-chrome (except a shiny logo?), but if that changes I'll probably add it to tree (in addition to/replacing chromium-bin). Or if another dev decides to add it
  

So that's it for the first round of questions, add yours in comments if it's still unanswered

About a month ago, I installed Gentoo on the new-to-me Acer Aspire1. Installation went like anything else, it is just a normal x86 host after all. I don't have everything on it working, because I don't care. If you are looking for additional resources on getting the extras working, you may want to look here or here.

The exciting part, that I got working and am ready to announce publicly, is my new atom-x86 binpkg repo. What makes this repo different than the binpkgs located on tinderbox.dev.gentoo.org/default-linux is that this repo has CFLAGS specific to the Intel Atom processor. I identified the compiler flags by using the following gcc command: gcc -Q --help=target -march=native and set the following -march=prescott -mtune=generic -msahf. On my linode (review) host, I have a chroot that builds all new packages in my world file once a day which comes from the aspire1. In this manor, I am able to always have binary packages available to me whenever I update my aspire1. Now, I have all the benefits of a source distro and the speed of a binary distro.

If you would like to use this repo, set PORTAGE_BINHOST in /etc/make.conf and add 'getbinpkg' to FEATURES (or use the emerge options directly). Be advised, that thought this works for me, I make no guarantees for you.

PORTAGE_BINHOST="http://tinderbox.jolexa.net/atom-x86/"
FEATURES="${FEATURES} getbinpkg"

I also have an html view of the packages available.

Here's a quick rundown on what's going on in alpha land (i.e. what's currently broken):

First of all, starting with version 147, sys-fs/udev uses a syscall from inotify (inotify_init1) which isn't implemented on alpha. For now, everything past version 146 (i.e. 147, 148, 149) is hardmasked because it would result in a system without any devices (including network, very annoying!). If any of you is keen on implementing the missing syscall for alpha, you'd have my gratitude (payable in a cold beverage of your choice). I'll try my hand at it, but it's not my strong suit and I have a myriad of other things on my alpha plate.

Martin Schmidt has recently acquired a HP DS15 which is one of the fastest alpha workstations ever produced. Naturally, he's trying to install Gentoo Linux on it. Unfortunately, the system type (Titan) needs a kernel option (LEGACY_START_ADDRESS) unset which in turn results in a non-compiling kernel. The root cause is a change of 64-bit data types that happened a while ago and wasn't carried out completely. Matt has hacked up a quick patch which Martin will try out. Naturally, help is appreciated here, too.

So recently I’ve gotten back into the game on rewriting my application GPytage so it’s a bit easier to work with. For those of you who don’t know what GPytage is, it’s a GTK application for managing Portage’s config files traditionally located in

written with PyGTK. The application is coming along nicely with its new backend, but still has a bit of a way to go before a rc is released. I’d say the current svn trunk is about beta status at the moment, it’s safe to use but all the features just aren’t implemented yet. Basic editing works right now as does saving and creating new files. It also supports infinitely recursive folders and files which the older version did not.

A quick list of the top of my head that I’ve still got to implement:

• Deleting files
• Renaming files
• Copy, Paste, Cut, etc
• Possibly drag and drop support
• Figures out sane keybindings for adding and deleting a row. I was thinking ctrl+e for inserting a new row and ctrl+d for deleting a row but I really have no idea, recommendations are welcome
• Converting a configuration file into the directory layout like the older GPytage did

That’s all I can think of off the top of my head. The svn trunk should be good for testing right now, I promise not to horribly break it. It would be appreciated if people would checkout the current trunk and give it a whirl and comment about how you liked, disliked, hated, loved, or would change about GPytage.

For testing purposes after checking out the svn trunk just cd into the scripts directory and run

. Then you should see the application in all its glory. If you feel uneasy about letting GPytage have actual access to your portage files, simply create a /etc/testportage directory that is identical to the old one such as

. This way GPytage can’t cause any harm. If you use the /etc/testportage directory, you would launch GPytage with

.

Feel free to drop by and say hi in #gpytage on the Freenode irc network.

trunk r230

I’ve been using firefox for too long.

Its excellent vimperator extension has prevented me from switching to anything else, but it is beginning to show its age. Slow loading times, occasional crashes, horrible JS performance…

Meet uzbl. Wordplay for usable. Its developers describe it as web interface tools which adhere to the unix philosophy. I like to think of it as a terminal for the web.

I have valid reasons: Instead of using tabs, I just spawn uzbl windows whenever I need something, then close them. Same as a terminal. That is possible because it loads instantly – like a terminal! Add the fully customizable vim-like bindings and very good webkit engine and you have a winner!

The fact that I’m using awesome (a tiling wm) also helps, since it manages all the windows for me.

Since I like uzbl so much, I added it to the portage tree:

[I] www-client/uzbl
Available versions: (~)0_pre20091130{tbz2} **9999{tbz2} {helpers}
Installed versions: 0_pre20091130{tbz2}(04:03:14 PM 12/04/2009)(helpers)
Homepage: http://www.uzbl.org
Description: A keyboard controlled (modal vim-like bindings, or with modifierkeys) browser based on Webkit

One tagged release and a live ebuild (that uses either the master or experimental branch).

I’ve also patched dmenu with the vertical patch to make it useful with uzbl. You can find the updated ebuild in wirelay (layman -a wirelay) – at least until I get the dmenu maintainers to add the patch in portage.

What’s in for you with Layman 1.2.4:

• Major bugfix affecting CVS-based overlays
• Support for repositories.xml (successer to layman-global.txt)

The only visual indication of the arrival of repositories.xml support for now is that contacts now show names where available:

layman 1.2.3

* Contact : scaranospambeus@gentoo.org

layman 1.2.4

* Contact : Tomas Chvatal <scaranospambeus@gentoo.org>

More goodies will come.

How to upgrade:

1. Unmask =app-portage/layman-1.2.4 if you’re on stable
2. sudo emerge -av =app-portage/layman-1.2.4
3. sudo etc-update  # To migrate /etc/layman/layman.cfg, very important

Btw report bugs please!

How we got here:

I bet a new Layman release isn’t really what you expected for today. A quick summary would be:

1. I requested SourceForge project admin access from Gunnar and happily received it,
2. applied my repositories.xml patch done earlier,
3. updated change logs,
4. fixed an unexpected last-minute showstopper (Layman hasn’t been handling CDATA sections before),
5. uploaded a tarball, and
6. and bumped the ebuild.

Help me with Layman!

If you know a little Python you are welcome to support Layman development!  These days my time is rather limited and there is a lot to do:

• Fixing Layman bugs
• Migrating from minidom to ElementTree
• Extending support for repositories.xml features like:
  • Multiple repository URLs
  • Overlay stability indicators
  • your favourite here

Sounds like fun? What are you waiting for?!

I got pinged yesterday on IRC (I hang out on Freenode far too often) about putting together a roadmap for what's left to getting the new Gentoo packages website live .... so here it is.

This is an incomplete list, and I've just started jotting it down yesterday afternoon as I started working on the site some more.  Also, it's a brain dump, so excuse the randomness.

Roadmap:

• package masks
• website; new design
• load testing
• bash script w/import options
• expanded versions
• options to use find all ebuilds updated recently
• status column for updates to happen in background
• db classes to access properties

I'll explain quickly what some of those mean.

Finding out whether a package is masked or not is a real pain in the butt.  The reason is you have so many ways a package can be masked.  I'm not gonna go into the coding required to checking it.  It's possible, and it's nice when it's done, but it's painful to write out.

New website -- yes, I'm rewriting it from scratch.  Well, the backend.  The functionality is going to be there 100%, so nothing is going to be lost.  If anything, there's gonna be a lot more stuff.  I'm also hoping to get a new design done before launching it.  Also, I'm probably going to do a closed testing invite session before launching it, so I can get some serious feedback first.

Okay, the status column thingie -- that's gonna eliminate one really annoying feature of the last website.  It would shut down for about 5 minutes while the site was updating, because it would delete stuff and add stuff all over the place.  The new one is just going to insert all the new stuff in the background, but won't flip it on to be actually visible until the import is completed.  So, it'll be completely transparent to the user, and the site will always have populated data, and any updates will just show up all of a sudden.

Now, some of the feature requests:

• RSS feeds
• XML API
• import all metadata
• parse changelogs
• profile masks
• tags
• track deleted ebuilds, packages
• screenshots
• user ratings
• twitter feed
• GLSA integration

A quick disclaimer -- no idea if and/or when any of those are going to be done, because they are all unnecessary to the actual launch of the site itself, which is what I'm working on now.  Another quick recap on what I'm planning, though.

The RSS feeds are going to be much better this time, and I'll have a larger selection: new ebuilds, recently updated ebuilds, per-arch feeds, etc.  And they'll have all the same info on the website too.

The XML API, which I've mentioned before, isn't really going to be that fancy to start with.  You'll just be able to do something like browse to website/app-admin/foobar/xml and it will have an XML printout of all the data that I have on that package.  Same for category pages, too.  Nothing fancy to start with.  Oh yes, I'll also produce database dumps as usual.

I need to import all metadata too to get GPNL back on its feet.  I already *have* it all in the database, but just as the raw original strings.  I need to sort through it and get it into its individual tables.  Again, I'm just doing the bare minimum right now to get the site up and running.

Parsing the changelogs, ugh.  That's a new feature I tried adding in the old website, and it never quite worked out exactly how I planned.  I'll get that one in eventually.

Profile support is one feature I'm really excited about, and one I wanted to keep a lid on for as long as possible.  Oh well.  Now you know.   Basically, I'm going to add support to the site to browse the keyword statuses for a specific profile instead of just the default one.  Once you change your profile, it'll affect package masks ... and, that's about it for now.  Still I think it'd be a handy feature.

Tags, screenshots, user ratings -- just some features that I'll eventually add to make the site actually accept user input.  That's gonna be a long way off because of all the work involved in user accounts and preferences and uploads.

Tracking deleted ebuilds -- I'm still debating whether I want to do this one or not.  I mean, I'll track them in the database, but it could be inaccurate for a number of reasons.  Not sure if I'm going to have a display for it on the website or not.  Would be kinda nice, though.

GLSA integration will hopefully be easy enough, I haven't looked at it at all.   Just track what GLSA notices there have been for a certain package and display them when you view it.  Nothing really fancy.

Alright, so that's about it.  I know I've gotten some feature requests from people, and if you don't see it listed here, then I've forgotten about it.  Please do me a favor and ping me on IRC or email and let me know, and I'll get it added to the list.

I still don't have a timeline to get the old site back up and running.  The good news is it is using a lot less CPU than I thought it'd be, so that expands my options for hosting.  The coding for the original roadmap is coming along at a clipped pace.  Everything I need to do has either already been done and just needs to be rewritten for the new backend, or is possible without too much problem.  In other words, there are no major roadblocks.  I still see it taking a few weeks, though.

I'll keep you posted.

In the mail today, I got the Efika MX Open Client. My first impressions are pretty good. No noise and no moving parts, it should last for a long time. It comes with Ubuntu 9.10 minimal on it out of the box.

That HDMI output makes it the best text console I have ever seen on my 40" 1080p LCD TV! Seriously though, on my TODO:

• Analyze the possibilities for a HTPC. This will be just something fun to do.
• Gentoo Prefix on ARM. This will be the first time, that we know of, that it has been attempted. It shouldn't be that hard because Gentoo already has ARM support which means that most apps already work.
• Install Gentoo Linux on it and help armin76 document the installation process.
• Assisting the Gentoo ARM team with providing binary packages and weekly stages for Gentoo Linux users.
• And more...

Size comparision of Efika MX vs Aspire1

Back of the Efika MX. Power, HDMI, Ethernet, headphone, mic

Front of Efika MX. USB, USB, SD Card Slot

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

Gilles had me promise to write a follow up to a post of his, and since I don't want him to call me a liar, here goes.

The Gnome Team (of which I'm officially a member, but I guess it's mostly honorary these days) is looking for fresh blood. Between our day jobs, the growing size of Gnome and slacking recruits (/me waves at Arun, Nirbheek and Romain I'm just kidding, you guys rock!), we're having a hell of a time making proper releases. You may not realize, but a full Gnome release is something like 60+ packages to bump, build and test.

So if you're a Gnome user, here's how you can help us.

First of all, the Gnome overlay. That's where upstream's odd-numbered releases go before we put them in portage. As of today, that's Gnome 2.29. If you want to start helping, then grab the overlay with layman and start testing. Update the overlay every day and report bugs. First to us on IRC, then upstream if needs be.

Second way to help us, the Gnome overlay. Yeah, like #1. Except this time, you can pitch in by doing bumps as they come in. The best way to check new releases is Gnome's ftp mailing list. You can do bumps locally and then push your changes to github or send us git-formatted patches.

Of course, come talk to us so that we can better explain how our ebuilds are supposed to work and how we do commits. Aside from me, no one has swine flu so the chances of getting sick are close to none.

Like most projects, if we like your work, we'll gladly grant you commit privs to the overlay. That's how Gilles and I first started.

Third way to help, bugzilla. That one's easy. Pick a bug, help us close it. It doesn't necessarily have to involve coding. A message telling us that you can still reproduce this bug several months after it was reported is good, forwarding bugs upstream is good, sending us a patch is good, closing a bug as a dupe of another bug is good, any help is good.

The big problem we (Gnome team) have with bugzilla is that we just have too many bugs and we just can't keep up.

So any help with the "easy" bugs means the other Gnomers can spend time on the harder bugs.

If you want to help or if you have any questions, come see us on #gentoo-desktop on FreeNode.

Cheers

Today we renamed kde-testing back to kde in layman. You should remove and add the overlay again:

layman -d kde-testing; layman -L; layman -a kde;

In other news,

Qt 4.6.0 final was released by Nokia yesterday. You’ll find ebuilds in portage’s ~testing. If you’re using stable and want to try it out, make sure you keyword ALL the ebuilds, or you might get ugly blocks A keyword file is available in qting-edge.

Upgrading world is the recommended way to go to avoid B blocks. If you don’t want to upgrade world, make sure your upgrade command includes all installed Qt modules or you will get blocks.

emerge -av1 $(qlist -IC x11-libs/qt\-)

Remember that “b” (lowercase b) blocks are automatically resolved by portage, just remove --pretend and proceed with the upgrade.

For those wondering, KDE 4 works fine with Qt 4.6

If you’re upgrading Qt from a previous version and your Qt apps misbehave, you should rebuild everything depending on Qt:

emerge -av1 $(for i in $(qlist -IC x11-libs/qt-); do equery -q d $i | grep -v 'x11-libs/qt-' | sed "s/^/=/"; done)

KDE 4.3.4 was also released yesterday, ebuilds are available in portage as usual

Lots of stuff to build, have fun!