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 <jcowg...@debian.org> wrote: > >> Hi, > >> > >> On 06/08/16 22:58, Nicholas D Steeves wrote: > >>> On 6 August 2016 at 05:12, Sebastian Ramacher <sramac...@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@Base, > >>> _glapi_set_nop_handler@Base, and table_set_noop_handler@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
signature.asc
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers