Please bear in mind that the entire discussion is about the Firefox from slackware-current, aka the development tree.

And, no one ask about adding something in the stable Slackware 14.2 or any other released version ...

So, now I am in measure to give new details about "the Rust issue"...

Long story short, Patrick Volkerding said, several months ago, that the Rust compiler looks being unable to compile itself without the help of those binaries shipped by https://www.rust-lang.org/en-US/othe...rs.html#source

There: http://www.linuxquestions.org/questi...ml#post5699437

And he was more precise, when I asked him for details: http://www.linuxquestions.org/questi...ml#post5699796

Then, I was curious if today I can rebuild the Rust compiler and Cargo packages, while using the already built and installed ones, without the help of the official binaries.

That, knowing/supposing that the Rust compiler (and its ecosystem) evolve very quickly, pushed by the Mozilla Foundation and Samsung Corporation. Also suspecting that even our Slackbuilds can evolve meantime.

And, for the sake of consistency, I decided to repeat the process 10 (ten) times, then to use the final installed Rust packages (if manage that rebuild to end with success) to build the (current) Firefox 55.0.2.

How the Rust packages from Slackbuilds.org have the feature of using the installed Rust, if any, I ran in a 10 times loop the following commands:
That make the SBOPKG to compile Rust and Cargo packages, then (re-)install (or upgrade) them. The final?

The Rust and Cargo packages was successfully built using the system available Rust compiler, and the process completed successfully, on expected TEN times.

Then, now I am 100% sure that today the Rust compiler would rebuild itself, while using a Slackware native Rust compiler, if are used those:

https://slackbuilds.org/repository/1...elopment/rust/
https://slackbuilds.org/repository/1...lopment/cargo/

Finally, using the Rust packages from the tenth rebuild, I built the Firefox 55.0.2, and I use it right now, as everyone can see in the attached screenshot.

PS. For those who want to repeat my adventures, I suggest them to build and install those two Rust packages, then to build the latest Firefox, while just saving the source code tarball in the Firefox's SlackBuild directory; no changes on files are required...

Attached Thumbnails

 

3 members found this post helpful.

altho I am not a slacker, I am running firefox from unpack on both a debian derivative called MX 16 and Tinycore Linux both 64 bit.

unpack means you download the package and unpack it so

/home/$USER/firefox/firefox will run as long as you have loaded the running dependencies and/or set up a 64 bit environment

if you try

it will tell you if you are missing any running dependencies (true for tinycore)

and may need to setup a link for 64 bit /lib64....YMMV

2) the advantage of this is......smaller downloads to update point releases
the integer release will be big but you always get it faster than the package maintainers

We actually have a forum member, ruario who created a script that will download the latest firefox, repackage it into a Slackware package, and optionally install it. It's basically a more automated version of yours that upgrades the system-installed package.

However, some users prefer to use their own compiled version, so they don't use this script.

there is nothing to compile, it unpacks and in TC there is a "get" script that will interact with the user's locale to offer their locale version of firefox and pack it into a TCZ file, which is close to the link to ruario's script.

in Slackware, I am pretty sure (well I am pretty HAHA) you don't need to do that
--just download it
---unpack it
--sym link it to your executable pathway which I presume for slackers is /usr as in

in case you already have a FF-ESR or other packaged version already installed, one would need to remove that package so no conflicts

Hell - I'll bite. Just to see what will happen.

And also because nobody else is reacting to it.

It's this bullshit that pushed me away from firefox and friends several years ago. Back to ELinks et al. "elinks -dump ..." shows you very clearly what a load of bullshit is on today's web pages. I am using more ncurses and command line programs now. Really the only gui programs I use often these days are vlc and smplayer/mplayer.

I am not participating in the rat race of hardware and software upgrades. So it doesn't matter what kind of hardware I am using right now. Developers and certain users here on LQ (you know who you are), and CEOs, et al should get out of their ivory towers once in a while and see what regular people are actually using and doing.

And since we're on the subject - 64-bit will not become important until sometime in the 2030's when 32-bit runs out of time. With BIOS you can use your computer as you please. With EFI/UEFI you are only allowed to do what Microsoft et al allow you to do. Therefor I will avoid it for as long as I can.

Listen to CEOs?? wtf! Nobody knows what's best for me than me. Me alone. I do as I damn well please. And that includes making mistakes.

Hell - I don't even care what society at large says one should do these days if one does not want to be outside of society. I even quit a job once cause the person I worked with wanted to do more social marketing aka facebook et al. Which is something I refuse to touch even with a ten foot pole.

So ... Listen to CEOs?? Over my big dead ass! When it comes to my computer and my life - yes - my competence is higher than some ceo's. Hell - some of these CEOs were not even born yet when I already programmed computers.

