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.