diff options
Diffstat (limited to 'metadata/news')
72 files changed, 3009 insertions, 0 deletions
diff --git a/metadata/news/2016-01-08-some-dhcpcd-hooks-are-now-examples/2016-01-08-some-dhcpcd-hooks-are-now-examples.en.txt b/metadata/news/2016-01-08-some-dhcpcd-hooks-are-now-examples/2016-01-08-some-dhcpcd-hooks-are-now-examples.en.txt new file mode 100644 index 000000000000..848a842b446c --- /dev/null +++ b/metadata/news/2016-01-08-some-dhcpcd-hooks-are-now-examples/2016-01-08-some-dhcpcd-hooks-are-now-examples.en.txt @@ -0,0 +1,21 @@ +Title: Some dhcpcd hooks are now examples +Author: William Hubbs <williamh@gentoo.org> +Content-Type: text/plain +Posted: 2016-01-08 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Installed: <=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. diff --git a/metadata/news/2016-01-27-upgrading-to-apache-2_4/2016-01-27-upgrading-to-apache-2_4.en.txt b/metadata/news/2016-01-27-upgrading-to-apache-2_4/2016-01-27-upgrading-to-apache-2_4.en.txt new file mode 100644 index 000000000000..bff0e7d400f9 --- /dev/null +++ b/metadata/news/2016-01-27-upgrading-to-apache-2_4/2016-01-27-upgrading-to-apache-2_4.en.txt @@ -0,0 +1,23 @@ +Title: Upgrading Apache from 2.2 to 2.4 +Author: Dirkjan Ochtman <djc@gentoo.org> +Content-Type: text/plain +Posted: 2016-01-27 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: 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 diff --git a/metadata/news/2016-04-07-kde-plasma5-stable/2016-04-07-kde-plasma5-stable.en.txt b/metadata/news/2016-04-07-kde-plasma5-stable/2016-04-07-kde-plasma5-stable.en.txt new file mode 100644 index 000000000000..c9302f0911ec --- /dev/null +++ b/metadata/news/2016-04-07-kde-plasma5-stable/2016-04-07-kde-plasma5-stable.en.txt @@ -0,0 +1,38 @@ +Title: KDE Plasma 5 Upgrade +Author: Michael Palimaka <kensington@gentoo.org> +Content-Type: text/plain +Posted: 2016-04-02 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: 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 diff --git a/metadata/news/2016-04-24-default-video-cards/2016-04-24-default-video-cards.en.txt b/metadata/news/2016-04-24-default-video-cards/2016-04-24-default-video-cards.en.txt new file mode 100644 index 000000000000..8a94240b08e9 --- /dev/null +++ b/metadata/news/2016-04-24-default-video-cards/2016-04-24-default-video-cards.en.txt @@ -0,0 +1,27 @@ +Title: Changes in default VIDEO_CARDS +Author: Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> +Content-Type: text/plain +Posted: 2016-04-24 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Keyword: amd64 +Display-If-Keyword: x86 +Display-If-Installed: x11-drivers/xf86-video-dummy +Display-If-Installed: x11-drivers/xf86-video-glint +Display-If-Installed: x11-drivers/xf86-video-mach64 +Display-If-Installed: x11-drivers/xf86-video-mga +Display-If-Installed: x11-drivers/xf86-video-nv +Display-If-Installed: x11-drivers/xf86-video-r128 +Display-If-Installed: x11-drivers/xf86-video-savage +Display-If-Installed: x11-drivers/xf86-video-tdfx +Display-If-Installed: x11-drivers/xf86-video-trident +Display-If-Installed: x11-drivers/xf86-video-v4l +Display-If-Installed: x11-drivers/xf86-video-via +Display-If-Installed: x11-drivers/xf86-video-vmware + +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. diff --git a/metadata/news/2016-05-23-lastpass-changes/2016-05-23-lastpass-changes.en.txt b/metadata/news/2016-05-23-lastpass-changes/2016-05-23-lastpass-changes.en.txt new file mode 100644 index 000000000000..4534932a7929 --- /dev/null +++ b/metadata/news/2016-05-23-lastpass-changes/2016-05-23-lastpass-changes.en.txt @@ -0,0 +1,30 @@ +Title: LastPass package migration +Author: Göktürk Yüksek <gokturk@gentoo.org> +Author: Robin H. Johnson <robbat2@gentoo.org> +Content-Type: text/plain +Posted: 2016-05-23 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: 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. diff --git a/metadata/news/2016-06-23-l10n-use_expand/2016-06-23-l10n-use_expand.en.txt b/metadata/news/2016-06-23-l10n-use_expand/2016-06-23-l10n-use_expand.en.txt new file mode 100644 index 000000000000..2ff30d780bff --- /dev/null +++ b/metadata/news/2016-06-23-l10n-use_expand/2016-06-23-l10n-use_expand.en.txt @@ -0,0 +1,49 @@ +Title: L10N USE_EXPAND variable replacing LINGUAS +Author: Mart Raudsepp <leio@gentoo.org> +Author: Ulrich Müller <ulm@gentoo.org> +Content-Type: text/plain +Posted: 2016-06-19 +Revision: 1 +News-Item-Format: 1.0 + +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. diff --git a/metadata/news/2016-08-08-openafs-debug_rodata/2016-08-08-openafs-debug_rodata.en.txt b/metadata/news/2016-08-08-openafs-debug_rodata/2016-08-08-openafs-debug_rodata.en.txt new file mode 100644 index 000000000000..3997c7df8113 --- /dev/null +++ b/metadata/news/2016-08-08-openafs-debug_rodata/2016-08-08-openafs-debug_rodata.en.txt @@ -0,0 +1,30 @@ +Title: OpenAFS no longer needs kernel option DEBUG_RODATA +Author: NP-Hardass <NP-Hardass@gentoo.org> +Author: Andrew Savchenko <bircoph@gentoo.org> +Content-Type: text/plain +Posted: 2016-08-08 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2 +Display-If-Keyword: amd64 +Display-If-Keyword: ~amd64-linux +Display-If-Keyword: ~sparc +Display-If-Keyword: x86 +Display-If-Keyword: ~x86-linux + +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 diff --git a/metadata/news/2016-09-26-migration-to-sys-libs_uclibc-ng/2016-09-26-migration-to-sys-libs_uclibc-ng.en.txt b/metadata/news/2016-09-26-migration-to-sys-libs_uclibc-ng/2016-09-26-migration-to-sys-libs_uclibc-ng.en.txt new file mode 100644 index 000000000000..6a0e2f016ab3 --- /dev/null +++ b/metadata/news/2016-09-26-migration-to-sys-libs_uclibc-ng/2016-09-26-migration-to-sys-libs_uclibc-ng.en.txt @@ -0,0 +1,47 @@ +Title: Migration to sys-libs/uclibc-ng +Author: Anthony G. Basile <blueness@gentoo.org> +Content-Type: text/plain +Posted: 2016-09-26 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: sys-libs/uclibc +Display-If-Profile: default/linux/uclibc/amd64 +Display-If-Profile: hardened/linux/uclibc/amd64 +Display-If-Profile: default/linux/uclibc/arm/armv7a +Display-If-Profile: hardened/linux/uclibc/arm/armv7a +Display-If-Profile: default/linux/uclibc/mips +Display-If-Profile: hardened/linux/uclibc/mips +Display-If-Profile: default/linux/uclibc/mips/mipsel +Display-If-Profile: hardened/linux/uclibc/mips/mipsel +Display-If-Profile: default/linux/uclibc/ppc +Display-If-Profile: hardened/linux/uclibc/ppc +Display-If-Profile: default/linux/uclibc/x86 +Display-If-Profile: hardened/linux/uclibc/x86 + +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 diff --git a/metadata/news/2016-09-27-openrc_0_22_updates/2016-09-27-openrc_0_22_updates.en.txt b/metadata/news/2016-09-27-openrc_0_22_updates/2016-09-27-openrc_0_22_updates.en.txt new file mode 100644 index 000000000000..48dfe46ce467 --- /dev/null +++ b/metadata/news/2016-09-27-openrc_0_22_updates/2016-09-27-openrc_0_22_updates.en.txt @@ -0,0 +1,22 @@ +Title: OpenRC 0.22 updates +Author: William Hubbs <williamh@gentoo.org> +Content-Type: text/plain +Posted: 2016-09-27 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <=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. diff --git a/metadata/news/2016-10-25-llvm_3_9_with_llvm_targets/2016-10-25-llvm_3_9_with_llvm_targets.en.txt b/metadata/news/2016-10-25-llvm_3_9_with_llvm_targets/2016-10-25-llvm_3_9_with_llvm_targets.en.txt new file mode 100644 index 000000000000..d5656db56539 --- /dev/null +++ b/metadata/news/2016-10-25-llvm_3_9_with_llvm_targets/2016-10-25-llvm_3_9_with_llvm_targets.en.txt @@ -0,0 +1,41 @@ +Title: LLVM 3.9 with LLVM_TARGETS +Author: Michał Górny <mgorny@gentoo.org> +Content-Type: text/plain +Posted: 2016-10-25 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <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. diff --git a/metadata/news/2016-11-04-important_fstab_and_localmount_update/2016-11-04-important_fstab_and_localmount_update.en.txt b/metadata/news/2016-11-04-important_fstab_and_localmount_update/2016-11-04-important_fstab_and_localmount_update.en.txt new file mode 100644 index 000000000000..3cd9a8f25541 --- /dev/null +++ b/metadata/news/2016-11-04-important_fstab_and_localmount_update/2016-11-04-important_fstab_and_localmount_update.en.txt @@ -0,0 +1,28 @@ +Title: Important fstab and localmount update +Author: William Hubbs <williamh@gentoo.org> +Author: Ian Stakenvicius <axs@gentoo.org> +Display-If-Installed: <=sys-apps/openrc-0.23 +Content-Type: text/plain +Posted: 2016-11-04 +Revision: 2 +News-Item-Format: 1.0 + +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. diff --git a/metadata/news/2016-12-06-ruby-20-removal/2016-12-06-ruby-20-removal.en.txt b/metadata/news/2016-12-06-ruby-20-removal/2016-12-06-ruby-20-removal.en.txt new file mode 100644 index 000000000000..c6bc2cf7fb44 --- /dev/null +++ b/metadata/news/2016-12-06-ruby-20-removal/2016-12-06-ruby-20-removal.en.txt @@ -0,0 +1,27 @@ +Title: Ruby 2.0 removal; Ruby 2.1 default +Author: Hans de Graaff <graaff@gentoo.org> +Content-Type: text/plain +Posted: 2016-12-04 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <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/ diff --git a/metadata/news/2017-01-15-kde-plasma-4-removal/2017-01-15-kde-plasma-4-removal.en.txt b/metadata/news/2017-01-15-kde-plasma-4-removal/2017-01-15-kde-plasma-4-removal.en.txt new file mode 100644 index 000000000000..d07bca7b7f4e --- /dev/null +++ b/metadata/news/2017-01-15-kde-plasma-4-removal/2017-01-15-kde-plasma-4-removal.en.txt @@ -0,0 +1,50 @@ +Title: KDE Plasma 4 and KDE profile removal +Author: Andreas Sturmlechner <asturm@gentoo.org> +Content-Type: text/plain +Posted: 2017-01-08 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: kde-plasma/kdebase-startkde +Display-If-Installed: kde-plasma/kdm +Display-If-Profile: default/linux/alpha/13.0/desktop/kde +Display-If-Profile: default/linux/alpha/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/amd64/13.0/desktop/kde +Display-If-Profile: default/linux/amd64/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/arm/13.0/desktop/kde +Display-If-Profile: default/linux/arm/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/arm/13.0/armv4/desktop/kde +Display-If-Profile: default/linux/arm/13.0/armv4t/desktop/kde +Display-If-Profile: default/linux/arm/13.0/armv5te/desktop/kde +Display-If-Profile: default/linux/arm/13.0/armv6j/desktop/kde +Display-If-Profile: default/linux/arm/13.0/armv7a/desktop/kde +Display-If-Profile: default/linux/ia64/13.0/desktop/kde +Display-If-Profile: default/linux/ia64/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/m68k/13.0/desktop/kde +Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop/kde +Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde/systemd +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/kde +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/kde/systemd +Display-If-Profile: default/linux/sh/13.0/desktop/kde +Display-If-Profile: default/linux/sparc/13.0/desktop/kde +Display-If-Profile: default/linux/sparc/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/x86/13.0/desktop/kde +Display-If-Profile: default/linux/x86/13.0/desktop/kde/systemd + +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 diff --git a/metadata/news/2017-01-21-python-exec-2-3-reclaims-python-symlinks/2017-01-21-python-exec-2-3-reclaims-python-symlinks.en.txt b/metadata/news/2017-01-21-python-exec-2-3-reclaims-python-symlinks/2017-01-21-python-exec-2-3-reclaims-python-symlinks.en.txt new file mode 100644 index 000000000000..4aa341514ac4 --- /dev/null +++ b/metadata/news/2017-01-21-python-exec-2-3-reclaims-python-symlinks/2017-01-21-python-exec-2-3-reclaims-python-symlinks.en.txt @@ -0,0 +1,40 @@ +Title: python-exec 2.3 reclaims python* symlinks +Author: Michał Górny <mgorny@gentoo.org> +Content-Type: text/plain +Posted: 2017-01-21 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <app-eselect/eselect-python-20160206 +Display-If-Installed: <dev-lang/python-exec-2.3 + +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 diff --git a/metadata/news/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22.en.txt b/metadata/news/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22.en.txt new file mode 100644 index 000000000000..b413ce40a58b --- /dev/null +++ b/metadata/news/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22.en.txt @@ -0,0 +1,77 @@ +Title: Upgrade to =sys-libs/uclibc-ng-1.0.22 +Author: Anthony G. Basile <blueness@gentoo.org> +Content-Type: text/plain +Posted: 2017-02-10 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: sys-libs/uclibc-ng +Display-If-Profile: default/linux/uclibc/amd64 +Display-If-Profile: hardened/linux/uclibc/amd64 +Display-If-Profile: default/linux/uclibc/arm/armv7a +Display-If-Profile: hardened/linux/uclibc/arm/armv7a +Display-If-Profile: default/linux/uclibc/mips +Display-If-Profile: hardened/linux/uclibc/mips +Display-If-Profile: default/linux/uclibc/mips/mipsel +Display-If-Profile: hardened/linux/uclibc/mips/mipsel +Display-If-Profile: default/linux/uclibc/ppc +Display-If-Profile: hardened/linux/uclibc/ppc +Display-If-Profile: default/linux/uclibc/x86 +Display-If-Profile: hardened/linux/uclibc/x86 + +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 + diff --git a/metadata/news/2017-03-02-exim-chunking-bug/2017-03-02-exim-chunking-bug.en.txt b/metadata/news/2017-03-02-exim-chunking-bug/2017-03-02-exim-chunking-bug.en.txt new file mode 100644 index 000000000000..7212f5861d91 --- /dev/null +++ b/metadata/news/2017-03-02-exim-chunking-bug/2017-03-02-exim-chunking-bug.en.txt @@ -0,0 +1,28 @@ +Title: =mail-mta/exim-4.88 problem with chunking +Author: Fabian Groffen <grobian@gentoo.org> +Content-Type: text/plain +Posted: 2017-03-01 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: =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 diff --git a/metadata/news/2017-04-10-split-and-slotted-wine/2017-04-10-split-and-slotted-wine.en.txt b/metadata/news/2017-04-10-split-and-slotted-wine/2017-04-10-split-and-slotted-wine.en.txt new file mode 100644 index 000000000000..da288f518798 --- /dev/null +++ b/metadata/news/2017-04-10-split-and-slotted-wine/2017-04-10-split-and-slotted-wine.en.txt @@ -0,0 +1,52 @@ +Title: app-emulation/wine split and slotting +Author: NP-Hardass <NP-Hardass@gentoo.org> +Content-Type: text/plain +Posted: 2017-04-10 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: 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 diff --git a/metadata/news/2017-07-16-systemd-rootprefix/2017-07-16-systemd-rootprefix.en.txt b/metadata/news/2017-07-16-systemd-rootprefix/2017-07-16-systemd-rootprefix.en.txt new file mode 100644 index 000000000000..429eee32de7d --- /dev/null +++ b/metadata/news/2017-07-16-systemd-rootprefix/2017-07-16-systemd-rootprefix.en.txt @@ -0,0 +1,34 @@ +Title: systemd rootprefix migration +Author: Mike Gilbert <floppym@gentoo.org> +Posted: 2017-07-16 +Revision: 4 +News-Item-Format: 2.0 +Display-If-Installed: <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 237 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. diff --git a/metadata/news/2017-08-19-hardened-sources-removal/2017-08-19-hardened-sources-removal.en.txt b/metadata/news/2017-08-19-hardened-sources-removal/2017-08-19-hardened-sources-removal.en.txt new file mode 100644 index 000000000000..a2da83e6af43 --- /dev/null +++ b/metadata/news/2017-08-19-hardened-sources-removal/2017-08-19-hardened-sources-removal.en.txt @@ -0,0 +1,54 @@ +Title: sys-kernel/hardened-sources removal +Author: Francisco Blas Izquierdo Riera <klondike@gentoo.org> +Posted: 2017-08-19 +Revision: 10 +News-Item-Format: 2.0 +Display-If-Installed: 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 diff --git a/metadata/news/2017-10-04-gentoolkit-dev-deprecation/2017-10-04-gentoolkit-dev-deprecation.en.txt b/metadata/news/2017-10-04-gentoolkit-dev-deprecation/2017-10-04-gentoolkit-dev-deprecation.en.txt new file mode 100644 index 000000000000..43f1a28cbe8e --- /dev/null +++ b/metadata/news/2017-10-04-gentoolkit-dev-deprecation/2017-10-04-gentoolkit-dev-deprecation.en.txt @@ -0,0 +1,22 @@ +Title: app-portage/gentoolkit-dev deprecation and removal +Author: Paul Varner <fuzzyray@gentoo.org> +Posted: 2017-09-19 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: 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. diff --git a/metadata/news/2017-10-13-openrc-service-binary-removal/2017-10-13-openrc-service-binary-removal.en.txt b/metadata/news/2017-10-13-openrc-service-binary-removal/2017-10-13-openrc-service-binary-removal.en.txt new file mode 100644 index 000000000000..9b3734300140 --- /dev/null +++ b/metadata/news/2017-10-13-openrc-service-binary-removal/2017-10-13-openrc-service-binary-removal.en.txt @@ -0,0 +1,14 @@ +Title: OpenRC "service" binary removal +Author: William Hubbs <williamh@gentoo.org> +Display-If-Installed: <=sys-apps/openrc-0.33 +Content-Type: text/plain +Posted: 2017-10-13 +Revision: 1 +News-Item-Format: 1.0 + +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. diff --git a/metadata/news/2017-11-21-old-wine-versions-moving-to-overlay/2017-11-21-old-wine-versions-moving-to-overlay.en.txt b/metadata/news/2017-11-21-old-wine-versions-moving-to-overlay/2017-11-21-old-wine-versions-moving-to-overlay.en.txt new file mode 100644 index 000000000000..ff28b96e6059 --- /dev/null +++ b/metadata/news/2017-11-21-old-wine-versions-moving-to-overlay/2017-11-21-old-wine-versions-moving-to-overlay.en.txt @@ -0,0 +1,37 @@ +Title: Old Wine versions moving to wine-overlay +Author: NP-Hardass <NP-Hardass@gentoo.org> +Posted: 2017-11-21 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: app-emulation/wine:0 +Display-If-Installed: app-emulation/wine-vanilla +Display-If-Installed: app-emulation/wine-staging +Display-If-Installed: app-emulation/wine-d3d9 +Display-If-Installed: app-emulation/wine-any + +To reduce the burden on main Gentoo repository, older versions of Wine +will be available only in the wine overlay. These ebuilds will still be +fully supported by the Gentoo Wine Project. This will result in +upstream stable releases and the several most recent upstream devel +releases being the only versions in ::gentoo; all versions meeting the +criteria for support within Gentoo [1] will be available in ::wine. + +To install the overlay you can either add the repos.conf file to your +portage configuration directory, add the repository via layman, or add the +repository via eselect-repository. + +* To add the repos.conf file: +# wget https://dev.gentoo.org/~np-hardass/proj/wine/wine.conf -O \ + /etc/portage/repos.conf/wine.conf + +Edit the /etc/portage/repos.conf/wine.conf file so that "location" +points to your desired folder to install the overlay. +# emaint sync --repo wine + +* To install the overlay via layman: +# layman -a wine + +* To install the overlay via eselect-repository: +# eselect repository enable wine + +[1] https://wiki.gentoo.org/wiki/Project:Wine/Policies_and_Procedures#Supported_versions diff --git a/metadata/news/2017-11-22-games-destable/2017-11-22-games-destable.en.txt b/metadata/news/2017-11-22-games-destable/2017-11-22-games-destable.en.txt new file mode 100644 index 000000000000..5c1981c34c53 --- /dev/null +++ b/metadata/news/2017-11-22-games-destable/2017-11-22-games-destable.en.txt @@ -0,0 +1,26 @@ +Title: No stable KEYWORDS for Gentoo Games +Author: David Seifert <soap@gentoo.org> +Content-Type: text/plain +Posted: 2017-11-22 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Keyword: amd64 x86 + +As the Games team does not have enough manpower to keep tabs on all +games packages, we have dropped all ebuilds maintained by the games +project to unstable KEYWORDS (without those required by other stable +packages). If you have any of these stable games packages installed, +you will have to add them to /etc/portage/package.accept_keywords/ +manually. Failures related to missing stable KEYWORDS will show up as + + The following keyword changes are necessary to proceed: + (see "package.accept_keywords" in the portage(5) man page for more details) + # required by @selected + # required by @world (argument) + =games-action/0verkill-0.16-r4 ~amd64 + +While we accept that this will cause some irritation for the community, +pretending we have a well supported games collection by having a +wealth of stable games packages is misleading at best. We welcome +contributions from outsiders willing to polish up the games landscape +in Gentoo via the Proxy Maintainers Project. diff --git a/metadata/news/2017-11-30-new-17-profiles/2017-11-30-new-17-profiles.en.txt b/metadata/news/2017-11-30-new-17-profiles/2017-11-30-new-17-profiles.en.txt new file mode 100644 index 000000000000..f66cd54c9e64 --- /dev/null +++ b/metadata/news/2017-11-30-new-17-profiles/2017-11-30-new-17-profiles.en.txt @@ -0,0 +1,89 @@ +Title: New 17.0 profiles in the Gentoo repository +Author: Andreas K. Hüttel <dilfridge@gentoo.org> +Posted: 2017-11-30 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Profile: default/linux/amd64/13.0 +Display-If-Profile: default/linux/amd64/13.0/selinux +Display-If-Profile: default/linux/amd64/13.0/desktop +Display-If-Profile: default/linux/amd64/13.0/desktop/gnome +Display-If-Profile: default/linux/amd64/13.0/desktop/gnome/systemd +Display-If-Profile: default/linux/amd64/13.0/desktop/plasma +Display-If-Profile: default/linux/amd64/13.0/desktop/plasma/systemd +Display-If-Profile: default/linux/amd64/13.0/developer +Display-If-Profile: default/linux/amd64/13.0/no-multilib +Display-If-Profile: default/linux/amd64/13.0/systemd +Display-If-Profile: default/linux/ia64/13.0 +Display-If-Profile: default/linux/ia64/13.0/desktop +Display-If-Profile: default/linux/ia64/13.0/desktop/gnome +Display-If-Profile: default/linux/ia64/13.0/desktop/gnome/systemd +Display-If-Profile: default/linux/ia64/13.0/developer +Display-If-Profile: default/linux/powerpc/ppc32/13.0 +Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop +Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop/gnome +Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop/gnome/systemd +Display-If-Profile: default/linux/powerpc/ppc32/13.0/developer +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/desktop +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/gnome +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/gnome/systemd +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/developer +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/desktop +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/gnome +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/gnome/systemd +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/developer +Display-If-Profile: default/linux/x86/13.0 +Display-If-Profile: default/linux/x86/13.0/selinux +Display-If-Profile: default/linux/x86/13.0/desktop +Display-If-Profile: default/linux/x86/13.0/desktop/gnome +Display-If-Profile: default/linux/x86/13.0/desktop/gnome/systemd +Display-If-Profile: default/linux/x86/13.0/desktop/plasma +Display-If-Profile: default/linux/x86/13.0/desktop/plasma/systemd +Display-If-Profile: default/linux/x86/13.0/developer +Display-If-Profile: default/linux/x86/13.0/no-multilib +Display-If-Profile: default/linux/x86/13.0/systemd + +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. diff --git a/metadata/news/2018-01-14-gnucash/2018-01-14-gnucash.en.txt b/metadata/news/2018-01-14-gnucash/2018-01-14-gnucash.en.txt new file mode 100644 index 000000000000..334c1c078335 --- /dev/null +++ b/metadata/news/2018-01-14-gnucash/2018-01-14-gnucash.en.txt @@ -0,0 +1,31 @@ +Title: GnuCash 2.7+ Breaking Change +Author: Aaron W. Swenson <titanofold@gentoo.org> +Posted: 2018-01-14 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: <app-office/gnucash-4 + +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 diff --git a/metadata/news/2018-01-23-systemd-blocker/2018-01-23-systemd-blocker.en.txt b/metadata/news/2018-01-23-systemd-blocker/2018-01-23-systemd-blocker.en.txt new file mode 100644 index 000000000000..17692d9b6eac --- /dev/null +++ b/metadata/news/2018-01-23-systemd-blocker/2018-01-23-systemd-blocker.en.txt @@ -0,0 +1,46 @@ +Title: systemd sysv-utils blocker resolution +Author: Mike Gilbert <floppym@gentoo.org> +Posted: 2018-01-23 +Revision: 2 +News-Item-Format: 2.0 +Display-If-Installed: <sys-apps/systemd-236-r4 + +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 diff --git a/metadata/news/2018-01-30-portage-rsync-verification/2018-01-30-portage-rsync-verification.en.txt b/metadata/news/2018-01-30-portage-rsync-verification/2018-01-30-portage-rsync-verification.en.txt new file mode 100644 index 000000000000..0e7fd910d7c8 --- /dev/null +++ b/metadata/news/2018-01-30-portage-rsync-verification/2018-01-30-portage-rsync-verification.en.txt @@ -0,0 +1,50 @@ +Title: Portage rsync tree verification +Author: Michał Górny <mgorny@gentoo.org> +Posted: 2018-01-30 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: <sys-apps/portage-2.3.62 + +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/ diff --git a/metadata/news/2018-04-08-radicale-2-requires-pre-install-migration/2018-04-08-radicale-2-requires-pre-install-migration.en.txt b/metadata/news/2018-04-08-radicale-2-requires-pre-install-migration/2018-04-08-radicale-2-requires-pre-install-migration.en.txt new file mode 100644 index 000000000000..8783ee846bb2 --- /dev/null +++ b/metadata/news/2018-04-08-radicale-2-requires-pre-install-migration/2018-04-08-radicale-2-requires-pre-install-migration.en.txt @@ -0,0 +1,26 @@ +Title: Radicale 2 requires pre-install migration +Author: Christopher Head <chead@chead.ca> +Posted: 2018-04-02 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: <www-apps/radicale-2 + +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. diff --git a/metadata/news/2018-05-22-python3-6/2018-05-22-python3-6.en.txt b/metadata/news/2018-05-22-python3-6/2018-05-22-python3-6.en.txt new file mode 100644 index 000000000000..c8901e970a7f --- /dev/null +++ b/metadata/news/2018-05-22-python3-6/2018-05-22-python3-6.en.txt @@ -0,0 +1,61 @@ +Title: Python 3.6 to become the default target +Author: Michał Górny <mgorny@gentoo.org> +Posted: 2018-05-22 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-lang/python:3.4 +Display-If-Installed: dev-lang/python:3.5 + +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 diff --git a/metadata/news/2018-07-11-portage-sync-allow-hardlinks/2018-07-11-portage-sync-allow-hardlinks.en.txt b/metadata/news/2018-07-11-portage-sync-allow-hardlinks/2018-07-11-portage-sync-allow-hardlinks.en.txt new file mode 100644 index 000000000000..18dc6b395842 --- /dev/null +++ b/metadata/news/2018-07-11-portage-sync-allow-hardlinks/2018-07-11-portage-sync-allow-hardlinks.en.txt @@ -0,0 +1,34 @@ +Title: Portage rsync hardlink support +Author: Zac Medico <zmedico@gentoo.org> +Posted: 2018-07-11 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: <sys-apps/portage-2.3.62 + +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 diff --git a/metadata/news/2018-08-07-openssh-ldap-migration/2018-08-07-openssh-ldap-migration.en.txt b/metadata/news/2018-08-07-openssh-ldap-migration/2018-08-07-openssh-ldap-migration.en.txt new file mode 100644 index 000000000000..d3def75ce262 --- /dev/null +++ b/metadata/news/2018-08-07-openssh-ldap-migration/2018-08-07-openssh-ldap-migration.en.txt @@ -0,0 +1,17 @@ +Title: Migration required for OpenSSH with LDAP +Author: Thomas Deutschmann <whissi@gentoo.org> +Posted: 2018-08-07 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: net-misc/openssh + +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 diff --git a/metadata/news/2018-09-07-arm-17-profile-migration/2018-09-07-arm-17-profile-migration.en.txt b/metadata/news/2018-09-07-arm-17-profile-migration/2018-09-07-arm-17-profile-migration.en.txt new file mode 100644 index 000000000000..800c733a054c --- /dev/null +++ b/metadata/news/2018-09-07-arm-17-profile-migration/2018-09-07-arm-17-profile-migration.en.txt @@ -0,0 +1,63 @@ +Title: ARM 17.0 profile migration with CHOST change +Author: James Le Cuirot <chewi@gentoo.org> +Content-Type: text/plain +Posted: 2018-09-07 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Keyword: arm +Display-If-Keyword: arm-linux + +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. diff --git a/metadata/news/2019-05-23-accept_license/2019-05-23-accept_license.en.txt b/metadata/news/2019-05-23-accept_license/2019-05-23-accept_license.en.txt new file mode 100644 index 000000000000..e42c120b672b --- /dev/null +++ b/metadata/news/2019-05-23-accept_license/2019-05-23-accept_license.en.txt @@ -0,0 +1,53 @@ +Title: Change of ACCEPT_LICENSE default +Author: Ulrich Müller <ulm@gentoo.org> +Author: Thomas Deutschmann <whissi@gentoo.org> +Posted: 2019-05-23 +Revision: 2 +News-Item-Format: 2.0 + +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 diff --git a/metadata/news/2019-06-05-amd64-17-1-profiles-are-now-stable/2019-06-05-amd64-17-1-profiles-are-now-stable.en.txt b/metadata/news/2019-06-05-amd64-17-1-profiles-are-now-stable/2019-06-05-amd64-17-1-profiles-are-now-stable.en.txt new file mode 100644 index 000000000000..59c746dba238 --- /dev/null +++ b/metadata/news/2019-06-05-amd64-17-1-profiles-are-now-stable/2019-06-05-amd64-17-1-profiles-are-now-stable.en.txt @@ -0,0 +1,129 @@ +Title: amd64 17.1 profiles are now stable +Author: Michał Górny <mgorny@gentoo.org> +Posted: 2019-06-05 +Revision: 3 +News-Item-Format: 2.0 +Display-If-Profile: default/linux/amd64/13.0 +Display-If-Profile: default/linux/amd64/13.0/selinux +Display-If-Profile: default/linux/amd64/13.0/desktop +Display-If-Profile: default/linux/amd64/13.0/desktop/gnome +Display-If-Profile: default/linux/amd64/13.0/desktop/gnome/systemd +Display-If-Profile: default/linux/amd64/13.0/desktop/plasma +Display-If-Profile: default/linux/amd64/13.0/desktop/plasma/systemd +Display-If-Profile: default/linux/amd64/13.0/developer +Display-If-Profile: default/linux/amd64/13.0/no-multilib +Display-If-Profile: default/linux/amd64/13.0/systemd +Display-If-Profile: default/linux/amd64/17.0 +Display-If-Profile: default/linux/amd64/17.0/selinux +Display-If-Profile: default/linux/amd64/17.0/hardened +Display-If-Profile: default/linux/amd64/17.0/hardened/selinux +Display-If-Profile: default/linux/amd64/17.0/desktop +Display-If-Profile: default/linux/amd64/17.0/desktop/gnome +Display-If-Profile: default/linux/amd64/17.0/desktop/gnome/systemd +Display-If-Profile: default/linux/amd64/17.0/desktop/plasma +Display-If-Profile: default/linux/amd64/17.0/desktop/plasma/systemd +Display-If-Profile: default/linux/amd64/17.0/developer +Display-If-Profile: default/linux/amd64/17.0/no-multilib +Display-If-Profile: default/linux/amd64/17.0/no-multilib/hardened +Display-If-Profile: default/linux/amd64/17.0/no-multilib/hardened/selinux +Display-If-Profile: default/linux/amd64/17.0/systemd + +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 diff --git a/metadata/news/2019-07-18-syncthing-update-incompatibility/2019-07-18-syncthing-update-incompatibility.en.txt b/metadata/news/2019-07-18-syncthing-update-incompatibility/2019-07-18-syncthing-update-incompatibility.en.txt new file mode 100644 index 000000000000..4b433216333a --- /dev/null +++ b/metadata/news/2019-07-18-syncthing-update-incompatibility/2019-07-18-syncthing-update-incompatibility.en.txt @@ -0,0 +1,16 @@ +Title: Syncthing 1.2.0 and newer do not interoperate with 0.14.45 and older +Author: Marek Szuba <marecki@gentoo.org> +Posted: 2019-07-18 +Revision: 2 +News-Item-Format: 2.0 +Display-If-Installed: net-p2p/syncthing + +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 diff --git a/metadata/news/2019-09-11-cpu_flags_ppc-introduction/2019-09-11-cpu_flags_ppc-introduction.en.txt b/metadata/news/2019-09-11-cpu_flags_ppc-introduction/2019-09-11-cpu_flags_ppc-introduction.en.txt new file mode 100644 index 000000000000..3267fe0af10b --- /dev/null +++ b/metadata/news/2019-09-11-cpu_flags_ppc-introduction/2019-09-11-cpu_flags_ppc-introduction.en.txt @@ -0,0 +1,39 @@ +Title: new CPU_FLAGS_PPC USE_EXPAND +Author: Georgy Yakovlev <gyakovlev@gentoo.org> +Posted: 2019-09-11 +Revision: 2 +News-Item-Format: 2.0 +Display-If-Keyword: ~ppc +Display-If-Keyword: ~ppc64 +Display-If-Keyword: ppc +Display-If-Keyword: ppc64 + + +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 + vsx2 - Use the Vector Scalar Extension v.2 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', 'vsx2' 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-9 + $ cpuid2cpuflags diff --git a/metadata/news/2019-10-29-cryfs-0_10-update/2019-10-29-cryfs-0_10-update.en.txt b/metadata/news/2019-10-29-cryfs-0_10-update/2019-10-29-cryfs-0_10-update.en.txt new file mode 100644 index 000000000000..31c694f9d0ed --- /dev/null +++ b/metadata/news/2019-10-29-cryfs-0_10-update/2019-10-29-cryfs-0_10-update.en.txt @@ -0,0 +1,25 @@ +Title: sys-fs/cryfs-0.10.2 update +Author: Andreas Sturmlechner <asturm@gentoo.org> +Posted: 2019-10-29 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: <sys-fs/cryfs-0.10 + +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 diff --git a/metadata/news/2019-11-25-rpi-firmware-dtb-files/2019-11-25-rpi-firmware-dtb-files.en.txt b/metadata/news/2019-11-25-rpi-firmware-dtb-files/2019-11-25-rpi-firmware-dtb-files.en.txt new file mode 100644 index 000000000000..8fe36a02d9d1 --- /dev/null +++ b/metadata/news/2019-11-25-rpi-firmware-dtb-files/2019-11-25-rpi-firmware-dtb-files.en.txt @@ -0,0 +1,25 @@ +Title: sys-boot/raspberrypi-firmware will not install device tree files +Author: Andrey Utkin <andrey_utkin@gentoo.org> +Content-Type: text/plain +Posted: 2019-11-25 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Installed: sys-boot/raspberrypi-firmware + +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 diff --git a/metadata/news/2019-12-30-genkernel-4-default-filenames/2019-12-30-genkernel-4-default-filenames.en.txt b/metadata/news/2019-12-30-genkernel-4-default-filenames/2019-12-30-genkernel-4-default-filenames.en.txt new file mode 100644 index 000000000000..ba5962e58602 --- /dev/null +++ b/metadata/news/2019-12-30-genkernel-4-default-filenames/2019-12-30-genkernel-4-default-filenames.en.txt @@ -0,0 +1,25 @@ +Title: Genkernel 4 changed default filenames +Author: Thomas Deutschmann <whissi@gentoo.org> +Posted: 2019-12-30 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: >=sys-kernel/genkernel-4 + +To be consistent with kernel's own naming which allows for easier +matching of kernel/initramfs with kernel files (/lib/modules), +genkernel 4 changed default kernel and initramfs filename: + + kernel-genkernel-%%ARCH%%-%%KV%% -> vmlinuz-%%KV%% + System.map-genkernel-%%ARCH%%-%%KV%% -> System.map-%%KV%% + initramfs-genkernel-%%ARCH%%-%%KV%% -> initramfs-%%KV%%.img + +Note that in genkernel 4, filenames are fully customizable and that +$ARCH value is now part of $KV value by default. + +All bootloaders and utilities like sys-apps/kexec-tools available in +Gentoo repository support the new naming schema. + +However, due to lexical ordering, the default boot entry in your boot +manager could still point to last kernel built with genkernel before +that name change, resulting in booting old kernel when not paying +attention on boot. diff --git a/metadata/news/2020-01-23-stable-alpha-keywords-removed/2020-01-23-stable-alpha-keywords-removed.en.txt b/metadata/news/2020-01-23-stable-alpha-keywords-removed/2020-01-23-stable-alpha-keywords-removed.en.txt new file mode 100644 index 000000000000..ad5b6544ff32 --- /dev/null +++ b/metadata/news/2020-01-23-stable-alpha-keywords-removed/2020-01-23-stable-alpha-keywords-removed.en.txt @@ -0,0 +1,14 @@ +Title: Stable alpha keywords removed +Author: Matt Turner <mattst88@gentoo.org> +Posted: 2020-01-23 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Keyword: alpha + +The Gentoo/Alpha team no longer thinks that the time invested in package +stabilization is warranted for the small number of users on Alpha. As a +result, we will drop all "alpha" keywords to "~alpha" on 2020-01-25 and will +add "~alpha" to ACCEPT_KEYWORDS in the profile. + +Users need not make any changes to their systems, and the Gentoo/Alpha team +has no plans to remove support for the architecture. diff --git a/metadata/news/2020-02-19-openssh-8_2-service-breakage/2020-02-19-openssh-8_2-service-breakage.en.txt b/metadata/news/2020-02-19-openssh-8_2-service-breakage/2020-02-19-openssh-8_2-service-breakage.en.txt new file mode 100644 index 000000000000..40a309deafbc --- /dev/null +++ b/metadata/news/2020-02-19-openssh-8_2-service-breakage/2020-02-19-openssh-8_2-service-breakage.en.txt @@ -0,0 +1,30 @@ +Title: OpenSSH 8.2_p1 running sshd breakage +Author: Patrick McLean <chutzpah@gentoo.org> +Posted: 2020-02-20 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: <net-misc/openssh-8.2 + +If sshd is running, and a system is upgraded from +<net-misc/openssh-8.2_p1 to >=net-misc/openssh-8.2_p1, any new ssh +connection will fail until sshd is restarted. + +Before restarting sshd, it is *strongly* recommended that you test your +configuration with the following command (as root): + sshd -t + +If your system is booted with openrc, use this command (as root) +to restart sshd: + rc-service sshd --nodeps restart + +If your system is booted with systemd, use this command (as root) +to restart sshd: + systemctl restart sshd + +WARNING: On systemd booted machines with PAM disabled, this command + will terminate all currently open ssh connections. It is + *strongly* recommended that you validate your configuration + before restarting sshd. + +If you are using systemd socket activation for sshd, then no action is +required. diff --git a/metadata/news/2020-03-30-stable-ia64-keywords-removed/2020-03-30-stable-ia64-keywords-removed.en.txt b/metadata/news/2020-03-30-stable-ia64-keywords-removed/2020-03-30-stable-ia64-keywords-removed.en.txt new file mode 100644 index 000000000000..ad55ad168961 --- /dev/null +++ b/metadata/news/2020-03-30-stable-ia64-keywords-removed/2020-03-30-stable-ia64-keywords-removed.en.txt @@ -0,0 +1,14 @@ +Title: Stable ia64 keywords removed +Author: Matt Turner <mattst88@gentoo.org> +Posted: 2020-03-30 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Keyword: ia64 + +The Gentoo/IA64 team no longer thinks that the time invested in package +stabilization is warranted for the small number of users on IA64. As a +result, we will drop all "ia64" keywords to "~ia64" on 2020-04-03 and will +add "~ia64" to ACCEPT_KEYWORDS in the profile. + +Users need not make any changes to their systems, and the Gentoo/IA64 team +has no plans to remove support for the architecture. diff --git a/metadata/news/2020-04-03-deprecation-of-legacy-x11-input-drivers/2020-04-03-deprecation-of-legacy-x11-input-drivers.en.txt b/metadata/news/2020-04-03-deprecation-of-legacy-x11-input-drivers/2020-04-03-deprecation-of-legacy-x11-input-drivers.en.txt new file mode 100644 index 000000000000..6f7dd7bbbc26 --- /dev/null +++ b/metadata/news/2020-04-03-deprecation-of-legacy-x11-input-drivers/2020-04-03-deprecation-of-legacy-x11-input-drivers.en.txt @@ -0,0 +1,45 @@ +Title: Deprecation of legacy X11 input drivers +Author: Piotr Karbowski <slashbeast@gentoo.org> +Posted: 2020-04-03 +Revision: 2 +News-Item-Format: 2.0 +Display-If-Installed: x11-drivers/xf86-input-mouse +Display-If-Installed: x11-drivers/xf86-input-keyboard + +The Gentoo X11 Team is announcing the deprecation and future removal of +the legacy X11 input drivers x11-drivers/xf86-input-mouse and +x11-drivers/xf86-input-keyboard. As of 2020-05-01 those input drivers +will be masked for removal. + +These drivers have been deprecated for many years, first by +xf86-input-evdev and then by xf86-input-libinput. + +The only use for those drivers remain in deployments which intentionally +opt-out of using udev, as both evdev and libinput require udev during +runtime, however given that upstream has already removed the Linux +support from xf86-input-keyboard, future X11 releases will no longer +support xf86-input-keyboard on Linux rendering those installation +infeasible to use without udev. + +In order to ensure frictionless upgrade path for future X11 releases, we +have decided to deprecate those drivers that are not in active use by +pretty much any installation of Gentoo. + +No action is required from end-users who are already using libinput (or +evdev). To check which driver is in use, one can use + + $ grep 'Using input driver' ~/.local/share/xorg/Xorg.0.log + +for the systems running xorg-server as regular user (-suid ++elogind/+systemd) or by running + + # grep 'Using input driver' /var/log/Xorg.0.log + +for those running xorg-server as root. + +If however neither libinput or evdev is in use, one should append +'libinput' to the INPUT_DEVICES variable inside /etc/portage/make.conf +while removing 'keyboard' and 'mouse' if present, then update @world +with new USE flags + + # emerge -N @world diff --git a/metadata/news/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt b/metadata/news/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt new file mode 100644 index 000000000000..c496154bd8e0 --- /dev/null +++ b/metadata/news/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt @@ -0,0 +1,25 @@ +Title: new ppc64le (little-endian) profiles +Author: Georgy Yakovlev <gyakovlev@gentoo.org> +Posted: 2020-04-04 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd + +A new set of 17.0 ppc64le profiles has been added to the Gentoo repository. +New profiles are compatible with existing ppc64 little-endian profiles, +and no additional action required after switching the profile. + +Please migrate away from the old profiles: + +* Old profiles: +default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian +default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd + +* Replaced by: +default/linux/ppc64le/17.0 +default/linux/ppc64le/17.0/systemd + +Desktop profiles are now also available. + +Refer to `eselect profile list` output. diff --git a/metadata/news/2020-04-14-elogind-default/2020-04-14-elogind-default.en.txt b/metadata/news/2020-04-14-elogind-default/2020-04-14-elogind-default.en.txt new file mode 100644 index 000000000000..d0cd3f67e442 --- /dev/null +++ b/metadata/news/2020-04-14-elogind-default/2020-04-14-elogind-default.en.txt @@ -0,0 +1,60 @@ +Title: Desktop profile switching USE default to elogind +Author: Andreas Sturmlechner <asturm@gentoo.org> +Posted: 2020-04-14 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-auth/consolekit + +Modern desktop environments make use of PAM session tracking for users, login +sessions and seats. [1] The most user-visible part of that is device and file +permissions management and reboot/shutdown handling without superuser rights. + +Users with systemd can stop reading here and continue with their daily +routine. + +ConsoleKit2 is unmaintained upstream for more than two years [2]. There are +many longstanding bugs and papercuts with consumers that aren't being fixed, +not least because these code paths receive very little testing. + +Enter the elogind project [3], which is a standalone logind implementation +based on systemd code, currently maintained by a fellow Gentoo user. We have +had sys-auth/elogind available in Gentoo since the beginning of 2017, and +meanwhile it has gained support [4] in KDE Plasma, Gnome [5], Cinnamon, MATE +and Xfce, as well as most other former consolekit consumers. + +Consequently, the desktop profile is switching away from consolekit to +elogind. Users of sys-auth/consolekit who selected a different profile should +consider doing the same. A guide is available [6]. Migration is easy, but any +existing consolekit session will be broken, and elogind will only begin to work +on relogin. + +Rely either on the profile, or set USE="elogind -consolekit" in make.conf +yourself. Make sure there is no consolekit debris in /etc/portage/package.use: + +# grep -R consolekit /etc/portage/package.use + +Rebuild all affected consumers and remove sys-auth/consolekit: + +# emerge --ask --changed-use --deep @world +# emerge --depclean consolekit + +Optional, but recommended in case of trouble such as missing reboot/shutdown +capabilities in the display manager: + +# rc-update add elogind boot + +For users of ~/.xinitrc instead of one of the supported DMs, do not forget to +update accordingly (ck-launch-session is gone without replacement). + +PS: Subsequently, this will lead to the last-riting of sys-power/pm-utils [7] +which is dead even longer than the original ConsoleKit(1) project. KDE Plasma +users sticking with sys-auth/consolekit are then going to lose suspend from +GUI without superuser rights. + +[1] https://wiki.gentoo.org/wiki/ConsoleKit +[2] https://github.com/ConsoleKit2/ConsoleKit2 +[3] https://github.com/elogind/elogind/blob/master/README.md +[4] https://bugs.gentoo.org/show_bug.cgi?id=elogind-support +[5] https://blogs.gentoo.org/leio/2019/03/26/gnome-3-30/ +[6] https://wiki.gentoo.org/wiki/Elogind +[7] https://bugs.gentoo.org/659616 diff --git a/metadata/news/2020-04-22-opencl-upgrade-file-collisions/2020-04-22-opencl-upgrade-file-collisions.en.txt b/metadata/news/2020-04-22-opencl-upgrade-file-collisions/2020-04-22-opencl-upgrade-file-collisions.en.txt new file mode 100644 index 000000000000..5aeb8569c3ad --- /dev/null +++ b/metadata/news/2020-04-22-opencl-upgrade-file-collisions/2020-04-22-opencl-upgrade-file-collisions.en.txt @@ -0,0 +1,28 @@ +Title: Potential file collisions during OpenCL upgrade +Author: Marek Szuba <marecki@gentoo.org> +Posted: 2020-04-22 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: app-eselect/eselect-opencl + +OpenCL support in Gentoo is now being migrated to having all implementations +operate through an ICD loader (dev-libs/ocl-icd or dev-libs/opencl-icd-loader) +installed directly into /usr rather than using eselect-opencl to switch +between implementations, with updated loader ebuilds having just been released +to the public. Unfortunately although the upgrade process will automatically +uninstall app-eselect/eselect-opencl, it will not remove the symbolic links to +libOpenCL.so created by this tool in library directories because those links +are not owned by the package in question. + +For everyone using the default Gentoo configuration of collision protection +(FEATURES='-collision-protect protect-owned'), this should cause no trouble +because this configuration allows the overwriting of orphaned files. +Obviously, systems with collision protection completely disabled (not +recommended but technically possible) will not be affected either. However, +if your system is configured for full collision protection +(FEATURES=collision-protect), it will be necessary to manually remove those +links + + rm -i /usr/lib{,64}/libOpenCL.so* + +before running the upgrade. diff --git a/metadata/news/2020-04-22-python3-7/2020-04-22-python3-7.en.txt b/metadata/news/2020-04-22-python3-7/2020-04-22-python3-7.en.txt new file mode 100644 index 000000000000..c933ca6259e9 --- /dev/null +++ b/metadata/news/2020-04-22-python3-7/2020-04-22-python3-7.en.txt @@ -0,0 +1,70 @@ +Title: Python 3.7 to become the default target +Author: Michał Górny <mgorny@gentoo.org> +Posted: 2020-04-22 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-lang/python:3.6 +Display-If-Installed: dev-lang/python:3.7 + +On 2020-05-06 (or later), Python 3.7 will replace Python 3.6 as one +of the default Python targets for Gentoo systems. The new default +values will be: + + PYTHON_TARGETS="python2_7 python3_7" + PYTHON_SINGLE_TARGET="python3_7" + +If you have not overriden these variables on your system, then your +package manager will switch to the new targets immediately. In order +to avoid dependency conflicts, please clean stray packages up +and rebuild/upgrade all packages with USE flag changes after the change, +e.g.: + + emerge --depclean + emerge -1vUD @world + emerge --depclean + +Please note that during the system upgrade some of the package +dependencies may temporarily become missing. While this should not +affect programs that are already fully loaded, it may cause ImportErrors +when starting Python scripts or loading additional modules (only scripts +running Python 3.6 are affected). + +In order to improve stability of the upgrade, you may choose to +temporarily enable both targets, i.e. set in /etc/portage/package.use +or its equivalent: + + */* PYTHON_TARGETS: python3_6 python3_7 + */* PYTHON_SINGLE_TARGET: -* python3_6 + +This will cause the dependencies to include both Python 3.6 and 3.7 +support whenever possible, throughout the next system upgrade. Once all +packages are updated, you can restart your scripts, remove the setting +and start another upgrade in order to cleanly remove Python 3.6. + +There are still some Gentoo packages that do not support Python 3.7. +We will be pushing updates to these packages as time permits. However, +some of them will probably be removed instead. + +If you would like to postpone the switch to Python 3.7, you can copy +the current value of PYTHON_TARGETS and/or PYTHON_SINGLE_TARGET +to /etc/portage/package.use or its equivalent: + + */* PYTHON_TARGETS: -python3_7 python3_6 + */* PYTHON_SINGLE_TARGET: -* python3_6 + +If you would like to migrate your systems earlier, you can do +the opposite. Note that if you are running ~arch, you may want to go +straight for Python 3.8 at this point. + +Please note that this switch is long overdue. Python 3.6 is no longer +receiving bug fixes. Its planned end-of-life is 2021-12-23 but we will +probably remove it earlier than that. [1] + +All above snippets assume using package.use to control USE flags. +If you still have make.conf entries for these targets, you need +to remove them. While using make.conf is possible, it is strongly +discouraged as it does not respect package defaults. The latter +can help you keep some of Python 3.6 packages without the need to +explicitly toggle flags per-package. + +[1] https://devguide.python.org/#status-of-python-branches diff --git a/metadata/news/2020-06-23-upgrade-to-sys-libs_pam-1_4_0/2020-06-23-upgrade-to-sys-libs_pam-1_4_0.en.txt b/metadata/news/2020-06-23-upgrade-to-sys-libs_pam-1_4_0/2020-06-23-upgrade-to-sys-libs_pam-1_4_0.en.txt new file mode 100644 index 000000000000..0c77c98637ba --- /dev/null +++ b/metadata/news/2020-06-23-upgrade-to-sys-libs_pam-1_4_0/2020-06-23-upgrade-to-sys-libs_pam-1_4_0.en.txt @@ -0,0 +1,28 @@ +Title: sys-libs/pam-1.4.0 upgrade +Author: Mikle Kolyada <zlogene@gentoo.org> +Content-Type: text/plain +Posted: 2020-06-23 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-libs/pam +Display-If-Installed: sys-auth/pambase + +Starting with the 1.4.0 release [1], we don't offer these modules anymore: + +* pam_tally and pam_tally2 have been deprecated and replaced + by the pam_faillock module +* pam_cracklib has been deprecated and replaced + by the pam_passwdqc module + +These changes affected our basic PAM stack configuration. + +You only need to take action if: +* you made manual changes to the PAM stack, or +* you use FEATURES="-config-protect-if-modified" option + +If this applies to you, please make sure to either run the etc-update or +dispatch-conf command in order to sync your configuration. + +Failure to do this may result in your system becoming inaccessible. + +[1] - https://github.com/linux-pam/linux-pam/releases/tag/v1.4.0 diff --git a/metadata/news/2020-06-24-xorg-server-dropping-default-suid/2020-06-24-xorg-server-dropping-default-suid.en.txt b/metadata/news/2020-06-24-xorg-server-dropping-default-suid/2020-06-24-xorg-server-dropping-default-suid.en.txt new file mode 100644 index 000000000000..b752bb720ede --- /dev/null +++ b/metadata/news/2020-06-24-xorg-server-dropping-default-suid/2020-06-24-xorg-server-dropping-default-suid.en.txt @@ -0,0 +1,32 @@ +Title: xorg-server dropping default suid +Author: Piotr Karbowski <slashbeast@gentoo.org> +Posted: 2020-06-24 +Revision: 3 +News-Item-Format: 2.0 +Display-If-Installed: x11-base/xorg-server + +Starting 2020-07-15, stable keyworded x11-base/xorg-server will default +to using the logind interface instead of suid by default. resulting in +better security by default through running the server as a regular user +instead of root. However, this will require our users to use a logind +provider such as elogind or systemd. The systemd users and those who are +not using systemd but use desktop profiles can stop reading here, as +they already have a logind provider enabled. + +Others, who have neither systemd or desktop profiles enabled will be +required to globally enable 'elogind' USE flag and update the system + + # emerge --newuse @world + +Afterwards, one will need to re-login, so the PAM can assign a seat. One +can confirm that a seat has been assigned upon login by running: + + $ loginctl user-status + +Users who do not wish to use logind interface or have rare hardware that +does not use KMS and because of that, require root privileges to +operate, can manually re-enable 'suid' and disable 'elogind' USE flags +in order to preserve the previous behavior. However, please note that +this is heavily discouraged to run X server as root due to security +reasons. The 'suid' USE flag will remain as optional opt-in for the need +of legacy hardware. diff --git a/metadata/news/2020-09-06-riscv-multilib-going-away/2020-09-06-riscv-multilib-going-away.en.txt b/metadata/news/2020-09-06-riscv-multilib-going-away/2020-09-06-riscv-multilib-going-away.en.txt new file mode 100644 index 000000000000..7f285c864b10 --- /dev/null +++ b/metadata/news/2020-09-06-riscv-multilib-going-away/2020-09-06-riscv-multilib-going-away.en.txt @@ -0,0 +1,21 @@ +Title: riscv multilib profile is going away +Author: Andreas K. Hüttel <dilfridge@gentoo.org> +Posted: 2020-09-06 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Profile: default/linux/riscv/17.0/rv64gc + +The Gentoo RISC-V team is discontinuing the riscv64 multilib stages and +profile. The main reason for this is that with the upcoming introduction +of riscv32 a multilib stage would contain both 32bit and 64bit binaries, +and so far no hardware exists that is able to run both and thus update +the stage or installation (unless you use qemu). + +Please switch to the rv64gc/lp64d profile. This is done by +* selecting default/linux/riscv/17.0/rv64gc/lp64d with eselect profile +* rebuilding gcc + emerge -1 sys-devel/gcc +* and then rebuilding your system + emerge -ev @world + +The default/linux/riscv/17.0/rv64gc profile will stop functioning soon. diff --git a/metadata/news/2020-09-28-python-2-7-cleanup/2020-09-28-python-2-7-cleanup.en.txt b/metadata/news/2020-09-28-python-2-7-cleanup/2020-09-28-python-2-7-cleanup.en.txt new file mode 100644 index 000000000000..5a6e9bc89cf0 --- /dev/null +++ b/metadata/news/2020-09-28-python-2-7-cleanup/2020-09-28-python-2-7-cleanup.en.txt @@ -0,0 +1,59 @@ +Title: Python 2.7 cleanup is progressing +Author: Michał Górny <mgorny@gentoo.org> +Posted: 2020-09-28 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-lang/python:2.7 + +Python 2.7 has reached its end-of-life by 2019-12-31, and many projects +have removed Python 2 support since. During the last few months we have +been working hard to migrate Gentoo to Python 3, and we have finally +reached the point making it possible for the vast majority of our users +to run a system free of Python 2.7 packages (except for the interpreter +itself). + +The few remaining high profile packages (e.g. dev-python/cython) +are preserving Python 2.7 only for a very few uncommon packages. +For this reason, we have decided to create new revisions of them having +Python 2.7 removed. If you do not need Python 2.7 there, your package +manager should upgrade these packages to the new revisions. + +Please note that you may need to manually uninstall any Python 2.7 +packages installed from third-party repositories and/or run `emerge +--depclean` first to remove orphan packages. The recommended process +for Portage users is: + + emerge --depclean + emerge -vDuU @world + emerge --depclean + +Please note that the Python 2.7 interpreter (without additional Python +packages) remains necessary to build a few high profile packages, +in particular Chromium, Mozilla software and PyPy. If you build either +of these packages from source, you will not be able to permanently +remove Python 2.7 from your system. + +We are going to preserve CPython 2.7 (and PyPy2.7) for as long +as necessary and provide security fixes to the best of our ability. +However, please note that we are not able to dedicate resources to +auditing Python 2.7's code and with little community interest in that, +it should be considered potentially vulnerable. + +If your projects still rely on Python 2.7, we would like to once again +encourage you to migrate them to Python 3. However, if you really need +to run them, we suggest using a virtualenv. To create a new Python 2.7 +environment, install dev-python/virtualenv and use the following option: + + virtualenv -p /usr/bin/python2.7 ... + +To create a PyPy2.7 environment: + + virtualenv -p /usr/bin/pypy ... + +Modern versions of pip should be able to automatically select older +versions of packages that still support Python 2.7. Please note that +these versions are generally no longer supported. They can be buggy, +vulnerable or simply incompatible with one another. + +Please do not forget to add dev-lang/python:2.7 to your @world set +or it may get depcleaned once all package dependencies are gone. diff --git a/metadata/news/2020-10-06-k8s-split-packages/2020-10-06-k8s-split-packages.en.txt b/metadata/news/2020-10-06-k8s-split-packages/2020-10-06-k8s-split-packages.en.txt new file mode 100644 index 000000000000..9ef5a9a1c519 --- /dev/null +++ b/metadata/news/2020-10-06-k8s-split-packages/2020-10-06-k8s-split-packages.en.txt @@ -0,0 +1,26 @@ +Title: kubernetes Split Packages Returning +Author: William Hubbs <williamh@gentoo.org> +Posted: 2020-10-06 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-cluster/kubernetes + +In order to fix the ability to upgrade kubernetes components separately, +the kubernetes split packages are returning [1]. + +Starting with kubernetes 1.17.12, 1.18.9 and 1.19.2, you will need to +install the following packages in the appropriate configuration for +your cluster. + +sys-cluster/kubeadm +sys-cluster/kube-apiserver +sys-cluster/kube-controller-manager +sys-cluster/kubectl +sys-cluster/kubelet +sys-cluster/kube-proxy +sys-cluster/kube-scheduler + +Once the split packages are stabilized, sys-cluster/kubernetes will be +masked and removed. + +[1] https://bugs.gentoo.org/741572 diff --git a/metadata/news/2020-12-26-most-stable-hppa-keywords-removed/2020-12-26-most-stable-hppa-keywords-removed.en.txt b/metadata/news/2020-12-26-most-stable-hppa-keywords-removed/2020-12-26-most-stable-hppa-keywords-removed.en.txt new file mode 100644 index 000000000000..872464a00410 --- /dev/null +++ b/metadata/news/2020-12-26-most-stable-hppa-keywords-removed/2020-12-26-most-stable-hppa-keywords-removed.en.txt @@ -0,0 +1,15 @@ +Title: Most stable hppa keywords removed +Author: Matt Turner <mattst88@gentoo.org> +Posted: 2020-12-26 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Keyword: hppa + +The Gentoo/HPPA team no longer thinks that the time invested in +package stabilization is warranted for the small number of users on +HPPA. As a result, we will drop most "hppa" keywords to "~hppa" on +2020-12-31. Around 850 packages will retain their stable keywords. + +Users need not make any changes to their systems—other than perhaps +adding some entries to their package.accept_keywords file. The +Gentoo/HPPA team has no plans to remove support for the architecture. diff --git a/metadata/news/2021-01-05-libressl-support-discontinued/2021-01-05-libressl-support-discontinued.en.txt b/metadata/news/2021-01-05-libressl-support-discontinued/2021-01-05-libressl-support-discontinued.en.txt new file mode 100644 index 000000000000..713d1df9abe6 --- /dev/null +++ b/metadata/news/2021-01-05-libressl-support-discontinued/2021-01-05-libressl-support-discontinued.en.txt @@ -0,0 +1,71 @@ +Title: LibreSSL support discontinued +Author: Michał Górny <mgorny@gentoo.org> +Posted: 2021-01-05 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-libs/libressl + +Starting 2021-02-01, Gentoo will discontinue supporting +dev-libs/libressl as an alternative to dev-libs/openssl. While it will +still be possible for expert users to use LibreSSL on their systems, +we are only going to provide support for OpenSSL-based systems. Most +importantly, we are no longer going to maintain downstream patches for +LibreSSL support -- it will rely on either package upstreams merging +such patches themselves, or LibreSSL upstream finally working towards +better OpenSSL compatibility. + +On 2021-02-01, we will mask the relevant USE flags and packages. If you +wish to continue using LibreSSL, you will be able to undo these masks +for the time being. However, as packages drop patching for LibreSSL +and the library is eventually removed from ::gentoo, it will become +necessary to use the user-maintained LibreSSL overlay [1]. As long-term +support for LibreSSL is not guaranteed, we recommend switching +to OpenSSL instead. More information on removal can be found +on the relevant bug [2]. + +To switch before the aforementioned date, remove 'libressl' from your +USE flags and CURL_SSL targets. Afterwards, it is recommended to +prefetch all the necessary distfiles before proceeding with the system +upgrade, in case wget(1) becomes broken in the process: + + emerge --fetchonly dev-libs/openssl net-misc/wget + emerge --fetchonly --deep --changed-use @world + +A --changed-use @world upgrade should automatically cause LibreSSL +to be replaced by OpenSSL, and all affected packages to be rebuilt: + + emerge --deselect dev-libs/libressl + emerge --changed-use --deep @world + + +LibreSSL has been forked off OpenSSL in 2014 to address a number of +problems with the original package. However, since then OpenSSL +development gained speed and the original reasons for the fork no longer +apply. Furthermore, LibreSSL started to repeatedly fall behind +and cause growing compatibility problems. While initially these +problems were related to packages using old/insecure OpenSSL APIs, today +they are mostly related to LibreSSL missing newer OpenSSL APIs +(yet declaring false compatibility with newer OpenSSL versions). + +With the little testing it gets, our developers and users had to put +a significant effort into fixing upstream packages. In some cases +(e.g. Qt), upstream has explicitly refused to support LibreSSL, forcing +us to maintain the patches forever. This in turn means that +security fixes, regular version bumps or end-user system upgrades are +often delayed because of necessary LibreSSL patching. What is even +worse, major runtime issues managed to sneak in that broke production +systems running LibreSSL in the past. + +To the best of our knowledge, the only benefit LibreSSL has over OpenSSL +right now is the additional libtls library. For this reason, we have +packaged dev-libs/libretls which is a port of this library that links +to OpenSSL. + +All these issues considered, we came to the conclusion that OpenSSL +should remain the only supported production option for Gentoo systems. +While the flexibility of Gentoo should make it possible to keep using +LibreSSL going forward, the effort necessary to provide first-class +official support for LibreSSL has proven to outweigh the benefit. + +[1] https://gitweb.gentoo.org/repo/proj/libressl.git/tree/README.md +[2] https://bugs.gentoo.org/762847 diff --git a/metadata/news/2021-01-30-display-manager-init/2021-01-30-display-manager-init.en.txt b/metadata/news/2021-01-30-display-manager-init/2021-01-30-display-manager-init.en.txt new file mode 100644 index 000000000000..30bbfd82688b --- /dev/null +++ b/metadata/news/2021-01-30-display-manager-init/2021-01-30-display-manager-init.en.txt @@ -0,0 +1,63 @@ +Title: New OpenRC Display Manager Initializer Scripts +Author: Aisha Tammy <gentoo@aisha.cc> +Author: Andreas Sturmlechner <asturm@gentoo.org> +Posted: 2021-01-30 +Revision: 6 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/openrc + +There has been a refactoring of the old 'xdm' init script into a new +script called 'display-manager', provided by a new package that will +be introduced by your @world update routine as a dependency of +x11-base/xorg-server-1.20.10-r1: + + gui-libs/display-manager-init + +The package is now in ~arch and will be available to stable users +starting with 2nd March 2021. [1] + +Its purpose is to provide the same startup mechanism for your chosen +display manager (like GDM, SDDM etc. [2]) as xdm did previously, but +without depending on x11-base/xorg-server. This is necessary to +support new DMs that no longer depend on Xorg. + +Existing settings from /etc/conf.d/xdm will be migrated to new +/etc/conf.d/display-manager config, however after installation it is +vital not to forget to run either `etc-update` or `dispatch-conf`. +Afterwards check that /etc/conf.d/display-manager contains the +desired value for DISPLAYMANAGER. + +The old 'xdm' init script is no longer supported and henceforth +removed from x11-base/xorg-server-1.20.10-r1, so it is imperative that +you switch from xdm to display-manager service in default runlevel: + + # rc-update del xdm default + # rc-update add display-manager default + +The changes are complete and on the next reboot, 'display-manager' +will start your chosen DM. + +To switch to the new script without rebooting, run the following +commands in a tty: + + # rc-service xdm stop + # rc-service display-manager start + +Finally, the following action is necessary *ONLY* if you are running + a) a DM (and rest of system) without Xorg + b) a DM from an overlay, to make sure display-manager persists + + # emerge --noreplace gui-libs/display-manager-init + + +[1] To make this change *now*, and proceed with this news item already, +stable users would need to add the following entries to +/etc/portage/package.accept_keywords [3] and update @world: + + ~sys-apps/sysvinit-2.98 + ~x11-apps/xinit-1.4.1 + ~x11-base/xorg-server-1.20.10 + ~gui-libs/display-manager-init-1.0 + +[2] https://wiki.gentoo.org/wiki/Display_manager +[3] https://wiki.gentoo.org/wiki//etc/portage/package.accept_keywords diff --git a/metadata/news/2021-01-30-python-preference-to-follow-python-targets/2021-01-30-python-preference-to-follow-python-targets.en.txt b/metadata/news/2021-01-30-python-preference-to-follow-python-targets/2021-01-30-python-preference-to-follow-python-targets.en.txt new file mode 100644 index 000000000000..dbdf2a7bdd34 --- /dev/null +++ b/metadata/news/2021-01-30-python-preference-to-follow-python-targets/2021-01-30-python-preference-to-follow-python-targets.en.txt @@ -0,0 +1,48 @@ +Title: Python preference to follow PYTHON_TARGETS +Author: Michał Górny <mgorny@gentoo.org> +Posted: 2021-01-30 +Revision: 1 +News-Item-Format: 2.0 + +On 2021-02-01 stable users will switch to a new method of updating +the preferred Python versions that employs the configuration update +mechanism in order to follow PYTHON_TARGETS. We will also deprecate +app-eselect/eselect-python, and it will stop being installed by default +after 2021-07-01. If you wish to use the newest Python version present +in your PYTHON_TARGETS, you only have to accept configuration changes. +If you wish to customize the behavior, read on. + +Since 2017, /usr/bin/python and the related non-versioned symlinks +are wrapped through dev-lang/python-exec. The list of preferred Python +implementations is stored in /etc/python-exec/python-exec.conf and/or +per-program /etc/python-exec/<basename>.conf configuration files. +To preserve backwards compatibility, app-eselect/eselect-python remained +a wrapper that updated this file. + +However, this mechanism alone has proven inconvenient to end users who +had to update python-exec.conf whenever the default PYTHON_TARGETS +changed. Thanks to the fallback logic, this was not a major problem +for software installed via Gentoo packages that always ensure that +a supported implementation is used. However, users have reported that +whenever the preference for /usr/bin/python mismatched their +PYTHON_TARGETS, their custom scripts would break due to unsatisfied +dependencies. This does not follow the principle of least surprise. + +For this reason, we have decided to change the default python-exec +configuration to match PYTHON_TARGETS by default, in the eclass +preference order, that is from the newest CPython version to oldest, +with alternative Python implementations coming afterwards. This change +will be propagated via the configuration protection mechanism whenever +dev-lang/python-exec-conf is installed or rebuilt due to PYTHON_TARGETS +changes. This will permit the users to interactively confirm +the updates. + +If the new default is not correct for you, please use your preferred +configuration update tool to discard or edit the new configuration file. + +Furthermore, dev-lang/python will no longer attempt to automatically +update the Python interpreter preference, or pull in eselect-python +automatically. If you wish to continue using it, please install/record +it explicitly to ensure that it is not unmerged, e.g.: + + emerge -n app-eselect/eselect-python diff --git a/metadata/news/2021-01-30-python-preference-to-follow-python-targets/2021-01-30-python-preference-to-follow-python-targets.ru.txt b/metadata/news/2021-01-30-python-preference-to-follow-python-targets/2021-01-30-python-preference-to-follow-python-targets.ru.txt new file mode 100644 index 000000000000..b09918897af7 --- /dev/null +++ b/metadata/news/2021-01-30-python-preference-to-follow-python-targets/2021-01-30-python-preference-to-follow-python-targets.ru.txt @@ -0,0 +1,49 @@ +Title: Предпочтения Python будут следовать за PYTHON_TARGETS +Author: Michał Górny <mgorny@gentoo.org> +Translator: Alexey Sokolov <alexey+gentoo@asokolov.org> +Posted: 2021-01-30 +Revision: 1 +News-Item-Format: 2.0 + +1 февраля 2021 пользователи стабильной ветки перейдут на новый метод обновления +предпочтительной версии Python, который будет использовать значение переменной +PYTHON_TARGETS и применять механизм обновления конфигураций. Также мы +объявляем app-eselect/eselect-python устаревшим и по умолчанию перестанем его +устанавливать. Если вы хотите использовать самую новую версию Python из +указанных в PYTHON_TARGETS, вам надо только принять изменения конфигурации. +Если же вам нужно настроить индивидуальное поведение, продолжайте читать. + +С 2017 года /usr/bin/python и тому подобные символические ссылки без версии +являются обёртками с помощью dev-lang/python-exec. Список предпочтительных +реализаций Python хранится в /etc/python-exec/python-exec.conf и/или в +/etc/python-exec/<программа>.conf для программ с конфигурацией не по умолчанию. +Для обратной совместимости app-eselect/eselect-python остался обёрткой, которая +обновляла этот файл. + +Однако сам по себе этот механизм оказался неудобен пользователям, которым +теперь приходилось обновлять python-exec.conf каждый раз, когда менялась +переменная PYTHON_TARGETS. Благодаря логике запасных вариантов это не было +большой проблемой для программ, установленных из репозитория Gentoo, т.к. они +гарантируют использование поддерживаемой реализации Python. Но пользователи +сообщали, что, когда предпочтение для /usr/bin/python не совпадало с их +PYTHON_TARGETS, из-за неудовлетворённых зависимостей ломались пользовательские +программы, что противоречит принципу наименьшего удивления. + +Поэтому мы решили изменить стандартную настройку python-exec, теперь она будет +совпадать с PYTHON_TARGETS в порядке предпочтения, используемым eclass'ом: +сначала все CPython, начиная с новейшей версии и заканчивая старейшей, затем +другие реализации Python. Это изменение будет установлено в систему с помощью +механизма защиты конфигураций каждый раз при установке или пересборке +dev-lang/python-exec-conf из-за изменения PYTHON_TARGETS. При этом у +пользователей будет возможность интерактивно подтвердить данные изменения. + +Если новые настройки вам не подходят, пожалуйста, используйте ваш любимый +инструмент обновления конфигурации, чтобы отбросить изменения или +отредактировать новый файл. + +Более того, dev-lang/python больше не будет пытаться автоматически обновить +предпочтительную версию Python и больше не будет автоматически затягивать +eselect-python. Если вы хотите продолжать его использовать, пожалуйста, +установите его вручную, чтобы он не удалился: + + emerge -n app-eselect/eselect-python diff --git a/metadata/news/2021-05-04-exim-transports-disallow-tainted/2021-05-04-exim-transports-disallow-tainted.en.txt b/metadata/news/2021-05-04-exim-transports-disallow-tainted/2021-05-04-exim-transports-disallow-tainted.en.txt new file mode 100644 index 000000000000..f16e485b15d6 --- /dev/null +++ b/metadata/news/2021-05-04-exim-transports-disallow-tainted/2021-05-04-exim-transports-disallow-tainted.en.txt @@ -0,0 +1,28 @@ +Title: Exim>=4.94 transports: tainted not permitted +Author: Fabian Groffen <grobian@gentoo.org> +Posted: 2021-05-04 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: mail-mta/exim + +The Message Transfer Agent Exim disallows tainted variables in transport +configurations since version 4.94. Existing exim.conf configurations +in /etc/exim need to be reviewed for breakage prior to upgrading to + >=mail-mta/exim-4.94 to avoid error conditions at runtime. + +Since the release of Exim-4.94, transports refuse to use tainted data in +constructing a delivery location. If you use this in your transports, +your configuration will break, causing errors and possible downtime. + +Particularly, the use of $local_part in any transport, should likely be +updated with $local_part_data. Check your local_delivery transport, +which historically used $local_part. + +Unfortunately there is not much documentation on "tainted" data for +Exim[1], and to resolve this, non-official sources need to be used, such +as [2] and [3]. + + +[1] https://lists.exim.org/lurker/message/20201109.222746.24ea3904.en.html +[2] https://mox.sh/sysadmin/tainted-filename-errors-in-exim-4.94/ +[3] https://jimbobmcgee.wordpress.com/2020/07/29/de-tainting-exim-configuration-variables/ diff --git a/metadata/news/2021-05-05-python3-9/2021-05-05-python3-9.en.txt b/metadata/news/2021-05-05-python3-9/2021-05-05-python3-9.en.txt new file mode 100644 index 000000000000..f42ec914b09e --- /dev/null +++ b/metadata/news/2021-05-05-python3-9/2021-05-05-python3-9.en.txt @@ -0,0 +1,119 @@ +Title: Python 3.9 to become the default on 2021-06-01 +Author: Michał Górny <mgorny@gentoo.org> +Posted: 2021-05-05 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-lang/python:3.7 +Display-If-Installed: dev-lang/python:3.8 + +We are planning to switch the default Python target of Gentoo systems +on 2021-06-01, from Python 3.8 to Python 3.9. If you have not changed +the values of PYTHON_TARGETS or PYTHON_SINGLE_TARGET, the change will +have immediate effect on your system and the package manager will try +to switch automatically on the next upgrade following the change. + +If you did change the values, prefer a safer approach or have problems +with the update, read on. + +Please note that the default upgrade method switches packages to the new +Python versions as they are rebuilt. This means that all interdependent +packages have to support the new version for the upgrade to proceed, +and that some programs may temporarily fail to find their dependencies +throughout the upgrade (although programs that are already started +are unlikely to be affected). + + +If you have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared +in make.conf, please remove these declarations as they will interfere +with the package.use samples provided below. Using make.conf for Python +targets is discouraged as it prevents package defaults from applying +when necessary. This news item assumes using /etc/portage/package.use +or your package manager's equivalent file for configuration. + + +At this point, you have a few configuration options to choose from: + +1. If you wish Python upgrades to apply automatically, you can remove + PYTHON_TARGETS and PYTHON_SINGLE_TARGET declarations. When + the defaults change, your package manager should handle the upgrade + automatically. However, you may still need to run the update + commands if any problems arise. + +2. If you wish to defer the upgrade for the time being, you can + explicitly set the old values in package.use. + +3. If you wish to force the upgrade earlier, you can explicitly set + the new values and run the upgrade commands. + +4. If you wish to use a safer approach (i.e. less likely to temporarily + break packages during the upgrade), you can perform a multi-step + upgrade as outlined below. + +5. Finally, you can use an arbitrary combination of PYTHON_TARGETS + and PYTHON_SINGLE_TARGET. + + +Deferring the upgrade +===================== +To defer the upgrade, explicitly set the old targets: + + */* PYTHON_TARGETS: -* python3_8 + */* PYTHON_SINGLE_TARGET: -* python3_8 + +This will enforce Python 3.8 and block any future updates. However, +please note that this solution will only be suitable for a few more +months and you will eventually need to perform the migration. + + +Forcing the upgrade +=================== +To force the upgrade earlier, explicitly set Python 3.9 targets: + + */* PYTHON_TARGETS: -* python3_9 + */* PYTHON_SINGLE_TARGET: -* python3_9 + +However, it is important to remember to remove this after the defaults +change, as it will interfere with the automatic switch to the next +Python version in the future. + + +Safer upgrade procedure +======================= +A safer approach is to add Python 3.9 support to your system first, +and only then remove Python 3.8. However, note that involves two +rebuilds of all the affected packages, so it will take noticeably +longer. + +First, enable both Python 3.8 and Python 3.9, and then run the upgrade +commands: + + */* PYTHON_TARGETS: -* python3_8 python3_9 + */* PYTHON_SINGLE_TARGET: -* python3_8 + +Then switch PYTHON_SINGLE_TARGET and run a second batch of upgrades: + + */* PYTHON_TARGETS: -* python3_8 python3_9 + */* PYTHON_SINGLE_TARGET: -* python3_9 + +Finally, switch to the final version and upgrade: + + */* PYTHON_TARGETS: -* python3_9 + */* PYTHON_SINGLE_TARGET: -* python3_9 + +You may wish to remove the target overrides after the defaults switch. +Alternatively, you can keep them to block the next automatic upgrade +to Python 3.10, and upgrade manually then. + + +Upgrade commands +================ +The Python 3.8 cleanup requires that Python 3.8 is removed from complete +dependency trees in batch. If some of the installed packages using +an older Python version are not triaged for the upgrade, the package +manager will throw dependency conflicts. This makes it important that +the upgrade is carried via a --deep --changed-use @world upgrade, +as well as that any stray packages are removed prior to it, e.g.: + + emerge --depclean + emerge -1vUD @world + emerge --depclean diff --git a/metadata/news/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt b/metadata/news/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt new file mode 100644 index 000000000000..035c6e237ac8 --- /dev/null +++ b/metadata/news/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt @@ -0,0 +1,121 @@ +Title: Python 3.9 станет базовым с 2021-06-01 +Author: Michał Górny <mgorny@gentoo.org> +Translator: Alexey Sokolov <alexey+gentoo@asokolov.org> +Posted: 2021-05-05 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-lang/python:3.7 +Display-If-Installed: dev-lang/python:3.8 + +1 июня 2021 года мы собираемся переключить Python target, используемый +по умолчанию на системах Gentoo, с версии 3.8 на версию 3.9. +Если вы не меняли значения переменных PYTHON_TARGETS или +PYTHON_SINGLE_TARGET, то упомянутое изменение затронет систему сразу +и пакетный менеджер попытается переключиться на новый Python target +автоматически при следующем обновлении системы. + +Если вы изменили значения этих переменных, предпочитаете более +безопасный подход или при обновлении возникли проблемы, то +продолжайте читать далее. + +Пожалуйста, обратите внимание, что метод обновления по умолчанию +переключает пакеты на новую версию Python после их пересборки. +Это означает, что все зависящие друг от друга пакеты должны поддерживать +новую версию Python для продолжения обновления и некоторые программы +временно могут не находить свои зависимости во время обновления +(однако, запущенные программы, вероятно, не будут подвержены проблеме). + +Если переменные PYTHON_TARGETS или PYTHON_SINGLE_TARGET объявлены +в вашем make.conf файле, пожалуйста, удалите их, так как они будут +конфликтовать с представленными ниже примерами конфигурации package.use. +Мы не рекомендуем использовать файл make.conf для задания значений +переменных Python target, так как это препятствует применению этих +значений по умолчанию для пакетов, когда это необходимо. В этой новости +мы предполагаем, что вы используете файл /etc/portage/package.use +или ваш эквивалент этого файла конфигурации пакетного менеджера. + +С этого момента у вас есть выбор из следующих вариантов настройки: + +1. Если вы хотите, чтобы Python обновлялся автоматически, вы можете + удалить объявленные переменные PYTHON_TARGETS и PYTHON_SINGLE_TARGET. + Когда их значения по умолчанию изменятся, пакетный менеджер должен + самостоятельно всё обновить. Но если возникнут проблемы, вам всё ещё + может понадобиться запустить команды обновления. + +2. Если вы хотите пока отложить обновление, вы можете явно указать + старые значения в файле package.use. + +3. Если вы хотите обновиться раньше, вы можете явно задать новые + значения и запустить команды обновления. + +4. Если вы хотите использовать более безопасный подход (т.е. с меньшей + вероятностью временной поломки пакетов во время обновления), + вы можете выполнить последовательное обновление, описанное ниже. + +5. Наконец, вы можете произвольным образом комбинировать значения + переменных PYTHON_TARGETS и PYTHON_SINGLE_TARGET. + + +Откладывание обновления +======================= +Чтобы отложить обновление, явно укажите старые значения: + + */* PYTHON_TARGETS: -* python3_8 + */* PYTHON_SINGLE_TARGET: -* python3_8 + +Это заставит систему использовать Python 3.8 и предотвратит последующие +обновления. Однако, учтите, что такое решение применимо только +в течение несколько месяцев и в конце концов вам всё-таки придётся +провести обновление. + + +Принудительное обновление +========================= +Чтобы обновиться до Python 3.9 раньше, явно укажите новые значения: + + */* PYTHON_TARGETS: -* python3_9 + */* PYTHON_SINGLE_TARGET: -* python3_9 + +При этом важно не забыть удалить эти строки после изменения значений +по умолчанию, иначе они помешают последующим автоматическим обновлениям +на следующие версии Python. + + +Процедура безопасного обновления +================================ +Более безопасный подход такой: сначала добавляется в систему поддержка +Python 3.9, а затем удаляется поддержка Python 3.8. Однако, учтите, +что все затронутые пакеты будут пересобраны дважды, что заметно дольше. + +Сначала включите Python 3.8 и Python 3.9 и запустите команды обновления: + + */* PYTHON_TARGETS: -* python3_8 python3_9 + */* PYTHON_SINGLE_TARGET: -* python3_8 + +Затем замените PYTHON_SINGLE_TARGET и ещё раз запустите обновление: + + */* PYTHON_TARGETS: -* python3_8 python3_9 + */* PYTHON_SINGLE_TARGET: -* python3_9 + +Наконец, переключитесь на окончательную версию и запустите обновление: + + */* PYTHON_TARGETS: -* python3_9 + */* PYTHON_SINGLE_TARGET: -* python3_9 + +После смены значений по умолчанию вы можете удалить эти настройки. +Или же вы можете оставить их, предотвращая автоматическое обновление +до Python 3.10, и позже обновиться вручную. + + +Команды обновления +================== +Для очистки системы от Python 3.8 требуется удалить его сразу из +всего дерева зависимостей. Если какие-то установленные пакеты, +использующие старую версию Python, не помечены для обновления, +пакетный менеджер покажет ошибки зависимостей. Поэтому важно проводить +обновление с использованием опций --deep --changed-use @world, +а также перед этим удалить все более не требуемые пакеты: + + emerge --depclean + emerge -1vUD @world + emerge --depclean diff --git a/metadata/news/2021-05-14-darktable-drop-x86/2021-05-14-darktable-drop-x86.en.txt b/metadata/news/2021-05-14-darktable-drop-x86/2021-05-14-darktable-drop-x86.en.txt new file mode 100644 index 000000000000..74d557d8df0f --- /dev/null +++ b/metadata/news/2021-05-14-darktable-drop-x86/2021-05-14-darktable-drop-x86.en.txt @@ -0,0 +1,18 @@ +Title: x86 support to be dropped from media-gfx/darktable +Author: Marek Szuba <marecki@gentoo.org> +Posted: 2021-05-14 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: =media-gfx/darktable-2.6.2 + +Since version 3.0.0 media-gfx/darktable officially only supports 64-bit +architectures, and we have observed errors while attempting to build these +versions on x86 - making media-gfx/darktable-2.6.2 the last version to +support this architecture. However the 2.6.x branch of Darktable has not +seen any activity since October 2019 and we have just confirmed with upstream +that all but the latest release branch (3.4.x at the time of writing this) are +not supported. + +In light of the above we have decided to remove media-gfx/darktable-2.6.2 from +the tree, thus dropping x86 support from that package, by 2021-06-15. + diff --git a/metadata/news/2021-05-18-syncthing-tls-incompatibility/2021-05-18-syncthing-tls-incompatibility.en.txt b/metadata/news/2021-05-18-syncthing-tls-incompatibility/2021-05-18-syncthing-tls-incompatibility.en.txt new file mode 100644 index 000000000000..2e5505c01152 --- /dev/null +++ b/metadata/news/2021-05-18-syncthing-tls-incompatibility/2021-05-18-syncthing-tls-incompatibility.en.txt @@ -0,0 +1,16 @@ +Title: >=net-p2p/syncthing-1.17.0 incompatibility warning +Author: Marek Szuba <marecki@gentoo.org> +Posted: 2021-05-18 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: net-p2p/syncthing + +Starting with version 1.17.0, net-p2p/syncthing by default only allows +TLS 1.3 for sync connections - making it impossible to sync with devices +not supporting it, i.e. running Syncthing versions older than 1.3.0. + +If you do require your Syncthing cluster to support TLS 1.2, you will have to +explicitly allow it by enabling the option "insecureAllowOldTLSVersions". +For details see: + +https://docs.syncthing.net/advanced/option-insecure-allow-old-tls-versions.html diff --git a/metadata/news/2021-05-30-deprecate-old-bdb-slots/2021-05-30-deprecate-old-bdb-slots.en.txt b/metadata/news/2021-05-30-deprecate-old-bdb-slots/2021-05-30-deprecate-old-bdb-slots.en.txt new file mode 100644 index 000000000000..b22291eb88fb --- /dev/null +++ b/metadata/news/2021-05-30-deprecate-old-bdb-slots/2021-05-30-deprecate-old-bdb-slots.en.txt @@ -0,0 +1,55 @@ +Title: sys-libs/db old SLOT removal +Author: David Seifert <soap@gentoo.org> +Posted: 2021-05-30 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-libs/db:1 +Display-If-Installed: sys-libs/db:3 +Display-If-Installed: sys-libs/db:4.2 +Display-If-Installed: sys-libs/db:4.3 +Display-If-Installed: sys-libs/db:4.4 +Display-If-Installed: sys-libs/db:4.5 +Display-If-Installed: sys-libs/db:4.6 +Display-If-Installed: sys-libs/db:4.7 +Display-If-Installed: sys-libs/db:5.1 + +On 2021-07-01, we will mask the following Berkeley DB (aka sys-libs/db) +slots for removal from the tree within 90 days (bug #792222): + +- 1 +- 3 +- 4.2 +- 4.3 +- 4.4 +- 4.5 +- 4.6 +- 4.7 +- 5.1 + +You should export your data first before rebuilding any applications +against newer slots of sys-libs/db. + +Furthermore, the Gentoo Base System Team has decided to consider +sys-libs/db a deprecated database backend. What this means for you is +that we will slowly start deprecating optional use of sys-libs/db in +consumers and mask their USE="berkdb" flags with the goal of eventual +removal of berkdb support from those packages. + +Other distros such as Fedora have started a gradual phase-out of +Berkeley DB too, given Oracle's strong-armed approach to community +input and their arguably hostile switch to the AGPLv3 +(https://fedoraproject.org/wiki/Changes/Libdb_deprecated). Furthermore, +Oracle is known for removing critical features from BDB in supposed +patch releases, such as the removal of the client-server architecture +and the SQL API between 18.1.32 and 18.1.40. + +To this end, we will also be removing USE="berkdb" from +profiles/default/linux/make.defaults on 2021-07-01. If you implicitly +depend on profiles enabling optional use of sys-libs/db, you will need +to enable this USE flag yourself. + +From here on, you should be working under the assumption that the +sys-libs/db package will be gone from the Gentoo repository within +**two years** from the time of this news item. If you depend on BDB in +a production environment, we strongly suggest you move to one of the +modern replacements, such as GDBM, SQLite or LMDB. diff --git a/metadata/news/2021-06-20-riscv-20-profile-migration/2021-06-20-riscv-20-profile-migration.en.txt b/metadata/news/2021-06-20-riscv-20-profile-migration/2021-06-20-riscv-20-profile-migration.en.txt new file mode 100644 index 000000000000..ea4c83a44326 --- /dev/null +++ b/metadata/news/2021-06-20-riscv-20-profile-migration/2021-06-20-riscv-20-profile-migration.en.txt @@ -0,0 +1,51 @@ +Title: riscv upgrade to 20.0 profiles +Author: Andreas K. Hüttel <dilfridge@gentoo.org> +Posted: 2021-06-20 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Profile: default/linux/riscv/17.0/rv64gc/lp64d +Display-If-Profile: default/linux/riscv/17.0/rv64gc/lp64d/systemd +Display-If-Profile: default/linux/riscv/17.0/rv64gc/lp64 +Display-If-Profile: default/linux/riscv/17.0/rv64gc/lp64/systemd + +On RISC-V we are switching from two-level library directories (e.g., +/usr/lib64/lp64d) to a more traditional directory architecture. +This is done via the profile upgrade from 17.0 to 20.0 profiles. + +We recommend to re-install from scratch using a 20.0 profile based +stage. 17.0 profiles will be deprecated immediately and removed +in 6 months. + +If you want to upgrade an existing installation, the following +steps should be taken. Please read all commands carefully first and +make sure you understand them, since the procedure is risky. The +commands are given for a lp64d profile; in case of a lp64 profile, +always replace lp64d with lp64. + +# cd /usr/local/lib64 +# cp -av lp64d/. . +# rm -rf lp64d +# ln -s . lp64d + +# cd /usr/lib64 +# cp -av lp64d/. . +# rm -rf lp64d +# ln -s . lp64d + +# cd /lib64 +# cp -av lp64d/. . +# rm -rf lp64d +# sln . lp64d + +Note that the last command uses "sln" instead of "ln -s". + +Then switch from your 17.0 profile to the corresponding 20.0 profile, +either by using "eselect profile" or by manually changing the +/etc/portage/make.profile symlink. + +Next, rebuild all packages: + +# emerge -eav world + +As last step, check if portage has removed any of the symlinks created +above, and if yes, recreate them. diff --git a/metadata/news/2021-06-28-use-pax_kernel-renamed/2021-06-28-use-pax_kernel-renamed.en.txt b/metadata/news/2021-06-28-use-pax_kernel-renamed/2021-06-28-use-pax_kernel-renamed.en.txt new file mode 100644 index 000000000000..49f75400e57b --- /dev/null +++ b/metadata/news/2021-06-28-use-pax_kernel-renamed/2021-06-28-use-pax_kernel-renamed.en.txt @@ -0,0 +1,30 @@ +Title: USE flag 'pax_kernel' to be renamed to 'pax-kernel' +Author: Marek Szuba <marecki@gentoo.org> +Posted: 2021-06-28 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Profile: default/linux/amd64/17.0/hardened +Display-If-Profile: default/linux/amd64/17.0/musl/hardened +Display-If-Profile: default/linux/amd64/17.0/no-multilib/hardened +Display-If-Profile: default/linux/amd64/17.0/uclibc/hardened +Display-If-Profile: default/linux/amd64/17.1/hardened +Display-If-Profile: default/linux/amd64/17.1/no-multilib/hardened +Display-If-Profile: default/linux/arm/17.0/musl/armv6j/hardened +Display-If-Profile: default/linux/arm/17.0/musl/armv7a/hardened +Display-If-Profile: default/linux/arm/17.0/uclibc/armv6j/hardened +Display-If-Profile: default/linux/arm/17.0/uclibc/armv7a/hardened +Display-If-Profile: default/linux/arm64/17.0/musl/hardened +Display-If-Profile: default/linux/powerpc/ppc32/17.0/musl/hardened +Display-If-Profile: default/linux/powerpc/ppc32/17.0/uclibc/hardened +Display-If-Profile: default/linux/ppc/17.0/musl/hardened +Display-If-Profile: default/linux/ppc/17.0/uclibc/hardened +Display-If-Profile: default/linux/ppc64/17.0/musl/hardened +Display-If-Profile: default/linux/ppc64le/17.0/musl/hardened +Display-If-Profile: default/linux/x86/17.0/hardened +Display-If-Profile: default/linux/x86/17.0/uclibc/hardened + +On 2021-07-01 the USE flag 'pax_kernel' will be renamed to 'pax-kernel' +in order to remove the disallowed underscore character. If you use +a PaX-enabled kernel, update your package-manager configuration +accordingly; failure to do so might result in affected packages no longer +functioning on your system. diff --git a/metadata/news/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.en.txt b/metadata/news/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.en.txt new file mode 100644 index 000000000000..16b5596c9978 --- /dev/null +++ b/metadata/news/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.en.txt @@ -0,0 +1,47 @@ +Title: migrating from glibc[crypt] to libxcrypt in ~arch +Author: Andreas K. Hüttel <dilfridge@gentoo.org> +Author: Sam James <sam@gentoo.org> +Posted: 2021-06-30 +Revision: 1 +News-Item-Format: 2.0 + +The implementation of libcrypt.so within glibc has been deprecated +for a long time and will be removed in the near future. + +For this reason, we are following other distributions (where +this has been tested for years already) and switching to the +external libxcrypt implementation, starting with ~arch +installations. + +This will be a regular update, and in nearly all cases you +will not have to take any action and not observe any problems. + +We do recommend, however, that your system is *fully* up +to date first. This is a standard recommendation but in this +specific case, it is useful to have a simplified depgraph +to ensure that Portage is able to smoothly calculate +an upgrade path. + +That is, please take the opportunity to fully upgrade your +systems now, before the migration occurs, to simplify matters. + +This change will occur on 2021-07-14 for ~arch users. Stable +users will update at a later date. + +If for whatever reason you do *not* wish to switch now - +which is only delaying the inevitable - you +need to take the following steps: +* unmask and enable the crypt USE flag of sys-libs/glibc +* mask the system USE flag of sys-libs/libxcrypt +* mask >=virtual/libcrypt-2 + +If you wish to manually migrate now, there are a series +of steps described on the wiki (see below), but the outline is: +* unforce the crypt USE flag of sys-libs/glibc and disable it +* unmask the system and split-usr (if applicable) USE flag of sys-libs/libxcrypt +and enable it +* unmask ~virtual/libcrypt-2 + +For more information, please see: +* https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation +* https://bugs.gentoo.org/699422 diff --git a/metadata/news/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt b/metadata/news/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt new file mode 100644 index 000000000000..d52db1143a5a --- /dev/null +++ b/metadata/news/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt @@ -0,0 +1,47 @@ +Title: Миграция в ~arch с glibc[crypt] на libxcrypt +Author: Andreas K. Hüttel <dilfridge@gentoo.org> +Author: Sam James <sam@gentoo.org> +Translator: Alexey Sokolov <alexey+gentoo@asokolov.org> +Posted: 2021-06-30 +Revision: 1 +News-Item-Format: 2.0 + +Реализация библиотеки libcrypt.so в glibc давно устарела и скоро +будет удалена. + +Прочие дистрибутивы годы назад уже переключились на внешнюю +реализацию под названием libxcrypt. Мы решили последовать их примеру +и тоже переключиться на libxcrypt. Вначале изменения затронут системы +на ~arch. + +Это будет обычное обновление, и, скорее всего, вам не нужно будет +предпринимать никаких действий, и проблем возникнуть не должно. + +Однако, мы рекомендуем сперва *полностью* обновить систему. +Это стандартная рекомендация, но в этом конкретном случае +более простой граф зависимостей поможет portage вычислить +порядок обновлений. + +Так что, чтобы упростить процесс обновления, пожалуйста, +обновите систему сейчас, до начала самой миграции. + +Для пользователей ~arch изменение произойдёт 14 июля 2021, +пользователи стабильной ветки перейдут на libxcrypt позже. + +Если по какой-либо причине вы *не* хотите пока переходить +на libxcrypt (всего лишь отлагая неизбежное), выполните +следующие действия: +* размаскируйте и включите USE-флаг crypt пакета sys-libs/glibc +* замаскируйте USE-флаг system пакета sys-libs/libxcrypt +* замаскируйте >=virtual/libcrypt-2 + +Если вы хотите перейти на libxcrypt уже, точная процедура +описана в wiki (см. ниже), но суть такая: +* принудительно выключите USE-флаг crypt пакета sys-libs/glibc +* размаскируйте USE-флаги system и, если требуется, split-usr + пакета sys-libs/libxcrypt +* размаскируйте ~virtual/libcrypt-2 + +Дополнительные сведения можно найти здесь: +* https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation +* https://bugs.gentoo.org/699422 diff --git a/metadata/news/2021-07-15-opentmpfiles-deprecation/2021-07-15-opentmpfiles-deprecation.en.txt b/metadata/news/2021-07-15-opentmpfiles-deprecation/2021-07-15-opentmpfiles-deprecation.en.txt new file mode 100644 index 000000000000..9f952d4a0208 --- /dev/null +++ b/metadata/news/2021-07-15-opentmpfiles-deprecation/2021-07-15-opentmpfiles-deprecation.en.txt @@ -0,0 +1,69 @@ +Title: systemd-tmpfiles replaces deprecated opentmpfiles +Author: Georgy Yakovlev <gyakovlev@gentoo.org> +Author: Sam James <sam@gentoo.org> +Posted: 2021-07-15 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/opentmpfiles +Display-If-Installed: sys-apps/systemd-tmpfiles + +A tmpfiles [0] implementation provides a generic mechanism to define +the creation of regular files, directories, pipes, and device nodes, +adjustments to their access mode, ownership, attributes, quota +assignments, and contents, and finally their time-based removal. +It is commonly used for volatile and temporary files and directories +such as those located under /run/, /tmp/, /var/tmp/, the API file +systems such as /sys/ or /proc/, as well as some other directories +below /var/. [1] + +On 2021-07-06, the sys-apps/opentmpfiles package was initially masked +due to a root privilege escalation vulnerability (CVE-2017-18925 [2], +bug #751415 [3], issue 4 [4] upstream). + +The severity of this vulnerability is disputed due to the practical +obstacles to its exploitation in any default or supported configuration. + +That said, the use of opentmpfiles is discouraged by its maintainer due +to the unpatched vulnerability and other long-standing bugs [5]. It has +now been declared obsolete in favour of systemd-tmpfiles by opentmpfiles +upstream. + +Users will start seeing their package manager trying to replace +sys-apps/opentmpfiles with sys-apps/systemd-tmpfiles because it is +another provider of virtual/tmpfiles. + +Despite the name, 'systemd-tmpfiles' does not depend on systemd, does +not use dbus, and is just a drop-in replacement for opentmpfiles. It is +a small binary built from systemd source code, but works separately, +similarly to eudev or elogind. It is known to work on both glibc and +musl systems. + +Note that systemd-tmpfiles is specifically for non-systemd systems. It +is intended to be used on an OpenRC system. + +If you wish to selectively test systemd-tmpfiles, follow those steps: + + 1. # emerge --oneshot sys-apps/systemd-tmpfiles + 2. # reboot + 3. # rm /etc/runlevels/boot/opentmpfiles-setup + 4. # rm /etc/runlevels/sysinit/opentmpfiles-dev + +No other steps required. + +If you still wish to use opentmpfiles for the time being, you can unmask [6] +opentmpfiles: + 1. In /etc/portage/package.unmask, add a line: + -sys-apps/opentmpfiles- + 2. # emerge --oneshot sys-apps/opentmpfiles + +Note that opentmpfiles is likely to be removed from gentoo repository +in the future. You may wish to put it in a local overlay instead [7]. + +[0] https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html +[1] https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html +[2] https://nvd.nist.gov/vuln/detail/CVE-2017-18925 +[3] https://bugs.gentoo.org/751415 +[4] https://github.com/OpenRC/opentmpfiles/issues/4 +[5] https://bugs.gentoo.org/741216 +[6] https://wiki.gentoo.org/wiki/Knowledge_Base:Unmasking_a_package +[7] https://wiki.gentoo.org/wiki/Custom_ebuild_repository#Creating_a_local_repository diff --git a/metadata/news/2021-07-16-pulseeffects-easyeffects/2021-07-16-pulseeffects-easyeffects.en.txt b/metadata/news/2021-07-16-pulseeffects-easyeffects/2021-07-16-pulseeffects-easyeffects.en.txt new file mode 100644 index 000000000000..afefdc6e0144 --- /dev/null +++ b/metadata/news/2021-07-16-pulseeffects-easyeffects/2021-07-16-pulseeffects-easyeffects.en.txt @@ -0,0 +1,33 @@ +Title: PulseEffects-5+ are now media-sound/easyeffects +Author: Marek Szuba <marecki@gentoo.org> +Posted: 2021-07-16 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: media-sound/pulseeffects + +Since version 5.0.0, media-sound/pulseeffects have explicitly required +media-video/pipewire rather than just a PulseAudio client (i.e. either +PipeWire or plain media-sound/pulseaudio). Following up on this change, +upstream has decided to rename the project to EasyEffects starting with +version 6.0.0. + +Gentoo will follow the upstream renaming but in a slightly different +fashion: + - versions older than 5.0.0, i.e. ones not depending on + media-video/pipewire, will continue to use the name + media-sound/pulseeffects; + - versions: 5.0.0 and newer, i.e. all requiring media-video/pipewire, + will be available as media-sound/easyeffects. + +media-sound/easyeffects is already available in the tree, and the +remaining PipeWire-dependent versions of media-sound/pulseeffects will +be removed on 2021-07-23. Therefore, PipeWire users of +media-sound/pulseeffects should switch to media-sound/easyeffects by +deselecting the old package and installing the new one, e.g. + +emerge --deselect media-sound/pulseeffects +emerge media-sound/easyeffects + +No action is required of media-sound/pulseeffects users who either use +PulseAudio exclusively or wish to retain the ability to use this +package with both PulseAudio and PipeWire. diff --git a/metadata/news/2021-07-17-new-ppc64-profiles/2021-07-17-new-ppc64-profiles.en.txt b/metadata/news/2021-07-17-new-ppc64-profiles/2021-07-17-new-ppc64-profiles.en.txt new file mode 100644 index 000000000000..63449633166e --- /dev/null +++ b/metadata/news/2021-07-17-new-ppc64-profiles/2021-07-17-new-ppc64-profiles.en.txt @@ -0,0 +1,78 @@ +Title: new ppc64 profiles +Author: Georgy Yakovlev <gyakovlev@gentoo.org> +Posted: 2021-07-17 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/desktop +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/desktop/gnome +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/desktop/gnome/systemd +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/developer + +A new set of ppc64 profiles has been added to the Gentoo +repository in Jan 2020. 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). + +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: + + # 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. 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. + +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 default/linux/ppc64/17.0 + +[at this point you can start using emerge again] + +9. Rebuild the toolchain: + + # emerge -1v sys-devel/gcc:10 + [ repeat for other slots you will be using ] + # emerge -1v sys-devel/binutils + # emerge -1v sys-libs/glibc + +For known issues, please see bugs #506276 [2] and #640184[3] . +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 [4], it applies to PPC64 as well. + +[1] https://gentoo.org/support/news-items/2017-11-30-new-17-profiles.html +[2] https://bugs.gentoo.org/506276 +[3] https://bugs.gentoo.org/640184 +[4] https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout diff --git a/metadata/news/2021-07-20-perl-5_34-upgrade/2021-07-20-perl-5_34-upgrade.en.txt b/metadata/news/2021-07-20-perl-5_34-upgrade/2021-07-20-perl-5_34-upgrade.en.txt new file mode 100644 index 000000000000..bc1baa111ece --- /dev/null +++ b/metadata/news/2021-07-20-perl-5_34-upgrade/2021-07-20-perl-5_34-upgrade.en.txt @@ -0,0 +1,46 @@ +Title: Perl 5.34 upgrade now stable +Author: Sam James <sam@gentoo.org> +Posted: 2021-07-20 +Revision: 1 +News-Item-Format: 2.0 + +The Perl project in Gentoo has begun stabilisation of Perl 5.34 [0] +which is the latest stable version released upstream. + +While the package manager usually handles this upgrade cleanly, +there are some bugs [1][2][3] which affect Portage's dependency resolution +that sometimes mean rebuilds occur in the wrong order - this is +exacerbated by the packaging model used for Perl (but not its fault). + +We therefore recommend the following procedure for users: +1. Sync your tree: +# emerge --sync + +2. Perform a full world upgrade, e.g.: +# emerge -a -uvDU @world --keep-going=y + +3. If any failures occur, please run perl-cleaner --all, then try again: +# perl-cleaner --all + +4. Perform a world upgrade again. + +5. Once complete, depclean: +# emerge -a --depclean + +If the upgrade fails with conflicts, please try --backtrack=1000 or some +other large number. + +Rarely, it may be necessary to perform a one-off installation of a package, +but usually `perl-cleaner` will resolve the issue. If an error message occurs +after running perl-cleaner, try e.g. for a fictional package dev-perl/foo: +# emerge -a --oneshot --verbose dev-perl/foo + +If you have any issues, please consult the standard support channels [4] +(such as our forums or IRC channels) and we will do our best to get your +system working well again. + +[0] https://bugs.gentoo.org/802639 +[1] https://bugs.gentoo.org/592880 +[2] https://bugs.gentoo.org/793992 +[3] https://bugs.gentoo.org/199856 +[4] https://www.gentoo.org/support/ diff --git a/metadata/news/README b/metadata/news/README new file mode 100644 index 000000000000..63cbead22366 --- /dev/null +++ b/metadata/news/README @@ -0,0 +1,7 @@ +Copyright of Gentoo news items is held by their respective authors +and translators. + +All news items committed after 2018-10-21 are licensed under the +Creative Commons Attribution-ShareAlike 4.0 International License. +Visit https://creativecommons.org/licenses/by-sa/4.0/ to view a copy +of this license. |