HOWTO add linux-​infrastructure ports for a new linux_​base port

In my last blog-​post I de­scribed how to cre­ate a new linux_​base port. This blog-​post is about the oth­er Linux-ports which make up the Linux-in­fra­struc­ture in the FreeBSD Ports Col­lec­tion for a giv­en Linux-​release.

What are linux-​infrastructure ports?

A linux_​base port con­tains as much as pos­sible and at the same time as little as pos­sible to make up a use­ful Linux-​compatibility-​experience in FreeBSD. I know, this is not a de­script­ive ex­plan­a­tion. And it is not on pur­pose. There are no fixed rules what has to be in­side or what not. It “ma­tured” in­to the cur­rent shape. A prac­tic­al ex­ample is, that there is no GUI–stuff in the linux_​base. While you need the GUI parts like GTK or QT for soft­ware like Skype and acror­ead, you do not need them for head­less game serv­ers. While you may need vari­ous lib­rar­ies for game serv­ers, you may not need those for Skype or acror­ead. As such some stand­ard parts are in sep­ar­ate ports which are named linux–LINUX_​DIST_​SUFFIX-NAME. For GTK and the Fe­dora 10 re­lease this res­ults in linux-​f10-​gtk2. Such gen­er­ic ports which de­pend upon a spe­cif­ic Linux-​release make up the Linux-​infrastructure in the FreeBSD Ports Col­lec­tion. Those ports are ref­er­enced in port-​Makefiles via the USE_​LINUX_​APPS vari­able, e.g. USE_LINUX_APPS=gtk2.

If you cre­ated a new linux_​base port, you need most stand­ard in­fra­struc­ture ports in a ver­sion for the Linux-​release used in the linux_​base port, to have the Linux-​application ports in the FreeBSD Ports Col­lec­tion work­ing (if you are un­lucky, some ports do not play well with the Linux-​release you have chosen, but this is out of the scope of this HOWTO).

Up­dat­ing Mk/

 First we need to set the LINUX_​DIST_​SUFFIX vari­able to a value suit­able to the new Linux-​release. This is done in the con­di­tion­al which checks the OVERRIDE_​LINUX_​NONBASE_​PORTS vari­able for val­id val­ues. Add an ap­pro­pri­ate con­di­tion­al, and do not for­get to add the new val­id value to the IGNORE line in the last else branch of the con­di­tion­al.

The next step is to check the _​LINUX_​APPS_​ALL and _​LINUX_​26_​APPS vari­ables. If there are some in­fra­struc­ture ports which are not avail­able for the new Linux-​release, the con­di­tion­al which checks the avail­ab­il­ity of a giv­en in­fra­struc­ture port for a giv­en Linux-​release needs to be mod­i­fied. If at a later step you no­tice that there are some ad­di­tion­al in­fra­struc­ture ports ne­ces­sary for the new Linux-​release, _​LINUX_​APPS_​ALL and the check-​logic needs to be mod­i­fied too (e.g. add a new vari­able for your Linux-​release, add the con­tent of the vari­able to _​LINUX_​APPS_​ALL, and change the check to do the right thing).

After that two te­di­ous parts need to be done.

For each in­fra­struc­ture port there is a set of vari­ables. The name_​PORT vari­able con­tains the loc­a­tion of the port in the Ports Col­lec­tion. Typ­ic­ally you do not have to change it (if you really want to change it, do not do it, fix the nam­ing of the in­fra­struc­ture port in­stead), be­cause we use a nam­ing con­ven­tion here which in­cludes the LINUX_​DIST_​SUFFIX. The name_​DETECT vari­able is an in­tern­al vari­able, do not change it (if you cre­ate a new in­fra­struc­ture port, copy it from some­where else and make sure the name in value of the vari­able matches the port name in the name of the vari­able). Then there are sev­er­al name_​suf­fix_​FILE vari­ables. Leave the ex­ist­ing ones alone, and add a new one with the cor­rect suf­fix for your new Linux-​release. The value of the vari­able needs to be an im­port­ant file which is in­stalled by the in­fra­struc­ture port in ques­tion. FYI: The con­tent of the name_​suf­fix_​FILE vari­ables are used to set the name_​DETECT vari­ables, de­pend­ing on the Linux-​relase the name_​DETECT vari­ables are used to check if the port is already in­stalled. Ideally the name_​suf­fix_​FILE vari­able points to a lib­rary in the port. The name_​DEPENDS vari­able lists de­pend­en­cies of this in­fra­struc­ture port. If the de­pend­en­cies changed in your Linux-​release, you need to add a con­di­tion­al to change the de­pend­ency if LINUX_​DIST_​SUFFIX is set to your Linux-​release.

Nor­mally this is all what needs to be done in PORTSDIR/Mk/, the rest of the file is code to check de­pend­en­cies and some cor­rect­ness checks.

