Bugzilla Bug 137137

i686-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -O2
-fomit-frame-pointer -DNDEBUG -m32 -march=i686 -Wall -Wstrict-prototypes
-Wdeclaration-after-statement -D__XEN_INTERFACE_VERSION__=0x00030101 -fPIC
-I/usr/include/python2.4 -c src/fsys/reiser/reisermodule.c -o
build/temp.linux-i686-2.4/src/fsys/reiser/reisermodule.o -fno-strict-aliasing
-Wall -Werror
src/fsys/reiser/reisermodule.c:20:26: dal/file_dal.h: No such file or directory
src/fsys/reiser/reisermodule.c: In function `file_dal_close':
src/fsys/reiser/reisermodule.c:49: error: structure has no member named `dev'
src/fsys/reiser/reisermodule.c:50: warning: implicit declaration of function
`dal_free'
src/fsys/reiser/reisermodule.c: In function `reiser_fs_open':
src/fsys/reiser/reisermodule.c:221: warning: implicit declaration of function
`file_dal_open'
src/fsys/reiser/reisermodule.c:221: warning: assignment makes pointer from
integer without a cast
error: command 'i686-pc-linux-gnu-gcc' failed with exit status 1
make[1]: *** [build] Error 1
make[1]: Leaving directory
`/var/tmp/portage/xen-tools-3.0.2-r1/work/xen-3.0.2/tools/pygrub'
make: *** [all] Error 2
make: Leaving directory `/vGentoo Base System version 1.6.14

Created an attachment (id=89442) [edit]
emerge --info

Looks like the same problem was reported upstream and marked invalid because it
worked for them on Debian - see
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=573

As far as I can tell, the problem is that pygrub (part of
app-emulation/xen-tools) is expecting progsreiserfs v0.3.0, which provides
/usr/include/dal/file_dal.h .

The only version of progsreiserfs in portage is 0.3.1rc8, which provides
/usr/include/dal/file.h instead of /usr/include/dal/file_dal.h and thus causes
the build failure. I've checked the two files and, as you'd expect, they're
different - the filename change is due to an API change (function names change
eg from 'file_dal_open' to 'file_open').

Things are fine in Debian because they only provide the 0.3.0.x versions.

I can replicate the build failure by installing sys-fs/progsreiserfs then
attempting to install app-emulation/xen-tools. After uninstalling
sys-fs/progsreiserfs, app-emulation/xen-tools builds fine. However, I don't
have access to hardware with virtualization extensions, so can't test pygrub's
functionality - I assume it will be missing support for reading partitions
formatted as reiserfs.

An easy solution is to make sys-fs/progsreiserfs-0.3.1 block
app-emulation/xen-tools, but that's not particularly nice for users. A slightly
better approach might be explicitly disabling reiserfs support in pygrub (which
may require a patch to setup.py), and using ewarn to notify the user (to
prevent bug reports about missing resierfs functionality).

I think the ideal solution is an investigation of the API change between 0.3.0
and 0.3.1, and hopefully a backwards-compatible patch to
http://lxr.xensource.com/lxr/source/tools/pygrub/src/fsys/reiser/reisermodule.c
that allows it to function with either version. However, I'm not in a position
to provide this.

A more realistic solution would be the introduction of an ebuild for the 0.3.0
series of progsreiserfs, using the same libraries/headers-only approach of the
0.3.1rc8 ebuild.

Created an attachment (id=94557) [edit]
a patch for reisermodules

a patch to test

Hi I just posted a patch that at least compiles xen. Please test if it is also
does what it should do.

hmm i really understand nothing...
is it a patch for xen or xen-tools?
how could i do this correctly, please?

(In reply to comment #4)
> Hi I just posted a patch that at least compiles xen. Please test if it is also
> does what it should do.
> 

oki, it works with the patch.
thank you

Fixed in app-emulation/xen-tools-3.0.2-r4, thanks.