diff options
Diffstat (limited to 'metadata/news')
65 files changed, 2563 insertions, 0 deletions
diff --git a/metadata/news/2015-02-02-nfs-service-changes/2015-02-02-nfs-service-changes.en.txt b/metadata/news/2015-02-02-nfs-service-changes/2015-02-02-nfs-service-changes.en.txt new file mode 100644 index 000000000000..7e1b2be650ca --- /dev/null +++ b/metadata/news/2015-02-02-nfs-service-changes/2015-02-02-nfs-service-changes.en.txt @@ -0,0 +1,39 @@ +Title: nfs service changes +Author: William Hubbs <williamh@gentoo.org> +Content-Type: text/plain +Posted: 2015-02-02 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <=net-fs/nfs-utils-1.3.1-r1 + +The upgrade to nfs-utils-1.3.1-r1 includes significant service changes +both for OpenRC and systemd users. + +OpenRC users: + +The OpenRC service which handled mounting nfs file systems has been +changed to only start the nfs client daemons and renamed to nfsclient. +Because of this change, if you use OpenRC and mount nfs file systems, +you need to perform the following steps: + +Add nfsclient to the runlevel nfsmount was in before. For example, if +nfsmount was in the default runlevel, run this command: + +rc-update add nfsclient default + +If you use a permanent network connection to the server, make sure +netmount is in the same runlevel as nfsclient. If not, it is recommended +that net-fs/autofs be set up to handle your network mounts. + +Systemd users: + +The nfs systemd units have been renamed. If you are exporting nfs +mounts, you should enable the rpcbind and nfs-server services. If you +are mounting nfs mounts systemd should automatically detect this and +start the nfs-client service. + +More Information: + +The following wiki page has more information about nfs file systems: + +http://wiki.gentoo.org/wiki/NFSv4 diff --git a/metadata/news/2015-02-04-portage-sync-changes/2015-02-04-portage-sync-changes.en.txt b/metadata/news/2015-02-04-portage-sync-changes/2015-02-04-portage-sync-changes.en.txt new file mode 100644 index 000000000000..aeff021602be --- /dev/null +++ b/metadata/news/2015-02-04-portage-sync-changes/2015-02-04-portage-sync-changes.en.txt @@ -0,0 +1,77 @@ +Title: New portage plug-in sync system +Author: Brian Dolbec <dolsen@gentoo.org> +Content-Type: text/plain +Posted: 2015-02-02 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <sys-apps/portage-2.3.62 + +There is a new plug-in sync system in >=sys-apps/portage-2.2.16. +This system will allow third party modules to be easily installed. Look +for a new layman plug-in sync module in layman's next release. Next is +a brief look at the changes. See the url [1] listed below for detailed +descriptions and usage. + +Changes: /etc/portage/repos.conf/* + New setting for all repository types (needed): + auto-sync = yes/no, true/false # default if absent: yes/true + + New for git sync-type: (applies to clone only) + sync-depth = n where n = {0,1,2,3,...} (optional, default = 1) + 0 -- full history + 1 -- shallow clone, only current state (default) + 2,3,... number of history changes to download + + New sync-type modules: + sync-type = svn # sync a subversion repository + sync-type = websync # Perform an emerge-webrsync operation + sync-type = laymanator # (if installed) runs a layman -s action + + New native portage postsync hooks + /etc/portage/postsync.d/* + Runs hooks once, only after all repos have been synced. + /etc/portage/repo.postsync.d/* + Runs each script with three arguments: + repo name, sync-uri, location + Each script is run at the completion of every repo synced. + +Migration: + Edit /etc/portage/repos.conf/*.conf files, add the auto-sync option + to each repository definition. Edit sync-type option to one of the + supported types {rsync, git, cvs, svn, websync, laymanator}. + [some-repo] + ... + sync-type = rsync + auto-sync = yes + + For an existing /etc/portage/repos.conf/layman.conf file: + 1) change/add the sync-type + sync-type = laymanator + 2) Ensure you have the correct layman version installed with + it's laymanator module also installed. + Alternate method: + Please see the wiki page url [1] for detailed instructions. + +Primary control of all sync operations has been moved from emerge to +emaint. "emerge --sync" now just calls the emaint sync module with the +--auto option. The --auto option performs a sync on only those +repositories with the auto-sync setting not set to 'no' or 'false'. If +it is absent, then it will default to yes and "emerge --sync" will sync +the repository. + +NOTE: As a result of the default auto-sync = True/Yes setting, commands + like "eix-sync", "esync -l", "emerge --sync && layman -S" will cause + many repositories to be synced multiple times in a row. Please edit + your configs or scripts to adjust for the new operation. + +WARNING: + Due to the above default. For any repos that you EXPLICITLY do not + want to be synced. You MUST set "auto-sync = no" + +The 'emaint sync' module operates similar to layman. It can sync +single or multiple repos. See "emaint --help" or for more details and +examples see the wiki page listed below [1]. + +Additional help and project API documentation can be found at: + +[1] https://wiki.gentoo.org/wiki/Project:Portage/Sync diff --git a/metadata/news/2015-04-06-apache-addhandler-addtype/2015-04-06-apache-addhandler-addtype.en.txt b/metadata/news/2015-04-06-apache-addhandler-addtype/2015-04-06-apache-addhandler-addtype.en.txt new file mode 100644 index 000000000000..f90d09191dee --- /dev/null +++ b/metadata/news/2015-04-06-apache-addhandler-addtype/2015-04-06-apache-addhandler-addtype.en.txt @@ -0,0 +1,100 @@ +Title: Apache AddHandler/AddType exploit protection +Author: Sebastian Pipping <sping@gentoo.org> +Content-Type: text/plain +Posted: 2015-04-06 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Installed: www-servers/apache + +Apache's directives AddHandler [1] and AddType [2] can be used +to map certain file name extensions (e.g. .php) to a handler +(e.g. application/x-httpd-php). While a line like + + AddHandler application/x-httpd-php .php .php5 .phtml + ^^^^^^^ +matches index.php, it also matches index.php.png. +With + + AddType application/x-httpd-php .php .php5 .phtml + ^^^^ +index.php.png is not executed, but index.php.disabled still is. + + +Apache's notes on multiple file extensions [3] document +a multi-language website as a context where that behavior +may be helpful. Unfortunately, it can also be a security threat. + +Combined with (not just PHP) applications that support +file upload, the AddHandler/AddType directive can get you into +remote code execution situations. + +That is why >=app-eselect/eselect-php-0.7.1-r4 avoids AddHandler +and is shipping + + <FilesMatch "\.(php|php5|phtml)$"> + SetHandler application/x-httpd-php + </FilesMatch> + +instead. + + +Why this news entry? + + * Since Apache configuration lives below /etc, + you need to run etc-update (or a substitute) + to actually have related fixes applied. + To get them into the running instance of Apache, + you need to make it reload its configuration, e.g. + + sudo /etc/init.d/apache2 reload + + * If you are currently relying on AddHandler to execute + secret_database_stuff.php.inc, moving away from AddHandler + could result in serving your database credentials in plain + text. A command like + + find /var/www/ -name '*.php.*' \ + -o -name '*.php5.*' \ + -o -name '*.phtml.*' + + may help discovering PHP files that would no longer be executed. + + Shipping automatic protection for this scenario is not trivial, + but you could manually install protection based on this recipe: + + <FilesMatch "\.(php|php5|phtml|phps)\."> + # a) Apache 2.2 / Apache 2.4 + mod_access_compat + #Order Deny,Allow + #Deny from all + + # b) Apache 2.4 + mod_authz_core + #Require all denied + + # c) Apache 2.x + mod_rewrite + #RewriteEngine on + #RewriteRule .* - [R=404,L] + </FilesMatch> + + * You may be using AddHandler or AddType in other places, + including off-package files. Please have a look. + + * app-eselect/eselect-php is not the only package affected. + There is a dedicated tracker bug at [4]. + As of the moment, affected packages include: + + app-eselect/eselect-php[apache2] + net-nds/gosa-core + www-apache/mod_fastcgi + www-apache/mod_flvx + www-apache/mod_python + www-apache/mod_suphp + www-apps/moinmoin + www-apps/rt[-lighttpd] + + +Thanks to Nico Suhl, Michael Orlitzky and Marc Schiffbauer. + +[1] https://httpd.apache.org/docs/current/mod/mod_mime.html#addhandler +[2] https://httpd.apache.org/docs/current/mod/mod_mime.html#addtype +[3] https://httpd.apache.org/docs/current/mod/mod_mime.html#multipleext +[4] https://bugs.gentoo.org/show_bug.cgi?id=544560 diff --git a/metadata/news/2015-05-01-shorewall-changes/2015-05-01-shorewall-changes.en.txt b/metadata/news/2015-05-01-shorewall-changes/2015-05-01-shorewall-changes.en.txt new file mode 100644 index 000000000000..08d1cdbf1bb4 --- /dev/null +++ b/metadata/news/2015-05-01-shorewall-changes/2015-05-01-shorewall-changes.en.txt @@ -0,0 +1,43 @@ +Title: shorewall is now a single package +Author: Ian Delaney <idella4@gentoo.org> +Content-Type: text/plain +Posted: 2015-05-01 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: net-firewall/shorewall-core +Display-If-Installed: net-firewall/shorewall6 +Display-If-Installed: net-firewall/shorewall-lite +Display-If-Installed: net-firewall/shorewall6-lite +Display-If-Installed: net-firewall/shorewall-init + +Starting with net-firewall/shorewall-4.6 we have re-integrated + + - net-firewall/shorewall-core + - net-firewall/shorewall6 + - net-firewall/shorewall-lite + - net-firewall/shorewall6-lite + - net-firewall/shorewall-init + +into a new all-in-one net-firewall/shorewall ebuild (see bug 522278). + +The new all-in-one ebuild makes maintenance a lot more easier because the +package is proxy-maintained and finding someone who is willing to help +you bumping 6 packages each time you provide an update was not easy in +the past. + +Because net-firewall/shorewall{-core,6,-lite,6-lite,init} is now +integrated in net-firewall/shorewall, we have to hard mask these old +ebuilds in the new monolithic ebuild to prevent file collisions. + +Due to this block we cannot migrate to the new version without user +interaction. Please remove the previous split ebuilds from your system if +you want to upgrade: + + $ emerge --ask --unmerge 'net-firewall/shorewall-*' \ + 'net-firewall/shorewall6*' + + +Please note: +Since the second shorewall-4.6 ebuild is now stabilized and shorewall-4.5 +is not compatible with the perl-5.20 (see bug 524558) we will start the +removal process for shorewall-4.5 ebuilds within the next 30 days. diff --git a/metadata/news/2015-06-08-udev-init-scripts-changes/2015-06-08-udev-init-scripts-changes.en.txt b/metadata/news/2015-06-08-udev-init-scripts-changes/2015-06-08-udev-init-scripts-changes.en.txt new file mode 100644 index 000000000000..5ab36d74f995 --- /dev/null +++ b/metadata/news/2015-06-08-udev-init-scripts-changes/2015-06-08-udev-init-scripts-changes.en.txt @@ -0,0 +1,20 @@ +Title: udev-init-scripts-29 important changes +Author: William Hubbs <williamh@gentoo.org> +Content-Type: text/plain +Posted: 2015-06-08 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Installed: <=sys-fs/udev-init-scripts-29 + +In udev-init-scripts-29 and newer, the udev service script has been +split into udev, udev-settle and udev-trigger. + +This means the settings in /etc/conf.d/udev have also been migrated +to the appropriate /etc/conf.d files, so be careful when you update your +configuration settings. + +udev and udev-trigger will be added to your sysinit runlevel, but not +udev-settle. udev-settle should not be added to a runlevel. Instead, if +a service needs this, it should add "need udev-settle" to its +dependencies. + diff --git a/metadata/news/2015-08-11-nepomuk-removal/2015-08-11-nepomuk-removal.en.txt b/metadata/news/2015-08-11-nepomuk-removal/2015-08-11-nepomuk-removal.en.txt new file mode 100644 index 000000000000..488c980fbed5 --- /dev/null +++ b/metadata/news/2015-08-11-nepomuk-removal/2015-08-11-nepomuk-removal.en.txt @@ -0,0 +1,24 @@ +Title: Nepomuk removal +Author: Johannes Huber <johu@gentoo.org> +Content-Type: text/plain +Posted: 2015-08-11 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: dev-db/virtuoso-server + +With KDE SC 4.13.0 release the default semantic desktop search engine +switched from Nepomuk to Baloo.[1] This change was honoured in Gentoo +by changing the semantic-desktop use flag to cover the new engine and +moving the old to nepomuk use flag. + +The underlaying storage backend for Nepomuk aka Virtuoso DB has a lot +of unsolved upstream issues[2], therefore we will remove it. This means +packages with build options on the old stack will drop them. Other +packages which hard requiring it will be removed. + +If you are still using Nepomuk you can switch to Baloo by globally +enable semantic-desktop and disabling nepomuk use flag in +/etc/portage/make.conf or using one of the kde desktop profiles. + +[1] https://www.kde.org/announcements/4.13/ +[2] https://bugs.gentoo.org/buglist.cgi?quicksearch=virtuoso diff --git a/metadata/news/2015-08-26-ruby-19-removal/2015-08-26-ruby-19-removal.en.txt b/metadata/news/2015-08-26-ruby-19-removal/2015-08-26-ruby-19-removal.en.txt new file mode 100644 index 000000000000..97c2465f7004 --- /dev/null +++ b/metadata/news/2015-08-26-ruby-19-removal/2015-08-26-ruby-19-removal.en.txt @@ -0,0 +1,26 @@ +Title: Ruby 1.9 removal; Ruby 2.0/2.1 default +Author: Manuel Rüger <mrueg@gentoo.org> +Content-Type: text/plain +Posted: 2015-08-26 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Installed: <dev-lang/ruby-2.0 + +Ruby MRI 1.9 has been retired by upstream in February 2015.[1] +We remove Ruby MRI 1.9 support from the tree now. In parallel Ruby MRI 2.1 +support will be activated in base profile's RUBY_TARGETS variable by default +in conjunction with Ruby MRI 2.0. + +If your currently eselected Ruby interpreter is ruby19, our recommendation is +to change it to ruby20. At the moment Ruby MRI 2.0 delivers the best possible +support of all Ruby interpreters in tree. + +Check the current setting via: + + eselect ruby show + +Change the current setting to Ruby MRI 2.0 via: + + eselect ruby set ruby20 + +[1] https://www.ruby-lang.org/en/news/2015/02/23/support-for-ruby-1-9-3-has-ended/ diff --git a/metadata/news/2015-09-09-libvirt-init-script-changes/2015-09-09-libvirt-init-script-changes.en.txt b/metadata/news/2015-09-09-libvirt-init-script-changes/2015-09-09-libvirt-init-script-changes.en.txt new file mode 100644 index 000000000000..83ed083c6ce1 --- /dev/null +++ b/metadata/news/2015-09-09-libvirt-init-script-changes/2015-09-09-libvirt-init-script-changes.en.txt @@ -0,0 +1,24 @@ +Title: libvirt-1.2.19 init script changes +Author: Doug Goldstein <cardoe@gentoo.org> +Content-Type: text/plain +Posted: 2015-09-09 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <app-emulation/libvirt-1.2.19 + +OpenRC Users: + +In libvirt-1.2.19 and newer, the libvirtd init script has been split into +libvirtd and libvirt-guests. + +The purpose of this change is to separate the management of the libvirtd +daemon from the libvirt domains/guests. This means that a number of settings +from /etc/conf.d/libvirtd have been moved to /etc/conf.d/libvirt-guests. These +settings have not been auto-migrated and you are advised to review +/etc/conf.d/libvirt-guests to ensure the behaviors are as you expect. + +You must add libvirt-guests to the same runlevel where you run libvirtd +currently. Otherwise your domains/guests will not be gracefully shutdown and +could result in data loss. To do this run the following commands: + $ rc-update add libvirt-guests + $ service libvirt-guests start diff --git a/metadata/news/2015-10-07-openrc-0-18-localmount-and-netmount-changes/2015-10-07-openrc-0-18-localmount-and-netmount-changes.en.txt b/metadata/news/2015-10-07-openrc-0-18-localmount-and-netmount-changes/2015-10-07-openrc-0-18-localmount-and-netmount-changes.en.txt new file mode 100644 index 000000000000..7b2b688d7147 --- /dev/null +++ b/metadata/news/2015-10-07-openrc-0-18-localmount-and-netmount-changes/2015-10-07-openrc-0-18-localmount-and-netmount-changes.en.txt @@ -0,0 +1,17 @@ +Title: OpenRC-0.18 localmount and netmount changes +Author: William Hubbs <williamh@gentoo.org> +Content-Type: text/plain +Posted: 2015-10-07 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <=sys-apps/openrc-0.18 + +The behaviour of localmount and netmount is changing on Linux systems. +In the past, these services always started successfully. However, now they +will fail if a file system they attempt to mount cannot be mounted. + +If you have file systems listed in fstab which should not be mounted at +boot time, make sure to add noauto to the mount options. If you have +file systems that you want to attempt to mount at boot time but failure +should be allowed, add nofail to the mount options for these file +systems in fstab. diff --git a/metadata/news/2015-10-21-future-support-of-hardened-sources-kernel/2015-10-21-future-support-of-hardened-sources-kernel.en.txt b/metadata/news/2015-10-21-future-support-of-hardened-sources-kernel/2015-10-21-future-support-of-hardened-sources-kernel.en.txt new file mode 100644 index 000000000000..3d5c76cba3d4 --- /dev/null +++ b/metadata/news/2015-10-21-future-support-of-hardened-sources-kernel/2015-10-21-future-support-of-hardened-sources-kernel.en.txt @@ -0,0 +1,62 @@ +Title: Future Support of hardened-sources Kernel +Author: Anthony G. Basile <blueness@gentoo.org> +Content-Type: text/plain +Posted: 2015-10-21 +Revision: 3 +News-Item-Format: 1.0 +Display-If-Installed: sys-kernel/hardened-sources +Display-If-Profile: hardened/linux/amd64 +Display-If-Profile: hardened/linux/amd64/no-multilib +Display-If-Profile: hardened/linux/amd64/no-multilib/selinux +Display-If-Profile: hardened/linux/amd64/selinux +Display-If-Profile: hardened/linux/amd64/x32 +Display-If-Profile: hardened/linux/arm/armv6j +Display-If-Profile: hardened/linux/arm/armv7a +Display-If-Profile: hardened/linux/ia64 +Display-If-Profile: hardened/linux/musl/amd64 +Display-If-Profile: hardened/linux/musl/amd64/x32 +Display-If-Profile: hardened/linux/musl/arm/armv7a +Display-If-Profile: hardened/linux/musl/mips +Display-If-Profile: hardened/linux/musl/mips/mipsel +Display-If-Profile: hardened/linux/musl/ppc +Display-If-Profile: hardened/linux/musl/x86 +Display-If-Profile: hardened/linux/powerpc/ppc32 +Display-If-Profile: hardened/linux/powerpc/ppc64/32bit-userland +Display-If-Profile: hardened/linux/powerpc/ppc64/64bit-userland +Display-If-Profile: hardened/linux/uclibc/amd64 +Display-If-Profile: hardened/linux/uclibc/arm/armv7a +Display-If-Profile: hardened/linux/uclibc/mips +Display-If-Profile: hardened/linux/uclibc/mips/mipsel +Display-If-Profile: hardened/linux/uclibc/ppc +Display-If-Profile: hardened/linux/uclibc/x86 +Display-If-Profile: hardened/linux/x86 +Display-If-Profile: hardened/linux/x86/selinux + +For many years, the Grsecurity team [1] has been supporting two versions of +their security patches against the Linux kernel, a stable and a testing +version, and Gentoo has made both of these available to our users through the +hardened-sources package. However, on August 26 of this year, the team +announced they would no longer be making the stable version publicly +available, citing trademark infringement by a major embedded systems company +as the reason. [2] The stable patches are now only available to sponsors of +Grsecurity and can no longer be distributed in Gentoo. However, the team did +assure us that they would continue to release and support the testing version +as they have in the past. + +What does this means for users of hardened-sources? Gentoo will continue to +make the testing version available through our hardened-sources package but we +will have to drop support for the 3.x series. In a few days, those ebuilds +will be removed from the tree and you will be required to upgrade to a 4.x +series kernel. Since the hardened-sources package only installs the kernel +source tree, you can continue using a currently built 3.x series kernel but +bear in mind that we cannot support you, nor will upstream. Also keep in mind +that the 4.x series will not be as reliable as the 3.x series was, so +reporting bugs promptly will be even more important. Gentoo will continue to +work closely with upstream to stay on top of any problems, but be prepared for +the occasional "bad" kernel. The more reporting we receive from our users, +the better we will be able to decide which hardened-sources kernels to mark +stable and which to drop. + +Refs. +[1] https://grsecurity.net +[2] https://grsecurity.net/announce.php diff --git a/metadata/news/2015-12-16-python-abiflags-rebuild-needed/2015-12-16-python-abiflags-rebuild-needed.en.txt b/metadata/news/2015-12-16-python-abiflags-rebuild-needed/2015-12-16-python-abiflags-rebuild-needed.en.txt new file mode 100644 index 000000000000..7fa3adea7a79 --- /dev/null +++ b/metadata/news/2015-12-16-python-abiflags-rebuild-needed/2015-12-16-python-abiflags-rebuild-needed.en.txt @@ -0,0 +1,53 @@ +Title: Python ABIFLAGS rebuild needed +Author: Mike Gilbert <floppym@gentoo.org> +Content-Type: text/plain +Posted: 2015-12-16 +Revision: 5 +News-Item-Format: 1.0 +Display-If-Installed: =dev-lang/python-3.3.5-r4 +Display-If-Installed: =dev-lang/python-3.3.5-r5 +Display-If-Installed: =dev-lang/python-3.3.5-r6 +Display-If-Installed: =dev-lang/python-3.3.5-r7 +Display-If-Installed: =dev-lang/python-3.3.5-r8 +Display-If-Installed: =dev-lang/python-3.3.5-r9 +Display-If-Installed: ~dev-lang/python-3.3.6 +Display-If-Installed: =dev-lang/python-3.4.3-r4 +Display-If-Installed: =dev-lang/python-3.4.3-r5 +Display-If-Installed: =dev-lang/python-3.4.3-r6 +Display-If-Installed: =dev-lang/python-3.4.3-r7 +Display-If-Installed: =dev-lang/python-3.4.3-r8 +Display-If-Installed: =dev-lang/python-3.4.3-r9 +Display-If-Installed: ~dev-lang/python-3.4.4 +Display-If-Installed: ~dev-lang/python-3.4.5 +Display-If-Installed: =dev-lang/python-3.5.0-r3 +Display-If-Installed: =dev-lang/python-3.5.0-r4 +Display-If-Installed: =dev-lang/python-3.5.0-r5 +Display-If-Installed: =dev-lang/python-3.5.0-r6 +Display-If-Installed: =dev-lang/python-3.5.0-r7 +Display-If-Installed: =dev-lang/python-3.5.0-r8 +Display-If-Installed: =dev-lang/python-3.5.0-r9 +Display-If-Installed: ~dev-lang/python-3.5.1 +Display-If-Installed: ~dev-lang/python-3.5.2 + +For several years, Gentoo has been patching python3 in a way that is +incompatible with PEP 3149 [1]. Gentoo has been enabling the PyMalloc feature, +but our python packages have not carried the appropriate ABI flag. + +We have removed this patch from the most recent dev-lang/python ebuilds at +the time of this writing. One result of this is that any packages which +install python extension modules must be rebuilt. + +You may experience build failures in related packages until this rebuild has +been completed. + +You can rebuild affected packages using the following commands. + +emerge -1v $(find /usr/lib*/python3* -name '*cpython-3[3-5].so') +emerge -1v /usr/include/python3.{3,4,5} + +It is possible that these commands will do nothing (or display a syntax error) +if all affected packages have already been rebuilt, causing the relevent files +to no longer exist. + +References: +[1] https://www.python.org/dev/peps/pep-3149/ diff --git a/metadata/news/2016-01-08-some-dhcpcd-hooks-are-now-examples/2016-01-08-some-dhcpcd-hooks-are-now-examples.en.txt b/metadata/news/2016-01-08-some-dhcpcd-hooks-are-now-examples/2016-01-08-some-dhcpcd-hooks-are-now-examples.en.txt new file mode 100644 index 000000000000..848a842b446c --- /dev/null +++ b/metadata/news/2016-01-08-some-dhcpcd-hooks-are-now-examples/2016-01-08-some-dhcpcd-hooks-are-now-examples.en.txt @@ -0,0 +1,21 @@ +Title: Some dhcpcd hooks are now examples +Author: William Hubbs <williamh@gentoo.org> +Content-Type: text/plain +Posted: 2016-01-08 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Installed: <=net-misc/dhcpcd-6.10.0 + +In dhcpcd-6.10.0, the following hooks are no longer installed in +/lib/dhcpcd/dhcpcd-hooks by default: + +10-wpa_supplicant +15-timezone +29-lookup-hostname + +These are now installed in /usr/share/dhcpcd/hooks, which is an example +directory. + +If you were using these hooks before you upgrade to 6.10.0, you will +need to copy them back to the /lib/dhcpcd/dhcpcd-hooks directory after the +upgrade. diff --git a/metadata/news/2016-01-27-upgrading-to-apache-2_4/2016-01-27-upgrading-to-apache-2_4.en.txt b/metadata/news/2016-01-27-upgrading-to-apache-2_4/2016-01-27-upgrading-to-apache-2_4.en.txt new file mode 100644 index 000000000000..bff0e7d400f9 --- /dev/null +++ b/metadata/news/2016-01-27-upgrading-to-apache-2_4/2016-01-27-upgrading-to-apache-2_4.en.txt @@ -0,0 +1,23 @@ +Title: Upgrading Apache from 2.2 to 2.4 +Author: Dirkjan Ochtman <djc@gentoo.org> +Content-Type: text/plain +Posted: 2016-01-27 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: www-servers/apache + +With the 2.4 branch released by upstream almost 4 years ago, stable +Gentoo systems will soon be upgraded from apache 2.2 to apache 2.4. +When upgrading, some configuration changes will have to be made. +Upstream has a handy guide: + +https://httpd.apache.org/docs/2.4/upgrading.html + +For more information on all the new features, start here: + +https://httpd.apache.org/docs/trunk/new_features_2_4.html + +After emerging Apache 2.4, you will also need to rebuild any +third-party modules: + +emerge -av1 /usr/lib/apache2/modules --exclude=www-servers/apache diff --git a/metadata/news/2016-04-07-kde-plasma5-stable/2016-04-07-kde-plasma5-stable.en.txt b/metadata/news/2016-04-07-kde-plasma5-stable/2016-04-07-kde-plasma5-stable.en.txt new file mode 100644 index 000000000000..c9302f0911ec --- /dev/null +++ b/metadata/news/2016-04-07-kde-plasma5-stable/2016-04-07-kde-plasma5-stable.en.txt @@ -0,0 +1,38 @@ +Title: KDE Plasma 5 Upgrade +Author: Michael Palimaka <kensington@gentoo.org> +Content-Type: text/plain +Posted: 2016-04-02 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: kde-base/plasma-workspace + +KDE Workspaces 4.11 has reached end of life and is no longer supported +by upstream. It is therefore recommended for all users to upgrade to +KDE Plasma 5. + +A detailed upgrade guide is available[1], but in most cases it is enough to +switch to the new desktop/plasma profile, update @world, and +emerge kde-plasma/plasma-meta: + +# eselect profile list +# eselect profile set <target> +# emerge --ask --changed-use --newrepo --deep world +# emerge --ask --verbose kde-plasma/plasma-meta + +If you normally use KDM to launch Plasma, note that it is no longer supported. +Upstream recommends x11-misc/sddm instead which is pulled in by plasma-meta by +default. OpenRC users should edit /etc/conf.d/xdm and update DISPLAYMANAGER. +Systemd users should run: systemctl reenable sddm.service + +Due to an an evolution of KDE upstream's release process[2], the traditional +monolithic KDE 4 release is now split into three distinct components. This +means that KDE Applications are now separate from the Plasma desktop and +older KDE 4-based applications will continue to function as normal inside +Plasma 5. + +KDE Workspaces 4.11 will remain in the tree for a reasonable time, but +be warned that it is unmaintained and may cause conflicts with +newer versions of KDE Applications. + +[1] https://wiki.gentoo.org/wiki/KDE/Plasma_5_upgrade +[2] https://dot.kde.org/2013/09/04/kde-release-structure-evolves diff --git a/metadata/news/2016-04-24-default-video-cards/2016-04-24-default-video-cards.en.txt b/metadata/news/2016-04-24-default-video-cards/2016-04-24-default-video-cards.en.txt new file mode 100644 index 000000000000..8a94240b08e9 --- /dev/null +++ b/metadata/news/2016-04-24-default-video-cards/2016-04-24-default-video-cards.en.txt @@ -0,0 +1,27 @@ +Title: Changes in default VIDEO_CARDS +Author: Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> +Content-Type: text/plain +Posted: 2016-04-24 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Keyword: amd64 +Display-If-Keyword: x86 +Display-If-Installed: x11-drivers/xf86-video-dummy +Display-If-Installed: x11-drivers/xf86-video-glint +Display-If-Installed: x11-drivers/xf86-video-mach64 +Display-If-Installed: x11-drivers/xf86-video-mga +Display-If-Installed: x11-drivers/xf86-video-nv +Display-If-Installed: x11-drivers/xf86-video-r128 +Display-If-Installed: x11-drivers/xf86-video-savage +Display-If-Installed: x11-drivers/xf86-video-tdfx +Display-If-Installed: x11-drivers/xf86-video-trident +Display-If-Installed: x11-drivers/xf86-video-v4l +Display-If-Installed: x11-drivers/xf86-video-via +Display-If-Installed: x11-drivers/xf86-video-vmware + +In order to better reflect the graphics chipsets present on modern +systems, the default VIDEO_CARDS setting has been changed to +"amdgpu fbdev intel nouveau radeon radeonsi vesa" + +If your graphics chipset requires a different driver, and you have not set +VIDEO_CARDS in make.conf, it is advisable to do that now. diff --git a/metadata/news/2016-05-23-lastpass-changes/2016-05-23-lastpass-changes.en.txt b/metadata/news/2016-05-23-lastpass-changes/2016-05-23-lastpass-changes.en.txt new file mode 100644 index 000000000000..4534932a7929 --- /dev/null +++ b/metadata/news/2016-05-23-lastpass-changes/2016-05-23-lastpass-changes.en.txt @@ -0,0 +1,30 @@ +Title: LastPass package migration +Author: Göktürk Yüksek <gokturk@gentoo.org> +Author: Robin H. Johnson <robbat2@gentoo.org> +Content-Type: text/plain +Posted: 2016-05-23 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: app-admin/lastpass + +LastPass-3 and earlier versions installed browser extensions along +with the necessary binary components. LastPass-4 and later versions +install only the binary components and leave installing the browser +extensions to the user. Furthermore, LastPass-3 is not available +anymore, it will be removed soon and users are required to upgrade. A +transparent package move is not possible due to the mentioned changes +and a manual migration is required. + +The currently installed package must be removed before proceeding with +the migration: + +emerge --unmerge --ask app-admin/lastpass + +LastPass for Firefox users can safely upgrade to version 4 by visiting +the official LastPass website and following the download instructions. +The browser extension already contains the required binary components. +No packages need to be installed. + +Users of Chrome/Chromium and Opera browsers need to switch to +app-admin/lastpass-binary-component and follow the instructions +displayed on the screen after the installation to complete the process. diff --git a/metadata/news/2016-06-23-l10n-use_expand/2016-06-23-l10n-use_expand.en.txt b/metadata/news/2016-06-23-l10n-use_expand/2016-06-23-l10n-use_expand.en.txt new file mode 100644 index 000000000000..2ff30d780bff --- /dev/null +++ b/metadata/news/2016-06-23-l10n-use_expand/2016-06-23-l10n-use_expand.en.txt @@ -0,0 +1,49 @@ +Title: L10N USE_EXPAND variable replacing LINGUAS +Author: Mart Raudsepp <leio@gentoo.org> +Author: Ulrich Müller <ulm@gentoo.org> +Content-Type: text/plain +Posted: 2016-06-19 +Revision: 1 +News-Item-Format: 1.0 + +The L10N variable is replacing LINGUAS as a USE_EXPAND, to avoid a +conceptual clash with the standard gettext LINGUAS behaviour. + +L10N controls which extra localization support will be installed. +This is commonly used for downloads of additional language packs. + +If you have set LINGUAS in your make.conf, you most likely want to add +its entries also to L10N. Note that while the common two letter language +codes (like "de" or "fr") are identical, more complex entries have a +different syntax because L10N now uses IETF language tags. (For example, +"pt_BR" becomes "pt-BR" and "sr@latin" becomes "sr-Latn".) You can look +up the available codes in profiles/desc/l10n.desc in the gentoo tree. +A detailed description of language tags (aka BCP 47) can be found at: +https://www.w3.org/International/articles/language-tags/ + +After a transition time for packages to be converted, the LINGUAS +environment variable will maintain the standard gettext behaviour and +will work as expected with all package managers. It controls which +language translations are built and installed. An unset value means all +available, an empty value means none, and a value can be an unordered +list of gettext language codes, with or without country codes. Usually +two letter language codes suffice, but can be narrowed down by country +codes with a "ll_CC" formatting, where "ll" is the language code and +"CC" is the country code, e.g., "en_GB". Some rare languages also have +three letter language codes. Note that LINGUAS does not only affect +installed gettext catalog files (*.mo), but also lines of translations +in an always shipped file (e.g., *.desktop). + +If you want English with a set LINGUAS, it is suggested to list it with +the desired country code, in case the default is not the usual "en_US". +It is also common to list "en" then, in case a package is natively +written in a different language, but does provide an English translation +for whichever country. A list of LINGUAS language codes is available at: +http://www.gnu.org/software/gettext/manual/gettext.html#Language-Codes + +If you have per-package customizations of the LINGUAS USE_EXPAND, you +should also rename those. This typically means changing linguas_* to +l10n_*, and possibly updating the syntax as described above. + +https://wiki.gentoo.org/wiki/Localization/Guide has also been updated to +reflect this change. diff --git a/metadata/news/2016-08-08-openafs-debug_rodata/2016-08-08-openafs-debug_rodata.en.txt b/metadata/news/2016-08-08-openafs-debug_rodata/2016-08-08-openafs-debug_rodata.en.txt new file mode 100644 index 000000000000..3997c7df8113 --- /dev/null +++ b/metadata/news/2016-08-08-openafs-debug_rodata/2016-08-08-openafs-debug_rodata.en.txt @@ -0,0 +1,30 @@ +Title: OpenAFS no longer needs kernel option DEBUG_RODATA +Author: NP-Hardass <NP-Hardass@gentoo.org> +Author: Andrew Savchenko <bircoph@gentoo.org> +Content-Type: text/plain +Posted: 2016-08-08 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2 +Display-If-Keyword: amd64 +Display-If-Keyword: ~amd64-linux +Display-If-Keyword: ~sparc +Display-If-Keyword: x86 +Display-If-Keyword: ~x86-linux + +As a result of bug #127084 [1], it was determined that OpenAFS's +kernel module required that the kernel's data structures be +read-write (CONFIG_DEBUG_RODATA=n). With recent OpenAFS versions +this limitation is no longer required. We tested the latest version +of OpenAFS with Linux kernels from 3.4 till 4.6, and determined that +OpenAFS kernel module works fine with CONFIG_DEBUG_RODATA=y. + +Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no +longer forced in the ebuild. Considering the security implications +of having CONFIG_DEBUG_RODATA turned off, it is highly advised that +you adjust your kernel config accordingly. Please note that the +default setting for CONFIG_DEBUG_RODATA is "y" and unless you have +another reason for keeping it disabled, we highly recommend that +you re-enable CONFIG_DEBUG_RODATA. + +[1] https://bugs.gentoo.org/show_bug.cgi?id=127084 diff --git a/metadata/news/2016-09-26-migration-to-sys-libs_uclibc-ng/2016-09-26-migration-to-sys-libs_uclibc-ng.en.txt b/metadata/news/2016-09-26-migration-to-sys-libs_uclibc-ng/2016-09-26-migration-to-sys-libs_uclibc-ng.en.txt new file mode 100644 index 000000000000..6a0e2f016ab3 --- /dev/null +++ b/metadata/news/2016-09-26-migration-to-sys-libs_uclibc-ng/2016-09-26-migration-to-sys-libs_uclibc-ng.en.txt @@ -0,0 +1,47 @@ +Title: Migration to sys-libs/uclibc-ng +Author: Anthony G. Basile <blueness@gentoo.org> +Content-Type: text/plain +Posted: 2016-09-26 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: sys-libs/uclibc +Display-If-Profile: default/linux/uclibc/amd64 +Display-If-Profile: hardened/linux/uclibc/amd64 +Display-If-Profile: default/linux/uclibc/arm/armv7a +Display-If-Profile: hardened/linux/uclibc/arm/armv7a +Display-If-Profile: default/linux/uclibc/mips +Display-If-Profile: hardened/linux/uclibc/mips +Display-If-Profile: default/linux/uclibc/mips/mipsel +Display-If-Profile: hardened/linux/uclibc/mips/mipsel +Display-If-Profile: default/linux/uclibc/ppc +Display-If-Profile: hardened/linux/uclibc/ppc +Display-If-Profile: default/linux/uclibc/x86 +Display-If-Profile: hardened/linux/uclibc/x86 + +Upstream development of uClibc has been stalled since July 2015 and +there hasn't been a proper release since May 2012 [1]. New patches +addressing important issues have been submitted but these have not been +reviewed nor have they been committed to the master branch. Also, +backporting even those patches which have been committed to master is +now impractical as too many intermediate layers of patches conflict. +For all intents and purposes, upstream uClibc is dead. + +Fortunately, a fork called uClibc-ng [2] was begun by Waldemar Brodkorb +in February 2015 and is actively being maintained. Accordingly, +Gentoo's Hardened uClibc project will be migrating to uClibc-ng as its +libc provider. Currently stage3 tarballs based on sys-libs/uclibc-ng +are available for all supported arches at [3] and these will become the +default after October 5, 2016. Older stage3s based on sys-libs/uclibc +will be removed. + +Unfortunately, migrating a production system from uclibc to uclibc-ng +is not straightforward owing to the central role played by libc. A +migration guide is provided at [4]. This has been tested on live +systems with success, but the user is cautioned to plan a backup and +recovery plan should something go wrong. + +Refs. +[1] https://git.uclibc.org/uClibc/log/ +[2] http://uclibc-ng.org/ +[3] http://distfiles.gentoo.org/experimental/ +[4] https://wiki.gentoo.org/wiki/Project:Hardened_uClibc#Migration_to_uClibc-ng diff --git a/metadata/news/2016-09-27-openrc_0_22_updates/2016-09-27-openrc_0_22_updates.en.txt b/metadata/news/2016-09-27-openrc_0_22_updates/2016-09-27-openrc_0_22_updates.en.txt new file mode 100644 index 000000000000..48dfe46ce467 --- /dev/null +++ b/metadata/news/2016-09-27-openrc_0_22_updates/2016-09-27-openrc_0_22_updates.en.txt @@ -0,0 +1,22 @@ +Title: OpenRC 0.22 updates +Author: William Hubbs <williamh@gentoo.org> +Content-Type: text/plain +Posted: 2016-09-27 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <=sys-apps/openrc-0.22 + +OpenRC 0.22 introduces the following changes: + +- In previous versions of OpenRC, configuration information was processed + so that service-specific configuration stored in /etc/conf.d/* was + overridden by global configuration stored in /etc/rc.conf. OpenRC 0.22 + reverses that. Global configuration stored in /etc/rc.conf is read first + then overridden by configuration stored in /etc/conf.d/*. + +- The swapfiles service, which was basically a copy of the swap service, + has been removed. If you are only using local swap partitions, as + described in the handbook for example, this change will not affect you. + If you are using swap files or swap partitions on network-backed devices + such as iSCSI, please adjust the dependencies of the swap + service as shown in /etc/conf.d/swap to reflect your situation. diff --git a/metadata/news/2016-10-25-llvm_3_9_with_llvm_targets/2016-10-25-llvm_3_9_with_llvm_targets.en.txt b/metadata/news/2016-10-25-llvm_3_9_with_llvm_targets/2016-10-25-llvm_3_9_with_llvm_targets.en.txt new file mode 100644 index 000000000000..d5656db56539 --- /dev/null +++ b/metadata/news/2016-10-25-llvm_3_9_with_llvm_targets/2016-10-25-llvm_3_9_with_llvm_targets.en.txt @@ -0,0 +1,41 @@ +Title: LLVM 3.9 with LLVM_TARGETS +Author: Michał Górny <mgorny@gentoo.org> +Content-Type: text/plain +Posted: 2016-10-25 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <sys-devel/llvm-3.9 + +The newest release of LLVM 3.9 has undergone major Gentoo changes, +and may require explicit action prior to the upgrade. In this release, +the semi-implicit target choice has been replaced with an explicit +LLVM_TARGETS flag set. + +If you did not enable USE=multitarget, no action should be required. +The targets for your host CPU, Berkeley Packet Filter (used by some +packages) and possibly two major GPUs (AMDGPU and NVPTX) will be enabled +by default which is a superset of the previous default. However, you may +want to disable some of those targets if you do not intend to install +packages requiring them (dev-util/bcc, media-libs/mesa). + +If you enabled USE=multitarget, you will now need to specify all +the requested targets explicitly. The old flag will be preserved +for some time for compatibility reasons; however, it will only enforce +explicitly selecting all targets. + +In order to enable all targets, add the following to your +/etc/portage/package.use or equivalent file: + + sys-devel/llvm LLVM_TARGETS: * + sys-devel/clang LLVM_TARGETS: * + +If you had to use USE=multitarget to enable some of the targets you +needed, you can now disable the flag and specify those targets +explicitly. + +Please also note that starting with LLVM-4.0, sys-devel/clang will be +built as a separate package and the enabled LLVM_TARGETS for that +package will actually enforce requested targets. + +Setting LLVM_TARGETS globally is discouraged as it can cause bootstrap +issues with sys-libs/compiler-rt in the future. diff --git a/metadata/news/2016-11-04-important_fstab_and_localmount_update/2016-11-04-important_fstab_and_localmount_update.en.txt b/metadata/news/2016-11-04-important_fstab_and_localmount_update/2016-11-04-important_fstab_and_localmount_update.en.txt new file mode 100644 index 000000000000..3cd9a8f25541 --- /dev/null +++ b/metadata/news/2016-11-04-important_fstab_and_localmount_update/2016-11-04-important_fstab_and_localmount_update.en.txt @@ -0,0 +1,28 @@ +Title: Important fstab and localmount update +Author: William Hubbs <williamh@gentoo.org> +Author: Ian Stakenvicius <axs@gentoo.org> +Display-If-Installed: <=sys-apps/openrc-0.23 +Content-Type: text/plain +Posted: 2016-11-04 +Revision: 2 +News-Item-Format: 1.0 + +Recent updates to service scripts in OpenRC and (e)udev have removed the +requirement for udev to "settle" before its startup completes. The +result of this is that services which used to wait for udev to finish +processing all kernel events will now start earlier. One such service +is localmount. + +If "/dev/disk/by-*" device paths are used for mount points in +fstab, it is possible that those symbolic links will not exist when +localmount starts and attempts to mount them. + +The recommended solution is to convert fstab from using +"/dev/disk/by-*" to the LABEL=, UUID=, PARTLABEL= or PARTUUID= syntax. +This syntax is supported directly by both util-linux and busybox's mount +commands and has no dependency on any device manager. More information +on this syntax can be found in the fstab(5) and mount(8) man pages. + +To force the old behaviour, instead of converting fstab, you can add +rc_want="dev-settle" to /etc/conf.d/localmount or add udev-settle to the +sysinit runlevel. diff --git a/metadata/news/2016-12-06-ruby-20-removal/2016-12-06-ruby-20-removal.en.txt b/metadata/news/2016-12-06-ruby-20-removal/2016-12-06-ruby-20-removal.en.txt new file mode 100644 index 000000000000..c6bc2cf7fb44 --- /dev/null +++ b/metadata/news/2016-12-06-ruby-20-removal/2016-12-06-ruby-20-removal.en.txt @@ -0,0 +1,27 @@ +Title: Ruby 2.0 removal; Ruby 2.1 default +Author: Hans de Graaff <graaff@gentoo.org> +Content-Type: text/plain +Posted: 2016-12-04 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <dev-lang/ruby-2.1 + +Ruby MRI (Matz's Ruby Interpreter) 2.0 was retired by upstream in +February 2016. [1] Following this, Ruby MRI 2.0 support will be +removed from Gentoo. We recommend updating to the 'ruby21' target as +soon as possible if you are still using 'ruby20'. + +Check the current setting via: + + eselect ruby show + +Change the current setting to Ruby MRI 2.1 via: + + eselect ruby set ruby21 + +Packages can be reinstalled for ruby21 only by using the -N option of +emerge: + + emerge -uvDNq world + +[1] https://www.ruby-lang.org/en/news/2016/02/24/support-plan-of-ruby-2-0-0-and-2-1/ diff --git a/metadata/news/2017-01-15-kde-plasma-4-removal/2017-01-15-kde-plasma-4-removal.en.txt b/metadata/news/2017-01-15-kde-plasma-4-removal/2017-01-15-kde-plasma-4-removal.en.txt new file mode 100644 index 000000000000..d07bca7b7f4e --- /dev/null +++ b/metadata/news/2017-01-15-kde-plasma-4-removal/2017-01-15-kde-plasma-4-removal.en.txt @@ -0,0 +1,50 @@ +Title: KDE Plasma 4 and KDE profile removal +Author: Andreas Sturmlechner <asturm@gentoo.org> +Content-Type: text/plain +Posted: 2017-01-08 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: kde-plasma/kdebase-startkde +Display-If-Installed: kde-plasma/kdm +Display-If-Profile: default/linux/alpha/13.0/desktop/kde +Display-If-Profile: default/linux/alpha/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/amd64/13.0/desktop/kde +Display-If-Profile: default/linux/amd64/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/arm/13.0/desktop/kde +Display-If-Profile: default/linux/arm/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/arm/13.0/armv4/desktop/kde +Display-If-Profile: default/linux/arm/13.0/armv4t/desktop/kde +Display-If-Profile: default/linux/arm/13.0/armv5te/desktop/kde +Display-If-Profile: default/linux/arm/13.0/armv6j/desktop/kde +Display-If-Profile: default/linux/arm/13.0/armv7a/desktop/kde +Display-If-Profile: default/linux/ia64/13.0/desktop/kde +Display-If-Profile: default/linux/ia64/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/m68k/13.0/desktop/kde +Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop/kde +Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde/systemd +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/kde +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/kde/systemd +Display-If-Profile: default/linux/sh/13.0/desktop/kde +Display-If-Profile: default/linux/sparc/13.0/desktop/kde +Display-If-Profile: default/linux/sparc/13.0/desktop/kde/systemd +Display-If-Profile: default/linux/x86/13.0/desktop/kde +Display-If-Profile: default/linux/x86/13.0/desktop/kde/systemd + +KDE Plasma 4 has reached end of life in Portage. Upstream dropped support +in 2015-08-19, no security bugs have been fixed since then. It is therefore +required for all users to upgrade to KDE Plasma 5. + +KDM is being removed as well. Upstream recommends x11-misc/sddm instead which +is pulled in by plasma-meta by default. +OpenRC users edit /etc/conf.d/xdm and update DISPLAYMANAGER. +Systemd users run: systemctl reenable sddm.service + +Part of the cleanup will also be the KDE desktop profile, which is superseded +by the Plasma desktop profile. Please follow the detailed upgrade guide.[1] + +KDE Plasma 4.11 packages will be moved to kde-sunset overlay.[2] + +[1] https://wiki.gentoo.org/wiki/KDE/Plasma_5_upgrade +[2] https://wiki.gentoo.org/wiki/Overlay:Kde-sunset diff --git a/metadata/news/2017-01-21-python-exec-2-3-reclaims-python-symlinks/2017-01-21-python-exec-2-3-reclaims-python-symlinks.en.txt b/metadata/news/2017-01-21-python-exec-2-3-reclaims-python-symlinks/2017-01-21-python-exec-2-3-reclaims-python-symlinks.en.txt new file mode 100644 index 000000000000..4aa341514ac4 --- /dev/null +++ b/metadata/news/2017-01-21-python-exec-2-3-reclaims-python-symlinks/2017-01-21-python-exec-2-3-reclaims-python-symlinks.en.txt @@ -0,0 +1,40 @@ +Title: python-exec 2.3 reclaims python* symlinks +Author: Michał Górny <mgorny@gentoo.org> +Content-Type: text/plain +Posted: 2017-01-21 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: <app-eselect/eselect-python-20160206 +Display-If-Installed: <dev-lang/python-exec-2.3 + +The new versions of python-exec (2.3 and newer) are reclaiming multiple +Python-related symlinks in /usr/bin, most notably /usr/bin/python*. This +may result in your package manager reporting file collisions. + +The respective symlinks were previously either unowned and created +dynamically by app-eselect/eselect-python, or installed by it. From now +on, all Python-related symlinks are installed and handled +by python-exec. This ensures that they respect the python-exec +configuration files and variables consistently with regular Python +packages, and improves their reliability. + +If you are using FEATURES=collision-protect, Portage will reject +the upgrade. If this is the case, please temporarily switch to +FEATURES=protect-owned for the upgrade. + +If you are using FEATURES=protect-owned, Portage will verbosely warn +about the file collisions but will proceed with the upgrade once +determining no replaced files are owned. Please disregard the warning. + +The potentially colliding files are: + + * /usr/bin/2to3 + * /usr/bin/idle + * /usr/bin/pydoc + * /usr/bin/python + * /usr/bin/python2 + * /usr/bin/python3 + * /usr/bin/python-config + +For more information on python-exec, please see: +https://wiki.gentoo.org/wiki/Project:Python/python-exec diff --git a/metadata/news/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22.en.txt b/metadata/news/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22.en.txt new file mode 100644 index 000000000000..b413ce40a58b --- /dev/null +++ b/metadata/news/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22/2017-02-10-upgrade-to-sys-libs_uclibc-ng-1_0_22.en.txt @@ -0,0 +1,77 @@ +Title: Upgrade to =sys-libs/uclibc-ng-1.0.22 +Author: Anthony G. Basile <blueness@gentoo.org> +Content-Type: text/plain +Posted: 2017-02-10 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: sys-libs/uclibc-ng +Display-If-Profile: default/linux/uclibc/amd64 +Display-If-Profile: hardened/linux/uclibc/amd64 +Display-If-Profile: default/linux/uclibc/arm/armv7a +Display-If-Profile: hardened/linux/uclibc/arm/armv7a +Display-If-Profile: default/linux/uclibc/mips +Display-If-Profile: hardened/linux/uclibc/mips +Display-If-Profile: default/linux/uclibc/mips/mipsel +Display-If-Profile: hardened/linux/uclibc/mips/mipsel +Display-If-Profile: default/linux/uclibc/ppc +Display-If-Profile: hardened/linux/uclibc/ppc +Display-If-Profile: default/linux/uclibc/x86 +Display-If-Profile: hardened/linux/uclibc/x86 + +There have been two major changes in uclibc-ng which need special +attention when upgrading. Version 1.0.19 restructured the breakout +libraries, libcrypt.so.0, libdl.so.0, and friends. The functions in +those libraries are now included in libuClibc-0.1.0.19.so. Version +1.0.21 and above removed libc support for obstack, expecting packages to +use their bundled GNU lib code. Both changes require special upgrade +procedures which we outline below: + +0. Because of changes in the library structure in previous versions, +make sure you are working with 1.0.19 and rebuild world using + + emerge -e @world + +This will make sure all the executables link directly against libc.so.0 +(as reported by `readelf -d`) rather than via symlinks like libdl.so.0 +-> libc.so.0. Then upgrade from 1.0.19 to 1.0.20 without symlink-compat: + + USE="-symlink-compat" emerge =sys-libs/uclibc-ng-1.0.20 + +1. Get rid of the obstack.h header since it's used by configure scripts +to look for function prototypes and macros. + + mv /usr/include/obstack.h ~ + +2. We also need to force the use of any bundled gnu lib code. We can do +this by removing the definition of _GNU_OBSTACK_INTERFACE_VERSION from +gnu-version.h + + cp /usr/include/gnu-versions.h ~ + sed -i -e '/#define _GNU_OBSTACK/d' /usr/include/gnu-versions.h + +3. We need to tell stdio.h that __UCLIBC_HAS_OBSTACK__ is false. We do +this via the uClibc_config.h file. + + cp /usr/include/bits/uClibc_config.h ~ + sed -i -e '/__UCLIBC_HAS_OBSTACK__/ s/1/0/' \ + /usr/include/bits/uClibc_config.h + +4. To be safe, you may want to back up your entire /lib directory so +you can fall back should something go wrong: + + cp -a /lib /lib.bak + +5. Now when we rebuild @world, all packages will use their bundled +obstack code rather than depending on libc to provide it. + + ac_cv_func_obstack_vprintf=no emerge --keep-going --exclude \ + sys-libs/uclibc-ng -e @world + +6. Finally update uclibc-ng to the latest + + emerge =sys-libs/uclibc-ng-1.0.22 + +7. For good measure, rebuild the entire system + + emerge —e @world + diff --git a/metadata/news/2017-03-02-exim-chunking-bug/2017-03-02-exim-chunking-bug.en.txt b/metadata/news/2017-03-02-exim-chunking-bug/2017-03-02-exim-chunking-bug.en.txt new file mode 100644 index 000000000000..7212f5861d91 --- /dev/null +++ b/metadata/news/2017-03-02-exim-chunking-bug/2017-03-02-exim-chunking-bug.en.txt @@ -0,0 +1,28 @@ +Title: =mail-mta/exim-4.88 problem with chunking +Author: Fabian Groffen <grobian@gentoo.org> +Content-Type: text/plain +Posted: 2017-03-01 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: =mail-mta/exim-4.88 + +Exim maintainers discovered that version 4.88 has some serious problems +with its CHUNKING extension. To quote: + + There are various known problems which can result in messages stuck in + queues and remote servers dropping connections on larger mails. + +In Gentoo, Exim 4.88 is the only stable version available, hence all +Exim users are advised to either upgrade to an unstable 4.89 release +candidate, or patch the configuration as follows: + +1) in the main configuration section, add: + + chunking_advertise_hosts = + +2) for each SMTP transport, add: + + hosts_try_chunking = + +Please see also the announcement sent to exim-announce: +https://lists.exim.org/lurker/message/20170301.031117.ff024aa8.en.html diff --git a/metadata/news/2017-04-10-split-and-slotted-wine/2017-04-10-split-and-slotted-wine.en.txt b/metadata/news/2017-04-10-split-and-slotted-wine/2017-04-10-split-and-slotted-wine.en.txt new file mode 100644 index 000000000000..da288f518798 --- /dev/null +++ b/metadata/news/2017-04-10-split-and-slotted-wine/2017-04-10-split-and-slotted-wine.en.txt @@ -0,0 +1,52 @@ +Title: app-emulation/wine split and slotting +Author: NP-Hardass <NP-Hardass@gentoo.org> +Content-Type: text/plain +Posted: 2017-04-10 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: app-emulation/wine:0 + +Starting with Wine 2.0, Wine in Gentoo is transitioning away from its +traditional packaging and toward a new, split and slotted, Wine. + +As many Wine users know, there are often regressions or an application +works better on one version of wine than another. Going forward, +packaging in Gentoo will allow simultaneous installation of multiple +versions of Wine. + +Additionally, to expedite vanilla releases as well as permit multiple +configurations for each Wine installation, the major patchsets have +been split out into separate packages. + +Going forward, app-emulation/wine will transition to: +app-emulation/wine-vanilla: upstream Wine with no external patchsets + (like if the old packaging forced USE="-staging -d3d9") +app-emulation/wine-staging: Wine with Wine-Staging's patchset + (like if the old packaging forced USE="+staging -d3d9") +app-emulation/wine-d3d9: Wine with Ixit's Gallium Nine patchset + (like if the old packaging forced USE="-staging +d3d9") +app-emulation/wine-any: Wine with any of the patchsets or flags + (exactly like the old packaging regarding USE flags) + +wine-any exists to allow the user to build any combination that they'd +like (like the old packaging). This means the user could use wine-any +to use both Wine-Staging and Gallium Nine. Alternatively, the user +could use wine-any to try out another configuration from other +packages. For example, the user could build wine-vanilla without +PulseAudio, and could build wine-any with PulseAudio. The sky is the +limit on how a user may choose to use app-emulation/wine-any. + +Users may opt for any specific package, or may emerge virtual/wine, +which is provided for dependency resolution. +Maintainers: Please note, app-emulation/wine will be dropped, so +please use virtual/wine going forward. + +Users may call each version specifically, or may call a symlink based +on their installed patchset, for example wine-2.1, wine-staging-2.2, +or wine-d3d9. + +Symlinks for wine are managed with app-eselect/eselect-wine. +# eselect wine set wine-vanilla-2.0 +/usr/bin/wine -> /usr/bin/wine-vanilla-2.0 +# eselect wine set --staging wine-staging-2.4 +/usr/bin/wine-staging -> /usr/bin/wine-staging-2.4 diff --git a/metadata/news/2017-07-16-systemd-rootprefix/2017-07-16-systemd-rootprefix.en.txt b/metadata/news/2017-07-16-systemd-rootprefix/2017-07-16-systemd-rootprefix.en.txt new file mode 100644 index 000000000000..429eee32de7d --- /dev/null +++ b/metadata/news/2017-07-16-systemd-rootprefix/2017-07-16-systemd-rootprefix.en.txt @@ -0,0 +1,34 @@ +Title: systemd rootprefix migration +Author: Mike Gilbert <floppym@gentoo.org> +Posted: 2017-07-16 +Revision: 4 +News-Item-Format: 2.0 +Display-If-Installed: <sys-apps/systemd-234 + +Starting with the 234 release, Gentoo's sys-apps/systemd package will +be built with rootprefix=/. This means most of the included programs +and system units will be installed under /lib/systemd instead of +/usr/lib/systemd. + +This change brings Gentoo into alignment with most other distros which +still maintain a distinction between boot-critical programs in /, and +less critical programs in /usr. This also means that users with a +separate /usr filesystem will have an easier time booting if their +initramfs should become corrupt or fail. + +Symlinks are provided for /usr/lib/systemd/systemd and +/usr/lib/systemd/systemd-shutdown to avoid breaking bootloader configs +and to allow the system to be shutdown/rebooted without issue. These +symlinks will likely be removed in the 237 release, so please update +your boot configuration to reference init=/lib/systemd/systemd. + +This change will be mostly transparent to typical users. You may notice +that system units move from /usr/lib/systemd/system to +/lib/systemd/system as you upgrade/re-install packages; this is normal. +Units will function properly from both locations. + +After upgrading, please run systemctl daemon-reexec ensure that the new +version is executed. Also make sure to regenerate your initramfs if it +includes a copy of systemd (dracut). + +If you encounter a problem, please report a bug. diff --git a/metadata/news/2017-08-19-hardened-sources-removal/2017-08-19-hardened-sources-removal.en.txt b/metadata/news/2017-08-19-hardened-sources-removal/2017-08-19-hardened-sources-removal.en.txt new file mode 100644 index 000000000000..a2da83e6af43 --- /dev/null +++ b/metadata/news/2017-08-19-hardened-sources-removal/2017-08-19-hardened-sources-removal.en.txt @@ -0,0 +1,54 @@ +Title: sys-kernel/hardened-sources removal +Author: Francisco Blas Izquierdo Riera <klondike@gentoo.org> +Posted: 2017-08-19 +Revision: 10 +News-Item-Format: 2.0 +Display-If-Installed: sys-kernel/hardened-sources + +As you may know the core of sys-kernel/hardened-sources have been the +grsecurity patches. + +Sadly, their developers have stopped making these patches freely +available [1]. This is a full stop of any public updates and not only +stable ones as was announced two years ago[2]. + +As a result, the Gentoo Hardened team is unable to keep providing +further updates of the patches, and although the hardened-sources have +proved (when using a hardened toolchain) being resistant against +certain attacks like the stack guard page jump techniques proposed by +Stack Clash, we can't ensure a regular patching schedule and therefore, +the security of the users of these kernel sources. + +Because of that we will be masking the hardened-sources on the 27th of +August and will proceed to remove them from the tree by the end of +September. Obviously, we will reinstate the package again if the +developers decide to make their patches publicly available again. + +Our recommendation is that users should consider using instead +sys-kernel/gentoo-sources. + +As an alternative, for users happy keeping themselves on the stable +4.9 branch of the kernel; minipli, another grsecurity user, is forward +porting the patches on [3]. + +Strcat from Copperhead OS is making his own version with some +additional hardening features over those on the latest version of the +Linux tree at [4]. + +The Gentoo Hardened team can't make any statement regarding the +security, reliability or update availability of either of those +patches as we aren't providing them and can't therefore make any +recommendation regarding their use. + +We'd like to note that all the userspace hardening and MAC support for +SELinux provided by Gentoo Hardened will still remain in the packages +found in the Gentoo repository. Keep in mind, though, that the +security provided by these features will be weakened a bit when using +sys-kernel/gentoo-sources. Also, all PaX related packages, except +sys-kernel/hardened-sources, will remain available for the time being. + +[1] https://grsecurity.net/passing_the_baton.php +[2] https://www.gentoo.org/support/news-items/2015-10-21-future- +support-of-hardened-sources-kernel.html +[3] https://github.com/minipli/linux-unofficial_grsec +[4] https://github.com/copperhead/linux-hardened diff --git a/metadata/news/2017-10-04-gentoolkit-dev-deprecation/2017-10-04-gentoolkit-dev-deprecation.en.txt b/metadata/news/2017-10-04-gentoolkit-dev-deprecation/2017-10-04-gentoolkit-dev-deprecation.en.txt new file mode 100644 index 000000000000..43f1a28cbe8e --- /dev/null +++ b/metadata/news/2017-10-04-gentoolkit-dev-deprecation/2017-10-04-gentoolkit-dev-deprecation.en.txt @@ -0,0 +1,22 @@ +Title: app-portage/gentoolkit-dev deprecation and removal +Author: Paul Varner <fuzzyray@gentoo.org> +Posted: 2017-09-19 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: app-portage/gentoolkit-dev + +The app-portage/gentoolkit-dev package has been deprecated and the ebump, +ekeyword and imlate have been moved to the app-portage/gentoolkit-0.4.0 +package. With the upcoming marking of >=app-portage/gentoolkit-0.4.0 stable, +users will need to take action since gentoolkit-dev and those versions of +gentoolkit block each other. + +In order to upgrade to the new version of gentoolkit, you will need to resolve +the blocks. The following command will remove gentoolkit-dev from your world +set and uninstall gentoolkit-dev. This will then allow the installation of +>=app-portage/gentoolkit-0.4.0. + +emerge --depclean app-portage/gentoolkit-dev + +Once >=app-portage/gentoolkit-0.4.0 is stabilized, the remaining gentoolkit-dev +releases will be masked for removal and subsequent tree-cleaning. diff --git a/metadata/news/2017-10-13-openrc-service-binary-removal/2017-10-13-openrc-service-binary-removal.en.txt b/metadata/news/2017-10-13-openrc-service-binary-removal/2017-10-13-openrc-service-binary-removal.en.txt new file mode 100644 index 000000000000..9b3734300140 --- /dev/null +++ b/metadata/news/2017-10-13-openrc-service-binary-removal/2017-10-13-openrc-service-binary-removal.en.txt @@ -0,0 +1,14 @@ +Title: OpenRC "service" binary removal +Author: William Hubbs <williamh@gentoo.org> +Display-If-Installed: <=sys-apps/openrc-0.33 +Content-Type: text/plain +Posted: 2017-10-13 +Revision: 1 +News-Item-Format: 1.0 + +OpenRC 0.33 will remove the "service" binary, which was just a copy of +the "rc-service" binary. + +If you only use rc-service this will not affect you. However, if you +still need the "service" command, you should install +sys-apps/init-system-helpers. diff --git a/metadata/news/2017-11-21-old-wine-versions-moving-to-overlay/2017-11-21-old-wine-versions-moving-to-overlay.en.txt b/metadata/news/2017-11-21-old-wine-versions-moving-to-overlay/2017-11-21-old-wine-versions-moving-to-overlay.en.txt new file mode 100644 index 000000000000..ff28b96e6059 --- /dev/null +++ b/metadata/news/2017-11-21-old-wine-versions-moving-to-overlay/2017-11-21-old-wine-versions-moving-to-overlay.en.txt @@ -0,0 +1,37 @@ +Title: Old Wine versions moving to wine-overlay +Author: NP-Hardass <NP-Hardass@gentoo.org> +Posted: 2017-11-21 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: app-emulation/wine:0 +Display-If-Installed: app-emulation/wine-vanilla +Display-If-Installed: app-emulation/wine-staging +Display-If-Installed: app-emulation/wine-d3d9 +Display-If-Installed: app-emulation/wine-any + +To reduce the burden on main Gentoo repository, older versions of Wine +will be available only in the wine overlay. These ebuilds will still be +fully supported by the Gentoo Wine Project. This will result in +upstream stable releases and the several most recent upstream devel +releases being the only versions in ::gentoo; all versions meeting the +criteria for support within Gentoo [1] will be available in ::wine. + +To install the overlay you can either add the repos.conf file to your +portage configuration directory, add the repository via layman, or add the +repository via eselect-repository. + +* To add the repos.conf file: +# wget https://dev.gentoo.org/~np-hardass/proj/wine/wine.conf -O \ + /etc/portage/repos.conf/wine.conf + +Edit the /etc/portage/repos.conf/wine.conf file so that "location" +points to your desired folder to install the overlay. +# emaint sync --repo wine + +* To install the overlay via layman: +# layman -a wine + +* To install the overlay via eselect-repository: +# eselect repository enable wine + +[1] https://wiki.gentoo.org/wiki/Project:Wine/Policies_and_Procedures#Supported_versions diff --git a/metadata/news/2017-11-22-games-destable/2017-11-22-games-destable.en.txt b/metadata/news/2017-11-22-games-destable/2017-11-22-games-destable.en.txt new file mode 100644 index 000000000000..5c1981c34c53 --- /dev/null +++ b/metadata/news/2017-11-22-games-destable/2017-11-22-games-destable.en.txt @@ -0,0 +1,26 @@ +Title: No stable KEYWORDS for Gentoo Games +Author: David Seifert <soap@gentoo.org> +Content-Type: text/plain +Posted: 2017-11-22 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Keyword: amd64 x86 + +As the Games team does not have enough manpower to keep tabs on all +games packages, we have dropped all ebuilds maintained by the games +project to unstable KEYWORDS (without those required by other stable +packages). If you have any of these stable games packages installed, +you will have to add them to /etc/portage/package.accept_keywords/ +manually. Failures related to missing stable KEYWORDS will show up as + + The following keyword changes are necessary to proceed: + (see "package.accept_keywords" in the portage(5) man page for more details) + # required by @selected + # required by @world (argument) + =games-action/0verkill-0.16-r4 ~amd64 + +While we accept that this will cause some irritation for the community, +pretending we have a well supported games collection by having a +wealth of stable games packages is misleading at best. We welcome +contributions from outsiders willing to polish up the games landscape +in Gentoo via the Proxy Maintainers Project. diff --git a/metadata/news/2017-11-30-new-17-profiles/2017-11-30-new-17-profiles.en.txt b/metadata/news/2017-11-30-new-17-profiles/2017-11-30-new-17-profiles.en.txt new file mode 100644 index 000000000000..f66cd54c9e64 --- /dev/null +++ b/metadata/news/2017-11-30-new-17-profiles/2017-11-30-new-17-profiles.en.txt @@ -0,0 +1,89 @@ +Title: New 17.0 profiles in the Gentoo repository +Author: Andreas K. Hüttel <dilfridge@gentoo.org> +Posted: 2017-11-30 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Profile: default/linux/amd64/13.0 +Display-If-Profile: default/linux/amd64/13.0/selinux +Display-If-Profile: default/linux/amd64/13.0/desktop +Display-If-Profile: default/linux/amd64/13.0/desktop/gnome +Display-If-Profile: default/linux/amd64/13.0/desktop/gnome/systemd +Display-If-Profile: default/linux/amd64/13.0/desktop/plasma +Display-If-Profile: default/linux/amd64/13.0/desktop/plasma/systemd +Display-If-Profile: default/linux/amd64/13.0/developer +Display-If-Profile: default/linux/amd64/13.0/no-multilib +Display-If-Profile: default/linux/amd64/13.0/systemd +Display-If-Profile: default/linux/ia64/13.0 +Display-If-Profile: default/linux/ia64/13.0/desktop +Display-If-Profile: default/linux/ia64/13.0/desktop/gnome +Display-If-Profile: default/linux/ia64/13.0/desktop/gnome/systemd +Display-If-Profile: default/linux/ia64/13.0/developer +Display-If-Profile: default/linux/powerpc/ppc32/13.0 +Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop +Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop/gnome +Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop/gnome/systemd +Display-If-Profile: default/linux/powerpc/ppc32/13.0/developer +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/desktop +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/gnome +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/gnome/systemd +Display-If-Profile: default/linux/powerpc/ppc64/13.0/32bit-userland/developer +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/desktop +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/gnome +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/gnome/systemd +Display-If-Profile: default/linux/powerpc/ppc64/13.0/64bit-userland/developer +Display-If-Profile: default/linux/x86/13.0 +Display-If-Profile: default/linux/x86/13.0/selinux +Display-If-Profile: default/linux/x86/13.0/desktop +Display-If-Profile: default/linux/x86/13.0/desktop/gnome +Display-If-Profile: default/linux/x86/13.0/desktop/gnome/systemd +Display-If-Profile: default/linux/x86/13.0/desktop/plasma +Display-If-Profile: default/linux/x86/13.0/desktop/plasma/systemd +Display-If-Profile: default/linux/x86/13.0/developer +Display-If-Profile: default/linux/x86/13.0/no-multilib +Display-If-Profile: default/linux/x86/13.0/systemd + +We have just added (for all arches except arm and mips, these follow +later) a new set of profiles with release version 17.0 to the Gentoo +repository. These bring three changes: +1) The default C++ language version for applications is now C++14. + This change is mostly relevant to Gentoo developers. It also + means, however, that compilers earlier than GCC 6 are masked + and not supported for use as a system compiler anymore. Feel + free to unmask them if you need them for specific applications. +2) Where supported, GCC will now build position-independent + executables (PIE) by default. This improves the overall + security fingerprint. The switch from non-PIE to PIE binaries, + however, requires some steps by users, as detailed below. +3) Up to now, hardened profiles were separate from the default + profile tree. Now they are moving into the 17.0 profile + as a feature there, similar to "no-multilib" and "systemd". + +Please migrate away from the 13.0 profiles within the six weeks after +GCC 6.4.0 has been stabilized on your architecture. The 13.0 profiles +will be deprecated then and removed in half a year. + +If you are not already running a hardened setup with PIE enabled, then +switching the profile involves the following steps: +If not already done, +* Use gcc-config to select gcc-6.4.0 or later as system compiler +* Re-source /etc/profile: + . /etc/profile +* Re-emerge libtool + emerge -1 sys-devel/libtool +Then, +* Select the new profile with eselect +* Re-emerge, in this sequence, gcc, binutils, and glibc + emerge -1 sys-devel/gcc:6.4.0 + emerge -1 sys-devel/binutils + emerge -1 sys-libs/glibc +* Rebuild your entire system + emerge -e @world + +Switching the profile from 13.0 to 17.0 modifies the settings of +GCC 6 to generate PIE executables by default; thus, you need to do +the rebuilds even if you have already used GCC 6 beforehand. +If you do not follow these steps you may get spurious build +failures when the linker tries unsuccessfully to combine non-PIE +and PIE code. diff --git a/metadata/news/2018-01-14-gnucash/2018-01-14-gnucash.en.txt b/metadata/news/2018-01-14-gnucash/2018-01-14-gnucash.en.txt new file mode 100644 index 000000000000..334c1c078335 --- /dev/null +++ b/metadata/news/2018-01-14-gnucash/2018-01-14-gnucash.en.txt @@ -0,0 +1,31 @@ +Title: GnuCash 2.7+ Breaking Change +Author: Aaron W. Swenson <titanofold@gentoo.org> +Posted: 2018-01-14 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: <app-office/gnucash-4 + +Along with changes to use modern libraries, GnuCash 2.7+ has changed the +schema [1] it uses for both databases and files. GnuCash will +automatically modify the file or database in place upon open. + +Therefore, it is imperative that you back up any files or databases +before using GnuCash 2.7 in case you run into an issue and want or need +to revert back to 2.6. + +Close any open session of GnuCash including remote sessions, then +follow the relevant backup instructions as follows: + +For XML (plain files): +$ cp /path/to/file.gnucash /path/to/file.gnucash.bak + +For MySQL: +$ mysqldump gnucash_db | xz > gnucash-2.6.sql.xz + +For PostgreSQL: +$ pg_dump -U gnucash_user -Z 5 gnucash_db > gnucash-2.6.sql.gz + +For SQLite: +$ cp /path/to/sqlite.file.gnucash /path/to/sqlite.file.gnucash.bak + +[1] https://github.com/Gnucash/gnucash/releases/tag/2.7.0a diff --git a/metadata/news/2018-01-23-systemd-blocker/2018-01-23-systemd-blocker.en.txt b/metadata/news/2018-01-23-systemd-blocker/2018-01-23-systemd-blocker.en.txt new file mode 100644 index 000000000000..17692d9b6eac --- /dev/null +++ b/metadata/news/2018-01-23-systemd-blocker/2018-01-23-systemd-blocker.en.txt @@ -0,0 +1,46 @@ +Title: systemd sysv-utils blocker resolution +Author: Mike Gilbert <floppym@gentoo.org> +Posted: 2018-01-23 +Revision: 2 +News-Item-Format: 2.0 +Display-If-Installed: <sys-apps/systemd-236-r4 + +Starting with systemd-236, the sysv-utils USE flag is enabled by +default. + +The sysv-utils USE flag controls installation of symlinks for several +key commands: + + /sbin/halt -> ../bin/systemctl + /sbin/init -> ../lib/systemd/systemd + /sbin/reboot -> ../bin/systemctl + /sbin/poweroff -> ../bin/systemctl + /sbin/runlevel -> ../bin/systemctl + /sbin/shutdown -> ../bin/systemctl + /sbin/telinit -> ../bin/systemctl + +These commands are otherwise provided by sys-apps/sysvinit. This package +is blocked by systemd when the sysv-utils USE flag is enabled. + +Enabling sysv-utils should cause Portage to un-merge sysvinit and OpenRC +if they are currently installed. emerge may emit a warning message +before doing so; if you are booting with systemd, this message is safe +to ignore. + +If you wish to keep sysvinit (and openrc) installed, you may disable the +sysv-utils USE flag locally. + +If you run into unresolvable blockers with sysv-utils enabled, ensure +that you do not have any reverse dependencies of sys-apps/sysvinit +selected (in your world file). + +Common packages to look for: + + sys-apps/sysvinit + sys-apps/openrc + net-misc/netifrc + +The equery command from gentoolkit may help track down installed +packages that depend on openrc. + + equery depends sys-apps/openrc diff --git a/metadata/news/2018-01-30-portage-rsync-verification/2018-01-30-portage-rsync-verification.en.txt b/metadata/news/2018-01-30-portage-rsync-verification/2018-01-30-portage-rsync-verification.en.txt new file mode 100644 index 000000000000..0e7fd910d7c8 --- /dev/null +++ b/metadata/news/2018-01-30-portage-rsync-verification/2018-01-30-portage-rsync-verification.en.txt @@ -0,0 +1,50 @@ +Title: Portage rsync tree verification +Author: Michał Górny <mgorny@gentoo.org> +Posted: 2018-01-30 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: <sys-apps/portage-2.3.62 + +Starting with sys-apps/portage-2.3.21, Portage will verify the Gentoo +repository after rsync by default. + +The new verification is intended for users who are syncing via rsync. +Users syncing via git or other methods are not affected, and complete +verification for them will be provided in the future. + +The verification is implemented via app-portage/gemato. Currently, +the whole repository is verified after syncing. On systems with slow +hard drives, this could take around 2 minutes. If you wish to disable +it, you can disable the 'rsync-verify' USE flag on sys-apps/portage +or set 'sync-rsync-verify-metamanifest = no' in your repos.conf. + +Please note that the verification currently does not prevent Portage +from using the repository after syncing. If 'emerge --sync' fails, +do not install any packages and retry syncing. In case of prolonged +or frequent verification failures, please make sure to report a bug +including the failing mirror addresses (found in emerge.log). + +The verification uses information from the binary keyring provided +by the app-crypt/gentoo-keys package. The keys are refreshed +from the keyserver before every use in order to check for revocation. +The post-sync verification ensures that the authenticity of the key +package itself is verified. However, manual verification is required +before the first use. + +On Gentoo installations created using installation media that included +portage-2.3.22, the keys will already be covered by the installation +media signatures. On existing installations, you need to manually +compare the primary key fingerprint (reported by gemato on every sync) +against the official Gentoo keys [1]. An example gemato output is: + + INFO:root:Valid OpenPGP signature found: + INFO:root:- primary key: 1234567890ABCDEF1234567890ABCDEF12345678 + INFO:root:- subkey: FEDCBA0987654321FEDCBA0987654321FEDCBA09 + +Please note that the above snippet does not include the real key id +on purpose. The primary key actually printed by gemato must match +the 'Gentoo Portage Snapshot Signing Key' on the website. Please make +sure to also check the certificate used for the secure connection +to the site! + +[1]:https://www.gentoo.org/downloads/signatures/ diff --git a/metadata/news/2018-04-08-radicale-2-requires-pre-install-migration/2018-04-08-radicale-2-requires-pre-install-migration.en.txt b/metadata/news/2018-04-08-radicale-2-requires-pre-install-migration/2018-04-08-radicale-2-requires-pre-install-migration.en.txt new file mode 100644 index 000000000000..8783ee846bb2 --- /dev/null +++ b/metadata/news/2018-04-08-radicale-2-requires-pre-install-migration/2018-04-08-radicale-2-requires-pre-install-migration.en.txt @@ -0,0 +1,26 @@ +Title: Radicale 2 requires pre-install migration +Author: Christopher Head <chead@chead.ca> +Posted: 2018-04-02 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: <www-apps/radicale-2 + +Radicale version 2 uses a new storage format and is not able to read +databases created by version 1. Version 1 releases starting from 1.1.3 +include a --export-storage option which can be used to export their +databases in a format that Radicale 2 can use; you must do this before +upgrading to version 2. + +If you have kept the Gentoo-default database configuration, this will +work: +1. Stop any running instance of Radicale. +2. Run `radicale --export-storage ~/radicale-exported`. +3. Run `chown -R radicale: ~/radicale-exported` +4. Run `mv /var/lib/radicale /var/lib/radicale.old`. +5. Install Radicale version 2. +6. Run `mv ~/radicale-exported /var/lib/radicale/collections`. + +For more details, or if you are have a more complex configuration, +please see the migration guide: http://radicale.org/1to2/ +If you do a custom migration, please ensure the database is cleaned out +of /var/lib/radicale, including the hidden .props file. diff --git a/metadata/news/2018-05-22-python3-6/2018-05-22-python3-6.en.txt b/metadata/news/2018-05-22-python3-6/2018-05-22-python3-6.en.txt new file mode 100644 index 000000000000..c8901e970a7f --- /dev/null +++ b/metadata/news/2018-05-22-python3-6/2018-05-22-python3-6.en.txt @@ -0,0 +1,61 @@ +Title: Python 3.6 to become the default target +Author: Michał Górny <mgorny@gentoo.org> +Posted: 2018-05-22 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-lang/python:3.4 +Display-If-Installed: dev-lang/python:3.5 + +On 2018-06-22, Python 3.6 will replace Python 3.5 in the default Python +targets for Gentoo systems. The new default targets will be: + + PYTHON_TARGETS="python2_7 python3_6" + PYTHON_SINGLE_TARGET="python3_6" + +If you have not overriden the value of those variables on your system, +then your package manager will want to use the new targets immediately. +In order to prevent dependency conflicts, please clean stray packages +and rebuild/upgrade all packages with USE flag changes after the change, +e.g.: + + emerge --depclean + emerge -1vUD @world + emerge --depclean + +Please note that upgrading dependencies in place may cause some +of the package dependencies to be temporarily missing. While this +should not affect scripts that are already fully loaded, it may cause +ImportErrors while starting Python scripts or loading additional +modules (only scripts running Python 3.5 are affected). + +In order to improve stability of the upgrade, you may choose to +temporarily enable both targets, i.e. set in /etc/portage/make.conf +or its equivalent: + + PYTHON_TARGETS="python2_7 python3_5 python3_6" + PYTHON_SINGLE_TARGET="python3_5" + +This will cause the dependencies to include both Python 3.5 and 3.6 +support on the next system upgrade. Once all packages are updated, +you can restart your scripts, remove the custom setting and run another +upgrade to remove support for Python 3.5. + +If you would like to postpone the switch to Python 3.6, you can copy +the current value of PYTHON_TARGETS and/or PYTHON_SINGLE_TARGET +to /etc/portage/make.conf or its equivalent: + + PYTHON_TARGETS="python2_7 python3_5" + PYTHON_SINGLE_TARGET="python3_5" + +If you would like to migrate your systems earlier, you can do the same +with the new value. + +If you are still using Python 3.4, please consider switching to a newer +version as it is reaching its end-of-life. The end-of-life dates +for the currently used versions are: + + Python 3.4 2019-03-16 + Python 2.7 2020-01-01 + Python 3.5 2020-09-13 [1] + +[1]:https://devguide.python.org/#status-of-python-branches diff --git a/metadata/news/2018-07-11-portage-sync-allow-hardlinks/2018-07-11-portage-sync-allow-hardlinks.en.txt b/metadata/news/2018-07-11-portage-sync-allow-hardlinks/2018-07-11-portage-sync-allow-hardlinks.en.txt new file mode 100644 index 000000000000..18dc6b395842 --- /dev/null +++ b/metadata/news/2018-07-11-portage-sync-allow-hardlinks/2018-07-11-portage-sync-allow-hardlinks.en.txt @@ -0,0 +1,34 @@ +Title: Portage rsync hardlink support +Author: Zac Medico <zmedico@gentoo.org> +Posted: 2018-07-11 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: <sys-apps/portage-2.3.62 + +For users of the rsync tree, beginning with sys-apps/portage-2.3.42, +the default behavior for sync operations will use hardlinks in order +to ensure that a repository remains in a valid state if something +goes wrong [1]. For example, if signature verification fails during a +sync operation, the new hardlink behavior will preserve the previous +state of the repository. + +The new behavior may conflict with configurations that restrict the +use of hardlinks, such as overlay filesystems. Therefore, users will +have to set "sync-allow-hardlinks = no" in repos.conf if they have +a configuration that restricts the use of hardlinks, but this should +not be very common: + +[DEFAULT] +sync-allow-hardlinks = no + +Note that it is possible to sync more efficiently using git [2] +instead of rsync, though git consumes an increasing amount of disk +space over time unless shallow pull is enabled via the sync-depth +option in repos.conf [3] (requires sys-apps/portage-2.3.42 or later). + +[1] https://bugs.gentoo.org/660410 sys-apps/portage: use rsync + --link-dest to implement atomic repository updates (and abort if + signature verification fails) +[2] https://wiki.gentoo.org/wiki/Portage_Security#git-mirror_repo +[3] https://bugs.gentoo.org/552814 sys-apps/portage: support shallow + git pull by setting sync-depth = 1 in repos.conf diff --git a/metadata/news/2018-08-07-openssh-ldap-migration/2018-08-07-openssh-ldap-migration.en.txt b/metadata/news/2018-08-07-openssh-ldap-migration/2018-08-07-openssh-ldap-migration.en.txt new file mode 100644 index 000000000000..d3def75ce262 --- /dev/null +++ b/metadata/news/2018-08-07-openssh-ldap-migration/2018-08-07-openssh-ldap-migration.en.txt @@ -0,0 +1,17 @@ +Title: Migration required for OpenSSH with LDAP +Author: Thomas Deutschmann <whissi@gentoo.org> +Posted: 2018-08-07 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: net-misc/openssh + +If your sshd authenticates against LDAP, you have to migrate your +current setup to a new one using sshd's "AuthorizedKeysCommand" option and +a wrapper provided by packages like the new sys-auth/ssh-ldap-pubkey or +sys-auth/sakcl because beginning with net-misc/openssh-7.7_p1, OpenSSH-LPK +patch set is deprecated and no longer applies. + +We have created a short migration guide in the Wiki [1] for more details. + + +[1] https://wiki.gentoo.org/wiki/SSH/LDAP_migration diff --git a/metadata/news/2018-09-07-arm-17-profile-migration/2018-09-07-arm-17-profile-migration.en.txt b/metadata/news/2018-09-07-arm-17-profile-migration/2018-09-07-arm-17-profile-migration.en.txt new file mode 100644 index 000000000000..800c733a054c --- /dev/null +++ b/metadata/news/2018-09-07-arm-17-profile-migration/2018-09-07-arm-17-profile-migration.en.txt @@ -0,0 +1,63 @@ +Title: ARM 17.0 profile migration with CHOST change +Author: James Le Cuirot <chewi@gentoo.org> +Content-Type: text/plain +Posted: 2018-09-07 +Revision: 2 +News-Item-Format: 1.0 +Display-If-Keyword: arm +Display-If-Keyword: arm-linux + +The new 17.0 profiles for ARM are now officially available. This not +only features the PIE migration previously announced for other +architectures but also a tuple (CHOST) change for hardfloat systems. + +In short, the tuple will change from armv7a-hardfloat-linux-gnueabi to +armv7a-unknown-linux-gnueabihf or similar. This is to fall in line with +what the rest of the Linux community are now using. If the vendor (2nd) +part of your tuple is different or missing then you may keep it as it +is. The hf ending is what matters. + +If you are using an unversioned alternative profile such as +hardened/linux/arm/armv7a then the default CHOST will have changed for +you already. Hopefully, you were shielded from the change by having +CHOST explicitly set in your make.conf. In this case, a migration is +still required. + +Changing CHOST is never simple and does carry some risk. We encourage +users to migrate but if you do not have sys-devel/llvm on your system +and you do not cross-compile for ARM then you may choose to keep your +existing CHOST. We will continue to support this to some degree +although we cannot promise that other packages will not be affected in +future. + +If you choose not to migrate or your system is not hardfloat then you +must ensure that CHOST is explicitly set in make.conf and then proceed +with a regular 17.0 migration to deal with PIE as detailed here: + +https://www.gentoo.org/support/news-items/2017-11-30-new-17-profiles.html + +Otherwise, if you do wish to migrate then we have written a script to +do the necessary steps for you. + +Download the raw script here: +https://dev.gentoo.org/~chewi/armhf-migrate.bash + +View with syntax highlighting and change history here: +https://gist.github.com/chewi/1601684ad8f3cf8de0b786c00fa09b3c + +It takes a minimal backup of the existing toolchain with quickpkg +before changing anything but we strongly recommend that you take a +full backup first. The script echos each command as it goes along so +that you can keep an eye on what it's doing. You are, of course, +welcome to tinker with the script or perform the migration manually if +you think you know your own system better. It is heavily commented for +this reason. + +If the script fails then you can take remedial action before running +it again and it should skip any time-consuming builds that it has +already done. If the migration doesn't go to plan then please do seek +help in #gentoo-arm. + +A migration of this kind can justify rebuilding @world but with ARM +typically being very slow, the script does just the minimum +necessary. You are free to rebuild @world yourself after running it. diff --git a/metadata/news/2019-02-13-virtual-mysql-depenedency/2019-02-13-virtual-mysql-depenedency.en.txt b/metadata/news/2019-02-13-virtual-mysql-depenedency/2019-02-13-virtual-mysql-depenedency.en.txt new file mode 100644 index 000000000000..29258deef397 --- /dev/null +++ b/metadata/news/2019-02-13-virtual-mysql-depenedency/2019-02-13-virtual-mysql-depenedency.en.txt @@ -0,0 +1,19 @@ +Title: MySQL server and library dependency shift +Author: Brian Evans <grknight@gentoo.org> +Posted: 2019-02-13 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: virtual/mysql + +Due to the complexity of supporting multiple client libraries, +the Gentoo MySQL maintainers have decided to drop dependencies on the +server installation where it is not absolutely necessary. + +This will mean that packages might not automatically install the server +as a dependency since it does not have to exist on the local machine. + +To ensure uninterrupted service, verify that the server package, +such as dev-db/mariadb, dev-db/mysql, etc, is included in the world file +where it is in operation. This can be accomplished by running emerge +with the --noreplace option. +Eg.: emerge --noreplace dev-db/mariadb 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-08-30-php-5_6-deprecation/2019-08-30-php-5_6-deprecation.en.txt b/metadata/news/2019-08-30-php-5_6-deprecation/2019-08-30-php-5_6-deprecation.en.txt new file mode 100644 index 000000000000..5e7218bfcfda --- /dev/null +++ b/metadata/news/2019-08-30-php-5_6-deprecation/2019-08-30-php-5_6-deprecation.en.txt @@ -0,0 +1,69 @@ +Title: Deprecation and removal of PHP 5.6 +Author: Brian Evans <grknight@gentoo.org> +Posted: 2019-08-30 +Revision: 2 +News-Item-Format: 2.0 +Display-If-Installed: dev-lang/php:5.6 +Display-If-Installed: dev-php/haru +Display-If-Installed: dev-php/magickwand +Display-If-Installed: dev-php/pecl-bbcode +Display-If-Installed: dev-php/pecl-cairo +Display-If-Installed: dev-php/pecl-dbx +Display-If-Installed: dev-php/pecl-htscanner +Display-If-Installed: dev-php/pecl-libevent +Display-If-Installed: dev-php/pecl-memcache +Display-If-Installed: dev-php/pecl-mongo +Display-If-Installed: dev-php/pecl-mysqlnd_ms +Display-If-Installed: dev-php/pecl-mysqlnd_qc +Display-If-Installed: dev-php/pecl-sphinx +Display-If-Installed: dev-php/pecl-spl_types +Display-If-Installed: dev-php/pecl-svn +Display-If-Installed: dev-php/pecl-xrange +Display-If-Installed: dev-php/suhosin +Display-If-Installed: dev-php/xcache +Display-If-Installed: dev-php/xhprof +Display-If-Installed: dev-php/pecl-apcu:0 +Display-If-Installed: dev-php/pecl-dbase:0 +Display-If-Installed: dev-php/pecl-http:2 +Display-If-Installed: dev-php/pecl-mailparse:0 +Display-If-Installed: dev-php/pecl-memcached:0 +Display-If-Installed: dev-php/pecl-oauth:0 +Display-If-Installed: dev-php/pecl-propro:0 +Display-If-Installed: dev-php/pecl-ps:0 +Display-If-Installed: dev-php/pecl-raphf:0 +Display-If-Installed: dev-php/pecl-rrd:0 +Display-If-Installed: dev-php/pecl-ssh2:0 +Display-If-Installed: dev-php/pecl-stomp:0 +Display-If-Installed: dev-php/pecl-xdiff:0 +Display-If-Installed: dev-php/pecl-yaml:0 +Display-If-Installed: dev-php/twig[extension] +Display-If-Installed: dev-php/PEAR-MDB2_Driver_mysql +Display-If-Installed: media-gfx/exact-image[php] +Display-If-Installed: sci-geosciences/mapserver[php,php_targets_php5-6] +Display-If-Installed: www-apps/rutorrent:3.4-r1 +Display-If-Installed: www-server/nginx-unit[php56] + +The Gentoo PHP Team is announcing the deprecation and future removal of +PHP 5.6. As of October 1, 2019, PHP 5.6 will be masked for removal. +Since some may consider this a critical package, we have decided on a +longer than normal 90 day removal period. + +Other distributions have already or will have moved to PHP 7.2 by the end of +the year. Currently, we are using a backport repository to keep +security updates in line with the main releases. However, we feel this +is the right time to remove this branch as maintenance burden will +likely only increase. + +To that end, the long list of PHP 5 only extensions must accompany its +removal. Many of which are long ignored by their upstream maintainers +and have no replacements. Some packages listed here have PHP 5 only +slots which are included as reminders to upgrade. + +Some packages do have replacements: +dev-php/pecl-memcache can be replaced by dev-php/pecl-memcached with + some small code modifications +dev-php/pecl-mongo has been superceded by dev-php/pecl-mongodb +dev-php/pecl-libevent should be replaced by dev-php/pecl-event + with code changes +dev-php/PEAR-MDB2_Driver_mysql should be easily replaced by + dev-php/PEAR-MDB2_Driver_mysqli with minor configuration changes 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-07-python-2-7-eol/2020-02-07-python-2-7-eol.en.txt b/metadata/news/2020-02-07-python-2-7-eol/2020-02-07-python-2-7-eol.en.txt new file mode 100644 index 000000000000..fb9c16ed55f8 --- /dev/null +++ b/metadata/news/2020-02-07-python-2-7-eol/2020-02-07-python-2-7-eol.en.txt @@ -0,0 +1,51 @@ +Title: Python 2.7 went EOL +Author: Michał Górny <mgorny@gentoo.org> +Posted: 2020-02-07 +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. Python package +upstreams have started removing Python 2 compatibility code from their +packages more aggressively. This includes common dependencies such as +dev-python/pytest, dev-python/setuptools and dev-python/sphinx. While +we realize that many packages are still dependent on Python 2, providing +full support for it exceeds our maintenance capabilities. + +Upstream is planning to make one more release of dev-lang/python:2.7 +in April 2020. We are going to continue maintaining and patching +the interpreter for as long as it is feasible, most likely even after +all Python 2 packages are gone from Gentoo. + +At the same time, we are actively working towards switching +the distribution to Python 3. Whenever possible, we are removing +Python 2 support from packages. It will remain available for +the packages missing Python 3 compatibility and their dependencies +for some more time. However, packages that have little chances of being +ported will eventually be removed. + +If you are still using Python 2 for your projects, we strongly recommend +you to migrate away. For the time being, it is preferable to use +dev-python/virtualenv or a similar solution rather than ebuilds, +to install the dependencies for your projects locally. + +Regular Gentoo systems will be migrated off Python 2 gracefully. It may +be necessary to use --changed-deps or a similar option during system +upgrades whenever they become blocked by Python 2 packages installed +earlier. + +If you wish to remove Python 2.7 entirely sooner, you can try removing +python2_7 from PYTHON_TARGETS. However, this will require adding +explicit package.use entries if some of the installed packages still +require Python 2. An example package.use entry follows: + + # disable py2.7 without altering the other flags + */* PYTHON_TARGETS: -python2_7 + # enable py2.7 for setuptools + dev-python/setuptools PYTHON_TARGETS: python2_7 + # switch a single-impl package to 2.7 + dev-embedded/libftdi PYTHON_TARGETS: python2_7 + dev-embedded/libftdi PYTHON_SINGLE_TARGET: -* python2_7 + +Note that package.use entries are not necessary for packages that +support one implementation only (i.e. do not support Python 3 at all). 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-03-kubernetes-moving-to-single-package/2020-04-03-kubernetes-moving-to-single-package.en.txt b/metadata/news/2020-04-03-kubernetes-moving-to-single-package/2020-04-03-kubernetes-moving-to-single-package.en.txt new file mode 100644 index 000000000000..499b30a1feb6 --- /dev/null +++ b/metadata/news/2020-04-03-kubernetes-moving-to-single-package/2020-04-03-kubernetes-moving-to-single-package.en.txt @@ -0,0 +1,31 @@ +Title: K8s Moving to a Single Package +Author: William Hubbs <williamh@gentoo.org> +Posted: 2020-04-03 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-cluster/kubeadm +Display-If-Installed: sys-cluster/kube-apiserver +Display-If-Installed: sys-cluster/kube-controller-manager +Display-If-Installed: sys-cluster/kubectl +Display-If-Installed: sys-cluster/kubelet +Display-If-Installed: sys-cluster/kube-proxy +Display-If-Installed: sys-cluster/kube-scheduler + +Formerly, we packaged kubernetes as seven separate packages: + +sys-cluster/kubeadm, sys-cluster/kube-apiserver, +sys-cluster/kube-controller-manager, sys-cluster/kubectl, +sys-cluster/kubelet, sys-cluster/kube-proxy and +sys-cluster/kube-scheduler. + +Starting with kubernetes 1.18.0, 1.17.5 and 1.16.9, these will be merged +into one package, sys-cluster/kubernetes. The components of this package +which are build and installed will be selectable by use flags. + +If you are using 1.16.x or 1.17.x and would like to migrate to the +single package without upgrading, I have also made 1.16.8 and 1.17.4 +available in this new package. + +Currently, everything is built and installed by default; however, I am +open to changing this if there is a better way to configure the default +build. diff --git a/metadata/news/2020-04-03-kubernetes-moving-to-single-package/2020-04-03-kubernetes-moving-to-single-package.en.txt.asc b/metadata/news/2020-04-03-kubernetes-moving-to-single-package/2020-04-03-kubernetes-moving-to-single-package.en.txt.asc new file mode 100644 index 000000000000..e9f1aefe605f --- /dev/null +++ b/metadata/news/2020-04-03-kubernetes-moving-to-single-package/2020-04-03-kubernetes-moving-to-single-package.en.txt.asc @@ -0,0 +1,16 @@ +-----BEGIN PGP SIGNATURE----- + +iQIzBAABCAAdFiEEnB9e/J8YI6T0NBsJm0Co7cr65zMFAl6HwJ0ACgkQm0Co7cr6 +5zNd5xAAsSSs++Ga+KQUVziwYdWBxC/AizJssBsVfPD4leyVz80bX+JYAqblqsCo +pVyNpA64dcOo9nEY7JAGEoSnvuND2IUutt8sKs4Wjgc/B9kt7IIqaSYlmLfbEBo1 +3ozdUQ8RIAalsQwjJMuShq/RgK1D/NKqqEVuDR9zhuW1X81fNUaKVf2QDFpm6rJV +Ho50Uwaac5Wkn9fruIeinl0YYn338FEpabgFfuVcABhNYJr/f9CJ5yjdV06CBFJH +cjlTlwlnQQl599zEO44fq9ZvYRn7aUAzzyA8ykRi7gCsqEOdc6v1HunDRNDOBR1w +ftMm8Du7rEr0nyqEJw7/CqS+UgNn4uJ6tB8LF151ZApE3DDoulfrEtQODAe9Xxv+ +4WFm+T2oX+9Ii1vueDrDjG6uoiUPBIiRV8Rbd7fstOdsbmGvdqFLAgs5oQiPfp0U +l8VPHoezg42kr0Zjy30Poubzl6dDoLlRYcIHjQIIYlXPMoql6U0T3IIYb7uaQWtl +piJ3Zs/B7Co8FhJAXHmP0fZ0vbggF+q/ax+QJCOq+fpO1PUqG9d8qb11NgnNiQeN +RhncuwGL8hbobrDswTyawfxo9hHv3ORryAE/qNS9xpVFj2cG2rDdail6Vw/l64UR +Agg18g4xzeyKbri0LzkURQCsLJVg22U2GFRAz20v8/BSnmCnXdE= +=x3lR +-----END PGP SIGNATURE----- diff --git a/metadata/news/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt b/metadata/news/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt new file mode 100644 index 000000000000..c496154bd8e0 --- /dev/null +++ b/metadata/news/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt @@ -0,0 +1,25 @@ +Title: new ppc64le (little-endian) profiles +Author: Georgy Yakovlev <gyakovlev@gentoo.org> +Posted: 2020-04-04 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd + +A new set of 17.0 ppc64le profiles has been added to the Gentoo repository. +New profiles are compatible with existing ppc64 little-endian profiles, +and no additional action required after switching the profile. + +Please migrate away from the old profiles: + +* Old profiles: +default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian +default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd + +* Replaced by: +default/linux/ppc64le/17.0 +default/linux/ppc64le/17.0/systemd + +Desktop profiles are now also available. + +Refer to `eselect profile list` output. diff --git a/metadata/news/2020-04-14-elogind-default/2020-04-14-elogind-default.en.txt b/metadata/news/2020-04-14-elogind-default/2020-04-14-elogind-default.en.txt new file mode 100644 index 000000000000..d0cd3f67e442 --- /dev/null +++ b/metadata/news/2020-04-14-elogind-default/2020-04-14-elogind-default.en.txt @@ -0,0 +1,60 @@ +Title: Desktop profile switching USE default to elogind +Author: Andreas Sturmlechner <asturm@gentoo.org> +Posted: 2020-04-14 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-auth/consolekit + +Modern desktop environments make use of PAM session tracking for users, login +sessions and seats. [1] The most user-visible part of that is device and file +permissions management and reboot/shutdown handling without superuser rights. + +Users with systemd can stop reading here and continue with their daily +routine. + +ConsoleKit2 is unmaintained upstream for more than two years [2]. There are +many longstanding bugs and papercuts with consumers that aren't being fixed, +not least because these code paths receive very little testing. + +Enter the elogind project [3], which is a standalone logind implementation +based on systemd code, currently maintained by a fellow Gentoo user. We have +had sys-auth/elogind available in Gentoo since the beginning of 2017, and +meanwhile it has gained support [4] in KDE Plasma, Gnome [5], Cinnamon, MATE +and Xfce, as well as most other former consolekit consumers. + +Consequently, the desktop profile is switching away from consolekit to +elogind. Users of sys-auth/consolekit who selected a different profile should +consider doing the same. A guide is available [6]. Migration is easy, but any +existing consolekit session will be broken, and elogind will only begin to work +on relogin. + +Rely either on the profile, or set USE="elogind -consolekit" in make.conf +yourself. Make sure there is no consolekit debris in /etc/portage/package.use: + +# grep -R consolekit /etc/portage/package.use + +Rebuild all affected consumers and remove sys-auth/consolekit: + +# emerge --ask --changed-use --deep @world +# emerge --depclean consolekit + +Optional, but recommended in case of trouble such as missing reboot/shutdown +capabilities in the display manager: + +# rc-update add elogind boot + +For users of ~/.xinitrc instead of one of the supported DMs, do not forget to +update accordingly (ck-launch-session is gone without replacement). + +PS: Subsequently, this will lead to the last-riting of sys-power/pm-utils [7] +which is dead even longer than the original ConsoleKit(1) project. KDE Plasma +users sticking with sys-auth/consolekit are then going to lose suspend from +GUI without superuser rights. + +[1] https://wiki.gentoo.org/wiki/ConsoleKit +[2] https://github.com/ConsoleKit2/ConsoleKit2 +[3] https://github.com/elogind/elogind/blob/master/README.md +[4] https://bugs.gentoo.org/show_bug.cgi?id=elogind-support +[5] https://blogs.gentoo.org/leio/2019/03/26/gnome-3-30/ +[6] https://wiki.gentoo.org/wiki/Elogind +[7] https://bugs.gentoo.org/659616 diff --git a/metadata/news/2020-04-22-opencl-upgrade-file-collisions/2020-04-22-opencl-upgrade-file-collisions.en.txt b/metadata/news/2020-04-22-opencl-upgrade-file-collisions/2020-04-22-opencl-upgrade-file-collisions.en.txt new file mode 100644 index 000000000000..5aeb8569c3ad --- /dev/null +++ b/metadata/news/2020-04-22-opencl-upgrade-file-collisions/2020-04-22-opencl-upgrade-file-collisions.en.txt @@ -0,0 +1,28 @@ +Title: Potential file collisions during OpenCL upgrade +Author: Marek Szuba <marecki@gentoo.org> +Posted: 2020-04-22 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: app-eselect/eselect-opencl + +OpenCL support in Gentoo is now being migrated to having all implementations +operate through an ICD loader (dev-libs/ocl-icd or dev-libs/opencl-icd-loader) +installed directly into /usr rather than using eselect-opencl to switch +between implementations, with updated loader ebuilds having just been released +to the public. Unfortunately although the upgrade process will automatically +uninstall app-eselect/eselect-opencl, it will not remove the symbolic links to +libOpenCL.so created by this tool in library directories because those links +are not owned by the package in question. + +For everyone using the default Gentoo configuration of collision protection +(FEATURES='-collision-protect protect-owned'), this should cause no trouble +because this configuration allows the overwriting of orphaned files. +Obviously, systems with collision protection completely disabled (not +recommended but technically possible) will not be affected either. However, +if your system is configured for full collision protection +(FEATURES=collision-protect), it will be necessary to manually remove those +links + + rm -i /usr/lib{,64}/libOpenCL.so* + +before running the upgrade. diff --git a/metadata/news/2020-04-22-python3-7/2020-04-22-python3-7.en.txt b/metadata/news/2020-04-22-python3-7/2020-04-22-python3-7.en.txt new file mode 100644 index 000000000000..c933ca6259e9 --- /dev/null +++ b/metadata/news/2020-04-22-python3-7/2020-04-22-python3-7.en.txt @@ -0,0 +1,70 @@ +Title: Python 3.7 to become the default target +Author: Michał Górny <mgorny@gentoo.org> +Posted: 2020-04-22 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-lang/python:3.6 +Display-If-Installed: dev-lang/python:3.7 + +On 2020-05-06 (or later), Python 3.7 will replace Python 3.6 as one +of the default Python targets for Gentoo systems. The new default +values will be: + + PYTHON_TARGETS="python2_7 python3_7" + PYTHON_SINGLE_TARGET="python3_7" + +If you have not overriden these variables on your system, then your +package manager will switch to the new targets immediately. In order +to avoid dependency conflicts, please clean stray packages up +and rebuild/upgrade all packages with USE flag changes after the change, +e.g.: + + emerge --depclean + emerge -1vUD @world + emerge --depclean + +Please note that during the system upgrade some of the package +dependencies may temporarily become missing. While this should not +affect programs that are already fully loaded, it may cause ImportErrors +when starting Python scripts or loading additional modules (only scripts +running Python 3.6 are affected). + +In order to improve stability of the upgrade, you may choose to +temporarily enable both targets, i.e. set in /etc/portage/package.use +or its equivalent: + + */* PYTHON_TARGETS: python3_6 python3_7 + */* PYTHON_SINGLE_TARGET: -* python3_6 + +This will cause the dependencies to include both Python 3.6 and 3.7 +support whenever possible, throughout the next system upgrade. Once all +packages are updated, you can restart your scripts, remove the setting +and start another upgrade in order to cleanly remove Python 3.6. + +There are still some Gentoo packages that do not support Python 3.7. +We will be pushing updates to these packages as time permits. However, +some of them will probably be removed instead. + +If you would like to postpone the switch to Python 3.7, you can copy +the current value of PYTHON_TARGETS and/or PYTHON_SINGLE_TARGET +to /etc/portage/package.use or its equivalent: + + */* PYTHON_TARGETS: -python3_7 python3_6 + */* PYTHON_SINGLE_TARGET: -* python3_6 + +If you would like to migrate your systems earlier, you can do +the opposite. Note that if you are running ~arch, you may want to go +straight for Python 3.8 at this point. + +Please note that this switch is long overdue. Python 3.6 is no longer +receiving bug fixes. Its planned end-of-life is 2021-12-23 but we will +probably remove it earlier than that. [1] + +All above snippets assume using package.use to control USE flags. +If you still have make.conf entries for these targets, you need +to remove them. While using make.conf is possible, it is strongly +discouraged as it does not respect package defaults. The latter +can help you keep some of Python 3.6 packages without the need to +explicitly toggle flags per-package. + +[1] https://devguide.python.org/#status-of-python-branches diff --git a/metadata/news/2020-06-23-upgrade-to-sys-libs_pam-1_4_0/2020-06-23-upgrade-to-sys-libs_pam-1_4_0.en.txt b/metadata/news/2020-06-23-upgrade-to-sys-libs_pam-1_4_0/2020-06-23-upgrade-to-sys-libs_pam-1_4_0.en.txt new file mode 100644 index 000000000000..0c77c98637ba --- /dev/null +++ b/metadata/news/2020-06-23-upgrade-to-sys-libs_pam-1_4_0/2020-06-23-upgrade-to-sys-libs_pam-1_4_0.en.txt @@ -0,0 +1,28 @@ +Title: sys-libs/pam-1.4.0 upgrade +Author: Mikle Kolyada <zlogene@gentoo.org> +Content-Type: text/plain +Posted: 2020-06-23 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-libs/pam +Display-If-Installed: sys-auth/pambase + +Starting with the 1.4.0 release [1], we don't offer these modules anymore: + +* pam_tally and pam_tally2 have been deprecated and replaced + by the pam_faillock module +* pam_cracklib has been deprecated and replaced + by the pam_passwdqc module + +These changes affected our basic PAM stack configuration. + +You only need to take action if: +* you made manual changes to the PAM stack, or +* you use FEATURES="-config-protect-if-modified" option + +If this applies to you, please make sure to either run the etc-update or +dispatch-conf command in order to sync your configuration. + +Failure to do this may result in your system becoming inaccessible. + +[1] - https://github.com/linux-pam/linux-pam/releases/tag/v1.4.0 diff --git a/metadata/news/2020-06-24-xorg-server-dropping-default-suid/2020-06-24-xorg-server-dropping-default-suid.en.txt b/metadata/news/2020-06-24-xorg-server-dropping-default-suid/2020-06-24-xorg-server-dropping-default-suid.en.txt new file mode 100644 index 000000000000..b752bb720ede --- /dev/null +++ b/metadata/news/2020-06-24-xorg-server-dropping-default-suid/2020-06-24-xorg-server-dropping-default-suid.en.txt @@ -0,0 +1,32 @@ +Title: xorg-server dropping default suid +Author: Piotr Karbowski <slashbeast@gentoo.org> +Posted: 2020-06-24 +Revision: 3 +News-Item-Format: 2.0 +Display-If-Installed: x11-base/xorg-server + +Starting 2020-07-15, stable keyworded x11-base/xorg-server will default +to using the logind interface instead of suid by default. resulting in +better security by default through running the server as a regular user +instead of root. However, this will require our users to use a logind +provider such as elogind or systemd. The systemd users and those who are +not using systemd but use desktop profiles can stop reading here, as +they already have a logind provider enabled. + +Others, who have neither systemd or desktop profiles enabled will be +required to globally enable 'elogind' USE flag and update the system + + # emerge --newuse @world + +Afterwards, one will need to re-login, so the PAM can assign a seat. One +can confirm that a seat has been assigned upon login by running: + + $ loginctl user-status + +Users who do not wish to use logind interface or have rare hardware that +does not use KMS and because of that, require root privileges to +operate, can manually re-enable 'suid' and disable 'elogind' USE flags +in order to preserve the previous behavior. However, please note that +this is heavily discouraged to run X server as root due to security +reasons. The 'suid' USE flag will remain as optional opt-in for the need +of legacy hardware. |