gentoo resync : 25.04.2020

20 files changed, 200 insertions, 415 deletions

diff --git a/metadata/news/2014-02-25-udev-upgrade/2014-02-25-udev-upgrade.en.txt b/metadata/news/2014-02-25-udev-upgrade/2014-02-25-udev-upgrade.en.txt
deleted file mode 100644
index 9c37eeeaf4bf..000000000000
--- a/metadata/news/2014-02-25-udev-upgrade/2014-02-25-udev-upgrade.en.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Title: Upgrade to >=sys-fs/udev-210
-Author: Samuli Suominen <ssuominen@gentoo.org>
-Content-Type: text/plain
-Posted: 2014-02-25
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: <sys-fs/udev-210
-
-The options CONFIG_FHANDLE and CONFIG_NET are now required in the kernel.
-You will be warned of them if they are missing while you upgrade to
->=sys-fs/udev-210 by the package manager.
-See the package's README at /usr/share/doc/udev-210/ for more optional
-kernel options.
-
-The most reliable way of disabling the new network interface scheme is still
-the kernel parameter "net.ifnames=0" since overriding the
-80-net-name-slot.rules in /etc/udev/rules.d/ no longer works since upstream
-renamed the file to /lib/udev/rules.d/80-net-setup-link.rules
-The actual configuration is at /lib/systemd/network/99-default.link, which
-you can override in /etc/systemd/network/
-So, to clarify, you can override the new .rules file or the .link file in /etc
-but using the kernel parameter is the most consistent way.
-
-Since both the systemd-udevd executable and the network configuration is stored
-at /lib/systemd, using a too wide INSTALL_MASK would be a mistake.
-
-[1] https://wiki.gentoo.org/wiki/Udev/upgrade#udev_208_to_210
-[2] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
diff --git a/metadata/news/2014-03-12-profile-eapi-5/2014-03-12-profile-eapi-5.en.txt b/metadata/news/2014-03-12-profile-eapi-5/2014-03-12-profile-eapi-5.en.txt
deleted file mode 100644
index 08a8ae6d1ce3..000000000000
--- a/metadata/news/2014-03-12-profile-eapi-5/2014-03-12-profile-eapi-5.en.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-Title: Profile EAPI 5 requirement
-Author: Zero_Chaos <zerochaos@gentoo.org>
-Content-Type: text/plain
-Posted: 2014-03-02
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: <sys-apps/portage-2.2.0_alpha130
-
-The Gentoo Council has decided that the entire profile tree will be
-updated to require EAPI=5 support.
-
-http://www.gentoo.org/proj/en/council/meeting-logs/20140114.txt
-
-For all non-deprecated profiles this requirement has already been in
-place for over one year. If you have updated your system at any point
-during 2013, and followed the instructions in the profile deprecation
-warnings (which cannot really easily be overlooked), and are running an
-up-to-date portage version, there is absolutely nothing that you need
-to do now.
-
-If you are running an installation that has not been updated for more
-than a year, the portage tree you have just updated to may be
-incompatible with your portage version, and the profile you are using
-may be gone.
-
-It is still possible to upgrade, following these simple steps:
-
-1.) Do not panic.
-2.) Download a portage snapshot from
-	http://dev.gentoo.org/~zerochaos/snapshots
-3.) Unpack the snapshot to ~/tmp
-4.) If you are not already, become root
-5.) # rsync --recursive --links --safe-links --perms --times --force \
-	--whole-file --delete --stats --human-readable \
-	--exclude=/distfiles --exclude=/local --exclude=/packages \
-	--verbose --progress --omit-dir-times /tmp/portage /usr/portage
-6.) # chown portage.portage -R /usr/portage
-6.) If needed, set your profile to a modern one (typically named 13.0)
-7.) # eselect profile list
-8.) # eselect profile set <desired profile>
-9.) emerge --update --oneshot portage
-
-Now that you have a modern copy of portage, you can go back to updating
-your system as usual. Please update your system at LEAST twice a year
-to avoid issues like this in the future.
-
-Thanks for flying Gentoo.
diff --git a/metadata/news/2014-03-16-ruby-1_8-removal/2014-03-16-ruby-1_8-removal.en.txt b/metadata/news/2014-03-16-ruby-1_8-removal/2014-03-16-ruby-1_8-removal.en.txt
deleted file mode 100644
index 11017ab2b1c9..000000000000
--- a/metadata/news/2014-03-16-ruby-1_8-removal/2014-03-16-ruby-1_8-removal.en.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Title: Ruby 1.8 removal; Ruby 1.9/2.0 default
-Author: Manuel Rüger <mrueg@gentoo.org>
-Content-Type: text/plain
-Posted: 2014-03-16
-Revision: 2
-News-Item-Format: 1.0
-Display-If-Installed: <dev-lang/ruby-1.9
-
-Ruby MRI 1.8 has been retired by upstream in June 2013.[1]
-We remove Ruby MRI 1.8 support from the tree now. In parallel Ruby MRI 2.0 
-support will be activated in base profile's RUBY_TARGETS variable by default 
-in conjunction with Ruby MRI 1.9.
-
-If your currently eselected Ruby interpreter is ruby18, our recommendation is 
-to change it to ruby19. At the moment Ruby MRI 1.9 delivers the best possible 
-support of all Ruby interpreters in tree.
-
-Check the current setting via:
-
-	eselect ruby show
-
-Change the current setting to Ruby MRI 1.9 via:
-
-	eselect ruby set ruby19
-
-[1] https://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7/
diff --git a/metadata/news/2014-06-03-upower-loses-hibernate-suspend-to-systemd/2014-06-03-upower-loses-hibernate-suspend-to-systemd.en.txt b/metadata/news/2014-06-03-upower-loses-hibernate-suspend-to-systemd/2014-06-03-upower-loses-hibernate-suspend-to-systemd.en.txt
deleted file mode 100644
index 135dc69e62a3..000000000000
--- a/metadata/news/2014-06-03-upower-loses-hibernate-suspend-to-systemd/2014-06-03-upower-loses-hibernate-suspend-to-systemd.en.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Title: UPower loses hibernate / suspend to systemd
-Author: Samuli Suominen <ssuominen@gentoo.org>
-Content-Type: text/plain
-Posted: 2014-06-03
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: <sys-power/upower-0.99.0
-
-UPower discontinued hibernate and suspend support in favor of systemd.
-Because of this, we have created a compability package at
-sys-power/upower-pm-utils which will give you the old UPower with
-sys-power/pm-utils support back.
-Some desktops have integrated the sys-power/pm-utils support directly
-to their code, like Xfce, and as a result, they work also with the new
-UPower as expected.
-
-All non-systemd users are recommended to choose between:
-
-# emerge --oneshot --noreplace 'sys-power/upower-pm-utils'
-
-or
-
-# emerge --oneshot --noreplace '>=sys-power/upower-0.99.0'
-
-However, all systemd users are recommended to stay with sys-power/upower.
-
-A small tip for GNOME _and_ systemd users, only 3.12 and newer support 0.99,
-so if you see the package manager pulling in sys-power/upower-pm-utils
-while using old GNOME, like 2.32 or 3.10, you _can_ prevent it by adding
-a package.mask entry for >=sys-power/upower-0.99
diff --git a/metadata/news/2014-07-17-dhcpcd_6_4_2_changes_defaults_for_ipv6/2014-07-17-dhcpcd_6_4_2_changes_defaults_for_ipv6.en.txt b/metadata/news/2014-07-17-dhcpcd_6_4_2_changes_defaults_for_ipv6/2014-07-17-dhcpcd_6_4_2_changes_defaults_for_ipv6.en.txt
deleted file mode 100644
index 11ce7a04bfa6..000000000000
--- a/metadata/news/2014-07-17-dhcpcd_6_4_2_changes_defaults_for_ipv6/2014-07-17-dhcpcd_6_4_2_changes_defaults_for_ipv6.en.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Title: dhcpcd >= 6.4.2 changes defaults for IPv6
-Author: William Hubbs <williamh@gentoo.org>
-Content-Type: text/plain
-Posted: 2014-07-17
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: <=net-misc/dhcpcd-6.4.2
-
-dhcpcd-6.4.2 and newer supports IPv6 stable private addresses when using
-IPv6 stateless address autoconfiguration (SLAAC) as described in
-RFC-7217 [1]. The configuration file shipped with dhcpcd activates this
-feature by default, because it means that a machine cannot be tracked
-across multiple networks since its address will no longer be based on
-the hardware address of the interface.
-
-I received a report in testing that IPv6 connectivity was lost due
-to this change [2]. If you are concerned about losing IPv6 connectivity,
-temporarily comment out the line in dhcpcd.conf that says
-"slaac private" until you can adjust to the new configuration.
-
-See the references below for why the upstream default is to use stable
-private instead of hardware-based addresses.
-
-[1] http://tools.ietf.org/html/rfc7217
-[2] https://bugs.gentoo.org/show_bug.cgi?id=514198
-[3] http://tools.ietf.org/html/draft-ietf-6man-default-iids-00
-[4] http://mail-index.netbsd.org/tech-net/2014/06/04/msg004572.html
diff --git a/metadata/news/2014-08-20-mysql_5_5_upgrade_procedures/2014-08-20-mysql_5_5_upgrade_procedures.en.txt b/metadata/news/2014-08-20-mysql_5_5_upgrade_procedures/2014-08-20-mysql_5_5_upgrade_procedures.en.txt
deleted file mode 100644
index f0feef1c57a2..000000000000
--- a/metadata/news/2014-08-20-mysql_5_5_upgrade_procedures/2014-08-20-mysql_5_5_upgrade_procedures.en.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Title: MySQL 5.5 upgrade procedures
-Author: Brian Evans <grknight@gentoo.org>
-Content-Type: text/plain
-Posted: 2014-08-20
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: <dev-db/mysql-5.5
-
-MySQL 5.5 is now stable across all arches. The upgrade process
-will require you to rebuild everything linked to
-libmysqlclient.so.16 and libmysqlclient_r.so.16.
-
-This may be done for you by portage with 'emerge @preserved-rebuild'.
-
-A small number of libraries may not be automatically rebuilt against
-the new MySQL libraries using preserved-rebuild.  If you have
-difficulties with packages not finding the new libraries, install
-app-portage/gentoolkit and run:
-# revdep-rebuild --library libmysqlclient.so.16
-# revdep-rebuild --library libmysqlclient_r.so.16
-
-The official upgrade documentation is available here:
-http://dev.mysql.com/doc/refman/5.5/en/upgrading.html
-
-Please be sure to review the upgrade document for any possible actions
-necessary before and after the upgrade. This includes running
-mysql_upgrade after the upgrade completion.
-
-Due to security flaws, MySQL 5.1 will be hard masked in 30 days after
-this news item is posted.  It will remain masked in the tree for
-3 months before removal.
diff --git a/metadata/news/2014-10-04-restructuring_of_mips_profiles/2014-10-04-restructuring_of_mips_profiles.en.txt b/metadata/news/2014-10-04-restructuring_of_mips_profiles/2014-10-04-restructuring_of_mips_profiles.en.txt
deleted file mode 100644
index 081d8a7ba9ed..000000000000
--- a/metadata/news/2014-10-04-restructuring_of_mips_profiles/2014-10-04-restructuring_of_mips_profiles.en.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-Title: Restructuring of mips profiles
-Author: Anthony G. Basile <blueness@gentoo.org>
-Content-Type: text/plain
-Posted: 2014-10-04
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Keyword: mips
-Display-If-Installed: sys-libs/glibc
-
-To accomodate the new multilib approach in Gentoo, the mips profiles will be
-changing on Oct 11, 2014.  The new profile structure will be as follows:
-
-  [1]   default/linux/mips/13.0/o32
-  [2]   default/linux/mips/13.0/n32
-  [3]   default/linux/mips/13.0/n64
-  [4]   default/linux/mips/13.0/multilib/o32
-  [5]   default/linux/mips/13.0/multilib/n32
-  [6]   default/linux/mips/13.0/multilib/n64
-  [7]   default/linux/mips/13.0/mipsel/o32
-  [8]   default/linux/mips/13.0/mipsel/n32
-  [9]   default/linux/mips/13.0/mipsel/n64
-  [10]  default/linux/mips/13.0/mipsel/multilib/o32
-  [11]  default/linux/mips/13.0/mipsel/multilib/n32
-  [12]  default/linux/mips/13.0/mipsel/multilib/n64
-  [13]  hardened/linux/musl/mips
-  [14]  hardened/linux/musl/mips/mipsel
-  [15]  default/linux/uclibc/mips
-  [16]  hardened/linux/uclibc/mips
-  [17]  default/linux/uclibc/mips/mipsel
-  [18]  hardened/linux/uclibc/mips/mipsel
-
-There are a few points to note about the change:
-
-1) Only the glibc profiles (1-12) are affected.  The embedded system profiles 
-(13-18) will not change.
-
-2) The glibc profiles will now explicitly state the ABIs.  In the case of
-non-multilib systems (1-3, 7-9) the stated ABI will be the only ABI available,
-while in the case of multilib systems (4-6, 10-12) the stated ABI will be the
-default ABI, and the others will be available by setting ABI_MIPS in make.conf.
-
-3) Profiles 1 and 7 are strictly 32-bit userland, but can run under either a
-32-bit or 64-bit kernel.  They will have CHOST = mips-unknown-linux-gnu and
-mipsel-unknown-linux-gnu, respectively.  All the other glibc profiles (2-6, 8-12)
-are 64-bits userland and will have CHOST = mips64-unknown-linux-gnu or
-mips64el-unknown-linux-gnu.
-
-4) Only users of profiles 1 and 7 need to change their profiles sym links using
-`eselect profile`.  However, all users should be aware of the CHOST value on
-their system to ensure it remains unchanged after the profile updates.
-
diff --git a/metadata/news/2014-10-22-mythtv-schedulesdirect-change/2014-10-22-mythtv-schedulesdirect-change.en.txt b/metadata/news/2014-10-22-mythtv-schedulesdirect-change/2014-10-22-mythtv-schedulesdirect-change.en.txt
deleted file mode 100644
index a6ecb8200c5c..000000000000
--- a/metadata/news/2014-10-22-mythtv-schedulesdirect-change/2014-10-22-mythtv-schedulesdirect-change.en.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Title: MythTV SchedulesDirect Change
-Author: Richard Freeman <rich0@gentoo.org>
-Content-Type: text/plain
-Posted: 2014-10-20
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: <media-tv/mythtv-0.27.4
-
-Many MythTV users use the SchedulesDirect service as a source of program
-data.  If you use this service you will need to take action or you will
-lose access to scheduling data on Nov 1st 2014.  If you do not use this
-service, no action is required.
-
-If you use the SchedulesDirect service, you must either upgrade to
-media-tv/mythtv-0.27.4, or you must follow one of the workarounds found
-at: http://www.mythtv.org/wiki/Schedules_Direct_URL_Change
-
-The link above also provides additional information about the change.
\ No newline at end of file
diff --git a/metadata/news/2014-10-22-upgrading-to-musl-1_1_5/2014-10-22-upgrading-to-musl-1_1_5.en.txt b/metadata/news/2014-10-22-upgrading-to-musl-1_1_5/2014-10-22-upgrading-to-musl-1_1_5.en.txt
deleted file mode 100644
index 77372bdf4547..000000000000
--- a/metadata/news/2014-10-22-upgrading-to-musl-1_1_5/2014-10-22-upgrading-to-musl-1_1_5.en.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-Title: Upgrading to musl 1.1.5
-Author: Anthony G. Basile <blueness@gentoo.org>
-Content-Type: text/plain
-Posted: 2014-10-22
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: sys-libs/musl
-
-Versions 1.1.4 and above of musl provide Native Language Support (nls).  Up
-till now, Gentoo musl stages have used GNU gettext to provide nls via libintl.so
-and linked applications against it.  Beginning with musl-1.1.5 we are switching
-to nls provided by musl.  Since musl is experimental, you are better off starting
-with a new stage3 dated later than 2014-10-20.  However, if you wish to upgrade
-an existing system, you can proceed as follows:
-
-1. Remove any references to -lintl from /etc/portage/package.env and
-/etc/portage/env/*.  If you did not modify these from the original stage3
-then you can just do `rm -rf /etc/portage/package.env /etc/portage/env`
-
-2. Update your system, except for musl:
-
-    emerge --exclude musl -uvNDq world
-
-3. Remove the libintl header belonging to gettext:
-
-    rm -f /usr/include/libintl.h
-
-4. Now you can update musl without a file collision:
-
-    emerge -1q =sys-libs/musl-1.1.5
-
-5. We need to turn USE=nls off in gettext:
-
-    echo "=sys-devel/gettext-0.19.3" >> /etc/portage/package.accept_keywords
-    echo "sys-devel/gettext -nls" >> /etc/portage/package.use
-    emerge -1 gettext
-
-6. Rebuild any packages that might be linking against libintl.so:
-
-    USE=-nls emerge -uvDNq world
-
-7. The previous step probably missed some executables, so find them all:
-
-    for i in /bin/* /sbin/ /usr/bin/* /usr/sbin/* ; do
-        readelf -d $i 2>&1 | grep -q libintl.so && echo $i
-    done
-
-You can identify what packages these belong to uing `equery b <exe>`  Rebuild
-those packages.
-
-8. At this point you can remove /usr/lib/libintl.so*.  To be safe, check that
-all your coreutils utilities (like mv, cp, ls, etc.) really aren't linking
-against libintl.so as described in the previous step and then mv that library
-out of the dynamic linker's search path.
-
-9. While not strictly necessary, you can rebuild your entire system to make
-sure everything links nicely against the new libc.so: emerge -evq world 
diff --git a/metadata/news/2014-11-07-udev-upgrade/2014-11-07-udev-upgrade.en.txt b/metadata/news/2014-11-07-udev-upgrade/2014-11-07-udev-upgrade.en.txt
deleted file mode 100644
index c1466095ced7..000000000000
--- a/metadata/news/2014-11-07-udev-upgrade/2014-11-07-udev-upgrade.en.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Title: Upgrade to udev >= 217 or eudev >= 2.1
-Author: Samuli Suominen <ssuominen@gentoo.org>
-Content-Type: text/plain
-Posted: 2014-11-07
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: <sys-fs/udev-217
-Display-If-Installed: <sys-fs/eudev-2.1
-
-sys-fs/udev-217 and sys-fs/eudev-2.1 no longer provide a userspace
-firmware loader. If you require firmware loading support, you must use
-kernel 3.7 or greater with CONFIG_FW_LOADER_USER_HELPER=n. No action is
-required if none of your kernel modules need firmware. See [1] for more
-information on the upgrade.
-
-[1] https://wiki.gentoo.org/wiki/Udev/upgrade#udev_216_to_217
diff --git a/metadata/news/2014-11-11-kgcc64-sparc-removal/2014-11-11-kgcc64-sparc-removal.en.txt b/metadata/news/2014-11-11-kgcc64-sparc-removal/2014-11-11-kgcc64-sparc-removal.en.txt
deleted file mode 100644
index 635c865ae9f8..000000000000
--- a/metadata/news/2014-11-11-kgcc64-sparc-removal/2014-11-11-kgcc64-sparc-removal.en.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Title: sys-devel/kgcc64 removal on sparc
-Author: Raúl Porcel <armin76@gentoo.org>
-Content-Type: text/plain
-Posted: 2014-11-11
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Profile: default/linux/sparc
-
-sys-devel/kgcc64 is going to be removed from the sparc system package set
-since the normal sys-devel/gcc can, since version 4.4, build 64bit kernels.
-
-Until now, you had to use CONFIG_CROSS_COMPILE="sparc64-unknown-linux-gnu-"
-in your kernel config, but with sys-devel/kgcc64 going away, you need to
-remove that option from your kernel configuration. 
-
-
diff --git a/metadata/news/2014-11-25-bash-completion-2_1-r90/2014-11-25-bash-completion-2_1-r90.en.txt b/metadata/news/2014-11-25-bash-completion-2_1-r90/2014-11-25-bash-completion-2_1-r90.en.txt
deleted file mode 100644
index f63ca7738a5e..000000000000
--- a/metadata/news/2014-11-25-bash-completion-2_1-r90/2014-11-25-bash-completion-2_1-r90.en.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-Title: bash-completion-2.1-r90
-Author: Michał Górny <mgorny@gentoo.org>
-Content-Type: text/plain
-Posted: 2014-11-25
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: >=app-shells/bash-completion-2.1-r90
-
-Starting with app-shells/bash-completion-2.1-r90, the framework used to
-enable and manage completions in Gentoo is finally changing in order to
-properly follow upstream design. This has some important implications
-for our users.
-
-Firstly, the install location for completions changes to follow upstream
-default. The completions enabled before the upgrade will continue to
-work but you may no longer be able to enable or disable completions
-installed prior to the upgrade. To solve this issue, the packages
-installing completions need to rebuilt. The following command can be
-used to automatically rebuild all the relevant packages:
-
-$ find /usr/share/bash-completion -maxdepth 1 -type f \
-	'!' -name 'bash_completion' -exec emerge -1v {} +
-
-Secondly, the autoloading support introduced upstream removes the
-penalties involved with enabling a great number of completions. This
-allowed us to switch to an opt-out model where all completions installed
-after the upgrade are enabled by default. Specific completions can be
-disabled using 'eselect bashcomp disable ...'
-
-The model change implies that all current selections done using 'eselect
-bashcomp' can not be properly migrated and will be disregarded when
-the relevant completion files are built against the new bash-completion
-version. After rebuilding all the packages providing completion files,
-you may want to remove the symlinks that were used to configure
-the previous framework using the following command:
-
-$ find /etc/bash_completion.d -type l -delete
-
-Thirdly, we have solved the issue causing bash-completion support to be
-enabled by default on login shells only. If you needed to explicitly
-source 'bash_completion' script in bashrc, you can safely remove that
-code now since system-wide bashrc takes care of loading it.
-
-Lastly, we would like to explain that USE=bash-completion is being
-removed from packages for the completions will be installed
-unconditionally now. However, this will result in some implicit
-dependencies being removed. Most specifically, users wishing to use
-bash-completion will have to request app-shells/bash-completion
-explicitly, e.g.:
-
-$ emerge -n app-shells/bash-completion
diff --git a/metadata/news/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt b/metadata/news/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt
new file mode 100644
index 000000000000..c496154bd8e0
--- /dev/null
+++ b/metadata/news/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt
@@ -0,0 +1,25 @@
+Title: new ppc64le (little-endian) profiles
+Author: Georgy Yakovlev <gyakovlev@gentoo.org>
+Posted: 2020-04-04
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian
+Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd
+
+A new set of 17.0 ppc64le profiles has been added to the Gentoo repository.
+New profiles are compatible with existing ppc64 little-endian profiles,
+and no additional action required after switching the profile.
+
+Please migrate away from the old profiles:
+
+* Old profiles:
+default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian
+default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd
+
+* Replaced by:
+default/linux/ppc64le/17.0 
+default/linux/ppc64le/17.0/systemd
+
+Desktop profiles are now also available.
+
+Refer to `eselect profile list` output.
diff --git a/metadata/news/2020-04-14-elogind-default/2020-04-14-elogind-default.en.txt b/metadata/news/2020-04-14-elogind-default/2020-04-14-elogind-default.en.txt
new file mode 100644
index 000000000000..d0cd3f67e442
--- /dev/null
+++ b/metadata/news/2020-04-14-elogind-default/2020-04-14-elogind-default.en.txt
@@ -0,0 +1,60 @@
+Title: Desktop profile switching USE default to elogind
+Author: Andreas Sturmlechner <asturm@gentoo.org>
+Posted: 2020-04-14
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Installed: sys-auth/consolekit
+
+Modern desktop environments make use of PAM session tracking for users, login
+sessions and seats. [1] The most user-visible part of that is device and file
+permissions management and reboot/shutdown handling without superuser rights.
+
+Users with systemd can stop reading here and continue with their daily
+routine.
+
+ConsoleKit2 is unmaintained upstream for more than two years [2]. There are
+many longstanding bugs and papercuts with consumers that aren't being fixed,
+not least because these code paths receive very little testing.
+
+Enter the elogind project [3], which is a standalone logind implementation
+based on systemd code, currently maintained by a fellow Gentoo user. We have
+had sys-auth/elogind available in Gentoo since the beginning of 2017, and
+meanwhile it has gained support [4] in KDE Plasma, Gnome [5], Cinnamon, MATE
+and Xfce, as well as most other former consolekit consumers.
+
+Consequently, the desktop profile is switching away from consolekit to
+elogind. Users of sys-auth/consolekit who selected a different profile should
+consider doing the same. A guide is available [6]. Migration is easy, but any
+existing consolekit session will be broken, and elogind will only begin to work
+on relogin.
+
+Rely either on the profile, or set USE="elogind -consolekit" in make.conf
+yourself. Make sure there is no consolekit debris in /etc/portage/package.use:
+
+# grep -R consolekit /etc/portage/package.use
+
+Rebuild all affected consumers and remove sys-auth/consolekit:
+
+# emerge --ask --changed-use --deep @world
+# emerge --depclean consolekit
+
+Optional, but recommended in case of trouble such as missing reboot/shutdown
+capabilities in the display manager:
+
+# rc-update add elogind boot
+
+For users of ~/.xinitrc instead of one of the supported DMs, do not forget to
+update accordingly (ck-launch-session is gone without replacement).
+
+PS: Subsequently, this will lead to the last-riting of sys-power/pm-utils [7]
+which is dead even longer than the original ConsoleKit(1) project. KDE Plasma
+users sticking with sys-auth/consolekit are then going to lose suspend from
+GUI without superuser rights.
+
+[1] https://wiki.gentoo.org/wiki/ConsoleKit
+[2] https://github.com/ConsoleKit2/ConsoleKit2
+[3] https://github.com/elogind/elogind/blob/master/README.md
+[4] https://bugs.gentoo.org/show_bug.cgi?id=elogind-support
+[5] https://blogs.gentoo.org/leio/2019/03/26/gnome-3-30/
+[6] https://wiki.gentoo.org/wiki/Elogind
+[7] https://bugs.gentoo.org/659616
diff --git a/metadata/news/2020-04-22-opencl-upgrade-file-collisions/2020-04-22-opencl-upgrade-file-collisions.en.txt b/metadata/news/2020-04-22-opencl-upgrade-file-collisions/2020-04-22-opencl-upgrade-file-collisions.en.txt
new file mode 100644
index 000000000000..5aeb8569c3ad
--- /dev/null
+++ b/metadata/news/2020-04-22-opencl-upgrade-file-collisions/2020-04-22-opencl-upgrade-file-collisions.en.txt
@@ -0,0 +1,28 @@
+Title: Potential file collisions during OpenCL upgrade
+Author: Marek Szuba <marecki@gentoo.org>
+Posted: 2020-04-22
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Installed: app-eselect/eselect-opencl
+
+OpenCL support in Gentoo is now being migrated to having all implementations
+operate through an ICD loader (dev-libs/ocl-icd or dev-libs/opencl-icd-loader)
+installed directly into /usr rather than using eselect-opencl to switch
+between implementations, with updated loader ebuilds having just been released
+to the public. Unfortunately although the upgrade process will automatically
+uninstall app-eselect/eselect-opencl, it will not remove the symbolic links to
+libOpenCL.so created by this tool in library directories because those links
+are not owned by the package in question.
+
+For everyone using the default Gentoo configuration of collision protection
+(FEATURES='-collision-protect protect-owned'), this should cause no trouble
+because this configuration allows the overwriting of orphaned files.
+Obviously, systems with collision protection completely disabled (not
+recommended but technically possible) will not be affected either. However,
+if your system is configured for full collision protection
+(FEATURES=collision-protect), it will be necessary to manually remove those
+links
+
+    rm -i /usr/lib{,64}/libOpenCL.so*
+
+before running the upgrade.
diff --git a/metadata/news/2020-04-22-python3-7/2020-04-22-python3-7.en.txt b/metadata/news/2020-04-22-python3-7/2020-04-22-python3-7.en.txt
new file mode 100644
index 000000000000..c933ca6259e9
--- /dev/null
+++ b/metadata/news/2020-04-22-python3-7/2020-04-22-python3-7.en.txt
@@ -0,0 +1,70 @@
+Title: Python 3.7 to become the default target
+Author: Michał Górny <mgorny@gentoo.org>
+Posted: 2020-04-22
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Installed: dev-lang/python:3.6
+Display-If-Installed: dev-lang/python:3.7
+
+On 2020-05-06 (or later), Python 3.7 will replace Python 3.6 as one
+of the default Python targets for Gentoo systems.  The new default
+values will be:
+
+    PYTHON_TARGETS="python2_7 python3_7"
+    PYTHON_SINGLE_TARGET="python3_7"
+
+If you have not overriden these variables on your system, then your
+package manager will switch to the new targets immediately.  In order
+to avoid dependency conflicts, please clean stray packages up
+and rebuild/upgrade all packages with USE flag changes after the change,
+e.g.:
+
+    emerge --depclean
+    emerge -1vUD @world
+    emerge --depclean
+
+Please note that during the system upgrade some of the package
+dependencies may temporarily become missing.  While this should not
+affect programs that are already fully loaded, it may cause ImportErrors
+when starting Python scripts or loading additional modules (only scripts
+running Python 3.6 are affected).
+
+In order to improve stability of the upgrade, you may choose to
+temporarily enable both targets, i.e. set in /etc/portage/package.use
+or its equivalent:
+
+    */* PYTHON_TARGETS: python3_6 python3_7
+    */* PYTHON_SINGLE_TARGET: -* python3_6
+
+This will cause the dependencies to include both Python 3.6 and 3.7
+support whenever possible, throughout the next system upgrade.  Once all
+packages are updated, you can restart your scripts, remove the setting
+and start another upgrade in order to cleanly remove Python 3.6.
+
+There are still some Gentoo packages that do not support Python 3.7.
+We will be pushing updates to these packages as time permits.  However,
+some of them will probably be removed instead.
+
+If you would like to postpone the switch to Python 3.7, you can copy
+the current value of PYTHON_TARGETS and/or PYTHON_SINGLE_TARGET
+to /etc/portage/package.use or its equivalent:
+
+    */* PYTHON_TARGETS: -python3_7 python3_6
+    */* PYTHON_SINGLE_TARGET: -* python3_6
+
+If you would like to migrate your systems earlier, you can do
+the opposite.  Note that if you are running ~arch, you may want to go
+straight for Python 3.8 at this point.
+
+Please note that this switch is long overdue.  Python 3.6 is no longer
+receiving bug fixes.  Its planned end-of-life is 2021-12-23 but we will
+probably remove it earlier than that.  [1]
+
+All above snippets assume using package.use to control USE flags.
+If you still have make.conf entries for these targets, you need
+to remove them.  While using make.conf is possible, it is strongly
+discouraged as it does not respect package defaults.  The latter
+can help you keep some of Python 3.6 packages without the need to
+explicitly toggle flags per-package.
+
+[1] https://devguide.python.org/#status-of-python-branches
diff --git a/metadata/news/Manifest b/metadata/news/Manifest
index 961e06a692e5..cc12549b272f 100644
--- a/metadata/news/Manifest
+++ b/metadata/news/Manifest
@@ -1,23 +1,23 @@
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA512
 
-MANIFEST Manifest.files.gz 13175 BLAKE2B 7eb738320345232ed2736a961e6688799f400d3000b5a8c07e207eb5018330e5e1d98a631168fb83ee021c13c98bebe7361bfa07f5507ec69c1f3ace0b23fceb SHA512 11dd46c9fdf08776322324c26f6a98dcb2de725556bea172e4668c76998844721c7894523de2828e7e1355dca7b7a057a368b55db3e47ffe97e8e0908203a328
-TIMESTAMP 2020-04-12T01:38:57Z
+MANIFEST Manifest.files.gz 11671 BLAKE2B 1690ee8d13e213a22166c131af13ff1a0dfed95b26626717da1dd0e69d4ef665a541c29fb093b3448e8ead5892ef808f1ff49a831e1b340a550acc001b504b9b SHA512 f9c4594162a5063caf99f69d3ea6a9bd4aa9ba259aef4cbb27a28dc923f75da8b758a02237fa977fb867ea8cb8b599d4a1b25c6f88cf07541aa64d7ae03f5127
+TIMESTAMP 2020-04-25T09:38:56Z
 -----BEGIN PGP SIGNATURE-----
 
-iQKTBAEBCgB9FiEE4dartjv8+0ugL98c7FkO6skYklAFAl6ScTFfFIAAAAAALgAo
+iQKTBAEBCgB9FiEE4dartjv8+0ugL98c7FkO6skYklAFAl6kBTBfFIAAAAAALgAo
 aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUx
 RDZBQkI2M0JGQ0ZCNEJBMDJGREYxQ0VDNTkwRUVBQzkxODkyNTAACgkQ7FkO6skY
-klBNgg/9G52SnSzcD3qo0v0o1Bm4SdVkgHnroq9RX4obV5MnxoXattkQeDEBLS/u
-Cdis+6RCXXOHv/qaeiQiyW4f8kYZ9VVIGgeivy6sSl9CRWNXVI6swpPit1lMgiLP
-+kEczT+XMe9PZEd6jXMK+ECoEmgdeY+F37HGHuLD3132dDffIdR/MX9BURBe+8PV
-Pu7uOOMrD31hjkNCOaQb7v2Uj9frn5phZ3VD/RgzHjlQKN8IRLE8K5oEDWVHny08
-JSFJ9fvS4Mh2coaLMOfgwCGYAPXQGXaytS68Wjrnt/VAdiooORsersTh/FYIhsAQ
-hA4nej/Bz8c7z+v7AevrdDQ+wANbctTjtwmN9aj1vipUnpPWQDYK/bKGNaRWsbvz
-2J18GupQiQKCtVpTClG2nuuzQEZs6KmGFu6ZtJqMPrd2R7+/cAxxaVQL+g32ECGz
-1oZ1mpJRwp9qqK1yZ/Rx/2ys+w3bXDATjY0VvjlRXYJObddG8deO0q9pnjtOsiPI
-S+0QAmXvUUHNbMzqxHcgyBDcgPogAqqL/mgXDuIMHRmJjKCbt8XBKlwI2wjPSNhK
-1DJdfbbSb88Aev5SIItjuvyteAonasj2cwRDw/1z/rKOvRC9bI8deVsRAkNrvGE+
-czE0k9HatbEf+DfQoAQwku9gN7/rkECIMMY3nkFwkB9v2KKDRvA=
-=W/bt
+klDbhBAAsABj4Pxtnw6+5+C6adkEX6qhRvPXHYohf/cjOrKubL1bbRlljC2EQeRq
+S/50GqWgeNED7mfLLD66NIlpl657qhadnVg9LD5puGdYcog6oErc8f67UCVWECX5
+Satp7qkh8oA+5Y6MMek0oVirQedWYTJaPiBVJqScdnaElDa8b2tEMf/ZCEzHG15h
+X+3QfhhZMGDaL+Dlsd7xZzj7dIYo2DOVXvCwRTq8JdDsHPeviD4oO4FYJmVtjWYr
+KTk4NKWbrlYhgJzwGQqxl/7UHWfYsXbuTarioqHKbTzIdH8HQflhp6nypK5NCoSU
+ja3+h8dn5NCPTvP8yFm3n7ZCH0bfAwv89cwG5LBcPbgEyUtNi9auEFqmoSQ/lWBg
+tD+t+6ScUkTnFJrpFd7AzDaMFFQHn5mbGphbIRWGUF2JZBDBLd3y1PsoQaVkSX3i
+xIaRLEnN3vusBOxx3UlUuVSW6WDeazRBheEg3EqQ9UAQ1Pz4K3rCAfnzaYwi0tnZ
+RAf2Is6kuLRGNvGrJ7/ZNqAiRSrUD2NBuEERRZlnLiEVFHXPQP54X86GZ/iQ40pw
+2FwyPz6iyi4wxmhfEsiAaYtusluyYG+bFBmHo361UvQSH1OQtmglII5lvUliv+KR
+W2DXmtb9/30pcYmZKx9xyPtjdmFVgtDS8mRvywwHddZCHsxybDU=
+=VF7m
 -----END PGP SIGNATURE-----
diff --git a/metadata/news/Manifest.files.gz b/metadata/news/Manifest.files.gz
index ebaf491520b3..fcdb44f07a5a 100644
--- a/metadata/news/Manifest.files.gz
+++ b/metadata/news/Manifest.files.gz
diff --git a/metadata/news/timestamp.chk b/metadata/news/timestamp.chk
index 5259482477da..64d6d4b98f8d 100644
--- a/metadata/news/timestamp.chk
+++ b/metadata/news/timestamp.chk
@@ -1 +1 @@
-Sun, 12 Apr 2020 01:38:54 +0000
+Sat, 25 Apr 2020 09:38:53 +0000
diff --git a/metadata/news/timestamp.commit b/metadata/news/timestamp.commit
index 6fcc4a7ef77d..7138643eac5e 100644
--- a/metadata/news/timestamp.commit
+++ b/metadata/news/timestamp.commit
@@ -1 +1 @@
-50254233f26f276c0597fb72614d982657f2227d 1586370336 2020-04-08T18:25:36+00:00
+336bf652c6faf7c15edc4cdc3076392086d6318a 1587585435 2020-04-22T19:57:15+00:00