SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I just enabled an rsync daemon on a 32bit system here. Server side:
Code:
root@test32:~# cat /etc/rsyncd.conf
uid = nobody
gid = nobody
port = 873
use chroot = no
max connections = 64
pid file = /var/run/rsyncd.pid
[pub]
path = /home/ftp/pub
read only = yes
exclude = .*
dont compress = *
From 64 bit client:
Code:
[rworkman@dev64 ~]$ rsync -av rsync://test32/pub/SlackBook/ SlackBook/
receiving incremental file list
created directory SlackBook
./
slackbook-2.0-docbook.tar.gz
slackbook-2.0.pdf
slackbook-2.0.ps
sent 84 bytes received 6,626,386 bytes 13,252,940.00 bytes/sec
total size is 6,624,520 speedup is 1.00
If you mean that the 32bit client is not working, then:
Code:
rworkman@test32:~$ rsync -av rsync://nas/pub/source/pithos/ pithos/
receiving incremental file list
created directory pithos
./
README
doinst.sh
pithos-1.5.0.tar.xz
pithos.SlackBuild
pithos.info
slack-desc
contrib/
contrib/pithosctl
sent 172 bytes received 108,293 bytes 216,930.00 bytes/sec
total size is 107,662 speedup is 0.99
In short, I don't see how to reproduce the rsync problem here :/
Distribution: Slackware64 14.2 and current, SlackwareARM current
Posts: 1,647
Rep:
Quote:
Originally Posted by Didier Spaier
Actually there is an issue with the last rsync package in Slackware64-current. I came across it as the Slint repositories are hosted c/o https://slackware.uk which runs Slackware64-current in a VM and I had this issue there when tryng to rsync. I tchat-ed about that with Tadgy and he ended up reverting to the previous rsync package (that he also hosts in /cumulative) which indeed solved the issue.
PS What happened is that most if not all files where chmod-ed 0600 by the rsync server.
Distribution: Slackware64 14.2 and current, SlackwareARM current
Posts: 1,647
Rep:
Quote:
Originally Posted by Ressy
The likely cause is GLIBC now uses lchmod() and that is causing a lot of problems in multi distros
I am awating wordback on its the cause in mariadb as well.
like I said, this shit only started when Pat upgraded GLIBC
and as for you asking to check the source as to why rsync is changing perms ? W T F .. this shows you don't understand the program at all, so I'm done here with you, you are unable to contribute anything worthwhile.
I have not kept a log of my tchat with Darren aka Tadgy (around midnight UTC last Sunday) but he certainly can give you more information. I would assume he reverted from rsync-3.2.3-x86_64-2 to rsync-3.2.3-x86_64-1 that solved the issue here.
On the rsync issue, I found this Ubuntu bug report the most informative, highlighting the problem in lchmod if /proc is not mounted. It appears that rsync has a patch to work around that behaviour as linked by titopoquito in post #6784.
Added to line 414 of makepkg. This way the packages built with makepkg --xattrs will have an xattr set, called 'trusted.slackware_v1.package_name', that would contain the package name.
This can be verified by getfattr -d -m - /usr/bin/application_name
This incurs almost no performance penalty on package creation (I tagged 25Gb of files in 1 minute, and the largest Slackware package is way smaller), and would let everyone know which package the file came from. This is very helpful when unexpected files appear in system directories.
trusted.* means that only someone having a CAP_SYS_ADMIN capability will be able to tamper with them, which is usually what is desirable.
This is by no means a replacement for files in /var/lib/pkgtools/packages/ , rather, this is intended to help finding whether the filesystem has been tampered with.
In particular, if some package ignores DESTDIR, you may not know that when writing a slackbuild. Then, untagged files will be likely coming from this package .
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,167
Rep:
Quote:
Originally Posted by Didier Spaier
I reaaly like Plasma 5 in -current
Thanks and kudos to Eric and Patrick for this. I really hope that 5.4.21 will make its way in -current (5.21.0 expected next Tuesday 16 February 2021).
As compared to kde4, what do you think is an improvement?
How is it technically superior to kde4?
Merci Beaucoup.
(Perhaps we can have this discussion in the "All things kde5/plasma" thread?)
Last edited by cwizardone; 02-17-2021 at 08:59 AM.
@cwizardone: I only had a quick look at it so take this a just a first impression. At least Plasma 5 is way lighter on resources, and is probably significantly more accessible to the blind using a screen reader or a Braille display, and it looks overall a lot more modern to me. Put it another way I could probably use it personally every day as a replacement for Mate, which would be out of question for KDE4. Technically I have no idea, as I didn't lift the hood to look at the engine.
Last edited by Didier Spaier; 02-17-2021 at 11:32 AM.
~# plasma-systemmonitor
QIODevice::read (QFile, "/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/cgroup.procs"): device not open
terminate called after throwing an instance of 'std::filesystem::__cxx11::filesystem_error'
what(): filesystem error: directory iterator cannot open directory: No such file or directory [/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service]
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = plasma-systemmonitor path = /usr/bin pid = 10224
KCrash: Arguments: /usr/bin/plasma-systemmonitor
KCrash: Attempting to start /usr/lib64/drkonqi
Unable to start Dr. Konqi
org.kde.drkonqi: The specified process does not exist.
Long story short, looks like this will be fixed on Plasma 5.21.1 but I hope that meantime the patch will be still applied by Slackware, as our plasma-systemmonitor is dead on arrival.
Last edited by LuckyCyborg; 02-17-2021 at 10:47 AM.
As compared to kde4, what do you think is an improvement?
How is it technically superior to kde4?
Merci Beaucoup.
(Perhaps we can have this discussion in the "All things kde5/plasma" thread?)
Stop it! You've tried starting this discussion many times. Many people have explained why they like Plasma5 more than KDE4, including technical reasons.
However, simply put, KDE4 is EOL. It doesn't belong in an up-to-date distro. It doesn't matter what your personal preferences are, Slackware is moving on. If you really want KDE4, stick with the project that was keeping it alive for -current (if it's still doing that, I'm too lazy to check).
In addition to bug fixes and feature improvements, these particular maintenance
releases also contain the fix for a vulnerability, CVE-2020-8625, about which more
information is provided in this Security Advisory:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
