pages tagged debian
spwhitton
https://spwhitton.name//tag/debian/
spwhitton
ikiwiki
2020-04-03T23:02:05Z
Manifest to run Debian pre-upload tests on builds.sr.ht
https://spwhitton.name//blog/entry/buildssrht-preupload/
2020-04-03T23:02:05Z
2020-04-03T17:47:07Z
<p>Before uploading stuff to Debian, I build in a clean chroot, and then
run piuparts, autopkgtest and lintian. For some of my packages this
can take around an hour on my laptop, which is fairly old. Normally I
don’t mind waiting, but sometimes I want to put my laptop away, and
then it would be good for things to be faster. It occurred to me that
I could make use of my <a href="https://builds.sr.ht/">builds.sr.ht</a> account
to run these tests on more powerful hardware.</p>
<p>This build manifest seems to work:</p>
<pre><code class="{.yaml}"># BEGIN CONFIGURABLE
sources:
- https://salsa.debian.org/perl-team/modules/packages/libgit-annex-perl.git
environment:
source: libgit-annex-perl
quilt: auto
# END CONFIGURABLE
image: debian/unstable
packages:
- autopkgtest
- devscripts
- dgit
- lintian
- piuparts
- sbuild
tasks:
- setup: |
cd $source
source_version=$(dpkg-parsechangelog -SVersion)
echo "source_version=$source_version" >>~/.buildenv
git deborig || origtargz
sudo sbuild-createchroot --command-prefix=eatmydata --include=eatmydata unstable /srv/chroot/unstable-amd64-sbuild
sudo sbuild-adduser $USER
- build: |
cd $source
dgit --quilt=$quilt sbuild -d unstable --no-run-lintian
- lintian: |
lintian ${source}_${source_version}_multi.changes
- piuparts: |
sudo piuparts --no-eatmydata --schroot unstable-amd64-sbuild ${source}_${source_version}_multi.changes
- autopkgtest: |
autopkgtest ${source}_${source_version}_multi.changes -- schroot unstable-amd64-sbuild
</code></pre>
<p><a href="https://git.spwhitton.name/dotfiles/tree/bin/buildssrht-preupload">And here’s my script</a>.</p>
Are you a DD or DM doing source-only uploads to Debian out of a git repository?
https://spwhitton.name//blog/entry/pushsourcedropin/
2018-03-11T21:22:16Z
2018-01-10T17:54:45Z
<p>If you are a Debian Maintainer (DM) or Debian Developer (DD) doing
source-only uploads to Debian for packages maintained in git, you are
probably using some variation of the following:</p>
<pre><code>% # sbuild/pbuilder, install and test the final package
% # everything looks good
% dch -r
% git commit debian/changelog "Finalise 1.2.3-1 upload"
% gbp buildpackage -S --git-tag
% debsign -S
% dput ftp-master ../foo_1.2.3-1_source.changes
% git push --follow-tags origin master
</code></pre>
<p>where the <code>origin</code> remote is probably <code>salsa.debian.org</code>. Please
consider replacing the above with the following:</p>
<pre><code>% # sbuild/pbuilder, install and test the final package
% # everything looks good
% dch -r
% git commit debian/changelog "Finalise 1.2.3-1 upload"
% dgit push-source --gbp
% git push --follow-tags origin master
</code></pre>
<p>where the <code>dgit push-source</code> call does the following:</p>
<ol>
<li>Various sanity checks, some of which are not performed by any other
tools, such as
<ul>
<li>not accidently overwriting an NMU.</li>
<li>not missing the .orig.tar from your upload</li>
<li>ensuring that the <code>Distribution</code> field in your changes is the
same as your changelog</li>
</ul>
</li>
<li>Builds a source package from your git HEAD.</li>
<li>Signs the .changes and .dsc.</li>
<li>dputs these to ftp-master.</li>
<li>Pushes your git history to
<a href="https://browse.dgit.debian.org/">dgit-repos</a>.</li>
</ol>
<p>Why might you want to do this? Well,</p>
<ol>
<li>You don’t need to learn how to use dgit for any other parts of your
workflow. It’s entirely drop-in.
<ul>
<li>Assuming that your repository has upstream source committed with
patches unapplied, and there is at least one quilt patch, dgit
will not make any merge commits on your master branch, or
anything surprising like that.</li>
</ul>
</li>
<li>No-one else in your team is required to use dgit. Nothing about
their workflow need change.</li>
<li>Benefit from dgit’s sanity checks.</li>
<li>Provide your git history on <code>dgit-repos</code> in a uniform format that
is easier for users, NMUers and downstreams to use (see
<code>dgit-user(7)</code> and <code>dgit-simple-nmu(7)</code>).
<ul>
<li>Note that this is independent of the history you push to
alioth/salsa. You still need to push to salsa as before, and
assuming that your repository has upstream source committed with
patches unapplied and there is at least one quilt patch, the
format of that history is not changed.</li>
</ul>
</li>
<li>Only a single command is required to perform the source-only
upload, instead of three.</li>
</ol>
<h1>Hints</h1>
<ol>
<li>If you’re using <code>git dpm</code> you’ll want <code>--dpm</code> instead of <code>--gbp</code>.</li>
<li>If the last upload of the package was not performed with dgit
(e.g. this is your first upload using dgit), you’ll need to pass
<code>--overwrite</code>. dgit will tell you if you need this. This is to
avoid accidently excluding the changes in NMUs.</li>
</ol>
dgit push-source
https://spwhitton.name//blog/entry/pushsource/
2018-01-08T07:48:27Z
2018-01-08T07:48:27Z
<p>dgit 4.2, which is now in Debian unstable, has a new subcommand: <code>dgit
push-source</code>. This is just like <code>dgit push</code>, except that</p>
<ul>
<li>it forces a source-only upload; and</li>
<li>it also takes care of preparing the <code>_source.changes</code>,
transparently, without the user needing to run <code>dpkg-buildpackage
-S</code> or <code>dgit build-source</code> or whatever.</li>
</ul>
<p><code>push-source</code> is useful to ensure you don’t accidently upload
binaries, and that was its original motivation. But there is a deeper
significance to this new command: to say</p>
<pre><code>% dgit push-source unstable
</code></pre>
<p>is, in one command, basically to say</p>
<pre><code>% git push ftp-master HEAD:unstable
</code></pre>
<p>That is: <code>dgit push-source</code> is like doing a single-step <code>git push</code> of
your git HEAD straight into the archive! The future is now!</p>
<p>The contrast here is with ordinary <code>dgit push</code>, which is not analogous
to a single <code>git push</code> command, because</p>
<ul>
<li>it involves uploading .debs, which make a material change to the
archive other than updating the source code of the package; and</li>
<li>it must be preceded by a call to <code>dpkg-buildpackage</code>, <code>dgit sbuild</code>
or similar to prepare the <code>.changes</code> file.</li>
</ul>
<p>While <code>dgit push-source</code> also involves uploading files to ftp-master
in addition to the git push, because that happens transparently and
does not require the user to run a build command, it can be thought of
as an implementation detail.</p>
<p>Two remaining points of disanalogy:</p>
<ol>
<li><p><code>git push</code> will push your HEAD no matter the state of the working
tree, but <code>dgit push-source</code> has to clean your working tree. I’m
thinking about
<a href="https://bugs.debian.org/886625">ways to improve this</a>.</p></li>
<li><p>For non-native packages, you still need an <code>orig.tar</code> in <code>..</code>.
Urgh. At least that’s easy to obtain thanks to
<a href="https://manpages.debian.org/git-deborig">git-deborig</a>.</p></li>
</ol>
Using Propellor to provision your Debian development laptop
https://spwhitton.name//blog/entry/propellorsbuild/
2017-11-23T22:53:23Z
2017-11-23T22:38:40Z
<p>sbuild is a tool used by those maintaining packages in Debian, and
derived distributions such as Ubuntu. When used correctly, it can
catch a lot of categories of bugs before packages are uploaded. It
does this by building the package in a clean environment, and then
running the package through the Lintian, piuparts, adequate and
autopkgtest tools. However, configuring sbuild so that it makes use
of all of these tools is cumbersome.</p>
<p>In response to this complexity, I wrote <a href="http://hackage.haskell.org/package/propellor/docs/Propellor-Property-Sbuild.html">a module</a> for the
<a href="https://propellor.branchable.com/">Propellor</a> configuration management system to prepare a system such
that a user can just go ahead and run the sbuild(1) command.</p>
<p>This module is useful on one’s development laptop – if you need to
reinstall your OS, you don’t have to look up the instructions for
setting up sbuild again. But it’s also useful on throwaway build
boxes. I can instruct propellor to provision a new virtual machine to
build packages with sbuild, and all the different tools mentioned
above will be connected together for me.</p>
<p>I just uploaded Propellor version 5.1.0 to Debian unstable. The
version overhauls the API and internals of the Sbuild module to take
better advantage of Propellor’s design. I won’t get into those
details in this post. What I’d like to do is demonstrate how you can
set up sbuild on your own machines, using Propellor.</p>
<h1>Getting started with Propellor</h1>
<p><code>apt-get install propellor</code>, and then <code>propellor --init</code>.</p>
<p>As mentioned, at the time of writing you’ll need to install from
Debian unstable. For this tutorial you need version 5.1.0 or
greater.</p>
<p>You’ll be offered two setups, options A and B. I suggest starting
with option B.</p>
<p>If you never use Propellor for anything other than provisioning
sbuild, you can stick with option B. If this tutorial makes you want
to check out more features of Propellor, you might consider switching
to option A and importing your old configuration.</p>
<p>Open <code>~/.propellor/config.hs</code>. You will see something like this:</p>
<div class="highlight-haskell"><pre class="hl"><span class="hl slc">-- The hosts propellor knows about.</span>
hosts <span class="hl opt">:: [</span>Host<span class="hl opt">]</span>
hosts <span class="hl opt">=</span>
<span class="hl opt">[</span> mybox
<span class="hl opt">]</span>
<span class="hl slc">-- An example host.</span>
mybox <span class="hl opt">::</span> Host
mybox <span class="hl opt">=</span> host <span class="hl str">"mybox.example.com"</span> <span class="hl opt">$</span> props
<span class="hl opt">&</span> osDebian Unstable X86_64
<span class="hl opt">&</span> Apt<span class="hl opt">.</span>stdSourcesList
<span class="hl opt">&</span> Apt<span class="hl opt">.</span>unattendedUpgrades
<span class="hl opt">&</span> Apt<span class="hl opt">.</span>installed <span class="hl opt">[</span><span class="hl str">"etckeeper"</span><span class="hl opt">]</span>
<span class="hl opt">&</span> Apt<span class="hl opt">.</span>installed <span class="hl opt">[</span><span class="hl str">"ssh"</span><span class="hl opt">]</span>
<span class="hl opt">&</span> User<span class="hl opt">.</span>hasSomePassword <span class="hl opt">(</span>User <span class="hl str">"root"</span><span class="hl opt">)</span>
<span class="hl opt">&</span> File<span class="hl opt">.</span>dirExists <span class="hl str">"/var/www"</span>
<span class="hl opt">&</span> Cron<span class="hl opt">.</span>runPropellor <span class="hl opt">(</span>Cron<span class="hl opt">.</span>Times <span class="hl str">"30 * * * *"</span><span class="hl opt">)</span>
</pre></div>
<p>You’ll want to customise this so that it reflects your computer. My
laptop is called <code>iris</code>, so I might replace the above with this:</p>
<div class="highlight-haskell"><pre class="hl"><span class="hl slc">-- The hosts propellor knows about.</span>
hosts <span class="hl opt">:: [</span>Host<span class="hl opt">]</span>
hosts <span class="hl opt">=</span>
<span class="hl opt">[</span> iris
<span class="hl opt">]</span>
<span class="hl slc">-- My laptop.</span>
iris <span class="hl opt">::</span> Host
iris <span class="hl opt">=</span> host <span class="hl str">"iris.silentflame.com"</span> <span class="hl opt">$</span> props
<span class="hl opt">&</span> osDebian Testing X86_64
</pre></div>
<p>The list of lines beginning with <code>&</code> are the <em>properties</em> of the host
iris. Here, I’ve removed all properties except the <code>osDebian</code>
property, which informs propellor that iris runs Debian testing and
has the amd64 architecture.</p>
<p>The effect of this is that Propellor will not try to change anything
about iris. In this tutorial, we are not going to let Propellor
configure anything about iris other than setting up sbuild.</p>
<p>(The <code>osDebian</code> property is a <em>pure info property</em>, which means that
it tells Propellor information about the host to which other
properties might refer, but it doesn’t itself change anything about
iris.)</p>
<h1>Telling Propellor to configure sbuild</h1>
<p>First, add to the <code>import</code> lines at the top of <code>config.hs</code> the lines:</p>
<div class="highlight-haskell"><pre class="hl"><span class="hl kwd">import qualified</span> Propellor<span class="hl opt">.</span>Property<span class="hl opt">.</span>Sbuild <span class="hl kwd">as</span> Sbuild
<span class="hl kwd">import qualified</span> Propellor<span class="hl opt">.</span>Property<span class="hl opt">.</span>Schroot <span class="hl kwd">as</span> Schroot
</pre></div>
<p>to enable use of the Sbuild module. Here is the full config for iris,
which I’ll go through line-by-line:</p>
<div class="highlight-haskell"><pre class="hl"><span class="hl slc">-- The hosts propellor knows about.</span>
hosts <span class="hl opt">:: [</span>Host<span class="hl opt">]</span>
hosts <span class="hl opt">=</span>
<span class="hl opt">[</span> iris
<span class="hl opt">]</span>
<span class="hl slc">-- My laptop.</span>
iris <span class="hl opt">::</span> Host
iris <span class="hl opt">=</span> host <span class="hl str">"iris.silentflame.com"</span> <span class="hl opt">$</span> props
<span class="hl opt">&</span> osDebian Testing X86_64
<span class="hl opt">&</span> Apt<span class="hl opt">.</span>useLocalCacher
<span class="hl opt">&</span> sidSchrootBuilt
<span class="hl opt">&</span> Sbuild<span class="hl opt">.</span>usableBy <span class="hl opt">(</span>User <span class="hl str">"spwhitton"</span><span class="hl opt">)</span>
<span class="hl opt">&</span> Schroot<span class="hl opt">.</span>overlaysInTmpfs
<span class="hl opt">&</span> Cron<span class="hl opt">.</span>runPropellor <span class="hl opt">(</span>Cron<span class="hl opt">.</span>Times <span class="hl str">"30 * * * *"</span><span class="hl opt">)</span>
<span class="hl kwd">where</span>
sidSchrootBuilt <span class="hl opt">=</span> Sbuild<span class="hl opt">.</span>built Sbuild<span class="hl opt">.</span>UseCcache <span class="hl opt">$</span> props
<span class="hl opt">&</span> osDebian Unstable X86_64
<span class="hl opt">&</span> Sbuild<span class="hl opt">.</span>update `period` Daily
<span class="hl opt">&</span> Sbuild<span class="hl opt">.</span>useHostProxy iris
</pre></div>
<ul>
<li><code>Apt.useLocalCacher</code> set up <code>apt-cacher-ng</code> and points apt on iris
at the cacher. This is the most efficient way to share a cache of
packages between apt on iris, and apt within the sbuild chroot.</li>
<li><code>sidSchrootBuilt</code> builds the sbuild schroot. Unfortunately, we have
to use a <code>where</code> clause because of Haskell’s rules about operator
precedence. But it’s just a simple substitution: imagine that <code>&
Sbuild.built ...</code> replaces <code>& sidSchrootBuilt</code>.
<ul>
<li><code>osDebian</code> specifies that this is a Debian unstable chroot. You
can easily change this, or add another chroot, for building
stable backports, etc.</li>
<li><code>Sbuild.UseCcache</code> enables ccache for builds in this chroot.
You can replace this with <code>Sbuild.NoCcache</code> when building a
package which is broken by ccache, which happens from
time-to-time.</li>
<li><code>Sbuild.update</code> updates the chroot once per day.</li>
<li><code>Sbuild.useHostProxy iris</code> causes Propellor to propagate iris’s
apt proxy into the chroot, so that apt in the chroot will also
use iris’s apt cacher.</li>
</ul>
</li>
<li><code>Sbuild.usableBy</code> adds <code>spwhitton</code> to the right group, so that he is
allowed to invoke sbuild(1).</li>
<li><code>Schroot.overlaysInTmpfs</code> configures sbuild to install build
dependencies and build packages in tmpfs. You can omit this
property on machines with low amounts of memory.</li>
<li><code>Cron.runPropellor</code> sets up a cron job to re-run propellor once per
hour. This is needed to ensure that things like <code>Sbuild.update</code>
actually happen. It will also normalise sbuild configuration files,
replace chroots that you accidently deleted, etc.</li>
</ul>
<h1>Running Propellor to configure your laptop</h1>
<pre><code>$ propellor iris.silentflame.com
</code></pre>
<p>In this configuration, you don’t need to worry about whether the
hostname <code>iris.silentflame.com</code> actually resolves to your laptop.
However, it must be possible to <code>ssh root@localhost</code>.</p>
<p>This should be enough that <code>spwhitton</code> can:</p>
<pre><code>$ sbuild -A --run-lintian --run-autopkgtest --run-piuparts foo.dsc
</code></pre>
<h1>Further configuration</h1>
<p>It is easy to add new schroots; for example, for building backports:</p>
<div class="highlight-haskell"><pre class="hl"> <span class="hl opt">...</span>
<span class="hl opt">&</span> stretchSchrootBuilt
<span class="hl opt">...</span>
<span class="hl kwd">where</span>
<span class="hl opt">...</span>
stretchSchrootBuilt <span class="hl opt">=</span> Sbuild<span class="hl opt">.</span>built Sbuild<span class="hl opt">.</span>UseCcache <span class="hl opt">$</span> props
<span class="hl opt">&</span> osDebian <span class="hl opt">(</span>Stable <span class="hl str">"stretch"</span><span class="hl opt">)</span> X86_64
<span class="hl opt">&</span> Sbuild<span class="hl opt">.</span>update `period` Daily
<span class="hl opt">&</span> Sbuild<span class="hl opt">.</span>useHostProxy iris
</pre></div>
<p>You can even use architectures other than <code>X86_64</code>. Propellor knows
how to invoke qemu when it needs to do this to build the chroot,
though sbuild does not know how to actually use chroots built in this
way.</p>
<p>You can also add additional properties to configure your chroot.
Perhaps on your LAN you need sbuild to install packages via https, and
you already have an apt cacher available. You can replace the
apt-cacher-ng configuration like this:</p>
<div class="highlight-haskell"><pre class="hl"> <span class="hl kwd">where</span>
sidSchrootBuilt <span class="hl opt">=</span> Sbuild<span class="hl opt">.</span>built Sbuild<span class="hl opt">.</span>UseCcache <span class="hl opt">$</span> props
<span class="hl opt">&</span> osDebian Unstable X86_64
<span class="hl opt">&</span> Sbuild<span class="hl opt">.</span>update `period` Daily
<span class="hl opt">&</span> Apt<span class="hl opt">.</span>mirror <span class="hl str">"https://foo.mirror/debian/"</span>
<span class="hl opt">&</span> Apt<span class="hl opt">.</span>installed <span class="hl opt">[</span><span class="hl str">"apt-transport-https"</span><span class="hl opt">]</span>
</pre></div>
<h1>Thanks</h1>
<p>Thanks to Propellor’s author, Joey Hess, for help navigating
Propellor’s type system while performing the overhaul included in
version 5.1.0. Also for a conversation at DebConf17 which enabled
this work by clearing some misconceptions of mine.</p>
DebCamp/DebConf17: reports on sprints and BoFs
https://spwhitton.name//blog/entry/debconf17_reports/
2017-08-18T17:46:17Z
2017-08-17T22:21:33Z
<p>In addition to my
<a href="https://spwhitton.name//blog/entry/debconf17/">personal reflections</a>
on DebCamp/DebConf17, here is a brief summary of the activities that I
had a hand in co-ordinating.</p>
<p>I won’t discuss here many other small items of work and valuable
conversations that I had during the two weeks; hopefully the fruits of
these will show themselves in my uploads to the archive over the next
year.</p>
<h1><a href="https://wiki.debian.org/Sprints/2017/DebianPolicy">Debian Policy sprint</a> & BoF</h1>
<ul>
<li><p><a href="https://tracker.debian.org/news/860960">released</a> version 4.0.1.0
of the Policy Manual</p></li>
<li><p>figured out
<a href="https://bugs.debian.org/844431">documenting reproducibility</a> in
policy. Formulating the wording turned out to be easier than I had
expected</p></li>
<li><p>approx. ten years after they were first published, incorporated
<a href="https://wiki.debian.org/MaintainerScripts">marga’s maintscript flowcharts</a>
into policy proper</p></li>
<li><p>converted policy from docbook to rST built with the Sphinx
toolchain. Many, many thanks to Hideki Yamane and David Bremner for
helping Russ and I get this merged to our master branch</p></li>
<li><p>triage of every single bug against policy, and mass closure of
inactive bugs, bringing the total down from more than 200 to around
125</p></li>
<li><p>conversations with Technical Committee members about how the two
teams can help each other’s work (mainly us helping them to help
us!)</p></li>
<li><p>conversations about how we handle disagreement and plans to
streamline our overly complex BTS usertags (watch this space)</p></li>
<li><p>very useful input from policy consumers about how the upgrading
checklist is formatted, and how we can recruit more people to get
patches written</p></li>
</ul>
<h1><a href="https://wiki.debian.org/Sprints/2017/Emacsen">Debian Emacs Team meeting/sprint</a></h1>
<ul>
<li><p>plans to finally drop our emacsXY binary packages, and just have a
single version of Emacs in the archive, so that we no longer have to
deal with bugs due to someone still having emacs21 installed
(David’s idea; Rob’s implementation; Sean’s mostly-helpful comments)</p></li>
<li><p>other plans to simplify and otherwise improve the
<a href="https://www.debian.org/doc/packaging-manuals/debian-emacs-policy">Debian Emacsen policy</a></p></li>
<li><p>finally finished off the work needed to RM emacs24—nine months
later—including a lot of NMUs</p></li>
<li><p>mentoring a junior team member</p></li>
</ul>
<p>Unfortunately we didn’t make any significant progress towards
converting all addons to use dh_elpa, as the work is not that much
fun. Might be worth a more focused sprint next year.</p>
<p><a href="http://pkg-emacsen.alioth.debian.org/meetings/dc17/">Report on team website</a></p>
<h1><a href="https://debconf17.debconf.org/talks/36/">Git for Debian packaging BoF</a> & follow-up conversations</h1>
<p>The BoF was far more about dgit than I had wanted; however, I think
that this was mostly because people had questions about dgit, rather
than any unintended lecturing by me.</p>
<p>I believe that several people came away from DebConf thinking that
starting to use dgit would improve Debian for themselves and for users
of their packages.</p>
I went all the way to Montréal for DebConf17, and all I got was a new MUA
https://spwhitton.name//blog/entry/debconf17/
2017-08-18T02:42:57Z
2017-08-17T21:50:51Z
<table class="img"><caption>This year’s group photo (by Aigars Mahinovs). I really like the tagline</caption><tr><td><a href="https://spwhitton.name//blog/img/debconf17.jpg"><img src="https://spwhitton.name//blog/entry/debconf17/500x183-debconf17.jpg" width="500" height="183" class="img" /></a></td></tr></table>
<p>On Sunday night I got back from Montréal, where I attended both
DebCamp17 and DebConf17. It was a wonderful two weeks. All I really
did was work on Debian for roughly eight hours per day, interspersed
with getting to know both people I’ve been working with since I first
began contributing to Debian in late 2015, and people I didn’t yet
know. But this was all I really needed to be doing. There was no
need to engage in distracting myself.</p>
<p>I enjoyed the first week more. There were sufficiently few people
present that you could know at least all of their faces, and
interesting-sounding talks didn’t interrupt making progress on one’s
own work or unblocking other people’s work. In the second week it was
great to meet people who were only present for the second week, but it
felt more like regular Debian, in that I was often waiting on other
people or they were waiting on me.</p>
<p>While I spent one morning actually writing fresh code, and I did a
fair amount of pure packaging work, the majority of my time was poured
into (i) <a href="https://www.debian.org/doc/debian-policy/">Debian Policy</a>;
(ii) discussions within the
<a href="https://pkg-emacsen.alioth.debian.org/">Emacs team</a>; and (iii)
discussions about <a href="https://manpages.debian.org/dgit">dgit</a>. This was
as I expected. During DebConf, it’s not that useful to seclude
oneself and sufficiently reacquaint oneself with a codebase that one
can start producing patches, because that can be done anywhere in the
world, without everyone else around. It’s far more useful to bring
different people together to get projects unblocked. I did some of
that for my own work, and also tried to help other people’s, including
those who weren’t able to attend the conference.</p>
<p>In my ordinary life, taking a step back from the methods by which I
protect my PGP keys and other personal data, I can appear to myself as
a paranoid extremist, or some kind of data hoarder. It was comforting
to find at DebConf plenty of people who go way further than me:
multiple user accounts on their laptop, with separate X servers, for
tasks of different security levels; PGP keys on smartcards; refusal to
sign my PGP key based on government-issued ID alone; use of Qubes OS.
One thing that did surprise me was to find myself in a minority for
using the GNOME desktop; I had previously assumed that most people
deep in Debian development didn’t bother with tiling window managers.
Turns out they are enthusiastic to talk about the trade-offs between
window managers while riding the subway train back to our
accommodation at midnight—who knew such people existed? I was
pleased to find them. One evening, I received a tag-teamed live
tutorial in using i3’s core keybindings, and the next morning GNOME
seemed deeply inelegant. The insinuation began, but I was immediately
embroiled in inner struggle over the fact that i3 is a very popular
tiling window manager, so it wouldn’t be very cool if I were to start
using it. This difficulty was compounded when I learned that the
Haskell team lead still uses xmonad. The struggle continues.</p>
<p>I hope that I’ve been influenced by the highly non-judgemental and
tolerant attitudes of the attendees of the conference. While most
people at the conference were pretty ordinary—aside from wanting to
talk about the details of Debian packaging and processes!—there were
several people who rather visibly rejected social norms about how to
present themselves. Around these people there was nothing of the
usual tension. Further, in contrast with my environment as a graduate
student, everyone was extremely relaxed about how everyone was
spending their time. People drinking beer in the evenings were
sitting at tables where other people were continuing to silently work
on Debian. It is nice to have my experience in Montréal as a
reference to check my own judgemental tendencies.</p>
<p>I came away with a lot more than a new MUA: a certainty that I want to
try to get to next year’s conference; friends; a real life community
behind what was hitherto mostly a hobby; a long list of tasks and the
belief that I can accomplish them; a list of PGP fingerprints to sign;
a new perspective on the arguments that occur on Debian mailing lists;
an awareness of the risk of unconsciously manipulating other community
members into getting work done.</p>
<p>With regard to the MUA, I should say that I did not waste a lot of
DebConf time messing with its configuration. I had actually worked
out a <a href="https://notmuchmail.org/">notmuch</a> configuration some months
ago, but couldn’t use it because I couldn’t figure out how to
incorporate my old mail archives into its index. Fortunately
notmuch’s maintainer is also on the Emacs team … he was able to
confirm that the crazy solution I’d come up with was not likely to
break notmuch’s operating assumptions, and so I was able to spend
about half an hour copying and pasting the configuration and scripts
I’d previously developed into my homedir, and then start using notmuch
for the remainder of the conference. The main reason for wanting to
use notmuch was to handle Debian mailing list volume more effectively
than I’m able to with mutt, so I was very happy to have the
opportunity to pester David with newbie questions.</p>
<p>Many, many thanks to all the volunteers whose efforts made DebCamp17
and DebConf17 possible.</p>
'Do you really need to do that?'
https://spwhitton.name//blog/entry/gnulinux_needtodothat/
2016-09-28T15:37:49Z
2016-09-28T15:25:09Z
<p>A new postdoc student arrived at our department this semester, and
after learning that he uses GNU/Linux for all his computing, I invited
him along to <a href="http://www.grundrisse.org/tfughh/">TFUG</a>. During some
of our meetings people asked “how could I do X on my GNU/Linux
desktop?” and, jokingly, the postdoc would respond “the answer to your
question is ‘do you really need to do that?’” Sometimes the more
experienced GNU/Linux users at the table would respond to questions by
suggesting that the user should simply give up on doing X, and the
postdoc would slap his thigh and laugh and say “see? I told you
that’s the answer!”</p>
<p>The phenomenon here is that people who have at some point made a
commitment to at least try to use GNU/Linux for all their computing
quickly find that they have come to value using GNU/Linux more than
they value engaging in certain activities that only work well/at all
under a proprietary operating system. I think that this is because
they get used to being treated with respect by their computer. And
indeed, one of the reasons I’ve almost entirely given up on computer
gaming is that computer games are non-free software. “Are you sure
you need to do that?” starts sounding like a genuine question rather
than simply a polite way of saying that what someone wants to do can’t
be achieved.</p>
<p>I suggest that this is a blessing in disguise. The majority of the
things that you can only do under a proprietary operating system are
things that it would be good for you if you were to switch them out
for other activities. I’m not suggesting that switching to a
GNU/Linux is a good way to give up on the entertainment industry.
It’s a good way of <em>moderating</em> your engagement with the entertainment
industry. Rather than logging onto Netflix, you might instead pop in
a DVD of a movie. You can still engage with contemporary popular
culture, but the technical barriers give you an opportunity to
moderate your consumption: once you’ve finished watching the movie,
the software won’t try to get you to watch something else by making a
calculation as to what you’re most likely to assent to watching next
based on what you’ve watched before. For this behaviour of the
Netflix software is just another example of non-free software working
against its user’s interests: watching a movie is good for you, but
binge-watching a TV series probably isn’t. In cases like this, living
in the world of Free Software makes it easier to engage with media
healthily.</p>
Skype inside Firejail version 0.9.40-rc1
https://spwhitton.name//blog/entry/firejailskype/
2016-06-15T12:58:51Z
2016-05-30T01:31:10Z
<p>Since my PGP key is on its way into the Debian Maintainers keyring,
I feel that I should be more careful about computer security. This
week I find that I need to run Skype in order to make some calls to
some landlines. With the new release candidate of Firejail, it’s
really easy to minimise the threat from its non-free code.</p>
<p>Firstly, check that the Skype .deb you download from their website
merely installs files and does not run any prerm or postinst scripts.
You can run <code>dpkg-deb --control skype-debian_4.3.0.37-1_i386.deb</code> and
confirm that there’s nothing executable in there. You should also
list the contents with <code>dpkg-deb --contents
skype-debian_4.3.0.37-1_i386.deb</code>, and confirm that it doesn’t install
anything to places that will be executed by the system, such as to
<code>/etc/cron.d</code>. For my own reference the safe .deb has sha256 hash
<code>a820e641d1ee3fece3fdf206f384eb65e764d7b1ceff3bc5dee818beb319993c</code>,
but you should perform these checks yourself.</p>
<p>Then install Firejail and Xephyr. You can hook Firejail and Xephyr
together manually, but Firejail version 0.9.40-rc1 can do it for you,
which is very convenient, so we install that from the Debian
Experimental archive:</p>
<pre><code># apt-get install xserver-xephyr firejail/experimental
</code></pre>
<p>Here’s an invocation to use the jail:</p>
<pre><code>$ firejail --x11=xephyr --private --private-tmp --net=eth0 openbox
$ DISPLAY=$(firemon --x11 | grep "DISPLAY" | sed 's/ DISPLAY //') \
firejail --net=eth0 --private --private-tmp skype
</code></pre>
<p>This takes advantage of Firejail’s existing jail profile for Skype.
We get the following:</p>
<ul>
<li>A private <code>/home/you</code> so that Skype cannot access any of your files
(disadvantage is that Skype can’t remember your username and
password; you can look at <code>--private=directory</code> to do something
persistent).</li>
<li>A private /tmp to avoid it going near any sockets.</li>
<li>A private X11 server so that Skype cannot access the contents of any
of your other windows (X11 inter-application security is virtually
non-existent).</li>
<li>The Firejail profile for Skype restricts the hardware it can access
to only what it needs i.e. network, camera, microphone etc.</li>
<li>The openbox window manager so you can close overlapping windows.</li>
</ul>
<p>This isn’t perfect. An annoyance is that the Xephyr window sticks
around when you close Skype. More seriously, computer security is
always an attacker’s advantage game, so this is just an attempt at
reducing (optimistically: minimising) the threat posed by non-free
code.</p>
<p><em>Update 2016/vi/1:</em> use openbox</p>
<p><em>Update 2016/vi/15:</em> use <code>--net=eth0</code> or the X11 jail is <a href="https://firejail.wordpress.com/documentation-2/x11-guide/">not actually secure</a></p>
dh_make_elpa & dh_elpa_test
https://spwhitton.name//blog/entry/dh_make_elpa_test/
2016-05-05T18:10:55Z
2016-05-05T18:08:30Z
<p>I recently completed and released some work on Debian’s tooling for
packaging Emacs Lisp addons to GNU Emacs. Emacs grew a package
manager called <code>package.el</code> a few years ago, and last year David
Bremner wrote the <code>dh_elpa</code> tool to simplify packaging addons for
Debian by leveraging <code>package.el</code> features. Packaging a series of
addons for Debian left me with a wishlist of features for dh_elpa and
I was recently able to implement them.</p>
<p>Debian tooling generally uses Perl, a language I didn’t know before
starting on this project. I was fortunate enough to receive a free
review copy of <em>Perl 5 by Example</em> when I attended a meeting of the
Bay Area Linux Users Group while I was visiting San Francisco a few
months ago. I accepted the book with the intent of doing this work.</p>
<h1>dh_make_elpa</h1>
<p><code>dh_make_elpa</code> (at present available from Debian experimental) is a
Perl script to convert a git repository cloned from the upstream of an
Emacs Lisp addon to a rudimentary Debian package. It performs a lot
of guesswork, and its simple heuristics are something I hope to
improve on. Since I am new to object-oriented program design in Perl
and I wanted to leverage object-oriented Debian tooling library code,
I took the structure of my project from <code>dh_make_perl</code>. In this
manner I found it easy and pleasant to write a maintainable script.</p>
<h1>dh_elpa_test</h1>
<p>A lot of Emacs Lisp addon packages use a program called Cask to manage
the Emacs Lisp dependencies needed to run their test suites. That
meant that <code>dh_auto_test</code> often fails to run Emacs Lisp addon package
test suites. Since the Debian packaging toolchain already has
advanced dependency management, it’s undesirable to involve Cask in
the package build pipeline if it can be avoided. I had been copying
and pasting the code needed to make the tests run in our environment
to the <code>debian/rules</code> files of each package whose test suite I wanted
to run.</p>
<p><code>dh_elpa_test</code> tries to detect Emacs Lisp addon package test suites
and run them with the workarounds needed in our environment. This
avoids boilerplate in <code>debian/rules</code>. <code>dh_elpa_test</code> also disables
<code>dh_auto_test</code> to avoid a inadvertent Cask invocation.</p>
<h1>Future & acknowledgements</h1>
<p>My hope for this work was to make it easier and faster to package
Emacs Lisp addon packages for Debian, for my own sake and for anyone
new who is interested in joining the
<a href="http://pkg-emacsen.alioth.debian.org/">pkg-emacsen team</a>. In the
future, I want to have <code>dh_elpa_test</code> generate an autopkgtest
definition so that a <code>Testsuite: pkg-emacsen</code> line in <code>debian/control</code>
is enough to have an Emacs Lisp addon package test suite run on
<a href="https://ci.debian.net/">Debian CI</a>.</p>
<p>I’m very grateful to David Bremner for reviewing and supporting this
work, and also for supporting my Emacs Lisp addon packaging work more
generally.</p>
Expiring the GNOME keyring daemon's SSH keys cache
https://spwhitton.name//blog/entry/gnomesshclear/
2015-11-18T17:09:12Z
2015-07-03T22:39:00Z
<p>The GNOME keyring is very convenient; it figures out what keys you need
to unlock and pops up the relevant dialogs to do so at the right times.
But by default it caches them until you logoff. You can have caches of
PGP passphrases expire:</p>
<pre><code>gsettings set org.gnome.crypto.cache gpg-cache-ttl 300
gsettings set org.gnome.crypto.cache gpg-cache-method 'timeout'
</code></pre>
<p>but per <a href="https://bugzilla.gnome.org/show_bug.cgi?id%3D525574">this bug</a>
you can’t do the same for SSH keys.[1] An alternative is to check for
X11 activity using the <code>xprintidle</code> utility, and clear all keys when the
user has been idle for five minutes. This crontab entry does that:</p>
<pre><code>#!/bin/sh
while true; do
if [ $(xprintidle) -ge 300000 ]; then
ssh-add -D 2>/dev/null
fi
sleep 300
done
</code></pre>
<p>I’ve got Xfce running <code>pkill -u $USER /path/to/this/script;
/path/to/this/script &</code> as part of its startup sequence.</p>
<h1>Notes</h1>
<p>[1] You can just turn off the SSH key handling of gnome-keyring-daemon
though I’m not sure this works in all versions of gnome-settings-daemon
in circulation. The gconf boolean key might be
<code>/apps/gnome-keyring/daemon-components/ssh</code>.</p>