[Pkg-clamav-devel] redo debian/rules with less dh for clamav

[Sebastian Andrzej Siewior]

On 2014-03-22 11:33:07 [+0100], Andreas Cadhalpun wrote:
> Hi,
Hi,

> On 22.03.2014 00:17, Sebastian Andrzej Siewior wrote:
> >On 2014-03-21 17:27:09 [+0100], Andreas Cadhalpun wrote:
> >>Because they are only created, when PO2DEBCONF is yes, which it normally is
> >>not. (I actually don't know, when this will be yes.)
> >
> >Is there an error if it tries to remove files which aren't there?
> 
> The problem is different: These files are not created during build, so if
> they get removed, the build fails.

Now I got this. PO2DEBCONF is a variable which may be set. This makes
sense then. Now I wanted to ask if we could always run PO2DEBCONF but
then I noticed that the master aren't there anymore. Looking at the old
git I must say that the file was never there. So. Who knows more about
this? :)

> >>I build with the old rules file (with added faketime) and compared the
> >>result to the packages build with the new rules file. I didn't find any
> >>fundamental difference, only:
> >>  * DEBIAN/control reads now 'libclamav6 (>= 0.98.1)' instead of 'libclamav6
> >>(>= 0.98.1+dfsg)', thanks to the symbols file.
> >>  * A few bytes in the binaries differ and I can't figure out why.
> >>
> >>Thus I think we can switch to the new debian/rules, assuming it still builds
> >>in oldstable/stable.
> >
> >Great. I'm going to build test it on stable/oldstable on a few
> >architectures and see how it goes.
> 
> It builds fine with wheezy on amd64.

Tested kfreebsd-amd64/wheezy, armel/wheezy, fine.
It doesn't work on squeeze on any architecture. The problem is:

|configure.ac:25: warning: macro `AM_PROG_AR' not found in library
|configure.ac:25: error: possibly undefined macro: AM_PROG_AR
|      If this token and others are legitimate, please use m4_pattern_allow.
|      See the Autoconf documentation.
|autoreconf: /usr/bin/autoconf failed with exit status: 1
|dh_autoreconf: autoreconf -f -i returned exit code 1
|make: *** [build] Error 9

That macro is not available in squeeze's automake version. The current
source there does not execute autoreconf.
That means that is different. The only reason why we do autoreconf in
in the first place is because we purge a few directories
(rar for instance) and need to update Makefile.in files. Would it work
to execute autoreconf as part of the upstream source split and keep it
as a patch?

After I dropped the autoreconf part it built on squeeze-i386.

> Best regards,
> Andreas

Sebastian