Re: [gentoo-user] Re: KDE6 and Pipewire control change

[Dale]

Dale wrote:
> Dale wrote:
>> Mark Knecht wrote:
>>>
>>>
>>> On Wed, Jul 3, 2024 at 6:33 AM Dale >> > wrote:
>>> 
>>> > Actually, it does.  Thing is, it doesn't show the HDMI as a option in
>>> > the list.  I bet the reason it doesn't show up under applications like
>>> > it did before is because it only sees the main speakers as a
>>> option.  No
>>> > need showing options when there is none.  So, I need to figure out how
>>> > to make it see HDMI as a option as well as main speakers.  Then
>>> maybe it
>>> > will show up under applications again.  I'd be back in business then.
>>> >
>>> > Something to work on when I get back from town.  Today is shot day.
>>> > :/   And grocery shopping.  Gotta eat.
>>>
>>> Audio over HDMI is not a requirement of the HDMI spec, it's an
>>> option.
>>>
>>> You might want to look at the specs for your card to see if NVidia 
>>> included it in the chipset. Graphics adapters intended for use in
>>> Bloomberg Stations might not include it.
>>>
>>> Typically
>>>
>>> lspci | grep Audio
>>>
>>> should tell you something.
>>>
>>> Good luck,
>>> Mark
>>
>>
>> Well, until the recent KDE upgrade, it worked.  I just had a easy way
>> to do it.  So I know the hardware is capable of it.  I just need to
>> figure out the software issue.  Since it doesn't see it now, I need
>> to figure out why it isn't being seen and fix it.  I may just need to
>> configure something.  Having it done in pipewire tho sure was handy. 
>> I hope that feature isn't gone for some reason.  As it is, I have to
>> manually tell Smplayer to send the audio to the HDMI port in
>> Preferences.  It works but I have to disable that to have sound on my
>> main speakers.  Thing is, on rare occasion I want to play a video on
>> the TV with mpv.  Doing it with pipewire made even it easy to
>> switch.  I just click on it, select for it to go to HDMI, done.  The
>> next time I play something with mpv, it goes back to the default. 
>> Really nifty. 
>>
>> Given the recent upgrade, I may just try logging out and back in. 
>> Maybe it just didn't pick it up last time.  It's not likely but
>> possible.  One can hope.  :-D
>>
>> Neighbor is sick.  Gotta go mow about 4 acres of grass.  Poor thing. 
>> He has issues.  :/  It's already 90F. 
>>
>> Dale
>>
>> :-)  :-) 
>
>
> Someone wrote me off list.  They not subscribed but read my post
> somehow.  Anyway, they recommended installing pavucontrol-qt and using
> the Pro Audio setting.  That package was already installed.  I'd never
> used Pro Audio before, didn't know what it was so didn't know it was a
> usable option.  However, when I selected it, all my options came
> back.  I got my three little horizontal lines back.  One of the
> options is HDMI again. 
>
> So, that's working again.  I hope this might help someone else who
> runs into this problem.  I won't be surprised tho if the original
> option comes back after I log out and back in again.  Weirder things
> have happened.  ;-)
>
> Thanks to all. 
>
> Dale
>
> :-)  :-) 


Oh, forgot to mention, I enabled that option in KDE System Settings
under Sound.  For me, it was at the top.  Could vary tho. 

Also, the monitor I bought dropped in price.  I ordered a second one. 
Should be here before to long.  My current 27" monitor will become the
monitor that moves from whatever system I need to use.  I plan to check
the power supply again in the LG but may retire it, just use it on that
rare occasion I need something simple but don't rely on it. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: KDE6 and Pipewire control change

[Dale]

Dale wrote:
> Mark Knecht wrote:
>>
>>
>> On Wed, Jul 3, 2024 at 6:33 AM Dale > > wrote:
>> 
>> > Actually, it does.  Thing is, it doesn't show the HDMI as a option in
>> > the list.  I bet the reason it doesn't show up under applications like
>> > it did before is because it only sees the main speakers as a
>> option.  No
>> > need showing options when there is none.  So, I need to figure out how
>> > to make it see HDMI as a option as well as main speakers.  Then
>> maybe it
>> > will show up under applications again.  I'd be back in business then.
>> >
>> > Something to work on when I get back from town.  Today is shot day.
>> > :/   And grocery shopping.  Gotta eat.
>>
>> Audio over HDMI is not a requirement of the HDMI spec, it's an
>> option.
>>
>> You might want to look at the specs for your card to see if NVidia 
>> included it in the chipset. Graphics adapters intended for use in
>> Bloomberg Stations might not include it.
>>
>> Typically
>>
>> lspci | grep Audio
>>
>> should tell you something.
>>
>> Good luck,
>> Mark
>
>
> Well, until the recent KDE upgrade, it worked.  I just had a easy way
> to do it.  So I know the hardware is capable of it.  I just need to
> figure out the software issue.  Since it doesn't see it now, I need to
> figure out why it isn't being seen and fix it.  I may just need to
> configure something.  Having it done in pipewire tho sure was handy. 
> I hope that feature isn't gone for some reason.  As it is, I have to
> manually tell Smplayer to send the audio to the HDMI port in
> Preferences.  It works but I have to disable that to have sound on my
> main speakers.  Thing is, on rare occasion I want to play a video on
> the TV with mpv.  Doing it with pipewire made even it easy to switch. 
> I just click on it, select for it to go to HDMI, done.  The next time
> I play something with mpv, it goes back to the default.  Really nifty. 
>
> Given the recent upgrade, I may just try logging out and back in. 
> Maybe it just didn't pick it up last time.  It's not likely but
> possible.  One can hope.  :-D
>
> Neighbor is sick.  Gotta go mow about 4 acres of grass.  Poor thing. 
> He has issues.  :/  It's already 90F. 
>
> Dale
>
> :-)  :-) 


Someone wrote me off list.  They not subscribed but read my post
somehow.  Anyway, they recommended installing pavucontrol-qt and using
the Pro Audio setting.  That package was already installed.  I'd never
used Pro Audio before, didn't know what it was so didn't know it was a
usable option.  However, when I selected it, all my options came back. 
I got my three little horizontal lines back.  One of the options is HDMI
again. 

So, that's working again.  I hope this might help someone else who runs
into this problem.  I won't be surprised tho if the original option
comes back after I log out and back in again.  Weirder things have
happened.  ;-)

Thanks to all. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: KDE6 and Pipewire control change

[Dale]

Mark Knecht wrote:
>
>
> On Wed, Jul 3, 2024 at 6:33 AM Dale  > wrote:
> 
> > Actually, it does.  Thing is, it doesn't show the HDMI as a option in
> > the list.  I bet the reason it doesn't show up under applications like
> > it did before is because it only sees the main speakers as a option.  No
> > need showing options when there is none.  So, I need to figure out how
> > to make it see HDMI as a option as well as main speakers.  Then maybe it
> > will show up under applications again.  I'd be back in business then.
> >
> > Something to work on when I get back from town.  Today is shot day.
> > :/   And grocery shopping.  Gotta eat.
>
> Audio over HDMI is not a requirement of the HDMI spec, it's an
> option.
>
> You might want to look at the specs for your card to see if NVidia 
> included it in the chipset. Graphics adapters intended for use in
> Bloomberg Stations might not include it.
>
> Typically
>
> lspci | grep Audio
>
> should tell you something.
>
> Good luck,
> Mark


Well, until the recent KDE upgrade, it worked.  I just had a easy way to
do it.  So I know the hardware is capable of it.  I just need to figure
out the software issue.  Since it doesn't see it now, I need to figure
out why it isn't being seen and fix it.  I may just need to configure
something.  Having it done in pipewire tho sure was handy.  I hope that
feature isn't gone for some reason.  As it is, I have to manually tell
Smplayer to send the audio to the HDMI port in Preferences.  It works
but I have to disable that to have sound on my main speakers.  Thing is,
on rare occasion I want to play a video on the TV with mpv.  Doing it
with pipewire made even it easy to switch.  I just click on it, select
for it to go to HDMI, done.  The next time I play something with mpv, it
goes back to the default.  Really nifty. 

Given the recent upgrade, I may just try logging out and back in.  Maybe
it just didn't pick it up last time.  It's not likely but possible.  One
can hope.  :-D

Neighbor is sick.  Gotta go mow about 4 acres of grass.  Poor thing.  He
has issues.  :/  It's already 90F. 

Dale

:-)  :-) 

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

[Michael]

On Wednesday, 3 July 2024 10:22:33 BST Dale wrote:

> Another update.  I rebooted several times to make sure whether things
> would be consistent.  Most of the time, it came up as it should.  Some
> times, not so much.  When I had just the new Samsung monitor connected,
> it was consistent.  When I added the old LG, it would not always come up
> like it should.  The biggest thing, the plasma panel would be on the
> wrong monitor. 

If you are adding a second monitor then you need an additional "Monitor" 
section with a different identifier in your xorg.conf for a multi-headed 
setup.  You need to add in the first monitor section:

Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName  "Samsung LS32B30"
HorizSync   30.0 - 84.0
VertRefresh 50.0 - 75.0
Option "PreferredMode" "1920x1080_60.00"
Option "Primary" "true"
Option "DPMS" "true"
EndSection

and then in the second monitor section:

Section "Monitor"
Identifier "Monitor1"
VendorName "Unknown"
ModelName  "LG blah-blah"
Option "PreferredMode" "1920x1080_60.00"
Option "RightOf" "Monitor0"
Option "DPMS" "true"
EndSection

Section "Screen" 
Identifier "Screen0"
Device "Device0"
Monitor"Monitor0"
SubSection "Display"
Depth   24
Virtual 3840 1080 # 1920 + 1920 (3840), 1080 + 0 (1080)
EndSubSection
EndSection

You'll get the correct identifiers and "Modelines", "PreferredMode", 
resolution, refresh rate, etc. values for the above by using 'xrandr -q'.


> I tried using xrandr to set this but it kept changing what monitors was
> connected where which would throw off what monitor got what priority.

Manually instructing xranrd to set up your monitors will not survive between 
reboots unless you store its settings in your xorg.conf.  You need to rerun it 
each time, manually or via a script.  Or, you just set correctly your 
xorg.conf once and then you can forget about it.  ;-)


> Finally, I removed the old LG.  It has caused enough grief already.  I
> unhooked the TV cable for my bedroom TV and connected it to the new
> rig.  I then booted.  I installed a package called arandr.  It's a
> sister to xrandr but GUI based.  Makes it very easy to see what is
> what.  On the first boot, the Samsung showed as connected to port 1. 
> The TV showed as port 3 I think.  It seems each port can do two displays
> so it kinda skips.  The first port is actually 0.  Anyway, I used arandr
> to set it up like I wanted.  I saved the file with the command in my
> home directory.  I then moved the command to a file in
> /etc/X11/xinit/xinitrc.d/ as a file.  They are usually started with a
> number in the file name.  Don't forget to add the bash bit on the first
> line if needed and make it executable as well.  Once I did that, the
> displays worked like they should.  So far at least.
> 
> The lesson to be learned is this.  When you have a monitor that is
> having issues and keeps showing as connected to different ports and
> such, you can't use that display to get a reliable configuration that
> will survive a reboot, maybe even a power off and back on.  Another
> thing, using either xrandr or arandr is a nifty feature if set up
> correctly.  Those two make it so a display, or set of displays more
> importantly, work like you want.  The arnadr command since it is a GUI,
> makes it a lot easier to create the xrandr command with the right
> options.  If you use that route tho, make sure all monitors are
> connected and on before starting.  You may can do it without it with
> xrandr but arandr needs the monitor to be on and working.  The other
> thing, putting the setting in /etc/X11/xinit/xinitrc.d/ seems to work
> pretty well.  So far at least. 
> 
> To be honest tho, I wish Nvidia would generate a conf file that contains
> both monitors and I could set it up properly there.  Then when I boot
> up, it reads that file and knows what monitor is what long before DM
> and/or sddm even starts.  It could also keep a monitor powered on even
> while on a console with nothing GUI running.  I kinda wish we could do
> it like we did back in the old days. 
> 
> I also had another thought. When changing the xorg.conf file, I wonder
> if it only reads that file when loading the nvidia drivers but not when
> DM is started/restarted.  I noticed on my system, when I booted but have
> not started DM, the Nvidia drivers were already loaded.  I'm not sure
> when the xorg.conf file is loaded but if it is loaded when the drivers
> load, then that could explain why some changes didn't make any changes
> to the display.  The changes were not seen unless I rebooted which I
> didn't always do.  Maybe someone here knows what order this happens in. 
> It could explain a lot tho. 

I think if you change parameters in the "Device" section for the graphics 
driver in your xorg.conf, you need to 

Re: [gentoo-user] Re: KDE6 and Pipewire control change

[Mark Knecht]

On Wed, Jul 3, 2024 at 6:33 AM Dale  wrote:

> Actually, it does.  Thing is, it doesn't show the HDMI as a option in
> the list.  I bet the reason it doesn't show up under applications like
> it did before is because it only sees the main speakers as a option.  No
> need showing options when there is none.  So, I need to figure out how
> to make it see HDMI as a option as well as main speakers.  Then maybe it
> will show up under applications again.  I'd be back in business then.
>
> Something to work on when I get back from town.  Today is shot day.
> :/   And grocery shopping.  Gotta eat.

Audio over HDMI is not a requirement of the HDMI spec, it's an
option.

You might want to look at the specs for your card to see if NVidia
included it in the chipset. Graphics adapters intended for use in
Bloomberg Stations might not include it.

Typically

lspci | grep Audio

should tell you something.

Good luck,
Mark

Re: [gentoo-user] world upgrade a mess, need some advise

[Dale]

Michael wrote:
> On Wednesday, 3 July 2024 01:34:12 BST Dale wrote:
>>
>> All I've ever seen is --depclean and preserved rebuild.  I don't recall
>> ever seeing anything else.  If a package fails, then it tacks the log
>> file on the end, sometimes of multiple packages.  To be honest tho, if
>> it fails, most of the time that isn't useful either.  Usually the actual
>> error is way up somewhere.  I've never seen anything about perl, python
>> or that sort of thing before. 
>>
>> It could be that my emerge options are good enough that it doesn't
>> trigger any of those.  When I had to run perl cleaner a while back tho,
>> I wish emerge had gave me a hint that it needed to be run if it couldn't
>> fix it itself.  Then again, it may not have known about it either. 
>>
>> I plan to run it and if it does nothing, at least then I know my system
>> is set up correctly. It's better than not doing it and having weird
>> problems that are hard to figure out the cause of. 
>>
>> Dale
>>
>> :-)  :-) 
> When perl itself is updated emerge let's you know to run perl-cleaner with a 
> message at the end.


Well, it missed it that time I had issues then.  o_O 

Dale

:-)  :-) 

Re: [gentoo-user] Re: KDE6 and Pipewire control change

[Dale]

Nikos Chantziaras wrote:
> On 02/07/2024 15:46, Dale wrote:
>> I can't find the controls I used to have with the new
>> pipewire.
> Does it show up in the "Devices" tab?
>
>
>


Actually, it does.  Thing is, it doesn't show the HDMI as a option in
the list.  I bet the reason it doesn't show up under applications like
it did before is because it only sees the main speakers as a option.  No
need showing options when there is none.  So, I need to figure out how
to make it see HDMI as a option as well as main speakers.  Then maybe it
will show up under applications again.  I'd be back in business then. 

Something to work on when I get back from town.  Today is shot day. 
:/   And grocery shopping.  Gotta eat. 

Dale

:-)  :-) 

[gentoo-user] Re: KDE6 and Pipewire control change

[Nikos Chantziaras]

On 02/07/2024 15:46, Dale wrote:

I can't find the controls I used to have with the new
pipewire.

Does it show up in the "Devices" tab?

Re: [gentoo-user] world upgrade a mess, need some advise

[Michael]

On Wednesday, 3 July 2024 01:34:12 BST Dale wrote:
> Eli Schwartz wrote:
> > On 7/2/24 7:33 PM, Dale wrote:
> >> What I wish, emerge would spit the information out after it completes
> >> instead of putting fairly important info in some log files somewhere for
> >> a person to go dig and find.  It already tells us we should run
> >> --depclean.  Why can't it tell us when we need to run some python tool,
> >> perl or anything else as well that has been triggered.  I've never seen
> >> emerge tell me to run anything but --depclean or preserved rebuild and
> >> to be honest, if a package isn't used, it likely doesn't hurt anything
> >> that it is still installed.  It's just cruft left behind.  Having a
> >> broken python, perl or some other important package should give us a
> >> notice at the end.  That to me would be more important than running
> >> -depclean.  Running preserved rebuild is important tho.
> >> 
> >> One thing about it, if it doesn't need to fix anything, I guess it does
> >> nothing.  Might upset a few electrons while checking is all.  ;-)
> > 
> > ... but it already does exactly this?
> > 
> > When a package emits a warning in the middle of 50 other packages being
> > compiled and installed... portage collects warnings and repeats them at
> > the end for you.
> > 
> > It doesn't matter because the package manager already rebuilds pretty
> > much all perl modules. Running perl-cleaner is advised "in case portage
> > missed something" which probably means "it wasn't part of @world".
> 
> All I've ever seen is --depclean and preserved rebuild.  I don't recall
> ever seeing anything else.  If a package fails, then it tacks the log
> file on the end, sometimes of multiple packages.  To be honest tho, if
> it fails, most of the time that isn't useful either.  Usually the actual
> error is way up somewhere.  I've never seen anything about perl, python
> or that sort of thing before. 
> 
> It could be that my emerge options are good enough that it doesn't
> trigger any of those.  When I had to run perl cleaner a while back tho,
> I wish emerge had gave me a hint that it needed to be run if it couldn't
> fix it itself.  Then again, it may not have known about it either. 
> 
> I plan to run it and if it does nothing, at least then I know my system
> is set up correctly. It's better than not doing it and having weird
> problems that are hard to figure out the cause of. 
> 
> Dale
> 
> :-)  :-) 

When perl itself is updated emerge let's you know to run perl-cleaner with a 
message at the end.

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

[Dale]

Dale wrote:
> Micheal and I had a email or two off list.  This is what I think the
> problem was.  Nvidia and KDE was clashing with each other.  I ended up
> connecting both the new monitor and old LG that gave me so much
> trouble.  I think Nvidia wanted to set the first port as primary but KDE
> wanted to set the 2nd port because I had that monitor connected before
> and it remembered it or something.  I set Nvidia GUI settings to what I
> wanted but it was still making everything HUGE.  I found the settings
> for KDE and actually reversed it.  One reason I wanted to reverse it,
> the plasma panel on the bottom was also on the wrong monitor.  It was on
> port 2, the old LG monitor, and I wanted it on port 1, the new Samsung
> monitor.  That's how I want it when I switch rigs as well.  Anyway, when
> I set it in KDE backwards, the mouse and such got a little weird.  I had
> to figure out how to get from one screen to another.  You may want to do
> that before changing settings.  Once I set it up backwards, I hit
> apply.  I think it had a confirm box for this which is why you need to
> know how to get the mouse pointer from one display to the other.  After
> I did that, I checked Nvidia and it still had the same settings for
> where displays were.  I then went back to the KDE settings and set them
> correctly.  I set Samsung as primary, new monitor, and LG as Right of
> Samsung.  I hit apply.  The screens blinked, plasma moved to the Samsung
> monitor and that HUGE problem went away.  Things are larger but just
> because it is a larger monitor.  Basically, it is as it should be. 
> Oddly, the old LG monitor works pretty well now too.  ROFL
>
> If I had the new monitor and used it from the beginning, it might have
> just worked.  I think KDE remembered it and insisted on making it
> primary instead of what I was telling Nvidia.  Setting it backwards and
> then setting it the correct way forced KDE to rethink the settings. 
> This may be a rare problem to run into but if someone reading this ever
> recycles a system and connects things differently, this may help. 
> Forcing KDE to do something backwards and then setting it to the correct
> way just may force KDE to forget previous info and work like you want it
> too. 
>
> I'm still trying to decide if I want to keep using the splitter or not. 
> I could bypass the splitter and connect directly to a video card port. 
> I'm just not sure why I should rework my cabling tho. 
>
> Thanks to all for the help, Micheal and Mark for sure.  I hope this info
> will help someone else tho.  When one of us beats something into
> submission, we can all learn from it.  It's why I read almost every post
> on this list.  It just might come in handy one day, if I remember what I
> read.  LOL 
>
> Dale
>
> :-)  :-) 
>

Another update.  I rebooted several times to make sure whether things
would be consistent.  Most of the time, it came up as it should.  Some
times, not so much.  When I had just the new Samsung monitor connected,
it was consistent.  When I added the old LG, it would not always come up
like it should.  The biggest thing, the plasma panel would be on the
wrong monitor. 

I tried using xrandr to set this but it kept changing what monitors was
connected where which would throw off what monitor got what priority. 
Finally, I removed the old LG.  It has caused enough grief already.  I
unhooked the TV cable for my bedroom TV and connected it to the new
rig.  I then booted.  I installed a package called arandr.  It's a
sister to xrandr but GUI based.  Makes it very easy to see what is
what.  On the first boot, the Samsung showed as connected to port 1. 
The TV showed as port 3 I think.  It seems each port can do two displays
so it kinda skips.  The first port is actually 0.  Anyway, I used arandr
to set it up like I wanted.  I saved the file with the command in my
home directory.  I then moved the command to a file in
/etc/X11/xinit/xinitrc.d/ as a file.  They are usually started with a
number in the file name.  Don't forget to add the bash bit on the first
line if needed and make it executable as well.  Once I did that, the
displays worked like they should.  So far at least.

The lesson to be learned is this.  When you have a monitor that is
having issues and keeps showing as connected to different ports and
such, you can't use that display to get a reliable configuration that
will survive a reboot, maybe even a power off and back on.  Another
thing, using either xrandr or arandr is a nifty feature if set up
correctly.  Those two make it so a display, or set of displays more
importantly, work like you want.  The arnadr command since it is a GUI,
makes it a lot easier to create the xrandr command with the right
options.  If you use that route tho, make sure all monitors are
connected and on before starting.  You may can do it without it with
xrandr but arandr needs the monitor to be on and working.  The other
thing, putting the setting in /etc/X11/xinit/xinitrc.d/ 

Re: [gentoo-user] world upgrade a mess, need some advise

[Dale]

Eli Schwartz wrote:
> On 7/2/24 7:33 PM, Dale wrote:
>> What I wish, emerge would spit the information out after it completes
>> instead of putting fairly important info in some log files somewhere for
>> a person to go dig and find.  It already tells us we should run
>> --depclean.  Why can't it tell us when we need to run some python tool,
>> perl or anything else as well that has been triggered.  I've never seen
>> emerge tell me to run anything but --depclean or preserved rebuild and
>> to be honest, if a package isn't used, it likely doesn't hurt anything
>> that it is still installed.  It's just cruft left behind.  Having a
>> broken python, perl or some other important package should give us a
>> notice at the end.  That to me would be more important than running
>> -depclean.  Running preserved rebuild is important tho.
>>
>> One thing about it, if it doesn't need to fix anything, I guess it does
>> nothing.  Might upset a few electrons while checking is all.  ;-)
>
> ... but it already does exactly this?
>
> When a package emits a warning in the middle of 50 other packages being
> compiled and installed... portage collects warnings and repeats them at
> the end for you.
>
> It doesn't matter because the package manager already rebuilds pretty
> much all perl modules. Running perl-cleaner is advised "in case portage
> missed something" which probably means "it wasn't part of @world".
>
>


All I've ever seen is --depclean and preserved rebuild.  I don't recall
ever seeing anything else.  If a package fails, then it tacks the log
file on the end, sometimes of multiple packages.  To be honest tho, if
it fails, most of the time that isn't useful either.  Usually the actual
error is way up somewhere.  I've never seen anything about perl, python
or that sort of thing before. 

It could be that my emerge options are good enough that it doesn't
trigger any of those.  When I had to run perl cleaner a while back tho,
I wish emerge had gave me a hint that it needed to be run if it couldn't
fix it itself.  Then again, it may not have known about it either. 

I plan to run it and if it does nothing, at least then I know my system
is set up correctly. It's better than not doing it and having weird
problems that are hard to figure out the cause of. 

Dale

:-)  :-) 

Re: [gentoo-user] world upgrade a mess, need some advise

[Eli Schwartz]

On 7/2/24 7:33 PM, Dale wrote:
> What I wish, emerge would spit the information out after it completes
> instead of putting fairly important info in some log files somewhere for
> a person to go dig and find.  It already tells us we should run
> --depclean.  Why can't it tell us when we need to run some python tool,
> perl or anything else as well that has been triggered.  I've never seen
> emerge tell me to run anything but --depclean or preserved rebuild and
> to be honest, if a package isn't used, it likely doesn't hurt anything
> that it is still installed.  It's just cruft left behind.  Having a
> broken python, perl or some other important package should give us a
> notice at the end.  That to me would be more important than running
> -depclean.  Running preserved rebuild is important tho.
> 
> One thing about it, if it doesn't need to fix anything, I guess it does
> nothing.  Might upset a few electrons while checking is all.  ;-)


... but it already does exactly this?

When a package emits a warning in the middle of 50 other packages being
compiled and installed... portage collects warnings and repeats them at
the end for you.

It doesn't matter because the package manager already rebuilds pretty
much all perl modules. Running perl-cleaner is advised "in case portage
missed something" which probably means "it wasn't part of @world".


-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] KDE6 and Pipewire control change

[Dale]

Mark Knecht wrote:
>
>
> On Tue, Jul 2, 2024 at 5:47 AM Dale  > wrote:
> 
> > Does anyone know where those controls went or if there is some new way
> > to control that that I've missed?  I really liked having those options.
> > It made things a lot easier.  USE flag info.
> 
>
> Everything I need is either in the speaker icon on the bottom rail or
> in System Settings-> Audio.
>
> I don't see anything missing from earlier versions of KDE audio, or if
> it is missing I never used it.
>
> Good luck with the new monitor
>
> Mark


It's missing here.  Right now, I can't play a video on my TV and it use
the TV speakers with mpv.  With the old pipewire, I just clicked the
speaker, clicked the applications tab and then find the correct instance
of mpv if I have more than one open.  Paused ones usually show a pause
button.  Once I find the right one, I just click the little horizontal
bars and select HDMI and the sound moves to my TV.  Thing is, it
defaults to my main speaker for mpv and others.  When I change it for a
one time thing, it resets when I start a app again.  It was quite handy
and made it very easy to switch with any app, even Firefox or something. 

Maybe it will come back with the next upgrade.  Or I'll find out where
it went if it got moved or something.  I sure miss it tho.

Rebooted a few times, still have the plasma panel thingy pop up on the
wrong monitor every once in a while but other than that, resolution and
stuff works.  I'll spend a few days beating it into submission until it
consistently comes up like it should each time.  It's working better now
at least. 

Dale

:-)  :-) 

Re: [gentoo-user] world upgrade a mess, need some advise

[Dale]

