LinuxQuestions.org - Requests for -current (14.2-->15.0)

I am among those who hope for a Slackware 15 soon. But I realize that there is a lot that goes into making a stable distribution that is "current" enough for ordinary users and "stable" enough to be a reliable go-to linux. The strategy I am adopting is to stop updating slackware64_current as of now. I have everything I want and it all works. If there is some crisis in Firefox or some other package that requires upgrading I will hopefully find out about it and be able to upgrade only that package. Maybe in six months or so I will want to upgrade everything again, but I am going to try and restrain myself, since I am in no way a beta tester.

I switched to current because I needed new hardware drivers in the new kernels and some newer program versions. I think the single most important hardware need is for the new AMD ryzen processors and graphics. That seems to be pretty well handled now. I also think it should be made clear to users that the mozjs packages need to be handled with removepkg and install-new. That can be a show-stopper since your computer just doesn't work right if you mess that up.

To points. First, by switch to -current, you became a tester. Second, if a package is listed in ChangeLog.txt as "Added." and another is listed as "Removed." It should be understood the one will have to do the following:

Code:

# slackpkg install-new

# slackpkg clean-system



-- OR --



# installpkg <added>

# removepkg <removed>

Note: Nothing wrong with mixing them up, "removepkg and install-new". Result are what matter.

I guess a third point is in order, READ, ChangeLog.txt before doing an update. This avoids most show stoppers.

gp.d	09-27-2020 05:17 AM

Quote:

Originally Posted by baldzhang (Post 6169724)

last firmware package: kernel-firmware-20200923_afbfb5f-noarch-1.txz, is missing symbol links.

upstream remove them, could be created by copy-firmware.sh.

That does not work for me, (maybe I did something wrong) but going back to an older version (20200901 in my case)
solved the problem: Some parts of "nouveau" are missing, so there was no hw-acceleration anymore ...

At this occasion I tried the proprietary nvidia-driver (450.66), that worked with X but when going back to runlevel 3
there was no signal for the monitor! Just a "black screen" with no chance to get back a screen!
rebooting over ssh and removing that driver "solved" that self-made problem

Thom1b

09-27-2020 06:57 AM

openssh-8.4 is released.

https://ftp.openbsd.org/pub/OpenBSD/...h-8.4p1.tar.gz
https://ftp.openbsd.org/pub/OpenBSD/...4p1.tar.gz.asc

allend

09-27-2020 07:26 AM

Quote:

because here we should install everything or we risk to be excommunicated.

Quote:

Partial installs are not allowed in Slackware. I heard that over those who dare to do this, lighting bolts will fall from heavens.

You are perfectly entitled to do a partial install. The problem comes with the time wasted when a lightning bolt falls, leading to threads something like:

Q. Hello roadside assist, my new Slackware model does not go. Can you help?
A. Does the engine go?
Q. Yes. What do I try next?
A. Does the engine rev when you press the accelerator?
Q. Yes. What do I try next?
A. Is the car in gear?
Q. Yes. What do I try next?
A. Then it should be going. Have you made any mods?
Q. I wanted a low profile look and took the wheels off. Would that make a difference?

ponce

09-27-2020 07:29 AM

Quote:

Originally Posted by Thom1b (Post 6170161)

openssh-8.4 is released.

https://ftp.openbsd.org/pub/OpenBSD/...h-8.4p1.tar.gz
https://ftp.openbsd.org/pub/OpenBSD/...4p1.tar.gz.asc

works fine here, FWIW.

just read this in the release notes, might interest a lot of people (that should have enough time to update their keys): it's there since a few releases but pasting again won't hurt

Code:

Future deprecation notice

=========================



It is now possible[1] to perform chosen-prefix attacks against the

SHA-1 algorithm for less than USD$50K. For this reason, we will be

disabling the "ssh-rsa" public key signature algorithm by default in a

near-future release.



This algorithm is unfortunately still used widely despite the

existence of better alternatives, being the only remaining public key

signature algorithm specified by the original SSH RFCs.



