It looks like I will make it again to visit FOSDEM this year. This time it won't be meeting of whole phpMyAdmin team, but just few members but I hope to meet other people in person as well. If you have something you would like to discuss with me in person there, it's best time to let me know so that we can schedule it. PS: It looks like it might be good timing for Debian release party as well :-).

Filed under: Debian English Phpmyadmin Suse 0 comments Flattr this!

new year, new RC bugs most of the fixes below are for newly reported bugs in versions that don't affect squeeze. the rest are mainly uploads of packages or patches prepared by others.

• #566072 util-linux: "fsck now failing hard for unavailable filesystems"
  prepare a patch based on adsb's analysis. later fixed in maintainer upload
• #605912 runit: "runit: Upgrade failure lenny -> squeeze"
  sponsor NMU prepared by jonathan nieder
• #606370 libcgi-pm-perl: "CVE-2010-2761 CVE-2010-4410 CVE-2010-4411"
  upload package prepared by ntyni to unstable, testing-proposed-updates, and stable (pkg-perl)
• #607556 src:libconfig-model-itself-perl: "libconfig-model-itself-perl: failed tests"
  manual close, new version works again (pkg-perl)
• #609398 src:libfile-userconfig-perl: "libfile-userconfig-perl: Failing tests if home of building user is not available"
  set HOME to a writable directory in debian/rules (pkg-perl)
• #609402 src:libapache2-reload-perl: "libapache2-reload-perl: mkdir in home of building user"
  upload package prepared by periapt (pkg-perl)
• #609464 src:libfile-homedir-perl: "libfile-homedir-perl: Failing tests in t/02_main.t tests"
  set HOME to a writable directory in debian/rules (pkg-perl)
• #609467 src:libpath-dispatcher-declarative-perl: "libpath-dispatcher-declarative-perl: tests fail"
  upload new upstream release (pkg-perl)
• #609468 src:libtk-pod-perl: "libtk-pod-perl: cannot remove path when cwd is /tmp/tkpod_8LQuQjJc for /tmp/tkpod_8LQuQjJc: at /usr/share/perl/5.10/File/Temp.pm line 902"
  set HOME to a writable directory in debian/rules (pkg-perl)
• #609469 src:dh-make-perl: "dh-make-perl: Tries to mkdir directory in home of building user"
  set HOME to a writable directory in debian/rules. in svn, not yet uploaded (pkg-perl)
• #609472 src:libgraphics-gnuplotif-perl: "libgraphics-gnuplotif-perl: Build hangs"
  set HOME to a writable directory in debian/rules (pkg-perl)

Recent Iceweasel betas allows to replace the menu bar with a Iceweasel button. This is not enabled by default, but right-clicking on the menu bar allows to disable the menu bar, which enables the Iceweasel button.
The button is not exactly very appealing, and takes quite a lot of horizontal space on the tab bar. But with a few lines of CSS, this can fortunately be changed. Edit the chrome/userChrome.css file under your user profile, and add the following lines:

#appmenu-toolbar-button  
  list-style-image: url("chrome://branding/content/icon16.png");
 
#appmenu-toolbar-button > .toolbarbutton-text,
#appmenu-toolbar-button > .toolbarbutton-menu-dropmarker  
  display: none !important;
 

This what Iceweasel looks like, then:

Back in July, our family took a train trip from Kansas to New York for Debconf10. And then in September, we went to Indiana. The only train service from here leaves at about 3AM in both directions. So starting about November, Jacob started asking me, Dad, will you wake me up in the middle of the night to go to the train station TODAY? He didn t seem to get it through his head that we didn t have another trip planned, although we surely would at some point. It just couldn t possibly be, right? So around Christmas, I booked a round trip from here to Galesburg, IL for just Jacob and me. We ll get on the train at 3AM Saturday morning, get to Galesburg about noon, and then head back home at 5PM, getting home again at, well, 3:30AM. Jacob is super excited about this. When the tickets arrived, he didn t yet know about the trip. I thought he d be excited then, but the ticket sleeve had a picture of a toy train that he didn t own, so he was somewhat sad. But starting the next day he was very excited. We wrote Amtrak on the Jan. 15 spot on his pharmacy calendar (a local pharmacy gives them away free each year). He carefully checked off each day as it went past. And he s been getting increasingly excited all week. Tonight he couldn t really think, couldn t really play, couldn t really calm down. He jabbered about how he would sit by the window, how precisely I would wake him up, and his eyes would open up right away and we ll go straight there. He talked about how he will look out the window at the dark night, and was extra excited when I told him he d see snow out the window like one of the Amtrak videos he likes to watch on Youtube. He already placed his order for breakfast in the dining car: French toast with syrup on top. He ran past the computer while I was looking at things to do in Galesburg, and saw I had a map up, and immediately noticed the train tracks. Then he pointed to the station, and said, Dad, that says Galesburg Amtrak . A rather stunned dad replied, Yes indeed it does, Jacob. I guess it was some combination of pre-reading and detective skills, but that surprised me. Anyhow, this is the first trip with just Jacob and me. We re going to have a blast, I m sure. I may, however, wind up going 24 hours without sleep if his adrenaline level is any guide

Having complained about the GPL compliance of the Fusion Garage Joojoo tablet in the past, I'm thrilled to say that I spoke to their new CTO earlier in the week and they now have full source availability here[1]. Previous engineering practices involved editing binary Debian packages rather than rebuilding from the Debian source packages, so there may be a small number of cases where it's awkward to rebuild an identical binary, but I think it's pretty clear at this point that they've done everything practical to make up for past mistakes. I've been assured that all further product development will take license compliance into account from the start, so while things may have taken a little longer than I'd have liked I think everything has worked out for the best. I'd like to say thanks to Fusion Garage and Megan Alpers at McGrath Power for their help in getting all of this resolved.

