jhan

Hi @jhan, @nrc,
With your help, I manage to fix the issues. What I was missing was to remerge the linux-firmware after doing correct configuration of the mesa and xorg-drivers.
Thanks a lot!

Fixed masking compat32.

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.

This user override only exists if booted into a debian patched kernel:
/proc/sys/kernel/unprivileged_userns_clone

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

We are not doing rolling release for the following reasons:
Too much time is spent on fixing various breakages coming in from Gentoo, which takes time away from other things... other things are more important such as new technology like fchroot and the upcoming containerization solution... If users are interested in certain packages being updated, I am encouraging them to submit a pull request and maintain these ebuilds themselves, so I am going to focus on helping YOU maintain ebuilds rather than have a few people (this has generally been Oleg) maintaining them for everyone. This model doesn't scale -- we all need to do a little bit rather than a few people doing a lot. See the YouTube channel here: https://www.youtube.com/channel/UCKmOY6p3c9hxv3vJMAF8vVw for tutorials Short-term, this means development slows down. But in reality, it will speed up development greatly. For those hanging out on IRC, you know that Oleg who has helped to maintain Funtoo for years has moved on to a new chapter in his life, so he is no longer active on Funtoo. But even though I am not slaving away over here, thanks to incoming pull requests Funtoo is continuing to move forward and be responsive to user needs.
So think of it as a course correction as we become more agile and community-oriented, and be part of the solution. If you are reading this, it means you are part of the Funtoo community and just as able to contribute to Funtoo as anyone else (maybe with some tutorials/videos to help).
When I work on technologies, I am trying more to work on key tools that help the community be more productive (like fchroot) rather than focusing on specific ebuilds, which I am leaving to the community to manage using pull requests.
Best,
Daniel

Funtoo isn't dying.  Funtoo is changing just like it always has.  You know far better than we do what you want from your Linux distro so ask yourself if you have liked all of the past changes to Funtoo.  Then stick with it and have some faith in the wisdom of our BDFL.  If you don't like what you see in a year or two you can go to another distro and have not lost anything. 
I originally switched to Funtoo because too many things in Gentoo and Debian stayed the same.  Having bleeding edge packages wasn't why I used Gentoo.  It was because it gave me a greater degree of control than any other OS.  The reason I love Debian is because the stable release is always stable but unfortunately I have to give a lot of control to use it.  Funtoo can give me the control that I want and at the same time give me the stability that I need so I am keeping an open mind.
If you have the skills to contribute to the code base and improve things for all of us I encourage you to get involved.  If you are like me and couldn't write a program if your life depended on it then I encourage you donate a bit of money to Funtoo every month. 

I have that feeling that maybe Funtoo needs more devs.

When I did a fresh Funtoo 1.3 install on my desktop PC I just set my profile with epro and installed the KDE meta package and it worked (nearly) flawlessly.  I did something like this:
 

#epro flavor desktop # epro mix-ins kde-plasma-5-new # epro mix-ins no-systemd # epro mix-ins gfxcard-nvidia # emerge -vauND --with-bdeps=y @world # (say yes to any USE flag changes) # dispatch-conf # emerge -vauND --with-bdeps=y @world #emerge -va xorg-server nvidia-drivers nvidia-settings # emerge -va plasma-meta # (say yes to any USE flag changes) # dispatch-conf # emerge -va plasma-meta
I have zero USE flags set in my make.conf and in package.use I only have what portage added.

Hi All,
I've created a new YouTube vlog entry for your enjoyment. This one is about the latest shocking news of being let go from a job. View it here -- I appreciate it if you help me get the word out about my channel, send me some upwardly-pointing thumbs and possibly even subscribe! ? Thanks!
Best,
Daniel
 
 

It really was the radeonsi's fault. I added a FLAG VIDEO_CARDS = "radeon radeonsi". So I realized the:
emerge -auDN @world
and stayed show!
Many thanks to all for the strength.

Hi there.  Long-time lurker, first-time poster.  I've been using Funtoo since 2012 (Gentoo since 2004) and I like what you're doing with it.  For a few years now I've preferred Funtoo to Gentoo when I build new things; and as a physicist, I get to do lots of neat stuff.

I have a request:  Will you please add sys-kernel/{gentoo,vanilla}-sources to the list of packages (e.g. vim) that are kept up-to-date?
I already maintain a local overlay for a few things and can automate tracking gentoo myself, but it becomes a chore to do this everywhere and I can't be the only person with an interest in these simple kernel packages.  (I think it would be marvelous if funtoo tools presented a way to automate tracking gentoo for simple things, without having to maintain an overlay ...)

Thanks for your consideration!  Keep up the good work. ?

(pic unrelated; but it was created with gnofract4d running on a Funtoo machine)

I had to fix some issues -- don't remember what exactly the error was -- about too many versions trying to be installed.  It suggested to use --verbose-conflicts but that didn't work.  Basically I had to reinstall any [installed] package(s) with a lower version dependency.  After I got those cleaned up, I attacked the errors like in my last post.  In the last post, I would have run `emerge libcanberra --ignore-world -1av`.  After sucessfully installing, then I would `emerge world -uDNav` again and deal with the next problem.  Had to uninstall gparted.  I couldn't fix that one.  I also got desperate and tried `emerge world -epv` (--empty-tree).  That actually gave me some good hints too. I had to fix an entry about chromium -~amd64 and add a USE entry.  See the end of the output of `emerge world -epv` below.
Total: 1398 packages (474 upgrades, 4 downgrades, 66 new, 15 in new slots, 839 reinstalls, 4 uninstalls), Size of downloads: 3,673,855 KiB Conflict: 9 blocks !!! The following update has been skipped due to unsatisfied dependencies: sys-block/gparted:0 selected: (sys-block/gparted-0.29.0:0/0::nokit, installed) skipped: (sys-block/gparted-0.29.0:0/0::nokit, ebuild scheduled for merge) (see unsatisfied dependency below) emerge: there are no ebuilds to satisfy ">=dev-cpp/gtkmm-2.22:2.4". (dependency required by "sys-block/gparted-0.29.0::nokit" [ebuild]) The following keyword changes are necessary to proceed: (see "package.accept_keywords" in the portage(5) man page for more details) # required by @selected # required by @world (argument) =www-client/chromium-71.0.3578.30 ~amd64 The following USE changes are necessary to proceed: (see "package.use" in the portage(5) man page for more details) # required by www-client/chromium-71.0.3578.30::net-kit # required by @selected # required by @world (argument) >=net-libs/nodejs-9.11.2 inspector !!! Problems have been detected with your world file !!! Please run emaint --check world !!! Ebuilds for the following packages are either all !!! masked or don't exist: sys-block/gparted After that I had one more package to rebuild and I finally got a sane output to emerge world -uDNav.  I've attached that output in a file.  It's large and in charge.
 
emerge-world-uDNpv.txt

One of the things I am pushing for is for Portage to grab any installed conflicting packages and add them to the package set automatically, before backtracking at all. This is likely going to resolve the majority of conflicts automatically. The upstream gentoo bug for this feature is https://bugs.gentoo.org/559354 <-- and I am thinking of something like an --expand option that will auto-add installed packages that conflict to the set of packages to be rebuilt, so users don't have to. If you think this would be a good idea, you may want to comment on the upstream bug and this may result in it being prioritized.

Hi All,
Within 12 hours, I plan to move 1.3-release to BETA status.
Along with this comes the very important change on 64-bit platforms -- I am removing multilib and making "pure64" compatibility the default. This means that 1.3-release builds with the x86-64bit arch will be 64-bit only.
This is done for a variety of reasons, most important of which is that the world has had a 64-bit PC instruction set for approximately 15 years. It is time to drop 32-bit support. For those who still need 32-bit support, it will be available via a Funtoo 32-bit chroot setup.
The story behind multilib is rather complex and interesting, and might be the focus of a future blog post, but for now, you will just have to trust me -- multilib support in Gentoo is a pain in the butt. It takes a lot of effort to work with and slows us down. Our efforts are best spent in other places, and chroot should work for the vast majority of users who truly are running a critical 32-bit application (other options are 32-bit containers, etc.)
EDIT: Upgrade Instructions Here: https://www.funtoo.org/Upgrade_Instructions/1.3-release
Best,
Daniel

The reason is explained here https://bugs.funtoo.org/browse/FL-5318?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
The profile overrules the make.conf

I use make.conf; I started to write it in 2010 using Gentoo; then I use it also if  may be "redundant" about some use flags; and i've a lot of USE and ~ 2000 ebuilds installed. Cause i like to have as more as possible the status and configuration of my system under my eyes :)

you can try this
portageq expand_virtual / virtual/cron

the problem is reported in https://bugs.funtoo.org/browse/FL-4576
the imagemagick-7 support patch is ready which will allow to remove the strict  dependency on older imagemagick and hence resolving the conflict.

I would start over from a fresh install. Just backup your data and wipe the partition.
Your processor is Silvermont according to this https://en.wikipedia.org/wiki/List_of_Intel_Pentium_microprocessors#"Bay_Trail-M"_(22_nm) Grab this stage3 from build.funtoo.org - funtoo-current/x86-64bit/intel64-silvermont/2017-12-09/stage3-intel64-silvermont-funtoo-current-2017-12-09.tar.xz these are the settings already active in the stage3 so no need to set them by hand  
add only these settings to the make.conf:
 
run these commands:
 

 
update your system:
 

 
emerge lxde-meta:
 

 
continue the installation according to:
https://www.funtoo.org/Install#Configuring_your_system
report back here how it went
 

We’d love to help you. To improve your chances of getting an answer, here are some tips:
Search, and research
...and keep track of what you find. Even if you don't find a useful answer elsewhere on the site, including links to related questions that haven't helped can help others in understanding how your question is different from the rest.
Write a title that summarizes the specific problem
The title is the first thing potential answerers will see, and if your title isn't interesting, they won't read the rest. So make it count:
Pretend you're talking to a busy colleague and have to sum up your entire question in one sentence: what details can you include that will help someone identify and solve your problem? Include any error messages, key APIs, or unusual circumstances that make your question different from similar questions already on the site.
Spelling, grammar and punctuation are important! Remember, this is the first part of your question others will see - you want to make a good impression. If you're not comfortable writing in English, ask a friend to proof-read it for you.
If you're having trouble summarizing the problem, write the title last - sometimes writing the rest of the question first can make it easier to describe the problem.
Examples:
Bad: Is there command to do what it needs? Good: How can I apply changes proposed by emerge? Bad: Problem update system Good: Why does the compile of dev-libs/boost-1.63.0 fail with x86_64-pc-linux-gnu-g++: internal compiler error: Killed (program cc1plus)? Introduce the problem before you post any code
In the body of your question, start by expanding on the summary you put in the title. Explain how you encountered the problem you're trying to solve, and any difficulties that have prevented you from solving it yourself. The first paragraph in your question is the second thing most readers will see, so make it as engaging and informative as possible.
Help others reproduce the problem
Not all questions benefit from including code. Here are some guidelines:
Include just enough code to allow others to reproduce the problem. For portage errors include all the relevant info and output. Include all relevant tags
Try to include a tag for the language, library, and specific API your question relates to. If you start typing in the tags field, the system will suggest tags that match what you've typed - be sure and read the descriptions given for them to make sure they're relevant to the question you're asking! See also: What are tags, and how should I use them?
Proof-read before posting!
Now that you're ready to ask your question, take a deep breath and read through it from start to finish. Pretend you're seeing it for the first time: does it make sense? Try reproducing the problem yourself, in a fresh environment and make sure you can do so using only the information included in your question. Add any details you missed and read through it again. Now is a good time to make sure that your title still describes the problem!
Post the question and respond to feedback
After you post, leave the question open in your browser for a bit, and see if anyone comments. If you missed an obvious piece of information, be ready to respond by editing your question to include it. If someone posts an answer, be ready to try it out and provide feedback!
Look for help asking for help
In spite of all your efforts, you may find your questions poorly-received. Don't despair! Learning to ask a good question is a worthy pursuit, and not one you'll master overnight. Here are some additional resources that you may find useful:
Writing the perfect question How do I ask and answer homework questions? How to debug small programs Meta discussions on asking questions How to ask questions the smart way — long but good advice.

I'd rather it be opt-in, myself.  One of the main reasons for my using Linux over other OS's is that data is specifically NOT sent by default.

This was very helpful.  Your output...
open("/etc/portage/repos.conf/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 My output...
open("/etc/portage/repos.conf/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission denied) It turns out that /etc/portage/repos.conf/ is owned by root:root.  Presumably, eix is using the portage user, and in combination with my default umask=077, it did not have permission.  It's not a problem for /var/git/meta-repo/ because it is owned by portage:portage.  I had adjusted the permissions of /var/git/meta-repo/ and one point, but never touched /etc/portage/repos.conf/.  Occasionally, umask=077 does lead to some oddities.
I have it working now.
Thank you.

yes