On Fri, Aug 22, 2014 at 10:58 AM, Rémi Denis-Courmont <r...@remlab.net> wrote: > Le 2014-08-22 11:24, Harald Sitter a écrit : > >> On Fri, Aug 22, 2014 at 9:38 AM, Rémi Denis-Courmont <r...@remlab.net> >> wrote: >>> >>> Le 2014-08-22 10:31, Harald Sitter a écrit : >>> >>>> All that being said perhaps the more interesting bit is why exactly >>>> VLC thinks the cache is invalid to begin with. In particular >>>> considering we only have one build that builds with all plugins we >>>> have packaged and there are no third party plugins in any package >>>> anywhere ever. So the cache should always have a superset of what is >>>> available on a system. >>> >>> >>> >>> Changed file name, file size, or file modification time. >> >> >> But how could either of those happen if the only supplier of plugins >> are the VLC packages and so all of the cases you mentioned should be >> reflected in a new cache file provided by a new version of vlc-nox? > > > You tell me; I have never reproduced the alleged crash.
Ah, reproducing this is easy: debootstrap sid apt-get install qtbase5-dev libvlc-dev cmake build-essential vlc-nox vlc; wget http://people.ubuntu.com/~apachelogger/src/vq5.tar.xz; tar -xf vq5.tar.xz; cd vq5 && mkdir build && cd build && cmake ..; ./vq5; .... -> Segmentation fault (core dumped) >> Or more to the point... how could a completely new installation with a >> matching version of vlc-nox and vlc end up thinking the cache is >> invalid? > > > It can't, unless something mucks with the modification time or some data > corruption happens. Maybe the build itself messes up the mtime, although that would be rather odd I guess. _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
