LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   [Suggestion] Mozilla Firefox ESR for Slackware 14.1 (https://www.linuxquestions.org/questions/slackware-14/%5Bsuggestion%5D-mozilla-firefox-esr-for-slackware-14-1-a-4175477484/)

sardinha 09-17-2013 01:26 PM

[Suggestion] Mozilla Firefox ESR for Slackware 14.1
 
Suggestion for Slackware 14.1 browser with stability, security and long support in mind: Firefox Extended Support Release 24
ftp://ftp.mozilla.org/pub/mozilla.or...eases/24.0esr/

kikinovak 09-17-2013 02:44 PM

Quote:

Originally Posted by sardinha (Post 5029368)
Suggestion for Slackware 14.1 browser with stability, security and long support in mind: Firefox Extended Support Release 24
ftp://ftp.mozilla.org/pub/mozilla.or...eases/24.0esr/

+1 on that.

Col-Panic 09-17-2013 05:23 PM

Quote:

Originally Posted by kikinovak (Post 5029405)
+1 on that.

+another. Seems like it would be a much better fit for Slackware than going with Mozilla's current mainstream rapid release versions.

TobiSGD 09-17-2013 07:00 PM

I would like to see Slackware keeping up with new Firefox releases. ESR is already available via SBo for anyone who wants to use that.

hitest 09-17-2013 07:49 PM

Quote:

Originally Posted by TobiSGD (Post 5029551)
I would like to see Slackware keeping up with new Firefox releases. ESR is already available via SBo for anyone who wants to use that.

Agreed. It is a selling point for Slackware 14.1 to have up to date applications at release time.

sardinha 09-18-2013 03:31 AM

Quote:

Originally Posted by hitest (Post 5029564)
Agreed. It is a selling point for Slackware 14.1 to have up to date applications at release time.

ESR is an up to date version just with a longer cycle release, it's great for the stable distro version because has security and bug fixes in "LTS".

Thanks Patrick for update Firefox to 24 ESR in 14.1 Beta!

TobiSGD 09-18-2013 03:45 AM

ESR is an up to date version only for now, after the next release of Firefox it will miss features of the new versions.
I personally don't like the switch, for me that is a major drawback. For example, if Mozilla had decided to make 23 instead of 24 the ESR then the users of the ESR version never would have got H.264 video acceleration.

zordrak 09-18-2013 03:52 AM

Entirely agree. Whether the standard package is available in /extra or the ESR is in /extra; the option to choose here seems important.

H_TeXMeX_H 09-18-2013 05:09 AM

I just switched to 24.0 ESR and things broke. I prefer ESR because I have to fix things less often, rather than every week or two.

TobiSGD 09-18-2013 05:47 AM

Quote:

Originally Posted by H_TeXMeX_H (Post 5029839)
I just switched to 24.0 ESR and things broke. I prefer ESR because I have to fix things less often, rather than every week or two.

Since I use Slackware I never had to fix a broken Firefox.

H_TeXMeX_H 09-18-2013 06:35 AM

I just had to fix it again, just now, and that may not be the last of it. Most of the fixes are UI fixes. For example, for some unknown reason downloads didn't show up at all. I had to delete my profile and create it from scratch. Just now I found that the theme I was using somehow added close buttons to all my tabs in this version of firefox, so that had to be replaced.

This hassle is caused by Firefox devs copying Chrome and its release schedule. Stuff breaks all the time and I have to fix it the way it should be. I'm not going to do this every week or two, so I'm sticking to ESR. If nothing seems to break for you then continue doing what you are doing, however not long ago Pat V. had to switch to ESR because FF did really break:
http://www.linuxquestions.org/questi...sr-4175467933/

TobiSGD 09-18-2013 06:45 AM

If that was a bug in Firefox or in KDE is still not known, but I would assume that it was in KDE. At least PV reported it to KDE, not Firefox.

marnold 09-18-2013 08:25 AM

-infinity+1

I felt that the downgrade to 17.0ESR was a massive step backwards. It lost functionality and also became less stable to boot. As a result, I've started using Chrome more.

With that said, I saw this in the -stable changelog:

Quote:

xap/mozilla-firefox-24.0esr-x86_64-1.txz: Upgraded.
I don't know if that means that Pat will be going with an ESR version for 14.1 or not.

Stuferus 09-18-2013 02:52 PM

i agree with TobiSGD, ill would also like to have the latest firefox.. not a fan of ESR here too.

kikinovak 09-18-2013 03:15 PM

Quote:

Originally Posted by TobiSGD (Post 5029795)
For example, if Mozilla had decided to make 23 instead of 24 the ESR then the users of the ESR version never would have got H.264 video acceleration.

Not never. They'd just have to wait for the next ESR release.

TobiSGD 09-18-2013 05:52 PM

Quote:

Originally Posted by kikinovak (Post 5030220)
Not never. They'd just have to wait for the next ESR release.

OK, I shouldn't have said never, in the worst case they would have to wait about a year (ESRs are released annually). In the case of better hardware video decoding support, which was added with Firefox 24, this would mean that users with older hardware would have to wait that long for getting better performance. The best option of course would be to have both versions available, one in the normal tree, one in /extra.

ruario 09-19-2013 01:11 AM

It is not especially hard to repack the binary builds that Mozilla produces (I do it), so if you don't want ESR you don't have to use it. If you do repack rather than recompile the KDE/FF bug does not appear.

TobiSGD 09-19-2013 08:44 AM

As far as I know the KDE/FF bug only appeared in 14.0, but not in -current, so this shouldn't be a problem anyway. The problem with repacking the binaries is that they are, AFAIK, not compiled with PGO, which means they come with sub-standard performance.

ponce 09-19-2013 08:49 AM

two small clarifications:
- the bug actually is between oxygen-gtk2 (the default gtk theme under kde) and firefox >= 22.0 on slackware64-14.0 (14.0 32bit and current/14.1 are not affected): it manifests also under xfce if you use the oxygen-gtk2 theme with it (firefox segfaults);
- the binaries from mozilla are, AFAIK, built with PGO.

ruario 09-19-2013 09:12 AM

Quote:

Originally Posted by TobiSGD (Post 5030703)
As far as I know the KDE/FF bug only appeared in 14.0, but not in -current, so this shouldn't be a problem anyway. The problem with repacking the binaries is that they are, AFAIK, not compiled with PGO, which means they come with sub-standard performance.

the Mozilla binaries use PGO.

ruario 09-19-2013 09:52 AM

actually it is the Slackware binaries that are not compiled with PGO. from http://ftp.uninett.no/pub/linux/slac...fox.SlackBuild

Code:

# PGO is disabled by default:
PGO=${PGO:-no}


burdi01 09-19-2013 10:10 AM

1 Attachment(s)
To use the non-ESR version of firefox I distilled the infrastructure from the xap/mozilla-firefox-24.0esr-x86_64-1.txz package into the attached package (rename .txt to .txz), the slack-desc of which reads:
Code:

mozilla-firefox-infra: mozilla-firefox (Mozilla Firefox Web browser) infrastructure
mozilla-firefox-infra:
mozilla-firefox-infra: Just untar the .tar.bz2 as retrieved from e.g.
mozilla-firefox-infra:  http://mozilla.mirrors.tds.net/pub/mozilla.org/firefox
mozilla-firefox-infra:    /releases/latest/linux-x86_64/
mozilla-firefox-infra:  into /usr/lib64 
mozilla-firefox-infra:
mozilla-firefox-infra: Visit the Mozilla Firefox project online:
mozilla-firefox-infra:  http://www.mozilla.org/projects/firefox/
mozilla-firefox-infra:

Download the firefox-24.0.tar.bz2 file, removepkg mozilla-firefox (your settings and addons are preserved), installpkg mozilla-firefox-infra and untar the tar.bz2 file. You should now be able to start firefox as usual.
Note that to install a new firefox version you just have to replace the /usr/lib64/firefox directory.
Note too that the .tar.bz2 can also be a localized one.
:D

ruario 09-19-2013 10:45 AM

Quote:

Originally Posted by burdi01 (Post 5030759)
To use the non-ESR version of firefox ...

here, I'll make even easier. run this:
www.panix.com/~ruari/latest-firefox

TobiSGD 09-19-2013 02:04 PM

Quote:

Originally Posted by ruario (Post 5030725)
the Mozilla binaries use PGO.

Quote:

actually it is the Slackware binaries that are not compiled with PGO. from http://ftp.uninett.no/pub/linux/slac...fox.SlackBuild
Ok, I stand corrected on that, I remembered it the other way around.

Quote:

here, I'll make even easier. run this:
www.panix.com/~ruari/latest-firefox
Thanks for that.

burdi01 09-19-2013 04:00 PM

Quote:

here, I'll make even easier. run this:
www.panix.com/~ruari/latest-firefox
Just a nitpick: Slackpkg and friends will want to replace that latest firefox with the package in the repository. You should name your package mozilla-firefox-latest or something like that.
:D

gegechris99 09-19-2013 04:30 PM

Quote:

Originally Posted by burdi01 (Post 5030970)
Just a nitpick: Slackpkg and friends will want to replace that latest firefox with the package in the repository. You should name your package mozilla-firefox-latest or something like that.
:D

/etc/slackpkg/blacklist is your friend :)

ruario 09-19-2013 04:49 PM

Quote:

Originally Posted by gegechris99 (Post 5030977)
/etc/slackpkg/blacklist is your friend :)

Exactly! ;)

burdi01 09-20-2013 03:35 AM

Quote:

/etc/slackpkg/blacklist is your friend :)
Of course blacklisting the package will stop it from being overwritten by the repo version. But why requiring an additional action (the blacklisting) instead of a simple change (change the package name) to the script?
:D

ruario 09-20-2013 04:01 AM

Because that is the entire point of blacklisting, to allow you to prevent slackpkg from manipulating packages you don't want it to touch. Blacklisting is already in wide use in the Slackware community. Why make a new system based on obscure naming, which seems flawed. Off the top of my head:
  • How do I easily get my system back to having only original versions of standard packages (with blacklisting I can just wipe blacklist and upgrade-all)?
  • How am I supposed to remember the various obscure names if I start doing this a lot (in the case of blacklisting I need only look in/edit one file should I need to change anything)?
  • If Slackware proper ever uses my package name convention my custom package would get wiped anyway.

I'm not planning on changing my script in this regard but if you would like to use it and decide you would prefer go down the nonstandard name route by all means edit it locally. ;)

burdi01 09-20-2013 06:54 AM

OK, let us agree to disagree then.
Kind regards, Dick :D

kabamaru 09-20-2013 08:34 AM

Quote:

Originally Posted by burdi01 (Post 5031225)
Of course blacklisting the package will stop it from being overwritten by the repo version. But why requiring an additional action (the blacklisting) instead of a simple change (change the package name) to the script?
:D

By creating package-versionX and the use of blacklisting you can just upgradepkg package-versionX. By renaming it to package-yourstring-versionX you're creating a package that conflicts with a stock one which has a different name. It's a bit messier IMO. By taking the extra step of blacklisting the package you won't have to worry about having the stock one re-installed accidentally e.g. by slackpkg, and have your files overwritten. Plus, it's easier to keep track what's going on in your system.

ruario 09-20-2013 10:00 AM

Indeed it is pretty standard to tell the difference between an official package and a non official one by using a tags. Many people (myself included) use their initials, others use something that makes sense to them, e.g. AlienBob uses 'alien' and SlackBuilds.org uses '_SBo'. This makes it easy to blacklist groups of packages from the same author (or project). It seems pretty odd to introduce a new method when the current one has (and continues to) work pretty well after all these years.

EDIT: Tags also make it easier to list collections of packages by the same author/project.


All times are GMT -5. The time now is 09:00 PM.