On Thu, 6 Aug 2009 18:13:03 +0200 Simon Richter <sjr@debian.org> wrote: One important point - it is Crush 2.0 that has been abandoned, not Crush itself. Once multiarch is implemented and working, I'm happy to work on Crush. Whether that is Crush 3.0 or 4.0 I have no idea, I doubt multiarch will be ready and working for 2.0. Even if multiarch has basic support in Debian 6.0 (Squeeze), I don't see that there is time to mould the Crush build system to multiarch *and* fix all the bugs and other issues before Squeeze itself is released. Crush development is stalled until multiarch is fully implemented. I should have made that clear - principally because I expect my health to improve sufficiently by then that I'll be able to pick up development of Crush once more. I'd be very pleased to find that others have joined the effort in the meantime, of course, as that will make extending Crush to more than one or two architectures achievable. It's not nice to have a gap in the release history of any distribution, but in the case of Crush, I feel that it is both inevitable and reasonable - given the scale of the problems at this moment. Crush (like Grip) does need to be tied to the Debian release cycle and I really think it is best to aim for Squeeze+1. Don't let the undoubted enthusiasm mask the size of the task. Hundreds and hundreds of developer hours are needed and Squeeze (and therefore Crush) could be in release freeze within 7 months. The release freeze really needs to be about implementation fixes, not core structural development. I wouldn't like Crush 2.0 to be worse than 1.0 - it was hard enough dealing with 1.0, we shouldn't expect to release 2.0 in an even worse state than 1.0. > Hi, > > > > 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. > > xcontrol is dead, long live xcontrol. > > In Cáceres, I had a (long) talk with Guillem Jover from the dpkg team. In > general, we both want to get rid of the xcontrol file in the long run, and > have the same information provided in the regular control file. There was a > small multi-arch cabal meeting, where Wookey, Héctor and myself presented > the emdebian use cases (cross compiling and toolchain bootstrap), which led > to a small syntax change (as to not close doors) and a request to write a > proper paper on what needs to be added to multiarch to support > cross-compiling and toolchain bootstrap. > > Multiarch in general allows us to install packages for any architecture on > a single host, provided they do not have file conflicts (with some > exceptions) and the version numbers of a single package is the same across > all architectures. Until multiarch arrives, we're still going to need a new version of xcontrol to implement the necessary package renaming support that is necessary for Crush 2.0. > So, this would allow us to get rid of dpkg-cross (as soon as all libraries > are converted to multi-arch). IMHO dpkg-cross (and therefore apt-cross) will still be core to the generation of Crush 2.0. Correct me if I'm wrong but multiarch requires at least one release cycle before it can actually help us - i.e. Squeeze +1 which will be the basis of any Crush 3.0, should it be possible. The state of multiarch in Debian was one reason for me choosing to drop Crush 2.0 as the best way to fit my reduced available time into a continued desire to do the best I can for Emdebian. The dpkg-cross, apt-cross, xcontrol mechanism used for Crush 1.0 was horribly fragile and extending it to cope with package renaming for Crush 2.0 is not something I really want to think about. Debian is at a cross-roads as far as cross-compiling is concerned, my concern is that the previous system used for Crush 1.0 will not bear the weight of Crush 2.0 and that the correct answer, multiarch, will not be ready in time for Crush 2.0. IF multiarch really can be implemented before Squeeze is frozen, then it is still a lot of work to redesign the entire Crush build system to work with it and then fix the bugs that are likely to result. If those bugs turn out to be in the multiarch system itself, it means that there is even less time to do anything about fixing them as multiarch support is not likely to be an RC bug in Squeeze, certainly not if the bug in question primarily affects cross-building support. > > > 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. > > Basically, we want an autobuilder that cross-compiles packages and > something lintianish to check whether the resulting packages are what we > want (specifically, if the generated binaries match the target > architecture). Those scripts (with lintian and edos-debcheck support) already exist in the emdebian-tools and emdebian-qa packages, it remains to fix whatever bugs arise when extending to more than one architecture and more than one buildd etc. The autobuilder used for Crush 1.0 was one of my home machines and that will not be available for Crush 2.0, it will be busy with Grip. > > > 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. > > In principle, the configure script should never look at any path directly, > but rather trust the compiler. That is the principle but it does not actually happen. It was to be the next component of the CodeAudit but no actual data yet exists on just how many packages break this principle - I just remember that there are more than a handful and less than a majority. The difficult part is that when fixing cross-builds, it's also useful to be able to check the build using the native compiler. So, the tests need to be done in clean chroots. Not a big hurdle but it all adds to the time required and time is short before the Squeeze release freeze. (It is already down to half the time it took to get Crush 1.0 into a releaseable state.) During the Lenny release freeze, I was mainly working on implementation bugs and also on Grip. In total, I was putting in about 20-30 hours a week just into Emdebian Crush and Grip for about a year. The biggest problems will come with the most important packages, like gcc and gtk. Thankfully, the new libc6 source is much easier to handle (until you start thinking about solving the gconv problems) as is tzdata. GTK is still borked due to problems in apt-cross. See bug # 502433 and last time I tried, gcc-4.4 does not build at all for Crush. > > > 10. test and document the proper support for CC_BUILD in autotools. > > IIRC the GNU project uses "CC_FOR_BUILD". AFAICT it does but in a completely undocumented manner and not all packages that do implement it do so in a consistent manner. > > > 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. > > I'd rather fix the configure scripts for good than hack around them. For a > lot of packages, simply rebuilding the script with current autoconf is > sufficient (for example, current autoconf knows to determine endianness by > analyzing the binary with objdump rather than running it). Fixing the configure scripts means fixing the autoconf macros which will take time. That won't happen for Crush 2.0. I respect the enthusiasm to try and fill the gap but even before my illness I had begun to doubt that Crush 2.0 would be possible. IMHO it is certainly unlikely that Crush 2.0 would be able to support more than just armel - possibly i386 if another two or three people start work on it now, but I really don't think that multiarch is going to help Crush 2.0 at this stage, not with the amount of available time left before the Squeeze release freeze and the requirement for multiarch to be supported by dpkg in Squeeze before being tested in actual packages in Squeeze+1. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpSOOtR3y2mR.pgp
Description: PGP signature