I see that glib-2.80.x has landed: commit b0cdd4865b65ff4759b8ad273871442b67f2b95f Author: Guillermo Joandet <gjoandet@gmail.com> Date: Fri May 10 10:12:54 2024 -0300 dev-libs/glib: Bump to 2.80.4 Signed-off-by: Guillermo Joandet <gjoandet@gmail.com> Signed-off-by: Pacho Ramos <pacho@gentoo.org> commit 87757767aae114d32059400fd72d1a59656f8382 Author: Guillermo Joandet <gjoandet@gmail.com> Date: Wed Jan 17 22:35:13 2024 -0300 dev-libs/gobject-introspection: Bump to 1.80.1 Signed-off-by: Guillermo Joandet <gjoandet@gmail.com> Signed-off-by: Pacho Ramos <pacho@gentoo.org> AFAIK, from discussions on IRC a while ago, we were avoiding doing this for now until we'd figured out the circular dep problems. The commit message doesn't discuss the issue or how it's been worked around/solved.
I see leio mentions it at https://github.com/gentoo/gentoo/pull/36834#issuecomment-2241515970. In general, Guillermo (and Pacho), please do write verbose commit messages, it helps a lot.
And indeed just hit it on world upgrade: ``` [nomerge ] app-emacs/pinentry-0.1_p20231126::gentoo [nomerge ] app-crypt/pinentry-1.3.1::gentoo USE="X caps emacs gtk ncurses qt5 qt6 verify-sig wayland -efl -keyring" [nomerge ] app-crypt/gcr-4.2.1:4/gcr-4.4-gck-2.2::gentoo USE="gtk introspection systemd vala -gtk-doc -test" [nomerge ] app-crypt/libsecret-0.21.1::gentoo USE="crypt introspection (test-rust) vala -gtk-doc -test -tpm" ABI_X86="(64) -32 (-x32)" [ebuild U ] dev-libs/gobject-introspection-1.80.1::gentoo [1.78.1::gentoo] USE="-doctool -gtk-doc -test" PYTHON_SINGLE_TARGET="python3_12 -python3_10 -python3_11 -python3_13" 1,016 KiB [ebuild U ] dev-libs/glib-2.80.4:2::gentoo [2.78.6:2::gentoo] USE="dbus elf introspection%* (mime) test xattr -debug -doc% (-selinux) -static-libs -sysprof -systemtap -utils (-gtk-doc%)" ABI_X86="(64) -32 (-x32)" 5,407 KiB Total: 2 packages (2 upgrades), Size of downloads: 6,422 KiB * Error: circular dependencies: (dev-libs/gobject-introspection-1.80.1:0/0::gentoo, ebuild scheduled for merge) depends on (dev-libs/glib-2.80.4:2/2::gentoo, ebuild scheduled for merge) (buildtime) (dev-libs/gobject-introspection-1.80.1:0/0::gentoo, ebuild scheduled for merge) (buildtime) It might be possible to break this cycle by applying the following change: - dev-libs/glib-2.80.4 (Change USE: -introspection) ``` I really think we should try figure *something* out to avoid every single user having to manually work around this. But it is a shame that meson subprojects can't be used here (https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/380#note_2089298).
I tried USE-introspection to avoid the circular dependencies, but portages fails with ``` USE=-introspection emerge -1v --color=n =dev-libs/glib-2.80.4' Local copy of remote index is up-to-date and will be used. These are the packages that would be merged, in order: Calculating dependencies ... done! Dependency resolution took 1.39 s (backtrack: 0/20). [ebuild U ] dev-libs/glib-2.80.4:2::gentoo [2.78.6:2::gentoo] USE="dbus elf (mime) static-libs sysprof xattr -debug -doc% -introspection% (-selinux) -systemtap -test -utils (-gtk-doc%)" ABI_X86="(64) -32 (-x32)" 5407 KiB [uninstall ] dev-util/gdbus-codegen-2.78.6::gentoo PYTHON_SINGLE_TARGET="python3_12 -python3_10 -python3_11" [blocks b ] <dev-util/gdbus-codegen-2.80.4 ("<dev-util/gdbus-codegen-2.80.4" is soft blocking dev-libs/glib-2.80.4) [blocks B ] <dev-libs/gobject-introspection-1.80.1 ("<dev-libs/gobject-introspection-1.80.1" is soft blocking dev-libs/glib-2.80.4) Total: 1 package (1 upgrade, 1 uninstall), Size of downloads: 5407 KiB Conflict: 2 blocks (1 unsatisfied) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (dev-libs/gobject-introspection-1.78.1-2:0/0::gentoo, installed) pulled in by >=dev-libs/gobject-introspection-1.54:0/0= required by (gnome-base/gnome-desktop-44.0-r400-1:4/2::gentoo, installed) USE="(seccomp) systemd udev -debug -gtk-doc" ABI_X86="(64)" >=dev-libs/gobject-introspection-1.56:0/0= required by (x11-libs/vte-0.74.2-2:2.91/2.91::gentoo, installed) USE="crypt icu introspection systemd vala -debug -gtk-doc -vanilla" ABI_X86="(64)" >=dev-libs/gobject-introspection-1.54:0/0= required by (gnome-extra/sushi-45.0-1:0/0::gentoo, installed) USE="X wayland" ABI_X86="(64)" >=dev-libs/gobject-introspection-1:= required by (app-text/evince-46.3-1:0/evd3.4-evv3.3::gentoo, installed) USE="gnome gstreamer introspection keyring spell tiff -cups -djvu -dvi -gtk-doc (-nautilus) -postscript -xps" ABI_X86="(64)" >=dev-libs/gobject-introspection-1.30:= required by (sys-fs/udisks-2.10.1-3:2/2::gentoo, installed) USE="acl daemon introspection nls systemd -debug (-elogind) -lvm (-selinux)" ABI_X86="(64)" >=dev-libs/gobject-introspection-1.71.1:= required by (dev-libs/gjs-1.78.5-1:0/0::gentoo, installed) USE="cairo readline sysprof -examples -test" ABI_X86="(64)" ... and on and on and on ```
(In reply to Albert W. Hopkins from comment #3) > I tried USE-introspection to avoid the circular dependencies, but portages > fails with > > ``` > USE=-introspection emerge -1v --color=n =dev-libs/glib-2.80.4' > Disabling USE introspection *only* for glib via package.use and then doing a full world upgrade (not emerge glib, that gives me the same conflict) resolved that problem on my end. But then after the world upgrade has completed, re-enabling USE introspection results in: Found CMake: /usr/bin/cmake (3.30.2) Run-time dependency gobject-introspection-1.0 found: NO (tried pkgconfig and cmake) ../glib-2.80.4/girepository/introspection/meson.build:53:17: ERROR: Dependency "gobject-introspection-1.0" not found, tried pkgconfig and cmake Which is strange because '/usr/lib64/pkgconfig/gobject-introspection-1.0.pc' exists.
Created attachment 899672 [details] meson configure log
(In reply to Sam James from comment #1) > In general, Guillermo (and Pacho), please do write verbose commit messages, > it helps a lot. OK thanks I thought it was enough with the long discussion in the referred PR
(In reply to Sam James from comment #2) [...] > I really think we should try figure *something* out to avoid every single > user having to manually work around this. But it is a shame that meson > subprojects can't be used here > (https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/ > 380#note_2089298). I already reviewed that and also found that reference but, at the end, it seems that there is no other solution than emerging newer glib without introspection, build newer instrospection and rebuild glib. It is what all the other distributions ended up doing and, looking to upstream, it seems nothing better will come for months (or years)
I am going to mask it in few mins (I am dealing with other reverse deps too)
(In reply to Andrew Nowa Ammerlaan from comment #4) > But then after the world upgrade has completed, re-enabling USE > introspection results in: > > Found CMake: /usr/bin/cmake (3.30.2) > Run-time dependency gobject-introspection-1.0 found: NO (tried pkgconfig and > cmake) > > ../glib-2.80.4/girepository/introspection/meson.build:53:17: ERROR: > Dependency "gobject-introspection-1.0" not found, tried pkgconfig and cmake > > Which is strange because '/usr/lib64/pkgconfig/gobject-introspection-1.0.pc' > exists. This resolves my problem: diff --git a/dev-libs/glib/glib-2.80.4.ebuild b/dev-libs/glib/glib-2.80.4.ebuild index e61ebbcbfe68..1a20959666c2 100644 --- a/dev-libs/glib/glib-2.80.4.ebuild +++ b/dev-libs/glib/glib-2.80.4.ebuild @@ -203,7 +203,7 @@ multilib_src_configure() { -Doss_fuzz=disabled $(meson_native_use_feature elf libelf) -Dmultiarch=false - $(meson_feature introspection) + $(meson_native_use_feature introspection) ) meson_src_configure }
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5a11a4800db7175e4376154797b25238c91dd29c commit 5a11a4800db7175e4376154797b25238c91dd29c Author: Pacho Ramos <pacho@gentoo.org> AuthorDate: 2024-08-09 11:55:10 +0000 Commit: Pacho Ramos <pacho@gentoo.org> CommitDate: 2024-08-09 12:04:10 +0000 profiles: mask glib-2.80 and co. due to issues when updating Bug: https://bugs.gentoo.org/937616 Signed-off-by: Pacho Ramos <pacho@gentoo.org> profiles/package.mask | 8 ++++++++ 1 file changed, 8 insertions(+)
(In reply to Pacho Ramos from comment #6) > I thought it was enough with the long discussion in the referred PR The thing is GH might disappear at some point, but git is forever, it's also easier to search and so on.
(In reply to Pacho Ramos from comment #7) Yeah, I appreciate this is pretty hard. The problem is, other distros can solve it _once_ on their builder, job done. They don't have the same problem we do. What I'm wondering if we can do is build glib-introspection once within the glib ebuild. I mentioned that to leio ages ago and IIRC it looked infeasible but I don't remember why yet.
Another core issue is that the whole tree assumes a gobject-introspection dep provides glib GIR, which it now doesn't. And making gobject-introspection have a long-term transitional dep on glib[introspection] to ensure it's there, ends up in circular issues. Maybe a PDEPEND, but then that doesn't ensure wrong order upgrades won't be broken afaik.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b816f464caf6e4217266aeef09e44163c5967d9e commit b816f464caf6e4217266aeef09e44163c5967d9e Author: Pacho Ramos <pacho@gentoo.org> AuthorDate: 2024-08-09 12:46:15 +0000 Commit: Pacho Ramos <pacho@gentoo.org> CommitDate: 2024-08-09 12:46:15 +0000 dev-libs/glib: instrospection support is not meant to be used in multilib Thanks-to: Andrew Nowa Ammerlaan Bug: https://bugs.gentoo.org/937616 Signed-off-by: Pacho Ramos <pacho@gentoo.org> dev-libs/glib/glib-2.80.4.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
(In reply to Larry the Git Cow from comment #10) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=5a11a4800db7175e4376154797b25238c91dd29c > > commit 5a11a4800db7175e4376154797b25238c91dd29c > Author: Pacho Ramos <pacho@gentoo.org> > AuthorDate: 2024-08-09 11:55:10 +0000 > Commit: Pacho Ramos <pacho@gentoo.org> > CommitDate: 2024-08-09 12:04:10 +0000 > > profiles: mask glib-2.80 and co. due to issues when updating > > Bug: https://bugs.gentoo.org/937616 > Signed-off-by: Pacho Ramos <pacho@gentoo.org> > > profiles/package.mask | 8 ++++++++ > 1 file changed, 8 insertions(+) $ emerge --ignore-default-opts -puD --changed-use @world [ ... ] !!! All ebuilds that could satisfy ">=dev-libs/glib-2.79.0:2" have been masked. !!! One of the following masked packages is required to complete your request: - dev-libs/glib-2.80.4::gentoo (masked by: package.mask) /usr/portage/profiles/package.mask: # Pacho Ramos <pacho@gentoo.org> (2024-08-09) # Mask until we find out a way to deal better with the upstream # introduced circular dep, bug #937616 (dependency required by "dev-libs/gobject-introspection-1.80.1::gentoo" [ebuild]) (dependency required by "media-libs/harfbuzz-9.0.0::gentoo[introspection]" [installed])
I think we need to mask: [ebuild U ] dev-util/glib-utils-2.80.4::gentoo [2.78.6::gentoo] PYTHON_SINGLE_TARGET="python3_12 -python3_10 -python3_11 -python3_13%" 5,407 KiB [ebuild U ] dev-util/gdbus-codegen-2.80.4::gentoo [2.78.6::gentoo] PYTHON_SINGLE_TARGET="python3_12 -python3_10 -python3_11 -python3_13%" 0 KiB as well.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=88edfd240adbad57c627633a32343b74ab575925 commit 88edfd240adbad57c627633a32343b74ab575925 Author: Pacho Ramos <pacho@gentoo.org> AuthorDate: 2024-08-09 14:07:07 +0000 Commit: Pacho Ramos <pacho@gentoo.org> CommitDate: 2024-08-09 14:07:39 +0000 profiles: update glib-2.80 mask Thanks-to: Sam James Bug: https://bugs.gentoo.org/937616 Signed-off-by: Pacho Ramos <pacho@gentoo.org> profiles/package.mask | 2 ++ 1 file changed, 2 insertions(+)
(In reply to Andrew Nowa Ammerlaan from comment #9) > (In reply to Andrew Nowa Ammerlaan from comment #4) this patch solved the gobject-introspection-1.0 error, thank you.
Hello, I have retried to update from a system that wasn't still running the updated glib. What I have needed to do is: 1. USE="-introspection" emerge -1av dev-libs/glib dev-libs/gobject-introspection dev-util/gdbus-codegen 2. emerge -1av dev-libs/glib dev-libs/gobject-introspection dev-util/gdbus-codegen (maybe not strictly needed as it seems portage was able to properly rebuild them before the consumer... but I think it will be safer in this way) 3. Run the regular world update. Maybe a news item could suggest this.
Regarding the transitional dep on glib[introspection], I have tried to modify gobject-introspection ebuild to add a "+introspection" USE flag RDEPENDing on glib[introspection?]. With that ebuild, it is possible to break the circular dep issue at update time with: 1. USE="-introspection" emerge -1av dev-libs/glib dev-libs/gobject-introspection-common dev-libs/gobject-introspection dev-util/gdbus-codegen 2. emerge -1av dev-libs/glib dev-libs/gobject-introspection-common dev-libs/gobject-introspection dev-util/gdbus-codegen 3. Regular world update In my case, I didn't need to rely on PDEPEND.
Relying on USE flag defaults isn't really a solution in ensuring deps that are required are there.
I don't think introspection is really working on systems without "introspection" USE flag globally enabled. What alternative would be feasible? PDEPEND on glib[introspection] from gobject-introspection is not possible as we still need to transitionally disable introspection in glib for updating.
Maybe another workaround would be to, instead of relying on "introspection" for gobject-introspection package, use a local "glib-bootstrap" (or similar). That should cover the corner cases of people actively disabling "introspection" USE flags for glib and gobject-introspection and still expecting to have working introspection support. I think that should be really rare (and near "shooting themselves in the foot")... but it's true that needing to explicitly enable "glib-bootstrap" at migration time would minimize even more the temporal breakage: 1. USE="-introspection glib-bootstrap" emerge -1av dev-libs/glib dev-libs/gobject-introspection-common dev-libs/gobject-introspection dev-util/gdbus-codegen 2. emerge -1av dev-libs/glib dev-libs/gobject-introspection-common dev-libs/gobject-introspection dev-util/gdbus-codegen 3. Regular world update
I found a way around this. Ive created a -r1 and a -r2 version of glib. Its not a "nice" way but it works: https://git.gjdwebserver.nl/gjdwebserver/gjdwebserver-overlay/src/branch/master/dev-libs/glib the r1 ebuild has the USE +introspection but is missing !<dev-libs/gobject-introspection-1.80.1 !<dev-util/gdbus-codegen-${PV} and uses -Dintrospection=disabled then just run: emerge --ask --oneshot =dev-libs/glib-2.80.4-r1 after that run: emerge --ask --oneshot dev-libs/gobject-introspection dev-util/gdbus-codegen the r2 version is just the normal glib ebuild And then emerge --ask --oneshot =dev-libs/glib-2.80.4-r2 After that gnome-shell 46 just emerges fine. TBH I dont see a way (outside of a bootstrap version) around this issue.
The approach suggested in comment #15 worked for me. (I also had to unmask thunderbird-128 as thunderbird-115 was crashing with wayland errors).
(In reply to Geoff Leach from comment #25) > The approach suggested in comment #19 worked for me. > > (I also had to unmask thunderbird-128 as thunderbird-115 was crashing with > wayland errors).
I think we'll have to do https://bugs.gentoo.org/937616#c12 or some separate mini glib package w/o introspection installed to some custom prefix.
(In reply to Sam James from comment #27) > I think we'll have to do https://bugs.gentoo.org/937616#c12 or some separate > mini glib package w/o introspection installed to some custom prefix. But the packages that depend on dev-libs/glib will still fail then since dev-libs/gobject-introspection has a hard reference to >=dev-libs/glib-2.79.0:2 Hence why I made comment #24 You will need to find a way to get dev-libs/gobject-introspection to not look at glib but the glib version without introspection.
(In reply to gjdijkman from comment #28) > (In reply to Sam James from comment #27) > > I think we'll have to do https://bugs.gentoo.org/937616#c12 or some separate > > mini glib package w/o introspection installed to some custom prefix. > > But the packages that depend on dev-libs/glib will still fail then since > dev-libs/gobject-introspection has a hard reference to > >=dev-libs/glib-2.79.0:2 Obviously we'd adapt ebuilds as required... > > You will need to find a way to get dev-libs/gobject-introspection to not > look at glib but the glib version without introspection. Yes.
(it seems these kind of links cannot be used in "See also"... I leave them here then as they could be useful too) In Exherbo it seems they finally opted for the rebuilding via their "gobject-introspection" USE flag and they updated the reverse deps to glib[gobject-introspection] https://gitlab.exherbo.org/exherbo/arbor/-/commit/e263444f8b18eea48954503532509d0b6e38d786 https://gitlab.exherbo.org/exherbo/arbor/-/commit/b2935eb2b88c45daebbf66d068bfacf8a094e231 And this is their news item (for paludis): https://gitlab.exherbo.org/exherbo/arbor/-/commit/75bf7a6e1c62c46176c6ee7ee03a68f7458099b2
When I updated to glib-2.79 I used this manual workaround : FEATURES="-protect-owned" emerge --oneshot --nodeps dev-util/glib-utils dev-util/gdbus-codegen dev-libs/glib After that, gobject-introspection was able to update smoothly on its own.
Please avoid making comments about manual workarounds. That part is well-understood.
There is no circular dep issue here. It is simply that Gentoo has has no way of cleanly dealing with a change of ownership like this this.
Created attachment 902996 [details] gobject-introspection ebuild without glib dependency
Created attachment 902997 [details] glib ebuild with some hacks for introspection
Was able to get a possible solution cooked up using the glib subproject for gobject-introspection. Had to get a little messy with PKG_CONFIG_PATH and LD_LIBRARY_PATH in the glib ebuild but it does work. attachment 902996 [details] attachment 902997 [details]
In my case it worked the https://bugs.gentoo.org/937616#c19 but in step 2 introspection active...otherwise the compilation of some software fails with problems with GIR 1. USE="-introspection" emerge -1av dev-libs/glib dev-libs/gobject-introspection-common dev-libs/gobject-introspection dev-util/gdbus-codegen 2. USE="introspection" emerge -1av dev-libs/glib dev-libs/gobject-introspection-common dev-libs/gobject-introspection dev-util/gdbus-codegen
Created attachment 903297 [details] merged glib + gobject-introspection ebuild I was able to come up with a better solution actually, integrating gobject-introspection into the glib ebuild. This does gobject-introspection so all dependent packages will need to have their dependency changed to glib[introspection]. I tested both emerging from nothing and from our previous 2.78.6 versions, both worked without manual intervention.
Given the upstream plans to break the circular dep, my gut feeling says that we should have a dev-util/g-ir-scanner that just ships that part in a way that doesn't have a dev-libs/glib dependency (perhaps building an internal copy that gets static linked). Albeit it may have some complications in realizing that, e.g. python extension linking to gobject or something. Also I'm not sure if maybe it shouldn't also provide /usr/lib64/libgirepository-2.0.so then, at which point it really becomes a dev-libs/libgirepository instead, someone needs to look into it in detail.
Actually, I just realized we can still keep gobject-introspection as a discrete package while implementing my approach for building glib. All we have to do is just not install gobject-introspection during the glib build. A bit of extra compile time sure, but much simpler. I don't think the internal version of gobject-introspection matters, just so long as glib is able to build with it.
