On Fri, Nov 5, 2010 at 4:35 PM, Hector Oron <[email protected]> wrote: > Hello, > > I am proud to announce a Debian Sprint[1] supported by Debian, Genesi USA > and Toby Churchill.
yay! > = Agenda = > * armhf status and Debian integration into dpkg and lintian > * multiarch support into dpkg > * Handling 'flavours' (ISA and optimisation options) (e.g. ARM > v5/v6/v7/VFP/Neon, x86 i586/i686/MMX) within Debian (dpkg support, package > metadata, partial archives, multilib gcc/install paths, multilib- or > flavoured- cross-tools) i haven't looked around, but has anyone suggested adding a base64-encoded extension to the .deb name, containing a bit-field of "capabilities"? the problem with splatting the capabilities into the .deb itself is that you then end up with dozens of combinations of capabilities, all with the exact same .deb filename. by encoding the capabilities in the actual filename, you can still pick a particular package by its version number etc. etc. _but_ you can identify whether it will work on a particular CPU by decoding its capabilities bits. 0x1 -> v5, 0x2 -> v6 .... 0x10 -> NEON and for x86, because, duh, you _so_ aren't going to get x86 instructions on ARM CPUs :) 0x1 -> i586 0x2 -> i686 0x4->MMX 0x8-> MMX2 there's a low-cost embedded x86 processor by RDC which ... hum... it can't run qt4 apps because the f*****g qt4 low-level image blit library assumes MMX instructions by default. and... 486 .debs were dropped several years ago, weren't they? so you get 386 .debs and they don't f****g work. > * Cross compilation environment (cross toolchains and target packages) - > bare metal support the level of expertise / machine-specific information is so vast that i strongly advise against "beginning from scratch". whilst wookey (or neil?) pointed out a few months back that it took several months - almost a year - to do the armel port, most of which was done by hand, and someone else pointed out recently that they managed in a couple of weeks to recompile automatically several hundred packages for Cortex A8, gaining a 40% performance jump by doing so, this is still an insanely ridiculous situation... when you compare it to openembedded. i believe that a sensible and sane approach to the dog's dinner mess of doing cross-compiling for dozens of targets and hundreds of machines would be to part-replace the capabilities of buildd with the capabilities of bitbake. in other words, write a bitbake recipe for openembedded that understood about debian/rules, dpkg-buildpackage and the debian cross buildpackage tools (note: openembedded already understands .deb packaging). now, that ain't gonna cut it for the _entire_ suite of debian packages: some of them simply aren't going to cross-compile as-is. two things help solve that: 1) openembedded has the ability to use qemu to configure packages! yes, you actually end up running _really_ native (only not really) via command-line qemu. 2) there is precedent for "OS-specific" debian/rules #includes (from the painful ubuntu) if you're absolutely desperate but i imagine that qemu pretty much solves it except in extreme rare cases (for example, that package mentioned last week which requires 1gb RAM to compile: current stable versions of qemu only do up to 256mb RAM, damnit) as far as cross toolchains are concerned: openembedded has it all, done already. why the f*** would you want to "start from scratch" when openembedded has everything that's needed?? question: why not recommend portage / gentoo instead of openembedded? answer: because openembedded has over one hundred ARM platforms supported already, with ARM CPU variants dating back over 10 years, and gentoo um... well... i don't have to look it up to know that it's not going to have anything _like_ the level of support for ARM CPUs. l. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
