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.
Today the KDE Community releases Plasma 5.24, a Long Term Support (LTS) release that will receive updates
and bugfixes until the final Plasma 5 version, before we transition to Plasma 6.
This new Plasma release focuses on smoothing out wrinkles, evolving the design,
and improving the overall feel and usability of the environment.
CVE-2022-22753: Privilege Escalation to SYSTEM on Windows via Maintenance Service
CVE-2022-22754: Extensions could have bypassed permission confirmation during update
CVE-2022-22756: Drag and dropping an image could have resulted in the dropped object being an executable
CVE-2022-22759: Sandboxed iframes could have executed script if the parent appended elements
CVE-2022-22760: Cross-Origin responses could be distinguished between script and non-script content-types
CVE-2022-22761: frame-ancestors Content Security Policy directive was not enforced for framed extension pages
CVE-2022-22763: Script Execution during invalid object state
CVE-2022-22764: Memory safety bugs fixed in Firefox 97 and Firefox ESR 91.6
Today the KDE Community releases Plasma 5.24, a Long Term Support (LTS) release that will receive updates
and bugfixes until the final Plasma 5 version, before we transition to Plasma 6.
This new Plasma release focuses on smoothing out wrinkles, evolving the design,
and improving the overall feel and usability of the environment.
What's new
Thunderbird will now offer to send large forwarded attachments via FileLink
Fixes
- Partially signed unencrypted messages displayed an incorrect "partially encrypted" notification
- Attachments filenames were not sanitized before saving to disk
- In the attachment bar, the "Import OpenPGP Key" item displayed for public keys displayed an error and did not import the key
- "Open with" attachment dialog did not have a selected radio button option
[QUOTE=Windu;6326745]Ever tried building a single package like this? For the kwayland package:
Code:
./kde.SlackBuild frameworks:kwayland
Thank you for your kind reference, of which I knew nothing. I go to invent.kde.org, download the recent tag, change Release and /usr, make and install into a tgz package. Navigating groups at invent is far easier to find packages than the inherited package structure of slackware64/source/kde. Refer to https://kdesrc-build.kde.org, perl scripts.
Ever tried building a single package like this? For the kwayland package:
Code:
./kde.SlackBuild frameworks:kwayland
Thank you for your kind reference, of which I knew nothing. I go to invent.kde.org, download the recent tag, change Release and /usr, make and install into a tgz package. Navigating groups at invent is far easier to find packages than the inherited package structure of slackware64/source/kde. Refer to https://kdesrc-build.kde.org, perl scripts.
BUT, the kde.SlackBuild I do not believe that's designed for building packages get from fetching sources from invent.kde.org
From what I seen, after several hundreds of full builds of Plasma5 while it still was in KTown (and last one done today, for Plasma 5.24.0) this kde.SlackBuild was designed to build the series of software published by kde.org, and it's always about software series released by KDE.
For example, into slackware64/source/kde/src/plasma goes the KDE Plasma tarballs, which are published separately, with their release cycle.
Homework: find what software series tarballs goes into slackware64/source/kde/src/frameworks
Last edited by LuckyCyborg; 02-08-2022 at 02:40 PM.
Or just remove the symlink altogether and let users create it if they want them.
This will prevent transition frustration if we get a python3 -> python4 upgrade.
Dunno about that. Not everyone is an expert and most python packages these days just say do "python" xyz.
I was reading about the status of python 2 recently, and it said it is obsolete and MOST packages have been moved to python3 bla bla. Needing python2 should be the exception. Having python -> python3 seems like a healthy default.
If python4 releases soon, which seems unlikely considering python3.10, uptake of and general transition to python4 would probably take a very long time. So likely for a long time python3 will be the default.
Dunno about that. Not everyone is an expert and most python packages these days just say do "python" xyz.
I was reading about the status of python 2 recently, and it said it is obsolete and MOST packages have been moved to python3 bla bla. Needing python2 should be the exception. Having python -> python3 seems like a healthy default.
If python4 releases soon, which seems unlikely considering python3.10, uptake of and general transition to python4 would probably take a very long time. So likely for a long time python3 will be the default.
Symlinking python -> python3 goes against upstream defaults. With python2, it was done automatically when you built the program, but the developers of python3 specifically chose to leave that bit out. This was probably to prevent people from defaulting to a python command, when they should be using python2, python3, or eventually maybe python6.
The transition between python2 and python3 was horrible partially because of that symlink and, in my opinion, we should try and avoid it in the future.
I guess we'll just need to see if Pat decides to deviate from upstream (he does do this occasionally) and create the symlink for python3 once python2 is finally removed (which I suspect python2 will be removed shortly after -current development resumes, but that's just a guess).
I guess we'll just need to see if Pat decides to deviate from upstream (he does do this occasionally) and create the symlink for python3 once python2 is finally removed (which I suspect python2 will be removed shortly after -current development resumes, but that's just a guess).
I'm not much into python at all.. But, you think he will remove python2 anytime soon? Not keep it for backwards compatibility and what not?
I'm not much into python at all.. But, you think he will remove python2 anytime soon? Not keep it for backwards compatibility and what not?
I don't think there's much using it in 15.0, but enough he didn't want to excise it at the time and deal with the fallout. There were enough other things he was dealing with trying to get the release to the finish line.
I'm thinking with the next development cycle, he'll make the move to remove it completely, but it's just a guess. It's been long suggested that people shouldn't be using python2 and it's been EOL for over 2 years now (with quite a few vulnerabilities).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
