Bug 21528

I have been encountering this problem also.  I spoke with Chris and
between the two of us, we were able to narrow the problem down to the
inclusion of NOMANCOMPRESS in our /etc/make.conf files.  Once removed,
installworld worked fine again.  I have not had a chance to research the
cause of this problem though.

- Matt

--
Matt Loschert                           loschert@servint.com
Software Engineer                       voice (703) 847-1381
ServInt Internet Services               fax   (703) 847-1383

Comment 2 dirk 2000-11-08 20:11:05 UTC

Responsible Changed
From-To: freebsd-bugs->kris

Over to Mr. openssl. 

I verified that this problem still exists in 4.2-BETA (as of today) 
if NOMANCOMPRESS is set. Would be nice if we can shake this out 
before 4.2-RELEASE... 8-) 

I'm trying to do further analysis.

Comment 3 ru 2001-10-11 16:17:21 UTC

State Changed
From-To: open->closed

This is likely to be caused by either of this: 

1.  Your computer date is set incorrectly. 
2.  Some /usr/src files have future modification dates. 

This confuses make(1) to think that object files are out 
of date, and causes them to be rebuilt when it's not 
supposed to, in `installworld'.  The build (pod2man 
call) should be made only in `buildworld'. 

The solution: 

1.  Check your computer's date. 
2.  ``find /usr/src -mtime -0'' 

Comment 4 ru 2001-10-11 16:17:21 UTC

Responsible Changed
From-To: kris->ru

Asked and answered.

Can this bug be reopened? I must respectfully dissent from ru's analysis
of the problem.

I ran into this behavior yesterday when upgrading a machine I had just
CVSupped to -STABLE. I've upgraded it many times in the past with no
problems, but before building world this time I set "NOMANCOMPRESS=  true"
in make.conf and this happened. I could find no evidence of a timestamp
discrepancy in /usr/src or in the existing system files; furthermore, I
had been running xntpd when I fetched and build world-ed. Finally, I was
able to duplicate this behavior on another machine.

Anyway, I don't understand why a timestamp issue would affect what seems
to be a PATH issue anyway. This error occurred for me in two places:
/usr/src/secure/usr.bin/openssl and /usr/src/secure/lib/libcrypto. All I
had to do was change pod2man to /usr/bin/pod2man in both Makefiles and it
worked.

If I'm missing something, let me know... I would also like to hear if
you are able to duplicate this problem or not. I just think this hasn't
come up too much because not that many people disable compression of man
pages.

-------------------------------------------------------------------------------
Kim Scarborough                                      http://www.unknown.nu/kim/
-------------------------------------------------------------------------------
"Nothing matters very much, and few things matter at all."
                                                               - Arthur Balfour
-------------------------------------------------------------------------------

Comment 6 ru 2002-02-11 17:44:46 UTC

On Sun, Feb 10, 2002 at 09:30:02AM -0800, Kim Scarborough wrote:
> 
>  Can this bug be reopened? I must respectfully dissent from ru's analysis
>  of the problem.
>  
No.

>  I ran into this behavior yesterday when upgrading a machine I had just
>  CVSupped to -STABLE. I've upgraded it many times in the past with no
>  problems, but before building world this time I set "NOMANCOMPRESS=  true"
>  in make.conf and this happened. I could find no evidence of a timestamp
>  discrepancy in /usr/src or in the existing system files; furthermore, I
>  had been running xntpd when I fetched and build world-ed. Finally, I was
>  able to duplicate this behavior on another machine.
>  
Great, then you have two buggy environments.  :-)

>  Anyway, I don't understand why a timestamp issue would affect what seems
>  to be a PATH issue anyway. This error occurred for me in two places:
>  /usr/src/secure/usr.bin/openssl and /usr/src/secure/lib/libcrypto. All I
>  had to do was change pod2man to /usr/bin/pod2man in both Makefiles and it
>  worked.
>  
Because it's not a PATH issue.  Manpages are supposed to be built during
`buildworld' stage, and not the `installworld' stage.  At the time of
INSTALLATION, you should have all the bits ALREADY BUILT UP.

Do you understand how make(1) works?  It rebuilds something if it's not
up-to-date with its "sources".  That's why such problems usually indicate
a problem with either system time, timezone setting, or modification
time on source files.  If the source file has modtime set in the
future, its target will always be considered out-of-date.

>  If I'm missing something, let me know... I would also like to hear if
>  you are able to duplicate this problem or not. I just think this hasn't
>  come up too much because not that many people disable compression of man
>  pages.
>  
No, I can't.  There's an unrelated bug exists in openssl/Makefile;
it doesn't add generated openssl.1 to CLEANFILES.

If you want a further help, please provide additional details, such
as how do you build and install your world.  Note that you should run
buildworld and installworld in the same make(1) environment, e.g.,
if you specify -DNOMANCOMPRESS to installworld, you should also
specify -DNOMANCOMPRESS to buildworld, etc.  Otherwise it will fail.


Cheers,
-- 
Ruslan Ermilov		Sysadmin and DBA,
ru@sunbay.com		Sunbay Software AG,
ru@FreeBSD.org		FreeBSD committer,
+380.652.512.251	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age