Am Samstag, 7. August 2010, 21:14:40 schrieb Andrew: > After rebuilding and fixing some high-priority packages (like ppp) and > potentially useful (like setserial), currently there are some packages > that can't be built: > fritz, unicorn, bash, lcd4linux, kismet, ipvsadm, zaptel, bristuff, > libpri, asterisk, openswan, wlan-ng, lirc, pump, irmp3, tinyproxy, > snort, gpio, ulogd > > What of them are important and really must be fixed, and what of them > are deprecated and must be excluded from this branch?
Andrew; most of these packages haven't ever compiled with the Bering-uclibc4 branch, so it is not related to the kernel upgrade. Namely: fritz, unicorn, bash,lcd4linux,kismet, ipvsadmin, zaptel, bristuff, libpri, asterisk, openswan, wlan-ng, pump, irmp3, tinyproxy, gpio. That's similar to your list above. I can add quagga and nut, both failed with the 2.6.32 kernel in a full build a few days ago. >From your list above I only consider ulogd as semi-important, cause this is needed for shorewall - at least if we don't change the shorewall setup, which can be done easily. All other packages would be a nice-to-have, but as I wrote at the time you started to work on Bering-uClibc4, I don't expect that each and every package has to be ready for a beta. (And as Martin pointed out often on the list - if a package is really demanded by a someone, he'll be either provide the patches/setup if he is a devloper, or will put enough energy as a user to help a developer, but we don't have to make everything on our own). I state again, you did a great job and a lot more packages seems to be in a good shape than I've expected a few weeks ago. So none of the failing packages are showstoppers for a beta-release (all of the currently failing packages has been added over the years after we released Bering-uClibc2 - so there is enough time to let v4 mature :)). BUT what I consider as showstoppers are the impossibilty to compile a kernel with a different config as I reported yesterday, the pb's with WLAN and ath5k I observe - if you can confirm it's a local problem I have, it will be fine with me. And if you want to upgrade busybox I'd suggest to do better before a release, so we have a beta that has all important packages upgraded to the intented versions. Also I'd like to ask again, if we shouldn't target to be ipv6-ready from the start - that means to get rid of the seperate ipv6 packages wherever possible (for example to have one shorewall.lrp with shorewall and shorewall6 instead of two lrp's, moddb.lrp and moddb6.lrp and so on). Once the core (kernel, uClibc, busybox) is fixed, providing a good documentation user and developers can start with, is IMHO more important, than providing packages that have been added over the years to the nowadays stable branch. YMMV kp ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
