Stats so far:Closedby removals: 8
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.
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.optipng -o9 image.png
pngcrush -q -rem gAMA -rem alla -rem text image.png image.crushed.pngDepending on the software used to produce the original PNG file, this can yield significant savings so I usually start with this.
pngnq -f -n 32 -s 3 image.png
advpng -z -4 image.png
inkscape --without-gui --export-width=80 --export-height=80 --export-png=80.png image.svg
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.
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):
dpkg-report
dpkg-report --last-two-days
dpkg-report --log-file /path/to/logs
dpkg-report --log-file /path/to/logs --merge
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)
The other day I was talking with someone else who is making backup
software (
bup, to be precise). That was nice, so I thought I'd
create an IRC channel for our kind of weirdos. If you like making
backup software, please join #backuphackers on irc.oftc.net.
Also, I think there's a need for neutral third parties to run
validation tests and benchmarks on backup software. Anyone interested
in doing that?
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.6That made me look more closely at the contents of /etc - the following command output was surprising:
steve@steve:~$ ls /etc wc -l 187Is 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-minimalI 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.
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.
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 developerto
newbieratio, 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!
A melancholic look at intellectual disability and how it was regarded and
treated by the society of the time (1960s). Despite an inevitable conclusion, it was enjoyable and thought provoking.
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 |
| 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 |
Wheezyreleased. 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 statisticsfor an explanation of the different numbers.
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
We 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.
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.
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
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):
(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.
I m currently running the problem class for the graph theory course at the Karlsruhe Institute of Technology, held by Prof. Maria Axenovich. On one problem sheet, I felt like setting the question in verse, and indeed, two students submitted their solution is in verse form as well. I have assembled the problem and both solution enjoy! 
Next.