Arch Linux User Repository

@TrialnError, the replacement is a good idea and I was unaware that vercmp would treat the _rc1 suffix as "newer" like that (TIL!).

I've pushed and updated pkgbuild with the version fixed. Thanks for the suggestion!

In such cases substitution could be used:
pkgver=0.2.5_rc1
And wherever the real one is needed: ${pkgver/_/-} which replaces _ with -.
Formally the full pkgver from upstream should be seen in the pkgver. Not only for maintenance reasons like tamirzb noted, but it is expected. That being said I am not sure how I would handle it. Although it seems the proposed case above would be recognized by vercmp? (vercmp 0.1 0.1_rc1). And if not some other substitution should work: pkgver=0.2.5_1 and ${pkgver/_/-rc}?

Edit: Some correction. I missed a - in the output of vercmp xD

Normally I would agree but 0.2.5-rc1 is not valid in the pkgver:

==> ERROR: pkgver is not allowed to contain colons, forward slashes, hyphens or whitespace.

That said, even if it was, -rc1 would be considered a downgrade given that 0.2.5 had already been published which would require a bump to the epoch for pacman to treat it as an upgrade. Given that this is the first time upstream has done this (afaik), I think it's better to just work around it and hope they don't use pre-release versions as bugfixes in the future. If it starts to become a problem then some other way of versioning this package will likely be needed.

@jhenson Yeah their usage of -rc1 is a bit weird. In this case it might be better to put the full 0.2.5-rc1 in the pkgver as usually the convention is to increase pkgver when the code changes and increase pkgrel when only the PKGBUILD changes. You can then also use the $pkgver variable in other parts of the PKGBUILD instead of hardcoding it for easier maintenance.

Ah! Thanks for that, @TrialnError. I totally missed when they added that support. I've updated the package (and fixed the source URL that I hadn't noticed was broken).

pacman/makepkg is able to produce checksums since 6.1 if the tag fragment is used with a git source. And #tag is used.

As I said in the commit message, upstream has (apparently) used the -rc1 suffix as a bugfix release (it was released after 0.2.5 and contains a fix for a nil pointer dereference). That's why I left this package at 0.2.5.

I dropped the SHA since the pakage is now building from the git repo and is now setting the version the same way upstream does it.

Why the shift to a release candidate instead of the stable version?

Also why remove the sha256 checksum?

Thanks for the report. I've added bluez-obex as an opt dep since it's not required unless you want to transfer files.

bluez-obex should probably be added as a dep? When I ran it the first time there was a pop-up which warned about missing feature of sending or receiving files because bluez obex is missing.