[07:27] <dholbach> good morning
[08:34] <justCarakas> o/
[08:45] <DanChapman> good morning all
[09:40] <JamesTait> Good morning all; happy Animation Day! :-D
[10:11] <dpm> ahayzen, I installed the latest music app from trunk, it looks really really good!
[10:11] <ahayzen> dpm, thanks me and victor are testing at the moment..we're hoping this will be nearly the final
[10:12] <popey> ahayzen: shall we crank a click out?
[10:12] <ahayzen> popey, not yet still testing :)
[10:12] <popey> kk
[10:12] <ahayzen> popey, i'll ping you when we think its good
[10:13] <popey> ok. ta
[10:13] <ahayzen> hopefully this will be one of the last click builds
[10:14] <dpm> ahayzen, there is a comment on this branch about deleting the database. I understand this is only relevant to developers jumping between branches, but for users the database migration will be transparent? https://code.launchpad.net/~andrew-hayzen/music-app/remix-recent-db-changes/+merge/239665
[10:15] <ahayzen> dpm. yeah it is one way though... so you can't go back...and it will delete your recent data (no attempt to migrate as that would be quite complicated and your recent data changes anyway)
[10:16] <dpm> ok, makes sense
[10:16] <ahayzen> dpm, yeah it was just a note to testers really to expect bad things if they attempted to go back
[10:18] <dpm> ok, thanks for clarifying :)
[10:20] <ahayzen> dpm, bug 1386613 is by design but with the db changes it could be quite easy to accept files on their own now
[10:20] <ahayzen> dpm, bug 1386605 'header' you refer to is the tab header?
[10:25] <dpm> ahayzen, yeah, the tab header does not hide
[10:25] <dpm> well, it hides for a split second, and then bounces back
[10:25] <ahayzen> dpm, interesting i wonder if that is us || UITK
[10:26] <dpm> ahayzen, not sure where it comes from, but the Songs tab, the Queue page and other places behave as expected
[10:26] <ahayzen> dpm, interesting
[10:27] <ahayzen> dpm, it seems to happen on the songsPage if you release over the header (the bit with a blurred background)?
[10:28] <ahayzen> dpm, or basically *sometimes* it reappears sometimes it doesn't lol
[10:29] <dpm> ahayzen, it doesn't seem to happen to me on the songs tab. The header seems to behave and stay hidden :)
[10:29] <ahayzen> dpm, we refer to the songsPage as the page after selecting an album...and the songs tab is the tracks tab
[10:29] <dpm> until I start scrolling in the other direction, where it appears as expected
[10:29] <dpm> ahayzen, aaaah
[10:29] <dpm> ok
[10:30] <dpm> so I was talking about the tracks tab
[10:30] <ahayzen> dpm, our autopilot test names got horribly confusing at one point
[10:31] <dpm> ahayzen, gotcha. So yeah, I can reproduce it on songsPage. The tab header always reappears.
[10:31] <ahayzen> dpm, yeah weird i'll look at it when i'm back from uni
[10:32] <dpm> ahayzen, no worries, just a small thing I noticed
[10:34] <ahayzen> bug 1386628 will be fun :) i had plans for that with the old app...i wonder what is causing it to be slow with the new one as a lot has changed
[10:38] <popey> nik90: are we any closer to landing the location branch? I am finding location detection to be pretty robust now.
[10:43] <nik90> popey: I didn't look into it recently. I can review my branch and see if there is anything else that needs to be done to complete it.
[10:43] <popey> nik90: thanks.
[10:49] <popey> seb128: do you know if we have a bug filed for calendar not starting on desktop ?
[10:50] <seb128> popey, not that I know
[10:50] <popey> seb128: did you say you knew what component the issue was in?
[10:51] <popey> I am seeing 403 errors in the terminal which may or may not be related
[10:51] <seb128> popey, I think some people said it was an issue with e-d-s
[10:51] <seb128> not sure if that's true
[10:51] <popey> plausible ☻
[10:51]  * popey files a bug
[10:52] <davmor2> popey: WARNING:root:Ignoring missing framework "ubuntu-sdk-14.10" so what is the current framework?
[10:52] <popey> davmor2: adb shell ls -l /usr/share/click/frameworks/
[10:56] <davmor2> popey: -rw-r--r-- 1 root root 42 Oct 14 17:37 ubuntu-sdk-14.10.framework hmmm so it just hates me then I don't blame it :)
[10:56] <popey> are you on trusty or utopic?
[10:56] <popey> also, it's a warning
[10:59] <ogra_> so ignorant
[10:59] <davmor2> popey: utopic
[11:00] <davmor2> popey: indeed but I'm assuming I shouldn't have a warning if it is correct though right?
[11:00] <popey> yeah, dunno why it's complaining
[11:01] <mihir> popey: it runs fine when i run application on my device.
[11:02] <popey> mihir: same here, but not on desktop
[11:02] <mihir> sorry i meant machine :|
[11:02] <popey> wondering if we're missing a package or if something is newer in rtm than utopic
[11:02] <popey> odd
[11:02] <popey> oh
[11:02] <mihir> i did that on saturday before i left DC
[11:03] <mihir> and i am on utopic
[11:03] <mihir> could you pastebin the errors ?
[11:06] <mihir> popey: one more input required for calendar choice page
[11:06] <mihir> 1). http://i.imgur.com/7MyWwGh.png
[11:06] <mihir> 2).http://i.imgur.com/Vca7oLq.png
[11:09] <mihir> popey: hmm i see , i don't have sync account because of that i might be able to run on desktop.
[11:09] <nik90> popey: I updated the clock location branch at https://code.launchpad.net/~nik90/ubuntu-clock-app/implement-location-finding/+merge/231793. It seems to work fine now on my rtm stable #5 image. Woohoo. However as mentioned in the comment I would like additional people to test it and see if it works as expected since it prominently shown in the main clock page.
[11:10] <popey> mihir: i pasted the error in the bug
[11:10] <mihir> popey: yes i see
[11:11] <nik90> mihir: if you got time later, mind giving a hand at testing https://code.launchpad.net/~nik90/ubuntu-clock-app/implement-location-finding/+merge/231793, the instructions are mentioned in the MP description. No code review necessary. Just real life testing on the device.
[11:11] <popey> mihir: i think the coloured blocks should be square.
[11:11] <nik90> davmor2, balloons: I would appreciate your help as well ^^
[11:11] <mihir> popey: that means 2nd option ?
[11:11] <popey> yes
[11:11] <mihir> popey: okay great :)
[11:11] <mihir> nik90: sure will do that :)
[11:12] <mihir> popey: for your reference , we have closed all strike items :- http://pad.ubuntu.com/DnXPSYyHVF
[11:12] <davmor2> nik90: I will be doing a lot of flashing today so I can look latter when things have calmed down
[11:12] <nik90> mihir: just report back your testing results in the MP comments since I won't be online on IRC due to my exams.
[11:12] <popey> yeah, i saw that earlier mihir, nice one!
[11:12] <nik90> davmor2: no hurry
[11:13] <mihir> nik90: sure I'll comment there :)
[11:14] <mihir> nik90: all the best for our exams :)
[11:14] <nik90> thnx mate
[11:14]  * nik90 is off
[11:23] <mihir> popey: okay :)
[12:01] <dpm> zsombi, could you give us a hand with this bug? https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1386208 - we've got no idea where the purple comes from in https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1386208/+attachment/4246224/+files/purple.png so some guidance would help already
[12:03] <davmor2> popey: made the mistake of not using the sdk is now published
[12:04] <popey> hah
[12:13] <zsombi> dpm: we found this bug during the sprint, it comes from an old palette value that hasn't been specified by the UX since the color schemes got more complex than they were...
[12:14] <zsombi> dpm: the old background color of SuruDark was purple, and that color hasn't been changed since.
[12:15] <zsombi> dpm: it is a toolkit bug
[12:19] <davmor2> popey: oh by the way the http://developer.ubuntu.com/publish/webapp/packaging-web-apps/ is wrong it say 128x128 icon and it is 256x256 for myapps
[12:20] <popey> davmor2: scroll down, see big orange button "Report a bug on this site"
[12:21] <davmor2> popey: ha nice :)  I hadn't scrolled down that far :)
[12:21] <popey> davmor2: also, i think that button won't work properly, looks like it should fill fields in
[12:21] <popey> try it
[12:23] <davmor2> popey: it adds reported from and the url
[12:23] <popey> did it work though?
[12:23] <davmor2> https://bugs.launchpad.net/developer-ubuntu-com/+bug/1386662
[12:23] <davmor2> popey: ^
[12:23] <popey> nice!
[12:24]  * popey confirms
[12:24] <dpm> zsombi, ok, thanks. So is there any workaround we can use for the app? And what is the toolkit's bug number, so that we can reference it in the file manager bug?
[12:24] <t1mp> dpm: 1386208 ;)
[12:24] <t1mp> I thought we had a bug for it, but I couldn't find one
[12:25] <zsombi> dpm: I don't think we had any special bug for that, colors in general get broken when the mainview starts to do gradients, and I think it's because it starts to grab SuruGradient, and not SuruDark... But I also assigned the bug to the toolkit
[12:25] <zsombi> t1mp: dpm: there was teh MainView.backgroundColor is unusable bug...
[12:26] <dpm> t1mp, zsombi, ah, nice, thanks! So why does it not affect other apps? Can we work around it while it's not fixed in the toolkit?
[12:26] <zsombi> t1mp: dpm: so we have to get rid of teh SuruGradient theme
[12:26] <t1mp> zsombi: where is that bug?
[12:26] <zsombi> dpm: those who use gradients in teh MainView they will have probs
[12:27] <zsombi> t1mp: the MainView one?
[12:28] <zsombi> t1mp: hmm... seems it got marked as invalid?
[12:28] <t1mp> zsombi: yes, I couldn't find it
[12:29] <dpm> zsombi, from, what you are saying, I understand that they'll have problems. But basically, if an app uses a gradient there is no workaround (i.e. overriding the theme) that can be used?
[12:29] <zsombi> dpm: of course there is! but you'll get binding loops :/
[12:29] <zsombi> t1mp: cannot find it either...
[12:30] <zsombi> dpm: but we can fix it
[12:30] <t1mp> zsombi: the StyledItem is internal in MainView, so apps cannot easily override it
[12:30] <zsombi> dpm: I mean to not to use SuruGradient
[12:30] <t1mp> zsombi: this is in the MainViewStyle:
[12:30] <zsombi> t1mp: why would they? they can set Theme.name = "Ubuntu.Components.Themes.SuruDark" right?
[12:30] <t1mp>         property string theme: (ColorUtils.luminance(styledItem.backgroundColor) >= 0.85) ? "Ambiance" :
[12:30] <t1mp>                                 (isGradient ? "SuruGradient" : "SuruDark")
[12:31] <zsombi> t1mp: ^^
[12:31] <zsombi> t1mp: that does not forbid an app to use a different theme, right?
[12:32] <zsombi> t1mp: but yes, the fix is not to use SuruGradient at all!
[12:32] <t1mp> uhm. yeah
[12:32] <t1mp> zsombi: can you comment the workaround in the bug report? that's useful for the app developers :)
[12:32] <zsombi> t1mp: sure...
[12:32] <dpm> I don't think I can quite follow - i.e. I don't even know what SuruGradient is or whether we're using it in file manager
[12:34] <dpm> elopio, are you around today?
[12:38] <zsombi> dpm: once upon atime, there were three King Themes: Ambiance, SuruDark and SuruGradient. They were ruling over the apps one after each other depending on the luminance of the background and whether the lands had separate colors for header and/or footer. Then the sorcerers came and decided to dismiss SuruGradient, being the evil and thus mainenance on that has been dropped
[12:39] <zsombi> dpm: but, unfortunately the evil cannot be removed easily from the Garden of Eden, so the ancient logic choosing the ruler had staid there, which now messes up teh kingdom...
[12:39] <zsombi> :)
[12:39] <dpm> zsombi, shall we then live happily ever after? :-)
[12:40] <zsombi> dpm: we shall, once we give enough treasure to the kingdom chooser, so the SuruGradient will be ruled out for good
[12:41] <zsombi> dpm: and, as the themes themselves are not part of the public API of the toolkit, we perhaps can simply remove it from the package
[12:42] <dpm> zsombi, awesome, and what shall we then recommend to the valiant knights of the ancient order of File Manager, to set Theme.name = "Ubuntu.Components.Themes.SuruDark", or not to use a gradient at all?
[12:42] <zsombi> dpm: now, the question is if this bug is a critical one or not...
[12:43] <dpm> zsombi, it definitely isn't critical, so I'm just trying to find out the best way to remove that purple from file manager
[12:43] <zsombi> dpm: they should hope that the force is with them, and do the workaround till the bug is fixed
[12:44] <zsombi> dpm: so, may the 4th be with app developers who use gradients in their apps :)
[12:44] <dpm> thanks zsombi, may the force be with you too :)
[12:45] <zsombi> t1mp: do U wanna take the Jedi sword? ;)
[12:46] <zsombi> t1mp: or I could fix it, however this bug ain't seems to be critical...
[12:46] <zsombi> t1mp: trhe other one was
[12:46] <zsombi> ehh
[12:46] <sverzegnassi> dpm, do you have some time to talk about the docviewer-app?
[12:47] <dpm> hi sverzegnassi, sure! How are you? Are you back home already?
[12:50] <t1mp> zsombi: what's the other one?
[12:50] <zsombi> t1mp: I foudn teh bug, I'll fix it https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1356779
[12:50] <zsombi> t1mp: it was marked as invalid.
[12:50] <sverzegnassi> dpm, I'm fine! I come back home on Sunday, the return flight was definitely better than the outbound one
[12:50]  * zsombi brb
[12:53] <t1mp> zsombi: I marked the new bug as a duplicate
[12:53] <dpm> sverzegnassi, cool :)
[13:14] <dpm> t1mp, zsombi, after a quick test, it seems adding Theme.name = "Ubuntu.Components.Themes.SuruDark" to http://bazaar.launchpad.net/~ubuntu-filemanager-dev/ubuntu-filemanager-app/trunk/view/head:/src/app/qml/filemanager.qml#L273 did not quite work. Anything that I might have missed?
[13:17] <zsombi> dpm: hmm...
[13:18] <zsombi> dpm: uhh... actually it won't you're right, because the SuruGradient uses the same MainViewStyle as Ambiance is using, so changing the theme will roll back the default logic :(
[13:20] <dpm> argh
[13:25] <t1mp> dpm: then the quick fix is not to use a gradient background
[13:27] <dpm> t1mp, yeah, I've just tested that, and it seems it will be the way to go
[13:27] <dpm> thanks guys
[13:28] <t1mp> dpm: yes, for now. Until we get a proper fix in
[13:28] <t1mp> zsombi: perhaps we should add a property Item background to the MainView?
[13:29] <t1mp> hmm.. maybe that's not even needed
[13:29] <t1mp> if the MainView contents is simply being clipped behind the header, apps can simply put the background Item behind the MainView
[13:29] <zsombi> dpm: one way to get the same background is to create a rectangle and set it's z to -1
[13:29] <zsombi> dpm: then don't set the colors to MainView yet
[13:30] <t1mp> zsombi: no need to set z to -1 if the background Item is in the qml file before the MainView (not inside it)
[13:30] <t1mp> so Item { id: background }; MainView { }, or even Item { id: background; MainView { } }
[13:31] <zsombi> t1mp: well, yes, unless someone uses QuickUtils.rootItem().backgroundColor... as then teh rootItem won't be teh MainView...
[13:31] <t1mp> zsombi: or de we rely on MainView being the root item in the tree?
[13:31] <zsombi> t1mp: afaik toolkit doesn't but you never know...
[13:31] <zsombi> t1mp: well, QuickUtils is not even supported as public API...
[13:32] <t1mp> zsombi: if you put the background inside MainView, even with z=-1, it will be clipped by contentsClipper inside the MainView
[13:33] <t1mp> that is there to hide mainview contents behind the (transparent) header
[13:33] <dpm> t1mp, zsombi, that's a bit too hardcore for me, I'll go with "no gradient" for now. Now I'm getting a black actions toolbar in the header. That's ok, better than purple, but does that mean that the toolbar can only be either black or light grey? So what if I write a Dropbox app and I want it to be blue?
[13:35] <zsombi> dpm: yes, we were already talking about this, and there's a slight problem implementing that :( So we either take a color of we mak eit transparent, so teh background color will be taken. This needs design input as well
[13:35] <t1mp> zsombi: I solved it for the header divider. We can use the same approach for the panel, if design agrees
[13:37] <dpm> zsombi, what's the current logic? If there is a color set as headerColor it's SuruDark (i.e. header actions black) and if there isn't, it's Ambiance (i.e. header actions light grey)?
[13:37] <t1mp> dpm:         property string theme: (ColorUtils.luminance(styledItem.backgroundColor) >= 0.85) ? "Ambiance" :
[13:38] <t1mp>                                 (isGradient ? "SuruGradient" : "SuruDark")
[13:38] <zsombi> t1mp: dpm was asking for teh header divider solution :)
[13:39] <t1mp> the new logic for the header divider (which has not landed yet) is:             dividerColor: Qt.darker(background.headerColor, 1.1)
[13:39] <t1mp> the current/old header divider uses a semi-transparent dark image for the background
[13:40] <zsombi> t1mp: right, so we can get the background color transferred to the header colors as well...
[13:40] <t1mp> zsombi: yes
[13:41] <t1mp> zsombi: shall I take https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1356779 ?
[13:41] <t1mp> (tomorrow..)
[13:43] <zsombi> t1mp: well, you could, however that falls back on the theme autochoose, but not to teh header color chosing
[13:44] <ajalkane> dpm: Mayhaps after your changes also the "Open With" dialog works correctly?
[13:44] <zsombi> t1mp: so the one we're talking about is a different one
[13:44]  * dpm tries
[13:44] <t1mp> zsombi: ok, you keep it. :)
[13:44] <zsombi> t1mp: so you or dpm shoudl fila a bug for the above discussed one
[13:44] <t1mp> zsombi: so https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1386208 is not a dupe..
[13:44] <dpm> ajalkane, unfortunately, it doesn't :/
[13:45] <ajalkane> ah, too bad
[13:45] <zsombi> t1mp: well, partly yes, but the other part we just discussed is not
[13:45] <t1mp> Dialogs all have a light background now, that was by design
[13:45] <t1mp> ajalkane: ^
[13:46] <zsombi> t1mp: dpm: and in my vision this misscoloring is not low priority, but pretty high
[13:46] <t1mp> zsombi: you are the one who gave it Low priority 1h ago
[13:46] <zsombi> t1mp: yes, because teh app's priority was low...
[13:46] <zsombi> t1mp: unduped it, and rised to High
[13:47] <ajalkane> t1mp: I don't know if you can call it a dialog, it's a "Page"
[13:47] <zsombi> sorry, rose :D
[13:47] <t1mp> zsombi: ok
[13:47] <t1mp> ajalkane: true, a Page is not a Dialog
[13:47] <t1mp> (I was referring to the Dialog component)
[13:49] <dpm> t1mp, zsombi, ok, so I know how we can fix the purple header actions for now. Any ideas on how to fix bug 1386212 ?
[13:50] <ajalkane> It's something about ContentHubPeerPicker component.
[13:50] <ajalkane> This might work on that? Component.onCompleted: Theme.name = "Ubuntu.Components.Themes.SuruDark"
[13:51] <zsombi> dpm: well, perhaps by setting a readable color to teh text would help, right?
[13:52] <zsombi> dpm: I mean noone should expect that all components will magically work with all colors :)
[13:52] <ajalkane> aye optimally one would want the whole page to follow File Manager's theme and not have white background
[13:54] <dpm> ajalkane, where's the content hub code in the app? I can't find a reference to ContentHubPeerPicker
[13:55] <dpm> ah, found it
[13:55] <dpm> ContentPeerPicker
[13:58] <ajalkane> yeah, something like that :)
[13:58] <akiva-thinkpad> dpm, Welcome back from the sprint or whatever you were doing. I am basically a free agent at the moment, if you have any project that needs shoring up.
[13:58] <akiva-thinkpad> ajalkane, o/
[13:58] <dpm> hey akiva-thinkpad o/
[13:59] <akiva-thinkpad> \o
[13:59] <dpm> akiva-thinkpad, good work with the file manager header!
[13:59] <akiva-thinkpad> thanks; ajalkane helped a lot with it.
[14:00] <dpm> akiva-thinkpad, would you be interested in looking at these? https://bugs.launchpad.net/ubuntu-filemanager-app/+bugs?field.tag=new-header
[14:00] <akiva-thinkpad> dpm, yep!
[14:00] <ajalkane> howdy akiva-thinkpad
[14:01] <akiva-thinkpad> dpm, okay I'll see if we can close all the bugs in it then.
[14:01] <akiva-thinkpad> dpm, what is the status of the RTM; is that done now? Are there any sprints or deadlines were aiming for?
[14:05] <dpm> akiva-thinkpad, essentially we're continually working with manufacturers. We're ramping up and having biweekly milestones to fix all critical bugs for the final image
[14:06] <akiva-thinkpad> dpm, good to know. Do we know if the full suite of core apps will be used?
[14:16] <popey> akiva-thinkpad: no, thats up to the manufacturer really. all of them are in the store though.
[14:23] <akiva-thinkpad> popey, ah cool.
[14:33] <dpm> ajalkane, if you happen to be around, would you mind reviewing https://code.launchpad.net/~dpm/ubuntu-filemanager-app/kill-purple/+merge/239860 - if that one looks ok and lands, I think we should then upload to the store
[14:34] <elopio> dpm: here
[14:34] <elopio> how can I help you?
[14:35] <dpm> hola elopio, hope you had a nice flight back
[14:35] <dpm> elopio, a couple of contributors have revived the docviewer project
[14:35] <elopio> dpm: I did, thanks. It was short this time.
[14:35] <dpm> nice :)
[14:36] <dpm> elopio, so I submitted a branch to make it easier to contribute and to clean things up: https://code.launchpad.net/~dpm/ubuntu-docviewer-app/add-plugin/+merge/237545
[14:36] <dpm> elopio, it needs the tests to be adapted to current AP practices, as I think the AP code is outdated. Would you mind having a look at it?
[14:38] <elopio> dpm: so, the tests need to pass the name of the file to open in a desktop file? that's what we are missing now?
[14:39] <ajalkane> dpm: sure, I skimmed through the commit and it looks good to me. Great to get rid of the purple header actions!
[14:40] <dpm> elopio, not sure, tbh. What I saw on the tests is that they were complaining that we're using deprecated emulators modules
[14:46] <dpm> ajalkane, thanks. If it looks good to you, would you mind top-approving too?
[14:48] <ajalkane> yeah of course, sorry forgot about it
[14:48] <elopio> dpm: that is just a warning. Not necessary to fix on your MP that is already too big.
[14:50] <elopio> it's already reported here: https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1341681
[14:51] <elopio> this is the error:
[14:51] <elopio>     self.arch_dir = glob.glob('%s/obj-*' % self.build_dir)[0]
[14:51] <elopio> IndexError: list index out of range
[14:51] <elopio> I'll see what weird thing is happening there.
[14:52] <dpm> elopio, yes, that's exactly what confused me when I was looking at it last week.
[14:53] <dpm> I don't even understand why the arch_dir is required for the tests
[14:57] <elopio> dpm: well, this is something you are adding on your branch
[14:58] <elopio> 1867	+ self.arch_dir = glob.glob('%s/obj-*' % self.build_dir)[0]
[14:58] <elopio> that's not in trunk.
[14:58] <dpm> elopio, yeah, my bad, I merged another branch from someone who had taken care of the AP tests, but it was at the sprint, and I didn't have much time to look at it.
[14:59] <elopio> I think that you should be able to launch the local location binary by using just the binary name, without the full path.
[15:02] <elopio> dpm: can you make the core apps ppa for vivid?
[15:56] <karni> Anyone has experience/had problems while playing video using Video component in QML? Or would you suggest MediaPlayer? I tried webview, but doesn't seem to work in all cases.
[16:08] <dpm> elopio, sorry, got busy with something else. Yes, I can set up the PPA for vivid
[16:09] <ajalkane> Anyone know what this error is, I'm trying to run from QtCreator FileManager on device: http://pastebin.com/mzDWNWcD
[16:09] <ajalkane> Short version: ImportError: cannot import name UpstartAppLaunch, introspection typelib not found
[16:09] <dpm> elopio, actually, no, they land there from Jenkins, IIRC, so no daily builds. fginther, could we enable vivid .deb builds for the core apps in Jenkins?
[16:11] <dpm> ajalkane, looks like you've got a missing package, but I can't tell which or where (desktop or device)
[16:11] <fginther> dpm, the vivid transisiton work is in progress. How soon do you need the vivid packages in the PPA?
[16:12] <popey> dpm: robert schroll saw that last week too
[16:12] <dpm> fginther, I'm in no rush, but elopio was asking for it
[16:12] <popey> he said there was something missing but we didnt know what
[16:13] <elopio> dpm: fginther: I can install a virtual machine with utopic to install the deb. I want to see if we need the full path to launch the app when it is installed from the deb.
[16:13] <elopio> I can also build the deb here. So no rush.
[16:14] <dpm> elopio, or you can use the emulator
[16:15] <fginther> elopio, thanks for the input. Everything should be in place this week, but let us know if there is an urgent need for a specific package
[16:16] <fginther> elopio, dpm, and just FYI, please start pinging the CI vanguard (which is usually 'cihelp') in #ubunut-ci-eng. It makes it easier to record requests
[16:16] <dpm> ok, thanks fginther
[16:16] <elopio> ack
[16:17] <dpm> ajalkane, popey, looks similar to bug 1327066 - Arto, is your Qt Creator up to date, are you running Ubuntu 14.04 or 14.10 on the desktop?
[16:18] <popey> oh could be.
[16:20] <dpm> ajalkane, do you have any of these 2 packages installed? http://packages.ubuntu.com/search?searchon=contents&keywords=UbuntuAppLaunch&mode=filename&suite=utopic&arch=any
[16:57] <dpm> elopio, ok, so at least for running locally (i.e. .deb not installed), that arch_dir thing is not needed. I managed to get the tests running, but now the complaint is about the app not being able to receive an argument as the path of the document to open
[16:58] <elopio> dpm: yes, I managed to install it. autopilot will call which to find the full path.
[16:58] <elopio> dpm: so, if you call the autopilot LaunchUpstartApp to start it, you can pass the path to the file as an argument.
[16:58] <elopio> the same for LaunchTestApp
[16:59] <elopio> the only problem is when you launch the app with LaunchClickApp. That's where the only way to pass arguments is through the command line.
[16:59] <elopio> I mean, through the desktop file.
[17:01] <elopio> dpm: on the setup, you only have launch_test_application. So you just have to pass the file path as arg to launch_test_installed and launch_test_local
[17:01] <dpm> elopio, let me have a look, not sure I quite get it yet
[17:02] <elopio> you are already doing it. Not sure why it's failing for you. Let me give it a try.
[17:03] <dpm> elopio, actually, wait. So, after removing the glob.glob() line, I can get the tests to run and pass locally
[17:03] <dpm> elopio, so the question is why they fail on Jenkins. Do we just need to have that line removed?
[17:04] <elopio> dpm: I think it will work on jenkins without that line, yes. It look correct.
[17:04] <elopio> what we are missing is how to find the binary location when compiled into a build dir.
[17:04] <elopio> remember the discussions we had about passing the build path from cmake to the test scripts?
[17:05] <karni> So, I can't play a video. Anyone? http://paste.ubuntu.com/8721620/ -- This uses MediaPlayer and VideoOutput
[17:05] <karni> jut sits there, silently, nothing is happening. autoLoad and autoPlay are set to true
[17:05] <karni> path is correct (I adb pulled and was able to play the file on my PC)
[17:05] <karni> the file has been recorded with krillin.
[17:05] <dpm> elopio, not sure I quite follow. That's exactly what I'm doing: I built the app from Qt creator locally (different build and source dir) and the tests run fine - I'm using that CMakeLists.txt.user parser that reads the build dir from there
[17:06] <elopio> dpm: by removing that line, what you did is that the local compiled binary is not found, so it launches the installed binary.
[17:07] <elopio> I think that jenkins won't have a local compiled binary because it generally installs the deb or the click.
[17:08] <elopio> so jenkins will be fine. We need to find a solution to locate the compiled binary for the cases you don't want to run the installed one.
[17:08] <dpm> elopio, no, I don't have an installed binary, that is, I don't have the package installed
[17:08] <elopio> dpm: then it doesn't make any sense :)
[17:08] <elopio> maybe you don't need that line to find the locallly compiled one.
[17:09] <dpm> elopio, that's exactly what I'm saying :) The CMakeLists.txt.user parser finds the build directory and the binary
[17:10] <elopio> dpm: okay then :) I wonder why that line was added, but if it works for you without it, things should just work.
[17:10] <elopio> we need to clean the way the app is started, to copy the strategy from the other apps. But we better wait for your branch to land to avoid a bigger mess.
[17:11] <dpm> elopio, it works for me (local build), but I think Jenkins would rather follow your setup (installed package) - did you remove the glob.glob() line and then the tests passed?
[17:17] <elopio> dpm: well, I got the installed app launching.
[17:17] <elopio> the tests are failing, not yet sure why. But that part seems to work
[17:18] <dpm> elopio, are you getting the same failure as Jenkins?
[17:19] <elopio> dpm: no, I removed the glob, removed the not used import, and changed the local location to not use the arch, just to get that part skiped.
[17:19] <elopio> autopilot.exceptions.StateNotFoundError: Object not found with name 'TextArea' and properties {'objectName': 'textAreaMain'}.
[17:19] <elopio> that's what I got.
[17:20] <dpm> oh, wow, that fails in an even more interesting way
[17:20] <ajalkane> dpm: I have this file: /usr/lib/girepository-1.0/UbuntuAppLaunch-2.typelib
[17:21] <ajalkane> But I just realized this might be because the arm kit has to be updated
[17:21] <dpm> aha
[17:21] <elopio> dpm: I might be missing dependencies, because the window is empty.
[17:21] <elopio> but if it works for you, jenkins on utopic should work. Please make the change and then we will see the new jenkins results.
[17:22] <dpm> elopio, yeah, pushed the change 10 mins ago, waiting for the Jenkins job to get triggered
[17:22] <mihir> hey any idea we have changed any permission issues on desktop , http://paste.ubuntu.com/8721791/ ?
[17:24] <mihir> popey: we might have got some changes in permission i believe that's why it is failing on desktop
[17:25] <popey> mihir: permission on what?
[17:26] <mihir> popey: may be it looks like it is not able to access the online accounts :|
[17:27] <mihir> popey: if you just stop syncing it runs with no issues :|
[17:27] <mihir> popey: i might be wrong though.
[17:27] <popey> yeah, i see that.
[17:30] <popey> ahayzen: heya
[17:30] <ahayzen> popey, yo
[17:31]  * ahayzen pretends to be wide awake and alert
[17:31] <popey> hah, join the rest of the channel
[17:31] <popey> ahayzen: jouni is back tomorrow.
[17:31] <ahayzen> \o/
[17:32] <popey> How's it going today? (slow as a result of jet lag?)
[17:32] <popey> I saw you guys merging late last night
[17:32] <ahayzen> popey, good ... i was up until 5am this morning then had 9am lectures ... so not really jet lag just lack of sleep in general aha
[17:32] <popey> ahhh
[17:33] <elopio> dpm: you need to remove the unused import
[17:33] <elopio> jenkins does static checks before running the tests.
[17:33] <ahayzen> popey, but we did *lots* of landings... we just need to iron out the bugs then build a click  and hopefully this is it lol
[17:33] <popey> "that's all"
[17:34]  * ahayzen thanks dpm for testing and reporting bugs from the latest remix branch
[17:34] <ahayzen> popey, yeah "that's all"
[17:34] <mihir> popey: turning off and on again works :D
[17:34]  * mihir reminds of THE IT CROWD ;)
[17:35] <popey> ☻
[17:35] <mihir> popey: can you try ?
[17:35] <popey> mihir: what? rebooting my pc?
[17:35] <popey> sure.
[17:35] <mihir> nah
[17:35] <mihir> popey: the online account :|
[17:35] <popey> i have
[17:35] <popey> what? remove and re-add?
[17:35] <mihir> and wait for while , i just toggled , Google account off, calendar sync on-off and it has stared :|
[17:36] <popey> ok, will test that in a short while and report on the bug
[17:36] <mihir> popey: okay thanks.
[17:36] <mihir> but i am still not able to get what exactly the issue is.
[17:37] <popey> ditto, will test more.
[17:37] <popey> will try adding other accounts too
[17:37] <popey> ahayzen: Anything we need to discuss then?
[17:38] <ahayzen> popey, erm... don't think so we just need to fix the bugs and then tell u to build a click :) ... so hopefully in the next 24hrs or so
[17:38] <popey> ok!
[17:41] <ahayzen> popey, are you able to run the latest branch as well for testing purposes?
[17:41] <popey> sure thing
[17:42]  * popey pulls
[17:42] <popey> ahayzen: rev 713>?
[17:42] <ahayzen> popey, thanks :) you should notice faster startup times as *loads* of things are in async now
[17:42] <ahayzen> popey, yep :)
[17:42] <popey> ASYNC ALL THE THINGS!
[17:42] <popey> ok
[17:42] <ahayzen> literally
[17:43] <ahayzen> i've seen startup times of ~2.5-3s from ~6s :D
[17:43] <popey> blimey
[17:44]  * popey needs more music
[17:44] <ahayzen> popey, heh my device is full of music ... i've only got 3% space left lol
[17:45] <popey> erk
[17:45] <popey> installed
[17:45] <ahayzen> popey, oh yeah battery life is awesome i managed to play music on the whole of the flgiht back and the bus so like 8hrs and it only used ~50% battery :)
[17:48] <popey> blimey
[17:51] <davmor2> popey: I already posted you a link to musics but you turned your nose up to it :P
[17:52] <mihir> ahayzen: that's sounds amazing :D
[17:52] <mihir> ahayzen: also your flight was delayed little :P
[17:52] <ahayzen> mihir, yeah ... again lol ... how was your trip back?
[17:53] <dpm> ahayzen, no worries, I enjoy testing it. I loved the "old" music app. The remix looks even more awesome
[17:53] <mihir> ahayzen: don't ask tiring :P lol it took me 21 hours to reach home :P
[17:53] <ahayzen> dpm, thanks :)
[17:53] <dpm> elopio, what unused import?
[17:54] <ahayzen> mihir, haha which way did you go? east->west or west->east i forget?
[17:54] <elopio> dpm: import glob
[17:54]  * dpm hates pyflakes
[17:55] <dpm> really...
[17:56] <mihir> ahayzen: i  passed through north Atlantic ocean
[17:56] <dpm> ok, next try
[17:56] <dpm> pushed
[18:01]  * mihir screencast the video for desktop failure.
[18:18] <mihir> popey: you still around?
[18:18] <mihir> popey: if yes then short screencast , https://www.youtube.com/watch?v=zqmr4PH5Kyc&feature=youtu.be
[18:20] <mihir> popey: https://www.youtube.com/watch?v=zqmr4PH5Kyc&feature=youtu.be i got dc if you missed the link.
[18:21] <popey> mihir: thats interesting!
[18:21] <popey> didnt realise it would work after you enable the calendar while the calendar is running
[18:21] <popey> add that to the bug! ☻
[18:21] <mihir> popey: hmm yup , :D but i am not sure on which side the bug is :-s
[18:21] <popey> me either
[18:22]  * popey makes food
[18:22] <popey> brb
[18:28] <mihir> popey: no issues , commented on bug, i'll update that if i came across any solution.
[18:31] <dpm_> elopio, ok, we're making progress, but it seems Jenkins still cannot find the executable: http://91.189.93.70:8080/job/generic-mediumtests-utopic-python3/1350/testReport/junit/ubuntu_docviewer_app.tests.test_docviewer/TestMainWindow/test_read_image_file_mimeType_with_mouse_/
[18:37] <elopio> dpm_: it's trying to launch it from the build dir, even if there's none.
[18:37] <elopio> there
[18:37] <elopio> 's a method get_build_dir that I didn't fully understood.
[18:37] <elopio> and every tests calls if build_dir exists, then launch locally
[18:37] <elopio> else, launch installed.
[18:40] <elopio> a slightly better check would be:
[18:40] <elopio> if local binary exists, then launch local.
[18:40] <elopio> else, launch installed.
[18:55] <dpm_> elopio, sorry, I hadn't seen your ping. I still don't quite get it: it uses exactly the same workflow as file manager, for which Jenkins can find the executable. Where is the call that each test does to "if build dir exists"?
[18:57] <kurt___> akiva-thinkpad, I finally got my Internet back up and working! I'm still trying to get that audio recorder working so i'm gonna delete the code off the launchpad and re-do what I have in the new 14.10  SDK framework
[18:59] <kurt___> not sure if you remeber helping me with that before but i messed up the setup somehow and could not get it work starting new may help me fix it.
[18:59] <dpm_> elopio, oh, I see it, it's in every test. Hm, a bit of code duplication too
[19:13] <elopio> dpm_: yes, not nice.
[19:13] <elopio> luckily we have only a few tests. We can make some clean ups before they start to add more.
[19:15] <dpm_> elopio, indeed, I think those need cleanup. For now I just fixed the bare minimum for the tests to run and we can take care of the cleanups on a separate branch. I pushed now
[19:15]  * dpm_ crosses fingers
[19:15]  * dpm_ prays to the CI gods
[19:16] <elopio> dpm_: yes. As soon as you have that branch landed, please ping me to copy some things from the other projects.
[19:16] <dpm_> thanks elopio!
[21:25] <josharenson> Is there a reason that "Run cmake" isn't listed under the build menu in my SDK? I can't build anything (from the SDK). I have the qtcreator-plugin-cmake installed
[21:31] <josharenson> and when I build for dekstop (instead of arm) the sdk just crashes
[21:31] <josharenson> ... back to vim