List of ports with "python 3" errors in poudriere

[Marcus von Appen]

Kubilay Kocak <koobs.freebsd at gmail.com>:

> On 29/10/2013 8:18 PM, Marcus von Appen wrote:
>>
>> John Marino <freebsd.contact at marino.st>:
>>
>>> Per IRC conversation with mva, I'm sending python@ a list of ports that
>>> currently don't build in DragonFly poudriere due to ports infrastructure
>>> problems.  I have not changed the python default in make.conf.  It would
>>> be nice to get Mk/bsd.python.mk (or whatever) fixed so these ports build
>>> in poudriere again.  Thanks, John
>>>
>>
>> [broken ports]
>>
>> There are several more (e.g. graphics/blender), which suffer from the
>> same issue.
>> For those, who wonder what is going wrong here:
>>
>> The interim hack in bsd.python.mk, which always causes ports to pull in
>> lang/python, if USE_PYTHON[_XXX] is set, is the problem. As some know, I am
>> currently testing all ports for that problem and am making lang/python a
>> dependency
>> on the port, rather than being implicitly set by bsd.python.mk.
>> Once done, the ports themselves will need to be fixed to use the proper
>> python version
>> rather than lang/python, so we can build version-specific packages.
>>
>> Long story short: No port should depend on lang/python at build and
>> installation time
>> as a mid-term goal.
>>
>> For those with too much free time at their hands: feel free to go
>> through John's list
>> and fix the ports to use a proper python version at build time instead
>> of `python` :-).
>>
>> Cheers
>> Marcus
>>
>>
>> _______________________________________________
>> freebsd-python at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-python
>> To unsubscribe, send any mail to "freebsd-python-unsubscribe at freebsd.org"
>
> Thanks for the explanation marcus.
>
> Can we get that list submitted as a PR, with clear instructions on the
> fix procedure? Maybe even an example fix to help motivate

Let me create a rough step-by-step example:

1) Use a tinderbox, poudriere or own jail

2) Grab a svn copy of the ports tree

3) Build the problematic port (to build all dependencies flawlessly)

4) Remove the python:${PORTSDIR}/lang/python entry from bsd.python.mk
   (around line 583 and line 590)

5) Build the problematic port again (the dependencies ideally should
   exist, so they won't cause problems with the missing python symlinks)

4.1) If the port fails due to `python` not being around, fix up the
       offending parts:
       a) by replacing them with ${PYTHON_CMD} (preferred)
       b) by replacing them with python2 or python3

5) If the port builds successfully now, check the USE_PYTHON[_XXX] line:
    a) if it uses USE_PYTHON[_XXX]= yes, change it to a proper version
       line, either the (only) version it builds with or a version range
       (see step 6)

6) Check the installed scripts of the port (stuff that goes into bin/ or
     share or so) or other functional parts that might be executed directly
     from the shell

     a) for the shebang usage of `python`
        i)  is the port compatible with all python versions?
            if yes: great, revise the settings of 5)
            if no: duh, revise the settings of 5) and restrict them
        ii) change `python` to a proper major or major.minor version
            in the script

     b) if the scripts are used by other ports as build dependency
        i) are they invoked with the correct commands by the relevant port?
           e.g `${PYTHON_CMD} depscript.py` instead of `python depscript.py`
               or ${LOCALBASE}/bin/depscript.py instead of `python ... `
           and so on
        ii) fix the dependent port on demand to invoke the scripts correctly

Step 4 to 6 will also be the main tasks, once the lang/python lines has been
officially removed from bsd.python.mk to check for functional issues with
ports, even if the build and install cleanly.

> I think this is a perfect opportunity to share the load, and I'll put my
> hand up to help.
>
> Some clarity/confirmation included in the PR for the following would
> also be great:
>
> - Can these be fixed *now* or is there something that needs to be done
> first?

That depends on the ports themselves, their functionality and behaviour as
dependencies for other ports. My infamous example of gtk20 would fit
here quite well.
gtk20 comes with a script gtk-builder-convert (or so), which uses a
simple /usr/bin/env python shebang, which gnome ports rely on (they
just fire up the script at their build stage) - those flaws (which can
happen for nearly every port) are hard to detect and will need manual
intervention here and there to evaluate and fix the issues.

Cheers
Marcus