Fedora Account System
Red Hat Associate
Red Hat Customer
Spec URL: https://www.techie.net/~talbert/wxWidgets.spec SRPM URL: https://www.techie.net/~talbert/wxWidgets-3.3.2-1.fc45.src.rpm Description: wxWidgets is a C++ cross-platform GUI library, offering classes for all common GUI controls as well as a comprehensive set of helper classes for most common application tasks, ranging from networking to HTML display and image manipulation. Fedora Account System Username: swt2c
Taking this review.
Copr build: https://copr.fedorainfracloud.org/coprs/build/10181754 (failed) Build log: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2443717-wxwidgets/fedora-rawhide-x86_64/10181754-wxWidgets/builder-live.log.gz Please make sure the package builds successfully at least for Fedora Rawhide. - If the build failed for unrelated reasons (e.g. temporary network unavailability), please ignore it. - If the build failed because of missing BuildRequires, please make sure they are listed in the "Depends On" field --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Initial spec review: > BuildRequires: xorg-x11-server-Xvfb Can this be swapped out for "wlheadless-run" or "xwfb-run"? > Requires(post): /usr/sbin/update-alternatives > Requires(postun): /usr/sbin/update-alternatives Can we get rid of alternatives and just make it mutually exclusive packages instead? Some kind of Provides+Conflicts stanza with a virtual name? e.g. Provides: devel(wxWidgets) Conflicts: devel(wxWidgets) Or something else, I guess... > %{_libdir}/libwx_gtk3u_adv-*.so.%{sover}* The soversion glob is too greedy, per https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files Also, some kind of bcond to make it so that if it's the default version, the package provides the unversioned names so it gets pulled in by default. Finally, could we consider switching from Autotools to CMake? It appears to be supported: https://github.com/wxWidgets/wxWidgets/blob/master/docs/doxygen/overviews/cmake.md
(In reply to Neal Gompa from comment #3) > Initial spec review: > > > BuildRequires: xorg-x11-server-Xvfb > > Can this be swapped out for "wlheadless-run" or "xwfb-run"? I've tried that on the wxWidgets 3.2 release and there were a ton more test failures. So, probably not without having to skip a *lot* of tests. Probably need to get upstream support for that. > > Requires(post): /usr/sbin/update-alternatives > > Requires(postun): /usr/sbin/update-alternatives > > Can we get rid of alternatives and just make it mutually exclusive packages > instead? > > Some kind of Provides+Conflicts stanza with a virtual name? e.g. > > Provides: devel(wxWidgets) > Conflicts: devel(wxWidgets) > > Or something else, I guess... Yeah, we could probably do conflicting devel packages. The alternatives setup is just how it has been...forever. > > %{_libdir}/libwx_gtk3u_adv-*.so.%{sover}* > > The soversion glob is too greedy, per > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > #_listing_shared_library_files > > Also, some kind of bcond to make it so that if it's the default version, the > package provides the unversioned names so it gets pulled in by default. > > Finally, could we consider switching from Autotools to CMake? It appears to > be supported: > https://github.com/wxWidgets/wxWidgets/blob/master/docs/doxygen/overviews/ > cmake.md I did initially try this, but ran into bugs. Autotools is still the main supported build system, so I'd prefer to stick with it for now.
*** Bug 2468482 has been marked as a duplicate of this bug. ***
*** Bug 2496326 has been marked as a duplicate of this bug. ***
Updated to wxWidgets 3.3.3 and addressed most comments: Spec URL: https://www.techie.net/~talbert/wxWidgets.spec SRPM URL: https://www.techie.net/~talbert/wxWidgets-3.3.3-1.fc45.src.rpm Paging @ngompa :)
By the way, 3.3.3 appears to have largely fixed the issues with CMake. I don't know if it has fixed all issues encountered when trying it previously here, but it seems worth trying again.
Copr build: https://copr.fedorainfracloud.org/coprs/build/10781366 (failed) Build log: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2443717-wxwidgets/fedora-rawhide-x86_64/10781366-wxWidgets/builder-live.log.gz Please make sure the package builds successfully at least for Fedora Rawhide. - If the build failed for unrelated reasons (e.g. temporary network unavailability), please ignore it. - If the build failed because of missing BuildRequires, please make sure they are listed in the "Depends On" field --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
(In reply to electricbrass from comment #8) > By the way, 3.3.3 appears to have largely fixed the issues with CMake. I > don't know if it has fixed all issues encountered when trying it previously > here, but it seems worth trying again. Yes, Scott, could you take a look at this again? (In reply to Fedora Review Service from comment #9) > Copr build: > https://copr.fedorainfracloud.org/coprs/build/10781366 > (failed) > > Build log: > https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora- > review-2443717-wxwidgets/fedora-rawhide-x86_64/10781366-wxWidgets/builder- > live.log.gz > It looks like the webtest and locale/language tests are failing?
Created attachment 2152794 [details] mock-build.log > It looks like the webtest and locale/language tests are failing? Not sure what that's about. I just built the SRPM in mock locally, and it finished just fine - including tests: > ../../tests/intl/intltest.cpp:443: warning: > Swedish locale not supported. > =============================================================================== > All tests passed (1220802 assertions in 474 test cases) > + LD_LIBRARY_PATH=/builddir/build/BUILD/wxWidgets-3.3.3-build/BUILDROOT/usr/lib64 > … > ../../tests/graphics/bitmap.cpp:65: warning: > Skipping test known not to work in wxGTK. > =============================================================================== > All tests passed (33452 assertions in 486 test cases) > + popd > ~/build/BUILD/wxWidgets-3.3.3-build/wxWidgets-3.3.3 > … > ../../tests/intl/intltest.cpp:443: warning: > Swedish locale not supported. > =============================================================================== > All tests passed (1220803 assertions in 474 test cases) > + popd > ~/build/BUILD/wxWidgets-3.3.3-build/wxWidgets-3.3.3 > … > Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILD/wxWidgets-3.3.3-build/BUILDROOT > Wrote: /builddir/build/RPMS/wxQt3.4-media-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxQt3.4-devel-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxGTK3.4-devel-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxGTK3.4-media-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxQt3.4-gl-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxGTK3.4-gl-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxGTK3.4-webview-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxQt3.4-media-debuginfo-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxGTK3.4-media-debuginfo-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxBase3.4-devel-debuginfo-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxQt3.4-gl-debuginfo-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxGTK3.4-webview-debuginfo-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxGTK3.4-gl-debuginfo-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxBase3.4-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxWidgets3.4-i18n-3.3.3-1.fc44.noarch.rpm > Wrote: /builddir/build/RPMS/wxBase3.4-devel-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxGTK3.4-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxQt3.4-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxWidgets-debuginfo-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxBase3.4-debuginfo-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxWidgets-debugsource-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxWidgets3.4-docs-3.3.3-1.fc44.noarch.rpm > Wrote: /builddir/build/RPMS/wxGTK3.4-debuginfo-3.3.3-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/wxQt3.4-debuginfo-3.3.3-1.fc44.x86_64.rpm > Executing(rmbuild): /bin/sh -e /var/tmp/rpm-tmp.a8O838 > + umask 022 > + cd /builddir/build/BUILD/wxWidgets-3.3.3-build > + test -d /builddir/build/BUILD/wxWidgets-3.3.3-build > + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w /builddir/build/BUILD/wxWidgets-3.3.3-build > + rm -rf /builddir/build/BUILD/wxWidgets-3.3.3-build > + RPM_EC=0 > ++ jobs -p > + exit 0 > Child return code was: 0 Full log attached.
Noticed the log in my last comment was on F44 while the failing log was on rawhide. So I ran it through a rawhide chroot in mock as well, and it finished too: > Finish: rpmbuild wxWidgets-3.3.3-1.fc45.src.rpm > Finish: build phase for wxWidgets-3.3.3-1.fc45.src.rpm > INFO: Done(wxWidgets-3.3.3-1.fc45.src.rpm) Config(fedora-rawhide-x86_64) 13 minutes 40 seconds > INFO: Results and/or logs in: /home/tarulia/Development/aegisub/wxWidgets/rawhide > INFO: Cleaning up build root ('cleanup_on_success=True') > Start: clean chroot > Finish: clean chroot > Finish: run
Yes, the tests run successfully locally for me in mock. I also ran a scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=148412504 There's an s390x failure there that I'm looking at, but by and large they pass. Not sure what's up with the copr build.
I saw this in the wxQt-devel subpackage: > Requires: gtk3-devel > Requires: libGLU-devel Is this correct?
OK, so for the last couple hours I've been banging my head against the wall trying to build Aegisub 3.5 beta[1] with wxQt from this (3.4.2 stable had the same result), and at this point I am fairly confident this is an issue with this package. I've installed the RPMs in the mock root, minus the GTK ones, and then started the build: > rpms=$(ls ./wxWidgets/*x86_64.rpm | grep -v GTK) > mock_root=$(pwd)/mock_root > mock -r fedora-44-x86_64 --rootdir=$mock_root --init > mock -r fedora-44-x86_64 --rootdir=$mock_root --install ${rpms} However, come the %build step, it fails because meson can't find wx-config (I added the ls as a sanity check): > + cd Aegisub-3.5.0 > + ls /usr/bin/wx-config /usr/bin/wxrc /usr/bin/wxrc-3.3 > /usr/bin/wx-config > /usr/bin/wxrc > /usr/bin/wxrc-3.3 > … > + /usr/bin/meson setup … > … > Run-time dependency zlib found: YES 1.3.1.zlib-ng > wx-config found: NO need ['>=3.2.2'] > Run-time dependency WxWidgets for cpp found: NO (tried config-tool) > ERROR: Cmake subproject wxWidgets is buildable: NO However, when I also install the GTK packages, the build succeeds. But of course, that makes the compiler link everything against wxgtk/libgtk: > ❯ ldd aegisub | grep gtk > libwx_gtk3u_stc-3.3.so.3 => not found > libwx_gtk3u_gl-3.3.so.3 => not found > libwx_gtk3u_core-3.3.so.3 => not found > libportal-gtk3.so.1 => not found > libgtk-3.so.0 => /lib64/libgtk-3.so.0 (0x00007f34b5a00000) > ❯ ldd aegisub | grep qt > ❯ echo $? > 1 I'm wondering if it has to do with the wx-config provided in the SRPM. I don't really know why this exists because from what I can tell upstream generates their own anyway. It was added to the current package 16 years ago[3], but I don't see an explanation as to why, and has been virtually unchanged since. I guess it was just carried over from there. Anyway, from what I can tell that wx-config file only looks for the wxGTK libraries, so it sort of makes sense that it works when wxGTK is installed in the buildroot. But I don't think that's intended? That would defeat the purpose of building wxQT in the first place, no? It also doesn't explain why wx-config isn't found at all by meson though :/ One possibility I see is that meson actually runs wx-config and it considers a non-0/1 exit as non-existent. I manually ran it in a toolbox, and that would make sense: > $ dnf list --installed wxGTK* > No matching packages to list > $ wx-config > wxGTK-devel isn't installed for architecture 'x86_64' > $ echo $? > 9 > $ sudo dnf install $(ls ./wxWidgets/*x86_64.rpm | grep GTK) -y > … > $ wx-config > > wx-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--release] [--version-full] > … > $ echo $? > 1 So I think the wrapper - if it is really still needed - would need to be rewritten to take wxQt into account. I might do a wxWidgets build without replacing wx-config and see how it goes. [1] https://src.fedoraproject.org/rpms/aegisub/blob/853c49e62049da390f4daf9d8d139d4344fea759/f/aegisub.spec [2] https://src.fedoraproject.org/rpms/wxGTK/blob/5f01483b6f866658a00752b06d14867e698802c6/f/wx-config [3] https://src.fedoraproject.org/rpms/wxGTK/c/db1199232abd00ff9eb783dfe1f89669dacfa4d1?branch=5f01483b6f866658a00752b06d14867e698802c6
Actually, taking another look at the spec. I assume this as well is carried over from the current package[1], but it actually does some fixups on the library paths in the wx-config.in file that is used to generate the upstream wrapper[2]: (L239/240 for this package) > # fix plugin dir for 64-bit > sed -i -e 's|/usr/lib\b|/usr/%{_lib}|' wx-config.in configure But then it goes ahead and nukes the resulting file entirely[3]: (L294-299 for this package) > # install our multilib-aware wrapper > ##Remove installed > rm %{buildroot}%{_bindir}/wx-config > ##Install new and symlink > install -p -D -m 755 %{SOURCE10} %{buildroot}%{_bindir}/wx-config > sed -i -e 's|=/usr|=%{_prefix}|' %{buildroot}%{_bindir}/wx-config I don't think that makes much sense? [1] https://src.fedoraproject.org/rpms/wxGTK/blob/rawhide/f/wxGTK.spec#_174-176 [2] https://github.com/wxWidgets/wxWidgets/blob/v3.3.3/wx-config.in [3] https://src.fedoraproject.org/rpms/wxGTK/blob/rawhide/f/wxGTK.spec#_211-218
OK, Update: I built wxWidgets without the wx-config wrapper, i.e. removed the Source10 referencing block mentioned above, and both it as well as Aegisub builds succeed just fine. I haven't tested how well the resulting build works, but I suppose that's outside of this issue anyway. > ❯ grep wx aegisub.spec > #BuildRequires: wxGTK-devel > #BuildRequires: wxGTK3.4-devel > BuildRequires: wxQt3.4-devel > ls /usr/bin/wx* > Wrote: /builddir/build/RPMS/aegisub-debugsource-3.5.0~beta-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/aegisub-3.5.0~beta-1.fc44.x86_64.rpm > Wrote: /builddir/build/RPMS/aegisub-debuginfo-3.5.0~beta-1.fc44.x86_64.rpm Obviously this is just a sample size of one and I don't know if/how this would affect other consumers of wxWidgets. But given that upstream's wrapper is vastly more complex and seems to work, and there seems to be no reference why it was replaced to begin with, there's an argument it could be removed?
Hm, a couple hours of experimenting later, it seems there is another problem with this that might have to be brought up with upstream, but now it also makes sense to me what the Arch PKGBUILD is doing. So the problem is that %make_install always installs to the same /usr/bin/wx-config, regardless of what toolkit it was built with. It is just a symlink pointing to the toolkit's specific wx-config. Since the spec is building both wxGTK and wxQt, this means that the second %make_install clobbers the already existing symlink from the first %make_install. That in turn means that if the custom wrapper is removed like I did in my last comment, that symlink now permanently points to wxQt because it happens to be built and installed second: > $ ls -l /usr/bin/wx* > lrwxrwxrwx. 1 root root 33 Jul 26 02:00 /usr/bin/wx-config -> ../lib64/wx/config/qt-unicode-3.3 > lrwxrwxrwx. 1 root root 8 Jul 26 02:00 /usr/bin/wxrc -> wxrc-3.3 > -rwxr-xr-x. 1 root root 132648 Jul 26 02:00 /usr/bin/wxrc-3.3 That of course means that all builds with only wxGTK installed (which would be all wxW based packages right now) would FTBFS because wx-config couldn't be found. I don't think the multi-arch wrapper is the solution here either though since it always defaults to wxGTK and there is no way to choose wxQt instead, making the wxQt build pointless. I don't really know how upstream intends this to work. Arch "solved" this by renaming the resulting wx-config[1][2], leaving the GTK one in place as the default. But for one that seems like a rather hacky solution to me, and for another I don't know how at application build time one would choose which to use, and not even the wiki has a page on it. Even now I don't even know how I would force an Aegisub build using the wxGTK backend that the current Fedora repo version does. I can't imagine always returning an arbitrary default that the developer has no control over is intended, but on the other hand I don't see wx-config returning anything for higher level buildsystems (i.e. meson, cmake, ...), only flags to add to the compiler directly. Of course this would be solved by not shipping wx-config in wxBase, but in the respective toolkit packages instead. That would be fine for building packages, but obviously that would mean you couldn't coinstall them during development. I'm not sure what the best route is here. [1] https://gitlab.archlinux.org/archlinux/packaging/packages/wxwidgets/-/blob/c0b212c66bedce067d3706df31ea130b12bee65e/PKGBUILD#L122 [2] https://gitlab.archlinux.org/archlinux/packaging/packages/wxwidgets/-/blob/c0b212c66bedce067d3706df31ea130b12bee65e/PKGBUILD#L214 PS: Sorry about all the walls of text (and emails), but I found all this just going along :(
(In reply to Neal Gompa from comment #14) > I saw this in the wxQt-devel subpackage: > > > Requires: gtk3-devel > > Requires: libGLU-devel > > Is this correct? Definitely not, will remove in next update.
(In reply to Scott Talbert from comment #19) > (In reply to Neal Gompa from comment #14) > > I saw this in the wxQt-devel subpackage: > > > > > Requires: gtk3-devel > > > Requires: libGLU-devel > > > > Is this correct? > > Definitely not, will remove in next update. I would guess this needs the Qt6 counterparts?
OK, just did another round of updates. Spec URL: https://www.techie.net/~talbert/wxWidgets.spec SRPM URL: https://www.techie.net/~talbert/wxWidgets-3.3.3-1.fc45.src.rpm 1) Switch to build using cmake (this was a pain, found more bugs) 2) Dropped the wx-config wrapper (not sure it's needed anymore) 3) Went back to the update-alternatives method for shipping wx-config as I don't see any way to ship conflicting wx-config files otherwise. 4) Cleaned up wrong -devel depends on Qt package. I believe this should resolve all open issues (or at least good enough to get this reviewed).
FWIW I could build both wxGTK and wxQt from this just fine. Just one note on the spec I noticed: I believe /usr/sbin should be using %{_sbindir} instead? Also update-alternatives is just a symlink to alternatives, might as well use that (not that it matters in any way) :D I've also tried the aforementioned Aegisub build again: [x] only wxGTK3.4 installed - linked correctly against wxGTK [x] only wxQt3.4 installed - linked correctly against wxQt [x] both wxGTK3.4 and wxQt3.4 installed - linked against wxGTK (i.e. expected default) So looks as expected overall :)
Some more spec review: > %build > %global _vpath_builddir %{gtk3dir} > %cmake -DwxBUILD_TOOLKIT=gtk3 -DwxBUILD_TESTS=ALL -DwxUSE_ARTPROVIDER_TANGO=OFF > %cmake_build > > %global _vpath_builddir %{qt6dir} > %cmake -DwxBUILD_TOOLKIT=qt -DwxBUILD_TESTS=ALL > %cmake_build Unless we're still trying to have this in EPEL 9 and older, this should be using the new %conf section, so it would look like so: """ %conf %define _vpath_builddir %{gtk3dir} %cmake -DwxBUILD_TOOLKIT=gtk3 -DwxBUILD_TESTS=ALL -DwxUSE_ARTPROVIDER_TANGO=OFF %define _vpath_buildder %{qt6dir} %cmake -DwxBUILD_TOOLKIT=qt -DwxBUILD_TESTS=ALL %build %define _vpath_builddir %{gtk3dir} %cmake_build %define _vpath_buildder %{qt6dir} %cmake_build """ I'm also guessing that "xwfb-run" still doesn't work? As far as replacing alternatives, I was going to suggest something like this for wxGTK-devel: """ Provides: wxWidgets-toolkit-devel Conflicts: wxWidgets-toolkit-devel RemovePathPostfixes: .gtk3ucfg """ And this for wxQt-devel: """ Provides: wxWidgets-toolkit-devel Conflicts: wxWidgets-toolkit-devel RemovePathPostfixes: .qt6cfg """ And then the wx-config variants would be suffixed as "wx-config.gtk3ucfg" and "wx-config.qt6cfg". The suffix would be stripped during rpmbuild time, and the result are mutually conflicting packages where you have to pick one or the other for the application being built.
(In reply to Neal Gompa from comment #23) > The suffix would be stripped during rpmbuild time, > and the result are mutually conflicting packages where you have to pick one > or the other for the application being built. I guess this is adjacent to the solution I proposed above, but that carries the same problem: It wouldn't matter for packaging because packagers can just pick one or the other. But Developers couldn't install both in parallel to build/test against both toolkits, or to use for different projects. The alternatives way leaves that option open. The one downside is that this requires root access. But chances are a developer already has that, or the sysadmin could set up sudoers to allow usage of alternatives.
(In reply to Tarulia from comment #24) > (In reply to Neal Gompa from comment #23) > > The suffix would be stripped during rpmbuild time, > > and the result are mutually conflicting packages where you have to pick one > > or the other for the application being built. > > I guess this is adjacent to the solution I proposed above, but that carries > the same problem: It wouldn't matter for packaging because packagers can > just pick one or the other. But Developers couldn't install both in parallel > to build/test against both toolkits, or to use for different projects. > > The alternatives way leaves that option open. The one downside is that this > requires root access. But chances are a developer already has that, or the > sysadmin could set up sudoers to allow usage of alternatives. Admittedly, the conflict mainly comes from wx-config. I'm also kind of iffy about having our default toolkit be GTK3 given that it's a dead-end toolkit, but I'm also cognizant that wxQt is relatively new... I'd rather everyone be forced to be explicit about this, but the developer thing is a good point.
(In reply to Neal Gompa from comment #25) > Admittedly, the conflict mainly comes from wx-config. I'm also kind of iffy > about having our default toolkit be GTK3 given that it's a dead-end toolkit, > but I'm also cognizant that wxQt is relatively new... I'd rather everyone be > forced to be explicit about this, but the developer thing is a good point. I'm with you on that one, mostly because I have a dislike for some of the design decisions in GTK3 (some of which are very annoying to deal with in Aegisub, hence my wxQt adventure). Regardless of that, 3.24 is still actively maintained, so it's not dead *yet*. More importantly though, currently all wxWidgets based packages are built with it, and arguably - regardless how stable (or not) wxQt is - a package review is probably not the right place to change the default. Moreover, wxWidgets themselves define GTK3 as the default[1]: ``` elseif(UNIX) set(wxDEFAULT_TOOLKIT gtk3) … wx_option(wxBUILD_TOOLKIT "Toolkit used by wxWidgets" ${wxDEFAULT_TOOLKIT} ``` So for better or worse - in the spirit of "upstream first" - I think it makes sense to keep it that way. There is also a GTK4 option, though I don't know how well supported this is. It was added 7 years ago[2], but Arch for their part disables the build. Speaking of options, wxWidgets also provides a way to build CLI-only applications and has a corresponding wx-config for it. It's built using -DwxUSE_GUI=OFF. Why one would do that I don't know, but it is an option. The question is whether this should also be built here? On another note, I just noticed the spec still references wx-config in Source10, but then doesn't use it. Probably makes sense to comment or remove that too. [1] https://github.com/wxWidgets/wxWidgets/blob/8d8967a29ac76b78a02b79eab7494545f09fff06/build/cmake/toolkit.cmake#L33-L41 [2] https://github.com/wxWidgets/wxWidgets/commit/46a94c2b48cc0aafe9fef1ff4d98d1f44770870c
(In reply to Tarulia from comment #26) > Speaking of options, wxWidgets also provides a way to build CLI-only > applications and has a corresponding wx-config for it. It's built using > -DwxUSE_GUI=OFF. Why one would do that I don't know, but it is an option. > The question is whether this should also be built here? Actually on that one. The alternatives setup already sets up the wxrc, but not wx-config? I don't see a specific build for it either though.
(In reply to Neal Gompa from comment #23) > Unless we're still trying to have this in EPEL 9 and older, this should be > using the new %conf section, so it would look like so: OK, I switched over to use %conf. > I'm also guessing that "xwfb-run" still doesn't work? It doesn't, and I don't think is the place to get it working. Needs to be supported upstream first. > As far as replacing alternatives, I was going to suggest something like this > for wxGTK-devel: > RemovePathPostfixes: .gtk3ucfg OK, that was the hint I was missing. If you feel strongly about elmininating alternatives and parallel installability, then we can do this. Otherwise, I'd just as well leave it as-is. (In reply to Neal Gompa from comment #25) > Admittedly, the conflict mainly comes from wx-config. I'm also kind of iffy > about having our default toolkit be GTK3 given that it's a dead-end toolkit, > but I'm also cognizant that wxQt is relatively new... I'd rather everyone be > forced to be explicit about this, but the developer thing is a good point. wxQt should definitely not be the default right now. (In reply to Tarulia from comment #26) > There is also a GTK4 option, though I don't know how well supported this is. > It was added 7 years ago[2], but Arch for their part disables the build. The GTK4 port is currently unusable as I understand it. > On another note, I just noticed the spec still references wx-config in > Source10, but then doesn't use it. Probably makes sense to comment or remove > that too. Removed.
(In reply to Tarulia from comment #27) > (In reply to Tarulia from comment #26) > > Speaking of options, wxWidgets also provides a way to build CLI-only > > applications and has a corresponding wx-config for it. It's built using > > -DwxUSE_GUI=OFF. Why one would do that I don't know, but it is an option. > > The question is whether this should also be built here? > > Actually on that one. The alternatives setup already sets up the wxrc, but > not wx-config? I don't see a specific build for it either though. I'm not aware of any applications actually being built with *just* wxBase (ie, no GUI), so I never packaged that separately as a -devel.
(In reply to Scott Talbert from comment #29) > I'm not aware of any applications actually being built with *just* wxBase > (ie, no GUI), so I never packaged that separately as a -devel. Me neither. Just thought I'd mention it in case it was missed.
Noticed this while doing further experiments with my Aegisub build. When I check `alternatives --list`, I see 2 entries for wxWidgets: ``` ❯ alternatives --list | grep wx wx-config auto /usr/lib64/wx/config/gtk3-unicode-3.3 wxrc auto /usr/libexec/wxWidgets/wxrc ``` But from the spec I can't tell why `wxrc` is getting an alternatives setup. There's only one file from `wxBase`, but none from the others. Do wxGTK and wxQt even produce their own `wxrc`, or do they all share the same? Also, if it had actual alternatives, shouldn't those be grouped with the respective `wx-config` so they are all swapped in tandem?
(In reply to Tarulia from comment #31) > Noticed this while doing further experiments with my Aegisub build. > > When I check `alternatives --list`, I see 2 entries for wxWidgets: > > ``` > ❯ alternatives --list | grep wx > wx-config auto /usr/lib64/wx/config/gtk3-unicode-3.3 > wxrc auto /usr/libexec/wxWidgets/wxrc > ``` > > But from the spec I can't tell why `wxrc` is getting an alternatives setup. > There's only one file from `wxBase`, but none from the others. Do wxGTK and > wxQt even produce their own `wxrc`, or do they all share the same? > > Also, if it had actual alternatives, shouldn't those be grouped with the > respective `wx-config` so they are all swapped in tandem? It's because the existing wxGTK package (wxWidgets 3.2) also provides wxrc.
Oh right they are supposed to be parallel-installable for the stable-unstable cycle? In that case there's arguably even more reason to group them, no? With the current setup it would be possible to install the 3.4 devel packages and the 3.2 devel package, giving 3 choices for `wx-config` and 2 for `wxrc`: ``` $ dnf list --installed wxGTK3.4-devel wxQt3.4-devel wxBase-devel Installed packages (available for reinstall, available for upgrade) wxBase-devel.x86_64 3.2.9-2.fc44 fedora wxGTK3.4-devel.x86_64 3.3.3-1.fc44 @commandline wxQt3.4-devel.x86_64 3.3.3-1.fc44 @commandline $ alternatives --config wx-config There are 3 programs which provide 'wx-config'. Selection Command ----------------------------------------------- *+ 1 /usr/lib64/wx/config/gtk3-unicode-3.3 2 /usr/lib64/wx/config/qt-unicode-3.3 3 /usr/libexec/wxGTK/wx-config $ alternatives --config wxrc There are 2 programs which provide 'wxrc'. Selection Command ----------------------------------------------- *+ 1 /usr/libexec/wxWidgets/wxrc 2 /usr/libexec/wxGTK/wxrc ``` However, because they are not linked, it would easily be possible for users to end up with any combination of the 5. For example `wx-config` from wxQt3.4 and `wxrc` from wxBase3.2, or `wx-config` from wxGTK3.2 with `wxrc` from 3.4. I don't imagine that would go very well. I'm by no means an expert on `alternatives` (I finally found out today how to actually choose one …), but I believe that is what the `--follower` options are for? I don't think it makes sense for them to be chosen individually.
Oh yeah, adding to my previous comment: This also raises the question which one should be default between the versions. I think there's an argument to be made that 3.2 should have higher priority than the 3.4 package since the 3.4 package is currently still on 3.3, which is technically their latest/"unstable" branch. Prioritising the stable branch probably makes the most sense until 3.4 is released.
(In reply to Tarulia from comment #33) > However, because they are not linked, it would easily be possible for users > to end up with any combination of the 5. For example `wx-config` from > wxQt3.4 and `wxrc` from wxBase3.2, or `wx-config` from wxGTK3.2 with `wxrc` > from 3.4. I don't imagine that would go very well. I'm not sure it's a big enough issue if wx-config is mismatched with wxrc to add even more complexity? Let's see what Neal says about whether he really wants to get rid of alternatives or not. > I'm by no means an expert on `alternatives` (I finally found out today how > to actually choose one …), but I believe that is what the `--follower` > options are for? I don't think it makes sense for them to be chosen > individually. Interesting, I'd never heard of the follower option before either.
Just noticed this while checking the build.log: ``` -- Which libraries should wxWidgets use? … wxUSE_LIBWEBP: sys (use libwebp (WebP file format)) wxUSE_NANOSVG: builtin (use NanoSVG for rasterizing SVG) wxUSE_LUNASVG: OFF (use LunaSVG for rasterizing SVG (C++17 minimum)) … ``` `builtin` denotes bundled dependencies, but it's not listed as bundled in the spec (it's in the 3rdparty directory, as well as lunasvg) And in the same section: ``` wxUSE_LIBLZMA: OFF (use liblzma for LZMA compression) ``` `xz-devel` is already installed as a dependency, so might as well turn this on. It's for wxLZMAInputStream[1] and wxLZMAOutputStream[2], though I'm not sure if they're used anywhere or if they're just for developers to use. I don't know why it's off by default either. It was added 8 years ago and never changed. The commit[3] says this was added "Prepare for using liblzma", so I think it was just forgot about afterwards. [1] https://docs.wxwidgets.org/latest/classwx_l_z_m_a_input_stream.html [2] https://docs.wxwidgets.org/latest/classwx_l_z_m_a_output_stream.html [3] https://github.com/wxWidgets/wxWidgets/commit/311b2aee5f963a9dd9c77f4db1e0304d7b30da0d
Yeah, we probably want to maximize use of system libraries. All the libraries in question are packaged in Fedora...
(In reply to Scott Talbert from comment #35) > (In reply to Tarulia from comment #33) > > However, because they are not linked, it would easily be possible for users > > to end up with any combination of the 5. For example `wx-config` from > > wxQt3.4 and `wxrc` from wxBase3.2, or `wx-config` from wxGTK3.2 with `wxrc` > > from 3.4. I don't imagine that would go very well. > > I'm not sure it's a big enough issue if wx-config is mismatched with wxrc to > add even more complexity? Let's see what Neal says about whether he really > wants to get rid of alternatives or not. > If we could get rid of it, I would like to. I worry about the complication inside of build environments with alternatives. I'm also confused why wxWidgets still doesn't offer a pkgconfig module, but at least there's a cmake module now. wx-config is annoying and awful...
OK, updates. I enabled wxUSE_LIBLZMA and wxUSE_LUNASVG. Unfortunately, using system libraries for lunasvg isn't supported currently, so we're stuck with the bundled versions for now. Also, I've found a solution to get rid of alternatives but avoid conflicting packages - I renamed the /usr/bin/wx-config's to be unique (wx-config-3.4-gtk3 and wx-config-3.4-qt). Most wxWidgets applications have a way to specify the wx-config path when building, so I think this should work. Otherwise, it is usually not hard to patch. Neal, if you want a pkgconfig module, feel free to implement one. Can we please get this package review moving? I'd like to get this done by the end of the month.
I'm not a reviewer so obviously I don't make the call, but I want to raise my concerns about this here. (In reply to Scott Talbert from comment #39) > Most wxWidgets applications have > a way to specify the wx-config path when building, so I think this should > work. Otherwise, it is usually not hard to patch. IMHO that's a risky assumption to make. I'm not sure how "Most" was determined when we don't know every wxWidgets based application out there. This is a solution I mentioned in Comment 18, since that's how Arch does it. But as I said there, in the case of Aegisub for example I can't find such an option and the only reference to wx-config in the repo is for the Mac build: https://github.com/TypesettingTools/Aegisub/blob/1ee570d9b218b60523f8b3834e3b28b76bf9df5e/packages/meson.build#L14-L19 So "just patch it" is also not going to work because there is nothing to patch (or at least nothing I can find). Besides that I don't think it's a good idea to introduce distro-specific binary names that deviate from upstream docs. This means that application upstreams and/or developers would need to patch their build system around it (if even possible, see above), which is probably not going to come off great. For Fedora packagers that's a non-issue because it stays in the Fedora ecosystem, but putting that on upstreams and developers too is a different problem. With the way it is right now even compiling the wxWidgets provided samples would fail. Those are intended for developers that have not used wxWidgets at all before and how are they supposed to know about this? I can also see these users opening "fails to build" bug reports upstream about this, which also isn't great. Granted alternatives is also somewhat Fedora/RHEL specific (if we ignore the Debian heritage), but it is a standard utility, and at least it uses standard binary names. It is also intended for exactly this usecase, so I don't understand why we'd need to get rid of it? Sure it might be complex, but many packages are. (In reply to Neal Gompa from comment #38) > I worry about the complication > inside of build environments with alternatives. I have tried a bunch of different variants with this: Installing only one variant at a time, and installing both plus wxWidgets 3.2 and swapping with alternatives, none of which gave any issues. The one thing I haven't tried is building both a GTK and Qt variant of an application in the same spec file. I don't know whether swapping the symlinks with alternatives works in mock. But on that front it's questionable how relevant that really is given that none of our packages are actually built that way. IMO that's a "we cross that bridge when we come to it" situation. The only issue I found with it is the aforementioned wxrc problem, which is solvable. That's just my 2cents.
(In reply to Tarulia from comment #40) > I'm not a reviewer so obviously I don't make the call, but I want to raise > my concerns about this here. > > (In reply to Scott Talbert from comment #39) > > Most wxWidgets applications have > > a way to specify the wx-config path when building, so I think this should > > work. Otherwise, it is usually not hard to patch. > > IMHO that's a risky assumption to make. I'm not sure how "Most" was > determined when we don't know every wxWidgets based application out there. Searching codesearch.debian.net and general wxWidgets packaging experience on Debian and Fedora over the past 10+ years. > This is a solution I mentioned in Comment 18, since that's how Arch does it. > But as I said there, in the case of Aegisub for example I can't find such an > option and the only reference to wx-config in the repo is for the Mac build: > https://github.com/TypesettingTools/Aegisub/blob/ > 1ee570d9b218b60523f8b3834e3b28b76bf9df5e/packages/meson.build#L14-L19 I did look into this briefly. It seems Aegisub uses Meson, which discovers wx-config itself. It appears you could override the wx-config location by providing a config file. > Besides that I don't think it's a good idea to introduce distro-specific > binary names that deviate from upstream docs. This means that application > upstreams and/or developers would need to patch their build system around it > (if even possible, see above), which is probably not going to come off > great. For Fedora packagers that's a non-issue because it stays in the > Fedora ecosystem, but putting that on upstreams and developers too is a > different problem. But in any event, I agree with you that having to potentially patch every application is not great. I think alternatives is the least bad approach, so I've reverted back to it.