Mailing List Archive

On Saturday, 23 March 2024 14:59:15 GMT Peter Humphrey wrote:
> Hello list,
>
> Has anyone tried the profile upgrade that was notified today? I tried it
> just now on a small rescue system and it failed on installing the first
> binary package, complaining that my disk layout was split-usr.
>
> My /var is on a separate partition, for easy of file recovery, but /usr is
> not. Is this the cause of the problem?

Please ignore that. Three seconds later I realised what I should have done:
run emerge-usr first.

--
Regards,
Peter.

On Saturday, 23 March 2024 15:08:56 GMT Peter Humphrey wrote:
> On Saturday, 23 March 2024 14:59:15 GMT Peter Humphrey wrote:
> > Hello list,
> >
> > Has anyone tried the profile upgrade that was notified today? I tried it
> > just now on a small rescue system and it failed on installing the first
> > binary package, complaining that my disk layout was split-usr.
> >
> > My /var is on a separate partition, for easy of file recovery, but /usr is
> > not. Is this the cause of the problem?
>
> Please ignore that. Three seconds later I realised what I should have done:
> run emerge-usr first.

The advice on the e-news item is to switch to the new 23.0 profile first using
the same fs structure you currently have and then to proceed with the
migration to a merged-usr.

Therefore if you have a split usr fs structure, you need to select a 'split-
usr' 23.0 profile.

On Saturday, 23 March 2024 15:08:56 GMT Peter Humphrey wrote:
> On Saturday, 23 March 2024 14:59:15 GMT Peter Humphrey wrote:
> > Hello list,
> >
> > Has anyone tried the profile upgrade that was notified today? I tried it
> > just now on a small rescue system and it failed on installing the first
> > binary package, complaining that my disk layout was split-usr.
> >
> > My /var is on a separate partition, for easy of file recovery, but /usr is
> > not. Is this the cause of the problem?
>
> Please ignore that. Three seconds later I realised what I should have done:
> run emerge-usr first.

No, that's wrong too. I need to do a bit of head-scratching.

--
Regards,
Peter.

Peter Humphrey wrote:
> On Saturday, 23 March 2024 15:08:56 GMT Peter Humphrey wrote:
>> On Saturday, 23 March 2024 14:59:15 GMT Peter Humphrey wrote:
>>> Hello list,
>>>
>>> Has anyone tried the profile upgrade that was notified today? I tried it
>>> just now on a small rescue system and it failed on installing the first
>>> binary package, complaining that my disk layout was split-usr.
>>>
>>> My /var is on a separate partition, for easy of file recovery, but /usr is
>>> not. Is this the cause of the problem?
>> Please ignore that. Three seconds later I realised what I should have done:
>> run emerge-usr first.
> No, that's wrong too. I need to do a bit of head-scratching.
>


I just did my weekly sync.  I'm currently on this profile.


  [8]   default/linux/amd64/17.1/desktop/plasma (stable) *


To find the profile I want to upgrade to, I look for the same name but
with the added split-usr added, for us old fuggys who still do things
the OLD way.  ;-) 


  [48]  default/linux/amd64/23.0/split-usr/desktop/plasma (exp)


If one uses systemd, look for the same thing as old but with systemd. 
Same with no-multilib or some of the other options.  Basically, just
look for the same as old but with the new bits you need. 

I have a spare hard drive that I do my updates on.  It's like a stage 4
thing that I update with a script, if you can call it that, right after
syncing.  I chroot in and do my updates there.  If anything goes wrong,
I just reset back to the stage 4 and try again if worse comes to worse. 
Once done, I copy the packages over to my main system and add -k to
emerge.  It makes updates a lot faster and stable.  Sometimes during KDE
updates, things can get out of sync and things stop working.  Having
packages that take a long time to compile makes that worse.  The qt
package, LOo, Firefox etc etc.  You can be sure I'm going to do that
with this update.  It's gonna take long enough to do the -k bit much
less the actual compile part.  I seem to recall we have to do a emerge
-e world with this.  o_O

I hope that helps you pick the correct one.  I been concerned about the
switch too.  It's easy to mess up something. 

Dale

:-)  :-) 

On Saturday, 23 March 2024 17:33:17 GMT Dale wrote:
> Peter Humphrey wrote:
> > On Saturday, 23 March 2024 15:08:56 GMT Peter Humphrey wrote:
> >> On Saturday, 23 March 2024 14:59:15 GMT Peter Humphrey wrote:
> >>> Hello list,
> >>>
> >>> Has anyone tried the profile upgrade that was notified today? I tried it
> >>> just now on a small rescue system and it failed on installing the first
> >>> binary package, complaining that my disk layout was split-usr.
> >>>
> >>> My /var is on a separate partition, for easy of file recovery, but /usr
> >>> is
> >>> not. Is this the cause of the problem?
> >>
> >> Please ignore that. Three seconds later I realised what I should have
> >> done: run emerge-usr first.
> >
> > No, that's wrong too. I need to do a bit of head-scratching.
>
> I just did my weekly sync. I'm currently on this profile.
>
>
> [8] default/linux/amd64/17.1/desktop/plasma (stable) *
>
>
> To find the profile I want to upgrade to, I look for the same name but
> with the added split-usr added, for us old fuggys who still do things
> the OLD way. ;-)
>
>
> [48] default/linux/amd64/23.0/split-usr/desktop/plasma (exp)
>
>
> If one uses systemd, look for the same thing as old but with systemd.
> Same with no-multilib or some of the other options. Basically, just
> look for the same as old but with the new bits you need.
>
> I have a spare hard drive that I do my updates on. It's like a stage 4
> thing that I update with a script, if you can call it that, right after
> syncing. I chroot in and do my updates there. If anything goes wrong,
> I just reset back to the stage 4 and try again if worse comes to worse.
> Once done, I copy the packages over to my main system and add -k to
> emerge. It makes updates a lot faster and stable. Sometimes during KDE
> updates, things can get out of sync and things stop working. Having
> packages that take a long time to compile makes that worse. The qt
> package, LOo, Firefox etc etc. You can be sure I'm going to do that
> with this update. It's gonna take long enough to do the -k bit much
> less the actual compile part. I seem to recall we have to do a emerge
> -e world with this. o_O
>
> I hope that helps you pick the correct one. I been concerned about the
> switch too. It's easy to mess up something.
>
> Dale
>
> :-) :-)