Arve Barsnes wrote:
> On Tue, 2 Jul 2024 at 18:49, Wols Lists  wrote:
>> On 02/07/2024 10:17, Arve Barsnes wrote:
>>> IMO, only bring out the hammer if you're having a problem.
>> And when you run emerge --update, does that sometimes find nothing to
>> upgrade? No reason why it *should* find something.
>>
>> There's a couple of commands like that that sometimes find nothing to do
>> - emerge --depclean is another.
>>
>> But if you set off all these "do something if there's something needing
>> doing" jobs, you'll always have a clean, up-to-date system.
>>
>> And yes it would be nice if there was a page somewhere in the handbook
>> or similar that said "this is how to keep your system up-to-date, just
>> run these commands every week or so".
> Sure, sometimes there are no updates, even on my unstable system it happens.
>
> And a world update tells you every time that you should run --depclean
> to make sure your system is consistent.
>
> And upgrading certain packages tells you to run other commands after
> updating to make sure your system is consistent. Including perl with
> perl-cleaner.
>
> If you do everything portage tells you to do, you'll have perl-cleaner
> mostly be a pointless waste of time, and if you never run it except
> when asked to, you might be forced to now and then to fix a problem.
> Your chosen solution to this 'dilemma' probably comes down to how
> confident you are when coming up to portage conflicts, no shame either
> way :)
>
> Cheers,
> Arve
>
>


What I wish, emerge would spit the information out after it completes
instead of putting fairly important info in some log files somewhere for
a person to go dig and find.  It already tells us we should run
--depclean.  Why can't it tell us when we need to run some python tool,
perl or anything else as well that has been triggered.  I've never seen
emerge tell me to run anything but --depclean or preserved rebuild and
to be honest, if a package isn't used, it likely doesn't hurt anything
that it is still installed.  It's just cruft left behind.  Having a
broken python, perl or some other important package should give us a
notice at the end.  That to me would be more important than running
-depclean.  Running preserved rebuild is important tho.

One thing about it, if it doesn't need to fix anything, I guess it does
nothing.  Might upset a few electrons while checking is all.  ;-)

Dale

:-)  :-) 

Re: [gentoo-user] world upgrade a mess, need some advise

[Arve Barsnes]

On Tue, 2 Jul 2024 at 18:49, Wols Lists  wrote:
>
> On 02/07/2024 10:17, Arve Barsnes wrote:
> > IMO, only bring out the hammer if you're having a problem.
>
> And when you run emerge --update, does that sometimes find nothing to
> upgrade? No reason why it *should* find something.
>
> There's a couple of commands like that that sometimes find nothing to do
> - emerge --depclean is another.
>
> But if you set off all these "do something if there's something needing
> doing" jobs, you'll always have a clean, up-to-date system.
>
> And yes it would be nice if there was a page somewhere in the handbook
> or similar that said "this is how to keep your system up-to-date, just
> run these commands every week or so".

Sure, sometimes there are no updates, even on my unstable system it happens.

And a world update tells you every time that you should run --depclean
to make sure your system is consistent.

And upgrading certain packages tells you to run other commands after
updating to make sure your system is consistent. Including perl with
perl-cleaner.

If you do everything portage tells you to do, you'll have perl-cleaner
mostly be a pointless waste of time, and if you never run it except
when asked to, you might be forced to now and then to fix a problem.
Your chosen solution to this 'dilemma' probably comes down to how
confident you are when coming up to portage conflicts, no shame either
way :)

Cheers,
Arve

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

[Dale]

Dale wrote:
>
> I tried it with those options and without.  Neither changed anything.  I
> originally tried it with no xorg.conf at all.  I was hoping maybe the
> Nvidia GUI thing would adjust things.  I may try that again.  No
> xorg.conf and use the GUI thing.  That's what I use to set up my TV and
> such anyway.  Thing is, the sddm screen is HUGE too.
>
> I just installed a older NVS 510 video card.  It behaves the same way. 
> I think that rules out a video card problem. 
>
> I checked the menus on the monitor and it doesn't seem to have the
> upscale feature.  I saw other options included in their screenshot tho. 
> Just not that one.  I did try other options tho.  They tend to change
> instantly.  Most of them only affected brightness and such.
>
> Given a different video card does the same way, it is either a driver
> issue or a wrong setting somewhere.  I don't see anything in any option
> about scaling or zooming in the monitor.  It is a fairly basic monitor. 
> I might add, after I bought it, the price dropped.  :/   Oh, while in
> KDE, I did go find the options for zoom and magnify and disabled all
> those.  I never use them anyway.  Still no change.
>
> Looks like we going to have to pull out a larger hammer.  Fix one
> problem, another pops up.  What is that game, whack a mole 
>
> I'm going to put the faster card back in so we can work on just one
> card.  Beat it into submission.  LOL
>
> Dale
>
> :-)  :-) 
>


Micheal and I had a email or two off list.  This is what I think the
problem was.  Nvidia and KDE was clashing with each other.  I ended up
connecting both the new monitor and old LG that gave me so much
trouble.  I think Nvidia wanted to set the first port as primary but KDE
wanted to set the 2nd port because I had that monitor connected before
and it remembered it or something.  I set Nvidia GUI settings to what I
wanted but it was still making everything HUGE.  I found the settings
for KDE and actually reversed it.  One reason I wanted to reverse it,
the plasma panel on the bottom was also on the wrong monitor.  It was on
port 2, the old LG monitor, and I wanted it on port 1, the new Samsung
monitor.  That's how I want it when I switch rigs as well.  Anyway, when
I set it in KDE backwards, the mouse and such got a little weird.  I had
to figure out how to get from one screen to another.  You may want to do
that before changing settings.  Once I set it up backwards, I hit
apply.  I think it had a confirm box for this which is why you need to
know how to get the mouse pointer from one display to the other.  After
I did that, I checked Nvidia and it still had the same settings for
where displays were.  I then went back to the KDE settings and set them
correctly.  I set Samsung as primary, new monitor, and LG as Right of
Samsung.  I hit apply.  The screens blinked, plasma moved to the Samsung
monitor and that HUGE problem went away.  Things are larger but just
because it is a larger monitor.  Basically, it is as it should be. 
Oddly, the old LG monitor works pretty well now too.  ROFL

If I had the new monitor and used it from the beginning, it might have
just worked.  I think KDE remembered it and insisted on making it
primary instead of what I was telling Nvidia.  Setting it backwards and
then setting it the correct way forced KDE to rethink the settings. 
This may be a rare problem to run into but if someone reading this ever
recycles a system and connects things differently, this may help. 
Forcing KDE to do something backwards and then setting it to the correct
way just may force KDE to forget previous info and work like you want it
too. 

I'm still trying to decide if I want to keep using the splitter or not. 
I could bypass the splitter and connect directly to a video card port. 
I'm just not sure why I should rework my cabling tho. 

Thanks to all for the help, Micheal and Mark for sure.  I hope this info
will help someone else tho.  When one of us beats something into
submission, we can all learn from it.  It's why I read almost every post
on this list.  It just might come in handy one day, if I remember what I
read.  LOL 

Dale

:-)  :-) 

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

[Mark Knecht]

On Tue, Jul 2, 2024 at 12:44 PM Dale  wrote:

> I tried it with those options and without.  Neither changed anything.  I
> originally tried it with no xorg.conf at all.  I was hoping maybe the
> Nvidia GUI thing would adjust things.  I may try that again.  No
> xorg.conf and use the GUI thing.  That's what I use to set up my TV and
> such anyway.  Thing is, the sddm screen is HUGE too.

> :-)  :-)

???

xdpyinfo | grep -B2 resolution

???

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

[Dale]

Michael wrote:
> On Tuesday, 2 July 2024 19:58:59 BST Dale wrote:
>> Howdy,
>>
>> New monitor came in.  Found it on my porch.  Unboxed it and hooked it
>> up.  Started with no xorg.conf file.  It's high res, plasma comes up so
>> all that is fine.  Now comes the problem.  Everything is HUGE.  Even on
>> SDDM screen, it's like it is zoomed in or something.  Icons are huge,
>> fonts are huge.  I think what it is doing is this, and it may be the
>> video card.  I think it is thinking I have four monitors set up as one
>> large screen.  With this one monitor, I'm seeing the top left monitor
>> but not seeing the rest since I only have one monitor connected.  I
>> might add, when I click to logout, that screen is huge too. 
>>
>> I generated a xorg.conf with the nvidia tool.  No change.  I tried
>> removing options that I thought might cause this largeness problem.  I
>> even rebooted.  No change.  I open the Nvidia GUI software and tried
>> adjusting things there.  No change.  I compared the setting to my main
>> rig, other than the difference in the cards, all settings appear to be
>> the same including what should be displayed where.  The resolution is
>> correct too.   
>>
>> Is it possible this card functions differently than my usual cards? 
>> Someone mentioned these tend to be used in a business system which could
>> mean they use four monitors for one large display, for presentations or
>> something.  Is there something I need to disable or enable so the card
>> knows I want independent monitors maybe?
>>
>> I'm attaching the xorg.conf file, including options I commented out.  I
>> also checked the logs, no errors or anything.  It's just the usual
>> things like mouse and keyboard loading and it finding the monitor
>> connected, unlike the old LG.  Maybe someone here as ran into this at
>> work or for a client and has a idea on how to fix or that this card is
>> not designed for my use. 
>>
>> While I'm waiting on a reply, I'm going to try one of my older spare
>> video cards.  If it works fine, it could be the new video card is set up
>> to work this way.  May not can even change it. 
>>
>> Thanks.
>>
>> Dale
>>
>> :-)  :-) 
> If it is this *this* monitor:
>
> https://www.samsung.com/us/computing/monitors/flat/32--s30b-fhd-75hz-amd-freesync-monitor-ls32b300nwnxgo/#specs
>
> you should be able to set:
>
> Section "Monitor"
> Identifier "Monitor0"
> VendorName "Unknown"
> ModelName  "Samsung LS32B30"
> HorizSync   30.0 - 84.0
> VertRefresh 50.0 - 75.0
> Option "PreferredMode" "1920x1080_75.00"
> Option "DPMS"
> EndSection
>
> for better responsiveness with less flicker when watching sports.
>
> Did you comment out all the #lines in the "Screen" section, rather than 
> letting nvidia set configure it as it needs to?
>
> Set the screen to the desired resolution to match the monitor, e.g.:
>
> Option "metamodes" "1920x1080 +0+0"
>
> and it should scale correctly.
>
> Also check if "Samsung Magic Upscale" has been enabled and this affects what 
> screen size is eventually displayed on the monitor:
>
> https://www.samsung.com/us/support/answer/ANS00086623/

I tried it with those options and without.  Neither changed anything.  I
originally tried it with no xorg.conf at all.  I was hoping maybe the
Nvidia GUI thing would adjust things.  I may try that again.  No
xorg.conf and use the GUI thing.  That's what I use to set up my TV and
such anyway.  Thing is, the sddm screen is HUGE too.

I just installed a older NVS 510 video card.  It behaves the same way. 
I think that rules out a video card problem. 

I checked the menus on the monitor and it doesn't seem to have the
upscale feature.  I saw other options included in their screenshot tho. 
Just not that one.  I did try other options tho.  They tend to change
instantly.  Most of them only affected brightness and such.

Given a different video card does the same way, it is either a driver
issue or a wrong setting somewhere.  I don't see anything in any option
about scaling or zooming in the monitor.  It is a fairly basic monitor. 
I might add, after I bought it, the price dropped.  :/   Oh, while in
KDE, I did go find the options for zoom and magnify and disabled all
those.  I never use them anyway.  Still no change.

Looks like we going to have to pull out a larger hammer.  Fix one
problem, another pops up.  What is that game, whack a mole 

I'm going to put the faster card back in so we can work on just one
card.  Beat it into submission.  LOL

Dale

:-)  :-) 

Re: [gentoo-user] ldconfig segfaults after updating to 23.0 profil

[Michael]

On Tuesday, 2 July 2024 20:05:37 BST Dan Johansson wrote:
> On 27.06.24 21:37, Michael wrote:
> > On Thursday, 27 June 2024 20:11:51 BST Dan Johansson wrote:
> >> Hello,
> >> 
> >> After updating my system to a 23.0 profile,
> >> default/linux/amd64/23.0/split-usr/desktop/plasma (stable), ldconfig has
> >> started segfaulting.
> > 
> > The 23.0 profile uses merged /usr as its default.  You can, however,
> > remain
> > with a split /usr for now.  What you can't do is mix the two.
> > 
> >> Here are the last few lines of "strace ldconfig":
> >> newfstatat(AT_FDCWD,
> >> "/usr/lib/rust/lib/librustc_driver-131b866216b2910c.so",
> >> {st_mode=S_IFREG|0644, st_size=153456592, ...}, 0) = 0 openat(AT_FDCWD,
> >> "/usr/lib/llvm/17/lib", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
> >> fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> >> getdents64(3, 0x572629d0 /* 22 entries */, 32768) = 824
> >> newfstatat(AT_FDCWD, "/usr/lib/llvm/17/lib/libclang.so.17",
> >> {st_mode=S_IFREG|0755, st_size=17506304, ...}, 0) = 0 openat(AT_FDCWD,
> >> "/usr/lib/llvm/17/lib/libclang.so.17", O_RDONLY) = 4 fstat(4,
> >> {st_mode=S_IFREG|0755, st_size=17506304, ...}) = 0
> >> mmap(NULL, 17506304, PROT_READ, MAP_SHARED, 4, 0) = 0x7fb6eb2d3000
> >> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
> >> si_addr=0x7fb6ed37c4dc}
> >> --- +++ killed by SIGSEGV +++
> >> Segmentation fault
> >> 
> >> The file in question (I think), does not look suspicious (I think):
> >> # ls -pal /usr/lib/llvm/17/lib/libclang.so.17
> >> /usr/lib/llvm/17/lib/libclang.so.17.0.6 lrwxrwxrwx 1 root root   18
> >> Jun
> >> 25 17:39 /usr/lib/llvm/17/lib/libclang.so.17 -> libclang.so.17.0.6
> >> -rwxr-xr-x 1 root root 14893056 Jun 25 17:39
> >> /usr/lib/llvm/17/lib/libclang.so.17.0.6
> >> 
> >> The system runs fine (as far as I ca see) but I am a bit nervous about
> >> rebooting at the moment.
> >> 
> >> Any suggestions?
> > 
> > I run a merged /usr profile 23.0, and my libclang.so.17.0.6 is bigger:
> > 
> > # ls -la /usr/lib/llvm/17/lib64/libclang.so.17.0.6
> > -rwxr-xr-x 1 root root 32579024 Jun  2 12:15 /usr/lib/llvm/17/lib64/
> > libclang.so.17.0.6
> > 
> > Have you re-emerged your toolchain and in particular sys-libs/glibc?
> 
> Found the culprit. It was sys-devel/clang
> 
> scanelf: /usr/lib/llvm/17/bin/clang-tidy: Invalid section header info (2)
> scanelf: /usr/lib/llvm/17/bin/c-index-test: Invalid section header info (2)
> scanelf: /usr/lib/llvm/17/lib/libclang.so: Invalid section header info (2)
> scanelf: /usr/lib/llvm/17/lib/libclang.so.17: Invalid section header info
> (2) scanelf: /usr/lib/llvm/17/lib/libclang.so.17.0.6: Invalid section
> header info (2)
> 
> After re-emerging sys-devel/clang again, ldconfig does not throw a sigsev.

How did you discover this?  Was it higher up in the build log?


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

[Michael]

On Tuesday, 2 July 2024 19:58:59 BST Dale wrote:
> Howdy,
> 
> New monitor came in.  Found it on my porch.  Unboxed it and hooked it
> up.  Started with no xorg.conf file.  It's high res, plasma comes up so
> all that is fine.  Now comes the problem.  Everything is HUGE.  Even on
> SDDM screen, it's like it is zoomed in or something.  Icons are huge,
> fonts are huge.  I think what it is doing is this, and it may be the
> video card.  I think it is thinking I have four monitors set up as one
> large screen.  With this one monitor, I'm seeing the top left monitor
> but not seeing the rest since I only have one monitor connected.  I
> might add, when I click to logout, that screen is huge too. 
> 
> I generated a xorg.conf with the nvidia tool.  No change.  I tried
> removing options that I thought might cause this largeness problem.  I
> even rebooted.  No change.  I open the Nvidia GUI software and tried
> adjusting things there.  No change.  I compared the setting to my main
> rig, other than the difference in the cards, all settings appear to be
> the same including what should be displayed where.  The resolution is
> correct too.   
> 
> Is it possible this card functions differently than my usual cards? 
> Someone mentioned these tend to be used in a business system which could
> mean they use four monitors for one large display, for presentations or
> something.  Is there something I need to disable or enable so the card
> knows I want independent monitors maybe?
> 
> I'm attaching the xorg.conf file, including options I commented out.  I
> also checked the logs, no errors or anything.  It's just the usual
> things like mouse and keyboard loading and it finding the monitor
> connected, unlike the old LG.  Maybe someone here as ran into this at
> work or for a client and has a idea on how to fix or that this card is
> not designed for my use. 
> 
> While I'm waiting on a reply, I'm going to try one of my older spare
> video cards.  If it works fine, it could be the new video card is set up
> to work this way.  May not can even change it. 
> 
> Thanks.
> 
> Dale
> 
> :-)  :-) 

If it is this *this* monitor:

https://www.samsung.com/us/computing/monitors/flat/32--s30b-fhd-75hz-amd-freesync-monitor-ls32b300nwnxgo/#specs

you should be able to set:

Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName  "Samsung LS32B30"
HorizSync   30.0 - 84.0
VertRefresh 50.0 - 75.0
Option "PreferredMode" "1920x1080_75.00"
Option "DPMS"
EndSection

for better responsiveness with less flicker when watching sports.

Did you comment out all the #lines in the "Screen" section, rather than 
letting nvidia set configure it as it needs to?

Set the screen to the desired resolution to match the monitor, e.g.:

Option "metamodes" "1920x1080 +0+0"

and it should scale correctly.

Also check if "Samsung Magic Upscale" has been enabled and this affects what 
screen size is eventually displayed on the monitor:

https://www.samsung.com/us/support/answer/ANS00086623/


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] ldconfig segfaults after updating to 23.0 profil

[Dan Johansson]

On 27.06.24 21:37, Michael wrote:

On Thursday, 27 June 2024 20:11:51 BST Dan Johansson wrote:

Hello,

After updating my system to a 23.0 profile,
default/linux/amd64/23.0/split-usr/desktop/plasma (stable), ldconfig has
started segfaulting.


The 23.0 profile uses merged /usr as its default.  You can, however, remain
with a split /usr for now.  What you can't do is mix the two.



Here are the last few lines of "strace ldconfig":
newfstatat(AT_FDCWD,
"/usr/lib/rust/lib/librustc_driver-131b866216b2910c.so",
{st_mode=S_IFREG|0644, st_size=153456592, ...}, 0) = 0 openat(AT_FDCWD,
"/usr/lib/llvm/17/lib", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents64(3, 0x572629d0 /* 22 entries */, 32768) = 824
newfstatat(AT_FDCWD, "/usr/lib/llvm/17/lib/libclang.so.17",
{st_mode=S_IFREG|0755, st_size=17506304, ...}, 0) = 0 openat(AT_FDCWD,
"/usr/lib/llvm/17/lib/libclang.so.17", O_RDONLY) = 4 fstat(4,
{st_mode=S_IFREG|0755, st_size=17506304, ...}) = 0
mmap(NULL, 17506304, PROT_READ, MAP_SHARED, 4, 0) = 0x7fb6eb2d3000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7fb6ed37c4dc}
--- +++ killed by SIGSEGV +++
Segmentation fault

The file in question (I think), does not look suspicious (I think):
# ls -pal /usr/lib/llvm/17/lib/libclang.so.17
/usr/lib/llvm/17/lib/libclang.so.17.0.6 lrwxrwxrwx 1 root root   18 Jun
25 17:39 /usr/lib/llvm/17/lib/libclang.so.17 -> libclang.so.17.0.6
-rwxr-xr-x 1 root root 14893056 Jun 25 17:39
/usr/lib/llvm/17/lib/libclang.so.17.0.6

The system runs fine (as far as I ca see) but I am a bit nervous about
rebooting at the moment.

Any suggestions?


I run a merged /usr profile 23.0, and my libclang.so.17.0.6 is bigger:

# ls -la /usr/lib/llvm/17/lib64/libclang.so.17.0.6
-rwxr-xr-x 1 root root 32579024 Jun  2 12:15 /usr/lib/llvm/17/lib64/
libclang.so.17.0.6

Have you re-emerged your toolchain and in particular sys-libs/glibc?


Found the culprit. It was sys-devel/clang

scanelf: /usr/lib/llvm/17/bin/clang-tidy: Invalid section header info (2)
scanelf: /usr/lib/llvm/17/bin/c-index-test: Invalid section header info (2)
scanelf: /usr/lib/llvm/17/lib/libclang.so: Invalid section header info (2)
scanelf: /usr/lib/llvm/17/lib/libclang.so.17: Invalid section header info (2)
scanelf: /usr/lib/llvm/17/lib/libclang.so.17.0.6: Invalid section header info 
(2)

After re-emerging sys-devel/clang again, ldconfig does not throw a sigsev.
--
Dan Johansson
***
This message is printed on 100% recycled electrons!
***

[gentoo-user] New monitor, new problem. Everything LARGE O_O

[Dale]

Howdy,

New monitor came in.  Found it on my porch.  Unboxed it and hooked it
up.  Started with no xorg.conf file.  It's high res, plasma comes up so
all that is fine.  Now comes the problem.  Everything is HUGE.  Even on
SDDM screen, it's like it is zoomed in or something.  Icons are huge,
fonts are huge.  I think what it is doing is this, and it may be the
video card.  I think it is thinking I have four monitors set up as one
large screen.  With this one monitor, I'm seeing the top left monitor
but not seeing the rest since I only have one monitor connected.  I
might add, when I click to logout, that screen is huge too. 

I generated a xorg.conf with the nvidia tool.  No change.  I tried
removing options that I thought might cause this largeness problem.  I
even rebooted.  No change.  I open the Nvidia GUI software and tried
adjusting things there.  No change.  I compared the setting to my main
rig, other than the difference in the cards, all settings appear to be
the same including what should be displayed where.  The resolution is
correct too.   

Is it possible this card functions differently than my usual cards? 
Someone mentioned these tend to be used in a business system which could
mean they use four monitors for one large display, for presentations or
something.  Is there something I need to disable or enable so the card
knows I want independent monitors maybe?

I'm attaching the xorg.conf file, including options I commented out.  I
also checked the logs, no errors or anything.  It's just the usual
things like mouse and keyboard loading and it finding the monitor
connected, unlike the old LG.  Maybe someone here as ran into this at
work or for a client and has a idea on how to fix or that this card is
not designed for my use. 

While I'm waiting on a reply, I'm going to try one of my older spare
video cards.  If it works fine, it could be the new video card is set up
to work this way.  May not can even change it. 

Thanks.

Dale

:-)  :-) 
root@Gentoo-1 ~ # cat /etc/X11/xorg.conf
# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 550.90.07

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 550.90.07

Section "ServerLayout"

#Option "Xinerama" "0"
Identifier "Layout0"
Screen  0  "Screen0" 0 0
InputDevice"Keyboard0" "CoreKeyboard"
InputDevice"Mouse0" "CorePointer"
Option "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"

# generated from data in "/etc/conf.d/gpm"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol"
Option "Device" "/dev/input/mice"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

# generated from default
Identifier "Keyboard0"
Driver "kbd"
EndSection

Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName  "Samsung LS32B30"
HorizSync   30.0 - 84.0
VertRefresh 50.0 - 75.0
Option "PreferredMode" "1920x1080_60.00"
Option "DPMS"
EndSection

Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName  "Quadro P1000"
EndSection

Section "Screen"

#Option "Stereo" "0"
#Option "MultiGPU" "Off"
#Option "BaseMosaic" "off"
Identifier "Screen0"
Device "Device0"
Monitor"Monitor0"
#DefaultDepth24
#Option "Stereo" "0"
#Option "nvidiaXineramaInfoOrder" "DP-3"
#Option "metamodes" "1920x1080 +0+0"
#Option "SLI" "Off"
#Option "MultiGPU" "Off"
#Option "BaseMosaic" "off"
SubSection "Display"
Depth   24
EndSubSection
EndSection

root@Gentoo-1 ~ #

Re: [gentoo-user] {SOLVED} Midnight Commander now viewing images with /usr/bin/xdg-open?!?!

[Michael]

On Tuesday, 2 July 2024 18:30:31 BST Walter Dnes wrote:
>   Midnight Commander has been using geeqie for viewing images on my
> system.  I did a world update last night.  Apparently image-viewing
> responsibility has been handed over to /usr/bin/xdg-open which, on my
> system, uses mupdf for jpg+jpeg and google-chrome-stable for png+gif
> images.  WTF!?!?!?
> 
> /bin/sh /usr/bin/xdg-open /home/waltdnes/downloads/stranded.jpg
> ...invokes...
> mupdf /home/waltdnes/downloads/stranded.jpg
> 
> /bin/sh /usr/bin/xdg-open /home/waltdnes/covidy/4bellcurve.png
> ...invokes...
> /usr/bin/google-chrome-stable /home/waltdnes/covidy/4bellcurve.png
> 
>   There's a right way, there's a wrong way, and then there's my way,  I
> inserted the following stanza in ~/.config/mc.ext.ini before any mention
> of image formats...
> 
> ###Start custom stuff###
> [image]
> Regex=\.(gif|jpeg|jpg|png|jng|mng|tiff|xbm|xpm|ico|svg|pgm|ppm|netpbm)$
> RegexIgnoreCase=true
> Open=/usr/bin/geeqie %p
> View=/usr/bin/geeqie %p
> #End custom stuff###
> 
> ...and mc is now back to using geeqie for image display,

Thanks for this!  One of my systems had started playing up some time ago, but 
I never got around to sorting out this ANNOYING problem.  I will duly 
implement your solution, with compliments.  :-)



signature.asc
Description: This is a digitally signed message part.

[gentoo-user] {SOLVED} Midnight Commander now viewing images with /usr/bin/xdg-open?!?!

[Walter Dnes]

  Midnight Commander has been using geeqie for viewing images on my
system.  I did a world update last night.  Apparently image-viewing
responsibility has been handed over to /usr/bin/xdg-open which, on my
system, uses mupdf for jpg+jpeg and google-chrome-stable for png+gif
images.  WTF!?!?!?

/bin/sh /usr/bin/xdg-open /home/waltdnes/downloads/stranded.jpg
...invokes...
mupdf /home/waltdnes/downloads/stranded.jpg

/bin/sh /usr/bin/xdg-open /home/waltdnes/covidy/4bellcurve.png
...invokes...
/usr/bin/google-chrome-stable /home/waltdnes/covidy/4bellcurve.png

  There's a right way, there's a wrong way, and then there's my way,  I
inserted the following stanza in ~/.config/mc.ext.ini before any mention
of image formats...

###Start custom stuff###
[image]
Regex=\.(gif|jpeg|jpg|png|jng|mng|tiff|xbm|xpm|ico|svg|pgm|ppm|netpbm)$
RegexIgnoreCase=true
Open=/usr/bin/geeqie %p
View=/usr/bin/geeqie %p
#End custom stuff###

...and mc is now back to using geeqie for image display,

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

Re: [gentoo-user] world upgrade a mess, need some advise

[Wols Lists]

On 02/07/2024 10:17, Arve Barsnes wrote:

IMO, only bring out the hammer if you're having a problem.


And when you run emerge --update, does that sometimes find nothing to 
upgrade? No reason why it *should* find something.


There's a couple of commands like that that sometimes find nothing to do 
- emerge --depclean is another.


But if you set off all these "do something if there's something needing 
doing" jobs, you'll always have a clean, up-to-date system.


And yes it would be nice if there was a page somewhere in the handbook 
or similar that said "this is how to keep your system up-to-date, just 
run these commands every week or so".


Cheers,
Wol

