[00:14] How do I run the unit tests? I was told './test/test-getst' but there is no file like that [00:15] I lied [00:15] tigrang, well where are you in the direction? [00:15] directory* [00:15] (should be in unity/build/tests/test-gtest [00:15] ) [00:15] was looking in tests/ directory, but it's inside build/tests [00:15] yup! [00:15] yea, my bad, thanks [00:16] no worries, I still get confused when I want to open a source file while in build/tests :) [00:16] but have to go ../../tests [01:21] bschaefer: still around? [01:22] cyphase, yup, hello [01:22] hehe [01:22] hello ;) [01:22] lol [01:22] opps [01:22] cyphase, sorry! [01:22] no problem, happens all the time [01:22] do you have time to do a quick review for autopilot-qt? [01:22] 4 chars overlap! [01:22] https://code.launchpad.net/~mathieu-tl/autopilot-qt/arches/+merge/154567 [01:22] cyphermox, yeah I can take a look hopefully [01:22] i should change to cyphzse :) [01:23] cyphase: nice :P [01:23] cyphermox, what is any declared? (Just want to make sure powerpc is the only thing missing from the list) [01:24] bschaefer: any actually includes powerpc [01:24] s/what/where* [01:24] (which is what we don't want) [01:24] cyphermox, yeah, so the list is 5? [01:24] that's subject from interpretation based on what distro builder supports [01:24] * bschaefer just wants to double check non are missing [01:24] on Ubuntu, yes [01:24] oo alright [01:24] cool looks good to me then [01:24] on Debian it's more like 15 or so ;) [01:25] haha, approved :) [01:25] this is just temporary to unblock autopilot-qt [01:25] thanks! [01:25] cyphermox, cool, I figure once its fixed it'll go back to any :) [01:25] np! [01:25] yup [01:58] Is there anything wrong with this (in terms of coding standards/style or stuff I shouldn't be using)? https://gist.github.com/tigrang/6af395688f7f782a0a92 (6 lines) [02:06] tigrang, looks fine to me. Looks like the surrounding code. [02:10] ok, thanks for taking a look === mmrazik is now known as mmrazik|crappy_i === mmrazik|crappy_i is now known as mmrazik [08:19] mzanetti: ran https://code.launchpad.net/~aacid/unity/giveNexus10TestMoreTimeToStart/+merge/154458 4 times on CI and didn't get any "36 seconds of nothing", seems it may be "a fix" since i'd say it was happening more than 25% [08:20] tsdgeos: ack [08:20] tsdgeos: thanks. I'll read it and approve if there aren't any bad thing in the code [08:21] looks fine [08:22] mzanetti: and we need https://code.launchpad.net/~aacid/unity/fix_hud_test_stubborness/+merge/154446 too [08:22] i had one of the tests need the retry [08:22] and then it failed becuse of the missing return :D [08:31] tsdgeos: right... approved... === alan_g is now known as alan_g|afk [08:49] MacSlow: mzanetti: Saviq: what about https://code.launchpad.net/~aacid/unity/removeUnusedFunction/+merge/154416 ? [08:49] tsdgeos, looking... [08:50] tsdgeos: we can remove it if its not needed, yes. I guess it will be needed at some point tho... [08:51] tsdgeos, btw... what's wrong with that function? [08:51] MacSlow: unused [08:51] tsdgeos, but how does the Dash get activated then... (asking because me still being new to QML) [08:52] mzanetti: not sure, we are already "showing the dash" when showing the launcher, or when clicking in the dash button, so obviously we know how to do it in a different way [08:52] MacSlow: it's connected somewhere else [08:52] tsdgeos: I guess this is more for the desktop szenario where the whole thing is hidden [08:53] tsdgeos: not about switching to the home lens [08:53] mzanetti: sure, that may be needed by then [08:53] yeah. thats what I meant.... well. don't have a strong opinion on it [08:54] tsdgeos, I'd be ok with removing it [08:54] i just suggest removeing because i was looking at how the dash works in a general way yesterday [08:54] and having a function that does nothing kept bugging me [08:55] ack... fine with it too... [08:55] tsdgeos: Iirc yesterday you asked what a "colocated" branch is [08:55] mzanetti: yep, Saviq answered [08:55] tsdgeos: ah. mind repeating the answer for me? I missed that one [08:55] mzanetti, what git does [08:56] mzanetti, so that you go "bzr switch some_branch" [08:56] mzanetti, and it checks out that branch to your working dir [08:56] while keeping the bare repos in .bzr/branches [08:56] wait... [08:56] thats possible? [08:56] mzanetti, `bzr colo-ify` [08:56] Saviq: what's your stance on removing this function https://code.launchpad.net/~aacid/unity/removeUnusedFunction/+merge/154416 [08:56] was my first question when I joined canonocal [08:56] tsdgeos, +1 [08:56] asked the wrong people then [08:57] tsdgeos, approved it [08:57] mzanetti, it's not the best, but more or less works [08:57] but you can't move/rename the dir after [08:57] it keeps full paths to the bare repos [08:58] right... thanks. I'll see if I can make the hook work with it [08:58] mzanetti, it's a slap-on, unfortunately [09:00] mzanetti: btw i'm not using colocated branches and the hook doesn't seem to work for me either [09:00] tsdgeos: I'll cjeck [09:00] check [09:14] Saviq: looking to pick up a work item. only one left in month 5 unassigned and not in progress is 'transition to google-test/mock.' [09:16] MacSlow: can you top approve it too? [09:17] dednick, not all of the Components are yet tested (they're not split into separate work items [09:17] dednick, and generally there's much more stuff that needs tests [09:17] tsdgeos, I did [09:18] Saviq: ok, sure. i'll take a look [09:18] MacSlow: you only "comment approved", not "top approved" https://code.launchpad.net/~aacid/unity/removeUnusedFunction/+merge/154416 see Status is still "Needs Review" [09:19] tsdgeos, ah that... what about the failing/broken test? [09:19] MacSlow: read the comment [09:19] tsdgeos, ah... seen the other branch [09:19] MacSlow: i can rettrigger the test run if you prefer [09:19] tsdgeos, done [09:20] cheers [09:20] dednick, but, if you want to take on the gtest transition, that's just fine, too [09:22] dednick, it's only about the tests in plugins/, too, as those are the only C++ tests we have === alan_g|afk is now known as alan_g [09:47] tsdgeos: Saviq: this should work now: https://code.launchpad.net/~mzanetti/unity/phablet-make-check-hook/+merge/153868 [09:49] mzanetti, cheers [09:54] didrocks, davidcalle: hi! In the new 100 scopes approach, the 'command lens' will still be there? [09:54] mzanetti: i'll give it a try now [09:55] sil2100, I can see it right now in the Dash, working along 100scopes, so I guess it is. [09:56] davidcalle: oh, do I need to install something to get it working with unity from ppa:ubuntu-unity/experimental-prevalidation ? [09:56] Since when I press alt+F2 it opens the home dash ;p [09:56] sil2100, my setup is a bit messy, but I think it should work OOTB [09:57] heh, now it suddenly works! [09:57] davidcalle: thanks, it seems my system had some problems then - now it's all ok [09:57] Oh, cool :) [10:00] sil2100: confirming the alt-f2 not opening the command [10:00] sil2100: do you mind please filing a bug? [10:00] sil2100: unity upstream [10:00] tag 100scopes === alan_g is now known as alan_g|tea [10:12] didrocks: to fix it, I had to open the dash normally and then press alt+f2 [10:13] Now it opens correctly, but many command lens files anyway fail because the prev and next lens/scope keybindings with the command lens now work differently, buggily [10:13] So it's another regression I think ;) (will open a bug for that as well) [10:13] */files/tests [10:13] sil2100: open bugs! [10:13] :) === alan_g|tea is now known as alan_g [10:51] dednick: hey! [10:51] dednick: so, you should have been aware that Francis did some work as well on the autopilot tests for unity-100scopes [10:52] Saviq: greyback: mzanetti: what's your opinion on this https://code.launchpad.net/~aacid/unity/doNotUseShellInHud/+merge/154661 ? [10:52] dednick: do you mind merging his work and yours? [10:52] dednick: then, once we get tests results without that, we can merge and rebuild and get the actual results [10:52] dednick: sounds good? [10:53] tsdgeos, +1 [10:53] tsdgeos, ah wait [10:53] tsdgeos, so we can get rid of the warning by just "&& shell.applicationManager" [10:54] Saviq: there is no shell in the hud tests [10:54] i tried that first [10:54] tsdgeos, right [10:54] but still complained [10:54] let me try again [10:54] tsdgeos, I'm just not a fan of passing everything down the tree like that [10:55] nor am I [10:55] 'cause it's gonna grow a lot [10:55] but I see why you need to do it. Perhaps we can attach a mock shell to all tests? [10:55] yeah, a mock shell I'd rather [10:55] didrocks: i had a testing branch. i believe we've now duplicated the work. lp:~unity-team/unity/libunity-7.0-breakage-tests [10:55] ok, i can do that [10:55] dednick: yeah, that's why I'm pinging you :) [10:55] did we should probably merge francis' work into there [10:55] :) ok [10:56] dednick: do you mind looking at https://code.launchpad.net/~fginther/unity/dash-tests-100-scopes/+merge/154648 [10:56] and get everything in one? [10:56] didrocks: sure. [10:56] dednick: thanks a lot :) [10:58] didrocks, should I pull cu2d r274 into production or you do? [10:59] jibel: feel free to do it [10:59] done [10:59] thanks jibel :) [11:00] dednick: do you need help? We should get that in trunk before the next hour (so that we don't block too much the tests which are taking 1h30) [11:00] didrocks: mine and his? [11:00] (and I know you will have the u1 dash in payment feature to review as well) [11:00] dednick: libunity-7.0-breakage-tests has some test fixes? [11:00] dednick: yep :) [11:00] sil2100: backlog the discussion :) [11:01] dednick: I can help you if needed [11:01] didrocks: working on it as fast as possible. i think francis changes wont cause much trouble. [11:01] great, do not hesitate if you need anything :) [11:01] didrocks: i'm just rebasing tests branch at the moment. [11:02] I'm just wondering if it wouldn't be better to rename LensBar (and all Lens* things) to Scope* instead of having both in the unity emulators [11:02] sil2100: let's not add more churn now [11:02] sil2100: we are already way too late [11:02] Ok [11:02] and still have a huge TODO list :) [11:03] mzanetti: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner/211/console ??¿?¿ [11:04] tsdgeos: I tried the aptitude thing.. doesn't work either.. its reverted and tests should pass again [11:04] ok, shall i retrigger ci? [11:04] yes please [11:07] dne [11:08] Saviq: greyback: mzanetti: https://code.launchpad.net/~aacid/unity/mockShellInHudTest/+merge/154664 better? [11:09] tsdgeos: imo you should fix the HUD to not directly access "shell" [11:09] mzanetti, we discussed that before [11:10] mzanetti, we need an object (just one) that will hold global things [11:10] sorry... the US government doesn't let me do anything else than focusing on their 555555555 pages long form [11:10] mzanetti, that's fine ;) [11:10] which just bailed out at 80% and I have to do it from scratch [11:10] mzanetti, otherwise we'll just grow a ton of "property variant something" [11:11] mzanetti, which I'm not a fan of, although I do see the argument [11:11] Saviq: no... I don't think adding a property to set the shell is the way to go [11:11] mzanetti, what else would you have in mind? [11:12] Saviq: I'd rather say components should have signals and properties to reflect their state and logic changing the Shell's behavior should be in Shell.qml [11:12] mzanetti, it's not about changing shell's behavior [11:12] mzanetti, it's not writing nothing [11:12] mzanetti, in that particular example it's just reading the list of running applications from the ApplicationManager [11:13] Saviq: not even that, is reading the kb status [11:13] if its just one I'd still vote for having a property aplicationList... anyways... feel free to ignore me... just saying how I would "fix" it [11:13] mzanetti, tsdgeos, what we could have is have "import Ubuntu.ApplicationManager 0.1" [11:13] Saviq: +1 [11:13] expose a singleton [11:14] that would probably be the cleanest ultimate solution [11:15] Saviq: problem with that is that you may bee exposing too much info to "third parties" that import that plugin? [11:15] tsdgeos, that's just a question of partitioning the API correctly [11:15] which we don't right now [11:16] so want me to work on that? or just accept my little mock for the moment and write in a blueprint the Ubuntu.ApplicationManager thing? [11:16] tsdgeos, no, for now we'll just go with your solution [11:16] tsdgeos, I'd go for a QtObject {} instead, though [11:16] ok [11:16] tsdgeos, no need for them to be visual Item {} s [11:17] right [11:18] oh, I'm flying back in the big Airbus again... [11:31] Saviq, you get a ride on the A380?! :) [11:31] MacSlow, yeah, second time [11:32] Saviq, sweet! [11:32] it's surprisingly non-different ;) [11:32] except for the fact it's huge and it takes an hour to board [11:32] Saviq, but you have a lot of more room to "run around" during the flight, don't you? [11:33] MacSlow, sure, there's enough space to run ;) [11:33] Saviq, and don't they have outside-view (forward-facing) cameras you can connect to on your tv-screen? [11:33] MacSlow, yeah, there's a bunch of cameras that you can watch [11:33] MacSlow, but in general the infotainment system is the same crap [11:35] Saviq, win32-based? [11:35] MacSlow, looked like it [11:36] MacSlow, but regardless what's it based on, the displays are crap, the touchscreens are crap, the quality is crap... [11:36] and the UI is crap [11:36] Anyone have any advice on implementing a search history for PageHeader.qml? [11:37] cyphermox: piing [11:37] nic-doffay, any requirements on the implementation? [11:39] MacSlow, it's just for testing atm. [11:39] Obviously to be extended at a later stage. [11:40] nic-doffay, easiest is to do it in JavaScript first and later bring it over to C++, when the design is right... but that's just me thinking into the blue and being still very new to QML & Co [11:41] Is there any reason to choose Javascript over QML? [11:41] nic-doffay, at least that approach allows you the fastest turn-around cycles for quick prototyping I guess [11:41] nic-doffay, not really... it's just what I've seen in examples [11:41] tsdgeos, python3-dbusmock isn't there for quantal, shall we add it to desktop-deps? [11:42] Saviq: do we use it? [11:42] tsdgeos, it's a HUD dep [11:42] tsdgeos, we might drop it, it's probably just for testing [11:42] Saviq: but only for some tests, everything still works otherwise [11:43] tsdgeos, yeah, let's drop from build_unity [11:43] or should, let me make sure [11:44] MacSlow, what examples exactly? [11:44] didrocks: done. fginther's AP test branch is just the changes i'd made already, so it's not needed. [11:44] dednick: great, mind rejecting this merge then? https://code.launchpad.net/~fginther/unity/dash-tests-100-scopes/+merge/154648 [11:45] dednick: let me approve yours [11:45] mzanetti: "file:///home/phablet/shell/Dash/DashVideos.qml:142: ReferenceError: root is not defined" is that related to what you did with the history? [11:45] dednick: link handy? :) [11:45] didrocks: https://code.launchpad.net/~unity-team/unity/libunity-7.0-breakage-tests/+merge/153607 [11:46] dednick: should I wait for the CI job to run? [11:46] with your last commit ;) [11:47] didrocks: probably :) [11:47] let's see then, looking at the code itself :) [11:47] it's about 6k lines [11:47] dednick: yeah, I've already given a look before TBH, just looking at your last commit [11:48] didrocks: dednick: I checked the autopilot parts, and they look good [11:48] sil2100: thanks! [11:48] The gtest parts, well, I hope didrocks already browsed through those ;p [11:49] yep ;) [11:49] dednick: but yay, good thing that you removed the *lens versions and replaced them with the *scope ones, that was the only thing that bothered me in Francis's branch [11:50] sil2100: yeah. i essentially just did a find/replace :) [11:51] dednick: I think that's better this way - having a LensBar and ScopeBar at once was really confusing ;) [11:51] sil2100: and i was getting loads of warnings about depricated mouse/keyboard functions being used. so i updated the keyboard/mouse work. [11:51] Saviq: yes, works fine without it, you remove python3-dbusmock or want me to? [11:52] sil2100: not sure if that is going to cause issues with older AP version or not though. I was using raring. [11:54] dednick: I think it's good to use the most recent changes here anyway, so it's good to have those modified [11:55] nic-doffay, uff.... I didn't keep the links around... [11:57] tsdgeos: history? [11:57] mzanetti: the search history thing? [11:58] tsdgeos: hmm.. would need check [11:58] nic-doffay, the history is meant to only store strings? I think QMLs ListModel is probably worth a look [11:59] MacSlow, pretty much. [11:59] For the time being at least. [11:59] I'll look into it. Thanks! [12:00] nic-doffay, don't know how easy it is to search through it... do you have to keep persistence of the history (across power-cycles)? [12:00] nic-doffay, or is the testing not that expanding? === MacSlow is now known as MacSlow|lunch [12:01] It's not that expanding at the moment. I think the best idea would perhaps be to leave it as is until more specs are received for the class. [12:01] Obviously write the further tests as the component is extended. [12:02] tsdgeos, can you do, please? [12:06] tsdgeos, ignore, /me doing [12:07] Saviq: ok, sorry [12:07] Saviq: still can do if you prefer [12:07] tsdgeos, that's fine, was otp but done now [12:07] oh we passed r500 mark [12:08] tsdgeos, it's yours, happy r500 ;) :D [12:08] weeeeeeeeeeeeee [12:17] cyphermox: ping #2 [12:17] sil2100: I think he will be there in a couple of hours [12:18] dednick: CI failed [12:18] didrocks: ah, ok, since I never know which timezone he is, since yesterday pinging did not work ;) [12:18] sil2100: he's in Canada [12:18] quebec more exactly :) [12:20] didrocks: checking [12:20] Ah, thanks :) [12:31] Might need design input for a PageHeader bug, it seems it needs more work. === alan_g is now known as alan_g|lunch === _salem is now known as salem_ [12:49] nic-doffay, what's up in there? [12:50] The layout depends on the various states Saviq . At the moment there's a bug that if you set the text the search container anchors over it. [12:50] Need direction on what to do with the class next and how to fix that. [12:51] nic-doffay, not sure what you mean there, the layout depends mostly on whether there's enough space to have the header title and the search entry next to each other [12:52] nic-doffay, if not, the search entry goes above the header title [12:52] what's the issue there? === MacSlow|lunch is now known as MacSlow [12:59] I didn't know whether to put it above or below Saviq [12:59] nic-doffay, it needs to be above the title, so that it slides down from the top [13:00] nic-doffay, but it's like that already [13:02] Not when I set it from my test. [13:02] Saviq, ^ [13:03] The label that is. [13:04] nic-doffay, it depends on the width of the item, maybe it's wide enough that it fits side-by-side? [13:05] sil2100: what'su p? [13:05] It's wider Saviq [13:05] nic-doffay, can you show your test please? [13:06] didrocks, you published autopilot-qt? [13:07] cyphermox: yeah, you pushed the fix for powerpc a little bit too late (the daily started before) so the process was stuck, I just rerun it and published while I was at it :) [13:07] tsdgeos: found one oddity in my trying to use ./run_on_device, my canonical ssh key isn't the default id_rsa.pub, it was id_rsa_canonical.pub [13:07] Saviq, https://pastebin.canonical.com/87390/ http://tinypic.com/view.php?pic=nqveyr&s=6 [13:07] didrocks: that's weird, I had rerun it after it landed too [13:07] I really thought it was good, there must have still been a little something wrong [13:07] OH [13:07] nic-doffay, ah you mean they don't fit next to each other? [13:07] cyphermox: probably, anyway, no worry :) [13:08] Yes. [13:08] didrocks: the old source was probably not superseded yet or something [13:08] nic-doffay, yeah, that wasn't taken into account properly there [13:08] nic-doffay, "narrowMode: parent.width < units.gu(60)" [13:10] cyphermox: yeah, probably [13:10] cyphermox: anyway, thanks for the fix! now in distro :) [13:10] nic-doffay, should instead check if parent.width > label.contentWidth + units.gu(40) or so [13:10] cyphermox: you probably have the other stacks still to look at [13:10] I'll experiment Saviq , thanks. [13:11] yup === mmrazik_ is now known as mmrazik [13:26] didrocks: I think libindicator also ran too early, it didn't catch the revert of indicator-ng changes, I'd rerun it unless you think that's a bad idea [13:27] cyphermox: sure, please do :) [13:29] also re: your hack for autopilot-qt in watch-ppa... [13:29] that's all that was missing really ;) [13:29] but I wonder if launchpad can't tell us which architectures are targetted by source upload XYZ instead [13:32] cyphermox: I know the long term plan for it [13:32] cyphermox: just I want to have time for putting under tests [13:32] before refactoring [13:32] ok [13:34] hmm crap that won't work [13:34] didrocks: just rebuilding, I can see the branch for jenkins is updated but the version to upload didn't get bumped [13:35] e.g. it's still trying to make 12.10.2daily12.03.21, which is obviously already published, so it skips right back to the check phase [13:35] hum [13:35] this can wait until tomorrow though [13:35] cyphermox: how are you running it? [13:35] there's effectively no change [13:35] ah [13:35] I did ./cu2d -R indicators libindicator [13:35] ok [13:35] and libindicator has no change? [13:36] it's a revert of a change we don't want in [13:36] yep [13:36] one sec [13:36] looking at the branch [13:36] you'll see the latest commit in /var/lib/jenkins/cu2d/work/head/indicators/libindicator [13:36] cyphermox: ah, but [13:37] libindicator is not published [13:37] to distro [13:37] what do you mean [13:37] no, it's in the PPA [13:37] cyphermox: ok, well, nothing to worry in this case, isn't it? [13:37] well, I see it as a bug [13:37] why? [13:37] we shouldn't upload to distro a change + it's revert [13:37] its* [13:37] it's an explicit feature in the code [13:38] to avoid uploading to distro an "empty change" [13:38] hmm [13:38] isn't the reverting commit explicitly a new change? [13:38] kgunn, how did that affect you? it doesn't matter which ssh key is sent [13:38] cyphermox: it's not from the distro point of view [13:38] no, i understand that [13:38] but how do you detect this? [13:38] cyphermox: comparing to latest released version [13:39] you're comparing every commit to every other commit? ;D [13:39] ah [13:39] released being "in distro" [13:39] I guess that makes sense then, yeah [13:39] kgunn, unless you changed your default to use the canonical one? [13:39] cyphermox: no, I forgot that idea :p [13:39] kgunn, in which case ssh'ing onto the device would fail? [13:39] cyphermox: in that case, if you don't want the ppa to have the change [13:39] cyphermox: you can just remove the package from the ppa [13:39] didrocks: nah it's fine, I understand [13:39] ok ;) [13:39] but to be clear, until we have a new commit [13:40] this can all wait until tomorrow and should be fine [13:40] nothing will be "good to publish" [13:40] yeah, I get it now [13:40] even tomorrow [13:40] if nothing more is in the branch :) [13:40] of course if you compare the code from the previously uploaded to distro with that you have now, there are no code changes [13:40] cyphermox: yeah, we should really see the ppa as a "place for validation", but the real source of truth to know if we want to do something is the distro [13:40] didrocks: right, the ppa won't have the right thing, but indicators will be green and not try to upload something it shouldn't === alan_g|lunch is now known as alan_g [13:41] exactly [13:41] kgunn, we should probably use ssh-copy-id and prompt for the password setup-time [13:42] Saviq: yep...busy right now...i'll interact in a bit [13:42] kgunn, sure [13:48] kgunn: yes that key thing happens here too, not sure how to easily solve that other than adding a parameter to let you set which key you want to use === mmrazik is now known as mmrazik|afk [14:23] meh, my raring doesn't like the hangout stuff much [14:24] firefox died like 4 times :-/ [14:24]