I suggest it would be best to take heed of the devs hard work and read the
instructions they have provided instead of winging it:

https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions

Il 23/03/24 18:42, Michael ha scritto:
> I suggest it would be best to take heed of the devs hard work and
read the
> instructions they have provided instead of winging it:
>
> https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions
>
I'm currently running a local merged profile:

# cat /var/db/repos/local/profiles/no-multilib-hardened-desktop/parent
gentoo:default/linux/amd64/17.1/no-multilib/hardened
gentoo:targets/desktop

$ euse -a | grep usr
split-usr           [+  D F ]

I suppose that before step 3 of the wiki I'd need to create a new local
merged profile, e.g.:

#cat
/var/db/repos/local/profiles/23.0-split-usr-no-multilib-hardened-desktop/parent
gentoo:default/linux/amd64/23.0/split-usr/no-multilib/hardened
gentoo:targets/split-usr/desktop

Does that make sense?

thanks

raf

On Saturday, 23 March 2024 18:29:58 GMT ralfconn wrote:
> Il 23/03/24 18:42, Michael ha scritto:
> > I suggest it would be best to take heed of the devs hard work and
>
> read the
>
> > instructions they have provided instead of winging it:
> >
> > https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions
>
> I'm currently running a local merged profile:
>
> # cat /var/db/repos/local/profiles/no-multilib-hardened-desktop/parent
> gentoo:default/linux/amd64/17.1/no-multilib/hardened
> gentoo:targets/desktop
>
> $ euse -a | grep usr
> split-usr [+ D F ]
>
> I suppose that before step 3 of the wiki I'd need to create a new local
> merged profile, e.g.:
>
> #cat
> /var/db/repos/local/profiles/23.0-split-usr-no-multilib-hardened-desktop/par
> ent gentoo:default/linux/amd64/23.0/split-usr/no-multilib/hardened
> gentoo:targets/split-usr/desktop
>
> Does that make sense?
>
> thanks
>
> raf

Update portage and check the profiles offered by 'eselect profile list'. For
example, I can see:

[51] default/linux/amd64/23.0/split-usr/no-multilib/hardened (stable)

which should provide what you're after.

Il 23/03/24 20:18, Michael ha scritto:
> On Saturday, 23 March 2024 19:10:28 GMT you wrote:
>> Il 23/03/24 19:43, Michael ha scritto:
>>> On Saturday, 23 March 2024 18:29:58 GMT ralfconn wrote:
>>>> Il 23/03/24 18:42, Michael ha scritto:
>>>> > I suggest it would be best to take heed of the devs hard work and
>>>>
>>>> read the
>>>>
>>>> > instructions they have provided instead of winging it:
>>>> >
>>>> > https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructio
>>>> > ns
>>>>
>>>> I'm currently running a local merged profile:
>>>>
>>>> # cat /var/db/repos/local/profiles/no-multilib-hardened-desktop/parent
>>>> gentoo:default/linux/amd64/17.1/no-multilib/hardened
>>>> gentoo:targets/desktop
>>>>
>>>> $ euse -a | grep usr
>>>> split-usr [+ D F ]
>>>>
>>>> I suppose that before step 3 of the wiki I'd need to create a new local
>>>> merged profile, e.g.:
>>>>
>>>> #cat
>>>> /var/db/repos/local/profiles/23.0-split-usr-no-multilib-hardened-desktop/
>>>> par ent gentoo:default/linux/amd64/23.0/split-usr/no-multilib/hardened
>>>> gentoo:targets/split-usr/desktop
>>>>
>>>> Does that make sense?
>>>>
>>>> thanks
>>>>
>>>> raf
>>> Update portage and check the profiles offered by 'eselect profile list'.
>>> For example, I can see:
>>>
>>> [51] default/linux/amd64/23.0/split-usr/no-multilib/hardened (stable)
>>>
>>> which should provide what you're after.
>> It's not a 'desktop' profile
> I'd think once you emerge/update the desktop environment or main packages you
> want, most of the desktop related USE choices will be applied anyway. In the
> first instance I'd select the above profile ([51]), update your toolchain and
> try an emerge --pretend of @world to see what USE flag differences remain. If
> this approach leaves you short you can always create your own merged profile
> as you had done.

(Due to my mistake the last message was sent to me only instead of the list)

