Codehelp blog

I've not had that many problems with network-manager, until now. The new version in unstable is just completely broken on my machine. Sadly, I can't report why it failed as I inadvertently closed the terminal with the relevant output.

Suffice to say, nm repeatedly got the wrong IP address, an invalid route and failed to set a usable nameserver. I've had those problems before with wireless but when this started happening with a wired connection (which had always previously worked), it was time to move on.

I've noticed people using wicd instead and decided I didn't have time to debug nm, I have a worksession starting in Cambridge on Sunday and a shed load of work to do before that, all of which requires a stable network connection.

Installing wicd replaced network-manager which was nice, (nm has always had problems working with any other network config so this allowed me to skip the removal of nm myself). wicd initially had a few issues - which I managed to pin down to the remnants of the broken nm config and steps that I'd taken to try to fix it.

Turns out that I may have some unresolved issues with my router - even with wicd I had problems getting a route over wireless. However, wicd allows suitable configuration that both works and is easy to keep discrete from other configs. Nice work. I have to set a static IP over wireless in order to set a valid route (and netmask). Looks like the DHCP implementation on the router is borked.

I'm sticking with wicd though - the interface is better for what I need, the icon has a useful traffic indication as well as signal strength and it's worth pursuing to see if the previous intermittent nm errors affect wicd.

Neil McGovern noticed me using drivel for my blog entries at the recent Debian UK BSP for Lenny and as he isn't using it anymore, suggested that I might want to take over maintenance. It's always better to have a package maintained by a regular user of the program.

So, this is the blog post prior to the upload of the blog client, drivel.

I have a feeling that I may be taking on another upstream project into the bargain - I'm interested but not sure how much time it should consume. Upstream is not exactly active but that isn't a huge problem for me. There is a new unreleased version that needs a few fixes but the hardest part is the external bells and whistles, not the core of the program.

The initial upload fixes all the lintian stuff in the current package but drivel is a bit different to other packages, fixing bugs in drivel means having a way to test drivel with a variety of blogs, not just my own and that means setting up admin access to a variety of blog engines. Not sure I really want to be setting aside that much time.

Once the new version is in Squeeze, I'd welcome any ideas about extra functionality, provided all such ideas come with either patches or a willingness to test the upstream code against your own blog.

From tomorrow, if you start seeing bugs or getting email about your packages where the version string ends in em[0-9], or where dependencies mentioned by reportbug include such a version suffix, the user is running one of the two Emdebian distributions to be released alongside lenny (and based on lenny packages). You might also see Emdebian in the output of 'apt-cache policy' if your bug reports request or supply such data.

If there is any doubt that the bug is present in Debian, please immediately re-assign the bug to the buildd.emdebian.org pseudo-package in the BTS.

I'll be posting to d-d-a with more information on the releases and the em1 version suffix - just as soon as Lenny itself is released.

A patch for reportbug is being tested and I'll file the bug probably tomorrow. A large proportion of the development work to actually get Emdebian to the point of two releases only happened after the lenny freeze began. (Not the recent deep freeze, the initial toolchain freeze before DebConf8). (reportbug itself is not currently part of Emdebian for a variety of reasons.)

Emdebian only uses a small subset of Debian packages, so this principally involves the core packages in Debian, GTK+2.0 and dependencies, XFCE and GPE as well as a small number of applications like iceweasel, sylpheed, xchat-gnome and grisbi.

The two Emdebian distributions will be:

Emdebian Grip 1.0 (lenny)

A small Debian-compatible Emdebian installation

Full release title:

    Emdebian GNU/Linux Grip 1.0 (based on Debian GNU/Linux 5.0 "lenny"). 

Short release name: 

    Emdebian Grip 1.0 (lenny)

Common release names:

    Emdebian Grip or Grip (lenny)

Architectures: i386, amd64, powerpc, arm, armel, mips and mipsel

Emdebian Grip explicitly supports mixing Debian and Emdebian and that is how a Debian package could end up depending on a package from Emdebian Grip - this is not expected to be a problem because Grip packages are binary-compatible with the Debian version, just with some files removed from the package. (i.e. Grip is post-processed, not recompiled.) Grip typically comes in at ~600Mb for a full XFCE desktop and uses the Lenny debian-installer images. (Grip base system ~250Mb.) I'm currently running Emdebian Grip on my Acer Aspire1.

More information: http://www.emdebian.org/grip/

Emdebian Crush 1.0 (lenny)

The smallest Emdebian installation - cross-built from Debian sources.

Full release title:

    Emdebian GNU/Linux Crush 1.0 (based on Debian GNU/Linux 5.0 "lenny"). 

Short release name:

    Emdebian Crush 1.0 (lenny)

Common release names:

    Emdebian Crush or Crush (lenny) 

Architectures: arm only 

More information: http://www.emdebian.org/crush/

Crush is the cross-built distribution from Emdebian - significant functional changes exist compared to the Debian package, libraries have been recompiled with options turned off and functionality removed etc. and Crush has dropped support for python or perl, and uses a modified, more recent version of busybox instead of coreutils. Crush is the hardest distribution to install, maintain and update and requires extensive customisation for particular machines with the benefit that it is an ultimately flexible Debian where the base system (equivalent to a debootstrap in Debian) can fit into 24Mb installed and a GPE GUI in 75Mb. uClibc support is expected in Crush 2.0 (squeeze), allowing sizes to shrink by another 10Mb or so. I'm currently running Emdebian Crush on my balloon3.

Theodore wonders about LUG activity - well, I have been very active over the years in the Devon and Cornwall GNU/Linux User Group but the problem is that Debian (and more specifically Emdebian) is taking up the time that I used to put into the LUG. The LUG itself has remained very active, although geography means that meetings are actually difficult. The LUG continues to attract new members, existing members continue to contribute and learn new stuff themselves and a number of the long-standing members have joined free software organisations in their own right - including Debian. If there is going to be another DD in Devon or Cornwall besides myself, I'm pretty sure that the person will have been part of the DCGLUG before considering joining Debian.

I'm still webmaster for my local LUG, I get to some meetings although some do conflict with existing Emdebian meetings.

What do I get out of it? Local friendships and exposure to GNU/Linux issues outside Debian.

Debian can be a very insular world - we care about Debian, we talk about Debian, we get together as Debian but sometimes we lack comparative input. We don't really know how we compare with other operating systems and other distributions at a user level. Debian Developers, in particular, can easily lose touch with ordinary users of other systems. Debian, for me, is also a distant world geographically. I live a long way from other DD's in the UK who gravitate towards Cambridge, 300 miles away. It's just nice to have people within 10-50 miles, people I can contact about hardware issues and who have just the part I need because they kept it "just in case".

I still contribute on the LUG mailing list, although my contributions are generally related to licences, avoiding non-free rubbish and issues around embedded devices. I'm not as active as I'd like to be or as I have been in the past but I still want to be part of the LUG.