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
_______________________________________________
Pkg-clamav-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-clamav-devel