Unfortunately not, the non-desktop profile is very stripped-down
compared to the desktop one. There's maybe 20 or more USE flags present
in my merged profile that are missing from [51].

In the meanwhile I tried to switch to my merged 23.0 profile, in step 9
binutils updates fine while gcc builds but fails to install with no
error message, so for now I'm back to 'merged' 17.1. Tomorrow I'll try
to analyze the install log better.

BTW, the only differences comparing emerge --info before and after the
switch are:

LDFLAGS="-Wl,-O1 -Wl,--as-needed"

vs

LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs"

and

USE = "cli fortran"

that after the switch disappear in favour of the new ones

USE = "lzma zstd"

(at least, in my 'crooked' local profile)

Michael wrote:
> On Saturday, 23 March 2024 17:33:17 GMT Dale wrote:
>> Peter Humphrey wrote:
>>> On Saturday, 23 March 2024 15:08:56 GMT Peter Humphrey wrote:
>>>> On Saturday, 23 March 2024 14:59:15 GMT Peter Humphrey wrote:
>>>>> Hello list,
>>>>>
>>>>> Has anyone tried the profile upgrade that was notified today? I tried it
>>>>> just now on a small rescue system and it failed on installing the first
>>>>> binary package, complaining that my disk layout was split-usr.
>>>>>
>>>>> My /var is on a separate partition, for easy of file recovery, but /usr
>>>>> is
>>>>> not. Is this the cause of the problem?
>>>> Please ignore that. Three seconds later I realised what I should have
>>>> done: run emerge-usr first.
>>> No, that's wrong too. I need to do a bit of head-scratching.
>> I just did my weekly sync. I'm currently on this profile.
>>
>>
>> [8] default/linux/amd64/17.1/desktop/plasma (stable) *
>>
>>
>> To find the profile I want to upgrade to, I look for the same name but
>> with the added split-usr added, for us old fuggys who still do things
>> the OLD way. ;-)
>>
>>
>> [48] default/linux/amd64/23.0/split-usr/desktop/plasma (exp)
>>
>>
>> If one uses systemd, look for the same thing as old but with systemd.
>> Same with no-multilib or some of the other options. Basically, just
>> look for the same as old but with the new bits you need.
>>
>> I have a spare hard drive that I do my updates on. It's like a stage 4
>> thing that I update with a script, if you can call it that, right after
>> syncing. I chroot in and do my updates there. If anything goes wrong,
>> I just reset back to the stage 4 and try again if worse comes to worse.
>> Once done, I copy the packages over to my main system and add -k to
>> emerge. It makes updates a lot faster and stable. Sometimes during KDE
>> updates, things can get out of sync and things stop working. Having
>> packages that take a long time to compile makes that worse. The qt
>> package, LOo, Firefox etc etc. You can be sure I'm going to do that
>> with this update. It's gonna take long enough to do the -k bit much
>> less the actual compile part. I seem to recall we have to do a emerge
>> -e world with this. o_O
>>
>> I hope that helps you pick the correct one. I been concerned about the
>> switch too. It's easy to mess up something.
>>
>> Dale
>>
>> :-) :-)
> I suggest it would be best to take heed of the devs hard work and read the
> instructions they have provided instead of winging it:
>
> https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions
>


I just read the news item which kinda says what I posted.  It listed a
couple examples as well.  I just went with what I have in case it would
clear up any muddy waters. 

In my chroot, I'm to the gcc build.

Dale

:-)  :-) 

Il 23/03/24 20:37, ralfconn ha scritto:
> In the meanwhile I tried to switch to my merged 23.0 profile, in step
> 9 binutils updates fine while gcc builds but fails to install with no
> error message, so for now I'm back to 'merged' 17.1. Tomorrow I'll try
> to analyze the install log better.
>
Looks like the problem was self-induced. I run a KSPP kernel, one
recommended setting blocks ptrace. Looking at yesterday's gcc failed
merge log I found that the kernel had blocked several attempts to call
ptrace. I disabled the option, gcc built fine and now I am running the
last step (rebuild world).

raf

Hi folks,

my current profile is default/linux/amd64/17.1, but I already migrated
to merged-usr some while ago (I know, that is not supported, really).

Any advice how to migrate to 23.0?

Cheers,
Björn

On Sunday, 24 March 2024 18:31:37 GMT Björn Fischer wrote:
> Hi folks,
>
> my current profile is default/linux/amd64/17.1, but I already migrated
> to merged-usr some while ago (I know, that is not supported, really).
>
> Any advice how to migrate to 23.0?
>
> Cheers,
> Björn

The default OpenRC 23.0 profiles now use merged-usr. So select a flavour to
suit your needs which does NOT show split-usr.

On Saturday, 23 March 2024 17:42:29 GMT Michael wrote:

> I suggest it would be best to take heed of the devs hard work and read the
> instructions they have provided instead of winging it:
>
> https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions

Of course I was doing that, but from the news item. My problem was that I
wasn't reading straight.

(I think I had a form of covid last month, and it's left a few loose ends -
mostly in my brain!)

--
Regards,
Peter.

Le lun. 25 mars 2024 à 15:41, Peter Humphrey <peter@prh.myzen.co.uk> a
écrit :

> On Saturday, 23 March 2024 17:42:29 GMT Michael wrote:
>
> > I suggest it would be best to take heed of the devs hard work and read
> the
> > instructions they have provided instead of winging it:
> >
> > https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions
>
> Of course I was doing that, but from the news item. My problem was that I
> wasn't reading straight.
>
> (I think I had a form of covid last month, and it's left a few loose ends
> -
> mostly in my brain!)
>
> --
> Regards,
> Peter.
>
>
>
Hello all,

I updated my profile from amd64/17.1/desktop/systemd/merged-usr to
amd64/23.0/desktop/systemd.
I followed the quite clear instructions without any issue.
With emerge --ask --emptytree @world, i had to recompile 1400 packages, so
it took all night long !!!
Some scare when the package 1201 failed and everything stopped (i forgot
the keep-going option).
Nevertheless, I rebooted and everything works fine ! Whew !!!

What i understand is that Gentoo is now mostly based on binary packages.
The sources are now the exception.
It's the opposite of what Gentoo was before... Right ?

Regards,

--
Jacques

On Monday, 25 March 2024 17:00:18 GMT Jacques Montier wrote:
> Le lun. 25 mars 2024 à 15:41, Peter Humphrey <peter@prh.myzen.co.uk> a
>
> écrit :
> > On Saturday, 23 March 2024 17:42:29 GMT Michael wrote:
> > > I suggest it would be best to take heed of the devs hard work and read
> >
> > the
> >
> > > instructions they have provided instead of winging it:
> > >
> > > https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions
> >
> > Of course I was doing that, but from the news item. My problem was that I
> > wasn't reading straight.
> >
> > (I think I had a form of covid last month, and it's left a few loose ends
> > -
> > mostly in my brain!)
> >
> > --
> > Regards,
> > Peter.
>
> Hello all,
>
> I updated my profile from amd64/17.1/desktop/systemd/merged-usr to
> amd64/23.0/desktop/systemd.
> I followed the quite clear instructions without any issue.
> With emerge --ask --emptytree @world, i had to recompile 1400 packages, so
> it took all night long !!!
> Some scare when the package 1201 failed and everything stopped (i forgot
> the keep-going option).
> Nevertheless, I rebooted and everything works fine ! Whew !!!
>
> What i understand is that Gentoo is now mostly based on binary packages.
> The sources are now the exception.
> It's the opposite of what Gentoo was before... Right ?
>
> Regards,
>
> --
> Jacques

Not really, Gentoo is still based on compiling from source - for those who
want to optimise/customise their systems.

More recently pre-compiled binary packages which suit generic hardware and
software configurations are also made available for those who want to get
something up and running quickly. This makes Gentoo similar to other binary
distributions.

The command syntax in the instructions included "--getbinpkg" to download pre-
built binaries, but with this note:

"In case you are already familiar with binary packages, you should be
able to add '--getbinpkg' to the emerge calls to speed things up.
The use of binary packages is completely optional though, and also not
as much tested as the source-based upgrade path yet."

Therefore, you can fetch binaries from the mirrors when these have the same
configuration as your locally compiled software to make the whole upgrade
complete faster, but it remains a personal choice.

Le lun. 25 mars 2024 à 18:18, Michael <confabulate@kintzios.com> a écrit :

> On Monday, 25 March 2024 17:00:18 GMT Jacques Montier wrote:
> > Le lun. 25 mars 2024 à 15:41, Peter Humphrey <peter@prh.myzen.co.uk> a
> >
> > écrit :
> > > On Saturday, 23 March 2024 17:42:29 GMT Michael wrote:
> > > > I suggest it would be best to take heed of the devs hard work and
> read
> > >
> > > the
> > >
> > > > instructions they have provided instead of winging it:
> > > >
> > > >
> https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions
> > >
> > > Of course I was doing that, but from the news item. My problem was
> that I
> > > wasn't reading straight.
> > >
> > > (I think I had a form of covid last month, and it's left a few loose
> ends
> > > -
> > > mostly in my brain!)
> > >
> > > --
> > > Regards,
> > > Peter.
> >
> > Hello all,
> >
> > I updated my profile from amd64/17.1/desktop/systemd/merged-usr to
> > amd64/23.0/desktop/systemd.
> > I followed the quite clear instructions without any issue.
> > With emerge --ask --emptytree @world, i had to recompile 1400 packages,
> so
> > it took all night long !!!
> > Some scare when the package 1201 failed and everything stopped (i forgot
> > the keep-going option).
> > Nevertheless, I rebooted and everything works fine ! Whew !!!
> >
> > What i understand is that Gentoo is now mostly based on binary packages.
> > The sources are now the exception.
> > It's the opposite of what Gentoo was before... Right ?
> >
> > Regards,
> >
> > --
> > Jacques
>
> Not really, Gentoo is still based on compiling from source - for those who
> want to optimise/customise their systems.
>
> More recently pre-compiled binary packages which suit generic hardware and
> software configurations are also made available for those who want to get
> something up and running quickly. This makes Gentoo similar to other
> binary
> distributions.
>
> The command syntax in the instructions included "--getbinpkg" to download
> pre-
> built binaries, but with this note:
>
> "In case you are already familiar with binary packages, you should be
> able to add '--getbinpkg' to the emerge calls to speed things up.
> The use of binary packages is completely optional though, and also not
> as much tested as the source-based upgrade path yet."
>
> Therefore, you can fetch binaries from the mirrors when these have the
> same
> configuration as your locally compiled software to make the whole upgrade
> complete faster, but it remains a personal choice.



