[SOLVED] What version of Python 3.x should ship with Slackware 15.0?
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.
View Poll Results: Which python3 should ship in Slackware 15.0?
I figured we would want the latest version, and upgrading from 3.8 to 3.9 had been uneventful, but we've hit a few more speed bumps with this one so I'm looking for some community feedback. If Slackware 15.0 is only going to ship one version of Python3, which one should it be?
I'm probably least informed of what is affected and what is not. What about Python 3.9 in 15.0 and then a fairly rapid 15.1 release to deal with the update to Python 3.10? But I suspect there is a queue of other stuff post 15.0 and it means that there will be a 15.0 and a 15.1 to support?
I might if I cared as strongly about other distributions.
I am happy with Python 3.10 if high-profile software is able to cope with it. In the long run and considering the Slackware release cycle, I'd take a version that is as recent as possible without major dealbreakers.
Re-compiling packages takes some time but that's a one-time effort, right?
EDIT: I realized that this post doesn't have any context itself and you'd need to refer to the post quoted in the quoted link. This is for a script that will easily update $PRGNAM.SlackBuild and $PRGNAM.info files for a new version. It will update the $VERSION variable in the .info and .SlackBuild, any download links containing the $VERSION, and it downloads the source files and determines the md5sum to be able to update the MD5SUM variable for those new download links. After running this, it should just be a matter of running the SlackBuild to verify the updates still build with these minor changes. My previous version of the script did not support programs that required multiple downloads, and that is what I fixed today.
You just cd into the directory of the SlackBuild and .info files and run the script passing the new version to it. This does only work if the versions are included in the download links (or the download link doesn't change).
Code:
cd location/to/SlackBuild-dir
version-bump.sh 1.5.8
After giving this some time to sink in and hoping that this update would be reverted because of its impact, I now think we are stuck with Python 3.10 in Slackware. Which means I had to start looking at which of my own packages are now broken.
I would rather say that he wanted 3.9 back. Faced with the reality that 3.10 is still in -current at time of writing, he started to move with the flow and already updated Inkscape and its dependencies to 3.10 and is asking support from those using his repositoy to identify his packages broken by 3.10 so he can recompile them.
Last edited by gegechris99; 10-23-2021 at 11:22 AM.
Reason: typo on Inkscape
I would rather say that he wanted 3.9 back. Faced with the reality that 3.10 is still in -current at time of writing, he started to move with the flow and already updated Inskape and its dependencies to 3.10 and is asking support from those using his repositoy to identify his packages broken by 3.10 so he can recompile them.
He really wants 3.9 back. In the comments: "alienbob
October 22, 2021 at 18:57
Well I hope he still reads this blog because I am not connected to the Slackware team since this summer."
He will update the packages but he doesn't sound happy about it.
I've been trying to get frescobaldi working in 3.10, and I think it's going to need a bug pass from the developer. Not sure who else uses it with slackware, but for the time being, you might be better served with atom + lilypond plugins.
If anyone reading this thread uses gnuradio and would like a patch for gnuradio-3.9.3.0 for python-3.10, I can provide one. I imagine the patch will apply to other versions of gnuradio - there is not much in it - but that's not tested.
If the latest version is the best why is glibc also not updated to 2.34
Code:
Sat Aug 7 19:04:04 UTC 2021
Since glibc-2.34 makes a potentially risky change of moving all functions
into the main library, and another inconvenient (for us) change of renaming
the library files, we'll stick with glibc-2.33 for Slackware 15.0 and test
the newer glibc in the next release cycle. But we'll backport the security
fixes from glibc-2.34 with this update:
The nameserver caching daemon (nscd), when processing a request for netgroup
lookup, may crash due to a double-free, potentially resulting in degraded
service or Denial of Service on the local system. Reported by Chris Schanzle.
The mq_notify function has a potential use-after-free issue when using a
notification type of SIGEV_THREAD and a thread attribute with a non-default
affinity mask.
The wordexp function may overflow the positional parameter number when
processing the expansion resulting in a crash. Reported by Philippe Antoine.
For more information, see:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27645
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33574
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-35942
(* Security fix *)
If the latest version is the best why is glibc also not updated to 2.34
Because the GLIBC 2.34 contains changes which requires mass rebuilding and patching various packages within Slackware. So, it will be update on the next development cycle, post 15.0 release.
Contrary, the Python 3.10 works quite well on Slackware and the eventual issues are on external software, supposed to be maintained by different people. Why should care Slackware of someone else turf?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
