Since the 3.5.0 release, Openbox automatically starts applications with .desktop files in /etc/xdg/autostart. This was already the case with previous releases when setting the . $GLOBALAUTOSTART instruction in the autostart script. This instruction is now deprecated. This has puzzled me as some applications were started twice in my Openbox session: those launched via my ~/.config/openbox/autostart script which are also launched through xdg autostart. I also like to use notify-osd when in openbox, but it seems the new gnome-fallback session requires notification-daemon. In my Openbox session, I have noticed that notification-daemon was launched whereas my autostart script specifies to use notify-osd. I then discovered that /etc/xdg/autostart/notification-daemon.desktop was the cause of this. I had to drop a notification-daemon.desktop file in my ~/.config/autostart/ directory with the following contents: The last two lines allow me to not start notification-daemon only when using Openbox ie. it still starts automatically when launching a GNOME session. You can check what applications are automatically started through xdg with: The results are quite amazing, most applications being only configured to start in GNOME or KDE, but nothing seems to be very coordinated amongst maintainers. I find this quite misleading, and would prefer openbox to stick with the previous default behaviour. Who said diehard ?!

I ve recently been to the LibreOffice Conference 2011 in Paris. It s very nice to finally meet in person all those names from the malinglist and the bug reports. Although meeting most people for the first time, I left the conference with a strong feeling of a community (which I m proud to be a member of), this is a very motivating feeling. During the conference I had the chance to work on LibreOffice related issues:

• Hebrew translation for version 3.5 (up by 2%).
• Fixes to the Hebrew translation for version 3.4 (noticed a few string changes in 3.3 not included in 3.4).
• Patch to fix a small typo in the code (noticed while trying to find the meaning of the string before translating).
• Patch to fix the appearance of the BrOffice logo in RTL UI instead of LibreOffice (fix to the 3.3 branch, already fixed in 3.4).
• 3 patches (1, 2, 3) to cleanup unused .chaos file types with Michael Meeks s encouragement and help with doing some digging in the code.
  Apparently, even non programmers can write patches with the appropriate help.
• Check about 30 RTL and Hebrew related bug reports for my RTL issues presentation, verifying them with 3.4.3.

The 3 patches began when I noticed a few weird strings to translate in the context of installation media good luck to those who will try to install LibreOffice from 5.25 disk, 3.5 disk or a tape drive. These 3 strings are now removed from the code with other 36 unused strings. So translators please take the strings to translate with a grain of salt. Post conference tasks (always ending up with more stuff to do after a conference):

• Recreate my RTL issues presentation so that the live example of bugs could be presented as slides.
• Keep advancing with the Hebrew translation (3.5 and 3.4 fixes).
• Finish the fdo bugzilla search for RTL bugs. I found out some other people who reports bugs (and try to coordinate with them).
  A list of RTL related bugs in LibreOffice I know of is here: http://wiki.hamakor.org.il/index.php/ _ _ (still work in progress, in Hebrew).
• Create a meta bug for the RTL bugs, and prioritize the issues to focus on what s important to make sure is fixed for version 3.5.
• Start testing version 3.5 for RTL bugs (daily / weekly builds).
• Help Christoph Noack with finding which PaperCuts we have in LibreOffice and try to get them fixed.

Filed under: LibreOffice, Openoffice.org

I'm indescribably happy to be able to say that I found Smudge alive and well this morning. I was getting ready to head out the door to work, and I opened the shutters in the kitchen and saw that the trap that I had outside by the front door was closed. The trap itself was wrapped in a sheet, so I couldn't immediately see what I'd caught. I quickly went outside, half-expecting to find a raccoon in there, and I was pleasantly surprised to find Smudge in there! I brought the trap inside and got Smudge out and raced her over to the food and water, where she had a long drink of water and something to eat. She's definitely lost some weight, but otherwise doesn't seem any worse for wear. She's currently sitting in my lap as I write this, so I don't think she's too traumatised by her ordeal. Lily was a bit standoffish this morning, hissing and growling at her, but I suspect that's because she didn't smell right. If she keeps that up, I'll put a drop of vanilla essence on both of them so they smell the same. Yesterday, I'd received a report of a possible sighting three streets over (houses on one side of the street back onto the Hetch Hetchy trail, where there were also reported sightings), so last night I placed the other trap in the backyard of one of the houses where there'd been a sighting. A couple of hours after that, I got another report of a possible sighting from someone else on the same street, further down. So I was pretty keen to substantiate all of these sightings on this particular street. Unfortunately, after two trips up there, I didn't see any black cats, so we'll never know if it was her or not. The night before last, I'd upgraded the food in the traps to some sardines, tuna and some fresh wet cat food, to try and lure her in. I have no idea if that helped or not, or she just finally found her way home, but it was such a relief to find her in the trap this morning. It turns out I caught an opossum in the other trap. Those are the funniest animals. They have a totally broken fight or flight reflex. This one would not leave the trap when I opened it. I ended up having to upend the trap and shake it out, and even then it just lay there playing dead - even when I shoved a bowl of food in its mouth. I've just done the rounds of the neighbourhood and taken down all the posters I'd put up. It had been suggested that I might want to update the posters and say that I'd found her, but I honestly don't want to do the extra trip to then take them all down again after that.

Jean-Yves Lefort s link-monitor-applet, an applet for the GNOME panel, is a great tool for those with often-changing and possibly unreliable network connection. It allows me to see, at one glance, whether I can reach the router, the internet and/or my VPN. Furthermore, the latency display tells me whether there is a point in working over SSH right now. I often observe other people, e.g. on conferences, to stare for a while at a non-loading web page, then fire up a terminal window and run random ping commands, while I immediately see that the network is down and can relax. Unfortunately, Jean-Yves seems to have stopped working on link-monitor-applet and does not reply to bug reports. This was not a big deal as long as I could use the last released version with minor patches of mine, but now gnome-panel 3 is coming up and all applets need porting to GTK3. Yesterday and today I worked on that, and got it so far that the applet is fully functional, although the visual styling is not perfect yet, because I m not sure how to do what Jean-Yves did with GtkStyle and GdkGC now with GtkStyleContext and Cairo. The code is in the gnome3 branch of my git repository.
For this issue, and any further maintenance work, I m looking for someone who is willing to take upstream responsibility for link-monitor-applet, e.g. making sure it works with the latest GNOME (well, GNOME in fallback mode) and that bug reports are handled. The code base is not too big, and both the non-standard build system and the gob-enhanced C code are fine to work with. I ll still be happy to serve as the maintainer of the Debian package of link-monitor-applet.

Flattr this post

