Package Details: openafs 1.8.7-1

Git Clone URL: (read-only, click to copy)
Package Base: openafs
Description: Open source implementation of the AFS distributed file system
Upstream URL:
Licenses: custom:"IBM Public License Version 1.0"
Conflicts: openafs-features
Submitter: None
Maintainer: Bevan
Last Packager: Bevan
Votes: 61
Popularity: 0.007988
First Submitted: 2006-02-01 17:18
Last Updated: 2021-01-15 08:34

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 ... Next › Last »

totsilence commented on 2017-10-23 17:13

I can reproduce the linking issue as well. It is related to missing "LINES" symbol which is part of in our ncurses package and -ltinfo is missing in some linker commands. When adding -ltinfo things build. Probably another patch to openafs autotools files is required.

Bevan commented on 2017-10-23 16:57

Mmh.. I think we are actually having two different issues here:

1) Infinite loop on configure: For some reason this seems to only occur on some systems. I cannot reproduce it. However, thanks to totsilence there is a patch which I now applied to all three openafs packages.

2) Linking error when trying to build openafs. This issue I can reproduce and it only occurs when building the openafs package. The module packages build fine. Unfortunately, the curses patch does not fix this issue although the error points into a similar direction (maybe the latest ncurses update?) So this is still unfixed...

kgizdov commented on 2017-10-23 09:18

Yes, indeed. It filled up my SSD twice yesterday... I was able to build it by manually waiting and killing the process, so the compilation can continue. What's strange is that it builds on my desk PC fine with the same exact environment. Interesting...

totsilence commented on 2017-10-23 08:33

Bevan, kgizdov: Yes, I need that patch to compile the kernel module. I don't know yet at which point this patched became necessary, but it's definetely required here: Otherwise ./configure goes into an infinite loop (it calls the "/usr/bin/yes") and "make.log" in the dkms build folder grows infinitely - I stopped it at 12 GB size.

Bevan commented on 2017-10-23 07:42

kgizdov: Could be related to the issue addressed here:

I will try to reproduce this later today.

kgizdov commented on 2017-10-22 23:53

stopped building for me:

[ yes != "" ] || case amd64_linux26 in \
alpha_dux*|sgi_*|sun*_5*|rs_aix*|*linux*|hp_ux11*|ia64_hpux*|*[nof]bsd*) \
cd src && cd tptserver && make all ;; \
*_darwin_[1-6][0-9]) \
echo Not building MT ptserver for amd64_linux26 ;; \
*_darwin_*) \
cd src && cd tptserver && make all ;; \
*) \
echo Not building MT ptserver for amd64_linux26 ;; \
set -x; \
if test "-lncurses"; then \
cd src && cd gtx && make all ; \
else \
echo Not building gtx, because no curses-headers found. ; \
+ test -lncurses
+ cd src
+ cd gtx
+ make all
make[3]: Entering directory '/home/gizdov/Packages/builds/openafs/src/openafs-'
gcc -o gtxtest gtxtest.o libgtx.a /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- -lncurses -lresolv
/usr/bin/ld: libgtx.a(curseswindows.o): undefined reference to symbol 'LINES'
/usr/lib/ error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:179: gtxtest] Error 1
make[3]: Leaving directory '/home/gizdov/Packages/builds/openafs/src/openafs-'
make[2]: *** [Makefile:350: gtx] Error 2
make[2]: Leaving directory '/home/gizdov/Packages/builds/openafs/src/openafs-'
make[1]: *** [Makefile:694: build] Error 2
make[1]: Leaving directory '/home/gizdov/Packages/builds/openafs/src/openafs-'
make: *** [Makefile:39: all_nolibafs] Error 2

Ethyling commented on 2017-09-14 14:01

@Bevan thanks

darkxsun commented on 2017-09-13 15:52

caddar: for more context, note than AUR packages assume base-devel is installed (including patch)

caddar commented on 2017-09-13 11:35

Yes and no. The hint with the AUR helper helped to resolved the problem - I tried to build the package manually and got an error complaining about missing command 'patch'... I use pacaur, and it seems it somehow doesn't complain or at least properly propagate the error that the patch was found, but never applied due to missing patch-utility.

After installing 'patch' everything worked, both manually and with the AUR helper. Thanks for the hint, should have known myself to try it manually...

Bevan commented on 2017-09-13 11:22

caddar: The fact that the error still occurs in line 109 shows that the patch has not been applied. Otherwise it would have to be line 112. I double checked that the patch should be applied in the PKGBUILD, though. I therefore guess there is some kind of caching problem. A wild guess: Was there still an old src directory lying around before you ran makepkg? Or are you maybe using some AUR helper that caches package sources? I did not increase pkgrel because the compiled result does not change by applying the patch but this may confuse AUR helpers.