Hi Andreas! Andreas Henriksson: > Read your bug report (#835533) and spent a few seconds looking at > the gcc6 ftbfs (#811640).
Thanks a lot! > The current ftbfs looks trivial to resolve bit apparently noone > cares enough about the package. OK, this is a useful data point. > Since you mentioned there was upstream activity I looked at how they solved > it in: > https://github.com/ipomoena/dasher/blob/master/Src/Gtk2/DasherAppSettings.cpp#L81 > (Not sure this is the correct upstream repository though.) > This does not look correct at all to me. > [...] > Without investigating any deeper I think this must result in a use-after-free. > We need someone that's interested in dasher to maintain it properly. > Apparently upstream could use an extra pair of eyes to help keep them > safe. Good to know. > This is thus my attempt at suckering you, who have shown atleast > a bit of interest in dasher, to be that person. I'm afraid I cannot be that person, simply because I am mostly illiterate at C/C++. Sorry! But I do appreciate your attempt at fixing the social/organizational problem that's hidden behind the mere surface of FTBFS bug reports :) > If not, the quick route would probably just be to add a patch with > the above suggested solution (which I've verified fixes the build) > and do an NMU to get dasher back into testing. I'll think about it. In theory I could do that, but I'm not keen on "forcing" into a Debian stable release software that 1. will soon be obsolete since upstream has a new major version in the works; 2. gets little care from its formal maintainers. If I did that I would feel responsible to effectively maintain the package in stable (which can imply getting fixes in sid first) during the lifetime of Stretch, which would not be reasonable a commitment to make, even though there are great chances that the maintenance work takes absolutely no time. Should I point the Debian Accessibility team / ML to this bug? Cheers, -- intrigeri