You are not logged in.
Pages: 1
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')?
Offline
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 ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
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.
Offline
Thanks for the reviews!
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.
( 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)
Offline
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)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
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?
Offline
_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)
Offline
I submitted the packages, thanks for you help again. Marking as solved.
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)
Offline
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)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
Pages: 1