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.