=== salem_ is now known as _salem [01:06] so what does Detectable autorepeat not supported mean? [01:06] my app runs on the desktp but crashes on the phone with said error.. [01:36] matv1 fixed it === _salem is now known as salem_ === ycheng_ is now known as ycheng === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === chihchun_afk is now known as chihchun === salem_ is now known as _salem === chriadam is now known as chriadam|away [04:16] Hello === VDVsx_ is now known as VDVsx === ecloud is now known as ecloud_wfh [06:45] good morning [07:44] sil2100, seb128: FYI, please see my last comment on bug 1359191 [07:44] bug 1359191 in language-pack-touch-es (Ubuntu) "Needs new language packs for projects that enabled langpack translations" [Undecided,Fix committed] https://launchpad.net/bugs/1359191 [07:45] sil2100: so we now can land my branches at any time and without having to wait for launchpad and new langpacks, which should make this whole mess much easier [07:45] pitti, oh, nice, thanks for doing that ;-) [07:45] I locally tested the new langpack on the phone; they are building now [07:45] so if we want to publish a new image today these will pick up the new langpacks [07:46] great [07:46] I'm crossing my fingers for you guys on promotion. [07:49] Oh, let me check that [07:51] sil2100: so if you are keen on cleaning up some silos I think releasing PPA-12 is reasonably safe now [07:52] argh, except that someone needs to top-approve https://code.launchpad.net/~pitti/unity-scope-scopes/use-langpack/+merge/231403 [07:52] seems robru already tried to unleash it [08:15] tvoss, hey, have you seen bug #1359251 ? I’m wondering if you could comment to shed a light on how the location service works in this regard? [08:15] bug 1359251 in webbrowser-app "[webapps] Denying geolocation permission doesn’t inform the requester of the denial" [High,New] https://launchpad.net/bugs/1359251 [08:25] oSoMoN, commented [08:27] tvoss, I’m not seeing the comment, could it be lp being slow? [08:27] oSoMoN, sigh, it ate my comment [08:28] launchpad eats comments for breakfast [08:29] and it likes them fresh [08:30] oSoMoN, hit refresh [08:30] tvoss, thanks! [08:31] oSoMoN, sure [08:31] oSoMoN, I think we should look into how to report the error from qtlocation [08:31] oSoMoN, btw: the app has no idea of the trust store or trust prompt interaction -> on purpose :) [08:31] tvoss, yeah, that’s what I thought, thanks for confirming [08:32] it really wouldn’t be secure to trust the app with interaction with the trust store, I guess [08:32] oSoMoN, yup, we could save all effort in that case [08:33] tvoss, who would be the right person to assign this bug to, for qtubuntu-sensors? [08:33] oSoMoN, unfortunately, me [09:03] tvoss: please look at my platform-api branch, feature freeze is today [09:06] Laney, done, should we get it in a silo? [09:07] tvoss: sure, that'd be good [09:07] Good morning all; happy Senior Citizens Day! :-D [09:30] Just got pinged on G+ by someone about an issue they're having with the emulator: http://ubuntuforums.org/showthread.php?t=2240474 [09:31] suggested they might try an i386 device as I've never had good luck with armhf display on this machine, reason I've been testing on my nexus 7 [09:42] pitti, i think the latest system-settings actually has a wipe/factory-reset option via a dbus interface i wonder if that would be usable [09:51] mvo_: ping [09:53] bzoltan: pong [09:54] mvo_: hello there. I have a most likely silly question :) Would it be possible to support the native chroots with click? Like real armhf click chroot [09:55] bzoltan: so armhf click chroot on a armhf system you mean? [09:56] mvo_: no, armhf click chroot on an x86 system. [09:56] mvo_: a real armhf chroot with armhf Qt tools and toolchain [09:57] bzoltan: right, and we would run the armhf binaries using something like qemu? [09:57] mvo_: yes, just as pbuilder type of chroots do [10:00] bzoltan: I don't have much experience with that, cjwatson or slangasek probably know better why its done the current way (sorry) [10:00] It would probably be disastrously bad because qemu and Qt aren't friends. [10:01] mvo_: the current way is perfect from the point of performance and practicality ... native toolchain with the target APIs and stuff. That is cool and fine. [10:01] Just as we see with virtual PPAs. [10:01] cjwatson: what would be the offer for building qmake projects? [10:01] We need to fix those to cross-build. [10:02] I'm pretty sure trying to use qemu would wind up being a non-productive time sink debugging issues none of us have any experience with, and that upstream has historically not been able to help with. [10:02] That's been the story with PPAs. [10:02] (Unfortunately; but there you have it ...) [10:06] cjwatson: yes, I can confirm that. Still we should have something for qmake projects. People are desperately trying to figure out all kind of ideas how to make app porting easier when there are hundreds of good apps using qmake. [10:06] ogra_: yeah, Sergio mentioned that yesterday, that sounds useful [10:07] ogra_: so perhaps that should get an option to save network connections? (that seems easiest, as the d-bus backend is already running as root I suppose) [10:07] pitti, seen my commant on the bugg ? [10:07] bzoltan: I know, just too many things to do ... [10:07] why do you need to save it at all ? [10:07] *comment [10:08] bzoltan: Just don't think we should go down what's proven to be a rat-hole in the past, that's all [10:09] pitti, i could imagine something like: phablet-config factory-reset (calling the dbus function); adb wait-for-device; phablet-network -n /path/to/local/netwrok/file [10:09] as a replacement [10:10] cjwatson: what about target specific toolchain + sysroots? I have seen that model working? True, that it is not cheap to maintain. [10:10] pitti, that would be what CI or smoke testing use ... [10:11] ogra_: I'd still like the saving part, so that it's convenient for running tests locall [10:11] y [10:11] and we don't have to add another config file [10:11] ogra_: ah, saw your comment [10:11] well, i wonder if you could get the password from NM somehow ... [10:11] bzoltan: Sounds no easier to do that than to fix what we have :) [10:11] bzoltan: And definitely horrific ongoing maintenance costs because it'd be a big impedance mismatch [10:12] cjwatson: Right. Is it easy to understand what it takes to fix what we have? [10:12] pitti, after all nm-applet is able to show the password to you, so there must be a way for the pahblet user to get it somehow === vrruiz_ is now known as rvr [10:13] (replied) [10:13] ogra_: ah, good point; yeah, I suppose we can read them over -dbus [10:13] (via a dbus request) [10:13] and d-bus too [10:13] right [10:13] (or +dbus?) [10:13] heh, der bus iis schon weg [10:13] (nena) [10:13] * pitti prefers d-bike [10:14] (shirtest pop song ever btw ... 7sec or so ) [10:14] ogra_: so anyway, I think this should be an option [10:14] yeah :) [10:14] ogra_: i. e. either do a full factory reset, or one with maintianing network connections (it's just so convenient and useful) [10:14] i'll look into that after i have cracked the package install problem ... (i still have no proper idea here) [10:15] bzoltan: I don't know, sorry, currently trying to prepare to go to a conference and rebranch RTM :) [10:15] ogra_: oh, I'm happy to work on this, I'd just like to agree on a rough structure and whether it's acceptable to you [10:15] pitti, yeah, just a switch to phablet-config factory-reset [10:15] bzoltan: I'll put it on my list for September though [10:15] tvoss: nice linux voice interview :) [10:15] cjwatson: OK :) thanks [10:16] ogra_: ok; then you could either use phablet-config factory-reset --keep-network, or phablet-config factory-reset followed by phablet-network (which already exists) [10:16] yeah [10:17] ogra_: or perhaps even more granular: phablet-config save-network / phablet-config factory-reset / phablet-config restore-network ? [10:17] ogra_: most people wouldn't notice, as they just call adt-run; and for scripts it's more flexible [10:18] yeah, sounds good too ... just more to add to the help function though :) [10:20] ogra_: ok, so perhaps I'll go with that; if we ever want a factory-reset --keep-network it could just re-use those two other building blocks [10:20] ogra_: thanks! I'll send a summary to the bug [10:20] thanks ! [10:20] :) [10:20] glad we could find a solution :) [10:23] ogra_: sent to the bug [10:23] thx [10:24] nik90, thank you :) [10:24] nik90, did they end up putting my entirely un-geeky desk on the back of the issue? [10:25] tvoss: there were 2 pictures of you in the article itself..let me check [10:26] tvoss: oh yes they did! [10:26] tvoss: wow well organized desk [10:26] nik90, well, yeah ... my wife helps by constantly reminding me if it becomes unorganized [10:27] hehe [10:28] * nik90 cleans his desk [10:28] ogra_: actually, I suppose the save/restore should go to phablet-network, not phablet-config [10:28] hmm, yeah [10:28] ah no, maybe not [10:28] while the name sounds like that, the help and implementation doesn't [10:28] well, you get restore fro free [10:28] if you use phablet-network [10:29] yeah, restore == phablet-network [10:30] ogra_: we'll have to craft an NM config file from the nm-cli data (as we can't directly read the files), but that shoudln't be too hard [10:30] pitti, no [10:30] pitti, we need to use dbus queries to get ssid and key ... thats all [10:30] (thats all phablet-network uses actually) [10:31] it pushes the whole file, with UUID, ipv4/6 methods, and all the other fun bits (coudl also be an ad-hoc network etc.) [10:31] phablet-network (restore) only needs these two for its nmcli call [10:31] no, dont look at the old code ;) [10:32] ogra_: I'm looking at phablet-network in bzr+ssh://bazaar.launchpad.net/+branch/phablet-tools/ [10:32] yes, better look at my MP ;) [10:32] ogra_: ack, thanks [10:33] it still uses the file from the PC ... or a supplied file on the PC as input [10:33] but nmcli to set up the network on the device [10:33] sweet [10:33] so only the input chain needs changing [10:34] https://code.launchpad.net/~ogra/phablet-tools/pahblet-network-drop-root/+merge/230864 ? [10:34] yeah [10:34] adb shell "nmcli device wifi connect ${SSID} password '${KEY}'" [10:37] meh, factory reset doesn't work with dual-boot [10:37] * pitti tries with emulator === MacSlow is now known as MacSlow|lunch [10:51] ogra_: oh, phablet-config is python, great; I was afraid having to parse complex D-bus structures as text in shell :) [10:53] ah no, we do; it runs on the host, not on the device [10:58] pitti, heh, yeah [10:59] ogra_: ok, I figured out the necessary d-bus calls, so it's working (as phablet user) in principle [10:59] pitti, feel free to just write some python tool if you want, i can stuff it into some package on the device [11:00] i.e. in dbus-property-service or lxc-android-config or so [11:00] nah, that's fine [11:00] k [11:00] * pitti pats his best friend sesd [11:00] sed [11:00] :) [11:03] wow, what happened to the emulator? it's too fast! :) [11:03] sergiusens: nice job! [11:10] does anyone know how I can emulate pressing the power button on the emulator? i. e. for rebooting/switching off? [11:10] there is a ctrl key combo i think [11:11] pitti, http://developer.android.com/tools/help/emulator.html [11:11] cheers! [11:11] F7 it seems [11:12] indeed, that works [11:12] including the "have I held it down long enough now?" effect :) [11:13] eeek [11:13] * ogra_ just noticed phablet cant see /userdata [11:14] more dbus stuff to add :( [11:15] ogra_: ok, so system-setting's "reset" doesn't really [11:15] it keeps network, time zone, locale, doesn't bring back the wizard, etc (at least in dual-boot and emulator) [11:15] and it's not actually using the recovery method [11:17] ah, no /cache/recovery in the emulator, so nevermind [11:18] right, talk to kenvandine ... he wrote that bit iirc [11:18] gdbus call --system -d com.canonical.SystemImage -o /Service -m com.canonical.SystemImage.FactoryReset [11:18] jgdx, there is an issue with the ubuntu-system-settings changes you landed yesterday, you can't wrap translatable strings like you did, gettext doesn't handle it and make a different string to translate for each line [11:18] argh, again? didn't I just fix that a week ago? [11:19] https://code.launchpad.net/~pitti/ubuntu-system-settings/i18n/+merge/230062 [11:22] jibel, brendand: do you happen to have a device which you can factory-reset? it apparenlty doesn't work on dual-boot, but I need to get somethign verified [11:22] :q [11:22] or om26er? [11:23] pitti, yes, I have a cleanly flashed device, with its on 197 at this moment [11:24] om26er: so could you do the wizard etc., maybe change language or time zone, then phablet-shell, and run "gdbus call --system -d com.canonical.SystemImage -o /Service -m com.canonical.SystemImage.FactoryReset" [11:24] pitti, I have one running 202 [11:24] om26er: that shoudl reset everything, i. e. next boot starts with wizard again and it doesn't have network or your files [11:25] pitti, ok, will report back [11:25] om26er: cheers! [11:28] pitti, the phone rebooted after gdbus call, the wizard started and didn't know anything about the previous settings (language, lock mode, network) [11:28] it looks like the reset was successful [11:28] pitti, that reset the device yes.. [11:29] seb128, ah, right. There's a fix for that coming[1]. Thanks, though, didn't know that. [1] https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/1357393-fix/+merge/231347#diff-line-257 [11:29] jgdx, thanks [11:31] jibel, om26er; très bien, thanks! [11:31] jibel, om26er: that ran as phablet, not root, right? (phablet-shell, not "adb shell") [11:32] pitti, yes [11:39] Hola! [11:42] pitti, yes as phablet [11:49] sergiusens, one more https://code.launchpad.net/~ogra/phablet-tools/phablet-tools-phablet-config-changes/+merge/231711 [11:51] ogra_: you own phablet-tools now! [11:51] haha [11:51] if i own it, can i re-write it in shell ? [11:51] :P [11:52] sergiusens, wahetver you do, dont top approve yet, first dbus-property-service needs to land [11:52] (which waits for traincon-0 [11:52] ) [11:53] ogra_: well it needs a silo and testing anyways [11:54] that too [11:54] so I can top approve all I want :-P [11:54] which is tricky ... i dont want to land adbd yet [11:54] people testing need to install the deb [11:55] ogra_: btw, I bet you have cached mediascanner data [11:55] oh, beacuse of music-app working ? [11:55] well, mediascanner is running happily ... no crashes today [11:56] not sure how much it caches ... i have 32G of music on SD ... might indeed all come from the cache [11:58] ogra_: they do [12:00] ogra_: wipe flo or mako and see [12:04] ogra_: maybe the scope dropped it and actually needed it :-P [12:05] yeah [12:05] well, i imagined music app might use curl to pull album art [12:05] or is that downloaded lower in the stack ? i.e. mediacanner [12:06] I heard the album art was pulled by thumbnailer and not music app directly [12:06] ogra_: media scanner uses grilo and music app uses the media sanner [12:06] interesting [12:07] nik90: ogra_ they used to use grilo directly (when arch any), now they just use the qml bindings [12:07] so it's impossible for it to be a music app problem [12:07] oh, i never claimed it was ! [12:07] :) [12:07] but removing/adding the libs changes behavior ... so it influences something [12:08] * ogra_ just wants to know if he needs to seed the libs or one of them :) [12:08] may be it influences thumbnailer then [12:08] though seems tvoss answered that question for curl already ;) [12:08] ogra_: check out silo-3 which has thumbnailer which failed to build for some reason [12:09] ogra_, curl has to be around, yes :) [12:09] tvoss, right, now the question is "just around" or "part of the framework" :) [12:10] updated to trusty and cant open chrome [12:10] if i seed it in sdk-libs it becomes a piece of our framework ... if i seed it in touch it will "just be there" [12:10] gg, chrome doesnt run on the phone ... [12:10] ogra_, well ... I'm fine with magically there === tvoss is now known as tvoss|afk [12:11] tvoss, right, but if other infra pieces use it we would want it in the framework [12:11] ? [12:11] gg, this is the IRC channel for ubuntu on phones [12:12] o [12:12] go to #ubuntu for support :) [12:12] gg, gg :P [12:16] exited as you were recommending where i need visit [12:16] go to #ubuntu for support :) [12:16] thx [12:16] np === _salem is now known as salem_ [12:21] ogra_: tvoss|afk shouldn't be part of the framework directly; the libs that use it should just depend on it [12:21] right and i have the feeling we are somewhere missing a dep [12:21] sergiusens, for some bits that isnt possible btw ... i.e. some unpackaged pieces [12:22] ogra_: yeah, but for this case it should be [12:22] right [12:22] u1db is a different story [12:22] if the qml bindings for it are not in the sdk-libs then something has gone wrong [12:22] yeah, i start to think U1DB doesnt actually cause the issues here [12:23] that lib only provides C bindings ... not sure if there is another C++ one [12:23] or a qtu1db [12:23] :) [12:23] your empty albumart dir kind of points to curl though [12:24] i bet it fills up if you install the lib [12:25] ogra_: yup, qtu1db [12:25] * sergiusens tries [12:25] lol, and i was just guessing [12:27] ogra_, so that libu1db is not really used by the sdk correct? that only makes sense [12:27] and libcurl should have something in platform depending on it no? [12:27] pmcgowan, right, but curl seems to be used by "something" [12:27] preferably that something should have a package dependency [12:27] agreed [12:28] but I'm fine with temporary seeding it [12:28] can you find with rdepends magic? [12:29] a dependency tool to find a missing dependency would be cool indeed :) [12:29] lol [12:29] no, i cant really :) [12:29] yeah [12:29] maybe you can reply to the list again as everyone is panicing ;) [12:30] panicing ? we rolled back the change, they have time to inspect the issue [12:31] pmcgowan: ogra_ installing the curl lib and restarting the mediascanner brought me back my scope artwork [12:31] yeah [12:31] so it might be mediascanner that actually need the dep [12:32] ogra_, folks worried we are removing u1db from the sdk [12:32] not sure why === MacSlow|lunch is now known as MacSlow === Guest60224 is now known as renatu [12:46] anyone know the difference between these two lines? (Cmake) http://pastebin.ubuntu.com/8105986/ === chihchun is now known as chihchun_afk [12:48] jgdx: the second REQUIRED in the second line, is invalid [12:51] jgdx: you probably just want pkg_check_module() for the second line, as well [12:52] jgdx: http://cmake.org/cmake/help/v2.8.8/cmake.html#module:FindPkgConfig [12:52] dobey, so that's most likely a copy paste gone bad? [12:52] pmcgowan: (as one of the panickers), I think we saw libu1db, ignored the lib, and read u1db being removed from the seeds which worried us since click packages don't really allow specifying the dependencies an app needs. And removing u1db would be disastrous for our apps. [12:52] weird if so. probably just a misunderstanding of REQUIRED flag [12:53] nik90, indeed ;) [12:53] dobey, anyway, thanks. That conclusion seems to fit my current woes [13:18] With ubuntu touch on a nexus 7, does it run kernel by canonical or does it use the android kernel? [13:20] charles: http://pastebin.ubuntu.com/8106246/ [13:20] Jouke, it uses a patched and changed kernel built by canonical, based on the android source [13:21] charles: see line 24, “setting hardware wakeup time to 2014-08-21 13:03:55 for ubuntu push client” [13:21] charles: see no line(s) at 13:03:* [13:22] charles: it only woke up when i did so manually [13:26] Chipaca, that's worrying -- the lines at 24 - 26 look correct [13:26] charles: for my use case i don't care (no network => nothing to do), but the clock might think differently [13:27] charles: if this is a mako bug it's probably no biggie (maybe this is why it doesn't deep sleep if a sim is in); if it affects other devices, then probably yes [13:28] charles: would you have other devices to test with? [13:28] i'm afraid all i have are twin makos [13:28] my n4 is all I have to test with [13:28] ok, i'll pester sergiusens as i know he has some other ones [13:28] tvoss|afk, does http://bazaar.launchpad.net/~charlesk/powerd/add-hardware-alarms/view/head:/src/wakeup.cpp#L54 look correct to you? [13:28] * Chipaca grins at sergiusens [13:30] Chipaca: charles have a deb or silo I can install? [13:30] sergiusens: yes [13:30] sergiusens: gimme a sec [13:31] sergiusens: silo 10's ppa [13:31] sergiusens: has the powerd bits [13:31] charles, dednick, thanks for the clock fix ... would it be possible to make the UI ask for the updated time directly after the screen wakes up ? it still takes about a minute for me til indicator and lock screen update after resume [13:31] Chipaca: anything simple to test? [13:31] danilos: heya, just finished reviewing your branch; found a couple of small issues that I've commented on in the MR, as soon as those are fixed I think it should be good to go :) [13:32] sergiusens, if you enable POWERD_DEBUG=1 in powerd's upstart job, you can watch syslog to confirm what powerd's doing wrt hardware wakeups [13:32] sergiusens, along the same lines as Chipaca's pastebin link from 10m ago [13:33] charles: thanks [13:33] sergiusens: and let me get you a dbus call to do the thing, unless you want to build push from my poller branch [13:34] Chipaca: no, but a push-client binary would be good regardless [13:34] Elleo, cool, thanks, I'll fix them later tonight [13:35] danilos: great, thanks very much :) [13:35] sergiusens: gdbus call -y -d com.canonical.powerd -o /com/canonical/powerd -m com.canonical.powerd.requestWakeup potato $(($(date +%s) + 120)) [13:36] sergiusens: and disable networking on the device [13:36] sergiusens: and unplug it [13:36] sergiusens: and whatever else is needed for it to reach deep sleep before the 120 seconds are over [13:36] sergiusens: (the "disable networking" is not about deep sleep, it's about the bug, so do that also) [13:37] Can one mount a usb-stick to ubuntu touch? can one use it as a real linux device or are there specific limitation I need to think about? [13:37] ogra_, could you file an indicator-datetime ticket for that, assign it to me, and I'll look at it in a week or so [13:38] charles, cool ... yeah, not urgent or anything [13:38] ogra_, ack, I just want to make sure it gets files so I don't forget about it [13:38] Chipaca, do you pass a relative or absolute wakeup time? [13:39] tvoss|afk, the call to _set_relative_to_with_behavior() is at http://bazaar.launchpad.net/~charlesk/powerd/add-hardware-alarms/view/head:/src/wakeup.cpp#L54 [13:40] charles, sure, but you just hand down the time from the exposed function [13:41] Jouke, while the default behavior of the phone will not be much different to android or IOS, when you swithc it to developer mode you will find a totally normal ubuntu underneath, and indeed you can hack it up in any direction you want :) (i heard about people running a tomcat apache setup on a ubuntu touch nexus4) [13:43] ogra_: ok, that sounds really interesting :) [13:48] charles: hi. re that clock fix. I'm still seeing a bit of odd behaviour. this morning i switched screen on and it was 9:30pm for a few seconds. [13:50] charles: it seems that the clock stops updating every minute after awhile as well. I put some trace logging in indicator-datetime header update. http://paste.ubuntu.com/8106415/ and you can see that it's skipping minutes. [13:51] i pluggined phone into usb at 13:46, which is why it's updating now. [13:52] i haven't seen it skip more than 2-3 minutes so far though. [13:53] charles: but that did take all night to reproduce. [13:53] mterry, on the checkable, do you think it will work? I am quite confused with those bi-directional things [13:54] mterry, I am thinking about the case when you activate/deactivate the check setting while the backend still is loading [13:54] Cimi, I think so. If the inner gets clicked, it changer outer, which changes inner to same, but stops there [13:54] Cimi, shouldn't be possible due to dbus activation, I wouldn't think... [13:55] mterry, because I remember I was having issues with bi directional bindings [13:55] mterry, if situation now is fine, good, but just because of a signal? [13:55] Cimi, specifically with a race condition with the backend? [13:56] mterry, no, just aligning them across multiple places [13:56] But by the time the user sees this page, I would think the backend would be fine [13:56] Ah [13:56] mterry, if you had wizard and settings running at the same time [13:57] I honestly don't know :) [13:57] Cimi, I think it's fine... I didn't test settings running at same time, but I did test wizard and confirmed the backend was seeing change [13:57] mterry, that's good enough [13:58] mterry, as long as the final change arrives on the system settings [13:58] mterry, either true or false [13:58] mterry, otherwise we need to fix also the system settings checkable component [13:58] mterry, it was plugins/security-privacy/diagnostics/DiagnosticsCheckEntry.qml [13:59] and/or the new one for location [13:59] Let me test real quick [14:00] mterry, pls also check code of that checkable inside the system settings, I doubt it was updated... [14:01] Cimi, that's what I'm doing [14:01] mterry, also, update import Ubuntu.Components.ListItems to 1.0 [14:01] cjwatson: quick question for when you have a moment: is there a way to change the directory where "click chroot create" will create the chroots in ? [14:01] Cimi, oh? [14:01] Cimi, what does that get us? [14:01] nerochiaro: No [14:02] nerochiaro: Though you can always make /var/lib/schroot/chroots a symlink to somewhere else if you have space issues or something [14:02] cjwatson: yeah, that's the issue. does the target dir need to have specific permissions or owners ? [14:02] mterry, to make sure we get all the fixes if they fix those components [14:03] nerochiaro: I don't recall. root:root 0755 would be safe as that's the current ownership/perms of /var/lib/schroot/chroots [14:03] cjwatson: thank you [14:09] Elleo: any updates on maliit cleanup? [14:12] cjwatson: i tried what you suggested a minute ago but chroot creation fails as in this pastebin: http://pastebin.ubuntu.com/8106573/ [14:12] cjwatson: anything obviously wrong ? [14:18] nerochiaro: You probably have that on a different filesystem that's mounted either noexec or nodev, as the error from debootstrap suggests. Check /etc/fstab [14:19] cjwatson: it's a diff ext4 filesystem mounted as "defaults" [14:20] cjwatson: what is debootstrap looking for ? I can options that are needed to fstab [14:21] nerochiaro: It's trying to run "mknod /var/lib/schroot/chroots/click-ubuntu-sdk-13.10-armhf/test-dev-null c 1 3" [14:23] saidinesh5: do you mean in terms of memory usage? [14:23] Elleo: more like the changes you wanted to upstream so that i can at least see the vkb :P [14:24] saidinesh5: ah right, we haven't got anything upstream, but we have synced upstream with our packages now [14:24] I'm not sure it'll make any difference to your problems though [14:24] packages? [14:24] tsdgeos, dandrader: I've updated https://code.launchpad.net/~macslow/unity8/fix-1348092/+merge/228090 again, but now it needs https://code.launchpad.net/~macslow/unity8/qmltest-tweak-for-1354406-workaround/+merge/231687 to land in trunk before the former. [14:25] saidinesh5: yeah, the maliit-framework, libmaliit*, etc. packages in utopic are based on the latest git version of maliit [14:25] saidinesh5: plus our patches for building with qt5.3, gcc 4.9, etc. [14:25] Ahh [14:25] saidinesh5: they were 3 or 4 months behind maliit HEAD previously [14:25] ohh [14:25] nah [14:26] I don't think it'll make much difference for you though [14:26] i doubt that changes anything for me [14:26] i mean i m on maliit HEAD [14:26] I've got no idea why things aren't showing up for you [14:26] dednick, it's okay if it skips minutes overnight when the phone is suspended [14:27] saidinesh5: if I get a bit of time next weekend I'll have a bit of a play with the default maliit plugins and see if I can reproduce your issue [14:27] aye thanks Elleo === alan_g is now known as alan_g|tea [14:28] dednick, but ogra mentioned the failure-to-update when the screen comes back on too, I agree that one's frustrating [14:29] charles: ok [14:30] charles: but why does it skip? [14:30] dednick, (as long suspend is actually what's happening in the pastebin, that is... ) [14:30] dednick, I'll leave running overnight tonight and see if I get the same behavior === om26er is now known as om26er|doctor [14:32] dednick, I don't know why there are skips in that pastebin, e.g. lines 23-25 -- [14:33] dednick, next thing I'd look at is adding a debug message to clock-live.cpp's restart_minute_timer() and on_minute_timer_reached() functions to make sure the periodic timer is working [14:33] cjwatson: i mounted the partition with defaults,dev,exec but I still get the same problem. anything else you can think of that I can add to that fstab line ? [14:34] nerochiaro: no, sorry, you'll have to dig into why mknod is failing. Try running that manually to confirm, and perhaps under strace [14:34] nerochiaro: (and under sudo, obviously) [14:34] cjwatson: ok. i'll try that. thanks for the help so far === alan_g|tea is now known as alan_g [14:50]