Update SLiM.spec to work with Qt 6 for Fedora and openSUSE

[bryce-carson]

The enterprise operating systems (RHEL, and the EPEL repos too) aren't building successfully with this spec file, but the failed build artifacts aren't shipped to those users so no worries.

The successfully built artifacts for Fedora and openSUSE are live and being shipped (I've already upgraded from the COPR, so we're good to go and release in my opinion).

[bryce-carson]

Because only a subset of our supported RPM-based operating systems have successful builds, I think it's okay to release and announce, but I won't bother building on COPR from the tagged version until we have a working RPM spec file that works for all of the current operating systems (potentially less RHEL 8).

I'm comfortable making a new release of the RPM package, which has it's own build version, when the spec file is really ready. The RPM package is currently packaging version 4.3 of the software, and the package itself is version 4.3-1, and after fixing the RPM spec issues it would be re-released as 4.3-2, but it will package the exact same software version so it won't require a point release on your part.

The enterprise users will be able to pick up the new version of the software the package for it is ready; everybody else is ready to forge ahead.

[bryce-carson]

I won't bother building on COPR from the tagged version until we have a working RPM spec file that works for all of the current operating systems (potentially less RHEL 8).

Actually, if you tag now with this spec file absorbed into the SLiM sources, then I will need to continue building the packages on COPR from my fork until you tag a minor release which incorporates the yet to be written RPM spec file fixes. Thus, when people inspect the package it won't appear that the sources come from the official GitHub, they'll see it came from an uploaded SRPM, but given I'm the maintainer of the package for four years now I don't think even the enterprise sysadmins would be surprised or concerned. They can always reach out if they're uneasy (or do the smart thing and build it themselves).

Forge ahead! 🚀

[bhaller]

Hi @bryce-carson. See email for some thoughts. Beyond what I wrote there, here I guess I'll add: my primary concern is to avoid confusion in the release rollout. I don't want to need to say "Users on platforms A, B, C can install now to get SLiM 4.3, but users on D, E, F will need to wait a while until the installer gets fixed for those platforms." It just makes for a confusing story. I already have to do that for Windows, because the pacman crank turns so slowly; I'd like to avoid having to complicate the story even further.

But. Do I understand what you wrote above to mean that for users on A, B, C, they are already getting SLiM 4.3, as of now? I wasn't expecting that. If that is the case, then perhaps my hand is forced, and I need to do the release immediately. People getting a version of SLiM that hasn't been announced/released yet is not good. So please let me know if that's the case, and I'll roll the release immediately. Thanks!

[bryce-carson]

Do I understand what you wrote above to mean that for users on A, B, C, they are already getting SLiM 4.3, as of now? I wasn't expecting that. If that is the case, then perhaps my hand is forced, and I need to do the release immediately. People getting a version of SLiM that hasn't been announced/released yet is not good. So please let me know if that's the case, and I'll roll the release immediately. Thanks!

That is the case, actually. I can revoke/delete the build, so that anyone who hasn't manually or automatically upgraded the package in the last two days (that is how long it has been out) won't be able to get it. I'll do that, because I don't want to force your hand and impress immediacy upon you when the release process is already stressful on your side of the fence.

[bhaller]

OK, let's do that; back to 4.2.2 for now. It sounds like you've got time to keep working on getting the remaining platforms going, and hopefully that won't be too difficult. Once that's done, update this PR I guess, then I'll merge, and then we'll do the release. Thanks!

[bryce-carson]

OK, let's do that; back to 4.2.2 for now. It sounds like you've got time to keep working on getting the remaining platforms going, and hopefully that won't be too difficult. Once that's done, update this PR I guess, then I'll merge, and then we'll do the release. Thanks!

I realized I could fork the COPR project and do my test builds for the various systems there, rather than only testing locally and then testing on all the other systems on the live COPR repo.

This won't happen again. Whenever we're doing a release I'll create a temporary fork and nobody will pull from that.

[bhaller]

Saw your latest commit. Hmm. Is there a way to just do an ls -l of the build directory, to see what is conflicting with cmake/make? Is this existing eidos thing a directory, or a file, or what? Where did it come from?? You could do it once at the start, and again after cmake runs?

[bryce-carson]

Is there a way to just do an ls -l of the build directory, to see what is conflicting with cmake/make?

There is! Not only can I call any shell command I like, but there's also an embedded Lua interpreter in RPM.

I realized that you probably haven't been reading the discussion between the Red Hat engineer and myself because you might not have gone through the trouble to create an account with Red Hat on their Bugzilla and Jira. I'll attach a screen shot of the discussion to this comment so you may read through it.

Is this existing eidos thing a directory, or a file, or what?

Nick Clifton---the engineer assigned the issue---concluded from reading the build logs from RHEL 8 and RHEL 9 builds I provided that RHEL 8's version of rpmbuild, or CMake itself, are deciding to do an in-source build (which we know is delicate, and in this case quite broken and the source of our troubles). We're not certain why the discrepancy exists, but it appears as a regression, yes, because RHEL 8 builds worked before without so much trouble.

Where did it come from?? You could do it once at the start, and again after cmake runs?

If my current build fails I'll read the documentation on enabling SSH access to the build machine and seeing if I can use the RPM REPL on that machine to debug the issue directly. At the very least, it'll let me explore the file system more easily than embedded stdout and stderr statements with echo in the RPM spec file.

Printable HTML version of the Jira issue (RHEL-49714.zip)

[bryce-carson]

https://frostyx.cz/posts/ssh-access-to-copr-builders

[bhaller]

@bryce-carson Thanks for the log; yes, I'm not following that conversation at present. :-> Interesting.

OK, so it is indeed because an in-source build is being done, and it is agreed that that is a regression in RHEL 8, and RHEL 8 is still being maintained by them (i.e., has not been end-of-lifed). So to me, we're now back to the old question: can they, and will they, fix this bug on their side? Maybe, for time reasons, it nevertheless makes sense for you to find a workaround; but if they were willing and able to fix the bug on their side, that would be good, especially if it turns out that you're not able to find a workaround. And if they could do a fix with a quick turnaround time, maybe your workaround labors would not even be needed. Up to you how to proceed, but I'm kind of annoyed on your behalf that so much of your time is being spent finding a workaround for their bug. :-O (And I'm surprised we're not just one of dozens or hundreds of packages being bitten by this regression!)

[bhaller]

https://frostyx.cz/posts/ssh-access-to-copr-builders

That is so cool.

[bryce-carson]

Even with the SSHA access I didn't have a lot of success in determining why the build was failing. I'm sure I could determine why, but I wasn't able to get something working yesterday with interactivity.

I did learn that the version of CMake is a little older, and the version of rpm itself is a little older, and there are certain differences I could see but didn't get to play with very well.

I can try again later, but I know you're getting impatient.

New issue! Having used the SSH builders it seems that all builders I try to use are now failing for some odd backend reason. I suspect the connection didn't terminate cleanly, despite following instructions, so I'm going to ask the Fedora Copr peoppe directly on AskFedora tonight or tomorrow.

[bhaller]

Even with the SSHA access I didn't have a lot of success in determining why the build was failing. I'm sure I could determine why, but I wasn't able to get something working yesterday with interactivity.

Huh. OK, so. There are a few steps to this, right?

• Detect that you're on RHEL 8, and/or detect that you're building directly inside the source directory
• Make a subdirectory for the build to go into
• cd to that new directory before the build starts, so it gets used
• probably redefine some build-system symbols to point to that new build directory so the build system co-operates

Which of these steps is the hard part? I'm guessing the last one? Are the symbols that you need to redefine just not well documented? Can you do a comprehensive dump of all build-system symbols that have been defined, to find all the hidden ones you need to fix?

I did learn that the version of CMake is a little older, and the version of rpm itself is a little older, and there are certain differences I could see but didn't get to play with very well.

I can try again later, but I know you're getting impatient.

Well, yes and no.

• There is an eventual deadline that this HAS to be out in time for people in the upcoming NYC workshop to update to it. That deadline is still a ways away, since the workshop starts Oct. 28th; but it is well before Oct. 28th itself, since people in the workshop need LOTS of lead time to figure out how to install, deal with the issues that inevitably bite some of them, etc. Given that the pacman crank takes a week (at least) to turn, let's say the end of September.

• There is the simple fact that this release has bug fixes and improvements that I want people to get access to, including fixes to crashes, etc. There's no hard deadline on this, but there are definitely users out there who are waiting, day by day, for this release to happen because it will fix a problem that they are experiencing.

• There is my own work. At this point, I have decided to make a new branch for post-4.3 work and start developing over there. So I am not really blocked at all. The only downside, for my own work, is that if further changes do becoem necessary for the 4.3 release, my life will get a little complicated with branching, merging, rebasing, etc. – git stuff that I'm not good at – but I'll survive. :->

So yes, I'm impatient, and some other folks are too, but the only real hard deadline is still several weeks out. I'd be pretty unhappy if this issue pushed the release all the way out to that hard deadline, though.

New issue! Having used the SSH builders it seems that all builders I try to use are now failing for some odd backend reason. I suspect the connection didn't terminate cleanly, despite following instructions, so I'm going to ask the Fedora Copr peoppe directly on AskFedora tonight or tomorrow.

Huh, very weird. Nothing is ever simple. I guess that SSH feature was experimental, and now you know why. :->

Well. Is everything done except this RHEL 8 issue? Builds for all other platforms now, installs/uses Qt5 vs. Qt6 as appropriate, etc.? If that is not the case, then please keep plugging away until you've got all of that working; that's essential. If we're missing only RHEL 8 now, then I'd say at this point it's up to you. If you feel like it's a solvable problem and you want to solve it, then I won't stand in your way; it would be great to be installing properly on all platforms. If you're tearing your hair out and you're out of ideas, and you want to give up on RHEL 8, I'm fine with that too. In the end, telling most Linux people they have to build from sources is not a major hardship for them; Linux people are generally pretty comfortable at that level. (The installer not working for macOS or Windows would be a much bigger deal, since people on those tend to be more clueless about building from sources.) And RHEL 8 has been broken for a little while, right? Last release or two? And we've gotten almost no complaints, right? Rupert and maybe 1-2 other people? So I'm just not sure how worthwhile it is to keep trying to find a workaround for their bug. (I'm also surprised by how little help they are giving you with this, to be frank; there must be a guy who maintains their build system who could provide you with a correct workaround in half an hour, and apparently they're not interested in having that guy help you, which kinda sucks given that, again, it's their bug. But maybe I'm being unfair; maybe they're helping you more than I see.)

So. Your choice. What do you think?

[bryce-carson]

Even with the SSHA access I didn't have a lot of success in determining why the build was failing. I'm sure I could determine why, but I wasn't able to get something working yesterday with interactivity.
Huh. OK, so. There are a few steps to this, right?

• Detect that you're on RHEL 8, and/or detect that you're building directly inside the source directory
• Make a subdirectory for the build to go into
• cd to that new directory before the build starts, so it gets used
• probably redefine some build-system symbols to point to that new build directory so the build system co-operates

Which of these steps is the hard part? I'm guessing the last one? Are the symbols that you need to redefine just not well documented? Can you do a comprehensive dump of all build-system symbols that have been defined, to find all the hidden ones you need to fix?

I tried to do a dump using the documented macro, but apparently it is undefined on RHEL 8, which doesn't make sense because this documentation doesn't state that these macros are unavailable on RPM 4.14.

Diagnostics

Macro	Description	Introduced
%trace	toggle print of debugging information before/after expansion
%dump	print the active (i.e. non-covered) macro table
%__file_name	current file (if parsing a file)	4.15
%__file_lineno	line number in current file (if parsing a file)	4.15

New issue! Having used the SSH builders it seems that all builders I try to use are now failing for some odd backend reason. I suspect the connection didn't terminate cleanly, despite following instructions, so I'm going to ask the Fedora Copr peoppe directly on AskFedora tonight or tomorrow.

Huh, very weird. Nothing is ever simple. I guess that SSH feature was experimental, and now you know why. :->

I suppose. I am able to make builds again now regardless.

Well. Is everything done except this RHEL 8 issue? Builds for all other platforms now, installs/uses Qt5 vs. Qt6 as appropriate, etc.?

That is the case now, yes.

If that is not the case, then please keep plugging away until you've got all of that working; that's essential. If we're missing only RHEL 8 now, then I'd say at this point it's up to you. If you feel like it's a solvable problem and you want to solve it, then I won't stand in your way; it would be great to be installing properly on all platforms.

It's not so bad, it's just annoying because the documentation is a little terse and isn't "ergonomic", sometimes I'll miss something or it won't be explained perfectly and I'll misuse something.

The %dump macro, for instance, appears like it's only intended use is to be placed at the beginning of an RPM spec file and then that spec file processed with RPM, but without actually using it during rpmbuild. I tried using %trace during a build and that caused some issues, so perhaps it is similarly only supposed to be used during a "parse this spec file" call to RPM, and never intended to be used when running rpmbuild.

If you're tearing your hair out and you're out of ideas, and you want to give up on RHEL 8, I'm fine with that too.

Well, I wasn't exactly "losing my religion" (getting really frustrated) like one of the commit messages said the other day. It's alright; I don't mind plugging away. Once a puzzle presents itself I usually like to complete it.

In the end, telling most Linux people they have to build from sources is not a major hardship for them; Linux people are generally pretty comfortable at that level. ... RHEL 8 has been broken for a little while, right? Last release or two? And we've gotten almost no complaints, right? Rupert and maybe 1-2 other people?

We haven't released for RHEL 8 since 4.0.1, so I'd like to give the administrators of these clusters a chance to ship the new version with bugfixes. It isn't too big of a deal to build from source, no, but I recall hearing from that Debian user in France that having a binary package makes installing the software across hundreds of machines much easier (I think in that case it's actually multiple machines and not a cluster). The RHEL users we have are each on clusters, I believe, and one of them positively said that they provide SLiMgui through their VNC service.

