Leaderboard

Folks, The Funtoo Linux 1.3 Maintenance Release 1 is now live, and contains the following updates in order to modernize the distro as well as to allow for a smoother transition to 1.4-release, currently in development: OpenSSL updated to 1.1.1b Ruby stack updated to current 2.6.3 release and moved to independently-maintained status rather than auto-generated. node.js updated to 12.3.0. webkit-gtk updated to 2.24.2. wpa_supplicant update to 2.8 to resolve some connectivity issues. updates to dev-libs/icu, libuv, http-parser, nghttp2, genkernel, eudev System updates should be pretty pain-free with no conflicts or other issues. To upgrade, simply ego sync and then emerge -auDN @world. For security reasons, all packages that use openssl will be automatically rebuilt by emerge. If you encounter complications, a bug report to bugs.funtoo.org would be appreciated. Upgrading from openssl 1.0 to 1.1.1 did require several packages to be updated and there could be a few that were missed and still need patches. Enjoy! -Daniel

Thank you so much this solves the problem without any hicupps ?

Your processor doesn't support aes which is in your CPU_FLAGS_86 and CFLAGS="- march=westmere" Building nettle with aes cpu flag set on gcc when your processor doesn't support aes could be the cause of the error. Reference: https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html ‘westmere’ Intel Westmere CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES and PCLMUL instruction set support. Set to native and add the proper flags to match your processor. Install cpuid2cpuflags Follow my directions here starting at Remove any gcc override settings you've made previously. After you've finished configuring gcc to match your processor rebuild nettle.

Is this the whole line from dmesg? Normally that message is followed by "in..." I suspect that something on your system is not compatible with your cpu. For that it would be interesting to know: - Your CPU (/proc/cpuinfo) - The output of 'emerge --info' - What stage3 you used for your system installation

Everyone, I have just started getting kit-fixups ready for 1.4-release development. Some key changes that are coming in 1.4-release: move away from eselect opengl and to libglvnd. official support of container-based solution for steam, etc. updates to pam and pambase 1.4-release will be tracking "current" gentoo for a while and will freeze sometime this summer, likely in June 2019. If you want to get involved, chat on #funtoo and look at the latest commits to kit-fixups on code.funtoo.org. I'll also be doing some introductory videos on how to get involved with the new release of Funtoo. -Daniel

My guess would be that this package is the culprit. It would be interesting to see what would happen if you get that /usr/include/util.h out of the way, if the emerge of gvfs will complete successfully then. Besides it seems that there have been quite some updates to libqmartixclient including the removal of QPointer from util.h. Could you try that out in some way? Renaming /usr/include/util.h or moving it away temporarily should be enough for that.

Have you tried to run, after ebuild file has been changed? ebuild <file>.ebuild digest

I am seeing only one issue with libevent not rebuilding correctly against the new openssl. I'll be pushing a fix for this shortly... workaround for now is to manually merge or unmask 2.1.8 of libevent and merge. This builds fine against openssl-1.1.1 -- it just happens to have an old mask entry preventing emerge from seeing it.

Thanks guys - I've put all three way to override python in my package.use!! # package.use # # three ways to select python version >=app-text/asciidoc-8.6.10 python_single_target_python2_7 python_targets_python2_7 dev-util/itstool PYTHON_TARGETS: -* python3_6 PYTHON_SINGLE_TARGET: -* python3_6 dev-libs/libxml2 python_targets_python*

Interesting way of adding python targets in package.use @cardinal Never seen that before. Although I think I might still prefer using python_targets_python* and python_single_target_python*. Seems to be easier to read for me, especially when I have other use flags as well. The interesting question would be if there is a difference between the error with "emerge @world" and "emerge -pv libxml2 itstool". Might help in locating the error.

Add to package.use dev-util/itstool PYTHON_TARGETS: -* python3_6 PYTHON_SINGLE_TARGET: -* python3_6 dev-libs/libxml2 PYTHON_TARGETS: -* python3_6 I don't specify >=< and package version when overriding default USE flags in package.use Reference: https://wiki.gentoo.org/wiki/Project:Python/PYTHON_TARGETS https://wiki.gentoo.org/wiki/Handbook:Parts/Working/USE