Resolved: permission denied: 'git' gui-libs/gtk-4.18.6-r1

[eccerr0r]

Weird. Seems portage wants to run 'git' while building gtk, and is portage denying it due to sandbox?

Code: Select all

[26/1170] /usr/lib/python-exec/python3.13/meson --internal exe --capture profile_conf.h -- /store/tmp/portage/gui-libs/gtk-4.18.6-r1/work/gtk-4.18.6/build-aux/meson/gen-profile-conf.py /store/tmp/portage/gui-libs/gtk-4.18.6-r1/work/gtk-4.18.6 default
FAILED: [code=1] profile_conf.h
/usr/lib/python-exec/python3.13/meson --internal exe --capture profile_conf.h -- /store/tmp/portage/gui-libs/gtk-4.18.6-r1/work/gtk-4.18.6/build-aux/meson/gen-profile-conf.py /store/tmp/portage/gui-libs/gtk-4.18.6-r1/work/gtk-4.18.6 default
--- stderr ---
Traceback (most recent call last):
  File "/store/tmp/portage/gui-libs/gtk-4.18.6-r1/work/gtk-4.18.6/build-aux/meson/gen-profile-conf.py", line 19, in <module>
    with subprocess.Popen(cmd, stdout=subprocess.PIPE) as p:
         ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/subprocess.py", line 1039, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
    ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        pass_fds, cwd, env,
                        ^^^^^^^^^^^^^^^^^^^
    ...<5 lines>...
                        gid, gids, uid, umask,
                        ^^^^^^^^^^^^^^^^^^^^^^
                        start_new_session, process_group)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/subprocess.py", line 1972, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
PermissionError: [Errno 13] Permission denied: 'git'

ninja: build stopped: subcommand failed.
 * ERROR: gui-libs/gtk-4.18.6-r1::gentoo failed (compile phase):

---

Resolved: turns out I had an old package dependency of old software that added a path that was security guarded (games) and now incompatible with how meson makes assumptions on what's installed or not. Removing the old software fixed the issue, which of course isn't exactly the "right" solution but it works around the problem. Giving user 'portage' rights to run games would have been the other workaround but that package really should have been depcleaned along with software that depended on it... IMHO having meson NOT fail with an even stupider obscure error message would have been the correct solution, but that's probably an upstream issue.

[Hu]

No, ninja wants to run git, probably to look up the current commit or similar. What is the output of namei -l /usr/bin/git?

[eccerr0r]

Code: Select all

$ git
bash: git: command not found

LOL I don't even have git installed on this machine. Should git be part of the build dependency list of gtk if it can download more stuff? Or should there be a way to stop it from downloading any more code...

[Hu]

Strange. I would expect a different error for trying to run a command that does not exist.

We would need to understand why gtk is trying to run git, but my initial position is that gtk should not run git during a Portage-managed build. If gtk is trying to download code, then that is wrong and would be blocked by the network sandbox. If gtk is trying to examine the properties of a local checkout, that is harmless, but probably would fail because the archive of the released source probably does not contain enough of a checkout for git to work.

I suggest examining the failing Python file to determine what it is trying to do with git.

[sam_]

I suspect you have some directory on PATH which isn't +x (so readable by Portage). We've seen issues like that before, if I'm remembering them right.

[Anon-E-moose]

if git were try to run something it would likely be one of the wrap files in subdirectory, which would imply some package that it expects hasn't been installed or it can't see it (for whatever reason)

These are the wrap files

Code: Select all

accesskit-c.wrap  gdk-pixbuf.wrap  gobject-introspection.wrap  harfbuzz.wrap           libjpeg-turbo.wrap  libtiff.wrap  sassc.wrap              wayland.wrap
cairo.wrap        gi-docgen.wrap   graphene.wrap               libcloudproviders.wrap  libpng.wrap         pango         sysprof.wrap
fribidi.wrap      glib.wrap        gstreamer-full.wrap         libepoxy.wrap           libsass.wrap        pango.wrap    wayland-protocols.wrap

Edit to add: the whole log file might mention what it was trying to git access.

[eccerr0r]

Only mention of git in the file:

Code: Select all

sys.stdout.write("/* This file is auto-generated. Do not edit. */\n")
sys.stdout.write("#pragma once\n")
sys.stdout.write("\n")
sys.stdout.write(f"#define PROFILE \"{profile}\"\n")

short_sha = os.environ.get('CI_COMMIT_SHORT_SHA')
if short_sha is None:
    cmd = ["git", "-C", repodir, "rev-parse", "--short", "HEAD"]
    try:
        with subprocess.Popen(cmd, stdout=subprocess.PIPE) as p:
            short_sha = p.stdout.read().decode('utf-8').rstrip("\n")
    except FileNotFoundError:
        short_sha = ''
        if profile != 'default':
            short_sha = 'devel'

sys.stdout.write(f"#define VCS_TAG \"{short_sha}\"\n")

hmm... really need to override this, there is no reason to git IMHO, so set CI_COMMIT_SHORT_SHA to something, anything?
Should the ebuild be doing this? And why am I the only one running into this? Something funky with my machine? (it's my old Pentium-M 32-bit)

[Anon-E-moose]

Look for mention of meson not finding some package. If it doesn't find it then it tries a wrap file (many of which are git).

[sam_]

This is nothing to do with wraps. That program gets invoked either way in meson.build:

Code: Select all

gen_profile_conf = find_program('build-aux/meson/gen-profile-conf.py')

profile = get_option('profile')
if profile == 'auto'
  if gtk_minor_version.is_even()
    profile = 'default'
  else
    profile = 'devel'
  endif
endif

profile_conf_h = declare_dependency(
  sources: custom_target('profile-conf',
    command: [gen_profile_conf, meson.project_source_root(), profile],
    capture: true,
    output: 'profile_conf.h',
    build_by_default: true,
    build_always_stale: true,
  )

It's just that it normally gets invoked and is harmless. See my earlier post.

[eccerr0r]

Yeah I'm fairly certain there's a 'git' somewhere that's -x causing the permission denied, but is that sufficient to cause a fail, would that not give a file not found error versus a permission denied, and it still would be considered a failed run?

Will I need git installed for this case in general even without wanting a 9999?

[sam_]

1. Yes.
2. No. It's because it finds one that it can't execute, rather than it not finding one at all. You can still file a bug and we can stub out the git detection, but this will surely end up breaking other things too. You should fix your system.

[eccerr0r]

Code: Select all

# find / -name git -type f

???

What if there is none...

[sam_]

I suspect you have some directory on PATH which isn't +x (so readable by Portage). We've seen issues like that before, if I'm remembering them right.

Please examine this possibility I mentioned earlier.

[eccerr0r]

Files:
/usr/share/misc/magic/git

Directories:
/usr/lib/python3.11/site-packages/portage/sync/modules/git
/usr/lib/python3.13/site-packages/portage/sync/modules/git
/usr/portage/dev-ruby/git
/usr/portage/dev-vcs/git
/usr/portage/acct-group/git
/usr/portage/acct-user/git
/store/tmp/portage/._portage_reinstall_.cfd7hn17/lib/portage/sync/modules/git
/store/tmp/portage/._portage_reinstall_.c1gfsrh2/lib/portage/sync/modules/git

Nothing out of the ordinary...
(/store/tmp/portage is my PORTAGE_TMPDIR of course...)

[sam_]

PATH, not directories matching git.

[eccerr0r]

Ok...i think i understand now.

I do have a /usr/games/bin that is mode 750 in PATH but portage probably doesn't have access to.

[sam_]

I don't think it actually needs to have a 'git' in there for the failure I'm thinking of to happen. But again, it doesn't have to be noexec (a mount option), just missing +x on a directory means you cannot list contents.

No need to 'instrument' Portage, it's already in the environment file it mentions at the end of the output when you have a failure.

[eccerr0r]

see edit above dealing with /usr/games/bin ... This is really old stuff here, haven't been touched in a decade, and I recall something dealing with portage itself installing /usr/games/bin with no access to people who are ... not allowed to play games... I don't even know why I merged them in the first place anymore...

gosh this is so slow doing forensics... partly because it's emerging firefox right now, mostly because this is a hard disk drive...

OKAY. Good bye all games. Need the disk space anyway.
# emerge --depclean $(equery list games*/*|cut -f3|sed 's/-[0-9].*//') # bah, just make it do it.

BTW I think it's probably the deprecated package games-misc/games-envd-0 that might have been the culprit package...

[logrusx]

BTW I think it's probably the deprecated package games-misc/games-envd-0 that might have been the culprit package...

For the record, it's not deprecated, it's long gone: https://github.com/gentoo-mirror/gentoo ... d5c8d1b5d9

Best Regards,
Georgi