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

This subforum is specifically to discuss packaging issues on different platforms (windows, mac, linux), and using different packaging systems (conda, etc...)
User avatar
kkremitzki
Veteran
Posts: 2511
Joined: Thu Mar 03, 2016 9:52 pm
Location: Illinois

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

Post by kkremitzki »

m42kus wrote:
Bluewind wrote:
kkremitzki wrote: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 :P
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
Yep, that fixed it. Thanks!
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
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

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

Post by Kunda1 »

m42kus wrote: Thu Feb 16, 2017 11:19 pm
Bluewind wrote:
kkremitzki wrote: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 :P
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
Linking https://forum.freecadweb.org/viewtopic.php?f=8&t=24555 which is an ARCH linux FC 0.16 packaging issue due to either qtwebkit removal or something else
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
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

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

Post by Kunda1 »

Bluewind wrote: Tue Jan 17, 2017 1:47 pm
wmayer wrote: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.
kkremitzki wrote:ping
can we do this yet ?
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
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

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

Post by Kunda1 »

Bluewind wrote: Tue Jan 17, 2017 1:47 pm
wmayer wrote: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.
kkremitzki wrote:ping
can we do this yet ?
webknjaz wrote:ping
Care to weigh in since you're proposing https://github.com/FreeCAD/FreeCAD/pull/952
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
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

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

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

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

Post by Kunda1 »

We can use repology now to track FreeCAD and its dependencies:

https://github.com/luzpaz/FreeCAD-dependencies/

Image
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
User avatar
Pauvres_honteux
Posts: 728
Joined: Sun Feb 16, 2014 12:05 am
Location: Far side of the moon

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

Post by Pauvres_honteux »

Hi, anyway we can aid Adrian Schröter in the task of bringin' the full version number to OpenSUSE? The solution must be low in maintenance resources, preferably automagic if possible.

As it stands now there's no way for a lay person to know what version he/she is running, in OpenSUSE. What I can read out, in YAST, looks like a jibberish hash number...
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

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

Post by Kunda1 »

Mod note: Moved this thread to the Packaging forum.
Pauvres_honteux wrote: Tue Aug 20, 2019 4:52 am Hi, anyway we can aid Adrian Schröter in the task of bringin' the full version number to OpenSUSE? The solution must be low in maintenance resources, preferably automagic if possible.
Sure thing! Please invite them to post their questions here.
Pauvres_honteux wrote: Tue Aug 20, 2019 4:52 am As it stands now there's no way for a lay person to know what version he/she is running, in OpenSUSE. What I can read out, in YAST, looks like a jibberish hash number...
https://forum.freecadweb.org/viewtopic.php?f=42&t=37216
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