LinuxQuestions.org - Call for testing

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Call for testing - MATE SlackBuilds (https://www.linuxquestions.org/questions/slackware-14/call-for-testing-mate-slackbuilds-4175455139/)

On my machine, it worked well, but it started a lot of file manager processes, causing the systray no room for other application and causing the machine to work on high load all the time until i logged out of the system.

any ideas on how to solve this problem?

i'm running -Current and i have all modules built fine here

i traced the mate-file-manager and run it in KDE and it reported an error

Code:

willysr@desktop:~$ caja

Initializing caja-open-terminal extension

The program 'caja' received an X Window System error.

This probably reflects a bug in the program.

The error was 'BadDrawable (invalid Pixmap or Window parameter)'.

  (Details: serial 7 error_code 9 request_code 53 minor_code 0)

  (Note to programmers: normally, X errors are reported asynchronously;

  that is, you will receive the error a while after causing it.

  To debug your program, run it with the --sync command line

  option to change this behavior. You can then get a meaningful

  backtrace from your debugger if you break on the gdk_x_error() function.)

however, when i ran caja --sync as suggested, it worked well...
now the problem is how to make caja is called with --sync parameter by default :)

Huh, I'm not seeing that at all. It's working nicely here, 136 processes total with no real load. How are you starting MATE - from KDM/login manager or via startx?

Via startx after i changed the default DE into mate

i solved it temporarily by removing mate-file-manager-open-terminal and mate-file-manager

First off - thanks for your efforts with this Chess.

I did a git clone, ran base/mate-build-base.sh and it fell over when it got to gtk-engines with "
You must have automake 1.7.x installed to compile".

So I replaced ./autogen.sh in the SlackBuild with ./configure and it got through the configure process and built. I realise this is probably not as robust but I'm curious to see what Mate looks like.

I am building on slackware64-current (March 20) BTW.

The rest of base and extra was uneventful. I pushed my luck and went into testing as well, and I have a few comments:

(1) mate-screensaver - the SlackBuild needed the old -L/usr/lib64 trick in

Code:

elif [ "$ARCH" = "x86_64" ]; then

  SLKCFLAGS="-O2 -fPIC -L/usr/lib64"

  LIBDIRSUFFIX="64"

(2) mate-system-monitor required me to first install libgtop.
(3) mate-text-editor required me to first install gtksourceview.

Just logged out of KDE and logged into Mate desktop without rebooting and everything seems to be working.

I spoke too soon. When I launch mate-terminal I get this:

Code:

fskmh@workstation:~> mate-terminal 



(mate-terminal:3356): GLib-GIO-ERROR **: Settings schema 'org.gnome.system.proxy.http' does not contain a key named 'use-http-proxy'

Trace/breakpoint trap

I am explicitly using a proxy (Squid). If I go into "Control Center" and then "Network Proxy" and change to "Direct internet connection", mate-terminal launches fine. Perhaps this is an upstream problem though, because there is no matching key in that schema:

Code:

fskmh@workstation:~> gsettings list-keys org.gnome.system.proxy.http

authentication-password

authentication-user

enabled

host

port

use-authentication

Tried the following and I can confirm that it does not work:

Code:

fskmh@workstation:~> gconftool-2 --set /system/http_proxy/use_http_proxy --type bool true

fskmh@workstation:~> gsettings set org.gnome.system.proxy.http host '127.0.0.1'

fskmh@workstation:~> gsettings set org.gnome.system.proxy.http port 3128      

fskmh@workstation:~> gsettings set org.gnome.system.proxy mode 'manual'

I suspect that something has to be recompiled with this key enabled.

Quote:

Originally Posted by fskmh (Post 4917068)

First off - thanks for your efforts with this Chess.

Thanks for testing!

Quote:

I did a git clone, ran base/mate-build-base.sh and it fell over when it got to gtk-engines with "
You must have automake 1.7.x installed to compile".

Yes, I have to assume that folks are building on a full install but thanks for letting me know how to proceed without automake.

Quote:

The rest of base and extra was uneventful. I pushed my luck and went into testing as well, and I have a few comments:

(1) mate-screensaver - the SlackBuild needed the old -L/usr/lib64 trick in

Code:

elif [ "$ARCH" = "x86_64" ]; then

  SLKCFLAGS="-O2 -fPIC -L/usr/lib64"

  LIBDIRSUFFIX="64"

Hmm, thanks - I'll check into this.

Quote:

(2) mate-system-monitor required me to first install libgtop.
(3) mate-text-editor required me to first install gtksourceview.

Yes, those dependencies should already be listed in the READMEs. The stuff in /testing, BTW, is not supported -- that's why they are in /testing. :-) I might add those deps or might not.

Quote:

Just logged out of KDE and logged into Mate desktop without rebooting and everything seems to be working.

I spoke too soon. When I launch mate-terminal I get this:

Code:

fskmh@workstation:~> mate-terminal 



(mate-terminal:3356): GLib-GIO-ERROR **: Settings schema 'org.gnome.system.proxy.http' does not contain a key named 'use-http-proxy'

Trace/breakpoint trap

Code:

fskmh@workstation:~> gsettings list-keys org.gnome.system.proxy.http

authentication-password

authentication-user

enabled

host

port

use-authentication

Tried the following and I can confirm that it does not work:

Code:

fskmh@workstation:~> gconftool-2 --set /system/http_proxy/use_http_proxy --type bool true

fskmh@workstation:~> gsettings set org.gnome.system.proxy.http host '127.0.0.1'

fskmh@workstation:~> gsettings set org.gnome.system.proxy.http port 3128      

fskmh@workstation:~> gsettings set org.gnome.system.proxy mode 'manual'

I suspect that something has to be recompiled with this key enabled.

