As Internet-connected people, we tend to interact with a lot of people who aren't necessarily geographically co-located. Hence today's cool little program I found: gworldclock. You pick an arbitrary number of timezones to have in your list, and the current time in all of them is displayed in a neat list, quietly ticking away regularly. Small? Yes. Trivial? Getting close to it. Really Useful? You betcha. It also has a very tidy 'rendezvous' mode, where you choose a time, a timezone (from your list of selected timezones) and it shows the corresponding time in all of your other chosen timezones. Again, something that 20 minutes of coding will probably produce, but the whole point of this open source thing is not having to re-invent the wheel... The 'g' does indicate a GTK application, but there is a kworldclock for people who wouldn't be seen dead with a GTK application on their desktop, and a console-only version, tzclock, for anyone who lives the text-mode life.

My. That's a mouthful of a title. I went to this event on Friday, which was run by OpenIsland. I don't really think I was the target audience; I'm already a convert and aware of the opportunities which Free Software offers. However, there were a few bits of interest to me. Brian Doran, director of the Southern Regional College talked about including discussion of Open Source in their computer related courses. He didn't commit to more use in the colleges' IT infrastructure (and indeed Netcraft reports the website as being hosted by a Win2k3/IIS combo), but it's still a significant step forward IMO - rather than just being spoon fed MS based product people will hopefully be encouraged to think about the options available and evaluate them on their merits. We'll see if it pans out in practice. Also notable was Reg Empey, NI Minister for Employment and Learning, giving a speech involving Open Source. It got hijacked into discussion about how they were going to invest in higher education in NI and fund more PHDs in a targeted manor, but I still think the fact that a member of the NI Assembly got up and used the words Open Source (or possibly Free and Open Source Software; I can't remember exactly which speaker used that once a sentence) is quite incredible. Whether or not he's fully aware of it, someone on his staff must have done some research, and decided that it was something government was prepared to think about, or at the very least not boycott. During the day I realised that I'm prejudiced towards Free Software. I'm not sure if this is a good thing or not. I will, in general, accept slightly less functionality as long as the Free option fulfils my primary needs. And I've got used to hanging around with people who also work this way, or at the very least consider Free Software on a level playing field with proprietary stuff. I was reminded that a lot of people work the other way; either they're not aware of the Free alternatives, or they view them with a natural suspicion. So it was really good to see people standing up and talking about how they'd built their businesses on Free Software, and even better, about how they were pushing back upstream fixes/features they'd needed as part of their business. I don't know if anyone in the audience was converted, but it's certainly the sort of thing I like to see - it's important to appreciate that as well as Free Software being a great resource, it's also often beneficial to share any changes you make from a business point of view, as it tends to make things easier for you in the long run. Hopefully the conference did some good in terms of making people aware of Free Software (well, mostly Open Source was talked about, but both got mentioned). I wasn't convinced that there was a need, but having talked to various people I think it's just that I have got used to being surrounded by converts and perhaps lost sight of the fact that there are still plenty of people out there who aren't yet giving Free Software a chance. There are plans for this to be an annual event, so I look forward to the next one (and I think there will be various more targeted meetings over the next year too; I know there was considerable interest in covering the use of Free Software in health).

