error: Symlink points to BuildRoot

[pfischermx]

I tried to see if this was reported but couldn't. Also already tried with QA_SKIP_BUILD_ROOT=1 and strip_binaries: false

Config:
{
"extensions": {
"enabled": [
"python_venv",
"blocks"
]
},
"core": {
"group": "Application/System",
"license": "MIT",
"name": "some-rpm-package-name",
"summary": "short package summary",
"version": "1.2.3"
},
"python_venv": {
"require_setup_py": false,
"name": "name_of_venv_dir_to_create",
"path": "/path/where/to/install/venv",
"strip_binaries": false
},
"blocks": {
"desc": [
"some long package description",
"each array element is a new line"
]
}
}

Error:
...
Successfully installed PyYAML-3.13 certifi-2018.10.15 chardet-3.0.4 gevent-1.3.7 greenlet-0.4.15 grequests-0.3.0 idna-2.7 pprint-0.1 requests-2.20.1 urllib3-1.24.1

• cd -
  /tmp/rpmvenv4y1Ddb/BUILD
• find /tmp/rpmvenv4y1Ddb/BUILDROOT/some-rpm-package-name-1.2.3-1.x86_64 -name RECORD -exec rm -rf '{}' ';'
• venvctrl-relocate --source=/tmp/rpmvenv4y1Ddb/BUILDROOT/some-rpm-package-name-1.2.3-1.x86_64//path/where/to/install/venv/name_of_venv_dir_to_create --destination=//path/where/to/install/venv/name_of_venv_dir_to_create
• /usr/lib/rpm/check-buildroot
• /usr/lib/rpm/redhat/brp-compress
• /usr/lib/rpm/redhat/brp-strip /usr/bin/strip
• /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
• /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
• /usr/lib/rpm/redhat/brp-python-hardlink
• /usr/lib/rpm/redhat/brp-java-repack-jars
  Processing files: some-rpm-package-name-1.2.3-1.x86_64
  error: Symlink points to BuildRoot: /path/where/to/install/venv/name_of_venv_dir_to_create/lib64 -> /tmp/rpmvenv4y1Ddb/BUILDROOT/some-rpm-package-name-1.2.3-1.x86_64/path/where/to/install/venv/name_of_venv_dir_to_create/lib

RPM build errors:
Symlink points to BuildRoot: /path/where/to/install/venv/name_of_venv_dir_to_create/lib64 -> /tmp/rpmvenv4y1Ddb/BUILDROOT/some-rpm-package-name-1.2.3-1.x86_64/path/where/to/install/venv/name_of_venv_dir_to_create/lib
There was an error generating the RPM.
The exit code was: 1.
The rpmbuild command was: rpmbuild -ba --define='_topdir /tmp/rpmvenv4y1Ddb' /tmp/rpmvenv4y1Ddb/SOURCES/package.spec.

This is on Centos7

$ rpmbuild --version
RPM version 4.11.3

The command I'm using is:
QA_SKIP_BUILD_ROOT=1 rpmvenv ./foo.config.json --verbose

Any ideas?

[kevinconway]

This would appear to be related to a virtualenv feature that attempts to map any files generated in /lib64 to /lib.

By default, the --always-copy flag is passed to virtualenv in order to prevent symlinks from being created between /lib64 and /lib. Your sample doesn't show it, but if your configuration is using any custom flags then you would need to re-add the --always-copy entry to prevent symlinks.

If it's not the flags then there are also a number of bugs related to this topic in the virtualenv issue tracker. Problems associated with the /lib64--/lib split seem to be recurring with each large release. From what I can tell, the 15.1 release is including in the epel-release repositories for Centos 7 under python-virtualenv. It might be good to try installing either a later or earlier version of virtualenv to see if there was a regression at some point.

[pfischermx]

Yeah I forgot to mention that I'm not using the virtualenv that comes with the OS. I installed it straight with pip.

$ rpm -qa | grep virtualenv | wc -l
0
$ pip list | grep virtualenv
virtualenv 16.1.0
$ virtualenv --version
16.1.0

and I know for a fact that it is only using the virtualenv module from /usr/local/lib (from pip).

$ ls -lah /tmp/rpmvenv_EVcg_/BUILDROOT/some-rpm-package-name-1.2.3-1.x86_64/path/where/to/install/venv/name_of_venv_dir_to_create/
total 4.0K
drwxr-xr-x. 5 pfischer users 56 Nov 29 09:41 .
drwxr-xr-x. 3 pfischer users 40 Nov 29 09:41 ..
drwxr-xr-x. 2 pfischer users 4.0K Nov 29 09:42 bin
drwxr-xr-x. 4 pfischer users 35 Nov 29 09:42 include
drwxr-xr-x. 3 pfischer users 23 Nov 29 09:41 lib
lrwxrwxrwx. 1 pfischer users 123 Nov 29 09:41 lib64 -> /tmp/rpmvenv_EVcg_/BUILDROOT/some-rpm-package-name-1.2.3-1.x86_64/path/where/to/install/venv/name_of_venv_dir_to_create/lib

Also added the --always-copy to the configuration.

• virtualenv --always-copy /tmp/rpmvenv_EVcg_/BUILDROOT/some-rpm-package-name-1.2.3-1.x86_64//path/where/to/install/venv/name_of_venv_dir_to_create

[pfischermx]

Ahh... this might be related to pypa/virtualenv#1248 - Will try to use the previous version.

[pfischermx]

Ah yes that was it. However with the previous version (1.16.0) I shouldn't use --always-copy since seems it is a bit odd/broken with Centos7 per: pypa/virtualenv#565

[kevinconway]

It's funny that you mention 565 because it was also mentioned in #56 . The interesting thing about #56 was that it could be resolved by rebuilding Python rather than using the system Python. I still don't fully understand what makes the system Pythons for Centos, Fedora, and RedHat so different from whatever assumption virtualenv is making that they don't work out of the box. This issue doesn't appear to affect Debian based distributions.

It can also be frustrating that the nature of the /lib64 symlinks has flipped multiple times from relative to absolute paths and that the functionality of --always-copy seems to regress so often. It's similar to #48 where the manylinux project binaries don't work well with standard tools like strip. There's, unfortunately, not much I can do about it from this project.

I'm happy you were able to find a version of virtualenv that works for you. If it continues to be problematic, rebuilding Python from source appears to be a more holistic fix for folks experiencing /lib64 related issues.

[sharksforarms]

@pfischermx Do you mean 16.0.0? virtualenv==16.0.0 works for me.