PKGBUILD review request

denisal · 2019-03-31 01:59:14

I just created my first two PKGBUILDs, would appreciate a quick review.

# Maintainer: Denis Alevi <mail at denisalevi dot de>

pkgname=python-httpsig
_name=${pkgname#python-}
pkgver=1.3.0
pkgrel=1
pkgdesc='Secure HTTP request signing using the HTTP Signature draft specification'
url='https://github.com/ahknight/httpsig'
arch=('any')
license=('MIT')
depends=('python-pycryptodome')
optdepends=('python-requests')
makedepends=('python-setuptools')
source=("https://files.pythonhosted.org/packages/source/${_name::1}/$_name/$_name-$pkgver.tar.gz")
sha256sums=('71d6d50246129c4f7cfec20f5e57e351d2b8492d631cc2aa967914acf91f6ce6')

build() {
  cd "${srcdir}/${_name}-${pkgver}"
  python setup.py build
}

package() {
  cd "${srcdir}/${_name}-${pkgver}"
  python setup.py install --optimize=1 --root="${pkgdir}" --skip-build
  install -D -m 644 LICENSE.txt "${pkgdir}/usr/share/licenses/$pkgname/LICENSE.txt"
}

check() {
  cd "${srcdir}/${_name}-${pkgver}"
  python setup.py test
}

# Maintainer: Denis Alevi <mail at denisalevi dot de>

pkgname=dpt-rp1-py-git
_name=${pkgname%-git}
pkgver=0.1.0r72.9d7aec5
_version=0.1.0
pkgrel=1
pkgdesc='Python package to manage a Sony DPT-RP1'
url='https://github.com/janten/dpt-rp1-py'
arch=('any')
license=('MIT')
depends=('python-httpsig' 'python-requests' 'python-pbkdf2' 'python-urllib3')
makedepends=('git' 'python-setuptools')
source=("git+https://github.com/janten/${_name}.git")
md5sums=('SKIP')

pkgver() {
  cd "${srcdir}/${_name}"
  ( set -o pipefail
    git describe --long 2>/dev/null | sed 's/\([^-]*-g\)/r\1/;s/-/./g' ||
    printf "%sr%s.%s" "$_version" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
  )
}

build() {
  cd "${srcdir}/${_name}"
  python setup.py build
}

package() {
  cd "${srcdir}/${_name}"
  python setup.py install --optimize=1 --root="${pkgdir}" --skip-build
  install -D -m 644 LICENSE "${pkgdir}/usr/share/licenses/$pkgname/LICENSE"
}

Both packages depend (at least indirectly) on python-pycryptodome, which supports only x86_64 architectures. Should they get an arch=('x86_64')?

Lone_Wolf · 2019-03-31 12:48:37

The documentation on pycryptodome website doesn't appear to mention x86_64 (or any specific architecture).
Maybe the arch package listing x86_64 instead of any as architecture is a mistake ?

Why are you downloading httpsig sourcecode from a 3rd party location and not from github ?

loqs · 2019-03-31 13:53:26

python-cryptodome builds dynamic libraries

python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Cipher/_ARC4.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Cipher/_Salsa20.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Cipher/_chacha20.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Cipher/_raw_aes.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Cipher/_raw_aesni.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Cipher/_raw_arc2.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Cipher/_raw_blowfish.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Cipher/_raw_cast.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Cipher/_raw_cbc.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Cipher/_raw_cfb.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Cipher/_raw_ctr.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Cipher/_raw_des.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Cipher/_raw_des3.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Cipher/_raw_ecb.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Cipher/_raw_ocb.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Cipher/_raw_ofb.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Hash/_BLAKE2b.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Hash/_BLAKE2s.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Hash/_MD2.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Hash/_MD4.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Hash/_MD5.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Hash/_RIPEMD160.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Hash/_SHA1.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Hash/_SHA224.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Hash/_SHA256.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Hash/_SHA384.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Hash/_SHA512.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Hash/_ghash_clmul.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Hash/_ghash_portable.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Hash/_keccak.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Hash/_poly1305.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Math/_montgomery.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Protocol/_scrypt.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/SelfTest/Cipher/test_vectors/wycheproof/aes_eax_test.json
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/SelfTest/Cipher/test_vectors/wycheproof/aes_gcm_test.json
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/SelfTest/Cipher/test_vectors/wycheproof/aes_siv_cmac_test.json
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/SelfTest/Cipher/test_vectors/wycheproof/chacha20_poly1305_test.json
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/SelfTest/Hash/test_vectors/wycheproof/aes_cmac_test.json
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/SelfTest/Signature/test_vectors/wycheproof/dsa_test.json
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/SelfTest/Signature/test_vectors/wycheproof/ecdsa_secp256r1_sha256_test.json
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/SelfTest/Signature/test_vectors/wycheproof/ecdsa_test.json
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/SelfTest/Signature/test_vectors/wycheproof/rsa_signature_test.json
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Util/_cpuid_c.cpython-37m-x86_64-linux-gnu.so
python-pycryptodome usr/lib/python3.7/site-packages/Crypto/Util/_strxor.cpython-37m-x86_64-linux-gnu.so

The python interface provide by python-pycryptodome is arch independant.

  ( set -o pipefail
    git describe --long 2>/dev/null | sed 's/\([^-]*-g\)/r\1/;s/-/./g' ||
    printf "%sr%s.%s" "$_version" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"

I would avoid using this and instead update the PKGBUILD if upstream introduces tags.

denisal · 2019-04-01 08:43:14

Thanks for the reviews!

Lone_Wolf wrote:

Why are you downloading httpsig sourcecode from a 3rd party location and not from github ?

I just grabbed the template from the arch wiki Python package guidelines for PyPI packages. But I guess since the PyPI package will be updated using the github release, github is the actual source? Will change that.

loqs wrote:

  ( set -o pipefail
    git describe --long 2>/dev/null | sed 's/$[^-]*-g$/r\1/;s/-/./g' ||
    printf "%sr%s.%s" "$_version" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
I would avoid using this and instead update the PKGBUILD if upstream introduces tags.

Got that from the arch wiki guidelines for git packages. But sure, its more readable without it.

Ok, so python-cryptodome is correctly listed as x86_64? On second thought, I would maybe not tag a package as arch specific just because it depends on an arch specific package. Considering that the dependency (in this case python-cryptodome) might become arch independent at some point, me as package maintainer would have to watch all dependencies for changes in arch dependency to correctly update. Doesn't sound like that makes sense. So I would keep both packages with arch independent tag and leave the arch dependency to the dependent packages?

Last edited by denisal (2019-04-01 08:44:59)

Lone_Wolf · 2019-04-01 10:01:30

I just grabbed the template from the arch wiki Python package guidelines for PyPI packages. But I guess since the PyPI package will be updated using the github release, github is the actual source? Will change that.

I checked the python guidelines and they do give the impression only pypi / pythonhosted sources are used.
When there are mutiple choices for something (download locations in this case) upstream choices are preferred.
for this package that is github.

so I would keep both packages with arch independent tag and leave the arch dependency to the dependent packages?

Yes.
archlinuxarm & archlinux32 have their own architecture specific pycryptodome pacakges, by keeping yours "any" users from those distros can use your aur packages also.

Last edited by Lone_Wolf (2019-04-01 10:01:56)

loqs · 2019-04-01 11:10:28

denisal wrote:

loqs wrote:
  ( set -o pipefail
    git describe --long 2>/dev/null | sed 's/$[^-]*-g$/r\1/;s/-/./g' ||
    printf "%sr%s.%s" "$_version" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
I would avoid using this and instead update the PKGBUILD if upstream introduces tags.
Got that from the arch wiki guidelines for git packages. But sure, its more readable without it.

_version=0.1.0

Does upstream consider the untagged version to be 0.1.0? Do you intend to increment this variable manually?

denisal · 2019-04-02 15:31:07

loqs wrote:

_version=0.1.0
Does upstream consider the untagged version to be 0.1.0? Do you intend to increment this variable manually?

That version is passed in upstreams setup.py. No releases or tags are used. But its read from a setup.json file. I could just parse that info from there actually. Something like

_version=$(grep version setup.json | awk -F'[""]' '{print $4}')

gives 0.1.0 from the

    "version": "0.1.0",

line in the json file (probably there is a single grep/awk command that does it without piping).

Great, thanks.

EDIT: awk command without grep and piping:

_version=$(awk -F'"' '/"version"/ {print $4}' setup.json)

Last edited by denisal (2019-04-03 10:22:58)

denisal · 2019-04-03 10:30:17

I submitted the packages, thanks for you help again. Marking as solved.

python-httpsig
dpt-rp1-py-git

EDIT:
Woops, I was to quick here. looks like I didn't properly rebuild the package when testing. When using the github release tarball as source, I get the following error when building:

==> Making package: python-httpsig 1.3.0-2 (Wed 03 Apr 2019 01:02:09 PM CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found httpsig-1.3.0.tar.gz
==> Validating source files with md5sums...
    httpsig-1.3.0.tar.gz ... Passed
==> Extracting sources...
  -> Extracting httpsig-1.3.0.tar.gz with bsdtar
==> Removing existing $pkgdir/ directory...
==> Starting build()...
Traceback (most recent call last):
  File "setup.py", line 40, in <module>
    test_suite="httpsig.tests",
  File "/usr/lib/python3.7/site-packages/setuptools/__init__.py", line 145, in setup
    return distutils.core.setup(**attrs)
  File "/usr/lib/python3.7/distutils/core.py", line 108, in setup
    _setup_distribution = dist = klass(attrs)
  File "/usr/lib/python3.7/site-packages/setuptools/dist.py", line 447, in __init__
    k: v for k, v in attrs.items()
  File "/usr/lib/python3.7/distutils/dist.py", line 292, in __init__
    self.finalize_options()
  File "/usr/lib/python3.7/site-packages/setuptools/dist.py", line 739, in finalize_options
    ep.load()(self, ep.name, value)
  File "/home/denis/source/aur/python-httpsig/src/httpsig-1.3.0/.eggs/setuptools_scm-3.2.0-py3.7.egg/setuptools_scm/integration.py", line 23, in version_keyword
    dist.metadata.version = get_version(**value)
  File "/home/denis/source/aur/python-httpsig/src/httpsig-1.3.0/.eggs/setuptools_scm-3.2.0-py3.7.egg/setuptools_scm/__init__.py", line 144, in get_version
    parsed_version = _do_parse(config)
  File "/home/denis/source/aur/python-httpsig/src/httpsig-1.3.0/.eggs/setuptools_scm-3.2.0-py3.7.egg/setuptools_scm/__init__.py", line 111, in _do_parse
    "use git+https://github.com/user/proj.git#egg=proj" % config.absolute_root
LookupError: setuptools-scm was unable to detect version for '/home/denis/source/aur/python-httpsig/src/httpsig-1.3.0'.

Make sure you're either building from a fully intact git repository or PyPI tarballs. Most other sources (such as GitHub's tarballs, a git checkout without the .git folder) don't contain the necessary metadata and will not work.

For example, if you're using pip, instead of https://github.com/user/proj/archive/master.zip use git+https://github.com/user/proj.git#egg=proj
==> ERROR: A failure occurred in build().
    Aborting...

So python setup.py build does not work with github tarballs? Alternatively I could just clone the corresponding release tag using:

makedepends=('git' 'python-setuptools')
source=("${_name}-${pkgver}::git+https://github.com/ahknight/httpsig#tag=v$pkgver")
md5sums=('SKIP')

But this means I can't verify the md5sums since the .git folder is changing? Is there another solution? If not, it seems almost preferable to use the PyPI source with given sha256sums (as in my initial post)?

Last edited by denisal (2019-04-03 11:18:17)

Lone_Wolf · 2019-04-03 11:45:34

from setup.py in the tarball

    use_scm_version=True,
    setup_requires=['setuptools_scm'],

No idea why, but that appears to make github tarballs impossible to build from

Assuming this is not an error but intentional , you have 2 options :
- use the pypi tarball
- use git to retrieve a specific commit (see man PKGBUILD)
the commit Merge branch 'release/1.3.0' looks like a good choice for that.

Last edited by Lone_Wolf (2019-04-03 11:46:00)

Arch Linux

#1 2019-03-31 01:59:14

PKGBUILD review request

#2 2019-03-31 12:48:37

Re: PKGBUILD review request

#3 2019-03-31 13:53:26

Re: PKGBUILD review request

#4 2019-04-01 08:43:14

Re: PKGBUILD review request

#5 2019-04-01 10:01:30

Re: PKGBUILD review request

#6 2019-04-01 11:10:28

Re: PKGBUILD review request

#7 2019-04-02 15:31:07

Re: PKGBUILD review request

#8 2019-04-03 10:30:17

Re: PKGBUILD review request

#9 2019-04-03 11:45:34

Re: PKGBUILD review request

Board footer