Packaging a free Firefox

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

Re: Packaging a free Firefox

[Clément Lassieur]

Clément Lassieur <clement@lassieur.org> writes:

> 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
                                                                their  ^
> home-made non-maintened full-of-security-issues Firefox.
>
> What do you think?
> Clément

Re: Packaging a free Firefox

[Nils Gillmann]

Clément Lassieur transcribed 1.5K bytes:
> 
> Clément Lassieur <clement@lassieur.org> writes:
> 
> > 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
>                                                                 their  ^
> > 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.

Re: Packaging a free Firefox

[Nils Gillmann]

Nils Gillmann transcribed 2.4K bytes:
> Clément Lassieur transcribed 1.5K bytes:
> > 
> > Clément Lassieur <clement@lassieur.org> writes:
> > 
> > > 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
> >                                                                 their  ^
> > > 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.

Re: Packaging a free Firefox

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 241 bytes --]


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

next browser (was: Packaging a free Firefox)

[Jack Hill]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

On Thu, 3 May 2018, Pierre Neidhardt wrote:

> 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,

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

Re: next browser (was: Packaging a free Firefox)

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]


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!

-- 
Pierre Neidhardt

Civilization is the limitless multiplication of unnecessary necessities.
		-- Mark Twain

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: next browser (was: Packaging a free Firefox)

[Jack Hill]

On Thu, 3 May 2018, Pierre Neidhardt wrote:

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

You're welcome.

> I will start working on it in the upcoming days.

Great.

> 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.

> Let's keep in touch!

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

Jack

Re: next browser (was: Packaging a free Firefox)

[Andy Patterson]

Hi Jack,

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

[...]

> 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.

> 
> 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

Re: next browser (was: Packaging a free Firefox)

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]


Is anyone able to start Next on GuixSD?  I can't seem to be able to
compile cl-sqlite, it complains that libsqlite3.so is not found:

	https://github.com/next-browser/next/issues/98

Could this be related to cl-cffi not being specifically taylored to
GuixSD?

@Andy: Can you share your cl-cffi package declaration?

-- 
Pierre Neidhardt

Williams and Holland's Law:
	If enough data is collected, anything may be proven by statistical
	methods.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: next browser (was: Packaging a free Firefox)

[ajpatter]

Hi Pierre,

>
> Hi Andy!
>
> Thanks for your help!  Wow, that's a lot of work!
> I hope you find time to commit it upstream, it would be a pity to let it
> go to waste :p
>
> Can you share the full definition of your freetype2 bindings?
> Thanks!
>
> sbcl-cffi-toolchain does not build for me:
>

[...]

> Any clue?

This looks like a problem with the asdf build system that I fixed, but
didn't finish getting pushed. I'll try to submit this again soon. You can
find the original patch here [1].


> --
> Pierre Neidhardt
>
> The sun never sets on those who ride into it.
> 		-- RKO
>

--
Andy

[1] <http://lists.gnu.org/archive/html/guix-patches/2017-04/msg00190.html>

Re: next browser (was: Packaging a free Firefox)

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]


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.

-- 
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: next browser (was: Packaging a free Firefox)

[Andy Patterson]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

Hi Pierre,

On Thu, 10 May 2018 16:36:11 +0200
Pierre Neidhardt <ambrevar@gmail.com> wrote:

> 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

[-- Attachment #2: 0001-gnu-Add-some-lisp-packages.patch --]
[-- Type: text/x-patch, Size: 28479 bytes --]

From 81b0547c40c20ef040e7bc0f2d0623b39bd38098 Mon Sep 17 00:00:00 2001
From: Andy Patterson <ajpatter@uwaterloo.ca>
Date: Thu, 10 May 2018 01:07:22 -0400
Subject: [PATCH] gnu: Add some lisp packages.

---
 gnu/packages/lisp.scm | 727 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 727 insertions(+)

diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 1f8e6ab42..17e709641 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -1433,3 +1433,730 @@ compressor.  It works on data produced by @code{parse-js} to generate a
      `(("sbcl" ,sbcl)
        ("sbcl-cl-uglify-js" ,sbcl-cl-uglify-js)))
     (synopsis "JavaScript compressor")))
+
+(define-public sbcl-closer-mop
+  (package
+    (name "sbcl-closer-mop")
+    (version "1.0.0")
+    (source
+     (origin
+       (method url-fetch)
+       (uri (string-append "https://github.com/pcostanza/closer-mop"
+                           "/archive/v" version ".tar.gz"))
+       (sha256
+        (base32 "1pyc8lk2yxbjhycm57377vhxy0xrh2pmg0w89m7fifan6haiisbl"))
+       (file-name (string-append "closer-mop-" version ".tar.gz"))))
+    (build-system asdf-build-system/sbcl)
+    (home-page "https://github.com/pcostanza/closer-mop/")
+    (synopsis "Meta Object Protocol (MOP) compatibility layer")
+    (description "Closer to MOP is a compatibility layer that rectifies many
+of the absent or incorrect CLOS MOP features across a broad range of Common
+Lisp implementations.")
+    (license license:x11)))
+
+(define-public sbcl-trivial-types
+  (let ((commit "ee869f2b7504d8aa9a74403641a5b42b16f47d88")
+        (revision "1"))
+    (package
+      (name "sbcl-trivial-types")
+      (version (string-append "0.1-" revision "." (string-take commit 7)))
+      (source
+       (origin
+         (method git-fetch)
+         (uri (git-reference
+               (url "https://github.com/m2ym/trivial-types.git")
+               (commit commit)))
+         (sha256
+          (base32 "1s4cp9bdlbn8447q7w7f1wkgwrbvfzp20mgs307l5pxvdslin341"))
+         (file-name (string-append "trivial-types-" version "-checkout"))))
+      (build-system asdf-build-system/sbcl)
+      (home-page "https://github.com/m2ym/trivial-types")
+      (synopsis "Trivial type definitions")
+      (description "TRIVIAL-TYPES provides missing but important type
+definitions such as PROPER-LIST, ASSOCIATION-LIST, PROPERTY-LIST and TUPLE.
+By using these types, you can keep type declarations more accurate. For
+example, you may write a class definition like:
+
+@example
+(defclass person ()
+  ((name :type string))
+  ((age :type fixnum))
+  ((friends :type list)))
+@end example
+
+However, it is not obvious for anyone except you that FRIENDS slot has
+only a list of person. If you want declare FRIENDS slot more
+accurately, PROPER-LIST is the best for that:
+
+@example
+(defclass person ()
+  ((name :type string))
+  ((age :type fixnum))
+  ((friends :type (proper-list person))))
+@end example
+
+In addition, TRIVIAL-TYPES also provides standard designators defined
+in ANSI standard such as PACKAGE-DESIGNATOR. They are useful when you
+write a function that takes a package-oid argument like:
+
+@example
+(defun list-external-symbols (package)
+  (declare (package-designator package))
+  (loop for symbol being the external-symbol of package
+        collect symbol))
+@end example
+")
+      (license license:lgpl2.0+))))
+
+(define-public sbcl-named-readtables
+  (let ((commit "4dfb89fa1af6b305b6492b8af042f5190c11e9fc")
+        (revision "1"))
+    (package
+      (name "sbcl-named-readtables")
+      (version (string-append "0.9-" revision "." (string-take commit 7)))
+      (source
+       (origin
+         (method git-fetch)
+         (uri (git-reference
+
+               (url "https://github.com/melisgl/named-readtables.git")
+               (commit commit)))
+         (sha256
+          (base32 "083kgh5462iqbb4px6kq8s7sggvpvkm36hx4qi9rnaw53b6ilqkk"))
+         (file-name (string-append "named-readtables-" version "-checkout"))))
+      (build-system asdf-build-system/sbcl)
+      (home-page "https://github.com/melisgl/named-readtables/")
+      (synopsis "Library that creates a namespace for named readtables")
+      (description "Named readtables is a library that creates a namespace for
+named readtables, which is akin to package namespacing in Common Lisp.")
+      (license license:bsd-3))))
+
+(define-public sbcl-cl-interpol
+  (package
+    (name "sbcl-cl-interpol")
+    (version "0.2.6")
+    (source
+     (origin
+       (method url-fetch)
+       (uri (string-append "https://github.com/edicl/cl-interpol"
+                           "/archive/v" version ".tar.gz"))
+       (sha256
+        (base32 "1cdl0dn55nsrr9w5ykzfgwh3f76n4k7g9cd1i6d90nqsdcnnwc3x"))
+       (file-name (string-append "cl-interpol-" version ".tar.gz"))))
+    (build-system asdf-build-system/sbcl)
+    (inputs `(("cl-unicode" ,sbcl-cl-unicode)))
+    (native-inputs `(("flexi-streams" ,sbcl-flexi-streams)))
+    (home-page "http://weitz.de/cl-interpol/")
+    (synopsis "String interpolation library for Common Lisp")
+    (description "CL-INTERPOL is a library for Common Lisp which modifies the
+reader so that you can have interpolation within strings similar to Perl or
+Unix Shell scripts.  It also provides various ways to insert arbitrary
+characters into literal strings even if your editor/IDE doesn't support
+them.")
+    (license license:bsd-2)))
+
+(define-public sbcl-split-sequence
+  (package
+    (name "sbcl-split-sequence")
+    (version "1.4")
+    (source
+     (origin
+       (method url-fetch)
+       (uri (string-append "https://github.com/sharplispers/split-sequence"
+                           "/archive/v" version ".tar.gz"))
+       (sha256
+        (base32 "12qgmnas2vd1wgyddf4fv2j5xsaj5mb2r0ylh043bwr6986gdbqa"))
+       (file-name (string-append "split-sequence-" version ".tar.gz"))))
+    (build-system asdf-build-system/sbcl)
+    (native-inputs `(("fiveam" ,sbcl-fiveam)))
+    (home-page "http://cliki.net/split-sequence")
+    (synopsis "Common Lisp utility to split sequences")
+    (description "A Common Lisp library whose purpose is to split a sequence
+into a list of subsequences delimited by objects satisfying a test.")
+    (license license:public-domain)))
+
+(define-public sbcl-rt
+  (let ((revision "1")
+        (commit "a6a7503a0b47953bc7579c90f02a6dba1f6e4c5a"))
+    (package
+      (name "sbcl-rt")
+      (version (string-append "0.0.0-" revision "." (string-take commit 7)))
+      (source
+       (origin
+         (method git-fetch)
+         (uri
+          (git-reference
+           (url "http://git.kpe.io/rt.git")
+           (commit commit)))
+         (sha256
+          (base32 "13si2rrxaagbr0bkvg6sqicxxpyshabx6ad6byc9n2ik5ysna69b"))
+         (file-name (string-append "rt-" version "-checkout"))))
+      (build-system asdf-build-system/sbcl)
+      (home-page "http://www.cliki.net/RT")
+      (synopsis "Regression testing framework")
+      (description "@code{rt} is short for \"regression testing\", an older
+test tramework from the CMU AI Repository.")
+      (license (list
+                license:lgpl3 ; for rt.asd
+                license:expat))))) ; for rt.lisp
+
+(define-public sbcl-hu.dwim.asdf
+  (let ((revision "1")
+        (commit "170b0e4fdde3df0bc537327e7600575daac9e141"))
+    (package
+      (name "sbcl-hu.dwim.asdf")
+      (version (string-append "0.0.0-" revision "." (string-take commit 7)))
+      (source
+       (origin
+         (method git-fetch)
+         (uri
+          (git-reference
+           (url "https://github.com/nixeagle/hu.dwim.asdf")
+           (commit commit)))
+         (sha256
+          (base32 "10ax7p8y6vjqxzcq125p62kf68zi455a65ysgk0kl1f2v839c33v"))
+         (file-name (string-append "hu.dwim.asdf-" version "-checkout"))))
+      (build-system asdf-build-system/sbcl)
+      (home-page "http://hub.darcs.net/hu.dwim/hu.dwim.asdf")
+      (synopsis "Extensions to ASDF")
+      (description "Various ASDF extensions such as attached test and
+documentation system, explicit development support, etc.")
+      (license license:public-domain))))
+
+(define-public sbcl-hu.dwim.stefil
+  (let ((revision "1")
+        (commit "ab6d1aa8995878a1b66d745dfd0ba021090bbcf9"))
+    (package
+      (name "sbcl-hu.dwim.stefil")
+      (version (string-append "0.0.0-" revision "." (string-take commit 7)))
+      (source
+       (origin
+         (method git-fetch)
+         (uri
+          (git-reference
+           (url "https://gitlab.common-lisp.net/xcvb/hu.dwim.stefil.git")
+           (commit commit)))
+         (sha256
+          (base32 "1d8yccw65zj3zh46cbi3x6nmn1dwdb76s9d0av035077mvyirqqp"))
+         (file-name (string-append "hu.dwim.stefil-" version "-checkout"))))
+      (build-system asdf-build-system/sbcl)
+      (native-inputs
+       `(("asdf:cl-hu.dwim.asdf" ,sbcl-hu.dwim.asdf)))
+      (inputs
+       `(("sbcl-alexandria" ,sbcl-alexandria)))
+      (home-page "http://hub.darcs.net/hu.dwim/hu.dwim.stefil")
+      (synopsis "Simple test framework")
+      (description "Stefil is a simple test framework for Common Lisp,
+with a focus on interactive development.")
+      (license license:public-domain))))
+
+(define-public sbcl-repl-utilities
+  (let ((commit "e0de9c92e774f77cab1a4cd92e2ac922ac3a807e")
+        (revision "1"))
+    (package
+      (name "sbcl-repl-utilities")
+      (version (string-append "0.0.0-" revision "." (string-take commit 7)))
+      (source
+       (origin
+         (method git-fetch)
+         (uri (git-reference
+               (url "https://github.com/m-n/repl-utilities.git")
+               (commit commit)))
+         (sha256
+          (base32 "1r5icmw3ha5y77kvzqni3a9bcd66d9pz5mjsbw04xg3jk0d15cgz"))
+         (file-name (string-append "repl-utilities" version "-checkout"))))
+      (build-system asdf-build-system/sbcl)
+      (home-page "https://github.com/m-n/repl-utilities/")
+      (synopsis "Library to simplify life at the REPL")
+      (description "REPL-Utilities provides a set of features which makes the
+use of the Read-Eval-Print-Loop (REPL) easier for common tasks.")
+      (license license:bsd-3))))
+
+(define-public sbcl-babel
+  (package
+    (name "sbcl-babel")
+    (version "0.5.0")
+    (source
+     (origin
+       (method url-fetch)
+       (uri (string-append
+             "https://github.com/cl-babel/babel/archive/v"
+             version ".tar.gz"))
+       (sha256
+        (base32 "189kgbmslh36xx0d2i1g6a7mcvjryvjzkdlnhilqy5xs7hkyqirq"))
+       (file-name (string-append name "-" version ".tar.gz"))))
+    (build-system asdf-build-system/sbcl)
+    (native-inputs
+     `(("tests:cl-hu.dwim.stefil" ,sbcl-hu.dwim.stefil)))
+    (inputs
+     `(("sbcl-alexandria" ,sbcl-alexandria)
+       ("sbcl-trivial-features" ,sbcl-trivial-features-bootstrap)))
+    (home-page "https://common-lisp.net/project/babel/")
+    (synopsis "Charset encoding and decoding library")
+    (description "Babel is a charset encoding and decoding library, not unlike
+GNU libiconv, but completely written in Common Lisp.")
+    (license license:x11)))
+
+(define-public sbcl-cffi-bootstrap
+  (package
+    (name "sbcl-cffi-bootstrap")
+    (version "0.18.0")
+    (source
+     (origin
+       (method url-fetch)
+       (uri (string-append "https://github.com/cffi/cffi/archive/v"
+                           version ".tar.gz"))
+       (sha256
+        (base32 "0ac40z3sg5szhm99l3bjpm0v1yz2vlhc6scqx1qzvlfcawc66m9q"))
+       (file-name (string-append name "-" version ".tar.gz"))))
+    (build-system asdf-build-system/sbcl)
+    (inputs
+     `(("libffi" ,libffi)
+       ("alexandria" ,sbcl-alexandria)
+       ("babel" ,sbcl-babel)
+       ("trivial-features" ,sbcl-trivial-features-bootstrap)))
+    (native-inputs
+     `(("pkg-config" ,pkg-config)))
+    (arguments
+     '(#:phases
+       (modify-phases %standard-phases
+         (add-after 'unpack 'fix-paths
+           (lambda* (#:key inputs #:allow-other-keys)
+             (substitute* "libffi/libffi.lisp"
+               (("libffi.so.6" all) (string-append
+                                     (assoc-ref inputs "libffi")
+                                     "/lib/" all)))
+             (substitute* "toolchain/c-toolchain.lisp"
+               (("\"cc\"") (format #f "~S" (which "gcc")))))))
+       #:asd-system-name "cffi"
+       #:tests? #f))
+    (home-page "http://common-lisp.net/project/cffi")
+    (synopsis "Common Foreign Function Interface for Common Lisp")
+    (description "The Common Foreign Function Interface (CFFI)
+purports to be a portable foreign function interface for Common Lisp.
+The CFFI library is composed of a Lisp-implementation-specific backend
+in the CFFI-SYS package, and a portable frontend in the CFFI
+package.")
+    (license license:x11)))
+
+(define-public sbcl-cffi-toolchain
+  (package
+    (inherit sbcl-cffi-bootstrap)
+    (name "sbcl-cffi-toolchain")
+    (inputs
+     `(("libffi" ,libffi)
+       ("sbcl-cffi" ,sbcl-cffi-bootstrap)))
+    (arguments
+     (substitute-keyword-arguments (package-arguments sbcl-cffi-bootstrap)
+       ((#:asd-system-name _) #f)
+       ((#:tests? _) #t)))))
+
+(define-public sbcl-cffi-libffi
+  (package
+    (inherit sbcl-cffi-toolchain)
+    (name "sbcl-cffi-libffi")
+    (inputs
+     `(("cffi" ,sbcl-cffi-bootstrap)
+       ("cffi-grovel" ,sbcl-cffi-grovel)
+       ("trivial-features" ,sbcl-trivial-features-bootstrap)
+       ("libffi" ,libffi)))))
+
+(define-public sbcl-cffi-grovel
+  (package
+    (inherit sbcl-cffi-toolchain)
+    (name "sbcl-cffi-grovel")
+    (inputs
+     `(("libffi" ,libffi)
+       ("cffi" ,sbcl-cffi-bootstrap)
+       ("cffi-toolchain" ,sbcl-cffi-toolchain)
+       ("alexandria" ,sbcl-alexandria)))
+    (arguments
+     (substitute-keyword-arguments (package-arguments sbcl-cffi-toolchain)
+       ((#:phases phases)
+        `(modify-phases ,phases
+           (add-after 'build 'install-headers
+             (lambda* (#:key outputs #:allow-other-keys)
+               (install-file "grovel/common.h"
+                             (string-append
+                              (assoc-ref outputs "out")
+                              "/include/grovel"))))))))))
+
+(define-public sbcl-cffi
+  (package
+    (inherit sbcl-cffi-toolchain)
+    (name "sbcl-cffi")
+    (inputs (package-inputs sbcl-cffi-bootstrap))
+    (native-inputs
+     `(("cffi-grovel" ,sbcl-cffi-grovel)
+       ("cffi-libffi" ,sbcl-cffi-libffi)
+       ("rt" ,sbcl-rt)
+       ("bordeaux-threads" ,sbcl-bordeaux-threads)
+       ,@(package-native-inputs sbcl-cffi-bootstrap)))))
+
+(define-public sbcl-trivial-features-bootstrap
+  (package
+    (name "sbcl-trivial-features")
+    (version "0.8")
+    (source
+     (origin
+       (method url-fetch)
+       (uri (string-append
+             "https://github.com/trivial-features/trivial-features/archive/v"
+             version ".tar.gz"))
+       (sha256
+        (base32 "0db1awn6jyhcfhyfvpjvfziprmq85cigf19mwbvaprhblydsag3c"))
+       (file-name (string-append "trivial-features-" version ".tar.gz"))))
+    (build-system asdf-build-system/sbcl)
+    (arguments '(#:tests? #f))
+    (home-page "http://cliki.net/trivial-features")
+    (synopsis "Ensures consistency of @code{*FEATURES*} in Common Lisp")
+    (description "Trivial-features ensures that @code{*FEATURES*} is
+consistent across multiple Common Lisp implementations.")
+    (license license:x11)))
+
+(define-public sbcl-osicat
+  (package
+    (name "sbcl-osicat")
+    (version "0.7.0")
+    (source
+     (origin
+       (method url-fetch)
+       (uri (string-append "https://github.com/osicat/osicat/archive/v"
+                           version ".tar.gz"))
+       (sha256
+        (base32
+         "10g8gvmnpl94c3iqf6nav663brk1qnc9wyz46q3vk4i77pbl63r6"))
+       (file-name (string-append "osicat-" version ".tar.gz"))))
+    (build-system asdf-build-system/sbcl)
+    (inputs
+     `(("cffi" ,sbcl-cffi)
+       ("alexandria" ,sbcl-alexandria)
+       ("trivial-features" ,sbcl-trivial-features-bootstrap)))
+    (native-inputs
+     `(("cffi-grovel" ,sbcl-cffi-grovel)
+       ("rt" ,sbcl-rt)))
+    (arguments
+     '(#:phases
+       (modify-phases %standard-phases
+         ;; We don't want the libraries in lib/<lisp>/posix re-parented.
+         (delete 'cleanup))))
+    (home-page "https://common-lisp.net/project/osicat/")
+    (synopsis "Lightweight operating system interface for Common Lisp")
+    (description "Osicat is a lightweight operating system interface for
+Common Lisp on POSIX-like systems, including Windows.")
+    (license license:x11)))
+
+(define-public sbcl-iterate
+  (let ((hash "e65a5020b5392fbb6be1cd4d3190d4e3fbe00f52")
+        (revision "1"))
+    (package
+      (name "sbcl-iterate")
+      (version (string-append "0.0.0-" revision "." (string-take hash 7)))
+      (source
+       (origin
+         (method darcs-fetch)
+         (uri
+          (darcs-reference
+           (url "https://www.common-lisp.net/project/iterate/darcs/iterate/")
+           (hash hash)))
+         (sha256
+          (base32 "1y7smkpa7haxmq17yrph8ax8lgc549pgc9sbzwz1bynqqycfj8id"))
+         (file-name (string-append "iterate-" version "-checkout"))))
+      (build-system asdf-build-system/sbcl)
+      (native-inputs
+       `(("rt" ,sbcl-rt)))
+      (home-page "https://common-lisp.net/project/iterate/")
+      (synopsis "Iteration facility for Common Lisp")
+      (description "Iterate is an iteration construct for Common Lisp. It is
+similar to the CL:LOOP macro, with these distinguishing marks:
+
+@enumerate
+@item It is extensible.
+@item It helps editors like Emacs indent iterate forms by having a more
+lisp-like syntax.
+@item It isn't part of the ANSI standard for Common Lisp.
+@end enumerate
+")
+      (license license:isc))))
+
+(define-public sbcl-anaphora
+  (package
+    (name "sbcl-anaphora")
+    (version "0.9.6")
+    (source
+     (origin
+       (method url-fetch)
+       (uri "https://github.com/tokenrove/anaphora/archive/0.9.6.tar.gz")
+       (file-name (string-append "anaphora-" version ".tar.gz"))
+       (sha256
+        (base32 "0bp8vg0y4ljla3i9322lyddmys4gzzhqq97zz4bjn46qrk5dvywl"))))
+    (build-system asdf-build-system/sbcl)
+    (native-inputs
+     `(("rt" ,sbcl-rt)))
+    (home-page "https://common-lisp.net/project/anaphora/")
+    (synopsis "Anaphoric macro package for Common Lisp")
+    (description "Anaphora is the anaphoric macro collection from Hell: it
+includes many new fiends in addition to old friends like AIF and AWHEN.")
+    (license license:public-domain)))
+
+(define-public sbcl-lift
+  (let ((commit "7d49a66c62759535624037826891152223d4206c")
+        (revision "1"))
+    (package
+      (name "sbcl-lift")
+      (version (string-append "0.0.0-" revision "." (string-take commit 7)))
+      (source
+       (origin
+         (method git-fetch)
+         (uri
+          (git-reference
+           (url "https://github.com/gwkkwg/lift.git")
+           (commit commit)))
+         (file-name (string-append "lift-" version "-checkout"))
+         (sha256
+          (base32 "127v5avpz1i4m0lkaxqrq8hrl69rdazqaxf6s8awf0nd7wj2g4dp"))))
+      (build-system asdf-build-system/sbcl)
+      (arguments
+       ;; The tests require a debugger, but we run with the debugger disabled.
+       '(#:tests? #f
+         #:phases
+         (modify-phases %standard-phases
+           ;; Do this to ensure the 'reset-gzip-timestamps phase works.
+           (add-after 'unpack 'make-gzips-writeable
+             (lambda _
+               (for-each (lambda (file)
+                           (chmod file #o755))
+                         (find-files "." "\\.gz$")))))))
+      ;; XXX: https://www.common-lisp.net/project/lift is gone for some reason.
+      (home-page "https://www.common-lisp.net/project/lift/user-guide.html")
+      (synopsis "Common Lisp test framework")
+      (description "LIFT is the LIsp Framework for Testing.  It is an SUnit
+variant.")
+      (license license:x11-style))))
+
+(define-public sbcl-let-plus
+  (let ((commit "77efafd94aba3943d4289fcc88377fe9240448a8")
+        (revision "1"))
+    (package
+      (name "sbcl-let-plus")
+      (version (string-append "0.0.0-" revision "." (string-take commit 7)))
+      (source
+       (origin
+         (method git-fetch)
+         (uri
+          (git-reference
+           (url "https://github.com/tpapp/let-plus.git")
+           (commit commit)))
+         (file-name (string-append "let-plus-" version "-checkout"))
+         (sha256
+          (base32 "07vgp2a4szdb07bph7iv2r067x4csl68nw3hjgdfxpmz08nr1jnv"))))
+      (build-system asdf-build-system/sbcl)
+      (inputs
+       `(("anaphora" ,sbcl-anaphora)
+         ("alexandria" ,sbcl-alexandria)))
+      (native-inputs
+       `(("lift" ,sbcl-lift)))
+      (home-page "https://github.com/tpapp/let-plus")
+      (synopsis "Destructuring extension of let*")
+      (description "Library which implements the let+ macro, which is a
+dectructuring extension of let*.  It features:
+
+@enumerate
+@item placeholder macros allow editor hints and syntax highlighting
+@item &ign for ignored values (in forms where that makes sense)
+@item very easy to extend
+@end enumerate
+")
+      (license license:boost1.0))))
+
+(define-public sbcl-cl-colors
+  (let ((commit "1867afb1fe75dcc8b72f139a4bb5290b70bc1cad")
+        (revision "1"))
+    (package
+      (name "sbcl-cl-colors")
+      (version (string-append "0.0.0-" revision "." (string-take commit 7)))
+      (source
+       (origin
+         (method git-fetch)
+         (uri
+          (git-reference
+           (url "https://github.com/tpapp/cl-colors.git")
+           (commit commit)))
+         (file-name (string-append "cl-colours-" version "-checkout"))
+         (sha256
+          (base32 "139j94vwa5ygzzk4w4aij6z75wh4ymlkpqj28h7vxp6ixchx668s"))))
+      (build-system asdf-build-system/sbcl)
+      (inputs
+       `(("alexandria" ,sbcl-alexandria)
+         ("let-plus" ,sbcl-let-plus)))
+      (home-page "http://www.cliki.net/cl-colors")
+      (synopsis "Simple color library for Common Lisp")
+      (description "CL-colors is a very simple color library for Common Lisp.
+It provides:
+
+@enumerate
+@item Types for representing colors in HSV and RGB spaces.
+@item Simple conversion functions between the above types.
+@item Some predefined colors (currently X11 color names).
+@end enumerate
+")
+      (license license:boost1.0))))
+
+(define-public sbcl-cl-ansi-text
+  (let ((commit "53badf7878f27f22f2d4a2a43e6df458e43acbe9")
+        (revision "1"))
+    (package
+      (name "sbcl-cl-ansi-text")
+      (version (git-version "0.0.0" revision commit))
+      (source
+       (origin
+         (method git-fetch)
+         (uri
+          (git-reference
+           (url "https://github.com/pnathan/cl-ansi-text.git")
+           (commit commit)))
+         (file-name (git-file-name "cl-ansi-text" version))
+         (sha256
+          (base32 "11i27n0dbz5lmygiw65zzr8lx0rac6b6yysqranphn31wls6ja3v"))))
+      (build-system asdf-build-system/sbcl)
+      (inputs
+       `(("alexandria" ,sbcl-alexandria)
+         ("cl-colors" ,sbcl-cl-colors)))
+      (home-page "https://github.com/pnathan/cl-ansi-text")
+      (synopsis "ANSI terminal color implementation for Common Lisp")
+      (description "CL-ansi-text provides utilities which enable printing to
+an ANSI terminal with colored text.  It provides the macro with-color which
+causes everything printed in the body to be displayed with the provided color.
+It further provides functions which will print the argument with the named
+color.")
+      (license license:lgpl2.0+))))
+
+(define-public sbcl-prove-asdf
+  (let ((commit "e217d243a5e363e44951c096072ff8e57824db93")
+        (revision "1"))
+    (package
+      (name "sbcl-prove-asdf")
+      (version (git-version "1.0.0" revision commit))
+      (source
+       (origin
+         (method git-fetch)
+         (uri
+          (git-reference
+           (url "https://github.com/fukamachi/prove.git")
+           (commit commit)))
+         (file-name (git-file-name "prove" version))
+         (sha256
+          (base32 "0xbr6prv096fjha1fnfwv5vh5w7r6rhw3fbb2sxw92nmvnj33cbk"))))
+      (build-system asdf-build-system/sbcl)
+      (home-page "https://github.com/fukamachi/prove")
+      (synopsis "Unit testing framework for Common Lisp")
+      (description "Prove is yet another unit testing framework for Common
+Lisp.
+It features:
+
+@enumerate
+@item Various simple functions for testing and informative error messages
+@item ASDF integration
+@item Extensible test reporters
+@item Colorizes the report if it's available
+@item Reports test durations
+@end enumerate
+")
+      (license license:x11))))
+
+(define-public sbcl-prove
+  (package
+    (inherit sbcl-prove-asdf)
+    (name "sbcl-prove")
+    (inputs
+     `(("alexandria" ,sbcl-alexandria)
+       ("cl-ansi-text" ,sbcl-cl-ansi-text)
+       ("cl-colors" ,sbcl-cl-colors)
+       ("cl-ppcre" ,sbcl-cl-ppcre)))
+    (native-inputs
+     `(("prove-asdf" ,sbcl-prove-asdf)
+       ("split-sequence" ,sbcl-split-sequence)))))
+
+(define-public sbcl-cl-test-more
+  (package
+    (inherit sbcl-prove)
+    (name "sbcl-cl-test-more")
+    (inputs
+     `(("prove" ,sbcl-prove)))
+    (arguments
+     '(#:phases
+       (modify-phases %standard-phases
+         ;; There are no output files so we need to handle this differently.
+         (add-before 'create-asd-file 'ensure-libdir-exists
+           (lambda* (#:key outputs #:allow-other-keys)
+             (mkdir-p (string-append
+                       (assoc-ref outputs "out") "/lib/" (%lisp-type)))))
+         ;; There are no components in this alias system.
+         (add-after 'create-asd-file 'remove-component-from-asd-file
+           (lambda* (#:key outputs #:allow-other-keys)
+             (define asd-file
+               (string-append
+                (assoc-ref outputs "out")
+                "/lib/" (%lisp-type) "/cl-test-more.asd"))
+             (substitute* asd-file
+               ((":components") "")
+               (("\\(\\(:compiled.*") ")")))))))))
+
+(define-public sbcl-cl21
+  (let ((commit "c36644f3b6ea4975174c8ce72de43a4524dd0696")
+        (revision "1"))
+    (package
+      (name "sbcl-cl21")
+      (version (git-version "0.0.0" revision commit))
+      (source
+       (origin
+         (method git-fetch)
+         (uri (git-reference
+               (url "https://github.com/cl21/cl21.git")
+               (commit commit)))
+         (sha256
+          (base32 "0pa0dx33br6ckhqlq7z7x562y1naidd5qns23pcbjnq1isfc5k8l"))
+         (file-name (string-append "cl21-" version "-checkout"))))
+      (build-system asdf-build-system/sbcl)
+      (inputs
+       `(("cl-ppcre" ,sbcl-cl-ppcre)
+         ("trivial-gray-streams" ,sbcl-trivial-gray-streams)
+         ("trivial-types" ,sbcl-trivial-types)
+         ("named-readtables" ,sbcl-named-readtables)
+         ("cl-interpol" ,sbcl-cl-interpol)
+         ("split-sequence" ,sbcl-split-sequence)
+         ("alexandria" ,sbcl-alexandria)
+         ("repl-utilities" ,sbcl-repl-utilities)
+         ("osicat" ,sbcl-osicat)
+         ("iterate" ,sbcl-iterate)
+         ("closer-mop" ,sbcl-closer-mop)))
+      (native-inputs
+       `(("cl-test-more" ,sbcl-cl-test-more)))
+      (arguments
+       '(#:phases
+         (modify-phases %standard-phases
+           (add-before 'check 'add-load-path
+             (lambda* (#:key outputs #:allow-other-keys)
+               (define path
+                 (string-append
+                  (assoc-ref outputs "out") %source-install-prefix "//"))
+               ;; XXX: After successfully running the tests, asdf complains
+               ;; that it cannot find the test system. Odd. Hack around it for
+               ;; now.
+               (prepend-to-source-registry path)
+               #t)))))
+      (home-page "http://cl21.org/")
+      (synopsis "Common Lisp in the 21st century")
+      (description "CL21 is an experimental project redesigning Common Lisp,
+which features:
+
+@enumerate
+@item More object oriented.
+@item Add more functional programming facilities.
+@item Organize symbols into several packages.
+@item Include MOP.
+@item Syntax for regular expression.
+@item Written in pure Common Lisp.
+@end enumerate
+")
+      (license license:unlicense))))
-- 
2.17.0

Re: next browser (was: Packaging a free Firefox)

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]


Hooray, I've managed to run Next Browser on GuixSD!

The main issue is with cffi: it does not find the libraries installed by Guix.

Andy's CFFI package does not seem to cut it.  I've asked on the CFFI
mailing list and received the following suggestion:

	https://mailman.common-lisp.net/pipermail/cffi-devel/2018-May/003051.html

Now to the question of packaging CFFI for Guix: which road shall we
follow?

- Package CFFI as-is and tweak `cffi:*foreign-library-directories*` when
  packaging packages that depend on it.

- Package a patched version of CFFI to lookup a specific library
  folder... But I'm not sure which one.

The problem with the first solution is that I'm not sure we can apply it
with the way ASDF works with common lisp system like Next.  Here follow
Next's Makefile:

--8<---------------cut here---------------start------------->8---
LISP?=sbcl

build-gtk:
	$(LISP) \
		--load next.asd \
		--eval '(ql:quickload :next/gtk)' \
		--eval '(asdf:make :next/gtk)' \
		--eval '(quit)'
--8<---------------cut here---------------end--------------->8---

We could patch it to

--8<---------------cut here---------------start------------->8---
LISP?=sbcl

build-gtk:
	$(LISP) \
		--eval '(ql:quickload :cffi)' \
		--eval '(push (format nil "~a/.guix-profile/lib/" (uiop:getenv "HOME")) cffi:*foreign-library-directories*)' \
    ## Rest is as usual.
		--load next.asd \
		--eval '(ql:quickload :next/gtk)' \
		--eval '(asdf:make :next/gtk)' \
		--eval '(quit)'
--8<---------------cut here---------------end--------------->8---

Or maybe just set `LISP=sbcl --eval '(ql:quickload :cffi...)`.

Suggestions?

--
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: next browser (was: Packaging a free Firefox)

[Ricardo Wurmus]

Hi Pierre,

> Hooray, I've managed to run Next Browser on GuixSD!

Excellent!  I’m looking forward to playing with it.

> The main issue is with cffi: it does not find the libraries installed by Guix.
[…]

I don’t understand this.  Should it load any libraries that the user may
have installed?  Or do you only refer to a specific set of libraries
that is known at build time?

> --8<---------------cut here---------------start------------->8---
> LISP?=sbcl
>
> build-gtk:
> 	$(LISP) \
> 		--eval '(ql:quickload :cffi)' \
> 		--eval '(push (format nil "~a/.guix-profile/lib/" (uiop:getenv "HOME")) cffi:*foreign-library-directories*)' \
>     ## Rest is as usual.
> 		--load next.asd \
> 		--eval '(ql:quickload :next/gtk)' \
> 		--eval '(asdf:make :next/gtk)' \
> 		--eval '(quit)'
> --8<---------------cut here---------------end--------------->8---

This would not be good, because packages can be installed in different
profiles, not only in the user’s home directory.

-- 
Ricardo

Re: next browser (was: Packaging a free Firefox)

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]


Ricardo Wurmus <rekado@elephly.net> writes:

>> The main issue is with cffi: it does not find the libraries installed by Guix.
> […]
>
> I don’t understand this.  Should it load any libraries that the user may
> have installed?  Or do you only refer to a specific set of libraries
> that is known at build time?

Sorry for the confusing report, I suppose it needs more details: cffi is
the "common foreign function interface" for Common Lisp.  It allows for
writing bindings to libraries written in different languages (mostly C
as far as I understand).

	http://common-lisp.net/project/cffi

cffi-based projects like Next load libraries at runtime (in
this case .so files).  No special provision is taken for finding those
libaries, or at least nothing I could spot from the source code.  I
understand that it relies on system calls.  But while
dlopen("libsqlite3.so") works in C, cffi fails to load "libsqlite3.so",
unless we specify an appropriate LD_LIBRARY_PATH.

I'm not quite sure how applications find libraries on GuixSD.

>> --8<---------------cut here---------------start------------->8---
>> LISP?=sbcl
>>
>> build-gtk:
>> 	$(LISP) \
>> 		--eval '(ql:quickload :cffi)' \
>> 		--eval '(push (format nil "~a/.guix-profile/lib/" (uiop:getenv "HOME")) cffi:*foreign-library-directories*)' \
>>     ## Rest is as usual.
>> 		--load next.asd \
>> 		--eval '(ql:quickload :next/gtk)' \
>> 		--eval '(asdf:make :next/gtk)' \
>> 		--eval '(quit)'
>> --8<---------------cut here---------------end--------------->8---
>
> This would not be good, because packages can be installed in different
> profiles, not only in the user’s home directory.

Indeed, but I don't know a better solution.  Any idea how to do this
properly?

GuixSD has LIBRARY_PATH=~/.guix-profile/lib, can we use that?

-- 
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: next browser (was: Packaging a free Firefox)

[Ricardo Wurmus]

Hi Pierre,

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>>> The main issue is with cffi: it does not find the libraries installed by Guix.
>> […]
>>
>> I don’t understand this.  Should it load any libraries that the user may
>> have installed?  Or do you only refer to a specific set of libraries
>> that is known at build time?
>
> Sorry for the confusing report, I suppose it needs more details: cffi is
> the "common foreign function interface" for Common Lisp.  It allows for
> writing bindings to libraries written in different languages (mostly C
> as far as I understand).
>
> 	http://common-lisp.net/project/cffi
>
> cffi-based projects like Next load libraries at runtime (in
> this case .so files).  No special provision is taken for finding those
> libaries, or at least nothing I could spot from the source code.  I
> understand that it relies on system calls.  But while
> dlopen("libsqlite3.so") works in C, cffi fails to load "libsqlite3.so",
> unless we specify an appropriate LD_LIBRARY_PATH.

It is sometimes possible to patch the sources by replacing the library
name with the full path of the library.  Have you tried that?

Another option is to wrap the executable in LD_LIBRARY_PATH, although
that should only be a last resort.

> GuixSD has LIBRARY_PATH=~/.guix-profile/lib, can we use that?

LIBRARY_PATH is only set when you have gcc-toolchain installed.  I don’t
have this variable.  It is also not applicable here: it is used by the
compiler at build time when linking applications.

--
Ricardo

Re: next browser (was: Packaging a free Firefox)

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]


Ricardo Wurmus <rekado@elephly.net> writes:

> It is sometimes possible to patch the sources by replacing the library
> name with the full path of the library.  Have you tried that?

You are right.  I think what we need here is to patch all the cffi
packages.
For instance, sqlite3-lib contains the following lines:

--8<---------------cut here---------------start------------->8---
(define-foreign-library sqlite3-lib
  (:darwin (:default "libsqlite3"))
  (:unix (:or "libsqlite3.so.0" "libsqlite3.so"))
  (t (:or (:default "libsqlite3") (:default "sqlite3"))))
--8<---------------cut here---------------end--------------->8---

Patching with the full path should work.  I'll see what I can do.

Maybe we should think of a function to do that automatically for all
cffi packages.  Not sure how doable that'd be.

> Another option is to wrap the executable in LD_LIBRARY_PATH, although
> that should only be a last resort.
>
>> GuixSD has LIBRARY_PATH=~/.guix-profile/lib, can we use that?
>
> LIBRARY_PATH is only set when you have gcc-toolchain installed.  I don’t
> have this variable.  It is also not applicable here: it is used by the
> compiler at build time when linking applications.

So to what would you wrap it?  The full path of the required libs?  E.g.

LD_LIBRARY_PATH=/gnu/store/sdin91pj2w7m5avvb6vykh6haq8q2ni0-sqlite-3.21.0/lib/:...

-- 
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: next browser (was: Packaging a free Firefox)

[Ricardo Wurmus]

Pierre Neidhardt <ambrevar@gmail.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> It is sometimes possible to patch the sources by replacing the library
>> name with the full path of the library.  Have you tried that?
>
> You are right.  I think what we need here is to patch all the cffi
> packages.
> For instance, sqlite3-lib contains the following lines:
>
> --8<---------------cut here---------------start------------->8---
> (define-foreign-library sqlite3-lib
>   (:darwin (:default "libsqlite3"))
>   (:unix (:or "libsqlite3.so.0" "libsqlite3.so"))
>   (t (:or (:default "libsqlite3") (:default "sqlite3"))))
> --8<---------------cut here---------------end--------------->8---
>
> Patching with the full path should work.  I'll see what I can do.

Thanks.

>> Another option is to wrap the executable in LD_LIBRARY_PATH, although
>> that should only be a last resort.
>>
>>> GuixSD has LIBRARY_PATH=~/.guix-profile/lib, can we use that?
>>
>> LIBRARY_PATH is only set when you have gcc-toolchain installed.  I don’t
>> have this variable.  It is also not applicable here: it is used by the
>> compiler at build time when linking applications.
>
> So to what would you wrap it?  The full path of the required libs?  E.g.
>
> LD_LIBRARY_PATH=/gnu/store/sdin91pj2w7m5avvb6vykh6haq8q2ni0-sqlite-3.21.0/lib/:...

Yes, just like that.  See the build phases of eolie in (gnu packages
gnome) as an example.

(Speaking of eolie: I should update it.)

-- 
Ricardo

Re: next browser (was: Packaging a free Firefox)

[ajpatter]

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

Re: Packaging a free Firefox

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]

Clément Lassieur <clement@lassieur.org> writes:

> 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

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Packaging a free Firefox

[Pjotr Prins]

On Wed, May 02, 2018 at 11:06:32PM -0700, Chris Marusich wrote:
> Clément Lassieur <clement@lassieur.org> writes:
> 
> > 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

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.

Re: Packaging a free Firefox

[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

Pjotr Prins writes:

> On Wed, May 02, 2018 at 11:06:32PM -0700, Chris Marusich wrote:
>> Clément Lassieur <clement@lassieur.org> writes:
>> 
>> > 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
>
> 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.

Re: Packaging a free Firefox

[Pjotr Prins]

On Thu, May 03, 2018 at 11:53:04AM +0200, Pjotr Prins wrote:
> On Wed, May 02, 2018 at 11:06:32PM -0700, Chris Marusich wrote:
> > Clément Lassieur <clement@lassieur.org> writes:
> > 
> > > 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.

Re: Packaging a free Firefox

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 3548 bytes --]

On Wed, May 02, 2018 at 23:06:32 -0700, Chris Marusich wrote:
> Clément Lassieur <clement@lassieur.org> writes:
>
>> 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).

> 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.

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

> 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

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 maintainers@gnu.org.)

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Packaging a free Firefox

[Pjotr Prins]

On Thu, May 03, 2018 at 01:59:24PM -0400, Mike Gerwitz wrote:
> 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.

Re: Packaging a free Firefox

[Nils Gillmann]

Pjotr Prins transcribed 650 bytes:
> On Thu, May 03, 2018 at 01:59:24PM -0400, Mike Gerwitz wrote:
> > 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.

Re: Packaging a free Firefox

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

On Fri, May 04, 2018 at 16:24:11 +0200, Pjotr Prins wrote:
> On Thu, May 03, 2018 at 01:59:24PM -0400, Mike Gerwitz wrote:
>> 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.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Packaging a free Firefox

[Pjotr Prins]

On Fri, May 04, 2018 at 12:27:07PM -0400, Mike Gerwitz wrote:
> 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.

Re: Packaging a free Firefox

[Pjotr Prins]

On Fri, May 04, 2018 at 04:24:11PM +0200, Pjotr Prins wrote:
> On Thu, May 03, 2018 at 01:59:24PM -0400, Mike Gerwitz wrote:
> > 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
runSafeSyncWithoutClone@resource://gre/modules/ExtensionUtils.jsm:25:110
tryInject@resource://gre/modules/ExtensionContent.jsm:197:9
execute@resource://gre/modules/ExtensionContent.jsm:273:5
trigger@resource://gre/modules/ExtensionContent.jsm:463:11
DocumentManager.observe@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.

Re: Packaging a free Firefox

[Ludovic Courtès]

Hi Pjotr,

Pjotr Prins <pjotr.public12@thebird.nl> skribis:

> 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
> runSafeSyncWithoutClone@resource://gre/modules/ExtensionUtils.jsm:25:110
> tryInject@resource://gre/modules/ExtensionContent.jsm:197:9
> execute@resource://gre/modules/ExtensionContent.jsm:273:5
> trigger@resource://gre/modules/ExtensionContent.jsm:463:11
> DocumentManager.observe@resource://gre/modules/ExtensionContent.jsm:342:7
> ]]
>
> 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?

> 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’.

Re: Packaging a free Firefox

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 2121 bytes --]

2018-05-15 10:57 GMT+02:00 Ludovic Courtès <ludo@gnu.org>:

> Hi Pjotr,
>
> Pjotr Prins <pjotr.public12@thebird.nl> skribis:
>
> > 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
> > runSafeSyncWithoutClone@resource://gre/modules/ExtensionUtils.jsm:25:110
> > tryInject@resource://gre/modules/ExtensionContent.jsm:197:9
> > execute@resource://gre/modules/ExtensionContent.jsm:273:5
> > trigger@resource://gre/modules/ExtensionContent.jsm:463:11
> > DocumentManager.observe@resource://gre/modules/
> ExtensionContent.jsm:342:7
> > ]]
> >
> > 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?
>
> > 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.

[-- Attachment #2: Type: text/html, Size: 2923 bytes --]

Re: Packaging a free Firefox

[Mark H Weaver]

Gábor Boskovits <boskovits@gmail.com> writes:
> 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

Re: Packaging a free Firefox

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

On Tue, May 15, 2018 at 10:57:39 +0200, Ludovic Courtès wrote:
> Hi Pjotr,
>
> Pjotr Prins <pjotr.public12@thebird.nl> skribis:
[...]
>> 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.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Packaging a free Firefox

[Ludovic Courtès]

Hello Mike,

Mike Gerwitz <mtg@gnu.org> skribis:

> 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.

Oh OK, thanks for explaining, I wasn’t aware of that.

Ludo’.

Re: Packaging a free Firefox

[Mark H Weaver]

Chris Marusich <cmmarusich@gmail.com> writes:

> 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

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

Re: Packaging a free Firefox

[Clément Lassieur]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> writes:

> Clément Lassieur <clement@lassieur.org> writes:
>
>> 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

Re: Packaging a free Firefox

[Clément Lassieur]

Clément Lassieur <clement@lassieur.org> writes:

> 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.

Re: Packaging a free Firefox

[Adonay Felipe Nogueira]

2018-05-02T23:06:37+0200 Clément Lassieur wrote:
> Hi,

Hi Clément,

> 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.

>   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/

Re: Packaging a free Firefox

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]

On Sat, May 05, 2018 at 19:06:27 -0300, Adonay Felipe Nogueira wrote:
> 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.

> 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
maintainers@gnu.org.

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Packaging a free Firefox

[Nils Gillmann]

Mike Gerwitz transcribed 2.2K bytes:
> On Sat, May 05, 2018 at 19:06:27 -0300, Adonay Felipe Nogueira wrote:
> > 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.

> 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.

> > 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
> maintainers@gnu.org.
> 
> > 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

Re: Packaging a free Firefox

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]

On Sun, May 06, 2018 at 06:01:59 +0000, Nils Gillmann wrote:
> Mike Gerwitz transcribed 2.2K bytes:
>> On Sat, May 05, 2018 at 19:06:27 -0300, Adonay Felipe Nogueira wrote:
>> > 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.

> 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.

>> 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.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Packaging a free Firefox

[Hartmut Goebel]

Am 06.05.2018 um 15:58 schrieb 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.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Packaging a free Firefox

[Hartmut Goebel]

Am 06.05.2018 um 03:24 schrieb Mike Gerwitz:
> On Sat, May 05, 2018 at 19:06:27 -0300, Adonay Felipe Nogueira wrote:
>> 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,

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Packaging a free Firefox

[Pjotr Prins]

On Sun, May 06, 2018 at 11:48:28AM +0200, Hartmut Goebel wrote:
> Am 06.05.2018 um 03:24 schrieb Mike Gerwitz:
> > On Sat, May 05, 2018 at 19:06:27 -0300, Adonay Felipe Nogueira wrote:
> >> 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.

Re: Packaging a free Firefox

[Katherine Cox-Buday]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

>> 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).

> 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.

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

Re: Packaging a free Firefox

[Tonton]

[-- Attachment #1: Type: text/plain, Size: 2506 bytes --]

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
Katherine Cox-Buday <cox.katherine.e@gmail.com> wrote:

> Pjotr Prins <pjotr.public12@thebird.nl> writes:
> 
> >> 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).
> 
> > 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.  
> 
> 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.
> 



-- 
I use gpg to sign my emails. All the symbols you may see at the bottom
of this mail is my cryptographic signature. It can be ignored, or used
to check that it really is me sending this email. Learn more by asking
me or see: https://u.fsf.org/zb or https://ssd.eff.org/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Packaging a free Firefox

[Katherine Cox-Buday]

Tonton <tonton@riseup.net> writes:

> 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.

-- 
Katherine

Re: Packaging a free Firefox

[Ludovic Courtès]

Hello Katherine,

Katherine Cox-Buday <cox.katherine.e@gmail.com> skribis:

> 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.

There will never be an “official” non-libre channel in that Guix as a
project will not provide such a channel.

Now, Firefox *is* free software, so there’s could be an official
“firefox” package, but in essence, it would have to incorporate pretty
much the same changes that IceCat provides.

I wonder why IceCat is based on an ESR, and what it would take to have
it follow Firefox releases more closely.  IWBN if IceCat could be pretty
much like Linux-libre, i.e., a set of scripts that semi-automatically
adjusts the Firefox source (I’m not sure if that is the case currently.)

At any rate, people interested in this should probably team up with the
IceCat people (person?) to see how we can together move in the right
direction.

Ludo’.

Re: Packaging a free Firefox

[Nils Gillmann]

Ludovic Courtès transcribed 1.1K bytes:
> Hello Katherine,
> 
> Katherine Cox-Buday <cox.katherine.e@gmail.com> skribis:
> 
> > 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.
> 
> There will never be an “official” non-libre channel in that Guix as a
> project will not provide such a channel.
> 
> Now, Firefox *is* free software, so there’s could be an official
> “firefox” package, but in essence, it would have to incorporate pretty
> much the same changes that IceCat provides.
> 
> I wonder why IceCat is based on an ESR, and what it would take to have
> it follow Firefox releases more closely.

I am not involved or speaking for Icecat, but ESR is moving slower than
Firefox "master" channel. This alone is good enough to base on it for
long-term support when you are a downstream vendor such as Torbrowser,
Icecat, or a simple company running a site-specific Firefox.

From Firefox; I remember reading Icecat ran into the same problems building
beyond 54.x than I have, but I might be wrong. In any case ESR as long as it
does provide the Off switch for rust should be kept around. After 54.x it's
up to those who solve the problems our build system (and presuable other systems
too) gets with the crates.

> IWBN if IceCat could be pretty

IWBN? What does that mean?

> much like Linux-libre, i.e., a set of scripts that semi-automatically
> adjusts the Firefox source (I’m not sure if that is the case currently.)
> 
> At any rate, people interested in this should probably team up with the
> IceCat people (person?) to see how we can together move in the right
> direction.
> 
> Ludo’.
> 

Re: Packaging a free Firefox

[Christopher Lemmer Webber]

Nils Gillmann writes:

> Ludovic Courtès transcribed 1.1K bytes:
>> Hello Katherine,
>> 
>> Katherine Cox-Buday <cox.katherine.e@gmail.com> skribis:
>> 
>> > 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.
>> 
>> There will never be an “official” non-libre channel in that Guix as a
>> project will not provide such a channel.
>> 
>> Now, Firefox *is* free software, so there’s could be an official
>> “firefox” package, but in essence, it would have to incorporate pretty
>> much the same changes that IceCat provides.
>> 
>> I wonder why IceCat is based on an ESR, and what it would take to have
>> it follow Firefox releases more closely.
>
> I am not involved or speaking for Icecat, but ESR is moving slower than
> Firefox "master" channel. This alone is good enough to base on it for
> long-term support when you are a downstream vendor such as Torbrowser,
> Icecat, or a simple company running a site-specific Firefox.

It would be really nice to be able to have tor browser bundle in GuixSD.

Re: Packaging a free Firefox

[Nils Gillmann]

Christopher Lemmer Webber transcribed 1.2K bytes:
> Nils Gillmann writes:
> 
> > Ludovic Courtès transcribed 1.1K bytes:
> >> Hello Katherine,
> >> 
> >> Katherine Cox-Buday <cox.katherine.e@gmail.com> skribis:
> >> 
> >> > 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.
> >> 
> >> There will never be an “official” non-libre channel in that Guix as a
> >> project will not provide such a channel.
> >> 
> >> Now, Firefox *is* free software, so there’s could be an official
> >> “firefox” package, but in essence, it would have to incorporate pretty
> >> much the same changes that IceCat provides.
> >> 
> >> I wonder why IceCat is based on an ESR, and what it would take to have
> >> it follow Firefox releases more closely.
> >
> > I am not involved or speaking for Icecat, but ESR is moving slower than
> > Firefox "master" channel. This alone is good enough to base on it for
> > long-term support when you are a downstream vendor such as Torbrowser,
> > Icecat, or a simple company running a site-specific Firefox.
> 
> It would be really nice to be able to have tor browser bundle in GuixSD.

TL;DR is we can have it and I will pick up work on it again pretty soon.
(We had the idea for a custom browser based on Torbrowser, so I have a
requirement beyond simply using it.)

Under the conditions (for packaging torbrowser) I talked about with Torbrowser-project
it is okay to ship it fully branded. I will have to get back to them as soon
as I am past the current bug and got it building.

Re: Packaging a free Firefox

[Christopher Lemmer Webber]

Nils Gillmann writes:

> Christopher Lemmer Webber transcribed 1.2K bytes:
>> Nils Gillmann writes:
>> 
>> > Ludovic Courtès transcribed 1.1K bytes:
>> >> Hello Katherine,
>> >> 
>> >> Katherine Cox-Buday <cox.katherine.e@gmail.com> skribis:
>> >> 
>> >> > 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.
>> >> 
>> >> There will never be an “official” non-libre channel in that Guix as a
>> >> project will not provide such a channel.
>> >> 
>> >> Now, Firefox *is* free software, so there’s could be an official
>> >> “firefox” package, but in essence, it would have to incorporate pretty
>> >> much the same changes that IceCat provides.
>> >> 
>> >> I wonder why IceCat is based on an ESR, and what it would take to have
>> >> it follow Firefox releases more closely.
>> >
>> > I am not involved or speaking for Icecat, but ESR is moving slower than
>> > Firefox "master" channel. This alone is good enough to base on it for
>> > long-term support when you are a downstream vendor such as Torbrowser,
>> > Icecat, or a simple company running a site-specific Firefox.
>> 
>> It would be really nice to be able to have tor browser bundle in GuixSD.
>
> TL;DR is we can have it and I will pick up work on it again pretty soon.
> (We had the idea for a custom browser based on Torbrowser, so I have a
> requirement beyond simply using it.)
>
> Under the conditions (for packaging torbrowser) I talked about with Torbrowser-project
> it is okay to ship it fully branded. I will have to get back to them as soon
> as I am past the current bug and got it building.

Hey, that's great news!  Thank you :)

Re: Packaging a free Firefox

[Pjotr Prins]

On Thu, May 17, 2018 at 12:57:22PM -0500, Christopher Lemmer Webber wrote:
> > Under the conditions (for packaging torbrowser) I talked about with Torbrowser-project
> > it is okay to ship it fully branded. I will have to get back to them as soon
> > as I am past the current bug and got it building.
> 
> Hey, that's great news!  Thank you :)

That is really cool! Where libre shines :)

When Icecat stops crashing it will be totally useful for most people
(95%).

For web developers or people who want/need a cutting edge Firefox
browser, including it would be useful too. I really think GNU Guix
should support that use case, if we can under our GNU constraints.

Pj.

Re: Packaging a free Firefox

[Pjotr Prins]

On Fri, May 18, 2018 at 06:14:24AM +0200, Pjotr Prins wrote:
> When Icecat stops crashing it will be totally useful for most people
> (95%).

Now I am on fast internet I have far less crashes. Looks like it is a
JS timeout of sorts. I am on 45.5.1, so next step is an upgrade.

Pj.

Re: Packaging a free Firefox

[Mark H Weaver]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> On Fri, May 18, 2018 at 06:14:24AM +0200, Pjotr Prins wrote:
>> When Icecat stops crashing it will be totally useful for most people
>> (95%).
>
> Now I am on fast internet I have far less crashes. Looks like it is a
> JS timeout of sorts. I am on 45.5.1, so next step is an upgrade.

45.5.1?  That's ancient, with a large number of known security flaws.
Why are you running such an old version?

      Mark

Re: Packaging a free Firefox

[Pjotr Prins]

On Mon, May 21, 2018 at 04:07:10PM -0400, Mark H Weaver wrote:
> 45.5.1?  That's ancient, with a large number of known security flaws.
> Why are you running such an old version?

Ancient? November 2016 released. Ancient is my thinpad and ancient is
me ;). Security matters, but my system is not *that* vulnerable. Note
that I run the browser in a degraded mode (noscript, noflash etc.).
That actually matters most.

I'll upgrade when I have the bandwidth and time.

Pj.

Re: Packaging a free Firefox

[Mark H Weaver]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> On Mon, May 21, 2018 at 04:07:10PM -0400, Mark H Weaver wrote:
>> 45.5.1?  That's ancient, with a large number of known security flaws.
>> Why are you running such an old version?
>
> Ancient? November 2016 released. Ancient is my thinpad and ancient is
> me ;). Security matters, but my system is not *that* vulnerable. Note
> that I run the browser in a degraded mode (noscript, noflash etc.).
> That actually matters most.

November 2016 is ancient for a web browser, which has an extraordinarily
large attack surface.  While it's true that disabling javascript helps,
there are known vulnerabilities in several other parts of the code.

Your system is vulnerable to attack.  If you think otherwise, you are
mistaken.

      Mark

Re: Packaging a free Firefox

[Pjotr Prins]

On Mon, May 21, 2018 at 04:07:10PM -0400, Mark H Weaver wrote:
> Pjotr Prins <pjotr.public12@thebird.nl> writes:
> 
> > On Fri, May 18, 2018 at 06:14:24AM +0200, Pjotr Prins wrote:
> >> When Icecat stops crashing it will be totally useful for most people
> >> (95%).
> >
> > Now I am on fast internet I have far less crashes. Looks like it is a
> > JS timeout of sorts. I am on 45.5.1, so next step is an upgrade.
> 
> 45.5.1?  That's ancient, with a large number of known security flaws.
> Why are you running such an old version?

Just to say that I upgraded to 52.6.0 and it is really stable. Thanks
for all that!

Pj.

Re: Packaging a free Firefox

[Mark H Weaver]

Hi Pjotr,

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> On Mon, May 21, 2018 at 04:07:10PM -0400, Mark H Weaver wrote:
>> Pjotr Prins <pjotr.public12@thebird.nl> writes:
>> 
>> > On Fri, May 18, 2018 at 06:14:24AM +0200, Pjotr Prins wrote:
>> >> When Icecat stops crashing it will be totally useful for most people
>> >> (95%).
>> >
>> > Now I am on fast internet I have far less crashes. Looks like it is a
>> > JS timeout of sorts. I am on 45.5.1, so next step is an upgrade.
>> 
>> 45.5.1?  That's ancient, with a large number of known security flaws.
>> Why are you running such an old version?
>
> Just to say that I upgraded to 52.6.0 and it is really stable. Thanks
> for all that!

I'm glad to hear it!  Thanks for letting me know.

      Mark

Re: Packaging a free Firefox

[Mark H Weaver]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> On Thu, May 17, 2018 at 12:57:22PM -0500, Christopher Lemmer Webber wrote:
>> > Under the conditions (for packaging torbrowser) I talked about with Torbrowser-project
>> > it is okay to ship it fully branded. I will have to get back to them as soon
>> > as I am past the current bug and got it building.
>> 
>> Hey, that's great news!  Thank you :)
>
> That is really cool! Where libre shines :)
>
> When Icecat stops crashing it will be totally useful for most people
> (95%).
>
> For web developers or people who want/need a cutting edge Firefox
> browser, including it would be useful too.

Did you know that Torbrowser is based on the same Firefox ESR 52 that
IceCat is based on?

      Mark

Re: Packaging a free Firefox

[Alex Vong]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

Hello,

Mark H Weaver <mhw@netris.org> writes:

> Pjotr Prins <pjotr.public12@thebird.nl> writes:
>
>> On Thu, May 17, 2018 at 12:57:22PM -0500, Christopher Lemmer Webber wrote:
>>> > Under the conditions (for packaging torbrowser) I talked about
>>> > with Torbrowser-project
>>> > it is okay to ship it fully branded. I will have to get back to
>>> > them as soon
>>> > as I am past the current bug and got it building.
>>> 
>>> Hey, that's great news!  Thank you :)
>>
>> That is really cool! Where libre shines :)
>>
>> When Icecat stops crashing it will be totally useful for most people
>> (95%).
>>
>> For web developers or people who want/need a cutting edge Firefox
>> browser, including it would be useful too.
>
> Did you know that Torbrowser is based on the same Firefox ESR 52 that
> IceCat is based on?
>
Tor browser user here! It is currently based on 52.8.0

>       Mark

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Packaging a free Firefox

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

On Thu, May 17, 2018 at 13:34:37 +0200, Ludovic Courtès wrote:
> I wonder why IceCat is based on an ESR, and what it would take to have
> it follow Firefox releases more closely.  IWBN if IceCat could be pretty
> much like Linux-libre, i.e., a set of scripts that semi-automatically
> adjusts the Firefox source (I’m not sure if that is the case currently.)

Its maintainer was struggling to keep up with any releases at all, which
is why Mark Weaver stepped up backporting security patches for
Guix.  I'm not sure how much effort is involved with running the script
and issuing a new release.

> At any rate, people interested in this should probably team up with the
> IceCat people (person?) to see how we can together move in the right
> direction.

Please do contact maintainers@gnu.org if anyone is interested!

Rubén Rodríguez is IceCat's maintainer and is an employee at the FSF.  I
proposed to both rms and John Sullivan at different points that maybe
IceCat maintenance can be made part of Rubén's responsibilities at the
FSF.  The FSF recently announced a paid contact position for LibreJS, so
maybe at some point IceCat can see some attention too.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Packaging a free Firefox

[Pjotr Prins]

On Wed, May 16, 2018 at 06:10:28PM +0200, Tonton wrote:
> 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.

The GUIX_PACKAGE_PATH works on an individual basis. When it comes to
sharing it is totally inconvenient. I know because we are using it in
production.

The main problems are (1) people need to check out a source tree to
use it - with troublesome instructions and slow install routes
(typically a few hours) and (2) the git versions of the GNU Guix repo
has to be in sync with the GUIX_PACKAGE_PATH repo.

With my collaborators we often face problems - even yesterday we had a
package conflict.

One reason we channels are slow in coming is because they need to
resolve multiple problems. But in a nutshell they are about sharing
software that is not in Guix mainline, divert responsibility to
channel maintainers, while providing fast trusted binary installs. 

One thing that needs to be resolved is how much we share with the Guix
trunk (i.e., the running Guix with pull). My current thought is that
we should share *nothing*. This is the only way to have reproducible
installs from channels. Of course the risk is that the daemon goes out
of sync. But I think we can handle that if the guix client makes sure
incompatibilities are notified. The channel should be updated to
support updated daemons.

You can see that thinking this through is non-trivial and Guix
maintainers probably realize there are more problems ;)

At this point everyone is hacking it their own way. Witness people
writing their own packages for firefox. Would be nice to have a
consistent path where we can be more efficient.

Pj.

Re: Packaging a free Firefox

[Christopher Lemmer Webber]

Katherine Cox-Buday writes:

> Pjotr Prins <pjotr.public12@thebird.nl> writes:
>
>>> 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

Re: Packaging a free Firefox

[Oleg Pykhalov]

[-- Attachment #1: Type: text/plain, Size: 1007 bytes --]

Hello Katherine,

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

> Pjotr Prins <pjotr.public12@thebird.nl> writes:

[…]

> 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 understand this, but still you could use almost all Guix stuff except
Shepherd system services [1] on a foreign distribution.  Guix works
smoothly for me on a working computer with GNU/Linux Mint on a board,
and I use GuixSD on my personal computer and laptop.  Also GuixSD has
the latest Chromium, but unfortunately without substitutes yet [2].

[…]

[1]  https://www.gnu.org/software/shepherd/
[2]  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28004

Oleg.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Packaging a free Firefox

[Katherine Cox-Buday]

Oleg Pykhalov <go.wigust@gmail.com> writes:

> I understand this, but still you could use almost all Guix stuff
> except Shepherd system services [1] on a foreign distribution. Guix
> works smoothly for me on a working computer with GNU/Linux Mint on a
> board, and I use GuixSD on my personal computer and laptop. Also
> GuixSD has the latest Chromium, but unfortunately without substitutes
> yet [2].

Thanks Oleg. I am indeed running Guix the package manager on a few
different distros. It's a good way for me to stay in touch with the
project until I can run GuixSD again.

-- 
Katherine

Re: Packaging a free Firefox

[Mark H Weaver]

Hi Katherine,

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

> Pjotr Prins <pjotr.public12@thebird.nl> writes:
>
>>> 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).

Can you tell me specifically what is wrong with GNU IceCat that makes it
unsuitable for you?  It has been my primary browser for several years.

     Thanks,
       Mark

Re: Packaging a free Firefox

[Thorsten Wilms]

On 17.05.2018 03:26, Mark H Weaver wrote:
> Can you tell me specifically what is wrong with GNU IceCat that makes it
> unsuitable for you?  It has been my primary browser for several years.

While that question wasn't addressed to me, my case was similar to what 
Katherine described, so here's my take on it:

Coming from latest Firefox, IceCat on GuixSD felt ridiculously slow. 
Hidden-HTML warnings and the LibreJS thing were unbearably annoying. I 
understand the reasoning behind LibreJS, but to me, personally, it is 
akin to fighting in a lost war instead of getting to the information I 
want here and now.

After disabling everything IceCat comes with, I found the replacement 
Add-on pages to be misdesigned for the context they appear in. I did not 
succeed in installing uMatrix, one of the few add-ons I care about.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

Re: Packaging a free Firefox

[Katherine Cox-Buday]

Mark H Weaver <mhw@netris.org> writes:

> Can you tell me specifically what is wrong with GNU IceCat that makes it
> unsuitable for you?  It has been my primary browser for several years.

I don't think aiming to change a user's motivations is a winning game,
but I can enumerate why I personally wanted to use Firefox. Maybe it
will help make Icecat better.

- Icecat doesn't have any of the new, more performant, pieces Mozilla
  have been integrating into Firefox (quantum, sevro).

- Icecat doesn't have the account synchronization meaning I didn't have
  access to bookmarks, history, synced tabs, etc.

- Icecat very _strangely_ came preinstalled with extensions I didn't
  want (I think I remember an extension for a fast food chain?)

- Icecat cut me off from the normal Firefox extension store. I can't
  remember if I was able to loan extensions I view as crucial for safely
  browsing the web.

- The number of maintainers and the way in which it was (is?) being
  maintained did not inspire confidence. The people maintaining this are
  heros, but I'd rather rely on the boring engineering practices of
  upstream Firefox than heroic efforts.

-- 
Katherine

Re: Packaging a free Firefox

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]

On Sun, May 06, 2018 at 11:48:28 +0200, Hartmut Goebel wrote:
> Am 06.05.2018 um 03:24 schrieb Mike Gerwitz:
>> On Sat, May 05, 2018 at 19:06:27 -0300, Adonay Felipe Nogueira wrote:
>>> 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

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Packaging a free Firefox

[Pjotr Prins]

On Sun, May 06, 2018 at 10:05:35AM -0400, Mike Gerwitz wrote:
> 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.

Re: Packaging a free Firefox

[Hartmut Goebel]

[-- Attachment #1.1: Type: text/plain, Size: 1002 bytes --]

Am 06.05.2018 um 16:05 schrieb 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.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Packaging a free Firefox

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

On Sun, May 06, 2018 at 18:33:56 +0200, Hartmut Goebel wrote:
> Am 06.05.2018 um 16:05 schrieb 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.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Packaging a free Firefox

[jah]

On 07/05/18 01:36, Mike Gerwitz wrote:
> On Sun, May 06, 2018 at 18:33:56 +0200, Hartmut Goebel wrote:
> 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.

Re: Packaging a free Firefox

[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’.

Re: Packaging a free Firefox

[Pjotr Prins]

On Mon, May 07, 2018 at 06:30:44PM +0200, Ludovic Courtès wrote:
> 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?

I don't think the words were meant to be harsh. We are all in this
together, right? Sorry if it came over that way.

> 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.

I don't think that mission is questioned. No one expects Skype to be
part of Guix ;)

Pj.

Re: Packaging a free Firefox

[Mark H Weaver]

Hartmut Goebel <h.goebel@crazy-compilers.com> writes:

> Am 06.05.2018 um 16:05 schrieb 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").

To be clear, our IceCat package allows you to install any compatible
addon, regardless of its license.  You are free to navigate to
addons.mozilla.org and install whatever you wish.  It's quite easy.

However, IceCat is modified to not direct users to that site by default.
That's part of our commitment as a project to not steer users toward
nonfree software.

I think it's rather absurd to suggest that we are somehow violating your
freedom by making a commitment as a project to exclude software that
doesn't meet our standards.

You can do what you want with your own computer.  Guix makes it
unusually easy to add your own packages, or modify our existing
packages, while still receiving updates from us.

Can you explain more clearly how we are infringing on your freedom?

       Mark

Re: Packaging a free Firefox

[Mark H Weaver]

Hartmut Goebel <h.goebel@crazy-compilers.com> writes:
> 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.

This is not a good analogy to this situation, because we're not asking
you to give up nonfree software.  Instead, you are demanding that we
include nonfree software in Guix.

If you want to make an analogy to veganism here, here's a better one:

What you're doing is analogous to walking into a vegan restaurant and
demanding that they add meat to their menu, based on the argument that
by excluding meat from their menu, they are infringing on your right to
eat what you want.

      Mark