If we fix the underlying issue all users logged into a GNOME session will be in the KVM group and no additional work is necessay, it works out of the box (as users would expect). Just pull this systemd patch into PureOS:

Jumping somewhat to a reasoned conclusion, given that the security for the most-common devices in/around the free software ecosystem (ie. Thinkpads) do not provide much security there has been a correspeonding lack of activity and effort put into the software.

The thing is that we plan to make PureOS target the average user so most of the time there will be no system administrator but only people who don't know what a terminal or a command line is. We cannot exclude this type of people who are the ones that currently have no access to software freedom by not being technical enough.

What we need to determine is if it is "doable" under Gnome/Debian with a reasonable level of security on par with iOS, Android and Windows (as examples).

As promised, I did a bit of research into these. The general consensus is that fingerprint readers are essentially insecure devices that give a false sense of security.

In T486#8954, @mladen.pejakovic wrote:

Yes, there was a typo. :)

So, I have a UK device and am not seeing this subsequent remapping. What, exactly, should I be looking for?

Sorry, I just realized I never replied: L15 is not affected, and only OSes with latest systemd are affected.

Fixed in https://source.puri.sm/pureos/core/pureos-meta/commit/d5c4459a71290fa0b0570e0d76b6b272d9fcf6f5

@zlatan.todoric Sorry for the late reply. As I am about to depart for Debconf, I can't really comment on the issue, but I can provide pictures of the chip I got from ThinkPenguin, which pretty much was exactly the same type that was already built into my Librem device:

Thanks for reeporting. Don't know how this slipped through.

Problem is we can't "just" add every new user created on the system to the kvm group.

Not sure what you mean with "filename information", but support for adding a GPG signature is on my todo list already.

With "Emoji font" you mean fonts-noto-color-emoji in particular, right?
Since we already ship a great deal of the Noto fonts for language/script compatibility, adding the Emoji font too would make some sense.

Done :-)

• Download the latest Twemoji/eosrei release from https://github.com/eosrei/twemoji-color-font/releases (in zip format)
• Extract TwitterColorEmoji-SVGinOT.ttf
• Delete /usr/lib/purebrowser/fonts/EmojiOneMozilla.ttf
• Copy TwitterColorEmoji-SVGinOT.ttf into that folder

Another option for a complete and regularly updated color emoji set is twemoji. It is not yet packaged for Debian afaik:

Note that this lead to strange emoji rendering in PureBrowser: https://tracker.pureos.net/T437

thx

Hi all, just to clarify some things:

Will users from previous versions need to add his user to the kvm group or will you implement a package with scripts to make necessary changes (if it is possible)?

I like this idea.

OK sorry for the misunderstanding.

Thank you @jonas.smedegaard !

I guess Chris' point was that you could close the issue yourself.

Users that are not part of the kvm group get an error message when starting Boxes that asks them to manually add themselves to the group.

Yes, you can close the issue.

@francois Thanks. Shall we close this one up then? :)

(IIRC my question around adduser.conf was to ensure new users had it, but not sure)

@chris.lamb Not sure if I get the question.. /etc/adduser.conf would need to be adjusted, as adduser is used by accountsservice in Debian.
New users created by Calamares are added to the kvm group, but not ones created by adduser/the OEM setup.

I was sawing apps installed some time ago after the upgrade and i saw that timidity (one of them) was running a daemon that i thought it could block the sound input and output, i uninstalled it and after reboot, externals speakers and microphone were detected.

Yeah, name is showed again after reboot.

The "Application menu" extension it works now. I have read that it does not work if you disable "hot corners" on "tweak". Now i am going to disable the extension and reboot to test if "Applications" name it appears again. (They appears after disable but i have not idea if they would appears after reboot)

I read this in a review:

The "Application menu" extension error was reported by some users days ago here: https://extensions.gnome.org/extension/6/applications-menu/ but i did not read about did not appear the name after this.

This issue seems to be triggered when I switch from one application or desktop to another, after I've woken up from a sleep/hibernate.

Thanks a lot for testing and reporting this, @francois!

The problem has now been fixed on my side with the new version of qemu (now on green). I can run a virtual machine without any problem.

Updated!

FYI for all subscribers - the Tor Browser downloaded from PureOS repos hasn't worked for anyone over the past 6-7 months. To use the Tor Browser, we all have to download the package directly from their website. It would be great if this could be fixed in the PureOS repos so everyone could easily download and install the Tor Browser Bundle using "Software" in PureOS. See the following threads for more on this:

People from thinkpenguin insist on that their card works with Trisquel 7 – and that if it doesn't work for me it has something to do with my system ("USB controller related problems/USB hub issues/or whatnot").

This is now "fixed" in PureOS, or worked-around rather.
I hope to maybe be able to address the actual issue at Debconf.

I've uploaded a new revision of Tilix with my patch to Debian: https://tracker.debian.org/news/973587/accepted-tilix-181-1-source-all-amd64-into-unstable/
Let's see if this sticks. Regardless of the workaround, we should still work towards fixing the actual issue, because that will not only benefit Tilix, but also GNOME Terminal and any other VTE-using app.

