Alexander Leidinger

For a long time I didn’t wrote something in my blog. This happens from time to time to a lot of people I think…

Ok, so some interesting news on the FreeBSD front: I’m porting NMM (version 1.0.0).Back in the days when I was writting my diploma thesis, those people where working on it already. I always wanted to port it, as it was cool to see it in action (one system picked up a football match and distributed it to a lot of PCs in the local subnet (AFAIR multicast) and even handhelds in real-time (with automatic downsizing to the output device), and was also distributing it to the Uni-Aula (AFAIR TCP stream)). The box was not powerful at all, and you where able to do a lot of processing on any machine in the network, while the client didn’t know where which processing happened. They also present it for several years on the CEBIT in Germany. They have videos showing it in action. You can do a lot more cool things with this. Think about a network aware multimedia center. You can have your movies / MP3s / whatever on several machines in your network, and the output is displayed on a not so powerful machine without any trace in the GUI that there are other machines involved. And if you want to play around, you can even see/hear the same stuff synchronized at the same time in multiple rooms and even on your handheld device.

This is scheduled to be used in the new KDE multimedia infrastructure, and even in some Bang&Olufsen products.

So far it compiles after a little bit of patching, but there are some strange things to solve before I can even try to use it. I posted a message to the development forum, let’s wait and see what they have to tell.

And on a related area, I also got a Wiimote (Wii remote controller) working in FreeBSD. I think this will be a nice mouse replacement for a multimedia center. I have a discussion on the FreeBSD bluetooth mailinglist regarding this.

I just submitted my patch to remove calls (exec()ing) to basename/dirname in bsd.port.mk to GNATS. I didn’t time if this improves anything, but I assume doing a regex replacement in a make-variable uses less resources than doing a fork()&exec() or a system() call.

I don’t think this gives a huge improvement at all, it’s maybe even below the measurement threshold, but hey, why using external tools if the internal features are enough to do what you want? At least this patch is recorded now somewhere…

In the last days I committed some scripts to $PORTSDIR/Tools/scripts which help in detecting the explicit library dependencies of installed ports. You just have to run $PORTSDIR/Tools/scripts/explicit_lib_depends.sh with the package-name of the installed port (alternatively you can give the path to the registered port, e.g. /var/db/pkg/gnome-terminal-2.18.1). One of the scripts which are called needs portupgrade installed. As an example here’s the complete output of a script run with the gnome-terminal port:

# /usr/ports/Tools/scripts/explicit_lib_depends.sh gnome-terminal-2.18.1
USE_FREETYPE=yes
USE_GETTEXT=yes
USE_GNOME+=atk
USE_GNOME+=esound
USE_GNOME+=gconf2
USE_GNOME+=glib20
USE_GNOME+=gnomevfs2
USE_GNOME+=gtk20
USE_GNOME+=libartlgpl2
USE_GNOME+=libbonobo
USE_GNOME+=libbonoboui
USE_GNOME+=libglade2
USE_GNOME+=libgnome
USE_GNOME+=libgnomecanvas
USE_GNOME+=libgnomeui
USE_GNOME+=libxml2
USE_GNOME+=orbit2
USE_GNOME+=pango
USE_GNOME+=vte
USE_ICONV=yes
USE_XORG+=ice
USE_XORG+=sm
USE_XORG+=x11
USE_XORG+=xau
USE_XORG+=xcursor
USE_XORG+=xdmcp
USE_XORG+=xext
USE_XORG+=xfixes
USE_XORG+=xft
USE_XORG+=xi
USE_XORG+=xinerama
USE_XORG+=xrandr
USE_XORG+=xrender
audiofile:${PORTSDIR}/audio/libaudiofile
avahi-client:${PORTSDIR}/net/avahi
avahi-common:${PORTSDIR}/net/avahi
avahi-glib:${PORTSDIR}/net/avahi
cairo:${PORTSDIR}/graphics/cairo
dbus-1:${PORTSDIR}/devel/dbus
dbus-glib-1:${PORTSDIR}/devel/dbus-glib
expat:${PORTSDIR}/textproc/expat2
fontconfig:${PORTSDIR}/x11-fonts/fontconfig
gnome-keyring:${PORTSDIR}/security/gnome-keyring
jpeg:${PORTSDIR}/graphics/jpeg
png:${PORTSDIR}/graphics/png
popt:${PORTSDIR}/devel/popt
startup-notification-1:${PORTSDIR}/x11/startup-notification

All those libraries are directly referenced (dynamically linked in) in the binaries or libs of the gnome-terminal port, indirect (dependencies of dependencies) ones are not listed (and not needed). So the script allows to quickly produce a list of libs/ports which

• should be referenced in the port Makefile (new port development, port updates)


• allows to check if a port lists all referenced LIB_DEPENDS (port maintenance)

To do this with all your ports you can run

