[OpenAFS-devel] FreeBSD 11.2 support, and some questions on /usr/ports/net/openafs

[Måns Nilsson]

Hi,

FreeBSD 11.1 is EOL as of 2018-09-30, so I've done some naive tinkering
to get openafs 1.8.2 to build on FreeBSD 11.2. I do get things to build
by creating

src/config/param.i386_fbsd_112.h
src/config/param.amd64_fbsd_112.h

from their 11.1 siblings and just upping the digits. In addition,

I put in a new line: (again just upping the numbers)

#define SYS_NAME_ID_amd64_fbsd_112 3042

in src/config/afs_sysnames.h. The resulting source tree builds. When I
"make install", and copy the kernel module to the current kernel moddir,
jury-rig an /usr/local/etc/openafs/*, a cache-dir and start script, etc,
(all those bits untouched from the 10.x port) and run the startscript,
I get a working AFS client.

I have copied the source tree into AFS from local disk, and rebuilt it
in AFS using this client. File server is local to me (same rack and GE
networking) and everything feels snappy and usable.

If this is useful to the community at large I can work on getting a
patch submitted. (There is that git learning curve; this lazy sysadmin
is still on RCS mostly...)

As for ports packaging, I've played around by just substituting bztarball
names and checksums and removing patches that are rejected because a
lot has changed since 1.6.22. By patching and adding files per above
I get a build that goes through. A number of files are missing or are
orphans for the install and package steps, though; "make check-orphans"
is quite upset. Again, this surely is because of the large changes.

I'm tempted to just recreate the plist and re-add the various bits needed.
My main question here, though, is if I'm clumsily recreating something
better done elsewhere.

Please advise.

[Benjamin Kaduk]

Post by MÃ¥ns Nilsson
Hi,
FreeBSD 11.1 is EOL as of 2018-09-30, so I've done some naive tinkering
to get openafs 1.8.2 to build on FreeBSD 11.2. I do get things to build
by creating
src/config/param.i386_fbsd_112.h
src/config/param.amd64_fbsd_112.h
from their 11.1 siblings and just upping the digits. In addition,
I put in a new line: (again just upping the numbers)
#define SYS_NAME_ID_amd64_fbsd_112 3042

Adding "support" for a new OS version is usually that simple, yes :)

Post by MÃ¥ns Nilsson
in src/config/afs_sysnames.h. The resulting source tree builds. When I
"make install", and copy the kernel module to the current kernel moddir,
jury-rig an /usr/local/etc/openafs/*, a cache-dir and start script, etc,
(all those bits untouched from the 10.x port) and run the startscript,
I get a working AFS client.
I have copied the source tree into AFS from local disk, and rebuilt it
in AFS using this client. File server is local to me (same rack and GE
networking) and everything feels snappy and usable.
If this is useful to the community at large I can work on getting a
patch submitted. (There is that git learning curve; this lazy sysadmin
is still on RCS mostly...)

Creating the param.h files/etc. is not a huge amount of work, so I won't
explicitly ask you to check out
https://wiki.openafs.org/devel/GitDevelopers/ and submit the patch to
gerrit, but on the other hand if someone else does it that makes getting it
merged into openafs.git easier.

Post by MÃ¥ns Nilsson
As for ports packaging, I've played around by just substituting bztarball
names and checksums and removing patches that are rejected because a
lot has changed since 1.6.22. By patching and adding files per above
I get a build that goes through. A number of files are missing or are
orphans for the install and package steps, though; "make check-orphans"
is quite upset. Again, this surely is because of the large changes.

Indeed, there's quite a bit that changed between 1.6 and 1.8; the Debian
packaging got quite a bit of a rewrite as well.

Post by MÃ¥ns Nilsson
I'm tempted to just recreate the plist and re-add the various bits needed.
My main question here, though, is if I'm clumsily recreating something
better done elsewhere.

I don't know of any other efforts in this vein, and it does seem that
recreating the plist and such from scratch would be lower effort than going
at it incrementally. I do note that the 1.8 kernel module build should not
need the workarounds in the port Makefile to run config(8) and get the
kernel headers, since we are using bsd.kmod.mk natively now.

Please feel to submit a bug against the FreeBSD ports tree if you get
something in place that looks nice, and my apologies for being something of
an absentee port maintainer...

-Ben