The current versions (even in ~arch) are only compatible with kernel 4.20 and older. This is quite ancient (december 2018), while 1.8.6 supports up 5.7. Reproducible: Always
marking as major, because limitation to the old kernel renders the package unusable for most users.
In case it helps speed things up, this is how I managed to build openafs-1.8.6: I used the patches from `https://dev.gentoo.org/~bircoph/afs/` with `PVER=20190106` like in the previous version, but removed the following files from that patchset: 000_all_p20181001.patch, 001_all_compiler-settings.patch The compiler settings don't need to be needed anymore, and the 000 patch looks like an update between the released version and some later git version. The systemd units were broken due to some quoting issues, so I fixed those: -ExecStartPre=/bin/sh -c "/bin/mkdir -p \\\"$(cut -d \\\':\\\' -f 2 /etc/openafs/cacheinfo)\\\"" +ExecStartPre=/bin/sh -c "/bin/mkdir -p $(cut -d ':' -f 2 /etc/openafs/cacheinfo)" I just tested with some files in my afs homedir on /afs/cern.ch/ but AFAICT it works fine, both for public files and for private one (w/ kerberos auth). Since I don't run an afs server I did not test anything server-related. I would attach an ebuild but since the changes are minor and mostly in the external patches that wouldn't be particularly helpful...
*don't seem to be needed damn typos and not being able to edit comments... ;x
*** Bug 696296 has been marked as a duplicate of this bug. ***
(In reply to Adrian from comment #2) > 001_all_compiler-settings.patch > The compiler settings don't need to be needed anymore, and the 000 patch > looks like an update between the released version and some later git version. This is wrong, because the idea of the patch is that toolchain components must use AC_CHECK_TOOL instead of AC_CHECK_PROGS, because they may be prefixed, e.g. x86_64-pc-linux-gnu-ar instead of ar. Users of toolchain built with USE="-native-symlinks" or non-gcc compilers may have their builds broken with AC_CHECK_PROGS being used. Though this patch was not hard to port. > The systemd units were broken due to some quoting issues, so I fixed those: > -ExecStartPre=/bin/sh -c "/bin/mkdir -p \\\"$(cut -d \\\':\\\' -f 2 > /etc/openafs/cacheinfo)\\\"" > +ExecStartPre=/bin/sh -c "/bin/mkdir -p $(cut -d ':' -f 2 > /etc/openafs/cacheinfo)" I fixed this in both units. But be aware that systemd support in openafs (and my other packages) is on as-is basis: I don't use systemd myself even on test setups, so its support is mostly third-party (upstream, user patches, etc). > I just tested with some files in my afs homedir on /afs/cern.ch/ but AFAICT > it works fine, both for public files and for private one (w/ kerberos auth). > Since I don't run an afs server I did not test anything server-related. I don't run AFS server as well, though np-hardass uses them afaik.
(In reply to Andrew Savchenko from comment #5) > (In reply to Adrian from comment #2) > > 001_all_compiler-settings.patch > > The compiler settings don't need to be needed anymore, and the 000 patch > > looks like an update between the released version and some later git version. > > This is wrong, because the idea of the patch is that toolchain components > must use AC_CHECK_TOOL instead of AC_CHECK_PROGS, because they may be > prefixed, e.g. x86_64-pc-linux-gnu-ar instead of ar. Users of toolchain > built with USE="-native-symlinks" or non-gcc compilers may have their builds > broken with AC_CHECK_PROGS being used. > > Though this patch was not hard to port. > > > The systemd units were broken due to some quoting issues, so I fixed those: > > -ExecStartPre=/bin/sh -c "/bin/mkdir -p \\\"$(cut -d \\\':\\\' -f 2 > > /etc/openafs/cacheinfo)\\\"" > > +ExecStartPre=/bin/sh -c "/bin/mkdir -p $(cut -d ':' -f 2 > > /etc/openafs/cacheinfo)" > > I fixed this in both units. But be aware that systemd support in openafs > (and my other packages) is on as-is basis: I don't use systemd myself even > on test setups, so its support is mostly third-party (upstream, user > patches, etc). > > > I just tested with some files in my afs homedir on /afs/cern.ch/ but AFAICT > > it works fine, both for public files and for private one (w/ kerberos auth). > > Since I don't run an afs server I did not test anything server-related. > > I don't run AFS server as well, though np-hardass uses them afaik. I had run AFS servers. I had some server problems a while back and never got the cluster back up and running. Currently without functioning AFS here.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d9e3fbc9f8f1990ab161537c1e0ce3658489f20d commit d9e3fbc9f8f1990ab161537c1e0ce3658489f20d Author: Andrew Savchenko <bircoph@gentoo.org> AuthorDate: 2020-09-13 09:40:58 +0000 Commit: Andrew Savchenko <bircoph@gentoo.org> CommitDate: 2020-09-13 09:47:49 +0000 net-fs/openafs: update to 1.8.6 - Version bump to 1.8.6, this fixes many bugs, - including CVE-2019-1860{1..3}. - Update to the latest upstream stable 1_8_x branch, which fixes more bugs and bring kernel 5.9 support. - Migrate to tmpfiles eclass. - Fix build with USE=tsm. - Fix systemd unit files, thanks Adrian <adrian@planetcoding.net> for suggestion. - Fix doxygen dep. Bug: https://bugs.gentoo.org/719136 Closes: https://bugs.gentoo.org/680944 Closes: https://bugs.gentoo.org/686488 Closes: https://bugs.gentoo.org/706738 Closes: https://bugs.gentoo.org/736160 Closes: https://bugs.gentoo.org/740630 Package-Manager: Portage-3.0.6, Repoman-3.0.1 Signed-off-by: Andrew Savchenko <bircoph@gentoo.org> net-fs/openafs/Manifest | 3 + net-fs/openafs/openafs-1.8.6.ebuild | 343 ++++++++++++++++++++++++++++++++++++ 2 files changed, 346 insertions(+)
(In reply to Adam Feldman from comment #6) > (In reply to Andrew Savchenko from comment #5) > > (In reply to Adrian from comment #2) > > > 001_all_compiler-settings.patch > > > The compiler settings don't need to be needed anymore, and the 000 patch > > > looks like an update between the released version and some later git version. > > > > This is wrong, because the idea of the patch is that toolchain components > > must use AC_CHECK_TOOL instead of AC_CHECK_PROGS, because they may be > > prefixed, e.g. x86_64-pc-linux-gnu-ar instead of ar. Users of toolchain > > built with USE="-native-symlinks" or non-gcc compilers may have their builds > > I don't run AFS server as well, though np-hardass uses them afaik. > > I had run AFS servers. I had some server problems a while back and never > got the cluster back up and running. Currently without functioning AFS here. I can run some server tests (since it's something I do for my openafs upstream work anyway). I'll also take a quick scan through the patches and see which ones I can try to pull upstream. The AC_CHECK_PROGS vs AC_CHECK_TOOL I think I can get pulled in).
(In reply to Cheyenne Wills from comment #8) > I can run some server tests (since it's something I do for my openafs > upstream work anyway). Thanks this will be appreciated. > I'll also take a quick scan through the patches and see which ones I can try > to pull upstream. The AC_CHECK_PROGS vs AC_CHECK_TOOL I think I can get > pulled in). Nice! Please also take a look at 0014-xbsa.patch: it fixes plain build issue: when tsm support is enabled (#define xbsa in OpenAFS code), the `struct butx_transactionInfo butxInfo` gets defined twice: in butc/butc_xbsa.h and butc/lwps.c which leads to linker failure, so I fixed this by using exterm in lwps.c.
(In reply to Andrew Savchenko from comment #9) > (In reply to Cheyenne Wills from comment #8) > > I can run some server tests (since it's something I do for my openafs > > upstream work anyway). > > Thanks this will be appreciated. > > > I'll also take a quick scan through the patches and see which ones I can try > > to pull upstream. The AC_CHECK_PROGS vs AC_CHECK_TOOL I think I can get > > pulled in). > > Nice! > > Please also take a look at 0014-xbsa.patch: it fixes plain build issue: when > tsm support is enabled (#define xbsa in OpenAFS code), the `struct > butx_transactionInfo butxInfo` gets defined twice: in butc/butc_xbsa.h and > butc/lwps.c which leads to linker failure, so I fixed this by using exterm > in lwps.c. Yes I saw that. I think there might be some more that I can pull in. Some of the patches appear to be a site specific (e.g. afsauthent-symbols, and the vserver patch come to mind). Some are gentoo specific. But yes the tsm patch I can probably push upstream. Though I won't be able to test it since I don't have access to a tsm server.
Oh.. just a heads up. A 1.8.7 will be going into pre-1 "real soon now". Also an "experimental" branch 1.9.x will be starting soon. I believe the plan for 1.9.x is for getting some development level features out for the public to test then a more stable version will follow the 1.9.x after some of the ideas are shaken out in 1.9.x. I believe that the 1.6.x series at this point is probably only going to receive security fixes or a possible bug fix -- but at this point new OS levels or fixes for newer compiler levels do not seem to be accepted. I believe that the 1.8.x series at this point is viewed as the current stable release and will continue to get updates (new OS levels, compiler stuff, bug fixes, etc.) -- though I'm not sure what type of new features will be accepted into 1.8.x. With newer levels of kerberos you need to be aware that if you are using DES types of encryption for your server keys you will probably need to rekey your servers.
