[00:21] <cjwatson> Laney: Did you have plans for dealing with haskell-platform?  7.4 -> 7.6 is a fairly big change, but it looks like the next upstream platform release is May, so we can't really wait
[00:25] <cjwatson> Laney: Maybe it's best to just not claim to provide the platform when we can't ...
[03:19] <ScottK> infinity or slangasek: If you're around ^^^ is a straightforward backport from upstream that it'd be nice to get in soonish.
[03:20] <infinity> ScottK: Will look when launchpad gets diffy with it.
[03:21] <ScottK> infinity: Thanks.  Diff can also be found at http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/kdepim/diff/260 if you'd rather not wait.
[03:22] <infinity> ScottK: I don't trust reviewed branches to match packages. :P
[03:22] <infinity> (If I'm impatient, I could download and diff, but I'm in no rush)
[03:22] <ScottK> OK.
[03:30] <ScottK> Thanks.
[07:31] <seb128> hey release friends
[07:31] <seb128> could anyone review the indicator stack in the queue?
[07:31] <seb128> (I hoped it would have happened over night and be on today's iso but they are still sitting in there :-()
[08:07] <Laney> cjwatson: I think that could go away and be backported when it appears if we don't see release candidates from upstream
[08:07] <Laney> https://github.com/haskell/haskell-platform/blob/master/haskell-platform.cabal
[08:08] <Laney> impressive effort debugging btw
[08:12] <seb128> Laney, \o/
[08:14] <cjwatson> hmph, not good enough yet to get haskell-conduit/armhf building :-/
[08:14] <cjwatson> ### Error in Data/Conduit.hs:8: expression `runResourceT $ sourceFile "input.txt" $$ sinkFile "output.txt"'
[08:14] <cjwatson> fd:11: hGetLine: end of file
[08:14] <cjwatson> doctests: fd:10: hClose: resource vanished (Broken pipe)
[08:14] <cjwatson> Test suite doctests: FAIL
[08:14] <cjwatson> which at least is different ...
[08:18] <seb128> whoever is reviewing indicators, thanks ;-)
[08:25] <slangasek> seb128: do you know what the story is with 'friends'?  It's an autolanded package with no bugs mentioned at all in the changelog; I'm not confident this is really meant to be going in post-freeze
[08:26] <seb128> slangasek, look at https://code.launchpad.net/~super-friends/friends/trunk
[08:26] <seb128> slangasek, you have the commits between the bot tags
[08:27] <seb128> slangasek, I assume that all the stuff autolanding are landing from the right (stable) vcs
[08:31] <slangasek> seb128: so why did we not get useful changelog entries?
[08:33] <slangasek> these autoland branches are already a pain wrt queue reviews, without me having to hunt down branches besides
[08:33] <slangasek> and really, the commit messages there aren't any more enlightening - I don't see why these are freeze-appropriate changes, it looks like a refactor with no justification given
[08:34] <slangasek> robru: ^^ these seem to be your changes, perhaps you could comment why this should go into raring this late in the cycle?
[08:34] <Laney> You get a changelog entry if the branch is linked to a bug, AIUI. I've previously argued that it should fall back the commit message rather than insert no message, but I didn't win that one.
[08:35] <slangasek> hmph
[08:35] <slangasek> seb128: anyway, all done except for friends
[08:35] <seb128> slangasek, you have 2 options to get a changelog entry
[08:35] <seb128> - edit the changelog with your commit
[08:35] <seb128> - link to a bug
[08:35] <seb128> (either with commit --fixes or by adding a bug reference like (lp: #...)
[08:36] <Daviey> it does seem crackful to maintain a changelog file, for something which is stored in VCS and built automatically.. but what do i know :)
[08:36] <seb128> slangasek, but I agree, that commit/update seems like weakly justified
[08:36] <seb128> it's more a problem with the person who did the commit that with the system though
[08:36] <seb128> slangasek, thanks for reviewing the other ones!
[08:37] <seb128> Laney, issue with "fall back to commit message" is that if your project has translation commits you could end up with 15 "updated translations" entries in the changelog
[08:37] <seb128> and nothing else
[08:37] <slangasek> Daviey: I don't care how the information in the changelog is generated, I just insist that there should be some - in this case it seems the missing changelog is caused by them not being bugfixes
[08:37] <seb128> which is not the end of the world, but suboptimal as well
[08:38] <Daviey> seb128: I thought the recommended way of handling translations was having LP commit to a separate branch, and a single merge commit - when it is suitable for the maintainer of trunk?
[08:39] <didrocks> thanks slangasek for looking at them ;)
[08:39] <didrocks> Laney: see what seb128's told. If you have any commit message, I think this is making a lot of noise for nothing
[08:39] <xnox> seb128: I remember writting hooks that strip "translation commits" but leave the rest in.
[08:39] <didrocks> Laney: but I'm happy to revisit this decision if needed at the sprint/UDS
[08:40] <seb128> Daviey, I'm not sure what's the "recommended" way, but see e.g http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/changes/1572?start_revid=1632
[08:40] <slangasek> didrocks: hey, just trying to clear the deck for my compiz fix to land ;)
[08:40] <seb128> Daviey, 1/3 of that page is "Launchpad automatic translations update."
[08:40] <didrocks> slangasek: ahah, it was interested ;)
[08:40] <infinity> didrocks: Some commits may be "noise" (like "fixed typo from previous commit" or whatever), but there must be a clever way to tag "I want this commit message in the changelog" that isn't always "it must be a bug reference".
[08:40] <didrocks> slangasek: however, the integration tests for the unity stack failed today. I think mterry will have a look once around
[08:40] <seb128> infinity, you can manually add it to the changelog
[08:41] <infinity> didrocks: Cause "I fixed this nasty bug or addeed this cool new feature before anyone noticed or asked for it" is pretty valid for a changelog. :P
[08:41] <infinity> seb128: Okay, but I suspect that feels like duplicate effort, which is why it's not happening.
[08:41] <didrocks> infinity: yeah, what seb128 told, that's why you can reference directly to the changelog
[08:42] <seb128> infinity, suggesting of smarter way to flag commits as "should show in the changelog" are welcome I guess ;-)
[08:42] <didrocks> infinity: I doubt that they will use a tag if they don't care about linking to a bug or adding a changelog entry TBH
[08:42] <seb128> we could add tags in the commit message
[08:42] <seb128> but that would be weird
[08:42] <slangasek> didrocks: bah, thwarted at every turn
[08:42] <seb128> that would add "noise" in the history log
[08:42] <infinity> Works for the kernel team.
[08:42] <Laney> that's what git-dch has you do
[08:42] <slangasek> didrocks: oh that reminds me, why is compiz's test suite not run at package build time?
[08:44] <didrocks> slangasek: probably a leftover of when it didn't run without X (they didn't separate that part). I'll just have a try in a pbuilder right now
[08:44] <slangasek> didrocks: ah, ok.  I'm pretty sure it doesn't need X now, it was running fine for me here
[08:44] <didrocks> slangasek: great, let me have a try quickly ;)
[08:45] <didrocks> well quickly == as fast as compiz will build ;)
[08:46] <Daviey> seb128: Just tried to find where it is documented, and the only references i can find from an official source is because of it's forceful overwriting - which seems weak.
[08:47] <didrocks> Laney: infinity: let's discuss that during the sprint, having upstream on board and knowing why they don't do dch -i or link to a bug report will be useful
[08:47] <didrocks> Laney: infinity: and seeing if another workflow will be easer for them to respect for important changes
[08:47] <didrocks> Laney: infinity: btw, I wrote that and linked them to https://wiki.ubuntu.com/DailyRelease/FAQ#My_name_deserves_to_be_in_the_changelog.21 a while ago
[08:48] <Laney> Sure. I just see empty changelogs fairly often and it's something that I'd like to work to avoid. I know that the process is supposed to block if this happens, but that doesn't always seem to work for whatever reason. :)
[08:48] <cjwatson> Another suggestion: fall back to commit message, but have a way to tag commits as not to be included in the changelog (e.g. "[SILENT]" in the commit message or something)
[08:49] <didrocks> cjwatson: ah, so on by default and off on demand?
[08:49] <cjwatson> Yeah
[08:49] <didrocks> cjwatson: TBH, we tried tag to UNBLOCK merge when being in a freeze a year ago
[08:49] <Laney> Right, with git-dch you put Git-Dch: Ignore in your changelog and it's skipped
[08:49] <didrocks> and most of the time, they forgot to add it
[08:49] <cjwatson> Seems like that would address the "too much noise" problem in the case where it actually bothers people
[08:49] <didrocks> I'm afraid the same thing will happen in a commit
[08:50] <cjwatson> You could for example turn it off centrally for translation processing
[08:50] <infinity> If a trivial commit slips into the changelog, that's not world-ending.
[08:50] <infinity> The inverse is annoying.
[08:50] <Laney> not that it's the end of the world if a few extra entries are added
[08:50] <Laney> ha
[08:50] <didrocks> we can maybe try that, I want first to talk with them about it
[08:51] <didrocks> and see what's the best way to get in
[08:51] <Laney> That or have the merger reject stuff if it's got no commit message
[08:51] <infinity> *nod*
[08:51] <didrocks> Laney: it's already the case
[08:51]  * infinity decides to find a bed.
[08:51] <didrocks> infinity: have a good night :)
[08:52] <Laney> ah, this one was a direct commit to the trunk branch
[08:52] <Laney> is that what shouldn't be done?
[08:52] <infinity> Well, I was going to watch some TV before bed, but pulseaudio now hates me.
[08:52] <didrocks> slangasek: how did you run the tests? I'm getting:
[08:52] <didrocks> /usr/bin/ctest --force-new-ctest-process -j1
[08:52] <didrocks> Test project /tmp/buildd/compiz-0.9.9~daily13.02.28/obj-x86_64-linux-gnu
[08:52] <didrocks> No tests were found!!!
[08:52] <didrocks> Laney: it should never be done, right
[08:53] <Laney> iiiiiiiinteresting
[08:53] <didrocks> robru: kenvandine ^
[08:53] <slangasek> didrocks: ah, did you add the missing build-dep on libxorg-gtest-dev?
[08:53] <slangasek> didrocks: (and enable it in the configure arguments?)
[08:53] <didrocks> slangasek: yeah, it's installed
[08:53] <didrocks> ah, there is a enabling
[08:53] <didrocks> ok, found it
[09:04] <didrocks> slangasek: hum, tests enabled, but nothing. I need to look closer when I've time for it
=== doko_ is now known as doko
=== greyback is now known as greyback|lunch
=== greyback|lunch is now known as greyback
[13:01] <apw> infinity, ^^ is the ftbfs fix for the config issue you spotted, process changed to cover for next time
[14:08] <kenvandine> didrocks, slangasek: i'll make sure merges get rejected without changelog entries or bug references, sorry about that
[14:08] <kenvandine> slangasek, those fixes are pretty important
[14:28] <xnox> kenvandine: didrocks: maybe jenkins should reject branches without bug/ref and/or comments in debian/changelog for "stable" branches (post FFe & for SRU)
[14:42] <kenvandine> xnox, didrocks i'd be fine with that
[14:43] <Laney> didrocks said earlier that it does that
[14:43] <Laney> but this was a direct commit to trunk so no merger was involved
[14:49] <kenvandine> humm.. the fixes i cared about weren't directly committed, but maybe there was some fix direct to trunk
[14:49] <kenvandine> oh, last night
[14:50] <kenvandine> robru pushed the fix for python compatibility for quantal directly to trunk..
[14:51] <kenvandine> ohhhhh.... he's been merging himself after the branches get reviewed
[14:51] <kenvandine> instead of waiting for the merger...
[14:51] <seb128> Laney, no, the merge reject merge requests without a commit message
[14:51] <kenvandine> robru, lets not do that :)
[14:51] <seb128> Laney, there is no requirement for bug reference or debian/changelog entry
[14:51] <seb128> oh maybe I'm wrong
[14:51] <kenvandine> indeed, so that wouldn't help here
[14:52] <kenvandine> i don't think there is anything that rejects without the changelog entry
[14:52] <seb128> right, what I though
[14:52] <Laney> ah ok, well that would be useful then
[14:52] <kenvandine> i've seen plenty of those uploaded with just a snapshot entry
[14:52] <didrocks> kenvandine: it's because upstream is not respecting the deal: for things important, it's either a bug linked or a direct changelog update
[14:52] <Laney> some other merger we have definitely does do that
[14:53] <didrocks> kenvandine: I don't think you want to have every commits listed
[14:53] <Laney> I've had to go back and set commit message before before a merge would be done by a bot
[14:53] <didrocks> and I'm not talking about a feature being merged with hundreds of commits :)
[14:53] <kenvandine> didrocks, then it's hard to decide when there should be something listed
[14:53] <didrocks> Laney: yeah, this is the commit message for bzr
[14:53] <Laney> I mean one on the MP
[14:53] <Laney> which is probably the right level to do it at?
[14:53] <kenvandine> these were all small bug fixes
[14:53] <didrocks> kenvandine: you would prefer to have everything listed?
[14:53] <kenvandine> but not LP bugs for them
[14:54] <Laney> anyway, back to what we said would be a topic for the sprint :P
[14:54] <kenvandine> so the issue is when it is optional,  it'll often get left out
[14:54] <kenvandine> i know our upstreams :)
[14:55] <kenvandine> i do really want the friends update that is in the queue to get through, fixes the dee cache :)
[14:56] <kenvandine> didrocks, i just don't like uploads to the archive with a one line changelog entry  " * Automatic snapshot from revision 179"
[14:58] <Laney> is there a convenient way to fetch the source of copies in the queue? queue can't do it.
[14:59] <cjwatson> Might be worth just teaching queue how
[14:59]  * Laney nods
[14:59] <didrocks> kenvandine: well, that's because of upstream basically, it's like "I don't like upstream not following our guidelines" :)
[14:59] <didrocks> kenvandine: you should lead by example and not have that on friends for instance :p
[14:59] <kenvandine> yeah... i know :)
[14:59] <kenvandine> but you know... none of those were my changes :)
[15:00] <kenvandine> but i did review them... i should have rejected :)
[15:02] <didrocks> right, we have 2 people to ack the change :)
[15:02] <didrocks> I can add the commit message when no bugs is linked
[15:02] <didrocks> but I want upstream to agree first
[15:03] <didrocks> let's see during the sprint
[15:03] <kenvandine> ok
=== didrocks1 is now known as didrocks
=== jbicha_ is now known as jbicha
[15:40] <doko> finally, cython didn't fail for random reasons on armhf ...
[16:23] <ScottK> Laney: dgetlp mostly works if you have the path to othe .dsc.
[16:23] <Laney> ScottK: Yep, but that's the other side of 'convenient' to me.
[16:23] <ScottK> Sure.
[16:24] <Laney> Apparently package_upload objects which are copies don't have a reference to the originating archive
[16:26] <ScottK> Apparently adding branding is a bug fix (ngnix)
[16:26] <ScottK> err nginx
[16:28] <Laney> Bug: there is no branding
[16:28] <Laney> Fix: add branding
[16:28] <kenvandine> hehe
[16:28] <ScottK> I don't think adding (Ubuntu) to the version string for a web server is a great idea.  I'm going to reject it.
[16:35] <jbicha> ScottK: apache on Ubuntu has done that for quite a while, see http://cdimage.ubuntu.com/404 for instance
[16:36] <ScottK> Right, but there are also some significant differences in Debian/Ubuntu on where data files are located and such for Apache, so it's actually relevant to know for troubleshooting.
[16:36] <ScottK> I don't think that's true for nginx, but whatever.
[16:36] <ScottK> If Daviey wants it, he can accept it.
[16:42] <rtg_> infinity, cjwatson: please accept Raring linux-meta with Highbank Q->R upgrade fixes. Vanhoof has the wherewithal to test.
[17:14] <antarus> all hail cjwatson !
[17:44] <dobey> can i bug anyone to look at a couple of UIFe requests please?
[17:45] <infinity> ScottK: Differences between Debian and Ubuntu apache packaging?  Back when I maintained it, the only difference was the branding. :P
[17:46] <ScottK> infinity: Sorry.  I meant Debian/Ubuntu different from the rest of the world, not from each other.
[17:46] <infinity> (And the point of the branding is entirely to hint people who like to do silly "which OS is more popular" statistics gathering).
[17:46] <slangasek> dobey: bugs numbers?
[17:46] <ScottK> infinity: I won't object if someone wants to accept it from rejected.
[17:46] <dobey> slangasek: bug #1151621 and bug #1166356
[17:46] <ubot2> Launchpad bug 1151621 in Ubuntu Software Center stable-5-6 "[UIFe] TypeError when opening edit menu" [Undecided,Triaged] https://launchpad.net/bugs/1151621
[17:46] <ubot2> Launchpad bug 1166356 in rhythmbox-ubuntuone (Ubuntu Quantal) "[UIFe] Old music store interface going away on server" [Undecided,New] https://launchpad.net/bugs/1166356
[18:13] <hallyn> is now a bad time to push a small lxc fix for bug 1166870?
[18:13] <ubot2> Launchpad bug 1166870 in lxc (Ubuntu) "lxc-clone fails silently" [High,In progress] https://launchpad.net/bugs/1166870
[18:17] <hallyn> (FinalBetaFreeze link on https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule leads to nonexistant wiki page0
[18:18] <hallyn> oh, should final beta freeze be taken out of topic, as final beta release should have happened?
=== slangasek changed the topic of #ubuntu-release to: Ubuntu 12.10 and 12.04.2 released | Archive: Frozen for release | Raring Ringtail Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
[18:19] <slangasek> hallyn: done
[18:19] <hallyn> slangasek: so i guess that's a no about uploading lxc? :)
[18:20] <slangasek> hallyn: "frozen" in the sense of "gated", not "immobile"
[18:20] <slangasek> bugfix uploads are still accepted
[18:20] <hallyn> ok thx
[18:27] <slangasek> dobey: I don't understand from bug #1151621 what you're requesting a UIFe on
[18:27] <ubot2> Launchpad bug 1151621 in Ubuntu Software Center stable-5-6 "[UIFe] TypeError when opening edit menu" [Undecided,Triaged] https://launchpad.net/bugs/1151621
[18:28] <slangasek> dobey: UI Freeze governs changes to text strings and window layout that would invalidate documentation, translations, screenshots - fixing a UI bug doesn't need a UIFe
[18:29] <infinity> Well, introducing a UI bug to work around a crash.  But yeah.
[18:29] <infinity> If there are screenshots of people pulling down the Edit menu in software-center, I'd be surprised.
[18:30] <dobey> slangasek: i don't know if it breaks any docs or not. hence the request for a UIFe for people who own docs/translations to say that it doesn't.
[18:31] <dobey> slangasek: my understanding was that all UI changes needed to request freeze exceptions at this point
[18:31] <slangasek> dobey: and bug #1166356 seems to be about an SRU rather than an upload to raring that needs a UIFe?  You've marked the raring task 'fix released'
[18:31] <ubot2> Launchpad bug 1166356 in rhythmbox-ubuntuone (Ubuntu Quantal) "[UIFe] Old music store interface going away on server" [Undecided,New] https://launchpad.net/bugs/1166356
[18:31] <dobey> slangasek: yes, the new version is raring, i want to SRU the new version to quantal/precise
[18:31] <slangasek> dobey: well, you haven't given any information in that bug to /tell/ the docs people what's changing that might impact them
[18:32] <slangasek> I don't see how a crash fix has any impact on docs
[18:32] <dobey> slangasek: because generally docs tend to document the UI, the edit menu of which is one aspect of said UI
[18:33] <infinity> dobey: I appreciate that you're being careful and cautious here.  In this case, probably a bit too much so, that's all. :)
[18:33] <infinity> dobey: If we have application specific docs that tell users all the ways to copy/paste, those docs are probably wrong. :P
[18:33] <slangasek> dobey: ok, on reread I see that the question is about removing one of the menu entries - right, that's reasonable
[18:33] <slangasek> dobey: UIFe approved
[18:34] <dobey> thanks
[18:34] <dobey> and the rhythmbox-ubuntuone one is about removing the UI on quantal/precise as well (it's already gone in raring)
[18:34] <slangasek> dobey: yeah, I think that's fine.. invalidating any screenshots of a UI that needs to go away is the lesser evil
[18:35] <dobey> yeah, i suppose we'll need to drop the screenshot from the 12.04 installer for the next point release
[18:35] <dobey> should i add ubiquity to that bug report?
[18:38] <slangasek> dobey: if there's a screenshot of this in the installer, it'd be in ubiquity-slideshow-ubuntu
[18:38] <dobey> ok
[21:01] <slangasek> balloons, tjaalton; tjaalton, balloons
[21:02] <tjaalton> balloons: yo
[21:02] <tjaalton> balloons: so, I'd need more people to test a new mesa release
[21:02] <tjaalton> which has a FFE bug open
[21:05] <tjaalton> balloons: I sent a CFT to ubuntu-devel@ last friday, but it didn't attract that many people, or they are shy to report success/failure to LP
[21:08] <balloons> tjaalton, hello :-)
[21:08] <balloons> we can certainly organize something for you
[21:09] <tjaalton> balloons: so it's for raring, and available on ppa:ubuntu-x-swat/x-staging
[21:11] <slangasek> balloons: basically, I've told tjaalton just now on #ubuntu-devel that I'm not comfortable accepting mesa in as a freeze exception without some wider testing; do you think it's realistic to gather info on it by next Tue at the latest?
[21:11] <slangasek> we would need assurance that a wide assortment of GPUs still work without regression
[21:12] <slangasek> I would say we'd want evidence from at least 4 different GPU flavors in each of the three families
[21:12] <tjaalton> something like that
[21:12] <balloons> slangasek, we can try -- now is a quite busy time of course, but a week should be enough time to get people testing. 4 different gpu flavors from each of intel, amd, and nvidia yes?
[21:12] <tjaalton> we already have piglit testing done
[21:12] <slangasek> balloons: yse
[21:12] <slangasek> yes
[21:12] <balloons> has this gone into the lab?
[21:13] <balloons> that's your best bet at the moment to get specific testing on different gpus
[21:13] <slangasek> plus some specific spot-checking for regressions on ARM (LLVM?), and spot-checking that it doesn't regress anything in combination with the binary drivers
[21:13] <tjaalton> nope
[21:13] <tjaalton> llvm is still a no-go
[21:13] <tjaalton> on arm
[21:13] <balloons> arm is broken..
[21:13] <balloons> :-(
[21:14] <ogra_> arm image should be fine again and you can at least test swrast
[21:14] <balloons> ogra_, did you fix it?
[21:14] <balloons> maybe I wasn't subbed on the bug, i didn't see anything about a fix
[21:15] <ogra_> nope, mlankhorst did
[21:15] <ogra_> you mean the "black screen after install" one, right ?
[21:15] <balloons> yes
[21:15] <ogra_> yup, a fix went in for that one
[21:16] <slangasek> tjaalton: well, llvm is "too slow to be worth anything for unity" on ARM because it's not ported to NEON... but someone should check in some capacity that LLVM isn't broken
[21:16] <ogra_> bug 1161981
[21:16] <ubot2> Launchpad bug 1161981 in xorg-server (Ubuntu) "Boot stalls after Ubuntu Raring desktop ARM (Panda board) install" [High,Fix released] https://launchpad.net/bugs/1161981
[21:16] <slangasek> maybe just an x86 VM test?
[21:16] <ogra_> balloons, ^^^
[21:16] <ogra_> went in yesterday ... should be fine on todays images
[21:16] <balloons> ogra_, ty.. must not have subbed :-)
[21:16] <tjaalton> slangasek: sure thing
[21:17] <tjaalton> I have a speedy panda for it..
[21:17] <ogra_> heh
[21:17] <ogra_> speedy ...
[21:17]  * ogra_ pets his chromebook
[21:17] <tjaalton> and nexus7 of course
[21:17] <ogra_> yeah, thats for the binary drivers :)
[21:18] <slangasek> so
[21:18] <slangasek> tjaalton: that sound like enough testing to you? :)
[21:18] <tjaalton> slangasek: yeah
[21:19] <balloons> ok, so I missed the response.. Has this been run in the lab tjaalton ?
[21:19] <tjaalton> balloons: nope
[21:22] <balloons> tjaalton, ok, so let's make that happen.. that will be the best thing to do to make sure it passes Steve's feel good test.. and after all you need him to feel good ;-)
[21:22] <balloons> alongside we'll pull community results to
[21:23] <tjaalton> sounds like a plan :)
[21:23] <slangasek> is the lab testing something we should be doing more systematically wrt mesa uploads?
[21:23] <slangasek> seems like a good candidate package for "critical ppa" pre-acceptance testing
[21:24] <slangasek> to at least give you X guys solid data about any possible regressions
[21:25] <balloons> slangasek, I think that's something worth chatting with the qa team about.
[21:25] <tjaalton> yeah
[21:26] <balloons> have them track the xorg-edgers crack ppa or something :-)
[21:26] <slangasek> this is indeed something that should happen
[21:26] <balloons> where's the ffe link btw?
[21:26] <slangasek> I'm surprised that's not already a priority for the lab, but I guess unity regression-testing is more critical
[21:26] <tjaalton> hmm actually there's a graphics test suite of some sorts they should be running when certifying new platforms
[21:26] <tjaalton> or is this the same lab we're talking about?
[21:27] <tjaalton> balloons: https://launchpad.net/bugs/1164093
[21:27] <ubot2> Launchpad bug 1164093 in mesa (Ubuntu) "FFe: new upstream release 9.1.1" [Wishlist,Triaged]
[21:27] <slangasek> tjaalton: different lab
[21:27] <tjaalton> ah
[21:44] <tjaalton> one thing I know the new version fixes is user-switching no longer hangs compiz on intel, like it sometimes does on mesa 9.0.x :)
=== Ursinha-afk is now known as Ursinha
=== elmo__ is now known as elmo
[22:24] <slangasek> cyphermox_: huh, so this nm upload only changes the test suite?
[22:24] <slangasek> I guess that's a pretty safe change
[23:35] <cyphermox_> slangasek: yeah, only adds tests