Package Details: cvmfs 2.9.4-1

Git Clone URL: https://aur.archlinux.org/cvmfs.git (read-only, click to copy)
Package Base: cvmfs
Description: A client-server file system implemented in FUSE and developed to deliver software distributions onto virtual machines in a fast, scalable, and reliable way.
Upstream URL: http://cernvm.cern.ch/portal/filesystem
Licenses: BSD
Submitter: bins
Maintainer: fsiegert (vandelli)
Last Packager: fsiegert
Votes: 10
Popularity: 0.000003
First Submitted: 2010-12-08 13:59 (UTC)
Last Updated: 2022-07-12 11:07 (UTC)

Pinned Comments

Latest Comments

vandelli commented on 2021-05-25 07:28 (UTC)

Hello @lfnister,

did you try rebuilding the cvmfs package? It should then link against the new protobuf library.

Ifnister commented on 2021-05-23 06:21 (UTC)

I get this error when trying to mount and then it fails:

CernVM-FS: running with credentials 969:969
CernVM-FS: loading Fuse module... failed to load cvmfs library, tried: './libcvmfs_fuse3.so' '/usr/lib/libcvmfs_fuse3.so' '/usr/lib64/libcvmfs_fuse3.so'
./libcvmfs_fuse3.so: cannot open shared object file: No such file or directory
libprotobuf-lite.so.26: cannot open shared object file: No such file or directory
libprotobuf-lite.so.26: cannot open shared object file: No such file or directory

There is only libprotobuf-lite.so.27 on my system.

fsiegert commented on 2021-03-16 15:56 (UTC)

@nikoladze Thanks for the report, I have pushed this as a (temporary) fix to AUR. It might be possible that you have to uninstall the system leveldb for cvmfs to pick up its own, I'm not sure.

nikoladze commented on 2021-03-15 14:18 (UTC) (edited on 2021-03-15 14:19 (UTC) by nikoladze)

I had some issues with the leveldb dependency after some recent update (got libcvmfs_fuse3.so: undefined symbol: _ZTIN7leveldb10EnvWrapperE). Adding leveldb back to the externals (in externals.patch) made it work again.

vandelli commented on 2020-11-04 13:13 (UTC)

Hello @fsiegert and @i.further,

see also:

https://github.com/wvandelli/cvmfs-aur/pull/1

Cheers Wainer

fsiegert commented on 2020-11-04 12:43 (UTC)

@i.further I think the /etc/auto.cvmfs file is only necessary if you want to use autofs. Is that what you want to do? As recommended in the post install message, systemd.automount seems to be working much more reliably: https://aur.archlinux.org/cgit/aur.git/tree/cvmfs.install?h=cvmfs#n10

In any case, the file still exists at /usr/lib/cvmfs/auto.cvmfs. The cvmfs installation does not seem to add the symlink to /etc automatically, so I'm not sure whether we should do it in the PKGBUILD either?

i.further commented on 2020-10-28 10:27 (UTC)

Hi it misses the /etc/auto.cvmfs

fsiegert commented on 2020-06-14 10:27 (UTC)

Thanks for the suggestion @ryuwd. This causes a lot of unused-variable warnings during compilation due to assert statements being optimised out, but I think it's still a change worth having. I've pushed this to the PKGBUILD now.

ryuwd commented on 2020-06-11 21:00 (UTC)

Hi, and thank you for providing this package. It works well.

I noticed in a recent install that CVMFS was not being compiled with optimisation (_FORTIFY_SOURCE warnings). CMake doesn't compile with optimisation as default, so I edited the PKGBUILD, and added this option to the CMake command in build():

-DCMAKE_BUILD_TYPE=Release

which added the desired optimisation flags when building. I wondered if this perhaps worth adding to the package?

Cheers, Ryun

dpm commented on 2017-08-16 16:33 (UTC)

Hi @vandelli, @fsiegert and @Bigben37, I reported it upstream https://sft.its.cern.ch/jira/browse/CVM-1362 Cheers, Davide

dpm commented on 2017-08-16 14:12 (UTC) (edited on 2017-08-16 16:31 (UTC) by dpm)

Hi @vandelli, I was looking exactly at line 44, because we have /etc/manjaro-release insted of /etc/arch-release. A quick fix could be something like that: 44 if (EXISTS /etc/arch-release or EXISTS /etc/manjaro-release) 45 set (ARCHLINUX TRUE) but I've never work with CMakeList ("or" or "OR" or other sign?) and also I would like to implement a sed command quite strong to pass future update of CMakeList.txt Cheers, Davide

vandelli commented on 2017-08-16 13:55 (UTC)

Hi @dpm, thanks for looking into this. While I believe this can be worked around in the PKGBUILD, perhaps it should also be reported upstream (https://sft.its.cern.ch/jira/projects/CVM/issues/)? The problem seems to originate around line 44 of the original CMakeList.txt file: 39 if (${CMAKE_SYSTEM_NAME} MATCHES "Linux") 40 set (LINUX TRUE) 41 if (EXISTS /etc/debian_version) 42 set (DEBIAN TRUE) 43 endif (EXISTS /etc/debian_version) 44 if (EXISTS /etc/arch-release) 45 set (ARCHLINUX TRUE) 46 endif (EXISTS /etc/arch-release) I assume /etc/arch-release does not exists in Manjaro, right? This causes Manjaro to be treated like a Redhat-like distribution. Cheers Wainer

dpm commented on 2017-08-16 13:17 (UTC)

Hi @fsiegert, I think that the problem comes from the CMakeList in cvmfs package, because Manjaro users fall in the section for other system where /usr/lib folder is the 32-bit one. In the following weeks, I could try to modify your PKGBUILD and mail it to you (Manjaro users have full access to AUR and for the next time you update the package I would like to have a smooth update) or even submit a pull request to GitHub repo. I'll see what to do. @Bigben37: nice workaround, simpler than mine! (I don't know if it could be dangerous remove the symlink from a such important folder, some other application could have a runtime error if access to it... I don't know) Cheers, Davide

Bigben37 commented on 2017-08-16 12:57 (UTC)

Hi @fsiegert and @dpm, I'm also running on Manjaro and had the same problem. In Manjaro /usr/lib64 is a symlink to /usr/lib, maybe this is the problem. My workaround was: - delete the /usr/lib64 symlink - install cvmfs - move the files installed in /usr/lib64 to /usr/lib - delete the /usr/lib64 directory - recreate the /usr/lib64->/usr/lib symlink

fsiegert commented on 2017-08-16 12:36 (UTC)

Hi @dpm, my /usr looks identically and I haven't seen this problem before and also have no idea where it should come from. So unless somebody on Arch encounters the same problem, I would suspect it's specific to Manjaro. Cheers, Frank

dpm commented on 2017-08-14 14:59 (UTC) (edited on 2017-08-14 16:38 (UTC) by dpm)

Hi @fsiegert and @vandelli, Thank you very much for mantaining this package! I've a problem installing it: error: failed to commit transaction (conflicting files) cvmfs: /usr/lib64 exists in filesystem I've seen that this should be already solved (comment of rajanandakumar 2016-01-28 11:55), but modified PKGBUILD doesn't work for me. Hint : with respect to rajanandakumar, I don't have the line 'cvmfs: /sbin exists in filesystem'. Addiotional info: I'm on Manjaro (Arch - based OS) and my /usr folder look like this: drwxr-xr-x 9 root root 4,0K 14 ago 16.22 . drwxr-xr-x 17 root root 4,0K 22 giu 10.31 .. drwxr-xr-x 5 root root 132K 14 ago 16.22 bin drwxr-xr-x 508 root root 68K 14 ago 16.22 include drwxr-xr-x 240 root root 224K 14 ago 16.22 lib drwxr-xr-x 30 root root 36K 13 ago 16.09 lib32 lrwxrwxrwx 1 root root 3 21 giu 16.44 lib64 -> lib drwxr-xr-x 13 root root 4,0K 7 giu 14.14 local lrwxrwxrwx 1 root root 3 21 giu 16.44 sbin -> bin drwxr-xr-x 342 root root 12K 14 ago 16.22 share drwxr-xr-x 3 root root 4,0K 14 ago 16.22 src Cheers, Davide EDIT: I managed to install package, modifying by hand CMakeList.txt line 113 ("lib64" to "lib") and 115 ("lib" to "lib32") and recompilying by means of your PKGBUILD after changing the md5sum for the pkg source. This CMakeList doesn't see Manjaro as Arch, so I've ended up in the section for Fedora, CentOS etc that probably have a different structure of /usr folder.

fsiegert commented on 2017-08-08 13:54 (UTC)

@Bigben37 Thanks for noticing this. I've fixed this typo without bumping the package version given that this doesn't change the installed files.

Bigben37 commented on 2017-08-08 13:21 (UTC)

Hi, thanks for providing this package :-) In cvmfs.install in line 10 a " is missing at the end. Because of this, the instructions in line 11 are not displayed properly. Cheers, Benjamin

fsiegert commented on 2017-07-09 20:39 (UTC)

@kgizdov: thanks for the hint, I have added the _netdev option to the mount command in the post-install message.

kgizdov commented on 2017-06-29 16:14 (UTC)

@kfinelli, that sounds more like Atlas scripts don't set the correct lib path to the ncurses version they used to compile ROOT against. If you set your environment from CVMFS and then do `ldd $(root-config --libdir)/*.so | grep -B 10 ncurses`, it will tell you whichever library (possibly libCling.so) does not find its dependency correctly.

kfinelli commented on 2017-06-29 12:04 (UTC)

This isn't directly related to the package, but might affect a lot of users- I noticed that in order to run ROOT as distributed on atlas cvmfs I needed to add the ncurses5-compat-libs from AUR. Another minor point is that the documentation link printed from cvmfs.install seems to be broken/out-of-date

kgizdov commented on 2017-06-26 21:21 (UTC)

Also, you should add `_netdev` as part of the mount options in `/etc/fstab`, otherwise you get a circular dependency on `network-online.target`. Check your `dmesg -l warn` output

kgizdov commented on 2017-06-25 13:39 (UTC)

@fsiegert, @vandelli, thanks for this - the systemd-mount works really nicely for me now. I think from now on that would be my default. I've tried AutoFS for other things before, but it never really worked correctly for me.

fsiegert commented on 2017-06-23 16:05 (UTC)

Thanks vandelli, that indeed seems to work great. I have pushed an updated PKGBUILD taking into account many of the suggestions from kgizdov (thanks!) and also the move to systemd.automount. When updating to that, please make sure you don't have any mounts from autofs left and also no directories created (manually) within /cvmfs. Let me know how this is working for you.

vandelli commented on 2017-06-23 06:00 (UTC)

Hi fsiegert, indeed I experienced similar problems with autofs. Eventually I kind of gave trying to understand the problem and instead started experimenting with systemd-automount. So far it works way better for me. This is what I added to /etc/fstab: atlas.cern.ch /cvmfs/atlas.cern.ch cvmfs noauto,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.idle-timeout=5min,x-systemd.device-timeout=10 0 0 This is on my laptop where I do not CVMFS mounted unless I'm using it, hence the noauto and x-systemd.idle-timeout=5min Cheers Wainer

fsiegert commented on 2017-06-22 14:16 (UTC)

Hi kgizdov, thanks a lot, that looks very nice, in particular since one of the built-in libs doesn't compile with gcc7 anymore! I had tried something similar before, and have encountered the following problem, which also happens with your PKGBUILD: Mounting directly (as root using "mount") works fine, but when I set up the autofs to mount automatically on demand, the mount doesn't succeed. Strangely enough this didn't happen when using the built-in libs, only when compiling against the system ones! This seems to be some kind of race condition between the cvmfs process trying to mount the originally requested directory, e.g. /cvmfs/sft.cern.ch, and another cvmfs process spawned automatically, trying to mount /cvmfs/cvmfs-config.cern.ch. In other words, the first "sft" cvmfs process tried to access a file in that "cvmfs-config" directory, thus triggering the second process. If I simply "ls /cvmfs/cvmfs-config.cern.ch" first, and only then access e.g. /cvmfs/sft.cern.ch, then autofs works fine, indicating in my view that there seems to be some conflict between the two simultaneous processes. Can you (or anybody else) reproduce this? I'd like to have a cvmfs package with automount working, so if you have any idea for a solution or workaround that would be great. I have also been thinking about whether switching to systemd.automount (https://wiki.archlinux.org/index.php/Fstab#Automount_with_systemd) might be an option, anybody have any experience with that? PS: Good point on the autofs dependency!

kgizdov commented on 2017-06-20 21:24 (UTC)

So I was playing around with this package and did some notable changes. Have a look here - https://github.com/kgizdov/cvmfs Significant changes: - do not use built-in packages, Arch already provides them - install the license properly - do not use 'libexec' folder as per Arch Packaging Standard, patch included - python-geoip.patch not needed when using Arch's python plugin - some stronger build options in settings.cmake specified - cvmfs_config does not require edits - include default.local in package and improve install message - do not auto configure autofs as it is not a dependency and not required for operation, give use info on install instead

rajanandakumar commented on 2016-02-01 17:34 (UTC)

Hi Frank, My apologies for the delay. It works fine now. Cheers, Raja.

fsiegert commented on 2016-01-28 13:21 (UTC)

Thanks rajanandakumar for letting me know about this. I was able to reproduce it, even though nothing in the package has changed in quite a while -- so I assume this must have been some external change which triggered this issue. Anyway, I have just pushed a new PKGBUILD which should take care of using the Arch-compatible directories instead of the two defaults (/usr/bin and /usr/lib instead of /sbin and /usr/lib64). Can you let me know whether that works for you now? Cheers, Frank

rajanandakumar commented on 2016-01-28 11:55 (UTC)

Hi, Trying to install it, I get error: failed to commit transaction (conflicting files) cvmfs: /sbin exists in filesystem cvmfs: /usr/lib64 exists in filesystem Errors occurred, no packages were upgraded. Any suggestions on how to go about fixing this? I did have a look at the various messages regarding this, dating back to 2013, but there seems to be none relevant here. Most seem to suggest that it needs to be fixed at the package level. Thanks and Cheers, Raja.

bins commented on 2014-06-06 17:31 (UTC)

hi Frank, yes, please, go ahead, adopt it :) thanks. -s

fsiegert commented on 2014-06-06 16:09 (UTC)

Hi Sebastien, Are you still working on the package or would you like to orphan it? I have an updated version for the current cvmfs release, which also takes care of some of the configuration steps automatically: http://fsiegert.web.cern.ch/fsiegert/tmp/cvmfs-2.1.19-1.src.tar.gz But I don't think I am allowed to upload it to AUR as long as you are the Maintainer. Cheers, Frank