Search Results: "ag"

5 December 2011

Axel Beckert: automounter vs procmail

At work we use .procmailrc files generated by CGIpaf to let non-technical users create forwards, out-of-office mails, etc. and any combination thereof. This also has the advantage that we can filter out double bounces and spam (which also prevents us from being listed in spammer blacklists). Unfortunately autofs (seems independent if autofs4 or autofs5 is used) seems to be unreliable if there are bursts of mount or umount requests, resulting either in File or directory not found error message while trying to access the home directory of a user, or Directory not empty error messages if the automounter tries to remove the mount point after unmounting. In that case a not mounted directory owned by root is left over. In the end both cases lead to procmail behaving as if that user does not have a .procmailrc which looks like sporadically lost mails to those who forward all mails. (The mails then can be found in the local default INBOX for that user.) Additionally there are similar issues when the NFS servers are not available. The most effective countermeasure we found so far was adding tests to the global /etc/procmailrc to check if the user s home directory exists and belongs to the correct user: 
# -----------------
# Global procmailrc
# -----------------
# For debugging, turn off if everything works well
VERBOSE=1
LOGFILE=/var/log/procmail.log
# This only works with bourne shells, $SHELL defaults to the user's
# login shell. And by experience dash seems not work, so we use bash.
OLDSHELL=$SHELL
SHELL=/bin/bash
# temporary failure (see EX_TEMPFAIL in /usr/include/sysexits.h) if
# $LOGNAME is not set for some reason. (Just to be sure our paths
# later on are not senseless.
:0
* ? test -z "$LOGNAME"
 
    LOG="Expected variable LOGNAME not set. "
    EXITCODE=75
    :0
    /dev/null
 
# temporary failure (see EX_TEMPFAIL in /usr/include/sysexits.h) if
# $HOME is not readable. ~$LOGNAME does not seem to work, so this uses
# a hard wired /home/.
:0
* ? test ! -r /home/$LOGNAME
 
    LOG="Home of user $LOGNAME not readable: /home/$LOGNAME "
    EXITCODE=75
    :0
    /dev/null
 
# temporary failure (see EX_TEMPFAIL in /usr/include/sysexits.h) if
# $HOME has wrong owner. ~$LOGNAME does not seem to work, so this uses
# a hard wired /home/.
:0
* ? test ! -O /home/$LOGNAME
 
    LOG="Home of user $LOGNAME has wrong owner: /home/$LOGNAME "
    EXITCODE=75
    :0
    /dev/null
 
[ ]
If you want to store a copy of these mails for debugging purposes on every delivery attempt, replace /dev/null with some Maildir or mbox only accessible for root. One small but important part was to explicitly declare bash as shell for executing the tests, otherwise mails for users with tcsh or zsh as login shell filled up the mail queue and never get delivered (if the SHELL variable never gets fixed). Only drawback so far: This leads to more lagging e-mail on e-mail bursts also for those users who have no .procmailrc because procmail can t check if there s really no .procmailrc. Extensive procmail documentation can be found online at the Procmail Documentation Project as well as in the man pages procmail(1), procmailrc(5) and procmailex(5).

Meike Reichle: Bug Squashing Party in Hildesheim is over

Alexander has already announced the final results of this weekend's BSP, but I'd like to add my personal thanks. So, kudos to all attendees, for helping to make the BSP such a success and also to my employer for the generous budget and my colleagues, especially Wolfram to whose initiative we owe this BSP, for helping out before, during and after the party. All in all it's been an event well worth repeating!

Alexander Reichle-Schmehl: Summary from the Bug Squashing Party in Hildesheim

Uff. Two and a half days of hunting release critical bugs ended yesterday evening. It think it was quite a success. According to the statistics we closed 23 bugs with direct uploads, we created patches for 11, 9 bugs got solved by package removals, 6 will be closed by uploads via the delayed queue, 2 bugs were closed as unreproducible, and 9 other bugs where closed as well (e.g. already fixed in older version). On the other hand we opened 3 and upgraded 6 bugs to be release critical. So in the end, we solved about... 60 bugs! Wow, I'm really impressed! I'm also really pleased how well we integrated the newbs. As I already mentioned, when planing for this BSP started, we were a bit worried about the DD / non-dd ratio, but in the end everything worked out very well. All of those, who registered as interested users where able to fix some rc bugs, or help sort out some BTS hickups, e.g. bugs opened with package a but closed in package b. And as a special pleasure it seems, that the longest outstanding rc bug might be fixed soonish, too :) I'd also like to thank Pengutronix for hosting and sponsoring the BSP! The infrastructure worked very well: You arrived, plugged in your notebook, had a local mirror, IPv6 and fast enough connection to the outside. They also provided lots of snacks, cooked food and drinks (later they complained Debian people won't drink enough; apparently they calculated with way more drinks) and a general good atmosphere. PS: To the best of my knowledge, it was also the greenest bug squashing party ever, with most foods and all the electricity coming from certified ecological production. Cool, eh?

Russell Coker: CyanogenMod and the Galaxy S

Thanks to some advice from Philipp Kern I have now got my Galaxy S running CyanogenMod 7.1.0 which is based on Android 2.3.7 [1]. CyanogenMod has lots of configuration options that seem to be lacking in the stock releases and also supports some advanced features such as OpenVPN and a command-line. I can t properly compare CyanogenMod to the stock Android as I ve only used versions 2.1 and 2.2 of the stock Android. Presumably some of the things that I like about CyanogenMod are in the stock Android 2.3.7 release. The process of updating a phone is difficult and has some risk. Fortunately Samsung provided Download mode in the BIOS to allow recovery. If you mess up the process of updating a Galaxy S and you can get Download mode by holding down volume-down, home, and then power buttons then you can almost certainly recover (so don t panic). The CyanogenMod people don t provide any documentation on upgrading from Android 2.2 (which is what Optus is still shipping AFAIK). So you will probably have some difficulty when upgrading a Galaxy S that you get in Australia (it seems that Optus is the only company shipping them in volume). As an aside if you want to buy a Gel Case for a Galaxy S in Australia then visit an Optus store. It seems that Optus is the only phone store that hasn t run out their Galaxy S accessories in favor of the Galaxy S2. I have previously written about the Galaxy S and Three Networking [2]. Now that I have the Galaxy S as my primary phone on the Virgin network all my data corruption problems are solved, the problem is entirely related to Three. With CyanogenMod there is an option to be able to toggle the LED Flash as a torch from the drop-down menu, this makes the lack of such a LED on the Galaxy S even more of an annoyance. I have also discovered that the Galaxy S apparently doesn t have a status LED! This makes it the only phone that I ve ever owned that has no clear way of informing me when the battery is charged! It s also really useful to have a flashing LED to indicate low battery when running a full screen app, and to have a flashing LED to indicate that email has been received. Someone should design a phone with multiple LEDs to indicate different things. I d like to have one LED to indicate charging status and another to indicate whether there is unread email or SMS. Whatever the cost of including a LED during manufacture it would have to be almost nothing compared to the ~$500 sale price of a phone. Wikipedia says The Samsung Galaxy S features a PowerVR graphics processor, yielding 20 million triangles per second, making it the fastest graphics processing unit in any smartphone at the time of release. Also, upon release, the Galaxy S was both the first Android phone to be certified for DivX HD, and at 9.9 mm was the thinnest smartphone available . I don t care about any of that, I want a phone with decent battery life, a LED Flash , and a status LED. The main benefit I get from the Galaxy S over the Xperia X10 is the greater storage. The Xperia X10 has a total of 1G of storage and only 465M of that is available for application install. My Galaxy S has 16G of internal storage of which 1.8G is available for phone apps and 13G is available for pictures and other mass storage. Having 1.8G for phone apps and internal phone storage used by such apps (which includes the offline IMAP cache) is a massive benefit, enough to outweigh the lack of a staus LED and a Flash LED. What I Really Want I d rather have a Samsung Galaxy Note. The Note has a LED flash, a 5.3 screen with 1280*800 resolution which is much better for running as a SSH client and also good for web browsing. I m not inclined to spend money on a phone now, so I ll probably use the Galaxy S until Virgin offers me a new phone or someone just gives me a new phone (I can always hope). One of the many nice features in the Galaxy Note is a built in stylus. When using my current phones for web browsing I sometimes find it difficult to have a touch registered to the desired part of the screen, this is a real problem with the Opera web browser which requires a long press to open a URL in a new tab.

4 December 2011

Gregor Herrmann: RC bugs 2011/48

here's my report about RC bug related activities for the last week. besides working on the bugs mentioned below I've also documented my RCBW work flow for the NMUs, just in case it's interesting for others.

Joerg Jaspert: BSP Hildesheim

Right, so I am at the BSP in Hildesheim. Arrived somewhere Friday, leave in a few hours, and in the meantime I managed to break all our 3 archives at least once. Yay. But heck, I also managed to get them back to work (with help from the FTPTeam too), so it was a good thing. We are back on one code revision for security, backports and main archive. Security also changed to the newer style of handling the buildd repositories and is now also using daks own method of writing packages files instead of using apt-ftparchive. And while I was at it I also created 3 new sections, got a SHA256SUMS file in addition to the MD5SUMS for the debian-installer images (thanks Joeyh for the quick reaction), enabled DM uploads for backports and implemented various other smaller fixes and cleanups.

Tanguy Ortolo: Concerning the good use of ITP

When someone wants to package a piece of software for Debian, he has to file an Intent to Package, by filing a special bug report against the pseudo-package wnpp (work-needing and prospective packages) with a title of ITP: software name . This way, we can synchronize our efforts, for instance if someone else wants to package the same piece of software. I have seen two recent examples of a misunderstanding of the correct use of such reports, so perhaps this reminder may be of some help for newcomers.While an Request for Package means that its author would like someone to package a piece of software, and ITP means that its author wants to package it himself and to have it integrated to Debian (in fact, an RFP also becomes an ITP when someone is willing to do the work). This means that the owner of an ITP bug is responsible for the corresponding work. Given that the ITP report is meant to inform others, that implies that he should document his progress by appending messages to the bug report. In particular, when something is blocking the work (typically a failure to find a sponsor), that should be indicated in the ITP report so that it does not appear as being abandoned. So, in a nutshell, when you have opened an ITP, do not expect someone to take it, to reply to it or whatever deus ex machina; you are now the owner of that bug, which means you are responsible of making it live and eventually closing it by sending your package to Debian. The progress of a packaging work should be documented, especially if it requires some specific help such as sponsoring, and the ITP report is the best place to do that since this is where interested people will look for status information.

Francois Marier: Optimising PNG files

I have written about using lossless optimisations techniques to reduce the size of images before, but I recently learned of a few other tools to further reduce the size of PNG images.

Basic optimisationWhile you could use Smush.it to manually optimise your images, if you want a single Open Source tool you can use in your scripts, optipng is the most effective one:
optipng -o9 image.png

Removing unnecessary chunksWhile not as effective as optipng in its basic optimisation mode, pngcrush can be used remove unnecessary chunks from PNG files:
pngcrush -q -rem gAMA -rem alla -rem text image.png image.crushed.png
Depending on the software used to produce the original PNG file, this can yield significant savings so I usually start with this.

Reducing the colour paletteWhen optimising images uploaded by users, it's not possible to know whether or not the palette size can be reduced without too much quality degradation. On the other hand, if you are optimising your own images, it might be worth trying this lossy optimisation technique.

For example, this image went from 7.2 kB to 5.2 kB after running it through pngnq:
pngnq -f -n 32 -s 3 image.png

Re-compressing final imageMost PNG writers use zlib to compress the final output but it turns out that there are better algorithms to do this.

Using AdvanceCOMP I was able to bring the same image as above from 5.1kB to 4.6kB:
advpng -z -4 image.png

When the source image is an SVGAnother thing I noticed while optimising PNG files is that rendering a PNG of the right size straight from an SVG file produces a smaller result than exporting a large PNG from that same SVG and then resizing the PNG to smaller sizes.

Here's how you can use Inkscape to generate an 80x80 PNG:
inkscape --without-gui --export-width=80 --export-height=80 --export-png=80.png image.svg

3 December 2011

Joachim Breitner: Some late recognition of metainit

Four years ago, during DebConf 7 in Edinburgh, I had the idea of creating init scripts not by hand, but rather describe them in a declarative way that handles most common cases and generate the real init scripts from them. Back than, this was partly motivated by the varying quality of init scripts and the advent of an alternative init system, upstart, for which proper service files could be generated as well. I implemented the idea and uploaded it as metainit to Debian, but it did not take off. Only one package uses it, and this package is not used much either. The project basically fell dormant. Yesterday, I got this mail:
Hi Joachim, I'm not very familiar with Debian ecosystem, however our company has recently switched to exclusively using Debian based servers, please forgive me if there exists a better channel for sending patches. We need (in house) to create a lot of trivial services and the sysv init system seems an ideal way to manage them, and metainit an great way to keep the config simple. However all our scripts require a heartbeat, the way we normally do this is with a bunch of checkers launched from cron. Metainit was ideal, but lacked the simple 'status' task found in most init scripts. This small patch adds that task, I hope you and others find it usefull. Regards,
together with the mentioned patch. So it turned out that the idea was a useful one after all, although it found its use on our user s machines, and not within the Debian packages, as I originally anticipated. Nice! During the recent discussions about the latest init system, systemd, there were more thoughts about generating init scripts/upstart service descriptions/systemd units from a declarative description, and if metainit had taken off back then, things would be easier now. So if anyone feels like reviving the project: Please do.

