Package Details: cvmfs 2.13.3-2

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: vandelli
Votes: 16
Popularity: 0.69
First Submitted: 2010-12-08 13:59 (UTC)
Last Updated: 2026-01-29 16:38 (UTC)

Pinned Comments

ktht commented on 2025-09-30 18:12 (UTC)

@DiV21dSREL I had almost the exact same issue: after the Manjaro update on 29/09/25 I was unable to access /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase, although its parent directory was accessible. After a fair bit of debugging (rebuilding cvmfs with debug symbols; setting CVMFS_HTTP_TRACING=on and specifying CVMFS_DEBUGLOG in /etc/cvmfs/default.local), it finally clicked for me that the offending package must be curl, as it got stuck waiting for the response from cvmfs servers. It also lines up with the fact that curl was upgraded from version 8.15 to 8.16 with the Manjaro update. After downgrading curl to version 8.15 (with sudo manjaro-downgrade curl if you're on Manjaro), I was able to access cvmfs just like before the update.

I also ran git bisect between tags 8.15 and 8.16 in the curl repo to figure out the commit that broke cvmfs. The offending commit happens to be this one, which is part of this PR. Following the discussion there, it seems that the PR introduced a regression in curl, which effectively caused it to run into a deadlock in some scenarios (cf this issue for details). The bug was fixed 2 weeks ago, and the problem is now gone with the current master branch. So we'll just have to wait for the next release of curl.

TLDR: downgrade curl to version 8.15; skip 8.16; wait for version 8.17.

Latest Comments

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

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

QuantumDancer 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

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