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 <k...@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 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110816141238.gc4...@hall.aurel32.net