Flattr this post

Christian Perrier: New update about Debian Installer localization

One string added in level 1, so all translations temporarily dropped from 100% 14 are already back to completeness. Before that, we had 25 that were complete. Yay. Apart from that, Norwegian Bokm l completed level 3. Full stats are here Status for D-I level 1 (core D-I files): Status for D-I level 2 (packages that have localized material that may appear during default installs, such as iso-codes, tasksel, etc.): Status for D-I level 3 (packages that have localized material that may appear during non-default installs, such as win32-loader) So, full 100% completeness (hall of fame) for: German, French, Portuguese, Slovak

Olly Betts: Debian RC Bugs Fixed for November 2011

Patrick Schoenfeld: Let me introduce DPKG::Log and dpkg-report

We have customers, which require a report about what we've done during maintenance windows. Usually this includes a report about upgrades, newly installed packages etc. and obviously everything we've done apart from that.
Till now we've prepared them manually. For a greater bunch of systems this is a big PITA, because to be somehow useful you have to collect the data for all systems and after that, prepare a report where you have:

Its also error-prone because humans make mistakes.

Perl to the rescue!
At least the part about generating a report about installed/upgraded/removed packages could be automated, because dpkg writes a well-formed logfile in /var/log/dpkg.log. But I noticed that there appearently is no library specialised at parsing that file. Its not a big deal, because the format of that file is really simple, but a proper library would be nice anyway.
And so I wrote such a library.
It basically takes a logfile, reads it line by line and stores each line parameterized into a generic object.

Its features include:

Based on that, I wrote another library DPKG::Log::Analyse, which takes a log, parses it with DPKG::Log and then extracts the more relevant information such as installed packages, upgraded packages, removed packages etc.

This, in turn, features:
- Info about newly installed packages
- Info about removed packages
- Info about upgraded packages
- Info about packages which got installed and removed again
- Info about packages which stayed halfinstalled or halfconfigured at the end of the logfile (or defined reporting period)


These libraries are already uploaded to CPAN and packaged for Debian.
They passed the NEW queue very quickly and are therefore available for Sid:

http://packages.debian.org/sid/libdpkg-log-perl

As an example use (and for my own use case, as stated above), I wrote dpkg-report, which uses the module and a Template::Toolkit based template to generate a report about what happened in the given logfile.
It currently misses some documentation, but it works somehow like this:

Report for a single host over the full log:
dpkg-report

Report for a single host for the last two days:
dpkg-report --last-two-days

Report for multiple hosts (and logfiles):
The script expects that each log file has the name <systemname>.dpkg.log so that it can guess the hostname from the system and can grab all such log files from a directory if a directory is specified as log-file arguments:</systemname>

dpkg-report --log-file /path/to/logs

This will generate a report about all systems without any merging.

Report for multiple hosts with merging:
dpkg-report --log-file /path/to/logs --merge

This will do the following:
A (fictive) report could look some what like this:

dpkg-Report for all:
------------------------
Newly Installed:
abc
Removed:
foo
Upgraded:
bar (0.99-12 - 1.00-1)
dpkg-Report for test*:
------------------------
Newly Installed:
blub
dpkg-Report for test1:
------------------------
Upgraded:
baz (1.0.0-1 -> 1.0.0-2)
dpkg-Report for test2:
------------------------
Upgraded:
zab (0.9.7 -> 0.9.8)

Currently this report generator is only included in the source package or in the git(hub) repository of the library. I wonder if it makes sense to let the source package build another binary package for it.
But its only a 238 lines perl script with a dependency on the perl library so I'm unsure if it warrants a new binary package. What do others think?

Steve Kemp: So I removed some more software from my host

Today I was idly performing some maintainence upon one of my hosts, and it crossed my mind to look beneath /etc in there I found: 
/etc/python
/etc/python2.4
/etc/python2.5
/etc/python2.6
That made me look more closely at the contents of /etc - the following command output was surprising: 
steve@steve:~$ ls /etc   wc -l
187
Is that average? Heavy? Light? I have no idea, but I purged a hell of a lot of software today. Now I have only python v2.6 although for some reason I still have: 
python
python-apt
python-apt-common
python-central
python-minimal
python-support
python2.6
python2.6-minimal
I suspect I could drop the pything2.6-minimal package, but for the moment I'm done. I have to make pretty people look exceptional with my magical camera. Anyway as part of this cleanup I ran a quick sanity-check on which processes are running and I think, short of kernel processes, I'm as minimal as I can be. I understand the purpose and reason for every running service: 
UID        PID  CMD
root         1  init [2]
pdnsd    14091  /usr/sbin/pdnsd --daemon -p /var/run/pdnsd.pid
root     14199  /usr/sbin/monit -c /etc/monit/monitrc -s /var/lib/monit/monit.state
root     14206  /usr/sbin/syslog-ng -p /var/run/syslog-ng.pid
root     14234  /usr/sbin/cron
102      14595  /usr/sbin/exim4 -bd -q30m
redis    14627  /usr/bin/redis-server /etc/redis/redis.conf
root     14637  /usr/sbin/sshd
These are basic services; I use monit to ensure those essential daemons keep running. The only oddity there is probably the local DNS cache, but it is useful if you run any kind of DNS blacklist-using service, for example. 
root     14794  /sbin/getty -L ttyS0 9600 vt100
I need a serial console login for emergencies. 
root     14796  runsv node-reverse-proxy
root     14797  /bin/sh ./run
root     14799  /opt/node/bin/node node-reverse-proxy.js --config ./rewrites.js
These three processes combine to run my reverse proxy which routes incoming HTTP requests to a number of local thttpd instances. 
qpsmtpd  27309    /usr/bin/perl -Tw /usr/bin/qpsmtpd-prefork --port 25 --user qpsmtpd --pid-file /var/run/qpsmtpd/qpsmtpd.pid --detach
..
The perl SMTP daemon which runs my incoming mail, passing it to exim4 which listens upon 127.0.0.1:2525. You can read about my setup in the out-of-date writeup Chris & I put together. 
 /usr/bin/memcached -m 64 -p 11211 -u root -l 127.0.0.1
Memory cache for transient items. 
s-blog    thttpd -C /etc/thttpd/sites.enabled/blog.steve.org.uk
1030      thttpd -C /etc/thttpd/sites.enabled/edinburgh-portraits.com
s-hg      thttpd -C /etc/thttpd/sites.enabled/hg.steve.org.uk
s-ipv4    thttpd -C /etc/thttpd/sites.enabled/ipv4.steve.org.uk
s-ipv6    thttpd -C /etc/thttpd/sites.enabled/ipv6.steve.org.uk
s-kvm     thttpd -C /etc/thttpd/sites.enabled/kvm-hosting.org
...
One thttpd instance is launched for each distinct HTTP site my server runs. Each site runs under its own UID, with its own chrooted directory tree. This is important for security. Each local instance listens upon 127.0.0.1 - and the reverse proxy previously mentioned rewrites connections to the appropriate one. 
1016     28812     /usr/bin/perl -I./lib/ -I./ /usr/local/bin/blogspam
My anti-spam filter for blog comments.
Here is my christmas challenge. Can you identify each service upon your host? Do you know why you're running what you're running? Me? I had no idea I had a dbus deamon running. Now I've purged it. Ha! ObQuote - "I owe everything to George Bailey. Help him, dear Father." - It's a wonderful life.

Evgeni Golov: git rocks even when it sucks

Today I wanted to clone my dotfiles repository (no, not available online, too much private stuff in there) to a remote machine and noticed that it has grown way too big (20MiB working directory and about 200MiB in .git), so I decided to clean it up. git gc did clean up a couple of megabytes, but .git was still about 190MiB, so I wasn t satisfied. Short thinking revealed the lost megabytes are somewhere in the history when I accidentally added some files and removed them afterwards (iceweasel, icedove, it s you I m blaming ;)). But how the heck do I find and remove them? git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch FILE' -- --all will remove FILE from all commits, says git-filter-branch(1), but how to find those files? They are not in my working directory anymore and I do not want to checkout every revision and look for big files in there. Let s ask git itself :)
for commit in git log --all --pretty=format:%H ; do git ls-tree -r -l $commit; done awk ' print $4 " " $5 ' sort -nu will show all files (actually all versions of all files) ever known to git, with the biggest ones at the end. Just identify the really big (unused) ones and remove them as above, thats what you think, right? Right, but .git won t be any smaller. Huh? Read git-filter-branch(1) again, just create a clone and it will be smaller, so mission accomplished! Now I had just 6MiB to push (compressed). For reference, the old tree would have used something about 150MiB to push.

