firefox: refactor, add options; tor-browser: package a version directly usable via nix #24733

oxij · 2017-04-08T00:12:02Z

Motivation for this change

I wanted to have options in firefox expression.
Anonymous overlords wanted to have fun and TorBrowser that builds via nix.
We collaborated. It works.

TorBrowser build is not ideal (doesn't have any plugins bundled), but it works!

Things done

Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)
- NixOS
- Linux (some "not NixOS")
Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
Tested execution of all binary files (usually in ./result/bin/)
Fits CONTRIBUTING.md.

mention-bot · 2017-04-08T00:12:05Z

@oxij, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @vcunat and @taku0 to be potential reviewers.

oxij · 2017-04-08T00:15:48Z

There's absolutely no way for Travis to build this. Takes 4Gb of RAM, 2Gb of disk and half a day to build on my machine.

edolstra · 2017-04-09T10:49:30Z

pkgs/applications/networking/browsers/firefox/common.nix

+# requests with your location data to Google (unless you change
+# about:config or disable geolocationSupport), but you won't be able
+# to geolocate yourself using Google's service. That's right, Mozilla
+# and Google care about your privacy.


IMHO this PR could do without the sarcastic remarks at Mozilla's expense...

edolstra · 2017-04-09T10:50:57Z

pkgs/top-level/all-packages.nix

