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
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.
$ 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
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
configure in order to put it back at the start of any
(Indeed I just did a test '
debuild -b -us -uc' on yet another
scratch copy of the source, and it seems to have run
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] [...]
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
The problem with using g-k-d is simple;
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
be your SSH agent; instead you need to be using the real
At least on my Fedora 24 install, the session stuff was already
ssh-agent process. It was just being preempted by part
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:
- Make a
~/.config/autostartdirectory if you don't already have one.
- Edit your copy to delete or rename the
X-GNOME-Autostart-Notifysettings. 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
ssh-agent gives you values that look like
ssh-agent process is started in
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 '
/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.
gconftool-2 stuff from this askubuntu question and
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.)