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.
It appears that Slackware still enables the /dev/kmem interface. From kernels/huge.s/config in Slackware64-current:
Code:
CONFIG_DEVKMEM=y
Recent discussions on LKML suggest that /dev/kmem may be removed from the kernel soon on the basis that nothing of significance uses it anymore and it represents a significant security risk. Furthermore, in a recent lwn.net article it was written:
Quote:
One will have to look long and hard for a distributor that enables this option in 2021; most of them disabled it many years ago.
It therefore seems prudent to at least consider the disabling of CONFIG_DEVKMEM in kernels supplied by Slackware.
KDE team decided to maintain security/usability patches for Qt 5.15 (till KDE is ported to Qt6).
It would be a good idea to follow, watch and incorporate them in Slackware.
I am a little confused by the latest changelog. Is Pat saying he is going to jump to kernel 5.12 or does he just mean the next version release of 5.10.x?
Code:
Tue Apr 6 19:54:52 UTC 2021
Thanks to nobodino and ponce for help fixing a few sources that wouldn't
build properly. Overnight I tested recompiling everything using gcc-10.3.0-RC
and had no build failures, so we'll be taking gcc-10.3.0 once it (and new
kernels) arrive probably sometime next week. And then I think we'll be calling
this a beta. Cheers! :-)
I am a little confused by the latest changelog. Is Pat saying he is going to jump to kernel 5.12 or does he just mean the next version release of 5.10.x?
Assuming no major hiccups with the expected 5.12 rc7 kernel this next Sunday (11 APR), Linus believes that the normal release schedule should be met for 5.12, which would mean releasing it on Sunday the 18th.
So based on those expected dates and knowing the US considers Sunday to be the first day of the week, I'd guess it'd be just newer 5.10.x or 5.11.x, but I wouldn't think that'd be a big enough deal to announce in the ChangeLog. So maybe he's following ISO 8601 stating that Monday is the start of the week and Sunday the 18th would be the end of "next week" and is announcing that 5.11 will be replaced with 5.12 in testing/.
Haha, we always look way too much into these changelog messages
I suggest to replace asciidoc by asciidoctor that supersedes it, either in the linux-doc packages or in its own package. It is fully compatible with the asciidoc syntax, so convtags should still work
With the 15.0 beta coming out next week or so it would be nice if the final choice of kernel held the long waited for fix for the Amazon Kindle device:
I have been patching my working kernel for some time now to get around an odd 'unmounting' issue with my Kindle Oasis and with the eventual backport of this fix the need will be gone...
With the 15.0 beta coming out next week or so it would be nice if the final choice of kernel held the long waited for fix for the Amazon Kindle device:
I have been patching my working kernel for some time now to get around an odd 'unmounting' issue with my Kindle Oasis and with the eventual backport of this fix the need will be gone...
According to this comment, upstream has fixed this. Looking over the commit history for 5.10, it should be in 5.10.26, which means the fix has been in -current since 26 MAR. (It's been in the 5.11.x series since 5.11.9, so that's been fixed on -current since 25 MAR.)
Code:
Alan Stern (1):
usb-storage: Add quirk to defeat Kindle's automatic unload
SOURCE: 5.10.26 Release notes
No more need to patch your kernels!
Last edited by bassmadrigal; 04-07-2021 at 12:36 AM.
Reason: Fix link
According to this comment, upstream has fixed this.
Your link is broken but I think you are referring to the Calibre fix which did not do anything useful with my Kindle Oasis unfortunately. From the time of the original bug report I have simply been compiling a 'safe' kernel for everyday use that has the problem patch reversed.
Quote:
Looking over the commit history for 5.10, it should be in 5.10.26, which means the fix has been in -current since 26 MAR. (It's been in the 5.11.x series since 5.11.9, so that's been fixed on -current since 25 MAR.)
Thanks for that, I have been using 5.10.18 on -current so the incorporation of the fix went completely unnoticed by me .
Quote:
No more need to patch your kernels!
Perhaps no need any more so now I will just do it for fun!
Your link is broken but I think you are referring to the Calibre fix which did not do anything useful with my Kindle Oasis unfortunately. From the time of the original bug report I have simply been compiling a 'safe' kernel for everyday use that has the problem patch reversed.
Oops! I fixed the link. It was the bottom comment of the kernel bug report you linked to. It said the fix has been done in 5.12 and will be backported to all active kernels back to 4.14 (so, 4.14, 4.19, 5.4, 5.10, and 5.11).
I just searched the commit history for 5.10 and 5.11 for the title of the patch you linked to, and it shows it should be in 5.10.26 and 5.11.9.
grab aom from SBo and add --enable-libaom in ffmpeg build options
grab dav1d from SBo and add --enable-libdav1d in ffmpeg build options
Other options are:
create new SlackBuild for rav1e and add --enable-rav1e in ffmpeg build options
create new SlackBuild for STV-AV1 and add --enable-stvav1 in ffmpeg build options
According to https://www.andrews-corner.org/sintel.html, rav1e is the one to go for. However I've been using the SBo's aom to build av1 support into the ffmpeg4 SlackBuild (14.2), which the mpv video player uses as a back end, and it seems to play back an AV1 encoded test video just fine.
I've locally rebuilt -current's ffmpeg with SBo's aom & --enable-libaom option and the resulting ffplay handles the AV1 test file too. Without the --enable-libaom option, ffplay plays the test video's audio OK but the video comes out as noise (not random but not really psychedelic either). As for mpv (which uses ffmpeg as backend) current's existing ffmpeg, without --enable-libaom, the test file can no longer be played at all, with mpv complaining:
Code:
(+) Video --vid=1 (*) (av1 1280x720 24.000fps)
(+) Audio --aid=1 (*) (aac 2ch 48000Hz)
Failed to initialize a decoder for codec 'av1'.
Video: no video
Exiting... (Errors when loading file)
BTW, the ffmpeg AV1 related build options are from https://ffmpeg.org/general.html (search for AV1) which also gives instructions to find & build each codec.
chris
Last edited by chris.willing; 04-07-2021 at 02:57 AM.
Reason: Add mpv error
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
.
