Gentoo Repository News
sys-boot/raspberrypi-firmware will not install device tree files - 25/11/2019 00:00 GMT
sys-boot/raspberrypi-firmware up to and including version 1.20190709
installed files /boot/*.dtb and /boot/overlays/*. Newer versions will no
longer install these files.
These files will be installed by sys-kernel/raspberrypi-image package.
If you do not use sys-kernel/raspberrypi-image, you need to install
these files according to the method you use to install the kernel. For
installation from source, this can be done with such commands:
make dtbs
cp -v arch/arm64/boot/dts/broadcom/*.dtb /boot/
cp -rv arch/arm64/boot/dts/overlays/ /boot/
This change is being made to enable arm64 users and custom kernels users
to use sys-boot/raspberrypi-firmware package.
See https://bugs.gentoo.org/685412
Posted By: Andrey Utkin
sys-fs/cryfs-0.10.2 update - 29/10/2019 00:00 GMT
Filesystems created with CryFS 0.9.x are incompatible with the new storage format. [1] Migration is necessary before mounting with CryFS 0.10 and possible for old containers going back as far as CryFS 0.9.4. [2] However, upstream recommend to create new containers with 0.10 to avoid potential data loss from a failed migration, and in order to benefit from all performance advantages of the new format. Before updating, copy all data from cryfs containers to a temporary and secure location. After the update, move it back into a newly created container. Don't forget to remove the temporary files afterwards. Users of KDE Plasma Vaults should follow the same procedure. To check the type of existing containers, open them using the Vaults widget. It is part of the path as displayed in dolphin. [1] https://bugs.gentoo.org/690324 [2] https://github.com/cryfs/cryfs/releases/tag/0.10.1
Posted By: Andreas Sturmlechner
new CPU_FLAGS_PPC USE_EXPAND - 11/09/2019 00:00 GMT
A new set of CPU_FLAGS_PPC USE_EXPAND flags has been added. The flags are: altivec - Use the AltiVec/VMX instruction set vsx - Use the Vector Scalar Extension instruction set vsx3 - Use the Vector Scalar Extension v.3 instruction set Note that CPU_FLAGS_PPC variable is used on ppc and ppc64 architectures. In order to transition to new set of flags, if the following flag was was present: USE="altivec" This flag needs to be set as: CPU_FLAGS_PPC="altivec" It's advised to keep 'altivec' USE flag enabled to ensure safe migration and compatibility with external repositories. 'vsx' and 'vsx3' are new flags and no migration necessary. To help users enable the correct USE_EXPAND flags PPC support has been added to app-portage/cpuid2cpuflags package: # emerge -1v >=app-portage/cpuid2cpuflags-7 $ cpuid2cpuflags
Posted By: Georgy Yakovlev
Deprecation and removal of PHP 5.6 - 30/08/2019 00:00 GMT
The Gentoo PHP Team is announcing the deprecation and future removal of PHP 5.6. As of October 1, 2019, PHP 5.6 will be masked for removal. Since some may consider this a critical package, we have decided on a longer than normal 90 day removal period. Other distributions have already or will have moved to PHP 7.2 by the end of the year. Currently, we are using a backport repository to keep security updates in line with the main releases. However, we feel this is the right time to remove this branch as maintenance burden will likely only increase. To that end, the long list of PHP 5 only extensions must accompany its removal. Many of which are long ignored by their upstream maintainers and have no replacements. Some packages listed here have PHP 5 only slots which are included as reminders to upgrade. Some packages do have replacements: dev-php/pecl-memcache can be replaced by dev-php/pecl-memcached with some small code modifications dev-php/pecl-mongo has been superceded by dev-php/pecl-mongodb dev-php/pecl-libevent should be replaced by dev-php/pecl-event with code changes dev-php/PEAR-MDB2_Driver_mysql should be easily replaced by dev-php/PEAR-MDB2_Driver_mysqli with minor configuration changes
Posted By: Brian Evans
Syncthing 1.2.0 and newer do not interoperate with 0.14.45 and older - 18/07/2019 00:00 GMT
Starting with version 1.2.0, Syncthing always uses large, variable-sized, blocks to index and transfer files larger than 256 MiB [1]. Syncthing version 0.14.45 and older will initially appear to accept files scanned with large blocks, but will later panic and shut down during some internal file operations. Do NOT install those versions, or enable large blocks in older versions, in clusters with devices still on v0.14.45 or older, e.g. Debian Stretch servers using distribution-provided packages. [1] https://docs.syncthing.net/advanced/folder-uselargeblocks.html
Posted By: Marek Szuba
amd64 17.1 profiles are now stable - 05/06/2019 00:00 GMT
A new set of 17.1 amd64 profiles has been added to the Gentoo
repository in Dec 2017. These profiles switch to a more standard
'no SYMLINK_LIB' multilib layout, and require explicit migration as
described below. They are considered stable at the moment, and we would
like to request all users to upgrade their systems. The old profiles
will be deprecated in the near future.
In the new profiles, the lib->lib64 compatibility symlink is removed.
64-bit libraries need to be installed directly to lib64. /lib
and /usr/lib become real directories, that are used for cross-arch
and native non-library packages (gcc, clang) and 32-bit libraries
on the multilib profile (which improves compatibility with prebuilt x86
packages).
Migration from both 13.0 and 17.0 profiles is supported. In case
of the former, reading the news item for 17.0 upgrade [1]
is recommended.
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. If you are still running a 13.0 profile, select gcc 6.4.0 or later
as the system compiler, source /etc/profile and reinstall libtool:
# gcc-config -l
[1] x86_64-pc-linux-gnu-5.5.0 *
[2] x86_64-pc-linux-gnu-8.3.0
# gcc-config 2
# . /etc/profile
# emerge -1v libtool
3. Install the tool:
# emerge -1v app-portage/unsymlink-lib
4. 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]
5. This is a very good time to make a backup.
6. Run 'unsymlink-lib --migrate'. You can add '--pretend' first to see
what is going to happen.
7. Reboot your system. Check if important programs work.
In particular, verify that 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 4.
8. 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.
9. Switch the profile, e.g.:
# eselect profile set default/linux/amd64/17.1/desktop
[at this point you can start using emerge again]
10. Rebuild the toolchain:
# emerge -1v sys-devel/gcc:8.3.0
[ repeat for other slots you will be using ]
[ if you are upgrading from 13.0 profile, also: ]
# emerge -1v sys-devel/binutils
# emerge -1v sys-libs/glibc
11. If you are using a multilib profile, rebuild all 32-bit packages.
This can be done using:
# emerge -1v --deep /lib32 /usr/lib32 /usr/lib/llvm/*/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:
# emerge -ev @world
12. 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:
# rm /lib32 /usr/lib32
For known issues, please see bug #506276 [2]. 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 [3].
[1] https://gentoo.org/support/news-items/2017-11-30-new-17-profiles.html
[2] https://bugs.gentoo.org/506276
[3] https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout
Posted By: Michał Górny
Change of ACCEPT_LICENSE default - 23/05/2019 00:00 GMT
The default set of accepted licenses has been changed [1,2] to: ACCEPT_LICENSE="-* @FREE" This means that by default only free software and documentation will be installable. The "FREE" license group is defined in the profiles/license_groups file in the Gentoo repository. It contains licenses that are explicitly approved by the Free Software Foundation, the Open Source Initiative, or that follow the Free Software Definition. The system wide default for the accepted licenses is controlled by the ACCEPT_LICENSE variable in /etc/portage/make.conf, or it can be specified on a per-package basis in /etc/portage/package.license. For example, to allow the app-arch/unrar and sys-kernel/linux-firmware packages to be installed, the following lines would have to be added to /etc/portage/package.license: app-arch/unrar unRAR sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE A migration tool app-portage/elicense is available. It scans installed packages for licenses that are no longer accepted, and generates a list in the same format as the package.license file. See elicense's README for further details. If you want to revert to the previous default, add the following line to /etc/portage/make.conf: ACCEPT_LICENSE="* -@EULA" This will permit all licenses, except End User License Agreements that require reading and signing an acceptance agreement. Note that this will also accept non-free software and documentation. See GLEP 23 [3] as well as the make.conf(5) and portage(5) man pages for the detailed syntax of the ACCEPT_LICENSE variable. Further information about licenses can be found in the Gentoo Handbook [4] and on the license groups wiki page [5]. [1] https://projects.gentoo.org/council/meeting-logs/20190210-summary.txt [2] https://bugs.gentoo.org/676248 [3] https://www.gentoo.org/glep/glep-0023.html [4] https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Portage#Licenses [5] https://wiki.gentoo.org/wiki/License_groups
Posted By: Thomas Deutschmann
MySQL server and library dependency shift - 13/02/2019 00:00 GMT
Due to the complexity of supporting multiple client libraries, the Gentoo MySQL maintainers have decided to drop dependencies on the server installation where it is not absolutely necessary. This will mean that packages might not automatically install the server as a dependency since it does not have to exist on the local machine. To ensure uninterrupted service, verify that the server package, such as dev-db/mariadb, dev-db/mysql, etc, is included in the world file where it is in operation. This can be accomplished by running emerge with the --noreplace option. Eg.: emerge --noreplace dev-db/mariadb
Posted By: Brian Evans
ARM 17.0 profile migration with CHOST change - 07/09/2018 00:00 GMT
The new 17.0 profiles for ARM are now officially available. This not only features the PIE migration previously announced for other architectures but also a tuple (CHOST) change for hardfloat systems. In short, the tuple will change from armv7a-hardfloat-linux-gnueabi to armv7a-unknown-linux-gnueabihf or similar. This is to fall in line with what the rest of the Linux community are now using. If the vendor (2nd) part of your tuple is different or missing then you may keep it as it is. The hf ending is what matters. If you are using an unversioned alternative profile such as hardened/linux/arm/armv7a then the default CHOST will have changed for you already. Hopefully, you were shielded from the change by having CHOST explicitly set in your make.conf. In this case, a migration is still required. Changing CHOST is never simple and does carry some risk. We encourage users to migrate but if you do not have sys-devel/llvm on your system and you do not cross-compile for ARM then you may choose to keep your existing CHOST. We will continue to support this to some degree although we cannot promise that other packages will not be affected in future. If you choose not to migrate or your system is not hardfloat then you must ensure that CHOST is explicitly set in make.conf and then proceed with a regular 17.0 migration to deal with PIE as detailed here: https://www.gentoo.org/support/news-items/2017-11-30-new-17-profiles.html Otherwise, if you do wish to migrate then we have written a script to do the necessary steps for you. Download the raw script here: https://dev.gentoo.org/~chewi/armhf-migrate.bash View with syntax highlighting and change history here: https://gist.github.com/chewi/1601684ad8f3cf8de0b786c00fa09b3c It takes a minimal backup of the existing toolchain with quickpkg before changing anything but we strongly recommend that you take a full backup first. The script echos each command as it goes along so that you can keep an eye on what it's doing. You are, of course, welcome to tinker with the script or perform the migration manually if you think you know your own system better. It is heavily commented for this reason. If the script fails then you can take remedial action before running it again and it should skip any time-consuming builds that it has already done. If the migration doesn't go to plan then please do seek help in #gentoo-arm. A migration of this kind can justify rebuilding @world but with ARM typically being very slow, the script does just the minimum necessary. You are free to rebuild @world yourself after running it.
Posted By: James Le Cuirot
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