While furnishing software to their users is their job, it's been my goal for some time to prepare the RPM shipping the binaries for as many people as possible. Dropping a supported operating permanently because of a lack of investment on my part in learning what is truly supported and unsupported isn't my fashion; it just creates a puzzle that I'll wish I had solved until I forget about it. Someone may eventually ask about it anyways (e.g., "Hey, we see on the mailing list that a much newer version of SLiM is available. Can you update the package?").

I'd only spent about an hour, maybe two, on the issue. I also working quickly, and iterating, rather than stepping back and really analyzing the issue as best as possible. Even now I'm running into some silly issues which I'm not expecting because I might be misapplying a macro or two (%echo, apparently, should never be on its own line, because it'll expand and echo to stdout, but then it'll be parsed as a shell command and oddly fail...).

So I'm just not sure how worthwhile it is to keep trying to find a workaround for their bug. (I'm also surprised by how little help they are giving you with this, to be frank; there must be a guy who maintains their build system who could provide you with a correct workaround in half an hour, and apparently they're not interested in having that guy help you, which kinda sucks given that, again, it's their bug. But maybe I'm being unfair; maybe they're helping you more than I see.)

So. Your choice. What do you think?

I think I've recieved a fair amount of help from the RH engineer considering there wasn't actually an issue in RHEL 8, it's an issue with rpmbuild which that engineer isn't responsible for; that engineer was responsible for the binutils package, but kept up with the issue on Jira and trying to help me out.

I'm asking in the Fedora Discourse and the Fedora Discord now, but I'm also much closer to a work-around the (non?-)issue myself. The communication will turn into a nice blog post, likely, and then an improvement to some documentation hopefully.

I'm working on it, and we're almost there. Shouldn't be too bad, but I'll keep you in the loop and I won't delay the release otherwise.

[bhaller]

Hi @bryce-carson. OK, I think I understand. I'm happy to wait. Let's get this solved. Thanks!

[bryce-carson]

@bhaller, the last commit permits a proper out-of-source build and all the targets are successfully built (at long last!). However, there is a problem during the install stage. I'm not sure why! I'm leaving this PR until tomorrow now, and taking a break because I opened a discussion on AskFedora and hopefully someone responds with some helpful comments by the time I return to the issue.

[bhaller]

Wow! OK, great! Progress! I'll wait to hear back on the next step. :->

[bhaller]

Hi @bryce-carson. Wondering how things are going. What is the problem during the install stage? Did you hear back from the Fedora folks?

[bryce-carson]

Hi @bryce-carson. Wondering how things are going. What is the problem during the install stage? Did you hear back from the Fedora folks?

I'm going to try to figure it out tonight.

I haven't had any emails yet, but I'll check regardless.

[bryce-carson]

https://discussion.fedoraproject.org/t/rhel-epel-8-builds-fail-due-to-differences-in-cmake-or-defined-rpm-macros/130941/1

No responses yet.

[bryce-carson]

It looks like the %install step is failing because %cmake_install is looking in the current directory, not the build directory which was manually passed to CMake.

RHEL 9

