[02:21] <mhall119> can I build unity8 on utopic, or does it require vivid?
[02:21] <mhall119> unity8-build-deps is trying to install newer versions of packages than I have
[02:46] <RAOF> mhall119: I believe you *should* be able to build on utopic (as long as you also have the various deps-from-source, such as Mir), but vivid's a better bet.
[03:02] <mhall119> RAOF: well I'm certainly getting an error on a clean branch
[08:39] <tsdgeos> pstolowski: did you get time to produce the fields i need to implement the review modification stuff?
[08:48] <pstolowski> tsdgeos, not yet, sorry, will get them soonish
[09:23] <tsdgeos> cimi: can you do https://code.launchpad.net/~aacid/unity8/noComponentsInGeneratedCardCreatorCode/+merge/258252 ?
[09:23] <tsdgeos> mzanetti: can you do https://code.launchpad.net/~aacid/unity8/fixtestMainNavigation/+merge/258173 ?
[09:23] <mzanetti> yep
[09:23] <tsdgeos> and i'll also need a volunteer for https://code.launchpad.net/~aacid/unity8/fallbackImage/+merge/258399
[09:24] <cimi> tsdgeos, you 100% we don't need components in the cards?
[09:24] <cimi> carousel and such... (just asking weird cases)
[09:25] <tsdgeos> cimi: the component is per category, so no, the card should never need it, we can generate the code based on the component contents
[09:25] <tsdgeos> same for template btw
[09:25] <tsdgeos> generated code should not depend on template because we can know that on compile time
[09:43] <tsdgeos> MacSlow: https://code.launchpad.net/~fboucault/unity8/notifications_icon_respect_ratio/+merge/258069 for you!
[09:48] <MacSlow> tsdgeos, thx for pointing that out... I've been looking up and down my inbox and don't see any email notification regarding this
[10:17] <mzanetti> tsdgeos, running make testDashContent gives me this: http://paste.ubuntu.com/11007513/
[10:18] <mzanetti> tsdgeos, make xvfbtestDashContent passes fine though
[10:18] <mzanetti> I don't think it's related to that branch
[10:18] <mzanetti> just as a FXI
[10:18] <mzanetti> FYI
[10:18] <tsdgeos> mzanetti: hmmm, really? damnit, i had that whole test running for 2 hours here :/
[10:18] <tsdgeos> mzanetti: that's with or without my branch?
[10:18] <mzanetti> on that above branch
[10:19] <mzanetti> but the failing line doesn't seem to be the one you touched
[10:19] <tsdgeos> sure, but the thing is making it all more stable :/
[10:19] <tsdgeos> not just one
[10:19] <tsdgeos> mzanetti: you have it failing all the time?
[10:19] <mzanetti> 2 out of 2 failing with testDashContent
[10:19] <mzanetti> 2 out of 2 passing with xvfbtestDashContent
[10:21] <mzanetti> tsdgeos, tried a third time, failed again
[10:21] <tsdgeos> :/
[10:21] <tsdgeos> not here
[10:22] <tsdgeos> does runnig it standalone makes it fail too?
[10:22]  * mzanetti tries
[10:22] <mzanetti> yep. still failing
[10:22] <mzanetti> make testDashContent FUNCTION="DashContent::test_show_header_on_list_movement"
[10:23] <tsdgeos> hmmm
[10:23] <tsdgeos> let me give you a patch to try to see what's happening
[10:24] <mzanetti> now that's interesting... it's passing with GRID_UNIT_PX=16 here
[10:24] <mzanetti> but with the default of 8 it fails
[10:24] <mzanetti> probably still just timing
[10:26] <tsdgeos> mzanetti: do you actually see some animation happening?
[10:26] <tsdgeos> mzanetti: can you try http://paste.ubuntu.com/11007606/ and paste the output
[10:27] <tsdgeos> i wonder if the animation is simply not happening for you
[10:28] <mzanetti> tsdgeos, qml: 120 112
[10:28] <mzanetti> repeatedly
[10:28] <mzanetti> not sure what animation I should see
[10:28] <tsdgeos> mzanetti: the header coming down
[10:28] <tsdgeos> i guess you don't :D
[10:30] <tsdgeos> does replacing the units.gu(2) by 4 in the touchFlick help?
[10:30] <mzanetti> tsdgeos, yeah. not animating
[10:31] <tsdgeos> probably not but let's make sure
[10:31] <mzanetti> tsdgeos, yes, passing with units.gu(4)
[10:31] <tsdgeos> ok
[10:31] <tsdgeos> weird
[10:31] <tsdgeos> i guess we can increase that
[10:31] <tsdgeos> it's just to trigger a "horizontal move"
[10:31] <tsdgeos> so it doesn't matter the actual number
[10:32] <tsdgeos> just weird you need it and not me
[10:32] <mzanetti> indeed...
[10:32] <tsdgeos> pushed anyawy
[10:32]  * mzanetti reverts and pulla
[10:32] <mzanetti> pulls
[10:34] <mzanetti> ack. passing now
[10:37]  * tsdgeos shurgs
[10:38] <tsdgeos> tx for the review :)
[11:25] <dandrader_> mzanetti, are wily repos already open?
[11:25] <dandrader_> ie, can we release stuff? :)
[11:25] <mzanetti> dandrader_, not that I know of
[11:30] <Saviq> dandrader_, mzanetti, there are silos targeting wily at least http://people.canonical.com/~platform/citrain_dashboard/#?q=ubuntu%2Flanding-014
[11:31] <Saviq> http://people.canonical.com/~platform/citrain_dashboard/#?q=wily
[11:31] <mzanetti> yeah, just saw that too
[11:31] <mzanetti> I just asked sil, he said the system is ready but the higher-ups didn't formally open it yet, as it usually seems to happen
[11:31] <mzanetti> so I guess we can start preparing silos targettting it
[11:32] <cimi> tsdgeos, I need to start using Ubuntu Components 1.3, but this spits out dozens of new deprecated debug messages
[11:33] <cimi> tsdgeos, shall I first fix those, then in a later branch do the feature?
[11:33] <Saviq> pete-woods, you might want to look at lp:unity8 for a refactored QmlPlugins.cmake
[11:33] <cimi> more than dozen, fundreds :D
[11:33] <cimi> hundreds
[11:33] <pete-woods> Saviq: that's where I stole it from
[11:34] <tsdgeos> cimi: can we just introduce it in the file you need it?
[11:34] <Saviq> pete-woods, yeah, but it doesn't look current?
[11:34] <Saviq> pete-woods, ah wait, it is
[11:34] <Saviq> pete-woods, but
[11:34] <Saviq> pete-woods, qmake foo will break cross-building
[11:34] <pete-woods> Saviq: you're right, it's not quite current
[11:34] <pete-woods> will pull updates
[11:36] <pete-woods> Saviq: from the looks of it I just need to delete a few buts
[11:38] <cimi> tsdgeos, yeah but I think it complains for others...
[11:38] <cimi> tsdgeos, I receive ton of debug messages, but the debug messages aren't clear
[11:39] <cimi> tsdgeos, <Unknown File>: QML UCDeprecatedTheme: Theme.palette is deprecated. Use ThemeSettings instead
[11:39] <cimi> unknown file :/
[11:40] <Saviq> cimi, grep -r Theme.palette ;)
[11:40] <cimi> Saviq, did, MANY files :)
[11:42] <pete-woods> Saviq: I take it that QMLPLUGIN_DESTINATION is magically set by Qt now?
[11:43] <Saviq> pete-woods, no
[11:43] <Saviq> pete-woods, but you shouldn't use qmake either, that won't work in cross-building
[11:44] <pete-woods> Saviq: well I just stole your macro :p
[11:44] <Saviq> pete-woods, my macro never called qmake ;)
[11:44] <Saviq> pete-woods, because we don't install in the public dir
[11:44] <pete-woods> Saviq: ah, that explains that then
[11:45] <pete-woods> I can just set it to usr/lib/ARCH/…
[11:45] <Saviq> pete-woods, that's the only way right now
[11:45] <pete-woods> works for me!
[11:46] <Saviq> pete-woods, just a note, those macros (should actually be functions...) are meant to be wrapped
[11:46] <Saviq> so they're generic
[11:46] <Saviq> pete-woods, http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/plugins/CMakeLists.txt
[11:46] <pete-woods> there is a wrapper function right at the bottom
[11:46] <pete-woods> Saviq: yeah, I stole that function
[11:47] <Saviq> pete-woods, good, I just saw that export_* was installing to QT_INSTALL_QML by default, don't do that :)
[11:48] <Saviq> pete-woods, on that note, you might want to have a look at https://code.launchpad.net/~unity-team/unity8/refactor-qmltests/+merge/257835
[11:50] <pete-woods> Saviq: will do :)
[11:53] <Saviq> pete-woods, we need tests in cmake-extras btw..
[11:53] <Saviq> pete-woods, and re: QT_INSTALL_QML, QTBUG: https://bugreports.qt.io/browse/QTBUG-29987 - but seems they just punted it
[11:59] <cimi> tsdgeos, some warning might not be ours, since I grep for some of those warnings and they are not in unity8
[11:59] <pete-woods> Saviq: yeah, I'm using a landing of indicator-network which uses most of the macros as a sort of test at the moment
[11:59] <cimi> tsdgeos, might be sdk broken somewhere
[11:59] <pete-woods> Saviq: but yeah, need to come up with a proper testing structure
[12:00] <pete-woods> wow, marked as invalid
[12:00] <pete-woods> nice
[12:01] <pete-woods> it's amazing how difficult we are able to make each other's lives
[12:02] <Saviq> pete-woods, yeah... [testing] totally, I'm quite scared to rely on this for all our builds with no tests... refactoring this thing was a mess
[12:03] <Saviq> pete-woods, sure, unity8 is a good testing ground for it, but would rather... you know ;)
[12:04] <pete-woods> well it looks like your refactoring only significantly touches the QmlTest.cmake
[12:04] <Saviq> pete-woods, oh yeah, that's just for this
[12:05] <Saviq> pete-woods, but QmlTest.cmake should make it into cmake-extras at some poitn
[12:05] <Saviq> *point
[12:06] <pete-woods> Saviq: sure, but that file is big and scary!
[12:06] <pete-woods> patches welcome! :p
[12:06] <Saviq> ;)
[12:06] <Saviq> once it actually gets ACKed, we'll see how it goes
[12:07] <pete-woods> Saviq: do you remember the cmake variable for arch triplet, btw?
[12:07] <pete-woods> I always forget the thing, and have to scour all my projects for it
[12:07] <Saviq> pete-woods, is there one? :D /me asked gcc -dumpmachine ;)
[12:13] <pete-woods> Saviq: CMAKE_LIBRARY_ARCHITECTURE
[12:13]  * Saviq fixes qmltest
[12:15] <Saviq> pete-woods, hum hum, isn't that going to be arm for x-building?
[12:16] <Saviq> that's probably good for this, not good for my use...
[12:16] <Saviq> OTOH we're not running those tests when x-building...
[12:17] <pete-woods> Saviq: tbh I thought it pretty much did what you said, i.e. parse gcc -somethingorother
[12:17] <Saviq> pete-woods, yeah, but when cross, gcc is not gcc ;)
[12:17] <Saviq> anyway
[12:18] <Saviq> you don't want to run tests on build arch if it != host arch anyway
[12:18] <pete-woods> true, dat!
[12:27] <ChrisTownsend>  
[12:34] <tsdgeos> cimi: well not broken but updated no
[12:34] <tsdgeos> ?
[12:35] <cimi> tsdgeos, yeah, but if I write a patch that deprecates something, I make sure I don't have deprecates in my own code :)
[12:42] <tsdgeos> cimi: oh well
[18:29] <tedg> greyback, Apparently it's already done for bug 1416096
[18:29] <tedg> greyback, You should be able to use the same value
[18:29]  * tedg is sad that he didn't find an action item for charles
[18:29] <greyback> tedg: sweet
[18:30] <charles> currently it's a string; you could test for "plugged_in = (state=='charging') || (state=='fully-charged')"
[19:12] <josharenson> elopio_: do you want to review this, or should I get someone from unity? https://code.launchpad.net/~josharenson/unity8/qa_helpers/+merge/258435
[22:47] <josharenson> elopio_: re qa_helper... How do you feel about making _is_greeter_active() public so that process_helpers can assert that the greeter was visible before calling unlock? I'm not sure its necessary, but that's how it was before.
[22:53] <josharenson> elopio_: I guess the wait_for_greeter call would fail actually so there is no reason... I like the logic all contained in the module better anyway
[22:54] <elopio_> josharenson: yes, I thougth that wait will raise the exception. But as you prefer, both sound good to me.