You are not logged in.
Hi,
I seem to be having problems with many packages from AUR. Most install fine, but many - which used to work fine - now don't. The error being:
==> Entering fakeroot environment...
fakeroot: FAKEROOTKEY set to 1453438524
fakeroot: nested operation not yet supported
For some reason makepkg enters a fakeroot environment twice (nested). I can compile the source manually, however I'm at a loss why this happens with makepkg and how to make the actual package (this also happens with aurutils, but of course I just tried with makepkg to rule out aurutils issues).
Curiously, one of the packages which triggered this is aurutils-git; however, after a few retries, it succeeded, without any changes on my part in between!
Another of the packages causing this is perl-mojolicious.
There are others, however they escape my mind / evade the error ATM. I will list them here once I encounter some (unless the cause is found and is generic).
Before someone asks: I am not running (makepkg) in a chroot myself.
Here is a complete log of my attempt running makepkg on the perl-mojolicious PKGBUILD. We can see fakeroot is actually run twice (nested)!
makepkg.conf
Any ideas?
Last edited by Wild Penguin (2020-07-22 14:01:28)
Offline
Fixed it after some trial-and-error.
I believe the culprit is these two lines:
/usr/share/makepkg/tidy/zipman.sh: line 50: files: bad array subscript
/usr/share/makepkg/tidy/zipman.sh: line 51: files[$inode]: bad array subscript
Why it fails, I'm not exactly sure. I did have my .cache (which aurutils uses) and, coincidentally, a subdirectory I was using for storing the PKGBUILD, symlinked elsewhere from my home directory.
Thinking maybe some part of that script does not like the symlink, I changed away to a directory which does not have a symlinked directory anywhere in it's path. Result: makepkg (and the said script) works now.
Marking as [SOLVED]!
Though, maybe there is still a bug, as I believe the script should not in fail under these conditions; as in "symlinks anywhere in a directory tree with PKGBUILD causes a failure with zipman.sh". Workaround: don't store PKGBUILDs under symlinks.
TL;DR: "symlinks anywhere in a directory tree with PKGBUILD causes a failure with zipman.sh"
Offline
I don't think symlinks themselves should matter as that section of code works on inodes. Did your symlinks go across filesystems? I could imagine that causing the errors you described.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
I don't think symlinks themselves should matter as that section of code works on inodes. Did your symlinks go across filesystems? I could imagine that causing the errors you described.
Yes, it did. I used symlinks to move large directories away from an SSD. The other FS is still ext4 (as is the homedir).
Last edited by Wild Penguin (2020-07-22 15:07:18)
Offline