Some of the source code files have the privilege of 444, which will cause an error when portage trying to delete them after the installation. Please fix these file privileges in prepare phase. Reproducible: Always
>>> Installing (1 of 1) app-shells/fzf-0.27.2::gentoo Process Process-3: Traceback (most recent call last): File "/home/xxxxx/gentoo/usr/lib/python3.9/site-packages/portage/package/ebuild/prepare_build_dirs.py", line 41, in prepare_build_dirs shutil.rmtree(clean_dir) File "/home/xxxxx/gentoo/usr/lib/python3.9/site-packages/portage/__init__.py", line 231, in __call__ rval = self._func(*wrapped_args, **wrapped_kwargs) File "/home/xxxxx/gentoo/usr/lib/python3.9/shutil.py", line 718, in rmtree _rmtree_safe_fd(fd, path, onerror) File "/home/xxxxx/gentoo/usr/lib/python3.9/shutil.py", line 655, in _rmtree_safe_fd _rmtree_safe_fd(dirfd, fullname, onerror) File "/home/xxxxx/gentoo/usr/lib/python3.9/shutil.py", line 655, in _rmtree_safe_fd _rmtree_safe_fd(dirfd, fullname, onerror) File "/home/xxxxx/gentoo/usr/lib/python3.9/shutil.py", line 655, in _rmtree_safe_fd _rmtree_safe_fd(dirfd, fullname, onerror) [Previous line repeated 3 more times] File "/home/xxxxx/gentoo/usr/lib/python3.9/shutil.py", line 675, in _rmtree_safe_fd onerror(os.unlink, fullname, sys.exc_info()) File "/home/xxxxx/gentoo/usr/lib/python3.9/shutil.py", line 673, in _rmtree_safe_fd os.unlink(entry.name, dir_fd=topfd) PermissionError: [Errno 13] Permission denied: 'grapheme.go' The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/home/xxxxx/gentoo/usr/lib/python3.9/multiprocessing/process.py", line 315, in _bootstrap self.run() File "/home/xxxxx/gentoo/usr/lib/python3.9/multiprocessing/process.py", line 108, in run self._target(*self._args, **self._kwargs) File "/home/xxxxx/gentoo/usr/lib/python3.9/site-packages/portage/util/_async/ForkProcess.py", line 156, in _bootstrap sys.exit(self._run()) File "/home/xxxxx/gentoo/usr/lib/python3.9/site-packages/portage/dbapi/_MergeProcess.py", line 193, in _run rval = mylink.merge(self.pkgloc, self.infloc, File "/home/xxxxx/gentoo/usr/lib/python3.9/site-packages/portage/dbapi/vartree.py", line 1752, in wrapper return f(self, *args, **kwargs) File "/home/xxxxx/gentoo/usr/lib/python3.9/site-packages/portage/dbapi/vartree.py", line 5372, in merge retval = self.treewalk(mergeroot, myroot, inforoot, myebuild, File "/home/xxxxx/gentoo/usr/lib/python3.9/site-packages/portage/dbapi/vartree.py", line 4229, in treewalk prepare_build_dirs(settings=self.settings, cleanup=cleanup) File "/home/xxxxx/gentoo/usr/lib/python3.9/site-packages/portage/package/ebuild/prepare_build_dirs.py", line 53, in prepare_build_dirs _raise_exc(oe) File "/home/xxxxx/gentoo/usr/lib/python3.9/site-packages/portage/util/install_mask.py", line 150, in _raise_exc raise wrapper portage.exception.PermissionDenied: [Errno 13] Permission denied: 'grapheme.go' >>> Failed to install app-shells/fzf-0.27.2, Log file: >>> '/home/xxxxx/gentoo/var/tmp/portage/app-shells/fzf-0.27.2/temp/build.log'
Created attachment 736303 [details, diff] Patch for dependency permission issue Hi, I can't reproduce it. Plus, the file in question 'grapheme.go' belongs to a dependecy specified in `EGO_SUM`. Specifically `github.com/rivo/uniseg`. If someone else is having the same issue, we can apply this patch. It should make sure that the folder containing the go dependencies has write permission for the user. ``` --- /var/db/pkg/app-shells/fzf-0.27.2/fzf-0.27.2.ebuild2021-08-26 21:36:42.359540985 +0200 +++ /data/projects/fzf-0.27.2.ebuild 2021-08-27 22:00:26.128394819 +0200 @@ -61,6 +61,7 @@ src_prepare() { default sed -i 's/-s -w //' Makefile || die # bug 795225 + chmod -R u+w "${HOME}"/go/pkg/mod/ } src_compile() { ```
Thank you for your reply Raffaele. Unfortunately the patch you add does not work. The problem is not in the Makefile. I found that for a normal Gentoo install, the file privilege of downloaded mod files are 644. But for a prefix install, the privilege becomes 444 and it causes the problem. This is not limited to one file (graphene.go), but applies to all the mod files. I guess you are testing it in a non-prefix install, which does not have this problem. If you test it in a prefix, you can reproduce it.
I found an upstream issue linked to it, https://github.com/golang/go/issues/27161 I actually was surprised that the go elass works in normal Gentoo install.
According this issue's comments, I suggest to add the option "modcacherw" to the go command. diff -Naur a/eclass/go-module.eclass b/eclass/go-module.eclass --- a/eclass/go-module.eclass> 2021-08-28 13:18:31.559603453 -0400 +++ b/eclass/go-module.eclass> 2021-08-28 13:18:09.274383078 -0400 @@ -387,7 +387,7 @@ > # This will print 'downloading' messages, but it's accessing content from > # the $GOPROXY file:/// URL! > einfo "Tidying go.mod/go.sum" -> go mod tidy >/dev/null +> go mod tidy -modcacherw >/dev/null - > # This used to call 'go get' to verify by fetching everything from the main > # go.mod. However 'go get' also turns out to recursively try to fetch
Sorry there are some additional symbols in the previous comment. Please use the following patch. It works in my prefix install. diff -Naur a/eclass/go-module.eclass b/eclass/go-module.eclass --- a/eclass/go-module.eclass 2021-08-28 13:18:31.559603453 -0400 +++ b/eclass/go-module.eclass 2021-08-28 13:18:09.274383078 -0400 @@ -387,7 +387,7 @@ # This will print 'downloading' messages, but it's accessing content from # the $GOPROXY file:/// URL! einfo "Tidying go.mod/go.sum" - go mod tidy >/dev/null + go mod tidy -modcacherw >/dev/null # This used to call 'go get' to verify by fetching everything from the main # go.mod. However 'go get' also turns out to recursively try to fetch
Hi Chang, Thanks for the research, it looks like it is more a generic problem with go packages with a custom prefix. I will try to replicate tonight after work. Also because I am considering two other possibilities: * Using `go clean -modcache` * Applying `-modcacherw` only if it is a prefix installation Plus, I would expect a lot of other go packages to fail for the same reason when installed in a prefix.
Hi Chang, I can't replicate it. Please provide the command you run and the configuration you are running. Plus, if there is a problem due to the implementation of `go mod tidy` I would expect that you face the same issue for all other go packages. Please let us now if you see the same problem with other go packages.
Hi Raffaele, Thank you. I got several Gentoo Prefix installation and they all have the same issue. They are installed on RHEL 8. What environment of Gentoo Prefix did you test on? Can you please look at the output of ls -lR ~/gentoo/var/tmp/portage/app-shells/fzf/ ? In my case there are a lot of files showing 444 privileges. This problem appears for all the go packages.
Also, this problem is for Gentoo Prefix user without root privilege.
I created a different bug for the go-module.eclass: https://bugs.gentoo.org/812977 We can probably close this one and mark it as duplicate.
I agree. Please close it.
*** This bug has been marked as a duplicate of bug 812977 ***
