Packaging a free Firefox

[Clément Lassieur]

Hi,

I find Icecat very buggy, even if I compare it to a home-made Firefox
package that inherits Icecat (and thus is very close to Icecat). For
example I can't even pay with my credit card with icecat-52-guix,
whereas I can with firefox-home-52-guix. (It looks like a javascript
issue.) Also, lots of videos don't work, and it's difficult to know
whether it's because of technical issues or because of DRM.

This may discourage people from using GuixSD.

My understanding is that Icecat exists because of two reasons:
1. a trademark/logo issue,
2. the need to remove non-free code from Firefox.

But it does more:
3. it only packages the stables versions of Firefox,
4. it adds add-ons,
5. it prevents the installation of non-free plugins,
6. probably other things that I'm not aware of.

It seems to me that the trademark/logo issue and the non-free code
removal could be dealt with at the Guix packaging level. It's probably
just a huge bunch of substitutes to do. The package would be huge, but
at least we would have control on it.

That would remove a layer of complexity, and probably reduce bugs (that
come from that layer). That would also allow us to have a recent
version of Firefox.

And it would be way better than everyone (I exaggerate a bit) having his
home-made non-maintened full-of-security-issues Firefox.

What do you think?
Clément

[Clément Lassieur]

Post by Clément Lassieur
Hi,
I find Icecat very buggy, even if I compare it to a home-made Firefox
package that inherits Icecat (and thus is very close to Icecat). For
example I can't even pay with my credit card with icecat-52-guix,
whereas I can with firefox-home-52-guix. (It looks like a javascript
issue.) Also, lots of videos don't work, and it's difficult to know
whether it's because of technical issues or because of DRM.
This may discourage people from using GuixSD.
1. a trademark/logo issue,
2. the need to remove non-free code from Firefox.
3. it only packages the stables versions of Firefox,
4. it adds add-ons,
5. it prevents the installation of non-free plugins,
6. probably other things that I'm not aware of.
It seems to me that the trademark/logo issue and the non-free code
removal could be dealt with at the Guix packaging level. It's probably
just a huge bunch of substitutes to do. The package would be huge, but
at least we would have control on it.
That would remove a layer of complexity, and probably reduce bugs (that
come from that layer). That would also allow us to have a recent
version of Firefox.
And it would be way better than everyone (I exaggerate a bit) having his

their ^

Post by Clément Lassieur
home-made non-maintened full-of-security-issues Firefox.
What do you think?
Clément

[Nils Gillmann]

Post by Clément Lassieur

Post by Clément Lassieur
Hi,
I find Icecat very buggy, even if I compare it to a home-made Firefox
package that inherits Icecat (and thus is very close to Icecat). For
example I can't even pay with my credit card with icecat-52-guix,
whereas I can with firefox-home-52-guix. (It looks like a javascript
issue.) Also, lots of videos don't work, and it's difficult to know
whether it's because of technical issues or because of DRM.
This may discourage people from using GuixSD.
1. a trademark/logo issue,
2. the need to remove non-free code from Firefox.
3. it only packages the stables versions of Firefox,
4. it adds add-ons,
5. it prevents the installation of non-free plugins,
6. probably other things that I'm not aware of.
It seems to me that the trademark/logo issue and the non-free code
removal could be dealt with at the Guix packaging level. It's probably
just a huge bunch of substitutes to do. The package would be huge, but
at least we would have control on it.
That would remove a layer of complexity, and probably reduce bugs (that
come from that layer). That would also allow us to have a recent
version of Firefox.
And it would be way better than everyone (I exaggerate a bit) having his

their ^

Post by Clément Lassieur
home-made non-maintened full-of-security-issues Firefox.
What do you think?
Clément

Among other things I've been working on Firefox. Not exactly with the intention
of a free one per se, but at least to have it. I've been updating Aurora Nightly
for a while.
Thing is, it get's tricky after 54.0 due to mandatory Rust. I wanted to give the
Rust problem another try soon, if you are serious about this, I can try and summarize
it or provide snippets. You'l be able to find the package definitions, but they do
not apply to Guix package structure (also I need to relicense it. whatever you'll
find AGPL3 licensed is in fact GPL3 licensed now. I am just too busy to fix the
headers, will do it on the weekend).. if I have commited the recent changes to the
wip version.
I seem to remember that the gnuzilla mailinglist did drop some hints about the core
issue I had with rust.

[Nils Gillmann]

Post by Nils Gillmann

Post by Clément Lassieur

Post by Clément Lassieur
Hi,
I find Icecat very buggy, even if I compare it to a home-made Firefox
package that inherits Icecat (and thus is very close to Icecat). For
example I can't even pay with my credit card with icecat-52-guix,
whereas I can with firefox-home-52-guix. (It looks like a javascript
issue.) Also, lots of videos don't work, and it's difficult to know
whether it's because of technical issues or because of DRM.
This may discourage people from using GuixSD.
1. a trademark/logo issue,
2. the need to remove non-free code from Firefox.
3. it only packages the stables versions of Firefox,
4. it adds add-ons,
5. it prevents the installation of non-free plugins,
6. probably other things that I'm not aware of.
It seems to me that the trademark/logo issue and the non-free code
removal could be dealt with at the Guix packaging level. It's probably
just a huge bunch of substitutes to do. The package would be huge, but
at least we would have control on it.
That would remove a layer of complexity, and probably reduce bugs (that
come from that layer). That would also allow us to have a recent
version of Firefox.
And it would be way better than everyone (I exaggerate a bit) having his

their ^

Post by Clément Lassieur
home-made non-maintened full-of-security-issues Firefox.
What do you think?
Clément

Among other things I've been working on Firefox. Not exactly with the intention
of a free one per se, but at least to have it. I've been updating Aurora Nightly
for a while.
Thing is, it get's tricky after 54.0 due to mandatory Rust. I wanted to give the
Rust problem another try soon, if you are serious about this, I can try and summarize
it or provide snippets. You'l be able to find the package definitions, but they do
not apply to Guix package structure (also I need to relicense it. whatever you'll
find AGPL3 licensed is in fact GPL3 licensed now. I am just too busy to fix the
headers, will do it on the weekend).. if I have commited the recent changes to the
wip version.
I seem to remember that the gnuzilla mailinglist did drop some hints about the core
issue I had with rust.

Addition: I think constructing and maintaing a free, unbranded version of Firefox (Aurora)
or even a branded one with a Guix theme is possible. What icecat does is not that complex
but it requires at least more than 1 person checking the sources continuously. Furthermore
we'd need a common ground of goals what changes would be applied and what changes are a
no-go.

[Pierre Neidhardt]

While not directly related to Firefox, Next Browser is also a
full-featured, highly-compatible webbrowser.

I'll package it for Guix very soon:

https://github.com/next-browser/next/issues/92
http://next-browser.com/

--
Pierre Neidhardt

[Jack Hill]

Post by Pierre Neidhardt
While not directly related to Firefox, Next Browser is also a
full-featured, highly-compatible webbrowser.
https://github.com/next-browser/next/issues/92
http://next-browser.com/

Pierre,

This is very exciting! I would like to use next.

I had started to package next for Guix [0], but haven't had a chance to
work on it recently, Is is also my first Guix package, so progress is
slower while I am learning. Please let me know if there is something I can
help with or if you want an enthusiastic tester ☺.

Best,
Jack

[0] https://gitlab.oit.duke.edu/jackhill/guix-packages/blob/master/next-browser.scm

[Pierre Neidhardt]

Thank you very much for reaching out to me, Jack!

I will start working on it in the upcoming days.

I'm starting to get there regarding Guix package declarations. I've
still got to learn more about Common Lisp packaging though.

Let's keep in touch!

[Jack Hill]

Post by Pierre Neidhardt
Thank you very much for reaching out to me, Jack!

You're welcome.

Post by Pierre Neidhardt
I will start working on it in the upcoming days.

Great.

Post by Pierre Neidhardt
I'm starting to get there regarding Guix package declarations. I've
still got to learn more about Common Lisp packaging though.

Me too. What I learned was from reading other package definitions. It did
seem to me that we would need to use git versions of some of the
dependencies rather than releases which slightly complicated things for a
first time packager. I also wasn't sure what to do about supporting
multiple CL implementations. I was planning to stick with just SBCL to
start.

I wonder if a quicklisp or similar CL package archive importer would make
sense and be useful.

Post by Pierre Neidhardt
Let's keep in touch!

Agreed. I'll be here and jackhill on #guix

Jack

[Andy Patterson]

Hi Jack,

On Thu, 3 May 2018 16:23:12 -0400 (EDT)
Jack Hill <***@jackhill.us> wrote:

[...]

Post by Jack Hill
Me too. What I learned was from reading other package definitions. It
did seem to me that we would need to use git versions of some of the
dependencies rather than releases which slightly complicated things
for a first time packager. I also wasn't sure what to do about
supporting multiple CL implementations. I was planning to stick with
just SBCL to start.

I took a look at your package definition and I wanted to let you know
that I have a working package for cffi on sbcl locally. I'll try to get
it submitted this weekend along with some changes to the asdf build
system that I've been working on.

Post by Jack Hill
I wonder if a quicklisp or similar CL package archive importer would
make sense and be useful.

This is what I've wanted to write for a while but never got around to.
Maybe I'll have a go at it again soon.

Thanks,

--
Andy

[Andy Patterson]

Hi Pierre,

On Thu, 10 May 2018 16:36:11 +0200

In the mean time, I figured that changing Alexandria's version from
"0.0.0-..." to "0.0.0" did the trick.
Now I'm stuck at packaging sbcl-cffi-gtk...
I'm fairly new to Common Lisp and I must say it's pretty
overwhelming! :/ Any recommendation in terms of documentation to get
me started? I'll focus on the ASDF manual for now.

I'd also have a look at the manual page for the asdf build system,
which explains some of the quirks that exist with packaging common lisp
software. Unfortunately I don't have much advice to offer since my own
methods for package authoring and debugging are very unsophisticated.

Also, it looks like I forgot to CC the list when I replied with the
package definitions, so I'll attach them again here.

Feel free to let me know if you have any more questions about
packaging for common lisp.

Thanks,

--
Andy

[a***@uwaterloo.ca]

Hi,

Also your sbcl-iterate declaration uses "darcs-reference" which
seems to be your own (unless I missed it). Mind sharing it? Thanks!

Right, I'll share this soon. In the mean time I think you should be able
to delete my definition of sbcl-iterate since one already exists in the
same file.

--
Pierre Neidhardt

Thanks,

--
Andy

[Chris Marusich]

Post by Clément Lassieur
I find Icecat very buggy, even if I compare it to a home-made Firefox
package that inherits Icecat (and thus is very close to Icecat). For
example I can't even pay with my credit card with icecat-52-guix,
whereas I can with firefox-home-52-guix. (It looks like a javascript
issue.) Also, lots of videos don't work, and it's difficult to know
whether it's because of technical issues or because of DRM.

This has not been my experience with IceCat. With two exceptions,
IceCat has performed just as well as Firefox for me for everything I
have done, including credit card payments. I sometimes watch YouTube
videos using IceCat, but I don't view many other videos, so I can't
really comment on how well IceCat handles videos. If it requires DRM,
of course, it's not going to work in IceCat, which is a good thing.

When I use IceCat over TOR, it doesn't always work. When I use IceCat
with extensions (plugins? add-ons? I'm not sure what the right
terminology is here) like NoScript enabled, it doesn't always work. But
when I don't use TOR and I disable those add-ons, everything works just
as well as stock Firefox. If you're still having trouble after
disabling those things, can you describe the specifics of what you're
having trouble with?

The exceptions I have experienced with IceCat:

1) A website failed for me because IceCat enables Referer spoofing by
default (network.http.referer.spoofSource in about:config). I had to
disable that feature to use that website.

2) It used to be that IceCat would crash frequently for me. However,
once I changed my gfx.canvas.azure.backends and
gfx.content.azure.backends from "cairo" to "skia", this problem stopped
for me. I don't know if this is still an issue , since I haven't ever
switched it back to "cairo". See here for details:

https://lists.gnu.org/archive/html/help-guix/2016-11/msg00008.html

[Pjotr Prins]

Post by Chris Marusich

Post by Clément Lassieur
I find Icecat very buggy, even if I compare it to a home-made Firefox
package that inherits Icecat (and thus is very close to Icecat). For
example I can't even pay with my credit card with icecat-52-guix,
whereas I can with firefox-home-52-guix. (It looks like a javascript
issue.) Also, lots of videos don't work, and it's difficult to know
whether it's because of technical issues or because of DRM.

This has not been my experience with IceCat. With two exceptions,
IceCat has performed just as well as Firefox for me for everything I
have done, including credit card payments. I sometimes watch YouTube
videos using IceCat, but I don't view many other videos, so I can't
really comment on how well IceCat handles videos. If it requires DRM,
of course, it's not going to work in IceCat, which is a good thing.
When I use IceCat over TOR, it doesn't always work. When I use IceCat
with extensions (plugins? add-ons? I'm not sure what the right
terminology is here) like NoScript enabled, it doesn't always work. But
when I don't use TOR and I disable those add-ons, everything works just
as well as stock Firefox. If you're still having trouble after
disabling those things, can you describe the specifics of what you're
having trouble with?
1) A website failed for me because IceCat enables Referer spoofing by
default (network.http.referer.spoofSource in about:config). I had to
disable that feature to use that website.
2) It used to be that IceCat would crash frequently for me. However,
once I changed my gfx.canvas.azure.backends and
gfx.content.azure.backends from "cairo" to "skia", this problem stopped
for me. I don't know if this is still an issue , since I haven't ever
https://lists.gnu.org/archive/html/help-guix/2016-11/msg00008.html

In my experience Icecat usually works. But sometimes it does not and
it is usually a JavaScript thing. It would be nice to have firefox
too. I agree with Clément that it is an important option for users and
it is still a dominant browser. Currently we only can install it as
binary blobs. Which are often broken in my setup.

Pj.

[Mathieu Othacehe]

Hi,

I agree with Pjotr and Clément, I do use mainly two programs on GuixSD,
Firefox and Emacs. Packaging a custom Firefox was like the first thing I
did when starting Guix. Even if we put a lot of efforts in Icecat, it it
still lagging behind Firefox. Thus, having an upstream stripped Firefox
seems like a good idea to me.

Mathieu

Post by Pjotr Prins

Post by Chris Marusich

Post by Clément Lassieur
I find Icecat very buggy, even if I compare it to a home-made Firefox
package that inherits Icecat (and thus is very close to Icecat). For
example I can't even pay with my credit card with icecat-52-guix,
whereas I can with firefox-home-52-guix. (It looks like a javascript
issue.) Also, lots of videos don't work, and it's difficult to know
whether it's because of technical issues or because of DRM.

This has not been my experience with IceCat. With two exceptions,
IceCat has performed just as well as Firefox for me for everything I
have done, including credit card payments. I sometimes watch YouTube
videos using IceCat, but I don't view many other videos, so I can't
really comment on how well IceCat handles videos. If it requires DRM,
of course, it's not going to work in IceCat, which is a good thing.
When I use IceCat over TOR, it doesn't always work. When I use IceCat
with extensions (plugins? add-ons? I'm not sure what the right
terminology is here) like NoScript enabled, it doesn't always work. But
when I don't use TOR and I disable those add-ons, everything works just
as well as stock Firefox. If you're still having trouble after
disabling those things, can you describe the specifics of what you're
having trouble with?
1) A website failed for me because IceCat enables Referer spoofing by
default (network.http.referer.spoofSource in about:config). I had to
disable that feature to use that website.
2) It used to be that IceCat would crash frequently for me. However,
once I changed my gfx.canvas.azure.backends and
gfx.content.azure.backends from "cairo" to "skia", this problem stopped
for me. I don't know if this is still an issue , since I haven't ever
https://lists.gnu.org/archive/html/help-guix/2016-11/msg00008.html

In my experience Icecat usually works. But sometimes it does not and
it is usually a JavaScript thing. It would be nice to have firefox
too. I agree with Clément that it is an important option for users and
it is still a dominant browser. Currently we only can install it as
binary blobs. Which are often broken in my setup.
Pj.

[Pjotr Prins]

Post by Clément Lassieur
I find Icecat very buggy, even if I compare it to a home-made Firefox
package that inherits Icecat (and thus is very close to Icecat). For
example I can't even pay with my credit card with icecat-52-guix,
whereas I can with firefox-home-52-guix. (It looks like a javascript
issue.) Also, lots of videos don't work, and it's difficult to know
whether it's because of technical issues or because of DRM.

Using Noscript extension I find Icecat to be much more stable. Not
sure what causes the crashes though, but now the experience is much
like a somewhat older FF.

It is probably worth pursuing Icecat and get those glitches fixed.

Pj.

[Mike Gerwitz]

Post by Chris Marusich

Post by Clément Lassieur
I find Icecat very buggy, even if I compare it to a home-made Firefox
package that inherits Icecat (and thus is very close to Icecat). For
example I can't even pay with my credit card with icecat-52-guix,
whereas I can with firefox-home-52-guix. (It looks like a javascript
issue.) Also, lots of videos don't work, and it's difficult to know
whether it's because of technical issues or because of DRM.

This has not been my experience with IceCat. With two exceptions,
IceCat has performed just as well as Firefox for me for everything I
have done, including credit card payments. I sometimes watch YouTube
videos using IceCat, but I don't view many other videos, so I can't
really comment on how well IceCat handles videos. If it requires DRM,
of course, it's not going to work in IceCat, which is a good thing.
When I use IceCat over TOR, it doesn't always work. When I use IceCat
with extensions (plugins? add-ons? I'm not sure what the right
terminology is here) like NoScript enabled, it doesn't always work. But
when I don't use TOR and I disable those add-ons, everything works just
as well as stock Firefox. If you're still having trouble after
disabling those things, can you describe the specifics of what you're
having trouble with?

