d-iKiBi’s bloghttp://mraw.org/blog/tags/d-i/KiBi’s blogikiwiki2016-08-03T17:44:34ZD-I Stretch Alpha 1http://mraw.org/blog/2015/07/22/D-I_Stretch_Alpha_1/2016-08-03T17:44:34Z2015-07-22T11:50:00Z
<p>Time for a quick recap of the beginning of the <em>Stretch</em> release cycle
as far as the Debian Installer is concerned:</p>
<ul>
<li>It took nearly 3 months after the <em>Jessie</em> release, but <code>linux</code>
finally managed to get into shape and fit for migration to
<code>testing</code>, which unblocked the way for an <code>debian-installer</code>
upload.</li>
<li>Trying to avoid last-minute fun, I’ve
<a href="https://lists.debian.org/debian-release/2015/07/msg00168.html">updated the britney freeze hints file</a>
to put into place a <code>block-udeb</code> on all packages.</li>
<li>Unfortunately, a recent change in <code>systemd</code> (implementation of
<a href="https://lists.debian.org/debian-devel/2015/06/msg00018.html">Proposal v2: enable stateless persistant network interface names</a>)
found its way into <code>testing</code> a bit before that, so I’ve had my
share of last-minute fun anyway! Indeed, that resulted in installer
system and installed system having different views on interface
naming. Thankfully I was approached by Michael Biebl right before
my final tests (and <code>debian-installer</code> upload) so there was little
head scratching involved. Commits were already in the <code>master</code>
branch so a little plan was proposed in
<a href="https://lists.debian.org/debian-release/2015/07/msg00234.html">Fixing udev-udeb vs. net.ifnames for Stretch Alpha 1</a>. This was implemented in two shots, given the
<a href="https://lists.debian.org/debian-release/2015/07/msg00254.html">extra round trip</a>
due to having dropped a binary package in the meanwhile and due to
<code>dak</code>’s complaining about it.</li>
<li>After the usual round of build (see
<a href="https://buildd.debian.org/status/package.php?p=debian-installer&suite=sid">logs</a>),
and <code>dak copy-installer</code> to get installer files from <code>unstable</code> to
<code>testing</code>, and <code>urgent</code> to get the source into <code>testing</code> as well
(see
<a href="https://lists.debian.org/debian-release/2015/07/msg00271.html">request</a>),
I’ve asked Steve McIntyre to start building images through <code>debian-cd</code>. As
expected, some troubles were run into, but they were swiftly fixed!</li>
<li>While Didier Raboud and Steve were performing some tests with the
built images, I’ve prepared the
<a href="https://lists.debian.org/debian-devel-announce/2015/07/msg00005.html">announcement for dda@</a>,
and updated the usual pages in the <code>debian-installer</code> corner of the website:
<a href="https://www.debian.org/devel/debian-installer/News/2015/20150721">news entry</a>,
<a href="https://www.debian.org/devel/debian-installer/errata">errata</a>, and
<a href="https://www.debian.org/devel/debian-installer/">homepage</a>.</li>
<li>Once the website was rebuilt to include these changes, I’ve sent
the announce, and
<a href="https://lists.debian.org/debian-release/2015/07/msg00350.html">lifted all <code>block-udeb</code></a>.</li>
</ul>
<p><em>(On a related note, I’ve started tweeting rather regularly about my
actions, wins & fails, using the
<a href="https://twitter.com/hashtag/debianinstaller">#DebianInstaller</a>
hashtag. I might try and aggregate
<a href="https://twitter.com/CyrilBrulebois">my tweets as @CyrilBrulebois</a>
into more regular blog posts, time permitting.)</em></p>
<p><strong>Executive summary:</strong>
<a href="https://lists.debian.org/debian-devel-announce/2015/07/msg00005.html">D-I Stretch Alpha 1</a>
is released, time to stretch a bit!</p>
<p><a href="http://mraw.org/blog/2015/07/22/stretching-cat.svg"><img src="http://mraw.org/blog/2015/07/22/stretching-cat.svg" alt="Stretching cat" class="img" /></a></p>
<p><em>(Credit: rferran on <a href="https://openclipart.org/detail/193429/gat-4">openclipart</a>)</em></p>
Why is my package blocked?http://mraw.org/blog/2014/08/10/Why_is_my_package_blocked/2014-08-10T19:48:22Z2014-08-10T17:45:00Z
<p>A bit of history: A while ago udeb-producing packages were getting
frozen on a regular fashion, when a d-i release was about to be
cut. While I wasn’t looking at the time, I can easily understand the
reasons behind that: d-i is built upon many components, it takes some
time to make sure it’s basically in shape for a release, and it’s very
annoying when a regression sneaks in right before the installation
images get built.</p>
<p>I took over d-i release maintenance in May 2012 and only a few uploads
happened before the <code>wheezy</code> freeze. I was only discovering the job at
the time, and I basically released whatever was in <code>testing</code> then. The
freeze began right after that (end of June), so I started double
checking things affecting d-i (in addition to or instead of the review
performed by other release team members), and unblocking packages when
changes seemed safe, or once they were tested.</p>
<p>A few uploads happened after the <code>wheezy</code> release and there’s already
a <code>Jessie Alpha 1</code> release. I was about to release <code>Jessie Beta 1</code>
after some fair bits of testing, a <code>debian-installer</code> upload, and the
only remaining bits were: building installation images (hello Steve),
and of course communication (mail announce and website update).</p>
<p>Unfortunately a new upstream release reached <code>testing</code> in the
meanwhile, breaking the installer in several ways. I’ll give details
below, of course not because I want to point finger at the maintainer,
but to illustrate the ramifications that a single package’s migrating to
<code>testing</code> can induce.</p>
<ul>
<li><p>parted 3.2-1 was uploaded on 2014-07-30 and migrated on 2014-08-05.</p></li>
<li><p>parted 3.2-2 fixed a regression reported in Ubuntu only
(<a href="https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1352252">LP#1352252</a>)
which I also hit with images built locally after that migration.</p></li>
<li><p>I then built some images locally using fixed parted packages but
then discovered that auto-lvm was still broken, which I reported in
<a href="https://bugs.debian.org/757417">#757417</a>.</p></li>
<li><p>After some investigation Colin confirmed some behavioral changes in
this new parted release, which imply the need for an update of
several other <code>partman-*</code> components:
<a href="https://bugs.debian.org/757661">#757661</a>,
<a href="https://bugs.debian.org/757662">#757662</a>,
<a href="https://bugs.debian.org/757663">#757663</a>,
<a href="https://bugs.debian.org/757664">#757664</a>,
<a href="https://bugs.debian.org/757665">#757665</a>,
<a href="https://bugs.debian.org/757666">#757666</a>.</p></li>
<li><p>Thankfully fixes have been added for all of those, but more testing is needed
before possibly urgenting those packages so that they get into
<code>testing</code> as soon as possible.</p></li>
</ul>
<p>Since I’d like to avoid such experience in the future, I’ll probably
reintroduce the old method and freeze all udeb-producing packages
during next d-i releases.</p>
<p>So you know why it might happen. Your next question might be: “What to
do when your package is getting caught in that net?”. In that case,
please get in touch with both <code>debian-release@</code> and <code>debian-boot@</code>
asking for an unblock. I’ll then review your particular package, and
either let it migrate to <code>testing</code>, or delay it until after the
release.</p>
<p><strong>Update:</strong> <a href="https://lists.debian.org/debian-devel-announce/2014/08/msg00003.html">official announcement</a>.</p>
D-I Jessie Alpha 1http://mraw.org/blog/2014/03/19/D-I_Jessie_Alpha_1/2014-03-19T02:05:04Z2014-03-19T02:05:00Z
<p><a href="http://mraw.org/blog/2014/03/19/wazza.jpg"><img src="http://mraw.org/blog/2014/03/19/wazza.jpg" width="487" height="280" class="img" /></a></p>
<p><strong>What’s up?</strong> That was the sound of a new Debian Installer release,
an early
<a href="https://lists.debian.org/debian-devel-announce/2014/03/msg00009.html">Alpha 1 for the Jessie release cycle</a>.</p>
<p>As usual, see the
<a href="http://www.debian.org/devel/debian-installer/">Debian Installer section</a>
of the Debian website, in particular the
<a href="http://www.debian.org/devel/debian-installer/errata">errata page</a>
which lists important, known issues. Then give it a try, and
<a href="http://www.debian.org/releases/stable/amd64/ch05s04.html.en#problem-report">report bugs</a>!</p>
<p>Let’s see if we can keep the
<a href="http://qa.debian.org/data/bts/graphs/by-maint/debian-boot@lists.debian.org.png">debian-boot@ bug count</a>
below 1400 for a while, even if we get many new installation
reports. Last weeks have been busy:</p>
<p><a href="http://mraw.org/blog/2014/03/19/debian-boot-lately.png"><img src="http://mraw.org/blog/2014/03/19/debian-boot-lately.png" width="145" height="329" class="img" /></a></p>
<p>Speaking of which, if you feel like helping with the triaging effort,
there’s now a bug type called “installer bugs” on
<a href="http://udd.debian.org/bugs/">UDD’s Bugs Search page</a>. <code>;)</code></p>
Fixing bugshttp://mraw.org/blog/2013/09/17/Fixing_bugs/2013-12-17T02:11:29Z2013-09-17T01:10:00Z
<p>It’s a somewhat strange feeling to spend time fixing things that broke
instead of implementing new things, but it’s not like I’m a creative
guy anyway…</p>
<ul>
<li><p><code>buildd.debian.org</code>
<a href="http://lists.debian.org/debian-infrastructure-announce/2013/09/msg00001.html">went down</a>,
but
<a href="http://lists.debian.org/debian-infrastructure-announce/2013/09/msg00002.html">it’s now up again</a>
thanks to the relevant admins. The
<a href="http://debblog.philkern.de/2013/09/buildddebianorg.html">CGI part mentioned by Philipp</a>
was fun to debug: the CGI worked when called from a shell, but not
from Apache (with an apparently strange DNS resolution error). I
suggested attaching it with <code>strace</code>, and the result was even
stranger: a connection to <code>nscd</code>’s socket was attempted but the DNS
resolution through the network wasn’t. A closer look revealed the
<code>nsswitch.conf</code> file was read, and its configuration was OK, so
what? Looking at <code>libnss_dns.so.2</code>, one could see the usual
syscalls for library loading: <code>open</code>, <code>read</code>, <code>fstat</code>, <code>mmap</code>… oh
wait, <code>mmap</code> failed with <code>ENOMEM (Cannot allocate memory)</code>. Tollef
<a href="http://anonscm.debian.org/gitweb/?p=mirror/dsa-puppet.git;a=commitdiff;h=721ad7172f27a55de960d3f77c00ea649692be22">bumped the <code>rlimits</code> on the Apache side</a>,
and that was it.</p></li>
<li><p>Linux kernel ABI bump notifications: they were
<a href="https://lists.debian.org/E1VKL1F-0001pH-No@ravel.debian.org">acting weird</a>
since kernel people resumed uploading <code>-trunk-</code> kernels to
<code>experimental</code>. That was identified a while ago, but since I like
<a href="https://lists.debian.org/20130914212358.GB27003@mraw.org">tested bugfixes</a>,
I actually did wait for it to happen; fixed in
<a href="http://anonscm.debian.org/viewvc/d-i?view=revision&revision=68876">r68876</a>.</p></li>
<li><p>Of course, d-i’s git repository
<a href="http://anonscm.debian.org/gitweb/?p=d-i/debian-installer.git;a=commitdiff;h=5edeb70ea1406d57909e44d0f0becbf5137f1738">was updated</a>
to bump the ABI from <code>3.10-2-*</code> to <code>3.10-3-*</code> accordingly.</p></li>
<li><p><a href="http://bugs.debian.org/722939">#722939</a> was reported against
<code>udev-udeb</code> since depending on a deb library isn’t a good thing
when you’re an udeb binary.</p></li>
<li><p>Trying to look into d-i build failures earlier this month,
<a href="https://lists.debian.org/20130916231527.GB21028@mraw.org">I thought I managed to reproduce the issue</a>,
but that was just my misunderstanding the way apt works. Long story
short, <code>*InRelease</code> and <code>*Packages</code> files are checked before
they’re put under <code>lists/</code>; modifying the contents isn’t expected:
the modification time is used to set the <code>If-Modified-Since</code> header
when trying to fetch a new version from the server, and it’s OK to
get a <code>304 Not Modified</code> in that case. As a side effect, that means
the files can be hand-edited, for example because you need to work
around the dependency bug mentioned above, and one will still get
<code>Hit</code> lines for all those files. If something goes wrong, one can
still <code>rm</code> the files and start over, but that looks like a large
hammer. Let’s see if the issue can get reproduced (and debugged!)
later on.</p></li>
</ul>
<p>For those last two points, the long term plan is:</p>
<ul>
<li><p>To check udeb installability automatically to catch such dependency
issues as early as possible.</p></li>
<li><p>To keep many more logs, so that one can still read the whole output
a few weeks after the fact, and so that one can compare some logs
to try and spot difference in a semi-automated fashion.</p></li>
</ul>
<p>Hopefully getting this done this week (famous last words, eh?).</p>
My first Perl modulehttp://mraw.org/blog/2013/06/29/My_first_Perl_module/2013-12-17T02:11:29Z2013-06-29T18:10:00Z
<p>Look! A tiny <a href="http://en.wikipedia.org/wiki/TARDIS">TARDIS</a>-powered
release, as if we were a few years back, when Perl was hype! It’s
called <a href="http://search.cpan.org/~kibi/IPC-GimpFu/">IPC::GimpFu</a> and
abstracts talking to Gimp’s script-fu server, making it possible to
run a few commands/scripts without having to care too much about
Gimp’s start-up time, and without having to deal manually with the
<a href="http://docs.gimp.org/en/gimp-filters-script-fu.html">script-fu server protocol</a>.</p>
<p>At the moment, it was mainly tested against a local server, and
without caring much about the reply (there’s the nasty
<a href="https://bugzilla.gnome.org/583778">#583778</a> anyway), and it needs
some polishing to make reports from CPAN testers greener…</p>
<p>Source is at <a href="http://git.mraw.org/">http://git.mraw.org/</a> (<code>git clone git://git.mraw.org/ipc-gimpfu</code>).</p>
<p>More on the reasons why I needed this module and those Gimp filters in
a later post.</p>
First release candidatehttp://mraw.org/blog/2013/02/17/First_release_candidate/2013-12-17T02:11:29Z2013-02-17T22:30:00Z
<p>After a release cycle longer than between each beta (which is slightly
sad, but I can’t spend all my time on Debian), here comes the
<a href="https://lists.debian.org/debian-devel-announce/2013/02/msg00005.html">first release candidate of the Debian Installer for Wheezy</a>.</p>
<p>The
<a href="http://www.debian.org/devel/debian-installer/News/2013/20130217">Debian Installer 7.0 RC1 announce</a>
on the website has links to relevant bug reports in the Debian BTS, and the
<a href="http://www.debian.org/devel/debian-installer/errata">errata page</a>
lists things you probably want to know about (including gotchas with
<code>grub-install</code> we’ve been having for a while, now diagnosed, and
hopefully fixed for the next release candidate).</p>
<p>According to Arwen’s sleepy attitude, it’s officially time for a nap!</p>
<p><a href="http://mraw.org/blog/2013/02/17/sleepy-arwen.jpg"><img src="http://mraw.org/blog/2013/02/17/sleepy-arwen.jpg" width="426" height="372" alt="Sleepy Arwen" class="img" /></a></p>
Funny bug numbershttp://mraw.org/blog/2012/12/30/Funny_bug_numbers/2013-12-17T02:11:29Z2012-12-30T00:30:00Z
<p><a href="http://bugs.debian.org/696699">#696699</a> was already a funny bug number,
but <a href="http://bugs.debian.org/696969">#696969</a> is even better. d-i FTW!</p>
X-mas gifthttp://mraw.org/blog/2012/12/25/X-mas_gift/2013-12-17T02:11:29Z2012-12-25T21:50:00Z
<p>I’ve been working on some autotesting features for <code>d-i</code> over the past
few weeks, and I’ve started lagging behind on my <code>debian-boot@</code>
reading accordingly, by several hundreds of mails. Today’s gift to myself: <strong>no more unread/unanswered mails in
that mailbox!</strong></p>
<p>Even if I’ve prepared things for a possible <code>d-i wheezy rc1</code> release
around Christmas, several things weren’t ready, most notably:
<code>grub-installer</code>. Hopefully <a href="http://bugs.debian.org/696615">#696615</a>
will be fixed soonish, probably by asking where to write when
<code>/target(/boot)</code> isn’t on <code>(hd0)</code>.</p>
<h3>Wanted!</h3>
<p>Speaking of <code>grub-installer</code>, if anyone can reproduce
<a href="http://bugs.debian.org/681227">#681227</a>, I’m all ears! Wouter has a
workaround for it (only in <code>sid</code> for now), but I’d very much like to
track down the root cause for that one. It is supposedly reproducible
with <code>wheezy beta 4</code> images and with weekly builds (they use
components from <code>testing</code>), all of those are available from the
<a href="http://www.debian.org/devel/debian-installer/">debian-installer website</a>.</p>
d-i hacking recipe #3: Debugging debconfhttp://mraw.org/blog/2012/12/23/d-i_hacking_recipe_3/2013-12-17T02:11:29Z2012-12-23T00:00:00Z
<p><strong>Problem #3:</strong> How to find out what’s going on with debconf?</p>
<p>Slightly longer version: As reported in
<a href="http://bugs.debian.org/679327">#679327</a>, the grub prompt during the
installation process is entitled “Configuring man-db”, which isn’t
exactly great. Given <code>man-db</code> is a known dpkg trigger, I
suspected this would be the reason for the broken title, and here’s
how I debugged it.</p>
<p>For starters, using d-i basically means asking a lot of questions,
which is implemented using the debconf mechanism. One should note that
two implementations are available:</p>
<ol>
<li>the historic implementation, in Perl: <code>debconf</code></li>
<li>the C reimplementation: <code>cdebconf</code></li>
</ol>
<p>d-i uses <code>cdebconf</code> udebs, but joy begins when packages get installed
in <code>/target</code>: <code>debconf</code> is used there. We’ll see why that matters.</p>
<p><strong>Recipe #3:</strong> Set <code>DEBCONF_DEBUG=developer</code> and read logs!</p>
<ol>
<li><p>Both implementations support the <code>DEBCONF_DEBUG</code> environment
variable. The installer supports passing that as a kernel
parameter; example from the syslinux prompt: select the “Graphical
install” entry, press “Tab”, remove <code>-- quiet</code> and put
<code>DEBCONF_DEBUG=developer</code> there instead.</p></li>
<li><p>Let’s look at <code>/var/log/syslog</code>; there’s a <code>tail -f</code> on it in VT4, but
one can run <code>grep</code> and friends on it in VT2 or VT3. There, one can see what
happens at the debconf level (the debconf protocol is documented in
<code>debconf-devel(7)</code>). Tiny excerpt (timestamps removed for clarity):</p>
<pre><code>frontend: --> GET preseed/early_command
frontend: <-- 0
…
frontend: --> GET debian-installer/framebuffer
frontend: <-- 0 true
…
debconf: --> GET debconf/language
debconf: <-- 0 en
debconf: --> SET debconf/language en
debconf: Setting debconf/language to en
debconf: <-- 0 value set
debconf: --> GET debconf/priority
debconf: <-- 0 high
debconf: --> GET rescue/enable
debconf: <-- 0 false
</code></pre></li>
<li><p>The interesting point was titles, right? So let’s look at the last
<code>TITLE</code> occurrences:</p>
<pre><code>debconf: --> SETTITLE debian-installer/main-menu-title
debconf: --> SETTITLE debian-installer/grub-installer/title
in-target: debconf (developer): ----> TITLE Configuration de man-db
debconf: --> TITLE Configuration de man-db
in-target: debconf (developer): <-- TITLE Configuration de man-db
in-target: debconf (developer): ----> TITLE Configuration de man-db
in-target: debconf (developer): ----> TITLE Configuration de grub-pc
debconf: --> TITLE Configuration de grub-pc
in-target: debconf (developer): <-- TITLE Configuration de grub-pc
in-target: debconf (developer): ----> TITLE Configuration de grub-pc
in-target: debconf (developer): ----> TITLE Configuration de man-db
debconf: --> TITLE Configuration de man-db
in-target: debconf (developer): <-- TITLE Configuration de man-db
in-target: debconf (developer): ----> TITLE Configuration de man-db
in-target: debconf (developer): ----> TITLE Configuration de grub-pc
debconf: --> TITLE Configuration de grub-pc
in-target: debconf (developer): <-- TITLE Configuration de grub-pc
in-target: debconf (developer): ----> TITLE Configuration de grub-pc
debconf: --> SETTITLE debian-installer/grub-installer/title
</code></pre>
<p>Bad news: the last one is about <code>grub</code>, so the title should be correct, right?</p></li>
<li><p>At this point, it might be the Gtk frontend behaving
strangely. It’s shipped in <code>cdebconf-gtk-udeb</code>, built from the
<code>cdebconf</code> source. Let’s look:</p>
<ul>
<li><code>src/modules/frontend/gtk/ui.c</code> has <code>cdebconf_gtk_update_frontend_title()</code>, which does what the function name suggests.</li>
<li><code>src/modules/frontend/gtk/di.c</code> has <code>cdebconf_gtk_di_run_dialog()</code>, which calls the first function.</li>
<li><p><code>src/modules/frontend/gtk/progress.c</code> has <code>cdebconf_gtk_show_progress()</code> (also calls the first
function), which comes with the following comments:</p>
<pre><code> /** Show the progress widgets.
*
* This will actually add the widgets to the corresponding containers.
* The main title saved when starting the PROGRESS operation will be restored
* from the value saved when START was called. This is needed when GO is
* called during a PROGRESS operation.
</code></pre></li>
</ul>
<p>Now that’s something! Even if the last entry is about <code>grub</code>, some
previous value could be restored and could be the reason for the
bad behaviour (that is easily confirmed by adding some
<code>debug_printf()</code> calls on <code>fe->title</code> in <code>cdebconf</code>, thanks to an
extra <code>"debug.h"</code> include). Maybe that’s what needs fixing!</p></li>
<li><p>Now it’s time to take a step back. A d-i environment is nice, but
testing things can easily become a burden. Taking a random <code>wheezy</code> or <code>sid</code>
chroot, and installing/removing a tiny package shipping a manpage
should be enough to run into the <code>man-db</code> trigger. Exporting
<code>DEBCONF_DEBUG=developer</code> there too, let’s either install or
remove <code>x11-apps</code> (the trigger does the same job, and the debconf
trace is the same), here’s the output:</p>
<pre><code>Processing triggers for man-db ...
debconf (developer): frontend started
debconf (developer): frontend running, package name is man-db
debconf (developer): starting /var/lib/dpkg/info/man-db.config configure /usr/share/man
debconf (developer): <-- VERSION 2.0
debconf (developer): --> 0 2.0
debconf (developer): <-- INPUT medium man-db/install-setuid
debconf (developer): --> 30 question skipped
debconf (developer): <-- GO
debconf (developer): --> 0 ok
debconf (developer): starting /var/lib/dpkg/info/man-db.postinst triggered /usr/share/man
debconf (developer): <-- VERSION 2.0
debconf (developer): --> 0 2.0
debconf (developer): <-- GET man-db/auto-update
debconf (developer): --> 0 true
</code></pre>
<p>Even if one didn’t know about the <code>cdebconf</code>/<code>debconf</code> thing, the
<code>frontend started</code> bit in the d-i syslog would have been the key:
it’s only found in <code>debconf</code>, in the <code>frontend</code> script. That one
has several ways to determine the package being acted on, and it
finally calls:</p>
<pre><code>debug developer => "frontend running, package name is $package";
$frontend->default_title($package) if length $package;
</code></pre>
<p>Tada, that’s likely to be the issue.</p></li>
<li><p>Tweaking that frontend script, it’s easy to make sure that the
code path for this use case is:</p>
<pre><code>elsif ($ARGV[0]=~m!^.*/(.*?)\.(?:postinst|postrm|prerm)$!) {
$package=$1;
}
</code></pre>
<p>Since <code>$ARGV[1]</code> is the action being passed to the maintainer
script, one can intercept the <code>triggered</code> action, and avoid
emitting a title update in this case; I’ve therefore reassigned
<a href="http://bugs.debian.org/679327">#679327</a> to the <code>debconf</code> package,
and proposed <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=0001-frontend-Stop-emitting-title-updates-with-triggered-.patch;att=1;bug=679327">a patch implementing that</a>, which Joey Hess seems to
find reasonable.</p></li>
</ol>
<p>In my message to the bug report I wrote I actually tested it in a d-i
environment, and made sure the issue had gone away. How I did that
will likely be described in the next d-i hacking recipe.</p>
Another month, another betahttp://mraw.org/blog/2012/11/22/Another_month_another_beta/2013-12-17T02:11:29Z2012-11-22T01:05:00Z
<p>Today’s recipe:</p>
<ul>
<li>a day off</li>
<li>a long night of sleep</li>
<li>acid jazz music</li>
<li>some <a href="http://en.wikipedia.org/wiki/24_(TV_series)">24</a> episodes</li>
<li>coffee</li>
<li>trout and pasta</li>
<li>sleepy cats</li>
</ul>
<p>Result:
<a href="http://lists.debian.org/debian-devel-announce/2012/11/msg00005.html">Debian Installer 7.0 Beta4 release</a>!</p>
<p>Speaking of which, shameless plug: I'm giving a Debian Installer talk
at <a href="http://fr2012.mini.debconf.org/">mini-DebConf Paris</a> this sunday.</p>
<p>(<strong>Update</strong>:
<a href="http://mraw.org/2012/11/22/2012-11-25-Paris-mini-DebConf--re-discovering-the-Debian-Installer.pdf">slides</a> &
<a href="http://anonscm.debian.org/gitweb/?p=d-i/debian-installer.git;a=tree;f=doc/talks/d-i_paris_minidebconf12">LaTeX source</a>
for this talk.)</p>