Package Details: openafs 1.8.13.2-1

Git Clone URL: https://aur.archlinux.org/openafs.git (read-only, click to copy)
Package Base: openafs
Description: Open source implementation of the AFS distributed file system
Upstream URL: http://www.openafs.org
Licenses: IPL-1.0
Conflicts: openafs-features
Submitter: None
Maintainer: Bevan
Last Packager: Bevan
Votes: 61
Popularity: 0.000000
First Submitted: 2006-02-01 17:18 (UTC)
Last Updated: 2025-01-31 19:25 (UTC)

Latest Comments

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

Bevan commented on 2020-07-08 21:38 (UTC) (edited on 2020-07-08 21:38 (UTC) by Bevan)

@nickoe: I had another look and I think there is not much we can do about that. The source code contains the __FILE__ macro in many places and the build system is written in a way that the source code location is given as absolute path to the compiler. It's mostly a cosmetic warning. A possible consequence is that certain error messages contain the path where the openafs package was built.

nickoe commented on 2020-07-07 11:52 (UTC)

@Bevan, ok no worries. I noticed this in a couple of packages by now. Maybe it is a new check that has been added to makepkg.

Bevan commented on 2020-07-07 11:38 (UTC)

@nickoe: Yes, for some reason the paths to some of the source files are included in those binaries / libraries. So far I just ignored this phenomenon - it does not really hurt. But I will see if I can find the root cause for this and if it is easily avoidable.

nickoe commented on 2020-07-07 11:30 (UTC)

I got this warning when building:

==> WARNING: Package contains reference to $srcdir
usr/lib/librokenafs.so.2.0.0
usr/lib/libuafs_pic.a
usr/lib/openafs/upclient
usr/lib/openafs/buserver
usr/lib/openafs/upserver
usr/lib/libuafs.a
usr/lib/libafshcrypto.so.2.0.0
usr/bin/bosserver
usr/bin/uss
usr/bin/tokens.krb
usr/bin/bos
usr/bin/bos_util
usr/bin/pagsh.krb
usr/bin/scout
usr/bin/fs
usr/bin/backup

darkxsun commented on 2020-04-06 22:22 (UTC)

@dmaxter Not needed. See https://wiki.archlinux.org/index.php/Arch_User_Repository:

Note: Packages in the AUR assume that the base-devel group is installed, i.e. they do not list the group's members as build dependencies explicitly.

dmaxter commented on 2020-04-06 21:31 (UTC) (edited on 2020-04-06 21:32 (UTC) by dmaxter)

Missing dependencies: automake and autoconf

drslmr commented on 2017-11-24 14:02 (UTC)

Hi, I had some issue concerning ypbind together with logging into my afs account where I have my home directory under afs. See https://github.com/systemd/systemd/issues/7074#issuecomment-344290625. In the above communication there was one workaround suggested to give the appropriate privileges to the login process, which works for me. But the better option would be to use nscd or sssd instead of yp. Does anyone have any experience using nscd or sssd with logging into an afs account?

drslmr commented on 2017-11-06 13:06 (UTC)

Unfortunately I could not find out what exactly caused my recent issue. But from a former snapshot of my installation that did not have the issue it was possible to upgrade to today's state. And now the issue is gone.

drslmr commented on 2017-11-04 09:50 (UTC) (edited on 2017-11-04 09:50 (UTC) by drslmr)

Bevan, thanks a lot for your effort. I'm sorry for taking your time. On a different machine I did update openafs and linux to 4.13.11-1-ARCH and I can not reproduce the problem. Too, on my ill machine I can still use an older snapshot of an complete arch installation without the reported issue. So I guess something went wrong during upgrading. I remember that at some point during post installation hook my disk ran out of space. I think it was due to openafs-modules-dkms. I removed parts of /var/vache and tried to reinstall every package again. But still something is wrong. It's my problem. Thanks again.

Bevan commented on 2017-11-03 14:05 (UTC)

drslmr: This sounds more like an issue with your AFS cell to me. If it's not, I guess it would be an upstream bug as I don't think we touch any code that's relevant for that. Can you try to debug this with your cell provider? I did a small test in a local test cell and it worked as expected with kernel 4.13.10-1-ARCH and the current openafs packages: 1. Created a user for an IP range: 192.168.1.0 2. Created a group containing this user named localnet 3. Set ACLs for a folder to only allow access by group localnet 4. Within this directory I created another folder only accessible for my authenticated user Without a token I could access the folder from step 3 from my local network and after obtaining a token I could also enter the folder from step 4. One thing that does not work is giving the IP-based user (i.e. 192.168.1.0) permissions via ACLs. This is on purpose and documented in http://docs.openafs.org/Reference/1/fs_setacl.html.

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