I've just pushed out version 0.16.2 of my
Python B-tree library. This should fix
all remaining problems of B-tree nodes being modified in place
while in the upload queue. This is done by never modifying nodes
after they have been put into the node store.
Performance suffers, but it's worth it for correctness.
If anyone would like take a stab at making it faster again,
there's instructions in the README
file for getting started with hacking the code, or you can ask
me. Profiling indicates
that it might be quite helpful to keep the root node of a tree
out of the store until the forest-of-trees gets committed.
On the other hand, the performance of obnam has not been greatly
affected by these changes, since it spends most of its time reading
and writing the contents of files being backed up.
The government of Egypt has blocked almost all Internet and mobile phone
access,
and, probably, every other form of communication as well. The government wants
to prevent its citizens from protesting and demanding the president to resign.
I wish the people of Egypt well. When the blocks are taken down, I hope
the people report that the country is peaceful and that they have finally
gotten some freedom.
The government of Egypt claims to be democratic, but what they are doing
should not be possible in a democracy. The fundamental
aspect of a democracy is that every citizen should have the right to
vote, but it is not the only necessary right for a democracy. Making
your concerns heard to the government, and to other people, is also
a fundamental right. As is hearing what other people have to say.
Riots and violence are not acceptable ways to protest. Cutting everyone
off is not going to prevent that, however, and it greatly harms any
chance of peaceful resolution. But that's hard to see, when you're
effectively a dictator, sitting at the top of a high tower, looking
down at the common people.
If the government is actively, and violently, hostile towards its people,
the people have three choices: they can submit and accept the situation
and continue suffering; they can oppose peacefully; or they can oppose
violently. It requires great wisdom to oppose peacefully, and quite a lot
of patience.
It's easy, from my northern European point of view, to look at Egypt
from afar, and think lofty thoughts. We here in the cold are not
safe from such oppression, however.
Evil people in the US have already tried to give the US president
similar powers
months ago.
They're trying again.
It is only a matter of time until this will be proposed in the EU, too,
if it hasn't been already.
In a crisis, people need timely access to reliable information, otherwise
the crisis gets made worse by rumors and people making bad decisions
based on bad data. Switching off communications is never the right
solution, from the people's point of view. Those in power
obviously think differently.
See also:
Information on how to bypass some of the blocks in
Egypt.
If There is any sort of food for thought worth reading, this is it.

It s quite common that the upstream build system generates/updates some files but does not clean them up properly when you call make clean. In that case, when you rebuild the package a second time in the same tree, the generated Debian source package will contain those changes.
You usually don t want those changes. They make your package harder to review because they contain unneeded modifications (either directly in the .diff.gz with the old source format, or in a new patch in debian/patches/debian-changes-<ver> with the 3.0 (quilt) source format).
I ll show you 3 ways to avoid this problem. They are all workarounds, the proper fix would be to improve the upstream build system to really clean up the generated files. This is usually possible for files that are created , but it s much more cumbersome for files that are updated (you would have to keep a backup of the original file so that you can restore it).
The traditional fix
Instead of relying on the upstream build system to do the work, we modify the clean target in debian/rules to remove the files that are left-over. Since debian/rules clean is always called before a source package is built, those generated files are not included as changes compared to what upstream provided.
A common work-around: always build from a clean state
As you have noted, the problem only happens when you build (source and binaries) twice in a row in the same tree. Some VCS-helper tools always build the Debian package in a temporary tree which is exported from the VCS. This is the case of svn-buildpackage by default and of git-buildpackage if you use its --git-export-dir option.
I don t like this solution because it solves the problem only for the maintainer. Anyone else who is working on top of the package without using the same VCS-helper tool would be affected by the problem.
A new way to avoid the problem
Since it s now possible to store dpkg-source options in the source package itself, we can conveniently have everybody use the --extend-diff-ignore option. It tells dpkg-source to ignore some files when checking whether we have made changes to upstream files.
For example if you want to ignore changes made on the files config.sub , config.guess and Makefile you could put this in debian/source/options:
# Don't store changes on autogenerated files extend-diff-ignore = "(^ /)(config\.sub config\.guess Makefile)$"You need to know a bit about Perl regular expressions since that s what is used by dpkg-source to match the filenames to exclude. Note that this approach always works, even when you can t remove the file. So it saves you having to make a backup of the unmodified file just to be able to restore it before the next build.
Found it useful? Be sure to not miss other packaging tips (or lessons), click here to subscribe to my free newsletter and get new articles by email.
No comment Liked this article? Click here. My blog is Flattr-enabled.
The bug webinterface of the
Ultimate Debian Database
currently knows about the following release critical bugs:
| In Total: | 575 |
|---|---|
| Affecting Squeeze: | 14 |
| Squeeze only: | 6 |
| Remaining to be fixed in Squeeze: | 8 |
| Pending in Squeeze: | 1 |
|---|---|
| Patched in Squeeze: | 0 |
| Duplicates in Squeeze: | 0 |
| Can be fixed in a security Update: | 2 |
| Contrib or non-free in Squeeze: | 0 |
| Claimed in Squeeze: | 0 |
| Delayed in Squeeze: | 0 |
| Otherwise fixed in Squeeze: | 0 |
Squeezereleased. However, with the view of the Release Managers, 9 need to be dealt with for the release to happen. Please see
Interpreting the release critical bug statisticsfor an explanation of the different numbers.
Like last year, here s a list of Debian related projects that I d like to tackle this year. I might not do them all, but I like to write them down, I am more productive when I have concrete objectives.
6 comments Liked this article? Click here. My blog is Flattr-enabled.
In its Fast distributions and slow servers article, Joe Zonker Brockmeier explains the difficulties that Fedora has to use its own distribution on their infrastructure and echoes some questions they faced:
Why wouldn t a Linux distribution project wish to showcase the distribution by hosting its infrastructure using its own system?I completely share the underlying assumption. Eating its own dog food is very important if you want to build a Linux distribution and claim with some confidence that it s of quality and usable. Debian does quite well nowadays in that respect. There were times where the mailing list server was using Qmail (non-free at that time, and thus not part of Debian) but that s long gone. We have also seen our build infrastructure relying on software that was not public and not packaged in Debian, but that also is history. The Debian System Administration team (DSA) maintains more than 140 servers running Debian. They mostly run the stable version of Debian but a few test machines are already running Squeeze since a few months (qa.debian.org for example). The Debian admins want to ensure that the next stable release of Debian still has everything they need and that the software they use still work as expected. Big kudos to the DSA team for this choice! I hope we ll be able to continue to live up to those standards for a long time to come. PS: If you want to learn more about the setup that the DSA team uses, head to dsa.debian.org. You ll find all their repositories and some of their internal documentation.
Subscribe to this blog by RSS, by email or on Facebook.
12 comments Liked this article? Click here. My blog is Flattr-enabled.
First day of Hackweek 6 is almost over and my progress is quite good so far. The first step wat to make Gammu connect to the Series60 applet and retrieve basic information:
$ ./gammu/gammu identify
Device : 5C:57:C8:xx:xx:xx
Manufacturer : Nokia
Model : E52 (RM-469)
Firmware : 3.0
IMEI : 359000000000000
That was pretty easy. If you want to try it, you need to install Series60 applet into phone (manually for now, but autoinstallation is planned for future) and configure gammu to talk to it:
[gammu]
connection = blues60
device = 5C:57:C8:xx:xx:xx
Second thing I choose to implement was manipulation with contacts. There are some oddities in the applet (like it simply crashes when giving it wrong contact ID to retrieve), which I will try to fix in future, but for now I stick with existing applet and code functionality only in Gammu. And it works:
$ ./gammu/gammu getmemory ME 215
Memory ME, Location 215
Last name : "Gammu"
First name : "Test"
Mobile number : "123456"
General number : [home]"654321"
Email address 1 : "gammu-users@lists.sourceforge.net"
0 entries empty, 1 entries filled
Tomorrow I should be able to implement calendar, let's see how will it go.
PS: All code is is available in our Git repository
Filed under: English Gammu Suse 0 comments Flattr this!
The CRANberries
service (which reports on new and updated
CRAN
packages for the
R language and environment) is now
tweeting about new packages. Simply follow @CRANberriesFeed to
receive theses messages.
For the technically minded, adding this to the existing 200-line program which runs all of
CRANberries
was very easy.
CRANberries
relies only on
R itself and a few Unix tools like
diffstat as well as the
simple blosxom txt-to-html/rss 'blog compiler'.
The tweeting itself is now done by this new function
which simply pipes the message in Greg KH's bti program (which is now a new dependency). Special thanks to its Debian maintainer Gregor Herrmann for some helpful emails; I am using the newest release 0.29 which itself needs liboauth0. Once OAuth tokens are set-up (and see here for how to do that) all we need is the three-liner above. At this point I am not too sure what to do about updated packages. One message per updated package seems too noisy. To be seen---comments or suggestions welcome.tweetNewBlogEntry <- function(curPkg, curVer, reposurl) ## tests reveal that pipe(), cat(), close() is easiest ## to send multiple messages, may need --background option con <- pipe("bti --config bti.conf", "w") cat("New CRAN package", curPkg, "with initial version", curVer, " http://goo.gl/pgljT\n", file=con) close(con)
Yesterday afternoon, I was at the first OrgCamp in Paris. It was my first
attendance to a BarCamp, and I really liked it. It's basically the first
geek event I do not find boring nor useless.
There was about 18-20 persons participating, which was quite high, since we
all initially though we would have been only 5.
We had several presentations of various features and personal usages of
Org-mode. For my part, I've quickly presented the agenda, and my BBDB
replacement named org-contacts (I'll probably talk about it on this blog in
another post later).
The only downside was that Bastien (the new Org-mode maintainer) was not
able to come and join us. On the other side, there were so much to tell for
a first time, I did not have so much time to code. I only have been able to
fix one bug reported during my agenda presentation.
In the end, the overall atmosphere was very enthusiastic and friendly, which
was extremely pleasant. The #org-mode-fr IRC channel has been created on
Freenode, following this event. Feel free to join us.
Since people liked it so badly, it seems there should be another barcamp in
the next months. Stay tuned.
[patches in $DISTRO] link to the PTSgit clone git://git.debian.org/users/enrico/distromatch.git
cd distromatch
# Careful: 90Mb
wget http://people.debian.org/~enrico/dist-info.tar.gz
tar zxf dist-info.tar.gz
# Takes a long time to do the indexing
./distromatch --reindex --verbose
Then you can query it this way:
./distromatch $DISTRO $PKGNAME [$PKGNAME1 ...]
This would give you, for the package $PKGNAME in $DISTRO, the corresponding
package names in all other distros for which we have data. If you do not
provide package names, it automatically shows output for all packages in
$DISTRO.
For example:
$ time ./distromatch debian libdigest-sha1-perl
debian:libdigest-sha1-perl fedora:perl-Digest-SHA1
debian:libdigest-sha1-perl mandriva:perl-Digest-SHA1
debian:libdigest-sha1-perl suse:perl-Digest-SHA1
real 0m0.073s
user 0m0.056s
sys 0m0.016s
Yes it's quick. It builds a Xapian index with the
information it needs, and then it reuses it. As soon as I find a moment, I
intend to deploy an instance of it on DDE.
It is using a range of different heuristics:
$ ls -l dist-debian/
total 39688
-rw-r--r-- 1 enrico enrico 1688249 Jan 20 17:37 binsrc
drwxr-xr-x 2 enrico enrico 4096 Jan 21 19:12 db
-rw-r--r-- 1 enrico enrico 29960406 Jan 21 10:02 files.gz
-rw-r--r-- 1 enrico enrico 8914771 Jan 21 18:39 interesting-files
$ head dist-debian/binsrc
openoffice.org-dev openoffice.org
ext4-modules-2.6.32-5-4kc-malta-di linux-kernel-di-mipsel-2.6
linux-headers-2.6.30-2-common linux-2.6
libnspr4 nspr
ipfm ipfm
libforks-perl libforks-perl
med-physics debian-med
libntfs-3g-dev ntfs-3g
libguppi16 guppi
selinux selinux
$ zcat dist-debian/files.gz head
memstat etc/memstat.conf
memstat usr/bin/memstat
memstat usr/share/doc/memstat/changelog.gz
memstat usr/share/doc/memstat/copyright
memstat usr/share/doc/memstat/memstat-tutorial.txt.gz
memstat usr/share/man/man1/memstat.1.gz
libdirectfb-dev usr/bin/directfb-config
libdirectfb-dev usr/bin/directfb-csource
libdirectfb-dev usr/include/directfb-internal/core/clipboard.h
libdirectfb-dev usr/include/directfb-internal/core/colorhash.h
interesting-files and db are generated when indexing.
To prove the usefulness of the idea (but does it need proving?), you can find
in the same git repo a little example app (it took me 10 minutes to write it),
that uses the distromatch engine to export Debtags tags to other distributions:
$ ./exportdebtags fedora head
memstat: admin::benchmarking, interface::commandline, role::program, use::monitor
libdirectfb-dev: devel::lang:c, devel::library, implemented-in::c, interface::framebuffer, role::devel-lib
libkonqsidebarplugin4a: implemented-in::c++, role::shared-lib, suite::kde, uitoolkit::qt
libemail-simple-perl: devel::lang:perl, devel::library, implemented-in::perl, role::devel-lib, role::shared-lib, works-with::mail
libpoe-component-pluggable-perl: devel::lang:perl, devel::library, implemented-in::perl, role::shared-lib
manpages-ja: culture::japanese, made-of::man, role::documentation
libhippocanvas-dev: devel::library, qa::low-popcon, role::devel-lib
libexpat-ocaml-dev: devel::lang:ocaml, devel::library, implemented-in::c, implemented-in::ocaml, role::devel-lib, works-with-format::xml
libgnutls-dev: devel::library, role::devel-lib, suite::gnu
Just in case this made you itch to play with Debtags in a non-Debian
distribution, I've generated the full datasets for
Fedora,
Mandriva and
OpenSUSE.
Others have been working on the same matching problem. After we started writing
code we started to become aware of existing work:

