Bug#544835: neverball - FTBFS: Failure to initialize virtual file system

[Guillem Jover]

Hi!

On Mon, 2009-10-19 at 14:52:44 +0200, Jordà Polo wrote:
> On Fri, Oct 02, 2009 at 10:48:22AM +0200, Jordà Polo wrote:
> > The new version has been uploaded (thanks Tolimar), and it is still
> > failing. The debug message is only slightly more descriptive:
> > 
> > > Failure to initialize virtual file system: No such file or directory
> > 
> > I haven't been able to take a look at it yet, and I'm leaving on
> > vacation. I'll try to fix it as soon as I come back (~2 weeks).
> 
> Like #544356, this bug also seems to be related to libphysfs
> initialization, except I haven't been able to reproduce it. `mapc' is
> failing in a slighly different scenario: it is being called directly
> (./mapc) instead of using PATH.
> 
> The only change that I can think of at the moment to fix this issue is
> calling `mapc' using the full path (as in
> /tmp/buildd/neverball-1.5.4/mapc), but since I can't reproduce it, I'm
> still not sure if it will make a difference.

The problem is that mapc is (indirectly) relying on HOME being writtable,
which fails on some buildds as they set it to a non-existent path. You
should be able to reproduce it by doing something like:

  $ HOME=/non-existent debuild -us -uc -b

The callgraph for the failing function looks something like:

  neverball/share/mapc.c:main()
  `- neverball/share/fs.c:fs_init()
     +- libphysfs/physfs.c:PHYSFS_init()
     |  `- libphysfs/physfs.c:calculateUserDir()
     |     `- libphysfs/platform/posix.c:__PHYSFS_platformGetUserDir()
     |        `- Gets HOME environment variable.
     + libphysfs/platform/unix.c:__PHYSFS_platformRealPath()
       `- Fails

regards,
guillem