Package Details: hib-dlagent-git 0.7.8.g4ffd7dd-1

Git Clone URL: https://aur.archlinux.org/hib-dlagent-git.git (read-only, click to copy)
Package Base: hib-dlagent-git
Description: Tool to download Humble Indie Bundle binaries by file name
Upstream URL: https://github.com/hagabaka/hib-dlagent
Licenses: GPL2
Conflicts: hib-dlagent
Provides: hib-dlagent
Submitter: hagabaka
Maintainer: tallero
Last Packager: hagabaka
Votes: 8
Popularity: 0.000000
First Submitted: 2015-04-17 01:03 (UTC)
Last Updated: 2016-02-21 23:02 (UTC)

Dependencies (4)

Required by (3)

Sources (1)

Latest Comments

1 2 3 Next › Last »

dreieck commented on 2024-06-20 12:52 (UTC)

Dependency python-humblebundle does not exist.

There is a package python-humblebundle-downloader, maybe this can be used?

Regards!

MarsSeed commented on 2024-04-22 00:43 (UTC) (edited on 2024-04-26 11:33 (UTC) by MarsSeed)

The humblebundle Python library had its last release in 2015 and was reported as broken as early as 2017.

The hib-dlagent repo is abandoned since 2018 and the application was reported as crashing during normal use in that year.

This package should be deleted because it is not functional and therefore not viable to keep.

Airon90 commented on 2024-04-18 07:04 (UTC)

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

tallero commented on 2024-03-18 00:31 (UTC) (edited on 2024-03-18 00:35 (UTC) by tallero)

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.

dreieck commented on 2022-05-09 11:35 (UTC) (edited on 2022-05-09 11:37 (UTC) by dreieck)

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.

Commander commented on 2022-03-07 10:06 (UTC)

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.

jose1711 commented on 2019-02-14 10:05 (UTC) (edited on 2019-02-14 10:05 (UTC) by jose1711)

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

hagabaka commented on 2015-05-10 23:48 (UTC)

@GloW: I just pushed a commit that should fix it. Can you update and try?

GloW commented on 2015-05-10 21:38 (UTC)

==> Retrieving sources... -> Downloading 140_Linux_1389820765.zip... Searching for 140_Linux_1389820765.zip Traceback (most recent call last): File "/usr/share/hib-dlagent/discover-url.py", line 16, in <module> for subproduct in order.subproducts: TypeError: 'NoneType' object is not iterable