Arch Linux User Repository

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.

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

I'm getting this on build():

Traceback (most recent call last):
  File "/usr/bin/meson", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3250, in <module>
    @_call_aside
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3234, in _call_aside
    f(*args, **kwargs)
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3263, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 583, in _build_master
    ws.require(__requires__)
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 900, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 786, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'meson==0.52.0' distribution was not found and is required by the application

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

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.

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

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

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.

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.

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.

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.

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.