Hi there. Attached to this bug is py-gnupg-0.3.2.ebuild, and ebuild I made for a py-gnupg which is a python interface to GnuPG. A pretty useful tool to enable python apps to talk to GnuPG. The logical place for this seems to be dev-python/py-gnupg. The homepage for this module is http://py-gnupg.sourceforge.net/. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 9047 [details] py-gnupg-0.3.2.ebuild The ebuild
Comment on attachment 9047 [details] py-gnupg-0.3.2.ebuild # Copyright 1999-2003 Gentoo Technologies, Inc. # Distributed under the terms of the GNU General Public License v2 # $Header: $ DESCRIPTION="A Python module to interface with GnuPG." HOMEPAGE="http://py-gnupg.sourceforge.net/" # Point to any required sources; these will be automatically downloaded by # Portage. SRC_URI="mirror://sourceforge/py-gnupg/GnuPGInterface-0.3.2.tar.gz" LICENSE="LGPL-2.1" SLOT="0" KEYWORDS="~x86 ~ppc ~sparc ~sparc64 ~alpha" IUSE="" DEPEND="virtual/python >=gnupg-1.2.1-r1" #Unzipped dirname DIRNAME="GnuPGInterface-0.3.2" S=${WORKDIR}/${DIRNAME} src_compile() { python setup.py build || die } src_install() { python setup.py install --root=${D} || die }
Reassigning bugs due to lack of time.
Created attachment 17705 [details] py-gnupg-0.3.2.ebuild I used "inherit distutils" and deleted the src_compile and src_install funcs, set the DOCS var to add some documentation that wasn't being installed. Alastair, I tested this and it works. I've used this in a previous project of mine and it performed well.
thanks. i've committed this now. Rob, just a couple of things. I prefer the DOCS variable to be at the bottom, because the package metadata stuff should be at the top of the ebuild. Also, only put in the archs that you've tested for. I know that for python modules they "should" work on all archs, but it is best to be sure. Finally, one of the deps was missing a category. But those are all minor issues, otherwise the ebuild was good.
Ok, that clears up my arch question I was going to ask next time we talked. I know the developer docs say to only put in the arch you tested it on, but I wasn't sure if we should ask the user if they actually tested the ebuild on all the archs they submitted. On the DOCS location, I'm not sure what you mean about the metadata. This metadata? http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-python/py-gnupg/metadata.xml?rev=1.1&content-type=text/vnd.viewcvs-markup Would the optimal variable locations be: Custom variables (MY_P etc.) Default variables DOCS for just about every Python ebuild?
