Volunteer Packagers Needed for the PPA

https://launchpad.net/~kunda1

@yorik am I really wrong that build is done from Salsa Debian Freecad daily? So It’s mainly fix build from there as I didn’t notice that there is no building stuff in automatically imported git on launchpad

Done!

This is the code used for the ppa AFAICS: https://code.launchpad.net/~freecad-maintainers/freecad/+git/freecad it seems in sync with the FreeCAD master code…

yorik may I ask you if it is in relation with this thread and fix the annoyance?

Is this PPA available just to build upstream git as there is this Freecad PPA based on freecad - [no description] (It only builds releases). As that is used for debian directory. Just asking as there should not be double effort on this and determine relationship..

I don’t really know if there is any relationship at all between the launchpad git and the debian salsa git. I believe not, each of them syncs with our FreeCAD master code independently. Only, debian makes builds at specific times, while normally the PPA should build daily, or so.

This looks like it would be the relevant files for packaging: https://git.launchpad.net/freecad/tree/?h=ppa/daily

This is the LP repo with the debian rules and control files:
freecad - [no description] is an import of the Git repository at Debian Science Maintainers / freecad · GitLab.

This is the LP repo with the current FC source:
~freecad-maintainers/freecad/+git/freecad - [no description] is an import of the Git repository at GitHub - FreeCAD/FreeCAD: Official source code of FreeCAD, a free and opensource multiplatform 3D parametric modeler..

The debian dir from the first gets inserted into the second for the daily build.

and where is this kind of stuff setup? Is there a script that gets executed on a schedule in launchpad? the whole process is very obscure to outsiders.

Speaking of which, I have an idea to make the daily ppa have correct full version information, in the FreeCAD-Bundle repo a source tarball with correct full version info is created every 4 hours (the conda builds use these), this is done here with a script that writes the version info and then makes a commit with it before doing

git archive HEAD -o ../freecad_source.tar.gz

we could auto push that commit with the version info to launchpad or push to a branch on github and have launchpad mirror it.

I don’t know how the scheduling part works.

The source gets built by running git-build-recipe against a Launchpad “recipe”. This builds a source tree that combines the debian stuff with the FC source, then makes a source tar ball and dsc file. After that it runs debuild against the tar ball to produce the package files.

The source tree produces a good FC executable using the usual CMake + make process. The problem is somewhere in the rules and control files that control debuild, but that’s as far as I got.

My notes to myself are attached.
packagingNotes.txt (1.89 KB)

Wow, that’s nice wizardry :slight_smile: Indeed it really makes these LP builds something pretty polished then and probably better integrated than snaps. Makes sense to keep it running indeed…

I don’t know about that, the snap process I found easier to understand than this and more transparent since it can all be seen on the github repo and it’s easy to propose changes, here I still don’t know what the exact build steps are or where I can find them, how is it configured or how to propose changes.

The mere fact that the package has been broken for months but still nobody seems to understand how the process actually works or how it may be fixed suggest it’s not that polished or very well integrated.

you have a point there :slight_smile:

Launchpad ain’t simpliest tool. But I’ll take serious a look at it next week when I have time (now just tried to recover my knownledge from the past about how receipe works) to make it work again. PPA and SNAP does not compete and they have different use cases and users. I admit I’m old school user and find deb install better suited for my workflow and again I’m not against SNAP packages as they seems to be the future what people want.

Question about is it polished and integrated I don’t understand as it’s kind of native way to install things to Ubuntu. There is good Debian support so I don’t see why it should be dropped. If Launchpad is too hard to use I suggest we could try to OBS (openSUSE Build Service) as it can build all needed distros in one place including Ubuntu and Debian (Fedora, Redhat and Arch) but again receipes are not Voodoo they are fairly simple when you get down how tool works.

When I looked at the Debian folder it seemed like an unnecessarily complicated system but that’s beside the point and out of our control. I too prefer native packages over snap and I expect a lot of people think the same, as long as somebody trustworthy is willing to maintain it it should be kept.

We where talking about the build process, not the integration with the distro.

If Launchpad is too hard to use I suggest we could try to OBS (openSUSE Build Service).

IMO this should be up to the maintainer’s preference.

It took a while to get around Launchpad and remember what I have forget but I got first build on going got 22.10 (which not release yet) with correct versioning. I made small test are in my personal project:
https://code.launchpad.net/~pasanen-tuukka/+recipe/freecad-test-daily
I’ll try to write more detailed stuff that next one who is coming after me is not as bad position as we are.

adrianinsaval I noticed there is already Snap build available in options and it’s making daily Snap. I take look at that after I get DEB building working.

Which Ubuntu version should be supported yorik, wandererfan and kunda1

I think the latest one should be supported but that IMHO

previously there was support for the current non LTS and for all LTS that where not EOL IIRC, but IMO it is up to the maintainer how much work he’s willing to put to support older releases.
Thanks for working on this, where can we see what the build process is?
About the snap, We already a snap daily build working, I believe independently of the ubuntu packages, and this might be preferable since sometimes they are broken.

I run Mint 19 & 20, so from a selfish perspective, I’d like to see support for Ubuntu 18.04 and 20.04.

I upgraded correct package and have to learn how-to run FreeCAD test package on every build. I think then we do 18.04,20.04,22.04 and 22.10 to ensure nothing breaks. So Ubuntu LTS and latest?

I have to see how to get OCCT and Netgen also updated. As I get this on shape (I test this some time that I really understand all these recipes) in some point it would be integrated into ~freecad-maintainers?