The pack­age depen­dency speedup was com­mit­ted by port­mgr, unfor­tu­nately it was not the lat­est ver­sion of it. The most recent ver­sion is sched­uled for an exper­i­men­tal ports build run (my patch also con­tains the pos­si­bil­ity to switch of the reg­is­tra­tion of implicit depen­den­cies, if enabled it gives a much bet­ter pic­ture regard­ing which port needs to be rebuild (portre­vi­sion bump) in case a depen­dency changes).

Patches for speed­ing up “make clean” are also sched­uled for an exper­i­men­tal ports build run. The pkg_create patch was also com­mit­ted to -cur­rent.

With all those stuff an update is much faster now, at least for those ports where the compile/build time was much lower than the infra­struc­ture pro­cess­ing (I doubt you will see a sig­nif­i­cant change in a build of OO ).

I had a look at some USB PRs and wrote a list of those with patches to Warner (as he is work­ing on USB stuff cur­rently). I also cat­e­go­rized them (easy, not easy, maybe already fixed, …). The easy ones he han­dled already, for the rest I don’t know his cur­rent plans.

Regard­ing lin­ux­u­la­tor stuff I’m work­ing on a MFC patch (no TLS, no futexes). As I don’t have a -sta­ble box I need some help test­ing it before I can com­mit it. I only com­pile tested this on –cur­rent with the new gcc 4.2. What I need is:

• test­ing on i386, amd64 (if I for­got some­thing, it may panic your system)
• “make uni­verse” test (you have to grep all the logs for “Error 1″ and inves­ti­gate the error if there’s one)
• LTP test run, see the wiki for more (best would be a diff of the logs in the result direc­tory of no-patch/patch runs)
• nor­mal linux appli­ca­tion use-tests

What the patch pro­vides is:

• mmap fixes
• fix mem­leaks
• add mprotect/iopl/lstat/ftruncate/statfs64/timer_*/mq_*
• more errno value mapping
• don’t limit num­ber of syscalls to 255
• allow to exec libs
• ioctl TIOCGPTN
• han­dle more socket options
• de-COMPAT_43-ify
• add dummy syscalls so that we know what is needed (reports from users)
• style(9)
• lin­procfs enhance­ments