- If this package can be used as a library and installs Python modules (*.so or *.py) into site-packages directories, then consider supporting installation for multiple Python versions. Please read section "Types of packages" in documentation [1] to decide if this package can support installation for multiple Python versions. - Ensure that the ebuilds do not use deprecated functions or variables. - Please check if Python 3 is supported by this package. You can temporarily set Python 3 as main active version of Python to properly test if this package supports Python 3. - If this package does not support Python 3: - Specify dependency on Python 2. You can use PYTHON_DEPEND helper variable, which should be set before inheriting of python eclass. Please read section "Specification of dependency on Python" in documentation [1]. - If this package cannot support installation for multiple versions of Python, then set active version of Python using python_set_active_version(). - Ensure that shebangs in installed scripts specify correct version of Python. If shebangs are too generic (e.g. '#!/usr/bin/python'), then you can use python_convert_shebangs() to convert shebangs. (Wrapper scripts generated by python_generate_wrapper_scripts() do not require any changes.) Please read section "Shebangs in installed scripts" in documentation [1]. - To ensure that changes applied to the ebuilds are sufficient, please temporarily set Python 3 as main active version of Python and test if this package can be properly installed and if it works at run time. Please see documentation [1] for more details. [1] http://www.gentoo.org/proj/en/Python/developersguide.xml
sys-libs/cracklib-2.8.16 fails to build with Python 3.
So howabout providing patch here for review. One restricted with python-2.
no log, so i'm going to guess you're talking about the install failure. it builds just fine. it's coming from the local py-compile file from python-2.x. might be fixed by converting to distutils. ... File "<string>", line 6 print 'Byte-compiling python modules...' ^ SyntaxError: invalid syntax make[2]: *** [install-pythonPYTHON] Error 1 as for fixing that file, i have no idea. i dont know what's wrong with it wrt python-3 syntax.
Created attachment 233809 [details] build.log it fails if python-3 was installed and eselected as system compiler... I'll try to add patch for this failure soon.
Created attachment 233811 [details, diff] cracklib-2.8.16.ebuild-python-cleanup.fixes.patch This patch fixes the problem. As I did some clenup as we go, small summary of python related changes: 1. inherit python 2. set DEPEND through eclass with PYTHON_DEPEND="python? 2" 3. python_set_active_version 2 This also fixes bug 302908. This package works only with python-2 and thus fix that was suggested in bug 302908 is incorrect and I've dropped it: - sed -i '/PYTHON/s:\(print\) \([^"]*\):\1(\2):' configure #302908 It's interesting to note, that after this fix was introduced, on 08 Mar 2010 Zac Medico specified <python-3 but forgot to drop this sed... Please review and either commit or give me Ok to commit. Should I bump revision during bump?
the die w/dodoc is crap. otherwise, tweaking the python behavior doesnt really matter to me as i never used it. feel free to commit once the dodoc thing is fixed.
(In reply to comment #6) > the die w/dodoc is crap. Why? It does not fail on it's own...
(In reply to comment #7) > (In reply to comment #6) > > the die w/dodoc is crap. > > Why? It does not fail on it's own... > || die is for functions that prevent cracklib (or any other ebuild) from working, docs don't fall into that category (as in, it will work fine even if ChangeLog is missing)
nor should it. blocking an otherwise perfectly fine install due to what largely amount to useless noise no one reads is stupid. if something goes wrong with the dodoc, we'll eventually see a bug, but there's absolutely no reason to screw over end users in the mean time.
Nixing the ||die sounds reasonable to me. Otherwise, looks like that patch fixes a lot of stuff The Right Way. Thanks, Peter, for your work on this and on the related bug 302908 that I reported.
It's better to not build static versions of Python modules instead of building them and later removing them.
Created attachment 233867 [details, diff] cracklib-2.8.16.ebuild.patch It's better to use distutils. It allows to easily support installation for multiple Python ABIs and avoids building of static versions of Python modules.
sticking one statement in an if block is lame. do `use python && foo` instead. if you arent going to use the bundled python logic anymore, then the python linking patch probably can be dropped too.
Hm, the ebuild should be tested by the maintainer, not the end user. Since it's no LiveCVS ebuild, the existence/absence of an ChangeLog is pretty determined. Anyway, one of these patched should go into the tree, a flame war about `|| die` or not `|| die` doesn't solve any bug.
Created attachment 233971 [details, diff] cracklib-2.8.16.ebuild.patch (In reply to comment #13) I'm attaching updated patch.
(In reply to comment #15) > Created an attachment (id=233971) [details] > cracklib-2.8.16.ebuild.patch > > (In reply to comment #13) > > I'm attaching updated patch. > You can't drop elibtoolize when there's library that gets installed, and ~x86-fbsd in KEYWORDS because it's also to get sane .so versioning for g/fbsd.
Created attachment 233975 [details, diff] cracklib-2.8.16.ebuild.patch
Michael: unless you have something useful to add, please refrain from commenting Arfrever: i dont know why you changed the quoting/slash style used with `rm` in the src_install, but the old way was correct. otherwise that new patch looks OK.
(In reply to comment #18) > Michael: unless you have something useful to add, please refrain from > commenting point taken. I am concerned about all these patches adding sys-libs/zlib, a member of the system list, defined in line 67 of /usr/portage/profiles/base/packages, to the *DEPEND. Isn't that redundant?
(In reply to comment #19) > (In reply to comment #18) > > Michael: unless you have something useful to add, please refrain from > > commenting > point taken. > > I am concerned about all these patches adding sys-libs/zlib, a member of > the system list, defined in line 67 of /usr/portage/profiles/base/packages, to > the *DEPEND. Isn't that redundant? > no. "or example, the embedded profile doesn't have zlib in system target" [1] [1] http://devmanual.gentoo.org/general-concepts/dependencies/index.html#implicit-system-dependency as in, it's always best to define the exact dependencies.
(In reply to comment #18) > Arfrever: i dont know why you changed the quoting/slash style used with `rm` in > the src_install, but the old way was correct. otherwise that new patch looks > OK. I committed the patch without change in quoting/slash style.
Created attachment 234115 [details, diff] cracklib-2.8.16.ebuild.patch And another patch for review: use do_python to make code a bit clearer. Is this good idea to apply?
(In reply to comment #22) It would cause problems for people who grep ebuilds for distutils_src_prepare() etc.
screw em, i like that patch and it addresses a complaint i did not vocalize as i lacked an idea for a better way. Peter: please 2 apply.
