Oleg Vinichenko

ok, a problem with libxkbcommon. need to sort it out.

and in /etc/portage/package.use? they should be lower case entries.

this output shows that you changed from 1.17-prime to master. what you doing next that making xorg-kit dropping back to 1.17-prime?

the problem is likely caused by custom set PYTHON_TARGETS in /etc/portage/make.conf, is this a case? @skunk

this is more complicated than i thought earlier, it will require to backport some older perl module ebuilds. i'm on it.

ok, thx. i'm preparing upgrade guide for stable now. there are still t many pitfalls as each box is unique.

I would like to see output when you do this. so switch to current as above and run emerge -auND @world but *do* not let portage do it's job (update). Paste full output.

new stages using meta-repo

https://github.com/funtoo/meta-repo/blob/master/README.rst

that news little bit outdated and yes, meta-repo is what replaced ports-2017 and will be defaul tree soon. Yes, that's the link for guide for testing meta-repo.

this link is about testing meta-repo, which will replace portage tree. it has some basic explanation of what kits are. master branches means they are have no direct control by Funtoo and pulling Gentoo ebuilds as they are. using master branch of curated kits, controlled kits, possibly can be provided, but it will not be actively supported. More details (notice it's old news and ports-2017 is replaced with meta-repo) but it can probably give the idea: http://www.funtoo.org/News:New_Ports-2017_tree_and_Kits It's not possible to give 100% information for now what will be production ready maintaining procedure as meta-repo is still beta. There will be announcement and a guide. Stabilization of ebuilds is not performed -- if you mean adding stable keywords -- is what actually stable was.

this, will bring certain update such as perl-5.24 and ncurses-6. I'll write more detailed assistance guide on how to make an update. notice, that there could be some quirks still but testing the meta-repo could help significantly as each box is unique and can reveal bugs, in meta-repo and in scripts which makes the repo

No. You can actually test what will be the result by testing meta-repo (a successor of portage tree). https://github.com/funtoo/meta-repo/blob/master/README.rst

that's the goal of kits, the package list defined by kit will be less frequent updated and it will more controlled and predictable is what makes stable rebundant at some point.

its only deprecation of stable, which is what controlled by ACCEPT_KEYWORDS="amd64", for example, so users had "stable" ebuilds on their system by means of keywords. I find it a misconception as it never guaranteed a true stability. In fact stable had more problems than current, and maintaining it on Funtoo was not too good experience. Maybe this worked well back in the early day of Gentoo, i can't tell.

i'll fix this.

biber will work with perl-5.22.2, it's just stupid dependencies set in ebuild, which forcing newer perl.

to sort this problem: you need to mask all ebuilds that you see with perl-5.24, masking exact versions. For example you see: =dev-lang/perl-5.24* required by (virtual/perl-ExtUtils-Install-2.40.0-r2:0/0::gentoo, installed) you need to put mask for =virtual/perl-ExtUtils-Install-2.40.0-r2, same goes for rest of ebuilds. then you need to mask perl-5.24 itself, then reinstall-5.22, and then run perl-cleaner. If you see that some ebuilds asking to put unstable keywords such as: [ebuild N ~] you shouldn't let portage install them, your problem was allowing unstable perl and it's dependencies installed on your box. ideally, it should never happen, but i have no information when and why this happened on your box. Sorry colored text, i have no idea how to disable it.

ok so you using stable and there are bunch of ebuilds with unstable keywords added. please, move /etc/portage/package.accept_keywords to /etc/portage/package.accept_keywords.backup and paste output of emerge -pvt dev-tex/biber

paste output of: grep -rE '(perl|biber)' /etc/portage

it depends on what initramfs generator tool you using.

i'm seeing quite a bit of failures in different packages with cppunit-1.14. so it will be important to investigate.

it's because those are likely build dependency which are needed only at build time. to me, this list looks like it's a dependency list for a genkernel and it's deps pulled in. to tell for sure, add --tree to emerge arguments. this does not look bad to me.

hmm. it puts older initramfs? can you give more details on a problem? i going to test zfs install myself on spare ssd.

install guide mentions clearly that user need to rebuild initramfs with zfs. surprisingly enough, genkernel-next using same code for zfs detection and also same hack for libgcc_s.so copy, so it's unclear why genkernel-next does work and genkernel doesn't. I'll look into that problem.