[05:40] <jhesketh> Hi There. Is this a good place to ask a few questions about the flow through ubiquity -> lightdm -> unity?
[08:29] <sil2100> Anyone here running most recent precise, unity 3D with a free moment of time to perform 2 small manual tests?
[08:30] <MCR1> sil2100: sry, on quantal already...
[08:31] <sil2100> MCR1: hm, quantal normal or quantal-proposed?
[08:31] <MCR1> normal with additional ppas
[08:31] <MCR1> I fear proposed ;)
[08:31] <sil2100> MCR1: but unity is from quantal, yes?
[08:31] <MCR1> no, from the staging PPA
[08:31] <sil2100> MCR1: good that you do! quantal-proposed is a risky game!
[08:32] <sil2100> MCR1: what version of unity is it?
[08:32] <MCR1> sil2100: 5.12+bzr2470ubuntu0+724
[08:33] <sil2100> MCR1: thanks, well, I need someone with a smaller version
[08:33] <sil2100> seb128: do you have a spare minute?
[08:33] <sil2100> seb128: (hi btw.)
[08:34] <seb128> sil2100, hey, yes
[08:34] <sil2100> seb128: you're running precise, yes?
[08:35] <sil2100> seb128: since I need 2 tests confirmed from someone running 5.12 - could you open the HUD, press Alt+F1 and tell me if you enter navigation mode on the Launcher?
[08:36] <didrocks> sil2100: it doesn't
[08:36] <didrocks> sil2100: there is a merge in trunk which is supposed to fix it :)
[08:37] <didrocks> (and a AP test as well IIRC)
[08:37] <sil2100> didrocks: it doesn't enter?
[08:37] <didrocks> yep
[08:37] <sil2100> didrocks: what's the desirable effect?
[08:37] <didrocks> entering the launcher keyboard navigation mode I think
[08:37] <didrocks> which is what the branch was supposed to do
[08:38] <sil2100> didrocks: since we have an autopilot test failing (both in AP and in manual-testing) which says it SHOULDN'T, but does
[08:38] <didrocks> hum?
[08:38] <sil2100> """Pressing Alt+F1 when the HUD is open must not start keyboard navigation mode."""
[08:38] <didrocks> ah HUD
[08:38] <didrocks> not dash
[08:38] <sil2100> This is the comment on the autopilot test
[08:38] <didrocks> sil2100: ok, then, please check with them
[08:39] <didrocks> it doesn't in dash and HUD on previous version
[08:39] <didrocks> I misread the merge then and thought the opposite was wanted
[08:39] <sil2100> So it's an regression?
[08:39] <didrocks> yeah
[08:41] <seb128> sil2100, it doesn't go in navigation mode
[08:42] <seb128> it seems weird that the hud and dash are supposed to behave differently
[08:42] <seb128> could be worth checking with design?
[08:43] <MCR1> Anyone an idea how we could fix that one: bug 1017550 ?
[08:43] <sil2100> seb128: I have some strange autopilot tests here... so keynav mode should work when dash is opened?
[08:45] <sil2100> JohnLea: hello, are you around?
[08:47] <seb128> sil2100, I'm not sure, best to check with JohnLea
[08:54] <JohnLea> sil2100, seb128 ; hi, I'm back, what's the question?
[08:55] <sil2100> JohnLea: hi, I'd like to ask a bit about the keynav behavior during dash and HUD
[08:55] <sil2100> JohnLea: when the HUD or the Dash are opened, what should Alt+F1 do?
[08:55] <sil2100> By design?
[08:57] <JohnLea> sil2100, seb128; close the Dash/HUD and open the Launcher keyboard navigation I think
[08:58] <sil2100> JohnLea: oh, that would actually make sense - but we have some autopilot tests in unity that say that it should be the opposite
[08:58] <sil2100> And that it shouldn't start keynav mode when in dash or HUD
[08:58] <JohnLea> sil2100; strange, I don't think that request came from us in design
[08:59] <didrocks> http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/2457
[08:59] <sil2100> JohnLea: ok, thanks - I'll try to find the person who made the AP and ask why they added this
[08:59] <JohnLea> sil2100; I think the tests are bugby ;-)
[08:59] <didrocks>         """This test when Alt+F1 is activated it must close the dash."""
[08:59] <didrocks> so the dash is fine, it was the MR I was referring to
[08:59] <sil2100> didrocks: ok
[09:00] <didrocks> sil2100: you mean, there is an opposite one for the HUD?
[09:00] <sil2100> didrocks: still need to bzr blame the person who added: """Pressing Alt+F1 when the HUD is open must not start keyboard navigation mode."""
[09:00] <didrocks> sil2100: yeah ;)
[09:00] <sil2100> didrocks: test called test_disabled_alt_f1 in test_hud.py
[09:00] <sil2100> didrocks: the same for test: """When switching from the hud to the dash alt+f1 is disabled."""
[09:00] <didrocks> sil2100: so basically, bother (HUD/dash) enters navigation mode, right?
[09:01] <didrocks> sil2100: it seems only the test has to be fixed for the HUD to test the fact that you enter navigation mode?
[09:01] <sil2100> didrocks: yes, both enter keynav mode
[09:01] <sil2100> didrocks: so the tests are probably invalid
[09:01] <didrocks> yeah, seems so
[09:01] <sil2100> didrocks: since alt+f1 for both dash and HUD in unity 6.0 enter keynav mode
[09:01] <didrocks> which is what is wanted, good, yeah bzr blame is your friend here :)
[09:01] <sil2100> didrocks: when in HUD, well, the hud is not hidden, but keynav mode works!
[09:02] <didrocks> sil2100: hum
[09:02] <sil2100> didrocks: so it's partially fixed ;p
[09:02] <didrocks> sil2100: it should do the same for both
[09:02] <didrocks> otherwise, it's confusing :)
[09:02] <sil2100> didrocks: yes, I presume ;)
[09:03] <sil2100> It seems as if brandon added this test..?
[09:03] <sil2100> Will have to discuss this with him when he's online
[09:04] <didrocks> yep
[09:24] <MCR1> smspillaz: Hi :) Is it more or less safe to use your new experimental Compiz PPA or is it rather not recommended to use it ?
[09:42] <smspillaz> MCR1: I'm still trying to get it building
[09:42] <smspillaz> MCR1: lots of things will be broken, there are a lot of plugins which have not been (and will not be in the near future) ported to the new API
[09:43] <smspillaz> when I say "lots of things" I mean "lots of things" if you extend beyond the default ubuntu usecase
[09:45] <MCR1> smspillaz: Thx 4 the info. I think I understand.
[09:45]  * MCR1 is removing the PPA from the sources...
[10:01] <smspillaz> MCR1: that being said, if you're feeling adventerous and want to help development, you can test whats in https://code.launchpad.net/~smspillaz/+archive/compiz-experimental/ and report bugs (tagged with 'gles')
[10:01] <smspillaz> I haven't been able to test it yet myself
[10:08] <MCR1> smspillaz: I just downgraded ;), but ofc. I will help with testing and reporting bugs, but not today anymore (not enough time)...
[10:10] <sil2100> didrocks: remember the problem I had with merge-upstream in libunity? (and why essentially I had to remove your unreleased version to re-add it later)?
[10:10] <sil2100> didrocks: the thing with merge-upstream throwing a python error that revision is not found
[10:10] <sil2100> didrocks: it seems to be the case because libunity ubuntu branch is in a bit of a mess-state
[10:11] <sil2100> The 5.90.0 version (UNRELEASED) wasn't properly imported with merge-upstream
[10:11] <sil2100> So, in fact, the lp:ubuntu/libunity tree doesn't have the upstream-5.90.0 tag pointing anywhere
[10:12] <sil2100> Because there is no merge for it
[10:13] <sil2100> didrocks: so when I try importing a new tarball, bzr merge-upstream wants to have a starting point from the last tarball import (5.90.0) - but can't find the revision there
[10:13] <sil2100> didrocks: since upstream-5.90.0 = ?
[10:14] <sil2100> didrocks: you can even see that through bzr vis that something's _wrong_
[10:16] <smspillaz> MCR1: sure np
[10:17] <MCR1> smspillaz: I guess it would be best to test this with some standard config, yes ? I mean without all the additional Compiz stuff I have up and running here ?
[10:18] <smspillaz> MCR1: it will work fine, but some things just won't work that's all
[10:19] <smspillaz> I don't *think* it will try and load anything built against the old abi
[10:20] <MCR1> smspillaz: Ok, since I often had the problem of Compiz not even starting when using my config... (Compiz updates keep me nervous all the time until the new boot is finished)
[10:21] <MCR1> smspillaz: Probably it would be wise to have a fresh Quantal installation on some partition just for tests of that kind...
[10:23] <smspillaz> MCR1: you'll need Quantal for this anwyays
[10:23] <smspillaz> *anyways
[10:23] <smspillaz> unity is depending on nux 3.0
[10:24] <sil2100> ...after the unity 6.0 release is done!
[10:24] <sil2100> :)
[10:26]  * smspillaz twiddles thumbs waiting for unity to build on the buildbots
[10:26] <MCR1> smspillaz: Sure, I will setup a new installation of Quantal and run the (manual) tests then - I will do it on Monday... (weekend==girlfriend&&partyparty) ;)
[10:26] <smspillaz> no problem have fun
[10:27] <c10ud> smspillaz, MCR1, as i was discussing with didrocks yesterday, nux3 and unity6 is possible in Precise
[10:27] <c10ud> ofcoure it is unsupported and such stuff, but still possible
[10:27] <c10ud> i have a few issues getting unity to build in a ppa, but locally it built and it's all good
[10:28] <smspillaz> c10ud: it might be. I think unity 6.0 and nux 3.0 are depending on boost1.49
[10:28] <smspillaz> but they might just be using functionality shared by boost1.46
[10:28] <c10ud> looks like they do, i'm running them right now
[10:28] <smspillaz> figures
[10:29] <smspillaz> I wouldn't be able to tell on my precise installation since I build a lot of things from source
[10:29] <c10ud> heh
[10:29] <smspillaz> glib, Xorg, kernel, unity, compiz, gnome, mesa etc
[10:30] <smspillaz> its hardly stable but who cares about /that/
[10:37] <didrocks> smspillaz: you need to use -r -1
[10:37] <didrocks> as I typed on the example :)
[10:38] <didrocks> sil2100: yeah, libunity case is different, right :)
[10:38] <didrocks> sil2100: please still get a real changelog :)
[10:38] <smspillaz> didrocks: -r -1 ?
[10:38] <smspillaz> didrocks: was this about the automerger ?
[10:38] <didrocks> oupss, it was for sil2100 :)
[10:38] <smspillaz> oh ok
[10:38] <smspillaz> didrocks: while you're here ...
[10:38] <sil2100> didrocks: will do! But I'll still have to, sadly, remove the last changelog entry and re-add it with the new version (but with the proper committer ;p)
[10:38] <smspillaz> didrocks: is compiz in freeze? automerger seems to be doing nothing
[10:39] <didrocks> smspillaz: yep :)
[10:39] <didrocks> smspillaz: yeah
[10:39] <smspillaz> kk
[10:39] <didrocks> smspillaz: see the email about the freeze, even if sil2100 never confirmed it was frozen on the ML
[10:39] <smspillaz> yeah I thought we were doing compiz a little later. oh well
[10:40]  * didrocks takes a shower now that the running-under-the-rain is done :)
[10:40] <smspillaz> heh
[10:40] <didrocks> smspillaz: you should UNBLOCK the test for gsettings
[10:40] <didrocks> and all changes related to it
[10:40] <didrocks> Mirv will have to redo the packaging anyway
[10:40] <sil2100> Well, I only wanted to freeze the unity trunk, without compiz!
[10:40] <didrocks> because he didn't go to all merge request to see that some tests were missing :)
[10:40] <sil2100> I think Mirv asked for a compiz freeze ;)
[10:41] <didrocks> always ensuring that the criterias are met is a must :)
[10:41] <didrocks> or you would make rick and distro unhappy ;)
[10:41] <didrocks> real shower now, really needed ;)
[10:55] <sil2100> mhr3_: in the new libunity you guys removed some symbols, mostly related to previews
[10:55] <sil2100> mhr3_: this was the cause of an ABI break that we had recently?
[10:56] <sil2100> hm, wait, actually I see those symbols were only in 5.90.0
[10:56] <sil2100> Which wasn't released
[10:56] <sil2100> didrocks: what should I write in the changelog in this case?
[10:57] <sil2100> didrocks: some symbols got removed, but only symbols with 5.90.0 version number - which didn't get 'officially' released
[10:57] <didrocks> sil2100: no, it's fine, previews were never released
[10:57] <sil2100> didrocks: should I note that some symbols from 5.90.0 got removed?
[10:57] <didrocks> so fine :)
[10:57] <didrocks> juts updated symbols
[10:58] <didrocks> that's it
[10:58] <sil2100> didrocks: ok, thanks
[10:58] <didrocks> nothing else :)
[10:58] <didrocks> yw
[11:01] <MCR1> gotta go. c ya. :)
[11:07] <sil2100> didrocks: for lenses, I should also use the Breaks: tag pointing to new unity?
[11:07] <sil2100> I mean, to old unity
[11:07] <didrocks> sil2100: indeed
[11:07] <didrocks> well << newversion
[11:07] <didrocks> as I did
[11:07] <sil2100> didrocks: ACK :)
[11:09] <sil2100> didrocks: actually, in unity packaging you did << 6.0.0, but actually we're not releasing 6.0.0 versions for the application and files lens
[11:09] <sil2100> The video lens also has different versioning
[11:09] <sil2100> didrocks: is that still correct?
[11:10] <Mirv> compiz would be working with the gsettings backend and testable via https://launchpad.net/~timo-jyrinki/+archive/prerelease-unity60/+packages
[11:10] <Mirv> if it will be unfrozen for adding tests (?) then fine, but the bzr3278 is now testable
[11:10] <didrocks> sil2100: oh? I gues you were
[11:11] <didrocks> guess*
[11:11] <didrocks> didn't we standardize in version 6 for everything?
[11:11] <didrocks> including lenses
[11:11] <didrocks> oh we backport them, right :)
[11:11] <didrocks> sil2100: for those we do backport, please fix the versionning
[11:11] <didrocks> Mirv: we will need to snapshot a newer version
[11:12] <didrocks> Mirv: keeping the freeze but UNBLOCK the merges for tests
[11:12] <didrocks> as we can't release without that
[11:12] <sil2100> didrocks: ACK, I'll fix that up
[11:12] <didrocks> thanks sil2100
[11:13] <Mirv> didrocks: ok, so waiting for the merge to trunk and then I'll rework the packaging accordingly
[11:14] <didrocks> yep :)
[11:14] <didrocks> Mirv: you are doing a tarball for the snapshot, right?
[11:16] <Mirv> didrocks: yes
[11:16] <sil2100> didrocks: oh! And I even see the thing you were talking about during the sprint - the unity-lens-applications package has Breaks: ula (<< 0.4.0), but we can remove that right? Since quantal doesn't offer smaller versions than 5.12, right ;)?
[11:16] <sil2100> So I can remove the Replaces and Breaks parts for ula previous? ;)
[11:17] <sil2100> (or, so called unity-place-applications)
[11:18] <didrocks> sil2100: yeah, you can clean that now
[11:18] <didrocks> as place doesn't exist anymore
[12:01] <sil2100> didrocks: I'm fixing up unity-2d for the new release now - in dependencies, should I add something like 'libunity-core-5.0 OR libunity-core-6.0' or just enforce using 6.0?
[12:01] <Klap-in> hi people! for bug 904205 the fix is merged in devel, what's the way to get it in precise?
[12:02] <didrocks> sil2100: no, just use 6.0
[12:02] <didrocks> Klap-in: we will backport important fixes in compiz trunk to precise next week
[12:04] <sil2100> didrocks: ok, done - I'll also push it upstream as a MRQ, since upstream needs to rebuild against the new nux and unity as well
[12:05] <didrocks> yep
[12:07] <Klap-in> ok, so at that moment also inclusion of that fix will be reviewed? or is it also helpfull to propose it somewhere in the sytem?
[12:07] <didrocks> Klap-in: no, we will review all commits in trunk
[12:08] <didrocks> and see if it's safe enough to backport it to precise or not
[12:11] <Klap-in> ok, nice. Then i will look forward to the review.
[12:38] <c10ud> new unity really brings an uber speedup
[12:38] <c10ud> never been able to get 60fps in a wine-gl game
[12:49] <sil2100> didrocks: hm, should we add a Replaces: libunity-core-5.0-5 for libunity-core-6.0-5 in debian/control?
[12:49] <didrocks> sil2100: why would we need that?
[12:50] <didrocks> c10ud: yeah, the last commit makes a clear difference in speed :)
[12:50] <sil2100> Since hm, now we can have both libunity-core-5.0-5 and libunity-core-6.0-5 installed in a system, right?
[12:50] <didrocks> sil2100: comes back to the conflicts/replaces definition
[12:51] <didrocks> first, do you have files that are common between the 2 packages?
[12:51] <didrocks> the answer is no
[12:51] <didrocks> so no need for replaces
[12:51] <sil2100> ACK ;)
[12:51] <didrocks> then, can't we install libunity-core-5.0-5 and libunity-core-6.0-5 on the same system?
[12:51] <didrocks> yes, we can if we want to :)
[12:51] <didrocks> so no need for conflicts :)
[12:52] <didrocks> sil2100: don't apply magic recipe, it's all about logic :)
[12:52] <didrocks> sil2100: dee needs it because it ships a common override files that isn't different between soname though :/
[13:03] <sil2100> Trevinho, andyrock: you here?
[14:35] <sil2100> andyrock: Trevinho: could you guys look at this one when you're around? https://bugs.launchpad.net/unity/+bug/1021327
[14:46] <Mirv> hmm, compiz_discover_tests got into compiz trunk, the gsettings branch apparently still brewing until tomorrow
[15:09] <didrocks> sil2100: I just saw your email, fixing those 2 regressions are not enough
[15:10] <didrocks> there are more issues and fixes needed :)
[15:10] <didrocks> I presented them in the detail of the sprint and entitled them as blocking release issue, can you find it on the document?
[15:11] <didrocks> (I'm just telling you them now to not block trunks more than now, normally, I should just check that once everything is green)
[15:17] <popey> didrocks, can you be more specific?
[15:17] <didrocks> popey: well, I would prefer you guys going back to your note and the release wiki page to find what's missing and what you didn't check
[15:18] <didrocks> popey: I told you it at least 6 times in the past 2 weeks as a hint of something missing and told you exactly what it was during the sprint, so if you don't look at little bit, I'm not sure you will have the reflex later to look at that
[15:28] <andyrock> sil2100, ping
[15:28] <didrocks> of course, if you don't find at all, I can help, but I would prefer you to find what's missing :)
[15:28] <popey> trust me we are looking
[15:28] <sil2100> andyrock: hi! Could you look at the unity release e-mail I sent?
[15:29] <sil2100> andyrock: there are 2 bugs that might need your help ;)
[15:29] <sil2100> (from Q)
[15:29] <andyrock> sil2100, perfect let me check the email
[15:30] <andyrock> sil2100, keynav mode inside dash?
[15:30] <sil2100> andyrock: that too - but the drag issue also is a bit annoying
[15:31] <andyrock> sil2100, i can reproduce the drag issue
[15:31] <sil2100> andyrock: and it seems to be a trunk regression
[15:31] <andyrock> sil2100, also dragging nautilus icon over the launcher
[15:51] <popey> didrocks, notes scoured, what have we missed?
[15:52] <didrocks> popey: so, something really important is to check that the new release passed the distro criterias
[15:53] <didrocks> one of them is that all commits matches the criterias
[15:53] <didrocks> that's why I constantly repeat "you should look at all merge requests"
[15:53] <didrocks> 2 commits don't have tests where they should have
[15:53] <popey> erk
[15:53] <didrocks> during the sprint, I showed you this link: https://docs.google.com/a/canonical.com/document/d/1kiVPg0U7VJpHt21y-Qm9VtnLxsTmKHfBmA2B16yLGzc/edit#
[15:54] <didrocks> where I post when I see a merge which doesn't (IMHO), match the criterais
[15:54] <didrocks> criterias
[15:54] <didrocks> so a discussion with upstream should be opened to know if this can be tested
[15:54] <didrocks> (those 2 ones were only noted and I told you, "we can't release now because of this")
[15:54] <didrocks> so, this is the first point
[15:55] <didrocks> the second, is that unity doesn't build an armfh for 3 weeks: https://launchpad.net/~unity-team/+archive/staging
[15:55] <didrocks> I told it during the sprint, I think Mirv was looking at it :)
[15:55] <didrocks> but we can't release as long as all the platform we support doesn't build
[15:58] <popey> thank you
[15:58] <didrocks> yw