Hi,
gapan wrote:westms wrote:1. After I had installed Salix64 Xfce 14.2beta1 first time, I installed the multimedia codecs. It noticed that QT4 (qt-4.8.7-x86_64-4.txz) is on the list of selectable codecs and which is also installed. Is that intended?
The openal-soft package included a GUI configuration tool that uses qt4. I have rebuilt the package to not include it now, so qt should not be needed anymore.
Thanks.
gapan wrote:westms wrote:1 In .xsession-errors there are two warning messages:
"(xfce4-session:1096): xfce4-session-WARNING **: xfsm_manager_load_session: Something wrong with /home/westms/.cache/sessions/xfce4-session-darkstar:0, Does it exist? Permissions issue?"
The message is the whole thing between the two double quotes. In fact, there is no directory xfce4-session-darkstar:0. There is only a directory thumbs-darkstar:0
Do you have the "Save session" option checked when logging out of xfce? I get that too, but I never save the xfce session.
No. Neither do I.
For testing, I added a directory
xfce4-session-darkstar:0. Permissions 0600. The message was persistent. Then I removed the directory and replaced it with an empty file with the same name. Permissions 0600. The message is gone.
Added: I searched the message. Is known for some time. Maybe the developers manage to eliminate the associated programming error someday.
gapan wrote:westms wrote:2. Another message in .xsession-errors:
xscreensaver: 22:12:59: couldn't get password of "root"
Fehlgeschlagen: Modulinitialisierung fehlgeschlagen
The last line in English would be: "Failed: module initialization failed"
I don't get that here. There is no reason xscreensaver should need the root password. I don't know why you get that message.
To see what happens, I enable the root user password. After a reboot, the xscreensaver message was gone.
Added: I may have found the answer to the root password problem in the xscreensaver FAQ (Q. # 9).
https://www.jwz.org/xscreensaver/faq.html#setuid
The xscreensaver runs with setuid bit. There remains the question of why the root password is supposedly required.
The "Fehlgeschlagen: Modulinitialisierung fehlgeschlagen" message is persistent. So it must be independent of the previous message, which was not recognized and it was noticed only later.
Added: This message may have various causes. The message may be a about a missing pulseaudio-component or is a consequence of the removal of the cgproxy and cgmanager processes.
gapan wrote:
Yes, it is. Make sure you have this line in your /etc/cups/cupsd.conf:
You might have replaced it without knowing while running dotnew.
Or, enable the root user password and use it...
Code: Select all
[etc]$ ls -l passwd*
-rw-r--r-- 1 root root 1347 Jul 22 00:54 passwd
-rw------- 1 root root 1346 Jul 22 00:54 passwd-
-rw-r--r-- 1 root root 1241 Mär 26 17:56 passwd.new
[etc]$
Code: Select all
[cups]$ ls -l cups*
-rw-r--r-- 1 root root 15560 Jun 13 05:22 cups-browsed.conf
-rw-r----- 1 root lp 2918 Feb 23 07:31 cups-files.conf
-rw-r----- 1 root lp 2918 Jun 15 07:53 cups-files.conf.default
-rw-r----- 1 root lp 4496 Jul 22 00:44 cupsd.conf
-rw-r----- 1 root lp 4496 Jun 15 07:53 cupsd.conf.default
[cups]$
below I try to explain what I see and suspect for the CUPS behavior.
My last beta1 installation was almost entirely completed on 22th of July at 0:54 o'clock. This can be seen at the file date of passwd.
The
cupsd.conf file was created during the installation, which can be seen at the file date. The
cupsd.conf.default file is older than a month. Both files have the exact same content, and they
do not contain a "System Group" line.
The files
cups-files.conf and
cups-files.conf.default are both older than my installation. They are also exactly the same and
contain a line with "System Group sys root", but
not the wheel group.
I conclude that dotnew is not responsible for the absence of the line or the group. The program I've never called manually, too.
The user configuration has been moved from
cupsd.conf to
cups-files.conf, which I also now read the first time. See the first paragraph in
man cupsd.conf.
Perhaps that was not previously aware of when creating the alpha1/beta1 releases 14.2. Maybe this comes also from upstream. I can imagine that somewhere in the entire sequence (building, installing or configure) wheel will be automatically added to the "System Group" list in
cupsd.conf. But there is no such line "System Group" included, and therefore the procedure goes under.
I added wheel to the SystemGroup list in
cups-files.conf. CUPS let me add a printer now.
A note: Especially Xfce feels very tough and is really slow. For testing, I use my fastest computer. Nevertheless Salix64 Xfce 14.2beta1 is slower than Salix64 Xfce 14.1 (with original kernel) on a slightly weaker computer. Probably there is still extensive logging and tracing. For example, in
~/.xfce4-session.verbose-log. Can we expect a speed increase later?
I test on.