This weekend I'm mostly alternating between reading, writing, and trying to avoid death by the plague.[*] I've switched Lumail to using a UTF-8 aware string library, which means we can now handle the obvious case:

--
-- Prove keybindings work.
--
keymap['global'][' '] = 'msg("UTF-8 rocks!")'

Similarly we can stuff input into the buffer:

--
-- Pretend the user typed ":msg ...\n"
--
stuff( ":msg('  is pie')\n" );

This transition was annoying to handle, but wasn't too difficult. There is only one more major update required, according to the development roadmap, which is to double check that UTF-8 output is correct. Otherwise I think I'm almost done. In the sense that I don't see anything obvious missing, barring things that won't ever happen such as mutt-style "tag" support. I've updated the online examples to include some nice code:

• A nice menu for viewing/opening attachments: view_attachments().
• A nice system for marking messages as read based upon their subjects: mark_read_by_pattern().

I can't claim to have many users, so far the development has been carried out by myself and approximately four other people. But that matters not. I genuinely believe this is a good client and it really suits the way that I handle (large volumes of) email:

• Show folders with unread mail.
• Quickly read it.

Allowing you to open multiple folders at once means you get a great view into your currently-unread mail, regardless of where procmail has placed it. The overriding feeling having "completed" the client is that Lua rocks. I'm torn between wanting to sleep some more, and wondering what other system/package/tool can be extended by Lua. As epiphanies go my on_idle() update takes some beating.

* - I do not have the black death, but I'm not well.

WebAuth is the site-wide centralized web authentication system that we use at Stanford. This release is a bug-fix release for the central login server, mostly focused on multifactor authentication but also featuring a wide variety of random bug fixes. Going into this release, I filtered the Apache error logs on all of our production servers for a period of a month and then set out to fix every log anomaly or odd behavior pattern that I detected. The most significant bug fix is to support for requiring non-password session factors. The code handled this entirely incorrectly, resulting in the user being stuck at the password authentication prompt and never able to proceed. It also cleans up several corner cases involving REMOTE_USER authentication to sites that require a Kerberos authenticator (such as for delegated credentials). This release downgrades a mismatch of login credentials and a webkdc-proxy token (single sign-on credentials) to a log warning rather than a fatal error and just discards the non-matching single sign-on credentials. This case ideally shouldn't happen, but sometimes users share devices, and if they hit a site with forced login or session factors, it's easy for this case to arise. WebLogin now retries the WebKDC POST once and ignores SIGPIPE errors to work around problems with signals from the FastCGI process manager. It also rewrites non-ASCII characters in XML from the WebKDC to work around XML validation errors created by non-ASCII characters in Kerberos error messages, pending a better fix on the WebKDC side. Password changes no longer go through the replay detection logic, which should not apply to them. Several error messages in WebLogin are now clearer. The WebKDC now requires that the return URL in a WebAuth request be an absolute URL and not contain any non-ASCII characters. A bug in the way that errors during the authentication process were reported has been fixed and should produce better error output for the user. There are also a few other, more minor bug fixes, particularly to logging and error reporting. You can get the latest release from the official WebAuth distribution site or from my WebAuth distribution pages.

I have a recurring problem when trying to use augeas on a complex node: trying to edit a specific entry in a list which is uniquely defined by many attributes. You probably don't know that you have this problem, but it is easy to spot it into your augeas/puppet resource. Here are some symptoms of this problem:

• you need to use onlyif with multiple constraint on the selection
• you use last() and last() +1

 
 augeas  
   "setup-shorewall":
     changes =>
       [
         "set entry[last() + 1]/source 'all'",
         "set entry[last()]/dest 'all'",
         "set entry[last()]/policy 'REJECT'",
         "set entry[last()]/log_level 'info'",
       ],
     onlyif => "match entry[source = 'all'][dest = 'all'][policy = 'REJECT'] size == 0";

For a long time, I thought it was the only solution. But last week, I read again the documentation and found another solution. My main concerns are the onlyif and last() parts, it doesn't look clean to me. The problem is that I cannot define the entry all at once and if I use a value that will be set late, the node cannot be targeted in between. The clean way to do this was to define first the target attribute. Typically, in augeas changes:

 set spec[user = '$name']/user '$name'

This way if the node doesn't exist it is created and you can then use it directly:

 set spec[user = '$name']/host_group/host 'ALL'
 set spec[user = '$name']/host_group/command1 'ALL'
 set spec[user = '$name']/host_group/command1/tag 'PASSWD'

But sometimes it is not possible to set the attribute directly -- typically when you need to use multiple attribute. The solution in this case is to use defnode:

 defnode target entry[#comment = 'puppet: <%= name %>']/ "<%= name %>"
 set $target/action '<%= action %>'
 set $target/source '<%= source %>'
 set $target/#comment 'puppet: <%= name %>'
 clear $target

The big trick here is that defnode needs a value, but most of the time you cannot set a value for the node -- because it has none. To solve this, you set a value with defnode, process with your change and you clear the node at the end. This recent discovery has simplify a lot some augeas changes I use. Feel free to leave comment on your personal technique to deal with augeas and puppet.

Finally, more bootlog-pr0n:

start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] exec init proc auth
INIT: version 2.88 booting
Using makefile-style concurrent boot in runlevel S.
Activating swap...done.
Checking root file system...fsck from util-linux 2.20.1
hd2 : tray open or drive not ready
hd2 : tray open or drive not ready
hd2 : tray open or drive not ready
hd2 : tray open or drive not ready
end_request: I/O error, dev 02:00, sector 0
/dev/hd0s1: clean, 44680/181056 files, 292234/723200 blocks
done.
Activating lvm and md swap...(default pager): Already paging to partition hd0s5!
done.
Checking file systems...fsck from util-linux 2.20.1
hd2 : tray open or drive not ready
hd2 : tray open or drive not ready
end_request: I/O error, dev 02:00, sector 0
done.
Cleaning up temporary files... /tmp.
Mounting local filesystems...done.
Activating swapfile swap...(default pager): Already paging to partition hd0s5!
done.
df: Warning: cannot read table of mounted file systems: No such file or directory
Cleaning up temporary files....
Configuring network interfaces...inetutils-ifconfig: invalid arguments
ifup: failed to open pid file /run/network/ifup-/dev/eth0.pid: No such file or directory
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
can't create /var/lib/dhcp/dhclient./dev/eth0.leases: No such file or directory
Listening on Socket//dev/eth0
Sending on   Socket//dev/eth0
DHCPDISCOVER on /dev/eth0 to 255.255.255.255 port 67 interval 8
DHCPREQUEST on /dev/eth0 to 255.255.255.255 port 67
DHCPOFFER from 10.0.2.2
DHCPACK from 10.0.2.2
can't create /var/lib/dhcp/dhclient./dev/eth0.leases: No such file or directory
bound to 10.0.2.15 -- renewal in 34744 seconds.
done.
Cleaning up temporary files....
Setting up X socket directories... /tmp/.X11-unix /tmp/.ICE-unix.
INIT: Entering runlevel: 2
Using makefile-style concurrent boot in runlevel 2.
Starting enhanced syslogd: rsyslogd.
Starting deferred execution scheduler: atd.
Starting periodic command scheduler: cron.
Starting system message bus: dbusFailed to set socket option"/var/run/dbus/system_bus_socket": Protocol not available.
Starting OpenBSD Secure Shell server: sshd.
unexpected ACK from keyboard
GNU 0.3 (debian) (console)
login: root
root@debian:~# shutdown -h now
Broadcast message from root@debian (console) (Fri Aug 16 20:02:47 2013):
The system is going down for system halt NOW!
INIT: Switching to runlevel: 0root@debian:~#
INIT: Sending processes the TERM signal
INIT: Sending processes the KILL signal
Using makefile-style concurrent boot in runlevel 0.
Stopping deferred execution scheduler: atd.
task c10f72a8 deallocating an invalid port 2098928, most probably a bug.
Asking all remaining processes to terminate...done.
All processes ended within 1 seconds...done.
Stopping enhanced syslogd: rsyslogd.
Deconfiguring network interfaces...ifdown: failed to open pid file /run/network/ifdown-/dev/eth0.pid: No such file or directory
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
can't create /var/lib/dhcp/dhclient./dev/eth0.leases: No such file or directory
Listening on Socket//dev/eth0
Sending on   Socket//dev/eth0
/bin/sh: 1: ifconfig: not found
done.
Deactivating swap...swapoff: /dev/hd0s5: 177152k swap space
done.
Unmounting weak filesystems...umount: /etc/mtab: Warning: duplicate entry for device /dev/hd0s1 (/dev/cons)
umount: could not find entry for: /dev/cons
done.
Unmounting local filesystems...done.
mount: cannot remount /: Device or resource busy
Will now halt.
init: notifying pfinet of shutdown...init: notifying tmpfs swap of shutdown...init: notifying tmpfs swap of shutdown...init: notifying tmpfs swap of shutdown...init: notifying ext2fs device:hd0s1 of shutdown...init: halting Mach (flags 0x8)...
In tight loop: hit ctl-alt-del to reboot

(You might note that df complains about not being able to read the mtab file. That is because it has been built with _PATH_MOUNTED being /var/run/mtab. This will correct itself when the coreutils package is being rebuilt against a patched libc.) I spent my last two weeks with polishing my patch series, that meant a lot of package rebuilds and that means a lot of waiting (even more so on the Hurd, short version: fakeroot-hurd could be fast but is not yet working properly, fakeroot-tcp is slow) and thus some frustration ;) Also I had to pay special attention so that the upgraded packages could be installed without accidentally breaking anything in the process. Making sysvinit pid 1 is surprisingly tricky in this regard since it breaks the ABI and requires a libc fix that also worked with the current Hurd servers. Here are the patches:

• The mtab translator (v4) provides /proc/mounts: http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00259.html
• When I wrote umount I thought I implemented all the flags used by the initscripts package. Turns out I forgot -d. umount.patch (v2): http://lists.gnu.org/archive/html/bug-hurd/2013-08/msg00018.html
• Make sysvinit pid 1 (sysvinit kinda requires that), fix killall5 (that was freezing the system before) (v2): http://lists.gnu.org/archive/html/bug-hurd/2013-08/msg00020.html
• Making sysvinit pid 1 breaks the ABI, since the glibc assumes /hurd/init to have pid 1: http://lists.gnu.org/archive/html/bug-hurd/2013-08/msg00046.html http://sourceware.org/ml/libc-alpha/2013-08/msg00205.html
• So now killall5 is not freezing the system anymore (actually it froze all processes but most importantly the procfs translator providing /proc and it then tried to walk over /proc which obviously blocked killall5 itself). Cool. But then it looks into /proc/*/stat for the fields start_code and end_code. So I dug into the exec server where the ELF decoding happens and handed this to the proc server, but the procfs translator has to make use of this: http://lists.gnu.org/archive/html/bug-hurd/2013-08/msg00017.html
• Patch series for the sysvinit package (v2). This contains a runsystem.sysv that can be enabled using update-alternatives --config runsystem and several small fixes: http://lists.gnu.org/archive/html/bug-hurd/2013-08/msg00038.html

So I had some spare time on my hand while waiting for numerous package rebuilds and I took this as an opportunity to read papers about Mach and to familiarize myself with mig, the Mach Interface Generator. While I have used it in the past, I had not yet looked at its implementation. And I had to patch the exec server, and there was both code implementing a questionable feature (on-demand unzipping of binaries) and code that was not even compiled (courtesy of the preprocessor) and had probably bit-rot by now. So I figured I could spend my time doing some cleanups:

• Cleanups for the exec server: http://lists.gnu.org/archive/html/bug-hurd/2013-08/msg00049.html
• Cleanups for mig: http://lists.gnu.org/archive/html/bug-hurd/2013-08/msg00055.html

I have rebuild all the necessary packages and uploaded them into an apt repository:

deb http://teythoon.cryptobitch.de/gsoc/heap/debian unstable main

Please use unstable for now. Also make sure that you have a recovery plan for your Debian/Hurd installation if anything goes wrong. For your convenience there's a seed tarball containing packages with the appropriate sources.list.d snippets and the repository key: https://teythoon.cryptobitch.de/gsoc/heap/debian/seed.tar If you want to switch to the new runsystem.sysv, do:

# update-alternatives --config runsystem

Whenever you switch runsystems, please use reboot-hurd to reboot the system. This is the most robust way. Known issues:

• procfs hardcodes the default kernel pid to 2. This breaks /proc/uptime and any program relying on it, most notably top and friends. Until this is properly fixed, you can do:

  # settrans -apfg /proc /hurd/procfs -c -k 3
  

• The mtab translator should probably try to filter out non-filesystem translators. df complains loudly about /dev/cons for example.

Next week I will address the network related issues. By now they are the source of most of the error messages in the bootlog.

This upload was the first one of my very first package in Debian. It was sponsored by Dafydd Harries, who I ve finally met at DebConf13, and got out of NEW on 2005-08-16. Exactly 8 years ago today. I only realized that yesterday evening, and Debian s birthday feels even more special to me now. Dafydd, it looks like I owe you a lot! :)

This DebConf is obviously quite special for me, being the DPL. It has really been great so far to talk to meet so many people, and especially to meet so many new Debian contributors or Developers. I m really happy to see that the next generation is ready! :) On Sunday, I delivered my Bits from the DPL talk. The video is available, and I ve finally uploaded the slides (working link here, it seems that Penta ate my slides). I hope you enjoyed it/will enjoy it!

Chromium is the free software build of the Google Chrome web browser. It s essentially the same as the Google code but will often be an older version, particularly when you get Chromium from Debian/Stable (or any other Linux distribution that doesn t track the latest versions all the time) and compare it to getting Chrome straight from Google. My wife is using Chromium on an AMD Opteron 1212 for all the usual web browsing tasks. Recently I ve noticed that it takes a lot of CPU time whenever she leaves a Google web site open, that can be Google+, Gmail, or Youtube. Web standards are complex and it s difficult to do everything the way that one might desire. Making a web browser that doesn t take 100% CPU time when the user is away from their desk may be a difficult technical challenge. Designing a web site that doesn t trigger such unwanted behavior in common web browsers might also be a challenge. But when one company produces both a web browser and some web sites that get a lot of traffic it s rather disappointing that they don t get this right. It could be that Google have fixed this in a more recent version of the Chrome source tree, and it could be that they fixed the browser code before rolling out a new version of Google+ etc which causes problems with the old version (which might explain why I ve never seen this problem). But even if that is the case it s still disappointing that they aren t supporting older versions. There is a real need for computers that don t need to be updated all the time, running a 3 month old Linux distribution such as Debian/Wheezy shouldn t be a problem. There s also a possibility that part of the cause of the problem is that an Opteron 1212 is a relatively slow CPU by today s standards and it s the slowest system I m currently supporting for serious desktop use. I don t even think it was one of the fastest CPUs available when it was released 4 years ago. But I think we should be able to expect systems to remain usable for more than 4 years. The Opteron 1212 system is a Dell PowerEdge tower server that is used as a workstation and a file server, so while I get desktop systems with faster CPUs for free I want to keep using the old PowerEdge server to avoid data corruption. As an aside I ve been storing important data on BTRFS for a year now and the only data loss I ve suffered has been due to a faulty DIMM. The filesystem checksums built in to modern filesystems such as BTRFS and ZFS mean that RAM corruption covers a greater portion of the risk to data integrity and the greater complexity of the data structures in such filesystems gives the possibility of corruption that can t be fixed without mkfs (as happened to me twice on the system with a bad DIMM). The consequences of such wasted CPU use are reduced CPU time for other programs which might be doing something useful, extra electricity use, and more noise from CPU cooling fans (which is particularly annoying for me in this case). Any suggesstions for reducing the CPU use of web browsers, particularly when idle?

I've been incredibly, overwhelmingly busy lately, and I'm still fairly consumed by things other than writing journal posts (or reviews, sigh), but hopefully it's letting up a bit now. At the least, I'm back to writing code instead of doing other things, which is quite a relief. There's nothing particularly exciting in this release of my C test harness software, but since I'm doing some general releases anyway, it seemed like a good time to flush out pending changes. This release changes the exit status of the bail and sysbail functions to 255 to more closely match the BAIL_OUT function in Perl's Test::More, and documents why the runtests test harness does not match Test::More's handling of a bailing test case. You can get the latest version from the C TAP Harness distribution page.

The debconf BoF about gitify all things make we to want to report some of my git-annex use cases. The problem Calibre is a ebook manager that is available in debian. I use it to maintain my library, but also to dowload every day an epub version of a French newspaper and then put it on my kobo. Configuring git annex for this I wanted to use git-annex, so

    $ git init
    $ git annex init "some useful name"

But I don't want every thing in annex, because Calibre use some text file to save some metadata, so I used:

    $ git config annex.largefiles "include=* exclude=*.opf exclude=*.json"

then lets add everything

    $ git annex add *
    $ git add *
    $ git commit -m "first commit"

Calibre need read and write access on the its database, so let unlock it:

    $ git annex unlock metadata.db

On my other computer I only need to do

    $ git clone $user@$host:Calibre\ library
    $ cd Calibre\ library
    $ git annex init "another useful name"
    $ git annex get .
    $ git annex unlock metadata.db

The problem is that every time you will git annex sync, git annex will lock again the metadata.db, so lets unlock it automatically. I use git hooks, in .git/hooks/post-commit I have

    #!/bin/bash
    git annex edit metadata.db

don't forget to make this file executable

    $ chmod a+x .git/hooks/post-commit

Day to day operation

    $ git annex add .

Will put new file into the annex

    $ git add .

Will take care of the files that should no go into annex

    $ git annex sync

Will make the repositories exchange informations about all this, and make remote change local

    $ git annex get .

Will make remote book locally available Merge conflict You should not run calibre on the two computer simultaneously, or without syncing before it. If you do, you will have a conflict that git-annex will automatically solve by rename both of the file. You can then either:

• Choose one. If no books have been changed or added on one of the computer, to use the other metadata.db will not make you loose any information
• rebuild it. calibredb restore_database won't do it, but will tell you how to do it.

Checking the library You can use calibredb check_library to check you library is correct. If you use git for it, it will always tell you that it is not correct: there is this author ".git" it doesn't know about. Just don't care about it. Maybe this can be solved by using vcsh but apparently vcsh+git annex it not well tested yet. Automatic stuff I use mr to automatically run all this, but some config could be done (I believe) to have git annex copy --auto do what it should. There are also the git annex assistant for this kind of automatic synchronizations of contents, but I don't know if my automatic unlocking of one file will break this. It might be interesting to find someway to unlock and lock the library only when running calibre, a simple script to launch calibre will do that. Note that each time you will lock and unlock, you will have a new commit in git.

I ve been using Android phones for 2.5 years and for all my phones (Sony-Ericsson Xperia X10, Samsung Galaxy S, Samsung Galaxy S3, and LG Nexus 4) I ve bought gel cases. The gel cases are made of soft rubber which allows phones to bounce rather than break if dropped and also provide better grip (both for holding the phone and for resting it on a vibrating surface such as a tray in a car or plane). The cases have cost me between $12.50 and $15, I haven t felt inclined to pay any more because a case has always seemed like a needless expense, something that merely compensates for deficiencies in phone design. There are some problems with the gel cases, the first one is that they are rather ugly, while I m not really interested in decorating my phones it seems a waste to have a nice phone like the Nexus 4 which has a neat sparkling pattern on the back and then use a case that entirely covers it. The next problem is the fact that the gel cases tend to restrict access to the buttons on the outside of the case. I have been given a Rearth Ringke Fusion case for my Nexus 4 by MobileZap (this is a link for the Nexus 4 cases they sell) [1]. The case features a transparent layer of plastic at the back which protects the phone against having the rear glass of the case break (a known risk with the Nexus 4) while still allowing the user to admire it. With good lighting the sparkling pattern on the back of the phone can still be enjoyed, unfortunately this doesn t show up at all in my photo. It s impossible for a photo to capture a shimmering effect although other photographers have done a better job at showing off a Nexus 4. Also the transparent back to the case gives the option of putting any form of decoration between the phone and the case, for example one could print the logo of their Ingress team and put it between the phone and the case. One thing that is visible in the photo is the feet on the back of the case. With small feet at the corners the transparent back usually won t touch a surface that it rests on, this should prevent unsightly scratches to the back of the case. Also the feet can get some grip on the surface that it rests on, my car has a tray suitable for resting a phone which has a pattern of dimples that catch the feet of the Ringke case and prevent it from sliding. Finally the external buttons for power and volume control are not obstructed in any way. After using 7 phones of 4 different models with gel cases I ve become accustomed to buttons either being difficult to press or easy to press accidentally. The Ringke case allows the buttons to be pressed easily when needed but doesn t seem prone to accidental presses. I m not about to buy a new case for my Galaxy Note 2 (my main phone at the moment) because I don t like paying to replace something that works. But next time I buy a case I ll look for something better than a plain gel case, it s worth paying an extra $9 to get a good case for a phone that costs $350 (the current discount rate for a Nexus 4) or more. I definitely recommend the Ringke case for a Nexus 4.

• [1] http://www.mobilezap.com.au/32387/google/nexus-4/cases.htm

This blog post is a little recipe to do a Debian migration for a node using Puppet and some other good practices. We do all the following commands as root, which on of the exceptional situation where you should have a real root session (login through console, or su -). I tend to avoid using the X server while doing an upgrade, so my 'best' setup is to have a laptop to take note and check things on the internet and a session to the computer to upgrade (ssh + su - or login as root into console). In both case, I use screen during the upgrade so that I can handle disconnection. Create or update your admin-syscheck script First of all, a good practice is to have a script that runs various test on the system that checks everything is ok. This is not only for upgrade but in general. But in the case of upgrade, it can be particularly useful. I call this script admin-syscheck. This is a simple bash script. This script check various aspect of the system and serve me as my external worker to check the most advanced knowledge I have gathered about setting up a service. For example, I know that having *.bak or *.dpkg-dist in /etc/ means that something needs to be merged and a file should be deleted. Another example is about setting up the right alias for 127.0.0.1 and ::1 (which you can differentiate using getent ahostsv4 and getent ahostsv6). I have packaged this script and distributed it using a specific apt-get repository. You can just distribute it using puppet. I recommend to run it daily to track changes (e.g. after an apt-get dist-upgrade) and to check that my setup is aligned with my most up-to-date knowledge about setting up a service (i.e. this is my external worker). In our case we are interested in checking presence of old and new configuration files, before and after upgrading. Here is this specific section of my script:

if ! $IS_ROOT; then
  warning "Not trying to detect dpkg leftover file in /etc/."
else
  LEFTOVER_FILES=( $(find /etc/ \
      -name "*.dpkg-dist" -o \
      -name "*.dpkg-old" -o \
      -name "*.ucf-old" -o \
      -name "*.ucf-dist" -o \
      -name "*.bak") )
  for i in "$ LEFTOVER_FILES[@] "; do
    if [ "$i" = "/etc/hosts.deny.purge.bak" ]; then
      continue
    fi
    if $fix; then
      BASE=$ i%.* 
      cond_exec vim -d $BASE $i
      read -p "Delete $i (y/N)? " ans
      if [ "$ans" = "y" ]; then
        cond_exec rm $i
      fi
    else
       report_error "dpkg leftover file: '$i'."
    fi
  done
fi

(cond_exec allows to do a dry run, you can just remove it). Setting $fix to true will spawn a vim -d old new command where you can edit and then delete the leftover file. This is extremly handy. Upgrading to Wheezy I strongly recommend to read first the upgrade chapter of the release notes. This gives you a more complete overview of the upgrade procedure. I just go through the basic step here. 1. Update everything on the system:

$> apt-get update 
$> apt-get dist-upgrade

2. Check that the current configuration apply cleanly:

$> puppet agent --test

3. Run admin-syscheck:

$> admin-syscheck

And fix all the problems. 4. Disable puppet: I use a cronjob to run puppet, so I just comment the line for the job (/etc/cron.d/puppet-custom). You should disable puppet by stopping the daemon and preventing it to run by editing /etc/default/puppet and set START=no. 4. Fix your sources and pinning: Change squeeze to wheezy in /etc/apt/sources.list and remove useless files in /etc/apt/sources.lists.d/. (You may keep certain sources that refers to stable, like google-chrome.list).

$> rm /etc/apt/sources.list.d/* # Check if this ok to do this with your system.

Although, I tend to fully purge /etc/apt/sources.list expect for the main line (removing backports and security is fine for a short time). The first run of puppet after upgrade will anyway reset this file.

$> rm /etc/apt/preferences.d/* # (at least the ones that do pin some version)

You can although remove all pinning from /etc/apt/preferences. 5. Now you start the real upgrade:

$> apt-get update 
$> apt-get dist-upgrade

6. During the upgrade you will be asked if you want to keep old configuration files or install the newer one from the maintainer. I have always wondered what to answer to this. But here is the answer after a few major upgrade: always install configuration files from maintainer if the service has no ultra-specific settings that could break during the upgrade. The only file, that I should not upgrade on my system, is /etc/sudoers. In this very specific case, you need to make sure before the upgrade that the old and new configuration can coexist. In the squeeze to wheezy case, I have just setup a few extra augeas rules to set the secure_path before the upgrade and it was fine. This is typically the kind of situation where you are thankful to have a real root session. 7. The upgrade can be long and require various fixing to remove/re-add packages to circumvent problems. At the end you will have a set of file *.dpkg-old and *.ucf-old (and some *.dpkg-dist and *.ucf-dist). The *-old files are your old version of the file, while the corresponding files match the maintainer version of it. The *-dist files are the maintainer version of the file and the corresponding files match your old version of it. Starting from here you have 2 options:

• This is one of the first computer you upgrade, go to 'first upgrade'.
• Your puppet configuration for wheezy is already bullet proof, go to 'further upgrade'.

First upgrade This is the tricky part, you'll have to spend a little time on it: 1. Go over all *. ucf,dpkg - old,dist and merge them with the corresponding configuration file. Use admin-syscheck with fix=true 2. Make a copy of your /etc directory into /etc.new:

$> cp -rp /etc /etc.new

3. Run puppet again:

$> puppet agent --test

4. Disable again the automatic run of puppet, if the previous command has re-enabled it. 5. Make a diff between /etc and /etc.new. Since you have a run of puppet, you know what has changed and should not have changed.

$> diff -Nurd /etc.new /etc

Everytime you find some files that doesn't match your expectation for the upgrade with puppet, change the corresponding puppet manifest to have what you expect. For example, if this is a file:

if ($lsbdistcodename == 'wheezy')  
  file  
    "/etc/foo":
        source => "puppet:///files/foo.wheezy"
    
  else  
  file  
    "/etc/foo":
        source => "puppet:///files/foo.squeeze"
    
 

People working with augeas and puppet, will appreciate the fact that they probably have 0 changes to make for this to work (since it only does a few replacement in configuration files). 6. Once you are happy with the changes, copy back /etc.new to /etc and go to step 3 until the difference is almost 0. 7. Re-enable automatic run of puppet. Do this procedure for a least each computer category you have (e.g. Desktop and Server nodes). Once you are fully confident your new puppet setup works, you will be able to use 'further upgrade' for the other nodes. Further upgrade. This one is super easy compare to a first upgrade: 1. Re-enable puppet and have it run at least once:

$> puppet agent --test

2. Merge *. dpkg,ucf - dist,old with corresponding files (you can run admin-syscheck with fix=true). This is mostly a sanity check since you should have already solved most problem with the 'first upgrade' procedure. That's it. Enjoy your upgrade to Wheezy with puppet.

DebConf! The venue here at Le Camp is pretty much perfect. Short walking distances, organic layout of the buildings, and a stunning view of the lake. I would be hard pressed to think of other venues which could be as nice... After arriving Fri/Sat night at 0330, Saturday was spent setting up the Access points: This little green valve caused a power outage in the server room, messing with servers, and resetting several switches to old configs. Xtaran had a lot of fun as a result of this. The ikiwiki BoF on sunday was rather interesting. I will try to publish some notes from this BoF and the other Git-related ones towards the end of the week. The Gitify ALL the things BoF managed to fill the room from "full-ish" over "good thing we don't need the beamer and can use the space in front of the whitescreen" over "out of chairs" over "the chairs from other rooms won't fit any more" to the final state of "people stand around near the walls and in the doors". At a total of 54 people, turnout has been... unexpectedly high.. The BoF started at 1130 and usually, slots are 45 minutes long. We extended our BoF into lunch time (I chose the slot just prior to lunch for precisely that reason) and finally finished at around 1245, i.e. 30 minutes late. After a quick show of hands on if there's interest in another BoF, I applied for and got the next slot, tomorrow at 11:30, once again in BoF room 1 and just before lunch. It's called Gitify EVEN MORE of the things and will expand on use cases and best practices. At a guess, we will focus on managing configurations and photos in default and complex situations. Sadly, neither of those BoF are taped. Afterwards, I had a chance to sit down with Lucas Nussbaum to talk over some points regarding the Debian Trademark Team. Finally, during Why Debian should (or should not) make systemd the default (it probably should not, but that's a different story), my kernel panicked. 3.9 and 3.10 have been less than ideal on my new X1 Carbon, but this was the first panic. I was not even done cussing and Ben Hutchings suddenly appeared on my side, telling me that yes, this particular module (mei) has been causing issues recently. As a closing note, I am really enjoying my first DebConf. Great venue, great people, great content, winebeer and cheese party tonight, and I found out that we have a fire place and fire wood...

Hi everyone! We now have both Qt4 and Qt5 in the archive. Those using Qt4 should not need to make any changes in their packages, although you can be extra-safe with a few steps. Don't rush, just read below.
Some backgroundSune took the time some months ago to consult upstream for a sane way to allow both SDKs to coexist without us distros having to reinvent the wheel choosing which tools have to be in use in each case.

After a long discussion, upstream decided to write qtchooser (already in the archive) to be able to select between Qt4, Qt5 and even special user's cases like cross-platform builds.

So instead of going trough Debian's alternatives as we did with Qt3/Qt4, we will make use of this new tool.
My package uses Qt, how should I proceed?There are many ways of choosing either of the versions of Qt:

- Using any qtchooser method (preferred):

* Exporting QT_SELECT with 4, qt4, 5 or qt5 as a value in debian/rules.
* Call the tool using the '-qtx' parameter, where x can be replaced with any of the options above.

- Build-depending on qt4-default or qt5-default. You can't B-D on both of them, as they can't coexist.

It is good to notice that:

- any qtchooser method will take precedence over build depending on qtX-default.
- If you export XDG_CONFIG_DIRS it will ignore the default paths to qtchooser's configs we setted up in the packages.

We have also provided qt4-[arch-triplet] and qt5-[arch-triplet] options for special cases.

Once again, if you are already using Qt4, there is no need to rush. See below.

Can is use both Qt4 and Qt5 in my package?You can't mix Qt4 and Qt5 in the same binary, but you may provide libraries compiled against one or the other. For example, your source package foo could provide both libqt4foo1 and libqt5foo1. You need to mangle your debian/rules and/or build system accordingly to achieve this. At the time of this writing I don't know of any examples yet.

So are you going to break the archive with a big transition?No, we have done our best to avoid having to make any changes to existing Qt4 packages. Qt tools should default to Qt4 except if overriden by any method described above.

My package uses Qt4, can I leave it as it is?While there is no need to apply the changes in this case, explicitly setting the Qt version will surely not hurt at all. But don't rush ;-)

[no pictures here, just a short report]. Today DebConf, this year's edition of the annual Debian developer conference, started with two inspiring talks about Debian proper, one by Lucas Nussbaum, the other by Joey Hess. This also means that yesterday DebCamp ended, the period preceeding DebConf and dedicated to working on Debian together with others. Here's a short report from my point of view: I arrived here on Tuesday, the first day of DebCamp. I immediately fell in love with the venue, & despite the early stage of setup, everything I needed was working fine for me from the very start. Like in previous years, I used the time to do work in the Debian Perl Group, especially taking advantage of the presence of other team members. That's the great thing about DebCamp & DebConf: collaborating in real-life & real-time, from quickly asking a question over sitting together to think about solutions for a problem to "just" chatting & thereby developping ideas for the future. In the previous days I

• tried to get down the amount of packages with not-yet uploaded new upstram releases;
• looked into the pending bugs around the Perl 5.18 transition;
• investigated with others the details of the upcoming new timezone file handling in the Perl world, which will make our lives easier but still needs some work on the Debian side;
• prepared with others the Perl Group's BoF that will take place during DebConf on Thursday;
• helped with the creation of a new pkg-perl-tools package.

I really enjoy my time here, & I'm especially happy to meet some people for the first time in meat space. This is only possible due to the generous support of the DebConf sponsors & the immense efforts of the DebConf team. Thank you!

Yesterday evening I've arrived at DebConf 13. I was quite tired after traveling so I just had few beers and went to bed. The travel went quite well besides somebody else broke wine and my suitcase was all wet from it. Fortunately almost nothing got inside so I have some clean clothes for next week :-). As I went to bed quite early, I woke up early as well so I went to short walk to see what is nearby:

Filed under: English Debian Photography 0 comments Flattr this!