Hi,
the link with installation scripts (PKGBUILD) [1] for Arch Linux [1] is dead and I guess has been dead for about a month now, since the Arch User Repositories (AUR) has been moved to a git-based backend [3] and the kwant-related packages have not been moved. I took the PKGBUILD files for tinyarray and kwant from a mirror [4] and updated them. They build on my system, but any comments before I reupload them to the AUR are greatly appreciated. You can find the new PKGBUILD files attached.
best regards, Jörg Behrmann
[1] https://aur.archlinux.org/packages/python2-kwant/ [2] http://kwant-project.org/install#arch-linux [3] https://lists.archlinux.org/pipermail/aur-general/2015-June/030724.html [4] https://github.com/aur-archive/python2-tinyarray and https://github.com/aur-archive/python2-kwant/
Hi Jörg,
Thanks a lot for updating Arch Linux packaging of Kwant! Are you planning to maintain them for some time in future?
Your scripts look fine to me. I just noticed that we were still using *.sig for the signatures of the tinyarray tarballs. I now renamed those to *.asc (which seems to be more standard, e.g. it’s what PyPI requires). Can you take this change into account?
Otherwise, you can verify that during the build Cython does not get run. It shouldn’t as the cythonized files are shipped in the tarball. If, however, during the Arch build process the files are copied and loose their proper timestamps it could happen that Cython will get run. In that case, there’s an option to setup.py to inhibit cython: --no-cython
On debian / ubuntu we also build the documentation. Not sure whether it’s common to do this for Arch packages as well. The documentation is available online anyway.
Also, could you please have a look at http://kwant-project.org/install#arch-linux and let me know if something could be improved there?
Thanks Christoph
Hey Christoph
On 10.09.2015 11:33, Christoph Groth wrote:
Thanks a lot for updating Arch Linux packaging of Kwant! Are you planning to maintain them for some time in future?
Sure, that's not a big deal, most of the work is done anyway
Your scripts look fine to me. I just noticed that we were still using *.sig for the signatures of the tinyarray tarballs. I now renamed those to *.asc (which seems to be more standard, e.g. it’s what PyPI requires). Can you take this change into account?
Will do.
Otherwise, you can verify that during the build Cython does not get run. It shouldn’t as the cythonized files are shipped in the tarball. If, however, during the Arch build process the files are copied and loose their proper timestamps it could happen that Cython will get run. In that case, there’s an option to setup.py to inhibit cython: --no-cython
I'll fix that, I just added it because I remembered my build failing due to a missing Cython in my virtualenv when I installed via pip yesterday. If the tarballs contain the cythonized files, this is an unnecessary dependency.
On debian / ubuntu we also build the documentation. Not sure whether it’s common to do this for Arch packages as well. The documentation is available online anyway.
I assume the documentation build process needs sphinx, is that correct? If so it might be easiest to factor out a documentation into a separate python2-kwant-doc package.
Also, could you please have a look at http://kwant-project.org/install#arch-linux and let me know if something could be improved there?
Yes! I forgot that in my last mail, a notice with which PGP key you make signatures and that this key needs to be added to the keyring of the user building the package would be most helpful.
best, Jörg
Jörg wrote:
I assume the documentation build process needs sphinx, is that correct? If so it might be easiest to factor out a documentation into a separate python2-kwant-doc package.
Indeed, and that's why we separate the two for Debian as well. There's python-kwant, and python-kwant-doc.
Also, could you please have a look at http://kwant-project.org/install#arch-linux and let me know if something could be improved there?
Yes! I forgot that in my last mail, a notice with which PGP key you make signatures and that this key needs to be added to the keyring of the user building the package would be most helpful.
I don't have any experience with Arch, so it would be most helpful if you could write a few sentences yourself that we could then include into the instructions.
Christoph
Thank you, Joerg, for your efforts!
I just tried the install scripts on a fresh Arch Linux installation. They do work nicely, and indeed do not require cython.
As for the PGP keys, I suppose
gpg --keyserver pgp.mit.edu --recv-key C3F147F5980F3535
is what is necessary, right?
There is one small issue though: mumps is listed as an optional dependency, and it sounds a bit as if kwant would be sped up if mumps is installed *after* kwant - but that wouldn't work, mumps has to be there on compile-time. Also, the mumps autodetect would not work in arch, I believe - so even with mumps installed kwant would not use it right now. This could be fixed with a appropriately filled-in build.conf, though (see http://www.kwant-project.org/doc/1.0/pre/install#build-configuration ).
I cannot test this, as one of the mumps dependencies (scalapack) does not compile for me at the moment. Maybe the best would be for now to remove mumps from the dependencies altogether?
Best,
Michael
On 10-09-15 11:56, Christoph Groth wrote:
Jörg wrote:
I assume the documentation build process needs sphinx, is that correct? If so it might be easiest to factor out a documentation into a separate python2-kwant-doc package.
Indeed, and that's why we separate the two for Debian as well. There's python-kwant, and python-kwant-doc.
Also, could you please have a look at http://kwant-project.org/install#arch-linux and let me know if something could be improved there?
Yes! I forgot that in my last mail, a notice with which PGP key you make signatures and that this key needs to be added to the keyring of the user building the package would be most helpful.
I don't have any experience with Arch, so it would be most helpful if you could write a few sentences yourself that we could then include into the instructions.
Christoph
-
Christoph Groth -
Jörg Behrmann -
Michael Wimmer