OrcaSlicer
OrcaSlicer copied to clipboard
SoftFever
Flatpak build
This is here so that I can link #3949 and #1670, along with testing the CI. THIS IS NOT FINISHED, AT ALL.
(imho it's really hard to find external work to show what's going on in an issue so I'm linking it here)
Flatpak build is ready, but I need to fix CI and add a CI job for flatpak.
@powpingdone it looks like github CI VM doesn't get enough free disk space to build a flatpak. Maybe it's time to ask help from flatpak experts?
@powpingdone I set up the current CI that is being used and I want to see if I can help with fixing the flatpak building. I personally don't have much experience with building flatpaks, but here it goes :). It seems as when packing the flatpak, you are attempting to build all of the dependencies and the application. Are you not able to simply package the already compiled program from the ubuntu CI? As I understand it, that is how the AppImage is created, but I also understand that flatpak uses containerization and could be different.
@Ocraftyone the reason for this is debugging symbols and the flatpak's runtime bundled deps. I might be able to just build an appimage in distribute that, but it would be a waste of space. Currently, the amount of debugging symbols, even compressed, is the issue in CI because I am running out of space.
@powpingdone is there a reason for the debug symbols? I do remember always running out of space if I tried to do them on actions and I don't think there is a way around it.
@Ocraftyone Distributing a flatpak (or appimage) with debugging symbols would allow for, well, better debugging. Like for, say, a deep segfault, a backtrace and execution context would be immensely helpful for pinpointing how a bug could happen. flatpak-builder automatically strips and distributes symbols as a separate "package" that can be installed later for helping debugging issues.
@SoftFever Could you weigh in on debugging symbols here? It's currently the only blocker for this pr to be reviewed.
@Ocraftyone Distributing a flatpak (or appimage) with debugging symbols would allow for, well, better debugging. Like for, say, a deep segfault, a backtrace and execution context would be immensely helpful for pinpointing how a bug could happen.
flatpak-builderautomatically strips and distributes symbols as a separate "package" that can be installed later for helping debugging issues.
Woah! That's some cool functionality! I know all of our other builds opt out of shipping with debug symbols. We have the logging system which can help us reproduce bugs on a developer machine.
About how much space do you need to have the build successfully work? How much space should be available, so that we don't run into the issue of no available space in the near future?
It will be better to pack these debug symbols in a separate package. Like we did for the windows PDB files
@SoftFever that would automatically be the case here, as that's part of distributing the flatpak. The problem is that the CI is running out of space during building.
@cochcoder unknown. I haven't actually fully measured it but if it's breaking past github's limit of 15gb then there's your (not accurate) minimum
@cochcoder unknown. I haven't actually fully measured it but if it's breaking past github's limit of 15gb then there's your (not accurate) minimum
I've never seen a Flatpak for applications like this get so large! Considering that all the current builds take up ~500 MB. Is this to do with poor optimization or am I missing something?
@Ocraftyone no
$ du -hd 1 .
1007M ./.git
8.0K ./.devcontainer
68K ./.github
28K ./.idea
3.8M ./SoftFever_doc
192K ./cmake
1.1G ./deps
7.4M ./doc
176K ./lib
8.1M ./localization
140M ./resources
164K ./sandboxes
4.0K ./scripts
49M ./src
240K ./t
3.3M ./tests
16K ./tools
480K ./xs
1.4G ./flatpak
20K ./.flatpak-builder
12G ./build
16G .
I mean, that build dir is 12G.
Oh, you're talking about flatpak size. Well, no, it's a normal size.
$ flatpak info io.github.softfever.OrcaSlicer
OrcaSlicer - Get even more perfect prints!
ID: io.github.softfever.OrcaSlicer
Ref: app/io.github.softfever.OrcaSlicer/x86_64/master
Arch: x86_64
Branch: master
Version: 2.0.0-951fc8e
License: AGPL-3.0-only
Origin: orcaslicer-origin
Collection:
Installation: user
Installed: 470.5 MB
Runtime: org.gnome.Platform/x86_64/45
Sdk: org.gnome.Sdk/x86_64/45
Commit: 2d373df0923172e6cba45ffc23c29bb8dbdd6471a8acb90dc4c772d97ac4f282
Parent: 0af880ef40c80f4f840f24251b5af468d297ed2591b7bbd7c4f220ea958a25fc
Subject: Export io.github.softfever.OrcaSlicer
Date: 2024-03-15 03:31:05 +0000
Would it be possible to exclude debug features on parts of orca you know currently work well/have less issues. Just to get the flatpak up then add them in as time goes on? That way people have a flatpak and you can slowly work more debug features in later on with more help from other developers?
@SoftFever debug symbols or no?
I prefer we don't include debug symbols in the flatpak file as 99.9999% percent people don't need this ;)
In the future, I would like to distribute debug symbols as (again) they're part of a separate package that is part of the build process but is not installed normally, just avail on the remote repository. Due to CI constraints though, that's just not happening...
Hi there thanks for working on getting this flatpaked, any update on how its going?
So have you finished cleanup and review? I'm personally "very" excited for this feature.
Someone correct me if I am wrong, but I don't think flatpak applies to macos or windows.
Someone correct me if I am wrong, but I don't think flatpak applies to macos or windows.
As far as I know, FlatPak is only for Linux.
Someone correct me if I am wrong, but I don't think flatpak applies to macos or windows.
As far as I know, FlatPak is only for Linux.
I was curious to this because the failing checks in the pipeline below are related to macos and I was wondering why they are there at all.
I was curious to this because the failing checks in the pipeline below are related to macos and I was wondering why they are there at all.
I'd think those should be removed, if this is a FlatPak only pipeline.
@SoftFever could you please approve the workflow so I can continue testing?
@SoftFever could you please approve the workflow so I can continue testing?
It should build automatically now. I temporarily disabled CI/CD this morning as I was fixing a build error. Let me know if it still has issues.