There's an outline of a pbuilder create wrapper in SVN (tools/em_make/empdebuild) - once a few more packages are built, we should have a usable chroot environment using the emdebian target repository. My questions are: If I make the basetgz use arch=arm, the chroot will not be cross-building anymore. This native chroot would only use the emdebian target repository. The native chroot can check the integrity of the archive (a la piuparts) by trying to install binaries from the emdebian target repository but is this native chroot useful for anything else? Is there any point making the native chroot able to rebuild cross-built packages? (It could make the emdebian target repository quite messy). Is it possible to run GUI (or any) programs from within such a chroot? Alternatively, drop arch= (and --foreign) from the debootstrap options and use two mirrors: the emdebian toolchain and the emdebian target repositories. I'd use this for building GUI packages because it means I don't have to install dozens of dependencies via dpkg-cross on my main system, instead the chroot runs dpkg-cross (via apt-cross) and then emdebian-tools. This is more complex because it means adding a normal Debian mirror to the chroot sources.list so that the correct build dependencies are available (like dpkg-cross, debhelper, perl and emdebian-tools). That makes it harder to spot missing packages. Essentially, this would be a normal pbuilder environment with emdebian packages taking priority. Do we want to support both? I'm beginning to think we should. I could enable support that packages are built in the cross chroot, and then tested in the native chroot prior to upload. That would mean that any missing packages arising from the cross chroot method will be caught at that stage. If packages are uploaded without being tested in the native chroot or if they fail to install in the native chroot at a later date, we could use a release-critical FTIN {fails to install native} bug once we have an operational BTS. What do we need for a buildd? native or cross? One idea for the cross-chroot is that dpkg-cross packages could be held in a third repository at emdebian.org or added to the toolchain repository. That would preclude the need for a Debian mirror and make it easy to spot missing packages. The problem there is that dpkg-cross doesn't make it simple to generate a .changes file so the dput upload needs to be adjusted. Also, has anyone tried 'dpkg-cross -A' on perl? If the native chroot works out, that may be the best method. Much like Debian, it means that building a package can involve two builds: one on the host system (debuild) and one in a chroot (pdebuild). Emdebian could use emdebuild for "base" packages and empdebuild --cross where there are lots of dependencies, followed by empdebuild --native which would be a similar function to pdebuild - checking all necessary dependencies are available. In our case, empdebuild --native checks *runtime* dependencies rather than build-depends. (Or should empdebuild always be --cross and a new script, emparts or eminstall for testing the runtime dependencies?) Remaining packages include util-linux, busybox and apt. I'll use the SVN versions to view the changes necessary but the current upstream sources, along with emdebian-tools, to actually create the new packages. There are a few issues with the emdebian website package search scripts at the moment, some packages are not showing up. xorg / x11-common are there, amongst others. Hopefully that won't take too long to fix. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpps3qGjnfXN.pgp
Description: PGP signature