env python3.5: no such file or directory

The dependency conflicts may require a lot of time to resolve. On the contrary, uninstalling old software is easy, but it might lead to multiple broken programs and strange errors. Here is one of them, after removing the old python 3.4 and 3.5 (or whatever version it prints in your case) under Gentoo despite the rebuilding all dependencies as required by the emerge command for the new python 3.6 an error occurred trying to emerge the “app-misc/geoclue-2.5.3-r2

[20/75] /usr/lib/python-exec/python3.6/meson --internal exe --unpickle /var/tmp/portage/app-misc/geoclue-2.5.3-r2/work/geoclue-2.5.3-build/meson-private/meson_exe_glib-mkenums_af4feac41c42ec7289410f8b20070c0528a3a7c0.dat
FAILED: public-api/gclue-enum-types.c 
/usr/lib/python-exec/python3.6/meson --internal exe --unpickle /var/tmp/portage/app-misc/geoclue-2.5.3-r2/work/geoclue-2.5.3-build/meson-private/meson_exe_glib-mkenums_af4feac41c42ec7289410f8b20070c0528a3a7c0.dat
/usr/bin/env: âpython3.5â: No such file or directory
ninja: build stopped: subcommand failed.
 * ERROR: app-misc/geoclue-2.5.3-r2::gentoo failed (compile phase):
 *   ninja -v -j15 -l14 -C /var/tmp/portage/app-misc/geoclue-2.5.3-r2/work/geoclue-2.5.3-build failed
 * Call stack:
 *     ebuild.sh, line  125:  Called src_compile
 *   environment, line 2847:  Called meson_src_compile
 *   environment, line 1904:  Called eninja '-C' '/var/tmp/portage/app-misc/geoclue-2.5.3-r2/work/geoclue-2.5.3-build'
 *   environment, line 1274:  Called die
 * The specific snippet of code:
 *       "$@" || die "${nonfatal_args[@]}" "${*} failed"

Despite the lines starting with “/usr/lib/python-exec/python3.6/meson”, there is an error for missing “python 3.5“.

Here is another example, just trying to execute the distcc-config and it immediately throws the error for missing “python 3.5“.

root@srv ~ # distcc-config 
/usr/bin/env: ‘python3.5’: No such file or directory

The python script distcc-config starts with:

root@srv ~ $ head /usr/bin/distcc-config
#!/usr/bin/env python3.5
# Copyright 1999-2018 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

import os, re, signal, subprocess, sys


Apparently, multiple programs use this technic to explicitly put a specific version of python in the header of the python script to be used. Thus grantees the version in the header will be used even you change the system or user-preferred Python interpreter.

But uninstalling this python version all these programs will stop working till you rebuild them with emerge.
Keep on reading!

Gentoo emerge: Failed Running automake

This article is for Gentoo build problem:

Failed Running automake

but basically the problem could occur in any Linux system and the solution is logically the same.
During our @world update our emerge failed on:

>>> Emerging (44 of 95) dev-libs/libmemcached-1.0.18-r3::gentoo
 * libmemcached-1.0.18.tar.gz BLAKE2B SHA512 size ;-) ...                                                                                                            [ ok ]
>>> Unpacking source...
>>> Unpacking libmemcached-1.0.18.tar.gz to /var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/work
>>> Source unpacked in /var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/work
>>> Preparing source in /var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/work/libmemcached-1.0.18 ...
 * Applying debug-disable-enable-1.0.18.patch ...                                                                                                                    [ ok ]
 * Applying continuum-1.0.18.patch ...                                                                                                                               [ ok ]
 * Applying libmemcached-1.0.18-gcc7.patch ...                                                                                                                       [ ok ]
 * Running eautoreconf in '/var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/work/libmemcached-1.0.18' ...
 * Running libtoolize --install --copy --force --automake ...                                                                                                        [ ok ]
 * Running aclocal -I m4 -I libtest/m4 ...                                                                                                                           [ ok ]
 * Running autoconf --force ...                                                                                                                                      [ ok ]
 * Running autoheader ...                                                                                                                                            [ ok ]
 * Running automake --add-missing --copy --foreign --force-missing ...                                                                                               [ !! ]

 * Failed Running automake !
 * Include in your bugreport the contents of:
 *   /var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/temp/automake.out

 * ERROR: dev-libs/libmemcached-1.0.18-r3::gentoo failed (prepare phase):
 *   Failed Running automake !
 * Call stack:
 *     ebuild.sh, line  124:  Called src_prepare
 *   environment, line 2214:  Called eautoreconf
 *   environment, line  714:  Called eautomake
 *   environment, line  668:  Called autotools_run_tool 'automake' '--add-missing' '--copy' '--foreign' '--force-missing'
 *   environment, line  532:  Called die
 * The specific snippet of code:
 *           die "Failed Running $1 !";
 * If you need support, post the output of `emerge --info '=dev-libs/libmemcached-1.0.18-r3::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=dev-libs/libmemcached-1.0.18-r3::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/temp/environment'.
 * Working directory: '/var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/work/libmemcached-1.0.18'
 * S: '/var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/work/libmemcached-1.0.18'

>>> Failed to emerge dev-libs/libmemcached-1.0.18-r3, Log file:

We have installed automake, the dependency is OK, there is no need of new version of automake (the libmemcached did not required to install a new version as a dependency), but still the build process failed!
automake has many different versions installed on the same system and the problem is that one of your currently installed version is too old, so you must upgrade all versions (from the all different branches installed).
First check what versions are installed (equery is part of app-portage/gentoolkit):

root@srv ~ # equery list automake
 * Searching for automake ...
[I--] [??] sys-devel/automake-1.11.3:1.11
[I--] [??] sys-devel/automake-1.12.6:1.12
[I--] [??] sys-devel/automake-1.13.4:1.13
[I--] [??] sys-devel/automake-1.14.1:1.14
[IP-] [  ] sys-devel/automake-1.15.1-r2:1.15
[IP-] [  ] sys-devel/automake-1.16.1-r1:1.16

We have version from branch 1.11, 1.12, 1.13 and 1.14 – one of these version is causing the problem!
Up until now no package required as a dependency 1.15 and 1.16, so we do not have it installed.

Here we upgrade them all to their latest versions in every branch version:

root@srv ~ # emerge -vu sys-devel/automake:1.11 sys-devel/automake:1.12 sys-devel/automake:1.13 sys-devel/automake:1.14

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U  ] sys-devel/automake-1.12.6-r2:1.12::gentoo [1.12.6:1.12::gentoo] USE="-test%" 1368 KiB
[ebuild     U  ] sys-devel/automake-1.11.6-r3:1.11::gentoo [1.11.3:1.11::gentoo] USE="-test%" 896 KiB
[ebuild     U  ] sys-devel/automake-1.14.1-r2:1.14::gentoo [1.14.1:1.14::gentoo] USE="-test%" 1455 KiB
[ebuild     U  ] sys-devel/automake-1.13.4-r2:1.13::gentoo [1.13.4:1.13::gentoo] USE="-test%" 1416 KiB

Total: 4 packages (4 upgrades), Size of downloads: 5133 KiB

As you can see we have updated version in every branch! And after updating them the building of libmemcached passed smoothly!
It’s not only in Gentoo, in most Linux distros (such as Ubuntu, CentOS, Manjaro, Mint and so on) have multiple automake version installed, so if you encounter this problem check your automake version installed for their latest versions and also if you miss some of them.

Gentoo update tips when updating packages with blocks and masked files

It’s not so rear to have

blocks or masked files

when using Gentoo emerge system, but it is not complex and in most cases it is easy to resolve

To summarize it up at the beginning and then we are going to show you other articles using these advises here where you’ll see what are the steps we took to resolve the conflicts and masked packages:

  • Use verbose,verbose-conflicts and backtrack with emerge
  • Remove only big GUI packages, which have really big dependency graph like office suites or development IDEs
  • Remove obsolete packages – you do not need them, they can just make problems when updating, because emerge will take into consideration their requirements and dependencies and your update could be impossible!
  • Do not update everything with one line, you could update only the base libraries like QT, which are very important for the Linux GUI in general
  • Include explicitly packages, which block our updates in the emerge line! You could specify packages with the versions.
  • use tools like “equery” (part of app-portage/gentoolkit) for checking dependencies and/or which packages depend on the queried package. You can use it with specific version for the package. “qlist” (part of app-portage/portage-utils) also is a handful tool.
  • Sometimes when updating a group or a package with big dependency graph it is much easier to drop the -“u” update argument and to rebuild some packages with the updates.
  • In rear cases you can use “–nodeps” when updating or installing a new package (we do not need and show this one here!)
  • Do NOT rebuild the entire system with “emerge -v world” every time when you rebuild glibc, gcc, it is not mandatory to do it to have a healthy system.
  • Add or remove USE flags if needed – emerge will show you information about it. Use package.use, package.mask, package.unmask and so on.
  • use qlist to update/re(build) to pull currently installed packages with some name or category (categories)
    emerge -v $(qlist -IC|grep <NAME>)

    and for update just add “u” to “-v”:

    emerge -vu $(qlist -IC|grep <NAME>)

Keep on reading!