The issue This morning (while I was running late for an appointement) I had a very weird stuff happening on my Thinkpad T61 laptop. Since I recently offered myself a shiny Thinkpad x201s, I have to admit I don't use much my T61 anymore. But this morning I had to print a page (for this appointement) and, as I didn't yet configured my printer on the x201s, I went to the T61. But I noticed that the network was down. I've tried quickly on wireless but, bad luck, my current wifi setup selects the channel automatically and it prefers choosing channels which aren't available in the US. Guess what, my T61 comes from the US and has those channels completely disabled, so no wireless available either. The investigation I first tried to

modprobe -r e1000e
modprobe e1000e to see if it fixed the problem, but it didn't. Worse, the interface disappeared and never reappeared. I tried to reboot but it didn't fix the problem, the link was still down. Running really late, I put the file on a usb key and printed it from the powerbook and postponed the fix for later. Now, this evening, I tried to investigate a bit more. Symptoms weren't only that the nic wasn't working, but there was a high load on the system (1-2 at idle), unresponsiveness every second or so, and watching top I could see spikes of high cpu usage for the kworker kernel thread. Typing that on google you can find a lot of people running on this issue, usually starting around kernel 2.6.36 or 2.6.37. Now, I might have upgraded the kernel recently to 3.0.0-4, but that didn't look related since the problem first appeared when the laptop was up and running. And I tried to reboot under 2.6.39, 2.6.38 and even 2.6.32 and the problem was still present. Each time, unloading the module would fix the problem, but loading it again wouldn't make the interface reappear. People advised to boot with pcie_ports=compat but that didn't do anything. I tried to boot without intel_iommu=force (disable Intel Vt-d) and pcie_aspm (Active State Power Management) but nothing either. Considering a userland issue, I've tried to boot a grml live distro (always keep a grml.iso in your /boot, extlinux-update will even put it in your menu automatically), and the problem was still present. So not a Debian kernel issue, not a userland issue, only thing left was the laptop. I didn't update the Bios recently, so I wondered exactly what could be the problem. I started to feel a little bad, since I still really like that laptop, and that I already decided to lend it to my sister since her own T61 is sitting with a dead system board in my shelf. I know she might have some negative waves, but she was not even landed when the problem first appear. The fix Then I had a flash. It's not mystery that I'm used to break network cards, and I had the bright idea to shutdown the laptop, disconnect AC and battery, then let it idle a bit. I even tried the secret Thinkpad power button code but I think it's unrelated. Then I re-plugged the battery, booted to grml and the issue was gone. I rebooted on the standard Debian and the link was up, network was working. So what happenned? The (tentative) explanation My guess is that, somehow, the network card firmware has an issue and choked on something (a network frame or an attack exactly like the one we demonstrated on ASF firmware). In fact, no, I don't think it's the e1000e firmware. My T61 comes with Intel vPro, which includes AMT (Active Management Technology), a remote management solution a bit like ASF but more advanced. As far as I know, AMT firmware always runs, even when it's disabled, it's just completely idle. Idle, but in this case I think it choked on something, and a reboot isn't enough to restart the AMT firmware. But a real hard reset without any power seems to do the trick. What next? Well, a part of me is pretty scared, but another is just bored. I mean, we know about that, that's exactly the kind of issue we are warning people of. I have no idea what exactly happened, and there's no way I'll be able to reproduce that, but I'm pretty sure it's something lying at a pretty low level in the platform, and which can severely disable your workstation. Now if it happens again I won't lose too much time on this. TL;DR: helping other people In case you came here because you searched on google terms like kworker cpu usage , e1000e, interrupts, it might be a good idea to first reboot on a live CD to eliminate installation issues, then shutdown the laptop, remove the battery and let it few seconds idle. This might be enough to reset something inside and fix the situation.

#### [WATER FRACTIONS IN EXTRASOLAR PLANETESIMALS](http://arxiv.org/PS_cache/arxiv/pdf/1110/1110.1774v1.pdf) #### Jura & Xu, Arxiv.org. #exoplanets, #water, #phd > Abstract: With the goal of using externally-polluted white dwarfs to investigate the water fractions of extrasolar planetesimals, we assemble from the literature a sample that we estimate to be more than 60% complete of DB white dwarfs warmer than 13,000 K, more luminous than 3 10 3 L and within 80 pc of the Sun. When considering all the stars together, we find the summed mass accretion rate of heavy atoms exceeds that of hydrogen by over a factor of 1000. If so, this sub-population of extrasolar asteroids treated as an ensemble has little water and is at least a factor of 20 drier than CI chondrites, the most primitive meteorites. In contrast, while an apparent excess of oxygen in a single DB can be interpreted as evidence that the accreted material originated in a water-rich parent body, we show that at least in some cases, there can be sufficient uncertainties in the time history of the accretion rate that such an argument may be ambiguous. Regardless of the difficulty associated with interpreting the results from an individual object, our analysis of the population of polluted DBs provides indirect observational support for the theoretical view that a snow line is important in disks where rocky planetesimals form. Ok, so we now have a way of estimating how wet planetary systems *were*, at the time they fell into the white dwarf star. Not very representative of the time they before the planet got roasted to a crisp by the stars Red Giant stage, however. Recovering the hydrogenation state of serpentinized minerals might be possible and useful.

