Have you ever wondered how to start getting involved in Debian/Ubuntu? Do you enjoy discovering new games and playing them? You might want to come to the games screenshot party! We hope that the party will be a fun, easy, low-commitment way to get involved. The Debian/Ubuntu games team is organising a half-day screenshots party on the weekend of 25th-26th February for creating screenshots for all the games that are available in Debian/Ubuntu. If you are interested in attending, please add your availability to the poll linked from the announcement so that we can get some idea of attendance and when is a good time for the people who are interested. Look forward to lots of game playing, screenshots and a merry time, hope to see you all there!

I've just spent several days trying to adapt git-annex to changes in ghc 7.4's handling of unicode in filenames. And by spent, I mean, time withdrawn from the bank, and frittered away. In kindergarten, the top of the classrom wall was encircled by the aA bB cC of the alphabet. I'll bet they still put that up on the walls. And all the kids who grow up to become involved with computers learn that was a lie. The alphabet doesn't stop at zZ. It wouldn't all fit on a wall anymore. So we're in a transition period, where we've all learnt deeply the alphabet, but the reality is much more complicated. And the collision between that intuitive sense of the world and the real world makes things more complicated still. And so, until we get much farther along in this transition period, you have to be very lucky indeed to not have wasted time dealing with that complexity, or at least having encountered Mojibake. Most of the pain centers around programming languages, and libraries, which are all at different stages of the transition from ascii and other legacy encodings to unicode.

• If you're using C, you likely deal with all characters as raw bytes, and rely on the backwards compatability built into UTF-8, or you go to long lengths to manually deal with wide characters, so you can intelligently manipulate strings. The transition has barely begin, and will, apparently, never end.
• If you're using perl (at least like I do in ikiwiki), everything is (probably) unicode internally, but every time you call a library or do IO you have to manually deal with conversions, that are generally not even documented. You constantly find new encoding bugs. (If you're lucky, you don't find outright language bugs... I have.) You're at a very uncomfortable midpoint of the transition.
• If you're using haskell, or probably lots of other languages like python and ruby, everything is unicode all the time.. except for when it's not.
• If you're using javascript, the transition is basically complete.

My most recent pain is because the haskell GHC compiler is moving along in the transition, getting closer to the end. Or at least finishing the second 80% and moving into the third 80%. (This is not a quick transition..) The change involves filename encodings, a situation that, at least on unix systems, is a vast mess of its own. Any filename, anywhere, can be in any encoding, and there's no way to know what's the right one, if you dislike guessing. Haskell folk like strongly typed stuff, so this ambiguity about what type of data is contained in a FilePath type was surely anathama. So GHC is changing to always use UTF-8 for operations on FilePath. (Or whatever the system encoding is set to, but let's just assume it's UTF-8.) Which is great and all, unless you need to write a Haskell program that can deal with arbitrary files. Let's say you want to delete a file. Just a simple rm. Now there are two problems:

1. The input filename is assumed to be in the system encoding aka unicode. What if it cannot be validly interpreted in that encoding? Probably your rm throws an exception.
2. Once the FilePath is loaded, it's been decoded to unicode characters. In order to call unlink, these have to be re-encoded to get a filename. Will that be the same bytes as the input filename and the filename on disk? Possibly not, and then the rm will delete the wrong thing, or fail.

But haskell people are smart, so they thought of this problem, and provided a separate type that can deal with it. RawFilePath hearks back to kindergarten; the filename is simply a series of bytes with no encoding. Which means it cannot be converted to a FilePath without encountering the above problems. But does let you write a safe rm in ghc 7.4. So I set out to make something more complicated than a rm, that still needs to deal with arbitrary filename encodings. And I soon saw it would be problimatic. Because the things ghc can do with RawFilePaths are limited. It can't even split the directory from the filename. We often do need to manipulate filenames in such ways, even if we don't know their encoding, when we're doing something more complicated than rm. If you use a library that does anything useful with FilePath, it's not available for RawFilePath. If you used standard haskell stuff like readFile and writeFile, it's not available for RawFilePath either. Enjoy your low-level POSIX interface! So, I went lowlevel, and wrote my own RawFilePath versions of pretty much all of System.FilePath, and System.Directory, and parts of MissingH and other libraries. (And noticed that I can understand all this Haskell code.. yay!) And I got it close enough to working that, I'm sure, if I wanted to chase type errors for a week, I could get git-annex, with ghc 7.4, to fully work on any encoding of filenames. But, now I'm left wondering what to do, because all this work is regressive; it's swimming against the tide of the transition. GHC's change is certainly the right change to make for most programs, that are not like rm. And so most programs and libraries won't use RawFilePath. This risks leaving a program that does a fish out of water. At this point, I'm inclined to make git-annex support only unicode (or the system encoding). That's easy. And maybe have a branch that uses RawFilePath, in a hackish and type-unsafe way, with no guarantees of correctness, for those who really need it.

---

Previously: unicode eye chart wanted on a bumper sticker abc boxes unpacking boxes

Sometimes two campaigns that I care about a lot pick the same day to hold an awareness-raising drive. It happened again on Tuesday. The one I took part in was advertising the Stop ACTA London Protest on Sat 11 Feb. The Anti-Counterfeiting Trade Agreement (#ACTA) is a plurilateral international agreement on enforcement of so-called intellectual property rights copyrights, trademarks and so on. It ll have major implications for freedom of expression, access to culture and privacy. It will also harm international trade and stifle cooperation. (More background at EDRI or a fairly large AJE page thanks to Occupy Bristol for the AJE link.) So the one I didn t support at the time was the Move Your Money UK launch day. That s a great idea too, suggesting that if we, the 99%, are actually unhappy with the big banks and their titled leaders, we should move as much as possible out of those banks and into financial institutions that we control. As you might expect for someone whose first memory of mutuals is a trust account at the local building society, I support that too. I still have building society accounts, as well as banking with the co-op bank and recently joining my local credit union. I ve moved my money. Why don t you? I didn t try to support both campaigns simultaneously on social networks because I thought it would reduce the number of people who saw my message. I backed the ACTA protest because a lot of my networks were already discussing Move Your Money and I thought Stop ACTA would benefit more. Was that the right decision? Who can tell? What would you have done?

On Wednesday, February 1, a new virtual server May First/People Link recently rented went offline. We contracted the virtual server through Server4All because we need their un-metered 100Mbit connection to help us handle the bandwidth for Sahara Reporters, one of the most important independent news sources for Saharan Africa. With the server offline, the web site was down as well. We scrambled to setup alternative caching servers to handle the bandwidth. When I logged into our control panel, I saw the message: This virtual server has been suspended by the administrator. Please contact support. I immediately contacted support and then received the message:

Hello
We have received the following complaint associated with your server/service.
IP: 76.73.121.164
To prevent any further abuse we have suspended this service. In order to
resume, we request you to cooperate with our investigation as promptly as
possible. Please respond to us with the following details:
(1) What has caused the complaint
(2) What is the server used for. Purpose?
(3) How can you resolve the complaint and make sure it will not be repeated.
Depending on the nature of the complaint and your response, we will put back
the server online.  Please note, this has violated our Terms Of Service. We
expect your response within 24 hours, otherwise your account will be
terminated permanently.  Thank you

What?? What complaint?? I followed up but had to wait til the next day to get the response.

Here is the full log,
An email advertizing the Domain Name: saharareporters.com
has been sent to the blacklist.woody.ch spamtrap.
This Domain does resolve to IP addresses one of which your are responsible:
76.73.121.164
Please investigate why this Domain has been advertized.
Attached you find the headers and reports in ARF for automatic processing.
Feedback is appreciated.
Actual listing periods:
Bounce: 1 Hour in DNS.
Whitelisted IP: Not lised in DNS.
Spam: 24 hours in DNS.
Every Hit: 14 days in evidence DB.
For any questions or Feedback, contact abuse@woody.ch
From: is intentionally set to a bit-bucket.
Kind regards
-Benoit Panizzon-

There is no attachment. I went to woody.ch and it was in German. Then tried blacklist.woody.ch, but no luck. Finally I found the Woody's World Blacklist Page. I plugged in our IP address into their checker and I got:

Output from the Check, if empty the IP is not listed.
164.121.73.76.[name of the blacklist] being tested.
Host 164.121.73.76.blacklist.woody.ch not found: 3(NXDOMAIN)
Host 164.121.73.76.blacklist.woody.ch not found: 3(NXDOMAIN)
Host 164.121.73.76.rbl.maps.vix.com not found: 3(NXDOMAIN)
Host 164.121.73.76.rbl.maps.vix.com not found: 3(NXDOMAIN)
Host 164.121.73.76.relays.mail-abuse.org not found: 3(NXDOMAIN)
Host 164.121.73.76.relays.mail-abuse.org not found: 3(NXDOMAIN)
;; connection timed out; no servers could be reached
;; connection timed out; no servers could be reached
;; connection timed out; no servers could be reached
;; connection timed out; no servers could be reached
Host 164.121.73.76.relays.ordb.org not found: 3(NXDOMAIN)
Host 164.121.73.76.relays.ordb.org not found: 3(NXDOMAIN)
Host 164.121.73.76.dev.null.dk not found: 3(NXDOMAIN)
Host 164.121.73.76.dev.null.dk not found: 3(NXDOMAIN)
Host 164.121.73.76.blackholes.five-ten-sg.com not found: 3(NXDOMAIN)
Host 164.121.73.76.blackholes.five-ten-sg.com not found: 3(NXDOMAIN)
Host 164.121.73.76.bl.spamcop.net not found: 3(NXDOMAIN)
Host 164.121.73.76.bl.spamcop.net not found: 3(NXDOMAIN)
Host 164.121.73.76.relays.visi.com not found: 3(NXDOMAIN)
Host 164.121.73.76.relays.visi.com not found: 3(NXDOMAIN)
164.121.73.76.blacklist.spambag.org has address 208.91.197.182
164.121.73.76.blacklist.spambag.org descriptive text "v=spf1 -all"

So, Woody's World thinks we are listed in spambag.org. I went to spambag.org and learned that the domain is for sale. I then tried blacklist.spambag.org and got the same page. This page has many links all pointing to advertisements. The "RBL List" link takes me to a page advertising "5 foods you must not eat." Next, out of curiousity, I tried Mxtoolbox. I got one hit from Barricuda. Barricuda says the reputation of the IP address is "poor". Why? According to Barricuda, the reasons could be:

• Your email server contains a virus and has been sending out spam.
• Your email server may be improperly configured.
• Your PC may be infected with a virus or botnet software program.
• Someone in your organization may have an infected PC with a virus or botnet program.
• You may be using a dynamic IP address which was previously used by a known spammer.
• Your marketing department may be sending out bulk emails that do not comply with the CAN-SPAM Act.
• You may have an insecure wireless network which is allowing unknown users to use your network to send spam.
• In some rare cases, your recipient's Barracuda Spam Firewall may be improperly configured.

Keep in mind, this IP address is not used for sending email. It's just the web site. I then took a step back and re-read the complaint and noticed that it says that the domain name saharareporters.com was listed in a spam email. Hm. More concerted searching for the terms "woody spamtrap blacklist" and I found a pattern in URLs that suggested I plug in the following: http://news.scoutnet.org/rblhostlist.php?id=saharareporters.com.uri And sure enough, there was a result. In short, it was a classic Nigerian Oil scam in which the person claims to be "JAMES IBORI ex-governor of DELTA STATE oil city." The scammer acknowledges that he has been arrested, but promises lots of cash to the person who can help him. In an effort to boost their credibility, the scammer included a link to a Sahara Reporters article about the real James Ibori. And that, my friends, is enough to have one of the most prominent independent African news organization taken offline. But, Sahara Reporters shouldn't necessarily feel singled out. Sahara Reporters should feel singled out. They exist to illuminate news from Africa. They were taken offline because a series of individuals don't know the difference between a prominent independent African news service and a criminal scammer. To most of the Internet, Nigeria and email scams are synonymous. That has to change. Although Sahara Reporters is particularly vulnerable, any site hosted with Server4All can potentially be taken down. All you have to do is write a fake spam/scam email, including a link to the web site you want to be taken offline, and then send that email to: listme@blacklist.woody.ch. I'm currently following up with both Woody's World and Server4All. However, once this particular issue is resolved, we're left with a much bigger and ominous problem. If your hosting provider (or their upstream provider) takes your site offline when it receives a complaint first and then asks questions second, you have a big problem. All of our legal fights over our rights to keep content online are moot if our providers, without any legal pressure to do so, still take down our services based on spurious complaints.

There is a Debian bug squashing party (BSP) in Perth, Western Australia being organised for the weekend of 10-11th of March. It will be held at the University of Western Australia in loft of the University Computer Club (UCC) in the student guild building. Sadly it is a bit far to travel for the majority of Debian contributors (and they probably wouldn't enjoy being upside down) but hopefully we can attract some locals and get them addicted to fixing bugs and contributing to Debian and the FLOSS community in general. Come one, come all, lets squish some bugs and get Debian into better shape for the coming freeze in June for the release of Debian 7 (wheezy). Thanks go to the UCC folks for the venue and to PLUG folks for helping with organisation and promotion of the event.

I wanted to give a final update of my experiment with adding symbols files to C++ library packages. In the end, I reverted the changes and have gone back to not providing a symbols file, and instead just using shlibs. Some of this is because of the general state of the available tools, and some of it is due to the nature of the packages I was working on. This set of packages has frequent SONAME bumps from upstream, so backward compatibility across Debian stable versions can't happen anyway. They also don't use symbol export control, which means that the number of exported symbols is quite large and contains a lot of things leaked from internal objects. But there are also tool issues. The biggest that I ran into is that symbols appear and disappear in the export list with different versions of the compiler, and the pkg-kde-tools utilities, while excellent, still interpret those changes as architecture-specific changes. So the symbols file accumulates supposedly arch-specific variations, which are actually about what version of the compiler happened to be installed on that buildd when the package was built. This also means that if a package that has had its symbols file updated for one architecture is built again on the same architecture but on another buildd with a different g++, it will often FTBFS since a different set of symbols will be present. Obviously, this is too fragile to be maintainable. Further debian-devel discussion pointed out that these symbol variations are probably all inline functions, where the compiler may or may not output a weak version of the symbol if it chooses not to inline it in some particular case. The right thing to do for these libraries (not all, since there are other uses of weak symbols) is to mark all weak symbols as optional and not care if they randomly appear and disappear. There are also some 32-bit vs. 64-bit variations that are not captured by the subst mechanism, which resulted in the symbols file developing a list of architecture restrictions that amounted to "all 32-bit systems" or "all 64-bit systems." These explicit lists are also fragile, and will break with each new architecture introduced in Debian. I filed three bugs with pkg-kde-tools with suggestions for improving the tools for other people going forward: #657805 pkgkde-getbuildlogs gets truncated logs
#657806 representation of covariant return thunks
#658333 option to mark weak symbols as optional but I think that the level of work and remaining fragility doesn't make sense for a lot of C++ libraries, at least right now without more direct support in dpkg-gensymbols and other tool improvements. I'm therefore also planning on changing the proposed Policy patch for symbols to make it more clear that shlibs is an acceptable alternative for C++, and to patch Lintian to suppress the info tag for no symbols file for C++ libraries.

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (213.68 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg The biggest change I made is a small patch that brings to an end years and years of recurring discussions about the build-arch and build-indep targets of debian/rules (see #229357). Last year the technical committee took this issue in its hands (see #629385) but it failed to take any resolution. Fortunately thanks to this we got some concrete numbers on the colateral damages inflicted on the archive for each possible approach. In the end, Guillem and I managed to agree on the way forward. The remaining of what I did as dpkg maintainer has not much to do with coding. I reviewed the work of Gianluca Ciccarelli on dpkg-maintscript-helper who is trying to provide helper functions to handle migration between directories and symlinks. I also reviewed a 2000-lines patch from Patrick Schoenfeld who s trying to provide a perl API to parse dpkg log files and extract meaningful data out of them. I updated the dpkg-architecture manual page to document the Makefile snippet /usr/share/dpkg/architecture.mk and to drop information that s no longer releveant nowadays. I reviewed a huge patch prepared by Russ Alberry to update the Debian policy and document the usage of symbols files for libraries. As the author of dpkg-gensymbols, I was keen to see it properly documented at the policy level. I brought up for discussion a detail that was annoying me for quite some time: some copyright notices were embedded in translatable strings and updating them resulted in useless work for translators. In the end we decided to drop those notices and to keep them only at the source level. I updated my multiarch branch on top of Guillem s branch several times, all the fixes that were in my branch have been integrated (often in a modified form). Unfortunately even if the code works quite well, Guillem doesn t want to release anything to Debian until he has finished to review everything and many people are annoyed by the unreasonable delay that it imposes. Cyril Brulebois tried to release a snapshot of the current multiarch branch to experimental but Guillem has been prompt to revert this upload. I m somewhat at a loss in this situation. I offered my help to Guillem multiple times but he keeps doing his work in private, he doesn t share many details of his review except some comments in commit logs or when it affects the public interface. I complained once more of this sad situation. Debian Package Maintenance Hub That s the codename I use for a new infrastructure that I would like to develop to replace the Package Tracking System and the DDPO and several other services. I started to draft a Debian Enhancement Proposal (DEP), see DEP-2, and requested some comments within the QA team. For now, it looks like that nobody had major objections on the driving idea behind this project. Those who commented were rather enthusiastic. I will continue to improve this DEP within the QA team and at some point I will bring the discussion to a larger audience like debian-devel@lists.debian.org. Package Tracking System Even if I started to design its replacement, the PTS will still be used for quite some time so I implemented two new features that I deemed important: displaying a TODO notice when there is (at least) one open bug related to a release goal, displaying a notice when the package is involved in an ongoing or upcoming transition. Misc packaging tasks I created and uploaded the dh-linktree package which is a debhelper addon to create symlink trees (useful to replace embedded copies of PHP/JavaScript libraries by symlinks to packaged copies of those files). I packaged quilt 0.50. I helped the upstream authors to merge a Debian patch that had been forwarded by Martin Quinson (a quilt s co-maintainer). I packaged a security release of WordPress (3.3.1) and a new upstream release of feed2omb and gnome-shell-timer. I prepared a new Debian release of python-django with a patch cherry-picked from the upstream SVN repository to fix the RC bug #655666. Book update We re again making decent progress in the translation of the Debian Administrator s Handbook, about 12 chapters are already translated. The liberation campaign is also (slowly) going forward. We re at 72% now (thanks to 63 new supporters!) while we were only at 67% at the start of January. Thanks See you next month for a new summary of my activities.

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

Just to say it out loud in the hope someone else is interested in it:

I've been studying and I'm intentioned to write an open sourced Natural Interaction module for OpenNI or libfreenect which is able to do skeleton and gesture recognition.

Ideally and in the *very* long term I'd like to have something very close in functionalities to what the closed sourced NITE is for OpenNI, but to begin with a simple shape or movement recognition module will make me happy.

I don't know anything about the subject, including the basic of image manipulation, but if someone would like to have some fun thinking about it, let's join the forces!

Hello Planet :) You may have seen my ancient blog posts pop up on the planet when XTaran was nice enough to add me to the planet's aggregation. Not quite sure why ikiwiki/planet decided to do this, but I will try to find out. If you have an idea, which does not involve re-spamming the feed, do let me know. In any case, expect mostly shell-related posts from me. And, as every year, I will be going to FOSDEM.

First of all, take this blog post as a rant from developer. I don't expect that this will change anything in how people ask me questions. Anyway before you write me email with some questions, please check following easy bits:

1. Have you tried to write your question into Google?
2. Most projects have documentation, have you looked at it?
3. There are mailing lists or discussion forums, do you really need to write directly to me?
4. Writing subject like "!important" or ALL IN CAPS will work other way than you probably expect.
5. Yes I have more email addresses, that does not mean you should write to all of them.

If you do follow these basic rules, you might get more help than usual. If you are interested in knowing more, there is famous How To Ask Questions The Smart Way which will tell you more information than I did in this rant.

Filed under: English Gammu Phpmyadmin 0 comments Flattr this!

Over the years, I ve always uploaded my local git repo (git clone bare myrep repo.git) as a tarball, which I then uncompress. But I ve been tired of doing that by hand, so I wrote a tiny shell script for it. Nothing fancy. You just do: alioth-new-git openstack then it uploads your current repo to Alioth under /git/openstack, for example. It s a really stupid script, please don t point me to gbp-create-remote-repo, I know it exists, but I prefer my own tiny thing. Here s the (lame) script:

#!/bin/sh
set -e
CWD= pwd 
PKG_NAME= basename $ CWD 
usage ()  
echo "$0 creates a new Git repository out of your current working tree on alioth."
echo "You must be at the root of that local git repository"
echo "$0 will use the current folder as the name for the Alioth git repository."
echo ""
echo "Usage: $0 <destination-project-path-on-alioth>"
echo "example: $0 openstack will create a /git/openstack/$ PKG_NAME .git repository"
echo "note that you will need to have write access on the destination project,"
echo "which means you must be a member of that said project on Alioth."
echo ""
echo "Please send patch/comments to: Thomas Goirand <zigo@debian.org>"
exit 1
 
if [ $# != 1 ] ; then
usage
fi
DEST_PROJECT=$1
# Create the tarball and upload it to Alioth
cd ..
echo "===> Cloning $ PKG_NAME  as bare: $ PKG_NAME .git"
git clone --bare $ PKG_NAME  $ PKG_NAME .git
echo "===> Building tarball: $ PKG_NAME .git.tar.gz"
tar -czf $ PKG_NAME .git.tar.gz $ PKG_NAME .git
echo "===> Uploading $ PKG_NAME .git.tar.gz to vasks.debian.org"
scp $ PKG_NAME .git.tar.gz vasks.debian.org:
# Uncompress it on Alioth, fix perms and hook
# note that the below block should be put back in a single
# line, but has been broken into multiple lines for readability
# on this blog
ssh vasks.debian.org "cd /git/$ DEST_PROJECT  &&
echo '===> Uncompressing $ PKG_NAME .git.tar.gz in /git/$ DEST_PROJECT ' &&
tar -xzf ~/$ PKG_NAME .git.tar.gz &&
echo '===> Activating update-server-info hook' &&
mv $ PKG_NAME .git/hooks/post-update.sample $ PKG_NAME .git/hooks/post-update &&
cd /git/$ DEST_PROJECT /$ PKG_NAME .git &&
git --bare update-server-info &&
echo '===> Deleting tarball on alioth' &&
rm ~/$ PKG_NAME .git.tar.gz &&
echo '===> Fxing g+w unix permissions' &&
find /git/$ DEST_PROJECT /$ PKG_NAME .git -exec chmod g+w   \\;"
# Clean localy created files
echo "===> Cleaning local bare copy and tarball"
rm $ PKG_NAME .git.tar.gz
rm -rf $ PKG_NAME .git

(This page was edited a few times, details are available.) Grab it while it s hot! Thanks to the hard work of dpkg developers and many (generations of) developers, multiarch is becoming a reality. If you want to give it a try, install dpkg from experimental, add a foreign architecture, and start trying to install packages. Example on amd64:

# dpkg --add-architecture i386
# dpkg --print-foreign-architectures
i386
# apt-get update
[ lots of amd64 and i386 Packages files get downloaded ]
# apt-get install mksh:i386
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  ed:i386
The following NEW packages will be installed:
  mksh:i386
0 upgraded, 1 newly installed, 0 to remove and 9 not upgraded.
Need to get 414 kB of archives.
After this operation, 707 kB of additional disk space will be used.
Get:1 http://ftp.fr.debian.org/debian/ sid/main mksh i386 40.4-2 [414 kB]
Fetched 414 kB in 0s (664 kB/s)
Selecting previously unselected package mksh.
(Reading database ... 171933 files and directories currently installed.)
Unpacking mksh (from .../archives/mksh_40.4-2_i386.deb) ...
Processing triggers for menu ...
Processing triggers for man-db ...
Setting up mksh (40.4-2) ...
update-alternatives: using /bin/mksh to provide /bin/ksh (ksh) in auto mode.
Processing triggers for menu ...
# mksh
$ ldd $(which mksh)
linux-gate.so.1 =>  (0xf779c000)
libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf75d6000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf75b9000)
/lib/ld-linux.so.2 (0xf779d000)

Of course, installing an i386 mksh package isn t exactly what multiarch is about. Dozens of packages have been patched already to add Multi-Arch fields, but until their (recursive) dependencies have been multiarch-ified, foreign packages can be uninstallable, as can be seen below, with the usual why is it uninstallable? hunt (shortened output):

# apt-get install psutils:i386
The following packages have unmet dependencies:
 psutils:i386 : Depends: libpaper1:i386 but it is not going to be installed
# apt-get install libpaper1:i386
The following packages have unmet dependencies:
 libpaper1:i386 : Depends: ucf:i386 (>= 0.28) but it is not installable
                  Recommends: libpaper-utils:i386 but it is not going to be installed
# apt-get install ucf:i386
E: Package 'ucf:i386' has no installation candidate

Another example, successful handling of the installation of a foreign package, while it s already installed with the host architecture:

# apt-get install xz-utils:i386
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  liblzma5:i386
Suggested packages:
  xz-lzma:i386
The following packages will be REMOVED:
  xz-utils
The following NEW packages will be installed:
  liblzma5:i386 xz-utils:i386
0 upgraded, 2 newly installed, 1 to remove and 9 not upgraded.
Need to get 440 kB of archives.
After this operation, 410 kB of additional disk space will be used.
Do you want to continue [Y/n]?
Get:1 http://ftp.fr.debian.org/debian/ sid/main liblzma5 i386 5.1.1alpha+20110809-3 [205 kB]
Get:2 http://ftp.fr.debian.org/debian/ sid/main xz-utils i386 5.1.1alpha+20110809-3 [235 kB]
Fetched 440 kB in 0s (478 kB/s)
dpkg: xz-utils: dependency problems, but removing anyway as you requested:
 dpkg depends on xz-utils.
 xz-lzma depends on xz-utils.
 dpkg-dev depends on xz-utils.
(Reading database ... 171952 files and directories currently installed.)
Removing xz-utils ...
Processing triggers for man-db ...
Selecting previously unselected package liblzma5:i386.
(Reading database ... 171908 files and directories currently installed.)
Unpacking liblzma5:i386 (from .../liblzma5_5.1.1alpha+20110809-3_i386.deb) ...
Selecting previously unselected package xz-utils.
Unpacking xz-utils (from .../xz-utils_5.1.1alpha+20110809-3_i386.deb) ...
Processing triggers for man-db ...
Setting up liblzma5:i386 (5.1.1alpha+20110809-3) ...
Setting up xz-utils (5.1.1alpha+20110809-3) ...
# dpkg -l xz-utils xz-utils:i386 'liblzma*:*'
[   ]
un  xz-utils            <none>
ii  xz-utils            5.1.1alpha+20110809-3
ii  liblzma5:amd64      5.1.1alpha+20110809-3
ii  liblzma5:i386       5.1.1alpha+20110809-3
# ldd $(which xz)
    linux-gate.so.1 =>  (0xf776b000)
    liblzma.so.5 => /usr/lib/i386-linux-gnu/liblzma.so.5 (0xf7724000)
    librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xf771b000)
    libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xf7701000)
    libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf75a4000)
    /lib/ld-linux.so.2 (0xf776c000)
# zgrep -a '_("Activities")' gnome-shell-3.2.2.1.tar.xz
        this._label = new St.Label(  text: _("Activities")  );

zgrep is a shell script, but it calls xz, which is from the i386 package, and everything runs just fine. Running it through strace -f -e '', I discovered those messages, which I had never seen before:

[ Process PID=8900 runs in 32 bit mode. ]
[ Process PID=8899 runs in 64 bit mode. ]
[ Process PID=8900 runs in 32 bit mode. ]
[ Process PID=8899 runs in 64 bit mode. ]
 

What s next? We re late! It s time to check what happens with that dpkg package, report bugs, and convert more libraries! Please think of the kittens, and coordinate with the release team to make sure you don t delay a transition when uploading a shiny, multiarch-ified package. In a nutshell, if you received a patch from Steve Langasek or Riku Voipio, it s a good indication your package will be helpful quickly when it s multiarchified. Since zlib is directly depended on by 2000+ packages, #569697 was pinged right after the dpkg upload; but many other packages will need patches and heavy testing. Hurry up, the freeze is coming, we need to shake it up as soon as possible!

In a perfectly orchestrated marketing campaign for a 100% free-libre tablet called Spark that will run KDE Plasma Active, Aaron Seigo writes today about the problems they are facing with GPL-violations. Apparently, every Chinese manufacturer is breaking the GPLv2 by not releasing the sources for their modified Linux kernel. Conversations and conversations with Zenithink (designers of the Spark), Synrgic (designers of the Dreambook W7), etc have arrived nowhere. To the point that CordiaTab, another similar effort using Gnome instead of KDE, has been cancelled. I have to say I am very surprised at the lack of the kernel sources. What is the Free Software Foundation doing? Why don t we seek ban of all imports of tablets whose manufacturers don t release the full GPL source? Apple got the Samsung GalaxyTab imports blocked in Germany and Australia for something as ethereal as patents covering the external frame design. We are talking about license infringement, which is easier to demonstrate in court. China may ignore intellectual property but they cannot ignore business, and no imports means no business. Let s get all GPL-infringing tablet imports banned and we will get more source in two weeks than we can digest in two years. Heck, I m surprised Apple is not trying this in court to block Android!

As phpMyAdmin is approaching to 3.5 release, it has come time to share about translations status. Here comes second round of translation status update. Since last update we have two more translations at 100%:

• English (Great Britain)
• French
• Russian
• Slovenian
• Spanish
• Swedish
• Turkish

There are few which are really close to 100% and I hope they will get there soon:

• Danish
• Japanese

Just on next level is Czech, where I'm progressing quite slowly and would welcome help :-). There was also great improvement in Romanian in past week so I hope we will see it soon on top of the list as well. Was your language not mentioned? It's now perfect time to contribute to it.

Filed under: English Phpmyadmin 0 comments Flattr this!

Since all problems related to Zenbook (Asus UX31e) under Linux can be solved without using the bleeding edge kernel and rest of the stuff, I m going to end my short adventure with ArchLinux. Basically I have nothing against ArchLinux. Seems to be quite good choice for someone more experienced, but assuming I m able to use new laptop under Debian then learning new options of pacman or yaourt is useless for me. Even such short adventure with ArchLinux ended up with my own PKGBUILDs for this distro Anyway. Goodbye Arch, welcome Debian unstable. Tomorrow I m going to reinstall to Debian. This time Windows 7 will be removed too.

Maybe this could be of interest to a few of my readers who may have missed the announcement, in particular for ones related to forges which will be deployed for private administrations in Europe. The recently stared ADMS.F/OSS project is described as :

ADMS.F/OSS is an XML and RDF vocabulary to describe software, in
particular free and open-source software (F/OSS), making it possible to
more easily search and discover software. The ADMS.F/OSS specification is still under development.

It is developped in the frame of an EC (European Community) programme for interoperability between public administrations (more on the page above). I ll try and participate to the working group, bringing in some feedback from the efforts on similar issues conducted during the (now over) COCLICO project. Hope this helps.

If you re not into packaging and if you asked how you could help Debian, someone probably suggested that you help to translate it. It s true that translating Debian is essential if we want to make Debian available to everybody on the world. There are many persons who are stuck as soon as they get a message in English, so it s important to aim for 100% coverage in terms of localization. Some vocabulary: localization vs internationalization Internationalization (i18n) is the work that makes it possible to translate messages in a given application. Localization (l10n) is the work of translating messages of said application. So as a translator, you ll be doing localization but some knowledge of internationalization is still useful because it will define how you re supposed to provide the translations. We ll come back to that later. Join your localization team Usually the translation work is shared among multiple translators within a localization team. Check out the Debian International page on www.debian.org to find out instructions for translators for each language. Many teams have a debian-l10n-*@lists.debian.org mailing list used for coordination, feel free to ask questions on those lists when you start (but make sure that you have read the relevant documentation before). Each team has its own workflow, so observe for a while to get used to what s happening before asking your first questions. What is there to translate? The translation of most of the software provided by Debian is not handled by Debian. The Debian translation teams only handle the translation of:

• the software that are specific to Debian (debian-installer, dpkg, APT, etc.) (*);
• the Debconf prompts in all Debian packages (*);
• the Debian documentation (*);
• the Debian website;
• the Debian wiki;
• the descriptions of packages.

Now before contributing to your first translation, I have to come back to internationalization to teach you a few things. In the above list, the projects marked with (*) do use PO files for their translation and the next sections will explain you how to work with those files. Introduction to Gettext The free software community has mostly standardized on a single internationalization infrastructure known as Gettext. With this tool, you re provided a POT file which contains all the translatable strings. It looks like this:

# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR Software in the Public Interest, Inc.
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <email>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: dpkg 1.16.1\n"
"Report-Msgid-Bugs-To: debian-dpkg@lists.debian.org\n"
"POT-Creation-Date: 2011-09-23 03:37+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <email>\n"
"Language-Team: LANGUAGE <ll>\n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=INTEGER; plural=EXPRESSION;\n"
#: lib/dpkg/ar.c:66
#, c-format
msgid "invalid character '%c' in archive '%.250s' member '%.16s' size"
msgstr ""
#: lib/dpkg/ar.c:81 lib/dpkg/ar.c:97 lib/dpkg/ar.c:108 lib/dpkg/ar.c:112
#: lib/dpkg/ar.c:134 utils/update-alternatives.c:1154
#, c-format
msgid "unable to write file '%s'"
msgstr ""
[ ]

The lines starting with #: are comments that indicate the source files where the (English) string is used. This can be useful if you want check the source to have more information about how the string is used. The lines starting with #, contain flags that can be important. If the fuzzy flag is set, the translated string is not used because it must be updated (or at least verified) since the original string evolved. The c-format flags indicates that the string must be a C format string, this has some implications in what s allowed in the string (in particular when it embeds conversion specifier for arguments submitted to printf-like functions). Another thing to note is that the translation of the empty string is used to store some meta-information about the translation itself. Contributing a translation as a PO file When you start a new translation, you copy that POT file to create a PO file for your own language (eg. fr.po for the French language). You replace some template values (identified with the upper case words in the POT file) and you replace all the empty strings on msgstr lines with the translation of the string that appears in the previous msgid line. The result could be something like this:

# translation of fr.po to French
# Messages fran ais pour dpkg (Linux-GNU Debian).
msgid ""
msgstr ""
"Project-Id-Version: fr\n"
"Report-Msgid-Bugs-To: debian-dpkg@lists.debian.org\n"
"POT-Creation-Date: 2011-09-23 03:37+0200\n"
"PO-Revision-Date: 2012-01-16 07:57+0100\n"
"Last-Translator: Christian Perrier <bubulle>\n"
"Language-Team: French <debian-l10n-french>\n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: Plural-Forms: nplurals=2; plural=n>1;\n"
"X-Generator: Lokalize 1.2\n"
#: lib/dpkg/ar.c:66
#, c-format
msgid "invalid character '%c' in archive '%.250s' member '%.16s' size"
msgstr "caract re invalide  %1$c  dans la taille du membre  %3$.16s  de l'archive  %2$.250s "
#: lib/dpkg/ar.c:81 lib/dpkg/ar.c:97 lib/dpkg/ar.c:108 lib/dpkg/ar.c:112
#: lib/dpkg/ar.c:134 utils/update-alternatives.c:1154
#, c-format
msgid "unable to write file '%s'"
msgstr "impossible d' crire le fichier  %s "
[ ]

If there s already a PO file for your language, there might still work to do: there might be strings that have not yet been translated and there might be fuzzy strings which have to be updated strings which were already translated but where the original string has been modified. There are software that can assist you to edit PO files: poedit, virtaal, lokalize, gtranslator. There are also special extensions for vim (packaged in vim-scripts) and for Emacs. Submit the translation for inclusion Once you have a complete PO file, you should submit it for inclusion. Sometimes you will have been granted commit rights to the source code repository so that you can include your translation by yourself. In the other cases, you should submit your translation with a bug report tagged l10n and someone else will include your work in the next release. Depending on the team, the workflow might require a review before the submission. In that case, you usually have to send a call for review on the coordination mailing list. Go ahead! Hopefully those explanations will be enough to get you started. There are many other things to learn but it s good to learn while practicing For example, can you find out why the French translation above changed %c in %1$c ?

Do you want to read more tutorials like this one? Click here to subscribe to my free newsletter, you can opt to receive future articles by email.

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

I ve spent a few days during work, after work and on the weekend working on python-sunlight, a unified API implementation of a few Sunlight services. This is very unstable, and not released yet (so please don t rely on it yet), but it will be shortly. Be sure to sign up for an API Key, and dump the key to ~/.sunlight.key there s a simple script to help with some of this in bin/, but nothing solid yet. I do, however, encourage you to use it and play around with it, and report your bugs. Contributions (in the form of code) are also very welcome, so please do fork the project and play around with it. Just to give everyone a taste of how cool this is this will pull up a list of twitter IDs of people who mention free market more then anyone else according to the congressional record:

from sunlight import capitolwords
from sunlight import congress
for person in capitolwords.phrases_by_entity(
    "legislator",
    phrase="free market",
    sort="count",
):
    n = congress.legislators( bioguide_id=person['legislator'],
        all_legislators="true" )
    if len(n) >= 1:
        n = n[0]
        if n['twitter_id'] != "":
            print n['twitter_id']

And the output:

RepRonPaul
stevekingia
SenSherrodBrown
JacksonLeeTX18
SenatorLeahy
ChuckGrassley
SenJohnMcCain
OrrinHatch
DanaRohrabacher
JudgeTedPoe
McConnellPress
edtowns
SenatorDurbin
SenatorSessions
SenatorHarkin
SenChrisDodd
russfeingold
RosLehtinen
sencarllevin
senjonkyl
Dennis_Kucinich
senatorsanders
SenatorReid
RepDanBurton
RepMikePence
SenSamBrownback
joebiden
FrankPallone
ToddAkin
senatorboxer
RepTrentFranks
JohnCornyn

Have fun! Show off what cha got, and please let me know if you do something cool!

GPL enforcement is a surprisingly difficult task. It's not just a matter of identifying an infringement - you need to make sure you have a copyright holder on your side, spend some money sending letters asking people to come into compliance, spend more money initiating a suit, spend even more money encouraging people to settle, spend yet more money actually taking them to court and then maybe, at the end, you have some source code. One of the (tiny) number of groups involved in doing this is the Software Freedom Conservancy, a non-profit organisation that offers various services to free software projects. One of their notable activities is enforcing the license of Busybox, a GPLed multi-purpose application that's used in many embedded Linux environments. And this is where things get interesting

GPLv2 (the license covering the relevant code) contains the following as part of section 4:

Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License.

There's some argument over what this means, precisely, but GPLv3 adds the following paragraph:

However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation

which tends to support the assertion that, under V2, once the license is terminated you've lost it forever. That gives the SFC a lever. If a vendor is shipping products using Busybox, and is found to be in violation, this interpretation of GPLv2 means that they have no license to ship Busybox again until the copyright holders (or their agents) grant them another. This is a bit of a problem if your entire stock consists of devices running Busybox. The SFC will grant a new license, but on one condition - not only must you provide the source code to Busybox, you must provide the source code to all other works on the device that require source distribution.

The outcome of this is that we've gained access to large bodies of source code that would otherwise have been kept by companies. The SFC have successfully used Busybox to force the source release of many vendor kernels, ensuring that users have the freedoms that the copyright holders granted to them. Everybody wins, with the exception of the violators. And it seems that they're unenthusiastic about that.

A couple of weeks ago, this page appeared on the elinux.org wiki. It's written by an engineer at Sony, and it's calling for contributions to rewriting Busybox. This would be entirely reasonable if it were for technical reasons, but it's not - it's explicitly stated that companies are afraid that Busybox copyright holders may force them to comply with the licenses of software they ship. If you ship this Busybox replacement instead of the original Busybox you'll be safe from the SFC. You'll be able to violate licenses with impunity.

What can we do? The real problem here is that the SFC's reliance on Busybox means that they're only able to target infringers who use that Busybox code. No significant kernel copyright holders have so far offered to allow the SFC to enforce their copyrights, with the result that enforcement action will grind to a halt as vendors move over to this Busybox replacement. So, if you hold copyright over any part of the Linux kernel, I'd urge you to get in touch with them. The alternative is a strangely ironic world where Sony are simultaneously funding lobbying for copyright enforcement against individuals and tools to help large corporations infringe at will. I'm not enthusiastic about that.

comments

