[Pkg-clamav-devel] clamav 0.98.5+dfsg-1 packaged

[Andreas Cadhalpun]

Hi Sebastian,

On 20.11.2014 23:59, Sebastian Andrzej Siewior wrote:
> On 2014-11-20 19:49:23 [+0100], Andreas Cadhalpun wrote:
>> In the long term I think LLVM should use pkg-config.
>> Until then the this patch should go upstream.
>
> okay, as written later, I will drop Kevin an Email and ask how he wishes
> to proceed.

Thanks.

>> This reminds me, that we have a rather large number of Debian patches:
>>   * 0001-Change-paths-in-sample-conf-file-to-match-Debian.patch:
>>     Debian specific
>>   * 0002-Add-an-additional-n-after-the-number-in-the-pidfile.patch:
>>     bb#10907, status?
> merged, part of 0.98.6

Good. :)

>>   * 0003-unit_tests-increment-test-timeout-from-40secs-to-5mi.patch:
>>     This should go upstream, possibly with even longer timeout.
>>     (It still timed out for me using qemu to emulate powerpc.)
>
> we can increase it to 30min or even more. The -rc1 failed on SH4 due to
> a timeout. But now I recall that upstream had the same problem and they
> wanted to deal with it somehow. But this did not happen. So let me
> forward it with 30min delay upstream and see what they say.

OK.

>>   * 0004-Fix-compiling-on-Hurd.patch:
>>     This should now go upstream.
> okay.

Forwarded: bb#11200

>>   * 0005-Workaround-a-bug-in-libc-on-Hurd.patch:
>>     This can now be dropped, because #752237 got fixed.
> …
>
>>   * 0006-remove-unnecessary-harmful-flags-from-libclamav.pc.patch:
>>     This should also go upstream.

Forwarded to: bb#11201

> I guess you forward those two (and #4) on your own or do you want me to
> do it?

I've forwarded them myself after verifying that #4 works without #5 now 
and amending #6 by moving @LIBCLAMAV_LIBS@ to Libs.private instead of 
completely removing it, because it is necessary for linking statically.

>>   * 0007-libclamav-use-libmspack.patch:
>>     bb#11062, targeted for 0.98.6
>>   * 0008-Add-upstream-systemd-support-for-clamav-daemon-and-c.patch:
>>     bb#10568, targeted for 0.99
>>   * 0009-fix-ssize_t-size_t-off_t-printf-modifier.patch:
>>     bb#11092, status?
> I don't know anything in particular. But if they take patch #8 they have
> to apply, too.

I see.

>>   * 0010-hardcode-LLVM-linker-flag-because-llvm-config-return.patch:
>>     Should go upstream, see bb#11146.
>
> I try to drop Kevin later an Email an Cc you.

OK.

>>   * 0011-Add-libmspack-library-from-upstream-without-unnecess.patch:
>>     see bb#11062, targeted for 0.98.6
>>   * 0012-allow-to-use-internal-libmspack-if-the-external-is-n.patch:
>>     see bb#11062, targeted for 0.98.6
>>   * 0013-fix-autoreconf-with-embedded-libmspack.patch:
>>     see bb#11062, targeted for 0.98.6
>
> lets hope that :)

Yes. :)

>>   * 0014-remove-AC_CONFIG_SRCDIR-llvm-configure-from-libclama.patch:
>>     This should go upstream, as configure.ac doesn't use LLVM's
>>     configure anymore.

Forwarded to: bb#11202

>>   * 0015-bb-10731-Allow-to-specificy-a-group-for-the-socket-o.patch:
>>     bb#10731, targeted for 0.98.6
>>   * 0016-clamav-milter-add-additinal-SMFIF_-flags-before-invo.patch:
>>     bb#10731, targeted for 0.98.6
>>   * 0017-Bump-.so-version-number.patch:
>>     backported from upstream/master
>>   * 0018-llvm-don-t-use-system-libs.patch:
>>     Should go upstream together with 0010.
>
> All in all it does not look that bad. Most things should get in for next
> .6. But then, they wanted to make a "quick" .6 due to patch #17.

I really think they should use the version numbers better to distinguish 
feature releases from bugfix releases...

>> Due to the current freeze, I'm wondering if I should push changes like
>> dropping 0005-Workaround-a-bug-in-libc-on-Hurd.patch to the unstable branch,
>> or create a new one (experimental?).
>
> Say you create a branch "after-freeze". Can you simply merge it into the
> unstable branch once the freeze is over? I doubt this will work due to
> the way git-dpm works.

It might work, if there were no other changes to the patches in the 
meantime. But we probably shouldn't bet on that.

> So a mental note (or a written one somewhere) would
> be better. In case of this #5 patch, if we can't (or should not) drop it
> I think nobody would mind if you add this "mental note" to the patch
> description.

I've now added a note about removing this patch after the release to my 
TODO list.

Best regards,
Andreas