Re: Darkplaces commits
On 22/05/13 14:38, David Bate wrote:
> On the upstream branch,
>
> git diff HEAD HEAD^ | grep -i copyright
>
> returns nothing.
My heuristic is mainly to read the diff looking for "copyright", "(c)",
"©", entirely new files or large chunks of new code. We should look out
for significant pieces of new code in order to check that they're not
non-free - updating the copyright information is a less important, but
more visible, side-effect.
I don't think we are under any obligation to update copyright years in
debian/copyright if upstream didn't add any copyright notices anyway,
but in a game engine where upstream aren't particularly strict about
copyright-tracking, I think it's good to have a best-effort version.
> I have only one remaining issue with d0-blind-id. It is regarding
> hardening (fortified functions of d0-blind-id.so), but I believe that
> it is a false positive (using dh 9, autotools and the other hardening
> options work correctly) but I will check that the flags are correctly
> getting passed.
I will consider d0-blind-id to be on my queue for review and upload,
then; possibly-missing hardening flags are something I can check.
I suspect that d0-blind-id might do so little I/O or memory allocation
(it's just a crypto implementation after all) that it doesn't actually
use any of the "hardened" functions. If blhc indicates that everything
is OK, then don't worry about it. False-positives on that particular
Lintian check seem to be fairly common, particularly in "simple" code
(the D-Bus regression tests are another false positive).
>> Upstream have made actual releases since then
>
> Release - commit
> 0~20121222 - 11867
> 0~20130301 - 11920
> 0~20130304 - 11924
>
> I do not know of the quality of these releases except that, for
> 0~20121222, the release note contains mostly fixes. The other releases
> look like they may be more intrusive. I will investigate.
Thanks! It might be worth pulling at least the first one into experimental?
S
Reply to: