It seems that PrintScreen is now bound to Gnome Settings Daemon, which is used to take screenshots instead of gnome-screenshot. Keyboard settings (in Gnome settings) still has a screenshot shortcuts section in the keyboard shortcut settings, but those too now only trigger Gnome Settings Daemon’s screenshot feature, not gnome-screenshot.

What’s worse, disabling those shortcuts does not allow for remapping PrintScreen back to gnome-screenshot using a custom shortcut, as pressing PrintScreen in the shortcut selector window still just triggers the GSD ’blink’ instead of registering PrintScreen as the new shortcut key for the custom command. Only the screenshot section’s pre-defined actions allow for PrintScreen to be grabbed. (At least that’s what it does here.)

When the screenshot shortcuts are disabled, nothing is apparently saved anywhere despite the blink effect. The ”Save a screenshot to Pictures” shortcut has to be defined for the screenshots to actually get saved, and then they will be unconditionally saved to $XDG_PICTURES_DIR: https://bugzilla.gnome.org/show_bug.cgi?id=699642

After upgrading from Xenial to Bionic, my syslog is being spammed by minissdpd. From today’s syslog going back three hours:

15.05 jani@saegusa:~$ grep ”is not from a LAN” /var/log/syslog | tail
Mar 23 15:03:30 saegusa minissdpd[1990]: peer 192.168.1.4:39280 is not from a LAN
Mar 23 15:03:33 saegusa minissdpd[1990]: message repeated 3 times: [ peer 192.168.1.4:39280 is not from a LAN]
Mar 23 15:03:36 saegusa minissdpd[1990]: peer 192.168.1.10:13206 is not from a LAN
Mar 23 15:03:36 saegusa minissdpd[1990]: peer 192.168.1.10:13206 is not from a LAN
Mar 23 15:03:51 saegusa minissdpd[1990]: peer 192.168.1.1:32769 is not from a LAN
Mar 23 15:04:21 saegusa minissdpd[1990]: message repeated 39 times: [ peer 192.168.1.1:32769 is not from a LAN]
Mar 23 15:04:29 saegusa minissdpd[1990]: peer 192.168.1.10:13206 is not from a LAN
Mar 23 15:04:29 saegusa minissdpd[1990]: peer 192.168.1.10:13206 is not from a LAN
Mar 23 15:04:50 saegusa minissdpd[1990]: peer 192.168.1.1:32769 is not from a LAN
Mar 23 15:04:51 saegusa minissdpd[1990]: message repeated 19 times: [ peer 192.168.1.1:32769 is not from a LAN]
15.05 jani@saegusa:~$ grep -c ”is not from a LAN” /var/log/syslog
1623

192.168.1.0 is my LAN.

According to the upstream report [1], specifying an interface should get rid of the ”not from a LAN” messages, and I can confirm that adding ”-i eth1” to the value of MiniSSDPd_OTHER_OPTIONS in /etc/default/minissdpd does just that. I don’t know how good a solution adding a fixed interface is though, I’d imagine switching to (e.g.) a wifi interface on a system with multiple interfaces would cause the message flood to reappear.

*[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890584

Possible upstream issues: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842015 -> https://dev.gnupg.org/T2818 (-> https://dev.gnupg.org/T2843#)

When I’m connected to my desktop computer via ssh, with the desktop computer’s desktop environment running and unlocked, trying to decrypt a gpg-encrypted file causes gpg-agent to invoke pinentry-gnome3 on the desktop. Assuming I’m physically elsewhere, I’m obviously unable to use the prompt on the desktop to enter the passphrase.

This happens despite both pinentry-tty and pinentry-curses being present on the desktop (in addition to pinentry-gnome3), and having GPG_TTY point to the correct tty (export GPG_TTY=$(tty)). Under these circumstances I’d expect gpg-agent to gracefully fall back to non-graphical alternatives.

Granted, I’ve so far only simulated being physically elsewhere by first ssh’ing out of the desktop, then back in again from the other end. If gpg-agent is using some kind of magic to detect that in reality I’m still physically on the desktop, then this report is invalid (although I’d still feel uneasy about such magic).

== Steps to reproduce ==
1. log in to desktop computer A
2. use another computer B to ssh in to the desktop computer
3. still physically on B, invoke `gpg -d encrypted.gpg` on A (over ssh)

== What happens ==
Graphical passphrase prompt pops up on A, while your ssh terminal on B waits

== What I expect to happen ==
For a non-graphical passphrase prompt (such as pinentry-tty or pinentry-curses) to appear on B’s ssh terminal

Upstream (based on a merged duplicate): https://dev.gnupg.org/T2011

When pinentry-tty is used to prompt for the password, interrupting the prompt using ctrl-c leaves the terminal only partially working: only some letter keys are echoed back.

The terminal remains in this broken state for about a minute, after which it resets itself and everything starts working again.

Below, I’m swiping through all alphabet and numeric keys of my keyboard at both 14.54, where only ”469+esgxb” gets through, and again at 14.55 (the last line), where they all come through.

14.54 jani@saegusa:testejä$ export LC_ALL=C
14.54 jani@saegusa:testejä$ { sleep 60; echo ”60 seconds passed”; } & LC_ALL=C /usr/bin/gpg -d passwords.gpg
[1] 12375
gpg: AES encrypted data
Enter passphrase

Passphrase:
gpg: signal Interrupt caught … exiting

14.54 jani@saegusa:testejä$ 469+esgxb^C
14.55 jani@saegusa:testejä$ 60 seconds passed

[1]+ Done { sleep 60; echo ”60 seconds passed”; }
14.55 jani@saegusa:testejä$ 1234567890+wertyuiopåasdfghjklöäzxcvbnm,.

== Steps to reproduce ==
1. Download https://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Car_crash_1.jpg/193px-Car_crash_1.jpg?download
2. Open the image in Shotwell Viewer: $ shotwell 193px-Car_crash_1.jpg
3. Select File > Save As…
4. Keep/set Format as ”Current”, don’t change any other parameters
5. Enter ”193px-Car_crash_1.png” (without quotes) as the filename, select OK

== What happens ==
The viewer now displays a black screen, with the text ”Photo source file missing:” followed by the (.png-ending) image path entered in the dialog. The file has not been saved.

== What I expect to happen ==
For the (now misnamed) .png-ending file to have been saved, and be opened in the Viewer.

== Other notes ==
* If an image file with the .png ending already exists, and I choose to overwrite it with the JPEG, the black error screen does not appear; instead the previously-existing PNG image file is then opened in the viewer.
* I’m (intentionally) not doing an actual Format change in the first Save As dialog here. If I do select PNG as the format, then saving the file does work as expected (using any filename extension).
* I used .png just as an example here. Using any variant of /jpe?g/i as the extension seems to work as expected (i.e. the file is saved under the new name), whereas anything else (.gif, .foo etc.) results in the same ”file missing” error as above.
* If the original file is a PNG file, saving it with .jpg (or any other extension for that matter) seems to work as expected (i.e the file is saved under the new name, with the now-incorrect extension).

(My original report at Launchpad: https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1710641#. I tweaked some details for the report above, with Shotwell 0.27.4 currently in Bionic.)

@kubiko That’s good to hear, gives me confidence in running the snap on my main server again (instead of the VM). Thanks again guys!

@xet7 Alright, here’s hoping those fixes hit the spot! Thanks a lot.

And now, suddenly, it just works again.

root@saegusa:~# snap install wekan
wekan 0.77-29-g9e62584 from 'xet7' installed

root@battra:~# snap install wekan
2018/03/02 16:39:13.986937 cmd.go:212: DEBUG: restarting into "/snap/core/current/usr/bin/snap"
wekan 0.77-29-g9e62584 from 'xet7' installed

Darn it, I was hoping to catch the exact cause. Unless you guys already found and fixed it?

What’s changed on my end since I posted the last comment a week ago is the core snap updating from 4017 to 4110.