0 comment(s) this blog is flattr enabled

Alexander Reichle-Schmehl: Report from the Bug Squashing Party in Hildesheim Part 1

Yesterday the Bug Squashing Party in Hildesheim, Germany started. I think it's going well, according to the statistics of the #debian-bugs channel, we solved 11 bugs with direct uploads, 2 with uploads to delayed, 5 via package removals and opened/upgraded only one. So we are still fixing more than we break ;) I'm especially pleased that some of the above was done by newbies. When we started to organise this BSP (well, when I started to watch Meike and Wolfram organise it to be precise), we where kind of worried by the experienced developer to newbie ratio, and already started to prepare introductions to packaging and similar adhoc sessions, but as it seems they don't seem to be needed. Good :) So back to fixing stuff, good hunt!

2 December 2011

Alexander Reichle-Schmehl: Release Critical Bug report for Week 48

The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:
In Total:1749
Affecting Wheezy:1094
Wheezy only:138
Remaining to be fixed in Wheezy:956
Of these 956 bugs, the following tags are set:
Pending in Wheezy:43
Patched in Wheezy:178
Duplicates in Wheezy:50
Can be fixed in a security Update:33
Contrib or non-free in Wheezy:12
Claimed in Wheezy:0
Delayed in Wheezy:2
Otherwise fixed in Wheezy:93
Ignoring all the above (multiple tags possible) 604 bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy released. However, with the view of the Release Managers, 991 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

Rapha&#235;l Hertzog: My Debian Activities in November 2011

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (310.73 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg: Multi-Arch Saga I know lots of people are waiting the landing of multiarch in Debian unstable, and so am I. Things are progressing, though not as quickly as I hoped. Guillem merged about half of the branch between the 24th October and the 6th of November. After that most of the work happened on his personal repository in his pu/multiarch/master branch. I verify this repository from time to time because Guillem does not inform me when he has made progress. I noticed changes on his repository on the 10th, 19th, 23th, 28th of November and on the 1th of December. He announced a long time ago that he had some interface changes and up to now only wrote about the switch from the command-line option --foreign-architecture (to put in /etc/dpkg/dpkg.cfg) to the explicit command dpkg --add-architecture that only needs to be called once (see mail here). As of today (December 2th), the promised email for the other interface changes is still not here. On November 23th, I reviewed Guillem s work and tried to run the code in his branch. I spent the whole day chasing up regressions and submitted lots of fixes to Guillem. Thanks to the extensive test-suite I wrote when I developed my branch, it has been fairly easy to track them all down. All the issues I reported have been fixed in the latest version of Guillem s branch although the fixes are often slightly different from those that I submitted. Dpkg: Squeeze Backport At the start of the month, I uploaded what I expected to be a fairly uncontroversial backport of dpkg 1.16.1.1. It turns out I was wrong. After some discussion, I think we came to an agreement that it was acceptable to backport dpkg-dev and libdpkg-perl only. My goal was not to bring the latest dpkg to users but to make it easier for package maintainers to backport packages using new features provided by dpkg-dev >= 1.16 (such as hardening build flags, the makefile snippets provided in /usr/share/dpkg/, or the improved dpkg-buildflags interface). Thus I modified the source package uploaded to squeeze-backports to build only dpkg-dev and libdpkg-perl. It has been uploaded on November 23th and it s waiting in the NEW queue for a backports admin to process it. Misc Dpkg Work I merged a patch of Colin Watson to be able to verify build-dependencies for a foreign architecture (taking into account the Multi-Arch status of each package listed). I released dpkg 1.16.1.2 with two minor fixes that were sitting in the sid branch. I wanted to get rid of this so that the path is clear for a 1.16.2 upload with multiarch. The package just migrated to testing so we re fine. I spent another day doing dpkg bug triaging on Launchpad, we re now down to 77 bugs with many of them tagged as incomplete and likely to expire in 2 months. The Debian Administrator s Handbook eBookWe released a sample chapter so that it s easier to have an idea of the quality of the book. The chapter covers the APT tools quite extensively. I bet that even you could learn something about apt-get/aptitude The crowfunding campaign on Ulule ended on November 28th.
With 675 supporters, we raised 24385 EUR. Of those, 14935 EUR have been put in the liberation fund and the rest corresponds to the various pre-orders and rewards offered. This means that the translation will happen (we just started) but that the book is currently not going to be released under a free license. Don t despair As planned, the liberation campaign is carried on until the 25 K target is reached! Instead of being hosted on Ulule, this permanent campaign is on the project website at debian-handbook.info/liberation/. Note that any contribution of 10 EUR or more means that you get a copy of the ebook as soon as it s available (even if the liberation target is not reached). Package Tracking System At the start of the month, I filed two ideas of improvements for the PTS in the bug tracking system: #647258 is about showing outstanding bugs that relate to a release goal and #647901 is about warning maintainers that the package is affected by a current transition. If you re a coder and want to start contributing to Debian and its QA team, those bugs could be interesting targets for a start. :-) In both cases, I have been in contact with members of the release team because those ideas require some structured data from the release team as input. Thanks to Meddi Dohguy and Niels Thykier for their help. Later in the month, the topic of relocating the PTS once again came up. For historical reasons, the PTS was hosted on master.debian.org together with the BTS. Nowadays the BTS has its own host and it made no sense anymore to have the PTS separate from the rest of the QA services hosted on qa.debian.org (currently quantz.debian.org). So together with Martin Zobel Helas we took care to plan the migration and on November 19th we executed the plan. It worked like a charm and almost nobody noticed (only one undocumented dependency was missed, which broke the SOAP interface). Misc Packaging Work WordPress was broken in Ubuntu and it was also not properly synchronized with Debian due to an almost useless change on their side. Thus I requested a sync so that the working version from Debian gets imported in Ubuntu. I sponsored the docbook-xsl 1.76.1 upload that I needed for Publican. Then I updated Publican just to discover that the test-suite triggers a new bug in fop (filed as #649476). I disabled the test-suite temporarily and uploaded Publican 2.8 to unstable. BTW, I also filed 2 upstream bugs with patches for issues I discovered while trying to generate the sample chapter of my book (see here and here). I uploaded a version 0.7.1 of nautilus-dropbox and fixed #648215 at the same time. I made an NMU of bison to fix a long-standing release critical bug that hit me once more during an upgrade (see #645038). I uploaded to experimental a new version of gnome-shell-timer compatible with GNOME 3.2. I took the opportunity to install from experimental the few GNOME 3.2 packages which are not yet in unstable Thanks See you next month for a new summary of my activities.

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

Michael Prokop: commit-sounds make committing more fun

December, release time. I m currently involved in the release management of three major projects and it s not always about fun. So lets make it more fun: https://github.com/mika/commit-sounds

1 December 2011

Christian Perrier: New update about Debian Installer localization

One string added in level 1, so all translations temporarily dropped from 100% 14 are already back to completeness. Before that, we had 25 that were complete. Yay. Apart from that, Norwegian Bokm l completed level 3. Full stats are here Status for D-I level 1 (core D-I files): Status for D-I level 2 (packages that have localized material that may appear during default installs, such as iso-codes, tasksel, etc.): Status for D-I level 3 (packages that have localized material that may appear during non-default installs, such as win32-loader) So, full 100% completeness (hall of fame) for: German, French, Portuguese, Slovak

Christian Perrier: Between 60 and 64 languages supported in Debian Installer

(including English!) The string freeze of Debian Installer officially ended at 23:59 yesterday (Sept. 20th). Indeed, this was extended a bit to today, with agreement by Otavio Salvador who I thank for this. That allowed Zak to "save" Tagalog and also the Welsh and Latvian translators to polish their work. We now have to decide about some of these languages: those that failed to meet the release criteria but were formerly activated in D-I. There are four such languages: Amharic, Welsh, Estonian and Northern Sami. Please find below the mail I just sent to debian-i18n and debian-boot. I promised that this discussion would happen in public. It will (but it will be short as we can't delay the release of the installer for ages....and I think that my proposals are reasonable!) 
First of all, the numbers as of Sunday Sept. 21st 09:32 UTC (date of
the last commit with an l10n update):
Languages meeting the release criteria: 59
------------------------------------------
Already activated and complete for level 1: 51
 Arabic, Belarusian, Bulgarian, Bosnian, Catalan, Czech, Danish,
 German, Dzongkha, Greek, Esperanto, Spanish, Basque, Finnish, French,
 Galician, Gujarati, Hebrew, Hindi, Croatian, Hungarian, Indonesian,
 Italian, Japanese, Georgian, Khmer, Korean, Lithuanian, Latvian,
 Macedonian, Malayalam, Marathi, Norwegian Bokm l, Nepali, Dutch,
 Norwegian Nynorsk, Punjabi, Polish, Portuguese, Brazilian Portuguese,
 Romanian, Russian, Slovak, Albabian, Swedish, Tamil, Thai, Turkish,
 Vietnamese, Simplified Chinese, Traditional Chinese
Already activated and complete for sublevels 1 and 2: 6
Bengali, Kurdish, Slovenian, Tagalog, Ukrainian, Wolof
Not yet activated languages complete for sublevels 1 and 2: 2
 (the mail in -i18n and -boot says 3 but this is an error by me)
Irish, Serbian
Languages failing to meet the release criteria: 15
--------------------------------------------------
Activated languages: 4
Amharic, Welsh, Estonian, Northern Sami
Not yet activated languages: 11
Afrikaans, Persian, Armenian, Icelandic, Kazakh, Kannada,
Malagasy, Malay, Telugu, Urdu, Xhosa
Discussion
----------
(careful people will notice that I moved Welsh down to "failed to meet
the release criteria" as this is what is technically correct)
Nothing to discuss for the 57 already activated languages that meet
the defined criteria. They'll be kept or first activated in the RC1
release of Debian Installer.
Similarly, nothing to discuss for the 11 languages that were not
activated and haven't made it. They will remain unactivated.
Two languages should be activated as they have met the release
criteria for the first time during the string freeze: Irish and Serbian.
This adds more load (and size changes) to D-I but I really don't see
any reason to not follow our own rules there.
The discussion comes for the 4 languages that fail to meet the release
criteria. Here are my proposals with some rationale:
Amharic: 
  I would really dislike deactivating Amharic because it's highly
  symbolic to have the language of Ethiopia activated. We have so few
  African languages. Also, the translation is nearly complete and the
  translator was well coping with updates until July. The missing
  stuff for Amharic in sublevels 1 and 2 are messages about loading
  drivers or firmware from removable media, the rescue mode stuff for
  the graphical installer and some messages that briefly appear during
  finish-install. A little bit more important is the message warning
  that the boot partition is not ext2 or ext3, added in August by
  tbm. I think this is not enough to drop out one year of efforts for
  the translator
  As a consequence, I propose to KEEP Amharic.
Welsh:
  Only five strings are missing in sublevels 1 and 2 because of the
  small experience of PO files by the person who completed the
  translation during last week. One will make the regular user login
  name screen to be in English and others will make the GRUB password
  screen to be in English as well, that's all.
  Additionnally, we can safely assume that all potential users of
  Welsh have good skills in English...and will therefore very easily
  cope with these screens.
  As a consequence, I propose to KEEP Welsh.
Estonian:
  The translation had NO update since Etch. The last update is dated
  back to Feb. 17th 2007. I haven't got any sign of life from the
  translator and no Estonian users have volunteered to maintain the
  translation.
  Missing strings are in many places, including several screens that
  appear in default installs. Even though one can assume that the
  skills of the average Linux user in Estonia is fairly good, I think
  this is not enough to throw users in a big mix of English and
  Estonian.
  As a consequence, I propose to DROP Estonian.
Northern Sami:
  The translation is very incomplete. With about any other language,
  that would be a reason to drop the translation.
  However, a few reasons make me suggest keeping it:
   - Northern Sami is mostly used in Norway and D-I will fall back
     to Norwegian Bokm l which is understood by all potentials users
     as it is teached in all Norwegian schools. 
   - Users will be warned, *in Sami*, about this situation
   - The choice of Sami will be kept in localechooser even if the
     translations are dropped. This is on request of Debian Edu
     developers to avoid them to develop a special boot floppy
     to offer the choice of Sami (a requirement for Norwegian
     schools). I personnally think this is a reward to Debian Edu and
     its ancestor Skolelinux for their initial involvement in the
     development of D-I
  As a consequence, I propose to KEEP Northern Sami.
I understand that these choices may be debatable and some may sound
slightly subjective. I however think this is the best way to be fair
with translators' efforts without compromising the quality of D-I.
Please note that the final word on this will be by D-I release
managers...but advices are very much welcomed.

Next.

Previous.