Category Archives: FreeBSD ports collection

Ascertaining installed ports for a specific architecture

When upgrading from one major version of FreeBSD to another, in my case from FreeBSD/amd64 stable/9 to FreeBSD/amd64 stable/10, it’s customary to upgrade the installed ports afterwards, beginning with ports-mgmt/pkg.

I forcefully upgraded all installed ports using portupgrade -afpv, but the upgrade of lang/ruby21 failed miserably.

I removed all traces of Ruby 2.1, i.e. ports-mgmt/portupgrade and databases/ruby-bdb, before manually compiling and installing lang/ruby21, databases/ruby-bdb, and ports-mgmt/portupgrade using the ports collection.

Now, I needed to know which remaining ports were still compiled for stable/9. The following snippet allowed me to gather the origins of such ports:

pkg query -a %o:%q | grep freebsd:9: | cut -d : -f 1

Now, I could feed that list to the newly installed portupgrade and upgrade the remaining ports:

portupgrade -fprv `pkg query -a %o:%q | grep freebsd:9: | cut -d : -f 1`

In the end, I should have removed lang/ruby21 completely after upgrading ports-mgmt/pkg, and reinstalled ports-mgmt/portupgrade manually using the ports collection. Only then is it safe to forcefully rebuild and reinstall all the other ports. Don’t forget to add devel/cvs if you used to rely on cvs in base, and adjust all references from /usr/bin/cvs to /usr/local/bin/cvs.

Upgrading lang/php5 to lang/php56

The 20150220 entry in /usr/ports/UPDATING contains no instructions for upgrading lang/php5 to lang/php56, at least not for us compiling our own ports.

I learned the hard way using portupgrade what needs to be done. I have summarised my steps into the script below. Use the script as a guide, and if you do run my script, then you’re on your own. To save you some effort, here’s the script ready for downloading. Continue reading Upgrading lang/php5 to lang/php56

Running dns/bind910 within a chroot after r382109

dns/bind910 gained native chroot support in r382109. Those of us who used to store the BIND files in /var/named/etc/namedb and ran BIND with /var/named as the chroot environment, must do five things:

  1. Rename the /var/named directory to something else, like /var/Named. This is to avoid upsetting make -C /usr/src delete-old and still retain the meaning of the directory’s name.
  2. Rename the /var/Named/etc/namedb directory to /var/Named/usr/local/etc/namedb.
  3. Edit /var/Named/usr/local/etc/namedb/named.conf to reflect that the BIND files now resides in /usr/local/etc/namedb, as seen from within the chroot environment.
  4. Change the appropriate line in /etc/rc.conf to read named_chrootdir="/var/Named".
  5. Restart BIND using /usr/local/etc/rc.d/named restart, or start BIND using /usr/local/etc/rc.d/named start if the former fails.

Missing chroot for dns/bind9{9,10}?

The removal of BIND from base in stable/10 left us with the option of running BIND from ports either in a jail, or as an ordinary service. The old BIND in base was able to run in a chroot environment, isolated from the rest of the system.

Some of us believe a chroot is a good compromise between running BIND as an unisolated service or in a jail. I personally believe the removal of /etc/namedb and /var/named as part of make delete-old is premature, as most of us would like to continue keeping all BIND related files in /var/named/etc/namedb.

Harald Schmalzbauer has been kind enough to recreate a chroot environment for dns/bind910. I guess the same patches can be used for dns/bind99 with some minor tweaking.

Take a look at Harald’s contribution if you feel a jail is too much work for a simple service like DNS. Continue reading Missing chroot for dns/bind9{9,10}?

Solving conflicts between print/texlive-base and devel/tex-kpathsea

The 20141214 entry in ports/head/UPDATING says:

AFFECTS: users of TeXLive

Several scripts in print/texlive-base have been moved to devel/tex-kpathsea. Upgrading them can fail because texlive-base depends on tex-kpathsea, and the new ex-kpathsea tries to install files which were installed by the old texlive-base. The following error message indicates this situation:

pkg-static: tex-kpathsea-6.2.0_1 conflicts with texlive-base-20140525_3 (installs files into the same place). Problematic file: /usr/local/bin/kpsewhere

To solve this problem, remove both of tex-kpathsea and texlive-base first and install the new versions:

# pkg delete -f tex-kpathsea texlive-base

The above is a bit drastic, at least for us who build our own ports. These two portupgrade commands gets the job done, albeit with some overhead:

portupgrade -fprv print/texlive-base
portupgrade -fprv devel/tex-kpathsea

gettext 0.19.3 in FreeBSD

devel/gettext, as of version 0.19.3, has been split into three ports:

  1. devel/gettext, the meta-port depending the two next ports;
  2. devel/gettext-runtime, the runtime libraries; and
  3. devel/gettext-tools, the tools for managing the message catalogs.

In my case, as I build my own ports, making the transition required manual intervention using both portupgrade and the ports collection tree:

portupgrade -fpvo devel/gettext-runtime gettext
cd /usr/ports/devel/gettext-tools && make && make install && make package && make clean
cd /usr/ports/devel/gettext && make && make install && make package && make clean
portupgrade -fprvx gettext -x gettext-runtime -x gettext-tools devel/gettext-runtime

AMANDA 3.3.2 and #undef bool

I upgraded a stable/8 i386 system and switched from lang/perl5.16 to lang/perl5.20 only to experience problems with swig generated code for AMANDA. I have confirmed this behaviour on stable/9 amd64 too.

I found 17 files containing these three lines:

#ifdef bool
#undef bool

This results in error messages such as:

Amanda/Application.c: In function 'SWIG_AsCharPtrAndSize':
Amanda/Application.c:1580: error: 'bool' undeclared (first use in this function)
Amanda/Application.c:1580: note: each undeclared identifier is reported only once for each function it appears in
Amanda/Application.c:1580: error: expected ':' before numeric constant

Continue reading AMANDA 3.3.2 and #undef bool

Local slave port for emulators/virtualbox-ose-additions without OpenGL and X11

I have a bunch of FreeBSD VMs running in VirtualBox. They all share a number of virtual harddrives, and among them are a virtual harddrive with the common contents of /var/db/ports.

My ports configuration of emulators/virtualbox-ose-additions have the OPENGL and X11 options set. This is useless on some of my simpler VMs, as those VMs have no need for any X11 ports, but they could sure benefit from having the VirtualBox additions installed. These simpler VMs are usually used only to test ZFS in FreeBSD in various configurations.

I could juggle the settings for emulators/virtualbox-ose-additions for each time I’m updating the VirtualBox additions port on my VMs, but I decided to create a local slave port disabling the OPENGL and X11 options. Maybe this port, with the necessary tweaking, could sit among its siblings in the official emulators category.


MASTERDIR=	${.CURDIR}/../../emulators/virtualbox-ose-additions
.include "${MASTERDIR}/Makefile"


COMMENT=	VirtualBox additions for FreeBSD guests without OPENGL and X11


PKGNAMESUFFIX=	-additions-nox11



For now you must copy the /var/db/ports/local_virtualbox-ose-additions-additions-nox11/options file to /var/db/ports/emulators_virtualbox-ose-additions-additions-nox11/options, or else dialog4ports(1) will keep nagging you until kingdom come.

I guess this problem stems from early processing of as done by the master Makefile at a time when the CATEGORIES variable was set to emulators.