Here is the latest news from the Gentoo Portage tree, listed in reverse chronological order.

OpenRC "service" binary removal

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.

Published: 2017-10-13 for <=sys-apps/openrc-0.33

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.

Perl 5.26 update: possible breakage

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

Published: 2017-10-10 for >=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

app-portage/gentoolkit-dev deprecation and removal

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.

Published: 2017-09-19 for 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.

sys-kernel/hardened-sources removal

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

Published: 2017-08-19 for 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

systemd rootprefix migration

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 235 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.

Published: 2017-07-16 for >=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 235 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.

app-emulation/wine split and slotting

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

Published: 2017-04-10 for 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

=mail-mta/exim-4.88 problem with chunking

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

Published: 2017-03-01 for =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

Upgrade to =sys-libs/uclibc-ng-1.0.22

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

Published: 2017-02-10 for sys-libs/uclibc-ng

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

python-exec 2.3 reclaims python* symlinks

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

Published: 2017-01-21 for <app-eselect/eselect-python-20160206

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

KDE Plasma 4 and KDE profile removal

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

Published: 2017-01-08 for kde-plasma/kdebase-startkde

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

Ruby 2.0 removal; Ruby 2.1 default

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/

Published: 2016-12-04 for <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/

Important fstab and localmount update

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.

Published: 2016-11-04 for <=sys-apps/openrc-0.23

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.

LLVM 3.9 with LLVM_TARGETS

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.

Published: 2016-10-25 for <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.

OpenRC 0.22 updates

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.

Published: 2016-09-27 for <=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.

Migration to sys-libs/uclibc-ng

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

Published: 2016-09-26 for sys-libs/uclibc

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

Grub2 multislot default setting is changing

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.

Published: 2016-08-11 for >=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.

OpenAFS no longer needs kernel option DEBUG_RODATA

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

Published: 2016-08-08 for <=net-fs/openafs-kernel-1.6.18.2

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

L10N USE_EXPAND variable replacing LINGUAS

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.

Published: 2016-06-19 for <=net-fs/openafs-kernel-1.6.18.2

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.

LastPass package migration

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.

Published: 2016-05-23 for 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.

Changes in default VIDEO_CARDS

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.

Published: 2016-04-24 for x11-drivers/xf86-video-dummy

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.

KDE Plasma 5 Upgrade

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

Published: 2016-04-02 for 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

Upgrading Apache from 2.2 to 2.4

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

Published: 2016-01-27 for 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

Some dhcpcd hooks are now examples

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.

Published: 2016-01-08 for <=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.

Python ABIFLAGS rebuild needed

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/

Published: 2015-12-16 for =dev-lang/python-3.3.5-r4

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/

GCC 5 Defaults to the New C++11 ABI

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/

Published: 2015-10-22 for >=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/

Future Support of hardened-sources Kernel

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

Published: 2015-10-21 for sys-kernel/hardened-sources

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

OpenRC-0.18 localmount and netmount changes

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.

Published: 2015-10-07 for <=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.

libvirt-1.2.19 init script changes

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

Published: 2015-09-09 for <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

Ruby 1.9 removal; Ruby 2.0/2.1 default

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/

Published: 2015-08-26 for <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/

OpenSSH 7.0 disables ssh-dss keys by default

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

Published: 2015-08-13 for 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

Nepomuk removal

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

Published: 2015-08-11 for 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

Python 3.4 enabled by default

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

Published: 2015-07-25 for dev-db/virtuoso-server

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

udev-init-scripts-29 important changes

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.

Published: 2015-06-08 for <=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.

shorewall is now a single package

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.

Published: 2015-05-01 for net-firewall/shorewall-core

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.

FFmpeg default

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.

Published: 2015-04-16 for media-video/ffmpeg

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.

Apache AddHandler/AddType exploit protection

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

Published: 2015-04-06 for 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

New portage plug-in sync system

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

Published: 2015-02-02 for 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

nfs service changes

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

Published: 2015-02-02 for <=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

ffmpeg/libav conflict management: USE=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.

Published: 2015-02-01 for media-video/ffmpeg

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.

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

Published: 2014-11-25 for >=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

sys-devel/kgcc64 removal on 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.

Published: 2014-11-11 for >=app-shells/bash-completion-2.1-r90

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.

Upgrade to udev >= 217 or 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

Published: 2014-11-07 for <sys-fs/udev-217

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

GCC 4.7 Introduced the New C++11 ABI

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

Published: 2014-10-26 for >=sys-devel/gcc-4.7.0

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

Upgrading to musl 1.1.5

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

Published: 2014-10-22 for 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

MythTV SchedulesDirect Change

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.

Published: 2014-10-20 for <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.

Restructuring of mips profiles

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.

Published: 2014-10-04 for 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.

MySQL 5.5 upgrade procedures

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.

Published: 2014-08-20 for <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.

