My internship is now finished, this means that I will be able to work on my GSoC project a lot more than the previous weeks. I hope to make some good progress in the next days.

This last 2 weeks, I was still studying how Jigsaw works. Even if there is no progress on the Jigsaw packaging I have done some packages that will help later.

I ve spend a lot of time trying to package JT Harness and JTReg.
I ve successfully built JT Harness using CDBS but I ve finally rewritten the package using only debhelper and javahelper. Javahelper was really useful to build JAR files, move them to the right directory, put the Javadoc in the right place as well as the examples. The Debian directory of JT Harness can be found on the Java team SVN.

svn co svn+ssh://$ SVN_USER @svn.debian.org/svn/pkg-java/trunk/libjtharness-java

The source package of jtharness build 2 binary packages: libjtharness-java and libjtharness-java-doc. You can see that by looking at the control file in the debian directory. There are some interesting files in this package, let s take a look at them.

First of all, some of the source files needed to be patched for the package to build. So to accomplish this, there is a couple of patches in debian/patches :

• dependencies.diff, used to locate JAR files in /usr/share/java , and,
• rxtx.diff, done by Tom Marble used to change some imports from javax.comm to gnu.io .

To generate these patches, I ve used the edit-patch command which is a really awesome tool. This command uses a temporary shell where we can edit files we want to patch. When the job is done, CTRL + D terminates the temporary shell and the patch is generated.

There are 4 interesting files which are used to build the binary packages and put the files in the right directories. These files are:

• rules,
• libjtharness-java-doc.install,
• libjtharness-java.jlibs, and,
• libjtharness-java-doc.javadoc.

Of course rules is the most important one. This file tells us how packages are built. A good thing is that rules is quite simple in the jtharness case.

#!/usr/bin/make -f
JAVA_HOME = /usr/lib/jvm/default-java

override_dh_auto_build:
ant -f build/build.xml

%:
dh $@ --with javahelper

We just tell where Java is and to use javahelper ( with javahelper). Overriding dh_auto_build is interesting because since the JT Harness uses Ant as build system we need to give to Ant where the build.xml file is. By default Ant is searching it in the current directory but in jtharness the file is in the build directory. Since the Ant build file is correctly written, the build generates JAR files, Javadoc and examples code. And libjtharness-java* files are here to put the generated things in the right places.
The job of libjtharness-java.jlibs is to tell where to find the JAR libraries. In this case, the intesresting JAR files were javatest.jar and jt-junit.jar . So in the .jlibs file we just give where those files are after being built.
The job of libjtharness-java-doc.javadoc is to tell where the Javadoc is and where to put it. So there is only one line that says the generated Javadoc is in jar-build/javadoc and put it in /usr/share/doc/libjtharness-java/api .
And finally, libjtharness-java-doc.install is used to move the examples. The syntax is same as libjtharness-java-doc.javadoc .

The JT Harness package can be found in Sid now thanks to Sylvestre Ledru who uploaded it for me. So the ITP bug that I created is now closed.

Building the package for jtreg is quite similar. In fact, it probably easier but I m still facing a problem. jtharness is just a library, jtreg does have main classes and generate some binaries. The difficulty here is to generate the man pages for the 2 generated binaries: jtdiff and jtreg. These 2 files are shell scripts which just use jtreg.jar with the correct parameters.

I tried several tools to generate the man pages of each script. Sadly, I can t find a way that does not causes any problems.
My first choice was to use help2man. This tool looked like to be perfect for the job. But I couldn t find how to launch the scripts correctly. The scripts needs jtreg.jar but they also need javatest.jar from the libjtharness-java package. The classpath cannot be set correctly due how the scripts are written. So to use help2man I ll probably have to patch and completely rewrite jtdiff.sh and jtreg.sh in the sources.
My second choice was to use txt2man. During the build of jtreg there is a usage.txt file which is generated and which can be used as a man page. txt2man can take this text file and output a man page based on the text. I thought it was working but when building the package, lintian threw some warnings about syntax errors in the man pages.

W: jtreg: manpage-has-bad-whatis-entry usr/share/man/man1/jtdiff.1.gz
W: jtreg: manpage-has-errors-from-man usr/share/man/man1/jtdiff.1.gz 292: warning [p 4, 3.3i]: cannot adjust line

Finally, few days ago I decided to try rst2man. This tool looks cool and easy to use. But the text that I have to convert into a man page is not a reStructured text so it cannot without patching the usage.txt file for example. I was going to do it but there is no such file in the sources of jtreg. Actually this file is generated during the build but the text had to come from somewhere. And it was from two properties files in the source code.
I m still looking for a good solution to generate the man pages. If someone has any idea just let me know

The debian packaging of jtreg is not in the Java team SVN yet because of the man pages problem. I opened an ITP bug so people know that someone is working on jtreg.

My goal for the next two weeks is to finish the jtreg package, understand how jpkg (which is supposed to create Debian packages) works in Jigsaw and write more examples using the modular JVM.

That was quite a headline, and I m going to try to back it up below. APRS is the Automatic Packet Reporting System. It s a system for exchanging brief packets of information. It is most frequently used for mapping applications, but it really does a lot more than that. It has its biggest home in the amateur radio world, but isn t limited to that, either. The most common way to use APRS is to have some device hooked up to a GPS transmit packets with the GPS information in them. These packets can then be plotted on a map in real-time or with history. That in itself isn t particularly newsworthy these days. An interesting thing about APRS is that it s not just positioning. Let s say that there was a search-and-rescue operation. A person could draw a rectangle on the map indicating the search area, and within about 3 seconds everyone else s map also shows that rectangle. People have even been known to play chess by sharing and moving objects on APRS! The next piece that makes this interesting is that APRS is an ad-hoc mesh network. In its traditional implementation, VHF amateur radio, a radio emits a packet with a geolocation in it (a beacon ) and any other radio within direct range of that can receive it. Radios can display basic information (such as distance to the other radio, heading, etc.) or hooked up to a laptop or mapping device for a better display. So if everyone is within a few miles, APRS works without any pre-existing infrastructure at all. This makes it wonderful for use in disaster areas, and was put to heavy use in Joplin after the tornado there. But what about radios that are too far away? Any APRS station could also be a digipeater. When a packet is transmitted, it has a maximum hop count. A digipeater hears the packet, decrements the maximum hop count, and re-transmits it. With this mechanism, packets can travel hundreds of miles. It creates a highly resilient network, one that can route around trouble without even having to have an explicit backup route. I could bring in a digipeater in my car it can be small enough to hold in my hand and instantly improve APRS reception in an area. One interesting aspect is that packets can be digipeated more than the maximum hop count. For instance, if a packet leaves my radio and is picked up by a digipeater to my west and one to my east, it can keep on traveling in both directions. This is part of what leads to resiliency. APRS also functions over the Internet. There is a large network of interconnected Internet servers that exchange all global APRS traffic amongst themselves. Gateways between the radio (RF) and Internet (APRS-IS) services exist, and are called iGates. They are not generally required, but make useful websites like aprs.fi and email gateways possible. As long as an iGate is within a reasonable number of hops from you, you re effectively linked. And again, if one iGate drops off, another iGate is probably monitoring your traffic too and you never notice. It s an ad-hoc mesh network that is actually reliable how about that? On the PC side, there are many programs for using APRS. The most common one for Windows is called UI-View, but I don t use Windows so I can t comment. On Linux, there are programs (such as aprx) for running your digipeater, but the best-known program is Xastir. Xastir lets you download map files to your local disk, and can interface with the APRS-IS Internet service, radios, weather stations, or simply other arbitrary machines to exchange information. Xastir is a very nice program and is well worth the install, despite its somewhat dated-looking interface. APRS clients, such as APRSDroid, exist for Android and iOS platforms as well. So let s say you re doing something like helping handle food/water stations for a long bike ride. Even if you don t have anybody with an amateur radio license, you can use APRS to great effect. At your headquarters, you can run Xastir and turn on its server mode . This puts everyone on a map. Then you can have everyone turn on APRS on their phone, and have it report to your custom server instead of APRS-IS. Now you have instant visibility into your entire team s location and status. If you have transport people driving supplies between locations, that s especially helpful. In an amateur radio scenario, you would instead have people with radios at each location, and one laptop hooked up to a radio at HQ. This provides an added bonus of not relying on third-party infrastructure such as cellphone towers. APRS also has a messaging system, similar in concept to text messaging. It works the same as other things. If I want to send a message to Jane, my radio simply emits a packet that lists the message and Jane as a recipient. It s digipeated up to its maximum hop count. If Jane is within RF range of one of those digipeaters, she gets the message and her radio ACKs it. Otherwise, it s delivered into the APRS-IS network probably several times, which isn t a problem and the APRS-IS network delivers it to the iGate closest to her, and from there it gets digipeated the rest of the way to her. Here s an example of something created with APRS. While I was on a bus choir tour last weekend, I had a radio with me that was beaconing all the while. Now it was a small handheld radio inside a large metal bus, so it didn t always have a digipeater in range. But still, you can go see a detailed map with the trail and even see exactly what path each packet took before it hit the Internet. If you want to try out Xastir, please grab at least version 2.0 the version in squeeze has some bugs.

Things aren t exactly going as smoothly as expected. Here are some explanations. First collateral damage: non-free fglrx and nvidia drivers. We have to admit we didn t think of those when we moved libGL.so.1 (and friends) from /usr/lib to /usr/lib/<triplet> (that s the move we call adding multiarch support ). In the mesa 7.10.3-2 upload, some Breaks statements were added to prevent users from installing new mesa packages if they still have old (without multiarch support) fglrx or nvidia packages. Solution: Sticking to the mesa packages in testing is the way to go until fixed fglrx and nvidia packages are uploaded. Second collateral damage: xserver-xorg-core in testing. The plan was to rebuild the server in unstable against the new mesa libraries, so that it would look into the new /usr/lib/<triplet> directory for mesa drivers. Since no source changes were needed, we went for a binNMU as explained in the previous blog post. That s the usual way to deal with libraries, and does the job very nicely. But that failed in this special case, for the following reasons:

1. The server only has libgl1-mesa-dri in Recommends, so there s no hard dependency here.
2. Usually, rebuilding a package against a new library means getting a dependency on the new library (typically because the binary compatibility has been broken, so the SONAME got bumped, meaning one depends on libfoo42 instead of libfoo41). And that means going in testing at the same time as the new library.

But in this case, rebuilding against the new library just means having a different search path somewhere in libglx.so. So the rebuilt package (2:1.10.2-1+b1) happily reached testing, which still contains the old mesa packages, which ship their files in the old /usr/lib path! Solution: Stick to 2:1.10.2-1 packages (snapshot.debian.org to the rescue), or wait a bit and get fixed packages. To get fixed packages, two things were needed:

1. Getting the server package fixed in unstable: that means adding Breaks against old (pre-multiarch) mesa packages, as seen in 2:1.10.2-2. This will ensure that new server package built against new mesa will not be co-installable with old mesa packages, and both mesa and the server should migrate together to testing.
2. Getting the server built again within testing, so that it gets built against old mesa, so that both mesa and the server in testing remains without multiarch until the packages in unstable are ready to migrate together.

While taking care of that second step, it was discovered that many buildds are still lacking a testing chroot, so there might be some delay until the server is rebuilt in testing (as 2:1.10.2-1+wheezy1). Eager users can use the time travel machine mentioned above to get stuff working again sooner. (As far as I can tell, the last problematic combination which would remain would be 2:1.10.2-1+wheezy1 server with new mesa, but we ll make sure we update the Breaks in the new mesa to make sure that it can t happen. Since it s not as urgent as getting the server in testing fixed, it s only queued for mesa 7.10.3-3 for now.)

Just reminding myself (and you) of the following pretty important tip that I got 2.5 years ago and already forgot: use alt=rss in blogger feeds when giving the feed to planetplanet. Planetplanet treats the "updated" field of Atom feeds similar to "published".

So hopefully planet Debian fixed now as well.

I reactivated my Twitter account yesterday, but do not expect too many tweets.

DECLARATIVE DIVERSIONS ====================== REPORT 2 This is the second report for declarative diversions for debian as part of Google Summer of Code. My first report was just a design draft but I have since been advised to structure it differently. So in this report I will talk about what I have done to date with the project and what my plans for the immediate future are. For the first while in this project I spent a lot of time with my mentor planning out what we were going to do and we discussed it with everyone who is involved with dpkg to get feedback. I quickly got a great deal of feedback and produced my first design draft. After which I got even more feedback and produced my second design draft. This week is the first week I have spent coding. So far I have coded a parser which works quite well for what we need. I spent the later part of this week integrating it into the existing codebase. But so far everything is looking extremely promising. My plans for the immediate future are to release a third design draft based on feedback from my existing code and to finalise the main part of the work. I believe this will be achieved by the next report date (1st of July) as well as a lot of basic functionality for the project. Anyone who wishes to discuss the project with me can either mail me through the mailing list, catch me on IRC (SCD[Eire]) or email me at sam.dunne101@gmail.com My blog: http://blog.sam-dunne.com My Github: https://github.com/samdunne/dpkg-diversions My code is located in /lib/dpkg/test in the gsoc-testing branch of my code Until next time, ~Sam

