Bug 777339 – eltpatch fails on many - if not all - packages that have patches (seen on MacBookAir 3.1 running 5.4.97-gentoo)

• Product: Gentoo Linux
• Status: RESOLVED NEEDINFO

[Description jplx 2021-03-20 03:08:08 UTC]

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.

[Comment 1 jplx 2021-03-20 03:08:41 UTC]

Created attachment 692487 [details]
emerge --info

[Comment 2 jplx 2021-03-20 03:09:06 UTC]

Created attachment 692490 [details]
emerge -pqv

[Comment 3 jplx 2021-03-20 03:09:25 UTC]

Created attachment 692493 [details]
environment

[Comment 4 jplx 2021-03-20 03:09:43 UTC]

Created attachment 692496 [details]
elibtool.log

[Comment 5 Sam James 2021-03-20 03:22:24 UTC]

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?

[Comment 6 jplx 2021-03-21 06:08:33 UTC]

Created attachment 692637 [details]
ps aux

[Comment 7 jplx 2021-03-21 06:09:06 UTC]

Created attachment 692640 [details]
env

[Comment 8 jplx 2021-03-21 06:11:51 UTC]

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.

[Comment 9 Sam James 2021-03-21 06:25:17 UTC]

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

[Comment 10 jplx 2021-03-21 07:09:06 UTC]

Created attachment 692643 [details]
ls /usr/local/bin

[Comment 11 jplx 2021-03-21 07:10:34 UTC]

Created attachment 692646 [details]
emerge world test

Here is the emerge world test. Same failure...

[Comment 12 jplx 2021-03-25 03:22:52 UTC]

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.