for port in /var/db/pkg/*; do
echo $port:
/usr/ports/Tools/scripts/explicit_lib_depends.sh $port
done > explicit_depends.txt

Not all USE_* switches of the Ports Collection are handled yet, if you stumble upon such a case, feel free to send me a mail.

Today I fixed 3 linux ports (converting to the “new” world order) to not use RPM directly (the right thing is to use rpm2cpio, and bsd.linux-rpm.mk provides some nice stuff to handle this).

In the last week I fixed some stuff in the linuxulator-MFC patch. It should now compile on amd64 and i386 without problems (at least the code which I have locally). There’s one (strange) panic report which I want to analyze and fix (if it is linuxulator related) with Roman before I update the patch on my site.

The package dependency speedup was committed by portmgr, unfortunately it was not the latest version of it. The most recent version is scheduled for an experimental ports build run (my patch also contains the possibility to switch of the registration of implicit dependencies, if enabled it gives a much better picture regarding which port needs to be rebuild (portrevision bump) in case a dependency changes).

Patches for speeding up “make clean” are also scheduled for an experimental ports build run. The pkg_create patch was also committed to -current.

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 infrastructure processing (I doubt you will see a significant 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 working on USB stuff currently). I also categorized them (easy, not easy, maybe already fixed, ...). The easy ones he handled already, for the rest I don’t know his current plans.

Regarding linuxulator stuff I’m working on a MFC patch (no TLS, no futexes). As I don’t have a -stable box I need some help testing it before I can commit it. I only compile tested this on -current with the new gcc 4.2. What I need is:

• testing on i386, amd64 (if I forgot something, it may panic your system)


• “make universe” test (you have to grep all the logs for “Error 1” and investigate 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 directory of no-patch/patch runs)


• normal linux application use-tests

What the patch provides is:

• mmap fixes


• fix memleaks


• add mprotect/iopl/lstat/ftruncate/statfs64/timer_*/mq_*


• more errno value mapping


• don’t limit number of syscalls to 255


• allow to exec libs


• ioctl TIOCGPTN


• handle more socket options


• de-COMPAT_43-ify


• add dummy syscalls so that we know what is needed (reports from users)


• style(9)


• linprocfs enhancements

Stephen Montgomery-Smith posted some patches for bsd.port.mk to the ports mailinglist to speed up the package dependency list creation. He did cut down the time from about 2min30sec (package dependency list of gnome2, tested on my system) to about 15-18sec. I enhanced this and now the time is down to about 12sec and a lot less programs to execute in the call (may be important on slow systems).

The patch for bsd.port.mk in my ports-patches directory contains more than only those improvements, the other part is not subject to submission yet.

If nobody finds some problems with the patch I will send it to GNATS and assign it to portmgr for inclusion into one of the next experimental ports builds.

• did meet nice people


• CAcert assuring was nice (1 of 3 assurer already gave some points to me, waiting for the rest to be able to be able to assure myself), now I know I have to get a new photo ID soon (expiry date)


• 10-15 people in my presentation, as there where not much people in total, this was ok/good enough for me


• not training a presentation at all is not a very good idea (I did know this already, but ENOTIME), but I was told it was ok


• having a laptop which exhibits sometimes some hardware problems will call for Murphy in any presentation more than once (thanks to Ulrich Spoerlein for jumping in with his own laptop, so I was able to continue)


• Oliver Herold (DesktopBSD) didn’t seem to have time to show up, so no minimal ex-classmate-meeting


• some photos (curtesy of Andreas Steinel)


• you can eat a good pizza at the FH in ZW


• I gave the remaining promotional material (a lot of flyers, a lot of FreeSBIE CDs and several FreeBSD 6.2 install CDs) to the UnixAG in ZW (thanks to Daniel Seuffert for providing all of this to me)


• I did not win the Cookbook for Geeks


• the 1822 Direkt Bank in Frankfurt (FFM) uses FreeBSD (and other nice Open Source stuff)


• latex-beamer is nice and easy (and was used for a lot of presentations on this day)

ZFS is there. Great! Thanks Pawel!

Now I wait a little bit until the first bugs are ironed out, and then I move all my stuff to it. The nice part: when you have 2 machines and everything you use is jailed, you just can do this without an “interruption of service” (or at least only with a very small one). Just move the jails to the other machine, replace the old FS with ZFS, and then move all jails back.

Yeah! Finally I got time to finish my work to put a desktop environment (in this case GNOME) into a jail. At least I have a proof of concept (I write this with firefox running in my “deskjail”). No, I don’t do this for additional security (there’s more security than in a non-jailed setup, but less security than in an ordinary jail, as you have to allow access to a lot more devices than in an ordinary jail), I do this for additional flexibility: Moving my desktop is now only the install of FreeBSD on a new machine and rsyncing the jail over to it. As the machine will also be a host of several jails where I have some common users with the same UID in each jail, I don’t pollute the jail-host with the desktop stuff and I have everything nicely separated.

Without a kernel patch and good devfs rules you will not get Xorg up and running in a jail (at least I didn’t managed to let it recognize my graphic card without the kernel patch). Now I have to beef up the patch a little bit and ask for review (it weakens up the security a little bit like the sysctl security.jail.sysvipc_allowed=1 or security.jail.allow_raw_sockets=1).

But first I have to finish the move of all my services I use at home to the jail-host now.