Re: QMake equivalent of CMake flag -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir}

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

 



Il 11/03/2018 01:56, Kevin Kofler ha scritto:
> The upstream makefile hardcodes /usr/lib here:
> https://github.com/open-eid/chrome-token-signing/blob/master/host-linux/chrome-token-signing.pro#L22
> The easiest fix is probably to just change:
> ffconf.path = /usr/lib/mozilla/native-messaging-hosts
> to:
> ffconf.path = $$LIBDIR/mozilla/native-messaging-hosts
> with a patch and pass LIBDIR=%{_libdir} on the command line (in the
> specfile, along with all the other command line arguments you are passing).

Thank you, I will proceed in such way
** UPDATE ** I let upstream read your message and I think the following
pull request has been made based on your suggestions
https://github.com/open-eid/chrome-token-signing/pull/100

> But I see a bigger issue here: THIS PACKAGE BUNDLES A PREBUILT BINARY XPI
> with the Firefox extension
> (https://github.com/open-eid/chrome-token-signing/blob/master/%7B443830f0-1fff-4f9a-aa1e-444bafbc7319%7D.xpi).
> This is NOT allowed in Fedora and should never have passed review. The
> package should instead rebuild the XPI from source. It will not be signed,
> but the Fedora Firefox accepts unsigned extensions if they are installed in
> system-wide directories.

Ok I will compile the extension from sources.

> By the way, Fedora ships the chromium browser which should be able to load
> the Chrome extension. You may have to change /etc/opt/chrome to
> /etc/chromium in hostconf.path, not sure whether Chromium checks both. And
> then there is that /opt/google/chrome/ckjefchnfjhjfedoccjbhjpbncimppeg.json
> that is apparently setting up auto-downloading the prebuilt extension from
> upstream (or really, from Google's store). (Just like the Firefox one, it is
> NOT built with the source code.) This file is NOT shippable as is, also
> because:
> 1. Fedora packages MUST NOT install to /opt. I am not sure what the correct
>    directory actually is for Chromium, and
> 2. that file sets up auto-updating the extension from upstream. But we do
>    NOT want to have packaged extensions updated directly from upstream.
> But
> 1. https://github.com/open-eid/chrome-token-signing/blob/master/host-linux/ee.ria.esteid.json
>    references that ckjefchnfjhjfedoccjbhjpbncimppeg extension as the only
>    allowed origin, so that would need updating too if the ID changes.
> 2. I have no idea in what paths Chromium looks for systemwide extensions. If
>    it's only /opt, we are stuck and need Chromium patched first.
> 3. Last I checked, Chromium did not require signed extensions (only Chrome
>    did, and only on some platforms), but this may have changed, in which
>    case Chromium would have to be patched, too.

Once I the work on the extension will be finished, if I will have some
free time I will try patching the package to work on Chromium too

> PS: I see one similar package in Fedora:
> https://src.fedoraproject.org/cgit/rpms/chrome-gnome-shell.git/tree/chrome-gnome-shell.spec
> but they chickened out of shipping the browser extensions entirely and ship
> only the native-messaging-host part. So you have to install the package AND
> install the extension from the browser's extension installation mechanism.
>
> This would be a solution if you cannot package the extensions in a way
> compliant with Fedora policies, but it is not very user-friendly.

I don't know if such approach would work on Firefox. For example, the
most important part of chrome-token-signing package is the JSON file and
I have been told that purpose of the extension is only to let Firefox
use the related JSON file. In a few words, you can't have such kind JSON
file without a related extension.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux