Recently app-i18n/unicode-data was bumped to version 14.0.0. This causes the following blocker: app-i18n/unicode-data:0 (app-i18n/unicode-data-14.0.0:0/0::gentoo, ebuild scheduled for merge) USE="" ABI_X86="(64)" conflicts with =app-i18n/unicode-data-13.0* required by (gnome-extra/gucharmap-13.0.8:2.90/2.90::gentoo, installed) USE="introspection -debug -gtk-doc -vala" ABI_X86="(64)"
This shouldn't be a _blocker_ per se, it should just skip the upgrade. Anyway, yeah, this happens with every new Unicode version but I don't think there's a corresponding gucharmap out yet.
(In reply to Sam James from comment #1) > This shouldn't be a _blocker_ per se, it should just skip the upgrade. > > Anyway, yeah, this happens with every new Unicode version but I don't think > there's a corresponding gucharmap out yet. Any idea why gucharmap would be so dependent on unicode-data version? If it is just updates to some tables that should not block client compilation.
(In reply to Gary E. Miller from comment #2) > Any idea why gucharmap would be so dependent on unicode-data version? > > If it is just updates to some tables that should not block client > compilation. Assuming upstream gucharmap hasn't changed too much from the GTK2 version of this I keep around, the main problem is the build generates several metadata .h files by directly reading the unicode-data you have installed (including embedding unicode version numbers in C defines), but those headers all reference an enum in a hardcoded file that defines which unicode versions it knows about. When that's out of date you get build errors. It's trivial to patch around manually (which is exactly how their releases operate[1]), but the correct long-term fix is to have it autogenerate the versions header too. Though that's probably out of scope for a bug like this, and I doubt upstream are interested. FWIW I did notice a 14.0.0 tag in their git repo. [1]: https://gitlab.gnome.org/GNOME/gucharmap/-/commit/b34cc8173f501b992833ee486d5cb5d563a7dff8#ab09af5eac2a07e766d0eda23d0da7f0fbc13bf1
(In reply to Enne Eziarc from comment #3) > FWIW I did notice a 14.0.0 tag in their git repo. > > [1]: > https://gitlab.gnome.org/GNOME/gucharmap/-/commit/ > b34cc8173f501b992833ee486d5cb5d563a7dff8#ab09af5eac2a07e766d0eda23d0da7f0fbc1 > 3bf1 That commit seems to solve our present problem. So I guess this bug should mutate into a request for a gucharmap version bump.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c71c16457541e9723ab99ebb2ba748afe4727f96 commit c71c16457541e9723ab99ebb2ba748afe4727f96 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2021-12-17 05:28:07 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2021-12-17 05:29:55 +0000 gnome-extra/gucharmap: Version bump to 14.0.1 Closes: https://bugs.gentoo.org/816342 Closes: https://bugs.gentoo.org/828119 Signed-off-by: Matt Turner <mattst88@gentoo.org> gnome-extra/gucharmap/Manifest | 1 + gnome-extra/gucharmap/gucharmap-14.0.1.ebuild | 66 +++++++++++++++++++++++++++ 2 files changed, 67 insertions(+)