Thanks Michael for your response,
but how could i know if one package has the same configuration as my
locally compiled software and if this one is as much tested as the
source-based package ?

--
Jacques Montier

On Monday, 25 March 2024 17:37:40 GMT Jacques Montier wrote:
> Le lun. 25 mars 2024 à 18:18, Michael <confabulate@kintzios.com> a écrit :

> > Therefore, you can fetch binaries from the mirrors when these have the
> > same
> > configuration as your locally compiled software to make the whole upgrade
> > complete faster, but it remains a personal choice.
>
> Thanks Michael for your response,
> but how could i know if one package has the same configuration as my
> locally compiled software and if this one is as much tested as the
> source-based package ?
>
> --
> Jacques Montier

When the packages on the Gentoo binhost mirror have been compiled with
different USE flags to your choices, these packages will not be fetched from
the mirror but compiled locally. Have a look here for more details:

https://wiki.gentoo.org/wiki/Gentoo_Binary_Host_Quickstart

Le lun. 25 mars 2024, 18:44, Michael <confabulate@kintzios.com> a écrit :

> On Monday, 25 March 2024 17:37:40 GMT Jacques Montier wrote:
> > Le lun. 25 mars 2024 à 18:18, Michael <confabulate@kintzios.com> a
> écrit :
>
> > > Therefore, you can fetch binaries from the mirrors when these have the
> > > same
> > > configuration as your locally compiled software to make the whole
> upgrade
> > > complete faster, but it remains a personal choice.
> >
> > Thanks Michael for your response,
> > but how could i know if one package has the same configuration as my
> > locally compiled software and if this one is as much tested as the
> > source-based package ?
> >
> > --
> > Jacques Montier
>
> When the packages on the Gentoo binhost mirror have been compiled with
> different USE flags to your choices, these packages will not be fetched
> from
> the mirror but compiled locally. Have a look here for more details:
>
> https://wiki.gentoo.org/wiki/Gentoo_Binary_Host_Quickstart
>
>
>
> Thanks a lot, Michael


Regards

--
Jacques

I have a question about binaries and the new profile: I have a number of almost identical architectures that I build binaries for and share across the similar sytems e.g. arm, aarch64, amd64 etc.

Is deleting the bin host storage (rm -rf <contents>) enough on the buildhost so I can share/use the binaries for the "emerge -e" on the other hosts? Or does it have to be a native emerge?
BillK

On Tuesday, 26 March 2024 10:32:05 GMT William KENWORTHY wrote:
> I have a question about binaries and the new profile: I have a number of
> almost identical architectures that I build binaries for and share across
> the similar sytems e.g. arm, aarch64, amd64 etc.
>
> Is deleting the bin host storage (rm -rf <contents>) enough on the buildhost
> so I can share/use the binaries for the "emerge -e" on the other hosts? Or
> does it have to be a native emerge? BillK

I'm about to try this out in the next couple of days. I will clean binpkgs on
both host and guest, transfer the freshly compile packages with the 23.0
profile to the guest and then emerge them there as binaries, but following the
profile migration guide, i.e. toolchain first followed by world. Should
things break I'll report back.

I'm AMD64 stable OpenRC. I got tired of dicking around resizing
partitions years ago, so I have all data and binaries in one honking
big partition. Also separate partitions for UEFI and swap. I assume
my system is already "merged-usr". Current profile...

[12] default/linux/amd64/17.1/no-multilib (exp) *

I just ran "emerge --sync" and got the profile news item. So do I
update world and then update profile? emerge -pv has 3 interesting
lines...

dev-libs/libaio-0.3.113-r1::gentoo [0.3.113::gentoo] USE="-static-libs -test (-split-usr%*)" 0 KiB

sys-apps/attr-2.5.2-r1::gentoo [2.5.1-r2::gentoo] USE="nls -debug -static-libs (-split-usr%*)" 327 KiB

sys-apps/coreutils-9.4-r1::gentoo [9.4::gentoo] USE="nls openssl (split-usr) xattr -acl -caps -gmp -hostname -kill -multicall (-selinux) -static -test -vanilla -verify-sig" 0 KiB

coreutils forces "split-usr" on, while the other 2 force it off. Any
booby-traps to watch out for before proceeding?

--
Roses are red
Roses are blue
Depending on their velocity
Relative to you

On Tue, Mar 26, 2024 at 11:21:32AM -0400, Walter Dnes wrote
> I'm AMD64 stable OpenRC. I got tired of dicking around resizing
> partitions years ago, so I have all data and binaries in one honking
> big partition. Also separate partitions for UEFI and swap. I assume
> my system is already "merged-usr". Current profile...
>
> [12] default/linux/amd64/17.1/no-multilib (exp) *
>
> I just ran "emerge --sync" and got the profile news item. So do I
> update world and then update profile? emerge -pv has 3 interesting
> lines...
>
> dev-libs/libaio-0.3.113-r1::gentoo [0.3.113::gentoo] USE="-static-libs -test (-split-usr%*)" 0 KiB
>
> sys-apps/attr-2.5.2-r1::gentoo [2.5.1-r2::gentoo] USE="nls -debug -static-libs (-split-usr%*)" 327 KiB
>
> sys-apps/coreutils-9.4-r1::gentoo [9.4::gentoo] USE="nls openssl (split-usr) xattr -acl -caps -gmp -hostname -kill -multicall (-selinux) -static -test -vanilla -verify-sig" 0 KiB
>
> coreutils forces "split-usr" on, while the other 2 force it off. Any
> booby-traps to watch out for before proceeding?

