@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.

@heather.ellsworth I took the liberty of retitling "your" issue here to describe the issue to be addressed.

Fixed upstream in Debian (see T599).

In T202#11747, @jeremiah.foster wrote:

I wonder if we want to have an acceptance criteria for this issue since while it is "closed" it is not "solved" perhaps.

This is T202 - merging into this newer one (instead of opposite) because this one had more details - except for the exact "error message" of the wording of the button when (mis)detected as not being _exactly_ Firefox.

I can suggest to create an issue for each addon, both to track their relationsips (e.g. if an addon like TOS;DR relates to _both_ privacy and freedom), and to track their resolution (i.e. packaging in Debian).

I suspect (but haven't looked closed) that some of the listed addons more appropriately belong in a new separate issue "PureOS is not freedom-governing enough by default".

I took the liberty of changing the title to describe the issue to be addressed here.

In T595#11754, @jeremiah.foster wrote:

Thank you @mladen.pejakovic. From what I can see, this essentially solves the issue no? I think we should close this issue.

Ah, thanks for the clarification. Makes sense to me now :-)