Tracking local changes in CVS
Dan Peterson
petesea at bigfoot.com
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 "config.h.in", 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:
aclocal
autoconf
autoheader
automake
or some combination of those? When I try to use those as listed above I
get errors when running automake:
configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found.
configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE,
configure.ac: that aclocal.m4 is present in the top-level directory,
configure.ac: and that aclocal.m4 was recently regenerated (using aclocal).
configure.ac: required file `./missing' not found
automake: no `Makefile.am' 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 configure.ac.
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/Makefile.in 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 Makefile.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