It's already been announced that 15.0 will end up on an LTS kernel, which I believe is the best option for the *default* kernel in a stable release. I still believe it should be released with an LTS kernel, but that ship has sailed. I'll likely continue to run kernels that are newer than what will be offered by Pat.

Not everyone appreciates being called a comrade or whatever other names you add to people. Many people associate "comrade" with the USSR and communism (I realize there's other definitions for it, but the reality is most associate it with communism). Why can't you simply call someone their name?

This goes both ways. You were constantly lobbying for Slackware to switch to a stable non-LTS kernel. How is this any different?

Why can't you enjoy the latest technologies if the ESR ends up in extra/? Or if it were to take back over as the primary browser (which wasn't being asked, and I doubt would happen based on Pat's ChangeLog entry), why can't you build it or use ruario's script to download the latest version?

Do you really think it takes that much of Pat's time to throw the next ESR version in the mozilla-firefox folder and run the SlackBuild? I imagine the ESR version is likely to build without changing anything in the SlackBuild. That is not guaranteed at all with newer Firefox versions.

Again, what is your issue with the ESR ending up in extra/? That is all that was being asked. You can still keep your precious latest version in the main tree, but extra/ could contain the ESR for those wanting more stability.

BTW, I don't use Firefox, so I really don't care what happens. However, I do like giving people choice, so I'm not against having both available.

No, you're confusing -current for a stable release of Slackware. That's where your expectations come from. Have a look through the ChangeLog for 14.2 after the release announcement.

There's been 616 patches released for 14.2 so far and 385 of them have been security fixes (62.5%). Most of the other ones I looked at were bug fixes (although, there were 25 timezone updates and 7 updates for xscreensaver that weren't bug/security "fixes"). Pat doesn't typically update programs in stable releases just because there's a new version number. That's what happens in -current.

I didn't express any expectations, did I?
But I admit that comment was inept.

Your expectations were shown by questioning what NonNonBa expects to see from a stable Slackware release. "Confusing Slackware for Debian" shows a misunderstanding of what a stable Slackware release does.

Exactly, because 'it depends ...', it's always good to have a backup option not depending on anything.

Exactly as an generic one, a huge kernel of course depends on the something: at least the way it has been configured. Try to boot using one if the file system for your root partition is missing. If you need a backup option, better keep a known to work other kernel + initrd at hand. Anyway it's up to Pat to decide what he ships in Slackware. I ceased to ship a huge kernel in Slint since February this year and found no reason so far to do otherwise.

I would love to see Multilib as a native option to install on Slackware 15.0, like enabling another mirror on Slackpkg, pretty much as slackpkgplus do. Or a /ml directory(multilib) be added on Slackware64.

Also I think will be good thing to have GCC 11.x on /testing, since it have some nice C++20 features, and some experimental C++23 feature too.
GCC 11.2 is expected to be released in the next week.

https://gcc.gnu.org/pipermail/gcc/2021-July/236674.html

5 members found this post helpful.

Patrick, could you enable the Jack integration on Firefox?

Excuse my ignorance, BUT this also requires adding JACK to Slackware, right?

LTS kernel, yes, but it seems firefox ESR is available only from AUR, which is not surprising from a bleeding-edge distro.

Otherwise, as a privacy improvement, it seems firefox's telemetry can be disabled by default in mozconfig:

Oh yeah, forgot that, but not need if Pat add it to the buildDeps(Pat need use autotools from 90's also nodejs) or, since we have ALSA, PulseAudio, Pipewire, could we get jack2 on /extra? We can get qjackctl and pulseaudio-jack from SlackBuilds anyway. Pipewire could also move to /extra since need do some configuration to start use it.

Seriously? You "forgot" that you intend for JACK to be added to Slackware, because Firefox would NOT work anymore without it?

No offense intended, BUT in some places of the World this is called "pervert demand" as in asking something collateral to impose an action.

Have balls to ask for JACK if you want it, champ!

Honestly, I believe that you do a big confusion regarding WHY the PipeWire was added to Slackware. In fact, it is a hard dependency of Plasma5 and cannot be moved in /extra because PipeWire is NOT optional.

In other hand, this "some configuration" to start PipeWire means to add 3 desktop files to XDG autostart - I for one I believe that they should be added since long time, at least as samples, but this is just my humble opinion...

However, what we need really badly is a split of PulseAudio package, separating its server in in its own package which could be optionally installed.

Because the PipeWire does a better job on doing even the PulseAudio server thing.

Oh, and BTW. PipeWire replaces also quite fine the JACK server, and there results a big simplification on the entire audio stack. For example, there is no need anymore for pulseaudio-jack things.

Ironically, looks like the single way to run a JACK-enabled Firefox without JACK, is to promote the PipeWire as main audio server.

3 members found this post helpful.

pipewire and jack can coexist withour peoblems.

Arround jack , i request at least 4 or 5 times, and no success , jack , can benefit other projects on slackware , like ffmpeg , gstreamer and other multimedia libs/apps.

audacious-plugins (autodetected only rebuild)
ffmpeg (add --enable-libjack)
fluidsynth (autodetected)
gst-plugins-good (autodetected)
mplayer (autodetected)
moc (--with-jack)
sdl2 (autodetected)


and more i lost , sure.

WHY we would need the JACK server when we already have PipeWire which replaces it and it's also a realtime audio server?

Honestly I believe that what we need is to dare to cut the cat tail adding those 3 desktop files to Slackware. That's it.

okey , probably i miss something , im not see options on projects to build with pipewire , like --enablejack , or similar for pipewire , but apparently , pipwire goals to replace jack.


Then these days , im not sure if jack is a good or bad idea ...cause pipewire is part now -current.

That's right, but I asked for guidance from @franzen and @volkerdi about this. These are my grounds:

1. We switched to texlive during this release cycle, back in 2017. Slackware 14.2's TeX setup was tetex, and SBo offered texlive base plus some additional packages (fonts, at one time, docs and extra)

2. Now we are approaching 15.0, with texlive (at least the base setup) in the main distribution, so I think it's fair to ask what is going to be the policy for the extra stuff.

3. It would be good to know whether we could expect that texlive-docs and texlive-extra shall remain in SBo, or be moved to /extra, or whatever. Since we have a wholly new TeX setup in comparison to 14.2, the question, I think, is warranted.

4. In addition, the extra stuff (now texlive-extra and texlive-docs) are from texlive 2019. We're now at texlive 2021, and I think it's fair to have guidance on whether an update to that extra stuff is forthcoming or not, so we can manage our TeX setup accordingly.

That is what I would like to know. If @franzen says there are no more planned updates to texlive-extra and texlive-docs, I'm fine with that. But now we have no clear path forward.