So, since yesterday I worked on updating Gentoo/FreeBSD ebuilds to 6.1. Thanks to Robert (arachnist) the work was quite easy, as he already tired most of the build stuff 🙂
What remained me to do was to fix the details and making sure that the result was fine, along with trying to build the stuff with SSP enabled.
Unfortunately I forgot (entirely) freebsd-usbin yesterday, and I’m working now to fix it. This wasn’t good mainly because the two applied patches failed, one has been fixed by shortening it and removing the hacks to use /usr/src/sys (as thanks to Benigno we now symlink the src directory in ${WORKDIR} and live happy), the other I had the patch from Robert to replace with.
That wasn’t enough, as it then failed on amd’s info file… but that made me notice that amd came out of contrib package… and that am-utils package is in portage. I’ve then removed amd from freebsd-usbin and now I’m fighting to make am-utils to build on Gentoo/FreeBSD. The main problem is due to the different way db is handled. On GLIBC, to have db1 you need to install it separately, but in FreeBSD the functions are provided by the libc, so you need nothing to link against, but at the same time, things like gdbm are more likely to conflict. In this case am-utils are picking up the ndbm.h header from gdbm but no library :/
I should be able to get that to work later today, in the mean time luckily I don’t use amd at all 😛 So next time the stage will be even smaller, as amd won’t be present (let’s minimal be minimal, do we?)
What remains in my mind as “to be decided” is the fate of ftpd and lukemftpd. lukemftp (the client) is removed in favour of tnftp (that’s the same code but updated with a new name), but we don’t have tnftpd (the server) in portage, although we do have quite a few of FTP daemons.
I’m thinking of simply dropping those two ftpd and leave the users with the choices already in portage, if someone really wants a lukemftpd-compatible daemon, I’d rather put tnftpd in portage independently so that it can be used by Gentoo Linux users, too, and it’s updated more regularly.
For who’s wondering yes, lighttpd here is already running with SSP enabled, as well as ruby 🙂
