As per bug #610008 , the kernel-2 eclass incorrectly uses python-any-r1. Before I fix that, I need the ebuilds who support the deblob script to make some changes. For reference: https://wiki.gentoo.org/wiki/Project:Python/python-any-r1 Add PYTHON_COMPAT=( pythonX_X pythonX_Y ) for the particular python versions supported e.g. PYTHON_COMPAT=( python3_5 ) Add python-any-r1 to lists of inherited ebuilds. e.g. inherit kernel-2 python-any-r1 Add PYTHON_DEPS to the DEPEND variable e.g. DEPEND+=" deblob? ( ${PYTHON_DEPS} )" Call python-any-r1_pkg_setup in pkg_setup e.g. pkg_setup() { use deblob && python-any-r1_pkg_setup }
Couple points of clarification: > I need the ebuilds who support the deblob script to make some changes. Unless I took the time to audit / read / understand the deblob feature of kernel-2 eclass, saying that I support it is probably wrong: Its presence is more of a legacy feature, and if it would mean adding or testing particular python versions for the sake of compatibility testing, I'd rather not. > PYTHON_COMPAT=( python3_5 ) I can add (and test) python3_4, since 3.4.5 is the primary one I have locally, with fallback to python2_7, but otherwise if it's going to require personally testing against multiple python versions the most likely result with this bug will be removal of deblob feature until such time as the refactored kernel-2 eclass is re-stabilized and the changes for usage (and the nature of python dependency for deblob) is better documented.
Because it's a python-related issue, I won't be supporting this. As compromise, if a co-maintainer opted to rescue this particular feature and take full responsibility for any python-specific implementation details, this is acceptable. If a future version of kernel-2 eclass transparently exposes a deblob feature without python-specific configuration requirements, I'll consider re-inclusion of the deblob feature. However, in this (current) form, it's a hard limit. I'm experienced with my own workflow, and know myself well enough to know that python is my kryptonite, and as such I have a zero tolerance policy for doing work in this language. Not negotiable.
As the co-maintainer of this package, I will handle all the python stuff
(In reply to Mike Pagano from comment #0) > As per bug #610008 , the kernel-2 eclass incorrectly uses python-any-r1. > Before I fix that, I need the ebuilds who support the deblob script to make > some changes. > > For reference: https://wiki.gentoo.org/wiki/Project:Python/python-any-r1 > > Add PYTHON_COMPAT=( pythonX_X pythonX_Y ) for the particular python versions > supported > > e.g. > > PYTHON_COMPAT=( python3_5 ) > > Add python-any-r1 to lists of inherited ebuilds. > e.g. > > inherit kernel-2 python-any-r1 > Shouldn't kernel-2 be inherited the last? > Add PYTHON_DEPS to the DEPEND variable > > e.g. > > DEPEND+=" deblob? ( ${PYTHON_DEPS} )" > > Call python-any-r1_pkg_setup in pkg_setup > > e.g. > > pkg_setup() { > use deblob && python-any-r1_pkg_setup > } Shouldn't we call "kernel-2_pkg_setup" here?
Just a heads-up, python3_4 seems like a no go, the deblob script silently fails: drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c: disabled non-Free firmware-loading machinery Traceback (most recent call last): File "/var/tmp/portage/sys-kernel/ck-sources-4.10.0/temp/deblob-check-script-wWUpsl", line 48, in <module> for line in sys.stdin: File "/usr/lib64/python3.4/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1298: ordinal not in range(128) ERROR: failed removing blobs from drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c cmp: EOF on drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c.deblob It does work with python2_7
commit 23f7b4dbcab1a11d46822ed3c40ebf222d1434cd Author: Göktürk Yüksek <gokturk@gentoo.org> Date: Fri Feb 24 03:25:37 2017 -0500 sys-kernel/ck-sources: correctly use python to support deblob #610620 Package-Manager: portage-2.3.0
(In reply to Göktürk Yüksek from comment #3) > As the co-maintainer of this package, I will handle all the python stuff Thanks for stepping up, Göktürk
