Bug#755154: vlc cache gen should happen at runtime, not buildtime

[Harald Sitter]

On Fri, Aug 22, 2014 at 10:58 AM, Rémi Denis-Courmont <remi at 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 <remi at 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.