Custom Query (2425 matches)

This is either a bug in cmake or cvmfs. Not sure.

here what I'm doing: built combo V00-00-03 first against py3-v4.1.0 into cmvfs/user /cvmfs/icecube.opensciencegrid.org/users/blaufuss/combo/V00-00-03/build then tried the parasitic build issue: cmake was not properly getting the PYTHON_INCLUDES etc into the parasitic workspace and builds fail immediately (can find Python.h)

I stepped back from py3-v4.1.0 to py3-v4.0.1 and built: /cvmfs/icecube.opensciencegrid.org/users/blaufuss/combo/V00-00-03/build2 and now things work fine they're different versions of cmake (3.16 vs 3.11) and python but this is a bit puzzling

I have been using a virtual environment to provide: python 3 (as /usr/bin/env python) needed libraries.

(note: virtualenv is made using cvmfs v3-v4.0.1 python toolset

I generate the vritualenv first, and from the virtual env, I run cmake to ensure I'm getting python 3.

But after build, when I try to run, libraries added to my local virtualenv are not available.

'which python' shows ./build/bin/python, which is a symlink to the original python in cvmfs and not the virtualenv one as it should be.

This breaks all scripts that need libs from the virtual env.

A work around is to delete the ./build/bin/python

• Is this even needed any longer?
• If is it, can we make it respect the virtualenv python that was there at cmake time?

Clsim server uses a ZMQ unix socket to communicate. Unix sockets are limited to roughly 100 characters of absolute path length by the kernel. Some sites are exceeding this length (specifically, UMD).

A workaround is needed for deeper directories. Maybe UDP/TCP on localhost?