Emdebian Grip 1.0.1 (based on Debian GNU/Linux 5.0.6) is now available.

Emdebian Grip is binary-compatible with Debian, providing smaller packages for use on embedded devices. Emdebian Grip selects a subset of Debian packages and removes documentation and other non-binary content without recompiling the source code. Currently, Emdebian Grip supports amd64, arm, armel, i386, mips, mipsel and powerpc in the stable distribution. ARM support will be dropped in the next stable release in favour of armel.

This is the first update of the stable distribution Emdebian Grip (based on Debian GNU/Linux 5.0), bringing Emdebian Grip up to date with Debian 5.0.6. This update mainly adds corrections for security problems to the stable release, along with a few adjustment to serious problems.

Please note that this update does not constitute a new version of Emdebian Grip 1.0 or Debian GNU/Linux 5.0 but only updates some of the packages included. Systems will upgrade to 1.0.1 via the Emdebian mirror after an installation.

For more details on the changes within Debian through 5.0.1, 5.0.2, 5.0.3, 5.0.4, 5.0.5 and now 5.0.6, see the Debian news website.

As well as updates to packages which already existed in Emdebian Grip 1.0, the update includes many new packages, including apache2, aspell and variants, and matchbox.

e.g. 822 packages were released for armel in Emdebian 1.0; this update increases that number to 1,297.

In case anyone else hasn't found these tweaks:

termcapinfo xterm|xterms|xs|rxvt ti@:te@

In ~/.screenrc gives you Shift-PageUp and Shift-PageDown control again, without resorting to Ctrl-A Esc, inside screen. (Best to do

$ cp /etc/screen.rc ~/.screenrc

as a starting point first, if not done already.)

Also:

/set scroll_page_count /2

/save

In irssi itself (easier than editing the config) gives you internal PageUp, PageDown control within the irssi window.

In each case, the manpage is so long and impenetrable that these may be obvious to those with a special knowledge of terminals but mere mortals like me can't find it in / understand the docs.

Eben Moglen's talk at DebConf10 has inspired a flood of responses and activity at DebConf10. The original talk overran the allotted time within the venue and then outside the venue for something like an hour, HackLab discussions migrated to the single theme and brought in more and more people over lunch. When the Skype talk was left without a speaker in the afternoon, it morphed into a FreedomBox BOF with maybe 100 delegates planning and contributing to the ideas and another BOF is planned for Friday. A rough outline is appearing on the wiki page for those who want to follow it and the video of the original talk is available, linked from that Wiki page.

What gets people excited about this project is that we already have all the components to do the work, people have been doing most of this stuff at home, on their own, for some time and it needs to be brought together as a series of packages and meta packages and other middleware glue to get it working. (multistrap is part of that glue - it's already being used commercially in a similar role. Debian Pure Blends is another part of the glue. This can be a Debian solution, it doesn't have to be a separate project.)

The software and glue doesn't have to be dependent on a single hardware platform, this is about getting the software right and deploying it on whatever hardware can run it - albeit that the architecture itself is likely to be ARM-something.

It is time for social networking to be freed from the man-in-the-middle - time to withdraw user data from central servers owned by some third-party and share directly with your friends (whichever network they use). Aggregate all data from all your friends, keep all your data in your own plug and access it from wherever you are using whatever devices you have to hand. What's more, your friends - especially the non-techy friends - can just buy a cheap beige box that hides away in the corner of their home and have all the same access too - everyone gets to choose exactly which pieces of data get shared and to whom and can then use their friends plugs to store encrypted backups of their other data. Or maybe the final solution will be slightly different - it's up to people in Debian to make it happen. The tools are in our own hands, if we want this, we just need to do it.

What is needed now is some direction, there are choices to be made about how the glue is designed and how this is turned into a "self-discoverable" distributed network service. Yes, IPv6 will make this easier but only once ordinary users can deploy the device transparently and without configuration, so an interim solution will be needed.

Who's up for the challenge?

check-deps.sh

Phil Hands and I devised a little script which is currently packaged as part of multistrap to check the dependencies of a .deb package before installing it - called check-deps.sh and can be found at /usr/share/multistrap/check-deps.sh. I just thought I'd publicise it a bit because it can help with one of my common test cases - when a binary package changes dependencies but you haven't uploaded it yet.

check-deps.sh takes a .deb to the command line -f|--file option and outputs the dependencies of that .deb and whether those dependencies (at the requested versions) exist in your apt-cache policy. Optionally, you can use check-deps.sh to also then install those dependencies (not the dependencies that would come from the current version in the repository) and the package itself.

I've found this to be a much more friendly way of satisfying runtime dependencies of a package. Where things like pbuilder would just force install the .deb and then get apt-get -f install to try and fix things, check-deps.sh will fail if the required dependencies are not available in the first place.

The benefits are two-fold. First you get to see the full list and you can easily see if your work to drop a dependency has just resulted in another package bringing that dependency back in etc. Secondly, you can test whether your .deb is installable without breaking your system and then having to remove it - e.g. against backports or a Debian derivative test chroot. It should be possible to extend the script to read Build-Depends but that means reading the input from the source package, not the built binary. Might be just as easy to have a second script for Build-Depends.

(Comments are still disabled due to spammers and time-wasters, but if you would like to see check-deps.sh more widely used or extended it isn't that hard to find my email address at debian.org.)

xapt

Another new perl script, this time using the multistrap and apt-grip core to replace the apt-cross breakage to install cross-dependencies of a Debian source package. xapt has very few dependencies (dpkg-dev, dpkg-cross, apt, perl) and very simple logic. It doesn't try to second-guess which packages to use as dependencies of cross packages, it just gets them all. As such, it still isn't the tool we need for optimal cross-dependency resolution, but then neither is apt-cross - come to that, Multiarch or sysroot aren't going to provide the right tool any time soon either. So xapt at least gets over the worst of the design problems in apt-cross (by not using the apt perl bindings mainly) and seems to just work within clean chroots which is where apt-cross has the most problems.

xapt will be a new binary package, so it will need to go through NEW but I'm looking at using it as part of pdebuild-cross because it is faster than apt-cross and seems to work much more efficiently than apt-cross inside a clean chroot. xapt does not care about multiarch or sysroot, it just gets the packages and passes them to dpkg-cross. Normally, xapt cleans up after itself but you can choose to leave the built packages in /var/lib/xapt/output if that is useful.

I've grown tired of the firefox/iceweasel memory hog for a couple of reasons:

• it is such a memory hog and this isn't a machine particularly short of RAM but I still notice it when compiling with a few FF windows open and FF is just generally slow.
• the upgrade behaviour of iceweasel is getting tedious, begging for a restart every time I do apt-get upgrade recently.

Chromium is just faster, everywhere. A nice touch is the new tab behaviour too - previews of the most recently viewed pages is far more useful than the usual homepage. Chromium is also faster than epiphany/webkit.

I'll still be using two different browsers, because neither iceweasel nor chromium can do the clever smart bookmarks thing of epiphany. I have come to utterly rely on bookmark input boxes for direct access to specific Debian bug numbers, individual PTS pages, Google searches, dwww searches, specific manpages, buildd reports and various other pages where a bookmark really needs to be an input box, not a label, and the bookmark itself sits on a toolbar and can then use http://url/%s which makes life so much easier.

Update

I wondered if epiphany smart bookmarks would be understood but apparently not. So:

The smart bookmarks are BTS, Google, PTS, buildd and man. At work, I've got a wider screen and I add several more for internal bug tracker numbers and similar.
Chromium and iceweasel/FF have nothing like this. Entering a bug number is utterly trivial - it even works with middle mouse button paste which, cleverly, opens the page in a new tab too. Iceweasel/FF can do this ONCE but only once, via an extension. The key points with epiphany are:

• It is trivial to setup - just make a bookmark with a %s and put that bookmark onto a toolbar - any toolbar.


• it is trivial to use and never needs any use of the address bar or editing anything


• It works for any query which can have a single argument at any point in the URL.


• You can have as many as you want, subject to how many toolbars you can use

So, yes, Leo, the way epiphany does this is massively more effective for a "work-type" browser situation where there is such a need to access a specific page immediately, with no editing or keyboard usage.

Turns out that the football is insufficiently engaging to distract me from picking up the laptop, but sufficiently noisy that I don't get time to think about more complex problems (leave those for weekday evenings), so weekends seem to offer a brief window to relax and do some QA/RC uploads.

As we're not yet in freeze, I'm not doing 0-day NMU's (although I am offering 7 day NMU's), but QA uploads can all be 0-day. Overall, it's proving to be quite useful and a lot easier than sponsoring NEW packages.

