SoftFever
Update Ubuntu 20.04 runners to Ubuntu 22.04
Deprecation of Ubuntu 20.04 runner images has begun the deprecation process and will be fully deprecated 4/1/25. This prepares for that by moving the older Ubuntu runner to 22.04
https://github.com/actions/runner-images/issues/11101
My personal version has building working on 22.04 https://github.com/SoftFever/OrcaSlicer/compare/main...NanashiTheNameless:OrcaSlicer:main
My fork is not Pull request safe or mergable as I has some other workflow changes, but it could be a good place to cherry-pick for differences to see why your PR does not work
Thank you @Ocraftyone
I will deprecate AppImage build to reduce the maintenance cost. So this change is not requried anymore
FYI I would advise against this, some linux distros cannot use flatpak, so having an AppImage for the sake of the linux community would be kind of you.
Thank you @Ocraftyone
I will deprecate AppImage build to reduce the maintenance cost. So this change is not requried anymore
Can confirm my earlier statement, I am investing exactly $0 in github build costs and have been able to build and maintain a version with AppImages still supported all without losing any functionality (excluding mac notarizing/code signing as I have no means to do it) All while staying as close to upstream as possible! https://github.com/NanashiTheNameless/OrcaSlicer/ Differences as of the time of writing: https://github.com/SoftFever/OrcaSlicer/compare/9c5c7c4c9217d2e28f943a46b90fa13a2abd6849...NanashiTheNameless:OrcaSlicer:299cacf18b8596125fe83ab3ae54a70c5e0fd91b
@SoftFever correct me if I'm wrong, but I believe it is the development time cost and the fact that two different appimages need to be created to support 20.04. I have an idea on a way to make it so one appimage would be compatible with both, but I haven't had much time to develop it
@SoftFever correct me if I'm wrong, but I believe it is the development time cost and the fact that two different appimages need to be created to support 20.04. I have an idea on a way to make it so one appimage would be compatible with both, but I haven't had much time to develop it
It's mostly just building under both environments, besides 20.04 (Focal) is out of standard support (see image below), So we only really need to support 22.04 (Jammy) and 24.04 (Noble) as 24.10 (Oracular) will have similar compatibility to its predecessor.
https://ubuntu.com/about/release-cycle
Edit: For clarity ESM requires an Ubuntu Pro license and as such can be ignored for this as we are considering regular users. people who would need it on 20.04 (Focal) can always self-build.
@SoftFever correct me if I'm wrong, but I believe it is the development time cost and the fact that two different appimages need to be created to support 20.04. I have an idea on a way to make it so one appimage would be compatible with both, but I haven't had much time to develop it
Yes, I meant development cost.
@NanashiTheNameless Can you elaborate on the use case where we can only use AppImage but not Flatpak? I'm just considering this to reduce the development cost. If there's such a case, we can reconsider. It's not a big issue.
My stance is to add flatpak and keep appimages as some people (myself included) dislike the way flatpak isolates the filesystem, (results in all pinned folders not being found by flatpak apps) Ultimately its your choice, whether you keep or remove it, and I will keep my fork with both alive for as long as I can. but i still think it would be wise to have both
@Ocraftyone Thank you. FYI. I will keep 24.04 AppImage build and deprecate the 20.04 build.
Ref to #9458 we will only keep the AppImage built with Ubuntu 24.04
Sounds good!