Re: [gentoo-user] KDE6 and Pipewire control change

[Mark Knecht]

On Tue, Jul 2, 2024 at 5:47 AM Dale  wrote:

> Does anyone know where those controls went or if there is some new way
> to control that that I've missed?  I really liked having those options.
> It made things a lot easier.  USE flag info.


Everything I need is either in the speaker icon on the bottom rail or in
System Settings-> Audio.

I don't see anything missing from earlier versions of KDE audio, or if it
is missing I never used it.

Good luck with the new monitor

Mark

Re: [gentoo-user] world upgrade a mess, need some advise

[Dale]

Arve Barsnes wrote:
> On Tue, 2 Jul 2024 at 10:57, Dale  wrote:
>> Just some additional info.  I did a update on my main rig the other
>> day.  According to emerge, everything is just fine.  I ran perl-cleaner
>> with pretend, it is wanting to emerge some 200 packages.  Looks like Wol
>> is right.  We need to run this after each OS update.  Maybe this should
>> be documented in a wiki somewhere???
> Sometimes you need a hammer, but most of the time you don't. Have not
> used perl-cleaner for a while, so I tried it here, and it found no
> packages needing to be rebuilt.
>
> IMO, only bring out the hammer if you're having a problem.
>
> Regards,
> Arve
>
>


Like on my last problem, I didn't realize it was a perl problem.  That
problem was likely lurking for a while just waiting on the right thing
to happen so it could pop up.  For me, I try to keep a clean system.  I
like clean upgrades, all packages to be linked to each other that should
be and for them to be in sync when needed.  If running perl-cleaner will
prevent problems, I don't mind pulling out that hammer when all I need
is a small hammer.  It's better than waiting for things to start failing
and then not know what hammer you need or even worse, what to hit. 

Way back when I ran into weird problems, I would do a emerge -e world. 
Oddly enough, that tended to fix problems that emerge didn't pick up
on.  Likely some package that was linked wrong during the upgrade of
another package.  Today, we have tools that help prevent that.  I
haven't done a emerge -e for that reason in a while.  Last I can
remember was when we were told to do that in a news item. 

Some problems are best fixed while small.  When they get big, they get
harder to fix.  That's my thinking.  To each his/her own tho.  ;-) 

Dale

:-)  :-) 

[gentoo-user] KDE6 and Pipewire control change

[Dale]

Howdy,

As most, if not all, KDE users know, a while back KDE started using
Pipewire.  After I saw how it worked, I kinda liked it because it gave
me some controls I needed and they made it easier to switch audio around
and adjust volume levels on different apps independently.  All things
considered, it was a improvement.  On my main rig, I recently did the
switch to KDE6, at least I'm pretty sure anyway.  One thing I noticed
after the upgrade, I can't find the controls I used to have with the new
pipewire.  As a example, if I want to watch a video on my TV, I could
click the little speaker thing on the bottom panel, click on the app
tab, find the app that is playing that video then click the horizontal
bars.  From there I could select to either send audio to the main
speakers or to the HDMI cable which is my TV.  I can't find the
horizontal bars anymore.  I've tried clicking other things thinking they
changed what you click but I can't find those controls anywhere. 

I checked the USE flags and they look OK.  I don't see anything disabled
except for things I don't have, either software or hardware wise.  I'll
put a list of those below.  I've looked everywhere I can think of but
don't see how to control it anymore.  I've had to go back to the old
manual way of telling Smplayer to send audio to HDMI.  Thing is, sending
mpv or other players audio is more difficult.  I have some videos that
have no audio with Smplayer because they use DTS or something and the
sound doesn't work, despite the USE flag being on for it.  So, for those
I use Qmplay2 or mpv to play. 

Does anyone know where those controls went or if there is some new way
to control that that I've missed?  I really liked having those options. 
It made things a lot easier.  USE flag info. 


root@fireball / # equery u kde-plasma/kpipewire media-video/pipewire
[ Legend : U - final flag setting for installation]
[    : I - package is installed with flag ]
[ Colors : set, unset ]
 * Found these USE flags for kde-plasma/kpipewire-6.1.1:
 U I
 - - debug : Enable extra debug codepaths, like asserts and extra
output. If you want to get meaningful backtraces see

https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
 - - test  : Enable dependencies and/or preparations necessary to run
tests (usually controlled by FEATURES=test but can be toggled independently)

 * Found these USE flags for media-video/pipewire-1.0.7:
 U I
 + + X : Enable audible bell for X11
 - - abi_x86_32    : 32-bit (x86) libraries
 - - bluetooth : Enable Bluetooth Support
 + + dbus  : Enable dbus support for anything that needs it
(gpsd, gnomemeeting, etc)
 - - doc   : Add extra documentation (API, Javadoc, etc). It is
recommended to enable per package instead of globally
 - - echo-cancel   : Enable WebRTC-based echo canceller via
media-libs/webrtc-audio-processing
 + + extra : Build pw-cat/pw-play/pw-record
 + + ffmpeg    : Enable ffmpeg/libav-based audio/video codec support
 - - flatpak   : Enable Flatpak support
 - - gsettings : Use gsettings (dev-libs/glib) to read/save used
modules (useful for e.g. media-sound/paprefs
 - - gstreamer : Add support for media-libs/gstreamer (Streaming media)
 - - ieee1394  : Enable FireWire/iLink IEEE1394 support (dv, camera,
...)
 - - jack-client   : Install a plugin for running PipeWire as a JACK client
 - - jack-sdk  : Use PipeWire as JACK replacement
 - - liblc3    : Allow loading LC3 plugins via media-sound/liblc3
 - - lv2   : Allow loading LV2 plugins via media-libs/lv2
 - - man   : Build and install man pages
 - - modemmanager  : Combined with USE=bluetooth, allows PipeWire to
perform telephony on mobile devices.
 + + pipewire-alsa : Replace PulseAudio's ALSA plugin with PipeWire's plugin
 + + readline  : Enable support for libreadline, a GNU line-editing
library that almost everyone wants
 - - roc   : Enable roc support for real-time audio streaming
over the network, using media-libs/roc-toolkit. See

https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Network#roc
 + + sound-server  : Provide sound server using ALSA and bluetooth devices
 + + ssl   : Enable raop-sink support (needs dev-libs/openssl)
 - - systemd   : Enable use of systemd-specific libraries and
features like socket activation or session tracking
 - - test  : Enable dependencies and/or preparations necessary
to run tests (usually controlled by FEATURES=test but can be toggled
independently)
 - - v4l   : Enable support for video4linux (using linux-headers
or userspace libv4l libraries)
 + + zeroconf  : Support for DNS Service Discovery (DNS-SD)
root@fireball / #


Thoughts? 

Dale

:-)  :-) 

P. S.  Monitor out for delivery.  Today is the day.  :-D  Oh, I have a
lot of dried basil now.  Last batch was 8 trays full.  I still got some
in planters that I will pick again in 

Re: [gentoo-user] how to record mp3 stream

[Håkon Alstadheim]

You can just dump the stream directly. Use an at-command or a cron-job 
to run wget or whatever, and then kill that job when you want the 
recording to stop. All players I've tried play such a dump just fine.


Den 01.07.2024 15:14, skrev Michael:

On Monday, 1 July 2024 11:39:09 BST Jacques Montier wrote:

Le lun. 1 juil. 2024 à 11:19, John Covici  a écrit :

Hi.  I am interested in recording an mp3 stream in the background and
being able to specify start/stop time, etc.

I looked at Google, but just found a package called audio-recorder,
but I am not sure its currently maintained and its not in the gentoo
packages.

Thanks in advance for any suggestions.

--
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

  John Covici wb2una
  cov...@ccs.covici.com

VLC ?
https://linuxconfig.org/how-to-stream-video-from-vlc

--
Jacques

There is arecord from the package media-sound/alsa-utils, there's ffmpeg and
even cvlc if you want/prefer to use CLI tools, but as far as I know they will
all require some scripting to control start/stop time if you're not doing it
manually.  Will probably require transcoding into MP3 from raw PCM audio
capture (e.g. from pcm_s16le).

You could always record over a longer duration and then chop the bits at the
start/end you don't wish to retain.

Re: [gentoo-user] world upgrade a mess, need some advise

[Arve Barsnes]

On Tue, 2 Jul 2024 at 10:57, Dale  wrote:
> Just some additional info.  I did a update on my main rig the other
> day.  According to emerge, everything is just fine.  I ran perl-cleaner
> with pretend, it is wanting to emerge some 200 packages.  Looks like Wol
> is right.  We need to run this after each OS update.  Maybe this should
> be documented in a wiki somewhere???

Sometimes you need a hammer, but most of the time you don't. Have not
used perl-cleaner for a while, so I tried it here, and it found no
packages needing to be rebuilt.

IMO, only bring out the hammer if you're having a problem.

Regards,
Arve

Re: [gentoo-user] world upgrade a mess, need some advise

[Dale]

John Covici wrote:
> On Mon, 01 Jul 2024 19:16:11 -0400,
> Wol wrote:
>> On 01/07/2024 20:27, John Covici wrote:
 I seem to recall having to run that during that upgrade as well.  It
 reinstalled a lot of packages but it worked.  It's worth trying for sure.

>>> But don't you do that after the upgrade -- I can't even start the
>>> upgrade, so how would perl-cleaner help?
>> Trust me it does!
>>
>> You have a bunch of old perl scripts, one (or more) of which are
>> blocking the upgrade. perl-cleaner will upgrade them to the
>> latest version compatible with your current perl, which then
>> frees up the perl upgrade. Make sure you run perl-cleaner again
>> afterwards, to ensure you have the absolute latest version of all
>> these extra bits. In fact, you should really run perl-cleaner
>> after every "emerge --update". Most people most of the time
>> either forget or don't realise ...
>>
>> Don't forget, if I've got it right, perl and CPAN predate linux,
>> so if there's an argument about who needs to change, perl simply
>> says "I was here first, you have to do it *my* way".
>>
>> Cheers,
>> Wol
>>
> I ran perl-cleaner and it is going right now -- installing perl itself
> and lots of others -- thanks a lot people.
>


Just some additional info.  I did a update on my main rig the other
day.  According to emerge, everything is just fine.  I ran perl-cleaner
with pretend, it is wanting to emerge some 200 packages.  Looks like Wol
is right.  We need to run this after each OS update.  Maybe this should
be documented in a wiki somewhere???

Dale

:-)  :-) 

P. S. Monitor left Memphis hub.  Should arrive today.  I hope. 

Re: [gentoo-user] world upgrade a mess, need some advise

[John Covici]

On Mon, 01 Jul 2024 19:16:11 -0400,
Wol wrote:
> 
> On 01/07/2024 20:27, John Covici wrote:
> >> I seem to recall having to run that during that upgrade as well.  It
> >> reinstalled a lot of packages but it worked.  It's worth trying for sure.
> >> 
> > But don't you do that after the upgrade -- I can't even start the
> > upgrade, so how would perl-cleaner help?
> 
> Trust me it does!
> 
> You have a bunch of old perl scripts, one (or more) of which are
> blocking the upgrade. perl-cleaner will upgrade them to the
> latest version compatible with your current perl, which then
> frees up the perl upgrade. Make sure you run perl-cleaner again
> afterwards, to ensure you have the absolute latest version of all
> these extra bits. In fact, you should really run perl-cleaner
> after every "emerge --update". Most people most of the time
> either forget or don't realise ...
> 
> Don't forget, if I've got it right, perl and CPAN predate linux,
> so if there's an argument about who needs to change, perl simply
> says "I was here first, you have to do it *my* way".
> 
> Cheers,
> Wol
> 

I ran perl-cleaner and it is going right now -- installing perl itself
and lots of others -- thanks a lot people.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com

Re: [gentoo-user] world upgrade a mess, need some advise

[Wol]

On 01/07/2024 20:27, John Covici wrote:

I seem to recall having to run that during that upgrade as well.  It
reinstalled a lot of packages but it worked.  It's worth trying for sure.


But don't you do that after the upgrade -- I can't even start the
upgrade, so how would perl-cleaner help?


Trust me it does!

You have a bunch of old perl scripts, one (or more) of which are 
blocking the upgrade. perl-cleaner will upgrade them to the latest 
version compatible with your current perl, which then frees up the perl 
upgrade. Make sure you run perl-cleaner again afterwards, to ensure you 
have the absolute latest version of all these extra bits. In fact, you 
should really run perl-cleaner after every "emerge --update". Most 
people most of the time either forget or don't realise ...


Don't forget, if I've got it right, perl and CPAN predate linux, so if 
there's an argument about who needs to change, perl simply says "I was 
here first, you have to do it *my* way".


Cheers,
Wol

Re: [gentoo-user] world upgrade a mess, need some advise

[Dale]

John Covici wrote:
> On Mon, 01 Jul 2024 09:53:56 -0400,
> Dale wrote:
>> Wols Lists wrote:
>>> On 01/07/2024 11:34, Michael wrote:
> Thanks in advance for any suggestions.
 Whenever I have a problem involving perl I first run:

 /usr/bin/perl-cleaner --reallyall

 I don't know if it will fix your problem, but it won't hurt trying
 this first.
>>> Yup. I discovered this. A lot of perl stuff doesn't seem to get
>>> updated in the normal course of updates, and all of a sudden perl
>>> itself gets wedged.
>>>
>>> Bear in mind large chunks of Perl are downloaded from CPAN, and the
>>> eco-system is designed to upgrade them from inside Perl itself, you
>>> can see how things go wrong ...
>>>
>>> Cheers,
>>> Wol
>>>
>>>
>>
>> I seem to recall having to run that during that upgrade as well.  It
>> reinstalled a lot of packages but it worked.  It's worth trying for sure.
>>
> But don't you do that after the upgrade -- I can't even start the
> upgrade, so how would perl-cleaner help?
>


I can't recall for sure but I think my problem was different but perl
related.  I had some circular problems with some packages and was
getting some weird error when it failed.  Anyway, I'm almost certain it
was Micheal that recommended running perl-cleaner.  It fixed the perl
problem I had.  I've seen a couple others over the years use it.  I
think perl tends to manage itself fairly well but sometimes, it just
needs a good swift kick. 

I think there is a pretend option.  You could try that if there is one
and just see what it says it will do and if you think it is OK.  Or,
post what it says here and see what others think about what it wants to
do if you not sure. 

I'm not a perl expert but that command has fixed some odd issues before. 

Dale

:-)  :-) 

P. S.  No monitor today.  They deliver before it gets this late.  It
looks like it missed the truck from the Memphis hub to my local
distribution center.  It shows it is still there, not here.  Maybe
tomorrow.  < me prays >

Re: [gentoo-user] world upgrade a mess, need some advise

[John Covici]

On Mon, 01 Jul 2024 09:53:56 -0400,
Dale wrote:
> 
> Wols Lists wrote:
> > On 01/07/2024 11:34, Michael wrote:
> >>> Thanks in advance for any suggestions.
> >> Whenever I have a problem involving perl I first run:
> >>
> >> /usr/bin/perl-cleaner --reallyall
> >>
> >> I don't know if it will fix your problem, but it won't hurt trying
> >> this first.
> >
> > Yup. I discovered this. A lot of perl stuff doesn't seem to get
> > updated in the normal course of updates, and all of a sudden perl
> > itself gets wedged.
> >
> > Bear in mind large chunks of Perl are downloaded from CPAN, and the
> > eco-system is designed to upgrade them from inside Perl itself, you
> > can see how things go wrong ...
> >
> > Cheers,
> > Wol
> >
> >
> 
> 
> I seem to recall having to run that during that upgrade as well.  It
> reinstalled a lot of packages but it worked.  It's worth trying for sure.
> 

But don't you do that after the upgrade -- I can't even start the
upgrade, so how would perl-cleaner help?

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com

Re: [gentoo-user] Using Gentoo binary packages

[Eli Schwartz]

On 7/1/24 11:35 AM, Peter Humphrey wrote:
> Hello list,
> 
> Can someone please tell me what the official cure is for the error "unsafe 
> permissions on homedir '/etc/portage/gnupg' ? I even get it if I remove that 
> directory altogether and then run 'getuto' .
> 
> If getuto can't create the directory with safe permissions, what chance do I 
> have?


GnuPG is incorrect, and the permissions aren't unsafe.

It is claiming they are unsafe because users other than root can see the
pubkeys in read-only mode.


-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-user] Using Gentoo binary packages

[Peter Humphrey]

Hello list,

Can someone please tell me what the official cure is for the error "unsafe 
permissions on homedir '/etc/portage/gnupg' ? I even get it if I remove that 
directory altogether and then run 'getuto' .

If getuto can't create the directory with safe permissions, what chance do I 
have?

-- 
Regards,
Peter.

Re: [gentoo-user] bash: genfun_has_readline

[Peter Humphrey]

On Sunday, 30 June 2024 16:56:56 BST I wrote:
> I'm seeing this every time I chroot into my rescue system:
> 
> # chroot /mnt/rescue /bin/bash
> bash: genfun_has_readline: command not found
--->8
> The same thing happened when I started a new build from stage-3, when I
> chrooted into the nascent system.

I was mistaken about that latter; it's more complicated than I thought.

The problem seems to have been that I was running the new installation by 
hosting a chroot on an already running Gentoo system. I still have no idea 
what's wrong with doing that, but I get all sorts of dramatic failures in 
emerging.

I've now run a successful installation from a SysRescCD, so I'm left with yet 
more head-scratching.

Sorry about the noise.

-- 
Regards,
Peter.

Re: [gentoo-user] world upgrade a mess, need some advise

[Dale]

Wols Lists wrote:
> On 01/07/2024 11:34, Michael wrote:
>>> Thanks in advance for any suggestions.
>> Whenever I have a problem involving perl I first run:
>>
>> /usr/bin/perl-cleaner --reallyall
>>
>> I don't know if it will fix your problem, but it won't hurt trying
>> this first.
>
> Yup. I discovered this. A lot of perl stuff doesn't seem to get
> updated in the normal course of updates, and all of a sudden perl
> itself gets wedged.
>
> Bear in mind large chunks of Perl are downloaded from CPAN, and the
> eco-system is designed to upgrade them from inside Perl itself, you
> can see how things go wrong ...
>
> Cheers,
> Wol
>
>


I seem to recall having to run that during that upgrade as well.  It
reinstalled a lot of packages but it worked.  It's worth trying for sure.

Dale

:-)  :-) 

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Michael wrote:
> On Sunday, 30 June 2024 23:56:40 BST Dale wrote:
>> Michael wrote:
>>> This is good! :D
>>> Edit the section below by adding the PreferredMode line:
>>>
>>> Section "Monitor"
>>>
>>> Identifier "Monitor0"
>>> VendorName "Unknown"
>>> ModelName  "LG Electronics W2253"
>>> HorizSync   30.0 - 83.0
>>> VertRefresh 56.0 - 61.0
>>> Option "PreferredMode"   "1920x1080_60.00"
>>> Option "DPMS"
>>>
>>> EndSection
>>>
>>> Save it, then check if you get a consistent result when you restart the
>>> DM, or reboot.
>>>
>>> If it is still playing up you need to show the Xorg.0.log while the
>>> monitor is working with the nvidia driver, to see which Modeline it uses
>>> and add this in the "Monitor" section too, above the "PreferredMode"
>>> entry.
>>>
>>> If none of this works reliably, then you have to capture the EDID table
>>> while the monitor is working, save it in a file and set nvidia-settings
>>> to use it hereafter.  However, if you will NOT be using this monitor for
>>> much longer this would be an exercise only to make you feel good for
>>> beating it into submission!  LOL!
>> OK.  First time, it worked.  Second time, it came up but in low res. 
>> Plasma was working to, both times.  So, I opened the Nvidia GUI and told
>> it to safe a new config with it in hi res mostly just to see what it
>> would add if anything.  It did.  The only change I could see was it
>> added metamodes options like this:
>>
>> Section "Screen"
>>
>> # Removed Option "metamodes" "nvidia-auto-select +0+0"
>> Identifier "Screen0"
>> Device "Device0"
>> Monitor"Monitor0"
>> DefaultDepth24
>> Option "Stereo" "0"
>> Option "nvidiaXineramaInfoOrder" "DP-3"
>> Option "metamodes" "1920x1080 +0+0"
>> #Option "metamodes" "1920x1080 +0+0; 1024x768_60 +0+0"
>> Option "SLI" "Off"
>> Option "MultiGPU" "Off"
>> Option "BaseMosaic" "off"
>> SubSection "Display"
>> Depth   24
>> EndSubSection
>> EndSection
>>
>>
>> As you can see, I removed the low res part, don't want that anyway, and
>> it seems to work more often but still fails a lot.  So, I removed the
>> metamodes Nvidia added.  Then it didn't come up at all, sddm or
>> anything, when I restarted DM.  I thought it adding your setting to
>> another section might help.  Guess not.  With the following removed, it
>> seems to do a little better but still can't depend on it to work.
>>
>> Section "Screen"
>> #Option "nvidiaXineramaInfoOrder" "DP-3"
>> #Option "metamodes" "1920x1080 +0+0"
>> #Option "metamodes" "1920x1080 +0+0; 1024x768_60 +0+0"
> You can add back:
>
> Option "metamodes" "1920x1080_60 +0+0"
>

Well, I did a sync and upgrade last night.  I also renamed the config
file so that it shouldn't be seen anymore.  That way when the new
monitor arrives, I don't have a clash with it. 


>> Basically, it is doing like it always has.  Most of the time, it doesn't
>> work.  Sometimes it does.  To be honest tho, I still wonder if it even
>> reads the file.  When I change something, I'd expect something
>> different.  Generally, it doesn't seem to affect anything unless I
>> reboot completely.  Sometimes I'm not sure it does then either.  So, I
>> think this old monitor just has a issue.  Maybe I need to rebuild some
>> more of the power supply or something in case it is providing bad power
>> to the parts that talks to the puter.  Either way, if the new one works,
>> I just don't think this old monitor is going to work correctly no matter
>> what we throw at it. 
> The last thing left to try is to capture the EDID table with nvidia-settings, 
> configure it to stop trying to load it from the monitor and instead feed the 
> captured file to it.  If that doesn't work either, then there is no solution 
> I 
> can think of ... 
>
>
>> I will saw this, we threw the kitchen sink at it.  I think this is one
>> of the longest threads I've seen in a long while.  o_O 
>>
>> Dale
>>
>> :-) 
>>
>> P. S.  Monitor updated.  Now it says tomorrow.  It's in the right place
>> to do so.  It's at the Memphis hub.  Usually, it comes from there to the
>> local distribution point and on the truck.  They sometimes deliver by
>> noon.  Could be a little late given it is Monday. 
> Hopefully this won't be the start of a new loong thread on yet another 
> monitor!  LOL!


I hope it works like it should.  If it does, I may do some work on that
old monitor.  Check the caps in the power supply and such as that.  I
rebuilt it a few years ago but maybe I missed something.  I may have
fixed it enough to come on, display part anyway, but not enough for
everything, the ID part, to work correctly. 

Right now, it still shows the new monitor at the hub around Memphis.  It
is Monday and they do get their stuff local a little late. UPS gets
theirs before sunup. 

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Michael]

On Sunday, 30 June 2024 23:56:40 BST Dale wrote:
> Michael wrote:
> > This is good! :D
> > Edit the section below by adding the PreferredMode line:
> > 
> > Section "Monitor"
> > 
> > Identifier "Monitor0"
> > VendorName "Unknown"
> > ModelName  "LG Electronics W2253"
> > HorizSync   30.0 - 83.0
> > VertRefresh 56.0 - 61.0
> > Option "PreferredMode"   "1920x1080_60.00"
> > Option "DPMS"
> > 
> > EndSection
> > 
> > Save it, then check if you get a consistent result when you restart the
> > DM, or reboot.
> > 
> > If it is still playing up you need to show the Xorg.0.log while the
> > monitor is working with the nvidia driver, to see which Modeline it uses
> > and add this in the "Monitor" section too, above the "PreferredMode"
> > entry.
> > 
> > If none of this works reliably, then you have to capture the EDID table
> > while the monitor is working, save it in a file and set nvidia-settings
> > to use it hereafter.  However, if you will NOT be using this monitor for
> > much longer this would be an exercise only to make you feel good for
> > beating it into submission!  LOL!
> 
> OK.  First time, it worked.  Second time, it came up but in low res. 
> Plasma was working to, both times.  So, I opened the Nvidia GUI and told
> it to safe a new config with it in hi res mostly just to see what it
> would add if anything.  It did.  The only change I could see was it
> added metamodes options like this:
> 
> Section "Screen"
> 
> # Removed Option "metamodes" "nvidia-auto-select +0+0"
> Identifier "Screen0"
> Device "Device0"
> Monitor"Monitor0"
> DefaultDepth24
> Option "Stereo" "0"
> Option "nvidiaXineramaInfoOrder" "DP-3"
> Option "metamodes" "1920x1080 +0+0"
> #Option "metamodes" "1920x1080 +0+0; 1024x768_60 +0+0"
> Option "SLI" "Off"
> Option "MultiGPU" "Off"
> Option "BaseMosaic" "off"
> SubSection "Display"
> Depth   24
> EndSubSection
> EndSection
> 
> 
> As you can see, I removed the low res part, don't want that anyway, and
> it seems to work more often but still fails a lot.  So, I removed the
> metamodes Nvidia added.  Then it didn't come up at all, sddm or
> anything, when I restarted DM.  I thought it adding your setting to
> another section might help.  Guess not.  With the following removed, it
> seems to do a little better but still can't depend on it to work.
> 
> Section "Screen"
> #Option "nvidiaXineramaInfoOrder" "DP-3"
> #Option "metamodes" "1920x1080 +0+0"
> #Option "metamodes" "1920x1080 +0+0; 1024x768_60 +0+0"

You can add back:

Option "metamodes" "1920x1080_60 +0+0"


> Basically, it is doing like it always has.  Most of the time, it doesn't
> work.  Sometimes it does.  To be honest tho, I still wonder if it even
> reads the file.  When I change something, I'd expect something
> different.  Generally, it doesn't seem to affect anything unless I
> reboot completely.  Sometimes I'm not sure it does then either.  So, I
> think this old monitor just has a issue.  Maybe I need to rebuild some
> more of the power supply or something in case it is providing bad power
> to the parts that talks to the puter.  Either way, if the new one works,
> I just don't think this old monitor is going to work correctly no matter
> what we throw at it. 

The last thing left to try is to capture the EDID table with nvidia-settings, 
configure it to stop trying to load it from the monitor and instead feed the 
captured file to it.  If that doesn't work either, then there is no solution I 
can think of ... 


> I will saw this, we threw the kitchen sink at it.  I think this is one
> of the longest threads I've seen in a long while.  o_O 
> 
> Dale
> 
> :-) 
> 
> P. S.  Monitor updated.  Now it says tomorrow.  It's in the right place
> to do so.  It's at the Memphis hub.  Usually, it comes from there to the
> local distribution point and on the truck.  They sometimes deliver by
> noon.  Could be a little late given it is Monday. 

Hopefully this won't be the start of a new loong thread on yet another 
monitor!  LOL!


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] how to record mp3 stream

[Michael]

On Monday, 1 July 2024 11:39:09 BST Jacques Montier wrote:
> Le lun. 1 juil. 2024 à 11:19, John Covici  a écrit :
> > Hi.  I am interested in recording an mp3 stream in the background and
> > being able to specify start/stop time, etc.
> > 
> > I looked at Google, but just found a package called audio-recorder,
> > but I am not sure its currently maintained and its not in the gentoo
> > packages.
> > 
> > Thanks in advance for any suggestions.
> > 
> > --
> > Your life is like a penny.  You're going to lose it.  The question is:
> > How do
> > you spend it?
> > 
> >  John Covici wb2una
> >  cov...@ccs.covici.com
> 
> VLC ?
> https://linuxconfig.org/how-to-stream-video-from-vlc
> 
> --
> Jacques

