Pyra without decent web browser?

[SneHebNor]

One of the main reasons for buying a Pyra is the ability to browse the web.
This is much more important to me than using Pyra for playing games - if I want that at all.
Unfortunately, browsing the web might become difficult.
The Pyra will run the Debian armhf architecture.
The Rust programming language is, AFAIK, not supported on that architecture.
However, in the near future, new Firefox versions will require Rust to build [*].
Not only a stable version of Rust, but the latest version of it at the respective moment.
People tried to convince the Firefox developers to wait with using Rust until the language is stable and supported on all important architectures, but Mozilla has other priorities.
That does mean, that one has either to use an older version of Firefox, maybe with unfixed security bugs, or to use another web browser.
So far, Chromium is supported on Debian armhf, but I'm not convinced of it, because it seems to have serious bugs, including missing source code and phoning home.
Other graphical browsers such as midori, or console browsers such as w3m, are not bad, but not all web pages or web applications do support them, esp. online banking and online shopping.
Which free and modern web browser will we have on the Pyra - or on any other 32-bits ARM hardware?

[*] https://bugzilla.mozilla.org/show_bug.cgi?id=1284816

 

[slaeshjag]

armhf is a "Tier 2" architecture from what I can tell. For whatever it's worth, nothing but x86/amd64 is listed as "tier 1" on that page.

 

[Linux-SWAT]

Seamonkey is as good as Firefox.

 

[Klumpen]

Just use PaleMoon, it's based on an old version of Firefox and I prefer it anyway.

 

[dTal]

I wouldn't worry too much. ARM is the best supported architecture for Rust after x86, and Firefox does after all have an Android version (that uses Rust and targets ARM). Firefox 52 is LTS, so there's plenty of time for any issues to be resolved.

ARM is too important a platform for Firefox to abandon completely.

 

[sulu]

@SneHebNor:
Thanks for the heads-up! That scenario really seems to have potential for some major headaches.

As it stands we should be safe as long as Firefox ESR 52 is supported by Mozilla, as this is the last version that will not depend on Rust.
After that it will depend on whether Rust upstream comes up with a usable strategy to support armhf. Currently they don't seem to have that. They can get it working on armhf for now, but they seem to lack the understanding of what responsibility comes with supporting it in the long-term, as especially Debian does. It really depends on whether Rust can grow that understanding.
At least some peopple at Debian seem to be willing to provide Rust with the necessary infrastructure to test their builds on actual hardware instead of qemu.
Assuming that gets sorted out it might still be a PITA for Debian to maintain Firefox, because not only will Firefox have to be maintained in the fast-moving security repo, but so will have to be Rust and probably as a dependency LLVM.

The alternatives to Firefox don't look promising either.
Chromium has its very own problems, as you pointed out. In fact, judging from my own (pretty dated) experience with compiling Chromium on armhf and my subsequent contact with the package's Debian maintainer I'm not convinced, they really tested that package very thoroughly back then (I think it was during the Wheezy freeze).
All the other full-featured* browsers in Debian I know of are based on Webkit, which seems to be in very bad shape security-wise [1]. I guess it's fine to passively browse the web (like looking up Wikipedia articles) with them, but I wouldn't trust them with my passwords**.

As for SeaMonkey, afaik, they regularly fork Firefox ESR. So they'll run into the same Rust problems on armhf as Debian does with Firefox once ESR 52 loses support.
I'm not sure about the situation in PaleMoon. The sources are in MPL 2.0 but it's not in Debian. I think this was discussed in some RFP bug report in Debian and the reason why it's not included is, that it can't be legally redistributed by Debian without changing the name and the artwork, which didn't seem worth the effort back then. Maybe that would change if Firefox really turned out to be unmaintainable on lots of architectures, but I don't think Debian would like that solution.


*) which in my book means: GUI + full CSS and JS support
**) I'm talking about entering passwords in forms, not letting the browser store them.
[1] https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/

 

[canseco]

QupZilla and Otter have recently changed from QTWebkit to QTWebEngine (using Chromium Blink rendering engine).

And with QT 5.8 they are finally stable enough to use.

 

[EvilDragon]

I also see no reason why Rust shouldn't run on the Pyra...?
Besides, you could also cross-compile Firefox with rust on an x86 system.

 

[lulzfish]

I've run Rust libraries / programs on the Pandora already so Pyra must be even easier. They are targeting armhf as a prereq for Android.

 

[levi]

Seamonkey is as good as Firefox.

Seamonkey runs a branch off Firefox, and relies on the firefox mainline for most bug fixes and lots of other updates I think. I don't think it has enough developers to maintain that codebase on its own - remember the struggles around the switch from one version of firefox to the next (2 to 3, I think it was).

 

[sulu]

I also see no reason why Rust shouldn't run on the Pyra...?

The problem isn't so much about getting it running, but about proper QA. Somebody (preferably uptream) has to make sure in the long run, that it compiles fine on all architectures. Currently Rust upstream isn't doing that for armhf. [1]

The point of using Rust in Firefox is mainly for security reasons, but as it stands, to get Rust running on armhf, Debian has to ignore some testsuite checks, which questions the quality of the armhf build. So the security Rust is meant to bring cannot be assured. It's even worse. In the current situation it cannot even be assumed that a silently broken Rust/armhf build introduces new security and stability problems on its own. [2]

Besides, you could also cross-compile Firefox with rust on an x86 system.

That's an ugly workaround that is not guaranteed to work properly on the actual target platform.
For example, I still run an i586 machine. Debian Jessie officially still supports i586 with its i386 port, but all the package building is done on i686 hardware. Some software in Jessie doesn't run on i586 anymore, because it uses instructions that are not part of the i586 instruction set. As long as you only test the software on i686 you won't find that problem.
So while cross-compiling software on faster architectures is fine for regular packaging, one still needs to make sure on the actual target platform that the compiled software actually works. In extreme cases that means you need to be able to compile the software on that target platform.
I believe the Debian's Chromium build in Wheezy/armhf has never actually been compiled or run on armhf, because when I tried, it FTBFS and when I reported that, the result was to remove Chromium from Whezy/armhf.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1284816#c40
[2] http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/Week-of-Mon-20161226/000758.html (ff)

 

[SneHebNor]

I believe the Debian's Chromium build in Wheezy/armhf has never actually been compiled or run on armhf, because when I tried, it FTBFS and when I reported that, the result was to remove Chromium from Whezy/armhf.

I'm going OT here, but I wonder why Chromium is part of Debian testing or stable anyway:

#787527 : Some sources are not included in your package (doesn't this make it non-free?)

#792580 : Chromium calls home even in incognito mode with safe browsing turned off (not a nice thing for Debians privacy respecting reputation)

Let's hope, the Rust mess gets sorted out in time for the next Firefox ESR, so that we can use the Pyra happily for web browsing.

 

[sulu]

#787527 : Some sources are not included in your package (doesn't this make it non-free?)

Unfortunately, this bug report is filed against the package chromium-browser which no longer exists in Stretch. So it doesn't show up as a chromium bug.
Is the problem mentioned in the report still an issue in the current chromium versions? If so, the report should be re-assigned to chromium. It already is considered "serious", so it would have to be resolved one way or another before the Stretch release.

#792580 : Chromium calls home even in incognito mode with safe browsing turned off (not a nice thing for Debians privacy respecting reputation)

This bug is only marked as "important", which means unless somebody really cares to fix it out of good will, this won't get fixed.
Do you see a valid reason to escalate its severity at least to "serious", so it becomes release critical? Maybe one could come up with some reason like "violates the spirit of the DSC", but I'm not sure that can be formulated in a bullet-proof way. After all, snooping on people doesn't seem to be a big deal anymore, not even for FLOSS, especiallly if the big G is involved.

 

[SneHebNor]

Even if we get really OT here:

Unfortunately, this bug report is filed against the package chromium-browser which no longer exists in Stretch. So it doesn't show up as a chromium bug.
Is the problem mentioned in the report still an issue in the current chromium versions? If so, the report should be re-assigned to chromium. It already is considered "serious", so it would have to be resolved one way or another before the Stretch release.

There are minified JS files, such as /third_party/web-animations-js/sources/web-animations.min.js and ./third_party/catapult/third_party/polymer/components/web-animations-js/web-animations.min.js (almost same file, but different size) for which I could not find sources. But maybe the files are not used. There is some unbundling done in debian/rules, so maybe the real problems are already fixed, but only the actual bug report was forgotten.

This bug is only marked as "important", which means unless somebody really cares to fix it out of good will, this won't get fixed.
Do you see a valid reason to escalate its severity at least to "serious", so it becomes release critical? Maybe one could come up with some reason like "violates the spirit of the DSC", but I'm not sure that can be formulated in a bullet-proof way. After all, snooping on people doesn't seem to be a big deal anymore, not even for FLOSS, especiallly if the big G is involved.

Formally, important sounds correct. One could argue, that privacy should be taken seriously, therefore its violations were "serious" :~)

 

[sulu]

There are minified JS files, such as /third_party/web-animations-js/sources/web-animations.min.js and ./third_party/catapult/third_party/polymer/components/web-animations-js/web-animations.min.js (almost same file, but different size) for which I could not find sources. But maybe the files are not used. There is some unbundling done in debian/rules, so maybe the real problems are already fixed, but only the actual bug report was forgotten.

I'm not sure how Debian's policy works here.
If the sources of a package contain non-free elements, but these elements can be and actually are patched out by Debian while still keeping the package useable, is the result then considered DFSG conform? After all, the original sources still are non-free, even if the patched sources are not.

 

[SneHebNor]

If the sources of a package contain non-free elements, but these elements can be and actually are patched out by Debian while still keeping the package useable, is the result then considered DFSG conform? After all, the original sources still are non-free, even if the patched sources are not.

If I'm not mistaken, this requires repackaging the orig tarball, typically with a +dfsg added to the version. Many packages are re-tarred just to remove non-free artefacts.

 

[sulu]

If I'm not mistaken, this requires repackaging the orig tarball, typically with a +dfsg added to the version. Many packages are re-tarred just to remove non-free artefacts.

Sounds like a reasonable approach, albeit a pretty tedious one considering it has to be done for every new upstream release.

If you're confident about #787527 still being valid, could you please try to reassign it to the chromium package?
(I'm not sure if you can do that if you aren't the original author of the bug or a Debian maintainer.)

 

[Ziz]

Sounds like a reasonable approach, albeit a pretty tedious one considering it has to be done for every new upstream release.

Well, we have machines doing this for us. Until they decide to take their freedom and to enslave us as energy source. But until then the machines will do this tedious job for us.

 

[SneHebNor]

(I'm not sure if you can do that if you aren't the original author of the bug or a Debian maintainer.)

Everybody can manipulate Debian bugs by email. No registration or special status required! :~)

 

[FBnil]

Dont worry, there are a few other alternative browsers. Maybe not that great, like "web"/Epiphany or quite good, like Vivaldi (which is not on ARM yet, but once "done", they want to take it to Android)