Bug 698236 – media-libs/shaderc-2019.0 - CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find PythonInterp: Found unsuitable version "2.7.16", but required is at least "3" [...]

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Marek Bartosiewicz 2019-10-22 07:00:39 UTC]

media-libs/shaderc-2019.0 configure fails, python version 3 required, seems that it finds version 2.7 instead:

>>> Emerging (1 of 1) media-libs/shaderc-2019.0::gentoo
>>> Failed to emerge media-libs/shaderc-2019.0, Log file:
>>>  '/var/tmp/portage/media-libs/shaderc-2019.0/temp/build.log'
>>> Jobs: 0 of 1 complete, 1 failed                 Load avg: 1.20, 0.81, 0.34
 * Package:    media-libs/shaderc-2019.0
 * Repository: gentoo
 * Maintainer: [e-mail]
 * USE:        abi_x86_64 amd64 elibc_glibc kernel_linux userland_GNU
 * FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox
>>> Unpacking source...
>>> Unpacking shaderc-2019.0.tar.gz to /var/tmp/portage/media-libs/shaderc-2019.0/work
>>> Source unpacked in /var/tmp/portage/media-libs/shaderc-2019.0/work
>>> Preparing source in /var/tmp/portage/media-libs/shaderc-2019.0/work/shaderc-2019.0 ...
 * Applying shaderc-2019.0-fix-glslang-link-order.patch ...
 [ ok ]
 * Hardcoded definition(s) removed in CMakeLists.txt:
 *    set(CMAKE_BUILD_TYPE "Debug")
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/media-libs/shaderc-2019.0/work/shaderc-2019.0 ...
 * abi_x86_64.amd64: running multilib-minimal_abi_src_configure
>>> Working in BUILD_DIR: "/var/tmp/portage/media-libs/shaderc-2019.0/work/shaderc-2019.0-abi_x86_64.amd64"
cmake -C /var/tmp/portage/media-libs/shaderc-2019.0/work/shaderc-2019.0-abi_x86_64.amd64/gentoo_common_config.cmake -G Unix Makefiles -DCMAKE_INSTALL_PREFIX=/usr -DSHADERC_SKIP_TESTS=yes -DCMAKE_BUILD_TYPE=Gentoo -DCMAKE_TOOLCHAIN_FILE=/var/tmp/portage/media-libs/shaderc-2019.0/work/shaderc-2019.0-abi_x86_64.amd64/gentoo_toolchain.cmake  /var/tmp/portage/media-libs/shaderc-2019.0/work/shaderc-2019.0
loading initial cache file /var/tmp/portage/media-libs/shaderc-2019.0/work/shaderc-2019.0-abi_x86_64.amd64/gentoo_common_config.cmake
-- The C compiler identification is GNU 9.2.0
-- The CXX compiler identification is GNU 9.2.0
-- Check for working C compiler: /usr/bin/x86_64-pc-linux-gnu-gcc
-- Check for working C compiler: /usr/bin/x86_64-pc-linux-gnu-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/x86_64-pc-linux-gnu-g++
-- Check for working CXX compiler: /usr/bin/x86_64-pc-linux-gnu-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Shaderc: build type is "Gentoo".
-- Configuring Shaderc to avoid building tests.
-- nosetests was not found - python code will not be tested
-- asciidoctor was not found - no documentation will be generated
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find PythonInterp: Found unsuitable version "2.7.16", but
  required is at least "3" (found
  /var/tmp/portage/media-libs/shaderc-2019.0/temp/python2.7/bin/python)
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:376 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake/Modules/FindPythonInterp.cmake:166 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  cmake/setup_build.cmake:46 (find_package)
  CMakeLists.txt:34 (include)


-- Configuring incomplete, errors occurred!


---------------------


eselect python list
Available Python interpreters, in order of preference:
  [1]   python3.7
  [2]   python3.6
  [3]   python2.7 (fallback)


Reproducible: Always

[Comment 1 Paolo Pedroni 2019-10-22 08:27:41 UTC]

I can confirm this.

[Comment 2 Jason Chan 2019-10-22 09:32:04 UTC]

I have the same error and order of Python interpreters as Marek Bartosiewicz.

In shaderc-2019.0.ebuild, changing:

PYTHON_COMPAT=( python{2_7,3_5,3_6} )

to

PYTHON_COMPAT=( python{3_5,3_6,3_7} )

fixes it.

[Comment 3 Marek Bartosiewicz 2019-10-22 10:57:44 UTC]

Thanks.

[Comment 4 Daniel Pielmeier 2019-10-22 20:51:56 UTC]

Nick any reason for bumping this straight to stable?

[Comment 5 Larry the Git Cow 2019-10-22 22:34:34 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=01424b087422771bf89941c77d681a4e60ecf74a

commit 01424b087422771bf89941c77d681a4e60ecf74a
Author:     Mike Lothain <[e-mail]>
AuthorDate: 2019-10-22 11:58:00 +0000
Commit:     Nick Sarnie <[e-mail]>
CommitDate: 2019-10-22 22:32:20 +0000

    media-libs/shaderc-2019.0 Remove python2 support
    
    This app errors when using python2, add python 3.7 too
    
    Signed-off-by: Mike Lothian <[e-mail]>
    Fixes: https://bugs.gentoo.org/show_bug.cgi?id=698236
    Closes: https://github.com/gentoo/gentoo/pull/13379
    Signed-off-by: Nick Sarnie <[e-mail]>

 media-libs/shaderc/shaderc-2019.0.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[Comment 6 Nick Sarnie 2019-10-22 22:36:24 UTC]

@billie Sorry, that was obviously not intentional. I've dropped this to testing now.

You can see in b80df046136e8783bb48b2fe244f42a17cbd0d3e that I used repoman by Package-Manager: Portage-2.3.78, Repoman-2.3.17

I have absolutely no idea why repoman didn't catch it this time, it has in the past.

[Comment 7 Daniel Pielmeier 2019-10-23 06:24:49 UTC]

(In reply to Nick Sarnie from comment #6)
> @billie Sorry, that was obviously not intentional. I've dropped this to
> testing now.
> 
> You can see in b80df046136e8783bb48b2fe244f42a17cbd0d3e that I used repoman
> by Package-Manager: Portage-2.3.78, Repoman-2.3.17
> 
> I have absolutely no idea why repoman didn't catch it this time, it has in
> the past.

Strange I did a quick test and I was notified about bumping straight to stable. However I am using stable repoman 2.3.16 while you are on testing 2.3.17.

Maybe you should test also with stable repoman. If it works then there is probably a bug in 2.3.17 which should be reported.

[Comment 8 Nick Sarnie 2019-10-23 22:25:27 UTC]

I can't reproduce it either.

Clearly that is what happened, because the only other way to commit straight to stable would be with --force (assuming no manual commit editing), and that adds a record of that in the commit message.


No idea.