diff options
12 files changed, 0 insertions, 398 deletions
diff --git a/2014-02-25-udev-upgrade/2014-02-25-udev-upgrade.en.txt b/2014-02-25-udev-upgrade/2014-02-25-udev-upgrade.en.txt deleted file mode 100644 index 9c37eee..0000000 --- a/2014-02-25-udev-upgrade/2014-02-25-udev-upgrade.en.txt +++ /dev/null @@ -1,28 +0,0 @@ -Title: Upgrade to >=sys-fs/udev-210 -Author: Samuli Suominen <ssuominen@gentoo.org> -Content-Type: text/plain -Posted: 2014-02-25 -Revision: 1 -News-Item-Format: 1.0 -Display-If-Installed: <sys-fs/udev-210 - -The options CONFIG_FHANDLE and CONFIG_NET are now required in the kernel. -You will be warned of them if they are missing while you upgrade to ->=sys-fs/udev-210 by the package manager. -See the package's README at /usr/share/doc/udev-210/ for more optional -kernel options. - -The most reliable way of disabling the new network interface scheme is still -the kernel parameter "net.ifnames=0" since overriding the -80-net-name-slot.rules in /etc/udev/rules.d/ no longer works since upstream -renamed the file to /lib/udev/rules.d/80-net-setup-link.rules -The actual configuration is at /lib/systemd/network/99-default.link, which -you can override in /etc/systemd/network/ -So, to clarify, you can override the new .rules file or the .link file in /etc -but using the kernel parameter is the most consistent way. - -Since both the systemd-udevd executable and the network configuration is stored -at /lib/systemd, using a too wide INSTALL_MASK would be a mistake. - -[1] https://wiki.gentoo.org/wiki/Udev/upgrade#udev_208_to_210 -[2] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames diff --git a/2014-03-12-profile-eapi-5/2014-03-12-profile-eapi-5.en.txt b/2014-03-12-profile-eapi-5/2014-03-12-profile-eapi-5.en.txt deleted file mode 100644 index 08a8ae6..0000000 --- a/2014-03-12-profile-eapi-5/2014-03-12-profile-eapi-5.en.txt +++ /dev/null @@ -1,47 +0,0 @@ -Title: Profile EAPI 5 requirement -Author: Zero_Chaos <zerochaos@gentoo.org> -Content-Type: text/plain -Posted: 2014-03-02 -Revision: 1 -News-Item-Format: 1.0 -Display-If-Installed: <sys-apps/portage-2.2.0_alpha130 - -The Gentoo Council has decided that the entire profile tree will be -updated to require EAPI=5 support. - -http://www.gentoo.org/proj/en/council/meeting-logs/20140114.txt - -For all non-deprecated profiles this requirement has already been in -place for over one year. If you have updated your system at any point -during 2013, and followed the instructions in the profile deprecation -warnings (which cannot really easily be overlooked), and are running an -up-to-date portage version, there is absolutely nothing that you need -to do now. - -If you are running an installation that has not been updated for more -than a year, the portage tree you have just updated to may be -incompatible with your portage version, and the profile you are using -may be gone. - -It is still possible to upgrade, following these simple steps: - -1.) Do not panic. -2.) Download a portage snapshot from - http://dev.gentoo.org/~zerochaos/snapshots -3.) Unpack the snapshot to ~/tmp -4.) If you are not already, become root -5.) # rsync --recursive --links --safe-links --perms --times --force \ - --whole-file --delete --stats --human-readable \ - --exclude=/distfiles --exclude=/local --exclude=/packages \ - --verbose --progress --omit-dir-times /tmp/portage /usr/portage -6.) # chown portage.portage -R /usr/portage -6.) If needed, set your profile to a modern one (typically named 13.0) -7.) # eselect profile list -8.) # eselect profile set <desired profile> -9.) emerge --update --oneshot portage - -Now that you have a modern copy of portage, you can go back to updating -your system as usual. Please update your system at LEAST twice a year -to avoid issues like this in the future. - -Thanks for flying Gentoo. diff --git a/2014-03-16-ruby-1_8-removal/2014-03-16-ruby-1_8-removal.en.txt b/2014-03-16-ruby-1_8-removal/2014-03-16-ruby-1_8-removal.en.txt deleted file mode 100644 index 11017ab..0000000 --- a/2014-03-16-ruby-1_8-removal/2014-03-16-ruby-1_8-removal.en.txt +++ /dev/null @@ -1,26 +0,0 @@ -Title: Ruby 1.8 removal; Ruby 1.9/2.0 default -Author: Manuel Rüger <mrueg@gentoo.org> -Content-Type: text/plain -Posted: 2014-03-16 -Revision: 2 -News-Item-Format: 1.0 -Display-If-Installed: <dev-lang/ruby-1.9 - -Ruby MRI 1.8 has been retired by upstream in June 2013.[1] -We remove Ruby MRI 1.8 support from the tree now. In parallel Ruby MRI 2.0 -support will be activated in base profile's RUBY_TARGETS variable by default -in conjunction with Ruby MRI 1.9. - -If your currently eselected Ruby interpreter is ruby18, our recommendation is -to change it to ruby19. At the moment Ruby MRI 1.9 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 1.9 via: - - eselect ruby set ruby19 - -[1] https://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7/ diff --git a/2014-06-03-upower-loses-hibernate-suspend-to-systemd/2014-06-03-upower-loses-hibernate-suspend-to-systemd.en.txt b/2014-06-03-upower-loses-hibernate-suspend-to-systemd/2014-06-03-upower-loses-hibernate-suspend-to-systemd.en.txt deleted file mode 100644 index 135dc69..0000000 --- a/2014-06-03-upower-loses-hibernate-suspend-to-systemd/2014-06-03-upower-loses-hibernate-suspend-to-systemd.en.txt +++ /dev/null @@ -1,30 +0,0 @@ -Title: UPower loses hibernate / suspend to systemd -Author: Samuli Suominen <ssuominen@gentoo.org> -Content-Type: text/plain -Posted: 2014-06-03 -Revision: 1 -News-Item-Format: 1.0 -Display-If-Installed: <sys-power/upower-0.99.0 - -UPower discontinued hibernate and suspend support in favor of systemd. -Because of this, we have created a compability package at -sys-power/upower-pm-utils which will give you the old UPower with -sys-power/pm-utils support back. -Some desktops have integrated the sys-power/pm-utils support directly -to their code, like Xfce, and as a result, they work also with the new -UPower as expected. - -All non-systemd users are recommended to choose between: - -# emerge --oneshot --noreplace 'sys-power/upower-pm-utils' - -or - -# emerge --oneshot --noreplace '>=sys-power/upower-0.99.0' - -However, all systemd users are recommended to stay with sys-power/upower. - -A small tip for GNOME _and_ systemd users, only 3.12 and newer support 0.99, -so if you see the package manager pulling in sys-power/upower-pm-utils -while using old GNOME, like 2.32 or 3.10, you _can_ prevent it by adding -a package.mask entry for >=sys-power/upower-0.99 diff --git a/2014-07-17-dhcpcd_6_4_2_changes_defaults_for_ipv6/2014-07-17-dhcpcd_6_4_2_changes_defaults_for_ipv6.en.txt b/2014-07-17-dhcpcd_6_4_2_changes_defaults_for_ipv6/2014-07-17-dhcpcd_6_4_2_changes_defaults_for_ipv6.en.txt deleted file mode 100644 index 11ce7a0..0000000 --- a/2014-07-17-dhcpcd_6_4_2_changes_defaults_for_ipv6/2014-07-17-dhcpcd_6_4_2_changes_defaults_for_ipv6.en.txt +++ /dev/null @@ -1,27 +0,0 @@ -Title: dhcpcd >= 6.4.2 changes defaults for IPv6 -Author: William Hubbs <williamh@gentoo.org> -Content-Type: text/plain -Posted: 2014-07-17 -Revision: 1 -News-Item-Format: 1.0 -Display-If-Installed: <=net-misc/dhcpcd-6.4.2 - -dhcpcd-6.4.2 and newer supports IPv6 stable private addresses when using -IPv6 stateless address autoconfiguration (SLAAC) as described in -RFC-7217 [1]. The configuration file shipped with dhcpcd activates this -feature by default, because it means that a machine cannot be tracked -across multiple networks since its address will no longer be based on -the hardware address of the interface. - -I received a report in testing that IPv6 connectivity was lost due -to this change [2]. If you are concerned about losing IPv6 connectivity, -temporarily comment out the line in dhcpcd.conf that says -"slaac private" until you can adjust to the new configuration. - -See the references below for why the upstream default is to use stable -private instead of hardware-based addresses. - -[1] http://tools.ietf.org/html/rfc7217 -[2] https://bugs.gentoo.org/show_bug.cgi?id=514198 -[3] http://tools.ietf.org/html/draft-ietf-6man-default-iids-00 -[4] http://mail-index.netbsd.org/tech-net/2014/06/04/msg004572.html diff --git a/2014-08-20-mysql_5_5_upgrade_procedures/2014-08-20-mysql_5_5_upgrade_procedures.en.txt b/2014-08-20-mysql_5_5_upgrade_procedures/2014-08-20-mysql_5_5_upgrade_procedures.en.txt deleted file mode 100644 index f0feef1..0000000 --- a/2014-08-20-mysql_5_5_upgrade_procedures/2014-08-20-mysql_5_5_upgrade_procedures.en.txt +++ /dev/null @@ -1,31 +0,0 @@ -Title: MySQL 5.5 upgrade procedures -Author: Brian Evans <grknight@gentoo.org> -Content-Type: text/plain -Posted: 2014-08-20 -Revision: 1 -News-Item-Format: 1.0 -Display-If-Installed: <dev-db/mysql-5.5 - -MySQL 5.5 is now stable across all arches. The upgrade process -will require you to rebuild everything linked to -libmysqlclient.so.16 and libmysqlclient_r.so.16. - -This may be done for you by portage with 'emerge @preserved-rebuild'. - -A small number of libraries may not be automatically rebuilt against -the new MySQL libraries using preserved-rebuild. If you have -difficulties with packages not finding the new libraries, install -app-portage/gentoolkit and run: -# revdep-rebuild --library libmysqlclient.so.16 -# revdep-rebuild --library libmysqlclient_r.so.16 - -The official upgrade documentation is available here: -http://dev.mysql.com/doc/refman/5.5/en/upgrading.html - -Please be sure to review the upgrade document for any possible actions -necessary before and after the upgrade. This includes running -mysql_upgrade after the upgrade completion. - -Due to security flaws, MySQL 5.1 will be hard masked in 30 days after -this news item is posted. It will remain masked in the tree for -3 months before removal. diff --git a/2014-10-04-restructuring_of_mips_profiles/2014-10-04-restructuring_of_mips_profiles.en.txt b/2014-10-04-restructuring_of_mips_profiles/2014-10-04-restructuring_of_mips_profiles.en.txt deleted file mode 100644 index 081d8a7..0000000 --- a/2014-10-04-restructuring_of_mips_profiles/2014-10-04-restructuring_of_mips_profiles.en.txt +++ /dev/null @@ -1,51 +0,0 @@ -Title: Restructuring of mips profiles -Author: Anthony G. Basile <blueness@gentoo.org> -Content-Type: text/plain -Posted: 2014-10-04 -Revision: 1 -News-Item-Format: 1.0 -Display-If-Keyword: mips -Display-If-Installed: sys-libs/glibc - -To accomodate the new multilib approach in Gentoo, the mips profiles will be -changing on Oct 11, 2014. The new profile structure will be as follows: - - [1] default/linux/mips/13.0/o32 - [2] default/linux/mips/13.0/n32 - [3] default/linux/mips/13.0/n64 - [4] default/linux/mips/13.0/multilib/o32 - [5] default/linux/mips/13.0/multilib/n32 - [6] default/linux/mips/13.0/multilib/n64 - [7] default/linux/mips/13.0/mipsel/o32 - [8] default/linux/mips/13.0/mipsel/n32 - [9] default/linux/mips/13.0/mipsel/n64 - [10] default/linux/mips/13.0/mipsel/multilib/o32 - [11] default/linux/mips/13.0/mipsel/multilib/n32 - [12] default/linux/mips/13.0/mipsel/multilib/n64 - [13] hardened/linux/musl/mips - [14] hardened/linux/musl/mips/mipsel - [15] default/linux/uclibc/mips - [16] hardened/linux/uclibc/mips - [17] default/linux/uclibc/mips/mipsel - [18] hardened/linux/uclibc/mips/mipsel - -There are a few points to note about the change: - -1) Only the glibc profiles (1-12) are affected. The embedded system profiles -(13-18) will not change. - -2) The glibc profiles will now explicitly state the ABIs. In the case of -non-multilib systems (1-3, 7-9) the stated ABI will be the only ABI available, -while in the case of multilib systems (4-6, 10-12) the stated ABI will be the -default ABI, and the others will be available by setting ABI_MIPS in make.conf. - -3) Profiles 1 and 7 are strictly 32-bit userland, but can run under either a -32-bit or 64-bit kernel. They will have CHOST = mips-unknown-linux-gnu and -mipsel-unknown-linux-gnu, respectively. All the other glibc profiles (2-6, 8-12) -are 64-bits userland and will have CHOST = mips64-unknown-linux-gnu or -mips64el-unknown-linux-gnu. - -4) Only users of profiles 1 and 7 need to change their profiles sym links using -`eselect profile`. However, all users should be aware of the CHOST value on -their system to ensure it remains unchanged after the profile updates. - diff --git a/2014-10-22-mythtv-schedulesdirect-change/2014-10-22-mythtv-schedulesdirect-change.en.txt b/2014-10-22-mythtv-schedulesdirect-change/2014-10-22-mythtv-schedulesdirect-change.en.txt deleted file mode 100644 index a6ecb82..0000000 --- a/2014-10-22-mythtv-schedulesdirect-change/2014-10-22-mythtv-schedulesdirect-change.en.txt +++ /dev/null @@ -1,18 +0,0 @@ -Title: MythTV SchedulesDirect Change -Author: Richard Freeman <rich0@gentoo.org> -Content-Type: text/plain -Posted: 2014-10-20 -Revision: 1 -News-Item-Format: 1.0 -Display-If-Installed: <media-tv/mythtv-0.27.4 - -Many MythTV users use the SchedulesDirect service as a source of program -data. If you use this service you will need to take action or you will -lose access to scheduling data on Nov 1st 2014. If you do not use this -service, no action is required. - -If you use the SchedulesDirect service, you must either upgrade to -media-tv/mythtv-0.27.4, or you must follow one of the workarounds found -at: http://www.mythtv.org/wiki/Schedules_Direct_URL_Change - -The link above also provides additional information about the change.
\ No newline at end of file diff --git a/2014-10-22-upgrading-to-musl-1_1_5/2014-10-22-upgrading-to-musl-1_1_5.en.txt b/2014-10-22-upgrading-to-musl-1_1_5/2014-10-22-upgrading-to-musl-1_1_5.en.txt deleted file mode 100644 index 77372bd..0000000 --- a/2014-10-22-upgrading-to-musl-1_1_5/2014-10-22-upgrading-to-musl-1_1_5.en.txt +++ /dev/null @@ -1,57 +0,0 @@ -Title: Upgrading to musl 1.1.5 -Author: Anthony G. Basile <blueness@gentoo.org> -Content-Type: text/plain -Posted: 2014-10-22 -Revision: 1 -News-Item-Format: 1.0 -Display-If-Installed: sys-libs/musl - -Versions 1.1.4 and above of musl provide Native Language Support (nls). Up -till now, Gentoo musl stages have used GNU gettext to provide nls via libintl.so -and linked applications against it. Beginning with musl-1.1.5 we are switching -to nls provided by musl. Since musl is experimental, you are better off starting -with a new stage3 dated later than 2014-10-20. However, if you wish to upgrade -an existing system, you can proceed as follows: - -1. Remove any references to -lintl from /etc/portage/package.env and -/etc/portage/env/*. If you did not modify these from the original stage3 -then you can just do `rm -rf /etc/portage/package.env /etc/portage/env` - -2. Update your system, except for musl: - - emerge --exclude musl -uvNDq world - -3. Remove the libintl header belonging to gettext: - - rm -f /usr/include/libintl.h - -4. Now you can update musl without a file collision: - - emerge -1q =sys-libs/musl-1.1.5 - -5. We need to turn USE=nls off in gettext: - - echo "=sys-devel/gettext-0.19.3" >> /etc/portage/package.accept_keywords - echo "sys-devel/gettext -nls" >> /etc/portage/package.use - emerge -1 gettext - -6. Rebuild any packages that might be linking against libintl.so: - - USE=-nls emerge -uvDNq world - -7. The previous step probably missed some executables, so find them all: - - for i in /bin/* /sbin/ /usr/bin/* /usr/sbin/* ; do - readelf -d $i 2>&1 | grep -q libintl.so && echo $i - done - -You can identify what packages these belong to uing `equery b <exe>` Rebuild -those packages. - -8. At this point you can remove /usr/lib/libintl.so*. To be safe, check that -all your coreutils utilities (like mv, cp, ls, etc.) really aren't linking -against libintl.so as described in the previous step and then mv that library -out of the dynamic linker's search path. - -9. While not strictly necessary, you can rebuild your entire system to make -sure everything links nicely against the new libc.so: emerge -evq world diff --git a/2014-11-07-udev-upgrade/2014-11-07-udev-upgrade.en.txt b/2014-11-07-udev-upgrade/2014-11-07-udev-upgrade.en.txt deleted file mode 100644 index c146609..0000000 --- a/2014-11-07-udev-upgrade/2014-11-07-udev-upgrade.en.txt +++ /dev/null @@ -1,16 +0,0 @@ -Title: Upgrade to udev >= 217 or eudev >= 2.1 -Author: Samuli Suominen <ssuominen@gentoo.org> -Content-Type: text/plain -Posted: 2014-11-07 -Revision: 1 -News-Item-Format: 1.0 -Display-If-Installed: <sys-fs/udev-217 -Display-If-Installed: <sys-fs/eudev-2.1 - -sys-fs/udev-217 and sys-fs/eudev-2.1 no longer provide a userspace -firmware loader. If you require firmware loading support, you must use -kernel 3.7 or greater with CONFIG_FW_LOADER_USER_HELPER=n. No action is -required if none of your kernel modules need firmware. See [1] for more -information on the upgrade. - -[1] https://wiki.gentoo.org/wiki/Udev/upgrade#udev_216_to_217 diff --git a/2014-11-11-kgcc64-sparc-removal/2014-11-11-kgcc64-sparc-removal.en.txt b/2014-11-11-kgcc64-sparc-removal/2014-11-11-kgcc64-sparc-removal.en.txt deleted file mode 100644 index 635c865..0000000 --- a/2014-11-11-kgcc64-sparc-removal/2014-11-11-kgcc64-sparc-removal.en.txt +++ /dev/null @@ -1,16 +0,0 @@ -Title: sys-devel/kgcc64 removal on sparc -Author: Raúl Porcel <armin76@gentoo.org> -Content-Type: text/plain -Posted: 2014-11-11 -Revision: 1 -News-Item-Format: 1.0 -Display-If-Profile: default/linux/sparc - -sys-devel/kgcc64 is going to be removed from the sparc system package set -since the normal sys-devel/gcc can, since version 4.4, build 64bit kernels. - -Until now, you had to use CONFIG_CROSS_COMPILE="sparc64-unknown-linux-gnu-" -in your kernel config, but with sys-devel/kgcc64 going away, you need to -remove that option from your kernel configuration. - - diff --git a/2014-11-25-bash-completion-2_1-r90/2014-11-25-bash-completion-2_1-r90.en.txt b/2014-11-25-bash-completion-2_1-r90/2014-11-25-bash-completion-2_1-r90.en.txt deleted file mode 100644 index f63ca77..0000000 --- a/2014-11-25-bash-completion-2_1-r90/2014-11-25-bash-completion-2_1-r90.en.txt +++ /dev/null @@ -1,51 +0,0 @@ -Title: bash-completion-2.1-r90 -Author: Michał Górny <mgorny@gentoo.org> -Content-Type: text/plain -Posted: 2014-11-25 -Revision: 1 -News-Item-Format: 1.0 -Display-If-Installed: >=app-shells/bash-completion-2.1-r90 - -Starting with app-shells/bash-completion-2.1-r90, the framework used to -enable and manage completions in Gentoo is finally changing in order to -properly follow upstream design. This has some important implications -for our users. - -Firstly, the install location for completions changes to follow upstream -default. The completions enabled before the upgrade will continue to -work but you may no longer be able to enable or disable completions -installed prior to the upgrade. To solve this issue, the packages -installing completions need to rebuilt. The following command can be -used to automatically rebuild all the relevant packages: - -$ find /usr/share/bash-completion -maxdepth 1 -type f \ - '!' -name 'bash_completion' -exec emerge -1v {} + - -Secondly, the autoloading support introduced upstream removes the -penalties involved with enabling a great number of completions. This -allowed us to switch to an opt-out model where all completions installed -after the upgrade are enabled by default. Specific completions can be -disabled using 'eselect bashcomp disable ...' - -The model change implies that all current selections done using 'eselect -bashcomp' can not be properly migrated and will be disregarded when -the relevant completion files are built against the new bash-completion -version. After rebuilding all the packages providing completion files, -you may want to remove the symlinks that were used to configure -the previous framework using the following command: - -$ find /etc/bash_completion.d -type l -delete - -Thirdly, we have solved the issue causing bash-completion support to be -enabled by default on login shells only. If you needed to explicitly -source 'bash_completion' script in bashrc, you can safely remove that -code now since system-wide bashrc takes care of loading it. - -Lastly, we would like to explain that USE=bash-completion is being -removed from packages for the completions will be installed -unconditionally now. However, this will result in some implicit -dependencies being removed. Most specifically, users wishing to use -bash-completion will have to request app-shells/bash-completion -explicitly, e.g.: - -$ emerge -n app-shells/bash-completion |