Arch Linux User Repository

This package seems to require humblebundle-python, which is not in AUR: https://pypi.org/project/humblebundle/

I have a package depending on this, a proteus providing package, but i currently use another proteus providing package not depending ow this I think.

I maintain all proteus providing packages btw.

The reason I have adopted this download agent is it's only natural for a trusted aur maintainer to obtain the best chain of trust over the largest part of the dependency tree of his packages if he can, since aur maintainers have write permissions over repos.

This is particularly meaningful because it's not safe to have hanging around broken or malicious dependencies managed by anybody so you have to check again and again if they get tampered with, so if you can optimize you optimize.

There's no reason to not have subsets of the aur known safely maintained instead that orphan or deleted, so orphan.

This is a note for all those who may wonder why I do maintain so many things on the aur.

Ahoj,

two issues regarding versioning:

1.:

The $pkgver of this package in the database is higher than the actual $pkgver which the PKGBUILD automatically fetches during the run of pkgver():

• AUR: 0.7.8.g4ffd7dd
• Current: 0.7.1

Current is smaller than AUR -- please check if

• the versioning scheme has changed, then increment epoch,
• pkgver() does not fetch the correct version, then correct pkgver(),
• the AUR version is just wrong -- then once re-upload with the correct version and increment epoch to signal that it is not a version downgrade.

Latest upstream commit seems to have happened at 2018-11-10.

Note that according to the executable hib-dlagent version is 0.6, which is even smaller than what git describe --tags shows. This might be a failure to update the file, though, on upstream side, which I have reported as upstream issue here.

2.:

The current version as calculated by pkgver() is 0.7.1. This seems not to reflect individual git commits -- but the package uses the latest git checkout. The version must be strongly monotoneously increasing -- so each git commit should produce some higher version. So I suggest to add some +r<git-commit-count> after the release version.

Here is a suggestion for a pkgver(), which currently produces 0.7.1+r44.20181110.f80346b:

pkgver() {
  cd "${srcdir}/${_appname}"

  local _ver
  local _rev
  local _date
  local _hash

  # _ver="$(grep '^[[:space:]]*VERSION[[:space:]]*=' hib-dlagent | tail -n1 | awk -F '=' '{print $2}' | tr -d '[[:space:]]')"  # Use version as the software thinks.
  _ver="$(git describe --tags | sed 's/^v//; s/-/./g')"  # Use version according to git tags.

  _rev="$(git rev-list --count HEAD)"
  _date="$(git log -1 --date=format:"%Y%m%d" --format="%ad")"
  _hash="$(git rev-parse --short HEAD)"

  if [ -z "${_ver}" ]; then
    error "Version could not be determined."
    return 1
  else
    printf '%s' "${_ver}+r${_rev}.${_date}.${_hash}"
  fi
}

Please address those issues, issue number 1 seems to be present already since 2019-02-14 at least, so more than three years now!

Thanks for maintaining.

Not sure if we should flag this out of date because of it not fetching versioning correctly or not. But as jose mentions its an issue with how it fetches pkgver.

i think there's something wrong with pkgver(). i am getting 0.7.1 - you have 0.7.8.g4ffd7dd