[review-request] python-intelhex

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[review-request] python-intelhex

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

PKGBUILD (1K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [review-request] python-intelhex

Justin Dray
This would probably be best posted to the package page for the
python2-intelhex package. The mailing list isn't really for issues with
individual packages.

FYI, removing the bin on python2 will be so that you can install both
packages side-by-side without conflicts, but the python3 will be the
default one used as a binary on the path.

On Tue, 24 Jan 2017 at 11:49 Quentin Bourgeois <[hidden email]> wrote:

> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [review-request] python-intelhex

tur-users mailing list
In reply to this post by Quentin Bourgeois
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 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.

--
Eli Schwartz


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [review-request] python-intelhex

Quentin Bourgeois
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 (849 bytes) Download Attachment