I have a Samsung CLP-315 printer. It works will with CUPS and foo2qpdl driver. Just ignore all the anti-distro junk written at driver s homepage, run aptitude install foo2zjs, and enjoy working printer on consistent system. But since the beginning there was a strange problem printing worked from everywhere, but not from iceweasel. If tried to print from the browser, error page was printed instead. So had to print to a pdf file, open it in kpdf, and print from there. Working but annoying. At last decided to do something with this. A quick search shows that problem is known, is not new, and as such has little chance to be quickly resolved. But then I found this hint. I immediately checked paper size in iceweasel s print dialog and yes, it was Letter! But the setting was greyed out, so unchangeable I ve tried to play with about:config (searching for print there), then tried to remove all printer setup from prefs.js no result, still Letter without option to change. But a web search helped again. Someone pointed that iceweasel has a separate menu item for page setup, at File::Page setup! That is where paper size has to be configured, tab within print dialog does not work! Mozilla people are wonderful UI designers. Many thanks to them for months of non-working printing. I ve told myself zillion of times that I should perform active steps to get rid of bugs on computers I use search the web for solutions, report bugs, fix code myself if nothing helps. That s the very point of using free software, after all. But still laziness lack of free time random real-life issues make me not to do so too often. So also many thanks to myself for months of non-working printing. But now printing from browser works, and that s good news . Update: full thanks above should be directed to, in order:

• Samsung firmware developers, who coded firmware that, when printing error page (btw wasting paper and toner), doesn t print what is actually wrong (paper size mismatch),
• Mozilla developers, who don t read default paper parameters from CUPS, but instead use own broken scheme,
• myself, for living with problem and not looking for solution for months,
• foo2qpdl upstream, who, by his anti-distro junk, turns people looking for solutions into wrong direction,
• Mozilla developers, who use braindead page setup UI.

And real thanks to the person (link above) for the hint about page size in applications that are unable to print

Last night was the last time I came back from a pub with my clothes stinking due to tobacco smoke. The Spanish congress has finally approved a real anti-smoking law which will ban smoking on public areas, with no exceptions or ways to workaround the ban. Starting on January 2nd, the Spanish state will be a smoke-free region (or mostly, it seems it'll be permitted in open-air events like football stadiums or bullrings, and I don't think that will be a great problem for me, specially the latter). For years, my intolerance to smoke has been increasing and I'm really expectant to see the benefits of this law in my habits. After more than 30 years dealing with smoke around us, it's our turn now. I've been speaking to a few barmans. In general they seem worried this will affect their business, but I can't see how it will. Spain has a big culture for having mid-morning almuerzos in bars, and people are not going to give that up due to not being able to smoke. They will just do it after they get out, not during the coffee, and that's it. The barmans of the two bars I visit most are non-smokers, but have to breath the smoke of hundreds of cigarretes every day, and can't do anything about it. Until tomorrow, when this will end and everyone will have a right to breath better air. I hope this kind of legislation continues to be adopted throughout Europe, because the FOSDEM welcome party is probably the next smoke horror I'll have to face soonish. :)

I knew walking all over the Pyrenees during a whole month would come with some side effects. I could imagine having a few muscular issues in my legs and some back pain for a while after getting back; after all we did over 7 hours of exercise every single day during a month. What I got after our hike was totally unexpected... I should have run a half marathon in Gandia on the 21st, and instead I stayed at home doing some assignments. When we came back, I was in a really good condition, and wanted to keep the good shape we had built the month before. Given I haven't been able to swim for nearly a year now, due to the Misterious Shoulder Injury and I don't have enough time to go out cycling regularly, I centered my efforts in running, with the idea of starting to get prepared for cross/mountain races this season. Training had to wait a little because some days after getting back, I got a sudden pain on both knees, which even made climbing stairs difficult. It stuck for a while, and when it finally went away, more or less, I went ahead and tried going out for a run. I haven't been training for over two years, so I indended to increase the distances proggressively. The first day I went out, I ran really nicely for the first 25 minutes, and suddenly I started getting an intense pain in the outer side of my right knee, to the point I could barely walk back home. I've tried letting them rest for weeks, and every time I try them, the pain comes back. My physiotherapist says my body has developed quite a few asymmetries, probably caused by the many days I had to walk crippled by a big blister in my right foot. As time passes, I feel I'm losing all the physical improvements I had developed during the summer, and I can't do anything about it. The new approach to tackle this is yoga. I know my body isn't too elastic, and the lack of stretching during the walk made it even worse, so I'll try to forget about real traning during some time and focus on healing my muscles. Hopefully, this will help me resolve the nastiest physical problem I've ever come across.

