appimage

[triplus]

I agree, remove calculix from the AppImage, to avoid confusion, the license is irrelevant.

Yes likely we should do that at some point. If @probono will read this he can change the .yml file or we can make a pull request with the change at some point in the future. But i guess lets wait for some actual user feedback first.

I'm having trouble articulating my opinion. An aggregation is OK as @probono has pointed out.

In the past OCC used GPL incompatible licence. No amount of packaging would resolve that. Luckily OCC licence changed and is now compatible with GPL. Therefore you can mix FreeCAD, OCC and GPL software in a single package.

If you would do that and would want in addition to add some code with GPL incompatible licence in the package then you would likely start caring about aggregation. For example you could add OsiFont licensed under GPL in a bundle with FreeCAD and after add some code in that bundle that is incompatible with GPL licence but doesn't prevent bundling in such way. And that would work as long as you would make it clear OsiFont is basically a standalone solution/package/library at the install time.

[probono]

Uploaded new AppImages without calculix-ccx.

[triplus]

Uploaded new AppImages without calculix-ccx.

Thanks @probono.

@sgrogan

I guess this is it. When you will have some time likely it makes sense to create and upload new FreeCAD 0.16 AppImage to our releases page. After that FreeCAD 0.16 AppImage will i guess only change if some issue will be reported and we will be able to fix it.

[probono]

And please don't forget the download page http://www.freecadweb.org/wiki/?title=Download

[sgrogan]

And please don't forget the download page http://www.freecadweb.org/wiki/?title=Download

Noted. The direct link to the files page.
https://github.com/FreeCAD/FreeCAD/releases/tag/0.16

[NormandC]

As likely packages in Debian will be updated. Getting OCE 0.18 in AppImage for FreeCAD 0.17 should therefore be a priority as it will enable some BOA tools to work (as they currently aren't available with OCE 0.17).

I disagree.

Why go to the hassle of packaging OCE 0.18? It's already obsolete since it's based on OCC 6.9.1 (released in september 2015). While OCCT is now at 7.1.0 (released in november 2016).

Plus 0.17 will absolutely need OCCT 7 in the long run (due to the FEM workbench).

I started a topic last fall about switching to OCCT 7 but work on its packaging kind of died down.

[triplus]

When FreeCAD 0.17 will be released providing AppImage for the release will likely make sense. Using OCE 0.18 should enable the AppImage to have access to a range of BOA tools not available with OCE 0.17. If the Debian package for OCE will be updated before FreeCAD 0.17 is released then likely we can reuse their work for the PPA purposes in the way as that was done in the past.

P.S. If the OCC PPA effort can be achieved before FreeCAD 0.17 is released. Sure why not.

[blacey]

Question: With the vibrant OCCT progress and the OCE lower lack of progress (i.e. doesn't yet support OCCT7), why aren't we using OCCT7 on Linux? We have been using OCCT7 for the 0.17 macOS builds for quite some time. The OCCT team invested in making it easier

[triplus]

There is a long and the short version. As for the short version.

Somebody needs to package newer OCC/OCE version (preferably on the PPA) and that would more or less be it for now.

[blacey]

Got it! Thanks. As of OCCT7, it is very straight-forward to build out-of-the-box using cmake. Unfortunately, I don't have time to tackle a PPA right now but we should keep it on our radar as a quick Google search shows there is interest in a PPA so maybe one will emerge from the broader community.