Hmm, I have not seen these issues at all and I've now installed this on three separate systems, one running 64 bit current, but then again I don't use squid. Thanks for letting me about the fix in this particular use case.

I appreciate the testing and feedback!

i can confirm that everything is working well on Slackware64-Current with only base packages installed (no extra and testing)
now testing in another Slackware-Current machine with only base package installed

if it's proven to be OK, then i guess one of the modules in extra/testing caused the problem i had with file-manager in base

Quote:

Originally Posted by fskmh (Post 4917068)

F
(1) mate-screensaver - the SlackBuild needed the old -L/usr/lib64 trick in

Code:

elif [ "$ARCH" = "x86_64" ]; then

  SLKCFLAGS="-O2 -fPIC -L/usr/lib64"

  LIBDIRSUFFIX="64"

Following up on this -- mate-screensaver built and installed fine on my slackware64-14.0 and slackware64-current systems and chroots without this change and I see that mate-screensaver.pc was correctly installed into /usr/lib64, so not sure why we would need to add this. What happened on your system when you tried to build it?

Here is what I get after running the build script in an "su -l" environment (without the -L/usr/lib64 kludge):

Code:

..

..

make[3]: Entering directory `/tmp/msb/mate-screensaver-1.5.2/src'

  CCLD    mate-screensaver-gl-helper

/usr/lib64/gcc/x86_64-slackware-linux/4.7.2/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/X11R6/lib/libbz2.so when searching for -lbz2

/usr/lib64/gcc/x86_64-slackware-linux/4.7.2/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/X11R6/lib/libbz2.a when searching for -lbz2

/usr/lib64/gcc/x86_64-slackware-linux/4.7.2/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/X11R6/lib/libz.so when searching for -lz

/usr/lib64/gcc/x86_64-slackware-linux/4.7.2/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/X11R6/lib/libz.a when searching for -lz

/usr/lib64/gcc/x86_64-slackware-linux/4.7.2/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/X11R6/lib/libresolv.so when searching for -lresolv

/usr/lib64/gcc/x86_64-slackware-linux/4.7.2/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/X11R6/lib/libresolv.a when searching for -lresolv

/usr/lib64/gcc/x86_64-slackware-linux/4.7.2/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/X11R6/lib/libpthread.so when searching for -lpthread

/usr/lib64/gcc/x86_64-slackware-linux/4.7.2/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/X11R6/lib/libpthread.a when searching for -lpthread

/usr/lib64/gcc/x86_64-slackware-linux/4.7.2/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/X11R6/lib/librt.so when searching for -lrt

/usr/lib64/gcc/x86_64-slackware-linux/4.7.2/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/X11R6/lib/librt.a when searching for -lrt

/usr/lib/libXext.so: could not read symbols: File in wrong format

collect2: error: ld returned 1 exit status

make[3]: *** [mate-screensaver-gl-helper] Error 1

make[3]: Leaving directory `/tmp/msb/mate-screensaver-1.5.2/src'

make[2]: *** [all] Error 2

make[2]: Leaving directory `/tmp/msb/mate-screensaver-1.5.2/src'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/tmp/msb/mate-screensaver-1.5.2'

make: *** [all] Error 2

I have experienced the linker trying link a 32 bit library with the odd package I have compiled in the past so I usually just force it to use /usr/lib64 without batting an eyelid.

I must confess - this is on slack64-current with a truckload of extra packages (mostly from SBo).

P.S. I have updated the following packages in the meantime:
mate-calc-1.5.2
mate-control-center-1.5.5
mate-desktop-1.5.8
mate-icon-theme-faenza-1.5.1
mate-keyring-1.5.1
mate-media-1.5.2
mate-settings-daemon-1.5.7
mate-terminal-1.5.1
mate-themes-1.5.1
mate-window-manager-1.5.5

These I added myself:
mate-file-manager-gksu-1.5.0
mate-bluetooth-1.5.1
mate-sensors-applet-1.5.2
mate-netspeed-1.5.2

I've been using this desktop for most of the afternoon and nothing's fallen over so far. Pulseaudio also seems to work the same as it does in KDE.

Quote:

Originally Posted by fskmh (Post 4917340)

I have experienced the linker trying link a 32 bit library with the odd package I have compiled in the past so I usually just force it to use /usr/lib64 without batting an eyelid.

this is because you are using a multilib environment, that usually is not supported by *.SlackBuild scripts.

Ah, thanks ponce - I suspected as much.

Just experienced the same issue willysr mentioned in #31. I tailed ~/.xsession-errors and got a bunch of these:

Code:

** Message: Initializing gksu extension...

Initializing caja-open-terminal extension

The program 'caja' received an X Window System error.

This probably reflects a bug in the program.

The error was 'BadDrawable (invalid Pixmap or Window parameter)'.

  (Details: serial 7 error_code 9 request_code 53 minor_code 0)

  (Note to programmers: normally, X errors are reported asynchronously;

  that is, you will receive the error a while after causing it.

  To debug your program, run it with the --sync command line

  option to change this behavior. You can then get a meaningful

  backtrace from your debugger if you break on the gdk_x_error() function.)

While I was fiddling around looking for more details it stopped by itself after about a minute. Looks like it stopped because X reached its limit on the number of client connections.

P.S. I am using runlevel 4 + KDM.

Try removing the mate-file-manager-open-terminal package and see if that helps. Willysr removed it and the problem cleared up apparently

I can't reproduce it here -- the file manager and the open-terminal extension work fine.

Quote:

Originally Posted by chess (Post 4917443)

That was the first thing I tried - didn't help.
Tried disabling compositing as well, but that didn't help either.

What did help was editing /usr/share/applications/caja.desktop and changing "Exec=caja" to "Exec=caja --sync".