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

[Bluewind]

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

Please NEVER EVER change published tags. Other users that have already cloned the repository will not receive the changed tag. They will continue to keep the old one and everyone involved will be confused. Yes, that includes the developers as well. Also see: https://git-scm.com/docs/git-tag#_on_re_tagging

Also after maintaining the Arch Linux freecad package for two years, I finally learned that freecad apparently does more than one release per year. Please just do what git, and anyone who knows git, expects you to do and tag them properly instead of changing the tarballs on the github page. You could just tag them with something like 0.16.1234. That way I get notified because the github rss feed shows a new release and you don't have to wonder which versions people are using when they say 0.16 because there is only one 0.16 tag and the others differ. Obviously you'll still have to update the version information before tagging the release.

If you want to know how that looks, take a look at the linux kernel:
https://git.kernel.org/cgit/linux/kerne ... /refs/tags
https://github.com/torvalds/linux/releases

I'd also suggest that you look into semver, but that might be a bit too disruptive for now: http://semver.org/

PS: Please set up HTTPS. Getting certs is free now thanks to Let's Encrypt.

[kkremitzki]

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

Please NEVER EVER change published tags. Other users that have already cloned the repository will not receive the changed tag. They will continue to keep the old one and everyone involved will be confused. Yes, that includes the developers as well. Also see: https://git-scm.com/docs/git-tag#_on_re_tagging

Also after maintaining the Arch Linux freecad package for two years, I finally learned that freecad apparently does more than one release per year. Please just do what git, and anyone who knows git, expects you to do and tag them properly instead of changing the tarballs on the github page. You could just tag them with something like 0.16.1234. That way I get notified because the github rss feed shows a new release and you don't have to wonder which versions people are using when they say 0.16 because there is only one 0.16 tag and the others differ. Obviously you'll still have to update the version information before tagging the release.

If you want to know how that looks, take a look at the linux kernel:
https://git.kernel.org/cgit/linux/kerne ... /refs/tags
https://github.com/torvalds/linux/releases

I'd also suggest that you look into semver, but that might be a bit too disruptive for now: http://semver.org/

PS: Please set up HTTPS. Getting certs is free now thanks to Let's Encrypt.

Thanks for letting me know on the tags bit. It'll still be possible to programmatically do things with git hooks, if necessary, when a tag is pushed the right way as you said.

Can you comment at all on what I mentioned re: the FreeCAD icon earlier in this thread? I'm not sure if it's a FreeCAD bug or what. Quoting here for reference:

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.

I had the same thought on semver, by the way.

As far as HTTPS, that should be coming soon as mentioned in this thread about downtime on Wednesday the 18th: viewtopic.php?f=8&t=19928

[wmayer]

FYI, this is how the packaging works at the moment:
When creating a source tarball then it's recommended to run

Code: Select all

make dist-git

which mimics the dist target from the good old autotools. This internally runs a Python script and puts the Version.h of the build directory into the source tarball. When creating the package from the source tarball it uses the provided Version.h.
This step should be performed by our release managers on the source code of the official git repo and then the tarball should be uploaded to github.

However, most of the package maintainers seem to just use the Download button of the repo directly and ignore the tarballs. There of course no Version.h is provided. So, it then tries to create the file on cmake configure time and therefore runs a Python script which checks for several VCS but for a build from a tarball this script won't succeed. So as fallback a Version.h is created from the cmake variables PACKAGE_VERSION_NAME, PACKAGE_VERSION_MAJOR, PACKAGE_VERSION_MINOR and PACKAGE_VERSION_PATCH.

When we provide a new release then we make a new branch and set these variables. So, this should work sufficiently well. The only missing information are the url and the date.

However, when creating a package from the master branch this won't work well because the above information is always outdated.

[Bluewind]

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.

That sounds like a bug indeed, but I don't maintain freecad-git. That package is maintained by a user in the AUR (Arch Linux User repository). I just maintain the freecad package in the official repository. I expect that you'll probably have them same issue there though since that also hardcodes a path for the icon. I'm not sure where icons are search and which formats are used by the search. If you want me to fix this, please create a bug report on our tracker and I'll look into it. If you don't experience the issue with the repo pacakage, just comment on the AUR package so it's fixed there.

[kkremitzki]

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.

That sounds like a bug indeed, but I don't maintain freecad-git. That package is maintained by a user in the AUR (Arch Linux User repository). I just maintain the freecad package in the official repository. I expect that you'll probably have them same issue there though since that also hardcodes a path for the icon. I'm not sure where icons are search and which formats are used by the search. If you want me to fix this, please create a bug report on our tracker and I'll look into it. If you don't experience the issue with the repo pacakage, just comment on the AUR package so it's fixed there.

Thanks again, I'll do some more testing on different DEs before proceeding.

[Bluewind]

When we provide a new release then we make a new branch and set these variables. So, this should work sufficiently well. The only missing information are the url and the date.

However, when creating a package from the master branch this won't work well because the above information is always outdated.

All I'd suggest you change here is that you also update the cmake file accordingly when you make a new patch release (so 0.16.6000 or whatever you use). Once you commited that change I'd ask that you also tag it with the version that you just put into the cmake file. Then it will show up on the github release page and the defaults will be correct.

If you prefer that I build the Arch Linux package from the git repository, I can also do that, but I will still build from the tag (0.16 in this case), not from a branch. So at least in terms of what source I build, there would be no difference. The tag would not change when you push new release tarballs to github or when you add new commits on the branch like you do now. The probably only difference would be that the build scripts pick up the revision number and display it.

Also in case you don't already, I'd suggest that you look into `git describe --dirty` to generate your version when you build from git. That will generate a version like 1.0.0-33-g566572a-dirty where the first part is a tag, the 33 is the number of commits since that tag, followed by the hash of the current commit and finally the dirty flag indicating that the workdir has uncommited changes. With that you'd only really need one version string and you'd have all the information in one place.

[Kunda1]

When we provide a new release then we make a new branch and set these variables. So, this should work sufficiently well. The only missing information are the url and the date.

However, when creating a package from the master branch this won't work well because the above information is always outdated.

All I'd suggest you change here is that you also update the cmake file accordingly when you make a new patch release (so 0.16.6000 or whatever you use). Once you commited that change I'd ask that you also tag it with the version that you just put into the cmake file. Then it will show up on the github release page and the defaults will be correct.

If you prefer that I build the Arch Linux package from the git repository, I can also do that, but I will still build from the tag (0.16 in this case), not from a branch. So at least in terms of what source I build, there would be no difference. The tag would not change when you push new release tarballs to github or when you add new commits on the branch like you do now. The probably only difference would be that the build scripts pick up the revision number and display it.

Also in case you don't already, I'd suggest that you look into `git describe --dirty` to generate your version when you build from git. That will generate a version like 1.0.0-33-g566572a-dirty where the first part is a tag, the 33 is the number of commits since that tag, followed by the hash of the current commit and finally the dirty flag indicating that the workdir has uncommited changes. With that you'd only really need one version string and you'd have all the information in one place.

@Bluewind do you think in the meantime you will patch the FreeCAD Arch community 0.16 package so that you compile from git or are you waiting for upstream to fix this issue?

[Bluewind]

If you prefer that I build the Arch Linux package from the git repository, I can also do that, but I will still build from the tag (0.16 in this case), not from a branch. So at least in terms of what source I build, there would be no difference. The tag would not change when you push new release tarballs to github or when you add new commits on the branch like you do now. The probably only difference would be that the build scripts pick up the revision number and display it.

@Bluewind do you think in the meantime you will patch the FreeCAD Arch community 0.16 package so that you compile from git or are you waiting for upstream to fix this issue?

As I've already explained, the package would be built from the same source code. Unless you explicitly tell me that you want me to build it this way, I won't since I don't even know if it would work as expected and I don't see how some revision number tells you more than the tag (which is also in git). I'd much rather see you tagging patch releases with an accompanying change in defaults and using your version number some more. Releasing 0.16.1 or whatever wouldn't hurt.

[Kunda1]

Pinging @m42kus aka drhooves the FreeCAD-git AUR maintainer

Just wanted to keep you in on the loop here.

[m42kus]

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.

That sounds like a bug indeed, but I don't maintain freecad-git. That package is maintained by a user in the AUR (Arch Linux User repository). I just maintain the freecad package in the official repository. I expect that you'll probably have them same issue there though since that also hardcodes a path for the icon. I'm not sure where icons are search and which formats are used by the search. If you want me to fix this, please create a bug report on our tracker and I'll look into it. If you don't experience the issue with the repo pacakage, just comment on the AUR package so it's fixed there.

Hi, freecad-git maintainer here.

Applications are supposed to install their icons in various directories named /usr/share/icons/<theme>/<size>x<size>/apps/<app_name>.{png,xpm,svg}. If the files are in those locations, it's possible to just specify <app_name> in the .desktop file to use the right icon for the configured <theme>. For more info see: https://specifications.freedesktop.org/ ... ec/latest/ and https://specifications.freedesktop.org/ ... ec/latest/

It should work correctly now with the freecad-git package. Can't promise anything because I don't use icons or icon themes
Maybe kkremitzki can test it and provide feedback? I also created a patch for the freecad package (gonna pm it to you Bluewind). Don't really want to create a bug report since I didn't really have the issue.

Edit: mixed up the names