concerning llibva backport

[Nicholas D Steeves]

On Thu, Aug 25, 2016 at 11:26:58PM +0100, James Cowgill wrote:
> 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
> 

Thank you James!

Nicholas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20160826/8e95eec9/attachment.sig>