AppImage - Include auto-updating logic in to appimage directly?

[antonyjr]

Should the 0.19-pre builds update to the 0.20-pre builds?

I assume so. But there is no 0.20_pre tag yet

I guess some disconnection with the updating tool won't be avoidable. For the updating process, it would be best if we remove the version from the naming-scheme and call the bundles FreeCAD_<commit_nr>*.Appimage

@looo you could ask users to execute a command to transition without a full download of FreeCAD. Use this tool -> https://github.com/antony-jr/appimage-u ... fo-writer/

Only python3, curl, wget and bash is needed which exists in pretty much every linux distros.

For example to fix the previous error in the update information one has to execute one liner while in the directory of the FreeCAD AppImage,

Code: Select all

 $ cd /path/to/FreeCAD-AppImage/
 $ bash <(curl -s https://git.io/JqTBd)

or you could just give a new release to 0.19_pre with the update information pointing to 0.20_pre which is simpler.

[Kunda1]

What is this sorcery?!

[looo]

Ok, I have several issues:

1. It was easy to upload builds via github action to the same repo, but we need a token from the FreeCAD-repo if we want to upload the builds to the FreeCAD-repo directly. In my eyes it's best to use the FreeCAD-Appimage repo to store the conda-based bundles. What do you guys think about this change?

2. the appimage-updating tool is not yet fixed. Somehow the env-variable is not available in the script and therefore the link is still wrong. Also, I would like to make the transition phase after a release is done simpler. Therefore I will call the weekly bundles something like "FreeCAD*weekly_builds*"

[sgrogan]

1. It was easy to upload builds via github action to the same repo, but we need a token from the FreeCAD-repo if we want to upload the builds to the FreeCAD-repo directly. In my eyes it's best to use the FreeCAD-Appimage repo to store the conda-based bundles. What do you guys think about this change?

+1
For the official stable releases I will manually copy the bundles to the main FreeCAD releases.
Links in the wiki and homepage should point to

https://github.com/freecad/freecad/releases/latest

2. the appimage-updating tool is not yet fixed. Somehow the env-variable is not available in the script and therefore the link is still wrong. Also, I would like to make the transition phase after a release is done simpler. Therefore I will call the weekly bundles something like "FreeCAD*weekly_builds*"

+1 +1
I will also place the LP based builds here, they can eventually be automated.
Links would point to

https://github.com/FreeCAD/FreeCAD-AppI ... kly-builds

[Kunda1]

1.
2.

I think we should build appimages more frequently.
Also https://forum.freecadweb.org/viewtopic. ... 9&start=30

[looo]

Thanks guys.

+1
For the official stable releases I will manually copy the bundles to the main FreeCAD releases.
Links in the wiki and homepage should point to

Yes I think thats an good idea. Trying to automate the build process as much as possible and moving to the official mirror once the builds are tested. Kind of a two-stage strategy.

I think we should build appimages more frequently.
Also https://forum.freecadweb.org/viewtopic. ... 9&start=30

That is still an issue. The builds are quite time-intensive as no caching at all is used. But as we see other issues when enabling caching, I am not sure if it is a good idea to go this way. In my eyes the one build a week strategy is still a good compromise.

[looo]

Seems like the internal appimage-updater should be fixed with thee builds:
https://github.com/FreeCAD/FreeCAD-AppI ... kly-builds

Now the question is if we should include the updater also with the 0.19 release-appimages? Does this makes sense?

[antonyjr]

Seems like the internal appimage-updater should be fixed with thee builds:
https://github.com/FreeCAD/FreeCAD-AppI ... kly-builds

Now the question is if we should include the updater also with the 0.19 release-appimages? Does this makes sense?

I have no idea. But I've proposed changes to make the internal updater much simple and easy to use. Please see https://github.com/looooo/freecad.appim ... ter/pull/5

Since 0.19 is going to be the next stable release, it would make sense to include the internal updater if you want the feature to update FreeCAD without external tools. Since Stable releases will have a lot of changes, I think it will be much more useful in stable releases than development releases with less changes weekly.

[Kunda1]

[0xff0000]

Out of curiosity, have the path issues touched on in https://github.com/FreeCAD/FreeCAD-Bund ... -322382955 made any headway?

I ask because without handling the mutable portion of the base path created by AppImages, there will be enduring problems with many of the configuration options. For example: I was wondering why (despite knowing I changed the setting) the TechDraw workbench was still using an A4 template instead of a US Letter one. The reason why is that the base path changes every time the AppImage is started, but the "settings" are stored with a fully qualified path (as would be reported by realpath).

screenshot of tech draw settings with mutable appimage path

Screenshot from 2021-07-27 09-09-32.png (128.5 KiB) Viewed 1421 times

Since this is stored in my "settings", I could copy everything into the correct xdg-user-dir (e.g. XDG_TEMPLATES_DIR or something within XDG_CONFIG_HOME) but by doing that I'll then lose the benefit of updates to any of the templates. This hits at the meta-concern, without a stable path within the AppImage to plugins, macros, templates, etc or a way of "synchronizing" assets with the AppImage I get the feeling many issues like this will persist.

And yes: I know "feelings" aren't a product development strategy.