This probably also happens with 3.0.5.1 I worked on filezilla build failure (bug #895642), which was caused by wx-config reporting: % wx-config --version 3.2.2.1 This breaks the default m4 macros for wxWidgets versioning as it does not expect the subversion to be there, from a git tag checkout of 3.2.2: % ./wx-config --version 3.2.2 (thanks wxWidgets upstream in https://github.com/wxWidgets/wxWidgets/pull/23289) I don't know the details for all the version substitution sed calls done in the ebuild (https://gitweb.gentoo.org/repo/gentoo.git/tree/x11-libs/wxGTK/wxGTK-3.2.2.1.ebuild#n111), is it because of the -gtk3 suffix? Fixing should probably update all the variables to always use ver_cut to get the proper range: https://devmanual.gentoo.org/ebuild-writing/variables/index.html#version-and-name-formatting-issues WXVERSION is probably the one causing the root bug WXRELEASE can also use ver_cut (it already has some shell string substitution) Not sure about WXSUBVERSION
I think 3.0.5.1 would work because it has WXVERSION=${WXSUBVERSION%.*} which evaluates to 3.0.5 while 3.2.2.1 has WXVERSION=${PV} # 3.2.1 which evaluates to 3.2.2.1, despite the outdated comment. Looks like this had been in the past handles by tweaking WXSUBVERSION to be ${PV}.0-gtk3 for releases with 3 components and ${PV}-gtk3 for releases with 4 components, which is fiddly and prone to mistakes like this. Some sort of ver_cut, now that we have that available, would be nicer indeed to have it reliably always work right.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=86d51f8fb503db6f6f023efdb1ebca4590404fa7 commit 86d51f8fb503db6f6f023efdb1ebca4590404fa7 Author: Arsen Arsenović <arsen@gentoo.org> AuthorDate: 2023-03-30 16:49:32 +0000 Commit: Arsen Arsenović <arsen@gentoo.org> CommitDate: 2023-03-30 17:28:11 +0000 x11-libs/wxGTK: Fix version handling in 3.2.2.1 Closes: https://bugs.gentoo.org/895982 Signed-off-by: Arsen Arsenović <arsen@gentoo.org> x11-libs/wxGTK/{wxGTK-3.2.2.1.ebuild => wxGTK-3.2.2.1-r1.ebuild} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
I've managed to build Filezilla with this patch, so I hope that suffices.
Yes the output looks good to me and indeed filezilla-3.63.2.1 emerged fine without the workaround patch (I will drop it as we only have fixed wxGTK-3.2.2.1-r1 now), thanks!
