These days I briefly discussed with a fellow Debian developer about how to maintain upstream patches in Debian packages with Git, what brought me to rethink a little about my current practices. What I usually do is pretty much like point 4 in Raphael's post "4 tips to maintain a 3.0 (quilt) Debian source package in a VCS": I make commits in the Debian packaging branch, or in a separate branch that is merged into the Debian packaging branch. Then I add the single-debian-patch option to debian/source/options so that a single Debian patch is generated, and include a patch header that points people interested in the individual changes to the public Git repository where they were originally done. My reasoning for doing so was the following: most upstream developers will hardly care enough to come check the patches applied against their source in Debian, so it's not so important to have a clean source package with separated and explained patches. But then there is the people who will actually care about the patches: other distribution developers. Not imposing a specific VCS on them to review the patches applied in Debian is a nice thing to do. Then I wrote a script called git-export-debian-patches (download, manpage), which was partly inspired by David Bremner's script. It exports all commits in the Debian packaging branch that do not touch files under debian/ and were not applied upstream to debian/patches. The script also creates an appropriate debian/patches/series files. The script is even smart enough to detect patches that were later reverted in the Debian branch and exclude them (and the commit that reverted them) from the patch list. The advantage I see over gbp-pq is that I don't need to rebase (and thus lose history) to have a clean set of patches. The advantage over the gitpkg quilt-patches-deb-export-hook hook is that I don't need to explicitly say which ranges I want: every change that is merged in master, was not applied upstream and was not reverted gets listed as a patch. To be honest I don't have any experience with either gbp-pq or gitpkg and these advantages were based on what I read, so please leave a (nice ;-)) comment if I said something stupid. I am looking forward to receive feedback about the tool, specially about potential corner cases in which it would break. For now I have tested it in a package with simple changes agains upstream source, and it seems fine.

OK, this one is meant for Planet Debian...

