Thanks!

More useful easy to install packages include libinklevel and ink from AUR (to show printer's ink levels) and the package img2pdf which converts images to a PDF file (available from Arch's repo - can be compiled with an older version of python-pikepdf such as 2.16.1 which is also available from Arch's repo after removing the check section and its dependencies from img2pdf's PKGBUILD).

The package zbar-gtk from Hyperbola's repos cannot be installed - a workaround is to compile a version of zbar containing zbar-gtk such as using this PKGBUILD (this version provides both zbar-gtk and zbar-qt).

# Maintainer (Arch): Felix Yan <felixonmars@archlinux.org>
# Contributor (Arch): Marti Raudsepp <marti@juffo.org>
# Contributor (Arch): Radu Andries <admiral0@tuxfamily.org>
# Contributor (Arch): Andy Weidenbaum <archbaum@gmail.com>
# Maintainer: André Silva <emulatorman@hyperbola.info>

pkgname=zbar
pkgver=0.23.90
_debver=0.23.90
_debrel=1
pkgrel=1
pkgdesc="Application and library for reading bar codes from various sources"
arch=('i686' 'x86_64')
url="https://github.com/mchehab/zbar"
license=('LGPL-2.1')
makedepends=('gtk' 'graphicsmagick' 'libxv' 'v4l-utils' 'qt-x11extras' 'python' 'xmlto'
             'docbook-xsl' 'gobject-introspection' 'quilt')
conflicts=('zbar-gtk' 'zbar-qt' 'python-zbar')
provides=('zbar-gtk' 'zbar-qt' 'python-zbar')
replaces=('zbar-gtk' 'zbar-qt' 'python-zbar')
source=("$pkgname-$pkgver.tar.gz::https://github.com/mchehab/zbar/archive/$pkgver.tar.gz"
        "https://deb.debian.org/debian/pool/main/z/zbar/zbar_$_debver-$_debrel.debian.tar.xz")
sha512sums=('d73d71873bec68ee021997512a9edbd223f5f5fe43c66c4dd3502224ba6009be2e5e1714766cb8e1056244673e87e0939ed0319116f61d7371b5ab79fb5e04eb'
            '14992376d82dae014450b1c9e44afce71be776fc2edc3d37436330f311322b508de7f28e96409d483dd5c40fd7e31922788b6a8975480e15ed784e0c9c43e11b')

prepare() {
  cd $pkgname-$pkgver
  if [[ ${pkgver%.*} = ${_debver%.*} ]]; then
    # Debian patches
    export QUILT_PATCHES=debian/patches
    export QUILT_REFRESH_ARGS='-p ab --no-timestamps --no-index'
    export QUILT_DIFF_ARGS='--no-timestamps'

    mv "$srcdir"/debian .

    quilt push -av
  fi
  autoreconf -vfi
}

build() {
  cd $pkgname-$pkgver
  ./configure --prefix=/usr --with-qt --with-gtk=gtk3 --without-dbus --with-graphicsmagick --without-imagemagick CFLAGS="$CFLAGS -DNDEBUG"
  sed -i -e 's/ -shared / -Wl,-O1,--as-needed\0/g' libtool
  make
}

package() {
  cd zbar-$pkgver
  make DESTDIR="$pkgdir" install

  install -Dm644 LICENSE.md -t "$pkgdir"/usr/share/licenses/$pkgname
}

# vim:set ts=2 sw=2 et:

Just also a reminder: We are for sure not "Arch GNU/Linux" any longer and our compatibility is and will going to vanish very soon. Even though packages like img2pdf are not included for a reason: They are impossible to build correct in a clean chroot-environment as their dependency is also not possible to be resolved (meaning therefore the dependencies). Here is a log from earlier tryouts:

 |  WARNING: The pip package is not available, falling back to EasyInstall for handling setup_requires/test_requires; this is deprecated and will be removed in a future version.
 |  Download error on https://pypi.org/simple/setuptools_scm_git_archive/: [Errno -3] Temporary failure in name resolution -- Some packages may not be found!
 |  Download error on https://pypi.org/simple/setuptools-scm-git-archive/: [Errno -3] Temporary failure in name resolution -- Some packages may not be found!
 |  Couldn't find index page for 'setuptools_scm_git_archive' (maybe misspelled?)

To explain: Even to have some stable tarball does not mean the concurrent package is respecting no further download. This is not supported within our build-environment and therefore it is not possible to include those packages, to be called for sure not clean for building. And yes: I understand absolutely the point to include more packages at a time and using the PKGBUILD-scripts back from Arch GNU/Linux at all. Nevertheless: The warning stays as to be seen above. Those packages and PKGBUILD-scripts can be only source for further ways from now on. Many are not designed very good or even worse just built without any clean environment and just uploaded as finished package. So there is this illusion they work in some way. They do not work and will not ever work for real!

The best way for testing is to setup libretools and use a chroot-environment. The commands makepkg and libremakepkg are not fully comparable at all, right from the beginning makepkg is absolutely tolerant for anything to be downloaded in between. But the chroot-environment is for sure not and very strict: One phase for collecting, afterwards building, checking and packaging without any further connection. Missing dependencies? Or wrong defined parameters will lead to an immediate ending of the process while makepkg stay a bit longer or tolerate them through downloading (to be seen in the log above as difference). And makepkg is using local installed files and packages, even when not defined within depends or makedepends. The result is not a clean package at all, not possible for used within chroot-environments and therefore also not possible to be included within the repositories. That's the reasoning when we exclude packages besides being incompatible, unfree, insecure or more. And with the dependency-example above: There is the deprecated-warning for everyone being alarmed that our way without python-pip is not possible for long with it. It is just rational to left out those packages as they are of no use and other applications using them the same.