dhcpcd >= 6.4.2 changes defaults for IPv6

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

Published: 2014-07-17 for <=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

GCC 4.8.3 defaults to -fstack-protector

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

Published: 2014-06-15 for >=sys-devel/gcc-4.8.3

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

UPower loses hibernate / suspend to systemd

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

Published: 2014-06-03 for <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

Ruby 1.8 removal; Ruby 1.9/2.0 default

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/

Published: 2014-03-16 for <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/

Profile EAPI 5 requirement

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.

Published: 2014-03-02 for <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.

Upgrade to >=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

Published: 2014-02-25 for <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

Upgrade to GNOME 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

Published: 2013-11-23 for <gnome-base/gnome-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

python-exec package move

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

Published: 2013-11-07 for 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

alpha, ia64: maintainers may remove stable versions

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

Published: 2013-10-24 for dev-python/python-exec

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

GRUB2 migration

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

Published: 2013-10-14 for <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

Separate /usr on Linux requires initramfs

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

Published: 2013-09-27 for <sys-boot/grub-1

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

m68k, s390, sh are dropping stable keywords

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

Published: 2013-09-22 for <sys-boot/grub-1

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

vanilla-sources stabilization policy

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.

Published: 2013-08-07 for 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.

Printer browsing in net-print/cups-1.6

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.

Published: 2013-06-30 for <=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.

PBXT now unsupported in MySQL/MariaDB

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

Published: 2013-06-01 for dev-db/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

baselayout-1.x deprecation final warning

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

Published: 2013-04-10 for <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

Upgrading udev to version >=200

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

Published: 2013-03-29 for <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

New 13.0 profiles and deprecation of 10.0 profiles

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.

Published: 2013-02-10 for <sys-fs/udev-201

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.

New 13.0 profiles and deprecation of 10.0 profiles

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.

Published: 2013-02-10 for <sys-fs/udev-201

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.

Upgrading to 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.

Published: 2012-07-23 for <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.

The default JPEG implementation

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.

Published: 2012-04-24 for =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.

baselayout-1.x deprecation

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

Published: 2012-02-14 for <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

Bacula-5.2.3 Upgrade

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.

Published: 2011-12-30 for <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.

Stabilization of KDE 4.7.3 including KDEPIM

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

Published: 2011-12-06 for <kde-base/libkdepim-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

Unmasking of and Upgrade to GNOME 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

Published: 2011-11-26 for <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

Upgrade to libpng15

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

Published: 2011-10-15 for <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

Mesa r600 driver now defaults to gallium

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

Published: 2011-08-28 for <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

Baselayout update

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!

Published: 2011-05-01 for <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!

Upgrade to 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

Published: 2011-04-27 for <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

GNUstep packages new layout

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

Published: 2011-04-26 for <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

Pending Removal of Java support on IA64

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.

Published: 2011-02-19 for 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.

Upgrade to GNOME 2.32

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

Published: 2011-02-14 for <gnome-base/gnome-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

Change on CAMERAS in 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.

Published: 2011-02-13 for <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.

Restructuring of Hardened profiles

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.

Published: 2010-11-13 for <media-libs/libgphoto2-2.4.10

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.

Info about GCC on Hardened profiles

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.

Published: 2010-10-27 for <sys-devel/gcc-4.4

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.

Perl 5.12 upgrade procedure

==> 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

Published: 2010-10-22 for <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

Upgrade to GNOME 2.28

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

Published: 2010-04-23 for <gnome-base/gnome-2.28.2

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

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.

Published: 2010-03-25 for =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.

New desktop subprofiles for GNOME and KDE

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)

Published: 2010-03-23 for =dev-lang/python-3.1*

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)

MythTV 0.22 Upgrade Database Corruption

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

Published: 2010-03-01 for <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

Layman storage path changed from version 1.3.0 on

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.

Published: 2010-02-28 for <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.

MySQL 5.1 unmasking and upgrade procedures

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.

Published: 2010-02-21 for <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.

Removal of libGL.la

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.

Published: 2010-01-31 for <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.

Using default-linux profile is now obsolete

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.

Published: 2009-10-22 for <app-admin/eselect-opengl-1.1.1-r2

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.

Upgrade to GNOME 2.26

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

Published: 2009-10-08 for <gnome-base/gnome-2.26.0

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

Migration to X.org Server 1.6 and 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

Published: 2009-10-02 for <x11-base/xorg-server-1.6

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

xorg-x11-7.4 and xorg-server-1.5 kernel support

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

Published: 2009-07-12 for x11-base/xorg-server

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

Migration to X.org 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

Published: 2009-04-06 for <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

Migration from teTeX to TeXLive

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

Published: 2009-04-06 for 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

Migrating to the new sparc multilib profile

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

Published: 2009-01-04 for app-text/tetex

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

Changes for Paludis 0.24

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.

Published: 2007-05-04 for <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.
comments powered by Disqus