Re: Darkplaces commits
At Tue, 21 May 2013 10:31:32 +0100,
Simon McVittie wrote:
> Thanks, I've had some time to look at Darkplaces now, and committed some
> more changes:
Thank you
>
> * when importing new upstream stuff, please at least skim-read/search
> the diff, and watch out for new copyright holders/licenses/etc.
Here I have made a mistake - I think I was too naive. On the
upstream branch,
git diff HEAD HEAD^ | grep -i copyright
returns nothing. With hindsight, knowing that the year changed, it is
clear that there should be a change in the copyright file and so I
should have done something deeper. Should I have checked the commit
logs to update the copyright file?
> * in this particular package, also please watch out for new (ab)uses
> of dlopen() to load shared libraries - for Debian we want them all
> to be either a "real" dependency or never used, I think
Will do.
> I was going to do an upload with your updates + my additional changes,
> but while testing it I found a nasty bug in libsdl1.2 which prevents
> darkplaces from exiting when run on my system
> (<http://bugs.debian.org/708760>). It doesn't seem to be a regression in
> darkplaces, but it's also pretty problematic - if you're running in
> full-screen or the mouse is captured, you can only recover by logging in
> on a text console and killing darkplaces. So, I'm not uploading just
> yet, in the hope that we can sort that out first.
>
> If that bug turns out to only affect pulseaudio/experimental or
> something, then I might upload anyway.
I have not encountered this with pulseaudio/sid, however I too think it is good
to postpone the upload until this problem is fixed rather than panic
whenever pulseaudio migrates.
> Please let me know when d0-blind-id is ready for review. I'll probably
> although if you don't mind me joining the Uploaders,
Of course.
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.
> 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.
> If you (or the Xonotic developers) can encourage LordHavoc to tag
> releases in svn, I'm sure that would make life easier too.
I will try...
David
Reply to: