GSoC '18: CM Project Thread

[NormandC]

Yeah, I don't know if this can be avoided. If there's a way, Kurt is obviously the one who has the most chances of finding it.

[yorik]

splitting into freecad-python2 and freecad-python3 seems a good idea, I have the impression that the deb world will still balance between the two for some time.

For the split between a "base" FreeCAD package and a "workbenches" one I have my doubts... Part and Mesh are I think mandatory in the base package. Only FEM really needs additional libs. Most the others could go into Workbenches, but is that really interesting? They add basically no dependency, and are small in size..

The addons system should indeed handle dependencies (it does already). Since it is all python, it's not that difficult.

[jmaustpc]

Also don't some workbenches require being selected at compile time? Or am I misunderstanding?

I would rather see an agreed set of default wbs and then use a cross platform addon system, as we do now.

[looo]

I would rather see an agreed set of default wbs and then use a cross platform addon system, as we do now.

I think we are talking about two things:
1. splitting the sources and externalize some workbenches
2. splitting the debian package

1.
I also think some wbs could be changed to be external. But I don't think you will find many which are pure python. I guess the ship and plot-wb are examples. But I think most of the others include c++-code.

2.
What is the main benefit of split debian packages?
I guess here we are talking about simple splitting the compiled files into different sub-packages. (eg freecad-robot) So this doesn't simplify the build and the question is if the benefit of split packages outweigh the additional maintaining work...

[kkremitzki]

I would rather see an agreed set of default wbs and then use a cross platform addon system, as we do now.

I think we are talking about two things:
1. splitting the sources and externalize some workbenches
2. splitting the debian package

1.
I also think some wbs could be changed to be external. But I don't think you will find many which are pure python. I guess the ship and plot-wb are examples. But I think most of the others include c++-code.

2.
What is the main benefit of split debian packages?
I guess here we are talking about simple splitting the compiled files into different sub-packages. (eg freecad-robot) So this doesn't simplify the build and the question is if the benefit of split packages outweigh the additional maintaining work...

Indeed there are two topics at hand, but I was mainly planning on (2) because (1) is just way too big. We can address it in a small way using the alternatives system. This would mean that FreeCAD would first be built with some minimal flags set, and those files set aside for the freecad-minimal package, and then again for Python 2 and 3.

The rationale for (2) is that it is 'nice' for the build infrastructure and for users. The FC package is about 135M but only about 65M of that is shared libraries. However since the package is multi-arch, the entire thing is copied for i386, x86_64, armel, armhf, arm64, etc., etc., on both the Debian infrastructure and Launchpad. So that 70M difference multiplies quite quickly. This will get worse if we have a freecad-python2, freecad-python3, and freecad-minimal for each arch. In fact, many of the 2-and-3 builds I have seen actually build against both 2 & 3 as well as python2-dbg and python3-dbg, which might be a nice option for developers.

For users, it means that they only have to download the part of the package that actually received a change. I am sure there are some with limited bandwidth for whom this would be appreciated, even if the difference is only a few dozen MB here and there.

The additional maintenance effort would be minimal, as this would just be a few more package definitions in debian/control, and a few lists of which files go where in debian/<packagename>.install. The real difficulty is in getting the simultaneous builds working correctly, since they are mostly just "magic" and should work by calling the build "--with python2,python3", but when they don't, it can be a real maze.

[Kunda1]

Regarding Option (1) here are some related discussions
https://forum.freecadweb.org/viewtopic.php?f=10&t=22691
issue #857, issue #2993, issue #3032

[Kunda1]

ping

Hey @mhochsteger as you are one of the maintainers of Netgen, I'm just giving you a heads up about this thread. One of the packages on @kkremitzki's agenda (AFAIK still a WIP) is packaging Netgen on Debian.
In a previous post on here you wrote:

We would like to get Netgen/NGSolve in to Debian but we are lacking the expertise of doing so, so any help is appreciated. Maybe packaging nglib only is a good starting point. I will have a look at the build scripts to check if that's easily possible.

Would you still be open to collaborating ?

[kkremitzki]

Hi, sorry for missing my update last week, my schedule was thrown off a bit by the holiday. Anyway, I just wanted to post a quick update about the 2nd coding period.

I finished the splitting of the FreeCAD package. See https://salsa.debian.org/kkremitzki-guest/freecad. This has resulted in quite a few lintian warnings no longer being present, so the quality of the package has gone up. Altogether, there is now the freecad metapackage, freecad-common (e.g. images, templates, materials files, etc.), freecad-runtime (the runtime .py and .ui files), freecad-python2 (the freecad binary compiled with python 2 option) and libfreecad-python2-0.17, the shared libraries compiled against python 2 (with the last 2 packages to be joined soon by python3 versions.) Quite a few files which were misplaced in /usr/lib/freecad are now stored in /usr/share/freecad and symlinked as necessary. This didn't cause any problems in my testing.

I also have prepared the standalone freecad-doc package at https://salsa.debian.org/science-team/freecad-doc. This will be nice once it gets to the PPA since it will mean freecad-doc doesn't get re-built and redownloaded each time the freecad-daily PPA updates. Unfortunately I had a hell of a time trying to get the PDF included. For some reason the Debian build process doesn't want to pick up freecad.pdf, even though I have a "freecad.*" which is grabbing freecad.qch and freecad.qhc. I'll need to consult someone on that because I'm stumped.

Speaking of PPAs, you also might notice that I updated OCCT on the PPA to 7.3 and updated the stable and daily builds alike.

Also, Netgen 6.2.1804 is officially uploaded to the repositories now! However there were several build failures on various platforms so I need to do some tweaking still before the package is totally finalized. Regardless, I should have it included in the daily builds PPA tomorrow, with a Netgen-enabled FreeCAD build right behind it.

Finally, I've begun the process for applying to become an official Debian Maintainer for FreeCAD and other packages. That means I'll be able to upload fixes to the Debian archives myself for the packages I'm designated as a maintainer for. That'll be nice!

One of the first steps in the process is to get a GPG key signed (see https://wiki.debian.org/Keysigning). So, I got in touch with a Debian Developer who works at cPanel in Houston, and I decided to drive down the morning of July 4th to try to avoid traffic. The keysigning went well and we had a nice chat about Debian things. Unfortunately the weather was incredibly far from cooperative!



(Yes, it really did look like that. For quite a while I was driving 30 MPH in a 75 MPH zone because visibility from the rain was that bad.)

[yorik]

Excellent news!! Congrats for your new position!

[Kunda1]

Driving 6-7 hours roudtrip for gpg keys is pretty damn valiant. Thank you for doing that @kkremitzki