On Fri, 11 May 2007 20:36:06 +1000 Brendan Simon <Brendan@BrendanSimon.com> wrote: > > I'd have thought GTK was pretty widely needed - most systems with > > a GUI (except the _really_ embedded ones that might use > > somethinglighter wieght). > > Network equipment is generally controlled and managed by a network > management workstation that has a GUI as a standalone app and talk to > the device via some other protocol (eg. SNMP). Another alternatives > is http/s. The GUI is not on the device. If the same method would work with more recent/powerful machines running Debian then there is no real reason why Emdebian cannot do the same with. Emdebian is Debian - only smaller. Naturally, there are some applications in Debian that make no sense in an embedded device like an iPAQ (e.g. pilot-link) but if there are other situations where they could be useful, Emdebian does not restrict you. If the package exists in Debian and can be cross-built, you can emdebianise it. > > It most definately is targetted to meet your needs, so if it doesn't > > something is wrong. (Bug reports to emdebian-tools in the Debian BTS please). > > All you should have to do is install emdebian-tools, emsource each > > package you want then make it cross-build (and check the results > > back in to emdebian svn - I can sort you out access). This last > > step varies from trivial to epic depending on package. Most are > > fairly painless. I'm quietly building a little collection of helpful snippets and common failures - I've put some in the Emdebian Developer Guide [0] which is linked off the Quick Start guide [1] because it is specific to emdebian-tools. I've only included the ones that apply fairly evenly to a number of packages. Check the Emdebian SVN and then contact me if you get stuck with a particular package. I'm going to look at using branches in Emdebian SVN to hold incomplete or failed build logs so that trunk/ only ever contains successful builds. > > Ideally the changes you need to make can be filed as upstream > > cross-compile bugs rather than kept as emdebian patches. I'm keeping that to one side for now - I want to get some kind of overview of the kinds of changes that are likely to crop up again and again as there is the potential here to end up with lots of very similar bug reports. Also, emdebian-tools needs a fix (hopefully this week) because some changes are only making it into the .diff.gz and not into explicit patches, e.g. changes to debian/foo.install or debian/bar.dirs files. This is part of the auto-build pbuilder, empdebuild, which will attempt to update Emdebian packages from updated Debian sources and therefore needs all the changes in SVN rather than in the repository. I'll be releasing emdebian-tools 0.2.1 later today that fixes a couple of minor bugs and then I'll be looking at empdebuild again. > > If you want it stable for Q4 then you will need to put some work in, > > exactly how much depends on how many packages you need, and how many > > others get involved. You may also be held up by existing blockers: gcc-4.1 and libx11-6. gcc-4.1 needs attention from experienced Debian developers to see if it can be built for Emdebian. libx11-6 needs empdebuild or a similar chroot build or a fix to apt-cross that can get passed the circular dependency problem in debconf. Note that perl does not currently cross-build in Emdebian either, so no packages dependent on perl can be cross-built. I'm not particularly bothered by that right now because I'm trying to remove perl from the rootfs completely but it will need to be fixed. It's ironic - I'm using emdebian-tools and apt-cross, both written in Perl, to remove Perl from the resulting system. Also, don't underestimate the amount of work required to get a successful cross-build - you need to know CDBS, debhelper and dpkg quite well and you also need to understand make and Makefiles. Remember to check ALL packages for manpages and other documentation that can creep in via all kinds of routes. deb-gview is useful here as debc has problems with cross-builds (it can't find the .deb from the .changes - possibly because it is assuming the host arch - I need to see if there's a bug report for that). > The other thing I would like is to use packages from a stable distro > (Etch). I thought I read somewhere that everything is happening with > Lenny/Sid packages. Is that correct? Everything is to be synced with Sid. Just like Debian, Emdebian only adds new packages to unstable (we could have experimental later too) unless there is an explicit reason to update testing (Lenny) or stable (Etch). All changes to testing or stable must be handled manually. Currently, all uploads to Emdebian only go into Emdebian unstable so packages built on Debian stable must not be uploaded. If an Emdebian package receives a security fix in Etch, we may have to incorporate the patch and rebuild but we aren't at that stage yet. The plan (once we have fixed the missing packages in the current list) is to migrate packages to Emdebian testing alongside Debian, just as we do for toolchains. When Lenny is released, we would then migrate our Emdebian packages into Emdebian stable. So, in effect, Emdebian isn't likely to support Etch directly at all - the first stable release that can really be expected to work with Emdebian will be Lenny. Which raises an interesting point: Is Emdebian testing an emLenny? ;-) > Can Etch packages be used? emdebian-tools was not released as part of Etch and is completely untested with Etch packages. There is no emdebian-tools package for Etch currently. The problems with using Etch packages are: 1. the toolchain will not be updated, 2. the build tools will not be updated and 3. improvements and patches that may get included in current Debian packages as a result of Emdebian bug reports are not going to be reflected in Etch. (Packages that do not cross-build now will be harder to fix in Etch.) 4. The biggest problem, however, is that Debian requires that packages for Debian unstable are BUILT on unstable and Emdebian needs the same kind of rule, otherwise the dependencies can become unmanageable. As we don't have a stable-proposed-updates or delayed-testing queue for incoming packages yet, we need to stipulate that new uploads are built on unstable. If the packages are not to be uploaded to Emdebian then this problem simply means you are likely to have to rebuild Etch packages that have already been emdebianised at a later version for Sid. Once a library transition has occurred in unstable, packages that depend on that library CANNOT be built on Etch and uploaded to Debian unstable - the same is also true for Emdebian. As Etch has only just been released, there are NUMEROUS library transitions occuring in Debian unstable right now which were held back by the Etch freeze, including libglib2.0-0 and libgtk+2.0-0 as well as glibc and gcc-4.1. Once those transitions stabilise and the new versions migrate into testing, it will be impossible to build on Debian Etch for Debian unstable and I believe the same will have to be true for Emdebian for the same reasons. So you can probably build packages on Etch (by building your own emdebian-tools and apt-cross packages from Emdebian SVN) but you should not expect to upload those packages to Emdebian because they will be going into Emdebian unstable, not stable and you will have to redo much of my existing work on older versions of the same packages. In short, I do not recommend using Etch for Emdebian. (Does the phrase "rod for your own back" seem appropriate?) [0] http://wiki.debian.org/EmdebianGuide [1] http://wiki.debian.org/EmdebianQuickStart -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpy8s1ZfA6JZ.pgp
Description: PGP signature