Tag: emerge

Gentoo – updating perl and problems like perl-core/ is blocking virtual/perl-

When upgrading Perl under Gentoo it’s almost typical to have blocks of the kind:

[blocks B      ] <perl-core/File-Path-2.160.0 ("<perl-core/File-Path-2.160.0" is blocking virtual/perl-File-Path-2.160.0)
[blocks B      ] <perl-core/Module-CoreList-5.201.905.220 ("<perl-core/Module-CoreList-5.201.905.220" is blocking virtual/perl-Module-CoreList-5.201.905.220)
[blocks B      ] <perl-core/Archive-Tar-2.320.0 ("<perl-core/Archive-Tar-2.320.0" is blocking virtual/perl-Archive-Tar-2.320.0)

These blocks appeared when we tried updaring the Perl 5.26 to 5.30 (dev-lang/perl-5.30.0:0/5.30::gentoo from dev-lang/perl-5.26.2:0). This update is a major update.
So what does it mean?
The virtual package and the perl-core package should be the same version, but it appears there are no corresponding same versions to the virtual package versions (). The problem is that the update depends on a newer version of File-Path, Module-CoreList, and Archive-Tar but there are only virtual packages with the required versions. Virtual packages are just meta-packages and they do not install any module. First, what are the virtual/[perl-module] and perl-core/[perl-module]:

  • perl-core/[perl-module] – perl independent modules. In fact, the same module may be independent and it may be part of the build-in packages from the Perl main package – dev-lang/perl. Sometimes you may choose the independent package, because of a newer version than the version included in the dev-lang/perl package.
  • virtual/[perl-module] – perl meta-package, which ensures the installation of the module. The module could be an independent package from above or module, which is included in the main Perl package (in dev-lang/perl)

To solve the blocks of this kind “perl-core/ is blocking virtual/perl-” you must check for a newer version of perl-core/* if there is no newer version, just to remove the package and let the setup (emerge) use the module included in dev-lang/perl.

In our case, there are no newer versions of the three packages and we remove them with:

emerge -Cv perl-core/File-Path perl-core/Module-CoreList perl-core/Archive-Tar

And then emerge with no problems the new version of Perl with:

emerge --verbose --verbose-conflicts --backtrack=200000 $(qlist -IC|grep perl|sort|uniq) media-gfx/inkscape media-gfx/imagemagick dev-php/pecl-imagick

For detail explaination of why we use verbose-conflicts, backtrack, qlist and three excplicitly added packages you may read our article on similar subject – Gentoo updating perl with many masked and blocked packages
You may read the offcial documentation for more information – https://wiki.gentoo.org/wiki/Perl#Introduction

Updating our Perl from dev-lang/perl-5.26.2:0 to dev-lang/perl-5.30.0:0/5.30

Keep on reading!

emerge – ERROR: 17.1 migration has not been performed – upgrade from 13 to 17.1

When upgrading to 17.1 profile you need to perform additional steps to get to a healthy Gentoo portage system using profile 17.1.
Here what we stumbled when we tried to upgrade from 13 to 17.1:

>>> Emerging (1 of 3) dev-libs/elfutils-0.177::gentoo
 * Fetching files in the background.
 * To view fetch progress, run in another terminal:
 * tail -f /var/log/emerge-fetch.log
 * elfutils-0.177.tar.bz2 BLAKE2B SHA512 size ;-) ...                                                                                                                [ ok ]
 * Please follow the instructions in the news item:
 * 2019-06-05-amd64-17-1-profiles-are-now-stable
 * or choose the 17.0 profile.
 * ERROR: dev-libs/elfutils-0.177::gentoo failed (setup phase):
 *   ERROR: 17.1 migration has not been performed!!
 * 
 * Call stack:
 *        ebuild.sh, line 591:  Called __source_all_bashrcs
 *        ebuild.sh, line 410:  Called __try_source '/usr/portage/profiles/default/linux/amd64/17.1/profile.bashrc'
 *        ebuild.sh, line 467:  Called __qa_source '/usr/portage/profiles/default/linux/amd64/17.1/profile.bashrc'
 *        ebuild.sh, line 112:  Called source '/usr/portage/profiles/default/linux/amd64/17.1/profile.bashrc'
 *   profile.bashrc, line   6:  Called die
 * The specific snippet of code:
 *              die "ERROR: 17.1 migration has not been performed!!"
 * 
 * If you need support, post the output of `emerge --info '=dev-libs/elfutils-0.177::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=dev-libs/elfutils-0.177::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/dev-libs/elfutils-0.177/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-libs/elfutils-0.177/temp/die.env'.
 * Working directory: '/var/tmp/portage/dev-libs/elfutils-0.177/homedir'
 * S: '/var/tmp/portage/dev-libs/elfutils-0.177/work/elfutils-0.177'

As you can see there is news, which consists of 12 steps to perform a successful upgrade to profile 17.1.
You can read the news with (the news output is included at the end of this article, just for completeness):

eselect news read 28

Specific note for our upgrade – in fact, our Gentoo installation was a chroot and it had not been updated for three years. The profile was 13.0 and portage supported only EAPI 5, which is a real problem. The new portage tree (we installed the latest) has no profile 13.0 and our emerge was half broken. We have preliminary steps described in Failed to install sys-apps/portage – Called pkg_preinst – portage._compat_upgrade.default_locations

Because we upgrade from 13.0 to 17.1, first, we need to perform the 17.0 upgrade (check the original steps here – https://gentoo.org/support/news-items/2017-11-30-new-17-profiles.html)

STEP 1) Select the previous profile 17.0 temporarily.

srv ~ # eselect profile set default/linux/amd64/17.0

You won’t be able to build any GNU GCC and you cannot continue with the next step.

STEP 2) Upgrade to GNU GCC 6.4.0 or later.

Our current GNU GCC is really old – 4.9.3. The latest version is gcc-9.2.0-r1 and we are going to use it.
Keep on reading!

Failed to install sys-apps/portage – Called pkg_preinst – portage._compat_upgrade.default_locations

Recently there was a problem with one compute node servers, which Gentoo (in fact, the chroot environment had not been updated for 3 years) could not emerge the new portage because it kept failing in the pkg_preinst with:

srv ~ # USE="-rsync-verify" emerge -va '=sys-apps/portage-2.3.76::gentoo'
.....
.....
>>> Installing (1 of 1) sys-apps/portage-2.3.76::gentoo
 * checking 1999 files for package collisions
1000 files checked ...
^[[B>>> Merging sys-apps/portage-2.3.76 to /
/usr/bin/python2.7: No module named _compat_upgrade
 * ERROR: sys-apps/portage-2.3.76::gentoo failed (preinst phase):
 *   (no error message)
 * 
 * Call stack:
 *     ebuild.sh, line 133:  Called pkg_preinst
 *   environment, line 3238:  Called die
 * The specific snippet of code:
 *       env -u DISTDIR -u PORTAGE_OVERRIDE_EPREFIX -u PORTAGE_REPOSITORIES -u PORTDIR -u PORTDIR_OVERLAY PYTHONPATH="${D%/}${PYTHON_SITEDIR}${PYTHONPATH:+:${PYTHONPATH}}" "${PYTHON}" -m portage._compat_upgrade.default_locations || die;
 * 
 * If you need support, post the output of `emerge --info '=sys-apps/portage-2.3.76::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-apps/portage-2.3.76::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-apps/portage-2.3.76/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-apps/portage-2.3.76/temp/environment'.
 * Working directory: '/var/tmp/portage/._portage_reinstall_.RKkxLW/pym'
 * S: '/var/tmp/portage/sys-apps/portage-2.3.76/work/portage-2.3.76'
!!! FAILED preinst: 1

>>> Failed to install sys-apps/portage-2.3.76, Log file:

>>>  '/var/tmp/portage/sys-apps/portage-2.3.76/temp/build.log'

Note this is the installation phase, where everything from the build process passes smoothly, but it fails to install it with some vague error of a dying line with a couple of python and portage environments. The problem is the current portage does not support EAPI 6 and 7 and some packages were unable to be installed!

And we fixed the issue by just using the method described in our previous article – Fix your broken or old portage in Gentoo, fix the emerge command
Cloning a new portage software and using it to emerge (install) a newer (or reinstall the current) portage in the system to fix the system’s portage and the emerge command:

cd /root
git clone https://anongit.gentoo.org/git/proj/portage.git
/root/portage/bin/emerge --sync
eselect profile set default/linux/amd64/17.1
/root/portage/bin/emerge -v portage

Now the latest and stable Gentoo profile is 17.1, so we set it to be sure we use it (in future this may change).
Keep on reading!

Fix your broken or old portage in Gentoo, fix the emerge command

Using Gentoo for servers and chroots it might happen to deal with old and not regularly updated Gentoo environment, which in some cases is completely non-updatable using the regular process with emerge command. And no emerge means no installs from the Gentoo packaging system. Or you maybe have a broken portage after failed update with missing emerge command or missing or broken portage modules

In general, this article is for those, who cannot update their “sys-apps/portage” or even the emerge command exits with errors and is of no use.

In cases such as:

  • Missing portage files (broken portage)
  • Broken emerge command (broken portage)
  • no update of new portage is possible – very very old portage, which does not support EAPI of all current “sys-apps/portage” (now is EAPI=5) and you do not have old portage ebuild files
  • Easy update the portage to the newest in an old Gentoo system.

A real world errors are included at the bottom for each case above.

You need just a working python 2.7.x and git to clone “https://anongit.gentoo.org/git/proj/portage.git” or at least some tool to download the portage package.

Unpack to a globally accessible directory, DO NOT USE “/root“, because emerge changes user to non-privileges and needs execute permission for other for the all the path to the directory of emerge. Look below for more details.

Our example is to repair a completely broken portage with error:

srv ~ # emerge -va portage
Traceback (most recent call last):
  File "/usr/lib/python-exec/python2.7/emerge", line 42, in <module>
    import portage
ImportError: No module named portage

STEP 1) Clone the portage package from the git or download the portage tarball.

If you do not have a git client you can always check the URL in the sys-app/portage ebuild and download the URL. Still, if you cannot find the tarball’s URL, you can just simply get a mirror such as https://mirror.leaseweb.com/gentoo/distfiles, wait for the loading of the page (12Mbytes, it’s huge, all Gentoo tarball files’ names are here) and grep in it by the name “portage”. Or you can check here https://dev.gentoo.org/~zmedico/portage/archives/. Download the latest tarball and unpack it in the /opt directory.
Using git is the easiest method, but it is the same with downloading and unpacking the tarball in the “/opt”.

srv opt # git clone https://anongit.gentoo.org/git/proj/portage.git
Cloning into 'portage'...
remote: Enumerating objects: 151654, done.
remote: Counting objects: 100% (151654/151654), done.
remote: Compressing objects: 100% (39915/39915), done.
remote: Total 151654 (delta 112542), reused 149864 (delta 111349)
Receiving objects: 100% (151654/151654), 22.38 MiB | 550.00 KiB/s, done.
Resolving deltas: 100% (112542/112542), done.
srv opt # cd portage/
srv portage # ls -al
total 232
drwxr-xr-x. 11 root root  4096 Oct  6 04:52 .
drwx------.  4 root root  4096 Oct  6 04:51 ..
drwxr-xr-x.  6 root root  4096 Oct  6 04:52 bin
drwxr-xr-x.  5 root root  4096 Oct  6 04:52 cnf
-rw-r--r--.  1 root root  1840 Oct  6 04:52 COPYING
-rw-r--r--.  1 root root  6646 Oct  6 04:52 DEVELOPING
drwxr-xr-x.  5 root root  4096 Oct  6 04:52 doc
-rw-r--r--.  1 root root   200 Oct  6 04:52 .editorconfig
drwxr-xr-x.  7 root root  4096 Oct  6 04:52 .git
-rw-r--r--.  1 root root    80 Oct  6 04:52 .gitignore
drwxr-xr-x.  4 root root  4096 Oct  6 04:52 lib
-rw-r--r--.  1 root root 18092 Oct  6 04:52 LICENSE
-rwxr-xr-x.  1 root root  1272 Oct  6 04:52 make.conf.example-repatch.sh
drwxr-xr-x.  3 root root  4096 Oct  6 04:52 man
-rw-r--r--.  1 root root   290 Oct  6 04:52 MANIFEST.in
drwxr-xr-x.  2 root root  4096 Oct  6 04:52 misc
-rw-r--r--.  1 root root 17845 Oct  6 04:52 NEWS
-rw-r--r--.  1 root root     0 Oct  6 04:52 .portage_not_installed
-rw-r--r--.  1 root root  2246 Oct  6 04:52 README
-rw-r--r--.  1 root root 68122 Oct  6 04:52 RELEASE-NOTES
drwxr-xr-x.  6 root root  4096 Oct  6 04:52 repoman
-rwxr-xr-x.  1 root root  4889 Oct  6 04:52 runtests
-rwxr-xr-x.  1 root root 19743 Oct  6 04:52 setup.py
drwxr-xr-x.  2 root root  4096 Oct  6 04:52 src
-rwxr-xr-x.  1 root root    81 Oct  6 04:52 tabcheck.py
-rw-r--r--.  1 root root  1864 Oct  6 04:52 TEST-NOTES
-rw-r--r--.  1 root root   571 Oct  6 04:52 testpath
-rw-r--r--.  1 root root   348 Oct  6 04:52 tox.ini
-rw-r--r--.  1 root root   584 Oct  6 04:52 .travis.yml

This is the latest portage with working emerge command in the bin sub-directory.
Keep on reading!

emerge – cannot sync with gpg: keyserver refresh failed: General error because of wrong date

Trying to sync one of our virtual servers we got a sync error not able to refresh the OpenPGP keys. The virtual server was just resumed and it was OK before the pause. In addition, there were no errors in dmesg or some kind of kernel panics. All seemed to be working even the server was in the distributed compiling node and no problems there. But still, the emerge syncing the portage tree wasn’t possible!
And the problem was the date of our virtual server, which was 4 months behind the real date!

Check the time and date of the server – if it is behind or in the future with a big interval this is the root of the problems with the inability to refresh the GPG keys.

Just synchronize the clock of the server and be careful when you resume pause virtual servers! When you resume them you should synchronize the clock because in multiple environments the clock might be wrong!
We have multiple articles on the time syncronization topic – openntpd – immediately sync the clock on startup, simple time synchronization of a server (laptop, desktop) using built-in systemd-timesyncd service and more.

compile-local ~ # emerge --sync
>>> Syncing repository 'gentoo' into '/usr/portage'...
 * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
 * Refreshing keys from keyserver ...OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: General error

OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: General error

OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: General error

OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: General error

OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: General error

OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: General error

OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: General error

^C

Exiting on signal Signals.SIGINT
compile-local ~ # date
Sat 08 Apr 2019 15:11:39 PM -00
compile-local ~ # /etc/init.d/ntpd restart
 * Starting OpenNTPD ...                                                                                                                                              [ ok ]
compile-local ~ # date
Sun 01 Sep 2019 08:02:34 AM -00
compile-local ~ #

Keep on reading!

Gentoo kde-frameworks/kdewebkit failed compilation with Qt5WebKit could not be found because dependency is required

Updating the KDE Plasma Desktop in our Gentoo workstations this time failed with 

CMake Error at /usr/share/cmake/Modules/CMakeFindDependencyMacro.cmake:48 (find_package):
  Found package configuration file:

    /usr/lib64/cmake/Qt5WebKit/Qt5WebKitConfig.cmake

  but it set Qt5WebKit_FOUND to FALSE so package "Qt5WebKit" is considered to
  be NOT FOUND.  Reason given by package:

  Qt5WebKit could not be found because dependency is required to have exact
  version 5.11.x.

It was strange because the previous emerge included the QT upgrade from old 5.11.2 to 5.12.1 and this dependency should have been resolved properly before:

emerge -vau $(qlist -IC|grep dev-qt|sort|uniq)

But apparently despite that the emerge built all QT libraries in dependency order the “dev-qt/qtwebkit” was built against the old QT libraries. And this is what is saying the above error!

The solution is really simple just rebuild the dev-qt/qtwebkit

root@srv ~ # emerge -va dev-qt/qtwebkit

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

Calculating dependencies... done!
[ebuild   R    ] dev-qt/qtwebkit-5.212.0_pre20180120:5/5.212::gentoo  USE="X geolocation hyphen jit multimedia opengl printsupport qml -gles2 -gstreamer -nsplugin 
-orientation -webp" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] yes

Keep on reading!

portage is blocked by “the current version of portage supports EAPI ‘6’. You must upgrade”

We’ve synced the portage tree before upgrading our old portage package (big mistake! always upgrade the portage package before sync) and then do the sync. After the sync the portage upgrade was impossible, because a dependency package supported only a new portage API (probably a new package) in our case EAPI 7 and the offensive package was “app-eselect/eselect-pinentry“.
So there are two options:

  1. Find the last version of the portage,which does not depend on the package – app-eselect/eselect-pinentry
  2. Find if some of the USE flags disable the inclusion of this dependency – app-eselect/eselect-pinentry

We chose the second option and found that if we compiled the portage package with

-rsync-verify

the portage did not pull the dependency “app-eselect/eselect-pinentry” and then after a successful upgrade we had the portage supported EAPI 7 and reinstalled it with activated “-rsync-verify”.
Keep on reading!

Access Violation error when compiling packages in Gentoo – symlink

Here is another example of an Access violation error when building packages in Gentoo. This time the build process could not make a symbolic link in “/usr/bin” and the build process of the package failed with:

 * ACCESS DENIED:  symlink:      /usr/bin/stransmit
CMake Error: failed to create symbolic link '/usr/bin/stransmit': permission denied

A detail explanation is available in our first article on the subject here – Access Violation error, when compiling packages in Gentoo.
All packages are built in a sandbox and there is a sandbox configuration in

/etc/sandbox.d/00default

, which instruct the build process where could write. If you get such an error in 99.99% there is a bug in the package and if you do not want to wait for fixing it (report it!) you can manually edit the SANDBOX_WRITE variable and add the path, which causes the build failure. Build the package and remove the added path!!! Or you risk making your system less secure!

We have problem with building the package “net-libs/srt-1.3.1”

srv1 src # emerge -v net-libs/srt

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

[ebuild  N     ] net-libs/srt-1.3.1::gentoo  USE="-doc -gnutls -libressl" ABI_X86="32 (64) (-x32)" 0 KiB

Total: 1 package (1 new), Size of downloads: 0 KiB

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) net-libs/srt-1.3.1::gentoo
 * srt-1.3.1.tar.gz BLAKE2B SHA512 size ;-) ...                                                                                                        [ ok ]
>>> Unpacking source...
.....
.....
>>> Install srt-1.3.1 into /var/tmp/portage/net-libs/srt-1.3.1/image/ category net-libs
 * abi_x86_32.x86: running multilib-minimal_abi_src_install
>>> Working in BUILD_DIR: "/var/tmp/portage/net-libs/srt-1.3.1/work/srt-1.3.1-abi_x86_32.x86"
make -j6 -l10 install 
[ 28%] Built target haicrypt_virtual
[ 40%] Built target srtsupport_virtual
[ 80%] Built target srt_virtual
[ 83%] Built target srt_static
[ 85%] Built target srt_shared
[ 90%] Built target srt-file-transmit
[ 95%] Built target srt-live-transmit
[100%] Built target srt-multiplex
Install the project...
-- Install configuration: "Gentoo"
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib32/libsrt.so.1.3.1
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib32/libsrt.so.1
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib32/libsrt.so
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib32/libsrt.a
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/version.h
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/srt.h
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/logging_api.h
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/platform_sys.h
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/udt.h
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/srt4udt.h
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib32/pkgconfig/haisrt.pc
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib32/pkgconfig/srt.pc
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-live-transmit
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-live-transmit
 * ACCESS DENIED:  symlink:      /usr/bin/stransmit
CMake Error: failed to create symbolic link '/usr/bin/stransmit': permission denied
-- Created symlink: /usr/bin/stransmit -> srt-live-transmit
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-file-transmit
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-file-transmit
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-multiplex
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-multiplex
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-ffplay
 * abi_x86_64.amd64: running multilib-minimal_abi_src_install
>>> Working in BUILD_DIR: "/var/tmp/portage/net-libs/srt-1.3.1/work/srt-1.3.1-abi_x86_64.amd64"
make -j6 -l10 install 
[ 11%] Built target srtsupport_virtual
[ 52%] Built target srt_virtual
[ 80%] Built target haicrypt_virtual
[ 83%] Built target srt_static
[ 85%] Built target srt_shared
[ 90%] Built target srt-multiplex
[ 95%] Built target srt-file-transmit
[100%] Built target srt-live-transmit
Install the project...
-- Install configuration: "Gentoo"
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib64/libsrt.so.1.3.1
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib64/libsrt.so.1
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib64/libsrt.so
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib64/libsrt.a
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/version.h
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/srt.h
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/logging_api.h
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/platform_sys.h
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/udt.h
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/srt4udt.h
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib64/pkgconfig/haisrt.pc
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib64/pkgconfig/srt.pc
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-live-transmit
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-live-transmit
 * ACCESS DENIED:  symlink:      /usr/bin/stransmit
CMake Error: failed to create symbolic link '/usr/bin/stransmit': permission denied
-- Created symlink: /usr/bin/stransmit -> srt-live-transmit
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-file-transmit
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-file-transmit
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-multiplex
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-multiplex
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-ffplay
>>> Completed installing srt-1.3.1 into /var/tmp/portage/net-libs/srt-1.3.1/image/

 * Final size of build directory: 14632 KiB (14.2 MiB)
 * Final size of installed tree:   5324 KiB ( 5.1 MiB)

 * --------------------------- ACCESS VIOLATION SUMMARY ---------------------------
 * LOG FILE: "/var/log/sandbox/sandbox-25570.log"
 * 
VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line

F: symlink
S: deny
P: /usr/bin/stransmit
A: /usr/bin/stransmit
R: /usr/bin/stransmit
C: /usr/bin/cmake -E create_symlink srt-live-transmit /usr/bin/stransmit 

F: symlink
S: deny
P: /usr/bin/stransmit
A: /usr/bin/stransmit
R: /usr/bin/stransmit
C: /usr/bin/cmake -E create_symlink srt-live-transmit /usr/bin/stransmit 
 * --------------------------------------------------------------------------------

>>> Failed to emerge net-libs/srt-1.3.1, Log file:

>>>  '/var/tmp/portage/net-libs/srt-1.3.1/temp/build.log'

In the installation phase occurred the package failure leaving half installed package. So we edited the “/etc/sandbox.d/00default” and added “:/usr/bin” at the end of SANDBOX_WRITE:

SANDBOX_WRITE="/usr/tmp/conftest:/usr/lib/conftest:/usr/lib32/conftest:/usr/lib64/conftest:/usr/tmp/cf:/usr/lib/cf:/usr/lib32/cf:/usr/lib64/cf:/usr/bin"

Then rebuild the package with emerge and remove the added path “:/usr/bin”. This is a dirty workaround, but it will allow you to use srt (and as a dependency to another packages’ installation).

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!