[1] I've taken a brief look at their new downloadable tarballs. If anyone does find anything missing, let me know and I'll be sure to pass it onto the right people.

Reading Scott's recent announcement on his move to Google was both surprising and a pleasure. Surprising, because it'll take time to stop associating his name to Ubuntu, Canonical, and the nice experiences I had while I worked with them. A pleasure, because his blog post was full of reminiscences of the very early days of a project that ended up being way more successful in just a few years than probably anyone in the Oxford conference could imagine. Scott, best of luck for this new adventure! Scott's write-up includes a sentence that made me remember I had been wanting to write a blog post related to all of this, but was pending Mark Shuttleworth's permission for posting:

Ok, Mark wasn t really a Nigerian 419 scammer, but some people did discard his e-mail as spam! Scott James Remnant

Many know the story of how I ended not being part of the Super-Secret-Debian-Startup Scott mentions. I even wrote about it in a blog post, 3 years ago:

[...] nothing beats the next email which sat for some dramatic 6 months in my messy inbox until I found out in the worst of the possible scenarios. Let's go back to late February, 2004, when I had no job, and I didn't have a clue on what to do with my life.

From: Mark Shuttleworth <mark@hbd.com>
Subject: New project to discuss
To: Jordi Mallach <jordi@debian.org>
Date: Sun, 29 Feb 2004 18:33:51 +0000
[...]
I'm hiring a team of debian developers to work full time on a new
distribution based on Debian. We're making internationalisation a prime
focus, together with Python and regular release management. I've discussed
it with a number of Debian leaders and they're all very positive about it.
[...]

I'm not sure if I totally missed it as it came in, or I skimmed through it and thought WTF?! Dude on crack or I just forgot I need to reply to this email , but I'd swear it was the former. Not long after, no-name-yet.com popped up, the rumours started spreading around Debian channels. Luckily, I got a job at LliureX two months later, where I worked during the following 2 years, but that's another story. I guess it was July or so when Ubuntu was made public, and Mark and his secret team organised a conference (blog entries [1] [2] [3] [4] [5]), just before the Warty release, and I was invited to it, for the same reasons I got that email. During that conference, probably because Mark sent me some email and I applied a filter to get to it, I found the lost email, and felt like digging a hole to hide for a LONG while. I couldn't believe the incredible opportunity I had missed. I went to Mark and said "hey, you're not going to believe this", and he did look quite surprised about someone being such an idiot. I wonder if I should reply to his email today...

When the usual suspects in the secret Spanish Debian Cabal channel read this blog post, they decided Mark deserved a reply, even if it would hit his inbox more than three and a half years late. :) With great care, we crafted an email that would look genuinely stupid in late 2007, but just arrogant and idiotic in 2004, when Ubuntu was just an African word, and the GNU/Linux distribution landscape was quickly evolving at the time, Gentoo Linux had the posh distribution crown, that Debian had held for quite a few years. I even took enough care to forge the X-Operating-System and User-Agent headers so they matched whatever was current in Debian in February 2004, and of course, top-posting seemed most appropriate. So Mark woke up that Monday, fired up his email client, and got... this:

Date: Mon, 1 Mar 2004 09:47:55 +0100
From: Jordi Mallach <jordi@sindominio.net>
To: Mark Shuttleworth <mark@hbd.com>
Subject: Re: New project to discuss
Organization: SinDominio
X-Operating-System: Debian GNU/Linux sid (Linux 2.6.3 i686)
User-Agent: Mutt/1.5.5.1+cvs20040105i
Hi Mark,
Thanks for your email. I nearly deleted this e-mail because for some
reason I thought it was targetted spam.
Your project looks very interesting, almost like a dream come true.
However, I feel a bit uneasy about your proposal. Something just doesn't
fit.
Why would someone start a company to work on /yet another/ Debian
derivative? Have you heard about Progeny's sad story? I think it's a
great example to show that Debian users don't want Debian-based distros,
they want people to work on the "real thing". Besides, I don't think
there's much more place for successful commercial distros, with Red Hat
and SuSE having well-established niches in the US and Europe.
Also, why focus on Debian specifically, Why not, for example, Gentoo,
which has a lot of buzz these days, and looks poised to be the next big
distribution?
To be honest, I think only a few people have the stamina or financial
stability to undertake a project like this, so I'd like to know
a bit more about you, and details on how you plan to sustain the
expenses.
Those are the main issues that worry me about your project. Other than
that, I would be interested in taking part in it, as I'm currently
unemployed and working on something Debian-based would be just too good
to miss.
You can reach me at +34 123 45 67 89, or if you feel like flying people
around Europe, I probably can be in the UK whenever it fits you.
Thanks, and hoping to hear from you again,
Jordi
On Sun, Feb 29, 2004 at 06:33:51PM +0000, Mark Shuttleworth wrote:
> Hi Jordi
>
> We haven't met, but both Jeff Waugh and Martin Michelmayr recommended that
> I get in touch with you in connection with a new project that I'm starting.
>
> I'm hiring a team of debian developers to work full time on a new
> distribution based on Debian. We're making internationalisation a prime
> focus, together with Python and regular release management. I've discussed
> it with a number of Debian leaders and they're all very positive about it.
>
> Would you be available to discuss it by telephone? I'm in the UK, so we
> could probably find a good timezoine easily enough ;-) Let me knof if
> you're keen to discuss it, when and what number to call.
>
> Cheers,
> Mark
>
> --
> Try Debian GNU/Linux. Software freedom for the bold, at www.debian.org
> http://www.markshuttleworth.com/

As you can imagine, his reaction was immediate:

Date: Mon, 22 Oct 2007 11:13:54 +0100
From: Mark Shuttleworth <mark@hbd.com>
To: Jordi Mallach <jordi@sindominio.net>
Subject: Re: New project to discuss
Jordi! I just got this now! Did you recently flush an old mail queue?

With thanks to all the Spanish Cabal members who were involved!

X11R7.6 got released on the 20th of December 2010. There were several status updates about XServer 1.9 in experimental on this blog previously, but here s a more thorough review of this katamari. Terminology: that s how upstream calls a badged annual rollup release. In other words, the server, drivers, client libraries, protocols, fonts, and basic applications are all individually released, and a rollup of all those is released from time to time, with a version for all of those components. The term comes from a series of video games. (Explanations taken from a message by Alan Coopersmith.) Katamaris are released with a consolidated changelog, where all components and versions are listed. There s also a git shortlog available for each component, pointing back to freedesktop s git web interface for each and every commit. I modified the table of versions to get the following table, dropping the X11R7.5 column, and adding a distribution one, so as to mention where each component for X11R7.6 can be found. It boils down mostly to:

• almost all drivers are available in experimental, built against XServer 1.9.
• libraries with heavy changes went to experimental while those with fixes and low-impact changes went to unstable.
• protocols went to unstable, they can t really break anything.
• applications don t matter too much anyway, most of them could be considered like toys. Some went to experimental, others went to unstable.
• fonts were skipped in this table, they are pretty much boring.

So there s the summary:

Type	Component	Version	Distribution
	xserver	1.9.3	experimental
app	bdftopcf	1.0.3	unstable
app	iceauth	1.0.4	experimental
app	luit	1.1.0	experimental
app	mkfontdir	1.0.6	unstable
app	mkfontscale	1.0.8	unstable
app	sessreg	1.0.6	unstable
app	setxkbmap	1.2.0	experimental
app	smproxy	1.0.4	experimental
app	x11perf	1.5.2	experimental
app	xauth	1.0.5	unstable
app	xbacklight	1.1.2	will be dropped
app	xcmsdb	1.0.3	experimental
app	xcursorgen	1.0.4	experimental
app	xdpyinfo	1.2.0	experimental
app	xdriinfo	1.0.4	experimental
app	xev	1.1.0	experimental
app	xgamma	1.0.4	experimental
app	xhost	1.0.4	experimental
app	xinput	1.5.3	unstable
app	xkbcomp	1.2.0	experimental
app	xkbevd	1.1.2	experimental
app	xkbutils	1.0.3	experimental
app	xkill	1.0.3	experimental
app	xlsatoms	1.1.0	unstable
app	xlsclients	1.1.1	experimental
app	xmodmap	1.0.5	experimental
app	xpr	1.0.3	will be dropped
app	xprop	1.2.0	experimental
app	xrandr	1.3.4	experimental
app	xrdb	1.0.7	experimental
app	xrefresh	1.0.4	experimental
app	xset	1.2.1	experimental
app	xsetroot	1.1.0	experimental
app	xvinfo	1.1.1	experimental
app	xwd	1.0.4	experimental
app	xwininfo	1.1.1	experimental
app	xwud	1.0.3	experimental
data	bitmaps	1.1.1	unstable
data	cursors	1.0.3	unstable
doc	xorg-docs	1.6	unstable
doc	xorg-sgml-doctools	1.6	unstable
driver	xf86-input-acecad	1.4.0	experimental
driver	xf86-input-aiptek	1.3.1	experimental
driver	xf86-input-evdev	2.5.0	experimental
driver	xf86-input-joystick	1.5.0	experimental
driver	xf86-input-keyboard	1.5.0	experimental
driver	xf86-input-mouse	1.6.0	experimental
driver	xf86-input-synaptics	1.3.0	experimental
driver	xf86-input-vmmouse	12.6.10	experimental
driver	xf86-input-void	1.3.1	experimental
driver	xf86-video-apm	1.2.3	experimental
driver	xf86-video-ark	0.7.3	experimental
driver	xf86-video-ast	0.91.10	dropped
driver	xf86-video-ati	6.13.2	experimental
driver	xf86-video-chips	1.2.3	experimental
driver	xf86-video-cirrus	1.3.2	experimental
driver	xf86-video-dummy	0.3.4	experimental
driver	xf86-video-fbdev	0.4.2	experimental
driver	xf86-video-geode	2.11.10	todo: needs upload
driver	xf86-video-glide	1.1.0	experimental
driver	xf86-video-glint	1.2.5	experimental
driver	xf86-video-i128	1.3.4	experimental
driver	xf86-video-i740	1.3.2	experimental
driver	xf86-video-intel	2.13.0	experimental
driver	xf86-video-mach64	6.8.2	experimental
driver	xf86-video-mga	1.4.13	experimental
driver	xf86-video-neomagic	1.2.5	experimental
driver	xf86-video-newport	0.2.3	todo: needs upload
driver	xf86-video-nv	2.1.18	will be dropped
driver	xf86-video-r128	6.8.1	experimental
driver	xf86-video-rendition	4.2.4	experimental
driver	xf86-video-s3	0.6.3	experimental
driver	xf86-video-s3virge	1.10.4	experimental
driver	xf86-video-savage	2.3.1	experimental
driver	xf86-video-siliconmotion	1.7.4	experimental
driver	xf86-video-sis	0.10.3	experimental
driver	xf86-video-sisusb	0.9.4	experimental
driver	xf86-video-suncg14	1.1.1	experimental
driver	xf86-video-suncg3	1.1.1	experimental
driver	xf86-video-suncg6	1.1.1	experimental
driver	xf86-video-sunffb	1.2.1	experimental
driver	xf86-video-sunleo	1.2.0	experimental
driver	xf86-video-suntcx	1.1.1	experimental
driver	xf86-video-tdfx	1.4.3	experimental
driver	xf86-video-tga	1.2.1	experimental
driver	xf86-video-trident	1.3.4	experimental
driver	xf86-video-tseng	1.2.4	experimental
driver	xf86-video-v4l	0.2.0	dropped
driver	xf86-video-vesa	2.3.0	experimental
driver	xf86-video-vmware	11.0.3	experimental
driver	xf86-video-voodoo	1.2.4	experimental
driver	xf86-video-wsfb	0.3.0	dropped
driver	xf86-video-xgi	1.6.0	dropped
driver	xf86-video-xgixp	1.8.0	dropped
font	fonts skipped
lib	libAppleWM	1.4.0	not for us
lib	libFS	1.0.3	unstable
lib	libICE	1.0.7	unstable
lib	libSM	1.2.0	unstable
lib	libWindowsWM	1.0.1	not for us
lib	libX11	1.4.0	experimental
lib	libXScrnSaver	1.2.1	unstable
lib	libXau	1.0.6	unstable
lib	libXaw	1.0.8	unstable
lib	libXcomposite	0.4.3	unstable
lib	libXcursor	1.1.11	unstable
lib	libXdamage	1.1.3	unstable
lib	libXdmcp	1.1.0	unstable
lib	libXext	1.2.0	experimental
lib	libXfixes	4.0.5	unstable
lib	libXfont	1.4.3	experimental
lib	libXft	2.2.0	experimental
lib	libXi	1.4.0	experimental
lib	libXinerama	1.1.1	unstable
lib	libXmu	1.1.0	unstable
lib	libXpm	3.5.9	unstable
lib	libXrandr	1.3.1	unstable
lib	libXrender	0.9.6	unstable
lib	libXRes	1.0.5	unstable
lib	libXt	1.0.9	experimental
lib	libXtst	1.2.0	unstable
lib	libXv	1.0.6	unstable
lib	libXvMC	1.0.6	unstable
lib	libXxf86dga	1.1.2	unstable
lib	libXxf86vm	1.1.1	unstable
lib	libdmx	1.1.1	unstable
lib	libfontenc	1.1.0	unstable
lib	libpciaccess	0.12.0	unstable
lib	libxkbfile	1.0.7	unstable
lib	libxtrans	1.2.6	unstable
proto	applewmproto	1.4.1	not for us
proto	bigreqsproto	1.1.1	unstable
proto	compositeproto	0.4.2	unstable
proto	damageproto	1.2.1	unstable
proto	dmxproto	2.3	unstable
proto	dri2proto	2.3	unstable
proto	fixesproto	4.1.2	unstable
proto	fontsproto	2.1.1	unstable
proto	glproto	1.4.12	unstable
proto	inputproto	2.0.1	unstable
proto	kbproto	1.0.5	unstable
proto	randrproto	1.3.2	unstable
proto	recordproto	1.14.1	unstable
proto	renderproto	0.11.1	unstable
proto	resourceproto	1.1.1	unstable
proto	scrnsaverproto	1.2.1	unstable
proto	videoproto	2.3.1	unstable
proto	windowswmproto	1.0.4	not for us
proto	xcmiscproto	1.2.1	unstable
proto	xextproto	7.1.2	unstable
proto	xf86bigfontproto	1.2.0	unstable
proto	xf86dgaproto	2.1	unstable
proto	xf86driproto	2.1.0	unstable
proto	xf86vidmodeproto	2.3	unstable
proto	xineramaproto	1.2	unstable
proto	x11proto	7.0.20	unstable
util	makedepend	1.0.3	unstable
util	macros	1.11.0	unstable
xcb	pthread-stubs	0.3	unstable
xcb	libxcb	1.7	experimental
xcb	proto	1.6	unstable

phpMyAdmin 3.4 is about to be released in something like two months (we want next beta to ship with brand new theme) and there is still plenty of translations to do. You still have lot of time to translate, but there is also lot of work to do. And I'm pretty sure there are some Slovak, German or Italian speaking readers of this blog. So what are you waiting for? :-)

Filed under: English Phpmyadmin 0 comments Flattr this!