There is arecord from the package media-sound/alsa-utils, there's ffmpeg and 
even cvlc if you want/prefer to use CLI tools, but as far as I know they will 
all require some scripting to control start/stop time if you're not doing it 
manually.  Will probably require transcoding into MP3 from raw PCM audio 
capture (e.g. from pcm_s16le).

You could always record over a longer duration and then chop the bits at the 
start/end you don't wish to retain.



signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] world upgrade a mess, need some advise

[Wols Lists]

On 01/07/2024 11:34, Michael wrote:

Thanks in advance for any suggestions.

Whenever I have a problem involving perl I first run:

/usr/bin/perl-cleaner --reallyall

I don't know if it will fix your problem, but it won't hurt trying this first.


Yup. I discovered this. A lot of perl stuff doesn't seem to get updated 
in the normal course of updates, and all of a sudden perl itself gets 
wedged.


Bear in mind large chunks of Perl are downloaded from CPAN, and the 
eco-system is designed to upgrade them from inside Perl itself, you can 
see how things go wrong ...


Cheers,
Wol

Re: [gentoo-user] how to record mp3 stream

[Jacques Montier]

Le lun. 1 juil. 2024 à 11:19, John Covici  a écrit :

> Hi.  I am interested in recording an mp3 stream in the background and
> being able to specify start/stop time, etc.
>
> I looked at Google, but just found a package called audio-recorder,
> but I am not sure its currently maintained and its not in the gentoo
> packages.
>
> Thanks in advance for any suggestions.
>
> --
> Your life is like a penny.  You're going to lose it.  The question is:
> How do
> you spend it?
>
>  John Covici wb2una
>  cov...@ccs.covici.com
>
>
VLC ?
https://linuxconfig.org/how-to-stream-video-from-vlc

--
Jacques

Re: [gentoo-user] world upgrade a mess, need some advise

[Michael]

On Monday, 1 July 2024 11:04:37 BST John Covici wrote:
> Hi.  So, trying to do a world update, I ran into two major problems --
> one is perl and the other is python 3.12.  Here is what I get trying
> to upgrade perl by itself:
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies   ... done!
> Dependency resolution took 28.07 s (backtrack: 3/200).
> 
> [ebuild U  ] dev-lang/perl-5.40.0:0/5.40::gentoo
> [5.38.2-r6:0/5.38::gentoo] USE="gdbm -berkdb -doc -minimal"
> PERL_FEATURES="(-debug) -ithreads -quadmath" 13,616 KiB
> 
> Total: 1 package (1 upgrade), Size of downloads: 13,616 KiB
> 
> !!! Multiple package instances within a single package slot have been
> pulled
> !!! into the dependency graph, resulting in a slot conflict:
> 
> dev-lang/perl:0
> 
>   (dev-lang/perl-5.40.0:0/5.40::gentoo, ebuild scheduled for merge)
>   USE="gdbm -berkdb -doc -minimal" ABI_X86="(64)"
>   PERL_FEATURES="(-debug) -ithreads -quadmath" pulled in by
>   =dev-lang/perl-5.40* required by
>   (virtual/perl-CPAN-2.360.0-r1-1:0/0::gentoo, installed) USE=""
>   ABI_X86="(64)"
>   ^  ^
>=dev-lang/perl-5.40.0 (Argument)
>   (and 35 more with the same problems)
> 
>   (dev-lang/perl-5.38.2-r6-1:0/5.38::gentoo, installed) USE="gdbm
>   -berkdb -doc -minimal" ABI_X86="(64)" PERL_FEATURES="(-debug)
>   -ithreads -quadmath" pulled in by
>   dev-lang/perl:0/5.38= required by
>   (virtual/perl-CPAN-Meta-YAML-0.18.0-r10-1:0/0::gentoo, installed)
>   USE="" ABI_X86="(64)"
>
>   dev-lang/perl:0/5.38=[-build(-)] 
required by
>   (dev-vcs/git-2.45.1-1:0/0::gentoo, installed) USE="blksha1 curl gpg
>   iconv keyring nls pcre perl safe-directory webdav -cgi -cvs -doc
>   -highlight -mediawiki -perforce (-selinux) -subversion -t\est -tk
>   -xinetd" ABI_X86="(64)" PYTHON_SINGLE_TARGET="python3_11 -python3_10
>   -python3_12"
>
>   \
>   =dev-lang/perl-5.38* required by
>   (virtual/perl-Socket-2.36.0-1:0/0::gentoo, installed) USE=""
>   ABI_X86="(64)"
>   ^  ^
>(and 308 more with the same problems)
> 
> NOTE: Use the '--verbose-conflicts' option to display parents omitted
> above
> 
> !!! The slot conflict(s) shown above involve package(s) which may need
> to
> !!! be rebuilt in order to solve the conflict(s). However, the
> following
> !!! package(s) cannot be rebuilt for the reason(s) shown:
> 
>   (dev-vcs/git-2.45.1-1:0/0::gentoo, installed): ebuild is masked or
>   unavailable
> 
> 
> It may be possible to solve this problem by using package.mask to
> prevent one of those packages from being selected. However, it is also
> possible that conflicting dependencies exist such that they are
> impossible to satisfy simultaneously.  If such a conflict exists in
> the dependencies of two different packages, then those packages can
> not be installed simultaneously.
> 
> For more information, see MASKED PACKAGES section in the emerge man
> page or refer to the Gentoo Handbook.
> 
> 
> !!! The following installed packages are masked:
> - xfce-base/xfconf-4.19.2::gentoo (masked by: package.mask)
> /var/db/repos/gentoo/profiles/package.mask:
> # Micha\u0142 Górny  (2024-06-08)
> # Prereleases of Xfce 4.20.  Masking upon popular request, due to
> # a large number of regressions in every new release.
> 
> - dev-php/PEAR-Mail-1.5.0::gentoo (masked by: package.mask)
> /var/db/repos/gentoo/profiles/package.mask:
> # Viorel Munteanu  (2024-06-11)
> # dev-php/pear, dev-php/PEAR-* and their reverse dependencies: mask
> for removal
> # in 30 days.
> ## they have around 40 bugs.
> # Removal: 2024-07-11.  Bug #933998.
> 
> - xfce-base/libxfce4util-4.19.3::gentoo (masked by: package.mask)
> - dev-php/PEAR-DB-1.11.0::gentoo (masked by: package.mask)
> - dev-build/xfce4-dev-tools-4.19.1::gentoo (masked by: package.mask)
> - dev-php/PEAR-Date-1.5.0_alpha4-r1::gentoo (masked by: package.mask)
> - xfce-base/exo-4.19.0::gentoo (masked by: package.mask)
> - dev-php/PEAR-XML_Serializer-0.21.0-r1::gentoo (masked by:
> - package.mask)
> - xfce-base/libxfce4ui-4.19.5::gentoo (masked by: package.mask)
> - dev-php/PEAR-XML_Parser-1.3.8-r1::gentoo (masked by: package.mask)
> For more information, see the MASKED PACKAGES section in the emerge
> man page or refer to the Gentoo Handbook.
> I tried with backtrack=1000, with no different results.
> 
> Thanks in advance for any suggestions.

Whenever I have a problem involving perl I first run:

/usr/bin/perl-cleaner --reallyall

I don't know if it will fix your problem, but it won't hurt trying this first.


signature.asc
Description: This is a digitally signed message part.

[gentoo-user] world upgrade a mess, need some advise

[John Covici]

Hi.  So, trying to do a world update, I ran into two major problems --
one is perl and the other is python 3.12.  Here is what I get trying
to upgrade perl by itself:

These are the packages that would be merged, in order:

Calculating dependencies   ... done!
Dependency resolution took 28.07 s (backtrack: 3/200).

[ebuild U  ] dev-lang/perl-5.40.0:0/5.40::gentoo
[5.38.2-r6:0/5.38::gentoo] USE="gdbm -berkdb -doc -minimal"
PERL_FEATURES="(-debug) -ithreads -quadmath" 13,616 KiB

Total: 1 package (1 upgrade), Size of downloads: 13,616 KiB

!!! Multiple package instances within a single package slot have been
pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-lang/perl:0

  (dev-lang/perl-5.40.0:0/5.40::gentoo, ebuild scheduled for merge)
  USE="gdbm -berkdb -doc -minimal" ABI_X86="(64)"
  PERL_FEATURES="(-debug) -ithreads -quadmath" pulled in by
  =dev-lang/perl-5.40* required by
  (virtual/perl-CPAN-2.360.0-r1-1:0/0::gentoo, installed) USE=""
  ABI_X86="(64)"
  ^  ^
 =dev-lang/perl-5.40.0 (Argument)
(and 35 more with the same problems)

  (dev-lang/perl-5.38.2-r6-1:0/5.38::gentoo, installed) USE="gdbm
  -berkdb -doc -minimal" ABI_X86="(64)" PERL_FEATURES="(-debug)
  -ithreads -quadmath" pulled in by
  dev-lang/perl:0/5.38= required by
  (virtual/perl-CPAN-Meta-YAML-0.18.0-r10-1:0/0::gentoo, installed)
  USE="" ABI_X86="(64)"
   
dev-lang/perl:0/5.38=[-build(-)] required by
  (dev-vcs/git-2.45.1-1:0/0::gentoo, installed) USE="blksha1 curl gpg
  iconv keyring nls pcre perl safe-directory webdav -cgi -cvs -doc
  -highlight -mediawiki -perforce (-selinux) -subversion -t\est -tk
  -xinetd" ABI_X86="(64)" PYTHON_SINGLE_TARGET="python3_11 -python3_10
  -python3_12"
   
  \
  =dev-lang/perl-5.38* required by
  (virtual/perl-Socket-2.36.0-1:0/0::gentoo, installed) USE=""
  ABI_X86="(64)"
  ^  ^
 (and 308 more with the same problems)

NOTE: Use the '--verbose-conflicts' option to display parents omitted
above

!!! The slot conflict(s) shown above involve package(s) which may need
to
!!! be rebuilt in order to solve the conflict(s). However, the
following
!!! package(s) cannot be rebuilt for the reason(s) shown:

  (dev-vcs/git-2.45.1-1:0/0::gentoo, installed): ebuild is masked or
  unavailable


It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously.  If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.


!!! The following installed packages are masked:
- xfce-base/xfconf-4.19.2::gentoo (masked by: package.mask)
/var/db/repos/gentoo/profiles/package.mask:
# Micha\u0142 Górny  (2024-06-08)
# Prereleases of Xfce 4.20.  Masking upon popular request, due to
# a large number of regressions in every new release.

- dev-php/PEAR-Mail-1.5.0::gentoo (masked by: package.mask)
/var/db/repos/gentoo/profiles/package.mask:
# Viorel Munteanu  (2024-06-11)
# dev-php/pear, dev-php/PEAR-* and their reverse dependencies: mask
for removal
# in 30 days.
## they have around 40 bugs.
# Removal: 2024-07-11.  Bug #933998.

- xfce-base/libxfce4util-4.19.3::gentoo (masked by: package.mask)
- dev-php/PEAR-DB-1.11.0::gentoo (masked by: package.mask)
- dev-build/xfce4-dev-tools-4.19.1::gentoo (masked by: package.mask)
- dev-php/PEAR-Date-1.5.0_alpha4-r1::gentoo (masked by: package.mask)
- xfce-base/exo-4.19.0::gentoo (masked by: package.mask)
- dev-php/PEAR-XML_Serializer-0.21.0-r1::gentoo (masked by:
- package.mask)
- xfce-base/libxfce4ui-4.19.5::gentoo (masked by: package.mask)
- dev-php/PEAR-XML_Parser-1.3.8-r1::gentoo (masked by: package.mask)
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
I tried with backtrack=1000, with no different results.

Thanks in advance for any suggestions.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com

[gentoo-user] how to record mp3 stream

[John Covici]

Hi.  I am interested in recording an mp3 stream in the background and
being able to specify start/stop time, etc.

I looked at Google, but just found a package called audio-recorder,
but I am not sure its currently maintained and its not in the gentoo
packages.

Thanks in advance for any suggestions.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Michael wrote:
> This is good! :D
> Edit the section below by adding the PreferredMode line:
>
> Section "Monitor"
> Identifier "Monitor0"
> VendorName "Unknown"
> ModelName  "LG Electronics W2253"
> HorizSync   30.0 - 83.0
> VertRefresh 56.0 - 61.0
> Option "PreferredMode"   "1920x1080_60.00"
> Option "DPMS"
> EndSection
>
> Save it, then check if you get a consistent result when you restart the DM, 
> or 
> reboot.
>
> If it is still playing up you need to show the Xorg.0.log while the monitor 
> is 
> working with the nvidia driver, to see which Modeline it uses and add this in 
> the "Monitor" section too, above the "PreferredMode" entry.
>
> If none of this works reliably, then you have to capture the EDID table while 
> the monitor is working, save it in a file and set nvidia-settings to use it 
> hereafter.  However, if you will NOT be using this monitor for much longer 
> this would be an exercise only to make you feel good for beating it into 
> submission!  LOL!

OK.  First time, it worked.  Second time, it came up but in low res. 
Plasma was working to, both times.  So, I opened the Nvidia GUI and told
it to safe a new config with it in hi res mostly just to see what it
would add if anything.  It did.  The only change I could see was it
added metamodes options like this:

Section "Screen"

# Removed Option "metamodes" "nvidia-auto-select +0+0"
    Identifier "Screen0"
    Device "Device0"
    Monitor    "Monitor0"
    DefaultDepth    24
    Option "Stereo" "0"
    Option "nvidiaXineramaInfoOrder" "DP-3"
    Option "metamodes" "1920x1080 +0+0"
#    Option "metamodes" "1920x1080 +0+0; 1024x768_60 +0+0"
    Option "SLI" "Off"
    Option "MultiGPU" "Off"
    Option "BaseMosaic" "off"
    SubSection "Display"
    Depth   24
    EndSubSection
EndSection


As you can see, I removed the low res part, don't want that anyway, and
it seems to work more often but still fails a lot.  So, I removed the
metamodes Nvidia added.  Then it didn't come up at all, sddm or
anything, when I restarted DM.  I thought it adding your setting to
another section might help.  Guess not.  With the following removed, it
seems to do a little better but still can't depend on it to work.

Section "Screen"
#    Option "nvidiaXineramaInfoOrder" "DP-3"
#    Option "metamodes" "1920x1080 +0+0"
#    Option "metamodes" "1920x1080 +0+0; 1024x768_60 +0+0"


Basically, it is doing like it always has.  Most of the time, it doesn't
work.  Sometimes it does.  To be honest tho, I still wonder if it even
reads the file.  When I change something, I'd expect something
different.  Generally, it doesn't seem to affect anything unless I
reboot completely.  Sometimes I'm not sure it does then either.  So, I
think this old monitor just has a issue.  Maybe I need to rebuild some
more of the power supply or something in case it is providing bad power
to the parts that talks to the puter.  Either way, if the new one works,
I just don't think this old monitor is going to work correctly no matter
what we throw at it. 

I will saw this, we threw the kitchen sink at it.  I think this is one
of the longest threads I've seen in a long while.  o_O 

Dale

:-) 

P. S.  Monitor updated.  Now it says tomorrow.  It's in the right place
to do so.  It's at the Memphis hub.  Usually, it comes from there to the
local distribution point and on the truck.  They sometimes deliver by
noon.  Could be a little late given it is Monday. 

Re: [gentoo-user] bash: genfun_has_readline

[Peter Humphrey]

On Sunday, 30 June 2024 18:51:20 BST David M. Fellows wrote:
> >Hello list,
> >
> >I'm seeing this every time I chroot into my rescue system:
> >
> ># chroot /mnt/rescue /bin/bash
> >bash: genfun_has_readline: command not found
> >
> >Google results suggest that the genfun is defined in the new version of
> >bashrc, but it isn't on any of my systems, even one ~amd64.
> >
> >The same thing happened when I started a new build from stage-3, when I
> >chrooted into the nascent system.
> >
> >Clues, anyone?
> 
> https://bugs.gentoo.org/935016
> 
> May have relevant information.

Thanks, but it doesn't help. What it says doesn't apply here.

-- 
Regards,
Peter.

Re: [gentoo-user] bash: genfun_has_readline

[David M. Fellows]

>Hello list,
>
>I'm seeing this every time I chroot into my rescue system:
>
># chroot /mnt/rescue /bin/bash
>bash: genfun_has_readline: command not found
>
>Google results suggest that the genfun is defined in the new version of 
>bashrc, 
>but it isn't on any of my systems, even one ~amd64.
>
>The same thing happened when I started a new build from stage-3, when I 
>chrooted into the nascent system.
>
>Clues, anyone?

https://bugs.gentoo.org/935016

May have relevant information.

DaveF
>
>-- 
>Regards,
>Peter.
>
>
>
>

[gentoo-user] bash: genfun_has_readline

[Peter Humphrey]

Hello list,

I'm seeing this every time I chroot into my rescue system:

# chroot /mnt/rescue /bin/bash
bash: genfun_has_readline: command not found

Google results suggest that the genfun is defined in the new version of bashrc, 
but it isn't on any of my systems, even one ~amd64.

The same thing happened when I started a new build from stage-3, when I 
chrooted into the nascent system.

Clues, anyone?

-- 
Regards,
Peter.

Re: [gentoo-user] cinnamon-screensaver issue

[Jacques Montier]

Le dim. 30 juin 2024 à 15:03, Eli Schwartz  a écrit :

> On 6/30/24 6:57 AM, Jacques Montier wrote:
> > Hello all,
> >
> > In the cinnamon xscreensaver preferences, time before the xscreensaver
> > starts is set to 5min.
> > After those 5 min, instead of the screensaver, all my working
> applications
> > stopped, the cinnamon xsession exit, and i just get the sddm screen for
> > logging...
> >
> > Manually launching with cinnamon-screensaver-command, it works fine.
> >
> > I really don't know what's going on.
> >
> > Attached journalctl extract.
> >
> > Installed version cinnamon :
> > gnome-extra/cinnamon-6.0.4
> > gnome-extra/cinnamon-screensaver-6.0.3
> >
> > Thanks a lot for your help.
>
>
> Waiting for https://bugs.gentoo.org/935054 to stabilize. Consider
> package.accept_keywords for cinnamon-session in the meantime.
>
> See also https://github.com/gentoo/gentoo/pull/36989
>
>
> --
> Eli Schwartz
>


Hello Eli,

I upgraded to (~) cinnamon-session-6.0.4 and it works fine.

Thanks very much.

Cheers,

--
Jacques

Re: [gentoo-user] cinnamon-screensaver issue

[Eli Schwartz]

On 6/30/24 6:57 AM, Jacques Montier wrote:
> Hello all,
> 
> In the cinnamon xscreensaver preferences, time before the xscreensaver
> starts is set to 5min.
> After those 5 min, instead of the screensaver, all my working applications
> stopped, the cinnamon xsession exit, and i just get the sddm screen for
> logging...
> 
> Manually launching with cinnamon-screensaver-command, it works fine.
> 
> I really don't know what's going on.
> 
> Attached journalctl extract.
> 
> Installed version cinnamon :
> gnome-extra/cinnamon-6.0.4
> gnome-extra/cinnamon-screensaver-6.0.3
> 
> Thanks a lot for your help.


Waiting for https://bugs.gentoo.org/935054 to stabilize. Consider
package.accept_keywords for cinnamon-session in the meantime.

See also https://github.com/gentoo/gentoo/pull/36989


-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-user] cinnamon-screensaver issue

[Jacques Montier]

Hello all,

In the cinnamon xscreensaver preferences, time before the xscreensaver
starts is set to 5min.
After those 5 min, instead of the screensaver, all my working applications
stopped, the cinnamon xsession exit, and i just get the sddm screen for
logging...

Manually launching with cinnamon-screensaver-command, it works fine.

I really don't know what's going on.

Attached journalctl extract.

Installed version cinnamon :
gnome-extra/cinnamon-6.0.4
gnome-extra/cinnamon-screensaver-6.0.3

Thanks a lot for your help.

Cheers,


*--*
*Jacques*
juin 29 20:52:12 GentooLinux org.cinnamon.ScreenSaver[3569]: Loading 
AccountsService
juin 29 20:52:12 GentooLinux org.cinnamon.ScreenSaver[3569]: Fractional scaling 
active: False
juin 29 20:52:12 GentooLinux cinnamon-killer-daemon[3590]: Bound Cinnamon 
restart to Escape.
juin 29 20:52:12 GentooLinux org.cinnamon.ScreenSaver[3569]: Trying to connect 
to logind...
juin 29 20:52:12 GentooLinux dbus-daemon[1072]: [session uid=1000 pid=1072 
pidfd=5] Successfully activated service 'org.cinnamon.ScreenSaver'
juin 29 20:52:12 GentooLinux org.cinnamon.ScreenSaver[3569]: Starting 
screensaver...
juin 29 20:52:12 GentooLinux dbus-daemon[1072]: [session uid=1000 pid=1072 
pidfd=5] Activating service name='org.cinnamon.CalendarServer' requested by 
':1.188' (uid=1000 pi>
juin 29 20:52:12 GentooLinux NetworkManager[929]:   [1719687132.4846] 
agent-manager: agent[79132a7687efe89c,:1.346/org.freedesktop.nm-applet/1000]: 
agent registered
juin 29 20:52:12 GentooLinux org.cinnamon.ScreenSaver[3569]: Cinnamon 
Screensaver support not found in current theme - adding some...
juin 29 20:52:12 GentooLinux cinnamon-session[3388]: WARNING: t+2.29526s: 
Detected that screensaver has appeared on the bus
juin 29 20:52:12 GentooLinux org.cinnamon.ScreenSaver[3569]: AccountsService 
ready
juin 29 20:52:12 GentooLinux org.cinnamon.ScreenSaver[3569]: Successfully using 
logind
juin 29 20:52:12 GentooLinux dbus-daemon[1072]: [session uid=1000 pid=1072 
pidfd=5] Successfully activated service 'org.cinnamon.CalendarServer'
juin 29 20:52:20 GentooLinux systemd[1]: Stopping User Manager for UID 219...
juin 29 20:52:20 GentooLinux systemd[3253]: Activating special unit Exit the 
Session...
juin 29 20:52:20 GentooLinux systemd[3253]: Stopped target Main User Target.
juin 29 20:52:20 GentooLinux wireplumber[3276]: m-dbus-connection: 
 DBus connection closed: Underlying GIOStream 
returned 0 bytes on an asy>
juin 29 20:52:20 GentooLinux gvfsd[3301]: A connection to the bus can't be made
juin 29 20:52:20 GentooLinux systemd[3253]: Stopping D-Bus User Message Bus...
juin 29 20:52:20 GentooLinux wireplumber[3276]: m-dbus-connection: 
 Trying to reconnect after core sync
juin 29 20:52:20 GentooLinux systemd[3253]: Stopping Virtual filesystem 
service...
juin 29 20:52:20 GentooLinux systemd[3253]: Stopping PipeWire PulseAudio...
juin 29 20:52:20 GentooLinux systemd[3253]: Stopping sandboxed app permission 
store...
juin 29 20:52:20 GentooLinux systemd[3253]: Stopped D-Bus User Message Bus.
juin 29 20:52:20 GentooLinux systemd[3253]: Stopped Virtual filesystem service.
juin 29 20:52:20 GentooLinux systemd[3253]: Stopped PipeWire PulseAudio.
juin 29 20:52:20 GentooLinux systemd[3253]: xdg-permission-store.service: Main 
process exited, code=exited, status=1/FAILURE
juin 29 20:52:20 GentooLinux systemd[3253]: xdg-permission-store.service: 
Failed with result 'exit-code'.
juin 29 20:52:20 GentooLinux systemd[3253]: Stopped sandboxed app permission 
store.
juin 29 20:52:20 GentooLinux systemd[3253]: Stopping Multimedia Service Session 
Manager...
juin 29 20:52:20 GentooLinux wireplumber[3276]: wireplumber: stopped by signal: 
Complété
juin 29 20:52:20 GentooLinux wireplumber[3276]: wireplumber: disconnected from 
pipewire
juin 29 20:52:20 GentooLinux systemd[3253]: Stopped Multimedia Service Session 
Manager.
juin 29 20:52:20 GentooLinux systemd[3253]: Stopping PipeWire Multimedia 
Service...
juin 29 20:52:20 GentooLinux systemd[3253]: Stopped PipeWire Multimedia Service.
juin 29 20:52:20 GentooLinux systemd[3253]: Removed slice User Core Session 
Slice.
juin 29 20:52:20 GentooLinux systemd[3253]: Stopped target Basic System.
juin 29 20:52:20 GentooLinux systemd[3253]: Stopped target Paths.
juin 29 20:52:20 GentooLinux systemd[3253]: Stopped target Sockets.
juin 29 20:52:20 GentooLinux systemd[3253]: Stopped target Timers.
juin 29 20:52:20 GentooLinux systemd[3253]: Closed D-Bus User Message Bus 
Socket.
juin 29 20:52:20 GentooLinux systemd[3253]: Closed PipeWire PulseAudio.
juin 29 20:52:20 GentooLinux systemd[3253]: Closed PipeWire Multimedia System 
Sockets.
juin 29 20:52:20 GentooLinux systemd[3253]: Removed slice User Application 
Slice.
juin 29 20:52:20 GentooLinux systemd[3253]: Reached target Shutdown.
juin 29 20:52:20 GentooLinux systemd[3253]: Finished Exit the Session.
juin 29 20:52:20 GentooLinux systemd[3253]: Reached target Exit the Session.
juin 29 20:52:20 GentooLinux (sd-pam)[3254]: 

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Michael]

On Sunday, 30 June 2024 10:36:16 BST Dale wrote:

> Here's a little update.  First, Kubuntu wiped my Gentoo install from
> being able to boot it.  I had to boot the Gentoo USB image, mount
> everything and reinstall grub/EFI stuff.  I got it back and now I can
> boot either one by selecting it in the BIOS. 
> 
> Second.  I decided to annoy the heck out of that thing.  I logged in
> over ssh and I kept restarting DM.  Took me several dozen tries but
> eventually I got KDE to come up, plasma and all.  I opened the Nvidia
> GUI and got it to save the xorg.conf file.  It's different but it has a
> lot of info now.

This is good!  :D

Edit the section below by adding the PreferredMode line:

Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName  "LG Electronics W2253"
HorizSync   30.0 - 83.0
VertRefresh 56.0 - 61.0
Option "PreferredMode"   "1920x1080_60.00"
Option "DPMS"
EndSection

Save it, then check if you get a consistent result when you restart the DM, or 
reboot.

If it is still playing up you need to show the Xorg.0.log while the monitor is 
working with the nvidia driver, to see which Modeline it uses and add this in 
the "Monitor" section too, above the "PreferredMode" entry.

