APT for package self-builders

One of the main jobs of a package manager like apt is to download packages (ideally in a secure way) from a repository so that they can be processed further – usually installed. FSVO "normal user" this is all there ever is to it in terms of getting packages.

Package maintainers and other users rolling their own binary packages on the other hand tend to have the packages they want to install and/or play-test with already on their disk. For them, it seems like an additional hassle to push their packages to a (temporary) repository, so apt can download data from there again… for the love of supercow, there must be a better way… right?

For the sake of a common start lets say I want to modify (and later upload) hello, so I acquire the source via apt source hello. Friendly as apt is it ran dpkg-source for me already, so I have (at the time of writing) the files hello_2.10.orig.tar.gz, hello_2.10-1.debian.tar.xz and hello_2.10-1.dsc in my working directory as well as the extracted tarballs in the subdirectory hello-2.10.

Anything slightly more complex than hello probably has a bunch of build-dependencies, so what I should do next is install build-dependencies: Everyone knows apt build-dep hello and that works in this case, but given that you have a dsc file we could just as well use that and free us from our reliance on the online repository: apt build-dep ./hello_2.10-1.dsc. We still depend on having a source package built previously this way… but wait! We have the source tree and this includes the debian/control file so… apt build-dep ./hello-2.10 – the later is especially handy if you happen to add additional build-dependencies while hacking on your hello.

So now that we can build the package have fun hacking on it! You probably have your preferred way of building packages, but for simplicity lets just continue using apt for now: apt source hello -b. If all worked out well we should have now (if you are on a amd64 machine) also a hello_2.10-1_amd64.changes file as well as two binary packages named hello_2.10-1_amd64.deb and hello-dbgsym_2.10-1_amd64.deb (you will also get a hello_2.10-1_amd64.buildinfo which you can hang onto, but apt has currently no way of making use of it, so I ignore it for the moment).

Everyone should know by now that you can install a deb via apt install ./hello_2.10-1_amd64.deb but that quickly gets boring with increasing numbers, especially if the packages you want to install have tight relations. So feel free to install all debs included in a changes file with apt install ./hello_2.10-1_amd64.changes.

So far so good, but all might be a bit much. What about install only some debs of a changes file? Here it gets interesting as if you play your cards right you can test upgrades this way as well. So lets add a temporary source of metadata (and packages) – but before you get your preferred repository builder setup and your text editor ready: You just have to add an option to your apt call. Coming back to our last example of installing packages via a changes file, lets say we just want to install hello and not hello-dbgsym: apt install --with-source ./hello_2.10-1_amd64.changes hello.

That will install hello just fine, but if you happen to have hello installed already… apt is going to tell you it has already the latest version installed. You can look at this situation e.g. with apt policy --with-source ./hello_2.10-1_amd64.changes hello. See, the Debian repository ships a binary-only rebuild as 2.10-1+b1 at the moment, which is a higher version than the one we have locally build. Your usual apt-knowledge will tell you that you can force apt to install your hello with apt install --with-source ./hello_2.10-1_amd64.changes hello=2.10-1 but that isn't why I went down this path: As you have seen now metadata inserted via --with-source participates as usual in the candidate selection process, so you can actually perform upgrade tests this way: apt upgrade --with-source ./hello_2.10-1_amd64.changes (or full-upgrade).

The hello example reaches its limits here, but if you consider time travel a possibility we will jump back into a time in which hello-debhelper existed. To be exact: Right to the moment its maintainer wanted to rename hello-debhelper to hello. Most people consider package renames hard. You need to get file overrides and maintainerscripts just right, but at least with figuring out the right dependency relations apt can help you a bit. How you can feed in changes files we have already seen, so lets imagine you deal with with multiple packages from different sources – or just want to iterate quickly! In that case you want to create a Packages file which you would normally find in a repository. You can write those by hand of course, but its probably easier to just call dpkg-scanpackages . > Packages (if you have dpkg-dev installed) or apt-ftparchive packages . > Packages (available via apt-utils) – they behave slightly different, but for our proposes its all the same. Either way, ending up with a Packages file nets you another file you can feed to --with-source (sorry, you can't install a Packages file). This also allows you to edit the dependency relations of multiple packages in a single file without constant "fiddle and build" loops of the included packages – just make sure to run as non-root & in simulation mode (-s) only or you will make dpkg (and in turn apt) very sad.

Of course upgrade testing is only complete if you can influence what is installed on your system before you try to upgrade easily. You can with apt install --with-source ./Packages hello=2.10-1 -s -o Dir::state::status=/dev/null (it will look like nothing is installed) or feed a self-crafted file (or some compressed /var/backups/dpkg.status file from days past), but to be fair that gets a bit fiddly, so at some point its probably easier to write an integration test for apt which are just little shellscript in which (nearly) everything is possible, but that might be the topic of another post some day.

Q: How long do I have to wait to use this?

A: I think I have implemented the later parts of this in the 1.3 series. Earlier parts are in starting with 1.0. Debian stable (stretch) has the 1.4 series, so… you can use it now. Otherwise use your preferred package manager to upgrade your system to latest stable release. I hope it is clear which package manager that should be… 😉︎

Q: Does this only work with apt?

A: This works just the same with apt-cache (where the --with-source option is documented in the manpage btw) and apt-get. Everything else using libapt (so aptitude included) does not at the moment, but potentially can and probably will in the future. If you feel like typing a little bit more you can at least replicate the --with-source examples by using the underlying generic option: aptitude install -s hello-dbgsym -o APT::Sources::With::=./hello_2.10-1_amd64.changes (That is all you really need anyhow, the rest is syntactic sugar). Before you start running off to report bugs: Check before reporting duplicates (and don't forget to attach patches)!

Q: Why are you always typing ./packages.deb?

A: With the --with-source option the ./ is not needed actually, but for consistency I wrote it everywhere. In the first examples we need it as apt needs to know somehow if the string it sees here is a package name, a glob, a regex, a task, … or a filename. The string "package.deb" could be a regex after all. And any string could be a directory name… Combine this with picking up files and directories in the current directory and you would have a potential security risk looming here if you start apt in /tmp (No worries, we hadn't realized this from the start either).

Q: But, but, but … security anyone?!?

The files are on your disk and apt expects that you have verified that they aren't some system-devouring malware. How should apt verify that after all as there is no trustpath. So don't think that downloading a random deb suddently became a safe thing to do because you used apt instead of dpkg -i. If the dsc or changes files you use are signed and you verfied them through, you can rest assured that apt is verifying that the hashes mentioned in those files apply to the files they index. Doesn't help you at all if the files are unsigned or other users are able to modify the files after you verified them, but apt will check hashes in those cases anyhow.

Q: I ❤︎ u, 🍑︎ tl;dr

Just 🏃︎ those, you might 😍︎ some of them:

apt source hello
apt build-dep ./hello-*/ -s
apt source -b hello
apt install ./hello_*.deb -s
apt install ./hello_*.changes -s
apt install --with-source ./hello_*.changes hello -s
apt-ftparchive packages . > ./Packages
apt upgrade --with-source ./Packages -s

P.S.: If you have expected this post to be published sometime inbetween the last two months… welcome to the club! I thought I would do it, too. Lets see how long I will need for the next one… I have it partly written already, but that was the case for this one as well… we will see.

APT for DPL Candidates

Today is a special day for apt: 20 years ago after much discussion in the team as well as in the Debian project at large "APT" was born.

What happened in all these years? A lot! But if there is one common theme then it is that many useful APT features, tricks and changes are not as known to the general public or even most Debian Developers as they should be.

A few postings are unlikely to change that, but I will try anyhow and this post is the start of a mini-series of "APT for …" articles showing off things: For the first installment I want to show nothing less but the longest running vote-rigging scheme in the known free (software) world. But lets start from the beginning:

Humans pride themselves having evolved over simple animals following their instincts by having a mind of their own to form decisions. On this concept, humans hold votes to agree upon stuff, including the Debian Project Leader for the next year.

DPL candidates are encouraged to provide a platform and a discussion between the candidates and the voters ensures that everyone can form a well informed opinion on the candidates in question and based on this information choose a candidate with their own free will.

Or, That is at least the theory Debian Developers want to believe in.

The following table tallies each leader vote since 1999 with the information if the candidate (68 over all, 37 unique) had contributed to APT (31/13), dpkg (29/17) or both (18/9) for cases I could identify (if I missed anything feel free to get in touch). The candidate in bold has won the election in the given year, candidates in italics won a later election:

Year Candidate APT? dpkg?
1999 Joseph Carter no no
Ben Collins no1 yes
Wichert Akkerman no yes
Richard Braakman no yes
2000 Ben Collins no1 yes
Wichert Akkerman no yes
Joel Klecker no yes
Matthew Vernon no yes
2001 Branden Robinson yes2 yes
Anand Kumria no yes
Ben Collins yes1 yes
Bdale Garbee yes3 no
2002 Branden Robinson yes2 yes
Raphaël Hertzog yes4 yes
Bdale Garbee yes3 no
2003 Moshe Zadka no no
Bdale Garbee yes3 no
Branden Robinson yes2 yes
Martin Michlmayr yes5 no
2004 Martin Michlmayr yes5 no
Gergely Nagy no no
Branden Robinson yes2 yes
2005 Matthew Garrett no no
Andreas Schuldei no yes
Angus Lees no no
Anthony Towns yes6 yes
Jonathan Walther no no
Branden Robinson yes2 yes
2006 Jeroen van Wolffelaar yes7 yes
Ari Pollak no no
Steve McIntyre yes8 no
Anthony Towns yes6 yes
Andreas Schuldei no yes
Jonathan (Ted) Walther no no
Bill Allombert no yes
2007 Wouter Verhelst no no
Aigars Mahinovs no no
Gustavo Franco no no
Sam Hocevar yes10 yes
Steve McIntyre yes8 no
Raphaël Hertzog yes4 yes
Anthony Towns yes6 yes
Simon Richter yes9 yes
2008 Marc Brockschmidt no no
Raphaël Hertzog yes4 yes
Steve McIntyre yes8 no
2009 Stefano Zacchiroli yes11 no
Steve McIntyre yes8 no
2010 Stefano Zacchiroli yes11 no
Wouter Verhelst no no
Charles Plessy yes12 yes
Margarita Manterola no yes
2011 Stefano Zacchiroli yes11 no
2012 Wouter Verhelst no no
Gergely Nagy no no
Stefano Zacchiroli yes11 no
2013 Gergely Nagy no no
Moray Allan no no
Lucas Nussbaum no no
2014 Lucas Nussbaum no no
Neil McGovern no no
2015 Mehdi Dogguy no no
Gergely Nagy no no
Neil McGovern no no
2016 Mehdi Dogguy no no
2017 Mehdi Dogguy no no
Chris Lamb yes13 yes
2018 Chris Lamb14 yes13 yes

We can see directly that until recently it was nearly mandatory to have contributed to apt or dpkg to be accepted as a DPL candidate. The recent no streak before Chris entered the table gets doubly weird if we factor in that I joined Debian and the APT project around 2009… We might get to the bottom of this coincident in the future, but for now lets get back to the topic at hand:

DDs have no free will

It is hard to accept for a human, but the table above shows that DDs aren't as free in their choice as they think they are; they follow a simple rule:

If at least one of the candidates contributed to APT, an APT contributor wins the election.

You can read this directly from the table above (20 votes total, including 6 votes without an apt candidate). Interestingly, the same rule for dpkg does not hold at all. In fact there are years in which the defining difference for the winning candidate is that he15 hasn't contributed to dpkg but only to apt (e.g. 2002).

Praying via bugreports and sacrifices in the form of patches in the Pantheon of the Supercow, the deity@ mailinglist, can have profound effects: Take the very first elections as an example: After being an unsuccessful candidate in 1999 and 2000, candidate Ben implemented the rsh transport method for apt and as a result became DPL in 2001.

And as if that wouldn't be enough, being on good terms with Supercow has additional benefits:

Contribution beats Re-Election

While it seems like DPLs are granted a second term if they wish the recent 2017 election shows that contributing to APT is stronger. Two other non-re-elections are on record: In 2003 where the bugreporter Bdale lost against the patchprovider Martin, so contribution size and recency seem to play a role as well, but that might not be everything there is to infights between contributors as shown in 2007 where Anthony lost against Sam in the biggest vote so far with 5 out of 8 candidates supported by apt (including the present and future DPL in this year).

The "Super" rubs of on the DPL

Many DPLs run for two terms, but only a single one managed to run a third time: After unsuccessful campaigning in 2009 Stefano not only worked on apt in 2010 and the following year(s) but also consulted with a certain highpriest of the Supercow netting a record three-year stint as DPL as a result.

It is to be seen if intercession of a highpriest is needed for long DPL terms, but it certainly doesn't hurt – and I make myself of course selflessly available (for a reasonable monetary offering) as said highpriest should a DPL (candidate) be in need of my divine bovine help (again)…

Every contribution matters – for real!

No contribution is too small, everything counts & supercow sees everything. Even "just" downgrading the severity of a bug counts10. Supercow values all contributors: Join their rank today and win the next DPL election in 2019!

Of course, supercow likes big and groundbreaking patches as much as the next project, but while other projects are just talking about how they like testers, bugreporters, translators and documentation improvers we in the apt project have the election-rigging data of 20 years to proof it! Supercow really cares for its contributors!

So to all past, present and future DPL candidates: Thanks for your contributions to APT (and Debian)!

That… this… what the f…edora?!?

Look at the calendar: Its not only easter sunday, its also the beginning of voting period for DPL 2018. What better day would there be for some fun about humans, genesis, elections and the 20th birthday of apt.

I promise that future installments in the series will be more practically useful but until then enjoy the festive days (if applicable) around apts birthday, have fun, take care and make sure to contribute to apt!


  1. Contributed the RSH/SSH method in 2000. Won the following election after two unsuccessful rounds. 

  2. Credited in AUTHORS for "Man Page Documentation" 

  3. Early tester as shown in e.g. #45050 

  4. Bugreporter and provider of draft patch, e.g. #793360 

  5. Bugreporter and patch provider, e.g. #417090 

  6. Multiple patches over the years since 2005 including the latest reimplementation of rred 

  7. Bugreporter and patch provider: #384182 

  8. Bugreporter and tester, e.g. #218995 

  9. Bugreporter, tester and patch provider, e.g. #509866 

  10. RC bug triager, e.g. #454666 

  11. Multiple bugreports and patches, including pushing & documenting EDSP 

  12. Documentation patches, e.g. #619088 

  13. Tester and patch provider, e.g. #848721 

  14. The vote hasn't happened yet, but NOTA is by definition not an apt contributor and hence can't win as outlined in this post. 

  15. To this day Debian had no DPL for which "he" does not apply. With this information, you might be able to change this in future elections! 

Winning the Google Open Source Lottery

I don't know about you, but I frequently get mails announcing that I was picked as the lucky winner of a lottery, compensation program or simply as "business associate". Obvious Spam of course, that never happens in reality. Just like my personal "favorite" at the moment: Mails notifying me of inheritance from a previously (more or less) unknown relative. Its just that this is what has happend basically a few weeks ago in reality to me (over the phone through) – and I am still dealing with the bureaucracy required of teaching everyone that I had absolutely no contact in the last two decades with the person for which I am supposed to be one of the legal successors now, regardless of how close the family relation is on paper… but that might be the topic of another day.

On the 1st March a mail titled "Google Open Source Peer Bonus Program" looked at first as if it would fall into this lottery spam class. It didn't exactly help that the mail was multipart HTML and text, but the text really only the text, not mentioning the embedded links used in the HTML part. It even included a prominent and obvious red flag: "Please fill out the form". 20% Bayes score didn't come from nothing. Still, for better or worse the words "Open Source" made it unlikely to be spam similar to how the word PGP indicates authenticity. So it happened, another spam message became true for me. I wonder which one will be next…

You have probably figured out by now that I didn't know that program before. Kinda embarrassing for a previous Google Summer of Code student (GSoC is run by the same office), but the idea behind it is simple: Google employees can nominate contributors to open source stuff for a small monetary "thank you!" gift card. Earlier this week winners for this round were announced – 52 contributors including yours truly. You might be surprised, but the rational given behind my name is APT (I got a private mail with the full rational from my "patron", just in case you wonder if at least I would know more).

It is funny how a guy who was taken aback by the prospect of needing a package manager like YaST to use Linux contributed just months later the first patch to apt and has roughly 8 years later amassed more than 2400 commits. It's birthday season in my family with e.g. mine just a few days ago, so its seems natural that apt has its own birthday today just as if it would be part of my family: 19th years this little bundle of bugs joy is now! In more sober moments I wonder sometimes how apt and I would have turned out if we hadn't meet. Would apt have met someone else? Would I? Given that I am still the newest team member and only recently joined Debian as DD at all…

APT has some strange ways of showing that it loves you: It e.g. helps users compose mails which end in a dilemma to give a recent example. Perhaps you need to be a special kind of crazy1 to consider this good, but as I see it apt has a big enough userbase that regardless of what your patch is doing, someone will like it. That drastically increases the chances that someone will also like it enough to say so in public – offsetting complains from all those who don't like the (effects of the) patch which are omnipresent. And twice in a blue moon some of those will even step forward and thank you explicitly. Not that it would be necessary, but it is nice anyhow. So, thanks for the love supercow, Google & apt users! 🙂︎

Or in other words: APT might very well be one of the most friendly (package manager related) project to contribute to as the language-specific managers have smaller userbases and hence a smaller chance of having someone liking your work (in public)… so contribute a patch or two and be loved, too! 💖︎

Disclaimer: I get no bonus for posting this nor are any other strings attached. Birthdays are just a good time to reflect. In terms of what I do with my new found riches (in case I really receive them – I haven't yet so that could still be an elaborate scam…): APT is a very humble program, but even it is thinking about moving away from a dev-box with less than 4 GB of RAM and no SSD, so it is happily accepting the gift and expects me to upgrade sooner now. What kind of precedence this sets for the two decades milestone next year? If APT isn't obsolete by then… We will see.

  1. which even ended up topping Hacker News around New Year's Eve… who would have thought that apt and reproducibility bugs are top news ;) 

Switching from ikiwiki to staticsite

Earlier this year Enrico Zini experimented with static site generators and ended up with writing his own in python via component reuse. I was running ikiwiki until now myself, which is okay, but I never became ultra happy with it. One of the factors was that I don't speak Perl – but I don't speak Python either. The biggest annoyance of ikiwiki is that it supports so many many features which I don't want/need like online editing and other changes are very hard to do like working on the theme.

staticsite (aka ssite) on the other hand provides very little in terms of features in comparison, but that just means I had less to disable and could play a bit with python, markdown and jinja2 on my own to implement what I really wanted to have (which mostly isn't available in ikiwiki either, so I would have to anyway) and I like playing with such small features compared to rolling my own static site generator in perfect NIH fashion. So, what features? Thanks for asking!

Tag cloud

ssite supports tags just fine and clouds are a display thing, so that is a matter of the template – or so I thought at least. Counting is a bit hard as reassignments aren't easy and jinja2 tries to print what it can. So what I use at the moment looks like a scary hack, but it seems to work for me for now:

{%- for taxonomy in taxonomies() -%}
<ul class="tags">
  {%- set total_tag_number = [ 0 ] -%}
  {%- for t in taxonomy.items -%}
    {%- if total_tag_number.append(total_tag_number.pop() + 1) -%}{%- endif -%}
  {%- endfor -%}
  {%- for key in taxonomy.items.keys()|sort -%}
    {%- set t = taxonomy.items[key] -%}
<li data-rate="{{((10/total_tag_number[0])*(t.pages|length))|round(0,'ceil')|int}}"><a href="{{url_for_tags(t)}}">{{t.name}}</a></li>
  {%- endfor -%}
{%- endfor -%}

The resulting unordered list can be styled at will with CSS, I opted for changing the font-size based on the data-rate field – manually for now as support for attr() isn't completely there yet – and making the list look less like a list.

ul li[data-rate] a { font-size: 80%; }
ul li[data-rate="1"] a { font-size: 90%; }
ul li[data-rate="2"] a { font-size: 100%; }
ul li[data-rate="3"] a { font-size: 110%; }

ul.tags, ul.tags li {
    list-style-type: none;
    display: inline;
ul.tags li:after { content: ", "; }
ul.tags li:last-child:after { content: ""; }

The result can be seen in the sidebar of this blog. Not completely happy yet, but a good first draft.

Smilies, Emojis, Emoticons and Unicode

ikiwiki has a plugin which uses a markdown list to define which text is mapped to other markdown text (usually an image). That is okayish, but results in a wild mixture of picture styles. It just looks strange if you have a blogpost and one of your smilies has a 3D effect and the other hasn't. Additionally, those are a bunch of small image files… for what is effectively a bit of text – or one (displayed) character: UTF-8 supports all kinds of smilies and other lovely pictures. Or, at least if the font you are using does, but that might be the topic of another post. Assuming good support you can do many cool things with UTF-8. The usual smilies like 🙂︎ 😉︎ 😃︎ 😎︎ the absolutely needed cat variants like 🐱︎ 😸︎ places on a 🗺︎ like the 🗽︎ and of course also various people like 👨︎ 👩︎ 💂︎ 👧︎ and 👦︎ who can travel to those places by 🚗︎ or 🚂︎ And some of those unicodes can be Fitzpatrick-skinned so that 👍︎ becomes 👍‍🏻︎ 👍‍🏼︎ 👍‍🏽︎ 👍‍🏾︎ 👍‍🏿︎ ❣︎

That feature isn't really ssite specific: It is implemented as a simple python-markdown extension replacing things like :) with 🙂︎ – just many many more of those replaces. You would think there are many pre-existing extensions dealing with this, but I couldn't really find one to my liking. Most of them are actually doing the same as the ikiwiki plugin: Mapping text to tiny images: Honorable mention is githubemoji which hotlinks the emojis github supports (& has replacement images for). There are others which do similar (hot)linking of images, but a small supported character range is common and funky stuff like the mentioned fitzpatrick or region letters creating flags ( 🇩︎ + 🇪︎ = 🇩‍🇪︎ ) stuff isn't supported in any. So, you guessed it: I implemented it myself. Partly at least. I am still working on making this great while learning python with it, so that will take some time still as I have basically reimplemented it a few times already… and there is also this problem that support for this isn't even close to be universal so something needs to be done about that, too.

Theme of the site

ssite comes by default with a bootstrap-based theme. That is okay, but that also means it looks like nearly every other page on the planet in terms of colors and stuff. It also means I have to include hundreds of kilobytes of frameworks in CSS and JavaScript (preferably via some CDN) to get that. And then I have to change the HTML to drop classes everywhere which control look and feel of the elements I have styled with them. That is okayish for large projects I guess. I used it myself in the past but perhaps the conversion of bootstrap2 to 3 I did as part of a university project some time ago distorts my feeling in the negative direction. I kinda like fiddling with CSS and Javascript (after all, I created my own Firefox extension to fiddle with them on all sites I visit: dotPageMod) on the other hand this is a personal page I don't have much problem if it isn't working in IE8 or what not, so the theme is a personal creation. Very minimal as I actually liked that property in ikwiki but with less ugly changes in the ikiwiki specific template syntax and more with jinja2 which is its own template syntax, but at least an independent engine used by others as well, so I might stumble over it again and it feels overall more powerful & natural.

So, perhaps not pretty and not a maximum in browser compatibility, but mine and that makes me happy. 😃︎ Various things I want/might change in this section as well, but a website is never really done anyhow… 🚧︎ 👷︎.

anything else?

Not much actually. Enrico implemented a markdown jinja2-filter based on a proof-of-concept patch from me and fixed some bugs I had reported really quickly. All in all the journey so far was quite enjoyable and it will be interesting to see how my impression is next year! As mentioned I have some ideas still, but I wanted to make a cut now and declare it version 1…

Also: One last far well to ikiwiki. I leave you for a younger & prettier alternative, but don't you worry: You served me well (and still do in some places) and there are many others which still depend on you and who knows, perhaps I will leap back if I ever want to get into perl. After all, one of the reasons I opted for ikiwiki back then was that I might learn some perl in the process. Didn't work, but perhaps next time. So long and thanks for all the fish, ikiwiki!

the new apt-transport-tor

It happened: Now that I am an uploading DD for a few months I finally made my first upload of a package – mind you, not of apt, but of a package I declared my intend to "steal" from another person a few weeks ago on deity@ and later also in a bugreport (#835128).

The result is that apt-transport-tor which used to be maintained by Tim Retout as a modified copy of apt code is now maintained by the APT team (with him and me as uploaders) using the apt code directly via a few symlinks.

That brings along a bunch of changes which I mentioned in the list/bug as well, but for completeness:

I had tried a few times to get people to provide feedback, but there wasn't much. I guess this is good as it means nobody has any complains about it. We will see if that will change now that it is on its way to archive, buildds, mirrors and users: Brace for impact in any case!

GSoC 2016: Summary

Intro, Outro and tl;dr

I participated again as a student in this years edition of the Google Summer of Code with Debian on the project APT↔dpkg communication rework. My initial proposal on the wiki details me and the plan, while this post serves as link hub and explanation of what I did. You can also find personal week-to-week posts starting with Day 0 right here on this blog, too.

The code for this project was already merged and uploaded to Debian unstable multiple times over the course of the summer, so everything described here later can be experienced directly. The official GSoC2016 final is 1.3~rc2, but APT always moves forward and I have no intention of leaving it alone, so this tag just marks the end of the GSoC2016 period and my return to "normal" contribution levels.

On a social front I finally applied for and shortly after received "Debian Developer, uploading" status. This is also the moment I want to thank Michael Vogt (mentor, apt), Julian Andres Klode (apt), Manuel A. Fernandez Montecelo (aptitude), Guillem Jover (dpkg), Enrico Zini (AM), the Debian Outreach team and the countless people I should have mentioned here, too, who have all helped me in many ways over the course of this GSoC and my entire Debian journey up to this point.

It was an overall great experience to work again on something as important as APT in Debian on a full-time basis. After two (very different) GSoCs in 2010 and now 2016 I can full heartily recommend to any student with a passion for open-source to apply next year. Perhaps in Debian and maybe in an APT project? We are waiting for YOU!


My first commit as part of GSoC was made on 25. April titled edsp: ask policy engine for the pin of the version directly (minor bugfix), the last commit I will be counting on 17. August titled methods: read config in most to least specific order (regression fix). Not all of them are directly related to the GSoC project itself (the first is), but "just" in the timeframe (like the last) but were handled as part of general emergencies or for similar reasons described later and/or in the weekly reports. This timeframe of 115 days saw a total of 222 commits authored by me + 9 commits committed by me for others (translations, patches, …). The timeframe saw 336 commits as a whole making me responsible for a bit shy of ⅔ of all APT commits in this timeframe with on average of nearly 2 commits each day. A diffstat run over my commits says "322 files changed, 11171 insertions(+), 5847 deletions(-)" consisting of code, documentation and tests (this doesn't include automatic churn like regeneration of po and pot files, which deludes the global statistic). As a special mention our tests alone changed by: "109 files changed, 2759 insertions(+), 1063 deletions(-)". In my weekly reports here on this blog I used ~10574 words (not including this post), another ~23555 words in the IRC channel #debian-apt and sometimes very long mails to deity@ and bugreports (~100 mails) [Not counting private chit-chat with mentor via IRC/mail].

APT External Installation Planner Protocol (EIPP)

The meat of the GSoC project was the ability to let libapt talk to (external) executables (called planners) which are tasked with creating a plan for the installation (and removal) of packages from the system in the order required by their various dependency relations, similar to how libapt can talk to external dependency solvers like aspcud via EDSP. The protocol (current, archive) details how apt and a planner can communicate. APT ships such an external planner already in the form of 'apt' which is "just" using the internal always existing planner implementation, but reads and talks proper EIPP. The major benefit is testing here as it is now possible to generate an EIPP request, feed it to different versions and compare results to find regressions and similar. It also helps in bugreports as such a request is now auto-generated and logged so that it can be easily attached to bugreports and a triager can use that file to reproduce the problem. Previously recreating the system state a user had before the failed upgrade was a very involved, error prune and time consuming task (actually fixing the problem still is, but at least the first step got a lot easier).

APTs good old planner implementation saw also the activation (and fixing) of many previously experimental options intended to optimize the process blocked previously by items of the next paragraph, which makes it look like a new planner now. Entirely new planners exist as prototypes, but they aren't suitable for real use yet due to not handling "edgecases" and being effected by bugs in dpkg. Summary: Everyone can create and work on his own planner in the programming language of choice and run it against realworld cases directly opening a competition space for the invention of future improvements.

APT↔dpkg communication

The other major building block and donor of much of the projects name. Assuming a planner has figured out a plan there is still much left to do which is of no concern for each planner but handled centrally in libapt: The actual calling of dpkg and interpreting its replies. That sounds easy enough, but if you imagine the need of thousand of packages to be installed/configured at once you fear hitting something as barebones as the kernels maximum allowed commandline length. That happened once in a while in the past so finding better solutions to that problem within easy reach (as in: existing in dpkg already, new interfaces for possible future use are a different matter) is in order. Other problems included the overuse of --force options, not communication the purge/removal intentions to dpkg, insufficient crossgrade handling and avoiding losing user configuration on conffile moves involving packages to be purged just to name a few. But also listening to dpkg in terms of how it processes triggers and how all this should be reported in the form of progress reports to the user especially if some steps aren't explicitly planned anymore by a planner, but left to dpkg to do at some point.

The result is mostly invisible to the user, expect that it should all be now slightly faster as e.g. triggers are run less and most "strange" errors a thing of the past.

Side projects, emergency calls and random bufixes

Not actually on my plan for GSoC and at best only marginally related if at all I ended up working on these to deal with important bugs on a "as long as we have a full-time developer" basis.

This includes hunting for strange errors if rred is involved in updating indexes, further preparing for a binary-all future, fixing SRV support, being the master of time, improving security by allowing it to be sidestepped sometimes, improving security by potentially breaking backward-compatibility a bit, stumble into libstdc++6 bugs, implement SOCKS5 proxy support and generic config fallback for acquire methods to be able to propose the mergeback of apt-transport-tor among very many other things.

A complete list can be found with the previously shared git-branch browsing starting at my first commit in the GSoC timeframe (see also statistics above).


I would love to keep working on APT full-time, but that seems rather unrealistic and all good things need to come to an end I guess, so the next weeks will have me adjust to a more "normal" contribution level of "just" in my (extended) free time again. I will also be casually "shopping" for a new money source in the form of a small job while returning to university which hasn't seen a lot of me the last few months and picking up some community work I had delayed for after GSoC. That means I will surely not keep my daily commit average up, but my journey here is far from over:

After many years in APT and Debian there is still something new in it to explore each week as both are evolving continuously – but most of it hidden in plain sight and unnoticed by the general public: Around the start of GSoC I was talking on #gsoc with an admin of another org who couldn't imagine that Debian participated at all as all projects Debian could offer would be bitsized in nature: It is just a distribution, right, not a real org producing value (slightly exaggerated for drama). I would like to concur with this view of course for obvious reasons.

My life would be massively different if I hadn't started to contribute to Debian and APT in particular ~7 years ago – even through I thought I wouldn't be "good enough" back then. I think its fair to say that I showed my past self that in fact I am. Now it is your turn!

Week 16: Constant Optimization

This week saw the release of 1.3~rc1 sporting my tor-changes disguised as general acquire methods changes I mentioned last week as well as the revamp of apt talking to dpkg (and back) I worked on the last couple weeks as part of GSoC. It doesn't include any new planner, a stub is still lying in a wip branch, but our good old planner looks and behaves slight different, so it feels like a new one – and surprising as it is: So far no bugreport related to this. Probably all user systems caught instantly fire! 🙂︎

So, the week was further used to get used to cmake, build and run apt on various porterboxes to fix testcase failures, fixing other incomings and especially pull some hair out while debugging the bug of the week which lends the title to this blogpost: A one word fix for an issues manifesting itself only in optimization level -O3 on ppc64el. Optimizations are evil…

Beside causing quite some time waste for this week as well as in previous years it is also closing a loop: I introduced this problem myself while being a GSoC student… in 2010. Time really flies. And I have no idea what I was thinking either… I could be describing more of these "tiny" bugs, but the commit messages tend to do a reasonable job and if you are really that damn interested: Feel free to ask. 🙂︎

This next week will be the last official in GSoC from a students POV as I am supposed to clean up all bases & submit my work for the final evaluation – this submit will be as a blogpost describing & linking to everything, which equals miles long and relatively soon, so that I purposefully have kept this one a very short one so you will have enough energy to bear with me for the next one.

Week 15: Onion ordering

The week started badly: I had for a long while now a dead 'e' key on my keyboard, but I didn't care that much… I just remapped CAPSLOCK, retrained my fingers and be done with it [I have some fucked up typing style anyhow]. All good, but at this week additional keys started to give up. You have no idea how annoying it is to not be able use the arrow keys. Many things I work with have at least the vim-keybindings, but even in vim picking an autocompletion becomes a nightmare (or navigating shell history)… So, replacement keyboard please! That took a while, especially replacing it as my laptop makes that extra hard it seems but oh well. All working again now! The c-key is actually working a bit too good (you have to only touch it now, which had me worried as it started out with producing and endless stream of 'c' out-of-the-box before I removed the cap once) but so be it for now.

As you might guess that wasn't the ideal work-environment and slowed me down (beside being annoying), so what I intended to do as a sideproject turned out to be covering most of the week. Mergeback of apt-transport-tor into apt? Yes, no, maybe? The first few responses by mail & IRC are in regards to the plan, but that still had the need for a lots of code to be written and refactored. I have to say, implementing SOCKS5 proxy support in apt was kinda fun and not nearly as hard as I had imagined. Slightly harder it was to get a setup working in which I could test it properly. Everyone knows netcat, but that really targets more text-based protocols, not binary ones like SOCKS5. Still, I managed to figure out how to do it with socat eventually, resulting in a testscript we can at least run manually (as it requires a specific port. Not every tool is as nice as our webserver which can be started on port 0 and reports the port it eventually picked for real). Playful as I am I even compared my implementation to others like curl, which our https method is using, where I ended up reporting minor bugs.

But why and why now you might ask: apt-transport-tor can be (surprise surprise) used to let apt talk to Tor network. Conceptionally that isn't incredibly hard: The Tor software provides a SOCKS5 proxy an application can connect to be done. Two years ago then apt-transport-tor was introduced only our curl-backed https method could do that & the intention was be able to make backports of that transport available, too, so even through I wasn't all that happy about it, we ended up with a modified copy of our https method named tor in the archive and as it is with most modified copies of code, they aren't really kept in sync with the original. I really want to get this resolved for stretch, so it slowly gets hightime to start this as if it turns out that I need to take over maintenance for it without previous-maintainer consent there is quiet a bit of waiting involved stuff like this should really not be changed last-minute before the freeze… you will find more details in the mentioned mail on the reasons for proposing this solution in the mail.

Beside, SOCKS support is actually a so much requested feature that the internet actually believes apt would support it already via Acquire::socks::proxy … which is and will also be in future wrong as there is no socks method we would configure a proxy for – if at all you configure a method like http to use a socks proxy…

Of course, bundled with this comes a bunch of other things like better redirection handling across methods and stuff, but that isn't really user visible, so I skip it here and instead refer you to the git branches if you are really interested. A few things I will surely also mention then the relevant code is in the archive so that interested peers can test…

On my actual battle front, the ordering progress was insignificant. I got lots of manual testing and review done, but not much new stuff. The problem is mostly that ordering is easy as long as the problem is easy, but as soon as Pre-Depends are entering the picture you suddenly have to account for all kinds of strange things like temporal removals, loops conflicting or-groups, … stuff you don't want to loose hair over while losing hair over your broken keyboard already. 😉︎

This week for realz, although target is now really more to merge the current stuff for apt 1.3. A new ordering algorithm is as detailed in the initial proposal buster material anyhow – and given all the changes in terms of trigger delaying and pending calls you are likely not to recognize our "old" ordering anymore, but more on this in the next two weeks as that will be the end of GSoC and hence I am going to look back at "the good old times" before GSoC compared to what we have now. 🙂︎

P.S.: This weeks weekend marks the start of a big wine festival in our state capital my family is one of the founding members of. I am "just" going to help building the booth through, so no giant timesink this time – just a couple hours – just in case you hear me saying something about wine again on IRC.

Week 14: This is CROSS!

Picture me as a messenger kicked into an endless pit of complexity by what was supposed to be an easy victim. It wasn't /that/ bad, but massaging apt to treat crossgrades right took some time – and then some more to request that dpkg would handle some of it, too, as it gets confused by multi-instance packages. Much like apt although that was just effecting apts progress reporting so not that bad… perhaps I am play-testing too much

In unrelated news I dealt with the two acquire bugs which started last week as such bugs are annoying & carry the risk of being security problems which would require immediate attention. Thankfully non of them seems to be one, but #831762 had me seriously worried for a while. Trivial in retrospective, but getting to a point in which you consider the possibility of that happening at all…

But back to the topic: There was one thing still needed to get our current internal planner a bit "smarter" by enabling options which existed for a while now, but were never activated by default, and that thing was simulation. While its kinda appealing to have the simulation only display what the planner explicitly told use to do, ignoring what would implicitly be done by the --pending calls we can't really do that as this would be an interface break. There are surely scripts out there doing funny things with this output so having it be incomplete is not an option, which in turn means that what I did internally for the progress reporting (and hook scripts) must also be done in the simulation. Easier said then done through as the implementation of it followed a direct approach running the simulation of each action as soon as the action was called rather than collecting all the actions first to post-process them (as I want to do it) and execute them only then. Add to this that this is a public class, so ABI is a concern… the solution I arrived at is slightly wrong, but is going to satisfy all existing callers (which is only aptitude in the archive thanks to codesearch.d.n) and reuses the "dpkg specific" code, which is a layer violation, but reuse is better than copy&paste without breaking ABI, so I am happy all things considered.

So, with that out of the way glory awaits: Changing the default of PackageManager::Configure from "all" to "smart"… and tada: It works! The simulation shows everything, the dpkg invocations are much shorter, trigger executions delayed, we rely more on --pending calls and progress reporting is properly moving forward as well! Not 100% production ready but good enough for a public wip branch for now (= wip aka: going to be rebased at will).

This also includes the barebones 'dpkg' planner I mentioned last week, based on that I was playing with ideas to find a more viable implementation (= handling Pre-Depends) but nothing of particular note produced yet. Maybe I can get something working this week – it is at least part of the plan beside polishing my wip branch – after leaving that pit that is… Hello, is anyone up there? Hello? Hello? …

Week 13: Progress reporting

On the public side of things I did a bunch of things this week which weren't exactly related to the GSoC project which were triggered by incoming mails (and IRC highlights) with bugreports and interesting whichlists, which isn't completed yet as there are two new responses with debug logs waiting for me next week.

I say that as I brushed up a smallish commit for merge this week which is supposed to deal better with triggers in progress reporting. That sounds boring – writing progress reporting stuff – but many people care deeply about it. While this one is more of a cosmetic change its conceptionally a big one: With the actions the planner proposed, apt builds for each package a list of states it will pass through while it is installed/upgraded/removed/purged. Triggers rain in this parade as we don't know beforehand that a package will be triggered. Instead, a status message from dpkg will tell us that a package was triggered, so if we don't want to end up in a state in which apt tells via progress report that it is done, but still has a gazillion triggers to run we have to notice this and add some progress states to the list of the triggered package – easy right? The "problem" starts with packages which are triggered but are destined to be upgraded to. A triggered package will loose its trigger state if it is unpacked, so our progress report has to skip the trigger states if the package is unpacked – we can't just exclude packages if they will be unpacked as it can easily be that a package is triggered, the trigger is acted upon and is upgraded "ages" later in this apt run.

My wip branch contains many more progress related commits as there is a big gotcha in the description above: I said "with the actions the planner proposed", so what about the actions the planner isn't proposing but will happen as part of dpkg --configure/--remove/--purge --pending calls? And what about hook scripts like apt-listbugs/changes which get told the actions to perform their own magic?

The solution is simple: We don't tell dpkg about this, but for our own usage we do trivial expansions of the --pending commands and use these for progress report planning as well as for telling the hookscripts about them. That sounds like a very simple and optional thing, but it was actually what blocked the activation of various config options I had implemented years ago which delay trigger execution, avoid explicit configuration of all packages at the end and all that which I could now all enable – a bit more on that after this hits the master branch. 🙂︎

I also looked into supporting crossgrades better. In apts conception a crossgrade is the remove of a package of arch A and the installation of a new package (with the same name) of arch B. dpkg on the other hand deals with it like a 'normal' upgrade, just that the architecture of the package changes. The issue with that isn't gigantic usually, but it becomes big with essential packages like if you try to crossgrade dpkg itself with apt: APT refuses to do that by default, but with enough force it will tell dpkg to remove dpkg:A and then it tells dpkg to unpack dpkg:B – just that there is no dpkg anymore which could unpack itself. At least in that case we can skip the remove of dpkg:A, but we can't do it unconditionally as that might very well be some part of an order requirement, so progress reporting should be prepared for either to (not) happen… That isn't finished yet and will surely leak into next week.

Next week will also see my freshly built planner 'dpkg' get a proper tour: With all the --pending calls it seems like a good idea to try to be extra dumb and have a planner just unpack everything in one go, let the rest be covered by --pending calls and see what breaks: Obviously the harder stuff, but I have two directions I would like to explore based on this minimal planner to make it viable. First I have to finish the crossgrading through, my usual self-review of commits and the bugreports I participated in this week want to trigger further actions, too… see you next week!

This blog has no centralized comment section. Feel free to comment on it in your own blog, some other page or channel you are on to discuss stuff and/or contact me by mail. I am happy to add pointers and updates as needed.