new package: cvmfs

[Crivella]

WIP

Adding the cvmfs client to termux to allow mounting CVMFS remote filesystems.

Currently only feature the client part of it.

This would allow access to a vast variety of repositories with data and/or software stacks

Main drive for this (from my side) is to get EESSI to work on android. Currently able to mount it and tha from a termux-chroot environment run a few of the demos from https://github.com/EESSI/eessi-demo

Potential issues:

• SOLVED: when cvmfs compiles its external pacparser dependency, it needs to generate an executable that than writes some header files. This will also dump the length of certain sizeofs into the generated files. When cross-compiling this executable needs to be runnable on the build host, but if the bitness differs between host and target, the compilation will fail afterward due to a precompiler check that the sizeof is what is expected.

[TomJo2000]

I think we can definitely consider this package for a packaging policy exception under the "scientific software" (e.g. TERMUX_PKG_GROUPS="science") category.

[Crivella]

Thanks for looking into this this quick! Will do more of the style fixes tomorrow form my WS.

Sorry for not opening a package request beforehand should've definitely done that.

I think we can definitely consider this package for a packaging policy exception under the "scientific software" (e.g. TERMUX_PKG_GROUPS="science") category.

That would be nice. At the end of things i guess this would fall in a similar category to nfs-utils as it is a tool to mount filesystems. In this case (AFAIK) they are mostly used to ship data/software in HPC environment and similar.

Also was keeping this as a draft to se if the CVMFS developers would like to chime in on this PR. We are also exploring to see if there would be the possibility to use this without needing to access /dev/fuse so it could be used from a simple proot environment without needed to actually do the mounting from tsu

[TomJo2000]

cvmfs isn't something I'd ever heard of before, but such it is with a lot of scientific software I support.

I don't think it should be dismissed out of hand just because it doesn't neatly fit within our standard relevancy criteria.

If someone from upstream wants to chime in packaging feedback is always appreciated and we try not to ship packages in a way their upstream has disapproved of.

[Crivella]

The builds on 32 bit systems seems to both be hitting the problem i described as a potential issue

when cvmfs compiles its external pacparser dependency, it needs to generate an executable that than writes some header files. This will also dump the length of certain sizeofs into the generated files. When cross-compiling this executable needs to be runnable on the build host, but if the bitness differs between host and target, the compilation will fail afterward due to a precompiler check that the sizeof is what is expected.

I am really unsure on how to solve that as the sizeofs in the generated headers ends up not matching the checks in the pre-compiler asserts

[robertkirkman]

The builds on 32 bit systems seems to both be hitting the problem i described as a potential issue

when cvmfs compiles its external pacparser dependency, it needs to generate an executable that than writes some header files. This will also dump the length of certain sizeofs into the generated files. When cross-compiling this executable needs to be runnable on the build host, but if the bitness differs between host and target, the compilation will fail afterward due to a precompiler check that the sizeof is what is expected.

I am really unsure on how to solve that as the sizeofs in the generated headers ends up not matching the checks in the pre-compiler asserts

I am going to debug that next and I will let you know if I know how to solve it or not

[Crivella]

@TomJo2000

That isn't gonna work for the 32 bit architectures. But I don't have good answer for what you'd do about it. ${TERMUX_ARCH_BITS} should be available in the environment during buildtime, so that could be used here. That will be either 64 or 32 depending on the bitness of the architecture.

Basically the external source of sha3 contains 3 subfolders (64opt 64compact 32BI) that are selected by setting ARCH=XXX to the XXX subfolder with different source files.

The default of 64opt was failing for missing headers if i recall correctly. Using 64compact i was able to compile sha3 also on i686 but i can't test the linking + execution due to the error not allowing to compile pacparser https://github.com/termux/termux-packages/pull/27139#issuecomment-3501466803

EDIT: Was able to test i686 after the changes suggested in https://github.com/termux/termux-packages/pull/27139#issuecomment-3501649407 and it seems that the 64compact sources also work there

[robertkirkman]

The builds on 32 bit systems seems to both be hitting the problem i described as a potential issue

when cvmfs compiles its external pacparser dependency, it needs to generate an executable that than writes some header files. This will also dump the length of certain sizeofs into the generated files. When cross-compiling this executable needs to be runnable on the build host, but if the bitness differs between host and target, the compilation will fail afterward due to a precompiler check that the sizeof is what is expected.

I am really unsure on how to solve that as the sizeofs in the generated headers ends up not matching the checks in the pre-compiler asserts