One of many, many changes in the latest lintian is vendor profiles and, thanks to a heads-up by Niels Thykier, Emdebian will have working profile support in the next upload of emdebian-grip. (The only reason it's not already in Debian is my own fault for not uploading when I thought I had the time to upload.)

$ lintian --profile emdebian-grip drivel_3.0.2-1em1_amd64.deb 

$ lintian --profile debian drivel_3.0.2-1em1_amd64.deb 

E: drivel: debian-changelog-file-missing

E: drivel: copyright-file-compressed

W: drivel: copyright-without-copyright-notice

E: drivel: description-contains-invalid-control-statement

W: drivel: binary-without-manpage usr/bin/drivel

So the em1 version implements Emdebian Policy for Emdebian Grip. Clean for Emdebian Grip, just as the Debian package is clean prior to the changes.

I expect this to dramatically improve the processing of Emdebian packages, both for Grip and for the cross-built flavour, Crush, once that actually starts up.

Thanks to the lintian team for this support. Now if there was some way of backporting this version of lintian to Squeeze, I could also use this at work to suppress really annoying lintian warnings about non-standard suite names. (The whole point of using a non-standard suite name is to keep our stuff separate from the normal Debian/Emdebian stuff for licensing reasons etc.) Update: of course, I didn't check the PTS for lintian before writing that, so hence didn't notice that the backport already exists! Thanks again to Niels for the prompt. I've now got another package to create for work. Update2: Thanks to Joerg Jaspert for the tip that all lintian versions get backported directly from unstable as an exception on ~bpo. The work package is ready, so this is going to make things a lot easier when building stuff on stable.

In other news, the same version of emdebian-grip will include support for integrating Emdebian Grip into Debian itself. This too will use vendor-specific support, this time an internal vendor name which just needs to work on the "buildd".

(It's not quite a buildd, Emdebian Grip doesn't build anything, it's all post-processing. It's just that the processing of Debian packages for Emdebian Grip will look a bit like having a second buildd working on the packages uploaded by the existing buildd. The process itself is still developing...)

Multistrap runtime message translations need updating but the manpages aren't being done this time around. More changes are likely before those get done.Current runtime translation status:

language        translated     fuzzy     untranslated

-----------------------------------------------------

  da               103           4             4

  fr                54          17            40

  pt                54          17            40

  vi                54          17            40

http://lists.debian.org/debian-i18n/2011/08/msg00105.html
Check with the relevant debian-i18n team for your language, this is just a prompter in case people miss the mailing list post.Update: Hmm, that went to the wrong blog. It got tagged i18n but was meant for the i18n blog. Ah well, doesn't hurt for Planet Debian to see what is going on elsewhere....

For a number of years, I've been making myself metapackages that pull favorite packages and pre-configure the desktop environment to use my favorite global default settings. This currently means configuring the gconf keys for the GTK theme, icon theme and background image for GDM. Until now, I implemented this by calling gconftool-2 directly in postinst as user gdm but Lintian recently started warning me that the correct way to do this would be by calling gconf-schemas or update-gconf-defaults instead. I was thus wondering, would anyone have any sample code that accomplishes this? To further complicate things, GNOME 3 has transitioned from gconf to dconf, which suggests that a slightly different method needs to be used to perform the same. Would anyone have any sample code to implement this? Thanks in advance to anyone who can help me with this!

The Border Gateway Protocol is what network operators use to exchange the various routes forming the Internet. It's a pretty critical piece of infrastructure. Most providers are probably using proprietary solutions using dedicated hardware, but free software on comodity hardware can also be an option for some networks. In Debian, we already have Quagga and Bird that both implement BGP on top of Linux for quite a while. Back in time, FOSDEM feb. 2006, Ging is being demonstrated. Immediately my mind races with something like: waow, we could port OpenBGPD on that! OpenBGPD is another BGP routing daemon. This new effort was started in 2003 by Henning Brauer for OpenBSD. To sum up its goal, it was meant to be secure, reliable, lean, easy to configure, fast and memory efficient. This is quite the opposite of Quagga codebase, which is inherited from an older project, Zebra which was mostly documented in Japanese. Another issue I have seen hapenning with Quagga on Linux is that its blocking implementation and the time that the kernel needs to insert/remove routes made the daemon unresponsive enough to created cascading failures. The IPv4 Internet is nowdays made of more than 350 000 prefixes, so when a network peer fails, the router needs to process those changes while continuing to answer other peers. Otherwise, they will kill the session meaning yet another 350 000 prefixes to process on both sides. And again when the session is restored. Leading to more downtime, flaps, and failures. OpenBGPD was ported to FreeBSD. The port is maintained by Hiroki Sato. Starting with this port and using libbsd made the creation of a package for Debian GNU/kFreeBSD pretty doable while at DebCamp11. It probably still has some pretty rough edges and the manpage needs to be reviewed (and some unsupported features trimmed, maybe), but the package should be usable. So OpenBGPD is now in Debian, and it could be one of the killer features of a port that some describe as a toy OS. Unfortunately I did not yet have access to proper network equipment to test the package on real production scenario (with 2 or 3 full BGP views). If you have a lab (or feel adventurous) and have access to such gears, please have a try!

Getting older^W wiser, and definitely fatter than yesterday [ Photo of the cake is missing, have I already told you I became fatter? ]

Via #241343:

* Package name    : apt-gentoo
  Version         : 0.0.1
* URL             : http://www-jcsu.jesus.cam.ac.uk/~mma29/apt-gentoo/
* License         : GPL version 2 or above
  Description     : enhanced package installation
 apt-gentoo enhances the Debian package installation experience to make
 it fully competitive with newly-popular source-based distributions.
 As packages are installed, apt-gentoo automatically downloads their
 build logs from the buildd network. The logs are then slowly scrolled
 past on the user's terminal to simulate building the software on the
 local machine.
 [..]

So, something like: Package/source and example installation transcript.

This is my first week back after two weeks off (I aim for three complete weeks off a year). Even if I had reached InboxZero (and ToDoZero and so on ), there was two weeks of requests, reports and rubbish piled on top of what was already scheduled. I wasn t even completely offline this time and was forwarding urgent incoming messages to other members of our co-op, but the backlog is still significant. How you deal with this? Basically, I arrive back and I feel like I m already behind. The good feeling of being up-to-date seems like a distant memory. The clear day I allocated to dealt with things that arrived seemed inadequate. Was that just bad luck because a lot of stuff came in, or is there a rule-of-thumb for how much catch-up time to allocate? 3 Lessons Learned From 6 Days Off The Grid Social Butterfly Guy offers a view on how to prioritise things, but it still looks like catch-up takes hours. Can you see any ways to make it more efficient but still please clients, collaborators and co-op members?

Welcome Planet Debian viewers If things are working right, Planet Debian will now be getting my blog posts tagged Debian. The main reason I had not done this before is not much on my blog relates to Debian, and it tends to be much less technical than most of the blogs there. Viewers from there might want to check out my recent post on debconf11 and may check out the rest of my blog archives, where I'm trying to get rid of my house and move in to a motorhome.

About 24 hours ago I rebooted the system that runs the secondary DNS for my zone and a few other zones. I d upgraded a few things and the system had been running for almost 200 days without a reboot so it was time for it. Unfortunately it didn t come back up. Even more unfortunately the other DNS server for my zone is ns.sws.net.au which is also the only other server for the sws.net.au zone. Normally this will work because the servers for the net.au zone have a glue record containing the server IP address. So when asked for the NS records for the sws.net.au domain the reply will include the IP address of ns.sws.net.au. The unfortunate part was that the IP address was the old IP address from before the sws.net.au servers changed to a new IP address range, I wonder whether this was due to the recovery process after the Distribute IT hack [1], as forgetting to change a glue record is not something that I or the other guy who runs that network would forget. But it is possible that we both stuffed up. The DNS secondary was an IBM P3-1GHz desktop system with two IDE disks in a RAID-1 array. It s been quite reliable, it s been running in the same hardware configuration for about four years now with only one disk replacement. It turned out that the cooling fan in the front of the case had seized up due to a lot of dirt and the BIOS wouldn t let the system boot in that state. Also one of the disks was reporting serious SMART problems and needed to be replaced poor cooling tends to cause disk errors. It seems that Compaq systems are good at informing the user of SMART problems, two different Compaq desktop systems (one from before the HP buyout and one from after) made very forceful recommendations that I replace the disk, it s a pity that the BIOS doesn t allow a normal boot process after the warning as following the recommendation to backup the data is difficult when the system won t boot. I have a temporary server running now, but my plan is to install a P3-866 system and use a 5400rpm disk to replace the 7200rpm that s currently in the second position in the RAID array. I ve done some tests on power use and an old P3 system uses a lot less than most new systems [2]. Power use directly maps to heat dissipation and a full size desktop system with big fans that dissipates less than 50W is more likely to survive a poorly cooled room in summer. Laptops dissipate less heat but as their vents are smaller (thus less effective at the best of times and more likely to get blocked) this doesn t provide a great benefit. Also my past experience of laptops as servers is that they don t want to boot up when the lid is closed and getting RAID-1 and multiple ethernet ports on a laptop is difficult. Finally I am going to create a third DNS server for the sws.net.au domain. While it is more pain to run extra servers, for some zones it s just worth it.

• [1] http://www.zdnet.com.au/distributeit-data-unrecoverable-post-hack-339317149.htm
• [2] http://doc.coker.com.au/environment/computer-power-use/

As our GSoC students are approaching quite well, we've already numerous features included in current master, which are worth mentioning. You can try all bellow mentioned features on our demo server. Grid editing provides really simple way of editing data, by simply clicking on it while browsing table. Just try it on some table. Performance suggestions are part of completely reworked server status and can give you valuable information how to tune your server. You can see it on demo server. Another nice addition to server status page is live monitor, which charts basic server information in real time. Again, try it on demo server (you need to press start for now, this will probably go away soon). Other big, thought not that fancy change is complete support for routines. This includes stored procedures/functions, triggers and events. For example see routines in sakilla database. Of course there is much more to mention, like improving of AJAX in lot of places, GIS support. On the other side, we've also recently decided to remove support for Microsoft Excel import and export as used PHPExcel library seems to suffer some licensing issues, which prevented phpMyAdmin from being included in Fedora. You can still use CSV or OpenDocument formats though.

Filed under: English Phpmyadmin 0 comments Flattr this!

DebConf11 ended nearly two weeks ago After all the discussions that happened there, I really feel that some of those topics could benefit from more coverage. Planet Debian looks like a good candidate, so we'll see how it goes. To sum it up: Hi there!

DebConf11 ended nearly two weeks ago After all the discussions that happened there, I really feel that some of those topics could benefit from more coverage. Planet Debian looks like a good candidate, so we'll see how it goes. To sum it up: Hi there!

Common licenses for software include the term worldwide . Now, what does worldwide mean? The problem with the term worldwide is that it is ambigous and depending on it s interpretation, violates against DFSG 6 which states: No Discrimination Against Fields of Endeavor . The reason: Space travel. If we take the term worldwide to mean everywhere on earth , the license becomes non-free, as it prohibits the use outside of this planet. Affected by this problem are the patent section of GPL-3, the Apache 2.0 license, the CC licenses, the GFDL, and probably also others. Now what should be used instead? Universal? No, that wouldn t work in case there are multiple ones (while travelling between them (if they exist) could be impossible, it would still be a restriction). The correct team would probably be omniversal meaning everywhere in the omniverse . But really, avoiding locations is probably the best way. In any case, if you have received software from me under a license that uses the term worldwide , you can treat worldwide as everywhere, and are thus free to use it outside of earth (and other planets).
Filed under: General

Using a very customizable email user agent (namely, Mutt), I am able to use several signatures depending on almost whatever criterion I want. So I spent some time drawing several thematic ones in ASCII Art, sometimes taking inspiration on existing models, sometimes entirely by myself (in bold). Hoping that it may be useful, here are some of them:

Bee (a logo of my engineering school, Centrale Paris)	___ (___\ ,- <(((((>0 Tanguy Ortolo (___/ -
Fishes (for April 1st)	(\_ _/) )\/__( > Tanguy < )__\/( )/ '
Angel (for Christmas)	(\ _ ( \o /\/ Tanguy _)>
Cyclist	__o _<_\,_ Tanguy (_) '(_)
Fencer	< o /--)---- Tanguy / >
Cypherpunk	____ Tanguy Ortolo /_ \______________ ((_) _ .--^---^^-^-' \____/ ' urn:pgp:240BBA15B694DD00E38030D8D6EFA6AC4B10D847:
Hacker	. o . . . o Tanguy Ortolo o o o
Debianist	,--. : / ) Tanguy Ortolo -' Debian Maintainer \_

If you like them, do not hesitate to copy them. I am not sure whether or not this can seriously be an object of copyright, so in case it would be necessary: I put them, at least those that are of my own (those labelled in bold), under CC0 (unfortunately my country law do not allow me to put my works under public domain): Copying is an act of love. Please copy.

---

PS: Sorry, but my blog does not allow comments with fixed-width fonts

git add -p is one of my favourite git features. It lets you selectively add the local changes hunk by hunk to the staging area. This is especially nice if you want to commit one change in a file, but not a second one, you also already did. Recently I noticed that you can also selectively revert changes already in the staging area using git reset -p HEAD. The user interface is exactly the same as for git add -p. Today I discovered another selective undo in git by just trying it out of curiosity if that works, too: Undoing local changes selectively using git checkout -p. Maybe less useful than those mentioned above, but nevertheless most times quicker than firing up your favourite editor and undoing the changes manually. Another nice git feature which I discovered by accidentially using it (this time even unwittingly) is git checkout - which behaves like cd -, just for branches instead of directories, i.e. it switches back to the previously checked out branch. Very useful for quickly changing between two branches again and again.

The SPI election results have been declared. Jimmy Kaplowitz, Clint Adams and Robert Brockway were elected to the SPI board. There were 75 voters, which is 16% turnout, up from the 13% in the last contested election, in 2009. The next meeting is this evening at 20:30 UTC (21:30 UK) in #spi on irc.spi-inc.org and there are a couple of resolutions, inviting the Drizzle database and Arch Linux distribution projects to associate, so that SPI can collect and process funds for them. Please, pop in and see how the new board members perform.

During Debconf 11, I got access to a fast s390 machine, and I have started to work on a Debian s390x port, the 64-bit version of the s390 port. One of my goal was to help the SPARC64 port, as some of the issues are the same: both are 64-bit big-endian, don t support unaligned access and behave differently between -fpic and -fPIC. Why such a port? When talking about 64-bit ports, we usually hear: 4GB is enough, handling 64-bit takes more memory . This really sounds like 640K ought to be enough for anybody . The s390 port is actually 31-bit from the address point of view (one bit is reserved for address space extension from 24 to 31 bits), so each process is limited to 2GB only. Nowadays applications which need more than 2GB are not that uncommon, especially on mainframes. Actually the 2GB limit already causes some problem in Debian: in some cases it s not possible to build haskell applications or even C applications using GCC. On the other hand, we already require a 64-bit kernel on the s390 port (only the userland is 32-bit), and applications are handling more and more 64-bit or greater values (files offset, time counters, uid, etc.). What is the status? Bootstrapping the architecture was not really easy (as for any other new architectures), due to a huge amount of dependencies and build-dependencies loops, as explained by Wookey during Debconf11. Now that this part is mostly done, an autobuilder has been started and currently more than 65% of the packages are built. The s390x port is hosted on debian-ports.org. Unfortunately it is not yet deboostrapable, though that should happen in the next few days (only a few packages are missing). The main issues are currently packages which fail to build from source due to linker, gcc-4.6 and curl changes, or due to the libjpeg and multiarch transitions, and thus are not directly related to s390x. If your package is in this case, it would be a good idea to fix it. Otherwise if it has a lot of reverse dependencies and the bug is opened for a while, just expect an NMU (as allowed by the 0-day NMU policy). Of course for a few packages s390x specific fixes are needed, some of them are already in the BTS. How you can help? The list of bugs blocking the s390x port is available through the s390x usertag, fixing these bugs (a lot of them are general FTBFS) would help a lot. Alternatively if you have access to an s390x machine you can take a look at the packages failing to build. Update: Fixed the explanation about the 32th bit, thanks to Bastian Blank for the comment.

Thanks to the tremendous growth of social applications over the past five years, we have our pick of services for collecting, saving and sharing our experiences online. We each have collections of photos, contacts, messages and more, spread across multiple popular services like Twitter, Facebook, LinkedIn, as well as many less popular services which address particular needs or preferences. We re also producing a wealth of exhaust data through our browsing history, mobile sensors, transactions and other activity streams that we rarely if ever examine directly. This ecosystem is becoming so complex that it s easy to lose track of what you ve created, shared or seen. We need new tools to manage this complexity, to make the most of the wealth of information and connections available to us through various services. John Battelle calls these metaservices , and points to growth in the number of connections between the services we use. I expect that this next age of information tools will center around data rather than services. Data is a common denominator for these online experiences, a bridge across disparate services, technologies, social graphs, and life cycles. Personal data, in particular, has this property: the only thing that links together your photos on Flickr, Facebook, Picasa and Twitpic is you. So where s your data center ? I don t anticipate the emergence of a single service where you do everything. There will continue to be innovation in the form of new and specialized services which meet a particular need very well. There won t be a single service which is everything to everybody. Instead, I foresee us wanting to track, save, use and control all of our stuff across the web. That s why my new colleagues and I are working to make that possible. There s open source code available on github, a vibrant IRC channel (#lockerproject on Freeenode), and lots more I d like to write about it. But it s time to get back to work for now

The trek from Andromeda is getting shorter every time. Hopefully the galaxies won't collide. I've just released version 0.20 of Obnam (although the armel binary is still building). The important bits: BUG FIXES:

• Non-ASCII filenames over SFTP root now work. (Thanks, Tapani Tarvainen, for the reproducible bug report.)
• The count of files while making a backup now counts all files found, not just those backed up. The old behavior was confusing people.

USER VISIBLE CHANGES:

• The output of obnam ls now formats the columns a little prettier, so that wide values do not cause misalignment.
• The error message when trying to use an encrypted repository without encryption is now better (and suggests missing encryption being the reason). Thanks, chrysn.
• Obnam now supports backing up of Unix sockets.