![](https://seccdn.libravatar.org/avatar/a836ff90f492078f494adcf0c6059fc6.jpg?s=120&d=mm&r=g)
-pj composed on 2024-05-16 23:37 (UTC-0500): ...
i | ruby3.2 | package | 3.2.2-4.3 | i586 | (System Packages) i | ruby3.2-rubygem-abstract_method | package | 1.2.1-2.8 | i586 | (System Packages) i | ruby3.2-rubygem-cfa | package | 1.0.2-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-cfa_grub2 | package | 2.0.0-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-cheetah | package | 1.0.0-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-fast_gettext | package | 2.3.0-1.3 | i586 | (System Packages) i | ruby3.2-rubygem-gem2rpm | package | 0.10.1-22.3 | i586 | (System Packages) i | ruby3.2-rubygem-nokogiri | package | 1.15.5-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-ruby-augeas | package | 0.5.0-3.8 | i586 | (System Packages) i | ruby3.2-rubygem-ruby-dbus | package | 0.23.1-2.3 | i586 | (System Packages) i | ruby3.2-rubygem-simpleidn | package | 0.2.1-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-unf | package | 0.1.4-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-unf_ext | package | 0.0.9.1-1.3 | i586 | (System Packages)
It seems as if nothing has changed after trying to ensure that "zypper dup" has completed fully.
I purged ruby3.2* on several installations manually after they were upgraded to ruby3.3* and left behind. Why zypper dup purged them itself on some and why on others not I never tried to determine.
and probably all but the brothers
in the list above. I don't believe there's any justification to continue having libKF5* or libKPim5* packages installed any more unless you purposely locked them so that they could not be upgraded or removed. Boost*1_84_0* has been upgraded to 1_85_0*. Highly likely incomplete zypper dup is the root cause of https://bugzilla.opensuse.org/show_bug.cgi?id=1224061.
I honestly do not think this is the case here (imcomplete zypper dup). What is the best way to check the "zypper dup" for completed status then? Passing zypper ve -> Dependencies of all installed packages are satisfied. Passing zypper ll -> no package locks are defined.
Zypper ve can only do so much. I use zypper pa --unneeded to find out what remains stuck in the cobwebs and needs admin purging. Apt-get can do this automatically on Debian, but zypper apparently hasn't yet been taught how. Until every instance of "(System Packages)" can be satisfactorily justified, I consider a dup incomplete.
Enabling software rendering allows me to navigate SDDM but creates a much less usable system tray/taskbar. Disabling software rendering (reverting to hardware rendering) now, nearly disables SDDM's display capability to select a different window manager or whatever else. It is much more difficult due to every option label displaying blank fields. I have been working a bit with the Enlightenment desktop on this machine directly after the 32 bit KDE Plasma P6 MEGARELEASE issues.
Your old laptop with 945GM graphics appears may be on the edge of a support maintenance cliff. Cf. https://bugzilla.opensuse.org/show_bug.cgi?id=1212696 (i965-only problem) Many moons ago, a new display driver technology was introduced as default, called device independent X, or DIX. It wasn't intended to support antiques, as there was too little of it still working in the hands of driver developers and maintainers at that point in time. The dividing line between supported or not for Intel GPUs was somewhere between 945 (not supported; yours) and 965 (supported). Until then, display drivers were all device dependent, or DDX. Thus, oldies like yours need support need the DDX adequately maintained, in an environment where the newer favorite child "modesetting DIX" gets most of the developer attention. For the 945, that's the xf86-video-intel rpm. It hasn't had an official "release" in somewhere around a decade. The current version in TW is 2.99.917.916yadayada. :p AFAIK, none of the DMs I am happy to use (not GDM; not SDDM) care in any way about graphics rendering configuration. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata