Hi
I was looking for something else when I noticed this.
There are embedded tabs present so the attached properly formated
patch is the proper way to apply (do not cut and paste)
diff include/Make/Html.make.orig include/Make/Html.make
85c85,86
< htmldesc = \
---
htmldesc:
htmldesc = \
This causes make to perform correctly but I do not know if the
output is as intended, I believe it now functions
Thanx
Ray
patch_Html.make (447 Bytes)
Raymond Burns wrote:
I was looking for something else when I noticed this.
There are embedded tabs present so the attached properly formated
patch is the proper way to apply (do not cut and paste)diff include/Make/Html.make.orig include/Make/Html.make
85c85,86
< htmldesc = \
---
> htmldesc:
> htmldesc = \This causes make to perform correctly but I do not know if the
output is as intended, I believe it now functions
What problem is this supposed to fix?
Also, I can't see how the patched version can work, as nothing tries
to make the "htmldesc" target.
--
Glynn Clements <glynn@gclements.plus.com>
Hi Glynn,
On Thu, 5 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.
The most recent cvs pull appears to recognise the completed target so
the message occurs only on the first make iteration.
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.
diff -u include/Make/Html.make.orig include/Make/Html.make
--- include/Make/Html.make.orig Tue Nov 10 09:18:51 2009
+++ include/Make/Html.make Tue Nov 10 09:18:57 2009
@@ -34,7 +34,7 @@
GISBASE=$(RUN_GISBASE) \
PATH="$(BIN):$$PATH" \
$(LD_LIBRARY_PATH_VAR)="$(BIN):$(ARCH_LIBDIR):$($(LD_LIBRARY_PATH_VAR))"
\
- LC_ALL=C $(1) --html-description < /dev/null | grep -v
'</body>\|</html>' > $(PGM).tmp.html ; true
+ LC_ALL=C $(1) --html-description < /dev/null 2>/dev/null |
grep -v '</body>\|</html>' > $(PGM).tmp.html ; true
$(HTMLDIR)/$(PGM).html: $(HTMLSRC)
if [ "$(HTMLSRC)" != "" ] ; then $(call htmldesc,$<) ; fi
--
Glynn Clements <glynn@gclements.plus.com>
Thanx
Ray
patch_Html.make2 (579 Bytes)
Raymond,
On Tue, Nov 10, 2009 at 7:11 PM, Raymond Burns <rayburns@comcast.net> wrote:
...
ERROR: MAPSET PERMANENT - permission denied
346 times on the current build.
In previous cvs pulls,
Do you really mean CVS? Or SVN?
We used to use CVS till end of 2007, then migrated onto another server
which is SVN. Perhaps you are looking at very old code?
Here is the current download page:
http://grass.osgeo.org/download/index.php#software
Markus
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").
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.
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?
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, Nov 11, 2009 at 2:22 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
...
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?
The user confirmed offlist to me that he was on CVS,
not SVN. So he was looking at outdated GRASS source code.
Markus
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@gclements.plus.com>
Thanx
Ray
Raymond Burns wrote:
> 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/demolocationnot 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.
That would explain it; you can use the -o flag to create files as the
current user/group rather than using the user/group from the tar file.
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.
The NAME, KEYWORDS and SYNOPSIS sections are generated by the
--html-description flag; everything from DESCRIPTION onwards is copied
from the description.html or <modulename>.html files. If the NAME,
KEYWORDS and SYNOPSIS sections are missing, then the --html-description
step failed.
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.
It shouldn't be necessary. When dist.<arch> ends up containing files
or directories owned by another user, it's usually caused by the
Makefiles using the "tar c | tar x" idiom to copy a directory, which
is really laziness on our part. We should be using $(INSTALL), even if
that means a command for each directory.
Although the current Makefile uses the -o flag when extracting
demolocation it doesn't do this for "make install", and there's no
guarantee that -o works on other "tar" programs (the "tar" program
isn't specified by POSIX).
--
Glynn Clements <glynn@gclements.plus.com>