driver/xf86-input-vmmouse : cannot create regular file `/lib/udev/rules.d/69-xorg-vmmouse.rules': Permission denied
peter.hutterer at who-t.net
Thu Jan 24 16:43:38 PST 2013
On Thu, Jan 24, 2013 at 06:40:19PM -0500, Dennis Clarke wrote:
> ----- Original Message -----
> From: Peter Hutterer <peter.hutterer at who-t.net>
> Date: Thursday, January 24, 2013 6:24 pm
> Subject: Re: driver/xf86-input-vmmouse : cannot create regular file `/lib/udev/rules.d/69-xorg-vmmouse.rules': Permission denied
> To: Dennis Clarke <dclarke at blastwave.org>
> Cc: xorg at lists.freedesktop.org
> > On Thu, Jan 24, 2013 at 01:11:36PM -0500, Dennis Clarke wrote:
> > >
> > > > > Do I need to isolate this module, build it as root, and then go
> > back
> > > > to being a
> > > > > regular user or ??
> > > >
> > > > vmmouse gets the directory to install the udev rules from
> > pkgconfig by
> > > > default, or --with-udev-rules-dir at configure time. if you don't
> > need
> > > > the
> > > > rules, you can consider the installation as successful though and
> > continue
> > > > to the next module.
> > >
> > > Not too sure how to deal with that. I generally just do a pull from
> > git and
> > > then fire off a build. This proceeds neatly until it hits the
> > vmmouse module
> > > which stops the process. I don't see an option anywhere to skip it
> > and
> > > I don't know if it is a "need" or a "want".
> > >
> > > What I could do is put the username doing the compile into a group called
> > > "xorg" and give that group write permissions to a few specific directories.
> > >
> > > Is that what you suggest ? Or am I supposed to do this build as the
> > root user?
> > - custom user with the right permissions or root is one option
> > - set $CONFFLAGS in the environment to --with-udev-rules-dir. other modules
> > will ignore it, those that don't would likely run into the same permission
> > issue anyway
> I am trying to do this compile as anyone would do any other software package
> which would generally have an install stage that comes after the compile and
> test phases. So the safe bet is to set CONFFLAGS with something like
> this : --with-udev-rules-dir=/opt/xorg/udev
> Dis that and the compile now proceeds but there will need to be some funky
> install done later to copy those bits in /opt/xorg/udev over to the /etc dir.
there is no good answer to this. we can make the driver compile and install
so it works out of the box _or_ we can make the driver compile as user,
without installing udev files. We can't get both, permissions get in the way
> Maybe .. not sure.
> Doing a compile as root is just not going to happen. Not without a full system
> backup first.
> oooops .. spoke too soon. the compile just failed again and quickly too :
> == Processing module/component: "driver/xf86-input-synaptics"
> == configuration options: --with-udev-rules-dir=/opt/xorg/udev
> Cloning into driver/xf86-input-synaptics...
> checking which optional backends will be build... ps2comm alpscomm eventcomm
> checking for MTDEV... no
> configure: error: Package requirements (mtdev) were not met:
> No package 'mtdev' found
> Looks like another dependecy needed.
fwiw, mtdev is needed for both synaptics and evdev.
> When I get to the end of this process I plan to write a detailed article that shows
> how you too can build X. Except with all the dependencies laid out up front
> as well as the secret tricks to make it work.
>  stuff someone knows but isn't documented anywhere to make the process
> easily digestable and no more complex than bootstrapping GCC.
it's quite hard documenting some of those "secrets". e.g. the udev dir
variable I literally only found in the configure.ac file after reading your
email. it's documented (./configure --help shows it), but that requires that
one knows what udev rules are, etc. So the tricky bit here is where to
start and when to stop documenting?
we don't have a useful list of dependencies because it's a moving target,
and it depends on the module set you're building.
You can use your distro to install the build-deps for you though. The
sledgehammer approach on Fedora is yum-builddep "xorg-x11-*"
More information about the xorg