The second te­di­ous part is to ac­tu­ally cre­ate all those in­fra­struc­ture ports. Nor­mally you can copy an ex­ist­ing in­fra­struc­ture port, re­name it, ad­just the PORTNAME, PORTVERSION, PORTREVISION, MASTER_​SITES, PKGNAMEPREFIX, DISTFILES, CONFLICTS (also in all oth­er Linux-​release ver­sions of this in­fra­struc­ture port), LINUX_​DIST_​VER, RPMVERSION (if set/​neccesary) and SRC_​DISTFILE vari­ables, gen­er­ate the dist­file check­sums (make make­sum), and fix the plist. I sug­gest to script parts of this work (as of this writ­ing Fresh­ports counts 68 ports where the port­name starts with linux-​f10-).

Adding new in­fra­struc­ture ports, or re­mov­ing in­fra­struc­ture ports for a giv­en Linux-​release

If your Linux-​release does not come with a pack­age for an ex­ist­ing in­fra­struc­ture port, just do not cre­ate a cor­res­pond­ing name_​suf­fix_​FILE line. You still need to do the right thing re­gard­ing de­pend­en­cies of ports which de­pend upon this non-​existing in­fra­struc­ture port (if your Linux-​release comes with pack­ages for them).

To add a new in­fra­struc­ture port, copy an ex­ist­ing block, re­name the vari­ables, set them cor­rectly, add a new vari­able for your Linux-​release in the first _​LINUX_​APPS_​ALL sec­tion, add the con­tent of this vari­able to _​LINUX_​APPS_​ALL, and change the check-​logic as de­scribed above.

Fi­nal words

If you have some­thing which in­stalls and dein­stalls cor­rectly, feel free to provide it on freebsd-​emulation@​FreeBSD.​org for re­view/​testing. If you have ques­tions dur­ing the port­ing, feel also free to send a mail there.

Are USB memory sticks really that bad?

Last week my ZFS cache device – an USB memory stick – showed xxxM write er­rors. I got this stick for free as a promo, so I do not ex­pect it to be of high qual­ity (or wear-​leveling or sim­il­ar life-​saving things). The stick sur­vived about 9 months, dur­ing which it provided a nice speed-​up for the ac­cess to the cor­res­pond­ing ZFS stor­age pool. I re­placed it by an­oth­er stick which I got for free as a promo. This new stick sur­vived… one long week­end. It has now 8xxM write er­rors and the USB sub­sys­tem is not able to speak to it any­more. 30 minutes ago I is­sued an “us­b­con­fig re­set” to this device, which is still not fin­ished. This leads me to the ques­tion if such sticks are really that bad, or if some prob­lem crept in­to the USB sub­sys­tem?

If this is a prob­lem with the memory stick it­self, I should be able to re­pro­duce such a prob­lem on a dif­fer­ent ma­chine with a dif­fer­ent OS. I could test this with FreeBSD 8.1, Sol­ar­is 10u9, or Win­dows XP. What I need is an auto­mated test. This rules out the Win­dows XP ma­chine for me, I do not want to spend time to search a suit­able test which is avail­able for free and al­lows to be run in an auto­mated way. For FreeBSD and Sol­ar­is it prob­ably comes down to use some disk-​I/​O bench­mark (I think there are enough to chose from in the FreeBSD Ports Col­lec­tion) and run it in a shell-loop.

I switched my feed read­er

Be­fore I have read the news feeds I am in­ter­ested in via the Fire­fox plu­gin “brief”. It did all I wanted it to do, but I had all the data and metadata (all the feeds and read items) only in one browser. I was not able to have a shared state at work and at home.

Now I in­stalled rnews on my web­serv­er. It is multi-​user cap­able, so that mul­tiple people can read the feeds they are in­ter­ested in, without the need to have mul­tiple in­stall­a­tions. I can use it from any place where I have an in­ter­net con­nec­tion, without los­ing the state.

It is in the FreeBSD Ports Col­lec­tion as www/​rnews.

LAME up­dated in the FreeBSD ports col­lec­tion

After all the big-​impact com­mits (Gnome/​gettext/​KDE/​X11/​…) have settled now, I took the time to up­date audio/​lame (I iden­ti­fied more than 100 ports with an (im­pli­cit) de­pend­ency on lame, 45 of them needed a port­re­vi­sion bump; if I forgot/​overlooked some, bump the re­vi­sion your­self or no­ti­fy me please). That is the first up­date of my ports where miwi@ did not beat me in com­mit­ting an up­date since a year (he has im­pli­cit ap­prov­al to do any­thing he wants with my ports).

I can be happy that he is/​was this fast (and that we have such a pro­duct­ive and ef­fi­cient com­mit­ter), or I can be sad that I do not have the time any­more to be faster than I am with such things… or both. Hmmm… I think I will go the happy way. 😉