I fixed it by using the old commit hash for the previous microcode. I didn't want to update the microcode since that would mean changing the version (so, changing the config, adding a new tag, rebuilding all, changing coreboot final hashes, changelog, etc..) and I'd like to do it later when I update the FSP for the skylake ones as well, but that one needs testing first and I wanted this fix to be out asap.

Humm.. I thought that repo was meant to contain an archive of all microcodes, I didn't realize he deleted old ones when new ones are out.
I'll update the link and use the commit hash, I prefer that than having the script break constantly.

Given that this is a) the default terminal and b) is *horrifically* ugly, this is giving new users a truly terrible first impression. :(

I was able to reproduce the same behaviour I see in Trisquel 7.0 with the card I got from thinkpenguin (with bluetooth module 0489:e076) – device is initialized but not usable, see above – with a recent kernel (Linux version 4.18.0-rc4) by reverting this commit. I'm quite sure I get the same result with the combo card I got with my Librem 13, but I don't want to change the cards too often… I'm afraid to fret the antenna connectors…

@chris.lamb The only thing we would need to do is get https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675008 fixed in some capacity, no policy change is required - unless we do end up sourcing /etc/profile.d/* for non-login shells like Fedora, in that case we need to change policy I guess.
If we want to establish a new directory for that purpose, we can also do so and add it to policy later. It ultimately all depends on that bug report.

the time we can expect to wait until fix is applied upstream

Considering that we target everyday users, and this affects the first-time experience of our default terminal, is it feasible to maintain a patch/fork of Tilix until the proper fix is applied upstream?

So, the official bug report to watch is now this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675008

@francois

actually, you'd want to change the link to use the latest commit hash, not master, otherwise the script will break again next time the microcode is updated. So instead use:
https://github.com/platomav/CPUMicrocodes/tree/956244154c87316e4e6162f02b17cf3547597b1a/Intel/cpu306D4_platC0_ver0000002**B_2018-03-22_PRD_0B0DD00D**.bin//

Merge request here: https://gitlab.com/lamby/osinfo-db/merge_requests/1

This issue affects everything using VTE, gnome-terminal is only exempt due to reverting an upstream change permanently via https://salsa.debian.org/gnome-team/gnome-terminal/blob/debian/master/debian/patches/Provide-fallback-for-reading-current-directory-if-OS.patch

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706065 for the Debian discussion about this on gnome-terminal and https://bugzilla.gnome.org/show_bug.cgi?id=697475#c43 for the upstream change that broke this in the first place, which VTE upstream won't change.
Also, the PR discussion has some more information: https://github.com/gnunn1/tilix/pull/1456#issuecomment-403175621

It's fixed now.

everything using VTE in Debian actually has to implement a workaround for this to work, gnome-terminal is carrying a patch for this for ages.

Checksum validation of 'main/source/Sources.xz' failed (5eb9cc2ccdf1bf16351400d06ae35d16089874d996c1afeab5b94179974051c2 != 56c51a31d6cc797891e0fa0b3112b7ffc7461819903664beddefcf565c742c0f). - the issue still persists.

@chris.lamb The proper fix would be to establish a new location for scripts to be sourced by shells even for non-login shells. At the moment, everything using VTE in Debian actually has to implement a workaround for this to work, gnome-terminal is carrying a patch for this for ages.

Currently blocked in Debian: gnucash unsatisfiable Build-Depends(-Arch) on armel: guile-2.2-dev

Assigning over for triage/priority :)

We can surely fix this annoying error without changing the Debian Policy (!).

The past sync run was interrupted, apparently because of connectivity issues (hashsum mismatch). This issue should resolve itself within the next few hours automatically - I'll keep this issue open until it does though.

Since upstream doesn't want this patch, we have no good way to resolve this.
I will discuss whether and how to change the Debian policy for sourcing files on first load of shells at Debconf, and if everything failes apply this patch downstream at Debian.

After playing around a bit I suspect the only reason why in Trisquel 7.0 both devices are initialized is that it uses an old kernel version (linux-libre 3.13), so the driver btusb is used instead of ath3k… Have a look at this commit: our bluetooth module (04ca:300d) is blacklistet in btusb and included in ath3k. I'm not sure but this could be a simple answer to the question why in Trisquel 7.0 the device is initialized but not in recent Debian versions / PureOS / …

Fixed.

This should be fixed - can you please verify that the issue is indeed resolved for you?

I received the module from thinkpenguin – and it's really a different QCNFA222… But yesterday I wasn't able to get it to work with Trisquel 7, it behaved the same way as our module (which is built in the Librem 13): the bluetooth device is initialized without the firmware but I can't find my other bluetooth devices to connect and when I set the device to visible I can't find it with my other devices.

The issue is known to the system: https://master.pureos.net/depcheck/green/binary/amd64/details/libkf5filemetadata-bin/5.45.0-1

Sure, I have no idea how you guys do things, so I'll just assign it to zlatan as suggested. Thanks.