Re: [gentoo-user] re-activating a netbook

[Michael]

Hi Philip,

On Thursday 19 September 2024 19:39:38 BST Philip Webb wrote:
> Back in 2009, I bought an Asus EEE netbook, 

Which model?  Does it have a 32bit or 64bit CPU instruction set?


[Snip ...]
> I wanted to replace Windows with Linux Mint or another binary distro
> -- avoiding the need to update Gentoo -- , but ran into a problem :
> Horace no longer boots from USB.  I can transfer files via USB stick,
> but can't get a live USB version of Mint etc to start.

If you press F2 on start up you should be able to get into the BIOS menu.  I 
think pressing Esc instead of F2 will show the Boot Order menu, where you can 
select the USB medium to boot from.  You can refer to the ASUS online docs for 
specific model buttons and options.

HOWEVER ... if the netbook CPU is 32bit, then you have to use a x86 LiveUSB, 
because an amd64 instruction set will not run on a 32bit CPU.


> Also, I now use Wifi exclusively -- I no longer have a landline -- ,
> but while Horace can access Wifi, his Gentoo doesn't have Wifi installed,
> so there's a Catch-22 : w/o a landline, I can't install WPA etc.

This is a matter of booting with a LiveUSB which has the necessary drivers/
firmware to drive the WiFi NIC on the netbook, plus configuring 
wpa_supplicant, or networkmanager with your WiFi AP authentication 
credentials.

Your Gentoo installation is too old to try to update/upgrade it, so it is best 
if you reinstall.  Given the inadequate CPU/RAM available on the netbook to 
compile software from source files within reasonable timescales, it is 
advisable you either install Gentoo using binary packages:

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

or install some other binary distro.

Of course, if your netbook has 32bit hardware your choices will be limited.  
You could still install Gentoo, but you'll have to build a 32bit host 
environment on a more powerful PC in order to compile all your 32bit packages 
as binaries and continue to do so each time you want to update your eeePC.  
I'd only recommend this route if you really wish to take it up as a hobby for 
a rainy day ...  ;-)


> One solution mb simply to copy an upto-date Mint ISO
> into the partition now occupied by Windows -- which I don't need --
> & set up Lilo -- which is my prefered boot manager -- to boot from it ;
> Lilo currently allows a choice of Gentoo/Windows.
> 
> Does anyone know if that would work or how to trouble-shoot it ?

Assuming you have found a LiveISO of an OS suitable for your hardware, you 
could copy the ISO on a directory in your Gentoo fs.  Then you will need to 
install GRUB2 and configure '/etc/grub.d/40_custom' to chainload the ISO from 
your disk:

https://wiki.gentoo.org/wiki/GRUB/Chainloading

I am not familiar how to do this with LILO, but I expect you'd have to add a 
new menu entry and specify a kernel cmdline to point it at the path where the 
ISO resides.  Something like this may/might work:

root=iso:/dev/hdaX:/path/to/live_image.iso rootfstype=ext4

HTH.


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

Re: [gentoo-user] re-activating a netbook

[Filip Kobierski]

> Horace no longer boots from USB

IMO that is because you are trying to boot in uefi mode and eeepc needs legacy 
mode.
Try flashing something that supports the legacy mode (MBR and so on).

Also I think reinstalling Gentoo would be easier than upgrading it.
Do you still want to use it? If so, remember about the binhost.


Regards
fkobi

 Original Message 
On 9/19/24 20:39, Philip Webb  wrote:

>  Back in 2009, I bought an Asus EEE netbook, which I called Horace,
>  & installed Gentoo alongside Windows, which I've never used.
>  Gentoo was last updated in 2015 ; the device is in good repair.
>  
>  Recently, I checked Horace & he still does  1  of his intended jobs,
>  ie reading & editing texts of novels etc downloaded from the I/net
>  (the other  2  jobs are no longer required).
>  
>  I wanted to replace Windows with Linux Mint or another binary distro
>  -- avoiding the need to update Gentoo -- , but ran into a problem :
>  Horace no longer boots from USB.  I can transfer files via USB stick,
>  but can't get a live USB version of Mint etc to start.
>  
>  Also, I now use Wifi exclusively -- I no longer have a landline -- ,
>  but while Horace can access Wifi, his Gentoo doesn't have Wifi installed,
>  so there's a Catch-22 : w/o a landline, I can't install WPA etc.
>  
>  One solution mb simply to copy an upto-date Mint ISO
>  into the partition now occupied by Windows -- which I don't need --
>  & set up Lilo -- which is my prefered boot manager -- to boot from it ;
>  Lilo currently allows a choice of Gentoo/Windows.
>  
>  Does anyone know if that would work or how to trouble-shoot it ?
>  
>  --
>  ,,
>  SUPPORT ___//___,   Philip Webb
>  ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
>  TRANSIT`-O--O---'   purslowatcadotinterdotnet
>  
>  
>


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Dale]

Frank Steinmetzger wrote:
> Am Sat, Sep 14, 2024 at 02:46:35PM -0500 schrieb Dale:
>
>> I was running the command again and when I was checking on it, it
>> stopped with this error. 
>>
>>
>>
>>   File "/root/dh", line 1209, in 
>>     main()
>>   File "/root/dh", line 1184, in main
>>     directory_hash(dir_path, '', dir_files, checksums)
>>   File "/root/dh", line 1007, in directory_hash
>>     os.path.basename(old_sums[filename][1])
>>  ^^
>> KeyError: 'Some Video.mp4'
> What was the exact command with which you ran it?
> Apparently the directory has a file 'Some Video.mp4', which was not listed 
> in an existing checksum file.

I'm fairly sure it was this command. 


/root/dh -c -f -F 1Checksums.md5 -v


I may have changed the -c to -u because I think it was the second run. 
I'd start with the thought it was -u if it were me.  There's another
command running right now and I cleared the scrollback part.  Once it
finishes, I can up arrow and be more sure.  At the moment, I'm letting
it test the files against the checksum it created, to be sure everything
is good.  It's almost half way through and no problems so far. 

I might add, I did a second run with -u, which I think produced the
error above, and it seems to have missed some directories.  When looking
I noticed some directories didn't have a checksum file in it.  That's
when I ran it a second time.  It skipped the ones it already did but
found the ones that was missed in first run.  There are almost 46,000
files in almost 800 directories.  Is there some tool your script relies
on that could make one of those numbers to high? 

> I also noticed a problem recently which happens if you give dh a directory 
> as argument which has no checksum file in it. Or something like it, I can’t 
> reproduce it from memory right now. I have been doing some refactoring 
> recently in order to get one-file-per-tree mode working.
>
>> I was doing a second run because I updated some files.  So, it was
>> skipping some and creating new for some new ones.  This is the command I
>> was running, which may not be the best way. 
>>
>>
>> /root/dh -c -f -F 1Checksums.md5 -v
> Yeah, using the -c option will clobber any old checksums and re-read all 
> files fresh. If you only changed a few files, using the -u option will 
> drastically increase speed because only the changed files will be read.
> Use the -d option to clean up dangling entries from checksum files.

That was my thinking.  When I update a set, I'll likely just cd to that
directory and update, -u, that one directory instead of everything. 
That will save time and all.  Doing everything takes days.  LOL


>
>> Also, what is the best way to handle this type of situation.  Let's say
>> I have a set of videos.  Later on I get a better set of videos, higher
>> resolution or something.  I copy those to a temporary directory then use
>> your dmv script from a while back to replace the old files with the new
>> files but with identical names.  Thing is, file is different, sometimes
>> a lot different.  What is the best way to get it to update the checksums
>> for the changed files?  Is the command above correct? 
> dh has some smarts built-in. If you changed a file, then its modification 
> timestamp will get udpated. When dh runs in -u mode and it finds a file 
> whose timestamp is newer than its associated checksum file, that means the 
> file may have been altered since the creation of that checksum. So dh will 
> re-hash the file and replace the checksum in the checksum file.
>

Sounds good.  I wasn't sure if it would see the change or not. 


>> I'm sometimes pretty good at finding software bugs.  But hey, it just
>> makes your software better.  ;-) 
> Me too, usually. If it’s not my software, anyways. ^^
> But I think you may be the first other of that tool other than me.
>


One thing I've noticed, when I run this tool, my video sputters at
times.  It does fine when not running.  This tool makes that set of hard
drives pretty busy.  It might be nice to add a ionice setting.  I'd just
set it inside the script.  If a person wants, they can edit and change
it.  Just set it to a little lower than normal stuff should be fine.  If
I restart smplayer, I may set its ionice to a higher priority.  Just a
thought and likely easy enough to do.  I don't want to stop your script
given it is so far along.

It sometimes pops up a question.  I figured out that I type in the
answer with the letter that is in parentheses.  Could you explain the
options a bit just to be sure I understand it correctly? 

So far, this is a nice tool.  It should find corruption, like my bad
memory stick, bit rot, bad drive or anything else that could corrupt a
file.  Even power failure I'd think.  It takes a while to do the
checksums but the script itself is fast.  Once you really happy with
this and feel like it is ready, you should really make a announcement
that it is ready.  Anyone who does a lot of write once and 

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Frank Steinmetzger]

Am Sat, Sep 14, 2024 at 02:46:35PM -0500 schrieb Dale:

> I was running the command again and when I was checking on it, it
> stopped with this error. 
> 
> 
> 
>   File "/root/dh", line 1209, in 
>     main()
>   File "/root/dh", line 1184, in main
>     directory_hash(dir_path, '', dir_files, checksums)
>   File "/root/dh", line 1007, in directory_hash
>     os.path.basename(old_sums[filename][1])
>  ^^
> KeyError: 'Some Video.mp4'

What was the exact command with which you ran it?
Apparently the directory has a file 'Some Video.mp4', which was not listed 
in an existing checksum file.

I also noticed a problem recently which happens if you give dh a directory 
as argument which has no checksum file in it. Or something like it, I can’t 
reproduce it from memory right now. I have been doing some refactoring 
recently in order to get one-file-per-tree mode working.

> I was doing a second run because I updated some files.  So, it was
> skipping some and creating new for some new ones.  This is the command I
> was running, which may not be the best way. 
> 
> 
> /root/dh -c -f -F 1Checksums.md5 -v

Yeah, using the -c option will clobber any old checksums and re-read all 
files fresh. If you only changed a few files, using the -u option will 
drastically increase speed because only the changed files will be read.
Use the -d option to clean up dangling entries from checksum files.


> Also, what is the best way to handle this type of situation.  Let's say
> I have a set of videos.  Later on I get a better set of videos, higher
> resolution or something.  I copy those to a temporary directory then use
> your dmv script from a while back to replace the old files with the new
> files but with identical names.  Thing is, file is different, sometimes
> a lot different.  What is the best way to get it to update the checksums
> for the changed files?  Is the command above correct? 

dh has some smarts built-in. If you changed a file, then its modification 
timestamp will get udpated. When dh runs in -u mode and it finds a file 
whose timestamp is newer than its associated checksum file, that means the 
file may have been altered since the creation of that checksum. So dh will 
re-hash the file and replace the checksum in the checksum file.


> I'm sometimes pretty good at finding software bugs.  But hey, it just
> makes your software better.  ;-) 

Me too, usually. If it’s not my software, anyways. ^^
But I think you may be the first other of that tool other than me.

-- 
Grüße | Greetings | Salut | Qapla’
Someone who eats oats for 200 years becomes very old.


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Dale]

Frank Steinmetzger wrote:
> Am Fri, Sep 06, 2024 at 01:21:20PM +0100 schrieb Michael:
>
 find path-to-directory/ -type f | xargs md5sum > digest.log

 then to compare with a backup of the same directory you could run:

 md5sum -c digest.log | grep FAILED
> I had a quick look at the manpage: with md5sum --quiet you can omit the grep 
> part.
>
 Someone more knowledgeable should be able to knock out some clever python
 script to do the same at speed.
> And that is exactly what I have written for myself over the last 11 years. I 
> call it dh (short for dirhash). As I described in the previous mail, I use 
> it to create one hash files per directory. But it also supports one hash 
> file per data file and – a rather new feature – one hash file at the root of 
> a tree. Have a look here: https://github.com/felf/dh
> Clone the repo or simply download the one file and put it into your path.
>
>>> I'll be honest here, on two points.  I'd really like to be able to do
>>> this but I have no idea where to or how to even start.  My setup for
>>> series type videos.  In a parent directory, where I'd like a tool to
>>> start, is about 600 directories.  On a few occasions, there is another
>>> directory inside that one.  That directory under the parent is the name
>>> of the series.
> In its default, my tool ignores directories which have subdirectories. It 
> only hashes files in dirs that have no subdirs (leaves in the tree). But 
> this can be overridden with the -f option.
>
> My tool also has an option to skip a number of directories and to process 
> only a certain number of directories.
>
>>> Sometimes I have a sub directory that has temp files;
>>> new files I have yet to rename, considering replacing in the main series
>>> directory etc.  I wouldn't mind having a file with a checksum for each
>>> video in the top directory, and even one in the sub directory.  As a
>>> example.
>>>
>>> TV_Series/
>>>
>>> ├── 77 Sunset Strip (1958)
>>> │   └── torrent
>>> ├── Adam-12 (1968)
>>> ├── Airwolf (1984)
> So with my tool you would do
> $ dh -f -F all TV_Series
> `-F all` causes a checksum file to be created for each data file.
>
>>> What
>>> I'd like, a program that would generate checksums for each file under
>>> say 77 Sunset and it could skip or include the directory under it.
> Unfortunately I don’t have a skip feature yet that skips specific 
> directories. I could add a feature that looks for a marker file and then 
> skips that directory (and its subdirs).
>

I was running the command again and when I was checking on it, it
stopped with this error. 



  File "/root/dh", line 1209, in 
    main()
  File "/root/dh", line 1184, in main
    directory_hash(dir_path, '', dir_files, checksums)
  File "/root/dh", line 1007, in directory_hash
    os.path.basename(old_sums[filename][1])
 ^^
KeyError: 'Some Video.mp4'



I was doing a second run because I updated some files.  So, it was
skipping some and creating new for some new ones.  This is the command I
was running, which may not be the best way. 


/root/dh -c -f -F 1Checksums.md5 -v


That make any sense to you?  That's all it spit out. 

Also, what is the best way to handle this type of situation.  Let's say
I have a set of videos.  Later on I get a better set of videos, higher
resolution or something.  I copy those to a temporary directory then use
your dmv script from a while back to replace the old files with the new
files but with identical names.  Thing is, file is different, sometimes
a lot different.  What is the best way to get it to update the checksums
for the changed files?  Is the command above correct? 

I'm sometimes pretty good at finding software bugs.  But hey, it just
makes your software better.  ;-) 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Wol]

On 08/09/2024 10:15, Michael wrote:

The placement of DIMMs depends on the MoBo, its manual would show in which
slot should DIMM modules be added and the (maximum) size of each stick the
MoBo can cope with.  Normally OEMs provide a list of tested memory brands and
models for their MoBos (QVL) and it is recommended to buy something on the
list, rather than improvise.


Both old and new mobos are, iirc, 4 x 32GB, and they just swapped the 
RAM over. But again iirc, the new mobo they supplied had two colours of 
ram slots, something like "black, red, black, red". To me that's obvious 
- both sticks in one colour! So - and I guess it was an apprentice who 
didn't know what he was doing - just shoved the ram in the first two slots.


Two major blunders from a shop - a brand new mobo won't boot - the FIRST 
suspect is an out-of-date bios. And then the second blunder - don't 
check the ram is in the right slots. That's one shop I certainly won't 
visit again.


(The only reason I asked a shop to fix it was because I didn't have an 
old chip so couldn't boot the board to upgrade the bios to work with the 
chip I had ...)


Cheers,
Wol

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Michael]

On Sunday 8 September 2024 02:59:04 BST Dale wrote:
> Wols Lists wrote:
> > On 04/09/2024 01:39, Dale wrote:
> >> I've seen that before too.  I'm hoping not.  I may shutdown my rig,
> >> remove and reinstall the memory and then test it for a bit.  May be a
> >> bad connection.  It has worked well for the past couple months tho.
> >> Still, it is possible to either be a bad connection or just going bad.
> > 
> > I've had *MOST* of my self-built systems force me to remove and
> > replace the ram several times before the system was happy.
> > 
> > And when a shop "fixed" my computer for me (replacing a mobo that
> > wasn't broken - I told them I thought it needed a bios upgrade and I
> > was right!) they also messed up the ram. Memory is supposed to go in
> > in matched pairs. So what do they do? One stick in each pair of slots
> > - the thing ran like a sloth on tranquillisers! As soon as I realised
> > what they'd done and put both sticks in the same pair, it was MUCH
> > faster.
> > 
> > Cheers,
> > Wol
> 
> I noticed on the set I had to return, the serial numbers were in
> sequence.  One was right after the other.  I don't know if that makes
> them a matched set or if they run some test to match them. 

Both.  They run a test, if one fails in their hands as opposed to yours, they 
pick up the next module and test that.  So you typically end up with numbers 
in a matched kit which are close enough.


> From my understanding tho, each 'bank' or pair has to be a matched set. 
> I did finally find a set of four but it is a different brand.  From what
> I read to tho, ASUS trains itself each time you boot up.  It finds the
> best setting for each set of memory.  It does say that it is usually set
> to a slower speed tho when all four are installed.

It depends if your MoBo comes with 'daisy chain' or 'T topology' RAM slot 
configuration.  Most consumer grade come with 'daisy chain' configuration and 
ASUS may also have an "Optimem" function/feature as they call it.

With 'daisy chain' you should achieve higher max. frequency if you fit 2 
matched DIMMs in the slots the manual suggests (typically B2 & A2), than if 
you fit 4 DIMMs to achieve the same total RAM size.

With 'T topology' you'll achieve a lower frequency with 2 DIMMs, but a higher 
frequency with 4 DIMMs at the same total RAM size, than you would with a 
'daisy chain' MoBo.

The ASUS "Optimem" is some automagic run by the firmware of their 'daisy 
chain' MoBos in terms of voltage and signal sequencing, to do the best job it 
can when you have 4 DIMMs installed.


> Just have to wait
> and see I guess.  Oh, when I boot the first couple times with new
> memory, it takes quite a bit longer on the BIOS boot screen.  After a
> couple times, it doesn't seem to take so long.  Not sure what, but it
> does something. 

The memory controller on the CPU probes the memory module(s) by varying 
voltage and latency until it achieves a reliable result.  If you have enabled 
DOCP as advised here and if provided in the BIOS also selected the RAM 
frequency of the DIMMs you bought, then the probing ought to take less time:

https://www.asus.com/support/faq/1042256/

Unless ... there's something wrong with the system (power, faulty RAM modules, 
buggy BIOS, etc.).


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

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Michael]

On Saturday 7 September 2024 23:48:43 BST Wols Lists wrote:
> On 05/09/2024 23:06, Michael wrote:
> > There is also dm-verity for a more involved solution.  I think for Dale
> > something like this should work:
> Snag is, I think dm-verity (or do you actually mean dm-integrity, which
> is what I use) merely checks that what you read from disk is what you
> wrote to disk. If the ram corrupted it before it was written, I don't
> think either of them will detect it.
> 
> Cheers,
> Wol

My bad, apologies, dm-verity is used to verify the boot path and deals with 
read-only fs.  With FEC it would also be able to recover from some limited 
data corruption.  I meant to write *dm-integrity*!  Thanks for correcting me.  
Either way, if the data being written is corrupted due to faulty RAM, the 
result will be corrupted too.

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

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Michael]

On Saturday 7 September 2024 23:12:41 BST Wols Lists wrote:
> On 04/09/2024 01:39, Dale wrote:
> > I've seen that before too.  I'm hoping not.  I may shutdown my rig,
> > remove and reinstall the memory and then test it for a bit.  May be a
> > bad connection.  It has worked well for the past couple months tho.
> > Still, it is possible to either be a bad connection or just going bad.
> 
> I've had *MOST* of my self-built systems force me to remove and replace
> the ram several times before the system was happy.
> 
> And when a shop "fixed" my computer for me (replacing a mobo that wasn't
> broken - I told them I thought it needed a bios upgrade and I was
> right!) they also messed up the ram. Memory is supposed to go in in
> matched pairs. So what do they do? One stick in each pair of slots - the
> thing ran like a sloth on tranquillisers! 

The placement of DIMMs depends on the MoBo, its manual would show in which 
slot should DIMM modules be added and the (maximum) size of each stick the 
MoBo can cope with.  Normally OEMs provide a list of tested memory brands and 
models for their MoBos (QVL) and it is recommended to buy something on the 
list, rather than improvise.

On ASUS MoBos with 4 slots and 2 DIMMs it is recommended you use slot B2 for 
one module, slots B2 and A2 for a pair of matched modules and the the 
remaining two slots A1 & B1 for a second pair of matched modules.  So, what 
the shop did would be reasonable, unless the MoBo OEM asked for a different 
configuration.


> As soon as I realised what
> they'd done and put both sticks in the same pair, it was MUCH faster.
> 
> Cheers,
> Wol

Sometimes, you have to place only one module of a matched pair in and boot the 
system, let the firmware probe and test the DIMM, before you shut it down to 
add more memory to it.  Whenever RAM does not behave as it should when 
installing it, it is a prompt for me to go back to the OEM manual for guidance 
on the peculiarities of their product.

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

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Dale]

Wols Lists wrote:
> On 04/09/2024 01:39, Dale wrote:
>> I've seen that before too.  I'm hoping not.  I may shutdown my rig,
>> remove and reinstall the memory and then test it for a bit.  May be a
>> bad connection.  It has worked well for the past couple months tho.
>> Still, it is possible to either be a bad connection or just going bad.
>
> I've had *MOST* of my self-built systems force me to remove and
> replace the ram several times before the system was happy.
>
> And when a shop "fixed" my computer for me (replacing a mobo that
> wasn't broken - I told them I thought it needed a bios upgrade and I
> was right!) they also messed up the ram. Memory is supposed to go in
> in matched pairs. So what do they do? One stick in each pair of slots
> - the thing ran like a sloth on tranquillisers! As soon as I realised
> what they'd done and put both sticks in the same pair, it was MUCH
> faster.
>
> Cheers,
> Wol
>
>


I noticed on the set I had to return, the serial numbers were in
sequence.  One was right after the other.  I don't know if that makes
them a matched set or if they run some test to match them. 

>From my understanding tho, each 'bank' or pair has to be a matched set. 
I did finally find a set of four but it is a different brand.  From what
I read to tho, ASUS trains itself each time you boot up.  It finds the
best setting for each set of memory.  It does say that it is usually set
to a slower speed tho when all four are installed.  Just have to wait
and see I guess.  Oh, when I boot the first couple times with new
memory, it takes quite a bit longer on the BIOS boot screen.  After a
couple times, it doesn't seem to take so long.  Not sure what, but it
does something. 

This new way sure is strange. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Wols Lists]

On 05/09/2024 23:06, Michael wrote:

There is also dm-verity for a more involved solution.  I think for Dale
something like this should work:


Snag is, I think dm-verity (or do you actually mean dm-integrity, which 
is what I use) merely checks that what you read from disk is what you 
wrote to disk. If the ram corrupted it before it was written, I don't 
think either of them will detect it.


Cheers,
Wol

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Wols Lists]

On 04/09/2024 01:39, Dale wrote:

I've seen that before too.  I'm hoping not.  I may shutdown my rig,
remove and reinstall the memory and then test it for a bit.  May be a
bad connection.  It has worked well for the past couple months tho.
Still, it is possible to either be a bad connection or just going bad.


I've had *MOST* of my self-built systems force me to remove and replace 
the ram several times before the system was happy.


And when a shop "fixed" my computer for me (replacing a mobo that wasn't 
broken - I told them I thought it needed a bios upgrade and I was 
right!) they also messed up the ram. Memory is supposed to go in in 
matched pairs. So what do they do? One stick in each pair of slots - the 
thing ran like a sloth on tranquillisers! As soon as I realised what 
they'd done and put both sticks in the same pair, it was MUCH faster.


Cheers,
Wol

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Mark Knecht]

On Fri, Sep 6, 2024 at 2:42 PM Frank Steinmetzger  wrote:
>
> Am Fri, Sep 06, 2024 at 01:21:20PM +0100 schrieb Michael:
>
> > > > find path-to-directory/ -type f | xargs md5sum > digest.log
> > > >
> > > > then to compare with a backup of the same directory you could run:
> > > >
> > > > md5sum -c digest.log | grep FAILED
>
> I had a quick look at the manpage: with md5sum --quiet you can omit the
grep
> part.
>
> > > > Someone more knowledgeable should be able to knock out some clever
python
> > > > script to do the same at speed.
>
> And that is exactly what I have written for myself over the last 11
years. I
> call it dh (short for dirhash). As I described in the previous mail, I use
> it to create one hash files per directory. But it also supports one hash
> file per data file and – a rather new feature – one hash file at the root
of
> a tree. Have a look here: https://github.com/felf/dh
> Clone the repo or simply download the one file and put it into your path.
>

Thanks for sharing this Frank.

Much appreciated.

Cheers,
Mark

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Frank Steinmetzger]

Am Sat, Sep 07, 2024 at 10:37:04AM +0100 schrieb Michael:
> On Friday 6 September 2024 22:41:33 BST Frank Steinmetzger wrote:

> > > > > Someone more knowledgeable should be able to knock out some clever
> > > > > python
> > > > > script to do the same at speed.
> > 
> > And that is exactly what I have written for myself over the last 11 years. I
> > call it dh (short for dirhash). As I described in the previous mail, I use
> > it to create one hash files per directory. But it also supports one hash
> > file per data file and – a rather new feature – one hash file at the root
> > of a tree. Have a look here: https://github.com/felf/dh
> > Clone the repo or simply download the one file and put it into your path.
> 
> Nice!  I've tested it briefly here.  You've put quite some effort into this.  
> Thank you Frank!
> 
> Probably not your use case, but I wonder how it can be used to compare SOURCE 
> to DESTINATION where SOURCE is the original fs and DESTINATION is some 
> backup, 
> without having to copy over manually all different directory/subdirectory 
> Checksums.md5 files.

When I have this problem, I usually diff the checksum files with mc or vim, 
because I don’t usually have to check many directories and files. You could 
use Krusader, a two-panel file manager. This has a synchronise tool with a 
file filter, so you synchronize two sides, check for file content and filter 
for *.md5.

> I suppose rsync can be used for the comparison to a backup fs anyway, your 
> script would be duplicating a function unnecessarily.

I believe rsync is capable of only syncing only files that match a pattern. 
But it was not very easy to achieve, I think.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

They say that memory is the second thing to go...
I forgot what the first thing was.


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Michael]

On Friday 6 September 2024 22:41:33 BST Frank Steinmetzger wrote:
> Am Fri, Sep 06, 2024 at 01:21:20PM +0100 schrieb Michael:
> > > > find path-to-directory/ -type f | xargs md5sum > digest.log
> > > > 
> > > > then to compare with a backup of the same directory you could run:
> > > > 
> > > > md5sum -c digest.log | grep FAILED
> 
> I had a quick look at the manpage: with md5sum --quiet you can omit the grep
> part.

Good catch.  You can tell I didn't spend much effort to come up with this. ;-)


> > > > Someone more knowledgeable should be able to knock out some clever
> > > > python
> > > > script to do the same at speed.
> 
> And that is exactly what I have written for myself over the last 11 years. I
> call it dh (short for dirhash). As I described in the previous mail, I use
> it to create one hash files per directory. But it also supports one hash
> file per data file and – a rather new feature – one hash file at the root
> of a tree. Have a look here: https://github.com/felf/dh
> Clone the repo or simply download the one file and put it into your path.

Nice!  I've tested it briefly here.  You've put quite some effort into this.  
Thank you Frank!

Probably not your use case, but I wonder how it can be used to compare SOURCE 
to DESTINATION where SOURCE is the original fs and DESTINATION is some backup, 
without having to copy over manually all different directory/subdirectory 
Checksums.md5 files.

I suppose rsync can be used for the comparison to a backup fs anyway, your 
script would be duplicating a function unnecessarily.


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

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Dale]

Michael wrote:
> On Friday 6 September 2024 21:15:32 BST Dale wrote:
>
>> Update.  New memory sticks i bought came in today.  I ran memtest from
>> Gentoo Live boot media and it passed.  Of course, the last pair passed
>> when new too so let's hope this one lasts longer.  Much longer. 
> Run each new stick on its own overnight.  Some times errors do not show up 
> until a few full cycles of tests have been run.

I've already booted into my OS now.  So far, it's seems OK.  Of course,
the last ones didn't fail for a few months.  I can't test that long
anyway.  ;-)  At least they not bad out of the box.  At first test anyway. 

I think the way the tests run now, it runs several different tests on
each section looking for it to return a incorrect result.  I think I saw
it say 10 tests or something.  The memtest I used was on the Gentoo Live
image from a few months ago.  It tests 1GB at a time.  Takes a while to
complete each test.  I know there are many ways to test memory tho.  I
don't recall ever having a stick of memory to go bad before.  For some
old junk rigs that are pretty much to old to care, I've put some cheap
brands in them and they still worked.  Oh, one of my f's returned a 7. 
I took a picture.  I printed it and included it with the memory.  That
way they may can tell where to start their test.  It was right at 7GB
mark. 

I did start the return process.  I filled out a online form and they
sent me a email a few hours later with a RMA.  I got a label printed and
boxed it up.  I'll go to the post office tomorrow.  It'll take several
days to get there tho.  No idea on how long it takes G.Skill to turn it
around.  Then it has to slide all the way back to me.  I figure two
weeks for shipping alone. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Michael]

On Friday 6 September 2024 21:15:32 BST Dale wrote:

> Update.  New memory sticks i bought came in today.  I ran memtest from
> Gentoo Live boot media and it passed.  Of course, the last pair passed
> when new too so let's hope this one lasts longer.  Much longer. 

Run each new stick on its own overnight.  Some times errors do not show up 
until a few full cycles of tests have been run.


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

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Frank Steinmetzger]

Am Fri, Sep 06, 2024 at 01:21:20PM +0100 schrieb Michael:

> > > find path-to-directory/ -type f | xargs md5sum > digest.log
> > > 
> > > then to compare with a backup of the same directory you could run:
> > > 
> > > md5sum -c digest.log | grep FAILED

I had a quick look at the manpage: with md5sum --quiet you can omit the grep 
part.

> > > Someone more knowledgeable should be able to knock out some clever python
> > > script to do the same at speed.

And that is exactly what I have written for myself over the last 11 years. I 
call it dh (short for dirhash). As I described in the previous mail, I use 
it to create one hash files per directory. But it also supports one hash 
file per data file and – a rather new feature – one hash file at the root of 
a tree. Have a look here: https://github.com/felf/dh
Clone the repo or simply download the one file and put it into your path.

> > I'll be honest here, on two points.  I'd really like to be able to do
> > this but I have no idea where to or how to even start.  My setup for
> > series type videos.  In a parent directory, where I'd like a tool to
> > start, is about 600 directories.  On a few occasions, there is another
> > directory inside that one.  That directory under the parent is the name
> > of the series.

In its default, my tool ignores directories which have subdirectories. It 
only hashes files in dirs that have no subdirs (leaves in the tree). But 
this can be overridden with the -f option.

My tool also has an option to skip a number of directories and to process 
only a certain number of directories.

> > Sometimes I have a sub directory that has temp files;
> > new files I have yet to rename, considering replacing in the main series
> > directory etc.  I wouldn't mind having a file with a checksum for each
> > video in the top directory, and even one in the sub directory.  As a
> > example.
> > 
> > TV_Series/
> > 
> > ├── 77 Sunset Strip (1958)
> > │   └── torrent
> > ├── Adam-12 (1968)
> > ├── Airwolf (1984)

So with my tool you would do
$ dh -f -F all TV_Series
`-F all` causes a checksum file to be created for each data file.

> > What
> > I'd like, a program that would generate checksums for each file under
> > say 77 Sunset and it could skip or include the directory under it.

Unfortunately I don’t have a skip feature yet that skips specific 
directories. I could add a feature that looks for a marker file and then 
skips that directory (and its subdirs).

> > Might be best if I could switch it on or off.  Obviously, I may not want
> > to do this for my whole system.  I'd like to be able to target
> > directories.  I have another large directory, lets say not a series but
> > sometimes has remakes, that I'd also like to do.  It is kinda set up
> > like the above, parent directory with a directory underneath and on
> > occasion one more under that. 
> 
> As an example, let's assume you have the following fs tree:
> 
> VIDEO
>   ├──TV_Series/
>   |  ├── 77 Sunset Strip (1958)
>   |  │   └── torrent
>   |  ├── Adam-12 (1968)
>   |  ├── Airwolf (1984)
>   |
>   ├──Documentaries
>   ├──Films
>   ├──etc.
> 
> You could run:
> 
> $ find VIDEO -type f | xargs md5sum > digest.log
> 
> The file digest.log will contain md5sum hashes of each of your files within 
> the VIDEO directory and its subdirectories.
> 
> To check if any of these files have changed, become corrupted, etc. you can 
> run:
> 
> $ md5sum -c digest.log | grep FAILED
> 
> If you want to compare the contents of the same VIDEO directory on a back up, 
> you can copy the same digest file with its hashes over to the backup top 
> directory and run again:
> 
> $ md5sum -c digest.log | grep FAILED

My tool does this as well. ;-)
In check mode, it recurses, looks for hash files and if it finds them, 
checks all hashes. There is also an option to only check paths and 
filenames, not hashes. This allows to quickly find files that have been 
renamed or deleted since the hash file was created.

> > One thing I worry about is not just memory problems, drive failure but
> > also just some random error or even bit rot.  Some of these files are
> > rarely changed or even touched.  I'd like a way to detect problems and
> > there may even be a software tool that does this with some setup,
> > reminds me of Kbackup where you can select what to backup or leave out
> > on a directory or even individual file level. 

Well that could be covered with ZFS, especially with a redundant pool so it 
can repair itself. Otherwise it will only identify the bitrot, but not be 
able to fix it.

> > Right now, I suspect my backup copy is likely better than my main copy. 

The problem is: if they differ, how do you know which one is good apart from 
watching one from start to finish? You could use vbindiff to first find the 
part that changed. That will at least tell you where the difference is, so 
you could seek to the area of the position in the video.

> This should work in rsync terms:
> 
> rsync -v --checksum 

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Dale]

Dale wrote:
> Grant Edwards wrote:
>> On 2024-09-03, Dale  wrote:
>>
>>> I was trying to re-emerge some packages.  The ones I was working on
>>> failed with "internal compiler error: Segmentation fault" or similar
>>> being the common reason for failing.
>> In my experience, that usually means failing RAM.  I'd try running
>> memtest86 for a day or two.
>>
>> --
>> Grant
> I've seen that before too.  I'm hoping not.  I may shutdown my rig,
> remove and reinstall the memory and then test it for a bit.  May be a
> bad connection.  It has worked well for the past couple months tho. 
> Still, it is possible to either be a bad connection or just going bad. 
>
> Dang those memory sticks ain't cheap.  o_~
>
> Thanks.  See if anyone else has any other ideas. 
>
> Dale
>
> :-)  :-) 
>


Update.  New memory sticks i bought came in today.  I ran memtest from
Gentoo Live boot media and it passed.  Of course, the last pair passed
when new too so let's hope this one lasts longer.  Much longer. 

Now to start the warranty swap process.  :/

Dale

:-)  :-) 

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Michael]

On Friday 6 September 2024 01:43:18 BST Dale wrote:
> Michael wrote:
> > On Thursday 5 September 2024 19:55:56 BST Frank Steinmetzger wrote:
> >> Am Thu, Sep 05, 2024 at 06:30:54AM -0500 schrieb Dale:
>  Use rsync with:
>   --checksum
>  
>  and
>  
>   --dry-run
> >> 
> >> I suggest calculating a checksum file from your active files. Then you
> >> don’t have to read the files over and over for each backup iteration you
> >> compare it against.
> >> 
>  You can also run find to identify which files were changed during the
>  period you were running with the dodgy RAM.  Thankfully you didn't run
>  for too long before you spotted it.
> >> 
> >> This. No need to check everything you ever stored. Just the most recent
> >> stuff, or at maximum, since you got the new PC.
> >> 
> >>> I have just shy of 45,000 files in 780 directories or so.  Almost 6,000
> >>> in another.  Some files are small, some are several GBs or so.  Thing
> >>> is, backups go from a single parent directory if you will.  Plus, I'd
> >>> want to compare them all anyway.  Just to be sure.
> >> 
> >> I aqcuired the habit of writing checksum files in all my media
> >> directories
> >> such as music albums, tv series and such, whenever I create one such
> >> directory. That way even years later I can still check whether the files
> >> are intact. I actually experienced broken music files from time to time
> >> (mostly on the MicroSD card in my tablet). So with checksum files, I can
> >> verify which file is bad and which (on another machine) is still good.
> > 
> > There is also dm-verity for a more involved solution.  I think for Dale
> > something like this should work:
> > 
> > find path-to-directory/ -type f | xargs md5sum > digest.log
> > 
> > then to compare with a backup of the same directory you could run:
> > 
> > md5sum -c digest.log | grep FAILED
> > 
> > Someone more knowledgeable should be able to knock out some clever python
> > script to do the same at speed.
> 
> I'll be honest here, on two points.  I'd really like to be able to do
> this but I have no idea where to or how to even start.  My setup for
> series type videos.  In a parent directory, where I'd like a tool to
> start, is about 600 directories.  On a few occasions, there is another
> directory inside that one.  That directory under the parent is the name
> of the series.  Sometimes I have a sub directory that has temp files;
> new files I have yet to rename, considering replacing in the main series
> directory etc.  I wouldn't mind having a file with a checksum for each
> video in the top directory, and even one in the sub directory.  As a
> example.
> 
> TV_Series/
> 
> ├── 77 Sunset Strip (1958)
> │   └── torrent
> ├── Adam-12 (1968)
> ├── Airwolf (1984)
> 
> 
> I got a part of the output of tree.  The directory 'torrent' under 77
> Sunset is temporary usually but sometimes a directory is there for
> videos about the making of a video, history of it or something.  What
> I'd like, a program that would generate checksums for each file under
> say 77 Sunset and it could skip or include the directory under it. 
> Might be best if I could switch it on or off.  Obviously, I may not want
> to do this for my whole system.  I'd like to be able to target
> directories.  I have another large directory, lets say not a series but
> sometimes has remakes, that I'd also like to do.  It is kinda set up
> like the above, parent directory with a directory underneath and on
> occasion one more under that. 

As an example, let's assume you have the following fs tree:

VIDEO
  ├──TV_Series/
  |  ├── 77 Sunset Strip (1958)
  |  │   └── torrent
  |  ├── Adam-12 (1968)
  |  ├── Airwolf (1984)
  |
  ├──Documentaries
  ├──Films
  ├──etc.

You could run:

$ find VIDEO -type f | xargs md5sum > digest.log

The file digest.log will contain md5sum hashes of each of your files within 
the VIDEO directory and its subdirectories.

To check if any of these files have changed, become corrupted, etc. you can 
run:

$ md5sum -c digest.log | grep FAILED

If you want to compare the contents of the same VIDEO directory on a back up, 
you can copy the same digest file with its hashes over to the backup top 
directory and run again:

$ md5sum -c digest.log | grep FAILED

Any files listed with "FAILED" next to them have changed since the backup was 
originally created.  Any files with "FAILED open or read" have been deleted, 
or are inaccessible.

You don't have to use md5sum, you can use sha1sum, sha256sum, etc. but md5sum 
will be quicker.  The probability of ending up with a hash clash across two 
files must be very small.

You can save the digest file with a date, PC name, top directory name next to 
it, to make it easy to identify when it was created and its origin.  
Especially useful if you move it across systems.


> One thing I worry about is not just memory problems, drive failure but
> also just some random error or even bit rot.  Some of these files are
> rarel

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Dale]

Michael wrote:
> On Thursday 5 September 2024 19:55:56 BST Frank Steinmetzger wrote:
>> Am Thu, Sep 05, 2024 at 06:30:54AM -0500 schrieb Dale:
 Use rsync with:
  --checksum

 and

  --dry-run
>> I suggest calculating a checksum file from your active files. Then you don’t
>> have to read the files over and over for each backup iteration you compare
>> it against.
>>
 You can also run find to identify which files were changed during the
 period you were running with the dodgy RAM.  Thankfully you didn't run
 for too long before you spotted it.
>> This. No need to check everything you ever stored. Just the most recent
>> stuff, or at maximum, since you got the new PC.
>>
>>> I have just shy of 45,000 files in 780 directories or so.  Almost 6,000
>>> in another.  Some files are small, some are several GBs or so.  Thing
>>> is, backups go from a single parent directory if you will.  Plus, I'd
>>> want to compare them all anyway.  Just to be sure.
>> I aqcuired the habit of writing checksum files in all my media directories
>> such as music albums, tv series and such, whenever I create one such
>> directory. That way even years later I can still check whether the files are
>> intact. I actually experienced broken music files from time to time (mostly
>> on the MicroSD card in my tablet). So with checksum files, I can verify
>> which file is bad and which (on another machine) is still good.
> There is also dm-verity for a more involved solution.  I think for Dale 
> something like this should work:
>
> find path-to-directory/ -type f | xargs md5sum > digest.log
>
> then to compare with a backup of the same directory you could run:
>
> md5sum -c digest.log | grep FAILED
>
> Someone more knowledgeable should be able to knock out some clever python 
> script to do the same at speed.


I'll be honest here, on two points.  I'd really like to be able to do
this but I have no idea where to or how to even start.  My setup for
series type videos.  In a parent directory, where I'd like a tool to
start, is about 600 directories.  On a few occasions, there is another
directory inside that one.  That directory under the parent is the name
of the series.  Sometimes I have a sub directory that has temp files;
new files I have yet to rename, considering replacing in the main series
directory etc.  I wouldn't mind having a file with a checksum for each
video in the top directory, and even one in the sub directory.  As a
example.

TV_Series/

├── 77 Sunset Strip (1958)
│   └── torrent
├── Adam-12 (1968)
├── Airwolf (1984)


I got a part of the output of tree.  The directory 'torrent' under 77
Sunset is temporary usually but sometimes a directory is there for
videos about the making of a video, history of it or something.  What
I'd like, a program that would generate checksums for each file under
say 77 Sunset and it could skip or include the directory under it. 
Might be best if I could switch it on or off.  Obviously, I may not want
to do this for my whole system.  I'd like to be able to target
directories.  I have another large directory, lets say not a series but
sometimes has remakes, that I'd also like to do.  It is kinda set up
like the above, parent directory with a directory underneath and on
occasion one more under that. 

One thing I worry about is not just memory problems, drive failure but
also just some random error or even bit rot.  Some of these files are
rarely changed or even touched.  I'd like a way to detect problems and
there may even be a software tool that does this with some setup,
reminds me of Kbackup where you can select what to backup or leave out
on a directory or even individual file level. 

While this could likely be done with a script of some kind, my scripting
skills are minimum at best, I suspect there is software out there
somewhere that can do this.  I have no idea what or where it could be
tho.  Given my lack of scripting skills, I'd be afraid I'd do something
bad and it delete files or something.  O_O  LOL 

I been watching videos again, those I was watching during the time the
memory was bad.  I've replaced three so far.  I think I noticed this
within a few hours.  Then it took a little while for me to figure out
the problem and shutdown to run the memtest.  I doubt many files were
affected unless it does something we don't know about.  I do plan to try
to use rsync checksum and dryrun when I get back up and running.  Also,
QB is finding a lot of its files are fine as well.  It's still
rechecking them.  It's a lot of files. 

Right now, I suspect my backup copy is likely better than my main copy. 
Once I get the memory in and can really run some software, then I'll run
rsync with those compare options and see what it says.  I just got to
remember to reverse things.  Backup is the source not the destination. 
If this works, I may run that each time, help detect problems maybe. 
Maybe?? 

Oh, memory made it to the Memphis hub.  Should be here tomorrow. 

Dale

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Michael]

On Thursday 5 September 2024 19:55:56 BST Frank Steinmetzger wrote:
> Am Thu, Sep 05, 2024 at 06:30:54AM -0500 schrieb Dale:
> > > Use rsync with:
> > >  --checksum
> > > 
> > > and
> > > 
> > >  --dry-run
> 
> I suggest calculating a checksum file from your active files. Then you don’t
> have to read the files over and over for each backup iteration you compare
> it against.
> 
> > > You can also run find to identify which files were changed during the
> > > period you were running with the dodgy RAM.  Thankfully you didn't run
> > > for too long before you spotted it.
> 
> This. No need to check everything you ever stored. Just the most recent
> stuff, or at maximum, since you got the new PC.
> 
> > I have just shy of 45,000 files in 780 directories or so.  Almost 6,000
> > in another.  Some files are small, some are several GBs or so.  Thing
> > is, backups go from a single parent directory if you will.  Plus, I'd
> > want to compare them all anyway.  Just to be sure.
> 
> I aqcuired the habit of writing checksum files in all my media directories
> such as music albums, tv series and such, whenever I create one such
> directory. That way even years later I can still check whether the files are
> intact. I actually experienced broken music files from time to time (mostly
> on the MicroSD card in my tablet). So with checksum files, I can verify
> which file is bad and which (on another machine) is still good.

There is also dm-verity for a more involved solution.  I think for Dale 
something like this should work:

find path-to-directory/ -type f | xargs md5sum > digest.log

then to compare with a backup of the same directory you could run:

md5sum -c digest.log | grep FAILED

Someone more knowledgeable should be able to knock out some clever python 
script to do the same at speed.

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

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Frank Steinmetzger]

Am Thu, Sep 05, 2024 at 06:30:54AM -0500 schrieb Dale:

> > Use rsync with:
> >
> >  --checksum
> >
> > and
> >
> >  --dry-run 

I suggest calculating a checksum file from your active files. Then you don’t 
have to read the files over and over for each backup iteration you compare 
it against.

> > You can also run find to identify which files were changed during the 
> > period 
> > you were running with the dodgy RAM.  Thankfully you didn't run for too 
> > long 
> > before you spotted it.

This. No need to check everything you ever stored. Just the most recent 
stuff, or at maximum, since you got the new PC.

> I have just shy of 45,000 files in 780 directories or so.  Almost 6,000
> in another.  Some files are small, some are several GBs or so.  Thing
> is, backups go from a single parent directory if you will.  Plus, I'd
> want to compare them all anyway.  Just to be sure.

I aqcuired the habit of writing checksum files in all my media directories 
such as music albums, tv series and such, whenever I create one such 
directory. That way even years later I can still check whether the files are 
intact. I actually experienced broken music files from time to time (mostly 
on the MicroSD card in my tablet). So with checksum files, I can verify which 
file is bad and which (on another machine) is still good.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

Lettered up the mixes?


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Dale]

Michael wrote:
> On Thursday 5 September 2024 11:53:16 BST Dale wrote:
>>
>> I made my backups last weekend.  I'm sure it was working fine then. 
>> After all, it would have failed to compile packages if it was bad.  I'm
>> thinking about checking against that copy like you mentioned but I have
>> other files I've added since then.  I figure if I remove the delete
>> option, that will solve that.  It can't compare but it can leave them be. 
> Use rsync with:
>
>  --checksum
>
> and
>
>  --dry-run 
>
> Then it will compare files in situ without doing anything else.
>
> If you have a directory or only a few files it is easy and quick to run.
>
> You can also run find to identify which files were changed during the period 
> you were running with the dodgy RAM.  Thankfully you didn't run for too long 
> before you spotted it.


I have just shy of 45,000 files in 780 directories or so.  Almost 6,000
in another.  Some files are small, some are several GBs or so.  Thing
is, backups go from a single parent directory if you will.  Plus, I'd
want to compare them all anyway.  Just to be sure.

I also went back and got QB to do a manual file test.  It seems to be
doing better.  There's over 4,000 torrents. Some 32TBs of data.  I think
it's going to take a while.  o_^  As it is, I set the speed to tiny
amounts until I get this sorted.  Don't want to accidentally share a bad
file. 

Dale

:-)  :-) 

P. S.  My trees need some rain today.  It's getting very dry.  I been
watering some trees.  My Swamp Chestnut trees are massive.  Hate to lose
those things.  Likely 100 years old according to my tree guru.  In the
fall, I wear a construction helmet.  Those things hurt when they fall
and hit my head. 

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Michael]

On Thursday 5 September 2024 11:53:16 BST Dale wrote:
> Michael wrote:
> > On Thursday 5 September 2024 09:36:36 BST Dale wrote:
> >> I've ran fsck before mounting on every file system so far.  I ran it on
> >> the OS file systems while booted from the Live image.  The others I just
> >> did before mounting.  I realize this doesn't mean the files themselves
> >> are OK but at least the file system under them is OK.
> > 
> > This could put your mind mostly at rest, at least the OS structure is OK
> > and the error was not running for too long.
> 
> That does help. 
> 
> >> I'm not sure how
> >> to know if any damage was done between when the memory stick failed and
> >> when I started the repair process.  I could find the ones I copied from
> >> place to place and check them but other than watching every single
> >> video, I'm not sure how to know if one is bad or not.  So far,
> >> thumbnails work.  o_O
> > 
> > If you have a copy of these files on another machine, you can run rsync
> > with --checksum.  This will only (re)copy the file over if the checksum
> > is different.
> 
> I made my backups last weekend.  I'm sure it was working fine then. 
> After all, it would have failed to compile packages if it was bad.  I'm
> thinking about checking against that copy like you mentioned but I have
> other files I've added since then.  I figure if I remove the delete
> option, that will solve that.  It can't compare but it can leave them be. 

Use rsync with:

 --checksum

and

 --dry-run 

Then it will compare files in situ without doing anything else.

If you have a directory or only a few files it is easy and quick to run.

You can also run find to identify which files were changed during the period 
you were running with the dodgy RAM.  Thankfully you didn't run for too long 
before you spotted it.


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

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Dale]

Frank Steinmetzger wrote:
> Am Thu, Sep 05, 2024 at 10:36:19AM +0100 schrieb Michael:
>
>>> Maybe that it only catches 1-bit errors, but Dale has more broken bits?
>> Or it could be Dale's kit is DDR4?
> You may be right. We talked about AM5 at great length during the concept 
> phase and then I think I actually asked back because in one mail he 
> mentioned to have bought an AM4 CPU (5000 series). :D

I looked, it is DDR4.  G.Skill F4-3600C18D-64GTRS is the brand and part
number.  I picked it because I've had that brand before and never had
trouble and it was on the ASUS list.  I did switch down from AM5 to
AM4.  AM5 doesn't have enough PCIe slots for me. 


>
> Damn Chinese keyboald dlivel!

That is familiar.  I'm starting to get used to this keyboard.  Sort of. 
I see things like that often tho. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Dale]

Michael wrote:
> On Thursday 5 September 2024 09:36:36 BST Dale wrote:
>
>> I've ran fsck before mounting on every file system so far.  I ran it on
>> the OS file systems while booted from the Live image.  The others I just
>> did before mounting.  I realize this doesn't mean the files themselves
>> are OK but at least the file system under them is OK.
> This could put your mind mostly at rest, at least the OS structure is OK and 
> the error was not running for too long.
>

That does help. 


>> I'm not sure how
>> to know if any damage was done between when the memory stick failed and
>> when I started the repair process.  I could find the ones I copied from
>> place to place and check them but other than watching every single
>> video, I'm not sure how to know if one is bad or not.  So far,
>> thumbnails work.  o_O
> If you have a copy of these files on another machine, you can run rsync with 
> --checksum.  This will only (re)copy the file over if the checksum is 
> different.
>


I made my backups last weekend.  I'm sure it was working fine then. 
After all, it would have failed to compile packages if it was bad.  I'm
thinking about checking against that copy like you mentioned but I have
other files I've added since then.  I figure if I remove the delete
option, that will solve that.  It can't compare but it can leave them be. 

I think I'm going to wait until the new memory comes in before I do
anything tho.  Including making backups. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Frank Steinmetzger]

Am Thu, Sep 05, 2024 at 10:36:19AM +0100 schrieb Michael:

> > Maybe that it only catches 1-bit errors, but Dale has more broken bits?
> 
> Or it could be Dale's kit is DDR4?

You may be right. We talked about AM5 at great length during the concept 
phase and then I think I actually asked back because in one mail he 
mentioned to have bought an AM4 CPU (5000 series). :D

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

Damn Chinese keyboald dlivel!


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Michael]

On Thursday 5 September 2024 10:08:08 BST Frank Steinmetzger wrote:
> Am Wed, Sep 04, 2024 at 11:38:01PM +0100 schrieb Michael:
> > Some MoBos are more tolerant than others.
> > 
> > Regarding Dale's question, which has already been answered - yes, anything
> > the bad memory has touched is suspect of corruption.  Without ECC RAM a
> > dodgy module can cause a lot of damage before it is discovered.
> 
> Actually I was wondering: DDR5 has built-in ECC. But that’s not the same as
> the server-grade stuff, because it all happens inside the module with no
> communication to the CPU or the OS. So what is the point of it if it still
> causes errors like in Dale’s case?
> 
> Maybe that it only catches 1-bit errors, but Dale has more broken bits?

Or it could be Dale's kit is DDR4?

Either way, as you say DDR5 is manufactured with On-Die ECC capable of 
correcting a single-bit error, necessary because DDR5 chip density has 
increased to the point where single-bit flip errors become unavoidable.  It 
also allows manufacturers to ship chips which would otherwise fail the JEDEC 
specification.  On-Die ECC will only correct bit flips *within* the memory 
chip.

Conventional Side-Band ECC with one additional chip dedicated to ECC 
correction is capable of correcting errors while data is being moved by the 
memory controller between the memory module and CPU/GPU.  It performs much 
more heavy lifting and this is why ECC memory is slower.


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

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Frank Steinmetzger]

Am Wed, Sep 04, 2024 at 11:38:01PM +0100 schrieb Michael:

> Some MoBos are more tolerant than others.

> Regarding Dale's question, which has already been answered - yes, anything 
> the 
> bad memory has touched is suspect of corruption.  Without ECC RAM a dodgy 
> module can cause a lot of damage before it is discovered.

Actually I was wondering: DDR5 has built-in ECC. But that’s not the same as the 
server-grade stuff, because it all happens inside the module with no 
communication to the CPU or the OS. So what is the point of it if it still 
causes errors like in Dale’s case?

Maybe that it only catches 1-bit errors, but Dale has more broken bits?

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

Says the zero to the eight: “nice belt”.


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Michael]

On Thursday 5 September 2024 09:36:36 BST Dale wrote:

> I've ran fsck before mounting on every file system so far.  I ran it on
> the OS file systems while booted from the Live image.  The others I just
> did before mounting.  I realize this doesn't mean the files themselves
> are OK but at least the file system under them is OK.

This could put your mind mostly at rest, at least the OS structure is OK and 
the error was not running for too long.


> I'm not sure how
> to know if any damage was done between when the memory stick failed and
> when I started the repair process.  I could find the ones I copied from
> place to place and check them but other than watching every single
> video, I'm not sure how to know if one is bad or not.  So far,
> thumbnails work.  o_O

If you have a copy of these files on another machine, you can run rsync with 
--checksum.  This will only (re)copy the file over if the checksum is 
different.



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

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Dale]

Michael wrote:
> On Thursday 5 September 2024 01:11:13 BST Dale wrote:
>
>> When I built this rig, I first booted the Gentoo Live boot image and
>> just played around a bit.  Mostly to let the CPU grease settle in a
>> bit.  Then I ran memtest through a whole test until it said it passed. 
>> Only then did I start working on the install.  The rig has ran without
>> issue until I noticed gkrellm temps were stuck.  They wasn't updating as
>> temps change.  So, I closed gkrellm but then it wouldn't open again. 
>> Ran it in a console and saw the error about missing module or
>> something.  Then I tried to figure out that problem which lead to seg
>> fault errors.  Well, that lead to the thread and the discovery of a bad
>> memory stick.  I check gkrellm often so it was most likely less than a
>> day.  Could have been only hours.  Knowing I check gkrellm often, it was
>> likely only a matter of a couple hours or so.  The only reason it might
>> have went longer, the CPU was mostly idle.  I watch more often when the
>> CPU is busy, updates etc. 
> Ah!  It seems it died while in active service.  :-)
>
> There's no way to protect against this kind of failure in real time, short of 
> running a server spec. board with ECC RAM.  An expensive proposition for a 
> home PC.


Yea, this mobo doesn't support that.  It does seem that the files for
Qbittorrent, QB, has some serious issues.  I got it to recheck them all
and almost all of them had something QB detected that made it download
them all again.  I think it has checksums for chunks of a file as well
as a checksum for the entire file.  I figure it got a mismatch for the
whole file and went to work.  I wish I could have just let it find the
bad chunks instead of the whole file.  Some torrents are hard to get. 

I've ran fsck before mounting on every file system so far.  I ran it on
the OS file systems while booted from the Live image.  The others I just
did before mounting.  I realize this doesn't mean the files themselves
are OK but at least the file system under them is OK.  I'm not sure how
to know if any damage was done between when the memory stick failed and
when I started the repair process.  I could find the ones I copied from
place to place and check them but other than watching every single
video, I'm not sure how to know if one is bad or not.  So far,
thumbnails work.  o_O

If Amazon is going to get that memory here Friday, it better get a move
on.  It hasn't shipped yet.  Amazon is bad to ship from warehouse to
warehouse and get it close before actually shipping it with USPS, FedEx
or something.  It says Friday so it will likely be here Friday.  I
haven't had one late yet.  Had them early tho.  ;-)  I actually paid for
shipping on this one.  I really should get prime. 

Come on memory sticks.  :-D

Dale

:-)  :-) 

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Michael]

On Thursday 5 September 2024 01:11:13 BST Dale wrote:

> When I built this rig, I first booted the Gentoo Live boot image and
> just played around a bit.  Mostly to let the CPU grease settle in a
> bit.  Then I ran memtest through a whole test until it said it passed. 
> Only then did I start working on the install.  The rig has ran without
> issue until I noticed gkrellm temps were stuck.  They wasn't updating as
> temps change.  So, I closed gkrellm but then it wouldn't open again. 
> Ran it in a console and saw the error about missing module or
> something.  Then I tried to figure out that problem which lead to seg
> fault errors.  Well, that lead to the thread and the discovery of a bad
> memory stick.  I check gkrellm often so it was most likely less than a
> day.  Could have been only hours.  Knowing I check gkrellm often, it was
> likely only a matter of a couple hours or so.  The only reason it might
> have went longer, the CPU was mostly idle.  I watch more often when the
> CPU is busy, updates etc. 

Ah!  It seems it died while in active service.  :-)

There's no way to protect against this kind of failure in real time, short of 
running a server spec. board with ECC RAM.  An expensive proposition for a 
home PC.


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

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Dale]

Michael wrote:
> On Wednesday 4 September 2024 23:07:17 BST Grant Edwards wrote:
>> On 2024-09-04, Dale  wrote:
>>> At one point, I looked for a set of four sticks of the memory.  I
>>> couldn't find any.  They only come in sets of two.  I read somewhere
>>> that the mobo expects each pair to be matched.
>> Yep, that's definitely how it was supposed to work. I fully expected
>> my two (identically spec'ed) sets of two work. All the documentation I
>> could find said it should. It just didn't. :/
>>
>> --
>> Grant
> Often you have to dial down latency and/or increase voltage when you add more 
> RAM modules.  It is a disappointment when faster memory has to be slowed down 
> because those extra two sticks you bought on ebay at a good price, are of a 
> slightly lower spec.
>
> Some MoBos are more tolerant than others.  I have had systems which failed to 
> work when the additional RAM modules were not part of a matching kit.  I've 
> had others which would work no matter what you threw at them.  High 
> performance MoBos which have highly strung specs, tend to require lowering 
> frequency/increasing latency when you add more RAM.
>
> Regarding Dale's question, which has already been answered - yes, anything 
> the 
> bad memory has touched is suspect of corruption.  Without ECC RAM a dodgy 
> module can cause a lot of damage before it is discovered.  This is why I 
> *always* run memtest86+ overnight whenever I get a new system, or add new 
> RAM.  
> I've only had one fail over the years, but I'd better be safe than sorry.  ;-)


When I built this rig, I first booted the Gentoo Live boot image and
just played around a bit.  Mostly to let the CPU grease settle in a
bit.  Then I ran memtest through a whole test until it said it passed. 
Only then did I start working on the install.  The rig has ran without
issue until I noticed gkrellm temps were stuck.  They wasn't updating as
temps change.  So, I closed gkrellm but then it wouldn't open again. 
Ran it in a console and saw the error about missing module or
something.  Then I tried to figure out that problem which lead to seg
fault errors.  Well, that lead to the thread and the discovery of a bad
memory stick.  I check gkrellm often so it was most likely less than a
day.  Could have been only hours.  Knowing I check gkrellm often, it was
likely only a matter of a couple hours or so.  The only reason it might
have went longer, the CPU was mostly idle.  I watch more often when the
CPU is busy, updates etc. 

I just hope I can put in all four sticks and it work once the bad set is
replaced.  I miss having 64GBs of memory already. 

Oh, QB is redoing a lot of files.  It seems it picked up on some . . .
issues.  :/

Dale

:-)  :-) 

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Michael]

On Wednesday 4 September 2024 23:07:17 BST Grant Edwards wrote:
> On 2024-09-04, Dale  wrote:
> > At one point, I looked for a set of four sticks of the memory.  I
> > couldn't find any.  They only come in sets of two.  I read somewhere
> > that the mobo expects each pair to be matched.
> 
> Yep, that's definitely how it was supposed to work. I fully expected
> my two (identically spec'ed) sets of two work. All the documentation I
> could find said it should. It just didn't. :/
> 
> --
> Grant

Often you have to dial down latency and/or increase voltage when you add more 
RAM modules.  It is a disappointment when faster memory has to be slowed down 
because those extra two sticks you bought on ebay at a good price, are of a 
slightly lower spec.

Some MoBos are more tolerant than others.  I have had systems which failed to 
work when the additional RAM modules were not part of a matching kit.  I've 
had others which would work no matter what you threw at them.  High 
performance MoBos which have highly strung specs, tend to require lowering 
frequency/increasing latency when you add more RAM.

Regarding Dale's question, which has already been answered - yes, anything the 
bad memory has touched is suspect of corruption.  Without ECC RAM a dodgy 
module can cause a lot of damage before it is discovered.  This is why I 
*always* run memtest86+ overnight whenever I get a new system, or add new RAM.  
I've only had one fail over the years, but I'd better be safe than sorry.  ;-)

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

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Dale]

Grant Edwards wrote:
> On 2024-09-04, Dale  wrote:
>
>> At one point, I looked for a set of four sticks of the memory.  I
>> couldn't find any.  They only come in sets of two.  I read somewhere
>> that the mobo expects each pair to be matched.
> Yep, that's definitely how it was supposed to work. I fully expected
> my two (identically spec'ed) sets of two work. All the documentation I
> could find said it should. It just didn't. :/
>
> --
> Grant
>

Well, when I get them all in, I'll post back how it went, unless I P. S.
it somewhere.  It could be a while.  They claim they will be here
Friday.  Who knows.  Then comes the testing part.  Of course, testing
the set I had didn't work out either.  o_O

QB is fixing quite a few files tho.  H.  It could take years for me
to watch all those videos.  O_O

Dale

:-)  :-) 

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Dale]

Grant Edwards wrote:
> On 2024-09-04, Frank Steinmetzger  wrote:
>> Am Wed, Sep 04, 2024 at 07:09:43PM - schrieb Grant Edwards:
>>> […]
>>> I plugged them in alongside the recently purchased pair. Wouldn't
>>> work. Either pair of SIMMs worked fine by themselves, but the only way
>>> I could get both pairs to work together was to drop the clock speed
>>> down to about a third the speed they were supposed to support.
>> Indeed that was my first thought when Dale mentioned getting another
>> pair. I don’t know if it’s true for all Ryzen chips, but if you use
>> four sticks, they may not work at the maximum speed advertised by
>> AMD (not counting in overlcocking). If you kept the settings to Auto
>> you shouldn’t get problems, but RAM may work slower then.
> Yea, I thought auto should work, but it didn't. I had to manually
> lower the RAM clock speed to get all four to work at the same
> time. The BIOS screens were a bit mind-boggling (very high on
> graphics, dazzle, and flash -- very low on usability). So it's
> possible I didn't really have auto mode correctly enabled.
>
>> OTOH, since you don’t do hard-core gaming or scientific
>> number-crunching, it is unlikely you will notice a difference in
>> your every-day computing.
> In my case I compared an "emerge" that took several minutes, and it
> took significantly longer with the lower RAM clock speed. I decided I
> was better off with fewer GB of faster RAM.
>
>

At one point, I looked for a set of four sticks of the memory.  I
couldn't find any.  They only come in sets of two.  I read somewhere
that the mobo expects each pair to be matched.  Thing is, things
change.  My mobo may work different or something or they figured out
some better coding.  The downside, my mobo is a somewhat older tech. 

Given the number of components on each stick, it's pretty amazing they
work at all.  I recall our conversation about the number of transistors
on a CPU.  I suspect memory is right up there with it.  32GBs on a stick
is a lot.  I think they have larger sticks too.  That means even more. 
Also, mine puts on a fancy light show.  It has LEDs that change colors. 
Annoying at times.  Needs a off switch.  LOL

My emerge -e world is still chugging along.  Not a single failure yet. 
I started Qbittorrent and it complained about files.  I did run fsck on
the file system tho and it did fix a few things, like it always does. 
It always finds something to improve on.  I told QB to force a recheck,
within minutes, it was off to the races again.  It appears to be fixing
any bad files.  Sort of neat that it can do that. 

Dale

:-)  :-) 

P. S.  With my TV not connected, my monitor situation went weird.  I
guess when I get the new rig back to normal, it will work like it did
before. 

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Frank Steinmetzger]

Am Wed, Sep 04, 2024 at 07:09:43PM - schrieb Grant Edwards:

> On 2024-09-04, Dale  wrote:
> 
> > I ordered another set of memory sticks. I figure I will have to send
> > them both back which means no memory at all. I wasn't planning to go to
> > 128GBs yet but guess I am now. [...]
> 
> Good luck.
> 
> […]
> I plugged them in alongside the recently purchased pair. Wouldn't
> work. Either pair of SIMMs worked fine by themselves, but the only way
> I could get both pairs to work together was to drop the clock speed
> down to about a third the speed they were supposed to support.

Indeed that was my first thought when Dale mentioned getting another pair. I 
don’t know if it’s true for all Ryzen chips, but if you use four sticks, 
they may not work at the maximum speed advertised by AMD (not counting in 
overlcocking). If you kept the settings to Auto you shouldn’t get problems, 
but RAM may work slower then. OTOH, since you don’t do hard-core gaming or 
scientific number-crunching, it is unlikely you will notice a difference in 
your every-day computing.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

How can I know what I’m thinking before I hear what I’m saying?


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Dale]

Peter Humphrey wrote:
> On Wednesday 4 September 2024 15:23:13 BST Grant Edwards wrote:
>> On 2024-09-04, Dale  wrote:
>>> I forgot to ask, is there anything else that bad memory could affect? 
> How long have you got?  ;-)
>


Well, the new files I downloaded, I can let Qbittorrent check what it
downloaded.  If it passes the tests, then I can copy those over and
replace what I copied over in the last week or so.  I think this stick
of memory only went bad in the past couple days.  Shouldn't be many
files.  I'd hope reading wouldn't corrupt a file. 

Emerge -e world is still going strong.  Still wondering about problem in
other thread tho. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Peter Humphrey]

On Wednesday 4 September 2024 15:23:13 BST Grant Edwards wrote:
> On 2024-09-04, Dale  wrote:
> > I forgot to ask, is there anything else that bad memory could affect? 

How long have you got?  ;-)

-- 
Regards,
Peter.

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Peter Humphrey]

On Wednesday 4 September 2024 12:21:19 BST Dale wrote:

> I wasn't planning to go to 128GBs yet but guess I am now.

I considered doubling up to 128GB a few months ago, but the technical help 
people at Armari (the workstation builder) told me that I'd need to jump 
through a few hoops. Not only would the chips need to have been selected for 
that purpose, but I'd have to do a fair amount of BIOS tuning while running 
performance tests.

I decided not to push my luck.

-- 
Regards,
Peter.

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Dale]

Frank Steinmetzger wrote:
> Am Wed, Sep 04, 2024 at 05:48:29AM -0500 schrieb Dale:
>
>> I wonder how much fun getting this memory replaced is going to be.  o_O 
> I once had a bad stick of Crucial Ballistix DDR3. I think it also started 
> with GCC segfaults. So I took a picture of the failing memtest, e-mailed 
> that to crucial and they sent me instructions what to do.
>
> I keep the packaging of all my tech stuff, so I put the sticks into their 
> blister (I bought it as a kit, so I had to send in both sticks), put a paper 
> note in for which one was faulty and sent them off to Crucial in Ireland. 
> After two weeks or so I got a new kit in the mail. Thankfully by that time I 
> had two kits for the maximum of 4 × 8 GiB, so I was able to continue using 
> my PC.
>

I ordered another set of memory sticks.  I figure I will have to send
them both back which means no memory at all.  I wasn't planning to go to
128GBs yet but guess I am now.  Once new ones come in, I'll start
working on getting them swapped.  I don't recall ever having a memory
stick go bad before.  I've had to reseat one before but not just plain
go bad. 

I noticed that that qtweb package now wants 32GBs of space to build
now.  Dang, I feel for someone using a Raspberry Pi.  That thing is
getting really big.  I didn't set up swap so I had to create a swapfile. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Frank Steinmetzger]

Am Wed, Sep 04, 2024 at 05:48:29AM -0500 schrieb Dale:

> I wonder how much fun getting this memory replaced is going to be.  o_O 

I once had a bad stick of Crucial Ballistix DDR3. I think it also started 
with GCC segfaults. So I took a picture of the failing memtest, e-mailed 
that to crucial and they sent me instructions what to do.

I keep the packaging of all my tech stuff, so I put the sticks into their 
blister (I bought it as a kit, so I had to send in both sticks), put a paper 
note in for which one was faulty and sent them off to Crucial in Ireland. 
After two weeks or so I got a new kit in the mail. Thankfully by that time I 
had two kits for the maximum of 4 × 8 GiB, so I was able to continue using 
my PC.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

An empty head is easier to nod with.


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Raffaele Belardi]

On 4 September 2024 02:12:51 CEST, Grant Edwards  
wrote:
>On 2024-09-03, Dale  wrote:
>
>> I was trying to re-emerge some packages.  The ones I was working on
>> failed with "internal compiler error: Segmentation fault" or similar
>> being the common reason for failing.
>
>In my experience, that usually means failing RAM.  I'd try running
>memtest86 for a day or two.
>
>--
>Grant
>

Also out of memory might cause a segmentation fault. Dale, do you have a swap 
partition or file? At least three of the packages you mention are quite memory 
hungry, depending on your -j options in make.conf. You should see an OOM error 
in the syslog if this is the case, is there any hint in it?

Raf

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[corbin bird]

On 9/3/24 19:39, Dale wrote:

Grant Edwards wrote:

On 2024-09-03, Dale  wrote:


I was trying to re-emerge some packages.  The ones I was working on
failed with "internal compiler error: Segmentation fault" or similar
being the common reason for failing.

In my experience, that usually means failing RAM.  I'd try running
memtest86 for a day or two.

--
Grant

I've seen that before too.  I'm hoping not.  I may shutdown my rig,
remove and reinstall the memory and then test it for a bit.  May be a
bad connection.  It has worked well for the past couple months tho.
Still, it is possible to either be a bad connection or just going bad.

Dang those memory sticks ain't cheap.  o_~

Thanks.  See if anyone else has any other ideas.

Dale

:-)  :-)

Please refresh my memory, what brand of CPU ( Intel or AMD ) is in your 
new rig?




If AMD, binutils can build -broken- without failing the compile process.

gcc starts segfaulting constantly.

workaround :

setup a package.env for gcc and binutils.

    gcc.conf contents :

CFLAGS="-march=generic -O2 -pipe"

CXXFLAGS="-march=generic -O2 -pipe"


use the old version of gcc to rebuild both binutils and gcc ( the new 
version ).


leave this fix in place, and prevent this error from reoccurring.


Hope this helps,

Corbin

Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".

[Dale]

Grant Edwards wrote:
> On 2024-09-03, Dale  wrote:
>
>> I was trying to re-emerge some packages.  The ones I was working on
>> failed with "internal compiler error: Segmentation fault" or similar
>> being the common reason for failing.
> In my experience, that usually means failing RAM.  I'd try running
> memtest86 for a day or two.
>
> --
> Grant

I've seen that before too.  I'm hoping not.  I may shutdown my rig,
remove and reinstall the memory and then test it for a bit.  May be a
bad connection.  It has worked well for the past couple months tho. 
Still, it is possible to either be a bad connection or just going bad. 

Dang those memory sticks ain't cheap.  o_~

Thanks.  See if anyone else has any other ideas. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: emerge keeps installing then uninstalling qtbase, qttools, ...

[Matthew Brooks]

Actually, looking more closely at the emerge man pages, it says that 
--with-bdeps is already automatically supplied for depclean, so that's probably 
not the issue after all. My apologies.

It might be worth seeing what a full update of world, with the --emptytree flag 
says (though without actually doing the rebuild). Sometimes including that will 
notice inconsistencies that a regular emerge doesn't spot.



On Tue,  3 Sep 2024 17:28:31 +
Matthew Brooks  wrote:

> While I'm not familiar enough with those packages to know for certain, it 
> sounds like they're probably *build* dependencies for something, but not 
> actual *runtime* dependencies, and so depclean prunes them, and then whenever 
> the package that needs them gets built again they get pulled in again.
> 
> I pretty much always use the "--with-bdeps" flag so that all the build 
> dependencies will stay installed and up-to-date for whenever they're next 
> needed.
> 
> I'm not *certain* if that's the problem here, but that general behavior 
> sounds like build-deps getting pruned.
> 
> 
> 
> On Tue, 3 Sep 2024 02:47:55 - (UTC)
> Grant Edwards  wrote:
> 
> > On 2024-09-03, Grant Edwards  wrote:  
> > > For the past 4 days or so, every time I do a sync and then
> > > 'emerge -auvND world', portage installs the following:
> > >
> > >   qttools
> > >   qtbase
> > >   qttranslations
> > >   xcb-util-cursor
> > >
> > > Afterwards, when I do 'emerge --depclean', it uninstalls them.
> > >
> > > Any ideas why?  It's getting a little annoying.
> > 
> > # emerge -auvNDt world
> > 
> >  * IMPORTANT: 30 news items need reading for repository 'gentoo'.
> >  * Use eselect news read to view new items.
> > 
> > These are the packages that would be merged, in reverse order:
> > 
> > Calculating dependencies... done!
> > Dependency resolution took 26.51 s (backtrack: 0/20).
> > 
> > [nomerge   ] dev-qt/qttools-6.7.2:6/6.7.2::gentoo  USE="assistant 
> > linguist qdbus widgets (zstd) -clang -designer -distancefieldgenerator 
> > -gles2-only -opengl -pixeltool -qdoc -qml -qtattributionsscanner -qtdiag 
> > -qtplugininfo -vulkan" LLVM_SLOT="18 -15 -16 -17" 
> > [nomerge   ]  dev-qt/qtbase-6.7.2-r4:6/6.7.2::gentoo  USE="X concurrent 
> > dbus gtk gui libinput network nls sql sqlite ssl udev widgets xml (zstd) 
> > -accessibility -brotli -cups -eglfs -evdev -gles2-only -gssapi -icu 
> > -journald -libproxy -mysql -oci8 -odbc -opengl -postgres -renderdoc -sctp 
> > -syslog -test -tslib -vulkan -wayland" 
> > [ebuild  N ]   dev-qt/qttranslations-6.7.2:6/6.7.2::gentoo  0 KiB
> > [ebuild  N ]dev-qt/qttools-6.7.2:6/6.7.2::gentoo  USE="assistant 
> > linguist qdbus widgets (zstd) -clang -designer -distancefieldgenerator 
> > -gles2-only -opengl -pixeltool -qdoc -qml -qtattributionsscanner -qtdiag 
> > -qtplugininfo -vulkan" LLVM_SLOT="18 -15 -16 -17" 0 KiB
> > [ebuild  N ] dev-qt/qtbase-6.7.2-r4:6/6.7.2::gentoo  USE="X 
> > concurrent dbus gtk gui libinput network nls sql sqlite ssl udev widgets 
> > xml (zstd) -accessibility -brotli -cups -eglfs -evdev -gles2-only -gssapi 
> > -icu -journald -libproxy -mysql -oci8 -odbc -opengl -postgres -renderdoc 
> > -sctp -syslog -test -tslib -vulkan -wayland" 0 KiB
> > [ebuild  N ]  x11-libs/xcb-util-cursor-0.1.5::gentoo  ABI_X86="(64) 
> > -32 (-x32)" 0 KiB
> > 
> > Total: 4 packages (4 new), Size of downloads: 0 KiB
> > 
> > 
> >   
> 
> 

Re: [gentoo-user] Re: emerge keeps installing then uninstalling qtbase, qttools, ...

[Matthew Brooks]

While I'm not familiar enough with those packages to know for certain, it 
sounds like they're probably *build* dependencies for something, but not actual 
*runtime* dependencies, and so depclean prunes them, and then whenever the 
package that needs them gets built again they get pulled in again.

I pretty much always use the "--with-bdeps" flag so that all the build 
dependencies will stay installed and up-to-date for whenever they're next 
needed.

I'm not *certain* if that's the problem here, but that general behavior sounds 
like build-deps getting pruned.



On Tue, 3 Sep 2024 02:47:55 - (UTC)
Grant Edwards  wrote:

> On 2024-09-03, Grant Edwards  wrote:
> > For the past 4 days or so, every time I do a sync and then
> > 'emerge -auvND world', portage installs the following:
> >
> >   qttools
> >   qtbase
> >   qttranslations
> >   xcb-util-cursor
> >
> > Afterwards, when I do 'emerge --depclean', it uninstalls them.
> >
> > Any ideas why?  It's getting a little annoying.  
> 
> # emerge -auvNDt world
> 
>  * IMPORTANT: 30 news items need reading for repository 'gentoo'.
>  * Use eselect news read to view new items.
> 
> These are the packages that would be merged, in reverse order:
> 
> Calculating dependencies... done!
> Dependency resolution took 26.51 s (backtrack: 0/20).
> 
> [nomerge   ] dev-qt/qttools-6.7.2:6/6.7.2::gentoo  USE="assistant 
> linguist qdbus widgets (zstd) -clang -designer -distancefieldgenerator 
> -gles2-only -opengl -pixeltool -qdoc -qml -qtattributionsscanner -qtdiag 
> -qtplugininfo -vulkan" LLVM_SLOT="18 -15 -16 -17" 
> [nomerge   ]  dev-qt/qtbase-6.7.2-r4:6/6.7.2::gentoo  USE="X concurrent 
> dbus gtk gui libinput network nls sql sqlite ssl udev widgets xml (zstd) 
> -accessibility -brotli -cups -eglfs -evdev -gles2-only -gssapi -icu -journald 
> -libproxy -mysql -oci8 -odbc -opengl -postgres -renderdoc -sctp -syslog -test 
> -tslib -vulkan -wayland" 
> [ebuild  N ]   dev-qt/qttranslations-6.7.2:6/6.7.2::gentoo  0 KiB
> [ebuild  N ]dev-qt/qttools-6.7.2:6/6.7.2::gentoo  USE="assistant 
> linguist qdbus widgets (zstd) -clang -designer -distancefieldgenerator 
> -gles2-only -opengl -pixeltool -qdoc -qml -qtattributionsscanner -qtdiag 
> -qtplugininfo -vulkan" LLVM_SLOT="18 -15 -16 -17" 0 KiB
> [ebuild  N ] dev-qt/qtbase-6.7.2-r4:6/6.7.2::gentoo  USE="X 
> concurrent dbus gtk gui libinput network nls sql sqlite ssl udev widgets xml 
> (zstd) -accessibility -brotli -cups -eglfs -evdev -gles2-only -gssapi -icu 
> -journald -libproxy -mysql -oci8 -odbc -opengl -postgres -renderdoc -sctp 
> -syslog -test -tslib -vulkan -wayland" 0 KiB
> [ebuild  N ]  x11-libs/xcb-util-cursor-0.1.5::gentoo  ABI_X86="(64) 
> -32 (-x32)" 0 KiB
> 
> Total: 4 packages (4 new), Size of downloads: 0 KiB
> 
> 
> 

Re: [gentoo-user] Re: Do I need firmware for an integrated graphics unit?

[Alan Mackenzie]

Hello, Grant.

On Wed, Aug 21, 2024 at 13:02:43 -, Grant Edwards wrote:
> On 2024-08-21, Alan Mackenzie  wrote:
> > On Wed, Aug 21, 2024 at 00:30:25 -, Grant Edwards wrote:
> >> On 2024-08-20, Alan Mackenzie  wrote:

> >> > I've just treated myself to a new machine based on a Ryzen 9 7900
> >> > processor.  I chose the second newest generation so as not to get caught
> >> > out with not quite debugged systems like I did the last time round.

> >> > Anyhow, I'm up to the stage of configuring the kernel, and I'm stuck at
> >> > the bit where I need to specify the firmware to be incorporated into the
> >> > kernel for the integrated graphics processor.

> >> I'm running a Ryzen 5 3400G with Radeon Vega graphics:

> > That's a separate graphics card, isn't it?  I'm trying to use the
> > integrated graphics processor on my Ryzen 7900.

> No, it's integrated into the Ryzen 5 3400G.

Sorry, I didn't recognise the chip number.  Is it a laptop chip rather
than a desktop one?

Anyhow, in the last couple of days, I've managed to get my new system to
boot, and I'm currently busy trying to bring X and XFCE4 up.  So I'm
getting there, slowly.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Re: Do I need firmware for an integrated graphics unit?

[Michael]

On Wednesday, 21 August 2024 12:39:58 BST Alan Mackenzie wrote:
> Hello, Grant.
> 
> On Wed, Aug 21, 2024 at 00:30:25 -, Grant Edwards wrote:
> > On 2024-08-20, Alan Mackenzie  wrote:
> > > I've just treated myself to a new machine based on a Ryzen 9 7900
> > > processor.  I chose the second newest generation so as not to get caught
> > > out with not quite debugged systems like I did the last time round.
> > > 
> > > Anyhow, I'm up to the stage of configuring the kernel, and I'm stuck at
> > > the bit where I need to specify the firmware to be incorporated into the
> > > kernel for the integrated graphics processor.
> > 
> > I'm running a Ryzen 5 3400G with Radeon Vega graphics:
> That's a separate graphics card, isn't it?  I'm trying to use the
> integrated graphics processor on my Ryzen 7900.
> 
> > $ lspci | grep -i vga
> > 2a:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
> > Picasso/Raven 2 [Radeon Vega Series / Radeon Vega Mobile Series] (rev c8)
> When I do lspci | grep -i vga, I just get:
> 
> VGA compatible controller, Advanced Micro Devices, Inc [AMD/ATI] Raphael
> (rev c4),
> 
> (well, something very similar, I'm copying it by hand).  The "Raphael",
> I believe, is the codename for the entire 7900 processor, not just the
> graphics controller.

The codename was Raphael AM5, this uses a RDNA2 Raphael graphics as far as I 
can tell.


> > $ dmesg | grep -i firmware
> > [0.091814] Spectre V2 : Enabling Speculation Barrier for firmware
> > calls
> > [0.244487] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
> > [0.261256] acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain 
> > [bus 00-3f] only partially covers this bridge [3.021472] Loading
> > firmware: amdgpu/picasso_gpu_info.bin
> > [3.045180] Loading firmware: amdgpu/picasso_sdma.bin
> > [3.046559] Loading firmware: amdgpu/picasso_asd.bin
> > [3.047121] Loading firmware: amdgpu/picasso_ta.bin
> > [3.047408] Loading firmware: amdgpu/raven_dmcu.bin
> > [3.048027] Loading firmware: amdgpu/picasso_pfp.bin
> > [3.048163] Loading firmware: amdgpu/picasso_me.bin
> > [3.048380] Loading firmware: amdgpu/picasso_ce.bin
> > [3.048491] Loading firmware: amdgpu/picasso_rlc_am4.bin
> > [3.048624] Loading firmware: amdgpu/picasso_mec.bin
> > [3.048891] Loading firmware: amdgpu/picasso_mec2.bin
> > [3.049687] Loading firmware: amdgpu/picasso_vcn.bin
> > [3.050007] [drm] Found VCN firmware Version ENC: 1.15 DEC: 3 VEP: 0
> > Revision: 0 [3.050015] amdgpu :2a:00.0: amdgpu: Will use PSP to
> > load VCN firmware [5.407436] Loading firmware: rtl_nic/rtl8168h-2.fw
> 
> As I reported in another post, dmesg | grep firmware just gives me three
> files, none of them to do with graphics.

Perhaps you can try a different LiveUSB, e.g. Ubuntu to see if it provides 
more info.



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

Re: [gentoo-user] Re: Do I need firmware for an integrated graphics unit?

[Alan Mackenzie]

Hello, Grant.

On Wed, Aug 21, 2024 at 00:30:25 -, Grant Edwards wrote:
> On 2024-08-20, Alan Mackenzie  wrote:

> > I've just treated myself to a new machine based on a Ryzen 9 7900
> > processor.  I chose the second newest generation so as not to get caught
> > out with not quite debugged systems like I did the last time round.

> > Anyhow, I'm up to the stage of configuring the kernel, and I'm stuck at
> > the bit where I need to specify the firmware to be incorporated into the
> > kernel for the integrated graphics processor.

> I'm running a Ryzen 5 3400G with Radeon Vega graphics:

That's a separate graphics card, isn't it?  I'm trying to use the
integrated graphics processor on my Ryzen 7900.

> $ lspci | grep -i vga
> 2a:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
> Picasso/Raven 2 [Radeon Vega Series / Radeon Vega Mobile Series] (rev c8)

When I do lspci | grep -i vga, I just get:

VGA compatible controller, Advanced Micro Devices, Inc [AMD/ATI] Raphael 
(rev c4),

(well, something very similar, I'm copying it by hand).  The "Raphael",
I believe, is the codename for the entire 7900 processor, not just the
graphics controller.


> $ dmesg | grep -i firmware
> [0.091814] Spectre V2 : Enabling Speculation Barrier for firmware calls
> [0.244487] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
> [0.261256] acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain  
> [bus 00-3f] only partially covers this bridge
> [3.021472] Loading firmware: amdgpu/picasso_gpu_info.bin
> [3.045180] Loading firmware: amdgpu/picasso_sdma.bin
> [3.046559] Loading firmware: amdgpu/picasso_asd.bin
> [3.047121] Loading firmware: amdgpu/picasso_ta.bin
> [3.047408] Loading firmware: amdgpu/raven_dmcu.bin
> [3.048027] Loading firmware: amdgpu/picasso_pfp.bin
> [3.048163] Loading firmware: amdgpu/picasso_me.bin
> [3.048380] Loading firmware: amdgpu/picasso_ce.bin
> [3.048491] Loading firmware: amdgpu/picasso_rlc_am4.bin
> [3.048624] Loading firmware: amdgpu/picasso_mec.bin
> [3.048891] Loading firmware: amdgpu/picasso_mec2.bin
> [3.049687] Loading firmware: amdgpu/picasso_vcn.bin
> [3.050007] [drm] Found VCN firmware Version ENC: 1.15 DEC: 3 VEP: 0 
> Revision: 0
> [3.050015] amdgpu :2a:00.0: amdgpu: Will use PSP to load VCN firmware
> [5.407436] Loading firmware: rtl_nic/rtl8168h-2.fw

As I reported in another post, dmesg | grep firmware just gives me three
files, none of them to do with graphics.

> $ zcat /proc/config.gz  | grep -i firmware
> CONFIG_PREVENT_FIRMWARE_BUILD=y
> # Firmware loader
> CONFIG_EXTRA_FIRMWARE=""
> # end of Firmware loader
> # Firmware Drivers
> CONFIG_FIRMWARE_MEMMAP=y
> # CONFIG_GOOGLE_FIRMWARE is not set
> # Tegra firmware driver
> # end of Tegra firmware driver
> # end of Firmware Drivers
> # CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
> # CONFIG_FIRMWARE_EDID is not set
> # CONFIG_TEST_FIRMWARE is not set
> CONFIG_GENTOO_PRINT_FIRMWARE_INFO=y

Yes, I get something like that on the installation system.

[  ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Re: 17 new packages because pip wants to write poetry?

[Eli Schwartz]

On 7/29/24 4:09 PM, Grant Edwards wrote:
> Right, but that's only useful after you track down the trigger for the
> new packages. What would be nice is avoiding that "tracking down"
> effort.  [I know, I should just relax, hit 'Y', and trust that emerge
> and the devs know what they're doing.]


That's basically just emerge -t though?


>> As for why it needs to format markdown -- build dependencies of
>> python software often do, since they want to render the darned stuff
>> into the https://pypi.org display page for that software
> 
> Oh. Is that display page (in html?) written into a log somewhere or
> shown during the build?


It's stored inside an installed file called

/usr/lib/python3.XX/site-packages/${PN}-${PV}.dist-info/METADATA

The file format is described at
https://packaging.python.org/en/latest/specifications/core-metadata/#description

Of course, the specific metadata field in question is not actually
useful for installed packages, only for web repository uploads, but
there you have it...

There is some useful metadata in that file, for example pip needs it to
be able to list which names and versions are installed, and also to
check whether each python module has its dependencies (or Extras
dependencies) installed. But the stuff that uses rst and markdown is
totally unnecessary for this, even though python build systems have to
add it.


>> aside: there are pip manpages, funny you should mention that.
> 
> When installed on Gentoo using dev-python/pip?
> 
>> I could totally add another bdepend on sphinx for this! But I would have
>> to package some things first. :(
> 
> No thanks, sphinx would pull in 10 more packages. :)
> 
> If I need pip documentation, I can google for it or look at the
> rst.bz2 files install in /usr/share/doc...
> 
> Thanks for tolerating my whinging.


Gentoo doesn't install the manpages, no.

We should. And per policy, manpages cannot be disabled by a USE flag:
https://projects.gentoo.org/qa/policy-guide/installed-files.html#pg0305

But what we can do is build the manpages ourselves and add an extra
SRC_URI to download that. And in this case it's a royal pain to package,
including the fact that it requires sphinxcontrib-towncrier which has
never released any version that isn't an alpha... amazing...


-- 
Eli Schwartz



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: 17 new packages because pip wants to write poetry?

[Eli Schwartz]

On 7/29/24 2:05 PM, Grant Edwards wrote:
> On 2024-07-29, Eli Schwartz  wrote:
>>
>>> It turns out dev-python/poetry has nothing to do with poetry, so my AI
>>> paranoia was unjustified (this time), but one wonders what devs are
>>> thinking when the decide they add dozens of new dependencies like
>>> that. Why does pip suddenly need to format (or produce?) both markdown
>>> and RTF when it's been able to get along fine without them for so many
>>> years?
>>
>> For many years, pip has contained bundled libraries. These libraries
>> recently got unbundled, and now you're installing a system copy.
> 
> Yep, I figured that was probably the answer.  I (for one) would
> appreciate some sort of notice when such an unbundling happens so that
> I don't waste time trying to track down why emerge suddenly wants to
> install a bunch of new packages.  I can't really come up with a good
> mechanism for that other than news items.


Well, it is there in the `git log` of the package. And at
https://packages.gentoo.org/packages/dev-python/pip/changelog


 Commits on 2024-06-23

dev-python/pip: Unbundle dependencies


>> pip has always "needed to format (or produce?) both markdown and RTF",
> 
> OK, now I'm genuinely curious: what does pip need to do with markdown
> and RTF? My first guess was that its man pages aren't written in nroff
> any more and somehow markdown was being used. [I already had at least
> one markdown implementation installed, but pip apparently demands a
> different one.] But there is no man page for pip. There are a bunch of
> documents in /usr/share/doc/pip-, but they're all reStructured Text.
> 
> Oh well, I guess I should be thankful it didn't force LaTeX and pandoc
> installs.


Python software loves to depend on python software and hates to depend
on anything that isn't written in python, so I think you're pretty safe
there. :)

As for why it needs to format markdown -- build dependencies of python
software often do, since they want to render the darned stuff into the
https://pypi.org display page for that software and the one and only way
to do so is to render it into the metadata files which get installed at
runtime -- and which are also directly displayed on https://pypi.org

I don't understand it myself, either.

In this case it's actually a bit worse because pip internally uses, and
usually bundles a code copy, of https://pypi.org/project/rich/

"rich" can do a lot of things, including take markdown and print it with
fancy formatting and colors to your terminal emulator. pip isn't using
most of the features of rich, but it is *using* rich at all, and
therefore markdown ends up as a recursive dependency.


...

aside: there are pip manpages, funny you should mention that.

I could totally add another bdepend on sphinx for this! But I would have
to package some things first. :(


-- 
Eli Schwartz



OpenPGP_signature.asc
Description: OpenPGP digital signature

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

:-)  :-) 

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] Re: Can't get the GUI to stay up for more than a minute or so before crashing

[Dale]

Michael wrote:
> On Monday, 24 June 2024 22:52:31 BST Dale wrote:
>> Grant Edwards wrote:
>>> On 2024-06-24, Dale  wrote:
 Michael wrote:
> On Monday, 24 June 2024 20:47:15 BST Dale wrote:
>> Have you seen this before?
> No, because I've never used dracut.
 I just had a thought.  I have /usr on the root partition now.  Do I even
 need a init thingy? 
>>> Same question as always: does your kernel have enough built-in
>>> drivers/modules to mount the root fileystem on /?
>>>
>>> If yes, then you don't need an initrd.
>>>
>>> If no, then you do need an initrd.
>>>
>>> I don't think where /usr is matters, does it?
>>>
>>> --
>>> Grant
>> My understanding, the whole init thing started with a bluetooth keyboard
>> or mouse driver that was installed in /usr instead of /bin or /sbin,
>> whichever one fits.  I've always had /usr on its own partition until
>> this time.  Mostly because it is easier to put /boot and root on regular
>> partitions and then put /usr, /var and of course /home on LVM.  That way
>> as software like LOo, KDE and others grew, I could use LVM to grow them
>> easily enough. 
> You need access to the LVM tools to be able to access your /usr.  I expect 
> they will be under /usr - hence you need an early userspace with the required 
> tools to be able mount LVM and anything in it.
>
> Alternatively, use btrfs and do away with LVM.
>
>
>> Given the merge of bin and sbin to /usr, I have no idea if a system will
>> boot without a init thingy or not.
> It won't boot without a initrd if /usr is on a different partition, because 
> the OS needs commands available on /usr to boot with.  Chicken <-> egg 
> problem.
>
>
>> This is the first time I've
>> ran/installed a system with those merged.  I'd think it would work but I
>> don't want to have a unbootable system to find out it doesn't either. 
> With a merged /usr you will now also have /bin, /sbin, /lib, /lib64, all of 
> them in /usr.
>

On this new install, basically, I have /, /boot, /efi, /home and /var on
separate partitions.  I put /usr on / like most people do nowadays.  I
guess I can boot without a init thingy but not sure.  I'd rather have
two entries, one with and one without a init thingy to test with.  May
do that later on. 

Dale

:-)  :-) 

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

[Michael]

On Monday, 24 June 2024 22:52:31 BST Dale wrote:
> Grant Edwards wrote:
> > On 2024-06-24, Dale  wrote:
> >> Michael wrote:
> >>> On Monday, 24 June 2024 20:47:15 BST Dale wrote:
>  Have you seen this before?
> >>> 
> >>> No, because I've never used dracut.
> >> 
> >> I just had a thought.  I have /usr on the root partition now.  Do I even
> >> need a init thingy? 
> > 
> > Same question as always: does your kernel have enough built-in
> > drivers/modules to mount the root fileystem on /?
> > 
> > If yes, then you don't need an initrd.
> > 
> > If no, then you do need an initrd.
> > 
> > I don't think where /usr is matters, does it?
> > 
> > --
> > Grant
> 
> My understanding, the whole init thing started with a bluetooth keyboard
> or mouse driver that was installed in /usr instead of /bin or /sbin,
> whichever one fits.  I've always had /usr on its own partition until
> this time.  Mostly because it is easier to put /boot and root on regular
> partitions and then put /usr, /var and of course /home on LVM.  That way
> as software like LOo, KDE and others grew, I could use LVM to grow them
> easily enough. 

You need access to the LVM tools to be able to access your /usr.  I expect 
they will be under /usr - hence you need an early userspace with the required 
tools to be able mount LVM and anything in it.

Alternatively, use btrfs and do away with LVM.


> Given the merge of bin and sbin to /usr, I have no idea if a system will
> boot without a init thingy or not.

It won't boot without a initrd if /usr is on a different partition, because 
the OS needs commands available on /usr to boot with.  Chicken <-> egg 
problem.


> This is the first time I've
> ran/installed a system with those merged.  I'd think it would work but I
> don't want to have a unbootable system to find out it doesn't either. 

With a merged /usr you will now also have /bin, /sbin, /lib, /lib64, all of 
them in /usr.



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

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

[Dale]

Grant Edwards wrote:
> On 2024-06-24, Dale  wrote:
>> Michael wrote:
>>> On Monday, 24 June 2024 20:47:15 BST Dale wrote:
>>>
 Have you seen this before?
>>> No, because I've never used dracut.
>> I just had a thought.  I have /usr on the root partition now.  Do I even
>> need a init thingy? 
> Same question as always: does your kernel have enough built-in
> drivers/modules to mount the root fileystem on /?
>
> If yes, then you don't need an initrd.
>
> If no, then you do need an initrd.
>
> I don't think where /usr is matters, does it?
>
> --
> Grant

My understanding, the whole init thing started with a bluetooth keyboard
or mouse driver that was installed in /usr instead of /bin or /sbin,
whichever one fits.  I've always had /usr on its own partition until
this time.  Mostly because it is easier to put /boot and root on regular
partitions and then put /usr, /var and of course /home on LVM.  That way
as software like LOo, KDE and others grew, I could use LVM to grow them
easily enough. 

Given the merge of bin and sbin to /usr, I have no idea if a system will
boot without a init thingy or not.  This is the first time I've
ran/installed a system with those merged.  I'd think it would work but I
don't want to have a unbootable system to find out it doesn't either. 
;-)  I'm having enough fun already.  LOL

Dale

:-)  :-) 

Re: [gentoo-user] Re: Keep getting LC_ALL error during install.

[Eli Schwartz]

On 6/16/24 7:22 PM, Wols Lists wrote:
> On 16/06/2024 23:39, Nuno Silva wrote:
>>> And of course, all the rules get bent by the various
>>> manufacturers. Bear in mind that basic EFI predates vFAT so even in
>>> UEFI vFAT isn't actually mandatory. Apple don't use it, iirc. There's
>>> nothing stopping GNU's OpenBIOS project or whatever it is using
>>> ext4. But vFAT is the official "lowest common denominator" which
>>> everything must support if it's not "single vendor for hardware and
>>> software". Which is why, of course, MS can't play fun and games - if
>>> they say Windows won't support vFAT they'll get hammered for
>>> anti-trust.
> 
>> But there are systems using exFAT, right? You mean UEFI firmwares will
>> happily accept other filesystems?
> 
> I don't know. But the formal specification of UEFI says it must accept
> vFAT (I believe exFAT was not acceptable because Microsoft had patented
> it). It does not say it can't accept other stuff. Which is why Apple
> doesn't use vFAT.
> 
> And it explicitly states the version of vFAT. I don't know which
> version, but it's along the lines of "version X dated Y", so that is
> locked in stone.
> 
> So basically, the UEFI spec says it CAN accept multiple filesystems, but
> it MUST accept vFAT if it wants the moniker "Universal". So unless (and
> probably even if) it's Apple hardware, it does support vFAT.


https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#file-system-format

"""
EFI encompasses the use of FAT32 for a system partition, and FAT12 or
FAT16 for removable media. The FAT32 system partition is identified by
an OSType value other than that used to identify previous versions of
FAT. This unique partition type distinguishes an EFI defined file system
from a normal FAT file system. The file system supported by EFI includes
support for long file names.
"""

It is permissible to additionally ship your own custom UEFI firmware
with arbitrary filesystem drivers that the specification does not
mandate support for, and Apple does this, but since Apple has to follow
the UEFI spec they support FAT as well.

You will notice upon reading, that UEFI mandates support for fat 12, but
permits a conforming implementation only support it for "removable media".

The firmware MUST support filesystem drivers for fat 12 / 16 / 32 in
order to satisfy this requirement, but is allowed to decline to use the
12 / 16 drivers unless the drive type is "removable media".

What that means in practice isn't obvious. But I somehow doubt any
firmware vendor is adding extra code to exercise their right to reject
the use of a driver they already had to commit to providing.


-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Keep getting LC_ALL error during install.

[Wols Lists]

On 16/06/2024 23:39, Nuno Silva wrote:

And of course, all the rules get bent by the various
manufacturers. Bear in mind that basic EFI predates vFAT so even in
UEFI vFAT isn't actually mandatory. Apple don't use it, iirc. There's
nothing stopping GNU's OpenBIOS project or whatever it is using
ext4. But vFAT is the official "lowest common denominator" which
everything must support if it's not "single vendor for hardware and
software". Which is why, of course, MS can't play fun and games - if
they say Windows won't support vFAT they'll get hammered for
anti-trust.



But there are systems using exFAT, right? You mean UEFI firmwares will
happily accept other filesystems?


I don't know. But the formal specification of UEFI says it must accept 
vFAT (I believe exFAT was not acceptable because Microsoft had patented 
it). It does not say it can't accept other stuff. Which is why Apple 
doesn't use vFAT.


And it explicitly states the version of vFAT. I don't know which 
version, but it's along the lines of "version X dated Y", so that is 
locked in stone.


So basically, the UEFI spec says it CAN accept multiple filesystems, but 
it MUST accept vFAT if it wants the moniker "Universal". So unless (and 
probably even if) it's Apple hardware, it does support vFAT.


Cheers,
Wol

Re: [gentoo-user] Re: (EE) AddScreen/ScreenInit failed for driver 0 [SOLVED]

[Michael]

On Tuesday, 11 June 2024 20:17:44 BST n952162 wrote:
> On 6/11/24 17:58, n952162 wrote:
> > Am I forgetting something ?
> 
> Yes. x11-drivers/xf86-video-intel

This package will be brought in as a dependency by emerge, as long as you have 
specified the correct VIDEO_CARDS="" drivers[1] in your make.conf and then 
emerged x11-base/xorg-server.[2]

Therefore it is not xf86-video-intel you forgot, but adding the necessary in 
make.conf.

[1] https://wiki.gentoo.org/wiki/Intel
[2] https://wiki.gentoo.org/wiki/X_server


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

Re: [gentoo-user] Re: python 3.12 update

[Rich Freeman]

On Wed, Jun 5, 2024 at 3:33 PM Wols Lists  wrote:
>
> On 05/06/2024 20:15, Meowie Gamer wrote:
> > I must've taken too long to join the mailing list because I missed the 
> > first part of whatever's happening here. How did this turn from python 3.12 
> > to a conversation about USE?
> >
>
> Because they're using USE or whatever to force packages to stay on 3.11,
> because they won't build with 3.12.
>
> So it's not necessarily about USE, but about the tactics people use to
> make emerge work the way they want. It might be MASK, or any of the
> other package... directories.

It is a bit more than that.  Even if you never touch
/etc/portage/package.use, you effectively will have USE flags set on
packages that involve python simply due to the profile (and the change
therein).  That is why the news item has you put -* at the start of
the setting if you're overriding it - otherwise you'll just be
appending to the profile setting.

While these do end up setting USE flags, you should still set the USE
expand variables as directed in the news item and documentation, and
not manipulate the USE flags directly.

-- 
Rich

Re: [gentoo-user] Re: python 3.12 update

[Joost Roeleveld]

--- Original message ---
From: Grant Edwards 
To: gentoo-user@lists.gentoo.org
Date: Wed, 05 Jun 2024 22:07:06 +0200



On 2024-06-05, Wols Lists  wrote:

On 05/06/2024 13:12, Eli Schwartz wrote:

Which I think is fine, if people want that, but not everyone does, so
delaying the update altogether might be preferable to those people.


Ie people like me who don't give a monkeys about python, and  
consider it a necessary evil.


I care quite a bit about Python and do a fair amount of developemnt in
Python. Howver, I don't (at this point) give a monkey's about 3.12 vs
3.11, so I'm just going to delay the 3.12 upgrade on all my machines
except for the one where I got stuck after step 1 of the now-famouse
"3 step upgrade process". :)

That one machine seems to be working fine (though it's still missing a
few packages that I removed because the build failed with 3.12). So
I'm going to leave it where it is (possibly reinstalling the missing
packages as I run into the need for them).

At some point, emerge -auvND will complain because some installed
package doesn't support 3.11 any longer — and then I'll upgrade to
3.12.


Except, if you use Python for development, it's slotted, so you can  
install any version you need (as long as it's in portage or an overlay).


The issue here is the devs insistence on upgrading to 3.12 before all  
the packages are ready for this.


In all this, I have yet to see a good reason apart from "Oooh... shiny!"

Re: [gentoo-user] Re: python 3.12 update

[Meowie Gamer]

I see, thanks for clearing it up.

Meowie

Re: [gentoo-user] Re: python 3.12 update

[Dale]

Meowie Gamer wrote:
> I must've taken too long to join the mailing list because I missed the first 
> part of whatever's happening here. How did this turn from python 3.12 to a 
> conversation about USE?
>
>


Because depending on what path you took to deal with this, you could end
up with entries in package.use for python 3.11. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: python 3.12 update

[Wols Lists]

On 05/06/2024 20:15, Meowie Gamer wrote:

I must've taken too long to join the mailing list because I missed the first 
part of whatever's happening here. How did this turn from python 3.12 to a 
conversation about USE?



Because they're using USE or whatever to force packages to stay on 3.11, 
because they won't build with 3.12.


So it's not necessarily about USE, but about the tactics people use to 
make emerge work the way they want. It might be MASK, or any of the 
other package... directories.


Cheers,
Wol

Re: [gentoo-user] Re: python 3.12 update

[Dale]

Wols Lists wrote:
> On 05/06/2024 13:28, Rich Freeman wrote:
>> Implementing dynamic USE management would take somebody a fair bit of
>> effort, and for all I know it would make every emerge you run take an
>> hour to recompute the dependency tree.  The ability to configure USE
>> flags, along with the ability to dynamically decide the version of
>> dynamically linked packages, makes Gentoo have a dependency tree that
>> is MUCH larger than basically any other distro out there.  This is why
>> portage takes so long to decide what to install compared to basically
>> everything else.
>
> What I at least try to do is use "autounmask-write", or whatever the
> appropriate option is. This does I believe flag individual versions of
> whatever.
>
> Then I DON'T let etc-update append the changes to J Random File in
> whatever package... directory is appropriate !!!
>
> I rename the ._ file to usually the name of the package I'm interested
> in, or maybe the current date, or whatever. Point is, I don't get some
> humungous file full of assorted unrelated dependencies. And then when
> I'm bored I go through deleting loads of files maybe 6 months old or
> more. Seeing as the packages have usually been replaced by then, it
> rarely affects anything.
>
> Yes it's a minor pain I have to go through this for pretty much every
> package update if I've got a problem package, but I do a --update once
> a week at most, so it's very little hassle.
>
> And occasionally I'll add the flag to make.conf, instead ... :-)
>
> Cheers,
> Wol
>
>


Don't forget eix-test-obsolete which will find and list entries that are
no longer needed.  Bad thing is, it doesn't seem to say which file it is
in when you use a directory.  It just says the type of file, *.use,
*.mask, *.keyword etc. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: python 3.12 update

[Meowie Gamer]

I must've taken too long to join the mailing list because I missed the first 
part of whatever's happening here. How did this turn from python 3.12 to a 
conversation about USE?

Re: [gentoo-user] Re: python 3.12 update

[Wols Lists]

On 05/06/2024 13:28, Rich Freeman wrote:

Implementing dynamic USE management would take somebody a fair bit of
effort, and for all I know it would make every emerge you run take an
hour to recompute the dependency tree.  The ability to configure USE
flags, along with the ability to dynamically decide the version of
dynamically linked packages, makes Gentoo have a dependency tree that
is MUCH larger than basically any other distro out there.  This is why
portage takes so long to decide what to install compared to basically
everything else.


What I at least try to do is use "autounmask-write", or whatever the 
appropriate option is. This does I believe flag individual versions of 
whatever.


Then I DON'T let etc-update append the changes to J Random File in 
whatever package... directory is appropriate !!!


I rename the ._ file to usually the name of the package I'm interested 
in, or maybe the current date, or whatever. Point is, I don't get some 
humungous file full of assorted unrelated dependencies. And then when 
I'm bored I go through deleting loads of files maybe 6 months old or 
more. Seeing as the packages have usually been replaced by then, it 
rarely affects anything.


Yes it's a minor pain I have to go through this for pretty much every 
package update if I've got a problem package, but I do a --update once a 
week at most, so it's very little hassle.


And occasionally I'll add the flag to make.conf, instead ... :-)

Cheers,
Wol

Re: [gentoo-user] Re: python 3.12 update

[Eli Schwartz]

On 6/5/24 2:05 PM, Grant Edwards wrote:
> What I found misleading (and tripped over) was the implication that
> the three step migration process outlined in the news item had a
> reasonable likelyhood of working for a large percentage of users.
> 
> If the new items had warned that anybody using one of 
> packages that won't work with 3.12 are going to have to stop after
> step 1 until those packages have been brought "up to date" so that
> they can build with 3.12.  Had I known that, I wouldn't have tried the
> three step migration and would have simply postponed the upgrade.


FWIW, I do think that for a large percentage of users, the lagging
packages simply aren't relevant to their use cases so it would indeed work.

Regardless, the purpose of the 3-step process I think is just to ensure
that portage doesn't trip while scheduling the rebuilds. If you are
getting dependency conflicts with the one-step process (emerge -puDU
@world) then steps 2 and 3 are likely not going to be able to be fully
carried out.


-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: python 3.12 update

[Arve Barsnes]

On Wed, 5 Jun 2024 at 20:05, Grant Edwards  wrote:
> What I found misleading (and tripped over) was the implication that
> the three step migration process outlined in the news item had a
> reasonable likelyhood of working for a large percentage of users.
>
> If the new items had warned that anybody using one of 
> packages that won't work with 3.12 are going to have to stop after
> step 1 until those packages have been brought "up to date" so that
> they can build with 3.12.  Had I known that, I wouldn't have tried the
> three step migration and would have simply postponed the upgrade.

Maybe I've been using gentoo too long, but I never assumed these three
steps were a 'single upgrade' recipe, I assumed each step were to be
undertaken as the portage tree allowed.

Reading the news item again, I see that no such thing is implied, but
perhaps it should have been? Otherwise, what is the point of these
steps as opposed to the automatic upgrade portage initially attempts?

The only way it is safer is if you have a complete functioning system
between each step, so I naturally assumed that there could be waiting
between each step to allow the tree to come to an upgradeable state.
Maybe some wording to that effect should be added when the 3.13 update
rolls around.

Either way, I went for the "bunch of 3.11 stuff in package.use" since
I "enjoy" that kind of process, so I wasn't impacted.

Regards,
Arve

Re: [gentoo-user] Re: python 3.12 update

[Rich Freeman]

On Wed, Jun 5, 2024 at 6:41 AM Dr Rainer Woitok  wrote:
>
> And no,  I don't buy  the point of view  that it's the responsibility of
> the developers  when my personal set  of USE flags suddenly  causes con-
> flicts.
>

Agree, but keep in mind that having personal sets of USE flags is
basically a necessity in Gentoo, and not a choice, because Gentoo does
not dynamically manage USE dependencies.

On any distro, including Gentoo, if you manually installed the
dependencies of every package you use explicitly, you'd probably end
up with a hopeless mess of dependency conflicts within a few months.
Everybody who has used Linux for any period of time understands that
this is a bad practice, and you should explicitly install the packages
you directly use, and let the package manager dynamically manage their
dependencies.  Then when a dependency becomes obsolete and is
replaced, the updates will happen automatically without the user
needing to worry about them.

Gentoo does this with package/version dependencies, but not with USE
flag dependencies.  If a package requires some other package to be
built with a particular USE flag, then portage will output an error,
and you will need to put an entry in package.use to manually specify
the USE configuration, and that will resolve the conflict. Then 5
years later you'll get some mysterious error due to that USE flag
setting being obsolete, and you have no idea why you even had it in
the first place unless you took meticulous notes, because the setting
doesn't reflect your own preference, but the requirements of some
package, which might be so far down the dependency tree that you don't
even know what it does.

Python version settings are just fancy ways of expressing USE
dependencies.  Unless you develop things in Python, you probably don't
care what versions of Python you have installed, and it is reasonable
to expect that the package manager or distro just takes care of this
for you.  Gentoo does not.

Implementing dynamic USE management would take somebody a fair bit of
effort, and for all I know it would make every emerge you run take an
hour to recompute the dependency tree.  The ability to configure USE
flags, along with the ability to dynamically decide the version of
dynamically linked packages, makes Gentoo have a dependency tree that
is MUCH larger than basically any other distro out there.  This is why
portage takes so long to decide what to install compared to basically
everything else.

It is this clash of expectations vs reality that causes many
frustration, and this is understandable.  That said, improving the
situation is a lot of work, whether this is in the form of a lot of
coordination to deal with the lack of dynamic USE dependencies, or the
effort to implement this feature in the package manager (which has
been discussed here and there for a decade or so).  You can't fault
volunteers for not working on things that they aren't interested in
working on.  That said, I do appreciate the frustration people have,
personally.  This is just one of those things you need to understand
about Gentoo, and then weigh the pros vs the cons when you choose what
distro to use.  If you want a distro that will just accept daily
updates with zero fuss, that isn't Gentoo.

-- 
Rich

Re: [gentoo-user] Re: python 3.12 update

[Dr Rainer Woitok]

Grant,

On Tue, 4 Jun 2024 17:00:29 - (UTC) you wrote:

> ...
> I don't see how (even in theory) steps 2 and 3 can work when you have
> packages installed that won't build with 3.12.

That depends  on your definition  of "work".   It occurs even when doing
normal updates that you run into a USE flag conflict  you have to solve.
If you call this a "failed" upgrade  and stop there,  well, that's up to
you.  Others simply roll up their sleeves, investigate and change or add
a USE flag.  Here the problem was NOT that Python 3.11 had vanished, but
just that Python 3.12 had become the new default.  So a finite number of
USE flag changes solved this problem.

And no,  I don't buy  the point of view  that it's the responsibility of
the developers  when my personal set  of USE flags suddenly  causes con-
flicts.

Sincerely,
  Rainer

Re: [gentoo-user] Re: python 3.12 update

[Eli Schwartz]

On 6/4/24 11:04 PM, Grant Edwards wrote:
> On 2024-06-04, Eli Schwartz  wrote:
>> If a package claimed to support python 3.12 and nonetheless failed to
>> build with it, that's a bug in the package -- can you provide more details?
> 
> IIRC, the first one was pycxx.  The build faild during the config
> step.  I uninstalled it (which meant I also had to uninstall pysvn,
> which I think means that meld is going to stop working).


Thanks for the report. This was migrated to python 3.12 in
https://bugs.gentoo.org/929486 and indeed it builds fine for me.

However, it is very obvious, *to me*, why it failed for you (even
without build logs). The package doesn't have a build dependency on the
dev-python/setuptools package, and python 3.12 removed a standard
library module (distutils) which is henceforth provided by this package.
And pycxx doesn't use pep517 mode either.

It's a trivial fix. You would have seen a build error that looked
something like

ModuleNotFoundError: No module named 'distutils'


I have queued the fix, so this should start working soon.

I do understand that this doesn't necessarily help you anymore, but
still. I am happy to at least make *one* package work reliably.

(Well, other packages too, just unrelated to your report.)


-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: python 3.12 update

[Eli Schwartz]

On 6/4/24 4:58 PM, Grant Edwards wrote:
> On 2024-06-04, Eli Schwartz  wrote:
> 
>> Note that it's not a build failure -- it is an upgrade calculation
>> failure. It fails before upgrading any packages since it knows it can't
>> resolve the dependencies.
> 
> I had plenty of both.


If a package claimed to support python 3.12 and nonetheless failed to
build with it, that's a bug in the package -- can you provide more details?


-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Mobo, CPU, memory and a m.2 thingy. This work together?

[Wols Lists]

On 03/06/2024 16:34, Dale wrote:

The way I did my last two rigs is this.  Find the fastest CPU.  Drop
down about 2 models.  That is not the fastest but very close to it but a
LOT cheaper.  Then buy a mobo and memory to go with it.  You get a
system that is likely close to 90% of the fastest you can get but a lot
cheaper.  Nowadays, even if you drop down a lot, it still costs a arm
and a leg and you get a lot less.


:-)

I look at tech as having two pricing models - the champagne model for 
the new stuff, where doubling performance doubles the price. And the 
coke model for older tech, where transport costs dominate, and different 
specs don't differ much in price. If I can get my tech at the "knee", 
where champagne prices become coke prices, I'm happy.


Cheers,
Wol

Re: [gentoo-user] Re: Mobo, CPU, memory and a m.2 thingy. This work together?

[Dale]

Wols Lists wrote:
> On 03/06/2024 12:07, MasterP wrote:
>> *NOTE*: Almost minutes after I wrote this, and before posting it, AMD
>> announced at Computex that the new gen will be available next month. So
>> maybe waiting for the new processors could be a good idea. Although
>> at the
>> launch, both the new boards and cpus are probably going to be very
>> expensive. Still, most new mid-to-high end boards will now have USB4
>> ports.
>
> My reaction - even if you buy the older version, this announcement
> will push down the "old tech" prices. Don't wait too long though, as a
> lot of stuff could be "end-of-lifed" and sold off cheap, rather than
> kept in production at a lower price point.
>
> Cheers.
> Wol
>
>


It is a delicate balance.  If you buy brand new tech, you pay for it,
BIG time.  If you drop down just a little, it is almost as fast but a
LOT cheaper. 

The way I did my last two rigs is this.  Find the fastest CPU.  Drop
down about 2 models.  That is not the fastest but very close to it but a
LOT cheaper.  Then buy a mobo and memory to go with it.  You get a
system that is likely close to 90% of the fastest you can get but a lot
cheaper.  Nowadays, even if you drop down a lot, it still costs a arm
and a leg and you get a lot less. 

Still a lot of think on.  I just wonder what prices will be like in 2 or
3 weeks.  Still, I do at least want AM5.  That AM4 is tempting tho. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Mobo, CPU, memory and a m.2 thingy. This work together?

[Wols Lists]

On 03/06/2024 12:07, MasterP wrote:

*NOTE*: Almost minutes after I wrote this, and before posting it, AMD
announced at Computex that the new gen will be available next month. So
maybe waiting for the new processors could be a good idea. Although at the
launch, both the new boards and cpus are probably going to be very
expensive. Still, most new mid-to-high end boards will now have USB4
ports.


My reaction - even if you buy the older version, this announcement will 
push down the "old tech" prices. Don't wait too long though, as a lot of 
stuff could be "end-of-lifed" and sold off cheap, rather than kept in 
production at a lower price point.


Cheers.
Wol

Re: [gentoo-user] Re: preparing /dev/sda1 for gentoo install x86 handbook

[Waldo Lemmer]

On Sun, Jun 2, 2024, 13:28 Nuno Silva  wrote:

> (Well, one request I have is to please don't top-post in this
> list. That's not the common style in this list, and tends to be an
> approach mostly from the Microsoft and business worlds.)
>

Top-posting is the default in Gmail, and there's no intuitive way to avoid
doing it in the Gmail app.

By default, quoted text is hidden behind three dots. After expanding those
three dots, attempting to append text to the bottom results in that text
being included as part of the quoted text. To avoid that, the quoted text
first needs to be modified in some way. That allows a newline at the end to
escape out of the quoted portion.

Finally, the two empty lines before the quoted text should be removed.

Waldo

>

Re: [gentoo-user] Re: preparing /dev/sda1 for gentoo install x86 handbook

[Dale]

Nuno Silva wrote:
> Some people may prefer one method of communication to the other, and one
> thing that has perhaps been lacking in Gentoo is more people reading the
> mailing list, which might allow finding out about (and acting on) some
> issues sooner.

I agree with this.  I subscribe to the -dev mailing list for that
reason.  I see news items that are coming before they even available
elsewhere.  I just saw one on texlive having file collisions where you
must uninstall it first, then install the new version.  Having a heads
up that something outside the norm is coming can be handy. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: preparing /dev/sda1 for gentoo install x86 handbook

[Peter Humphrey]

On Sunday, 2 June 2024 01:54:08 BST Grant Edwards wrote:
> On 2024-06-01, Wol  wrote:
> > I've got news for you, there are quite a few weirdos on the list,
> 
> Hey! I resemble that remark.

Hey! Are you pinching my joke?

-- 
Regards,
Peter.


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

Re: [gentoo-user] Re: preparing /dev/sda1 for gentoo install x86 handbook

[Dale]

Mark Knecht wrote:
>
>
> On Sat, Jun 1, 2024 at 1:16 PM Wol  > wrote:
> > I've got news for you, there are quite a few weirdos on the list, but it
> > adds spice!
> >
> Ah! I feel so at home!
>
> Thanks Wol!


+1.  I've been told I was weird all my life.  I kinda take offense when
someone says I'm not weird now.  ROFL 

Dale

:-)  :-) 

P. S.  On the subject of threads and Gentoo related.  I've decided to
use my credit card and buy the mobo, CPU and memory.  So, I'm going
through info that others posted in earlier threads and I'm about ready
to pull all my hair out.  To be blunt, none of the mobos are worth half
the price they want to charge.  I just watched a video of a guy ranting
about the exact same thing I'm thinking.  Make it flashy, use obscure
language to make something old sound new and raise the price to the
sky.  Oh, also put stuff on the mobo that should be handled with a PCIe
card, for those few who want that feature.  Don't forget, raise the
price some more for something the buyer doesn't want and intends to
disable at first boot up.  I realize this is basically a text only
mailing list.  Imagine a emoji thingy that is red from anger and very
frustrated.  I used to love to pick parts to build a system.  Now, I
just want it to be over with so I can end my misery.  It went from being
fun to being something akin to digging up a plugged sewer line, that you
know is going to spray you with some nasty stuff.  :-@

Expect another thread on this.  Whenever I get done letting the steam
escape from my eyes and ears. 

Re: [gentoo-user] Re: preparing /dev/sda1 for gentoo install x86 handbook

[Mark Knecht]

On Sat, Jun 1, 2024 at 1:16 PM Wol  wrote:
> I've got news for you, there are quite a few weirdos on the list, but it
> adds spice!
>
Ah! I feel so at home!

Thanks Wol!

Re: [gentoo-user] Re: preparing /dev/sda1 for gentoo install x86 handbook

[Kévin GASPARD DE RENEFORT]

Hello,

This was not a "moderator" like answer, more an advice: Since I started 
to translate some pages in French for the Wiki of Gentoo, I've already 
asked why IRC and not somewhere else, as **the mailing-list** dedicated 
to it. I do not link the oblivion that is an IRC channel, to be honest.


Somehow, it's (wiki's ML) unused, and more "regular" peoples, doing 
wiki's works since a while now, told me that… they do it on two places:


- #gentoo-w...@libera.chat

- Each discussion page for each dedicated subject.

I'm not on the #gentoo-wiki channel to explain how to do things at these 
contributors… doing it since years, or decade(s). I'm here to participate.


"Some complete" stranger to the list is happy to present himself: 
https://wiki.gentoo.org/wiki/User:Kgdrenefort


Joke aside, I just wanted to be nice and redirect another user to 
somewhere which could be, maybe, a better place to talk about it :).


Regards,
GASPARD DE RENEFORT Kévin

Le 01/06/2024 à 22:15, Wol a écrit :

On 31/05/2024 16:26, Nuno Silva wrote:

On 2024-05-31, Kévin GASPARD DE RENEFORT wrote:

Is this not possible to go, as I said, on IRC or use the discussion 
page ?


This is not really the place for this topic, IMHO.


Why not? This is a Gentoo mailing list. Do you mean it should instead be
brought up in the Gentoo Documentation Project mailing list?

That was my sort-of reaction, but for somewhat different reasons. We 
have a regular poster on the list posting something a little bit 
weird, and then we have someone I've never seen on the list before, 
posting a moderator-like message.


Seriously? Some complete stranger to the list, telling off a regular 
for posting something weird?


I've got news for you, there are quite a few weirdos on the list, but 
it adds spice!


Cheers,
Wol

Re: [gentoo-user] Re: preparing /dev/sda1 for gentoo install x86 handbook

[Wol]

On 31/05/2024 16:26, Nuno Silva wrote:

On 2024-05-31, Kévin GASPARD DE RENEFORT wrote:


Is this not possible to go, as I said, on IRC or use the discussion page ?

This is not really the place for this topic, IMHO.


Why not? This is a Gentoo mailing list. Do you mean it should instead be
brought up in the Gentoo Documentation Project mailing list?

That was my sort-of reaction, but for somewhat different reasons. We 
have a regular poster on the list posting something a little bit weird, 
and then we have someone I've never seen on the list before, posting a 
moderator-like message.


Seriously? Some complete stranger to the list, telling off a regular for 
posting something weird?


I've got news for you, there are quite a few weirdos on the list, but it 
adds spice!


Cheers,
Wol

Re: [gentoo-user] Re: preparing /dev/sda1 for gentoo install x86 handbook

[Jude DaShiell]

It went on irc.


--
 Jude 
 "There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo.
 Please use in that order."
 Ed Howdershelt 1940.

On Fri, 31 May 2024, Nuno Silva wrote:

> On 2024-05-31, Kévin GASPARD DE RENEFORT wrote:
>
> > Is this not possible to go, as I said, on IRC or use the discussion page ?
> >
> > This is not really the place for this topic, IMHO.
>
> Why not? This is a Gentoo mailing list. Do you mean it should instead be
> brought up in the Gentoo Documentation Project mailing list?
>
>

Re: [gentoo-user] Re: PCIe version 2, 3 etc and how to know which a card is.

[Michael]

On Tuesday, 28 May 2024 19:02:09 BST Dale wrote:
> Grant Edwards wrote:
> > On 2024-05-28, Dale  wrote:
> >> Grant Edwards wrote:
> >>> On 2024-05-21, Dale  wrote:
> > Here's my udev rules file that defines my network interface names
> > for the machine I'm on at the moment:
> > 
> > --/etc/udev/rules.d/70-my-persistent-net.rules
> > --- SUBSYSTEM=="net", ACTION=="add",
> > ATTR{address}=="2c:f0:5d:6f:10:af", NAME="net0" SUBSYSTEM=="net",
> > ACTION=="add", ATTR{address}=="00:1b:21:b1:d1:e9", NAME="net1"
> > -
> > >> 
> >> Got a little busy with my garden.  Found my first zucchini yesterday. 
> >> Ready to pick in a few days.  Found some small tomatoes too.  Anyway. 
> >> Did manage to create this rule tho.  This look reasonable?  I'm thinking
> >> it should be named something else tho.  It could clash with the usual
> >> name. 
> >> 
> >> # PCI device 0x11ab:0x4363 (Intel e1000e)
> >> #SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> >> ATTR{address}=="68:05:ca:42:17:39",ATTR{dev_id}=="0x0", ATTR{type}=="1",
> >> KERNEL=="eth*", NAME="enp3s0"
> > 
> > Did my examples (with the MAC addresses and device names changed) not
> > work?
> > 
> >> I got the ATTR address from ifconfig.  I'm not real sure on the other
> >> ATTR variables tho.
> > 
> > I don't use the other other ATTRs, ACTION, DRIVERS, or KERNEL and I
> > don't know why you added them, so I can't comment.
> > 
> > --
> > Grant
> 
> Well, I found one with google and sort of went by that.  Now that I read
> yours again, yours makes more sense, from what little I know.  o_O
> 
> Is ATTR address the same as Mac address?  If so, why not have the same
> names for all tools  How's this look?

An ATTR can be any of the identifying attributes of your particular NIC.  Take 
a look in /sys/class/net/ to find out the current name of the device, e.g. 
enp4s0, then look at its attributes:

udevadm info -a /sys/class/net/enp4s0/

You can use any attributes which *uniquely* identify the NIC, e.g. vendor/
device ID, MAC address, etc. to avoid misidentification.


> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="68:05:ca:42:17:39",
> NAME="dale0"
> 
> 
> I gave it a different name this time.  I'm assuming I'd need to reboot to
> test this or is restarting udev enough??

If it is a remote PC and you're using netifrc, you'll need to create a new 
symlink, e.g.:

ln -s /etc/init.d/net.lo /etc/init.d/net.dale0

You probably know you can stop the predictable device naming by adding to your 
kernel command line:

net.ifnames=0

If you only have one wired NIC, then it will pop up as eth0.


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

Re: [gentoo-user] Re: PCIe version 2, 3 etc and how to know which a card is.

[Dale]

Grant Edwards wrote:
> On 2024-05-28, Dale  wrote:
>> Grant Edwards wrote:
>>> On 2024-05-21, Dale  wrote:
>>>
> Here's my udev rules file that defines my network interface names
> for the machine I'm on at the moment:
>
> --/etc/udev/rules.d/70-my-persistent-net.rules---
> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="2c:f0:5d:6f:10:af", 
> NAME="net0"
> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1b:21:b1:d1:e9", 
> NAME="net1"
> -
>> Got a little busy with my garden.  Found my first zucchini yesterday. 
>> Ready to pick in a few days.  Found some small tomatoes too.  Anyway. 
>> Did manage to create this rule tho.  This look reasonable?  I'm thinking
>> it should be named something else tho.  It could clash with the usual
>> name. 
>>
>> # PCI device 0x11ab:0x4363 (Intel e1000e)
>> #SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>> ATTR{address}=="68:05:ca:42:17:39",ATTR{dev_id}=="0x0", ATTR{type}=="1",
>> KERNEL=="eth*", NAME="enp3s0"
> Did my examples (with the MAC addresses and device names changed) not
> work?
>
>> I got the ATTR address from ifconfig.  I'm not real sure on the other
>> ATTR variables tho.
> I don't use the other other ATTRs, ACTION, DRIVERS, or KERNEL and I
> don't know why you added them, so I can't comment.
>
> --
> Grant

Well, I found one with google and sort of went by that.  Now that I read
yours again, yours makes more sense, from what little I know.  o_O

Is ATTR address the same as Mac address?  If so, why not have the same
names for all tools  How's this look?

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="68:05:ca:42:17:39", 
NAME="dale0"


I gave it a different name this time.  I'm assuming I'd need to reboot to test 
this or is restarting udev enough?? 

Dang it's humid outside.  I feel like I need diving gear out there so I can 
breathe.  O_O 

Dale 

:-)  :-)  

Re: [gentoo-user] Re: PCIe version 2, 3 etc and how to know which a card is.

[Dale]

Grant Edwards wrote:
> On 2024-05-21, Dale  wrote:
>
>>> Here's my udev rules file that defines my network interface names
>>> for the machine I'm on at the moment:
>>>
>>> --/etc/udev/rules.d/70-my-persistent-net.rules---
>>> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="2c:f0:5d:6f:10:af", 
>>> NAME="net0"
>>> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1b:21:b1:d1:e9", 
>>> NAME="net1"
>>> -
>> Examples do help a lot.  I do use the enp* naming scheme.  My
>> understanding, that is the "new" way.
> The suffix for those enp* names comes from the PCI bus subsystem based
> on bus number, slot number, etc.  [Yes, slot number apparently does
> change based on what PCIe cards are present. No, that doesn't make
> sense to me either]
>
>> Based on your config, I would need to change the NAME= to enp* names
>> and that would correct that.
> I suppose you could, but I would not use enp* names. Those could
> conflict with the autogenerated names.
>
>> Where you have ATTR, is that a quote or did you edit to remove a
>> number, MAC address, IP or something? 
> What I posted is exactly what's in the file
> (without the --- delimiters).
>
> Here's more documentation:
>
> https://wiki.gentoo.org/wiki/Udev
> https://wiki.archlinux.org/title/udev
> https://wiki.archlinux.org/title/Network_configuration#Change_interface_name
>
> [The arch Wiki is always a good fallback if the Gentoo manual/Wiki
> don't have what you're looking for.]
>
>> If it is one of those, where do I find that info?  I checked
>> ifconfig and didn't see a MAC address.  I also checked lspci -v. 
>> I'm not sure where you get the needed info from.   BTW, right now,
>> I'm on my main rig. 
> The only thing you need to change from my example would be the mac
> address(es) (e.g. 2c:f0:5d:6f:10:af) and the names (e.g. net0).
>
>> I have the package net-misc/networkmanager installed.  Most likely
>> pulled in by something else.  Could I use it to configure this? 
> Possibly, I don't use networkmanager and don't know how it works on
> Gentoo.  I use the default Gentoo netifrc scheme
> https://wiki.gentoo.org/wiki/Netifrc.
>
>> I also have KDE installed on the NAS box, it is also a backup rig in
>> case my main rig dies.  It may have a GUI that I could use.  I'm not
>> opposed to the command line way tho.  Biggest thing, copy and paste
>> would be nice. 
> I don't know much of anything about KDE.
>
> --
> Grant

Got a little busy with my garden.  Found my first zucchini yesterday. 
Ready to pick in a few days.  Found some small tomatoes too.  Anyway. 
Did manage to create this rule tho.  This look reasonable?  I'm thinking
it should be named something else tho.  It could clash with the usual
name. 

# PCI device 0x11ab:0x4363 (Intel e1000e)
#SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="68:05:ca:42:17:39",ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="eth*", NAME="enp3s0"

I got the ATTR address from ifconfig.  I'm not real sure on the other
ATTR variables tho.

I did this on my main rig.  It is commented out at the moment.  I'll use
it as a guide on the NAS box tho.  May enable this on my main rig, just
so they all the same.

Ironically, I removed the net.enp* from the default runlevel and put
dhcpd back.  It starts no matter where the card is located with that. 
It just sees it, starts it and carries on.  Still, I'd like all my
installs to be done the same way.  It's hard enough to remember how to
do things.  :/

Thanks.

Dale

:-)  :-) 

Re: [gentoo-user] Re: Off Topic - UPnP servers

[Mark Knecht]

On Sat, May 25, 2024 at 3:14 PM Grant Edwards 
wrote:
>
> On 2024-05-24, Mark Knecht  wrote:
>
> > The unit showed up today and was a breeze to set up and get running
> > at a basic level. The device requires an app on my phone.
>
> That sets of an alarm for me.
>
> > The app is available for Android and Apple but not available for the
> > Amazon Fire tablet.
>
> Good luck...  I avoid products like that. There have been too many
> "smart" things in the past that required an app -- then the app
> stopped working two or three years later. The purchaser of the thing
> now has a useless lump, and has to start shopping for a replacement.

Yeah, that's a reasonable point of view and one I hadn't considered.

Cheers.
Mark

Re: [gentoo-user] Re: Off Topic - UPnP servers

[Mark Knecht]

On Fri, May 24, 2024 at 1:25 PM Tsukasa Mcp_Reznor 
wrote:
>
> For what it's worth I've been using gerbera for years, it'll pass-through
supported videos/codecs or you can set it up to transcode.   Highly
recommend it.  On my roku TV's I just use the roku media player, it'll see
UPnP servers just fine.

Thanks. Great info and much appreciated.

The unit showed up today and was a breeze to set up and get running at a
basic level. The device requires an app on my phone. The app is available
for Android and Apple but not available for the Amazon Fire tablet.

I was able to stream Internet Radio immediately. I then transferred
about 20% of my CD collection FLAC files to a flash drive and they play
fine and sound great. I am currently using the audio output on the unit but
will be testing my Schitt Modi DAC over the weekend, along with attempting
to connect to Plex.

One small problem I ran into is the unused flash drive I had in the flash
drive box had a default FAT filesystem on it and the FLAC library, ripped
mostly with k3b but also a little abcde, has characters in names that
aren't supported so I had some complaints getting things copied. I will say
that a big flash drive might be a great solution to not having to turn the
server on and having media available 24/7.

Cheers,
Mark

Re: [gentoo-user] Re: Off Topic - UPnP servers

[Tsukasa Mcp_Reznor]

For what it's worth I've been using gerbera for years, it'll pass-through 
supported videos/codecs or you can set it up to transcode.   Highly recommend 
it.  On my roku TV's I just use the roku media player, it'll see UPnP servers 
just fine.

Re: [gentoo-user] Re: Off Topic - UPnP servers

[Mark Knecht]

On Fri, May 24, 2024 at 8:26 AM Grant Edwards 
wrote:
>
> On 2024-05-24, Mark Knecht  wrote:
>
> > I'm a Plex user for video and have also ripped my CD
> > collection. Plex plays audio fine to TVs that have a Plex app but
> > apparently sometimes doesn't work well (as of yet untested by me) to
> > network streaming players.
>
> I never got the Plex app for Roku to work in a usable manner (and I
> think it eventually got discontinued?).  The Plex app in Kodi has
> always worked fine for me (though I haven't used it for probably about
> a year).  Plex also worked with other DLNA clients I've tried (Kodi, VLC).
>
> > While I don't know if the above will be a problem I've purchased a
> > network streaming player and will test it out over the weekend when it
> > arrives but if Plex doesn't work, or doesn't work well,
>
> I'd be interested to hear what player you got and how it works with Plex.
>

The Cambridge Audio MXN10 which is arriving today. Good reviews but I've
never listened to it so that will be interesting. I'll be using an older
NAD pre
and power amp and a pair of Theil 1.2's. I'll start without my old
subwoofer
and see what it's like but the 1.2's aren't the greatest at low-end so I'll
add the SW if necessary.

I'd like to start with my ripped CD content but for about $10/month it will
stream from Tidal and a few other sources so if I have any trouble serving
content then I'll get a Tidal subscription.

I'll report back on the Plex side as it goes as well as any other servers I
try out. I'm sorta leaning toward Gerbera for it's simplicity and clean
looking interface but it comes down to how the server works with the
C.A. StreamMagic app as this streamer has no front panel controls.

Thanks for the info.

Cheers,
Mark

Re: [gentoo-user] Re: PCIe version 2, 3 etc and how to know which a card is.

[Dale]

Grant Edwards wrote:
> On 2024-05-21, Dale  wrote:
>
>
>>> If you want consisent network device names (even when you change
>>> hardware), you need to either
>>>
>>>  1. create udev rules that assign device names based on MAC addresses.
>>>
>>>  2. use a network configuration subsystem that assigns device names
>>> and configurations based on MAC addresses.
>> Do you, or someone else, know of a good howto on how to use MAC
>> addresses like that?  Given this thing is usually remotely accessed, I
>> really need it to be consistent with or without the card.  Maybe you
>> have a bookmarked link saved somewhere.  I'm on openrc to.  I'll google
>> around but you, or someone else here, may have a really good and simple
>> howto link. 
> The udev way is probably the most universal. Some distros will create
> udev rules automagically so that network interface names persist over
> hardware changes, but Gentoo doesn't.  Here's my udev rules file that
> defines my network interface names for the machine I'm on at the moment:
>
> --/etc/udev/rules.d/70-my-persistent-net.rules---
> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="2c:f0:5d:6f:10:af", 
> NAME="net0"
> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1b:21:b1:d1:e9", 
> NAME="net1"
> -
>
> I used to use "ethN" instead of "netN", but those names are used
> internally by the kernel during startup, and people were warned not to
> use them in udev rules because of certain race conditions that might
> happen.  I never ran into problems using "ethN" names, but eventually
> decided not to push my luck.
>
> The network configuration route depends on what network configuration
> (and possibly init) system you use.  I know how to do it that way on
> Ubunutu (which is systemd based) using netplan...
>
> --
> Grant

Examples do help a lot.  I do use the enp* naming scheme.  My
understanding, that is the "new" way.  Based on your config, I would
need to change the NAME= to enp* names and that would correct that. 
Where you have ATTR, is that a quote or did you edit to remove a number,
MAC address, IP or something?  If it is one of those, where do I find
that info?  I checked ifconfig and didn't see a MAC address.  I also
checked lspci -v.  I'm not sure where you get the needed info from. 
BTW, right now, I'm on my main rig. 

I have the package net-misc/networkmanager installed.  Most likely
pulled in by something else.  Could I use it to configure this?  I also
have KDE installed on the NAS box, it is also a backup rig in case my
main rig dies.  It may have a GUI that I could use.  I'm not opposed to
the command line way tho.  Biggest thing, copy and paste would be nice. 
;-) 

I'm trying to hoe weeds in my garden at the moment.  Hoe a little, take
a break, then repeat.  I did sharpen the edge on my hoe tho.  If I touch
it, it's cut.  Makes it a lot easier. 

Thanks. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: PCIe version 2, 3 etc and how to know which a card is.

[Dale]

Grant Edwards wrote:
> On 2024-05-21, Dale  wrote:
>
>> So they both show up.  When I try to start the network, it says:
>>
>> ERROR: Interface enp3s0 does not exist.
> Are you sure the network interface name hasn't changed?  What does
> "ifconfig -a" or "ip addr" show?
>
> After booting up, what does "dmesg | grep enp" show?
>
>> Ensure that you have loaded the correct kernel module for your hardware.
>>
>>
>> I find that odd since it obviously sees the card.  It's in the list
>> above after all.  So, it sees the card but can't see it.  0_o  Odd. 
> Identifying the presense of a PCI card and creating the device by
> which is is accessed are two different things.
>
>> I tried different slots for the SATA card and they all do the same
>> thing.  Wouldn't each slot have a different interrupt?
> No.  If cards are using legacy interrupts (most do) there are four
> interrupts (A,B,C,D) that are shared by all cards (just like there
> always were). Newer cards and motherboards can use something called
> MSI or MSI-X interrupts that aren't shared, but in my experience the
> use of those isn't very widespread.
>
>> It was at this point, I checked your suggestion.  I looked and noticed
>> that the network card was now at slot 4 not slot 3 like it used to be. 
>> So, I created a new link to slot 4.  The network came up.  So,
>> basically, it changed names as you suggested. I thought the purpose of
>> the enp* names was that they are consistent. 
> They are consistent through reboots.  They are not consistent if you
> change hardware.
>
>> Adding or removing cards wouldn't change the names of cards, like
>> network cards.
> Yes, it can.
>
>> It seems, in this case at least, the names can change.  Any way to
>> make adding the card not change this??  I tend to not have a monitor
>> or keyboard connected to this rig.
> If you want consisent network device names (even when you change
> hardware), you need to either
>
>  1. create udev rules that assign device names based on MAC addresses.
>
>  2. use a network configuration subsystem that assigns device names
> and configurations based on MAC addresses.
>
> --
> Grant

Do you, or someone else, know of a good howto on how to use MAC
addresses like that?  Given this thing is usually remotely accessed, I
really need it to be consistent with or without the card.  Maybe you
have a bookmarked link saved somewhere.  I'm on openrc to.  I'll google
around but you, or someone else here, may have a really good and simple
howto link. 

Well, learned something in the past couple days.  Thanks.

Dale

:-)  :-) 

Re: [gentoo-user] Re: PCIe version 2, 3 etc and how to know which a card is.

[Neil Bothwick]

On Tue, 21 May 2024 06:51:51 -0400, Rich Freeman wrote:

>  I usually stick e*
> in my networkd config for the device name on single-NIC hosts.  If you
> have multiple NICs then I maybe there is a better way to go about it -
> maybe there is a network manager that can use more data from the NIC
> itself to track them.

systemd .network definitions can match on MAC address, if that helps.


-- 
Neil Bothwick

... "I dropped my toothpaste," Tom said, Crestfallen.


pgpGZMKuEyY6P.pgp
Description: OpenPGP digital signature