Especially not CEOs - there are better people incl. here on LQ to get your answers from.

Mark Zuckerberg? oh my ... a prime example of what not to be and not to do.

But this statement of yours does explain a lot about you.

You need to choose better people in your life to get answers from.

Many years ago my elders taught me that if everybody else jumps off a cliff, do not follow them blindly but think for yourself. Make up your own damn mind.

@Didier - I have a pretty thick skin. I've been called worse. And I do agree - about the slight nuances in the English language.

2 members found this post helpful.

This is wrong.

BIOS was originally proprietary of the IBM PC and was reverse engineered, cf. https://en.wikipedia.org/wiki/BIOS

But UEFI is an open standard[1]. The specification is publicly available and free. You don't have to register to download it, so do yourself a favor: http://www.uefi.org/specifications. Happy reading, and feel free to come back here to ask any question.

[1]Here I use he word "standard" with its common meaning, not pretending that the specification has been endorsed or approved by a standard body like ISO. Fortunately as else you'd have to pay to read it

1 members found this post helpful.

He's probably confusing UEFI with SecureBoot, which is a feature in UEFI you can simply turn off if you do not need it.

1 members found this post helpful.

I usually don't say this - but in this case I am replying - Whatever!

Just look at how many questions there are still about EFI/UEFI/Secureboot not working - users trying elilo, refind to make things work and then ending up switching to legacy mode. Ol' fashioned lilo just worked (w/ ol' fashioned bios).

And I used to have an IBM manual with assembly listing of the bios:
The technical reference manual is what contained the BIOS listing - I learned a lot from it.
http://www.vintage-computer.com/ibm_pc.shtml
http://www.vintage-computer.com/images/ibmdocs.jpg

Attached Thumbnails

 

That was the era of the IBM monopoly, then replaced by the Microsoft monopoly, maybe soon superseded by an Apple + Google duopoly or just by a Google monopoly. So, what?

Let's go back on tracks. What is the topic, by the way?

The latest Pigzilla Firehog from slackware-current, with the Rust "issue" and how it will eat your dog?

Microsoft tightens Windows 10's Secure Boot screws: Where does that leave Linux

Eric - nothing personal. But ...

I am not confused. I am just sick and tired of all this new shit that only makes things more complicated for users.

All this does is that people/users have to spend more money. A rat race of hardware and software upgrades. For no good reason.

There are bugs in the software that people use everyday, which they would much rather have fixed. Instead of adding new features that nobody really asked for. Mozilla Firefox is one example of this. EFI/UEFI being another example. There are issues in vim's todo list, dating back to 2009.

Mozilla Firefox changing the add-on api to webextensions. Add-on signing another example. Many users will not be able to continue using the add-ons they have come to rely on. Add-on developers throwing in the towel - pentadactyl is one example.

Etc, etc, etc ...

The latest one being: Vim now supports quitting Emacs, a feature Bram Moolenaar calls "very important".

2 members found this post helpful.

rust - as in:

Given sufficient time, oxygen, and water, any software will eventually convert entirely to rust and disintegrate.

1 members found this post helpful.

I think you misunderstood what I said. ruario's script will download the pre-compiled Firefox from Mozilla and will repackage it into a Slackware package that a user can install to replace the stock package. There's no compiling needed. This also allows Firefox to be installed system-wide and allows any users to use the latest version. If we were to just download and unpack it in our home folder, other users would be unable to use Firefox (unless you open up permissions to your home directory).

However, I stated that some prefer to have packages that were compiled on a Slackware machine, so they likely have no desire to use ruario's script.

Some UEFI implementations are buggy, just as some BIOSes are buggy. I've ran into some weird issues with BIOS. It isn't as pristine and bug-free as we're wanting to remember.

I will say that I don't have much experience with UEFI and I shyed away from it for a long time because of posts on this forum and not wanting to subject myself to the "horrors" I've seen on here. However, a few weeks ago I decided to play with it and see how it works. It was much simpler than I was expecting... and I was even doing it on an NVMe drive (which did take some maneuvering, but that wasn't a UEFI issue, but rather an issue with the tools not being updated early enough to support NVMe drives). In a matter of 20 minutes, I felt as comfortable with elilo as I do with lilo (which makes sense because they have very similar conf layouts).

I know my experiences don't match everyones, but for all the posts on the forum documenting the issues, there's probably many more that don't post their success stories, because it "just worked" and there was no need to run to a forum to post that.

1 members found this post helpful.

yes I assumed as the OP was talking about rust.....and updating rust that slackware FF was compiled from source.

I suppose I could read your slacker's pkg script but where is the fun in that?

true....my way requires an unpack for each user or ......unpack initially done by root to somewhere like /usr/share and then make that folder rwx for all