[08:36] <cimi> hola albert (tsdgeos)
[08:36] <cimi> back from holiday! yahoo
[08:37] <cimi> anything I should take care of immediately that should have my attention?
[08:37] <tsdgeos> cimi: hi, welcome back :)
[08:37] <tsdgeos> cimi: nothing urgent that i can remmeber
[08:37] <tsdgeos> cimi: i made a small branch to fix your social-cards branch to unblock pstolowski but it's not urgent
[08:38] <tsdgeos> just have a look at it when you have time
[08:38] <cimi> tsdgeos, I do
[08:39] <cimi> not much mails to read
[08:39] <cimi> *many
[08:39] <cimi> easter was quiet
[08:41] <tsdgeos> yep :)
[08:45] <dednick> mzanetti: I've been given some mail for you from office to give to you in Prague. It's in my bag, but dont let me forget :)
[08:45] <mzanetti> dednick, hah, ok. I'll try to remember
[08:45] <mzanetti> it's probably the Priority Pass
[08:58] <pstolowski> cimi, hey! social-actions silo looks good functionality-wise (please also update my test scope; there's a new click pkg in the src tree). but i think the placement of the buttons looks a little weird, i expected them the be overlaid on the card's image, instead it's below (or above)
[08:58] <pstolowski> cimi, not sure if that's by design?
[08:59] <cimi> pstolowski, it is by design
[09:00] <pstolowski> cimi, ok then
[09:21] <cimi> tsdgeos, shall I merge your branch inside mine?
[09:21] <cimi> tsdgeos, or you guys can approve social-card, I fixed josh comemnt
[09:21] <cimi> comment
[09:21] <tsdgeos> cimi: i'd leave it as is, less silo changes needed
[09:22] <cimi> ok
[09:22] <cimi> tsdgeos, josh comment fixed
[09:24] <tsdgeos> oki
[11:23] <cimi> pstolowski, tsdgeos I started asking patricia on the visuals, but I say that if we have the functionality working we can get this merged then we'll look after the visuals at a later branch unity8 only
[12:55] <mterry> mzanetti: I naively tried to update USC (by including both wallpapers as compiled headers) and gcc on armhf chokes on it (crashes)...
[12:55] <mterry> mzanetti: afternoon  :)
[13:30] <Saviq> mterry, hey, can you please recycle https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-046/excuses.html
[13:31] <pstolowski> cimi, sounds good to me
[13:36] <mzanetti> mterry, hey ho
[13:36] <mzanetti> mterry, that's odd
[13:36] <mzanetti> mterry, but why are they compiled in anyways... can't they be read from the fs?
[13:38] <mterry> mzanetti: that's how they were done in past...  I was just trying to reduce delta for this update.  But I agree, could/should be read from fs for convenience.  I'm looking at just updating the one phone wallpaper as a half-way step
[13:38] <mterry> Saviq: sure
[13:38] <mterry> Saviq: done
[13:38] <mzanetti> mterry, sounds like a waste of memory too
[13:38] <mterry> mzanetti: well if we load both images, yeah
[13:39] <mzanetti> mterry, so I figure the wallpaper update won't happen for OTA-10 anyways
[13:39] <mterry> mzanetti: yeah that's my recommendation  :)
[13:39] <mterry> mzanetti: I'd rather do this update right, which seems like it will involve retooling USC a bit
[13:39] <mzanetti> agreed
[13:39] <mzanetti> lets target OTA-11
[13:45] <mterry> mzanetti: another issue that struck me when looking at USC source -- so now that tablet and phone are different images, and we're looking at multiple monitors, some in portrait, some in landscape, do we show different backgrounds depending on monitor form factor?  Or is there one background that we pick based on the device's form factor and just rotate it
[13:45] <mterry> (similar question to yesterday's rotation question)
[13:46] <mzanetti> hmm... can't answer this one right now tbh
[13:47] <mzanetti> there's 2 things: should the wallpaper on the large screen be a different one than the one on the small screen? a question for design really
[13:48] <mterry> mzanetti: yeah.  I don't know if they thought through the ramifications of two different wallpapers
[13:48] <mzanetti> the other: if it should be the same. how are optimizing things? If the phones need to load some 4k images, it's slowing things down unneccessarily
[13:48] <mterry> mzanetti: right?  that bg they gave us is huge
[13:48] <mzanetti> yeah
[13:48] <mzanetti> it highlights the rotation bug a bit more
[13:48] <mzanetti> which is why I don't want to land it for OTA-10 after all
[13:49] <mterry> mzanetti: we could go the enablement way and have one optimized bg per device  :)  But that's obviously a pain to maintain
[13:49] <mterry> mzanetti: first boot can optimize an image though
[13:49] <mzanetti> I'd rather have some sets shipped in unity
[13:49] <mzanetti> yeah. or that
[13:50] <mterry> mzanetti: and every time u8 sees a new monitor, it can quickly optimize one for that monitor, stick it in /var/cache/ somewhere
[13:50] <mzanetti> sounds like that'd be a good idea anyways. whenever we require a new size for a screen, just cache it on disk
[13:50] <mterry> oh I guess user session, so ~/.cache
[13:51] <Saviq> thumbnailer!
[13:51] <mzanetti> Saviq, no
[13:51] <Saviq> I know ;P
[13:51] <mzanetti> but yeah
[13:51] <mzanetti> I'll create something at some point
[13:51] <mzanetti> I need this too often, really
[13:51] <mzanetti> the queueing of notifications is annoying as hell
[13:52] <mterry> mzanetti: USC should use the same mechanism
[13:52] <Saviq> well, I know why not thumbnailer for usc, why not elsewhere/
[13:52] <mzanetti> Saviq, because michi says this is out of scope
[13:52] <mzanetti> Saviq, I had that discussion for a while
[13:52] <Saviq> whaat? caching images is out of scope? what is the scope then?
[13:52] <mzanetti> extracting media artwork from files
[13:53] <mzanetti> but they better be not special in any way
[13:53] <mzanetti> the fact that it works for some images is merely an accident
[13:53] <Saviq> why does it even support images then, that's not "extracting media artwork"
[13:53] <mzanetti> ...
[13:54] <Saviq> ok well, I'll put it in scope somewhere
[13:54] <Saviq> more of an SDK topic really
[13:54] <mzanetti> yeah
[13:54] <mzanetti> Saviq, when doing so: it should work for remote images and images in qrc files
[13:55] <Saviq> mzanetti, that last one might be tricky, but sure
[13:55] <mzanetti> given that our sdk templates for apps are using qrc files by default
[13:55] <mzanetti> and the remote image case is really the most useful one
[13:55] <Saviq> well, that's obvious
[13:55] <mzanetti> Saviq, well, if this is gonna be a new component, it will probably be in-process
[13:55] <Saviq> mzanetti, but we need the default image provider in Qt to be overridable TBH
[13:55] <mzanetti> and with that have access to qrc contents
[13:56] <Saviq> mzanetti, unlikely to be in process as a whole
[13:56] <Saviq> need a central DB and such
[13:56] <Saviq> well, or maybe not
[13:56] <mzanetti> Saviq, the SDK already "overrides" the default image provider (overriding is the wrong word - rather extending)
[13:56] <Saviq> maybe can cache in ~/.cache/$app
[13:56] <mzanetti> yeah, I'd go for app-local
[13:56] <Saviq> mzanetti, the default *image* not, the provider :P
[13:56] <Saviq> EWEIRDCOMMA
[13:57] <mzanetti> in any case, I'd be ok with having another provider and using image://cached/file:///foobar.png
[13:57] <mzanetti> would leave the option open to not use it
[13:57] <mzanetti> anyhow, gotta jump to a meeting now
[13:57] <Saviq> I'd leave the option out
[13:58] <Saviq> or maybe make it opt-out rather than opt-in
[13:58] <mzanetti> wfm, but it should be possible to opt-out at least
[13:58] <mzanetti> remote content might change without changing the path
[13:58] <mzanetti> etc...
[14:04] <mzanetti> ok. that meeting was quick
[14:04] <mzanetti> I basically said "ok" 3 times and that was it :D
[14:08] <mterry> Saviq, mzanetti: Guess what I realized I hadn't seen in forever?  The "3-power-button-press" bug
[14:08] <ltinkl> mzanetti, oh, something regarding the modal notifications background?
[14:08] <mzanetti> ltinkl, ?
[14:08] <mzanetti> you mean from design?
[14:08] <ltinkl> mzanetti, yea, meeting == design
[14:09] <mzanetti> no... was a meeting ith HR
[14:09] <mzanetti> well I did talk to design today, but only about the converged stages
[14:16] <mterry> Does desktop unity8 session work for anyone else?  I just get a black screen and nothing obviously wrong in unity8.log
[14:16] <tsdgeos> mterry: works here
[14:16] <tsdgeos> mterry: you may have the gst problem
[14:16] <tsdgeos> did you fix it/have it?
[14:16] <mterry> tsdgeos: oh right...
[14:16] <mterry> tsdgeos: I remember being pointed at that before and it did help with one of my testing users
[14:17] <tsdgeos> try again then :)
[16:05] <Saviq> mterry, hey, can you please publish https://requests.ci-train.ubuntu.com/#/ticket/1206
[16:05] <mterry> sure
[16:07] <mterry> Saviq: packaging diff looks ok, but looks like you intentionally added "XS-Testsuite: autopkgtest" ?  That shouldn't be needed anymore.  It's automatically added.  But it's harmless
[16:12] <mterry> Saviq: "Publish failed: qtmir-gles has merges in bad states.
[16:12] <mterry> unity8 has merges in bad states"
[16:20] <Saviq> mterry, I *removed* it
[16:21] <mterry> Saviq: for unity8, it got added
[16:21] <mterry> Saviq: I guess by mzanetti, not you
[16:21] <Saviq> mterry, ah yes, because train builds packages on trusty, which does not add
[16:21] <Saviq> automagically
[16:21] <mterry> trusty yikes
[16:21] <Saviq> (source ones)
[16:21] <mterry> I guess that makes sense
[16:22] <Saviq> mterry, all ACKed now
[16:30] <mterry> Saviq: published
[16:32] <mterry> mzanetti: I'm looking at the usageMode calculation code for bug 1564351.  In determining longEdgeWidth, we should use the screen size, not the window size.  But then I'm leery of just using Screen.height/width, because that's only one of the monitors (right?  Is it monitor 0?).  And it's harder to mock I guess.  Do we have a better solution?  Or maybe this
[16:32] <mterry> should just wait until usageMode gets a rethink
[16:32] <ubot5`> bug 1564351 in unity8 (Ubuntu) ""Swipe from the left edge to open the launcher" - do not work on the desktop" [Undecided,Confirmed] https://launchpad.net/bugs/1564351
[16:39] <mterry> mzanetti: guh nm.  We don't need to use Screen size there.  I was brain-farting
[20:26] <Saviq> mterry, whaa¿? http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity8 the fail! is FAIL!  : qmltestrunner::Wizard::test_accountPage() function returned unexpected result
[20:26] <Saviq>    Actual   (): tzPage
[20:26] <Saviq>    Expected (): accountPage
[20:26] <mterry> hrm
[20:26] <Saviq> please recycle, and if you can explain how did we get tzPage, I'm all ears :P
[20:26] <mterry> recycled...
[20:27] <mterry> Saviq: tzPage is before accounts...  And its "next" button isn't enabled if a timezone isn't selected... So something might have gone wrong there
[20:29] <Saviq> mterry, but we disabled tzPage
[20:29] <Saviq> ah wait we didn't?
[20:29] <Saviq> right
[20:29] <mterry> naw
[20:30]  * Saviq got lost in all we did
[20:30] <mterry> Saviq: :)
[20:30] <Saviq> well ok, one more to the "flaky test" bin...