If none of this works reliably, then you have to capture the EDID table while 
the monitor is working, save it in a file and set nvidia-settings to use it 
hereafter.  However, if you will NOT be using this monitor for much longer 
this would be an exercise only to make you feel good for beating it into 
submission!  LOL!


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Dale wrote:
> Mark Knecht wrote:
>>
>>
>> He certainly does have his hands full!
>>
>> I'm confused. (a standard state of being for me...) I thought Dale
>> reported that
>> he installed Kubuntu on an SSD - or did we just talk about that idea
>> - and he
>> said all the port problems were ironed out with the open source driver.
>>
>> What he didn't report was if he installed the nvidia-drivers in
>> Kubuntu. I 
>> personally wouldn't write off the 'old monitor' until doing at least
>> that.
>>
>> sudo apt update
>> sudo apt upgrade
>>
>> ubuntu-drivers list
>> (make sure the video-card is found)
>>
>> sudo apt install nvidia-drivers-550
>> (assuming he has a Quadro P1000 from memory)
>>
>> reboot
>>
>> Shouldn't take more than 5-10 minutes to try. No real risk as 
>> he's going to blow away the Kubuntu install anyway.
>>
>
>
> I do have Kubuntu installed on a 2.5" SSD.  I wasn't sure how to
> install and switch to the Nvidia drivers.  That was on my todo list as
> soon as I had some time.  Thing is, the new monitor may get here
> first.  I just picked a whole gallon ice cream bucket packed full of
> basil.  It's soaking in the sink now.  Dehydrator comes next.  That
> takes at least a day to complete.  On the positive side, the house
> smells really good for a day or so.  LOL 
>
> I also thought of going to boot runlevel on my main rig while in a
> console, unplug the monitor hooked to my main rig now and plug it into
> the new rig.  Then boot and see what happens.  It might work.  It's a
> newer monitor and it's a Samsung instead of a LG.  If it did work, I
> could switch and switch to new monitor when it gets here.  I plan to
> use the old Dell rig to watch TV with while I switch.  I can use the
> backup drives for that.  Moving all these drives could take a while.  O_O
>
> At least now I have the commands needed to try it tho.  That helps.  :-D 
>
> Michael, I did try the settings you posted.  I thought I tried them
> and posted a reply.  I may have missed one tho.  This is a long
> thread.  This monitor has been a serious PITA.  :-@ 
>
> Back to the basil.  Glad my meds are working pretty good.  -_O
>
> Dale
>
> :-) :-) 


Here's a little update.  First, Kubuntu wiped my Gentoo install from
being able to boot it.  I had to boot the Gentoo USB image, mount
everything and reinstall grub/EFI stuff.  I got it back and now I can
boot either one by selecting it in the BIOS. 

Second.  I decided to annoy the heck out of that thing.  I logged in
over ssh and I kept restarting DM.  Took me several dozen tries but
eventually I got KDE to come up, plasma and all.  I opened the Nvidia
GUI and got it to save the xorg.conf file.  It's different but it has a
lot of info now.  Thing is, when I logged out and back in, same thing as
before.  Sometimes it doesn't work at all, sometimes it is the wrong
resolution or plasma doesn't start up or some other problem.  Since
email wraps things, I'm attaching the xorg.conf file it generated. 
Kinda nifty.  Some are like the info Micheal posted. 

I think at this point, I'm cutting the thing off until the new monitor
comes in.  I'm dreaming of hammers, shooting it and other things that
ain't good.  :/ 

Monitor is already about 100 miles from me at a FedEx hub.  I won't be
surprised if it comes in Monday.  It could be Tuesday tho.  They could
know it will take longer for some reason or other.  It's getting close
tho.  Yes, it is 4:30AM here.  Not a good night, yet.

Dale

:-)  :-) 
root@Gentoo-1 ~ # cat /etc/X11/xorg.conf
# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 550.90.07

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 550.90.07

Section "ServerLayout"
Identifier "Layout0"
Screen  0  "Screen0" 0 0
InputDevice"Keyboard0" "CoreKeyboard"
InputDevice"Mouse0" "CorePointer"
Option "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"

# generated from data in "/etc/conf.d/gpm"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol"
Option "Device" "/dev/input/mice"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

# generated from default
Identifier "Keyboard0"
Driver "kbd"
EndSection

Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName  "LG Electronics W2253"
HorizSync   30.0 - 83.0
VertRefresh 56.0 - 61.0
Option "DPMS"
EndSection

Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName  "Quadro P1000"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor"Monitor0"
DefaultDepth24
Option "Stereo" "0"
Option "nvidiaXineramaInfoOrder" "DP-3"
Option

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Dale wrote:
> Mark Knecht wrote:
>>
>>
>> He certainly does have his hands full!
>>
>> I'm confused. (a standard state of being for me...) I thought Dale
>> reported that
>> he installed Kubuntu on an SSD - or did we just talk about that idea
>> - and he
>> said all the port problems were ironed out with the open source driver.
>>
>> What he didn't report was if he installed the nvidia-drivers in
>> Kubuntu. I 
>> personally wouldn't write off the 'old monitor' until doing at least
>> that.
>>
>> sudo apt update
>> sudo apt upgrade
>>
>> ubuntu-drivers list
>> (make sure the video-card is found)
>>
>> sudo apt install nvidia-drivers-550
>> (assuming he has a Quadro P1000 from memory)
>>
>> reboot
>>
>> Shouldn't take more than 5-10 minutes to try. No real risk as 
>> he's going to blow away the Kubuntu install anyway.
>>
>
>
> I do have Kubuntu installed on a 2.5" SSD.  I wasn't sure how to
> install and switch to the Nvidia drivers.  That was on my todo list as
> soon as I had some time.  Thing is, the new monitor may get here
> first.  I just picked a whole gallon ice cream bucket packed full of
> basil.  It's soaking in the sink now.  Dehydrator comes next.  That
> takes at least a day to complete.  On the positive side, the house
> smells really good for a day or so.  LOL 
>
> I also thought of going to boot runlevel on my main rig while in a
> console, unplug the monitor hooked to my main rig now and plug it into
> the new rig.  Then boot and see what happens.  It might work.  It's a
> newer monitor and it's a Samsung instead of a LG.  If it did work, I
> could switch and switch to new monitor when it gets here.  I plan to
> use the old Dell rig to watch TV with while I switch.  I can use the
> backup drives for that.  Moving all these drives could take a while.  O_O
>
> At least now I have the commands needed to try it tho.  That helps.  :-D 
>
> Michael, I did try the settings you posted.  I thought I tried them
> and posted a reply.  I may have missed one tho.  This is a long
> thread.  This monitor has been a serious PITA.  :-@ 
>
> Back to the basil.  Glad my meds are working pretty good.  -_O
>
> Dale
>
> :-) :-) 


Here's a little update.  First, Kubuntu wiped my Gentoo install from
being able to boot it.  I had to boot the Gentoo USB image, mount
everything and reinstall grub/EFI stuff.  I got it back and now I can
boot either one by selecting it in the BIOS. 

Second.  I decided to annoy the heck out of that thing.  I logged in
over ssh and I kept restarting DM.  Took me several dozen tries but
eventually I got KDE to come up, plasma and all.  I opened the Nvidia
GUI and got it to save the xorg.conf file.  It's different but it has a
lot of info now.  Thing is, when I logged out and back in, same thing as
before.  Sometimes it doesn't work at all, sometimes it is the wrong
resolution or plasma doesn't start up or some other problem.  Since
email wraps things, I'm attaching the xorg.conf file it generated. 
Kinda nifty.  Some are like the info Micheal posted. 

I think at this point, I'm cutting the thing off until the new monitor
comes in.  I'm dreaming of hammers, shooting it and other things that
ain't good.  :/ 

Monitor is already about 100 miles from me at a FedEx hub.  I won't be
surprised if it comes in Monday.  It could be Tuesday tho.  They could
know it will take longer for some reason or other.  It's getting close
tho. 

Dale

:-)  :-) 
root@Gentoo-1 ~ # cat /etc/X11/xorg.conf
# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 550.90.07

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 550.90.07

Section "ServerLayout"
Identifier "Layout0"
Screen  0  "Screen0" 0 0
InputDevice"Keyboard0" "CoreKeyboard"
InputDevice"Mouse0" "CorePointer"
Option "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"

# generated from data in "/etc/conf.d/gpm"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol"
Option "Device" "/dev/input/mice"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

# generated from default
Identifier "Keyboard0"
Driver "kbd"
EndSection

Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName  "LG Electronics W2253"
HorizSync   30.0 - 83.0
VertRefresh 56.0 - 61.0
Option "DPMS"
EndSection

Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName  "Quadro P1000"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor"Monitor0"
DefaultDepth24
Option "Stereo" "0"
Option "nvidiaXineramaInfoOrder" "DP-3"
Option "metamodes" "nvidia-auto-select +0+0"

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Mark Knecht wrote:
>
>
> On Sat, Jun 29, 2024 at 3:15 PM Michael  > wrote:
> >
> > On Saturday, 29 June 2024 21:30:59 BST Dale wrote:
> > > I booted the rig up and decided to try something.  Once it was
> booted, I
> > > logged in from my main rig via ssh.  I then typed in the command to
> > > start DM.  It started and looked OK.  Then I just up arrow and changed
> > > it to restart the DM.  I restarted DM back to back several times, more
> > > than a dozen.  Sometimes it wouldn't work, sometimes it would be low
> > > resolution and sometimes it would come up and look like it should, hi
> > > res and all.  I also tried logging in when it was working and I could
> > > login.  The biggest thing I noticed, it never came up fully.  Most of
> > > the time it came up in hi res but no plasma.  A few times it was a low
> > > res screen and no plasma.  Looked like maybe 720P or less.
> > >
> > > The thing is, it didn't fully come up even once.  It was always
> lacking
> > > plasma at least.  Some of the time, it was low res.  Several
> times, the
> > > monitor would go black and cut off completely.  It would go to sleep.
> > > If the new monitor works, I'm thinking Micheal is right.  The monitor
> > > works with slower systems and the nouveau drivers on boot media.  With
> > > Nvidia on the install, hit or miss, mostly miss.  I think it has only
> > > worked fully twice.
> >
> > I think after all these attempts you have proven this monitor with
> this nvidia
> > card just won't work on its own, unless and until you try changing the
> > "Monitor" settings as I suggested in my previous message, or
> extract, store
> > and feed the monitor's EDID file to your card.
> >
> > However, you have your hands full and may want to leave this for now
> and wait
> > for the next larger and more modern monitor to show up.  Hopefully
> that will
> > work better!  :-)
>
> He certainly does have his hands full!
>
> I'm confused. (a standard state of being for me...) I thought Dale
> reported that
> he installed Kubuntu on an SSD - or did we just talk about that idea -
> and he
> said all the port problems were ironed out with the open source driver.
>
> What he didn't report was if he installed the nvidia-drivers in
> Kubuntu. I 
> personally wouldn't write off the 'old monitor' until doing at least that.
>
> sudo apt update
> sudo apt upgrade
>
> ubuntu-drivers list
> (make sure the video-card is found)
>
> sudo apt install nvidia-drivers-550
> (assuming he has a Quadro P1000 from memory)
>
> reboot
>
> Shouldn't take more than 5-10 minutes to try. No real risk as 
> he's going to blow away the Kubuntu install anyway.
>


I do have Kubuntu installed on a 2.5" SSD.  I wasn't sure how to install
and switch to the Nvidia drivers.  That was on my todo list as soon as I
had some time.  Thing is, the new monitor may get here first.  I just
picked a whole gallon ice cream bucket packed full of basil.  It's
soaking in the sink now.  Dehydrator comes next.  That takes at least a
day to complete.  On the positive side, the house smells really good for
a day or so.  LOL 

I also thought of going to boot runlevel on my main rig while in a
console, unplug the monitor hooked to my main rig now and plug it into
the new rig.  Then boot and see what happens.  It might work.  It's a
newer monitor and it's a Samsung instead of a LG.  If it did work, I
could switch and switch to new monitor when it gets here.  I plan to use
the old Dell rig to watch TV with while I switch.  I can use the backup
drives for that.  Moving all these drives could take a while.  O_O

At least now I have the commands needed to try it tho.  That helps.  :-D 

Michael, I did try the settings you posted.  I thought I tried them and
posted a reply.  I may have missed one tho.  This is a long thread. 
This monitor has been a serious PITA.  :-@ 

Back to the basil.  Glad my meds are working pretty good.  -_O

Dale

:-) :-) 

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Mark Knecht]

On Sat, Jun 29, 2024 at 3:15 PM Michael  wrote:
>
> On Saturday, 29 June 2024 21:30:59 BST Dale wrote:
> > I booted the rig up and decided to try something.  Once it was booted, I
> > logged in from my main rig via ssh.  I then typed in the command to
> > start DM.  It started and looked OK.  Then I just up arrow and changed
> > it to restart the DM.  I restarted DM back to back several times, more
> > than a dozen.  Sometimes it wouldn't work, sometimes it would be low
> > resolution and sometimes it would come up and look like it should, hi
> > res and all.  I also tried logging in when it was working and I could
> > login.  The biggest thing I noticed, it never came up fully.  Most of
> > the time it came up in hi res but no plasma.  A few times it was a low
> > res screen and no plasma.  Looked like maybe 720P or less.
> >
> > The thing is, it didn't fully come up even once.  It was always lacking
> > plasma at least.  Some of the time, it was low res.  Several times, the
> > monitor would go black and cut off completely.  It would go to sleep.
> > If the new monitor works, I'm thinking Micheal is right.  The monitor
> > works with slower systems and the nouveau drivers on boot media.  With
> > Nvidia on the install, hit or miss, mostly miss.  I think it has only
> > worked fully twice.
>
> I think after all these attempts you have proven this monitor with this
nvidia
> card just won't work on its own, unless and until you try changing the
> "Monitor" settings as I suggested in my previous message, or extract,
store
> and feed the monitor's EDID file to your card.
>
> However, you have your hands full and may want to leave this for now and
wait
> for the next larger and more modern monitor to show up.  Hopefully that
will
> work better!  :-)

He certainly does have his hands full!

I'm confused. (a standard state of being for me...) I thought Dale reported
that
he installed Kubuntu on an SSD - or did we just talk about that idea - and
he
said all the port problems were ironed out with the open source driver.

What he didn't report was if he installed the nvidia-drivers in Kubuntu. I
personally wouldn't write off the 'old monitor' until doing at least that.

sudo apt update
sudo apt upgrade

ubuntu-drivers list
(make sure the video-card is found)

sudo apt install nvidia-drivers-550
(assuming he has a Quadro P1000 from memory)

reboot

Shouldn't take more than 5-10 minutes to try. No real risk as
he's going to blow away the Kubuntu install anyway.

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Jack wrote:
> Have you tried downloading the EDID from the monitor so it can be
> loaded as firmware from disk, so the response speed of the monitor
> isn't a factor?  I had to do that once for a similar reason, but it
> was so many years ago I don't actually remember the details - in fact
> it might have been a big glass CRT  monitor where I had to get the
> edid from off the interwebs somewhere.
>

I haven't but maybe I should.  Thing is, if the new monitor that is on
the way works, I won't likely ever have this monitor on the new rig
again.  It is the smallest and oldest monitor I have.  I usually use it
during installs or on rigs I rarely use anyway.  This is mostly on the
NAS box rigs that I use to do backups with.  I only boot them once a
week and they only run for a couple hours at most.  I pitched the old
CRT monitors long ago.  Those thing produced a LOT of heat and pulled a
huge amount of power compared to the new flat screen ones. 

I just realized something.  The CPU cooler and m.2 cooler is made by the
same company.  No wonder they look so much alike.  ROFL  Oh, I did add
some thermal pad to the controller end.  It was making some contact
before but it looks like it was only touching about half of the
controller chip based on the indentation it left behind in the pad.  A
.5mm thick piece made it fairly flat between the controller and memory
chip.  It would likely work fine even under heavy use but now I know it
is going to cool very well.  I can be a little OCD on some things.  :/ 

Oh, I'm in the heat picking basil.  Dang that stuff smells good.  Almost
got a ice cream bucket full.  :-D  I'm still on the first planter.  I
got two more to go.  o_O

Dale

:-)  :-) 

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Michael]

On Saturday, 29 June 2024 21:30:59 BST Dale wrote:
> I booted the rig up and decided to try something.  Once it was booted, I
> logged in from my main rig via ssh.  I then typed in the command to
> start DM.  It started and looked OK.  Then I just up arrow and changed
> it to restart the DM.  I restarted DM back to back several times, more
> than a dozen.  Sometimes it wouldn't work, sometimes it would be low
> resolution and sometimes it would come up and look like it should, hi
> res and all.  I also tried logging in when it was working and I could
> login.  The biggest thing I noticed, it never came up fully.  Most of
> the time it came up in hi res but no plasma.  A few times it was a low
> res screen and no plasma.  Looked like maybe 720P or less. 
> 
> The thing is, it didn't fully come up even once.  It was always lacking
> plasma at least.  Some of the time, it was low res.  Several times, the
> monitor would go black and cut off completely.  It would go to sleep. 
> If the new monitor works, I'm thinking Micheal is right.  The monitor
> works with slower systems and the nouveau drivers on boot media.  With
> Nvidia on the install, hit or miss, mostly miss.  I think it has only
> worked fully twice. 

I think after all these attempts you have proven this monitor with this nvidia 
card just won't work on its own, unless and until you try changing the 
"Monitor" settings as I suggested in my previous message, or extract, store 
and feed the monitor's EDID file to your card.

However, you have your hands full and may want to leave this for now and wait 
for the next larger and more modern monitor to show up.  Hopefully that will 
work better!  :-)


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Jack]

Have you tried downloading the EDID from the monitor so it can be loaded 
as firmware from disk, so the response speed of the monitor isn't a 
factor?  I had to do that once for a similar reason, but it was so many 
years ago I don't actually remember the details - in fact it might have 
been a big glass CRT  monitor where I had to get the edid from off the 
interwebs somewhere.


On 6/29/24 4:30 PM, Dale wrote:

I booted the rig up and decided to try something.  Once it was booted, I
logged in from my main rig via ssh.  I then typed in the command to
start DM.  It started and looked OK.  Then I just up arrow and changed
it to restart the DM.  I restarted DM back to back several times, more
than a dozen.  Sometimes it wouldn't work, sometimes it would be low
resolution and sometimes it would come up and look like it should, hi
res and all.  I also tried logging in when it was working and I could
login.  The biggest thing I noticed, it never came up fully.  Most of
the time it came up in hi res but no plasma.  A few times it was a low
res screen and no plasma.  Looked like maybe 720P or less.

The thing is, it didn't fully come up even once.  It was always lacking
plasma at least.  Some of the time, it was low res.  Several times, the
monitor would go black and cut off completely.  It would go to sleep.
If the new monitor works, I'm thinking Micheal is right.  The monitor
works with slower systems and the nouveau drivers on boot media.  With
Nvidia on the install, hit or miss, mostly miss.  I think it has only
worked fully twice.

The last update showed the monitor a couple states away.  FedEx is
pretty speedy.  I think if things move well, it could be here Monday.
It still shows Tuesday tho.  Given I been dealing with this for a week
or so now, another few days isn't a big deal.  Plus, I'll have a really
nice large monitor for these old eyes.  o_o

I took meds last night.  I didn't wake up in time to pick my basil
again.  I got three planters of it that need picking.  It's hot and
humid outside.  Try again in the morning.  That basil sure is good.
Even opening the jar smells awesome.  Nothing like the store bought stuff.

I finally uploaded some pics.  Some are while the rig is running.  You
can see the LEDs on the memory stick lit up.  Some are components.
Also, there is a couple of the little m.2 stick cooler.  I think that
little thing is so cute.  Kinda looks like the CPU cooler, just
smaller.  m.2 sticks runs at just above 100F even when pretty busy.
Very effective.  :-D  This is a link to the gallery or whatever.

https://postimg.cc/gallery/w6HQp83

Just imagine that in a Fractal Design Define XL case now.  Dang that
case is big.  It's a hair larger than my Cooler Master HAF-932 which is
a awesome case.  Oh, I also finally fixed the power on light on the
front.  I hooked the wires up backwards.  LEDs never work well when
connected up wrong.  LOL

Dale

:-)  :-)

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

I booted the rig up and decided to try something.  Once it was booted, I
logged in from my main rig via ssh.  I then typed in the command to
start DM.  It started and looked OK.  Then I just up arrow and changed
it to restart the DM.  I restarted DM back to back several times, more
than a dozen.  Sometimes it wouldn't work, sometimes it would be low
resolution and sometimes it would come up and look like it should, hi
res and all.  I also tried logging in when it was working and I could
login.  The biggest thing I noticed, it never came up fully.  Most of
the time it came up in hi res but no plasma.  A few times it was a low
res screen and no plasma.  Looked like maybe 720P or less. 

The thing is, it didn't fully come up even once.  It was always lacking
plasma at least.  Some of the time, it was low res.  Several times, the
monitor would go black and cut off completely.  It would go to sleep. 
If the new monitor works, I'm thinking Micheal is right.  The monitor
works with slower systems and the nouveau drivers on boot media.  With
Nvidia on the install, hit or miss, mostly miss.  I think it has only
worked fully twice. 

The last update showed the monitor a couple states away.  FedEx is
pretty speedy.  I think if things move well, it could be here Monday. 
It still shows Tuesday tho.  Given I been dealing with this for a week
or so now, another few days isn't a big deal.  Plus, I'll have a really
nice large monitor for these old eyes.  o_o

I took meds last night.  I didn't wake up in time to pick my basil
again.  I got three planters of it that need picking.  It's hot and
humid outside.  Try again in the morning.  That basil sure is good. 
Even opening the jar smells awesome.  Nothing like the store bought stuff. 

I finally uploaded some pics.  Some are while the rig is running.  You
can see the LEDs on the memory stick lit up.  Some are components. 
Also, there is a couple of the little m.2 stick cooler.  I think that
little thing is so cute.  Kinda looks like the CPU cooler, just
smaller.  m.2 sticks runs at just above 100F even when pretty busy. 
Very effective.  :-D  This is a link to the gallery or whatever. 

https://postimg.cc/gallery/w6HQp83

Just imagine that in a Fractal Design Define XL case now.  Dang that
case is big.  It's a hair larger than my Cooler Master HAF-932 which is
a awesome case.  Oh, I also finally fixed the power on light on the
front.  I hooked the wires up backwards.  LEDs never work well when
connected up wrong.  LOL 

Dale

:-)  :-) 

[gentoo-user] Re: Can't get the GUI to stay up for more than a minute or so before crashing

[Grant Edwards]

On 2024-06-28, Dale  wrote:

> Before I ran out of steam this morning, I tried the nouveau drivers
> again.  I never can remember how to spell that. :/  I unmerged the
> nvidia drivers to do this.  I used the in tree nouveau drivers tho.  For
> some reason, even tho I removed the nvidia package and rebooted, it
> still showed it was loading the nvidia drivers which shouldn't even
> exist.  No matter what I did, it loaded the nvidia drivers.  I could see
> it with lsmod and lspci -k.  It's like I can't get rid of the nvidia
> drivers now.

There are two parts to the nvidia drivers: the kernel module (which is
what you're seeing with lspci -k and lsmod) and the user-space Xorg
driver (which is presumably what you unmerged).

--
Grant

[gentoo-user] Re: Eliminating unwanted linux-firmware blobs.

[Grant Edwards]

On 2024-06-28, Eli Schwartz  wrote:
> On 6/28/24 6:31 PM, Peter Humphrey wrote:
>> On Friday, 28 June 2024 20:32:11 BST Tsukasa Mcp_Reznor wrote:
>> 
>>> Remove the date.so it becomes
>>> /etc/portage/savedconfig/sys-kernel/linux-firmware then it applies to all
>>> of them and not the specified version.
>>>
>>> Hope that helps
>> 
>> It certainly does. I wish I'd known that years ago: it would have saved me 
>> an 
>> awful lot of renaming.
>
> The elog message states:
>
>  * Your configuration for sys-kernel/linux-firmware-20240610-r1 has been
> saved in
>  * "/etc/portage/savedconfig/sys-kernel/linux-firmware-20240610-r1" for
> your editing pleasure.
>  * You can edit these files by hand and remerge this package with
>  * USE=savedconfig to customise the configuration.
>  * You can rename this file/directory to one of the following for
>  * its configuration to apply to multiple versions:
>  * ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/
>  * [${CTARGET}|${CHOST}|""]/${CATEGORY}/[${PF}|${P}|${PN}]
>
> I admit that this is a bit hard to analyze...

Just a bit. :)

Sure would be nice if it was mentioned on whe Wiki page. Mayber later
today...

--
Grant

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Michael wrote:
> On Thursday, 27 June 2024 23:52:25 BST Dale wrote:
>
> It's your call which drivers you should try to get it to work with first.
>
> Slow GUI response with the nouveau driver would indicate the kernel 
> configuration/firmware loading was not 100% when you trying initially, 
> because 
> it works fine when you tried it again with Kubuntu's kernel.
>
> People who use Nvidia prefer the nvidia driver in terms of performance, CUDA, 
> etc. so you may want to stick with the nvidia driver initially.  In this 
> case, 
> walk through this guide and cross-check you followed all suggestions in there 
> to configure your kernel, including disabling the nouveau driver.
>
> https://wiki.gentoo.org/wiki/NVIDIA/nvidia-drivers
>


I went through that guide.  I did find some drivers that needed to be
enabled according to the guide.  I enabled them, recompiled and
rebooted.  Nothing changed. 


> If you intend to have both nouveau and nvidia drivers and switch between 
> them, 
> then you can build nouveau as a module and implement the more convoluted 
> switching methods suggested in the next guide, but I suggest you leave this 
> for later and not confuse the two drivers:
>
> https://wiki.gentoo.org/wiki/Nouveau_%26_nvidia-drivers_switching

I wasn't intending to use both, just see if the nouveau drivers would
work and perform well.  With some tweaking maybe.  They seem to work
fine on the boot media.  If they did that on the install and with all my
monitors connected, I'd be fine with it.  I want the monitors to work. 
Nvidia would be nice given it is what I'm used to but right now, Nvidia
is on my bad list.  :-D  Keep in mind, I may end up with three monitors,
maybe four, connected.  Whatever driver I use needs to be up to the
task.  I'd think Nvidia would be, if it ever works that is.  LOL 


>
> Having checked your kernel against the nvidia-driver guide, installed your 
> updated kernel & initramfs images you should reboot.  Use 'lspci -k' and scan 
> dmesg to make sure nvidia is loaded and there were no hiccups.
>
> You've tried not having an xorg.conf and didn't work, or at least it did not 
> work reliably.  Mind you, you also tried with a xorg.conf and this didn't 
> make 
> things better.  LOL!  However, I think this was because the "Monitor" section 
> was mostly empty:
>
> Section "Monitor"
> Identifier "Monitor0"
> VendorName "Unknown"
> ModelName  "Unknown"
> Option "DPMS"
> EndSection
>
> Restart, if you need to, the display-manager until you eventually arrive at a 
> fully loaded and functioning desktop.  nvidia-smi should reveal if the driver 
> is loaded and working fully.  You can run nvidia-settings, (emerge x11-
> drivers/nvidia-drivers with USE="tools") to tweak resolution and frequency 
> for 
> your monitor, which will then be stored in your config file:
>
> https://download.nvidia.com/XFree86/Linux-x86_64/1.0-6106/nvidia-settings-user-guide.txt

I have tools enabled.  Did that long ago.  Those tools while rarely used
can come in handy. 

>
> O, while all is working as desired 'xrandr -q' will provide you with some 
> useful information for your xorg.conf:
>
> Identifier - e.g. "DisplayPort-0", or "LG Electronics W2253"
>
> Modeline - e.g. Modeline 1920x1080_60.0  138.50  1920 1968 2000 2080  1080 
> 1083 1088  +hsync +vsync
>
> and you can set a preferred option in your xorg.conf; e.g.
>
> HorizSync   15.0 - 67.0
> VertRefresh 59.0 - 60.0
> Modeline"1920x1080_60.0  138.50  1920 1968 2000 2080  1080 1083 1088 
>  +hsync +vsync"
> Option "PreferredMode" "1920x1080"_60.0"
>
> or some such.


