[Pkg-clamav-devel] remaining clamav bugs

[Sebastian Andrzej Siewior]

On 2014-06-25 01:54:06 [+0200], Andreas Cadhalpun wrote:
> Hi,
Hi,

> I have been going over the remaining clamav bugs and closed those, which I
> found invalid.
> 
> As I understand it, the situation for the remaining bugs is:
> 
> Forwarded bugs:
>  * #636881: waiting for upstream inclusion
yes
>  * #690788: waiting for upstream reply
>  * #690789: waiting for upstream reply
Those two look similar as both are about web downloads. I asked upstream
to make them public. I have no idea what upstream did here but I guess
nothing. The easiest way to close/fix both is probably to use libcurl
for the download. I just browsed freshclam/manager.c which seems to do
the work here and it looks like they implemented everything (includung
proxy support) more or less from scratch.

>  * #740059: waiting for upstream inclusion
>     None of the forwarded bugs are publicly accessible.
>     So has there been progress on any of them?
>     Maybe we should create an account for the pkg-clamav-devel list and
>     add it to the CC list of all these bugs.
But then you still can't login and comment unless we share a common
login. I just asked upstream to make it public.

>  * #295547: TODO: update patch -> ping upstream
Yes, we could do that. In case nothing happens we could close this since
the reported said he does no loger care.
 
> Outstanding bugs:
>  * #636877: blocked by 636881
So the best case scenario is once we get 636881 fixed, we can think how
we get that files removed on update :)

>  * #675558: TODO: Can clamav be made to use the system libmspack?
oh yes. This looks like fun. I think yes it should work. The purpose /
required functionality is the same.

>  * #393258: Should we split clamdscan from the clamd package and make
>             clamdscan only recommend clamd?
It makes sense for the scenario mentioned.

>  * #530520
The mail mentioned in bug report is probably
http://archives.neohapsis.com/archives/postfix/2008-08/0797.html
It looks 100% harmless. The fix would be either for postfix not to open
a connection before we have the hostname (which makes me wonder why do
we need to resolve the hostname at all). The simpler way would be to drop
the message about host unknown.
We could add a reference to this email explaining the situation, drop
the check (or the resolve of the hostname in case it does not matter)
and see how upstream reacts.

, #529986: What do you think about these?
Sounds usefull however I am not sure how many people care about his. The
popcon stats is quite low. 

>  * #234926: Wait for reply. Without that, close the bug.

He does not care about his anymore, the initial usecase is no longer
valid.
It would be nice to have the same timestamp but it adds actually no
value. If we pull-in libcurl then we get mostlikely the correct
timestamp for the complete cvd file downloads. And the problem remains
probably for the case where the cvd file is an incremental update.
I would say we close this sice Marc no longer cares and the added value
has no meaning to anyone.

> Best regards,
> Andreas

Sebastian