This is a public service announcement: depth and bpp are different.

Depth refers to the number of significant bits (usually colour-significant, i.e. R + G + B bits for RGB modes) per pixel. bpp, i.e. bits per pixel, refers to the number of bits used altogether for pixel storage. Ignoring alpha, the usual configuration of your framebuffer will be depth 24 (8 bits each for R, G and B), but 32bpp: 8 unused bits at the top. 24bpp and depth 24 means that there are no unused bits, and that four pixels will occupy 96 bits (12 bytes), and not 128 bits (16 bytes), as there would be in 32bpp. (Thankfully, no-one actually uses 24bpp in the real world.) That is all.

I've just uploaded Policy 3.8.1.0 with the first batch of post-lenny changes. There isn't anything that earth-shattering in this set, but I'm hoping that we'll be able to get a lot more done during the squeeze release cycle. Policy has well over a hundred open bugs, quite a few of which we should be able to resolve. I also uploaded Lintian 2.2.8, which is synchronized against Policy 3.8.1 and also reverts some changes around install-menu due to a reverted change in debhelper 7.2.5, and fixes diagnosis of diversions. The last few versions of Lintian have all been a little bit buggy due mostly to the current pace of change. Hopefully this version will have fewer unexpected problems. Here is the summary of normative Policy changes, taken from upgrading-checklist.txt.gz in the debian-policy package.

• Care should be taken when adding functionality to essential and such additions create an obligation to support that functionality in essential forever unless significant work is done.
• Changelog files must be encoded in UTF-8.
• Tighten some format requirements for changelog files from a should to a must.
• Remove alternative changelog formats. Debian only supports one changelog format for the Debian Archive.
• New nocheck option for DEB_BUILD_OPTIONS indicating any build-time test suite provided by the package should not be run.
• All control files must be encoded in UTF-8.
• debian/control allows comment lines starting with # with no preceding whitespace.
• Init scripts ending in .sh are not handled specially. They are not sourced and are not guaranteed to be run by /bin/sh regardless of the #! line. This brings Policy in line with the long-standing behavior of the init system in Debian.
• The start action of an init script must exit successfully and not start the daemon again if it's already running.
• /var/run and /var/lock may be mounted as temporary filesystems, and init scripts must therefore create any necessary subdirectories dynamically.
• /bin/sh scripts may assume that local can take multiple variable arguments and supports assignment.
• User mailboxes may be mode 600 and owned by the user rather than mode 660, owned by user, and group mail.

Wouter and Christian have started bragging about their travel arrangements to attend DebConf, with probably insane amounts of toxic substances aimed at making DebConf9 the smelliest DebConf ever. So, it is time for me to announce my intentions as well. I have booked my ticket to travel MEX-MAD, leaving on Thursday 16/07/2009 and arriving to Spain on Friday 17. That means I will be getting to C ceres Friday evening. And I am flying back on Sunday 02/08/2009, which only means that I'll be jetlagged on Monday at work :-P Buying plane tickets when your country's currency has lost 50% of its worth against any other major currency in the world (US dollars are now at ~MX$15.50, and Euros are quickly approaching MX$20), let me tell you, is no fun. Even less if the plane tickets have increased their cost in absolute terms as well, due to the decrease in demand. But, yes, the good news do stand: See you in C ceres!

Nearly a month has elapsed since Debian released Lenny. The interesting thing for me about this release was that I failed to get to the point where running etch was causing me pain. This became even more evident when Katherine commented on my Lenny T-Shirt - I'd forgotten to mention our release to her! Previously there have been a bunch of features coming that I really wanted, sometimes to the point of using backports. It's probably something to do with the way I run Debian; I use stable for remote machines and while in the past this would have meant quite a few work boxes these days it's just a box at my parents' and my colo. Where I felt the pain during this release cycle was on the boxes where I run unstable (my home desktop) or testing (my work box and my laptops). Development on new shininess slows down significantly while we're preparing for release (not unsurprisingly). And there are things coming up I quite like the look of, largely aimed at the desktop arena. I've been running Network Manager 0.7 from experimental on my EEE, for example - I need the HSO 3G support to avoid unnecessary faff on a daily basis. I've got ATI cards in my work and home desktops, so I'm watching the Mesa developments with interest - roll on OpenGL 2.0 support hopefully. The Intel KMS support that doesn't seem to be quite there yet but RSN, no, really, will be nice for my laptops. Experimental VDRs are looking interesting and perhaps worth upgrading my PVR to.

For a long time I haven't really understood the point of view that Debian shouldn't release. Or rather, I haven't understood why people would think that was a serious option. The first Debian box I installed went into a colo facility shortly afterwards. This is the first release I've not been running Debian on a commercial colo box and while I treat my personal colo in a similar fashion it's not quite the same in terms of priorities. However I still think regular releases are hugely important to the project. Some pain for those of us more interested in new shiny is a small price to pay for producing a flexible, reliable distribution, be they server administrators (though I see a worrying number of people decide to install testing on their production servers and then rarely/never update it), derivers or appliance vendors.

Mind you, now we've released I'm going to have to do all those things I've been putting off. I should probably start with moving my Perl bits into pkg-perl. And maybe I should switch over some sources.list files to point at squeeze instead of lenny...

position:fixed in Android Webkit Good news for mobile web developers! In the latest development build of Android ("cupcake"), WebKit supports iPhone touch events and CSS3 animations/transforms. This means that Richard Herrera's iPhone fixed positioning hack will soon work Android too. The WebKit CSS Animation demos also work, but lack of hardware acceleration in Android makes them painfully slow compared to the iPhone.

Things are feeling unstable around here. That's mostly a good thing, but ... Switching to ext4 seemed like a good idea since I was resizing my file server's filesystem anyway. And I'd used ext4 on my laptop for a while, with no problems. But, I ran into a bug that causes ext4 to hang. So I'm left with my main server at home piling up hundreds of processes in uninterruptible sleep when this breaks. And, eventually running out of memory and dying. There's a fix, in newer -pre kernels, but so far I have not had luck getting those kernels to work with my Thecus. There's a regression in those kernels that breaks the NIC, and my attempt at backing that changeset out still left it unable to get on the net. Did I mention that I don't even have a serial console on this machine? That natively building a kernel on armel takes about 12 hours? Makes this sort of thing much fun. Need to find the right header and spend some time with a soldering iron one day. Converting back to ext3 would mean resizing a 2 TB array, which ran resize2fs out of memory when I tried it. It looks like I will have to leave /home unmounted while I'm on my trip, to keep the rest of the server up. When I get back, I've ordered a third terabyte drive, and will use it to switch back to ext3. Having these silly amounts of storage is fun, until you have to admin it. The other fun I've run into is that a new version of mpd has horrible performance on arm. Max Kellermann was very helpful in tracking down the issues involved, and helping me get a version that has at least reasonable performance again. Oh, and if someone could tell me why gnome terminal 2.24.3 can't open links anymore, I'd appreaciate it.

It looks like I'm definitely losing Monday release schedule, but it does not matter that much, new release is here anyway. I wanted to push some bigger changes into first testing release after 1.23, but instead of that I did bunch of bug fixes, documentation and test improvements. Full list of changes follows:

• Fixed decoding of Samsung memory entries.
• Properly handle corrupted messages from Nokia phones (bug #811).
• Fix parsing of calls from Alcatel C701 (bug #831).
• Fixed handling of error states with -len and -autolen parameters.
• Fixed possible crash in DBI engine.
• PostgreSQL engine properly uses sequences instead of reinventing.
• MySQL engine properly uses auto increments instead of reinventing.
• Fix escaping of field name in PostgreSQL engine.
• Better SMSD files logging.
• Added testing of SMSD files engine.
• Increase timeout for AT settings SIM card SMS storage.
• Fixed date formatting in PostgreSQL SMSD service.
• Add option to install without documentation.
• Add -textutf8 option for TEXT sms.
• Fix crash when some lines in config are too long.
• Make smsdrc example better looking by removing obsolete docs.
• Make dku2 connection types work on Linux (alias to fbususb).
• Better calculation of signal percent.
• Fixed getting of memory status for some Nokias (bug #836).

You can download from usual place: http://cihar.com/gammu/, Debian users will find packages in experimental soon, SUSE, Fedora and Mandriva users can check experimental repository in OpenSuse Build Service.

Samba.grep.be, my main server (which occasionally also hosts a domU for p2) was upgraded to lenny this monday evening. I wish I could say there were no issues, but unfortunately that's not true. At first, everything seemed to run smoothly; of course I did have to recompile a few locally written programs to run against some SONAME changes (programs that are too trivial to package, really, and too ugly too), but other than that, everything was fine. It went wrong sometime during the night. Apparently something didn't like the new kernel or the new xen, because everything started to lock up. Since I only noticed this when I was at a customer the next day, I couldn't fix it until I got home again in the evening (meaning, downtime for a full day); and unfortunately, the exact failure mode meant that not much was written to the log -- certainly not enough to figure out what went wrong:

Mar 10 04:04:41 samba kernel: [ 7033.011523] INFO: task cron:21006 blocked for more than 120 seconds.
Mar 10 06:43:46 samba kernel: [ 7033.011614] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 10 17:35:04 samba kernel: [ 7033.011701] cron          D 7fffffffffffffff     0 21006   4147

After that, nothing before the reboot, which happened at around 21:00. Take good note of the timings on those messages, and the apparent discrepancies between the syslog timestamp and the kernel timestamp. 7033 seconds after boot was around 3:30 AM... When I arrived at the physical server, this kind of message was rolling over the console several times a second, with just the name and PID of the blocking process changed. And with several more lines following the message, of course. As a result, the system was not responsive at all. I didn't file a bug since, frankly, there's so little information that I wouldn't even know what to file a bug against (the kernel? Xen? Some rogue process that runs as root and changes settings which cause a driver to block? I wouldn't know). Instead, all I could do was to reboot the server and hope for the best. Not that I like that kind of situation. Fortunately, the problem didn't reproduce itself today; here's for hoping that it never will.

It seems python-dateutil is the Python module that can bring some sanity to time handling in Python. I ve finally found a module that can these two tasks:

• parse dates in several formats
• provide machinery to make the standard datetime talk timezones

For the first item I was using mx.DateTime, but it seems dateutil s parser is very good too. The second item has been bugging me for a long time. You have the datetime module in the standard library providing nice object-oriented interfaces to date and time, but what good it is if you can t even use it to print a date in RFC822 format! At least now it s possible:

  from datetime import datetime
  from dateutil.tz import gettz
  print datetime.now(tz=gettz()).strftime('... %z %Z')

(Oh, sure, that simple task can be done directly with the time module. But if you re dealing with HTML templates, you really want to pass date objects around, and let the templates print them one or more times in whatever format they need, including %z or %Z. And with dateutil you can use any timezone, of course, not just the current one.) The dateutil module also offers interfaces to do relative time calculations (what date will it be in 47 days?), and some stuff for recurrence rules. Check it out!

Yesterday evening, I registered for Debconf9 in C ceres. I also registered my first proposed event: the now traditional cheese and wine party. Being in Spain with no regulations on food import for the traditional cheese providers in the Debconf crowd, I promise that this cheese party will be E.V.I.L. And Debconf 9 will be a great success, of course. See you in C ceres!

Translink are breaking the trains for 3 months at the end of March. This is manifesting as the line between Ballymena and Coleraine being entirely shut (it's only single track, so it's not like they can do one side at a time), but will hopefully result in a smoother, faster journey. Not much good for the 3 months when my journey goes from a single train ride to a train, bus, then another train ride. And gets longer by 20-30 minutes (so potentially 5 hours a day commuting. Yay!). I think not.

So I have rented a flat in Belfast, conveniently only 3 minutes walk from work. 3 month leases are hard to find so I have it for 6 months. I'm a bit freaked. I shouldn't be really; I lived alone when Katherine first moved back to NI. But that was in a house I'd been in for ages rather than somewhere entirely new to me. It proved its worth last night when we were able to walk to Do You Remember the First Time? in a couple of minutes though. Being in the city centre is damn handy, though I'm having to get used to the regular noise of traffic again. :)

(This post primarily a test of Drivel; it's not worth the hassle of dealing with Virgin or BT to get a broadband connection, so I'm going to end up continuing to use my Orange 3G dongle and trying to do things in local clients where possible.)

Not sure how many people check the list of packages requested - 452 packages at the time of writing.

One thing occurs to me when viewing the list, the standard DDPO page format doesn't lend itself to this kind of data. There is no PTS page, nothing available in pool, no bugs, no versions or builds (inevitably) and no popcon, watch or section. What might be more useful here would be not just a link to the RFP bug report, but the title of that bug report so that a quick scan of the RFP page could shed more light on the packages than the bare upstream package name.

Maybe even create RSS feeds for new ITP, RFP, O and ITA bugs?

(Particularly useful is the support for listing only specific source packages - I think I might link to some pages from Emdebian using that syntax.) e.g. this list of core packages for Emdebian support.

Also idly wondering if there could be some way of adding Emdebian data to this kind of output - maybe a line beneath the current suite listing with the em[0-9] details. Not sure what data sources are used for the DDPO package data but if it is Packages.gz files etc., those are available. If this seems like a good idea or knows how it could be done, please post a comment.

After some thinking I've just filled in application for Gammu in Google Summer of Code 2009. I feel the project is recently getting some boost and it would be great if some students would help us with new ideas. On the other side I'm afraid that chances to get accepted for such a small project is quite limited, but if you have some great ideas which could be implemented as a summer project, feel free to add them to our wiki, maybe they will attract somebody :-). Ideas page: http://www.gammu.org/wiki/index.php?title=Gammu:GSoC2009

I wasn t sure to really understand this project of law until I read a lot about it during the past days. As some of you might already know, this law, called Internet et Cr ation , but mainly referred as HADOPI law ¹, is a Three Strikes scheme to fight against illegal downloads proposed before the last summer by the French government, and then voted in the Autumn by the S nat (the first of the two French houses of Parliament). Not that I am in favor of illegal downloads of movies and music, but the way this law plans to fight against them is a real threat for French free software developers and users. I won t explain here all the details of this law, but to sum up, it plans to suspend the Internet access to people downloading illegal files from the peer-to-peer network, after 2 notices. Here are the problems I have noticed, as far as I am personally concerned, besides more general aspects this law implies (user freedom etc.):

• Some private actors, indirectly working for French leisure and cultural companies, will be in charge of controlling the French Internet. They will only base their accusations on the IP addresses, which I do not think to be a proof alone.
• An Internet user, accused to have illegally downloaded movies or music will have to prove by his own means he has not done it - ie. his Internet connection could have been hacked, but he needs to prove it! This is totally contrary to the way justice normally works in France, where you are supposed to be innocent until the contrary is proved. A large majority of French Internet users do not have the necessary technical skills to secure their wireless network and hence their Internet connection. And even with good skills, all of them do not own a wireless router supporting eg. WPA2, which creates a real discrimination towards French Internet users.
• A chapter of the project of law plans the possibility to set up a kind of firewall on the computers connected to the Internet - they will allow Internet users to prove their sincerity. This causes however a big issue for free software users: I doubt such a piece of software will be available for free operating systems (such as GNU/Linux, FreeBSD etc.). Even if it is, it won t be opensource - if it was, anybody could amend it and/or disable it, hence no real possibility for the user to prove it was running when the illegal download was noticed.
• This law doesn t take into account the fact that an increasing part of the peer-to-peer exchanges are encrypted, or run anonymously. More over, other technical ways of downloading are not considered (streaming, direct downloads especially when the websites are hosted abroad).

The law should be discussed at the Assembl e Nationale from today (the second house of Parliament), I hence contacted my local representative last week in order to propose a meeting allowing me to expose my concerns. Until now, I have received no answer, despite the fact he accepted to commit in favor of free software when running for being re-elected in june 2007 (he signed the Pacte des logiciels libres from the APRIL association). I guess I will receive an answer once the law is voted!

OK, so after a lot of dithering I finally decided that I wanted to stand again for re-election in the DPL election this year. That's despite the fact that it's not good for my health and I don't have enough time to start with... Why am I doing it?

• I believe I've done a good job in the last year, and lots of other people seem to agree. However, I did not find the time for all the work I hoped to do and I think it's worth carrying on.
• I've been pestered to stand again by a lot of my friends in the project.
• I wasn't going to let Zack stand unopposed! *grin*

To make the job easier this year if elected, I'm standing with Luk Claes as an assistant. He and I are good friends, and we share ideas and values on a lot of points. My experience from the last year as DPL tells me that the job is a big one, and sharing the load with a willing victim^Wvolunteer should help with that.

I have recently configured my mail server to use IMAP. I started doing this when I was attending Linux.conf.au so that I could read urgent mail using my EeePC while at the conference and then be able to deal with the more complex stuff using my laptop later on. The next logical step is to have mail delivered to different folders in the IMAP account. While there are ways of doing this via the Subject and other header fields, my needs are not that great. All I need to do is to support user+extension@example.com going to a folder named extension in the user s mail store. While changing my mail server I decided to install Postfixadmin at the same time. My first attempt to use Maildrop was to put the following in the /etc/postfix/main.cf file:
mailbox_command = /usr/bin/maildrop -d mail -f $SENDER $DOMAIN $USER $EXTENSION That seems to only work when you have local accounts, so I ended up setting fallback_transport = maildrop and then putting the following in /etc/postfix/master.cf: maildrop unix - n n - - pipe flags=DRhu user=vmail argv=/usr/bin/maildrop -d vmail $ nexthop $ user $ extension Where vmail is a Unix account I created for storing mail. Then I added the following to /etc/postfix/main.cf. Some of these are probably redundant (such as the virtual_mailbox_base). The recipient limit is set to 1 because there are no command-line parameters for maildrop to support two recipients for the same message.
virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
virtual_gid_maps = static:2000
virtual_uid_maps = static:2000
virtual_mailbox_base = /mail
vmaildir_destination_recipient_limit = 1
virtual_transport = maildrop
maildrop_destination_recipient_limit = 1
The files /etc/postfix/mysql* all have fields user=, password=, hosts=, and dbname=. The queries in each of the files are as follows:
mysql_virtual_alias_maps.cf:query = SELECT goto FROM alias WHERE address='%s' AND active = 1
mysql_virtual_domains_maps.cf:query = SELECT domain FROM domain WHERE domain='%s'
mysql_virtual_mailbox_maps.cf:query = SELECT maildir FROM mailbox WHERE username='%s' AND active = 1 The /etc/courier/maildroprc file has the following contents: # log the maildrop actions
logfile "/var/log/maildrop.log" # parameters 1, 2, and 3 are the domain, user, and extension
DOMAIN=tolower("$1")
USER=tolower("$2")
EXTENSION=tolower("$3")
DEFAULT="/mail/$DOMAIN/$USER" # try making a backup (cc) copy of the mail but do not abort if it fails
exception
cc "$DEFAULT/.backup/"
# try delivering to the extension folder but do not abort if it fails
exception
if(length("$EXTENSION") != 0 && "$EXTENSION" ne "backup")

to "$DEFAULT/.$EXTENSION/"

# deliver to the main inbox if there is no folder matching the extension or if no extension is specified
to "$DEFAULT/"
Installing Postfixadmin [1] was another challenge entirely. One of the complications of this is that there is no Debian package for Lenny (it seems that there will be one in Squeeze - Lenny+1). I found David Goodwin s tutorial on installing Postfixadmin and lots of other things on Debian/Etch [2] to be a very useful resource. I look forward to seeing a Lenny version of that document. Please let me know if you can think of any way to improve this.

• [1] http://postfixadmin.sourceforge.net/


• [2] http://codepoets.co.uk/postfixadmin-postgresql-courier-squirrelmail-debian-etch-howto-tutorial

A bit of an unusual situation with drivel - I'm taking over maintenance from Neil McGovern and I've updated various parts of the package during that process. However, to avoid swamping Neil in wishlist [l10n] bugs during the time taken for the BTS etc. to switch over, I'm not sending a call for updated translations at this time, even though most of the current translations are out of date.

drivel is also quiet upstream and although there is an unreleased version in SVN that I will probably package once 2.0.3-4 is in Squeeze, I've checked the upstream po/ and none of the existing translations have been changed in SVN, beyond predictable changes in the line numbers where strings appear. There are a small number of new translations but most of these are also out of date:

$ msgfmt -c --statistics po-svn/ar.po
43 translated messages, 219 fuzzy translations, 43 untranslated messages.
neil@holly:test$ msgfmt -c --statistics po-svn/dz.po
305 translated messages.
neil@holly:test$ msgfmt -c --statistics po-svn/oc.po
91 translated messages, 214 untranslated messages.
neil@holly:test$ msgfmt -c --statistics po-svn/th.po
212 translated messages, 93 untranslated messages.
neil@holly:test$ msgfmt -c --statistics po-svn/zh_HK.po
297 translated messages, 4 untranslated messages.

Bizarrely, one has even been removed:

$ msgfmt -c --statistics po-current/no.po
149 translated messages, 29 fuzzy translations, 96 untranslated messages.

I'm pondering whether to join / take over upstream for drivel, at which point it becomes trivial to make a useful call for translations, get all the PO files updated both in the current package and in SVN and then make a fully updated release.

drivel already includes bg.po ca.po cs.po de.po el.po en_CA.po en_GB.po es.po fi.po fr.po ja.po lt.po nb.po ne.po nl.po no.po pa.po pl.po pt.po pt_BR.po ru.po rw.po sq.po sr.po sr@Latn.po sv.po vi.po zh_CN.po zh_TW.po and all of those are out of date.

So don't file i18n bugs against drivel just yet, wait for the call. Thanks.

I got an IPv6 tunnel/subnet during the weekend and set it up. So, for everyone who's visiting my blog or Buildd.Net can do this via IPv6 now. At least when I've not broke it again in the meantime. ;)

Sadly it's not a native IPv6 connectivity because the hosting company want charging me an extra amount of 29.- for that. Given the fact that the IPv4 Exhaustion Counter says that the IPv4 might be running out in 763 days, I don't think that this kind of extra charging will speed up the transition to IPv6.



Anyway, when you encounter problems in accessing my sites via IPv6, please drop me a note! For example I still need to setup rDNS and email... but http should work now - except for my SSL sites... but maybe that's a different story...

I m back from this years Cebit (well, yesterday already, just didn t write about it). Had a mostly good time that week, with our booth being small but visible to the visitors. In the first picture you see Rene (not our OpenOffice.org Rene :) ) setting up our second laptop, which we used whenever we had to show something to our visitors. The upper laptop with the presentation on it is my own. As it has a pretty big display we used it to continually have a presentation about Debian run. If there is no room for a projector this is a good alternative way. Later on we also had bb running, with customized texts for Cebit. As old as bb might be, it is still the best eye catcher you can have for a fair like Cebit. Nothing (well, maybe besides sex) works that good. We had a good week there, answering all sorts of questions. We had many people that knew nothing about Debian, Linux or even OpenSource and we had many that had heard about this other system already as well as people with very specific problems with various packages in Debian. There had been many people asking about the difference between Debian and Ubuntu and what we think about it, many told us they switched to Ubuntu for their Desktop but keep Debian on the Server because Ubuntu doesn t know what stability means, lots of others told us they switched back from Ubuntu because Debian is better. We also had those people that can not understand how Debian can exists if it doesn t sell anything and sometimes it turned out to be pretty hard to explain why we do what we do in a way they understand it. So all in all it was Cebit as usual. :) As one can read in the news, Cebit was much smaller than last year. 25% less exhibitors and 20% less visitors is very visible. Yet, besides a pretty tedious Sunday with the lowest visitor rate, the Debian booth wasn t much affected by it. We did have about all the usual people that visit us every year and for the rest, well, we are generic enough to attract attention from most visitors. This years booth was setup in a different way than the past years. As you can see on the pictures, it was a huge booth which had 15 different OpenSource projects on it, all arranged in isles of 3 tables each. We had BSD and Mozilla with us and the fsfe was our direct neighbor. Past years had an own booth per Project. Both ways have their advantages and disadvantages, and I think (and hope) next year will see a mixture of it. Large projects, which are known to attract lots of attention, like Debian, KDE or Mozilla, should have their own, seperated, booth. Something like 6 square meters each, placed as far away from each other as possible. Between those one or two larger areas having such tables arranged for smaller projects, like scribus or gosa will also give them a nice demonstration point and good access for visitors. Well, lets see how it will look like next year, it depends on many factors, the biggest being the money available to the OpenSource area.

When you order good into Switzerland, they will pass the customs office, where VAT and possibly import duties are levied. The customs office does not charge any duties if the total amount to be paid is less than 5 CHF Practically, given 7.6% VAT, this means that you can import 5 CHF / 0.076 = 65.79 CHF for free . As soon as you exceed this amount, it gets complicated. All of a sudden, the carrier charges you for the customs declaration it does in your name. What really blows my mind is that the fee to pay to the carrier (more on that later) actually plays into the whole equation. Let s assume you order goods for 100 CHF, which is well above the free import limit. You also paid 10 CHF for shipping. The carrier charges you 20 CHF to do the customs presentation for you. There, they determine that import duties are 5 CHF, and you end up paying: (100 + 10 + 20 + 5) * 107.6% = 145.26. That s fun, isn t it? I continue to be amazed by all the ways in which the government sucks money from your pockets. What s similarly baffling is how some carries deal with this. The Swiss Post (and their ally TNT) makes you pay taxes, duties, and fees on delivery, and their charges are the lowest when compared to the other carriers. With this approach, you have the option to refuse the package, if you re willing to deal with the vendor to get your money back. DHL is the only other carries I know who does things like the Swiss Post. However, due to their extraordinary crap performance and service, I could never recommend them to anyone. The three letters of DHL, a German company, apparently stand for das heisst langsam this means slow . None of the other carriers give you the option to accept the duties and their services. For instance, GLS delivers your parcel, and some weeks later you get an invoice, asking for the taxes and duties, and charging a fee of 45 CHF for their service, which you ve never really asked for and which you could not refuse. UPS, FedEx, and DPD fall into the same category, but their charges are lower. The one and only time I had used GLS to have something shipped to me, I called them up to complain about their invoice, and replied with an invoice of my own, in which I charged the same amount for opening and reading your letter and giving your call-centre employee the chance to talk to me directly . They got the message and dropped the invoice. The next step should be to play them off against each other: create some pencil art, write an invoice for half a million, and pay UPS to deliver the package to GLS headquarters. Attach a miniature audio transmitter to the invoice for added fun. NP: Goldie: Timeless