4.3 release process #468
Comments
Cool, a new minor version of SLiM! I'll do some test builds on my local machine and see how things go; my concern is with the builds for (open)SUSE; they have different package names which I've had trouble identifying before. If needed, I'll talk to their excellent volunteer packagers in their Discord for assistance, but I'm hoping I can just do a search and replace too. For Fedora, the new package version/name is simply I'll do some work for this on Sunday, I think. |
Thanks, that sounds great. :-> |
|
I'm not getting to this today, @bhaller. I will make a little time for it tomorrow evening. |
While connected to a COPR VM and chrooted into an EPEL 8 environment, it appears that the EPEL 8 build environment has a CMake which: 1. Isn't directed to create an out of source build, for whatever reason (I had troubles determining exactly what was going on) 2. Assumes that the current directory is both the source and build directory (the current directory being the source directory which is changed to by rpmbuild automatically, I think). As far as I can tell, the easiest way around issue MesserLab#440 to enable MesserLab#465 and MesserLab#468 is to make the build directory and change to it before calling cmake --build, but this only works if we manually specify the source and build directory when calling `%cmake`, which shouldn't be too delicate, as long as the definition of `%cmake` doesn't include source and build directories on other distributions. I'm out of practice with rpmbuild and COPR's finer details, or I never was practiced in using these at this level, and I don't know a better way of debugging the build process at this point after investigating through SSH than to just submit a new build. I got stuck trying to create a new SRPM with the edited spec file. It's easier to just edit on GitHub like this and have an automatic build tell me if things are going to work as I expect this might. If it doesn't then I'm calling in reinforcements to investigate the issue for me and offer their support (the Fedora community!).
|
Hi @bryce-carson @grahamgower @rdinnager @bernard-kim! Sorry for the delay, but this roll of this release has now resumed. Bryce fought mighty battles to get the various Linux installers working, including reviving the RHEL 8 build that has been broken (due to a bug on their end) since SLiM 4.0.1 or something. I just finished fighting my own battles getting the conda build for Windows working again after it spontaneously broke, with extensive help from a guy in their support space. But the release is now tagged ( So! Please check in here regarding your respective installers. Once Arch and the other Linux platforms are ready, I'll announce on slim-discuss; the Windows pacman crank will presumably take longer to turn as usual, so I won't wait for it. Let's get this out the door! :-> |
|
By the way, @bryce-carson, I suppose the script at https://github.com/MesserLab/SLiM-Extras/blob/master/installation/DebianUbuntuInstall.sh for Debian and Ubuntu needs to be updated to use Qt6 instead of Qt5, when appropriate? It looks like it patches the |
https://copr.fedorainfracloud.org/coprs/bacarson/SLiM-Selection_on_Linked_Mutations/build/8028803/ |
Oh, my my! You're right. I'll get to that sometime soon. |
That is all green, yay! Fantastic. I have checked the checkbox above for the COPR-based platforms. |
|
The Arch installer is now updated. |
Thanks @grahamgower! |
|
OK, thanks @bryce-carson for updating the install script for Ubuntu and Debian! I gather @rdinnager is working on turning the pacman crank, but that always takes a long time due to human review of the package, so I think I will now proceed with the release! Stay tuned. |
|
It was a long process, but I'm glad it's over. One of the major changes is the use of the GitHub API, so in the future, once any bugs are shaken out of it (as they crop up) we won't need to update the version of SLiM which it installs. It will always install the latest version. The Org document which explains the installation script's implementation is, of course, best viewed in Emacs where it was written, but it can be viewed in a rendered form here. |
|
@bhaller, I learned that curl is not installed be default on either Debian or Ubuntu, and wget is always installed by default. I removed the usage of curl inside the script, but the SLiM manual installation instructions cover the cases where users have either installed or a preference. That's only for downloading the script. It should work fine either way, I hope. The only downside I see is if the manual instructs users to pipe the script directly into POSIX sh, rather than saving the script. I think if that happens one of the checks I wrote will simply reject the script. If that happens, they'll be instructed by the script to launch it manually with the BASH shell, not the POSIX |
|
OK, all duly noted. First time I've ever seen a "literate program", interesting! Thanks @bryce-carson! (Nice that it won't need to be updated for new versions any more, that's cool. :->) |
|
The release has now been announced at https://groups.google.com/g/slim-discuss, so it's official! (People have been unwittingly installing it for days, though. :->) |
Hi everybody! Here is a new issue to track SLiM release 4.3, which is ready to roll.
Remember, for this release SLiMgui is shifting from Qt5 to Qt6 on modern platforms (more info here: #465), although you might wish to keep building it against Qt5 on older platforms if you have control over that. If you do not have control over that for your installer, then please just choose Qt6; it has been out for a pretty long time now (they're on Qt 6.7.2), so it's time for the changeover. Users on such old platforms that they need Qt5 will need to build manually, in that case; not the end of the world, and perhaps will encourage them to update. :->
I have not yet created the v4.3 tag, and the Release on GitHub does not yet exist. That probably means that none of you can take action quite yet. I will post here again when those things happen; please stay tuned. I'm creating this issue earlier in the process than usual because:
@bryce-carson, I have updated SLiM.spec with the new version number, but I have not attempted to switch it over to specifying Qt6 instead of Qt5; I need you to do that, since package names might have changed, dependencies might have changed, etc., so it might be more technical than just a search-replace. I wasn't sure if I needed to wait to tag the release until SLiM.spec is final, since it lives inside the GitHub repo; so I'm waiting on this issue before tagging. Please submit a PR with the necessary SLiM.spec changes. Thanks!
Once that is done and the release is tagged, here's the usual checklist:
IIRC, @bernard-kim has volunteered to help manage the pacman crank, and the plan was that he would turn the crank this time around to get the practice doing it, presumably with help from @rdinnager. If now is not the best time, and it makes more sense for @rdinnager to just do the crank, that's fine too of course. I'll let you guys co-ordinate on that (here on this issue, if you want to); thanks!
The text was updated successfully, but these errors were encountered: