concerning llibva backport

[Nicholas D Steeves]

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:
>> On 5 August 2016 at 09:43, Sebastian Ramacher <sramacher at debian.org> wrote:
>> > On 2016-07-29 06:40:07, Nicholas D Steeves wrote:
>> >> On 29 July 2016 at 06:28,  <sten-guest at users.alioth.debian.org> wrote:
>> >> > The branch, jessie-backports has been created
>> >> >         at  b40f4e34eed7e6e9f3225aa28f8ac9963d509747 (commit)
>> >> >
>> >> > - Shortlog ------------------------------------------------------------
>> >> > commit b40f4e34eed7e6e9f3225aa28f8ac9963d509747
>> >> > Author: Nicholas D Steeves <nsteeves at gmail.com>
>> >> > Date:   Fri Jul 29 06:25:56 2016 -0400
>> >> >
>> >> >     Backport 1.7.1-1 to Jessie.
>> >> >
>> >>
>> >> I figured out a way to a hack to work around the gbp build failure
>> >> that is fixed in 1.7.1-2 UNRELEASED.  Briefly, in ~/.gbp.conf:  change
>> >> the cleaner line under [DEFAULT] to "cleaner = true" ;-)  Please
>> >> upload the libva bpo and this one simultaneously.
>> >
>> > I'm not in the backports ACL. You'll need another DD to sponsor the upload.
>> >
>> > Cheers
>> > --
>> > Sebastian Ramacher
>>
>> 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?

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
).  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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libgl1-mesa-glx_10.3.2.symbols
Type: application/octet-stream
Size: 38577 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20160806/1ce33fc6/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libgl1-mesa-glx_11.1.3.symbols
Type: application/octet-stream
Size: 33460 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20160806/1ce33fc6/attachment-0003.obj>