I am going to debug that next and I will let you know if I know how to solve it or not

This changeset appears to enable 32-bit support in your package. Please let me know if you have any questions about it.

diff --git a/root-packages/cvmfs/0032-pass-socklen_t-to-accept.patch b/root-packages/cvmfs/0032-pass-socklen_t-to-accept.patch
new file mode 100644
index 0000000000..f54e922d7d
--- /dev/null
+++ b/root-packages/cvmfs/0032-pass-socklen_t-to-accept.patch
@@ -0,0 +1,17 @@
+Fixes error
+mount/mount.cvmfs.cc:222:24: error: no matching function for call to 'accept'
+note: candidate function not viable: no known conversion from 'unsigned int *'
+to 'socklen_t * _Nullable' (aka 'int *') for 3rd argument
+when building for 32-bit Android
+
+--- a/mount/mount.cvmfs.cc
++++ b/mount/mount.cvmfs.cc
+@@ -218,7 +218,7 @@ static int GetExistingFuseFd(const string &fqrn, const string &workspace,
+   int fuse_fd = -1;
+   if (result == "OK") {
+     struct sockaddr_un addr;
+-    unsigned int len = sizeof(addr);
++    socklen_t len = sizeof(addr);
+     const int con_fd = accept(recv_sock_fd,
+                               reinterpret_cast<struct sockaddr *>(&addr), &len);
+     fuse_fd = RecvFdFromSocket(con_fd);
diff --git a/root-packages/cvmfs/build.sh b/root-packages/cvmfs/build.sh
index 62694a779b..2633c7fffa 100644
--- a/root-packages/cvmfs/build.sh
+++ b/root-packages/cvmfs/build.sh
@@ -32,16 +32,16 @@ TERMUX_PKG_EXTRA_CONFIGURE_ARGS="
 -DLibArchive_LIBRARY=$TERMUX_PREFIX/lib/libarchive.so
 -DSPARSEHASH_INCLUDE_DIR=$TERMUX_PREFIX/include/sparsehash
 
--DLEVELDB_INCLUDE_DIR=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH}/include
--DLEVELDB_LIBRARIES=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH}/lib/libleveldb.a
--DPACPARSER_INCLUDE_DIR=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH}/include
--DPACPARSER_LIBRARY=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH}/lib/libpacparser.a
--DVJSON_INCLUDE_DIRS=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH}/include
--DVJSON_LIBRARIES=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH}/lib/libvjson.a
--DSHA3_INCLUDE_DIRS=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH}/include
--DSHA3_LIBRARIES=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH}/lib/libsha3.a
--DLibcrypto_INCLUDE_DIRS=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH}/crypto/include
--DLibcrypto_LIBRARIES=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH}/crypto/lib/libcrypto.a
+-DLEVELDB_INCLUDE_DIR=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH/arm/armv7-a/}/include
+-DLEVELDB_LIBRARIES=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH/arm/armv7-a/}/lib/libleveldb.a
+-DPACPARSER_INCLUDE_DIR=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH/arm/armv7-a/}/include
+-DPACPARSER_LIBRARY=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH/arm/armv7-a/}/lib/libpacparser.a
+-DVJSON_INCLUDE_DIRS=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH/arm/armv7-a/}/include
+-DVJSON_LIBRARIES=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH/arm/armv7-a/}/lib/libvjson.a
+-DSHA3_INCLUDE_DIRS=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH/arm/armv7-a/}/include
+-DSHA3_LIBRARIES=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH/arm/armv7-a/}/lib/libsha3.a
+-DLibcrypto_INCLUDE_DIRS=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH/arm/armv7-a/}/crypto/include
+-DLibcrypto_LIBRARIES=$TERMUX_PKG_SRCDIR/externals_install.${TERMUX_ARCH/arm/armv7-a/}/crypto/lib/libcrypto.a
 "
 
 termux_step_pre_configure () {
@@ -57,4 +57,10 @@ termux_step_pre_configure () {
 	export CLANG_TARGET_TRIPLE="${TERMUX_HOST_PLATFORM}${TERMUX_PKG_API_LEVEL}"
 	export TERMUX_STANDALONE_TOOLCHAIN
 	export LDFLAGS
+
+	patch="$TERMUX_PKG_BUILDER_DIR/crosscompile-pacparser.diff"
+	echo "Applying patch: $(basename "$patch")"
+	test -f "$patch" && sed \
+		-e "s%\@TERMUX_ARCH_BITS\@%${TERMUX_ARCH_BITS}%g" \
+		"$patch" | patch --silent -p1
 }
diff --git a/root-packages/cvmfs/0002-crosscompile-pacparser.patch b/root-packages/cvmfs/crosscompile-pacparser.diff
similarity index 96%
rename from root-packages/cvmfs/0002-crosscompile-pacparser.patch
rename to root-packages/cvmfs/crosscompile-pacparser.diff
index dc725a5a33..802c5304e0 100644
--- a/root-packages/cvmfs/0002-crosscompile-pacparser.patch
+++ b/root-packages/cvmfs/crosscompile-pacparser.diff
@@ -77,7 +77,7 @@ index 55b1a95c5..3acb323d2 100755
  [ -d $static_result_dir ] && rm -fR $static_result_dir
  make $FIX_PYTHON -C src clean -j ${CVMFS_BUILD_EXTERNAL_NJOBS}
 -make $FIX_PYTHON $FIX_COMP CVMFS_BASE_C_FLAGS="$CVMFS_BASE_C_FLAGS" -j1 -C src pacparser.o spidermonkey/libjs.a  # default target runs tests!
-+make $FIX_PYTHON $FIX_COMP CVMFS_BASE_C_FLAGS="$CVMFS_BASE_C_FLAGS" CC="clang" -j1 -C src pacparser.o spidermonkey/libjs.a  # default target runs tests!
++make $FIX_PYTHON $FIX_COMP CVMFS_BASE_C_FLAGS="$CVMFS_BASE_C_FLAGS" CC="clang -m@TERMUX_ARCH_BITS@" -j1 -C src pacparser.o spidermonkey/libjs.a  # default target runs tests!
  echo "finished internal build of libpacparser"
  
  echo "creating static link library for libpacparser..."

I have not tested it at runtime on 32-bit devices beyond very basic trivial invocations, like this. Would you like to test it yourself (which is possible to do on some phones that are otherwise 64-bit by installing the 32-bit ARM build of Termux APK), or would you like me to try to test it? If you would like me to try to test it on one of my 32-bit devices, would it be not too much trouble for you to write some test scripts I could run that you think would effectively test the functionality of the package on 32-bit devices?

~ $ cvmfs2 -V
CernVM-FS version 2.13.3

~ $ uname -a
Linux localhost 3.4.112-Lineage-g716f00ee2e8 #1 SMP PREEMPT Sun Oct 13 11:16:54 CDT 2019 armv7l Android
~ $ 

[Crivella]

This changeset appears to enable 32-bit support in your package. Please let me know if you have any questions about it.

Thank you very much. Will try to test it, but also do not mind adding some test scripts

[Crivella]

@robertkirkman Again thanks for the help on the 32 bit it is compiling and working now

I've been using eessi for testing as this is the platform i work on, but we can also use atlas from the docs of CVMFS

so you wont need the extra public key found in https://github.com/EESSI/filesystem-layer/releases/download/latest/cvmfs-config-eessi_latest_all.deb

This is the edited config file i use

CVMFS_CACHE_BASE=/data/data/com.termux/files/home/cache
CVMFS_RELOAD_SOCKETS=/data/data/com.termux/files/home/cache
CVMFS_USYSLOG=/data/data/com.termux/files/home/cache/cvmfs.log
CVMFS_CLAIM_OWNERSHIP=yes
CVMFS_SERVER_URL=http://cvmfs-stratum-one.cern.ch/cvmfs/atlas.cern.ch
CVMFS_KEYS_DIR=/data/data/com.termux/files/usr/etc/cvmfs/keys/cern.ch
CVMFS_HTTP_PROXY=DIRECT

and you can mount it whit this set of commands (starting from home)

~> mkdir cache
~> mkdir atlas
~> tsu

TSU ~> ls atlas
# empty dir
TSU ~> cvmfs2 -o config=atlas.conf atlas.cern.ch `realpath atlas`
TSU ~> ls atlas
#  repo  test1
TSU ~> cat atlas/test1
#  test

[robertkirkman]

Currently only feature the client part of it.

I was kind of wondering "why does it need to have -DBUILD_SERVER=OFF?"

so, I set -DBUILD_SERVER=ON and compiled it, and I started to fix all the errors that happened.

Here is what I made so far, which makes it completely build with -DBUILD_SERVER=ON:

patch swissknife_sync.cc

libandroid-glob does not support GLOB_ONLYDIR or GLOB_PERIOD,
if the software does not work as a result of removing references to them,
then it means that the software is unfortunately only implemented for glibc
and cannot be used with bionic yet.

--- a/cvmfs/swissknife_sync.cc
+++ b/cvmfs/swissknife_sync.cc
@@ -376,7 +376,7 @@ void swissknife::CommandApplyDirtab::DetermineNestedCatalogCandidates(
     // state
     const std::string &glob_string = i->pathspec.GetGlobString();
     const std::string &glob_string_abs = union_dir_ + glob_string;
-    const int glob_flags = GLOB_ONLYDIR | GLOB_NOSORT | GLOB_PERIOD
+    const int glob_flags = GLOB_NOSORT
                            | GLOB_ALTDIRFUNC;
     glob_t glob_res;
     g_glob_uniondir = new std::string(union_dir_);

Patch acl.cc

Fix error: use of undeclared identifier 'htole16'

--- a/cvmfs/acl.cc
+++ b/cvmfs/acl.cc
@@ -10,6 +10,7 @@
 #include <cassert>
 #include <cstring>
 #include <vector>
+#include <sys/endian.h>
 
 #include "util/posix.h"
 

Add PACKAGES+=" cpio" to scripts/setup-ubuntu.sh

(and to test that temporarily without rebuilding the docker container, scripts/run-docker.sh bash -c "sudo apt update && sudo apt install -y cpio" can be used)

Add maxminddb; to -DBUILTIN_EXTERNALS_LIST

Add libandroid-glob to TERMUX_PKG_DEPENDS and -landroid-glob to LDFLAGS

Put this bulk-patcher command in termux_step_pre_configure()

(it does not patch all other absolute paths that would need to be patched to run the server, but it gets all that are necessary to complete the build without build errors)

	find "${TERMUX_PKG_SRCDIR}" -type f | \
		xargs -n 1 sed -i \
		-e "s|/usr/share|$TERMUX_PREFIX/share|g" \
		-e "s|/etc/logrotate|$TERMUX_PREFIX/etc/logrotate|g" \
		-e "s|/var|$TERMUX_PREFIX/var|g" \
		-e "s|/tmp|$TERMUX_PREFIX/tmp|g"

However, much more additional changes and complicated setup might be required, I'm not sure what else is needed but it would probably be a lot. In particular, there is an incredibly huge script called cvmfs_server, it is filled with absolute paths, I am sure more absolute paths would probably need to be patched, in order to create a completely runnable server setup.

If you are interested in progressing towards that also, then let me know and I might try to help more with any parts that are difficult for you to fix.

[Crivella]

I was kind of wondering "why does it need to have -DBUILD_SERVER=OFF?"

Mainly because I was mostly interested in the client functionalities, but also to deal with the problems with one branch of the build at a time. I guess the usecases of running a CVMFS server from a phone might be less than that of mounting an existing FS, but can give it a shot. Not 100% sure, but i do not think anything root specific should be required for hosting so that might also get its separate package in the non root- repo

[robertkirkman]

Mainly because I was mostly interested in the client functionalities, but also to deal with the problems with one branch of the build at a time. I guess the usecases of running a CVMFS server from a phone might be less than that of mounting an existing FS, but can give it a shot.

yes that's ok, one reason I thought to try it is because you mentioned that you used a termux-chroot installation for part of your test, and I wondered if maybe compiling with -DBUILD_SERVER=ON and making it work, could hypothetically allow removing the requirement for termux-chroot.

If it's too difficult to make work correctly then it can stay disabled.

Not 100% sure, but i do not think anything root specific should be required for hosting so that might also get its separate package in the non root- repo

In my opinion, based on the precedent set by many previous packages, if the package has major functionality that works without root, but other functionality that requires root, the whole package should be in the packages folder instead of the root-packages folder, while packages that are completely useless without root remain in the root-packages folder.

The reason I have been following that practice is because, if I were to find packages that have some functionality that requires root and start moving them into the root-packages folder, a huge number of packages currently in the packages folder would have to be moved to the root-packages folder instead, so in order for there to be some logical consistency to the organization of the packages, it seems to make the most sense to keep root-packages for packages that are completely useless without root.

[Crivella]

The termux-chroot is specific to EESSI, as all the software that comes from it is rpathed to /cvmfs/software.eessi.io which is the default location you get when using automount, but i would not say it is something specific to cvmfs itself.

Anyway might give it a try especially if we can get the upstream dev interested, we are in contact on the EESSI slack

[boegel]

I'd say @vvolkl is the main contact for the CernVM-FS development team currently. Maybe @jblomer (former project lead for CernVM-FS) is also interested...