Tomorrow, at this time, I'll probably be unsuccessfully trying to find a comfortable position on a seat of the Bilmanbus to Irun. Very early on Saturday, as soon as we get off the bus, Maria and I will quickly head to Hondarribia's beach in Cape Higer to symbolically wet our feet in the waters of the Cantabrian Sea. We won't have much time to enjoy the cold waters of the ocean, though. Soon after that, we'll have to take a deep breath, look East, and start walking if we want to achieve our utmost objective: take a bath in the beautiful beaches of the Cap de Creus, in the Mediterranean sea. In between, 30 days and 840 kilometres of thick woods, deep valleys, high peaks and cold waters, all of which shape incredible landscapes.

The Portella de Baiau, during our 2008 trip For a whole month, we'll be mostly disconnected from everything else that isn't our knee ache, our blisters, the Sun over our heads or where to get food. It's the first time I leave on a hiking trip as long and tough as this one, and I feel both uncertainty and eagerness. We've been so busy during the last few months that we've been unable to train at all for this, and I'm probably in the worst physical condition in a decade. It's too late to take care of that now, so we'll try to take good care of our legs and spine. In order to get back home in the Mediterranean, we'll have to be fast, some days joining two stages and skipping a few that we know are not that interesting (sections over asphalt, etc.). It's hard to make it in just one month, but we'll try our best. The plan is going to sleep not long after sunset, getting up at dawn, to be able to walk for a decent time before the heat starts being a handicap and just resting at midday, when the Sun is strongest. Of course, this means that I'm missing, yet again, this year's edition of DebConf in New York City, which is really sad because I was looking forward hanging around with Mako, Mika, Biella, micah, Clint and the rest of the NYC/ Boston gang, but when the idea of doing a long trip this summer popped up around January, it was clear DebConf seemed unlikely this year. I hope all of you have a lot of fun, and see you in a few weeks!

This is my first post on Planet Debian. In the title, I used the plural for planets, as I will try to be bilingual, and send here each time a translation from my post on Plan te Debian. For this, I will use po4a and Virtaal or Poedit, mostly for training purpose since there is not much to translate anyway. Conversions will be via ikiwiki s po plugin. This blog is hosted on Branchable. I am a Debian developer since 2008, and specialize in bioinformatics through the Debian Med project. In the everyday life I'm a (molecular) biologist. My current packages are mostly research tools, but in view of the amazing progresses of DNA sequencing, we may see software aiming at the general public in the future. And given the stakes, I hope that some of them will be free and we'll manage to distribute them in Debian!

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.

Not for the first time, I ve seen the suggestion in the echo chamber that Mono packages should be moved from Debian into the non-free repository, which is not formally part of Debian. The reason, as it so often is, is patents specifically this time, the searing risk posed to Debian and its users that Mono s packaging does not (and technically could not without forking from upstream) provide base class libraries which implement only the content of ECMA-335 4th Edition. As I understand it, this implies three things about the suggestion/demand: firstly, that the individual in question believes that Mono end users are at risk from patent litigation from Microsoft Corp because Mono s implementation of Microsoft.NET beyond the content of ECMA 334/335 infringes on Microsoft patents; secondly, that the Microsoft Community Promise which promises not to assert legal claims over third party implementations of ECMA-335 4th Edition (and ECMA-334 4th Edition which defines the C# language) would render a pure ECMA-only runtime safe if it existed (which it does not); thirdly that without the protection offered by the Microsoft Community Promise, the source code licenses of Mono are irrelevant the patent risk renders the software non-Free. It appears, unfortunately, that the community of Free Software Advocates don t actually understand what Free Software actually IS. That explains an awful lot, but should surprise nobody. So here s a lesson on what, exactly, is being advocated for. The Free Software Foundation defines four Software Freedoms these are the minimum criteria required for something to be considered Free Software by the FSF:

• The freedom to run the program, for any purpose (freedom 0).
• The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help your neighbor (freedom 2).
• The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

Other groups have their own variants on these, but those are really just clarifications on the FSF definition - for example, the Debian Free Software Guidelines mostly line up, but have some additional clauses such as clause 4 which allows software to be considered Free if source code may be redistributed without modifications, as long as patches may be shipped alongside. These four freedoms are offered to you by the software s copyright holders only, and apply regardless of their choice of license any Free license, from a lengthy legal tome like the MPL to the completely-Free WTFPL, will offer you these four basic freedoms as a minimum, and any additional clauses in their licenses cannot seek to restrict these freedoms. These four freedoms represent the beginning, and end, of whether a piece of software is Free or not. Software does not need to be developed in the open, in a community-responsive way, in order to qualify as Free projects such as Google s Android, which are developed under a throw a final release over the wall, bugs and all, and expect people to thank you for it model, are still free, even if contribution is difficult. Actually, on a related note, software does not need to solicit upstream contribution of any kind in order to qualify as Free as long as you personally can redistribute the code with changes, then that s enough. Software does not need to serve a fully or even partially legal purpose in order to qualify as Free the favoured tool for causing distributed denial of service attacks, Low Orbit Ion Cannon, is Free Software, even though realistically it serves no legal purpose. DeCSS, the code initially used to allow DVD media to play on Linux (by breaking the CSS encryption mechanism) is Free Software. Software does not need to be useful or tasteful in order to qualify as Free the Last Measure Operating System, a minimalist OS primarily designed to loudly display the famous shock site images from goatse and related, is Free Software. Even in somewhat less clear-cut cases of taste, your personal opinion of software has no bearing on whether it is Free Software, as long as the four freedoms are guaranteed by the author(s). Software does not need to have only Free dependencies to qualify as Free Software it is entirely permissible to write software which relies upon a non-Free framework or library, and release your code under a Free license. It is the downstream recipient s problem to provide the dependencies, including their choice to craft a Free replacement for any non-Free code you make use of. Debian has a special repository called contrib, where Free software which only works with non-Free data, lives for example, Free game engines which require the insertion of proprietary game data in order to operate. You could write Free addons for expensive proprietary software such as Matlab, and as long as your code is Free, your responsibilities are met. Software does not need to avoid patents software, algorithmic, or otherwise in order to qualify as Free. The Freetype font library was still entirely Free Software when Apple were slinging threats around regarding font hinting data. FFmpeg, the Swiss Army knife of media codec libraries, is Free Software regardless of the number of codec patents it breaks. Software does not need any third party approval to be Free Software the rights of Free Software can only be offered by the copyright holders, and the opinion of third parties is an irrelevance as to whether software is Free. The GPL d clone of Blizzard Entertainment s Battle.net servers, bnetd, is Free Software, regardless of legal takedown notices. Third parties cannot influence whether or not a piece of software is Free. They can influence tangentially related topics, such as whether the software can be legally used, but that s the limit. And even within a given piece of software, where copyright is shared by contributors, the author of one component has no say on other components. And you can t make code which is already released as Free, suddenly un-Free you can, if you hold all the copyrights, close up future versions, but your existing code remains Free forever. Reasonably, you can opt to avoid using a piece of software because you have requirements beyond it merely being Free Software Cdrtools has been avoided in Debian for a long time due to the upstream author s legal threats and rambling but that is a side issue as to the question of whether or not the software is Free. Patents are simply not involved in the question of whether or not something is Free Software, except for one narrow case: where Free Software is released by somebody who also holds related patents, and uses a license such as Ms-PL or Apache 2.0 or GPLv3 which requires them to also release those patents to those using/distributing the software. Outside that narrow situation, patents do not relate to the question of whether something is Free Software even if a company releases some source code under a license like BSD then demands patent fees from end users. So, on to the original topic of Mono. Every piece of Mono s source code is released by its authors under a license which guarantees the FSF s Four Freedoms. Whether or not you find Mono useful or tasteful does not affect that Free status. Whether or not Mono infringes upon any laws or patents does not affect that Free status. That Mono contains some libraries whose upstream author is Microsoft does not give Microsoft even the remotest claim to a single line of code outside the code they wrote and even then, it wouldn t be an issue, since the licenses they use are Free. In fact, both the licenses used in the Microsoft portions of the source base make patent grants to all users, in addition to guaranteeing the FSF s Four Freedoms and any license contamination would decrease, not increase, any risk of legal attack from Microsoft. There s even plenty of Microsoft code available for re-use at a lower level than the currently re-used libraries: The Microsoft.NET Micro Framework (for use on embedded platforms direct to the metal) is under the Free Software Apache 2.0 license, and would provide access to some of Microsoft s runtime and class library code, complete with a patent grant, if it were desired. Please try to keep your thought processes straight. If you want to argue that you re all for Free Software, please remember that there s plenty of Free Software you might not approve of and don t claim to be a Free Software advocate then use bogus arguments to claim that Free Software is not Free. Free Software includes LMOS and LOIC and Mono, whether you like it or not.

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

Hello The new version of libconfig-model-perl 1.229 is now available in Debian/Sid. This new version provides a model of Debian s DEP-5 copyright file specification updated according to the CANDIDATE version. (Among other features, like editor/validator for debian/control). The DEP-5 editor must be run in the source package directory (I ll provide an example below) with the following command:

config-edit -application dpkg-copyright

Features:

• check copyright file (with option -ui none )
• migrate from old format to new format ( with option -ui none -save )
• graphical editor (no option, but libconfig-model-tkui-perl must be installed)

Known issues:

• some keywords from older versions of DEP-5 specs may have been missed. In this case, feel free to send a mail to config-model-users mailing list or to log a bug in BTS.
• the update of the content of the format string is silent. This behavior is a bit cavalier. This will change in the next version

Example: The copyright file of libconfig-model-backend-augeas-perl needs to be updated: Here s the original copyright file (slightly edited to protect my mail box and save electrons) :

$ cat debian/copyright
Format-Specification: http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=196 Upstream-Maintainer: Dominique Dumont (ddumont at cpan.org)
Upstream-Source: http://search.cpan.org/dist/Config-Model-Backend-Augeas/
Upstream-Name: Config-Model-Backend-Augeas Copyright: 2008-2009, Dominique Dumont (ddumont at cpan.org)
License: LGPL-2+ Files: debian/*
Copyright: 2009, Dominique Dumont
License: LGPL-2+ License: LGPL-2+
This program is free software; you can redistribute it and/or
[snip]

First, let s just check issues:

$ config-edit -application dpkg-copyright -ui none
Element Upstream-Maintainer of node Debian::Dpkg::Copyright is deprecated
Element Upstream-Source of node Debian::Dpkg::Copyright is deprecated
Element Upstream-Name of node Debian::Dpkg::Copyright is deprecated
Missing Files: specification at top of section number 2. Adding Files: * spec

Then, let s see what s config-edit can fix all by itself:

$ config-edit -application dpkg-copyright -ui none -save
[ same warnings displayed ]

Let s check the result of the migration:

$ config-edit -application dpkg-copyright -ui none
[ good: no more warnings ]

And here s the content of the upgraded file (drum rolls, please):

$ cat debian/copyright
Format: http://dep.debian.net/deps/dep5/
Upstream-Name: Config-Model-Backend-Augeas
Upstream-Contact: Dominique Dumont (ddumont at cpan.org)
Source: http://search.cpan.org/dist/Config-Model-Backend-Augeas/ Files: *
Copyright: 2008-2009, Dominique Dumont (ddumont at cpan.org)
License: LGPL-2+ Files: debian/*
Copyright: 2009, Dominique Dumont
License: LGPL-2+ License: LGPL-2+
This program is free software; you can redistribute it and/or
[snip]

You can see that:

• keywords were changed while keeping the correct content
• Format: was updated with the right URL
• Files: * line was added in the right place

Please provide feedback! If you have problem migrating DEP5 files, yell, and we ll fix them. If this migration works fine, don t be shy, please say so. Under the hood:

Most of the migration work is specified in DEP-5 model [2]. Using config-model s GUI [3] to update DEP-5 model, about one hour was spent to:

• flag old parameters as deprecated
• introduce new parameters from candidate version (mostly done by cut n'paste old parameters into their new name, done within the model editor GUI )
• cut n'paste the doc bits from the web page into the model editor GUI
• specify migrate_from instruction to copy semantic content from old parameters to new ones. (*)

This shows one important feature of Config::Model: maintenance and evolution of a model is not a huge task. Even though copyright files are not configuration files, the same approach can be used to specify model and migration of other configuration files. Now comes the question of the migration as seen by the user. Well, it s your turn now. Try it and tell us how it works! Hopefully, encouraged by your feedback, other people will apply config-model to other specifications or other configuration. All the best (*) E.g, in the text format produced by the model editor GUI: 'Upstream-Contact',

'value_type' => 'string',
'migrate_from' =>
'formula' => '$old_maintainer',
'variables' =>
'old_maintainer' => '- Maintainer'

,
'type' => 'leaf',
'description' => '* Syntax: line based list [snip]'
,


The Debian Installer team has announced the Debian Installer 6.0 Release Candidate 1 release. Read about all the changes and improvements at their announcement.

Remember Squeeze will ship with a completely free Linux Kernel, although if you require use of the non-free bits you can keep fetching them from non-free. Non-free is not part of the Debian default installation and must be enabled manually.

Your help is welcome:

• With any of the bugs at http://tinyurl.com/squeeze-sort, especially with the bugs marked as blocked.
• With the release notes, report a bug to release-notes (with patch!) if you see any information missing or incomplete or if you have something worthwhile to add.
• Translating the release notes with the Debian internationalization teams.
• And you are still on time to do upgrade and installation tests and report any big issue you may encounter.

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.

There are several ways a program can hit the disk, and it can be hard to know exactly what s going on, especially when you want to take into account the kernel caches. This includes, but is not limited to:

• any access to a file, which may lead to I/O to read its parent directories if they are not already in the inode or dentry caches
• enumerating a directory with readdir(), which may lead to I/O on the directory for the same reason
• read()/write() on a file, which may lead to I/O on the file if it is not in the page cache
• accesses in a mmap()ed area of memory, which may lead to I/O on the underlying file if it is not in the page cache
• etc.

There are various ways to track system calls (e.g. strace) allowing to track what a program is doing with files and directories, but that doesn t tell you if you re actually hitting the disk or not. There are also various ways to track block I/O (e.g. blktrace) allowing to track actual I/O on the block devices, but it is then hard to back-track what part of which files or directories these I/O relate to. To the best of my knowledge, there are unfortunately no tools to do such tracking easily. Systemtap, however, allows to access the kernel s internals and to gather almost any kind of information from any place in a running kernel. The downside is that it means you need to know how the kernel works internally to gather the data you need ; that will limit the focus of this post. I had been playing, in the past, with Taras script, which he used a while ago to track I/O during startup. Unfortunately, it became clear something was missing in the picture, so I had to investigate what s going on in the kernel. Setting up systemtap On Debian systems, you need to install the following packages:

• systemtap
• linux-image-2.6.x-y-$arch-dbg (where x, y, and $arch correspond to the kernel package you are using)
• linux-headers-2.6.x-y-$arch (likewise)
• make

That should be enough to pull all the required dependencies. You may want to add yourself to the stapdev and stapusr groups, if you don t want to run systemtap as root. If, like in my case, you don t have enough space left for all the files in /usr/lib/debug, you can trick dpkg into not unpacking files you don t need:

# echo path-exclude /usr/lib/debug/lib/modules/*/kernel/drivers/* > /etc/dpkg/dpkg.cfg.d/kernel-dbg

The file in /etc/dpkg/dpkg.cfg.d can obviously be named as you like, and you can adjust the path-exclude pattern to what you (don t) want. In the above case, kernel drivers debugging symbols will be ignored. Please note that this feature requires dpkg version 1.15.8 or greater. Small digression One of the first problems I had with Taras script is that systemtap would complain that it doesn t know the kernel.function("ext4_get_block") probe. It is due to a very unfortunate misfeature of systemtap, where the kernel.* probes refer to whatever is in the vmlinux image. Modules probes have a separate namespace, namely module("name").*. So for the ext4_get_block() function, this means you need to set a probe for either kernel.function("ext4_get_block") or module("ext4").function("ext4_get_block"), depending how your kernel was compiled. And you can t even use both in your script, because systemtap will complain about either being an unknown probe Tracking the right thing I was very recently pointed to a Red Hat document containing 4 useful systemtap scripts ported from dtrace, which gives me a good occasion to explain the issue at hand with the first of these scripts. This script attempts to track I/O by following read() and write() system calls. Which is not tracking I/O, it is merely tracking some system calls (Taras script had the same kind of problem with read()/write() induced I/O). You could just do the very same with existing tools like strace, and that wouldn t even require some system privileges. To demonstrate the script doesn t actually track the use of storage devices as the document claims, consider the following source code:

#include <fcntl.h>
#include <sys/stat.h>
#include <unistd.h>
/* Ensure the resulting binary is decently sized */
const char dummy[1024 * 1024] = "a";
int main(int argc, char *argv[])  
  struct stat st;
  char buf[65536];
  int i, fd = open(argv[0], O_RDONLY);
  for (i = 0; i < 100000; i++)  
    read(fd, buf, 65536);
    lseek(fd, 0, SEEK_SET);
    read(fd, buf, 65536);
    lseek(fd, 512 * 1024, SEEK_SET);
   
  close(fd);
  return 0;
 

All it does is reading some parts of the executable a lot of times (notice the trick to make the executable size at least 1MB). Not a lot of programs will actually do something as bold as reading the same data again and again (though we could probably be surprised), but this easily points the problem. Here is what the output of the systemtap script looks like for this program (stripping other unrelevant processes):

         process     read   KB tot    write   KB tot
            test   400002 25600001        0        0

Now, do you really believe 25MB have actually been read from the disk? (Note that the read() count seems odd as well, as there should only be around 200000 calls) Read-ahead, page cache and mmap() What the kernel actually does is that a read() on a file is going to check the page cache first. If there is nothing corresponding to the read() request in the page cache, then it goes down to the disk, and fills page cache. But as loading only a few bytes or kilobytes from the disk could be wasteful, the kernel also reads a few more blocks ahead, apparently with some heuristic. But read() and write() aren t the sole way a program may hit the disk. On UNIX systems, a file can be mapped in memory with the mmap() system call, and all accesses in the memory range corresponding to this mapping will be reflected on the file. There are exceptions, depending on how the mapping is established, but let s keep it simple. There is a lot of litterature on the subject if you want to document yourself on mmap(). The way the kernel will read from the file, however, is quite similar to that of read(), and uses page cache and read ahead. The systemtap script debunked above doesn t track these. I ll skip write accesses, because for now, they haven t been in my scope. Tracking some I/O with systemtap What I ve been trying to track so far has been limited to disk reads, which happen to be the only accesses occurring on shared library files. Programs and shared libraries are first being read() from, so that the dynamic linker gets the ELF headers and knows what to load, and then are mmap()ed following PT_LOAD entries in these headers. As far as my investigation in the Linux kernel code goes, fortunately, both accesses, before they end up actually hitting the disk, go through the __do_page_cache_readahead kernel function (this function was tracked in Taras script). Unfortunately, while it is called with an offset and a number of pages to read for a given file, it turns out the last pages in that number are not necessarily being read from the disk. I don t know for sure, because the latter had an effect on my observations, but some might even already be in the page cache. Going further down, we reach the VFS layer, which ends up being file-system specific. But fortunately, a bunch of (common) file-systems actually share page mapping code, and commonly use the mpage_readpage and mpage_readpages functions, both calling do_mpage_readpage to do the actual work. And this function seems to be properly called only once for each page not in the page cache already. If my reading of the kernel source is right, this however is not really where it ends, and do_mpage_readpage doesn t actually hit the disk. It seems to only gather some information (basically, a mapping between storage blocks and memory) that is going to be submitted to the block I/O layer, which itself may do some fancy stuff with it, such as reordering the I/Os depending on other requests it got from other processes, the position of the disk heads, etc. And when I say do_mpage_readpage doesn t actually hit the disk, I m again simplifying the issue, because it actually might, as there might be a need to read some metadata from the disk to know where some blocks are located. But tracking metadata reads is much harder, and I haven t investigated it. Anyways, skipping metadata, going further down after do_mpage_readpage is hard because it s difficult to back-track which block I/O is related to which read-ahead, corresponding to what read at what position in which file. do_mpage_readpage already has part of this problem because it is not called with any reference to the corresponding file. But __do_page_cache_readahead is. So knowing all the above, here is my script, the one I used to get the most recent Firefox startup data you can find in my last posts:

global targetpid;
global file_path;
probe begin  
  targetpid = target();
 
probe kernel.function("__do_page_cache_readahead")  
  if (targetpid == pid())
    file_path[tid()] = d_path(&$filp->f_path);
 
probe kernel.function("do_mpage_readpage")  
  if (targetpid == pid() && (tid() in file_path))  
    now = gettimeofday_us();
    printf("%d %s %d\n", now, file_path[tid()], $page->index*4096);
   
 
probe kernel.function("__do_page_cache_readahead").return  
  if (targetpid == pid())
    delete file_path[tid()];
 

This script needs to be used with a command given to systemtap, with the -c option, such as in the following command line:

# stap readpage.stp -c firefox

Each line of output represents a page (i.e. 4,096 bytes) being read, and contains a timestamp, the name of the file being read, and the offset in the file. As discussed above, do_mpage_readpage is not really the place the I/O actually occurs, so the timestamps are not entirely accurate, and the actual read order from disk might be slightly different, but it still is a quite reliable view in that the result should be reproducible with the same files even when they re not located on the same blocks on disk, and provided their page cache status is the same when starting the program. This systemtap script ignores writes, as well as metadata accesses (including but not limited to inodes, dentries, bitmap blocks and indirect blocks). It also doesn t account accesses to files opened with the O_DIRECT flag or similar constructs (raw devices, etc.) Read-ahead in action Back to the small example program, my systemtap script records 102 page accesses, that is, 417,792 bytes, much less than the actual binary size on my system (1,055,747 bytes). We are still far from the 25MB figure from the other systemtap script. But we are also far from the 128KiB the program actively reads (64KiB twice, leaving a hole between the two blocks). At this point, it is important to note that the ELF headers and program code all fit within a single page (4 KiB), and following the 1MiB section corresponding to the dummy variable, there are only 5,219 bytes of other ELF sections, including the .dynamic section. So even counting everything the dynamic linker needs to read, and the program code itself, we re still far from what my systemtap script records. Grouping consecutive blocks with consecutive timestamps, here is what can be observed:

Offset	Length
0	16,384
983,040	73,728
16,384	262,144
524,288	65,536

(By now, you should have guessed why I wanted that big hole between the read()s ; if you want to reproduce at home, I suggest you also use my page cache flush helper) As earlier investigations showed, the first accesses by the dynamic loader are to read the ELF headers and .dynamic section. As mentioned above, these are really small. Yet, the kernel actually reads much more: 16KiB at the beginning of the file when reading the ELF headers, and 72KiB at the end when reading the .dynamic section. Subsequent accesses from the dynamic loader are obviously already covered by these accesses. Next accesses are those due to the program itself. The program actively reads 64KiB at the beginning of the file, then 64KiB starting at offset 524,288. For the first read, the kernel already had 16KiB in the page cache, so it didn t read them again, but instead of reading the remainder, it reads 256KiB. For the second read, however, it only reads the requested 64KiB. As you can see, this is far from being something like you wanted n KiB, I ll read that fixed amount now . Further testing with different read patterns (e.g. changing the hole size, read size, or reading from the dummy variable directly instead of read()ing the binary) is left as an exercise to the reader.

The meeting agenda is already posted for tonight s (Wednesday s) SPI board IRC meeting which will be at 2030 UTC in #spi on irc.oftc.net. I m sorry it s pretty late notice, but you might like to come along and let the board know what you think they should be doing, or offer to help out with the new website.

After previous series of posts about Gammu usage in proprietary software, finding culprit and getting the sources I got number of questions and suggestions. So what are the suggestions? Lesson I've learned is that even though the website seems to be dead, the project itself does not have to be. This is what I thought about http://gpl-violations.org/ and I was proven wrong and these guys are now looking at my case. Another option is Software Freedom Law Center - http://www.softwarefreedom.org/. I've contacted them from the very beginning (about year ago) and got some useful hints, though now my contact seems to be gone (or simply too busy). FSF also provides information how to proceed in case of license violation. Maybe these hints will be also useful for somebody else and I hope they will help me as well.

Filed under: English Gammu Gpl 0 comments Flattr this!

I ve just been playing with icmptx, a system for tunneling IP over ICMP Echo which could be handy if I ever find myself blocked by firewalls. Unfortunately the documentation is lacking. Below is a sample configuration that works for me, all you have to do is to put the correct IP address in for SERVERIP in both scripts and it should work. I m not sure what the ideal value for the MTU is, 65535 is the largest possible. For transmission it usually won t make any difference as the occasions when I need such things will usually be download-only sessions and the ACK packets will be quite small. For receiving data the server has an MTU of 1500 on the Ethernet port so nothing bigger than that will come in. Presumably when downloading data the packets will be transmitted in two ICMP fragments.One interesting feature of the program is that it doesn t match requests and replies. I presume this is because any firewall that only allows one reply per echo request will probably ensure that the reply contents match the request contents, so they just assume that a firewall will let all ICMP echo/reply traffic through. The upside of this is that it should give lower round trip times than any tunneling system that polls for return data.I ve filed some Debian bug reports about it, bug #609413 is a request for it to set icmp_echo_ignore_all when it s running and also emulate the regular PING functionality. Bug #609412 is a request for it to assign the IP address to the tun0 interface. Bug #609414 is a request for the server side of it to call daemon(0,0).I won t leave this running. Having to run a virtual server with the regular ICMP functionality disabled is too much effort for the small benefit that using ICMP tunneling may offer over DNS tunneling.My configuration scripts (with the IP address removed) are below.ConfigurationServer#!/bin/sh
set -e
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
icmptx -s SERVERIP &
sleep 0.5
ifconfig tun0 mtu 65535 10.10.10.1 netmask 255.255.255.0Client#!/bin/sh
set -e
killall icmptx true
icmptx -c SERVERIP &
sleep 0.5
ifconfig tun0 mtu 65535 10.10.10.2 netmask 255.255.255.0
wait

So David Watson and Michal iha are doing Project 52 this year? Well, lemme in ;)Actually, me and some friends were doing so the last year already and we will to continue this year too. We re calling it wir knipsen! which translates into English as we snap! .This week my contributions look like this:
Yepp, these are three images as these are our rules: three pictures every week :)Hope you enjoy them and don t forget to have a look at the other pictures at wirknipsen.de.

