The Include directive, when given a directory as parameter (such as /etc/proftpd/conf.d/, as in the stock /etc/proftpd/proftpd.conf), causes all files in said directory to be read, not just ones ending in .conf. This causes problems if, for instance, I’m using vim to edit a file in the included directory while the proftpd service is being (re)started: vim stores a .swp file in the same directory, and proftpd may fail to start with ”fatal: unknown configuration directive” when it tries to parse the .swp file.
Those scripts are ran from the initrd, so it’s looking for plymouth and plymouthd in the initrd /bin and /sbin directories, and those are probably missing the said files just as the error message says.
/usr/share/initramfs-tools/hooks/plymouth is responsible for copying the plymouth executables onto the initrd, so to see why it fails to copy the files, I added `set -x` to it and then ran `update-initramfs -v -u`.
In my case (I’m running Kodibuntu, I recently upgraded the underlying system from 14.04 to 16.04) the issue was that the hook failed to find Kodibuntu theme files for Plymouth, because it was looking for them in /usr/share/plymouth/themes (which apparently is the standard place), whereas the files actually resided in /lib/plymouth/themes for some (legacy?) reason. The hook therefore determined that I have no working Plymouth theme and thus don’t need the executables.
After moving the theme files to /usr/share/plymouth/themes (and some manual labor updating references in the files themselves as well as Plymouth’s alternatives) the hook now correctly finds those files and then proceeds to copy the Plymouth executables onto the initrd.
Haven’t seen this once since upgrading to 16.04 back in April, so I’m pretty sure the issue has been fixed. Yay!
Steps to reproduce:
Select to download a file uploaded to a channel.
What happens:
A browser window/tab opens with a Slack redirect URL pointing to the file, and asks me to log in to Slack.
What I expect to happen:
I’d prefer it if Scudcloud just directly prompted me with the file saving dialogue, without having to log in to Slack again in the browser.
Other info:
I’m using version 1.22-2 from the PPA on Ubuntu 14.04. I have 2FV set up for the Slack team in question in case it matters.
Steps to reproduce:
0. Have two projects, A and B
1. Open project A in Geany, make no changes
2. Select Project > Recent Projects > Project B
(Reproduced on an up-to-date Xenial installation today.)
What happens:
A dialog pops up saying the previous project is open, and asks if I want to close it before proceeding.
What I expect to happen instead:
For Project B to open without the dialog. I’ve not made any changes to Project A so the dialog is blocking the switch unnecessarily. If I *had* made changes, I’d expect them to be saved implicitly at this point, or, failing that, to be prompted to *save* the changes before switching; not whether I want to close Project A (which I do).
Perhaps unrelatedly, the prompt title (”The ’Project A’ project is open.”) seems to be missing from Launchpad translations; only the question (”Do you want to close it before proceeding?”) is translatable.
Thanks @VicDeo, that indeed fixes it.
I’d argue that the comment above the setting in the sample makes this less than apparent — at least I would have been unlikely to have dared to set it to false on my own, and it still seems to me that in making this change I lose ”a crucial security check” for .htaccess. But that’s perhaps subject for another bug.
modules/main/templates/_textarea.inc.php has two links pointing to URLs under issues.thebuggenie.com without preceding http:// protocol, resulting in non-working links.
$ grep 'href="issues' core/modules/main/templates/_textarea.inc.php
'MarkdownFormatting')); ?>
'MarkdownFormatting')); ?>
- Open a text area, for example to report a new issue
- Have Markdown as Selected syntax
- Have the ”See more formatting tips in MarkdownFormatting” tip appear (I don’t know the exact steps to trigger this)
4. Try to open the MarkdownFormatting link
In Wily, adding the PPA and running `apt update` results in a ”W: Failed to fetch … 404 Not Found”: apparently there are no Wily builds in the PPAs. FWIW, I have been using dailies from the ”vivid” repository and they seem to work fine under Wily.
The README documents wontDeepEqual() as similar to willDeepEqual() but expecting a rejected promise. But a wontDeepEqual() function is not actually defined in the plugin code.