tag:blogger.com,1999:blog-206635242024-03-07T11:58:27.290+02:00Funkyware: ITCeteraFree Software entrepreneurship: Debian, Ubuntu and beyond.Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.comBlogger84125tag:blogger.com,1999:blog-20663524.post-22234065117206031502023-11-16T10:31:00.003+02:002023-11-16T11:38:58.897+02:00dhcpcd almost ready to replace ISC dhclient in Debian<p>A lot of time has passed since my previous post on my work to make <b>dhcpcd</b> the drop-in replacement for the deprecated ISC dhclient a.k.a. <b>isc-dhcp-client</b>. Current status:</p>
<ul>
<li>Upstream now regularly produces releases and with a smaller delta than before. This makes it easier to track possible breakage.</li>
<li>Debian packaging has essentially remained unchanged. A few Recommends were shuffled, but that's about it.</li>
<li>The only remaining bug is fixing the build for <b>Hurd</b>. Patches are welcome. Once that is fixed, bumping <b>dhcpcd-base</b>'s priority to important is all that's left.</li>
</ul>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com2tag:blogger.com,1999:blog-20663524.post-55834263563976931382022-07-17T22:10:00.000+03:002022-07-17T22:10:14.091+03:00Trying to chainload iPXE on old Etherboot hardware<p>Among my collection of PC hardware, I have a few rarities whose netboot implementation predates PXE. Since I recently managed to configure <b>dnsmasq</b> as a potent TFTP and PXE server, I figured that I'd try chainloading <b>iPXE</b> via BOOTP options. This required preparing a boot image using antiquated tools:</p>
<code>$ sudo mkelf-linux --param=autoboot --output=/srv/tftp/ipxe.nbi /srv/tftp/ipxe.lkrn</code>
<p>The host succesufully loads the boot image, except that the iPXE blob fails to find the network card:</p>
<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhAmZ-7zHHydvSJ_lOz9CaKNz0zonuRNVIFL-TZzq-jcHHuheMDxP9lCp55UPDaywehR-OsWN6wWuiHqtbXKOT1VI5VQO72Y3s06Gh-gR_g9ldvHhjHubFY4-8y_0UaVavASympve6aA9fOKoWEDHUIQJphdXwKkLqzV-KkTjSiNWHmVHcaPQ/s4160/IMG_20220717_210749.jpg" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" width="500" data-original-height="3120" data-original-width="4160" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhAmZ-7zHHydvSJ_lOz9CaKNz0zonuRNVIFL-TZzq-jcHHuheMDxP9lCp55UPDaywehR-OsWN6wWuiHqtbXKOT1VI5VQO72Y3s06Gh-gR_g9ldvHhjHubFY4-8y_0UaVavASympve6aA9fOKoWEDHUIQJphdXwKkLqzV-KkTjSiNWHmVHcaPQ/s400/IMG_20220717_210749.jpg"/></a></div>
<p>Any ideas?</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0tag:blogger.com,1999:blog-20663524.post-70332742266232692072022-07-03T11:52:00.001+03:002022-07-03T11:57:48.633+03:00Refactoring Debian's dhcpcd packaging<p>Given news that ISC's DHCP suite is getting deprecated by upstream and seeing how <b>dhclient</b> has never worked properly for DHCPv6, I decided to look into alternatives. ISC itself recommends Roy Maple's <b>dhcpcd</b> as a migration path. Sadly, Debian's package had been left unattended for a good 2 years. After refactoring the packaging, updating to the latest upstream and performing one NMU, I decided to adopt the package.</p>
<p>Numerous issues were exposed in the process:</p>
<ul>
<li>Upstream's <b>./configure</b> makes BSD assumptions. No harm done, but still...</li>
<li>Upstream's <b>./configure</b> is broken. <code>--prefix</code> does not propagate to all components. For instance, I had to manually specify the full path for manual pages. Patches are welcome.</li>
<li>Debian had implemented custom exit hooks for all its <b>NTP</b> packages. Since then, upstream has implemented this in a much more concise way. All that's missing upstream is support for <b>timesyncd</b>. Patches are welcome.</li>
<li>I'm still undecided on whether <code>--prefix</code> should assume <code>/</code> or <code>/usr</code> for networking binaries on a Debian system. Feedback is welcome.</li>
<li>The previous maintainer had implemented plenty of transitional measures in <b>maintainer scripts</b> such as symbolically linking <code>/sbin/dhcpcd</code> and <code>/usr/sbin/dhcpcd</code>. Most of this can probably be removed, but I haven't gotten around verifying this. Feedback and patches are welcome.</li>
<li>The previous maintainer had created an <b>init.d</b> script and <b>systemd</b> unit. Both of these interfere with launching <b>dhcpcd</b> using <b>ifupdown</b> via <code>/etc/network/interfaces</code> which I really need for configuring a router for IPv4 MASQ and IPv6 bridge. I solved this by putting them in a separate package and shipping the rest via a new binary target called <b>dhcpcd-base</b> along a logic similar to <b>dnsmasq</b>.
<li>DHCPv6 Prefix Delegation mysteriously reports <code>enp4s0: no global addresses for default route</code> after a reboot. Yet if I manually restart the interface, none of this appears. Help debuging this is welcome.</li>
<li>Support for Predictable Interface Names was missing because Debian's package didn't Build-Depends on <code>libudev-dev</code>. Fixed.</li>
<li>Support for priviledge separation was missing because Debian's package did not <b>./configure</b> this or create a system user for this. Fixed.</li>
<li>I am pondering moving the Debian package out of the <b>dhcpcd5</b> namespace back into the <b>dhcpcd</b> namespace. The 5 was the result of an upstream fork that happened a long time ago and the original dhcpcd package no longer is in the Debian archive. Feedback is welcome on whether this would be desirable.</li>
</ul>
<p>The key advantage of <b>dhcpcd</b> over <b>dhclient</b> is that works as a dual-stack DHCP client by design. With privilege separation enabled, this means separate child processes handling IPv4 and IPv6 configuration and passing the received information to the parent process to configure networking and update <code>/etc/resolv.conf</code> with nameservers for both stacks. Additionally, <code>/etc/network/interfaces</code> no longer needs separate <b>inet</b> and <b>inet6</b> lines for each DHCP interface, which makes for much cleaner configuration files.</p>
<p>A secondary advantage is that the dual-stack includes built-in fallback to <b>Bonjour</b> for IPv4 and <b>SLAAC</b> for IPv6. Basically, unless the interface needs a static IP address, this client handles network configuration in a smart and transparent way.</p>
<p>A third advantage is built-in support for DHCPv6 Prefix Delegation. Enabling this requires just two lines in the configuration file.</p>
<p>In the long run, I feel that <b>dhcpcd-base</b> should probably replace <b>isc-dhcp-client</b> as the default DHCP client with priority Important. Adequate IPv6 support should come out of the box on a standard Debian installation, yet <b>dhclient</b> never got around implementing that properly.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com2tag:blogger.com,1999:blog-20663524.post-78495287790955188202021-09-07T14:08:00.001+03:002021-09-07T14:21:21.327+03:00sudo apt-get update && sudo apt-get dist-upgrade<p>Debian 11 (codename <b>Bullseye</b>) was recently released. This was the smoothest upgrade I've experienced in some 20 years as a Debian user. In my haste, I completely forgot to first upgrade <b>dpkg</b> and <b>apt</b>, doing a straight <b>dist-upgrade</b>. Nonetheless, everything worked out of the box. No unresolved dependency cycles. Via my last-mile Gigabit connection, it took about 5 minutes to upgrade and reboot. Congratulations to everyone who made this possible!</p>
<p>Since the upgrade, only a handful of bugs were found. I filed bug reports. Over these past few days, maintainers have started responding. In once particular case, my report exposed a CVE caused by copy-pasted code between two similar packages. The source package fixed their code to something more secure a few years ago, while the destination package missed it. The situation has been brought to Debian's security team's attention and should be fixed over the next few days.</p>
<h4>Afterthoughts</h4>
<p>Having recently experienced hard-disk problems on my main desktop, upgrading to Bullseye made me revisit a few issues. One of these was the possibility of transiting to BTRFS. Last time I investigated the possibility was back when <b>Ubuntu</b> briefly switched their default filesystem to BRTFS. Back then, my feeling was that BRTFS wasn't ready for mainstream. For instance, the utility to convert an EXT2/3/4 partition to BTRFS corrupted the end of the partition. No thanks. However, in recent years, many large-scale online services have migrated to BRTFS and seem to be extremely happy with the result. Additionally, <b>Linux</b> kernel 5 added useful features such as background defragmentation. This got me pondering whether now would be a good time to migrate to BRTFS. Sadly it seems that the stock kernel shipping with Bullseye doesn't have any of these advanced features enabled in its configuration. Oh well.</p>
<h4>Geode</h4>
<p>The only point that has become problematic is my Geode hosts. For one things, upstream <b>Rust</b> maintainers have decided to ignore the fact that i686 is a specification and arbitrarily added compiler flags for more recent x86-32 CPUs to their i686 target. While Debian Rust maintainers have purposely downgraded the target, <b>RustC</b> still produces binaries that the Geode LX (essentially an i686 without PAE) cannot process. This affects fairly basic packages such as <b>librsvg</b>, which breaks SVG image support for a number of dependencies. Additionally, there's been persistent problems with <b>systemd</b> crashing on my Geode hosts whenever <b>daemon-reload</b> is issued. Then, a few days ago, problems started occurring with C++ binaries, because GCC-11 upstream enabled flags for more recent CPUs in their default i686 target. While I realize that SSE and similar recent CPU features produce better binaries, I cannot help but feel that treating CPU targets as anything else than a specification is a mistake. i686 is a specification. It is not a generic equivalent to x86-32.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com1tag:blogger.com,1999:blog-20663524.post-37899260836573488902021-05-19T15:04:00.002+03:002021-05-19T15:51:13.503+03:00WebRTC fails tests on Firefox 78.10.0esr (64-bit)<p>Having to participate in many online events since the COVID crisis started, I've come to notice that few of the online clients work properly on the current <b>Firefox ESR</b> found in <b>Debian</b>. A quick visit at <a href="https://test.webrtc.org/">WebRTC Test</a> confirmed that none of the tests in the <b>Network</b> and <b>Connectivity</b> section pass. Meanwhile, a Windows 10 laptop running Edge via the same network works just fine, so I have to assume that either a Firefox or Debian packaging issue is to blame, but I wouldn't know where to start. Any help? Thanks!<p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com2tag:blogger.com,1999:blog-20663524.post-38943483029925236802021-02-28T09:40:00.002+02:002021-02-28T16:46:07.033+02:00Shipping Debian with GNOME X.XX.0 is an extremely bad idea<p>Since the freeze has slowly crept in, now is the time to revisit my pet peeve with <b>Debian</b>'s release process: to publish a new Debian release as soon as <b>GNOME</b> published a new X.XX.0 version. This is an extremely bad idea: X.XX.0 releases tend to lack polish, their translations are not up-to-date and several silly bugs that hamper the user experience (what the <b>Ubuntu</b> guys call "paper cuts") exist. Those issues tend to be fixed later when GNOME X.XX.1, X.XX.2, etc. bugfix releases are published. However, Debian has a policy of <i>not</i> pushing non-security releases onto a stable distribution. In this particular case, there are only two valid alternatives: either release Bullseye with GNOME 3.38.X or change the Debian policy to allow pushing 3.40.X bugfix releases via <b>bullseye-updates</b>.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com2tag:blogger.com,1999:blog-20663524.post-21384535763746454992021-02-15T20:10:00.004+02:002021-02-17T20:09:51.222+02:00OpenWRT: WRT54GL: Backfire: IPv6 issues<p>While having a <b>Debian</b> boxen as a router feels nice, I kept on longing for something smaller and quieter. I then remembered that I still had my old <b>WRT54GL</b> somewhere. After upgrading the <b>OpenWRT</b> firmware to the latest supported version for that hardware (Backfire 10.03.1, r29592), I installed <b>radvd</b> and <b>wide-dhcpv6-client</b>. Configuring radvd to deliver consistent results was easy enough.</p><p>The issue I keep on experiencing is the external interface (wan) dropping the IPv6 address it received from the ISP via router advertisement, which in turn kills the default IPv6 route to the outside world. Logging in via SSH and manually running "rdisc6 eth0.1" restores the IPv6 gateway. I just honestly wished I didn't have to do this every time I need to reboot the router.</p><p>Does this issue sound familiar to anyone? What was the solution?</p><p>PS: No, I won't just go and ditch this WRT54GL just because new toys exist on the market. This is obviously a software issue, so I need a software solution.</p><p>PPS: IPv6 pretty much works out of the box on the Debian boxen I had been using as my router. I previously <a href="https://q-funk.blogspot.com/2020/11/adding-ipv6-support-to-my-home-lan.html">wrote</a> about this on my blog. Basically, it's unlikely to be an ISP issue.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com1tag:blogger.com,1999:blog-20663524.post-33037240736108012092021-01-02T12:41:00.005+02:002021-01-25T16:33:15.693+02:00Help needed: clean up and submit KMS driver for Geode LX to LKML<p>Ever since X.org switched to rootless operation, the days of the Geode X.org driver have been numbered. The old codebase dates back from Geode's early days at Cyrix, was then updated by NSC to add support for their new GX2 architecture, from which AMD dropped GX1 support and added support for their new LX architecture. To put it mildly, that codebase is a serious mess.</p> <p>However, at least the LX code comes with plenty of niceties, such as being able to detect when it runs on an OLPC XO-1 and to probe DCC pins to determine the optimal display resolution on other hardware. This still doesn't make the codebase cruft-free.</p>
<p>Anyhow, most Linux distributions have dropped support for anything older than i686 with PAE, which essentially means that the GX2 code is just for show. Debian is one of very few distributions whose x86-32 port still ships with i686 without PAE. In fact, the lowest common denominator kernel on i386 is configured for Geode (LX).</p>
<p>A while back, someone had started working on a KMS driver for the Geode LX. Through word of mouth, I got my hands on a copy of their Git tree. The driver worked reasonably well, but the codebase needs some polishing before it could be included in the Linux kernel tree.</p>
<p>Hence this call for help:</p>
<p>Is there anyone with good experience of the LKML coding standards who would be willing to clean up the driver's code and submit the patch to the LKML?</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com3tag:blogger.com,1999:blog-20663524.post-53937396444884618402020-11-03T16:16:00.001+02:002020-11-03T17:48:51.999+02:00GRUB fine-tuning<p>A couple of years ago, I moved into a new flat that comes with RJ45 sockets wired for 10 Gigabit (but currently offering 1 Gigabit) Ethernet.</p><p>This also meant changing the settings on my router box for my new ISP.</p><p>I took this opportunity to review my router's other settings too. I'll be blogging about these over the next few posts.</p>
<h4>GRUB fine-tuning</h4>
<p>One thing that had been annoying me ever since Debian migrated to <b>systemd</b> as /sbin/init is that boot message verbosity hasn't been the same. Previously, the <b>cmdline</b> option <code>quiet</code> merely suppressed the kernel's output to the bootscreen, but left the daemon startup messages alone. Not anymore. Nowadays, <code>quiet</code> produces a blank screen.</p>
<p>After some googling, I found the solution to that:</p>
<code>GRUB_CMDLINE_LINUX_DEFAULT="noquiet loglevel=5"</code>
<p>The former restores daemon startup messages, while the later makes the kernel output only significant notices or more serious messages. On most of my hosts, it mostly reports inconsistencies in the ACPI configuration of the BIOS.</p>
<p>Another setting I find useful is a reboot delay in case a kernel panic happens:</p>
<code>GRUB_CMDLINE_LINUX="panic=15"</code>
<p>This gives me enough time to snap a picture of the screen output to attach to the bug report that will follow.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0tag:blogger.com,1999:blog-20663524.post-73511714612455942582016-08-07T20:18:00.002+03:002016-08-07T20:18:49.380+03:00Debian within a Windows partition?A few years ago, I remember that Ubuntu had a trick that allowed the distribution to be installed as one large file within a Windows partition. Does the same thing exist to install Debian?Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com3tag:blogger.com,1999:blog-20663524.post-78083859043164031482016-02-04T16:27:00.001+02:002016-02-04T16:27:59.141+02:00xf86-video-geode 2.11.18<p>Yesterday, I pushed out version 2.11.18 of the <b>Geode X.Org</b> driver. This is the driver used by the <b>OLPC XO-1</b> and by a plethora of low-power desktops, micro notebooks and thin clients. This release mostly includes maintenance fixes of all sorts. Of noticeable interest is a fix for the long-standing issue that switching between X and a VT would result in a blank screen (this should probably be cherry-picked for distributions running earlier releases of this driver). Many thanks to <strong>Connor Behan</strong> for the fix!</p><br />
<p>Unfortunately, this driver still doesn't work with GNOME. On my testing host, launching GDM produces a blank screen. 'ps' and other tools show that GDM is running but there's no screen content; the screen remains pitch black. This issue doesn't happen with other display managers e.g. LightDM. Bug reports have been filed, additional information was provided, but the issue still hasn't been resolved.</p><br />
<p>Additionally, X server flat out crashes on Geode hosts running Linux kernels 4.2 or newer. 'xkbcomp' repeatedly fails to launch and X exits with a fatal error. Bug reports have been filed, but not reacted to. However, interestingly enough, X launches fine if my testing host is booted with earliers kernels, which <em>might</em> suggest what the actual cause of this particular bug might be:</p><br />
<p>Since kernel 4.2 entered Debian, the base level i386 kernel on Debian is now compiled for i686 (without PAE). Until now, the base level was i586. This essentially makes it pointless to build the Geode driver with GX2 support. It also means that older GX1 hardware won't be able to run Debian either, starting with the next stable release.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0tag:blogger.com,1999:blog-20663524.post-5887735250134850202015-10-28T09:34:00.002+02:002015-10-28T09:36:49.394+02:00xf86-video-geode: Last call, dernier sévice<p>I guess that the time has finally come to admit that, as far as upstream development is concerned, the <a href="http://www.x.org/wiki/GeodeDriver">Geode X.Org driver</a> is reaching retirement age:</p><br />
<p>While there have indeed been recent contributions by a number of developers to keep it compilable against recent X releases, the Geode driver has accumulated too much cruft from the Cyrix and NSC days, and it hasn't seen any active contribution from AMD in a long time. Besides, nowadays, Xserver pretty much assumes that its runs on an X driver that leverages its matching kernel driver and thus won't require root priviledges to launch. This isn't the case with the Geode driver, since it directly probes FBDEV and MSR, both of which reside in /dev and require root priviledges to access.</p><br />
<p>On Debian, as a stopgap measure, the package now Recommends a legacy wrapper that enforces operation as root. Meanwhile, other distributions are mercilessly droping all X drivers that don't leverage KMS. Basically, unless a miracle happens really quick, Geode will soon become unusable on X.</p><br />
<p>Back when AMD was still involved, a concensus had been reached that, since the Geode series doesn't offer any sort of advanced graphic capabilities, the most sensible option would indeed be to make a KMS driver and let Xserver use its generic modeline driver on top of that, then drop the Geode X driver entirely. Amazingly enough, someone did start working on a <a href="https://gitorious.org/lx">KMS driver for Geode LX</a>, but it never made it as far as the Linux kernel tree (additionally, Gitorious seems to be down, but I have a copy of the driver's Git tree on hand, if anyone is interested). While I'll still be accepting and merging patches to the Geode X driver, our best long-term option would be to finalize the KMS driver and have it merged into Linux ASAP.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0tag:blogger.com,1999:blog-20663524.post-10468372326222499482015-03-23T16:19:00.000+02:002015-03-23T21:27:57.884+02:00This and That<p>I haven't blogged anything in months and figured that now might be a good time to get around that. Here it goes:</p><br />
<h4>Free Software</h4><br />
<p>While I occasionally upgrade the packaging of the software I maintain at Debian to keep up with best practices, my activity downsizing goes on. Simply put: I never had any ambition to become a Debian Developer. My involvement has always remained pragmatic and mostly from the perspective of packaging software that I found useful. Even then, my motivation for doing that keeps on dwindling into nothingness, because key pieces of software keep on breaking, whenever someone upstream decides to reinvent the wheel.</p><br />
<p>For instance, GNOME no longer works at all on Geode chipsets and it barely works on Nouveau chipsets. This happened as soon as GNOME 3.14 was uploaded into unstable, right before the freeze started. Then again, I wouldn't jump to a conclusion that GNOME itself might be at fault, since Plymouth also stopped working on the same two video platforms at the same time. For all we know, this could be caused by some changes in the X.Org server code. Bugs were filed, additional information was provided, but no fix has taken place.</p><br />
<p>Given how Geode and Nouveau represent 80% of my hardware investment (my Intel laptop being the sole exception), it essentially means that the upcoming Debian "stable" is useless for me. Now try and remain motivated, even just as a mere Free Software end-user. At this point, I'm done.</p><br />
<h4>Politics</h4><br />
<p>Finland is holding national elections this April. I still have no idea who I'll vote for this time. The guy I voted for last time has become a career politician with an inflated ego and zero connection to the average Finn's aspirations and worries. Meanwhile, two friends are standing as candidates: one who is a razor-sharp fact finder and who is a proven pragmatic decision-maker, but whose values are slightly off with mine, and one whose actions come straight from the heart but whose concept of today's Finnish reality leaves a lot to be desired.</p><br />
<h4>National Defence</h4><br />
<p>There's been a lot of recent articles about how former hardware and locations of the Finnish defence forces and border guards have been sold, often for peanuts, to Russian interests. In some cases, we're only talking about buildings formerly used for on-site staff accommodations. In other cases, former patrol boats and navy harbours changed hands. Now, to top it all, it appears that our north-western neighbour, Norway, has sold a former submarine base to German investors who, in turn, leased it to – you guessed it – Russian interests.</p><br />
<p>Looking at Russian actions in Ukraine, I cannot help but feel great concern that strategic locations are falling into potentially dangerous hands. Just seeing the picture of a former navy harbour with a handful of patrol boats on standby, right on the Finnish coastline, half-way between Helsinki and Turku, was a sobering experience. While the whole idea of shooting at people – even invading armies – gives me the creeps, at this point, I cannot help but start pondering whether defending this country might in fact be an occupation worth training for.</p><br />
<h4>Employment</h4><br />
<p>It has now been 6 years since I held my last dayjob. Since then, the only thing I've found is an unpaid training in the national bureaucracy. I've also freelanced as an actor and model, but that barely brought me pocket change, if even that. Seeing my face on posters advertising a movie I participated in last year was indeed nice, getting some media attention in connection to that too, but it hasn't lead to additional gigs. As far as I can tell, this was just my Warholian 15 minutes of fame.</p><br />
<p>However, there's a larger issue at stake. Newspapers recently published an employment statistics map for Nordic countries and the truth couldn't be more bleak: while Norway and Sweden's employment figures are nearly spotless for almost every province, those of Finland are – save for a couple of mildly successful provinces – outright catastrophic. Given this and despite feeling relatively happy living in Finland and having developed a will to defend this country from an eventual Russian assault, I've come to the conclusion that I would be better off going West, with a strong preference for Norway.</p><br />
<p>Now, the main question is, doing what? 6 years later, I have strong doubts that I would be remotely considered for any high-tech job. Besides, come to think of it, I wouldn't want any new office job. Off the top of my head, my idea of a cool job that would allow me to stay physically fit would be working as a tourist guide in Lapland. However, if Norway is anything like Finland, someone probably needs a dozen of permits of all sorts (first aid certification, C or even D class driving license, college degree in tourism, etc.) that I cannot afford. What then?</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0tag:blogger.com,1999:blog-20663524.post-66353180809299404902014-12-02T02:09:00.001+02:002014-12-02T02:15:00.473+02:00GNOME is destroying the whole GTK universe<p>When GNOME 3.14 components were uploaded into Debian (just a few days before the Jessie freeze started), GNOME stopped working on two video platforms: Geode (xf86-video-geode) and NVIDIA (xf86-video-nouveau). On Geode, GDM launches into a black screen. On NVIDIA, GDM launches as expected, but then the GNOME session itself barfs with the dreaded "Oh No! Something went wrong. [Logout]" dialog during session initialization. Basically, components in GNOME have become too tightly dependent upon some video driver features. Thinking out loud, I figured that reverting to a desktop environment that is based upon GTK+3, without GNOME's bells and whistles, would at least restore operation on my NVDIA hosts. Alas, it does not: Cinnamon, too, barfs during session initialization. Great. Now what?</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com15tag:blogger.com,1999:blog-20663524.post-11199457864148900482014-11-09T01:07:00.000+02:002014-11-09T01:07:21.043+02:00On the Joey debacle<p>Looking back, I cannot think of a single moment when Joey wouldn't have shown the utmost patience and courtesy towards anyone involved in Debian, even towards mere users filing sometimes senseless bug reports against his packages. From this perspective, I cannot help but venture that whatever chain of events lead to Joey's decisions essentially means one thing: Debian must have seriously gotten off-course for someone who has been involved for so long to call it quits. As for the current situation at hands, while I admittedly haven't followed too closely who or what caused Joey's decision, I nonetheless cannot help but feel that whoever pushed Joey's buttons so hard as to make him decide to leave Debian ought to be the one(s) kicked out of Debian instead.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0tag:blogger.com,1999:blog-20663524.post-57881668423554343122014-11-07T18:52:00.000+02:002014-11-07T19:48:00.180+02:00HEL has just frozen over. Wait. No. Debian did.Noticing that Debian just entered its freeze, I went ahead and changed the APT sources on a spare host that is currently running stable. Then, it was time for this command to be executed:<br />
<br />
<pre>sudo apt-get update && \
sudo apt-get install apt dpkg locales && \
sudo apt-get --purge dist-upgrade && \
sudo apt-get --fix-policy install && \
sudo apt-get --purge autoremove $(deborphan --guess-all)
</pre><br />
I guess I'll be busy filing bug reports for the next few hours. Wish me (and each faulty package's maintainer) luck!<br />
<br />
PS: Apparently, so many aspects of Debian have become dependent upon GPG features that merely upgrading APT, DPKG and libc6+locales is no longer enough. One must also upgrade gnupg and gnupg2. Thus, the second element of the above recipe has become: <br />
<br />
<tt>sudo apt-get install apt dpkg gnupg gnupg2 locales && \</tt><br />
<br />
Hopefully, APT's <tt>dist-upgrade</tt> command already knows that these must be upgraded first...<br />
<br />
PPS: Hosts running Network-Manager cannot be upgraded remotely, because Network-Manager insists upon killing the network connection and the SSH daemon with it, when its turn comes to get upgraded.Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com4tag:blogger.com,1999:blog-20663524.post-29095319068065720112013-03-20T08:13:00.001+02:002013-03-20T08:13:26.402+02:00Outstanding issue in Debian: unroutable public v6 IP<p>Given how Debian and Ubuntu nowadays enable IPv6 support by default, the routing table includes some IPv6 entries by standard. However, this has the unpleasant side-effect that <strong>lib C</strong> tries to connect to public IPv6 addresses, even in a case when the only IPv6 entries are for <strong>loopback</strong> and <strong>local link</strong>. Apparently, libc incorrectly assumes that the mere presence of any IPv6 means that there is a usable default IPv6 route. This results in, among other things, <strong>APT</strong> failing at fetching packages from the Debian repository if the DNS rotation returned the IPv6 address for the server first. I was thus wondering whether libc6 could be made to reject public IPv6 addresses, in cases when the host has no IPv6 gateway in its routing table? Or would there be a smarter way to prevent applications from failing at contacting IPv6 addresses whenever there is no IPv6 connection to the outside world?</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com21tag:blogger.com,1999:blog-20663524.post-4688924232972245672012-12-07T16:37:00.002+02:002012-12-07T16:39:35.672+02:00xf86-video-geode 2.11.14<p>A few days ago, I pushed out version 2.11.14 of the <b>Geode X.org</b> driver. This is the driver used by the <b>OLPC XO-1</b> and by a plethora of low-power desktops, micro notebooks and thin clients.</p><br />
<p>This release mostly features long-overdue fixes to rendering issues under <b>GTK3+</b> and <b>xulrunner</b>, plus yet more ongoing changes to make this driver compile under recent X servers.</p><br />
<p>Sadly, the release took place much <a href="http://bugs.debian.org/692600">too late</a> to be included into the upcoming stable Debian version, Wheezy, which is already deeply into freeze, pending publication.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0tag:blogger.com,1999:blog-20663524.post-23619818556556448572012-09-15T18:49:00.001+03:002012-09-15T19:01:51.260+03:00HTML5: Firefox without FlashOver the past few days, I decided to purge <b>Gnash</b> and <b>LightSpark</b> from my laptop to see whether my Internet experience would be affected in any dramatic way. Amazingly, a number of sites seem to offer video content encoded in <b>Theora</b> (VP3) or <b>WebM</b> (VP8). Sadly, a handful of popular sites such as <b>Vimeo</b> insist upon using the <b>H.264</b> (MPEG-4) CODEC, which cannot be safely supported on Free Software because of unclear licensing issues that might impose an ulterior usage fee onto the end-users.<br />
<br />
The good news is that the Mozilla Foundation has decided to avoid the issue together: starting with the most recent release of the mobile version of <b>Firefox</b>, content decoding is offloaded to the platform's native media CODEC library. On most Free Software platforms, this means that <b>Gstreamer</b> will handle the content and, in turn, use <tt>gstreamer-plugins-bad</tt> to perform the decoding. However, Gstreamer support is still rather sketchy, as attested by <a href="http://bugs.debian.org/682917">this Debian bug report</a> and thus disabled by default. This leaves me wondering how little is missing for this to properly work. Would either <b>Canonical</b> or <b>Red Hat</b> perhaps be interested in funding this?Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com1tag:blogger.com,1999:blog-20663524.post-15710520838398824392012-07-28T16:39:00.000+03:002012-09-01T15:03:08.724+03:00PulseAudio: system mode broken<p>Ever since version 1.1 of PulseAudio was released, remote audio stopped working for me. Basically, the tunnel created by enabling "Detect native remote PulseAudio sinks" in <strong>paprefs</strong> on the client side immediately crashes the PulseAudio server on the remote host. I reported the issue at <a href="https://bugs.freedesktop.org/show_bug.cgi?id=49681">Free Desktop bug #49681</a>. The issue still exists in version 2.0, which is what Debian's next stable release is supposed to ship (and in 2.1, available via the experimental repository). This essentially means that I cannot upgrade my hosts to Wheezy without losing my remote speakers. Would anybody knowledgable enough with PulseAudio internals be able to help me track down the cause of this bug?</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0tag:blogger.com,1999:blog-20663524.post-61055567863791405172012-07-28T16:05:00.000+03:002012-07-28T16:24:53.367+03:00OpenWRT: SLAAC and DHCPv6 on White Russian<p>As I <a href="http://q-funk.blogspot.fi/2012/05/openwrt-accepting-router-adverts-from.html">recently reported</a>, I have been trying to configure my Linksys WRT54GL running the OpenWRT firmware (version 0.9 a.k.a. White Russian) to support SLAAC and DHCPv6 out of the box.</p><p>Most of the feedback I got involved upgrading the OpenWRT firmware to a more recent release that might not fit the available storage capacity of the device, which felt like too risky of an operation to attempt.</p><p>The solution I found instead involved adding <strong>ipkg</strong> sources to OpenWRT's backports repository, which offers a minimalistic DHCPv6 client. Although I haven't been able to find any proper documentation for this client, the content of its configuration file is mostly intelligible. What remains now is to actually configure it to cooperate with the kernel's native SLAAC implementation and, whenever an IPv6 network is found on the ISP side, to propagate the address space, DNS and routing information to my LAN using <strong>radvd</strong>.</p><p>Would anyone located within the Helsinki metropolitan area happen to have an IPv6 testing environment that would at least allow me to configure and test my router?</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0tag:blogger.com,1999:blog-20663524.post-9391264761549633462012-05-29T10:05:00.000+03:002012-05-29T10:05:56.184+03:00OpenWRT: accepting Router Adverts from the ISP in White Russian?<p>As we are getting closer to the <strong>World IPv6 Day</strong>, I thought that I'd see if I can upgrade my WRT54GL's OpenWRT (White Russian) installation to accept Router Adverts from the ISP to acquire an IPv6 address (rather than via a 4-to-6 tunnel broker, which seems to be the most documented case), and to propagate its IPv6 address space to my local network via my WRT45GL's <tt>radvd</tt>. Unfortunately, most of the instructions out there concern newer OpenWRT releases to which I cannot upgrade to because their software base takes up significantly more space than White Russian does. Still, I figure that someone in the community must have already succeeded at configuring their WRT54GL for this and might be able to help. Anyone? :)</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com5tag:blogger.com,1999:blog-20663524.post-1437119103797556042012-02-14T12:27:00.004+02:002012-02-14T13:29:08.545+02:00Adopted: ispell-et, myspell-lv, rus-ispell.<p>Over recent months, I have been pondering the relevance of my Free Software involvement a lot:</p>
<p>More than anything, it constantly feels more and more like several important distributions and projects are moving in directions that break with the old ways far too radically, by breaking software usability rules such as <cite>"least surprise"</cite>, <cite>"works out of the box"</cite>, and <cite>"if it ain't broken, don't fix it"</cite> either to try new approaches to addressing existing needs or simply for change's sake.</p>
<p>Another aspect lies in my usual motivation for packaging or adopting software: because I need it and nobody else bothered doing it. Further reflection made me ponder what, correspondingly, are my usual reasons for dropping software: because what exists already works and because everybody and their grand-mother already invented a million of ways to handle the same issue.</p>
<p>Which brings us to today's news.</p>
<p>What prompted me to hand the dictionary packages I maintained over to someone else was a combination of <cite>"no longer need it"</cite> and <cite>"it already works fine as it is."</cite></p>
<p>For instance, the <strong>Estonian</strong> dictionaries haven't seen any upstream release since the initial one in 2003. While I still use Estonian daily in my online communications, the last 9 years have mostly been spent making minor changes to the dependencies and maintainer scripts, just to keep the package compliant with current <strong>Debian</strong> packaging policies and with ongoing improvements to the <code>dictionary-common</code> maintainer tools. This is not the sort of work that requires any knowledge of the Estonian language, so I felt that having dictionary-common developers handle those technical transitions in a clean and across-the-board way for as many dictionary packages as possible would be more productive than me trying to keep track of those changes by myself.</p>
<p>A similar case applies to the <strong>Latvian</strong> dictionaries. While there have been occasional upstream releases, some of which required patching the source code, maintaining the package has mostly been about tracking Debian policy changes and dictionary-common functional changes. Additionally, my interest for learning Latvian has dramatically dropped over the years, so I no longer saw any point in remaining involved in maintaining the package.</p>
<p>Ditto for the <strong>Russian</strong> dictionaries: occasional upstream releases, occasional patches, regular packaging upgrades to keep up with the Debian policy and with dictionary-common functionality, but no longer much of anything than a passive interest in practicing my Russian.</p>
<p>One of the developers behind dictionary-common, <strong>Agustin Martin Domingo</strong>, frequently helped me make sense of the changes I needed to track in the past, so he gladly accepted taking over the technical maintenance of all 3 packages. The Estonian dictionaries, while extremely skim in the breadth of vocabulary they cover, remain useful, but are essentially deprecated, as the upstream author is working on a spell checking engine similar to what <strong>Voikko</strong> does for <strong>Finnish</strong>, which is why maintaining them will be a rather easy task for Agustin. Meanwhile, <strong>Aigars Mahinovs</strong> passively remains on board for the Latvian dictionaries, while the Russian dictionaries have been adopted by <strong>Mikhail Gusarov</strong>, in both cases with Agustin assisting on technical matters.</p>
<p>Basically, I feel that passing the maintenance over to people whose motivation remains high is a better way to guarantee those packages' future than leaving them in my unmotivated hands and I'm glad that I found someone to keep on packaging them.</p>
<p>PS: happy Valentine's day to everyone!</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0tag:blogger.com,1999:blog-20663524.post-85997209554204018562012-01-03T17:49:00.003+02:002012-01-03T18:06:12.627+02:00xf86-video-geode 2.11.13<p>A few days ago, I pushed out version 2.11.13 of the Geode X driver. This is the driver used by the <a href="http://www.laptop.org">OLPC XO-1</a>, by a plethora of thin clients such as the <a href="http://www.thincan.com">ThinCan</a>, by low-power desktops such as the <a href="http://www.linutop.com">Linutop</a> and by a few notebooks such as the <strong>eCafé EC800</strong>.</p>
<p>While this release indeed features a few bugfixes (mainly to keep this driver compilable on the latest X server), the lion's share of the changes involve a complete overhaul of the build scripts, courtesy of Gaetan Nadon. The key motivation for this overhaul was to acknowledge the efforts made by third-party contributors to make the driver compile on BSD variants. Sure enough, this release finally compiles on FreeBSD and, low and behold, on Hurd.</p>
<p>However, the hybrid nature of Debian's FreeBSD kernel-based GNU operating system variant posed an additional challenge, because it provides usable support for Video for Linux version 2 (V4L2), but without the full complement of Linux definitions. This resulted in one post-release commit (included in Debian and Ubuntu package 2.11.13-2), following which my assertion that we could now safely define this package as <code>Architecture: any-i386</code> finally proved to be a safe one for Debian-based operating systems.</p>
<p>At this point, I'm curious as to how many more operating systems, especialy BSD variants, can finally use this driver. Patches to further improve support of non-Linux systems are welcome.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com2tag:blogger.com,1999:blog-20663524.post-14041357220078019622011-09-24T18:50:00.002+03:002011-09-24T19:00:48.994+03:00Proposed updates for CUPS-PDF packages at Ubuntu<p>For those who use CUPS-PDF on <strong>Ubuntu</strong>, I have pushed some updated packages into <em>Lucid-proposed</em>, <em>Maverick-proposed</em> and <em>Natty-proposed</em>, mainly to make the package's post-install actions bulletproof, so that automated installs and PPD updates take place in a flawless way. Comments from anyone who tested these package updates are welcome on Launchpad bug <a href="https://bugs.launchpad.net/ubuntu/+source/cups-pdf/+bug/805947">#805947</a>. Once these updates have been approved, I'll go through the daunting task of reducing the <code>debdiff</code> down to its utmost essential components and attempt to submit a <em>stable-update</em> to <strong>Debian</strong> as well.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0