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.
The inference is clearly that Slackware 15.0 will be sticking with the ESR going forwards, otherwise there'd be no reason to mention and smiley-face it.
Barring any confirmation of intent, I guess we'll find out for certain when firefox moves to 92 and Slackware 15.0 doesn't.
Why didn't he include it when it was released then?
Why didn't he include it when it was released then?
Perhaps Pat is waiting for the ESR to diverge from the mainline before branding it as such. Only he knows his intentions at this point. I can only state my interpretation of the changelog comment: YMMV.
The inference is clearly that Slackware 15.0 will be sticking with the ESR going forwards, otherwise there'd be no reason to mention and smiley-face it.
Barring any confirmation of intent, I guess we'll find out for certain when firefox moves to 92 and Slackware 15.0 doesn't.
This is a distinct possibility but based on comments in the change logs when we went back to Firefox proper I'm guessing we will stick with that and not the ESR release. I could be wrong of course.
Code:
Mon Mar 15 19:37:28 UTC 2021
<<snip>>
xap/mozilla-firefox-86.0.1-x86_64-1.txz: Upgraded.
When we first moved Slackware to the Firefox ESR channel, the motivation
was to keep Firefox secure while delaying a requirement for Rust at build
time. Of course, eventually that ESR version reached EOL and we had to
introduce Rust into Slackware 14.2 in order to continue providing updates.
Eventually that also ran into roadblocks as Firefox required first newer
C/C++ compilers, and then finally a newer libstdc++. To continue, we'd
have had to bump GCC to a much newer version, making other maintenance
difficult or impossible. At this point, the latest Firefox has no additional
dependencies beyond those of the ESR version, and it's unlikely that it
will be any more difficult to keep it maintained. I think we all want the
Slackware 15.0 release to be as good as possible, and most users will be
better served if we resume following the latest desktop releases.
Thanks to LuckyCyborg who can always be counted on to give me a friendly
kick in the rear end. :-) Thanks also to ponce for the updated gkrust patch.
This is a distinct possibility but based on comments in the change logs when we went back to Firefox proper I'm guessing we will stick with that and not the ESR release. I could be wrong of course.
This is a distinct possibility but based on comments in the change logs when we went back to Firefox proper I'm guessing we will stick with that and not the ESR release. I could be wrong of course.
Code:
Mon Mar 15 19:37:28 UTC 2021
<<snip>>
xap/mozilla-firefox-86.0.1-x86_64-1.txz: Upgraded.
When we first moved Slackware to the Firefox ESR channel, the motivation
was to keep Firefox secure while delaying a requirement for Rust at build
time. Of course, eventually that ESR version reached EOL and we had to
introduce Rust into Slackware 14.2 in order to continue providing updates.
Eventually that also ran into roadblocks as Firefox required first newer
C/C++ compilers, and then finally a newer libstdc++. To continue, we'd
have had to bump GCC to a much newer version, making other maintenance
difficult or impossible. At this point, the latest Firefox has no additional
dependencies beyond those of the ESR version, and it's unlikely that it
will be any more difficult to keep it maintained. I think we all want the
Slackware 15.0 release to be as good as possible, and most users will be
better served if we resume following the latest desktop releases.
Thanks to LuckyCyborg who can always be counted on to give me a friendly
kick in the rear end. :-) Thanks also to ponce for the updated gkrust patch.
Exactly! The Man said clear his intentions and his reasons. With a lengthy explanation.
But, some people was hit so hard on their beliefs that Firefox for Enterprise must be on Slackware, so they embrace that hard a remark, like someone drowning a stick.
However, there is a much more plausible reason for this remark: the MozJS package is built from the Firefox for Enterprise sources.
So, right now we have mozjs78-78.13.0esr-x86_64-1.txz and is quite plausible that in the near future it will be upgraded to mozjs91-91.0.1esr-x86_64-1.txz or something similar, because of that "New ESR release :-)"
Last edited by LuckyCyborg; 08-19-2021 at 10:44 AM.
But, some people was hit so hard on their beliefs that Firefox for Enterprise must be on Slackware, so they embrace that hard a remark, like someone drowning a stick.
*onto my soapbox*
And some want Slackware to consistently introduce potentially disrupting packages into a stable release.
There is no happy medium. No matter what way Pat chooses to go, someone will be disappointed. I am of the belief that a stable release should be stable and introducing potentially disrupting official packages is not ideal and should only happen when necessary (like if a branch becomes unsupported upstream, but we really needed fixes and it is too much to backport).
If someone wants the new features from Firefox, it is *really* easy to use ruario's script to repackage the official binaries. Since pure-alsa was removed, that makes it even easier to use his script. It even defaults to the desktop release.
If someone wants a newer kernel, it's pretty straightforward to build your own nowadays.
My belief is not from a standpoint that everyone should be running these long term support versions, but that switching away from them should be a choice made by the admin of the system (which I've done for my systems many times). For those using the official packages, they should be able to upgrade them without worry that they're going to have drastic changes unless there's no other way (and then it should be covered on the ChangeLog, like when openssh was upgraded and changed the default for root login).
Keep the potentially disruptive packages in -current.
*off my soapbox*
I'm not personally bothered by these and will continue to use Slackware as I please, but it seems to go against the philosophy of "stable" releases that Slackware has seemed to follow in the past.
Since pure-alsa was removed, that makes it even easier to use his script. It even defaults to the desktop release.
The lack of alsa support is annoying, but easily worked around with apulse.
I use this wrapper script on my CRUX box(which uses mozilla's binary build):
Code:
$ cat usr/local/bin/firefox
#!/bin/sh
# Uncomment and change the following if you want to specify
# a specific ALSA audio device.
#export APULSE_PLAYBACK_DEVICE='default'
exec /usr/bin/apulse /usr/bin/firefox "$@"
I'm not personally bothered by these and will continue to use Slackware as I please, but it seems to go against the philosophy of "stable" releases that Slackware has seemed to follow in the past.
Firefox desktop is not less stable than ESR Edition
Firefox ESR is focused on a very specific audience :
users who do not want or cannot update every few weeks.
91.1esr will only be released when 92.0 will be out
91.2esr, with 93.0
….
92.0esr, with 101.0 (?)
This cycle of release is very suitable for the corporate environment
A pending issue that I already reported sometime ago: since the introduction of PAM, mariadb comes with the file /etc/security/user_map.conf. Unfortunately it is not installed as a .new file, so any user-changes will be overwritten on every update! There is no need to force an update of this file as the original only contains comments.
Last edited by Markus Wiesner; 08-19-2021 at 01:50 PM.
Mesa 21.2 introduced the Intel "Crocus" Gallium3D driver for i965 through Haswell graphics hardware support, PanVK was merged for starting on Vulkan for Arm Mali GPUs, support for alternate GBM back-ends contributed by NVIDIA, continued work on Intel Gen12/Xe Graphics across the board, various RADV Vulkan driver improvements, and much more.
Those "alternate GBM back-ends" means a huge improvement for the Wayland on NVIDIA and Intel Crocus (at least for me) looks working better and faster than the "classic" Intel driver on HD2000 hardware given by my i3 2120T and i3 3220T. It's kinda of Iris Legacy.
Last edited by LuckyCyborg; 08-19-2021 at 04:28 PM.
Hello , i think the konsole build 2 , have bad patch , when no config , initial size are wrong (like 1st run) , i found the 2 original commits and patches for this.
Our patch is only 1 file , i dont know if a "try merged" or what , but not good , there are the originals.
I really interested on this one , read explanations... and please , apply
From c78edfbac49852cec40efd5cbe73c341bc06c5ab Mon Sep 17 00:00:00 2001
From: Ahmad Samir <a.samirh78@gmail.com>
Date: Thu, 29 Jul 2021 18:45:45 +0200
Subject: [PATCH] Fix MainWindow size when there is no saved size
The very first time a user runs Konsole, where is no konsolerc file in $HOME,
there is no saved size to restore, instead use the sizeHint(), which ideally
will be the size set in the default profile (based on lines/columns setting).
Hello , i think the konsole build 2 , have bad patch , when no config , initial size are wrong (like 1st run) , i found the 2 original commits and patches for this.
Our patch is only 1 file , i dont know if a "try merged" or what , but not good , there are the originals.
I really interested on this one , read explanations... and please , apply
From c78edfbac49852cec40efd5cbe73c341bc06c5ab Mon Sep 17 00:00:00 2001
From: Ahmad Samir <a.samirh78@gmail.com>
Date: Thu, 29 Jul 2021 18:45:45 +0200
Subject: [PATCH] Fix MainWindow size when there is no saved size
The very first time a user runs Konsole, where is no konsolerc file in $HOME,
there is no saved size to restore, instead use the sizeHint(), which ideally
will be the size set in the default profile (based on lines/columns setting).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
