There seems to be a lot of work, and it's a very steep learning curve. One has to be very Debian savvy before the extra knowledge and time required to be an emDebian developer/maintainer.
I there anyway to partition this so that a smaller knowledge/experience base is required to contribute ?? I notice uClibc is a candidate, but I remember a post about embedded glibc which was/is a smaller lighter libc based on glibc sources. Would this be a better candidate than uClibc ?? Should glibc, embedded-glibc and uclibc all be "supported" ?? Cheers, Brendan. Prince Riley wrote: > I'm going to ask the members of this list who haven't as yet spoken up > about the items on Neil's post to please do so by Friday. Once we > have those idea, suggestions, and recommendations we can put those > ideas into a draft summary. > > > On Wed, Aug 5, 2009 at 3:53 PM, Neil Williams <[email protected] > <mailto:[email protected]>> wrote: > > On Wed, 5 Aug 2009 14:52:22 +0000 > Prince Riley <[email protected] > <mailto:[email protected]>> wrote: > > > Neil, > > > > We are all very glad and appreciative of the great work you've done > > so far. We all understand and respect your decision and wish you the > > best as you try to recover your health. > > > > My question, and one I'm sure has also occurred to others interested > > in this project, is how do we move ahead during your absence. > Perhaps > > you can offer some advice or recommendations on how members of this > > list can help you transition your efforts so we can maintain the > > project's momentum and achieve its goals. > > It isn't about helping me transition anything, someone else needs to > take over maintenance and development. This is the "bus" scenario - > whereby a project has had only a single active developer and once that > developer is lost, it's about going back to first principles and > picking up the threads. I can help in small areas but my time is too > limited to go through the details, just the overview. > > Seeing as you asked, maybe this little list will give you some idea of > why I had to abandon this particular task - I'm not convinced that the > problems can be fixed before Squeeze, even if someone else takes > on the > role. Several stages rely on other tasks within Debian that may or may > not make it into Squeeze. The list is by no means complete either! > Even > before my illness, I had *serious* doubts about whether Crush 2.0 was > possible. > > 0. You'll find plenty of hacks, errors and mistakes that have remained > in the current scritps from the earlier development phases. It is > worth > revisiting things like that and seeing what breaks without them. > Ensure > you test with more than a few packages - there are various gotchas > that > only apply to a handful of packages and some of those packages have > since had new upstream releases that may well have fixed the issues > that led to the hacks in the emdebian-tools scripts. Other > improvements > elsewhere could also lead to some procedures within the current > scripts > becoming redundant or new ones needing to be devised. > > 1. Read the EmdebianCodeAudit wiki page and supporting pages, go > through and cross-build each package to work out what each audit point > means. Results are for armel, using emsource and emdebuild. Replicate > results using chroots builds (with empdebuild) wherever possible. > Various other parts of the wiki also need to be cleaned up, as > does the > website itself which still has a fair bit of outdated information. > > 2. Continue discussion on how xcontrol support can actually be > implemented. Check how it is used in the CodeAudit and tie that into > the developments at DebConf9. > > 3. Learn the emdebian-tools scripts and manpages, read the source code > and get a handle on how things currently work - taking over > maintenance of a native package means taking over the source code too, > in effect the "upstream". > > 4. Struggle with the inherent weaknesses in apt-cross which lie in the > horrible apt perl bindings - the most recent version of apt has (once > again) broken these bindings and apt-cross needs a patch to continue > operating. (Something to do with /etc/apt/preferences.d/). Hope that > someone gets apt to understand multiarch so that this whole issue can > be removed - you need a C++ expert for that role. > > 5. Get the toolchains back into installable state - I can't upgrade my > own armel boxes today but I don't have time to investigate why. Build > scripts that ensure that this persistent problem is fixed for the long > term and across all supported architectures. > > 6. Create a local mirror and use the scripts in emdebian-qa and > emdebian-tools to upload cross-built packages into the repo and start > building a small set of packages for armel. Don't proceed to other > architectures or make the mirror publicly accessible until the rest of > the issues in the Code Audit have been fixed. > > 7. Pick up development of emdebian-tools from existing SVN - there are > some changes in SVN that still need testing. > > 8. Start developing ways to test and fix an existing problem in that > the ./configure scripts in some packages insist on looking for stuff > in /usr/lib/ and then linking against the shared libraries > in /usr/arm-linux-gnueabi/lib/ etc. This is a disaster waiting to > happen and must be fixed before Crush can progress to more than one > architecture. In the same manner, check builds for /usr/include/ > pollution and drop the apt-get build-deps stage in a clean chroot. If > no xcontrol file, allow (nay require) native deps. > > 9. Make notes in CodeAudit of packages that fail to rebuild twice in a > row and detail why. > > 10. test and document the proper support for CC_BUILD in autotools. > > 11. Get Build-Depends split into debian/control and normal Debian? > Possibly as well as Depends-Install (installed on build) and > Depends-Runtime ? Building a *static* chroot for another machine, only > needs runtime stuff. Allows native cross-versions of packages, smaller > installed images. No way to put a prefix in front of maintainer > scripts > for config files. Need a mangling frontend in dpkg before calling the > script. Install time scripts vs runtime scripts. (A topic briefly > discussed with Wookey, hopefully my notes aren't too brief for the > idea > to be reconstructed. I knew what I meant at the time.) > > 12. Create a new wiki page to detail things like this and whatever > else > comes up as you go. Link it from the EmdebianTracker page? > > 13. Please don't come to me continually for input, if Crush is to > continue, someone needs to take over maintenance and that means filing > and fixing the bug reports without looking at me to do it. (You'd > alter > the Maintainer: field in debian/control to remove my name and enter > your own so that the bug messages for the emdebian-tools source > package go to you or to this list.) > > 14. Work out how to fix "X-Build-Cross-Libtool: yes" which is probably > tied into other libtool issues identified in the CodeAudit to do with > refreshing the autoconf and libtool metadata prior to attempting the > cross-build. > > 15. Get CMake build systems cross-building properly. > > 16. Get a mini-perl and some kind of python support. > > 17. Solve what ever other issues turn up during these processes. > > 18. Fix all the packages that used to cross-build for Crush 1.0 > but not > longer cross-build in unstable. (The CodeAudit identifies these > packages, one is gcc-4.4). Work out and gain consensus on whether such > packages should *not* be cross-built from source and just "borrowed" > directly from Grip. This is a Policy decision about whether Crush > should be 100% buildable from source or whether compromises are > acceptable. Mixing Crush and Grip will *only* work if the xcontrol > support is fixed such that changed functionality is always encoded > within the binary package name like libgconf-noldap-2-4 etc. > > 19. Identify *new* packages that have become dependencies of necessary > packages in Crush since the release of 1.0 and then work out how > to get > each of these to cross-build. > > 20. Test these packages with real systems and see if the rootfs > scripts > can still operate and what new bugs arise at installation/deployment > time. > > 21. Manage the repository to cope with britney (the script that > migrates packages from unstable into testing in Debian). > > 22. Manage the repository to cope with testing-proposed-updates once > the Squeeze release freeze starts to happen. > > 23. Test and report bugs with the locale support via Emdebian > TDebs and > langupdate. > > 24. Fix issues like the bulky gconv files in libc6 and test with the > tzdata support. > > 25. uClibc support > > 26. Finalise the cache value support in dpkg-cross and add to it if > necessary. Consider deploying the cache values into the Debian package > such that the files can be created at build time on a > per-package-per-architecture basis. > > 27. Keep an eye on multiarch developments and feed into the process to > ensure Debian gets a usable cross-build environment based on > multiarch. > Get dpkg-cross merged into dpkg as soon as multiarch is supportable. > > 28. Whatever else I've forgotten. > > Is that enough for now? > > -- > > > Neil Williams > ============= > http://www.data-freedom.org/ > http://www.linux.codehelp.co.uk/ > http://e-mail.is-not-s.ms/ > > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
