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
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

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

Post by looo »

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.
User avatar
kkremitzki
Veteran
Posts: 2515
Joined: Thu Mar 03, 2016 9:52 pm
Location: Illinois

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

Post by kkremitzki »

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: 228
Joined: Sat Jun 14, 2014 9:40 pm

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

Post by bgoodr »

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
Veteran
Posts: 9041
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

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

Post by openBrain »

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
Veteran
Posts: 9041
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

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

Post by openBrain »

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

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

Post by hobbes1069 »

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
Veteran
Posts: 9041
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

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

Post by openBrain »

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 ?
User avatar
hobbes1069
Posts: 291
Joined: Wed Nov 09, 2011 3:49 pm
Location: Southaven, MS

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

Post by hobbes1069 »

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
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

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

Post by sgrogan »

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. :)
"fight the good fight"
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

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

Post by Kunda1 »

Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Post Reply