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