Package Details: python-zxing-cpp 3.1.1-2

Git Clone URL: https://aur.archlinux.org/python-zxing-cpp.git (read-only, click to copy)
Package Base: python-zxing-cpp
Description: Python bindings for zxing-cpp
Upstream URL: https://github.com/zxing-cpp/zxing-cpp
Licenses: Apache-2.0
Submitter: yochananmarqos
Maintainer: yochananmarqos
Last Packager: yochananmarqos
Votes: 5
Popularity: 0.72
First Submitted: 2024-05-09 23:49 (UTC)
Last Updated: 2026-08-15 15:52 (UTC)

Latest Comments

yochananmarqos commented on 2026-08-15 15:52 (UTC) (edited on 2026-08-15 15:52 (UTC) by yochananmarqos)

@bauminao: I've added ARM64 support, but will not bump the pkgrel. The binary python-zxing-cpp-bin package supports it as well.

bauminao commented on 2026-08-15 12:57 (UTC)

I guess you can add 'aarch64' to the arch-array. Needed it for yubikey-tools as dependency and managed to create the package succesfully on my pine-tab2. Someone with more knowledge should perhaps check. But it is worth to mention here, I guess.

marmis commented on 2026-08-09 06:56 (UTC)

Hi, I know AUR is locked right now, but I wanted to report this before I forget.

I've noted for some time now that some Python packages with native libraries don't have debug info for them. After looking around a bit, I think it's the default skbuild.install.strip=true that does that for this package. However, changing that option by itself wasn't enough, but combined with CMAKE_BUILD_TYPE=RelWithDebInfo it works!

build() {
  cd "$_name-$pkgver/wrappers/python"
  export SKBUILD_CMAKE_BUILD_TYPE=RelWithDebInfo
  export SKBUILD_INSTALL_STRIP=false
  python -m build --wheel --no-isolation
}

I recommend setting them because besides allowing debug builds for those that want it, makepkg tends to do a better job at stripping binaries than most build toos, so the package actually shrinks in size: "Net Upgrade Size: -0,17 MiB".

yochananmarqos commented on 2026-06-15 15:12 (UTC)

@cgirard: There are no new Python bindings, see the release notes. 3.0.0 is the latest release on PyPI.

micwoj92 commented on 2025-11-20 19:47 (UTC)

What is the logic of not wanting to add glibc dependency but adding a transistive makedep of python-setuptools? Previosly it was already installed because of python-setuptools-scm

micwoj92 commented on 2025-03-11 00:01 (UTC)

Noone says to go through all packages. But this could be simply added to your local repo and then pushed on next pkgver bump or something.

I can say about namcap that it depends, for binary packages, python modules it can be great help, however it is almost useless for packages that are ruby/perl/bash scripts.

yochananmarqos commented on 2025-03-09 22:56 (UTC) (edited on 2025-03-09 22:56 (UTC) by yochananmarqos)

@micwoj92: This is the AUR, not the Arch repos. I'm a community member, not an Arch Package Maintainer. I'm not going to go through my almost 500 AUR packages to add redundant dependencies. There has already been a lot of discussion about this topic. Look how many packages depend on glibc, it's ridiculous.

Either way, Allan said namcap should not be relied upon; however I like it.

micwoj92 commented on 2025-03-09 22:22 (UTC) (edited on 2025-03-09 22:23 (UTC) by micwoj92)

Exactly what you said, to list all dependencies explicitly

yochananmarqos commented on 2025-03-09 22:20 (UTC)

@micwoj92: The zxing-cpp repo package already depends on them. What would adding them accomplish?

P.S. Yes, I'm aware of what namcap says and transitive dependencies.

micwoj92 commented on 2025-03-09 22:09 (UTC)

Please add glibc and gcc-libs to deps