I use IceCat personally and FF Dev Edition at work. Until the recent
move to WebExtensions, I used the same addons. I use NoScript and Tor
and have no problems. But I rarely enable JS and never run proprietary
JS, so my exposure may be different. I do not use LibreJS (because I
don't usually run JS at all in general and it historically did not play
well with NoScript; maybe that has changed).

Post by Chris Marusich
1) A website failed for me because IceCat enables Referer spoofing by
default (network.http.referer.spoofSource in about:config). I had to
disable that feature to use that website.

This was a frustrating problem for me for CloudFlare CAPTCHAs---it would
enter an infinte direct loop. Disabling referer spoofing fixed the
issue.

Post by Chris Marusich
2) It used to be that IceCat would crash frequently for me. However,
once I changed my gfx.canvas.azure.backends and
gfx.content.azure.backends from "cairo" to "skia", this problem stopped
for me. I don't know if this is still an issue , since I haven't ever
https://lists.gnu.org/archive/html/help-guix/2016-11/msg00008.html

It will crash for me if I try e.g. Jitsi Meet; I'll have to see if
anything you are describing helps.


Anyway: I too would like a modern version of FF packaged for Guix. I
know that David Thompson was exploring it at some point but got hung up
on some Rust packaging issues that he didn't have the time to
explore. I want the modern performance benefits, and I also use the
browser for web development. IceCat maintenance also effectively falls
on Mark Weaver backporting security patches in Guix; Rubén Rodriguez
(IceCat) maintainer has a lot on his plate and IceCat does not get a lot
of attention.

(If anyone wants to help with IceCat maintenance, he would like the
help; contact us at ***@gnu.org.)

[Pjotr Prins]

Post by Mike Gerwitz
I use IceCat personally and FF Dev Edition at work. Until the recent
move to WebExtensions, I used the same addons. I use NoScript and Tor
and have no problems. But I rarely enable JS and never run proprietary
JS, so my exposure may be different. I do not use LibreJS (because I
don't usually run JS at all in general and it historically did not play
well with NoScript; maybe that has changed).

Disabling all extensions makes Icecat work much better. I'll try it as
a default now.

Question: why do we switch on extensions by default? Sure confused my
experience.

Pj.

[Nils Gillmann]

Post by Pjotr Prins

Post by Mike Gerwitz
I use IceCat personally and FF Dev Edition at work. Until the recent
move to WebExtensions, I used the same addons. I use NoScript and Tor
and have no problems. But I rarely enable JS and never run proprietary
JS, so my exposure may be different. I do not use LibreJS (because I
don't usually run JS at all in general and it historically did not play
well with NoScript; maybe that has changed).

Disabling all extensions makes Icecat work much better. I'll try it as
a default now.
Question: why do we switch on extensions by default? Sure confused my
experience.
Pj.

I think it's because this is upstreams decision and we usually stick
with what upstream does. Although you could almost call our Icecat
a variant of Icecat due to more work going into tracking Mozilla
and applying patches done by Mark.

[Mike Gerwitz]

Post by Pjotr Prins

Post by Mike Gerwitz
I use IceCat personally and FF Dev Edition at work. Until the recent
move to WebExtensions, I used the same addons. I use NoScript and Tor
and have no problems. But I rarely enable JS and never run proprietary
JS, so my exposure may be different. I do not use LibreJS (because I
don't usually run JS at all in general and it historically did not play
well with NoScript; maybe that has changed).

Disabling all extensions makes Icecat work much better. I'll try it as
a default now.

I don't think I made clear with the above: I use many different addons
(NoScript, Privacy Badger, HTTPS Everywhere, uBlock Origin,
Self-Destructing Cookies, Foxyproxy, Tree Style Tab, and some misc
ones); I didn't want to give the impression that extensions are a
problem for me.

As far as the extensions that come _with_ IceCat, I just don't have use
for them or use something else in place of them.

[Pjotr Prins]

Post by Mike Gerwitz
As far as the extensions that come _with_ IceCat, I just don't have use
for them or use something else in place of them.

That appears reasonable. Maybe we can provide flavours of Icecat
in addition to the default.

Pj.

[Pjotr Prins]

Post by Pjotr Prins

Post by Mike Gerwitz
I use IceCat personally and FF Dev Edition at work. Until the recent
move to WebExtensions, I used the same addons. I use NoScript and Tor
and have no problems. But I rarely enable JS and never run proprietary
JS, so my exposure may be different. I do not use LibreJS (because I
don't usually run JS at all in general and it historically did not play
well with NoScript; maybe that has changed).

Disabling all extensions makes Icecat work much better. I'll try it as
a default now.
Question: why do we switch on extensions by default? Sure confused my
experience.

So I have been using Icecate for 10 days. It is frustrating because it
does crash every other hour on some JS load. The error always looks like

Extension error: SyntaxError: in strict mode code, functions may be declared only at top level or immediately within another function resource://gre/modules/ExtensionUtils.jsm -> moz-extension://73353d04-3869-453b-8b9b-f71ceaae6e26/polyfill.js 63
[[Exception stack
Current stack
***@resource://gre/modules/ExtensionUtils.jsm:25:110
***@resource://gre/modules/ExtensionContent.jsm:197:9
***@resource://gre/modules/ExtensionContent.jsm:273:5
***@resource://gre/modules/ExtensionContent.jsm:463:11
***@resource://gre/modules/ExtensionContent.jsm:342:7
]]

I only have noscript and adblock plus installed and running. Any ideas?

I know I can file it as a bug, and we should if there is no idea. But
I think I'll go to FF again if this persists.

Pj.

[Ludovic Courtès]

Hi Pjotr,

Post by Pjotr Prins
So I have been using Icecate for 10 days. It is frustrating because it
does crash every other hour on some JS load. The error always looks like
Extension error: SyntaxError: in strict mode code, functions may be declared only at top level or immediately within another function resource://gre/modules/ExtensionUtils.jsm -> moz-extension://73353d04-3869-453b-8b9b-f71ceaae6e26/polyfill.js 63
[[Exception stack
Current stack
]]
I only have noscript and adblock plus installed and running. Any ideas?

Did you check on the “about:home” page whether other things were
enabled? Also, is the JS error above fatal? JS is designed to keep
going in spite of errors (really!), so it could be that the thing above
doesn’t matter.

FWIW, I’ve been using IceCat (actually mostly Conkeror, but it’s the
same thing) for a long time and I’ve rarely experienced crashes. I’m
surprised the experience is that bad for you. Is this on GuixSD?

Post by Pjotr Prins
I think I'll go to FF again if this persists.

IceCat is essentially the same code as FireFox modulo branding, add-ons,
and a few trivial things. I don’t see how IceCat itself could be
blamed—the add-ons maybe, the way it is packaged in Guix perhaps, but
IceCat?…

Ludo’.

[Gábor Boskovits]

Post by Ludovic Courtès
Hi Pjotr,

Post by Pjotr Prins
So I have been using Icecate for 10 days. It is frustrating because it
does crash every other hour on some JS load. The error always looks like
Extension error: SyntaxError: in strict mode code, functions may be

declared only at top level or immediately within another function
resource://gre/modules/ExtensionUtils.jsm ->
moz-extension://73353d04-3869-453b-8b9b-f71ceaae6e26/polyfill.js 63

Post by Pjotr Prins
[[Exception stack
Current stack

ExtensionContent.jsm:342:7

Post by Pjotr Prins
]]
I only have noscript and adblock plus installed and running. Any ideas?

Did you check on the “about:home” page whether other things were
enabled? Also, is the JS error above fatal? JS is designed to keep
going in spite of errors (really!), so it could be that the thing above
doesn’t matter.
FWIW, I’ve been using IceCat (actually mostly Conkeror, but it’s the
same thing) for a long time and I’ve rarely experienced crashes. I’m
surprised the experience is that bad for you. Is this on GuixSD?

Post by Pjotr Prins
I think I'll go to FF again if this persists.

IceCat is essentially the same code as FireFox modulo branding, add-ons,
and a few trivial things. I don’t see how IceCat itself could be
blamed—the add-ons maybe, the way it is packaged in Guix perhaps, but
IceCat?

Ludo’.
There was a bug in earlier Firefox, might that be that IceCat doesn't have

the fix for that yet? I don't know how much IceCat is delayed to Firefox.
https://stackoverflow.com/questions/24573061/uncaught-syntaxerror-in-strict-mode-code-functions-can-only-be-declared-at-top,
see the last comment.

[Mark H Weaver]

There was a bug in earlier Firefox, might that be that IceCat doesn't have
the fix for that yet? I don't know how much IceCat is delayed to Firefox.
https://stackoverflow.com/questions/24573061/uncaught-syntaxerror-in-strict-mode-code-functions-can-only-be-declared-at-top, see the last comment.

Someone wrote in that thread that updating to Firefox 52.4 solved the
issue for them. If that's the case, the issue should be fixed in IceCat
as well, because our IceCat package includes all relevant fixes from
Firefox ESR up through 52.8.

Mark

[Mike Gerwitz]

Post by Ludovic Courtès
Hi Pjotr,

[...]

Post by Ludovic Courtès

Post by Pjotr Prins
I think I'll go to FF again if this persists.

IceCat is essentially the same code as FireFox modulo branding, add-ons,
and a few trivial things. I don’t see how IceCat itself could be
blamed—the add-ons maybe, the way it is packaged in Guix perhaps, but
IceCat?


IceCat is based on an old ESR; FF has undergone many substantial changes
(and rewrites of parts of the system) since then; it's much more
performant and I've found it to be much more stable over the years.
(I use IceCat at home and FF at work.)

So when users compare IceCat to "Firefox", they're not likely
performing a valid comparison, since they're going to use a modern
version of Firefox.

I think Rubén is working on an ESR upgrade, so maybe users' experiences
will be a bit better soon.

[Mark H Weaver]

Post by Chris Marusich
2) It used to be that IceCat would crash frequently for me. However,
once I changed my gfx.canvas.azure.backends and
gfx.content.azure.backends from "cairo" to "skia", this problem stopped
for me. I don't know if this is still an issue , since I haven't ever
https://lists.gnu.org/archive/html/help-guix/2016-11/msg00008.html

FYI, I switched back to the "cairo" backend a couple of months ago, and
I haven't experienced any crashes, so I disabled this workaround on our
'core-updates' branch.

https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=1293f6d8a4dfad23ec693a1f2785cdb8d09b36f6

Mark

[Clément Lassieur]

Hi Chris,

Post by Chris Marusich

Post by Clément Lassieur
I find Icecat very buggy, even if I compare it to a home-made Firefox
package that inherits Icecat (and thus is very close to Icecat). For
example I can't even pay with my credit card with icecat-52-guix,
whereas I can with firefox-home-52-guix. (It looks like a javascript
issue.) Also, lots of videos don't work, and it's difficult to know
whether it's because of technical issues or because of DRM.

This has not been my experience with IceCat. With two exceptions,
IceCat has performed just as well as Firefox for me for everything I
have done, including credit card payments. I sometimes watch YouTube
videos using IceCat, but I don't view many other videos, so I can't
really comment on how well IceCat handles videos. If it requires DRM,
of course, it's not going to work in IceCat, which is a good thing.
When I use IceCat over TOR, it doesn't always work. When I use IceCat
with extensions (plugins? add-ons? I'm not sure what the right
terminology is here) like NoScript enabled, it doesn't always work. But
when I don't use TOR and I disable those add-ons, everything works just
as well as stock Firefox. If you're still having trouble after
disabling those things, can you describe the specifics of what you're
having trouble with?

You are right, there were tons of add-ons enabled, and disabling them
allowed me to do my credit card payment. I don't know why I never
thought about disabling them. (I wonder if it would be better to
disable them by default.) So... I apologize for being unfair with
Icecat :-) most of what I said is wrong.

