[Pkg-clamav-devel] package status for jessie
Scott Kitterman
debian at kitterman.com
Fri Aug 22 07:06:51 UTC 2014
On Friday, August 22, 2014 00:27:03 Andreas Cadhalpun wrote:
> Hi Sebastian,
>
> thanks for this comprehensive TODO list. ;)
>
> 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?
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.
> > - #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.
> > - 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.
> > - the bigeasy branch
> >
> > I plan to merge the changes from that branch into exp around the
> > weekend which should close #636877 and #636881. I am however not sure
> > how we deal with the removal of the file in /etc/default. Any
> > guidelines there or just a rm command somewhere?
>
> This would be good.
> For the conffile removal, have a look at 'man dpkg-maintscript-helper'
> and 'man dh_installdeb'. Creating debian/clamav-milter.maintscript with
> something like the following line should be enough:
> rm_conffile /etc/default/clamav-milter 0.98.5~beta1 clamav-milter
That seems correct. Just doing an rm is not sufficient. Let's get this merged
for the next upload.
> > - systemd
> >
> > Andreas added support systemd support for clamd and freshclam
> > Shouldn't we add something for clamav-milter?
>
> Yes. :)
> The main reason, why I didn't try to do that, was that the clamav-milter
> init script is a bit complex with all that socket group handling and
> files in /etc/default are generally discouraged under systemd...
> But once the bigeasy branch is merged, one could add systemd support for
> clamav-milter.
Then let's move forward on this as well.
> > - 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/
> > - 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.
> > - LFS
> >
> > Andreas added a fast sollution for this and I try to get upstream
> > somehow to accept this. Lintian however reports missing LFS for the
> > experimental build. This is interresting :)
>
> The lintian tag is experimental, likely for a good reason.
> It just checks for some symbols used [2] and the comment there doesn't
> make it any more convincing:
> "List was found by grepping around in /usr/include on an i386 system
> with build-essential installed"
>
> This tag probably has a lot of false positives. But if someone wants to
> check, lintian detects the following symbols in libclamav as non-LFS:
> 108: 00000000 0 FUNC GLOBAL DEFAULT UND __fxstat at GLIBC_2.0 (5)
> 418: 00000000 0 FUNC GLOBAL DEFAULT UND __lxstat at GLIBC_2.0 (5)
> 260: 00000000 0 FUNC GLOBAL DEFAULT UND __xstat at GLIBC_2.0 (5)
> 331: 00000000 0 FUNC GLOBAL DEFAULT UND fopen at GLIBC_2.1 (4)
> 161: 00000000 0 FUNC GLOBAL DEFAULT UND ftruncate at GLIBC_2.0 (5)
> 326: 00000000 0 FUNC GLOBAL DEFAULT UND getrlimit at GLIBC_2.2 (13)
> 365: 00000000 0 FUNC GLOBAL DEFAULT UND lseek at GLIBC_2.0 (14)
> 128: 00000000 0 FUNC GLOBAL DEFAULT UND mmap at GLIBC_2.0 (5)
> 80: 00000000 0 FUNC GLOBAL DEFAULT UND open at GLIBC_2.0 (14)
> 119: 00000000 0 FUNC GLOBAL DEFAULT UND pread at GLIBC_2.2 (7)
> 390: 00000000 0 FUNC GLOBAL DEFAULT UND readdir at GLIBC_2.0 (5)
> 245: 00000000 0 FUNC GLOBAL DEFAULT UND setrlimit at GLIBC_2.2 (13)
> 8: 00000000 0 FUNC GLOBAL DEFAULT UND truncate at GLIBC_2.0 (5)
>
> In libclamunrar:
> 7: 00000000 0 FUNC GLOBAL DEFAULT UND lseek at GLIBC_2.0 (3)
>
> In libclamunrar_iface:
> 7: 00000000 0 FUNC GLOBAL DEFAULT UND lseek at GLIBC_2.0 (4)
> 15: 00000000 0 FUNC GLOBAL DEFAULT UND open at GLIBC_2.0 (4)
>
> In havp:
> 88: 00000000 0 FUNC GLOBAL DEFAULT UND ftruncate at GLIBC_2.0 (3)
> 34: 00000000 0 FUNC GLOBAL DEFAULT UND lseek at GLIBC_2.0 (3)
> 101: 00000000 0 FUNC GLOBAL DEFAULT UND mkstemp at GLIBC_2.0 (3)
> 3: 00000000 0 FUNC GLOBAL DEFAULT UND open at GLIBC_2.0 (3)
>
> > 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.
> > - lintian bugs. doesn't look that tragic: LFS and broken symlinks.
>
> The symlinks should probably just be dropped. For LFS see above.
>
> > havp:
> > - lintian complains about LFS
>
> See above.
>
> > - translate call for debconf
>
> Why? There are no outdated translations.
>
> > - there are five bugs open which don't look that complicated and should
> >
> > be easy to fix.
>
> Probably, if one figures out how to test havp. ;)
>
> > clamtk:
> > - best package ever :) One open bug which marked pending
>
> Even better, an improved version of the fix for this bug is already
> included upstream and will be part of 5.08, which will be released soon.
>
> > - lintian thinks that description is too short.
>
> One can try to extract some more information from the README and add it
> to the description.
>
> > 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).
>
> 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.
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.
> 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.
> - The debian/copyright should be made DEP5 compatible.
Personally, I think this is low priority, but if you want to, certainly go
ahead.
Thanks again for all the work the two of you are putting in on the team.
Debian is definitely better for it.
Scott K
More information about the Pkg-clamav-devel
mailing list