[04:14] <Noskcaj> How can we make intel-vaapi-driver migrate to release? It seems to just be waiting for arches that it's not meant to build on
[04:17] <Logan_> I'll take a look
[04:18] <Logan_> usually that doesn't matter unless it built successfully on those architectures before
[04:19] <Logan_> er, that seems like a bug with the excuses
[04:20] <infinity> It's a minor misfeature.  It's not wrong about those packages being out of date.
[04:20] <infinity> But they also happen to be NBS.
[04:20] <infinity> It's hard to determine that because they were arch:all and then disappeared.
[04:20] <Logan_> do they need to be removed?
[04:21] <infinity> Yeah, I'm going to do that.
[04:21] <Logan_> that's what I figured
[04:22] <infinity> Should migrate after the next publisher cycle, but I'll keep an eye out.
[04:22] <Logan_> any reason why it's not showing up in update_output.txt?
[04:27] <infinity> Logan_: Because it failed in the excuses stage.
[04:27] <infinity> Logan_: It's a 2-stage process, if it fails excuses, it's not tried in the output pass.
[04:28] <Logan_> ah
[04:28] <Logan_> I always thought the raw output included excuses as well
[04:28] <infinity> Nope.
[04:28] <infinity> escuses is checking up-to-date, RC bugginess, age (which we don't take into account in Ubuntu), autopkgtests...
[04:29] <infinity> Only when all of that passes do we do the costly installability checks that output represents.
[04:30] <Logan_> gotcha
[05:07] <Logan_> infinity: I feel like it's a hacky solution to use the system libtool (i.e. force the LIBTOOL variable in Makefile.in to libtool rather than @LIBTOOL@), but when I get a version mismatch after autoreconf, it seems to be the only way around it
[05:07] <Logan_> is there a better way to avoid that?
[05:23] <Noskcaj> How can i make lp:debian/hexchat up to date again? (a new bugfix release should be in it)
[09:10] <Noskcaj> Can someone please mass sync the openarena packages?
[11:28] <cjwatson> Noskcaj: maybe but only given a complete list; I'm not going to search
[18:12] <hallyn> desrt: i released 03.31 cgamager w prune.  i cannot safely do kill-and-remove, but i wll do gettasksrecusive wbich will letyouge allpids at once, hup then ksiglill, then reget to verkfy no new forkd, then prune
[18:13]  * hallyn out
[18:18] <nadrimajstor> From the shell, how can I see which configure flags were used for building a particular package? (i.e not the debian/rules but the configure options that were derived from rules)
[18:19] <jtaylor> depends on the package
[18:19] <jtaylor> if you are lucky dpkg-buildflags
[18:19] <jtaylor> otherwise you have to read rules and the buildlog
[18:21] <nadrimajstor> jtaylor: mesa package.
[18:23] <nadrimajstor> jtaylor: I'm trying to follow the rules file but after two screens of config munging back and forth my brain hurts. :D
[18:23] <TJ-> nadrimajstor: There's also pkgconfig entries; "/usr/share/pkgconfig/*"
[18:24] <jtaylor> those should only contain paths
[18:25] <jtaylor> very rarely abi stuff
[18:25] <jtaylor> anything else in there is a bug
[18:27] <nadrimajstor> dpkg-buildflags give me just generic options... pkconfig is mostly empty for me... (and it looks there is stuff that should not be there - will file a bug at ubuntu-mate)
[18:27] <nadrimajstor> So, go to LP, look for build logs?
[18:27] <jtaylor> yes
[18:27] <nadrimajstor> ok
[18:27] <jtaylor> what are you looking for?
[18:28] <nadrimajstor> Does --with-egl-platforms= contain framebuffer (among dri, x11 ...)
[18:28] <jtaylor> that can typically be found in the rules file
[18:32] <nadrimajstor> jtaylor: On the second look... There is no mention of fbdev anywhere in the rules file... Thanks jtaylor
[18:33]  * nadrimajstor off to recompile mesa
[18:33]  * nadrimajstor thinks that apt-get build-dep is a bless :)
[18:34] <jtaylor> then you'll love mk-build-deps -ir :)
[18:35]  * nadrimajstor off to RTFM on mk-build-deps
[18:35] <jtaylor> does the same but allows you to remove all again be removing a meta package it installs
[18:39] <nadrimajstor> jtaylor: Ahaaa.... I got it. :)