diff options
Diffstat (limited to 'metadata/news')
108 files changed, 3757 insertions, 0 deletions
diff --git a/metadata/news/2007-05-04-paludis-0_24/2007-05-04-paludis-0_24.en.txt b/metadata/news/2007-05-04-paludis-0_24/2007-05-04-paludis-0_24.en.txt new file mode 100644 index 000000000000..d66e7741600e --- /dev/null +++ b/metadata/news/2007-05-04-paludis-0_24/2007-05-04-paludis-0_24.en.txt @@ -0,0 +1,12 @@ +Title: Changes for Paludis 0.24 +Author: Piotr Jaroszyński <peper@gentoo.org> +Content-Type: text/plain +Posted: 2007-05-04 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Installed: <sys-apps/paludis-0.30 + +As of Paludis 0.24, the use of '*' to match all packages in the Paludis +configuration files 'use.conf', 'keywords.conf' and 'licenses.conf' is +deprecated in favour of '*/*'. You should update your configuration +files after upgrading. diff --git a/metadata/news/2009-01-04-sparc-multilib/2009-01-04-sparc-multilib.en.txt b/metadata/news/2009-01-04-sparc-multilib/2009-01-04-sparc-multilib.en.txt new file mode 100644 index 000000000000..f3e9bf3ace6a --- /dev/null +++ b/metadata/news/2009-01-04-sparc-multilib/2009-01-04-sparc-multilib.en.txt @@ -0,0 +1,17 @@ +Title: Migrating to the new sparc multilib profile +Author: Friedrich Oslage <bluebird@gentoo.org> +Content-Type: text/plain +Posted: 2009-01-04 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Profile: default/linux/sparc/experimental/multilib +Display-If-Profile: default/linux/sparc/experimental/multilib/desktop +Display-If-Profile: default/linux/sparc/experimental/multilib/developer +Display-If-Profile: default/linux/sparc/experimental/multilib/server + +When migrating to the new sparc multilib profile please keep in mind that it is +still in an experimental state. Also note that you need to follow the migration +guide [0], otherwise important packages such as gcc or glibc will fail to +compile and most other packages will be installed incorrectly. + +[0] http://sparc.gentoo.org/multilib.xml diff --git a/metadata/news/2009-04-06-tetex/2009-04-06-tetex.en.txt b/metadata/news/2009-04-06-tetex/2009-04-06-tetex.en.txt new file mode 100644 index 000000000000..9546708820c7 --- /dev/null +++ b/metadata/news/2009-04-06-tetex/2009-04-06-tetex.en.txt @@ -0,0 +1,14 @@ +Title: Migration from teTeX to TeXLive +Author: Christian Faulhammer <fauli@gentoo.org> +Author: Ulrich Müller <ulm@gentoo.org> +Author: Alexis Ballier <aballier@gentoo.org> +Content-Type: text/plain +Posted: 2009-04-06 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: app-text/tetex + +teTeX is obsolete and has been unsupported upstream since May of 2006. +All users who still have teTeX installed should uninstall it and install +TeXLive using the upgrade guide accessible at the following URL: + http://www.gentoo.org/proj/en/tex/texlive-migration-guide.xml diff --git a/metadata/news/2009-04-06-x_server-1_5/2009-04-06-x_server-1_5.en.txt b/metadata/news/2009-04-06-x_server-1_5/2009-04-06-x_server-1_5.en.txt new file mode 100644 index 000000000000..c92df9859ab1 --- /dev/null +++ b/metadata/news/2009-04-06-x_server-1_5/2009-04-06-x_server-1_5.en.txt @@ -0,0 +1,15 @@ +Title: Migration to X.org Server 1.5 +Author: Remi Cardona <remi@gentoo.org> +Author: Christian Faulhammer <fauli@gentoo.org> +Content-Type: text/plain +Posted: 2009-04-06 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <x11-base/xorg-server-1.5 + +A lot of changes regarding device recognition and use by the X server +have been introduced in the 1.5 update. As that version is going +stable on all architectures, users should read the upgrade guide [0] +before actually updating the package. + +[0] http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml diff --git a/metadata/news/2009-07-12-xorg-74-alpha/2009-07-12-xorg-74-alpha.en.txt b/metadata/news/2009-07-12-xorg-74-alpha/2009-07-12-xorg-74-alpha.en.txt new file mode 100644 index 000000000000..a275ec14d719 --- /dev/null +++ b/metadata/news/2009-07-12-xorg-74-alpha/2009-07-12-xorg-74-alpha.en.txt @@ -0,0 +1,24 @@ +Title: xorg-x11-7.4 and xorg-server-1.5 kernel support +Author: Tobias Klausmann <klausman@gentoo.org> +Content-Type: text/plain +Posted: 2009-07-12 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: x11-base/xorg-server +Display-If-Profile: default-linux/alpha +Display-If-Profile: default/linux/alpha + +Recent versions of xorg's X11 require kernel support to access PCI and AGP +graphic cards. This support has only recently been added to the Linux kernel +(sys-kernel/vanilla-sources-2.6.30 and sys-kernel/gentoo-sources-2.6.29-r5). +Thus, you will need to run a recent enough kernel to use recent versions of X11 +on an alpha. If you only start programs on your alpha, but the display is on +another machine, no upgrade is necessary. + +Furthermore, not all graphics card drivers have been updated to work with the +newer X server API. One example is the glint driver used for Permedia cards. The +upstream developers have been informed about this, but no fixes are available +yet, please see https://bugs.freedesktop.org/show_bug.cgi?id=21546 + +For a general guide to upgrading to Xorg 1.5, see the Gentoo upgrade guide: +http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml diff --git a/metadata/news/2009-10-02-xorg-server-1-6-libxcb-1_4/2009-10-02-xorg-server-1-6-libxcb-1_4.en.txt b/metadata/news/2009-10-02-xorg-server-1-6-libxcb-1_4/2009-10-02-xorg-server-1-6-libxcb-1_4.en.txt new file mode 100644 index 000000000000..886f7f902eed --- /dev/null +++ b/metadata/news/2009-10-02-xorg-server-1-6-libxcb-1_4/2009-10-02-xorg-server-1-6-libxcb-1_4.en.txt @@ -0,0 +1,15 @@ +Title: Migration to X.org Server 1.6 and libxcb 1.4 +Author: Remi Cardona <remi@gentoo.org> +Content-Type: text/plain +Posted: 2009-10-02 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <x11-base/xorg-server-1.6 +Display-If-Installed: <x11-libs/libxcb-1.4 + +We're pleased to announce the stabilization of xorg-server-1.6. Users +are strongly encouraged to read the following two guides before +upgrading: + +http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml +http://www.gentoo.org/proj/en/desktop/x/x11/libxcb-1.4-upgrade-guide.xml diff --git a/metadata/news/2009-10-08-gnome-226/2009-10-08-gnome-226.en.txt b/metadata/news/2009-10-08-gnome-226/2009-10-08-gnome-226.en.txt new file mode 100644 index 000000000000..065e675c5d7b --- /dev/null +++ b/metadata/news/2009-10-08-gnome-226/2009-10-08-gnome-226.en.txt @@ -0,0 +1,19 @@ +Title: Upgrade to GNOME 2.26 +Author: Mart Raudsepp <leio@gentoo.org> +Content-Type: text/plain +Posted: 2009-10-08 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <gnome-base/gnome-2.26.0 +Display-If-Installed: <gnome-base/gnome-light-2.26.0 +Display-If-Installed: <gnome-base/gnome-session-2.26.2 +Display-If-Installed: <gnome-base/gnome-menus-2.26.2 + +We are pleased to announce the stabilization of GNOME-2.26. Users are +strongly encouraged to read the GNOME 2.26 Upgrade Guide, to avoid any +possible issues relating to the upgrade, such as Applications menu items +disappearing, or nautilus constantly restarting when it is configured to +not handle the desktop. + +Please read the Gnome 2.26 Upgrade Guide: +http://gnome.gentoo.org/howtos/gnome-2.26-upgrade.xml diff --git a/metadata/news/2009-10-22-default-linux/2009-10-22-default-linux.en.txt b/metadata/news/2009-10-22-default-linux/2009-10-22-default-linux.en.txt new file mode 100644 index 000000000000..88ca0e041566 --- /dev/null +++ b/metadata/news/2009-10-22-default-linux/2009-10-22-default-linux.en.txt @@ -0,0 +1,29 @@ +Title: Using default-linux profile is now obsolete +Author: Samuli Suominen <ssuominen@gentoo.org> +Content-Type: text/plain +Posted: 2009-10-22 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Profile: default-linux/alpha +Display-If-Profile: default-linux/amd64 +Display-If-Profile: default-linux/arm +Display-If-Profile: default-linux/ia64 +Display-If-Profile: default-linux/m68k +Display-If-Profile: default-linux/s390 +Display-If-Profile: default-linux/sh +Display-If-Profile: default-linux/sparc +Display-If-Profile: default-linux/x86 + +The profiles in default-linux/ have been deprecated for six weeks. +Users using these profiles are expected to migrate to a new profile +before 2009-12-01, at which point the default-linux/ profiles will be +removed. The new profiles contain up to date configurations and were +adopted because they were easier to maintain. Users can switch to a +new profile using eselect: + +# eselect profile list +# eselect profile set <target> + +If a machine is not migrated to a new valid profile before the deprecated +profiles are removed, emerge will have very limited functionality until +the migration is done. diff --git a/metadata/news/2010-01-31-eselect-opengl/2010-01-31-eselect-opengl.en.txt b/metadata/news/2010-01-31-eselect-opengl/2010-01-31-eselect-opengl.en.txt new file mode 100644 index 000000000000..469d62a92243 --- /dev/null +++ b/metadata/news/2010-01-31-eselect-opengl/2010-01-31-eselect-opengl.en.txt @@ -0,0 +1,16 @@ +Title: Removal of libGL.la +Author: Tomáš Chvátal <scarabeus@gentoo.org> +Content-Type: text/plain +Posted: 2010-01-31 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <app-admin/eselect-opengl-1.1.1-r2 + +Eselect-opengl package now strips the libGL.la file. This file was broken and +thus we proceeded with its removal. It brings slight inconvenience on you fellow +users. After emerging the new version =app-admin/eselect-opengl-1.1.1-r2 please +emerge one more package dev-util/lafilefixer and use it for fixing all various +compilation issues by running as root: +# lafilefixer --justfixit +Note that not-running this command will bring you compilation issues so you +should really pay attention to this message and act upon it. diff --git a/metadata/news/2010-02-21-mysql-upgrade/2010-02-21-mysql-upgrade.en.txt b/metadata/news/2010-02-21-mysql-upgrade/2010-02-21-mysql-upgrade.en.txt new file mode 100644 index 000000000000..493bab44e468 --- /dev/null +++ b/metadata/news/2010-02-21-mysql-upgrade/2010-02-21-mysql-upgrade.en.txt @@ -0,0 +1,25 @@ +Title: MySQL 5.1 unmasking and upgrade procedures +Author: Robin H. Johnson <robbat2@gentoo.org> +Content-Type: text/plain +Posted: 2010-02-21 +Revision: 5 +News-Item-Format: 1.0 +Display-If-Installed: <dev-db/mysql-5.1 + +The 5.1 series of MySQL is going to be unmasked at the same time as the release +of this news item. When upgrading from an older major version (including 5.0), +you will be required to rebuild everything linked to the libmysqlclient.so.15 +and libmysqlclient_r.so.15. + +You can do this by installing app-portage/gentoolkit and running: +# revdep-rebuild --library libmysqlclient.so.15 +# revdep-rebuild --library libmysqlclient_r.so.15 + +If you use the Portage 2.2 series, you may also use: +# emerge @preserved-rebuild + +The official upgrade documentation is available here: +http://dev.mysql.com/doc/refman/5.1/en/upgrading.html + +Note that existing databases may need converting as well, again including those +upgrading from 5.0 to 5.1. Details are in the update documentation. diff --git a/metadata/news/2010-02-28-layman-storage-path-change/2010-02-28-layman-storage-path-change.en.txt b/metadata/news/2010-02-28-layman-storage-path-change/2010-02-28-layman-storage-path-change.en.txt new file mode 100644 index 000000000000..5726373ce128 --- /dev/null +++ b/metadata/news/2010-02-28-layman-storage-path-change/2010-02-28-layman-storage-path-change.en.txt @@ -0,0 +1,41 @@ +Title: Layman storage path changed from version 1.3.0 on +Author: Sebastian Pipping <sping@gentoo.org> +Content-Type: text/plain +Posted: 2010-02-28 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Installed: <app-portage/layman-1.3 + +Layman has been using /usr/local/portage/layman to store +overlay checkouts from version 1.2.3 on. As that path +was violating the concept of keeping portage away from +/usr/local the default of this storage location moves to + + /var/lib/layman + +from version 1.3.0 on. If you have never touched the file +/etc/layman/layman.cfg manually before, you may be tempted to let +tools like etc-update or dispatch-conf blindly accept this new version +of layman.cfg. + +As that would hide all your currently installed overlays from layman +it's probably not what you want. Your options are: + + A) Moving + 1. Move your current content to /var/lib/layman. + 2. Update PORTDIR_OVERLAY in /var/lib/layman/make.conf accordingly. + 3. Make /etc/make.conf source /var/lib/layman/make.conf. + 4. Set option "storage" in /etc/layman/layman.cfg + to "/var/lib/layman". + + B) A symlink + Put a symlink to your current storage location at /var/lib/layman + before upgrading layman. + + C) Configuration + Reject the path change for layman.cfg when running tools like + etc-update or dispatch-conf. Be aware with this way you'll have + to do it for each layman update again. + +PS: This news item is a reaction to users having run into this problem +(see bug #306233). Thanks to Volker Hemmann for reporting. diff --git a/metadata/news/2010-03-01-mythtv-upgrade/2010-03-01-mythtv-upgrade.en.txt b/metadata/news/2010-03-01-mythtv-upgrade/2010-03-01-mythtv-upgrade.en.txt new file mode 100644 index 000000000000..71bf12826ec5 --- /dev/null +++ b/metadata/news/2010-03-01-mythtv-upgrade/2010-03-01-mythtv-upgrade.en.txt @@ -0,0 +1,35 @@ +Title: MythTV 0.22 Upgrade Database Corruption +Author: Richard Freeman <rich0@gentoo.org> +Content-Type: text/plain +Posted: 2010-03-01 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <media-tv/mythtv-0.22 + +Due to an incompatibility between MythTV 0.21 and the default Gentoo +MySQL configuration, it is likely that long-time MythTV users will +have databases with a mixture of locale encodings. If you upgrade to +0.22 without following these directions carefully, you could end up +with a database that contains errors that are extremely difficult to +fix. + +Note that not all mythtv users need to modify their databases, and +this should only be performed at the time of the upgrade. The guide +below contains instructions that can be used to determine if this +problem pertains to you. + +Please see the MythTV Upgrade Guide for instructions: + + http://wiki.mythtv.org/wiki/Fixing_Corrupt_Database_Encoding + +Be sure to save a database backup using mysqldump before upgrading. +Also, be sure to upgrade any other clients/backends you are using to +0.22 at the same time. The upgrade instructions need to be followed +once per database - individual client/backend upgrades do not require +these steps. + +If you do run into problems with your upgrade, there is a forum thread +where you may be able to find help: + + http://forums.gentoo.org/viewtopic-t-816566-highlight-.html + diff --git a/metadata/news/2010-03-23-new-subprofiles/2010-03-23-new-subprofiles.en.txt b/metadata/news/2010-03-23-new-subprofiles/2010-03-23-new-subprofiles.en.txt new file mode 100644 index 000000000000..550c33d0c9a7 --- /dev/null +++ b/metadata/news/2010-03-23-new-subprofiles/2010-03-23-new-subprofiles.en.txt @@ -0,0 +1,31 @@ +Title: New desktop subprofiles for GNOME and KDE +Author: Theo Chatzimichos <tampakrap@gentoo.org> +Content-Type: text/plain +Posted: 2010-03-23 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Profile: default/linux/alpha/10.0/desktop +Display-If-Profile: default/linux/amd64/10.0/desktop +Display-If-Profile: default/linux/arm/10.0/desktop +Display-If-Profile: default/linux/hppa/10.0/desktop +Display-If-Profile: default/linux/ia64/10.0/desktop +Display-If-Profile: default/linux/m68k/10.0/desktop +Display-If-Profile: default/linux/powerpc/ppc32/10.0/desktop +Display-If-Profile: default/linux/powerpc/ppc64/10.0/32bit-userland/desktop +Display-If-Profile: default/linux/powerpc/ppc64/10.0/64bit-userland/desktop +Display-If-Profile: default/linux/powerpc/ppc64/10.0/desktop +Display-If-Profile: default/linux/sh/10.0/desktop +Display-If-Profile: default/linux/sparc/10.0/desktop +Display-If-Profile: default/linux/sparc/experimental/multilib/desktop +Display-If-Profile: default/linux/x86/10.0/desktop + +There are two new subprofiles under desktop, one for GNOME and one for +KDE. Users that have only one of those two DEs may choose the according +subprofile. Users of other DEs or WMs may stick to the desktop profile. + +Attention: KDE or GNOME specific USE flags have been stripped from the +desktop profile. More specifically: +GNOME subprofile contains: USE="eds evo gnome gstreamer" +KDE subprofile contains: USE="kde" + +(I'll commit the change on Friday, 26 Mar 2010) diff --git a/metadata/news/2010-03-25-python-3_1/2010-03-25-python-3_1.en.txt b/metadata/news/2010-03-25-python-3_1/2010-03-25-python-3_1.en.txt new file mode 100644 index 000000000000..13533ecaf8bc --- /dev/null +++ b/metadata/news/2010-03-25-python-3_1/2010-03-25-python-3_1.en.txt @@ -0,0 +1,28 @@ +Title: Python 3.1 +Author: Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> +Content-Type: text/plain +Posted: 2010-03-25 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: =dev-lang/python-3.1* + +Python 3 is a new major version of Python and is intentionally incompatible +with Python 2. Many external modules have not been ported yet to Python 3, +so Python 2 still needs to be installed. You can benefit from having Python 3 +installed without setting Python 3.1 as main active version of Python. +Currently you should not set Python 3.1 as main active version of Python. +When setting it becomes recommended, a separate news item will be created +to notify users. + +Although Python 3.1 should not be set as main active version of Python, +you should run python-updater after installation of Python 3.1. By default, +modules that support both Python 2 and Python 3 are installed for both +the active version of Python 2 and the active version of Python 3 when both +Python 2 and Python 3 are installed. + +It is recommended to use a UTF-8 locale to avoid potential problems. Especially +C and POSIX locales are discouraged. If locale has not been explicitly set, +then POSIX locale is used, so you should ensure that locale has been set. +Problems occurring only with non-UTF-8 locales should be reported directly +to upstream developers of given packages. +See http://www.gentoo.org/doc/en/utf-8.xml for more information about UTF-8. diff --git a/metadata/news/2010-05-02-gnome-228/2010-05-02-gnome-228.en.txt b/metadata/news/2010-05-02-gnome-228/2010-05-02-gnome-228.en.txt new file mode 100644 index 000000000000..177e160a1d86 --- /dev/null +++ b/metadata/news/2010-05-02-gnome-228/2010-05-02-gnome-228.en.txt @@ -0,0 +1,18 @@ +Title: Upgrade to GNOME 2.28 +Author: Pacho Ramos <pacho@gentoo.org> +Content-Type: text/plain +Posted: 2010-04-23 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <gnome-base/gnome-2.28.2 +Display-If-Installed: <gnome-base/gnome-light-2.28.1 +Display-If-Installed: <gnome-base/gnome-session-2.28.0 +Display-If-Installed: <gnome-base/gnome-menus-2.28.0.1 + +We are pleased to announce the stabilization of GNOME-2.28. Users are +strongly encouraged to read the GNOME 2.28 Upgrade Guide, to avoid any +possible issues relating to the upgrade, such as Applications menu items +disappearing, missing icons, or mouse interaction problems. + +Please read the Gnome 2.28 Upgrade Guide: +http://gnome.gentoo.org/howtos/gnome-2.28-upgrade.xml diff --git a/metadata/news/2010-10-22-perl-5_12-upgrade-procedure/2010-10-22-perl-5_12-upgrade-procedure.en.txt b/metadata/news/2010-10-22-perl-5_12-upgrade-procedure/2010-10-22-perl-5_12-upgrade-procedure.en.txt new file mode 100644 index 000000000000..0be2ab381542 --- /dev/null +++ b/metadata/news/2010-10-22-perl-5_12-upgrade-procedure/2010-10-22-perl-5_12-upgrade-procedure.en.txt @@ -0,0 +1,27 @@ +Title: Perl 5.12 upgrade procedure +Author: perl-team <perl@gentoo.org> +Author: Torsten Veller <tove@gentoo.org> +Content-Type: text/plain +Posted: 2010-10-22 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <dev-lang/perl-5.12 + +==> Run `perl-cleaner --all` after upgrading to a new Perl version! <== + +"Perl 5.12 is not binary compatible with prior releases of Perl. If +you have built extensions (i.e. modules that include C code) using an +earlier version of Perl, you will need to rebuild and reinstall those +extensions." [1] + +In fact, in Gentoo you currently have to rebuild all Perl modules and +all binaries linking libperl to get into a consistent state again. + +perl-cleaner generates a list of broken packages and passes it to your +package manager to reinstall them. After reinstalling the packages, +perl-cleaner outputs a list of files the script could not deal with +(like modules installed not via the package manager). + +See `man perl-cleaner` for its options. + +[1] http://search.cpan.org/dist/perl-5.12.2/INSTALL#Changes_and_Incompatibilities diff --git a/metadata/news/2010-10-27-hardened-gcc4-info/2010-10-27-hardened-gcc4-info.en.txt b/metadata/news/2010-10-27-hardened-gcc4-info/2010-10-27-hardened-gcc4-info.en.txt new file mode 100644 index 000000000000..6ca95223dbec --- /dev/null +++ b/metadata/news/2010-10-27-hardened-gcc4-info/2010-10-27-hardened-gcc4-info.en.txt @@ -0,0 +1,20 @@ +Title: Info about GCC on Hardened profiles +Author: Magnus Granberg <zorry@gentoo.org> +Content-Type: text/plain +Posted: 2010-10-27 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <sys-devel/gcc-4.4 +Display-If-Profile: hardened/linux + +GCC 4.4.4-r2 is now stable in the hardened profiles (on x86 and +amd64 as of 2010-10-24, other architectures will follow later). +Starting from this version, SSP support is enabled by default for the +architectures it is supported on (namely x86, amd64, ppc, ppc64 and +arm). Previously, GCC 4.3.4 had SSP support but it was not enabled +by default. + +Older GCC versions in the hardened profiles, such as the +GCC 3.x series will be obsoleted, problems arising on those versions, +but not applying to GCC 4.4.4-r2 will not be fixed, so please update +to the new version. diff --git a/metadata/news/2010-11-13-hardened-profiles/2010-11-13-hardened-profiles.en.txt b/metadata/news/2010-11-13-hardened-profiles/2010-11-13-hardened-profiles.en.txt new file mode 100644 index 000000000000..98c7378eabc1 --- /dev/null +++ b/metadata/news/2010-11-13-hardened-profiles/2010-11-13-hardened-profiles.en.txt @@ -0,0 +1,51 @@ +Title: Restructuring of Hardened profiles +Author: Anthony G. Basile <blueness@gentoo.org> +Author: Hardened Team <hardened@gentoo.org> +Content-Type: text/plain +Posted: 2010-11-13 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Profile: hardened/linux/ia64/10.0 +Display-If-Profile: hardened/linux/ia64/10.0/server +Display-If-Profile: hardened/linux/ia64/10.0/desktop +Display-If-Profile: hardened/linux/ia64/10.0/developer +Display-If-Profile: hardened/linux/x86/10.0 +Display-If-Profile: hardened/linux/x86/10.0/server +Display-If-Profile: hardened/linux/x86/10.0/no-nptl +Display-If-Profile: hardened/linux/x86/10.0/desktop +Display-If-Profile: hardened/linux/x86/10.0/developer +Display-If-Profile: hardened/linux/amd64/10.0 +Display-If-Profile: hardened/linux/amd64/10.0/server +Display-If-Profile: hardened/linux/amd64/10.0/desktop +Display-If-Profile: hardened/linux/amd64/10.0/no-multilib +Display-If-Profile: hardened/linux/amd64/10.0/developer +Display-If-Profile: hardened/linux/powerpc/ppc32/10.0 +Display-If-Profile: hardened/linux/powerpc/ppc32/10.0/server +Display-If-Profile: hardened/linux/powerpc/ppc32/10.0/desktop +Display-If-Profile: hardened/linux/powerpc/ppc32/10.0/developer +Display-If-Profile: hardened/linux/powerpc/ppc64/10.0 +Display-If-Profile: hardened/linux/powerpc/ppc64/10.0/server +Display-If-Profile: hardened/linux/powerpc/ppc64/10.0/desktop +Display-If-Profile: hardened/linux/powerpc/ppc64/10.0/32bit-userland +Display-If-Profile: hardened/linux/powerpc/ppc64/10.0/32bit-userland/server +Display-If-Profile: hardened/linux/powerpc/ppc64/10.0/32bit-userland/desktop +Display-If-Profile: hardened/linux/powerpc/ppc64/10.0/32bit-userland/developer +Display-If-Profile: hardened/linux/powerpc/ppc64/10.0/64bit-userland +Display-If-Profile: hardened/linux/powerpc/ppc64/10.0/64bit-userland/server +Display-If-Profile: hardened/linux/powerpc/ppc64/10.0/64bit-userland/desktop +Display-If-Profile: hardened/linux/powerpc/ppc64/10.0/64bit-userland/developer +Display-If-Profile: hardened/linux/powerpc/ppc64/10.0/developer + +During the next few weeks, all hardened profiles will be restructured to +remove the version number "/10.0". For example, if your current profile +is "hardened/linux/amd64/10.0/no-multilib" your new profile will be +"hardened/linux/amd64/no-multilib". + +We will change the profiles one arch at a time, starting with ia64, and +proceeding in order with ppc, ppc64, x86 and amd64. Once your arch has +been updated, you will receive a warning when running emerge that your +profile has been deprecated. When you do, use "eselect profile list" to +get a list of the new profiles. Then, use "eselect profile set <num>" +to switch to your new profile with corresponding number <num>. + +Progress with the restructuring will be tracked in bug #344861. diff --git a/metadata/news/2011-02-13-libgphoto2-2_4_10/2011-02-13-libgphoto2-2_4_10.en.txt b/metadata/news/2011-02-13-libgphoto2-2_4_10/2011-02-13-libgphoto2-2_4_10.en.txt new file mode 100644 index 000000000000..d599f3a43bb4 --- /dev/null +++ b/metadata/news/2011-02-13-libgphoto2-2_4_10/2011-02-13-libgphoto2-2_4_10.en.txt @@ -0,0 +1,14 @@ +Title: Change on CAMERAS in libgphoto2-2.4.10 +Author: Pacho Ramos <pacho@gentoo.org> +Content-Type: text/plain +Posted: 2011-02-13 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Installed: <media-libs/libgphoto2-2.4.10 + +In order to not violate package manager handling, selective cameras +build logic has been modified in libgphoto2-2.4.10 to build 'ptp2' by +default, nothing if CAMERAS variable is set to an empty value and only +the ones specified otherwise. + +See http://bugs.gentoo.org/346491 for reference. diff --git a/metadata/news/2011-02-14-gnome-232/2011-02-14-gnome-232.en.txt b/metadata/news/2011-02-14-gnome-232/2011-02-14-gnome-232.en.txt new file mode 100644 index 000000000000..47c121664892 --- /dev/null +++ b/metadata/news/2011-02-14-gnome-232/2011-02-14-gnome-232.en.txt @@ -0,0 +1,17 @@ +Title: Upgrade to GNOME 2.32 +Author: Pacho Ramos <pacho@gentoo.org> +Content-Type: text/plain +Posted: 2011-02-14 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <gnome-base/gnome-2.32.1 +Display-If-Installed: <gnome-base/gnome-light-2.32.1 +Display-If-Installed: <gnome-base/gnome-session-2.32.1 + +We are pleased to announce the stabilization of GNOME-2.32. Users are +strongly encouraged to read the GNOME 2.32 Upgrade Guide, to avoid any +possible issues relating to the upgrade, such as gnome-panel hanging +issues, evolution migration problems and others. + +Please read the Gnome 2.32 Upgrade Guide: +http://gnome.gentoo.org/howtos/gnome-2.32-upgrade.xml diff --git a/metadata/news/2011-02-19-ia64-java-removal/2011-02-19-ia64-java-removal.en.txt b/metadata/news/2011-02-19-ia64-java-removal/2011-02-19-ia64-java-removal.en.txt new file mode 100644 index 000000000000..eb4577850dfb --- /dev/null +++ b/metadata/news/2011-02-19-ia64-java-removal/2011-02-19-ia64-java-removal.en.txt @@ -0,0 +1,19 @@ +Title: Pending Removal of Java support on IA64 +Author: Petteri Räty <betelgeuse@gentoo.org> +Author: IA64 Arch Team <ia64@gentoo.org> +Author: Vlastimil Babka <caster@gentoo.org> +Content-Type: text/plain +Posted: 2011-02-19 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Keyword: ia64 +Display-If-Installed: dev-java/java-config + +Since the IA64 arch team does not have the resources to maintain Java support, +we have agreed that ia64 keywords will be dropped from Java packages, and the +java USE flag masked on IA64, unless more manpower becomes available. +If you are willing to help with the maintenance, please contact ia64@gentoo.org. +If there is not enough interest, Java support will be removed during the second +half of March 2011. + +The removal is tracked in bug #345433. diff --git a/metadata/news/2011-04-26-gnustep-new-layout/2011-04-26-gnustep-new-layout.en.txt b/metadata/news/2011-04-26-gnustep-new-layout/2011-04-26-gnustep-new-layout.en.txt new file mode 100644 index 000000000000..ca24ef63993b --- /dev/null +++ b/metadata/news/2011-04-26-gnustep-new-layout/2011-04-26-gnustep-new-layout.en.txt @@ -0,0 +1,20 @@ +Title: GNUstep packages new layout +Author: Bernard Cafarelli <voyageur@gentoo.org> +Content-Type: text/plain +Posted: 2011-04-26 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <gnustep-base/gnustep-make-2.6.0 + +Traditionally, GNUstep used its own filesystem layout, installing +everything under /usr/GNUstep. Starting with gnustep-make-2.6.0, the +default filesystem layout has changed and is now the 'fhs' layout, +installing files in standard Unix directories. + +Following upstream's change, GNUstep packages in Gentoo will now +also use the new default layout. Your system will switch to it +after updating gnustep-base/gnustep-make to >=2.6.0. + +This change means that you have to re-emerge all installed packages +depending on GNUstep to move them to the new layout. You can use +gnustep-base/gnustep-updater for this step diff --git a/metadata/news/2011-04-27-glib-228/2011-04-27-glib-228.en.txt b/metadata/news/2011-04-27-glib-228/2011-04-27-glib-228.en.txt new file mode 100644 index 000000000000..823413d35d39 --- /dev/null +++ b/metadata/news/2011-04-27-glib-228/2011-04-27-glib-228.en.txt @@ -0,0 +1,37 @@ +Title: Upgrade to GLIB 2.28 +Author: The Gentoo Freedesktop Maintainers <freedesktop-bugs@gentoo.org> +Content-Type: text/plain +Posted: 2011-04-27 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <dev-libs/glib-2.28 + +The method for setting default applications for specific URI types +(https://, mailto://, etc.) changed in dev-libs/glib-2.28 and newer. +If you previously set them in GConf using the Configuration Editor, +they will now be ignored. + +If you use GNOME, you must upgrade gnome-session and +gnome-control-center and set your default browser/mail-client again. + +If you don't use GNOME, you should ensure that the file +~/.local/share/applications/mimeapps.list has the following content: + +[Added Associations] +x-scheme-handler/http=$browser_name.desktop; +x-scheme-handler/https=$browser_name.desktop; +x-scheme-handler/mailto=$mailclient_name.desktop; + +Replace $browser_name.desktop and $mailclient_name.desktop with the +appropriate file from /usr/share/applications that can handle +http/https/mailto URIs. + +The system-wide version of the file is often at +/usr/share/applications/defaults.list instead. + +Please make sure that your browsers and mail clients have been upgraded +to the latest stable versions before doing all this. + +More information about using defaults.list and mimeapps.list is at: + +http://www.freedesktop.org/wiki/Specifications/mime-actions-spec diff --git a/metadata/news/2011-05-01-baselayout-update/2011-05-01-baselayout-update.en.txt b/metadata/news/2011-05-01-baselayout-update/2011-05-01-baselayout-update.en.txt new file mode 100644 index 000000000000..d4b768950ac9 --- /dev/null +++ b/metadata/news/2011-05-01-baselayout-update/2011-05-01-baselayout-update.en.txt @@ -0,0 +1,29 @@ +Title: Baselayout update +Author: Christian Faulhammer <fauli@gentoo.org> +Author: William Hubbs <williamh@gentoo.org> +Content-Type: text/plain +Posted: 2011-05-01 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <sys-apps/baselayout-2 + +The baselayout package provides files which all systems must have in +order to function properly. You are currently using version 1.x, which +has several issues. The most significant of these is that the included +init scripts are written entirely in bash, which makes them slow and +not very flexible. + +On 2011/05/08, you will see an update for sys-apps/baselayout to +2.x and a new package, sys-apps/openrc. It is recommended that you +perform this update as soon as possible. + +Please note, after these packages are emerged, it is +__Absolutely_Critical__ that you immediately update your configuration +files with dispatch-conf, etc-update or a similar tool then follow the +steps in the migration guide located at the following URL. +http://www.gentoo.org/doc/en/openrc-migration.xml + +FAILURE TO FOLLOW ALL OF THESE STEPS WILL RESULT IN AN UNBOOTABLE +SYSTEM! IF THIS SHOULD HAPPEN, YOU WILL NEED TO BOOT FROM A LIVE CD OR +DVD, MOUNT YOUR ROOT FILE SYSTEM, CHROOT INTO THAT ENVIRONMENT AND +FOLLOW THE ABOVE STEPS! diff --git a/metadata/news/2011-08-28-mesa-r600g/2011-08-28-mesa-r600g.en.txt b/metadata/news/2011-08-28-mesa-r600g/2011-08-28-mesa-r600g.en.txt new file mode 100644 index 000000000000..110f330080e5 --- /dev/null +++ b/metadata/news/2011-08-28-mesa-r600g/2011-08-28-mesa-r600g.en.txt @@ -0,0 +1,26 @@ +Title: Mesa r600 driver now defaults to gallium +Author: Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> +Content-Type: text/plain +Posted: 2011-08-28 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <media-libs/mesa-7.12 + +This news item is relevant to you only if you have a Radeon graphics +chipset and use the free/open source driver. + +The r600 driver that provides 3D acceleration for Radeon HD 2400 and +later cards comes in the "classic" and "gallium" variants. The gallium +driver is based on the new Gallium3D infrastructure and was chosen as +the default driver for media-libs/mesa-7.11. + +Existing users will not be switched automatically. To switch to the +r600 gallium driver, use the following command: + + eselect mesa set r600 gallium + +Gallium3D requires kernel modesetting (KMS). If your system is not yet +configured for KMS, consult the X Server Configuration HOWTO for +instructions prior to switching: + + http://www.gentoo.org/doc/en/xorg-config.xml diff --git a/metadata/news/2011-10-15-libpng15/2011-10-15-libpng15.en.txt b/metadata/news/2011-10-15-libpng15/2011-10-15-libpng15.en.txt new file mode 100644 index 000000000000..d5c3f272e19b --- /dev/null +++ b/metadata/news/2011-10-15-libpng15/2011-10-15-libpng15.en.txt @@ -0,0 +1,32 @@ +Title: Upgrade to libpng15 +Author: Samuli Suominen <ssuominen@gentoo.org> +Content-Type: text/plain +Posted: 2011-10-15 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <media-libs/libpng-1.5 + +After upgrading from libpng14 to libpng15 it's important that you rebuild +cairo and gdk-pixbuf as soon as possible if they are installed. + +Then you can proceed with rebuilding the rest of the software against the new +library: + +# revdep-rebuild --library libpng14.so.14 -- --keep-going + +Note: It might be necessary to run the previous command more than once. + +If you find packages not building with the message "ld: cannot find -lpng14", +they are likely caused by broken libtool archives (.la) in your system. + +You can identify those files with following one-liner: + +# find /usr/ -name '*.la' -exec grep png14 {} + + +Once you have identified the broken files, you can either delete them, +edit them in place and replace png14 with png15, or re-emerge the packages +they belong to. + +More information and help is available at the following forum post: + +http://forums.gentoo.org/viewtopic-t-894950.html diff --git a/metadata/news/2011-11-27-gnome3-unmask/2011-11-27-gnome3-unmask.en.txt b/metadata/news/2011-11-27-gnome3-unmask/2011-11-27-gnome3-unmask.en.txt new file mode 100644 index 000000000000..7077a667a3e6 --- /dev/null +++ b/metadata/news/2011-11-27-gnome3-unmask/2011-11-27-gnome3-unmask.en.txt @@ -0,0 +1,16 @@ +Title: Unmasking of and Upgrade to GNOME 3.2 +Author: Nirbheek Chauhan <nirbheek@gentoo.org> +Content-Type: text/plain +Posted: 2011-11-26 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <gnome-base/gnome-session-3.2 + +We are pleased to announce the addition to tree and unmasking of GNOME-3.2. +Users are strongly encouraged to read the GNOME 3.2 Guide. GNOME 3 has +a massively changed interface and requires working 3D drivers for use, however +there is a fallback mode which is very similar to GNOME 2 and does not require +3D acceleration. + +Please read the Gnome 3.2 Guide: +http://gnome.gentoo.org/howtos/gnome-3.2-upgrade.xml diff --git a/metadata/news/2011-12-06-kde473-kdepim/2011-12-06-kde473-kdepim.en.txt b/metadata/news/2011-12-06-kde473-kdepim/2011-12-06-kde473-kdepim.en.txt new file mode 100644 index 000000000000..2565795e9d51 --- /dev/null +++ b/metadata/news/2011-12-06-kde473-kdepim/2011-12-06-kde473-kdepim.en.txt @@ -0,0 +1,29 @@ +Title: Stabilization of KDE 4.7.3 including KDEPIM +Author: Andreas K. Huettel <dilfridge@gentoo.org> +Content-Type: text/plain +Posted: 2011-12-06 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <kde-base/libkdepim-4.5 +Display-If-Installed: <kde-base/blogilo-4.5 +Display-If-Installed: <kde-base/kabcclient-4.5 +Display-If-Installed: <kde-base/kdepim-strigi-analyzer-4.5 +Display-If-Installed: <kde-base/konsolekalendar-4.5 +Display-If-Installed: <kde-base/libkleo-4.5 +Display-If-Installed: <kde-base/libkpgp-4.5 + +We are pleased to announce the upcoming stabilization of KDE 4.7.3. +In general the upgrade of KDE from 4.6.5 to 4.7.3 should be unproblematic. +However, if you are using the KDEPIM application suite (i.e., akregator, +blogilo, kmail, knode, kontact, korganizer, and others) where the stable +version so far was 4.4.11.1, please be aware of the following: + +The stable upgrade from KDEPIM 4.4.11.1 to KDEPIM 4.7.3 is a MAJOR upgrade +with potential for major breakage. Therefore we will *try* to keep +and support the old, so-far stable KDEPIM 4.4.11.1 as long as possible. +If you *dont* want to upgrade your KDEPIM yet but keep the old version, +please download the following file and add it into your +/etc/portage/package.mask: +http://www.gentoo.org/proj/en/desktop/kde/kdepim-4.7-mask.txt +If you decide to upgrade, please have a look at the upgrade guide first: +http://wiki.gentoo.org/wiki/KDEPIM-4.7_upgrade diff --git a/metadata/news/2011-12-30-bacula-updates/2011-12-30-bacula-updates.en.txt b/metadata/news/2011-12-30-bacula-updates/2011-12-30-bacula-updates.en.txt new file mode 100644 index 000000000000..269dfa981db1 --- /dev/null +++ b/metadata/news/2011-12-30-bacula-updates/2011-12-30-bacula-updates.en.txt @@ -0,0 +1,27 @@ +Title: Bacula-5.2.3 Upgrade +Author: Thomas Beierlein <tomjbe@gentoo.org> +Content-Type: text/plain +Posted: 2011-12-30 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <app-backup/bacula-5.2.0 + +The 5.2.x release series of Bacula uses a new database catalog format. +If you're upgrading from a 3.x.x or 5.0.x release, you must upgrade your +bacula catalog database. + +Please read the manual chapter for how to upgrade your database (see +http://www.bacula.org/5.2.x-manuals/en/main/main/Installing_Bacula.html). +You can find database upgrade scripts in /usr/libexec/bacula/(updatedb/). + +It is strongly recommended that you save a copy of your existing database +before upgrading. For details how to do it please look into your database +documentation. + +The simplest way to upgrade the database: + +1. Stop Bacula from running (at least the director and storage daemons). +2. Save a copy of your existing database. +3. Emerge the new version of Bacula. +4. Run the appropriate upgrade script from /usr/libexec/bacula/updatedb/. +5. Start the new Bacula. diff --git a/metadata/news/2012-02-14-baselayout-1-deprecation/2012-02-14-baselayout-1-deprecation.en.txt b/metadata/news/2012-02-14-baselayout-1-deprecation/2012-02-14-baselayout-1-deprecation.en.txt new file mode 100644 index 000000000000..d5f671c0c73a --- /dev/null +++ b/metadata/news/2012-02-14-baselayout-1-deprecation/2012-02-14-baselayout-1-deprecation.en.txt @@ -0,0 +1,30 @@ +Title: baselayout-1.x deprecation +Author: William Hubbs <williamh@gentoo.org> +Content-Type: text/plain +Posted: 2012-02-14 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <sys-apps/baselayout-2 + +On 28 Jun 2011, baselayout-2.x and OpenRC were first marked stable on +all supported architectures in Gentoo Linux. + +This was the point at which we stopped working on issues in baselayout-1 +and began encouraging users to upgrade to baselayout-2 and OpenRC. + +Although we are not supporting baselayout-1, we are supporting migration +from baselayout-1 to OpenRC and baselayout-2. + +According to Gentoo policy, the support for migration from baselayout-1 +to baselayout-2 ends one year after baselayout-2 and OpenRC became +stable. That date will be 28 Jun 2012. + +This news item is to inform you that you must migrate your system +to baselayout-2 and OpenRC before 28 Jun 2012. Starting on this date, we +will no longer support this migration, and you may need to re-install +any systems which are still running baselayout-1. + +For questions about how to migrate your system, see the OpenRC migration +guide [1]. + +[1] http://www.gentoo.org/doc/en/openrc-migration.xml diff --git a/metadata/news/2012-04-24-libjpeg-turbo-by-default/2012-04-24-libjpeg-turbo-by-default.en.txt b/metadata/news/2012-04-24-libjpeg-turbo-by-default/2012-04-24-libjpeg-turbo-by-default.en.txt new file mode 100644 index 000000000000..512b32f2109d --- /dev/null +++ b/metadata/news/2012-04-24-libjpeg-turbo-by-default/2012-04-24-libjpeg-turbo-by-default.en.txt @@ -0,0 +1,19 @@ +Title: The default JPEG implementation +Author: Samuli Suominen <ssuominen@gentoo.org> +Content-Type: text/plain +Posted: 2012-04-24 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: =media-libs/jpeg-8* + +libjpeg-turbo is a derivative of libjpeg that uses MMX, SSE, SSE2, +and NEON SIMD instructions to accelerate baseline JPEG +compression/decompression by about 2-4x on amd64, arm and x86 +platforms. It is based on libjpeg/SIMD but has numerous enhancements. + +All users are recommended to migrate: + +# emerge --deselect media-libs/jpeg +# emerge --oneshot media-libs/libjpeg-turbo + +media-libs/jpeg:0 will be left in tree as a fallback implementation. diff --git a/metadata/news/2012-07-23-upgrading-postfix/2012-07-23-upgrading-postfix.en.txt b/metadata/news/2012-07-23-upgrading-postfix/2012-07-23-upgrading-postfix.en.txt new file mode 100644 index 000000000000..f9cb0e4aff8f --- /dev/null +++ b/metadata/news/2012-07-23-upgrading-postfix/2012-07-23-upgrading-postfix.en.txt @@ -0,0 +1,13 @@ +Title: Upgrading to postfix-2.9 +Author: Eray Aslan <eras@gentoo.org> +Content-Type: text/plain +Posted: 2012-07-23 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <mail-mta/postfix-2.9 + +Daemons for >=mail-mta/postfix-2.9 are installed under +/usr/libexec/postfix. Please do not forget to adjust your main.cf by +running etc-update/dispatch-conf or similar and accepting the new +daemon_directory setting. Otherwise, postfix will not be able to find +the binaries it is looking for. diff --git a/metadata/news/2013-02-10-new-13-profiles-server/2013-02-10-new-13-profiles-server.en.txt b/metadata/news/2013-02-10-new-13-profiles-server/2013-02-10-new-13-profiles-server.en.txt new file mode 100644 index 000000000000..999f73c96324 --- /dev/null +++ b/metadata/news/2013-02-10-new-13-profiles-server/2013-02-10-new-13-profiles-server.en.txt @@ -0,0 +1,41 @@ +Title: New 13.0 profiles and deprecation of 10.0 profiles +Author: Andreas K. Huettel <dilfridge@gentoo.org> +Content-Type: text/plain +Posted: 2013-02-10 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Profile: default/linux/alpha/10.0/server +Display-If-Profile: default/linux/amd64/10.0/server +Display-If-Profile: default/linux/arm/10.0/server +Display-If-Profile: default/linux/arm/10.0/armv4/server +Display-If-Profile: default/linux/arm/10.0/armv4t/server +Display-If-Profile: default/linux/arm/10.0/armv5te/server +Display-If-Profile: default/linux/arm/10.0/armv6j/server +Display-If-Profile: default/linux/arm/10.0/armv7a/server +Display-If-Profile: default/linux/hppa/10.0/server +Display-If-Profile: default/linux/ia64/10.0/server +Display-If-Profile: default/linux/m68k/10.0/server +Display-If-Profile: default/linux/powerpc/ppc32/10.0/server +Display-If-Profile: default/linux/powerpc/ppc64/10.0/32bit-userland/server +Display-If-Profile: default/linux/powerpc/ppc64/10.0/64bit-userland/server +Display-If-Profile: default/linux/s390/10.0/server +Display-If-Profile: default/linux/s390/10.0/server/s390x +Display-If-Profile: default/linux/sh/10.0/server +Display-If-Profile: default/linux/sparc/10.0/server +Display-If-Profile: default/linux/x86/10.0/server + +We have generated a new set of profiles for Gentoo installation. These are now +called 13.0 instead of 10.0. Everyone should upgrade as soon as possible (but +please make sure sys-apps/portage is updated to current stable *before* you +switch profile). +This brings (nearly) no user-visible changes. Some new files have been added +to the profile directories that make it possible for the developers to do more +fine-grained use flag masking (see PMS-5 for the details), and this formally +requires a new profile tree with EAPI=5. +In the course of this change, the "server" profiles will be removed; they do +not exist in the 13.0 tree anymore. You should migrate to the corresponding +parent profile. This may change the default value of some use-flags. The +specific setting in "server" was + USE="-perl -python snmp truetype xml" +You may want to check the setting of these flags after switching profile, but +otherwise nothing changes. diff --git a/metadata/news/2013-02-10-new-13-profiles/2013-02-10-new-13-profiles.en.txt b/metadata/news/2013-02-10-new-13-profiles/2013-02-10-new-13-profiles.en.txt new file mode 100644 index 000000000000..63aca0c017dd --- /dev/null +++ b/metadata/news/2013-02-10-new-13-profiles/2013-02-10-new-13-profiles.en.txt @@ -0,0 +1,116 @@ +Title: New 13.0 profiles and deprecation of 10.0 profiles +Author: Andreas K. Huettel <dilfridge@gentoo.org> +Content-Type: text/plain +Posted: 2013-02-10 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Profile: default/linux/alpha/10.0 +Display-If-Profile: default/linux/alpha/10.0/desktop +Display-If-Profile: default/linux/alpha/10.0/desktop/gnome +Display-If-Profile: default/linux/alpha/10.0/desktop/kde +Display-If-Profile: default/linux/alpha/10.0/developer +Display-If-Profile: default/linux/amd64/10.0 +Display-If-Profile: default/linux/amd64/10.0/selinux +Display-If-Profile: default/linux/amd64/10.0/desktop +Display-If-Profile: default/linux/amd64/10.0/desktop/gnome +Display-If-Profile: default/linux/amd64/10.0/desktop/kde +Display-If-Profile: default/linux/amd64/10.0/developer +Display-If-Profile: default/linux/amd64/10.0/no-multilib +Display-If-Profile: default/linux/amd64/10.0/x32 +Display-If-Profile: default/linux/arm/10.0 +Display-If-Profile: default/linux/arm/10.0/desktop +Display-If-Profile: default/linux/arm/10.0/desktop/gnome +Display-If-Profile: default/linux/arm/10.0/desktop/kde +Display-If-Profile: default/linux/arm/10.0/developer +Display-If-Profile: default/linux/arm/10.0/armv4 +Display-If-Profile: default/linux/arm/10.0/armv4/desktop +Display-If-Profile: default/linux/arm/10.0/armv4/desktop/gnome +Display-If-Profile: default/linux/arm/10.0/armv4/desktop/kde +Display-If-Profile: default/linux/arm/10.0/armv4/developer +Display-If-Profile: default/linux/arm/10.0/armv4t +Display-If-Profile: default/linux/arm/10.0/armv4t/desktop +Display-If-Profile: default/linux/arm/10.0/armv4t/desktop/gnome +Display-If-Profile: default/linux/arm/10.0/armv4t/desktop/kde +Display-If-Profile: default/linux/arm/10.0/armv4t/developer +Display-If-Profile: default/linux/arm/10.0/armv5te +Display-If-Profile: default/linux/arm/10.0/armv5te/desktop +Display-If-Profile: default/linux/arm/10.0/armv5te/desktop/gnome +Display-If-Profile: default/linux/arm/10.0/armv5te/desktop/kde +Display-If-Profile: default/linux/arm/10.0/armv5te/developer +Display-If-Profile: default/linux/arm/10.0/armv6j +Display-If-Profile: default/linux/arm/10.0/armv6j/desktop +Display-If-Profile: default/linux/arm/10.0/armv6j/desktop/gnome +Display-If-Profile: default/linux/arm/10.0/armv6j/desktop/kde +Display-If-Profile: default/linux/arm/10.0/armv6j/developer +Display-If-Profile: default/linux/arm/10.0/armv7a +Display-If-Profile: default/linux/arm/10.0/armv7a/desktop +Display-If-Profile: default/linux/arm/10.0/armv7a/desktop/gnome +Display-If-Profile: default/linux/arm/10.0/armv7a/desktop/kde +Display-If-Profile: default/linux/arm/10.0/armv7a/developer +Display-If-Profile: default/linux/hppa/10.0 +Display-If-Profile: default/linux/hppa/10.0/desktop +Display-If-Profile: default/linux/hppa/10.0/developer +Display-If-Profile: default/linux/ia64/10.0 +Display-If-Profile: default/linux/ia64/10.0/desktop +Display-If-Profile: default/linux/ia64/10.0/desktop/gnome +Display-If-Profile: default/linux/ia64/10.0/desktop/kde +Display-If-Profile: default/linux/ia64/10.0/developer +Display-If-Profile: default/linux/m68k/10.0 +Display-If-Profile: default/linux/m68k/10.0/desktop +Display-If-Profile: default/linux/m68k/10.0/desktop/gnome +Display-If-Profile: default/linux/m68k/10.0/desktop/kde +Display-If-Profile: default/linux/m68k/10.0/developer +Display-If-Profile: default/linux/mips/10.0 +Display-If-Profile: default/linux/mips/10.0/n32 +Display-If-Profile: default/linux/mips/10.0/n64 +Display-If-Profile: default/linux/mips/10.0/multilib +Display-If-Profile: default/linux/mips/10.0/multilib/n32 +Display-If-Profile: default/linux/mips/10.0/multilib/n64 +Display-If-Profile: default/linux/mips/10.0/mipsel +Display-If-Profile: default/linux/mips/10.0/mipsel/n32 +Display-If-Profile: default/linux/mips/10.0/mipsel/n64 +Display-If-Profile: default/linux/mips/10.0/mipsel/multilib +Display-If-Profile: default/linux/mips/10.0/mipsel/multilib/n32 +Display-If-Profile: default/linux/mips/10.0/mipsel/multilib/n64 +Display-If-Profile: default/linux/powerpc/ppc32/10.0 +Display-If-Profile: default/linux/powerpc/ppc32/10.0/desktop +Display-If-Profile: default/linux/powerpc/ppc32/10.0/desktop/gnome +Display-If-Profile: default/linux/powerpc/ppc32/10.0/desktop/kde +Display-If-Profile: default/linux/powerpc/ppc32/10.0/developer +Display-If-Profile: default/linux/powerpc/ppc64/10.0/32bit-userland +Display-If-Profile: default/linux/powerpc/ppc64/10.0/32bit-userland/desktop +Display-If-Profile: default/linux/powerpc/ppc64/10.0/32bit-userland/desktop/gnome +Display-If-Profile: default/linux/powerpc/ppc64/10.0/32bit-userland/desktop/kde +Display-If-Profile: default/linux/powerpc/ppc64/10.0/32bit-userland/developer +Display-If-Profile: default/linux/powerpc/ppc64/10.0/64bit-userland +Display-If-Profile: default/linux/powerpc/ppc64/10.0/64bit-userland/desktop +Display-If-Profile: default/linux/powerpc/ppc64/10.0/64bit-userland/desktop/gnome +Display-If-Profile: default/linux/powerpc/ppc64/10.0/64bit-userland/desktop/kde +Display-If-Profile: default/linux/powerpc/ppc64/10.0/64bit-userland/developer +Display-If-Profile: default/linux/s390/10.0 +Display-If-Profile: default/linux/s390/10.0/s390x +Display-If-Profile: default/linux/sh/10.0 +Display-If-Profile: default/linux/sh/10.0/desktop +Display-If-Profile: default/linux/sh/10.0/desktop/gnome +Display-If-Profile: default/linux/sh/10.0/desktop/kde +Display-If-Profile: default/linux/sh/10.0/developer +Display-If-Profile: default/linux/sparc/10.0 +Display-If-Profile: default/linux/sparc/10.0/desktop +Display-If-Profile: default/linux/sparc/10.0/desktop/gnome +Display-If-Profile: default/linux/sparc/10.0/desktop/kde +Display-If-Profile: default/linux/sparc/10.0/developer +Display-If-Profile: default/linux/x86/10.0 +Display-If-Profile: default/linux/x86/10.0/selinux +Display-If-Profile: default/linux/x86/10.0/desktop +Display-If-Profile: default/linux/x86/10.0/desktop/gnome +Display-If-Profile: default/linux/x86/10.0/desktop/kde +Display-If-Profile: default/linux/x86/10.0/developer + +We have generated a new set of profiles for Gentoo installation. These are now +called 13.0 instead of 10.0. Everyone should upgrade as soon as possible (but +please make sure sys-apps/portage is updated to current stable *before* you +switch profile). +This brings (nearly) no user-visible changes. Some new files have been added +to the profile directories that make it possible for the developers to do more +fine-grained use flag masking (see PMS-5 for the details), and this formally +requires a new profile tree with EAPI=5. diff --git a/metadata/news/2013-03-29-udev-upgrade/2013-03-29-udev-upgrade.en.txt b/metadata/news/2013-03-29-udev-upgrade/2013-03-29-udev-upgrade.en.txt new file mode 100644 index 000000000000..2816d067437f --- /dev/null +++ b/metadata/news/2013-03-29-udev-upgrade/2013-03-29-udev-upgrade.en.txt @@ -0,0 +1,102 @@ +Title: Upgrading udev to version >=200 +Author: Samuli Suominen <ssuominen@gentoo.org> +Content-Type: text/plain +Posted: 2013-03-29 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Installed: <sys-fs/udev-201 + +This replaces the earlier news item about the udev 197 upgrade and +describes the predictable network interface names in more detail. + +If you skip anything in this news item, your system will not be +bootable, or your networking will be down, or both. + +Pay attention also to every message printed by emerge of sys-fs/udev +and sys-fs/udev-init-scripts as this news item may not be complete. + +1. udev-postmount init script: + +Remove the udev-postmount init script from your runlevels. + +2. devtmpfs support: + +You need at least version 2.6.32 of the kernel for devtmpfs +functionality. Once you have this, make sure CONFIG_DEVTMPFS=y is set +in the kernel configuration. See the gentoo udev guide for the option in +make menuconfig [1]. + +If you have a line for /dev in /etc/fstab, make sure it is configured +for file system type devtmpfs (not tmpfs or any other type). Also, you +can remove this line if you prefer, since devtmpfs is mounted +automatically. + +3. Old interface naming rules: + +If the system still has old network interface renaming rules in +/etc/udev/rules.d, like 70-persistent-net.rules, those will need +to be either modified or removed. + +If you choose to modify them, you must use free namespace (like net* +or internet*) instead of kernel namespace (like eth* or wlan*) +because in-place renaming has been deprecated, see small +documentation of it if you like[2]. + +The file 70-persistent-net.rules, like the 70-persistent-cd.rules +should be removed, so if you modify, rename the file also to something +else like 70-my-network.rules to silence the deprecation warning coming +from the end of the sys-fs/udev emerge. + +This is the old format with reserved namespace: + +SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="xx:xx:xx:xx:xx:xx", NAME="eth0" +SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="yy:yy:yy:yy:yy:yy", NAME="eth1" + +This is the new format with free namespace: + +SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="xx:xx:xx:xx:xx:xx", NAME="net0" +SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="yy:yy:yy:yy:yy:yy", NAME="net1" + +4. predictable network interface names: + +If /etc/udev/rules.d/80-net-name-slot.rules is an empty file or a +symlink to /dev/null, the new names will be disabled and the kernel will +do all the interface naming, and the resulting names may vary by kernel +configuration, hardware configuration and kernel version. + +Also, the forementioned old 70-persistent-net.rules might interfere with +the new predictable interface names. + +You can get attributes of your network interfaces using a command like +the following (replace eth0 with the name of the appropriate interface): + +# udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null + +You can copy /lib/udev/rules.d/80-net-name-slot.rules to +/etc/udev/rules.d and specify the attributes and in which order +they will be used for naming. See upstream wiki[3] for detailed list +of options. + +You can prepare the system for the new names before booting for example +by renaming /etc/init.d/net.* symlinks, editing /etc/conf.d/net, etc. + +The feature can also be completely disabled using net.ifnames=0 on the +kernel command line. + +If you only have one interface card, you don't necessarily have much +use for this feature as the name almost always stays at eth0, you can +easily disable it using forementioned methods. + +This feature can also replace the functionality of sys-apps/biosdevname, +but you can still keep using it if you want. + +In a normal new installation there are no files in /etc/udev/rules.d +and if you haven't edited any files you have in there, you should most +likely backup and delete them all if they don't belong to any packages. + +The official wiki has a dedicated page for udev upgrade notes[4]. + +[1] http://www.gentoo.org/doc/en/udev-guide.xml +[2] http://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html +[3] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames +[4] http://wiki.gentoo.org/wiki/Udev/upgrade diff --git a/metadata/news/2013-04-10-baselayout-1-deprecation-final-warning/2013-04-10-baselayout-1-deprecation-final-warning.en.txt b/metadata/news/2013-04-10-baselayout-1-deprecation-final-warning/2013-04-10-baselayout-1-deprecation-final-warning.en.txt new file mode 100644 index 000000000000..331d36f5d55b --- /dev/null +++ b/metadata/news/2013-04-10-baselayout-1-deprecation-final-warning/2013-04-10-baselayout-1-deprecation-final-warning.en.txt @@ -0,0 +1,32 @@ +Title: baselayout-1.x deprecation final warning +Author: William Hubbs <williamh@gentoo.org> +Content-Type: text/plain +Posted: 2013-04-10 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <sys-apps/baselayout-2 + +WARNING! THIS NEWS ITEM REQUIRES IMMEDIATE ATTENTION! + +On 28 Jun 2011, baselayout-2.x and OpenRC were first marked stable on +all supported architectures in Gentoo Linux. + +Although we no longer support baselayout-1.x, we have continued support +for migration from baselayout-1.x to baselayout-2.x and OpenRC. + +According to Gentoo policy, the support for migration was slated to end +on 28 Jun 2012, a year after OpenRC was first marked stable. + +This is your final warning. openrc-0.11.8 will be the final release of +OpenRC to support migration from baselayout-1.x. + +If you do not upgrade your system to baselayout-2.x and openrc-0.11.8 +before openrc-0.11.8 leaves the tree, you will have to perform the +migration manually when you upgrade or you will be left with an +unbootable system. Manual migration is not officially supported, and +could include fixing things with a live cd or re-installing your system. + +For questions about how to migrate your system, see the OpenRC migration +guide [1]. + +[1] http://www.gentoo.org/doc/en/openrc-migration.xml diff --git a/metadata/news/2013-06-01-mysql-pbxt-dropped/2013-06-01-mysql-pbxt-dropped.en.txt b/metadata/news/2013-06-01-mysql-pbxt-dropped/2013-06-01-mysql-pbxt-dropped.en.txt new file mode 100644 index 000000000000..1f7293adc47d --- /dev/null +++ b/metadata/news/2013-06-01-mysql-pbxt-dropped/2013-06-01-mysql-pbxt-dropped.en.txt @@ -0,0 +1,41 @@ +Title: PBXT now unsupported in MySQL/MariaDB +Author: Robin H. Johnson <robbat2@gentoo.org> +Content-Type: text/plain +Posted: 2013-06-01 +Revision: 4 +News-Item-Format: 1.0 +Display-If-Installed: dev-db/mysql +Display-If-Installed: dev-db/mysql-cluster +Display-If-Installed: dev-db/mariadb +Display-If-Installed: dev-db/mariadb-galera +Display-If-Installed: dev-db/percona-server +Display-If-Installed: dev-db/google-mysql + +The PBXT/PrimeBase engine is unsupported upstream in MySQL & MariaDB for some +time now [1]. It is no longer built in the upstream MariaDB 5.5 binaries[2][3] +and if it is enabled in a source build, it fails many tests [4]. + +In light of this, the MySQL team has decided to mask it in +profiles/base/package.use.mask for all relevant packages. +>=dev-db/mysql-5.5 pbxt +>=dev-db/mariadb-5.5 pbxt +>=dev-db/mysql-cluster-5.5 pbxt # overlay +>=dev-db/mariadb-galera-5.5 pbxt # overlay +>=dev-db/percona-server-5.5 pbxt # overlay +>=dev-db/google-mysql-5.5 pbxt # overlay + +All users who have data stored in PBXT-backed tables MUST convert the tables +to another format BEFORE upgrading to MySQL/MariaDB 5.5, as the tables will +become inaccessible otherwise. + +We will continue to allow it to be built in the 5.0/5.1 series, to make the +above data migration easy, but we strongly encourage all users to move their +data out of the PBXT engine. + +If you need to check for PBXT tables easily, look in your MySQL/MariaDB +datadir for any files with a .xt extension. + +1. https://lists.launchpad.net/pbxt-discuss/msg00134.html +2. http://www.bytebot.net/blog/archives/2012/05/25/mariadb-5-5-has-deprecated-pbxt +3. https://kb.askmonty.org/en/about-pbxt/ +4. https://bugs.gentoo.org/show_bug.cgi?id=471616#c1 diff --git a/metadata/news/2013-06-30-cups16/2013-06-30-cups16.en.txt b/metadata/news/2013-06-30-cups16/2013-06-30-cups16.en.txt new file mode 100644 index 000000000000..ba72857d5ab7 --- /dev/null +++ b/metadata/news/2013-06-30-cups16/2013-06-30-cups16.en.txt @@ -0,0 +1,21 @@ +Title: Printer browsing in net-print/cups-1.6 +Author: Andreas K. Huettel <dilfridge@gentoo.org> +Content-Type: text/plain +Posted: 2013-06-30 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <=net-print/cups-1.6.2-r5 + +net-print/cups-1.6 no longer supports automatic remote printers or +implicit classes via the CUPS, LDAP, or SLP protocols, i.e. "network +browsing". + +The browsing functionality can be restored by running cups-browsed +from net-print/cups-filters as a separate daemon (just add its init +script to your default runlevel). By default cups-browsed uses the +net-print/cups-1.5 browse protocol, but it can also utilize zeroconf +(if the zeroconf use flag is set). See /etc/cups/cups-browsed.conf +for configuration. + +Of course, directly specifying the location of your printers in +the cups interface works as well. diff --git a/metadata/news/2013-08-07-vanilla-sources-stablization-policy/2013-08-07-vanilla-sources-stablization-policy.en.txt b/metadata/news/2013-08-07-vanilla-sources-stablization-policy/2013-08-07-vanilla-sources-stablization-policy.en.txt new file mode 100644 index 000000000000..75158ec826a0 --- /dev/null +++ b/metadata/news/2013-08-07-vanilla-sources-stablization-policy/2013-08-07-vanilla-sources-stablization-policy.en.txt @@ -0,0 +1,26 @@ +Title: vanilla-sources stabilization policy +Author: Mike Pagano <mpagano@gentoo.org> +Content-Type: text/plain +Posted: 2013-08-07 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: sys-kernel/vanilla-sources + +The Gentoo Kernel Team will no longer be providing stable +vanilla-sources kernels. All currently stabilized vanilla-sources +versions will be dropped to ~arch. The Arch teams, via normal requests +of the Kernel Team, will continue to stabilize gentoo-sources kernels +upon request. This decision is based on the facts that upstream is now +releasing approximately 1-2 vanilla-sources kernels a week. Arch teams, +understandably, are unable to keep up with this rate of release. As +most vanilla releases contain security fixes, the user who only runs +stable vanilla-sources will consistently be behind and potentially at +risk. For the latest "upstream kernel unpatched by Gentoo", we +recommend users add 'sys-kernel/vanilla-sources' to their +package.accept_keywords file. gentoo-sources will continue to be a +tested and supported version for Gentoo users. + + +Note: This news item only applies to gentoo-sources and vanilla-sources. +Other kernels currently maintained in portage have their own policies +and procedures in place today. diff --git a/metadata/news/2013-09-22-minor-arches-1/2013-09-22-minor-arches-1.en.txt b/metadata/news/2013-09-22-minor-arches-1/2013-09-22-minor-arches-1.en.txt new file mode 100644 index 000000000000..c6fc3ac58bff --- /dev/null +++ b/metadata/news/2013-09-22-minor-arches-1/2013-09-22-minor-arches-1.en.txt @@ -0,0 +1,28 @@ +Title: m68k, s390, sh are dropping stable keywords +Author: Andreas K. Huettel <dilfridge@gentoo.org> +Content-Type: text/plain +Posted: 2013-09-22 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Keyword: m68k +Display-If-Keyword: s390 +Display-If-Keyword: sh + +Following discussion [1] and a vote by the Gentoo Council [2,3], +m68k, s390, and sh will drop all stable keywords and become +unstable/testing only arches. The main reason for this is that +these arch teams visibly lack manpower, resulting in undesirable +delays. + +In a week, the ACCEPT_KEYWORDS variable in the respective profiles +will be switched to automatically include ~arch packages. Systems +running stable before will update to current unstable/testing then. +Afterwards m68k, s390, and sh keywords on all ebuilds will be +changed to ~m68k, ~s390, and ~sh. + +No steps are required from users, however you should be aware +of the upcoming changes. + +[1] http://thread.gmane.org/gmane.linux.gentoo.project/2975/focus=2984 +[2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917.txt +[3] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt diff --git a/metadata/news/2013-09-27-initramfs-required/2013-09-27-initramfs-required.en.txt b/metadata/news/2013-09-27-initramfs-required/2013-09-27-initramfs-required.en.txt new file mode 100644 index 000000000000..4f382a70ed8f --- /dev/null +++ b/metadata/news/2013-09-27-initramfs-required/2013-09-27-initramfs-required.en.txt @@ -0,0 +1,29 @@ +Title: Separate /usr on Linux requires initramfs +Author: William Hubbs <williamh@gentoo.org> +Content-Type: text/plain +Posted: 2013-09-27 +Revision: 1 +News-Item-Format: 1.0 + +Linux systems which have / and /usr on separate file systems but do not +use an initramfs will not be supported starting on 01-Nov-2013. + +If you have / and /usr on separate file systems and you are not +currently using an initramfs, you must set one up before this date. +Otherwise, at some point on or after this date, upgrading packages +will make your system unbootable. + +For more information on setting up an initramfs, see this URL: + +https://wiki.gentoo.org/wiki/Initramfs/HOWTO + +Due to many upstream changes, properly supporting Linux systems that +have /usr missing at boot time has become increasingly difficult. +Despite all our efforts, it already breaks in some exotic +configurations, and this trend is likely to grow worse. + +For more information on the upstream changes and why using an initramfs +is the cleanest route forward, see the following URLs: + +http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken +https://blog.flameeyes.eu/2013/01/the-boot-process diff --git a/metadata/news/2013-10-14-grub2-migration/2013-10-14-grub2-migration.en.txt b/metadata/news/2013-10-14-grub2-migration/2013-10-14-grub2-migration.en.txt new file mode 100644 index 000000000000..d9323463a13c --- /dev/null +++ b/metadata/news/2013-10-14-grub2-migration/2013-10-14-grub2-migration.en.txt @@ -0,0 +1,31 @@ +Title: GRUB2 migration +Author: Mike Gilbert <floppym@gentoo.org> +Content-Type: text/plain +Posted: 2013-10-14 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <sys-boot/grub-1 + +A newer version of GRUB (sys-boot/grub) is now stable. There are now +two available slots: + +sys-boot/grub:0 - Known as "GRUB Legacy" +sys-boot/grub:2 - Known as "GRUB2" + +GRUB2 uses a different configuration format, and requires a manual +migration before your system will actually use it. A guide [1] is +available on the gentoo.org website, and the Gentoo wiki [2][3] has +additional information. + +If you would prefer not to migrate at this time, you do not need to +take any action: GRUB Legacy will remain functional in /boot. To +prevent any associated files (documentation) from being removed, add +sys-boot/grub:0 to your world file. For example: + +emerge --noreplace sys-boot/grub:0 + +References: + +[1] http://www.gentoo.org/doc/en/grub2-migration.xml +[2] https://wiki.gentoo.org/wiki/GRUB2_Quick_Start +[3] https://wiki.gentoo.org/wiki/GRUB2 diff --git a/metadata/news/2013-10-24-minor-arches-2/2013-10-24-minor-arches-2.en.txt b/metadata/news/2013-10-24-minor-arches-2/2013-10-24-minor-arches-2.en.txt new file mode 100644 index 000000000000..4f2e0a72cfbe --- /dev/null +++ b/metadata/news/2013-10-24-minor-arches-2/2013-10-24-minor-arches-2.en.txt @@ -0,0 +1,23 @@ +Title: alpha, ia64: maintainers may remove stable versions +Author: Andreas K. Huettel <dilfridge@gentoo.org> +Content-Type: text/plain +Posted: 2013-10-24 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Keyword: alpha +Display-If-Keyword: ia64 + +Following discussion [1] and a vote by the Gentoo Council [2,3], +on alpha and ia64 package maintainers are allowed to remove +the last stable version of a package under certain circumstances +(basically when it is outdated and the stablerequest for a newer +version on alpha or ia64 has been pending for a while; for the +details, see [2,3]). + +You should be aware that this may occasionally cause broken +dependencies and/or require keywording of packages for stable +users. Then again, things may work out fine just as well. + +[1] http://thread.gmane.org/gmane.linux.gentoo.project/2975/focus=2984 +[2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917.txt +[3] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt diff --git a/metadata/news/2013-11-07-python-exec-package-move/2013-11-07-python-exec-package-move.en.txt b/metadata/news/2013-11-07-python-exec-package-move/2013-11-07-python-exec-package-move.en.txt new file mode 100644 index 000000000000..3e5536f71458 --- /dev/null +++ b/metadata/news/2013-11-07-python-exec-package-move/2013-11-07-python-exec-package-move.en.txt @@ -0,0 +1,46 @@ +Title: python-exec package move +Author: Michał Górny <mgorny@gentoo.org> +Content-Type: text/plain +Posted: 2013-11-07 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: dev-python/python-exec + +Due to the recent issues which caused dev-python/python-exec:0 to be +removed prematurely [1], we had to perform an urgent package move. +Since we could not use the automatic updates support in portage, users +will notice two python-exec packages and possibly blockers. + +Currently, dev-lang/python-exec is the real package that contains +python-exec and that will be used in the future. dev-python/python-exec +is a virtual package that is kept for compatibility with dependencies +in already-installed packages. + +In the most favorable scenario, the package will be upgraded correctly +on your next world update if you use the '--deep' (-D) and '--update' +(-u) options. If you don't want to perform a complete world update +or if it fails for you, you may as well manually upgrade +dev-python/python-exec: + + emerge -1 dev-python/python-exec + +This will cause portage to update both python-exec packages and resolve +the blockers properly. + +Please note that if you have applied any kind of package-specific +modifications to dev-python/python-exec (such as applying keywords +through 'package.accept_keywords'), you will need to copy them to +dev-lang/python-exec as well. + +If you have applied keywords to dev-python/python-exec in order +to unmask Python 3.3 on a stable system, please consider removing +the keywords and reading our wiki page that explains how to properly +unmask USE flags [2]. + +We apologize for all the inconveniences. If you have any more issues +with python-exec, please do not hesitate to contact as at #gentoo-python +IRC channel (@freenode) or the gentoo-python@lists.gentoo.org mailing +list. + +[1]:https://bugs.gentoo.org/show_bug.cgi?id=489440 +[2]:https://wiki.gentoo.org/wiki/Unmasking_non-stable_Python_implementations diff --git a/metadata/news/2013-11-23-gnome-38/2013-11-23-gnome-38.en.txt b/metadata/news/2013-11-23-gnome-38/2013-11-23-gnome-38.en.txt new file mode 100644 index 000000000000..11773fcc1931 --- /dev/null +++ b/metadata/news/2013-11-23-gnome-38/2013-11-23-gnome-38.en.txt @@ -0,0 +1,23 @@ +Title: Upgrade to GNOME 3.8 +Author: Pacho Ramos <pacho@gentoo.org> +Content-Type: text/plain +Posted: 2013-11-23 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <gnome-base/gnome-3.8 +Display-If-Installed: <gnome-base/gnome-light-3.8 +Display-If-Installed: <gnome-base/gnome-session-3.8 +Display-If-Installed: <gnome-base/gdm-3.8 + +We are pleased to announce the stabilization of GNOME 3.8. Users are +strongly encouraged to read the GNOME 3.8 Upgrade Guide to avoid any +possible issues relating to the upgrade. The guide will also show you +how to migrate to systemd as it is the only supported setup now, +suggesting you how to avoid blockers and problems trying to let you +have a smoother update. + +Additionally, it will inform you about important changes regarding +configuration and troubleshooting. + +Please read the Gnome 3.8 Upgrade Guide: +http://wiki.gentoo.org/wiki/GNOME/3.8-upgrade-guide 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 new file mode 100644 index 000000000000..9c37eeeaf4bf --- /dev/null +++ b/metadata/news/2014-02-25-udev-upgrade/2014-02-25-udev-upgrade.en.txt @@ -0,0 +1,28 @@ +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 new file mode 100644 index 000000000000..08a8ae6d1ce3 --- /dev/null +++ b/metadata/news/2014-03-12-profile-eapi-5/2014-03-12-profile-eapi-5.en.txt @@ -0,0 +1,47 @@ +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 new file mode 100644 index 000000000000..11017ab2b1c9 --- /dev/null +++ b/metadata/news/2014-03-16-ruby-1_8-removal/2014-03-16-ruby-1_8-removal.en.txt @@ -0,0 +1,26 @@ +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 new file mode 100644 index 000000000000..135dc69e62a3 --- /dev/null +++ b/metadata/news/2014-06-03-upower-loses-hibernate-suspend-to-systemd/2014-06-03-upower-loses-hibernate-suspend-to-systemd.en.txt @@ -0,0 +1,30 @@ +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-06-15-gcc48_ssp/2014-06-15-gcc48_ssp.en.txt b/metadata/news/2014-06-15-gcc48_ssp/2014-06-15-gcc48_ssp.en.txt new file mode 100644 index 000000000000..926f6ffdb26b --- /dev/null +++ b/metadata/news/2014-06-15-gcc48_ssp/2014-06-15-gcc48_ssp.en.txt @@ -0,0 +1,36 @@ +Title: GCC 4.8.3 defaults to -fstack-protector +Author: Ryan Hill <rhill@gentoo.org> +Content-Type: text/plain +Posted: 2014-06-15 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Installed: >=sys-devel/gcc-4.8.3 +Display-If-Keyword: amd64 +Display-If-Keyword: arm +Display-If-Keyword: mips +Display-If-Keyword: ppc +Display-If-Keyword: ppc64 +Display-If-Keyword: x86 +Display-If-Keyword: amd64-fbsd +Display-If-Keyword: x86-fbsd + +Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be +enabled by default. The 4.8 series will enable -fstack-protector +while 4.9 and later enable -fstack-protector-strong. + +SSP is a security feature that attempts to mitigate stack-based buffer +overflows by placing a canary value on the stack after the function +return pointer and checking for that value before the function returns. +If a buffer overflow occurs and the canary value is overwritten, the +program aborts. + +There is a small performance cost to these features. They can be +disabled with -fno-stack-protector. + +For more information these options, refer to the GCC Manual, or the +following articles. + +http://en.wikipedia.org/wiki/Buffer_overflow_protection +http://en.wikipedia.org/wiki/Stack_buffer_overflow +https://securityblog.redhat.com/tag/stack-protector +http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong 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 new file mode 100644 index 000000000000..11ce7a04bfa6 --- /dev/null +++ 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 @@ -0,0 +1,27 @@ +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 new file mode 100644 index 000000000000..f0feef1c57a2 --- /dev/null +++ b/metadata/news/2014-08-20-mysql_5_5_upgrade_procedures/2014-08-20-mysql_5_5_upgrade_procedures.en.txt @@ -0,0 +1,31 @@ +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 new file mode 100644 index 000000000000..081d8a7ba9ed --- /dev/null +++ b/metadata/news/2014-10-04-restructuring_of_mips_profiles/2014-10-04-restructuring_of_mips_profiles.en.txt @@ -0,0 +1,51 @@ +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 new file mode 100644 index 000000000000..a6ecb8200c5c --- /dev/null +++ b/metadata/news/2014-10-22-mythtv-schedulesdirect-change/2014-10-22-mythtv-schedulesdirect-change.en.txt @@ -0,0 +1,18 @@ +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 new file mode 100644 index 000000000000..77372bdf4547 --- /dev/null +++ b/metadata/news/2014-10-22-upgrading-to-musl-1_1_5/2014-10-22-upgrading-to-musl-1_1_5.en.txt @@ -0,0 +1,57 @@ +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-10-26-gcc_4_7_introduced_new_c++11_abi/2014-10-26-gcc_4_7_introduced_new_c++11_abi.en.txt b/metadata/news/2014-10-26-gcc_4_7_introduced_new_c++11_abi/2014-10-26-gcc_4_7_introduced_new_c++11_abi.en.txt new file mode 100644 index 000000000000..d074dbe27d24 --- /dev/null +++ b/metadata/news/2014-10-26-gcc_4_7_introduced_new_c++11_abi/2014-10-26-gcc_4_7_introduced_new_c++11_abi.en.txt @@ -0,0 +1,50 @@ +Title: GCC 4.7 Introduced the New C++11 ABI +Author: Anthony G. Basile <blueness@gentoo.org> +Content-Type: text/plain +Posted: 2014-10-26 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: >=sys-devel/gcc-4.7.0 +Display-If-Keyword: amd64 +Display-If-Keyword: arm +Display-If-Keyword: mips +Display-If-Keyword: ppc +Display-If-Keyword: ppc64 +Display-If-Keyword: x86 +Display-If-Keyword: amd64-fbsd +Display-If-Keyword: x86-fbsd + +GCC 4.7 introduced the new experimental 2011 ISO C++ standard [1], along with +its GNU variant. This new standard is not the default in gcc-4.7, 4.8 or 4.9, +the default is still gnu++98, but it can be enabled by passing -std=c++11 or +-std=gnu++11 to CXXFLAGS. + +Users that wish to try C++11 should exercise caution because it is not +ABI-compatible with C++98. Nor is C++11 code compiled with gcc-4.7 guaranteed +to be ABI-compatible with C++11 compiled with 4.8, or vice versa [2]. Thus +linking C++98 and C++11, or C++11 compiled with different versions of gcc, is +likely to cause breakage. For packages which are self-contained or do not link +against any libraries written in C++, there is no problem. However, switching +to C++11 and then building packages which link against any of the numerous +libraries in an incompatible ABI can lead to a broken system. + +This is a precautionary news item and the typical user need not do anything. +However, as C++11 gains in popularity and the number of packages using it +increases, it is important that users understand these issues [3]. + +For an ABI compliance checker, and more information about C++ ABIs, see [4]. + +Ref. + +[1] http://www.stroustrup.com/C++11FAQ.html + +[2] Upstream GCC does not support ABI-compatibility between gcc-4.x and 4.y for +any x != y . See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758. Even +having different versions of gcc installed simultaneously may lead to problems, +especially if the older version of gcc is active. An example is +https://bugs.gentoo.org/show_bug.cgi?id=513386. + +[3] Note that some packages like www-client/chromium and net-libs/webkit-gtk +are already using C++11 features. + +[4] http://ispras.linuxbase.org/index.php/ABI_compliance_checker 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 new file mode 100644 index 000000000000..c1466095ced7 --- /dev/null +++ b/metadata/news/2014-11-07-udev-upgrade/2014-11-07-udev-upgrade.en.txt @@ -0,0 +1,16 @@ +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 new file mode 100644 index 000000000000..635c865ae9f8 --- /dev/null +++ b/metadata/news/2014-11-11-kgcc64-sparc-removal/2014-11-11-kgcc64-sparc-removal.en.txt @@ -0,0 +1,16 @@ +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 new file mode 100644 index 000000000000..f63ca7738a5e --- /dev/null +++ b/metadata/news/2014-11-25-bash-completion-2_1-r90/2014-11-25-bash-completion-2_1-r90.en.txt @@ -0,0 +1,51 @@ +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/2015-02-01-use-libav/2015-02-01-use-libav.en.txt b/metadata/news/2015-02-01-use-libav/2015-02-01-use-libav.en.txt new file mode 100644 index 000000000000..47d54f476d90 --- /dev/null +++ b/metadata/news/2015-02-01-use-libav/2015-02-01-use-libav.en.txt @@ -0,0 +1,35 @@ +Title: ffmpeg/libav conflict management: USE=libav +Author: Michał Górny <mgorny@gentoo.org> +Content-Type: text/plain +Posted: 2015-02-01 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Installed: media-video/ffmpeg +Display-If-Installed: media-video/libav + +The support for automatic choice between ffmpeg and libav is going to be +deprecated in favor of explicit choice via USE flags. This change aims +to solve multiple repeating issues, including Portage undesirably +wanting to replace one package with the other, lack of proper reverse +dependency on ffmpeg/libav upgrades and some of the hard-to-understand +upgrade failures involving blockers. It also may be used to make ffmpeg +and libav co-installable in the future. + +The current USE=ffmpeg will maintain its role of enabling optional +support for ffmpeg or a compatible implementation (libav) in a package. +However, whenever appropriate additional USE=libav will be introduced to +control the preference of one implementation over the other. + +Users who currently use libav need to enable USE=libav in +/etc/portage/make.conf. It should be noted that users still need to +enable USE=ffmpeg on packages with optional libav support as well. +Users who currently use ffmpeg need to take no action. + +Please also note that some packages support only one of the two +implementations. An attempt to install one of those packages may result +in blockers requiring the user changes the global USE=libav state. + +Please do not alter the state of 'libav' flag on a per-package basis +(e.g. via package.use). The flag needs to be set globally to have +consistent value throughout all packages. Otherwise, blockers will +prevent upgrades. 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 new file mode 100644 index 000000000000..7e1b2be650ca --- /dev/null +++ b/metadata/news/2015-02-02-nfs-service-changes/2015-02-02-nfs-service-changes.en.txt @@ -0,0 +1,39 @@ +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 new file mode 100644 index 000000000000..5a2d2124ba42 --- /dev/null +++ b/metadata/news/2015-02-04-portage-sync-changes/2015-02-04-portage-sync-changes.en.txt @@ -0,0 +1,77 @@ +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 + +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 new file mode 100644 index 000000000000..f90d09191dee --- /dev/null +++ b/metadata/news/2015-04-06-apache-addhandler-addtype/2015-04-06-apache-addhandler-addtype.en.txt @@ -0,0 +1,100 @@ +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-04-16-ffmpeg-default/2015-04-16-ffmpeg-default.en.txt b/metadata/news/2015-04-16-ffmpeg-default/2015-04-16-ffmpeg-default.en.txt new file mode 100644 index 000000000000..82c01f18678a --- /dev/null +++ b/metadata/news/2015-04-16-ffmpeg-default/2015-04-16-ffmpeg-default.en.txt @@ -0,0 +1,25 @@ +Title: FFmpeg default +Author: Ben de Groot <yngwin@gentoo.org> +Content-Type: text/plain +Posted: 2015-04-16 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: media-video/ffmpeg +Display-If-Installed: media-video/libav + +Since the choice between ffmpeg and libav has been made more +explicit, there has been a lot of discussion about what the +default implementation should be. It can be concluded that +media-video/ffmpeg has wider support, and would be somewhat +more convenient for most end-users. + +For this reason the default implementation has been switched +back from media-video/libav to media-video/ffmpeg by removing +the libav useflag from the base profile. + +If the libav useflag is already globally enabled or disabled +in /etc/portage/make.conf, then no further action is required. + +Users who implicitly relied on libav being enabled in their +profile, and who wish to continue using libav, should enable +USE=libav in their /etc/portage/make.conf file. 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 new file mode 100644 index 000000000000..08d1cdbf1bb4 --- /dev/null +++ b/metadata/news/2015-05-01-shorewall-changes/2015-05-01-shorewall-changes.en.txt @@ -0,0 +1,43 @@ +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 new file mode 100644 index 000000000000..5ab36d74f995 --- /dev/null +++ b/metadata/news/2015-06-08-udev-init-scripts-changes/2015-06-08-udev-init-scripts-changes.en.txt @@ -0,0 +1,20 @@ +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-07-25-python-targets/2015-07-25-python-targets.en.txt b/metadata/news/2015-07-25-python-targets/2015-07-25-python-targets.en.txt new file mode 100644 index 000000000000..720eb66760d2 --- /dev/null +++ b/metadata/news/2015-07-25-python-targets/2015-07-25-python-targets.en.txt @@ -0,0 +1,26 @@ +Title: Python 3.4 enabled by default +Author: Mike Gilbert <floppym@gentoo.org> +Content-Type: text/plain +Posted: 2015-07-25 +Revision: 1 +News-Item-Format: 1.0 + +Python 3.4 is now enabled by default, replacing Python 3.3 as the +default Python 3 interpreter. + +PYTHON_TARGETS will be adjusted to contain python2_7 and python3_4 by +default via your profile. + +PYTHON_SINGLE_TARGET will remain set to python2_7 by default. + +If you have PYTHON_TARGETS set in make.conf, that setting will still be +respected. You may want to adjust this setting manually. + +Once the changes have taken place, a world update should take care of +reinstalling any python libraries you have installed. You should also +switch your default python3 interpreter using eselect python. + +For example: + +eselect python set --python3 python3.4 +emerge -uDv --changed-use @world 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 new file mode 100644 index 000000000000..488c980fbed5 --- /dev/null +++ b/metadata/news/2015-08-11-nepomuk-removal/2015-08-11-nepomuk-removal.en.txt @@ -0,0 +1,24 @@ +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-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt b/metadata/news/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt new file mode 100644 index 000000000000..1c4f296551e4 --- /dev/null +++ b/metadata/news/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt @@ -0,0 +1,27 @@ +Title: OpenSSH 7.0 disables ssh-dss keys by default +Author: Mike Frysinger <vapier@gentoo.org> +Content-Type: text/plain +Posted: 2015-08-13 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: net-misc/openssh + +Starting with the 7.0 release of OpenSSH, support for ssh-dss keys has +been disabled by default at runtime due to their inherit weakness. If +you rely on these key types, you will have to take corrective action or +risk being locked out. + +Your best option is to generate new keys using strong algos such as rsa +or ecdsa or ed25519. RSA keys will give you the greatest portability +with other clients/servers while ed25519 will get you the best security +with OpenSSH (but requires recent versions of client & server). + +If you are stuck with DSA keys, you can re-enable support locally by +updating your sshd_config and ~/.ssh/config files with lines like so: + PubkeyAcceptedKeyTypes=+ssh-dss + +Be aware though that eventually OpenSSH will drop support for DSA keys +entirely, so this is only a stop gap solution. + +More details can be found on OpenSSH's website: + http://www.openssh.com/legacy.html 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 new file mode 100644 index 000000000000..97c2465f7004 --- /dev/null +++ b/metadata/news/2015-08-26-ruby-19-removal/2015-08-26-ruby-19-removal.en.txt @@ -0,0 +1,26 @@ +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 new file mode 100644 index 000000000000..83ed083c6ce1 --- /dev/null +++ b/metadata/news/2015-09-09-libvirt-init-script-changes/2015-09-09-libvirt-init-script-changes.en.txt @@ -0,0 +1,24 @@ +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 new file mode 100644 index 000000000000..7b2b688d7147 --- /dev/null +++ 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 @@ -0,0 +1,17 @@ +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 new file mode 100644 index 000000000000..3d5c76cba3d4 --- /dev/null +++ b/metadata/news/2015-10-21-future-support-of-hardened-sources-kernel/2015-10-21-future-support-of-hardened-sources-kernel.en.txt @@ -0,0 +1,62 @@ +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-10-22-gcc-5-new-c++11-abi/2015-10-22-gcc-5-new-c++11-abi.en.txt b/metadata/news/2015-10-22-gcc-5-new-c++11-abi/2015-10-22-gcc-5-new-c++11-abi.en.txt new file mode 100644 index 000000000000..9760753cee3c --- /dev/null +++ b/metadata/news/2015-10-22-gcc-5-new-c++11-abi/2015-10-22-gcc-5-new-c++11-abi.en.txt @@ -0,0 +1,26 @@ +Title: GCC 5 Defaults to the New C++11 ABI +Author: Mike Frysinger <vapier@gentoo.org> +Content-Type: text/plain +Posted: 2015-10-22 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Installed: >=sys-devel/gcc-5 + +GCC 5 uses the new C++ ABI by default. When building new code, you might run +into link time errors that include lines similar to: +...: undefined reference to '_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17' + +Or you might see linkage failures with "std::__cxx11::string" in the output. + +These are signs that you need to rebuild packages using the new C++ ABI. +You can quickly do so by using revdep-rebuild (from gentoolkit). + +For gentoolkit-0.3.1 or higher: +# revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc + +For previous versions of gentoolkit: +# revdep-rebuild --library 'libstdc\+\+\.so\.6' -- --exclude gcc + +For more details, feel free to peruse: +https://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ +https://blogs.gentoo.org/blueness/2015/03/10/the-c11-abi-incompatibility-problem-in-gentoo/ 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 new file mode 100644 index 000000000000..7fa3adea7a79 --- /dev/null +++ b/metadata/news/2015-12-16-python-abiflags-rebuild-needed/2015-12-16-python-abiflags-rebuild-needed.en.txt @@ -0,0 +1,53 @@ +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/2016-01-08-some-dhcpcd-hooks-are-now-examples/2016-01-08-some-dhcpcd-hooks-are-now-examples.en.txt b/metadata/news/2016-01-08-some-dhcpcd-hooks-are-now-examples/2016-01-08-some-dhcpcd-hooks-are-now-examples.en.txt new file mode 100644 index 000000000000..848a842b446c --- /dev/null +++ b/metadata/news/2016-01-08-some-dhcpcd-hooks-are-now-examples/2016-01-08-some-dhcpcd-hooks-are-now-examples.en.txt @@ -0,0 +1,21 @@ +Title: Some dhcpcd hooks are now examples +Author: William Hubbs <williamh@gentoo.org> +Content-Type: text/plain +Posted: 2016-01-08 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Installed: <=net-misc/dhcpcd-6.10.0 + +In dhcpcd-6.10.0, the following hooks are no longer installed in +/lib/dhcpcd/dhcpcd-hooks by default: + +10-wpa_supplicant +15-timezone +29-lookup-hostname + +These are now installed in /usr/share/dhcpcd/hooks, which is an example +directory. + +If you were using these hooks before you upgrade to 6.10.0, you will +need to copy them back to the /lib/dhcpcd/dhcpcd-hooks directory after the +upgrade. diff --git a/metadata/news/2016-01-27-upgrading-to-apache-2_4/2016-01-27-upgrading-to-apache-2_4.en.txt b/metadata/news/2016-01-27-upgrading-to-apache-2_4/2016-01-27-upgrading-to-apache-2_4.en.txt new file mode 100644 index 000000000000..bff0e7d400f9 --- /dev/null +++ b/metadata/news/2016-01-27-upgrading-to-apache-2_4/2016-01-27-upgrading-to-apache-2_4.en.txt @@ -0,0 +1,23 @@ +Title: Upgrading Apache from 2.2 to 2.4 +Author: Dirkjan Ochtman <djc@gentoo.org> +Content-Type: text/plain +Posted: 2016-01-27 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: www-servers/apache + +With the 2.4 branch released by upstream almost 4 years ago, stable +Gentoo systems will soon be upgraded from apache 2.2 to apache 2.4. +When upgrading, some configuration changes will have to be made. +Upstream has a handy guide: + +https://httpd.apache.org/docs/2.4/upgrading.html + +For more information on all the new features, start here: + +https://httpd.apache.org/docs/trunk/new_features_2_4.html + +After emerging Apache 2.4, you will also need to rebuild any +third-party modules: + +emerge -av1 /usr/lib/apache2/modules --exclude=www-servers/apache diff --git a/metadata/news/2016-04-07-kde-plasma5-stable/2016-04-07-kde-plasma5-stable.en.txt b/metadata/news/2016-04-07-kde-plasma5-stable/2016-04-07-kde-plasma5-stable.en.txt new file mode 100644 index 000000000000..c9302f0911ec --- /dev/null +++ b/metadata/news/2016-04-07-kde-plasma5-stable/2016-04-07-kde-plasma5-stable.en.txt @@ -0,0 +1,38 @@ +Title: KDE Plasma 5 Upgrade +Author: Michael Palimaka <kensington@gentoo.org> +Content-Type: text/plain +Posted: 2016-04-02 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: kde-base/plasma-workspace + +KDE Workspaces 4.11 has reached end of life and is no longer supported +by upstream. It is therefore recommended for all users to upgrade to +KDE Plasma 5. + +A detailed upgrade guide is available[1], but in most cases it is enough to +switch to the new desktop/plasma profile, update @world, and +emerge kde-plasma/plasma-meta: + +# eselect profile list +# eselect profile set <target> +# emerge --ask --changed-use --newrepo --deep world +# emerge --ask --verbose kde-plasma/plasma-meta + +If you normally use KDM to launch Plasma, note that it is no longer supported. +Upstream recommends x11-misc/sddm instead which is pulled in by plasma-meta by +default. OpenRC users should edit /etc/conf.d/xdm and update DISPLAYMANAGER. +Systemd users should run: systemctl reenable sddm.service + +Due to an an evolution of KDE upstream's release process[2], the traditional +monolithic KDE 4 release is now split into three distinct components. This +means that KDE Applications are now separate from the Plasma desktop and +older KDE 4-based applications will continue to function as normal inside +Plasma 5. + +KDE Workspaces 4.11 will remain in the tree for a reasonable time, but +be warned that it is unmaintained and may cause conflicts with +newer versions of KDE Applications. + +[1] https://wiki.gentoo.org/wiki/KDE/Plasma_5_upgrade +[2] https://dot.kde.org/2013/09/04/kde-release-structure-evolves diff --git a/metadata/news/2016-04-24-default-video-cards/2016-04-24-default-video-cards.en.txt b/metadata/news/2016-04-24-default-video-cards/2016-04-24-default-video-cards.en.txt new file mode 100644 index 000000000000..8a94240b08e9 --- /dev/null +++ b/metadata/news/2016-04-24-default-video-cards/2016-04-24-default-video-cards.en.txt @@ -0,0 +1,27 @@ +Title: Changes in default VIDEO_CARDS +Author: Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> +Content-Type: text/plain +Posted: 2016-04-24 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Keyword: amd64 +Display-If-Keyword: x86 +Display-If-Installed: x11-drivers/xf86-video-dummy +Display-If-Installed: x11-drivers/xf86-video-glint +Display-If-Installed: x11-drivers/xf86-video-mach64 +Display-If-Installed: x11-drivers/xf86-video-mga +Display-If-Installed: x11-drivers/xf86-video-nv +Display-If-Installed: x11-drivers/xf86-video-r128 +Display-If-Installed: x11-drivers/xf86-video-savage +Display-If-Installed: x11-drivers/xf86-video-tdfx +Display-If-Installed: x11-drivers/xf86-video-trident +Display-If-Installed: x11-drivers/xf86-video-v4l +Display-If-Installed: x11-drivers/xf86-video-via +Display-If-Installed: x11-drivers/xf86-video-vmware + +In order to better reflect the graphics chipsets present on modern +systems, the default VIDEO_CARDS setting has been changed to +"amdgpu fbdev intel nouveau radeon radeonsi vesa" + +If your graphics chipset requires a different driver, and you have not set +VIDEO_CARDS in make.conf, it is advisable to do that now. diff --git a/metadata/news/2016-05-23-lastpass-changes/2016-05-23-lastpass-changes.en.txt b/metadata/news/2016-05-23-lastpass-changes/2016-05-23-lastpass-changes.en.txt new file mode 100644 index 000000000000..4534932a7929 --- /dev/null +++ b/metadata/news/2016-05-23-lastpass-changes/2016-05-23-lastpass-changes.en.txt @@ -0,0 +1,30 @@ +Title: LastPass package migration +Author: Göktürk Yüksek <gokturk@gentoo.org> +Author: Robin H. Johnson <robbat2@gentoo.org> +Content-Type: text/plain +Posted: 2016-05-23 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: app-admin/lastpass + +LastPass-3 and earlier versions installed browser extensions along +with the necessary binary components. LastPass-4 and later versions +install only the binary components and leave installing the browser +extensions to the user. Furthermore, LastPass-3 is not available +anymore, it will be removed soon and users are required to upgrade. A +transparent package move is not possible due to the mentioned changes +and a manual migration is required. + +The currently installed package must be removed before proceeding with +the migration: + +emerge --unmerge --ask app-admin/lastpass + +LastPass for Firefox users can safely upgrade to version 4 by visiting +the official LastPass website and following the download instructions. +The browser extension already contains the required binary components. +No packages need to be installed. + +Users of Chrome/Chromium and Opera browsers need to switch to +app-admin/lastpass-binary-component and follow the instructions +displayed on the screen after the installation to complete the process. diff --git a/metadata/news/2016-06-23-l10n-use_expand/2016-06-23-l10n-use_expand.en.txt b/metadata/news/2016-06-23-l10n-use_expand/2016-06-23-l10n-use_expand.en.txt new file mode 100644 index 000000000000..2ff30d780bff --- /dev/null +++ b/metadata/news/2016-06-23-l10n-use_expand/2016-06-23-l10n-use_expand.en.txt @@ -0,0 +1,49 @@ +Title: L10N USE_EXPAND variable replacing LINGUAS +Author: Mart Raudsepp <leio@gentoo.org> +Author: Ulrich Müller <ulm@gentoo.org> +Content-Type: text/plain +Posted: 2016-06-19 +Revision: 1 +News-Item-Format: 1.0 + +The L10N variable is replacing LINGUAS as a USE_EXPAND, to avoid a +conceptual clash with the standard gettext LINGUAS behaviour. + +L10N controls which extra localization support will be installed. +This is commonly used for downloads of additional language packs. + +If you have set LINGUAS in your make.conf, you most likely want to add +its entries also to L10N. Note that while the common two letter language +codes (like "de" or "fr") are identical, more complex entries have a +different syntax because L10N now uses IETF language tags. (For example, +"pt_BR" becomes "pt-BR" and "sr@latin" becomes "sr-Latn".) You can look +up the available codes in profiles/desc/l10n.desc in the gentoo tree. +A detailed description of language tags (aka BCP 47) can be found at: +https://www.w3.org/International/articles/language-tags/ + +After a transition time for packages to be converted, the LINGUAS +environment variable will maintain the standard gettext behaviour and +will work as expected with all package managers. It controls which +language translations are built and installed. An unset value means all +available, an empty value means none, and a value can be an unordered +list of gettext language codes, with or without country codes. Usually +two letter language codes suffice, but can be narrowed down by country +codes with a "ll_CC" formatting, where "ll" is the language code and +"CC" is the country code, e.g., "en_GB". Some rare languages also have +three letter language codes. Note that LINGUAS does not only affect +installed gettext catalog files (*.mo), but also lines of translations +in an always shipped file (e.g., *.desktop). + +If you want English with a set LINGUAS, it is suggested to list it with +the desired country code, in case the default is not the usual "en_US". +It is also common to list "en" then, in case a package is natively +written in a different language, but does provide an English translation +for whichever country. A list of LINGUAS language codes is available at: +http://www.gnu.org/software/gettext/manual/gettext.html#Language-Codes + +If you have per-package customizations of the LINGUAS USE_EXPAND, you +should also rename those. This typically means changing linguas_* to +l10n_*, and possibly updating the syntax as described above. + +https://wiki.gentoo.org/wiki/Localization/Guide has also been updated to +reflect this change. diff --git a/metadata/news/2016-08-08-openafs-debug_rodata/2016-08-08-openafs-debug_rodata.en.txt b/metadata/news/2016-08-08-openafs-debug_rodata/2016-08-08-openafs-debug_rodata.en.txt new file mode 100644 index 000000000000..3997c7df8113 --- /dev/null +++ b/metadata/news/2016-08-08-openafs-debug_rodata/2016-08-08-openafs-debug_rodata.en.txt @@ -0,0 +1,30 @@ +Title: OpenAFS no longer needs kernel option DEBUG_RODATA +Author: NP-Hardass <NP-Hardass@gentoo.org> +Author: Andrew Savchenko <bircoph@gentoo.org> +Content-Type: text/plain +Posted: 2016-08-08 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2 +Display-If-Keyword: amd64 +Display-If-Keyword: ~amd64-linux +Display-If-Keyword: ~sparc +Display-If-Keyword: x86 +Display-If-Keyword: ~x86-linux + +As a result of bug #127084 [1], it was determined that OpenAFS's +kernel module required that the kernel's data structures be +read-write (CONFIG_DEBUG_RODATA=n). With recent OpenAFS versions +this limitation is no longer required. We tested the latest version +of OpenAFS with Linux kernels from 3.4 till 4.6, and determined that +OpenAFS kernel module works fine with CONFIG_DEBUG_RODATA=y. + +Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no +longer forced in the ebuild. Considering the security implications +of having CONFIG_DEBUG_RODATA turned off, it is highly advised that +you adjust your kernel config accordingly. Please note that the +default setting for CONFIG_DEBUG_RODATA is "y" and unless you have +another reason for keeping it disabled, we highly recommend that +you re-enable CONFIG_DEBUG_RODATA. + +[1] https://bugs.gentoo.org/show_bug.cgi?id=127084 diff --git a/metadata/news/2016-08-11-grub2_multislot_default/2016-08-11-grub2_multislot_default.en.txt b/metadata/news/2016-08-11-grub2_multislot_default/2016-08-11-grub2_multislot_default.en.txt new file mode 100644 index 000000000000..2cd1891c405a --- /dev/null +++ b/metadata/news/2016-08-11-grub2_multislot_default/2016-08-11-grub2_multislot_default.en.txt @@ -0,0 +1,21 @@ +Title: Grub2 multislot default setting is changing +Author: William Hubbs <williamh@gentoo.org> +Author: Ian Stakenvicius <axs@gentoo.org> +Content-Type: text/plain +Posted: 2016-08-11 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: >=sys-boot/grub-2 + +The multislot use flag in sys-boot/grub-2.x is no longer enabled by +default. + +When the flag is enabled, all upstream binaries and documentation are +renamed to "grub2" so as not to collide with grub-0. Now that the use +flag is no longer default-enabled, these names will revert back to +their upstream defaults. For example, grub2-mkconfig will become +grub-mkconfig, grub2-install will become grub-install, etc. + +If you wish to retain the previous naming scheme, please make sure to +explicitly enable USE="multislot" on sys-boot/grub in the usual manner. + diff --git a/metadata/news/2016-09-26-migration-to-sys-libs_uclibc-ng/2016-09-26-migration-to-sys-libs_uclibc-ng.en.txt b/metadata/news/2016-09-26-migration-to-sys-libs_uclibc-ng/2016-09-26-migration-to-sys-libs_uclibc-ng.en.txt new file mode 100644 index 000000000000..6a0e2f016ab3 --- /dev/null +++ b/metadata/news/2016-09-26-migration-to-sys-libs_uclibc-ng/2016-09-26-migration-to-sys-libs_uclibc-ng.en.txt @@ -0,0 +1,47 @@ +Title: Migration to sys-libs/uclibc-ng +Author: Anthony G. Basile <blueness@gentoo.org> +Content-Type: text/plain +Posted: 2016-09-26 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: sys-libs/uclibc +Display-If-Profile: default/linux/uclibc/amd64 +Display-If-Profile: hardened/linux/uclibc/amd64 +Display-If-Profile: default/linux/uclibc/arm/armv7a +Display-If-Profile: hardened/linux/uclibc/arm/armv7a +Display-If-Profile: default/linux/uclibc/mips +Display-If-Profile: hardened/linux/uclibc/mips +Display-If-Profile: default/linux/uclibc/mips/mipsel +Display-If-Profile: hardened/linux/uclibc/mips/mipsel +Display-If-Profile: default/linux/uclibc/ppc +Display-If-Profile: hardened/linux/uclibc/ppc +Display-If-Profile: default/linux/uclibc/x86 +Display-If-Profile: hardened/linux/uclibc/x86 + +Upstream development of uClibc has been stalled since July 2015 and +there hasn't been a proper release since May 2012 [1]. New patches +addressing important issues have been submitted but these have not been +reviewed nor have they been committed to the master branch. Also, +backporting even those patches which have been committed to master is +now impractical as too many intermediate layers of patches conflict. +For all intents and purposes, upstream uClibc is dead. + +Fortunately, a fork called uClibc-ng [2] was begun by Waldemar Brodkorb +in February 2015 and is actively being maintained. Accordingly, +Gentoo's Hardened uClibc project will be migrating to uClibc-ng as its +libc provider. Currently stage3 tarballs based on sys-libs/uclibc-ng +are available for all supported arches at [3] and these will become the +default after October 5, 2016. Older stage3s based on sys-libs/uclibc +will be removed. + +Unfortunately, migrating a production system from uclibc to uclibc-ng +is not straightforward owing to the central role played by libc. A +migration guide is provided at [4]. This has been tested on live +systems with success, but the user is cautioned to plan a backup and +recovery plan should something go wrong. + +Refs. +[1] https://git.uclibc.org/uClibc/log/ +[2] http://uclibc-ng.org/ +[3] http://distfiles.gentoo.org/experimental/ +[4] https://wiki.gentoo.org/wiki/Project:Hardened_uClibc#Migration_to_uClibc-ng diff --git a/metadata/news/2016-09-27-openrc_0_22_updates/2016-09-27-openrc_0_22_updates.en.txt b/metadata/news/2016-09-27-openrc_0_22_updates/2016-09-27-openrc_0_22_updates.en.txt new file mode 100644 index 000000000000..48dfe46ce467 --- /dev/null +++ b/metadata/news/2016-09-27-openrc_0_22_updates/2016-09-27-openrc_0_22_updates.en.txt @@ -0,0 +1,22 @@ +Title: OpenRC 0.22 updates +Author: William Hubbs <williamh@gentoo.org> +Content-Type: text/plain +Posted: 2016-09-27 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <=sys-apps/openrc-0.22 + +OpenRC 0.22 introduces the following changes: + +- In previous versions of OpenRC, configuration information was processed + so that service-specific configuration stored in /etc/conf.d/* was + overridden by global configuration stored in /etc/rc.conf. OpenRC 0.22 + reverses that. Global configuration stored in /etc/rc.conf is read first + then overridden by configuration stored in /etc/conf.d/*. + +- The swapfiles service, which was basically a copy of the swap service, + has been removed. If you are only using local swap partitions, as + described in the handbook for example, this change will not affect you. + If you are using swap files or swap partitions on network-backed devices + such as iSCSI, please adjust the dependencies of the swap + service as shown in /etc/conf.d/swap to reflect your situation. diff --git a/metadata/news/2016-10-25-llvm_3_9_with_llvm_targets/2016-10-25-llvm_3_9_with_llvm_targets.en.txt b/metadata/news/2016-10-25-llvm_3_9_with_llvm_targets/2016-10-25-llvm_3_9_with_llvm_targets.en.txt new file mode 100644 index 000000000000..d5656db56539 --- /dev/null +++ b/metadata/news/2016-10-25-llvm_3_9_with_llvm_targets/2016-10-25-llvm_3_9_with_llvm_targets.en.txt @@ -0,0 +1,41 @@ +Title: LLVM 3.9 with LLVM_TARGETS +Author: Michał Górny <mgorny@gentoo.org> +Content-Type: text/plain +Posted: 2016-10-25 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <sys-devel/llvm-3.9 + +The newest release of LLVM 3.9 has undergone major Gentoo changes, +and may require explicit action prior to the upgrade. In this release, +the semi-implicit target choice has been replaced with an explicit +LLVM_TARGETS flag set. + +If you did not enable USE=multitarget, no action should be required. +The targets for your host CPU, Berkeley Packet Filter (used by some +packages) and possibly two major GPUs (AMDGPU and NVPTX) will be enabled +by default which is a superset of the previous default. However, you may +want to disable some of those targets if you do not intend to install +packages requiring them (dev-util/bcc, media-libs/mesa). + +If you enabled USE=multitarget, you will now need to specify all +the requested targets explicitly. The old flag will be preserved +for some time for compatibility reasons; however, it will only enforce +explicitly selecting all targets. + +In order to enable all targets, add the following to your +/etc/portage/package.use or equivalent file: + + sys-devel/llvm LLVM_TARGETS: * + sys-devel/clang LLVM_TARGETS: * + +If you had to use USE=multitarget to enable some of the targets you +needed, you can now disable the flag and specify those targets +explicitly. + +Please also note that starting with LLVM-4.0, sys-devel/clang will be +built as a separate package and the enabled LLVM_TARGETS for that +package will actually enforce requested targets. + +Setting LLVM_TARGETS globally is discouraged as it can cause bootstrap +issues with sys-libs/compiler-rt in the future. diff --git a/metadata/news/2016-11-04-important_fstab_and_localmount_update/2016-11-04-important_fstab_and_localmount_update.en.txt b/metadata/news/2016-11-04-important_fstab_and_localmount_update/2016-11-04-important_fstab_and_localmount_update.en.txt new file mode 100644 index 000000000000..3cd9a8f25541 --- /dev/null +++ b/metadata/news/2016-11-04-important_fstab_and_localmount_update/2016-11-04-important_fstab_and_localmount_update.en.txt @@ -0,0 +1,28 @@ +Title: Important fstab and localmount update +Author: William Hubbs <williamh@gentoo.org> +Author: Ian Stakenvicius <axs@gentoo.org> +Display-If-Installed: <=sys-apps/openrc-0.23 +Content-Type: text/plain +Posted: 2016-11-04 +Revision: 2 +News-Item-Format: 1.0 + +Recent updates to service scripts in OpenRC and (e)udev have removed the +requirement for udev to "settle" before its startup completes. The +result of this is that services which used to wait for udev to finish +processing all kernel events will now start earlier. One such service +is localmount. + +If "/dev/disk/by-*" device paths are used for mount points in +fstab, it is possible that those symbolic links will not exist when +localmount starts and attempts to mount them. + +The recommended solution is to convert fstab from using +"/dev/disk/by-*" to the LABEL=, UUID=, PARTLABEL= or PARTUUID= syntax. +This syntax is supported directly by both util-linux and busybox's mount +commands and has no dependency on any device manager. More information +on this syntax can be found in the fstab(5) and mount(8) man pages. + +To force the old behaviour, instead of converting fstab, you can add +rc_want="dev-settle" to /etc/conf.d/localmount or add udev-settle to the +sysinit runlevel. diff --git a/metadata/news/2016-12-06-ruby-20-removal/2016-12-06-ruby-20-removal.en.txt b/metadata/news/2016-12-06-ruby-20-removal/2016-12-06-ruby-20-removal.en.txt new file mode 100644 index 000000000000..c6bc2cf7fb44 --- /dev/null +++ b/metadata/news/2016-12-06-ruby-20-removal/2016-12-06-ruby-20-removal.en.txt @@ -0,0 +1,27 @@ +Title: Ruby 2.0 removal; Ruby 2.1 default +Author: Hans de Graaff <graaff@gentoo.org> +Content-Type: text/plain +Posted: 2016-12-04 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <dev-lang/ruby-2.1 + +Ruby MRI (Matz's Ruby Interpreter) 2.0 was retired by upstream in +February 2016. [1] Following this, Ruby MRI 2.0 support will be +removed from Gentoo. We recommend updating to the 'ruby21' target as +soon as possible if you are still using 'ruby20'. + +Check the current setting via: + + eselect ruby show + +Change the current setting to Ruby MRI 2.1 via: + + eselect ruby set ruby21 + +Packages can be reinstalled for ruby21 only by using the -N option of +emerge: + + emerge -uvDNq world + +[1] https://www.ruby-lang.org/en/news/2016/02/24/support-plan-of-ruby-2-0-0-and-2-1/ diff --git a/metadata/news/2017-01-15-kde-plasma-4-removal/2017-01-15-kde-plasma-4-removal.en.txt b/metadata/news/2017-01-15-kde-plasma-4-removal/2017-01-15-kde-plasma-4-removal.en.txt new file mode 100644 index 000000000000..d07bca7b7f4e --- /dev/null +++ b/metadata/news/2017-01-15-kde-plasma-4-removal/2017-01-15-kde-plasma-4-removal.en.txt @@ -0,0 +1,50 @@ +Title: KDE Plasma 4 and KDE profile removal +Author: Andreas Sturmlechner <asturm@gentoo.org> +Content-Type: text/plain +Posted: 2017-01-08 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: kde-plasma/kdebase-startkde +Display-If-Installed: kde-plasma/kdm +Display-If-Profile: default/linux/alpha/13.0/desktop/kde +Display-If-Profile: default/linux/alpha/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/amd64/13.0/desktop/kde +Display-If-Profile: default/linux/amd64/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/arm/13.0/desktop/kde +Display-If-Profile: default/linux/arm/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/arm/13.0/armv4/desktop/kde +Display-If-Profile: default/linux/arm/13.0/armv4t/desktop/kde +Display-If-Profile: default/linux/arm/13.0/armv5te/desktop/kde +Display-If-Profile: default/linux/arm/13.0/armv6j/desktop/kde +Display-If-Profile: default/linux/arm/13.0/armv7a/desktop/kde +Display-If-Profile: default/linux/ia64/13.0/desktop/kde +Display-If-Profile: default/linux/ia64/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/m68k/13.0/desktop/kde +Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop/kde +Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde/systemd +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/kde +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/kde/systemd +Display-If-Profile: default/linux/sh/13.0/desktop/kde +Display-If-Profile: default/linux/sparc/13.0/desktop/kde +Display-If-Profile: default/linux/sparc/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/x86/13.0/desktop/kde +Display-If-Profile: default/linux/x86/13.0/desktop/kde/systemd + +KDE Plasma 4 has reached end of life in Portage. Upstream dropped support +in 2015-08-19, no security bugs have been fixed since then. It is therefore +required for all users to upgrade to KDE Plasma 5. + +KDM is being removed as well. Upstream recommends x11-misc/sddm instead which +is pulled in by plasma-meta by default. +OpenRC users edit /etc/conf.d/xdm and update DISPLAYMANAGER. +Systemd users run: systemctl reenable sddm.service + +Part of the cleanup will also be the KDE desktop profile, which is superseded +by the Plasma desktop profile. Please follow the detailed upgrade guide.[1] + +KDE Plasma 4.11 packages will be moved to kde-sunset overlay.[2] + +[1] https://wiki.gentoo.org/wiki/KDE/Plasma_5_upgrade +[2] https://wiki.gentoo.org/wiki/Overlay:Kde-sunset diff --git a/metadata/news/2017-01-21-python-exec-2-3-reclaims-python-symlinks/2017-01-21-python-exec-2-3-reclaims-python-symlinks.en.txt b/metadata/news/2017-01-21-python-exec-2-3-reclaims-python-symlinks/2017-01-21-python-exec-2-3-reclaims-python-symlinks.en.txt new file mode 100644 index 000000000000..4aa341514ac4 --- /dev/null +++ b/metadata/news/2017-01-21-python-exec-2-3-reclaims-python-symlinks/2017-01-21-python-exec-2-3-reclaims-python-symlinks.en.txt @@ -0,0 +1,40 @@ +Title: python-exec 2.3 reclaims python* symlinks +Author: Michał Górny <mgorny@gentoo.org> +Content-Type: text/plain +Posted: 2017-01-21 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <app-eselect/eselect-python-20160206 +Display-If-Installed: <dev-lang/python-exec-2.3 + +The new versions of python-exec (2.3 and newer) are reclaiming multiple +Python-related symlinks in /usr/bin, most notably /usr/bin/python*. This +may result in your package manager reporting file collisions. + +The respective symlinks were previously either unowned and created +dynamically by app-eselect/eselect-python, or installed by it. From now +on, all Python-related symlinks are installed and handled +by python-exec. This ensures that they respect the python-exec +configuration files and variables consistently with regular Python +packages, and improves their reliability. + +If you are using FEATURES=collision-protect, Portage will reject +the upgrade. If this is the case, please temporarily switch to +FEATURES=protect-owned for the upgrade. + +If you are using FEATURES=protect-owned, Portage will verbosely warn +about the file collisions but will proceed with the upgrade once +determining no replaced files are owned. Please disregard the warning. + +The potentially colliding files are: + + * /usr/bin/2to3 + * /usr/bin/idle + * /usr/bin/pydoc + * /usr/bin/python + * /usr/bin/python2 + * /usr/bin/python3 + * /usr/bin/python-config + +For more information on python-exec, please see: +https://wiki.gentoo.org/wiki/Project:Python/python-exec diff --git a/metadata/news/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22.en.txt b/metadata/news/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22.en.txt new file mode 100644 index 000000000000..b413ce40a58b --- /dev/null +++ b/metadata/news/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22.en.txt @@ -0,0 +1,77 @@ +Title: Upgrade to =sys-libs/uclibc-ng-1.0.22 +Author: Anthony G. Basile <blueness@gentoo.org> +Content-Type: text/plain +Posted: 2017-02-10 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: sys-libs/uclibc-ng +Display-If-Profile: default/linux/uclibc/amd64 +Display-If-Profile: hardened/linux/uclibc/amd64 +Display-If-Profile: default/linux/uclibc/arm/armv7a +Display-If-Profile: hardened/linux/uclibc/arm/armv7a +Display-If-Profile: default/linux/uclibc/mips +Display-If-Profile: hardened/linux/uclibc/mips +Display-If-Profile: default/linux/uclibc/mips/mipsel +Display-If-Profile: hardened/linux/uclibc/mips/mipsel +Display-If-Profile: default/linux/uclibc/ppc +Display-If-Profile: hardened/linux/uclibc/ppc +Display-If-Profile: default/linux/uclibc/x86 +Display-If-Profile: hardened/linux/uclibc/x86 + +There have been two major changes in uclibc-ng which need special +attention when upgrading. Version 1.0.19 restructured the breakout +libraries, libcrypt.so.0, libdl.so.0, and friends. The functions in +those libraries are now included in libuClibc-0.1.0.19.so. Version +1.0.21 and above removed libc support for obstack, expecting packages to +use their bundled GNU lib code. Both changes require special upgrade +procedures which we outline below: + +0. Because of changes in the library structure in previous versions, +make sure you are working with 1.0.19 and rebuild world using + + emerge -e @world + +This will make sure all the executables link directly against libc.so.0 +(as reported by `readelf -d`) rather than via symlinks like libdl.so.0 +-> libc.so.0. Then upgrade from 1.0.19 to 1.0.20 without symlink-compat: + + USE="-symlink-compat" emerge =sys-libs/uclibc-ng-1.0.20 + +1. Get rid of the obstack.h header since it's used by configure scripts +to look for function prototypes and macros. + + mv /usr/include/obstack.h ~ + +2. We also need to force the use of any bundled gnu lib code. We can do +this by removing the definition of _GNU_OBSTACK_INTERFACE_VERSION from +gnu-version.h + + cp /usr/include/gnu-versions.h ~ + sed -i -e '/#define _GNU_OBSTACK/d' /usr/include/gnu-versions.h + +3. We need to tell stdio.h that __UCLIBC_HAS_OBSTACK__ is false. We do +this via the uClibc_config.h file. + + cp /usr/include/bits/uClibc_config.h ~ + sed -i -e '/__UCLIBC_HAS_OBSTACK__/ s/1/0/' \ + /usr/include/bits/uClibc_config.h + +4. To be safe, you may want to back up your entire /lib directory so +you can fall back should something go wrong: + + cp -a /lib /lib.bak + +5. Now when we rebuild @world, all packages will use their bundled +obstack code rather than depending on libc to provide it. + + ac_cv_func_obstack_vprintf=no emerge --keep-going --exclude \ + sys-libs/uclibc-ng -e @world + +6. Finally update uclibc-ng to the latest + + emerge =sys-libs/uclibc-ng-1.0.22 + +7. For good measure, rebuild the entire system + + emerge —e @world + diff --git a/metadata/news/2017-03-02-exim-chunking-bug/2017-03-02-exim-chunking-bug.en.txt b/metadata/news/2017-03-02-exim-chunking-bug/2017-03-02-exim-chunking-bug.en.txt new file mode 100644 index 000000000000..7212f5861d91 --- /dev/null +++ b/metadata/news/2017-03-02-exim-chunking-bug/2017-03-02-exim-chunking-bug.en.txt @@ -0,0 +1,28 @@ +Title: =mail-mta/exim-4.88 problem with chunking +Author: Fabian Groffen <grobian@gentoo.org> +Content-Type: text/plain +Posted: 2017-03-01 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: =mail-mta/exim-4.88 + +Exim maintainers discovered that version 4.88 has some serious problems +with its CHUNKING extension. To quote: + + There are various known problems which can result in messages stuck in + queues and remote servers dropping connections on larger mails. + +In Gentoo, Exim 4.88 is the only stable version available, hence all +Exim users are advised to either upgrade to an unstable 4.89 release +candidate, or patch the configuration as follows: + +1) in the main configuration section, add: + + chunking_advertise_hosts = + +2) for each SMTP transport, add: + + hosts_try_chunking = + +Please see also the announcement sent to exim-announce: +https://lists.exim.org/lurker/message/20170301.031117.ff024aa8.en.html diff --git a/metadata/news/2017-04-10-split-and-slotted-wine/2017-04-10-split-and-slotted-wine.en.txt b/metadata/news/2017-04-10-split-and-slotted-wine/2017-04-10-split-and-slotted-wine.en.txt new file mode 100644 index 000000000000..da288f518798 --- /dev/null +++ b/metadata/news/2017-04-10-split-and-slotted-wine/2017-04-10-split-and-slotted-wine.en.txt @@ -0,0 +1,52 @@ +Title: app-emulation/wine split and slotting +Author: NP-Hardass <NP-Hardass@gentoo.org> +Content-Type: text/plain +Posted: 2017-04-10 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: app-emulation/wine:0 + +Starting with Wine 2.0, Wine in Gentoo is transitioning away from its +traditional packaging and toward a new, split and slotted, Wine. + +As many Wine users know, there are often regressions or an application +works better on one version of wine than another. Going forward, +packaging in Gentoo will allow simultaneous installation of multiple +versions of Wine. + +Additionally, to expedite vanilla releases as well as permit multiple +configurations for each Wine installation, the major patchsets have +been split out into separate packages. + +Going forward, app-emulation/wine will transition to: +app-emulation/wine-vanilla: upstream Wine with no external patchsets + (like if the old packaging forced USE="-staging -d3d9") +app-emulation/wine-staging: Wine with Wine-Staging's patchset + (like if the old packaging forced USE="+staging -d3d9") +app-emulation/wine-d3d9: Wine with Ixit's Gallium Nine patchset + (like if the old packaging forced USE="-staging +d3d9") +app-emulation/wine-any: Wine with any of the patchsets or flags + (exactly like the old packaging regarding USE flags) + +wine-any exists to allow the user to build any combination that they'd +like (like the old packaging). This means the user could use wine-any +to use both Wine-Staging and Gallium Nine. Alternatively, the user +could use wine-any to try out another configuration from other +packages. For example, the user could build wine-vanilla without +PulseAudio, and could build wine-any with PulseAudio. The sky is the +limit on how a user may choose to use app-emulation/wine-any. + +Users may opt for any specific package, or may emerge virtual/wine, +which is provided for dependency resolution. +Maintainers: Please note, app-emulation/wine will be dropped, so +please use virtual/wine going forward. + +Users may call each version specifically, or may call a symlink based +on their installed patchset, for example wine-2.1, wine-staging-2.2, +or wine-d3d9. + +Symlinks for wine are managed with app-eselect/eselect-wine. +# eselect wine set wine-vanilla-2.0 +/usr/bin/wine -> /usr/bin/wine-vanilla-2.0 +# eselect wine set --staging wine-staging-2.4 +/usr/bin/wine-staging -> /usr/bin/wine-staging-2.4 diff --git a/metadata/news/2017-07-16-systemd-rootprefix/2017-07-16-systemd-rootprefix.en.txt b/metadata/news/2017-07-16-systemd-rootprefix/2017-07-16-systemd-rootprefix.en.txt new file mode 100644 index 000000000000..429eee32de7d --- /dev/null +++ b/metadata/news/2017-07-16-systemd-rootprefix/2017-07-16-systemd-rootprefix.en.txt @@ -0,0 +1,34 @@ +Title: systemd rootprefix migration +Author: Mike Gilbert <floppym@gentoo.org> +Posted: 2017-07-16 +Revision: 4 +News-Item-Format: 2.0 +Display-If-Installed: <sys-apps/systemd-234 + +Starting with the 234 release, Gentoo's sys-apps/systemd package will +be built with rootprefix=/. This means most of the included programs +and system units will be installed under /lib/systemd instead of +/usr/lib/systemd. + +This change brings Gentoo into alignment with most other distros which +still maintain a distinction between boot-critical programs in /, and +less critical programs in /usr. This also means that users with a +separate /usr filesystem will have an easier time booting if their +initramfs should become corrupt or fail. + +Symlinks are provided for /usr/lib/systemd/systemd and +/usr/lib/systemd/systemd-shutdown to avoid breaking bootloader configs +and to allow the system to be shutdown/rebooted without issue. These +symlinks will likely be removed in the 237 release, so please update +your boot configuration to reference init=/lib/systemd/systemd. + +This change will be mostly transparent to typical users. You may notice +that system units move from /usr/lib/systemd/system to +/lib/systemd/system as you upgrade/re-install packages; this is normal. +Units will function properly from both locations. + +After upgrading, please run systemctl daemon-reexec ensure that the new +version is executed. Also make sure to regenerate your initramfs if it +includes a copy of systemd (dracut). + +If you encounter a problem, please report a bug. diff --git a/metadata/news/2017-08-19-hardened-sources-removal/2017-08-19-hardened-sources-removal.en.txt b/metadata/news/2017-08-19-hardened-sources-removal/2017-08-19-hardened-sources-removal.en.txt new file mode 100644 index 000000000000..a2da83e6af43 --- /dev/null +++ b/metadata/news/2017-08-19-hardened-sources-removal/2017-08-19-hardened-sources-removal.en.txt @@ -0,0 +1,54 @@ +Title: sys-kernel/hardened-sources removal +Author: Francisco Blas Izquierdo Riera <klondike@gentoo.org> +Posted: 2017-08-19 +Revision: 10 +News-Item-Format: 2.0 +Display-If-Installed: sys-kernel/hardened-sources + +As you may know the core of sys-kernel/hardened-sources have been the +grsecurity patches. + +Sadly, their developers have stopped making these patches freely +available [1]. This is a full stop of any public updates and not only +stable ones as was announced two years ago[2]. + +As a result, the Gentoo Hardened team is unable to keep providing +further updates of the patches, and although the hardened-sources have +proved (when using a hardened toolchain) being resistant against +certain attacks like the stack guard page jump techniques proposed by +Stack Clash, we can't ensure a regular patching schedule and therefore, +the security of the users of these kernel sources. + +Because of that we will be masking the hardened-sources on the 27th of +August and will proceed to remove them from the tree by the end of +September. Obviously, we will reinstate the package again if the +developers decide to make their patches publicly available again. + +Our recommendation is that users should consider using instead +sys-kernel/gentoo-sources. + +As an alternative, for users happy keeping themselves on the stable +4.9 branch of the kernel; minipli, another grsecurity user, is forward +porting the patches on [3]. + +Strcat from Copperhead OS is making his own version with some +additional hardening features over those on the latest version of the +Linux tree at [4]. + +The Gentoo Hardened team can't make any statement regarding the +security, reliability or update availability of either of those +patches as we aren't providing them and can't therefore make any +recommendation regarding their use. + +We'd like to note that all the userspace hardening and MAC support for +SELinux provided by Gentoo Hardened will still remain in the packages +found in the Gentoo repository. Keep in mind, though, that the +security provided by these features will be weakened a bit when using +sys-kernel/gentoo-sources. Also, all PaX related packages, except +sys-kernel/hardened-sources, will remain available for the time being. + +[1] https://grsecurity.net/passing_the_baton.php +[2] https://www.gentoo.org/support/news-items/2015-10-21-future- +support-of-hardened-sources-kernel.html +[3] https://github.com/minipli/linux-unofficial_grsec +[4] https://github.com/copperhead/linux-hardened diff --git a/metadata/news/2017-10-04-gentoolkit-dev-deprecation/2017-10-04-gentoolkit-dev-deprecation.en.txt b/metadata/news/2017-10-04-gentoolkit-dev-deprecation/2017-10-04-gentoolkit-dev-deprecation.en.txt new file mode 100644 index 000000000000..43f1a28cbe8e --- /dev/null +++ b/metadata/news/2017-10-04-gentoolkit-dev-deprecation/2017-10-04-gentoolkit-dev-deprecation.en.txt @@ -0,0 +1,22 @@ +Title: app-portage/gentoolkit-dev deprecation and removal +Author: Paul Varner <fuzzyray@gentoo.org> +Posted: 2017-09-19 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: app-portage/gentoolkit-dev + +The app-portage/gentoolkit-dev package has been deprecated and the ebump, +ekeyword and imlate have been moved to the app-portage/gentoolkit-0.4.0 +package. With the upcoming marking of >=app-portage/gentoolkit-0.4.0 stable, +users will need to take action since gentoolkit-dev and those versions of +gentoolkit block each other. + +In order to upgrade to the new version of gentoolkit, you will need to resolve +the blocks. The following command will remove gentoolkit-dev from your world +set and uninstall gentoolkit-dev. This will then allow the installation of +>=app-portage/gentoolkit-0.4.0. + +emerge --depclean app-portage/gentoolkit-dev + +Once >=app-portage/gentoolkit-0.4.0 is stabilized, the remaining gentoolkit-dev +releases will be masked for removal and subsequent tree-cleaning. diff --git a/metadata/news/2017-10-10-perl-5_26-update/2017-10-10-perl-5_26-update.en.txt b/metadata/news/2017-10-10-perl-5_26-update/2017-10-10-perl-5_26-update.en.txt new file mode 100644 index 000000000000..c6277c52ea16 --- /dev/null +++ b/metadata/news/2017-10-10-perl-5_26-update/2017-10-10-perl-5_26-update.en.txt @@ -0,0 +1,32 @@ +Title: Perl 5.26 update: possible breakage +Author: Andreas K. Hüttel <dilfridge@gentoo.org> +Posted: 2017-10-10 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: >=dev-lang/perl-5.26.0 + +You have just upgraded to Perl 5.26. This release brings several +incompatible changes, as a result of deprecations coming to term +and of changes in default settings to mitigate a potential +security issue [1]. + +While we have made sure that all resulting build failures within +Gentoo are fixed, this may not be the case for runtime issues, +and certainly can affect third-party code (e.g., "hand-installed" +server applications). + +Typical errors are: +* Can't locate inc/... in @INC (you may need to install the inc::... module) +* error: ... has no member named ‘op_sibling’ +* Unescaped left brace in regex is illegal in ... + +Please see the pages [2,3] for details and report bugs if you run +into problems during or after the Perl update. + +General purpose advice on updating Perl can be found on page [4]. + +[1] https://rt.perl.org/Ticket/Display.html?id=127834 + https://bugs.gentoo.org/show_bug.cgi?id=589680 +[2] https://wiki.gentoo.org/wiki/Project:Perl/Dot-In-INC-Removal +[3] https://wiki.gentoo.org/wiki/Project:Perl/5.26_Known_Issues +[4] https://wiki.gentoo.org/wiki/Perl diff --git a/metadata/news/2017-10-13-openrc-service-binary-removal/2017-10-13-openrc-service-binary-removal.en.txt b/metadata/news/2017-10-13-openrc-service-binary-removal/2017-10-13-openrc-service-binary-removal.en.txt new file mode 100644 index 000000000000..9b3734300140 --- /dev/null +++ b/metadata/news/2017-10-13-openrc-service-binary-removal/2017-10-13-openrc-service-binary-removal.en.txt @@ -0,0 +1,14 @@ +Title: OpenRC "service" binary removal +Author: William Hubbs <williamh@gentoo.org> +Display-If-Installed: <=sys-apps/openrc-0.33 +Content-Type: text/plain +Posted: 2017-10-13 +Revision: 1 +News-Item-Format: 1.0 + +OpenRC 0.33 will remove the "service" binary, which was just a copy of +the "rc-service" binary. + +If you only use rc-service this will not affect you. However, if you +still need the "service" command, you should install +sys-apps/init-system-helpers. diff --git a/metadata/news/2017-11-21-old-wine-versions-moving-to-overlay/2017-11-21-old-wine-versions-moving-to-overlay.en.txt b/metadata/news/2017-11-21-old-wine-versions-moving-to-overlay/2017-11-21-old-wine-versions-moving-to-overlay.en.txt new file mode 100644 index 000000000000..ff28b96e6059 --- /dev/null +++ b/metadata/news/2017-11-21-old-wine-versions-moving-to-overlay/2017-11-21-old-wine-versions-moving-to-overlay.en.txt @@ -0,0 +1,37 @@ +Title: Old Wine versions moving to wine-overlay +Author: NP-Hardass <NP-Hardass@gentoo.org> +Posted: 2017-11-21 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: app-emulation/wine:0 +Display-If-Installed: app-emulation/wine-vanilla +Display-If-Installed: app-emulation/wine-staging +Display-If-Installed: app-emulation/wine-d3d9 +Display-If-Installed: app-emulation/wine-any + +To reduce the burden on main Gentoo repository, older versions of Wine +will be available only in the wine overlay. These ebuilds will still be +fully supported by the Gentoo Wine Project. This will result in +upstream stable releases and the several most recent upstream devel +releases being the only versions in ::gentoo; all versions meeting the +criteria for support within Gentoo [1] will be available in ::wine. + +To install the overlay you can either add the repos.conf file to your +portage configuration directory, add the repository via layman, or add the +repository via eselect-repository. + +* To add the repos.conf file: +# wget https://dev.gentoo.org/~np-hardass/proj/wine/wine.conf -O \ + /etc/portage/repos.conf/wine.conf + +Edit the /etc/portage/repos.conf/wine.conf file so that "location" +points to your desired folder to install the overlay. +# emaint sync --repo wine + +* To install the overlay via layman: +# layman -a wine + +* To install the overlay via eselect-repository: +# eselect repository enable wine + +[1] https://wiki.gentoo.org/wiki/Project:Wine/Policies_and_Procedures#Supported_versions diff --git a/metadata/news/2017-11-22-games-destable/2017-11-22-games-destable.en.txt b/metadata/news/2017-11-22-games-destable/2017-11-22-games-destable.en.txt new file mode 100644 index 000000000000..5c1981c34c53 --- /dev/null +++ b/metadata/news/2017-11-22-games-destable/2017-11-22-games-destable.en.txt @@ -0,0 +1,26 @@ +Title: No stable KEYWORDS for Gentoo Games +Author: David Seifert <soap@gentoo.org> +Content-Type: text/plain +Posted: 2017-11-22 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Keyword: amd64 x86 + +As the Games team does not have enough manpower to keep tabs on all +games packages, we have dropped all ebuilds maintained by the games +project to unstable KEYWORDS (without those required by other stable +packages). If you have any of these stable games packages installed, +you will have to add them to /etc/portage/package.accept_keywords/ +manually. Failures related to missing stable KEYWORDS will show up as + + 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) + =games-action/0verkill-0.16-r4 ~amd64 + +While we accept that this will cause some irritation for the community, +pretending we have a well supported games collection by having a +wealth of stable games packages is misleading at best. We welcome +contributions from outsiders willing to polish up the games landscape +in Gentoo via the Proxy Maintainers Project. diff --git a/metadata/news/2017-11-30-new-17-profiles/2017-11-30-new-17-profiles.en.txt b/metadata/news/2017-11-30-new-17-profiles/2017-11-30-new-17-profiles.en.txt new file mode 100644 index 000000000000..f66cd54c9e64 --- /dev/null +++ b/metadata/news/2017-11-30-new-17-profiles/2017-11-30-new-17-profiles.en.txt @@ -0,0 +1,89 @@ +Title: New 17.0 profiles in the Gentoo repository +Author: Andreas K. Hüttel <dilfridge@gentoo.org> +Posted: 2017-11-30 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Profile: default/linux/amd64/13.0 +Display-If-Profile: default/linux/amd64/13.0/selinux +Display-If-Profile: default/linux/amd64/13.0/desktop +Display-If-Profile: default/linux/amd64/13.0/desktop/gnome +Display-If-Profile: default/linux/amd64/13.0/desktop/gnome/systemd +Display-If-Profile: default/linux/amd64/13.0/desktop/plasma +Display-If-Profile: default/linux/amd64/13.0/desktop/plasma/systemd +Display-If-Profile: default/linux/amd64/13.0/developer +Display-If-Profile: default/linux/amd64/13.0/no-multilib +Display-If-Profile: default/linux/amd64/13.0/systemd +Display-If-Profile: default/linux/ia64/13.0 +Display-If-Profile: default/linux/ia64/13.0/desktop +Display-If-Profile: default/linux/ia64/13.0/desktop/gnome +Display-If-Profile: default/linux/ia64/13.0/desktop/gnome/systemd +Display-If-Profile: default/linux/ia64/13.0/developer +Display-If-Profile: default/linux/powerpc/ppc32/13.0 +Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop +Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop/gnome +Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop/gnome/systemd +Display-If-Profile: default/linux/powerpc/ppc32/13.0/developer +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/desktop +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/gnome +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/gnome/systemd +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/developer +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/desktop +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/gnome +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/gnome/systemd +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/developer +Display-If-Profile: default/linux/x86/13.0 +Display-If-Profile: default/linux/x86/13.0/selinux +Display-If-Profile: default/linux/x86/13.0/desktop +Display-If-Profile: default/linux/x86/13.0/desktop/gnome +Display-If-Profile: default/linux/x86/13.0/desktop/gnome/systemd +Display-If-Profile: default/linux/x86/13.0/desktop/plasma +Display-If-Profile: default/linux/x86/13.0/desktop/plasma/systemd +Display-If-Profile: default/linux/x86/13.0/developer +Display-If-Profile: default/linux/x86/13.0/no-multilib +Display-If-Profile: default/linux/x86/13.0/systemd + +We have just added (for all arches except arm and mips, these follow +later) a new set of profiles with release version 17.0 to the Gentoo +repository. These bring three changes: +1) The default C++ language version for applications is now C++14. + This change is mostly relevant to Gentoo developers. It also + means, however, that compilers earlier than GCC 6 are masked + and not supported for use as a system compiler anymore. Feel + free to unmask them if you need them for specific applications. +2) Where supported, GCC will now build position-independent + executables (PIE) by default. This improves the overall + security fingerprint. The switch from non-PIE to PIE binaries, + however, requires some steps by users, as detailed below. +3) Up to now, hardened profiles were separate from the default + profile tree. Now they are moving into the 17.0 profile + as a feature there, similar to "no-multilib" and "systemd". + +Please migrate away from the 13.0 profiles within the six weeks after +GCC 6.4.0 has been stabilized on your architecture. The 13.0 profiles +will be deprecated then and removed in half a year. + +If you are not already running a hardened setup with PIE enabled, then +switching the profile involves the following steps: +If not already done, +* Use gcc-config to select gcc-6.4.0 or later as system compiler +* Re-source /etc/profile: + . /etc/profile +* Re-emerge libtool + emerge -1 sys-devel/libtool +Then, +* Select the new profile with eselect +* Re-emerge, in this sequence, gcc, binutils, and glibc + emerge -1 sys-devel/gcc:6.4.0 + emerge -1 sys-devel/binutils + emerge -1 sys-libs/glibc +* Rebuild your entire system + emerge -e @world + +Switching the profile from 13.0 to 17.0 modifies the settings of +GCC 6 to generate PIE executables by default; thus, you need to do +the rebuilds even if you have already used GCC 6 beforehand. +If you do not follow these steps you may get spurious build +failures when the linker tries unsuccessfully to combine non-PIE +and PIE code. diff --git a/metadata/news/2017-12-26-experimental-amd64-17-1-profiles/2017-12-26-experimental-amd64-17-1-profiles.en.txt b/metadata/news/2017-12-26-experimental-amd64-17-1-profiles/2017-12-26-experimental-amd64-17-1-profiles.en.txt new file mode 100644 index 000000000000..44187995cbbe --- /dev/null +++ b/metadata/news/2017-12-26-experimental-amd64-17-1-profiles/2017-12-26-experimental-amd64-17-1-profiles.en.txt @@ -0,0 +1,106 @@ +Title: Experimental amd64 17.1 profiles up for testing +Author: Michał Górny <mgorny@gentoo.org> +Posted: 2017-12-26 +Revision: 3 +News-Item-Format: 2.0 +Display-If-Profile: default/linux/amd64/13.0 +Display-If-Profile: default/linux/amd64/13.0/selinux +Display-If-Profile: default/linux/amd64/13.0/desktop +Display-If-Profile: default/linux/amd64/13.0/desktop/gnome +Display-If-Profile: default/linux/amd64/13.0/desktop/gnome/systemd +Display-If-Profile: default/linux/amd64/13.0/desktop/plasma +Display-If-Profile: default/linux/amd64/13.0/desktop/plasma/systemd +Display-If-Profile: default/linux/amd64/13.0/developer +Display-If-Profile: default/linux/amd64/13.0/no-multilib +Display-If-Profile: default/linux/amd64/13.0/systemd +Display-If-Profile: default/linux/amd64/17.0 +Display-If-Profile: default/linux/amd64/17.0/selinux +Display-If-Profile: default/linux/amd64/17.0/hardened +Display-If-Profile: default/linux/amd64/17.0/hardened/selinux +Display-If-Profile: default/linux/amd64/17.0/desktop +Display-If-Profile: default/linux/amd64/17.0/desktop/gnome +Display-If-Profile: default/linux/amd64/17.0/desktop/gnome/systemd +Display-If-Profile: default/linux/amd64/17.0/desktop/plasma +Display-If-Profile: default/linux/amd64/17.0/desktop/plasma/systemd +Display-If-Profile: default/linux/amd64/17.0/developer +Display-If-Profile: default/linux/amd64/17.0/no-multilib +Display-If-Profile: default/linux/amd64/17.0/no-multilib/hardened +Display-If-Profile: default/linux/amd64/17.0/no-multilib/hardened/selinux +Display-If-Profile: default/linux/amd64/17.0/systemd + +A new set of 17.1 amd64 profiles has been added to the Gentoo +repository. Those profiles switch to a more standard 'no SYMLINK_LIB' +multilib layout, and require explicit migration as described below. They +are considered experimental at the moment, and have a fair risk +of breaking your system. We would therefore like to ask our users to +test them on their non-production ~amd64 systems. + +In those profiles, the lib->lib64 compatibility symlink is removed. +The 'lib' directory becomes a separate directory, that is used +for cross-arch and native non-library packages (gcc, clang) and 32-bit +libraries on the multilib profile (for better compatibility with +prebuilt x86 packages). + +Migration from both 13.0 and 17.0 profiles is supported. In case +of the former, please read the news item for 17.0 upgrade first +and enable gcc 6.4.0 or newer first as explained there. + +The migration is performed using app-portage/unsymlink-lib tool. +The following steps can be used to upgrade your system: + +1. Sync and upgrade your system to the newest package versions + to reduce the risk of issues. + +2. Install the tool, e.g. via 'emerge -1v app-portage/unsymlink-lib' + +3. Run 'unsymlink-lib --analyze' and check the output for obvious + mistakes. If you need to perform any changes to the system, remember + to run 'unsymlink-lib --analyze' again afterwards. + +[past this point do not call emerge or modify /usr manually] + +4. This is a very good time to make a backup. + +5. Run 'unsymlink-lib --migrate'. You can add '--pretend' first to see + what is going to happen. + +6. Reboot your system and see if it still boots. Check if important + programs work. In particular, check if e.g. 'emerge --info' works + (but do not install anything). If you hit any serious problems, + you can use 'unsymlink-lib --rollback' to revert the changes + and return to step 3. + +7. Run 'unsymlink-lib --finish'. You can add '--pretend' first to see + what is going to happen but note that you're going to see a very long + list of files to remove. + +8. Switch the profile, e.g.: + + eselect profile set --force default/linux/amd64/17.1/desktop + +[at this point you can start using emerge again] + +9. Rebuild sys-devel/gcc. If you are switching from 13.0 profiles, + rebuild sys-devel/binutils and sys-libs/glibc afterwards. + +10. If you are using a multilib profile, rebuild all 32-bit packages. + This can be done using: + + emerge -1v /lib32 /usr/lib32 + + Alternatively, if you are switching from one of the 13.0 profiles + you can rebuild all packages as detailed in the 17.0 news item. + +11. Once the last 32-bit package is rebuilt, your package manager + should remove the orphaned /lib32 and /usr/lib32 symlinks. If that + does not happen, remove them manually. + +For known issues, please see bug #506276 [1]. If you have any problems +with the new profiles or the migration procedure, please report a bug +and make it block the tracker. + +For more information on the layout, please see the wiki article +on AMD64 multilib layouts [2]. + +[1]:https://bugs.gentoo.org/506276 +[2]:https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout diff --git a/metadata/news/2018-01-14-gnucash/2018-01-14-gnucash.en.txt b/metadata/news/2018-01-14-gnucash/2018-01-14-gnucash.en.txt new file mode 100644 index 000000000000..334c1c078335 --- /dev/null +++ b/metadata/news/2018-01-14-gnucash/2018-01-14-gnucash.en.txt @@ -0,0 +1,31 @@ +Title: GnuCash 2.7+ Breaking Change +Author: Aaron W. Swenson <titanofold@gentoo.org> +Posted: 2018-01-14 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: <app-office/gnucash-4 + +Along with changes to use modern libraries, GnuCash 2.7+ has changed the +schema [1] it uses for both databases and files. GnuCash will +automatically modify the file or database in place upon open. + +Therefore, it is imperative that you back up any files or databases +before using GnuCash 2.7 in case you run into an issue and want or need +to revert back to 2.6. + +Close any open session of GnuCash including remote sessions, then +follow the relevant backup instructions as follows: + +For XML (plain files): +$ cp /path/to/file.gnucash /path/to/file.gnucash.bak + +For MySQL: +$ mysqldump gnucash_db | xz > gnucash-2.6.sql.xz + +For PostgreSQL: +$ pg_dump -U gnucash_user -Z 5 gnucash_db > gnucash-2.6.sql.gz + +For SQLite: +$ cp /path/to/sqlite.file.gnucash /path/to/sqlite.file.gnucash.bak + +[1] https://github.com/Gnucash/gnucash/releases/tag/2.7.0a diff --git a/metadata/news/2018-01-23-systemd-blocker/2018-01-23-systemd-blocker.en.txt b/metadata/news/2018-01-23-systemd-blocker/2018-01-23-systemd-blocker.en.txt new file mode 100644 index 000000000000..17692d9b6eac --- /dev/null +++ b/metadata/news/2018-01-23-systemd-blocker/2018-01-23-systemd-blocker.en.txt @@ -0,0 +1,46 @@ +Title: systemd sysv-utils blocker resolution +Author: Mike Gilbert <floppym@gentoo.org> +Posted: 2018-01-23 +Revision: 2 +News-Item-Format: 2.0 +Display-If-Installed: <sys-apps/systemd-236-r4 + +Starting with systemd-236, the sysv-utils USE flag is enabled by +default. + +The sysv-utils USE flag controls installation of symlinks for several +key commands: + + /sbin/halt -> ../bin/systemctl + /sbin/init -> ../lib/systemd/systemd + /sbin/reboot -> ../bin/systemctl + /sbin/poweroff -> ../bin/systemctl + /sbin/runlevel -> ../bin/systemctl + /sbin/shutdown -> ../bin/systemctl + /sbin/telinit -> ../bin/systemctl + +These commands are otherwise provided by sys-apps/sysvinit. This package +is blocked by systemd when the sysv-utils USE flag is enabled. + +Enabling sysv-utils should cause Portage to un-merge sysvinit and OpenRC +if they are currently installed. emerge may emit a warning message +before doing so; if you are booting with systemd, this message is safe +to ignore. + +If you wish to keep sysvinit (and openrc) installed, you may disable the +sysv-utils USE flag locally. + +If you run into unresolvable blockers with sysv-utils enabled, ensure +that you do not have any reverse dependencies of sys-apps/sysvinit +selected (in your world file). + +Common packages to look for: + + sys-apps/sysvinit + sys-apps/openrc + net-misc/netifrc + +The equery command from gentoolkit may help track down installed +packages that depend on openrc. + + equery depends sys-apps/openrc diff --git a/metadata/news/2018-01-30-portage-rsync-verification/2018-01-30-portage-rsync-verification.en.txt b/metadata/news/2018-01-30-portage-rsync-verification/2018-01-30-portage-rsync-verification.en.txt new file mode 100644 index 000000000000..1964855e4d1a --- /dev/null +++ b/metadata/news/2018-01-30-portage-rsync-verification/2018-01-30-portage-rsync-verification.en.txt @@ -0,0 +1,50 @@ +Title: Portage rsync tree verification +Author: Michał Górny <mgorny@gentoo.org> +Posted: 2018-01-30 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/portage + +Starting with sys-apps/portage-2.3.21, Portage will verify the Gentoo +repository after rsync by default. + +The new verification is intended for users who are syncing via rsync. +Users syncing via git or other methods are not affected, and complete +verification for them will be provided in the future. + +The verification is implemented via app-portage/gemato. Currently, +the whole repository is verified after syncing. On systems with slow +hard drives, this could take around 2 minutes. If you wish to disable +it, you can disable the 'rsync-verify' USE flag on sys-apps/portage +or set 'sync-rsync-verify-metamanifest = no' in your repos.conf. + +Please note that the verification currently does not prevent Portage +from using the repository after syncing. If 'emerge --sync' fails, +do not install any packages and retry syncing. In case of prolonged +or frequent verification failures, please make sure to report a bug +including the failing mirror addresses (found in emerge.log). + +The verification uses information from the binary keyring provided +by the app-crypt/gentoo-keys package. The keys are refreshed +from the keyserver before every use in order to check for revocation. +The post-sync verification ensures that the authenticity of the key +package itself is verified. However, manual verification is required +before the first use. + +On Gentoo installations created using installation media that included +portage-2.3.22, the keys will already be covered by the installation +media signatures. On existing installations, you need to manually +compare the primary key fingerprint (reported by gemato on every sync) +against the official Gentoo keys [1]. An example gemato output is: + + INFO:root:Valid OpenPGP signature found: + INFO:root:- primary key: 1234567890ABCDEF1234567890ABCDEF12345678 + INFO:root:- subkey: FEDCBA0987654321FEDCBA0987654321FEDCBA09 + +Please note that the above snippet does not include the real key id +on purpose. The primary key actually printed by gemato must match +the 'Gentoo Portage Snapshot Signing Key' on the website. Please make +sure to also check the certificate used for the secure connection +to the site! + +[1]:https://www.gentoo.org/downloads/signatures/ diff --git a/metadata/news/2018-03-13-portage-rsync-verification-unstable/2018-03-13-portage-rsync-verification-unstable.en.txt b/metadata/news/2018-03-13-portage-rsync-verification-unstable/2018-03-13-portage-rsync-verification-unstable.en.txt new file mode 100644 index 000000000000..9f96f2719235 --- /dev/null +++ b/metadata/news/2018-03-13-portage-rsync-verification-unstable/2018-03-13-portage-rsync-verification-unstable.en.txt @@ -0,0 +1,46 @@ +Title: Portage rsync tree verification unstable +Author: Zac Medico <zmedico@gentoo.org> +Posted: 2018-03-13 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/portage + +Portage rsync tree verification is being temporarily turned off by +default, starting with sys-apps/portage-2.3.24. This permits +stabilization of sys-apps/portage-2.3.24 while still working on bugs +relating to tree verification [1]: deadlocks [2] & key fetching [3]. + +If users wish to enable the 'rsync-verify' USE flag for sys-apps/portage, +they need to follow these steps: + +1) In order to unmask the 'rsync-verify' USE flag, create a file named +/etc/portage/profile/package.use.mask containing a line like the +following: + + sys-apps/portage -rsync-verify + +2) Once the 'rsync-verify' USE flag has been unmasked as described +in step 1, it can be enabled with a line like the following in +/etc/portage/package.use: + + sys-apps/portage rsync-verify + +3) After the configuration changes in steps 1 and 2 have been made, run +the following command: + + emerge --oneshot --newuse '>=sys-apps/portage-2.3.24' + +After all above steps are successfully completed, a line like the +following should appear in the emerge --info output for the gentoo +repository: + + sync-rsync-verify-metamanifest: yes + +If you wish to disable it for some reason, you can set +'sync-rsync-verify-metamanifest = no' in your repos.conf. + +[1] https://bugs.gentoo.org/650144 sys-apps/portage: [TRACKER] issues + related to 'rsync-verify' USE flag +[2] https://bugs.gentoo.org/647964 app-portage/gemato-11.2: deadlock? +[3] https://bugs.gentoo.org/649276 sys-apps/portage: gpg key refresh + needs exponential backoff with jitter diff --git a/metadata/news/2018-04-08-radicale-2-requires-pre-install-migration/2018-04-08-radicale-2-requires-pre-install-migration.en.txt b/metadata/news/2018-04-08-radicale-2-requires-pre-install-migration/2018-04-08-radicale-2-requires-pre-install-migration.en.txt new file mode 100644 index 000000000000..8783ee846bb2 --- /dev/null +++ b/metadata/news/2018-04-08-radicale-2-requires-pre-install-migration/2018-04-08-radicale-2-requires-pre-install-migration.en.txt @@ -0,0 +1,26 @@ +Title: Radicale 2 requires pre-install migration +Author: Christopher Head <chead@chead.ca> +Posted: 2018-04-02 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: <www-apps/radicale-2 + +Radicale version 2 uses a new storage format and is not able to read +databases created by version 1. Version 1 releases starting from 1.1.3 +include a --export-storage option which can be used to export their +databases in a format that Radicale 2 can use; you must do this before +upgrading to version 2. + +If you have kept the Gentoo-default database configuration, this will +work: +1. Stop any running instance of Radicale. +2. Run `radicale --export-storage ~/radicale-exported`. +3. Run `chown -R radicale: ~/radicale-exported` +4. Run `mv /var/lib/radicale /var/lib/radicale.old`. +5. Install Radicale version 2. +6. Run `mv ~/radicale-exported /var/lib/radicale/collections`. + +For more details, or if you are have a more complex configuration, +please see the migration guide: http://radicale.org/1to2/ +If you do a custom migration, please ensure the database is cleaned out +of /var/lib/radicale, including the hidden .props file. diff --git a/metadata/news/2018-05-22-python3-6/2018-05-22-python3-6.en.txt b/metadata/news/2018-05-22-python3-6/2018-05-22-python3-6.en.txt new file mode 100644 index 000000000000..c8901e970a7f --- /dev/null +++ b/metadata/news/2018-05-22-python3-6/2018-05-22-python3-6.en.txt @@ -0,0 +1,61 @@ +Title: Python 3.6 to become the default target +Author: Michał Górny <mgorny@gentoo.org> +Posted: 2018-05-22 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-lang/python:3.4 +Display-If-Installed: dev-lang/python:3.5 + +On 2018-06-22, Python 3.6 will replace Python 3.5 in the default Python +targets for Gentoo systems. The new default targets will be: + + PYTHON_TARGETS="python2_7 python3_6" + PYTHON_SINGLE_TARGET="python3_6" + +If you have not overriden the value of those variables on your system, +then your package manager will want to use the new targets immediately. +In order to prevent dependency conflicts, please clean stray packages +and rebuild/upgrade all packages with USE flag changes after the change, +e.g.: + + emerge --depclean + emerge -1vUD @world + emerge --depclean + +Please note that upgrading dependencies in place may cause some +of the package dependencies to be temporarily missing. While this +should not affect scripts that are already fully loaded, it may cause +ImportErrors while starting Python scripts or loading additional +modules (only scripts running Python 3.5 are affected). + +In order to improve stability of the upgrade, you may choose to +temporarily enable both targets, i.e. set in /etc/portage/make.conf +or its equivalent: + + PYTHON_TARGETS="python2_7 python3_5 python3_6" + PYTHON_SINGLE_TARGET="python3_5" + +This will cause the dependencies to include both Python 3.5 and 3.6 +support on the next system upgrade. Once all packages are updated, +you can restart your scripts, remove the custom setting and run another +upgrade to remove support for Python 3.5. + +If you would like to postpone the switch to Python 3.6, you can copy +the current value of PYTHON_TARGETS and/or PYTHON_SINGLE_TARGET +to /etc/portage/make.conf or its equivalent: + + PYTHON_TARGETS="python2_7 python3_5" + PYTHON_SINGLE_TARGET="python3_5" + +If you would like to migrate your systems earlier, you can do the same +with the new value. + +If you are still using Python 3.4, please consider switching to a newer +version as it is reaching its end-of-life. The end-of-life dates +for the currently used versions are: + + Python 3.4 2019-03-16 + Python 2.7 2020-01-01 + Python 3.5 2020-09-13 [1] + +[1]:https://devguide.python.org/#status-of-python-branches |