On Wed, 2008-10-29 at 09:31 +1100, Brendan Simon wrote: > Neil Williams wrote: > > On Tue, 2008-10-28 at 23:26 +0800, GNUbie wrote: > > > > OK, that might be a little bit tight for a GUI based on Lenny, even with > > XFCE. However, I read below that you don't need a GUI so 512Mb is plenty > > of space. I'm still not sure what you want the device to do though > > because amd64 is a powerful architecture and I can't imagine that you'd > > get it to run without a fan or have much of a battery life if the device > > is meant to be portable, which makes it hard to see the appeal of solid > > state storage. > Embedded != Low Power True. Embedded != slow CPU too - in fact, I'm not sure that any flavour of Emdebian will be suitable for really old or really slow CPU machines - the underlying code is Debian after all. Functionality changes are one thing but reducing the level of complexity of the code can only be done to a point - choosing apps like GPE reduces the "frontend" complexity of the code but you've still got to get the underlying libraries running. I have to start somewhere so I'm starting with PDA-type devices. > It is true that a lot of embedded devices have limited storage, > computing power and need to be low power, but not all. Hence my questions about what kind of device was involved as the description didn't fit "the usual suspects" and we have to target Emdebian at something, then customise from that. > I do agree that Emdebian should cater for low power, low capacity, low > speed devices, however it should also cater for higher end embedded > devices too. Always been part of the plan. If anyone fancies stepping up to do some of the development for Emdebian Grip, please say so. I'm happy developing for Emdebian Crush and using Grip as a basis for Crush so if people really want to develop Grip in and of itself, you'll need to help me out here with your own time and effort. There's only so much I can do and I'm pretty much at maximum with the current development workflow. emgrip can develop separately from the rest of emdebian-tools because it cannot use Emdebian::Tools or other cross-building modules that are being developed for Crush. If someone can take it on and start working with Grip - building repositories, processing more packages, improving in-build behaviour, implementing the DEB_BUILD_OPTION support that is just an idea at this stage, adding a debhelper wrapper, adding CDBS and CMake support, adding support for .changes files, download support via an apt wrapper (maybe libcache-apt-perl), automation, porting to edos-debcheck support using code from emdebcheck and options to apt (not apt-cross), porting Grip to Debian Installer - then Grip will arrive sooner. I envisage the code migrating to a different source package (I thought maybe dpkg but only once Lenny is released) so feel free to work on the code separately (rename the scripts to suit too) and let me know. I want Grip to be a release-goal for Squeeze. I want someone to join the work and let me get on with Crush, TDebs, cross-build support in Debian, NMU's etc. You'll have all the support you need, just do some of the work. :-) > From memory, Emdebian Grip would be a good candidate for this, right ??? Yes, when it actually arrives. :-) Have a go with /usr/share/emdebian-tools/emgrip from emdebian-grip (in the Emdebian repository) and file bugs about missing features, packages that break or packages that still contain docs etc. Better still, take on development of Grip and fix the bugs. You don't need the rest of emdebian-tools to use Grip, just the TDeb support which is common to both. The internal version of emgrip is 0.0.1 - the package got the 1.4.11 moniker because it is currently built from emdebian-tools sources. If you want to, you could change emgrip from perl to something else but I would not be able to help you if you choose python and I'm not sure that anything except perl or shell would be acceptable to the rest of Debian for a debhelper/dpkg-dev build tool for use in all packages. > I have developed for PowerPC architecture, using Apple PowerPC PowerMacs > as the development hosts, however now that Apple have gone Intel, it > makes it harder to find powerful PowerPC platforms to build powerpc > binaries. > > Ideally I would prefer to use powerful commodity PCs, and cross-compile > everything I need to customize. Grip doesn't need to be cross-compiled, it should support native building ON an Emdebian Grip machine. Yes, it probably will be slow but cross-building is still not implemented in more than 1% of Debian packages. Grip needs to have almost a full package set - I'd guess at 10,000 or maybe 15,000 packages of the 20,000 in Debian. Crush currently has 248. > Ideally I could use all the pre-built powerpc debs from Lenny, and just > cross-compile new packages that I need to modify or create. No, you just "grip" prebuilt debs from Lenny. Depending on how Grip develops, there is nothing stopping Grip from actually working with Etch packages or even Sarge. > Ideally, IMHO, Emdebian should be able to totally cross-compile a > powerpc <or insert favorite arch> distribution from scratch, and produce > exactly the same outputs (.debs) as a build on the native powerpc > <insert arch> host. > > Is that a goal of Debian Grip ??? Cross-building is not part of Grip. Cross-building is initially related only to Emdebian Crush using functionality changes for dependency reduction. Cross-building may be a bonus from work on Crush but Grip is essentially about repackaging prebuilt native binaries. Packages can be "gripped" during the build, prior to inclusion into a Grip repository or after downloading onto the device running Grip (if sufficient space exists). Packages can be gripped on any architecture, for any architecture. It doesn't matter if you want to Grip powerpc packages on amd64, just as long as the full sized powerpc binaries exist - in most cases, exist in a Debian mirror somewhere. emgrip is based on dpkg-cross without the -cross stuff so it can work anywhere (hence the limited dependencies) and churn out any package for any architecture whilst working on any architecture. There is no compilation involved. Emdebian Grip aims to provide a natively-built Debian Installation for any architecture supported by Debian in a way that is functionally identical to Debian, just smaller and using TDebs in the Emdebian manner for extra granularity. However, if Grip does get to 10,000 packages, using Emdebian TDebs would turn that into more like 150,000 which may well be a decision that has to be faced at some point. Grip should support native building on the Grip device and if you base it on Lenny and more so Squeeze, it will support cross-building on the Grip device or using Grip as a target of cross-building on a different box running Debian Squeeze. In such cases, you wouldn't use emdebian-tools to cross build, you'd use 'dpkg-buildpackage -a' so that the Crush functionality changes do not get applied but that depends on the cross-building support being developed for Crush and implemented in the Debian package. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part