[aur-general] Help with python-magic-wormhole PKGBUILD
Howdy, I have had a few people post that they are having trouble with this since it became a split package. Currently, I am unable to reproduce the problems. I have installed it both with yay and with makepkg. I do see one who tried to install it as a group, and since both provide the same package, that would conflict, but they should be able to install either python2-magic-wormhole or python-magic-wormhole. I Can't find anything wrong with the PKGBUILD. Can someone please take a look and let me know if there's anything I can do to make it work better for these people who are having problems? https://aur.archlinux.org/pkgbase/magic-wormhole/ Thanks, Storm -- Powered by Arch Linux! I am registered Linux user number 508465: https://linuxcounter.net/user/508465.html get my public PGP key: gpg --keyserver wwwkeys.pgp.net --recv-key 43DDC193 How to load Windows on your machine in 2 minutes or less: http://www.youtube.com/watch?v=FVbf9tOGwno "Death or glory i will find, Rebellion on my mind." Grave Digger - Rebellion (The Clans Are Marching)
On Mon, 2018-12-10 at 10:24 -0500, Storm Dragon via aur-general wrote:
Howdy,
I have had a few people post that they are having trouble with this since it became a split package. Currently, I am unable to reproduce the problems. I have installed it both with yay and with makepkg. I do see one who tried to install it as a group, and since both provide the same package, that would conflict, but they should be able to install either python2-magic-wormhole or python-magic-wormhole.
I Can't find anything wrong with the PKGBUILD. Can someone please take a look and let me know if there's anything I can do to make it work better for these people who are having problems?
https://aur.archlinux.org/pkgbase/magic-wormhole/
Thanks, Storm
I can confirm that pikaur does not properly handle the package. The problem appears to be that the PKGBUILD requires both the python- and python2-versions of dependencies, but both of the splits then define their own depends. Pikaur then installs only the depends for the version that I specify (I tried python 3 first) and ignores the python 2 versions. Then when "makepkg -s" is called, it complains that the python2 versions of the AUR packages cannot be found. (repo packages are fine, of course) I don't know if this is a bug, but you can probably work around this by moving all those dependencies to the makedepends if you need them during the build or remove them altogether otherwise. For me, the latter option works. Best, Bert.
On 12/10/18 10:42 AM, Bert Peters via aur-general wrote:
I can confirm that pikaur does not properly handle the package. The problem appears to be that the PKGBUILD requires both the python- and python2-versions of dependencies, but both of the splits then define their own depends.
Pikaur then installs only the depends for the version that I specify (I tried python 3 first) and ignores the python 2 versions. Then when "makepkg -s" is called, it complains that the python2 versions of the AUR packages cannot be found. (repo packages are fine, of course)
I don't know if this is a bug, but you can probably work around this by moving all those dependencies to the makedepends if you need them during the build or remove them altogether otherwise. For me, the latter option works.
The package_*() depends override globally listed depends. If pikaur does not try to install the global depends together with the makedepends before the build happens... this is a bug in pikaur and pikaur is broken. This is regardless of whether the PKGBUILD "should" use global depends. -- Eli Schwartz Bug Wrangler and Trusted User
On Mon, 2018-12-10 at 11:17 -0500, Eli Schwartz via aur-general wrote:
The package_*() depends override globally listed depends. If pikaur does not try to install the global depends together with the makedepends before the build happens... this is a bug in pikaur and pikaur is broken.
This is regardless of whether the PKGBUILD "should" use global depends.
I wasn't insisting that the original package was wrong, I was reproducing the bug that Storm asked about. I wouldn't be surprised if other AUR helpers have this issue too. Thanks for clarifying the correct behaviour; I've created an issue for this. Best, Bert.
On 12/10/18 10:24 AM, Storm Dragon via aur-general wrote:
Howdy,
I have had a few people post that they are having trouble with this since it became a split package. Currently, I am unable to reproduce the problems. I have installed it both with yay and with makepkg. I do see one who tried to install it as a group, and since both provide the same package, that would conflict, but they should be able to install either python2-magic-wormhole or python-magic-wormhole.
I Can't find anything wrong with the PKGBUILD. Can someone please take a look and let me know if there's anything I can do to make it work better for these people who are having problems?
I can think of a few things wrong with the package. Primarily, why do they both install the /usr/bin/wormhole binary? Per accepted standards for python programs, if it can be built with python3 it must be built and installed with python3. Command-line binaries should *never* care which programming language they are implemented with. The fact that the "magic-wormhole" program also provides a python library is immaterial. I assume its primary use is to run the "wormhole" command. If some other program also needs to import it as a python library rather than use the executable binary interface, and needs to use the python2 version, then it should provide the library *without* providing the binary. It will then be perfectly okay being coinstalled. Additional notes: The (primary) package should continue to be named "magic-wormhole". There is no need for any provides/conflicts/replaces, since python2-magic-wormhole should not be a replacement for the command-line tool. Please use proper line wrapping for extremely long depends arrays, as the current PKGBUILD is difficult to read. The url pointing to PyPI is not very helpful, I recommend using the readthedocs website: https://magic-wormhole.readthedocs.io/en/latest/welcome.html Python packages should use `python setup.py build` in a build() function, rather than going straight to `python setup.py install` in package(). See: https://wiki.archlinux.org/index.php/Python_package_guidelines -- Eli Schwartz Bug Wrangler and Trusted User
Howdy, On Mon, Dec 10, 2018 at 11:34:27AM -0500, AUR General wrote:
I can think of a few things wrong with the package. Primarily, why do they both install the /usr/bin/wormhole binary?
Per accepted standards for python programs, if it can be built with python3 it must be built and installed with python3. Command-line binaries should *never* care which programming language they are implemented with.
The fact that the "magic-wormhole" program also provides a python library is immaterial. I assume its primary use is to run the "wormhole" command.
If some other program also needs to import it as a python library rather than use the executable binary interface, and needs to use the python2 version, then it should provide the library *without* providing the binary. It will then be perfectly okay being coinstalled.
Additional notes:
The (primary) package should continue to be named "magic-wormhole". There is no need for any provides/conflicts/replaces, since python2-magic-wormhole should not be a replacement for the command-line tool.
Please use proper line wrapping for extremely long depends arrays, as the current PKGBUILD is difficult to read.
The url pointing to PyPI is not very helpful, I recommend using the readthedocs website: https://magic-wormhole.readthedocs.io/en/latest/welcome.html
Python packages should use `python setup.py build` in a build() function, rather than going straight to `python setup.py install` in package(). See: https://wiki.archlinux.org/index.php/Python_package_guidelines
So just to make sure, this all boils down to, this shouldn't be a split package, and the probablem with taholafs should be solved by that package maintainer instead of depending on me? Would it be ok to unsplit the package and go back to a python3 only distribution now?
-- Eli Schwartz Bug Wrangler and Trusted User
-- Powered by Arch Linux! I am registered Linux user number 508465: https://linuxcounter.net/user/508465.html get my public PGP key: gpg --keyserver wwwkeys.pgp.net --recv-key 43DDC193 "A sea of green will set us free" Six Feet Under - 420
On 12/10/18 11:54 AM, Storm Dragon via aur-general wrote:
So just to make sure, this all boils down to, this shouldn't be a split package, and the probablem with taholafs should be solved by that package maintainer instead of depending on me? Would it be ok to unsplit the package and go back to a python3 only distribution now?
If taholafs requires the ability to "import wormhole" in a python2 program, then it is fine to provide a split package. However, the split python2 package should only contain the library module, and should rm -rf "${pkgdir}"/usr/bin ... Is taholafs not in the AUR? There are no AUR packages which depend on magic-wormhole, and I cannot find anything when searching for "taholafs". -- Eli Schwartz Bug Wrangler and Trusted User
On 12/10/18 12:15 PM, Eli Schwartz wrote:
On 12/10/18 11:54 AM, Storm Dragon via aur-general wrote:
So just to make sure, this all boils down to, this shouldn't be a split package, and the probablem with taholafs should be solved by that package maintainer instead of depending on me? Would it be ok to unsplit the package and go back to a python3 only distribution now?
If taholafs requires the ability to "import wormhole" in a python2 program, then it is fine to provide a split package.
However, the split python2 package should only contain the library module, and should rm -rf "${pkgdir}"/usr/bin
...
Is taholafs not in the AUR? There are no AUR packages which depend on magic-wormhole, and I cannot find anything when searching for "taholafs".
I've written up an untested PKGBUILD that expresses what I believe you want. Note how I've fixed up the url and the two package names it provides, and installed the LICENSE file which you *must* install for MIT-licensed software. Also note the addition of the testsuite, and the reliance on a dummy array _deps=() to track the twelve module dependencies, which are super annoying to enter four times over. paste: https://paste.xinu.at/DsTdAi/ inline: # Maintainer: Storm Dragon <stormdragon2976@gmail.com> # Contributor: Eli Schwartz <eschwartz@archlinux.org> pkgbase=magic-wormhole pkgname=('magic-wormhole' 'python2-magic-wormhole') pkgver=0.11.2 pkgrel=1 pkgdesc="Securely transfer data between computers" arch=('any') url="https://magic-wormhole.readthedocs.io/en/latest/welcome.html" license=('MIT') _deps=('autobahn' 'click' 'cffi' 'hkdf' 'humanize' 'idna' 'ipaddress' 'pynacl' 'service-identity' 'spake2' 'tqdm' 'txtorcon') makedepends=('python2-setuptools' 'python-setuptools') checkdepends=("${_deps[@]/#/python-}" "${_deps[@]/#/python2-}" 'python-mock' 'python2-mock') source=("https://files.pythonhosted.org/packages/source/${pkgbase::1}/${pkgbase}/${pkgbase}-${pkgver}.tar.gz") sha512sums=('890c0f1f946dfd9a9bde2ec0079c55dc23b328e04780e6baf8c580dfd068bf37a5b2e00e12119be6529a6e0893d4f711145e04c349ccfdf7ef91e87cef785d36') build() { cd "${srcdir}/${_pkgname}-${pkgver}" python setup.py build python2 setup.py build } check() { cd "${srcdir}/${_pkgname}-${pkgver}" python setup.py test python2 setup.py test } package_magic-wormhole() { pkgdesc="Securely transfer data between computers" depends=("${_deps[@]/#/python-}") cd "${srcdir}/${_pkgname}-${pkgver}" python2 setup.py install --root="${pkgdir}/" --optimize=1 install -Dm644 LICENSE "${pkgdir}"/usr/share/licenses/${pkgname}/LICENSE } package_python2-magic-wormhole() { pkgdesc="Library to securely transfer data between computers" depends=("${_deps[@]/#/python2-}") cd "${srcdir}/${_pkgname}-${pkgver}" python2 setup.py install --root="${pkgdir}/" --optimize=1 rm -rf "${pkgdir}"/usr/bin install -Dm644 LICENSE "${pkgdir}"/usr/share/licenses/${pkgname}/LICENSE } -- Eli Schwartz Bug Wrangler and Trusted User
On 12/10/18 12:19 PM, Eli Schwartz wrote:
On 12/10/18 12:15 PM, Eli Schwartz wrote:
On 12/10/18 11:54 AM, Storm Dragon via aur-general wrote:
So just to make sure, this all boils down to, this shouldn't be a split package, and the probablem with taholafs should be solved by that package maintainer instead of depending on me? Would it be ok to unsplit the package and go back to a python3 only distribution now?
If taholafs requires the ability to "import wormhole" in a python2 program, then it is fine to provide a split package.
However, the split python2 package should only contain the library module, and should rm -rf "${pkgdir}"/usr/bin
...
Is taholafs not in the AUR? There are no AUR packages which depend on magic-wormhole, and I cannot find anything when searching for "taholafs".
I've written up an untested PKGBUILD that expresses what I believe you want. Note how I've fixed up the url and the two package names it provides, and installed the LICENSE file which you *must* install for MIT-licensed software.
Also note the addition of the testsuite, and the reliance on a dummy array _deps=() to track the twelve module dependencies, which are super annoying to enter four times over.
paste: https://paste.xinu.at/DsTdAi/
inline:
# Maintainer: Storm Dragon <stormdragon2976@gmail.com> # Contributor: Eli Schwartz <eschwartz@archlinux.org>
pkgbase=magic-wormhole pkgname=('magic-wormhole' 'python2-magic-wormhole') pkgver=0.11.2 pkgrel=1 pkgdesc="Securely transfer data between computers" arch=('any') url="https://magic-wormhole.readthedocs.io/en/latest/welcome.html" license=('MIT') _deps=('autobahn' 'click' 'cffi' 'hkdf' 'humanize' 'idna' 'ipaddress' 'pynacl' 'service-identity' 'spake2' 'tqdm' 'txtorcon') makedepends=('python2-setuptools' 'python-setuptools') checkdepends=("${_deps[@]/#/python-}" "${_deps[@]/#/python2-}" 'python-mock' 'python2-mock') source=("https://files.pythonhosted.org/packages/source/${pkgbase::1}/${pkgbase}/${pkgbase}-${pkgver}.tar.gz") sha512sums=('890c0f1f946dfd9a9bde2ec0079c55dc23b328e04780e6baf8c580dfd068bf37a5b2e00e12119be6529a6e0893d4f711145e04c349ccfdf7ef91e87cef785d36')
build() { cd "${srcdir}/${_pkgname}-${pkgver}" python setup.py build python2 setup.py build }
check() { cd "${srcdir}/${_pkgname}-${pkgver}"
python setup.py test python2 setup.py test }
package_magic-wormhole() { pkgdesc="Securely transfer data between computers" depends=("${_deps[@]/#/python-}") cd "${srcdir}/${_pkgname}-${pkgver}"
python2 setup.py install --root="${pkgdir}/" --optimize=1
This is obviously a copy-paste error and must be "python".
install -Dm644 LICENSE "${pkgdir}"/usr/share/licenses/${pkgname}/LICENSE }
package_python2-magic-wormhole() { pkgdesc="Library to securely transfer data between computers" depends=("${_deps[@]/#/python2-}") cd "${srcdir}/${_pkgname}-${pkgver}"
python2 setup.py install --root="${pkgdir}/" --optimize=1 rm -rf "${pkgdir}"/usr/bin install -Dm644 LICENSE "${pkgdir}"/usr/share/licenses/${pkgname}/LICENSE }
-- Eli Schwartz Bug Wrangler and Trusted User
Howdy, On Mon, Dec 10, 2018 at 12:21:19PM -0500, AUR General wrote:
Is taholafs not in the AUR? There are no AUR packages which depend on magic-wormhole, and I cannot find anything when searching for "taholafs".
I guess it would be helpful if I had spelled the package name correctly. :) It is tahoe-lafs-git.
I've written up an untested PKGBUILD that expresses what I believe you want. Note how I've fixed up the url and the two package names it provides, and installed the LICENSE file which you *must* install for MIT-licensed software.
Also note the addition of the testsuite, and the reliance on a dummy array _deps=() to track the twelve module dependencies, which are super annoying to enter four times over.
Thanks so much for this, I have learned a lot from it. It seems to work, but now I'm having trouble with another package, python2-humanize which, in part, says this: make: Entering directory '/home/storm/.cache/yay/python2-humanize/src/humanize-0.5.1/docs' sphinx-build -b html -d _build/doctrees . _build/html make: sphinx-build: Command not found make: *** [Makefile:34: html] Error 127 This does not happen with the python3 version. I have heard that python2 is going to be completely deprecated after january. If that is true, will these packages have to be changed back to py3 only after then?
-- Eli Schwartz Bug Wrangler and Trusted User
-- Powered by Arch Linux! I am registered Linux user number 508465: https://linuxcounter.net/user/508465.html get my public PGP key: gpg --keyserver wwwkeys.pgp.net --recv-key 43DDC193 The great thing about Object Oriented code is that it can make small, simple problems look like large, complex ones. "And the blood drains down like devil's rain, We'll bathe tonight." The Misfits - Skulls
On 12/11/18 12:38 PM, Storm Dragon via aur-general wrote:
Howdy,
On Mon, Dec 10, 2018 at 12:21:19PM -0500, AUR General wrote:
Is taholafs not in the AUR? There are no AUR packages which depend on magic-wormhole, and I cannot find anything when searching for "taholafs".
I guess it would be helpful if I had spelled the package name correctly. :) It is tahoe-lafs-git.
Ouch. There's an AUR package for that but it hasn't been updated since 2015 and the most glaring issue is that it currently depends on "twisted" which was deprecated for "python2-twisted" a long time ago. Also yeah, it imports wormhole in the python code, and uses python2, so it should be updated to new versions of tahoe-lafs and in the process updated to depend on python2-magic-wormhole. If you're interested in this package, please request it to be orphaned, then fix it up.
I've written up an untested PKGBUILD that expresses what I believe you want. Note how I've fixed up the url and the two package names it provides, and installed the LICENSE file which you *must* install for MIT-licensed software.
Also note the addition of the testsuite, and the reliance on a dummy array _deps=() to track the twelve module dependencies, which are super annoying to enter four times over.
Thanks so much for this, I have learned a lot from it. It seems to work, but now I'm having trouble with another package, python2-humanize which, in part, says this:
make: Entering directory '/home/storm/.cache/yay/python2-humanize/src/humanize-0.5.1/docs' sphinx-build -b html -d _build/doctrees . _build/html make: sphinx-build: Command not found make: *** [Makefile:34: html] Error 127
This does not happen with the python3 version.
The python3 version is in the official repos. The Makefile that is being run over there unconditionally uses the command "sphinx-build" which is provided by python-sphinx, and the package needs to be updated to depend on that instead... or to stop using the Makefile, and invoke sphinx-build2 instead. *glares at foxlike maintainer*
I have heard that python2 is going to be completely deprecated after january. If that is true, will these packages have to be changed back to py3 only after then?
Python2 is not going away IMHO. There is too much code which still uses it. The Python Software Foundation may drop support for it, but I suspect other interest groups will pick up the torch... Either way, it is up to the maintainer whether to support python2 split builds. You might decide it is simply not worth it. -- Eli Schwartz Bug Wrangler and Trusted User
participants (3)
-
Bert Peters
-
Eli Schwartz
-
Storm Dragon