Hello List,
how can I get back the ability writing accents on my KDE3-desktop?
My System is openSUSE 13.1 with KDE3 (3.5.10 release 262) from
inofficial Suse-repos. I'm using the keyboard layout with dead keys.
Under KDE4 all applications can work with accents. Under KDE3 there
is no application writing accents.
Writing accents is active (kcontrol).
Any hints (or is this behaviour a bug)?.
Thanks,
Helga
--
## Technik: [http://de.opensuse.org]
## Privat: [http://www.eschkitai.de]
--
To unsubscribe, e-mail: opensuse-kde3+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kde3+owner(a)opensuse.org
All,
On a new 42.3 install, the journal is filling with hundreds of messages on boot:
Apr 08 07:40:05 wizard systemd-udevd[1386]: failed to execute
'/usr/lib/udev/socket:@/org/freedesktop/hal/udev_event'
'socket:@/org/freedesktop/hal/udev_event': No such file or directory
Why should systemd be looking for the /org/freedesktop/hal/udev_event?
Aren't we building with --nohal? or should I have installed something else to
provide this dependency?
KDE3 is running great -- I was just surprised to see the boot messages when
I checked with:
$ journalctl -n -l -b -p 3
--
David C. Rankin, J.D.,P.E.
--
To unsubscribe, e-mail: opensuse-kde3+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kde3+owner(a)opensuse.org
All,
There are a couple of tweaks you can make to have kdm/kde3 boot like a
rocket ship. kde-kdebase does not include a kdm3.service file. This causes
systemd to flail around looking for one. I have one from the TDE builds I did
for Arch that I installed on 42.3 -- works perfect!
$ cat /usr/lib/systemd/system/kdm3.service
[Unit]
Description=KDE3 Display Manager
After=systemd-user-sessions.service
[Service]
ExecStart=/opt/kde3/bin/kdm
[Install]
Alias=display-manager.service
Just create the file and save it as /usr/lib/systemd/system/kdm3.service.
Then do
# systemctl daemon reload
(to have systemd re-read its services files)
Then just enable the service:
# systemctl enable kdm3
That's it, the next boot, systemd will enable kdm3.service and the 90 sec
timeout looking for a display manager is gone, e.g.
17:29 wizard:~/cnf/kde> sc -l status kdm3
● kdm3.service - KDE3 Display Manager
Loaded: loaded (/usr/lib/systemd/system/kdm3.service; enabled; vendor
preset: disabled)
Active: active (running) since Sat 2018-04-21 17:00:28 CDT; 29min ago
Main PID: 1351 (kdm)
Tasks: 2 (limit: 512)
CGroup: /system.slice/kdm3.service
├─1351 /opt/kde3/bin/kdm
└─1451 /usr/bin/Xorg -br -nolisten tcp :0 vt8 -auth
/var/lib/xdm/authdir/authfiles/A:0-5uunkE
Apr 21 17:00:28 wizard systemd[1]: Started KDE3 Display Manager.
=== We need to add this to the kdebase package ===
Next, wicked has an incredibly long global timeout of 30 seconds set (it
doesn't require any, but I set it at 1 second just to be on the safe side).
This doesn't effect all systems, but caused my system with Intel eth0 to hang
(even though no cable is plugged in) for the full 30 sec timeout causing my
boot time to balloon to nearly 1 minute.
You fix the problem by editing /etc/sysconfig/network/config and setting:
WAIT_FOR_INTERFACES="1"
After reducing the wait time from 30 to 1 second, I can now boot from
OFF/cold to full KDE3 (with my custom kdm moodin splash theme) in 12.1
seconds, e.g.
$ systemd-analyze
Startup finished in 5.455s (kernel) + 3.466s (initrd) + 3.193s (userspace) =
12.115s
That is the entire boot to my killer login in a total of 12.115 seconds.
That's the way Linux with SSD should work. I can even drop another second by
leaving WAIT_FOR_INTERFACES="" (empty).
Give it a try if you have a boot delay based on wicked. To see all your
services and their boot activation times, systemd plot with create a handy
.svg graphic showing all service activation and the time it takes, just use:
$ systemd-analyze plot > yourfile.svg
The just look at it in a browser to determine if you have any delays you can
fix -- and exactly what they are.
--
David C. Rankin, J.D.,P.E.
--
To unsubscribe, e-mail: opensuse-kde3+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kde3+owner(a)opensuse.org
Ilya, all
(Ilya, I dropped a note on the kde-kdegraphics3 buildservice page)
The current build of fribidi (which kde-kdegraphics3 requires) deprecates
the symbol fribidi_log2vis required by the .svg preview for konqueror and the
file-open dialog. The deprecation is controlled by a simple #define in
fribidi-0.19.2/lib/common.h, e.g.
#define FRIBIDI_NO_DEPRECATED
I have patched and build fribidi removing the define with a simple comment
(ironic in what is captured in the patch)
--- fribidi-0.19.2/lib/common.h
+++ fribidi-0.19.2/lib/common.h 2018-04-19 02:17:14.407743609 -0500
@@ -178,9 +178,9 @@
# define _GNU_SOURCE
#endif /* !_GNU_SOURCE */
-/* We respect our own rules. */
+/* We respect our own rules.
#define FRIBIDI_NO_DEPRECATED
-
+*/
#include "debug.h"
Now that I have fribidi built, I would like to rebuild kdegraphics using the
new (old) fribidi, however, my build-service foo isn't quite up to the task. I
can branch kdegraphics to my build-service account, but how do I tell it to
use my fribidi instead of the normal fribidi from OSS? I don't have any
problems adding or removing or modifying the .spec, but in the 'requires', how
do I say "Use my fribid, not the one from OSS?"
Any help there would be appreciated...
--
David C. Rankin, J.D.,P.E.
--
To unsubscribe, e-mail: opensuse-kde3+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kde3+owner(a)opensuse.org
All,
Attempting a preview of a .svg file (from systemd-analyze) in konqueror
produced a error dialog:
There was an error loading the module KSVGPlugin.
The diagnostics is:
/opt/kde3/lib64/libtext2path.so.0: undefined symbol: fribidi_log2vis
Which is provided by kdegraphics3-3.5.10-153.53.x86_64. Has there been a
soname bump in one of the libraries used by kdegraphics that is causing the
problem?
How can we trigger a rebuild of kdegraphics to see if that fixes the problem?
The .svg file opens just fine in inkscape, so it isn't a problem with the
.svg file.
--
David C. Rankin, J.D.,P.E.
--
To unsubscribe, e-mail: opensuse-kde3+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kde3+owner(a)opensuse.org
None of GDM, LightDM, SDDM provide functionality provided by KDM3 or KDM4. Thus,
one or the other is still needed as long as
http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_Tumbleweed/ remains
populated.
Why should KDM# depend on anything from Packman? Even 42.3 and 15.0 show ~ the
following:
# zypper se -s libIlmImf
| libIlmImf-Imf_2_1-21-32bit | package | 2.1.0-10.3.1 | x86_64 | Update
| libIlmImf-Imf_2_1-21-32bit | package | 2.1.0-9.5 | x86_64 | OSS
i | libIlmImf-2_2-22 | package | 2.2.0-37.2 | x86_64 | (System Packages)
i | libIlmImf-Imf_2_1-21 | package | 2.1.0-10.3.1 | x86_64 | Update
v | libIlmImf-Imf_2_1-21 | package | 2.1.0-9.5 | x86_64 | OSS
Why does a DM even need a "Library to Handle EXR Pictures in 16-Bit" in the
first place?
--
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
--
To unsubscribe, e-mail: opensuse-kde3+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kde3+owner(a)opensuse.org