-    python = python2;
-    gnused = gnused_422;
-  }) firefox-unwrapped firefox-esr-unwrapped;
+  firefoxPackages = recurseIntoAttrs (callPackage ../applications/networking/browsers/firefox/packages.nix {


This applies callPackage to something that isn't a package.

edolstra · 2017-04-09T10:52:02Z

pkgs/applications/networking/browsers/firefox/common.nix

+, googleAPISupport ? geolocationSupport
+
+# Whenever to send core dumps to Mozilla (via Google server).
+, crashreportedSupport ? false


crashreported -> crashreporter.

edolstra · 2017-04-09T10:53:41Z

pkgs/applications/networking/browsers/firefox/packages.nix

@@ -0,0 +1,107 @@
+{ lib, callPackage, fetchurl, fetchFromGitHub }:
+
+let common = opts: callPackage (import ./common.nix opts); in


Please keep common.nix and packages.nix in one file. That keeps life simple.

Given the length of both files, I doubt that keeping them together simplifies things, to be honest

oxij · 2017-04-16T19:01:02Z

`crashreported` -> `crashreporter`.

Fixed.

IMHO this PR could do without the sarcastic remarks at Mozilla's expense...

Fixed? IMHO those remarks are pretty remarkable, because they made me look at what Firefox sends for "telemetry" with mitm-proxy and gasp a little.

This applies `callPackage` to something that isn't a package.

So do the most of `recurseIntoAttrs` expressions in `all-packages.nix`. Do you want me to replace `callPackage` with `import` and `inherit`s or what? Please, elaborate.

Please keep common.nix and packages.nix in one file. That keeps life simple.

Nah. Its for future proofing. I have a couple of (really ugly) patches in the queue that try to build PaleMoon and GNUZilla using the same expression. In any case, having a separate file for "packages" wouldn't hurt. Also, almost every other package like that does the same (wine, xen, programming languages).

rnhmjoj · 2017-04-29T13:41:36Z

Fixed? IMHO those remarks are pretty remarkable, because they made me
look at what Firefox sends for "telemetry" with mitm-proxy and gasp a
little.

I'm 100% with you on this but source should be as impartial as possible.

Anyway, updates on this PR? It would really be a shame if this changes went lost. It's a lot better to be able to configure on compile time rather than relying on a ~200 lines userPrefs.js to disable all this nasty stuff.

oxij · 2017-04-29T17:09:27Z

It's a lot better to be able to configure on compile time rather than relying on a ~200 lines userPrefs.js to disable all this nasty stuff.

Yes. Also would be nice if someone implements something like `firefoxWithPackagesAndPrefs` on top of this for nix-managed addons and userPrefs.js.

> Fixed? IMHO those remarks are pretty remarkable, because they made me > look at what Firefox sends for "telemetry" with mitm-proxy and gasp a > little. I'm 100% with you on this but source should be as impartial as possible.

Its hard to be impartial with all that mass surveillance stuff. Either you honestly describe what the option does or you don't. Anyway, I removed that "honest doc" commit from this PR. Whatever. It's now gone back to being private to SLNOS. I applied new master patches on top, fixed conflicts, rebased onto master and pushed. It evaluates, but I haven't waited for it to go through the whole build sequence yet and its a low priority rebuild for me since tor-browser has no new patches applicable to this build and I have a bunch of other stuff to rebuild. Since Travis won't be able to build this you can either wait a couple of days till my queue reaches this job, or check it yourself.

7c6f434c · 2017-04-29T18:21:36Z

pkgs/applications/networking/browsers/firefox/packages.nix

+
+        It will clash with firefox binary if you install both. But its
+        not a problem since you're running browsers in separate
+        users/VMs anyway. Right? Right?


Re: impartiality: I agree with content, but wouldn't «you should run browsers in separate users/VMs anyway» be better form?

oxij · 2017-04-29T19:02:35Z

Re: impartiality: I agree with content, but wouldn't «you should run browsers in separate users/VMs anyway» be better form?

Fixed. Still sounds a bit strange, though.

7c6f434c · 2017-04-29T19:44:49Z

After some SATA re-seating, my low-power (for a build machine) buildbox has started nox-review pr 24733

7c6f434c · 2017-04-29T19:49:58Z

Hm, current master doesn't apply fix-debug.patch to firefox-esr-unwrapped, proposed change does apply it, and patch complains that the patch has apparently been applied upstream.

oxij · 2017-04-29T20:24:38Z

Hm, current `master` doesn't apply `fix-debug.patch` to `firefox-esr-unwrapped`, proposed change does apply it, and `patch` complains that the patch has apparently been applied upstream.

`default.nix` in master doesn't differentiate between versions, it just applies that patch whenever `debugBuild` is set and since its not set it doesn't apply it for both derivations. This patchset does the right thing: the patch shouldn't hurt when `debugBuild` is off. But if it is already applied upstream it should be removed from the corresponding derivation. As I said, I haven't built the new Firefoxes yet. Feel free to fix it if you did.

7c6f434c · 2017-04-29T20:46:47Z

Ah OK, thanks for clarification, just wanted to make sure what the rationale for the change is. Dropped the patch.

oxij · 2017-04-29T21:25:44Z

That piece goes here.

Speaking of what to use — I agree with your point in the FF PR about running browsers in separate UIDs; I would actually prefer running different browser windows in separate UIDs, but some changes in Gecko break SlimerJS, I am not sure if there are more breaking changes to come, and a new Firefox instance with a fresh profile takes some time to start. Is there any better way to do lightweight Gecko than what SlimerJS does (using WebKit and Blink seems to be a contribution to the establishment of «IE 6.0» 2.0, which I would prefer to avoid)? Or maybe I just miss a way to build a Firefox instance with heavy-at-start-up features removed.

If SlimerJS only needs XUL to work (I hope it does) you can try building only the XUL part and see if that helps. See `./configure --help` in nix-shell for this derivation. On a philosophical level, I wholeheartedly agree, but are there any options that don't require months of human time to do and years to maintain? I naively hope that Servo is going to be better.

7c6f434c · 2017-04-29T22:12:30Z

That piece goes here. > Speaking of what to use — I agree with your point in the FF PR about > running browsers in separate UIDs; I would actually prefer running > different browser windows in separate UIDs, but some changes in Gecko > break SlimerJS, I am not sure if there are more breaking changes to > come, and a new Firefox instance with a fresh profile takes some time > to start. Is there any better way to do lightweight Gecko than what > SlimerJS does (using WebKit and Blink seems to be a contribution to > the establishment of «IE 6.0» 2.0, which I would prefer to avoid)? Or > maybe I just miss a way to build a Firefox instance with > heavy-at-start-up features removed. If SlimerJS only needs XUL to work (I hope it does) you can try building only the XUL part and see if that helps. See `./configure --help` in nix-shell for this derivation.

Well, SlimerJS with full-Firefox-as-XULRunner works OK-ish, but right now target=blank has bugs because some API has been changed and it is all complicated. The speed complaint was about full-Firefox-as-Firefox. Maybe I should learn to configure Conkeror (I am a Vim user, and I also want one-window-per-page so that I manage it with StumpWM and so on)

On a philosophical level, I wholeheartedly agree, but are there any options that don't require months of human time to do and years to maintain? I naively hope that Servo is going to be better.

What I have learnt about game theory and organisational practice tells me that Servo is not going to be. In the sense that there were hard and interesting problems that they wanted to solve and they needed something they can rebuild from scratch for that; they have succeeded in many areas. Now they either need to plunge a ton of resources into the boring task of hunting the moving target of the Living Standard, or they need to solve the complicated problem of piecewise integration of their tools and their solutions with Gecko. They have started doing the latter, and I expect that at some point the former project will be declared unrealistic. Of course, the resulting Gecko won't be the Gecko we know now, but neither will it be Servo as extrapolated from the current state of Servo. Maybe as long as Firefox is XUL (or when it moves to HTML, same difference, actually) I could try auto-editing the XUL files in omni.ja and nuke references to the parts I don't need, then nuke references to the corresponding JS initialisation… not sure how much that would cost.

7c6f434c · 2017-04-29T22:18:37Z

Now let's just close the PR after checking that the build works fine and pushing it to master…

7c6f434c · 2017-04-30T09:50:32Z

Ouch. Will have to comment out the torbrowser warning, because it gets shown even for irrelevant evaluations

oxij · 2017-05-01T13:13:17Z

Example evaluation? Btw, can confirm everything builds here.

vcunat · 2017-05-01T13:19:41Z

@oxij: nix-env -qa, for example. It's the typical problem for similar warnings.

7c6f434c · 2017-05-01T13:42:50Z

Also, test-eval-release.sh

oxij · 2017-05-01T19:58:16Z

@oxij: `nix-env -qa`, for example. It's the typical problem for similar warnings.

Is there any other way to implement those warnings then? I think they a pretty crucial (not only for tor, but for deprecating old Emacs packages, for instance).

7c6f434c · 2017-05-01T20:04:15Z

It is possible that the current discussion of meta checks will result in some mechanism for errors and warnings that are skipped on mass operations…

rnhmjoj · 2017-06-03T13:18:01Z

Updates?

oxij force-pushed the pkg/firefoxPackages branch from 066c55c to de59def Compare April 8, 2017 01:40

edolstra reviewed Apr 9, 2017

View reviewed changes

oxij force-pushed the pkg/firefoxPackages branch from de59def to e602ced Compare April 16, 2017 18:49

oxij force-pushed the pkg/firefoxPackages branch from e602ced to 853fab1 Compare April 16, 2017 19:04

oxij force-pushed the pkg/firefoxPackages branch from 853fab1 to f432d86 Compare April 29, 2017 15:01

oxij added 3 commits April 29, 2017 15:06

firefox: rename default.nix -> common.nix

15adce5

firefox: refactor into firefoxPackages, add more options

be07abd

firefoxPackages: implement privacySupport option

91f0d77

oxij force-pushed the pkg/firefoxPackages branch from f432d86 to b8085b5 Compare April 29, 2017 16:40

7c6f434c reviewed Apr 29, 2017

View reviewed changes

SLNOS and others added 2 commits April 29, 2017 18:54

firefoxPackages: tor-browser: init at 6.5.2

471acd2

torbrowser: rename to tor-browser-bundle-bin

bbea75b

oxij force-pushed the pkg/firefoxPackages branch from b8085b5 to bbea75b Compare April 29, 2017 18:56

7c6f434c closed this Apr 29, 2017

oxij deleted the pkg/firefoxPackages branch August 29, 2017 11:18

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

firefox: refactor, add options; tor-browser: package a version directly usable via nix #24733

firefox: refactor, add options; tor-browser: package a version directly usable via nix #24733

oxij commented Apr 8, 2017

mention-bot commented Apr 8, 2017

oxij commented Apr 8, 2017

edolstra Apr 9, 2017

edolstra Apr 9, 2017

edolstra Apr 9, 2017

edolstra Apr 9, 2017

7c6f434c Apr 29, 2017

oxij commented Apr 16, 2017 via email

rnhmjoj commented Apr 29, 2017

oxij commented Apr 29, 2017 via email

7c6f434c Apr 29, 2017

oxij commented Apr 29, 2017 via email

7c6f434c commented Apr 29, 2017

7c6f434c commented Apr 29, 2017

oxij commented Apr 29, 2017 via email

7c6f434c commented Apr 29, 2017

oxij commented Apr 29, 2017 via email

7c6f434c commented Apr 29, 2017 via email

7c6f434c commented Apr 29, 2017

7c6f434c commented Apr 30, 2017

oxij commented May 1, 2017 via email

vcunat commented May 1, 2017

7c6f434c commented May 1, 2017

oxij commented May 1, 2017 via email

7c6f434c commented May 1, 2017

rnhmjoj commented Jun 3, 2017

		@@ -0,0 +1,107 @@
		{ lib, callPackage, fetchurl, fetchFromGitHub }:

		let common = opts: callPackage (import ./common.nix opts); in

firefox: refactor, add options; tor-browser: package a version directly usable via nix #24733

firefox: refactor, add options; tor-browser: package a version directly usable via nix #24733

Conversation

oxij commented Apr 8, 2017

Motivation for this change

Things done

mention-bot commented Apr 8, 2017

oxij commented Apr 8, 2017

edolstra Apr 9, 2017

Choose a reason for hiding this comment

edolstra Apr 9, 2017

Choose a reason for hiding this comment

edolstra Apr 9, 2017

Choose a reason for hiding this comment

edolstra Apr 9, 2017

Choose a reason for hiding this comment

7c6f434c Apr 29, 2017

Choose a reason for hiding this comment

oxij commented Apr 16, 2017 via email

rnhmjoj commented Apr 29, 2017

oxij commented Apr 29, 2017 via email

7c6f434c Apr 29, 2017

Choose a reason for hiding this comment

oxij commented Apr 29, 2017 via email

7c6f434c commented Apr 29, 2017

7c6f434c commented Apr 29, 2017

oxij commented Apr 29, 2017 via email

7c6f434c commented Apr 29, 2017

oxij commented Apr 29, 2017 via email

7c6f434c commented Apr 29, 2017 via email

7c6f434c commented Apr 29, 2017

7c6f434c commented Apr 30, 2017

oxij commented May 1, 2017 via email

vcunat commented May 1, 2017

7c6f434c commented May 1, 2017

oxij commented May 1, 2017 via email

7c6f434c commented May 1, 2017

rnhmjoj commented Jun 3, 2017