[GRASS-dev] fix for build, ERROR: MAPSET PERMANENT - permission denied

[Raymond Burns]

Hi Glynn,

Comments within the text:

On Wed, 11 Nov 2009, Glynn Clements wrote:

> 
> Raymond Burns wrote:
> 
> > > > I was looking for something else when I noticed this.
> > > > 
> > <snip>
> > 
> > > 
> > > What problem is this supposed to fix?
> > > 
> > 
> > ERROR: MAPSET PERMANENT - permission denied
> > 
> > 346 times on the current build.
> > 
> > In previous cvs pulls, each make iteration rebuilt the html pages and
> > presented this message which leaves the lasting impression the target
> > did not get made correctly and therefore may have left targets beyond
> > it in the makefile un made.
> 
> That suggests that the dist.<arch>/demolocation has the wrong
> ownership. This could happen if you have an existing dist.<arch>
> directory owned by another user (or possibly if you build as "root").
> 

I often build as root and am doing so now. When I add a user on this
box I'll try that also.

> > The most recent cvs pull appears to recognise the completed target so
> > the message occurs only on the first make iteration.
> 
> The error arises because the process for generating the HTML files
> runs each command with the --html-description option. If the command
> fails, you get an error, but I suspect that you may still end up with
> an incomplete HTML file, which will then be used by subsequent builds.
> 
> > > Also, I can't see how the patched version can work, as nothing tries
> > > to make the "htmldesc" target.
> > 
> > It did not, this as a revision I believe does, though it does not
> > paste well either. At this point, if there is possible useful output
> > from the execution of the code with --html-description there may be
> > reason to ignore the patch and retain the message, if there is no
> > other useful output of the --html-description I would just as soon not
> > see an implied permission violation. On a new platform. I get enough
> > of those that are real.
> 
> This is attempting to fix the symptoms rather than the problem. The
> problem is that dist.<arch>/demolocation has the wrong owner. This can
> affect more than just the HTML files.

Fixing a symptom does us no good, sorry to pester it but lets keep
going.

> 
> The dist.<arch>/demolocation demolocation is made by copying the
> demolocation directory using "tar cBf - ... | tar xBfo - ...". The
> copy should be owned by the current user (even if run as root, due to
> the -o flag; OTOH, this may not be recognised by non-GNU versions of
> "tar").
> 
> Can you check the permissions on the dist.<arch>/demolocation
> directory?

yes;

grass-6.4.0RC5# ls dist.sparc64-unknown-linux-gnu/demolocation/ -ld
drwxr-xr-x   3 1338     1200         4096 Nov 11 14:30
dist.sparc64-unknown-linux-gnu/demolocation

not a known user so yes I'm probably going to fix a couple of things
at one time here.

user and group are probably from the grass-6.4.0RC5 tarball, I
untarred it as root.

(before you ask)
tar (GNU tar) 1.13

The original tree I first used was built by root on an ia32 many times
and works well (start from known good and change as few variables as
possible before proceeding). I would not know if all the details of
the html pages are correct. I have read some of them, with lynx, they
hold information.

after # chown -R root.root * ; make clean; make 

yes, the message is gone and yes it ran code with --html-description

I wonder, the user who configures the package ultimately has write
permissions in the tree, is it worth a chown $USER dist.<arch> or
would that be stepping over a line. Many of the admins who read me the
riot act for compiling as root also veto code that has a chown in it.

The original tree, regardless of how old, is still available to work
on the details if you wish. I'm getting into other issues where
warnings about casting pointers to integers of different size are of
interest and will probably be topic of another thread. I'm still
teaching this box what size_t is and figuring out why t2==0 in
read_data_fp_compressed.

> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>
> 

Thanx
  Ray