Today I discovered via digi.no that the Chrome developers, in a surprising announcement, yesterday announced plans to drop H.264 support for HTML5 <video> in the browser. The argument used is that H.264 is not a "completely open" codec technology. If you believe H.264 was free for everyone to use, I recommend having a look at the essay "H.264 Not The Kind Of Free That Matters". It is not free of cost for creators of video tools, nor those of us that want to publish on the Internet, and the terms provided by MPEG-LA excludes free software projects from licensing the patents needed for H.264. Some background information on the Google announcement is available from OSnews. A good read. :) Personally, I believe it is great that Google is taking a stand to promote equal terms for everyone when it comes to video publishing on the Internet. This can only be done by publishing using free and open standards, which is only possible if the web browsers provide support for these free and open standards. At the moment there seem to be two camps in the web browser world when it come to video support. Some browsers support H.264, and others support Ogg Theora and WebM (Dirac is not really an option yet), forcing those of us that want to publish video on the Internet and which can not accept the terms of use presented by MPEG-LA for H.264 to not reach all potential viewers. Wikipedia keep an updated summary of the current browser support. Not surprising, several people would prefer Google to keep promoting H.264, and John Gruber presents the mind set of these people quite well. His rhetorical questions provoked a reply from Thom Holwerda with another set of questions presenting the issues with H.264. Both are worth a read. Some argue that if Google is dropping H.264 because it isn't free, they should also drop support for the Adobe Flash plugin. This argument was covered by Simon Phipps in todays blog post, which I find to put the issue in context. To me it make perfect sense to drop native H.264 support for HTML5 in the browser while still allowing plugins. I suspect the reason this announcement make so many people protest, is that all the users and promoters of H.264 suddenly get an uneasy feeling that they might be backing the wrong horse. A lot of TV broadcasters have been moving to H.264 the last few years, and a lot of money has been invested in hardware based on the belief that they could use the same video format for both broadcasting and web publishing. Suddenly this belief is shaken. An interesting question is why Google is doing this. While the presented argument might be true enough, I believe Google would only present the argument if the change make sense from a business perspective. One reason might be that they are currently negotiating with MPEG-LA over royalties or usage terms, and giving MPEG-LA the feeling that dropping H.264 completely from Chroome, Youtube and Google Video would improve the negotiation position of Google. Another reason might be that Google want to save money by not having to pay the video tax to MPEG-LA at all, and thus want to move to a video format not requiring royalties at all. A third reason might be that the Chrome development team simply want to avoid the Chrome/Chromium split to get more help with the development of Chrome. I guess time will tell. Update 2011-01-15: The Google Chrome team provided more background and information on the move it a blog post yesterday.

If you like phpMyAdmin and have web design skills, this is a chance for you. The question for new default theme has been opened for a while and in last weeks we've finally decided to rather make open contest than to stick with choosing from existing themes. All you need to do is to submit theme (compatible with phpMyAdmin 3.4) till 13th February 2011. You can find more details on our wiki.

Filed under: English Phpmyadmin 0 comments Flattr this!

Obviously. In contrast to what I claimed a few years ago, I am now also part of the FOSDEM info team, the central team that organizes this great meeting that happens every year in Brussels, Belgium. Currently, my involvement is limited to doing the same things that I did last year (except then by actually being part of the team rather than talking to them through mail), but this might change for future editions. These "things" involve organizing the cross-distro development room. The schedule isn't finalized yet (that'll happen sometime later this week), but interested parties can go have a look at the list of proposed talks for the cross-distro devroom. There's an interesting lot, IMO.

Once again, a polemic regarding how to properly integrate the Ruby language and libraries with the Debian distribution has been ignited. Similar arguments were presented in November and December 2008 and September 2010 And excuse me for just refering to my own blog, but there are links to some other posts from there... and there will surely be many others I just missed. There were even nice collaboration attempts (such as DebGem, announced in January 2009... But which apparently never stuck on, as it is still listed as in its public Beta period and lists only support for Debian 4.0 and Ubuntu 8.04 and 8.10). Some days ago, while I was on vacation, I received a mail from Lucas Nussbaum expressing the burnout he had been suffering from this situation. Some days after that, he posted a corresponding blog post - Giving up on Ruby packaging. The comments following his post are most interesting The one comment I'd like to highlight (noting I skimmed a whole deal of them) is by Paul Brannan, one of the original RubyGems authors. Yes, possibly the design criteria for Gems included some mutually-conflicting goals, and they cover some of Debian's goals. Unfortunately, this conflicting criteria... Was resolved to the opposite way we would have wanted (specifically, that a sysadmin should be able to install software with the same tools he was already familiar with). And of course, there are deeper disagreements, which are rightly stemmed from different priorities: Debian (+derivatives) is meant to make user's and sysadmin's lifes simpler. Gems are meant to make developers' lifes simpler. And while all developers are some sort of users, and sysadminsthe reverse is (obviously) not so. A developer maintaining several different codebases will surely suffer (well, this particular developer has surely suffered) if he has to maintain them all using coherent versions of system libraries. When a system is programmed, its developers want to use the greatest, latest tools to offer the best experience and functionality. And it's natural for libraries to evolve over time. However, any sysadmin will grind their teeth at the prospect of having many different versions of libraries, as the Gem model proposes. Why? Well, I was bitten by a minor example of it Bug fixes do not get backported. Of course, if simple bugs are not backported, security and stability of the system as a whole suffers. Often, new software versions will not only add functionality, but improve on how things are done. Not only bugs get corrected, but we get better response times, better memory handling, etc. It might sound harsh to say this, and even more, as a developer it feels I am talking against myself But while development time should be minimized during the system design/implementation, once systems are in production, it should be used to allow for friendlier sysadmin relations. I have to wear both hats at my real-life job. So, what is my take on this? Of course, blaming myself for choosing the wrong version is a no-go. When evaluating a library before using it in my projects, I try to look at its history and API-stability. APIs that change often speak about immature libraries which are still trying to get the right way to implement their functionality; just-started projects might be great and revolutionary, but they do not yet show any kind of long-term committment... And can lead (and have often led me) to painful rewrites when the Next Big Thing is reached. As for the users: Even if your favorite language has the best and friendliest distribution method, users just do not care about what language was a particular piece of software implemented in. Users want to be able to install and uninstall with their system's usual tools. Directly using Gems, CPAN, PEAR and whatnot is just unnatural for users, however convenient they are for developers. Distributions offer a non-technical advantage in this regard as well: A human filter. As an example, as I write this there are 19392 Ruby Gems and 19092 Perl modules in CPAN (note that CPAN stores some older versions but discourages authors from keeping too many - So no, they are still very different in size). Debian has around 30,000 packages. Why is that? Because all Debian packages _must_ be human-generated, human-reviewed, human-submitted. This means, a person must think each packaged piece of code is worth packaging, is stable enough and provides value to users as it is, and is fit for being part of a stable release. I am not saying with this that 90% of CPAN and Gems are crap I am saying that they are probably early implementations, to be installed, tested and improved by developers, and still not apt for general public use. Or maybe not interesting enough to be packaged as a service for the non-techie public at large. Oh, and one last point: Ruby is not a new language anymore. It is a mature, powerful language with different implementations, every time more stable... But it is a language deeply affected by the (not so new anymore either) the appearance of Rails. Why do I say this? Because although the language is in no way tied to Web development, many of its strongest uses are Web-oriented. How does this affect the current discussion? Well, because many people argue that users are no longer needed to install the software. Web systems are installed by sysadmins and used via a Web browser, and sysadmins are expected be more skilled than casual users. Still, in Debian (and in other distributions, surely) we try to make sysadmin's lives simpler I have (again, talking out of personal experience) installed several webapps (and system tools, and whatnot) for which I never followed any instructions besides aptitude install foo Using different languages, frameworks, and so on. Can I troubleshoot their installs? Probably, as there is a common logic for how the distribution I have chosen and specialized in works. Can I find causes for bugs in them? Possibly, although there are some languages and frameworks I dare not touch. Can I get help on getting them out of a tight spot? Surely, as there is a central bug tracking system for my distribution And one of the maintainer's tasks is to separate the problems related to the distribution (packaging, installing, simple user questions and misconceptions) to those derived from real bugs upstream. Anyway I am not saying that our way is the best way. No, by a long shot. Again, developers should have an easy, convenient way for installing whatever they want to play with. And to publish it without jumping through hoops. With this post, I'm only trying to express again why Debian works the way it does. And hope for better cooperation in the future. And as for several comments of what I read in Lucas' post, I think that there is interest for this synergy among some of the most committed Ruby people.

