[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

From: Marius Bakke
Subject: Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.
Date: Thu, 21 Feb 2019 08:49:47 +0100
User-agent: Notmuch/0.28.2 ( Emacs/26.1 (x86_64-pc-linux-gnu)

Luke <address@hidden> writes:

> On 02/20/2019 05:10 PM, Marius Bakke wrote:
>> bill-auger <address@hidden> writes:
>>> On Wed, 20 Feb 2019 15:50:02 +0100 Marius wrote:
>>>> That message says we are no longer using a _fork_ of
>>>> Ungoogled-Chromium. Earlier revisions of the patch was pulling from
>>>> my repository[0], now we use the canonical upstream repository
>>>> directly:
>>> but then what do you do to the upstream sources? - we all agree the
>>> upstream sources are not FSDG-free - arent the ungoogled patches the
>>> keystone of your liberation procedure?
>> The liberation procedure is right there in the package definition:
>> <>.
>> This script is what creates the FSDG-free source tarball presented to
>> users when they run `guix build --source ungoogled-chromium`.
>>> that is entirely why i am confused now - it would help tremendously if
>>> you could tell us what you did to the upstream sources that you believe
>>> makes the FSDG-free - like a liberation recipe in plain english would
>>> be awseome
>> There are comments in the script.  Please ask if any of the steps are
>> unclear!  Improvements welcome.
> Correct me if I'm wrong, but Widevine DRM and the ability to run
> proprietary codecs is still being built according to the provided
> package source?
> That's definitely a blocker.

Widevine is *not* built.  The ability to run proprietary codecs is
provided by the system "ffmpeg" library, thus it makes no sense for
Chromium to place additional restrictions on top of that.

> Some GN prefs missing from chromium.scm:
> ---
> ;; Disable non-free codecs
> "proprietary_codecs=false"
> ;; Disable DRM
> "enable_widevine=false"

I explicitly disabled Widevine in this commit to prevent further

> ;; Not XMPP compliant, walled-garden SaaSS:
> "enable_hangout_services_extension=false"

This option is disabled by default and (I believe) deprecated.

> ;; Note:
> "use_openh264=false"
> "rtc_use_h264=false"

I'm not an expert, so I'll defer judgement on this topic to someone more
knowledgeable.  My understanding is that the OpenH264 library in use is
sufficiently free.  Is that incorrect?

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]