* patches question
@ 2016-06-23 10:41 ng0
2016-06-23 11:09 ` Andreas Enge
2016-06-23 13:23 ` ng0
0 siblings, 2 replies; 22+ messages in thread
From: ng0 @ 2016-06-23 10:41 UTC (permalink / raw)
To: guix-devel
After the last reply to my netcat-openbsd, I am
uncertain about the kind of patches which can
be included by policy.
For firefox, I would start to include what fixes
buildprocess for us and fixes bugs (including
features) upstream has not bothered to close yet
or in general.
That is what the netcat-openbsd-* files of debian
are about I assume (but I have not asked debian
yet).
For firefox, bundled libraries and applications
can be patched away (system graphite+harfbuzz),
more I can not figure out in this state of package.
Gentoo has 37 patches for the 45.x of firefox,
some which are useless to us, some which can be
useful completely or just in parts.
Some are even solved through the way we can
build software.
Sometimes I don't want to wait up on upstream.
Maybe some fixes by (example name) Gentoo have
not been pushed back to mozilla, but if it
fixes builds and features I see no reason why
not to use it.
In the case of firefox I'm willing to communicate
with mozilla, as with all software, but I'd do this
after inclusion of patches so we can drop patches
once there has been a merge or a bug has been resolved.
--
♥Ⓐ ng0
For non-prism friendly talk find me on
psyced.org / loupsycedyglgamf.onion
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: patches question
2016-06-23 10:41 patches question ng0
@ 2016-06-23 11:09 ` Andreas Enge
2016-06-23 11:30 ` ng0
2016-06-23 13:23 ` ng0
1 sibling, 1 reply; 22+ messages in thread
From: Andreas Enge @ 2016-06-23 11:09 UTC (permalink / raw)
To: guix-devel
Hello,
On Thu, Jun 23, 2016 at 10:41:08AM +0000, ng0 wrote:
> After the last reply to my netcat-openbsd, I am
> uncertain about the kind of patches which can
> be included by policy.
my opinion is: as few patches as possible, given that we need to maintain
them with very little peoplepower, and that we do not intend to substitute
ourselves to upstream. Also, if possible, things should be reported upstream
so that we can take patches out again. Another reason to do so is that
packages should essentially behave in the same way as the same software
compiled by hand. Recall also cases of security problems introduced into
other distributions by non-upstream adding patches to cryto software they
did not completely understand.
> For firefox, I would start to include what fixes
> buildprocess for us and fixes bugs (including
> features) upstream has not bothered to close yet
> or in general.
Particularities of our build process may clearly make patches necessary
(although I often prefer to treat them more generically in a build phase,
using "substitute*", for instance, which may be more robust across package
updates). After that, I would consider mainly security fixes and maybe
important functional fixes made by upstream that are not yet in a release.
Clearly features that upstream does not bother to implement are not acceptable
for patches, as they will have to be maintained and adapted indefinitely.
> For firefox, bundled libraries and applications
> can be patched away (system graphite+harfbuzz),
Unbundling and removal of non-free parts are also possible cases, although
most of the time this is done by a call to "delete-file-recursively" in a
snippet.
> That is what the netcat-openbsd-* files of debian
> are about I assume (but I have not asked debian
> yet).
I do not know about this particular software, but while Debian is a good
source for copyright info and patch material, they definitely are not our
lead as to the decision of whether to include patches: If you divide our
number of packages by the number of regular contributors, you will end up
with a few hundred packages per person. I think Debian has no particular
policy as to which patches are acceptable, and that this is mainly up to
the package maintainer. In our case, since we do not have designated
maintainers, every additional patch is an additional burden on the person
trying to update or more generally work on a package later. As a bad example
of a Debian patch, I have encountered one that corrected an English typo
in a comment (!) in the C code of a package.
Andreas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: patches question
2016-06-23 11:09 ` Andreas Enge
@ 2016-06-23 11:30 ` ng0
2016-06-23 20:14 ` Andreas Enge
0 siblings, 1 reply; 22+ messages in thread
From: ng0 @ 2016-06-23 11:30 UTC (permalink / raw)
To: guix-devel
On 2016-06-23(01:09:43PM+0200), Andreas Enge wrote:
> Hello,
>
> On Thu, Jun 23, 2016 at 10:41:08AM +0000, ng0 wrote:
> > After the last reply to my netcat-openbsd, I am
> > uncertain about the kind of patches which can
> > be included by policy.
>
> my opinion is: as few patches as possible, given that we need to maintain
> them with very little peoplepower, and that we do not intend to substitute
> ourselves to upstream. Also, if possible, things should be reported upstream
> so that we can take patches out again. Another reason to do so is that
> packages should essentially behave in the same way as the same software
> compiled by hand. Recall also cases of security problems introduced into
> other distributions by non-upstream adding patches to cryto software they
> did not completely understand.
>
> > For firefox, I would start to include what fixes
> > buildprocess for us and fixes bugs (including
> > features) upstream has not bothered to close yet
> > or in general.
>
> Particularities of our build process may clearly make patches necessary
> (although I often prefer to treat them more generically in a build phase,
> using "substitute*", for instance, which may be more robust across package
> updates). After that, I would consider mainly security fixes and maybe
> important functional fixes made by upstream that are not yet in a release.
> Clearly features that upstream does not bother to implement are not acceptable
> for patches, as they will have to be maintained and adapted indefinitely.
Okay, sounds logical and reasonable.
I wanted to ask Debian about the netcat-openbsd case
and why certain features are added/fixed.
> > For firefox, bundled libraries and applications
> > can be patched away (system graphite+harfbuzz),
>
> Unbundling and removal of non-free parts are also possible cases, although
> most of the time this is done by a call to "delete-file-recursively" in a
> snippet.
The length of the package definition in this case could
be smaller. With comments it's at 300 lines now.
Some temporary patches to open bugs would increase this
length.
That's my only motivation for the patches directory,
length of code. If it does not matter, I will do it
in the packages themselves as long as possible even
for non-trivial fixes.
> > That is what the netcat-openbsd-* files of debian
> > are about I assume (but I have not asked debian
> > yet).
>
> I do not know about this particular software, but while Debian is a good
> source for copyright info and patch material, they definitely are not our
> lead as to the decision of whether to include patches: If you divide our
> number of packages by the number of regular contributors, you will end up
> with a few hundred packages per person. I think Debian has no particular
> policy as to which patches are acceptable, and that this is mainly up to
> the package maintainer. In our case, since we do not have designated
> maintainers, every additional patch is an additional burden on the person
> trying to update or more generally work on a package later. As a bad example
> of a Debian patch, I have encountered one that corrected an English typo
> in a comment (!) in the C code of a package.
>
> Andreas
>
>
In the case of netcat-openbsd, Debian is the Linux upstream,
maintaining the port of netcat from OpenBSD.
The patches have not seen an update since 2012 and are still
functional.
I can understand that we don't want to maintain more patches
than necessary, so in the case of netcat-openbsd I'll contact
Debian, as mentioned in the thread of the patch, to ask about
a merge of their patches into their maintained port.
If the reply is negative, I'll look at the patches and only
take what's really necessary.
--
♥Ⓐ ng0
For non-prism friendly talk find me on
psyced.org / loupsycedyglgamf.onion
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: patches question
2016-06-23 10:41 patches question ng0
2016-06-23 11:09 ` Andreas Enge
@ 2016-06-23 13:23 ` ng0
2016-06-23 20:27 ` Andreas Enge
2016-06-24 12:09 ` Ludovic Courtès
1 sibling, 2 replies; 22+ messages in thread
From: ng0 @ 2016-06-23 13:23 UTC (permalink / raw)
To: guix-devel
Firefox wip, untested, not even run, just filling in fixes
which very likely have broken syntax looks like the later
inserted file. In this file there is a 140+ lines phase
which aims at doing what the following inserted patch
does. It is still growing (2 files left to patch).
As 'maybe' icecat can make use of the harfbuzz graphite
phase in this case it makes more sense to drop it
into gnu/packages/patches/ .. right?
diff --git a/config/Makefile.in b/config/Makefile.in
--- a/config/Makefile.in
+++ b/config/Makefile.in
@@ -44,16 +44,18 @@ export:: $(export-preqs)
-DMOZ_NATIVE_HUNSPELL=$(MOZ_NATIVE_HUNSPELL) \
-DMOZ_NATIVE_BZ2=$(MOZ_NATIVE_BZ2) \
-DMOZ_NATIVE_ZLIB=$(MOZ_NATIVE_ZLIB) \
-DMOZ_NATIVE_PNG=$(MOZ_NATIVE_PNG) \
-DMOZ_NATIVE_JPEG=$(MOZ_NATIVE_JPEG) \
-DMOZ_NATIVE_LIBEVENT=$(MOZ_NATIVE_LIBEVENT) \
-DMOZ_NATIVE_LIBVPX=$(MOZ_NATIVE_LIBVPX) \
-DMOZ_NATIVE_ICU=$(MOZ_NATIVE_ICU) \
+ -DMOZ_NATIVE_GRAPHITE2=$(MOZ_NATIVE_GRAPHITE2) \
+ -DMOZ_NATIVE_HARFBUZZ=$(MOZ_NATIVE_HARFBUZZ) \
$(srcdir)/system-headers | $(PERL) $(topsrcdir)/nsprpub/config/make-system-wrappers.pl system_wrappers
$(INSTALL) system_wrappers $(DIST)
GARBAGE_DIRS += system_wrappers
endif
ifdef WRAP_STL_INCLUDES
ifdef GNU_CXX
diff --git a/config/system-headers b/config/system-headers
--- a/config/system-headers
+++ b/config/system-headers
@@ -1340,8 +1340,16 @@ unicode/udatpg.h
unicode/uenum.h
unicode/unorm.h
unicode/unum.h
unicode/ustring.h
unicode/utypes.h
#endif
libutil.h
unwind.h
+#if MOZ_NATIVE_GRAPHITE2==1
+graphite2/Font.h
+graphite2/Segment.h
+#endif
+#if MOZ_NATIVE_HARFBUZZ==1
+harfbuzz/hb-ot.h
+harfbuzz/hb.h
+#endif
diff --git a/dom/base/moz.build b/dom/base/moz.build
--- a/dom/base/moz.build
+++ b/dom/base/moz.build
@@ -477,16 +477,19 @@ for var in ('MOZ_B2G_RIL', 'MOZ_B2G_FM')
DEFINES[var] = True
if CONFIG['MOZ_BUILD_APP'] in ['browser', 'mobile/android', 'xulrunner']:
DEFINES['HAVE_SIDEBAR'] = True
if CONFIG['MOZ_X11']:
CXXFLAGS += CONFIG['TK_CFLAGS']
+if CONFIG['MOZ_NATIVE_HARFBUZZ']:
+ CXXFLAGS += CONFIG['MOZ_HARFBUZZ_CFLAGS']
+
GENERATED_FILES += [
'PropertyUseCounterMap.inc',
'UseCounterList.h',
]
countermap = GENERATED_FILES['PropertyUseCounterMap.inc']
countermap.script = 'gen-usecounters.py:property_map'
countermap.inputs = ['UseCounters.conf']
diff --git a/gfx/graphite2/moz-gr-update.sh b/gfx/graphite2/moz-gr-update.sh
--- a/gfx/graphite2/moz-gr-update.sh
+++ b/gfx/graphite2/moz-gr-update.sh
@@ -1,11 +1,12 @@
#!/bin/bash
# Script used to update the Graphite2 library in the mozilla source tree
+# and bump version for --with-system-graphite2
# This script lives in gfx/graphite2, along with the library source,
# but must be run from the top level of the mozilla-central tree.
# Run as
#
# ./gfx/graphite2/moz-gr-update.sh RELEASE
#
@@ -32,22 +33,26 @@ echo "This directory contains the Graphi
echo "$TARBALL" >> gfx/graphite2/README.mozilla
echo ""
echo "See" $0 "for update procedure." >> gfx/graphite2/README.mozilla
# fix up includes because of bug 721839 (cstdio) and bug 803066 (Windows.h)
#find gfx/graphite2/ -name "*.cpp" -exec perl -p -i -e "s/<cstdio>/<stdio.h>/;s/Windows.h/windows.h/;" {} \;
#find gfx/graphite2/ -name "*.h" -exec perl -p -i -e "s/<cstdio>/<stdio.h>/;s/Windows.h/windows.h/;" {} \;
+# chase version for --with-system-graphite2
+perl -p -i -e "s/[0-9]+\,[0-9]+\,[0-9]+/$RELEASE/ and tr/./,/ \
+ if /GR2_VERSION_REQUIRE/" configure.in
+
# summarize what's been touched
echo Updated to $RELEASE.
echo Here is what changed in the gfx/graphite2 directory:
echo
-hg stat gfx/graphite2
+hg stat configure.in gfx/graphite2
echo
echo If gfx/graphite2/src/files.mk has changed, please make corresponding
echo changes to gfx/graphite2/src/moz.build
echo
echo
echo Now use hg commands to create a patch for the mozilla tree.
diff --git a/gfx/moz.build b/gfx/moz.build
--- a/gfx/moz.build
+++ b/gfx/moz.build
@@ -2,26 +2,30 @@
# vim: set filetype=python:
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
if CONFIG['MOZ_TREE_CAIRO']:
DIRS += ['cairo']
+if not CONFIG['MOZ_NATIVE_GRAPHITE2']:
+ DIRS += ['graphite2/src' ]
+
+if not CONFIG['MOZ_NATIVE_HARFBUZZ']:
+ DIRS += ['harfbuzz/src']
+
DIRS += [
'2d',
'ycbcr',
'angle',
'src',
'qcms',
'gl',
'layers',
- 'graphite2/src',
- 'harfbuzz/src',
'ots/src',
'thebes',
'ipc',
'vr',
]
if CONFIG['MOZ_ENABLE_SKIA']:
DIRS += ['skia']
diff --git a/intl/unicharutil/util/moz.build b/intl/unicharutil/util/moz.build
--- a/intl/unicharutil/util/moz.build
+++ b/intl/unicharutil/util/moz.build
@@ -39,9 +39,12 @@ if CONFIG['_MSC_VER']:
CFLAGS += ['-Zl']
CXXFLAGS += ['-Zl']
if CONFIG['ENABLE_INTL_API']:
CXXFLAGS += CONFIG['MOZ_ICU_CFLAGS']
LOCAL_INCLUDES += CONFIG['MOZ_ICU_INCLUDES']
USE_LIBS += ['icu']
+if CONFIG['MOZ_NATIVE_HARFBUZZ']:
+ CXXFLAGS += CONFIG['MOZ_HARFBUZZ_CFLAGS']
+
DIST_INSTALL = True
diff --git a/netwerk/dns/moz.build b/netwerk/dns/moz.build
--- a/netwerk/dns/moz.build
+++ b/netwerk/dns/moz.build
@@ -61,16 +61,19 @@ etld_data = GENERATED_FILES['etld_data.i
etld_data.script = 'prepare_tlds.py'
etld_data.inputs = ['effective_tld_names.dat']
# need to include etld_data.inc
LOCAL_INCLUDES += [
'/netwerk/base',
]
+if CONFIG['MOZ_NATIVE_HARFBUZZ']:
+ CXXFLAGS += CONFIG['MOZ_HARFBUZZ_CFLAGS']
+
if CONFIG['MOZ_WIDGET_TOOLKIT'] == 'gonk' and CONFIG['ANDROID_VERSION'] > '19':
LOCAL_INCLUDES += ['%' + '%s/bionic/libc/dns/include' % CONFIG['ANDROID_SOURCE']]
if CONFIG['ENABLE_INTL_API']:
DEFINES['IDNA2008'] = True
CXXFLAGS += CONFIG['MOZ_ICU_CFLAGS']
CFLAGS += CONFIG['MOZ_ICU_CFLAGS']
LOCAL_INCLUDES += CONFIG['MOZ_ICU_INCLUDES']
diff --git a/configure.in b/configure.in
--- a/configure.in
+++ b/configure.in
@@ -6425,16 +6425,59 @@ if test "$USE_FC_FREETYPE"; then
else
FT2_CFLAGS="$FT2_CFLAGS $_FONTCONFIG_CFLAGS"
FT2_LIBS="$FT2_LIBS $_FONTCONFIG_LIBS"
fi
])
fi
dnl ========================================================
+dnl Check for harfbuzz
+dnl ========================================================
+
+MOZ_ARG_WITH_BOOL(system-harfbuzz,
+[ --with-system-harfbuzz Use system harfbuzz (located with pkgconfig)],
+MOZ_NATIVE_HARFBUZZ=1,
+MOZ_NATIVE_HARFBUZZ=)
+
+if test -n "$MOZ_NATIVE_HARFBUZZ"; then
+ PKG_CHECK_MODULES(MOZ_HARFBUZZ, harfbuzz >= 1.1.3)
+fi
+
+AC_SUBST(MOZ_NATIVE_HARFBUZZ)
+
+dnl ========================================================
+dnl Check for graphite2
+dnl ========================================================
+
+MOZ_ARG_WITH_BOOL(system-graphite2,
+[ --with-system-graphite2 Use system graphite2 (located with pkgconfig)],
+MOZ_NATIVE_GRAPHITE2=1,
+MOZ_NATIVE_GRAPHITE2=)
+
+if test -n "$MOZ_NATIVE_GRAPHITE2"; then
+ PKG_CHECK_MODULES(MOZ_GRAPHITE2, graphite2)
+
+ dnl graphite2.pc has bogus version, check manually
+ AC_TRY_COMPILE([ #include <graphite2/Font.h>
+ #define GR2_VERSION_REQUIRE(major,minor,bugfix) \
+ ( GR2_VERSION_MAJOR * 10000 + GR2_VERSION_MINOR \
+ * 100 + GR2_VERSION_BUGFIX >= \
+ (major) * 10000 + (minor) * 100 + (bugfix) )
+ ], [
+ #if !GR2_VERSION_REQUIRE(1,3,8)
+ #error "Insufficient graphite2 version."
+ #endif
+ ], [],
+ [AC_MSG_ERROR([--with-system-graphite2 requested but no working libgraphite2 found])])
+fi
+
+AC_SUBST(MOZ_NATIVE_GRAPHITE2)
+
+dnl ========================================================
dnl Check for pixman and cairo
dnl ========================================================
MOZ_TREE_CAIRO=1
MOZ_ARG_ENABLE_BOOL(system-cairo,
[ --enable-system-cairo Use system cairo (located with pkgconfig)],
MOZ_TREE_CAIRO=,
MOZ_TREE_CAIRO=1 )
diff --git a/toolkit/library/moz.build b/toolkit/library/moz.build
--- a/toolkit/library/moz.build
+++ b/toolkit/library/moz.build
@@ -230,16 +230,22 @@ if CONFIG['MOZ_NATIVE_LIBVPX']:
OS_LIBS += CONFIG['MOZ_LIBVPX_LIBS']
if not CONFIG['MOZ_TREE_PIXMAN']:
OS_LIBS += CONFIG['MOZ_PIXMAN_LIBS']
if CONFIG['MOZ_ALSA']:
OS_LIBS += CONFIG['MOZ_ALSA_LIBS']
+if CONFIG['MOZ_NATIVE_GRAPHITE2']:
+ OS_LIBS += CONFIG['MOZ_GRAPHITE2_LIBS']
+
+if CONFIG['MOZ_NATIVE_HARFBUZZ']:
+ OS_LIBS += CONFIG['MOZ_HARFBUZZ_LIBS']
+
if CONFIG['HAVE_CLOCK_MONOTONIC']:
OS_LIBS += CONFIG['REALTIME_LIBS']
if CONFIG['MOZ_WIDGET_TOOLKIT'] == 'android':
OS_LIBS += [
'GLESv2',
]
--- a/gfx/thebes/moz.build 2016-04-22 16:55:14.249871300 -0400
+++ b/gfx/thebes/moz.build 2016-04-22 16:56:34.149595582 -0400
@@ -306,7 +306,14 @@
LOCAL_INCLUDES += CONFIG['SKIA_INCLUDES']
-DEFINES['GRAPHITE2_STATIC'] = True
+if CONFIG['MOZ_NATIVE_HARFBUZZ']:
+ CXXFLAGS += CONFIG['MOZ_HARFBUZZ_CFLAGS']
+
+if CONFIG['MOZ_NATIVE_GRAPHITE2']:
+ CXXFLAGS += CONFIG['MOZ_GRAPHITE2_CFLAGS']
+else:
+ DEFINES['GRAPHITE2_STATIC'] = True
+
if CONFIG['CLANG_CXX']:
# Suppress warnings from Skia header files.
--- a/gfx/skia/generate_mozbuild.py 2016-03-15 18:37:29.000000000 -0400
+++ b/gfx/skia/generate_mozbuild.py 2016-04-22 20:29:06.972228378 -0400
@@ -155,6 +155,9 @@
if CONFIG['CPU_ARCH'] == 'arm':
SOURCES['skia/src/opts/SkBlitRow_opts_arm.cpp'].flags += ['-fomit-frame-pointer']
+if CONFIG['MOZ_NATIVE_HARFBUZZ']:
+ CXXFLAGS += CONFIG['MOZ_HARFBUZZ_CFLAGS']
+
if CONFIG['MOZ_WIDGET_TOOLKIT'] in ('gtk2', 'gtk3', 'android', 'gonk', 'qt'):
CXXFLAGS += CONFIG['MOZ_CAIRO_CFLAGS']
CXXFLAGS += CONFIG['CAIRO_FT_CFLAGS']
--- a/gfx/skia/moz.build 2016-03-15 18:37:29.000000000 -0400
+++ b/gfx/skia/moz.build 2016-04-22 20:28:18.202338752 -0400
@@ -684,6 +684,9 @@
if CONFIG['CPU_ARCH'] == 'arm':
SOURCES['skia/src/opts/SkBlitRow_opts_arm.cpp'].flags += ['-fomit-frame-pointer']
+if CONFIG['MOZ_NATIVE_HARFBUZZ']:
+ CXXFLAGS += CONFIG['MOZ_HARFBUZZ_CFLAGS']
+
if CONFIG['MOZ_WIDGET_TOOLKIT'] in ('gtk2', 'gtk3', 'android', 'gonk', 'qt'):
CXXFLAGS += CONFIG['MOZ_CAIRO_CFLAGS']
CXXFLAGS += CONFIG['CAIRO_FT_CFLAGS']
...and this is the firefox.scm wip (which I said above
is broken and has broken syntax and also contradicting
statements in the comments as things need to be removed
and edited)
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2016 ng0 <ng0@we.make.ritual.n0.is>
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
(define-module (gnu packages firefox)
#:use-module ((srfi srfi-1) #:hide (zip))
#:use-module (gnu packages)
#:use-module ((guix licenses) #:prefix license:)
#:use-module (guix packages)
#:use-module (guix download)
#:use-module (guix build-system gnu)
#:use-module (gnu packages databases)
#:use-module (gnu packages glib)
#:use-module (gnu packages gstreamer)
#:use-module (gnu packages gtk)
#:use-module (gnu packages gnome)
#:use-module (gnu packages libcanberra)
#:use-module (gnu packages cups)
#:use-module (gnu packages mit-krb5)
#:use-module (gnu packages linux)
#:use-module (gnu packages perl)
#:use-module (gnu packages pkg-config)
#:use-module (gnu packages compression)
#:use-module (gnu packages fontutils)
#:use-module (gnu packages libevent)
#:use-module (gnu packages libreoffice) ;for hunspell
#:use-module (gnu packages image)
#:use-module (gnu packages libffi)
#:use-module (gnu packages pulseaudio)
#:use-module (gnu packages python)
#:use-module (gnu packages xorg)
#:use-module (gnu packages gl)
#:use-module (gnu packages assembly)
#:use-module (gnu packages icu4c)
#:use-module (gnu packages video)
#:use-module (gnu packages xdisorg)
#:use-module (gnu packages zip)
#:use-module (gnu packages gnuzilla))
(define-public firefox
(package
(name "firefox")
(version "45.2.0esr")
(source
(origin
(method url-fetch)
(uri (string-append "https://archive.mozilla.org/pub/"
name "/releases/" version "/source/"
name "-" version ".source.tar.xz"))
(sha256
(base32
"0jw0firs0rsg1a6msxbw6kar49rlscbnwmasvhcwjca20ds9fwhs"))
(patches (search-patches
"icecat-avoid-bundled-includes.patch"
"firefox_system_harfbuzz_graphite_bug847568.patch"
"firefox_allow-utf8-fallback.patch"))
(modules '((guix build utils)))
;; we might encounter things here which have been
;; solved in the patchsets by gentoo.
(snippet
'(begin
(for-each delete-file-recursively
'("intl/icu" "nsprpub"
"modules/freetype2" "modules/zlib"
"modules/libbz2"
"ipc/chromium/src/third_party/libevent"
"media/libvpx" "security/nss" "gfx/cairo"
"js/src/ctypes/libffi" "db/sqlite3"))
;; todo? libogg libtheora
;; libvorbis libopus speex
;; not packaged atm: libtremor
;; not packaged atm: soundtouch))
#t))))
;; according to gentoo those are the deps:
;; rdep: >=nss-3.21.1 >=nspr-4.12
;; dep: opengl
;; how to build:
;; 1. do stuff, patches etc
;; 2. autoreconf, cd js/src autoreconf
;; update configure of jemalloc(? wat):
;;; cd memory/jemalloc/src autoreconf
;; preconfigure it:
;; configure (build) it:
;; CC= CXX= LD=
;; also: MOZ_MAKE_FLAGS="stuff" SHELL="/bin/bash"
;; make -f client.mk realbuild
;; install it:
;; as branding we'll use official it seems:
;; part of make already:
;; sizes="16 22 24 32 256" icon_path="browser/branding/official" icon="firefox" name="Mozilla Firefox"
;; for size in ${sizes}; do
;; insinto "/share/icons/hicolor/${size}x${size}/apps"
;; newins "${icon_path}/default${size}.png" "${icon}.png"
;; done
;; different name for 128x128
;; insinto /share/icons/hicolor/128x128/apps
;; newins "${icon_path}/mozicon128.png" "${icon}.png"
;; legacy DEs:
;; newicon "${icon_path}/content/icon48.png" "${icon}.png"
;; newmenu "${FILESDIR}/icon/${PN}.desktop" "${PN}.desktop"
;; sed -i -e "s:@NAME@:${name}:" -e "s:@ICON@:${icon}:" \
;; "${ED}/usr/share/applications/${PN}.desktop" || die
;; update the gnome icon cache.
;; done.
;; I package this version for a future inherit of torbrowser.
;; some of the patches might only be specific to this version
(build-system gnu-build-system)
(inputs
`(("alsa-lib" ,alsa-lib)
("bzip2" ,bzip2)
("cairo" ,cairo)
("cups" ,cups)
("dbus-glib" ,dbus-glib)
("gdk-pixbuf" ,gdk-pixbuf)
("glib" ,glib)
("gstreamer" ,gstreamer)
("gst-plugins-base" ,gst-plugins-base)
("gtk+" ,gtk+-2)
("pango" ,pango)
("freetype" ,freetype)
("hunspell" ,hunspell)
("libcanberra" ,libcanberra)
("libgnome" ,libgnome)
("libxft" ,libxft)
("libevent" ,libevent)
("libxinerama" ,libxinerama)
("libxscrnsaver" ,libxscrnsaver)
("libxcomposite" ,libxcomposite)
("libxt" ,libxt)
("libffi" ,libffi)
("libvpx" ,libvpx)
("icu4c" ,icu4c)
("pixman" ,pixman)
("pulseaudio" ,pulseaudio)
("mesa" ,mesa)
("mit-krb5" ,mit-krb5)
("nspr" ,nspr)
("nss" ,nss)
("sqlite" ,sqlite)
("startup-notification" ,startup-notification)
("unzip" ,unzip)
("yasm" ,yasm)
("zip" ,zip)
("zlib" ,zlib)))
(native-inputs
`(("perl" ,perl)
("python" ,python-2) ; Python 3 not supported
("python2-pysqlite" ,python2-pysqlite)
("pkg-config" ,pkg-config)))
;; firefox 45esr depends on either qt5 or gtk3 (or gtk2?)
(arguments
`(#:out-of-source? #t ; built outside of source dir
;;#:tests? #f ;assumption: no check target.
;;#:validate-runpath? #f
#:configure-flags
'(;; debug build: 8GiB, normal: 4GiB
"--disable-debug" "--disable-debug-symbols"
;; use system libs:
"--with-system-zlib" "--with-system-bz2"
"--with-system-libevent" "--with-system-libvpx"
"--with-system-icu"
"--with-system-nspr" "--with-nspr-prefix=/location"
"--with-system-nss" "--with-nss-prefix=/location"
"--enable-system-pixman" "--enable-system-cairo"
"--enable-system-ffi" "--enable-system-hunspell"
"--enable-system-sqlite"
;; --enable-system-cairo ;; --with-system-jpeg
;; --with-system-harfbuff ;; --with-system-graphite2 (?)
;; other
"--enable-pango" "--enable-svg" ; wasn't there a bug w png?
;; branding
;; If you want the resulting program to call itself "Firefox" instead
;; of "Shiretoko" or whatever, enable this option. However, those
;; binaries may not be distributed without permission from the
;; Mozilla Foundation, see https://www.mozilla.org/foundation/trademarks/.
"--with-branding=browser/branding/aurora"
;; necko-wifi is optional, disable it (wth is this even):
"--disable-necko-wifi"
;; for now, disable google api ... however this works:
;; todo.
;; media
"--enable-ogg" "--enable-wave"
"--enable-gstreamer=1.0" "--enable-pulseaudio"
;; general
"--libdir=/location" "--enable-gio"
"--disable-crashreporter" "--enable-system-ffi"
"--enable-default-toolkit=cairo-gtk3"
;; unclear:
;; "--disable-skia" "--disable-gconf"
;; can the guix let firefox play in sandboxes? is it necessary?
"--enable-content-sandbox" ; wtf that
"--disable-content-sandbox-reporter"
;;"--disable-installer" "--enable-release" ; ? wth
;;"--enable-official-branding" ; (c)!
;;"--enable-strip" "--enable-optimize" ;? wat.
"--disable-updater" "--with-intl-api")
#:modules ((ice-9 ftw)
(ice-9 rdelim)
(ice-9 match)
,@%gnu-build-system-modules)
#:phases
(modify-phases %standard-phases
(add-after 'unpack 'ensure-no-mtimes-pre-1980
(lambda _
(let ((early-1980 315619200)) ; 1980-01-02 utc
(ftw "." (lambda (file stat flag)
(unless (<= early-1980 (stat:mtime stat))
(utime file early-1980 early-1980))
#t))
#t)))
(add-after 'unpack 'remove-h264parse-from-blacklist
(lambda _
(substitute* "dom/media/gstreamer/GStreamerFormatHelper.cpp"
(("^ \"h264parse\",\n") ""))
#t))
(add-after 'unpack 'arrange-to-link-libxul-with-libraries-it-might-dlopen
(lambda _
(substitute* "toolkit/library/moz.build"
(("^# This needs to be last")
"OS_LIBS += [
'GL', 'gnome-2', 'canberra', 'Xss', 'cups', 'gssapi_krb5',
'gstreamer-1.0', 'gstapp-1.0', 'gstvideo-1.0', ]\n\n"))
#t))
(add-after 'unpack 'use-system-harfbuzz-graphite
(lambda _
(substitute* "config/Makefile.in"
(("^-DMOZ_NATIVE_ICU=$(MOZ_NATIVE_ICU) \\")
"-DMOZ_NATIVE_ICU=$(MOZ_NATIVE_ICU) \\\n
-DMOZ_NATIVE_GRAPHITE2=$(MOZ_NATIVE_GRAPHITE2) \\\n
-DMOZ_NATIVE_HARFBUZZ=$(MOZ_NATIVE_HARFBUZZ) \\\n"))
(substitute* "config/system-headers"
(("^unwind.h")
"unwind.h\n
#if MOZ_NATIVE_GRAPHITE2==1\n
graphite2/Font.h\n
graphite2/Segment.h\n
#endif\n
#if MOZ_NATIVE_HARFBUZZ==1\n
harfbuzz/hb-ot.h\n
harfbuzz/hb.h\n
#endif"))
(substitute* "dom/base/moz.build"
(("^if CONFIG['MOZ_X11']:\n
CXXFLAGS += CONFIG['TK_CFLAGS']")
"^if CONFIG['MOZ_X11']:\n
CXXFLAGS += CONFIG['TK_CFLAGS']\n
if CONFIG['MOZ_NATIVE_HARFBUZZ']:\n
CXXFLAGS += CONFIG['MOZ_HARFBUZZ_CFLAGS']\n\n"))
(substitute* "gfx/graphite2/moz-gr-update.sh"
(("^# Script used to update the Graphite2 library in the mozilla source tree")
"# Script used to update the Graphite2 library in the mozilla source tree
# and bump version for --with-system-graphite2")
(("#find gfx/graphite2/ -name \"*.h\" -exec perl -p -i -e \"s/<cstdio>/<stdio.h>/;s/Windows.h/windows.h/;\" {} \;")
"#find gfx/graphite2/ -name \"*.h\" -exec perl -p -i -e \"s/<cstdio>/<stdio.h>/;s/Windows.h/windows.h/;\" {} \;\n\n
# chase version for --with-system-graphite2
perl -p -i -e \"s/[0-9]+\,[0-9]+\,[0-9]+/$RELEASE/ and tr/./,/ \
if /GR2_VERSION_REQUIRE/\" configure.in\n\n")
(("hg stat gfx/graphite2")
"hg stat configure.in gfx/graphite2"))
(substitute* "gfx/moz.build"
(("^if CONFIG['MOZ_TREE_CAIRO']:\n
DIRS += ['cairo']")
"if CONFIG['MOZ_TREE_CAIRO']:\n
DIRS += ['cairo']\n
if not CONFIG['MOZ_NATIVE_GRAPHITE2']:\n
DIRS += ['graphite2/src' ]\n\n
if not CONFIG['MOZ_NATIVE_HARFBUZZ']:\n
DIRS += ['harfbuzz/src']\n\n")
(("DIRS += [\n
'2d',\n
'ycbcr',\n
'angle',\n
'src',\n
'qcms',\n
'gl',\n
'layers',\n
'graphite2/src',\n
'harfbuzz/src',\n
'ots/src',\n
'thebes',\n
'ipc',\n
'vr',\n
]\n")
"DIRS += [\n
'2d',\n
'ycbcr',\n
'angle',\n
'src',\n
'qcms',\n
'gl',\n
'layers',\n
'ots/src',\n
'thebes',\n
'ipc',\n
'vr',\n
]\n"))
(substitute* "intl/unicharutil/util/moz.build"
(("if CONFIG['ENABLE_INTL_API']:\n
CXXFLAGS += CONFIG['MOZ_ICU_CFLAGS']\n
LOCAL_INCLUDES += CONFIG['MOZ_ICU_INCLUDES']\n
USE_LIBS += ['icu']\n\n")
"if CONFIG['ENABLE_INTL_API']:\n
CXXFLAGS += CONFIG['MOZ_ICU_CFLAGS']\n
LOCAL_INCLUDES += CONFIG['MOZ_ICU_INCLUDES']\n
USE_LIBS += ['icu']\n\n
if CONFIG['MOZ_NATIVE_HARFBUZZ']:\n
CXXFLAGS += CONFIG['MOZ_HARFBUZZ_CFLAGS']\n\n"))
(substitute* "netwerk/dns/moz.build"
(("# need to include etld_data.inc
LOCAL_INCLUDES += [\n
'/netwerk/base',\n
]\n\n")
"# need to include etld_data.inc
330LOCAL_INCLUDES += [\n
331'/netwerk/base',\n
332]\n\n
if CONFIG['MOZ_NATIVE_HARFBUZZ']:\n
CXXFLAGS += CONFIG['MOZ_HARFBUZZ_CFLAGS']\n\n"))
(substitute* "configure.in"
(("else\n
FT2_CFLAGS=\"$FT2_CFLAGS $_FONTCONFIG_CFLAGS\"\n
FT2_LIBS=\"$FT2_LIBS $_FONTCONFIG_LIBS\"\n
fi\n
])\n
fi\n\n
dnl ========================================================\n")
"else\n
FT2_CFLAGS=\"$FT2_CFLAGS $_FONTCONFIG_CFLAGS\"\n
FT2_LIBS=\"$FT2_LIBS $_FONTCONFIG_LIBS\"\n
fi\n
])\n
fi\n\n
dnl ========================================================\n
dnl Check for harfbuzz\n
dnl ========================================================\n\n
MOZ_ARG_WITH_BOOL(system-harfbuzz,\n
[ --with-system-harfbuzz Use system harfbuzz (located with pkgconfig)],\n
MOZ_NATIVE_HARFBUZZ=1,\n
MOZ_NATIVE_HARFBUZZ=)\n\n
if test -n \"$MOZ_NATIVE_HARFBUZZ\"\; then\n
PKG_CHECK_MODULES(MOZ_HARFBUZZ, harfbuzz >= 1.1.3)\n
fi\n\n
AC_SUBST(MOZ_NATIVE_HARFBUZZ)\n\n
dnl ========================================================\n
dnl Check for graphite2\n
dnl ========================================================\n\n
MOZ_ARG_WITH_BOOL(system-graphite2,\n
[ --with-system-graphite2 Use system graphite2 (located with pkgconfig)],\n
MOZ_NATIVE_GRAPHITE2=1,\n
MOZ_NATIVE_GRAPHITE2=)\n\n
if test -n \"$MOZ_NATIVE_GRAPHITE2\"\; then\n
PKG_CHECK_MODULES(MOZ_GRAPHITE2, graphite2)\n\n
dnl graphite2.pc has bogus version, check manually\n
AC_TRY_COMPILE([ #include <graphite2/Font.h>\n
#define GR2_VERSION_REQUIRE(major,minor,bugfix) \\\n
( GR2_VERSION_MAJOR * 10000 + GR2_VERSION_MINOR \\\n
* 100 + GR2_VERSION_BUGFIX >= \\\n
(major) * 10000 + \(minor\) * 100 + \(bugfix\) \) \n
], [\n
#if !GR2_VERSION_REQUIRE(1,3,8\)\n
#error \"Insufficient graphite2 version.\"\n
#endif\n
], [],\n
[AC_MSG_ERROR([--with-system-graphite2 requested but no working libgraphite2 found]\)])\n
fi\n\n
AC_SUBST(MOZ_NATIVE_GRAPHITE2\)\n\n
dnl ========================================================\n"))
#t))
(replace 'configure
(lambda* (#:key outputs configure-flags #:allow-other-keys)
(let* ((out (assoc-ref outputs "out"))
(bash (which "bash"))
(abs-srcdir (getcwd))
(srcdir (string-append "../" (basename abs-srcdir)))
(flags `(,(string-append "--prefix=" out)
,(string-append "--with-l10n-base="
abs-srcdir "/l10n")
,@configure-flags)))
(setenv "SHELL" bash)
(setenv "CONFIG_SHELL" bash)
;; or objdir...?:
(mkdir "../build")
(chdir "../build")
(format #t "build directory: ~s~%" (getcwd))
(format #t "configure flags: ~s~%" flags)
(zero? (apply system* bash
(string-append srcdir "/configure")
flags)))))
;; we are entirely missing a .desktop afaic.
;;(add-before 'configure 'install-desktop-entry)
(synopsis "I shit unicorns")
(description "I kissed a brick and I licked it.")
(home-page "https://www.mozilla.com/firefox")
(license license:mpl2.0)
;; for graphite we want to do:
;; echo "sticky_pref(\"gfx.font_rendering.graphite.enabled\",true);" >> "${prefs_file}" || die
;; we also want gmp blobs to be disabled..
--
♥Ⓐ ng0
For non-prism friendly talk find me on
psyced.org / loupsycedyglgamf.onion
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: patches question
2016-06-23 11:30 ` ng0
@ 2016-06-23 20:14 ` Andreas Enge
2016-06-23 22:18 ` ng0
0 siblings, 1 reply; 22+ messages in thread
From: Andreas Enge @ 2016-06-23 20:14 UTC (permalink / raw)
To: guix-devel
On Thu, Jun 23, 2016 at 11:30:35AM +0000, ng0 wrote:
> In the case of netcat-openbsd, Debian is the Linux upstream,
> maintaining the port of netcat from OpenBSD.
> The patches have not seen an update since 2012 and are still
> functional.
> I can understand that we don't want to maintain more patches
> than necessary, so in the case of netcat-openbsd I'll contact
> Debian, as mentioned in the thread of the patch, to ask about
> a merge of their patches into their maintained port.
So did I understand correctly that the Debian project maintains the "official"
tarball of the software package, and at the same time, the same person main-
tains a patch series that is not part of the tarball? This sounds very
surprising.
Andreas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: patches question
2016-06-23 13:23 ` ng0
@ 2016-06-23 20:27 ` Andreas Enge
2016-06-24 12:09 ` Ludovic Courtès
1 sibling, 0 replies; 22+ messages in thread
From: Andreas Enge @ 2016-06-23 20:27 UTC (permalink / raw)
To: guix-devel
On Thu, Jun 23, 2016 at 01:23:47PM +0000, ng0 wrote:
> Firefox wip, untested, not even run, just filling in fixes
> which very likely have broken syntax looks like the later
> inserted file. In this file there is a 140+ lines phase
> which aims at doing what the following inserted patch
> does. It is still growing (2 files left to patch).
> As 'maybe' icecat can make use of the harfbuzz graphite
> phase in this case it makes more sense to drop it
> into gnu/packages/patches/ .. right?
I must admit I have difficulties understanding what you are trying to do
(after I finally managed to parse the first sentence above, in which it
is rather unclear who or what is the subject of the different verbs).
It is clear that the complicated scheme "substitute*" in your package
definition are inferior to a real patch; if all they do is just reimplement
finely chiselled patches, they do not make sense.
The example I had in mind for uses of "substitute*" was when a string could
be replaced by another one everywhere in files, for instance "/bin/sh" by
"sh" or these kinds of things; then "substitute*" will still work, even
if a few lines are swapped in the file or the string occurs once more or
less in a later version. A patch would fail in that situation.
It looks like you are trying to use the system harfbuzz instead of a bundled
copy? Or the system graphite? If that is the case, maybe it would be optimal
to propose a patch upstream? The icecat package definition contains a few
comments pointing to bug reports at bugzilla.mozilla.org.
Andreas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: patches question
2016-06-23 20:14 ` Andreas Enge
@ 2016-06-23 22:18 ` ng0
0 siblings, 0 replies; 22+ messages in thread
From: ng0 @ 2016-06-23 22:18 UTC (permalink / raw)
To: guix-devel
On 2016-06-23(10:14:50PM+0200), Andreas Enge wrote:
> On Thu, Jun 23, 2016 at 11:30:35AM +0000, ng0 wrote:
> > In the case of netcat-openbsd, Debian is the Linux upstream,
> > maintaining the port of netcat from OpenBSD.
> > The patches have not seen an update since 2012 and are still
> > functional.
> > I can understand that we don't want to maintain more patches
> > than necessary, so in the case of netcat-openbsd I'll contact
> > Debian, as mentioned in the thread of the patch, to ask about
> > a merge of their patches into their maintained port.
>
> So did I understand correctly that the Debian project maintains the "official"
> tarball of the software package, and at the same time, the same person main-
> tains a patch series that is not part of the tarball? This sounds very
> surprising.
>
> Andreas
>
>
Correct. It is indeed surprising, but I don't know if there
is a consensus in debian in how to deal with this.
Other distributions (like gentoo) pull both the source and
the patches tarball and use them as if they were one and the
same.
--
♥Ⓐ ng0
For non-prism friendly talk find me on
psyced.org / loupsycedyglgamf.onion
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: patches question
2016-06-23 13:23 ` ng0
2016-06-23 20:27 ` Andreas Enge
@ 2016-06-24 12:09 ` Ludovic Courtès
2016-06-24 13:43 ` ng0
1 sibling, 1 reply; 22+ messages in thread
From: Ludovic Courtès @ 2016-06-24 12:09 UTC (permalink / raw)
To: guix-devel
Hello!
ng0 <ng0@we.make.ritual.n0.is> skribis:
> diff --git a/config/Makefile.in b/config/Makefile.in
> --- a/config/Makefile.in
> +++ b/config/Makefile.in
I view this patch as upstream work that Guix should not carry. To put
it differently, it’s not Guix’s missing to maintain a fork of Firefox
(or any other package).
> (define-public firefox
> (package
> (name "firefox")
> (version "45.2.0esr")
What is the goal here?
Guix proper can provide IceCat (which modifies Firefox to comply with
trademark rules, to comply with the GNU FSDG¹, and to enhance privacy),
maybe Tor Browser (assuming it complies with the FSDG as well), but not
stock Firefox (unless the trademark issue and FSDG violations are
resolved.)
Besides, I think it should be possible to (inherit icecat) rather than
duplicate all the recipe.
Hope this clarifies things!
Thanks,
Ludo’.
¹ https://www.gnu.org/distros/free-system-distribution-guidelines.html
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: patches question
2016-06-24 12:09 ` Ludovic Courtès
@ 2016-06-24 13:43 ` ng0
2016-06-24 15:48 ` Tor Browser Ludovic Courtès
0 siblings, 1 reply; 22+ messages in thread
From: ng0 @ 2016-06-24 13:43 UTC (permalink / raw)
To: guix-devel
On 2016-06-24(02:09:39PM+0200), Ludovic Courtès wrote:
> Hello!
>
> ng0 <ng0@we.make.ritual.n0.is> skribis:
>
> > diff --git a/config/Makefile.in b/config/Makefile.in
> > --- a/config/Makefile.in
> > +++ b/config/Makefile.in
>
> I view this patch as upstream work that Guix should not carry. To put
> it differently, it’s not Guix’s missing to maintain a fork of Firefox
> (or any other package).
I cleared up some code since I posted this. We do not have to include the
patch for the libraries (if this is what this was refering to).
> > (define-public firefox
> > (package
> > (name "firefox")
> > (version "45.2.0esr")
>
> What is the goal here?
>
> Guix proper can provide IceCat (which modifies Firefox to comply with
> trademark rules, to comply with the GNU FSDG¹, and to enhance privacy),
> maybe Tor Browser (assuming it complies with the FSDG as well), but not
> stock Firefox (unless the trademark issue and FSDG violations are
> resolved.)
Writing a base for torbrowser, as icecat is too old for torbrowser
(different version of firefox) and I'd like to replicate torbrowser
in a way which is compatible to us.
If this requires to construct the browser based on what icecat does
but with guix package phase patching, I see no problem with this
other than potential legal issues which need to be clarified by other
people.
> Besides, I think it should be possible to (inherit icecat) rather than
> duplicate all the recipe.
True, but between 38.8 and 45.2.0 things change, patches can not be reused,
and the reason I gave above.
> Hope this clarifies things!
>
> Thanks,
> Ludo’.
>
> ¹ https://www.gnu.org/distros/free-system-distribution-guidelines.html
>
I am more willing to maintain another fork of firefox than to
wait for icecat to be recent enough to be usable as a base for
a torbrowser package.
Additionally I was about to get in contact with torproject and
ask about possible trademark/confusion issues on their side,
the unsent email:
Hello,
I'm currently in the process of packaging a modified firefox
for GNU Guix[1], for safety labeled "icepanda" for now.
My intention with this is to provide a base package for a
torbrowser which will be compatible for us as a GNU project.
The resulting torbrowser will be different from what
torproject ships in binaries:
- we need to remove certain addons of base firefox,
- replace as much included libraries with our system
packaged libraries as possible,
- replace the mozilla store which recommends non-free
software
- there are two solutions here, the long term one
I prefer is to import browser addons into our
reproducible store
- rebrand the firefox to prevent trademark issues.
Once torbrowser can inherit this firefox brand and
is functional this way, we will inform users that
this is an unofficial build and that usage might be
dangerous depending on their threat level etc
(comparable to the pkg_postinstall() in [0]), a note
which has yet to be written.
The base (firefox) is obviously altered, but I can not
tell at this moment how much of torbrowser, if anything
at all, needs to be adjusted. My guess is that torbrowser
specific changes can technically be included without
problems, the practical part leads me to my question.
Potential usage issues I am interested in include if/how
much the default fingerprint of the webbrowser differs
from the binary you ship.
The question I now have is, are we allowed to use the name
torbrowser for the binary substitute we will distribute,
or is this a potential trademark / confusion issue (as
written in your FAQ) and we should pick a different name
like "onionpanda" (going with the current work in progress
name "icepanda")?
[0]: https://data.gpo.zugaina.org/torbrowser/www-client/torbrowser/torbrowser-45.2.0_p602.ebuild
[1]: https://www.gnu.org/s/guix
--
♥Ⓐ ng0
For non-prism friendly talk find me on
psyced.org / loupsycedyglgamf.onion
^ permalink raw reply [flat|nested] 22+ messages in thread
* Tor Browser
2016-06-24 13:43 ` ng0
@ 2016-06-24 15:48 ` Ludovic Courtès
2016-06-24 17:49 ` ng0
0 siblings, 1 reply; 22+ messages in thread
From: Ludovic Courtès @ 2016-06-24 15:48 UTC (permalink / raw)
To: guix-devel
ng0 <ng0@we.make.ritual.n0.is> skribis:
> On 2016-06-24(02:09:39PM+0200), Ludovic Courtès wrote:
[...]
>> > (define-public firefox
>> > (package
>> > (name "firefox")
>> > (version "45.2.0esr")
>>
>> What is the goal here?
>>
>> Guix proper can provide IceCat (which modifies Firefox to comply with
>> trademark rules, to comply with the GNU FSDG¹, and to enhance privacy),
>> maybe Tor Browser (assuming it complies with the FSDG as well), but not
>> stock Firefox (unless the trademark issue and FSDG violations are
>> resolved.)
>
> Writing a base for torbrowser
Great! Then I think you don’t need to worry about Firefox at all.
Maybe TB uses Firefox’s source and then patches it, but that doesn’t
mean we need a Firefox package.
>> Besides, I think it should be possible to (inherit icecat) rather than
>> duplicate all the recipe.
>
> True, but between 38.8 and 45.2.0 things change, patches can not be reused,
> and the reason I gave above.
Then use the Firefox 45 source as a starting point.
> I am more willing to maintain another fork of firefox than to
> wait for icecat to be recent enough to be usable as a base for
> a torbrowser package.
I think there’s a misunderstanding: if Guix provides Tor Browser, then
it should provide precisely Tor Browser, not Firecat or Icefox with 20
patches. :-)
> Additionally I was about to get in contact with torproject and
> ask about possible trademark/confusion issues on their side,
> the unsent email:
I think we do not need to bother them. AFAIK, we can use the name “Tor
Browser” just fine, so there’s no reason to invent another name or
anything.
The only issue that needs to be addressed (but again, we don’t need to
bother the Tor folks with that) is whether Tor Browser is FSDG-compliant
(concretely, whether it recommends non-free software, for instance.)
HTH!
Ludo’.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tor Browser
2016-06-24 15:48 ` Tor Browser Ludovic Courtès
@ 2016-06-24 17:49 ` ng0
2016-06-26 10:05 ` Ludovic Courtès
0 siblings, 1 reply; 22+ messages in thread
From: ng0 @ 2016-06-24 17:49 UTC (permalink / raw)
To: guix-devel
On 2016-06-24(05:48:49PM+0200), Ludovic Courtès wrote:
> ng0 <ng0@we.make.ritual.n0.is> skribis:
>
> > On 2016-06-24(02:09:39PM+0200), Ludovic Courtès wrote:
>
> [...]
>
> >> > (define-public firefox
> >> > (package
> >> > (name "firefox")
> >> > (version "45.2.0esr")
> >>
> >> What is the goal here?
> >>
> >> Guix proper can provide IceCat (which modifies Firefox to comply with
> >> trademark rules, to comply with the GNU FSDG¹, and to enhance privacy),
> >> maybe Tor Browser (assuming it complies with the FSDG as well), but not
> >> stock Firefox (unless the trademark issue and FSDG violations are
> >> resolved.)
> >
> > Writing a base for torbrowser
>
> Great! Then I think you don’t need to worry about Firefox at all.
> Maybe TB uses Firefox’s source and then patches it, but that doesn’t
> mean we need a Firefox package.
>
> >> Besides, I think it should be possible to (inherit icecat) rather than
> >> duplicate all the recipe.
> >
> > True, but between 38.8 and 45.2.0 things change, patches can not be reused,
> > and the reason I gave above.
>
> Then use the Firefox 45 source as a starting point.
Do we have something comparable? I thought it was better to start off
with a native 45.2.0esr, leave out this part of the gitian build of
torbrowser and try to just inherit/patch it that way.
Maybe my approach is still a bit gentoo'ish. In our Gentoo overlay we
replicated the gitian build, but I was only maintaining it and ocassionaly
doing a version bump and testing, I did not come up with the procedure.
What it does is the following:
A shallow checkout of https://git.torproject.org/tor-browser.git
which is usually pinned to a tag specified in the gitian build
repository of torproject for tor-browser,
pull in gentoo specific patchsets for the firefox version,
pull in an architecture specific torbrowser from either
https://archive.torproject.org/tor-package-archive/${PN}/${TOR_PV}or
https://dist.torproject.org/${PN}/${TOR_PV} (arch is x86 or amd64),
prepare the source:
1. apply firefox patches
2. revert "change the default firefox profile directory to be tbb-relative" (patch)
3. allow the lightspark and freshplayerplugins for whatever reasons (except them from a blocklist)
4. fix some nss problems
5. set the plugins directory to the global one of gentoo
6. fix sandbox violations
etc etc (very similar to firefox at this point and before it)
configure:
rename install executables and directories
disable the update + set the tor-browser version
install (build):
some orientation around the tor-browser-bunde.git repository
some firefox again
set a profile
install files.
After writing this out of the context of the ebuild syntax,
I can see why it could be build without a firefox package.
However we still would need to apply what icecat does,
at least part of it, where necessary.
Yesterday I wrote phases for most of what the icecat build
bash script does.
> > I am more willing to maintain another fork of firefox than to
> > wait for icecat to be recent enough to be usable as a base for
> > a torbrowser package.
>
> I think there’s a misunderstanding: if Guix provides Tor Browser, then
> it should provide precisely Tor Browser, not Firecat or Icefox with 20
> patches. :-)
" However we still would need to apply what icecat does, or "
" at least part of it. "
" Yesterday I wrote phases for most of what the icecat build "
" bash script does. "
Does this not apply here, that we need to patch torbrowser?
You can still use the mozilla store for example.
> > Additionally I was about to get in contact with torproject and
> > ask about possible trademark/confusion issues on their side,
> > the unsent email:
>
> I think we do not need to bother them. AFAIK, we can use the name “Tor
> Browser” just fine, so there’s no reason to invent another name or
> anything.
>
> The only issue that needs to be addressed (but again, we don’t need to
> bother the Tor folks with that) is whether Tor Browser is FSDG-compliant
> (concretely, whether it recommends non-free software, for instance.)
That's why I was about to ask them. Some parts needs to be changed,
out of the same motivation why icecat exists.
Their FAQ says that they "don't want to be trademark bullies", so
a good conversation is better than a sudden surprise on both ends.
No one can be an expert in everything, and international law is
something I don't claim to be an expert in, so I seek conversation.
~~~~~~
Aside, I wonder if crypto export laws would be applicable to
binaries of crypto software we package and some nations still
having regulations on them. And on top of that, what happens
when guix moves to secure, real distributed, peer-to-peer
package package distribution.
Not that I really care or believe that anyone is legally
responsible then, but I'm curious about the 'what if'.
~~~~~~
A bit related offtopic now, what I inteded to write in the
email to torproject and what I discussed this year with a
contact:
It would be nice to have a modified firefox
– or anything firefox based or being an application of top
of something which uses the mozilla app+extensions store –
which uses extensions, addons, apps, coming from the guix
store, imported by compatible licenses.
And I think this would be then a case where we, in the eyes
of the developers of affected software, have altered the
application, in my view just an extension of security but
for them it could mean an irritation.
Completely source based gentoo derivates can do something
in this direction already because they only provide you
with the source, not binaries.
We also provide binaries.
Would this be a modification gone too far already? I see
it as an extension to the software.
> HTH!
>
> Ludo’.
>
For the license part:
I have not double checked myself, but our ebuild says that
the codebase of torproject is under BSD license (which
probably is inaccurate and unspecific) and icons are under
the CCPL-Attribution-3.0
# BSD license applies to torproject-related code like the patches
# icons are under CCPL-Attribution-3.0
LICENSE="BSD CC-BY-3.0 MPL-2.0 GPL-2 LGPL-2.1"
--
♥Ⓐ ng0
For non-prism friendly talk find me on
psyced.org / loupsycedyglgamf.onion
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tor Browser
2016-06-24 17:49 ` ng0
@ 2016-06-26 10:05 ` Ludovic Courtès
2016-06-29 12:48 ` ng0
0 siblings, 1 reply; 22+ messages in thread
From: Ludovic Courtès @ 2016-06-26 10:05 UTC (permalink / raw)
To: guix-devel
Hi!
ng0 <ng0@we.make.ritual.n0.is> skribis:
> What it does is the following:
>
> A shallow checkout of https://git.torproject.org/tor-browser.git
> which is usually pinned to a tag specified in the gitian build
> repository of torproject for tor-browser,
> pull in gentoo specific patchsets for the firefox version,
> pull in an architecture specific torbrowser from either
> https://archive.torproject.org/tor-package-archive/${PN}/${TOR_PV}or
> https://dist.torproject.org/${PN}/${TOR_PV} (arch is x86 or amd64),
> prepare the source:
> 1. apply firefox patches
> 2. revert "change the default firefox profile directory to be tbb-relative" (patch)
> 3. allow the lightspark and freshplayerplugins for whatever reasons (except them from a blocklist)
> 4. fix some nss problems
> 5. set the plugins directory to the global one of gentoo
> 6. fix sandbox violations
> etc etc (very similar to firefox at this point and before it)
> configure:
> rename install executables and directories
> disable the update + set the tor-browser version
> install (build):
> some orientation around the tor-browser-bunde.git repository
> some firefox again
> set a profile
> install files.
I suppose TB contains a script that does all that, right? Would it work
to simply run it? If it invokes wget/curl, then this needs to be
replaced, but the rest should be fine.
It’s unfortunate that there’s no ready-to-build TB tarball, that would
simplify things for us.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tor Browser
2016-06-26 10:05 ` Ludovic Courtès
@ 2016-06-29 12:48 ` ng0
2016-06-30 10:29 ` Ludovic Courtès
0 siblings, 1 reply; 22+ messages in thread
From: ng0 @ 2016-06-29 12:48 UTC (permalink / raw)
To: guix-devel
Ludovic Courtès writes:
> Hi!
>
> ng0 <ng0@we.make.ritual.n0.is> skribis:
>
>> What it does is the following:
>>
>> A shallow checkout of https://git.torproject.org/tor-browser.git
>> which is usually pinned to a tag specified in the gitian build
>> repository of torproject for tor-browser,
>> pull in gentoo specific patchsets for the firefox version,
>> pull in an architecture specific torbrowser from either
>> https://archive.torproject.org/tor-package-archive/${PN}/${TOR_PV}or
>> https://dist.torproject.org/${PN}/${TOR_PV} (arch is x86 or amd64),
>> prepare the source:
>> 1. apply firefox patches
>> 2. revert "change the default firefox profile directory to be tbb-relative" (patch)
>> 3. allow the lightspark and freshplayerplugins for whatever reasons (except them from a blocklist)
>> 4. fix some nss problems
>> 5. set the plugins directory to the global one of gentoo
>> 6. fix sandbox violations
>> etc etc (very similar to firefox at this point and before it)
>> configure:
>> rename install executables and directories
>> disable the update + set the tor-browser version
>> install (build):
>> some orientation around the tor-browser-bunde.git repository
>> some firefox again
>> set a profile
>> install files.
>
> I suppose TB contains a script that does all that, right? Would it work
> to simply run it? If it invokes wget/curl, then this needs to be
> replaced, but the rest should be fine.
It's not that easy I'm afraid.
Currently they use a gitian build, as described in this README[0],
which the person maintaining the torbrowser ebuild for Gentoo out
of portage replicates and follows in parts.
It can't be followed completely, as `builders/tor-browser-bundle'
requires a checkout of gitian of the torproject.org
So we have to look at what they do and recreate this build
procedure, there's no individual Makefile, the releases are
created in VMs.
Dependencies are kept up to date here[1].
This[2] is the script connecting/using gitian for gnu-linux releases.
The Makefile just runs the corresponding scripts.
18 Months ago they also started a trac ticket on NixOS as an idea[3]
> It’s unfortunate that there’s no ready-to-build TB tarball, that would
> simplify things for us.
Yes.. But I think icecat suffers from the same problem, only that
icecat tarballs/binaries are built using a bash script applying
all that's needed to the firefox sources again.
> Thanks,
> Ludo’.
>
[0]: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/README.build
[1]: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/versions
[2]: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/mkbundle-linux.sh
[3]: https://trac.torproject.org/projects/tor/ticket/12520
--
♥Ⓐ ng0
For non-prism friendly talk find me on
psyced.org / loupsycedyglgamf.onion
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tor Browser
2016-06-29 12:48 ` ng0
@ 2016-06-30 10:29 ` Ludovic Courtès
2016-06-30 16:09 ` ng0
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Ludovic Courtès @ 2016-06-30 10:29 UTC (permalink / raw)
To: ng0; +Cc: guix-devel
ng0@we.make.ritual.n0.is skribis:
> Ludovic Courtès writes:
[...]
>> I suppose TB contains a script that does all that, right? Would it work
>> to simply run it? If it invokes wget/curl, then this needs to be
>> replaced, but the rest should be fine.
>
> It's not that easy I'm afraid.
> Currently they use a gitian build, as described in this README[0],
> which the person maintaining the torbrowser ebuild for Gentoo out
> of portage replicates and follows in parts.
> It can't be followed completely, as `builders/tor-browser-bundle'
> requires a checkout of gitian of the torproject.org
>
> So we have to look at what they do and recreate this build
> procedure, there's no individual Makefile, the releases are
> created in VMs.
>
> Dependencies are kept up to date here[1].
>
> This[2] is the script connecting/using gitian for gnu-linux releases.
>
> The Makefile just runs the corresponding scripts.
Gitian is about building binaries. There must be some script somewhere
to apply the relevant patches to the source first, before one builds it,
no?
>> It’s unfortunate that there’s no ready-to-build TB tarball, that would
>> simplify things for us.
>
> Yes.. But I think icecat suffers from the same problem, only that
> icecat tarballs/binaries are built using a bash script applying
> all that's needed to the firefox sources again.
IceCat publishes source tarballs that, AIUI, are produced essentially by
running a script that patches Firefox’s code base (same approach for
Linux-libre.)
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tor Browser
2016-06-30 10:29 ` Ludovic Courtès
@ 2016-06-30 16:09 ` ng0
2016-06-30 18:00 ` ng0
2016-08-05 13:35 ` ng0
2 siblings, 0 replies; 22+ messages in thread
From: ng0 @ 2016-06-30 16:09 UTC (permalink / raw)
To: guix-devel
Ludovic Courtès writes:
> ng0@we.make.ritual.n0.is skribis:
>
>> Ludovic Courtès writes:
>
> [...]
>
>>> I suppose TB contains a script that does all that, right? Would it work
>>> to simply run it? If it invokes wget/curl, then this needs to be
>>> replaced, but the rest should be fine.
>>
>> It's not that easy I'm afraid.
>> Currently they use a gitian build, as described in this README[0],
>> which the person maintaining the torbrowser ebuild for Gentoo out
>> of portage replicates and follows in parts.
>> It can't be followed completely, as `builders/tor-browser-bundle'
>> requires a checkout of gitian of the torproject.org
>>
>> So we have to look at what they do and recreate this build
>> procedure, there's no individual Makefile, the releases are
>> created in VMs.
>>
>> Dependencies are kept up to date here[1].
>>
>> This[2] is the script connecting/using gitian for gnu-linux releases.
>>
>> The Makefile just runs the corresponding scripts.
>
> Gitian is about building binaries. There must be some script somewhere
> to apply the relevant patches to the source first, before one builds it,
> no?
>
>>> It’s unfortunate that there’s no ready-to-build TB tarball, that would
>>> simplify things for us.
>>
>> Yes.. But I think icecat suffers from the same problem, only that
>> icecat tarballs/binaries are built using a bash script applying
>> all that's needed to the firefox sources again.
>
> IceCat publishes source tarballs that, AIUI, are produced essentially by
> running a script that patches Firefox’s code base (same approach for
> Linux-libre.)
>
> Thanks,
> Ludo’.
Torbrowser is due to recent events and focusing on something much
bigger (email introducing this will follow soon) not so high on
my priority list.
In fact tor circuits are so unreliable (at least it became very
annoying dealing with the connection amount of skipped circuits)
lately that I think of moving the things I use hidden-services
for to gnunet-vpn as soon as I find time to work around this on
the server.
However I will still find the relevant dirs and files so someone
I told about this might start working on it and proxy their work
through me to us (that's due to another reason I'd like to
address later).. If not, anyone else is welcome to spot this
email and start working.
Licenses used:
https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-Data/Docs/Licenses
I think these are also relevant:
https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/patches?id=d79acaf07209445b641061b09257a0ed0dd58340
Now I wonder if it'd be enough to just inherit icecat, replace
the source, apply some additional patches and it justworks™
I hope it's that easy.
--
♥Ⓐ ng0
For non-prism friendly talk find me on
psyced.org / loupsycedyglgamf.onion
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tor Browser
2016-06-30 10:29 ` Ludovic Courtès
2016-06-30 16:09 ` ng0
@ 2016-06-30 18:00 ` ng0
2016-08-05 13:35 ` ng0
2 siblings, 0 replies; 22+ messages in thread
From: ng0 @ 2016-06-30 18:00 UTC (permalink / raw)
To: guix-devel
Ludovic Courtès writes:
> ng0@we.make.ritual.n0.is skribis:
>
>> Ludovic Courtès writes:
>
> [...]
>
>>> I suppose TB contains a script that does all that, right? Would it
>>> work
>>> to simply run it? If it invokes wget/curl, then this needs to be
>>> replaced, but the rest should be fine.
>>
>> It's not that easy I'm afraid.
>> Currently they use a gitian build, as described in this README[0],
>> which the person maintaining the torbrowser ebuild for Gentoo out
>> of portage replicates and follows in parts.
>> It can't be followed completely, as `builders/tor-browser-bundle'
>> requires a checkout of gitian of the torproject.org
>>
>> So we have to look at what they do and recreate this build
>> procedure, there's no individual Makefile, the releases are
>> created in VMs.
>>
>> Dependencies are kept up to date here[1].
>>
>> This[2] is the script connecting/using gitian for gnu-linux
>> releases.
>>
>> The Makefile just runs the corresponding scripts.
>
> Gitian is about building binaries. There must be some script
> somewhere
> to apply the relevant patches to the source first, before one builds
> it,
> no?
>
>>> It’s unfortunate that there’s no ready-to-build TB tarball, that
>>> would
>>> simplify things for us.
>>
>> Yes.. But I think icecat suffers from the same problem, only that
>> icecat tarballs/binaries are built using a bash script applying
>> all that's needed to the firefox sources again.
>
> IceCat publishes source tarballs that, AIUI, are produced essentially
> by
> running a script that patches Firefox’s code base (same approach for
> Linux-libre.)
>
> Thanks,
> Ludo’.
Whoever is interested in continuing this, the below approach is
not the fine art and must be cut down in length, but it works.
You only have to look at what's in torbrowser sources and adapt
accordingly.
Good luck and success.
;; apparently for whatever reason torproject does not provide
;; individual language files, they are one lang included in
;; named sources as $name-$OS-$version_$lang.tar.xz
(define-public torbrowser
(package
(inherit icecat)
(name "torbrowser")
(version "6.0.2")
(source
(origin
(method url-fetch)
(uri (string-append "https://dist.torproject.org/"
name "/" version "/tor-browser"
"-linux64-" version "_en-US.tar.xz"))
(sha256
(base32
"08zik2id1rkcl5cw4yscdgb8rdahx342j1fps576465sziy5z06x"))))
;; (modules '((guix build utils)))
;; (snippet
;; '(begin
;; ;; Remove bundled libraries that we don't use, since they may
;; ;; contain unpatched security flaws, they waste disk space and
;; ;; network bandwidth, and may cause confusion.
;; (for-each delete-file-recursively
;; '(;; FIXME: Removing the bundled icu breaks configure.
;; ;; * The bundled icu headers are used in some places.
;; ;; * The version number is taken from the bundled copy.
;; ;;"intl/icu"
;; ;;
;; ;; FIXME: A script from the bundled nspr is used.
;; ;;"nsprpub"
;; ;;
;; ;; TODO: Use system media libraries. Waiting for:
;; ;; <https://bugzilla.mozilla.org/show_bug.cgi?id=517422>
;; ;; * libogg
;; ;; * libtheora
;; ;; * libvorbis
;; ;; * libtremor (not yet in guix)
;; ;; * libopus
;; ;; * speex
;; ;; * soundtouch (not yet in guix)
;; ;;
;; ;; TODO: Use system harfbuzz. Waiting for:
;; ;; <https://bugzilla.mozilla.org/show_bug.cgi?id=847568>
;; ;;
;; ;; TODO: Use system graphite2.
;; ;;
;; ;;;"modules/freetype2"
;; ;;;"modules/zlib"
;; ;;;"modules/libbz2"
;; "ipc/chromium/src/third_party/libevent"
;; "media/libvpx"
;; "security/nss"
;; "gfx/cairo"
;; "js/src/ctypes/libffi"
;; "db/sqlite3"))
;; #t))))
(build-system gnu-build-system)
(inputs
`(("alsa-lib" ,alsa-lib)
("bzip2" ,bzip2)
("cairo" ,cairo)
("cups" ,cups)
("dbus-glib" ,dbus-glib)
("gdk-pixbuf" ,gdk-pixbuf)
("glib" ,glib)
("gstreamer" ,gstreamer)
("gst-plugins-base" ,gst-plugins-base)
("gtk+" ,gtk+-2)
("pango" ,pango)
("freetype" ,freetype)
("hunspell" ,hunspell)
("libcanberra" ,libcanberra)
("libgnome" ,libgnome)
("libxft" ,libxft)
("libevent" ,libevent)
("libxinerama" ,libxinerama)
("libxscrnsaver" ,libxscrnsaver)
("libxcomposite" ,libxcomposite)
("libxt" ,libxt)
("libffi" ,libffi)
("libvpx" ,libvpx)
("icu4c" ,icu4c)
("pixman" ,pixman)
("pulseaudio" ,pulseaudio)
("mesa" ,mesa)
("mit-krb5" ,mit-krb5)
("nspr" ,nspr)
("nss" ,nss)
("sqlite" ,sqlite)
("startup-notification" ,startup-notification)
("unzip" ,unzip)
("yasm" ,yasm)
("zip" ,zip)
("zlib" ,zlib)))
(native-inputs
`(("perl" ,perl)
("python" ,python-2) ; Python 3 not supported
("python2-pysqlite" ,python2-pysqlite)
("pkg-config" ,pkg-config)))
(arguments
`(#:tests? #f ; no check target
#:out-of-source? #t ; must be built outside of the source directory
;; XXX: There are RUNPATH issues such as
;; $prefix/lib/icecat-31.6.0/plugin-container NEEDing libmozalloc.so,
;; which is not in its RUNPATH, but they appear to be harmless in
;; practice somehow. See <http://hydra.gnu.org/build/378133>.
#:validate-runpath? #f
#:configure-flags '("--enable-default-toolkit=cairo-gtk2"
"--enable-pango"
"--enable-gio"
"--enable-svg"
"--enable-canvas"
"--enable-mathml"
"--enable-startup-notification"
"--enable-pulseaudio"
"--enable-gstreamer=1.0"
"--disable-gnomevfs"
"--disable-gconf"
"--disable-gnomeui"
;; Building with debugging symbols takes ~5GiB, so
;; disable it.
"--disable-debug"
"--disable-debug-symbols"
;; Avoid bundled libraries.
;; "--with-system-zlib"
;; "--with-system-bz2"
;; "--with-system-libevent"
;; "--with-system-libvpx"
;; "--with-system-icu"
;; "--with-system-nspr"
;; "--with-system-nss"
;; "--enable-system-pixman"
;; "--enable-system-cairo"
;; "--enable-system-ffi"
;; "--enable-system-hunspell"
;; "--enable-system-sqlite"
;; Fails with "--with-system-png won't work because
;; the system's libpng doesn't have APNG support".
;; According to
;; http://sourceforge.net/projects/libpng-apng/ ,
;; "the Animated Portable Network Graphics (APNG)
;; is an unofficial extension of the Portable
;; Network Graphics (PNG) format";
;; we probably do not wish to support it.
;; "--with-system-png"
;; Fails with "libjpeg-turbo JCS_EXTENSIONS
;; required".
;; According to
;; http://sourceforge.net/projects/libjpeg-turbo/ ,
;; "libjpeg-turbo is a derivative of libjpeg that
;; uses MMX, SSE, SSE2, and NEON SIMD instructions
;; to accelerate baseline JPEG compression/
;; decompression", so we had better not use it
;; "--with-system-jpeg"
)
#:modules ((ice-9 ftw)
(ice-9 rdelim)
(ice-9 match)
,@%gnu-build-system-modules)
#:phases
(modify-phases %standard-phases
(add-after
'unpack 'ensure-no-mtimes-pre-1980
(lambda _
;; Without this, the 'source/test/addons/packed.xpi' and
;; 'source/test/addons/simple-prefs.xpi' targets fail while trying
;; to create zip archives.
(let ((early-1980 315619200)) ; 1980-01-02 UTC
(ftw "." (lambda (file stat flag)
(unless (<= early-1980 (stat:mtime stat))
(utime file early-1980 early-1980))
#t))
#t)))
(add-after
'unpack 'remove-h264parse-from-blacklist
(lambda _
;; Remove h264parse from gstreamer format helper blacklist. It
;; was put there to work around a bug in a pre-1.0 version of
;; gstreamer. See:
;; https://www.mozilla.org/en-US/security/advisories/mfsa2015-47/
(substitute* "dom/media/gstreamer/GStreamerFormatHelper.cpp"
(("^ \"h264parse\",\n") ""))
#t))
;; (add-after
;; 'unpack 'arrange-to-link-libxul-with-libraries-it-might-dlopen
;; (lambda _
;; ;; libxul.so dynamically opens libraries, so here we explicitly
;; ;; link them into libxul.so instead.
;; ;;
;; ;; TODO: It might be preferable to patch in absolute file names in
;; ;; calls to dlopen or PR_LoadLibrary, but that didn't seem to
;; ;; work. More investigation is needed.
;; (substitute* "toolkit/library/moz.build"
;; (("^# This needs to be last")
;; "OS_LIBS += [
;; 'GL', 'gnome-2', 'canberra', 'Xss', 'cups', 'gssapi_krb5',
;; 'gstreamer-1.0', 'gstapp-1.0', 'gstvideo-1.0' ]\n\n"))
;; #t))
(replace
'configure
;; configure does not work followed by both "SHELL=..." and
;; "CONFIG_SHELL=..."; set environment variables instead
(lambda* (#:key outputs configure-flags #:allow-other-keys)
(let* ((out (assoc-ref outputs "out"))
(bash (which "bash"))
(abs-srcdir (getcwd))
(srcdir (string-append "../" (basename abs-srcdir)))
(flags `(,(string-append "--prefix=" out)
,(string-append "--with-l10n-base="
abs-srcdir "/l10n")
,@configure-flags)))
(setenv "SHELL" bash)
(setenv "CONFIG_SHELL" bash)
(mkdir "../build")
(chdir "../build")
(format #t "build directory: ~s~%" (getcwd))
(format #t "configure flags: ~s~%" flags)
(zero? (apply system* bash
(string-append srcdir "/configure")
flags)))))
(add-before 'configure 'install-desktop-entry
(lambda* (#:key outputs #:allow-other-keys)
;; Install the '.desktop' file.
(define (swallow-%%-directives input output)
;; Interpret '%%ifdef' directives found in the '.desktop' file.
(let loop ((state 'top))
(match (read-line input 'concat)
((? eof-object?)
#t)
((? string? line)
(cond ((string-prefix? "%%ifdef" line)
(loop 'ifdef))
((string-prefix? "%%else" line)
(loop 'else))
((string-prefix? "%%endif" line)
(loop 'top))
(else
(case state
((top else)
(display line output)
(loop state))
(else
(loop state)))))))))
(let* ((out (assoc-ref outputs "out"))
(applications (string-append out "/share/applications")))
(call-with-input-file "debian/icecat.desktop.in"
(lambda (input)
(call-with-output-file "debian/icecat.desktop"
(lambda (output)
(swallow-%%-directives input output)))))
(substitute* "debian/icecat.desktop"
(("@MOZ_DISPLAY_NAME@")
"GNU IceCat")
(("^Exec=@MOZ_APP_NAME@")
(string-append "Exec=" out "/bin/icecat"))
(("@MOZ_APP_NAME@")
"icecat"))
(install-file "debian/icecat.desktop" applications)
#t))))))
(home-page "https://torproject.org")
(synopsis "The Tor Browser")
(description
"Bla.")))
--
♥Ⓐ ng0
For non-prism friendly talk find me on
psyced.org / loupsycedyglgamf.onion
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tor Browser
2016-06-30 10:29 ` Ludovic Courtès
2016-06-30 16:09 ` ng0
2016-06-30 18:00 ` ng0
@ 2016-08-05 13:35 ` ng0
2016-08-06 4:05 ` Alex Vong
2 siblings, 1 reply; 22+ messages in thread
From: ng0 @ 2016-08-05 13:35 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Ludovic Courtès <ludo@gnu.org> writes:
> ng0@we.make.ritual.n0.is skribis:
>
>> Ludovic Courtès writes:
>
> [...]
>
>>> I suppose TB contains a script that does all that, right? Would it work
>>> to simply run it? If it invokes wget/curl, then this needs to be
>>> replaced, but the rest should be fine.
>>
>> It's not that easy I'm afraid.
>> Currently they use a gitian build, as described in this README[0],
>> which the person maintaining the torbrowser ebuild for Gentoo out
>> of portage replicates and follows in parts.
>> It can't be followed completely, as `builders/tor-browser-bundle'
>> requires a checkout of gitian of the torproject.org
>>
>> So we have to look at what they do and recreate this build
>> procedure, there's no individual Makefile, the releases are
>> created in VMs.
>>
>> Dependencies are kept up to date here[1].
>>
>> This[2] is the script connecting/using gitian for gnu-linux releases.
>>
>> The Makefile just runs the corresponding scripts.
>
> Gitian is about building binaries. There must be some script somewhere
> to apply the relevant patches to the source first, before one builds it,
> no?
>
>>> It’s unfortunate that there’s no ready-to-build TB tarball, that would
>>> simplify things for us.
>>
>> Yes.. But I think icecat suffers from the same problem, only that
>> icecat tarballs/binaries are built using a bash script applying
>> all that's needed to the firefox sources again.
>
> IceCat publishes source tarballs that, AIUI, are produced essentially by
> running a script that patches Firefox’s code base (same approach for
> Linux-libre.)
>
> Thanks,
> Ludo’.
There are the .mar files, which I suppose are the built source of
torbrowser, but I can't tell for sure since i can't find an upstream for
mar-tools. I guess it is Mozilla, but where is it available?
https://dist.torproject.org/torbrowser/6.0.3/
--
♥Ⓐ ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tor Browser
2016-08-05 13:35 ` ng0
@ 2016-08-06 4:05 ` Alex Vong
2016-08-06 11:14 ` ng0
0 siblings, 1 reply; 22+ messages in thread
From: Alex Vong @ 2016-08-06 4:05 UTC (permalink / raw)
To: ng0; +Cc: guix-devel
ng0 <ng0@we.make.ritual.n0.is> writes:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> ng0@we.make.ritual.n0.is skribis:
>>
>>> Ludovic Courtès writes:
>>
>> [...]
>>
>>>> I suppose TB contains a script that does all that, right? Would it work
>>>> to simply run it? If it invokes wget/curl, then this needs to be
>>>> replaced, but the rest should be fine.
>>>
>>> It's not that easy I'm afraid.
>>> Currently they use a gitian build, as described in this README[0],
>>> which the person maintaining the torbrowser ebuild for Gentoo out
>>> of portage replicates and follows in parts.
>>> It can't be followed completely, as `builders/tor-browser-bundle'
>>> requires a checkout of gitian of the torproject.org
>>>
>>> So we have to look at what they do and recreate this build
>>> procedure, there's no individual Makefile, the releases are
>>> created in VMs.
>>>
>>> Dependencies are kept up to date here[1].
>>>
>>> This[2] is the script connecting/using gitian for gnu-linux releases.
>>>
>>> The Makefile just runs the corresponding scripts.
>>
>> Gitian is about building binaries. There must be some script somewhere
>> to apply the relevant patches to the source first, before one builds it,
>> no?
>>
>>>> It’s unfortunate that there’s no ready-to-build TB tarball, that would
>>>> simplify things for us.
>>>
>>> Yes.. But I think icecat suffers from the same problem, only that
>>> icecat tarballs/binaries are built using a bash script applying
>>> all that's needed to the firefox sources again.
>>
>> IceCat publishes source tarballs that, AIUI, are produced essentially by
>> running a script that patches Firefox’s code base (same approach for
>> Linux-libre.)
>>
>> Thanks,
>> Ludo’.
>
> There are the .mar files, which I suppose are the built source of
> torbrowser, but I can't tell for sure since i can't find an upstream for
> mar-tools. I guess it is Mozilla, but where is it available?
>
> https://dist.torproject.org/torbrowser/6.0.3/
Hi, I am a tor browser and torsocks user (since a few months ago). Last
time I tried building tor browser from source (and failed), gitian will
have to download some non-free xcode stuff to build for the os x
platform. Is it possible to only build for gnu/linux without building
for windows and os x? Will the resulting binary still be byte-to-byte
identical with the tor project official build?
Also, it seems tor browser needs virtualenv and virtualbox to
build. Last time I checked virtualbox, it was on the contrib area of
debian since it requires a non-free[1] compiler to build the bios[2].
I hope we can find way around these issues since tor browser is IMHO an
essential tool nowadays. Finally, I agree that icecat could switch to
tor browser as its upstream.
[1]: https://en.wikipedia.org/wiki/Sybase_Open_Watcom_Public_License
[2]: https://wiki.debian.org/VirtualBox
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tor Browser
2016-08-06 4:05 ` Alex Vong
@ 2016-08-06 11:14 ` ng0
2016-08-08 8:03 ` Alex Vong
0 siblings, 1 reply; 22+ messages in thread
From: ng0 @ 2016-08-06 11:14 UTC (permalink / raw)
To: guix-devel
Hi,
in the following reply I assume that you did not read all of the
original thread[0]. If I am wrong, correct me.
Alex Vong <alexvong1995@gmail.com> writes:
> ng0 <ng0@we.make.ritual.n0.is> writes:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> ng0@we.make.ritual.n0.is skribis:
>>>
>>>> Ludovic Courtès writes:
>>>
>>> [...]
>>>
>>>>> I suppose TB contains a script that does all that, right? Would it work
>>>>> to simply run it? If it invokes wget/curl, then this needs to be
>>>>> replaced, but the rest should be fine.
>>>>
>>>> It's not that easy I'm afraid.
>>>> Currently they use a gitian build, as described in this README[0],
>>>> which the person maintaining the torbrowser ebuild for Gentoo out
>>>> of portage replicates and follows in parts.
>>>> It can't be followed completely, as `builders/tor-browser-bundle'
>>>> requires a checkout of gitian of the torproject.org
>>>>
>>>> So we have to look at what they do and recreate this build
>>>> procedure, there's no individual Makefile, the releases are
>>>> created in VMs.
>>>>
>>>> Dependencies are kept up to date here[1].
>>>>
>>>> This[2] is the script connecting/using gitian for gnu-linux releases.
>>>>
>>>> The Makefile just runs the corresponding scripts.
>>>
>>> Gitian is about building binaries. There must be some script somewhere
>>> to apply the relevant patches to the source first, before one builds it,
>>> no?
>>>
>>>>> It’s unfortunate that there’s no ready-to-build TB tarball, that would
>>>>> simplify things for us.
>>>>
>>>> Yes.. But I think icecat suffers from the same problem, only that
>>>> icecat tarballs/binaries are built using a bash script applying
>>>> all that's needed to the firefox sources again.
>>>
>>> IceCat publishes source tarballs that, AIUI, are produced essentially by
>>> running a script that patches Firefox’s code base (same approach for
>>> Linux-libre.)
>>>
>>> Thanks,
>>> Ludo’.
>>
>> There are the .mar files, which I suppose are the built source of
>> torbrowser, but I can't tell for sure since i can't find an upstream for
>> mar-tools. I guess it is Mozilla, but where is it available?
>>
>> https://dist.torproject.org/torbrowser/6.0.3/
>
> Hi, I am a tor browser and torsocks user (since a few months ago). Last
> time I tried building tor browser from source (and failed), gitian will
> have to download some non-free xcode stuff to build for the os x
> platform. Is it possible to only build for gnu/linux without building
> for windows and os x? Will the resulting binary still be byte-to-byte
> identical with the tor project official build?
Was this a build with a guix package? Can you share the code if it is?
> Also, it seems tor browser needs virtualenv and virtualbox to
> build. Last time I checked virtualbox, it was on the contrib area of
> debian since it requires a non-free[1] compiler to build the bios[2].
> I hope we can find way around these issues since tor browser is IMHO an
> essential tool nowadays.
You might want to re-read the full thread this message is part of. I
already wrote that with the builds I use for torbrowser in Gentoo, that
at least virtualbox is not needed and Ludovic said that the gitian build
is not what we should be looking into. It is mostly poncho's work on
Gentoo, but the overlay I contribute to mirrors their work. There we
don't use gitian but a combination of torbrowser source + firefox source
and distro specific patches.
We could also address tor with this when we succeed, as they have an
interest in NixOS or they are looking into it, specifically hydra for
builds: https://trac.torproject.org/projects/tor/ticket/12520
> Finally, I agree that icecat could switch to tor browser as its upstream.
Maybe you want to help me out with writing the email / post to
torproject:
https://lists.gnu.org/archive/html/guix-devel/2016-08/msg00326.html
On second note, maybe this is message should be addressed to both
torproject and icecat developer(s). What do you think? I have no fixed
plan in mind for this.
[0]: https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=torbrowser&submit=Search&idxname=guix-devel
>
> [1]: https://en.wikipedia.org/wiki/Sybase_Open_Watcom_Public_License
> [2]: https://wiki.debian.org/VirtualBox
--
♥Ⓐ ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tor Browser
2016-08-06 11:14 ` ng0
@ 2016-08-08 8:03 ` Alex Vong
2016-08-10 20:01 ` Mark H Weaver
0 siblings, 1 reply; 22+ messages in thread
From: Alex Vong @ 2016-08-08 8:03 UTC (permalink / raw)
To: ng0; +Cc: guix-devel
Hello,
ng0 <ng0@we.make.ritual.n0.is> writes:
> Hi,
>
> in the following reply I assume that you did not read all of the
> original thread[0]. If I am wrong, correct me.
>
You are right, I didn't read the whole thread.
> Alex Vong <alexvong1995@gmail.com> writes:
>
>> ng0 <ng0@we.make.ritual.n0.is> writes:
>>
>>> Ludovic Courtès <ludo@gnu.org> writes:
>>>
>>>> ng0@we.make.ritual.n0.is skribis:
>>>>
>>>>> Ludovic Courtès writes:
>>>>
>>>> [...]
>>>>
>>>>>> I suppose TB contains a script that does all that, right? Would it work
>>>>>> to simply run it? If it invokes wget/curl, then this needs to be
>>>>>> replaced, but the rest should be fine.
>>>>>
>>>>> It's not that easy I'm afraid.
>>>>> Currently they use a gitian build, as described in this README[0],
>>>>> which the person maintaining the torbrowser ebuild for Gentoo out
>>>>> of portage replicates and follows in parts.
>>>>> It can't be followed completely, as `builders/tor-browser-bundle'
>>>>> requires a checkout of gitian of the torproject.org
>>>>>
>>>>> So we have to look at what they do and recreate this build
>>>>> procedure, there's no individual Makefile, the releases are
>>>>> created in VMs.
>>>>>
>>>>> Dependencies are kept up to date here[1].
>>>>>
>>>>> This[2] is the script connecting/using gitian for gnu-linux releases.
>>>>>
>>>>> The Makefile just runs the corresponding scripts.
>>>>
>>>> Gitian is about building binaries. There must be some script somewhere
>>>> to apply the relevant patches to the source first, before one builds it,
>>>> no?
>>>>
>>>>>> It’s unfortunate that there’s no ready-to-build TB tarball, that would
>>>>>> simplify things for us.
>>>>>
>>>>> Yes.. But I think icecat suffers from the same problem, only that
>>>>> icecat tarballs/binaries are built using a bash script applying
>>>>> all that's needed to the firefox sources again.
>>>>
>>>> IceCat publishes source tarballs that, AIUI, are produced essentially by
>>>> running a script that patches Firefox’s code base (same approach for
>>>> Linux-libre.)
>>>>
>>>> Thanks,
>>>> Ludo’.
>>>
>>> There are the .mar files, which I suppose are the built source of
>>> torbrowser, but I can't tell for sure since i can't find an upstream for
>>> mar-tools. I guess it is Mozilla, but where is it available?
>>>
>>> https://dist.torproject.org/torbrowser/6.0.3/
>>
>> Hi, I am a tor browser and torsocks user (since a few months ago). Last
>> time I tried building tor browser from source (and failed), gitian will
>> have to download some non-free xcode stuff to build for the os x
>> platform. Is it possible to only build for gnu/linux without building
>> for windows and os x? Will the resulting binary still be byte-to-byte
>> identical with the tor project official build?
>
> Was this a build with a guix package? Can you share the code if it is?
>
I was trying to reproduce the official build. I didn't write any guix
recipe.
>> Also, it seems tor browser needs virtualenv and virtualbox to
>> build. Last time I checked virtualbox, it was on the contrib area of
>> debian since it requires a non-free[1] compiler to build the bios[2].
>> I hope we can find way around these issues since tor browser is IMHO an
>> essential tool nowadays.
>
> You might want to re-read the full thread this message is part of. I
> already wrote that with the builds I use for torbrowser in Gentoo, that
> at least virtualbox is not needed and Ludovic said that the gitian build
> is not what we should be looking into. It is mostly poncho's work on
> Gentoo, but the overlay I contribute to mirrors their work. There we
> don't use gitian but a combination of torbrowser source + firefox source
> and distro specific patches.
>
I see. So poncho and you have already done the hard work :)
>
> We could also address tor with this when we succeed, as they have an
> interest in NixOS or they are looking into it, specifically hydra for
> builds: https://trac.torproject.org/projects/tor/ticket/12520
>
>> Finally, I agree that icecat could switch to tor browser as its upstream.
>
> Maybe you want to help me out with writing the email / post to
> torproject:
> https://lists.gnu.org/archive/html/guix-devel/2016-08/msg00326.html
>
> On second note, maybe this is message should be addressed to both
> torproject and icecat developer(s). What do you think? I have no fixed
> plan in mind for this.
>
Hmm, maybe I will give my (rough) idea here. In my opinion, icecat has 2
important features, librejs (gpl3+) and the lack of non-free addons
suggestion.
For librejs, TBB already have noscripts, although they serve different
purposes (librejs intends to block non-free js only), I doubt devs would
want to include 2 js blocker addons. But I think html5 everyhere will be
a good addon for TBB since most html5 player requires js. Currently,
enabling noscript breaks most video-playing sites.
For the lack of non-free addons suggestion, TBB recommends not to
install addon, but the addon page is still there, which suggest non-free
addons. I don't really know what should we do here. Perhaps we could
turn off the suggestion by default and warned user about the existence
of non-free addons? We could also provide a replacement page (like
icecat).
For other addons, I think https everywhere is already in TBB and
spyblock looks like haven't been update for long time, so they don't
need to be add to TBB.
Finally, do you know what is the current state of the firefox trademark
issue? Some say it is fixed. (Debian switched back to firefox next
release)
What is your idea?
> [0]:
> https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=torbrowser&submit=Search&idxname=guix-devel
>>
>> [1]: https://en.wikipedia.org/wiki/Sybase_Open_Watcom_Public_License
>> [2]: https://wiki.debian.org/VirtualBox
Cheers,
Alex
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tor Browser
2016-08-08 8:03 ` Alex Vong
@ 2016-08-10 20:01 ` Mark H Weaver
2016-08-11 8:51 ` ng0
0 siblings, 1 reply; 22+ messages in thread
From: Mark H Weaver @ 2016-08-10 20:01 UTC (permalink / raw)
To: Alex Vong; +Cc: guix-devel
Alex Vong <alexvong1995@gmail.com> writes:
> ng0 <ng0@we.make.ritual.n0.is> writes:
>
>> Alex Vong <alexvong1995@gmail.com> writes:
>>
>>> Finally, I agree that icecat could switch to tor browser as its upstream.
>>
>> Maybe you want to help me out with writing the email / post to
>> torproject:
>> https://lists.gnu.org/archive/html/guix-devel/2016-08/msg00326.html
>>
>> On second note, maybe this is message should be addressed to both
>> torproject and icecat developer(s). What do you think? I have no fixed
>> plan in mind for this.
>>
> Hmm, maybe I will give my (rough) idea here. In my opinion, icecat has 2
> important features, librejs (gpl3+) and the lack of non-free addons
> suggestion.
We would also need to remove Firefox support for DRM (e.g. EME), avoid
steering users to non-free media codecs, and maybe some other things to
meet the requirements of the GNU FSDG.
I suspect that these changes are substantial enough that we'll need to
change the branding, and avoid using the Firefox trademark, but I'm not
sure.
> For librejs, TBB already have noscripts, although they serve different
> purposes (librejs intends to block non-free js only), I doubt devs would
> want to include 2 js blocker addons. But I think html5 everyhere will be
> a good addon for TBB since most html5 player requires js. Currently,
> enabling noscript breaks most video-playing sites.
>
> For the lack of non-free addons suggestion, TBB recommends not to
> install addon, but the addon page is still there, which suggest non-free
> addons. I don't really know what should we do here.
The IceCat project maintains a page of free addons. I guess we should
use that.
I agree that the best outcome would be for IceCat to switch to Tor
Browser as its upstream, or at least to borrow heavily from their patch
set.
Thanks,
Mark
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tor Browser
2016-08-10 20:01 ` Mark H Weaver
@ 2016-08-11 8:51 ` ng0
0 siblings, 0 replies; 22+ messages in thread
From: ng0 @ 2016-08-11 8:51 UTC (permalink / raw)
To: Mark H Weaver, Alex Vong; +Cc: guix-devel
Hi,
Mark H Weaver <mhw@netris.org> writes:
> Alex Vong <alexvong1995@gmail.com> writes:
>
>> ng0 <ng0@we.make.ritual.n0.is> writes:
>>
>>> Alex Vong <alexvong1995@gmail.com> writes:
>>>
>>>> Finally, I agree that icecat could switch to tor browser as its upstream.
>>>
>>> Maybe you want to help me out with writing the email / post to
>>> torproject:
>>> https://lists.gnu.org/archive/html/guix-devel/2016-08/msg00326.html
>>>
>>> On second note, maybe this is message should be addressed to both
>>> torproject and icecat developer(s). What do you think? I have no fixed
>>> plan in mind for this.
>>>
>> Hmm, maybe I will give my (rough) idea here. In my opinion, icecat has 2
>> important features, librejs (gpl3+) and the lack of non-free addons
>> suggestion.
>
> We would also need to remove Firefox support for DRM (e.g. EME), avoid
> steering users to non-free media codecs, and maybe some other things to
> meet the requirements of the GNU FSDG.
>
> I suspect that these changes are substantial enough that we'll need to
> change the branding, and avoid using the Firefox trademark, but I'm not
> sure.
I think there's a need to change the branding. Gentoo ships a firefox
with a huge patchset applied and uses a branding with some changes
(Aurora). I'd like to get the icecat developer involved in the
discussion at some point, to get additional input and find out where
help is needed.
I think the same idea like for many projects applies for Icecat: when
you get involved, bugfixing is faster. Icecat has the bug of being based
on an insecure firefox version - let's help to move it somewhere safe.
>> For librejs, TBB already have noscripts, although they serve different
>> purposes (librejs intends to block non-free js only), I doubt devs would
>> want to include 2 js blocker addons. But I think html5 everyhere will be
>> a good addon for TBB since most html5 player requires js. Currently,
>> enabling noscript breaks most video-playing sites.
>>
>> For the lack of non-free addons suggestion, TBB recommends not to
>> install addon, but the addon page is still there, which suggest non-free
>> addons. I don't really know what should we do here.
>
> The IceCat project maintains a page of free addons. I guess we should
> use that.
With our gentoo overlay, we started to include addons to be installed
from outside the mozilla addon store, as the gentoo firefox is
configured to have a system controlled addon location.
Now starting with FF 48, addons will only be able to be installed from
the official FF store, but I think this setting can be turned off
hopefully.
We (ybti overlay) discussed a similar approach for Guix, to configure
firefox based browsers (and others) to additionally use addons from
Guix, to allow more control of what's included etc.
> I agree that the best outcome would be for IceCat to switch to Tor
> Browser as its upstream,
Agreed, but...
> or at least to borrow heavily from their patch
> set.
>
...maybe that is not completely necessary, the bugtracker link of firefox
which I was passed recently shows that firefox and torbrowser want to
upstream the patchset of torbrowser.
> Thanks,
> Mark
--
♥Ⓐ ng0
For non-prism friendly talk find me on http://www.psyced.org
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2016-08-11 8:51 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-23 10:41 patches question ng0
2016-06-23 11:09 ` Andreas Enge
2016-06-23 11:30 ` ng0
2016-06-23 20:14 ` Andreas Enge
2016-06-23 22:18 ` ng0
2016-06-23 13:23 ` ng0
2016-06-23 20:27 ` Andreas Enge
2016-06-24 12:09 ` Ludovic Courtès
2016-06-24 13:43 ` ng0
2016-06-24 15:48 ` Tor Browser Ludovic Courtès
2016-06-24 17:49 ` ng0
2016-06-26 10:05 ` Ludovic Courtès
2016-06-29 12:48 ` ng0
2016-06-30 10:29 ` Ludovic Courtès
2016-06-30 16:09 ` ng0
2016-06-30 18:00 ` ng0
2016-08-05 13:35 ` ng0
2016-08-06 4:05 ` Alex Vong
2016-08-06 11:14 ` ng0
2016-08-08 8:03 ` Alex Vong
2016-08-10 20:01 ` Mark H Weaver
2016-08-11 8:51 ` ng0
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).