Oops, also add...

net-firewall/iptables-1.8.10:0/1.8.3::gentoo [1.8.9:0/1.8.3::gentoo] USE="(split-usr) -conntrack -netlink -nftables -pcap -static-libs -test%" 627 KiB


--
Roses are red
Roses are blue
Depending on their velocity
Relative to you

On Tuesday, 26 March 2024 15:21:32 GMT Walter Dnes wrote:

> I'm AMD64 stable OpenRC. I got tired of dicking around resizing
> partitions years ago, so I have all data and binaries in one honking
> big partition. Also separate partitions for UEFI and swap. I assume
> my system is already "merged-usr". Current profile...

Perhaps, perhaps not. I fell for that one too. 'merged-usr' refers to moving
/bin, /sbin and maybe others under /usr and replacing their top-level
directories with symlinks to their new positions.

Once merged, never to be unmerged again, without lots of preparation and hoop-
jumping.

--
Regards,
Peter.

On 2024-03-26, Walter Dnes <waltdnes@waltdnes.org> wrote:
> I'm AMD64 stable OpenRC. I got tired of dicking around resizing
> partitions years ago, so I have all data and binaries in one honking
> big partition. Also separate partitions for UEFI and swap. I assume
> my system is already "merged-usr". Current profile...
>
> [12] default/linux/amd64/17.1/no-multilib (exp) *

No, it is not merged user. If it were, the profile would say above
would say "/merged-usr" at the end.

> I just ran "emerge --sync" and got the profile news item. So do I
> update world and then update profile? emerge -pv has 3 interesting
> lines...

Follow the instructions in the new item.

On Tuesday, 26 March 2024 15:21:32 GMT Walter Dnes wrote:
> I'm AMD64 stable OpenRC. I got tired of dicking around resizing
> partitions years ago, so I have all data and binaries in one honking
> big partition. Also separate partitions for UEFI and swap. I assume
> my system is already "merged-usr". Current profile...
>
> [12] default/linux/amd64/17.1/no-multilib (exp) *
>
> I just ran "emerge --sync" and got the profile news item. So do I
> update world and then update profile?

No!

Please check the migration instructions for profile 23 as provided in the news
item. You must follow the steps suggested in the order they are written *and*
you must select the correct profile. The profile you show above is split-usr,
which was the default. This is the traditional split-usr linux fs which has /
bin, /sbin, /lib and /lib64 as discrete directories under /, e.g.:

~ # tree -L 1 /
/
??? bin
??? boot
??? dev
??? etc
??? home
??? lib
??? lib64
??? lost+found
??? media
??? mnt
??? opt
??? proc
??? root
??? run
??? sbin
??? sys
??? tmp
??? usr
??? var

20 directories, 0 files


The merged-usr fs structure has the aforementioned directories set as symlinks
under /usr, e.g.:

~ # tree -L 1 /
/
??? bin -> usr/bin
??? boot
??? dev
??? etc
??? home
??? lib -> usr/lib
??? lib64 -> usr/lib64
??? media
??? mnt
??? opt
??? proc
??? root
??? run
??? sbin -> usr/bin
??? sys
??? tmp
??? usr
??? var
??? BackUps

20 directories, 0 files


Consequently, in following the migration instructions methodically and
assuming you have a split-usr fs layout, you will need to change profile to:

[49] default/linux/amd64/23.0/split-usr/no-multilib (stable)

rebuild your toolchain in the order and in the way suggested in the news item,
then emerge @world with '--emptytree'.

If you want to convert the fs structure to a merged-usr layout after the
migration to your new profile follow the instructions here:

https://wiki.gentoo.org/wiki/Merge-usr

Assuming the --dryrun does not come up with any problems you then have to run
emerge -uaNDv world, which will spit out which packages are affected by it -
e.g. on one of my systems I see these candidates:

Dependency resolution took 35.09 s (backtrack: 0/20).

