Hi Paul, > (1) > > gpio fails to package > tries to package staging/lib/modules/gpio.o > file is really staging/lib/modules/2.4.32/gpio/gpio.o correct, that was broken by a recent update to the build scripts. We're looking into that.
> (2) > > initrd needs to be built as real root, not fakeroot because it tries to > mount loopback filesystems in order to make the packages Also correct. We're working on a way to get it to work without the need for mounting the loopback fs - but for now the only way to get by without real root access is to give your local user permission to mount /mnt/loop (or you can add "mountpoint=/mnt/somethingElse" to conf/buildtool.conf if you want to use a different mountpoint) > (3) > > lrpstat requires java_home & java sdk to be built but is not documented > and not depended upon... Correct - if you have any ideas on how to solve that, I'd gladly hear them. Last time I checked, installing a java sdk required acknowledging the end user licence agreement - not something easily done in an automated build script. For now, I simply commented out lrpstat in sources.cfg with a note that anybody who wants to build it needs a Java SDK, plus the appropriate environment settings. Actually, it needs two JDKs - a 1.1 compatible one (so the applet can be run on IE without a separate jre installed), and a more recent one (to actually compile the classes - the older JDKs don't run on any of my linux systems) . > (4) > > shorewall fails to package, cp is failing on /etc/shorewall/*, looks like > this cp happens *AFTER* "Cleaning up dir /tmp/BUILDTOOL_STAGING_xxxx" Not quite - the "Cleaning up" part is part of the error handler, so buildpacket doesn't leave tons of stuff in the tmp dir when it exits upon error. The actual problem is that the cp call returns a nonzero value (I guess because it ommitted the subdirectories) and hence buildpacket assumes something went wrong (since the info page on cp states "An exit status of zero indicates success, and a nonzero value indicates failure") and exits. We're looking at how to get around that without breaking anything else. > (5) > > pptpd is attempting to execute aclocal1.9 as part of the build > > it should be depending upon the version of autotools inside the leaf > buildtool environment, not trying to use a hardcoded explicit version > in the host environment. > > -------------------------------------------------------------------------- > > (6) > > upnpd package needs to depend upon lpthread in sources.conf I don't know about those two - so I'll let somebody else comment. > (7) > > No clear differentiation between programs that run in the host environment > and programs that need to be compiled in the target environment. > Good exercise would be to build LEAF on a non x86 linux box and find all > of this crap (for example, linux/scripts/mkdep (a binary) is compiled > against uclibc by the target compiler, but run on the host). > > (Of course, I've mentioned this before... but it really needs to get fixed > as our host and target environments diverge) Good luck on that one. I'd really like to see that too, but the last time I tried, I failed miserably. There are _many_ configure scripts out there that simply cannot cope with a true cross-compile - many assume that the build host will also be the target host. If you specify the appropriate options (--build and --host, if I recall correctly), they fail. So, even if we fix all the "crap" that's compiled against uclibc but runs on the build-host, it wouldn't really help much, unless somebody takes the time and cleans up those troublesome configure scripts too, and then takes the changes upstream, so the changes to the configure scripts wouldn't have to be re-applied with the next version. Martin ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ leaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/leaf-devel