Michael and his daughter Marie
import apt cache = apt.Cache() cache["update-manager"].mark_install() cache.commit()
4 comments Liked this article? Click here. My blog is Flattr-enabled.
The bug webinterface of the
Ultimate Debian Database
currently knows about the following release critical bugs:
| In Total: | 575 |
|---|---|
| Affecting Squeeze: | 25 |
| Squeeze only: | 10 |
| Remaining to be fixed in Squeeze: | 15 |
| Pending in Squeeze: | 0 |
|---|---|
| Patched in Squeeze: | 7 |
| Duplicates in Squeeze: | 2 |
| Can be fixed in a security Update: | 1 |
| Contrib or non-free in Squeeze: | 0 |
| Claimed in Squeeze: | 0 |
| Delayed in Squeeze: | 0 |
| Otherwise fixed in Squeeze: | 6 |
Squeezereleased. However, with the view of the Release Managers, 21 need to be dealt with for the release to happen. Please see
Interpreting the release critical bug statisticsfor an explanation of the different numbers.
tar -cpf - /usr/bin tar -xvpf - -C /mnt/testfs| Test | ext4 | S3QL | SDFS | zfs-fuse |
|---|---|---|---|---|
| First copy | 1.59s | 6m20s | 2m2s | 0m25s |
| Sync/Flush | 8.0s | 1m1s | 0s | 0s |
| Second copy+sync | N/A | 0m48s | 1m48s | 0m24s |
| Disk usage after 1st copy | 516MB | 156MB | 791MB | 201MB |
| Disk usage after 2nd copy | N/A | 157MB | 823MB | 208MB |
| Make tarball | 0.2s | 1m1s | 2m22s | 0m54s |
| Max RAM usage | N/A | 150MB | 350MB | 153MB |
| Compression | none | lzma | none | gzip-2 |
Next.