[ebuild R ] sys-apps/baselayout-2.14-r2::gentoo USE="-build (-split-
usr*)" 0 KiB
[ebuild R ] dev-libs/lzo-2.10:2::gentoo USE="-examples (-split-usr*) -
static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild R ] app-alternatives/bzip2-1::gentoo USE="reference -lbzip2 -
pbzip2 (-split-usr*)" 0 KiB
[ebuild R ] app-alternatives/tar-0::gentoo USE="gnu -libarchive (-split-
usr*)" 0 KiB
[ebuild R ] app-alternatives/gzip-1::gentoo USE="reference -pigz (-
split-usr*)" 0 KiB
[ebuild R ] app-alternatives/cpio-0::gentoo USE="gnu -libarchive (-
split-usr*)" 0 KiB
[ebuild R ] app-alternatives/awk-4::gentoo USE="gawk -busybox -mawk -
nawk (-split-usr*)" 0 KiB
[ebuild R ] sys-apps/coreutils-9.4-r1::gentoo USE="acl nls openssl xattr
-caps -gmp -hostname -kill -multicall (-selinux) (-split-usr*) -static -test -
vanilla -verify-sig" 0 KiB
[ebuild R ] sys-libs/libxcrypt-4.4.36:0/1::gentoo USE="(compat) (system)
-headers-only (-split-usr*) -static-libs -test" ABI_X86="32 (64) (-x32)" 0 KiB
[ebuild R ] sys-apps/systemd-utils-254.8::gentoo USE="acl kmod tmpfiles
udev -boot -kernel-install -secureboot (-selinux) (-split-usr*) -sysusers -
test -ukify" ABI_X86="(64) -32 (-x32)" PYTHON_SINGLE_TARGET="python3_11 -
python3_10 -python3_12" 0 KiB
[ebuild R ] sys-libs/ncurses-6.4_p20230401:0/6::gentoo USE="cxx gpm
stack-realign (tinfo) -ada -debug -doc -minimal -profile (-split-usr*) -
static-libs -test -trace -verify-sig" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild R ] dev-libs/libusb-1.0.26:1::gentoo USE="udev -debug -doc -
examples (-split-usr*) -static-libs -test" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild R ] sys-process/procps-3.3.17-r2:0/8::gentoo USE="elogind kill
ncurses nls (unicode) -modern-top (-selinux) (-split-usr*) -static-libs -
systemd -test" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild R ] sys-apps/shadow-4.14.2:0/4::gentoo USE="acl nls pam xattr -
audit -cracklib (-selinux) -skey (-split-usr*) -su -systemd -verify-sig" 0 KiB
[ebuild R ] net-firewall/iptables-1.8.10:0/1.8.3::gentoo USE="-conntrack
-netlink -nftables -pcap (-split-usr*) -static-libs -test" 0 KiB
[ebuild R ] net-mail/mailutils-3.15::gentoo USE="clients gdbm ipv6 nls
pam ssl threads -berkdb -bidi -emacs -guile -kerberos -kyotocabinet -ldap -
mysql -postgres -python -sasl -servers (-split-usr*) -static-libs -tcpd -
tokyocabinet" PYTHON_SINGLE_TARGET="python3_11 -python3_10" 0 KiB

Total: 16 packages (16 reinstalls), Size of downloads: 0 KiB

HTH.

Walter Dnes wrote:
> I just ran "emerge --sync" and got the profile news item. So do I
> update world and then update profile? emerge -pv has 3 interesting
> lines...
>



On this point, you need to update world first and then change profiles. 
I tried to change profiles first and then do the updates and it caused
problems.  It might work, it might not.  I can say it will work if you
do the updates first and then change profiles.  The news item even says
to do the updates first and run --depclean.  I forgot to run --depclean
but I'm not sure if that caused a package to fail or not.  I have one
package that refuses to rebuild.  I'll likely post it to another thread
since it may not actually be related to the profile change.  After all,
sometimes packages do fail. 

So, update first then change profiles. 

Dale

:-)  :-) 

On Tue, Mar 26, 2024 at 04:21:23PM +0000, Michael wrote
> On Tuesday, 26 March 2024 15:21:32 GMT Walter Dnes wrote:
> > I assume my system is already "merged-usr". Current profile...
> >
> > [12] default/linux/amd64/17.1/no-multilib (exp) *
> >
> > I just ran "emerge --sync" and got the profile news item. So do I
> > update world and then update profile?
>
> No!

Good thing I asked.

> Please check the migration instructions for profile 23 as provided in
> the news item. You must follow the steps suggested in the order they
> are written *and* you must select the correct profile. The profile
> you show above is split-usr, which was the default.

Thanks for the clarification. So my system is considered "split-usr",
regardless of everything being on one partition. I got the news item
when I ran "emerge --sync". My understanding is that step 1 in the news
item says "Please also update your system fully and depclean before
proceeding" so I should update world first. Since I'm currently on profile
"default/linux/amd64/17.1/no-multilib" then I should migrate to profile
"default/linux/amd64/23.0/split-usr/no-multilib" as per the news item.
Migrating from there to "default/linux/amd64/23.0/no-multilib" is a
separate process as per the Gentoo wiki. Is my understanding correct?

--
Roses are red
Roses are blue
Depending on their velocity
Relative to you

On 2024-03-26, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Tue, Mar 26, 2024 at 04:21:23PM +0000, Michael wrote
>> On Tuesday, 26 March 2024 15:21:32 GMT Walter Dnes wrote:
>> > I assume my system is already "merged-usr". Current profile...
>> >
>> > [12] default/linux/amd64/17.1/no-multilib (exp) *
>> >

[...]

>
> Thanks for the clarification. So my system is considered
> "split-usr", regardless of everything being on one partition.

Yes. "split user" means that /bin and /usr/bin are two different
directories. Likewise for /lib and /usr/lib, and so on...

It doesn't matter that /foo and /usr/foo directories are in the same
filesystem.

> I got the news item when I ran "emerge --sync". My understanding is
> that step 1 in the news item says "Please also update your system
> fully and depclean before proceeding" so I should update world
> first.

Yes. And depclean.

> Since I'm currently on profile
> "default/linux/amd64/17.1/no-multilib" then I should migrate to
> profile "default/linux/amd64/23.0/split-usr/no-multilib" as per the
> news item.

Yes -- If you're using OpenRC. I assume you are not using systemd
since your old profile wasn't a systemd profile [.In theory you could
be running systemd on a non-systemd profile, but it's not common.] If
you are running systemd, you should first update to the "merged-usr"
flavor of your current profile.

There's a detailed table at

https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_table

It shows exactly what new profile corresponds to what old profile.

> Migrating from there to "default/linux/amd64/23.0/no-multilib" is a
> separate process as per the Gentoo wiki. Is my understanding
> correct?

Yes: https://wiki.gentoo.org/wiki/Merge-usr

On Tuesday, 26 March 2024 13:01:16 GMT Michael wrote:
> On Tuesday, 26 March 2024 10:32:05 GMT William KENWORTHY wrote:
> > I have a question about binaries and the new profile: I have a number of
> > almost identical architectures that I build binaries for and share across
> > the similar sytems e.g. arm, aarch64, amd64 etc.
> >
> > Is deleting the bin host storage (rm -rf <contents>) enough on the
> > buildhost so I can share/use the binaries for the "emerge -e" on the
> > other hosts? Or does it have to be a native emerge? BillK
>
> I'm about to try this out in the next couple of days. I will clean binpkgs
> on both host and guest, transfer the freshly compile packages with the 23.0
> profile to the guest and then emerge them there as binaries, but following
> the profile migration guide, i.e. toolchain first followed by world.
> Should things break I'll report back.

All went according to plan.

Cleared out all files in binpks on both build-host and the guest. Carried out
the steps for the migration to profile 23.0 on the host, transferred binaries
to the guest, migrated guest to profile 23.0 using binaries. Then merged /usr
on both. All is good following this upgrade, but as always YMMV.

Thanks for the help. I've migrated my 3 operating Gentoo machines;
main desktop, backup desktop, and an old used Lenovo Thinkpad X201. The
poor thing was thrashing away for over 18 hours with 657 packages on the
emerge --emptytree!!! And that's after using a homebrew bash script to
select the max available speed on the CPU. "time" output...

> real 1086m47.440s
> user 1732m29.120s
> sys 146m54.026s

> > I got the news item when I ran "emerge --sync". My understanding is
> > that step 1 in the news item says "Please also update your system
> > fully and depclean before proceeding" so I should update world
> > first.
>
> Yes. And depclean.

I ended up unmerging specific items manually. Depclean is "rather
agressive", and wants to remove all but the latest kernel, *EVEN A
KERNEL THAT I'M CURRENTLY USING*. I'm currently on 6.1.67...

[x8940][waltdnes][~] eselect kernel list
Available kernel symlink targets:
[1] linux-6.1.57-gentoo
[2] linux-6.1.67-gentoo *
[3] linux-6.6.13-gentoo
[4] linux-6.6.21-gentoo

I ran into the Intel integrated graphics problem described in...
https://discussion.fedoraproject.org/t/f39-kernel-6-6-x-no-video-on-intel-integrated-graphics/98360

His solution...

> I was filling out the details for a bug report. Under the description,
> it asked if I have tried rawhide. I installed 6.7.0-0.rc4.35.fc40
> and it fixed the issue!

This appears to be a bug in the 6.6.x kernels, which is fixed in
6.7.x. My 2 desktops and the Thinkpad all have integrated Intel
graphics, so I'll sit at 6.1.67 until 6.7.x, or higher, goes stable.
/var/db/repos/gentoo/sys-kernel/gentoo-kernel/gentoo-kernel-6.7.10.ebuild
is already present, but is keyworded "~amd64".

--
Roses are red
Roses are blue
Depending on their velocity
Relative to you

On Saturday, 30 March 2024 19:34:42 CEST Walter Dnes wrote:
> Thanks for the help. I've migrated my 3 operating Gentoo machines;
> main desktop, backup desktop, and an old used Lenovo Thinkpad X201. The
> poor thing was thrashing away for over 18 hours with 657 packages on the
> emerge --emptytree!!! And that's after using a homebrew bash script to
> select the max available speed on the CPU. "time" output...

What does that script do?

> > real 1086m47.440s
> > user 1732m29.120s
> > sys 146m54.026s
> >
> > > I got the news item when I ran "emerge --sync". My understanding is
> > > that step 1 in the news item says "Please also update your system
> > > fully and depclean before proceeding" so I should update world
> > > first.
> >
> > Yes. And depclean.
>
> I ended up unmerging specific items manually. Depclean is "rather
> agressive", and wants to remove all but the latest kernel, *EVEN A
> KERNEL THAT I'M CURRENTLY USING*. I'm currently on 6.1.67...

Unless you plan on recompiling that kernel, there is no need to actually KEEP
the sources.

> [x8940][waltdnes][~] eselect kernel list
> Available kernel symlink targets:
> [1] linux-6.1.57-gentoo
> [2] linux-6.1.67-gentoo *
> [3] linux-6.6.13-gentoo
> [4] linux-6.6.21-gentoo
>
> I ran into the Intel integrated graphics problem described in...
> https://discussion.fedoraproject.org/t/f39-kernel-6-6-x-no-video-on-intel-in
> tegrated-graphics/98360
>
> His solution...
>
> > I was filling out the details for a bug report. Under the description,
> > it asked if I have tried rawhide. I installed 6.7.0-0.rc4.35.fc40
> > and it fixed the issue!
>
> This appears to be a bug in the 6.6.x kernels, which is fixed in
> 6.7.x. My 2 desktops and the Thinkpad all have integrated Intel
> graphics, so I'll sit at 6.1.67 until 6.7.x, or higher, goes stable.
> /var/db/repos/gentoo/sys-kernel/gentoo-kernel/gentoo-kernel-6.7.10.ebuild
> is already present, but is keyworded "~amd64".