Re: port-i386/44306: current NetBSD sources do not build

[Tomasz Motyl <butterfly_tm666%yahoo.com@localhost>]

David Laight <david <at> l8s.co.uk> writes:

> 
> The following reply was made to PR port-i386/44306; it has been noted by 
GNATS.
> 
> From: David Laight <david <at> l8s.co.uk>
> To: gnats-bugs <at> NetBSD.org
> Cc: port-i386-maintainer <at> netbsd.org, gnats-admin <at> netbsd.org,
>       netbsd-bugs <at> netbsd.org
> Subject: Re: port-i386/44306: current NetBSD sources do not build
> Date: Sat, 1 Jan 2011 19:11:38 +0000
> 
>  On Sat, Jan 01, 2011 at 06:35:01PM +0000, basia_i_tomek <at> 
magickgarden.dyndns-server.com wrote:
>  > >Number:         44306
>  > >Category:       port-i386
>  > >Synopsis:       Current sources are not buildable
>  ...
>  > .../external/ibm-public/postfix/lib/dns. Neither cleandir nor objs 
(NOCLEANDIR=yes  ) targets work.
>  > 
>  > Error transcript:
>  > nbmake: "/mnt/modlishka/srcs/external/ibm-
public/postfix/lib/dns/obj/.depend" line 2: Need an operator
>  > nbmake: Fatal errors encountered -- cannot continue
> 
>  You need to look at what is wrong in the .depend file (generated from *.d by
>  make depend). Without knowing the contents (especially line 2) we can't
>  say what is wrong.
> 
>  Neither of the 'clean' options you specified will remove the *.d or .depend
>  files.
> 
>  As a matter of practice it is better to build with all the object files
>  in a completely separate direcory tree - rather than in subdirectories
>  of each directory. Typically you need to front build.sh with something
>  like:
> 
>  base=`(cd ..;/bin/pwd)`
>  machine=i386
> 
>  destdir=$base/dest_$machine
>  objdir=$base/obj_$machine
>  releasedir=$base/release
> 
>  [ -d $objdir ] || mkdir $objdir || exit 1
>  [ -d $destdir ] || mkdir $destdir || exit 1
>  [ -d $releasedir ] || mkdir $releasedir || exit 1
> 
>  exec ./build.sh -u -U -D $destdir -O $objdir -R $releasedir "$@"
> 
>  Then is is very easy to tidy up by just deleting the object tree completely.
> 
>       David
> 
>  -- 
>  David Laight: david <at> l8s.co.uk
> 
> 


Dear David,

I have given it further investigation. It appears that certain chain of 
actions brings one to the mentioned failure:
1. fetch all the *.tgz from ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-
current/tar_files/
2. untar all of them to lets say /mylocation/
3. cd /mylocation/src/
4. cvs update -CAdP .

According to my observations parametres given to the cvs are crucial in here. 
With the high likehood some file is going to get corrupted - a text file being 
intermitted or appended with some binary data. Therefore I manually apply cvs -
C ./somefailing sub-dir/ .
It happens @ random places. After my reporing the thing 
on /mnt/modlishka/srcs/external/ibm-public/postfix/lib/dns/obj/.depend".
It occured after some cvs -CAdP in .../ld/ld.texinfo file in 5.99.43.
I yet do not fully understand the nature of this phenomennon but it does not 
yet mean that the problem does not exist. It might be worth trying to test it 
in the other environment and trying to reprod.
I am aware of the constant development and real time check-ins. It however 
would be improbable to be trapped in-between check-ins for 6 days.
I have isolated the tree for yes - 6 days doing same thing: cvs -CAdP so I 
excluded my fetching some intermediate code-base and performed a different 
action: 'cvs -C' on its copy. The copy has got built succesfully. And here is 
my genuine concern, while there should be no difference between the two.

My version of CVS: 1.12.13 . 


With my best wishes
    Tomasz