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.
Sat Oct 16 18:12:37 UTC 2021
ap/pamixer-1.5-x86_64-1.txz: Upgraded.
l/librsvg-2.52.2-x86_64-1.txz: Upgraded.
l/liburing-2.1-x86_64-2.txz: Rebuilt.
Don't package the examples.
l/spirv-llvm-translator-13.0.0-x86_64-1.txz: Upgraded.
Mon Oct 18 18:40:47 UTC 2021
a/kernel-firmware-20211018_d34196f-noarch-1.txz: Upgraded.
ap/hplip-3.20.5-x86_64-5.txz: Rebuilt.
Applied patch to fix hp-scan when using Python 3.10. Thanks to kingbeowulf.
ap/mpg123-1.29.1-x86_64-1.txz: Upgraded.
kde/plasma-workspace-5.23.0-x86_64-3.txz: Rebuilt.
[PATCH] Revert "No icons on the desktop by default". Thanks to LuckyCyborg.
9 updates. Including a (* Security fix *)! : 8 upgraded, 1 rebuilt
Code:
Thu Oct 21 19:36:32 UTC 2021
a/lvm2-2.03.13-x86_64-1.txz: Upgraded.
Reverted to working version.
d/rust-1.56.0-x86_64-1.txz: Upgraded.
l/pipewire-0.3.39-x86_64-1.txz: Upgraded.
n/krb5-1.19.2-x86_64-2.txz: Rebuilt.
[PATCH] Fix KDC null deref on TGS inner body null server.
This fixes an issue where an authenticated attacker can cause a denial of
service in the KDC by sending a FAST TGS request with no server field.
Thanks to nobodino.
For more information, see:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-37750
(* Security fix *)
x/ibus-m17n-1.4.8-x86_64-1.txz: Upgraded.
x/libinput-1.19.2-x86_64-1.txz: Upgraded.
xap/freerdp-2.4.1-x86_64-1.txz: Upgraded.
This update fixes two security issues:
Improper client input validation for gateway connections allows to overwrite
memory.
Improper region checks in all clients allow out of bound write to memory.
For more information, see:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41159
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41160
(* Security fix *)
xap/gftp-2.7.1b-x86_64-1.txz: Upgraded.
extra/php8/php8-8.0.12-x86_64-1.txz: Upgraded.
This update fixes bugs and a security issue:
FPM: PHP-FPM oob R/W in root process leading to privilege escalation.
For more information, see:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21703
(* Security fix *)
17 updates. Including a (* Security fix *)! : 11 upgraded, 6 rebuilt
Code:
Sat Oct 23 18:57:30 UTC 2021
a/aaa_terminfo-6.3-x86_64-1.txz: Upgraded.
a/glibc-zoneinfo-2021e-noarch-1.txz: Upgraded.
ap/itstool-2.0.7-x86_64-2.txz: Rebuilt.
Rebuilt with PYTHON=/usr/bin/python3. Thanks to USUARIONUEVO.
ap/mpg123-1.29.2-x86_64-1.txz: Upgraded.
d/meson-0.59.3-x86_64-1.txz: Upgraded.
d/parallel-20211022-noarch-1.txz: Upgraded.
d/python-pip-21.3.1-x86_64-1.txz: Upgraded.
d/python-setuptools-58.3.0-x86_64-1.txz: Upgraded.
l/exiv2-0.27.5-x86_64-1.txz: Upgraded.
l/ncurses-6.3-x86_64-1.txz: Upgraded.
n/php-7.4.25-x86_64-1.txz: Upgraded.
This update fixes bugs and a security issue:
FPM: PHP-FPM oob R/W in root process leading to privilege escalation.
For more information, see:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21703
(* Security fix *)
xap/mozilla-thunderbird-91.2.1-x86_64-1.txz: Upgraded.
This is a bugfix release.
For more information, see:
https://www.mozilla.org/en-US/thunderbird/91.2.1/releasenotes/
testing/packages/linux-5.14.x/kernel-generic-5.14.14-x86_64-2.txz: Rebuilt.
testing/packages/linux-5.14.x/kernel-headers-5.14.14-x86-2.txz: Rebuilt.
testing/packages/linux-5.14.x/kernel-huge-5.14.14-x86_64-2.txz: Rebuilt.
testing/packages/linux-5.14.x/kernel-modules-5.14.14-x86_64-2.txz: Rebuilt.
testing/packages/linux-5.14.x/kernel-source-5.14.14-noarch-2.txz: Rebuilt.
These kernels enable CONFIG_PREEMPT=y and CONFIG_PREEMPT_DYNAMIC=y allowing
the kernel preemption model to be specified on the kernel command line
with one of these options: preempt=none, preempt=voluntary, and preempt=full.
Since there is no .config option to set a default, and the default in the
kernel sources is "full" (which is probably not a good default), the
kernel-source.SlackBuild has been modified to add support for an environment
variable CONFIG_PREEMPT_DEFAULT_MODE which can be set to none, voluntary, or
full to set the default kernel preemption model when a command line option
is not provided. These kernels have been built with a preemption model of
"none" (presumably the safest choice which will behave like the kernels we
have shipped before.) The runtime overhead on 64-bit should be negligible.
On 32-bit we lack support for HAVE_STATIC_CALL_INLINE, so spinlocks and
mutexes will have to be approached through a trampoline, adding a very small
amount of overhead. I feel this is probably worth it in order to have the
option to run a kernel with voluntary or full preemption, especially for
gaming or desktop purposes. The reduction in input lag with these modes is
actually quite noticable.
To check the current preemption model, you may use debugfs:
mount -t debugfs none /sys/kernel/debug
cat /sys/kernel/debug/sched/preempt
(none) voluntary full
You may change to a different preemption model on the fly once debugfs is
mounted:
echo voluntary > /sys/kernel/debug/sched/preempt
cat /sys/kernel/debug/sched/preempt
none (voluntary) full
Thanks to Daedra.
-DRM_I810 n
-INLINE_READ_UNLOCK y
-INLINE_READ_UNLOCK_IRQ y
-INLINE_SPIN_UNLOCK_IRQ y
-INLINE_WRITE_UNLOCK y
-INLINE_WRITE_UNLOCK_IRQ y
PREEMPT n -> y
PREEMPT_VOLUNTARY y -> n
+CEC_GPIO n
+DEBUG_PREEMPT y
+PREEMPTION y
+PREEMPT_COUNT y
+PREEMPT_DYNAMIC y
+PREEMPT_RCU y
+PREEMPT_TRACER n
+RCU_BOOST n
+TASKS_RCU y
+UNINLINE_SPIN_UNLOCK y
Mon Oct 25 19:30:42 UTC 2021
ap/slackpkg-15.0.8-noarch-1.txz: Upgraded.
Author: piterpunk <piterpunk@slackware.com>
To make it easier to do an unattended slackpkg update/upgrade process,
this commit provides different exit codes for many situations:
0 Successful slackpkg execution.
1 Something wrong happened.
20 No package found to be downloaded, installed, reinstalled,
upgraded, or removed.
50 Slackpkg itself was upgraded and you need to re-run it.
100 There are pending updates.
Code and the main manpage are updated accordingly.
In addition, this commit also:
- removes the ChangeLog.txt in doinst.sh, so the needed
'slackpkg update' after Slackpkg upgrade won't say it's all OK
and doesn't need to redo the package lists
- removes AUTHORS from manpage. Nowadays there is code from many
people in Slackpkg and it seems a bit unfair to have only my and
Evaldo's name listed there.
Signed-off-by: Robby Workman <rworkman@slackware.com>
d/meson-0.60.0-x86_64-1.txz: Upgraded.
l/ffmpeg-4.4.1-x86_64-1.txz: Upgraded.
l/imagemagick-7.1.0_11-x86_64-1.txz: Upgraded.
l/libcap-2.60-x86_64-1.txz: Upgraded.
l/libsoup-2.74.1-x86_64-1.txz: Upgraded.
l/sip-4.19.25-x86_64-3.txz: Rebuilt.
Drop the Qt4 modules. Thanks to gmgf.
n/dhcpcd-9.4.1-x86_64-1.txz: Upgraded.
testing/packages/linux-5.14.x/kernel-generic-5.14.14-x86_64-3.txz: Rebuilt.
testing/packages/linux-5.14.x/kernel-headers-5.14.14-x86-3.txz: Rebuilt.
testing/packages/linux-5.14.x/kernel-huge-5.14.14-x86_64-3.txz: Rebuilt.
testing/packages/linux-5.14.x/kernel-modules-5.14.14-x86_64-3.txz: Rebuilt.
testing/packages/linux-5.14.x/kernel-source-5.14.14-noarch-3.txz: Rebuilt.
Let's enable SCHED_AUTOGROUP, which should improve desktop latency under a
heavy CPU load while being mostly inert on servers. It may be disabled at
boot time with a "noautogroup" kernel parameter, or at runtime like this:
echo 0 > /proc/sys/kernel/sched_autogroup_enabled
Thanks to gbschenkel.
SCHED_AUTOGROUP n -> y
testing/packages/linux-5.14.x/kernel-source-5.14.14-noarch-3.txz: Rebuilt.[/COLOR]
Let's enable SCHED_AUTOGROUP, which should improve desktop latency under a
heavy CPU load while being mostly inert on servers. It may be disabled at
boot time with a "noautogroup" kernel parameter, or at runtime like this:
echo 0 > /proc/sys/kernel/sched_autogroup_enabled
Thanks to gbschenkel.
SCHED_AUTOGROUP n -> y
A word of warning on this one. Old-school techniques like "nice 19" will no longer work with SCHED_AUTOGROUP enabled because nice values only work within the scope of their processes' cgroup; so, if you pop open a terminal for a compile job and do "nice 19 make" it won't have any effect as that will be the only process in that terminal's session/control group.
Also, I believe changing /proc/sys/kernel/sched_autogroup will only affect anything that starts afterwards, any processes already running will have already been separated into their own autogroup, so if you don't want this feature, best to disable it with the kernel boot parameter: which is what I'll be doing (when using Pat's generic kernel).
P.S. I tried AUTOGROUP when it was first introduced to the kernel and I found that judicious use of nice did a much better job of maintaining responsiveness.
Mon Oct 25 19:30:42 UTC 2021
ap/slackpkg-15.0.8-noarch-1.txz: Upgraded.
This seems to have broken slackpkg for me using -current. I didn't think to save my old mirror file, but it's now looking for slackware64-15.0 folders that don't exist.
This seems to have broken slackpkg for me using -current. I didn't think to save my old mirror file, but it's now looking for slackware64-15.0 folders that don't exist.
Sorry for your loss, BUT I hope that you would agree that the software from Slackware -current should align somehow to future Slackware 15.0, right?
A word of warning on this one. Old-school techniques like "nice 19" will no longer work with SCHED_AUTOGROUP enabled because nice values only work within the scope of their processes' cgroup; so, if you pop open a terminal for a compile job and do "nice 19 make" it won't have any effect as that will be the only process in that terminal's session/control group.
Also, I believe changing /proc/sys/kernel/sched_autogroup will only affect anything that starts afterwards, any processes already running will have already been separated into their own autogroup, so if you don't want this feature, best to disable it with the kernel boot parameter: which is what I'll be doing (when using Pat's generic kernel).
P.S. I tried AUTOGROUP when it was first introduced to the kernel and I found that judicious use of nice did a much better job of maintaining responsiveness.
When even Mr. Lennart Poettering, who everybody knows that he has a little (inoffensive?) mania for shinny CGROUPS, so... when even him argues that this kernel feature is eventually useful only for building all day along kernels on a console, while watching movies on a second console, I for one I'm kinda disappointed of the collateral effects like nuking those "nice" things.
On Tue, 16.11.10 10:49, Linus Torvalds (torvalds@linux-foundation.org) wrote:
> Because it's something we want to do it for all users, and for all
> shells, and make sure it gets done automatically. Including for users
> that have old distributions etc, and make it easy to do in one place.
> And then you do it for all the other heuristics we can see easily in
> the kernel. And then you do it magically without users even having to
> _notice_.
Well, this feature is pretty much interesting only for kernel hackers
anyway. It is completely irrelevant for normal desktop people. Because
a) normal users don't use many terminals anyway and that very seldom and
b) if they do that they do not create gazillion of processes from one of
the terminals and only very few in the other. Because only then this
patch becomes relevant.
Heck, the patch wouldn't even have any effect on my machine (and I am
hacker), because I tend to run my builds from within emacs. And since
emacs has no TTY (since it is a X11/gtk build) it wouldn't be in its own
scheduling group.
So, this patch only has an effect of people who build kernels from an
xterm with make -j all day, and at the same time want to watch a movie,
from a player they also start from a terminal, but from another one.
Only in such a setup this patch matters. And for everybody else it is
completely irrelevant. If you don't use terminals it has no effect. If
you don't run massivily parallel CPU hoggers it has no effect. If you do
not run your mplayer from a terminal it has no effect.
The kernel bears your name, but that doesn't mean your own use of it was
typical for more than you and a number kernel hackers like you.
Also, this implicit assumption that nobody would ever see this because
people upgrade their kernels often and userspace seldom is just nonsense
anyway. That's how *you* do it. But in reality userspace is updated for
most folks way more often then the kernel is.
Or to turn this around: think how awesome that would be if we did this
in userspace, then we could support older kernels too and wouldn't have
to upgrade everything to your not-yet-released new kernel.
Suddenly it doesn't seem that wonderful anymore to play with the kernel
to add this, does it?
> Suddenly it doesn't seem that wonderful any more to play with bashrc,
> does it?
Well, I have no plans in pushing anybody to do this in bash really. All
I am saying that tying this to a tty is crazy. And this is policy, and
should be done in userspace, and we are almost there to do this in
userspace.
In fact, I just prepped a patch to systemd to move every service and
every user session into its own cgroup in the 'cpu' hierarchy (in
addition to the group it already creates in the 'systemd' hierarchy). On
a system that runs systemd for both managing users and sessions this
means you are already half-way at what you want.
> User-level configuration for something that should just work is
> annoying. We can do better.
Well, that says you, as a kernel hacker. For you it is easier to hack
the kernel than to fiddle with the rest of the stack. Doesn't make it the
right fix. You know, there are a lot of userspace folsk being afraid of
and too lazy to hacking the kernel and hence rather workaround kernel
fuckups in userspace then fixing it properly. But you are doing it the
other way round, since userspace gives you the creeps you want to add
something to the kernel that doesn't really have any value for anybody
but a number of kernel folks, and is policy anyway, and what userspace
people are working on anyway.
> Put another way: if we find a better way to do something, we should
> _not_ say "well, if users want it, they can do this <technical thing
> here>". If it really is a better way to do something, we should just
> do it. Requiring user setup is _not_ a feature.
Well, if I make behaviour like this default in systemd, then this means
there won't be user setup for this. Because the distros shipping systemd
will get this as default behaviour.
Lennart
--
Lennart Poettering - Red Hat, Inc.
Last edited by LuckyCyborg; 10-25-2021 at 05:25 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
