Adrian: Thanks for taking a look! I’m using Ubuntu 18.04, and that appears to be crucial here: I created a 16.04 VM, installed all in-release updates (including Firefox 63), and just as you, was unable to reproduce the issue. I then upgraded the VM to 18.04 and the bug immediately manifested again.
I first reported this against 62 in Launchpad: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1798103
Firefox was since updated to 63 in Ubuntu and the issue remains.
Under Apache Web server configuration, there’s a prompt to create a symlink to enable the newly created site:
ln -s /etc/apache2/sites-available/nextcloud.conf /etc/apache2/sites-enabled/nextcloud.conf
As the instructions in this section are written for Debian, Ubuntu, and their derivatives, a2ensite should be used instead:
a2ensite nextcloud.conf
The commands are currently functionally equivalent (AFAIK), but should this change sometime, the latter would be more future proof, besides being much shorter and easier to type.
Additionally, immediately following the ln -s there is a section about Additional Apache configurations, which correctly instructs the use of a2enmod to create the symlinks. Replacing ln -s with a2ensitewould thus harmonize the two sections.
Okay, did it! https://gitlab.gnome.org/GNOME/gnome-terminal/issues/30
Some years back (2013/2014 maybe?) the ’New Window’ and ’New Tab’ menu items were combined into a single ’New Terminal’ item.
This apparently met with resistance from users, so Fedora and recently also Ubuntu have chosen to build Gnome terminal with DISUNIFY_NEW_TERMINAL_SECTION to restore the old behavior.
This unfortunately leaves users of those distros, like myself, who actually prefer the simplicity of ’New Terminal’, with no practical way to restore that functionality (beyond rebuilding the package with the compile-time switch reverted).
After hearing me out, the Ubuntu maintainer suggested I file a bug here, asking to turn the compile-time option into a Gsetting so that the behavior could be more easily adjusted per user preferences.
So that is what I’m asking here.
Jeremy: If this is indeed the popular choice then I fully respect that. I just wanted to voice my disgruntlement, since I feel the way this was set by upstream is much simpler. Sorry for being late with it, didn’t realize this was getting overridden before the change already came into effect.
Output from procps’ ps with -e only produces the process name, so grepping for ”cli.js start” fails every time. This change adds (POSIX-compliant) -f to all ps calls to get the full command. AWK print parameter is adjusted accordingly where needed.
Issue #1359 resulted in PR #1370, but only addressed the stop: target. The changes here address the rest of the ps calls the same way.
@droidmonkey That page seems to have been deleted from the wiki, but I think I found the problem, sort of. I’m using the -proposed repository, where the current proposed snapd-xdg-open (2.28.5) is just a transitional package (pointing back to snapd), as they’ve integrated xdg-open into snapd itself.
If I downgrade snapd-xdg-open back to 0.0.0~16.04 from -updates (which also requires a downgrade of snapd back to 2.27.5), the Open URL function in KeepassXC does work (with the fresh 2.2.2 release at least).
So an upcoming change in these packages will break this, unless they do some more juggling before the packages move from -proposed to -updates.
The issue persists for me in 2.2.1 in Ubuntu 16.04. I can get it to work by removing snad-xdg-open from snapcraft.yaml (effectively reverting PR #1011) before building the snap.