Yeah, unfortunately the Librems are very often shipped with old software, Polywell didn't stay up-to-date with new releases. But issues like we had recently with the OEM setup of course also don't help with these issues.

This is not so surprising for a 'dist-upgrade'. I don't know if you want to do the dist-upgrade or not, perhaps you need those important packages and don't want them removed, but if you like you can try just doing a regular apt upgrade that will not be as invasive.

Cool. I have another Librem that was sent to me for testing, I'm going to look for this too on that one. I worry that some of the machines may be shipping with older software.

Hmm yeah, then the PureOS version installed on that machine is likely very old.
In any case, after you update your system the issue will go away completely.

This appeared on a laptop that was shipped to me this week. I'll check the vintage of the software.

This is a task on my list, but it will take a lot of work and time to resolve properly. Dak isn't really designed for this, so some changes will be needed (just a normal dinstall run currently takes more than an hour alone).

I think this is an ancient bug - did you try a very old installation image of PureOS?

apt dist-upgrade

This weather is far more of for smokey bourbon...

ACCEPTED in Debian.

Can you share the command you used? Also, what is in your /etc/apt/sources.list (or /etc/apt/sources.list.d/* ?

Now just lean back and drink gin&tonic for a few weeks while Debian and Laniakea processes it to PureOS green :-D

Accepted in Debian. (Grr at your insistence of License-Grant! j/k)

Package is libhostfile-manager-perl tracked in Debian as bug#916437.

@chris.lamb: Please have a look at the Debian package now in NEW queue, and approve if acceptable.

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.