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