linux_base-c6

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 lin­ux 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 updat­ed 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 lin­ux 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.

New Cen­tOS linux_base for test­ing soonish

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 near­ly usable to include into the Ports Col­lec­tion (the SRPMs need to be added, but that can be done with­in some minutes).

When FreeB­SD 8.3 is released and the Ports Col­lec­tion open for sweep­ing com­mits again, I will ask port­m­gr 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 need­ed to com­plete­ly 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­port­ed FreeB­SD releases.

Atten­tion: Any­one installing the port from the PR should be aware that using it is a high­ly exper­i­men­tal task. You need to change the lin­ux­u­la­tor to imper­son­ate him­self as a lin­ux 2.6.18 ker­nel (described in the pkg-message of the port), and the code in FreeB­SD 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­port­ed syscalls. Reports to emulation@FreeBSD.org please, not here on the webpage.

Non-default lin­ux base ports deprecated

Yes­ter­day I dep­re­cat­ed the non-default Fedo­ra based Lin­ux base ports. This means fc6, f7, f8 and f9 will van­ish soon (I decid­ed for one month of expiry time). This is because all of them are End of Life upstream since a long time (= no secu­ri­ty updates).

The fc4 and f10 ones are still avail­able – even if they are End of Life too – because FreeB­SD 7.x can not use some­thing new­er than the fc4 one, and we have not test­ed yet a more recent Lin­ux distribution.

Prob­a­bly the most easy way to update the Lin­ux base ports to some­thing new­er is to stay with Fedo­ra (we have a lot of ports-infrastructure for it already). Unfor­tu­nate­ly it is not known if some­thing new­er works with­out prob­lems (miss­ing epoll/inotify sup­port could be a road­block here in case it is exten­sive­ly used in a more recent version).

I want to get some time to have a look if a more recent Fedo­ra ver­sion is suit­able for the use as a Lin­ux base in FreeB­SD 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 test­ed a more recent Fedo­ra ver­sion feel free to share your experience.

Ports relat­ed stuff

The pack­age depen­den­cy speedup was com­mit­ted by port­m­gr, unfor­tu­nate­ly 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­i­ty to switch of the reg­is­tra­tion of implic­it 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­den­cy changes).

Patch­es 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 low­er 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 fore­see nice improve­ments in the soundsystem

Ariffs changes two months ago to reduce the laten­cy 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 gener­ic 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 mix­er 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.