Poor Sarah. Cat dramas always seem to befall us when she's in Australia. It looks as if Smudge has managed to escape the house. Being at work all day, it took me 24 hours to notice. Our friend Helen came over on Sunday night. Smudge was definitely around then, because she was climbing all over Liam. Helen used the downstairs bathroom before she went home, and I remember her having to shoo Smudge out because she was in there. I'm pretty sure she went home after that. If my memory serves, she saw herself out and I was in the kitchen cleaning up, so my current theory is that she escaped when Helen left. On Monday night, I had a lengthy video call with Sarah, who was at my parent's place setting up their new Mac Mini. I didn't realise until after that, when I was about to go to bed, that I hadn't been harassed by Smudge all evening. So I searched the house that night, and couldn't find her. Liam had already gone to bed for the night, so I hoped she was stuck in his room, and went to bed too. This morning, Liam and I both searched the house, and the immediate surrounds, without any luck. I called the Palo Alto Animal Services (I got the dispatch because the shelter hadn't opened yet), emailed the local neighbourhood association, and went to work. I called Palo Alto Animal Services again later in the day to report her missing to the shelter itself, and Betty-Ann there recognised my accent and name and asked me if I was Sarah's husband (Sarah used to volunteer there a lot, and we adopted Smudge from there), so they're now keeping a look out. Smudge is micro chipped, but wasn't wearing a collar. She's allowed in the back yard, because it's totally enclosed and can't escape, so she shouldn't be totally freaked out by being outdoors. Whenever she does escape out the front door, she usually makes a beeline to the right, which is mostly enclosed, but she can certainly get out of the complex. Unfortunately she often doesn't come when called, so for all I know she's in some obscure location 10 metres from the front door and I can't see her. My main concerns are that we're only two blocks from Highway 101, so if she does stray too far, she could get into serious trouble, and I'm also a bit worried about raccoons giving her grief. I spent some time tonight putting up posters in the immediate area and poking around bushes. I've left the two humane cat traps that we have out by the front door with some cat food in them, in the hope that she's roaming around and will walk into one of them. Oh and the other big concern I have is that Halloween is coming up. Shelters tend not to adopt out black cats around Halloween because bad things can happen to them. So now we wait. I'm really hoping she turns up safe and sound, soon.

I have recently been working on some code for NetSurf which builds up an output buffer by repeatedly calling snprintf(); No great shock there, well understood trivial pattern that has been used repeatedly for ages. Gosh I feel silly now, in fact I was so convinced I was right I wrote a program to "prove" it.

A month ago, I published an article on the compared performances of stunnel, nginx and stud as SSL terminators. The conclusion was to use stud on a 64-bit system, with session caching and AES. stunnel was unable to scale properly and nginx exhibited important latency issues. I got constructive comments on many aspects. Therefore, here is the second round. The protagonists are the same but both the conditions and the conclusions have changed a bit.

Benchmarks The hardware platform remains unchanged:

• HP DL 380 G7
• 6 GB RAM
• 2 L5630 @ 2.13GHz (8 cores), hyperthreading disabled
• 2 Intel 82576 NIC
• Spirent Avalanche 2900 appliance

We focus on the following environment:

• Ubuntu Lucid, featuring a patched version of OpenSSL 0.9.8k with AES-NI builtin and enabled by default
• 2.6.39 kernel (250 HZ)
• 64-bit
• 1 core for HAProxy, 2 cores for network cards¹, 4 cores for SSL, 1 core for the system
• system limit of 100,000 file descriptors per process

On the SSL side, the main components are:

• 2048-bit certificates
• AES128-SHA cipher suite
• 8 HTTP/1.0 requests per client
• HTTP response payload of 1024 bytes

If you are interested in different conditions (32-bit, number of cores, 1024-bit certificates, proportion of session reuses), have a look at the previous article whose results on the matter are still valid. I only consider 2048-bit certificates because most certificates issued today are 2048-bit. In SP800-57, NIST advises that 1024-bit RSA keys will no longer be viable after 2010 and advises moving to 2048-bit RSA keys:

If information is initially signed in 2009 and needs to remain secure for a maximum of ten years (i.e., from 2009 to 2019), a 1024-bit RSA key would not provide sufficient protection between 2011 and 2019 and, therefore, it is not recommended that 1024-bit RSA be used in this case.

And the protagonists are:

• stud, @e207dbc5a3, with session cache enabled for 20,000 sessions, listen backlog of 1000 connections,
• stunnel 4.44, configured with --disable-libwrap --with-threads=pthread (configuration),
• nginx 1.1.4, configured with --with-http_ssl_module (configuration).

UPDATED: Configuration of nginx has been updated to switch to off both multi_accept and accept_mutex thanks to the feedback of Maxim Dounin on latency issues that were present in the previous article (and still present in the early version of this article). HAProxy (configuration) is used for stunnel and stud to add load-balancing. For each test, we want to maximize the number of HTTP transactions per second (TPS) while minimizing latency and unsucessful transactions. The maximum number of allowed failed transactions is set at 1 transaction out of 1000. The maximum allowed average latency is 100 ms².

Control case Below is the first comparison between stud, nginx and stunnel on plain Ubuntu Lucid. Like in previous benchs, stunnel is not able to scale, with a maximum of 400 TPS. However, early latency issues of nginx has been solved, thanks to the change in configuration. stud and nginx gets similar performance but, as you can see on the bottom plot (whose scale is logarithmic) stud starts with an initial latency of 40 ms. This is pretty annoying. I have tried some micro optimization to solve this issue but without luck. If latency matters for you, stick with stunnel or nginx (or find where the problem lies in stud). UPDATED: After reporting this issue, a fix has been commited. The culprit was Nagle s algorithm which improves bandwidth at the expense of latency. With the fix, performances are mostly the same but there is no latency penalty any more.

OpenSSL 1.0.0e When I published the first round of benchmarks, Micha Trojnara was dubious about the bad results of stunnel. He told me on Twitter:

I solved it! You compiled stunnel against a 4 years old OpenSSL with MT-unsafe SSL_accept. Upgrade OpenSSL and rebuild stunnel. This bug was fixed in OpenSSL 1.0.0b. I implemented a (slow) workaround, so stunnel doesn t crash with earlier versions of OpenSSL.

Therefore, I backported Ubuntu Oneiric OpenSSL 1.0.0e to Ubuntu Lucid³ and, as you can see yourself on the plot below, there is a huge performance boost for stunnel: about 400%! stud features a slight improvement too (about 8%) but still starts with a latency of 40 ms while nginx does not improve.

Intel Accelerator Engine Most Linux distributions are still using OpenSSL 0.9.8. For example, Debian Squeeze ships with OpenSSL 0.9.8o, Ubuntu Lucid with 0.9.8k and RHEL 5.7 with 0.9.8e. Therefore, they are not eligible to recent performance improvements. To solve this, Intel released Intel Accelerator Engine, which also brings, among other things, AES-NI support:

This is essentially a collection of assembler modules from development OpenSSL branch, packed together as a standalone engine. Standalone means that it can be compiled outside OpenSSL source tree without patching the latter. Idea is to provide a way to utilize new code in already released OpenSSL versions constrained by support and release policies limiting their evolvement to genuine bug fixes.

Alas, in my tests, there was no improvement compared to OpenSSL 1.0.0e (already patched with AES-NI support). stunnel comes with out-of-the-box support for additional engines. Just add something like this to your stunnel.conf:

engine=dynamic
engineCtrl=SO_PATH:/WOO/intel-accel-1.4/libintel-accel.so
engineCtrl=ID:intel-accel
engineCtrl=LIST_ADD:1
engineCtrl=LOAD
engineCtrl=INIT

For stud, you should grab support for engine selection from GitHub and for nginx, just specify the engine with ssl_engine.

Intel Performance Primitives In his great article Accelerated SSL , Simon Kuhn shows huge performance improvements by using Intel s IPP library, a library aimed at leveraging power of multi-core processors and including some cryptographic primitives and a patch to make use of them in OpenSSL. Unfortunately, this library is not free, not even as in free beer . The patch provided by Intel only applies on OpenSSL 0.9.8j. Simon updated it for OpenSSL 1.0.0d. It also applies with a slight modification to OpenSSL 1.0.0e. Look at Simon s article for instructions on how to compile OpenSSL with IPP. Simon measured 220% improvement on RSA 1024-bit private key operations by using this library. Unfortunately, we don t get such a performance burst with stud which exhibits a 15% improvement (but remember that private key operations only happen once every 8 transactions thanks to session reuse). Worst, with stunnel, performances are reduced by one third and nginx just segfaults. I think such a library is risky to use in production.

Hyperthreading During the previous tests, only half the capacity of each core were used. For stud, adding more workers per core only slightly improves this situation (less than 10% with 4 workers per core). Therefore, I thought using hyperthreading could rectify the situation here. In this case, stud, stunnel and nginx are allocated 8 virtual cores instead of 4. stud only got a small improvement of 5%, nginx a moderate improvement of 11% while stunnel got a significant improvement of 26%.

Conclusion Here is a quick recap of the maximum TPS reached on each tests (while keeping average response time below 100 ms). All tests were run on 4 physical cores with 2048-bit certificates, AES128-SHA cipher suite. Each client makes 8 HTTP requests and reuse the first SSL session.

Context	nginx 1.1.4	stunnel 4.44	stud @e207dbc5a3
OpenSSL 0.9.8k	1489 TPS	400 TPS	1492 TPS
OpenSSL 1.0.0e	1501 TPS	1561 TPS	1609 TPS
OpenSSL 1.0.0e + IPP	-	1101 TPS	1857 TPS
OpenSSL 1.0.0e + HT	1718 TPS	1973 TPS	1694 TPS

I also would like to stress that below 1500 TPS, stunnel adds an overhead of a few milliseconds while stud adds 40 milliseconds. With OpenSSL 1.0.0e and hyperthreading enabled, stunnel has both good performance and low latency on low loads to moderate loads. You may just want to limit the number of allowed connections to avoid collapsing on high loads. While in the previous round, stud was the champion and stunnel lagged behind, the situation is now reversed : stunnel is on top! UPDATED: As said earlier, the latency issue with stud has been solved. Performances remain mostly the same.

---

1. HAProxy and network cards don t need dedicated core for this kind of load. However, if you also want to handle non SSL traffic, those dedicated cores can get busy.
2. The real condition is more complex. Each point is considered valid if the corresponding average latency is less than 100 ms or if the average on the next 8 points is less than 100 ms. Temporary latency bursts are therefore allowed. We are not so forgiveful with failed transactions.
3. This is pretty straighforward: I just dropped multiarch support. I chose to use Ubuntu version of OpenSSL instead of upstream because there are some interesting patches, like automatic support of AES-NI.

Our friends Andrew and Janice finally tied the knot last Sunday, in Langkawi, Malaysia. They're Aussies currently living in New York, and Janice is of Malaysian descent, so I think part of the reason was to accommodate some Malaysian relatives that wouldn't be able to travel, and the other reason was that it was going to mean a bunch of people had to travel anyway, so why not travel somewhere a bit exotic? As my sister is getting married later this month in Brisbane, we decided to spare Zoe two massive international flights in close succession, and Sarah and Zoe flew out a few days ahead of me, and went to Brisbane, and then Zoe, Sarah and her mum flew to Langkawi from there, and I flew there from San Francisco, with the plan being for Sarah and Zoe to hang out in Brisbane for the 4 weeks in between weddings. It was the longest amount of travel I think I've ever done. I hadn't sat down and calculated what the travel time was beforehand, and when I got on the flight from San Francisco to Hong Kong, and they said it was going to be nearly 14 hours just to Hong Kong, I nearly wept. The only good thing about it was I didn't have to wrangle a toddler as well. From there, I had to get to Singapore, with a several hour layover, and then another flight from Singapore to Langkawi. I left SFO at 1:20am on Monday morning, and finally arrived at about 7am (San Francisco time) the following day. I didn't even bother getting off the plane in Hong Kong, it was only an hour and a half layover. I think the layover in Singapore was 5 hours, and it was a separate flight. Singapore airport at least was pretty good to kill time in. It was funny, I was reading Wired while I was killing time in Singapore, and they had an article, which included a side bar on 10 Best Airports to Get Stuck In, and I observed that getting to Langkawi and back involved using 4 of them. The flight into Langkawi was more eventful than usual. I was dozing a bit as we were coming in to land, and I woke up to the sensation of taking off again. I wondered if we'd had an aborted landing? Sure enough, soon after, the captain got on the public address and said that they'd had to abort the landing due to bad weather in Langkawi. He had pretty bad Engrish, thanking us for our frustration and saying something about fuel, so I didn't get a lot of the details. We proceeded to circle for a while before finally landing. I think the flight ended up landing something like an hour or more later than scheduled. So that was mildly exciting. Langkawi airport was one of those little "walk across the tarmac" places. I think I stood the closest to an operating jet engine that I ever have, as another aeroplane taxied in to a stop between my plane and the terminal while I was walking to it. Loud. Anyway, that was all just me getting there. Sarah had a bit of fun getting to Brisbane on her own with Zoe. She's now too long to sleep in an in-flight bassinet, and doesn't seem to like sleeping vertically in the Ergo Baby Carrier (possibly she was too hot in it). I think she got a bit of sleep lying across Sarah's lap, but Sarah didn't get much sleep. I think there was similar fun for the Brisbane to Kuala Lumpur flight, but at least she had two laps to lie across for that one. Sarah, Zoe and Sarah's mum arrived in Langkawi earlier in the day on Tuesday, and I made it to the resort at about 10pm (local time) and pretty much immediately crashed for the night. The Westin Langkawi was just fabulous. I don't think we've stayed at a resort since our honeymoon, and this resort was a whole other level compared to Heron Island. The rooms were very comfortable, and the resort was very accommodating of a toddler. Their Kids Club menu was excellent. The breakfast buffet (included in our room rate) was the most comprehensive breakfast buffet I have ever seen in a hotel. The only thing missing was bacon, being a Muslim country, but I can live without that. It was pretty easy to just fill up on breakfast, skip lunch and just have a light dinner. The on-resort dining prices were also very reasonable. The off-resort prices were even cheaper. The resort facilities in general were very comprehensive. Three pools. A children's play room. A well equipped gym and recreational area including squash courts. An extremely nice day spa. The thing I liked best about the whole destination wedding thing was all of the activities leading up to the actual wedding. The wedding was on the Sunday, and we had the Hen's and Buck's parties on Friday. Apparently Australia is the only place that calls it a Buck's party. The rest of the world calls it a Stag party, how about that? There was some last-minute changes to the Buck's party, and we ended up chartering this huge $2 million yacht for 4 hours and going for a cruise and doing some jetskiing and water sports. The captain was Aussie, so we all had a good chat with him. Apparently it's a corporate vessel, with an exclusive chartering arrangement with the Westin. On Friday night, we all went out to a seafood buffet dinner at the Yellow Cafe over at Cenang Beach. Most of the guys and girls already knew each other courtesy of the day's activities, so dinner involved a lot of meeting the other halves. What I really liked about all of the pre-wedding stuff was that by the time the wedding rolled around, you really felt like you knew a bunch of Andrew and Janice's family and friends, which I think made the whole thing feel a lot more intimate. Saturday was a recovery day. Sarah's aunties Glenda (who was in Singapore on business) and Vicki (who lives in Thailand) had joined us at the resort by this stage, so we were all knocking around together checking out the island. We took the cable car to the top, but unfortunately the sky bridge was closed due to the inclement weather. There was a lot of touristy stuff at the bottom of where the cable car was, and Zoe got to have an encounter with a very large python. She even tried to give it a kiss. One of the things that was surprising was how popular Zoe was with all of the locals and other Asian tourists. We could probably have charged for photographs. There was a little girl, who I thought was possibly a similar age to Zoe (turned out she was two and a half) and I asked her parents if I could take a photo of the two girls together, and no sooner had they sat down together and a virtual paparazzi materialised out of nowhere taking photographs. Similarly, all of the staff at the Westin were totally taken by Zoe, and wanted to touch her. To her credit, Zoe handled all of the extra attention pretty well. The wedding wasn't until 6pm on Sunday, so we did a 4 hour island hopping boat tour in the morning. That was a bit of an experience. It was nothing short of sheer bedlam trying to board the right boat at the wharf (I use the term lightly) and then the boat's captain had to arrange the passengers appropriately so as to keep the boat on an even keel. It was a narrow motor boat with a canopy cover over the back two thirds of it. First stop was Dayang Bunting Island, home of Pregnant Maiden Lake, where we stopped for 45 minutes. More bedlam ensued getting off the boat at the wharf there (there was veritable flotilla of tour boats all trying to load and unload at the same time). Monkeys abounded. They seemed incredibly tame. We were practically tripping over them. Zoe didn't seem to be as taken by the monkeys as I thought she would. It was a short walk up a reasonable flight of stairs to get to the lake, though some incredibly humid jungle, and once we got there, there wasn't a huge amount to do in the time we had available. So we dunked Zoe's feet in the lake a few times and then made our way back to the chaos at the wharf and got back on our boat. We stopped for a similar amount of time at another island with a pretty nice beach, and Zoe had enough time to a quick swim in the ocean with Sarah, and then we made our way back to the boat again to another spot where we watched sea eagle feeding. Heaps of eagles circling overhead would take turns to swoop down and grab fish and fly off again. It was impressive. I think I managed to snap some good action shots with the long lens. Then we had the wedding itself. It was on the beach out the front of the Heavenly Spa on the resort. Let me say, the Westin knows how to put a wedding together. The ceremony was as lovely as the location. For the reception, the one 5 bedroom villa on the resort was booked for the night. Dinner was a buffet on the lawn out the front (briefly delayed thanks to a rain shower) and then speeches and general partying happened around the terrace out the back of the villa. There were some beautiful speeches. Janice's brought a tear to my eye. Part of the whole package included something like a 10 person video crew that were running around capturing everything. It felt a bit surreal. It was definitely the most high-end wedding I've ever been to (sorry Scott and Julie, your "Wedding of the Century" has been eclipsed by the "Wedding of the Millennium"). Monday was a wind down day. Zoe mercifully gave us a sleep in until 8am. Our flights didn't leave until the evening on Tuesday, so after we checked out we went for a drive around the island to try and get Zoe to take a nap in the car. We ended up at the fruit farm, which to the best of my understanding is run by the government. Zoe had fallen asleep by this stage, and Sarah said she'd stay behind in the car and have a nap too. So her mum and I went on the tour. It was a fun little tour. There were only four of us on it. They drive you around the farm on the back of a truck and show you the various crops they have. They stop at a few places and give you a bunch of fruit samples, attempt to answer your questions, and take funny pictures of you. The favourite seemed to be to dangle a fruit on a knife up close in front of the camera while having the subject(s) in the background look like they're carrying an enormous fruit. We got back to the car to an upset Sarah and small group of locals milling around. Sarah had managed to lock Zoe in the car for about 30 minutes when she got out to make her a sandwich after Zoe had woken up from her nap. Fortunately the engine was running and the air conditioning was on, so there was no risk of Zoe overheating (on the contrary, she was a bit on the cool side). Some kind locals had somehow figured out which car rental company to call (it's possible there's only one) and someone came out with a spare key, so the crisis was averted just before we got back to the car. It's the first time Zoe's been locked in the car (it's pretty much impossible in the Prius) and it was just our luck that it'd happen in a foreign country! One of the saddest things about Langkawi was the amount of garbage floating around in the ocean, and washing up on the beaches. I was swimming in the ocean off the yacht while we were out on the Buck's party, and it was disgusting. The jetski was temporarily disabled due to sucking in something. We visited Black Sand Beach, which was supposed to be something of a tourist attraction. Covered in trash. Ian Kiernan would be sad. The captain of the yacht we were on for the Buck's party said it was all from Thailand and got flushed out of all the rivers and streams by the recent rain. Just goes to show how connected everything is. The house is very quiet without Sarah and Zoe, but my friend Liam is visiting from Zurich for a couple of weeks, so that's helping break the silence. I'm using the time to get a heap of things done that I don't otherwise get time to get done. Unfortunately the photos from the trip are only available on Facebook at the moment, but they'll eventually get uploaded here.

