builddKiBi’s bloghttp://mraw.org/blog/tags/buildd/KiBi’s blogikiwiki2013-12-17T02:11:29ZFixing 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>
Bus factorhttp://mraw.org/blog/2012/07/15/Bus_factor/2013-12-17T02:11:29Z2012-07-15T17:15:00Z
<p>Stuff/team I’m currently involved with:</p>
<ul>
<li><p>Debian System Administration: I’m just in the <code>porter-*</code> groups, so
that I can fulfill installation requests in various chroots on
Debian porterboxes; this means real DSA members can concentrate on
more important things while still keeping the turnaround quick for
developers who want to debug stuff on exotic architectures.
Reminder for that procedure:
<a href="http://dsa.debian.org/doc/install-req/">Chroot Install Request Guidelines</a>.</p></li>
<li><p>After having maintained the <code>kfreebsd-*</code> buildds for a while, I’m
still in the wanna-build team, meaning I can take care of give
backs, one of the most common requests on <code>debian-wb-team@</code>. It’s
been a while since it’s been split up from <code>debian-release@</code>, and
instructions are still available in
<a href="http://release.debian.org/wanna-build.txt">wanna-build.txt</a>.
Basically: anything buildd-related goes to
<code>$arch@buildd.debian.org</code> or <code>debian-wb-team@lists.debian.org</code>,
with the sole exception of binNMUs, which are handled by the
release team.</p></li>
<li><p>Speaking of which, I joined the release team a few months ago;
plenty of (not-so-)funny things to do, like coordinating
transitions to <code>testing</code>, and more recently, dealing with unblock
requests during the freeze. While the Debian world is usually
driven by the “just do” motto, there’s one area where one has to
learn to say “no, sorry”. Hopefully people won’t hate us for that,
and we’ll find alternative ways (like backporting specific fixes,
or postponing new features until <code>wheezy-backports</code> is open).</p></li>
<li><p>Given nobody on <code>debian-boot@</code> stepped up to prepare new
<code>debian-installer</code> releases, I figured I would give a hand there
until somebody more involved with <code>d-i</code> would manage that on the
long run. That’s
<a href="https://lists.debian.org/20120610232949.GA1059@mraw.org">a</a>
<a href="https://lists.debian.org/20120624215418.GU6468@mraw.org">lot</a>
<a href="https://lists.debian.org/20120708160952.GM29142@mraw.org">of</a>
<a href="https://lists.debian.org/20120709231514.GA6071@mraw.org">heavy</a>
<a href="https://lists.debian.org/20120711200313.GC6631@mraw.org">work</a>,
trying to get all involved packages into shape at a given moment,
and getting people to fix their stuff when anything
breaks. Hopefully that’ll work out and once CD images are ready, we
should be able to run some more tests on those before officially
publishing <code>d-i beta 1</code>.</p></li>
<li><p>And since the CD team is also understaffed, I joined Steve McIntyre
a while ago during a point release to see how that was done, and
how I could help. Things drove me to the other teams above, so I
couldn’t help much so far, but at least I managed to build a few
test images on <code>pettersson</code> (the very nice machine on which images
are built), using the <code>debian-cd</code> account. The intent was to make
sure <code>debian-installer</code> could safely migrate from <code>unstable</code> to
<code>testing</code>. That has happened lately, so images are being prepared.</p></li>
<li><p>And of course I’m still maintaining the whole X stack, with the
help of a few other guys on specific areas.</p></li>
</ul>
<p>I don’t feel like
<a href="http://en.wikipedia.org/wiki/Bus_factor">getting hit by a bus</a>, but I
would hate burning out and going away from all this.</p>
<p>People have called repeatedly for help in core packaging team. And
that has been true for the X Strike Force for a while (hint: Julien
only managed to pull me into this because I ported the Graphical
Installer <a href="http://mraw.org/2010/01/31/Saving_private_GI/">from DirectFB to X11</a>).</p>
<p>The same holds with non-packaging teams. I’m pretty sure Steve would
love to see new members in <code>debian-cd</code>. I’m also pretty sure having
more people involved in the <code>d-i</code> team would be very nice, especially
if one could find out how to make the whole release process less
insane than it is currently. I guess we could try out new ideas right
after the release; it feels to me that right now is just not the time
to fight the current release process.</p>
Smile of the dayhttp://mraw.org/blog/2011/07/20/Smile_of_the_day/2013-12-17T02:11:29Z2011-07-20T20:40:00Z
<p>It’s been a while since my last patches for GNU/kFreeBSD, and
<a href="http://www.christoph-egger.org/">Christoph</a> kindly took over the
<code>kfreebsd-*</code> build daemons from me some time ago, but still:
<a href="http://lists.debian.org/debian-devel/2011/07/msg00501.html">smile of the day</a>.
Thanks, Russ.</p>
Getting replaced by scriptshttp://mraw.org/blog/2011/04/11/Getting_replaced_by_scripts/2013-12-17T02:11:29Z2011-04-10T23:10:00Z
<p>As already
<a href="http://suihkulokki.blogspot.com/2011/04/getting-replaced-by-scripts-and-it.html">blogged by Riku</a>,
getting replaced by script is really great!</p>
<p>Until now, I’ve had a crontab fetching my <em>supporting-very-big-mails</em>
(up to 100MB or so) mailbox every few minutes, and looking into my
<code>=incoming-buildd/</code> maildir on a very regular fashion. With some
simple mutt maildir hooks, replying to a <em>Successful</em> log would
trigger extracting the <code>changes</code> file from there, setting some
options, like PGP inline signing, and the mail would be ready to go
back to the buildd. That part was just about being a GPG-signing
monkey, so really not a funny part.</p>
<p>Since we no longer have to worry about this boring and time-consuming
task, I’ve switched to a crontab firing up 4 times a day, and I try to
deal with all incoming mails at once. Coupled with the new filters
(<em>e.g.</em> on <code>out-of-date</code> packages on the <a href="https://buildd.debian.org/status/">buildd status</a> page), I started using my time to file
<code>FTBFS</code> bugs again, so that maintainers notice their packages fail to
build without having to wait for a non-happening testing migration.</p>
<p>After <strong>10</strong> days, the following mutt filter in <code>=debian-bts/</code> lists
<strong>69</strong> bugs:</p>
<pre><code>~s "Bug#.*FTBFS" ~P ~d 01/04/2011-
</code></pre>
<p>(<code>Subject</code> contains <code>Bug#.*FTBFS</code>, mails from me, starting from 01/04/2011.)</p>
<p>Figuring out whether that’s due to another package’s bug, an outdated
chroot, a temporary glitch, etc. might take some time; that’s why it’s
a bit hard to stay on top of things; and when the backlog grows up,
motivation to go through this tedious task can be pretty low,
especially when one sees repeated mistakes. I hope the amount of
(possible) use cases for <a href="http://bugs.debian.org/620686">#620686</a> will
decrease over time; instead, I’d be very happy if maintainers could at
least check what’s mentioned in <code>configure.ac</code>/<code>configure.in</code>. Keeping
an eye on its diff between upstream versions should be easy
enough. <code>;)</code></p>
Buildd funhttp://mraw.org/blog/2010/10/02/Buildd_fun/2013-12-17T02:11:29Z2010-10-02T15:20:00Z
<p>Being a buildd admin means one gets to sign successful build logs so
that the built packages get uploaded from buildds to the archive, but
that also includes filing bugs for packages which fail to build from
source (<code>Build-Attempted</code>). Once that done, they can be marked as
<code>Failed</code>, usually with a reason. A few words plus a bug number is
usually convenient, so that people (maintainers, possible NMUers,
other buildd admins) browsing <a href="https://buildd.debian.org/status/">https://buildd.debian.org/status/</a> can
just click the bug number to reach the BTS.</p>
<p>There were a few packages in <code>Build-Attempted</code> for <code>alpha</code>, for which
I reported some bugs yesterday, which explains the crossing lines on
the following graph:</p>
<p><a href="http://mraw.org/blog/2010/10/02/alpha.png"><img src="http://mraw.org/blog/2010/10/02/alpha.png" width="625" height="536" alt="Buildd stats for alpha" class="img" /></a></p>
<p><em>(That’s an edited version of the
<a href="https://buildd.debian.org/stats/alpha.png">buildd stats for alpha</a>.)</em></p>
<p>One has to be careful while filing bugs, since the severity depends on
the target architecture(s) for which the package is failing, but also
on its already being built there. Mostly, that boils down to <code>serious</code>
for regressions (no longer builds) on release architectures,
<code>important</code> otherwise. The only exception I’m applying is packages
failing on all architectures due to obviously missing build
dependencies, since they can’t be built again, even on the single
architecture they’re available for (and we want to guarantee that
doesn’t happen, we want to be able to <code>binNMU</code> them).</p>
<p>There are currently no packages in <code>Build-Attempted</code> for <code>alpha</code>,
<code>kfreebsd-amd64</code>, <code>kfreebsd-i386</code>, and <code>sparc</code> (architectures I take
care of), but I’m going to have a look at other architectures as well,
since having portable software and reported (<code>FTBFS</code>) bugs sounds like
a worthwhile goal.</p>
Saving Private G-I…http://mraw.org/blog/2010/01/31/Saving_private_GI/2013-12-17T02:11:28Z2010-01-31T01:00:00Z
<p><em>(Disclaimer: this post is not about
<a href="http://en.wikipedia.org/wiki/GI_(term)">G.I.</a>)</em></p>
<h2>Graphical installer</h2>
<p>Josselin
<a href="http://np237.livejournal.com/27459.html">posted his thoughts about g-i</a>,
and given at least the first parts sound doable, I’m tempted to have a
look at dealing with the needed udebs. Never touched anything like
this before, but oh well, one learns every day. Time to learn a bit
more about X11 as well.</p>
<p>It looks like generating a new <code>mini.iso</code> (using <code>d-i</code>’s trunk) wasn’t
that difficult, so hopefully once I’m done with a few udebs, it should
be possible to add them to this image and make sure those are usable,
at least when loaded manually.</p>
<p>Once that finished, gluing everything together is probably going to be
another story, but hopefully that won’t be impossible.</p>
<h2>Unrelated stories</h2>
<ul>
<li><p>Thanks to DSA (especially weasel), <code>kfreebsd-*</code> now have DSA-admin’d
<code>experimental</code> buildds. Aurélien took care of setting them up; they
managed to go through all <code>experimental</code> packages, and bugs were
filed accordingly. Some were just marked as <code>failed</code>, usually with
<em>“Needs porting.”</em>, especially when there were no regressions with
respect to what was previously built on those architectures (as a
reminder: <code>out-of-date</code> means <code>serious</code>, <code>uncompiled</code> means
<code>important</code>).</p></li>
<li><p>On a related note, this
<a href="https://buildd.debian.org/status/">buildd.d.o form</a> makes it
possible to browse the build logs for various suites. See the
<a href="http://lists.debian.org/debian-devel-announce/2010/01/msg00005.html">dda@ announce</a>
for details.</p></li>
<li><p>It looks like I’m going to stop dealing with Java at all:
<a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557230#12">#557230</a>. Thanks
to Gabriele Giacone for taking care!</p></li>
<li><p>It also looks like I’m
<a href="http://lists.debian.org/debian-python/2010/01/msg00146.html">done with Python packages</a>
as well.</p></li>
<li><p>A new
<a href="http://packages.debian.org/module-assistant">module-assistant</a>
package got uploaded, which should fix issues with newer kernel
versions (ya can haz
<a href="http://packages.qa.debian.org/m/module-assistant/news/20100127T101039Z.html">detailz</a>). I’m
wondering whether backporting it through
<a href="http://backports.org/">backports.org</a> from time to time would be of
some help to anyone? It is (or should be) directly installable in a
<code>lenny</code> environment, but maybe people would like it to be directly
available once the <code>lenny-backports</code> repository enabled?
Mail/wishlist bug welcome if you want it.</p></li>
<li><p>If you received some signatures from me lately… no, I wasn’t
pretending I met you at LCA or whatever, but that was from Cáceres
<em>(Hi Penny! <code>;)</code>)</em>. Key rollover being thought of.</p></li>
</ul>
Random KiBibitshttp://mraw.org/blog/2009/08/02/Random_KiBibits/2013-12-17T02:11:28Z2009-08-01T22:00:00Z
<h2>Extremadura</h2>
<ul>
<li><p>DebConf’9 timing was really nice, allowing for following talks,
getting things done, and meeting people.</p></li>
<li><p>Upper talk room’s speaker’s chairs aren’t as comfortable as they
seem; First row seats are OK to sleep on, though.</p></li>
<li><p>Guards actually don’t want people to sleep there, and can even chase
people in hacklabs to make sure they go sleep in the right venue;
Funny wake-up, with a lot of Spanish, and little to be understood
(note to self: try and get some Spanish basics before being in the
plane for Spain next time).</p></li>
<li><p>Very sympathetic guard anyway, apparently (read: still in Spanish)
saying how sorry she felt for that. And even hugging and kissing
when one was leaving. Spanish people, you rock.</p></li>
<li><p>Day trip totally rocked, as well as the formal dinner. Orga-team
<code>\o/</code>.</p></li>
<li><p>Totally in love with the Bosnian bid for DebConf’11. Let’s hope
they’ll keep on doing a great job.</p></li>
<li><p>Oh, and decided to get another NM. Very funny to sit next to each
other and mail NM Q&A every few hours.</p></li>
</ul>
<h2>Packages</h2>
<ul>
<li><p>I requested assistance for the <a href="http://packages.debian.org/src%3Agraphviz">src:graphviz</a>
package. While being a quite interesting technical challenge back
when I started packaging various things, it is currently quite
sucking my time, and I would really love someone else step in. I
guess the <a href="http://bugs.debian.org/536245"><code>RFH</code> (#536245)</a> will be
turned into an <code>RFA</code> quite soon.</p></li>
<li><p>Pabs orphaned <a href="http://synfig.org">Synfig</a>-related packages <a href="http://packages.debian.org/src%3Aetl">src:etl</a>, <a href="http://packages.debian.org/src%3Asynfig">src:synfig</a>, <a href="http://packages.debian.org/src%3Asynfigstudio">src:synfigstudio</a>. Given
I don’t currently plan to dive more into them, I don’t feel like I
would do a great job by keeping on maintaining them alone.</p></li>
<li><p>The same goes for <a href="http://packages.debian.org/src%3Aluxrender">src:luxrender</a>. It’s RC-buggy but given
I may orphan it as well, I’m not really keen on uploading a new
upstream release to fix it. On a related note, I might have spent
some time on the <a href="http://packages.debian.org/src%3Aaqsis">src:aqsis</a> package but again, if one is
not a very regular user, what’s the point?</p></li>
<li><p>I’m also quite wondering what to do with
<a href="http://www.blender.org">Blender</a>. Details can be found in
<a href="http://lists.debian.org/debian-devel/2009/08/msg00028.html">my mail to <code>debian-devel@</code></a>.</p></li>
</ul>
<p>It’s quite sad to let some packages go, especially some which are
quite popular, and which have made me dream for years (graphics stuff
interested me back when I first touched a computer already); But well,
time is a scarce resource. <code>:(</code></p>
<h2>GNU/kFreeBSD</h2>
<ul>
<li><p>Taking care of buildds is a really interesting experiment.</p></li>
<li><p>The new wanna-build feature called
<a href="http://upsilon.cc/~zack/blog/posts/2009/07/wanna-build_gains_detection_of_uninstallable_build-deps/">edos-builddebcheck</a>
is really appreciated on <code>kfreebsd-*</code>; most of the time, I’ve been
setting <code>dep-waits</code> because of missing and/or uninstallable
packages. Now it seems that all that stuff is being handled
automatically, and I only have to concentrate on the successful
build logs, and on the failed ones due to needed porting, broken
build systems, etc. <strong>EPIC WIN</strong>, if you ask me.</p></li>
<li><p><code>d-i</code> port seems to be on good tracks, and having weekly reports is
great.</p></li>
<li><p>We’re still waiting for <code>util-linux</code> in <code>unstable</code> but once that
done, we should get <code>hal</code> (thanks to a close cooperation with both
its Debian maintainer and upstream), which should make it possible
to get a lot of packages from the X11, GNOME, and KDE stacks. Once
that done, a status update might be sent to <code>d-d-a@</code>.</p></li>
</ul>
Best questions everhttp://mraw.org/blog/2009/07/01/Best_questions_ever/2013-12-17T02:11:28Z2009-07-01T15:47:00Z
<p>Would someone guess the link between:</p>
<ul>
<li><p>What mail client are you using?</p></li>
<li><p>Are you around during the next two weeks?</p></li>
</ul>
<p><a href="http://mraw.org/blog/2009/07/01/gnukfreebsd.png"><img src="http://mraw.org/blog/2009/07/01/gnukfreebsd.png" width="100" height="106" alt="GNU/kFreeBSD logo" class="img" /></a></p>
<p>After answering those, I’ve been offered to take care of the
GNU/kFreeBSD buildds, which is yet another experience. <code>\o/</code></p>
<p>Quite a good timing since I’ve recently tried to get involved with the
GNU/kFreeBSD ports again, prodding maintainers, uploading fixed
packages (usually thanks to Petr Salinger’s patches), or providing
patches myself.</p>