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.
- Remote content did not load in user-defined signatures
- Addons that added new action buttons were not shown for addon upgrades, requiring removal and reinstall
- Various stability improvements
- Security fix
Overview of changes in GLib 2.74.4
==================================
* Fix missing input validation in `GDBusMenuModel` (work by Lars Uebernickel) (#861)
* Various GVariant security fixes when handling untrusted data (work by
William Manley, Philip Withnall, Simon McVittie) (#2121, #2540, #2794, #2797,
#2839, #2840, #2841)
* Bugs fixed:
- #861 insufficient input validation in GDBusMenuModel (Lars Uebernickel)
- #2121 GVariant deserialisation does not match spec for non-normal data
(William Manley, Philip Withnall)
- #2540 Parsing serialized GVariants can blow up run-time and memory (Philip
Withnall)
- #2794 GVariant offset table entry size is not checked in is_normal() (Philip
Withnall)
- #2797 g_variant_byteswap() can take a long time with some non-normal inputs
(Philip Withnall)
- #2835 gio/gapplication test fails with test_dbus_activate: assertion failed
(n_activations == 2): (1 == 2) (Philip Withnall)
- #2839 [bisected] GVariant test regression on big-endian architectures (Simon
McVittie)
- #2840 fuzz_variant_binary_byteswap: Heap-buffer-overflow in
g_variant_serialised_get_child (Philip Withnall)
- #2841 fuzz_variant_text: Timeout in fuzz_variant_text (Philip Withnall)
- #2852 alpine/musl: catching signals from a subprocess triggers
GLib:ERROR:../glib/gmain.c:5569:siginfo_t_to_wait_status: code should not be
reached (Philip Withnall)
- !3114 Backport !3113 “gaction: Validate actions activated over D-Bus” to
glib-2-74
- !3126 Backport !3125 “Various fixes to normal form handling in GVariant” to
glib-2-74
- !3134 Backport !3133 “gmenumodel: disallow exporting large menus on the bus”
to glib-2-74
- !3138 Backport !3136 “gvariant-serialiser: Convert endianness of offsets” to
glib-2-74
- !3153 Backport !3120 “glib/gthread-posix: Conditionally use `futex` and/or
`futex_time64` syscalls...” to glib-2-74
- !3161 Backport !3158 ”gmain: Define fallback values for siginfo_t constants
for musl” to glib-2-74
- !3164 Backport !3163 “gvariant: Check offset table doesn’t fall outside
variant bounds and speed up text parsing” to glib-2-74
extras/sendmail also needs to be rebuilt to be linked with l/icu4c-72.1. If one has applied any -current updates since Dec 17 2022 when the temporary icu4c-71.1 libs were removed off a/aaa_libraries, it will continue to work until restarted.
Code:
# /etc/rc.d/rc.sendmail restart
Starting sendmail MTA daemon: /usr/sbin/sendmail -L sm-mta -bd -q25m
/usr/sbin/sendmail: error while loading shared libraries: libicuuc.so.71: cannot open shared object file: No such file or directory
Starting sendmail MSP queue runner: /usr/sbin/sendmail -L sm-msp-queue -Ac -q25m
/usr/sbin/sendmail: error while loading shared libraries: libicuuc.so.71: cannot open shared object file: No such file or directory
# _
Can we also start looking at upgrading OpenSSL to the more modern v3.0? For the record, v1.1.1 support will end in September 2023. From https://www.openssl.org/source/:
Quote:
Note: The latest stable version is the 3.0 series supported until 7th September 2026. This is also a Long Term Support (LTS) version. The previous LTS version (the 1.1.1 series) is also available and is supported until 11th September 2023. All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of support and should not be used. Users of these older versions are encouraged to upgrade to 3.0 as soon as possible. Extended support for 1.0.2 to gain access to security fixes for that version is available.
I for one, I started to believe that naming the development tree of Slackware as "current" is misleading for the beginner users of Slackware.
So, my proposal is to rename the tree of slackware-current to slackware-development or slackware-devel or slackware-testing or whatever else name associated with its true development stage.
Let's acknowledge that "current" had a different meaning 30 years ago, but that today it just generate confusion.
Last edited by LuckyCyborg; 12-24-2022 at 07:27 AM.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,199
Rep:
No real need, in my opinion, to change the name of -current. Those who seem to not understand -current is the development branch will get just as "confused" regardless of whatever name is used.
I for one, I started to believe that naming the development tree of Slackware as "current" is misleading for the beginner users of Slackware.
So, my proposal is to rename the tree of slackware-current to slackware-development or slackware-devel or slackware-testing or whatever else name associated with its true development stage.
Let's acknowledge that "current" had a different meaning 30 years ago, but that today it just generate confusion.
I thought that this thread was a place to request updates to programs that are already included in Slackware and maybe request a program or library that isn't included. Please tell me if I am wrong.
No real need, in my opinion, to change the name of -current. Those who seem to not understand -current is the development branch will get just as "confused" regardless of whatever name is used.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