This is the output of xrandr and nvidia-settings.


root@Gentoo-1 ~ # nvidia-settings -q all

ERROR: The control display is undefined; please run `nvidia-settings
--help` for usage information.

root@Gentoo-1 ~ # xrandr -q
Can't open display
root@Gentoo-1 ~ #


At one point, the nvidia command spit out a LOT of info.  I scrolled
through it and saw nothing that looked like a error.  Thing is, I can't
get it back now.  The xrandr command also spit out a little info.  For
some reason, after a reboot and the screen being like it was, it shows
that above now.  I have DM running, logged into KDE but no plasma. 
Resolution looks correct.  I think if plasma was working, it would be
normal.  A 'ps aux | grep plasma' shows it is running.  There is nothing
on the screen tho.  Not even one dot.  I left a Konsole window open the
last time it worked.  That's how I know it is up.  Otherwise, I'd have a
black screen and nothing else. 


>
> If the above won't do it, you can capture the monitor's EDID while it is 
> working - you can use nvidia-settings again:
>
> https://nvidia.custhelp.com/app/answers/detail/a_id/3571/~/managing-a-display-edid-on-linux
>
> There's a more manual way to do this too:
>
> find /sys |grep -i edid
>
> then copy the corresponding file to /lib/firmware/LG/W2253_edid.bin
>
> and add it to your kernel before you recompile it:
>

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Mark Knecht wrote:
>
>
> On Fri, Jun 28, 2024 at 2:41 PM Dale  > wrote:
> 
> > Doing that was actually not much trouble.  I booted, changed
> something just in case it rebooted and went back for some reason but
> would change something on the screen.  Usually, I change the page on
> the KDE welcome screen to like page 4 or something.  If it were to
> restart the GUI or anything, it would go back to page 1.  Anyway, once
> booted, I'd go do something else for a while.  Then when I came back,
> shutdown, change port and repeat.
> >
> > To Micheal's point tho, I suspect the boot media I'm using is slow
> enough, loading from a USB stick instead of a m.2 drive, that it also
> is able to get the info needed, most likely from the monitor, and work
> like it should.  This could literally be a system that is just going
> to fast.  By the time the monitor gets the request, the computer has
> already moved on except for those rare occasions where it works.
> >
> > I have a 2.5" SSD drive.  I actually mounted it in the system
> already just not hooked up to power or data cables.  I could install
> Kubuntu on that easily.  If I get the steam up, I just may do that. 
> Between working on this new build, my sis-n-law being sick, I just had
> to much going on for to long.  Just a bit ago I walked up a very steep
> hill to take watermelons in the house for her.  I can walk up faster
> than I can drive up.  No other powered vehicle I can use.  Car and
> feet is all I got.  Still, that walk up the hill and carrying
> watermelons up the steps took my energy level down a few more
> notches.  Thank goodness for my meds.  At least my back isn't so angry
> at me.
> >
> > I just hope this new monitor works out of the box, and doesn't get
> damaged in shipping.  ;-)
> >
> > Dale
> >
> > :-)  :-)
> >
> > P. S.  I'm pretty sure the recent upgrade put my main rig on KDE6. 
> I had some clashes with lxqt or something to the point I uninstalled
> it, did the KDE update and then added lxqt? back.  I still had to work
> out some issues.  So far, it is working OK.  No problems or anything
> except for losing my weather thingy on the bottom panel.  I'm sure
> that will be updated soon.  May do the same on the new rig if I get
> time.  Not that I can test it or anything tho.  LOL
>
> My point about putting KDE on a drive and really running it is that
> you can install all the non-standard drivers, which NVidia is part of,
> which I'm not sure is totally supported when running in the Try It
> mode from boot media. Once installed and booted from the SSD then
> really use the system and figure out what's going on with these ports.
> There is still a small possibility in my mind that this is something
> about Quadro cards which were designed for a different market and that
> possibly haven't been as well tested in the consumer or Gentoo arena. 
>
> You have a lot going on so ask questions if you need me. I'm always
> lurking around somewhere.
>
> Cheers,
> Mark

I got up a little steam.  I hooked up the SSD drive and installed
Kubuntu which went very fast.  It seems all those SSD type drives are
really fast.  Anyway, when I booted up the first time, it went straight
to KDE and it was like it should be, resolution, plasma and all. 
Kubuntu isn't half bad.  I just like a source based distro.  Since it
uses the nouveau drivers tho, I'm not to surprised it worked.  If they
had worked this well on Gentoo, I would have used them.  Thing was awful
tho. 

I'll search around and see if I can figure out how to switch to nvidia
drivers.  I figured out how to install the software to install
software.  That sounds weird.  :/  Anyway, I found the nvidia drivers
but wasn't sure what to do after they were installed.  There is no
xorg.conf file. 

I also tried to get some log info, all I found was Xorg and sddm.  We
agree that sddm is working.  The Xorg file looked like one I posted from
something else.  Not sure it would help to post that monster. 

That's the update for now.  May work on it more later on. 

Dale

:-)  :-) 

Re: [gentoo-user] Eliminating unwanted linux-firmware blobs.

[Eli Schwartz]

On 6/28/24 6:31 PM, Peter Humphrey wrote:
> On Friday, 28 June 2024 20:32:11 BST Tsukasa Mcp_Reznor wrote:
> 
>> Remove the date.so it becomes
>> /etc/portage/savedconfig/sys-kernel/linux-firmware then it applies to all
>> of them and not the specified version.
>>
>> Hope that helps
> 
> It certainly does. I wish I'd known that years ago: it would have saved me an 
> awful lot of renaming.


The elog message states:


 * Your configuration for sys-kernel/linux-firmware-20240610-r1 has been
saved in
 * "/etc/portage/savedconfig/sys-kernel/linux-firmware-20240610-r1" for
your editing pleasure.
 * You can edit these files by hand and remerge this package with
 * USE=savedconfig to customise the configuration.
 * You can rename this file/directory to one of the following for
 * its configuration to apply to multiple versions:
 * ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/
 * [${CTARGET}|${CHOST}|""]/${CATEGORY}/[${PF}|${P}|${PN}]


I admit that this is a bit hard to analyze...


-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Eliminating unwanted linux-firmware blobs.

[Peter Humphrey]

On Friday, 28 June 2024 20:32:11 BST Tsukasa Mcp_Reznor wrote:

> Remove the date.so it becomes
> /etc/portage/savedconfig/sys-kernel/linux-firmware then it applies to all
> of them and not the specified version.
> 
> Hope that helps

It certainly does. I wish I'd known that years ago: it would have saved me an 
awful lot of renaming.

-- 
Regards,
Peter.

Re: [gentoo-user] bashrc and setting PS1 variable heads up.

[Dale]

Peter Humphrey wrote:
> On Friday, 28 June 2024 08:32:44 BST Dale wrote:
>
>> I did a major upgrade and found out I had a lot of config files to
>> update.  I performed those updates, while losing some of my settings. 
>> Anyway, I figured out how to set the alias variables.  Simple enough. 
>> Create a file and list them in the file.  The PS1 is different because
>> it usually determines if a user is root or not and gives a different
>> prompt.  That requires a little bit of scripting, which most know is a
>> huge weak point for me. 
> I thought the proper place to define aliases was in /etc/profile.d/
> profile_aliases.sh. That's where I have mine, anyway.
>
> PS1 is set in /etc/bash/bashrc.d/10-gentoo-color.bash, as you say. I change 
> the prompt colours in there, in the case of the little rescue system I have 
> on 
> each machine. That's so that I can see which system I'm logged-on to (I 
> maintain the rescue system by chrooting into it from the main system, and 
> it's 
> far too easy to make mistakes without that precaution).
>


Way back when I first wanted to change mine, it was done in bashrc. 
According to searches, lots of people change it there but lots also do
it in other places, some in user directories.  Personal preference I
guess. 

Mostly, I wanted to give a heads up to those who set it the way I do and
that there is a clash if set in another file.  When I couldn't login at
all, I got kinda worried.  It made several things start acting weird. 
If a person sees the post and knows to check if that file exists, then
it could save someone else some issues.  At first, I couldn't understand
the reason it wasn't working.  I think when I ran dispatch-update, that
really started something.  One of the files updated was bashrc.  It
seems the way history is stored changed.  I gotta read up on that
again.  Sounds like it records commands as they are ran now instead of
when you logout.  I'm not sure.  I kinda had other issues to deal with
at the time.  ;-)  If so, that could be a good thing given I use Konsole
and sometimes have 7, 8 or more tabs open doing different things.  I'd
like them all recorded not just the last tab I close. 

I do wish someone would create a wiki page that shows the different ways
to do this sort of things with the new way being included.  Some may
want to do it my way but some may want to do it your way or some other
way for various reasons.  Right now, I don't see anything that details
this sort of thing on the wiki.  Maybe my search terms was bad but one
of them was bashrc. 

Time to wash dishes and heat up supper.  Gotta throw some coal in the
firebox.  Build up some steam.  -_O

Dale

:-)  :-) 

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Mark Knecht]

On Fri, Jun 28, 2024 at 2:41 PM Dale  wrote:

> Doing that was actually not much trouble.  I booted, changed something
just in case it rebooted and went back for some reason but would change
something on the screen.  Usually, I change the page on the KDE welcome
screen to like page 4 or something.  If it were to restart the GUI or
anything, it would go back to page 1.  Anyway, once booted, I'd go do
something else for a while.  Then when I came back, shutdown, change port
and repeat.
>
> To Micheal's point tho, I suspect the boot media I'm using is slow
enough, loading from a USB stick instead of a m.2 drive, that it also is
able to get the info needed, most likely from the monitor, and work like it
should.  This could literally be a system that is just going to fast.  By
the time the monitor gets the request, the computer has already moved on
except for those rare occasions where it works.
>
> I have a 2.5" SSD drive.  I actually mounted it in the system already
just not hooked up to power or data cables.  I could install Kubuntu on
that easily.  If I get the steam up, I just may do that.  Between working
on this new build, my sis-n-law being sick, I just had to much going on for
to long.  Just a bit ago I walked up a very steep hill to take watermelons
in the house for her.  I can walk up faster than I can drive up.  No other
powered vehicle I can use.  Car and feet is all I got.  Still, that walk up
the hill and carrying watermelons up the steps took my energy level down a
few more notches.  Thank goodness for my meds.  At least my back isn't so
angry at me.
>
> I just hope this new monitor works out of the box, and doesn't get
damaged in shipping.  ;-)
>
> Dale
>
> :-)  :-)
>
> P. S.  I'm pretty sure the recent upgrade put my main rig on KDE6.  I had
some clashes with lxqt or something to the point I uninstalled it, did the
KDE update and then added lxqt? back.  I still had to work out some
issues.  So far, it is working OK.  No problems or anything except for
losing my weather thingy on the bottom panel.  I'm sure that will be
updated soon.  May do the same on the new rig if I get time.  Not that I
can test it or anything tho.  LOL

My point about putting KDE on a drive and really running it is that you can
install all the non-standard drivers, which NVidia is part of, which I'm
not sure is totally supported when running in the Try It mode from boot
media. Once installed and booted from the SSD then really use the system
and figure out what's going on with these ports. There is still a small
possibility in my mind that this is something about Quadro cards which were
designed for a different market and that possibly haven't been as well
tested in the consumer or Gentoo arena.

You have a lot going on so ask questions if you need me. I'm always lurking
around somewhere.

Cheers,
Mark

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Mark Knecht wrote:
>
>
> On Thu, Jun 27, 2024 at 10:18 PM Dale  > wrote:
> >
> > Mark Knecht wrote:
> >
> >
> >
> > On Thu, Jun 27, 2024 at 4:01 PM Dale  > wrote:
> > 
> > >
> > > I think the rig and video card are fine.  I did try a different
> card and version of nvidia drivers once tho.  Same thing.  At first, I
> tried the nouveau drivers.  All the bootable media uses that driver. 
> When I tried it on my install, it was very slow and the mouse pointer
> was very jerky.  It was horrible.  I removed those drivers and
> installed nvidia.  Sadly, things got worse.
> > >
> > > I'll boot into Kubuntu again and see what info it has.  The ones I
> attached tho is all there was. Either it doesn't have those files or
> the files were blank.  I think Xorg and messages was all there was.
> > >
> > > I'm out of steam.  May boot Kubuntu and let it sit while I nap. 
> It worked for several minutes last time tho.  It seemed to work fine. 
> Very fast too, unlike on my install.
> > >
> >
> > Yeah, I can hear the frustration and weariness in your writing.
> However I know you are up to fixing this.
> >
> > One additional experiment you can do, and I suspect Kubuntu passes
> every time, is boot the machine with the monitor plugged into each
> port one at a time. Do complete power downs between each boot. If
> Kubuntu comes up it will really tell you a stable, tested OS has
> solved these problems. If it doesn't then that's good info also.
> >
> > I think possibly you purchased a Quadro adapter? I don't know how
> popular those are amongst this crowd but they have been very popular
> in business settings. That might make a bigger difference in terms of
> the nvidia driver vs the Open Source one.
> >
> > Good luck with your machine,
> > Mark
> >
> >
> >
> > I admit, I'm thinking about unplugging the thing and sticking it in
> the closet.  If nothing else, I'm tired of walking around this huge
> thing.  I was hoping to have switched long ago.  Usually, I look
> forward and even get excited to build a new rig.  This time, with the
> lacking slots of the original mobo and having to go way down power
> wise, I just want to make sure I have a working computer if something
> happens to my main rig.  There's not a whole lot to get excited
> about.  Having it not work, well, that doesn't help.  Poor Michael is
> trying to help but this thing is weird.  With every reboot, it does
> something differently.
> >
> > On the Kubuntu test.  I started with what the bracket shows as port
> 1.  I then went through each port until I got to port 4.  I rebooted
> in between each switch.  Even unplugged the monitor.  It worked every
> time.  During the booting of the image tho, there was several seconds
> where the screen went weird.  It had these horizontal lines on it that
> looked like stair steps.  I've seen this type of thing on other boot
> media even with my main rig and the NAS box.  It's like the image is
> in the process of loading drivers or something.  Anyway, once it came
> up tho, rock solid.
> >
> > I checked the nvidia website three times now.  Still, I wonder, am I
> using the wrong driver?  Would the wrong driver even load without a
> nasty message somewhere that is obvious?  The Nvidia website shows this:
> >
> >
> > Version:                     550.90.07
> > Release Date:             2024.6.4
> > Operating System:     Linux 64-bit
> > Language:                 English (US)
> > File Size:                   293.33 MB
> >
> > I tried that series and the earlier version as well.  Hard to
> believe that both versions would fail the same way due to a bug.  If
> someone wants to double check, Nvidia Quadro P1000 is the info.  Even
> if the selection tool is wrong, it shows up under supported products,
> for both desktops and laptops.
> >
> > I may try to the Nouveau driver thing again.  Instead of building it
> into the kernel, I may try the tree version.  Maybe it will work
> better than the one in the kernel.  One can hope.  Right now, I'm
> trying to sort through a massive update on my main rig.  Something
> broke eix.  o_O  I managed to update the config files.  Broke my
> prompt tho.  I need a hammer.  :/
> >
> > Dale
> >
> > :-)  :-)
>
> Good morning Dale,
>    OK, thanks for indulging me on the Kubuntu testing. Based on my
> understanding of the results - basically everything 'worked' but some
> of the reactions were slow - I'd say don't worry about that when
> running from boot media. I've seen a little of that myself, but it's
> never been a problem on a real install. To me it's good news that the
> Kubuntu install worked fine with all your monitors on any port you
> tried. That's GOOD news. No need to change hardware.
>
>    I know you love your disk space. I wonder if you have a partition
> somewhere that you could just install Kubuntu, install the NVidia
> drivers, get the machine updated and then study why Kubuntu has your
> hardware nailed and Gentoo doesn't? 

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Michael wrote:
> On Thursday, 27 June 2024 23:52:25 BST Dale wrote:
>> Michael wrote:
>>> [snip ...]
>>> [30.345] (II) modeset(0): [DRI2]   DRI driver: nouveau  <== Not nvidia
>>> ==
>>>
>>> [snip ...]
>>> [30.295] (II) modeset(0): Output DP-1 disconnected
>>> [30.295] (II) modeset(0): Output DP-2 disconnected
>>> [30.295] (II) modeset(0): Output DP-3 disconnected
>>> [30.295] (II) modeset(0): Output DP-4 connected
>>>
>>> What does it take to connect the cable on the FIRST port of the video
>>> card?
>> This reply may be a little odd.  I wrote some then went back and tried
>> some stuff and added info to it.  Trying to make it make sense. 
> My apologies, I didn't meant to add to your frustration.  Working with a 
> headless system is no fun when you expect to run a desktop on this thing!

I didn't take it that way.  I learned long ago that text doesn't convey
emotion very well.  I take things in the best possible way unless there
is no other way to read it.  I've just never had this much trouble
getting a computer to work.  Things have improved a lot and mostly, they
just work without much help from us.  Generally, if the correct drivers
are in the kernel and the right packages are installed, it works.  Like
magic.  Usually without a config file even. 


>
> I was just making a remark on the fact the card detects the monitor as being 
> connected to DFP-3 or DFP-5 when using the proprietary nvidia driver, but the 
> DP-4 when you used the open source nouveau driver.
>

I've noticed that the port numbers keep changing too.  I don't
understand why since the card should assign those but it is changing. 
It changes even when all I do is reboot. 


>>> At first, when it really wouldn't work, I had it on the bottom port.  At
>> some point we thought that was the last port, #4 or DP-3 in the logs,
>> and not the first port.  I moved it to the top port which is #1, we
>> thought.  It's still on that port but that port did work once and
>> resulted in "solved" being added to the subject line.  I just double
>> checked.  It is plugged in the top port.  Unless the bottom port is #1
>> like I originally thought, then it should be on port #1.  I did a search
>> and found a image that shows it puts the port number on the metal
>> bracket.  I removed the card so I could see the numbers.  The bottom
>> port is number 1 like I originally thought.  So, I had it in the right
>> port to begin with, which wasn't working either.  I'll put it back on
>> what the metal bracket says is port #1, or bottom port.  I booted up,
>> started DM, correct resolution but no plasma and background is black. 
>> Still not a functional desktop.  Partially works tho.  Time to reboot. 
>> On reboot, sddm and KDE are low resolution.  It does have a background
>> image and plasma is working.  Keep in mind, all I did is reboot.  I
>> didn't change any config file or run any commands.  Reboot again.  This
>> time, correct resolution but no plasma.  Again, all I did was reboot. 
>> No changes to anything at all.  As you can see, each time I reboot, it
>> is like rolling dice.  I suspect if I keep rebooting it will eventually
>> do the black screen and power the monitor off. 
> It seems to me the card is probing the monitor to find out what settings it 
> prefers/will work with.  This probing of the driver scrolls through a number 
> of potential Modelines, but if the monitor does not respond in a timely 
> manner 
> with its preferred resolution and frequency you get a broken result.
>
> Here are some hypotheses of mine, in absence of more concrete evidence.  The 
> old box is slower and the initialisation process takes longer.  In this 
> longer 
> processing time the monitor responds with its EDID and what not.  The card 
> receives it in a timely fashion and sets the driver accordingly.
>
> With your new box things happen faster on the PC side, but not on the monitor 
> side.  Two times out of three the synchronisation between driver and monitor 
> fails and you end up with reports of EDID not found and monitor shown as 
> disconnected in your Xorg.0.log.
>
> Having the monitor plugged in any port on the card, first or last, should not 
> make a difference, but if milli/nano-seconds count then it /might/ make a 
> difference, assuming the ports are tried sequentially by the driver.  Hence I 
> had suggested stick with the first port.  Some user reports on the interwebs 
> mentioned it, so I thought it is worth trying it.
>
> What else worth trying is  to set fixed directives for the "Monitor" section 
> in your xorg config file, or capture the EDID table into a file and feed it 
> to 
> the driver.  The former ought to work, the latter may not if the EDID itself 
> is buggy, but that's a problem to solve later if it even exists.  Either way, 
> setting explicit directives for the monitor Modeline(s) and preferred 
> resolution/frequency ought to take auto-probing out of the equation.
>

And to me, that all makes sense.  This 

[gentoo-user] Re: Eliminating unwanted linux-firmware blobs.

[Grant Edwards]

On 2024-06-28, Tsukasa Mcp_Reznor  wrote:

> Remove the date.so it becomes 
> /etc/portage/savedconfig/sys-kernel/linux-firmware
> then it applies to all of them and not the specified version.

Yes, that's the clue I was missing.

--
Grant

Re: [gentoo-user] Eliminating unwanted linux-firmware blobs.

[Tsukasa Mcp_Reznor]

Remove the date.so it becomes 
/etc/portage/savedconfig/sys-kernel/linux-firmware
then it applies to all of them and not the specified version.

Hope that helps


From: Grant Edwards 
Sent: Friday, June 28, 2024 12:17 PM
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Eliminating unwanted linux-firmware blobs.

Is there any graceful way to handle the elimination of unwanted
linux-firmware blobs when doing an update?

I believe I understand the process as outlined at
https://wiki.gentoo.org/wiki/Linux_firmware:

 1. install/upgrade sys-kernel/linux-firmware
 2. edit /etc/portage/savedconfig/sys-kernel/linux-firmware-ddmm
 3. re-emerge sys-kernel/linux-firmware with the savedcofnig USE flag

I've tried that a few times, but it's rather annoying to have to do
that every time linux-firmware gets updated.

AFAICT, the list of three or four blobs that I actually need on a
specific machine never changes.

It seems like there ought to be a way to configure that required
firmware list and have the emerge -u "just work", but I can't find
it. Have I missed something?

Yes, I know...
  Disk space is cheap.
  Premature optimization ...
  etc.

It still annoys me.

--
Grant

Re: [gentoo-user] Eliminating unwanted linux-firmware blobs.

[Waldo Lemmer]

On Fri, Jun 28, 2024, 18:28 Vitaliy Perekhovy  wrote:

> On Fri, Jun 28, 2024 at 04:17:23PM -, Grant Edwards wrote:
> > Is there any graceful way to handle the elimination of unwanted
> > linux-firmware blobs when doing an update?
> >
> > I believe I understand the process as outlined at
> > https://wiki.gentoo.org/wiki/Linux_firmware:
> >
> >  1. install/upgrade sys-kernel/linux-firmware
> >  2. edit /etc/portage/savedconfig/sys-kernel/linux-firmware-ddmm
> >  3. re-emerge sys-kernel/linux-firmware with the savedcofnig USE flag
> >
> > I've tried that a few times, but it's rather annoying to have to do
> > that every time linux-firmware gets updated.
> >
> > AFAICT, the list of three or four blobs that I actually need on a
> > specific machine never changes.
> >
> > It seems like there ought to be a way to configure that required
> > firmware list and have the emerge -u "just work", but I can't find
> > it. Have I missed something?
> >
> > Yes, I know...
> >   Disk space is cheap.
> >   Premature optimization ...
> >   etc.
> >
> > It still annoys me.
> >
> > --
> > Grant
>
> Save your firmware list in
> /etc/portage/savedconfig/sys-kernel/linux-firmware
> That's it.
>
> --
> Best regards,
> Vitaliy Perekhovy
>

After every update to sys-kernel/linux-firmware, you may get the following
output:

 * IMPORTANT: config file
'/etc/portage/savedconfig/sys-kernel/linux-firmware-20240610' needs
updating.
 * See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS
 * sections of the emerge man page to learn how to update config files.

It's a good idea to compare this file to your current file to see if any
firmware blobs have gotten updates. However, it's important to then discard
this file by choosing `z` in dispatch-conf.

Regards,
Waldo

>

Re: [gentoo-user] Eliminating unwanted linux-firmware blobs.

[Vitaliy Perekhovy]

On Fri, Jun 28, 2024 at 04:17:23PM -, Grant Edwards wrote:
> Is there any graceful way to handle the elimination of unwanted
> linux-firmware blobs when doing an update?
> 
> I believe I understand the process as outlined at
> https://wiki.gentoo.org/wiki/Linux_firmware:
> 
>  1. install/upgrade sys-kernel/linux-firmware
>  2. edit /etc/portage/savedconfig/sys-kernel/linux-firmware-ddmm
>  3. re-emerge sys-kernel/linux-firmware with the savedcofnig USE flag
> 
> I've tried that a few times, but it's rather annoying to have to do
> that every time linux-firmware gets updated.
> 
> AFAICT, the list of three or four blobs that I actually need on a
> specific machine never changes.
> 
> It seems like there ought to be a way to configure that required
> firmware list and have the emerge -u "just work", but I can't find
> it. Have I missed something?
> 
> Yes, I know...
>   Disk space is cheap.
>   Premature optimization ...
>   etc.
> 
> It still annoys me.
> 
> --
> Grant

Save your firmware list in /etc/portage/savedconfig/sys-kernel/linux-firmware
That's it.

-- 
Best regards,
Vitaliy Perekhovy


signature.asc
Description: PGP signature

[gentoo-user] Eliminating unwanted linux-firmware blobs.

[Grant Edwards]

Is there any graceful way to handle the elimination of unwanted
linux-firmware blobs when doing an update?

I believe I understand the process as outlined at
https://wiki.gentoo.org/wiki/Linux_firmware:

 1. install/upgrade sys-kernel/linux-firmware
 2. edit /etc/portage/savedconfig/sys-kernel/linux-firmware-ddmm
 3. re-emerge sys-kernel/linux-firmware with the savedcofnig USE flag

I've tried that a few times, but it's rather annoying to have to do
that every time linux-firmware gets updated.

AFAICT, the list of three or four blobs that I actually need on a
specific machine never changes.

It seems like there ought to be a way to configure that required
firmware list and have the emerge -u "just work", but I can't find
it. Have I missed something?

Yes, I know...
  Disk space is cheap.
  Premature optimization ...
  etc.

It still annoys me.

--
Grant

Re: [gentoo-user] bashrc and setting PS1 variable heads up.

[Peter Humphrey]

On Friday, 28 June 2024 08:32:44 BST Dale wrote:

> I did a major upgrade and found out I had a lot of config files to
> update.  I performed those updates, while losing some of my settings. 
> Anyway, I figured out how to set the alias variables.  Simple enough. 
> Create a file and list them in the file.  The PS1 is different because
> it usually determines if a user is root or not and gives a different
> prompt.  That requires a little bit of scripting, which most know is a
> huge weak point for me. 

I thought the proper place to define aliases was in /etc/profile.d/
profile_aliases.sh. That's where I have mine, anyway.

PS1 is set in /etc/bash/bashrc.d/10-gentoo-color.bash, as you say. I change 
the prompt colours in there, in the case of the little rescue system I have on 
each machine. That's so that I can see which system I'm logged-on to (I 
maintain the rescue system by chrooting into it from the main system, and it's 
far too easy to make mistakes without that precaution).

-- 
Regards,
Peter.

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Mark Knecht]

