[gentoo-dev] [PATCH] profiles: Reorder AMD64 profile list to place 17.1 on top

[gentoo-dev] [PATCH] profiles: Reorder AMD64 profile list to place 17.1 on top

[Brian Evans]

Users frequently are choosing the wrong profile versions in new installs
and accidentally downgrading to 17.0 with some saying they see it first.

A simple reordering could help new installs.

Since we do not guarantee ordering, any automated tooling concerns should not
be an issue because the full profile name can always be used.

Signed-off-by: Brian Evans <grknight@gentoo.org>
---
 profiles/profiles.desc | 36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/profiles/profiles.desc b/profiles/profiles.desc
index b45e918984a..aa1770a7840 100644
--- a/profiles/profiles.desc
+++ b/profiles/profiles.desc
@@ -14,24 +14,6 @@ alpha		default/linux/alpha/17.0/desktop/gnome		stable
 alpha		default/linux/alpha/17.0/desktop/gnome/systemd	stable
 alpha		default/linux/alpha/17.0/developer		stable
 
-# AMD64 Profiles
-# @MAINTAINER: amd64@gentoo.org
-amd64		default/linux/amd64/17.0				stable
-amd64		default/linux/amd64/17.0/selinux			stable
-amd64		default/linux/amd64/17.0/hardened			stable
-amd64		default/linux/amd64/17.0/hardened/selinux		stable
-amd64		default/linux/amd64/17.0/desktop			stable
-amd64		default/linux/amd64/17.0/desktop/gnome			stable
-amd64		default/linux/amd64/17.0/desktop/gnome/systemd		stable
-amd64		default/linux/amd64/17.0/desktop/plasma			stable
-amd64		default/linux/amd64/17.0/desktop/plasma/systemd		stable
-amd64		default/linux/amd64/17.0/developer			stable
-amd64		default/linux/amd64/17.0/no-multilib			stable
-amd64		default/linux/amd64/17.0/no-multilib/hardened		stable
-amd64		default/linux/amd64/17.0/no-multilib/hardened/selinux	stable
-amd64		default/linux/amd64/17.0/systemd			stable
-amd64		default/linux/amd64/17.0/x32				dev
-
 # SYMLINK_LIB=no profiles
 # Run app-portage/unsymlink-lib *before* switching the profile.
 # @MAINTAINER: mgorny@gentoo.org
@@ -50,6 +32,24 @@ amd64		default/linux/amd64/17.1/no-multilib/hardened		stable
 amd64		default/linux/amd64/17.1/no-multilib/hardened/selinux	stable
 amd64		default/linux/amd64/17.1/systemd			stable
 
+# AMD64 Profiles
+# @MAINTAINER: amd64@gentoo.org
+amd64		default/linux/amd64/17.0				stable
+amd64		default/linux/amd64/17.0/selinux			stable
+amd64		default/linux/amd64/17.0/hardened			stable
+amd64		default/linux/amd64/17.0/hardened/selinux		stable
+amd64		default/linux/amd64/17.0/desktop			stable
+amd64		default/linux/amd64/17.0/desktop/gnome			stable
+amd64		default/linux/amd64/17.0/desktop/gnome/systemd		stable
+amd64		default/linux/amd64/17.0/desktop/plasma			stable
+amd64		default/linux/amd64/17.0/desktop/plasma/systemd		stable
+amd64		default/linux/amd64/17.0/developer			stable
+amd64		default/linux/amd64/17.0/no-multilib			stable
+amd64		default/linux/amd64/17.0/no-multilib/hardened		stable
+amd64		default/linux/amd64/17.0/no-multilib/hardened/selinux	stable
+amd64		default/linux/amd64/17.0/systemd			stable
+amd64		default/linux/amd64/17.0/x32				dev
+
 # ARM Profiles
 # @MAINTAINER: arm@gentoo.org
 arm		default/linux/arm/17.0				stable
-- 
2.29.0

Re: [gentoo-dev] [PATCH] profiles: Reorder AMD64 profile list to place 17.1 on top

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3334 bytes --]

On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote:
> Users frequently are choosing the wrong profile versions in new installs
> and accidentally downgrading to 17.0 with some saying they see it first.
> 
> A simple reordering could help new installs.
> 
> Since we do not guarantee ordering, any automated tooling concerns should not
> be an issue because the full profile name can always be used.
> 
> Signed-off-by: Brian Evans <grknight@gentoo.org>
> ---
>  profiles/profiles.desc | 36 ++++++++++++++++++------------------
>  1 file changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/profiles/profiles.desc b/profiles/profiles.desc
> index b45e918984a..aa1770a7840 100644
> --- a/profiles/profiles.desc
> +++ b/profiles/profiles.desc
> @@ -14,24 +14,6 @@ alpha		default/linux/alpha/17.0/desktop/gnome		stable
>  alpha		default/linux/alpha/17.0/desktop/gnome/systemd	stable
>  alpha		default/linux/alpha/17.0/developer		stable
>  
> -# AMD64 Profiles
> -# @MAINTAINER: amd64@gentoo.org
> -amd64		default/linux/amd64/17.0				stable
> -amd64		default/linux/amd64/17.0/selinux			stable
> -amd64		default/linux/amd64/17.0/hardened			stable
> -amd64		default/linux/amd64/17.0/hardened/selinux		stable
> -amd64		default/linux/amd64/17.0/desktop			stable
> -amd64		default/linux/amd64/17.0/desktop/gnome			stable
> -amd64		default/linux/amd64/17.0/desktop/gnome/systemd		stable
> -amd64		default/linux/amd64/17.0/desktop/plasma			stable
> -amd64		default/linux/amd64/17.0/desktop/plasma/systemd		stable
> -amd64		default/linux/amd64/17.0/developer			stable
> -amd64		default/linux/amd64/17.0/no-multilib			stable
> -amd64		default/linux/amd64/17.0/no-multilib/hardened		stable
> -amd64		default/linux/amd64/17.0/no-multilib/hardened/selinux	stable
> -amd64		default/linux/amd64/17.0/systemd			stable
> -amd64		default/linux/amd64/17.0/x32				dev
> -
>  # SYMLINK_LIB=no profiles
>  # Run app-portage/unsymlink-lib *before* switching the profile.
>  # @MAINTAINER: mgorny@gentoo.org
> @@ -50,6 +32,24 @@ amd64		default/linux/amd64/17.1/no-multilib/hardened		stable
>  amd64		default/linux/amd64/17.1/no-multilib/hardened/selinux	stable
>  amd64		default/linux/amd64/17.1/systemd			stable
>  
> +# AMD64 Profiles
> +# @MAINTAINER: amd64@gentoo.org
> +amd64		default/linux/amd64/17.0				stable
> +amd64		default/linux/amd64/17.0/selinux			stable
> +amd64		default/linux/amd64/17.0/hardened			stable
> +amd64		default/linux/amd64/17.0/hardened/selinux		stable
> +amd64		default/linux/amd64/17.0/desktop			stable
> +amd64		default/linux/amd64/17.0/desktop/gnome			stable
> +amd64		default/linux/amd64/17.0/desktop/gnome/systemd		stable
> +amd64		default/linux/amd64/17.0/desktop/plasma			stable
> +amd64		default/linux/amd64/17.0/desktop/plasma/systemd		stable
> +amd64		default/linux/amd64/17.0/developer			stable
> +amd64		default/linux/amd64/17.0/no-multilib			stable
> +amd64		default/linux/amd64/17.0/no-multilib/hardened		stable
> +amd64		default/linux/amd64/17.0/no-multilib/hardened/selinux	stable
> +amd64		default/linux/amd64/17.0/systemd			stable
> +amd64		default/linux/amd64/17.0/x32				dev
> +
>  # ARM Profiles
>  # @MAINTAINER: arm@gentoo.org
>  arm		default/linux/arm/17.0				stable

Makes sense.  Thanks!
-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

[gentoo-dev] Deprecating AMD64 17.0 profiles?

[Andreas K. Hüttel]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny:
> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote:
> > Users frequently are choosing the wrong profile versions in new installs
> > and accidentally downgrading to 17.0 with some saying they see it first.
> > 
> > A simple reordering could help new installs.

Independent of this useful change, it's probably time to deprecate the amd64 
17.0 profiles!

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Alexey Sokolov]

22.10.2020 20:16, Andreas K. Hüttel пишет:
> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny:
>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote:
>>> Users frequently are choosing the wrong profile versions in new installs
>>> and accidentally downgrading to 17.0 with some saying they see it first.
>>>
>>> A simple reordering could help new installs.
> 
> Independent of this useful change, it's probably time to deprecate the amd64 
> 17.0 profiles!
> 

Prefix bootstrap script still makes new installations to use it

-- 
Best regards,
Alexey "DarthGandalf" Sokolov

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

On 07-11-2020 11:42:44 +0000, Alexey Sokolov wrote:
> 22.10.2020 20:16, Andreas K. Hüttel пишет:
> > Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny:
> >> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote:
> >>> Users frequently are choosing the wrong profile versions in new installs
> >>> and accidentally downgrading to 17.0 with some saying they see it first.
> >>>
> >>> A simple reordering could help new installs.
> > 
> > Independent of this useful change, it's probably time to deprecate the amd64 
> > 17.0 profiles!
> > 
> 
> Prefix bootstrap script still makes new installations to use it

This should be solved with

b0445c0a8dd6d2f792c5bb088b154aca53868353
a9c478dc881ee18fefc7342da994b00e60eaad8e

on gentoo.git and

0d7f6b6eb00d0f51f35019846b8f79048b30be93

on prefix.git.

Thanks,
Fabian


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Alexey Sokolov]

07.11.2020 12:56, Fabian Groffen пишет:
> On 07-11-2020 11:42:44 +0000, Alexey Sokolov wrote:
>> 22.10.2020 20:16, Andreas K. Hüttel пишет:
>>> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny:
>>>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote:
>>>>> Users frequently are choosing the wrong profile versions in new installs
>>>>> and accidentally downgrading to 17.0 with some saying they see it first.
>>>>>
>>>>> A simple reordering could help new installs.
>>>
>>> Independent of this useful change, it's probably time to deprecate the amd64 
>>> 17.0 profiles!
>>>
>>
>> Prefix bootstrap script still makes new installations to use it
> 
> This should be solved with
> 
> b0445c0a8dd6d2f792c5bb088b154aca53868353
> a9c478dc881ee18fefc7342da994b00e60eaad8e
> 
> on gentoo.git and
> 
> 0d7f6b6eb00d0f51f35019846b8f79048b30be93
> 
> on prefix.git.
> 
> Thanks,
> Fabian
> 
> 

Hi Fabian
I tried to migrate my prefix to 17.1, and there are issues.

1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an
error "/usr/lib is a real directory! was the migration done already?"

2) $ unsymlink-lib --root ~/gentoo --migrate --pretend
usage: unsymlink-lib [-h] [-p] [--root ROOT] [--analyze] [--migrate]
                     [--rollback] [--finish] [--force-rollback]
                     [--resume-finish] [-P PREFIX] [--hardlink]
unsymlink-lib: error: Requested action requires root privileges

Well, I worked it around by adding "is_root = True" to unsymlink-lib

3) Step 9 (Rebuild gcc) fails:
configure:4372: checking whether the C compiler works



configure:4394: x86_64-pc-linux-gnu-gcc    conftest.c  >&5



/home/user/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/as:
error while loading shared libraries:
libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so: cannot open shared
object file: No such file or directory
configure:4398: $? = 1



configure:4436: result: no

The file exists:
$ find ~ -name libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so
/home/user/gentoo/usr/lib/binutils/x86_64-pc-linux-gnu/2.34/libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so

-- 
Best regards,
Alexey "DarthGandalf" Sokolov

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 2865 bytes --]

On 09-11-2020 19:38:28 +0000, Alexey Sokolov wrote:
> Hi Fabian
> I tried to migrate my prefix to 17.1, and there are issues.
> 
> 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an
> error "/usr/lib is a real directory! was the migration done already?"

I think unsymlink-lib doesn't have Prefix support, but in addition,
what unsymlink-lib is trying to achieve, is not a thing perhaps on
Prefix.

A prefix system (at least all of mine) doesn't have libXX or lib/XX
(a.k.a.  multilib) directories.  The /usr-split was long ago removed,
and thus what we have is:

  lib -> usr/lib

Now, SYMLINK_LIB=no seems to split into lib and lib64, but lib64 does
not exist on Prefix systems.

Since Prefix is non-multilib by design*, I wonder if unsymlink-lib is
necessary in the best case, but going to break the Prefix system in the
worst case.

What instructed you to perform the migration?  Was it the news-item?  I
don't think it should apply for Prefix profiles, and perhaps we should
be happy the tool won't work.

* non-multilib is a decision dating back a decade or so, which means
  effectively any Prefix install you encounter should be non-multilib


> 2) $ unsymlink-lib --root ~/gentoo --migrate --pretend
> usage: unsymlink-lib [-h] [-p] [--root ROOT] [--analyze] [--migrate]
>                      [--rollback] [--finish] [--force-rollback]
>                      [--resume-finish] [-P PREFIX] [--hardlink]
> unsymlink-lib: error: Requested action requires root privileges
> 
> Well, I worked it around by adding "is_root = True" to unsymlink-lib

Did it do anything to your system like creating a lib64 directory?  Does
anything work (because I have doubts on whether your system can still
find the libs in there now).

> 
> 3) Step 9 (Rebuild gcc) fails:
> configure:4372: checking whether the C compiler works
> 
> 
> 
> configure:4394: x86_64-pc-linux-gnu-gcc    conftest.c  >&5
> 
> 
> 
> /home/user/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/as:
> error while loading shared libraries:
> libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so: cannot open shared

Something like this I was suspecting.  Can you still rollback?  If you
can, I'd try that and hope it restores your system in working order.

For any Prefix user, DO NOT run unsymlink-lib, I believe you should NOT
NEED IT!

Thanks,
Fabian

> object file: No such file or directory
> configure:4398: $? = 1
> 
> 
> 
> configure:4436: result: no
> 
> The file exists:
> $ find ~ -name libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so
> /home/user/gentoo/usr/lib/binutils/x86_64-pc-linux-gnu/2.34/libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so
> 
> -- 
> Best regards,
> Alexey "DarthGandalf" Sokolov
> 

-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

On Tue, 2020-11-10 at 08:55 +0100, Fabian Groffen wrote:
> On 09-11-2020 19:38:28 +0000, Alexey Sokolov wrote:
> > Hi Fabian
> > I tried to migrate my prefix to 17.1, and there are issues.
> > 
> > 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an
> > error "/usr/lib is a real directory! was the migration done already?"
> 
> I think unsymlink-lib doesn't have Prefix support, but in addition,
> what unsymlink-lib is trying to achieve, is not a thing perhaps on
> Prefix.
> 
> A prefix system (at least all of mine) doesn't have libXX or lib/XX
> (a.k.a.  multilib) directories.  The /usr-split was long ago removed,
> and thus what we have is:
> 
>   lib -> usr/lib
> 
> Now, SYMLINK_LIB=no seems to split into lib and lib64, but lib64 does
> not exist on Prefix systems.
> 

So what you're saying is that you've had the wrong value of SYMLINK_LIB
for ages, and now you've created a meaningless 17.1 profile that chnages
it but isn't actually supposed to change anything, correct?

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

On 10-11-2020 09:34:52 +0100, Michał Górny wrote:
> On Tue, 2020-11-10 at 08:55 +0100, Fabian Groffen wrote:
> > On 09-11-2020 19:38:28 +0000, Alexey Sokolov wrote:
> > > Hi Fabian
> > > I tried to migrate my prefix to 17.1, and there are issues.
> > > 
> > > 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an
> > > error "/usr/lib is a real directory! was the migration done already?"
> > 
> > I think unsymlink-lib doesn't have Prefix support, but in addition,
> > what unsymlink-lib is trying to achieve, is not a thing perhaps on
> > Prefix.
> > 
> > A prefix system (at least all of mine) doesn't have libXX or lib/XX
> > (a.k.a.  multilib) directories.  The /usr-split was long ago removed,
> > and thus what we have is:
> > 
> >   lib -> usr/lib
> > 
> > Now, SYMLINK_LIB=no seems to split into lib and lib64, but lib64 does
> > not exist on Prefix systems.
> > 
> 
> So what you're saying is that you've had the wrong value of SYMLINK_LIB
> for ages, and now you've created a meaningless 17.1 profile that chnages
> it but isn't actually supposed to change anything, correct?

I guess, because the amd64 17.0 profile is deprecated with force, and I
had to do something ...


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]

On Tue, 2020-11-10 at 09:41 +0100, Fabian Groffen wrote:
> On 10-11-2020 09:34:52 +0100, Michał Górny wrote:
> > On Tue, 2020-11-10 at 08:55 +0100, Fabian Groffen wrote:
> > > On 09-11-2020 19:38:28 +0000, Alexey Sokolov wrote:
> > > > Hi Fabian
> > > > I tried to migrate my prefix to 17.1, and there are issues.
> > > > 
> > > > 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an
> > > > error "/usr/lib is a real directory! was the migration done already?"
> > > 
> > > I think unsymlink-lib doesn't have Prefix support, but in addition,
> > > what unsymlink-lib is trying to achieve, is not a thing perhaps on
> > > Prefix.
> > > 
> > > A prefix system (at least all of mine) doesn't have libXX or lib/XX
> > > (a.k.a.  multilib) directories.  The /usr-split was long ago removed,
> > > and thus what we have is:
> > > 
> > >   lib -> usr/lib
> > > 
> > > Now, SYMLINK_LIB=no seems to split into lib and lib64, but lib64 does
> > > not exist on Prefix systems.
> > > 
> > 
> > So what you're saying is that you've had the wrong value of SYMLINK_LIB
> > for ages, and now you've created a meaningless 17.1 profile that chnages
> > it but isn't actually supposed to change anything, correct?
> 
> I guess, because the amd64 17.0 profile is deprecated with force, and I
> had to do something ...

Now that's a lie.  Only the regular amd64 profiles are deprecated.
There are no deprecation notices e.g. in the x32 profile or prefix
profiles.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

On 10-11-2020 09:49:27 +0100, Michał Górny wrote:
> > > So what you're saying is that you've had the wrong value of SYMLINK_LIB
> > > for ages, and now you've created a meaningless 17.1 profile that chnages
> > > it but isn't actually supposed to change anything, correct?
> > 
> > I guess, because the amd64 17.0 profile is deprecated with force, and I
> > had to do something ...
> 
> Now that's a lie.  Only the regular amd64 profiles are deprecated.
> There are no deprecation notices e.g. in the x32 profile or prefix
> profiles.

Our profiles either directly depend on the amd64/17.0 profile, or we use
a sub-profile from amd64/17.0 profile, so if it's going to get removed,
we are having a problem, don't we?


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

On Tue, 2020-11-10 at 09:53 +0100, Fabian Groffen wrote:
> On 10-11-2020 09:49:27 +0100, Michał Górny wrote:
> > > > So what you're saying is that you've had the wrong value of SYMLINK_LIB
> > > > for ages, and now you've created a meaningless 17.1 profile that chnages
> > > > it but isn't actually supposed to change anything, correct?
> > > 
> > > I guess, because the amd64 17.0 profile is deprecated with force, and I
> > > had to do something ...
> > 
> > Now that's a lie.  Only the regular amd64 profiles are deprecated.
> > There are no deprecation notices e.g. in the x32 profile or prefix
> > profiles.
> 
> Our profiles either directly depend on the amd64/17.0 profile, or we use
> a sub-profile from amd64/17.0 profile, so if it's going to get removed,
> we are having a problem, don't we?

It isn't going to be removed as long as other profiles depend on it.
 It'll probably be re-parented.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Alexey Sokolov]

[-- Attachment #1: Type: text/plain, Size: 2651 bytes --]

10.11.2020 08:55, Fabian Groffen пишет:
> On 09-11-2020 19:38:28 +0000, Alexey Sokolov wrote:
>> Hi Fabian
>> I tried to migrate my prefix to 17.1, and there are issues.
>>
>> 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an
>> error "/usr/lib is a real directory! was the migration done already?"
> 
> I think unsymlink-lib doesn't have Prefix support, but in addition,
> what unsymlink-lib is trying to achieve, is not a thing perhaps on
> Prefix.
> 
> A prefix system (at least all of mine) doesn't have libXX or lib/XX
> (a.k.a.  multilib) directories.  The /usr-split was long ago removed,
> and thus what we have is:
> 
>   lib -> usr/lib
> 
> Now, SYMLINK_LIB=no seems to split into lib and lib64, but lib64 does
> not exist on Prefix systems.
> 
> Since Prefix is non-multilib by design*, I wonder if unsymlink-lib is
> necessary in the best case, but going to break the Prefix system in the
> worst case.
> 
> What instructed you to perform the migration?  Was it the news-item?  I
> don't think it should apply for Prefix profiles, and perhaps we should
> be happy the tool won't work.

It was the big scary warning about the deprecation whenever I run
emerge. It contains list of steps.

> * non-multilib is a decision dating back a decade or so, which means
>   effectively any Prefix install you encounter should be non-multilib
> 
> 
>> 2) $ unsymlink-lib --root ~/gentoo --migrate --pretend
>> usage: unsymlink-lib [-h] [-p] [--root ROOT] [--analyze] [--migrate]
>>                      [--rollback] [--finish] [--force-rollback]
>>                      [--resume-finish] [-P PREFIX] [--hardlink]
>> unsymlink-lib: error: Requested action requires root privileges
>>
>> Well, I worked it around by adding "is_root = True" to unsymlink-lib
> 
> Did it do anything to your system like creating a lib64 directory?  Does
> anything work (because I have doubts on whether your system can still
> find the libs in there now).

Yes. Attaching logs.

> 
>>
>> 3) Step 9 (Rebuild gcc) fails:
>> configure:4372: checking whether the C compiler works
>>
>>
>>
>> configure:4394: x86_64-pc-linux-gnu-gcc    conftest.c  >&5
>>
>>
>>
>> /home/user/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/as:
>> error while loading shared libraries:
>> libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so: cannot open shared
> 
> Something like this I was suspecting.  Can you still rollback?  If you
> can, I'd try that and hope it restores your system in working order.

Yeah, don't worry, this is my ebuild-testing chroot. I just did "lxc
restore".


-- 
Best regards,
Alexey "DarthGandalf" Sokolov

[-- Attachment #2: analyze.log --]
[-- Type: text/x-log, Size: 6533 bytes --]

Analyzing files installed into lib & lib64...

directories that will be moved to /home/user/gentoo/lib/:
	(+ 0 files)

directories whose contents will be split between /home/user/gentoo/lib/ and /home/user/gentoo/lib64/:

orphan dirs/files (not owned by any package) that will be moved to /home/user/gentoo/lib/:
	gentoo
	modprobe.d
	systemd

orphan dirs/files (not owned by any package) that will be kept in /home/user/gentoo/lib64/:
	ld-2.31.so
	ld-linux-x86-64.so.2
	libBrokenLocale-2.31.so
	libBrokenLocale.so.1
	libSegFault.so
	libanl-2.31.so
	libanl.so.1
	libc-2.31.so
	libc.so.6
	libcrypt-2.31.so
	libcrypt.so.1
	libdl-2.31.so
	libdl.so.2
	libkmod.so.2
	libkmod.so.2.3.5
	libm-2.31.so
	libm.so.6
	libmemusage.so
	libmvec-2.31.so
	libmvec.so.1
	libnsl-2.31.so
	libnsl.so.1
	libnss_compat-2.31.so
	libnss_compat.so.2
	libnss_db-2.31.so
	libnss_db.so.2
	libnss_dns-2.31.so
	libnss_dns.so.2
	libnss_files-2.31.so
	libnss_files.so.2
	libnss_hesiod-2.31.so
	libnss_hesiod.so.2
	libpcprofile.so
	libpthread-2.31.so
	libpthread.so.0
	libresolv-2.31.so
	libresolv.so.2
	librt-2.31.so
	librt.so.1
	libthread_db-1.0.so
	libthread_db.so.1
	libutil-2.31.so
	libutil.so.1

directories that will be moved to /home/user/gentoo/usr/lib/:
	(+ 0 files)

directories whose contents will be split between /home/user/gentoo/usr/lib/ and /home/user/gentoo/usr/lib64/:

orphan dirs/files (not owned by any package) that will be moved to /home/user/gentoo/usr/lib/:
	Mcrt1.o
	Scrt1.o
	audit
	binutils
	cmake
	crt1.o
	crti.o
	crtn.o
	debug
	engines-1.1
	gawk
	gcc
	gconv
	gcrt1.o
	gettext
	glibc-2.31
	help2man
	libffi
	misc
	perl5
	pkgconfig
	portage
	python-exec
	python3.7
	systemd
	terminfo
	tmpfiles.d
	xml2Conf.sh

orphan dirs/files (not owned by any package) that will be kept in /home/user/gentoo/usr/lib64/:
	libBrokenLocale.a
	libBrokenLocale.so
	libacl.so
	libacl.so.1
	libacl.so.1.1.2253
	libanl.a
	libanl.so
	libasprintf.so
	libasprintf.so.0
	libasprintf.so.0.0.0
	libassuan.so
	libassuan.so.0
	libassuan.so.0.8.3
	libattr.so
	libattr.so.1
	libattr.so.1.1.2448
	libb2.so
	libb2.so.1
	libb2.so.1.0.4
	libblkid.so
	libblkid.so.1
	libblkid.so.1.1.0
	libbz2.so
	libbz2.so.1
	libbz2.so.1.0
	libbz2.so.1.0.6
	libc.a
	libc.so
	libc_nonshared.a
	libcrypt.a
	libcrypt.so
	libcrypto.so
	libcrypto.so.1.1
	libcurl.so
	libcurl.so.4
	libcurl.so.4.6.0
	libcurses.so
	libdb-5.3.a
	libdb-5.3.la
	libdb-5.3.so
	libdb.a
	libdb.so
	libdl.a
	libdl.so
	libexpat.so
	libexpat.so.1
	libexpat.so.1.6.10
	libexpatw.so
	libexpatw.so.1
	libexpatw.so.1.6.10
	libfdisk.so
	libfdisk.so.1
	libfdisk.so.1.1.0
	libffi.so
	libffi.so.7
	libffi.so.7.1.0
	libfl.a
	libform.so
	libform.so.6
	libform.so.6.2
	libformw.so
	libformw.so.6
	libformw.so.6.2
	libg.a
	libgcrypt.so
	libgcrypt.so.20
	libgcrypt.so.20.2.6
	libgdbm.so
	libgdbm.so.6
	libgdbm.so.6.0.0
	libgdbm_compat.so
	libgdbm_compat.so.4
	libgdbm_compat.so.4.0.0
	libgettextlib-0.21.so
	libgettextlib.so
	libgettextpo.so
	libgettextpo.so.0
	libgettextpo.so.0.5.7
	libgettextsrc-0.21.so
	libgettextsrc.so
	libgmp.so
	libgmp.so.10
	libgmp.so.10.4.0
	libgmpxx.so
	libgmpxx.so.4
	libgmpxx.so.4.6.0
	libgnutls-openssl.so
	libgnutls-openssl.so.27
	libgnutls-openssl.so.27.0.2
	libgnutls.so
	libgnutls.so.30
	libgnutls.so.30.28.1
	libgnutlsxx.so
	libgnutlsxx.so.28
	libgnutlsxx.so.28.1.0
	libgpg-error.so
	libgpg-error.so.0
	libgpg-error.so.0.29.0
	libgpgme.so
	libgpgme.so.11
	libgpgme.so.11.22.0
	libgpgmepp.so
	libgpgmepp.so.6
	libgpgmepp.so.6.9.0
	libhistory.so
	libhistory.so.8
	libhistory.so.8.0
	libhogweed.so
	libhogweed.so.6
	libhogweed.so.6.0
	libidn2.so
	libidn2.so.0
	libidn2.so.0.3.7
	libkmod.so
	libksba.so
	libksba.so.8
	libksba.so.8.11.6
	libltdl.la
	libltdl.so
	libltdl.so.7
	libltdl.so.7.3.1
	liblzma.so
	liblzma.so.5
	liblzma.so.5.2.5
	libm.a
	libm.so
	libmagic.so
	libmagic.so.1
	libmagic.so.1.0.0
	libmcheck.a
	libmenu.so
	libmenu.so.6
	libmenu.so.6.2
	libmenuw.so
	libmenuw.so.6
	libmenuw.so.6.2
	libmount.so
	libmount.so.1
	libmount.so.1.1.0
	libmpc.so
	libmpc.so.3
	libmpc.so.3.2.0
	libmpfr.so
	libmpfr.so.6
	libmpfr.so.6.1.0
	libmvec.a
	libmvec.so
	libncurses++.so
	libncurses++.so.6
	libncurses++.so.6.2
	libncurses++w.so
	libncurses++w.so.6
	libncurses++w.so.6.2
	libncurses.so
	libncurses.so.6
	libncurses.so.6.2
	libncursesw.so
	libncursesw.so.6
	libncursesw.so.6.2
	libnettle.so
	libnettle.so.8
	libnettle.so.8.0
	libnghttp2.so
	libnghttp2.so.14
	libnghttp2.so.14.20.0
	libnpth.so
	libnpth.so.0
	libnpth.so.0.1.2
	libnss_compat.so
	libnss_db.so
	libnss_dns.so
	libnss_files.so
	libnss_hesiod.so
	libpanel.so
	libpanel.so.6
	libpanel.so.6.2
	libpanelw.so
	libpanelw.so.6
	libpanelw.so.6.2
	libpcre.so
	libpcre.so.1
	libpcre.so.1.2.12
	libpcre2-8.so
	libpcre2-8.so.0
	libpcre2-8.so.0.10.0
	libpcre2-posix.so
	libpcre2-posix.so.2
	libpcre2-posix.so.2.0.3
	libpcrecpp.so
	libpcrecpp.so.0
	libpcrecpp.so.0.0.2
	libpcreposix.so
	libpcreposix.so.0
	libpcreposix.so.0.0.7
	libperl.so
	libperl.so.5.30
	libperl.so.5.30.3
	libpkgconf.a
	libpkgconf.so
	libpkgconf.so.3
	libpkgconf.so.3.0.0
	libpopt.so
	libpopt.so.0
	libpopt.so.0.0.0
	libprocps.so
	libprocps.so.8
	libprocps.so.8.0.2
	libpthread.a
	libpthread.so
	libpython3.7m.so
	libpython3.7m.so.1.0
	libreadline.so
	libreadline.so.8
	libreadline.so.8.0
	libresolv.a
	libresolv.so
	librt.a
	librt.so
	libsandbox.so
	libseccomp.so
	libseccomp.so.2
	libseccomp.so.2.4.3
	libsmartcols.so
	libsmartcols.so.1
	libsmartcols.so.1.1.0
	libssl.so
	libssl.so.1.1
	libtasn1.so
	libtasn1.so.6
	libtasn1.so.6.6.0
	libtextstyle.so
	libtextstyle.so.0
	libtextstyle.so.0.1.1
	libthread_db.so
	libtinfo.so
	libtinfo.so.6
	libtinfo.so.6.2
	libtinfow.so
	libtinfow.so.6
	libtinfow.so.6.2
	libunistring.so
	libunistring.so.2
	libunistring.so.2.1.0
	libutil.a
	libutil.so
	libuuid.so
	libuuid.so.1
	libuuid.so.1.3.0
	libxml2.so
	libxml2.so.2
	libxml2.so.2.9.10
	libz.so
	libz.so.1
	libz.so.1.2.11
	libzstd.so
	libzstd.so.1
	libzstd.so.1.4.4
	locale
	preloadable_libintl.so

directories that will be moved to /home/user/gentoo/usr/local/lib/:
	(+ 0 files)

directories whose contents will be split between /home/user/gentoo/usr/local/lib/ and /home/user/gentoo/usr/local/lib64/:


Warning: no lib32 paths found. This is fine if you are running no-multilib,
otherwise this is suspicious.


The state has been saved and the migration is ready to proceed.
To initiate it, please run:

	/home/user/gentoo/usr/lib/python-exec/python3.7/unsymlink-lib --migrate

Please do not perform any changes to the system at this point.
If you performed any changes, please rerun the analysis.

[-- Attachment #3: ls-l.log --]
[-- Type: text/x-log, Size: 1036 bytes --]

total 55928
-rw-r--r-- 1 user user     6533 Nov 10 09:18 analyze.log
drwxr-xr-x 1 user user      790 Oct  6 20:11 bin
drwxr-xr-x 1 user user     1052 Nov 10 09:17 etc
lrwxrwxrwx 1 user user        7 Nov 10 09:19 lib -> lib.new
drwxr-xr-x 1 user user       46 Nov 10 09:19 lib.new
drwxr-xr-x 1 user user     1334 Oct  9 19:44 lib64
-rw-r--r-- 1 user user        0 Nov 10 09:19 ls-l.log
-rw-r--r-- 1 user user     1448 Nov 10 09:19 migrate-pretend.log
-rw-r--r-- 1 user user      838 Nov 10 09:19 migrate.log
drwxr-xr-x 1 user user        0 Jul 20 00:04 run
drwxr-xr-x 1 user user      212 Oct  6 20:11 sbin
-rw-r--r-- 1 user user  1467019 Jul 19 23:48 stage1.log
-rw-r--r-- 1 user user 11120838 Jul 20 00:04 stage2.log
-rw-r--r-- 1 user user 44644530 Jul 20 00:49 stage3.log
-rwxr-xr-x 1 user user     3327 Jul 20 08:18 startprefix
-rwxr-xr-x 1 user user     3332 Sep  1 23:12 startprefix2
drwxr-xr-x 1 user user        0 Jul 20 08:12 tmp
drwxr-xr-x 1 user user      130 Nov 10 09:19 usr
drwxr-xr-x 1 user user       42 Jul 20 00:43 var

[-- Attachment #4: migrate.log --]
[-- Type: text/x-log, Size: 838 bytes --]

[/home/user/gentoo/lib32] & /home/user/gentoo/lib -> /home/user/gentoo/lib.new ...
[/home/user/gentoo/usr/lib32] & /home/user/gentoo/usr/lib -> /home/user/gentoo/usr/lib.new ...
[/home/user/gentoo/usr/local/lib32] & /home/user/gentoo/usr/local/lib -> /home/user/gentoo/usr/local/lib.new ...
Updating: /home/user/gentoo/lib -> lib.new ...
Updating: /home/user/gentoo/usr/lib -> lib.new ...
Updating: /home/user/gentoo/usr/local/lib -> lib.new ...


Initial migration complete. Please now test whether your system works
correctly. It might be a good idea to try rebooting it. Once tested,
complete the migration and clean up backup files via calling:

	/home/user/gentoo/usr/lib/python-exec/python3.7/unsymlink-lib --finish

If you wish to revert the changes, run:

	/home/user/gentoo/usr/lib/python-exec/python3.7/unsymlink-lib --rollback

[-- Attachment #5: migrate-pretend.log --]
[-- Type: text/x-log, Size: 1457 bytes --]

Those are the actions that would be performed:
mkdir /home/user/gentoo/lib.new
cp -a --reflink=auto -- /home/user/gentoo/lib/systemd /home/user/gentoo/lib/gentoo /home/user/gentoo/lib/modprobe.d /home/user/gentoo/lib.new/
mkdir /home/user/gentoo/usr/lib.new
cp -a --reflink=auto -- /home/user/gentoo/usr/lib/xml2Conf.sh /home/user/gentoo/usr/lib/Scrt1.o /home/user/gentoo/usr/lib/libffi /home/user/gentoo/usr/lib/python-exec /home/user/gentoo/usr/lib/gettext /home/user/gentoo/usr/lib/terminfo /home/user/gentoo/usr/lib/python3.7 /home/user/gentoo/usr/lib/systemd /home/user/gentoo/usr/lib/portage /home/user/gentoo/usr/lib/cmake /home/user/gentoo/usr/lib/Mcrt1.o /home/user/gentoo/usr/lib/gconv /home/user/gentoo/usr/lib/binutils /home/user/gentoo/usr/lib/debug /home/user/gentoo/usr/lib/perl5 /home/user/gentoo/usr/lib/gcc /home/user/gentoo/usr/lib/help2man /home/user/gentoo/usr/lib/gcrt1.o /home/user/gentoo/usr/lib/crtn.o /home/user/gentoo/usr/lib/crt1.o /home/user/gentoo/usr/lib/glibc-2.31 /home/user/gentoo/usr/lib/misc /home/user/gentoo/usr/lib/gawk /home/user/gentoo/usr/lib/tmpfiles.d /home/user/gentoo/usr/lib/pkgconfig /home/user/gentoo/usr/lib/audit /home/user/gentoo/usr/lib/crti.o /home/user/gentoo/usr/lib/engines-1.1 /home/user/gentoo/usr/lib.new/
mkdir /home/user/gentoo/usr/local/lib.new
ln -s -f -T lib.new /home/user/gentoo/lib
ln -s -f -T lib.new /home/user/gentoo/usr/lib
ln -s -f -T lib.new /home/user/gentoo/usr/local/lib

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

On 10-11-2020 09:21:53 +0000, Alexey Sokolov wrote:
> > What instructed you to perform the migration?  Was it the news-item?  I
> > don't think it should apply for Prefix profiles, and perhaps we should
> > be happy the tool won't work.
> 
> It was the big scary warning about the deprecation whenever I run
> emerge. It contains list of steps.

Ok.  I don't know if we can do anything about that.

> > Did it do anything to your system like creating a lib64 directory?  Does
> > anything work (because I have doubts on whether your system can still
> > find the libs in there now).
> 
> Yes. Attaching logs.

The logs seem to indicate that it thinks all libs on your systems do not
belong to any package.  This suggests the tool cannot locate the VDB or
something, as most of the things in the list are obviously owned by
packages.

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Andreas K. Huettel]

On November 7, 2020 1:42:44 PM GMT+02:00, Alexey Sokolov <alexey+gentoo@asokolov.org> wrote:
>22.10.2020 20:16, Andreas K. Hüttel пишет:
>> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny:
>>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote:
>>>> Users frequently are choosing the wrong profile versions in new
>installs
>>>> and accidentally downgrading to 17.0 with some saying they see it
>first.
>>>>
>>>> A simple reordering could help new installs.
>> 
>> Independent of this useful change, it's probably time to deprecate
>the amd64 
>> 17.0 profiles!
>> 
>
>Prefix bootstrap script still makes new installations to use it

Meh. Time to change that then...
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Alexey Sokolov]

07.11.2020 14:39, Andreas K. Huettel пишет:
> 
> 
> On November 7, 2020 1:42:44 PM GMT+02:00, Alexey Sokolov <alexey+gentoo@asokolov.org> wrote:
>> 22.10.2020 20:16, Andreas K. Hüttel пишет:
>>> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny:
>>>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote:
>>>>> Users frequently are choosing the wrong profile versions in new
>> installs
>>>>> and accidentally downgrading to 17.0 with some saying they see it
>> first.
>>>>>
>>>>> A simple reordering could help new installs.
>>>
>>> Independent of this useful change, it's probably time to deprecate
>> the amd64 
>>> 17.0 profiles!
>>>
>>
>> Prefix bootstrap script still makes new installations to use it
> 
> Meh. Time to change that then...
> 

Nah, Fabian has just fixed it (in another reply to my message in this
thread)

-- 
Best regards,
Alexey "DarthGandalf" Sokolov

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Jaco Kroon]

Hi,

Having just completed the migration on two systems I found some things
which concerns me:

1.  A default/linux/amd64/17.0/desktop to
default/linux/amd64/17.1/desktop.  This differs from the no-multilib in
that there are symlinks now for the various lib32 to lib.  No such
symlinks on the no-mulilib systems (this makes sense, but why is lib32 a
symlink back to lib/)

2.  If /usr/local/lib* doesn't exist the script bails out.  This only
happened on one of the two systems I did now, specifically the
default/linux/amd64/17.0/no-multilib =>
default/linux/amd64/17.1/no-multilib one.  Other systems I've just
checked seems to already have this by virtue of
/usr/local/lib{64,32}/.keep existing, but no owners of the files, so
this could be sheer dump luck.  Which is never good.  Sorted by manually
creating lib32 and creating the symlink as instructed.  Post migrate
there is a lib/ and lib64/ folder.  The complaint on this was about
/usr/local/lib32 if I recall correctly

What is the actual "target" objective with the change?  I would have
expected (not being one to follow this too closely):

lib/ - arch independent stuff (eg, netifrc / dhclient etc scripts).
lib32/ - 32-bit specific stuff (libs for 32-bit).
lib64/ - 64-bit specific stuff (libs for 64-bit).

What am I missing?

Kind Regards,
Jaco

On 2020/10/22 21:16, Andreas K. Hüttel wrote:

> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny:
>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote:
>>> Users frequently are choosing the wrong profile versions in new installs
>>> and accidentally downgrading to 17.0 with some saying they see it first.
>>>
>>> A simple reordering could help new installs.
> Independent of this useful change, it's probably time to deprecate the amd64 
> 17.0 profiles!
>

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

>>>>> On Mon, 09 Nov 2020, Jaco Kroon wrote:

> What is the actual "target" objective with the change?  I would have
> expected (not being one to follow this too closely):

> lib/ - arch independent stuff (eg, netifrc / dhclient etc scripts).
> lib32/ - 32-bit specific stuff (libs for 32-bit).
> lib64/ - 64-bit specific stuff (libs for 64-bit).

It is explained here:
https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout#Rationale

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Jaco Kroon]

Hi Ulrich,

On 2020/11/09 12:59, Ulrich Mueller wrote:
>>>>>> On Mon, 09 Nov 2020, Jaco Kroon wrote:
>> What is the actual "target" objective with the change?  I would have
>> expected (not being one to follow this too closely):
>> lib/ - arch independent stuff (eg, netifrc / dhclient etc scripts).
>> lib32/ - 32-bit specific stuff (libs for 32-bit).
>> lib64/ - 64-bit specific stuff (libs for 64-bit).
> It is explained here:
> https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout#Rationale

Thank you, that makes a lot of sense and answers all my questions
...just wondering where the lib32 => lib symlink comes from now.

So if anybody else ends up wondering:

jkroon@plastiekpoot ~ $ ls -lah /lib32 /usr/lib32 /usr/local/lib32
ls: cannot access '/usr/local/lib32': No such file or directory
lrwxrwxrwx 1 root root 3 Nov  9 10:02 /lib32 -> lib
lrwxrwxrwx 1 root root 3 Nov  9 10:02 /usr/lib32 -> lib

equery has some answers that there are still stuff installed into
/usr/lib32 (which will likely clear over time, and the symlink will be
unmerged).  There is this one potential pitfall down the line that I'm
seeing, fairly certain this would have been covered and that a remerge
of glibc will fix this:

jkroon@plastiekpoot ~ $ equery belongs /lib32 /usr/lib32
...
sys-libs/glibc-2.32-r2 (/lib -> lib64)

So job well done to the implementation team!!  Great work thank you!

Kind Regards,
Jaco

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Marek Szuba]

[-- Attachment #1.1.1: Type: text/plain, Size: 700 bytes --]

On 2020-11-09 12:09, Jaco Kroon wrote:

> equery has some answers that there are still stuff installed into
> /usr/lib32 (which will likely clear over time, and the symlink will be
> unmerged).  There is this one potential pitfall down the line that I'm
> seeing, fairly certain this would have been covered and that a remerge
> of glibc will fix this:

As a matter of fact the complete migration procedure (including cleaning 
up lib32 symlinks) was described in the news items introducing 17.1, for 
instance "2019-06-05-amd64-17-1-profiles-are-now-stable". In short, run

emerge -1v --deep /lib32 /usr/lib32 /usr/lib/llvm/*/lib32

and the lib32 symlinks should go.

-- 
Marecki

[-- Attachment #1.1.2: OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc --]
[-- Type: application/pgp-keys, Size: 122125 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Peter Stuge]

Andreas K. Hüttel wrote:
> it's probably time to deprecate the amd64 17.0 profiles!

I for one am not so excited about the amd64 17.1 profiles. On the surface
it appeared to me that one developer has "taken over" just about everything,
which (regardless of the individual) can't be a good thing..


Jaco Kroon wrote:
> ...just wondering where the lib32 => lib symlink comes from now.

baselayout contains a conversion to/from lib symlink(s).


Kind regards

//Peter

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Aaron Bauman]

On November 9, 2020 6:54:33 AM EST, Peter Stuge <peter@stuge.se> wrote:
>Andreas K. Hüttel wrote:
>> it's probably time to deprecate the amd64 17.0 profiles!
>
>I for one am not so excited about the amd64 17.1 profiles. On the
>surface
>it appeared to me that one developer has "taken over" just about
>everything,
>which (regardless of the individual) can't be a good thing..
>

What does this even mean?

>
>Jaco Kroon wrote:
>> ...just wondering where the lib32 => lib symlink comes from now.
>
>baselayout contains a conversion to/from lib symlink(s).
>
>
>Kind regards
>
>//Peter

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Andreas K. Huettel]

On November 9, 2020 1:54:33 PM GMT+02:00, Peter Stuge <peter@stuge.se> wrote:
>Andreas K. Hüttel wrote:
>> it's probably time to deprecate the amd64 17.0 profiles!
>
>I for one am not so excited about the amd64 17.1 profiles. On the
>surface
>it appeared to me that one developer has "taken over" just about
>everything,
>which (regardless of the individual) can't be a good thing..
>

Please wait a bit longer, I'm still working on my evil world domination plans! 😎

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.