Let's say you have a
configure.ac file which contains this:
PKG_CHECK_VAR([p11_moduledir], "p11-kit-1", "p11_module_path")
AC_SUBST([p11_moduledir])
and that it goes with a
Makefile.am which contains this:
dist_p11_module_DATA = foo.module
Then things should work fine, right? When you run
make install, your
modules install to the right location, and p11-kit will pick up
everything the way it should.
Well, no. Not exactly. That is, it will work for the common case, but
not for some other cases. You see, if you do that, then
make distcheck
will fail pretty spectacularly. At least if you run that as non-root
(which you really really should do). The problem is that by specifying
the
p11_moduledir variable in that way, you hardcode it; it doesn't
honour any
$prefix or
$DESTDIR variables that way. The result of
that is that when a user installs your package by specifying
--prefix=/opt/testmeout, it will
still overwrite files in the system
directory. Obviously, that's not desireable.
The
$DESTDIR bit is especially troublesome, as it makes packaging your
software for the common distributions complicated (most packaging
software heavily relies on DESTDIR support to "install" your software in
a staging area before turning it into an installable package).
So what's the right way then? I've been wondering about that myself, and
asked
for the right way to do something like that on the automake mailinglist
a while back. The answer I got there wasn't entirely satisfying, and at
the time I decided to take the easy way out (
EXTRA_DIST the file, but
don't actually install it). Recently, however, I ran against a similar
problem for
something else, and
decided to try to do it the proper way this time around.
p11-kit, like systemd, ships
pkg-config files which contain
variables for the default locations to install files into. These
variables' values are meant to be easy to use from scripts, so that no
munging of them is required if you want to directly install to the
system-wide default location. The downside of this is that, if you want
to install to the system-wide default location
by default from an
autotools package (but still allow the user to
--prefix your
installation into some other place, accepting that then things won't
work out of the box), you
do need to do the aforementioned munging.
Luckily, that munging isn't too hard, provided whatever package you're
installing for did the right thing:
PKG_CHECK_VAR([p11_moduledir], "p11-kit-1", "p11_module_path")
PKG_CHECK_VAR([p11kit_libdir], "p11-kit-1", "libdir")
if test -z $ac_cv_env_p11_moduledir_set; then
p11_moduledir=$(echo $p11_moduledir sed -e "s,$p11kit_libdir,\$ libdir ,g")
fi
AC_SUBST([p11_moduledir])
Whoa, what just happened?
First, we ask p11-kit-1 where it expects modules to be. After that, we
ask p11-kit-1 what was used as "libdir" at installation time. Usually
that should be something like
/usr/lib or
/usr/lib/gnu arch
triplet or some such, but it could really be anything.
Next, we test to see whether the user set the
p11_moduledir variable
on the command line. If so, we don't want to munge it.
The next line looks for the value of whatever
libdir was set to when
p11-kit-1 was installed in the value of
p11_module_path, and replaces
it with the literal string
$ libdir .
Finally, we exit our if and
AC_SUBST our value into the rest of the
build system.
The resulting package will have the following semantics:
- If someone installs
p11-kit-1 your package with the same prefix,
the files will install to the correct location.
- If someone installs both packages with a different prefix, then by
default the files will not install to the correct location. This is
what you'd want, however; using a non-default prefix is the only way
to install something as non-root, and if root installed something into
/usr, a normal user wouldn't be able to fix things.
- If someone installs both packages with a different prefix, but
sets the
p11_moduledir variable to the correct location, at
configure time, then things will work as expected.
I suppose it would've been easier if the
PKG_CHECK_VAR macro could
(optionally) do that munging by itself, but then, can't have everything.
If you want, sicherboot automatically creates db, KEK, and PK keys, and puts the public keys on your EFI System Partition (ESP) together with the KeyTool tool, so you can enroll the keys in UEFI. You can of course also use other keys, you just need to drop a db.crt and a db.key file into 
Welcome to gambaru.de. Here is my monthly report that covers what I have been doing for Debian. If you re interested in Android, Java, Games and LTS topics, this might be interesting for you.
Debian Android
Debian LTS
August marked the sixteenth month I contributed to 
A masterpiece by Yukio Mishima Patriotism the story of love and dead. A short story about the double suicide of a Lieutenant and his wife following the 
Not only the book is a masterpiece by itself, also the movie is a special piece of art: Filmed in silent movie style with text inserts, the whole story takes place on a Noh stage. This is in particular interesting as Mishima was one of the few, if not the only, modern Noh play writer. He has written several Noh plays.
Another very impressive scene for me was when, after her husbands suicide, Reiko returns from putting up her final make-up into the central room. Her kimono is already blood soaked and the trailing kimono leaves traces on the Noh stage resembling the strokes of a calligraphy, as if her movement is guided, too, by .
The final scene of the movie shows the two of them in a Zen stone garden, forming the stone, the unreachable island of happiness.
Very impressive, both the book as well as the movie.
The Haskell minicourse at the University of Pennsylvania, also known as 
My monthly report covers a large part of what I have been doing in the free software world. I write it for 
In the spirit of blogging about some of the code i ve written in the past year or two, I wrote a small utility library called 
The seventh update in the 0.12.* series of 
Even though the Chess Olympiad takes some attention right now, development on
Nageru (my live video mixer) has continued steadily throughout since the 1.3.0 release. I wanted to
take a little time to talk about the upcoming 1.4.0 release, and why things
are as they are; writing down things often make them a bit clearer.
Every major release of Nageru has had a specific primary focus: 1.0.0 was about
just getting everything to work, 1.1.0 was about NVIDIA support for more
oomph, 1.2.0 was about stabilization and polish (and added support for
Blackmagic's PCI cards as a nice little bonus), and 1.3.0 was about x264
integration. For 1.4.0, I wanted to work on multitrack audio and mixing.
Audio has always been a clear focus for Nageru, and for good reason; video is
90% about audio, and it's sorely neglected in most amateur productions
(not to mention that processing tools are nearly non-existant in most free or
cheap software video mixers). Right from the get-go, it's had a chain with
proper leveling, compressors and most importantly visual monitoring, so that
you know when things are not as they should be. However, it was also written
with an assumption that there would be a single audio input source (one of
the cameras), and that's going to change.
Single-input is less of a showstopper than one'd think at first; you can work
around it by buying a mixer, plug everything into that and then feed that
signal into the computer. However, there are a few downsides: If you want
camera audio, you'll need to pull more cable from each camera (or have SDI
de-embedders). Your mixer is likely to require an extra power supply, and
that means yet more cable (any decent USB video card can power over USB, so
why shouldn't your audio?). You'll need to buy and transport yet another
device. And so on. (If you already have a PA mixer, of course you can use it,
but just reusing the PA mix as a stream mix rarely gives the best results,
and mixing on an aux bus gives very little flexibility.)
So for 1.4.0, I wanted something to get essentially the processing equivalent
of a mid-range mixer. But even though my education is in DSP, my experience
with mixers is rather limited, so I did the only reasonable thing and went
over to a friend who's also an (award-winning) audio engineer. (It turns out
that everything on a mixer is the way it is for a pretty good reason, tuned
through 50+ years of collective audio experience. If you just try to make up
something on your own without understanding what's going on, you have a
0.001% chance of stumbling upon some genius new way of doing things by
accident, and a significantly larger chance than that of messing things up.)
After some back and forth, we figured out a reasonable set of basic tools
that would be useful in the right hands, and not too confusing for a
beginner. So let's have a look at the new controls you get:
There's one set of these controls for each bus. (This is the expanded view; there's
also a compact view that has only the meters and the fader, which is what
you'll typically want to use during the run itself the expanded view is for
setup and tweaking.) A bus in Nageru is a pair of channels (left/right),
sourced from a video capture or ALSA card. The channel mapping is flexible;
my USB sound card has 18 channels, for instance, and you can use that to make
several buses. Each bus has a name (here I named it very creatively Main ,
but in a real setting you might want something like Blue microphone or
Speaker PC ), which is just for convenience; it doesn't mean much.
The most important parts of the mix are given the most screen estate,
so even though the way through the signal chain is left-to-right
top-to-bottom, I'll go over it in the opposite direction.
By far the most important part is the audio level, so the fader naturally is
very prominent. (Note that the scale is nonlinear; you want more resolution
in the most important area.) Changing a fader with the mouse or keyboard is
possible, and probably most people will be doing that, but Nageru will also
support USB faders. These usually speak MIDI, for historical reasons, and
there are some UI challenges when they're all so different, but you can get
really small ones if you want to get that tactile feel without blowing up
your budget or getting a bigger backpack.
Then there's the meter to the left of that. Nageru already has R128 level
meters in the mastering section (not shown here, but generally unchanged from
1.3.0), and those are kept as-is, but for each bus, you don't want to know loudness; you want to know
recording levels, so you want a peak meter, not a loudness meter. In particular, you don't want the bus to send clipped data
to the master (which would happen if you set it too high); Nageru can handle
this situation pretty well (unlike most digital mixers, it mixes in
full 32-bit floating-point so there's no internal clipping, and there's a limiter on the master by default),
but it's still not a good place to be in, so you can see that being marked
in red in this example. The meter doubles as an input peak check during
setup; if you turn off all the effects and set the fader to neutral, you can
see if the input hits peak or not, and then adjust it down. (Also, you can
see here that I only have audio in the left channel; I'd better check my
connections, or perhaps just use mono, by setting the right channel on the
bus mapping to the same input as the left one.)
The compressor (now moved from the mastering section to each bus) should be
well-known for those using 1.3.0, but in this view, it also has a reduction
meter, so that you can see whether it kicks in or not. Most casual users
would want to just leave the gain staging and compressor settings alone, but
a skilled audio engineer will know how to adjust these to each speaker's
antics (some speak at a pretty even volume and thus can get a bit of
headroom, while some are much more variable and need tighter settings).
Finally (or, well, first), there's the EQ section. The lo-cut is again
well-known from 1.3.0 (the cutoff frequency is the same across all buses),
but there's now also a simple three-band EQ per bus. Simply ask the speaker
to talk normally for a bit, and tweak the controls until it sounds good.
People have different voices and different ways of holding the microphone,
and if you have a reasonable ear, you can use the EQ to your advantage to
make them sound a little more even on the stream. Either that, or just
put it in neutral, and the entire EQ code will be bypassed.
The code is making pretty good progress; all the DSP stuff is done
(save for some optimizations I want to do in zita-resampler, now that
the discussion flow is started again),
and in theory, one could use it already as-is. However, there's a fair
amount of gnarly support code that still needs to be written: In particular,
I need to do some refactoring to support ALSA hotplug (you don't want
your entire stream to go down just because an USB soundcard dropped out
for a split second), and similarly some serialization of saving/loading
bus mappings. It's not exactly rocket science, but all the code still needs
to be written, and there are a number of corner cases to think of.
If you want to peek, the code is in the