gmake[1]: Leaving directory '/builddir/build/BUILD/SLiM-4.3/redhat-linux-build'
/usr/bin/cmake -E cmake_progress_start /builddir/build/BUILD/SLiM-4.3/redhat-linux-build/CMakeFiles 0
+ RPM_EC=0
++ jobs -p
+ exit 0
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.eY8r2f
+ umask 022
+ cd /builddir/build/BUILD
+ '[' /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64 '!=' / ']'
+ rm -rf /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64
++ dirname /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64
+ mkdir -p /builddir/build/BUILDROOT
+ mkdir /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64
+ cd SLiM-4.3
+ DESTDIR=/builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64
+ /usr/bin/cmake --install redhat-linux-build
-- Install configuration: "Release"
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/bin/slim
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/bin/eidos
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/applications
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/applications/org.messerlab.slimgui.desktop
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/icons
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/icons/hicolor
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/icons/hicolor/scalable
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/icons/hicolor/scalable/apps
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/icons/hicolor/scalable/apps/org.messerlab.slimgui.svg
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/icons/hicolor/scalable/mimetypes
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/icons/hicolor/scalable/mimetypes/text-slim.svg
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/icons/hicolor/symbolic
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/icons/hicolor/symbolic/apps
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/icons/hicolor/symbolic/apps/org.messerlab.slimgui-symbolic.svg
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/metainfo
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/metainfo/org.messerlab.slimgui.appdata.xml
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/metainfo/org.messerlab.slimgui.metainfo.xml
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/mime
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/mime/packages
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/share/mime/packages/org.messerlab.slimgui-mime.xml
-- Installing: /builddir/build/BUILDROOT/SLiM-4.3-1.el9.x86_64/usr/bin/SLiMgui

RHEL 8

gmake[2]: Leaving directory '/builddir/build/BUILD/SLiM-4.3/x86_64-redhat-linux-gnu'
[100%] Built target SLiMgui
gmake[1]: Leaving directory '/builddir/build/BUILD/SLiM-4.3/x86_64-redhat-linux-gnu'
/usr/bin/cmake -E cmake_progress_start /builddir/build/BUILD/SLiM-4.3/x86_64-redhat-linux-gnu/CMakeFiles 0
+ exit 0
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.yNgSG3
+ umask 022
+ cd /builddir/build/BUILD
+ '[' /builddir/build/BUILDROOT/SLiM-4.3-1.el8.x86_64 '!=' / ']'
+ rm -rf /builddir/build/BUILDROOT/SLiM-4.3-1.el8.x86_64
++ dirname /builddir/build/BUILDROOT/SLiM-4.3-1.el8.x86_64
+ mkdir -p /builddir/build/BUILDROOT
+ mkdir /builddir/build/BUILDROOT/SLiM-4.3-1.el8.x86_64
+ cd SLiM-4.3
+ DESTDIR=/builddir/build/BUILDROOT/SLiM-4.3-1.el8.x86_64
+ /usr/bin/cmake --install .
CMake Error: Error processing file: /builddir/build/BUILD/SLiM-4.3/cmake_install.cmake
error: Bad exit status from /var/tmp/rpm-tmp.yNgSG3 (%install)
    Bad exit status from /var/tmp/rpm-tmp.yNgSG3 (%install)

[bhaller]

It looks like the %install step is failing because %cmake_install is looking in the current directory, not the build directory which was manually passed to CMake.

Oh, that's annoying. I guess your cmake build uses the custom build path, but the separate call to /usr/bin/cmake --install doesn't get that path. Can you pass the custom path again, to that call, somehow? Anyhow, you understand this stuff way better than I do. Good luck. :-O

[bryce-carson]

It looks like the %install step is failing because %cmake_install is looking in the current directory, not the build directory which was manually passed to CMake.

Oh, that's annoying. I guess your cmake build uses the custom build path, but the separate call to /usr/bin/cmake --install doesn't get that path. Can you pass the custom path again, to that call, somehow? Anyhow, you understand this stuff way better than I do. Good luck. :-O

Yep, I can and did. Now it's complaining because I didn't specify the fake root to install into and tried to install on the real root. Once I fix that (which isn't hard) it should all be good to go.

I'm just taking a food nap. I ate too much McDonald's. Once I wake up and I'm not face-planting on my keyboard I'll finish up.

[bhaller]

Yep, I can and did. Now it's complaining because I didn't specify the fake root to install into and tried to install on the real root. Once I fix that (which isn't hard) it should all be good to go.

I'm just taking a food nap. I ate too much McDonald's. Once I wake up and I'm not face-planting on my keyboard I'll finish up.

OK great. (Well, maybe "too much McDonald's" is not great. :->) If I can make a small request here: if you haven't already, please add some comment lines outlining what's going on with the various steps, what you found out in your investigations, etc. TBH I live in fear of the day when you no longer have time to maintain this stuff; if/when that day comes, comments will be extremely useful for whoever inherits this from you. Thanks a bunch, as always!

[bryce-carson]

@bhaller This is ready to merge.

I wasn't able to do a final test build on Fedora 41 and Fedora Rawhide because COPR is having build issues with those. GPG keys have changed and everyone is having problems, but we shouldn't have problems by the time we release because the package is "Fedora native" and was working without issue. No need to worry.

[bhaller]

OK, merged! Yay! Thanks again!