Google seems to become more and more annoying. Package download http://dl.google.com/linux/chrome/deb/ is slow. Not just slow, but slow. Any random apt-get update will take ages; just sitting there waiting for Google's servers to send any data. Downloading actual packages is slow, as well. Ironically, Google's PageRank will punish sites for loading slowly; it's a pity they don't use their considerable server & bandwidth capacities to fix slowness they are causing, themselves. Chrome Copy and paste is a central part of what I use a mouse for. X has had two copy buffers for as long as I can remember, one for mouse selection, pasting with middle mouse button and one for CTRL-c/CTRL-v. Chrome merges the two. That's bad enough in and as of itself, but every time Chrome gets focus, it will clobber anything you may have in your copy buffers at that time with anything that's selected. No matter if you selected it via mouse, via keyboard, a context switch autoselected something. Selection goes into buffer. Every time. Every. Single. Time. To add insult to injury, this is dependent on which tab is active. And if you happen to search on the site (CTRL-f), it will always use what's in the search bar to clobber buffers, no matter if anything on the actual website has been selected. I can't find the bug report about this at the moment, but Google's stance is that this is a feature and introducing an option for traditional copy & paste handling is not desirable. Google+ I get that they feel a need to combat Facebook, but still, pushing Google+ on you is just annoying. At least the Android application has had a permission change on ICS so it can not auto-update. It's the little things ;) WWW Unified branding, the need to support touch-based devices in their UI, etc. Still, GMail's new interface sucks and the old one will be going away for good. And while making some UI elements larger or displaying them unconditionally makes sense for hand-held portrait displays, this is highly annoying on wide-screen landscape displays. 1366x768 may have overtaken 1024x768, but 768 is a constant here and still not a lot. As an aside, hopefully the Apple Effect and the iPad 3 will break the age-long stalemate with regards to screen resolution. More is better, here. Android Bloatware Using stock Android means you won't get Facebook and other useless apps pre-installed. Yet, uninstalling stock applications, like Google+, is impossible. Rights management It's nice that I get to see what kind of access an application would like to have. It's not nice that I can not choose what access I am willing to grant any given application. I can make a binary decision, install or not install, but I can't refuse random access rights to applications. There are custom versions of Android out there which allow you to do this and many applications seem to cope with being unable to do some things. This should be a standard feature. Access management The concept of "access to USB storage" meaning "whatver your SD card or, in the Galaxy Nexus' case, just a specific directory" is also broken. There is a middle ground between "this application needs access to a large chunk of storage" and "this application needs complete access to said large chunk". Just assign the application a specific directory to write into and read from and done's done. Multi-user I can not hand anyone my phone to play a game or surf the Internet without giving them the ability to look through all my email, contacts, calendar, you name it. While I only give my phone to people I trust completely, this still sucks. How hard can it be to create a minimal guest mode which allows people to access a few pre-selected applications with a custom setting of if they are allowed to use cellular data and/or WiFi? Data access Authorized Access Ah, the big one.... Keep in mind that I am using Google's latest and greatest, the Samsung Galaxy Nexus GSM. It's as cutting-edge as you can get. Yes, having one continuous storage device is nice. But MTP support on Linux is abysmal and you are forced to access your data by means of MTP or PTP. gphoto2, gwenview, and gthumb are all unable to import any photos via PTP; no program I tried can transfer anything via MTP. gphoto2 will transfer the background images which APOD (highly recommended, by the way; there's also a donation application for this) stores on my phone. That's it. So, unless I send email to myself, use WiFi-based hacks, or root my phone, I can not access my data. On the strongest mobile platform in the world. Using the most powerful and versatile OS with up-to-date packages. In 2012. Yay. Unauthorized Access Not being able to access my data is a Bad Thing. Even worse is when others can access my data. Contrary to older Android versions, someone decided that it would be a good idea to allow MTP or PTP, only. As in "you can not disable MTP and PTP. One of them has the be activated." This is awesome when you want to charge your phone at an airport or at an acquaintance's possibly malware-ridden Windows machine. Everyone and their bot-herder can potentially access my data while I can not. Usability And while MTP/PTP is an either/or decision, they are using check-boxes, not radio buttons. There's a decade or more of UI experience about check-box versus radio button, so why not use it? I know of at least one owner of a Galaxy Nexus who was not even aware that he couldn't turn off MTP (the default) as the UI pretends otherwise. Opaqueness And good luck trying to contact anybody about this. Having filed a few bugs against Google stuff in the past, I simply gave up on it. Back when Gmail's mailing list filtering and labelling system was somewhat broken, I spent months hunting down people who knew people who knew someone who was able to actually do something about it.

Still waiting for mine - though I did buy a case for when it comes. News from www.raspberrypi.org - the prototype submitted for EMC testing has apparently passed, though the paperwork has to be validated (blog posting).
It has passed CE marking, FCC part 15 marking, Canadian certification and the Australian C-Tick scheme. There is also an updated trademark policy at new trademark rules ( http://www.raspberrypi.org/trademark-rules ) and a video over at the Farnell/Element14 website from Eben Upton detailing how to set up the Raspberry Pi, shots of booting, explanations of how to use an editor, compile a first Python program and how to build the graphics demos provided. ( http://www.element14.com/community/docs/DOC-44459 )

Behind Debian Edu and Skolelinux there are a lot of people doing the hard work of setting together all the pieces. This time I present to you Andreas Mundt, who have been part of the technical development team several years. He was also a key contributor in getting GOsa and Kerberos set up in the recently released Debian Edu Squeeze version. Who are you, and how do you spend your days? My name is Andreas Mundt, I grew up in south Germany. After studying Physics I spent several years at university doing research in Quantum Optics. After that I worked some years in an optics company. Finally I decided to turn over a new leaf in my life and started teaching 10 to 19 years old kids at school. I teach math, physics, information technology and science/technology. How did you get in contact with the Skolelinux/Debian Edu project? Already before I switched to teaching, I followed the Debian Edu project because of my interest in education and Debian. Within the qualification/training period for the teaching, I started contributing. What do you see as the advantages of Skolelinux/Debian Edu? The advantages of Debian Edu are the well known name, the out-of-the-box philosophy and of course the great free software of the Debian Project! What do you see as the disadvantages of Skolelinux/Debian Edu? As every coin has two sides, the out-of-the-box philosophy has its downside, too. In my opinion, it is hard to modify and tweak the setup, if you need or want that. Further more, it is not easily possible to upgrade the system to a new release. It takes much too long after a Debian release to prepare the -Edu release, perhaps because the number of developers working on the core of the code is rather small and often busy elsewhere. The Debian LAN project might fill the use case of a more flexible system. Which free software do you use daily? I am only using non-free software if I am forced to and run Debian on all my machines. For documents I prefer LaTeX and PGF/TikZ, then mutt and iceweasel for email respectively web browsing. At school I have Arduino and Fritzing in use for a micro controller project. Which strategy do you believe is the right one to use to get schools to use free software? One of the major problems is the vendor lock-in from top to bottom: Especially in combination with ignorant government employees and politicians, this works out great for the "market-leader". The school administration here in Baden-Wuerttemberg is occupied by that vendor. Documents have to be prepared in non-free, proprietary formats. Even free browsers do not work for the school administration. Publishers of school books provide software only for proprietary platforms. To change this, political work is very important. Parts of the political spectrum have become aware of the problem in the last years. However it takes quite some time and courageous politicians to 'free' the system. There is currently some discussion about "Open Data" and "Free/Open Standards". I am not sure if all the involved parties have a clue about the potential of these ideas, and probably only a fraction takes them seriously. However it might slowly make free software and the philosophy behind it more known and popular.

On my everyday netbook (a very reliable first generation ASUS EeePC 701 4G) the disk (4 GB as the product name suggests :-) is nearly always close to full. TL;DWTR? Jump directly to the HowTo. :-) So I came up with a few techniques to save some more disk space. Installing localepurge was one of the earliest. Another one was to implement aptitude filters to do interactively what deborphan does non-interactively. Yet another one is to use du and friends a lot ncdu is definitely my favourite du-like tool in the meanwhile. Using du and friends I often noticed how much disk space /usr/share/doc takes up. But since I value the contents of /usr/share/doc a lot, I condemn how Nokia solved that on the N900: They let APT delete all files and directories under /usr/share/doc (including the copyright files!) via some package named docpurge. I also dislike Ubuntu s solution to truncate the shipped changelog files (you can still get the remainder of the files on the web somewhere) as they re an important source of information for me. So when aptitude showed me that some package suddenly wanted to use up quite some more disk space, I noticed that the new package version included the upstream changelog twice. So I started searching for duplicate files under /usr/share/doc. There are quite some tools to find duplicate files in Debian. hardlink seemed most appropriate for this case. First I just looked for duplicate files per package, which even on that less than four gigabytes installation on my EeePC found nine packages which shipped at least one file twice. As recommended I rather opted for an according Lintian check (see bugs. Niels Thykier kindly implemented such a check in Lintian and its findings are as reported as tags duplicate-changelog-files (Severity: normal, from Lintian 2.5.2 on) and duplicate-files (Severity: minor, experimental, from Lintian 2.5.0 on). Nevertheless, some source packages generate several binary packages and all of them (of course) ship the same, in some cases quite large (Debian) changelog file. So I found myself running hardlink /usr/share/doc now and then to gain some more free disk space. But as I run Sid and package upgrades happen more than daily, I came to the conclusion that I should run this command more or less after each aptitude run, i.e. automatically. Having taken localepurge s APT hook as example, I added the following content as /etc/apt/apt.conf.d/98-hardlink-doc to my system:

// Hardlink identical docs, changelogs, copyrights, examples, etc
DPkg
 
Post-Invoke  "if [ -x /usr/bin/hardlink ]; then /usr/bin/hardlink -t /usr/share/doc; else exit 0; fi"; ;
 ;

So now installing a package which contains duplicate files looks like this:

~ # aptitude install perl-tk
The following NEW packages will be installed:
  perl-tk 
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,522 kB of archives. After unpacking 6,783 kB will be used.
Get: 1 http://ftp.ch.debian.org/debian/ sid/main perl-tk i386 1:804.029-1.2 [2,522 kB]
Fetched 2,522 kB in 1s (1,287 kB/s)  
Selecting previously unselected package perl-tk.
(Reading database ... 121849 files and directories currently installed.)
Unpacking perl-tk (from .../perl-tk_1%3a804.029-1.2_i386.deb) ...
Processing triggers for man-db ...
Setting up perl-tk (1:804.029-1.2) ...
Mode:     real
Files:    15423
Linked:   3 files
Compared: 14724 files
Saved:    7.29 KiB
Duration: 4.03 seconds
localepurge: Disk space freed in /usr/share/locale: 0 KiB
localepurge: Disk space freed in /usr/share/man: 0 KiB
localepurge: Disk space freed in /usr/share/gnome/help: 0 KiB
localepurge: Disk space freed in /usr/share/omf: 0 KiB
Total disk space freed by localepurge: 0 KiB

Sure, that wasn t the most space saving example, but on some installations I saved around 100 MB of disk space that way and I still haven t found a case where this caused unwanted damage. (Use of this advice on your own risk, though. Pointers to potential problems welcome. :-)

I recently had a bug report in jffnms that the SLA checks were failing with bizarre calculations. Things like 300% disk drive utilization and the like. Briefly, JFFNMS is written in PHP and checks values that come out of rrdtool and makes various comparisons like have you used more than 80% of your disk or have there been too many errors. The logs showed strange input variables coming in, all were integers below 10. I don t know of many 1 or 3 kB sized disk drives. What was going on? I ran a rrdtool fetch command on the relevant file and got output of something like 1,780000e+07 which for an 18GB drive seemed ok. Notice the comma, in this locale that s a decimal point hmm. In lib/api.rrdtool.inc.php there is this line around the rrdtool_fetch area: A quick check and I was finding that my 1,7 e+07 was coming back as 1. We had a float conversion problem. Or more specifically, php has a float conversion problem. I built a small check script like the following: Which gave the output of:

Decimal is , . Pi is 3,14 and 3 Half is 0,5

So PHP is saying that decimal point is a comma and it uses it BUT if a string comes in with a comma, its not a decimal point. Really?? Are they serious here? I tried various combinations and could not make it parse correctly. The fix was made easier for me because I know rrdtool fetch only outputs values in scientific notation. That means if there is a string with a comma, then it must be a decimal point as it could never be used for a thousands mark. By using str_replace to replace any comma with a period the code worked again and didn t even need the locale to be set correctly, or that the locale for the shell where rrdtool is run is the same as the locale in php.

Related articles

• More On PHP s Bad Design (ilyabirman.net)
• PHP is crazy (ma.tt)
• PHP team announces 5.4.1 release date (webdev360.com)
• The Design of PHP is Awesome (ilyabirman.net)

Two weeks ago, I was at LOAD, where I did a tutorial on Debian Packaging. Unfortunately, I wasn't doing very well physically, and as a result my preparation wasn't what I had hoped for. It ended up being not so much a tutorial as a walking the audience through packaging a piece of software in casu NBD with debhelper in dh mode. Not very difficult, but since there's nothing for people to fall back on afterwards, it may help if they have a writedown of what I said during the session; and I promised to put it on my blog. So, here goes. However, note that the canonical written tutorial on Debian Packaging is here. With apologies to readers of Planet Debian, most of whom for which all this is probably old hat. Unlike RPM packaging, in Debian, the data that tells the debian packaging system how to package a piece of software is functionally split among a number of files. All these files go in a toplevel directory in the source package, (unsurprisingly) called 'debian'. There are four files that are required for every Debian package: the control, changelog, copyright, and rules files. Without these files, dpkg-dev will fail to produce a package any package. The first, the control file, contains metadata on packages: the name of the package, its description, the dependencies, etc. Basically, almost all the information you see when you run 'apt-cache show <package>' (with one exception) is in the control file. If you have a source package that builds multiple binary packages, then you should have multiple 'Package' stanzas in the control file. In my opinion, creating a control file is easiest done by copying a control file from another (similar?) package, and modifying it to suit the software you're dealing with. The one exception, the one bit of metadata that is not found in the control file is the version number: this data is contained in the changelog file. This file looks like a free-form file for the most part, but it really is a machine-parsable format; as such, it's best to edit it with specialized tools, such as the debian-changelog-mode in the emacs editor, or the debchange script, also available as dch, from the devscripts package. In the changelog, you should document any changes you make to the package, making sure the version number (top line), distribution (unstable, experimental, stable, ...; top line), urgency (top line; used mainly when testing needs to be updated urgently for things like security updates), author (bottom line) and date and time (also bottom line) are correct. The copyright file, unsurprisingly, should contain the copyrights statements of the original software, and the license (or a reference to a copy of the same license text under /usr/share/common-licenses). This file is still free-format in most packages today, although a machine-readable format for this file has recently been defined. Of the four required files, this is probably the most boring one, but hey, we can't like everything we do. The last file, the rules file, is where all the action happens. This file is defined as a Makefile, of which the targets are called for various parts of the build system. The rules file has a number of required targets (such as build, clean, and others), but if you're using debhelper in dh mode, you don't need to worry about those; instead, you can use the following simple rules file:

#!/usr/bin/make -f
%:
	dh $@

With the first line, the shebang, we make clear that this is a makefile, and that it should be called by make. The next is a generic target (the % is a wildcard for make), with just one command: 'call dh with the name of the target being called'. Since dh implements all required rules targets, that immediately gets you a working package. Go ahead, try! Run 'dpkg-buildpackage -rfakeroot', and see what happens. Did that work? Maybe, maybe not. First, you'll have seen loads of warnings about something involving a "compatibility level". This is from debhelper; this compatibility level, or 'API level' if you wish, allows debhelper to move forward and make incompatible changes without breaking all the existing packages out there; whenever the compat level is bumped, some new functionality will only be made available if you also raise the compat level in your source package (and then you'll know you may have some changes to do in your package). Since the original debhelper, over a decade ago, did not have a compat level, the absense of a compat level signals compat level 1, which is far outdated now, and about to be unsupported. Hence the warning. The fix is simple: create a file debian/compat containing a single number: the compatibility level you're working with. It's best to use the most recent level which debhelper supports when you create your package, which as of this writing is level 9. Ignoring the compatibility level, if you're building a software package which uses a well-established build system, and you only build one binary package out of that, chances are pretty high that everything worked as expected. If not, you'll have more work. Building multiple packages requires that you tell debhelper somehow which file goes in which package. You can do this with a file debian/package.install, where package is the name of the binary package you're building. The install file is read by dh_install, one of many tools in the debhelper suite. You see, in the old days (before debhelper 7), debhelper was just a suite of tools, which required that you wrote a debian/rules file containing all the individual tools to be called in the correct order. This mode is still supported; in fact, even if you do use dh, you do, since all that tool really does is call the right tools in the right order; the real work is done by the invidual tools. They all have their own man page; to understand how dh_install chooses which file to put in which package, go read man dh_install. Go ahead, do it now; I'll wait. Back? Good. You've now learned that dh_install can install files either from the source directory (useful for packages containing only scripts or so), or from a directory debian/tmp. If you use an autotools-based software package, this is what dh will do for you. When you called dpkg-builpackage above, you may also have noticed that the output contained many lines starting with dh_, one of which said dh_install. As you may have guessed, dh echoes every debhelper command just before it will execute them. This allows you to look at the output, and see what's happening. For more detail, set the environment variable DH_VERBOSE to a non-zero value. I'm sure you'll have seen one or two debhelper tools that could make your package better. Go ahead, go and read their man pages to see what they do, and how they do it. Most of these will require you to create a file debian/package.toolname to specify details. In some cases, you may need to specify command-line arguments to the tool to get it to do what you want. In yet other cases, the tool won't support what you need it to do, and you'll have to do something manual. What to do now? The dh command line doesn't support adding extra commands easily. Does this mean you'd have to revert to old-style long, non-dh debian/rules files? Luckily, no. You can create an override target. If dh detects that you have such a target for a particular tool, it will call that target instead of the tool. This target's rules can then call the tool in question (or not), and add any command line arguments, or extra commands, as needed. An override target is a normal Makefile target with a name of the form override_dh_something, where dh_something is the name of the tool you wish to override. At this point, I'd reached almost the end of my two allotted hours, and a member of the audience asked how to make dpkg deal with configuration files. The answer is, you don't need to do anything! Not if you use debhelper, anyway; all you need to do is install the file in /etc. Since debian policy specifies that all files in /etc need to be configuration files and that no conffiles may be placed anywhere but in /etc, debhelper will automatically mark any file installed in /etc as a conffile, which will cause dpkg to ask the user what to do with changes to such files. Note that in Debian parlance, a conffile is not the same thing as a configuration file: a conffile is a configuration file that is part of the binary package (i.e., if you call 'dpkg --contents' on the .deb file, you'll see it in the output), whereas a configuration file is a file (any file, including files generated during or after installation of the .deb file on a system). Occasionally, this is also why some differences to configuration files are managed through debconf, while others aren't: the ones managed through debconf are non-conffile configuration files managed through ucf, whereas the others are conffiles. So in the simplest of cases, if you want to install a configuration file and you want to make sure it's protected against accidental overwrites by package upgrades, all you need to do is make sure it's installed to /etc; debhelper will do the rest. And that concludes this introduction. Please note it's only an introduction, not a full-blown tutorial; while this will allow you to get started, you may have to learn a bit more if you wish to eventually upload a package to Debian.

Normally people aren't stupid or evil enough to demand that I not use a word at all. On the occasions that they are that stupid or evil, typically only one word is singled out. Thus, when someone demonstrates enough unwisdom to give me a list, I feel the need to share publicly:

• moist
• foodie
• panties
• partner in crime

Seriously.

RS and Farnell have started contacting the first wave of customers: some of the first Raspberry Pi boards will be shipping tomorrow and over the weekend.

Similarly, the two distribution companies are ramping up for constant rolling production and mass volume shipping.

Raspberry Pi post

[Courtesy www.raspberrypi.org - Raspberry Pi is a trademark of the Raspberry Pi foundation which is a registered charity in the UK]

Many websites have addresses that use a www.- prefix. Some people are encouraging this practice, other are advising against it. I, for one, think this prefix makes sense and is really useful, so here is an explanation of my opinion. In a nutshell: the Wold Wide Web is one Internet service among many other such as domain name, mail, mailboxes or instant messenging; using a dedicated prefix allows to distribute all these services to specific servers in a convenient way.On Internet, you can expose several services, the most common being domain names (DNS), websites (HTTP), incoming mail (SMTP), outgoing mail submission (submission), mailbox fetching (POP) or consultating (IMAP) and instant messenging (XMPP). Constraints Modern Internet services can have constraints such as load balancing, failover and most importantly the possibility to use specific servers for each service instead of having all of them on the same server. Dedicated records Some service were designed or revised to take these contraints into account; this include the domain name, incoming mail and instant messenging, by using dedicated DNS records:

example.com.                    NS              roquefort.example.com.
example.com.                    MX  10          morbier.example.com.
_xmpp-server._tcp.example.com.  SRV 10 100 5269 morbier.example.com.

In that example, the name service of example.com. is provided by the server Roquefort while the incoming mail and instant messenging service are provided by Morbier Dedicated prefixes On the contrary, some services were not designed to take these constraint into account, and may be too fossilized to be revised for that; this includes the Web and mailbox service. A convenient way to work around the antiquated design of these services is to use a well known prefix:

www.example.com.                CNAME           ossau-iraty.example.com.
smtp.example.com.               CNAME           morbier.example.com.
pop.example.com.                CNAME           morbier.example.com.
imap.example.com.               CNAME           morbier.example.com.

In that example, the Web service of example.com. is provided by the server Ossay-Iraty while the email submission and mailbox services are provided by Morbier. Readability and flexibility Using dedicated records and prefixes increases the consistency and readability of a DNS zone, since it allows to refer to the servers by their canonical host name, and to define their IP addresses once and for all:

; Services
example.com.                    NS              roquefort.example.com.
example.com.                    MX  10          morbier.example.com.
pop.example.com.                CNAME           morbier.example.com.
imap.example.com.               CNAME           morbier.example.com.
www.example.com.                CNAME           ossau-iraty.example.com.
; Hosts
roquefort.example.com.          A               192.2.0.12
                                AAAA            2001:db8::12
morbier.example.com             A               192.2.0.42
                                AAAA            2001:db8::42
ossau-iraty.example.com.        A               192.2.0.51
                                AAAA            2001:db8::51

You can think of that practice as connecting dots between services and hosts:

name service    Roquefort
incoming mail   Morbier
mailboxes         Ossau-Iraty
website        

With such a DNS zone, it is very easy to identify which server is hosting each service. Using host names rather than IP addresses multiple times reduces the information duplication, which in turn facilitates future chances and reduces the risk of error (it is easier to swith the website from Ossay-Iraty to Morbier than from 192.2.0.51/2001:db8::51 to 192.2.0.42/2001:db8::42).

The Debian Project is pleased to announce that registration is now open for DebConf12, which will take place in Managua, Nicaragua, from Sunday 8 July to Saturday 14 July 2012. The conference will be preceded as usual by one week of DebCamp, from Sunday 1 July to Saturday 7 July. As previous years, three different registration options will be available: Sponsored, Professional and Corporate. Through the Sponsored category, the Debian Project intend to help some people attend who would not be able to pay for their own travel to DebConf. The Corporate category, with a USD 1300 (EUR 1000) registration fee is intended for those attending DebConf as representatives of companies. The Professional category, with a USD 650 (EUR 500) registration fee, is intended for any individual or company who wants to help the conference by paying the direct costs of their attendence. It will only be possible to apply for food and accommodation grants and/or travel grants until 15 May. For more detailed information about how to register, please see the separate announcement from the DebConf team. Call for papers Debian invites submissions of proposals for papers, presentations, discussion sessions and tutorials for its DebConf12 conference. Submissions are not limited to raditional talks: you could propose a performance, art installation, debate, or anything else. Official submissions will be accepted until 1 June 2012, 23:59 UTC. This year, we will continue to organize some talks into thematic tracks. If you have a proposal for a DebConf track, please contact <debconf-team@lists.debconf.org>. Previous examples included Debian Science, Debian Infrastructure, and Community Outreach tracks. If you would like to be a track coordinator, please volunteer on that list. Detailed information on how to submit an event are available on the mail from the DebConf team.

Agile processes harness change for the customer's competitive advantage. Principles behind the Agile Manifesto

After two and a half years at Smoothwall, I'm moving on - Friday is my last day. Since I joined the development team, we have adopted Agile development, set up a pretty nifty Gerrit/Jenkins code review + integration system, and introduced dpkg for package management. Along the way, I helped with a bunch of important features for the business, like a ground-up rewrite of the web filter, and time-based browsing usage quotas. I will be starting at CV-Library on Monday, for a whole new set of challenges. They're based in Fleet, so I'll have an hour-long commute each way on the train. I've been assured by an expert in these matters that facilitating wage slavery is a comparatively more ethical pursuit than facilitating internet censorship. :) To make the commute somewhat more bearable, I'm moving house on Saturday. So far, the packing's going quite well...

---

---

---

how embarassing, i make a point of asking for comments and critique on my previous post but comments didn't actually work unless you're logged in. I only noticed because someone emailed me. It was the admin-ssl plugin. de-activated now, so comments are working again. A few people tried to add comments according to the log if you feel like making them again, go right ahead. thanks Craig comments working again is a post from: Errata

I ve been getting a lot of spam recently from people wanting to write guest posts or have their site included in a future links post. Guest Posts For guest posts the social convention for the planets which aggregate my blog seems to be that random guest posts are unacceptable. I could change my blog feed to have some posts excluded from the planet feeds but that s too much effort and I don t want random guest posts anyway. The only situations in which I will accept guest posts are when someone is writing what I might have written (IE they generally agree with me) or if they are a member of the free software community who doesn t have their own blog but has something relevant to say. Any applicant for a guest post who runs a business that is useless and/or evil IMHO (EG anything related to the TSA) is going to get rejected firmly. Any applicant who tells me that they can write on a wide variety of topics probably isn t capable of making me an offer that I would accept. Tell me that you can write about Linux programming or computer security and I ll be interested, but you have to provide links to your previous work. An application to write a guest post that starts with something like I liked your recent post at the above URL but I think you missed some important points, as I have some experience in that field I think I could write a guest post that would help educate your readers may be accepted. Probably the best thing to do however is to write comments on my blog, if you can write informative comments and offer to make a longer comment into a guest post then there s a good chance that I ll be interested. Generally though I will only offer the opportunity to write a guest post to someone who writes something really informative in private email or on a closed mailing list. If you can solve a technical problem about Linux that has me stumped then I will almost certainly be willing to accept a guest post about it! Links Posts There are many sites which consist of nothing but links to other sites. In the 90 s such sites were really useful but since the rise of Google their value has declined dramatically. As an aside when I ran an Internet Cafe in the 90 s I had every web browser start with the main page of my Hot Stuff list, the purpose of this was to increase the hit rate of my Squid cache by having most of the customers visit the same sites. Even back then I probably wouldn t have bothered if it wasn t for Squid hits. It must seem like an easy way to make money to create pages of links to articles with short summaries and then hope for advertising revenue, a domain sale, or the launch of some sort of profitable business once people start using the site. I wonder whether that ever works out for people. It doesn t seem like a good business model, doing something that requires little skill, which can be done by almost anyone, and which is done by many people. Maybe there are sweat-shops dedicated to this. Anyway my links posts are unlikely to ever link to any such links pages, I don t think that the people who read my blog want double indirection. I won t entirely rule out linking to a links page, but it would have to be of very high quality and related to something very technical about computers. Basically anyone who reads this should give up on the idea of submitting a links page to me, if it s good enough to make me break my policy of not linking to such things then I ll probably find it myself. Conclusion As a general rule if you want someone to publish your work then you need to look at what they are publishing and make sure that your work fits. With the recent requests for links and guest posts I ve been getting I have to wonder whether the people making the requests have even read my blog. That method of operating is unlikely to give any success at a blog that has any reasonable number of readers. I ll probably link to this from my about page or something. It might discourage some of the spammers. Related posts:

1. Link Within Good Things about LinkWithin For the last 10 weeks I ve...
2. Feedburner Item Link Clicks For a while I used the Item Link Clicks feature...
3. Can you run SE Linux on a Xen Guest? I was asked Can you run SELinux on a XEN...

Today I took that final step:

touch /srv/_global_/blacklisted/domains/aol.com

I remember, even a couple of years ago, I had friends who would mail me from their @aol.com email addresses. These days people have moved on. The two single biggest mail-providers I see in terms of spam are:

• @yahoo.com - 832 in the past nine days.
• @aol.com - 242 in the past nine days.

I'd like to drop @yahoo.com but I have some (misguided) friends who continue to use it to mail me. I might start dropping non-friend mails from that domain, but that's a bigger job. Yes, this is a dull entry. Sorry. My existing bathroom has been ripped out and turned into this as a stepping stone into its new incarnation. I'm trapped in my office. Dust almost everywhere. Noise everywhere else. ObQuote: "There can be no understanding between the hand and the brain unless the heart acts as mediator. " - Metropolis

apport just cleared the new queue and is now available in experimental. For those who do not know what apport is:

Debugging program crashes without any automated tools has been pretty time consuming and hard for both developers and users. Many program crashes remain unreported or unfixed because:

• Many crashes are not easily reproducible.

• End users do not know how to prepare a report that is really useful for developers, like building a package with debug symbols, operating gdb, etc.

• A considerable part of bug triage is spent with collecting relevant information about the crash itself, package versions, hardware architecture, operating system version, etc.
• There is no easy frontend which allow users to submit detailed problem reports.
• Existing solutions like bug-buddy or krash are specific to a particular desktop environment, are nontrivial to adapt to the needs of a distribution developer, do not work for crashes of background servers (like a database or an email server), and do not integrate well with existing debug packages that a distribution might provide.

Apport is a system which

• intercepts crashes right when they happen the first time,
• gathers potentially useful information about the crash and the OS environment,
• can be automatically invoked for unhandled exceptions in other programming languages (e. g. in Ubuntu this is done for Python),
• can be automatically invoked for other problems that can be automatically detected (e. g. Ubuntu automatically detects and reports package installation/upgrade failures from update-manager),
• presents a UI that informs the user about the crash and instructs them on how to proceed,
• and is able to file non-crash bug reports about software, so that developers still get information about package versions, OS version etc.

At this moment, it is quite broken. The crashes are not intercepted by update-notifier on my box. With it now in experimental, my intent is to slowly integrate it well with all dependent tools for Debian. It won't be ready for the Wheezy release, but hopefully for the one after that.On the Ubuntu side, Canonical hosts a retracing service that takes user reported core dumps and generates a usable backtrace. For Debian, my plan is to have a chroot kind interface, where in the user could opt-in to download all debug packages to generate a valid backtrace. This could go as the debian backend for apport in the future. On the bug reporting side, afaik, we do not have a web interface to lodge bugs. To report bugs (minus the core dumps), we will want a backend to submit it over email. The current apport report gathering tool is pretty good (if compared to other tools like reportbug), so here the low hanging fruit would be to just take the report and feed in email to our BTS server. For the eyes:

I met Francesca in Debconf 11 in Banja Luka. If I recall correctly, it s Enrico Zini who introduced me to her, because she was the madamezou (her IRC nickname) who started to get involved in the publicity team. Since then and despite having a bachelor thesis to complete she got way more involved and even gained official responsibilities in the project. Before starting with the interview, I wanted to mention that Francesca is drafting a diversity statement for Debian I was expecting the discussions to go nowhere but she listened to all objections and managed to improve the text and build a consensus around it. Thank you for this and keep up the good work, Francesca! Rapha l: Who are you? Francesca: My name is Francesca, I m 30 and I studied Social Sciences. Currently I live in Italy but I m planning to go abroad (not a lot of jobs here for geeky social scientists). Apart for Debian and FLOSS world in general, I have unrestrained passions for chocolate; zombie movies; sci-fi; zombie books; knitting sewing crafting and DIY in general; zombie videogames; bicycles; pulling apart objects to look inside them; splatter B movies, David Foster Wallace s books, playing trumpet, and did I already mentioned zombies? Days are too short for all this stuff, but I try to do my best. Raphael: How did you start contributing to Debian? Francesca: Some years ago I was stuck in bed for literally some months, due to a grave series of migraine attacks. I wasn t able to do anything: no social life, no books or television. So, I decided to turn on the laptop and do something constructive with it: I was already a Debian user and it seemed quite logical to me to try to give back to the community. I am not a coder and I ve not studied Computer Science, so my first step was to join an Italian Debian on-line community (Debianizzati) and help with tutorials, users support, wiki management. In a couple of months I learnt many things: helping other users with their problems forces you to do lots of research! My first contributions to the Debian project were mostly translations of the main website. Translators are the perfect typos spotters: they work so precisely on the text to be translated that they finish to do a great QA job. This is how I ve started to contribute to the Debian website: with very simple things, fixing typos or wrong links or misplaced wml tags. I still remember my first commit to the website: the idea was to undercase some tags, but it ended up that I misplaced some of them and in addition I fixed them only in the English page and not on the translations as well. When after a couple of minutes, K re Thor Olsen a long time contributor of the team and now webmaster reverted my commit, I felt so stupid and full of shame. But, to my great surprise, no one treated me like an idiot for that error: Gerfried Fuchs, one of the guru of the team, replies me in a really helpful and polite way explaining what I did wrong and how to do things correctly. I think this episode was a turning point in my Debian life: there s this idea that Debian Developers are just a bunch of arrogant assholes and maybe it was true in the past, but for my experience they are not. Well, at least the ones I met and work with .

To my great surprise, no one treated me like an idiot for that error.

Since then, I joined the WWW team and helped them apply the shiny new design provided by Kalle S derman. A lot of work was done during the week immediately before the release of the new website. Oh that was a week! We worked night and day to have the new design ready for February 6th, and it was fantastic when we finally published it, simultaneously with the release of Squeeze. At the same time, I started to contribute more actively to the Debian Publicity team, not only translating news but also writing them. It can sound scary for a non native English speaker to write something from scratch in English, but you have to keep in mind that your text will be reviewed by native speakers before being published. And we have some fantastic reviewers in the English localisation team: particularly Justin B Rye, who is tireless in his effort and more recently Moray Allan. I think I m particularly lucky to work with all these people: there s a special mood in both Publicity and WWW team, which makes you feel happy to do things and at the same time pushes you to do more just because it s fun to work with them sharing jokes, ideas, rants, patches and hugs. Rapha l: I believe that you have been trough the new member process very quickly. You re now a Non-Uploading Debian Developer. How was the experience and what does this mean to you? Francesca: Becoming a Debian Developer was not so obvious for me, because I didn t need to be a DD for the work I do in Debian. For instance, I don t maintain packages, so I had no reasons to want to become a DD in order to have uploading rights. For a while I didn t really feel the necessity of being a DD. Luckily, some people started to pester me about it, asking me to apply for the NM process. I remember Martin Zobel-Helas doing this for an entire week every single day, and Gerfried Fuchs doing it as well. Suddenly, I realized that people I worked with felt that I deserved the DD status and that I simply had thought I didn t. As a non coder and a woman, there probably was a bit of impostor syndrome involved. Having people encouraging me, gave me more confidence and the desire to finally become a DD. And so I did. The process for non uploading DD is identical to the one to become an uploading DD, with one exception: in the second part of the process (named Tasks and Skills) instead of questions about how to create and maintain packages, there are questions about the non packaging work you usually do in Debian. The general resolution which created the possibility to become a non uploading DD gave us a chance to recognize the great effort of Debian contributors who work in various area (translations, documentation, artworks, etc.) that were not always considered as important as packaging efforts. And this is great because if you are a regular contributor, if you love Debian and you are committed to the project, there are no reasons to not be an official member of it. With regards to this, I like the metaphor used by Meike Reichle in her recent talk about the Debian Women Project (video recording here):

a Debian Developer status is a lot like a citizenship in a country that you re living in. If you live in a country and you don t have citizenship, you can find a job, buy a house, have a family [...] but if this country at any point in time decides to go into a direction that you don t like, there s nothing you can do about it. You are not in the position to make any change or to make any effect on that country: you just live there, but there s no way that you can excercise influence on the people who run this country.

Rapha l: You recently joined the Debian Press Team. What does it involve and how are you managing this new responsibility? Francesca: The Press Team is basically the armed wing of the Publicity Team: it handles announcements that need to be kept private until the release, moderate the debian-announce and debian-news mailing list and maintain contacts with press people from outside the project. The real job, so, is done within the Publicity Team. The most important part of our work is to write announcements and the newsletter: while the newsletter is published bi-weekly, the announcements need to be write in a shorter timeframe. Localization is really important in spreading Debian word, so we work closely with translators: both announcements and DPN are usually translated in four or five different languages. The publicity work could be stressful, as we have strict deadlines, we need to take quick decisions and often do last-minute changes. Personally, I like it: I work better under pressure. But I know that is sometimes difficult for contributors to accept that we can t debate endlessly on details, we have just to go on and do our best in a given timeframe.

The publicity work could be stressful, as we have strict deadlines, [ ]. Personally, I like it.

Raphael: You re one of the main editor behind the Debian Project News. What s the role and scope of this newsletter? Francesca: Debian Project News is our beloved newsletter, direct successor of the Debian Weekly News founded by Joey Hess in 1999 and later kept alive by Martin Schulze. In 2007, Debian Weekly News was discontinued but in 2008 the project was revived by Alexander Reichle Schmehl. The idea behind DPN is to provide our users an overview of what is happening inside and outside the project. As the core team of editors is formed by three people, the main problem is to be able to collect enough news from various sources: in this sense we are always glad when someone points us to interesting blogposts, mails and articles. DPN is also a good chance for non coders to contribute to Debian: propose news, write paragraphs and review the draft before the publication are quite easy tasks but very useful. English native speakers can do a proofread (as no one of the main editors is a native speaker) while others can always translate DPN in their native language. People who want to help us can take a look at our wiki page.

DPN is also a good chance for non coders to contribute to Debian.

Just yesterday I realized that since January we don t miss or delay an issue: so I d like to thank the fantastic team of editors, reviewers and translators who made it possible. The team is now working on another way of spreading Debian s message: a long-time project is finally becoming real. Stay tuned, surprise arriving! Raphael: You re trying to organize IRC training sessions but that doesn t seem to take off in Debian, while it s quite common in the Ubuntu community. How do you explain that? Francesca: I m not sure about it: both Debian users and contributors seemed to appreciate this initiative in the past. I was quite surprised by the amount of Debian members present during the various sessions and by the amount of interesting questions asked by the users. So the only reason I can think about is that I need to put more enthusiasm in convincing the teams to do it: they need more encouragement (or to be pestered more!). I, for myself, think that IRC training sessions are a great way to promote our work, to share our best practice, to talk about our project to a wider audience. And I ll sure try to organize more of them. Help, suggestions, ideas are really welcome! Raphael: If you could spend all your time on Debian, what would you work on? Francesca: There is a project I d like to give more love, but I always end up without the time to do it: the debian-community.org project. Back in 2007, Holger Levsen founded it with the aim of reducing the gap between Debian contributors and Debian users, giving all an opportunity to contribute, share ideas and more. The project was discontinued and I d really like to revive it: in these years various things have changed, but I think that the core idea of having a node to connect existing local communities is still good and doable. In Debian we don t have the wide and well articulated local infrastructure present in other distributions (Ubuntu, particularly, but also Fedora): even if I don t like too centralized structures, I think that a better connection between the project and local groups of users and on-line communities would be a step forward for the project. Being part of the Events Team, I m aware of how much we need to improve our communication with local groups. An example is the events organization: sometimes, Publicity and Events teams even don t know about regional Debian related events (like booth at conferences, workshops, talks, install parties, etc) and this is a shame because we could offer a lot of help in organizing and promoting local events. What we lack is better communication. And debian-community.org project could give us exactly this. Could be a cluster of local groups, a platform for events organization and even a useful resource for newbies who want to find a local group near them. I started some effort in this sense, sending a proposal about it, working on a census of Debian local groups. Any help is appreciated! I m really curious to see how many Debian communities (from all around the world and the web) are out there, and I d love to have members from these communities better connected with the Debian Project. Raphael: What s the biggest problem of Debian? Probably the bikeshedding feticism of almost all of us. It s the other side of the coin of Debian s commitment to technical excellence and our perfectionism, but sometimes it leads just to endless discussions about details, and it is a blocker for various initiatives. In Debian, you have to be really patient and in a way stubborn to push some changes. This is frustrating sometimes. On the other hand, I really appreciate how people take some times to think to each proposals, give some feedback and discuss about it: the process could be annoying, indeed, but the result is often an improvement of the initial proposal. Raphael: Is there someone in Debian that you admire for their contributions? Most of my teammates are simply brilliant and adorable and hard-working. But I have to admit that I particularly admire David Pr vot: beside being a webmaster he does a lot of things, from French translations to DPN editing. All his contributions have a great quality and he s able to push you always further in doing things and doing them better. He is a good example of how I d like to be as contributor: smart, tireless, friendly.

---

Thank you to Francesca for the time spent answering my questions. I hope you enjoyed reading her answers as I did. Note that older interviews are indexed on wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.

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

I look after a lot of systems, and most of them want identical and simple backups taking of their filesystems. Currently I use backup2l which works but suffers from a couple of minor issues. In short I want to take a full filesystem backup (i.e. Backup "/"). I wish to only exclude a few directories and mounted filesystems. So my configuration looks like this:

# List of directories to make backups of.
# All paths MUST be absolute and start with a '/'!
SRCLIST=(  / /boot -xdev )
# The following expression specifies the files not to be archived.
SKIPCOND=( -path '/var/backups/localhost' -o -path '/var/run/' -o \
    -path '/tmp'  -o -path '/var/tmp' \
    -o -path '/dev' -o -path '/spam' \
    -o -path '/var/spool/' )

The only surprising thing here is that I abuse the internals of backup2l because I know that it uses "find" to build up a list of files - so I sneakily add int "-xdev" to the first argument. This means I don't accidentally backup any mounted gluster filesystem, mounted MySQL binary/log mounts, etc. backup2l then goes and does its jobs. It allows me to define things to run before and after the backup runs via code like this:

# This user-defined bash function is executed before a backup is made
PRE_BACKUP ()
 
   if [ -d /etc/backup2l/pre.d/ ]; then
      run-parts /etc/backup2l/pre.d/
   fi
 

So what is my gripe? Well I get a daily email, per-system, which shows lots of detail - but the key thing. The important thing. The thing I care about more than anything else, the actual "success" or "fail" result is only discoverable by reading the mail. If the backup fails, due to out of disk, I won't know unless I read the middle of the mail. If the pre/post-steps fail I won't know unless I examine the output. As I said to a colleague today in my view the success or failure of the backup is the combination of each of three distinct steps:

• pre-backup jobs.
• backup itself
• post-backup jobs.

If any of the three fail I want to know. If they succeed then ideally I don't want a mail at all - but if I get one it should have:

Subject: Backup Success - $(hostname) - $(date)

So I've looked around at programs such as backup-ninja, backup-manager and they seem similar. It is a shame as I mostly like backup2l, but in short I want to do the same thing on about 50-250 hosts:

• Dump mysql, optionally.
• Dump postgresql, optionally.
• Dump the filesystem. Incrementals are great, but full copies are probably tolerable.
• Rsync those local filesystem backups to a remote location.

In my case it is usually the rsync-step that fails. Which is horrific if you don't notice (quota exceeded. connection reset by peer. etc). The local backups are good enough for 95% of recovery times - but if the hardware is fried having the backups be available, albeit slowly, is required. Using GNU Tar incrementally is trivial. If it weren't such a messy program I'd probably be inclined to hack on backup2l - but in 2012 I can't believe I need to. (Yes, backuppc rocks. So does duplicity. So does amanda. But they're not appropriate here. Sadly.) ObQuote: "Oh, I get it. I see now. You've been training for two years to take me out, and now here I am. Whew! " - Blade II - An example of a rare breed, a sequel that doesn't suck. No pun intended.

Hello Last week-end, I ve participated Perl/QA hackathon in Paris. Here s a short summary of the main activities during this week-end. I was not in the best of shape due to a nasty (biological) bug that wore me down before the hackathon. First of all, I discussed with rjbs about the bunch of debian patches I ve written for Software::License. These patches (and hacks) are used in Debian to provide licenses summaries in Debian::Dpkg::Copyright model to help write Debian copyright files. License management is boring but necessary. cme and Software::License help in making this task slightly less boring. Ricardo kindly suggested some modifications and agreed to include my patches. I implemented these modifications directly during the hackathon. The other tasks during this week-end were (not necessarily in that order):

• I discussed with alanhaggai and gave him some ideas to fix his Archive::Zip module
• I did a live demo of Debian packaging to ribasushi: I updated the Debian package libdbix-class-schema-loader-perl from CPAN and uploaded it in Debian.
• I presented how to package Perl modules for Debian. renormalist will package his own module Data::Dpath and its dependencies for Debian. I will sponsor his packages once they are available on Debian perl s team git repository. Unless gregoa beats me to it
• I discussed with Slaven Rezic some binding weirdness found in Perl/Tk HList. Config::Model s graphical interface provide a viewer widget and and editor widget for configuration items. As expected, the viewer is invoked by a single left click. One would expect a double click to invoke the editor widget. But the double click bindinngdoes not owrk in HList when the single click is used. Currently the editor widget is invoked with a right-click, which is not user-friendly. According to Slaven, the bug might be hidden quite deep in Perl/Tk guts. Fixing it won t be easy.
• As a Debian/sid user, I ve been quite spoiled: I ve always had a recent Perl available on my system. I ve neved had to compile Perl since my HPUX days back in last century. However, Config;:Model tests failed with Perl 5.15.9, a development version not available in Debian (sid is not that unstable). Thanks to Xavier Caron, I ve learned about perlbrew and cpanminus to reproduce this bug and fix the issue. Many apologies to miyagawa for asking dumb questions about cpanm: the disctinction between runtime and build time does not apply to cpan minus. I guess that s the drawback of wearing 2 hats (Debian dev hat and Perl dev hat): your brain may get confused and you conflate issues. Oops.

Many thanks to FreeSide who sponsored my travel, to the hackathons organisers and to all the participants for their welcome. All the best