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.
The problem is the release model. Unlike the BSDs, "stable" kernels don't just include important fixes; they may also include other changes, so long as those changes don't break any APIs, and worse still, those changes are taken from the same development sources as are going into the mainline kernel Release Candidates, before they've had time to be proven. The result is that you get far too many changes, and you can actually encounter the bizarre situation of having a bug appear in the so called "stable" releases when it never even made it to the actual mainline release because it was fixed in a subsequent RC prior to the official release.
The whole release engineering model is just insanity, and is why distro like Redhat/Ubuntu maintain their own kernels.
"stable" releases simply aren't what people think they are, and nor are the "LTS" releases.
I teach You what insanity is: calling this model "an accident".
IMHO this is by design to have little or no use of the "free for all" code base but still have enough material there for the actual big players to be able to forge a actual running product (like Android with always something from few years back and major distros either with truckload of patches or something few months old).
So far we where lucky and PV made wonders, i am on the edge of my seat of what wonder he will pull now - he's the man but boy it was never crazy like this before
I teach You what insanity is: calling this model "an accident".
So far we where lucky and PV made wonders, i am on the edge of my seat of what wonder he will pull now - he's the man but boy it was never crazy like this before
I agree I often wonder how in the world does Pat keep all this stuff straight in his head.
I imagine he has some huge chart on the wall with all the dependencies like we did back in the day when contractors first started to use Murphy's Critical Path Management. Some of the charts were 8 feet high and 16 feet long (hand drawn) just to track the project.
Anyway PV is one amazing individual.
Is anyone else seeing the following key error that I get when trying to verify the latest "modules" .txz (downloaded with wget)?
Code:
# gpg -verify kernel-modules-5.10.23-x86_64-1.txz.asc
gpg: ify: skipped: public key not found
gpg: kernel-modules-5.10.23-x86_64-1.txz.asc: encryption failed: public key not found
I do not get that error with the "huge" .txz download:
Code:
# gpg --verify kernel-huge-5.10.23-x86_64-1.txz.asc
gpg: assuming signed data in `kernel-huge-5.10.23-x86_64-1.txz'
gpg: Signature made Thu 11 Mar 2021 03:33:25 PM PST using DSA key ID 40102233
gpg: Good signature from "Slackware Linux Project <security@slackware.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: EC56 49DA 401E 22AB FA67 36EF 6A44 63C0 4010 2233
Is anyone else seeing the following key error that I get when trying to verify the latest "modules" .txz (downloaded with wget)?
Code:
# gpg -verify kernel-modules-5.10.23-x86_64-1.txz.asc
gpg: ify: skipped: public key not found
gpg: kernel-modules-5.10.23-x86_64-1.txz.asc: encryption failed: public key not found
I do not get that error with the "huge" .txz download:
Code:
# gpg --verify kernel-huge-5.10.23-x86_64-1.txz.asc
gpg: assuming signed data in `kernel-huge-5.10.23-x86_64-1.txz'
gpg: Signature made Thu 11 Mar 2021 03:33:25 PM PST using DSA key ID 40102233
gpg: Good signature from "Slackware Linux Project <security@slackware.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: EC56 49DA 401E 22AB FA67 36EF 6A44 63C0 4010 2233
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,099
Original Poster
Rep:
Here we go again.
The Linux Kernel Archive by Thread message board hasn't been updated in about 10 hours. The last time stamp was 09:35 EST. It should be EDT as the U.S. went on Day Light Saving Time yesterday, Sunday. The current correct time is 19:30 EDT.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,099
Original Poster
Rep:
The Linux Kernel Archive by Thread message board didn't come back to life until one minute after midnight EST on 16 March. Actually, if it is still running on Standard time, that would make it 01:01 EDT on the 16th.
Regardless, apparently some new release candidates were posted into the ether while the board was down. From looking through the bits & pieces it appears,
Year 2021, Round 20 has been posted,
and has been scheduled for release on Wednesday, 17 March 2021 (St. Patrick's Day), at approximately 14:00, GMT.
There are no details, but here is what I have sorted out so far,
5.11.7-rc1, will have 306 patches.
5.10.24-rc1, will contain 290 patches.
5.4.106-rc1, will include 168 patches.
4.19.181-rc1, will incorporate 120 patches.
4.14.226-rc1, will accommodate 95 patches.
4.9.262-rc1, will subsume 78 patches.
4.4.262-rc1, will embody 75 patches.
Last edited by cwizardone; 03-16-2021 at 08:40 AM.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,099
Original Poster
Rep:
Year 2021, Round 21.
Another batch of updates has been scheduled for release on Sunday, 21 March 2021, at approximately 12:00, GMT. If no problems are found while testing the release candidates, they might be available sometime on Saturday (depending on your time zone).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.