https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: x11-wm/fvwm-2.7.0-r2 fails to compile (GCC-14-SYSTEM). Discovered on: amd64 (internal ref: gcc14_tinderbox) NOTE: (GCC-14-SYSTEM) in the summary means that the bug was found on a machine that runs gcc-14 but this bug MAY or MAY NOT BE related to the new compiler
Created attachment 881669 [details] build.log build log and emerge --info
gcc14_tinderbox has reproduced this issue with version 2.7.0-r4 - Updating summary.
This only occurs when USE=png is disabled. In /var/tmp/portage/x11-wm/fvwm-2.7.0-r4/work/fvwm-2.7.0/libs/Fpng.h There is a fair amount of code to abstract away png support using glorious technology such as: #if PngSupport typedef png_uint_32 Fpng_uint_32; #define Fpng_destroy_read_struct(a,b,c) png_destroy_read_struct(a,b,c) #else typedef unsigned long Fpng_uint_32; #define Fpng_destroy_read_struct(a,b,c) #endif It also exposes png.h to consumers of Fpng.h. In /var/tmp/portage/x11-wm/fvwm-2.7.0-r4/work/fvwm-2.7.0/libs/PictureImageLoader.c static Bool PImageLoadPng(FIMAGE_CMD_ARGS) { if (!PngSupport) { return False; } [...] And later on in the function, it uses various typedef'ed Fpng* typedefs and defines, but also uses, unconditionally, png_get_color_type(Fpng_ptr, Finfo_ptr) no define to hide it. I personally think the entire thing is silly and standard technology here is to ifdef out the entire function to a stub. Note: the linked PR is broken. It unconditionally depends on png.h which is quite missing the point. We can just as easily remove the USE flag and unconditionally enable png support.
Eli, does something like this look alright to you? I reason that since PNG support is not enabled, we shouldn't be needing this. diff --git a/libs/PictureImageLoader.c b/libs/PictureImageLoader.c index c615081..0a91400 100644 --- a/libs/PictureImageLoader.c +++ b/libs/PictureImageLoader.c @@ -468,6 +468,7 @@ Bool PImageLoadPng(FIMAGE_CMD_ARGS) Fpng_set_expand(Fpng_ptr); } +#if PngSupport /* TA: XXX: (2011-02-14) -- Happy Valentines Day. * * png_get_color_type() defined in libpng 1.5 now hides a data member @@ -492,6 +493,7 @@ Bool PImageLoadPng(FIMAGE_CMD_ARGS) { hasg = 1; } +#endif if (hasa) Fpng_set_expand(Fpng_ptr);
ci has reproduced this issue with version 2.7.0-r5 - Updating summary.
(In reply to Eli Schwartz from comment #3) > Note: the linked PR is broken. It unconditionally depends on png.h which is > quite missing the point. We can just as easily remove the USE flag and > unconditionally enable png support. Yes, `png` is an essential feature for fvwm, with `configure` having a big warning if it is disabled. https://github.com/fvwmorg/fvwm/blob/02f28e29610d482360f4ec466a4527ccd3c3feae/configure.ac#L837 Let's just drop the USE in the short term, it's really not tested without it. Longer term, is there any reason to keep legacy fvwm in-tree? It's not maintained upstream (or in Gentoo), the build system here likely has a number of bugs that were fixed in later versions, not to mention general quality of life improvements. We already have `x11-wm/fvwm3` to not collide with this package. I'd be prepared to drop this and maybe even pkgmove fvwm3 (or not...).
(In reply to Matt Jolly from comment #6) > Longer term, is there any reason to keep legacy fvwm in-tree? It's not > maintained upstream (or in Gentoo), the build system here likely has a > number of bugs that were fixed in later versions, not to mention general > quality of life improvements. > I know of someone using it still although I can ask if they would try fvwm3. > We already have `x11-wm/fvwm3` to not collide with this package. I'd be > prepared to drop this and maybe even pkgmove fvwm3 (or not...). I don't think a pkgmove is appropriate -- they're different upstream projects and importantly have incompatible configurations.
I vote that we last-rite x11-wm/fvwm with a message pointing to x11-wm/fvwm3 as a migration path. Maybe we will shake out an interested maintainer, though as all upstream effort is on fvwm3 now users are probably better off migrating. > they're different upstream projects and importantly have incompatible configurations. I'd probably have made them both subslots of x11-wm/fvwm if I'd thought about it when adding the package instead of the blocking dependency: I sometimes kick myself for this as we don't support installing the two simultaneously via transforms. We could transform fvwm2 via a revbump to enable that... Just put a 2 at the end of all the bins, not supported in fvwm3 meson packaging (yet). Re different configurations, I asked upstream: Fvwm2 Configs will work with fvwm3 however some massaging is likely to be required. There isn't (currently) an fvwm-convert script for fvwm3 which maybe we can help with. The following migration guide is considered comprehensive: https://github.com/fvwmorg/fvwm3/discussions/878 It should end up in any mask message.
I use fvwm sometimes on older or slower machines (I have it installed on arm32). I was not aware of fvwm3, I can try that. But why last rite it? This is the only open bug, and forcing png to always on sounds entirely reasonable.
1. Unmaintained in Gentoo 2. Effectively archived upstream 3. FVWM3 (the fvwmorg successor) does everything this does, better, and without significantly increased resource usage. 4. I did some work on fvwm3 recently to port the build system and given the common code some of those issues are bound to exist here. If you (or someone else) is willing to step up as a maintainer I don't really have an objection to keeping it around; we're talking about a trivial fix for the package ~11 months after the bug was logged. If not I don't see a point in waiting until the next issue is found when fvwm3 is maintained and covers the use case with an apparently straightforward migration. We may as well rip that band-aid off now :)
Ok. I'll test fvwm3 this weekend and I'll see if I want to take this.
I have some tentative plans to work on keywording fvwm3 where I have hardware (x86 aarch64 SPARC) and intend to actually stabilise it from this release, so we can assume parity between the packages "soon". I've had a few testimonials saying that the migration from 2->3 was straightforward; please reach out on IRC (#fvwm) if you get stuck.
I tried fvwm3, works fine for me, I have nothing against the last rites.
