(There's also a minor update to apt-cross, 0.4.1) emdebian-tools 0.5.4 is an incremental release for Emdebian but the changes are (or should be) useful. In testing an Emdebian implementation of tdebs, I've tweaked the tools so that it should now be a lot easier to build arbitrary packages with emdebuild outside of emsource. e.g. I'm updating 'langupdate' which will be an Emdebian-native package that handles these tdebs via a new repo on buildd.emdebian.org: http://www.emdebian.org/locale/ The main drive is to separate the numerous extra packages created by emlocale into a separate repository so that the main apt-cache and dpkg information can be kept within a sane size. Translations will disappear from the Emdebian target repository in due course. To get a working implementation without multiple patches, I'm not using the .tdeb suffix - using the normal .deb instead. Translation packages built with emlocale >= 0.5.4 will have a XC-Package-Type: tdeb control stanza. Installing and updating translations on an Emdebian device, once langupdate is ready, will simply require running 'sudo langupdate'. This will update the separate (temporary) cache of translation data, check for the list of supported locales on that device, prepare a list of translations for those locales and then compare that list with the dpkg list of installed packages. If any new or updated translation packages are found, they can be installed. As langupdate is not in Debian (and possibly does not need to be in Debian until tdebs are more widely supported), it became necessary to ensure that the tools can be used in this situation: cd path/to/SVN/ make dist # cp tarball to build path, unpack etc.... cd langupdate-0.0.2/ debuild emdebuild This gives you two .changes files, two .dsc files and correctly splits out the translation(s) of langupdate itself (nicely recursive) into suitable packages when using emdebuild, via emlocale. This works because ../langupdate.old/ does not exist and any scripting around such methods should remove ../$package.old/ prior to unpacking any new tarball. (emsource would normally handle that for you.) Apart from that, it should be simple to now build any package for Emdebian, whether or not it exists in Debian. http://buildd.emdebian.org/svn/browser/current/host/trunk/langupdate/trunk/ (langupdate is a small GPL3 C/C++ package depending on libapt-pkg) There's a bit more to do on langupdate before it's ready but the repository is working fine. It may look a little strange at first - and note that there is *no* source directory at this time - but that is because the repo is very granular. Each locale root has a component of it's own, so en_GB and en_US share a component, pt and pt_BR share a component etc. Components are normally kept for main, contrib and non-free but having over 80 components didn't seem to be a problem for reprepro. ;-) That's why the details of using that repo are to be "hidden" / wrapped within langupdate so that people don't have to be worried about source lines like: deb http://buildd.emdebian.org/locale/ unstable $lang where $lang is a variable. :-) If you're wondering what all this actually means, see: http://lists.debian.org/debian-devel/2007/11/msg00117.html http://wiki.debian.org/i18n/TranslationDebs http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/58-Emdebian-Tdeb-plans.html Overall, the locale repo should cut the size of /usr/share/locale/ to zero on some devices and by a factor of 30 on most devices. Even when a user needs two or three locales, we still get a massive 90% reduction in the amount of space taken up by the .mo files. Even the largest translation (fr) takes up only 9Mb for a full Gnome install whereas by default Debian takes up over 250Mb by insisting on having all locales. Issues remaining include: 1. Debian Tdebs are intended to include translated manpages, images and other cruft that Emdebian simply doesn't want. 2. Need a way of creating a "source" package (so that the repo stays legal) that contains the original .pot file and the current .po file from which the .mo is generated as well as a build method for single translations. 3. No method for supporting non-gettext translations. I'm not sure how much of a problem this would really be. gettext is far and away the single most common method of translation in free software. 4. With the source package, there is a need for upload handlers so that translators can revise the .mo and upload a new translation - independently of the upstream package. This raises a dependent issue of how to get such changes back into the upstream package - bearing in mind that most translations originate outside Debian. Using the BTS might not be an option because that tends to lead to yet another package upload to Debian to close the bug when the .mo file itself would not be part of the Debian package anymore. Equally, upstream translations need to be made into tdebs. 5. If translations are updated in Debian separately from packages, Emdebian will need an autobuilder that can repackage the updates and strip out what we don't need. Overall, what we have is enough infrastructure to create a working implementation of tdebs in advance of Debian, to prove that the system can work. Then, much like the rest of Emdebian work, we can show Debian how the system can be expanded to cope with wider requirements whilst retaining what we need within Emdebian. I think we only need to solve Issue 2 above (possibly by extending emlocale) and complete the development of langupdate to have a usable system for Emdebian. Any takers? -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpM8dbHmXfvx.pgp
Description: PGP signature