[aur-general] Signoff report for [community-testing]
=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 76 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 1 fully signed off package * 99 packages missing signoffs * 4 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [community-testing] in last 24 hours (76 total) == * 0ad-a21-2 (i686) * aegisub-3.2.2-17 (i686) * arm-none-eabi-gcc-6.2.0-2 (i686) * bluegriffon-2.1.1-5 (i686) * calibre-2.73.0-2 (i686) * codeblocks-16.01-7 (i686) * couchdb-2.0.0-3 (i686) * dwdiff-2.0.9-7 (i686) * gambas3-3.9.1-3 (i686) * gdal-2.1.1-3 (i686) * gnustep-base-1.24.9-3 (i686) * gnustep-gui-0.25.0-4 (i686) * goldendict-1.5.0RC2-5 (i686) * haskell-text-icu-0.7.0.1-6 (i686) * ibus-qt-1.3.3-7 (i686) * mapnik-3.0.12-3 (i686) * ncmpcpp-0.7.7-3 (i686) * nodejs-7.2.0-2 (i686) * onboard-1.3.0-3 (i686) * open-vm-tools-6:10.1.0-2 (i686) * openobex-1.7.2-1 (i686) * openttd-1.6.1-2 (i686) * pandoc-citeproc-0.10.2.2-5 (i686) * parrot-8.1.0-4 (i686) * pdf2djvu-0.9.4-5 (i686) * phantomjs-2.1.1-4 (i686) * poedit-1.8.11-2 (i686) * python-pyicu-1.9.5-2 (i686) * seamonkey-2.40-7 (i686) * sigil-0.9.7-2 (i686) * sword-1.7.4-8 (i686) * tea-43.1.0-3 (i686) * tesseract-3.04.01-2 (i686) * widelands-19-3 (i686) * xcb-util-xrm-1.2-1 (i686) * xulrunner-41.0.2-9 (i686) * yaz-5.18.0-3 (i686) * znc-1.6.3-5 (i686) * 0ad-a21-2 (x86_64) * aegisub-3.2.2-17 (x86_64) * arm-none-eabi-gcc-6.2.0-2 (x86_64) * bluegriffon-2.1.1-5 (x86_64) * calibre-2.73.0-2 (x86_64) * codeblocks-16.01-7 (x86_64) * couchdb-2.0.0-3 (x86_64) * dwdiff-2.0.9-7 (x86_64) * gambas3-3.9.1-3 (x86_64) * gdal-2.1.1-3 (x86_64) * gnustep-base-1.24.9-3 (x86_64) * gnustep-gui-0.25.0-4 (x86_64) * goldendict-1.5.0RC2-5 (x86_64) * haskell-text-icu-0.7.0.1-6 (x86_64) * ibus-qt-1.3.3-7 (x86_64) * mapnik-3.0.12-3 (x86_64) * ncmpcpp-0.7.7-3 (x86_64) * nodejs-7.2.0-2 (x86_64) * onboard-1.3.0-3 (x86_64) * open-vm-tools-6:10.1.0-2 (x86_64) * openobex-1.7.2-1 (x86_64) * openttd-1.6.1-2 (x86_64) * pandoc-citeproc-0.10.2.2-5 (x86_64) * parrot-8.1.0-4 (x86_64) * pdf2djvu-0.9.4-5 (x86_64) * phantomjs-2.1.1-4 (x86_64) * poedit-1.8.11-2 (x86_64) * python-pyicu-1.9.5-2 (x86_64) * seamonkey-2.40-7 (x86_64) * sigil-0.9.7-2 (x86_64) * sword-1.7.4-8 (x86_64) * tea-43.1.0-3 (x86_64) * tesseract-3.04.01-2 (x86_64) * widelands-19-3 (x86_64) * xcb-util-xrm-1.2-1 (x86_64) * xulrunner-41.0.2-9 (x86_64) * yaz-5.18.0-3 (x86_64) * znc-1.6.3-5 (x86_64) == Incomplete signoffs for [community] (99 total) == * python-cairosvg-2.0.0-1 (any) 0/2 signoffs * python-celery-4.0.0-1 (any) 0/2 signoffs * python-cryptography-vectors-1.6-1 (any) 0/2 signoffs * python-kombu-4.0.0-1 (any) 0/2 signoffs * python-logilab-common-1.3.0-1 (any) 0/2 signoffs * python-passlib-1.7.0-1 (any) 0/2 signoffs * 0ad-a21-2 (i686) 0/1 signoffs * aegisub-3.2.2-17 (i686) 0/1 signoffs * arm-none-eabi-gcc-6.2.0-2 (i686) 0/1 signoffs * bluegriffon-2.1.1-5 (i686) 0/1 signoffs * calibre-2.73.0-2 (i686) 0/1 signoffs * codeblocks-16.01-7 (i686) 0/1 signoffs * couchdb-2.0.0-3 (i686) 0/1 signoffs * darktable-2:2.2.0rc1-1 (i686) 0/1 signoffs * devil-1.7.8-24 (i686) 0/1 signoffs * dwdiff-2.0.9-7 (i686) 0/1 signoffs * gambas3-3.9.1-3 (i686) 0/1 signoffs * gdal-2.1.1-3 (i686) 0/1 signoffs * gimp-ufraw-0.22-9 (i686) 0/1 signoffs * gnustep-base-1.24.9-3 (i686) 0/1 signoffs * gnustep-gui-0.25.0-4 (i686) 0/1 signoffs * goldendict-1.5.0RC2-5 (i686) 0/1 signoffs * haskell-text-icu-0.7.0.1-6 (i686) 0/1 signoffs * ibus-qt-1.3.3-7 (i686) 0/1 signoffs * keepalived-1.3.2-1 (i686) 0/1 signoffs * libasl-0.1.7-1 (i686) 0/1 signoffs * libfdk-aac-0.1.4.r88.5fd7e65-1 (i686) 0/1 signoffs * mapnik-3.0.12-3 (i686) 0/1 signoffs * ncmpcpp-0.7.7-3 (i686) 0/1 signoffs * nodejs-7.2.0-2 (i686) 0/1 signoffs * onboard-1.3.0-3 (i686) 0/1 signoffs * open-vm-tools-6:10.1.0-2 (i686) 0/1 signoffs * openobex-1.7.2-1 (i686) 0/1 signoffs * openscenegraph-3.4.0-4 (i686) 0/1 signoffs * openttd-1.6.1-2 (i686) 0/1 signoffs * pandoc-citeproc-0.10.2.2-5 (i686) 0/1 signoffs * parrot-8.1.0-4 (i686) 0/1 signoffs * pdf2djvu-0.9.4-5 (i686) 0/1 signoffs * phantomjs-2.1.1-4 (i686) 0/1 signoffs * poedit-1.8.11-2 (i686) 0/1 signoffs * python-pyicu-1.9.5-2 (i686) 0/1 signoffs * seamonkey-2.40-7 (i686) 0/1 signoffs * sigil-0.9.7-2 (i686) 0/1 signoffs * sword-1.7.4-8 (i686) 0/1 signoffs * tea-43.1.0-3 (i686) 0/1 signoffs * tesseract-3.04.01-2 (i686) 0/1 signoffs * widelands-19-3 (i686) 0/1 signoffs * xcb-util-xrm-1.2-1 (i686) 0/1 signoffs * xulrunner-41.0.2-9 (i686) 0/1 signoffs * xv-3.10a-22 (i686) 0/1 signoffs * yaz-5.18.0-3 (i686)
Re: [aur-general] TU Application: Baptiste Jonglez
On Tue, Nov 29, 2016 at 01:04:47AM +0100, Levente Polyak wrote: > On 11/29/2016 12:29 AM, Baptiste Jonglez wrote: > >> - you should use git+https:// instead of plain git:// even through the > >> CA world is a bit wonky it still authenticates the server and at the > >> very bare minimum adds confidentiality. > > > > I don't like the "everything-over-HTTP(S)" approach in general, especially > > when there is a dedicated protocol that works (yes, I know, this is basic > > ranting). > > > > Assuming the git revision is identified by a commit hash, I see no value > > in using HTTPS for authentication or verification. I agree it is useful > > however when building from a tag or a branch, as you correctly pointed out > > for another package. > > > > On the other hand, if one day the TLS certificate becomes invalid (expired > > certificate, untrusted CA, etc), the package would fail to build. I see > > this as a significant drawback of using git+https://. > > Well pulling over TLS was discussed over and over and over and over > again and we ended up that we just do it for all of our packages if > available... > Thats why this came up in the first place: > https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/ Yes, I saw the discussion on arch-dev-public (but obviously could not participate). > I quote dave: "Security is not a binary thing". > It adds another layer of security, if you like it or not. It > authenticates the server (yes there may be untrusted CA, so? *shrug*) > and i repeat again: at the very bare minimum adds confidentiality. Feel > free to re-read the arch-dev-public thread, the outcome was the > mentioned todo list. > > I heard a lot of opinions and some of them are understandable... but > saying that its a significant drawback as the certificate could possible > be invalid/expired is certainly nothing i would _ever_ consider as such. For a package in [community], an expired certificate for the upstream tarball is not a big deal, since it does not directly affect the Arch user installing the package. As a packager, you can just get the tarball by some other means, or wait a few days so that somebody renews the cert. But for the AUR, an expired certificate would be annoying, as any user trying to build the package (e.g. using an AUR helper) would encounter an error. > I never get why people always make such a big fuzz in not pulling over TLS. > The same argumentation could be used for the regular tarballs and I > repeat, the outcome is simple: use https, easy as that. Well, I agree with the outcome of the discussion, which was basically "One way or the other does not change much security-wise, so let's switch to HTTPS if doing so does not require significant efforts". > >> ring-gnome-git > >> - a VCS package should always provide its non-VCS package variant like > >> 'ring-gnome' > > > > Actually, the missing "provides" is intended. The Ring components are > > interdependent and get updated quite frequently, so at any given time > > `ring-foo` and `ring-foo-git` are likely offer a different API/ABI. > > > > More practically, when the "provides" was here, I had issues with AUR > > users mixing -git and non-git ring packages and complaining of building > > errors. > > > > This could be the case for literally _any_ library f.e. and still all of > them have their corresponding provides. If there would be anything > depending on ring-gnome you created an unresolvable hell be just > conflicting it because it may have API changes. > > > >> libringclient-git > >> - a VCS package should always provide its non-VCS package variant like > >> 'libringclient' > >> - If there is no strong reason to depend on a git variant, always depend > >> on the non VCS, in this case ring-daemon instead of ring-daemon-git > > > > See the above comment on gnome-ring-git. > > And here is the -git hell I describes, either take all -git or none... > that's not how it should be. Think how it would be if every library > would be like that, that would mean you need to use -git for the whole > system just because you switch a single package. Don't enforce it just > because... if such happens people will figure. Again, the constraints are a bit different on the AUR and on a binary repository. What I try to ensure is that somebody running e.g. "yaourt -S ring-gnome-git" will not have compilation issues. If ring-gnome-git depends on libringclient, then the former will not build if the API provided by libringclient has changed recently. But you're right, it's a mess. I updated the *ring*-git packages so that they only depend on non-git packages, and they now all provide their non-git version. Anyway, I was thinking of orphaning all those -git Ring packages, since I don't use them anymore and they take time to maintain. Baptiste signature.asc Description: PGP signature
Re: [aur-general] TU Application: Baptiste Jonglez
On 11/29/2016 11:33 AM, Baptiste Jonglez wrote: > For a package in [community], an expired certificate for the upstream > tarball is not a big deal, since it does not directly affect the Arch user > installing the package. As a packager, you can just get the tarball by > some other means, or wait a few days so that somebody renews the cert. > > But for the AUR, an expired certificate would be annoying, as any user > trying to build the package (e.g. using an AUR helper) would encounter an > error. > I call bullshit, especially as your cases are purely about github! Surly, as if they can't wait "a few days" in such an unlikely scenario. And what if upstream forgets to pay for their servers, it won't be available too. How often do you think that certificates stay in an expired state. Of cause there may be one or two cases that could be named, its still certainly nothing to build upon. >> I never get why people always make such a big fuzz in not pulling over TLS. >> The same argumentation could be used for the regular tarballs and I >> repeat, the outcome is simple: use https, easy as that. > > Well, I agree with the outcome of the discussion, which was basically "One > way or the other does not change much security-wise, so let's switch to > HTTPS if doing so does not require significant efforts". > Fine, if you were already aware of the outcome, why this useless waste of time to discuss it yet again. Especially a TU applicant should follow chosen best practices and decisions. The AUR should not be any different from how they should be in the binary repos, so I expect to see those changes in your packages as well. >> libringclient-git - a VCS package should always provide its non-VCS package variant like 'libringclient' - If there is no strong reason to depend on a git variant, always depend on the non VCS, in this case ring-daemon instead of ring-daemon-git >>> >>> See the above comment on gnome-ring-git. >> >> And here is the -git hell I describes, either take all -git or none... >> that's not how it should be. Think how it would be if every library >> would be like that, that would mean you need to use -git for the whole >> system just because you switch a single package. Don't enforce it just >> because... if such happens people will figure. > > Again, the constraints are a bit different on the AUR and on a binary > repository. What I try to ensure is that somebody running e.g. "yaourt -S > ring-gnome-git" will not have compilation issues. If ring-gnome-git > depends on libringclient, then the former will not build if the API > provided by libringclient has changed recently. > Again, even through there are quite obviously no -git packages in the binary repository, the PKGBUILDs in the AUR should not be created in a different way then you would write them in the binary repo. Also AUR packages are influenced by each other and just completely abandon all provides is clearly a very bad practice. As easy as that. https://lists.archlinux.org/pipermail/aur-general/2016-October/032845.html cheers, Levente signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application: Baptiste Jonglez
On November 29, 2016 12:08:39 PM GMT+01:00, Levente Polyak wrote: >Fine, if you were already aware of the outcome, why this useless waste >of time to discuss it yet again. Well, I actually withdraw this sentence, the discussion period is pretty much about discussing :P Cheers, Levente
Re: [aur-general] TU Application: Baptiste Jonglez
Well, I actually withdraw this sentence, the discussion period is pretty much about discussing :P technically the discussion period has not even begun, since there was no confirmation of sponsorship yet. g
Re: [aur-general] TU Application: Baptiste Jonglez
On 11/28/2016 06:29 PM, Baptiste Jonglez wrote: > On the other hand, if one day the TLS certificate becomes invalid (expired > certificate, untrusted CA, etc), the package would fail to build. I see > this as a significant drawback of using git+https://. When you say drawback, are you referring to TLS performing its intended role? I am really confused as to what you are trying to accomplish here. I thought the whole point of switching to git+https:// is in order that builds should fail when suspicious things happen to the source code, like getting served from a domain with a very suspiciously broken certificate. The CACERT model assumes website owners are still alive and capable of renewing their certificate before people call their customer service (if applicable) number to complain that they can't access the website. On the whole, it tends to be pretty successful. (Leaving aside peoples' questions on the premise of the model, at least when we use it we use it according to spec.) An untrusted CA is, well, untrusted. Why would I want to build a package authenticated by them, if I don't trust them? Seriously, your argument is an argument against using TLS on the World Wide Web. "I don't wanna use TLS, because now I cannot access all these broken websites anymore!" -- Eli Schwartz
Re: [aur-general] [REVIEW REQUEST] python-viivakoodi
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] TU Application: Baptiste Jonglez
On Tue, 29 Nov 2016 12:08:39 +0100 Levente Polyak wrote: > On 11/29/2016 11:33 AM, Baptiste Jonglez wrote: > > For a package in [community], an expired certificate for the upstream > > tarball is not a big deal, since it does not directly affect the Arch user > > installing the package. As a packager, you can just get the tarball by > > some other means, or wait a few days so that somebody renews the cert. > > > > But for the AUR, an expired certificate would be annoying, as any user > > trying to build the package (e.g. using an AUR helper) would encounter an > > error. > > > > I call bullshit, especially as your cases are purely about github! > Surly, as if they can't wait "a few days" in such an unlikely scenario. > And what if upstream forgets to pay for their servers, it won't be > available too. > How often do you think that certificates stay in an expired state. Of > cause there may be one or two cases that could be named, its still > certainly nothing to build upon. > > > >> I never get why people always make such a big fuzz in not pulling over TLS. > >> The same argumentation could be used for the regular tarballs and I > >> repeat, the outcome is simple: use https, easy as that. > > > > Well, I agree with the outcome of the discussion, which was basically "One > > way or the other does not change much security-wise, so let's switch to > > HTTPS if doing so does not require significant efforts". > > > > Fine, if you were already aware of the outcome, why this useless waste > of time to discuss it yet again. Especially a TU applicant should follow > chosen best practices and decisions. The AUR should not be any different > from how they should be in the binary repos, so I expect to see those > changes in your packages as well. Git packages were not discussed, and https wasn't really "chosen best practices", it was more "eh, why not". Getting all emotional because someone doesn't buy into your reteric 100% isn't helping anyone. > >> > libringclient-git > - a VCS package should always provide its non-VCS package variant like > 'libringclient' > - If there is no strong reason to depend on a git variant, always depend > on the non VCS, in this case ring-daemon instead of ring-daemon-git > >>> > >>> See the above comment on gnome-ring-git. > >> > >> And here is the -git hell I describes, either take all -git or none... > >> that's not how it should be. Think how it would be if every library > >> would be like that, that would mean you need to use -git for the whole > >> system just because you switch a single package. Don't enforce it just > >> because... if such happens people will figure. > > > > Again, the constraints are a bit different on the AUR and on a binary > > repository. What I try to ensure is that somebody running e.g. "yaourt -S > > ring-gnome-git" will not have compilation issues. If ring-gnome-git > > depends on libringclient, then the former will not build if the API > > provided by libringclient has changed recently. > > > > Again, even through there are quite obviously no -git packages in the > binary repository, the PKGBUILDs in the AUR should not be created in a > different way then you would write them in the binary repo. Also AUR > packages are influenced by each other and just completely abandon all > provides is clearly a very bad practice. As easy as that. > > https://lists.archlinux.org/pipermail/aur-general/2016-October/032845.html Reality time: The AUR is different than the binary repos. Yes, ideally the PKGBUILD should be able to go directly to the binary repos, but reality needs to take precedence over blind ideology. AUR packages are managed differently than repo packages and in the vast majority of cases are built differently as well. I agree with you in this case, but please don't use this dubious argument. It does make sense to depend on the -git versions in cases like this as well. We're not talking everything, we're talking everything in a given stack provided by a single upstream. Applying this to another example, Qt5 packages from git should depend on other Qt5 packages from git, not on their stable versions. Doug pgpSgMvvIeLnj.pgp Description: OpenPGP digital signature
Re: [aur-general] TU Application: Baptiste Jonglez
On Mon, 28 Nov 2016 at 07:33:16, Baptiste Jonglez wrote: > I would like to apply to become a TU. Lukas Fleischer has kindly accepted > to sponsor my application. I confirm that I sponsor Baptiste. I have worked with him several times in the past; among other things he contributed several patches to calcurse back in 2012 [1]. He is knowledgable and I think he will be a great addition to the team! Let the discussion period begin! [1] http://git.calcurse.org/calcurse.git/log/?qt=author&q=Baptiste+Jonglez signature.asc Description: signature
[aur-general] gitpkg Helper
On Mon, Nov 28, 2016 at 5:26 PM Levente Polyak wrote: > In fact we already had several discussions in the IRC about this topic > and what I mentioned above was always sufficient to justify getting rid > of it. The only reason we don't yet have a TODO list to switch away from > #tag= is simply lack of time (but its still on my todo list besides > getting a TODO list for git:// sources). > > If a remember correctly either heftig or JGC has created a convenience > script to update a PKGBUILDs values, maybe they share it with us :) > I did, and it's tracked here now: https://git.archlinux.org/infrastructure.git/tree/roles/archbuild/files/gitpkg Made from cardboard and duct tape. Use with care. May eat your babies for breakfast.
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
> > ?).
>
> 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
Re: [aur-general] [REVIEW REQUEST] python-viivakoodi
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