So far, RC uploads:

• 572464: ceferino


• 572470: gregorio

RC offers:

• 582422 : bacula


• 579378 :dibbler

QA uploads:

• gnome-pilot


• gnome-pilot-conduits


• rezound


• filerunner


• cdcover

Didn't think I'd get time to stuff like that with Squeeze.

multistrap is gaining some important functionality. When preparing a root filesystem for a new product, the sources used to generate the system need to be made available. So, multistrap has an option to retain the sources and 2.1.5 adds the functionality of downloading the source packages to go alongside the binaries that are downloaded to make the system itself, into a directory outside the final system.

Equally, 2.1.5 includes the idea (contributed by Rodolfo Giometti) of not listing deb-src entries inside the final filesystem - a useful idea to save space on systems where there is no likelihood of sources actually being downloaded "on-device".

Also in 2.1.5, is a handler for device tables. udev is one thing but when creating new systems from scratch, some devices still need to be created with mknod. MAKEDEV is too general, creating dozens of nodes when maybe only a handful are needed yet also omitting device nodes that actually are needed. So, /usr/share/multistrap/device-table.pl can parse a mini device table file (a tab-separated-value file), creating directories, symlinks and device nodes in a specified directory.

The aim is to combine the entire generation of a bootable root filesystem in a single call to multistrap - to which two further steps are necessary.

1. Packing up into a tarball at the end


2. Running a customised script outside the eventual filesystem, passing it the location and architecture of the filesystem.

Both are in 2.1.5 - the config script can be used to pre-seed debconf questions, write out custom configuration changes, run the device table parser and various other tasks.

As with earlier versions, multistrap supports creating package building chroots (including cross-building chroots) and, to go alongside this functionality, pdebuild-cross has now entered unstable. pdebuild-cross is a set of hooks for pbuilder to support cross-building inside a pbuilder chroot created by multistrap.

I'm hoping to be able to cover more about these issues at DebConf10.

If debootstrap is not doing what you need, multistrap is probably the answer - and if it doesn't quite do what you need yet, ask.

From Planet Gnome - apologies if you read both planets but I hadn't seen this recall before it was posted by Richard Hughes. If you are affected, feedback the required metadata to upower using:

for i in /sys/class/power_supply/*/*; do echo $i; cat $i; done

My HP dv6000 laptop met the initial criteria but once I'd entered all the info, I got a message:

Your battery is not affected and is not part of this replacement program. 

Thank you for your cooperation. ..... You may continue using your battery.

Which is nice.

I'm going to Debconf 10:



I've also decided to put in a late submission for a talk about multistrap - a description of the new features in multistrap for creation of complex chroots and bootable root filesystems using apt to collect packages from multiple repositories and/or suites.

The current version of multistrap in experimental has gained a lot of features and will soon be migrating into Debian unstable where it will replace emdebian-rootfs and emsandbox - the old debootstrap scripts which haven't worked properly for a while. Documentation is lagging a bit but I'm in the process of updating the emdebian website with detailed docs on how multistrap can be used.

Also in NEW is pdebuild-cross, an extension to pbuilder which uses multistrap to create a cross-building chroot tarball and provides pbuilder hooks to allow svn-buildpackage to cross-build directly from SVN using pbuilder support. pdebuild-cross will, in time, replace most of the functionality in the old emdebian-tools package and dramatically simplify the dependencies of the old package in the process. The talk will briefly cover that too. pdebuild-cross is a little hamstrung by the well known bugs in apt-cross but alternatives can be easily incorporated when the time comes.

A new package - a set of hooks and wrappers to extend pbuilder and pdebuild for cross-building support - is heading to Debian experimental soon. Support depends on replacing debootstrap with multistrap when creating the cross building chroot and includes an svn helper to use alongside svn-buildpackage to cross-build directly from SVN.

There are limitations - apt-cross being the main one. Once these rough edges are smoothed over, pdebuild-cross could possibly migrate into pbuilder.

The reason to ditch debootstrap is so that the cross-building chroot can collect packages from multiple repositories (in this case, the emdebian toolchain repository). The package scripts support no options directly but will pass options down to the underlying tools. Other configuration happens in /etc/pdebuild-cross/pdebuild-cross.rc which is an extended pbuilder.rc file. I see this as a better option than bulking out the scripts with option support - especially at this stage of development.

Initially, pdebuild-cross will be a binary package built from the emdebian-crush source package (which itself replaces the emdebian-tools source package) and pdebuild-cross will depend on the version of multistrap also in Debian experimental.

Coming to Debian NEW soon....

SVN: http://www.emdebian.org/svn/browser/current/host/trunk/emdebian-tools/branches/2.2.0

I've put up a proposal for the Debian part of the Google Summer of Code 2010 and this proposal is based on previous work with edos-debcheck for Emdebian Grip. It started from a simple mailing list post.

Even without formally announcing the proposal, I've already got a potential student!

Regarding my previous post on source format 3.0, I think it came across that I was blaming lintian entirely which would be unfair.

(As a side-note, a bug in serendipity XMLRPC resulting in all entries having comments disabled has led to a welcome effect of spreading the discussion more widely than a series of comments on my own site could have achieved. I'm happy with this state of affairs, so it you want to comment, either contact me by private email or put your comments on your own blog. I won't be enabling comments any time soon.)

The extended information behind the lintian warning is one thing (I've explained my position on that to Russ privately) - my main objection is to how such a warning was pushed into lintian and the entire use 3.0 or be damned approach that seems to be being adopted.

IMHO, source format 3.0 is not good enough to be the standard dpkg source format for a simple reason: It offers nothing to well maintained packages. Not all packages need NMU's - ever. Not all packages have patches - ever. Native packages and packages with the Debian maintainer upstream gain nothing from 3.0, as far as I can see.

I have 67 source packages - after much very careful consideration, I have found that a handful of those (less than 10) actually benefit from 3.0 and the rest are all unaffected. None of the packages that I will keep on 1.0 have ever had an NMU since I've been maintainer, most are either native or entirely under my sole upstream control. I will decide whether Debian gets a .tar.gz or a .tar.bz2 and although I generally offer both for download where I can, I see no reason to adopt .tar.bz2 as my default for Debian packaging.

Adding a redundant directory and file is obnoxious. I fail to see why debian/source-format would not have been perfectly suitable. Nevertheless, I will do what is necessary to avoid 3.0 until there is a compelling technical reason to adopt it.

The imperative for those in favour of 3.0 is to convince me that there is a reason TO change, not to make it difficult for me NOT to change. I do not need any reason to avoid 3.0 other than I do not have a good enough reason to move from 1.0. Making developers feel like luddites or incompetent merely because the proponents of 3.0 have failed to convince others to move to 3.0 is just insulting. You want me to use 3.0? Explain why I should bother - the current "reasons" on the Wiki page are simply not good enough and any rehash of those will be ignored. Come up with something new or respect my decision and let me get on with more important stuff.

The new lintian addition "missing-debian-source-format" is starting to remind me of a pestering nanny.

I use source format 3.0 only where I see a technical benefit and that - so far - is restricted to packages that use a .tar.bz2 upstream and one or two with really tricky patching requirements. It is literally one or two as well - out of 67 source packages which I maintain (more than some of those nagging me to change).

Packages for which I am upstream and all my native packages will stick with source format 1.0 - because there is no technical reason to migrate. Packages where I'm not upstream but which continue to use .tar.gz and have minimal or absent patching needs will also stay with 1.0 indefinitely. (I can't see how dpkg can drop 1.0 support, even after multiple stable releases after Squeeze.)

I've no interest in being side-tracked into a pointless "discussion" with those who have already made up their minds that nobody could possibly think that 3.0 is unwelcome or uninteresting. Nagging me won't help - I don't consider 3.0 worth using and I see no technical reasons to adopt it blindly.

Crush 2.0 was abandoned last year when the freeze for Debian Squeeze was still scheduled to start at the end of 2009. Even with the expected delays in the timetable for the Debian release, there never was going to be enough time to get Crush 2.0 released with the resources available. Subsequent Crush releases have always been planned, only the release of Crush 2.0 alongside Debian 6.0 (Squeeze) was abandoned.

However, Emdebian Grip has developed nicely and Grip 2.0 is going to be a significant advance over Grip 1.0 - lots more packages, lots of bugs fixed for smoother installations, multistrap support, etc.

The success of Grip has led to a slim chance of working out something for Emdebian Crush. The current state of cross-building / multiarch in Debian means that cross-building more than a handful of packages is simply unrealistic with the resources available within Emdebian. Instead, Crush will be based on Grip for 2.0 and subsequent releases, until things settle out.

Packages that are in Grip and which are designed upstream for embedded situations will simply be made accessible in Crush without further changes. Cross-building packages like this results in binaries that are all but identical to the Grip equivalent. (There is a massive difference between adapting a package for Crush and designing the package from scratch for embedded use. Emdebian is not taking on that task.)

The changes that Crush will make are being calculated, using a shortlist of packages that are (typically) not designed for embedded use but which support a long, long string of --enable-foo options in the build system - most of which Crush can change into --disable-foo. This results in fewer dependencies for the resulting binary packages so that things like LDAP can be removed. The packages themselves are being selected on the basis of what was released in Crush 1.0 for compatibility reasons. The source packages and the resulting binary packages will be renamed (busybox-crush etc.) and suitable Provides: Replaces: and Conflicts: deployed, allowing mixing of Grip and Crush packages on one device.

Other changes are then based around replacing coreutils with a reconfigured busybox and removing perl completely. Wrapper scripts, helpers and other changes will try to stitch the gaps.

It's a chance, a bit slim but a chance nonetheless. The plan offers a possibility, a worthwhile experiment. If it works, Emdebian Crush 2.0 could be a reality on seven architectures and with 2,000 packages available, released alongside Debian 6.0 (Squeeze). If it fails, people will just have to wait for multiarch to settle out and Crush 3.0, due for release alongside Debian 7.0 (Squeeze+1). In the meantime, there's always Emdebian Grip.

I've got a few fixes to go into drivel 3.0.1 but I've been trying to decide on whether to re-factor the underlying code - libsoup specifically. Drivel has it's own way of handling xmlrpc messages and this method doesn't work well with the libsoup2.4 changes, so currently it backports some code from libsoup2.2. This isn't ideal for all the usual reasons and I've been waiting for time to sort it out.

Time is lacking. My change of career has dramatically changed the amount of time I have for upstream code and as long as drivel continues working for most people, I'm not sure how much time it deserves.

I've done a lot of refactoring in drivel already, for the GTK3 transition mainly, but this libsoup stuff is much more awkward because it raises new bugs with each blog engine that drivel tries to support. It's not helped when some blog engines retain broken XML practices that mean that the standard libsoup2.4 support simply fails to post a message with properties. (I'm looking at you livejournal.com).

Anyone fancy helping out with a branch where the old xmlrpc code can be replaced by soup_value_hash_insert? I've made an SVN branch for soup24 changes at SourceForge. There's a mailing list too (v.quiet).

I'm going to update a few screenshots, complete a few more tests and then release 3.0.1.