Arch Linux User Repository

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

Sorry, I thought you meant do not include initially. I was wondering why.

It all makes sense now.

Please do include $pkgname or similar in the source archive name, when it doesn't include the project name already:

-source=("https://github.com/plp13/qman/archive/refs/tags/v1.3.1.tar.gz")
+source=("${pkgname}-${pkgver}.tar.gz::https://github.com/plp13/qman/archive/refs/tags/v${pkgver}.tar.gz")

Otherwise you mess with people who use a shared $SRCDEST (which gets littered by files like v1.3.1.tar.gz, impacting build of other packages that are broken in the same way).