On Wed, Jul 02, 2003 at 11:09:19AM -0600, Al Stone wrote:
> > +++ oprofile-debian/ReleaseNotes 2003-06-25 11:23:26.000000000
> None of the debian changes have to be in the oprofile
> CVS tree. You could choose to include none of these;
> it's normally considered the responsibility of the debian
> package maintainer to synchronize the CVS tree with any
OK. I'd prefer to keep this part separate then.
> > +dnl AC_TRY_COMPILE([#include <bfd.h>], ,
> > +AC_COMPILE_IFELSE([#include <bfd.h>],
> > Why ? What does this macro do ? It seems undocumented. Does it work
> > with autoconf 2.13 ?
> Using the debian unstable release, AC_TRY_COMPILE was
> reported as being deprecated and that AC_COMPILE_IFELSE
> was to be used instead (autoconf 2.57 and automake 1.7.5).
> That's was why I replaced it. I don't believe it works
> in 2.13; I can go either way on whether it's a necessary
> change or not -- it does keep some warnings out of the
> build of the package.
The warnings should just be ignored until autoconf 2.13 is no longer
> Not that I've been able to come up with yet :(. This
OK doke. Then I guess the file is OK for now.
> The two files -- debian/changelog and ChangeLog serve entirely
> different purposes. The debian/changelog file is meant to
This can go in our tree then.
> > > - KSRC=/lib/modules/`uname -r`/build
> > + KSRC=/usr/src/linux
> > This change is incorrect on any system except a standard Debian one, I
> > suspect ... We cannot default to /usr/src/linux, there is no standard
> > that says it must match the running kernel
> This change goes hand-in-hand with the changes to m4/findkernel.m4.
> The idea was to make this so that regardless of the default, the
> macro would actually test for the existence of the source directories
> and fall back on 'KSRC=/lib/modules/`uname -r`/build' if it had to.
This is the wrong way round for many systems. E.g. on my box, the
existing default /usr/src/linux has *nothing* to do with what kernel
I'm running (found via /lib/modules/`uname -r`/build).
So surely you should check the /lib/modules path first. If the packager
needs to use a different kernel tree, can't they use --with-linux=
./configure option ?