[07:22] <tsdgeos> bzoltan_: back sorry i had to leave early yesterday, had to accomodate for me forgetting my bag and come back after 15min of walking on the rain :D
[07:37] <bzoltan_> tsdgeos: :) No worries
[07:38] <bzoltan_> tsdgeos: we had talked about the topic with other folks.
[07:38] <bzoltan_> tsdgeos:  we can recap if you wish.
[07:39] <tsdgeos> bzoltan_: that'd be great :)
[08:17] <tsdgeos> Saviq: merged already?
[08:19] <bzoltan_> tsdgeos:  do you want a hangout or mumble?
[08:19] <tsdgeos> bzoltan_: no strong preference
[08:20] <bzoltan_> tsdgeos: https://plus.google.com/hangouts/_/calendar/em9sdGFuLmJhbG9naEBjYW5vbmljYWwuY29t.g04rj4pc565qsh6humb980bt1k?authuser=0
[08:59] <tsdgeos> pstolowski: so https://code.launchpad.net/~stolowski/unity8/pkg-version-into-varlib/+merge/272398 means you stop doing a dpkg -l on runtime on the plugin?
[09:02] <pstolowski> tsdgeos, yes
[10:07] <mzanetti> greyback_, you don't happen to know of a way where I can figure the connected screens in qml?
[10:08] <greyback_> mzanetti: the multimonitor branch has a qml Screens plugin, which returns a model of the screens
[10:08] <mzanetti> greyback_, qtmir?
[10:08] <greyback_> yeah
[10:09] <mzanetti> ah... I was reading through the unity8 multimonitor branch
[10:09] <mzanetti> thanks
[10:10] <mzanetti> perfect, just what I was looking for
[10:11] <greyback_> cool
[10:39] <Saviq> tsdgeos, "merged already"?
[10:39] <tsdgeos> Saviq: nothing :D ignore me
[10:39] <Saviq> ack
[13:07] <pstolowski> mzanetti, hey, i'm going to land my unity8 change in silo 35
[13:07] <mzanetti> Saviq, you ok with that? ^
[13:08] <mzanetti> pstolowski, saviq is currently landing the things for us, please sync with him on conflicts
[13:08] <mzanetti> pstolowski, apart from that, I'm fine with landing it
[13:08] <Saviq> pstolowski, you rebuilt today? there was a unity8 landing overnight
[13:09] <pstolowski> Saviq, yes, I rebuilt ~2hrs ago
[13:09] <Saviq> pstolowski, ok go for it then, leave a note to QA that they're packaging changes alone
[13:09] <Saviq> so they don't spend a lifetime testing it
[13:10] <pstolowski> Saviq, it's packaging change for unity8 only, in the plugin there is actual code change for this fix
[13:10] <Saviq> pstolowski, sure, I mean so they don't spend a lifetime testing the shell
[13:11] <pstolowski> Saviq, ah, ok, yeah
[13:17] <Saviq> ltinkl, dropped bug #1504538 on you since you're the last that touched the screen grabber :)
[13:17] <ubot5`> bug 1504538 in unity8 (Ubuntu) "Screenshots are not orientated properly" [High,Triaged] https://launchpad.net/bugs/1504538
[13:17] <tsdgeos> ltinkl: reportingPage vs reporting_page ?¿
[13:17] <ltinkl> tsdgeos, ye, working on it :)
[13:18] <tsdgeos> k
[13:19] <ltinkl> Saviq, hmm, unlikely I broke something there... but let's see
[13:20] <Saviq> ltinkl, oh no, I'm not saying you broke it
[13:20] <Saviq> ltinkl, just you touched it last, so might as well fix the bug :)
[13:20] <ltinkl> Saviq, haha, fair enough :)
[13:20] <Saviq> ltinkl, not critical of course
[13:20] <Saviq> ltinkl, on that note, we should have a test for the fix you made last night
[13:21] <ltinkl> Saviq, which one? the plaintext?
[13:21] <Saviq> feed some \n\n into a notification and check that lineCount ends up expected
[13:21] <Saviq> yup
[13:21] <ltinkl> Saviq, ok
[13:21] <Saviq> ltinkl, but that, too, is medium prio
[13:21] <Saviq> will add a bug so we don't forget
[13:23] <ltinkl> Saviq, thx
[13:24] <Saviq> mzanetti, noticed we're not rotating in windowed mode, that on purpose?
[13:24] <Saviq> or just Not Yet There™?
[13:24] <mzanetti> Saviq, not really on purpose, no. more like not implemented yet
[13:24] <Saviq> ack
[13:26] <Saviq> ltinkl, bug #1504549
[13:26] <ubot5`> bug 1504549 in unity8 (Ubuntu) "No unit test for multiline notifications" [Medium,Triaged] https://launchpad.net/bugs/1504549
[13:26] <ltinkl> Saviq, ack
[13:37] <dandrader> mzanetti, what's the URL to that silos page?
[13:38] <Saviq> dandrader, https://requests.ci-train.ubuntu.com/
[13:39] <dandrader> Saviq, thanks
[13:39] <mzanetti> dandrader, hey, about this one: https://code.launchpad.net/~dandrader/unity8/noStretchOnResize/+merge/271604
[13:39] <mzanetti> dandrader, just to make sure we're not both waiting on each other...
[13:40] <mzanetti> so far my assumption is you'll fix the out-of-sync resizing
[13:40] <mzanetti> but we're not going for any outline or something that would require design interaction
[13:40] <mzanetti> does that match with your state on it?
[13:41] <dandrader> mzanetti, I've a big update in the works in https://code.launchpad.net/~dandrader/unity8/noStretchOnResize-WIP
[13:41] <dandrader> mzanetti, gonna push to that MP once it's ready (almost there)
[13:41] <dandrader> mzanetti, a much larger change though
[13:42] <dandrader> mzanetti, yes, no outline
[13:44] <mzanetti> ack
[14:04] <Saviq> ltinkl, mzanetti, https://code.launchpad.net/~lukas-kde/unity8/platformPlugin/+merge/273974/comments/691480
[14:05] <mzanetti> Saviq, don't think so... in pocketPC mode you still don't want to shut down the phone
[14:05] <ltinkl> Saviq, ye a good question :) I tend to think a phone is still a phone, with just some external devices connected
[14:05] <mzanetti> well, I guess design could convince me otherwise...
[14:06] <mzanetti> we've discussed this for a while this morning and came to this conclusion
[14:06] <mzanetti> Saviq, as indicated by the bug kgunn reported, he seems to expect this particular thing to still behave like a phone too
[14:07] <mzanetti> unless design comes up with some more complete story around it, IMO this is the best we can do
[14:07] <mzanetti> s/unless/until/
[14:07] <Saviq> ok
[14:07] <Saviq> ltinkl, you mention some supported values (like computer, laptop etc.) in the doc
[14:08] <Saviq> ltinkl, but then use only one of them (and two others) in the code
[14:08] <Saviq> that on purpose?
[14:08] <kgunn> mzanetti: i honestly didn't think about it until i just read saviq's comment
[14:08] <ltinkl> Saviq, yup, our devices don't get detected, so the property is empty; unlike regular laptops/PCs
[14:08] <kgunn> and i do think we'll likely need to change policies there somehow
[14:09] <kgunn> e.g. mouse movement should also wakeup screen
[14:09] <Saviq> oh yeah, that's for sure
[14:09] <mzanetti> kgunn, definitely... silo0 actually did that
[14:09] <ltinkl> kgunn, the phone screen?
[14:09] <Saviq> ltinkl, both screens
[14:09] <Saviq> ltinkl, and phone screen if there's no external one, I'd say so
[14:09] <ltinkl> Saviq, why the phone? there's just the notice
[14:10] <ltinkl> Saviq, ah right, in case of no monitor attached
[14:10] <Saviq> or maybe suspending the phone should disconnect the mouse so they can both go to sleep
[14:10] <kgunn> well, there is a potential of a configuration w/o a screen too
[14:10] <kgunn> s/screen/external monitor
[14:10] <ltinkl> ye
[14:10]  * Saviq wonders if BT connection can be established when phone deep-sleep
[14:11] <mzanetti> yes
[14:11] <ltinkl> well I still do think that for this very case of power button, it should dim the screen on the phone and bring up the power dialog on a PC
[14:11] <Saviq> then kbd/mouse input should wake yeah
[14:11] <Saviq> ltinkl, eek, so unexpected
[14:11] <Saviq> ltinkl, you need to do one, or the other :)
[14:11] <Saviq> not both
[14:11] <mzanetti> Saviq, in deep-sleep, it wakes up like twice a minute for a few secs and works through things
[14:11] <Saviq> mzanetti, ack
[14:11] <mzanetti> there's a chance the mouse gave up in the meantime... but normally it would work
[14:12] <Saviq> and if it doesn't straight away you'd just press the power button on the phone
[14:12] <ltinkl> Saviq, why unexpected? people are used to their phone power button to handle the screen, not to shutdown; why change it depending on whether we get a mouse connected?
[14:12] <Saviq> and if connected to power, it would work because it won't deep sleep
[14:13] <Saviq> ltinkl, if it blanks the phone screen (I'm not saying it shouldn't), it shouldn't show the dialog
[14:14] <Saviq> ltinkl, because then you press the phone power button to see the clock (when we have the phone working as a phone still despite an external screen)
[14:14] <Saviq> and the dialog comes up
[14:14] <ltinkl> Saviq, well wait... it doesn't show the dialog :)
[14:14] <Saviq> or something
[14:14] <mzanetti> yeah, I'm with ltinkl here... even if I dock my phone to a pc, I still expect the power button to act phone-ish, not like the Power button on my laptop
[14:14] <Saviq> ltinkl, owait, I misunderstood
[14:14] <ltinkl> seems so :)
[14:14] <Saviq> ltinkl, I read "show the dialog on the PC"
[14:14] <Saviq> as "show the dialog on the external screen"
[14:14] <ltinkl> in "PC mode"
[14:14] <ltinkl> like a true PC, desktop mode
[14:15] <Saviq> ltinkl, you mean, *on a PC* ;)
[14:15] <Saviq> not in PC mode
[14:15] <Saviq> ltinkl, mzanetti, should it also dim the external screen do you think?
[14:15] <mzanetti> right now I'd say yes
[14:15] <ltinkl> can't do
[14:15] <ltinkl> can we?
[14:15] <mzanetti> but again, I'd allow design to convince me otherwise if they come up with a complete story
[14:15] <Saviq> sure we can
[14:16] <Saviq> ltinkl, just disable the output
[14:16] <Saviq> ltinkl, screen suspends
[14:16] <ltinkl> how do we dim the external monitor?
[14:16] <ltinkl> ah ok
[14:16] <Saviq> what your laptop does today
[14:16] <Saviq> I think we actually do that with the phone already
[14:16] <Saviq> lemme connect it to my monitor
[14:16]  * mzanetti waits for the crash :D
[14:16] <ltinkl> well I was thinking "dim == change the brightness" which we can't do obviously
[14:17] <ltinkl> (for an external monitor)
[14:17] <mzanetti> there are some that allow that too
[14:18] <greyback_> mir doesn't have any knobs for that (yet?)
[14:18] <mzanetti> sounds like we found some new trello cards
[14:18] <mzanetti> handling display/kbd brightness buttons
[14:19] <ltinkl> Saviq, from my MP: "To get access to platform properties like form factor to be able to distinguish whether we run on a PC or on a phone/tablet."
[14:19] <ltinkl> Saviq, "on _a_ PC"
[14:19] <ltinkl> :)
[14:19] <greyback_> as it's relevant, mir is gaining api to allow shell send hint to clients of the form factor the shell has decided
[14:21] <Saviq> ltinkl, I think morphis might be interested in the chassis bit (re: bluetooth device class)
[14:22] <morphis> Saviq: for sure
[14:22] <Saviq> ok no, we just go *black*
[14:22] <mzanetti> heh :D
[14:22] <ltinkl> morphis, hi, what do you need it for exactly?
[14:22] <Saviq> morphis, https://code.launchpad.net/~lukas-kde/unity8/platformPlugin/+merge/273974
[14:23] <Saviq> http://www.freedesktop.org/wiki/Software/systemd/hostnamed/
[14:23] <morphis> ltinkl: setting the bluetooth device class
[14:23] <ltinkl> morphis, setting? isn't that what the device already provide?
[14:23] <morphis> ltinkl: it isn't set in hardware
[14:23] <ltinkl> morphis, ah
[14:23] <morphis> you have to configure that once you startup the bluetooth stack
[14:24] <ltinkl> morphis, is it bluez5 btw?
[14:24] <morphis> yes
[14:24] <ltinkl> morphis, http://api.kde.org/frameworks-api/frameworks5-apidocs/bluez-qt/html/index.html
[14:24] <ltinkl> morphis, there you go
[14:24] <morphis> hostnamed is one of the things we're using
[14:24] <Saviq> ltinkl, I think you're missing the point
[14:25] <ltinkl> Saviq, ye maybe :)
[14:25] <morphis> ltinkl: I don't need anything to access bluez5 :)
[14:25] <Saviq> ltinkl, morphis maintains the BT stack for us :)
[14:25] <ltinkl> ah yes, that was the missing point :)
[14:25] <morphis> :)
[14:25] <Saviq> ltinkl, he needs somewhere to read the hardware form factor
[14:25] <Saviq> ltinkl, to set the device class appropriately
[14:26] <morphis> Saviq: the approach from https://code.launchpad.net/~lukas-kde/unity8/platformPlugin/+merge/273974 will only work for devices which provide the DMI interface
[14:26] <Saviq> seems like hostnamed could be it (we'd have to see where it gets the value)
[14:26] <Saviq> morphis, oh ok, so that wraps DMI
[14:26] <morphis> so not on our Touch devices
[14:26] <morphis> yes
[14:26] <Saviq> ok so as you were ;D
[14:26] <morphis> bluez4 did access DMI directly and now we're using hostnamed for that
[14:26] <morphis> Saviq: yeah :)
[14:26] <ltinkl> then I'd say have a look at hostnamed code; the docu says: "will be determined automatically from DMI/SMBIOS/ACPI firmware information"
[14:27] <Saviq> and we need a fallback for that on android
[14:27] <morphis> ltinkl: exactly that is what it does
[14:27] <morphis> Saviq: so right now it looks like this:
[14:27] <morphis> 1. If hostnamed is present and has the chassis property set, we will take that
[14:27] <morphis> 2. If /etc/ubuntu-touch-session.d/android.conf has the FORM_FACTOR variable set, we will use that
[14:28] <mzanetti> Saviq, summarized my thoughts https://code.launchpad.net/~lukas-kde/unity8/platformPlugin/+merge/273974/comments/691489
[14:29] <Saviq> mzanetti, already replied
[14:29] <morphis> mzanetti: +1
[14:30] <morphis> ltinkl: you might want to use the FORM_FACTOR variable as fallback too if you need more information on non-pc platforms
[14:31] <ltinkl> morphis, does it use the same values?
[14:31] <ltinkl> morphis, as hostnamed
[14:31] <morphis> ltinkl: right now it only uses smartphone and tablet
[14:31] <morphis> but I would vote for using the same values there
[14:31] <morphis> everything else doesn't make sense
[14:32] <morphis> ltinkl: but respect that this variable isn't there yet
[14:32] <morphis> I will introduce it soon for all devices (mako, flo, krillin, arale)
[14:32] <ltinkl> morphis, hmm, what I'd like to see is hostnamed uses a config file, and we fill it with our own default values for the known products
[14:32] <Saviq> morphis, we only really need to know if we're on a pc now
[14:32] <Saviq> ltinkl, yeah, if only hostnamed accepted that upstream ;)
[14:32] <ltinkl> morphis, then you wouldn't need a separate config file
[14:32] <morphis> ltinkl: we could try to extend systemd, yes :)
[14:33] <ltinkl> Saviq, I think it would, those properties are read/write
[14:33] <morphis> they are rw?
[14:33] <ltinkl> yes
[14:33] <morphis> why that?
[14:33] <Saviq> ltinkl, we need to think about replacing that whole file with something smarter (see ubuntu-phone ML re: bluetooth device class)
[14:33] <ltinkl> man hostnamectl
[14:33] <Saviq> ltinkl, when we get there, that will definitely be one option
[14:34] <morphis> ltinkl: I see
[14:34] <morphis> ltinkl, Saviq: we could also go the way that we setup an upstart job on touch which calls hostnamectl set-chassis <value from FORM_FACTOR>
[14:34] <ltinkl> yup, that would be nice
[14:35] <ltinkl> (if we can't go with a config file)
[14:35] <morphis> ltinkl: still have to extend systemd to acccept "smartphone"
[14:35] <ltinkl> I don't see why not, the other systemd services have them too
[14:35] <ltinkl> morphis, there is a value for that already, "handset"
[14:36] <Saviq> morphis, yeah, it feels like hostnamed would be "downstream" for our whole solution for the android.conf replacement
[14:36] <Saviq> morphis, especially as we have more values than fit there
[14:37] <Saviq> but sounds like bug #1427106 could be fixed with hostnamed
[14:37] <ubot5`> bug 1427106 in ubuntu-system-settings (Ubuntu) "[System Settings] There should be a way to set a custom device name" [Low,Confirmed] https://launchpad.net/bugs/1427106
[14:37] <morphis> ltinkl: hm
[14:37] <ltinkl> Saviq, so for that bug, there is a way
[14:38] <ltinkl> Saviq, at the same service, there is PrettyHostname field that can be set
[14:38] <morphis> ltinkl: that is doable if we take "handset" for our phones
[14:38] <ltinkl> Saviq, which is basically your custom device name
[14:38] <morphis> ltinkl, Saviq: https://github.com/systemd/systemd/blob/master/src/hostname/hostnamed.c#L101
[14:39] <ltinkl> morphis, haa nice, so /etc/machine-info it is :)
[14:39] <morphis> ltinkl: so we have that config file already
[14:39] <ltinkl> even better
[14:39] <morphis> ltinkl: only the question if our hostnamed in the overlay-ppa already supports it :)
[14:40] <ltinkl> morphis, heh, easy to try out :)
[14:41] <ltinkl> morphis, this is krillin as of now: http://paste.ubuntu.com/12724041/
[14:41] <ltinkl> morphis, let me try to create that config file there
[14:41] <morphis> works
[14:41] <ltinkl> ok :)
[14:42] <ltinkl> morphis, you mean with your custom config?
[14:42] <morphis> so now the questions is where does /etc/machine-info come from
[14:42] <morphis> ltinkl: just added CHASSIS="handset" to /etc/machine-info and restarted hostnamed
[14:42] <morphis> then it turned up in hostnamectl
[14:42] <ltinkl> nowhere currently, I guess we need to ship it with the device images
[14:43] <morphis> not sure if we are not doing that already
[14:43] <ltinkl> no idea
[14:43] <morphis> otherwise we can easily do that
[14:44] <morphis> ltinkl, Saviq: I will take care to sort that
[14:44] <ltinkl> morphis, great, thx
[14:45] <morphis> but good that we've found this
[14:45] <morphis> then we don't need this FORM_FACTOR one anymore
[14:45] <ltinkl> heh, it now supports "watch" as well as the form factor :D
[14:45]  * ltinkl missing "brain_implant"
[14:46] <morphis> :D
[14:52] <Saviq> morphis, ltinkl, I'd say it gets generated with defaults by hostnamed
[14:53] <morphis> possible
[14:53] <ltinkl> Saviq, generated? I don't have it
[14:53] <morphis> but I doubt that on the phone if the file isn't mounted as read-write
[14:53] <Saviq> ltinkl, on phone I do
[14:53] <ltinkl> ah
[14:53] <morphis> on mako it exists
[14:53] <Saviq> but indeed on laptop I don't
[14:54] <ltinkl> so which package does it come from?
[14:54] <ltinkl> if any
[14:54] <Saviq> ooh that's where PRETTY_HOSTNAME is stored
[14:54] <Saviq> ltinkl, must come from device tarball
[14:54] <ltinkl> ok, so we can also ship the form factor thingy
[14:54] <morphis> right
[14:55] <ltinkl> on PC it's probably only detected at runtime
[14:55] <ltinkl> since a PC has a BIOS
[14:57] <tsdgeos> mzanetti: https://code.launchpad.net/~aacid/unity8/use_sdk12/+merge/273182/comments/691502
[14:58] <mzanetti> tsdgeos, mhm, fair enough
[15:11] <mzanetti> tsdgeos, but hmm... if we're going to move to 1.3 for ota8, we probably should get those fixed asap
[15:12] <tsdgeos> one is merged into staging already
[15:12] <tsdgeos> the other one let me check
[15:12]  * tsdgeos opens
[15:14] <tsdgeos> https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/abstractbutton_longpress/+merge/272926 hasn't landed yet
[15:15] <tsdgeos> or it has
[15:15] <tsdgeos> it has
[15:15] <tsdgeos> let me retriiger CI then
[15:18] <tsdgeos> done
[16:13] <TJ-> is anyone actively investigating bug 987060 ?
[16:13] <ubot5`> bug 987060 in Unity HUD "massive memory leak in unity-panel-service and hud-service when invoking the hud on Firefox profiles with large amounts of bookmarks LTS 12.04 14.04" [Critical,Confirmed] https://launchpad.net/bugs/987060