Re: [aur-general] [review-request] moolticute
On 17-01-28 21:08:09, Eli Schwartz via aur-general wrote: > On 01/28/2017 07:55 PM, Quentin Bourgeois wrote: > > As the daemon is expected to talk with an USB device I included an > > udev rules that should match it and allow logged user interaction. > > In addition, the project does not include any systemd service > > file. The daemon is expected to run for every user session so I use > > systemd user instance. This service file is now very basic I will > > first try to make it upstream, so every distribution could benefit > > from this eventually. I guess that a lot are using systemd now. > > Yes, please do that. If upstream won't do so however, it is okay to > bundle a service file with the PKGBUILD. > > Upstream should also, ideally, install a udev rule themselves. For some > reason, their README explicitly tells Ubuntu and Arch users to create > *different* udev rules by hand, using `echo ... | sudo tee`. Which is > weird for several reasons. > Hi, sorry for the delay, I worked with upstream and both the systemd service file and the udev rules will be provided in the next release of the software. I also merge udev for Arch and Ubuntu as the rule should work on every systemd based node. > > While creating the systemd file I was wonderering how would be the > > guideline in a case that an upstream systemd service file won't match > > (for any reason) Arch Linux policy (let say applying it will break > > the package functionality in Arch) would the good way to fix it in the > > first would be to create in the PKGBUILD a systemd drop-ins? Maybe a better way to turn my question would be: What if, an Arch packager would like to improve in some way a systemd service provided by upstream (for example by using one of the different isolation mechanisms provided by systemd), but that improvement is rejected by upstream for reason not application to Arch Linux. But it could not make sense. > I'm not sure what you even mean by this. How would a systemd unit break > its own functionality, and if so, why wouldn't that be a cause for > concern upstream? > What Arch Linux policy would it violate anyway? > > > Regarding udev, after installing my rule I decided to force reloading > > the rules files but not replaying event (only print a message to warn > > the user). My view is that the later would only be needed for people > > that already plugged the device before installing the package. > > Take a look at the (many) packages that own a file in > /usr/lib/udev/rules.d/ and try to see how many of them include an > install script explicitly reloading the rules. (Hint: None of them.) > There is a reason for this, udev is already pretty smart. > > As for the message, surely that is rather obvious already? install > scripts are meant for situations where simply installing the package > isn't enough to actually make things work, or *vitally critical > information is likely to elude the user* unless you bug them about it in > a post-install message. > > Telling the user that an intuitive aspect of hardware device control > applies here too, smells like over-mothering handholding to me. > Get it, I removed this part. On 17-01-29 11:06:05, NicoHood wrote: > On 01/29/2017 01:55 AM, Quentin Bourgeois wrote: > > Hi, > > > > I'm looking for uploading moolticute[0] into AUR but I still have some > > doubt that my package has good taste or not. The project is in C++ and > > use qt-5. > > Hi, > I also wanted to package moolticute for AUR but it was not ready at that > time. I had not tried to package it again but still have it on my TODO > list. It would be nice if you could contact me via tox/irc so we could > possibly work together on this. > > When moolticute gets popular enough I plan to move it to the official > repository. We also have a good chance that upstream accepts our > patches, as I've already worked with them and it shouldnt be that hard > to apply some systemd patches for example. > > So contact me in privat if you like to work together. I can also test > with real hardware (Normal one and Mini Beta hardware). > > Cheers, > Nico > Hi Nico, I will ping you on IRC for that. I will also package the client and ssh-agent for AUR in the next week, so I will probably asking new advice on Go package at that time. signature.asc Description: PGP signature
Re: [aur-general] [review-request] moolticute
Hi, Still about the moolticute packaging I am in a situation where different tools (that will leave in different Arch package) will needs access to the device. For that, I am considering moving the udev rules in other package[0] and make every tools depend on the former[1]. I only see android-udev that perform the same thing, am I doing this right ? Thanks! [0] https://git.bourgeois.eu/aur_mooltipass_udev.git/tree/PKGBUILD [1] https://git.bourgeois.eu/aur_moolticute.git/tree/PKGBUILD#n12 signature.asc Description: PGP signature
[aur-general] [review-request] python-intelhex
Hi,
I am currently looking for building python2-intelhex[0] from
AUR. Unfortunately the build failed, while I am using aursync[1] and
require build into a clean (created for this build) chroot:
$ aursync -c python2-intelhex
[...]
==> Starting package_python-intelhex()...
/startdir/PKGBUILD: line 17: python: command not found
==> ERROR: A failure occurred in package_python-intelhex().
Aborting...
==> ERROR: Build failed, check /var/lib/aurbuild/x86_64/user/build
Note that with the python3 package version I come up with the same
bug.
Thus, I decide to have a look at the PKGBUILD and suggest some
modifications I guess the maintainer will be glad to merge any
proposal, but did the community see any thing more to change ?
Basically I made use a lot more of its internal variable __pkgname,
define python{,2}-setuptools as makedepends and add the license file
to the package.
In another way I don't really understand the rm on the bin directory?
The problem I saw is that only installing python2-intelhex wont allow
the use of the provided scripts[2]. However, I conducted small
tests and they seems to works even with python2. So my guess is to
create an other AUR PKGBUILD that will perform pretty the same things
but only packaging the provided scripts, let call this package
python-intelhex-scripts. Then, one need to enforce a dependencies of
python{,2}-intelhex with python-intelhex-script at the same upstream
release version.
I propose some modification in the python-intelhex[3] PKGBUILD and a
new PKGBUILD for python-intelhex-scripts[4].
What do you think ?
Thanks in advance for your feedback!
[0] https://aur.archlinux.org/packages/python2-intelhex/
[1] https://github.com/AladW/aurutils
[2] https://github.com/bialix/intelhex/tree/master/scripts
[3]
https://git.bourgeois.eu/aur_python_intelhex.git/tree/PKGBUILD?id=e6187787c3743e63c5830f78dd18d58f5bc40f79
[4]
https://git.bourgeois.eu/aur_python_intelhex_scripts.git/tree/PKGBUILD?id=b346e34509a53cd0ed094f686f635d7e3873a372
# Maintainer: Quentin Bourgeois <quentin+archli...@bourgeois.eu>
__reponame='intelhex'
__pkgname="${__reponame}-scripts"
__license_filename='LICENSE.txt'
pkgname=("python-${__pkgname}")
pkgver=2.1
pkgrel=1
pkgdesc='Python IntelHex scripts'
url="https://github.com/bialix/${__reponame};
optdepends=()
license=('BSD')
arch=('any')
source=("${__pkgname}-${pkgver}.tar.gz::${url}/archive/${pkgver}.tar.gz")
sha512sums=('af5ee3cb7424d15cf259861dcedf6ca68ecfae0819cb9f5c3437a1c8ff8c2f03486dd9f12b93564a5e2f4b7bab4c055a44c6dbe2a86007165412336bd2a4554f')
makedepends=('python-setuptools'
'python2-setuptools')
check() {
cd "${srcdir}/${__reponame}-${pkgver}"
msg "Running tests"
python setup.py test -q
}
package_python-intelhex-scripts() {
depends=('python' 'python-setuptools')
cd "${srcdir}/${__reponame}-${pkgver}"
python setup.py install --root="${pkgdir}" --optimize=1
install -Dm644 "$__license_filename"
"${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
rm -rf "${pkgdir}/usr/lib/"
rm -rf "${pkgdir}/usr/share/"
}
signature.asc
Description: PGP signature
Re: [aur-general] [review-request] python-intelhex
On 17-01-23 22:53:35, Eli Schwartz via aur-general wrote:
> On 01/23/2017 08:42 PM, Quentin Bourgeois wrote:
> > Thus, I decide to have a look at the PKGBUILD and suggest some
> > modifications I guess the maintainer will be glad to merge any
> > proposal, but did the community see any thing more to change ?
> > Basically I made use a lot more of its internal variable __pkgname,
> > define python{,2}-setuptools as makedepends and add the license file
> > to the package.
>
> Right, so comment on the AUR that the dependencies are not installed.
> This is a simple, *standard* fix, and as Justin said, asking for
> feedback here is a bit... odd. Asking for guidance writing your own
> PKGBUILDs is one thing (and serves, most of all, to help users learn how
> to do it properly themeselves), asking us to pick apart selected AUR
> packages that you happen to use is another thing entirely.
>
> Also, nitpicking over the *extent* of others' use of templating
> variables like _pkgname is classless, moreso when your own (over)use of
> __license_filename is a wasteful overreaction.
In fact I was included my previously mail to the mailing as part as my
learning experience. My thought was to I don't forget anything I was
not relying on the community to make my proposal applied.
(Note that using external git was not to takeover or whatsoever the
package but just a way to sharing my ideas).
Anyway, thanks Eli for opening a new request on the project page.
>
> > In another way I don't really understand the rm on the bin directory?
> > The problem I saw is that only installing python2-intelhex wont allow
> > the use of the provided scripts[2]. However, I conducted small
> > tests and they seems to works even with python2. So my guess is to
> > create an other AUR PKGBUILD that will perform pretty the same things
> > but only packaging the provided scripts, let call this package
> > python-intelhex-scripts. Then, one need to enforce a dependencies of
> > python{,2}-intelhex with python-intelhex-script at the same upstream
> > release version.
>
> Absolutely not, this package is doing it the standard and recommended
> way. And splitting the scripts would not achieve your goal anyway, since
> the version of python is hardcoded in the shebang -- hence why you
> yourself explicitly depended on "python", which is not provided by
> "python2" under any circumstances!
>
> But if you were to split them out, they should've been a third split
> package in the same PKGBUILD.
>
Duly noted, I keep this technique for posterity.
> --
> Eli Schwartz
>
signature.asc
Description: PGP signature
[aur-general] [review-request] moolticute
Hi,
I'm looking for uploading moolticute[0] into AUR but I still have some
doubt that my package has good taste or not. The project is in C++ and
use qt-5.
I would like to upload a classical PKGBUILD[1] (with tag release) then
one that follow the git master branch[2].
As the daemon is expected to talk with an USB device I included an
udev rules that should match it and allow logged user interaction.
In addition, the project does not include any systemd service
file. The daemon is expected to run for every user session so I use
systemd user instance. This service file is now very basic I will
first try to make it upstream, so every distribution could benefit
from this eventually. I guess that a lot are using systemd now.
While creating the systemd file I was wonderering how would be the
guideline in a case that an upstream systemd service file won't match
(for any reason) Arch Linux policy (let say applying it will break
the package functionality in Arch) would the good way to fix it in the
first would be to create in the PKGBUILD a systemd drop-ins?
Regarding udev, after installing my rule I decided to force reloading
the rules files but not replaying event (only print a message to warn
the user). My view is that the later would only be needed for people
that already plugged the device before installing the package.
Even with the i686 phase out, the tools seems to work great with this
architecture, so I included it too.
Finally, the release name[3] currently include "beta" (like v0.5.2-beta)
does I have to put this into the pkgver or leave as 0.5.2?
If comments/directions I will be glad to improve my work.
Thanks !
[0] https://github.com/raoulh/moolticute
[1]
https://git.bourgeois.eu/aur_moolticute.git/tree/PKGBUILD?id=85e4d6f29352a54d85c00f3dfd2c5f1fef052811
[2]
https://git.bourgeois.eu/aur_moolticute_git.git/tree/PKGBUILD?id=140f3e3efceacf5ca24d2a77c04458a80d998c8a
[3] https://github.com/raoulh/moolticute/releases
# Maintainer: Quentin Bourgeois <quentin+archli...@bourgeois.eu>
pkgname=moolticute
pkgver=0.5.2
pkgrel=1
pkgdesc="Easy companion for Mooltipass device"
arch=('x86_64' 'i686')
url="https://github.com/raoulh/${pkgname};
license=('GPL3')
depends=('libusb'
'qt5-base'
'qt5-websockets')
makedepends=('make')
checkdepends=()
optdepends=()
install="${pkgname}.install"
source=("${pkgname}-${pkgver}.tar.gz::${url}/archive/v${pkgver}-beta.tar.gz"
'69-mooltipass.rules'
'moolticute.service')
sha256sums=('a22d4078870da77affb67c7eae2d2cc426ec799a0928f494df32ab995431fe8a'
'e8e8da3f29d27e34a9f41b23ba04b74dbf25bcc7d586e5b6d2ee72bade889503'
'135d7dda3698872745bec79fa2ee7a964fa2fbc90f90d1d57e034bc0104ce13a')
build() {
cd "${pkgname}-${pkgver}-beta"
mkdir build
cd build/
qmake-qt5 ../Moolticute.pro \
PREFIX=/usr \
QMAKE_CFLAGS_RELEASE="${CFLAGS}" \
QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}"
make
}
package() {
cd "${pkgname}-${pkgver}-beta/build/"
make INSTALL_ROOT="${pkgdir}/" install
install -Dm644 "${srcdir}/69-mooltipass.rules" \
"${pkgdir}/usr/lib/udev/rules.d/69-mooltipass.rules"
install -Dm644 "${srcdir}/moolticute.service" \
"${pkgdir}/usr/lib/systemd/user/moolticute.service"
}
# Maintainer: Quentin Bourgeois <quentin+archli...@bourgeois.eu>
pkgname=moolticute-git
_pkgname="${pkgname%-git}"
pkgver=0.5.2.r0.g9486816
pkgrel=1
pkgdesc="Easy companion for Mooltipass device"
arch=('x86_64' 'i686')
url="https://github.com/raoulh/${_pkgname};
license=('GPL3')
provides=("${_pkgname}")
conflicts=("${_pkgname}")
depends=('libusb'
'qt5-base'
'qt5-websockets')
makedepends=('git'
'make')
checkdepends=()
optdepends=()
install="${_pkgname}.install"
source=("git+${url}.git"
'69-mooltipass.rules'
'moolticute.service')
sha256sums=('SKIP'
'e8e8da3f29d27e34a9f41b23ba04b74dbf25bcc7d586e5b6d2ee72bade889503'
'135d7dda3698872745bec79fa2ee7a964fa2fbc90f90d1d57e034bc0104ce13a')
pkgver() {
cd "${srcdir}/${_pkgname}"
git describe --long --tags | sed
's/beta.//;s/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'
}
build() {
cd "${srcdir}/${_pkgname}"
mkdir build
cd build/
qmake-qt5 ../Moolticute.pro \
PREFIX=/usr \
QMAKE_CFLAGS_RELEASE="${CFLAGS}" \
QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}"
make
}
package() {
cd "${srcdir}/${_pkgname}/build/"
make INSTALL_ROOT="$
[aur-general] [REVIEW REQUEST] python-viivakoodi
Hi,
I'm looking forward to have the python library viivakoodi[0] as an
Arch Linux packages. If I am not miss-lead this library does not exist
in the Arch Linux repositories nor in AUR.
Use-case
I'm building this package to be able to use scripts provided into the
mooltipass framework[1].
I personally hate the pip thing so I would appreciate to have it
directly as an Arch Linux packages.
Description
---
I comes with a PKGBUILD that could be found attached to this email or
directly to my personal git repository[2].
As this is my first PKGBUILD (and contribution) I would appreciate any
criticisms on this.
I came up with the following points by my own:
* I'm not sure that the way I install the LICENSE file in the
package_*() functions is the way it should be done.
* As it is stated into the project README[3] argparse is required
for python 2.6, 3.0 and 3.1. What is the good way to do this into
a PKGBUILD ? I opt to force argparse as dependencies so I am sure
that it should runs for everyone.
* I have decided to introduce my custom variable _pylibname, I hope it
would be okay.
* Upstream does not provide any GPG signature of the tarballs nor
commit signature. I've chosen to provide a detached GPG signature
of the downloaded tarball with my GPG key. For me, its better to
have this link-ability between the package maintainer and the
downloaded tarball than nothing at all.
Do you have comments or anything ?
Thanks for helping me and reviewing.
Q.
[0] https://github.com/kxepal/viivakoodi
[1] https://github.com/limpkin/mooltipass/tree/master/tools/_python_framework
[2] https://git.bourgeois.eu/aur_python_viivakoodi.git/tree/
[3] https://github.com/kxepal/viivakoodi/blob/master/README.rst
# Maintainer: Quentin Bourgeois <quentin+archli...@bourgeois.eu>
#
# TODO: * viivakoodi require (python) argparse if python interpreter is 2.6,
# 3.0 or 3.1 => how to do that ?
_pylibname=viivakoodi
pkgname=("python2-$_pylibname" "python-$_pylibname")
pkgver=0.8.0
pkgrel=1
pkgdesc='Barcode generator for Python. Fork of pyBarcode project.'
arch=('x86_64')
url="https://github.com/kxepal/$_pylibname;
license=('MIT')
groups=()
depends=()
makedepends=()
optdepends=('inkscape: tools for manipulating vector objects (eg: SVG files)')
checkdepends=('python-tox' 'python-pylint' 'python2-tox' 'python2-pylint')
provides=()
conflicts=()
replaces=()
backup=()
options=()
install=
changelog=
source=("$_pylibname-$pkgver.tar.gz::https://github.com/kxepal/$_pylibname/archive/$pkgver.tar.gz;
"$_pylibname-$pkgver.tar.gz.sig::https://pki.bourgeois.eu/archlinux/aur/$_pylibname-$pkgver.tar.gz.sig;)
noextract=()
md5sums=()
sha1sums=()
sha256sums=('e1a17dc24975d5242202cfbb7534d69dd14eeb26bdf8a10f056c7b04904fef1e'
'c161bd90708ca20c841321139f7e8fe5ae53cb25f55d0327fea5b59ac401f8e9')
sha384sums=('e2da627423221298dfc55be93ab07e42d8801f0fa63bcfc5ad6bfa689181bcd0e7eb9525abdfd20aa3637ae5656b'
'b92e09d3e801b55ec97e28b105d8033d6bace8fc869343331e1093bbb35aabe201432e43ea4487014c92b190a65c89f8')
sha512sums=('b9f5fc859b3ec33a1cf264d5ede597ff79cd447043668cf433096bf0bf89e24e1a8bf05f7914420934bc6c03a66ec0df99a203136c3f6506e0fda8e3c6f619fd'
'68b6df665e76555489b9abc616fda11180c1c420e8a5dd74c191543335ee0b887fbba8115f7823aed676242b559af10141fc6a40c4b068a39b9e1038917dc29e')
# quentin bourgeois GPG key no package dev but provide a signature of the
archive used when creating PKGBUILD file
validpgpkeys=('A5A90A2DE9D979C1BD0085CB8663D1331DD47615')
check() {
cd "$srcdir/$_pylibname-$pkgver"
for py_int in python3 python2; do
msg "Testing $_pylibname-$pkgver with $py_int"
"$py_int" ./test.py
done
}
package_python-viivakoodi() {
# as python-3.0 and python-3.1 need argparse I force for every version
depends+=('python' 'python-argparse')
makedepends+=('python-setuptools')
provides+=('python2-viivakoodi')
optdepends+=('python-pillow')
cd "$srcdir/$_pylibname-$pkgver"
python setup.py install --root="$pkgdir/" --optimize=1
if [ -f LICENSE ]; then
install -Dm0644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
install -Dm0644 LICENSE
"$pkgdir/usr/share/licenses/$pkgname/LICENSE.launcher"
else
warning "license file not found"
fi
}
package_python2-viivakoodi() {
# as python2.6 need argparse I force for every version
depends+=('python2>=2.6' 'python2-argparse')
makedepends+=('python2-setuptools')
provides+=('python2-viivakoodi')
optdepends+=('python2-pillow')
cd "$srcdir/$_pylibname-$pkgver"
python2 setup.py install --root="$pkgdir/" --optimize=1
if [ -f LICENSE ]; then
install -Dm0644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
install -
Re: [aur-general] [REVIEW REQUEST] python-viivakoodi
On 16-11-26 19:27:37, Eli Schwartz via aur-general wrote:
> On 11/26/2016 01:01 AM, Florian Bruhin wrote:
> >> * Upstream does not provide any GPG signature of the tarballs nor
> >> commit signature. I've chosen to provide a detached GPG signature
> >> of the downloaded tarball with my GPG key. For me, its better to
> >> have this link-ability between the package maintainer and the
> >> downloaded tarball than nothing at all.
> >
> > Not sure if that makes much sense, and FWIW I've had some issues with
> > people not being able to install AUR packages with PGP keys. I don't
> > recall exactly what the problem was though...
>
> This. GPG signatures are meant to prove that upstream really released
> it, but if all you know is that the AUR maintainer *thinks* this is the
> upstream release, you might as well just stick with checksums, which
> will serve just as well to prove the source code is the same source code
> the AUR maintainer used.
>
> Anyone who can defeat the checksum (by modifying your PKGBUILD) can also
> defeat your own GPG key.
>
You are right I have remove this, my first goals was to sign my
PKGBUILD file I don't think its possible ?
On 16-11-26 07:01:15, Florian Bruhin wrote:
> > optdepends=('inkscape: tools for manipulating vector objects (eg: SVG
> > files)')
>
> You'd usually put an explanation when/why inkscape is needed here.
>
Inkscape (or any other tool for SVG handling) is needed if one would
like to see the result of generated document in SVG format. As there
could be a long list I am not sure if such dependencies should be put
into PKGBUILD, even in optdepends ?
> > if [ -f LICENSE ]; then
> > install -Dm0644 LICENSE
> > "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
> > install -Dm0644 LICENSE
> > "$pkgdir/usr/share/licenses/$pkgname/LICENSE.launcher"
> > else
> > warning "license file not found"
> > fi
>
> Why would it ever not exist?
I add this check in case upstream change for any reason and not break
the build process. The warning should be enough to let me investigate.
I generally don't perform operation on resource that could not be
present, I just applied this here too.
Thanks for your feedback, I have updated the PKGBUILD[0].
[0] https://git.bourgeois.eu/aur_python_viivakoodi.git/tree/
signature.asc
Description: PGP signature
Re: [aur-general] [REVIEW REQUEST] python-viivakoodi
On 16-11-27 11:10:51, Eli Schwartz via aur-general wrote:
> On 11/27/2016 10:30 AM, Quentin Bourgeois wrote:
> > You are right I have remove this, my first goals was to sign my
> > PKGBUILD file I don't think its possible ?
>
> No, although the AUR is HTTPS.
>
> If people clone the package instead of downloading the snapshot (several
> AUR helpers can be configured to do that), and if they obtain your
> public key, they can use git to verify signed commits. Assuming they
> know you sign your commits.
> But no AUR helper tries to check that... and how would you know which
> key to trust?
>
> > Inkscape (or any other tool for SVG handling) is needed if one would
> > like to see the result of generated document in SVG format. As there
> > could be a long list I am not sure if such dependencies should be put
> > into PKGBUILD, even in optdepends ?
>
> Looking at the project README, it just generates an SVG file (and says
> you will need a program that opens SVG, like most browsers). It doesn't
> fundamentally integrate with Inkscape, and you should not add as a
> dependency every single program capable of opening a specific filetype.
> In fact, you shouldn't even add one such program. ;)
>
> When it describes "Program to open SVG objects" as a requirement, they
> probably shouldn't have listed that in the code requirements, since it
> is only a *logical* requirement...
>
> > I add this check in case upstream change for any reason and not break
> > the build process. The warning should be enough to let me investigate.
> > I generally don't perform operation on resource that could not be
> > present, I just applied this here too.
>
> You should catch that when you make the package yourself before pushing
> an update to the AUR, since the install command would fail with an error
> and makepkg would abort with an error. At least, I assume you consume
> your own packages...
>
> As a general rule, do not clutter up the PKGBUILD with things that can
> change from version to version unless it is a VCS package and the same
> PKGBUILD applies from version to version as new commits are pulled from
> the VCS source.
> Also, don't make checks like that for things which are really quite
> unlikely to change. Why do you think they might do that???
With this, I come with a simpler PKGBUILD[0] in which I push
modifications you advised. I also removed some dependencies that are
used for code coverage and building documentation, which I do not
install for now.
Did we get to something good ?
[0] https://git.bourgeois.eu/aur_python_viivakoodi.git/tree/
# Maintainer: Quentin Bourgeois <quentin+archli...@bourgeois.eu>
pkgbase=viivakoodi
pkgname=("python2-$pkgbase" "python-$pkgbase")
pkgver=0.8.0
pkgrel=1
pkgdesc='Barcode generator for Python. Fork of pyBarcode project.'
arch=('any')
url="https://github.com/kxepal/$pkgbase;
license=('MIT')
makedepends+=('python-setuptools'
'python2-setuptools')
source=("$pkgbase-$pkgver.tar.gz::https://github.com/kxepal/$pkgbase/archive/$pkgver.tar.gz;)
sha256sums=('e1a17dc24975d5242202cfbb7534d69dd14eeb26bdf8a10f056c7b04904fef1e')
check() {
cd "$srcdir/$pkgbase-$pkgver"
for py_int in python3 python2; do
msg "Testing $pkgbase-$pkgver with $py_int"
"$py_int" ./test.py
done
}
package_python-viivakoodi() {
depends+=('python')
provides+=('python2-viivakoodi')
optdepends+=('python-pillow: render barcodes as images')
checkdepends+=('python-pytest'
'python-mock'
'python-tox')
cd "$srcdir/$pkgbase-$pkgver"
python setup.py install --root="$pkgdir/" --optimize=1
install -Dm0644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
install -Dm0644 LICENSE
"$pkgdir/usr/share/licenses/$pkgname/LICENSE.launcher"
}
package_python2-viivakoodi() {
depends+=('python2')
provides+=('python2-viivakoodi')
optdepends+=('python2-pillow: render barcodes as images')
checkdepends+=('python2-pytest'
'python2-mock'
'python2-tox')
cd "$srcdir/$pkgbase-$pkgver"
python2 setup.py install --root="$pkgdir/" --optimize=1
install -Dm0644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
install -Dm0644 LICENSE
"$pkgdir/usr/share/licenses/$pkgname/LICENSE.launcher"
}
signature.asc
Description: PGP signature
Re: [aur-general] [REVIEW REQUEST] python-viivakoodi
On 16-11-27 19:41:06, Eli Schwartz via aur-general wrote:
> On 11/27/2016 06:10 PM, Quentin Bourgeois wrote:
> > With this, I come with a simpler PKGBUILD[0] in which I push
> > modifications you advised. I also removed some dependencies that are
> > used for code coverage and building documentation, which I do not
> > install for now.
> >
> > Did we get to something good ?
> >
> > [0] https://git.bourgeois.eu/aur_python_viivakoodi.git/tree/
>
I should comes with all modification on this batch.
> Err, why do both split packages provide 'python2-viivakoodi'? One of
> them already is 'python2-viivakoodi', and the other by definition
> doesn't supply it, being Python 3.
My mistake.
> You declare setuptools as a makedepends only, but I hate to inform you
> that setuptools-installed packages have a runtime dependency on
> setuptools to launch their console scripts. (This is the downside of
> having python itself be capable of generating the entry point launchers
> in a cross-platform manner -- rather than using your own python scripts
> with file extensions, then assuming Linux users will be happy with the
> extension and Windows users will be able to launch a non-binary.)
>
> For module-only python packages, it is only a makedepends... for
> packages which ship with console_scripts you need it at runtime as well,
> otherwise the console_scripts will fail trying to import pkg_resources.
>
> You can either have each split package depend on python{,2}-setuptools,
> or depend on both that and the python{,2} package itself. I have seen it
> done both ways.
Hum, this was not abvious for me, thanks. With what I have understand
from that I have decide to make every split package depend on pythonX
and pythonX-setuptools its seem simpler for me to understand.
I will dig this setuptools + console_script topics by my own.
On this, when I run namcap on created packages I get some warnings:
$ namcap *.tar.xz
python2-viivakoodi W: Dependency python2 included but already satisfied
python2-viivakoodi W: Dependency included and not needed ('python2-setuptools')
python-viivakoodi W: Dependency python included but already satisfied
python-viivakoodi W: Dependency included and not needed ('python-setuptools')
For every packages the first warning is due to my choice. For the
second does namcap could warn packager that are not aware of the
setuptools+console_scripts things (or maybe its something well known
?).
>
> ...
>
> There are still some optional style preferences, like leaving a line of
> whitespace after the "# Maintainer:" line and reusing the "$url"
> variable in the source array. Feel free to take that or leave it, though. :)
> Also, I don't usually see people initializing an array with += but it
> isn't like that is harmful.
> Also, the permissions mode in chmod/install assumes leading zeroes, so
> you don't need to explicitly say those licenses are lacking in
> suid/sticky attributes.
Integrated, the += intialization was due to the empty variables
remove.
On style preferences, when I code in Bash I over use {} arround
variables (mainly when variables are tied to other strings). What is
the guideline on this ?
>
> --
> Eli Schwartz
# Maintainer: Quentin Bourgeois <quentin+archli...@bourgeois.eu>
pkgbase=viivakoodi
pkgname=("python2-$pkgbase" "python-$pkgbase")
pkgver=0.8.0
pkgrel=1
pkgdesc='Barcode generator for Python. Fork of pyBarcode project.'
arch=('any')
url="https://github.com/kxepal/$pkgbase;
license=('MIT')
source=("$pkgbase-$pkgver.tar.gz::$url/archive/$pkgver.tar.gz")
sha256sums=('e1a17dc24975d5242202cfbb7534d69dd14eeb26bdf8a10f056c7b04904fef1e')
check() {
cd "$srcdir/$pkgbase-$pkgver"
for py_int in python3 python2; do
msg "Testing $pkgbase-$pkgver with $py_int"
"$py_int" ./test.py
done
}
package_python-viivakoodi() {
depends=('python'
'python-setuptools')
optdepends=('python-pillow: render barcodes as images')
checkdepends=('python-pytest'
'python-mock'
'python-tox')
cd "$srcdir/$pkgbase-$pkgver"
python setup.py install --root="$pkgdir/" --optimize=1
install -Dm644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
install -Dm644 LICENSE
"$pkgdir/usr/share/licenses/$pkgname/LICENSE.launcher"
}
package_python2-viivakoodi() {
depends=('python2'
'python2-setuptools')
optdepends=('python2-pillow: render barcodes as images')
checkdepends=('python2-pytest'
'python2-mock'
'python2-tox')
cd "$srcdir/$pkgbase-$pkgver"
python2 setup.py install --root="$pkgdir/" --optimize=1
install -Dm644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
install -Dm644 LICENSE
"$pkgdir/usr/share/licenses/$pkgname/LICENSE.launcher"
}
signature.asc
Description: PGP signature
Re: [aur-general] [REVIEW REQUEST] python-viivakoodi
On 16-11-29 23:59:45, Eli Schwartz via aur-general wrote:
> On 11/29/2016 08:19 PM, Quentin Bourgeois wrote:
> > Ouch, one new try :p
>
> Looks good to me. I'd say it is ready to upload to the AUR.
>
Hi,
I finally managed to upload to AUR[0]. I had to made some
modification[1] in order to pass the different hooks on the server but
I think they would be ok.
Thanks to you and Florian for showing me the way, I really appreciate.
Nevertheless it seems that I definitely need to change from yaourt to
other AUR helper that supports split packages. :p
> > Definitely, but its quiet fun to be faced with such problems.
>
> It's also quite fun even when you're loud. ;)
>
> > If you may I propose the following summary in order to assert that
> > I am starting to get a bigger picture:
> >
> > - setuptools related stuff
> > Some project, like viivakoodi, needs setuptools for installation. In
> > such case pythonX-setuptools is needed at build-time.
> > * If we provide a split packages both python{,2}-setuptools should
> > be included into makedepends()
> > * If the project use *console_scripts* entry points
> > pythonX-setuptools is needed as the runtime dependencies too.
> >
> > - PKGBUILD/makepkg related stuff
> > At built-time makepkg "merge" both makedepends() and depends().
> > * However, if we are building a split package with a depends()
> > inside a package_* function, this depends() will not be watched at
> > built-time. So packager must "copy" the content of package_*
> > depends() into global makedepends() in that particular case.
>
> Yup, that's about it. Predicated on the build needing all runtime
> dependencies installed, which is the case for setuptools.
>
> It is worth noting purely for correctness, that the *console_scripts*
> spec also has a brother called *gui_scripts*, which is the same thing
> but indicates the script/exe should launch a GUI instead of existing in
> a terminal. (I guess that has a practical difference on Windows.)
>
> While not referenced here because viivakoodi has none, projects that
> have *gui_scripts* display the same behavior -- setuptools is generating
> the *entry_points* ==> {console,gui}_scripts instead of using the
> user-supplied *scripts* , and since setuptools generates it for you it
> embeds itself into the scene. I suppose this is useful for allowing it
> to check the *.egg-info/requires.txt at runtime, although distro
> packaging theoretically takes care of that for us.
>
Is it relevant to add some of this information
(runtime deps on setuptools) ? I don't remember having seen such
information while looking at the manpage/wiki. In the other hand I
don't known if its obvious for other.
[0]: https://aur.archlinux.org/packages/python-viivakoodi/
https://aur.archlinux.org/packages/python2-viivakoodi/
[1]:
https://git.bourgeois.eu/aur_python_viivakoodi.git/tree/PKGBUILD?h=python-viivakoodi-0.8.0-3
> --
> Eli Schwartz
signature.asc
Description: PGP signature
Re: [aur-general] [REVIEW REQUEST] python-viivakoodi
On 16-12-01 21:57:08, Eli Schwartz via aur-general wrote: > On 12/01/2016 08:24 PM, Quentin Bourgeois wrote: > > I finally managed to upload to AUR[0]. I had to made some > > modification[1] in order to pass the different hooks on the server but > > I think they would be ok. > > So I see... especially the "every commit must have a .SRCINFO". I had > kind of sort of assumed you would push the PKGBUILD you finally settled > on as the initial PKGBUILD, but apparently you opted to preserve your > learning experience for eternity. :p > > Unfortunately that won't work, since your learning experience included a > missing .SRCINFO which cannot be preserved. :D Indeed, I did a pretty bad job with that, which, was not tested enough. I will try to come up with a better solution by tomorrow. > > > Is it relevant to add some of this information > > (runtime deps on setuptools) ? I don't remember having seen such > > information while looking at the manpage/wiki. In the other hand I > > don't known if its obvious for other. > > Which manpage/wiki? I was thinking of the wiki page that give instruction with Python PKGBUILD[0]. > > I guess it is sort of assumed that people won't uninstall setuptools -- > it is part of the python package manager scene (distutils -> setuptools > -> pip) and in a way it sort of competes with pacman. > "The standard library is where modules go to die" but nevertheless, I am > pretty sure the setuptools developers would love to make sure everyone > always has it, no matter what. > > But I will admit it wasn't obvious to me... until I learned the basics > of python module packaging. > > -- > Eli Schwartz [0] https://wiki.archlinux.org/index.php/Python_PKGBUILD signature.asc Description: PGP signature
Re: [aur-general] [REVIEW REQUEST] python-viivakoodi
On 16-11-28 23:02:02, Eli Schwartz via aur-general wrote:
> On 11/28/2016 07:47 PM, Quentin Bourgeois wrote:
> > On 16-11-27 19:41:06, Eli Schwartz via aur-general wrote:
> >> On 11/27/2016 06:10 PM, Quentin Bourgeois wrote:
> >>> With this, I come with a simpler PKGBUILD[0] in which I push
> >>> modifications you advised. I also removed some dependencies that are
> >>> used for code coverage and building documentation, which I do not
> >>> install for now.
> >>>
> >>> Did we get to something good ?
> >>>
> >>> [0] https://git.bourgeois.eu/aur_python_viivakoodi.git/tree/
> >>
> > I should comes with all modification on this batch.
> >
> >> Err, why do both split packages provide 'python2-viivakoodi'? One of
> >> them already is 'python2-viivakoodi', and the other by definition
> >> doesn't supply it, being Python 3.
> > My mistake.
> >
> >> You declare setuptools as a makedepends only, but I hate to inform you
> >> that setuptools-installed packages have a runtime dependency on
> >> setuptools to launch their console scripts. (This is the downside of
> >> having python itself be capable of generating the entry point launchers
> >> in a cross-platform manner -- rather than using your own python scripts
> >> with file extensions, then assuming Linux users will be happy with the
> >> extension and Windows users will be able to launch a non-binary.)
> >>
> >> For module-only python packages, it is only a makedepends... for
> >> packages which ship with console_scripts you need it at runtime as well,
> >> otherwise the console_scripts will fail trying to import pkg_resources.
> >>
> >> You can either have each split package depend on python{,2}-setuptools,
> >> or depend on both that and the python{,2} package itself. I have seen it
> >> done both ways.
> > Hum, this was not abvious for me, thanks. With what I have understand
> > from that I have decide to make every split package depend on pythonX
> > and pythonX-setuptools its seem simpler for me to understand.
> >
> > I will dig this setuptools + console_script topics by my own.
>
> No, put the combined setuptools makedepends back! makepkg usually
> includes depends=() in the resolved build-time dependencies, but for
> split packages which have depends=() declared in the package_* function,
> those do not get added to the build-time dependencies.
>
> You can actually use that as a practical way to define rundepends --
> runtime-only depends which don't need to be installed when building
> (which makepkg has no concept of and the developers aren't interested in
> especially considering there is a reasonable workaround).
>
> So, many python packages end up with a makedepends on
> python{,2}-setuptools (to ensure building works) *and* a depends on
> setuptools in each package_* function.
Ouch, one new try :p
>
> Sorry, this must seem quite confusing with all this back and forth. :D
> On the other hand, think of everything you are learning...
Definitely, but its quiet fun to be faced with such problems. If you
may I propose the following summary in order to assert that I am
starting to get a bigger picture:
- setuptools related stuff
Some project, like viivakoodi, needs setuptools for installation. In
such case pythonX-setuptools is needed at build-time.
* If we provide a split packages both python{,2}-setuptools should
be included into makedepends()
* If the project use *console_scripts* entry points
pythonX-setuptools is needed as the runtime dependencies too.
- PKGBUILD/makepkg related stuff
At built-time makepkg "merge" both makedepends() and depends().
* However, if we are building a split package with a depends()
inside a package_* function, this depends() will not be watched at
built-time. So packager must "copy" the content of package_*
depends() into global makedepends() in that particular case.
> > On this, when I run namcap on created packages I get some warnings:
> >
> > $ namcap *.tar.xz
> > python2-viivakoodi W: Dependency python2 included but already satisfied
> > python2-viivakoodi W: Dependency included and not needed
> > ('python2-setuptools')
> > python-viivakoodi W: Dependency python included but already satisfied
> > python-viivakoodi W: Dependency included and not needed
> > ('python-setuptools')
> >
> >
> > For every packages the first warning is due to my choice. For the
> > second does namcap could warn packager that are not aware of the
> > setuptools+console_scripts things (or maybe its something well known
Re: [aur-general] [REVIEW REQUEST] python-viivakoodi
On 16-12-03 19:38:13, Eli Schwartz via aur-general wrote: > On 12/02/2016 08:04 PM, Quentin Bourgeois wrote: > >> Which manpage/wiki? > > I was thinking of the wiki page that give instruction with Python > > PKGBUILD[0]. > > > > [0] https://wiki.archlinux.org/index.php/Python_PKGBUILD > > Check that Wiki page again, I added a section on setuptools. > > Suggestions are welcome, in case anyone reads this who is better at > writing Wikis than I am; I make no promises... > Seems good to me, I just remove a word repitition. The section on setuptools is clear! Thanks. signature.asc Description: PGP signature