I just uploaded a snapshot of GNU Screen to Debian Experimental. The package (4.1.0~20110819git450e8f3-1) is based on upstream s HEAD whose most recent commit currently dates to the 19th of August 2011. While the upload fixes tons of bugs which accumulated over the past two years in Debian s, Ubuntu s and upstream s bug tracker, I don t yet regard it as suitable for the next stable release (and hence for Debian Unstable) since there s one not so nice issue about it:

• #644788: screen 4.1.0 can t attach to a running/detached screen 4.0.3 session

Nevertheless it fixes a lot of open issues (of which the oldest is a wishlist bug report dating back to 1998 :-) and I didn t want to withhold it from the rest of the Debian community so I uploaded it to Debian Experimental. Issues closed in Debian Experimental

• #25096: digraph table should be run-time configurable
• #152961: lacks tsl/fsl/dsl caps
• #176626: mini-curses type of interface for screen -r w/ multiple screens? (Fixed by suggesting iselect, screenie or byobu)
• #223320: does not switch mouse mode
• #344759: mishandles xterm control string to set window title
• #353090: please enable the built-in telnet
• #361274: cannot reattach to sessionname if there is another session with similar sessionname
• #450421: please raise MAXWIN to at least 100 (merged with #499273)
• #461107: Requires test -t 0 even when opening a new window on existing screen
• #481411: window created with -d -m silently ignores -X exec
• #488619: Session name string escape
• #496750: screen -d -m and -D -m segfault if setenv given with no value in a configuration file
• #532240: screen with caption SEGVs when resized to 1 line tall
• #541793: C-a h (mis)documented twice
• #558724: breaks altscreen
• #560231: Please remove restriction on user/login name length
• #578729: outputs spaces when refreshing/attaching a window with defbce on
• #591624: segfault when running screen -d -m with layout save default in .screenrc
• #603009: Updating the screen Uploaders list
• #612990: /etc/init.d/screen-cleanup: should check for existence of screen binary
• #621704: Fix slow scrolling in vertical splits
• #630535: manpage typo
• #641867: version bump (this bug report sparked the upload :-)

Issues which will be closed in Ubuntu

• #183849: update to git version of screen
• #315237: crashes with certain options and terminal sizes
• #582153: doesn t accept login names longer than 20 chars
• #588846: slow when using vertical split
• #702094: Copying and pasting from mutt includes many trailing spaces
• #786292: segfaults if using layout saving with -D -m
• #788670: segfault in screen/byobu in natty

Please test the version from Experimental If you are affected by one of the issues mentioned above, please try the version from Debian Experimental and check if they re resolved for you, too. Thanks to all who contributed! A lot of the fixes have been made or applied upstream by Sadrul Habib Chowdhury who also industriously tagged Debian bug reports as fixed-upstream . Thanks! Thanks also to Brian P Kroth who gave the initial spark to this upload by packaging Fedora 15 s git snapshot for Debian and filing bug although the upload is based on the current HEAD version of GNU Screen as this fixes some more important issues than the snapshot Fedora 15 includes. That way also two patches from Fedora/RedHat s screen package are included in this upload. (Co-) Maintainer wanted! Oh, and if you care about the state of GNU Screen in Debian, I d really appreciate if you d join in and contribute to our collab-maint git repository there are still a lot of issues unresolved and I know that I won t be able to fix all of them myself. And since Hessophanes unfortunately currently has not enough time for the package, we definitely need more people maintaining this package. P.S. Yes, I know about tmux and tried to get some of my setups working with it, too. But I still prefer screen over tmux. :-)

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (144.3 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg work While taking care of the last details for the hardening feature in dpkg 1.16.1, I have mailed debian-devel to find volunteers to handle a hardening release goal. The objective is to ensure a large number of packages have been converted/rebuilt to actually use the new hardening build flags. Then I prepared the draft of the announce of the dpkg 1.16.1 upload (aka Bits of dpkg maintainers sent to debian-devel-announce) which got expanded by Guillem to also cover new features since dpkg 1.15.7. update-alternatives got some refactoring by Guillem which resulted in a regression that has been fortunately discovered by Sven Joachim. I fixed that regression and did some further cleanup inspired by the root cause of this regression (see top 4 commits here). Note that Sven is one of the few persons who are running the git version of dpkg. Hopefully the number of tester will increase since I recently documented the APT repositories with autobuilt versions of dpkg in the wiki. At the end of the month, I started working on a bugfix release (what s going to be 1.16.1.1) by fixing some of the unavoidable problems discovered after an upload that accumulated more than 4 months worth of work (see top 4 commits here). The Debian Administrator s Handbook I spent countless hours finalizing the launch of the crowdfunding campaign for the Debian Administrator s Handbook and it went live on September 27th. So far it s on good track with more than 63% of the base funding already secured. But we still have a long way to go to reach the liberation goal (we re at 21%). It s still worth nothing that more than 55% of the money raised has been put in the liberation fund so there are many persons who care about getting the book freed. More than 250 persons are supporting the project currently with an average contribution of 38 EUR. I would have expected much less for the average contribution but many more supporters. I still hope we can get more people on board with the perspective of a good DFSG-free Debian ebook. Did you order your copy? If not, click here and fix this! By the way Paypal used to be required but it s no longer the case, you can support the project just with your usual credit card. Misc blog updates Over time, I have written many useful articles for Debian users and Debian contributors. But scattered in the history, they are somewhat difficult to find. To fix this I have created some index pages listing them. Check them out:

• Mastering Debian
• Contributing to Debian
• Debian Packaging Tutorials

Two new articles joined those pages this month: How to triage bugs in the Debian Bug Tracking System and Understand dpkg and don t get stuck with a maintainer script failure. While writing the first article, I noticed we lacked a good page showing the most buggy packages so I quickly created it (with the help of UDD): http://qa.debian.org/cgi-bin/bugs-by-source Misc packaging work I did a small update to the developer s reference. Luca Falavigna submitted a patch to clarify how one is supposed to deal with meta-packages (cf #569219), I improved it and integrated the result in the SVN repository. I upgraded nautilus-dropbox to version 0.6.9 and while doing this I discovered a bug in mergechanges (filed as #640782). I uploaded a new release of quilt mainly to add the Multi-Arch: foreign field so that it can satisfy dependencies of foreign packages (i.e. packages of a different architecture). Django released some security advisories (tracked in #641405) and since the maintainer did not deal with the issue, I stepped up to the task (I m a backup maintainer) and released the fixed version 1.3.1 to unstable. I took the opportunity to switch from python-support to dh_python2, and do some misc improvements to the packaging (see changelog). I wanted to update publican to a newer version but it turned out to be not possible because Debian doesn t have the latest version of docbook-xsl yet. I also discovered some bugs in the test suite and forwarded upstream the patch I created (see upstream bug). On top of this, fop was failing due to some java problem related to the introduction of multiarch. After having reported the bug, the java maintainers quickly released a fixed version. So now publican is ready in the git repository but it s waiting on the docbook-xsl update. I got in touch with the maintainer who said he would have the time to take care of it by mid-october. Thanks See you next month for a new summary of my activities.

One comment Liked this article? Click here. My blog is Flattr-enabled.

Today I was wondering that I had almost no new mail in my inbox in the morning. After a while I decided to have a look into the server logfiles . so I learned that postfix wasn t able to deliver mails via lmtp cause of:

Oct 7 07:45:56 post cyrus/lmtpunix[307]: DBERROR db4: Logging region out of memory; you may need to increase its size
Oct 7 07:45:56 post cyrus/lmtpunix[307]: DBERROR: opening /var/lib/cyrus/deliver.db: Cannot allocate memory
Oct 7 07:45:56 post cyrus/lmtpunix[307]: DBERROR: opening /var/lib/cyrus/deliver.db: cyrusdb error
Oct 7 07:45:56 post cyrus/lmtpunix[307]: FATAL: lmtpd: unable to init duplicate delivery database
Oct 7 07:45:56 post cyrus/master[754]: service lmtpunix pid 307 in READY state: terminated abnormally Seems like this can be fixed with:

/etc/init.d/cyrus2.2 stop
cat< /var/lib/cyrus/db/DB_CONFIG
set_cachesize 0 2097152 1
set_lg_regionmax 1048576
EOM
/etc/init.d/cyrus2.2 start Looking more closer into the logs, it turned out that this trouble started last night when I connected with a client running the soon to be released Ubuntu Oneiric Ocelot using the new kmail2. So it looks like the KDE/Ubuntu folks broke again kmail (or any KDE subsystem), as it also has troubles when migrating over from kmail(1) and it looks like it s not able to access most of the imap subfolders. Well done!

Would MTAs please stop sending hi-bit7 messages to other MTAs which do not advertise 8BITMIME! Recode it to QP or BASE64, damnit! The receiving MTA is entitled to strip the set bit7, which kinda makes things hard to read (while I know how to deal with blvde Stra_e, the advent of UTF-8 makes that blC6de StraC?e, introduces C0 control characters and makes typographic quotation marks into NUL-containing octet sequences (as their UTF-8 representation contains 0x80 octets) which let every sensible MDA terminate the line there). I even filed in the Debian BTS against the BTS (might be Drexim's fault, though). Would MUAs please default to Quoted-Printable! And mail hosters should use the same server when retrying delivery, to benefit greylisting. Or at least publish a list of outgoing IPv4 addresses they use for sending. Or use IPv6. Oh, and STARTTLS, while we are on my wishlist. It's a sad day when the percentage of correctly encoded eMail messages in my INBOX is smaller than that of my Spambox...

python 2.7.2-7 wheezy all
python 2.7.2-7 sid all This took a lot of work from a lot of people. Thank you everyone. Fortunately there won t be a python2.8, so we don t have to do this again.

Mankind, it would appear, owe a great deal of their evolutionary advantage to using tools. This ability appears to have been massively amplified by our creation of machine tools.

Woodchuck and FrOSCon

At the end of August, I attended FrOSCon in Bonn again, after skipping it last year. The evening before FrOSCon however, I visited Neal Walfield, his wife Isabel and their little son Noam in D sseldorf. Besides having a great time and a lovely dinner, I was most impressed by their collection of Maemo devices (they had at least two N770s, an N900 and, to my jealousy, an N950) which Neal is doing research on these days. He works on woodchuck, which is a project investigating how to improve data availability on mobile devices and our conversation prompted him to implement ATP Woodchuck, which makes smarter decisions when to run APT upgrade on your Maemo device then the standard updater. As part of the research, they also run a user behaviour study which I joined, where one installs a client which records various data off your N900 and sends them anonymized (he seems to be doing a good job at that) to figure out how people use their mobile devices and hopefully enhance the experience. So if you have a N900, you should consider joining the study so they get better data.
The next day, I picked up Martin Michlmayr nearby and we headed for FrOSCon. I was quite impressed by the Makerbot at the Tarent booth, but I still don't know what they are really doing and why they had it on display... In the afternoon, I attended a couple of talks in the PostgreSQL developer room and a talk about a big OpenVPN deployment, before ending the day with the excellent as always social event barbeque. On Sunday, I went to quite a few talks, but I thought that two of them were particularly interesting:
Michael "Monty" Widenius of MySQL gave a talk titled "Why going open source will improve your product" about starting businesses on an open source project, or how business can/should open-source their product. Besides a detailed discussion about the various forms of Open Source licenses and the Open-Core model, he proposed the idea of "Business Source" (see slide 20 of his presentation), where a startup would distribute the source code under a non-commercial (but otherwise open-source) license with the explicit guarantee that the license would be changed to a true FLOSS license at some defined point in the future, giving the company a head start to develop and nurture their project. I asked whether this has been already implemented in practise and how the community could be sure that e.g. lawyers after a hostile takeover would not just remove that part of the copyright notice, as long as a true distribution under a FLOSS license has not happened yet. Monty wasn't aware of any real-word cases, and he did not seem to be concerned about this and said the original intent would be clear in a possible court case. This was the first time I heard about this approach, I wonder how other people think about it, whether it would work in practise and be a useful thing to have?
Second, I attended a talk by Gregor Geiermann, a Ph.D. student in linguistics on "Perceptions of rudeness in Free Software communities". He conducted an online survey about the perceived rudeness of several forum thread posts on Ubuntu Forums. Survey participants were first asked a couple of generic questions about their gender, nationality etc. and were then presented with a series of posts. For each post, they were asked to rate how rude they thought it was on a scale of 1 to 5 and they also had the possibility to highlight the parts of the post they considered rude as well as add comments. He presented a neat web application for analyzing the results, which makes it possible to select different groups (he did male vs. female and Americans vs. Germans in the talk) and have their overall rudeness ratings as well as the highlighted texts visualized as different shades of blue. Comments can be easily accessed. There were quite a few interesting differences e.g. in how Germans perceived rudeness compared to Americans (RTFM comments were considered less rude by Germans for example, IIRC). In response to my question, he said he intended to release the web application as open source and this might be an interesting tool for FLOSS projects to analyze how their public communication channels are perceived by various groups. Unfortunately, I cannot find any other resources about this on the web as of today, so I should try to contact him about it at some point.

The MeeGo community is frustrated with the news of the MeeGo brand being abandoned. Some are understandably angry or otherwise not happy about how Linux Foundation, Intel handled the Tizen announcement and community in general - or more like how they didn't handle it at all.Last week Openmind 2011 happened to be arranged in Tampere on the very same day as Tizen announcement came alive. It was good in the way that it lead to the fact that Nomovok's CEO Pasi Nieminen was able to initiate the "Reigniting MeeGo" session not just by talking vague things about future, but actually about the process which led to Tizen and the unfortunately brief initial PR about it. Pasi is intense on emphasizing the quality and role of Qt in Tizen as well, even though officially Tizen is all about HTML5 and apparently from Samsung's part at least EFL is provided as a native toolkit. However, the promise of Tizen compared to MeeGo is reportedly that the toolkit is not specified in compliancy documents, so HTML5 with WAC is the main/only "3rd party apps" layer whereas others can be offered case-by-case. This means that unlike before, the underlying system can be built on top of practically any distribution (theoretically) and using whatever toolkits and other techniques wanted. Obviously the "Nordic System Integrators" are probably all very keen of using Qt to produce more of Nokia N9 quality user experiences in various products.

Taking the corporate hat off, I as a community member am also puzzled. The only reason I was not completely blown by the news was that I didn't yet manage to get involved in MeeGo community on a daily basis, since I'm involved with a dozen communities already. Instead I've been more like scratching the surface with MeeGo Network Finland meetings, IRC activity, OBS usage for building a few apps for MeeGo Harmattan and MeeGo proper etc. But I can somewhat understand how people like Jarkko Moilanen from meego-fi feel. They have given a _lot_ to the MeeGo community and brand, all taken away without hearing or pre-notice.

So where to now for MeeGo community? Tizen is one obvious choice. However, for all the talks that even I started this post with, Tizen is still vaporware today, and the dislike of how community is being treated might make it easy to consider other options. Also, if Tizen's reference implementation has lesser meaning, it might also mean less to actually be "in" the Tizen community than in MeeGo. I met Jos Poortvliet at Openmind, and he invited people to openSUSE. There is a lot of common ground with MeeGo and openSUSE - strong OBS usage, RPM packaging, community side focused on KDE and therefore Qt.

I would like to now point similarly to Debian! If one is tired about corporate interests and not listening to community, there is no match for Debian's 15+ years history, purely volunteer based, trust based organization, and first of all scope. While openSUSE has traditionally focused on desktop (even though like Jos pointed out they are open to all new contributions and projects), Debian has always had the "universal" scope, ie. no boundaries besides producing free software operating system for various purposes. There are over 10 architectures maintained at the moment, including the ARM (different ports for ARMv4 and hard-float ARMv7) and x86 from MeeGo world. There are even alternative kernels to Linux, mainly the GNU/kFreeBSD port. There are multiple relevant plans and projects like the Smartphones wiki area, most noticeably Debian on Neo FreeRunner. I have run Debian on my primary mobile phone for over 2.5 years, although now in the recent months I've had dual-SIM in my Nokia N950 as well (Debian not yet running on Nokia N950 or Nokia N9 - but it can and will be done!).

What Debian may lack in both good and bad is corporate funding, if you don't count the still quite respectful contributions from Ubuntu to Debian (it's in Ubuntu's interests to contribute as much possible back to Debian, so that the delta remains small). For each and every aspect, it needs a volunteer - there are a thousand volunteer Debian Developers, and at least a double of that of people without the official DD status but who still maintain a package or two among the 25000+ packages in Debian. That means also that one my find it more lucrative to join a project that has paid people to do some of the "boring parts", more of fancy web tools, including for bug handling and build systems like the OBS (which I do love by the way). On the other hand, there is no other project in my opinion where what you do really matters as much.

To find out more about Debian from MeeGo perspective, please see the recent mailing list post Mobile UXes - From the DebConf11 BoF to the stars where I wrote most of the MeeGo (CE) part when I was asked to and known of my MeeGo involvement.

Last but not certainly least, there is the Mer project - originally "maemo reconstructed", ie. making Nokia's "not really distro" into a real distro by filling in the void places. Now it's obviously MeeGo reconstructed, and they aim to be the MeeGo they always wanted MeeGo to be! Read the post for details from Carsten Munk and other key Mer people. They share the love for Qt, and want the core to be as lean as possible. They also aim to incorporate the most community like aspect from MeeGo - MeeGo CE - as the reference vendor in Mer. They also aim to be Tizen compliant - and when Tizen comes alive, I wouldn't see why the Tizen reference implementation couldn't be used for saving resources. Maybe Nomovok and/or others could offer the Qt maintaining part.

So, it might be that Tizen itself is enough for most people's needs. The key point however in this post is not to fall in agony if one corporate based project takes big turns - it has happened before, it will happen in the future. There are always enough political and business reasons from some points of view to do Big Changes. But the wider community is out there, always, and it's bigger than you think. You should consider where you want to contribute by asking yourself why you are/were part of for example the MeeGo community. Aaron Seigo from KDE asked us all this question in the Openmind MeeGo Reignited session, and I think it's good to repeat.

Quite a belated English blog (after the Thai version), due to busy personal life lately. I had visited Yangon during 4-11 Sep. to give some talks and tutorials on Debian packaging and mirroring. And I've shared some information with community. The visit was initiated by Ngwe Tun and the Myanmar L10N team. I found later that a Facebook event had been created for this. Localization The first day was a comparison between Myanmar and Thai supports in GNU/Linux, in which I briefed the status on Thai side, and Thura Hlaing on Myanmar side. It was nice that we had the Myanmar Computer Federation (MCF) director presiding the meeting til the end. That means GNU/Linux support has been awared at executive level. According to Thura, Burmese has gained support in GNU/Linux quite well. On the rendering side, all the reordering for the logical order is normally done with pure GSUB in the fonts, without special processing on the rendering engine. This is suboptimal in principle, but it's the most effective way, as Windows redering engine itself does not yet support Myanmar, either. For input method, Myanmar XKB map has been available in xkb-data for a long time, but to serve users' familarity with visual order typing, some reordering input methods have been developed, based on keymagic and ibus. But all are not context-sensitive like what's done for Thai in other frameworks. Fortunately, with the surrounding text API recently added to ibus, this has become possible. One unusual requirement for Myanmar script editing is the caret movements. It needs to move syllable-wise, not character-wise nor cluster-wise. So, I suggested them to have a look on UAX #29 to see how it should be amended. Myanmar locales are already done, both for GNU C library and CLDR. And even a GNOME applet for Myanmar lunar calendar is also available. This latter thing is what Thai can learn from. Burmese word segmentation is not supported in general. But R&D works have been done for this in its NLP lab. A serious issue left to solve is the existing abuses of Unicode. In Myanmar, there exist at least 14 variations of font hacks, abusing some free slots in Unicode charts as pre-composed clusters for information interchange (not for font internals), making plain text interchange impossible without the proper font for rendering. For program translation, the new Myanmar L10N team is trying to request for a mass submission to the current GNOME team. And for Debian, Thura Hlaing and Ngwe Tun has already started the translation process with Christian's help. Along my stay, I could see the team actively discussing on the IT glossary, trying to settle down the translated terms. This looked very fun. Debian Then, the next three days were a workshop on Debian packaging, where I have presented the basics of Debian package building, uploading, quality-controlling, modifying, creating and delivering. This aimed toward the development of a local distribution based on Debian. Each day in the afternoon was the time for setting up a Debian mirror, not only for convenient local distro developement, but also for general users. This is important because internet penetration is still low in Myanmar. The main media for software distribution is CD/DVD, which means only stable version of Debian can be spread, which is not good for desktop users. Having a mirror should improve the situation somehow. It should make dist-upgrading to testing/unstable easier. And it should make CD snapshotting using local distributions easier, too. For this, I also presented another quick slide on Debian mirroring & caching. In the last day, I was introduced to the staffs of Myanmar NLP Lab and their projects, which include Myanmar OCR (based on tesseract), information retrieval, machine translation, and other lingustic resources like dictionary, lexicon and text corpus. Furthermore, I was also offerred technical helps on developing a Lao/Esaan Tham font for a Lao and North Eastern Thailand variation of Tham script, which is Mon-based and is closely related to Myanmar script. (See some sample transliterations if you are curious how it looks like. It was part of my hacking during DebConf11 travelling.) Currently, its OpenType support is quite sufficient, but it still renders poorly on Mac OSX. To cope with this, I was given a Mac Mini as a present from Myanmar for its development, as well as some explanations on AAT features from a Myanmar font developer. And I am very grateful for that.