kde apps extremely slow

[jyp]

Hi
Just completed a long overdue du this afternoo on 3 machines that have been happily running siduction for quite a while: a thinkpad and two similar desktop boxes, all running Intel video.
As usual, everything went smoothly except on one of the desktop machine.

Dolphin, Gwenview, Konqueror are so slow to respond that they are virtually unusable.
Krusader, Kate, Gimp all seem to work normally.
I tried hard to find something through Google without any success.
Any clue or direction that I could investigate?
Thanks.

[dibl]

Slow KDE packages does not appear to be a common problem -- there are no other recent reports like this.

You will have to use htop or other diagnostic tools to find out exactly which process is consuming too many resources, whether it is CPU or memory that is the bottleneck, and then apply your google-foo to search for other cases similar to yours.

There is a known current bug in the xserver-xorg and xserver-common packages, but the bug report says it causes a plasma-desktop freeze:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900149

I did not experience this bug on my 3 KDE desktop systems, but other users are waiting to upgrade until the fixed packages are available.

[jyp]

Thanks @dibl for replying
I did use htop to see unusual behavior, cpu or memory wise, but didn't notice anything strange.
I will keep trying to find something and post it if relevant.
The last resort would be to reinstall using the latest image, patience 2018.3.0, and keep from upgrading that recent image until things get sorted out.

Also, a big thank to the team for all the tremendously good work and the constant caring of siduction users.

[devil]

There was something with a file from vbox that needed to be deleted. Can't find it right now, on vacation and only equipped with a phone. Someone else reading this might jump in. The issues shows one of the problems stemming from infrequently updating. Noone can tell you when the problem was introduced.

[jyp]

@devil wrote

one of the problems stemming from infrequently updating

.
Yes, my bad. It is not my usual behavior but things happen sometimes.
Maybe downgrading to

   
• xserver-common_1.19.6-1_all.deb
• xserver-xorg-core_1.19.6-1_amd64.deb
• xserver-xorg-video-intel_2.99.917+git20171229-1_amd64.deb

Never done that kind of procedure but I will search for it.

[jyp]

So I downloaded

   
• xserver-common_1.19.6-1_all.deb
• xserver-xorg-core_1.19.6-1_amd64.deb
• xserver-xorg-video-intel_2.99.917+git20171229-1_amd64.deb

Do I need to first purge

   
• xserver-common_1.20.0-2_all
• xserver-xorg-core_1.20.02_amd64
• xserver-xorg-video-intel_2.99.917+git20171229-1+_amd64

or simply do

Code Auswählen Erweitern

dpkg -i server-common_1.19.6-1_all.deb xserver-xorg-core_1.19.6-1_amd64.deb xserver-xorg-video-intel_2.99.917+git20171229-1_amd64.deb
And what about the config files?
Thank you.

[dibl]

Yes, you'll purge first, but here's a problem for you.  What you should have done was enable the repos where you found the older package versions, (was it stable or testing?) and disable the unstable repo.  You say you "downloaded" but what if those three packages have dependencies, and those dependencies are located in repos that you do not have enabled?

So, you will have to enable the repos where you found the 19.6-1 packages, and disable the unstable repos, and then

Code Auswählen Erweitern

apt update and then

Code Auswählen Erweitern

apt install and install the three packages that you downloaded, FROM THE REPO, not using the downloaded packages.

This could work -- good luck!  And of course we still don't know whether the xserver packages are even the source your slow KDE packages, so .........

[jyp]

@dibl
Thanks for the big picture! I was naively assuming that it was simply a substitution of  packages.I downloaded the packages from snapshot.debian.org.
I am also aware that dpkg does not take care of dependencies.
Patience... I will wait out for the next xserver-* update.
Thanks again.

[melmarker]

I am also aware that dpkg does not take care of dependencies.
Patience... I will wait out for the next xserver-* update.

Maybe a different approach is also helpful next time such things happend - why use plumbing tools if one could use the porcelain - yes, analogue to git plumbing and procelain. apt is able to install local packages and do the resolving work. apt-show-versions might be helpful too:

• point to the snapshot you like
• comment out sid
• update the package list
• use apt-show-versions to show which packages are not in any archive
• happy hacking

[jyp]

@melmarker
Forgive my ignorance but the main part of the procedure is a bit cryptic to me._point to the snapshot you like_ ?? Does it mean modifying _/etc/apt/sources.list.d_ ? adding the snapshot repo? Something like _http://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main_?
_comment out sid_?? Does it mean commenting out the line pointing to sid in _/etc/apt/sources.list.d_ ?
Thanks

[melmarker]

You get it nearly right - except the lenny part. Let's take nano:
* in buildd is 1.98-1, you want the older version (hypotetical)
* you type in the package you want in the snapshots main page
* you get your result: http://snapshot.debian.org/package/nano/
* http://snapshot.debian.org/package/nano/2.9.7-1/  <-- the version we want
* we look when the binaries are last seen in snapshots

Code Auswählen Erweitern


4ec23d1e8df1115f1791e3e58b9220d79a9629b4:

    nano_2.9.7-1_amd64.deb
        Seen in debian on 2018-05-16 15:32:04 in /pool/main/n/nano.

  * we extract the link and build a source line from:
     http://snapshot.debian.org/archive/debian/20180516T153204Z/pool/main/n/nano/

Code Auswählen Erweitern


deb  http://snapshot.debian.org/archive/debian/20180516T153204Z/ unstable main
# deb $some_debian_mirror/debian unstable main

  * we should now apt update - the regular repo is commented out, so the mirror have the latest version
 
after doing so business as usual

[jyp]

Thanks a lot.
Almost right would not have done it. You made it clear.
Always fun to learn.Thanks again.

[melmarker]

and now to the really funny part - downgrades don't work in several situations like any kind of databases or applications that changed the data format within the new version - sure, one can downgrade the application - but whats about the datas?

[piper]

Code Auswählen Erweitern

rm -f /etc/X11/Xsession.d/98vboxadd-xclient

vbox that needed to be deleted