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.
Ok, but my point remains: upstream needs to send clear communication. Apparently one tool is deprecated and the other experimental. Why should Slackware choose a tool marked experimental over one marked deprecated? More concerning is the kernel commit is from 2017 and yet rasdaemon still marks enabling MCE events as experimental. Unless "--enable-mce" means something different than "replace functionality of mcelog", which forgive me if that's not the correct interpretation.
This is the first stable release of the 1.18 series. Users and distributions are strongly encouraged to update to this version. These are the highlights of this release:
Highlights
A new config-based portal matching mechanism that gives more precise control over which portal backends are picked for each portal.
New portals: Clipboard and Input Capture
The settings portal now documents an 'accent-color' key
Other changes
New portal APIs:
Introduce a new Clipboard portal. This portal extends the Remote Desktop portal by adding support for sharing clipboard between remote machines.
Introduce a new Input Capture portal. This portal adds mechanisms for taking control of input devices. The primary usage model is centered around the InputLeap and Synergy use cases, where local devices are used to control remote displays.
Add an "accept-label" option the the Print portal. This lets apps suggest a proper label to the print operation.
Document a new 'accent-color' key in the Settings portal. This key represents an arbitrary color in sRGB colorspace. How implementations of the portal provide this key is entirely dependent on their internal policies and design.
Support restoring remote desktop sessions
Introduce the ReadOne() method in the Settings portal. This method is now preferred over the Read() method, as Read() mistakenly returned a variant inside a variant. The Read() method will continue to exist for compatibility with existing apps, but its usage is deprecated. We recommend apps to port to the ReadOne() method. Apps can decide whether to use ReadOne() or Read() by looking at the version of the Settings portal.
Changes that might be relevant for distributors:
Rework how portal implementations are loaded. This new, more robust system allows selecting specific backends for specific portals, and layering them when necessary. Platforms that provide portals implementation are encouraged to provide a suitable configuration file.
Drop the Autotools build. Meson is now the only supported build system.
The PipeWire dependency is now mandatory
Bump GLib dependency to 2.66
Misc changes:
Improve robustness of the OpenURI portal by validating more URIs
Various small visual tweaks to the generated documentation
Various fixes to the Global Shortcuts portal
Stop using the deprecated GTimeVal struct
Document xdg-desktop-portal versioning scheme
Fix various issues in the OpenURI portal
Bump interface version of the Printer portal to 2
Validate addresses following the HTML specs in the Email portal
Document minimum version of the new ReadOne() method of the Settings portal
Add a mapping id property to the ScreenCast portal
Add activation token parameter to the Email portal
Test tarball generation in CI
Translation updates
Ok, but my point remains: upstream needs to send clear communication. Apparently one tool is deprecated and the other experimental. Why should Slackware choose a tool marked experimental over one marked deprecated? More concerning is the kernel commit is from 2017 and yet rasdaemon still marks enabling MCE events as experimental. Unless "--enable-mce" means something different than "replace functionality of mcelog", which forgive me if that's not the correct interpretation.
For clarification, if by your word 'tool' refers to the userspace program then the userspace program were not being deprecated or anything. It is the kernel interface that change from /dev/mcelog to some EDAC-related interface and the shipped userspace mcelog program simply can not read data from the new interface although /dev/mcelog still exist (current kernel still provide /dev/mcelog via CONFIG_X86_MCELOG_LEGACY=y).
Here is the output of mcelog daemon on 2015 machine with current installed:
Code:
root@hv32:~# uname -r
6.1.53
root@hv32:~# lscpu | grep '^Model name:' | xargs
Model name: Intel(R) Xeon(R) CPU E7-4890 v2 @ 2.80GHz
root@hv32:~# ps axuw | grep mcelog
root 28313 0.0 0.0 4548 352 ? Ss 16:00 0:00 /usr/sbin/mcelog --daemon
root@hv32:~# grep mcelog /var/log/syslog | tail
Sep 19 16:00:26 hv32 mcelog: Cannot read sysfs field /sys/kernel/security/lockdown: No such file or directory
Sep 19 16:00:26 hv32 mcelog: Kernel in lockdown. Cannot enable DIMM error location reporting
This is the output from rasdaemon version 0.8.0 from the same machine (yes with all available options enabled):
Overview of Changes in 4.12.2, 20-09-2023
=========================================
* GtkTooltip:
- Don't cross native boundaries when looking for tooltips
* GtkCenterLayout, GtkEntry, GtkSearchEntry:
- Fix some issues with baseline handling
* GtkSwitch:
- Respect text direction
* Theme:
- Use relative font sizes
* GSK:
- Make repeated gradients match between GL and cairo
- Make rounded rect shrinking match between Vulkan, GL and cairo
- Fix parsing of text nodes with color glyphs
- Restrict an optimization to the cases where it is correct
- Fix rendering of shadows with opacity
* macOS:
- Clamp damage regions to the surface size
* Windows:
- Fix missing minimize and maximize buttons
* Translation updates
Basque
Brazilian Portuguese
Catalan
Chinese (China)
Czech
Danish
Dutch
Finnish
Galician
German
Hungarian
Italian
Kazakh
Latvian
Lithuanian
Slovenian
Spanish
Turkish
Mesa 22.3.0 split the intel vulkan driver into ANV for current chipsets and HASVK for legacy (ivy bridge, haswell, broadwell generation). The current package slackbuild needs the line
-Dvulkan-drivers=amd,intel,swrast \
edited to
-Dvulkan-drivers=amd,intel,intel_hasvk,swrast \
to enable vulkan support for ivy bridge, haswell, and broadwell intel graphics.
Hello,
PV, is there a technical reason for not adding this ?
I can't say I need it for now but this doesn't seem to hurt.
About /etc/rc.d/rc.crond, I noticed that when you do a "stop" and then later a "start" from a terminal, the cron process and processes it launches inherit the current shell environment.
I'm wondering if some sort of environment cleaning wouldn't be desirable ?
Env leaking is a wider issue than just crond, but yes, looks like dcron doesn't clean up the environment properly before executing jobs.
The man-page for crontab says this:
Quote:
Unlike other cron daemons, this crond/crontab package doesn’t try to do everything under the sun. It doesn’t try to keep track of user’s preferred shells; that would require special‐casing users with no login shell. Instead, it just runs all commands using /bin/sh. (Commands can of course be script files written in any shell you like.)
Nor does it do any special environment handling. A shell script is better‐suited to doing that than a cron daemon. This cron daemon sets up only four environment variables: USER, LOGNAME, HOME, and SHELL.
But the code that runs jobs uses execl() which allows the existing env to leak through to the jobs it executes.
Now, it doesn't explicitly say "... sets up only four environment variables in a clean environment" but IMO it wouldn't be unreasonable to infer that from what is written.
IMO this issue should be fixed with a patch to crond itself rather than a kludge in the rc file. Let me see if I can come up with a patch.
About /etc/rc.d/rc.crond, I noticed that when you do a "stop" and then later a "start" from a terminal, the cron process and processes it launches inherit the current shell environment.
I'm wondering if some sort of environment cleaning wouldn't be desirable ?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
