Re: libvpx transition
On 15/05/15 16:52, Emilio Pozuelo Monfort wrote:
> On 15/05/15 16:30, Sebastian Dröge wrote:
>> Hi Emilio,
>> I indeed forgot that, sorry!
>> On Fr, 2015-05-15 at 16:21 +0200, Emilio Pozuelo Monfort wrote:
>>> Hi Sebastian,
>>> There's an uncoordinated transition for libvpx in unstable. I suppose you didn't
>>> remember the soname had changed when re-uploading to unstable now that the
>>> freeze is over. It affects a few of packages and I do wonder whether the rdeps
>>> will build just fine or not. I saw this and shows that a few symbols were
>>> removed, but I don't know if that affects our rdeps.
>> All recent rdeps should build fine against the new version of the
>> library. The removed symbols shouldn't be used by anything (at least I'm
>> not aware of any user), the bigger problem is that some compatibility
>> #defines disappeared from the headers.
>> But I expect everything recent to build just fine. The only thing that
>> probably doesn't is gst-plugins-bad0.10, but that one should really just
>> die and disappear from the archive.
>>> Can you check if the rdeps are fine, so we can schedule binNMUs if appropriate?
>> Please schedule binNMUs for everything except gst-plugins-bad0.10, that
>> will have to be patched a little. If any of the binNMUs fails for
>> whatever reason, patching the packages should be a matter of sed (I'll
>> check then).
> Great, I have scheduled the binNMUs. Let's see how things go.
libgd2 and icedove fail to build because of libvpx. I've filed bugs for both.
iceweasel failed to build for seemingly unrelated reasons (and with old libvpx).
gst-plugins-bad0.10 needs an upload.