It is GSoC season again

Google Summer of Code 2016 is starting.

If you are a student please be patient. Your time will come soon, at which point we’ll be able to answer all your questions. In this initial phase the audience is project mentors. Note that you do not need to be a Gentoo developer to be a mentor.

While we are finalizing the application, we need all of you to submit your project ideas before the end of next week (February 19th). To do so you should go to this year’s idea page and follow the instructions in the “Ideas” section. If you proposed an idea last year and would like to propose it again for this year, you can look it up and add it. Or you can just tell us and we will do it for you. Don’t hesitate to add an idea even it isn’t totally fleshed out; we will help you fill in the blanks. A project represents 3 months of full-time work for a student. A good rule of thumb is that it should take you between 2 and 4 weeks to complete depending on how expert you are in the field. You can also have a look at last year’s idea page for examples.

If you would like to be a mentor for this year please tell us sooner rather than later. You can be a mentor following up with students while they’re working on their project, or you can be an expert-mentor in a specific field who will be called in to advise on an as-needed basis (or maybe never). We will also need people to help us review project proposals. In case you can help in any capacity don’t hesitate to contact us. GSoC is seriously fun!

If you want to reach us or have any questions about any of the above, the easiest way is to ping Calchan or rafaelmartins in the #gentoo-soc channel on Freenode.


I don’t know about you but I’m going to SCALE 14x.

I'm going to SCALE 14x!

SCALE is always a lot of fun and last year I particularly liked their new embedded track. This year’s schedule looks equally exciting. Among the speakers you may recognize former Gentoo developers as well as a few OSS celebrities.

We’ll have a booth again this year. Feel free to come talk to us or help us on the booth. One of the new things this year is we’re getting a Gentoo specific promotional code for a 50% rebate on full-access passes for the entire event. The code is GNTOO. It’s not only for Gentoo developers, but also for all Gentoo users, potential users, new-year-resolution future users, friends, etc… Use it! Spread it! I’m looking forward to see you all there.

The Answer to the Ultimate Question of QEMU chroots, argument pages, and binutils

is 46.

In a previous post I described how to patch QEMU to allow building binutils in a cross chroot. In there I increased the maximal number of argument pages to 64 because I was just after a quick fix. Today I finally bisected that, and the result is you need at least 46 for MAX_ARG_PAGES in order for binutils to build.

In bug 533882 it is discussed that LibreOffice requires an even larger number of pages. It is possible other packages also require such a large limit. Note that it may not be a good idea to increase the MAX_ARG_PAGES limit to an absurdly high number and leave it at that. A large amount of memory will be allocated in the target’s memory space and that may be a problem.

Hopefully QEMU switches to a dynamic limit someday like the kernel. In the meantime, my upcoming crossroot tool will offer a way to more easily deal with that.

Why we do not have nor want R packages in the tree

Here’s a bug and my response to it which both deserve a little bit more visibility than being buried under some random bug number. I’m actually surprised nobody complained about that before.

GNU R supports to run
> install.packages(‘ggplot2’)
in the R console as user. The library ggplot2 will then be installed in users home. Most distros like debian and the like provide a package per library.

First, thank you for pointing out that it is possible to install and maintain your own packages in your $HOME. It didn’t use to work, and the reason why it now does is a little further down but I will not spoil it.

Here’s my response:

Please, do not ever add R packages to the tree. There are thousands of them and they are mostly very badly written, to be polite. If you look at other distros you will see that they give an illusion of having some R packages, but almost all of them (if not all) are seriously lagging behind their respective upstream or simply unmaintained. The reason is that it’s a massive amount of very frustrating and pointless work.

Upstream recommends maintaining your packages yourself in your $HOME and we’ll go with that. I have sent patches a couple of years ago to fix the way this works, and now (as you can obviously see) it does work correctly on all distros, not just Gentoo. Also, real scientists usually like to lock down the exact versions of packages they use, which is not possible when they are maintained by a third party.

If you want to live on the edge then feel free to ask Benda Xu (heroxbd) for an access to the R overlay repository. It serves tens of thousands of ebuilds for R packages automatically converted from a number of sources. It mostly works, and helps in preserving a seemingly low but nonetheless functional level of mental sanity of your beloved volunteer developers.

That, or you maintain your own overlay of packages and have it added to layman.

While we are on that subject, I would like to publicly thank André Erdmann for the fantastic work he has done over the past few years. He wrote, and still occasionally updates, the magical software which runs behind the R overlay server. Thank you, André.

/bin/sh: Argument list too long

I tried building binutils-2.25 in a qemu chroot and I got the following error during the build process:

/bin/sh: Argument list too long

Google wasn’t helpful. So I looked at the code for qemu-2.2.0, which is where my static qemu binary comes from. At some point I stumbled on this line in linux-user/qemu.h:

#define MAX_ARG_PAGES 33

I changed that 33 to a 64, rebuilt, replaced the approriate static binary in my chroot, and the error went away.

Google Summer of Code 2015

TL;DR: Gentoo not selected for GSoC 2015 ‘to make way for new orgs”. All is not lost: some Gentoo projects will be available within other organizations.

As you may have already noted, the Gentoo Foundation was not selected as a mentoring organization for GSoC 2015. Many immediately started to speculate why that happened.

Today I had an opportunity to talk (on irc) to Carol Smith, from Google’s Open Source Programs Office. I asked her why we had been rejected, if they had seen any issue with our application to GSoC, and if she had comments about it. Here’s what her answer was:

yeah, i’m sorry that this is going to be disappointing
but this was just us trying to make way for new orgs this year 🙁
i don’t see anything wrong with your ideas page or application, it looks good

Then I asked her the following:

one discussion we had after our rejection is if we should keep focusing on doing GSoC to attract contributors as we’ve been doing, or focus more on having projects actually be implemented, and how much you cared about it

To which she replied:

well, i’ll say that wasn’t a factor in this rejection
having said that, we in general like to see more new developers instead of the same ones year over year
we’d prefer gsoc was used to attract new members of the community
but like i said, that wasn’t a factor in your case

It’s pretty clear we haven’t done anything wrong, and that they like what we do and the way we do it. Which doesn’t mean we can’t improve, by the way. I know Carol well enough to be sure she was not dodging my questions to politely brush me aside. She says things as they are.

So, what happened then? First, the overall number of accepted organizations went down roughly 30% compared to last year. The immediate thought which comes to mind is “budget cut”. Maybe. But the team who organizes GSoC is largely the same year over year. You can’t indefinitely grow an organization at constant manpower. And last year was big.

Second, and probably the main reason why we were rejected is that this year small and/or newer organizations were favored. This was explicitly said by Carol (and I believe others) multiple times. I’m sure some of you will argue that this isn’t a good idea, but the fact is it’s their program and they run it the way they want. I will certainly not blame them. This does not mean no large organizations were selected, but that tough choices had to be made among them.

In my opinion, Carol’s lack of words to explain why we were not selected meant “not bad but not good enough”. The playing field is improving every year. We surely felt a little too confident and now have to step up our game. I have ideas for next year, these will be discussed in due time.

In the meantime, some Gentoo projects will be available within other organizations. I will not talk about what hasn’t been announced yet, but I can certainly make this one official:
glee: Gentoo-based Linux appliances on Minnowboard
If you’re interested, feel free to contact me directly.

Google Summer of Code 2015

This is a quick informational message about GSoC 2015.

The Gentoo Foundation is in the process of applying to GSoC 2015 as an organization. This is the 10th year we’ll participate to this very successful and exciting program.

Right now, we need you to propose project ideas. You do not need to be a developer to propose an idea. First, open this link in a new tab/window. Change the title My_new_idea in the URL to the actual title, load the page again, fill in all the information and save the article. Then, edit the ideas page and include a link to it. If you need any help with this, or advice regarding the description or your idea, come talk to us in #gentoo-soc on Freenode.


Tagaini Jisho

I haven’t been using Tagaini Jisho for long, but so far I’m impressed. Tagaini Jisho is a kanji dictionary and study tool. Here’s what the author has to say about it:

Tagaini Jisho is a free, open-source Japanese dictionary and kanji lookup tool that is available for Windows, MacOS X and Linux and aims at becoming your Japanese study assistant. It allows you to quickly search for entries and mark those that you wish to study, along with tags and personal notes. It also let you train entries you are studying and follows your progression in remembering them. Finally, it makes it easy to review entries you did not remember by listing them on screen or printing them on a small booklet.

Tagaini Jisho also features complete stroke order animations for more than 6000 kanji.

You can find the author’s website at

I have pushed version 1.0.2 to the tree. Note that there is a version of sqlite which is bundled with the source tarball. I tried to unbundle it but it wasn’t trivial (to me, at least), so I left it there for the time being. If you figure out how to properly unbundle sqlite, feel free to commit the changes yourself. As usual with my packages, don’t waste time asking if you can do it, just do it.

Forking ebuilds

Here’s a response to an email thread I sent recently. This was on a private alias but I’m not exposing the context or quoting anybody, so I’m not leaking anything but my own opinion which has no reason to be secret.

GLEP39 explicitly states that projects can be competing. I don’t see how you can exclude competing ebuilds from that since nothing prevents anybody from starting a project dedicated to maintaining an ebuild.

So, if you want to prevent devs from pushing competing ebuilds to the tree you have to change GLEP 39 first. No arguing or “hey all, hear my opinion” emails on whatever list will be able to change that.

Some are against forking ebuilds and object duplicating effort and lack of manpower. I will bluntly declare those people shortsighted. Territoriality is exactly what prevents us from getting more manpower. I’m interested in improving package X but developer A who maintains it is an ass and won’t yield on anything. At best I’ll just fork it in an overlay (with all the issues that having a package in an overlay entail, i.e. no QA, it’ll die pretty quickly, etc…), at worst I’m moving to Arch, or Exherbo, or else… What have we gained by not duplicating effort? We have gained negative manpower.

As long as forked ebuilds can cohabit peacefully in the tree using say a virtual (note: not talking about the devs here but about the packages) we should see them as progress. Gentoo is about choice. Let consumers, i.e. users and devs depending on the ebuild in various ways, have that choice. They’ll quickly make it known which one is best, at which point the failing ebuild will just die by itself. Let me say it again: Gentoo is about choice.

If it ever happened that devs of forked ebuilds could not cohabit peacefully on our lists or channels, then I would consider that a deliberate intention of not cooperating. As with any deliberate transgression of our rules if I were devrel lead right now I would simply retire all involved developers on the spot without warning. Note the use of the word “deliberate” here. It is important we allow devs to make mistakes, even encourage it. But we are adults. If one of us knowingly chooses to not play by the rules he or she should not be allowed to play. “Do not be an ass” is one of those rules. We’ve been there before with great success and it looks like we are going to have to go there again soon.

There you have it. You can start sending me your hate mail in 3… 2… 1…

Managing R packages

We still don’t have proper integration of CRAN and BIOC in Gentoo. I have proposed a GSoC project to remedy that. Feel free to contact me about it.

In the meantime if you need to install CRAN or BIOC packages you probably use install.packages() in R. This resolves R dependencies and installs all you need automatically. You are on your own about system dependencies though, but this is what CRAN integration in Portage is about. Upstream recommends you su root when installing R packages from within R. This is not always possible and I hope you will agree with me this is not the right thing to do. At best you will make your package manager cry due to collisions. At worst, well, it can be way worse. The recommended way should be for users to manage their R packages in their personal library. If you don’t have one, a personal library will be created for you the first time you use install.packages() or update.packages(). So there is nothing special to do and it mostly works.

One problem arises when a package you are installing depends on a version of a recommended package newer than the one you have. Recommended packages are some of those which are installed by Portage when you emerge R, thus they are owned by root. Non-root users can’t update them in the main library, which they don’t have access to, but they can do so in their personal library. However, there is a bug in R which will let you update recommended packages in your personal library, but only if you didn’t have one when you started the process. If you had one, as it’s most likely the case, the install will just fail. Frustrating.

About four weeks ago I silently added two patches to dev-lang/R-2.14.2 in order to fix this behavior. So far nobody complained. Yesterday I bumped R to 2.15.0 and the patches still apply cleanly. Please test and report back.

I have filed a bug upstream about these patches. Let’s see what they make out of them. The real solution to this problem though, at least as far as Gentoo is concerned, is to have Portage manage your R packages. And I’m sure it will come someday.