+

+ Half the Coverity issues in Gnash fixed in the next release +

+

+ 29th April 2014 +

+

I've been following the Gnash +project 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 +Lightspark 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.

+ +

A few months ago, I started looking at +Coverity, 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.

+ +

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.

+ +

If you want to help out, you find us on +the +gnash-dev mailing list and on +the #gnash channel on +irc.freenode.net IRC server.

+ +

+

+ + + Tags: english, multimedia, video, web. + + +

+

+ Install hardware dependent packages using tasksel (Isenkram 0.7) +

+

+ 23rd April 2014 +

+

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 +my Isenkram +package. 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.

+ +

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 +/usr/share/tasksel/descs/isenkram.desc and look like +this:

+ +

+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
+

+ +

The second part is in +/usr/lib/tasksel/packages/for-current-hardware and look like +this:

+ +

+#!/bin/sh
+#
+(
+    isenkram-lookup
+    isenkram-autoinstall-firmware -l
+) | sort -u
+

+ +

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.

+ +

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 +#719837 and +#730704). The cause is in +the python-apt code (bug +#745487), 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.

+ +

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 +DEP-11, and +GSoC +project 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.

+ +

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 +the pymissile +package or submit a bug report with the details to the isenkram +package. See also +all my +blog posts tagged isenkram 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.

+ +

+

+ + + Tags: debian, english, isenkram. + + +

+

FreedomBox milestone - all packages now in Debian Sid @@ -675,6 +837,31 @@ image.

Entries from April 2014.

Archive