[Pkg-clamav-devel] Processing of clamav_0.98.4+dfsg-1_i386.changes

Andreas Cadhalpun andreas.cadhalpun at googlemail.com
Wed Jul 2 21:12:01 UTC 2014


Hi Sebastian,

On 02.07.2014 21:43, Sebastian Andrzej Siewior wrote:
> On 2014-07-02 21:03:36 [+0200], Andreas Cadhalpun wrote:
>> On 02.07.2014 20:05, Scott Kitterman wrote:
>>> On July 2, 2014 12:41:00 PM EDT, Andreas Cadhalpun <andreas.cadhalpun at googlemail.com> wrote:
>>>> Indeed, as the sf.net page doesn't work currently, I switched the watch
>>>> file now to github.com. The downsides are:
>>>>   * larger tarball containing more win32 and contrib files
>
> Some of the win32 files are removed by the split script so I wouldn't
> bother. Not sure about the contrib stuff.

Now uscan removes both contrib and win32 directories, so that's not the 
problem. It's rather that the originally downloaded tarball is now 
nearly 40 MB instead of the 15 MB tarball from sourceforge.
There are also various .gitignore files, which would interfere with our 
own usage of git, so I added them to Files-Excluded as well.

The contrib folder contains many things, e.g. a (probably out of date) 
version of our split-tarball.sh. :)

>>>>   * no automatic verification of signatures, as the github tarballs
>>>>     aren't signed
> okay.
>
>>>> When/If sf.net works again, we can switch back.
>>>>
>>>> I added a Files-Excluded field to debian/copyright so that uscan
>>>> automatically removes a lot of useless files. The split-tarball.sh
>>>> script is still needed to extract libclamunrar.
>>>
>>> Since upstream guitar is a copy of the 'real' private git repo, I wonder if we can be sure it'll always match the tarball?
>>
>> Well, currently the tarball from github.com just contains some more files
>> than the tarball from sourceforge.net, which doesn't do any harm.
>
> Seriously? No wonder it takes them so long to create a new release if
> they manually create the tarballs :)

The additional files/directories are:
  * .gitignore files (and a .gitattributes)
  * contrib directory
  * additional Doxygen files
  * config/test-driver
  * libclamav/7z/lzma.diff (not sure what that's for)
  * additional subdirectories in libclamav/c++/llvm
    (but we don't care, as we remove it entirely)
  * libclamav/c++/TODO.CLAMAV
  * libclamav/c++/merge.sh
  * libclamav/c++/strip-llvm.sh
  * libclamav/tomsfastmath/mont/fp_mont_small.i
  * libclamav/tomsfastmath/numtheory/fp_gcd.c
  * libclamav/tomsfastmath/numtheory/fp_isprime.c
  * libclamav/tomsfastmath/numtheory/fp_lcm.c
  * libclamav/tomsfastmath/numtheory/fp_prime_miller_rabin.c
  * libclamav/tomsfastmath/numtheory/fp_prime_random_ex.c
  * libclamav/tomsfastmath/LICENSE
  * llvm directory
  * m4/reorganization/libs/libconfig.m4
  * unit_tests/duma_tests.sh
  * unit_tests/efence_tests.sh
  * unit_tests/valgrind_tests.sh
  * win32/clamav-for-windows (75 MB due to embedded wxWidgets)
  * autojunk.sh

And it doesn't contain:
  * libclamav/version.h

I don't know why they modify their release tarball in this way, but I 
don't think it makes much difference for us.

> I will try ping upstream later about this.

Thanks. Maybe they can sync their repo and their release tarball 
contents a bit more.

> Maybe they can manage to sign their tags.

That would be good, although I don't know if uscan can verify signed 
tags. Or would there be detached signatures on the download page?

> Then we have to worry about the extra files.

I wouldn't worry too much about them.

> Unless ofcourse they host their files on
> clamav.net which would solve the problem once for all :)

If they have the bandwith, this would be best.

>> And as long as sf.net doesn't work, I think this is better than effectively
>> not having a watch file.
>
> Even if the next release makes it t HEAnet, there is no guarantee that
> release after will make it.

Yes, that's true. But is has worked for a lot of releases in the past...

Best regards,
Andreas



More information about the Pkg-clamav-devel mailing list