[RFS] updated libva and intel-vaapi-driver bpos

[Nicholas D Steeves]

On Tue, Nov 22, 2016 at 03:23:27AM +0100, Mattia Rizzolo wrote:
> On Mon, Nov 21, 2016 at 07:31:10PM -0500, Nicholas D Steeves wrote:
> > Proof that they build is here:
> > https://mentors.debian.net/package/libva
> > https://mentors.debian.net/package/intel-vaapi-driver
> 
> bah, no need for mentors (for me at least); I'm very happy to just use
> the git repository.
> 
> > I'm not sure what version of libva mentors builds intel-vaapi-driver
> > against, but it seems to have worked.
> 
> ?
> mentors.d.n doesn't build anything.  What do you mean by that?

Oh!  I've been assuming that the delay between when a package is
uploaded to mentors.d.n and the time it appears under "My Packages"
was because mentors was building the package...  Either way, I won't
bother using mentors.d.n for future bpos of these packages.

> > When I built them locally I
> > built libva first, and copied the debs to my local repo.  The clean
> > jessie pbuilder I use to build these intel-vaapi-driver then pulls in
> > whatever version it needs.
> 
> Yeah, well, the build-dep is very clear on the need of 1.7.3 of libva :)
> In this case I usually test build locally by using the local repo, but
> then upload source only and the have the buildd figure what to do (they
> will not try the build until the needed libva is available).

Oh good, I wasn't sure about this :-)

> > Do you think the mipsel delays from the last run can be used to
> > predict $DELAY for an upload of intel-vaapi-driver to deferred/$DELAY?
> 
> umh, not sure what you mean here?
> Why would we need to do anything to wait for mipsel?

My bad, it skipped my mind that intel-vaapi-driver only builds for
amd64 and i386!

> > The libva version I've requested migrates to testing tomorrow,
> > assuming no bugs are reported in the next however many of hours :-)
> 
> yeah, I'll wait for that to happen before looking at these anyway :P
> I want everything but backports-master chasing after me, that wouldn't
> be nice (also because I saw how bad that could be...).

Sounds good!

Thanks again,
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/20161121/572d3e60/attachment.sig>