2013-09-27-initramfs-required
  Title                     Separate /usr on Linux requires initramfs
  Author                    William Hubbs <williamh@gentoo.org>
  Posted                    2013-09-27
  Revision                  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

2014-06-15-gcc48_ssp
  Title                     GCC 4.8.3 defaults to -fstack-protector
  Author                    Ryan Hill <rhill@gentoo.org>
  Posted                    2014-06-15
  Revision                  2

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

2014-10-26-gcc_4_7_introduced_new_c++11_abi
  Title                     GCC 4.7 Introduced the New C++11 ABI
  Author                    Anthony G. Basile <blueness@gentoo.org>
  Posted                    2014-10-26
  Revision                  1

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

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

2015-10-22-gcc-5-new-c++11-abi
  Title                     GCC 5 Defaults to the New C++11 ABI
  Author                    Mike Frysinger <vapier@gentoo.org>
  Posted                    2015-10-22
  Revision                  2

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/

2016-06-23-l10n-use_expand
  Title                     L10N USE_EXPAND variable replacing LINGUAS
  Author                    Mart Raudsepp <leio@gentoo.org>
  Author                    Ulrich Müller <ulm@gentoo.org>
  Posted                    2016-06-19
  Revision                  1

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.

2017-12-26-experimental-amd64-17-1-profiles
  Title                     Experimental amd64 17.1 profiles up for testing
  Author                    Michał Górny <mgorny@gentoo.org>
  Posted                    2017-12-26
  Revision                  3

A new set of 17.1 amd64 profiles has been added to the Gentoo
repository. Those profiles switch to a more standard 'no SYMLINK_LIB'
multilib layout, and require explicit migration as described below. They
are considered experimental at the moment, and have a fair risk
of breaking your system. We would therefore like to ask our users to
test them on their non-production ~amd64 systems.

In those profiles, the lib->lib64 compatibility symlink is removed.
The 'lib' directory becomes a separate directory, that is used
for cross-arch and native non-library packages (gcc, clang) and 32-bit
libraries on the multilib profile (for better compatibility with
prebuilt x86 packages).

Migration from both 13.0 and 17.0 profiles is supported. In case
of the former, please read the news item for 17.0 upgrade first
and enable gcc 6.4.0 or newer first as explained there.

The migration is performed using app-portage/unsymlink-lib tool.
The following steps can be used to upgrade your system:

1. Sync and upgrade your system to the newest package versions
   to reduce the risk of issues.

2. Install the tool, e.g. via 'emerge -1v app-portage/unsymlink-lib'

3. Run 'unsymlink-lib --analyze' and check the output for obvious
   mistakes. If you need to perform any changes to the system, remember
   to run 'unsymlink-lib --analyze' again afterwards.

[past this point do not call emerge or modify /usr manually]

4. This is a very good time to make a backup.

5. Run 'unsymlink-lib --migrate'. You can add '--pretend' first to see
   what is going to happen.

6. Reboot your system and see if it still boots. Check if important
   programs work. In particular, check if e.g. 'emerge --info' works
   (but do not install anything). If you hit any serious problems,
   you can use 'unsymlink-lib --rollback' to revert the changes
   and return to step 3.

7. Run 'unsymlink-lib --finish'. You can add '--pretend' first to see
   what is going to happen but note that you're going to see a very long
   list of files to remove.

8. Switch the profile, e.g.:

     eselect profile set --force default/linux/amd64/17.1/desktop

[at this point you can start using emerge again]

9. Rebuild sys-devel/gcc. If you are switching from 13.0 profiles,
   rebuild sys-devel/binutils and sys-libs/glibc afterwards.

10. If you are using a multilib profile, rebuild all 32-bit packages.
    This can be done using:

      emerge -1v /lib32 /usr/lib32

    Alternatively, if you are switching from one of the 13.0 profiles
    you can rebuild all packages as detailed in the 17.0 news item.

11. Once the last 32-bit package is rebuilt, your package manager
    should remove the orphaned /lib32 and /usr/lib32 symlinks. If that
    does not happen, remove them manually.

For known issues, please see bug #506276 [1]. If you have any problems
with the new profiles or the migration procedure, please report a bug
and make it block the tracker.

For more information on the layout, please see the wiki article
on AMD64 multilib layouts [2].

[1]:https://bugs.gentoo.org/506276
[2]:https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout

2018-01-30-portage-rsync-verification
  Title                     Portage rsync tree verification
  Author                    Michał Górny <mgorny@gentoo.org>
  Posted                    2018-01-30
  Revision                  1

Starting with sys-apps/portage-2.3.21, Portage will verify the Gentoo
repository after rsync by default.

The new verification is intended for users who are syncing via rsync.
Users syncing via git or other methods are not affected, and complete
verification for them will be provided in the future.

The verification is implemented via app-portage/gemato. Currently,
the whole repository is verified after syncing. On systems with slow
hard drives, this could take around 2 minutes. If you wish to disable
it, you can disable the 'rsync-verify' USE flag on sys-apps/portage
or set 'sync-rsync-verify-metamanifest = no' in your repos.conf.

Please note that the verification currently does not prevent Portage
from using the repository after syncing. If 'emerge --sync' fails,
do not install any packages and retry syncing. In case of prolonged
or frequent verification failures, please make sure to report a bug
including the failing mirror addresses (found in emerge.log).

The verification uses information from the binary keyring provided
by the app-crypt/gentoo-keys package. The keys are refreshed
from the keyserver before every use in order to check for revocation.
The post-sync verification ensures that the authenticity of the key
package itself is verified. However, manual verification is required
before the first use.

On Gentoo installations created using installation media that included
portage-2.3.22, the keys will already be covered by the installation
media signatures. On existing installations, you need to manually
compare the primary key fingerprint (reported by gemato on every sync)
against the official Gentoo keys [1]. An example gemato output is:

  INFO:root:Valid OpenPGP signature found:
  INFO:root:- primary key: 1234567890ABCDEF1234567890ABCDEF12345678
  INFO:root:- subkey: FEDCBA0987654321FEDCBA0987654321FEDCBA09

Please note that the above snippet does not include the real key id
on purpose. The primary key actually printed by gemato must match
the 'Gentoo Portage Snapshot Signing Key' on the website. Please make
sure to also check the certificate used for the secure connection
to the site!

[1]:https://www.gentoo.org/downloads/signatures/

2018-03-13-portage-rsync-verification-unstable
  Title                     Portage rsync tree verification unstable
  Author                    Zac Medico <zmedico@gentoo.org>
  Posted                    2018-03-13
  Revision                  1

Portage rsync tree verification is being temporarily turned off by
default, starting with sys-apps/portage-2.3.24. This permits
stabilization of sys-apps/portage-2.3.24 while still working on bugs
relating to tree verification [1]: deadlocks [2] & key fetching [3].

If users wish to enable the 'rsync-verify' USE flag for sys-apps/portage,
they need to follow these steps:

1) In order to unmask the 'rsync-verify' USE flag, create a file named
/etc/portage/profile/package.use.mask containing a line like the
following:

    sys-apps/portage -rsync-verify

2) Once the 'rsync-verify' USE flag has been unmasked as described
in step 1, it can be enabled with a line like the following in
/etc/portage/package.use:

    sys-apps/portage rsync-verify

3) After the configuration changes in steps 1 and 2 have been made, run
the following command:

    emerge --oneshot --newuse '>=sys-apps/portage-2.3.24'

After all above steps are successfully completed, a line like the
following should appear in the emerge --info output for the gentoo
repository:

    sync-rsync-verify-metamanifest: yes

If you wish to disable it for some reason, you can set
'sync-rsync-verify-metamanifest = no' in your repos.conf.

[1] https://bugs.gentoo.org/650144 sys-apps/portage: [TRACKER] issues
    related to 'rsync-verify' USE flag
[2] https://bugs.gentoo.org/647964 app-portage/gemato-11.2: deadlock?
[3] https://bugs.gentoo.org/649276 sys-apps/portage: gpg key refresh
    needs exponential backoff with jitter

2018-05-22-python3-6
  Title                     Python 3.6 to become the default target
  Author                    Michał Górny <mgorny@gentoo.org>
  Posted                    2018-05-22
  Revision                  1

On 2018-06-22, Python 3.6 will replace Python 3.5 in the default Python
targets for Gentoo systems.  The new default targets will be:

    PYTHON_TARGETS="python2_7 python3_6"
    PYTHON_SINGLE_TARGET="python3_6"

If you have not overriden the value of those variables on your system,
then your package manager will want to use the new targets immediately.
In order to prevent dependency conflicts, please clean stray packages
and rebuild/upgrade all packages with USE flag changes after the change,
e.g.:

    emerge --depclean
    emerge -1vUD @world
    emerge --depclean

Please note that upgrading dependencies in place may cause some
of the package dependencies to be temporarily missing.  While this
should not affect scripts that are already fully loaded, it may cause
ImportErrors while starting Python scripts or loading additional
modules (only scripts running Python 3.5 are affected).

In order to improve stability of the upgrade, you may choose to
temporarily enable both targets, i.e. set in /etc/portage/make.conf
or its equivalent:

    PYTHON_TARGETS="python2_7 python3_5 python3_6"
    PYTHON_SINGLE_TARGET="python3_5"

This will cause the dependencies to include both Python 3.5 and 3.6
support on the next system upgrade.  Once all packages are updated,
you can restart your scripts, remove the custom setting and run another
upgrade to remove support for Python 3.5.

If you would like to postpone the switch to Python 3.6, you can copy
the current value of PYTHON_TARGETS and/or PYTHON_SINGLE_TARGET
to /etc/portage/make.conf or its equivalent:

    PYTHON_TARGETS="python2_7 python3_5"
    PYTHON_SINGLE_TARGET="python3_5"

If you would like to migrate your systems earlier, you can do the same
with the new value.

If you are still using Python 3.4, please consider switching to a newer
version as it is reaching its end-of-life.  The end-of-life dates
for the currently used versions are:

  Python 3.4        2019-03-16
  Python 2.7        2020-01-01
  Python 3.5        2020-09-13 [1]

[1]:https://devguide.python.org/#status-of-python-branches

(chroot) sysresccd / #