Arch Linux User Repository

Semantically, x.ry.gz means y revisions of x. If not going to actually count revisions, should use a different letter, like c for count or t for total.

Using the total count ignores that every example with version number greater than 0 uses git describe, where "revision" is the number of additional commits since the tagged version. The total count is used as a fallback when no versions have been tagged.

Knowing the number of commits since the version was tagged is useful when looking for the source of regressions or checking whether a bug might have been fixed prior to opening a new issue report. For instance, if a bug is found in 0.8.2, there's no point building and checking 0.8.2.r0.g#.

Since 0.8.2 was recently tagged, monotonicity is preserved because 0.8.2.r0.g# is greater than 0.8.RC2.r473.150c1e8.

@xiota

Pacman knows that RC versions are lower than numeric versions. You can use vercmp command to check. vercmp 0.8.RC2.r473 0.8.0 return -1 which means RC version is lower than numeric.

VCS package guidelines

They say that REVISION is a monotonically increasing number that uniquely identifies the source tree. The total count of commits totally fits this monotonic requirement. I would even say it is more monotonic than the number of commits since last tag.

Also reducing the REVISION now would result new packages being considered lower version than existing ones.

Please change the pkgver() to

• Use the full release version numbers only (not RC). This makes comparison with the standard aur/bubblejail package easier.
• Use the number of revisions since release, not the total revision count, in accordance with VCS package guidelines. This makes determining the difference between the normal and git packages easier.

Two different, working solutions have been provided in previous comments.

Thanks for updating. Why do you want to avoid sed? For repositories that are appropriately tagged, it is the method recommended in the vcs package guidelines.

Some problems with the current pkgver.

• Non numerical component in the version-proper: 0.8.RC2. I would prefer the last real, fully numerical release version.
• Counts all commits: r473. I would prefer to count commits since release, as git describe normally does. Versions that are identical to release would be immediately identifiable by r0. This is the standard that the vcs package guidelines recommends.
• git hash isn't prefixed with g. This is inconsequential, but is the norm established by git describe and the vcs package guidelines.

pkgver() {
  cd "$srcdir/$pkgname"

  _version=$(git describe --abbrev=0 --tags --match [0-9]*.[0-9]*.[0-9] --match [0-9]*.[0-9]*.[0-9][0-9])
  _count=$(git rev-list --count $_version..HEAD)
  _commit=$(git rev-parse --short HEAD)

  printf "%s.r%s.g%s" \
    "$_version" \
    "$_count" \
    "$_commit"
}

@xiota I implemented the fixes. Thank you for pointing them out.

As for pkgver() I used a slightly different solution that does not involve sed.

This should depend on python-pyxdg because aur/python-xdg is an incompatible package.

License should be GPL3, not GPL3+. Otherwise, custom license file needs to be installed to /usr/share/licenses/bubblejail-git.

Also, please update pkgver() to produce version strings like 0.7.0.r49.g9278e6b:

git describe --long --tags --match [0-9]*.[0-9]*.[0-9] --match [0-9]*.[0-9]*.[0-9][0-9] | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'

Tests should be fixed now.

@Nonie689 yeah, when I moved the packages I forgot to update the module location.

Failed at the testing:

meson testlog.txt

File "/usr/lib/python3.10/unittest/loader.py", line 436, in _find_test_path module = self._get_module_from_name(name) File "/usr/lib/python3.10/unittest/loader.py", line 377, in _get_module_from_name import(name) File "/home/archuser/.cache/pacaur/bubblejail-git/src/bubblejail-git/test/test_service_info.py", line 22, in <module> from bubblejail.services import (SERVICES_CLASSES, BubblejailService, ModuleNotFoundError: No module named 'bubblejail'

Ran 3 tests in 0.000s

FAILED (errors=3)

Summary of Failures:

1/1 unittest FAIL 0.17s exit status 1

Ok: 0

Expected Fail: 0

Fail: 1

Unexpected Pass: 0

Skipped: 0

Timeout: 0