On Thu, Jun 27, 2024 at 10:18 PM Dale  wrote:
>
> Mark Knecht wrote:
>
>
>
> On Thu, Jun 27, 2024 at 4:01 PM Dale  wrote:
> 
> >
> > I think the rig and video card are fine.  I did try a different card
and version of nvidia drivers once tho.  Same thing.  At first, I tried the
nouveau drivers.  All the bootable media uses that driver.  When I tried it
on my install, it was very slow and the mouse pointer was very jerky.  It
was horrible.  I removed those drivers and installed nvidia.  Sadly, things
got worse.
> >
> > I'll boot into Kubuntu again and see what info it has.  The ones I
attached tho is all there was. Either it doesn't have those files or the
files were blank.  I think Xorg and messages was all there was.
> >
> > I'm out of steam.  May boot Kubuntu and let it sit while I nap.  It
worked for several minutes last time tho.  It seemed to work fine.  Very
fast too, unlike on my install.
> >
>
> Yeah, I can hear the frustration and weariness in your writing. However I
know you are up to fixing this.
>
> One additional experiment you can do, and I suspect Kubuntu passes every
time, is boot the machine with the monitor plugged into each port one at a
time. Do complete power downs between each boot. If Kubuntu comes up it
will really tell you a stable, tested OS has solved these problems. If it
doesn't then that's good info also.
>
> I think possibly you purchased a Quadro adapter? I don't know how popular
those are amongst this crowd but they have been very popular in business
settings. That might make a bigger difference in terms of the nvidia driver
vs the Open Source one.
>
> Good luck with your machine,
> Mark
>
>
>
> I admit, I'm thinking about unplugging the thing and sticking it in the
closet.  If nothing else, I'm tired of walking around this huge thing.  I
was hoping to have switched long ago.  Usually, I look forward and even get
excited to build a new rig.  This time, with the lacking slots of the
original mobo and having to go way down power wise, I just want to make
sure I have a working computer if something happens to my main rig.
There's not a whole lot to get excited about.  Having it not work, well,
that doesn't help.  Poor Michael is trying to help but this thing is
weird.  With every reboot, it does something differently.
>
> On the Kubuntu test.  I started with what the bracket shows as port 1.  I
then went through each port until I got to port 4.  I rebooted in between
each switch.  Even unplugged the monitor.  It worked every time.  During
the booting of the image tho, there was several seconds where the screen
went weird.  It had these horizontal lines on it that looked like stair
steps.  I've seen this type of thing on other boot media even with my main
rig and the NAS box.  It's like the image is in the process of loading
drivers or something.  Anyway, once it came up tho, rock solid.
>
> I checked the nvidia website three times now.  Still, I wonder, am I
using the wrong driver?  Would the wrong driver even load without a nasty
message somewhere that is obvious?  The Nvidia website shows this:
>
>
> Version: 550.90.07
> Release Date: 2024.6.4
> Operating System: Linux 64-bit
> Language: English (US)
> File Size:   293.33 MB
>
> I tried that series and the earlier version as well.  Hard to believe
that both versions would fail the same way due to a bug.  If someone wants
to double check, Nvidia Quadro P1000 is the info.  Even if the selection
tool is wrong, it shows up under supported products, for both desktops and
laptops.
>
> I may try to the Nouveau driver thing again.  Instead of building it into
the kernel, I may try the tree version.  Maybe it will work better than the
one in the kernel.  One can hope.  Right now, I'm trying to sort through a
massive update on my main rig.  Something broke eix.  o_O  I managed to
update the config files.  Broke my prompt tho.  I need a hammer.  :/
>
> Dale
>
> :-)  :-)

Good morning Dale,
   OK, thanks for indulging me on the Kubuntu testing. Based on my
understanding of the results - basically everything 'worked' but some of
the reactions were slow - I'd say don't worry about that when running from
boot media. I've seen a little of that myself, but it's never been a
problem on a real install. To me it's good news that the Kubuntu install
worked fine with all your monitors on any port you tried. That's GOOD news.
No need to change hardware.

   I know you love your disk space. I wonder if you have a partition
somewhere that you could just install Kubuntu, install the NVidia drivers,
get the machine updated and then study why Kubuntu has your hardware nailed
and Gentoo doesn't? Once you've installed Kubuntu there are just a few
commands to update the machine to current levels and because you're good
with dual boot I don't foresee it being a big problem for you. Create a
100GB partition - or use some partition you can reuse in the future -
install Kubuntu, runit, and 

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Michael]

On Thursday, 27 June 2024 23:52:25 BST Dale wrote:
> Michael wrote:

> > [snip ...]
> > [30.345] (II) modeset(0): [DRI2]   DRI driver: nouveau  <== Not nvidia
> > ==
> > 
> > [snip ...]
> > [30.295] (II) modeset(0): Output DP-1 disconnected
> > [30.295] (II) modeset(0): Output DP-2 disconnected
> > [30.295] (II) modeset(0): Output DP-3 disconnected
> > [30.295] (II) modeset(0): Output DP-4 connected
> > 
> > What does it take to connect the cable on the FIRST port of the video
> > card?
> 
> This reply may be a little odd.  I wrote some then went back and tried
> some stuff and added info to it.  Trying to make it make sense. 

My apologies, I didn't meant to add to your frustration.  Working with a 
headless system is no fun when you expect to run a desktop on this thing!

I was just making a remark on the fact the card detects the monitor as being 
connected to DFP-3 or DFP-5 when using the proprietary nvidia driver, but the 
DP-4 when you used the open source nouveau driver.


> > At first, when it really wouldn't work, I had it on the bottom port.  At
> some point we thought that was the last port, #4 or DP-3 in the logs,
> and not the first port.  I moved it to the top port which is #1, we
> thought.  It's still on that port but that port did work once and
> resulted in "solved" being added to the subject line.  I just double
> checked.  It is plugged in the top port.  Unless the bottom port is #1
> like I originally thought, then it should be on port #1.  I did a search
> and found a image that shows it puts the port number on the metal
> bracket.  I removed the card so I could see the numbers.  The bottom
> port is number 1 like I originally thought.  So, I had it in the right
> port to begin with, which wasn't working either.  I'll put it back on
> what the metal bracket says is port #1, or bottom port.  I booted up,
> started DM, correct resolution but no plasma and background is black. 
> Still not a functional desktop.  Partially works tho.  Time to reboot. 
> On reboot, sddm and KDE are low resolution.  It does have a background
> image and plasma is working.  Keep in mind, all I did is reboot.  I
> didn't change any config file or run any commands.  Reboot again.  This
> time, correct resolution but no plasma.  Again, all I did was reboot. 
> No changes to anything at all.  As you can see, each time I reboot, it
> is like rolling dice.  I suspect if I keep rebooting it will eventually
> do the black screen and power the monitor off. 

It seems to me the card is probing the monitor to find out what settings it 
prefers/will work with.  This probing of the driver scrolls through a number 
of potential Modelines, but if the monitor does not respond in a timely manner 
with its preferred resolution and frequency you get a broken result.

Here are some hypotheses of mine, in absence of more concrete evidence.  The 
old box is slower and the initialisation process takes longer.  In this longer 
processing time the monitor responds with its EDID and what not.  The card 
receives it in a timely fashion and sets the driver accordingly.

With your new box things happen faster on the PC side, but not on the monitor 
side.  Two times out of three the synchronisation between driver and monitor 
fails and you end up with reports of EDID not found and monitor shown as 
disconnected in your Xorg.0.log.

Having the monitor plugged in any port on the card, first or last, should not 
make a difference, but if milli/nano-seconds count then it /might/ make a 
difference, assuming the ports are tried sequentially by the driver.  Hence I 
had suggested stick with the first port.  Some user reports on the interwebs 
mentioned it, so I thought it is worth trying it.

What else worth trying is  to set fixed directives for the "Monitor" section 
in your xorg config file, or capture the EDID table into a file and feed it to 
the driver.  The former ought to work, the latter may not if the EDID itself 
is buggy, but that's a problem to solve later if it even exists.  Either way, 
setting explicit directives for the monitor Modeline(s) and preferred 
resolution/frequency ought to take auto-probing out of the equation.


> I did originally try to use the nouveau drivers.  It kinda worked, once
> at least, but the screen was very slow to respond and the mouse was very
> jerky.  It just wasn't good enough for whatever reason.  I recompiled
> the kernel without those drivers and emerged nvidia.

It's your call which drivers you should try to get it to work with first.

Slow GUI response with the nouveau driver would indicate the kernel 
configuration/firmware loading was not 100% when you trying initially, because 
it works fine when you tried it again with Kubuntu's kernel.

People who use Nvidia prefer the nvidia driver in terms of performance, CUDA, 
etc. so you may want to stick with the nvidia driver initially.  In this case, 
walk through this guide and cross-check you followed all suggestions in 

Re: [gentoo-user] bashrc and setting PS1 variable heads up.

[Wols Lists]

On 28/06/2024 08:32, Dale wrote:

Also, some software can add files to the bashrc.d directory too.  I'm
not sure what added the gentoo-color file but I also found a file for
kitty that I installed recently.  If I remove kitty, it removes the file
too.  From what I've read, this is why it is changing to a directory.
It gives software a place to change these settings and be removed if the
software is removed.


The other BIGGY here, is that by separating out all the little changes 
for eg kitty, your personal preferrences, etc etc into little files on 
their own rather than one big monolith, you don't suddenly get 
etc-update or whatever moaning "/etc/bashrc has changed, do you want the 
old one, new one, or merge changes".


I've still got my original /etc/postfix.cf file because it's been so 
mangled with local changes I daren't touch it ...


I think systemd is the big driver here - it was a design aim of systemd 
to put default configuration in one place, local system over-rides in a 
second, and user over-rides in a third. I'm sure other software beat 
systemd to it, but systemd said "you *WILL* do this", and once they 
enforced it, everybody started doing it. Makes sense ...


Cheers,
Wol

[gentoo-user] bashrc and setting PS1 variable heads up.

[Dale]

Howdy,

I did a major upgrade and found out I had a lot of config files to
update.  I performed those updates, while losing some of my settings. 
Anyway, I figured out how to set the alias variables.  Simple enough. 
Create a file and list them in the file.  The PS1 is different because
it usually determines if a user is root or not and gives a different
prompt.  That requires a little bit of scripting, which most know is a
huge weak point for me. 

I tried setting PS1 by copying the part of the old bashrc file and
putting it in a file in the bashrc.d directory.  It went sideways
quick.  Sometimes it wouldn't log me in at all.  It acted like I typed
in a bad password.  Then I used grep -r to see if there was a clash in
setting PS1.  Turns out, there is.  If you want to set your prompt to
something other than the default, look and see if you have a file named
gentoo-color.bash in the bashrc.d directory.  You may want to use grep
-r in case PS1 is in another file too.  If you have that file tho, set
the PS1 variable in it.  If not, it causes issues.  The issue seems to
depend on what it is reading first and last. 

I figure most set this in a bashrc file in the user directory they want
it to apply too.  It seems tho that bash is moving to a new way.  Sort
of like portage did when package.* files became directories.  I kinda
like the change really.  If I want to change a alias, I change the alias
file.  Easy to find, nothing to remember which is good for me, and it
kinda organizes things.  Also easy to remove if no longer needed. 

Also, some software can add files to the bashrc.d directory too.  I'm
not sure what added the gentoo-color file but I also found a file for
kitty that I installed recently.  If I remove kitty, it removes the file
too.  From what I've read, this is why it is changing to a directory. 
It gives software a place to change these settings and be removed if the
software is removed. 

I just wanted to post this as a heads up for those who don't know about
the change.  Not being able to login was a bit nerve wrecking.  o_O

Dale

:-)  :-) 

Re: [gentoo-user] Re: Config file updates and using diff.

[Dale]

Grant Edwards wrote:
> On 2024-06-27, Dale  wrote:
>> Howdy,
>>
>> I just finished a large update on my main rig.  I have a lot of config
>> files to update and some have new entries that are needed but I don't
>> want to lose the ones I've already set.  Usually, I just pick the new
>> one and have a saved copy of the old config to put back my settings. 
>> This is a lot of config files tho.  I been using dispatch-conf for this
>> but I've never figured out how to use the diff feature and tell it which
>> parts I want to keep and what I want to update. 
>>
>> First, I've looked on the wiki and can't find a howto on using the diff
>> tool.  Is there a guide on there I can't find?  Second, is there a
>> better way to do this, a very easy way if you will?  Like maybe a GUI
>> thing where I use the mouse to select.  It would be nice if it is
>> something I can easily remember how to do given how rare it is I need to
>> do a diff of the files. 
> I used the "meld" utility for doing visual side-by side diffs and
> resolving merges. At one point, I had figured out how to get
> etc-udpate to invoke meld for me, but I've lost that setting somehow.
>
> I usually just use etc-udpate, and then individually invoke meld with
> the two file paths shown by etc-udpate. I merge the relevent bits of
> the new default config file into my existing one using meld, then I
> tell etc-udpate to "discard the new file" (or whatever that option
> is).
>

I tried several different things, even those outside of emerge like
kdiff3.  I couldn't figure out how to use any of them.  Eventually, I
just hit 'use new' on them all.  Now I'm trying to fix everything it
messed up.  Most everything works except for the bashrc.d stuff.  It
seems things started moving from a single file to a directory with
different files for different things.  I kinda like the idea myself. I
just wish I could get it to work right.  LOL 

Thanks for the suggestion. 

Dale

:-)  :-) 

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Mark Knecht wrote:
>
>
> On Thu, Jun 27, 2024 at 4:01 PM Dale  > wrote:
> 
> >
> > I think the rig and video card are fine.  I did try a different card
> and version of nvidia drivers once tho.  Same thing.  At first, I
> tried the nouveau drivers.  All the bootable media uses that driver. 
> When I tried it on my install, it was very slow and the mouse pointer
> was very jerky.  It was horrible.  I removed those drivers and
> installed nvidia.  Sadly, things got worse.
> >
> > I'll boot into Kubuntu again and see what info it has.  The ones I
> attached tho is all there was. Either it doesn't have those files or
> the files were blank.  I think Xorg and messages was all there was.
> >
> > I'm out of steam.  May boot Kubuntu and let it sit while I nap.  It
> worked for several minutes last time tho.  It seemed to work fine. 
> Very fast too, unlike on my install.
> >
>
> Yeah, I can hear the frustration and weariness in your writing.
> However I know you are up to fixing this.
>
> One additional experiment you can do, and I suspect Kubuntu passes
> every time, is boot the machine with the monitor plugged into each
> port one at a time. Do complete power downs between each boot. If
> Kubuntu comes up it will really tell you a stable, tested OS has
> solved these problems. If it doesn't then that's good info also.
>
> I think possibly you purchased a Quadro adapter? I don't know how
> popular those are amongst this crowd but they have been very popular
> in business settings. That might make a bigger difference in terms of
> the nvidia driver vs the Open Source one.
>
> Good luck with your machine,
> Mark


I admit, I'm thinking about unplugging the thing and sticking it in the
closet.  If nothing else, I'm tired of walking around this huge thing. 
I was hoping to have switched long ago.  Usually, I look forward and
even get excited to build a new rig.  This time, with the lacking slots
of the original mobo and having to go way down power wise, I just want
to make sure I have a working computer if something happens to my main
rig.  There's not a whole lot to get excited about.  Having it not work,
well, that doesn't help.  Poor Michael is trying to help but this thing
is weird.  With every reboot, it does something differently. 

On the Kubuntu test.  I started with what the bracket shows as port 1. 
I then went through each port until I got to port 4.  I rebooted in
between each switch.  Even unplugged the monitor.  It worked every
time.  During the booting of the image tho, there was several seconds
where the screen went weird.  It had these horizontal lines on it that
looked like stair steps.  I've seen this type of thing on other boot
media even with my main rig and the NAS box.  It's like the image is in
the process of loading drivers or something.  Anyway, once it came up
tho, rock solid. 

I checked the nvidia website three times now.  Still, I wonder, am I
using the wrong driver?  Would the wrong driver even load without a
nasty message somewhere that is obvious?  The Nvidia website shows this:


Version:                 550.90.07
Release Date:         2024.6.4
Operating System: Linux 64-bit
Language:                 English (US)
File Size:               293.33 MB

I tried that series and the earlier version as well.  Hard to believe
that both versions would fail the same way due to a bug.  If someone
wants to double check, Nvidia Quadro P1000 is the info.  Even if the
selection tool is wrong, it shows up under supported products, for both
desktops and laptops. 

I may try to the Nouveau driver thing again.  Instead of building it
into the kernel, I may try the tree version.  Maybe it will work better
than the one in the kernel.  One can hope.  Right now, I'm trying to
sort through a massive update on my main rig.  Something broke eix. 
o_O  I managed to update the config files.  Broke my prompt tho.  I need
a hammer.  :/

Dale

:-)  :-) 

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Mark Knecht]

On Thu, Jun 27, 2024 at 4:01 PM Dale  wrote:

>
> I think the rig and video card are fine.  I did try a different card and
version of nvidia drivers once tho.  Same thing.  At first, I tried the
nouveau drivers.  All the bootable media uses that driver.  When I tried it
on my install, it was very slow and the mouse pointer was very jerky.  It
was horrible.  I removed those drivers and installed nvidia.  Sadly, things
got worse.
>
> I'll boot into Kubuntu again and see what info it has.  The ones I
attached tho is all there was. Either it doesn't have those files or the
files were blank.  I think Xorg and messages was all there was.
>
> I'm out of steam.  May boot Kubuntu and let it sit while I nap.  It
worked for several minutes last time tho.  It seemed to work fine.  Very
fast too, unlike on my install.
>

Yeah, I can hear the frustration and weariness in your writing. However I
know you are up to fixing this.

One additional experiment you can do, and I suspect Kubuntu passes every
time, is boot the machine with the monitor plugged into each port one at a
time. Do complete power downs between each boot. If Kubuntu comes up it
will really tell you a stable, tested OS has solved these problems. If it
doesn't then that's good info also.

I think possibly you purchased a Quadro adapter? I don't know how popular
those are amongst this crowd but they have been very popular in business
settings. That might make a bigger difference in terms of the nvidia driver
vs the Open Source one.

Good luck with your machine,
Mark

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Mark Knecht wrote:
>
>
> On Thu, Jun 27, 2024 at 2:13 PM Dale  > wrote:
> 
> > I've tried to use nvidia-settings but the man page is like Greek. 
> The one thing I did figure out, -q all.  On my main rig, it spits out
> TONS of info.  On the new rig, it just says something like no display
> found or something.  It's like two lines, maybe one.
> >
> > Had several interruptions so managed to try Kubuntu "Try" option. 
> It comes up just fine, correct resolution, plasma is working and all. 
> I'm attaching the Xorg log from Kubuntu.
> >
> > Maybe the Kubuntu log will shed some light.
> >
> > Dale
> >
> > :-)  :-)
>
> OK, so if Kubuntu comes up and runs stable for an hour or two then I
> don't think it's your new rig or monitor.
>
> I have a suspicion that Kubuntu booted and loaded the Open Source
> driver and not the nvidia driver, but that's just a guess. However, if
> that's the case then you can almost certainly use whatever Kubuntu has
> used as far as drivers and an xorg.conf file and see if that helps
> with your Gentoo issues. Once you get Gentoo working with the Open
> Source driver then you could investigate using nvidia's.
>
> If you have time to let the machine soak awhile then I'd consider a
> reboot into Kubuntu and then take a look at what drivers are loaded
> using lsmod. There will likely be a huge list. I have a 2 year old
> machine that's not unlike your new machine (yours is slightly more
> powerful I think) but the list of drivers loaded is just huge. However
> it works, and once you get it going with lots of drivers you can then
> rebuild things with them in the kernel if you want to.
>
> Anyway, look at lsmod and report back. Here's mine running Kubuntu,
> and I have no xorg.conf but it runs fine with 3 monitors.
>
> mark@science2:~$ lsmod | grep nvidia
> nvidia_uvm           1789952  0
> nvidia_drm             90112  16
> nvidia_modeset       1314816  39 nvidia_drm
> nvidia              56827904  1890 nvidia_uvm,nvidia_modeset
> video                  73728  2 asus_wmi,nvidia_modeset
> mark@science2:~$
>
> Good luck,
> Mark


I think the rig and video card are fine.  I did try a different card and
version of nvidia drivers once tho.  Same thing.  At first, I tried the
nouveau drivers.  All the bootable media uses that driver.  When I tried
it on my install, it was very slow and the mouse pointer was very
jerky.  It was horrible.  I removed those drivers and installed nvidia. 
Sadly, things got worse. 

I'll boot into Kubuntu again and see what info it has.  The ones I
attached tho is all there was. Either it doesn't have those files or the
files were blank.  I think Xorg and messages was all there was. 

I'm out of steam.  May boot Kubuntu and let it sit while I nap.  It
worked for several minutes last time tho.  It seemed to work fine.  Very
fast too, unlike on my install. 

Dale

:-)  :-) 

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Michael wrote:
> On Thursday, 27 June 2024 22:06:36 BST Dale wrote:
>> Mark Knecht wrote:
>>> On Thu, Jun 27, 2024 at 12:03 AM Dale >>
>>> > wrote:
 Update.  I played around a bit.  I figured I didn't have a lot to lose
 here.  It either works, or it doesn't.  After playing around a bit, I
 got it to work.  I have not restarted it to see if it will work again,
 yet.  I wanted to grab some log info first, while it is working.  So,
 this part is about when KDE comes up completely but could include some
 attempts that failed.  Comes up completely means, in the correct
 resolution, background image and the panel thing on the bottom, which
 means plasma is running as it should.  I'm doing these inside the email
 instead of as attachments.  Sorry for the length.  I just want to share
 this while I have it available.

 This first one, I had a few failures before it succeeded.  I couldn't
 figure out when the working bit started so it is the complete log.
>>> Hi Dale,
>>>I have returned home and can once again bottom post.
>>>
>>>There's no way I'm going to read and understand this
>>> whole thread but I did have one question and one comment:
>>>
>>> 1) Did you ever actually try the Kubunu option that didn't
>>> require an install? I saw you mentions Knoppix and maybe
>>> one other option. Just curious as to what the results were.
>>>
>>> 2) I see you discussing xorg.conf file which I don't use
>>> here but did you generate this file - if you are really using
>>> it - using the nvidia-settings app, or by hand? 
>>>
>>>If your system will stay up I believe nvidia-settings is
>>> recommended by NVidia, or was anyway. It does a good
>>> job of showing the layout and handling options that NVidia
>>> says make their cards work better.
>>>
>>> Good luck,
>>> Mark
>> I booted the Gentoo live image and Knoppix.  Knoppix is old.  I don't
>> think it is being maintained anymore but even on this new hardware, even
>> it worked.  I've booted other things to and all work fine except the
>> Gentoo install, the one thing I need to work.  I checked, I did download
>> Kubuntu but I don't remember trying it.  With my memory tho, I may have
>> and just don't remember it.  :/  I'll add it to my Ventoy stick and try
>> it shortly.  It's hot, humid and my energy level isn't much.  The family
>> visit to the hospital drained me good.  And she is still sick.  I took
>> her some tomatoes this morning and she likes the peaches I got for her
>> too.  Not much she can eat. 
>>
>> I've tried with no xorg.conf at first.  Then I tried with one that tells
>> it to use the nvidia driver, even tho lsmod shows it loaded and lspci -k
>> shows it being used.  Then I used nvidia-xconfig to create a conf file. 
>> Then I tried some options that Michael suggested.  On occasion, it
>> works.  Most of the time, it doesn't.  To be honest, I'm not sure if
>> anything we do is affecting it.  I think sometimes things just drop into
>> place and it works.  Most of the time, things don't drop into place and
>> it fails or only partially works. 
>>
>> Given I've used different boot media, a different video card and
>> different config options, I'm thinking it is the monitor and it just
>> clashes with this one install but works with others, which may figure
>> out to ignore what the monitor fails to do.  I find it odd but it is
>> logical. 
>>
>> I've tried to use nvidia-settings but the man page is like Greek.  The
>> one thing I did figure out, -q all.  On my main rig, it spits out TONS
>> of info.  On the new rig, it just says something like no display found
>> or something.  It's like two lines, maybe one. 
>>
>> Had several interruptions so managed to try Kubuntu "Try" option.  It
>> comes up just fine, correct resolution, plasma is working and all.  I'm
>> attaching the Xorg log from Kubuntu. 
>>
>> Maybe the Kubuntu log will shed some light. 
>>
>> Dale
>>
>> :-)  :-) 
> [snip ...]
> [30.345] (II) modeset(0): [DRI2]   DRI driver: nouveau  <== Not nvidia ==
>
> [snip ...]
> [30.295] (II) modeset(0): Output DP-1 disconnected
> [30.295] (II) modeset(0): Output DP-2 disconnected
> [30.295] (II) modeset(0): Output DP-3 disconnected
> [30.295] (II) modeset(0): Output DP-4 connected
>
> What does it take to connect the cable on the FIRST port of the video card?  

This reply may be a little odd.  I wrote some then went back and tried
some stuff and added info to it.  Trying to make it make sense. 

At first, when it really wouldn't work, I had it on the bottom port.  At
some point we thought that was the last port, #4 or DP-3 in the logs,
and not the first port.  I moved it to the top port which is #1, we
thought.  It's still on that port but that port did work once and
resulted in "solved" being added to the subject line.  I just double
checked.  It is plugged in the top port.  Unless the bottom port is #1
like I originally thought, then it should 

[gentoo-user] Re: Config file updates and using diff.

[Grant Edwards]

On 2024-06-27, Dale  wrote:
> Howdy,
>
> I just finished a large update on my main rig.  I have a lot of config
> files to update and some have new entries that are needed but I don't
> want to lose the ones I've already set.  Usually, I just pick the new
> one and have a saved copy of the old config to put back my settings. 
> This is a lot of config files tho.  I been using dispatch-conf for this
> but I've never figured out how to use the diff feature and tell it which
> parts I want to keep and what I want to update. 
>
> First, I've looked on the wiki and can't find a howto on using the diff
> tool.  Is there a guide on there I can't find?  Second, is there a
> better way to do this, a very easy way if you will?  Like maybe a GUI
> thing where I use the mouse to select.  It would be nice if it is
> something I can easily remember how to do given how rare it is I need to
> do a diff of the files. 

I used the "meld" utility for doing visual side-by side diffs and
resolving merges. At one point, I had figured out how to get
etc-udpate to invoke meld for me, but I've lost that setting somehow.

I usually just use etc-udpate, and then individually invoke meld with
the two file paths shown by etc-udpate. I merge the relevent bits of
the new default config file into my existing one using meld, then I
tell etc-udpate to "discard the new file" (or whatever that option
is).

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Mark Knecht]

On Thu, Jun 27, 2024 at 2:13 PM Dale  wrote:

> I've tried to use nvidia-settings but the man page is like Greek.  The
one thing I did figure out, -q all.  On my main rig, it spits out TONS of
info.  On the new rig, it just says something like no display found or
something.  It's like two lines, maybe one.
>
> Had several interruptions so managed to try Kubuntu "Try" option.  It
comes up just fine, correct resolution, plasma is working and all.  I'm
attaching the Xorg log from Kubuntu.
>
> Maybe the Kubuntu log will shed some light.
>
> Dale
>
> :-)  :-)

OK, so if Kubuntu comes up and runs stable for an hour or two then I don't
think it's your new rig or monitor.

I have a suspicion that Kubuntu booted and loaded the Open Source driver
and not the nvidia driver, but that's just a guess. However, if that's the
case then you can almost certainly use whatever Kubuntu has used as far as
drivers and an xorg.conf file and see if that helps with your Gentoo
issues. Once you get Gentoo working with the Open Source driver then you
could investigate using nvidia's.

