Richi’s post about the pdiff-by-default agony resonates with me a lot.
On EVERY Debian installation I have ever done in the last few years, without any exceptions, I have turned off pdiffs. Even on all the oddball cases (Raspberry Pi, account on a remote machine, …) where I don’t run my install-configs script, I have ended up turning off pdiffs eventually, because it is just so insanely slow on modern internet connections. And by modern I mean even the DSL link my parents’ place has since 14 years.
Let’s disable pdiffs by default already.
Thanks to Axel Beckert (abe@), 12 people interested in Debian met last Tuesday in Zürich and celebrated the start of our monthly Debian meetup.
New faces are always very welcome. If you live in Zürich, or if you’re visiting, please feel free to attend our meetup — no registration necessary.
See the initial announcement, and subscribe to email@example.com for updates.
Thanks to everyone for the nice evening, see you next time!
During DebConf, Asheesh presented the idea of using git instead of the file system for storing the contents of Debian Code Search. The hope was that it would lead to fewer disk seeks and less data due to gits delta-encoding. Maybe the reduction would be big enough that enough data could be held in RAM to allow for fast retrieval.
Joey Hess helped me out with a couple of details: he revealed that using
git repack -a -d will lead to a single packfile that optimally
contains HEAD, not caring about the history. Also, he showed me how to use
git cat-file. We did a small-scale experiment and the results were
promising. I told him I’ll do the experiment of just committing the entire
unpacked source mirror to git and promised to follow up with the results, so
stapelberg@couper ~/unpacked master $ time cat <<EOT | git cat-file --batch >/dev/null :linux_3.2.32-1/sound/pci/ice1712/aureon.c :linux_3.2.32-1/sound/soc/codecs/sgtl5000.c :linux_3.2.32-1/sound/pci/hda/patch_conexant.c EOT cat <<<'' 0,00s user 0,00s system 62% cpu 0,006 total git cat-file --batch > /dev/null 4,38s user 1,08s system 99% cpu 5,477 total stapelberg@couper ~/unpacked master $ time cat linux_3.2.32-1/sound/pci/ice1712/aureon.c linux_3.2.32-1/sound/soc/codecs/sgtl5000.c linux_3.2.32-1/sound/pci/hda/patch_conexant.c >/dev/null cat linux_3.2.32-1/sound/pci/ice1712/aureon.c > /dev/null 0,00s user 0,00s system 69% cpu 0,006 total stapelberg@couper ~/unpacked master $ time cat <<EOT | git cat-file --batch >/dev/null :i3-wm_4.6-1/libi3/font.c EOT cat <<<':i3-wm_4.6-1/libi3/font.c' 0,00s user 0,00s system 51% cpu 0,008 total git cat-file --batch > /dev/null 4,30s user 1,18s system 99% cpu 5,533 total stapelberg@couper ~/unpacked master $ time cat i3-wm_4.6-1/libi3/font.c >/dev/null cat i3-wm_4.6-1/libi3/font.c > /dev/null 0,00s user 0,00s system 0% cpu 0,004 total
Even after repeating those tests a couple of times to get a warm page cache, the result stays the same: git takes about 5 seconds to resolve the deltas in a large repository. Even if this was 5 seconds startup time and a very small amount of additional time per file, it would not be acceptable for our use case.
The conclusion is that git is clearly not suitable for this kind of usage,
which is not surprising after having heard a couple of times that git does not
scale :-). For the curious, the
.git/objects directory is 29 GiB
for roughly 140 GiB of source code, so the delta encoding is quite impressive
in terms of saving space. However, keep in mind that the compressed (!) Debian
source archive is about 35 GiB, so the savings are not that huge.
I gave two talks at this year’s DebConf, both about systemd. A huge thanks goes to the video team for their excellent work and putting up the videos that quickly! Find the recordings and slides here:
I will arrive at DebConf 2013 on Sunday afternoon. In case you are interested in Go (the programming language), systemd, i3 or getting your package reviewed, please talk to me! :-)
Looking forward to meeting many of you in real life.
Good news, everyone! dh-golang is now in Debian unstable. With this debhelper addon, packaging software written in Go is very simple.
Have a look at the
example/ directory in dh-golang to see how it is meant to be used.
Essentially, export the DH_GOPKG variable containing the canonical upstream
location of the package (e.g. github.com/stapelberg/godebiancontrol)
and then use
dh $@ --buildsystem=golang --with=golang. That’s it!
Now, given that this package is very new and only two packages use it so far (both of which are not yet in Debian, but real soon™), there are most likely bugs and missing features. This is where you come in: when packaging software written in Go, please contact me and tell me whether dh-golang worked for you and what could be improved. In case something does not work, definitely report it. Even if everything worked, I’d be happy to have a look at your packaging before you upload.
Also see https://wiki.debian.org/MichaelStapelberg/GoPackaging.
Posting this on behalf of a friend of mine in the hope that you can help:
I’ve failed several times now to find a suitable WLAN USB dongle that works out of the box on Debian testing. Often manufacturers change the chipsets without changing the version numbers, the product pages are incomplete or even state wrong information.
I turn to you, in the hopes that someone can give me helpful pointers. The dongle should have:
If you have any hints, please send them directly to breunig AT uni-hd DOT de. Thanks!
As of today, systemd 204 is available in Debian experimental. If you are interested in systemd, please install it and report any issues to the BTS — merely reporting them on IRC is not sufficient, we need to have them in the BTS so we don’t forget about them.
In case you’ve been using the unofficial 204 packages from http://people.debian.org/~biebl/systemd, please downgrade first to systemd 44-12 and udev 175-7.2, then upgrade to the versions in Debian experimental. This will ensure that during the upgrade all obsolete conffiles are upgraded properly.
Thanks for helping with testing!
Sometimes, people show up in our IRC channel #debian-systemd or on our mailing list firstname.lastname@example.org and ask how they can help. This blog post answers that question.
First of all, whatever you end up doing, please coordinate with us first! Saying hi in our IRC channel or on our mailing list and explaining what you intend to do is all we ask for. In the past, people have filed bug reports with service files that are not idiomatic, and we really need to avoid that.
Currently, our biggest task is to add/improve systemd support to individual Debian packages, and this is where we can use a lot of help.
We have a dashboard which contains two lists:
After you picked a service from the second list in our dashboard, first double-check that there is no bug filed against it yet (the dashboard might be a few hours behind).
Then, search for a service file, either upstream or in other distributions such as Arch Linux, Fedora, Gentoo, etc. In case there is no service file yet, write one. Please carefully test the service file (e.g. does starting/stopping/restarting and reloading work) and send it to us for review.
Be careful to avoid obvious regressions from the sysvinit init script. That is, don’t just write a very simplistic service file that breaks a use-case which formerly worked. If in doubt, ask pkg-systemd-maintainers or chose a different package to work on.
Afterwards, add systemd support by using the dh-systemd helper, see https://wiki.debian.org/Systemd/Packaging.
The last step is to file a proper bug report against the package that uses our usertag and CCs pkg-systemd-maintainers. See http://bugs.debian.org/714190 for an example.
Check if the package currently has any direct systemctl calls in its maintscripts and remove them if so (see http://bugs.debian.org/713853 for an example).
Follow https://wiki.debian.org/Systemd/Packaging to add systemd support using the dh-systemd helper.
Check whether the maintscripts look good and generate a debdiff to highlight the differences between the old and the new version:
debdiff --controlfiles=ALL OLD_amd64.changes NEW_amd64.changes
Then file a bug report which uses our usertag and CCs pkg-systemd-maintainers. See http://bugs.debian.org/713853 for an example.
Thank you for helping us and Debian in general!
The German computer magazine c't has covered Debsources in its most recent edition (c't 16/2013). In that article, they also state:
Debsources integriert auch eine Code-Suche, allerdings werden lediglich die Quellen des Unstable-Zweigs durchsucht, der zirka ein Drittel des Quellcodes von Debsources ausmacht.
This loosely translates to:
Debsources also integrates a code search engine, but it only searches the sources of the unstable tree, which makes up for roughly one third of the sources that Debsources covers.
I suspect the author of the article arrived at this conclusion because Debsources talks about 400 GiB of source code, whereas Debian Code Search talks about 130 GiB of source code.
However, it still struck me as odd and giving the wrong impression. I thought
that packages don’t differ that much between stable, testing and unstable. So I
psql and pounded UDD
until it revealed how many packages are different between stable, testing and
So, in conclusion, Debian Code Search covers 74% of wheezy, testing and unstable. Debsources also covers contrib and non-free, which explains the higher disk usage. In particular, there might be big blobs in non-free that account for a lot of disk space. Also, Debsources keeps sources around for a few weeks whereas Debian Code Search only keeps the most recent snapshot.
SELECT COUNT(*) FROM (SELECT migrations.source, sources.version AS stable_version, testing_version, unstable_version FROM sources LEFT JOIN migrations USING (source) WHERE sources.release = 'wheezy') AS x WHERE regexp_replace(stable_version::text, E'-([0-9.]+)$', '') = regexp_replace(testing_version::text, E'-([0-9.]+)$', '');