concerning llibva backport

[Nicholas D Steeves]

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.

Thanks!
Nicholas