If you have time to let the machine soak awhile then I'd consider a reboot
into Kubuntu and then take a look at what drivers are loaded using lsmod.
There will likely be a huge list. I have a 2 year old machine that's not
unlike your new machine (yours is slightly more powerful I think) but the
list of drivers loaded is just huge. However it works, and once you get it
going with lots of drivers you can then rebuild things with them in the
kernel if you want to.

Anyway, look at lsmod and report back. Here's mine running Kubuntu, and I
have no xorg.conf but it runs fine with 3 monitors.

mark@science2:~$ lsmod | grep nvidia
nvidia_uvm   1789952  0
nvidia_drm 90112  16
nvidia_modeset   1314816  39 nvidia_drm
nvidia  56827904  1890 nvidia_uvm,nvidia_modeset
video  73728  2 asus_wmi,nvidia_modeset
mark@science2:~$

Good luck,
Mark

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Michael]

On Thursday, 27 June 2024 22:06:36 BST Dale wrote:
> Mark Knecht wrote:
> > On Thu, Jun 27, 2024 at 12:03 AM Dale  > 
> > > wrote:
> > > Update.  I played around a bit.  I figured I didn't have a lot to lose
> > > here.  It either works, or it doesn't.  After playing around a bit, I
> > > got it to work.  I have not restarted it to see if it will work again,
> > > yet.  I wanted to grab some log info first, while it is working.  So,
> > > this part is about when KDE comes up completely but could include some
> > > attempts that failed.  Comes up completely means, in the correct
> > > resolution, background image and the panel thing on the bottom, which
> > > means plasma is running as it should.  I'm doing these inside the email
> > > instead of as attachments.  Sorry for the length.  I just want to share
> > > this while I have it available.
> > > 
> > > This first one, I had a few failures before it succeeded.  I couldn't
> > > figure out when the working bit started so it is the complete log.
> > 
> > Hi Dale,
> >I have returned home and can once again bottom post.
> > 
> >There's no way I'm going to read and understand this
> > whole thread but I did have one question and one comment:
> > 
> > 1) Did you ever actually try the Kubunu option that didn't
> > require an install? I saw you mentions Knoppix and maybe
> > one other option. Just curious as to what the results were.
> > 
> > 2) I see you discussing xorg.conf file which I don't use
> > here but did you generate this file - if you are really using
> > it - using the nvidia-settings app, or by hand? 
> > 
> >If your system will stay up I believe nvidia-settings is
> > recommended by NVidia, or was anyway. It does a good
> > job of showing the layout and handling options that NVidia
> > says make their cards work better.
> > 
> > Good luck,
> > Mark
> 
> I booted the Gentoo live image and Knoppix.  Knoppix is old.  I don't
> think it is being maintained anymore but even on this new hardware, even
> it worked.  I've booted other things to and all work fine except the
> Gentoo install, the one thing I need to work.  I checked, I did download
> Kubuntu but I don't remember trying it.  With my memory tho, I may have
> and just don't remember it.  :/  I'll add it to my Ventoy stick and try
> it shortly.  It's hot, humid and my energy level isn't much.  The family
> visit to the hospital drained me good.  And she is still sick.  I took
> her some tomatoes this morning and she likes the peaches I got for her
> too.  Not much she can eat. 
> 
> I've tried with no xorg.conf at first.  Then I tried with one that tells
> it to use the nvidia driver, even tho lsmod shows it loaded and lspci -k
> shows it being used.  Then I used nvidia-xconfig to create a conf file. 
> Then I tried some options that Michael suggested.  On occasion, it
> works.  Most of the time, it doesn't.  To be honest, I'm not sure if
> anything we do is affecting it.  I think sometimes things just drop into
> place and it works.  Most of the time, things don't drop into place and
> it fails or only partially works. 
> 
> Given I've used different boot media, a different video card and
> different config options, I'm thinking it is the monitor and it just
> clashes with this one install but works with others, which may figure
> out to ignore what the monitor fails to do.  I find it odd but it is
> logical. 
> 
> I've tried to use nvidia-settings but the man page is like Greek.  The
> one thing I did figure out, -q all.  On my main rig, it spits out TONS
> of info.  On the new rig, it just says something like no display found
> or something.  It's like two lines, maybe one. 
> 
> Had several interruptions so managed to try Kubuntu "Try" option.  It
> comes up just fine, correct resolution, plasma is working and all.  I'm
> attaching the Xorg log from Kubuntu. 
> 
> Maybe the Kubuntu log will shed some light. 
> 
> Dale
> 
> :-)  :-) 

[snip ...]
[30.345] (II) modeset(0): [DRI2]   DRI driver: nouveau  <== Not nvidia ==

[snip ...]
[30.295] (II) modeset(0): Output DP-1 disconnected
[30.295] (II) modeset(0): Output DP-2 disconnected
[30.295] (II) modeset(0): Output DP-3 disconnected
[30.295] (II) modeset(0): Output DP-4 connected

What does it take to connect the cable on the FIRST port of the video card?  


signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Config file updates and using diff.

[Dale]

Howdy,

I just finished a large update on my main rig.  I have a lot of config
files to update and some have new entries that are needed but I don't
want to lose the ones I've already set.  Usually, I just pick the new
one and have a saved copy of the old config to put back my settings. 
This is a lot of config files tho.  I been using dispatch-conf for this
but I've never figured out how to use the diff feature and tell it which
parts I want to keep and what I want to update. 

First, I've looked on the wiki and can't find a howto on using the diff
tool.  Is there a guide on there I can't find?  Second, is there a
better way to do this, a very easy way if you will?  Like maybe a GUI
thing where I use the mouse to select.  It would be nice if it is
something I can easily remember how to do given how rare it is I need to
do a diff of the files. 

Thoughts? 

Dale

:-)  :-) 

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Mark Knecht wrote:
>
>
> On Thu, Jun 27, 2024 at 12:03 AM Dale  > wrote:
> >
> > Update.  I played around a bit.  I figured I didn't have a lot to lose
> > here.  It either works, or it doesn't.  After playing around a bit, I
> > got it to work.  I have not restarted it to see if it will work again,
> > yet.  I wanted to grab some log info first, while it is working.  So,
> > this part is about when KDE comes up completely but could include some
> > attempts that failed.  Comes up completely means, in the correct
> > resolution, background image and the panel thing on the bottom, which
> > means plasma is running as it should.  I'm doing these inside the email
> > instead of as attachments.  Sorry for the length.  I just want to share
> > this while I have it available.
> >
> > This first one, I had a few failures before it succeeded.  I couldn't
> > figure out when the working bit started so it is the complete log.
> >
> >
>
> Hi Dale,
>    I have returned home and can once again bottom post.
>
>    There's no way I'm going to read and understand this
> whole thread but I did have one question and one comment:
>
> 1) Did you ever actually try the Kubunu option that didn't
> require an install? I saw you mentions Knoppix and maybe
> one other option. Just curious as to what the results were.
>
> 2) I see you discussing xorg.conf file which I don't use
> here but did you generate this file - if you are really using
> it - using the nvidia-settings app, or by hand? 
>
>    If your system will stay up I believe nvidia-settings is
> recommended by NVidia, or was anyway. It does a good
> job of showing the layout and handling options that NVidia
> says make their cards work better.
>
> Good luck,
> Mark

I booted the Gentoo live image and Knoppix.  Knoppix is old.  I don't
think it is being maintained anymore but even on this new hardware, even
it worked.  I've booted other things to and all work fine except the
Gentoo install, the one thing I need to work.  I checked, I did download
Kubuntu but I don't remember trying it.  With my memory tho, I may have
and just don't remember it.  :/  I'll add it to my Ventoy stick and try
it shortly.  It's hot, humid and my energy level isn't much.  The family
visit to the hospital drained me good.  And she is still sick.  I took
her some tomatoes this morning and she likes the peaches I got for her
too.  Not much she can eat. 

I've tried with no xorg.conf at first.  Then I tried with one that tells
it to use the nvidia driver, even tho lsmod shows it loaded and lspci -k
shows it being used.  Then I used nvidia-xconfig to create a conf file. 
Then I tried some options that Michael suggested.  On occasion, it
works.  Most of the time, it doesn't.  To be honest, I'm not sure if
anything we do is affecting it.  I think sometimes things just drop into
place and it works.  Most of the time, things don't drop into place and
it fails or only partially works. 

Given I've used different boot media, a different video card and
different config options, I'm thinking it is the monitor and it just
clashes with this one install but works with others, which may figure
out to ignore what the monitor fails to do.  I find it odd but it is
logical. 

I've tried to use nvidia-settings but the man page is like Greek.  The
one thing I did figure out, -q all.  On my main rig, it spits out TONS
of info.  On the new rig, it just says something like no display found
or something.  It's like two lines, maybe one. 

Had several interruptions so managed to try Kubuntu "Try" option.  It
comes up just fine, correct resolution, plasma is working and all.  I'm
attaching the Xorg log from Kubuntu. 

Maybe the Kubuntu log will shed some light. 

Dale

:-)  :-) 
[27.870] (--) Log file renamed from "/var/log/Xorg.pid-2309.log" to "/var/log/Xorg.0.log"
[27.874] 
X.Org X Server 1.21.1.11
X Protocol Version 11, Revision 0
[27.874] Current Operating System: Linux kubuntu 6.8.0-31-generic #31-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 20 00:40:06 UTC 2024 x86_64
[27.874] Kernel command line: BOOT_IMAGE=/casper/vmlinuz rdinit=/vtoy/vtoy --- quiet splash
[27.874] xorg-server 2:21.1.12-1ubuntu1 (For technical support please see http://www.ubuntu.com/support) 
[27.874] Current version of pixman: 0.42.2
[27.874] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[27.874] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[27.874] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jun 27 15:42:53 2024
[27.875] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[27.875] (==) No Layout section.  Using the first Screen section.
[27.875] (==) No screen section available. Using defaults.
[27.875] (**) |-->Screen "Default Screen Section" (0)
[27.875] (**) |  

Re: [gentoo-user] ldconfig segfaults after updating to 23.0 profil

[Michael]

On Thursday, 27 June 2024 20:11:51 BST Dan Johansson wrote:
> Hello,
> 
> After updating my system to a 23.0 profile,
> default/linux/amd64/23.0/split-usr/desktop/plasma (stable), ldconfig has
> started segfaulting.

The 23.0 profile uses merged /usr as its default.  You can, however, remain 
with a split /usr for now.  What you can't do is mix the two.


> Here are the last few lines of "strace ldconfig":
> newfstatat(AT_FDCWD,
> "/usr/lib/rust/lib/librustc_driver-131b866216b2910c.so",
> {st_mode=S_IFREG|0644, st_size=153456592, ...}, 0) = 0 openat(AT_FDCWD,
> "/usr/lib/llvm/17/lib", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
> fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> getdents64(3, 0x572629d0 /* 22 entries */, 32768) = 824
> newfstatat(AT_FDCWD, "/usr/lib/llvm/17/lib/libclang.so.17",
> {st_mode=S_IFREG|0755, st_size=17506304, ...}, 0) = 0 openat(AT_FDCWD,
> "/usr/lib/llvm/17/lib/libclang.so.17", O_RDONLY) = 4 fstat(4,
> {st_mode=S_IFREG|0755, st_size=17506304, ...}) = 0
> mmap(NULL, 17506304, PROT_READ, MAP_SHARED, 4, 0) = 0x7fb6eb2d3000
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7fb6ed37c4dc}
> --- +++ killed by SIGSEGV +++
> Segmentation fault
> 
> The file in question (I think), does not look suspicious (I think):
> # ls -pal /usr/lib/llvm/17/lib/libclang.so.17
> /usr/lib/llvm/17/lib/libclang.so.17.0.6 lrwxrwxrwx 1 root root   18 Jun
> 25 17:39 /usr/lib/llvm/17/lib/libclang.so.17 -> libclang.so.17.0.6
> -rwxr-xr-x 1 root root 14893056 Jun 25 17:39
> /usr/lib/llvm/17/lib/libclang.so.17.0.6
> 
> The system runs fine (as far as I ca see) but I am a bit nervous about
> rebooting at the moment.
> 
> Any suggestions?

I run a merged /usr profile 23.0, and my libclang.so.17.0.6 is bigger:

# ls -la /usr/lib/llvm/17/lib64/libclang.so.17.0.6 
-rwxr-xr-x 1 root root 32579024 Jun  2 12:15 /usr/lib/llvm/17/lib64/
libclang.so.17.0.6

Have you re-emerged your toolchain and in particular sys-libs/glibc?


signature.asc
Description: This is a digitally signed message part.

[gentoo-user] ldconfig segfaults after updating to 23.0 profil

[Dan Johansson]

Hello,

After updating my system to a 23.0 profile, 
default/linux/amd64/23.0/split-usr/desktop/plasma (stable), ldconfig has 
started segfaulting.

Here are the last few lines of "strace ldconfig":
newfstatat(AT_FDCWD, "/usr/lib/rust/lib/librustc_driver-131b866216b2910c.so", 
{st_mode=S_IFREG|0644, st_size=153456592, ...}, 0) = 0
openat(AT_FDCWD, "/usr/lib/llvm/17/lib", 
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents64(3, 0x572629d0 /* 22 entries */, 32768) = 824
newfstatat(AT_FDCWD, "/usr/lib/llvm/17/lib/libclang.so.17", 
{st_mode=S_IFREG|0755, st_size=17506304, ...}, 0) = 0
openat(AT_FDCWD, "/usr/lib/llvm/17/lib/libclang.so.17", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0755, st_size=17506304, ...}) = 0
mmap(NULL, 17506304, PROT_READ, MAP_SHARED, 4, 0) = 0x7fb6eb2d3000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7fb6ed37c4dc} ---
+++ killed by SIGSEGV +++
Segmentation fault

The file in question (I think), does not look suspicious (I think):
# ls -pal /usr/lib/llvm/17/lib/libclang.so.17 
/usr/lib/llvm/17/lib/libclang.so.17.0.6
lrwxrwxrwx 1 root root   18 Jun 25 17:39 /usr/lib/llvm/17/lib/libclang.so.17 
-> libclang.so.17.0.6
-rwxr-xr-x 1 root root 14893056 Jun 25 17:39 
/usr/lib/llvm/17/lib/libclang.so.17.0.6

The system runs fine (as far as I ca see) but I am a bit nervous about 
rebooting at the moment.

Any suggestions?

Regards,
--
Dan Johansson,
***
This message is printed on 100% recycled electrons!
***

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Mark Knecht]

On Thu, Jun 27, 2024 at 12:03 AM Dale  wrote:
>
> Update.  I played around a bit.  I figured I didn't have a lot to lose
> here.  It either works, or it doesn't.  After playing around a bit, I
> got it to work.  I have not restarted it to see if it will work again,
> yet.  I wanted to grab some log info first, while it is working.  So,
> this part is about when KDE comes up completely but could include some
> attempts that failed.  Comes up completely means, in the correct
> resolution, background image and the panel thing on the bottom, which
> means plasma is running as it should.  I'm doing these inside the email
> instead of as attachments.  Sorry for the length.  I just want to share
> this while I have it available.
>
> This first one, I had a few failures before it succeeded.  I couldn't
> figure out when the working bit started so it is the complete log.
>
>

Hi Dale,
   I have returned home and can once again bottom post.

   There's no way I'm going to read and understand this
whole thread but I did have one question and one comment:

1) Did you ever actually try the Kubunu option that didn't
require an install? I saw you mentions Knoppix and maybe
one other option. Just curious as to what the results were.

2) I see you discussing xorg.conf file which I don't use
here but did you generate this file - if you are really using
it - using the nvidia-settings app, or by hand?

   If your system will stay up I believe nvidia-settings is
recommended by NVidia, or was anyway. It does a good
job of showing the layout and handling options that NVidia
says make their cards work better.

Good luck,
Mark

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Michael]

On Thursday, 27 June 2024 07:54:43 BST Dale wrote:
> Update.  I played around a bit.  I figured I didn't have a lot to lose
> here.  It either works, or it doesn't.  After playing around a bit, I
> got it to work.  I have not restarted it to see if it will work again,
> yet.  I wanted to grab some log info first, while it is working.  So,
> this part is about when KDE comes up completely but could include some
> attempts that failed.  Comes up completely means, in the correct
> resolution, background image and the panel thing on the bottom, which
> means plasma is running as it should.  I'm doing these inside the email
> instead of as attachments.  Sorry for the length.  I just want to share
> this while I have it available.

Your Display Manager (SDDM) works fine.  There is no problem with the the DM.

Your system log does not reveal anything untoward.  The driver components are 
loading fine.  No problem with this either.

Your Xorg.0.log now shows a different port (DP-5) and the monitor bobs up & 
down.  My money is on a buggy EDID.


> [  1236.810] (--) NVIDIA(GPU-0):
> [  1237.031] (--) NVIDIA(GPU-0): LG Electronics W2253 (DFP-5): connected
> [  1237.031] (--) NVIDIA(GPU-0): LG Electronics W2253 (DFP-5): Internal TMDS
> [  1237.031] (--) NVIDIA(GPU-0): LG Electronics W2253 (DFP-5): 300.0 MHz
> maximum pixel clock
[Snip ...]

Are you still plugged into the same physical port on the video card?

If yes, then its designation DFP-? is allocated dynamically.

The monitor is shown to be disconnected a couple of times and eventually 
reconnected.  Again on port DP-5.  Normally this should be on port DP-0 if you 
have plugged it into the first port.


> This is xorg.conf. 

At which point did you originally generate this file?  While the monitor was 
on and running, or after it went sideways?


> Gentoo-1 ~ # cat /etc/X11/xorg.conf
> # nvidia-xconfig: X configuration file generated by nvidia-xconfig
> # nvidia-xconfig:  version 550.90.07
[Snip ...]

> Section "Monitor"
> Identifier "Monitor0"
> VendorName "Unknown"
> ModelName  "Unknown"
> Option "DPMS"
> EndSection

Regenerate the file while the monitor is working and check what/if its details 
come up in the above section.

> #Section "Device"
> #Identifier "Device0"
> #Driver "nvidia"
> #VendorName "NVIDIA Corporation"
> #EndSection
> 
> Section "Device"
> 
>Identifier  "Device0"
> #   Identifier  "nvidia"
>Driver  "nvidia"
>BusID   "PCI:9:0:0"
>Option "UseEDID" "false" ## Comment out this entry for now <==
> 
> EndSection
> 
> Section "Screen"
> Identifier "Screen0"
> Device "Device0"
> Monitor"Monitor0"
> DefaultDepth24
> SubSection "Display"
> Depth   24
> EndSubSection
> EndSection
> 
> Gentoo-1 ~ #
> 
> 
> I took the info you sent and sort of combined it with what
> nvidia-xconfig created.  This is when it worked, this time anyway. 
> Other things I tried did nothing.  Now that I have documented all this,
> I'm going to reboot the rig and see if it works again.  I think we
> already have failed logs but will share what happens. 

Comment out the line: Option "UseEDID" "false"

Let's see if the Monitor shows up in the recreated config file, otherwise 
you'll need to fill in its Model name and sync frequencies to take probing and 
guessing out of the equation.

If this still doesn't work, then you should try to feed its EDID file to the 
card.


> Given I get different results even with the same settings, I'm wondering
> about that monitor.  I've changed video cards so that should eliminate
> that.  The only common thing is the monitor.  Thing is, that monitor
> worked for a long time on my main rig, it also has worked fine on the
> NAS box and the old Dell system as well.  That was very recent I might
> add.  This new system is the only one that has issues with that monitor. 

Were the other PCs using the same DP cable, or HDMI/DVI?  What xorg.conf files 
did they have generated?


> The new monitor should give us clues.  If it just works when it gets
> here, then it is the monitor acting weird.  If it does the same thing,
> there is a config error somewhere.  I can't think of anything else. 

I can think of a buggy monitor EDID.  There are a lot of cheap monitors being 
churned out with average display panels, but bottom dollar chip, bezel and 
stand.  Power saving features introduce their own bugs.  You could check the 
monitor's own menu to disable eco modes and what not, if you keep your monitor 
running 24-7.


> Open to ideas still.  I'd like to get this working.  If for no other
> reason, the new monitor could have the same issue and require some
> special settings somewhere.
> 
> Thanks for all the help.  Sorry to have so much info in one email.  :/  
> At least we have details of when it is working now tho.  :-D

The email line wrap makes things difficult to read.  You can redirect the 

Re: [gentoo-user] Issues.

[Michael]

On Thursday, 27 June 2024 08:16:10 BST Alan Grimes wrote:
> I had updated my machine, rebooted, keyboard started working, thought
> would never see the problem again...
> 
> 
> Had a power failure, came back on line, keyboard broken,
> power went down again, came back on line, keyboard broken.

Is this a USB or PS/2 keyboard?


> also X windows won't start my right hand monitor, workaround is to
> manually yank the cable and reinsert, starts working but that's BS...
> (Display Port)

Primary or secondary monitor, with or without a config file?  Have you swapped 
cables around to a different port?

> Also, Konqueror disappeared so what in god's name am I supposed to use a
> file manager? 

Dolphin?

> It was also the only web browser that I had that was
> compatible with Verizon's broken payment site so I could pay my FIOS
> bill... How am I supposed to do that now, punks?

Does Falkon work?


> Gah, it's annoying as
> hell to have a large chunk of my keyboard not working... There are a lot
> of garbage keyboards out there that don't even have numpads, If I had
> one of those, I would't be able to use this garbage at all, what in
> god's name is going on???


signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Issues.

[Alan Grimes]

I had updated my machine, rebooted, keyboard started working, thought 
would never see the problem again...



Had a power failure, came back on line, keyboard broken,
power went down again, came back on line, keyboard broken.

also X windows won't start my right hand monitor, workaround is to 
manually yank the cable and reinsert, starts working but that's BS... 
(Display Port)



Also, Konqueror disappeared so what in god's name am I supposed to use a 
file manager? It was also the only web browser that I had that was 
compatible with Verizon's broken payment site so I could pay my FIOS 
bill... How am I supposed to do that now, punks?  Gah, it's annoying as 
hell to have a large chunk of my keyboard not working... There are a lot 
of garbage keyboards out there that don't even have numpads, If I had 
one of those, I would't be able to use this garbage at all, what in 
god's name is going on???


--
You can't out-crazy a Democrat.
#EggCrisis  #BlackWinter
White is the new Kulak.
Powers are not rights.

Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Update.  I played around a bit.  I figured I didn't have a lot to lose
here.  It either works, or it doesn't.  After playing around a bit, I
got it to work.  I have not restarted it to see if it will work again,
yet.  I wanted to grab some log info first, while it is working.  So,
this part is about when KDE comes up completely but could include some
attempts that failed.  Comes up completely means, in the correct
resolution, background image and the panel thing on the bottom, which
means plasma is running as it should.  I'm doing these inside the email
instead of as attachments.  Sorry for the length.  I just want to share
this while I have it available.

This first one, I had a few failures before it succeeded.  I couldn't
figure out when the working bit started so it is the complete log.



Gentoo-1 ~ # cat /var/log/Xorg.0.log
[  1236.678] (--) Log file renamed from "/var/log/Xorg.pid-3720.log" to
"/var/log/Xorg.0.log"
[  1236.678]
X.Org X Server 1.21.1.13
X Protocol Version 11, Revision 0
[  1236.678] Current Operating System: Linux Gentoo-1 6.9.4-gentoo #11
SMP PREEMPT_DYNAMIC Sat Jun 22 18:45:21 CDT 2024 x86_64
[  1236.678] Kernel command line: BOOT_IMAGE=/kernel-6.9.4-6
root=UUID=26e58ee4-9c8f-4efd-bbb3-215df71cf85e ro
[  1236.678] 
[  1236.678] Current version of pixman: 0.43.4
[  1236.678]    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
[  1236.678] Markers: (--) probed, (**) from config file, (==) default
setting,
    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1236.678] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jun 27
00:50:03 2024
[  1236.678] (==) Using config file: "/etc/X11/xorg.conf"
[  1236.678] (==) Using config directory: "/etc/X11/xorg.conf.d"
[  1236.678] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  1236.678] (==) ServerLayout "Layout0"
[  1236.678] (**) |-->Screen "Screen0" (0)
[  1236.678] (**) |   |-->Monitor "Monitor0"
[  1236.678] (**) |   |-->Device "Device0"
[  1236.678] (**) |   |-->GPUDevice "nvidia"
[  1236.678] (**) |   |-->GPUDevice "Device0"
[  1236.678] (**) |-->Input Device "Keyboard0"
[  1236.678] (**) |-->Input Device "Mouse0"
[  1236.678] (**) Allowing byte-swapped clients
[  1236.678] (==) Automatically adding devices
[  1236.678] (==) Automatically enabling devices
[  1236.678] (==) Automatically adding GPU devices
[  1236.678] (==) Automatically binding GPU devices
[  1236.678] (==) Max clients allowed: 256, resource mask: 0x1f
[  1236.678] (WW) The directory "/usr/share/fonts/OTF" does not exist.
[  1236.678]    Entry deleted from font path.
[  1236.678] (WW) `fonts.dir' not found (or not valid) in
"/usr/share/fonts/75dpi".
[  1236.678]    Entry deleted from font path.
[  1236.678]    (Run 'mkfontdir' on "/usr/share/fonts/75dpi").
[  1236.678] (==) FontPath set to:
    /usr/share/fonts/misc,
    /usr/share/fonts/TTF,
    /usr/share/fonts/Type1,
    /usr/share/fonts/100dpi
[  1236.678] (==) ModulePath set to "/usr/lib64/xorg/modules"
[  1236.678] (WW) Hotplugging is on, devices using drivers 'kbd',
'mouse' or 'vmmouse' will be disabled.
[  1236.678] (WW) Disabling Keyboard0
[  1236.678] (WW) Disabling Mouse0
[  1236.678] (II) Module ABI versions:
[  1236.678]    X.Org ANSI C Emulation: 0.4
[  1236.678]    X.Org Video Driver: 25.2
[  1236.678]    X.Org XInput driver : 24.4
[  1236.678]    X.Org Server Extension : 10.0
[  1236.678] (++) using VT number 8

[  1236.678] (II) systemd-logind: logind integration requires -keeptty
and -keeptty was not provided, disabling logind integration
[  1236.679] (II) xfree86: Adding drm device (/dev/dri/card0)
[  1236.679] (II) Platform probe for
/sys/devices/pci:00/:00:03.1/:09:00.0/drm/card0
[  1236.799] (--) PCI:*(9@0:0:0) 10de:1cb1:10de:11bc rev 161, Mem @
0xfb00/16777216, 0xd000/268435456, 0xe000/33554432, I/O @
0xe000/128, BIOS @ 0x/524288
[  1236.799] (II) LoadModule: "glx"
[  1236.799] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
[  1236.800] (II) Module glx: vendor="X.Org Foundation"
[  1236.800]    compiled for 1.21.1.13, module version = 1.0.0
[  1236.800]    ABI class: X.Org Server Extension, version 10.0
[  1236.800] (II) LoadModule: "nvidia"
[  1236.800] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so
[  1236.800] (II) Module nvidia: vendor="NVIDIA Corporation"
[  1236.800]    compiled for 1.6.99.901, module version = 1.0.0
[  1236.800]    Module class: X.Org Video Driver
[  1236.800] (II) NVIDIA dlloader X Driver  550.90.07  Fri May 31
09:34:34 UTC 2024
[  1236.800] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
[  1236.803] (II) Loading sub module "fb"
[  1236.803] (II) LoadModule: "fb"
[  1236.803] (II) Module "fb" already built-in
[  1236.803] (II) Loading sub module "wfb"
[  1236.803] (II) LoadModule: "wfb"
[  1236.803] (II) Loading