Re: [aur-general] [REVIEW REQUEST] python-viivakoodi

2016-12-04 Thread Quentin Bourgeois 
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

Re: [aur-general] [REVIEW REQUEST] python-viivakoodi

2016-12-03 Thread Eli Schwartz via aur-general 
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...

-- 
Eli Schwartz

Re: [aur-general] [REVIEW REQUEST] python-viivakoodi

2016-12-03 Thread Eli Schwartz via aur-general 
On 12/02/2016 08:04 PM, Quentin Bourgeois wrote:
> 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.

That was a joke... I *don't* really think it is important to save the
fact that you forgot the .SRCINFO, and after all there is a time and a
place for `git filter-branch` (in fact, this is how many people migrated
from AUR3 to AUR4).

But the right solution to the question "how can I enforce proper
.SRCINFO, now I know I need them", is, as far as I am concerned, to
emulate me. See: https://github.com/eli-schwartz/pkgbuilds

githooks are where it's at. ;)

-- 
Eli Schwartz

Re: [aur-general] [REVIEW REQUEST] python-viivakoodi

2016-12-02 Thread Quentin Bourgeois 
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

2016-12-01 Thread Eli Schwartz via aur-general 
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

> 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 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

Re: [aur-general] [REVIEW REQUEST] python-viivakoodi

2016-12-01 Thread Quentin Bourgeois 
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

2016-11-29 Thread Eli Schwartz via aur-general 
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.

> 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.

-- 
Eli Schwartz

Re: [aur-general] [REVIEW REQUEST] python-viivakoodi

2016-11-29 Thread Quentin Bourgeois 
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
> > ?). 
> 
> Namcap is meant to offer suggestions that may or may not be applicable.
> It should *never* be taken as gospel truth.
> 
> I am not sure how it figures out which python packages are "needed",
> although it usually does a pretty good job of checking shared library
> dependencies.
> 
> > 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 ?
> 
> There are no guidelines,

Re: [aur-general] [REVIEW REQUEST] python-viivakoodi

2016-11-29 Thread Eli Schwartz via aur-general 
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.

Sorry, this must seem quite confusing with all this back and forth. :D
On the other hand, think of everything you are learning...

> 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
> ?). 

Namcap is meant to offer suggestions that may or may not be applicable.
It should *never* be taken as gospel truth.

I am not sure how it figures out which python packages are "needed",
although it usually does a pretty good job of checking shared library
dependencies.

> 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 ?

There are no guidelines, some people use them and some people don't.
(Rather like bash itself, which also has its fiercely divided camps
advocating competing style guides.) I myself prefer them, you are
definitely not alone. :)



-- 
Eli Schwartz

Re: [aur-general] [REVIEW REQUEST] python-viivakoodi

2016-11-28 Thread Quentin Bourgeois 
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 

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

2016-11-27 Thread Eli Schwartz via aur-general 
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/

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.

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.

...

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.

-- 
Eli Schwartz

Re: [aur-general] [REVIEW REQUEST] python-viivakoodi

2016-11-27 Thread Quentin Bourgeois 
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 
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

2016-11-27 Thread Eli Schwartz via aur-general 
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???

-- 
Eli Schwartz

Re: [aur-general] [REVIEW REQUEST] python-viivakoodi

2016-11-27 Thread Quentin Bourgeois 
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

2016-11-26 Thread Eli Schwartz via aur-general 
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.

-- 
Eli Schwartz

Re: [aur-general] [REVIEW REQUEST] python-viivakoodi

2016-11-25 Thread Florian Bruhin 
* Quentin Bourgeois  [2016-11-26 03:03:02 +0100]:
>   * 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.

You don't. Partial updates are unsupported on Arch, so you can be sure
Arch linux users use Python 2.7 or 3.5.

>   * 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...

> groups=()
> depends=()
> makedepends=()
> provides=()
> conflicts=()
> replaces=()
> backup=()
> options=()
> install=
> changelog=

You can remove empty variables ;)

> optdepends=('inkscape: tools for manipulating vector objects (eg: SVG files)')

You'd usually put an explanation when/why inkscape is needed here.

> checkdepends=('python-tox' 'python-pylint' 'python2-tox' 'python2-pylint') 

I don't think it makes sense to run pylint during check(). It tells
you nothing about if the package is working correctly or not.

> sha256sums=('e1a17dc24975d5242202cfbb7534d69dd14eeb26bdf8a10f056c7b04904fef1e'
>  
> 
> 'c161bd90708ca20c841321139f7e8fe5ae53cb25f55d0327fea5b59ac401f8e9')
> sha384sums=('e2da627423221298dfc55be93ab07e42d8801f0fa63bcfc5ad6bfa689181bcd0e7eb9525abdfd20aa3637ae5656b'
>  
> 
> 'b92e09d3e801b55ec97e28b105d8033d6bace8fc869343331e1093bbb35aabe201432e43ea4487014c92b190a65c89f8')
> sha512sums=('b9f5fc859b3ec33a1cf264d5ede597ff79cd447043668cf433096bf0bf89e24e1a8bf05f7914420934bc6c03a66ec0df99a203136c3f6506e0fda8e3c6f619fd'
>  
> 
> '68b6df665e76555489b9abc616fda11180c1c420e8a5dd74c191543335ee0b887fbba8115f7823aed676242b559af10141fc6a40c4b068a39b9e1038917dc29e')

No point in providing all of them - stick to one.

> 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?

Florian

-- 
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
 I love long mails! | http://email.is-not-s.ms/


signature.asc
Description: PGP signature

[aur-general] [REVIEW REQUEST] python-viivakoodi

2016-11-25 Thread Quentin Bourgeois 
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 
#
# 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 -Dm0644 LICENSE 
"$pkgdir/usr/share/licenses/$pkgname/LICENSE.launcher"
else
warning "license file not found"
fi
}


signature.asc