Mailing List Archive

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

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

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.

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

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!
>

>>>>> 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

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

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

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

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.

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.

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

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

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

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

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

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

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

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

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