When you read this, GNOME Shell 3.2 will (hopefully!) have finally transitioned to Debian s testing suite. Planet GNOME readers might think Debian now has outdated versions of software even in their development versions, or the distribution s development marches at glacial pace. Wheezy GNOME users will finally have a Shell that matches the rest of their GNOME components, something that works with the Shell extensions website and much less problems and limitations compared to 3.0.2. The reality is that GNOME 3.2 s packaging was quite ready back when it was released in late September, but a number of not-so-desirable situations held GNOME Shell from transitioning to testing until today, four months later. So, what happened? TL;DR: transitioning from GNOME 2 GNOME 3 is not so easy if you want to keep testing in a sane state, and when you need to deal with dozens of indirectly related packages, for more than 10 architectures but it shouldn t take nearly a full year, either Let s go back to the last months of 2010. Debian squeeze is in very deep freeze, and the release team and many Debian developers are focusing on squashing as many release critical bugs as they can, in order to make Debian 6.0 the great release it ended up being. The GNOME project has recently delayed the big launch of GNOME 3.0 again, until March 2011; Debian has already settled on GNOME 2.28 for its release, although it will end up cherry-picking many updates from the 2.30 release modules. With most of the stabilization work being done, many Debian GNOME team members were at that time working on packaging very early versions of what would end up being GNOME 3.0 technology: GTK+3.0, GNOME Shell, Mutter and some brave users even tried to use it via the experimental archive. On February 6th, Debian 6.0 was released, and soon after, on April 6th, GNOME made a huge step forward with the much anticipated release of GNOME 3.0. At that time, Debian developers were busy breaking unstable as much as they could, as it s tradition on the weeks following a major release, and the Debian GNOME team was able to start moving some GNOME 3.0 libraries (those which were parallel-installable with their GTK+2.0 versions) to unstable. However, moving the bulk of GNOME 3.0 to unstable wasn t so easy. When you start doing that, you need to be sure you re ready to have all affected packages in a transitionable state as soon as possible, to minimise the chances of blocking transitions of unrelated packages via the dependencies they pick up with rebuilds. All the packages involved in a transition need to be ready to go in the same testing run , for all supported architectures. When you re dealing with dozens of GNOME source packages at the same time, many of which introduce new libraries, or worse, introduce incompatible APIs that affect many more unrelated packages, things get hairy, and you need a plan. So, Joss outlined what a sane approach to this monster transition could look like. The amount of work to do was what we call fun on #debian-gnome. In a nutshell, we had to deal with quite a few transitions, starting with having a newer version of libnotify in unstable, and a pre-requisite for that was making sure all the packages using libnotify1 were ready to use the source-incompatible libnotify4, and this meant preparing patches and NMUs for many of our packages, as well as many others not under our control. Before starting a controlled transition like this one, we had to get an ACK from the release team, who was busy enough handling other huge transitions like Perl 5.12, so by the time we got our own slot, we were well into Summer. With libnotify done in August, it was time to get our hands dirty with more exciting stuff, like getting Nautilus in testing. This meant bumping a soname and requiring all packages providing Nautilus extensions to migrate to GTK+3.0, or drop the extension entirely, as you can t mix GTK+2.0 and GTK+3.0 symbols in the same process. However, in GNOME 3.0, automounting code had moved from Nautilus to gnome-settings-daemon, so in order to not break filesystem automounting in testing for an unreasonable amount of time, both Nautilus and g-s-d needed to go in at the same time. The fun thing is that g-s-d dragged glib2.0, gvfs, gnome-control-center, gdm3, gnome-media, gnome-session and gnome-panel into the equation, so this transition needed extra planning and a lot more work than initially expected: migrating all nautilus extensions, plus ensuring all Panel applets had migrated to GTK+3.0 and the new libpanel-applet-4 interface. In short, this was the monster transition we were trying to avoid. By the time all this mess was sorted out, GNOME 3.2 had been released, and for what users said, it was a lot better than 3.0. We still had no more than a few bits and pieces of 3.0 in testing, and we were working hard to get 3.0 in wheezy. With all the excitement around 3.2, at times it was difficult to explain outsiders why we were beating a dead 3.0 horse Going back to our huge transition, it was just a matter of time before all the packages would be built and be ready to enter, on the same run, in testing. A few weeks later, in early November and after several rounds of mass-bug-filings, fixing unrelated FTBFS, many NMUs, package removal requests and dealing with any possible problem that could block our transition, everything seemed to be set, and our release team magicians had everything in place for the big magic to happen. However, our first clash with the rest of Debian happened a few hours before our victory, in the form of an unannounced ruby-gnome2 upload which resetted the count for everyone. It was fun to see the release team trying all sorts of black magic in an attempt to mitigate the damage. Fortunately, after a few tries they managed to fool britney (the script that handles package transitions from unstable to testing) somehow, and the hardest part of the job was done with just one day of delay. At last, the core of GNOME 3 was in testing, and testing users found soon after. The rest of the week saw a cascade of hate posts against GNOME 3 in Planet Debian, and personally I didn t find that especially motivating to keep on working on the rest of GNOME bits. With experimental clear of GNOME 3.0 stuff, we finally were able to focus on packaging whatever GNOME 3.2 components were not already done, and preparing for what should be a plain simple transition of GNOME 3.0 to 3.2. After our share of wait for a transition slot, as Perl 5.14, ICU and OpenSSL were in the line before us, and after dealing with a minor tracker 0.12 transition, we were ready for our next episode: evolution-data-server. At first sight, we thought this would be a lot easier, but it still got a bit hairy due to evo-data-server massive soname bumps. We were given our slot just before Christmas, after a few weeks of wait for others to finish their migration rounds, and most of the pack entered wheezy a few days before the new year. No rejoicing, though, as GNOME Shell 3.2 didn t make it. First, we discovered it was FTBFS on kFreeBSD architectures, as NetworkManager had been promoted from optional to required, for apparently no good reason, leaving the BSD world in the cold, including our exotic GNU/kFreeBSD architectures. Now, let s clarify that I m a supporter of the Debian kFreeBSD architectures and was really happy to see it accepted as a technology preview in squeeze. However, as you know, GNOME Shell currently requires hardware acceleration to run, a requirement hardly met in kFreeBSD, unless you re using a DRI1 X driver. We seriously doubted anyone had ever ran a GNOME 3 session on kfreebsd-*. However, if it didn t build, it was a blocker bug for GNOME Shell. We considered creating different meta-packages for kFreeBSD architectures, to conclude it d be a mess, so our awesome Michael Biebl ended up cooking up a patch that restored the ability to build the Shell without NetworkManager support. With this out of our way, we just needed to upload Michael s fix and watch the buildds do their part of the job. Or maybe not? Enter Iceweasel 9. In parallel, and with incredible bad timing, Iceweasel 9.0 was uploaded to Debian the very same day it was released by Mozilla. Again, it greeted us with a nasty surprise: yet another mozjs API change, which made gjs FTBFS, which meant our kFreeBSD fixes would be unusable until someone who knew Gjs internals well enough bit the bullet and worked around the new API changes. Again, Michael Biebl tried to be our saviour, but unfortunately wasn t able to fix all the problems, so we tried to focus on plan B. Mozilla had released a fork of the mozjs that is included in Firefox, so that embedders would have a bit less of a hard time with these recurrent API changes. This was based on Firefox 4, and was already being packaged by Ubuntu. Gjs would build using this older version just fine, so we just needed to get it in Debian as soon as possible. We just needed to find a sucke^Wvolunteer that would be inclined to maintain the beast. Only after a few weeks we managed to get Chris Coulson, the Ubuntu packager, to maintain the package directly through the Debian archive via package syncs. However, his package had only been auto-compiled in the three Ubuntu architectures, that is amd64, armel and i386. It s late January 2012, and we ve been fighting this war for 10 months. After getting some help from Michael to get the new package in shape for Debian standards, we were excited to sponsor it for Chris. Duh, after a few days in the NEW fridge, it was rejected by the ftp-masters. The license statement was missing quite a few details, so I went ahead and sacrificed a few hours of my copious free time to get this sorted out. A few days later, mozjs was accepted, but the result was horrible. It was very red. mozjs didn t build on half of our targets. Mike Hommey was quick to file a bug and point us to the most obvious fuckups. As he had dealt with this in the past as the Iceweasel maintainer, all of these issues were fixed and patches were ready to be applied verbatim or with minimal changes to our sources. With mozjs finally built successfully (although with severe problems on ia64), we were finally able to rebuild Gjs against it, upload GNOME Shell with our kFreeBSD fixes and wait until today for this mess to be over. Whew. I can t say I ve enjoyed all the stages of this ride. Some bumps on the road were clearly there to test our patience, but it has helped me get back in touch with non-leaf GNOME packaging, which was all I was doing for a while due to being super-busy lately with studies. It also reminds me of the privilege of working side by side with some awesome people, not only Joss, Michael, Sjoerd, Laurent or Gustavo, to name just a few Debian GNOME team members, but also the receptive release team members like Julien or Cyril, and NEW-processing record-breaking ftp-master Luca. Without them, we might be trying to figure out the Nautilus transition since last Summer. We really hope GNOME 3.4 will be a piece of cake compared to this. ;)