Bug 281083
| Summary: | devel/glib20 and devel/gobject-introspection: update to 2.82 and 1.82 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Jan Beich <jbeich> | ||||||||
| Component: | Individual Port(s) | Assignee: | freebsd-desktop (Team) <desktop> | ||||||||
| Status: | Open --- | ||||||||||
| Severity: | Affects Only Me | CC: | agh, arrowd, citrin, desktop, diizzy, makc, mew14930xvi, vishwin | ||||||||
| Priority: | --- | Flags: | vishwin:
maintainer-feedback+
|
||||||||
| Version: | Latest | ||||||||||
| Hardware: | Any | ||||||||||
| OS: | Any | ||||||||||
| URL: | https://gitlab.gnome.org/GNOME/glib/-/blob/2.82.1/NEWS | ||||||||||
| See Also: | https://reviews.freebsd.org/D47139 | ||||||||||
| Bug Depends on: | 273722 | ||||||||||
| Bug Blocks: | 270358 | ||||||||||
| Attachments: |
|
||||||||||
Some new failure logs: https://pkg-status.freebsd.org/gohan04/data/140amd64-default-foo/2024-08-28_15h41m37s/logs/errors/pinot-1.21_13.log https://pkg-status.freebsd.org/gohan04/data/140amd64-default-foo/2024-08-28_15h41m37s/logs/errors/libvirt-10.3.0_1.log https://pkg-status.freebsd.org/gohan04/data/140amd64-default-foo/2024-08-28_15h41m37s/logs/errors/paps-0.8.0_2.log https://pkg-status.freebsd.org/gohan04/data/140amd64-default-foo/2024-08-28_15h41m37s/logs/errors/gchemutils-0.14.17_4.log https://pkg-status.freebsd.org/gohan04/data/140amd64-default-foo/2024-08-28_15h41m37s/logs/errors/qstardict-1.4_1.log https://pkg-status.freebsd.org/gohan04/data/140amd64-default-foo/2024-08-28_15h41m37s/logs/errors/sdcv-0.5.5.log https://pkg-status.freebsd.org/gohan04/data/140amd64-default-foo/2024-08-28_15h41m37s/logs/errors/stardict-3.0.6_7.log https://pkg-status.freebsd.org/gohan04/data/140amd64-default-foo/2024-08-28_15h41m37s/logs/errors/nautilus-42.2_3.log Created attachment 253195 [details]
fix build
Patches for textproc/stardict3, textproc/sdcv and textproc/qstardict.
I suspect that both patches are subject to the "just fix it" blanket approval. (In reply to Gleb Popov from comment #3) I agree Created attachment 253279 [details]
fix build
Patches for deskutils/pinot, print/paps, science/gchemutils and x11-fm/nautilus.
Did you check upstream projects at least one of the fixes is correct? Blindly discarding "const" can lead to crashes. A safer way is to simply convert variable to "const" (or use proper type), so the compiler would error out if anything tries to mutate the value later. This is not a patch to propose to Upstream. https://gitee.com/huzheng/stardict-3.0.7/blob/master/dict/src/lib/stddict.cpp#L2541 https://gitee.com/huzheng/stardict-3.0.7/blob/master/dict/src/lib/stddict.cpp#L2651 It is not clear to me why making implicit type conversions explicit would lead to crashes. It was not an implicit type conversion. glib 2.80.5 #define g_utf8_next_char(p) (char *)((p) + g_utf8_skip[*(const guchar *)(p)]) glib 2.82.0 #define g_utf8_next_char(p) ((p) + g_utf8_skip[*(const guchar *)(p)]) devel/libvirt could be built by updating to 10.7.0 and disabling ssh_proxy introduced in 10.4.0. Failed in 10.6.0. Pinot (added for glib 2.81.1) https://salsa.debian.org/debian/pinot/-/commit/056089ea089b98db02e94a39e99fabe4bafb13b8 libvirt - this appears to be fixed in later versions than what we have in tree paps - Fedora have a ton of patches, https://src.fedoraproject.org/rpms/paps/tree/rawhide qstardict, active fork appears to be located here: https://gitlab.com/a-rodin/qstardict (Alpine uses it at least) stardict, possibly related https://sources.debian.org/patches/stardict/3.0.7%2Bgit20220909%2Bdfsg-6/fix-gcc14-FTBFS%231078396.patch/ Comment on attachment 253109 [details]
v1 (apply via "git am")
The additional docs generated need to be gatekept under %%DOCS%%.
Expanding this to also include devel/gobject-introspection since they are meant to be updated together. They are slated to merge at some point: https://gitlab.gnome.org/GNOME/glib/-/issues/2616 However, there is now a circular dependency between the two since the GLib introspection data is no longer generated/included in gobject-introspection, but generated as part of the GLib build: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/433 Upstream's advice on dealing with circular dependency: https://discourse.gnome.org/t/dealing-with-glib-and-gobject-introspection-circular-dependency/18701 I'm thinking we may need to make a devel/glib20-bootstrap or similar so that we have the GLib introspection data available for consumers to use in some fashion. Sounds ugly, I know, and it may still run into linking issues, but otherwise gobject-introspection cannot be updated past 1.78, which has its own problems. Cancelling exp-run for now until further progress is made here. From ports 47c17dccc9b0 commit message: > Temporarily pass -Dintrospection=disabled to avoid dependency loop with devel/gobject-introspection. If you insist on scope creep consider this abandoned. I have plenty of my own ports, so don't need desktop@ help in burning out. (In reply to Jan Beich from comment #14) That bit wasn't sustainable and it is now biting us big time. Consumers really need that GLib introspection data that gobject-introspection removed since 1.79, but is only available when -Dintrospection=enabled is passed to glib since 2.79. Noticed especially when devel/libgusb failed to build because those files became missing from devel/gobject-introspection. Further, this also blocks setuptools from being updated. introspection uses distutils primitives. Only a problem when setuptools is present in the environment, especially under Python 3.12+ (distutils no longer part of the base distribution), as setuptools 74+'s copy of distutils removed legacy msvc compiler modules that introspection referenced until 1.81.2. You can call this scope creep or whatever you want, but the reality is that the changes happening in glib are not trivial. Why don't we just follow the upstream's advice ("glib -> introspection -> glib") in the introspection port?
Comment on attachment 253109 [details] v1 (apply via "git am") https://reviews.freebsd.org/D47139 for the *gory* details (I'm dead serious) Re-emphasising that building in-place or otherwise unclean environments will not work and is unsupported due to upstream's circular dependency situation; you must use isolated environments like poudriere. exp-run to be requested later, but there are already consumer failures that need addressing in large part from introspection being stricter in this version. (In reply to Charlie Li from comment #18) Pending bug 273722 to be qualified and committed. Some of the (particularly) introspection failures are from older pygobject running with newer introspection (which is stricter as previously mentioned). |
Created attachment 253109 [details] v1 (apply via "git am")