Depending on use case, using `fmt -w 80` instead of fold may do for a workaround.

$ zsync http://cdimage.ubuntu.com/ubuntu-server/daily/current/zesty-server-amd64.iso.zsync
#################### 100.0% 144.7 kBps DONE     

No relevent local data found - I will be downloading the whole file. If that's not what you want, CTRL-C out. You should specify the local file is the old version of the file to download with -i (you might have to decompress it with gzip -d first). Or perhaps you just have no data that helps download the file

What I *think* it’s trying to say is something like: ”No relevant local data was found, and therefore the entire file will be downloaded. If that’s not what you want, use Ctrl-C to abort. If you do have local data, you should specify the location with -i. If the local data is compressed, decompress it first.”

Also, the ”verifying download…checksum matches OK” message (after downloading is finished) could do with capitalization and whitespace: ”Verifying download… Checksum matches OK.”

Redefining TimeoutIdle or TimeoutNoTransfer in a configuration file inside /etc/proftpd/conf.d/, after they’ve already been defined in /etc/proftpd/proftpd.conf, fails to change those values for the daemon — that is, after restarting the daemon, the values for those parameters remain as those set in /etc/proftpd/proftpd.conf.

At least TimeoutIdle or TimeoutNoTransfer are affected. TimeoutSession and TimeoutLogin, which (in stock 16.04) haven’t been defined in the master configuration file can be set effectively, but setting them first in the master file, then again to different values inside conf.d reveals them to be equally affected.

On the other hand, (at least) ServerName *can* be overridden in the custom configuration file, so the handling of different configuration knobs in this regard seems to be inconsistent.

Steps to reproduce:
1. Create a /etc/proftpd/conf.d/proftpd.conf with the following lines:
TimeoutIdle 10
TimeoutNoTransfer 10
2. Restart proftpd
3. Log into the server, wait 11 seconds

What I expect to happen:
To get kicked out of the server.

What happens instead:
I’m allowed to linger on the server, presumably for the 600 seconds defined for TimeoutNoTransfer in /etc/proftpd/proftpd.conf.

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:

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.

Great, thanks!

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.

With more testing I found that the context menu position depends (perhaps solely) on whether my mouse pointer is on the left side or the right side of the horizontal half of the rightmost monitor: if you imagine a vertical line dividing the rightmost monitor’s display area into two equal-sized halves, right-clicking anywhere on the left side of that line brings up the menu on the correct display, whereas right-clicking anywhere on the right side brings it up on the wrong display.

(That is why I first made the mistake of thinking links weren’t affected: the ones I tried first just happened to be on the left side.)

Unfortunately I don’t have a third display to verify that I’m really seeing a different manifestation of the same bug as Nathaniel, of one that depends on the monitor count.