AppImages of v0.18 release builds

[kkremitzki]

The problem with an evergreen 0.18 tag is that it becomes very difficult or impossible to troubleshoot issues by comparing different releases.

[mfv]

The problem with an evergreen 0.18 tag is that it becomes very difficult or impossible to troubleshoot issues by comparing different releases.

+1

[triplus]

The issue is some build systems don't use git and they download the source from the release page.

OK, therefor some would like to have point releases provided as a separate releases/tags. For i guess the purpose of easier obtaining the source code and changelogs. This is therefore sensible thing to provide. What is in my opinion not a sensible thing to do is to have binaries provided for all point releases. It's confusing and a huge maintenance burden.

I need to do some experiments on my github page.

Maybe if an orphan branch would be created and a single commit would be added. Some text describing that this isn't FreeCAD source code. That could i guess get tagged as "continuous" and maybe one more for "release". Here is where we would maintain development and latest (point) release binaries. Before each new release, we would archive the latest (point) release binaries, and the description text, from "release" to an appropriate release. From time to time i guess we would need to delete and recreate them, to bump them back to the top. That is, if such approach will end up working in the first place.

I still copy some stuff manually, but it could be scripted. We could also use the new libpack. @saso has done some experiments with this on AppVeyor. I think we can make it work, first step is to build Win on Travis. After that we can work on deploying it.

For now i was thinking more in the direction of leveraging Conda based Windows builds. In addition to Linux and macOS ones. As for building directly on Travis. It's possible, but i don't know when that will happen.

Thanks for the continued interest. We've come far in the last few years.

Today i went ahead and pushed some changes to AppImage repo. One remaining thing that i couldn't sort out just yet is to achieve successful deployment of Linux and macOS builds. Some sort of malformed url issue is at play, will try to figure out that part tomorrow.

The problem with an evergreen 0.18 tag is that it becomes very difficult or impossible to troubleshoot issues by comparing different releases.

That part therefore got sorted out. But the result is not suitable for dealing with binaries. For that hopefully a more optimal solution will be the outcome of such discussions.

P.S. In addition with having "continuous" and "release" sections. People likely wouldn't be confused anymore, believing binaries are out of date, as a number seems to indicate that.

[sgrogan]

That part therefore got sorted out. But the result is not suitable for dealing with binaries. For that hopefully a more optimal solution will be the outcome of such discussions.

@probono's script offered the hint. Deploy "releases" to

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

This will always point to the latest release. Only caveat is that the release must exist. So when we create a point release (or regular release) tag, also create a release on the release page. 0.19_pre is a pre-release so it's separate.

[NormandC]

I just noticed a FreeCAD_0.18_stable.AppImage under the 0.19_pre release page. Is it a mistake?

[triplus]

@sgrogan

I can do more tests in the future, but likely that is more useful as an API. That is, with some scripting involved, you can extract the actual latest release name, such as the current 0.18.1. After indeed, you could use that information to deploy to 0.18.1. If documentation archive would have a stable name, for name to always be the same, Travis script could create the download link in such way too. Currently it uses "hardcoded path" for documentation made available on 0.18. For AppImage update information, this is likely not as useful, unless update tool can handle "latest" and do the conversion automatically. Will do some tests in the future. For now i disabled update information for stable AppImages.

This is the current situation:

https://github.com/FreeCAD/FreeCAD/rele ... g/0.19_pre

Stable and development Conda based builds for Linux and macOS are currently deployed to 0.19_pre (daily). Stable one have documentation included. I wanted to deploy stable builds to 0.18.1, by setting a variable and committing the change to the AppImage repo. Note that there is an option to do that without involving the commit, but for that one needs to have access to AppImage repo related settings on Travis. In addition that currently doesn't work at all, as the only tag that doesn't produce "url malform" issue is the 0.19_pre one. I feel that this could end up being a limitation of current scripts we use for handling the deployment.

@looo

It would be great if you could create FreeCAD 0.18.1 build with correct version information. Currently it isn't set correctly and the version script creates some garbled name. As a temporary workaround i have set the name manually. Testing AppImages i noticed 2 additional issues. QT Assistant path (try accessing help by pressing F1 key) is currently not set correctly and likely you removed too much libraries, as my system provided version of libstdc++.so.6 isn't compatible with bundled tibtbb.so.2 (0.18_pre AppImages didn't have such issue).

As for macOS builds. Some people using macOS should start testing and report back. As for Windows builds. If there is a Windows script, on how to convert Conda Windows build in a portable binary or installer. We can try to make that happen too (on Travis).

P.S. Once most of the issues reported get sorted out, we can start using latest binaries as the release binaries. Next week, as a secondary objective, i will invest some free time in making PPA based AppImages to work again. If doable, likely Py2/Qt4 one, based on Ubuntu Xenial, should be included on FreeCAD 0.18 release section.

@NormandC

Currently deploying to other tags doesn't work. Therefore stable releases will be deployed to 0.19_pre for now (daily). After confirmation they in general work, moving them to 0.18.1 manually by @sgrogan should happen. Stable releases deployment to 0.19_pre can be turned off after. I can investigate situation regarding current deployment scripts further in the future. But i don't consider that as being a primary objective for now.

[NormandC]

https://forum.freecadweb.org/viewtopic.php?f=4&t=35647

[NormandC]

Stable one have documentation included.

When hitting F1, I get a pop up telling me it can't load Qt Assistant:

Impossible to load Qt assistant (/home/travis/build/FreeCAD/FreeCAD-AppImage/conda/linux_stable/AppDir/usr/bin/assistant)

[triplus]

Today i corrected the path for macOS stable builds, and documentation should be added now to the bundle.

@sgrogan

I checked and AppImage update procedure can utilize GitHub API (latest)! Once Conda FreeCAD 0.18 builds will start producing correct version information i will add the update information again.

Currently we use a filter "glibc2.12-x86_64.AppImage.zsync". This could i guess be made more future proof, as sooner or latter glibc version will get bumped, by using ".AppImage.zsync". The problem is such solution wouldn't support two AppImages with update information on a single releases page. As likely clash would occur. Therefore something like "recommended.AppImage.zsync" would need to be used instead. The same could apply if we would ever have "continuous". This isn't something we need to think about or resolve for now.

@looo

Indeed we should try to fix the theming issue. If i remember correctly fallback theme (GTK 2) is being used to fix global menu related issues, and this should get resolved once Conda gets newer Qt? As Conda is slow at such things, we should investigate different possible solutions, and get both global menu and theming issue sorted out.

[looo]

thanks @ triplus for repairing the automatic upload of appimages! This definitely deserve some beer.

It would be great if you could create FreeCAD 0.18.1 build with correct version information. Currently it isn't set correctly and the version script creates some garbled name. As a temporary workaround i have set the name manually. Testing AppImages i noticed 2 additional issues. QT Assistant path (try accessing help by pressing F1 key) is currently not set correctly and likely you removed too much libraries, as my system provided version of libstdc++.so.6 isn't compatible with bundled tibtbb.so.2 (0.18_pre AppImages didn't have such issue).

I will eventuelly switch to use git directly for getting the sources. It's not recommended by conda-forge, thats why I never used it (I guess because checksums should be used). The other way is to provide releases also on the freecad channel, which I already did for 0.18.1 and old toolchain.

As for macOS builds. Some people using macOS should start testing and report back. As for Windows builds. If there is a Windows script, on how to convert Conda Windows build in a portable binary or installer. We can try to make that happen too (on Travis).

Yes it's maybe nice to have this for windows too, but first we have to solve the issues for linux and macos. All currently reported issues on linux seem to be related to hard-coded paths. These problems do not occur for freecad installed directly with conda-package-manager. If necessary we can switch the release back to the old toolchain which didn't had much issues with hard-coded paths.
So maybe it's possible to make release builds use conda-forge/label/cf201901 and freecad/label/dev_cf201901?

Anyway it would be nice to have a tool which replaces all the hard-coded paths with relative paths (if this is possible). We would need such a tool for osx too.

ps.: I can try fixing the theming issue and switch stable releases back to old-toolchain if you are ok with these changes.
theming should be fixed with adding:

Code: Select all

export QT_STYLE_OVERRIDE=gtk2

edit: wrong command