Package Details: auracle-git r427.33f9097-1

Git Clone URL: https://aur.archlinux.org/auracle-git.git (read-only, click to copy)
Package Base: auracle-git
Description: A flexible client for the AUR
Upstream URL: https://github.com/falconindy/auracle
Keywords: aur
Licenses: MIT
Conflicts: auracle
Provides: auracle
Submitter: Foxboron
Maintainer: artafinde (falconindy)
Last Packager: falconindy
Votes: 123
Popularity: 0.47
First Submitted: 2017-07-02 16:40 (UTC)
Last Updated: 2025-04-16 17:39 (UTC)

Dependencies (13)

Required by (10)

Sources (1)

Pinned Comments

artafinde commented on 2022-01-26 09:15 (UTC) (edited on 2022-01-29 10:24 (UTC) by artafinde)

If the build fails:

  • Clear your aur helper cache and SRCPKGDEST directory
  • Rebuild in clean chroot 1
  • If it still fails, use a paste bin 2 to show full build logs

There's a package build already which you can try out from my repo.

falconindy commented on 2020-05-31 15:35 (UTC)

FAQ:

  • The dependencies are correct. fmt and nlohmann_json are configured as subprojects for ease of development on my end, and it's only natural to statically link C++ projects, as ABI stability with exported C++ libraries isn't a thing (compared to C).
  • If you think pod2man is missing, it's a configuration problem on your end. pod2man is part of the perl package, but in a perl-specific PATH handled by /etc/profile.d/perlbin.sh
  • I'm only able to test auracle on i686 and x86_64, so that's what I'm willing to commit to in the PKGBUILD. If you want to build this on some other architecture, use makepkg -A. The "any" architecture is reserved for packages with architecture independent files (and compiled C++ is not).

Latest Comments

« First ‹ Previous 1 .. 15 16 17 18 19 20 21 22 23 24 25 .. 28 Next › Last »

falconindy commented on 2019-11-10 17:00 (UTC)

'auracle update' now exists, and does what 'cower -ud' used to do. 'auracle sync' is deprecated (verb still exists, but is now undocumented) and is replaced by 'auracle outdated'.

falconindy commented on 2019-11-03 14:11 (UTC)

I'm not interested in adding arm support if I can't actually test. The GitHub repo needs an ARM CI if you want this.

razer commented on 2019-11-03 07:26 (UTC)

Please add 'armv6h', 'armv7h' to have it working on arm boards like the raspberry

SanskritFritz commented on 2019-10-24 12:20 (UTC)

lisu_ml How do you get notified by a pkgrel change anyway? In what manner does pkgrel bump help you in this situation?

lisu_ml commented on 2019-10-24 10:23 (UTC)

I agree, it's really sad.

Let's people maintain their packages all along, who needs AUR anyway?

Was nice talking to you. So long.

falconindy commented on 2019-10-24 10:19 (UTC)

Nah, it's annoying that people don't understand how the AUR works.

Packages you install from the AUR are your responsibility. As is, you need to uninstall auracle, upgrade, and then rebuild/reinstall. Changing the pkgrel doesn't offer anything here.

lisu_ml commented on 2019-10-24 10:10 (UTC)

Also, something to think about. Imagine situation like this:

Someone has some AUR packages installed on the system. But he/she prefers to keep packages build from AUR in the private custom repository so they can be updated automatically with pacman. The person has some scripts to automatically rebuild and upload to the repo all AUR packages he uses. The script automatically checks if there is new version of the package available in AUR. What happens with auracle-git right now? It's not being rebuilt by the script as both pkgver and pkgrel are the same as previously. Nothing has changed to tell the script there is new version or release of the package. So what he does? He clones the auracle-git AUR repo, manually bumps pkgrel, rebuilds and uploads new release to the repository as otherwise pacman wouldn't pick it up on system upgrade.

This sucks. And could be avoided with simple pkgrel build, which is totally proper thing to do in cases like that.

Not my package, but it's really annoying people don't understand the difference between version and release.

lisu_ml commented on 2019-10-24 10:01 (UTC)

What you have just said is absolutely true, correct and expected.

The pkgrel bump is required only now, only for r290.d59f80b as this specific GitHub release results in broken shared dependencies in AUR if anyone has it already built and installed and it means the package has to be rebuilt. Once upstream commits new changes to the repo, makepkg would trigger pkgver() which will trigger automatic rebuild, so pkgrel should be lowered as having it set to 2 is not required anymore, as the version has changed.

So yes, users with already installed package could rebuild the package manually, and trigger manual update or maintainer could simply bump pkgrel and it would be picked up automatically by any AUR software manager / helper.

For me, the choice is obvious.

SanskritFritz commented on 2019-10-24 09:46 (UTC) (edited on 2019-10-24 09:46 (UTC) by SanskritFritz)

In your example the version was not changed so pkgver() was not run. When the version changes (meaning there was new commits upstream) then pkgver() is fired and it resets the pkgrel to 1.

lisu_ml commented on 2019-10-24 09:41 (UTC) (edited on 2019-10-24 09:43 (UTC) by lisu_ml)

But the pkgrel will be updated also when you rebuild the package.

No, it won't

Unchanged pkgrel:

Finished making: auracle-git r290.d59f80b-1 (Thu 24 Oct 2019 11:32:07 CEST)

Bumped pkgrel:

Finished making: auracle-git r290.d59f80b-2 (Thu 24 Oct 2019 11:33:46 CEST)

So again: Git package users are expected to follow upstream development and rebuild the package themselves when necessary. https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_versioning

Not sure what I should get from it? The link points to arch packaging guidelines and there is no even mention about VCS AUR packages.

Following the link:

Package releases (i.e. PKGBUILD#pkgrel) are specific to Arch Linux packages.

So again: pkgrel are specific to packages, so they can be bumped on demand if required.

Here is more suitable link: https://wiki.archlinux.org/index.php/VCS_package_guidelines#Guidelines

Which says:

If the resulting package is different after changing the dependencies, URL, sources, etc. increasing the pkgrel is mandatory. Touching the pkgver is not.

And in auracle-git case, the resulting package is different as it's built using new version of shared library, so the pkgrel should be bumped.

That's my opinion.

« First ‹ Previous 1 .. 15 16 17 18 19 20 21 22 23 24 25 .. 28 Next › Last »