[11:10] <bluesabre> Noskcaj ^ (also verified that rebuild fixes the issue)
[13:57] <mlankhorst> infinity: ping?
=== bjf is now known as __bjf
[14:43] <zul> Can I get an archive admin to look at python-osprofiler and python-lxc please?
=== PaulW2U_ is now known as PaulW2U
=== Adri2000_ is now known as Guest60909
=== Trevinho_ is now known as Trevinho
=== psivaa_ is now known as psivaa
=== davmor2_ is now known as davmor2
[16:16] <infinity> mlankhorst: Hey.
[16:17] <mlankhorst> hey
[16:17] <mlankhorst> can you take a look at the ffe's?
=== popey_ is now known as popey
[16:18] <infinity> mlankhorst: Bug number(s)?
[16:19] <infinity> mlankhorst: And do they contain assurances that I'll see upstream point releases before release?
[16:20] <mlankhorst> 1.16 is already released
[16:21] <infinity> mlankhorst: Oh, that was in reference to Mesa.  If there's also an X FFe, give me bugs numbers, please.
[16:21] <mlankhorst> bug 1364003 bug 1359769
[16:21] <ubot2`> Launchpad bug 1364003 in mesa "[FFE] mesa 10.3" [Undecided,New] https://launchpad.net/bugs/1364003
[16:21] <ubot2`> Launchpad bug 1359769 in xorg-server "[FFE] xorg-server 1.16" [Undecided,New] https://launchpad.net/bugs/1359769
[16:21] <ubot93> bug 1364003 in mesa (Ubuntu) "[FFE] mesa 10.3" [Undecided,New] https://launchpad.net/bugs/1364003
[16:21] <ubot93> bug 1359769 in xorg-server (Ubuntu) "[FFE] xorg-server 1.16" [Undecided,New] https://launchpad.net/bugs/1359769
[16:22] <mlankhorst> http://lists.freedesktop.org/archives/mesa-dev/2014-August/066953.html mentions sept 12th
[16:22] <infinity> Why do we have two bots?
[16:22] <mlankhorst> no idea..
[16:22] <apw> two bots of different versions too
[16:24] <infinity> mlankhorst: Right, final release in Sept, will we see a 10.3.1 before utopic ships, though?
[16:25] <infinity> mlankhorst: xorg, I think I'm fine with, iff you're doing a full transition of drivers/etc and if you've made sure the non-free drivers are up to speed.
[16:26] <mlankhorst> yeah
[16:26] <mlankhorst> just fglrx remaining, some free drivers will be dropped due to lack of maintenance, similar to debian
=== kees_ is now known as kees
[16:28] <infinity> mlankhorst: Which free drivers?  Anything people might/should care about?
[16:28] <mlankhorst> no, old stuff like s3
[16:28] <infinity> mlankhorst: (Trivial porting that we're being too lazy to fix, or fundamental breakage?)
[16:28] <mlankhorst> really ancient pre-historic stuff
[16:28] <infinity> Sometimes "unmaintained" just means "it works fine, and just needs minor API porting changes".
[16:29] <infinity> I've never sorted out why "unmaintained" is such a dirty word for stable software.
[16:29] <mlankhorst> in this case it means 'nobody uses it any more' ;-)
[16:29] <mlankhorst> and porting it requires more than a recompile
[16:30] <infinity> mlankhorst: Well, nobody uses it in the sense that there's a replacement (kms + modesetting?), or in that you believe no one should own those cards anymore, so screw 'em if they do?
[16:31] <mlankhorst> in the sense that 'if debian dropped support for it, why should we keep it?'
[16:31] <mlankhorst> we share the stack with them
[16:31] <mlankhorst> and it's very likely those drivers have been broken
[16:31] <mlankhorst> I'm not sure anyone tested since xorg 1.13 (which removed XAA, breaking a lot of them)
[16:31] <infinity> Fair enough.  If Debian gets enough bugs to fix and reintroduce them, are you prepared to follow suit?
[16:32] <mlankhorst> sure
[16:32] <mlankhorst> I'd just syncpackage from debian then
[16:32] <infinity> But yeah, if they're old enough that it seems unlikely people would pair those cards with the CPUs we support (ie: PAE-only i686 and above), we're probably safer than Debian in this regard.
[16:33] <mlankhorst> I've thrown my s3 card out long ago, probably with my cyrix :P
[16:34] <infinity> I assume this is just older S3 cards, not whatever silicon VIA is still pumping out from the same IP?
[16:34] <infinity> Or whoever owns them now.
[16:35] <infinity> Oh, they seem to have spun off independently again.
[16:35] <infinity> They just don't seem to want to die.
[16:36] <mlankhorst> yeah the really old ones
[16:36] <mlankhorst> newer one has -sis or something
[16:37] <infinity> mlankhorst: Alright.  +1 on the xorg thing, then, once the drivers are already and you've tested a fake transition in a PPA.
[16:37] <stgraber> I know some servers were still shipping with some of those crazy old chips, though you don't really care about running X on those anyway ;)
[16:37] <stgraber> we laos had a bunch of older s3 and via on thin clients, but those were VIA CPUs that don't do PAE so they can't boot our current kernel anyway (and are stuck on 12.04)
[16:39] <mlankhorst> not sure why you would run a non-lts kernel on them anyway
=== sil2100_ is now known as sil2100
=== rtg is now known as Guest46668
=== seb128_ is now known as seb128
[16:59] <infinity> mlankhorst: Also, what does "Build fixes to support a gallium megablob" mean for us?
[17:00] <infinity> mlankhorst: Was that something we were hackishly doing as a shared library before, and has that now become easier or harder?
[19:22] <mlankhorst> infinity: we use upstream's attempt
[19:22] <mlankhorst> they have their own megablob now for gallium
[19:23] <mlankhorst> which is smaller than mine
=== Guest91506 is now known as NCommander
=== NCommander is now known as Guest86602
[19:37] <infinity> mlankhorst: Alright, that sounds reasonable then.
[19:38] <infinity> mlankhorst: So, really, just give me a non-fabricated assurance that 10.3.1 is happening before utopic release, cause I don't trust mesa .0 releases (this may change, but not this week...) and you've got your FFe.
[19:39] <infinity> mlankhorst: Or a commitment to watch commits and backport .1-targetted patches to .0 with some fervor.  Obviously better if the work load isn't entirely on you, though.
[20:00] <mlankhorst> ok
[20:01] <mlankhorst> yeah I had a small build regression with -rc2, but it was easy to find and revert :-)
[20:02] <mlankhorst> failed on parallel -j8 build/install
[20:26] <mlankhorst> infinity: if .0 is broken I'll make sure it gets fixed before final release, but I think we should get it sooner rather than later this cycle.
[20:27] <mlankhorst> since I was asked to refresh to mir too, and flip to llvm 3.5 which broke on 10.2 before (although that release doesn't officially support 3.5)
[20:28] <infinity> mlankhorst: Oh, I don't disagree that you should upload ASAP if we plan to use 10.3, my point is that I want to know we won't be shipping 10.3.0 in the final release.
[20:29] <infinity> mlankhorst: Unless this is the first mesa release in history that isn't fundamentally broken on some subset of machines, which I frankly don't believe will be true without widespread testing, which I doubt upstream has ever done, hence the situation. :P
[20:29] <infinity> mlankhorst: So, I'm fine us being guinea pigs, IF 10.3.1 will be out by release, or you backport like a madman from the will-become-10.3.1 branch.
[20:30] <mlankhorst> yeah
[20:30] <mlankhorst> I'll poke the release manager
[20:30]  * ScottK predicts we break kwin again too, since the main upstream developer doesn't test against pre-releases.
[20:30] <mlankhorst> I should really upgrade to trusty sometime soon. :P
[20:31] <infinity> ScottK: Was that a casual FFe veto in passing, or just a note of something we'll need to watch for and potentially fix?
[20:32] <ScottK> It's not a veto.
[20:32] <ScottK> It's a "we should test this before we jump in"
[20:32] <infinity> Kay.  I think the one big argument (ditching llvm 3.4) and medium-sized argument (probably better new hardware support) likely trumps anything else.
[20:33] <infinity> But all for testing. :P
[20:33] <infinity> mlankhorst: Do you have a PPA with 10.3-pre packages that one could, say, build and run KDE against?
[20:34] <ScottK> Socially, it's much better for us to go to kwin upstream and give test results/report bugs before we jump and ask for feedback rather than have him find out with the KDE bugzilla exploads.
[20:34] <infinity> ScottK: Indeed.  Though, I'd also argue it's better for upstreams who rely heavily on other projects to test against their trunks instead of panicking on release day too. ;)
[20:35] <ScottK> Well sure, but the version of KDE we're releasing with is already post-release, so it's a bit late for that.
[20:35] <infinity> Fair point.
[20:36] <ScottK> If we updated mesa in process, rather than late, via FFe, we'd be fine.
[20:37] <mlankhorst> infinity: not sure if I have one right now, building is general fine though
[20:37] <mlankhorst> lets see if I uploaded it to x-staging yet
[20:39] <mlankhorst> Nope, forgot to push the git trees. I'll upload it to x-staging tomorrow.
[23:25] <lool> excuses for ubuntu-system-settings say it's held up waiting for the ubuntu-system-settings-online-accounts to run, but for some reason they aren't running https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/lastBuild/?
[23:25] <lool> I see other recent autopkgtests runs: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-unity-scope-click/lastBuild/?