0.18.4 crash with gdb trace

[Hermit]

I'm familiar with COPR but I'm not a huge fan of it. It's suited for package distribution for private intranets, but not for developing a single desktop application. It seems like the wrong approach to me.

I think what we really want/need is just the version-set for each tagged release. This would facilitate bug reporting too.

There's a Debian Docker-based development container floating around which is a better approach at isolating dependencies. I'm going to look at using one for Fedora to get a pristine version-set and build procedure for that distro.

[vocx]

... I'm going to look at using one for Fedora to get a pristine version-set and build procedure for that distro.

But do look for Hobbes and Przemo, because I feel that the Fedora community is relatively fragmented. It's better if Fedora users all come together to organize this.

FreeCAD (0.19, 0.18) crashes under Linux Fedora 31 (FreeCAD killed by SIGABRT)

[Hermit]

I've seen their posts in the Fedora / Bugzilla forums. I think they are focused on getting a working end-user package or rpm for Fedora. COPR is a fine tool for organizing this purpose.

I'm more interested in extending / building / debugging with FreeCAD and so I'll be focused on refining the build instructions on the Wiki for Fedora.

I have another related question: are the Windows users still using LibPack to perform builds and releases, and do you think it would be reasonable to use a LibPack-like folder structure to simplify development builds on other Linux platforms like Fedora?

[vocx]

...
I have another related question: are the Windows users still using LibPack to perform builds and releases, and do you think it would be reasonable to use a LibPack-like folder structure to simplify development builds on other Linux platforms like Fedora?

Yes, the LibPack is still available. In the GitHub release page, there are two versions of FreeCAD for Windows, one based on the LibPack and the other based on Conda.

I'm not sure what you mean for LibPack structure for Linux, but I think it's not needed, because in Linux getting the dependencies is generally easier. Moreover, there is Conda. Maybe this is what you want; with Conda you are able to select all dependencies in a way that they are compatible with each other; the MacOS and Windows distributions, and Linux AppImage are all generated from Conda in this way.

There is also the Ubuntu Snap, and the Flatpack. We need more information on the Flatpack because I'm not sure the Flatpack packager is in this forum, maybe that's also interesting for you.

[Hermit]

I'm not sure what you mean for LibPack structure for Linux, but I think it's not needed, because in Linux getting the dependencies is generally easier. Moreover, there is Conda. Maybe this is what you want; with Conda you are able to select all dependencies in a way that they are compatible with each other; the MacOS and Windows distributions, and Linux AppImage are all generated from Conda in this way.

Well, it's only easier if the dependencies "line up" in a target distro with the ones in the default Debian distro. There are often subtle differences in naming and folder structure between Debian and Fedora that can break a build. It can sometimes be fixed using CMake variables, but I don't always know if the result is correct, even if the build is successful. That's why I wanted to compare with a LibPack-based binary.

[sgrogan]

Well, it's only easier if the dependencies "line up" in a target distro with the ones in the default Debian distro

The issue is FreeCAD aims to support the oldest Debian/Ubuntu non-EOL (16.04 now) to the newest.
Of course then things "lining up" is hard. I would look at the conda build packaging https://travis-ci.org/github/FreeCAD/Fr ... /721495572
The conda packages move fast, but any cross-dependencies are usually solved quickly.