Package Details: bluetuith 1:0.2.6-2

Git Clone URL: https://aur.archlinux.org/bluetuith.git (read-only, click to copy)
Package Base: bluetuith
Description: TUI-based bluetooth manager
Upstream URL: https://github.com/bluetuith-org/bluetuith
Keywords: adapter blue bluetooth bluetuith manager obex receive send tooth tui
Licenses: MIT
Submitter: lmartinez-mirror
Maintainer: dpeukert
Last Packager: dpeukert
Votes: 12
Popularity: 1.18
First Submitted: 2022-07-09 05:54 (UTC)
Last Updated: 2026-04-15 16:21 (UTC)

Dependencies (8)

Required by (0)

Sources (1)

Latest Comments

1 2 Next › Last »

TrialnError commented on 2026-04-18 17:33 (UTC) (edited on 2026-04-18 17:33 (UTC) by TrialnError)

One remark on the recent PKGBUILD changes: Why would every increase in pkgver result in a new clone of the sources? That is unnecessary

heapifyman commented on 2026-04-17 11:29 (UTC) (edited on 2026-04-17 11:31 (UTC) by heapifyman)

@dpeukert

==> Starting prepare()...
go: github.com/darkhz/tview@v0.0.0-20240308094543-6078a888ff79: invalid version: unknown revision 6078a888ff79

archie123q commented on 2025-09-21 17:41 (UTC) (edited on 2025-09-21 17:44 (UTC) by archie123q)

@tamirzb mistake was corrected

Anyone who upgraded this to v0.2.5 should do:

pacman -Rs bluetuith
remove bluetuith from pacman cache
build and install aur package

I'm doing contributions to AUR first time, let me know if there any problems with this package

tamirzb commented on 2025-09-17 10:11 (UTC)

@whiteman808 Why go back to v0.2.5? And why use epoch?

jhenson commented on 2025-08-29 03:39 (UTC)

@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!

TrialnError commented on 2025-08-28 18:43 (UTC) (edited on 2025-08-28 18:48 (UTC) by TrialnError)

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

jhenson commented on 2025-08-28 13:29 (UTC)

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.

tamirzb commented on 2025-08-28 07:27 (UTC)

@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.

jhenson commented on 2025-08-27 17:23 (UTC)

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).

TrialnError commented on 2025-08-27 17:12 (UTC)

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

1 2 Next › Last »