[00:05] Hello, is it possible to use libhybris on the Ubuntu desktop? [00:12] Nothing_Much: what would you use it for on an Ubuntu desktop? [00:12] libhybris is a wrapper around hardware-specific android libraries; you probably don't have any of those on your desktop [00:17] slangasek: For an arm device that doesn't have drivers yet on it. [00:17] *for Linux [00:17] so you are running Ubuntu desktop on an ARM device? [00:18] Yes I am [00:18] ok [00:18] so /in theory/, you could use this to provide Ubuntu desktop through XMir on top of Mir, routing through libhybris [00:18] but I think you'll be the first to actually do this if you succeed :) === chihchun_afk is now known as chihchun [00:19] Ah well, I was going to try Wayland, though now that you mention it, I could try both, at different times. [00:20] Since this is Ubuntu though, how would I go about using XMir? [00:21] apt-get install unity-system-compositor, I believe [00:21] that's it? [00:21] oh uh oh [00:21] I forgot to mention I'm using uh.. Xubuntu [00:21] XMir won't care ;) [00:21] Oh really? Cool [00:21] https://wiki.ubuntu.com/Mir/Installing [00:24] I'd also like to see if Wayland would work, no offense. [00:24] none taken ;) [00:24] I believe you'll find the wayland story is a bit more do-it-yourself, though [00:24] oh dear [00:25] yeah that's a problem when you're dealing with a dumb consumer like myself [00:27] Okay so I got a warning and Xmir won't launch [00:28] [ 11314.194] (WW) "xmir" is not to be loaded by default. Skippin [00:28] g [00:29] hmm, I'm not sure where that's configured [00:29] do you already have the libhybris stuff installed? [00:29] Yes [00:29] ok [00:30] Do I need libubuntu-application-api1? [00:31] not 100% sure, but I think you only need libhardware2 [00:31] I got that installed already [00:31] lemme try restarting lightdm again [00:32] still software rasterizer :( [00:32] yes [00:33] you need to configure the X server somehow so that it knows to use xmir on your hardware [00:34] would that require an xorg.conf? :( [00:34] probably :) [00:34] hmm.. [00:35] well, so far no driver exists on Linux for an Exynos 5 atm, that should be where Libhybris takes its place [00:41] What would I put for the "driver" section of the conf? === Namidairo`bnc is now known as Namidairo [00:42] I don't think you need to specify a driver, only to specify that the mir module should be loaded [00:42] Oh [00:42] but you may not even need to do that; it's possible all the configuration lives in lightdm [00:42] How would I do that? [00:42] Well I did sudo lightdm restart twice [00:42] Maybe a full restart will do it [00:42] brb [00:44] still nothin' [00:44] Nothing_Much: yes, you need additional config somewhere, I just don't know where :) [00:44] Oh darn [00:44] out of the box, Mir+Xmir will only run on known supported drivers [00:45] is lightdm displaying for you? [00:45] Yeah, lightdm is here but not under xmir === LarrySteeze is now known as LarrySteeze|Away [00:46] so if you've restarted lightdm, it *should* be displaying on top of mir [00:46] because of /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf [00:46] well it's not, it says this: [ 10.061] (WW) "xmir" is not to be loaded by default. Skipping. [00:46] that's XMir [00:46] that's not related to whether Mir is running [00:47] lightdm talks to Mir directly, it doesn't rely on XMir [00:47] do you have an X server running when at the lightdm greeter? [00:47] You mean.. a gui? [00:48] I mean, is there an 'X' process running [00:49] I'm not sure? [00:49] ps waxuf | grep X [00:49] if there is, Mir is failing to start [00:49] Yeah there is [00:49] X that is [00:49] Not Mir [00:51] what happens if you run 'unity-system-compositor' from the commandline? (best not to try this from an existing X session, you may want to stop lightdm first) [00:51] hmm.. [00:52] I'll risk it [00:52] well, even if it doesn't crash your X server, it may not tell you anything useful :) [00:52] ERROR: Throw location unknown (consider using BOOST_THROW_EXCEPTION) [00:52] Dynamic exception type: boost::exception_detail::clone_impl > [00:52] std::exception::what: assign: Bad file descriptor [00:52] Just got that [00:52] you need to run it as root [00:52] and you really want to run it from console [00:53] well - console, or remotely [00:55] Ah [02:25] So I apparently flashed this for no reason.. Oh well, does anybody know an xorg.conf for XMir? === LarrySteeze|Away is now known as LarrySteeze === LarrySteeze is now known as LarrySteeze|Away === chriadam|away is now known as chriadam === Namidairo is now known as Namidairo`bnc === Namidairo`bnc is now known as Namidairo === chihchun is now known as chihchun_afk [04:24] Anybody know how to get libhybris to work on an Ubuntu desktop with xmir? [04:27] nothing_much: what are you trying to do? [04:28] cwayne: I'm trying to run (X)Ubuntu desktop on an arm device. [04:28] It's not a tablet btw [04:28] Just a very tiny arm PC :) [04:28] something like a panda board? [04:28] Yeah [04:28] ah [04:29] Except it uses an Exynos 5 [04:29] sorry, I don't know anything to help you, I was just curious :) [04:29] Ah darn [04:29] Anybody else? I'm using an Odroid-XU [04:29] Trying to get libhybris to work [04:29] nothing_much: more people are active in this channel in EU timezones [04:30] oh really? [04:30] well luckily I'm nocturnal [04:30] in the US [04:31] ha, me too [04:32] to be honest nothing_much, i'm not sure anyone's really tried anything with libhybris re: desktop [04:32] you sure about that? [04:32] there should be a way to [04:32] since it's basically utilizing the android driver.. things [04:32] right? [04:35] i'm not saying it's not possible [04:35] i'm just saying to my knowledge nobody's tried yet [04:35] (people may very well have, just not to my knowledge) [04:35] yeah === jhattara_ is now known as jhattara [05:12] mhall119: ok, I can do a branch === chihchun_afk is now known as chihchun === iahmad is now known as iahmad|afk === chriadam is now known as chriadam|away === iahmad|afk is now known as iahmad === fmasi_afk is now known as fmasi === fmasi is now known as fmasi_afk === fmasi_afk is now known as fmasi [09:48] Good morning all; happy Friday and happy X-Ray Day! :-D [09:48] JamesTait: woo! [10:00] dpm, hey, regarding your question on robru’s askubuntu answer about the term size, it’s probably because the image is RO by default, try "touch /userdata/.writable_image" and then reboot [10:06] oSoMoN, oh, but that will make my image writable and I'll have to reflash to get back to RO, right? That makes that answer not really useful [10:06] actually, I should probably say it is useful, but only applies to RW images [10:07] dpm, yeah [10:07] dpm, I would answer on the askubuntu page directly, but apparently my reputation is too low and I’m not allowed to answer to inline questions [10:09] seb128: Hey, when I open system settings > date & time with a touch nexus 4 I've just updated to latest devel-proposed, I get an empty list of settings, and the title doesn't say "Date & time" but "System settings"; is this known? [10:09] lool: It's https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1248646 [10:09] Ubuntu bug 1248646 in Ubuntu UI Toolkit "API break: ItemSelector.expanded changed to read-only" [Critical,In progress] [10:09] lool, yes, https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1248646 [10:10] Ok thanks [10:10] lool, it has not been a good week for the uitk, ken also told me that their toolbar change is creating issues as well [10:10] ack [10:11] 19:18:00 < robru> t1mp, ping. any ETA on those ui-toolkit patches landing? [10:11] robru: which patches? We have a bunch of MRs that are ready to be merged, but waiting for AP1.4 to land before we approve stuff === jcollado is now known as jcollado_afk [10:17] seb128: there was no UITK release since 11 Oct until now, so a very large amount of changes that were made in the past month only came to the apps now [10:18] t1mp, yeah, that's "suboptimal" [10:18] seb128: a bunch of good ones, but also the bugs that popped up :( [10:19] did AP1.4 land? i.e., can we land fixes in the UITK now? [10:20] sil2100: ^^ [10:23] t1mp: AP 1.4 landed, but probably Mirv will know best regarding landings in UITK [10:23] Mirv: ? [10:23] sil2100: ok, thanks. I'll wait for Mirv's "go" === b0bben_ is now known as b0bben [10:32] t1mp: yes, so as discussed I know of two regression fixes https://code.launchpad.net/~nicolas-doffay/ubuntu-ui-toolkit/selector-api-break-fix/+merge/194313 + https://bugs.launchpad.net/ubuntu-rssreader-app/+bug/1248759 - those can go in as soon as possible [10:32] Ubuntu bug 1248759 in Ubuntu UI Toolkit "Once the toolbar in the Add feeds page is hidden, I can't make it appear anymore" [Critical,Confirmed] [10:33] (the latter if applicable) [10:35] t1mp: then after we are sure there are no regressions anymore compared to the 20131016 ui-toolkit release, and nothing that is required for fixing app AP tests, and we have an image that has the new ui-toolkit release, the trunk can be "really" opened [10:38] Mirv: happroving https://code.launchpad.net/~nicolas-doffay/ubuntu-ui-toolkit/selector-api-break-fix/+merge/194313 [10:44] happroval accepted [10:56] MacSlow, hey, could you review https://code.launchpad.net/~larsu/notify-osd/update-sync/+merge/194364 ? [11:00] seb128, do we have any migration process for user settings on upgrades in place yet ? (i.e. if at some point LC_ALL gets set, will the user setting get updated so he gets the fix) [11:00] if not, we should definitely work out something ... [11:00] ogra_, what do you mean with LC_? [11:01] seb128, thats just an example [11:01] i know that you set the locales in ~/,pam-environment [11:01] we will need a way to update the user settings if there are system fixes coming in [11:02] so users that upgrade get the fix too in their setups [11:02] ogra_, man session-migration [11:02] ah, k [11:02] (no man on the phone :P ) [11:03] ogra_, http://blog.didrocks.fr/post/Announcing-session-migration-now-in-ubuntu [11:03] yeah, i remember it [11:03] ogra_, http://manpages.ubuntu.com/manpages/raring/man1/session-migration.1.html [11:03] i wasnt aware we use it on the phone [11:04] ogra_, we don't yet afaik, but no reason we couldn't if we had a need for it [11:04] right, we should [11:04] ogra_, there is no config migration to do yet afaik though [11:04] there will surely be :) [11:04] ogra_, I'm not convinced, but let's see [11:05] i just want to make sure that we dont forget about it before the first stable to stable update happens ... [11:06] seb128, well, how will i get 24h clock settings if you dotn migrate my ~/.pam-environment once that bug gets fixed ? [11:06] (for example) [11:08] Morning all [11:09] ogra_, to be fair I don't care, we have enough issues, it's a v1, you can go to settings and pick a locale to fix your clock [11:09] how would i know about this ? [11:10] it wont be the last settign we have to migrate and it will likely also affect v2 or v3 once we have changes in settings [11:11] which gets particulary intresting with asac approach that you shoould be able to switch channels back and forth being up or downgraded at your aill [11:11] *will [11:11] (since there will be settings that arent backwards compatible or wheer the format of the file in the homedir changed etc) [11:13] seb128, on it [11:16] maybe we should make settings - similar to APIs - something that we dont treat as an internal thing that we can just change and refactor as we feel, but rather something that should be managed, discussed and once agreed, frozen forever with an SETTINGS scheme version etc. :) [11:16] * asac doubts its doable for the past, but maybe something to think about future way we handle setting schemes [11:17] asac, well, we have the boot hooks to handle such stuff, and i suppose running the session -migration automatically against the current version of whatever setting you have for each up-downgrade should work [11:17] I want a good mail/calendar/contacts application with support for getting it from a server (as in not local) for ubuntu.. why arent there any? [11:18] yarre, because you didnt write one yet ! [11:18] :) [11:18] ogra_: i think its not so much about migrating away... its keeping backward compatibility... [11:18] consider we use a setting called background which might be just a string now [11:18] in future we decide we need to make a structured setting out of that (e.g. a tupel) [11:18] asac, well, its keeping compatibility ... in either direction [11:18] so shouldnt we continue to keep the other setting working? [11:19] at least if you want to allow the either-direction-channel-switch approach [11:19] right compatibilty ... i think settings should be come a part of our API that we version and not change without keeping in mind that those that use the old setting scheme still need to be able to continue to do so [11:19] anyway. i haven't thought about this problem enough to have any sane input :) [11:20] right, me neither, thats why i asked seb128 :) [11:20] seb128: what are we using to store the settings? dconf? [11:21] dconf or dot files ... depending on the app [11:21] s/app/setting/ [11:21] seb128: are apps supposed to access settings at all? [11:21] or are they confined to just have access to its own settings? [11:21] only through the API [11:21] ogra_: what kind of API? a generic key value look up? or rather strictly typed etc. functions? [11:22] well, except language and locale settings for example ... they just are session wide set [11:22] e.g. get ("background") or getBackground() [11:22] ? [11:22] something like that, yeah [11:22] where is the settings API? [11:22] iirc you can currentlly reqest info about stuff like aut-rotation defaults and such [11:22] i guess that should naturally get embraced by platform API [11:22] asac, ogra_: apps setting is a topic we didn't tackle yet [11:22] somewhere in the QMl stuff ... Ubuntu.Components or so [11:23] but i would think app settings are a matter of the app devs [11:23] asac, ogra_: system settings are a mix of gsettings and file, e.g /etc/timezone, we basically use whatever was in place [11:23] not our problem [11:23] ogra_, asac: app settings are likely going to be qsettings with a qpa using e.g u1db [11:23] seb128: right. thats the backend, but how do apps/unity etc. interact with that? do we have an API? [11:23] what i care about are the system defaults that live in ~/ [11:23] or do they go directly to /etc/timzeone etc. as needed? [11:24] ogra_: this has happened a couple of times to me now on maguro it looks like it is suspended ie black screen, you press the power button to wake it and nothing you have to pull the battery to get it to power up again [11:24] davmor2, that only happens to be if it drained the battery completely [11:25] asac, we have a mix, gsettings-qt is the API to access gsettings, for /etc files we either use custom backends to talk to dbus services (e.g timedated) or direct file editing from cpp [11:25] * ogra_ has seen that as well ... but i usually need to charge it then before i can actually boot [11:25] ogra_: no this is on 40% when it happened this morning [11:25] so last night must of been on 80-ish% [11:25] davmor2, well, file a bug, attach syslog and stuff :) [11:26] ogra_: I was hoping it would happen again so I could see if I could adb into it in the broken state [11:26] ah, well, then do that [11:27] mguro is slowly moving to lower prio though ... [11:29] seb128: gsettings-qt is basically a key look up? or is that something more meaningful? [11:29] e.g. get("background) rather than getBackgroundInfo [11:29] seb128: smells like we should hide all of that behind the platform API and make a decent API there for all our system settings [11:30] i will connect you to ricmm [11:30] asac, it's a key lookup yes, e.g [11:30] GSettings { [11:30] id: desk [11:30] schema.id: "org.gnome.desktop.sound" [11:30] } [11:30] print(desk.eventSounds) [11:30] right. think right thing is to really hide all that stuff behind a decent API that we can manage, discuss and support forever :) ... let's see if we can experiment with that as part of platform API v2 and discuss/see where we would hit walls etc. [11:31] but just an idea to put up there for now :) [11:31] asac, wfm; though the number of components accessing system settings is limited (it's basically the settings app) [11:31] asac, so I'm not sure it makes sense to have an API for it [11:31] well, you will still need to migrate whatever lives in the homedir [11:31] migrate from what to what? [11:32] seb128: aren't all components != app a potential client for those settings? e.g. unity, mir, etc.? [11:32] seb128, from image 100 saucy to image trusty 10 and backwards [11:32] asac, for some yes, but those are shared are mostly stored in gsettings or accountsservice [11:32] seb128, asac wants to be able to move the release back and forth underneath the stable and devel aliases ... [11:32] ogra_, well, what do you want to migrate when switching between those images? [11:33] ad as well allow users to do that randomly as they like [11:33] ogra_, Im not old enough.. somebody should have done it already >_< [11:34] note: going back is not a big priority for now :) ... but its an interesting test for many things :) [11:34] seb128, well, if image 1 has keys x, y and z ... and image 10 renames then to xa, xb and xc ... once you roll back you need to migrate them back to the old names [11:34] ogra_, having compat in our storage backends is not going to be easy, image an app using a sqlite db and changing the table structure in a new version [11:34] ogra_, that's a difficult topic, good luck tackling it [11:34] seb128, i dont care about apps [11:34] its not about apps so myuch. yeah. those would just get disabled [11:34] thats (as i said above) a matter of the app devs to keep compatibility [11:35] also an app has to decide if they support downgrading etc. [11:35] asac, so you would e.g loose your addressbook contacts? [11:35] its the system settings ... imagine we rename "background" to "wallpaper" [11:35] or webbrowser bookmarks? [11:35] this name needs to be tied to an image version then [11:35] and the upgrade mechanism needs to know about it [11:36] and change it accordingly [11:36] ogra_, system settings is such a ridiculous small part of that issue [11:36] app devs need to define their own settings api [11:36] ogra_, where it gets tricky is not system settings, it's e-d-s and contacts, or webbrowser and bookmarks [11:36] right, system apps fall under system settings for me [11:37] they don't for me [11:37] they are thing I've no clue about and I'm not interested in resolving [11:37] well, we need to resolve it for the whole of the system [11:37] supporting format changes in both direction is not an easy problem [11:37] but not for any apps that dont come preinstalled [11:37] ogra_, is any OS out there doing that? === vrruiz_ is now known as rvr [11:38] seb128, i dont know any OS that supports going back and forth at your will [11:38] yeah, because it's not an easy problem [11:38] i know [11:38] :) [11:38] i think it would be worth a vUDS discussion [11:38] well, not my call, but it seems a lot of efforts ... not sure that's our first issue to tackle [11:39] it is something that will influence our future ... and it will be hard to fix once we have to much stuff established, better do it right from the start so we dont have to hack around issues later [11:39] the issue is that we don't start from scratch [11:40] we have lot of components coming from out there [11:40] i.e. via defining an API version for settings or somw such ... as asac suggested (not sure thats a good idea, but i have no better one) [11:40] we should never have used eds :) [11:40] which don't support that and don't plan ot [11:40] asac, sure, we can forget about opensource and just start an OS from 0, not reusing anything existing ;-) [11:40] seb128, it doesnt have to live in the components ... rather in an upper layer [11:40] seb128: I didnt say that :) [11:41] in the abstraction above the actual apps [11:41] asac, well, that's sort of what we are doing though, we want to change/rewrite almost everything than exists [11:41] right [11:41] i think there is a pattern [11:41] ogra_, create the abstraction and then apps eventually will see the benefit and start using it? :p [11:42] seb128, right, but we need to define the abstraction layer ... it doesnt exist yet ;) [11:42] ogra_, ok, wfm, let me know when it exists so I can look at using it ;-) [11:42] seb128, i dont see that as a "your team alone" issue, it spans across all teams ... [11:42] I don't even see how you could abstract things so different in a same API [11:43] right. lets ignore this topic for now :) [11:43] if you add a system setting with your app, you add the setting and possible values to a db ... [11:43] if the setting naming changes the db needs to reflect this [11:43] is /etc/timezone a db? [11:43] i will have our smart archtects think about this a bit and see what they come up with :) [11:44] and the session migration uses the db to migrate to the matching setting of a specific version [11:44] ogra_, the issue is that not every transformation is reversible [11:44] most will be though [11:44] ogra_, you might have stuff doing sql db updates on upgrade that you are not able to reverse later if you want to downgrade [11:44] e.g e-d-s for contacts storage [11:44] there might be settings in v2 that weren in v1 ... these wouldnt be touched on going backwards [11:45] so you would loose your addressbook on downgrade [11:45] then you need to keep a backup of the old db and move the data [11:45] and the API needs to know this (as well as the migration tool) [11:45] addressbook synched to the cloud might be an answer [11:45] :) [11:45] same for bookmarks [11:46] or that ... but that forces you to be online [11:46] ogra_, if you do that you loose any edition done while running the new version [11:46] why ? [11:46] because the new version is not going to edit the old db you move [11:46] i read the data from the new db and push it into the old structure [11:46] lol [11:46] good luck doing that [11:47] the tool needs to know both structures [11:47] I think you underestimate how much work is in there [11:47] and know that they are incompatible and how to solve this [11:47] no app dev is going to want to support retro compat for their past formats [11:47] i dont think i do ... [11:47] i know it is a big thing [11:48] is that a so compelling feature that it's worth the investment? [11:48] app devs (for click package apps from the store) wont have to do that [11:48] their settings are bound to the app, not to the system [11:48] when they get settings from the system that already happens through the ubuntu API [11:49] seb128, well, not that compelling for going backwards (i dont like that idea anyway) but it is surely very important that we update the user settings when going forward [11:51] s/user settings/user-dir stored system settings/ [11:51] ogra_, we spent some time thinking about upgrades issues in the past and came with some solution, but it's not an easy topic ... I don't even want to think about handling downgrades and both way transitions [11:51] ogra_, right, upgrade is not something new [11:51] ogra_, and we already support those [11:51] seb128, right, asac brought up that going back thing yesterday ... [11:52] downgrade is another topic [11:52] which made me think about tieing settings to the image version somehow [11:52] that doesn't help you much... [11:53] the above db and tool would ... but it would require a lot of developer discipline to keep it up to date [11:53] you need to know how to transform a configuration described in a new format to one that the old app can read [11:53] and that's just simply not always possible [11:53] yes [11:54] sometime the changes made create a situation were you don't have enough infos to create something the old app version would understand [11:54] ti is always possible to migrate data ... as long as you know both formats [11:54] if the new format is rich enough [11:54] let's say you dropped a field [11:54] and are adding new entries [11:55] what would happen with the old app that use that field? [11:55] would you just "invent" values to populate the config on downgrade [11:55] liek i said, you might have to create a new db in the old format and feed the content of the new db into it ... dropping all data for unknown keys [11:55] how buggy is that going to look in the app? [11:55] well, what if it's the other way around === dandrader is now known as dandrader|afk [11:55] if the old config has more infos [11:55] like timestamps of when the records are created [11:55] and the new one doesn't [11:55] you have the new db around already [11:55] and you don't have the info to retro fill it [11:56] and upgrade the content that changed in the old one since you migrated [11:56] well, the new db might not have the infos you need [11:56] cf my timestamp example [11:56] the new db already has it [11:56] when i went forward it got all the imafo [11:56] not for new record you added since the update [11:57] since the new version stopped collecting those info, because it got simplified [11:57] if i go back and make changes in the old db and then go forward again the changes just need to be fed into the new db again [11:57] if it got simplified that simplification will happen again going forward [11:57] yeah, the issue is going back to the old one when you did change on the new one [11:57] as you said, forward we already have a migration [11:58] you might be missing info to retrofit in the old config === jcollado_afk is now known as jcollado [11:58] because you just stopped to need those in the new world [11:58] so you simply don't have them [11:58] and you have no way to guess them [11:58] (like a timestamp of an event that happened and didn't register) === MacSlow is now known as MacSlow|lunch === b0bben_ is now known as b0bben === Namidairo is now known as Namidairo`bnc [12:08] oSoMoN: is https://code.launchpad.net/~osomon/gallery-app/hide-toolbar/+merge/194094 still worked on / going in, or is it abandoned in favor of UI Toolkit side https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/ap-toolbar-open/+merge/194122 ? [12:09] oSoMoN: ahum, I see gallery-app AP:s themselves are passing already without it.. === dandrader|afk is now known as dandrader [12:12] Mirv, it’s on hold until we have a resolution on the UITK side indeed [12:15] ogra_, KDE Kontact does all of the things i asked ;) [12:15] yarre, so you just need to port it to QML then :) [12:17] ogra_, nope no porting... just run and be happy ;) [12:17] wont work [12:17] i just need it on my regular desktop [12:18] oh, i thought you complained about mail on the phone [12:18] no just linux in general :) [12:19] well, this is the ubuntu-touch channel, nobody expects general linux mail questions here :) [12:19] (#ubuntu is the channel for general ubuntu questions ;) ) === Namidairo`bnc is now known as Namidairo [12:24] oSoMoN: alright, thanks === iahmad is now known as iahmad|afk === chihchun is now known as chihchun_afk === alan_g is now known as alan_g|lunch [13:23] seb128: do you want to test the fixed ui-toolkit version, settings was affected? [13:24] Mirv, I sure can, and yes, setting was affected, some of the panels wouldn't load, easy to test ;-) [13:25] seb128: yeah I noticed, too. http://pastebin.ubuntu.com/6382000/ [13:25] and error alredy :) [13:25] Mirv, thanks [13:25] daily-build PPA, that is === alan_g|lunch is now known as alan_g === MacSlow|lunch is now known as MacSlow [14:11] MacSlow, thanks for review the notify-osd changes, how is that looking? ;-) [14:11] MacSlow, oh, you just commented while I was writing that it seems [14:12] seb128, just commenting on the bug itself with my solution/alternative (while waiting for design-input) so it still can move forward regardless the outcome. [14:16] seb128: I went through all of the settings panels, seem to work fine [14:16] What's the sdk team channel? (besides ubuntu-sdk which has like 2 folks in it ;) ) [14:16] Mirv, great, thanks, I'm about to test as well if you still need my ack [14:17] nvm got it [14:17] seb128: if you happen to test I'm happy to get an ack. I'm running various AP:s still. [14:23] seb128, just posted my alternate solutions as a further comment [14:23] MacSlow, thanks [14:24] Mirv, it's way better but there is still a bug there [14:24] Mirv, the ringtone/messaging sound subscreens are empty with that version, they work if you downgrade to the saucy toolkit version [14:37] t1mp: ^ [14:37] dandrader: ^ [14:38] seb128: ok, thanks for testing. I haven't found any regressions so far, so I'll probably be releasing it (or kenvandine / robru will if I won't) as is, but a new bug would be needed for the remaining problem [14:39] Mirv, do you have ringtones listed in the corresponding panel? [14:39] Mirv, that's not a regression compared to the buggy trusty version but it's still once compared to a week ago [14:40] seb128: I'll check once my current AP is finished [14:40] seb128: I'm now comparing just regressions to #15 image [14:40] Mirv, ok, seems an improvement over that one indeed === Namidairo is now known as Namidairo`bnc === dandrader is now known as dandrader|lunch [14:47] tedg, you mentioned in Oakland wanting to be able to use the greeter DBus API in unity8 sooner rather than later. But you'd only be using it in phone_greeter mode, right? Which we don't ask for yet [14:48] mterry, Well, that depends what the greeter is on the desktop. [14:48] mterry, And in the phone greeter case I'd prefer to just ask "what's the current user?" and then never get a change. [14:48] tedg, you mean unity8-greeter or unity-greeter? [14:48] mterry, So if it changes form "phablet" to "phone" we don't have to care. [14:49] tedg, sure, but in phone greeter case, you won't use that indicator code until I split the greeter right? [14:49] why would the greeter differe pn phone/tablet or desktop ? [14:49] *differ on [14:49] ogra_, Multi user by default. [14:50] tedg, right, but why would the greeter differ ? :) [14:50] mterry, I'm confused. We'd still have the same code path. We'd just be asking you for which user to ask account service for. [14:51] mterry, We wouldn't be using the switching, but we still need to know the user name. [14:51] tedg, i dont think we should have different greeters, but instead one that can detect if there is more than one user and show the right stuff [14:51] ogra_, it's not the greeter, it's the indicators [14:51] ogra_, the greeter does detect that [14:51] ogra_, That's the plan, but we're not there yet. And I think mterry is trying to prioritize. [14:51] tedg, if i have a fully converged phone one day i might wat to have multiple users on this [14:51] ogra_, we support that! :) [14:51] ogra_, oh you mean on the indicator sid [14:52] you guys discussed having different greeters above [14:52] based on multi/single user [14:52] No, it's the unity7 legacy greeter vs. the unity8 new greeter. [14:52] tedg, I'm just saying, in Oakland, you said you'd like me to port the desktop DBus API to unity8 so the indicators could at least start using that before I split the greeter out. [14:52] tedg, aaaah ! [14:53] tedg, but "phone" mode (c.f. phone_greeter) shouldn't be using the DBus API, right? [14:53] mterry, I guess all I really want is that you implement enough of the API that you can return "phablet" as the current user. [14:53] tedg, and all we ever ask is for "phone" mode right now [14:53] mterry, The indicators display different UIs, but they dont' have different modes. [14:54] (plus or minus, but mostly) [14:54] tedg, so the indicator will always look for a greeter and ask for the current user, even in a user session, where it will just fail to find the DBus name? [14:54] mterry, So, yes, it'll have a "lightdm" mode. But not a form factor mode. [14:55] hi! What was a command to perform test on .click package before I submit it to USC ? [14:55] seb128: no the ringtones/messaging submenus do not show the list [14:56] tedg, OK. But "lightdm" mode isn't being used in phone yet, until I split, right? I'm just not seeing why landing DBus stuff now in unity8 (ahead of split) would be useful to you [14:56] otherwise fine [14:56] Mirv, save here [14:56] same [14:56] chrisccoulson: hey, on bug #1249326, is that something you have started or something others could look at? [14:56] bug 1249326 in Oxide "