[Pkg-clamav-devel] package status for jessie

Fri Aug 22 20:37:25 UTC 2014

Hi,

On 22.08.2014 09:06, Scott Kitterman wrote:
> On Friday, August 22, 2014 00:27:03 Andreas Cadhalpun wrote:
>> On 21.08.2014 22:07, Sebastian Andrzej Siewior wrote:
>>> clamav:
>>> - oldstable reference
>>>
>>>     The rules file for has still the parts from oldstable. Shouldn't we
>>>     drop oldstable support?
>>
>> As the init scripts don't work correctly in oldstable anymore, I think
>> we should remove this oldstable support also from debian/rules.
>
> What is it that doesn't work?

The status, reload-database and reload-log actions of the init scripts 
use command line options (start-stop-daemon --status and pkill -F), 
which are not present in squeeze. Therefore clamav-daemon depends on 
dpkg (>= 1.16.1) and procps (>= 1:3.3.2).

This had been much much worse before 0.98.4+dfsg-2, because the 
freshclam init script had used 'pkill -0 -F' unconditionally (and 
unnecessarily) and thus failed always in squeeze.

> I would also like to make it easy to support Ubuntu 10.04 since it has 8
> months of support time left.  Leaving the ability to use the embedded llvm and
> some of the other oldstable things makes that easier.  I'd prefer to leave it
> as is unless it's blocking other work.  Also, since there is the Squeeze LTS
> project ongoing I wouldn't want to complicate their work further should they
> want to update the package.

OK, so let's keep it a bit longer.
To make it easier for old versions, 'start-stop-daemon --status' could 
be replaced with status_of_proc, but I don't know of a good replacement 
for 'pkill -F'. Probably it's easiest to just remove the '-F' option 
when backporting.

>>> - #393258
>>>
>>>     Andreas suggested to split clamdscan out of the clamav package so it
>>>     could be installed without freshclam. It was dropped first due to the
>>>     large NEW queue. What about it for next exp release (i.e. before the
>>>     final release)?
>>
>> Yes, we could do that. In case it is still in the NEW queue, when the
>> final release happens, we can always upload that without the split to
>> unstable, canceling the experimental upload.
>
> Yes.  Now is a good time for this.

I think that clamav-daemon should recommend the new clamdscan package 
(to keep the same functionality present on upgrade), but the clamdscan 
package should only suggest clamav-daemon, so that it is not 
automatically installed with it.

>>> - clamav-data
>>>
>>>     what about the obsolete clamav-data package? It is not shipped anymore
>>>     and last release was in oldstable. Shouldn't we drop any reference to
>>>     it?
>>
>> Does anyone know, why it is not shipped anymore? The removal bug #612196
>> contains very little information...
>> But unless someone wants to bring it back, we should drop all references
>> to it.
>
> When it was shipped, it was autogenerated.  There were some policy changes
> that made this difficult to do, so the maintainer gave up on it.  I don't recall
> all the details.  There are deployments that do not have direct internet
> access, so I think it's good to leave this alternate depends in so that end
> users can roll their own clamav-data package if needed.

In my opinion a clamav-data package in the Debian archive doesn't make 
much sense, because it will get horribly outdated, once it is in a 
stable release.
I can see the use-case you mention, but it doesn't help much, as there 
is no easy way to create a clamav-data package and thus end users can't 
really create their own.
So I think we should reintroduce the clamav-getfiles package, which was 
removed, because it was RC buggy and unmaintained (#649848). But if we 
don't do that, I think we shouldn't have clamav-data in the dependencies.

>>> - check libclamunrar + havp + friends (exp build)
>>>
>>>     if it still works after the LFS change.
>>
>> I think these should still work, but checking wouldn't hurt.
>> But I'm not sure how to test havp. Does someone know how to setup a test
>> instance for it? (Probably it's documented somewhere, but ...)
>
> havp is probably a good candidate for an autopkgtest, because it does take
> some work to set up manually, but I'm unlikely to have time to work on it in
> the next few weeks.  It looks like it's not so hard:
>
> http://www.rasyid.net/2008/12/11/install-havp-http-antivirus-proxy-in-freebsd-71/

Thanks for the link. When I read it, I noticed that the havp package in 
Debian does all that already. ;)
The only thing one has to do is to configure the system http proxy to 
point at the havp instance, e.g. localhost:8080, when run on the same 
computer.

I tried to download Eicar [1] and it was properly intercepted by havp.
So at least havp still works.

>>> - the zlib lintian issue
>>>
>>>     we identified that clamav uses somekind of "extended" deflate
>>>     algorithm which is not provided by zlib. I guess we should look into
>>>     this but it doesn't look that important, does it?
>>
>> I would say it is about as important as the libmspack bug was, i.e.
>> normal severity in the BTS categories. The only difference is that we
>> can't fix it on the clamav side, without the 64-bit functions in zlib
>> (#308799), which are unlikely to be added [1].
>
> I think the goal here should be to energize the clamav devs to try and
> upstream their changes into zlib.  Not much we can do, as you say.

Indeed, that's probably the only solution.

>>> libclamunrar:
>>> - update to 0.98.5 while doing
>>
>> Did anything change in libclamunrar?
>
> Once we get the final, it'd be nice to make the versions match.

OK.

>>> Anything else that should be added?
>
> There is a separate upstream source for a KDE menu based scanning:
>
> https://bitbucket.org/dave_theunsub/clamtk-kde/downloads/clamtk-kde-0.16.tar.gz
>
> It is so trivial, I think we ought to consider adding it to the existing
> clamtk package rather than making a new source package for it.  I don't think
> it needs a new binary package as it can be installed and if the appropriate
> KDE packages aren't installed, it will just never be used (unlike the nautilus
> plugin that would have necessarily dragged in half of Gnome).

This seems to be so trivial, that I wonder, why the clamtk tarball 
doesn't include the clamtk-kde.desktop [2]. I think we should ask Dave 
to add it in the next release, so that it will be easy for us to install 
it. The icons are already present (and the clamtk-kde man page is anyway 
not very informative).

>> clamav:
>>    - We should probably get rid of the PO2DEBCONF part in clamav's
>>      debian/rules, as it is now no longer needed (I think).
>>    - The bugs #529986 and #530520 should be dealt with.
>
> For #529986, I don't think we should do that in Debian.  Either upstream
> should do it, or it should not be done at all.  I'm personally not in favor of
> dropping in place of rejection because it makes the mail system less reliable.
> There are also jurisdictions where it's not legal.

In that case it's probably best to close this bug as wontfix.

> Resolving #530520 would be nice.  If there's a low risk patch, I don't mind us
> doing it first, but we ought to make sure upstream will eventually take the
> patch.

OK.

>> havp:
>>    - There is still a havp.templates.master in havp, but template
>>      translations seem to be handled differently nowadays, which is
>>      probably also the cause for the untranslatable-debconf-templates
>>      lintian error.
>
> Yes.  I believe this is the case, but how this is done always escapes me.
> Perhaps we can find someone who actually works on translations to look at it.

I think I got it now: havp.templates is what is shipped in the binary 
packages and nowadays created during the build process. Therefore I 
removed it and renamed havp.templates.master to havp.templates.
The lintian errors are gone now and the binary still contains the 
translations, so it should be fine.

Best regards,
Andreas

1: http://www.eicar.org/download/eicar.com
2: 
https://bitbucket.org/dave_theunsub/clamtk-kde/src/e8176f82dcc9ce34faaad81dd22cebef845dc06a/clamtk-kde.desktop?at=master