Ticket #4014 - Finding a solution for the 'version.h' issue

This subforum is specifically to discuss packaging issues on different platforms (windows, mac, linux), and using different packaging systems (conda, etc...)
User avatar
looo
Posts: 3096
Joined: Mon Nov 11, 2013 5:29 pm

Re: Ticket #4014 - Finding a solution for the 'version.h' issue

Postby looo » Tue Oct 08, 2019 11:04 am

For Debian, we're not allowed to call out to the internet
I guess it should be possible to add the git commit info to the debianized source. So this is not really an issue.
please help with my conda-packaging efforts: https://liberapay.com/looooo/
minimalistic blog: https://looooo.github.io/mini-blog/
User avatar
kkremitzki
Posts: 1860
Joined: Thu Mar 03, 2016 9:52 pm
Location: Texas

Re: Ticket #4014 - Finding a solution for the 'version.h' issue

Postby kkremitzki » Tue Oct 08, 2019 3:32 pm

For Debian packaging, it would be sufficient to be able to just force a version via CMake flags so I could manually set e.g. 0.18.4 and so forth. A solution for the daily builds is a bit trickier.
Like my FreeCAD work? I'd appreciate any level of support via Patreon, Liberapay, or PayPal! Read more about what I do at my blog.
User avatar
bgoodr
Posts: 223
Joined: Sat Jun 14, 2014 9:40 pm

Re: Ticket #4014 - Finding a solution for the 'version.h' issue

Postby bgoodr » Sun Oct 27, 2019 4:15 pm

kkremitzki wrote:
Tue Oct 08, 2019 3:32 pm
For Debian packaging, ... A solution for the daily builds is a bit trickier.
Indeed. Given that difficulty, I speculate that you might discover that it is actually impossible to do for daily builds. If that is what is discovered, IMO, someone should temper the instructions in the IMPORTANT: Please read first before asking for help post that currently states:
NormandC wrote: Please do not attach a screen capture instead of posting the Help > About FreeCAD information from the clipboard.
to, in addition to the above, also indicate that for daily builds, describe all of the platform-specific commands needed to provide the relevant version info (e.g., example for Ubuntu/Debian-based distributions is at https://forum.freecadweb.org/viewtopic. ... 12#p343312).

I hope it doesn't come to that; I hope it is found that my speculation above is erroneous, and including some release/date time stamp into the About FreeCAD dialog box is viable even if the git commit hash value of the build is not possible to include.
openBrain
Posts: 3022
Joined: Fri Nov 09, 2018 5:38 pm

Re: Finding a solution for the 'version.h' issue

Postby openBrain » Wed Jan 01, 2020 5:21 pm

kkremitzki wrote:
Sun Jun 23, 2019 7:35 pm
Here's the recipe:

Code: Select all

# git-build-recipe format 0.4 deb-version {debupstream}~{time}
lp:~freecad-maintainers/freecad/+git/freecad master
nest-part debian lp:freecad debian debian ppa/daily
Hi all, tried to push a bit on this topic. Maybe found something interesting (I hope).
I can get SHA of current LaunchPad clone of FC GH repo with the following command :

Code: Select all

git ls-remote https://git.launchpad.net/~freecad-maintainers/freecad/+git/freecad/ | head -n1 | cut -f1
And thus, extending this trick, I can recover commit number with :

Code: Select all

curl -I -k "https://api.github.com/repos/FreeCAD/FreeCAD/commits?per_page=1&sha=`git ls-remote https://git.launchpad.net/~freecad-maintainers/freecad/+git/freecad/ | head -n1 | cut -f1`" | sed -n '/^Link:/ s/.*"next".*page=\([0-9]*\).*"last".*/\1/p'
Is that kind of bash commands that could be run in the LP recipe, and eventually be used to populate the version.h file ?
openBrain
Posts: 3022
Joined: Fri Nov 09, 2018 5:38 pm

Re: Ticket #4014 - Finding a solution for the 'version.h' issue

Postby openBrain » Fri Jan 03, 2020 10:36 am

Some feedback ? At least I know I'm not digging an empty spot. :)
hobbes1069
Posts: 226
Joined: Wed Nov 09, 2011 3:49 pm

Re: Ticket #4014 - Finding a solution for the 'version.h' issue

Postby hobbes1069 » Fri Jan 03, 2020 2:42 pm

My only feedback might not be helpful :)

As the Fedora package maintainer I would like a more generic fix that's not Debian specific.

I haven't dug into this but there's got to be a way to handle this in CMake during configuration.

Thanks,
Richard
openBrain
Posts: 3022
Joined: Fri Nov 09, 2018 5:38 pm

Re: Ticket #4014 - Finding a solution for the 'version.h' issue

Postby openBrain » Fri Jan 03, 2020 2:46 pm

hobbes1069 wrote:
Fri Jan 03, 2020 2:42 pm
My only feedback might not be helpful :)

As the Fedora package maintainer I would like a more generic fix that's not Debian specific.

I haven't dug into this but there's got to be a way to handle this in CMake during configuration.
Hi Richard, thanks. This is handled in CMake already. The problem with Debian is that build process doesn't get any Internet access so we need to find an alternative solution. Is that the case also for Fedora build process ?
hobbes1069
Posts: 226
Joined: Wed Nov 09, 2011 3:49 pm

Re: Ticket #4014 - Finding a solution for the 'version.h' issue

Postby hobbes1069 » Fri Jan 03, 2020 2:58 pm

openBrain wrote:
Fri Jan 03, 2020 2:46 pm
hobbes1069 wrote:
Fri Jan 03, 2020 2:42 pm
My only feedback might not be helpful :)

As the Fedora package maintainer I would like a more generic fix that's not Debian specific.

I haven't dug into this but there's got to be a way to handle this in CMake during configuration.
Hi Richard, thanks. This is handled in CMake already. The problem with Debian is that build process doesn't get any Internet access so we need to find an alternative solution. Is that the case also for Fedora build process ?
Yes, internet access is not permitted on the build server.

I have a patch to work around the issue since 0.14 so I haven't looked into it in a very long time but maybe I need to get around to it. I'm still in Coin3/Coin4 hell on Fedora right now so that's been my main priority.

For tagged releases, shouldn't Version.h be generated within the tarball?

Thanks,
Richard
User avatar
sgrogan
Posts: 5574
Joined: Wed Oct 22, 2014 5:02 pm

Re: Ticket #4014 - Finding a solution for the 'version.h' issue

Postby sgrogan » Fri Jan 03, 2020 11:29 pm

openBrain wrote:
Fri Jan 03, 2020 10:36 am
Some feedback ? At least I know I'm not digging an empty spot.
I don't think we can run bash commands from the recipe.
We have theses options available https://help.launchpad.net/Packaging/So ... ds/Recipes, on Launchpad at least.
On LP at least we could code some of the info into the packagename, which would be there in the tarball name. It's Important to make sure the builds are increasing, i.e. if using the git hash make sure it's after something that is increasing

If we did this maybe we could add a CMake switch BUIlD_FROM_TARBALL and modify the CMake macro WCREV.py to parse the tarball name to get the info?
On GitHub the release name is the name of the release tarball, so it would need to be done manually(as I do now), or we could potentially script Travis_CI to create the release.

The problem that persists is that the auto-magically created tarballs from either LP or GH strip the git history, including the tags.

And thanks openBrain for the continued interest. This is a tough nut to crack. :)