Re: [gentoo-user] Dolphin confusing different run instances.

2024-09-13 Thread Peter Humphrey
On Thursday 12 September 2024 13:54:25 BST Dale wrote:

> This is fairly new and very consistent.  It started a couple updates ago
> and I was hoping it was a bug and would be fixed.  I'm starting to think
> it is a new feature.  I've looked in preferences and can't find any
> setting related to this behavior.

Is it related to the recent problem in sddm or plasma, in which things appear 
on the wrong desktops on startup, or all piled up on top of one another?

-- 
Regards,
Peter.






Re: [gentoo-user] Dolphin confusing different run instances.

2024-09-13 Thread Dale
Peter Humphrey wrote:
> On Thursday 12 September 2024 13:54:25 BST Dale wrote:
>
>> This is fairly new and very consistent.  It started a couple updates ago
>> and I was hoping it was a bug and would be fixed.  I'm starting to think
>> it is a new feature.  I've looked in preferences and can't find any
>> setting related to this behavior.
> Is it related to the recent problem in sddm or plasma, in which things appear 
> on the wrong desktops on startup, or all piled up on top of one another?
>


Not this time.  There was a setting for this but I didn't think it would
do what I wanted so I didn't try it.  Frank mentioned that was the
correct setting and I tried it.  Sure enough, that was the problem.  I
figured I either missed something or Dolphin just made a big change. It
was me. 

I will say this to tho, I was getting the same plasma thing until I
started setting up window rules for all my apps.  I also removed the
plasma panel thingy at the bottom of screen two.  That also helped with
some other issues.  Firefox started going to screen 2 the other day.  I
set up window rules for it and included both size and screen location. 
It seems the Force option is the only reliable way to make it work tho. 

I notice another KDE release is on the way.  It's unstable when it hits
the tree but I run unstable for KDE and friends.  It may have some fixes
as well.  Introduce a new feature, get half a dozen bugs to fix.  Fix
those and then repeat.  LOL  Isn't that the way software works??? 

Should have a nice update to do this weekend. 

Dale

:-)  :-) 

P. S.  Checksum tool says this now.  (dir 190 of 631)  It's chewing on
it.  Just like eating a elephant.  :-D



Re: [gentoo-user] Dolphin confusing different run instances.

2024-09-13 Thread Peter Humphrey
On Friday 13 September 2024 11:03:08 BST Dale wrote:

> I notice another KDE release is on the way.  It's unstable when it hits
> the tree but I run unstable for KDE and friends.  It may have some fixes
> as well.  Introduce a new feature, get half a dozen bugs to fix.  Fix
> those and then repeat.  LOL  Isn't that the way software works??? 
> 
> Should have a nice update to do this weekend. 

Good news - I've just installed it, and it does seem to have fixed my problem 
with misplaced windows. Just a quick look so far, but it seems good. I only 
have the one connected monitor, though.

-- 
Regards,
Peter.






[gentoo-user] xpra server on gentoo? Any gotchas?

2024-09-13 Thread n952162

Hello all,

when I run an xpra server on a gentoo box and attach via a client is on
a nixos box), I get the following:

   /: Permission denied (publickey,password,keyboard-interactive)./
   /2024-09-13 11:04:03,232 Error: failed to receive anything, not an
   xpra server?/
   /2024-09-13 11:04:03,233   could also be the wrong protocol,
   username, password or port/
   /2024-09-13 11:04:03,233   or the session was not found/
   /2024-09-13 11:04:03,233 Connection failed/

"PasswordAuthentication yes" is left commented out in
/etc/ssh/sshd_config, i.e. is the default.

Anyone experience this?



Re: [gentoo-user] Dolphin confusing different run instances.

2024-09-13 Thread Frank Steinmetzger
Am Fri, Sep 13, 2024 at 01:19:00AM -0500 schrieb Dale:

> >> P. S.  Planning to try that checksum script soon.  It's a large number
> >> of files so it will take a long time to run.  I think you mentioned that
> >> if stopped, it will resume where it left off.
> > Only if it creates checksums, because it knows by the existence of 
> > checksums 
> > where to resume. But if you want to read checksums and verify them, you 
> > need 
> > to use arguments to tell it how many directories to process and how many to 
> > skip at the beginning.
> >
> > Perhaps try it first with a few small directories to get a feel for its 
> > behaviour. The normal way to go is:
> >
> > dh -u [DIR] to create the checksum files
> > dh [DIR] do read it back
> > Use the --skip option to skip the given number of dirs at the beginning.
> >
> > Remember that by default it will not create checksums in directories that 
> > have subdirectories. I know this sounds a little strange, but for a 
> > hierarchy of music albums, this seemed sensible 10 years ago.
> >
> 
> Well, I read through the help page and settled on this.  I might have
> did this wrong.  ;-)
> 
> /root/dh -c -F 1Checksums.md5 -v
> 
> Right now I have the command in /root.  I just did a cd to the parent
> directory I wanted it to work on and then ran that command.  Right now,
> it is working on this bit.
> 
> 
> (dir 141 of 631)
> 
> and
> 
> (file  8079 of 34061)

I am thinking about adding filesize information, but that would require 
updating the status line during the processing of a file instead of only 
between files. That’s not trivial, as it involves timers and threads.

> I was wondering tho, is there a way to make it put all the checksum
> files in one place, like a directory call checksums, and they just all
> go in there?

Hm … from an algorithmic point of view, it would actually not be that 
complicated by creating a shortened filename from the source directory, but 
the real-world use seems a bit far-fetched. Checksums should be close to 
their data. If you have read errors for either, then the other is useless 
anyways. :D

> Or just a single file in the parent directory?  That way
> the files aren't in each directory.

That’s what the -s option is for. This will create only one checksum file at 
the root level for each directory argument. So if you run `dh -us foo/ bar/`, 
then it will go into foo/, create one checksum file there and put all lines 
into that one file, even for subdirectories, and do the same in bar/.

However, at the moment automatically detecting and properly verifying those 
files is still in the works. So I think you have to use the -s option or -F 
all to read them.

> Thing is, can I still just run it
> on one directory if I have a suspected bad one?

Not with one checksum file at the root level for an entire tree. The way I 
would handle this case: run dh -u on the directory of interest and then 
compare the checksums in the root-level file and the newly created file with 
a diff tool. Or copy the lines from the existing checksum file, create a new 
file in the directory of interest, remove the directory part of the paths 
and then run dh on just that directory.

-- 
Grüße | Greetings | Salut | Qapla’
I don’t have a problem with alcohol, just without!


signature.asc
Description: PGP signature