1. Folks may want to use this recording in free software.
To the extent possible under law, I have waived all copyright
and related or neighboring rights to this work. The frogs have too.
An email or a link to this page would be appreciated though.

Over the past months we have seen the end of two Debian derivatives.
In January the news came that Junta de Extremadura (Spain) were abandoning
the development of LinEx and switching to Debian itself.
Early in March the Debian derivatives census scripts noted that the
Vanillux apt repository was down.
Fabrice Quenneville then confirmed that he had to put a hold on
the Vanillux project due to the cost of bandwidth and servers.
In addition the future of StormOS is in doubt after
Illumian was created.
StormOS is a port of Debian to the OpenSolaris kernel and Illumian is similar
but uses only apt/dpkg and repackages everything else.

The LinEx page in the Debian derivatives census did not reveal much
information about the project that would have been useful to Debian, in
particular it does not list any apt repositories.
As a result it is quite hard to say what has potentially been lost.
Twomails from people close to or involved in the project
indicate that much of the LinEx distribution was already merged into Debian.
It is probably safe to say that everything of value has been merged into Debian,
including at least one of the developers involved in LinEx.

Vanillux was a small distribution with few developers according to the Google
caches of their website.
If we look at the patches created by the derivatives census scripts,
we can see that the 5 source packages that were possibly derived from Debian
source packages were simply imported from Christian Marillat's repository of
non-free, patented, legally restricted and multimedia-related packages.
The patches indicate that 3 source packages were forked from Debian and that
2 source packages were done from scratch.
The forked packages seem to be mainly about enabling support for proprietary and
patented codecs in several programs.
This is a surprisingly small number of altered/differing packages, so what else
could Vanillux folks have been working on?
It appears that there were 12 new source packages that were not derived
from Debian source packages.
These appear to be mainly multimedia-related packages, one font imported from
an Ubuntu PPA, some syslinux themes and a metapackage.
The multimedia packages are all from Christian Marillat's repository.
The Debian multimedia team is working hard on bringing multimedia related
software to Debian and welcomes help with that.
The font (Cantarell) is now in Debian under a different source package name.
The metapackage appears to be very similar to from the ubuntu-meta source
package from Ubuntu that uses germinate.
So at first glance, the contribution of Vanillux to the world of Linux
distributions appears to be in the area of artwork and package selection.
The artwork produced is basically Vanillux branding and is thus not usable by
Debian, although we would like more artists involved in Debian.
The meta-package is not easily useful to Debian since we use a different
mechanism for our task packages and our task packages have already been updated
for the GNOME 3 transition.
Still, the amount of difference between to source packages is relatively small.
So, what else?
Perusing the diff between the list of source packages exposed by the
Packages and Sources files, I noted that a number of binary packages in the
Packages files reference source packages not listed in the Sources files.
When I saw picasa in that list, it occurred to me that Vanillux might have
directly imported some binary packages without their corresponding source
packages.
Perusing their apt metadata confirms that they have imported some
binary packages of non-free software directly from vendors. These include
Google Desktop, Opera, Picasa and VirtualBox 3.2.
The rest of the packages in the diff appear to be caused by some sort of
issue with the import process from Debian and other apt repos.
Most of the above could be achieved by adding some external commerical
repositories to a normal Debian system or by merging some of those
repositories (such as the Opera one) into Debian.

The interesting thing about the Debian derivatives census is that it allows us
to perform analyses like these and figure out what patches and packages we might
like to integrate into Debian. In this way we can salvage some of the value of
our derivatives if they abandon ship.

If you have any ideas or code for improving the census or are running a Debian
derivative, please join us at the Debian derivatives frontdesk.

We recently held a Debian bug squashing party (BSP) in Perth,
Western Australia.
Over the weekend we had about 10 or so people show up to participate, learn
about fixing bugs in Debian and try to fix some.
The BSP co-incided with a weekend heat wave with temperatures reaching 38°C and
the venue lacked air conditioning.
Most of the attendees were new to Debian development but were Debian users.
Our focus was on release critical bugs highlighted by rc-alert and the
UDD bugs list, but we also discussed IPv6 bugs in CUPS and some bugs
that were affecting UCC infrastructure.
The UCC president also worked on fixing their door-locking system, replacing
the broken system based on an ancient modem with an Arduino board.
We managed to fix, work on or investigate 12 or more bugs.
I was hoping we would get through more, but the weather and the average
experience level conspired against us.
After we were done on Sunday a few of us went down to the local pub to have a
meal, a beer and some geeky conversation.
All in all we had a good time and got some bugs fixed.

The UCC president seemed to be keen on doing another BSP, hopefully we can do
another one before the freeze happens.
There were a few people who missed the BSP so it would be good to give them a
chance to work on some bugs.

Thanks go to the UCC folks for the venue and to PLUG folks
for helping with organisation and promotion of the event.

Unfortunately, only 5 people participated in the screenshots party, I had hoped
that we would get more folks turn up. Only one of those was not already involved
in the games team and that one person found out via our spam on the
#debian-mentors IRC channel. This means that most of our promotion
of the event was ineffective. Hopefully for future games parties we can
improve this, please let us know if you have any ideas about that.

We also had 7 other people on the channel during the party lurking, discussing
and or working on other things, in particular Ben Armstrong was working on a
games live CD.

Over the 7 hours of the party, we uploaded 100 screenshots for 40 different
packages. Of the packages, 2 are available only in Debian (auralquiz, cutechess),
one is available only in Ubuntu (plasma-widget-tictactoe) and the rest are
available in both. I think we got quite a bit done for such a small group.

Some of us could not resist filing some bugs on packages that had
issues preventing or delaying us from taking screenshots. I also suggested to
one maintainer that his package (acm4) be removed from Debian, since it is
obsoleted by acm and unusable.

If you want to play some games, check out goplay, which is a tool for
browsing available games using debtags that displays screenshots from
the games-thumbnails package, which has just been updated with the
screenshots created during the party. goplay needs some more development, if you
would like to help out with that, you would be most welcome.

Have you ever wondered how to start getting involved in Debian/Ubuntu?
Do you enjoy discovering new games and playing them?
You might want to come to the games screenshot party!
We hope that the party will be a fun, easy, low-commitment way to get involved.

If you are interested in attending, please add your availability to the poll
linked from the announcement so that we can get some idea of
attendance and when is a good time for the people who are interested.

Look forward to lots of game playing, screenshots and a merry time,
hope to see you all there!

There is a Debian bug squashing party (BSP) in Perth, Western Australia
being organised for the weekend of 9-11th of March.
It will be held at the University of Western Australia in loft of the
University Computer Club (UCC) in the student guild building.
Sadly it is a bit far to travel for the majority of Debian contributors
(and they probably wouldn't enjoy being upsidedown) but
hopefully we can attract some locals and get them addicted to fixing bugs
and contributing to Debian and the FLOSS community in general.

Come one, come all, lets squish some bugs and get Debian into better shape for
the coming freeze in June for the release of Debian 7 (wheezy).

Thanks go to the UCC folks for the venue and to PLUG folks
for helping with organisation and promotion of the event.

Debian is finally transitioning from the unmaintained and Debian-specific font manager called defoma. The replacement is called fontconfig and it is maintained upstream and in Debian (by upstream) and is cross-distribution with wide support from our upstreams and other distributions. With the upload of libwmf 0.2.8.4-9 (thanks Loïc!) the last package in Debian sid declaring a strict dependency on defoma has removed this dependency. There is still more todo, some more bugs to file and some lenny->squeeze->wheezy upgrade testing to do. Thanks go to Christian PERRIER for slogging through and providing encouragement, bug reports and NMUs. The transition is unfortunately not without loss of functionality;

Xorg does not yet support fontconfig so for now programs relying on server-side fonts will only be able to use the xfonts- packages shipping their fonts in the directories known by the X server. According to Keith Packard it isn't easy to add fontconfig support to Xorg, there are some ways to paper over this though. We could use the Xorg server's font catalogue system to link to a fontconfig provided symlink farm (similar to what is done with defoma & Xorg). We could adjust the Xorg fonts utils to recurse into subdirectories. As far as I can tell, other distributions have completely ignored this issue and not all fonts are available to the Xorg server there.

There are some issues with Ghostscript and CJK that I do not fully understand, I am hoping these can be resolved before the release of wheezy. We need people to restart work on this issue.

TeX uses a different directory for fonts to the rest of the system. Fonts used by TeX cannot be used by the rest of the system and vice versa. This issue has always existed in Debian and other distributions and is unrelated to the removal of defoma.

If your software doesn't use one of the text renderers (such as Pango, Qt or QuesoGLC) that find fonts on their own and fall back on other fonts where needed (due to missing fonts or glyphs), please switch text rendering systems. If you are unable to switch, please use fontconfig to search for font filenames rather than hard-coding them at build time.

This message brought to you by the Debian Fonts Task Force. We welcome people who want to help us maintain font packages or improve support and quality assurance for fonts and font related software.

The Debian/Ubuntu games team is organizing another meeting,
if you're into developing and/or packaging of games, or just generally curious
about games in Debian/Ubuntu, you should join!

It will be held next Saturday, on the 26th of November, in the #debian-games
channel on irc.debian.org (also know as irc.oftc.net). More information is
available on the meeting wiki page.

The agenda starts off with the usual round of introductions, so if you're
new to the team, say hi! Then we'll be going through the action items from
the last meeting, including work on the Debian Games LiveCD, and what's up
with the /usr/games/ path anyways?

Next we'll be moving onto how the games team is faring in terms of members:
are new recruits finding it comfortable, should we advertise more?

Next up it's the squeeky penguin: Wheezy is somewhere in the
not-completely-distant future, how does that affect the games team, should
we be scuffling to get specific tasks done?

Then onto the recurring question of sponsoring, and how to improve it,
should we be utilising DebExpo more? What about our favourite
PET?

Lastly, PlayDeb is doing some really neat stuff, would it make
sense for our team to push some changes to PlayDeb? Would it make sense for
PlayDeb to push changes to Debian Games?

Hopes are for a good discussion, and a merry time, hope to see you all there!

I have been a long-time user of the Galeon web browser, which,
while powerful for its time, is getting a bit long in the teeth and has
been abandoned for a long time. As a result I need to find something new.

As Galeon uses the Mozilla engine I figure switching to Iceweasel/Firefox
will be the least amount of pain since they share similar formats for lots
of the user configuration and data (with the exception of history). Switching
to Firefox also gives me access to a lot of configurability and a vast sea
of extensions all written in RDF, JavaScript and zoooool (ahem, XUL). Another
plus was that I was already using Firebug for the occasional web development
project.

Looking at the Mozilla addons site is like entering someone's shed. There
will be the few beautiful unfinished projects still being worked on, one
polished finished scuplture gathering dust but still admirable, things with
power plugs from a bygone era, some things that have a coin slot on them,
some cryptic machines with no visible screws or manuals, some spiders and
their cobwebs and a few rats and mice chewing through things. A place where
you can find some excellent, well documented, useful and Free Software
extensions alongside lots of crud. Luckily for me the good stuff that I
wanted to use was already in Debian or the friendly Debian Mozilla extension
maintainers team was willing to package them for me.

In my quest for freedom from Galeon I first noticed that there is no up button
in Iceweasel. Bummer, I use that a lot so I went searching for extensions.
I soon found one extension, but it hadn't kept up with the ever-changing
Mozilla APIs so it fell by the wayside. Thanks to the leavers of breadcrumbs
I picked up the trail to a new shiny and working extension. Lo-and-behold I
found Uppity, which was all about going up and as it turns out,
much better at that than Galeon. Thanks to MozExt team, thats solved, next!

The next glaring problem was the lack of Galeon-style smart
bookmarks. Before you ask, yes, Firefox smart keyword bookmarks are not
the same thing. This was rediculously hard to search for due to the wording
used by both projects being same same but different. Some folks switched to
Epiphany to get the extra search boxes on their toolbars. Like
this guy I was not interested in that, mainly due to the addons
I would be missing out on. I tried a few different tacks, even searching for
a way to have multiple search boxes in the Firefox toolbars. I soon gave up
on finding an extension that would do this like Galeon does so I figured its
time to roll up the sleeves and learn some zzzoooool. I already know a little
bit about JavaScript and CSS so... First slap a dash of a tutorial about
adding toolbar buttons, add a slither of adding extensions without installing
them, stare down some Mozilla reference manuals, thrown in a pinch of
favicons, give up on a wild goose chase or two, add a big fat blob of zoooool
and sautee in fugly hacks. Soon enough you will have something hardcoded
that works like Galeon smart bookmarks but looks even better.

I may eventually turn this into a proper and functionally equivalent extension
for Galeon-stlye smart bookmarks but for now it will remain a useful hack.
If you want to get your hands dirty with zzzoooooool and try this out after
modifying it to use your personal search URLs, please feel free to
contact me.

For now the only remaining issue I can see is that the forward/back buttons
in Iceweasel don't have the explict menu buttons. This is a minor issue for
me so now it is time for me to figure out how to migrate my data and
config1 before permanently switching away from Galeon.

Wish me luck!

1. Of course the data and config are fugly, but that is a something
for another, much broader and more complicated hack

Whenever I want to login to a Debian porterbox to figure out some
architecture-specific issue I typically do not care which particular
host I am going to login to, just what architecture the host is.

After discovering that it is not yet easy for the Debian
sysadmins (DSA) to add aliases to DNS for this purpose, I whipped up
a quick script to grab the relevant data about Debian machines
from the Debian LDAP server and work around this in my OpenSSH config.

To use the script you should run the script and place the magic
comment lines suggested by the script into your ~/.ssh/config file and
then run the script again, which will contact the Debian LDAP server using
python-ldap, download the relevant information and replace the
relevant part of your ~/.ssh/config file with some OpenSSH configuration
directives to map Debian architecture names to hostnames. Within just a
few seconds you will be able to login to armel, powerpc.port or
kfreebsd-amd64.port.debian.org instead of needing to manually look
up which servers to login for a particular architecture.