The better alternatives include:



 * The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These

  algorithms have the advantage of using the same key type as

  "ssh-rsa" but use the safe SHA-2 hash algorithms. These have been

  supported since OpenSSH 7.2 and are already used by default if the

  client and server support them.



 * The ssh-ed25519 signature algorithm. It has been supported in

  OpenSSH since release 6.5.



 * The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521. These

  have been supported by OpenSSH since release 5.7.



To check whether a server is using the weak ssh-rsa public key

algorithm, for host authentication, try to connect to it after

removing the ssh-rsa algorithm from ssh(1)'s allowed list:



    ssh -oHostKeyAlgorithms=-ssh-rsa user@host



If the host key verification fails and no other supported host key

types are available, the server software on that host should be

upgraded.



We intend to enable UpdateHostKeys by default in the next OpenSSH

release. This will assist the client by automatically migrating to

better algorithms. Users may consider enabling this option manually.



[1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and

    Application to the PGP Web of Trust" Leurent, G and Peyrin, T

    (2020) https://eprint.iacr.org/2020/014.pdf

bassmadrigal

09-27-2020 04:00 PM

Quote:

Originally Posted by ZhaoLin1457 (Post 6169987)

Partial installs are not allowed in Slackware. I heard that over those who dare to do this, lighting bolts will fall from heavens.

If Pat were to choose to leave out a portion of KDE/Plasma5 like Jeebizz requested, it would not be a "partial install". A partial install is when a user chooses to leave something out that Pat includes with a full install, not if Pat chooses to not include a piece of software (I believe he's not included some xfce programs).

If Pat were to leave KDE PIM and akonadi out, they could reside on SBo (if someone wanted to add and support them).

ZhaoLin1457

09-27-2020 04:31 PM

Quote:

Originally Posted by bassmadrigal (Post 6170304)

If Pat were to choose to leave out a portion of KDE/Plasma5 like Jeebizz requested, it would not be a "partial install".

There is no such thing like KDE PIM in the today Plasma5.

Basically, what you refer as KDE PIM, is a part of KDE Applications, which KDE Applications are released as whole by KDE.

And I believe that we shall respect the upstream decisions.

Really matters that the installed size of Slackware is 40GB or 39GB? Anyways, thanks to the Full Recommended Install Doctrine (to permit me to quote His Holiness Enorbet) really does not matter.

If I get Plasma5, I would love to get the whole hog and myself to choose what to install. So, I am not against that "KDE PIM" to lives in a separate series.

But, just because some radicals does not need or want KDE PIM, that shall not force me to not use this PIM or to make difficult for me to use it.

I honestly love those KDE PIM features, you have problems with that?

Then just not not install them and do not force others to be near impossible to use them.

Oh, wait... I forgot about lightning bolts.

Jeebizz

09-27-2020 04:46 PM

Quote:

Originally Posted by bassmadrigal (Post 6170304)

As it was just a suggestion, if Pat chooses to keep them in that is fine too - I do not mind removing them on my own; but I would probably just ask for some assistance in getting a list of Akonadi/KDE-Pim dependencies so that I can remove them myself if need be. I tried to manually track them when I was messing with Devuan today, but yea I think I missed some libs. If I could (when Plasma5 is finally introduced into Slackware) get a full list of deps/libs for Akonadi and KDE-Pims - that would be great and I'll just go in during the install and manually opt out of those particular packages myself, I don't mind at all. Again, now that I know Plasma5 can function just fine without Akonadi and KDE-Pim, there is no longer any reason for me to not give KDE another look now. :)

Didier Spaier

09-27-2020 05:05 PM

Small nitpick: in smartmontools.SlackBuild please write /sbin/makepkg instead of just makepkg for fakeroot users among us.

saxa	09-27-2020 06:17 PM

libsigc++-2.10.4
https://download.gnome.org/sources/l...-2.10.4.tar.xz

saxa	09-28-2020 05:56 AM

gcr-3.38.0
https://download.gnome.org/sources/g...-3.38.0.tar.xz

Actually there is also the version 3 of libsigc++ but I am not sure if it is directly upgradable.

libsigc++-3.0.4
https://download.gnome.org/sources/l...+-3.0.4.tar.xz

saxa	09-28-2020 06:59 AM

vala-0.50.1
https://download.gnome.org/sources/v...-0.50.1.tar.xz

bassmadrigal

09-28-2020 10:16 AM

Quote:

Originally Posted by ZhaoLin1457 (Post 6170311)

Reread my post. I was simply pointing out that if Pat chooses to leave something out from upstream, it does not mean that someone is doing a "partial install". A "partial install" is leaving packages out that Pat included in a full install of Slackware, not Pat choosing to not include something from upstream.

I have no care whether the applications that could be considered KDE-Pim are included or excluded.

ArTourter

09-28-2020 11:18 AM

Quote:

Originally Posted by saxa (Post 6170425)

Actually there is also the version 3 of libsigc++ but I am not sure if it is directly upgradable.

libsigc++-3.0.4
https://download.gnome.org/sources/l...+-3.0.4.tar.xz

Well is seems that one can have both version 2 and 3 installed concurrently according to the release notes for version 3.0.0

Quote:

3.0.0 (stable)

This is the first stable release of sigc++-3.0, installable in
parallel with sigc++-2.0.

saxa	09-28-2020 01:34 PM

Great, I have not saw that info reading fast on the web site. It is probably a different API version and maybe someday something will
ask for it.

baldzhang

09-28-2020 10:10 PM

Quote:

Originally Posted by baldzhang (Post 6169724)

last firmware package: kernel-firmware-20200923_afbfb5f-noarch-1.txz, is missing symbol links.

upstream remove them, could be created by copy-firmware.sh.

package: kernel-firmware-20200928_b78a66c-noarch-1.txz still missing symbol links ...

biker_rat

09-28-2020 10:20 PM

Mesa is now 20.2.0

USUARIONUEVO

09-29-2020 12:54 AM

Quote:

Originally Posted by baldzhang (Post 6170647)

package: kernel-firmware-20200928_b78a66c-noarch-1.txz still missing symbol links ...

Code:

make DESTDIR=$PKG FIRMWAREDIR=/lib/firmware install

baldzhang

09-29-2020 08:12 AM

Quote:

Originally Posted by USUARIONUEVO (Post 6170664)

Code:

make DESTDIR=$PKG FIRMWAREDIR=/lib/firmware install

I have many ways to fix it for myself, this is just a report.

drumz

09-29-2020 09:57 AM

Quote:

Originally Posted by baldzhang (Post 6169724)

last firmware package: kernel-firmware-20200923_afbfb5f-noarch-1.txz, is missing symbol links.

upstream remove them, could be created by copy-firmware.sh.

This is caused by these 3 commits:

https://git.kernel.org/pub/scm/linux...1448684b6b9fdd
https://git.kernel.org/pub/scm/linux...a8fe0f3f88c9f6
https://git.kernel.org/pub/scm/linux...727749765f88b7

Investigating further, this "WHENCE" file contains other "Link" lines that have always been ignored by the current SlackBuild. As USUARIONUEVO has already mentioned a few times, the SlackBuild should call "make" instead of "mv linux-firmware lib/firmware".

So the proper "request for current" is:

Pat, please apply one of the following 2 patches to kernel-firmware.SlackBuild so that it utilizes the included Makefile to properly install the links:

So this one was my first attempt to purely use the included Makefile. However, by comparing the resulting package it does not install any of the documentation or license files (including GPL-2 and GPL-3!):

Code:

--- kernel-firmware.orig.SlackBuild    2019-09-29 16:48:35.000000000 -0700

+++ kernel-firmware.makeonly.SlackBuild 2020-09-29 07:45:49.232774011 -0700

@@ -49,15 +49,15 @@

 rm -rf $PKG

 mkdir -p $TMP $PKG

 

-cd $PKG

+cd $TMP

+rm -rf linux-firmware

 git clone git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

 # Better determine these the same way as above.

 DATE="$(lynx -dump -width=256 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=HEAD | grep "  committer " | head -n 1 | rev | cut -f 3 -d ' ' | rev | tr -d -)"

 HEADISAT="$(lynx -dump -width=256 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=HEAD | grep "    commit  " | head -n 1 | cut -f 2 -d ] | cut -b 1-7)"

-find . -name ".git*" -exec rm -rf "{}" \+

+cd linux-firmware

 chown -R root:root .

-mkdir -p lib

-mv linux-firmware lib/firmware

+make DESTDIR=$PKG install

 

 # Remove sources for carl9170fw:

 ( cd $PKG/lib/firmware

And this is my second option, which clones the repository into the package directory (like the original SlackBuild) and then runs "make install". Of course "make" spews out lots of warnings because it tries to copy files over themselves. But other than the warnings there is no harm. Additionally, the links get created correctly. This also preserves all the license and documentation files.

Code:

$ diff -u kernel-firmware.orig.SlackBuild kernel-firmware.allfiles.SlackBuild 

--- kernel-firmware.orig.SlackBuild    2019-09-29 16:48:35.000000000 -0700

+++ kernel-firmware.allfiles.SlackBuild 2020-09-29 07:37:00.068972213 -0700

@@ -58,6 +58,8 @@

 chown -R root:root .

 mkdir -p lib

 mv linux-firmware lib/firmware

+cd lib/firmware

+make DESTDIR=$PKG install

 

 # Remove sources for carl9170fw:

 ( cd $PKG/lib/firmware

In my opinion, upstream needs a "make" flag to install documentation and license files...

(If you wanted to get REALLY fancy you could test for the existence of linux-firmware in $TMP and do a "git pull" instead of "git clone", but that also kind of breaks the "clean system" mentality.)

gp.d	09-30-2020 09:28 AM

Quote:

Originally Posted by drumz (Post 6170819)

Code:

--- kernel-firmware.orig.SlackBuild    2019-09-29 16:48:35.000000000 -0700

+++ kernel-firmware.makeonly.SlackBuild 2020-09-29 07:45:49.232774011 -0700

@@ -49,15 +49,15 @@

 rm -rf $PKG

 mkdir -p $TMP $PKG

 

-cd $PKG

+cd $TMP

+rm -rf linux-firmware

 git clone git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

 # Better determine these the same way as above.

 DATE="$(lynx -dump -width=256 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=HEAD | grep "  committer " | head -n 1 | rev | cut -f 3 -d ' ' | rev | tr -d -)"

 HEADISAT="$(lynx -dump -width=256 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=HEAD | grep "    commit  " | head -n 1 | cut -f 2 -d ] | cut -b 1-7)"

-find . -name ".git*" -exec rm -rf "{}" \+

+cd linux-firmware

 chown -R root:root .

-mkdir -p lib

-mv linux-firmware lib/firmware

+make DESTDIR=$PKG install

 

 # Remove sources for carl9170fw:

 ( cd $PKG/lib/firmware

Code:

$ diff -u kernel-firmware.orig.SlackBuild kernel-firmware.allfiles.SlackBuild 

--- kernel-firmware.orig.SlackBuild    2019-09-29 16:48:35.000000000 -0700

+++ kernel-firmware.allfiles.SlackBuild 2020-09-29 07:37:00.068972213 -0700

@@ -58,6 +58,8 @@

 chown -R root:root .

 mkdir -p lib

 mv linux-firmware lib/firmware

+cd lib/firmware

+make DESTDIR=$PKG install

 

 # Remove sources for carl9170fw:

 ( cd $PKG/lib/firmware

Thanks for the patches, that solved my problem with the missing "nouveau"-modules
I've disabled (greylisted) the update for the kernel-firmware package for now
and will watch if there are any changes.
kind regards

USUARIONUEVO

09-30-2020 05:33 PM

ruby in problems

CVE-2020-25613

https://github.com/ruby/webrick/commit/8946bb38b4

patch here --> https://raw.githubusercontent.com/ar.../webrick.patch

USUARIONUEVO

09-30-2020 05:40 PM

oepncl 3.0 is released

OpenCL 1.2 applications should be able to run unchanged on OpenCL 3.0 drivers/devices.
OpenCL 2.x software can also run on OpenCL 3.0 implementations assuming the driver supports all CL2 features used by the application.

opencl 3 , support more hardware and features.

https://www.khronos.org/blog/opencl-...l-sdk-released

WinFree

10-01-2020 11:53 AM

fish
https://fishshell.com/

saxa	10-01-2020 01:04 PM

glib-2.66.1
https://download.gnome.org/sources/g...-2.66.1.tar.xz

ziprun

10-01-2020 04:30 PM

Can I please have an answer if slackware 15 will have OpenJDK 8 or OpenJDK 11? I've asked before, and nobody opposed it, but I just would like a reason against adding OpenJDK to slackware because it's now fully GPL and everything. So there should be no issue with adding it now.

USUARIONUEVO

10-01-2020 06:34 PM

Quote:

Originally Posted by ziprun (Post 6171669)

nothing in slackware needs , then why add a heavy size package ?

ever can install if need from slackbuilds

bassmadrigal

10-01-2020 07:06 PM

Quote:

Originally Posted by ziprun (Post 6171669)

One of the dev team members mentioned earlier in regards to another package is that they aren't experts in all packages, and some packages deserve the better maintenance a dedicated maintainer can provide than what Pat and team can.

If openjdk was added, it is likely that a stable release wouldn't see any major version bumps, meaning when openjdk20 eventually comes out, users would need to replace the stock package with a 3rd-party one (like with php5 in 14.2 and users who want to run php7).

I don't know enough about jdk to know how complicated packaging is or how easy it is to support multiple versions or whether a version bump is potentially disrupting (meaning the version in stable would likely not get the next major release), but if it ends up not being added reasons like these may be cause.

(Plus, as USUARIONUEVO, mentioned, it's not currently a dependency for any programs within Slackware, which gives Pat less of a reason to look into including it.)

sombragris

10-01-2020 09:17 PM

Quote:

Originally Posted by ziprun (Post 6171669)

AlienBob maintains great OpenJDK 7/8 packages, and there are SlackBuilds in SBo for other Java versions, even newer ones. So, Java is available.

TurboBlaze

10-02-2020 02:42 AM

PHP 7.4.11
https://www.php.net/ChangeLog-7.php
https://www.php.net/downloads

ponce

10-02-2020 03:05 AM

Quote:

Originally Posted by TurboBlaze (Post 6171829)

PHP 7.4.11
https://www.php.net/ChangeLog-7.php
https://www.php.net/downloads

I think you missed this

Quote:

Originally Posted by Slackware current's ChangeLog

Tue Sep 29 18:11:08 UTC 2020
n/php-7.4.11-x86_64-1.txz: Upgraded.
This update fixes bugs and two security issues:
Core: PHP parses encoded cookie names so malicious `__Host-` cookies
can be sent.
OpenSSL: Wrong ciphertext/tag in AES-CCM encryption for a 12 bytes IV.
For more information, see:
https://cve.mitre.org/cgi-bin/cvenam...=CVE-2020-7070
https://cve.mitre.org/cgi-bin/cvenam...=CVE-2020-7069
(* Security fix *)

saxa	10-02-2020 08:40 AM

gvfs-1.46.1
https://download.gnome.org/sources/g...-1.46.1.tar.xz

saxa	10-02-2020 01:00 PM

dconf-editor-3.36.7
https://download.gnome.org/sources/d...-3.36.7.tar.xz

But better if we can upgrade to latest 3.38.x

mats_b_tegner

10-02-2020 01:03 PM

Quote:

Originally Posted by USUARIONUEVO (Post 6171321)

ruby in problems
CVE-2020-25613
https://github.com/ruby/webrick/commit/8946bb38b4
patch here --> https://raw.githubusercontent.com/ar.../webrick.patch

Fixed in Ruby 2.7.2:
https://www.ruby-lang.org/en/news/20...-7-2-released/

Didier Spaier

10-02-2020 03:11 PM

Small nitpick: in oprofile.SackBuild, --with-kernel-support is an unrecognized option.

saxa	10-02-2020 03:40 PM

librsvg-2.50.1
https://download.gnome.org/sources/l...-2.50.1.tar.xz

saxa	10-03-2020 09:00 AM

gobject-introspection-1.66.1
https://download.gnome.org/sources/g...-1.66.1.tar.xz

moesasji

10-03-2020 09:28 AM

From the changelog the move to GNU make 4.3 was reverted on the 27th of January. Would it be worth revisiting that seeming that some of the performance improvement seem to big wins?

From the distri silverhaze release notes:

Quote:

make 4.3 fixes performance issues with heavily concurrent builds, e.g. linux (down from over an hour to merely 10 minutes).

kingbeowulf

10-03-2020 09:44 PM

Request bump to kernel 5.8 or newer. I know, I know. 5.4.x is "longterm" but it doesn't look like it will get this fix backported.

[radeonsi/Navi] Google Maps causes amdgpu to crash
https://gitlab.freedesktop.org/mesa/mesa/-/issues/2481

Not sure how many of you have bumped into this issue with amdgpu. When amdgpu pops, X.org and DE freezes. Only remedy is to remoe in (ssh etc) and reboot. My RX 5700 XT has been running excellent except for this one issue (so far!). Sure, google is evil, but their mapping app is really good.

Jeebizz

10-03-2020 10:49 PM

Quote:

Originally Posted by kingbeowulf (Post 6172366)

Not going to happen, --Current will stay at 5.4 or until 5.9 is ready and has a few point releases after, since if I am not mistaken 5.9 will be LTS.

Roman Dyaba

10-03-2020 11:38 PM

for 64-bit: 5.4 is fault, 5.8 is way. no more to say.

TheTKS

10-04-2020 06:36 AM

TigerVNC 1.11.0, please

https://github.com/TigerVNC/tigervnc...es/tag/v1.11.0

upnort

10-04-2020 07:24 AM

Quote:

Not going to happen, --Current will stay at 5.4 or until 5.9 is ready and has a few point releases after, since if I am not mistaken 5.9 will be LTS.

Adding a newer kernel in /extra or /testing would be nice.

tramtrist

10-04-2020 07:51 AM

I have amdgpu as well and would like to see a formal kernel post 5.4 somewhere though I understand LTS is the best case.
5.9 SHOULD be LTS based on the pattern of previous releases and the fact that LTS releases usually come in the last release of the calendar year. Here's hoping for us amdgpu users that 5.9 will make it into 15

cwizardone

10-04-2020 11:37 AM

Quote:

Originally Posted by tramtrist (Post 6172489)

I......5.9 SHOULD be LTS based on the pattern of previous releases and the fact that LTS releases usually come in the last release of the calendar year. Here's hoping for us amdgpu users that 5.9 will make it into 15

Last Sunday Mr. Torvalds said he would, most likely, issue an 8th release candidate for the 5.9 kernel. That means the 5.9.0 kernel will be available one week from today. If he has had a change of heart, we might
see it later today.

Jeebizz

10-04-2020 11:47 AM

Quote:

Originally Posted by upnort (Post 6172485)

Adding a newer kernel in /extra or /testing would be nice.

Honestly at this point, what has occupied my mind is Plasma5 - I want to keep patient on that, but seriously something has to give - there is no word from Pat on where we are on that.....

drgibbon

10-04-2020 04:35 PM

Quote:

Originally Posted by Jeebizz (Post 6172554)

Honestly at this point, what has occupied my mind is Plasma5 - I want to keep patient on that, but seriously something has to give - there is no word from Pat on where we are on that.....

Nope, could just as easily be 2021, etc.

Jeebizz

10-04-2020 04:38 PM

Quote:

Originally Posted by drgibbon (Post 6172613)

Nope, could just as easily be 2021, etc.

Maybe, and also putting that aside - will XFCE be bumped to 4.16 when it is stable, or will it still be at 4.12?

drgibbon

10-04-2020 07:34 PM

Quote:

Originally Posted by Jeebizz (Post 6172614)

Maybe, and also putting that aside - will XFCE be bumped to 4.16 when it is stable, or will it still be at 4.12?