Re: wip/cliqz: Request for review

[Santhosh Raju <santhosh.raju%gmail.com@localhost>]

On Sat, Apr 13, 2019 at 12:11 PM Greg Troxel <gdt%lexort.com@localhost> wrote:
>
> Santhosh Raju <santhosh.raju%gmail.com@localhost> writes:
>
> > If possible, I would like to import the package from pkgsrc-wip to
> > pkgsrc-current.
> >
> > The only thing I have not been able to test out is trying to build and
> > run the package in NetBSD/i386, so not sure if I should somehow mark
> > this package is not tested for that platform. Suggestions on this are
> > welcome.
>
> Did you test it on every other combination of OS and CPU?  I am really
> glad to hear that it's ok on NetBSD/sun2 5_STABLE!  (That's a joke...)
>

:-)

> But seriously, we do not require testing everywhere, especially for new
> packages.  I am guessing it builds on NetBD/amd64, and if so that's
> great.   We mark packages as BROKEN if they ought to build but do not,
> and as NOT_FOR if there is a documented good reason why they aren't
> appopriate for a platform (e.g., upstream says "this only works on X",
> when that actually makes sense).  We do not generally keep notes about
> where things have been tested in the package; once in pkgsrc, then next
> branch, there will be bulk builds, and you can see where it built and
> where it doesn't.  Or where rust didn't build and so this was never
> tried.
>

Understood, in that case it can wait till then. And then if need be I
can mark the package as BROKEN for i386 or apply fixes. I know it does
build on i386, just that I have no way to test / build it out.

It does build and work on NetBSD/amd64, I have tried out various
builds in my VirtualBox instance.

> > I would like to do this by tomorrow if there are no comments on it.
>
> I didn't want to try to build it as my NetBSD/i386 package test box is
> slow and old (a 2006-era laptop).  The only things that jumped out at me
> were:
>
>   pkglint passes, which is good.
>
>   It has a fixed requirement on clang, rather than just some c++
>   version.  If that is really the way it is and documented to be that
>   way by upstream, that's 100% fine.  But if it's not documented
>   upstream, then an upstream bug is probably appropriate and certainly a
>   comment about why.
>

The cliqz project basically uses Firefox and since there was a recent
shift in Firefox building using clang everywhere, I guess the change
applies here too. I believe this is probably why you see the fixed
requirement on clang.

>   The DESCR talks about "proprietary" things, but then I see the license
>   is mpl.  Perhaps that's taken from upstream, but it would be good to
>   reword if they really just mean "cliqz has filtering/saftey features
>   not found in other browsers".   If there is an aspect of this which is
>   not really open source, then then license tag needs adjusting.

The "proprietary" thing here is the extension developed by Cliqz and
used by Cliqz browser, this extension basically gets baked into their
browser build and is part of the distfile. The browser and the source
is open since it follows basically Firefox upstream hence the mpl
license. Which is why the wording has been put like that by the makers
of the browser.

So yes, there is an aspect of it which is not really open source, Any
advice on how to proceed with the license tag here?

Regards
Santhosh