[00:34] sergiusens: sorry, I was AFK - still need an answer to your question? [00:36] thomi_, np, sort of yeah, not sure why we need to know the resolution, only thing I found in the ap code was something about multimonitor [00:36] sergiusens: it's for the touch devices [00:37] sergiusens: need to know the screen resolution so we can create a touch device with the appropriate properties [00:37] thomi_, right === thomi_ is now known as thomi [00:37] thomi, forgot about that one over the weekend [00:38] thomi, my new problem is the emulator; it's a 'generic' device with multiple possibilities wrt to resolution [00:38] thomi, I guess that would be fixed once you can query the platform again, right? [00:39] sergiusens: right... I can see that would be a problem [00:41] sergiusens: sounds like we need a generic platform interrogation service [00:42] so we can tell things like screen resolution, SS support etc. [00:42] something that's a bit more dynamic than the build propertie sfile [00:43] thomi, yeah, I know I can get the resolution with an egl call, but not sure you want that directly [00:43] sergiusens: I thought we had a good solution with the platform API & python bindings. The only problem was that nobody was prepared to maintain the python bindings [00:44] thomi, yeah, and v2 is coming shortly [00:44] thomi, perhaps an autopackage test would solve that [00:44] sergiusens: maybe, but the specific issue I'm referring to was supporting python 3 :) [00:45] but yeah, I'm sure we can get better notificaiton for when something crashes [00:45] thomi, what's the biggest problem with migrating to 3? === LarrySteeze is now known as LarrySteeze|Away [00:47] sergiusens: nobody was willing to do the work - it was a simple fix, just a few #ifdef's needed here and there... [00:48] sergiusens: as a stop-gap, we dropped the platform-api alltogether, and inserted the hack in autopilot... which I'm not too happy about (can you tell? :P ) [00:48] thomi, I can tell [00:48] do i need to use linux to install this ubuntu on my nexus 7? [00:48] sergiusens: :) [00:49] sergiusens: I'm not really that upset - if someone fixed it properly, I'd owe them a beer or two [00:49] thomi, I'm shuffling between things here; but I'll see if I can get something done wrt before the break === Namidairo`bnc is now known as Namidairo === hakr is now known as h[a]kr [01:58] Anybody home? === LarrySteeze|Away is now known as LarrySteeze === Namidairo is now known as Namidairo`bnc === Namidairo`bnc is now known as Namidairo === chriadam|away is now known as chriadam === chihchun_afk is now known as chihchun === h[a]kr is now known as hakr === shuduo_afk is now known as shuduo === duflu_ is now known as duflu === ricardodrosales is now known as ricdros === h[a]kr is now known as hakr === Nothing_Much_ is now known as Nothing_Much === vying is now known as Guest74028 === shuduo is now known as shuduo_afk === shuduo_afk is now known as shuduo === shuduo is now known as shuduo_afk === shuduo_afk is now known as shuduo === Namidairo is now known as Namidairo`bnc === tvoss|food is now known as tvoss [07:59] good morning === iahmad is now known as iahmad|afk === shuduo is now known as shuduo_afk === chriadam is now known as chriadam|away === shuduo_afk is now known as shuduo === Namidairo`bnc is now known as Namidairo === iahmad|afk is now known as iahmad [10:20] (how) can I get autopilot to look in the cwd for tests? [10:21] ah, I got it, I needed to be one level up [10:36] right, usualy something like "autopilot run tests" if there is a tests/__init__.py [10:37] tvoss: hello, I have some questions related to process-cpp release [10:38] sil2100, sure shoot [10:38] tvoss: on the landing pipeline I see that as a 'test-case', I should run a build of platform-api with the new process-cpp to have the unit tests ran - but hm, I don't see platform-api deping on the process-cpp libraries? [10:39] pitti, ^ can you help here? [10:39] sil2100: right, landing platform-api tests is blocked by getting process-cpp in [10:39] sil2100: that's https://code.launchpad.net/~pitti/platform-api/test-backend/+merge/198098 [10:40] tvoss: Ah [10:40] sil2100: but that will fall apart due to this bug in process-cpp (this pretty much completely breaks the package ATM) [10:40] sil2100: so you can run tests from that branch [10:40] sil2100: (merely bzr bd -- -b will build and run tests) [10:40] pitti: ah, so building this platform-api branch with the latest process-cpp from trunk, yes? [10:40] sil2100: correct; that's why I'm eager to land this (thanks for taking care of it!) [10:41] pitti: ok, then I'm testing this and releasing - of course process-cpp without this platform-api branch landed is 'safe' to release by itsown, right? :) [10:41] Just making sure [10:41] sil2100: right, it's a prerequisite [10:42] sil2100: it's been broken for quite a while, so apparently not much other stuff is using libprocess-cpp [10:42] Awesome then [10:42] Thanks for the info, moving on then ;) [10:42] sil2100: i. e. adding tests to platform-api is blocked by process-cpp, but not the other way round === shuduo is now known as shuduo_afk [10:42] \o/ === shuduo_afk is now known as shuduo [10:45] Morning all [10:51] pitti: ok, so the code compiles fine and tests pass, but it seems that the package fails to build due to symbols file mismatch [10:52] sil2100: oh, which one? I've been building process-cpp quite a lot, worked fine [10:52] (and platform-api, too of course) [10:53] pitti: the platform-api branch, when using the latest process-cpp from trunk [10:53] pitti: I get a biiiig symbols diff, mostly with leaked out boost symbols [10:53] sil2100: right, I get the symbols diff, too, but it builds [10:54] (no idea about the symbols; they aren't even demangled) [10:54] pitti: yes yes, everything else is fine besides these symbols ;) Just making sure it's a known thing [10:54] But I guess all is fine with process-cpp so I'll publish it [10:54] sil2100: right, I confirm that issue [10:58] sil2100, pitti process-cpp should not leak symbols, its default visibility is hidden and it even has -fvisibility-inlines-hidden [11:00] tvoss: hmm... but it seems that somehow it does, as now I see only process-cpp depends on boost here [11:00] sil2100, can you pastebin the symbols please? [11:00] tvoss: sure, one moment [11:01] http://paste.ubuntu.com/6560765/ [11:02] sil2100, that's from platform-api, right? [11:02] tvoss: right - but from what I see platform-api does not use boost in any moment, besides from process-cpp, right? [11:03] sil2100, it does, implicitly via the location service [11:03] sil2100, so symbols are fine [11:04] tvoss: oh, so these are from location-service? Since I saw platform-api building fine before in the daily-build PPA, without any symbol file diff [11:06] I wonder why I can't build platform-api now... let me downgrade process-cpp and check if it helps [11:06] Actually hmmm, process-cpp is not used in platform-api trunk, so it's unrelated [11:07] And it builds fine in daily-build, so I guess all is ok === vrruiz_ is now known as rvr [11:20] how do I click an option in an ItemSelector with autopilot? [11:21] even better, is there a reference for interacting with the sdk widgets? [11:23] Laney: we have autopilot emulators for UITK components. For TabBar, for example it has a function switch_to_next_tab() [11:24] Laney: so that approach would "solve" your issue, except that the emulators are not complete yet. We don't have it for the ItemSelector [11:25] timp: aha, I see [11:25] I can poke the backend to change it if needed for now [11:26] yeah, the problem with that is when the implementation of the ItemSelector would be changed, your tests will break [11:26] but for now it would work, and I don't see another way [11:26] I meant the backend in ubuntu-system-settings [11:26] but what do you mean? [11:27] I thought you meant to somehow get the components representing the options in the OptionSelector, but that is quite dependent on the current implementation [11:27] oh right, I have no idea how to do that :-) [11:28] it's controlled by a property so I can change that over dbus [11:28] ahh. you change the property that the ItemSelector represents [11:28] yeah [11:29] I'll get into a problem on the next page, but at least I can write a few tests for this stuff [11:31] Laney: ok. [11:31] Laney: I reported this bug https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1260285 [11:31] Ubuntu bug 1260285 in Ubuntu UI Toolkit "No autopilot emulator for option/item selectors" [Undecided,New] [11:31] thanks for the hints [11:31] cool, subscribing === _salem is now known as salem_ === MacSlow is now known as MacSlow|lunch === _salem is now known as salem_ === Namidairo is now known as Namidairo`bnc [12:16] there is whatsapp for ubuntu-touch? [12:16] pr0teus, not at the moment, no === Namidairo`bnc is now known as Namidairo [12:20] and what is the best hardware to try out ubuntu-touch? [12:22] what is AUTOMOC and how to use it with CMake in Qt5 ? [12:22] i have an experia u, but it only has 512mb of ram i'm note sure if i could install ubuntu [12:22] bzoltan or Mirv: maybe you know ? " what is AUTOMOC and how to use it with CMake in Qt5 ?" [12:23] xnox: no idea [12:24] Laney: any idea on how AUTOMOC is used in Qt5? I see that ubuntu-system-settings uses that integration? [12:24] xnox: no idea aside from that the moc is Qt's sort of C++ extension, so automoc would then handle the meta-object compilations automatically I guess [12:24] on a lower level, I don't know much about how it works [12:24] xnox: no idea, Satoris wrote the cmake stuff for us [12:25] Mirv: right. it's failing for me with "No such file or directory, moc failed..." [12:25] it allows the usage of slots/signals [12:26] I haven't seen that, so I don't know what would be the usual fix === shuduo is now known as shuduo_afk === dednick is now known as dednick|lunch [12:47] Does anybody know, if there are any plans for 14.04 to implement some kind of switch, if a bigger display [12:47] will be connected to a smartphone (Nexus 4 for example), the operating mode is switching to tablet mode? [12:49] ffelgenh: we are already working on making the same app work on phone/tablet/desktop, so apps would adapt to different screens [12:49] ffelgenh: I don't know when it will/should be finished [12:56] timp: this adaption will check the resolution or will it check the device type [12:58] timp: because the use case i'm interested in is a phone connected to a bigger display ... checking the device type would'nt be enough === dandrader is now known as dandrader|afk [13:00] ffelgenh, convergence is on the plan for 14.10 ... i doubt we will do much more than "by device type setup" during 14.04 [13:01] ffelgenh: it is not 100% worked out yet [13:01] (which for tablets only means that the sidestage is enabled in landscape mode) [13:01] I think apps should adapt to different screen resolutions. already you can see in some apps (or UITK examples) that they adapt to changes in window-size on the desktop [13:01] but it is currently for the apps to do it correctly [13:02] ffelgenh, ogra_ currently, if apps want to support different devices and they ask how that is supported in the UITK, we recommend them to use the screen size [13:03] so I'm talking about the apps only [13:03] unity and the stages that ogra_ talks about are probably a more complex story [13:04] ogra_: so for that you're right, 14.10 :) [13:09] timp, ogra_ thx for explaning those different concepts === alan_g is now known as alan_g|lunch === dandrader|afk is now known as dandrader === MacSlow|lunch is now known as MacSlow === dednick|lunch is now known as dednick === iahmad_ is now known as iahmad === Namidairo is now known as Namidairo`bnc [13:28] hi im looking at kernel configs , anyone know what driver is used for the celluar / gps [13:28] tvoss: now that process-cpp is in, I made the necessary changes to the branch and set it to needs-review; it's ready from my POV now (https://code.launchpad.net/~pitti/platform-api/test-backend/+merge/198098) [13:29] pitti, great, thanks for the update [13:29] * tvoss notes that typing struct SpaceVehicle is really cool :) === Namidairo`bnc is now known as Namidairo === alan_g|lunch is now known as alan_g [14:13] tvoss, ricmm: oh, I think the platform-api tests for https://jenkins.qa.ubuntu.com/job/platform-api-trusty-armhf-ci/6/console might fail for a similar reason like what we recently discussed with moving to g++-4.8 [14:13] ricmm: I only get garbage for the functions that return floats; -- I guess I need to declare them with this pcs attribute magic? [14:14] pitti, ricmm is off, but yes, the pcs stuff is required [14:21] tvoss: ack, works fine now; (nice to have tests :) ) [14:22] pitti, indeed :) [14:30] dholbach: well, let's see how s-i 2.0.3 goes, now that it's finally gotten promoted ;) [14:30] barry, hey,was it you I had to bother when a udd branch got out of sync? [14:30] barry, I commented on the bug [14:30] sergiusens: wgrant perhaps? not me i think :( [14:31] ack, thanks [14:32] chrisccoulson: hey, any thought on bug #1260137? [14:32] bug 1260137 in Oxide "oxide won't load on armhf - libOxideQtCore.so.0: undefined symbol: arm_memset16" [Critical,New] https://launchpad.net/bugs/1260137 [14:33] jdstrand, yeah, just about to take a look at that [14:33] jdstrand, we have an #oxide channel now btw [14:33] chrisccoulson: great! what do you think it is? [14:33] that's where me an oSoMoN are :) [14:34] jdstrand, i wonder if it's related to the fact that we haven't turned off the neon runtime detection [14:34] (we do turn that off in chromium) [14:34] I googled it last night [14:34] and saw that chromium had some logic for neon vs armv# [14:35] it was a year old though [14:35] and also failed the build, not just at runtime [14:36] so it seems plausible [14:37] rsalveti: curious, have you seen anything related to bug #1260137? [14:37] bug 1260137 in Oxide "oxide won't load on armhf - libOxideQtCore.so.0: undefined symbol: arm_memset16" [Critical,New] https://launchpad.net/bugs/1260137 [14:37] rsalveti: and hi btw :) [14:38] chrisccoulson: btw, you probably saw-- I decoupled packaging from uploading to ubuntu [14:38] chrisccoulson: (in the work items) [14:40] mzanetti, if the shell wanted to grab a screenshot for internal use and dump it to a file, would it want to use the new screenshotting support or can it just grab its mir surface and do that? [14:41] tvoss: jenkins gave its blessings now \o/ (I pushed another fix to clean up a warning, though) [14:41] mterry: what I'm working on is really apps [14:42] mterry: so not doing screenshots of unity itself [14:42] tvoss: should ricmm review this branch once he's back, or do you want to do it? [14:42] mzanetti, well, my question is about whatever's on the screen so might include apps [14:42] I assume the shell has that info [14:42] tvoss: (ATM you are set to be the reviewer, but that's mostly just because you replied first) [14:43] mterry: hmm... so what I'm doing is to grab the surface of the application (to be used in runningapplicationsgrid) [14:43] mterry: but you might want to try QQuickWindow::grabWindow() [14:43] pitti, let me approve it, ricmm can then give the final top-approve [14:44] tvoss: ack, added a review request from Ricardo === dandrader is now known as dandrader|lunch [14:50] ogra_, any objection to me adding /var/lib/lightdm to writable-paths? (it's HOME for the greeter) === dpm_ is now known as dpm [14:56] mterry, I dont think hes around [14:56] boo [14:56] maybe ask sergiusens [14:56] sergiusens, ^ [14:57] mterry, if you are going to push anything, I just asked lool or xnox to review http://people.canonical.com/~sergiusens/lxc-android-config/ [14:58] mterry, I can add it there, or if you don't mind sponsoring that, I don't have issues with you adding that [14:58] sergiusens, if you wouldn't mind adding: [14:58] /var/lib/lightdm auto persistent none none [14:58] sergiusens, to the writable-paths file... [14:59] mterry, will do [14:59] sergiusens, thanks! [14:59] pitti: ah, forgot to mention - process-cpp is already released [15:05] sil2100: I noticed, thanks! platform-api works fine now in trusty [15:07] mterry, it's added [15:08] * mterry hugs sergiusens [15:09] mterry, I want that in to see if I can get udd back as well; not using a vcs seems sad :-) [15:10] yeah :-/ [15:14] seb128, tedg, Laney, kenvandine: http://goo.gl/IPzwi0 === Namidairo is now known as Namidairo`bnc [15:21] mpt, thanks [15:22] seb128, fyi I added a couple of bugs recently where multiple settings panels were opened [15:23] pmcgowan, I saw that, I need to test it, I don't think anything changed recently on our side that could create that [15:23] pmcgowan, I wonder if that's an url-dispatcher issue [15:23] seb128, could be for the one from the pulldown [15:23] I think the online accounts one is just thats its a separate app? [15:23] cno [15:24] tedg, do you have any idea about #1259973 ? [15:24] it's always been the case [15:24] pmcgowan, right, online accounts is a known issue [15:24] vg [15:24] we just push onto the page stack; I don't think we ever got a clear answer as to the correct behaviour there [15:25] seb128, Huh, no. Does it close in that case? [15:26] oh right [15:26] pmcgowan, what you describe in that bug is not a bug [15:26] seb128, ah so its a feature [15:26] pmcgowan, you have settings open on cellular, you switch to wifi, back bring you where you were [15:26] seb128, it was just not what I expected [15:27] right [15:27] I will yeild to the usability gurus [15:27] as Laney said, we didn't get real clear guidance from design on that [15:27] if you get some we are happy to change the behaviour [15:27] thanks ;-) [15:27] ok will copy the bug task to them [15:27] pmcgowan, oh, btw, in case you didn't notice we got webkitgtk dropping from the touch image recently ;-) [15:28] (gtk is still there, next to clean out) [15:28] seb128, its the little things that make me happy ;) [15:28] now gtk3? [15:28] ;-) [15:28] hehe [15:28] next! [15:28] g haters === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g [15:42] dholbach: hi. we were looking at LP: # 1256229 and stgraber noticed something weird about your recovery log file [15:42] dholbach: it claims the date is Wed Nov 20. stgraber thought maybe your device isn't actually rebooting into recovery [15:43] dholbach: no idea why that would be, but you can try to do this manually by issuing `reboot -f recovery` [15:47] oSoMoN, hey, popey has some results for notes running on mako that are not 100% pass [15:47] barry, ok, let me try it [15:47] oSoMoN: do you want bugs for these failures? [15:49] mterry, hey,lool is asking me if the lightdm persistence be temporary [15:49] barry, ok, it rebooted, but everything seems to still be the same :/ [15:49] *could be [15:50] sergiusens, mterry: Basically we can make it writable without making it persistent; does it need to be persistent? this implies backwards / forwards compat "forever" [15:50] barry, shall I run "system-image-cli -b 0" now? [15:50] as in, SD card with userdata might be kept across a reinstall of a newer or older version that the one that created the data [15:50] dholbach: yes, then reboot -f recovery again. [15:51] barry, all right, I'll let you know how it goes [15:51] sergiusens: My device is currently semi-broken; I can't always deploy touch on it, and I'm not sure testing system-image level changes under emulator is great; otherwise good to go if at least 2 people booted with this (you + someone) [15:51] sergiusens, lool: well, it is a homedir, so not that different a contract from other homedirs. For today, it can be temporary, but I have a feature or two I probably will need persistence for. But can upgrade it when needed. I was just looking ahead [15:52] Those features aren't finalized yet, so might as well play it safe with temporary [15:53] lool, /var/lib/bluetooth keeps track of all the pairings [15:53] mterry: maybe it's worth having it persistnet for the desktop touch image? [15:53] sergiusens: yeah, I guessed this would be the case; ok [15:53] sergiusens: is the format stable in some way? [15:54] sergiusens: basically if it never needs to change, it needs to change so that the new format works with old software and we need to add a boot hook to convert it [15:54] lool, hmmm; something for cyphermox or awe_ [15:54] lool, I think even for desktop, that dir doesn't need to be persistent... I'm trying to think if we ever store any gsettings for the greeter [15:55] lool, not sure if we are upgrading the bluetooth stack at all; but I'm guessing we'd need the same for ofono [15:55] lool, I'd say the software itself should know how to manage it's own config upgrades tough [15:55] though [15:55] sergiusens, what's the issue? [15:56] awe_, if files in /var/lib/bluetooth are stable and what's the case with bluez5 [15:56] no bluez 5 for 14.04 [15:56] awe_, when we do update though, do you know if the file formats change? [15:57] there's a schism between the pulseaudio devs & the bluez/ofono guys [15:57] re: how headset & handsfree are implemented [15:57] awe_, if they do, we will need to plan for that (same if stuff in /var/lib/ofono) change [15:57] sergiusens, sure...but that's something we'd tackle when we start working on the new version [15:58] sergiusens, pretty sure there's been no schema change to the ofono settings files [15:58] only additions [15:58] lool, well, in any case, /var/lib/bluetooth needs to be persistent [15:58] can't say the same about bluez, as I've never really been hands-obn [15:58] s/obn/on/ [15:59] awe_, ack; seems fine, if we need config file update mechanisms, we will just need to plan for it [15:59] sergiusens, yea, I thought we had the same issue with /var/lib/ofono/ dirs [15:59] sergiusens: I'm just underlining the new contract this new software will operate under so that we get a chance to review the format of the data which cross the border :-) [16:01] awe_, we do [16:01] lool, well we don't control bluetooth === jevon is now known as Guest32107 === gatox is now known as gatox_lunch [16:02] lool, I don't know where it's going to go; but whenever it's updated some layer of adaptations will need to be pulled in [16:02] lool, I feel the android full on source model to be more attractive as days pass :-P === dandrader|lunch is now known as dandrader === Guest32107 is now known as jevon_ [16:05] rsalveti, awe_ , cyphermox: what did you do to ofono? sms and 3g are down for me [16:06] it's been working.. tbh I avoided touching any of it ;) [16:06] cyphermox: this is the latest image r62 [16:06] lool, recap then; should I change lightdm to temporary? Can we keep bluetooth persistent? [16:07] bluetooth persistent? [16:07] * cyphermox gets highlighted :) [16:08] cyphermox, I pinged you like three times and you see the bluetooth highlight :-) [16:09] you did? [16:09] cyphermox, /var/lib/bluetooth [16:09] ahahah [16:09] cyphermox, fwiw http://people.canonical.com/~sergiusens/lxc-android-config/ [16:10] cyphermox, that path needs to be writable for bluetooth to work, I made it persistent since the pairing info was stored there (right?) but lool suggested it be writable but temporary [16:10] stuff gets written bu bluez to /var/lib/bluetooth [16:10] cyphermox, which means it gets recreated on every boot [16:10] yeah, looks right [16:10] it probably should be persistent as much as possible to make it easier on bluetooth, like, name cache and the like [16:11] cyphermox, which means that if the config file changes inside that path and the software doesn't handle it, we will need to [16:11] sergiusens: say that again, you mean when set to be persistent? [16:12] cyphermox, we're on bluez4 (right?); it has a bunch of files written to /var/lib/bluetooth; if when we update to bluez5 one of those configs is incompatible, we will need to re marshall the files in there so they are compatible with bluez5 [16:13] cyphermox, I don't think it's that much of a deal btw if it comes to that [16:13] yes probably [16:13] awe_, rsalveti :ah I guess that ofono crash in /var/crash is not too conducive to a working sms system maybe [16:13] but as you say, no big deal [16:13] I don't expect the files to be that different anyway, and most likely not different at all [16:14] sounds good; now I only need word back from mterry and we can upload :-) [16:14] barry, still the same :-/ [16:14] sergiusens, I am OK with temporary for now, but may need to upgrade to persistent in future [16:14] cyphermox, meh, I was going to ask you during the standup to add lxc-android-config to the landing plan :-P [16:14] mterry, let me change that then [16:14] sure, I can [16:15] sergiusens: if it keeps pairing inforation, it ought to be persistent [16:15] sergiusens: was just challenging whether we really needed it or not [16:15] but seems we do [16:15] lool: things will work without it, for the most part [16:15] stgraber: ^^. dholbach, and the date is still nov 20 in recovery's log file? [16:16] perhaps except for the persistance of pairable and mode [16:16] which is still kind of useful [16:16] everything else gets re-discovered [16:16] barry, yes, still the same [16:16] cyphermox, I would need to repair my headset every time though [16:17] lool, cyphermox I've updated http://people.canonical.com/~sergiusens/lxc-android-config [16:17] * sergiusens wants udd to work again [16:17] dholbach: when rebooting do you see the upgrade screen (android droid logo with a progres bar)? [16:17] dholbach: dang. and this was with the 2.0.3 debs? or still 1.9.1? [16:18] barry, 1.9.1 :-/ [16:18] stgraber, no, just the normal Google logo [16:19] davmor2, completely dead in the water, or intermittent? [16:19] sergiusens: lool: mterry: so, ok, I add lxc-android-config to the landing plan? [16:19] dholbach: ok, so you're not booting into the upgrader at all... [16:19] dholbach: what device is that? [16:19] cyphermox, yes please on my side [16:19] stgraber, grouper [16:20] dholbach: ok, one sec [16:20] awe_: intermittent on a reboot it worked however it soon died I have a crash report in /var/crash that I'm trying to get sent [16:20] dholbach: grab http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20131212.1/trusty-preinstalled-recovery-armel+grouper.img [16:20] dholbach: then do "adb shell reboot -f bootloader" [16:20] dholbach: then "fastboot flash recovery trusty-preinstalled-recovery-armel+grouper.img" [16:20] dholbach: then "fastboot reboot" [16:21] cyphermox: +1 from me for the 3 changes but haven't boot tested it and would want 2 people to boot test it (I assume sergiusens is 1 already) [16:21] dholbach: and finally "adb shell reboot -f recovery" [16:21] dholbach: and see if that helps ;) [16:21] lool, if it's in the landing plan, the testing is granted for ;-) [16:21] hehe [16:21] sergiusens: well depends if you land it in lp:ubuntu/lxc-android-config or not ;-) [16:22] stgraber, now it boots into recovery :) [16:22] lool, oh yeah; but for te UDD side; I talked to wgrant, he showed me the importer error; the changelog had warnings and the importer doesn't handle utf8 (your names) so I removed the changelog warnings [16:23] davmor2, ack [16:23] what device? [16:23] dholbach: ok, so something was messed up in your recovery partition... not sure what would have corrupted it though [16:24] dholbach: could be some problem with the NAND chip or a failed recovery partition update, who knows... [16:24] dholbach: if that fixes it, please close the bug... and yay! crossing my fingers for you :) [16:24] lool: we do tsting as we publish anyway [16:25] lool: I understand that it's something that gets manually uploaded thouhg [16:25] sergiusens: how do I test it, just untar that tarball on my device and reboot? [16:25] sergiusens: you're basically saying it's my fault that we have non-7bits chars changelogs because I have an UTF-8 name? :-P [16:26] cyphermox: You can switch to writable mode and dpkg -i the package and reboot but you have to unmount the bind-mounted udev rules first [16:26] awe_: maguro [16:26] err [16:26] it wasn't a deb was it? [16:26] lool, nah, it's the importers fault [16:27] lool, that breaks the idea [16:27] davmor2, ok, I'll try and reproduce on my end [16:27] oh right, source package [16:27] sergiusens: cool I feared I had to pick another name [16:27] awe_: this is on image r62 [16:27] davmor2, is that stable? [16:27] awe_: no devel-proposed with the new ofono stack [16:28] ok [16:28] cyphermox, lool adb shell mount -o remount,rw /; adb push etc/system-image/writable-paths /etc/system-image/writable-paths; adb shell sync; adb shell reboot [16:28] sergiusens, cyphermox: Try to test the actual .deb [16:29] I know it shouldn't make a difference, but just in case it does because something change that we have not thought of... [16:29] lool, hmm, I thought this one was full of symlinks [16:30] symlinks or bind-mounts? [16:30] there's one [16:30] but ISTR I've installed this successfully in the past [16:31] after unmounting one bind-mount [16:31] * sergiusens the murder by numbers song from the police came to his mind when looking at the version number [16:31] lool, do you recall which one? [16:31] awe_: oh interesting if I call the maguro from my land line the call works I also get a message that I tried to send earlier and then ofono crashes again [16:31] sergiusens: some /lib/udev/.../local rules file [16:32] davmor2, can you file a bug, and also attach the contents of /etc/init/ofono.override? [16:33] lool, why is writable paths set as a config file? [16:34] cyphermox, push the deb, remount / as above, umount /lib/udev/rules.d/70-android.rules, dpkg -i; reboot === dandrader is now known as dandrader|afk [16:37] om26er, ping [16:37] salem_, pong [16:38] om26er, hey, do you know if it is possible to enable ci and autolanding for ofono-qt? [16:39] salem_, yes I think we can ask the CI team. fginther help ? [16:39] lool, is this the right way to make it temporary?/var/lib/lightdm auto temporary none none ? [16:40] I can propose a branch [16:40] om26er, ok. cool! we will need that to land the delivery report support in tp-ofono. [16:41] om26er, https://code.launchpad.net/~tiagosh/ofono-qt/statusreport/+merge/198567 [16:43] salem_, was ofono-qt previously in lp:phablet-extras/ofono-qt ? [16:43] om26er, hm, let me see [16:44] om26er, it is still there I think. [16:44] cyphermox, I just copied over a new set, I had the temporary syntax wrong for lightdm; installing from package was fine from my side [16:45] bfiller, hey; wrt to notes; popey saw some errors on mako when running the click; it's been approved anyways tough [16:45] cyphermox, lool package install tested and is fine === ricardodrosales is now known as ricdros === gatox_lunch is now known as gatox [16:49] fginther, when you get around, can you please review this https://code.launchpad.net/~om26er/cupstream2distro-config/ofono-qt_CI/+merge/198782 [16:49] salem_, ^ [16:50] om26er, salem_, I can get... [16:50] om26er, you beat me to it [16:50] :D [16:51] Until recently I was interested in getting an ubuntu-based phone, but now I'm concerned about security and open source hardware. === dandrader|afk is now known as dandrader [16:53] ogra_: hi, I'm looking at https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1256061 [16:53] Ubuntu bug 1256061 in qtubuntu (Ubuntu) "clock forcefully switches from 24h to 12h AM/PM format once the panel clock is loaded" [Critical,Confirmed] [16:53] ogra_: just to be sure, how did you switched to a German locale? [16:54] *switch [16:55] sergiusens: you mean the autopilot tests? [16:55] sergiusens: it worked for me, argh. [16:56] mterry: hi, just getting back to you about the MIR for unity-voice [16:57] with the tests that do run in the pbuilder environment enabled, does that improve the situation enough? [16:59] sergiusens: thanks [17:02] bfiller, yeah, I tested on maguro and worked fine; it's still going to be in the next builds so you can check the results there once in [17:02] pete-woods, let me refresh my memory [17:02] om26er, a couple things to update, please see my comment [17:03] fginther, fixing [17:03]