concerning llibva backport

[James Cowgill]

On 23/08/16 23:30, Nicholas D Steeves wrote:
> On 7 August 2016 at 09:12, James Cowgill <jcowgill at debian.org> wrote:
>> Hi,
>>
>> On 06/08/16 22:58, Nicholas D Steeves wrote:
>>> On 6 August 2016 at 05:12, Sebastian Ramacher <sramacher at debian.org> wrote:
>>>> On 2016-08-05 16:03:39, Nicholas D Steeves wrote:
>>>>> Hi Sebastian,
>>>>>
>>>>> I did a fresh build of libva-1.7.1-1~bpo+1 today, and noticed that it
>>>>> was building against mesa-10.3.2-1+deb8u1 from Jessie.  I've been
>>>>> testing it on a Jessie+backported mesa-11.1.3-1~bpo8+1, and the
>>>>> packages I've been testing have also been built against mesa-10.3.x.
>>>>> Do you think it's ok to build against mesa 10.3.2, or should we bump
>>>>> the build deps of libva to pull in mesa from jessie-backports.  I'm in
>>>>> favour of bumping the deps asap.
>>>>
>>>> NACK. The mesa build dependency does not matter at all. The only intersting
>>>> thing is libdrm vor intel-vaapi-driver.
>>>>
>>>>> Additionally, I think it would also
>>>>> be wise to bump the intel-vaapi-driver build-depend on libdrm-dev to
>>>>> prevent it from being built against libdrm-2.4.58-2.
>>>>
>>>> This was recently bumped to match the upstream requirement. There is not other
>>>> bumping needed.
>>>>
>>>> Cheers
>>>> --
>>>> Sebastian Ramacher
>>>
>>> So, just to definitively confirm, the following is a non-issue?:
>>>
>>> I found was that in some cases symbols were added, in some cases they
>>> were removed.  In particular I'm concerned with a number of symbols
>>> from libgl1-mesa-glx that were removed in 11.x.  If building against
>>> mesa-10.x makes vaapi use any of these texture, matrix, transform,
>>> shader, or surface symbols then would libva or the intel vaapi driver
>>> misbehave if those functions are not included in mesa 11.x?
>>
>> Mesa (and libGL in general) is a special library which is allowed to
>> remove certain functions without breaking the ABI because all users of
>> those functions are expected to look them up using dlsym and gracefully
>> handle any errors. As far as I can tell, it was mostly obsolete
>> extension functions that were removed in mesa-11.
>>
>>> In years past I've had libvaapi or intel-vaapi-driver compilation fail
>>> because of incompatible texture and (especially!) surface functions.
>>> The Ubuntu convention also seems to be that libvaapi bpo depends on
>>> libmesa bpo ( https://askubuntu.com/questions/758398/ubuntu-14-04-4-lts-enablement-stack-has-unmet-mesa-dev-dependencies
>>> ).
>>
>> I'm not sure the above question has anything to do with libva and I
>> couldn't find any Ubuntu backports of libva when I tried searching.
>>
>>> Back then, I ran into what I believe was this issue when I
>>> privately backported libva to Wheezy, and had to backport libmesa too,
>>> and also had to use debuild instead of a clean chroot.  Symbol files
>>> are attached.  I generated them with using dpkg-deb to unpack the
>>> packages, then dpkg-gensymbols -v1 -plibgl1-mesa-glx
>>> -Plibgl1-mesa-glx_$VERSION -Olibgl1-mesa-glx_$VERSION.symbols
>>>
>>> libglapi-mesa-11.x added _glapi_new_nop_table at Base,
>>> _glapi_set_nop_handler at Base, and table_set_noop_handler at Base, but I
>>> don't recognize those as being relevant to VAAPI.
>>>
>>> Please let me know, I'd prefer to be wrong :-)
>>>
>>> Thank you for taking the time to respond,
>>> Nicholas
>>
>> James
> 
> Thank you for the clarification James!  And sorry for the delay...busy
> period with work.  If there are no remaining issues blocking an
> upload, would someone with the bpo acl please upload and tag backports
> for libva and intel-vaapi-driver?  The backports both are on their
> respective jessie-backports branches.

Uploaded!

James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20160825/a62aaafa/attachment-0001.sig>