Thread tracking different OS/Distro maintainers (creating more uniformity)

[Kunda1]

Sorry for the horrendous subject title. My intention in this thread is to aggregate and track different FreeCAD distro maintainer workflows and specifically making sure that the release info is correct (ex. Help > About FreeCAD)

Manjaro Linux 16.10

• Currently the Manjaro Community version is 0.16-6 (essentially this is an archlinux package that is synced in to Manjaro Community)
  Maintained by (link to package page)
  The Revision # and the Release # are labelled 'Unknown'
  Upstream ticket: https://bugs.archlinux.org/task/52553 https://github.com/manjaro/packages-com ... issues/249

[sgrogan]

My intention in this thread is to aggregate and track different FreeCAD distro maintainer workflows and specifically making sure that the release info is correct (ex. Help > About FreeCAD)

See here also: viewtopic.php?f=4&p=148647 and here: viewtopic.php?f=4&t=17538
The crux of the matter is if not building with git the packager must handle them version.h themselves.
Brainstorming welcome.

[NormandC]

See jobermayr's last reply in the first link:

Maybe a git-hook on github which automatically updates src/Build/Version.h.cmake on each commit would be a better solution ...

Seems interesting.

[sgrogan]

Another possibility is to use the created tarball from the Ubuntu FreeCAD maintainers PPA. I just checked and of course the generated tarball contains the merged version.h file. I don't know how excited packagers would be about using this "derived asset" but it would solve the problem.

See jobermayr's last reply in the first link:

jobermayr wrote:
Maybe a git-hook on github which automatically updates src/Build/Version.h.cmake on each commit would be a better solution ...


Seems interesting.

There is a user working on syncing the forum "Pull Request" topic with github's pull request. I'll find the topic and ask for help.
REF: viewtopic.php?f=10&t=19130 I sent @kkremitzki a PM

[kkremitzki]

Sorry for the horrendous subject title.

Hah, it is a doozy of a title.

I think I can help as I'm familiar with git hooks, but I'm not too familiar with the packaging of FreeCAD. I did just happen to switch from Ubuntu to Arch on my desktop last night so I'll start looking at it now and comment further when I have some questions.

Edit: This reminds me that after I installed freecad-git on Arch, the icon was wrong (i.e. not using my icon theme) and I had to go to /usr/share/applications/freecad.desktop and change icon=/opt/freecad/data/freecad.xpm to icon=freecad. I guess this might be another packaging bug but I can't remember if I had something similar happen on Ubuntu.

[kkremitzki]

Alright, so I'd say my reproduction of the issue is as follows.

As a package maintainer, I might want to build the package with a series of commands along the lines of:

Code: Select all

wget https://github.com/FreeCAD/FreeCAD/archive/0.16.tar.gz
tar xzf 0.16.tar.gz
mkdir build
cd build
cmake ../FreeCAD-0.16
make -j$(nproc)

The problem is that after the cmake line, if I were to cat src/Build/Version.h, I would see this:

Code: Select all

// Version Number
#define FCVersionMajor "0"
#define FCVersionMinor "16"
#define FCVersionName  "Vulcan"
// test: Hash (ca7c5d31a4d61f32a25b71025b14641a6e378328), Date: 2016-04-06 22:39:34 -0300
#define FCRevision      "Unknown"      //Highest committed revision number
#define FCRevisionDate  "Unknown"     //Date of highest committed revision
#define FCRepositoryURL "Unknown"      //Repository URL of the working copy

So, the question is, what triggers the builds of these tarballs?

If they aren't automated, they could be, e.g. by having a git hook or webhook waiting for a git push to a release or latest version tag.

Another question: when I visit https://github.com/FreeCAD/FreeCAD/releases I see the following for 0.16:

Untitled 1.png (236.13 KiB) Viewed 3501 times

I tested both tarballs and they both had the "Unknown" problem but also had different hashes and dates. Shouldn't those be the same version?

[Kunda1]

nice sleuthing

[kkremitzki]

Hah, well, perhaps I should have fully read all the linked threads first, because a lot of what I found was replicated there. But I understand the problem now, time to get to work!

[Kunda1]

Also, i'm not sure, but this may be of importance
git commit 675bcc251060d2c597bcea761be5fb672b4ea2bd / issue #2125

[kkremitzki]

So the option I explored involves hardcoding values into src/Build/Version.h.cmake. That may not end up being the best solution but I think a lot of what I found still applies.

The three values that problematically show "Unknown" normally look something like:

Code: Select all

#define FCRevision      "9571 (Git)"      //Highest committed revision number
#define FCRevisionDate  "2017/01/08 17:48:14"     //Date of highest committed revision
#define FCRepositoryURL "https://github.com/FreeCAD/FreeCAD master"      //Repository URL of the working copy

So, if we want to hardcode them using git hooks, we have a bit of a problem. GitHub doesn't allow post-receive hooks because that would allow arbitrary execution of code on their servers. Normally a post-receive hook is what we'd want, since the alternative is hardcoding values before a tag is pushed. That, however, also has issues because files in .git/hooks are not included in the repository, so they'd have to have a new folder outside of .git and some script would have to unpack them into the hooks dir.

Besides that, things seem promising. Let's assume we are using a post-receive hook, since that's what I tested using this guide.

Let's say I'm a committer and I want to push the newest version of 0.16. I can run the following commands:

Code: Select all

g tag -f 0.16 # force updating
g push origin :refs/tags/0.16 # delete on remote
g push origin 0.16 # push tag pointed at new commit

A post-receive hook will see a commit coming in on branch refs/tags/0.16 and it will have that commit hash. The following one-liners will generate the revision number and date of that committed revision, in the same format as shown above:

Code: Select all

echo $(git show-ref refs/tags/0.16 | cut -d' ' -f 1) "(Git)"
git show --pretty=format:"%cd" --date=format:"%Y/%m/%d %H:%M:%S" $(git show-ref refs/tags/0.16 | cut -d' ' -f 1) | head -n 1

So, it's definitely possible to insert those values into the script with git hooks. The problems are whether that's the right solution, and then choosing between

• using a developer-side pre-push hook that will need to be moved into place somehow, preferably without adding hassle
• using a server-side post-receive hook. this means github will send a webhook with the post-receive payload to, for example, the webhook server I've been working on. the downside is that this will add another commit as the webhook server pushes the hardcoded file commit, and so every tagged release will actually be showing "commit number + 1". so on second thought it looks like we'll have to go with the first option.

Sorry for the rambling post, just wanted to offload what I've found so far.