Hello everyone,
Since Neil's post to the list that he can no longer devote his time to working on Crush 2.0, we should open a discussion of how to move forward in his absence.
Neil replied with a list of project items (which I have included again in this post) that give us a starting point in putting together a preliminary roadmap toward finishing the work he is passing on to the rest of us. I've taken a look at Neil's list, a few of the items will certainly involve further clarification and study, others are challenging , yet can be tackled in isolation.
There are items in the list that a problems which will need input from other groups in the Debian community and still others that will affect the overall scope and direction Crush 2.0 takes.
At this point, what I'm asking of the members on this list is to review and comment on the items so that we can collectively begin to work toward prioritizing them and hopefully some of you will be generous enough to suggest/recommend how you could contribute efforts to work on them. If anyone can offer suggestions on how to organize the effort on this so more than one person can work on Crush 2.0, please by all means speak up. At this point, the floor is open and we can all weigh in with whatever we believe will contribute toward moving this project along.
I'll check in with everyone here again in about a week. By then, perhaps we'll have moved the list forward and have some idea of the direction we need to take with Crush 2.0.
Once again, a big thank you to Neil for his efforts on this and best of luck.
Prince
several
===============NEIL'S LIST FOR CRUSH 2.0 AUG 2009 ==================
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?
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/