Am Samstag, 2. Oktober 2010, 06:53:18 schrieb Enrico Weigelt: > * davidMbrooke <dmb.leaf-de...@ntlworld.com> schrieb: > > 1. There are still some 3.x packages that do not build successfully on > > 4.x / with GCC 4.x. Andrew, kp and I are working away at those but there > > are more to fix (or decide to drop). > > Which ones ? (I'll have a look at them and pass 'em through Briegel). > > > 2. As you noted in a separate mail we have many packages based on old > > upstream versions. In some cases we "held back" the version to keep the > > disk image size small or for compatibility with the 2.4 kernel. > > I can't check on 2.4 kernel as I don't haven't running it anymore. > But I could do some size checks. >
Enrico; I suggest, that you first start to understand the structure we've build up the last eight years working on bering-uclibc. It is possible to run buildenv for the latest stable 3.x version and for the 4.x in development. It looks to me that you've put the bering-uclibc 3.x version into "your" git - bash version in 4.x is 3.2.48. So you do have 2.4 kernel already in your SCM, just do a full build, package it, prepare the images and you can also start a 2.4 machine in qemu :). Pls note, as Martin said: There are other utilities we used in the release process that are build on cvs - for example have a look at genpage.pl... Others may be replaced with current development (prepareimages and createimages by buildimage.pl - though the latter requires to full build on your own, instead of just creating images from the already built packages in cvs. Maybe this will be improved in a future version of buildimage.pl.) buildtool, cvs and the releated utilities has served me very well over the years. For shure there might be better alternatives around, but they just don't work yet to build _and_ release a 3.x or 4.x version. It's that easy to me. What I really miss is a comprehensive documenation(tool), (the wiki is IMHO a good start and hopefully an improvement over the old docbook-based process, which was too difficult to setup and use to write _and_ release documents for too many developers), and a bug-tracker (Mike mentioned TRAC, fine with me). I really don't want to stop you or anyone else to research a new SCM and/or buildenv, and I do know that the main reason working on OSS project is doing interesting things (and not everyone is interested to write good documenation). So move on with what you are interested in, but be aware that at least I am pretty ignorant and quiet about what seems to be "academic" discussion to me - as always, code is the most convincible argument :) That said: Welcome on the list! kp (no harm intended, just want to make my point.) ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
