In T595#12043, @sean.obrien wrote:

the recommendation was unofficial and I'd rather not push on it...

why enabling the compatibility mode, as it seems like we do for PureBrowser by default, doesn't fix the problem is a mystery to me.

@jonas.smedegaard the recommendation was unofficial and I'd rather not push on it... could end up with policy that isn't in our interest. Waterfox uses the same style of UA string, and they have compatibility with the addons store.

Seems directly tied to Laniakea: Assigning to @mak

@sean.obrien Is the conversation with Mozilla, leading to their suggesting that particular string, public? If so, please provide URL.

@mladen.pejakovic My point is that "Compatibility mode" is something specific in the context of Firefox.

Confusingly that page talks about "compatibility mode" which is *not* what it is about: Compatibility mode is already enabled.

A known workaround is to configure PureBrowser to impersonate Firefox: https://tracker.pureos.net/w/troubleshooting/firefox_compat_mode/

Is there a workaround until an update is sent out?

@kyle.rankin Do you recall more detailed how/where the Tails website broke? Is it still the case?

I can't reproduce this.

What is the error message you're getting from update-initramfs?

For reference, this is the JS library that the Mozilla addons team uses to figure out the UA: https://github.com/faisalman/ua-parser-js/

@jonas.smedegaard clarification - I visited addons.mozilla.org in a new browser tab after making that UA change, and was able to install addons that would fail with the previous UA string. I assume the UA override in about:config does *not* fix the problem for the browser as a whole, which is why browsing through the "addons manager" still barks at you for not running a compatible browser.

@sean.obrien Can you please elaborate what more exactly you tested when you wrote "I've tested, and it works".

I did some more testing, and for the sake of accuracy, this is a slightly better UA string:

We need to change the PureBrowser user agent string format to be compatible with the Firefox addons site. After discussions with Mozilla, this is the format of the string we need to send:

This issue is bogus - even if package is reintroduced into PureOS: libxnvctrl does _not_ need nor promote non-free software (see T64).

This issue is bogus: libxnvctrl does _not_ need nor promote free software (see T64).

This issue is bogus: libxnvctrl does _not_ need nor promote free software (see T64).

This issue is bogus: libxnvctrl does _not_ need nor promote free software (see T64).

This issue is bogus: libxnvctrl does _not_ need nor promote free software (see T64).

I have come to same conclusion as you, @mak, that this is no Freedom issue, and too painful without any real gain to try solve.

https://salsa.debian.org/qa/jenkins.debian.net/merge_requests/24 merged

That's your call.

I think making a flatpak and hosting that flatpak is an acceptable approach. This is why;

I see several approaches:

It feels like there is a decision to be made here: are we going to invest time and resources in PureOS components when they are not in Debian yet? My feeling from the team is that the answer is an emphatic "yes."

I've put initial packaging here https://source.puri.sm/Librem5/mfgtools/tree/pureos/purple .
RFP for Debian is . I'm happy to maintain this in Debian if someone from the PureOS team joins me.

It's more tied to the fact that PureOS does not support UEFI in any way.
We should add support for it, but as of now this task is kind of low priority.

Requested debian weekly live images here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916687 (as my primary use case is to test laptopsfor h-node.org and debian live images support UEFI)

Seems directly tied to bootstrapping tools in the hands of Matthias.

Just for reference: https://source.puri.sm/Librem5/librem5-devkit-tools - it will gain a librem5-devkit-host part with the next MR.

T440 is related but they had an option to disable UEFI.

Did the following as per instructed and it fixed the issue:

Thank you David. I'm going to take the C as a passing grade and close this tracker item concluding that Gitlab CE is sufficiently free for our purposes.

Note that FSF give GitLab a C-grade "Acceptable hosting for a GNU package", noting "All JavaScript code served to the client is free, but does not work with LibreJS enabled."

https://lists.gnu.org/archive/html/libreplanet-discuss/2015-03/msg00095.html

More discussion on this topic upstream: https://gitlab.com/gitlab-org/gitlab-ce/issues/51287
NB: This thread ^^ is about Gitlab Community Edition.

As of this comment, we are at 84.5%. However:

When I first suggested this in the other issue, these addons were just suggestions, not a "must have" list.

I think you're right Jonas. I'll set up a tracker per add-on.