Re: [gentoo-user] KDE Frameworks 6 window management
On Friday 6 September 2024 02:02:55 BST Dale wrote: > For some reason, the second monitor has a plasma thing, where app menu > icon, virtual desktop, clock and such is, on the second monitor as > well. My TV screen has nothing. No desktop icons, plasma thingy or > anything. It just has a default background image and that is it. Why > the second monitor got done that way, I dunno. May I should remove the > plasma thing completely. The "... plasma thing" = Plasma Panel container Can be placed on any screen edge. Can be more than one. Starting from the left, it contains: 1. Kmenu (i.e. application menu/launcher) 2. Desktop pager (virtual desktops) 3. Task manager (shortcut icons to applications and open applications) 4. System Tray (notifications, Kmix, clock, etc.) >From what I recall SystemSettings allows you to select to have the Plasma Panel only on the primary monitor. That's how I've set it on a dual monitor PC here. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Wayland and CPU load
On Friday 6 September 2024 01:33:04 BST Peter Humphrey wrote: > On Friday 6 September 2024 00:21:31 BST Peter Humphrey wrote: > > I think I know what it is: the kernel's list of firmware blobs is empty. I > > don't know where they all went, but it shouldn't be too hard to find them. > > Indeed it was so. Now fixed and working fine. Without all requisite firmware for your graphics the Kwin compositor will fall back to software rendering. As you've experienced without hardware acceleration Kwin will eat up CPU cycles. Emerging sys-kernel/linux-firmware and configuring your system to use it fixes the problem by providing the necessary code for the graphics card to do the heavy lifting: https://wiki.gentoo.org/wiki/Intel signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Wayland and CPU load
On Friday 6 September 2024 10:10:47 BST Michael wrote: > On Friday 6 September 2024 01:33:04 BST Peter Humphrey wrote: > > On Friday 6 September 2024 00:21:31 BST Peter Humphrey wrote: > > > I think I know what it is: the kernel's list of firmware blobs is empty. > > > I > > > don't know where they all went, but it shouldn't be too hard to find > > > them. > > > > Indeed it was so. Now fixed and working fine. > > Without all requisite firmware for your graphics the Kwin compositor will > fall back to software rendering. As you've experienced without hardware > acceleration Kwin will eat up CPU cycles. > > Emerging sys-kernel/linux-firmware and configuring your system to use it > fixes the problem by providing the necessary code for the graphics card to > do the heavy lifting: Yes, I know, and I had it set up from when I acquired the machine. The mystery is why it was missing from my two most recent kernels. -- Regards, Peter.
Re: [gentoo-user] Wayland and CPU load
On Friday 6 September 2024 10:45:26 BST Peter Humphrey wrote: > On Friday 6 September 2024 10:10:47 BST Michael wrote: > > On Friday 6 September 2024 01:33:04 BST Peter Humphrey wrote: > > > On Friday 6 September 2024 00:21:31 BST Peter Humphrey wrote: > > > > I think I know what it is: the kernel's list of firmware blobs is > > > > empty. > > > > I > > > > don't know where they all went, but it shouldn't be too hard to find > > > > them. > > > > > > Indeed it was so. Now fixed and working fine. > > > > Without all requisite firmware for your graphics the Kwin compositor will > > fall back to software rendering. As you've experienced without hardware > > acceleration Kwin will eat up CPU cycles. > > > > Emerging sys-kernel/linux-firmware and configuring your system to use it > > fixes the problem by providing the necessary code for the graphics card to > > > do the heavy lifting: > Yes, I know, and I had it set up from when I acquired the machine. The > mystery is why it was missing from my two most recent kernels. You could have inadvertently cleaned this package from your /var/lib/portage/ world, or unmerged it for some reason. Worth noting, dmesg would have complained it can't find this & that firmware. Either way, problem solved. :-) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] KDE Frameworks 6 window management
Michael wrote: > On Friday 6 September 2024 02:02:55 BST Dale wrote: > >> For some reason, the second monitor has a plasma thing, where app menu >> icon, virtual desktop, clock and such is, on the second monitor as >> well. My TV screen has nothing. No desktop icons, plasma thingy or >> anything. It just has a default background image and that is it. Why >> the second monitor got done that way, I dunno. May I should remove the >> plasma thing completely. > The "... plasma thing" = Plasma Panel container > > Can be placed on any screen edge. > > Can be more than one. > > Starting from the left, it contains: > > 1. Kmenu (i.e. application menu/launcher) > 2. Desktop pager (virtual desktops) > 3. Task manager (shortcut icons to applications and open applications) > 4. System Tray (notifications, Kmix, clock, etc.) > > >From what I recall SystemSettings allows you to select to have the Plasma > Panel only on the primary monitor. That's how I've set it on a dual monitor > PC here. Well, on my old rig, the second screen, TV, never had the plasma panel. On the new rig, it showed up on both from the beginning. I guess I could just delete/remove it. I don't really see a need for two anyway. I get why the primary has one. Just no idea why the second does but yet the third doesn't. It looks like if the default is to add one to all screens, then the TV would have one too. It's not like the puter knows I only have two of the monitors sitting in front of me and the third is elsewhere. ;-) I might add, another odd thing that started after a recent update. When I logout of KDE or when first booting and am on the sddm login screen, my first monitor powers off. The second monitor stays on and has the login screen as does the TV screen. Yet the primary screen turns off. At first when we got past the wonky monitor problem, all three would stay on and mirror each other. Now it doesn't. I might add, if I switch to a console, screen one turns back on and all three mirror each other. I kinda like that because if I need to do something that takes a bit, I don't have to go to the living room to turn the TV back on again. This monitor situation is getting plenty weird. I never know when it is going to change something and work weirdly. I don't know what is changing it tho. I haven't changed anything. Dale :-) :-)
Re: [gentoo-user] KDE Frameworks 6 window management
On Friday 6 September 2024 12:04:08 BST Dale wrote: > I might add, another odd thing that started after a recent update. When > I logout of KDE or when first booting and am on the sddm login screen, > my first monitor powers off. The second monitor stays on and has the > login screen as does the TV screen. Yet the primary screen turns off. > At first when we got past the wonky monitor problem, all three would > stay on and mirror each other. Now it doesn't. > > I might add, if I switch to a console, screen one turns back on and all > three mirror each other. I kinda like that because if I need to do > something that takes a bit, I don't have to go to the living room to > turn the TV back on again. It sounds as if the primary monitor is using DPMS in Xorg, if you're running X, or some similar energy saving feature. Check SystemSettings > Power Management > Display and Brightness. Meanwhile back at the ranch, I think my Gkrellm dock panel problem is related to KDE 6 not identifying the Gkrellm window as a 'dock/panel', probably because the Gtk2 code is far too old to integrate with Plasma. :-( signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Wayland and CPU load
On Friday 6 September 2024 11:41:03 BST Michael wrote: > You could have inadvertently cleaned this package from your > /var/lib/portage/ world, or unmerged it for some reason. No, nothing like that. The sources and config files were all present, but the extra_firmware entries had been deleted. I know I'm getting a bit old for all this, but how can I inadvertently remove something I know should stay put? > Worth noting, dmesg would have complained it can't find this & that firmware. That's what put me on to it. > Either way, problem solved. :-) Indeed. -- Regards, Peter.
Re: [gentoo-user] KDE Frameworks 6 window management
Michael wrote: > On Friday 6 September 2024 12:04:08 BST Dale wrote: > >> I might add, another odd thing that started after a recent update. When >> I logout of KDE or when first booting and am on the sddm login screen, >> my first monitor powers off. The second monitor stays on and has the >> login screen as does the TV screen. Yet the primary screen turns off. >> At first when we got past the wonky monitor problem, all three would >> stay on and mirror each other. Now it doesn't. >> >> I might add, if I switch to a console, screen one turns back on and all >> three mirror each other. I kinda like that because if I need to do >> something that takes a bit, I don't have to go to the living room to >> turn the TV back on again. > It sounds as if the primary monitor is using DPMS in Xorg, if you're running > X, or some similar energy saving feature. Check SystemSettings > Power > Management > Display and Brightness. You may be on to something. I have DPMS enabled on my two main monitors but not the TV. That said, I had my monitors set to not turn off. I did that the other day so that they would stay on while I was doing my emerge -e world. I wanted to keep a eye on it in case something failed and the emerge stopped. Should I have DPMS set to on or turn them all off in xorg.conf? I'm thinking on. Thursday a week ago tho, everything turned off when I locked the screen, TV as well. It seems it can turn things off even without DPMS. > Meanwhile back at the ranch, I think my Gkrellm dock panel problem is related > to KDE 6 not identifying the Gkrellm window as a 'dock/panel', probably > because the Gtk2 code is far too old to integrate with Plasma. :-( > > This is bad. It's a sign gkrellm might stop working. I hope someone who can code will update and keep gkrellm alive and going. I'd hate to see that go away. That's a awesome tool that is impossible to replace. I don't know of anything that comes close. Dale :-) :-)
Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".
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] KDE Frameworks 6 window management
On Friday 6 September 2024 12:40:25 BST Dale wrote: > Michael wrote: > > On Friday 6 September 2024 12:04:08 BST Dale wrote: > >> I might add, another odd thing that started after a recent update. When > >> I logout of KDE or when first booting and am on the sddm login screen, > >> my first monitor powers off. The second monitor stays on and has the > >> login screen as does the TV screen. Yet the primary screen turns off. > >> At first when we got past the wonky monitor problem, all three would > >> stay on and mirror each other. Now it doesn't. > >> > >> I might add, if I switch to a console, screen one turns back on and all > >> three mirror each other. I kinda like that because if I need to do > >> something that takes a bit, I don't have to go to the living room to > >> turn the TV back on again. > > > > It sounds as if the primary monitor is using DPMS in Xorg, if you're > > running X, or some similar energy saving feature. Check SystemSettings > > > Power Management > Display and Brightness. > > You may be on to something. I have DPMS enabled on my two main monitors > but not the TV. That said, I had my monitors set to not turn off. I > did that the other day so that they would stay on while I was doing my > emerge -e world. I wanted to keep a eye on it in case something failed > and the emerge stopped. > > Should I have DPMS set to on or turn them all off in xorg.conf? I'm > thinking on. Thursday a week ago tho, everything turned off when I > locked the screen, TV as well. It seems it can turn things off even > without DPMS. > > > Meanwhile back at the ranch, I think my Gkrellm dock panel problem is > > related to KDE 6 not identifying the Gkrellm window as a 'dock/panel', > > probably because the Gtk2 code is far too old to integrate with Plasma. > > :-( > This is bad. It's a sign gkrellm might stop working. I hope someone > who can code will update and keep gkrellm alive and going. I'd hate to > see that go away. That's a awesome tool that is impossible to replace. > I don't know of anything that comes close. > > Dale > > :-) :-) The second problem I started this thread with, related to the Kmail composer window inheriting the main Kmail window size and vice versa, seems to occur because both windows are identified having the same "kmail org.kde.kmail2" named Class. I played around with various properties, like window type and what not, but I have not been able to add a separate window size for the composer alone without affecting the main Kmail window. If anyone comes up with a working solution please chime in! signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] KDE Frameworks 6 window management
On 2024.09.06 11:12, Michael wrote: [snip ] The second problem I started this thread with, related to the Kmail composer window inheriting the main Kmail window size and vice versa, seems to occur because both windows are identified having the same "kmail org.kde.kmail2" named Class. I played around with various properties, like window type and what not, but I have not been able to add a separate window size for the composer alone without affecting the main Kmail window. If anyone comes up with a working solution please chime in! I haven't been following very closely, but it sound like one approach would be to have one of the windows use a different name Class. Might it be worth raising as an issue for kmail itself?
Re: [gentoo-user] Re: Package compile failures with "internal compiler error: Segmentation fault".
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".
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".
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".
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 :-) :-)
