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