Denis Dupeyron

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 http://www.tagaini.net/.

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.

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…

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.

It’s Council election time again. So don’t forget to vote before Sunday at the latest, after church or pastis depending on your religion.

To my great surprise I was nominated again this year. To my even greater surprise I was encouraged by another developer, whose opinion matters to me a lot, to accept my nomination.

I was so not expecting to be nominated that the surprise made me consider accepting for a while. Those who know about my personal situation know how foolish that would be. It kept me thinking until the deadline though, which is why I didn’t formally decline on time. I consider this impolite so please accept this apology.

And since nobody is asking for my opinion here it is. What is important is that you vote, whoever you vote for. But it’s better if you vote right, and this year it’s quite easy.

Whoever is running but can’t be bothered to plan and write a manifesto doesn’t deserve your vote. That leaves 6 candidates.

Whoever doesn’t write a serious manifesto (by serious I mean “not a joke”, I’m not even discussing the actual contents) doesn’t deserve to be taken seriously. That leaves 4 candidates. Please note here that we only have 4 genuinely interested candidates for 7 seats.

Whoever has a technical idea is a good candidate to lead a project but not to the Council. Whoever wants to push a GLEP is a good candidate to become that GLEP’s champion (see workflow) and doesn’t need an election. Claiming “I want a pink pony!” (e.g. git) doesn’t count as an idea. That leaves 2 proposals on the table, and one of them is rather weak.

The good news is that the other one is a lot more than just not weak. Donnie, because that’s who we are talking about, shows he has a rather clear vision of how to go forward. I’m not going to say that it’s the only way forward and that I agree with everything in his manifesto, although I do agree with most of it, and I will let you form your own opinion. As with every council platform it is quite ambitious but it lists practical ideas that do set a direction. When there’s a pile of shit in front of you a long drawn-out plan is not necessary. What is needed is simply to roll-up your sleeves, quit talking and get working on a few simple but efficient actions to get the ball rolling. And Donnie is the man for that.

Sadly, he is the only one I can see.

Here is an excerpt from an email I have sent to a friend some time ago. Who he is (obviously a Gentoo developer) and what the context was is of no importance. I thought some of you may find it inspirational.

[…] What I did that day wasn’t and still isn’t in any rulebook. It might even have been considered by some as interventionism, and I’m sure some complained about it in my back. But it had to be done and was done in a nice and jolly manner. We all cheered, drank and laughed.

My point is the following. Stop hiding behind rules and processes. Whatever it is, do it for the hell of it, because it has to be done and is what is good for Gentoo. Do it because it’s fun. Do it because you’ll end up helping people and pleasing them. But do it, don’t hide like you were hiding that day […]

It’s not a secret that not all developers systematically update Changelogs when committing to the tree. Sometimes it’s because they’re lazy. Sometimes it’s because they think what they’re committing isn’t worth adding more cruft to the Changelog. Sometimes even they might be right.

Less than two weeks ago the Council members have voted that committing to Changelogs would be mandatory. No exception. The good news is that the QA police is already at work and has filed at least one bug against a developer with threats for more. They have also asked for and obtained one suspension. These guys are obviously rogue developers who defy authority and need to be dealt with utmost severity. Possible sentences include suspension, forced retirement and ban from a specific project for multiple years. Not everybody has been taken care of yet but it will eventually happen, and sooner rather than later, because we know who they are.

All is well that ends well and we can all go to bed with the satisfaction of a job well done.

Except that we are talking about heavy committers, with more commits than most of us, and in one particular instance more commits then anybody else, ever. These guys say they will commit to Changelogs but in some cases they believe it doesn’t make sense. They are not listened too however. I find that interesting because they’re the ones who made Gentoo what it is. You can’t say the same about the council (not this one in particular but councils in general which includes this one). If anything we should simply follow their lead, do what they do, thank them and then shut up. They’re not problematic developers, I’ve unfortunately had to deal with my fair share of these and know how they are. No, those are people who know what they are doing and are proving it thousands of times a month. The only issue with them is that they spend more time working than arguing. Some of them have however been on the Council at some point or another. And we’re saying that their opinion doesn’t matter?

Except also that Gentoo is a community of volunteer developers who donate their time to a project. To some of them it’s even a cause. Is this how such a community should be treated? Apparently yes, Gentoo is now do or die. I can see the fun running away at the speed of light.

All that because faced with its inability to encourage a behavior in a positive way, the Council opted for the easy solution which consists in pulling out the big guns and shooting all around. It’s surprising to see this from a group of Council members that you would otherwise call tame to be polite. I tried explaining to some of them that they had made a wrong turn somewhere and that it wasn’t too late but they won’t admit it. Although one has admitted that this couldn’t end well. I guess it’s been a long year for them. They’ll soon get an opportunity to get a well deserved vacation if they so desire.

There’s more to this story with a Queen of Drama, her unstable temper, her rise to power and her faithful servants. But this one is far from finished yet so I’ll keep watching.

Now please forgive me because I have to go. My popcorn is ready.

Sebastian (sping) recently posted about Bumpday. This gave me an idea for a little experiment.

As part of the bumpday contest, you can claim any bump assigned to me (Calchan) or to the Soldering Iron Brotherhood (sci-electronics) as yours. What you should do is, after you have properly tested and committed the ebuild, assign the bug to yourself and mark it RESOLVED/FIXED. Make sure you cvs up in the package directory before you commit in case some other dev was faster than you.

You may also file a bug when you spot a package which needs a bump and doesn’t have a bug for it yet. In this case you can assign it directly to you (please add me to the CC list) and RESOLVE/FIX it.

All I’m asking is you really test what you commit, especially in the case of electronics stuff which is sometimes not trivial (you didn’t think it would be that easy, right?). You should also fix all known bugs which would still apply to the version you’re committing.

There are a few easy targets out there, so don’t waste any time. And if you’re good at greping metadata in the tree there are even more of them.

How’s that for non-territoriality?

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

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

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

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

I’m going to go ahead and assume you have all read the summary of the last council meeting. It can be summarized even further.

[list]
[*]We decided the #gentoo-council channel would be moderated during meetings. Developers and users have plenty of opportunities to tell us what their opinion is prior to and during the meetings.

[*]We confirmed Thomas Anderson as the council secretary and clarified that the role of the secretary is limited to posting the logs and summaries of council meetings.

[*]The council decided it wasn’t competent to decide how GLEP 39 should be amended.
[/list]

Some would say that it isn’t much. And I wouldn’t disagree. I wished this council could be someday called the council that slacked less but we’re apparently not taking that direction. Let’s see if we can change that. By the way I encourage everybody, anybody, to post discussion topics to the gentoo-council mailing list and debate there.

What I really wanted to discuss today is amending GLEP 39, and more exactly how to proceed. This GLEP serves in certain ways as our constitution and is more critical than any others. It was written almost 4 years ago and as such relects the situation as it was back then. It has been criticized a lot, many want or wanted to replace it at some point in time, some even went as far as writing replacements for it (count me as one of them), but I have yet to see something that is worth discussing in public.

Now, I’m not going to say that it’s perfect. No text of that kind can be even close to perfect. My point today isn’t about discussing what should be kept in it and what should be changed (don’t worry though, I’ll discuss that soon), but to make sure we agree on the fact that we need a mechanism to modify it. And by extension replace it if we decide so someday. Not that it wasn’t ever amended in the past, it was, but in a way that I can’t imagine satisfies the whole developer community. Don’t extrapolate from what I just wrote that I disagree with the changes or how they happened, quite the contrary actually. But I talk to a lot of you and many tell me they believe that since GLEP 39 was the result of the vote of all developers, any change to it needs to be again voted by all developers. I disagree with that simply because GLEP 39 itself has provisions that would imply the contrary. However, all opinions need to be taken into account, especially when the same one comes back often.

So, what happened during that last council meeting? One of the questions was whether the council could decide on a process to amend GLEP 39. The vote ended up saying no. The next item on the agenda was then to organize a vote of the whole developer community to decide, since the council declared itself incompetent. Strangely enough this item was skipped. How can that be interpreted? Frankly, I’m not sure.

Someone argued that there was no point bothering with how to amend GLEP 39 since we could always organize a quick vote of all developers. I see two issues with that. One is that we had just voted that we couldn’t decide on a process, but arguing that we can always use an all-developer vote is precisely deciding on a process, and it’s inconsistent. The second one is that GLEP 39 was already amended a few times, and each time without an all developer vote. I don’t seem to remember anybody complaining about that. So there must be at least a significant part of the developer population which is happy with not having to vote on changes of GLEP39, and is comfortable with the “vote out the bums” clause.

Most probably what happened is that we were running late with the meeting and the item was skipped because it didn’t seem important to your new council. Yep, you heard me. Your new council doesn’t really care about what you think on amending GLEP 39. If you think your council should care more then let it be known.

Recently one of our developers decided he would raise hell in one of our irc channels. “For the lulz” he said. What ensued was a rather large number of kicks which ended in a ban. I contacted him and tried to talk to him. He wouldn’t agree at first, then stopped answering, and went on in another channel. I spent a good amount of time trying to reason him at around midnight my local time knowing I had an early meeting at the office the day after. He stopped and apologized a few seconds before I hit the button to suspend him.

He didn’t have any really bad intentions but he still created a shitstorm. In his mind everybody overreacted but there was one thing that he didn’t understand. Him behaving like this made a few people unhappy. Whether they were right or wrong to be unhappy, they were, and they showed it. In return they started filling some of your fellow devs’ maiboxes, and irc queries started popping faster than it is humanly possible to answer. In short after a few minutes some of us had their screen blinking like Christmas trees.

So, kids: don’t make an ass of yourselves in public, whether on irc or elsewhere. And if you absolutely have to do so don’t do it in a #gentoo- channel, and preferably not with your gentoo irc cloak. If you don’t do it for yourself do it out of respect for those whose task it is to try and maintain a semblance of peace on irc or on our mailing-lists. And think of all those traces you’re leaving behind for the next time you’ll look for a job. Think also of the image you’re projecting for the whole Gentoo community. You’re a developer, so if you care show yourself and your distro in good light.

And remember that we’re a large project with all kinds of different cultures. Something that may seem totally insignificant and/or funny to you may (and will probably) be seen as abrasive by others. We have to operate on a lowest common denominator. That’s unfortunate but there’s no way around it.

Thanks for your attention.