Building dev-libs/glib-2.82.5 fails during configuration phase: […] Found CMake: /usr/bin/cmake (3.31.5) Run-time dependency gobject-introspection-1.0 found: NO (tried cmake) ../glib-2.82.5/girepository/introspection/meson.build:78:17: ERROR: Dependency lookup for gobject-introspection-1.0 with method 'pkgconfig' failed: Could not generate cflags for gobject-introspection-1.0: Package dependency requirement 'glib-2.0 >= 2.82.0' could not be satisfied. Package 'glib-2.0' has version '2.80.5', required version is '>= 2.82.0' Package dependency requirement 'gobject-2.0 >= 2.82.0' could not be satisfied. Package 'gobject-2.0' has version '2.80.5', required version is '>= 2.82.0' A full log can be found at /var/tmp/portage/dev-libs/glib-2.82.5/work/glib-2.82.5-abi_x86_64.amd64/meson-logs/meson-log.txt * ERROR: dev-libs/glib-2.82.5::gentoo failed (configure phase): […] The package is installed and the corresponding pkgconfig files do exist: ❯ qlist dev-libs/gobject-introspection | grep pc /usr/lib64/pkgconfig/gobject-introspection-no-export-1.0.pc /usr/lib64/pkgconfig/gobject-introspection-1.0.pc However, as the error message states, the Required property in gobject-introspection-1.0.pc itself requires a glib version higher than the currently installed. (That is, glib-2.80.5-r1 is installed, to be updated to 2.82.5, yet currently installed gobject-introspection-1.82.0-r2 requires already >=glib-2.82.) Interestingly, gobject-introspection-1.82.0-r2 has as RDEPEND already >=dev-libs/glib-2.82.0:2[introspection], yet it is not installed. This leaves me a bit puzzled. I worked around this by manually patching gobject-introspection-1.0.pc, i.e., changing the required glib and gobject minimum verison to 2.80.0; upgrading glib; and reverting the change to the pc file. I filed this bug mainly for documentary reasons, in case others have similar issues. Reproducible: Always
Having the full build.log, meson-log.txt, and indeed emerge --info would be helpful here.
(In reply to Sam James from comment #1) > Having the full build.log, meson-log.txt, and indeed emerge --info would be > helpful here. (In particular, really need to understand what interaction happened with the boostrap gobject-introspection in the ebuild.)
Shame on me, I did not copied those files before the successful workaround-emerge cleaned it up. What I could restore is this information from emerge.log: 1742135107: >>> emerge (21 of 46) dev-libs/gobject-introspection-1.82.0-r2 to / 1742135107: === (21 of 46) Merging Binary (dev-libs/gobject-introspection-1.82.0-r2::/var/cache/binpkgs/dev-libs/gobject-introspection/gobject-introspection-1.82.0-r2-1.gpkg.tar) 1742135111: >>> AUTOCLEAN: dev-libs/gobject-introspection:0 1742135111: === Unmerging... (dev-libs/gobject-introspection-1.80.1-r3) 1742135113: >>> unmerge success: dev-libs/gobject-introspection-1.80.1-r3 1742135115: === (21 of 46) Post-Build Cleaning (dev-libs/gobject-introspection-1.82.0-r2::/var/cache/binpkgs/dev-libs/gobject-introspection/gobject-introspection-1.82.0-r2-1.gpkg.tar) 1742135115: ::: completed emerge (21 of 46) dev-libs/gobject-introspection-1.82.0-r2 to / 1742135115: >>> emerge (22 of 46) sys-libs/ncurses-6.5_p20250125 to / […] 1742135183: >>> emerge (25 of 46) dev-libs/glib-2.82.5 to / 1742135183: === (25 of 46) Cleaning (dev-libs/glib-2.82.5::/var/db/repos/gentoo/dev-libs/glib/glib-2.82.5.ebuild) 1742135183: === (25 of 46) Compiling/Merging (dev-libs/glib-2.82.5::/var/db/repos/gentoo/dev-libs/glib/glib-2.82.5.ebuild) 1742135216: *** Finished. Cleaning up... 1742135216: *** exiting unsuccessfully with status '1'. 1742135217: *** terminating. Here we see that dev-libs/gobject-introspection-1.82.0-r2 has been scheduled for merge before dev-libs/glib-2.82.5. But for glib to be upgraded from <2.82 to >=2.82, it requires a <gobject-introspection-2.82, since gobject-introspection-1.82.0-r2 has a pkgconfig that requires >=dev-libs/glib-2.82. Based on this, dev-libs/glib-2.82.5 shall have a BDEPEND on >=dev-libs/gobject-introspection-1.82.0. But is has not. The set use-flag 'introspection' pulls in ">=dev-libs/gobject-introspection-common-${INTROSPECTION_PV}", with INTROSPECTION_PV being 1.82.0, for [R]DEPEND. And we have "!gobject-introspection-1.80.1" as [R]DEPEND. Hope this adds valuable information.
(In reply to Stefan Huber from comment #3) > Based on this, dev-libs/glib-2.82.5 shall have a BDEPEND on > >=dev-libs/gobject-introspection-1.82.0. But is has not. That would introduce a circular dependency. This is why we have.. ``` # Build internal copy of gobject-introspection to avoid circular dependency (built for native abi only) if multilib_native_use introspection && ! has_version ">=dev-libs/${INTROSPECTION_P}" ; then [...] ``` in the glib ebuilds, since 2.80.x. The questions are: * How did you end up with gobject-introspection-1.82.0 installed before glib-2.82*? * Did the `has_version` check return true instead of false, so it didn't try to build a bootstrap gobject-introspection? * Are binpkgs relevant here? (Yes, probably; doesn't mean a dep is necessarily wrong, may be a Portage bug, but likely relevant nonetheless)
gobject-introspection even has a configure check for the right version of glib, so it can't be built with the wrong one. That would mean having a binpkg of gobject-introspection is needed for whatever you hit.
Right, gobject-introspection has glib-2.82.0 as [R]DEPEND. But since gobject-introspection has been installed as binpkg as of emerge.log, this allowed gobject-introspection to be emerged before glib? I am sorry, I am not very familiar with the dependency mechanics of binpkg. The emerge command that led to this was according to emerge.log: 1742197495: Started emerge on: Mär 17, 2025 08:44:54 1742197495: *** emerge --newuse --oneshot --update --ask --backtrack=200 --deep --keep-going --with-bdeps=y --reinstall=changed-use --getbinpkg --regex-search-auto=y --verbose --usepkg @world
Suspect this will bite everyone using binary packages. sudo emerge -a --unmerge dev-libs/gobject-introspection sudo emerge -a1 dev-libs/glib sudo telinit u sudo emerge --autounmask=y --autounmask-write --ask --update --newuse --deep --with-bdeps=y @world worked for me after the first emerge @world failed.
(In reply to Mark G. Woodruff from comment #7) > Suspect this will bite everyone using binary packages. > I don't think so. We'd have far more reports of that if so. > sudo emerge -a --unmerge dev-libs/gobject-introspection > sudo emerge -a1 dev-libs/glib > sudo telinit u (glibc != glib, so no need for that.) > sudo emerge --autounmask=y --autounmask-write --ask --update --newuse --deep > --with-bdeps=y @world > > worked for me after the first emerge @world failed. If you hit this exact issue, it'd be great to have the logs Stefan lost.
Created attachment 921212 [details] emerge log If this doesn't have what you need, let me know and I'll emerge it on another system (which should fail the same way)
Created attachment 921315 [details] emerge --info dev-libs/glib
Created attachment 921316 [details] amd64 meson-log /var/tmp/portage/dev-libs/glib-2.82.5/work/glib-2.82.5-abi_x86_64.amd64/meson-logs/meson-log.txt
Created attachment 921317 [details] x86 meson log /var/tmp/portage/dev-libs/glib-2.82.5/work/glib-2.82.5-abi_x86_64.amd64/meson-logs/meson-log.txt
Created attachment 921318 [details] build.log /var/tmp/portage/dev-libs/glib-2.82.5/temp/build.log
This seems to have hit me too. I have enabled binary packages globally, but as my system is also multilib globally, there is some large disparity between what packages are installed from binary packages, and which aren't (is there a chance we might get an official multilib binhost?). Let me know what I can/should test before continuing. I haven't dug much into what is causing this, other than trying `env USE=-introspection`, which didn't help, as I don't have too much time on my hands lately. It might be useful to know I haven't updated my system in a while, and I never got around to fixing the rust migration yet. I'm currently sitting at >100 pending updates: Total: 145 packages (122 upgrades, 1 downgrade, 3 new, 2 in new slots, 17 reinstalls, 32 binaries), Size of downloads: 0 KiB
emerge -p -uvDU @world (or whatever your regular upgrade command is) output showing a bad merge plan would be really helpful. What would be even *more* helpful is if someone could try extract a stage3 (possibly one from last week or something), and then give commands that lead to a bad merge plan being shown.
Created attachment 921319 [details] emerge update @world logs emerge -p -uUDN @world 2>&1 | tee emerge_uUDN_@world.txt
I do believe many of the updates here are unrelated to this issue. I only mentioned that since there might be some correlation. I hope I'll have time this weekend to clean up the system, and oneshotting upgrades until only the blockers remain. If I should wait on any of that for testing purposes, please let me know. I'd be happy to be a bunny.
> I don't think so. We'd have far more reports of that if so. Here you go, +1 Number 65 in my last emerge is binary of gobject-introspection-1.82.0-r2. After this glib as regular build compiled and failing with the same dependency error. Not every one running gentoo with binary package distribution will complain but silently apply the fix with unmerge gobject-instrospection followed by emerge of glib. The latter does not merge on my machine because of non matching USE: =dev-libs/glib-2.82.5 static-libs The host building my binaries also builds qemu which requires static-libs for some packages. The machine which emerged in wrong order does not need any emulation nor container nor virtualization and thus builds glib on its own. I'll simply set up a binary package distribution for non-emulation/ non-virtualization hosts or add static-libs for this machine. Maybe the latter since it doesn't require much work.
> The latter does not merge on my machine because of non matching USE: Should be: The latter does not merge >binary package of glib< on my machine because of non matching USE:
(In reply to onkobu from comment #18) > > I don't think so. We'd have far more reports of that if so. > Not every one running gentoo with binary package distribution will complain > but silently apply the fix with unmerge gobject-instrospection followed by > emerge of glib. I'm not disputing that the issue exists. I'm saying there's something more to it (like merge order), i.e. it's not simply about binpkg users and every binpkg user is affected.
A workaround we can add in dev-libs/glib is to see if the available gobject-introspection is truly usable, not just checking has_version.
(In reply to Sam James from comment #20) (This is also shown by the fact that glib+gobject-introspection are extremely common dependencies and we've had no mention of it on forums, MLs, or IRC; again, the issue is real, I was simply disputing that "every binpkg user" would hit it.)
> I was simply disputing that "every binpkg user" would hit it. No offense intended, I'm fine. I could also solve it by re-configuring USE so that the particular hosts pulls both binaries. Maybe dependency calculation for binaries yields a different order something like priority (gobject-introspection comes first) or relaxation (glib is pushed back after gobject-introspection). I assume that binary packages skip some of the DEPEND-constraints because they're already build and only require runtime dependencies.
I have a weird related problem: dev-libs/gobject-introspection requires dev-libs/glib[introspection] dev-libs/glib[introspection] requires dev-libs/gobject-introspection, but to satisfy this dev-libs/gobject-introspection is built into a temporary directory in src_configure However, on my system that always fails with: ``` Traceback (most recent call last): File "/usr/lib/portage/python3.12/doins.py", line 609, in <module> sys.exit(main(sys.argv[1:])) ^^^^^^^^^^^^^^^^^^ File "/usr/lib/portage/python3.12/doins.py", line 582, in main install_runner.install_dir(opts.dest) File "/usr/lib/portage/python3.12/doins.py", line 384, in install_dir self._dir_runner.run(dest) File "/usr/lib/portage/python3.12/doins.py", line 305, in run os.makedirs(dest) File "<frozen os>", line 215, in makedirs File "<frozen os>", line 215, in makedirs File "<frozen os>", line 215, in makedirs File "<frozen os>", line 225, in makedirs PermissionError: [Errno 13] Permission denied: b'/var/tmp/portage/dev-libs/glib-2.82.5/image/usr' * ERROR: dev-libs/glib-2.82.5 failed (configure phase): * dodoc failed * * If you need support, post the output of `emerge --info '=dev-libs/glib-2.82.5'`, * the complete build log and the output of `emerge -pqv '=dev-libs/glib-2.82.5'`. * The complete build log is located at '/var/log/portage/build/dev-libs/glib-2.82.5:20250405-091410.log.gz'. * For convenience, a symlink to the build log is located at '/var/tmp/portage/dev-libs/glib-2.82.5/temp/build.log.gz'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/glib-2.82.5/temp/environment'. * Working directory: '/var/tmp/portage/dev-libs/glib-2.82.5/work/gobject-introspection-1.82.0' * S: '/var/tmp/portage/dev-libs/glib-2.82.5/work/glib-2.82.5' Traceback (most recent call last): File "/usr/lib/portage/python3.12/doins.py", line 609, in <module> sys.exit(main(sys.argv[1:])) ^^^^^^^^^^^^^^^^^^ File "/usr/lib/portage/python3.12/doins.py", line 582, in main install_runner.install_dir(opts.dest) File "/usr/lib/portage/python3.12/doins.py", line 384, in install_dir self._dir_runner.run(dest) File "/usr/lib/portage/python3.12/doins.py", line 305, in run os.makedirs(dest) File "<frozen os>", line 215, in makedirs File "<frozen os>", line 215, in makedirs File "<frozen os>", line 215, in makedirs File "<frozen os>", line 225, in makedirs PermissionError: [Errno 13] Permission denied: b'/var/tmp/portage/dev-libs/glib-2.82.5/image/usr' * ERROR: dev-libs/glib-2.82.5 failed (configure phase): * dodoc failed * * If you need support, post the output of `emerge --info '=dev-libs/glib-2.82.5'`, * the complete build log and the output of `emerge -pqv '=dev-libs/glib-2.82.5'`. * The complete build log is located at '/var/log/portage/build/dev-libs/glib-2.82.5:20250405-091410.log.gz'. * For convenience, a symlink to the build log is located at '/var/tmp/portage/dev-libs/glib-2.82.5/temp/build.log.gz'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/glib-2.82.5/temp/environment'. * Working directory: '/var/tmp/portage/dev-libs/glib-2.82.5/work/gobject-introspection-1.82.0' * S: '/var/tmp/portage/dev-libs/glib-2.82.5/work/glib-2.82.5' >>> Failed to emerge dev-libs/glib-2.82.5, Log file: >>> '/var/log/portage/build/dev-libs/glib-2.82.5:20250405-091410.log.gz' ``` … and after digging into this, it does indeed appear to be a permissions issue: /var/tmp/portage/dev-libs/glib-2.82.5/image/ does exist, and is owned by `root:root` (permissions 0755) … however, during src_configure, the portage `emerge` process is running as `portage:portage` - and so it doesn't have permission to create `/var/tmp/portage/dev-libs/glib-2.82.5/image/usr` beneath `/var/tmp/portage/dev-libs/glib-2.82.5/image` If I chown/chmod `/var/tmp/portage/dev-libs/glib-2.82.5/image` then the build succeeds. … how is this working for anyone?! (… or have I enabled a non-default FEATURE which affects this behaviour? The build still fails with 'FEATURES="-sandbox -usersandbox"')
(In reply to Stuart Shelton from comment #24) > I have a weird related problem: > It's not really related to this bug, which is about merge order. Please file a new bug with the full build.log and emerge --info.
(In reply to Sam James from comment #25) > (In reply to Stuart Shelton from comment #24) > > I have a weird related problem: > > > > It's not really related to this bug, which is about merge order. Please file > a new bug with the full build.log and emerge --info. Ah, no - it's not: The dev-libs/glib ebuilds which build gobject-introspection in src_configure break if FEATURES="userpriv" :( (… and I'm not aware of any means to override FEATURE flags on a per-package basis?)
Sorry - misread that. I agree, this isn't a merge order bug. Which this one is!
Again, I think there's way more to your bug, userpriv is the default configuration. Let's discuss it in a new one please.
(In reply to Sam James from comment #25) > It's not really related to this bug, which is about merge order. Please file > a new bug with the full build.log and emerge --info. https://bugs.gentoo.org/953218
