Seems I for­got to announce that the linux_base-c6 is in the Ports Col­lec­tion now. Well, it is not a replace­ment for the cur­rent default linux base, the lin­ux­u­la­tor infra­struc­ture ports are miss­ing and we need to check if the ker­nel sup­ports enough of 2.6.18 that noth­ing breaks.

TODO:

• check for updated RPMs for linux_base-c6
• cre­ate lin­ux­u­la­tor infra­struc­ture ports
• improve the ker­nel to sup­port more of linux 2.6.18

To my knowl­edge, nobody is work­ing on any­thing of this. Any­one is wel­come to have a look and pro­vide patches.

It seems my HOWTO cre­ate a new linux_base port was not too bad. There is now a PR for a Cen­tOS 6 based linux_base port. I had a quick look at it and it seems that it is nearly usable to include into the Ports Col­lec­tion (the SRPMs need to be added, but that can be done within some minutes).

When FreeBSD 8.3 is released and the Ports Col­lec­tion open for sweep­ing com­mits again, I will ask port­mgr to do a repo-copy for the new port and com­mit it. This is just the linux_base port, not the com­plete infra­struc­ture which is needed to com­pletely replace the cur­rent default lin­ux­u­la­tor user­land. This is just a start. The process of switch­ing to a more recent linux_base port is a long process, and in this case depends upon enough sup­port in the sup­ported FreeBSD releases.

Atten­tion: Any­one installing the port from the PR should be aware that using it is a highly exper­i­men­tal task. You need to change the lin­ux­u­la­tor to imper­son­ate him­self as a linux 2.6.18 ker­nel (described in the pkg-message of the port), and the code in FreeBSD is far from sup­port­ing this. Any­one who wants to try it is wel­come, but you have to run FreeBSD-current as of at least the last week­end, and watch out for ker­nel mes­sages about unsup­ported syscalls. Reports to emulation@FreeBSD.org please, not here on the webpage.

Yes­ter­day I dep­re­cated the non-default Fedora based Linux base ports. This means fc6, f7, f8 and f9 will van­ish soon (I decided for one month of expiry time). This is because all of them are End of Life upstream since a long time (= no secu­rity updates).

The fc4 and f10 ones are still avail­able — even if they are End of Life too — because FreeBSD 7.x can not use some­thing newer than the fc4 one, and we have not tested yet a more recent Linux dis­tri­b­u­tion.

Prob­a­bly the most easy way to update the Linux base ports to some­thing newer is to stay with Fedora (we have a lot of ports–infra­struc­ture for it already). Unfor­tu­nately it is not known if some­thing newer works with­out prob­lems (miss­ing epoll/inotify sup­port could be a road­block here in case it is exten­sively used in a more recent version).

I want to get some time to have a look if a more recent Fedora ver­sion is suit­able for the use as a Linux base in FreeBSD 8.x+, but I do not have an esti­mate when I can start and how long it may take. In case some­one already tested a more recent Fedora ver­sion feel free to share your experience.

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 ).

Ariffs changes two months ago to reduce the latency in the soundsys­tem also pre­pared the way for mul­ti­chan­nel sup­port and Yuriy added mul­ti­chan­nel record­ing to the emu10kx dri­ver (there are some bugs ATM and it is only a proof of con­cept to play around with it until we get real mul­ti­chan­nel sup­port in the generic sound code). Ryan tries to get some time (let’s cross fin­gers!) to con­vert a dri­ver (prob­a­bly the emu10kx dri­ver) to use the new mixer infra­struc­ture before he has to con­cen­trate on his stud­ies again.

This looks like we could get some very nice stuff this year.