Hmm, I think it's happening again. I changed the Planet Ubuntu to only feed on posts tagged 'ubuntu' from now on, and now as an example tagged one post as 'ubuntu', in addition to this one I'm now writing. Google told me that using "Label actions" to change labels wouldn't affect the feed, but it looks like the feed timestamp for my previous, older post was again updated (not the "Published", but "Updated")... so I guess I won't be tagging any further old posts, unless it turns out the previous problem I had was that the Published stamp was also renewed and the Planet Ubuntu ignores Updated stamp.

If you have a solution, please tell it.

Update: Solution found! Thanks, artfwo.

--- cut ---
Vuoden 2007 lopussa Siebrand asetti lokalisointitavoitteet MediaWikille.Tavoitteet olivat todella kunnianhimoisia. N ytt kin silt , ett n ihin ei p st . Emme kuitenkaan aio luovuttaa ilman taistelua. Viel on vajaa viikko aikaa saavuttaa nuo tavoitteet. Sin voit auttaa saavuttamaan tavoitteet suomen kielen osalta.

Yhteisty ss Stichting Open Progressin kanssa pystymme tarjoamaan sinulle kannustusta. Tarjoamme 1000 euroa jaettuna kaikkien k nt jien kesken, jotka ovat tehneet yli 500 uutta k nn st MediaWikiin ja sen laajennuksiin vuoden loppuun menness .

My s muut Betawikin projektit kaipaavat apua. Kiinnostaisiko sinua k nt vaikkapa FreeCol-peli tai Mantis-virheenseurantaj rjestelm . Yst v llinen ja yhteisty kykyinen ymp rist saattaa sinut vauhtiin sek auttaa sinua kehittym n suomentajana parantamalla k nn ksi yhdess .

Betawiki l ytyy osoitteesta http://translatewiki.net.
--- cut ---
(l hde)

Katso my s http://lokalisointi.org/.

Edit Aug 18th: video available (ogv, also on youtube)

Forget AMD, Intel, NVIDIA! Thomas White's incredible work with Neo FreeRunner's puny graphics dec...accelerator, Smedia Glamo 3362 is starting to bear fruits. Not listening to such comments as the chip will never be used anywhere else and why not spend your time doing something more relevant , he has chosen to actually do what he likes and sees as an interesting challenge. And that's often the spirit of free software, so I don't really agree with the naysayers.

The camera shot on the right, running KMS-enabled X.org driver for the glamo chip on my Debian installation (visible software matchbox-window-manager, fbpanel, zhone), is a bit optimistic looking since Zhone happens to draw correctly. A lot of the drawing is not yet synced correctly, which shows as all text and images in eg. GTK applications being garbled. But as little as two days ago one couldn't yet much launch applications without X crashing, so the newest commits by Thomas were a big step forwards. I'm using Debian, and he's not, so I try to find time to help in debugging even though I really can't much help with the driver code.

The driver is not just one piece of code, but consists of a kernel drm driver (direct rendering manager) using GEM, libdrm support for the kernel driver and finally the X.org driver supporting these other components and offering buzz-words like DRI2. There is also a beginning of a Mesa 3D driver, though it is so far just a skeleton driver since the 2D/KMS/EXA/DRM parts are what should be done first before dwelling into the OpenGL realm.

Openmoko the company is basically nowadays just producing new Neo FreeRunners to resellers, but the community of the so far only Free phone is thriving. The final (Openmoko produced, from where gta02-core continues) version of the phone, with the famous buzzing problem fixed, appeared on store shelves some time ago, offering better out-of-the-box phone functionality in addition to all the mini computer features. It was also offered to Debconf visitors on discount.

It's not only cool to have kernel mode-setting, though it is indeed very cool as well. The reason for much sorrow in the whole OM project has been the graphics chip, and some of the problems with the chip are only finally solvable with the kernel doing the mode-setting. So it's both a very modern thing to use KMS, but there are also clear potential benefits of having accurate control over this very sensitive piece of silicon. The current non-KMS X.org driver for example busy loops in order to try to feed the chip at a correct pace, causing CPU usage every time there is any drawing going on.

This is somehow reminding me about getting the best out of 8-bit computers and other hardware with some specific limitations. The glamo chip is very limited in some ways, but also capable in some other ways like theoretically offering MPEG-4 decoding, OpenGL ES 3D support. It's a mixed bag of things, and I can very well imagine it's indeed an interesting challenge to work on it, if you just have the skills (I don't) and nerves (proper debugging tools help).

It's so nerdy to drool over lines in the X.org log, but I just can help it:

X.Org X Server 1.6.3
Release Date: 2009-7-31
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.28 armv5tel Debian
Current Operating System: Linux neo 2.6.29-GTA02_mydrm #2 PREEMPT Mon Aug 17 18:24:39 EEST 2009 armv4tl
...
II) Using KMS!
...
(WW) Glamo(0): EXA hardware acceleration initialising
(II) EXA(0): Driver allocated offscreen pixmaps
(II) EXA(0): Driver registered support for the following operations:
(II) Solid
(II) Copy
(II) Glamo(0): Initialized EXA acceleration
...
(II) Glamo(0): RandR 1.2 enabled, ignore the following RandR disabled message.
...
(II) Glamo(0): [glamo-dri] Name of DRM device is '/dev/dri/card0'
(WW) Glamo(0): [DRI2] Version 1 API (broken front buffer rendering)
(II) Glamo(0): [DRI2] Setup complete
...
(II) AIGLX: enabled GLX_MESA_copy_sub_buffer
(II) AIGLX: Loaded and initialized /usr/lib/dri/glamo_dri.so
(II) GLX: Initialized DRI2 GL provider for screen 0
(II) Glamo(0): Adding framebuffer....!
(II) Glamo(0): 8 480 640 16 16 960
(II) Glamo(0): rootPixmap = 0x1d0a00
(II) Glamo(0): Done

The main release party in Finland was held at Tampere, Finland and organized by Ixonos Plc and COSS. It was a great success, as proven by the almost 200 participants and great speakers.

The first sessions were mostly about the basics of Ubuntu and its roots in Debian and elsewhere. Then Tuure Vartiainen from Tampere University of Technology shared with us the release from the official Finnish mirror perspective (fi.archive.ubuntu.com, fi.releases.ubuntu.com, ...). 10.04 LTS release date was very hectic and the transfer speeds were not constantly optimal, but quite good anyway. For 10.10 they hope to up the network connectivity to 10G. I also took the opportunity to thank him later personally for the Ubuntu Finnish Remix mirroring which was arranged right before the release as well.

The next-to-final session was about Ubuntu for senior people with brief demoing of how Ubuntu UI can be customized. To give a little different perspective to usage of Ubuntu, the final speaker was a theater director and dramatist Jotaarkka Pennanen from Interactive Film Productions. Blender among else was praised.

In addition to speakers, we had 300 Ubuntu Finnish Remix CD:s, Ubuntu posters, Free Software Foundation Europe flyers, COSS flyers et cetera. After the main program there was a dinner and some wine offered to participants, which was a great social ending to the event.

Now a few photos follow. Unfortunately they are from before the event actually began, so others have probably more crowded photos and photos of the speakers themselves.

I'm writing a blog entry instead of just replying to myself on a mailing list, since this subject might be interesting to a largish portion of the community. Most people assume things just magically work out by themselves and then after a release wonder why it wasn't so.

So, I raised a question on ubuntu-devel-discuss mailing list about whether usb-modeswitch should be included in the default Ubuntu 10.04 LTS installation instead of it only being in the universe repository. Reason was simply that firstly, I've read some general wonderings from the community about why it isn't already so. Secondly, without it my 3G modem (Huawei E1552) was first not functional, but right after installing usb-modeswitch package Network Manager worked smoothly with it.

Since I didn't get much discussion going on besides some statements that it doesn't work for everybody and even has caused extra problems for some others (in 9.10), I asked for a small round of comments on the subject on IRC. The channels are logged so I believe I can quote those a bit.

Colin Watson said among else:

"surely we just want the kernel to DTRT [do the right thing] by default ... this is the upstream trend ... it already DTRT for quite a few devices"
"I'd be very concerned about advertising that it's the Way to get things to work, and thus undermining getting things fixed in the kernel"
"I agree that usb-modeswitch is often a way to get otherwise non-working hardware to work ... I'm just not very convinced it's a real properly supportable option"
"but I'm just another user from this point of view, albeit one who ended up in quite a few discussions with various appropriate upstreams last time round :)"

Later on Paul Sladen continued a bit, among else:

"usb-modeswitch is a very long-winded way of sending a single usb-mass-storage command to the device's first profile"
"grep -hr MessageContent usb_modeswitch.d/ sort -n uniq -c sort -rn shows the level of duplication in the configuration files"
"...I do like that it is done in userspace though, as so easy to disable if you wanted something else".

Meanwhile I also IM:d a bit with Antti Kaijanm ki from whom I probably originally coined the idea of following whether usb-modeswitch is integrated into Ubuntu or not. He mainly said that he doubts the feasibility of updating kernel's USB storage quirks in a stable release, compared to having stable release upgrades about the usb-modeswitch-data udev rules. He also proposed discussing maintainability and usability by distros with the Debian maintainer and upstream, although it sounds like Colin might have had some talks already.

So there we are now. Apparently at this point it is hoped that as many quirks as possible are inserted in the kernel, see for example drivers/usb/storage/unusual_devs.h in the kernel. But if you have concerns about if 10.04 LTS will be kept up-to-date regarding 3G modems and want to somehow participate in bringing usb-modeswitch into Ubuntu default installation or simply discuss how to handle the kernel SRUs properly, it's time to stand up and do something.

Should there perhaps be a process with which the usb-modeswitch developers would get the information they are gathering more easily to the upstream kernel _and_ (older) distribution kernels? Is this simply a case of being easier to address an issue with a "hackish" approach, or is the usb-modeswitch actually the right way to go?

Note that I'm no expert in this area, I simply become interested in various subject from time to time :)

-Timo, going to figure out a kernel quirk for his 3G modem

Since Matt is going to be busy the next few weeks moving and traveling, he arranged for Stefano Zacchiroli to fill in for him temporarily as my mentor. I must say, I am quite lucky to have the chance to have both Matt and Stefano as mentors this summer. Yesterday, I had my first call with Stefano. I started by filling him in on the current status of the project. We discussed how the dashboard is going to be based on tasks rather than bug . He reminded me that we want to make sure all useful information makes its way back to the BTS (ideally in an automated or) in a fast and easy way. Most of the information that will be stored in the dashboard probably won t be that useful to the package maintainers. However, there will be a column for DEX members to add notes about tasks. This column could potentially contain some useful information. That is one reason that the dashboard will parse this column for bug numbers and then display extended information about the bug. Hopefully, this will encourage DEX members to send information to the BTS when relevant. Having the bug numbers will also allow us to automate sending information from the DEX dashboard to the BTS if we choose to. I also spent some time this week working on a script to generate some graphs. These graphs will allow us to track the number of remaining tasks in a project vs. time. Stefano mentioned possibly borrowing some code from the Ubuntu burndown charts, but right now, I think the Ubuntu charts might be a bit more complicated than what we need. We can always decide to borrow some features/code down the road if necessary. It is also just about time for me to prepare my second formal report for the Summer of Code. I will use that to showcase the current status of the code and make it available for people to test and review.

It was very much a team effort. My friend Brandon, who is an excellent photographer, came over and took some photos. Then my friend Sara, who is a bit of a Wikipedia contributor/edit/expert, showed me how to upload the photo to the Wikimedia Commons, and then it was just a case of gluing it all together by making the edit on the Wikipedia page. Then it was almost immediately deleted. It turns out that apparently the Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Generic license (better known as CC BY-NC-SA 2.0) is somehow incompatible with Wikipedia & friends (I haven't figured out the exact ins and outs of why yet). I had to get Brandon to re-license the photo I used as just CC BY-SA 2.0 (basically ditching the non-commercial restriction). Then it magically reappeared (after some help from Sara with the response). Crikey, this Wikipedia contributing is tricky stuff. At least when Speck's owners get back to pick her up, I can tell them their gecko is famous.

All mail clients suck. Some just suck less. But they all have their own peculiarities. mutt, for instance, is a full-featured text-mode mail client. As such, it's pretty popular amongst many Linux enthousiasts, including me. A common error made amongst mutt users is to talk about attaching a file in a mail, but then forgetting to actually do so afterwards. This is because mutt starts an external editor to allow you to edit the message in question, which since it's not mutt itself would seem to make it impossible to attach a file while you're editing a mail, requiring one to remember to actually perform the attach step. One solution to this problem could be to use the little script that Steve wrote, which will complain if you mention something about an attachment in a mail without actually attaching anything. While I'm sure it works to some extent, this kind of script has the downside that it's never going to be 100% correct in all cases (you might mistype the word 'attach', or you might use another word that you didn't think about when you wrote the script, or you might be replying to someone who sent you an attachment). However, a better way could be to realize that mutt does, actually, support attaching files while you're editing a mail text, by way of the 'Attach:' pseudo-header. It requires two steps:

1. Make sure that you have set 'edit_headers' to 'yes' in your configuration. This will cause mutt to fire your editor on a file that also contains the (relevant) headers for your mail, rather than just the body.
2. When you want to attach a file, rather than trying to remember to do so after exiting your editor, just add an 'Attach:' header to the headers section of your mail, with as argument a filename optionally followed by a description. When mutt finds that header, it'll attach the named file, and all is well.

Yes, of course, that does mean you'll have to change your habits, and actually remember to add the damn pseudo-header rather than be like me and still forget to attach files. But hey, can't help you with that.

Unfortunately, GLabels is currently unmaintained. Still, it's a very convenient tool, IMHO to print DIY business cards. Here's my glabels business card file, for those interested to borrow and reuse it.

The first concrete outcome from the Debian derivatives census is the creation of Planet Debian Derivatives. For those of you who are interested in the activities of distributions derived from Debian, it aggregates the blogs and planets of all the distributions represented in the derivatives census. The list of feeds will be expanded semi-automatically as more distributions participate in the census and maintainers of census pages add new blog and planet URLs. Many thanks to Joerg Jaspert for doing the necessary setup procedures for the addition of the new sub-planet to Planet Debian. I'm glad that it was accepted alongside the sole language-based sub-planet (Planet Debian Spanish). I plan further integration of information about derivatives with Debian infrastructure. My next target will be integration of information about the packages in Debian derivatives into Debian. I hope to work on getting that information into UDD (and rmadison) and the packages.d.o site during DebConf11 and DebCamp. If you are interested in helping out, please add your ideas to the integration wiki page, check out the code and add more scripts to it. If you have any comments or questions about this or any other activities related to Debian derivatives, please direct them to the debian-derivatives list and the #debian-derivatives IRC channel on OFTC. Those of you interested in the other side of the software stream might want to take a look at Planet Debian Upstream, which is run by the excellent Joey Hess. He is also on the lookout for interesting blogs by people writing software that is packaged in Debian. The site is created using ikiwiki, hosted on branchable and editable with an OpenID account.

Ever since I blogged about the status of GNOME 3 in Debian experimental, my web logs show that many people are looking for ways to try out GNOME 3 with Debian Squeeze. No GNOME 3 for Debian 6.0 Don t hold your breath, it s highly unlikely that anyone of the Debian GNOME team will prepare backports of GNOME 3 for Debian 6.0 Squeeze. It s already difficult enough to do everything right in unstable with a solid upgrade path from the current versions in Squeeze But if you are brave enough to want to install GNOME 3 with Debian 6.0 on your machine then I would suggest that you re the kind of person who should run Debian testing instead (or even Debian unstable, it s not so horrible). That s what most people who like to run recent versions of software do. How to run Debian testing You re convinced and want to run Debian testing? It s really easy, just edit your /etc/apt/sources.list and replace stable with testing . A complete file could look like this:

# Main repository
deb http://ftp.debian.org/debian testing main contrib non-free
deb-src http://ftp.debian.org/debian testing main contrib non-free
# Security updates
deb http://security.debian.org/debian-security testing main contrib non-free

Now you should be able to run apt-get dist-upgrade and end up with a testing system. How to install GNOME 3 on Debian testing aka wheezy If you want to try GNOME 3 before it has landed in testing, you ll have to add unstable and experimental to your sources.list:

deb http://ftp.debian.org/debian unstable main contrib non-free
deb http://ftp.debian.org/debian experimental main contrib non-free

You should not install GNOME 3 from experimental if you re not ready to deal with some problems and glitches. Beware: once you upgraded to GNOME 3 it will be next to impossible to go back to GNOME 2.32 (you can try it, but it s not officially supported by Debian).

To avoid upgrading all your packages to unstable, you will tell APT to prefer testing with the APT::Default-Release directive:

# cat >/etc/apt/apt.conf.d/local <<END
APT::Default-Release "testing";
END

To allow APT to upgrade the GNOME packages to unstable/experimental, you will also install the following pinning file as /etc/apt/preferences.d/gnome:

