You are not logged in.
I am trying to figure out how does "Flag Package Out-of-Date" work. I am trying to make work my OpenVPN in GNOME. Now to note: yes, it works in terminal - I am talking about the Gnome extension.
When i visit the package page: networkmanager-openvpn I see that the version is 1.12.0-1
The current version in the arch repo has a version that cant handle 'data-ciphers-fallback' parameter. But after my own investigating I found out that the Upstream URL , and from there to the "NetworkManager-openvpn", leads to Gnome's Gitlab which just recently (two weeks ago) was updated exactly for this "bug".
I tried to flag it as outdated but when I search this package in the Package Search, I see no "Flag Date".
Where is the process being stalled? Is this the case where maintainers are too busy? Is this the case were the bug fix/commit on the Gnomes git is not a part of a official release?
Thank you for clarifying. ![]()
Offline
If there hasn't been a release, it's not out of date. If there's a bug in the current version, file a bug report.
Offline
If there hasn't been a release, it's not out of date. If there's a bug in the current version, file a bug report.
Well, The last official release on the Gnomes git is "1.12.0" and the arch repo has a "1.12.0-1". So there is this kind of disconnect where im unsure what this "-1" signifies. And to file a bug report - the bug is fixed. In the official repo. What should I report?
Offline
Scimmia wrote:If there hasn't been a release, it's not out of date. If there's a bug in the current version, file a bug report.
Well, The last official release on the Gnomes git is "1.12.0" and the arch repo has a "1.12.0-1". So there is this kind of disconnect where im unsure what this "-1" signifies. And to file a bug report - the bug is fixed. In the official repo. What should I report?
there is nothing to report yet. The latest version from upstream is "1.12.0". The official Arch repo has "1.12.0-1" the "1.12.0" signals that Arch is basing the package off of the matching versioning of the upstream (in this case, the latest), the "-1" signals that it's the first package release from Arch's end. Any revision made not by upstream but by arch is where the "-X" comes into play, anything before that is straight from upstream.
With that being said, there is nothing to report because upstream hasn't released a new version. They may have patched the bug in the commit but they still haven't made a binary release. Once they do a new binary release, then you may flag the package out of date
Offline
Proximity wrote:Scimmia wrote:If there hasn't been a release, it's not out of date. If there's a bug in the current version, file a bug report.
Well, The last official release on the Gnomes git is "1.12.0" and the arch repo has a "1.12.0-1". So there is this kind of disconnect where im unsure what this "-1" signifies. And to file a bug report - the bug is fixed. In the official repo. What should I report?
there is nothing to report yet. The latest version from upstream is "1.12.0". The official Arch repo has "1.12.0-1" the "1.12.0" signals that Arch is basing the package off of the matching versioning of the upstream (in this case, the latest), the "-1" signals that it's the first package release from Arch's end. Any revision made not by upstream but by arch is where the "-X" comes into play, anything before that is straight from upstream.
With that being said, there is nothing to report because upstream hasn't released a new version. They may have patched the bug in the commit but they still haven't made a binary release. Once they do a new binary release, then you may flag the package out of date
I understand now, thanks for the clarification.
Offline
You can still file a bug report:
https://gitlab.archlinux.org/archlinux/ … n/-/issues
If the maintainer deems it significant enough, they can cherry-pick the fix into 1.12.0 (and the package would then become 1.12.0-2).
Offline
You can still file a bug report:
https://gitlab.archlinux.org/archlinux/ … n/-/issuesIf the maintainer deems it significant enough, they can cherry-pick the fix into 1.12.0 (and the package would then become 1.12.0-2).
Ahaa so the Arch's repo sort of forks from upstream on its own git if the situation needs it. Makes sence now that I think about it. Thanks. It is question if its better at this time to wait for a release on upstream or file a bug in arch repo.
Thanks for the answer thought ![]()
Offline
No not at all, the above git repo just contains the packaging files (PKGBUILD, .SRCINFO, .nvchecker.toml etc.) needed to build the package in a clean chroot: https://gitlab.archlinux.org/archlinux/ … er-openvpn
This is not the git repository for "networkmanager-openvpn" or a fork of it!
Offline
No not at all, the above git repo just contains the packaging files (PKGBUILD, .SRCINFO, .nvchecker.toml etc.) needed to build the package in a clean chroot: https://gitlab.archlinux.org/archlinux/ … er-openvpn
This is not the git repository for "networkmanager-openvpn" or a fork of it!
Then what does the "-1" stand for? If I understood it, if there is a bug, I can create an issue on arch repo and the bug can be fixed in the arch repo. Therefor deviating from upstream. Fork might a bad word there, more like a different branch.
Last edited by Proximity (2025-03-03 17:55:37)
Offline
Then what does the "-1" stand for?
Package Release (pkgrel).
33b5156 build: Fix tests by adding missing config to EXTRA_DIST fixes failing tests which Arch does not run. Do you not want instead or in addition
fd01b9d Add support for 'data-ciphers-fallback' option and ef27d60 Add support for 'data-ciphers' and 'data-ciphers-fallback' to the GUI?
Offline
Proximity wrote:Then what does the "-1" stand for?
Package Release (pkgrel).
33b5156 build: Fix tests by adding missing config to EXTRA_DIST fixes failing tests which Arch does not run. Do you not want instead or in addition
fd01b9d Add support for 'data-ciphers-fallback' option and ef27d60 Add support for 'data-ciphers' and 'data-ciphers-fallback' to the GUI?
Youre right. I copied the wrong link.
Offline