Created attachment 692484 [details] build.log The patch process appears to be broken on this system (MacBookAir3.1). It runs gnome-wayland but the failure occurs even when gnome is not running ('systemctl disable gdm' and reboot). The issue can be highlighted by using ebuild on librsvg as an example: CODE jplx-airgn2 /usr/portage/gnome-base/librsvg # ebuild librsvg-2.50.3.ebuild clean jplx-airgn2 /usr/portage/gnome-base/librsvg # ls /var/tmp/portage/ jplx-airgn2 /usr/portage/gnome-base/librsvg # ebuild librsvg-2.50.3.ebuild prepare * librsvg-2.50.3.tar.xz BLAKE2B SHA512 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking librsvg-2.50.3.tar.xz to /var/tmp/portage/gnome-base/librsvg-2.50.3/work >>> Source unpacked in /var/tmp/portage/gnome-base/librsvg-2.50.3/work >>> Preparing source in /var/tmp/portage/gnome-base/librsvg-2.50.3/work/librsvg-2.50.3 ... * Disabling deprecation warnings ... [ ok ] * Running elibtoolize in: librsvg-2.50.3/ * Portage patch failed to apply (ltmain.sh version 2.4.6)! * Please file a bug report to add a proper patch. * ERROR: gnome-base/librsvg-2.50.3::gentoo failed (prepare phase): * eltpatch failed * * Call stack: * ebuild.sh, line 125: Called src_prepare * environment, line 3326: Called gnome2_src_prepare * environment, line 1937: Called elibtoolize * environment, line 726: Called die * The specific snippet of code: * ELT_LOGDIR=${T} LD=$(tc-getLD) eltpatch "${@}" || die "eltpatch failed" * * If you need support, post the output of `emerge --info '=gnome-base/librsvg-2.50.3::gentoo'`, * the complete build log and the output of `emerge -pqv '=gnome-base/librsvg-2.50.3::gentoo'`. * The complete build log is located at '/var/tmp/portage/gnome-base/librsvg-2.50.3/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/gnome-base/librsvg-2.50.3/temp/environment'. * Working directory: '/var/tmp/portage/gnome-base/librsvg-2.50.3/work/librsvg-2.50.3' * S: '/var/tmp/portage/gnome-base/librsvg-2.50.3/work/librsvg-2.50.3' END OF CODE the failing test in /usr/bin/eltpatch appears to be: CODE grep -qs 'We do not want portage' "${d}/eltmain.sh; then .... END OF CODE The following error shows up in /var/tmp/portage/gnome-base/librsvg-2.50.3/temp/elibtool.log for every patch: CODE ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. Error: too many environment variables, please use --rmenv END OF CODE sys-apps/sandbox (containing libsandbox.so) was emerged again to make sure but the same error still comes up. Again, this issue affects patches from many - if not all - programs. So, it breaks the emerge and update processes.
Created attachment 692487 [details] emerge --info
Created attachment 692490 [details] emerge -pqv
Created attachment 692493 [details] environment
Created attachment 692496 [details] elibtool.log
I assumed this was Prefix first, but it's not (libtool weirdness happens there sometimes). So, this is really weird: > ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. >Error: too many environment variables, please use --rmenv >END OF CODE >sys-apps/sandbox (containing libsandbox.so) was emerged again to make sure but the >same error still comes up. 1) Are you using something like Firejail? It's incompatible with sandbox. You don't want to be running emerge or any build systems through Firejail. I think by default it may automatically sandbox/shadow binaries, and we don't want that. 2) Can you tell me anything else that's "interesting" about your system? 3) Could you share 'env' and also tell me if this is reproducible with 'env -i' then running emerge or ebuild?
Created attachment 692637 [details] ps aux
Created attachment 692640 [details] env
Thank you for your help. Here is the info: 1) Firejail was installed on this system following these instructions: https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Install_Guide/Sandboxing_the_Firefox_Browser_with_Firejail#setup_clipboard_sharing My understanding is that Firejail runs as user (jplx) under gnome-wayland when using firefox. This issue arrises when gnome-wayland is not running and as root. So, it looks unrelated to Firejail (at least this is my understanding). Attached file 'ps-aux' shows all processes running before invoking the ebuild command. 2) this system runs gnome-wayland with systemd and had no problem for a while. This issue happened in the last two months. It has only two cpu's and less than 2GB of memory: CODE jplx-airgn2 ~ # free -m total used free shared buff/cache available Mem: 1727 81 1397 1 248 1495 Swap: 3071 0 3071 END OF CODE Therefore, I usually perform updates with gnome not running, just under the kernel to save on resources. When updates require lots of compile space, I use an external disk or flash memory with USB connection and mount it as /var/tmp/portage like: CODE mount /dev/sdb1 /var/tmp/portage END OF CODE and then I run the update. But it is not the case now: CODE jplx-airgn2 ~ # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 56.5G 0 disk ├─sda1 8:1 0 200M 0 part ├─sda2 8:2 0 500M 0 part └─sda3 8:3 0 55.8G 0 part └─root_e2adbe2e-8f39-4208-80fb-24a35996ccc9-vg1-root 253:0 0 55.8G 0 crypt ├─vg1-swap 253:1 0 3G 0 lvm [SWAP] ├─vg1-root 253:2 0 47G 0 lvm / └─vg1-home END OF CODE 3) env is attached. After running 'env -i', the failure occurs exactly the same as before.
It seems like an interesting coincidence that I suspected Firejail and it's involved. It's pretty much the only time I've seen these fun sandbox problems. I suspect this is Firejail as, by default, it'll do a lot of wrapping: https://wiki.archlinux.org/index.php/firejail#Using_Firejail_by_default. Please run: 1) ls /usr/local/bin/ and show us then 2) PATH="/usr/lib/portage/python3.8/ebuild-helpers/xattr:/usr/lib/portage/python3.8/ebuild-helpers:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/lib/llvm/11/bin" emerge -a -uvDU @world
Created attachment 692643 [details] ls /usr/local/bin
Created attachment 692646 [details] emerge world test Here is the emerge world test. Same failure...
You were right and the link you provided in comment #9 (archlinux-Using Firejail by Default) was key to understand the problem. Looking through the history, I found out that I had invoked the "firecfg" command (while debugging a different firefox networking issue that is now resolved). That "firecfg" command leads to "use Firejail by default for all applications for which it has profiles". It creates symbolic links in /usr/local/bin pointing to /usr/bin/firejail, for all programs for which firejail has default profiles. In the Troubleshooting section, it mentions that "/usr/bin/patch: **** Can't open patch file" could occur. Because I never really intended to use Firejail by default for many applications, I ran: CODE firecfg --clean END OF CODE All the links in /usr/local/bin were deleted. I had to restore the xephyr-helper file that was part of the initial installation of sandboxing Firefox. The emerge process now runs fine. So, problem solved. Because this issue appears to be very confusing, you may - or may not - want to make a change to allow patches to proceed after invoking the firecfg command. Anyway, thank you for your help.
