Created attachment 247538 [details] Illustration -- although the menu-items are in proper Ukrainian, the menu-title itself is garbled The upstream's configure now checks for the presence of the bind_textdomain_codeset-function. The check fails, because the function is provided by libinto.so, but configure does not add -lintl to the compiler command-line. The subtle failure causes (some) of the UI text to be garbled for people, who use non-UTF8 encoding -- such as uk_UA.KOI8-U. I'm not sure, how to best work around the problem while the upstream are working on the proper fix (see URL for link to the bug-report). I simply added the following snippet to my own /etc/make.conf, which proved sufficient: .if ${.CURDIR:T:M*xfce4*} CONFIGURE_ENV+= LIBS=-lintl LDFLAGS=-L${LOCALBASE}/lib .endif This was not a problem earlier -- a machine I have with Xfce4-4.16.4 is fine...
(In reply to Mikhail T. from comment #0) Hi, Thanks for reporting this. Looks like a change introduced in recent releases. It should be fairly easy to fix in the ports, since there are official ways to pass extra flags to the environment. While your CONFIGURE_ENV trick works, I think using the LIBS variable and maybe, if needed, USES=localbase:ldflags I'm going to do some testing, but I will be a little slow since I'm away from home these days and mostly out the while day. I'm also going to followup in the upstream bug shortly. Thanks for the accurate description and the analysis you did!
Upstream moved the issue to a different component, update the link.
Created attachment 247550 [details] patch v1 I applied the submitter suggested patch, binding it to the NLS option. This is needed because gettext is not set as a runtime dependency if the NLS option is disabled, so libintl could not be present. It works fine in poudriere, where the configure check now succeeds. This is a workaround, though, A better fix needs to be coordinated with upstream. In the while, can you also test this patch? Thanks in advance!
I have also created a patch with upstream that should really fix this: https://gitlab.xfce.org/madpilot/libxfce4util/-/commit/7f71b90dd2240d88ca7cb9a6e7272e46a6fa0926 This patch is untested right now. I'll send it as a pull request after testing.
(In reply to Guido Falsi from comment #4) SOrry that patch is actually wrong and will not work. I need to fix it.
I have filed a pull request upstream to really fix this. I will commit the workaround shortly though.
(In reply to Guido Falsi from comment #6) https://gitlab.xfce.org/xfce/libxfce4util/-/merge_requests/41
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=1c3d203e8a5476b616fd82adb7b5f98274ef89db commit 1c3d203e8a5476b616fd82adb7b5f98274ef89db Author: Guido Falsi <madpilot@FreeBSD.org> AuthorDate: 2024-01-09 22:44:19 +0000 Commit: Guido Falsi <madpilot@FreeBSD.org> CommitDate: 2024-01-09 22:44:19 +0000 x11/libxfce4util: Workaround gettext library detection issue Due to an issue in the configure script gettext functions are not detected properly t configure time. This is causing display issues with non-UTF8 locales. This commit implements a workaround by passing some extra env to configure to successfully detect the library. A proper fix is proposed upstream at [1]. [1] https://gitlab.xfce.org/xfce/libxfce4util/-/merge_requests/41 PR: 276211 x11/libxfce4util/Makefile | 2 ++ 1 file changed, 2 insertions(+)
Keeping this open for now, to track progress with the proper fix.
A commit in branch 2024Q1 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=aaddd26ab326f3a721d1e5b1f4542e12dee9cb7b commit aaddd26ab326f3a721d1e5b1f4542e12dee9cb7b Author: Guido Falsi <madpilot@FreeBSD.org> AuthorDate: 2024-01-09 22:44:19 +0000 Commit: Guido Falsi <madpilot@FreeBSD.org> CommitDate: 2024-01-09 23:22:04 +0000 x11/libxfce4util: Workaround gettext library detection issue Due to an issue in the configure script gettext functions are not detected properly t configure time. This is causing display issues with non-UTF8 locales. This commit implements a workaround by passing some extra env to configure to successfully detect the library. A proper fix is proposed upstream at [1]. [1] https://gitlab.xfce.org/xfce/libxfce4util/-/merge_requests/41 PR: 276211 (cherry picked from commit 1c3d203e8a5476b616fd82adb7b5f98274ef89db) x11/libxfce4util/Makefile | 2 ++ 1 file changed, 2 insertions(+)
My only concern is whether it is just the libxfce4util, that needs this -- other pieces (xfce4-wm, xfce4-panel) also have configure look for the same function. But I don't know, if that matters... Unfortunately, I can't test right away, because this is my desktop -- and I cannot afford to restart it during the week. It makes sense that the proper fix would be applied to configure.ac -- but our XFCE4-ports don't regenerate the configure currently, do they?
> Unfortunately, I can't test right away, because this is my desktop -- and I cannot afford to restart it during the week. Ok, so I updated the ports-tree, commented-out my work-around from the /etc/make.conf, forcibly rebuilt all of the xfce4* ports, and restarted just the panel and xfwm4 (which one can restart without killing the entire X-session). Both continue show cyrillics correctly... Thank you for the quick (and energetic) reaction :)
(In reply to Mikhail T. from comment #11) What I committed is just a workaround to plug the hole, while a better solution is being discussed with upstream. To answer your question, a port can be made to rebuild configure script with USES=autoreconf. It will add dependencies on autoconf utilities, and be aware that most of the time this causes some more dependencies to come up, in this case it would require an unconditional build time dependency on gtk-doc. autoreconf also makes port build take longer, since more work needs to be performed, so it should be avoided unless strictly necessary.
(In reply to Guido Falsi from comment #13) > a port can be made to rebuild configure script with USES=autoreconf Yes, I know this :) I was just pointing out, we do not currently do that.
(In reply to Mikhail T. from comment #11) My merge request upstream was accepted. Comments upstream indicate that the issue could be present in other components, but upstream is aware and has plans to fix those. So I expect newer releases to contain a fix when they come out. I'm going to close this as fixed since we did our part at this point, and things are moving on by themselves. Thanks again for reporting and analysis!