You are not logged in.
Hello Developer, when wie get firefox 67.0.4-1?
Thank you for your work.
Greetz
arch32yes
Last edited by arch32yes (2019-09-26 08:18:34)
Offline
That only appeared upstream yesterday, so just hold on a moment. Although I guess it's actually firefox 67.0.3 you're interested in? That ones a requirement if you work for coinhive and a few other places and don't have a javascript hardening plugin.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
On pentium4 this will happen when the backlog has been build normally, I'll prioritize it a little bit.. :-)
On i686 rust is currently broken in SSE2 and other intrinsics, so I have to see first, how I can
build a rust with rust without this stuff. firefox requires rust.
I start considering dropping firefox/thunderbird for i686 and point to seamonkey, palemoon, trojita for
faster and easier to build software..
Offline
Is seamonkey (and palemoon I think) a long term solution to this? Certainly when I used to use Seamonkey as a reaction against firefox taking over the mozilla suite in the early days, it was just a reskinned firefox with the mail and other components maintained. At the time of writing, it appears to be pre-quantum presently, but have they stated that's a long term goal of theirs, or is it just that they've not caught up yet?
Wikipedia reckons firefox sources post 53.0 need SSE2 to build. Seamonkey's last build was based on firefox 52.9, and the project seems to have hit a little strife. I don't know, but I'd expect that codebase to be close enough to firefox 66 to need the patches we're currently hanging on. Palemoon diverged from firefox longer ago, and I've no idea whether that needs patching or not.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Firefox 68.0.1 now seems to have been available in Arch Linux 64 since 2019.07.20, i.e. since nine days.
Is there any technical reason for Arch Linux 32 only having Firefox 66.0.5, or is it just lack of manpower?
Offline
We need a recomile of rust, but rust has some issues around LLVM and refuses to rebuild, so we might have to bootstrap it.
Offline
Thank you for your feedback - does that apply to both the i686 and the pentium4 architectures?
Offline
Sadly it applies to both i686 and pentium4.. :-(
Offline
There is another aspect to consider:
https://archlinux32.org/buildmaster/bui … 4&arch=any
so packages which are in 'core' or are blocking a lot of other packages (like bluez) must be addressed with
highest priority. Otherwise we risk to accumulate stale packages and worse, unknown bugs of currently
blocked packages.
Biggest other issues currently are rust (as always) and java on pentium4..
Offline
This far at least, there have been no patches in firefox 67 or 68 that I can see that affect me, although if I weren't blocking most scripts, some of the security patches in 68 at least might worry me. So I'm not worried yet, but I can't say that will last for long.
What's the prime cause for these blockers? Is it a dependency maze where it takes a lot of work to calculate what to build first, or would we gain a lot with faster builds due to running newer hardware in 32-bit mode?
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
No, it's mainly lacking brainpower: if rust breaks badly, it has to be bootstrapped from micro to micro revision. This is tedious,
errorprone and badly documented.
Offline
As I see it, we have enough build slaves to cope with the backlog. The buildmaster could be a little bit faster, but it's also not a big blocker
(see the very nice new graph of deep42thought:
https://archlinux32.org/buildmaster/
It shows how long build slaves have to handle build assignments.
Offline
main blocker on i686 is rust - which we need to "bootstrap" from 1.33 to 1.36
Offline
Feel free to use the manjaro32 packages if they help (e.g. https://www.uex.dk/public/manjaro/x32-s … kg.tar.xz)
I could probably also build a plain arch32 package if I thought about it...
Offline
jonathon: thanks for the manjaro package. My build now fails in stage 1 with
error: couldn't load codegen backend "/build/rust/src/rustc-1.36.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so": "libLLVM-8-rust-1.36.0-stable.so: cannot open shared object file: No such file or directory"Any idea where that file should come from? I'll try a symlink to libLLVM-8.so for now - let's see if that "fixes" it ...
Offline
great, now I have
error: couldn't load codegen backend "/build/rust/src/rustc-1.36.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so": "/build/rust/src/rustc-1.36.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so: symbol LLVMInitializeRISCVAsmParser version LLVM_8 not defined in file libLLVM-8-rust-1.36.0-stable.so with link time reference"so the symlink does not work
Offline
The only difference I can see is that I have cbindgen-0.9.0...
Offline
ok, I'll retry with that installed, too
Offline
I'll continue my research on the bug tracker
Offline
yeah. very soon we can create a book from that bug report.. ;-)
Offline
Many thanks for all your feedbacks so far - much appreciated by this enthusiastic Arch Linux 32 user.
Please excuse my naivety, but why is building Rust such a problem in Arch Linux 32, compared to Arch Linux 64 where Rust 1.36 has been available in Extra since 2019-07-23?
Are there technical differences which make building 32-bit Rust more difficult than 64-bit, or is it simply a manpower issue?
Offline
Rust has a convoluted build system building in one big unreadable Python script (x.py) and pulling all kind
of binary microlibraries from the rust webpage with cargo.
Every rust version is at most compatible with the previous minor rust version.
non-SSE2 and i486 builds where not available upstream, so you have to go through a bootstrapping process,
in the worst case from mrust to rust 1.19 all up the versions to the current rust version.
rust hit a LLVM-7 LLVM-8 problem on i686, we had packages before for rustc, no problem.
It's a combination of man power, knowledge and documentation problem.
Offline
Many thanks again for your quick and thorough feedback - much appreciated !
Offline
Have also a look at:
https://news.ycombinator.com/item?id=18686720
and
This corner of software/compiler and distribution development is one and needed only by a few persons on this
planet, but it has important consequences, if things are not properly done. :-)
Offline
I'm glad to hear it's not only us suffering from rust's decisions on software development, and firefox's decision to use rust.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline