Vielä täällä luetaan!
Vielä täällä luetaan!
Vielä täällä luetaan!
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.)
I wonder what are the changes of getting pwned on one of those nowadays, with all the known security holes. Could be not even the crooks bother anymore though.
Sorry, but 5.0.0-1ubuntu1 didn’t fix this. In Utopic, with the same ’The Snowman’ DVD as before, I still get:
*** Zero check failed in src/ifo_read.c:903
for pgc->subp_control[i] = 0x00000001
*** Zero check failed in src/ifo_read.c:903
for pgc->subp_control[i] = 0x00000001
*** Zero check failed in src/ifo_read.c:903
for pgc->subp_control[i] = 0x00000001
jani@ubudev:~/lumiukko$ apt-cache policy libdvdread4
libdvdread4:
Installed: 5.0.0-1ubuntu1
Candidate: 5.0.0-1ubuntu1
Version table:
*** 5.0.0-1ubuntu1 0
500 http://archive.ubuntu.com/ubuntu/ utopic/universe amd64 Packages
100 /var/lib/dpkg/status
”Jääpingviini (Pygoscelis adeliae) on keisaripingviinin ohella toinen Etelämantereella elävistä pingviinilajeista.” Kuitenkin valkokulmapingviini, jääpingviini (ainakin en-w:n mukaan) ja myssypingviini elävät nekin toisten artikkeleiden mukaan Etelämantereen niemimaalla tai reunoilla.
The issue went away when I removed gnome-user-share (sudo apt-get --purge remove gnome-user-share
). Apparently it was caused by Gnome’s file sharing function referring to $XDG_PUBLICSHARE_DIR and recreating the (default-named) directory when not found. With gnome-user-share removed, the ”Public” directory no longer reappears.
I’ve set ”enabled=False” in my /etc/xdg/user-dirs.conf which, according to comments in that file, and also according to the spec, should stop xdg-user-dirs-update from running at login time and thus also from recreating any missing $XDG_*_DIR directories.
Additionally, I’ve commented out the definition of XDG_PUBLICSHARE_DIR in my user’s ~/.config/user-dirs.dirs due to not being able to decide where to point it at for now.
Despite xdg-user-dirs-update being disabled, a directory named ”Public” reappears in my user’s home directory at every login. What is causing this and how can I stop the unwanted Public directory from appearing? I’ve found an old Red Hat bug referencing a similar issue, but it’s closed without a known fix.
The issue doesn’t occur for $XDG_TEMPLATES_DIR which I’ve similarly commented out.