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

[Benjamin Kaduk]

On Sun, Nov 25, 2018 at 09:41:29AM +0100, Måns Nilsson wrote:
> 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 :)

> 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.

> 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.

> 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