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.
In fact, today Plasma6 is a kind of Plasma5 5.50, this time they didn't bother to rewrite everything from scratch. And it is as stable as possible.
Apart from porting under Qt6, they improved the default theme a bit. In addition, there are some small improvements in the design. The most interesting part is in the Wayland sessions. Now they are rock solid.
The problem is different, it seems that they decided that phonon-gstreamer will be abandoned and we need either VLC and phonon-vlc, or MPV and phonon-mpv, which appeared more recently.
Having said that, I have a personal proposal for -current: to add MPV, which is a relatively small video player similar with MPlayer, and which currently only needs two small dependencies: mujs and luajit. The rest of the dependencies are already in -current.
Last edited by ZhaoLin1457; 04-02-2024 at 05:43 PM.
ffmpeg-6.1.1 can't be recompiuled with nv-codec-headers-12.2.72.0
Hi,
After upgrading nv-codec-headers-12.2.72.0, I faced compilation issue of ffmpeg-6.1.1.
Error log is below.
Code:
libavcodec/nvenc.c: In function 'nvenc_setup_hevc_config':
libavcodec/nvenc.c:1373:9: error: 'NV_ENC_CONFIG_HEVC' has no member named 'pixelBitDepthMinus8'
1373 | hevc->pixelBitDepthMinus8 = IS_10BIT(ctx->data_pix_fmt) ? 2 : 0;
| ^~
libavcodec/nvenc.c: In function 'nvenc_setup_av1_config':
CC libavcodec/options.o
libavcodec/nvenc.c:1458:8: error: 'NV_ENC_CONFIG_AV1' has no member named 'inputPixelBitDepthMinus8'
1458 | av1->inputPixelBitDepthMinus8 = IS_10BIT(ctx->data_pix_fmt) ? 2 : 0;
| ^~
libavcodec/nvenc.c:1459:8: error: 'NV_ENC_CONFIG_AV1' has no member named 'pixelBitDepthMinus8'
1459 | av1->pixelBitDepthMinus8 = (IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) ? 2 : 0;
| ^~
libavcodec/nvenc.c: In function 'nvenc_map_buffer_format':
libavcodec/nvenc.c:1692:16: error: 'NV_ENC_BUFFER_FORMAT_YV12_PL' undeclared (first use in this function); did you mean 'NV_ENC_BUFFER_FORMAT_YV12'?
1692 | return NV_ENC_BUFFER_FORMAT_YV12_PL;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
| NV_ENC_BUFFER_FORMAT_YV12
libavcodec/nvenc.c:1692:16: note: each undeclared identifier is reported only once for each function it appears in
CC libavcodec/opus_celt.o
CC libavcodec/opus_metadata_bsf.o
libavcodec/nvenc.c:1694:16: error: 'NV_ENC_BUFFER_FORMAT_NV12_PL' undeclared (first use in this function); did you mean 'NV_ENC_BUFFER_FORMAT_NV12'?
1694 | return NV_ENC_BUFFER_FORMAT_NV12_PL;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
| NV_ENC_BUFFER_FORMAT_NV12
CC libavcodec/opus_parse.o
CC libavcodec/opus_parser.o
libavcodec/nvenc.c:1700:16: error: 'NV_ENC_BUFFER_FORMAT_YUV444_PL' undeclared (first use in this function); did you mean 'NV_ENC_BUFFER_FORMAT_YUV444'?
1700 | return NV_ENC_BUFFER_FORMAT_YUV444_PL;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| NV_ENC_BUFFER_FORMAT_YUV444
CC libavcodec/opus_pvq.o
make: *** [ffbuild/common.mak:81: libavcodec/nvenc.o] Error 1
make: *** Waiting for unfinished jobs....
GEN libavdevice/libavdevice.ver
CC libavfilter/opencl/avgblur.o
CC libavfilter/opencl/colorkey.o
CC libavfilter/opencl/colorspace_common.o
CC libavfilter/opencl/convolution.o
CC libavfilter/opencl/deshake.o
CC libavfilter/opencl/neighbor.o
CC libavfilter/opencl/nlmeans.o
CC libavfilter/opencl/overlay.o
CC libavfilter/opencl/pad.o
CC libavfilter/opencl/remap.o
CC libavfilter/opencl/tonemap.o
CC libavfilter/opencl/transpose.o
CC libavfilter/opencl/unsharp.o
CC libavfilter/opencl/xfade.o
GEN libavfilter/libavfilter.ver
GEN libswscale/libswscale.ver
GEN libavutil/libavutil.ver
LD libavutil/libavutil.so.58
LD libswscale/libswscale.so.7
GEN libpostproc/libpostproc.ver
LD libpostproc/libpostproc.so.57
GEN libavformat/libavformat.ver
CC libavcodec/nvenc.o
libavcodec/nvenc.c: In function 'nvenc_setup_hevc_config':
libavcodec/nvenc.c:1373:9: error: 'NV_ENC_CONFIG_HEVC' has no member named 'pixelBitDepthMinus8'
1373 | hevc->pixelBitDepthMinus8 = IS_10BIT(ctx->data_pix_fmt) ? 2 : 0;
| ^~
libavcodec/nvenc.c: In function 'nvenc_setup_av1_config':
libavcodec/nvenc.c:1458:8: error: 'NV_ENC_CONFIG_AV1' has no member named 'inputPixelBitDepthMinus8'
1458 | av1->inputPixelBitDepthMinus8 = IS_10BIT(ctx->data_pix_fmt) ? 2 : 0;
| ^~
libavcodec/nvenc.c:1459:8: error: 'NV_ENC_CONFIG_AV1' has no member named 'pixelBitDepthMinus8'
1459 | av1->pixelBitDepthMinus8 = (IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) ? 2 : 0;
| ^~
libavcodec/nvenc.c: In function 'nvenc_map_buffer_format':
libavcodec/nvenc.c:1692:16: error: 'NV_ENC_BUFFER_FORMAT_YV12_PL' undeclared (first use in this function); did you mean 'NV_ENC_BUFFER_FORMAT_YV12'?
1692 | return NV_ENC_BUFFER_FORMAT_YV12_PL;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
| NV_ENC_BUFFER_FORMAT_YV12
libavcodec/nvenc.c:1692:16: note: each undeclared identifier is reported only once for each function it appears in
libavcodec/nvenc.c:1694:16: error: 'NV_ENC_BUFFER_FORMAT_NV12_PL' undeclared (first use in this function); did you mean 'NV_ENC_BUFFER_FORMAT_NV12'?
1694 | return NV_ENC_BUFFER_FORMAT_NV12_PL;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
| NV_ENC_BUFFER_FORMAT_NV12
libavcodec/nvenc.c:1700:16: error: 'NV_ENC_BUFFER_FORMAT_YUV444_PL' undeclared (first use in this function); did you mean 'NV_ENC_BUFFER_FORMAT_YUV444'?
1700 | return NV_ENC_BUFFER_FORMAT_YUV444_PL;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| NV_ENC_BUFFER_FORMAT_YUV444
make: *** [ffbuild/common.mak:81: libavcodec/nvenc.o] Error 1
Overview of Changes in 4.14.2, 03-04-2024
=========================================
* GtkScale:
- Improve positioning of values in some cases
* Theme:
- Make progress in entries visible
* Accessibility:
- Fix text insertion handling
* GDK:
- dnd: Use the default cursor durion motion
- dnd: Use a better cursor for indicating the move action
* GSK:
- gl: Handle offloads in offscreen context better
- Fix text rendering problems with some fonts
* Wayland:
- Tighten up some protocol version checks
- Use the presentation time protocol
- Fix a crash with subsurfaces
- Improve settings portal handling
* macOS:
- Fix up the app menu support
* Windows:
- Fix problems with minimization
- Fix build without fontconfig
* Debugging:
- Add font settings in the inspector
* Demos:
- Clean up the application demo
- Update cursor images for the cursor demo
* Translation updates:
Catalan
Czech
French
Georgian
Hebrew
Persian
Slovenian
Turkish
Ukrainian
Request to reconsider the use of unofficial sources for the blackbox package
In 2018 I asked for an upgrade of the blackbox window manager package to an unofficial, forked version: https://www.linuxquestions.org/quest...ml#post5870193 (I posted as the user "formalist", but the username was changed to "anon082" when I deleted my account.)
The Slackware blackbox package was subsequently rebuilt from the unofficial forked source code, and since then the blackbox package has been upgraded several times based on the same unofficial sources. The Slackware blackbox package is still being built from the unofficial, forked version.
In light of the recent news about the security vulnerability introduced into xz, I think it would be a good idea to make sure packages are built using official and trusted source code only. I therefore would like to ask for a reconsideration of the decision to use unofficial sources to build the blackbox package for Slackware.
If a decision is taken to build the blackbox package using official sources instead, then it would, I think, also be wise to consider replacing the package in earlier Slackware releases where the blackbox package is based on the unofficial source code.
In 2018 I asked for an upgrade of the blackbox window manager package to an unofficial, forked version: https://www.linuxquestions.org/quest...ml#post5870193 (I posted as the user "formalist", but the username was changed to "anon082" when I deleted my account.)
The Slackware blackbox package was subsequently rebuilt from the unofficial forked source code, and since then the blackbox package has been upgraded several times based on the same unofficial sources. The Slackware blackbox package is still being built from the unofficial, forked version.
In light of the recent news about the security vulnerability introduced into xz, I think it would be a good idea to make sure packages are built using official and trusted source code only. I therefore would like to ask for a reconsideration of the decision to use unofficial sources to build the blackbox package for Slackware.
If a decision is taken to build the blackbox package using official sources instead, then it would, I think, also be wise to consider replacing the package in earlier Slackware releases where the blackbox package is based on the unofficial source code.
Don't confuse unofficial and original or fork
(Xorg, GCC, LibreOffice, MariaDB, etc. are forks. Probably Slackware can be considered as a fork too :-) )
Code:
The original author seems to have ceased updating the repository with the exception
of a minor fix of compilation problems in 2015, leaving the last original version
at 0.70.1. However an actively maintained fork by Brian Bidulock has been picked up by
several Linux distributions in its place
I don't confuse the two, one attribute doesn't preclude the other. It's a fork and it's unofficial.
Quote:
Originally Posted by marav
Code:
The original author seems to have ceased updating the repository with the exception
of a minor fix of compilation problems in 2015, leaving the last original version
at 0.70.1. However an actively maintained fork by Brian Bidulock has been picked up by
several Linux distributions in its place
I don't confuse the two, one attribute doesn't preclude the other. It's a fork and it's unofficial.
The fact that other Linux distributions package the forked version doesn't imply that the source code is trustable.
What do you mean unofficial?
Unofficial for who?
Official Slackware 15.0 source repo is: http://ftp.slackware.com/pub/slackwa...4-15.0/source/
Unofficial Slackware 15.0 source repo is : XXXXX
There must be an entity attached to the word "unofficial"
You might want to fix that second url.
Also, SBo is official.
Last edited by volkerdi; 04-03-2024 at 03:17 PM.
Reason: redacted ;-)
l/aom-3.8.2-x86_64-1.txz: Added.
Needed to add AV1 encode/decode support to ffmpeg.
Thanks to Andrew Strong.
l/dav1d-1.4.1-x86_64-1.txz: Added.
Needed to add AV1 decode support to ffmpeg.
l/ffmpeg-6.1.1-x86_64-2.txz: Rebuilt.
Patched to build with nv-codec-headers-12.2.72.0. Thanks to J_W.
Compiled against aom-3.8.2 and dav1d-1.4.1 for AV1 support.
Thanks to glennmcc.
xap/MPlayer-20240403-x86_64-1.txz: Upgraded.
Compiled using --enable-libaom-lavc and --enable-libdav1d-lavc.
Thanks to glennmcc.
______________________________________________________________________
I can now stop building custom versions from source.
In light of the recent news about the security vulnerability introduced into xz, I think it would be a good idea to make sure packages are built using official and trusted source code only.
Except that in the 'xz' case it was the official and trusted source that was backdoored by an official and trusted co-maintainer, so your rationale doesn't really hold.
There are plenty of forks out there maintained by honourable people. I have no view on the maintainer of this new blackbox fork one way or the other but until such time as they prove themselves unworthy their efforts should be respected.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.