Arch Linux User Repository

@bergentroll: I added a check() function and made some other fixes. So now makepkg --check pulls cunit and runs the tests while makepkg --nocheck doesn't.

I think this should fix the issue.

Seems cunit must be in makedepends because it has been calling in build(), and there is no check() actually. Or better to disable tests while building with tests option and move it to check() function.

@nesk_aur thanks for the confirmation. I had an issue with aarch64 in the past, which was supposedly fixed, but I was waiting for a second confirmation before making it official. I guess now I have that :-)

@plp thanks, it was a problem on my end (older python installed). Btw, package builds and works on aarch64 arch.

@nesk_aur it works for me with python-cogapp 3.3.0-7:

$ pacman -Qs python-cogapp
local/python-cogapp 3.3.0-7
    A code generator for executing Python snippets in source files

Does the failure also happen when you do cog -h?

Not building (python-cogapp is installed):

FAILED: src/config.h 
/usr/bin/cog -d -o src/config.h ../qman-1.3.1/src/config.h.cog
Traceback (most recent call last):
  File "/usr/bin/cog", line 5, in <module>
    from cogapp import main
ModuleNotFoundError: No module named 'cogapp'
[2/10] Generating src/config.c with a custom command
FAILED: src/config.c 
/usr/bin/cog -d -o src/config.c ../qman-1.3.1/src/config.c.cog
Traceback (most recent call last):
  File "/usr/bin/cog", line 5, in <module>
    from cogapp import main
ModuleNotFoundError: No module named 'cogapp'
ninja: build stopped: subcommand failed.
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/bin/ninja -C /dev/shm/qman/src/build
==> ERROR: A failure occurred in build().

@intelfx

I understand what you are saying. However, until now qman-git has been playing the role of the stable Qman release package. I admit, this shouldn't have happened, and I should have been paying more attention to the guidelines. But I haven't been, and it has happened. So, now we have a bunch of users who should really migrate to qman, otherwise they'll be stuck with the unstable qman-git package.

Perhaps then it may be better if we keep replaces in place, and also delete qman-git, to give everybody a chance to migrate. Then, after a reasonable amount of time has passed (perhaps 3-4 weeks), we can remove the replaces directive from qman and re-introduce qman-git as a proper unstable package that follows the devel branch.

I did not notice this at first, but please remove the replaces=() line. See the AUR rules of submission, subpoint 5 for details.

@intelfx Definitely put it in the wiki. It makes absolute sense once explained, but it's not something the casual packager will ever think of.

@plp

On that package, I did mean "do not include". Those are two different things.

1. If you are cloning a git repository, it already includes the name of the project. Do not decorate it with $pkgname. Otherwise, if someone uploads a variant of your package to AUR (say, qman-patched-git or qman-release-git), the user will get two separate clones of the same git repo (both named after respective $pkgnames) for no good reason.

2. If you are downloading a tarball from GitHub and its name only includes the version, do decorate it with $pkgname (or, better, the raw project name, when the two don't match). Otherwise, the user will get a v1.2.3.tar.gz in their $SRCDEST, which will mess up other similarly broken packages in case of a version clash.

I should probably put this into the wiki.