Re: Bug#630129: libwx-perl: Error: Unable to initialize gtk, is DISPLAY set properly?
reassign 630129 fakeroot
retitle 630129 fakeroot doesn't simulate access() properly
affects 630129 xvfb
thanks
On Tue, Aug 16, 2011 at 03:34:34PM +0200, Aurelien Jarno wrote:
> reassign 630129 xvfb
> retitle 630129 xvfb: doesn't work as non-root user
> affects 630129 libwx-perl
> thanks
>
> On Mon, Jun 20, 2011 at 11:55:48PM +0200, Salvatore Bonaccorso wrote:
> > Hi
> >
> > Now I have a really small set of package difference, where libwx-perl
> > FTBFS:
> >
> > -Setting up xserver-common (2:1.10.2-1) ...
> > -Setting up xvfb (2:1.10.2-1+b1) ...
> > +Setting up xserver-common (2:1.10.2-1+wheezy1) ...
> > +Setting up xvfb (2:1.10.2-1+wheezy1) ...
> >
> > But the changes done was:
> >
> > xorg-server (2:1.10.2-1+wheezy1) testing; urgency=low
> >
> > * Rebuild in testing against mesa without multiarch support.
> >
> > -- Cyril Brulebois <kibi@debian.org> Sat, 18 Jun 2011 10:49:00 +0200
> >
> > and it seems strange, that this would be the reason for FTBFS?
> > Attached is the diff between two builds in wheezy two days ago and
> > today.
> >
>
> A lot of packages started to FTBFS because of recent changes, for
> example most of the R packages. I have used the '-e' option of xvfb-run
> to track this issue, and the problem is the following:
>
> | [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!
> | [dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list!
> | [dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list!
> | [dix] Could not init font path element /usr/share/fonts/X11/Type1, removing from list!
> | [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list!
> | [dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list!
> | [dix] Could not init font path element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list!
> | The XKEYBOARD keymap compiler (xkbcomp) reports:
> | > Error: Cannot open "/var/lib/xkb/server-105.xkm" to write keyboard description
> | > Exiting
> | (EE) Error compiling keymap (server-105)
> | (EE) XKB: Couldn't compile keymap
> | (EE) XKB: Failed to load keymap. Loading default keymap instead.
> | The XKEYBOARD keymap compiler (xkbcomp) reports:
> | > Error: Cannot open "/var/lib/xkb/server-105.xkm" to write keyboard description
> | > Exiting
> | (EE) Error compiling keymap (server-105)
> | (EE) XKB: Couldn't compile keymap
> | XKB: Failed to compile keymap
> | Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.
> |
> | Fatal server error:
> | Failed to activate core devices.
>
> Basically xvfb-run tries to write a file to /var/lib/xkb/, which is a
> directory owned by root (and not thus not accessible to the normal user)
> so it fails. When this directory is made writeable to the user (for
> example 1777), the build succeed.
>
xkb actually correctly tests that it can write to /var/lib/xkb, and
fallbacks to /tmp if not. For that it uses :
access(XKM_OUTPUT_DIR, W_OK | X_OK) == 0
(see http://cgit.freedesktop.org/xorg/xserver/tree/xkb/ddxLoad.c#n149)
When fakeroot is used, it simulates that this path is writeable, but
later fails when trying to write the file. It should simulate both
access() and open() consistently.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: