2014-11-07-udev-upgrade
  Title                     Upgrade to udev >= 217 or eudev >= 2.1
  Author                    Samuli Suominen <ssuominen@gentoo.org>
  Posted                    2014-11-07
  Revision                  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

2015-01-28-cpu_flags_x86-introduction
  Title                     CPU_FLAGS_X86 introduction
  Author                    Michał Górny <mgorny@gentoo.org>
  Posted                    2015-01-28
  Revision                  2

The USE flags corresponding to the instruction sets and other features
specific to the x86 (amd64) architecture are being moved into a separate
USE flag group called CPU_FLAGS_X86.

In order not to lose CPU-specific optimizations, users will be required
to update their make.conf (and package.use) file. For example, if
the following USE flags were present:

  USE="mmx mmxext sse sse2 sse3"

Those flags need to be copied into:

  CPU_FLAGS_X86="mmx mmxext sse sse2 sse3"

Please note that the same CPU_FLAGS_X86 variable is used both on x86
and amd64 systems.

When in doubt, you can consult the flag descriptions using one of
the commonly available tools, e.g. `equery uses` from gentoolkit:

  $ equery uses media-video/ffmpeg

Most of the flag names match /proc/cpuinfo names, with the notable
exception of SSE3 which is called 'pni' in /proc/cpuinfo (please also
do not confuse it with distinct SSSE3).

To help users enable the correct USE flags, we are providing a Python
script that generates the correct value using /proc/cpuinfo. It can be
found in the app-portage/cpuinfo2cpuflags package:

  $ emerge -1v app-portage/cpuinfo2cpuflags
  $ cpuinfo2cpuflags-x86

In order to ensure safe migration and maintain compatibility with
external repositories, it is recommended to preserve the old USE
settings for a period of one year or until no package of interest is
still using them.

2015-02-04-portage-sync-changes
  Title                     New portage plug-in sync system
  Author                    Brian Dolbec <dolsen@gentoo.org>
  Posted                    2015-02-02
  Revision                  1

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

2015-03-28-true-multilib
  Title                     True multilib support on amd64
  Author                    Michał Górny <mgorny@gentoo.org>
  Posted                    2015-03-28
  Revision                  1

Starting on 2015-03-29, we are enabling true multilib support on amd64
and masking the old emul-linux-x86 package sets for removal. This
change provides our users with the opportunity to build 32-bit libraries
from source with all the flexibility given by ebuilds and the security
of using mainline ebuilds, rather than relying on pre-packaged binary
versions of them.

The switch to the new system is likely to require a specific action from
the users of our multilib profiles. Since the new system collides with
the old one, the Package Manager must be able to clearly satisfy all
the dependencies using the new system in order to proceed. This may
require unmerging packages installed from third-party repositories that
have not been updated to support the new system.

In order to enable building necessary 32-bit libraries, users will be
required to enable the abi_x86_32 USE flag on respective packages.
This can be done using /etc/portage/package.use entries alike
the following:

    sys-libs/zlib abi_x86_32

In most of the cases, Portage will be able to deliver correct
suggestions for that when using the --autounmask feature. However, some
users may prefer setting ABI_X86 globally to enable 32-bit libraries
in all packages that support building them. This can be done using
the following package.use entry:

    */* abi_x86_32

In case of issues, blockers especially, users are recommended
to manually uninstall any emul-linux-x86 packages that may have been
installed on their systems. This will aid the Package Manager
in choosing the correct dependency resolution path. If using Portage,
this can be done using the following command:

    $ emerge -C 'app-emulation/emul-linux-x86*'

Note: 32-bit applications may be temporarily broken after this step.
Therefore, it should be followed by a @world upgrade immediately.

2015-06-08-udev-init-scripts-changes
  Title                     udev-init-scripts-29 important changes
  Author                    William Hubbs <williamh@gentoo.org>
  Posted                    2015-06-08
  Revision                  2

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.


2015-07-25-python-targets
  Title                     Python 3.4 enabled by default
  Author                    Mike Gilbert <floppym@gentoo.org>
  Posted                    2015-07-25
  Revision                  1

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

2015-08-13-openssh-weak-keys
  Title                     OpenSSH 7.0 disables ssh-dss keys by default
  Author                    Mike Frysinger <vapier@gentoo.org>
  Posted                    2015-08-13
  Revision                  1

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