diff options
Diffstat (limited to 'metadata/news')
79 files changed, 3510 insertions, 0 deletions
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-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-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-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-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-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-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/2021-08-01-tcpd-disabled/2021-08-01-tcpd-disabled.en.txt b/metadata/news/2021-08-01-tcpd-disabled/2021-08-01-tcpd-disabled.en.txt new file mode 100644 index 000000000000..02e18bf15c6f --- /dev/null +++ b/metadata/news/2021-08-01-tcpd-disabled/2021-08-01-tcpd-disabled.en.txt @@ -0,0 +1,68 @@ +Title: USE=tcpd no longer globally enabled +Author: David Seifert <soap@gentoo.org> +Posted: 2021-08-01 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Profile: default/linux/* +Display-If-Installed: net-analyzer/argus-clients[tcpd] +Display-If-Installed: net-ftp/proftpd[tcpd] +Display-If-Installed: app-admin/conserver[tcpd] +Display-If-Installed: app-admin/prelude-manager[tcpd] +Display-If-Installed: app-admin/qpage[tcpd] +Display-If-Installed: app-admin/syslog-ng[tcpd] +Display-If-Installed: app-backup/bacula[tcpd] +Display-If-Installed: app-backup/bareos[tcpd] +Display-If-Installed: app-misc/mosquitto[tcpd] +Display-If-Installed: dev-libs/yaz[tcpd] +Display-If-Installed: gnome-base/gdm[tcpd] +Display-If-Installed: mail-mta/exim[tcpd] +Display-If-Installed: mail-mta/sendmail[tcpd] +Display-If-Installed: media-sound/pulseaudio[tcpd] +Display-If-Installed: net-analyzer/argus[tcpd] +Display-If-Installed: net-analyzer/net-snmp[tcpd] +Display-If-Installed: net-analyzer/nrpe[tcpd] +Display-If-Installed: net-analyzer/nsca[tcpd] +Display-If-Installed: net-analyzer/rrdtool[tcpd] +Display-If-Installed: net-fs/netatalk[tcpd] +Display-If-Installed: net-fs/nfs-utils[tcpd] +Display-If-Installed: net-ftp/atftp[tcpd] +Display-If-Installed: net-ftp/tftp-hpa[tcpd] +Display-If-Installed: net-ftp/vsftpd[tcpd] +Display-If-Installed: net-irc/ngircd[tcpd] +Display-If-Installed: net-mail/cyrus-imapd[tcpd] +Display-If-Installed: net-mail/dovecot[tcpd] +Display-If-Installed: net-mail/mailutils[tcpd] +Display-If-Installed: net-mail/tpop3d[tcpd] +Display-If-Installed: net-misc/apt-cacher-ng[tcpd] +Display-If-Installed: net-misc/ser2net[tcpd] +Display-If-Installed: net-misc/socat[tcpd] +Display-If-Installed: net-misc/sslh[tcpd] +Display-If-Installed: net-misc/stunnel[tcpd] +Display-If-Installed: net-misc/usbip[tcpd] +Display-If-Installed: net-nds/openldap[tcpd] +Display-If-Installed: net-nds/rpcbind[tcpd] +Display-If-Installed: net-nds/tac_plus[tcpd] +Display-If-Installed: net-proxy/dante[tcpd] +Display-If-Installed: net-vpn/ocserv[tcpd] +Display-If-Installed: net-vpn/pptpd[tcpd] +Display-If-Installed: sci-libs/dcmtk[tcpd] +Display-If-Installed: sys-apps/linux-misc-apps[tcpd] +Display-If-Installed: sys-apps/xinetd[tcpd] +Display-If-Installed: sys-fs/quota[tcpd] +Display-If-Installed: sys-power/nut[tcpd] + +On 2021-11-01, we will remove USE="tcpd" from the globally default +enabled USE flags (https://bugs.gentoo.org/805077). USE="tcpd" usually +enables sys-apps/tcp-wrappers for an ad hoc firewall based on +/etc/hosts.allow and /etc/hosts.deny. + +The Base System project has come to the conclusion that 24 years after +the last upstream release, tcp-wrappers is not suitable for a default +configuration in 2021 anymore. Other distributions have completely +removed support at this point. We strongly recommend you switch to more +modern packet filters, such as BPF, nftables, or iptables. If you rely +on tcp-wrappers, you can re-enable the flag, see + + https://wiki.gentoo.org/wiki//etc/portage/package.use + +for package-specific ways to re-enable tcp-wrappers. diff --git a/metadata/news/2021-08-11-oauth2-creds-chromium/2021-08-11-oauth2-creds-chromium.en.txt b/metadata/news/2021-08-11-oauth2-creds-chromium/2021-08-11-oauth2-creds-chromium.en.txt new file mode 100644 index 000000000000..0d7a8aca1995 --- /dev/null +++ b/metadata/news/2021-08-11-oauth2-creds-chromium/2021-08-11-oauth2-creds-chromium.en.txt @@ -0,0 +1,44 @@ +Title: OAuth2 Credentials Removed from Chromium +Author: Jason A. Donenfeld <zx2c4@gentoo.org> +Posted: 2021-08-11 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: www-client/chromium + +In March of this year, Google announced that OAuth2 credentials would be revoked +for distros shipping Chromium. This was covered in multiple places at the time, +such as [1,2,3]. Around that time, with 89.0.4389.82, Gentoo removed OAuth2 +credentials from its packages. However, they slipped back in shortly after. + +As a result, some users [4] have found that recently Google's SSO does not +persist between browser sessions; e.g. you have to log back into GMail every +time you open your browser. This week's changes [5] restore the old behavior +we had in March, of not shipping Gentoo OAuth2 credentials. + +If you find that certain Google services are no longer working, you may wish to +supply OAuth2 credentials manually, obtained by following the instructions at +[6]. However, even without supplying such credentials, Google's SSO should now +be working as expected. + +There are now two options for passing these credentials to Chromium via + +/etc/chromium/default: + + 1. GOOGLE_DEFAULT_CLIENT_ID and GOOGLE_DEFAULT_CLIENT_SECRET environment + variables: + export GOOGLE_DEFAULT_CLIENT_ID="<client-id>" + export GOOGLE_DEFAULT_CLIENT_SECRET="<client-secret>" + + 2. --oauth2-client-id and --oauth2-client-secret= command line switches: + CHROMIUM_FLAGS+=" --oauth2-client-id=<client-id>" + CHROMIUM_FLAGS+=" --oauth2-client-secret=<client-secret>" + +Alternatively these environment variables and command line switches may be given +at the command line for ad-hoc testing. + +[1] https://archlinux.org/news/chromium-losing-sync-support-in-early-march/ +[2] https://bodhi.fedoraproject.org/updates/FEDORA-2021-48866282e5 +[3] https://hackaday.com/2021/01/26/whats-the-deal-with-chromium-on-linux-google-at-odds-with-package-maintainers/ +[4] https://bugs.gentoo.org/791871 +[5] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fce48ef271bbcaee9afdf0481294da167e665a9b +[6] http://www.chromium.org/developers/how-tos/api-keys diff --git a/metadata/news/2021-08-18-uclibc-ng-retirement/2021-08-18-uclibc-ng-retirement.en.txt b/metadata/news/2021-08-18-uclibc-ng-retirement/2021-08-18-uclibc-ng-retirement.en.txt new file mode 100644 index 000000000000..862ad2ec84aa --- /dev/null +++ b/metadata/news/2021-08-18-uclibc-ng-retirement/2021-08-18-uclibc-ng-retirement.en.txt @@ -0,0 +1,20 @@ +Title: uClibc-ng retirement on 2022-01-01 +Author: Anthony G. Basile <blueness@gentoo.org> +Posted: 2021-08-18 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Profile: default/linux/uclibc/* + +uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021, +no one has volunteered to step up maintenance or expressed interest in +the uClibc-ng profiles. With this announcement we last-rite the "uclibc" +profiles, which will be removed on 2022-01-01. For parties interested in +an alternative libc, consider moving to musl, which is supported. + +Gentoo continues to wholeheartedly support musl and is focusing its +efforts in that area. + +Resources: +- https://wiki.gentoo.org/wiki/Project:Hardened_musl +- https://gitweb.gentoo.org/proj/musl.git/ (overlay for patches) +- #gentoo-hardened (IRC channel on irc.libera.chat) for support and discussion diff --git a/metadata/news/2021-08-19-mc-legacy-config-dirs/2021-08-19-mc-legacy-config-dirs.en.txt b/metadata/news/2021-08-19-mc-legacy-config-dirs/2021-08-19-mc-legacy-config-dirs.en.txt new file mode 100644 index 000000000000..fe7d6ce15b61 --- /dev/null +++ b/metadata/news/2021-08-19-mc-legacy-config-dirs/2021-08-19-mc-legacy-config-dirs.en.txt @@ -0,0 +1,37 @@ +Title: >=app-misc/mc-4.8.27 to drop support for ~/.mc +Author: Marek Szuba <marecki@gentoo.org> +Posted: 2021-08-19 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: app-misc/mc + +app-misc/mc versions between 4.8.1 and 4.8.26, inclusive, would look +for their user configuration in two possible places: + + * if built with USE=-xdg, only the legacy directory ~/.mc is used; + + * if built with USE=xdg, mc uses appropriate XDG user directories + (e.g. ~/.config/mc, ~/.local/share/mc) if present and attempts + to automatically migrate the contents of ~/.mc otherwise. + +However, starting with version 4.8.27 Midnight Commander will use _only +XDG user directories_ for its configuration and no longer automatically +migrate the contents of ~/.mc. For more information, see: + + https://midnight-commander.org/wiki/NEWS-4.8.27 + https://midnight-commander.org/ticket/3682 + +For everyone who currently uses app-misc/mc[-xdg], or has not started +mc for so long that it hasn't had a chance to migrate its configuration, +upgrading to 4.8.27 or newer will result in Midnight Commander +effectively reverting to default user configuration. In order to prevent +this from happening, make sure automatic migration is available: + + echo 'app-misc/mc xdg' >> /etc/portage/package.use + emerge --oneshot <app-misc/mc-4.8.27 + +and have every user on your system with ~/.mc present run both 'mc' +and 'mcedit' at least once prior to the version upgrade. + +No action is required of everyone currently using app-misc/mc +with USE=xdg enabled. diff --git a/metadata/news/2021-08-24-eudev-retirement/2021-08-24-eudev-retirement.en.txt b/metadata/news/2021-08-24-eudev-retirement/2021-08-24-eudev-retirement.en.txt new file mode 100644 index 000000000000..750f09d6772b --- /dev/null +++ b/metadata/news/2021-08-24-eudev-retirement/2021-08-24-eudev-retirement.en.txt @@ -0,0 +1,72 @@ +Title: eudev retirement on 2022-01-01 +Author: Anthony G. Basile <blueness@gentoo.org> +Posted: 2021-08-24 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-fs/eudev + +UPDATE (2022-01-14): sys-fs/eudev is now maintained by a new collection +of cross-distribution contributors. It will therefore remain in the +Gentoo repository. + +Help is still welcome with maintaining it within Gentoo if users +are interested. + +The default for new installs will remain sys-fs/udev and the +rest of this news item still applies. +--- + +sys-fs/udev is becoming the standard provider of udev on non-systemd (e.g. +OpenRC) systems. Users of systemd will continue to use the udev services +provided by the sys-apps/systemd package itself. + +The transition should be uneventful in most cases, but please +read this item in full to understand some possible corner cases. + +eudev will be retired and removed from Gentoo on 2022-01-01. We will +start masking eudev on 2021-10-01 and give people 3 months to prepare +their transition. You should ensure that sys-fs/eudev is not in your +world file by running + + emerge --deselect sys-fs/eudev + +in order for Portage to replace eudev with sys-fs/udev once the +package.mask is in place. We fully support udev on musl, whereas uclibc +will still have to rely on eudev before also being removed on 2022-01-01. + + **WARNING 1** + +If you happen to have an INSTALL_MASK including "systemd", e.g. a +blanket "*systemd*" glob, you will inevitably break your system. sys-fs/udev +contains "systemd" in some of its directories and filenames, hence a blanket +filter rule will likely lead to a non-functional udev installation. + +Please also verify you do not have "sys-fs/udev" in package.mask. + + **WARNING 2** + +If you DO NOT want the "predictable interface naming" of newer versions +of udev and instead prefer the old style (e.g. "eth0"), there are several +options available. + +The simplest is to pass 'net.ifnames=0' on the kernel command line. + +See the wiki for more information: +https://wiki.gentoo.org/wiki/Udev#Optional:_Disable_or_override_predictable_network_interface_naming. + + Rationale + +The integration of udev into the systemd git repo introduced numerous +problems for non-glibc systems, such as musl and uclibc. Several +options were considered, and the one chosen was to fork and maintain udev +independent of the rest of systemd. This was meant as a stop-gap solution +until such time as the problems with systemd on musl had been resolved. +This is now the case with patches provided by openembedded, and my original +reason for maintaining eudev is no longer relevant. + +I am willing to transfer eudev to another umbrella organization or Linux +distribution that is willing to continue its maintenance, but maintaining +eudev cannot be done purely through proxy-maintaining and requires an +understanding of its internals. This is a steep learning curve and must +be an earnest effort. For this reason, the Base System project has decided +not to support eudev as an option going forward. diff --git a/metadata/news/2021-09-05-setuptools_scm-6_3_0-temporary-breakage/2021-09-05-setuptools_scm-6_3_0-temporary-breakage.en.txt b/metadata/news/2021-09-05-setuptools_scm-6_3_0-temporary-breakage/2021-09-05-setuptools_scm-6_3_0-temporary-breakage.en.txt new file mode 100644 index 000000000000..988002c7dc18 --- /dev/null +++ b/metadata/news/2021-09-05-setuptools_scm-6_3_0-temporary-breakage/2021-09-05-setuptools_scm-6_3_0-temporary-breakage.en.txt @@ -0,0 +1,49 @@ +Title: setuptools_scm-6.3.0 temporary runtime breakage +Author: Arthur Zamarin <arthurzam@gentoo.org> +Author: Sam James <sam@gentoo.org> +Posted: 2021-09-05 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: =dev-python/setuptools_scm-6.3.0 + +Users who upgraded to =dev-python/setuptools_scm-6.3.0 between 2021-09-03 +15:42 UTC and 2021-09-03 19:03 UTC may be affected by a bug [0]. If you have not +upgraded to this version or have >=dev-python/setuptools_scm-6.3.0-r1 installed, +you are not affected. + +A missing dependency in the setuptools_scm ebuild meant there was a timeframe in +which anyone who installed dev-python/setuptools_scm and dev-python/packaging in +the wrong order won't be able to build any Python package using setuptools +unless a workaround is applied. + +Specifically, this affects users with =dev-python/setuptools_scm-6.3.0 installed +and where dev-python/packaging is not installed (applies separately for each/any +Python target). The bad tree state was between gentoo.git commits +8882e54abf78d3af69faed5844e3ad441482f23e and +0c76b447cd1be9cf611f649970851750304d9ca6. + +Affected users will see errors similar to the following when installing Python +packages: +``` +pkg_resources.DistributionNotFound: The 'packaging>=20.0' distribution was not +found and is required by the application +``` + +To fix this manually, you need to fully remove all dev-python/setuptools_scm +files by running the following commands: + +# Necessary to obtain a fixed version of setuptools_scm +$ emerge --sync + +# --unmerge is NOT advised normally, but is required to avoid setuptools picking +# up the runtime-broken setuptools_scm version when re-installing setuptools_scm +$ emerge --unmerge =dev-python/setuptools_scm-6.3.0 + +$ emerge --oneshot dev-python/setuptools dev-python/pyparsing dev-python/packaging +$ emerge --oneshot ">=dev-python/setuptools_scm-6.3.0-r1" + +Note that the version specifiers above are not strictly necessary if you have an +up-to-date copy of the tree but provide a safety net. + +[0] https://bugs.gentoo.org/811504 + diff --git a/metadata/news/2021-09-24-busybox-removal-from-system-set/2021-09-24-busybox-removal-from-system-set.en.txt b/metadata/news/2021-09-24-busybox-removal-from-system-set/2021-09-24-busybox-removal-from-system-set.en.txt new file mode 100644 index 000000000000..81593d34e63d --- /dev/null +++ b/metadata/news/2021-09-24-busybox-removal-from-system-set/2021-09-24-busybox-removal-from-system-set.en.txt @@ -0,0 +1,24 @@ +Title: busybox removal from system set +Author: Mike Gilbert <floppym@gentoo.org> +Posted: 2021-09-24 +Revision: 2 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/busybox +Display-If-Profile: default/linux/* + +The sys-apps/busybox package has been removed from the system +set (@system) in Linux profiles. It was decided that this package is not +necessary for a basic system install. + +If you would like to keep this package installed, please ensure it is +present in your Portage world file. + + emerge --select --noreplace sys-apps/busybox + +As well, the "static" USE flag has been disabled by default. It may be +re-enabled locally via package.use if so desired. + +UPDATE: busybox includes a DHCP client (udhcpc). Some users of netifrc +unknowingly rely on this client. If your networking configuration uses +DHCP, please ensure that you have a DHCP client selected in the Portage +world file. diff --git a/metadata/news/2021-09-29-possible-failure-to-preserve-libraries/2021-09-29-possible-failure-to-preserve-libraries.en.txt b/metadata/news/2021-09-29-possible-failure-to-preserve-libraries/2021-09-29-possible-failure-to-preserve-libraries.en.txt new file mode 100644 index 000000000000..68aa6af5e8f1 --- /dev/null +++ b/metadata/news/2021-09-29-possible-failure-to-preserve-libraries/2021-09-29-possible-failure-to-preserve-libraries.en.txt @@ -0,0 +1,114 @@ +Title: Possible failure to preserve libraries +Author: Sam James <sam@gentoo.org> +Author: Hank Leininger <hlein@korelogic.com> +Posted: 2021-09-29 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/portage + +We have observed in some cases corruption of Portage's internal database +(VDB), where the libraries provided by a package are not recorded. This +can break the "preserve-libs" functionality, and thus in rare cases +break your system during much later updates (even if you do not use +"preseved-libs" now, but decide to switch it on later). + +The underlying problem occurs usually when glibc has been upgraded to a +new major version, but pax-utils has not yet been upgraded to a version +compatible with it (but at that moment stays undetected). + +The full technical details and investigation can be found on a Wiki page +[0] and on Bugzilla [1]. Changes have been made to prevent this happening +again both within Portage [7] (with possibly more to come [2]) and within the +glibc and pax-utils ebuilds [3][4]. + +To detect whether a system is affected, emerge the +app-portage/recover-broken-vdb package: +``` +$ emerge --ask --verbose --oneshot app-portage/recover-broken-vdb +``` +which provides two tools: recover-broken-vdb-find-broken.sh and +recover-broken-vdb. + +Then run recover-broken-vdb-find-broken.sh: +``` +$ recover-broken-vdb-find-broken.sh | tee broken_vdb_packages +``` + +This check should be run on all Gentoo systems. It is only necessary +to run this as a one-off, as changes have been made to prevent such +problems occurring in future. + +If you have any output, read on. + +Fixing a broken system is not always straightforward. It is strongly +recommended to take a backup of your full system before proceeding, +as well as a copy of /var/db/pkg (the VDB): + +Step 1. A tool has been developed [5] to attempt to fix the consistency + of the Portage database. Using this tool to modify the VDB is NOT + mandatory (read the full news item before proceeding) - you can skip + to Step 2 if you wish, but fixing the integrity of the VDB + makes it as safe as reasonably possible to proceed with + rebuilding packages. + + Run: + ``` + # Take a backup of /var/db/pkg before proceeding, such as by doing: + $ cp -a /var/db/pkg /var/db/pkg.orig + + # And then: + $ emerge --ask --verbose --oneshot --noreplace \ + app-portage/recover-broken-vdb + + $ recover-broken-vdb + + # The tool will output to a random temporary directory. + # Inspect the results, and then update the real /var/db/pkg/ + # by doing either: + + $ recover-broken-vdb --output /var/db/pkg + + # Or, manually copying the new files from the temporary directory tree + # into your real /var/db/pkg/ directory tree. + ``` + +Step 2. Attempt to rebuild the affected packages, first upgrading + app-misc/pax-utils to the latest version: + ``` + $ emerge --ask --verbose --oneshot ">=app-misc/pax-utils-1.3.3" + $ emerge --ask --verbose --oneshot --usepkg=n $(grep -v '#' broken_vdb_packages) + ``` + + It's possible that the relevant versions have disappeared from the tree, so + if the emerge command fails, please attempt a normal world upgrade. + +Step 3. Given that there are possible other side-effects of the corruption/bug, + it is strongly recommended that if any corruption is detected, all + packages on the system should be rebuilt, after following the above + steps: + ``` + $ emerge --ask --emptytree --usepkg=n @world + ``` + + Note that binary packages may need to be discarded given they may + contain corrupt metadata. + + If no libraries were broken, it is likely safe to skip this step. It + should be sufficient, for resource-constrained machines, to simply + rebuild any broken libraries and their consumers (reverse-dependencies): + revdep-rebuild may help you do this. + + (If you do not know what that means, please proceed with Step 3.) + +Please see the wiki [0] for a full description of the background +of this problem and handling corner cases such as e.g. already +being affected by system breakage [6] as a result of the bug. + +[0] https://wiki.gentoo.org/wiki/Project:Toolchain/Corrupt_VDB_ELF_files +[1] https://bugs.gentoo.org/811462 +[2] https://github.com/gentoo/portage/pull/744 +[3] https://bugs.gentoo.org/811462#c6 +[4] https://bugs.gentoo.org/811462#c7 +[5] https://github.com/thesamesam/recover-broken-vdb +[6] https://wiki.gentoo.org/wiki/Fix_my_Gentoo +[7] https://gitweb.gentoo.org/proj/portage.git/commit/?id=83af7270fafbd7b1eed0031a5e06836ad1edf06d diff --git a/metadata/news/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt b/metadata/news/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt new file mode 100644 index 000000000000..cfdcc4a32d38 --- /dev/null +++ b/metadata/news/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt @@ -0,0 +1,26 @@ +Title: OpenSSH RSA SHA-1 signatures +Author: Mike Gilbert <floppym@gentoo.org> +Posted: 2021-10-08 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: net-misc/openssh + +As of version 8.8, OpenSSH disables RSA signatures using the SHA-1 +hash algorithm by default. This change affects both the client and +server components. + +After upgrading to this version, you may have trouble connecting to +older SSH servers that do not support the newer RSA/SHA-256/SHA-512 +signatures. Support for these signatures was added in OpenSSH 7.2. + +As well, you may have trouble using older SSH clients to connect to a +server running OpenSSH 8.8 or higher. Some older clients do not +automatically utilize the newer hashes. For example, PuTTY before +version 0.75 is affected. + +To resolve these problems, please upgrade your SSH client/server +whereever possible. If this is not feasible, support for the SHA-1 +hashes may be re-enabled using the following config options: + +HostkeyAlgorithms +ssh-rsa +PubkeyAcceptedAlgorithms +ssh-rsa diff --git a/metadata/news/2021-10-17-openssl-bindist-removal/2021-10-17-openssl-bindist-removal.en.txt b/metadata/news/2021-10-17-openssl-bindist-removal/2021-10-17-openssl-bindist-removal.en.txt new file mode 100644 index 000000000000..ca6c6e651348 --- /dev/null +++ b/metadata/news/2021-10-17-openssl-bindist-removal/2021-10-17-openssl-bindist-removal.en.txt @@ -0,0 +1,38 @@ +Title: dev-libs/openssl USE=bindist removal +Author: Robin H. Johnson <robbat2@gentoo.org> +Posted: 2021-10-17 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-libs/openssl[bindist] + +On 2021-11-19, the base-system team will remove USE=bindist +behavior from dev-libs/openssl, per bug #762850 [1]. + +Users should not experience any ABI incompatibilities that +require recompilation when moving from +dev-libs/openssl[bindist] to dev-libs/openssl[-bindist]. + +However, moving back in future may recompile if any binaries +of their systems depend on the additional symbols available +with USE=-bindist. + +USE=bindist on dev-libs/openssl historically applied RedHat +work, called hobble-openssl [2], that was intended to make +OpenSSL "safe" to distribute with regards to various +patents, in the opinion of RedHat's legal counsel. The +hobble-openssl, in it's last iterations, it greatly +restricted which parts of EC (elliptic curve) were available +[3][4] + +Debian & Ubuntu do not apply any similar behavior, and +Gentoo intends to follow Debian's lead with regards to +OpenSSL hobble-openssl moving forward. + +[1] https://bugs.gentoo.org/762850 +[2] Multiple files: + https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/hobble-openssl + https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/ectest.c + https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/ec_curve.c + https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/0011-Remove-EC-curves.patch +[3] https://archives.gentoo.org/gentoo-dev/message/f0d16240bb0dd1ff38fb5223bec810ab +[4] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening#system-wide-crypto-policies_using-the-system-wide-cryptographic-policies diff --git a/metadata/news/2021-10-18-libxcrypt-migration-stable/2021-10-18-libxcrypt-migration-stable.en.txt b/metadata/news/2021-10-18-libxcrypt-migration-stable/2021-10-18-libxcrypt-migration-stable.en.txt new file mode 100644 index 000000000000..74e80d58f7e6 --- /dev/null +++ b/metadata/news/2021-10-18-libxcrypt-migration-stable/2021-10-18-libxcrypt-migration-stable.en.txt @@ -0,0 +1,110 @@ +Title: migrating from glibc[crypt] to libxcrypt in stable +Author: Andreas K. Hüttel <dilfridge@gentoo.org> +Author: Sam James <sam@gentoo.org> +Posted: 2021-10-18 +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, now also in stable 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. If +you hit issues, please read on. + +## Upgrades before 2021-11-01 + +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. + +Please take the opportunity to fully upgrade your +systems now, before the migration occurs, to simplify matters + +This change will occur on 2021-11-01 for stable users. +~arch users by default should already have switched. + +## General advice + +We also recommend being in a root shell (not via 'sudo' +or similar tools) so that if any issues occur during the upgrade, +you are not locked out of the console. It is not expected +that any such issues will occur but this is a precaution. + +It is also recommended that users do _not_ have +FEATURES="collision-protect" enabled because it is +aggressive in protecting even orphaned files. Instead, +use FEATURES="unmerge-orphans" which is almost identical +in behaviour. + +## Delaying the migration *or* circular dependencies + +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 +* unmask virtual/libcrypt:0/1 + +If hitting circular dependencies involving Python 3.10, +see the wiki for more details [3], but the same steps +listed above must be taken (mask newer libcrypt temporarily, +do a world upgrade, then unmask). + +## Migrating early + +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 + +## PAM warning + +Please note that if you last changed your password before ~2008, +it may be using md5crypt or similar other weak mechanisms in /etc/shadow; +a bug in PAM [0][1] may mean that you were unable to login. We recommend +using "passwd" to change/refresh your password so it is using modern +methods. A new version of PAM has been added to the tree to resolve this issue. + +## Build failures + +In some cases, Portage may schedule a rebuild of certain packages in an +incorrect order [2]. If building a package fails, please try upgrading +Python itself to help avoid spurious build failures, and then +libcrypt and libxcrypt first: + +# emerge -v1 --ignore-built-slot-operator-deps=y dev-lang/python:3.8 dev-lang/python:3.9 +# emerge -v1 virtual/libcrypt sys-libs/libxcrypt + +And then continue the world upgrade with Portage's "--keep-going=y". + +## Blockers/conflicts + +If you hit blockers/conflicts, please see the wiki page linked below, but +common helpful tips are: +* try more backtracking (e.g. --backtrack=1000) +* try --ignore-built-slot-operator-deps=y temporarily on the world upgrade, +then run a world upgrade again without it. + +Do NOT attempt to unmerge glibc at any point. + +## More help + +For more information or troubleshooting tips, please see: +* https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation +* https://bugs.gentoo.org/699422 +* Reach out to our support channels (https://www.gentoo.org/support/) + +[0] https://bugs.gentoo.org/802267 +[1] https://bugs.gentoo.org/802807 +[2] https://bugs.gentoo.org/802210 +[3] https://wiki.gentoo.org/wiki/User:Sam/Portage_help/Circular_dependencies#Python_and_libcrypt diff --git a/metadata/news/2021-10-24-netifrc-dhcp-client/2021-10-24-netifrc-dhcp-client.en.txt b/metadata/news/2021-10-24-netifrc-dhcp-client/2021-10-24-netifrc-dhcp-client.en.txt new file mode 100644 index 000000000000..d97a45443d2b --- /dev/null +++ b/metadata/news/2021-10-24-netifrc-dhcp-client/2021-10-24-netifrc-dhcp-client.en.txt @@ -0,0 +1,21 @@ +Title: netifrc DHCP client +Author: Mike Gilbert <floppym@gentoo.org> +Posted: 2021-10-24 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: net-misc/netifrc +Display-If-Profile: default/linux/* + +The sys-apps/busybox package was recently removed from the system set. +Users of net-misc/netifrc may have unknowingly relied upon this package +to provide a DHCP client. + +If you are using netifrc and use DHCP for network connectivity, please +ensure you have a supported DHCP client installed/selected in the +Portage world file. + +Supported clients include: + +dhcpcd provided by net-misc/dhcpcd +dhclient provided by net-misc/dhcp +udhcpc provided by sys-apps/busybox diff --git a/metadata/news/2021-10-30-upgrade-to-net-news_rssguard-4_0/2021-10-30-upgrade-to-net-news_rssguard-4_0.en.txt b/metadata/news/2021-10-30-upgrade-to-net-news_rssguard-4_0/2021-10-30-upgrade-to-net-news_rssguard-4_0.en.txt new file mode 100644 index 000000000000..98e143d13707 --- /dev/null +++ b/metadata/news/2021-10-30-upgrade-to-net-news_rssguard-4_0/2021-10-30-upgrade-to-net-news_rssguard-4_0.en.txt @@ -0,0 +1,30 @@ +Title: net-news/rssguard-4.0 upgrade +Author: Anna Vyalkova <cyber+gentoo@sysrq.in> +Author: Proxy Maintainers <proxy-maint@gentoo.org> +Posted: 2021-10-30 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: <net-news/rssguard-4.0 + +RSS Guard database files created by RSS Guard version 3.9.x are +incompatible with RSS Guard version 4.0 or later [0]. + +Configuration file (config.ini) is fully backwards compatible according +to the upstream. You can save it (File -> Backup settings) before an +upgrade and restore it later (File -> Restore settings). + +There is no reliable way to automate the database format conversion, so +action from the user is required before an upgrade can take place. + +The first option would be to export your feeds as an OMPL file +(Accounts -> Export feeds) before an upgrade and import them later +(Account -> Import feeds). + +The second option would be to manually update your database.db file to +4.x.x format following a guide by the upstream developer [1]. + +Keep in mind that application data directory has been renamed from +"~/.config/RSS Guard" to "~/.config/RSS Guard 4". + +[0] https://github.com/martinrotter/rssguard/releases/tag/4.0.0 +[1] https://github.com/martinrotter/rssguard/blob/master/resources/docs/Documentation.md#migratt diff --git a/metadata/news/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt b/metadata/news/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt new file mode 100644 index 000000000000..c977ae7f9725 --- /dev/null +++ b/metadata/news/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt @@ -0,0 +1,45 @@ +Title: Full MariaDB database restore maybe required +Author: Thomas Deutschmann <whissi@gentoo.org> +Posted: 2021-11-23 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-db/mariadb +Display-If-Installed: sys-cluster/galera + +On 2021-11-21, keywords for dev-db/mariadb:10.6 were removed to +address a file collision with dev-db/mariadb-connector-c. This +unintentionally triggered a version downgrade for users who had +successfully upgraded to dev-db/mariadb:10.6 already. [Link 1]. + +However, downgrades are not supported in MySQL/MariaDB [Link 2]. + +In case you already fully upgraded to MariaDB 10.6 (which includes +executing mysql_upgrade command) and unintentionally downgraded your +MariaDB instance afterwards during the time window when keywords were +removed, you maybe experiencing different problems: + +At best, your unwanted downgraded MariaDB instance prevented startup +so all you have to do is upgrade to MariaDB 10.6 again to resume +services. + +In case previous MariaDB version was able to start, you are encouraged +to do a full backup as soon as possible using mysqldump command and +manually restore each database ("logical downgrade") to prevent any +data corruption. + +Depending on used feature set and from which version you upgraded, +it is maybe required to do a full restore from a previous backup before +MariaDB 10.6 upgrade to restore services and prevent any data loss or +future runtime errors. + +In case you are using MariaDB in a cluster and/or Galera setup you +probably have to rebuild the entire cluster in case the upgrade to +MariaDB 10.6 was already replicated (using pt-table-checksum from +dev-db/percona-toolkit can help you to validate your cluster). + +Keep in mind that due to the downgrade, point-in-time recovery may +not be available to the extent that you are used to. + +Link 1: https://bugs.gentoo.org/825234 + +Link 2: https://mariadb.com/kb/en/downgrading-between-major-versions-of-mariadb/ diff --git a/metadata/news/2022-03-05-singularity_to_apptainer/2022-03-05-singularity_to_apptainer.en.txt b/metadata/news/2022-03-05-singularity_to_apptainer/2022-03-05-singularity_to_apptainer.en.txt new file mode 100644 index 000000000000..0d9c99268982 --- /dev/null +++ b/metadata/news/2022-03-05-singularity_to_apptainer/2022-03-05-singularity_to_apptainer.en.txt @@ -0,0 +1,26 @@ +Title: Transition from sys-cluster/singularity to app-containers/apptainer +Author: Marek Szuba <marecki@gentoo.org> +Posted: 2022-03-05 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-cluster/singularity + +In autumn 2021 the Singularity project joined the Linux Foundation +and changed its name to Apptainer [1]. The change has been reflected +in the renaming of files and environment variables, as well as a reset +of version numbers back to 1.0.0. + +Apptainer packages include compatibility symlinks to old Singularity +executables, provide bash-completion rules for both the old and the new +name, continue to honour old environment variables, and will upon +the first run import user data from Singularity directories. Therefore, +for most users it will be sufficient to deselect the old package and +install the new one, e.g.: + +emerge --deselect sys-cluster/singularity +emerge app-containers/apptainer + +However, customisations made to system-wide configuration +in /etc/singularity will have to be applied to /etc/apptainer by hand. + +[1] https://apptainer.org/news/community-announcement-20211130/ diff --git a/metadata/news/2022-03-30-qt-5_15_3-bump/2022-03-30-qt-5_15_3-bump.en.txt b/metadata/news/2022-03-30-qt-5_15_3-bump/2022-03-30-qt-5_15_3-bump.en.txt new file mode 100644 index 000000000000..ad4db1dc88d0 --- /dev/null +++ b/metadata/news/2022-03-30-qt-5_15_3-bump/2022-03-30-qt-5_15_3-bump.en.txt @@ -0,0 +1,23 @@ +Title: Qt 5.15.3 version bump with binary path changes +Author: Andreas Sturmlechner <asturm@gentoo.org> +Posted: 2022-03-30 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: >=dev-qt/qtcore-5.15.3 + +Up until Qt 5.15.2 we were using qtchooser to provide unversioned links to Qt +binaries in PATH, like qmake, moc, qmljs etc. Starting with 5.15.3 [1] such +links will be installed by each respective Qt package and '5'-version-suffixed, +e.g. qmake becomes qmake5, qml becomes qml5 etc., mirroring Qt6. + +If you develop with Qt5 and rely on unversioned binaries for your workflow, +dev-qt/qtchooser as a tool for quickly switching between multiple Qt +installations (e.g. Qt3, Qt4 and Qt5) can still be manually installed. The +'default' Qt version in PATH is then controlled via config in +/etc/xdg/qtchooser. + +Otherwise, dev-qt/qtchooser will be slated for cleanup on your next +emerge --depclean run. + +[1] https://archives.gentoo.org/gentoo-dev/message/ +5f3681b5b28dabeb5339d44e9585d29f diff --git a/metadata/news/2022-03-30-qt-5_15_3-bump/2022-03-30-qt-5_15_3-bump.ru.txt b/metadata/news/2022-03-30-qt-5_15_3-bump/2022-03-30-qt-5_15_3-bump.ru.txt new file mode 100644 index 000000000000..4c5fa16298c5 --- /dev/null +++ b/metadata/news/2022-03-30-qt-5_15_3-bump/2022-03-30-qt-5_15_3-bump.ru.txt @@ -0,0 +1,25 @@ +Title: Новая версия Qt 5.15.3 меняет имена исполняемых файлов +Author: Andreas Sturmlechner <asturm@gentoo.org> +Translator: Alexey Sokolov <alexey+gentoo@asokolov.org> +Posted: 2022-03-30 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: >=dev-qt/qtcore-5.15.3 + +В версиях Qt по 5.15.2 мы использовали qtchooser, чтобы устанавливать +исполняемые файлы Qt в PATH без номера версии, такие как qmake, moc, +qmljs и т.д. Начиная с версии 5.15.3 [1] эти файлы будут установлены самим +соответствующим пакетом Qt и будут заканчиваться на "5": например, qmake +станет qmake5, qml станет qml5 и т.д., так же, как это делает Qt 6. + +Если вы используете Qt5 при разработке, и ваш рабочий процесс зависит от +этих файлов без версии, вы всё ещё можете установить dev-qt/qtchooser — +инструмент для быстрого переключения между различными установленными Qt +(например, Qt3, Qt4, Qt5). В таком случае версия Qt в PATH по умолчанию +настраивается в /etc/xdg/qtchooser. + +В противном случае dev-qt/qtchooser будет удалён при следующем запуске +emerge --depclean. + +[1] https://archives.gentoo.org/gentoo-dev/message/ +5f3681b5b28dabeb5339d44e9585d29f diff --git a/metadata/news/2022-04-12-ccache-4_6-sandbox/2022-04-12-ccache-4_6-sandbox.en.txt b/metadata/news/2022-04-12-ccache-4_6-sandbox/2022-04-12-ccache-4_6-sandbox.en.txt new file mode 100644 index 000000000000..1dabea97f708 --- /dev/null +++ b/metadata/news/2022-04-12-ccache-4_6-sandbox/2022-04-12-ccache-4_6-sandbox.en.txt @@ -0,0 +1,25 @@ +Title: Sandbox issue with ccache 4.6 +Author: Sam James <sam@gentoo.org> +Posted: 2022-04-12 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: =dev-util/ccache-4.6 + +Users with ccache enabled for the dev-util/ccache package itself may need +to temporarily disable ccache in order to upgrade the package. + +Users on an earlier version of ccache (<4.6) or newer (>=4.6-r1) are +unaffected. + +For a small window (between 2022-04-09-4:30AM UTC and 2022-04-09-11:27AM UTC), +the ccache ebuild may have caused a sandbox violation [0] in some circumstances. + +To resolve this issue, temporarily re-emerge dev-util/ccache with ccache +disabled: +# FEATURES="-ccache" emerge -v1 ">dev-util/ccache-4.6" + +The sandbox violations occur when trying to use ccache for any package; +users who do not have ccache enabled globally (or at least not for ccache +itself) should also proactively upgrade ccache as above. + +[0] https://bugs.gentoo.org/837362 diff --git a/metadata/news/2022-04-17-systemd-utils-update-needed/2022-04-17-systemd-utils-update-needed.en.txt b/metadata/news/2022-04-17-systemd-utils-update-needed/2022-04-17-systemd-utils-update-needed.en.txt new file mode 100644 index 000000000000..22262edda025 --- /dev/null +++ b/metadata/news/2022-04-17-systemd-utils-update-needed/2022-04-17-systemd-utils-update-needed.en.txt @@ -0,0 +1,12 @@ +Title: sys-apps/systemd-utils update needed +Author: Mike Gilbert <floppym@gentoo.org> +Posted: 2022-04-17 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: =sys-apps/systemd-utils-250.4 + +The currently installed version of sys-apps/systemd-utils may cause +kernel modules to fail to load on boot. + +Please upgrade to >=sys-apps/systemd-utils-250.4-r1 as soon as possible, +and certainly before rebooting your system. diff --git a/metadata/news/2022-04-19-systemd-utils/2022-04-19-systemd-utils.en.txt b/metadata/news/2022-04-19-systemd-utils/2022-04-19-systemd-utils.en.txt new file mode 100644 index 000000000000..522456433554 --- /dev/null +++ b/metadata/news/2022-04-19-systemd-utils/2022-04-19-systemd-utils.en.txt @@ -0,0 +1,50 @@ +Title: Migration to sys-apps/systemd-utils +Author: Mike Gilbert <floppym@gentoo.org> +Posted: 2022-04-19 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/systemd-tmpfiles +Display-If-Installed: sys-apps/systemd-utils +Display-If-Installed: sys-boot/systemd-boot +Display-If-Installed: sys-fs/udev + +The sys-apps/systemd-utils package was recently added to the gentoo +repository. This replaces sys-apps/systemd-tmpfiles, +sys-boot/systemd-boot, and sys-fs/udev with a single package, and is +for OpenRC users. It does not depend on sys-apps/systemd and contains +the same exact components as the split packages. + +USE flags are provided to allow each component to be enabled +or disabled. This change was made to significantly ease maintenance of tools +split out from systemd. + +When upgrading to sys-apps/systemd-tmpfiles-250, +sys-apps/systemd-utils[tmpfiles] will be pulled in as a dependency. + +When upgrading to sys-boot/systemd-boot-250, +sys-apps/systemd-utils[boot] will be pulled in as a dependency. + +When upgrading to sys-fs/udev-250, sys-apps/systemd-utils[udev] will be +pulled in as a dependency. + +At a later date, sys-apps/systemd-tmpfiles, sys-boot/systemd-boot, and +sys-fs/udev will be masked for removal once a suitable version of +sys-apps/systemd-utils has been marked stable and sufficient time has +been provided for users to migrate. + +Possible problems when upgrading: + +1. If sys-fs/eudev is present in the world file (@selected), emerge will + abort the upgrade with a unsolvable blocker error. To resolve this, + either remove sys-fs/eudev from the world file + (emerge --deselect sys-fs/eudev), or disable the 'udev' USE flag for + sys-apps/systemd-utils. + +2. The 'boot' USE flag on sys-apps/systemd-utils is disabled by default. + Users migrating from sys-boot/systemd-boot will need to enable the + 'boot' USE flag (in package.use) to continue receiving updates. + +3. If you have package.use entries for any of sys-apps/systemd-tmpfiles, + sys-boot/systemd-boot, or sys-fs/udev, please update the relevant lines + to refer to sys-apps/systemd-utils instead. This might include + ABI_X86_32 for some users! diff --git a/metadata/news/2022-05-23-borgmatic-config-changes/2022-05-23-borgmatic-config-changes.en.txt b/metadata/news/2022-05-23-borgmatic-config-changes/2022-05-23-borgmatic-config-changes.en.txt new file mode 100644 index 000000000000..f2374f666180 --- /dev/null +++ b/metadata/news/2022-05-23-borgmatic-config-changes/2022-05-23-borgmatic-config-changes.en.txt @@ -0,0 +1,14 @@ +Title: Breaking configuration changes in borgmatic-1.6.0 +Author: Marek Szuba <marecki@gentoo.org> +Posted: 2022-05-23 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: app-backup/borgmatic + +Version 1.6.0 of app-backup/borgmatic has introduced some breaking +changes to the way Borgmatic handles the merging of its configuration +files and executes command hooks. If you use these features, please +review your Borgmatic config files to make sure they continue to work +correctly with >=app-backup/borgmatic-1.6.0. For details, see [1]. + +[1] https://github.com/borgmatic-collective/borgmatic/releases/tag/1.6.0 diff --git a/metadata/news/2022-05-26-apache-nginx-glep-81/2022-05-26-apache-nginx-glep-81.en.txt b/metadata/news/2022-05-26-apache-nginx-glep-81/2022-05-26-apache-nginx-glep-81.en.txt new file mode 100644 index 000000000000..195c8673680c --- /dev/null +++ b/metadata/news/2022-05-26-apache-nginx-glep-81/2022-05-26-apache-nginx-glep-81.en.txt @@ -0,0 +1,66 @@ +Title: Migration to GLEP-81 enabled webservers +Author: Conrad Kostecki <conikost@gentoo.org> +Posted: 2022-05-20 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: www-servers/apache +Display-If-Installed: www-servers/nginx + +In future, in order to complete the whole GLEP-81 migration, +the packages www-servers/apache and www-servers/nginx +will be migrated to GLEP-81. + +If changes have been made to the default user and group created +by one of the both packages, the configuration needs to be updated, +as otherwise it will be overwritten. + +The following configuration settings can be set +in make.conf or per package in package.env: + +1. ACCT_USER_<UPPERCASE_USERNAME>_GROUPS + for overriding all default groups. + +2. ACCT_USER_<UPPERCASE_USERNAME>_GROUPS_ADD + for adding additional groups to default groups. + +3. ACCT_USER_<UPPERCASE_USERNAME>_HOME + for overriding default home directory. + +4. ACCT_USER_<UPPERCASE_USERNAME>_HOME_OWNER + for overriding default owner of home directory. + +5. ACCT_USER_<UPPERCASE_USERNAME>_HOME_PERMS + for overriding default permissions of home directory. + +6. ACCT_USER_<UPPERCASE_USERNAME>_SHELL + for overriding default assigned shell. + +If being set per package in package.env, it needs to +be set for acct-user/apache or acct-user/nginx, +depending on which user should be modified. + +See [1] for more details on those variables. + +** Package acct-user/apache will use username/group 'apache'. +-> ACCT_USER_APACHE_GROUPS=".." +-> ACCT_USER_APACHE_GROUPS_ADD=".." +-> ACCT_USER_APACHE_HOME=".." +-> ACCT_USER_APACHE_HOME_OWNER=".." +-> ACCT_USER_APACHE_HOME_PERMS=".." +-> ACCT_USER_APACHE_SHELL=".." + +** Package acct-user/nginx will use username/group 'nginx'. +-> ACCT_USER_NGINX_GROUPS=".." +-> ACCT_USER_NGINX_GROUPS_ADD=".." +-> ACCT_USER_NGINX_HOME=".." +-> ACCT_USER_NGINX_HOME_OWNER=".." +-> ACCT_USER_NGINX_HOME_PERMS=".." +-> ACCT_USER_NGINX_SHELL=".." + +Please update configuration parameters before emerging +both GLEP-81 enabled ebuilds, as otherwise configuration +will be overwritten to default. + +Migration to GLEP-81 will start after 2022-07-01. + +[1] https://devmanual.gentoo.org/eclass-reference/acct-user.eclass/index.html diff --git a/metadata/news/2022-06-13-python3-10/2022-06-13-python3-10.en.txt b/metadata/news/2022-06-13-python3-10/2022-06-13-python3-10.en.txt new file mode 100644 index 000000000000..cbf5df732e6b --- /dev/null +++ b/metadata/news/2022-06-13-python3-10/2022-06-13-python3-10.en.txt @@ -0,0 +1,120 @@ +Title: Python 3.10 to become the default on 2022-07-01 +Author: Michał Górny <mgorny@gentoo.org> +Posted: 2022-06-13 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-lang/python:3.8 +Display-If-Installed: dev-lang/python:3.9 + +We are planning to switch the default Python target of Gentoo systems +on 2022-07-01, from Python 3.9 to Python 3.10. 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_9 + */* PYTHON_SINGLE_TARGET: -* python3_9 + +This will enforce Python 3.9 and block any future updates. However, +please note that this is only a temporary solution and you will +eventually need to perform the migration. + + +Forcing the upgrade +=================== +To force the upgrade earlier, explicitly select the Python 3.10 targets: + + */* PYTHON_TARGETS: -* python3_10 + */* PYTHON_SINGLE_TARGET: -* python3_10 + +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.10 support to your system first, +and only then remove Python 3.9. However, note that this involves two +rebuilds of all the affected packages, so it will take noticeably +longer. + +First, enable both Python 3.9 and Python 3.10, and then run the upgrade +commands: + + */* PYTHON_TARGETS: -* python3_9 python3_10 + */* PYTHON_SINGLE_TARGET: -* python3_9 + +Then switch PYTHON_SINGLE_TARGET and run the second batch of upgrades: + + */* PYTHON_TARGETS: -* python3_9 python3_10 + */* PYTHON_SINGLE_TARGET: -* python3_10 + +Finally, switch to the final version and upgrade: + + */* PYTHON_TARGETS: -* python3_10 + */* PYTHON_SINGLE_TARGET: -* python3_10 + +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.11, and upgrade manually then. + + +Upgrade commands +================ +The Python 3.9 cleanup requires that Python 3.9 is removed from +the 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/2022-06-13-python3-10/2022-06-13-python3-10.pl.txt b/metadata/news/2022-06-13-python3-10/2022-06-13-python3-10.pl.txt new file mode 100644 index 000000000000..684ff3248fbe --- /dev/null +++ b/metadata/news/2022-06-13-python3-10/2022-06-13-python3-10.pl.txt @@ -0,0 +1,133 @@ +Title: Python 3.10 stanie się domyślną wersją począwszy od 2022-07-01 +Author: Michał Górny <mgorny@gentoo.org> +Translator: Michał Górny <mgorny@gentoo.org> +Posted: 2022-06-13 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-lang/python:3.8 +Display-If-Installed: dev-lang/python:3.9 + +Gentoo planuje zmienić domyślną wersję Pythona z 3.9 na 3.10 w dniu +1. lipca 2022 r. Użytkownicy, którzy nie zmieniali wartości flag +PYTHON_TARGETS oraz PYTHON_SINGLE_TARGET nie muszą nic robić. Menadżer +pakietów automatycznie zaktualizuje wsparcie Pythona do nowej wersji +przy kolejnej aktualizacji systemu po tej zmianie. + +Informacje zawarte w tej wiadomości przeznaczone są dla użytkowników, +którzy zmieniali preferowaną wersję Pythona bądź chcą przeprowadzić +aktualizację w bezpieczniejszy sposób. + +Uwaga: standardowa metoda aktualizacji podmienia obsługiwaną wersję +Pythona w poszczególnych pakietach w miarę ich aktualizacji. +Oznacza to, że aktualizacja systemu możliwa będzie wyłącznie, jeżeli +wszystkie zainstalowane pakiety obsługują nową wersję. W trakcie +aktualizacji zależności poszczególnych zainstalowanych programów mogą +stać się tymczasowo niedostępne, nie powinno to jednak mieć wpływu +na działanie już uruchomionych aplikacji. + + +Użytkownicy, którzy wykorzystują plik make.conf do ustawienia wartości +zmiennych PYTHON_TARGETS lub PYTHON_SINGLE_TARGET powinni usunąć +te wartości, gdyż będą one kolidowały z przykładami package.use +przedstawionymi w tej wiadomości. Wykorzystywanie pliku make.conf +do konfiguracji tych zmiennych jest niewskazane, gdyż ustawienia te +nadpisują domyślne wartości flag zawarte w poszczególnych pakietach. +Dalszy ciąg tej wiadomości zakłada wykorzystywanie package.use +lub równoważnego pliku konfiguracyjnego. + + +Dostępne są następujące możliwości aktualizacji: + +1. Automatyczna aktualizacja wersji Pythona. Aby skorzystać z tej + opcji, należy usunąć zmienne PYTHON_TARGETS + oraz PYTHON_SINGLE_TARGET. Wówczas menadżer pakietów automatycznie + przeprowadzi aktualizację ilekroć zmieni się domyślna wersja Pythona + w Gentoo. Niemniej, może zaistnieć konieczność ręcznej aktualizacji + w przypadku wystąpienia problemów. + +2. Odroczenie aktualizacji poprzez wymuszenie poprzedniej wersji + w pliku package.use. + +3. Wymuszenie wcześniejszej aktualizacji poprzez podanie nowej wersji + i dokonanie aktualizacji systemu. + +4. Zastosowanie bezpiecznego podejścia (tj. zmniejszającego ryzyko + niesprawnych programów w trakcie aktualizacji) poprzez wykonanie + aktualizacji w kilku krokach. Proces ten jest szczegółowo opisany + w dalszej części wiadomości. + +5. Zastosowanie dowolnej kombinacji zmiennych PYTHON_TARGETS + oraz PYTHON_SINGLE_TARGET. + + +Odroczenie aktualizacji +======================= +Aby odroczyć aktualizację do późniejszego terminu, należy wymusić +poprzednią wersję Pythona: + + */* PYTHON_TARGETS: -* python3_9 + */* PYTHON_SINGLE_TARGET: -* python3_9 + +W ten sposób Python 3.9 zostanie wymuszony na stałe i przyszłe +aktualizacje zostaną zablokowane. Należy jednak pamiętać, że jest +to rozwiązanie tymczasowe i w przyszłości aktualizacja stanie się +konieczna. + + +Wymuszenie aktualizacji +======================= +Aby wymusić aktualizację wcześniej, należy wybrać Pythona 3.10: + + */* PYTHON_TARGETS: -* python3_10 + */* PYTHON_SINGLE_TARGET: -* python3_10 + +Zalecane jest jednak usunięcie tych ustawień po podanym wyżej terminie, +aby nie kolidowały w przyszłości z kolejną zmianą domyślnej wersji +Pythona. + + +Bezpieczna procedura aktualizacji +================================= +Bezpieczniejszą alternatywą do standardowego procesu jest wprowadzenie +wsparcia Pythona 3.10 w pierwszym kroku, a następnie usunięcie Pythona +3.9. Należy jednak pamiętać, że będzie wymagało to dwukrotnego +przebudowania wszystkich pakietów używających Pythona, tak więc łączny +czas aktualizacji zostanie wydłużony. + +Najpierw załączyć należy obydwie wersje Pythona i przeprowadzić +aktualizację systemu: + + */* PYTHON_TARGETS: -* python3_9 python3_10 + */* PYTHON_SINGLE_TARGET: -* python3_9 + +Następnie przełączyć należy wartość PYTHON_SINGLE_TARGET i przebudować +pakiety używające tych flag: + + */* PYTHON_TARGETS: -* python3_9 python3_10 + */* PYTHON_SINGLE_TARGET: -* python3_10 + +W ostatnim kroku należy wyłączyć poprzednią wersję i przeprowadzić +kolejną aktualizację: + + */* PYTHON_TARGETS: -* python3_10 + */* PYTHON_SINGLE_TARGET: -* python3_10 + +Po terminie zmiany domyślnych wartości, konfigurację tę można usunąć. +Alternatywnie, pozostawienie jej zablokuje przyszłą aktualizację +do Pythona 3.11 i pozwoli na ręczne przeprowadzenie bezpieczniej +aktualizacji. + + +Proces aktualizacji +=================== +Usunięcie Pythona 3.9 wymaga, by odpowiednie flagi zostały jednocześnie +wyłączone w całym drzewie zależności. Jeżeli niektóre z zainstalowanych +pakietów nie zostaną uwzględnione w planowanej aktualizacji, mogą one +zablokować ten proces. Dlatego też istotne jest przeprowadzenie +aktualizacji przy pomocy parametrów `--deep --changed-use @world` bądź +równoważnych, jak również wcześniejsze usunięcie niepotrzebnych +pakietów. Można tego dokonać używając poleceń: + + emerge --depclean + emerge -1vUD @world + emerge --depclean diff --git a/metadata/news/2022-06-13-python3-10/2022-06-13-python3-10.ru.txt b/metadata/news/2022-06-13-python3-10/2022-06-13-python3-10.ru.txt new file mode 100644 index 000000000000..cc92b9212389 --- /dev/null +++ b/metadata/news/2022-06-13-python3-10/2022-06-13-python3-10.ru.txt @@ -0,0 +1,120 @@ +Title: Python 3.10 станет базовым с 2022-07-01 +Author: Michał Górny <mgorny@gentoo.org> +Translator: Alexey Sokolov <alexey+gentoo@asokolov.org> +Posted: 2022-06-13 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-lang/python:3.8 +Display-If-Installed: dev-lang/python:3.9 + +1 июля 2022 года мы собираемся переключить Python target, используемый +по умолчанию на системах Gentoo, с версии 3.9 на версию 3.10. +Если вы не меняли значения переменных 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_9 + */* PYTHON_SINGLE_TARGET: -* python3_9 + +Это заставит систему использовать Python 3.9 и предотвратит последующие +обновления. Однако, учтите, что такое решение временное, +и в конце концов вам всё-таки придётся провести обновление. + + +Принудительное обновление +========================= +Чтобы обновиться до Python 3.10 раньше, явно укажите новые значения: + + */* PYTHON_TARGETS: -* python3_10 + */* PYTHON_SINGLE_TARGET: -* python3_10 + +При этом важно не забыть удалить эти строки после изменения значений +по умолчанию, иначе они помешают последующим автоматическим обновлениям +на следующие версии Python. + + +Процедура безопасного обновления +================================ +Более безопасный подход такой: сначала добавляется в систему поддержка +Python 3.10, а затем удаляется поддержка Python 3.9. Однако, учтите, +что все затронутые пакеты будут пересобраны дважды, что заметно дольше. + +Сначала включите Python 3.9 и Python 3.10 и запустите команды обновления: + + */* PYTHON_TARGETS: -* python3_9 python3_10 + */* PYTHON_SINGLE_TARGET: -* python3_9 + +Затем замените PYTHON_SINGLE_TARGET и ещё раз запустите обновление: + + */* PYTHON_TARGETS: -* python3_9 python3_10 + */* PYTHON_SINGLE_TARGET: -* python3_10 + +Наконец, переключитесь на окончательную версию и запустите обновление: + + */* PYTHON_TARGETS: -* python3_10 + */* PYTHON_SINGLE_TARGET: -* python3_10 + +После смены значений по умолчанию вы можете удалить эти настройки. +Или же вы можете оставить их, предотвращая автоматическое обновление +до Python 3.11, и позже обновиться вручную. + + +Команды обновления +================== +Для очистки системы от Python 3.9 требуется удалить его сразу из +всего дерева зависимостей. Если какие-то установленные пакеты, +использующие старую версию Python, не помечены для обновления, +пакетный менеджер покажет ошибки зависимостей. Поэтому важно проводить +обновление с использованием опций --deep --changed-use @world, +а также перед этим удалить все более не требуемые пакеты: + + emerge --depclean + emerge -1vUD @world + emerge --depclean diff --git a/metadata/news/2022-06-26-mu-corruption/2022-06-26-mu-corruption.en.txt b/metadata/news/2022-06-26-mu-corruption/2022-06-26-mu-corruption.en.txt new file mode 100644 index 000000000000..4b4b1b9da440 --- /dev/null +++ b/metadata/news/2022-06-26-mu-corruption/2022-06-26-mu-corruption.en.txt @@ -0,0 +1,22 @@ +Title: Mu 1.7.23 Causing Maildir Corruption +Author: Matthew Smith <matthew@gentoo.org> +Posted: 2022-06-26 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: =net-mail/mu-1.7.23 + +Development versions of mu between 1.7.18 and 1.7.25 (only 1.7.23 was ever +packaged in Gentoo) have a bug causing mail file names to sometimes get mangled +after moving messages between directories. Symptoms include unread messages +never being marked as read. + +Affected messages have the ':2,' flag appended multiple times. Using the +following commands, users can remove the extra flags. + + find ~/Maildir -name '*:2,*:*' | + sed "s/\(\([^:]*\)\(:2,\)\{1,\}\(:2,.*$\)\)/mv '\0' '\2\4'/" \ + > rename.sh + # review rename.sh. empty file indicates that you are unaffected + sh rename.sh + +Upstream issue: https://github.com/djcb/mu/issues/2268 diff --git a/metadata/news/2022-07-29-pipewire-sound-server/2022-07-29-pipewire-sound-server.en.txt b/metadata/news/2022-07-29-pipewire-sound-server/2022-07-29-pipewire-sound-server.en.txt new file mode 100644 index 000000000000..81b31f66a8e8 --- /dev/null +++ b/metadata/news/2022-07-29-pipewire-sound-server/2022-07-29-pipewire-sound-server.en.txt @@ -0,0 +1,167 @@ +Title: PipeWire sound server migration +Author: Sam James <sam@gentoo.org> +Posted: 2022-07-29 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: media-video/pipewire +Display-If-Installed: media-sound/pulseaudio +Display-If-Installed: media-sound/pulseaudio-daemon +Display-If-Installed: media-libs/libpulse + +PipeWire has gained a new USE flag "sound-server" for enabling/disabling its +sound server capabilities. + +This change is needed to avoid PipeWire and PulseAudio conflicting over control +of audio devices. Before this change, OpenRC users were in some cases +accidentally migrated to PipeWire which was difficult to override without +manually editing launcher files. + +For non-audio purposes, PipeWire is installed in many configurations as more +and more software depends on it for e.g. screensharing, sandboxing, +and window previews, so users will need to act based on their preferred +setup rather than simply avoiding installing PipeWire, as it is +increasingly required as a dependency. + +Packages needing PulseAudio's APIs will be migrated from the now-meta package +media-sound/pulseaudio to depending on media-libs/libpulse. The runtime +PulseAudio server can be provided by either PipeWire (media-video/pipewire) +or the original PulseAudio (media-sound/pulseaudio-daemon). + +The new sound-server USE flag for PipeWire allows easily controlling +this behavior. + +There are several options available: + +1. To use PipeWire for sound, users should enable USE=sound-server for PipeWire: + + Place the following entries in /etc/portage/package.use: + ``` + media-video/pipewire sound-server + media-sound/pulseaudio -daemon + ``` + + First, sync: + # emerge --sync + + Deselect media-sound/pulseaudio-daemon: + # emerge --deselect media-sound/pulseaudio-daemon + + Then perform a world upgrade with PipeWire on the command line to add + it to the world file: + # emerge --ask --update --changed-use --deep @world media-video/pipewire + + Then depclean: + # emerge --ask --depclean + + OpenRC users on an XDG-compliant desktop which respects autostart files + will not need to take any further action. + + OpenRC users using a minimal desktop which does not respect autostart + files will need to run `gentoo-pipewire-launcher &` in e.g. + `~/.xprofile`. + + Users who want to switch to PipeWire providing a PulseAudio daemon + may need to `emerge --deselect` packages in their world file which + hard-require media-sound/pulseaudio-daemon. There are only a handful + of these. A non-exhaustive list: + * media-sound/paprefs + * media-sound/pasystray + * media-sound/pulseaudio-modules-bt (shouldn't be needed anyway) + * net-misc/pulseaudio-dlna + + If not using any of those packages anymore, please emerge --deselect + them. If still using these, PipeWire as a PulseAudio is not an + option at this time. + + (Note that media-libs/libpulse (which PipeWire will be using, don't emerge + libpulse manually) provides 'pactl' which can be used as a replacement for + e.g. media-sound/pulseaudio-ctl, so personal scripts can be adapted to this + if desired.) + + systemd users will also need to run the following commands: + $ systemctl --user --now disable pulseaudio.service pulseaudio.socket + $ systemctl --user --now enable pipewire.socket pipewire-pulse.socket + $ systemctl --user --now disable pipewire-media-session.service + $ systemctl --user --force enable wireplumber.service + + Root user may replace --user with --global to change system default + configuration for all of the above commands. + +2. To use PulseAudio's daemon for sound, users should disable USE=sound-server + for PipeWire, enable USE=daemon on media-sound/pulseaudio, and add + media-sound/pulseaudio-daemon to their world file: + + Place the following entries in /etc/portage/package.use: + ``` + media-video/pipewire -sound-server + media-sound/pulseaudio daemon + ``` + + Add media-sound/pulseaudio-daemon to @world: + # emerge --noreplace media-sound/pulseaudio-daemon + + Then perform a world upgrade: + # emerge --ask --update --changed-use --deep @world + + Then depclean: + # emerge --ask --depclean + + OpenRC users on an XDG-compliant desktop which respects autostart files + will not need to take any further action. + + OpenRC users using a minimal desktop which does not respect autostart + files should consider adding `gentoo-pipewire-launcher &` in e.g. + `~/.xprofile` but it's not strictly required in terms of audio + handling. It may be required in future for the non-audio usecases + described above. + + systemd users will also need to run the following commands: + $ systemctl --user --now enable pulseaudio.service pulseaudio.socket + $ systemctl --user --now disable pipewire.socket pipewire-pulse.socket + + Alternatively, systemd users can run the following commands as root to change + the default for all users: + # systemctl --global enable pulseaudio.service pulseaudio.socket + # systemctl --global --force disable pipewire.socket pipewire-pulse.socket + + (If taking this option, the services must be started manually as a one-off as + a user.) + +3. For users without sound on their system, those using JACK without + PipeWire, or those using pure ALSA without PipeWire, the following steps + are recommended: + + Place the following entries in /etc/portage/package.use: + ``` + media-video/pipewire -sound-server + media-sound/pulseaudio -daemon + ``` + + Then perform a world upgrade: + # emerge --ask --update --changed-use --deep @world + + Then depclean: + # emerge --ask --depclean + + OpenRC users on an XDG-compliant desktop which respects autostart files + will not need to take any further action. + + OpenRC users using a minimal desktop which does not respect autostart + files will need to run `gentoo-pipewire-launcher &` in e.g. + `~/.xprofile`. + + systemd users will also likely want to run the following commands as a user, again + for the purposes of non-audio PipeWire use: + $ systemctl --user --now enable pipewire.socket + $ systemctl --user --now --force enable wireplumber.service + + Alternatively, systemd users can run the following commands as root to change + the default for all users, again for the purposes of non-audio PipeWire use: + # systemctl --global enable pipewire.socket + # systemctl --global --force enable wireplumber.service + + (If taking this option, the services must be started manually as a one-off as + a user.) + +Further resources: +* https://wiki.gentoo.org/wiki/PipeWire diff --git a/metadata/news/2022-11-19-lvm2-default-USE-flags/2022-11-19-lvm2-default-USE-flags.en.txt b/metadata/news/2022-11-19-lvm2-default-USE-flags/2022-11-19-lvm2-default-USE-flags.en.txt new file mode 100644 index 000000000000..9be28307ba59 --- /dev/null +++ b/metadata/news/2022-11-19-lvm2-default-USE-flags/2022-11-19-lvm2-default-USE-flags.en.txt @@ -0,0 +1,34 @@ +Title: LVM2 default USE flag change +Author: David Seifert <soap@gentoo.org> +Posted: 2022-11-19 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-fs/lvm2 + +The Gentoo Base System team has recently switched from the disabling +"device-mapper-only" flag to the enabling "lvm" (bug #718910). + +After considering most reverse dependencies of sys-fs/lvm2, the Base System Team +has decided that the majority of Gentoo users are unlikely to use the LVM2 +components of sys-fs/lvm2, instead relying solely on it providing device-mapper +functionality. + +To this end, we will disable the default enabled flag "+lvm" on sys-fs/lvm2 +on 2023-01-01. If you do not have USE=lvm somehow globally enabled, this means +you will lose LVM2 (but not device-mapper!) functionality, so enable it in your +config if your boot configuration depends on it or if you depend on any of the +lvm2-* daemons. + +If you use LVM2 for any partitions, or if you use tools like 'lvchange', you +should enable USE=lvm. + +Furthermore, we have considered other default enabled USE flags too, and have +come to the conclusion that USE=+thin makes even less sense than USE=+lvm. +Thin-provisioned LVM volumes are an important use case in certain VM hosting +scenarios, but unlikely to be relevant for the large majority of Gentoo users. + +In summary: +- Enable USE="lvm" if you use lvm2 (but not needed for device-mapper) as described above. + This includes using LVM for any partitions. +- Enable USE="lvm thin" if you use thin as described above. +- If you don't know what LVM2 is, you don't need to take any action. diff --git a/metadata/news/2022-11-21-tmpfiles-clean/2022-11-21-tmpfiles-clean.en.txt b/metadata/news/2022-11-21-tmpfiles-clean/2022-11-21-tmpfiles-clean.en.txt new file mode 100644 index 000000000000..c4038eaac305 --- /dev/null +++ b/metadata/news/2022-11-21-tmpfiles-clean/2022-11-21-tmpfiles-clean.en.txt @@ -0,0 +1,16 @@ +Title: systemd-tmpfiles --clean enabled by default +Author: Mike Gilbert <floppym@gentoo.org> +Posted: 2022-11-21 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/systemd-utils[tmpfiles] + +Starting with sys-apps/systemd-utils-251.8-r1, a script is installed in +/etc/cron.daily to run "systemd-tmpfiles --clean" once per day. This +will remove stale temp files based on settings specified in tmpfiles.d. + +This change is meant to mimic the behavior of +systemd-tmpfiles-clean.timer from systemd on systems running OpenRC. + +If you wish to opt-out, simply comment out the command in +/etc/cron.daily/systemd-tmpfiles-clean. diff --git a/metadata/news/2022-12-01-systemd-usrmerge/2022-12-01-systemd-usrmerge.en.txt b/metadata/news/2022-12-01-systemd-usrmerge/2022-12-01-systemd-usrmerge.en.txt new file mode 100644 index 000000000000..be1870c18d5f --- /dev/null +++ b/metadata/news/2022-12-01-systemd-usrmerge/2022-12-01-systemd-usrmerge.en.txt @@ -0,0 +1,44 @@ +Title: /usr merge for systemd users +Author: Mike Gilbert <floppym@gentoo.org> +Posted: 2022-12-01 +Revision: 3 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/systemd + +In the latter half of 2023, systemd will drop support for +split-usr/unmerged-usr systems [1]. All Gentoo systems running systemd +will need to be migrated to merged-usr. + +Migrating to merged-usr will move all data from /bin, /sbin, and /lib +into the /usr/bin and /usr/lib directories. The directories in / are +replaced with symlinks. + +To facilitate this, a new set of sub-profiles has been created, and a +script is available to perform the actual migration. + +To migrate a system to merged-usr, follow this procedure: + +1. Ensure your system backups are up to date. + +2. Install sys-apps/merge-usr. + +3. Run "merge-usr --dryrun" as root to check for conflicts. These will + appear with the word ERROR at the start of the line. + +4. Resolve any conflicts. This may involve deleting duplicate files. If + in doubt, seek support in a Gentoo support channel. + +5. Run the merge-usr script from a root shell. Avoid running it via sudo + directly to avoid locking yourself out if an unexpected error occurs. + +6. Switch to a merged-usr profile. + eg. eselect profile set default/linux/amd64/17.1/systemd/merged-usr + +7. Run emerge with the --newuse or --changed-use option to rebuild + any packages that have a "split-usr" USE flag. + eg. emerge -uDN @world + +For new installs, new "mergedusr" stage3 tarballs are being produced for +commonly used profiles. + +[1] https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html 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. |