(Now? Ie. with the openpgp-smartcard branch, no?)

Sweet! So, what's the timeline look like for me to be able to test this on something?

https://bugs.debian.org/909567

https://github.com/evilsocket/opensnitch/pull/207

@kyle.rankin Did you see https://bugs.debian.org/903163#135 ? :)

@james.rufer GNOME Software will fetch an extension list when run under GNOME Shell. So, you'll need to run it in a GNOME Shell session and the GNOME site has to be reachable. Try refreshing the software index (refresh button in GNOME Software) in case information is missing.

@todd It seems to me that your question at 11:52 was ambiguous: I guess you intended to ask about _default_ behaviour, and to me it is more likely that Matthias answered only about _ability_ - i.e. that Software center sends requests outside of pureos.net if told to do so. Therefore I disagree that @james.rufer's test is counter to @mak's answer.

@james.rufer does any GNOME extensions appear? (this would be the answer to only packages from approved PureOS.net and it would be counter to what Matthias mentioned in the chat history @ 12:05)... So I want to confirm that...

Chat history on the subject from #community-pureos:talk.puri.sm

Seems to me those fields are simply not provided, and Evince (which it seems you use to parse and inspect the files) wrongly show a bogus timestamp when none is proviced.

The tool nethogs is available in PureOS in the package nethogs. I.e. the tool is "included in most Linux distributions" as was quoted in that forum thread you are linking to.

This problem seems to occur especially when the system in on heavy load. I can easily reproduce it when building the Debian package hdf5.

Add:
This has occurred on three installations, so does not appear random.

After installation, when doing the system upgrade, get the following message:

Installed the latest ISO in Boxes. "UTC" did not come up in search.

I am not sure I understand the problem - what is the issue here? That extensions can be downloaded from GNOME?
Since we trust GNOME already, I don't think it makes sense to disallow that in GNOME software, especially because doing so means people will have trouble installing GNOME extensions.

Reassigning to Matthias, our expert on AppStream (including what and how much PureOS has derived from Debian in that area).

I am glad you isolated the problem. Having been a developer in a previous life, I was only thinking that maybe Mozilla fixed something that might have coincided with the updates.

Should I be going to the cairo project to report this?

gnome-logs shows that AppArmor is denying something with snap, which is how I've installed Firefox. Firefox had not been updated in a while, so something else was changed during one of the recent PureOS updates. I'm not new to the concept of reverse firewalls, but I'm a complete newbie to AppArmor, so will have to dig in.

Even though Nautilus' own "About" dialog showed version 3.30.0-stable, it was actually version 3.30.0-1. I just saw an update to 3.30.0-4, checked the bugs at https://gitlab.gnome.org/GNOME/nautilus/issues , and saw other people had the same bugs. This just got fixed in version 3.30.0-4. Whew, I was about to install Dolphin or Thunar.

It appears that 62.0.2 (not 62.0-2) was released today by Mozilla. When it is available in snap, you may want to try it to see if it fixes your problem.

The official build downloaded from their webpage works without problem.

Definitely does not matter if there are multiple tabs or not for Nautilus to crash. Fast or slow typing both produce a crash. Pasting into the search field so far does not produce a crash. In one case, %CPU reached 200% and Nautilus became unresponsive for long enough that I killed the process. All this is completely new behavior with 3.30.0-stable and never happened with the prior version, 3.26.3.1, which was rock solid.

As of 2018-09-19 KeePassXC has not failed throughout all the updates through yesterday.

(Also needs python3-grpc package in Debian)

Solved on last libvirt updates.

Ah, of course. Thanks!

Urgency bumped manually.

So, I can't exactly figure out exactly which USB device, etc. I need to disable this for (presumbly the "root hub", but I can't reproduce that bit).. plus I managed to reproduce this with the internal trackpad so I've gone ahead and disabled application of the Powertop profile for now in purism-power-optimisations version 0.5.3.

Problem solved! Thank you so much @mak

@jsbret Replace the
GRUB_CMDLINE_LINUX_DEFAULT=“quiet cryptdevice=UUID=708e0d88-4db9-4713-a5ac-aea1abe6e832:luks-708e0d88-4db9-4713-a5ac-aea1abe6e832 root=/dev/mapper/luks-708e0d88-4db9-4713-a5ac-aea1abe6e832 resume=/dev/mapper/luks-708e0d88-4db9-4713-a5ac-aea1abe6e832 splash”
line with
GRUB_CMDLINE_LINUX_DEFAULT=“quiet splash”
ensure GRUB_ENABLE_CRYPTODISK is commented out and then run sudo update-grub and you should be fine.

@mak Thanks for the advice. I commented the line

megadown is now in PureOS, so closing. Thanks. Let me know if you need to update a new version, naturally.

I also just got the 3.30.0 update for GNOME Screenshot, and 'Grab the current window' still shows the display corruption. As before, 'Grab the whole screen' and 'Select area to grab' do not have any problem. So, the bug is limited to grabbing a window.

Great stuff; this helps in tracking it down. On it..

WTF, https://www.mail-archive.com/kernel-packages@lists.launchpad.net/msg297817.html

@jsbret This very much sounds like a different issue that was solved a while ago. Check your /etc/default/grub for GRUB_ENABLE_CRYPTODISK, that option and associated settings should not be enabled (otherwise GRUB tries to decrypt /, which it shouldn't attempt to).

This may be fixed with today's (9/16) update. gnome-screenshot itself was updated to 3.30.0 and appears to work for me.

That's exactly my issue (Librem 13v3). After boot I have to plug-cycle the mouse once for it to become usable

Hi @chris.lamb. I rebooted and ran powertop --auto-tune and my usb mouse and keyboard stopped responding until I detached and reattached the cables.

Hey Theo, can you maybe add a storage engine to our Phab instance?
Just having flatfile storage should actually be sufficient. I can not add this myself because I think I lack permission on the server itself (and that is needed to change this setting).

Example logging output

Hi @johenry, thanks for filing this issue. Whilst I can't reproduce this, like
@mak I suspect this might be be the powertop parts of the purism-power-optmisations. After you reboot and you /cannot/ reproduce, can you try running powertop --auto-tune as root and let me know whether this causes the issue to return?

I did the same and the problem still occurs, but I noticed that gnome-screenshot was not updated in the latest batch. (Now 9/15. Because of Florence, I did not login and update the past couple of days.) On my system, it is still 3.26.0-3.

The issue here is that the tools (Calamares and gnome-initial-setup) use completely different technology.
One would have to implement a password quality checker for Calamares upstream as well.

@Chris, can you look into this and see if it indeed has anything to do with purism-power-optimisations? (that's the only thing that would make sense to me, but it could also be a kernel issue in general. Encryption being the culprit seems highly unlikely to me though).

Yesterday’s system update showed many GNOME packages upgraded to 3.30.0, but it did not fix this issue.

I have installed 2.10 version from official repositories and it works :)