OpenBSD

The OpenBSD project produces a FREE, multi-platform 4.4BSD-based UNIX-like operating system.

• My commit statistcs, with pretty graphs and stuff.
• Ports I maintain
• What I have been working on recently
• Porting stuff to do
• Machines I own and their dmesg

• OpenBSD Journal
• OpenPorts
• Stable Packages
• CVS via Web
• The FAQ
• CVS statistics, in general and by developer.
• A fast UK OpenBSD Mirror.
• OpenBSD Mirror Status Reports
• OpenBSD Kernel Internals (slides)

Things to check before posting to ports@

• pkg/DESCR is `fmt -72` formatted.
• `make port-lib-depends-check` is happy
• “VAR=” syntax is consistent in port Makefile
• Did you check if there was a regression test?
• Look in the packing list for ”.desktop” and “share/mime” and add RUN_DEPENDS on desktop-utils and/or shared-mime-data respectively if needed. Each also requires some @exec magic. See audio/audacity for examples.
• Does it build on non-common arches? Sparc64 is a good test.
• Is USE_LIBTOOL needed?
• Can you think of any programs needed at runtime for RUN_DEPENDS?

MAKE_FLAGS =            INSTALL='/usr/bin/install -c' \
                        INSTALL_PROGRAM='/usr/bin/install -c -s -m 555' \
                        INSTALL_DATA='/usr/bin/install -c -m 644'

Sometimes MAKE_ENV screws up the regression tests. In such cases copy (from bsd.port.mk) the regress target example and remove the “env -i ${MAKE_ENV}” part. At the time of writing I had to to do this kind of thing:

# MAKE_ENV hoses the regression test, so we do this manually
do-regress:
        cd ${WRKSRC} && ${MAKE_PROGRAM} ${ALL_REGRESS_FLAGS} \
                -f ${MAKE_FILE} ${REGRESS_TARGET} ${REGRESS_LOG}

“USE_GMAKE = Yes” is likely to fix this. Damned GNUisms.

• apply the patch WITHOUT -E
• find . -name '*.orig' | xargs rm
• find . -size 0 | xargs cvs delete -f
• cvs up | grep '?' | awk '{print $2}' | xargs cvs add
• run 'cvs up' and examine output.
• cvs -dcvs.openbsd.org:/cvs commit

• To see the compiler command line in cmake configure like 'cmake -DCMAKE_VERBOSE_MAKEFILE=ON .'
• The config.log alternative in Cmake is CmakeFiles/CMakeErrorLog.log and CMakeFiles/CMakeOutput.log.
• To re-configure fully, remove the cache file CMakeCache.txt.
• To add link flags, use 'set( CMAKE_REQUIRED_FLAGS -L/some/dir )'
• If cmake adds the wrong separator for rpath flags, I have seen the hack:

string( REPLACE ";" " " FLAGS_REPLACED "${IMLIB2_LDFLAGS}" )
set( CMAKE_REQUIRED_FLAGS "${FLAGS_REPLACED}" )

These are *potential* ideas for things which I think could be improved in OpenBSD. Ya, ya, talk is cheap. Think of this as my rainy day list of stuff I may attempt to do (assuming by some miracle theres a day where I'm not busy).

The BSD amd implementation is dated and hard to configure.

A new one with a simple config file would be far better.

Worst case scenario, make the old one support NFSv3. NFSv2 does not support files >4GB.

Make the hotplug daemon notice CDROM insertion and mount it automatically? It's a misnomer, as no real hardware is added when a CDROM is inserted. Also, how would un-mounting work?

Something similar to solaris' nwamd (network auto-magic daemon), where the daemon sits about monitoring network devices (both wired and wireless) and connects them when they are plugged in or a known wireless network is in range (and it's key if any is supplied in the config file). It should also notice cables becoming unplugged and networks going out of range, and look for alternative network connectivity.

I guess this would mean moving all of the functions apart from main() from ifconfig.c into another file (complete with header), so that we can call them from the new ifconfigd? I'm no expert…

If the above ever happend, perhaps a GUI will be born to sit in system tray of netwm compatible WM's, or maybe someone can modify the gnome network tool to interface with this?