Re: [gentoo-dev] [RFC] amd64 17.1 profiles stable
> On Sun, 24 Feb 2019, Aaron Bauman wrote: > Following up on Michał's work with the amd64 17.1 profiles, I have > revised the original news item for review with the intent of moving the > profiles to stable. > These profiles were initially published by Michał in December 2017 as > exp and were moved to dev status in December 2018. As such, these profiles > will now be marked stable following the news item review. "Changes that require a re-read of the news item (i.e., most changes that are not spelling or formatting related) should instead use a new news item." (GLEP 42) > === > Title: amd64 17.1 Profiles > Author: Michał Górny > Posted: 2019-12-23 > Revision: 4 > 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 > The 17.1 amd64 profiles have been in the Gentoo repository for several months > and have been tested in exp and dev profile statuses. These profiles switch to > a more standard 'no SYMLINK_LIB' multilib layout, and require explicit > migration > as described below. They are now considered stable. Flip the order of the 2nd and 3rd sentence? You're talking about stability, then explain the profiles, then stability again. Also, please keep line wrapping consistent with the rest of the text, i.e. at 72 characters. > In these profiles, the lib->lib64 compatibility symlink is removed. > The 'lib' directory becomes a separate directory, that is used > for cross-arch and native non-library packages (gcc, clang) and 32-bit > libraries on the multilib profile (for better compatibility with > prebuilt x86 packages). > Migration from both 13.0 and 17.0 profiles are supported. In case s/are/is/ (Subject is "migration" and it's singular.) > of the former, please read the news item for 17.0 upgrade first > and enable gcc 6.4.0 or newer first as explained there. > The migration is performed using app-portage/unsymlink-lib tool. > The following steps can be used to upgrade your system: > 1. Sync and upgrade your system to the newest package versions >to reduce the risk of issues. > 2. Install the tool, e.g. via 'emerge -1v app-portage/unsymlink-lib' > 3. Run 'unsymlink-lib --analyze' and check the output for obvious >mistakes. If you need to perform any changes to the system, remember >to run 'unsymlink-lib --analyze' again afterwards. > [past this point do not call emerge or modify /usr manually] > 4. This is a very good time to make a backup. > 5. Run 'unsymlink-lib --migrate'. You can add '--pretend' first to see >what is going to happen. > 6. Reboot your system and see if it still boots. Check if important >programs work. In particular, check if 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 3. > 7. Run 'unsymlink-lib --finish'. You can add '--pretend' first to see >what is going to happen but note that you're going to see a very long >list of files to remove. > 8. Switch the profile, e.g.: > eselect profile set --force default/linux/amd64/17.1/desktop > [at this point you can start using emerge again] > 9. Rebuild sys-devel/gcc. If you are switching from 13.0 profiles, >rebuild sys-devel/binutils and sys-libs/glibc afterwards. > 10. If you are using a multilib profile, rebuild all 32-bit packages. > This can be done using: > emerge -1v /lib32 /usr/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. > 11. Onc
Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
> On Wed, 20 Feb 2019, Michał Górny wrote:
> On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
>> > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
>>
>>
>> ># Don't install libtool archives (even for modules)
>> > - prune_libtool_files --all
>> > + find "${D}" -name '*.la' -delete || die
>>
>> Maybe restrict removal to regular files, i.e. add "-type f"?
> I suppose you should have spoken up when people started adopting that
> 'find' line all over the place. Though I honestly doubt we're going
> to see many packages installing '*.la' non-files.
I have updated the example in ltprune.eclass now.
That still won't catch regular non-libtool files, but people needing
additional sanity checks can still use the eclass.
Ulrich
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
On 02/24/19 01:19, Matt Turner wrote:
> On Fri, Feb 22, 2019 at 8:30 PM desultory wrote:
>>
>> On 02/20/19 02:36, Michał Górny wrote:
>>> On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> On Wed, 20 Feb 2019, Matt Turner wrote:
> # Don't install libtool archives (even for modules)
> - prune_libtool_files --all
> + find "${D}" -name '*.la' -delete || die
Maybe restrict removal to regular files, i.e. add "-type f"?
>>>
>>> I suppose you should have spoken up when people started adopting that
>>> 'find' line all over the place. Though I honestly doubt we're going to
>>> see many packages installing '*.la' non-files.
>>>
>> Just so we are all clear here: your argument is that more fully correct
>> approaches should not be considered in the present and future because
>> less fully correct approaches were implemented in the past? And,
>> further, that since nothing matching a specific pattern happens to come
>> to your mind at he moment, such things do not exist? Perhaps dialing
>> back the rhetoric from 11 and considering feedback as an opportunity to
>> improve existing code is called for in this case, among others.
>
> I think you might be reading more into this than was intended.
>
I am reading into it what was written into it.
> I read his email as lamenting that the horse has left the barn, so to
> speak.
Since we are going with animal husbandry analogies, his specific manner
of rejecting feedback was more akin to leaving the barn door open,
letting the horse go play in traffic and ignoring that there is no real
reason to believe that the horse will not be killed by a vehicle on the
basis of it has only been hit a few times and has not yet succumbed to
its injuries.
> There are already hundreds of uses of find -name '*.la' -delete
> without -type f in the tree, probably in large part because
> ltprune.eclass suggests the form without it.
>
Which, following the animal husbandry theme brings us to the elephant in
the room [1]:
"
# @MAINTAINER:
# Michał Górny
"
Given that another developer has noted two different issues with the
suggested boilerplate [2][3], why has he, as a member of QA and as
maintainer of the eclass in question, rejected or simply ignored their
concerns? He would not even need to override another maintainer to fix a
*comment* in that eclass. Is asking for rationale somehow that much of a
problem?
> Suggesting dialing down the rhetoric when it appears that you have
> overreacted is a bit humorous.
>
Given his behavior, it hardly seems so to me.
>
[1] https://gitweb.gentoo.org/repo/gentoo.git/plain/eclass/ltprune.eclass
[2]
https://archives.gentoo.org/gentoo-dev/message/d528ab54d230afc11430ea9660c7feaa
[3]
https://archives.gentoo.org/gentoo-dev/message/539b9ba7d4b21086bc2ba3b8d11dacdb
Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
On 02/24/19 04:04, Michał Górny wrote:
> On Sat, 2019-02-23 at 22:19 -0800, Matt Turner wrote:
>> On Fri, Feb 22, 2019 at 8:30 PM desultory wrote:
>>>
>>> On 02/20/19 02:36, Michał Górny wrote:
On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
>> On Wed, 20 Feb 2019, Matt Turner wrote:
>
>
>> # Don't install libtool archives (even for modules)
>> - prune_libtool_files --all
>> + find "${D}" -name '*.la' -delete || die
>
> Maybe restrict removal to regular files, i.e. add "-type f"?
I suppose you should have spoken up when people started adopting that
'find' line all over the place. Though I honestly doubt we're going to
see many packages installing '*.la' non-files.
>>>
>>> Just so we are all clear here: your argument is that more fully correct
>>> approaches should not be considered in the present and future because
>>> less fully correct approaches were implemented in the past? And,
>>> further, that since nothing matching a specific pattern happens to come
>>> to your mind at he moment, such things do not exist? Perhaps dialing
>>> back the rhetoric from 11 and considering feedback as an opportunity to
>>> improve existing code is called for in this case, among others.
>>
>> I think you might be reading more into this than was intended.
>>
>> I read his email as lamenting that the horse has left the barn, so to
>> speak. There are already hundreds of uses of find -name '*.la' -delete
>> without -type f in the tree, probably in large part because
>> ltprune.eclass suggests the form without it.
>>
>> Suggesting dialing down the rhetoric when it appears that you have
>> overreacted is a bit humorous.
>>
>
> He simply decided to stalk me and issue ad hominem attacks whenever he
> can. It's how professionals in Gentoo react to critique.
>
I am hardly "stalking" you. I am addressing bad ideas and poor
maintainer behavior, that it happens to be yours is immaterial to me.
Besides, you effectively demanded that I participate more broadly[1], so
do kindly pick one sort of libel and stick to it. As contradicting
yourself not only weakens your argument (were it to have a basis to
begin with), it makes malicious intent more obvious.
As for ad hominem attacks, do kindly present examples, I would be most
interested in any which you can demonstrate are unjustified. When I ask
if/how/why your behavior is acceptable for someone in your roles, I am
seriously asking that question. I want to know the rationale, especially
under what are, at least nominally, the rules governing the interactions
and behaviors which I am inquiring about. Though I will forego linking
to that, as that evidently annoys you.
[1]
https://archives.gentoo.org/gentoo-project/message/b498bcfaf34ffc355eaba3afafd1ee96
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2019-02-24 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2019-02-24 23:59 UTC. Removals: dev-libs/sway 20190222-22:37 bman 99a4d0be218 dev-libs/swayidle 20190222-22:34 bman dfbb280e9b7 dev-libs/swaylock 20190222-22:34 bman dfbb280e9b7 dev-libs/wlroots 20190222-22:30 bman 8b43c571011 Additions: app-benchmarks/interbench 20190221-19:44 monsieurp 50a19d3c52f app-crypt/20190221-19:40 monsieurp c478e16b2ca app-emulation/slirp4netns 20190218-10:31 zmedicofb9c5140920 app-text/diff-pdf 20190216-17:30 mjo0cc3af65220 dev-python/requests-credssp 20190221-10:40 chainsaw 4a124cb2e50 gui-apps/swayidle 20190222-22:35 bman 97aba5400b8 gui-apps/swaylock 20190222-22:35 bman 97aba5400b8 gui-libs/wlroots 20190222-22:31 bman 057227baf4c gui-wm/sway 20190222-22:38 bman 38de6aa1104 kde-misc/plasma-pass 20190218-14:55 asturm 490c50511b9 media-fonts/ibm-plex 20190222-08:23 zlogene6612c8d3b88 media-libs/lsp-plugins20190223-22:23 prometheanfire 4f83787f636 sci-libs/tensorflow-estimator 20190217-13:59 perfinion b7bb43b59e0 -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-libs/sway,removed,bman,20190222-22:37,99a4d0be218 dev-libs/swayidle,removed,bman,20190222-22:34,dfbb280e9b7 dev-libs/swaylock,removed,bman,20190222-22:34,dfbb280e9b7 dev-libs/wlroots,removed,bman,20190222-22:30,8b43c571011 Added Packages: media-libs/lsp-plugins,added,prometheanfire,20190223-22:23,4f83787f636 gui-wm/sway,added,bman,20190222-22:38,38de6aa1104 gui-apps/swayidle,added,bman,20190222-22:35,97aba5400b8 gui-apps/swaylock,added,bman,20190222-22:35,97aba5400b8 gui-libs/wlroots,added,bman,20190222-22:31,057227baf4c app-crypt/,added,monsieurp,20190221-19:40,c478e16b2ca app-benchmarks/interbench,added,monsieurp,20190221-19:44,50a19d3c52f media-fonts/ibm-plex,added,zlogene,20190222-08:23,6612c8d3b88 dev-python/requests-credssp,added,chainsaw,20190221-10:40,4a124cb2e50 app-text/diff-pdf,added,mjo,20190216-17:30,0cc3af65220 app-emulation/slirp4netns,added,zmedico,20190218-10:31,fb9c5140920 kde-misc/plasma-pass,added,asturm,20190218-14:55,490c50511b9 sci-libs/tensorflow-estimator,added,perfinion,20190217-13:59,b7bb43b59e0 Done.
[gentoo-dev] [RFC] [v2] amd64 17.1 profiles stable
Following the feedback so far, here is v2 of the news item. It will be released as a new news items and the old news item removed. This will ensure that users are prompted again and can follow the appropriate directions. Now wrapped at 72 chars. Thanks to Michał for the feedback. === Title: amd64 17.1 Profiles Author: Aaron Bauman Posted: 2019-02-xx Revision: 0 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 The 17.1 amd64 profiles have been in the Gentoo repository for over a year and have been tested in exp and dev profile statuses. These profiles switch to a more standard 'no SYMLINK_LIB' multilib layout and require explicit migration as described below. They are now considered stable and the removal of all 13.0 profiles is imminent. Users are highly encouraged to transition their systems. In these profiles, the lib->lib64 compatibility symlink is removed. The 'lib' directory becomes a separate directory, that is used for cross-arch and native non-library packages (gcc, clang) and 32-bit libraries on the multilib profile (for better compatibility with prebuilt x86 packages). Migration from both 13.0 and 17.0 profiles are supported. In case of the former, please read the news item for 17.0 upgrade first and enable gcc 6.4.0 or newer first as explained there. The migration is performed using app-portage/unsymlink-lib tool. The following steps can be used to upgrade your system: 1. Sync and upgrade your system to the newest package versions to reduce the risk of issues. 2. Install the tool, e.g. via 'emerge -1v app-portage/unsymlink-lib' 3. Run 'unsymlink-lib --analyze' and check the output for obvious mistakes. If you need to perform any changes to the system, remember to run 'unsymlink-lib --analyze' again afterwards. [past this point do not call emerge or modify /usr manually] 4. This is a very good time to make a backup. 5. Run 'unsymlink-lib --migrate'. You can add '--pretend' first to see what is going to happen. 6. Reboot your system and see if it still boots. Check if important programs work. In particular, check if 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 3. 7. Run 'unsymlink-lib --finish'. You can add '--pretend' first to see what is going to happen but note that you're going to see a very long list of files to remove. 8. Switch the profile, e.g.: eselect profile set --force default/linux/amd64/17.1/desktop [at this point you can start using emerge again] 9. Rebuild sys-devel/gcc. If you are switching from 13.0 profiles, rebuild sys-devel/binutils and sys-libs/glibc afterwards. 10. If you are using a multilib profile, rebuild all 32-bit packages. This can be done using: emerge -1v /lib32 /usr/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. 11. 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. For known issues, please see bug #506276 [1]. 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 [2]. [1]:https://bugs.gentoo.org/506276 [2]:https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 3/3] xorg-2.eclass: Add EAPI=7 support
On Sun, Feb 24, 2019 at 4:44 AM Matija Skala wrote:
>
> Dne sreda, 20. februar 2019 ob 05:45:41 CET je Matt Turner napisal:
> > + default
> > xorg-2_reconf_source
> > - autotools-utils_src_prepare "$@"
> > +
> > + [[ ${PATCHES} ]] && epatch "${PATCHES[@]}"
> > }
> >
>
> On EAPI=7, this code would apply ${PATCHES} twice.
Thank you! Removed.
[gentoo-dev] [PATCH] cmake-utils.eclass: Fix _cmake_modify-cmakelists, add QA output
Bug: https://bugs.gentoo.org/674768
---
eclass/cmake-utils.eclass | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 77c6d0481c..42a108976f 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -419,13 +419,17 @@ _cmake_modify-cmakelists() {
grep -qs "<<< Gentoo configuration >>>"
"${CMAKE_USE_DIR}"/CMakeLists.txt && return 0
# Comment out all set ( value)
- # TODO Add QA checker - inform when variable being checked for below is
set in CMakeLists.txt
- find "${CMAKE_USE_DIR}" -name CMakeLists.txt \
- -exec sed -i -e
'/^[[:space:]]*[sS][eE][tT][[:space:]]*([[:space:]]*CMAKE_BUILD_TYPE.*)/{s/^/#IGNORE
/g}' {} + \
- -exec sed -i -e
'/^[[:space:]]*[sS][eE][tT][[:space:]]*([[:space:]]*CMAKE_COLOR_MAKEFILE.*)/{s/^/#IGNORE
/g}' {} + \
- -exec sed -i -e
'/^[[:space:]]*[sS][eE][tT][[:space:]]*([[:space:]]*CMAKE_INSTALL_PREFIX.*)/{s/^/#IGNORE
/g}' {} + \
- -exec sed -i -e
'/^[[:space:]]*[sS][eE][tT][[:space:]]*([[:space:]]*CMAKE_VERBOSE_MAKEFILE.*)/{s/^/#IGNORE
/g}' {} + \
- || die "${LINENO}: failed to disable hardcoded settings"
+ find "${CMAKE_USE_DIR}" -name CMakeLists.txt -exec sed \
+ -e
'/^[[:space:]]*set[[:space:]]*([[:space:]]*CMAKE_BUILD_TYPE[[:space:]].*)/I{s/^/#_cmake_modify_IGNORE
/g}' \
+ -e
'/^[[:space:]]*set[[:space:]]*([[:space:]]*CMAKE_COLOR_MAKEFILE[[:space:]].*)/I{s/^/#_cmake_modify_IGNORE
/g}' \
+ -e
'/^[[:space:]]*set[[:space:]]*([[:space:]]*CMAKE_INSTALL_PREFIX[[:space:]].*)/I{s/^/#_cmake_modify_IGNORE
/g}' \
+ -e
'/^[[:space:]]*set[[:space:]]*([[:space:]]*CMAKE_VERBOSE_MAKEFILE[[:space:]].*)/I{s/^/#G_cmake_modify_IGNORE
/g}' \
+ -i {} + || die "${LINENO}: failed to disable hardcoded settings"
+ local x
+ for x in $(find "${CMAKE_USE_DIR}" -name CMakeLists.txt -exec grep -l
"^#_cmake_modify_IGNORE" {} +;); do
+ eqawarn "Hardcoded definition(s) removed in $(echo "${x}" | cut
-c $((${#CMAKE_USE_DIR}+2))-):"
+ eqawarn "$(grep -se '^#_cmake_modify_IGNORE' ${x} | cut -c
22-99)"
+ done
# NOTE Append some useful summary here
cat >> "${CMAKE_USE_DIR}"/CMakeLists.txt <<- _EOF_ || die
--
2.20.1
[gentoo-dev] [PATCH] glep-0063: Require encryption subkey, and make primary certify-only
Following the recent mailing list discussion indicating that developers are taking GLEP 63 as only source of truth about OpenPGP keys, and can make assumption that if encryption key is not listed there they should not have one. Amend the specification to extend it beyond the previous limited scope of commit signing, and require an encryption key appropriately. This matches the GnuPG defaults. While at it, add a recommendation that the primary key is certify-only. Other usage is implicitly discouraged anyway via requiring subkeys. Originally this recommendation was omitted as I wasn't aware that gpg had a (hidden) option to change usage of existing keys. --- glep-0063.rst | 43 +-- 1 file changed, 29 insertions(+), 14 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index 64fb437..b4bbe62 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -7,10 +7,10 @@ Author: Robin H. Johnson , Michał Górny Type: Standards Track Status: Final -Version: 2 +Version: 2.1 Created: 2013-02-18 -Last-Modified: 2018-07-21 -Post-History: 2013-11-10, 2018-07-03, 2018-07-21 +Last-Modified: 2019-02-24 +Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24 Content-Type: text/x-rst --- @@ -28,6 +28,13 @@ OpenPGP key management policies for the Gentoo Linux distribution. Changes === +v2.1 + A requirement for an encryption key has been added, in order to extend + the GLEP beyond commit signing and into use of OpenPGP for dev-to-dev + and user-to-dev communications. + + A recommendation for primary key to be certify-only has been added. + v2 The distinct minimal and recommended expirations have been replaced by a single requirement. The rules have been simplified to use @@ -70,22 +77,28 @@ Linux development are sorely needed. This document provides both a set of bare minimum requirements and a set of best practice recommendations for the use of GnuPG (or other OpenPGP providers) by Gentoo Linux developers. It is intended to provide a basis for future improvements such as, e.g., -consistent ebuild or package signing and verifying by end users. +consistent ebuild or package signing and verification by end users, +and providing secure and authenticated communication channel between users +and developers. Specifications for OpenPGP keys === Bare minimum requirements - -This section specifies obligatory requirements for all OpenPGP keys used -to commit to Gentoo. Keys that do not conform to those requirements can -not be used to commit. +This section specifies obligatory requirements for all OpenPGP keys that +are used in the context of Gentoo developer actions. All developers +are required to have at least one key conforming to those requirements. +Keys that do not conform to them can not be used to commit. 1. SHA-2 series output digest (SHA-1 digests internally permitted), at least 256-bit. All subkey self-signatures must use this digest. -2. Signing subkey that is different from the primary key, and does not - have any other capabilities enabled. +2. a. Signing subkey that is different from the primary key, and does + not have any other capabilities enabled. + + b. Encryption subkey that is different from the primary key, and does + not have any other capabilities enabled. 3. Primary key and the signing subkey are both of type EITHER: @@ -110,15 +123,17 @@ The developers should follow those practices unless there is a strong technical reason not to (e.g. hardware limitations, necessity of replacing their primary key). -1. Primary key and the signing subkey are both of type RSA, 2048 bits +1. Primary key has only ``certify`` capability enabled. + +2. Primary key and the signing subkey are both of type RSA, 2048 bits (OpenPGP v4 key format or later). -2. Key expiration renewed annually to a fixed day of the year. +3. Key expiration renewed annually to a fixed day of the year. -3. Create a revocation certificate & store it hardcopy offsite securely +4. Create a revocation certificate & store it hardcopy offsite securely (it's about ~300 bytes). -4. Encrypted backup of your secret keys. +5. Encrypted backup of your secret keys. Gentoo LDAP === @@ -193,7 +208,7 @@ References Copyright = -Copyright (c) 2013-2018 by Robin Hugh Johnson, Andreas K. Hüttel, +Copyright (c) 2013-2019 by Robin Hugh Johnson, Andreas K. Hüttel, Marissa Fischer, Michał Górny. This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 -- 2.21.0.rc2
Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
On Sat, 2019-02-23 at 22:19 -0800, Matt Turner wrote:
> On Fri, Feb 22, 2019 at 8:30 PM desultory wrote:
> >
> > On 02/20/19 02:36, Michał Górny wrote:
> > > On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> > > > > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
> > > >
> > > >
> > > > > # Don't install libtool archives (even for modules)
> > > > > - prune_libtool_files --all
> > > > > + find "${D}" -name '*.la' -delete || die
> > > >
> > > > Maybe restrict removal to regular files, i.e. add "-type f"?
> > >
> > > I suppose you should have spoken up when people started adopting that
> > > 'find' line all over the place. Though I honestly doubt we're going to
> > > see many packages installing '*.la' non-files.
> > >
> >
> > Just so we are all clear here: your argument is that more fully correct
> > approaches should not be considered in the present and future because
> > less fully correct approaches were implemented in the past? And,
> > further, that since nothing matching a specific pattern happens to come
> > to your mind at he moment, such things do not exist? Perhaps dialing
> > back the rhetoric from 11 and considering feedback as an opportunity to
> > improve existing code is called for in this case, among others.
>
> I think you might be reading more into this than was intended.
>
> I read his email as lamenting that the horse has left the barn, so to
> speak. There are already hundreds of uses of find -name '*.la' -delete
> without -type f in the tree, probably in large part because
> ltprune.eclass suggests the form without it.
>
> Suggesting dialing down the rhetoric when it appears that you have
> overreacted is a bit humorous.
>
He simply decided to stalk me and issue ad hominem attacks whenever he
can. It's how professionals in Gentoo react to critique.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] amd64 17.1 profiles stable
On Sat, 2019-02-23 at 19:44 -0500, Aaron Bauman wrote: > Title: amd64 17.1 Profiles > Author: Michał Górny Please put yourself here, as you're taking over. > Posted: 2019-12-23 Cool date, bro. > Revision: 4 To be honest, I'm not sure if updating the old news item is a good solution. People who have read it already (and dismissed as irrelevant at the time) would not see it again, would they? So maybe adding it as a new news item (and possibly removing the old one) would be a better course of action. > 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 > > The 17.1 amd64 profiles have been in the Gentoo repository for several months > and have been tested in exp and dev profile statuses. These profiles switch to > a more standard 'no SYMLINK_LIB' multilib layout, and require explicit > migration > as described below. They are now considered stable. The text below has been wrapped at 72 chars. Please use a consistent wrapping for the whole news item (whichever you choose). Probably worthwhile to put emphasis that old profiles are going to be deprecated and users actually should start migrating. > In these profiles, the lib->lib64 compatibility symlink is removed. > The 'lib' directory becomes a separate directory, that is used > for cross-arch and native non-library packages (gcc, clang) and 32-bit > libraries on the multilib profile (for better compatibility with > prebuilt x86 packages). > > Migration from both 13.0 and 17.0 profiles are supported. In case > of the former, please read the news item for 17.0 upgrade first > and enable gcc 6.4.0 or newer first as explained there. > > The migration is performed using app-portage/unsymlink-lib tool. > The following steps can be used to upgrade your system: > > 1. Sync and upgrade your system to the newest package versions >to reduce the risk of issues. > > 2. Install the tool, e.g. via 'emerge -1v app-portage/unsymlink-lib' > > 3. Run 'unsymlink-lib --analyze' and check the output for obvious >mistakes. If you need to perform any changes to the system, remember >to run 'unsymlink-lib --analyze' again afterwards. > > [past this point do not call emerge or modify /usr manually] > > 4. This is a very good time to make a backup. > > 5. Run 'unsymlink-lib --migrate'. You can add '--pretend' first to see >what is going to happen. > > 6. Reboot your system and see if it still boots. Check if important >programs work. In particular, check if 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 3. > > 7. Run 'unsymlink-lib --finish'. You can add '--pretend' first to see >what is going to happen but note that you're going to see a very long >list of files to remove. > > 8. Switch the profile, e.g.: > > eselect profile set --force default/linux/amd64/17.1/desktop > > [at this point you can start using emerge again] > > 9. Rebuild sys-devel/gcc. If you are switching from 13.0 profiles, >rebuild sys-devel/binutils and sys-libs/glibc afterwards. > > 10. If you are using a multilib profile, rebuild all 32-bit packages. > This can be done using: > > emerge -1v /lib32 /usr/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. > > 11. 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
