Codehelp blog

OK, it's gone 2am and I'm still battling with what was meant to be a simple task - check the latest (unreleased) changes in tslib on my touchscreen device.

First problem was that I forgot that the balloon is running Lenny, so I suddenly needed the armel libc6 from Sid. OK, that's not bad, a bit of a pain to have to install it but less pain than creating a Lenny chroot to cross-build tslib - marginally.

Second problem was more awkward - turns out that emdebian-tools 1.6.1 has broken the more fragile cross-build support which carefully wraps broken libtool installations. I was intending to work out how to fix each one of those before Squeeze anyway. The fix for the workaround was relatively straightforward and will be in 1.6.2, due for release once I've had some sleep.

Third problem was something much older - turns out that this broken libtool wrapper had only been able to work for the default cross-building architecture since about emdebian-tools 1.4 or 1.5 and if asked to build for a different arch, it got the wrong symbols. Hmm.

The diffs for each of these changes appear simple but, as ever, identifying the cause of the bug was harder. (In this case, sometimes the error showed up as "C++ compiler unable to create executables" - thanks autotools, that's really handy to know; other times it showed up as ERROR, symbols from ./.libs/libfoo are ABI 4 but symbols from libc are ABI version 0 - still cryptic but at least it is entirely accurate.)

Still, I've now been able to test tslib 1.0-7 and it works just fine and I've got an extra upload of emdebian-tools 1.6.2 to make tomorrow. Ah well.

debootstrap has only ever been designed to work with a single repository and the current code includes a comment:

# XXX: I can't think how to deal well with dependency resolution and

#      lots of Packages files. -- aj 2005/06/12

The main reason for that, AFAICT, is that debootstrap has a perfectly valid goal of trying to work without needing dpkg or apt themselves, doing everything in the chroot. Theoretically, anything that can run POSIX shell should be able to run debootstrap.

Emdebian has a need for a different script that can assume that both dpkg and apt are fully functional already and behave as normal Debian packages which opens the door to supporting as many repositories as apt itself can handle and, until now, that support was --foreign only. i.e. it was explicitly for cross-debootstrap (armel, etc.) for use with Emdebian Grip and actually used debootstrap for some of the work. That code has been simplified and there is no need for debootstrap now in multistrap. (multistrap itself is written in perl.)

I recognise that native support could be useful so I've been working on a fix for the native support - partially achieved by dropping the need to use debootstrap at all and porting the existing fix for #518719 from the emdebian-rootfs package (shell) into perl.

In effect, multistrap allows you to collapse the following stages into one:

1. $ sudo debootstrap $suite $dir $mirror


2. $ sudo chroot $dir


3. # nano /etc/apt/sources.list


4. # apt-get update


5. # apt-get install $package_list


6. # apt-get clean


7. $ sudo $my_config_script

That much is architecture-neutral (due to the support for working around #518719 which allows packages to be unpacked without running the configure scripts) - what I've added for native support is that sudo chroot $dir dpkg --configure -a can be automatically run before the config_script. In the typical Emdebian case, the configure stage would happen immediately after unpacking the multistrap filesystem onto the device (certainly before first boot).

That gives you a single method for creating a complete root filesystem with everything you need installed, everything configured and the config_script hook allows you to put in things like kernels and kernel modules etc. too - all ready for tar -czf and unpacking onto your device. Instead of a plain debootstrap, multistrap can give you a complete filesystem with all the packages you'd only install as soon as debootstrap had finished.

In addition, multistrap allows apt to decide which versions to install from the collection of Packages files so you can implement fallbacks and other permutations of mirrors and packages. Emdebian is using this functionality to mix private packages with official packages from Emdebian Grip 1.0 and ensure that not only are all dependencies met but that each dependency has the chance to be the latest version without needing any configuration or manual parsing. Just specify the repositories and which packages you need at the top level from each one. apt does the rest.

So, the question:

Does this deserve to be a separate source package ? For now, it's heading into Emdebian as part of the emdebian-rootfs package, version 1.6.1.

The advantages will be that multistrap itself doesn't need to be tied to the still rapidly developing emdebian-tools source package and doesn't need to carry the quite large changelog from emdebian-tools (which is just going to keep on growing).

 3014 2009-03-17 20:54 ./usr/share/doc/multistrap/README

 2265 2009-02-18 18:32 ./usr/share/doc/multistrap/TODO

 1536 2008-08-20 14:25 ./usr/share/doc/multistrap/copyright

21067 2009-03-17 21:58 ./usr/share/doc/multistrap/changelog.gz

 1233 2008-10-28 13:13 ./usr/share/doc/multistrap/NEWS.Debian.gz

Disadvantages, it's very small (a lot of the current content is actually POD documentation) and probably doesn't warrant a source package all alone.

 17774 2009-03-22 13:41 ./usr/sbin/multistrap

Details:

 Package: multistrap

 Source: emdebian-tools

 Version: 1.6.1

 Architecture: all

 Maintainer: Neil Williams 

 Installed-Size: 120

 Depends: perl, apt, debhelper (>= 5), 

  libconfig-auto-perl, libparse-debian-packages-perl

 Replaces: emdebian-rootfs (<= 1.6.0)

 Section: admin

 Priority: extra

 Homepage: http://www.emdebian.org/

 Description: multiple repository bootstrap based on apt

  debootstrap replacement with multiple repository support

  using apt to handle all dependency issues and conflicts.

  .

  Includes support for foreign architecture multistraps that need

  only minimal configuration on the final device. Supports cleaning

  up the generated bootstrap filesystem to remove downloaded packages

  and hooks to modify the files in the bootstrap filesystem after

  the packages have been unpacked but before being configured.

Is there a better home? devscripts? Ideas? (It would need to be a package I can join as Uploader: and I'd prefer if that package used subversion.)

From the FFII:

EPO seeks to validate software patents without the European Parliament

Benjamin Henrion, President of the association, says: "The current plan of the patent lobby is very clear: avoid a new software patent directive, validate the EPO practice via a central patent court, and guide the hand of the courts via a decision of the Enlarged Board of Appeal. They want to avoid the intervention of the European Parliament in substantive patent law."

In other words, seeing as the elected representatives have blocked a change in the law, the unelected quango will simply seek a change in the rules to make it unnecessary to change the law and therefore avoid asking the elected representatives at all.

This is crazy, dangerous and downright sinister.

"Considering that the EPO is an institution acting as judge and party, where the attributions and procedures have to be revised. [...] Demand the revision of rules of function of the EPO in order to guarantee that this institution can publicly justify the accountability in the exercise of its functions [...]."

Judge, jury and executioner more like.

Interested parties have up to the last day of April to send their comments to the Enlarged Board of Appeal.

Information for third parties wishing to file written statements

Communication from the Enlarged Board of Appeal concerning case G 3/08

(my comments added in bold)

In accordance with Article 112(1)(b) EPC, the President of the European Patent Office has referred the following points of law concerning the limits of patentability of programs for computers within the meaning of Article 52(2)(c) and (3) EPC to the Enlarged Board of Appeal. The case is pending under ref. No. G 3/08.

The questions referred are:

1. Can a computer program only be excluded as a computer program as such if it is explicity claimed as a computer program?

No, any computer program is excluded no matter how it is claimed because a computer program is not patentable. The patent claim must contain material other than a computer program and the computer program itself cannot be claimed as part of any patent claim nor can any computer program ever be deemed to have infringed any patent claim even if that claim was previously based entirely in hardware.

2.(a) Can a claim in the area of computer programs avoid exclusion under Art. 52(2)(c) and (3) merely by explicity mentioning the use of a computer or a computer-readable data storage medium?

No patent claim can be made against any method expressed as a computer program. It is the software that matters, not the paraphernalia of computers. Therefore, whether a computer or computer-readable data storage media are mentioned, any software is automatically excluded from patentability. If the claim makes no sense without that software, then the claim is excluded.

(b) If question 2(a) is answered in the negative, is a further technical effect necessary to avoid exclusion, said effect going beyond those effects inherent in the use of a computer or data storage medium to respectively execute or store a computer program?

Any effect is excluded from patentability if that effect is or can be executed by software. If the effect becomes possible via software at some point in the future, the software cannot be deemed to have infringed the patent claim because software is not patentable.

3.(a) Must a claimed feature cause a technical effect on a physical entity in the real world in order to contribute to the technical character of the claim?

Effects on the "real world" are irrelevant - if the effect is or can be performed in software, the effect is excluded and any software implementing that effect cannot be deemed to have infringed the patent claim. The real world still includes the electrons that implement the effect of software but software is not patentable.

(b) If question 3(a) is answered in the positive, is it sufficient that the physical entity be an unspecified computer?

No, the effect is not the issue, the method is the issue.

(c) If question 3(a) is answered in the negative, can features contribute to the technical character of the claim if the only effects to which they contribute are independent of any particular hardware that may be used?

Portability infers software and software is not patentable. A claim must be excluded if it is wholly or partially implemented as software or can be wholly implemented as software and no software implementation can be deemed to have infringed the patent claim either in whole or in part now or in the future because software is not patentable.

4.(a) Does the activity of programming a computer necessarily involve technical considerations?

No. Programming is a form of speech, it uses languages and different languages have different requirements for technical expertise. Some languages require little or no technical expertise to generate an effect within a computer by means of software.

(b) If question 4(a) is answered in the positive, do all features resulting from programming thus contribute to the technical character of a claim?

No software programming can have any technical character for patentability because software is not patentable.

(c) If question 4(a) is answered in the negative, can features resulting from programming contribute to the technical character of a claim only when they contribute to a further technical effect when the program is executed?

No, if the features result from programming then the software to effect those features is not patentable and the feature itself is not patentable. No effect of a computer program can be wholly or partially patentable.

The text of the referral in the English language is available under Referrals pending before the Enlarged Board of Appeal.

The Enlarged Board of Appeal considering the referral will be composed as follows:

* P. Messerli (CH) (Chairman)
* M. Vogel (DE)
* D. Rees (GB)
* M. Dorn (DK)
* K. Härmand (EE)
* A. Klein (FR)
* J.-P. Seitz (FR)

It is expected that third parties will wish to use the opportunity to file written statements in accordance with Article 10 of the Rules of Procedure of the Enlarged Board of Appeal (OJ EPO 2007, 303 ff). To ensure that any such statements can be given due consideration they should be filed together with any new cited documents by the end of April 2009 at the Registry of the Enlarged Board of Appeal, quoting case number G 3/08. An additional filing of the statement and documents in electronic form would be appreciated (Dg3registry_eba@epo.org ).

---

Feel free to add your own answers to the questions as comments.

Not sure how many people check the list of packages requested - 452 packages at the time of writing.

One thing occurs to me when viewing the list, the standard DDPO page format doesn't lend itself to this kind of data. There is no PTS page, nothing available in pool, no bugs, no versions or builds (inevitably) and no popcon, watch or section. What might be more useful here would be not just a link to the RFP bug report, but the title of that bug report so that a quick scan of the RFP page could shed more light on the packages than the bare upstream package name.

Maybe even create RSS feeds for new ITP, RFP, O and ITA bugs?

(Particularly useful is the support for listing only specific source packages - I think I might link to some pages from Emdebian using that syntax.) e.g. this list of core packages for Emdebian support.

Also idly wondering if there could be some way of adding Emdebian data to this kind of output - maybe a line beneath the current suite listing with the em[0-9] details. Not sure what data sources are used for the DDPO package data but if it is Packages.gz files etc., those are available. If this seems like a good idea or knows how it could be done, please post a comment.

A bit of an unusual situation with drivel - I'm taking over maintenance from Neil McGovern and I've updated various parts of the package during that process. However, to avoid swamping Neil in wishlist [l10n] bugs during the time taken for the BTS etc. to switch over, I'm not sending a call for updated translations at this time, even though most of the current translations are out of date.

drivel is also quiet upstream and although there is an unreleased version in SVN that I will probably package once 2.0.3-4 is in Squeeze, I've checked the upstream po/ and none of the existing translations have been changed in SVN, beyond predictable changes in the line numbers where strings appear. There are a small number of new translations but most of these are also out of date:

$ msgfmt -c --statistics po-svn/ar.po
43 translated messages, 219 fuzzy translations, 43 untranslated messages.
neil@holly:test$ msgfmt -c --statistics po-svn/dz.po
305 translated messages.
neil@holly:test$ msgfmt -c --statistics po-svn/oc.po
91 translated messages, 214 untranslated messages.
neil@holly:test$ msgfmt -c --statistics po-svn/th.po
212 translated messages, 93 untranslated messages.
neil@holly:test$ msgfmt -c --statistics po-svn/zh_HK.po
297 translated messages, 4 untranslated messages.

Bizarrely, one has even been removed:

$ msgfmt -c --statistics po-current/no.po
149 translated messages, 29 fuzzy translations, 96 untranslated messages.

I'm pondering whether to join / take over upstream for drivel, at which point it becomes trivial to make a useful call for translations, get all the PO files updated both in the current package and in SVN and then make a fully updated release.

drivel already includes bg.po ca.po cs.po de.po el.po en_CA.po en_GB.po es.po fi.po fr.po ja.po lt.po nb.po ne.po nl.po no.po pa.po pl.po pt.po pt_BR.po ru.po rw.po sq.po sr.po sr@Latn.po sv.po vi.po zh_CN.po zh_TW.po and all of those are out of date.

So don't file i18n bugs against drivel just yet, wait for the call. Thanks.