Take a look if it helps
https://www.linuxquestions.org/quest...ghlight=geeqie

Amazing what search will do for you.

https://www.linuxquestions.org/quest...ie-4175690033/

Hi,

9P can be used when installing Slackware in libvirt/QEMU.
So, it the case 9P becomes modularized, please add the modules to installer's initrd.

--
Best regards,
Andrzej Telszewski

The latest glib2 upgrade in -current (2.66.7) has solved this - at least on my machine.

1 members found this post helpful.

tar-1.34

https://ftp.gnu.org/gnu/tar/tar-1.34.tar.xz

1 members found this post helpful.

That did not help here, I already had that installed.

Paulo2's link to chrisretusn's post solved the problem.

Thank you!!

Odd.
You mentioned in your previous post that you have issues when trying to open an image file from Dolphin. I don't have Dolphin installed, but no problems open image files from Thunar, Caja or SpaceFM. Could it be KDE specific?

No, there's a problem if using XFCE as well

https://www.linuxquestions.org/quest...3/#post6217362

Yes, there was a problem, but as already mentioned in that thread it's gone for me (and others) after upgrading to glib2-2.66.7

I'll see if the new rebuild (including the other 1546 updates/rebuilds) will solve the problem
l/glib2-2.66.7-x86_64-2.txz: Rebuilt.

Current ChangeLog...

"Mon Feb 15 19:23:44 UTC 2021
Here we go again... upgraded to glibc-2.33 and one last mass rebuild for
Slackware 15.0. The only packages upgraded in this batch are glibc and the
kernels - everything else is just a rebuild against the new glibc. Not
rebuilt in this batch: devs (best to just leave this alone), glibc-zoneinfo,
kernel-firmware, rust, linux-faqs, linux-howtos, aspell-en, mozilla-firefox,
mozilla-thunderbird, and seamonkey. There's a new Rust compiler but Firefox
and Thunderbird will need to be patched to use it, so we'll hold off on
those until they're ready for the new Rust either with patches or new
upstream releases. Until we have that and a few more scheduled upgrades I'm
not quite ready to call this beta yet, but you can call it 15.0-alpha1. :-)
Cheers!"

2 members found this post helpful.

So took the plunge and did the mammoth upgrade on 32bit

The earlier problem still exists

rsync: [receiver] failed to set permissions on "/home/nl/.gimp-2.8/.menurc.i5gqnS" (in roswell): Operation not supported (95)
rsync: [receiver] failed to set permissions on "/home/nl/.gimp-2.8/.tags.xml.TR0Nm1" (in roswell): Operation not supported (95)
rsync: [receiver] failed to set permissions on "/home/nl/.gimp-2.8/.themerc.Vp5SE9" (in roswell): Operation not supported (95)
rsync: [receiver] failed to set permissions on "/home/nl/.kde/share/apps/krdc/.bookmarks.xml.Ka48Oo" (in roswell): Operation not supported (95)
rsync: [receiver] failed to set permissions on "/home/nl/.kde/share/apps/krdc/.bookmarks.xml.bak.JHXU8h" (in roswell): Operation not supported (95)
rsync: [receiver] failed to set permissions on "/home/nl/.kde/share/apps/krdc/.bookmarks.xml.tbcache.YSfzA1" (in roswell): Operation not supported (95)


root@dev:/usr/bin# mv rsync rsync.bad
root@dev:/usr/bin# cp rsync.good rsync

rerun rsync
completes no error

again, the rsync.good is a copy before the first rebuilds back in January this year.

So all the same version, just different builds


The same problem with mariadb

2021-02-16 17:19:53 0 [Note] InnoDB: Using Linux native AIO
2021-02-16 17:19:53 0 [Note] InnoDB: Uses event mutexes
2021-02-16 17:19:53 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2021-02-16 17:19:53 0 [Note] InnoDB: Number of pools: 1
2021-02-16 17:19:53 0 [Note] InnoDB: Using generic crc32 instructions
2021-02-16 17:19:53 0 [Note] mariadbd: O_TMPFILE is not supported on /tmp (disabling future attempts)
2021-02-16 17:19:53 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728
2021-02-16 17:19:53 0 [Note] InnoDB: Completed initialization of buffer pool
2021-02-16 17:19:53 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
210216 17:19:53 [ERROR] mysqld got signal 4 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.5.8-MariaDB-log
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466473 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x49000
??:0(my_print_stacktrace)[0x12418fe]
??:0(handle_fatal_signal)[0xba6992]
addr2line: 'linux-gate.so.1': No such file
linux-gate.so.1(__kernel_sigreturn+0x0)[0xb7ef5554]
??:0(my_dlerror)[0x125c180]
??:0(std::unique_lock<std::mutex>::unlock())[0x10f0e3c]
??:0(std::unique_lock<std::mutex>::unlock())[0x10e641f]
??:0(std::unique_lock<std::mutex>::unlock())[0x11686d3]
??:0(std::unique_lock<std::mutex>::unlock())[0x116c588]
??:0(std::unique_lock<std::mutex>::unlock())[0x116cb87]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x7c8f98]
??:0(wsrep_notify_status(wsrep::server_state::state, wsrep::view const*))[0xf55bdc]
??:0(ha_initialize_handlerton(st_plugin_int*))[0xba9b2d]
??:0(sys_var_pluginvar::sys_var_pluginvar(sys_var_chain*, char const*, st_plugin_int*, st_mysql_sys_var*))[0x94d0cc]
??:0(plugin_init(int*, char**, int))[0x94e7da]
??:0(unireg_abort)[0x84a56c]
??:0(mysqld_main(int, char**))[0x850b35]
??:0(main)[0x80d467]
??:0(__libc_start_main)[0xb758c889]
??:0(_start)[0x843811]
The manual page at https://mariadb.com/kb/en/how-to-pro...ce-for-mysqld/ contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /var/lib/mysql
Resource Limits:
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 15947 15947 processes
Max open files 32184 32184 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 15947 15947 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
Core pattern: core

despite what mariadb says, there is no core file

Also, last mass rebuild copy over mariadb binary and it worked, this rebuild it flat out refuses

*sigh*

2021-02-14: sane-backends-1.0.32 has been released.
https://gitlab.com/sane-project/back...eleases/1.0.32

To be honest this seems to me more of a configuration issue.

cmake 3.19.5
https://cmake.org/download/

1 members found this post helpful.

how so?

The config has not been touched, it worked since -current was installed UNTIL Pats rebuilds in January which kept the same configs, even the same versions of rsync and mariadb, just Pat has rebuilt them and that rebuild broke them.

ldd shows nothing missing a check of ldd agaisnt the shared objects shows nothing missing.
unless you are using 32bit and Pats mariadb and rsync, you not replicating the same dev space I am that sees the error