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.

The XDG specified directories, as described by Jacob, are not created with the account, they’re created (and recreated if missing) when the user logs in. Pointing those user-dirs variables at $HOME is a workaround, but it doesn’t actually disable the functionality; if disabling is what you want, you can change ”enabled=True” to ”enabled=False” in /etc/xdg/user-dirs.conf. As the comment in that file above the definition says,

# This controls the behaviour of xdg-user-dirs-update which is run on user login
# You can also have per-user config in ~/.config/user-dirs.conf, or specify
# the XDG_CONFIG_HOME and/or XDG_CONFIG_DIRS to override this

Why don’t we build deep below ground instead of high above it?

I’ve worked around that enum error (since before owncloud 7 already) by adding this in 3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Platforms/MySqlPlatform.php:

@@ -661,6 +661,7 @@
     protected function initializeDoctrineTypeMappings()
     {
         $this->doctrineTypeMapping = array(
+            'enum' => 'string',
             'tinyint'       => 'boolean',
             'smallint'      => 'smallint',
             'mediumint'     => 'integer',

Reopening. It didn’t go away after all, looks like the occurrence varies (didn’t see it yesterday), perhaps those Chromium settings just made it more probable.

I take that back, it seems to have been caused by Chromium all along (more specifically either #threaded-compositing-mode or #deadline-scheduling), despite those glitches appearing outside of Chromium too. Sot it’s a Chromium bug, but I’m too lazy to debug this further (the issue goes away with those configuration flags set to default) so I’ll just mark this as invalid.

*kyberhesarissa