Wandering Thoughts archives

Why I'm unhappy with how Debian builds from source packages right now

A few years ago, I wrote about a problem with how Debian builds from source packages, namely that it builds your binary packages in the source package working area and this can lead to contamination of your source package working area. Fast-forward to today:

@thatcks: Current status: really hating the Debian approach to building packages because it commingling source & build areas has blown up in my face.

@thatcks: I think I'm going to have to extract my change, nuke the entire package area, and start over completely from scratch, testing included.

I'd been making a change to a quilt-based Ubuntu source package. It was a simple change, I had it in a quilt patch since we've done this drill before, and I'd built and tested the updated binary packages. As one of our pre-deployment steps, an obvious thing to do was build a source package too as a nice encapsulated artifact of our changes.

So:

$ debuild -S -us -uc
[... natter natter ...]
dpkg-source: info: local changes detected, the modified files are:
  <package>-<ver>/configure
dpkg-source: error: aborting due to unexpected upstream changes, see [...]

There is only one problem: I hadn't changed configure. At all.

The upstream tarball of this package ships a configure.ac as well as the straight configure. My best guess is that building the package from source the way Ubuntu does it re-runs autoconf, and the autoconf-generated configure is different from the upstream configure in minor ways (the actual diffs are small but plausible for this). This means that after a single build, your source package working area is contaminated unless you carefully save or re-extract the original configure in order to put it back at the start of any rebuild.

(Indeed I just did a test 'debuild -b -us -uc' on yet another scratch copy of the source, and it seems to have run autoconf.)

I assume that the people who maintain this Ubuntu package don't notice this because the normal Debian source package is not how they actually work with it. Instead I suspect that they have it in git, build it with automated builders that always start clean from a source package, and so on. In other words, they have a different industrial production system and the source package is a lie.

It's difficult for me to find words to express how this makes me feel. Angry is certainly part of it, not simply for what this means for us making changes to the package but also for what it means about how much the package maintainers and Ubuntu in general care about the 'standard' way of building packages. At the best, practices have shifted once again without anyone making it official and clear; at the worst, outside people like me are simply second class citizens when it comes to package work.

(This is of course par for the course for Ubuntu, where Canonical has been extending various digits in people's directions for some time, but I don't have to like it.)

I have no idea what this means for how we want to maintain our local changes here. I have at best vague theories. Probably I'm going to have to try to find unofficial information online about how other people do it.

(This is definitely going to slow down our work with the package, too, and I'll leave things at that rather than going off at length here.)

PS: One thing that this means is that the Ubuntu package build process lacks consistency checks to detect this sort of thing. Given an aphorism, I expect that there are plenty of Ubuntu source packages that have this problem.

Sidebar: Some actual build-time output

[...]
dh_autotools-dev_restoreconfig
debconf-updatepo
dh_clean
 debian/rules build
dh_testdir
dh_autotools-dev_updateconfig
autoconf
# <pkg>
[runs configure]
[...]

And debian/rules has a 'config-stamp: configure' section that does the dh_testdir stuff et al. The earlier output is from the 'clean:' section of debian/rules for this package. So I believe I have the root cause identified.

Whoever thought that re-running autoconf was a good idea, well, I have no words.

What I'm doing to use a Yubikey in Fedora 24's Cinnamon desktop environment

On my desktop machines, I run a fully custom window manager environment where I had almost no problems integrating my Yubikey into my regular environment; most of what it took was some mild hacks to my special screensaver stuff. However, I also have an office laptop that uses a Cinnamon-based environment and I wanted to be able to use the Yubikey there. That turned out to be rather more difficult, because Cinnamon normally handles SSH agent stuff through gnome-keyring-daemon.

The problem with using g-k-d is simple; gnome-keyring-daemon is pretty bad at dealing with SSH keys. Well, perhaps 'limited' is a more charitable label. It still doesn't support ED25519 keys, for example. But in this case the really fatal limitation is that it appears to have no support for using PKCS#11 shared library providers. Since Yubikey-hosted SSH keys can only be accessed through just such a shared library, gnome-keyring-daemon is unable to host them. This means that if you want to have Yubikeys managed through your SSH agent instead of having to unlock them with your PIN every time you use them, you can't let gnome-keyring-daemon be your SSH agent; instead you need to be using the real ssh-agent.

At least on my Fedora 24 install, the session stuff was already starting a ssh-agent process. It was just being preempted by part of the gnome-keyring-daemon setup. Perhaps in a normal Gnome 3 environment there is some graphical way of turning this off, but I couldn't find anything in my Cinnamon settings. Instead you have to do this by hand, like so:

1. Make a ~/.config/autostart directory if you don't already have one.
2. Copy /etc/xdg/autostart/gnome-keyring-ssh.desktop to it.
3. Edit your copy to delete or rename the X-GNOME-Autostart, X-GNOME-AutoRestart, and X-GNOME-Autostart-Notify settings. Possibly you only need to get the first one.

Now log out and log back in again, and you should be using the real ssh-agent instead of gnome-keyring-daemon's emulation of it. You can see which one you're using based on the value of the $SSH_AUTH_SOCK environment variable; if it's of the form /run/user/<uid>/keyring/ssh, you're still using gnome-keyring-agent. The real ssh-agent gives you values that look like /tmp/ssh-<blah>/agent.<pid>.

(The ssh-agent process is started in /etc/X11/xinit/xinitrc-common, which in Fedora comes from the xorg-x11-xinit package. You probably have it installed by default, at least in a Cinnamon-based environment.)

Once you're using the real ssh-agent, you can add the Yubikey hosted SSH keys to it with the usual 'ssh-add -s /usr/lib64/opensc-pkcs11.so' and so on. I wrote a script for this, which I can easily run through my Cinnamon customizations. Since I only use my laptop infrequently, I haven't explored things like integration into screen locking; it's enough for me that I can use my Yubikey through the laptop if I really need to, it doesn't have to be as convenient or polished as I want it to be on my desktop.

Information for this entry comes from Using ssh-agent and ED25519 keys on GNOME, the Arch wiki entry on the GNOME keyring daemon, and this entry on using gpg-agent with GNOME. Sadly, the gconftool-2 stuff from this askubuntu question and its answers doesn't work for me.

(It turns out that lots of people are unhappy with having gnome-keyring-daemon act as their SSH agent. Possibly I should have hunted this down years ago just so I could use ED25519 keys on my laptop.)