Well I've had a busy weekend, but I'm sober now. I made a new release of xen-tools, which has a couple of minor bugfixes and not much else. I also released a new update for Debian of the xen-shell which fixes a couple of bashisms. Finally I've managed to sign up two new users to my anti-spam proxy. Hopefully they're very happy. In real news I painted about 1 square meter of my flat, (we're now into week three of painting a single room...), and replaced five light bulbs:

My eyes! The goggles do nothing!

Now I need to install a request tracking system (otrs2) and catch up on significantly outstanding RT status updates. I'm getting hopeless again. Maybe I should just give it all up and become a plumber. Plumbing is easy: Water goes downhill. The rest is just regulations and a willingness to get dirty...

Finally I was able to open the registration for DebConf8 and send the Call for Papers. For the full details please read the whole mail. We had a lot of work in the last few weeks to make this possible, as we set us the goal “We will keep all data entered last year, people won’t have to enter that again”. And we made it! It wasn’t all that easy to do, as we switched from the old 0.2.10 version of Pentabarf to the more recent, completly rewritten 0.3.9 release of it. Which had a completly new database schema, making the database upgrade a fun task, having had a lot of changes for our own data… After Mark and Stephen finished the database it was my task to get all the changes to the interface back which we had done. Which took about a week longer than I expected it, unfortunately delaying the CfP about 4 days. But hey, the new code is way better now. The actual difference between us and plain upstream is about 30% of that with 0.2.10. Which is nice. Of course we still miss a few things, but those aren’t important for the CfP and will be readded soon. Some of those features also will be sent (and most possibly merged) upstream. A big thanks go to Mark (mhy) Hymers and Stephen (sgran) Gran who did the database upgrade (keeping all our own data in it!) and to upstream who did help me out multiple times to get this running. (Yes, this stuff is also the reason why NEW got that huge again. No worries, I will fix that this weekend, shouldn’t take more than one or two “NEW-sessions”).

Our Dear Leader Sam Hocevar has previously blogged about PIC and inline ASM. Today I came across a sort of extension to this problem. Consider the following code, which implements a double word compare and swap using the x86 cmpxchg8b instruction (for a bonus you can lock it to make it atomic). This type of CAS can be used to implement lock-free algorithms (I've previously blogged about that sort of thing). The problem is that the cmpxchg8b uses the ebx register, i.e. pseudo code looks like: PIC code reserves ebx for internal use, so if you try to compile that with -fPIC you will get an error about not being able to allocate ebx. A first attempt to create a PIC friendly version would simply save and restore ebx and not gcc anything about it, something like: Unfortunately, this isn't a generic solution. It works fine with the PIC case, because gcc will not allocate ebx for anything else. But in the non-PIC case, there is a chance that ebx will be used for addr. This would cause a probably fairly tricky bug to track down! The solution is to use the #if __PIC__ directive to either tell gcc you're clobbering ebx in the non-PIC case, or just keep two versions around; one that saves and restores ebx for PIC and one that doesn't.

With pristine-tar version 0.5, I've added a new feature: The ability to easily inject enough information into a git repository so that a pristine tarball can later be regenerated from that repository. If a package's upstream branch contains the upstream source corresponding to the tarball to be imported, it's very simple to use.

joey@kodama:~/src/fbreader> pristine-tar commit ~/lib/debian/unstable/fbreader_0.8.12.orig.tar.gz 
pristine-tar: committed fbreader_0.8.12.orig.tar.gz.delta to branch pristine-tar

Otherwise, you also have to specify a tag (or any tree-ish really) where the upstream source can be found.

joey@kodama:~/src/fbreader> pristine-tar commit ~/fbreader_0.8.9.orig.tar.gz upstream/0.8.9
pristine-tar: committed fbreader_0.8.9.orig.tar.gz.delta to branch pristine-tar

Here's what it puts in the pristine-tar branch that it creates. In this example, the delta files are 40-some kilobytes, which is much nicer than if I'd had to check the 2 megabyte tarballs into git directly.

joey@kodama:~/src/fbreader> git checkout pristine-tar 
Switched to branch "pristine-tar"
joey@kodama:~/src/fbreader> ls -l
total 104
-rw-r--r-- 1 joey joey 46583 Jan 31 21:26 fbreader_0.8.12.orig.tar.gz.delta
-rw-r--r-- 1 joey joey    40 Jan 31 21:26 fbreader_0.8.12.orig.tar.gz.id
-rw-r--r-- 1 joey joey 45267 Jan 31 21:26 fbreader_0.8.9.orig.tar.gz.delta
-rw-r--r-- 1 joey joey    40 Jan 31 21:26 fbreader_0.8.9.orig.tar.gz.id

Don't forget to push the pristine-tar branch to your server for safekeeping.

joey@kodama:~/src/fbreader> git push origin pristine-tar

Once a tarball's delta is checked in, you can easily and quickly regenerate the original tarball.

joey@kodama:~/src/fbreader> pristine-tar checkout ../fbreader_0.8.12.orig.tar.gz
pristine-tar: successfully generated ../fbreader_0.8.12.orig.tar.gz

Yes, it's really the same file. :-)

joey@kodama:~/src/fbreader> md5sum ~/lib/debian/unstable/fbreader_0.8.12.orig.tar.gz ../fbreader_0.8.12.orig.tar.gz 
8045abe1acc75dbdd220400df541f23f  /home/joey/lib/debian/unstable/fbreader_0.8.12.orig.tar.gz
8045abe1acc75dbdd220400df541f23f  ../fbreader_0.8.12.orig.tar.gz

The above example is from the perspective of a maintainer of a Debian package. But this can also be used by the authors who generate the pristine tarballs in the first place. Check them into git using pristine-tar. Then you can regenerate any tarball you've ever released using just your project's git repository.

joey@kodama:~/src/pristine-tar> pristine-tar commit ../pristine-tar_0.5.tar.gz tags/0.5
pristine-tar: committed pristine-tar_0.5.tar.gz.delta to branch pristine-tar

One word of warning: For pristine-tar to check out the tarball, git needs to be able to check out the tree that you referred to when you committed it in the first place. If that was a tag that you've told git to delete, you're SOL. If it was a branch and the branch has changed in the meantime, that's fine, so long as git can find the original id that is stored in the .tar.gz.id file.

---

I hope that tools like git-import-orig and git-debimport can get support for automatically calling pristine-tar commit when importing tarballs into git, and that tools like git-buildpackage and gitpkg can use it to check out the tarballs.

If you try using some of my software, or any software come to think of it, and it doesn't work, or causes you problems then there is a simple solution. Tell me. I might not be able to fix it immediately, I might not ever be able to fix it. But chances are I can, and if there is a record it'll help others out in the future regardless. I've bumped into this in the past "Oh yes I tried to use that tool you wrote but it didn't work, so I ended up with something else."

It seems that my blogging contest idea is a failure. Could the interested people please meet me near the LCA registration desk at the start of the lunch breakh today for a post-mortem. Any last-minute entries can be submitted by telling me the URL then.

Share This

On Sunday, the day before LCA 2008 officially started, Kelly and Rusty asked us first-timers to blog about events, specifically about what we liked and disliked. So far, this conference has been really enjoyable and busy, and I have not found the time to write about its content. The talk I just heard leaves me without an excuse, so there: I have recently had a very interesting and enlightening discussion with a blind Debian developer. When I saw on the conference schedule that Jason White would talk about using Linux with speech and Braille output interfaces, I passed up my opportunity to hear Andrew Tridgell talk about clustered Samba and attended his lecture instead. Jason covered a great number of aspects: from the history of the Braille system, and current, Free implementations thereof, via speech output, to strategies of integrating these techniques into existing programmes which are generally not designed with visually-impaired users in mind. He has a collection of references on his webpage, to which I shall refer for the technical content. His presentation left me very excited and impressed. Excited to see him giving a presentation with such enthusiasm and energy, and impressed because his talk (without notes or slides) was by far better than the job of the average presenter with access to notes and slides to display. Jason conveyed a lot of information in a very well-structured, capitivating report. I think he left most of the audience speechless (figuratively speaking; there were good questions). I feel uneasy with thanking Jason explicitly, or even writing this blog post. If you bear with me for a minute, then let me bridge to women involvement in open-source software. My position on this topic is quite clear: I make no distinctions where they are not obvious, and simultaneously I think it s awesome that more and more women are joining the predominantly male crowd (and their influence undeniably makes the community a more comfortable place). Every now and then, I would like to comment on that, such as I think it s awesome that you are working on this, being a woman (an oversimplified example). What I am trying to say is given how few women are involved with OSS, I appreciate all the more what you are doing. This is non-judgemental, I don t say this because I am trying to highlight someone s gender or sex. It s a communication issue, and I am learning, but I d also rather not limit what I say by making absolutely sure never to offend anyone. But when I utter such a comment, it might still greatly annoy someone or yield vicious returns. This is not always the case in fact, less than it used to be but I ve encountered it here and there, which made me more careful. So when I write about Jason s presentation and how great it was, I want to highlight how it s a greater achievement for him than it would be for me, because he is blind and I am not. I don t mean to single him out or put him on the spot. I am simply impressed, very impressed. And being who I am, I d like to say so. Thanks, Jason. Update: David Schmitt makes an interesting point:

The important question is now, why are we blind people doing great presentations more impressing than people with working eyes doing a great presentation? My personal answer isn t so great: because I didn t expect it. No wonder people get offended if you tell em to their face that I m impressed with his achievements, because I wouldn t have expected it.

I don t agree, or at least I fail to see it. I was impressed, I did not expect it (which isn t to say that I came in to Jason s talk expecting it to be any less than a good talk, I had no expectation! Please think for a second if this isn t immediately clear!) is that offensive? I didn t know Jason, had no way to know whether his presentations are great or less so, but then he pretty much blew me away. The presentation was better than what I am used to (from anyone), and the achievement is all the more greater because it seems to me that he has had to put much more effort into it, purely for accessibility reasons. I guess I should know better, but I still, after all these years, have a problem seeing through the end of it, understanding it. Kant to the rescue, my intentions are good (I claim), but this goes both ways regardless: in any communication, one ought to try hard never to offend. At the same time, one ought to try hard not to be offended until one can be reasonably sure that offence was intended. When I brought this up in Adaora Oniya s miniconf talk on communication challenges, Bdale Garbee recalled the policy in use when he was involved in protocol design work groups: send politely, receive with an open mind. I don t remember his exact words, but I think I got the gist. Update: I just talked to Jason and got his feedback on the issue. It boils down to a quote I ll transcribe: I want my work to be judged by its merit and not by who I am. It only leaves me wondering about the situation at hand: I was impressed by his very well-structured and presented talk and by the fact that he did such a good job given his visual impairment. In any case, I ll close the issue. Jason told me he d happily engage in further discussion and I stated that he is not offended. There is another lesson I learnt: the next time I blog about someone else in such a way, I should really get his/her clearance before publishing! Just to be sure

On January 26th 2008, the OCaml community has its first meeting in Europe. There was 5 different talks, including one from me. The meeting was pretty constructive and i think some great things should come out of it. In this post, i will focus on the Debian maintainer point of view. The meeting was organized by me, with the help of Garbriel Kerneis and Vincent Balat. I wish to thank Mme Turgis from ENST/ParisTech who has made possible all this to happen. Introduction: I announce the creation of OCamlCore, a SS2L. It will provide commercial support for OCaml and related products. It will also provide community with some resources (including a GForge, a planet, some SCM repository...) For now, i will open administration to Debian people who wish to help (for root rights) and from the whole community for other task (gforge and general administration). For now, i will choose alone who can administrate and who cannot... This is not a very open position, but this server is also for my company. Xavier Leroy give us a nice talk that has let us see some future direction:

• OCaml 3.11 will have native dynlink
• hope to integrate GHC like type system (GADT: Generalized Algebraic Data Types)
• need to work on parallelism, following different paradigm

But above all, Xavier talked about the fact that there is a lack of manpower at INRIA and invited the community to build tools and other things (including a CPAN like distribution) to make the language more widespread. He also stated that a lot of things will stay in place in the name of backward compatibility. OCsigen Vincent Balat has given us a nice talk about OCsigen, a new framework for programming web application. This program is already in Debian and it is at the root of Debian discussion about moving .cm[ao] into libxxx-ocaml package. This new framework allows to program web application using continuation, which should ease a lot of aspect. It also features static type checking, including static verification of the generated HTML pages. GODI I was impressed to see G. Stolpmann coming to the meeting. Unfortunately, i cannot follow the whole talk, since i have some phone call to make, in order to book the restaurant. From what i have seen, it seems that GODI is growing, in term of manpower. They have some issues with OCaml 3.10, because of camlp4 and some packages. At the end of the conference, he was pushing for a more general use of GODIVA. In particular, it requires to have a very uniform way of building software. It should be the foundation of a build standard for OCaml software. In my humble opinion, i don't agree on this point. Basically, its proposal was based on configure/make all, which is too C style way of doing. It is not bad, but just exclude ocamlbuild enabled software. ocamlbuild Nicolas Pouillard has made an introduction on how to use ocamlbuild. I have discovered how it was working, since i didn't have time to work on this topic. It seems a good thing. I hope to be able to try it at some point. The conclusion was about modifying ocamlbuild to allow the use of multiple plugins. For now, the plugin is a separate file which is compiled first and then loaded, as a special case. Nicolas is looking for a full OCaml way to handle this for multiple plugins. OCaml in Debian I have spoken about different aspect of Debian packaging. After a short introduction and some history about OCaml in Debian, I come to some conclusions/problems:

• we have an early integration, which makes Debian handle a lot of packages, but this is due to a long history
• we still are not able to cope with libraries incompatibilities when rebuilding, we only have addressed ocaml package ABI problem
• the debian package management system is not really compliant with the OCaml way of creating libraries, which is our main problem
• native compilation is broken on 3 arches (Xavier Leroy told us that this should be solved for ARM)
• use of Alioth has made us more efficient to integrate packages
• Debian team are working by step: from time to time we begin to integrate a lot of packages, mostly because of some maintainers wishing to integrate a software with a lot of dependencies

Talking with Xavier give me some additional informations:

• ARM is fixed, it should compile with Debian stable on ARM, he explains that the problem is related to the multi ABI flavor of ARM
• he says that we should not have any problem concerning bytecode stripping of executable, if there is still some we should find the OCaml library that triggers this behavior
• I realize that this behavior can be triggered by ocamlmakefile, that still have a "-custom" option
• he promises me that he will send me a simple test to find custom bytecode application (combination of "file X" and a specific string at the end of the file)

At the end of the presentation, there were some questions. I discover that many people are ignoring the ABI problem with OCaml and its libraries. They seem to discover that it requires regular rebuild of our packages. I also have a discussion about the fact that Debian binary distribution doesn't fit developers need. It seems that developers prefer to have the source of libraries they compile and also the most recent release. But at the same time, people avoid using GODI, which also have the problem of needing to wait for a particular library to be released... After some discussion, I point that some companies prefer to live in a frozen world, which Debian stable can provide. Living in a frozen world helps company developers to have the same environment from the beginning to the end of a project - which can last years. It also help to avoid build environment de-synchronization between company developers. There was also a question about interaction between installed OCaml package and GODI software. I cannot answer it, expect with a "patches are welcome". OCaml on a JVM using OCaml-Java Xavier Clerc explained us how he has achieved running a full OCaml environment on a JVM. This work was pretty impressive, because he was able to compile OCaml top level and provide it as an applet. This is something amazing (and working). He stated also that this should allow to do some binding with java graphical user interface from OCaml. I was pretty busy with a phone call (to a restaurant for the dinner), so i don't have attend the whole conference. Anyway, the project is promising, but it needs to recompile every library using its compiler. I think this is not suited for Debian for now. Workshop The workshop was shorter than it should have been. This is due to accumulated time shift during the day. However, it was pretty interesting, because everybody can talked almost freely. The initial discussion was about the "Unicode situation". This was a question about Unicode in Unison, but there is no real solution about it. For reader information, unison has problem with filename containing UTF-8 char. In particular when syncing two directories which are on two file system with a different encoding on each. Even if the file can be represented on the two file systems, the comparison (between UTF-8 and ISO8859-15) fails. This is because the comparison is a byte to byte comparison. We discuss further the idea of OSR (OCaml standard recommendation) which was briefly discussed in the morning. I think David Teller (who have also done a great part of the IRC retranscription) was very keen on this idea. I invited Nicolas Pouillard to discuss the three following subjects. About camlp4 documentation, Nicolas told people about the he set up. About ocamlfind and ocamlbuild, he went back to the multiple plugin problems. About ocamlbuild and GODI, Gerd, Nicolas and Xavier tried to build a list of what metadata can be shared. This includes list of files to be installed (PLIST in GODI). Concerning the "feedback from the Gallium", Xavier explains that he has done this in the morning (which is true). I think that Xavier implicitly agreed on the fact that if this kind of event happens again, he can do another talk about future of OCaml. Concerning Summer of Code, I just remind that people can write description of Google Summer of Code project in the cocan wiki. Another one remind about Jane St Capital summer of code. Points concerning common interfaces raise the discussion about OSR. The organization of next year events doesn't raise particular interest. I think people would be interested to have one next year, if something comes out of this meeting.

My previous post about my LCA mini-conf talk received an interesting comment from Christopher Neugebauer. He said that he had some trouble understanding me because I speak quickly, he wasn’t the first person to make that complaint (it’s the most common complaint I receive). If a talk goes well then I have a lot to say and little time to say it and end up speaking quickly if I don’t concentrate enough on speaking slowly. If a talk doesn’t go well then I get nervous and speak quickly. When a speaker talks too quickly it is appropriate to call out a request for them to speak more slowly. I know I’m not the only person who has difficulty in speaking slowly enough and I expect that others also wouldn’t mind such requests from the audience. Chris suggested giving a talk with a small number of words used on the projector, it’s an interesting idea and may be worth a try. However I have recently watched Lawrence Lessig’s talk published on TED.com [1] which used that technique, I was disappointed in the result. His talk appeared to be very well received by the audience, I’m not sure whether that is because the audience was less familiar with his ideas than I am or whether it’s a technique that works better for an audience than for a video. I would appreciate further suggestions in this regard. Update: It’s interesting to note that Bruce Schneier’s keynote for LCA had no presentation material, he spoke from written notes.

• [1] http://www.ted.com/index.php/talks/view/id/187

Share This

Due to the lack of entries so far I am amending the rules. It is no longer required that an entry be on the blog of the person who submitted it. Being on any blog that is aggregated by the conference Planet will do. This is known as a “guest post“. All it requires is that you email the post content to a blogger who you trust and they post it crediting you as the author. Guest posts are fairly common among serious bloggers, a google search will surely give more information.

Share This

Apparently, the task scheduler in all Windows NT-derived versions up to (and including) Windows Server 2003 cannot run jobs under the "NT Authority\Network Service" security principal; "NT Authority\System" is the only so-called well-know security principal that can be used with it. Support for running tasks as "Network Service" or "Local Service" was only added in Task Scheduler 2.0, which is the version that ships with Vista and will be also included in Windows Server 2008.

Side note: I wonder why the link above, being a command reference for an administrative tool, is on the MSDN and not on the Technet site.

Practical implication is that without being able to use the "Network Service" principal, a distinct network account (domain account or server account) is required for any job that needs to access any network resource. This also means keeping track of another account and password — and taking care of controlling and auditing it's access; whereas the "Network Service" principal cannot normally be used for interactive sessions.

Annoyingly, the task scheduler UI also does not tell you that you can't if you try, but rather gives the un-helpful message "Access is denied. You do not have permission to perform the requested operation".
The same message is also shown when, for a regular account, the password entered does not match the actual account password. (This happened to me because the keyboard layout on a remote desktop session turned out to be not what I thought it was)
Anyone know if the error reporting has improved anything in the new task scheduler?

Apparently, the task scheduler in all Windows NT-derived versions up to (and including) Windows Server 2003 cannot run jobs under the "NT Authority\Network Service" security principal; "NT Authority\System" is the only so-called well-know security principal that can be used with it. Support for running tasks as "Network Service" or "Local Service" was only added in Task Scheduler 2.0, which is the version that ships with Vista and will be also included in Windows Server 2008.

Side note: I wonder why the link above, being a command reference for an administrative tool, is on the MSDN and not on the Technet site.

Practical implication is that without being able to use the "Network Service" principal, a distinct network account (domain account or server account) is required for any job that needs to access any network resource. This also means keeping track of another account and password — and taking care of controlling and auditing it's access; whereas the "Network Service" principal cannot normally be used for interactive sessions.

Annoyingly, the task scheduler UI also does not tell you that you can't if you try, but rather gives the un-helpful message "Access is denied. You do not have permission to perform the requested operation".
The same message is also shown when, for a regular account, the password entered does not match the actual account password. (This happened to me because the keyboard layout on a remote desktop session turned out to be not what I thought it was)
Anyone know if the error reporting has improved anything in the new task scheduler?

...install a Babelbox, de-activate the "db_info babelbox/info" line in preseed_early and put the following in big capitals on a sheet of paper attached to the monitor:

BABELBOX CONTEST
Guess what language is used to install
that Debian system.

...and wait for the crowd to slowly gather around the box and start guessing. If you can offer stickers pins CDs to winners, that's even better. Hint: do not activate easy to guess languages. Good candidates (apart from all non Latin ones which are all *very* hard to recognize for the regular French geek, except maybe Japanese) are Hungarian, Basque, Slovenian. Arabic is too easy to recognize and so is Greek. Indic languages are a great success but Dzongkha is generally the winner. Hint 2: do not sort languages alphabetically by locales. Geeks are too smart and the geeks manning the booth will learn too quickly. Watch also people trying to switch to a console during the D-I runs and typing "cat /proc/cmdline". Hint 3: train yourself to recognize the languages before the contest so that you look clever... That worked pretty well during 1st day of Solutions Linux.

I speculate that most of what we do for Debian squares with what others do for their respective distro. Thus, it should be possible to identify a conceptual workflow applicable to all distros, consolidate individual workflows on a per-package basis, and profit from each other. Jonathan let me have the after-afternoon-coffee slot of the Distro Summit for an impromptu discussion on the various workflows used by distros for packaging. The discussion round was very short-notice and despite the announcement sent to the conference mailing list, only ten people showed up: two people familiar with Fedora, and ( versus ) eight Debianites. Regardless, I think the discussion was success- and fruitful. We were able to identify a one-to-one mapping between the Fedora and Debian workflows, even though we use different techniques:

• both distros separate original software ( orig tarball ) from modifications made to fit the software in with the rest of the distro.
• Fedora keeps the .spec file, which references the original tarball, alongside any patch files in a per-release directory in their CVS tree, e.g. /mdadm/fedora8 and /glibc/rawhide. To obtain a source tree, the contributor checks out the CVS subtree, downloads the tarball according to the .spec file, and merges the two. There is a tool to automate this, obviously. This process is regularly executed to produce source RPMs .
• Debian keeps the original tarball next to a diff.gz file on the mirrors, along with a dsc file which refers to them both. Tools like dget take the URL to the dsc file to download all three, then invoke dpkg-source to unpack the tarball and apply the diff. Individual patch files are either stored in ./debian/patches/ (and applied by the diff), or they don t exist (meaning that all modifications are concatenated in the diff.gz file.

Many Debian package maintainers use version control systems to maintain the ./debian directory, and if patch files are stored in ./debian/patches/, then Debian and Fedora both store patch files in a version control repository, which seems awful. Just as I am only one of many who are experimenting with VCS-based workflows for Debian packaging, the Fedora people are also considering the use of version control for packaging. Unlike Fedora, who seem to try to standardise on bzr, I try to cater for the plethora of version control systems in use in Debian, anticipating the impossibility of standardising/converging on a single tool across the entire project. It seems that our two projects are both at the start of a new phase in packaging, a paradigm shift . What better time could there be for us to listen to each other and come up with a workflow that works for both projects? My suggestion currently centres around a common repository for each package across all (participating) distros, and feature branches. Specifically, given an upstream source tree, modifications made during packaging for a given distro fall into four categories:

• upstream changes, such as bug fixes in the original code, or simple things like manpage typos.
• (Linux) distro stuff, such as init.d scripts or Linux-ifications, which upstream doesn t care about or doesn t want.
• .deb/.rpm-specific changes, like the ./debian directory or the .spec file.
• distro-specific modifications, like policy compliance and the like.

Given a version control system with sufficient branching support, I imagine having different namespaces for branches: upstream-patches/*, distro/*, rpm/* or debian/*. Now, when building the Debian package, I d apply upstream-patches/*, distro/*, deb/* and debian/* in order, while my colleague from the Fedora project would apply upstream-patches/*, distro/*, rpm/* and fedora/*, before calling the build tools and uploading the package. There are surely problems to be overcome. Pascal Hakim mentioned patch dependencies, and I can t necessarily say with a clear conscience that my workflow isn t too complicated to be unleashed into the public yet. But if we find a conceptual workflow applicable to more than one distro, it should be possible to implement a higher-level tool to implement it. Also, the above is basically patch maintenance, not the entire workflow. Bug tracking system integration is going to play a role, as well as other aspects of daily distro packaging. I ll leave those for future time. For me, this is the start of a potentially fruitful cooperation and I hope that interested parties from other distros jump on. For now, I suggest my mailing list for discussion. You can also find some links on the Debian wiki.

AdSense patch for ikiwiki's embed pluging Today I've started playing with AdSense, mainly to check whether a typical homepage+blog web site (read: mine) can survive its hosting costs by the means of this kind of revenue or not. However I don't want the ads to be visible on all pages, but only in some of them, mainly the main blog page (which scores high in search engine results and is also not prone to the risk of bothering usual readers, thanks to---$DEITY bless them---RSS/Atom feeds) and some selected pet software project homepages. With ikiwiki implementing this appeared trickier than I expected. The main difficulty is of course the wiki-wide htmlscrubber plugin which I do not want to switch off because of discussion pages and a part of my website which is actually used as a world-editable wiki. Googling around it seems that there is an adsense.pm plugin for ikiwiki, but it is not registered in the ikiwiki plugins page; as such I was not particularly envy to try it out. Besides, the right place to add such a feature to me seems the embed plugin. ... so I've minimally patched it: see bug #462970. If you're willing to use AdSense with ikiwiki please try out the patch: since I'm an AdSense newbie it might well be I've underestimated the possible script snippets it can generate. Post comments to bug #462970.

Today I gave a talk about Debian security at the security mini-conf of LCA. Before I started the talk I asked for suggestions as to how to get more entries in my security blogging contest [0]. During the talk I asked for suggestions as to how to get more people involved in security development. One suggestion was to offer incentives. I’m experimenting with that with my blogging contest and may do future variations of the same thing. I started with describing some of the history of security in Debian (primarily things that involved me in some way): In 2003 I suggested that exec-shield be a standard feature in Debian kernel images [1]. I created a kernel-patch-exec-shield package in 2003 and Marcus Better took it over in 2004. We are hoping to get it included in Lenny. AMD64 architecture doesn’t need exec-shield as the CPU has separate write and execute bits in the page table, but it would be nice to get exec-shield included before the last P4 machine gets decommissioned. A presentation at the security miniconf at LCA 2005 on the topic of stack smashing is interesting [2]. At the time Adamantix was a distribution based on Debian which used PaX (similar to exec-shield). Adamantix has gone away. Hardened Gentoo has been available with Pax for all this time (but is not widely used). RHEL and Fedora have been available for all this time with exec-shield… In mid 2002 I demonstrated the first SE Linux Play machine at a conference in Germany. It was fully operational with root as the guest user. At that time SE Linux support in Debian was essentially complete. Since that time the scope of the SE Linuc project has increased slightly (EG controlling DBUS access) so the amount of work required for full support is greater. Most of that support is in Debian and Etch is basically working with SE Linux (although not quite as well as it was in 2002 due to lack of support for the strict policy). The aim is to have Lenny SE Linux become as functional as SE Linux in Fedora Core 5. While FC5 has more SE Linux features than the SE Linux project supported in 2002 it’s still a great disappointment that it’s taken so long. FC5 had pam_namespace to polyinstantiate directories such as /tmp. Lenny will hopefully have it. I described the current status: The hardening-wrapper package in unstable allows environment variables starting with DEB_BUILD_HARDENING_ to be used to control execution of GCC. Documented on the Debian Hardening Wikipedia page [3]. It’s still a little experimental and may change in the near future, but it works. Lucas Nussbaum is working on automatically building Debian packages with warnings for security related issues. The aim is to build all packages and maintain a central location for the logs to allow DDs to find and fix the problems in their packages. The Alioth Hardening project [4] will hopefully get some action soon (the people involved are busy doing work but not updating the project). The current plan is to base the Debian Hardening work around it. SE Linux in Debian is something that I want to get working correctly. There are still some significant issues that make strict policy unusable (such as correct labelling of /etc/passwd) as of last time I tested it. Finally I described the future plans. There were many questions about usability features for SE Linux, I mentioned in concept the features that Red Hat and Tresys people are developing (which I often don’t use as I prefer vi for policy editing). There were some questions about how SE Linux works. More than half the audience indicated that they had used it so I assumed some basic knowledge of SE Linux when describing how SE Linux works in regard to minimum privilege and the benefits of MAC in terms of limiting the scope of attack. I noted that every program has bugs and every program which performs security related tasks (which includes serving data to the net without being owned) should be assumed to inevitably have security related bugs (see the The Inevitability of Failure paper []). Based on the Twilight of the Books [5] article I decided to give this talk with no slides as an experiment. I talked from notes that I wrote and advised the delegates to read my blog for the details. Not presenting any slides meant that the room lights were all left on, which made things much easier when answering the many questions (I prefer an interactive format to my talks and have more questions than most speakers). It will be interesting to get some feedback from delegates about how they regarded this.

• [0] http://etbe.coker.com.au/2008/01/20/lca-2008-security-blogging-contest/


• [1] http://www.debian.org/News/weekly/2003/45/


• [2] http://www.linux.org.au/conf/2005/security_miniconf/presentations/smashing.pdf


• [3] http://wiki.debian.org/Hardening


• [4] http://alioth.debian.org/projects/hardening/


• [5] http://etbe.coker.com.au/2007/12/28/twilight-of-the-books/

Share This

I filed an HP support request on 22 January. On 23 January, I received the following mail: Your support request regarding,HP LaserJet 3052 All-In-One E-Mail Support, was received 1/22/2008, 9:41:14 AM. Your unique ID is 532458. A support engineer will be getting back to you, via email, within the next business day to address your issue. We appreciate your patience. By 28 January I had not heard back from them. Why do they even bother to send such auto-replies?

The first of my talks at LCA 2008 gave me a chance to talk about the current state of the Debian project, which got me my first LWN.net coverage with a photo, even (subscribers only for now, the article will become public on 7 February). Thank you, Jonathan Corbet, for a very good article which nailed all the main points! Slides are here. I agreed to this talk on short notice because I like to talk about Debian and was honoured by the chance to represent the project in this form. I would not have been able to do it without plenty of helpful input from colleagues in the last few days. Since I didn t get a chance to display the final slide with the acknowledgements during the talk, I would herewith like to thank specifically Andreas Tille, Michael Banck, Kevin Mark, Josip Rodin, MJ Ray, Cyril Brulebois, Stefano Zacchiroli, Frans Pop, Moritz M hlenhoff, Russ Allbery, Steve Langasek, Luk Class, Andreas Schuldei, and Christian Perrier. No guarantees for the completeness of the list. The talk ended in an open discussion on how Debian could improve. I took notes and shall forward them to the project mailing list, once I get a chance. Thanks to all the participants, as well. Update: during the talk, I mentioned that there was no security support around the time of the etch release. Thanks to Moritz M hlenhoff, who spotted my error: that should have been sarge . The problems with security support had long been resolved by the time etch was being prepared, and this was in (large?) part thanks to Moritz. Sorry for the screwup! I also called Linux to tend towards multimedia more than one might like. I should not have made this comment as a representative of the Debian project, and I probably did unjust to the Linux kernel in whole. This is entirely a personal issue, I have a number of problems with Linux memory management, scheduling, and some other points relevant to production use. I ve had some of these problems for years, but they seem never to get fixed, while development is fast-paced. Then I look at some of the work being done and I wonder what the priorities are. Regardless, I should not have made this comment and I apologise for it.