It's no secret to the people I around me that over the past two years I've become a Haskell fan, to put it mildly. I mean, what's not to like? Just in the past month:

• a conceptual one-line change (map parMap, but the actual commit is a big longer as it splits a foldl in two) and re-linking with the threaded runtime resulted in the balancing routines used in the ganeti-htools code to achieve between 60% and 80% increase with the number of cores; without any locking primitives, thread synchronisation, etc.; and yet the algorithm is not at all slower when run single-threaded, which is something very hard to do in other, mainstream languages
• a recent test project of mine introduced me to the web framework Yesod, which gives statically-type checked URL construction and referencing, without requiring me to do any value escaping, URL component construction, etc.; comparing that to what I'm used from other languages (though admitedly I don't have too much experience with web development), it's unbelievable how well the type system plays even with the untyped world of the Web applications

The downside is that whenever I feel Ok, now I kind of know my way around Haskell , I learn of another thing that completely resets how I feel about my Haskell understanding. The most recent example is Template Haskell. I mean, there are people who already blame Haskell for its arcane syntax, which I like. But Template Haskell goes a step forward and allows you to use a Haskell library to write Haskell code, with an even more contorted syntax or at least that how it looks for now to my eyes. Gladly this is not easily doable in a recursive way (meta-TH code writing TH code that will write Haskell code), otherwise heads would explode (at least mine). But even though it seems very complicated, I feel that the power that it enables (a macro system that generates code that will be statically checked) is removing one of the last big advantages that (for me) Python had over Haskell: it's easy to do class modification in Python and introspection (e.g. via metaclasses) to automate boiler plate away, but it's of course not type safe (so unittests galore). With TH, you can do the same customization of data types (and not only) and compile-time introspection (called reification) to alter (some) of the properties of the respective type, for example automatic instance derivation, so one less reason to say this particular problem is harder to do in Haskell than in other languages . I haven't yet used TH for my own code and until I actually use it extensively I won't be sure it's actually a good replacement for throw a __metaclass__ in there and automate the boring parts away . But in any case, it looks to be yet another awesome tool in the Haskell programmer's toolbox, which I can't wait to use.

2.6.37, which was released today, has been a very big release for ASoC about 40,000 lines of changes covering every single file within the subsystem plus a bunch of new drivers. The highlights are:

• Overhaul of the core APIs for registration of all kinds of devices from my co-maintainer Liam Girdwood, reducing the level of direct coupling between machine drivers and their CODEC and CPU drivers allowing ASoC machines to have multiple CODEC devices and multiple instances of the same CODEC device within a system.
• New CODEC drivers for 88PM860x CODEC, MAX98088/9, WL1273, WM8962, WM8804, and WM8985.
• New CPU drivers for EP93xx AC 97 controllers, MPC 85xx SSI ports, and SH HDMI controllers.
• Machine support for Freescale P1022 DS, Marvell Tavor and Saarb and Simplemachines Sim.One

