Merge commit '192df982389eb4606a3d7051b52c082b52455fbd' into master

12 files changed, 7 insertions, 485 deletions

diff --git a/metadata/news/2015-02-02-nfs-service-changes/2015-02-02-nfs-service-changes.en.txt b/metadata/news/2015-02-02-nfs-service-changes/2015-02-02-nfs-service-changes.en.txt
deleted file mode 100644
index 7e1b2be650ca..000000000000
--- a/metadata/news/2015-02-02-nfs-service-changes/2015-02-02-nfs-service-changes.en.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-Title: nfs service changes
-Author: William Hubbs <williamh@gentoo.org>
-Content-Type: text/plain
-Posted: 2015-02-02
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: <=net-fs/nfs-utils-1.3.1-r1
-
-The upgrade to nfs-utils-1.3.1-r1 includes significant service changes
-both for OpenRC and systemd users.
-
-OpenRC users:
-
-The OpenRC service which handled mounting nfs file systems has been
-changed to only start the nfs client daemons and renamed to nfsclient.
-Because of this change, if you use OpenRC and mount nfs file systems,
-you need to perform the following steps:
-
-Add nfsclient to the runlevel nfsmount was in before. For example, if
-nfsmount was in the default runlevel, run this command:
-
-rc-update add nfsclient default
-
-If you use a permanent network connection to the server, make sure
-netmount is in the same runlevel as nfsclient. If not, it is recommended
-that net-fs/autofs be set up to handle your network mounts.
-
-Systemd users:
-
-The nfs systemd units have been renamed.  If you are exporting nfs
-mounts, you should enable the rpcbind and nfs-server services.  If you
-are mounting nfs mounts systemd should automatically detect this and
-start the nfs-client service.
-
-More Information:
-
-The following wiki page has more information about nfs file systems:
-
-http://wiki.gentoo.org/wiki/NFSv4
diff --git a/metadata/news/2015-02-04-portage-sync-changes/2015-02-04-portage-sync-changes.en.txt b/metadata/news/2015-02-04-portage-sync-changes/2015-02-04-portage-sync-changes.en.txt
deleted file mode 100644
index aeff021602be..000000000000
--- a/metadata/news/2015-02-04-portage-sync-changes/2015-02-04-portage-sync-changes.en.txt
+++ /dev/null
@@ -1,77 +0,0 @@
-Title: New portage plug-in sync system
-Author: Brian Dolbec <dolsen@gentoo.org>
-Content-Type: text/plain
-Posted: 2015-02-02
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: <sys-apps/portage-2.3.62
-
-There is a new plug-in sync system in >=sys-apps/portage-2.2.16.
-This system will allow third party modules to be easily installed.  Look
-for a new layman plug-in sync module in layman's next release.  Next is
-a brief look at the changes.  See the url [1] listed below for detailed
-descriptions and usage.
-
-Changes:  /etc/portage/repos.conf/*
-    New setting for all repository types (needed):
-        auto-sync = yes/no, true/false  # default if absent: yes/true
-
-    New for git sync-type: (applies to clone only)
-        sync-depth = n  where n = {0,1,2,3,...} (optional, default = 1)
-            0 -- full history
-            1 -- shallow clone, only current state (default)
-            2,3,... number of history changes to download
-
-    New sync-type modules:
-        sync-type = svn  # sync a subversion repository
-        sync-type = websync # Perform an emerge-webrsync operation
-        sync-type = laymanator  # (if installed) runs a layman -s action
-
-    New native portage postsync hooks
-        /etc/portage/postsync.d/*
-            Runs hooks once, only after all repos have been synced.
-        /etc/portage/repo.postsync.d/*
-            Runs each script with three arguments:
-                repo name, sync-uri, location
-            Each script is run at the completion of every repo synced.
-
-Migration:
-    Edit /etc/portage/repos.conf/*.conf files, add the auto-sync option
-    to each repository definition.  Edit sync-type option to one of the
-    supported types {rsync, git, cvs, svn, websync, laymanator}.
-        [some-repo]
-        ...
-        sync-type = rsync
-        auto-sync = yes
-
-    For an existing /etc/portage/repos.conf/layman.conf file:
-        1) change/add the sync-type
-            sync-type = laymanator
-        2) Ensure you have the correct layman version installed with
-           it's laymanator module also installed.
-    Alternate method:
-        Please see the wiki page url [1] for detailed instructions.
-
-Primary control of all sync operations has been moved from emerge to
-emaint.  "emerge --sync" now just calls the emaint sync module with the
---auto option.  The --auto option performs a sync on only those
-repositories with the auto-sync setting not set to 'no' or 'false'. If
-it is absent, then it will default to yes and "emerge --sync" will sync
-the repository.
-
-NOTE: As a result of the default auto-sync = True/Yes setting, commands
-    like "eix-sync", "esync -l", "emerge --sync && layman -S" will cause
-    many repositories to be synced multiple times in a row.  Please edit
-    your configs or scripts to adjust for the new operation.
-
-WARNING:
-    Due to the above default. For any repos that you EXPLICITLY do not
-    want to be synced. You MUST set "auto-sync = no"
-
-The 'emaint sync' module operates similar to layman.  It can sync
-single or multiple repos.  See "emaint --help" or for more details and
-examples see the wiki page listed below [1].
-
-Additional help and project API documentation can be found at:
-
-[1] https://wiki.gentoo.org/wiki/Project:Portage/Sync
diff --git a/metadata/news/2015-04-06-apache-addhandler-addtype/2015-04-06-apache-addhandler-addtype.en.txt b/metadata/news/2015-04-06-apache-addhandler-addtype/2015-04-06-apache-addhandler-addtype.en.txt
deleted file mode 100644
index f90d09191dee..000000000000
--- a/metadata/news/2015-04-06-apache-addhandler-addtype/2015-04-06-apache-addhandler-addtype.en.txt
+++ /dev/null
@@ -1,100 +0,0 @@
-Title: Apache AddHandler/AddType exploit protection
-Author: Sebastian Pipping <sping@gentoo.org>
-Content-Type: text/plain
-Posted: 2015-04-06
-Revision: 2
-News-Item-Format: 1.0
-Display-If-Installed: www-servers/apache
-
-Apache's directives AddHandler [1] and AddType [2] can be used
-to map certain file name extensions (e.g. .php) to a handler
-(e.g. application/x-httpd-php).  While a line like
-
-  AddHandler application/x-httpd-php .php .php5 .phtml
-     ^^^^^^^
-matches index.php, it also matches index.php.png.
-With
-
-  AddType application/x-httpd-php .php .php5 .phtml
-     ^^^^
-index.php.png is not executed, but index.php.disabled still is.
-
-
-Apache's notes on multiple file extensions [3] document
-a multi-language website as a context where that behavior
-may be helpful.  Unfortunately, it can also be a security threat.
-
-Combined with (not just PHP) applications that support
-file upload, the AddHandler/AddType directive can get you into
-remote code execution situations.
-
-That is why >=app-eselect/eselect-php-0.7.1-r4 avoids AddHandler
-and is shipping
-
-  <FilesMatch "\.(php|php5|phtml)$">
-    SetHandler application/x-httpd-php
-  </FilesMatch>
-
-instead.
-
-
-Why this news entry?
-
- * Since Apache configuration lives below /etc,
-   you need to run etc-update (or a substitute)
-   to actually have related fixes applied.
-   To get them into the running instance of Apache,
-   you need to make it reload its configuration, e.g.
-
-     sudo /etc/init.d/apache2 reload
-
- * If you are currently relying on AddHandler to execute
-   secret_database_stuff.php.inc, moving away from AddHandler
-   could result in serving your database credentials in plain
-   text.  A command like
-
-     find /var/www/ -name '*.php.*' \
-                 -o -name '*.php5.*' \
-                 -o -name '*.phtml.*'
-
-   may help discovering PHP files that would no longer be executed.
-
-   Shipping automatic protection for this scenario is not trivial,
-   but you could manually install protection based on this recipe:
-
-     <FilesMatch "\.(php|php5|phtml|phps)\.">
-       # a) Apache 2.2 / Apache 2.4 + mod_access_compat
-       #Order Deny,Allow
-       #Deny from all
-
-       # b) Apache 2.4 + mod_authz_core
-       #Require all denied
-
-       # c) Apache 2.x + mod_rewrite
-       #RewriteEngine on
-       #RewriteRule .* - [R=404,L]
-     </FilesMatch>
-
- * You may be using AddHandler or AddType in other places,
-   including off-package files.  Please have a look.
-
- * app-eselect/eselect-php is not the only package affected.
-   There is a dedicated tracker bug at [4].
-   As of the moment, affected packages include:
-
-     app-eselect/eselect-php[apache2]
-     net-nds/gosa-core
-     www-apache/mod_fastcgi
-     www-apache/mod_flvx
-     www-apache/mod_python
-     www-apache/mod_suphp
-     www-apps/moinmoin
-     www-apps/rt[-lighttpd]
-
-
-Thanks to Nico Suhl, Michael Orlitzky and Marc Schiffbauer.
-
-[1] https://httpd.apache.org/docs/current/mod/mod_mime.html#addhandler
-[2] https://httpd.apache.org/docs/current/mod/mod_mime.html#addtype
-[3] https://httpd.apache.org/docs/current/mod/mod_mime.html#multipleext
-[4] https://bugs.gentoo.org/show_bug.cgi?id=544560
diff --git a/metadata/news/2015-05-01-shorewall-changes/2015-05-01-shorewall-changes.en.txt b/metadata/news/2015-05-01-shorewall-changes/2015-05-01-shorewall-changes.en.txt
deleted file mode 100644
index 08d1cdbf1bb4..000000000000
--- a/metadata/news/2015-05-01-shorewall-changes/2015-05-01-shorewall-changes.en.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-Title: shorewall is now a single package
-Author: Ian Delaney <idella4@gentoo.org>
-Content-Type: text/plain
-Posted: 2015-05-01
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: net-firewall/shorewall-core
-Display-If-Installed: net-firewall/shorewall6
-Display-If-Installed: net-firewall/shorewall-lite
-Display-If-Installed: net-firewall/shorewall6-lite
-Display-If-Installed: net-firewall/shorewall-init
-
-Starting with net-firewall/shorewall-4.6 we have re-integrated
-
-  - net-firewall/shorewall-core
-  - net-firewall/shorewall6
-  - net-firewall/shorewall-lite
-  - net-firewall/shorewall6-lite
-  - net-firewall/shorewall-init
-
-into a new all-in-one net-firewall/shorewall ebuild (see bug 522278).
-
-The new all-in-one ebuild makes maintenance a lot more easier because the
-package is proxy-maintained and finding someone who is willing to help
-you bumping 6 packages each time you provide an update was not easy in
-the past.
-
-Because net-firewall/shorewall{-core,6,-lite,6-lite,init} is now
-integrated in net-firewall/shorewall, we have to hard mask these old
-ebuilds in the new monolithic ebuild to prevent file collisions.
-
-Due to this block we cannot migrate to the new version without user
-interaction. Please remove the previous split ebuilds from your system if
-you want to upgrade:
-
-  $ emerge --ask --unmerge 'net-firewall/shorewall-*' \
-            'net-firewall/shorewall6*'
-
-
-Please note:
-Since the second shorewall-4.6 ebuild is now stabilized and shorewall-4.5
-is not compatible with the perl-5.20 (see bug 524558) we will start the
-removal process for shorewall-4.5 ebuilds within the next 30 days.
diff --git a/metadata/news/2015-06-08-udev-init-scripts-changes/2015-06-08-udev-init-scripts-changes.en.txt b/metadata/news/2015-06-08-udev-init-scripts-changes/2015-06-08-udev-init-scripts-changes.en.txt
deleted file mode 100644
index 5ab36d74f995..000000000000
--- a/metadata/news/2015-06-08-udev-init-scripts-changes/2015-06-08-udev-init-scripts-changes.en.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Title: udev-init-scripts-29 important changes
-Author: William Hubbs <williamh@gentoo.org>
-Content-Type: text/plain
-Posted: 2015-06-08
-Revision: 2
-News-Item-Format: 1.0
-Display-If-Installed: <=sys-fs/udev-init-scripts-29
-
-In udev-init-scripts-29 and newer, the udev service script has been
-split into udev, udev-settle and udev-trigger.
-
-This means the settings in /etc/conf.d/udev have also been migrated
-to the appropriate /etc/conf.d files, so be careful when you update your
-configuration settings.
-
-udev and udev-trigger will be added to your sysinit runlevel, but not
-udev-settle. udev-settle should not be added to a runlevel. Instead, if
-a service needs this, it should add "need udev-settle" to its
-dependencies.
-
diff --git a/metadata/news/2015-08-11-nepomuk-removal/2015-08-11-nepomuk-removal.en.txt b/metadata/news/2015-08-11-nepomuk-removal/2015-08-11-nepomuk-removal.en.txt
deleted file mode 100644
index 488c980fbed5..000000000000
--- a/metadata/news/2015-08-11-nepomuk-removal/2015-08-11-nepomuk-removal.en.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Title: Nepomuk removal
-Author: Johannes Huber <johu@gentoo.org>
-Content-Type: text/plain
-Posted: 2015-08-11
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: dev-db/virtuoso-server
-
-With KDE SC 4.13.0 release the default semantic desktop search engine
-switched from Nepomuk to Baloo.[1] This change was honoured in Gentoo
-by changing the semantic-desktop use flag to cover the new engine and
-moving the old to nepomuk use flag.
-
-The underlaying storage backend for Nepomuk aka Virtuoso DB has a lot
-of unsolved upstream issues[2], therefore we will remove it. This means
-packages with build options on the old stack will drop them. Other
-packages which hard requiring it will be removed.
-
-If you are still using Nepomuk you can switch to Baloo by globally
-enable semantic-desktop and disabling nepomuk use flag in
-/etc/portage/make.conf or using one of the kde desktop profiles.
-
-[1] https://www.kde.org/announcements/4.13/
-[2] https://bugs.gentoo.org/buglist.cgi?quicksearch=virtuoso
diff --git a/metadata/news/2015-08-26-ruby-19-removal/2015-08-26-ruby-19-removal.en.txt b/metadata/news/2015-08-26-ruby-19-removal/2015-08-26-ruby-19-removal.en.txt
deleted file mode 100644
index 97c2465f7004..000000000000
--- a/metadata/news/2015-08-26-ruby-19-removal/2015-08-26-ruby-19-removal.en.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Title: Ruby 1.9 removal; Ruby 2.0/2.1 default
-Author: Manuel Rüger <mrueg@gentoo.org>
-Content-Type: text/plain
-Posted: 2015-08-26
-Revision: 2
-News-Item-Format: 1.0
-Display-If-Installed: <dev-lang/ruby-2.0
-
-Ruby MRI 1.9 has been retired by upstream in February 2015.[1]
-We remove Ruby MRI 1.9 support from the tree now. In parallel Ruby MRI 2.1 
-support will be activated in base profile's RUBY_TARGETS variable by default 
-in conjunction with Ruby MRI 2.0.
-
-If your currently eselected Ruby interpreter is ruby19, our recommendation is 
-to change it to ruby20. At the moment Ruby MRI 2.0 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 2.0 via:
-
-	eselect ruby set ruby20
-
-[1] https://www.ruby-lang.org/en/news/2015/02/23/support-for-ruby-1-9-3-has-ended/
diff --git a/metadata/news/2015-09-09-libvirt-init-script-changes/2015-09-09-libvirt-init-script-changes.en.txt b/metadata/news/2015-09-09-libvirt-init-script-changes/2015-09-09-libvirt-init-script-changes.en.txt
deleted file mode 100644
index 83ed083c6ce1..000000000000
--- a/metadata/news/2015-09-09-libvirt-init-script-changes/2015-09-09-libvirt-init-script-changes.en.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Title: libvirt-1.2.19 init script changes
-Author: Doug Goldstein <cardoe@gentoo.org>
-Content-Type: text/plain
-Posted: 2015-09-09
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: <app-emulation/libvirt-1.2.19
-
-OpenRC Users:
-
-In libvirt-1.2.19 and newer, the libvirtd init script has been split into
-libvirtd and libvirt-guests.
-
-The purpose of this change is to separate the management of the libvirtd
-daemon from the libvirt domains/guests. This means that a number of settings
-from /etc/conf.d/libvirtd have been moved to /etc/conf.d/libvirt-guests. These
-settings have not been auto-migrated and you are advised to review
-/etc/conf.d/libvirt-guests to ensure the behaviors are as you expect.
-
-You must add libvirt-guests to the same runlevel where you run libvirtd
-currently. Otherwise your domains/guests will not be gracefully shutdown and
-could result in data loss. To do this run the following commands:
-  $ rc-update add libvirt-guests
-  $ service libvirt-guests start
diff --git a/metadata/news/2015-10-07-openrc-0-18-localmount-and-netmount-changes/2015-10-07-openrc-0-18-localmount-and-netmount-changes.en.txt b/metadata/news/2015-10-07-openrc-0-18-localmount-and-netmount-changes/2015-10-07-openrc-0-18-localmount-and-netmount-changes.en.txt
deleted file mode 100644
index 7b2b688d7147..000000000000
--- a/metadata/news/2015-10-07-openrc-0-18-localmount-and-netmount-changes/2015-10-07-openrc-0-18-localmount-and-netmount-changes.en.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Title: OpenRC-0.18 localmount and netmount changes
-Author: William Hubbs <williamh@gentoo.org>
-Content-Type: text/plain
-Posted: 2015-10-07
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: <=sys-apps/openrc-0.18
-
-The behaviour of localmount and netmount is changing on Linux systems.
-In the past, these services always started successfully. However, now they
-will fail if a file system they attempt to mount cannot be mounted.
-
-If you have file systems listed in fstab which should not be mounted at
-boot time, make sure to add noauto to the mount options. If you have
-file systems that you want to attempt to mount at boot time but failure
-should be allowed, add nofail to the mount options for these file
-systems in fstab.
diff --git a/metadata/news/2015-10-21-future-support-of-hardened-sources-kernel/2015-10-21-future-support-of-hardened-sources-kernel.en.txt b/metadata/news/2015-10-21-future-support-of-hardened-sources-kernel/2015-10-21-future-support-of-hardened-sources-kernel.en.txt
deleted file mode 100644
index 3d5c76cba3d4..000000000000
--- a/metadata/news/2015-10-21-future-support-of-hardened-sources-kernel/2015-10-21-future-support-of-hardened-sources-kernel.en.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-Title: Future Support of hardened-sources Kernel
-Author: Anthony G. Basile <blueness@gentoo.org>
-Content-Type: text/plain
-Posted: 2015-10-21
-Revision: 3
-News-Item-Format: 1.0
-Display-If-Installed: sys-kernel/hardened-sources
-Display-If-Profile: hardened/linux/amd64
-Display-If-Profile: hardened/linux/amd64/no-multilib
-Display-If-Profile: hardened/linux/amd64/no-multilib/selinux
-Display-If-Profile: hardened/linux/amd64/selinux
-Display-If-Profile: hardened/linux/amd64/x32
-Display-If-Profile: hardened/linux/arm/armv6j
-Display-If-Profile: hardened/linux/arm/armv7a
-Display-If-Profile: hardened/linux/ia64
-Display-If-Profile: hardened/linux/musl/amd64
-Display-If-Profile: hardened/linux/musl/amd64/x32
-Display-If-Profile: hardened/linux/musl/arm/armv7a
-Display-If-Profile: hardened/linux/musl/mips
-Display-If-Profile: hardened/linux/musl/mips/mipsel
-Display-If-Profile: hardened/linux/musl/ppc
-Display-If-Profile: hardened/linux/musl/x86
-Display-If-Profile: hardened/linux/powerpc/ppc32
-Display-If-Profile: hardened/linux/powerpc/ppc64/32bit-userland
-Display-If-Profile: hardened/linux/powerpc/ppc64/64bit-userland
-Display-If-Profile: hardened/linux/uclibc/amd64
-Display-If-Profile: hardened/linux/uclibc/arm/armv7a
-Display-If-Profile: hardened/linux/uclibc/mips
-Display-If-Profile: hardened/linux/uclibc/mips/mipsel
-Display-If-Profile: hardened/linux/uclibc/ppc
-Display-If-Profile: hardened/linux/uclibc/x86
-Display-If-Profile: hardened/linux/x86
-Display-If-Profile: hardened/linux/x86/selinux
-
-For many years, the Grsecurity team [1] has been supporting two versions of
-their security patches against the Linux kernel, a stable and a testing
-version, and Gentoo has made both of these available to our users through the
-hardened-sources package.  However, on August 26 of this year, the team
-announced they would no longer be making the stable version publicly
-available, citing trademark infringement by a major embedded systems company
-as the reason. [2]  The stable patches are now only available to sponsors of
-Grsecurity and can no longer be distributed in Gentoo.  However, the team did
-assure us that they would continue to release and support the testing version
-as they have in the past.
-
-What does this means for users of hardened-sources?  Gentoo will continue to
-make the testing version available through our hardened-sources package but we
-will have to drop support for the 3.x series.  In a few days, those ebuilds
-will be removed from the tree and you will be required to upgrade to a 4.x
-series kernel.  Since the hardened-sources package only installs the kernel
-source tree, you can continue using a currently built 3.x series kernel but
-bear in mind that we cannot support you, nor will upstream.  Also keep in mind
-that the 4.x series will not be as reliable as the 3.x series was, so
-reporting bugs promptly will be even more important.  Gentoo will continue to
-work closely with upstream to stay on top of any problems, but be prepared for
-the occasional "bad" kernel.  The more reporting we receive from our users,
-the better we will be able to decide which hardened-sources kernels to mark
-stable and which to drop.
-
-Refs.
-[1] https://grsecurity.net
-[2] https://grsecurity.net/announce.php
diff --git a/metadata/news/2015-12-16-python-abiflags-rebuild-needed/2015-12-16-python-abiflags-rebuild-needed.en.txt b/metadata/news/2015-12-16-python-abiflags-rebuild-needed/2015-12-16-python-abiflags-rebuild-needed.en.txt
deleted file mode 100644
index 7fa3adea7a79..000000000000
--- a/metadata/news/2015-12-16-python-abiflags-rebuild-needed/2015-12-16-python-abiflags-rebuild-needed.en.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-Title: Python ABIFLAGS rebuild needed
-Author: Mike Gilbert <floppym@gentoo.org>
-Content-Type: text/plain
-Posted: 2015-12-16
-Revision: 5
-News-Item-Format: 1.0
-Display-If-Installed: =dev-lang/python-3.3.5-r4
-Display-If-Installed: =dev-lang/python-3.3.5-r5
-Display-If-Installed: =dev-lang/python-3.3.5-r6
-Display-If-Installed: =dev-lang/python-3.3.5-r7
-Display-If-Installed: =dev-lang/python-3.3.5-r8
-Display-If-Installed: =dev-lang/python-3.3.5-r9
-Display-If-Installed: ~dev-lang/python-3.3.6
-Display-If-Installed: =dev-lang/python-3.4.3-r4
-Display-If-Installed: =dev-lang/python-3.4.3-r5
-Display-If-Installed: =dev-lang/python-3.4.3-r6
-Display-If-Installed: =dev-lang/python-3.4.3-r7
-Display-If-Installed: =dev-lang/python-3.4.3-r8
-Display-If-Installed: =dev-lang/python-3.4.3-r9
-Display-If-Installed: ~dev-lang/python-3.4.4
-Display-If-Installed: ~dev-lang/python-3.4.5
-Display-If-Installed: =dev-lang/python-3.5.0-r3
-Display-If-Installed: =dev-lang/python-3.5.0-r4
-Display-If-Installed: =dev-lang/python-3.5.0-r5
-Display-If-Installed: =dev-lang/python-3.5.0-r6
-Display-If-Installed: =dev-lang/python-3.5.0-r7
-Display-If-Installed: =dev-lang/python-3.5.0-r8
-Display-If-Installed: =dev-lang/python-3.5.0-r9
-Display-If-Installed: ~dev-lang/python-3.5.1
-Display-If-Installed: ~dev-lang/python-3.5.2
-
-For several years, Gentoo has been patching python3 in a way that is
-incompatible with PEP 3149 [1]. Gentoo has been enabling the PyMalloc feature,
-but our python packages have not carried the appropriate ABI flag.
-
-We have removed this patch from the most recent dev-lang/python ebuilds at
-the time of this writing. One result of this is that any packages which
-install python extension modules must be rebuilt.
-
-You may experience build failures in related packages until this rebuild has
-been completed.
-
-You can rebuild affected packages using the following commands.
-
-emerge -1v $(find /usr/lib*/python3* -name '*cpython-3[3-5].so')
-emerge -1v /usr/include/python3.{3,4,5}
-
-It is possible that these commands will do nothing (or display a syntax error)
-if all affected packages have already been rebuilt, causing the relevent files
-to no longer exist.
-
-References:
-[1] https://www.python.org/dev/peps/pep-3149/
diff --git a/metadata/news/README b/metadata/news/README
new file mode 100644
index 000000000000..63cbead22366
--- /dev/null
+++ b/metadata/news/README
@@ -0,0 +1,7 @@
+Copyright of Gentoo news items is held by their respective authors
+and translators.
+
+All news items committed after 2018-10-21 are licensed under the
+Creative Commons Attribution-ShareAlike 4.0 International License.
+Visit https://creativecommons.org/licenses/by-sa/4.0/ to view a copy
+of this license.