Package: *gnome* libglib2.0* *vte* *pulse* *peas* libgtk* *gjs* *gconf* *gstreamer* alacarte *brasero* cheese ekiga empathy* gdm3 gcalctool baobab *gucharmap* gvfs* hamster-applet *nautilus* seahorse* sound-juicer *totem* remmina vino gksu xdg-user-dirs-gtk dmz-cursor-theme eog epiphany* evince* *evolution* file-roller gedit* metacity *mutter* yelp* rhythmbox* banshee* system-config-printer transmission-* tomboy network-manager* libnm-* update-notifier shotwell liferea *software-properties* libunique-3.0-0 libseed-gtk3-0 libnotify* libpanel-applet-4-0 libgdata11 libcamel* libcanberra* libchamplain* libebackend* libebook* libecal* libedata* libegroupwise* libevent* gir1.2-* libxklavier16 python-gmenu libgdict-1.0-6 libgdu-gtk0
Pin: release experimental
Pin-Priority: 990
Package: *gnome* libglib2.0* *vte* *pulse* *peas* libgtk* *gjs* *gconf* *gstreamer* alacarte *brasero* cheese ekiga empathy* gdm3 gcalctool baobab *gucharmap* gvfs* hamster-applet *nautilus* seahorse* sound-juicer *totem* remmina vino gksu xdg-user-dirs-gtk dmz-cursor-theme eog epiphany* evince* *evolution* file-roller gedit* metacity *mutter* yelp* rhythmbox* banshee* system-config-printer transmission-* tomboy network-manager* libnm-* update-notifier shotwell liferea *software-properties* libunique-3.0-0 libseed-gtk3-0 libnotify* libpanel-applet-4-0 libgdata11 libcamel* libcanberra* libchamplain* libebackend* libebook* libecal* libedata* libegroupwise* libevent* gir1.2-* libxklavier16 python-gmenu libgdict-1.0-6 libgdu-gtk0
Pin: release unstable
Pin-Priority: 990
Package: *
Pin: release experimental
Pin-Priority: 150

Note that I used Pin-Priority: 990 this time (while I used 500 in the article explaining how to install GNOME 3 on top of unstable), that s because you want these packages to have the same priority than those of testing, and they have a priority of 990 instead of 500 due to the APT::Default-Release setting. You re done, your next dist-upgrade should install GNOME 3. It will pull a bunch of packages from unstable too but that s expected since the packages required by GNOME 3 are spread between unstable and experimental.

If you want to read more articles like this one, click here to subscribe to my free newsletter. You can also follow me on Identi.ca, Twitter and Facebook.

13 comments Liked this article? Click here. My blog is Flattr-enabled.

Looking around old files I have put online ages ago I stumbled upon a Unknown Horizons Code Swarm Video I have created back in September 2009. Feeling more than a bit sad this piece of software died soon after being released. Searching the web for "Code Swarm" still finds lots of old Videos created back then.

Yesterday I released version 4 of dh-autoreconf, fixing two bugs, and introducing a new feature: Patching ltmain.sh to make -Wl, as-needed work. For this new feature, run dh_autoreconf with the as-needed option. dh_autoreconf will then patch all ltmain.sh equal to the system one (which should be all ltmain.sh files if libtoolize ran before or via dh_autoreconf). On clean, dh_autoreconf_clean reverses the patch again. So, if your package runs autoreconf, and patches ltmain.sh via a patch you can now do this automatically via dh-autoreconf and be future-proof. The only problem is that this might break once the patch no longer applies to libtool, at which point I need to update the package to include an updated patch. A solution for this problem would be to include the patch in libtool itself, as I proposed in Bug#347650. In case this works well, the option could also become the default which would make things even easier.
Filed under: Debian

One of our paper has been accepted to The 14th International ACM SIGSOFT Symposium on Component Based Software Engineering (CBSE-2011) happening in June in Boulder, Colorado, USA. This is a joint work with Roberto Di Cosmo, Ralf Treinen and Stefano Zacchiroli.

Abstract

 Software distributions in the FOSS world rely on so-called 
  package managers for the installation and removal of packages on
  target machines. State-of-the-art package managers are monolithic in
  architecture, and each of them is hard-wired to an ad-hoc 
  dependency solver implementing a customized heuristics. In this
  paper we propose a modular architecture allowing for pluggable
  dependency solvers and backends. We argue that this is the path
  that leads to the next generation of package managers that will
  deliver better results, accept more expressive input languages, and
  can be easily adaptable to new platforms.  We present a working
  prototype---called MPM---which has been implemented following the
  design advocated in this paper.

---

More details about the paper are available here