On 07/11/06 12:42:40, Neil Williams wrote: On 07/11/06 11:35:52, Wookey wrote:
Let me redo that. When converting a Debian package to an Emdebian package - i.e. when creating the emdebian diff.gz - we need to call emlocale and dump the doc build code. At each Debian upstream release, emlocale would be run again (to catch new translations) and there'd need to be a check that no new docs have been added or new doc build rules added. Once that is done, 'apt-cross --install gpe-contacts' will be a usable command. That opens the door to using the toolchain created (and maintained) via emchain in a chrootWhy do you want to install a cross-toolchain into a chroot to build things? I had always envisioned doing it in your normal rootfs (unless building for a different target suite to the host).> That's certainly how dpkg-cross does it.Oh, you mean the hierarchy it fills under /usr/arm-linux-gnu ? That's not what I think of as a chroot. It's just a place in the normal root to put libs, includes etc which represent the target build environment. Obviously it is correct for a cross-build compiler to reference those.
No, I meant that packages installed with dpkg-cross show up in the normal apt-cache on the host machine.
I'd prefer to be able to build without them installed on the host.
Clearly building with pbuild or sbuild is a good idea for the same reasons that it is with debian packages. It should be the way the buildds operate, but I don't want to make it a necessity.
That's OK. We can have a emdebuild as well as an empdebuild script - the first doesn't use a chroot, the second does. Just like debuild and pdebuild.
The other problem is that packages installed by dpkg-cross onto the host system would need to be removed at the end of the build because they hold back the equivalent host package when doing apt-get upgrade.Hmm - you mean they have en explicit dependency on that 'conventional' package? I've never noticed dpkg-cross packages getting in my way like this, so I don;t actually think you are right. I think they only depend on other -cross packages, and thus are entirely independent. In which case this isn't an issue.
I installed the packages from the emdebian repository for amd64 and a subsequent apt-get upgrade insisted that they all be removed when gcc4.1 was updated.
I've now got my own 'emchain' packages installed using dpkg-cross and I also get an explicit depends:
Package: gcc-4.1-arm-linux-gnu Status: install ok installed Priority: extra Section: devel Installed-Size: 596 Maintainer: Debian GCC Maintainers <email@example.com> Architecture: amd64 Source: gcc-4.1 (4.1.1ds2-19) Version: 4.1.1-19 Provides: c-compiler-arm-linux-gnu, libssp0-devDepends: gcc-4.1-base (= 4.1.1-19), cpp-4.1-arm-linux-gnu (= 4.1.1-19), binutils-arm-linux-gnu (>= 2.16.1cvs20051214), libgcc1-arm-cross (>= 1:4.1.1-19), libssp0, libc6 (>= 2.3.5-1)
So when gcc-4.1 (4.1.1-20) is uploaded, apt-get upgrade will hold back gcc-4.1 until I remove gcc-4.1-arm-linux-gnu. The same thing happens with cpp* and g++*.
What do you get for: apt-cache show gcc-4.1-arm-linux-gnu | grep Depends ? Is this a bug in dpkg-cross ? Are you expecting: (>= instead of =)Depends: gcc-4.1-base (>= 4.1.1-19), cpp-4.1-arm-linux-gnu (>= 4.1.1-19), binutils-arm-linux-gnu (>= 2.16.1cvs20051214), libgcc1-arm-cross (>= 1:4.1.1-19), libssp0, libc6 (>= 2.3.5-1)
or just: Depends: libssp0 $ dpkg -l dpkg-cross ii dpkg-cross 1.32 Is it a lack of gcc-4.1-base-arm-linux-gnu ? (That's not built currently - not sure why.) neil@holly:gcc-4.1-4.1.1ds2$ grep Package debian/control Package: libgcc1-arm-cross Package: libgcc2-arm-cross Package: lib64gcc1-arm-cross Package: gcc-4.1-arm-linux-gnu Package: cpp-4.1-arm-linux-gnu Package: g++-4.1-arm-linux-gnu Package: libstdc++6-arm-cross Package: lib64stdc++6-arm-cross Package: libstdc++6-4.1-dev-arm-cross Package: libstdc++6-4.1-pic-arm-cross Package: libstdc++6-4.1-dbg-arm-cross Package: lib32stdc++6-4.1-dbg-arm-cross Package: lib64stdc++6-4.1-dbg-arm-cross The command I'm using is: `export GCC_TARGET=$arch`; `debian/rules control`; `dpkg-buildpackage -b -rfakeroot`; gcc-4.1-base isn't an _all.deb so I can't see why it isn't built. Hmm.
The alternative is a hook in cron-apt that does what emchain will do for gcc, binutils and libc: removes them if new packages are available for the host, installs and configures the host packages, rebuilds the cross built packages and installs them on the host.I think you are getting a bit carried away there.
A virtual locale package would be needed for each language so that all translations for that language can be installed as a set. The individual locale packages contain only the foo.mo file. On this Debian system, /usr/share/locale/ takes up 288Mb. /usr/share/locale/en_GB/ takes up 4.6Mb, .../de/ and .../fr/ take up closer to 9Mb each. That's *all* available translations for a full Gnome environment in under 10Mb, not almost 300.
Agreed. The advantages on the target are enormous. I'd like debian to have something like this too. Maybe we should try and push this idea upstream...
(once it's working) :-)
The user can still specify more than one locale so that the locale can be changed at login time. It's just that *only* the translation files for specific locales get installed on the target. Equally, converting a device installed with en_GB as the only locale into a device capable of supporting de or pt_BR just means installing that one set of language files (and optionally removing the originals).
No argument with any of this but if you add pt_BR later does that mean you get pt_BR files for packages installed _from now on_ or does it go back and get the laguage files for all the packages that are currently installed too? The second is nicer but I don't think a virtual locale package gets us that for free - we'd need some scriptage somewhere. I don't think it's too hard. Something to think about.
I've thought about a virtual package that tracks the translation packages but there are problems. Yes, it would "backfill" with all the language files *and* keep that list up to date as new translations are made available but I'm not clear on how it would do it *only* for the packages installed. Can a virtual package have an indeterminate number of possible dependencies?
A virtual package could be an all-or-nothing affair, meaning it may have to be further split into a virtual for GPE, a virtual for Gnome -Yuk!
Yes, there needs to be some scripting/processing here - and on the target device too. It could be quite simple though - another run through apt-cache by a simple package that holds lists of all available translations (rather than depending on them). Update that package to receive new translations. Run a script in that package to find missing translations in what is already installed, optionally installing them direct.
That's one up on OE/GPE because they don't support this! :-)It would work nicely as a C application using libglib2.0 and SQLite. Could even have a Gtk frontend as well as a command line.
Two tables: one updated by the package containing the list of all available translations. A second table updated from the list of installed packages that identifies packages without translations.
Alternatively, what is the status of Perl on the target device? Are we doing without it?
What's your preference? An automated tool that works invisibly whenever the user runs apt-get update && apt-get upgrade, or, an interactive tool that the user can use to query the translation database?
Each bitbake recipe (their build/packaging instruction set) contains a LICENCE field and a MAINTAINER field, but no copyright data that I can see.Yes. This does seem to be standard proceedure. We'll do that for now but don't tell debian-legal just yet :-) Keeping the copyright info with the source seems fair enough to me.
Agreed. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Description: PGP signature