I just got inspired by David Watson and will try the same challenge. I find it interesting to take and publish one photo every week, but I'm not really sure if I will last. First week photo is from Sun Eclipse few days ago, though it is not much visible :-).

Filed under: English Photography 3 comments Flattr this!

After finding that Sonim's software uses GPL licensed Gammu, the obvious step was to ask them for sources of the software. They quickly transferred their responsibility to company which made software for them - A&W (Anwsoft). It took some iterations to explain them that I'm pretty sure that their software is based on Gammu and finally they gave up pointing to some external contributor for being guilty of this:

Due to the product was developed years ago, and the source code was bought from a SOHO programmer on the first beginning, so we didn t notice it included some open source code inside.

The good thing in the same thing was that they were willing to cooperate:

We are willing to cooperate with you to follow GPL License and provide corresponding sources.

As it turned out in upcoming communication, they didn't have (and still don't have) idea what GPL license contains and what they should publish. But that's story for the next post.

Filed under: English Gammu Gpl 0 comments Flattr this!

As some of my readers may now, I'm a regular user of public transport. Even though I'm living in an area (far suburbs of Paris) where the use of cars for nearly everything is common, I managed up to now to not use my car for my daily commute. I was using the public bus line of our town, that starts close from our house and ends up at the local train station where I can commute to U line of Paris transport system (then C line, then another bus ride). You can compare this complicated 1h30 travel to the 35 minutes drive I would have if I was using my car. I *was*. I'll stop from tomorrow. The reason is simple: my U train start hour is 6h57. The bus formerly started at 6h36, then reached the train station at 6h51, which was a quite good commute. That made me leave our house at about 6h25, considering a 10min walk from the house to the bus stop. That's 32 minutes for....3 kilometers. Already needs some motivation, right? This changed today (with minimal notice). To catch the same train, I should have a bus at 6h31, thus leave 5 minutes earlier, so *nearly 40 minutes before the train schedule*. Considering that driving from our place to the train station is about 12 minutes, the deal is now made. I'll stop being the only non captive person using the bus in our neighbourhood (all others are people who can't use a car). So much for environment, etc. This is an 'interesting' way to understand why it is so easy to discourage proper use of public transport and minimize the impact on environment. A small change can lead to such effects. Of course, as you may expect, I won't stop there. Letters to the (public-funded) bus company and people in charge of public transport in our city (the bus line deficit is funded by the city), will follow very soon. Tehre are indeed many other reasons why people don't use our local buses that much. One being that, even though there are 2 trains every 15 minutes leaving the station (U and N lines), both alternated with a 7.5 minutes interval....there is only one bus every 15 minutes....on each bus line. Sometimes, even, you don't know why, there's a 23 minutes gap. Imagine waiting for your bus for more than 20 minutes at night in winter...when you're about 2-3 kilometers away from your home... Sure, that would need a lot of funding to have a really convenient system. But how about spending the billions of euros spent in super-highways, toll tunnels, etc., in public transport infrastructure? Funding my local bus line to have 2 buses every 15 minutes at peak hours would cost about the price of 100m of a 3-lane highway, for one year. Make the deal. (All that will indeed reinforce my backup system : run from my house to the train station, for 3km and 15 minutes...which involves another run at the end of my train ride, for 4km and 20 minutes. That, however, involves some "logistics" organization to be sure that I don't spend the day working in my stinking running suit. That also means up to 56km run every week, which I can't always do, particularly if I plan a race for the next week-end!) Another side effect: I will have less time for Debian as my bus commutes were used for hacking, while it will be much more difficult when driving my car to the train station, isn't it?