The version issue remains though: having a Firefox 58 (not 52) would be
great, but maybe it's not worth doing the package, I don't know.

Thank you all for replying, and thanks to the Icecat mainteners for
their work ;-)

Clément

[Clément Lassieur]

Post by Clément Lassieur
You are right, there were tons of add-ons enabled, and disabling them
allowed me to do my credit card payment. I don't know why I never
thought about disabling them. (I wonder if it would be better to
disable them by default.)

I think the answer is https://directory.fsf.org/wiki/IceCat#Philosophy.

[Adonay Felipe Nogueira]

Post by Clément Lassieur
Hi,

Hi Clément,

Post by Clément Lassieur
I find Icecat very buggy, even if I compare it to a home-made Firefox
package that inherits Icecat (and thus is very close to Icecat). For
example I can't even pay with my credit card with icecat-52-guix,
whereas I can with firefox-home-52-guix. (It looks like a javascript
issue.) Also, lots of videos don't work, and it's difficult to know
whether it's because of technical issues or because of DRM.

I have noticed somepeople advocating for packaging Firefox in GNU Guix,
and since FF still has freedom issues, I see it as a no-go. What if,
instead of making Guix's own "IceCat based on latest Firefox", we do get
in touch with IceCat project instead so that they get convinced to use
"latest Firefox" (and perhaps help them?) instead of ESR? Another option
is to package Trisquel's Abrowser.

As for the JavaScript issue, it really is a matter of reaching out to
the *website owners*, or changing the service provider. Really, serious
business people that value end-user privacy, security and accessibility
shouldn't be requiring the clients to run client-side forced
autoexecutable code, specially now that we found out about Meltdown and
Spectre unfixable vulnerabilities.

Post by Clément Lassieur
5. it prevents the installation of non-free plugins,

Could you please report this bug to GNUzilla project (the one
responsible for IceCat)? If by "prevents" you mean "forbids" then this
is definetively a bug, not a feature. Free/libre software shouldn't
forbid doing that, it insltead mustn't *recommend* doing it, and must
not mention these non-free functional data.
--
- Formas de contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Ativista do /software/ livre (não confundir com gratuito). Avaliador
da liberdade de /software/ e de /sites/.
- Arquivos que aceito: https://libreplanet.org/wiki/User:Adfeno#Arquivos
- Contribuições à sociedade:
https://libreplanet.org/wiki/User:Adfeno#Contributions
- Gosta do meu trabalho? Contrate-me ou doe algo para mim!
https://libreplanet.org/wiki/User:Adfeno#Suporte
- Use comunicações sociais federadas padronizadas, onde o "social"
permanece independente do fornecedor. #DeleteWhatsApp. Use #XMPP
(https://libreplanet.org/wiki/XMPP.pt), #DeleteFacebook
#DeleteInstagram #DeleteTwitter #DeleteYouTube. Use #ActivityPub via
#Mastodon (https://joinmastodon.org/).
- #DeleteNetflix #CancelNetflix. Evite #DRM:
https://www.defectivebydesign.org/

[Mike Gerwitz]

Post by Adonay Felipe Nogueira
I have noticed somepeople advocating for packaging Firefox in GNU Guix,
and since FF still has freedom issues, I see it as a no-go.

A simple option for now is to package FF by disabling those features and
_not_ providing an alternative. For example, IceCat loads a different
addon page than FF; we could just load no addon page at all, or a static
one saying that it's something'll we'll get to eventually.

I have no suggestions for dealing with the trademark issue, though.

Post by Adonay Felipe Nogueira
What if, instead of making Guix's own "IceCat based on latest
Firefox", we do get in touch with IceCat project instead so that they
get convinced to use "latest Firefox" (and perhaps help them?) instead
of ESR?

We (GNU) are looking for co-maintainers for IceCat. If anyone expresses
interest with your suggestion, please have them contact

Post by Adonay Felipe Nogueira
Another option is to package Trisquel's Abrowser.

Isn't Abrowser more up-to-date than IceCat is? It's maintained by the
same person (Rubén), but I haven't used Trisquel on a desktop in quite
some time.

[Nils Gillmann]

Post by Mike Gerwitz

Post by Adonay Felipe Nogueira
I have noticed somepeople advocating for packaging Firefox in GNU Guix,
and since FF still has freedom issues, I see it as a no-go.

A simple option for now is to package FF by disabling those features and
_not_ providing an alternative. For example, IceCat loads a different
addon page than FF; we could just load no addon page at all, or a static
one saying that it's something'll we'll get to eventually.

For the majority of people it will be "weird" to load add-ons not via
the Mozlla Store, but if explained before usage it can work out.
I thin with regards to Addons of Mozilla based software, we just have
to reimplement what Nix does for the Addons.

Post by Mike Gerwitz
I have no suggestions for dealing with the trademark issue, though.

The branding "aurora" (building without branding) is trademark free.
What remains are mentions of "Firefo" in some places.

Post by Mike Gerwitz

Post by Adonay Felipe Nogueira
What if, instead of making Guix's own "IceCat based on latest
Firefox", we do get in touch with IceCat project instead so that they
get convinced to use "latest Firefox" (and perhaps help them?) instead
of ESR?

We (GNU) are looking for co-maintainers for IceCat. If anyone expresses
interest with your suggestion, please have them contact

Post by Adonay Felipe Nogueira
Another option is to package Trisquel's Abrowser.

Isn't Abrowser more up-to-date than IceCat is? It's maintained by the
same person (Rubén), but I haven't used Trisquel on a desktop in quite
some time.
--
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[Mike Gerwitz]

Post by Nils Gillmann

Post by Mike Gerwitz

Post by Adonay Felipe Nogueira
I have noticed somepeople advocating for packaging Firefox in GNU Guix,
and since FF still has freedom issues, I see it as a no-go.

A simple option for now is to package FF by disabling those features and
_not_ providing an alternative. For example, IceCat loads a different
addon page than FF; we could just load no addon page at all, or a static
one saying that it's something'll we'll get to eventually.

For the majority of people it will be "weird" to load add-ons not via
the Mozlla Store, but if explained before usage it can work out.

Users are free to still use addons.mozilla.org, of course. I do,
because I know to check the license of the addon before installing, and
the website does not require JS for the functions that I need.

I suspect that most Guix users are more technical than average users and
would be much less bothered by a kluge for the time being. But to
prevent bug reports, something should certainly indicate that it's not
failing to load because of a bug.

Post by Nils Gillmann
I thin with regards to Addons of Mozilla based software, we just have
to reimplement what Nix does for the Addons.

I'm not familiar with what Nix does; is it similar to what Guix does
with e.g. Emacs packages? I would like that.

Post by Nils Gillmann

Post by Mike Gerwitz
I have no suggestions for dealing with the trademark issue, though.

The branding "aurora" (building without branding) is trademark free.
What remains are mentions of "Firefo" in some places.

Oh, excellent.

[Hartmut Goebel]

Post by Mike Gerwitz
I suspect that most Guix users are more technical than average users and
would be much less bothered by a kluge for the time being.

I would be bothered by such a kludge, which IMHO is of no use.

[Hartmut Goebel]

Post by Mike Gerwitz

Post by Adonay Felipe Nogueira
I have noticed somepeople advocating for packaging Firefox in GNU Guix,
and since FF still has freedom issues, I see it as a no-go.

A simple option for now is to package FF by disabling those features and
_not_ providing an alternative. For example, IceCat loads a different
addon page than FF; we could just load no addon page at all, or a static
one saying that it's something'll we'll get to eventually.

Not packaging FF or crippling FF is a no-go! Doing so will discourage
users from using GuixSD and Free Software.

You will defeat your supporters, those who want to go the
free-software-route. But you will not change the world, since your
supporters have to carry the can, and the vendors, who are causing the
problems, will be untouched. This is the same as not providing
proprietary firmware in libre-linux.

If you want to make the world a better place, you may decide to live
vegan. And if you expect everybody to become vegan, you will reach less
than if you try to convince people to start with eating less or no meat.

Having strong opinions and working towards them is the one side.
Convincing people is the other side.

Followup-to: alt.religion.free-software,

[Pjotr Prins]

Post by Hartmut Goebel

Post by Mike Gerwitz

Post by Adonay Felipe Nogueira
I have noticed somepeople advocating for packaging Firefox in GNU Guix,
and since FF still has freedom issues, I see it as a no-go.

A simple option for now is to package FF by disabling those features and
_not_ providing an alternative. For example, IceCat loads a different
addon page than FF; we could just load no addon page at all, or a static
one saying that it's something'll we'll get to eventually.

Not packaging FF or crippling FF is a no-go! Doing so will discourage
users from using GuixSD and Free Software.

That is an interesting one. GNU Guix, by virtue of it being a GNU
project needs to abide by GNU free software terms. But even among core
project members there are variations in thought in how to compromise
with user requirements. A package manager that does not target user
needs is a shitty package manager. This is one reason I champion the
concept of channels:

guix channel firefox http://some-origin/guix-channels/firefox
guix package -i firefox

so we can make GNU Guix as pure as possible and leverage less pure
concepts (such as Firefox and Conda) into something that is not
considered part of the core project. I think it would also render
other maintenance benefits, for example versioning of old software
would become much easier.

guix channel ruby-1.8 http://some-origin/guix-channels/ruby-1.8
guix package -i ruby

I hope we get something like this at some point.

Pj.

[Katherine Cox-Buday]

Post by Pjotr Prins

Post by Hartmut Goebel
Not packaging FF or crippling FF is a no-go! Doing so will discourage
users from using GuixSD and Free Software.

As an anecdote with a data-point of one, I uninstalled GuixSD because I
suddenly needed the machine I was running it on to be my daily driver. I
had been attempting to package Firefox whenever I had a spare moment,
but I ran out of time and needed it to work as I didn't have time to
migrate all the machines I use to a libre-friendly browser (nor am I
sure I want to).

Post by Pjotr Prins
That is an interesting one. GNU Guix, by virtue of it being a GNU
project needs to abide by GNU free software terms. But even among core
project members there are variations in thought in how to compromise
with user requirements. A package manager that does not target user
needs is a shitty package manager. This is one reason I champion the
guix channel firefox http://some-origin/guix-channels/firefox
guix package -i firefox
so we can make GNU Guix as pure as possible and leverage less pure
concepts (such as Firefox and Conda) into something that is not
considered part of the core project. I think it would also render
other maintenance benefits, for example versioning of old software
would become much easier.
guix channel ruby-1.8 http://some-origin/guix-channels/ruby-1.8
guix package -i ruby
I hope we get something like this at some point.

So do I. I completely agree with the points made elsewhere in this
thread about joining idealism with pragmatism, and I think channels are
a good way to allow people who want/need to run less-than-libre software
to remain with and support Guix, without forcing the project to adopt
software contrary to its goals.

[Tonton]

I guess channels already sort of exist. have a git repo or similar with
whatever guix packages in it and point $GUIX_PACKAGE_PATH at it. Then all
packages defined in your git repo are suddenly part of your available guix
packages.

On Wed, 16 May 2018 10:44:20 -0500

Post by Katherine Cox-Buday

Post by Pjotr Prins

Post by Hartmut Goebel
Not packaging FF or crippling FF is a no-go! Doing so will discourage
users from using GuixSD and Free Software.

As an anecdote with a data-point of one, I uninstalled GuixSD because I
suddenly needed the machine I was running it on to be my daily driver. I
had been attempting to package Firefox whenever I had a spare moment,
but I ran out of time and needed it to work as I didn't have time to
migrate all the machines I use to a libre-friendly browser (nor am I
sure I want to).

Post by Pjotr Prins
That is an interesting one. GNU Guix, by virtue of it being a GNU
project needs to abide by GNU free software terms. But even among core
project members there are variations in thought in how to compromise
with user requirements. A package manager that does not target user
needs is a shitty package manager. This is one reason I champion the
guix channel firefox http://some-origin/guix-channels/firefox
guix package -i firefox
so we can make GNU Guix as pure as possible and leverage less pure
concepts (such as Firefox and Conda) into something that is not
considered part of the core project. I think it would also render
other maintenance benefits, for example versioning of old software
would become much easier.
guix channel ruby-1.8 http://some-origin/guix-channels/ruby-1.8
guix package -i ruby
I hope we get something like this at some point.

So do I. I completely agree with the points made elsewhere in this
thread about joining idealism with pragmatism, and I think channels are
a good way to allow people who want/need to run less-than-libre software
to remain with and support Guix, without forcing the project to adopt
software contrary to its goals.

[Katherine Cox-Buday]

Post by Tonton
I guess channels already sort of exist. have a git repo or similar with
whatever guix packages in it and point $GUIX_PACKAGE_PATH at it. Then all
packages defined in your git repo are suddenly part of your available guix
packages.

I agree this is an option; however, I think there's an important
distinction between the two. Having channels reifies the concept of
different repositories and rallies groups of users around a single
target.

E.g. I've seen several people in this thread mention they had already,
or were trying to, package Firefox (myself included). Had there been an
official non-libre channel, this work might not have been duplicated.

[Christopher Lemmer Webber]

Post by Katherine Cox-Buday

Post by Hartmut Goebel
Not packaging FF or crippling FF is a no-go! Doing so will discourage
users from using GuixSD and Free Software.

As an anecdote with a data-point of one, I uninstalled GuixSD because I
suddenly needed the machine I was running it on to be my daily driver. I
had been attempting to package Firefox whenever I had a spare moment,
but I ran out of time and needed it to work as I didn't have time to
migrate all the machines I use to a libre-friendly browser (nor am I
sure I want to).

I'm sorry to hear we lost you as a user, and hope eventually you can
come back. I suspect that you aren't the only person whom we've lost
due to this.

I think that means that at least one of these three is a priority, IMO:
- Getting Chromium in
- Getting Firefox in (even if we remove the direct link to Mozilla's
extensions page and have to rebrand to Aurora)
- Getting a channels mechanism

These days Guix has nearly everything I need, but this is a clear gap
for many. Icecat helps a tremendous amount (and thank you thank you to
Mark for all your work keeping things patched) but I do think we need to
provide some other browser options.

- Chris

[Mike Gerwitz]

Post by Hartmut Goebel

Post by Mike Gerwitz

Post by Adonay Felipe Nogueira
I have noticed somepeople advocating for packaging Firefox in GNU Guix,
and since FF still has freedom issues, I see it as a no-go.

A simple option for now is to package FF by disabling those features and
_not_ providing an alternative. For example, IceCat loads a different
addon page than FF; we could just load no addon page at all, or a static
one saying that it's something'll we'll get to eventually.

Not packaging FF or crippling FF is a no-go! Doing so will discourage
users from using GuixSD and Free Software.

Packaging Firefox as-is is not an option. In the case of their addon
system, they encourage installation of non-free addons, which is against
the Free Software Distribution Guidelines (FSDG), and is the same reason
that Debian isn't a recommended free software distribution.

https://www.gnu.org/distros/free-system-distribution-guidelines.html

[Pjotr Prins]

Post by Mike Gerwitz
Packaging Firefox as-is is not an option. In the case of their addon
system, they encourage installation of non-free addons, which is against
the Free Software Distribution Guidelines (FSDG), and is the same reason
that Debian isn't a recommended free software distribution.

Which is ridiculous. The Debian project goes to great lengths
providing free software and is an absolute boon to free software in
general.

That they allow users to help package other things is pragmatic and
only grows the community in the end (I agree with Hartmut). Without
distributions like Debian Linux would have been much smaller. Maybe we
should appreciate that and help that form our own strategy.

Last thing I say about it. I appreciate absolute thinking - it is
important to be critical. But we also need to be pragmatic.

Pj.

[Hartmut Goebel]

Post by Mike Gerwitz
In the case of their addon
system, they encourage installation of non-free addons, which is against
the Free Software Distribution Guidelines (FSDG), and is the same reason
that Debian isn't a recommended free software distribution.

My aim is to empower people, not to infantilize them.

If we disable adding add-on, we appoint ourselves as guardian for
immature users. And this IMHO is contrary to "free" (as in "free speech").

We might add some warning on the add-on page like:

Some of the add-ons listed here are no [Free Software](link). Please
check the license prior to installing. (More information »»](link)

This would make people aware of the problem but still give them the
freedom to decide. This is what F-droid does.

[Mike Gerwitz]

Post by Hartmut Goebel

Post by Mike Gerwitz
In the case of their addon
system, they encourage installation of non-free addons, which is against
the Free Software Distribution Guidelines (FSDG), and is the same reason
that Debian isn't a recommended free software distribution.

My aim is to empower people, not to infantilize them.
If we disable adding add-on, we appoint ourselves as guardian for
immature users. And this IMHO is contrary to "free" (as in "free speech").

There might be a miscommunication: I'm not suggesting that we disable
addons (I use many of them), merely that we do not have the default
Firefox addon page, which encourages non-free software. IceCat replaces
it with its own page that uses the free software directory, for example.
Users are free to use that directory; go to addons.mozilla.org
themselves; or install addons however else they choose.

[jah]

Post by Mike Gerwitz
IceCat replaces
it with its own page that uses the free software directory, for example.
Users are free to use that directory; go to addons.mozilla.org
themselves; or install addons however else they choose.

Trisquel maintain a directory of addons too:-

https://trisquel.info/browser-plain

Each item in the list has a link to a page which displays, among other
info, the name of the license and a link to the source code.

[Ludovic Courtès]

All,

I don’t think the harsh words are warranted. Clément reported that some
of the add-ons that IceCat enables by default, which are there to
improve user privacy and autonomy, can cause web sites to behave badly.
Anyone can disable those add-ons, so I think we’re fine, aren’t we?

Also, Guix follows the FSDG as part of its mission, which I think isn’t
news to anyone involved in the discussion, so it seems odd to question
that.

Thanks,
Ludo’.