On a lark, I signed up for the pilot program of the Google Cr-48 about a week ago. To my surprise, I found the distinctive box on my doorstep a week later. After initially mistaking it for an overpacked, late-model OLPC XO-1 I would have to repair, I sort of did a double-take as I realized what I had received. Using Chrome OS Wow, they weren t kidding about the boot time. Chrome OS responds (to suspend / resume and boot / power-off) very quickly. Responsiveness elsewhere in the OS of course varies on system load and other factors. On the terms page, there is a system security setting which tells me I have a Trusted Platform Module, and that my TPM has a randomly generated password. The dialog could use some rewording; I m pretty familiar with the idea of a TPM, but I m still not sure what I m to do with that information. Cloud print is really a problem for me, right now. I use school printers for the majority of my work, which I was previously able to use by adding them by IP address. Unless there s some magic I m missing here, I can t do that with Chrome OS, and such a feature will not be supported. (except by connectors on Windows and Mac computers) General thoughts I can t imagine using a system running Chrome OS as a primary computer. The biggest missing feature is PGP (or any sort of encryption) support for email. This is probably not terribly difficult to implement as an extension, but the idea of my cryptographic software being automatically updated is rather unsettling. I think I ll have to agree with Paul Buchheit that ChromeOS will have to merge with Android; there is a utility for local apps, even if they re becoming less and less critical.

The book Mastering phpMyAdmin 3.3.x for Effective MySQL Management is already available for some time, but I still think I should promote a little bit in my blog so here it is :-). The book covers all you might want to know about using phpMyAdmin. It really does not make sense to copy text from book description, so feel free to find yourself what all it does cover. As every time, this book is written by Marc Delisle, who is for several years project admin, so probably the person who knows most about hidden features. Usually technical review of the book is done by some other developers and this time it was me doing this job (among other reviewers). I hope we did good job and you will like this book. PS: As a nice bonus, the phpMyAdmin project receives money from every purchased book.

Filed under: English Phpmyadmin 0 comments Flattr this!

I have finally reached a decision regarding my involvement in the Debian Ruby packaging efforts. I have decided to stop. This has been a very hard decision to make. I have invested huge amounts of time in that work over the years. I still love the language, and will continue to use it on a daily basis for my own developments. I still hope that it will succeed. I know that some people will be disappointed by that decision (and that others will think your work was useless anyway, people should use RVM and rubygems ). But I also know that I won t be able to push for all the required changes alone. I just don t have the time, nor the motivation. For the record, here are the changes I would have liked to see in the Ruby community. The core Ruby development community should mature.
The core Ruby development community is still dominated by Japanese developers. While not a bad thing in itself, it is easily explained by the fact that the main development mailing list, where most of the important decisions are taken, is in japanese. ruby-dev@ should be closed, and all the technical discussions should happen on the english-speaking ruby-core@ list instead. The release management process should also improve. Currently, it looks like a total mess. The following Ruby development branches are actively maintained:
ruby_1_8 (106 commits over the last six months)
ruby_1_8_6 (4 commits over the last six months)
ruby_1_8_7 (35 commits over the last six months)
ruby_1_9_1 (4 commits over the last six months)
ruby_1_9_2 (227 commits over the last six months)
trunk (1543 commits over the last six months) While the state of the ruby_1_8_6 and ruby_1_9_1 branches is clear (very important bugfixes only), the state of all of the other branches is rather unclear.
What s the stable Ruby branch? 1.8 or 1.9? If it s 1.9, why are people still actively developing in the ruby_1_8 branch? How long will they continue to be maintained in parallel, dividing the manpower? Is a Ruby 1.8.8 release to be expected? Will it be ABI/API compatible with 1.8.7? Is the ruby_1_8_7 branch really bugfixes-only? How much testing of it has been done? If it s bugfixes-only and regression-free, I should push it to Debian squeeze, due to be released in a few weeks. But would you recommend that? Due to past breakages in the ruby_1_8_7 branch, it s unlikely that we will do it.
Is the ruby_1_9_2 a regression-free, bugfix-only branch? If yes, isn t 227 commits over 6 months a lot? What will be the version of the next release of trunk ? When is it expected? Will it be ABI-compatible with the current ruby_1_9_2 branch? API-compatible?
New releases in the 1.8.7 and 1.9.2 branches were done on december 25th. Why were they no betas or RCs allowing wider testing? How much testing has been done behind the scenes? Most of those questions have no clear answer. The Ruby development community should build a common understanding of the status of the various branches, and of their release expectations. Releasing on december 25th of each year sounds fun, but is releasing when everybody is on vacation really a good idea? It would be fantastic to have something similar to Python Enhancement Proposals in the Ruby community. But having open discussions in english about the major issues would already be great. Ruby is not just the interpreter.
The Ruby development community should clearly define what the Ruby platform is. There are some big players, like Rails, and newer interpreter releases should not be done before ensuring that those big players still work. Also, since we have alternative Ruby interpreters, like JRuby, Rubinius and MacRuby, we need a clear process on how they integrate with the rest of the ecosystem. For example, having each of them rely on their own outdated fork of the whole stdlib is ridiculous, since it s not where they compete. The Ruby community should acknowledge that RVM and Rubygems are not for everybody. People who say so should be laughed at. Of course, RVM and Rubygems are nice tools for some people. But it is completely wrong to believe that compiling from source using RVM should be the standard way of installing Ruby, or that all people interested in installing Redmine should know that Ruby has its own specific packaging system. The Ruby community should work with their target platforms to improve how Ruby is distributed instead of reinventing the wheel. That includes Debian, but also RedHat-based distros, for example. It is likely that it won t be possible to reach a one-size-fits-all situation. But that s real life. Some people in the Ruby community should stop behaving like assholes. As one of the Debian Ruby maintainers, I have been routinely accused of creating crippled packages on purpose (FTR, I don t think that the Debian packages are crippled, despite what the rumors says). Debian is not the only target of that. Just yesterday, someone called for abandonning YARV (the new Ruby VM in Ruby 1.9), calling it Yet Another Random Vailure. This kind of comments is really hurting the people who are investing their free time in Ruby, and is turning away people who consider getting involved. In Debian, we have had a lot of problems getting people to help with Ruby maintenance since they are getting shit from the community all the time. So, what s the future for Ruby in Debian?

• For the interpreter, the two other maintainers, Akira Yamada and Daigo Moriwaki, are of course free to continue their work, and I wish them good luck.
• For the pkg-ruby-extras team, which maintains most of the Ruby libraries and applications, the future is less clear. The team was already badly understaffed, and I feel that I should probably clean up its status by orphaning/removing the packages that are unmaintained otherwise. This won t affect all the packages that the team maintains: some packages (like redmine) are actively maintained, and will stay.
• For me, it just means I will have more time for other things (possibly not Free Software-related). If things improve dramatically, I might also come back to Ruby packaging at some point.

Update: there s also a number of interesting comments about this post on this site.
Update 2: First, thanks a lot for all the interesting comments. I will make some follow-up posts trying to summarize what was said. It seems that this post also triggered some reactions on ruby-core@, with Charles Olivier explaining the JRuby stdlib fork, and Yui Naruse clarifying that all questions are welcomed on ruby-core@. This is great, really.

It's new year (for almost 18 hours here) and it's time to balance a bit what has happened in year 2010. I'm not going to expose details from my personal life and anything related to work, so all what remains are open source projects where I am active. For phpMyAdmin it was year of quite big changes, most of them beeing agreed on Fosdem 2010. We have migrated to git from svn, what was great step forward and I really like the change. It was also decided to use gettext (or rather php-gettext) for translations in upcoming release. I can see this move (together with online translation service) has definitely attracted more contributors (hey, but there are still many languages not translated, you're welcome!). Also we've participated in Google Summer of Code 2010, what lead to several big projects being merged into our code base (see my summary for more details). All in all, we're heading to 3.4 release in first months of 2011, which will be quite major step and hopefully heading in right direction. In Gammu and Wammu, there were lot of code improvements, most of them probably going into Gammu SMS Daemon (the latest one being unified SQL backend removing lot of code duplication). Another major improvement is The Gammu Manual covering everything from Gammu command line, through SMSD up to python and C API. On the other side I've bought me a Symbian based phone, which does not work with Gammu and I use Series60-Remote for that, so my interest in Gammu has declined a bit. Even though I've started adopting some packages in Debian, so it looked like I will end up with much more than last year, but at the end I've decided I'm too overloaded with some of them (and don't use them anymore), so I've given some for adoption and got rid of nanoblogger (and nanoblogger-extra) and looking for somebody to pick up gpointing-device-settings. Maybe all mpd related packages will follow soon, because I currently do not use mpd, so it limits quite a bit my ability to test them. And of course: Happy New Year 2011!

Filed under: Debian Gammu Phpmyadmin English 0 comments Flattr this!

I m a long-time snipmate.vim user and I ve been adding occasionally some snippets to it, and today I want to share it to everyone who may be interested on using them. All of them are CSS3, Javascript and HTML5 related, plus 2 (or something) for PHP+WordPress. Anyway, if any of you use WordPress+PHP and use snippets please, let me know. I m working on WordPress these days and some snippets would help me a lot. You can download my snippets from my github, hope its useful for anyone.

After several months of leisurely development (I've read through everything on the Internet several times, and notified everyone who was wrong), I have finally gotten obnam, my backup application, into a state where it successfully backs up my laptop's hard disk to a USB disk. I therefore declare it to be perfe... no, wait, I don't. It's slow. It's probably buggy in ways that will make you want to abandon computers forever. It's also slow. And buggy. Did I mention it is slow, making backups at only a few megabytes per second? Disclaimers aside, I am happy to have gotten obnam to this stage. It's not nearly ready, but it's getting along nicely. If you've been curious about obnam ever since I first mentioned it in 2007, now might be a good time to try it out. I would be very interested in hearing any feedback. Obnam is implemented using copy-on-write B-trees, and I've also released my B-tree implementation. See the NEWS file in each source tree for information for what's changed since the previous release. Links:

• Obnam
• btree

I have made Debian packages of obnam, btree, and some of my other stuff that they need, for all, amd64, and i386 architectures. The repository is at http://code.liw.fi/debian/, so add this to your sources.list if you want to use that:

deb http://code.liw.fi/debian squeeze main

Note, however, that I do not guarantee that this repository will be in any useful state at any given time. I use it, and rely on it, and will fix things when they bother me, but that's all the guarantee I give. (Do you get the impression I've read too many contracts?) Once obnam is ready, and Debian squeeze is released, I'll upload it to Debian, and then you'll get it for any architecture Debian runs one. If anyone wants to help me maintain the packages for Debian, please e-mail me. If, on the other hand, you'd like to help make obnam faster, or better, the bug tracker has some pointers. Right now speed is perhaps the biggest problem. The B-tree library needs optimizing, as does obnam itself. And the LRU cache I use. The worst missing feature is encryption support. I do my backups to a local hard disk, which is full-disk encrypted, which is why I haven't cared about implementing encryption yet. Also, I need to design a good way to manage keys, etc. Help with that would be quite welcome.