/etc/X11/imwheel/imwheel rc starts out with:
# This is only for demonstration of the priority command…
# See the other global Exclude command below for the one you want to use!
# If this is activated it will only apps that have a lower priority
# priority is based first on the priority command, then the position in this
# file – the higher the line is in a file the higher in a priority class it is
# thus for a default priority you can see that the position in the file is
# important, but the priority command CAN appear anywahere in a window’s list
# of translations, and the priority will be assigned to all translations below
# it until either a new window is defined or the priority is set again.
I can’t make heads or tails of that. It’s like most of the sentence-ending periods have been misplaced to make random, unnecessary ellipses elsewhere in the file.
This does indeed seem to be fixed Vivid. Nautilus now has two options to remember the credentials (till logout or forever), and both seem to do what it says on the tin.
I have the exact same problem with the exact same scanner (but I’m running 64-bit Ubuntu w/Linux 3.13.0-45). Sometimes instead of error -110 the logs show the device as being identified correctly, but immediately followed by ”string descriptor 0 read error: -32”. On very rare occasions it just works (no errors when plugged in, identified correctly and scanning works).-110 apparently means not enough power, which is doubly funny because the damn thing has its own power source, and surely a desktop PSU has more power than a laptop…
The community wiki currently claims that the default editor for visudo has been sensible-editor since 8.10 [1]. But for me in both 12.04 and 14.04, `sudo visudo` still launches /etc/alternatives/editor, so select-editor doesn’t actually change visudo’s editor; for that I have to run `sudo update-alternatives –config editor`. So I suspect that either the wiki has incorrect advice, or this bug has been fixed, and has since reappeared.
* [1] https://help.ubuntu.com/community/Sudoers?action=recall&rev=25#content
In README, 2.2.1. Step 1 says I need to add ”execute pathogen#infect()” to .vimrc, while the second point in the checklist at the end of 2.2.2. Step 2 says it should have been ”call pathogen#infect()”. I’m guessing both work, but it should probably be consistently the same in the instructions.
IN 12.04 at least, this seems to be tied to Xorg’s blanking which by default happens after 10 minutes/600 seconds. It can be unset via xset on the commandline, but I finally managed to do this via xorg.conf, like so:
jani@saegusa:~$ cat /etc/X11/xorg.conf.d/*
Section ”Extensions”
Option ”DPMS” ”Disable”
Option ”MIT-SCREEN-SAVER” ”Disable”
EndSection
Section ”Device”
Identifier ”Intel Graphics”
Driver ”intel”
Option ”DPMS” ”Disable”
EndSection
Section ”ServerFlags”
Option ”NoPM” ”true”
EndSection
Section ”ServerLayout”
Identifier ”X.org Configured”
Option ”BlankTime” ”0”
Option ”StandbyTime” ”0”
Option ”SuspendTime” ”0”
Option ”OffTime” ”0”
EndSection
It could be that just the ServerLayout section is actually required (and I’m not sure if other graphics drivers even have a DPMS option of their own like intel does), as none of the other sections by themselves nor together prevented the screen from turning off. (The most confusing one is MIT-SCREEN-SAVER, which I thought was exactly what the xset timeouts were controlling, but apparently not so, as disabling it does not prevent the issue either.)
Thanks Michael. I’ve added lxpanel as being affected, hopefully someone there can take a look.
The indicator blinks between what looks like an empty graph (in a vertically shorter box) and the actual graph (in a full-sized box). This is best demonstrated in a video so I’m attaching one below.
Both the official repository version (0.4) and the one from daily PPA (0.5) exhibit this. Different color schemes don’t seem to affect it (i.e. the problem remains). There’s further problems when I add a third graph, but this report is just about the blinking.
(Bug #1336828 is about the indicator missing entirely in 14.04, so I decided to report this slightly different issue separately.)
For the ’Incorrect padding’ issue, Bug #1012358. (Leaving this as non-duplicate, since the reporter has other ’damaged’ errors besides that one.)
I acknowledge that (and as I said, it hasn’t really caused any issues with the backups), I was just responding to this being ”fixed” (above). If it’s not really an issue in the code, maybe we should close this as invalid? (Although I could argue that the message makes it seem as if there is a problem with the code when in fact there isn’t, so the bug could be ”this warning is slightly misleading”. But that’s up for interpretation.)