Requests for -current (14.2-->15.0)

Jeebizz · 10-01-2019, 12:38 PM

Quote:

Originally Posted by olear

Maybe, but releasing Slackware 15 with kernel 4.19 or 5.4 would be a bad decision in regards to security down the line.

I can get security updates to the kernel I run on Slackware 14.2 until 2022. Getting ~2 years on Slackware 15.0 is not good IMHO.

Looking back Slackware 15 should have been released (early) 2018 with kernel 4.14 (EOL 2024).

I would say that is the main issue. I think that this development cycle has been longer than usual, but again there are circumstances that caused that - software inclusion mainly. .

Didier Spaier · 10-01-2019, 01:02 PM

Quote:

Originally Posted by Jeebizz

I hope I don't run into that on my production machine when I use cfdisk to wipe the partitions itself (writing to disk and the old fs still stays even after reboot)

Using cfdisk you create or modify a partition table, recording where each partition begins and ends and the partition's type. This doesn't change the content of the partitions, including the file systems, in any way. To change a file system type you have to set up a new one for the partition.

Didier Spaier · 10-01-2019, 01:06 PM

Let Pat decide which kernel he includes in any Slackware version, and upgrade it as he sees fit. If this choice does not fit your needs, just build and install another one.

Jeebizz · 10-01-2019, 01:24 PM

Quote:

Originally Posted by Didier Spaier

Quote:

Originally Posted by Jeebizz

I hope I don't run into that on my production machine when I use cfdisk to wipe the partitions itself (writing to disk and the old fs still stays even after reboot)

Using cfdisk you create or modify a partition table, recording where each partition begins and ends and the partition's type. This doesn't change the content of the partitions, including the file systems, in any way. To change a file system type you have to set up a new one for the partition.

Right, but I know for a fact I cleared the partition in cfdisk, then chose to format sda2 as f2fs and it didnt stick, so I dont know..

igadoter · 10-01-2019, 02:00 PM

Quote:

Originally Posted by Jeebizz

I don't know why the settings were not sticking, because I know I made sure to write to disk in cfdisk - I literally had to delete the VM and start a new, and this time I created the partitions - I can't explain why when I wiped the partition types and wrote to disk, it kept reverting back as being labeled as jfs.

Now you have f2fs partition. Still got troubles with installation on this partition?

Jeebizz · 10-01-2019, 03:09 PM

Quote:

Originally Posted by igadoter

Quote:

Originally Posted by Jeebizz

I don't know why the settings were not sticking, because I know I made sure to write to disk in cfdisk - I literally had to delete the VM and start a new, and this time I created the partitions - I can't explain why when I wiped the partition types and wrote to disk, it kept reverting back as being labeled as jfs.

Now you have f2fs partition. Still got troubles with installation on this partition?

Yes, installation was successful.

bassmadrigal · 10-01-2019, 08:22 PM

Quote:

Originally Posted by olear

Since Slackware stable is supported over several years the only sensible versions (right now) would be 4.14 or 4.9.

Personally, I think this would be a bad solution. It limits hardware support on a new release and would make Slackware 15.0 not be the stellar release that its users deserve. No previous version of Slackware was released with the knowledge LTS kernels might get support past the 2 year mark (14.2 was released in 2016 and 4.4 was announced to have 6 years of support in 2017... when 14.2 was released, it was expected the 4.4 kernel would have 2 years of support by kernel.org).

Keep in mind, 6 year LTS kernels are still relatively new. It was first announced 2 years ago with the 4.4 kernel... only about 5 months before 4.4 was expected to go EOL (it was initially going to be EOL Feb 2018 and they announced in Sep 2017 that it would have 6 years of support). And 4.14 was initially released with only 2 years of guaranteed support, but that was recently extended to 6 years. It is very possible the same could happen for the 4.19 and the 5.4 releases. The fact that Slackware 14.2 ended up with a 6 year kernel in a time when the development of the next stable release has taken longer than the normal 2 year LTS period of a kernel is straight up luck. 14.2 wasn't released with the expectation of 6 years of kernel support, and I hope Pat doesn't release 15.0 expecting a 6 year kernel support. I hope that Slackware doesn't get to the point where the next stable is regularly released more than 2 years after the previous stable.

Also, keep in mind that the length of development time for 15.0 is unprecedented in Slackware history. We don't know whether 15.1 will keep a similar extremely extended development cycle or get to something a bit more useful, like maybe 1-2 years of development time. I have a feeling it is because Pat is working on something potentially disruptive in the background like including PAM or QT5/KDE5 and he needs it to be at a certain level before he's willing to push it out to the masses (I imagine him getting pulseaudio to work so seamlessly for most users is why 14.2 took so long), and that took a lot more time than he expected... especially with all the CPU security issues that have popped up over the last year and a half and the crazy amount of patches that have been pushed out to various software stacks. If he's able to get everything working smoothly with 15.0, hopefully there won't be anything super disruptive in future releases and he can push out 15.1 quicker.

It would've been nice to get an interim 14.2.1 release with a few things upgraded to take advantage of newer hardware, but that never happened. Hopefully whatever Pat is brewing is getting close for him to make public and could lead to us getting a 15.0 release soonish.

Long story short, with the time we've been waiting for 15.0, it should be a stellar release supporting the latest and greatest... not handicapped by putting in a 2+ year old kernel, just to ensure we can get 6 years of kernel updates.

bassmadrigal · 10-01-2019, 09:28 PM

I should probably mention that these are just my personal opinions on the matter. Obviously, Pat is going to do what he feels is best for Slackware. I don't know if he factors expected support from kernel developers into his release cycle. It is very possible that the extended support of the 4.4 kernel is what made him feel that he could push out the 15.0 release further to ensure it is worth the 15.0 label.

franzen · 10-02-2019, 04:01 AM

Quote:

Originally Posted by franzen

While you are on it

Just to mention it, from llvm.SlackBuild

Code:

  find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null

may become

Code:

  find . -type f -exec file '{}' \+ | grep "executable" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null

Also to mention:
\+ omits problems with filenames containing whitespaces etc., just like "-print0 | xargs -0".

and from the find manpage:

Code:

 -exec command {} +
   [...]
   If find encounters an error, this can sometimes cause an immedi‐
   ate  exit, so some pending commands may not be run at all.  This
   variant of -exec always returns true.

There are some BuildScripts with a trailing '| true' after 'find' which could be omitted, as it feels like a workaround for me.

GazL · 10-02-2019, 05:02 AM

Just a couple of points on using '+' on find in case some folk don't know them:

'+' has no special meaning to the shell, so unlike ';' the escape is unnecessary on all these finds people are posting.

Also worth remembering, + only works with commands that may take multiple file arguments, for example one couldn't do a find /tmp/somedir -type f -exec unlink {} + but a \; based variant would be ok.

Apologies to any grannys I've just tried to teach to suck eggs.

ehartman · 10-02-2019, 06:32 AM

Quote:

Originally Posted by franzen

Just to mention it, from llvm.SlackBuild

Code:

  find . -type f -exec file '{}' \+ | grep "executable" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null

You can even combine the two greps into one as

Code:

find . -type f -exec file '{}' + | grep "ELF .* executable" | <rest of the commandline

And, as others already have remarked: the \ in front of the + isn't needed (so I have removed it).

GazL · 10-02-2019, 06:47 AM

or, given that there's also a 'cut' in that pipeline, use a sed instead of both greps and the cut. Something along the lines of:

Code:

sed -e '/: ELF.*executable,/s/\(.*\):.*/\1/'

franzen · 10-02-2019, 09:02 AM

Quote:

Originally Posted by GazL

Apologies to any grannys I've just tried to teach to suck eggs.

In case the buildscripts are gonna be changed, it's the right time to throw hints in.
Things might be overseen, regardless if the knowledge already exists for decades.

jostber · 10-02-2019, 01:40 PM

Ruby 2.6.5 is released:

https://www.ruby-lang.org/en/news/20...-6-5-released/

ponce · 10-02-2019, 01:52 PM

Quote:

Originally Posted by jostber

Ruby 2.6.5 is released:

https://www.ruby-lang.org/en/news/20...-6-5-released/

maybe you missed it, it's already in current

Code:

Wed Oct  2 06:46:20 UTC 2019
[...]
d/ruby-2.6.5-x86_64-1.txz:  Upgraded.
  This update fixes bugs and security issues:
  A code injection vulnerability of Shell#[] and Shell#test.
  HTTP response splitting in WEBrick (Additional fix).
  A NUL injection vulnerability of File.fnmatch and File.fnmatch?.
  Regular Expression Denial of Service vulnerability of WEBrick's Digest
  access authentication.
  For more information, see:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16255
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16254
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15845
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16201
  (* Security fix *)