[03:39] Trevinho, around? do these errors mean anything to you? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1252937 [03:39] Ubuntu bug 1252937 in unity8 (Ubuntu) "14 test failures on latest unity8 build." [Critical,New] [03:40] Saviq, ^^ [08:08] Mirv: sorry i should have attended that one, lost track of stuff [08:08] ah, i see saviq joined later [08:34] Mirv: can you trigger a rebuild of https://code.launchpad.net/~canonical-qt5-edgers/+recipe/unity-mir-daily-qt52 ? i don't seem to be able to choose the "[testuse] Qt5 Beta2" archive from the list [08:34] Saviq: maybe you can? ↑↑ [08:35] tsdgeos: clicked the button [08:35] tx [08:35] and yeah savi_q could have done that too [08:37] Saviq: we've been 40 revisions without a release, shouldn't we get one? [08:44] Mirv: can you actually trigger the unity8 one? i got a patch in this morning that should get rid of the armhf failure too [08:45] Mirv: https://launchpadlibrarian.net/156994226/buildlog.txt.gz ?¿ [08:45] tsdgeos: ok. [08:46] tsdgeos: Saviq: it was too tempting btw, I was running with Qt 5.2 already, I can post a video soon :) I merged some branches, disabled tests (in case they'd fail) and recompiled unity8 + qtubuntu + unity-mir on the device [08:47] Mirv: so you're seeing the ugly regression in the ubuntushapes? [08:57] damnit my nexus4 decided to commit suicide again [08:57] * tsdgeos searches or the original charger [09:07] tsdgeos: that's what you get for filling your home with Z10 chargers :P [09:07] it's not my fault if BB loves giving me free stuff [09:07] lol [09:07] at this point i've gotten 3 Z10 and a Playbook :D [09:08] insane [09:08] I wonder why they take names when giving away their free stuff. certainly not to check for duplicates [09:12] mzanetti: i think they only duplicate by e-mail address [09:13] because you know there's so many "Albert Astals Cid" in the world you can't know if tsdgeos@yahoo.es aacid@kde.org and albert.astals@canonical.com are the same guy or not :D [09:13] ah. so you are being sneaky [09:13] :) [09:13] i am not being sneaky [09:13] i am just contributing to Qt a lot :-P [09:14] ok. sure... [09:14] i got red light in the nexus4 btw [09:14] needed to do the magic three finger salture though [09:14] tsdgeos: https://plus.google.com/107379654278574464995/posts/NeUt19z1V3p [09:15] lol [09:15] empty scopes?¿ [09:15] that's bad :D [09:18] tsdgeos: yep, not really sure why.. I get a black screen relatively soon too. but that's for this afternoon's session about where we're at with testing :) [09:18] "it starts" [09:32] tsdgeos, what do you make of this test? https://code.launchpad.net/~nicolas-doffay/unity8/search-history-persist/+merge/193935 [09:32] nic-doffay: i retriggered ci [09:33] tsdgeos, I didn't see anything related. [09:33] the ci machines are sometimes stupidly username blocked [09:33] and thus everything fails to run [09:33] it's something the ci people are working on [09:33] basically if you see all 28 autopilot tests fail at once [09:33] it's probably that [09:35] mzanetti, which package do you suggest I should report bug for ? re: running qmltestrunner on Mir [09:36] erm [09:37] /var/local/autopilot/setup.log: The following packages have unmet dependencies: [09:37] /var/local/autopilot/setup.log: unity8 : Depends: libunity-mir1 but it is not going to be installed [09:37] what ?¿ [09:39] nic-doffay: seems the CI for your MR will fail again because of ↑ :_/ [09:40] om26er: unity-mir [09:41] mzanetti: any idea what's causing the above problem with deps?¿ [09:41] isnt the upside down question mark supposed to go at the beginning of the sentece? [09:41] I think some build failed [09:41] no. I don't know what that is [09:42] build of the dependency I mean [09:43] mzanetti: it is, but it's easier to add it at the end :P [09:43] tsdgeos: well, libunity-mir probably depends on something that doesn't exist (yet/any more) [09:43] since it's confortably located on the keyboard besides the other [09:43] tsdgeos: but that defeats it's purpose. I always liked the fact that you know it is a question before you start reading [09:43] trueth [09:53] tsdgeos, err [09:53] yes? [10:02] tsdgeos, just re the setup.log [10:03] nic-doffay: ?¿ [10:03] * tsdgeos is lost [10:04] MacSlow: why the "skipBackground" in the fullscreen lockscreen? [10:07] mzanetti, that's to avoiding the black/opaque rect drawn by the PinPad... [10:08] MacSlow: well, there should be the background image from the shell [10:08] MacSlow: if it's just black that's an issue in the Lockscreen I'd say [10:09] mzanetti, there's still the surrounding element which has the notifications bg-color and setting the shell-background would make it look very ugly with the notification-border [10:10] MacSlow: hmm...why is that? I thought the lockscreen content is fullscreen [10:11] mzanetti, there's still the padding/margins from the parent-element, which fill space up to the edges [10:12] MacSlow: hmm... any chance to get around that? [10:12] mzanetti, also it would look a bit weird, if the pinpad would flush up right to the screen-edges [10:12] mzanetti, I tried and didn't get any working results [10:16] mzanetti, besides... I was a bit surprised, that the background (other than what the parent is) could be forced onto the pinpad [10:17] MacSlow: not sure I understand [10:18] mzanetti, I didn't expect an opaque background color (with the option to set a custom image) was the default for it. [10:19] mzanetti, I thought it would just be a transparent background... like e.g. the OptionSelector has [10:20] MacSlow: well, in the end it should be, but blur the background. as we are not able to properly do that yet, we went for putting the background image into it [10:21] MacSlow: in any case, the notifications border needs to go away [10:21] Cimi: can you re-review https://code.launchpad.net/~nick-dedekind/unity8/lp1238182/+merge/192965 when you get a minute? [10:21] dednick, yup [10:21] Cimi: thanks [10:22] mzanetti, I can try again... but don't know if I get to a acceptable solution this time [10:22] MacSlow: I can help you [10:23] mzanetti, I'll stick to the snap-decision states until lunch... after that I'll address the border [10:24] sil2100, when can we except the new unity-scopes-shell to land in distro? [10:25] sil2100, right now it's pretty safe to land it, cause it doesn't include deps on the new stuff yet [10:25] cc dednick ^ [10:26] mhr3, sil2100: I'm more interested in getting ubuntu-settings-components landed! :) [10:26] dednick: mhr3: one moment, let me check something [10:28] dednick: ok, after I land one of the fixes that seb128 pointed out yesterday, we can enable and release the ubuntu-settings-components for sure [10:28] mhr3: unity-scopes-shell I think is ok as well, as seb128 reviewed my packaging changes and didn't note any problems, so I guess we can do the same here [10:28] sil2100: fixes for? [10:28] dednick: packaging, minor things [10:29] sil2100: ah, ok [10:29] sil2100, unity-scopes-shell ... I reviewed your packaging changes, not the package for NEW [10:29] sil2100, not sure if that's what you are talking about there? [10:30] seb128: ah, right, I thought you also did the preNEW review during that time as well ;) I don't want to bother you too much though, so maybe I can ask didrocks to perform the preNEW review or something [10:30] Since you're like doing all the review work since yesterday for me ;p [10:30] sil2100, let me do the preNEW, didrocks is fighting with his trusty to get it back to "working" [10:30] jeez what's with jenkins these days :/ [10:31] seb128: thanks again! [10:33] Saviq: it's broooooooooken [10:33] sil2100, mhr3: you guys are joking right? [10:33] Saviq: seems to have some kind of broken dependency packages [10:33] tsdgeos, where? [10:33] om26er, yeah, unlock_screen was looking fine, just needed to test it still [10:33] sil2100, mhr3: [10:33] $ licensecheck * -r | grep " GPL (v3" | wc -l [10:33] 74 [10:33] $ grep License debian/copyright [10:33] License: LGPL-3 [10:34] Saviq, ok. thanks [10:34] seb128: ouch [10:34] Wait... [10:34] Saviq: this is not jenkins but it's a similar error https://launchpadlibrarian.net/156994226/buildlog.txt.gz [10:34] Saviq: let me look up one in jenkisn [10:35] sil2100, if the source should be GPL you need to fix the copyright and ./data/unity-plugin-scopes.pc.in: LGPL (v3) [10:35] seb128: ok, right, I think this is something that I obviously missed during the review [10:35] :q [10:35] sil2100, fwiw it should be gpl, no need for lgpl there [10:36] Saviq: see http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty/810/console [10:36] mzanetti, is qmltestrunner responsible for running both unit tests and integration tests ? [10:36] /var/local/autopilot/setup.log: The following packages have unmet dependencies: [10:36] /var/local/autopilot/setup.log: unity8 : Depends: libunity-mir1 but it is not going to be installed [10:36] seb128, mhr3: fixing those 2 issues [10:36] ty [10:37] tsdgeos, that seems to have started happening very recently [10:37] om26er: not really... we use autopilot for integration tests [10:37] tsdgeos, like 4hrs ago we had a successful desktop run (touch failed due to device failing) [10:37] mzanetti, sorry, I was referring to the integration tests of QtMultimedia, they test if the sound is really working for example [10:38] om26er: still talking about those .qtt files? [10:38] mzanetti, no [10:38] Saviq: yeah :-/ [10:38] mzanetti, they are of the format tst_name [10:38] om26er: no .qml? [10:39] om26er: in that case they're binaries. just run them with ./ [10:39] mzanetti, no, rather the compiled cpp binaries [10:39] mzanetti, right. I just wanted to know which is the tool that runs them ? [10:39] none. the have their own main() [10:40] (usually generated through the QT_TEST_MAIN macro) [10:40] om26er: ^ [10:40] mzanetti: MacSlow: what's missing for top approval in https://code.launchpad.net/~mzanetti/unity8/generic-lockscreen/+merge/191951 ? [10:40] tsdgeos: jenkins probably :P [10:40] mzanetti, right. so those also don't work under Mir [10:40] tsdgeos: I think it's ready to go [10:41] om26er: why not? [10:41] tsdgeos, mzanetti: nothing... my bad... top-approved [10:41] just pass --desktop_file_hint... [10:41] mhr3, seb128: https://code.launchpad.net/~sil2100/unity-scopes-shell/packaging_review/+merge/195936 [10:41] om26er: also, most likely those tests don't even paint a UI. so you wouldn't even need that [10:41] mzanetti, not really sure. I get: [10:41] QUbuntu: Could not create application instance [10:41] Aborted (core dumped) [10:42] om26er: yeah. just add --desktop_file_hint=/usr/share/applications/some-random-file.desktop [10:42] seb128, +1 from me, pls top-approve if you're ok with that [10:42] mzanetti, we want to run those tests to make sure that all the QtMultimedia apis are working fine with our backend implementation on the phone [10:42] om26er: that's on the phone or on the desktop? [10:42] tsdgeos, the launchpad failure is different [10:42] tsdgeos, phone [10:42] tsdgeos: on the phone, with mir [10:42] ok [10:43] tsdgeos, the launchpad failure builds in the ppa, from trunks [10:43] sil2100, mhr3: ok, approved, thanks [10:43] Saviq: ok, still both failed :-/ [10:43] om26er: did you try running them with the parameter? [10:43] tsdgeos, and because mir isn't built in that ppa, unity-mir fails due to http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/revision/145 [10:44] sil2100, mhr3: the naming is a bit weird otherwise, especially that the description states "Library to integrate"... [10:44] mzanetti, yeah. I get this http://paste.ubuntu.com/6447502/ [10:45] oh crap [10:45] seb128, well... yea, should be "plugin" [10:45] Saviq: ^^ [10:46] mzanetti, om26er yeah, that happens sometimes, at which point you need to use upstart-app-launch directly [10:46] Saviq: i see, so how do we fix that? [10:46] Saviq: but that requires a valid .desktop file, or? [10:46] sil2100, mind fixing that in your branch while it's not merged yet? [10:47] mzanetti, yes [10:47] mzanetti, it might be that Exec=%s would work [10:47] mhr3: sure, I bumped it back to unapproved and fixing [10:47] Saviq: but we can't have valid .desktop files for every test [10:47] ah ok. worth a try [10:47] sil2100, thx [10:47] Plugin to integrate scopes with the Unity shell <- is ok? [10:47] yep [10:47] mzanetti, then you'd go upstart-app-launch foo $PWD/tst_foo [10:47] * mzanetti tries [10:48] Cimi: how's the basedashrenderer thing going? [10:48] Saviq: the .desktop file needs to be located in /usr/share/applications? [10:48] mzanetti, or ~/.local/share/applications [10:48] tsdgeos, I have a bug [10:49] mzanetti, btw seems some unit tests are running fine without any arguments(but just executing the binary) others, don't [10:49] Cimi: get a bird :P [10:49] sil2100, ok to re-approve? [10:49] Cimi: can i help? [10:49] tsdgeos, you can try if you want [10:49] let me push [10:49] om26er: yeah... depends on whether it tries to paint something on the screen or if its just a command line based test [10:50] mhr3: actually I just noticed that lp-propose proposed the wrong branch... so let me propose a different merge and auto-approve [10:50] tsdgeos, the PPA we don't fix - we just wait for mir 0.1.1 to be released (they must've forced the unity-mir dependency through) [10:50] sil2100, fwiw the diff looks fine [10:50] mzanetti, none of those tests tries to paint anything, they are all verbose only. [10:50] hence unit-tests ;) [10:50] sil2100, doesn't really matter that you're reusing old branch [10:50] mhr3: yeah, I know, just I'm a bit worried if the merger/LP wouldn't go crazy, but hell, let's try and approve [10:51] om26er: a) why wouldn't a unit test paint anything? b) you don't necessarily see something even if its accessing the display server [10:51] sil2100, it'll be fine, i'm doing that from time to time too :) [10:51] tsdgeos, lp:~unity-team/unity8/dash-renderers [10:51] mzanetti, right, that. [10:51] Cimi: ok, i'll have a look [10:52] Mirv, hey, is mir 0.1.1 getting into the archive soon-ish? [10:52] mhr3: phew, I'm always worried, since then there are like 2 merge commits pointing to the same branch, always makes me worry [10:52] tsdgeos, 1) the indicator triangle at the bottom of the preview does not move [10:52] 2) the preview of the carousel leads to empty scope after [10:52] you close it [10:53] Saviq: very soonish after https://code.launchpad.net/~timo-jyrinki/unity-system-compositor/clean_conffile/+merge/195934 this lands, otherwise all tested [10:53] dednick: https://code.launchpad.net/~sil2100/ubuntu-settings-components/tests_copyright/+merge/195937 <- with this we can push u-s-c out [10:53] sil2100: hey, don't hijack the u-s-c abbreviation, it means unity-system-compositor! [10:53] :) [10:54] soon we can push both u-s-c's out [10:54] Daamn [10:54] ;) [10:54] It's just so tedious to write the long name, so as long as the person knows the context, I guess it's ok to mix ;p [10:55] yes of course :) [10:57] sil2100: cool. approved. [10:58] bug 1253044 [10:58] bug 1253044 in unity-mir "Running unittests that require access to the display server crash" [Undecided,New] https://launchpad.net/bugs/1253044 [10:58] Saviq, mzanetti ^ for reference. [10:59] tsdgeos, maybe we need to create bindings with some properties in DashFilterGrid.qml [10:59] like alias [10:59] but can you override a property declaration? [11:01] Mirv, thanks [11:01] mzanetti, om26er, maybe those tests just need to run with QT_QPA_PLATFORM=minimal? [11:02] Saviq: think about the listviewwithpageheader test for example [11:02] Cimi: let me see [11:03] Saviq, apparently they seem to be running [11:04] mzanetti, sure, but that's a UI test [11:04] mzanetti, let's see if om26er can cut it with minimal [11:04] yeah ok... the qtmultimedia tests actually might work with that [11:04] om26er, there's a conflict in https://code.launchpad.net/~om26er/phablet-tools/unlock_screen/+merge/195529 [11:04] but still I guess the target is to be able to run ui tests too [11:05] mzanetti, sure [11:05] Saviq: Desktop Exec line code '%s' unknown, skipping [11:05] mzanetti, hmm [11:05] mzanetti, might be it "protects" against that [11:06] mzanetti, but anyway, yeah, we just need something that will make upstart exec an arbitrary binary, while saying the .desktop file is foo [11:06] but how about this? I have a script "dummyrunner" and a .desktop file for it. I guess passing normal arguments would work to exec stuff in the script [11:06] mzanetti, sure it would [11:07] mzanetti, just "exec $@" [11:07] mzanetti, fwiw [11:07] Exec=exec %s [11:07] maybe that'd work [11:07] although that's not a normal binary [11:08] Saviq: yeah. but it still should work if i call "exec someBinary" in there [11:08] I do that with some apps to export LD_LIBRARY_PATH first [11:08] mzanetti, in the script, yes [11:08] mzanetti, just not directly in the .desktop file [11:08] nope [11:11] Saviq: no. can't seem to pass arguments to the script [11:12] oh. seems to work [11:12] % U [11:13] foo bar [11:13] interesting :) [11:13] mzanetti, so what's the verdict? [11:13] % U in IRC causes underscores [11:13] ;D [11:14] still trying. gimme one more minute [11:14] %U [11:14] foo bar [11:14] might be my client [11:14] % U [11:14] foo bar [11:14] yeah, nothing here ;) [11:19] Saviq, thanks, merged with trunk now. [11:21] hah. got it [11:23] om26er, Saviq: http://paste.ubuntu.com/6447666/ [11:25] mzanetti, yup, sounds right [11:25] actually changing Exec to dummyrunner % u % U would allow us even to pass arguments to the binary I guess [11:25] (without the spaces ofc) [11:27] Cimi: some of your bindings are wrong on the DashFilter [11:27] tsdgeos, can you spot? [11:27] tsdgeos, those are not bindings [11:27] Cimi: http://paste.ubuntu.com/6447673/ [11:27] btw. the lvwph test fails on the phone :P [11:27] I see [11:27] makes sense [11:28] and the others probably need the same [11:28] an alias but be indeed better [11:29] and it works too [11:29] tsdgeos: hmm... it's always off by 5: http://paste.ubuntu.com/6447677/ [11:29] but then you end up in a weird situation in which your base item has a property === _salem is now known as salem_ [11:29] and you have another one [11:29] with the same name :-/ [11:29] tsdgeos, yeah... [11:30] tsdgeos, it was my concern indeed [11:30] mzanetti: and then segfaults? [11:30] yeah. but I'm not sure if that's because the screen blanked [11:31] tsdgeos: nope. segfaults indeed [11:31] sil2100: your changes have been merged into ubuntu-settings-components. landing time? [11:31] mzanetti: the input is failing [11:32] those 5 px are the difference between receiving and not receiving the mouse events [11:32] strange. given that the other tests seem to work [11:32] mzanetti: it's the only test that uses the mouse to change y [11:32] ah ok [11:32] because needs to overshoot [11:32] the others just change the y programatically [11:33] hmm... interesting... [11:33] tsdgeos: so something in the QPA? [11:34] om26er: btw. let me know if that works for you with the QtMultimedia tests [11:34] mzanetti, yeah, will be testing that in a few. [11:35] mzanetti: don't know tbh [11:35] mzanetti: is this new? [11:35] didn't we have test running on the phone for a while? [11:37] tsdgeos: I don't think we ever did [11:37] really? [11:37] then it was autopilot running on the phone? [11:37] tsdgeos: yeah. AP is [11:37] ah [11:37] hmmm [11:37] don't know what may be causing this [11:37] tsdgeos: iiuc om26er is working on getting unit tests running otp too [11:39] qpa may be it [11:39] not sure how mousePress is wired [11:39] maybe it's not wired at all? [11:39] heh... that might well be [11:39] but wait... I did run qml tests already and iirc they were passing [11:40] I guess it uses the same wires [11:40] do we have mousPress calls in there? [11:40] qmltests? sure [11:40] ok [11:41] tbh i'm more worried about the crash than this one :D [11:41] but someone would have to debug it properly [11:41] yeah... the crash might reveal a real one [11:41] and see why it's not getting the y changed on those moves [11:41] maybe it's all a thing of i need a .gu multiplier [11:42] hmm... apart from this, that would be a good idea in any case [11:42] the LVWPH tests are freakin tiny here [11:42] but I don't think we have GUs in C++ yet [11:42] i can't think why the .gu should matter [11:42] otoh [11:43] since it's all in the same "scale" [11:43] but who knows [11:43] tsdgeos: actually... they pass on my desktop which is pretty much the same as on the phone [11:43] right [11:43] it's what i was saying, if everything is small it should still work [11:43] because everything is small [11:43] yep [11:49] om26er, this conflicted, too... https://code.launchpad.net/~om26er/unity8/unlocker_fix_non_working_code/+merge/194850 [11:51] Saviq, things are running against me today :/ will fix that. [11:51] hey. if I have a flickable, and inside that another flickable. is it possible to scroll the outer flickable when the inner one reaches its end? [11:52] mzanetti, I don't think it is [11:52] Saviq: design wants it [11:52] Saviq: any ideas? [11:52] mzanetti, definitely not if you allow overshoot/dragging on bounds [11:52] mzanetti, feels like digging in Qt [11:52] Saviq: yeah. I tried setting it to StopAtBounds [11:52] doesn't work [11:53] mzanetti, to make it give up the touch if isAtEnd / isAtBeginning [11:53] yeah... was hoping I'm not the first one that needs this :D [11:53] mzanetti: you can't do that seamlessly [11:54] i tried to make it work once [11:54] don't remember what for [11:54] but it's just "impossible" as it stands now, nobody is going to pass the extra momentum from the inner flickable to the outer one [11:55] and make it look acceptable [11:55] yeah... I was afraid of that [11:56] mzanetti: can't you just use one flickable? [11:56] tsdgeos: not really [11:56] no [11:56] why not? [11:56] the dash is doing it [11:56] tsdgeos: yeah, but the dash doesn't scroll the categories [11:56] or they really want viewport inside viewport [11:56] tsdgeos: yep. [11:56] someone kill design :D [11:57] viewport inside viewport looks like a terribly complicated use pattern to me [11:57] tsdgeos: https://docs.google.com/a/canonical.com/document/d/1_c4029C6Jwll_ng8gqp3SRnF4DgXRA3tR_LL3J-zOD8/edit [11:57] tsdgeos: page 3 [11:58] tsdgeos: its like the previews in the dash. when you reached the end of the preview, the dash would continue scrolling [11:58] tsdgeos: I don't think its really bad for usage. but yeah. its really bad for the developer :D [11:59] mzanetti: but isn't it "expanding"? [11:59] where's the inner flickable here? [11:59] tsdgeos: yes. up to a may of ListView.height - delegate.collapsedHeight [11:59] tsdgeos: if the expanded content is still larger, it should scroll [11:59] s/may/max/ [12:00] mzanetti, but is it really expected that when you reach beginning / end of the content, you continue scrolling? [12:00] Saviq: yes. I explicitly asked for that [12:00] mzanetti: i think it may be a wording confusion [12:00] mzanetti: and they just want what the dash does when the expanding category is bigger than the dash [12:00] but i may be wrong [12:01] tsdgeos, no [12:01] tsdgeos, I'm afraid in that case it really is it's supposed to scroll inside [12:01] ok [12:01] [Monday 18 November 2013] [17:43:48] when scrolling in the expanded item, and you reach the end of the content (no more scrolling possible), and you try to scroll more, then the list will scroll [12:01] but I can't see how it'd be acceptable to the user to overshoot and that becoming a "global" scroll [12:02] true [12:02] so what i described is not necessary [12:02] or is it? [12:02]