aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--2016-01-08-some-dhcpcd-hooks-are-now-examples/2016-01-08-some-dhcpcd-hooks-are-now-examples.en.txt21
-rw-r--r--2016-01-27-upgrading-to-apache-2_4/2016-01-27-upgrading-to-apache-2_4.en.txt23
-rw-r--r--2016-04-07-kde-plasma5-stable/2016-04-07-kde-plasma5-stable.en.txt38
-rw-r--r--2016-04-24-default-video-cards/2016-04-24-default-video-cards.en.txt27
-rw-r--r--2016-05-23-lastpass-changes/2016-05-23-lastpass-changes.en.txt30
-rw-r--r--2016-06-23-l10n-use_expand/2016-06-23-l10n-use_expand.en.txt49
-rw-r--r--2016-08-08-openafs-debug_rodata/2016-08-08-openafs-debug_rodata.en.txt30
-rw-r--r--2016-09-26-migration-to-sys-libs_uclibc-ng/2016-09-26-migration-to-sys-libs_uclibc-ng.en.txt47
-rw-r--r--2016-09-27-openrc_0_22_updates/2016-09-27-openrc_0_22_updates.en.txt22
-rw-r--r--2016-10-25-llvm_3_9_with_llvm_targets/2016-10-25-llvm_3_9_with_llvm_targets.en.txt41
-rw-r--r--2016-11-04-important_fstab_and_localmount_update/2016-11-04-important_fstab_and_localmount_update.en.txt28
-rw-r--r--2016-12-06-ruby-20-removal/2016-12-06-ruby-20-removal.en.txt27
-rw-r--r--2017-01-15-kde-plasma-4-removal/2017-01-15-kde-plasma-4-removal.en.txt50
-rw-r--r--2017-01-21-python-exec-2-3-reclaims-python-symlinks/2017-01-21-python-exec-2-3-reclaims-python-symlinks.en.txt40
-rw-r--r--2018-05-22-python3-6/2018-05-22-python3-6.en.txt61
-rw-r--r--2020-04-22-python3-7/2020-04-22-python3-7.en.txt70
-rw-r--r--2020-09-28-python-2-7-cleanup/2020-09-28-python-2-7-cleanup.en.txt59
-rw-r--r--2021-01-30-python-preference-to-follow-python-targets/2021-01-30-python-preference-to-follow-python-targets.en.txt48
-rw-r--r--2021-01-30-python-preference-to-follow-python-targets/2021-01-30-python-preference-to-follow-python-targets.ru.txt49
-rw-r--r--2021-05-05-python3-9/2021-05-05-python3-9.en.txt119
-rw-r--r--2021-05-05-python3-9/2021-05-05-python3-9.ru.txt121
-rw-r--r--2022-06-26-mu-corruption/2022-06-26-mu-corruption.en.txt8
-rw-r--r--2022-07-29-pipewire-sound-server/2022-07-29-pipewire-sound-server.en.txt167
23 files changed, 171 insertions, 1004 deletions
diff --git a/2016-01-08-some-dhcpcd-hooks-are-now-examples/2016-01-08-some-dhcpcd-hooks-are-now-examples.en.txt b/2016-01-08-some-dhcpcd-hooks-are-now-examples/2016-01-08-some-dhcpcd-hooks-are-now-examples.en.txt
deleted file mode 100644
index 848a842..0000000
--- a/2016-01-08-some-dhcpcd-hooks-are-now-examples/2016-01-08-some-dhcpcd-hooks-are-now-examples.en.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Title: Some dhcpcd hooks are now examples
-Author: William Hubbs <williamh@gentoo.org>
-Content-Type: text/plain
-Posted: 2016-01-08
-Revision: 2
-News-Item-Format: 1.0
-Display-If-Installed: <=net-misc/dhcpcd-6.10.0
-
-In dhcpcd-6.10.0, the following hooks are no longer installed in
-/lib/dhcpcd/dhcpcd-hooks by default:
-
-10-wpa_supplicant
-15-timezone
-29-lookup-hostname
-
-These are now installed in /usr/share/dhcpcd/hooks, which is an example
-directory.
-
-If you were using these hooks before you upgrade to 6.10.0, you will
-need to copy them back to the /lib/dhcpcd/dhcpcd-hooks directory after the
-upgrade.
diff --git a/2016-01-27-upgrading-to-apache-2_4/2016-01-27-upgrading-to-apache-2_4.en.txt b/2016-01-27-upgrading-to-apache-2_4/2016-01-27-upgrading-to-apache-2_4.en.txt
deleted file mode 100644
index bff0e7d..0000000
--- a/2016-01-27-upgrading-to-apache-2_4/2016-01-27-upgrading-to-apache-2_4.en.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Title: Upgrading Apache from 2.2 to 2.4
-Author: Dirkjan Ochtman <djc@gentoo.org>
-Content-Type: text/plain
-Posted: 2016-01-27
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: www-servers/apache
-
-With the 2.4 branch released by upstream almost 4 years ago, stable
-Gentoo systems will soon be upgraded from apache 2.2 to apache 2.4.
-When upgrading, some configuration changes will have to be made.
-Upstream has a handy guide:
-
-https://httpd.apache.org/docs/2.4/upgrading.html
-
-For more information on all the new features, start here:
-
-https://httpd.apache.org/docs/trunk/new_features_2_4.html
-
-After emerging Apache 2.4, you will also need to rebuild any
-third-party modules:
-
-emerge -av1 /usr/lib/apache2/modules --exclude=www-servers/apache
diff --git a/2016-04-07-kde-plasma5-stable/2016-04-07-kde-plasma5-stable.en.txt b/2016-04-07-kde-plasma5-stable/2016-04-07-kde-plasma5-stable.en.txt
deleted file mode 100644
index c9302f0..0000000
--- a/2016-04-07-kde-plasma5-stable/2016-04-07-kde-plasma5-stable.en.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Title: KDE Plasma 5 Upgrade
-Author: Michael Palimaka <kensington@gentoo.org>
-Content-Type: text/plain
-Posted: 2016-04-02
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: kde-base/plasma-workspace
-
-KDE Workspaces 4.11 has reached end of life and is no longer supported
-by upstream. It is therefore recommended for all users to upgrade to
-KDE Plasma 5.
-
-A detailed upgrade guide is available[1], but in most cases it is enough to
-switch to the new desktop/plasma profile, update @world, and
-emerge kde-plasma/plasma-meta:
-
-# eselect profile list
-# eselect profile set <target>
-# emerge --ask --changed-use --newrepo --deep world
-# emerge --ask --verbose kde-plasma/plasma-meta
-
-If you normally use KDM to launch Plasma, note that it is no longer supported.
-Upstream recommends x11-misc/sddm instead which is pulled in by plasma-meta by
-default. OpenRC users should edit /etc/conf.d/xdm and update DISPLAYMANAGER.
-Systemd users should run: systemctl reenable sddm.service
-
-Due to an an evolution of KDE upstream's release process[2], the traditional
-monolithic KDE 4 release is now split into three distinct components. This
-means that KDE Applications are now separate from the Plasma desktop and
-older KDE 4-based applications will continue to function as normal inside
-Plasma 5.
-
-KDE Workspaces 4.11 will remain in the tree for a reasonable time, but
-be warned that it is unmaintained and may cause conflicts with
-newer versions of KDE Applications.
-
-[1] https://wiki.gentoo.org/wiki/KDE/Plasma_5_upgrade
-[2] https://dot.kde.org/2013/09/04/kde-release-structure-evolves
diff --git a/2016-04-24-default-video-cards/2016-04-24-default-video-cards.en.txt b/2016-04-24-default-video-cards/2016-04-24-default-video-cards.en.txt
deleted file mode 100644
index 8a94240..0000000
--- a/2016-04-24-default-video-cards/2016-04-24-default-video-cards.en.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Title: Changes in default VIDEO_CARDS
-Author: Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org>
-Content-Type: text/plain
-Posted: 2016-04-24
-Revision: 2
-News-Item-Format: 1.0
-Display-If-Keyword: amd64
-Display-If-Keyword: x86
-Display-If-Installed: x11-drivers/xf86-video-dummy
-Display-If-Installed: x11-drivers/xf86-video-glint
-Display-If-Installed: x11-drivers/xf86-video-mach64
-Display-If-Installed: x11-drivers/xf86-video-mga
-Display-If-Installed: x11-drivers/xf86-video-nv
-Display-If-Installed: x11-drivers/xf86-video-r128
-Display-If-Installed: x11-drivers/xf86-video-savage
-Display-If-Installed: x11-drivers/xf86-video-tdfx
-Display-If-Installed: x11-drivers/xf86-video-trident
-Display-If-Installed: x11-drivers/xf86-video-v4l
-Display-If-Installed: x11-drivers/xf86-video-via
-Display-If-Installed: x11-drivers/xf86-video-vmware
-
-In order to better reflect the graphics chipsets present on modern
-systems, the default VIDEO_CARDS setting has been changed to
-"amdgpu fbdev intel nouveau radeon radeonsi vesa"
-
-If your graphics chipset requires a different driver, and you have not set
-VIDEO_CARDS in make.conf, it is advisable to do that now.
diff --git a/2016-05-23-lastpass-changes/2016-05-23-lastpass-changes.en.txt b/2016-05-23-lastpass-changes/2016-05-23-lastpass-changes.en.txt
deleted file mode 100644
index 4534932..0000000
--- a/2016-05-23-lastpass-changes/2016-05-23-lastpass-changes.en.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Title: LastPass package migration
-Author: Göktürk Yüksek <gokturk@gentoo.org>
-Author: Robin H. Johnson <robbat2@gentoo.org>
-Content-Type: text/plain
-Posted: 2016-05-23
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: app-admin/lastpass
-
-LastPass-3 and earlier versions installed browser extensions along
-with the necessary binary components. LastPass-4 and later versions
-install only the binary components and leave installing the browser
-extensions to the user. Furthermore, LastPass-3 is not available
-anymore, it will be removed soon and users are required to upgrade. A
-transparent package move is not possible due to the mentioned changes
-and a manual migration is required.
-
-The currently installed package must be removed before proceeding with
-the migration:
-
-emerge --unmerge --ask app-admin/lastpass
-
-LastPass for Firefox users can safely upgrade to version 4 by visiting
-the official LastPass website and following the download instructions.
-The browser extension already contains the required binary components.
-No packages need to be installed.
-
-Users of Chrome/Chromium and Opera browsers need to switch to
-app-admin/lastpass-binary-component and follow the instructions
-displayed on the screen after the installation to complete the process.
diff --git a/2016-06-23-l10n-use_expand/2016-06-23-l10n-use_expand.en.txt b/2016-06-23-l10n-use_expand/2016-06-23-l10n-use_expand.en.txt
deleted file mode 100644
index 2ff30d7..0000000
--- a/2016-06-23-l10n-use_expand/2016-06-23-l10n-use_expand.en.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-Title: L10N USE_EXPAND variable replacing LINGUAS
-Author: Mart Raudsepp <leio@gentoo.org>
-Author: Ulrich Müller <ulm@gentoo.org>
-Content-Type: text/plain
-Posted: 2016-06-19
-Revision: 1
-News-Item-Format: 1.0
-
-The L10N variable is replacing LINGUAS as a USE_EXPAND, to avoid a
-conceptual clash with the standard gettext LINGUAS behaviour.
-
-L10N controls which extra localization support will be installed.
-This is commonly used for downloads of additional language packs.
-
-If you have set LINGUAS in your make.conf, you most likely want to add
-its entries also to L10N. Note that while the common two letter language
-codes (like "de" or "fr") are identical, more complex entries have a
-different syntax because L10N now uses IETF language tags. (For example,
-"pt_BR" becomes "pt-BR" and "sr@latin" becomes "sr-Latn".) You can look
-up the available codes in profiles/desc/l10n.desc in the gentoo tree.
-A detailed description of language tags (aka BCP 47) can be found at:
-https://www.w3.org/International/articles/language-tags/
-
-After a transition time for packages to be converted, the LINGUAS
-environment variable will maintain the standard gettext behaviour and
-will work as expected with all package managers. It controls which
-language translations are built and installed. An unset value means all
-available, an empty value means none, and a value can be an unordered
-list of gettext language codes, with or without country codes. Usually
-two letter language codes suffice, but can be narrowed down by country
-codes with a "ll_CC" formatting, where "ll" is the language code and
-"CC" is the country code, e.g., "en_GB". Some rare languages also have
-three letter language codes. Note that LINGUAS does not only affect
-installed gettext catalog files (*.mo), but also lines of translations
-in an always shipped file (e.g., *.desktop).
-
-If you want English with a set LINGUAS, it is suggested to list it with
-the desired country code, in case the default is not the usual "en_US".
-It is also common to list "en" then, in case a package is natively
-written in a different language, but does provide an English translation
-for whichever country. A list of LINGUAS language codes is available at:
-http://www.gnu.org/software/gettext/manual/gettext.html#Language-Codes
-
-If you have per-package customizations of the LINGUAS USE_EXPAND, you
-should also rename those. This typically means changing linguas_* to
-l10n_*, and possibly updating the syntax as described above.
-
-https://wiki.gentoo.org/wiki/Localization/Guide has also been updated to
-reflect this change.
diff --git a/2016-08-08-openafs-debug_rodata/2016-08-08-openafs-debug_rodata.en.txt b/2016-08-08-openafs-debug_rodata/2016-08-08-openafs-debug_rodata.en.txt
deleted file mode 100644
index 3997c7d..0000000
--- a/2016-08-08-openafs-debug_rodata/2016-08-08-openafs-debug_rodata.en.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Title: OpenAFS no longer needs kernel option DEBUG_RODATA
-Author: NP-Hardass <NP-Hardass@gentoo.org>
-Author: Andrew Savchenko <bircoph@gentoo.org>
-Content-Type: text/plain
-Posted: 2016-08-08
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
-Display-If-Keyword: amd64
-Display-If-Keyword: ~amd64-linux
-Display-If-Keyword: ~sparc
-Display-If-Keyword: x86
-Display-If-Keyword: ~x86-linux
-
-As a result of bug #127084 [1], it was determined that OpenAFS's
-kernel module required that the kernel's data structures be
-read-write (CONFIG_DEBUG_RODATA=n). With recent OpenAFS versions
-this limitation is no longer required. We tested the latest version
-of OpenAFS with Linux kernels from 3.4 till 4.6, and determined that
-OpenAFS kernel module works fine with CONFIG_DEBUG_RODATA=y.
-
-Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no
-longer forced in the ebuild. Considering the security implications
-of having CONFIG_DEBUG_RODATA turned off, it is highly advised that
-you adjust your kernel config accordingly. Please note that the
-default setting for CONFIG_DEBUG_RODATA is "y" and unless you have
-another reason for keeping it disabled, we highly recommend that
-you re-enable CONFIG_DEBUG_RODATA.
-
-[1] https://bugs.gentoo.org/show_bug.cgi?id=127084
diff --git a/2016-09-26-migration-to-sys-libs_uclibc-ng/2016-09-26-migration-to-sys-libs_uclibc-ng.en.txt b/2016-09-26-migration-to-sys-libs_uclibc-ng/2016-09-26-migration-to-sys-libs_uclibc-ng.en.txt
deleted file mode 100644
index 6a0e2f0..0000000
--- a/2016-09-26-migration-to-sys-libs_uclibc-ng/2016-09-26-migration-to-sys-libs_uclibc-ng.en.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-Title: Migration to sys-libs/uclibc-ng
-Author: Anthony G. Basile <blueness@gentoo.org>
-Content-Type: text/plain
-Posted: 2016-09-26
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: sys-libs/uclibc
-Display-If-Profile: default/linux/uclibc/amd64
-Display-If-Profile: hardened/linux/uclibc/amd64
-Display-If-Profile: default/linux/uclibc/arm/armv7a
-Display-If-Profile: hardened/linux/uclibc/arm/armv7a
-Display-If-Profile: default/linux/uclibc/mips
-Display-If-Profile: hardened/linux/uclibc/mips
-Display-If-Profile: default/linux/uclibc/mips/mipsel
-Display-If-Profile: hardened/linux/uclibc/mips/mipsel
-Display-If-Profile: default/linux/uclibc/ppc
-Display-If-Profile: hardened/linux/uclibc/ppc
-Display-If-Profile: default/linux/uclibc/x86
-Display-If-Profile: hardened/linux/uclibc/x86
-
-Upstream development of uClibc has been stalled since July 2015 and
-there hasn't been a proper release since May 2012 [1]. New patches
-addressing important issues have been submitted but these have not been
-reviewed nor have they been committed to the master branch. Also,
-backporting even those patches which have been committed to master is
-now impractical as too many intermediate layers of patches conflict.
-For all intents and purposes, upstream uClibc is dead.
-
-Fortunately, a fork called uClibc-ng [2] was begun by Waldemar Brodkorb
-in February 2015 and is actively being maintained. Accordingly,
-Gentoo's Hardened uClibc project will be migrating to uClibc-ng as its
-libc provider. Currently stage3 tarballs based on sys-libs/uclibc-ng
-are available for all supported arches at [3] and these will become the
-default after October 5, 2016. Older stage3s based on sys-libs/uclibc
-will be removed.
-
-Unfortunately, migrating a production system from uclibc to uclibc-ng
-is not straightforward owing to the central role played by libc. A
-migration guide is provided at [4]. This has been tested on live
-systems with success, but the user is cautioned to plan a backup and
-recovery plan should something go wrong.
-
-Refs.
-[1] https://git.uclibc.org/uClibc/log/
-[2] http://uclibc-ng.org/
-[3] http://distfiles.gentoo.org/experimental/
-[4] https://wiki.gentoo.org/wiki/Project:Hardened_uClibc#Migration_to_uClibc-ng
diff --git a/2016-09-27-openrc_0_22_updates/2016-09-27-openrc_0_22_updates.en.txt b/2016-09-27-openrc_0_22_updates/2016-09-27-openrc_0_22_updates.en.txt
deleted file mode 100644
index 48dfe46..0000000
--- a/2016-09-27-openrc_0_22_updates/2016-09-27-openrc_0_22_updates.en.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Title: OpenRC 0.22 updates
-Author: William Hubbs <williamh@gentoo.org>
-Content-Type: text/plain
-Posted: 2016-09-27
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: <=sys-apps/openrc-0.22
-
-OpenRC 0.22 introduces the following changes:
-
-- In previous versions of OpenRC, configuration information was processed
- so that service-specific configuration stored in /etc/conf.d/* was
- overridden by global configuration stored in /etc/rc.conf. OpenRC 0.22
- reverses that. Global configuration stored in /etc/rc.conf is read first
- then overridden by configuration stored in /etc/conf.d/*.
-
-- The swapfiles service, which was basically a copy of the swap service,
- has been removed. If you are only using local swap partitions, as
- described in the handbook for example, this change will not affect you.
- If you are using swap files or swap partitions on network-backed devices
- such as iSCSI, please adjust the dependencies of the swap
- service as shown in /etc/conf.d/swap to reflect your situation.
diff --git a/2016-10-25-llvm_3_9_with_llvm_targets/2016-10-25-llvm_3_9_with_llvm_targets.en.txt b/2016-10-25-llvm_3_9_with_llvm_targets/2016-10-25-llvm_3_9_with_llvm_targets.en.txt
deleted file mode 100644
index d5656db..0000000
--- a/2016-10-25-llvm_3_9_with_llvm_targets/2016-10-25-llvm_3_9_with_llvm_targets.en.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Title: LLVM 3.9 with LLVM_TARGETS
-Author: Michał Górny <mgorny@gentoo.org>
-Content-Type: text/plain
-Posted: 2016-10-25
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: <sys-devel/llvm-3.9
-
-The newest release of LLVM 3.9 has undergone major Gentoo changes,
-and may require explicit action prior to the upgrade. In this release,
-the semi-implicit target choice has been replaced with an explicit
-LLVM_TARGETS flag set.
-
-If you did not enable USE=multitarget, no action should be required.
-The targets for your host CPU, Berkeley Packet Filter (used by some
-packages) and possibly two major GPUs (AMDGPU and NVPTX) will be enabled
-by default which is a superset of the previous default. However, you may
-want to disable some of those targets if you do not intend to install
-packages requiring them (dev-util/bcc, media-libs/mesa).
-
-If you enabled USE=multitarget, you will now need to specify all
-the requested targets explicitly. The old flag will be preserved
-for some time for compatibility reasons; however, it will only enforce
-explicitly selecting all targets.
-
-In order to enable all targets, add the following to your
-/etc/portage/package.use or equivalent file:
-
- sys-devel/llvm LLVM_TARGETS: *
- sys-devel/clang LLVM_TARGETS: *
-
-If you had to use USE=multitarget to enable some of the targets you
-needed, you can now disable the flag and specify those targets
-explicitly.
-
-Please also note that starting with LLVM-4.0, sys-devel/clang will be
-built as a separate package and the enabled LLVM_TARGETS for that
-package will actually enforce requested targets.
-
-Setting LLVM_TARGETS globally is discouraged as it can cause bootstrap
-issues with sys-libs/compiler-rt in the future.
diff --git a/2016-11-04-important_fstab_and_localmount_update/2016-11-04-important_fstab_and_localmount_update.en.txt b/2016-11-04-important_fstab_and_localmount_update/2016-11-04-important_fstab_and_localmount_update.en.txt
deleted file mode 100644
index 3cd9a8f..0000000
--- a/2016-11-04-important_fstab_and_localmount_update/2016-11-04-important_fstab_and_localmount_update.en.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Title: Important fstab and localmount update
-Author: William Hubbs <williamh@gentoo.org>
-Author: Ian Stakenvicius <axs@gentoo.org>
-Display-If-Installed: <=sys-apps/openrc-0.23
-Content-Type: text/plain
-Posted: 2016-11-04
-Revision: 2
-News-Item-Format: 1.0
-
-Recent updates to service scripts in OpenRC and (e)udev have removed the
-requirement for udev to "settle" before its startup completes. The
-result of this is that services which used to wait for udev to finish
-processing all kernel events will now start earlier. One such service
-is localmount.
-
-If "/dev/disk/by-*" device paths are used for mount points in
-fstab, it is possible that those symbolic links will not exist when
-localmount starts and attempts to mount them.
-
-The recommended solution is to convert fstab from using
-"/dev/disk/by-*" to the LABEL=, UUID=, PARTLABEL= or PARTUUID= syntax.
-This syntax is supported directly by both util-linux and busybox's mount
-commands and has no dependency on any device manager. More information
-on this syntax can be found in the fstab(5) and mount(8) man pages.
-
-To force the old behaviour, instead of converting fstab, you can add
-rc_want="dev-settle" to /etc/conf.d/localmount or add udev-settle to the
-sysinit runlevel.
diff --git a/2016-12-06-ruby-20-removal/2016-12-06-ruby-20-removal.en.txt b/2016-12-06-ruby-20-removal/2016-12-06-ruby-20-removal.en.txt
deleted file mode 100644
index c6bc2cf..0000000
--- a/2016-12-06-ruby-20-removal/2016-12-06-ruby-20-removal.en.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Title: Ruby 2.0 removal; Ruby 2.1 default
-Author: Hans de Graaff <graaff@gentoo.org>
-Content-Type: text/plain
-Posted: 2016-12-04
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: <dev-lang/ruby-2.1
-
-Ruby MRI (Matz's Ruby Interpreter) 2.0 was retired by upstream in
-February 2016. [1] Following this, Ruby MRI 2.0 support will be
-removed from Gentoo. We recommend updating to the 'ruby21' target as
-soon as possible if you are still using 'ruby20'.
-
-Check the current setting via:
-
- eselect ruby show
-
-Change the current setting to Ruby MRI 2.1 via:
-
- eselect ruby set ruby21
-
-Packages can be reinstalled for ruby21 only by using the -N option of
-emerge:
-
- emerge -uvDNq world
-
-[1] https://www.ruby-lang.org/en/news/2016/02/24/support-plan-of-ruby-2-0-0-and-2-1/
diff --git a/2017-01-15-kde-plasma-4-removal/2017-01-15-kde-plasma-4-removal.en.txt b/2017-01-15-kde-plasma-4-removal/2017-01-15-kde-plasma-4-removal.en.txt
deleted file mode 100644
index d07bca7..0000000
--- a/2017-01-15-kde-plasma-4-removal/2017-01-15-kde-plasma-4-removal.en.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Title: KDE Plasma 4 and KDE profile removal
-Author: Andreas Sturmlechner <asturm@gentoo.org>
-Content-Type: text/plain
-Posted: 2017-01-08
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: kde-plasma/kdebase-startkde
-Display-If-Installed: kde-plasma/kdm
-Display-If-Profile: default/linux/alpha/13.0/desktop/kde
-Display-If-Profile: default/linux/alpha/13.0/desktop/kde/systemd
-Display-If-Profile: default/linux/amd64/13.0/desktop/kde
-Display-If-Profile: default/linux/amd64/13.0/desktop/kde/systemd
-Display-If-Profile: default/linux/arm/13.0/desktop/kde
-Display-If-Profile: default/linux/arm/13.0/desktop/kde/systemd
-Display-If-Profile: default/linux/arm/13.0/armv4/desktop/kde
-Display-If-Profile: default/linux/arm/13.0/armv4t/desktop/kde
-Display-If-Profile: default/linux/arm/13.0/armv5te/desktop/kde
-Display-If-Profile: default/linux/arm/13.0/armv6j/desktop/kde
-Display-If-Profile: default/linux/arm/13.0/armv7a/desktop/kde
-Display-If-Profile: default/linux/ia64/13.0/desktop/kde
-Display-If-Profile: default/linux/ia64/13.0/desktop/kde/systemd
-Display-If-Profile: default/linux/m68k/13.0/desktop/kde
-Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop/kde
-Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop/kde/systemd
-Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde
-Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde/systemd
-Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/kde
-Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/kde/systemd
-Display-If-Profile: default/linux/sh/13.0/desktop/kde
-Display-If-Profile: default/linux/sparc/13.0/desktop/kde
-Display-If-Profile: default/linux/sparc/13.0/desktop/kde/systemd
-Display-If-Profile: default/linux/x86/13.0/desktop/kde
-Display-If-Profile: default/linux/x86/13.0/desktop/kde/systemd
-
-KDE Plasma 4 has reached end of life in Portage. Upstream dropped support
-in 2015-08-19, no security bugs have been fixed since then. It is therefore
-required for all users to upgrade to KDE Plasma 5.
-
-KDM is being removed as well. Upstream recommends x11-misc/sddm instead which
-is pulled in by plasma-meta by default.
-OpenRC users edit /etc/conf.d/xdm and update DISPLAYMANAGER.
-Systemd users run: systemctl reenable sddm.service
-
-Part of the cleanup will also be the KDE desktop profile, which is superseded
-by the Plasma desktop profile. Please follow the detailed upgrade guide.[1]
-
-KDE Plasma 4.11 packages will be moved to kde-sunset overlay.[2]
-
-[1] https://wiki.gentoo.org/wiki/KDE/Plasma_5_upgrade
-[2] https://wiki.gentoo.org/wiki/Overlay:Kde-sunset
diff --git a/2017-01-21-python-exec-2-3-reclaims-python-symlinks/2017-01-21-python-exec-2-3-reclaims-python-symlinks.en.txt b/2017-01-21-python-exec-2-3-reclaims-python-symlinks/2017-01-21-python-exec-2-3-reclaims-python-symlinks.en.txt
deleted file mode 100644
index 4aa3415..0000000
--- a/2017-01-21-python-exec-2-3-reclaims-python-symlinks/2017-01-21-python-exec-2-3-reclaims-python-symlinks.en.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-Title: python-exec 2.3 reclaims python* symlinks
-Author: Michał Górny <mgorny@gentoo.org>
-Content-Type: text/plain
-Posted: 2017-01-21
-Revision: 1
-News-Item-Format: 1.0
-Display-If-Installed: <app-eselect/eselect-python-20160206
-Display-If-Installed: <dev-lang/python-exec-2.3
-
-The new versions of python-exec (2.3 and newer) are reclaiming multiple
-Python-related symlinks in /usr/bin, most notably /usr/bin/python*. This
-may result in your package manager reporting file collisions.
-
-The respective symlinks were previously either unowned and created
-dynamically by app-eselect/eselect-python, or installed by it. From now
-on, all Python-related symlinks are installed and handled
-by python-exec. This ensures that they respect the python-exec
-configuration files and variables consistently with regular Python
-packages, and improves their reliability.
-
-If you are using FEATURES=collision-protect, Portage will reject
-the upgrade. If this is the case, please temporarily switch to
-FEATURES=protect-owned for the upgrade.
-
-If you are using FEATURES=protect-owned, Portage will verbosely warn
-about the file collisions but will proceed with the upgrade once
-determining no replaced files are owned. Please disregard the warning.
-
-The potentially colliding files are:
-
- * /usr/bin/2to3
- * /usr/bin/idle
- * /usr/bin/pydoc
- * /usr/bin/python
- * /usr/bin/python2
- * /usr/bin/python3
- * /usr/bin/python-config
-
-For more information on python-exec, please see:
-https://wiki.gentoo.org/wiki/Project:Python/python-exec
diff --git a/2018-05-22-python3-6/2018-05-22-python3-6.en.txt b/2018-05-22-python3-6/2018-05-22-python3-6.en.txt
deleted file mode 100644
index c8901e9..0000000
--- a/2018-05-22-python3-6/2018-05-22-python3-6.en.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-Title: Python 3.6 to become the default target
-Author: Michał Górny <mgorny@gentoo.org>
-Posted: 2018-05-22
-Revision: 1
-News-Item-Format: 2.0
-Display-If-Installed: dev-lang/python:3.4
-Display-If-Installed: dev-lang/python:3.5
-
-On 2018-06-22, Python 3.6 will replace Python 3.5 in the default Python
-targets for Gentoo systems. The new default targets will be:
-
- PYTHON_TARGETS="python2_7 python3_6"
- PYTHON_SINGLE_TARGET="python3_6"
-
-If you have not overriden the value of those variables on your system,
-then your package manager will want to use the new targets immediately.
-In order to prevent dependency conflicts, please clean stray packages
-and rebuild/upgrade all packages with USE flag changes after the change,
-e.g.:
-
- emerge --depclean
- emerge -1vUD @world
- emerge --depclean
-
-Please note that upgrading dependencies in place may cause some
-of the package dependencies to be temporarily missing. While this
-should not affect scripts that are already fully loaded, it may cause
-ImportErrors while starting Python scripts or loading additional
-modules (only scripts running Python 3.5 are affected).
-
-In order to improve stability of the upgrade, you may choose to
-temporarily enable both targets, i.e. set in /etc/portage/make.conf
-or its equivalent:
-
- PYTHON_TARGETS="python2_7 python3_5 python3_6"
- PYTHON_SINGLE_TARGET="python3_5"
-
-This will cause the dependencies to include both Python 3.5 and 3.6
-support on the next system upgrade. Once all packages are updated,
-you can restart your scripts, remove the custom setting and run another
-upgrade to remove support for Python 3.5.
-
-If you would like to postpone the switch to Python 3.6, you can copy
-the current value of PYTHON_TARGETS and/or PYTHON_SINGLE_TARGET
-to /etc/portage/make.conf or its equivalent:
-
- PYTHON_TARGETS="python2_7 python3_5"
- PYTHON_SINGLE_TARGET="python3_5"
-
-If you would like to migrate your systems earlier, you can do the same
-with the new value.
-
-If you are still using Python 3.4, please consider switching to a newer
-version as it is reaching its end-of-life. The end-of-life dates
-for the currently used versions are:
-
- Python 3.4 2019-03-16
- Python 2.7 2020-01-01
- Python 3.5 2020-09-13 [1]
-
-[1]:https://devguide.python.org/#status-of-python-branches
diff --git a/2020-04-22-python3-7/2020-04-22-python3-7.en.txt b/2020-04-22-python3-7/2020-04-22-python3-7.en.txt
deleted file mode 100644
index c933ca6..0000000
--- a/2020-04-22-python3-7/2020-04-22-python3-7.en.txt
+++ /dev/null
@@ -1,70 +0,0 @@
-Title: Python 3.7 to become the default target
-Author: Michał Górny <mgorny@gentoo.org>
-Posted: 2020-04-22
-Revision: 1
-News-Item-Format: 2.0
-Display-If-Installed: dev-lang/python:3.6
-Display-If-Installed: dev-lang/python:3.7
-
-On 2020-05-06 (or later), Python 3.7 will replace Python 3.6 as one
-of the default Python targets for Gentoo systems. The new default
-values will be:
-
- PYTHON_TARGETS="python2_7 python3_7"
- PYTHON_SINGLE_TARGET="python3_7"
-
-If you have not overriden these variables on your system, then your
-package manager will switch to the new targets immediately. In order
-to avoid dependency conflicts, please clean stray packages up
-and rebuild/upgrade all packages with USE flag changes after the change,
-e.g.:
-
- emerge --depclean
- emerge -1vUD @world
- emerge --depclean
-
-Please note that during the system upgrade some of the package
-dependencies may temporarily become missing. While this should not
-affect programs that are already fully loaded, it may cause ImportErrors
-when starting Python scripts or loading additional modules (only scripts
-running Python 3.6 are affected).
-
-In order to improve stability of the upgrade, you may choose to
-temporarily enable both targets, i.e. set in /etc/portage/package.use
-or its equivalent:
-
- */* PYTHON_TARGETS: python3_6 python3_7
- */* PYTHON_SINGLE_TARGET: -* python3_6
-
-This will cause the dependencies to include both Python 3.6 and 3.7
-support whenever possible, throughout the next system upgrade. Once all
-packages are updated, you can restart your scripts, remove the setting
-and start another upgrade in order to cleanly remove Python 3.6.
-
-There are still some Gentoo packages that do not support Python 3.7.
-We will be pushing updates to these packages as time permits. However,
-some of them will probably be removed instead.
-
-If you would like to postpone the switch to Python 3.7, you can copy
-the current value of PYTHON_TARGETS and/or PYTHON_SINGLE_TARGET
-to /etc/portage/package.use or its equivalent:
-
- */* PYTHON_TARGETS: -python3_7 python3_6
- */* PYTHON_SINGLE_TARGET: -* python3_6
-
-If you would like to migrate your systems earlier, you can do
-the opposite. Note that if you are running ~arch, you may want to go
-straight for Python 3.8 at this point.
-
-Please note that this switch is long overdue. Python 3.6 is no longer
-receiving bug fixes. Its planned end-of-life is 2021-12-23 but we will
-probably remove it earlier than that. [1]
-
-All above snippets assume using package.use to control USE flags.
-If you still have make.conf entries for these targets, you need
-to remove them. While using make.conf is possible, it is strongly
-discouraged as it does not respect package defaults. The latter
-can help you keep some of Python 3.6 packages without the need to
-explicitly toggle flags per-package.
-
-[1] https://devguide.python.org/#status-of-python-branches
diff --git a/2020-09-28-python-2-7-cleanup/2020-09-28-python-2-7-cleanup.en.txt b/2020-09-28-python-2-7-cleanup/2020-09-28-python-2-7-cleanup.en.txt
deleted file mode 100644
index 5a6e9bc..0000000
--- a/2020-09-28-python-2-7-cleanup/2020-09-28-python-2-7-cleanup.en.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-Title: Python 2.7 cleanup is progressing
-Author: Michał Górny <mgorny@gentoo.org>
-Posted: 2020-09-28
-Revision: 1
-News-Item-Format: 2.0
-Display-If-Installed: dev-lang/python:2.7
-
-Python 2.7 has reached its end-of-life by 2019-12-31, and many projects
-have removed Python 2 support since. During the last few months we have
-been working hard to migrate Gentoo to Python 3, and we have finally
-reached the point making it possible for the vast majority of our users
-to run a system free of Python 2.7 packages (except for the interpreter
-itself).
-
-The few remaining high profile packages (e.g. dev-python/cython)
-are preserving Python 2.7 only for a very few uncommon packages.
-For this reason, we have decided to create new revisions of them having
-Python 2.7 removed. If you do not need Python 2.7 there, your package
-manager should upgrade these packages to the new revisions.
-
-Please note that you may need to manually uninstall any Python 2.7
-packages installed from third-party repositories and/or run `emerge
---depclean` first to remove orphan packages. The recommended process
-for Portage users is:
-
- emerge --depclean
- emerge -vDuU @world
- emerge --depclean
-
-Please note that the Python 2.7 interpreter (without additional Python
-packages) remains necessary to build a few high profile packages,
-in particular Chromium, Mozilla software and PyPy. If you build either
-of these packages from source, you will not be able to permanently
-remove Python 2.7 from your system.
-
-We are going to preserve CPython 2.7 (and PyPy2.7) for as long
-as necessary and provide security fixes to the best of our ability.
-However, please note that we are not able to dedicate resources to
-auditing Python 2.7's code and with little community interest in that,
-it should be considered potentially vulnerable.
-
-If your projects still rely on Python 2.7, we would like to once again
-encourage you to migrate them to Python 3. However, if you really need
-to run them, we suggest using a virtualenv. To create a new Python 2.7
-environment, install dev-python/virtualenv and use the following option:
-
- virtualenv -p /usr/bin/python2.7 ...
-
-To create a PyPy2.7 environment:
-
- virtualenv -p /usr/bin/pypy ...
-
-Modern versions of pip should be able to automatically select older
-versions of packages that still support Python 2.7. Please note that
-these versions are generally no longer supported. They can be buggy,
-vulnerable or simply incompatible with one another.
-
-Please do not forget to add dev-lang/python:2.7 to your @world set
-or it may get depcleaned once all package dependencies are gone.
diff --git a/2021-01-30-python-preference-to-follow-python-targets/2021-01-30-python-preference-to-follow-python-targets.en.txt b/2021-01-30-python-preference-to-follow-python-targets/2021-01-30-python-preference-to-follow-python-targets.en.txt
deleted file mode 100644
index dbdf2a7..0000000
--- a/2021-01-30-python-preference-to-follow-python-targets/2021-01-30-python-preference-to-follow-python-targets.en.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-Title: Python preference to follow PYTHON_TARGETS
-Author: Michał Górny <mgorny@gentoo.org>
-Posted: 2021-01-30
-Revision: 1
-News-Item-Format: 2.0
-
-On 2021-02-01 stable users will switch to a new method of updating
-the preferred Python versions that employs the configuration update
-mechanism in order to follow PYTHON_TARGETS. We will also deprecate
-app-eselect/eselect-python, and it will stop being installed by default
-after 2021-07-01. If you wish to use the newest Python version present
-in your PYTHON_TARGETS, you only have to accept configuration changes.
-If you wish to customize the behavior, read on.
-
-Since 2017, /usr/bin/python and the related non-versioned symlinks
-are wrapped through dev-lang/python-exec. The list of preferred Python
-implementations is stored in /etc/python-exec/python-exec.conf and/or
-per-program /etc/python-exec/<basename>.conf configuration files.
-To preserve backwards compatibility, app-eselect/eselect-python remained
-a wrapper that updated this file.
-
-However, this mechanism alone has proven inconvenient to end users who
-had to update python-exec.conf whenever the default PYTHON_TARGETS
-changed. Thanks to the fallback logic, this was not a major problem
-for software installed via Gentoo packages that always ensure that
-a supported implementation is used. However, users have reported that
-whenever the preference for /usr/bin/python mismatched their
-PYTHON_TARGETS, their custom scripts would break due to unsatisfied
-dependencies. This does not follow the principle of least surprise.
-
-For this reason, we have decided to change the default python-exec
-configuration to match PYTHON_TARGETS by default, in the eclass
-preference order, that is from the newest CPython version to oldest,
-with alternative Python implementations coming afterwards. This change
-will be propagated via the configuration protection mechanism whenever
-dev-lang/python-exec-conf is installed or rebuilt due to PYTHON_TARGETS
-changes. This will permit the users to interactively confirm
-the updates.
-
-If the new default is not correct for you, please use your preferred
-configuration update tool to discard or edit the new configuration file.
-
-Furthermore, dev-lang/python will no longer attempt to automatically
-update the Python interpreter preference, or pull in eselect-python
-automatically. If you wish to continue using it, please install/record
-it explicitly to ensure that it is not unmerged, e.g.:
-
- emerge -n app-eselect/eselect-python
diff --git a/2021-01-30-python-preference-to-follow-python-targets/2021-01-30-python-preference-to-follow-python-targets.ru.txt b/2021-01-30-python-preference-to-follow-python-targets/2021-01-30-python-preference-to-follow-python-targets.ru.txt
deleted file mode 100644
index b099188..0000000
--- a/2021-01-30-python-preference-to-follow-python-targets/2021-01-30-python-preference-to-follow-python-targets.ru.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-Title: Предпочтения Python будут следовать за PYTHON_TARGETS
-Author: Michał Górny <mgorny@gentoo.org>
-Translator: Alexey Sokolov <alexey+gentoo@asokolov.org>
-Posted: 2021-01-30
-Revision: 1
-News-Item-Format: 2.0
-
-1 февраля 2021 пользователи стабильной ветки перейдут на новый метод обновления
-предпочтительной версии Python, который будет использовать значение переменной
-PYTHON_TARGETS и применять механизм обновления конфигураций. Также мы
-объявляем app-eselect/eselect-python устаревшим и по умолчанию перестанем его
-устанавливать. Если вы хотите использовать самую новую версию Python из
-указанных в PYTHON_TARGETS, вам надо только принять изменения конфигурации.
-Если же вам нужно настроить индивидуальное поведение, продолжайте читать.
-
-С 2017 года /usr/bin/python и тому подобные символические ссылки без версии
-являются обёртками с помощью dev-lang/python-exec. Список предпочтительных
-реализаций Python хранится в /etc/python-exec/python-exec.conf и/или в
-/etc/python-exec/<программа>.conf для программ с конфигурацией не по умолчанию.
-Для обратной совместимости app-eselect/eselect-python остался обёрткой, которая
-обновляла этот файл.
-
-Однако сам по себе этот механизм оказался неудобен пользователям, которым
-теперь приходилось обновлять python-exec.conf каждый раз, когда менялась
-переменная PYTHON_TARGETS. Благодаря логике запасных вариантов это не было
-большой проблемой для программ, установленных из репозитория Gentoo, т.к. они
-гарантируют использование поддерживаемой реализации Python. Но пользователи
-сообщали, что, когда предпочтение для /usr/bin/python не совпадало с их
-PYTHON_TARGETS, из-за неудовлетворённых зависимостей ломались пользовательские
-программы, что противоречит принципу наименьшего удивления.
-
-Поэтому мы решили изменить стандартную настройку python-exec, теперь она будет
-совпадать с PYTHON_TARGETS в порядке предпочтения, используемым eclass'ом:
-сначала все CPython, начиная с новейшей версии и заканчивая старейшей, затем
-другие реализации Python. Это изменение будет установлено в систему с помощью
-механизма защиты конфигураций каждый раз при установке или пересборке
-dev-lang/python-exec-conf из-за изменения PYTHON_TARGETS. При этом у
-пользователей будет возможность интерактивно подтвердить данные изменения.
-
-Если новые настройки вам не подходят, пожалуйста, используйте ваш любимый
-инструмент обновления конфигурации, чтобы отбросить изменения или
-отредактировать новый файл.
-
-Более того, dev-lang/python больше не будет пытаться автоматически обновить
-предпочтительную версию Python и больше не будет автоматически затягивать
-eselect-python. Если вы хотите продолжать его использовать, пожалуйста,
-установите его вручную, чтобы он не удалился:
-
- emerge -n app-eselect/eselect-python
diff --git a/2021-05-05-python3-9/2021-05-05-python3-9.en.txt b/2021-05-05-python3-9/2021-05-05-python3-9.en.txt
deleted file mode 100644
index f42ec91..0000000
--- a/2021-05-05-python3-9/2021-05-05-python3-9.en.txt
+++ /dev/null
@@ -1,119 +0,0 @@
-Title: Python 3.9 to become the default on 2021-06-01
-Author: Michał Górny <mgorny@gentoo.org>
-Posted: 2021-05-05
-Revision: 1
-News-Item-Format: 2.0
-Display-If-Installed: dev-lang/python:3.7
-Display-If-Installed: dev-lang/python:3.8
-
-We are planning to switch the default Python target of Gentoo systems
-on 2021-06-01, from Python 3.8 to Python 3.9. If you have not changed
-the values of PYTHON_TARGETS or PYTHON_SINGLE_TARGET, the change will
-have immediate effect on your system and the package manager will try
-to switch automatically on the next upgrade following the change.
-
-If you did change the values, prefer a safer approach or have problems
-with the update, read on.
-
-Please note that the default upgrade method switches packages to the new
-Python versions as they are rebuilt. This means that all interdependent
-packages have to support the new version for the upgrade to proceed,
-and that some programs may temporarily fail to find their dependencies
-throughout the upgrade (although programs that are already started
-are unlikely to be affected).
-
-
-If you have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared
-in make.conf, please remove these declarations as they will interfere
-with the package.use samples provided below. Using make.conf for Python
-targets is discouraged as it prevents package defaults from applying
-when necessary. This news item assumes using /etc/portage/package.use
-or your package manager's equivalent file for configuration.
-
-
-At this point, you have a few configuration options to choose from:
-
-1. If you wish Python upgrades to apply automatically, you can remove
- PYTHON_TARGETS and PYTHON_SINGLE_TARGET declarations. When
- the defaults change, your package manager should handle the upgrade
- automatically. However, you may still need to run the update
- commands if any problems arise.
-
-2. If you wish to defer the upgrade for the time being, you can
- explicitly set the old values in package.use.
-
-3. If you wish to force the upgrade earlier, you can explicitly set
- the new values and run the upgrade commands.
-
-4. If you wish to use a safer approach (i.e. less likely to temporarily
- break packages during the upgrade), you can perform a multi-step
- upgrade as outlined below.
-
-5. Finally, you can use an arbitrary combination of PYTHON_TARGETS
- and PYTHON_SINGLE_TARGET.
-
-
-Deferring the upgrade
-=====================
-To defer the upgrade, explicitly set the old targets:
-
- */* PYTHON_TARGETS: -* python3_8
- */* PYTHON_SINGLE_TARGET: -* python3_8
-
-This will enforce Python 3.8 and block any future updates. However,
-please note that this solution will only be suitable for a few more
-months and you will eventually need to perform the migration.
-
-
-Forcing the upgrade
-===================
-To force the upgrade earlier, explicitly set Python 3.9 targets:
-
- */* PYTHON_TARGETS: -* python3_9
- */* PYTHON_SINGLE_TARGET: -* python3_9
-
-However, it is important to remember to remove this after the defaults
-change, as it will interfere with the automatic switch to the next
-Python version in the future.
-
-
-Safer upgrade procedure
-=======================
-A safer approach is to add Python 3.9 support to your system first,
-and only then remove Python 3.8. However, note that involves two
-rebuilds of all the affected packages, so it will take noticeably
-longer.
-
-First, enable both Python 3.8 and Python 3.9, and then run the upgrade
-commands:
-
- */* PYTHON_TARGETS: -* python3_8 python3_9
- */* PYTHON_SINGLE_TARGET: -* python3_8
-
-Then switch PYTHON_SINGLE_TARGET and run a second batch of upgrades:
-
- */* PYTHON_TARGETS: -* python3_8 python3_9
- */* PYTHON_SINGLE_TARGET: -* python3_9
-
-Finally, switch to the final version and upgrade:
-
- */* PYTHON_TARGETS: -* python3_9
- */* PYTHON_SINGLE_TARGET: -* python3_9
-
-You may wish to remove the target overrides after the defaults switch.
-Alternatively, you can keep them to block the next automatic upgrade
-to Python 3.10, and upgrade manually then.
-
-
-Upgrade commands
-================
-The Python 3.8 cleanup requires that Python 3.8 is removed from complete
-dependency trees in batch. If some of the installed packages using
-an older Python version are not triaged for the upgrade, the package
-manager will throw dependency conflicts. This makes it important that
-the upgrade is carried via a --deep --changed-use @world upgrade,
-as well as that any stray packages are removed prior to it, e.g.:
-
- emerge --depclean
- emerge -1vUD @world
- emerge --depclean
diff --git a/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt b/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt
deleted file mode 100644
index 035c6e2..0000000
--- a/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt
+++ /dev/null
@@ -1,121 +0,0 @@
-Title: Python 3.9 станет базовым с 2021-06-01
-Author: Michał Górny <mgorny@gentoo.org>
-Translator: Alexey Sokolov <alexey+gentoo@asokolov.org>
-Posted: 2021-05-05
-Revision: 1
-News-Item-Format: 2.0
-Display-If-Installed: dev-lang/python:3.7
-Display-If-Installed: dev-lang/python:3.8
-
-1 июня 2021 года мы собираемся переключить Python target, используемый
-по умолчанию на системах Gentoo, с версии 3.8 на версию 3.9.
-Если вы не меняли значения переменных PYTHON_TARGETS или
-PYTHON_SINGLE_TARGET, то упомянутое изменение затронет систему сразу
-и пакетный менеджер попытается переключиться на новый Python target
-автоматически при следующем обновлении системы.
-
-Если вы изменили значения этих переменных, предпочитаете более
-безопасный подход или при обновлении возникли проблемы, то
-продолжайте читать далее.
-
-Пожалуйста, обратите внимание, что метод обновления по умолчанию
-переключает пакеты на новую версию Python после их пересборки.
-Это означает, что все зависящие друг от друга пакеты должны поддерживать
-новую версию Python для продолжения обновления и некоторые программы
-временно могут не находить свои зависимости во время обновления
-(однако, запущенные программы, вероятно, не будут подвержены проблеме).
-
-Если переменные PYTHON_TARGETS или PYTHON_SINGLE_TARGET объявлены
-в вашем make.conf файле, пожалуйста, удалите их, так как они будут
-конфликтовать с представленными ниже примерами конфигурации package.use.
-Мы не рекомендуем использовать файл make.conf для задания значений
-переменных Python target, так как это препятствует применению этих
-значений по умолчанию для пакетов, когда это необходимо. В этой новости
-мы предполагаем, что вы используете файл /etc/portage/package.use
-или ваш эквивалент этого файла конфигурации пакетного менеджера.
-
-С этого момента у вас есть выбор из следующих вариантов настройки:
-
-1. Если вы хотите, чтобы Python обновлялся автоматически, вы можете
- удалить объявленные переменные PYTHON_TARGETS и PYTHON_SINGLE_TARGET.
- Когда их значения по умолчанию изменятся, пакетный менеджер должен
- самостоятельно всё обновить. Но если возникнут проблемы, вам всё ещё
- может понадобиться запустить команды обновления.
-
-2. Если вы хотите пока отложить обновление, вы можете явно указать
- старые значения в файле package.use.
-
-3. Если вы хотите обновиться раньше, вы можете явно задать новые
- значения и запустить команды обновления.
-
-4. Если вы хотите использовать более безопасный подход (т.е. с меньшей
- вероятностью временной поломки пакетов во время обновления),
- вы можете выполнить последовательное обновление, описанное ниже.
-
-5. Наконец, вы можете произвольным образом комбинировать значения
- переменных PYTHON_TARGETS и PYTHON_SINGLE_TARGET.
-
-
-Откладывание обновления
-=======================
-Чтобы отложить обновление, явно укажите старые значения:
-
- */* PYTHON_TARGETS: -* python3_8
- */* PYTHON_SINGLE_TARGET: -* python3_8
-
-Это заставит систему использовать Python 3.8 и предотвратит последующие
-обновления. Однако, учтите, что такое решение применимо только
-в течение несколько месяцев и в конце концов вам всё-таки придётся
-провести обновление.
-
-
-Принудительное обновление
-=========================
-Чтобы обновиться до Python 3.9 раньше, явно укажите новые значения:
-
- */* PYTHON_TARGETS: -* python3_9
- */* PYTHON_SINGLE_TARGET: -* python3_9
-
-При этом важно не забыть удалить эти строки после изменения значений
-по умолчанию, иначе они помешают последующим автоматическим обновлениям
-на следующие версии Python.
-
-
-Процедура безопасного обновления
-================================
-Более безопасный подход такой: сначала добавляется в систему поддержка
-Python 3.9, а затем удаляется поддержка Python 3.8. Однако, учтите,
-что все затронутые пакеты будут пересобраны дважды, что заметно дольше.
-
-Сначала включите Python 3.8 и Python 3.9 и запустите команды обновления:
-
- */* PYTHON_TARGETS: -* python3_8 python3_9
- */* PYTHON_SINGLE_TARGET: -* python3_8
-
-Затем замените PYTHON_SINGLE_TARGET и ещё раз запустите обновление:
-
- */* PYTHON_TARGETS: -* python3_8 python3_9
- */* PYTHON_SINGLE_TARGET: -* python3_9
-
-Наконец, переключитесь на окончательную версию и запустите обновление:
-
- */* PYTHON_TARGETS: -* python3_9
- */* PYTHON_SINGLE_TARGET: -* python3_9
-
-После смены значений по умолчанию вы можете удалить эти настройки.
-Или же вы можете оставить их, предотвращая автоматическое обновление
-до Python 3.10, и позже обновиться вручную.
-
-
-Команды обновления
-==================
-Для очистки системы от Python 3.8 требуется удалить его сразу из
-всего дерева зависимостей. Если какие-то установленные пакеты,
-использующие старую версию Python, не помечены для обновления,
-пакетный менеджер покажет ошибки зависимостей. Поэтому важно проводить
-обновление с использованием опций --deep --changed-use @world,
-а также перед этим удалить все более не требуемые пакеты:
-
- emerge --depclean
- emerge -1vUD @world
- emerge --depclean
diff --git a/2022-06-26-mu-corruption/2022-06-26-mu-corruption.en.txt b/2022-06-26-mu-corruption/2022-06-26-mu-corruption.en.txt
index 40a8ab2..4b4b1b9 100644
--- a/2022-06-26-mu-corruption/2022-06-26-mu-corruption.en.txt
+++ b/2022-06-26-mu-corruption/2022-06-26-mu-corruption.en.txt
@@ -5,10 +5,10 @@ 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 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.
+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.
diff --git a/2022-07-29-pipewire-sound-server/2022-07-29-pipewire-sound-server.en.txt b/2022-07-29-pipewire-sound-server/2022-07-29-pipewire-sound-server.en.txt
new file mode 100644
index 0000000..81b31f6
--- /dev/null
+++ b/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