<link>http://people.skolelinux.org/pere/blog/</link>
+ <item>
+ <title>Half the Coverity issues in Gnash fixed in the next release</title>
+ <link>http://people.skolelinux.org/pere/blog/Half_the_Coverity_issues_in_Gnash_fixed_in_the_next_release.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Half_the_Coverity_issues_in_Gnash_fixed_in_the_next_release.html</guid>
+ <pubDate>Tue, 29 Apr 2014 14:20:00 +0200</pubDate>
+ <description><p>I've been following <a href="http://www.getgnash.org/">the Gnash
+project</a> for quite a while now. It is a free software
+implementation of Adobe Flash, both a standalone player and a browser
+plugin. Gnash implement support for the AVM1 format (and not the
+newer AVM2 format - see
+<a href="http://lightspark.github.io/">Lightspark</a> for that one),
+allowing several flash based sites to work. Thanks to the friendly
+developers at Youtube, it also work with Youtube videos, because the
+Javascript code at Youtube detect Gnash and serve a AVM1 player to
+those users. :) Would be great if someone found time to implement AVM2
+support, but it has not happened yet. If you install both Lightspark
+and Gnash, Lightspark will invoke Gnash if it find a AVM1 flash file,
+so you can get both handled as free software. Unfortunately,
+Lightspark so far only implement a small subset of AVM2, and many
+sites do not work yet.</p>
+
+<p>A few months ago, I started looking at
+<a href="http://scan.coverity.com/">Coverity</a>, the static source
+checker used to find heaps and heaps of bugs in free software (thanks
+to the donation of a scanning service to free software projects by the
+company developing this non-free code checker), and Gnash was one of
+the projects I decided to check out. Coverity is able to find lock
+errors, memory errors, dead code and more. A few days ago they even
+extended it to also be able to find the heartbleed bug in OpenSSL.
+There are heaps of checks being done on the instrumented code, and the
+amount of bogus warnings is quite low compared to the other static
+code checkers I have tested over the years.</p>
+
+<p>Since a few weeks ago, I've been working with the other Gnash
+developers squashing bugs discovered by Coverity. I was quite happy
+today when I checked the current status and saw that of the 777 issues
+detected so far, 374 are marked as fixed. This make me confident that
+the next Gnash release will be more stable and more dependable than
+the previous one. Most of the reported issues were and are in the
+test suite, but it also found a few in the rest of the code.</p>
+
+<p>If you want to help out, you find us on
+<a href="https://lists.gnu.org/mailman/listinfo/gnash-dev">the
+gnash-dev mailing list</a> and on
+<a href="irc://irc.freenode.net/#gnash">the #gnash channel on
+irc.freenode.net IRC server</a>.</p>
+</description>
+ </item>
+
+ <item>
+ <title>Install hardware dependent packages using tasksel (Isenkram 0.7)</title>
+ <link>http://people.skolelinux.org/pere/blog/Install_hardware_dependent_packages_using_tasksel__Isenkram_0_7_.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Install_hardware_dependent_packages_using_tasksel__Isenkram_0_7_.html</guid>
+ <pubDate>Wed, 23 Apr 2014 14:50:00 +0200</pubDate>
+ <description><p>It would be nice if it was easier in Debian to get all the hardware
+related packages relevant for the computer installed automatically.
+So I implemented one, using
+<a href="http://packages.qa.debian.org/isenkram">my Isenkram
+package</a>. To use it, install the tasksel and isenkram packages and
+run tasksel as user root. You should be presented with a new option,
+"Hardware specific packages (autodetected by isenkram)". When you
+select it, tasksel will install the packages isenkram claim is fit for
+the current hardware, hot pluggable or not.<p>
+
+<p>The implementation is in two files, one is the tasksel menu entry
+description, and the other is the script used to extract the list of
+packages to install. The first part is in
+<tt>/usr/share/tasksel/descs/isenkram.desc</tt> and look like
+this:</p>
+
+<p><blockquote><pre>
+Task: isenkram
+Section: hardware
+Description: Hardware specific packages (autodetected by isenkram)
+ Based on the detected hardware various hardware specific packages are
+ proposed.
+Test-new-install: mark show
+Relevance: 8
+Packages: for-current-hardware
+</pre></blockquote></p>
+
+<p>The second part is in
+<tt>/usr/lib/tasksel/packages/for-current-hardware</tt> and look like
+this:</p>
+
+<p><blockquote><pre>
+#!/bin/sh
+#
+(
+ isenkram-lookup
+ isenkram-autoinstall-firmware -l
+) | sort -u
+</pre></blockquote></p>
+
+<p>All in all, a very short and simple implementation making it
+trivial to install the hardware dependent package we all may want to
+have installed on our machines. I've not been able to find a way to
+get tasksel to tell you exactly which packages it plan to install
+before doing the installation. So if you are curious or careful,
+check the output from the isenkram-* command line tools first.</p>
+
+<p>The information about which packages are handling which hardware is
+fetched either from the isenkram package itself in
+/usr/share/isenkram/, from git.debian.org or from the APT package
+database (using the Modaliases header). The APT package database
+parsing have caused a nasty resource leak in the isenkram daemon (bugs
+<a href="http://bugs.debian.org/719837">#719837</a> and
+<a href="http://bugs.debian.org/730704">#730704</a>). The cause is in
+the python-apt code (bug
+<a href="http://bugs.debian.org/745487">#745487</a>), but using a
+workaround I was able to get rid of the file descriptor leak and
+reduce the memory leak from ~30 MiB per hardware detection down to
+around 2 MiB per hardware detection. It should make the desktop
+daemon a lot more useful. The fix is in version 0.7 uploaded to
+unstable today.</p>
+
+<p>I believe the current way of mapping hardware to packages in
+Isenkram is is a good draft, but in the future I expect isenkram to
+use the AppStream data source for this. A proposal for getting proper
+AppStream support into Debian is floating around as
+<a href="https://wiki.debian.org/DEP-11">DEP-11</a>, and
+<a href="https://wiki.debian.org/SummerOfCode2014/Projects#SummerOfCode2014.2FProjects.2FAppStreamDEP11Implementation.AppStream.2FDEP-11_for_the_Debian_Archive">GSoC
+project</a> will take place this summer to improve the situation. I
+look forward to seeing the result, and welcome patches for isenkram to
+start using the information when it is ready.</p>
+
+<p>If you want your package to map to some specific hardware, either
+add a "Xb-Modaliases" header to your control file like I did in
+<a href="http://packages.qa.debian.org/pymissile">the pymissile
+package</a> or submit a bug report with the details to the isenkram
+package. See also
+<a href="http://people.skolelinux.org/pere/blog/tags/isenkram/">all my
+blog posts tagged isenkram</a> for details on the notation. I expect
+the information will be migrated to AppStream eventually, but for the
+moment I got no better place to store it.</p>
+</description>
+ </item>
+
<item>
<title>FreedomBox milestone - all packages now in Debian Sid</title>
<link>http://people.skolelinux.org/pere/blog/FreedomBox_milestone___all_packages_now_in_Debian_Sid.html</link>
projects / homepage.git / blobdiff