GNU bug report logs - #28004
Chromium

Previous Next

Full log

Message #14 received at 28004 <at> debbugs.gnu.org (full text, mbox):

From: ng0 <ng0 <at> infotropique.org>
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: 28004 <at> debbugs.gnu.org, ng0 <ng0 <at> infotropique.org>
Subject: Re: [bug#28004] Chromium
Date: Tue, 8 Aug 2017 05:53:29 +0000

[Message part 1 (text/plain, inline)]

Marius Bakke transcribed 2.4K bytes:
> ng0 <ng0 <at> infotropique.org> writes:
> 
> > Hi Marius,
> >
> > Marius Bakke transcribed 43K bytes:
> >> Hello Guix!
> >> 
> >> Attached is a patch for Chromium, a popular web browser.
> >
> > Nice! I've been using this from your branch for a while now,
> > works just fine :)
> > Is this not affected by the chromium discussion which happened
> > a while back? Can we include this? I'm all for this, because I
> > mainly use it for websites where firefox/icecat doesn't work so
> > well, and building it locally takes a very long time.
> 
> I believe this is within the Free System Distribution Guidelines.

What I meant was this long discussion about "QTWebengine is nonfree",
but as far as I experienced in being one of the early users of chromium
for a long time, it doesn't depend on anything Qt and doesn't bundle it.
So without having the time this morning to refresh the discussion, I think
it was about Chromium as a part for other software which is provided
through QtWebengine (Or maybe I'm tired and write only almost nonsense).

> DRM
> ("Widevine") is disabled at build time, and the Web Store is
> non-functional without the end user explicitly enabling it.
> 
> There are some grey areas though. The browser may interact with certain
> non-free APIs (apart from regular browser duties) such as translation or
> prediction services. These features are optional, but some are enabled
> by default, and difficult to maintain patches for (I've tried).
> 
> However, I have verified that it does not send any unsolicited requests
> with the current command-line options, apart from the very first launch
> which spawns a login prompt (help wanted!). Without either of those
> flags the browser "calls home" every time it starts.
> 
> >> Note that I cannot guarantee timely delivery of security updates. Major
> >> version upgrades are hugely painful, and almost always contain many
> >> high-severity fixes. Should we mention that in the description?
> >> 
> >> Happy for any feedback.
> >> 
> >
> > Shouldn't you mention defines in addition to the define-public aswell,
> > or don't we do that?
> 
> Not for new files (modules), typically. I don't think Magit can fill out
> those variable names (by pressing C on the hunks) either ;-) But it
> should probably go in web-browsers.scm anyway.

Isn't web-browsers just for smaller browsers? we have gnuzilla, and I'm
about to add palemoon when I have analysed and cleaned up my build of it.

Of course we coukd add them all to web-browser, the file won't become too large.
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.