[05:22]  * Guest42341 such a beautiful day, today. great for science and such
[09:31] <Mirv> heh, I was going to "quickly grab" the unity8 audio role patch for the xenial Qt 5.5.1 build, but it depends on use_quick_24 which depends on use_sdk_13 so I'll just instead remove the two lines from QML files :)
[09:47] <tsdgeos> Saviq: mzanetti: since we regularly forget to run make pot_file do you think i should add items to the checklist in both submit and review saying "HAve you run make_pot if there's new i18n messages"?
[09:48] <Saviq> tsdgeos, maybe we can automate that
[09:49] <tsdgeos> Saviq: as in?
[09:49] <mzanetti> sounds like a silo thin
[09:49] <mzanetti> thing
[09:49] <Saviq> mzanetti, bug #1359667
[09:50] <mzanetti> yep
[09:50] <Saviq> but tsdgeos, have a test that updates the .pot and compares it with the one in source (ignoring newlines and header etc.)
[09:50] <Saviq> but yeah, maybe time better spent on trying the approach proposed by robru in the bug
[09:51] <tsdgeos> i agree with him that commiting from the build bots is scary
[09:51] <tsdgeos> :D
[09:52] <tsdgeos> i think i kind of prefer the suggestion to have a test
[09:52] <tsdgeos> or maybe just run make_pot as part of make
[09:52] <Saviq> tsdgeos, don't want that, we'll get .pot updates with every MP
[09:53] <Saviq> at least not unconditionally
[09:53] <tsdgeos> ok
[09:53]  * Saviq don't see a problem with build bot committing
[09:54] <tsdgeos> actually i shouldn't eihter since it's what we have in KDE :D
[09:54] <Saviq> ;)
[09:54] <tsdgeos> but somehow here us doing it instead of a site-wide script makes me a bit more uneasy
[09:59] <Saviq> tsdgeos, oh yeah, the debian/rules approach makes me cringe, too, would much rather have an explicit hook mechanism
[10:00] <Saviq> but since debian/rules is really just a Makefile, maybe it's workable
[10:03] <tsdgeos> Saviq: the question is, does the thing thar run debian/rules actually have commit power on the repo?
[10:05] <Saviq> tsdgeos, don't think so, not today indeed
[10:05] <Saviq> so we'd need the train to do something anyway
[10:05] <Saviq> at which point might as well have a custom solution
[10:07] <Saviq> tsdgeos, oh well, they do run clean when bzr is available, so should be fine
[10:08] <Saviq> but we'd need to have a condition on which to hinge whether we do it or not, that the train would make true (like an env var)
[10:09] <tsdgeos> seems like that'd be close to "a hook" :D
[10:27] <tsdgeos> faenil: i didn't set https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1431328 since i could never reproduce it
[10:28] <tsdgeos> so no idea if it's fixed or not, maybe you can try to reproduce it or give us some more steps?
[10:30] <tsdgeos> mzanetti: isn't it a bit bad to have almost duplicated code in Unity/Launcher  vs Greeter/Unity/Launcher ?
[10:32] <mzanetti> tsdgeos, there's not so much duplicate, is there?
[10:32] <mzanetti> it's a different implementation of a backend
[10:33] <tsdgeos> mzanetti: quicklistentry, quicklistmodel, launcheritem
[10:33] <tsdgeos> problem is they have small differences
[10:33] <mzanetti> tsdgeos, well, that's the api definition
[10:33] <tsdgeos> and the untrained eye can't decide if it's because people forgot to update them
[10:33] <tsdgeos> or because it actually needs to be different
[10:33] <mzanetti> obviously it needs the same classes
[10:34] <mzanetti> tsdgeos, what do you suggest?
[10:34] <tsdgeos> e.g. one has
[10:34] <tsdgeos> if (countVisible) setAlerting(true);
[10:34] <Saviq> maybe we can abuse Qt/QML revisions? :)
[10:35] <tsdgeos> and the other has not
[10:35] <Saviq> and export Unity.Launcher with rev 1, and Greeter.Unity.Launcher with rev 2?
[10:35] <tsdgeos> and i guess this is a "correct" difference for greeter vs non-greeter
[10:35] <mzanetti> tsdgeos, yes... well, the bigger difference is actually how the models are filled
[10:36] <mzanetti> one has access to the system, the other only to accounts-service
[10:36] <tsdgeos> right
[10:36] <faenil> tsdgeos: sorry, I'll try again and see if it works now.
[10:36] <tsdgeos> i guess we could share those 3 files in a lib
[10:36] <tsdgeos> but maybe it's me just being annoyin :D
[10:40] <Saviq> since nobody related to what I wrote, maybe it's just too crazy, but mzanetti, tsdgeos maybe we can abuse Qt's revision mechanism and export different revisions to Unity. and to Greeter.Unity.? or did you not respond because you hate that idea? ;)
[10:40] <mzanetti> haha
[10:40] <mzanetti> tbh I'd need to read up on that first to form an opinion
[10:41] <tsdgeos> Saviq: i think it's unneeded since it's basically C++ code that is dupe, we can "fix" with simpler solutions if we think is a problem
[10:42] <mzanetti> Saviq, you mean just using different import versions?
[10:42] <Saviq> mzanetti, no
[10:42] <Saviq> mzanetti, basically, you can declare the same method multiple times, marking them with a different revision
[10:42] <Saviq> mzanetti, then, as you register the plugin, you say which revision you want
[10:43] <mzanetti> ah so we'd have just one plugin, which implements some methods multiple times
[10:43] <mzanetti> sounds like it could work...
[10:43] <Saviq> so you can have two different implementations of the same method in the same .so, and depending on which plugin you import you get one or the other
[10:43] <Saviq> s/which plugin you import/which import you use/
[10:43] <mzanetti> but also sounds like you better test that first as for sure you'll run into corner cases
[10:44] <ThijsWouters> \close
[10:44] <Saviq> oh sure, and maybe not even in this case, but we should keep that possibility in mind
[10:44] <mzanetti> yes... I really need to use that at some point... when you write apps usually that revisioning stuff is not really needed...
[10:46] <Saviq> yeah, it's usually only useful for backwards compat
[10:46] <Saviq> so not really for unity8 either
[10:47] <Saviq> we *could* think of applying that to all the bits that implement unity-api APIs, but probably too early for that still
[10:48] <faenil> tsdgeos: ah that's why I didn't provide any info, you replied "it's the first run of build.sh that installs the build deps" but in the comment above I say that I ran build.sh -s and then build.sh
[10:48] <Saviq> faenil, let me come to you :)
[11:15] <Saviq> tsdgeos, could you have a look at https://code.launchpad.net/~larsu/gsettings-qt/lp1503693/+merge/276190 ?
[11:15] <tsdgeos> Saviq: as in, confirm the bug exists and this workarounds it?
[11:15] <tsdgeos> fix the qt bug?
[11:16] <tsdgeos> or?
[11:16] <Saviq> tsdgeos, seb128 asked for a review of ↑, but if we can fix the Qt bug, might be better ;)
[11:16] <seb128> Saviq, +1!
[11:17] <tsdgeos> "can fix" is a pretty broad statement :D
[11:17] <tsdgeos> i'm sure we can fix it, but it may take much more than those 3 lines :D
[11:17] <tsdgeos> but anyway yes i'll have a look
[11:17] <tsdgeos> i already had a look to it tbh
[11:17] <tsdgeos> but i'll have a second and approve if that's what you guys want
[13:39] <mterry> greyback_, heyo, poke about the no-touch-no-lifecycle branches.  They are in our silo, but I realized they aren't approved yet.  Would like to get them cleared, since other branches have started to pre-req them
[13:57] <Prasad> Hi, is anybody working on fix for bug # 1154364
[14:11] <greyback_> mterry: on it
[14:12] <mterry> thx!
[14:13] <mterry> greyback_, also I made a small change to the unity-api branch after you had approved it -- Saviq caught me not incrementing the VERSION for unity-shell-application
[14:13] <mterry> greyback_, so might want to give that a look over again
[14:13] <greyback_> ok
[14:18] <Prasad> Hi, I'm a C++ software , and willing to contribute to unity bug fixes
[14:37] <tsdgeos> Saviq: so do we want cimi to run make pot_file on lp:~cimi/unity8/preview-sharing or lading it "broken" and update it later?
[14:40] <Saviq> tsdgeos, we'll rebuild silo 21 so yeah
[14:40] <Saviq> cimi, ↑
[14:41] <cimi> Saviq, oki
[14:42] <tsdgeos> Saviq: mzanetti: opinion on https://code.launchpad.net/~aacid/unity8/coding_update/+merge/276662 ?
[14:48] <mzanetti> tsdgeos, +1 for less redundancy
[14:49] <cimi> tsdgeos, I like having some information already in the package, shall we leave a bit and point to the website for "more details"?
[14:49] <cimi> like, usually when I download some new source code, I grep for README/HACKING for quick build instructions
[14:51] <tsdgeos> cimi: what would you leave of what i removed?
[14:52] <cimi> tsdgeos, maybe just build and a simple run
[14:56] <tsdgeos> dandrader: your "let's keep it closer to the code so it's update" has been proved wrong
[14:56] <tsdgeos> the web is up to date, that file is not
[14:56] <tsdgeos> true is that i updated the web so i'm half cheating
[14:56] <tsdgeos> but it was still more up to date that the file
[14:56] <tsdgeos> before i updated it more
[14:59] <dandrader> tsdgeos, you need special rights to edit that web page? it's not even a wiki
[15:00] <tsdgeos> dandrader: yes it's not a wiki
[15:00] <tsdgeos> it's a wordpress instance
[15:00] <dandrader> tsdgeos, I recall mhall119 was trying to get it up to date before...
[15:00] <dandrader> but a hard job as he's not involved in the daily development
[15:01] <Saviq> it should probably be in our source and updated from there automagically on the website
[15:01] <mhall119> dandrader: you just need to be in the right LP team and then go to unity.ubuntu.com/wp-admin/
[15:01] <dandrader> Saviq, that's my opinion as well
[15:01] <mhall119> ~unity-website-editors is the team
[15:02] <tsdgeos> Saviq: ideality is nice, who's going to write that wordpress plugin ? :D
[15:04] <tsdgeos> dandrader: Saviq: we could link from the web to http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/CODING
[15:05] <tsdgeos> it's less fancy
[15:05] <tsdgeos> would also saves us from having to update stuff twice
[15:05] <Saviq> tsdgeos, I'm sure there is a wordpress plugin that imports rst or something from a url already
[15:05] <Saviq> and that url could very well be ↑
[15:06] <dandrader> We could just ensure that CODING file follows some lightweight markup language and ta da!
[15:17] <tsdgeos> Saviq: you moved https://code.launchpad.net/~cimi/unity8/sdk1.3_newUbuntuShape/+merge/271610 to needs review because of the flaky test, should we move back to approved? i remmeber you mentioning something about the flaky not being clocking?
[15:17] <Saviq> tsdgeos, yeah, will do
[15:17] <mterry> greyback_, thanks for reviews!
[15:18] <mterry> tsdgeos, you approved the slim greeter branch?
[15:18] <tsdgeos> mterry: wrong click
[15:18] <tsdgeos> mterry: it should be back on needs review
[15:18] <mterry> josharenson, btw I'm reviewing slim greeter as we speak
[15:18] <tsdgeos> plrease double check
[15:19] <mterry> tsdgeos, oh cool, LP must not have sent me email yet.  I'm reviewing the branch now actually
[15:19] <josharenson> mterry: cool, you saw the conversation I just had w/ tsdgeos in #unity?
[15:19] <mterry> mmm, no will read
[15:19] <mterry> josharenson, ah cool
[15:19] <tsdgeos> josharenson: mterry: the CI just passed :)
[15:20] <mterry> josharenson, will avoid complaining about any qmluitest failures then
[15:20] <mterry> oh good
[15:20] <josharenson> tsdgeos: cool maybe the thing I did last night worked then... chmodded the runtests.sh
[15:22] <mterry> josharenson, so in terms of testing...  I'm confirming that there are no regressions on phone, and then confirming that the new greeter works on my desktop?  Anything else?
[15:22] <mterry> I guess test each of the modes real quick maybe
[15:23] <josharenson> mterry: uhhh I tested multi monitor... you can take my word for that
[15:24] <cimi> tsdgeos, you got my message about two columns?
[15:24] <tsdgeos> cimi: i did
[15:25] <tsdgeos> but there was "no message" D
[15:25] <tsdgeos> just a forward
[15:25] <tsdgeos> what do i do with it?
[15:25] <cimi> tsdgeos, I wrote here but probable I was disconnected
[15:25] <cimi> tsdgeos, design asked me to increase those paddings
[15:25] <cimi> as you read the mail
[15:26] <cimi> tsdgeos, also, potfiles were updated too in the branch you needreviewed
[15:26] <tsdgeos> cimi: in the past or just now?
[15:26] <cimi> 20 mins ago
[15:26] <tsdgeos> cimi: forgot to push?
[15:27] <cimi> tsdgeos, I did
[15:27] <tsdgeos> wait i'm looking at the wrong MR
[15:27] <cimi> "meh" :D
[15:28] <tsdgeos> back to approved
[15:28] <cimi> cool
[15:37] <tsdgeos> cimi: be careful when moving those margins
[15:37] <cimi> tsdgeos, yeah...
[15:37] <tsdgeos> they'll complain later again when the composition is differnet :D
[15:37] <cimi> tsdgeos, do we have any code or place that gets enabled for two column layout?
[15:37] <cimi> is everything in Preview.qml?
[15:38] <tsdgeos> not sure what you mean
[15:38] <tsdgeos> Preview.qml decides the number of columns yes
[15:38] <tsdgeos> property int columns: width >= units.gu(80) ? 2 : 1
[15:39] <tsdgeos> should be readonly if you're going to modify that file
[16:40] <larsu> Saviq: are you planning on landing the gsettings-qt patch?
[17:04] <mzanetti> dandrader|afk, I've moved the code over to Dialogs.qml... not sure if it's really better, but the argument to take some load from Shell.qml is a good one
[17:09] <Saviq> larsu, I didn't, do you want us to?
[17:12] <larsu> Saviq: yes please, unless seb128 wants to...
[17:14] <kgunn> mzanetti: trying to locate a bug i think you logged, i couldn't find it, but in windowed mode/monitor connect u-s-c cpu is high ?
[17:14] <kgunn> maybe i dreamed that
[17:14] <Saviq> kgunn, bug #1499039
[17:14] <mzanetti> kgunn, I think Saviq logged it in the end, but I have seen the issue too
[17:15] <Saviq> seb128, could you take care of that landing please? I'm already on the naughty list in the train ;)
[17:15] <mzanetti> haha
[17:30] <cimi> ltinkl, you around?
[17:37] <seb128> Saviq, can do
[18:02] <jcastro> hi guys, I'm in xenial on the unity8 session
[18:03] <jcastro> the one problem is it seems the lock screen is over the desktop
[18:03] <jcastro> so when I click on the launcher to launch apps I don't see them launching
[18:03] <jcastro> I suspect they're behind the lock screen
[18:03] <jcastro> putting my password in the lock screen turns the entire screen black, so I don't think that's what is supposed to happen
[18:29] <Saviq> jcastro, what release?
[18:31] <jcastro> the latest in xenial, let me check
[18:32] <Saviq> jcastro, can you try a different user
[18:32] <jcastro> Saviq: 8.11+15.10.20151021-0ubuntu1 is the version of the unity8 package
[18:33] <jcastro> sure
[18:34] <jcastro> same thing with a new test user
[18:35] <jcastro> with either user I can't get past the unity8 lock screen
[18:36] <Saviq> jcastro, and you installed via unity8-desktop-session-mir?
[18:36] <jcastro> yep
[18:36] <Saviq> jcastro, and you select the unity8 session in the greeter?
[18:36] <Saviq> jcastro, can you clear ~/.cache/upstart/*, try again and see what you find there
[18:38] <jcastro> no change
[18:40] <Saviq> jcastro, didn't mean that would fix, but the logs could help then
[18:53] <jcastro> oh! ok I have a session, will investigate and come back later
[18:53] <jcastro> thanks for the tips
[18:54] <jcastro> also is there a PPA I should follow? I don't mind breakage, I'm basically setting aside a machine for U8
[19:02] <Saviq> jcastro, no ppa, everything goes straight into trunks and xenial
[19:03] <jcastro> man dude, look at all these logs, finally, a desktop that logs everything, I love you.
[19:09] <Saviq> jcastro, plenty more to be logged, but yeah, much better than .xsession-errors, 'innit ;)
[19:12] <jcastro> nothing reallu jumps out as fatal-looking
[19:12] <jcastro> we need WARN: and ERR: for grepability :)
[21:15] <pmcgowan> when we pair with a bluetooth keyboard do we suppress the OSK?