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.
php 7.x is end of life, no updates security or otherwise at January 1 2023, 3 weeks from now
I see 8.1.x is in extra and should be supported for 22 months, is anyone running this version?
Any hiccups with anything you were running, blogs, forums, carts, whatever?
It's worse than that
php 7.4.x is EOL since Nov. 28, 2022 ...
Code:
If you are using these releases, you are strongly urged to upgrade to a current version,
as using older versions may expose you to security vulnerabilities and bugs that have been
fixed in more recent versions of PHP.
php 7.x is end of life, no updates security or otherwise at January 1 2023, 3 weeks from now
I see 8.1.x is in extra and should be supported for 22 months, is anyone running this version?
Any hiccups with anything you were running, blogs, forums, carts, whatever?
I've been using PHP 8.1.x for some time, compiled from sources (my old habit) and I have no compatibility issues with what I need (Apache, Joomla, Roundcube).
I am guessing when v7 is EOL, Pat will most likely just version bump security updates to the 8.x series, and so most likely everyone by then will have most likely installed the 8 or 8.1 from /extra ?
I am guessing when v7 is EOL, Pat will most likely just version bump security updates to the 8.x series, and so most likely everyone by then will have most likely installed the 8 or 8.1 from /extra ?
OR, more probably he will just stop pushing updates for v7, as nothing new will be available. Just like he did with the other/older releases.
How you people loves to compare Slackware with RHEL, I would say that RHEL itself will maintain 10 years the included in a release, BUT even Slackware maintains 10 years also a release, the Slackware depends on upstream, hence The Team cannot maintain the included software for 10 years.
OR, more probably he will just stop pushing updates for v7, as nothing new will be available. Just like he did with the other/older releases.
How you people loves to compare Slackware with RHEL, I would say that RHEL itself will maintain 10 years the included in a release, BUT even Slackware maintains 10 years also a release, the Slackware depends on upstream, hence The Team cannot maintain the included software for 10 years.
I don't know how you jumped to that conclusion; RHEL probably has the resources to maintain an EOL package on their own - Slackware does not. Overall I do not understand your post, so what is your proposal? Just stay an an EOL package? Pat is just to write up patches himself for php7 then?
I don't know how you jumped to that conclusion; RHEL probably has the resources to maintain an EOL package on their own - Slackware does not. Overall I do not understand your post, so what is your proposal? Just stay an an EOL package? Pat is just to write up patches himself for php7 then?
If we look on what Slackware did on the previous -stable releases, I bet that Slackware 15.0 will stay on the last PHP7 release, once it's public available. Because, this what was did in the past and just like you said, Slackware has no resources to maintain EOL packages on their own.
Maybe you have unrealistic expectations from Slackware and its release 15.0 ?
It's obvious that The World moves too fast for Slackware...
In my humble opinion, more realistic will be a release cycle of one year and a support period of one year or two. Anything else is exactly what you are about to learn: maintaining yourself the software. DIY.
Last edited by LuckyCyborg; 12-06-2022 at 11:16 AM.
If we look on what Slackware did on the previous -stable releases, I bet that Slackware 15.0 will stay on the last PHP7 release, once it's public available. Because, this what was did in the past and just like you said, Slackware has no resources to maintain EOL packages on their own.
Maybe, or if the package is EOL - and php8 and 8.1 is already in /extra I do not see why Pat won't just start on that and include security updates from there.
Quote:
Originally Posted by LuckyCyborg
Maybe you have unrealistic expectations from Slackware and its release 15.0 ?
Not really I just tend to go with the flow.
Quote:
Originally Posted by LuckyCyborg
It's obvious that The World moves too fast for Slackware...
Sure this last release was a long wait; I however do not have the expertise or the time to assist in the endeavor , perhaps you do - if so why not contribute?
Quote:
Originally Posted by LuckyCyborg
In my humble opinion, more realistic will be a release cycle of one year and a support period of one year or two. Anything else is exactly what you are about to learn: maintaining yourself the software. DIY.
Ok, join the team and develop - I myself do not really care - if I were so concerned about a faster release cycle; I would have used a different distro as my main distro. I also again do not have the time or the knowledge to offer assistance to Slackware. I just use it , just because it happens to be the first distro I was introduced to, and always end up coming back.
As LuckyCyborg writes, mostly when a package becomes EOL or when a package stops compiling on a "maintained" version of Slackware that package will no longer get any updates. This applies not only to php, but also other packages like firefox and thunderbird.
On the other hand, during the times, it has happened that packages in the extra directory gets security updates. At least this has happened for wicd which then was in the extra directory. Usually you do not want to install a patch like that unless you already have the package (in this example wicd) installed, but when it comes to php8 it might be a good idea to install security updates when php7 is EOL.
As LuckyCyborg writes, mostly when a package becomes EOL or when a package stops compiling on a "maintained" version of Slackware that package will no longer get any updates. This applies not only to php, but also other packages like firefox and thunderbird.
On the other hand, during the times, it has happened that packages in the extra directory gets security updates. At least this has happened for wicd which then was in the extra directory. Usually you do not want to install a patch like that unless you already have the package (in this example wicd) installed, but when it comes to php8 it might be a good idea to install security updates when php7 is EOL.
regards Henrik
Guess what? The Slackware 15.0 have in /extra both PHP80 and PHP81 which packages are maintained with security fixes, in parallel with the ones for PHP7 . And this way I believe that will continue until all 2 of them goes EOL.
So, in a sense the concerns of this thread are a no issue. Because there will be a maintained PHP on Slackware 15.0 until ALL of those 3 versions will go EOL.
However, seems like some people does not understand really the Slackware (or any other Linux distribution with point releases) Architecture and that a -stable release is not a rolling release. I for one, I have heard long time ago that -stable release means a stable API and ABI. You want more? DIY or jump in a superior release.
So, in fact the solution for having ALWAYS a maintained PHP in a -stable release is you guys to "persuade" Slackware to seriously shorten its release cycle. One release per year will give you really what you want. Go wild and seriously ask for this.
Last edited by LuckyCyborg; 12-06-2022 at 03:33 PM.
I just upgraded my workstation to Php8.0.
The php.ini which comes with php 8 tries to load extension xmlrpc.so which doesn't exist any more. This generates all kinds of warnings.
I use weberp for accounting, this relies on xmlrpc.so to print pdf files. This is not a Slackware problem.
I've been using PHP 8.1.x for some time, compiled from sources (my old habit) and I have no compatibility issues with what I need (Apache, Joomla, Roundcube).
Thanks, I do build 7.4 from source because of gd issues requiring X libs, I was going to try 8.1 in extra to see if the issue remains before I build source.
cheers
(sorry for delay reply, I am not once again getting notifications from LQ, not blacklisted, just not sending)
I just upgraded my workstation to Php8.0.
The php.ini which comes with php 8 tries to load extension xmlrpc.so which doesn't exist any more. This generates all kinds of warnings.
I use weberp for accounting, this relies on xmlrpc.so to print pdf files. This is not a Slackware problem.
Just my thoughts.
Don
I found the same issue after upgrading to 8.1.12 ponce informed me that the solution to this was to comment
Code:
extension=xmlrpc
from my php.ini
For me this was acceptable as I don't use it, though I did get some other errors when testing some code for issues.
NOTE: If you're upgrading from php 7 to php 8+ I recommend you update your pear modules if any are installed especially pear::mail
Code:
pear upgrade
Regarding xmlrpc, from what I can tell this appears to have been abandoned for some time and unlinked from PHP.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
