Tracking local changes in CVS

Dan Peterson petesea at
Wed Jun 28 11:07:05 EST 2006

I'm tracking some custom OpenSSH changes (based on 4.3p2) in a local CVS 
repository and have run into a few problems... mainly (I believe) because 
of the .cvsignore files.

Keep in mind the main idea here is to commit the OpenSSH source without 
changes, tag, then add my custom changes and add a new tag.  I can 
probably fix these by making local modes, but I'm just wondering if there 
are specific reasons importing the source without changes doesn't work.

1) .cvsignore includes "configure" and "", which means those 
aren't available when I checkout my imported OpenSSH tree.  Is the 
"standard" approach to use the automake stuff to generate these, ie:


or some combination of those?   When I try to use those as listed above I 
get errors when running automake: no proper invocation of AM_INIT_AUTOMAKE was found. You should verify that invokes AM_INIT_AUTOMAKE, that aclocal.m4 is present in the top-level directory, and that aclocal.m4 was recently regenerated (using aclocal). required file `./missing' not found
    automake: no `' found for any configure output

This is with automake 1.9.5 and autoconf 2.59.

The error appears to be that "AM_INIT_AUTOMAKE" is not in 
Is it supposed to be?

I must admit I had to chuckle at "required file ./missing not found"... 1) 
because "./missing" is required and 2) that "/.missing" was not found. :-)

2) scard/.cvsignore includes "Ssh.bin" AND scard/ has the rule 
for target Ssh.bin commented out.  This means "Ssh.bin" is not checked 
out (since it was never checked in) and it doesn't get generated (without 
uncommenting the section in that is).  This causes problems 
when running "make install" even if "Smartcard" support is disabled.  Is 
there some reason the rule for Ssh.bin is commented out?   And should this 
even be run if Smartcard support is disabled?

3) Ok... this last one isn't really a problem with importing into CVS...

If the --with-privsep-path=DIR configure option is used and the DIR 
doesn't exist when "make tests" is run, then "make tests" will fail. 
Shouldn't "make tests" be trying to use a privsep dir inside the test area 
rather then the REAL privsep dir?   Main problem I see with this is if the 
source is built as someone other then root... which means even if "make 
tests" created it's own privsep dir it wouldn't be owned by root.   In 
that case, would it be possible for "make tests" to skip the privsep tests 
and continue rather then failing all tests?

More information about the openssh-unix-dev mailing list