Gentoo Repository News
Migration required for OpenSSH with LDAP - 07/08/2018 00:00 GMT
If your sshd authenticates against LDAP, you have to migrate your current setup to a new one using sshd's "AuthorizedKeysCommand" option and a wrapper provided by packages like the new sys-auth/ssh-ldap-pubkey or sys-auth/sakcl because beginning with net-misc/openssh-7.7_p1, OpenSSH-LPK patch set is deprecated and no longer applies. We have created a short migration guide in the Wiki [1] for more details. [1] https://wiki.gentoo.org/wiki/SSH/LDAP_migration
Posted By: Thomas Deutschmann
Portage rsync hardlink support - 11/07/2018 00:00 GMT
For users of the rsync tree, beginning with sys-apps/portage-2.3.42,
the default behavior for sync operations will use hardlinks in order
to ensure that a repository remains in a valid state if something
goes wrong [1]. For example, if signature verification fails during a
sync operation, the new hardlink behavior will preserve the previous
state of the repository.
The new behavior may conflict with configurations that restrict the
use of hardlinks, such as overlay filesystems. Therefore, users will
have to set "sync-allow-hardlinks = no" in repos.conf if they have
a configuration that restricts the use of hardlinks, but this should
not be very common:
[DEFAULT]
sync-allow-hardlinks = no
Note that it is possible to sync more efficiently using git [2]
instead of rsync, though git consumes an increasing amount of disk
space over time unless shallow pull is enabled via the sync-depth
option in repos.conf [3] (requires sys-apps/portage-2.3.42 or later).
[1] https://bugs.gentoo.org/660410 sys-apps/portage: use rsync
--link-dest to implement atomic repository updates (and abort if
signature verification fails)
[2] https://wiki.gentoo.org/wiki/Portage_Security#git-mirror_repo
[3] https://bugs.gentoo.org/552814 sys-apps/portage: support shallow
git pull by setting sync-depth = 1 in repos.conf
Posted By: Zac Medico
Python 3.6 to become the default target - 22/05/2018 00:00 GMT
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
Posted By: Michał Górny
Radicale 2 requires pre-install migration - 02/04/2018 00:00 GMT
Radicale version 2 uses a new storage format and is not able to read databases created by version 1. Version 1 releases starting from 1.1.3 include a --export-storage option which can be used to export their databases in a format that Radicale 2 can use; you must do this before upgrading to version 2. If you have kept the Gentoo-default database configuration, this will work: 1. Stop any running instance of Radicale. 2. Run `radicale --export-storage ~/radicale-exported`. 3. Run `chown -R radicale: ~/radicale-exported` 4. Run `mv /var/lib/radicale /var/lib/radicale.old`. 5. Install Radicale version 2. 6. Run `mv ~/radicale-exported /var/lib/radicale/collections`. For more details, or if you are have a more complex configuration, please see the migration guide: http://radicale.org/1to2/ If you do a custom migration, please ensure the database is cleaned out of /var/lib/radicale, including the hidden .props file.
Posted By: Christopher Head
Portage rsync tree verification unstable - 13/03/2018 00:00 GMT
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
Posted By: Zac Medico
Portage rsync tree verification - 30/01/2018 00:00 GMT
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/
Posted By: Michał Górny
systemd sysv-utils blocker resolution - 23/01/2018 00:00 GMT
Starting with systemd-236, the sysv-utils USE flag is enabled by
default.
The sysv-utils USE flag controls installation of symlinks for several
key commands:
/sbin/halt -> ../bin/systemctl
/sbin/init -> ../lib/systemd/systemd
/sbin/reboot -> ../bin/systemctl
/sbin/poweroff -> ../bin/systemctl
/sbin/runlevel -> ../bin/systemctl
/sbin/shutdown -> ../bin/systemctl
/sbin/telinit -> ../bin/systemctl
These commands are otherwise provided by sys-apps/sysvinit. This package
is blocked by systemd when the sysv-utils USE flag is enabled.
Enabling sysv-utils should cause Portage to un-merge sysvinit and OpenRC
if they are currently installed. emerge may emit a warning message
before doing so; if you are booting with systemd, this message is safe
to ignore.
If you wish to keep sysvinit (and openrc) installed, you may disable the
sysv-utils USE flag locally.
If you run into unresolvable blockers with sysv-utils enabled, ensure
that you do not have any reverse dependencies of sys-apps/sysvinit
selected (in your world file).
Common packages to look for:
sys-apps/sysvinit
sys-apps/openrc
net-misc/netifrc
The equery command from gentoolkit may help track down installed
packages that depend on openrc.
equery depends sys-apps/openrc
Posted By: Mike Gilbert
GnuCash 2.7+ Breaking Change - 14/01/2018 00:00 GMT
Along with changes to use modern libraries, GnuCash 2.7+ has changed the schema [1] it uses for both databases and files. GnuCash will automatically modify the file or database in place upon open. Therefore, it is imperative that you back up any files or databases before using GnuCash 2.7 in case you run into an issue and want or need to revert back to 2.6. Close any open session of GnuCash including remote sessions, then follow the relevant backup instructions as follows: For XML (plain files): $ cp /path/to/file.gnucash /path/to/file.gnucash.bak For MySQL: $ mysqldump gnucash_db | xz > gnucash-2.6.sql.xz For PostgreSQL: $ pg_dump -U gnucash_user -Z 5 gnucash_db > gnucash-2.6.sql.gz For SQLite: $ cp /path/to/sqlite.file.gnucash /path/to/sqlite.file.gnucash.bak [1] https://github.com/Gnucash/gnucash/releases/tag/2.7.0a
Posted By: Aaron W. Swenson
Experimental amd64 17.1 profiles up for testing - 26/12/2017 00:00 GMT
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
Posted By: Michał Górny
New 17.0 profiles in the Gentoo repository - 30/11/2017 00:00 GMT
We have just added (for all arches except arm and mips, these follow
later) a new set of profiles with release version 17.0 to the Gentoo
repository. These bring three changes:
1) The default C++ language version for applications is now C++14.
This change is mostly relevant to Gentoo developers. It also
means, however, that compilers earlier than GCC 6 are masked
and not supported for use as a system compiler anymore. Feel
free to unmask them if you need them for specific applications.
2) Where supported, GCC will now build position-independent
executables (PIE) by default. This improves the overall
security fingerprint. The switch from non-PIE to PIE binaries,
however, requires some steps by users, as detailed below.
3) Up to now, hardened profiles were separate from the default
profile tree. Now they are moving into the 17.0 profile
as a feature there, similar to "no-multilib" and "systemd".
Please migrate away from the 13.0 profiles within the six weeks after
GCC 6.4.0 has been stabilized on your architecture. The 13.0 profiles
will be deprecated then and removed in half a year.
If you are not already running a hardened setup with PIE enabled, then
switching the profile involves the following steps:
If not already done,
* Use gcc-config to select gcc-6.4.0 or later as system compiler
* Re-source /etc/profile:
. /etc/profile
* Re-emerge libtool
emerge -1 sys-devel/libtool
Then,
* Select the new profile with eselect
* Re-emerge, in this sequence, gcc, binutils, and glibc
emerge -1 sys-devel/gcc:6.4.0
emerge -1 sys-devel/binutils
emerge -1 sys-libs/glibc
* Rebuild your entire system
emerge -e @world
Switching the profile from 13.0 to 17.0 modifies the settings of
GCC 6 to generate PIE executables by default; thus, you need to do
the rebuilds even if you have already used GCC 6 beforehand.
If you do not follow these steps you may get spurious build
failures when the linker tries unsuccessfully to combine non-PIE
and PIE code.
Posted By: Andreas K. Hüttel