Hi!
Attached is the patch for RELENG_4. It works but I don't like
how it pollutes the Makefile.inc1. Anyone with a better idea?
On Tue, Dec 12, 2000 at 09:43:55AM -0800, Marcel Moolenaar wrote:
Ruslan Ermilov wrote:
Let me rephrase the question: Did you modify the manpages to get it
[I don't know why -current is CC'd this is clearly about -stable]
Ruslan Ermilov wrote:
Attached is the patch for RELENG_4. It works but I don't like
how it pollutes the Makefile.inc1. Anyone with a better idea?
Allow me to sidetrack for a moment:
I just ugraded a machine from 4.1 to
On Mon, Dec 11, 2000 at 09:07:53AM -0800, Marcel Moolenaar wrote:
Ruslan Ermilov wrote:
On Sat, Dec 09, 2000 at 12:29:54PM -0800, Marcel Moolenaar wrote:
Ruslan Ermilov wrote:
On Fri, Dec 08, 2000 at 06:22:09PM -0800, Marcel Moolenaar wrote:
Ruslan Ermilov wrote:
On Mon, Dec 11, 2000 at 09:12:17AM -0800, Marcel Moolenaar wrote:
Ruslan Ermilov wrote:
It appers that running mtree(1) with -U under non-root account works OK,
i.e. it creates all missing directories, and exits with status of zero.
I believe it also emits warnings, right?
What if
Ruslan Ermilov wrote:
Let me rephrase the question: Did you modify the manpages to get it to
work with the new groff(1) or is the new groff(1) backward compatible
with the old groff(1)?
The new groff(1) is not always backwards compatible.
Ok, thanks. That's all I wanted to hear.
OK,
On Tue, Dec 12, 2000 at 10:23:44AM +0200, Ruslan Ermilov wrote:
OK, I will augment the USRDIRS then, add the groff to bootstrap-tools,
and leave the better (if one exists) implementation to someone else.
Why does groff need to be a bootstrap-tool? Its not like we need to
build manpages that
David O'Brien wrote:
On Tue, Dec 12, 2000 at 10:23:44AM +0200, Ruslan Ermilov wrote:
OK, I will augment the USRDIRS then, add the groff to bootstrap-tools,
and leave the better (if one exists) implementation to someone else.
Why does groff need to be a bootstrap-tool? Its not like we
Marcel Moolenaar wrote:
Why does groff need to be a bootstrap-tool? Its not like we need to
build manpages that early in the build.
There's no other place. Only bootstrap tools, cross tools and build
tools are build in such a way that they can run on the build machine.
You can't build
"Daniel C. Sobral" wrote:
There's no other place. Only bootstrap tools, cross tools and build
tools are build in such a way that they can run on the build machine.
You can't build it later than cross-tools. It's not a cross tool itself
and definitely not a build tool. It must be a
On Sat, Dec 09, 2000 at 12:29:54PM -0800, Marcel Moolenaar wrote:
Ruslan Ermilov wrote:
On Fri, Dec 08, 2000 at 06:22:09PM -0800, Marcel Moolenaar wrote:
Ruslan Ermilov wrote:
The attached patches (p4 and p5) try to solve this bootstrapping
problem with groff(1).
Sorry,
On 10 Dec 2000, Dag-Erling Smorgrav wrote:
Marcel Moolenaar [EMAIL PROTECTED] writes:
According to the manpage, if you remove -U it doesn't create new
directories or symlinks. At least that's how I interpret it.
You interpret it wrong. -U just tells mtree to fix permissions. The
On Sat, Dec 09, 2000 at 12:43:24PM -0800, Marcel Moolenaar wrote:
Ruslan Ermilov wrote:
On Fri, Dec 08, 2000 at 06:17:52PM -0800, Marcel Moolenaar wrote:
Ruslan Ermilov wrote:
The attached patches (p4 and p5) try to solve this bootstrapping
problem with groff(1). I have
On Sat, Dec 09, 2000 at 10:11:28PM -0800, Thomas D. Dean wrote:
I have no environment settings that relate to groff and only MANPATH
that relates to man.
There are no local modifications. etc/make.conf only has
CFLAGS= -O -pipe
HAVE_MOTIF= yes
MOTIF_STATIC= yes
USA_RESIDENT=
Ruslan Ermilov wrote:
On Sat, Dec 09, 2000 at 12:29:54PM -0800, Marcel Moolenaar wrote:
Ruslan Ermilov wrote:
On Fri, Dec 08, 2000 at 06:22:09PM -0800, Marcel Moolenaar wrote:
Ruslan Ermilov wrote:
The attached patches (p4 and p5) try to solve this bootstrapping
Ruslan Ermilov wrote:
It appers that running mtree(1) with -U under non-root account works OK,
i.e. it creates all missing directories, and exits with status of zero.
I believe it also emits warnings, right?
What if we create the mtree(1)-compatible BSD.world.dist?
The below was generated
David O'Brien wrote:
On Sat, Dec 09, 2000 at 07:59:46PM -0800, Marcel Moolenaar wrote:
The only thing you don't like about mtree is it changing ownership +
modes, right?
Not only that. Using mtree(1) creates busloads of unnecessary
directories.
But they're harmless. While I
Marcel Moolenaar [EMAIL PROTECTED] writes:
According to the manpage, if you remove -U it doesn't create new
directories or symlinks. At least that's how I interpret it.
You interpret it wrong. -U just tells mtree to fix permissions. The
canonical way to use the mtree files in /etc/mtree is
On Fri, Dec 08, 2000 at 06:17:52PM -0800, Marcel Moolenaar wrote:
Ruslan Ermilov wrote:
The attached patches (p4 and p5) try to solve this bootstrapping
problem with groff(1). I have lightly tested this on my -stable
box, and would appreciate a feedback on them.
Do not remove the
On Fri, Dec 08, 2000 at 06:22:09PM -0800, Marcel Moolenaar wrote:
Ruslan Ermilov wrote:
The attached patches (p4 and p5) try to solve this bootstrapping
problem with groff(1).
Sorry, I missed this statement before. What exactly are the
bootstrapping problems you're seeing?
New
Ruslan Ermilov wrote:
On Fri, Dec 08, 2000 at 06:22:09PM -0800, Marcel Moolenaar wrote:
Ruslan Ermilov wrote:
The attached patches (p4 and p5) try to solve this bootstrapping
problem with groff(1).
Sorry, I missed this statement before. What exactly are the
bootstrapping
Is this the problem I see with mal-formatted man pages?
The pages appear as 1 block with no headers, tities, etc.
tomdean
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
"Thomas D. Dean" wrote:
Is this the problem I see with mal-formatted man pages?
Possibly. I don't know if we changed files to get our sources working
with the new groff(1). If we did, we definitely have a bootstrapping
problem, because that would mean that we can't reliably create manpages
# ls /usr/share/man/man*/zzz*
/usr/share/man/man8/zzz.8.gz
# ls /usr/share/man/cat*/zzz*
ls: No match.
Ok, so, man zzz should reformat the man page. I have attached the
output of 'man -d zzz' and 'man zzz'
After 'man zzz', I see
# ls /usr/share/man/cat*/zzz*
/usr/share/man/cat8/zzz.8.gz
So,
"Thomas D. Dean" wrote:
trying command: (cd /usr/share/man ; /usr/bin/zcat
/usr/share/man/man8/zzz.8.gz | /usr/bin/tbl |
/usr/bin/groff -S -Wall -mtty-char -man -Tascii | ...
should be -mandoc
trying
/usr/bin/groff -S -Wall -mtty-char -man -Tascii | ...
should be -mandoc
This was generated by 'man', not me. There appears to be a problem in
man.
tomdean
To Unsubscribe: send mail to [EMAIL PROTECTED]
On Sat, Dec 09, 2000 at 12:43:24PM -0800, Marcel Moolenaar wrote:
On the other hand, I also don't want to use mtree.
The only thing you don't like about mtree is it changing ownership +
modes, right? If so, what about a new flag to mtree to make it only
create directories and nothing else?
David O'Brien wrote:
On Sat, Dec 09, 2000 at 12:43:24PM -0800, Marcel Moolenaar wrote:
On the other hand, I also don't want to use mtree.
The only thing you don't like about mtree is it changing ownership +
modes, right?
Not only that. Using mtree(1) creates busloads of unnecessary
"Thomas D. Dean" wrote:
/usr/bin/groff -S -Wall -mtty-char -man -Tascii | ...
should be -mandoc
This was generated by 'man', not me.
I understand that.
There appears to be a problem in man.
Not
I have no environment settings that relate to groff and only MANPATH
that relates to man.
There are no local modifications. etc/make.conf only has
CFLAGS= -O -pipe
HAVE_MOTIF= yes
MOTIF_STATIC= yes
USA_RESIDENT= YES
WRKDIRPREFIX= /usr/obj/ports
NO_MODULES= NO
I have always
"Thomas D. Dean" wrote:
# cd /usr/src/gnu/usr.bin
# make clean
# cd /usr/src
# make -DNOCLEAN world
fixed the problem. Before, I used 'make -j36 -DNOCLEAN world'. Could
it be a problem with the Makefile in man?
-DNOCLEAN is not guaranteed to work. Especially when makefiles change.
Ruslan Ermilov wrote:
The attached patches (p4 and p5) try to solve this bootstrapping
problem with groff(1). I have lightly tested this on my -stable
box, and would appreciate a feedback on them.
Do not remove the USRDIRS and INCDIRS and replace it with mtree (ie make
hierarchy). There's
Ruslan Ermilov wrote:
The attached patches (p4 and p5) try to solve this bootstrapping
problem with groff(1).
Sorry, I missed this statement before. What exactly are the
bootstrapping problems you're seeing?
--
Marcel Moolenaar
mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
tel: (408)
:Ruslan Ermilov wrote:
:
: The attached patches (p4 and p5) try to solve this bootstrapping
: problem with groff(1).
:
:Sorry, I missed this statement before. What exactly are the
:bootstrapping problems you're seeing?
:
:--
:Marcel Moolenaar
: mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
:
Matt Dillon wrote:
/usr/src/gnu/usr.bin/groff# make
=== libgroff
=== libdriver
=== libbib
=== addftinfo
=== afmtodit
=== doc
=== eqn
c++ -O -pipe -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_MATH_H=1
Matt Dillon [EMAIL PROTECTED] writes:
c++ -O -pipe -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_MATH_H=1
-DRET_TYPE_SRAND_IS_VOID=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1
-DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void
35 matches
Mail list logo