Thanks for the suggestion.

This was addressed in Debian today with the release of kodi 2:17.6+dfsg1-2.
Consequently should likely reach PureOS in ~1 month.

This is not really a duplicate of T255, but rather an issue concretely actionable since it is isolated to a specific package, whereas T255 is a meta-issue tracking the broader concept.

The issue remains. I'm informed of this "unable to install" issue everytime I open Software.

If you go to the hamburger menu and then add ons, you'll see the attached picture. In the past this was directed to a FSF add on page. After loading up the most recent build on a test machine without Firefox installed, the normal Firefox add-ons page is shown within PureBrowser. So the original issue remains despite my being incorrect as to the cause.

This should be addressed in the latest images, I am not sure though if the solution covers all cases (I could only do limited testing).
So, please reopen the issue in case this happens again!

That's a weird one... Can you still reproduce the issue? Can you verify that the "packagekit" package is installed?

What exactly does "issues" mean? What did you try, what did you expect and what was the actual result and error message?

Likely some GNOME weirdness. Needs to be investigated, the image sets should be identical.

Calamares should never even show up in the software center. I marked it's .desktop files to be ignored from inclusion in the software catalog now (effective as of calamares >= 3.2~rc4-0pureos5)
Thanks for noticing!

Keysafe is packaged for Debian - but only targeted experimental: https://tracker.debian.org/pkg/keysafe

We might want to also include Symbola (fonts-symbola) which in my experience fills the gaps on more obscure and newer emoji (and other bits of Unicode). It seems Symbola is not that great for emoji, so I withdraw this suggestion. Still good for ancient fonts, but I'm not sure those will see everyday use :D

Part of the solution may involve backing up (not syncing) your own GPG key, which could be achieved with something like Keysafe

ok. Please in future use chat for guidance - or the user support forum, perhaps - as issue tracker is better suited to track issues (bugs and pseudo-bugs like wishlist requests) tied to components of the Operating system.

Perhaps I should have been clearer, this was just a query about *how* to check that my second disk is encrypted. You have answered my query so I closed the ticket :)

I am confused: Did that actually fix the reported issue?

Seems an issue for @mak.

Seems an issue for @mak.

Seems an issue for @mak.

Seems an issue for @mak.

Seems an issue for @mak.

Seems an issue for @mak.

Seems an issue for @mak.

Thanks! lsblk results:

Please consider filing an RFP bug in Debian - and then reference the resulting bugnumber here: https://www.debian.org/Bugs/Reporting

Please consider filing an RFP bug in Debian - and then reference the resulting bugnumber here: https://www.debian.org/Bugs/Reporting

One way to inspect what is on encrypted volumes is typing lsblk in a terminal - volumes in branches off of a *_crypt entry is encrypted.

Perhaps you typed "255" in the popup dialog, where it expects "T255"?

At best, this is low priority.

Hmmm, this should be closed as a duplicate of https://tracker.pureos.net/T255 but I can't bring it up :P

See also https://tracker.pureos.net/T398

As far as I'm aware MPRIS is DE-independent, and music players that implement MPRIS also implement minimise-on-close behavior (citation needed). I've made a list of music players for comparison (arbitrary selection based on *I've heard that name in forums so I believe it's "popular"*), and I'll also query QL upstream. (All this as time allows.)

Thanks for reporting!

Technically harmless - data reporting is disabled so only a rogue obsolete message tied with our rename from Mozilla to Purism (as per Mozilla trademark guidelines) - but bad user experience nevertheless.

@jonas.smedegaard the Librem 15 v3 has a TN screen (instead of ISP) so it is not really good for graphics and I do my work on the Librem 13 instead.

Yeah, for us it is a change needed for consistency and ease of development, but for our users it doesn't matter at all and thereby is more of a cosmetic change (I should have been clearer on what I meant ^^).

Thanks, although I mildly disagree that it's just cosmetic change given that it requires separate access with yet another set of credentials and ACL to maintain etc. etc etc.

Ok, in that case I claim this task again - this is really not blocking anything at all, in a way it's more a cosmetic/consistency change. I had it on my todo list anyway, so having this bug makes sense.

In T387#7065, @mak wrote:

@todd Why did you reassign the task?

In T393#7101, @jonas.smedegaard wrote:

@todd: Can Purism pay for a ColorHug2 for me? It is an Open Source Hardware (OSHW) certified device using Free drivers. It costs 95 british pounds.

ColorHug2 ordered - should be shipped tomorrow (from UK to Denmark, so if lucky arrives this week).

thanks for the input, @davidrevoy.

@jonas.smedegaard : Thank you for adding this item to the tracker after my review and for the ping by email.

I co-maintain the package icc-profiles-free in debian where it would be appropriate to include ICC profiles once created.

@todd Why did you reassign the task?
It is still valid, even if Chris can now commit to the repo (which I though he could...), but moving it will need quite a lot more changes to not break things - that's the reason why all infrastructure components are still on Github, especially since Gogs was very unreliable initially and we couldn't risk these repositories to go down.

Added lamby as a github admin

SHow.. thanks =)

this looks like an issue for @mak

What URL(s) are you talking about?

If Firefox is also installed on the system, the PureBrowser FSF add-ons pages becomes the normal Firefox add-ons page instead.

At the moment, this is not easily possible without setting up some kind of merge with Github or redirection, as a couple of tools pull data from the repository and have it hardcoded.
I want to have the repository and everything else moved rather soon though, and at the same time split the "PureOS" group at Gogs into pureos-packages and pureos proper, so all the infrastructure pieces can live there as well and we have a separate place for packages (for easier permission control, clear scope and less potential for name conflicts).