[00:17] <matv1> does emulator run in a vm? does anyone know?
[00:18] <matv1> getting an error creating an instance
[07:20] <dholbach> good morning
[07:50] <ivivek> I have downloaded trusty binaries from for Nexus10
[07:50] <ivivek> how can I get the source code
[07:50] <ivivek> the documentation points to saucy code
[07:50] <ivivek> repo init -u git://phablet.ubuntu.com/CyanogenMod/android.git -b phablet-saucy
[07:51] <ivivek> I tried phablet-trusty branch....but it still seems to use the 4.2.2 versio of android
[07:51] <ivivek> but the binaries that I have installed used 4.4.2
[07:51] <ivivek> from where can I get code for trusty with Android 4.4.2
[08:25] <bman_> Can someone help me get ubuntu touch installed on nexus 7 (2013)
[08:27] <bman_> Can anyone help me?
[08:58] <popey> bug 1294768 is annoying me
[09:30] <JamesTait> Good morning all; happy Friday, and happy Common Courtesy Day! :-D
[09:50] <davmor2> Morning all
[11:18] <r3pwn> Is anyone that is porting this having an issue with locating an initrd-someotherstuffhere-touch when compiling?
[11:51] <timppa> Uh, just synced google calendar to touch. Calendar app does not seem to handle timezones correctly :( Is there a bug open for it?
[12:35] <popey> timppa: bug 1267814
[13:00] <davmor2> popey: I have a feeling that the issue with alarms tz and the calendar sync one is that eds is set to utc not the local timezone I bet :)
[13:42] <saxin> How can I find apps that other users have made for the Ubuntu-touch?
[13:42] <saxin> There is no software center etc?
[13:43] <ogra_> saxin, they are listed in the application lens under "available apps"
[13:43] <ogra_> (note this is populated with online data, so you need to be on wlan or 3G to see it)
[13:44] <saxin> I'm using the emulator atm
[13:45] <ivivek_> I tried getting trusty source using repo init -u git://phablet.ubuntu.com/CyanogenMod/android.git -b phablet-trusty
[13:45] <ivivek_> is this the right branch/repo ?
[13:46] <ivivek_> I did not find any documentation
[13:46] <ivivek_> but after building these sources for nexus10 the device does not boot
[13:46] <ivivek_> any idea ?
[13:47] <ogra_> ivivek_, any reason why you dont use the existing system images ?
[13:48] <ivivek_> I want to modify the android side code
[13:48] <ogra_> note that we switched to AOSP ... might be that the porting guide doesn not refelct this yet
[13:49] <ivivek_> ohh..ok. porting guide still mentiones cm10.1
[13:49] <ivivek_> from where can I get the sources ?
[13:49] <ogra_> phablet-dev-bootstrap should do the right thing i think
[13:50]  * ogra_ only uses the android package from the archive in the extremely rare cases when he needs to look at the android side)
[13:50] <ivivek_> so repo init -u git://phablet.ubuntu.com/CyanogenMod/android.git -b phablet-dev-bootstrap should work ?
[13:50] <ogra_> no
[13:51] <ogra_> phablet-dev-bootstrap should set up your tree for you
[13:51] <ivivek_> ohh...ok
[13:51] <ivivek_> got it....let me try
[13:51] <ogra_> https://wiki.ubuntu.com/Touch/Porting#Set_up_your_development_environment
[13:52] <ogra_> there is also some discussion on the ML currently where people provide some help for building the android HAL
[13:53] <ivivek_> ok...thanks...will search for it in the archives...
[13:55] <Tassadar> see https://lists.launchpad.net/ubuntu-phone/msg06378.html
[13:55] <cwayne> chrisccoulson, ping -- re: oxide WebView.Preferences... what kind of stuff would be exposed there?  anything that would make sense to be pre-seeded with custom defaults?
[14:01] <ivivek_> thanks a lot  @Tassadar and @ogra_
[14:02] <cwayne> mardy, hiya, are the click-hooks in now that 5.2 is in?
[14:02] <davmor2> asac, rickspencer3: regarding the decision to promote an image or not.  If you would like I can compile a full list like I did with image 237 on whether it was safe to land QT5.2.1, it will take some time but might help with the decision making to know that everything else is definitely green-ish
[14:03] <ogra_> yeah, looks like 250 is the most stable image in a long long time
[14:03] <rickspencer3> davmor2, that's fine, but my view is that we should wait and see what upstream says before we break our pledge of no-known regressions getting promoted
[14:04] <ogra_> rickspencer3, but how does it help us to see what upstream says ?
[14:04] <ogra_> we need it fixed regardless
[14:04] <rickspencer3> ogra_, because if it's our bug and we can fix it quickly, I think we should just wait to promote and not break our pledge
[14:04] <mardy> cwayne: noooo, you are too hopeful ;-)
[14:04] <ogra_> we cant fix it quickly
[14:05] <mardy> cwayne: we have a silo for that, under testing
[14:05] <ogra_> i think thats already clear
[14:05] <rickspencer3> ogra_, oh, I thought we didn't really know what the problem was, we just traced it back to the test case we put in the bug
[14:05] <ogra_> except by the Mir hack that will cut our battery life in half
[14:05] <ogra_> (i'm exaggerating :P )
[14:06] <cwayne> mardy, can't help bein' hopeful :D
[14:06] <rickspencer3> ogra_, oh, the mir hack, I don't think is the way to go
[14:06] <ogra_> rickspencer3, we know what the problem is, we just dont know exactly where in the code the commit is ... and the bi-secting takes huge amounts of time
[14:06] <mardy> cwayne: doesn't harm :-)
[14:06] <rickspencer3> that's also a regression, and a silly one
[14:06] <cwayne> mardy, as always, let me know if you guys need help testing or anythiing :)
[14:06] <davmor2> ogra_: I kill 2/3's of my battery overnight with the hack in place rather than the 1/3 that is normally gone
[14:06] <ogra_> becausee building Qt on arm is slow and takes really long
[14:06] <ogra_> -e
[14:07] <mardy> ogra_: is actually someone of us bisecting to try to find when the regression happened?
[14:07] <ogra_> davmor2, right, i dont think thats acceptable
[14:07] <ogra_> mardy, yes, Saviq is on it
[14:07] <davmor2> ogra_: it most certainly isn't
[14:07] <mardy> ogra_: cool
[14:07] <Saviq> assuming /me can build freakin' qtdeclarative other than 5.2
[14:07] <ogra_> but given the build time Qt takes i doubt we will have a definite answer today
[14:08] <rickspencer3> hmmm
[14:08] <ogra_> which is why i suggested this one time special casing
[14:08] <ogra_> to unlock the rest of the world
[14:08] <rickspencer3> ogra_, right
[14:08] <rickspencer3> ogra_, I'm not trying to blow you off
[14:08] <ogra_> :)
[14:08] <rickspencer3> and I appreciate that you are being pragmatic and thoughtful
[14:09] <saxin> ogra_: I'm looking for the "available apps for download" but I can't find it. I can see "Recent apps", "Installed" and "Dash plugins". When I watch youtube videoes of ubuntu-touch running on a real phone I can see the "Available apps..." Can the problem be that I use the emulator maybe?
[14:09] <davmor2> rickspencer3: Hence me asking if it is worth me compiling a full listing so we know all the other core apps are pretty much solid so the only regression would be the QT one that is a WIP
[14:09] <ogra_> saxin, sounds like
[14:10] <rickspencer3> davmor2, well, tbh .. I don't feel like this is my call to make
[14:11] <rickspencer3> however, my opinion is that we have been well severed wrt quality when we have not given in to impatience and frustrations and stuck to being systematic
[14:11] <rickspencer3> I think this is a tough call to make, and in absence of a clear path forward, I would counsel waiting until we know specifically what the issue is
[14:12] <rickspencer3> otherwise, we are promoting an image with a defect, and we don't really know where the defect i
[14:12] <rickspencer3> s
[14:12] <ogra_> i think we are in a special situation where we clash with the distro schedule and should make a one time exception
[14:12] <mterry> ogra_, btw, I got session-manager-touch renamed.  So if you hadn't noticed yet, don't be surprised
[14:12] <ogra_> but it is not my call to make either :)
[14:12] <ogra_> just throwing in my opinion here
[14:12] <rickspencer3> ogra_, again, I think you are being very reasonable
[14:13] <ogra_> mterry, well, i commented on the MP
[14:13] <ogra_> mterry, please get the issues fixed first
[14:13] <rickspencer3> I think your opinion is well thought out and pragmatic
[14:13] <rickspencer3> I'm just throwing my opinion out there too
[14:13] <ogra_> rickspencer3, so if its not your call either (which i thought it was) whose is it ? asac's ?
[14:13] <rickspencer3> and if comes down to me, I think we should uphold the value "no promotion with known regressions"
[14:14] <rickspencer3> ogra_, tbh, I don't know, I always thought it came down to the release team led by didr0cks
[14:14] <ogra_> well, he is not around this weekend (and today)
[14:14] <ogra_> so i thought it was asac and you to decide in this case
[14:15] <rickspencer3> ogra_, well, when I was asked what we should do, I said to stick to the value
[14:15] <rickspencer3> "no promotion with known regressions"
[14:15] <ogra_> k
[14:15] <ogra_> even if we might get a bad beta on desktop due to this ?
[14:15] <rickspencer3> ogra_, well, the thing is, I was asked yesterday
[14:16] <rickspencer3> when we didn't know as much about the bug as we do today
[14:16] <mterry> ogra_, oh sure, wasn't even thinking of that.  Will poke robru
[14:16] <rickspencer3> that said, it is my opinion that we still don't know enough, and we shouldn't promote
[14:16] <rickspencer3> however ...
[14:16] <rickspencer3> I think we should talk about how to not to block people
[14:16] <davmor2> rickspencer3, asac, ogra: didrocks is on holiday :)  How about this for a compromise then.  We just move the traincon:0 to traincon:1 so that things can still be landed if we all agree that the images today are solid bah the QT issue?  That unblocks as I understand will mostly unblock the teams right?  But still no promoted image as such
[14:17] <ogra_> rickspencer3, i think thats a sprint topic :)
[14:17] <ogra_> but wont help us now
[14:17] <rickspencer3> ogra_, of a mailin list topic :)
[14:17] <cjwatson> we could still promote an older image if we decide that we understand the problem well enough, even if we've later built a version that has some other regression
[14:17] <ogra_> (or rather wont help desktop now)
[14:17] <cjwatson> right?
[14:18] <ogra_> cjwatson, we dont have an older image ... the last we promoted was 237 ... (we are at 250) ... all images after 237 have Qt 5.2 and the issue
[14:18] <cjwatson> I think you misunderstand me
[14:18] <ogra_> but since 246 all images are green and have passed dogfooding as well ... the last three ones were the best images we had in a while
[14:19] <cjwatson> Rick doesn't want to promote 250 because we aren't sure we understand exactly where the event handling problem is (personally I found the bug report contents very persuasive, but anyway)
[14:19] <cjwatson> Let us say we go on and build 251, 252, etc.
[14:19] <cjwatson> Maybe they aren't quite as good as 250 for some other reason
[14:19] <cjwatson> But in the meantime, we get upstream feedback that means that we're confident we understand that our current diagnosis of the event handling problem is correct
[14:20] <cjwatson> We could then, as I understand it, promote 250
[14:20] <ogra_> cjwatson, right, i totally dont care about touch in this whole discussion ... we can indeed move along like you say, the prob here is the block for desktop that goes along with the block for touch ...
[14:21] <ogra_> we essentially block the weekend for fixes on desktop ... right before beta freeze
[14:21] <sil2100> hmmm
[14:21] <ogra_> (or s/desktop/archive in general/)
[14:21] <cjwatson> well, what I mean is we could unblock with the above as a plan once we get upstream feedback
[14:21] <cjwatson> it doesn't seem like we'd be any worse off by doing so
[14:24] <ogra_> ah, i get what you mean ... right, we could just unblock all ... and hope for the best
[14:24] <cwayne> well we can not promote an image and still land things right? just not touch-related things
[14:24] <ogra_> (and use 250 as fallback image)
[14:24] <ogra_> cwayne, the issues is that there are many overlapping things that block desktop
[14:26] <ogra_> *issue
[14:27] <ogra_> (indicators, plumbing etc)
[14:27] <bosnjak> hi all
[14:28] <bosnjak> in theory, how do i make a phone call when developing with python, outside of the SDK?
[14:28] <sil2100> Whatever you guys decide, I will follow - I have personally hoped that we might be able to fix  this issue fast, as in till today afternoon, but I guess it's a more complicated issue
[14:29] <sil2100> Not sure how this case was discussed on vUDS
[14:30] <ogra_> the issue is not to fix it fast ... there is simply a known delay in even building Qt to actually do the bi-secting
[14:30] <ogra_> the issue is well identified imho
[14:30] <sil2100> Right
[14:31] <ogra_> just not the specific commit that causes it ... and it is unlikely that we get info about this specific commit before monday
[14:32] <sil2100> Indeed, well, just saying that in the morning I have still hoped that it would be fixed till now, but as it's not so easy to find then we might really need to consider changing the approach
[14:47] <awafaa> on my Nexus4 I get the "ROM may flash stock recovery on boot. Fix?" message when trying to apply the latest update, what is the correct answer - yes / no / go back ?
[14:51] <saxin> ogra_: I tried the x86 Emulator now (was using ARM before) and now I can see the apps from other users. \o/
[14:57] <davmor2> awafaa: Flashing from android or from Ubuntu?
[14:58] <ogra_> saxin, awesome !
[14:58] <awafaa> davmor2: i flashed it from ubuntu, and now when I try and install the update (237 i think) i'm faced with the message
[14:58] <awafaa> if i select Go Back it always show update 237 available
[14:59] <davmor2> ogra_: ^ any clue?
[14:59] <davmor2> awafaa: I've never seen that
[15:01] <awafaa> it looks like the same message that is shown to Nexus 10 flashes (according to https://wiki.ubuntu.com/Touch/Install#Step_4_-_Downloading_.26_Deploying_Image_to_Device)
[15:02] <Tassadar> it doesn't matter, you can select whatever
[15:03] <Tassadar> stock android reflashes stock recovery if you flash any other, CWM has a "feature" to disable that behaviour
[15:04] <awafaa> ok
[15:04] <Tassadar> it doesn't really do anything when you're using Ubuntu, the /system partition is not even used
[15:04] <Tassadar> you can choose "yes" to make it stop with those messages
[15:15] <bfiller> Elleo: testing content hub changes from silo, seeing an issue with addres book app that may be related ot your change
[15:15] <bfiller> Elleo: after choosing a picture from gallery, it correclty shows up in address book. But when pressing "save" it disapears
[15:17] <bfiller> renato: can you try this on latest image? can you correctly choose a contact picture and save it without it disappearing?
[15:18] <Elleo> bfiller: ah, I see, when you save it doesn't show the image; but it seems it is actually saving it
[15:18] <Elleo> bfiller: if you go back to the contact list it's updated with the correct image
[15:18] <bfiller> Elleo: right, and if you favorite the contact the picture disappears again
[15:19] <bfiller> Elleo: don't know if this is a regression with your change or busted in the latest image
[15:19] <Elleo> if you go to edit and cancel it loses the image too
[15:19] <Elleo> I don't think favouriting should touch any of my changes
[15:20] <bfiller> Elleo: going to try without your chanages and see
[15:20] <Elleo> okay
[15:22] <kenvandine> bfiller, it failed for me just now, but backing out and going in again it showed the picture
[15:22] <kenvandine> ah, Elleo already pointed that out :)
[15:22] <kenvandine> sounds unrelated to this change
[15:25] <awafaa> erm, could someone advise why if i add my account details in System Settings>Accounts do i have to still add them into the individual app's?
[15:26] <awafaa> is that because the "apps" are just the web ones and not native (so no sharing of details)?
[15:27] <mhall119> Mirv: is Qt 5.2 going to be backported to Saucy in the SDK team ppa?
[15:28] <awafaa> Tassadar: btw, it looks it does matter what option i choose. both No & Go Back still result in update 237 trying to get rammed down my throat even though i've installed it numerous times
[15:28]  * awafaa gives Yes an go
[15:29] <balloons> m-b-o, are you set on this? https://code.launchpad.net/~martin-borho/ubuntu-weather-app/refactored-icon-handling/+merge/211214
[15:30] <m-b-o> balloons: yeah. bumped the .deb version
[15:31] <balloons> kk, so anything else you needed help on or are you set?
[15:31] <m-b-o> balloons: but something stranged happened: locally the float 19.8.... was rounded to 20, jenkins rounded the same value to 19
[15:31] <balloons> oO? interesting..
[15:32] <m-b-o> I've chanegd the test data to get it passed. Is jenkins already with Qt 5.2?
[15:32] <balloons> m-b-o, are you on 5.2?
[15:32] <m-b-o> hmm, not that I know
[15:33] <balloons> are you on trusty or no?
[15:34] <m-b-o> balloons: I'm on saucy and still 5.0.2
[15:35] <balloons> m-b-o, ahh, yes trusty is 5.2 now, and that happened last week?
[15:35] <m-b-o> balloons: it worked as expected
[15:37] <m-b-o> balloons: me is I've read something about changes changes to float values in 5.4. anyways... we should keep that in mind
[15:37] <m-b-o> balloons: but I have something else to show you :) https://bugs.launchpad.net/ubuntu-weather-app/+bug/1295612
[15:38] <balloons> yea, don't feel the need to test that sort of thing, as it's not part of weather :-)
[15:38] <mhall119> cwayne: ping
[15:39] <cwayne> mhall119, pong
[15:39] <bfiller> Elleo, kenvandine : problem existed before your change
[15:39] <mhall119> cwayne: do you have time today for a hangout about imporitng API docs?
[15:39] <bfiller> regression
[15:40] <balloons> m-b-o, how did the test change?
[15:41] <m-b-o> balloons: http://bazaar.launchpad.net/~ubuntu-weather-dev/ubuntu-weather-app/trunk/revision/163 line 324 and following
[15:41] <Elleo> bfiller: okay, thanks
[15:41] <balloons> ohh, something I've done eh?
[15:41] <m-b-o> balloons: :)
[15:42] <cwayne> mhall119, sure
[15:42] <mhall119> cwayne: how about in 15 minutes, are you free then?
[15:42] <balloons> m-b-o, sure, probably should docstring that test better so we know what we are intentionally testing
[15:42] <mhall119> cwayne: how about in 15 minutes, are you free then?
[15:43] <mhall119> bah, ignore the dup
[15:43] <m-b-o> balloons: indeed. Do you think we should keep this test around?
[15:43] <balloons> and stop me from changing the test, hah
[15:43] <balloons> m-b-o, if it's a specific action you want to check for then yes
[15:44] <balloons> you regressed on this at one point
[15:45] <m-b-o> balloons: not on the the action we're testing with the test. The test failed too with that workerscript issue
[15:46] <m-b-o> balloons: I'll fix the test by occassion, just wanted you to know :)
[15:46] <balloons> m-b-o, the goal of the acceptance tests is to ensure the user workflow is sound.
[15:47] <balloons> m-b-o, k thanks. Sorry for swapping it :-)
[15:47] <m-b-o> balloons: no problem :)
[15:58] <t1mp> popey: carrier: oFono (T-MeeGo) <-- what's that?
[15:59] <popey> t1mp: hmm?
[15:59] <popey> T-Mobile?
[15:59] <t1mp> popey: I  never saw that before. I have an American T-Mobile sim card in it (and I am in Europe), but the roaming icon disappeared from my status bar
[16:00] <t1mp> popey: so I was wondering why and I checked the carrier and saw that
[16:00] <popey> looks like a typo
[16:00] <t1mp> it never said oFono before. Just T-Mobile or something similar
[16:00] <popey> I've never heard of it before
[16:00] <Stskeeps> fwiw ofono-ril might have some memory corruption somewhere, on jolla devices we saw really odd operator names
[16:01] <Stskeeps> but didn't track it down
[16:01] <popey> thanks Stskeeps
[16:11] <boiko> jibel: hi, would you by chance have time to give me some help with some jenkins failures on telephony-service?
[16:17] <dragonkeeper> hello
[16:18] <dragonkeeper> vendor/cm/config/common_full.mk:4: ubuntu/assets/UbuntuAssets.mk: No such file or directory
[16:18] <dragonkeeper>  i keep getting this error what have i missed thats needed to obtain this file
[16:38] <jibel> boiko, sure, which failures?
[16:38] <boiko> jibel: https://code.launchpad.net/~boiko/telephony-service/conf_call/+merge/212055
[16:38] <boiko> jibel: I tried on a local pbuild chroot, and the tests pass
[16:38] <dragonkeeper> http://pastebin.com/GE3QcmLu   this is my full error
[16:59] <jonahbron> Does anyone know the status on the HUD working on the desktop with QML?
[16:59] <jonahbron> It doesn't seem to be working, so I'm guessing it's not finished being implemented.
[17:15] <boiko> jibel: so, any idea on what is going on there?
[17:15] <jibel> boiko, not yet, build is successful locally
[17:16] <boiko> jibel: it is weird that the most simple tests were the ones that failed, the other ones (involving dbus and so on) passed
[17:21] <awe> jdstrand, no
[17:21] <jdstrand> urfkill is root?
[17:21] <awe> cyphermox, ^^
[17:21] <awe> pretty sure that's a yes
[17:21] <jdstrand> well, non-user is good enough
[17:22] <awe> definitely non-user
[17:22] <awe> runs on the system bus
[17:22] <Wellark> awe: ok, so.
[17:22] <awe> has control over the kernel device killswitches ( bt & wifi )
[17:22] <Wellark> the only settable properties on Modem are
[17:22] <awe> and any ofono modem 'online' props
[17:23] <jdstrand> tyhicks: you here?
[17:23] <Wellark> Powered, Online, Lockdown
[17:23] <tyhicks> yes
[17:24] <Wellark> awe: I'm not sure how the Lockdown property should be used
[17:24] <jdstrand> tyhicks: so Wellark is thinking about making sure that urfkill can contact ofono for some method
[17:24] <jdstrand> s/that/that only/
[17:24] <Wellark> but for now, we would be OK to block the setProperty() for everyone except urfkill
[17:24] <jdstrand> tyhicks: apps are covered fine, cause they can't access ofono
[17:24] <awe> so the question, is can we lock down all SetProperty made to a specific object path, that are made from any process other than urfkill?
[17:25] <jdstrand> tyhicks: but he was wondering how to limit the access to ofono to only urfkill
[17:25] <jdstrand> tyhicks: I said to use polkit with appropriate policy to all the urfkill user access
[17:25] <Wellark> jdstrand: is there no way of specifying that the sender has to match a well known name?
[17:25] <awe> ie. d = org.freedesktop.ofono o = /org/freedesktop/ofono -i = ...DBus.Properties -m ...SetProperty
[17:26] <jdstrand> tyhicks: but, there was a question of how to protect ofono with apparmor
[17:26] <tyhicks> jdstrand: are either ofono or urfkill confined by apparmor?
[17:26] <Wellark> jdstrand: also it would be super useful at some point to be able to block only certain calls to a method based on the contents of the arguments
[17:26] <jdstrand> Wellark: we have 'peer', yes, but I asked tyhicks to join cause we haven't profiled in the way I'm thinking we would have to yet
[17:26] <Wellark> is that on the roadmap?
[17:26] <jdstrand> tyhicks: not yet, but they could be
[17:27] <tyhicks> Wellark: that won't ever be possible
[17:27] <awe> ok...let's slowdown
[17:27] <awe> first, jdstrand is apparmor the mechanism used to prevent apps from accessing org.freedesktop.ofono by default?
[17:28] <jdstrand> Wellark: we can't look at message contents safely/efficiently. we could do a super-gross hack in theory, but it isn't something we are planning, no
[17:28] <jdstrand> awe: yes
[17:28] <awe> ok
[17:28] <jdstrand> awe: apps are confined very strictly
[17:28] <awe> so at this point, unless we need to allow *some* apps to access, sounds like apparmor is tangential to this conversation?
[17:28] <Wellark> well, just thinking about all these API's that have a generic SetProperty(string, variant).
[17:28] <Wellark> like ofono
[17:28] <awe> Wellark, hold on a sec...
[17:29] <jdstrand> awe: some apps are considered 'trusted' and may run effectively unconfined. these are limited to Canoncail right now, but potentially OEMs where we have an arrangement
[17:29] <awe> ok
[17:29] <Wellark> awe: I'm just saying that if there is a writable property added to the Modem later on.
[17:29] <awe> Wellark, dude hold on a sec, I understand
[17:29] <Wellark> ok.
[17:29] <jdstrand> awe: then there are things that are installed via debs that run in the user's session-- those are typically not confined (though, they could be, but lets just use that as the dividing line atm)
[17:30] <awe> ok
[17:30] <cjwatson> mardy: sorry, I was just getting back to libaccounts-glib.  I see that dbarth suggested this should land with webapps-oa (which is silo 7), but I don't see it there?
[17:30] <jdstrand> awe: eg, on the converged desktop, thunderbird from the archive is not confined, but angry birds from the app store is
[17:31] <jdstrand> indicators are not confined
[17:31] <awe> right
[17:31] <jdstrand> system settings is not confined
[17:31] <jdstrand> etc
[17:31] <ogra_> angry birds is a eunuch app :)
[17:31] <awe> but those are effectively white-listed, right?
[17:32] <jdstrand> awe: no, not really. apparmor in Ubuntu uses targeted policy. by default things are unconfined unless you define policy for it
[17:32] <jdstrand> awe: we define policy for all untrusted 3rd party click apps
[17:32] <awe> ok, but what about polkit then?  Does it comes into play for arbitrary process started in the user session?
[17:33] <awe> or does the process need to be whitelisted in a system polkit file?
[17:33] <jdstrand> awe: we don't for most other things. you can see what is confined by doing 'sudo aa-status'
[17:33] <awe> right, but that's apparmor
[17:33] <jdstrand> yes
[17:33] <jdstrand> polkit is something you write in your application
[17:34] <awe> right, which can cause auth to happen
[17:34] <jdstrand> it is specifically designed to allow defining policy for methods in your dbus api
[17:34] <awe> sorry been heads down in MMS land recently
[17:34] <jdstrand> that policy can say things like 'no prompt for root', 'no prompt if user on the console', etc
[17:34] <awe> but there's the low-level dbus policy files
[17:34] <awe> yup
[17:35] <jdstrand> the low level policy files are less flexible
[17:35] <jdstrand> (fyi, https://wiki.ubuntu.com/SecurityTeam/PolicyKitPermissions/12.04 has some info and links to help with understanind how polkit permissions work)
[17:36] <jdstrand> tyhicks: can you describe how the dbus policy files work-- isn't it for uid and bus? is there more?
[17:36]  * jdstrand can't remember otoh
[17:36] <tyhicks> I don't know of the top of my head either
[17:36] <awe> jdstrand, so I'm going to have poke at this later...  I believe the current images lock down ofono @ the dbus level, and then processes that need to interact add there own policy files
[17:36] <jdstrand> ok, let me try to pull up the docs
[17:36] <awe> one sec...
[17:36] <tyhicks> I haven't had to deal with them at all while developing aa mediation
[17:37] <jdstrand> http://dbus.freedesktop.org/doc/dbus-daemon.1.html
[17:37] <jdstrand> it seems mostly what I said
[17:37] <tyhicks> jdstrand: they're embedded into the bus config files, so it is specific to the bus
[17:38] <dbarth> cjwatson: we're having multiple issues with this silo content
[17:38] <dbarth> cjwatson: do you think you can have your branch go into another batch to have it land more quickly
[17:38] <jdstrand> actually, there is more flexibility than I thought
[17:38] <dbarth> otherwise, i will need to re-do a pass on monday with the silo content, cause we have found new bugs
[17:39] <dbarth> (not with the multi-arch bits)
[17:39] <tyhicks> yeah, the policy language does look mostly full featured
[17:39] <awe> jdstrand, tyhicks, Wellark, here's the ofono dbus conf file: http://pastebin.ubuntu.com/7131742/
[17:39] <awe> it
[17:40] <jdstrand> awe: so, you might be able to get away with just dbus policy files. polkit could be used if you want to add prompting or overriding
[17:40] <awe> jdstrand, ack
[17:40] <awe> it looks like by default, root is allowed full access to ofono, but everything else is denied by default
[17:41] <awe> Wellark, have you tested any of this while running as 'phablet' and confirmed that things are unrestricted?
[17:41] <jdstrand> well, there is the at_console policy
[17:41] <awe> how does that apply to a touch device?
[17:42] <Wellark> awe: they are not as indicator-network install dbus permission file which allows phablet to access ofono
[17:42] <awe> is that a big hole?
[17:42] <Wellark> as indicator-network is run as phablet user
[17:42] <awe> Wellark, ah...
[17:42] <awe> ok
[17:42] <jdstrand> the phablet user should be considered 'at_console'
[17:42] <jdstrand> but, urfkill-- that is non-phablet?
[17:42] <awe> right
[17:43] <Wellark> yep.
[17:43] <Wellark> ofono and urfkill run as root
[17:43] <jdstrand> so if it runs as root, it should be fine. if it doesn't and isn't 'phablet', it won't be at_console
[17:43] <awe> but if Wellark had a dbus conf file for the indicators, that leads me to believe indicators aren't "at_console"
[17:43] <jdstrand> so you could add a <deny send_interface="dangerous interface"> under at_console
[17:44] <Wellark> indicators are at_console as they are run inside user session, right?
[17:44] <jdstrand> and then <policy user="urfkill user">Mallow send_interface="dangerous interface">
[17:44] <Wellark> this is something that needs more investigation
[17:44] <jdstrand> note, this is otoh glancing at the policy you pasted-- I don't know all the policy for ofono, so you'd want to go through it and verify
[17:45] <cjwatson> dbarth: well, it was your suggestion
[17:45] <jdstrand> Wellark: indicators are running as the phablet user, so yes
[17:45] <cjwatson> dbarth,mardy: I'd be quite happy for it to go into a separate batch, but I have the problem that I can't just land my libaccounts-glib branch because there's other significant development already on trunk
[17:45] <jdstrand> again, I am not speaking authoritatively-- I haven't looked at all the policy
[17:45] <awe> if that's true, then theoretically you wouldn't need to have added dbus conf files for the indicstor
[17:45] <awe> I'm confused
[17:46] <jdstrand> that is what I'm thinking
[17:46] <cjwatson> dbarth,mardy: one alternative option is that I could just upload it directly to the archive
[17:46] <awe> well, it is friday
[17:46] <awe> ;/
[17:46] <Wellark> awe: I haven't added the file. it has been hanging around
[17:46] <Wellark> I need to check if it's still needed
[17:46] <jdstrand> perhaps the at_console is way too lenient
[17:47] <awe> if you could check that on your own that'd be great.  I have some other stuff to finish this afternoon, so I will make this a task for Mon
[17:47] <jdstrand> but, presumably the dialer-app needs it
[17:47] <awe> yea...
[17:47] <Wellark> yeah..
[17:47] <Wellark> awe: I don't have mental CPU cycles to check this today
[17:48] <Wellark> but I will put it on TODO list
[17:48] <awe> Wellark, could you add an ofono bug about locking down 'Online' as I asked earlier, and I'll start working on it?
[17:48] <awe> haha
[17:48] <awe> you brought it up1
[17:48] <jdstrand> so, I like the critical thinking around this. I do want to say that currently we have the concepts of trusted apps. the dialer-app and the indicators are trusted
[17:48] <Wellark> awe: I was only making a suggestion ;)
[17:48] <awe> jdstrand, tyhicks, thanks for your input;  you may be hearing from me again next week after I do a bit of a survey
[17:48] <Wellark> awe: I will file the bug
[17:49] <awe> Wellark, thanks!
[17:49] <jdstrand> awe: ok
[17:49] <jdstrand> tyhicks: but before you go
[17:49] <tyhicks> sorry for going quiet - I was shuffling through the dbus-daemon code to understand how it does at_console
[17:49] <jdstrand> tyhicks: I was thinking about what if ofono was confined
[17:50] <jdstrand> tyhicks: today, could we say that only a process running under a certain profile can connect?
[17:50] <jdstrand> well connect
[17:50] <tyhicks> jdstrand: what do you mean by connect? send a message?
[17:50] <jdstrand> more I mean, can we specify policy for a process running ander a specific file, and say, deny to unconfined?
[17:51] <jdstrand> meh
[17:51] <jdstrand> too many typos
[17:51]  * awe thought it was only him with the fumble fingers today
[17:51] <jdstrand> more I mean, can we specify policy for a process running under a specific profile, and say, specify deny for unconfined/everything else
[17:51] <jdstrand> tyhicks: ^
[17:51] <awe> ah, which would cover anything installed by normal debs...
[17:52] <Wellark> awe: the worst case scenario is that we need to come up with utility API's that are designed in a way that we can confine them at the exact level we want :)
[17:52] <awe> that ran in the user session
[17:52] <Wellark> but let's not go there yet
[17:52]  * tyhicks thinks
[17:52] <jdstrand> tyhicks: I know we talked that sort of thing long term, but I wasn't sure we could do it now
[17:53] <tyhicks> jdstrand: can you come up with an example rule? I want to make sure I'm understanding
[17:53] <jdstrand> tyhicks: ie, this is pretty much the conversation about confining the trusted helper
[17:54] <jdstrand> tyhicks: ah, I might be thinking of using 'label'
[17:54] <jdstrand> let me make something up
[17:54] <jdstrand> profile ofono { dbus bus=system label=urfkill ..., }
[17:55] <jdstrand> tyhicks: ie, *only* urfkill can talk to ofono
[17:55] <tyhicks> it would be like this:
[17:55] <tyhicks> profile ofono { dbus bus=system ... peer=(label=urfkill), }
[17:55] <jdstrand> (I realize urfkill would need to have a profile name)
[17:56] <jdstrand> run under that profile
[17:56] <jdstrand> ok, so yes, it is possible
[17:56] <tyhicks> yes
[17:56] <tyhicks> profile ofono { dbus bus=system (send receive) peer=(label=urfkill), }
[17:56] <jdstrand> so we could define some basic profiles for dialer-app, urfkill, indicator-network
[17:56] <awe> but urfkill runs as root
[17:56] <jdstrand> then a loose policy for ofono
[17:56] <tyhicks> that rule would allow cross talk between ofono and urfkill
[17:56] <dbarth> cjwatson: i think that's easier: feel free to do so; i don't want to block you anymore at this stage
[17:57] <awe> jdstrand, we'd also need to ensure that NM could talk to ofono
[17:57] <tyhicks> yep
[17:57] <awe> and telepathy-ofono
[17:57] <awe> and ...
[17:57] <awe> nuntium
[17:57] <jdstrand> with dbus rules for letting dialer-app, urfkill and indicator-network to talk to it
[17:57] <jdstrand> awe: sure, this is just thinking out loud
[17:57] <jdstrand> tyhicks: that would work today, no?
[17:58] <tyhicks> jdstrand: it should work just fine
[17:58] <jdstrand> neat
[17:58] <awe> and those profiles could have granularity down to a method call?
[17:58] <jdstrand> tyhicks: I've not used 'label' in policy yet, so I wasn't sure how to apply it
[17:58] <jdstrand> awe: yes
[17:58] <Wellark> uuh, that sounds awesome
[17:59] <tyhicks> I'm trying to see if we have tests for any rules like that
[17:59] <Wellark> would it be possible to allow a click application to access some of the dbus API's also given the app has sufficient permissions given by the user?
[17:59] <awe> so again, I think to answer Wellark's original question, we'd want to guard a specific destination=org.freedesktop.ofono object=/org/freedesktop.ofono interface=...DBus.Properties and method=SetProperty
[18:00] <awe> and only allow urfkill access to the same ^^
[18:00] <jdstrand> Wellark: essentially, no (there is actually something we could do with hooks, but lets not discuss that yet)
[18:00] <Wellark> awe: ofono does not implement org.freedesktop.Properties
[18:00] <Wellark> jdstrand: ack
[18:00] <jdstrand> Wellark: but apps have an explicit deny to talk to ofono anyway
[18:00] <jdstrand> we consider it too risky right now. maybe down the line we can relax it if there is a compelling use case
[18:01] <Wellark> jdstrand: yeah, just thinking if we need an SDK API for accessing some info that ofono provides
[18:01] <Wellark> or any of these services
[18:01] <jdstrand> Wellark: that I think gets back to the connectivity api thostr_'s team was working on
[18:01] <Wellark> jdstrand: I'm the main developer of connectivity-api
[18:01] <Wellark> :)
[18:01] <tyhicks> jdstrand: unfortunately, we don't have any test cases that use peer=(label=foo) right now, but I fully expect it to work
[18:01] <jdstrand> I'd *highly* prefer apps use that and not contact ofono/nm directly
[18:01] <jdstrand> ah, well there you go
[18:02] <tyhicks> I think I can add some to QRT without much trouble
[18:02] <awe> Wellark, then the change the interface to /org/freedesktop/ofono
[18:02] <jdstrand> Wellark: so, is that an out of process service or just something down deep in a library that runs in process to the app?
[18:03] <Wellark> jdstrand: right now it's a library that monitors signals coming from NM
[18:03] <jdstrand> yeah, apps are going to have trouble with that
[18:03] <awe> I can't keep track of which daemons use the correct DBus.Properties, and which don't.  Should've been mandatory in my opinion.  too much rope available to screw things up
[18:03] <awe> but it's still the same basic protection rule
[18:03] <awe> with a different interface
[18:03] <jdstrand> (cause the app has to talk to nm directly)
[18:04] <Wellark> jdstrand: so we would have to come up with connectivity-daemon
[18:04] <jdstrand> which, incidentally, is also explicitly denied
[18:04] <Wellark> which is the one that the connectivity-api talks to
[18:04] <Wellark> and then the connectivity-daemon is allowed to talk with system services
[18:04] <jdstrand> Wellark: yes, I have been advocating for that
[18:04] <Wellark> jdstrand: yep.
[18:04] <awe> connman?
[18:04]  * awe ducks
[18:04] <cyphermox> not the same
[18:05] <jdstrand> Wellark: it will keep things very clean for the apps, and the connectivity-daemon can do whateve it needs
[18:05]  * awe someone wouldn't find that funny
[18:05] <awe> ahhh
[18:05] <cyphermox> NM can do the connectivity api as much as connman could anyway
[18:05] <awe> s/someone/knew someone/
[18:05] <jdstrand> we could drop all kinds of dumb /sys/class/net and /proc rules in the policy now
[18:05] <Wellark> jdstrand: yeah, I know.. will need to figure it out.
[18:05] <jdstrand> (see the the connectivity policy group)
[18:06] <jdstrand> Wellark: cool
[18:06] <awe> cyphermox, we're discussing how to integrate the connectivity api into the SDK in a trusted helper manner
[18:06] <cyphermox> yes, I can follow
[18:06] <cyphermox> just sayin'
[18:06] <awe> so the connman quip was a joke
[18:06] <cyphermox> I know ;)
[18:06] <cyphermox> I'm saying though, connman or NM, absolutely the same thing
[18:07] <awe> yes
[18:07] <Wellark> agreed.
[18:07] <jdstrand> it is Yet Another Daemon, but that is our model-- we have helpers with reasonable, controlled apis that apps can talk to rather than talking directly to services that change all the time and aren't designed to work with untrusted applications
[18:07] <Wellark> jdstrand: indeed
[18:07] <Wellark> like the generic SetProperty()
[18:07] <awe> yea, just kinda makes my head hurt
[18:07] <cyphermox> yes
[18:07] <Wellark> we have no way of allowing just some of the properties to be changed
[18:08] <Wellark> it's all or nothing
[18:08] <cyphermox> well, the SDK is supposed to be your way to do this
[18:08] <jdstrand> Wellark: I'm super glad we had a chance to chat-- it has been on my todo list to talk to you (though I didn't know it was you :) about the connectivity api
[18:08] <awe> it'd be nice for use to figure out some way of mediating comms to our existing daemons without having to add yet another(s)
[18:08] <cyphermox> awe: +1
[18:08] <Wellark> I don't want to add any unneccessary daemon, to be clear
[18:09] <cyphermox> no, we know
[18:09] <jdstrand> Wellark: so, with the connectivity-daemon, just like indicator-network, dialer-app, and nm, we could allow connectivity-daemon to talk to ofono
[18:09] <cyphermox> but there doesn't appear to be much choce
[18:09] <awe> jdstrand, there is not "connectivity daemon"
[18:09] <jdstrand> (and urfkill)
[18:09] <jdstrand> awe: not yet :)
[18:09] <Wellark> yeah, we don't have it right now
[18:09] <cyphermox> awe: no, just projecting
[18:09] <jdstrand> I'm just saying, in the future, that is what we could do
[18:10] <awe> and myself and cyphermox are saying it'd be nice to figure this out without having to add yad
[18:10] <jdstrand> apps can talk to connectivity daemon, but not nm and ofono
[18:10] <cyphermox> awe: we're lacking in other options though
[18:11] <cyphermox> you can't really differentiate between a call through the API (library) that does a DBus call from a DBus call directly done by the app
[18:11] <jdstrand> well
[18:11] <Wellark> and if we would have the connectivity-daemon in a trusted helper style then we could introduce app permissions in arbitrary granularity
[18:11] <cyphermox> that's why having the app speak to a daemon, which then is the only point of contact between it and other daemons (nm, urfkill, ofono, etc)
[18:11] <jdstrand> well, nm could be 'connectivity-daemon' with a very simple api for apps to use
[18:11] <cyphermox> well, yeah, daemon/trusted-helper
[18:11] <cyphermox> jdstrand: it could, indeed
[18:12] <jdstrand> then we could let apps talk to those methods *only*
[18:12] <cyphermox> but Wellark has build some other things around it
[18:12] <awe> right, why can't we define an app profile?
[18:12] <cyphermox> and that wouldn't solve the issue for MMSs / numtium
[18:12] <jdstrand> the problem is right now, various libraries (eg, QtSystemInfo::NetworkInfo) jump all over the entire nm dbus api and leak too much info
[18:12] <cyphermox> yep
[18:13] <awe> ok, I remember
[18:13] <cyphermox> jdstrand: well *our* api could just not use that and speak to NM directly, ask just what it really needs
[18:13] <awe> we can't lock down access to particular properties
[18:13] <cyphermox> but then can we lock apps from using the other QT bits
[18:13] <jdstrand> but, if it had a controlled connectivity sub-api that didn't require the app to jump all over, then that should be fine. we'd remove the current explicit denial and add allow rules for that sub-api
[18:13] <cyphermox> awe: no, but if the sdk only does a call to $method, it's fine
[18:13] <awe> sure
[18:14] <cyphermox> yeah
[18:14] <awe> but there was about certain props that contained privacy related data
[18:14] <jdstrand> (and that still works with the previous confinement idea tyhicks and I discussed)
[18:14] <cyphermox> AFAIK it doesn't currently require the app to jump all over except maybe for one thing that apps really ought not to do
[18:15] <cyphermox> (getting the IP address)
[18:15] <awe> Wellark, we already have a daemon that proxies communication to NM; it used to be called chewy
[18:15] <awe> ;D
[18:15] <awe> and it runs in the user session
[18:15] <cyphermox> awe: doesn't chewy actually do MM rather than NM though?
[18:15] <awe> haha
[18:15] <awe> not
[18:15] <awe> NM does MM
[18:15] <cyphermox> ok ;)
[18:15] <awe> chewy --> indicator-network
[18:16] <cyphermox> right right
[18:16] <awe> ( there might be a suffix involved )
[18:16] <jdstrand> cyphermox: if you look at 'aa-easyprof --policy-vendor=ubuntu --policy-version=1.1 --show-policy-group -p connectivity' you can see what it did about 6 months ago
[18:16] <cyphermox> jdstrand: ok
[18:17] <jdstrand> 'it' being QtSystemInfo::NetworkInfo
[18:17] <Wellark> jdstrand: I need to go
[18:17] <Wellark> jdstrand: but we could chat in more detail next week
[18:17] <jdstrand> Wellark: ok. thanks for the chat :)
[18:17] <jdstrand> sure
[18:18] <jdstrand> cyphermox: notice, most of that output of that command is commented out-- we don't allow it cause it reveals too much info
[18:22] <cyphermox> jdstrand: yeah, well NetworkInfo probably gets you an IP, which the apps shouldn't have to ever care about
[18:22] <cyphermox> and that I can see how it would dig to get the value
[18:25] <jdstrand> it was that and mac iirc. the ofono ones gave at quite a bit too
[18:29] <cjwatson> dbarth: done
[18:29] <cjwatson> mardy: ^-
[18:36] <dbarth> cjwatson: thanks and sorry for the false start
[18:50] <davmor2> mzanetti: tagger is crashing on QT5.2.1 on mako just a heads up
[18:51] <davmor2> mzanetti: it connects to the camera then shortly after dies
[18:58] <mzanetti> davmor2: ok, thanks for the info. will rebuild it
[19:09] <timppa> Evening! Is there any particular reason why nexus 7 is not detected by sdk?
[19:33] <dafo> how long should the boot after the autodeploy.zip step take? It's been ~15min already
[19:33] <dafo> 14.04 on Galaxy Nexus
[19:37] <dafo> still on google logo
[20:24] <elcuco> hi, the instructions mention how to install from ubuntu, but I am running debian. how can i install from debian...?
[21:01] <taiebot> Hey guys congrats for promoting 250 however i have a lots of apps which do not start. So far Music. Calendar,sudoku. notes. I am the only one with this problem?
[21:03] <popey> taiebot: update them using update manager
[21:04] <taiebot> I have nothing to update in update manager. While i had some to update in the previous image but they were giving me command error now they are not showing up might be related.
[21:05] <popey> I'll investigate a bit more
[21:06] <taiebot> popey: If you need anything from me let me know .
[21:06] <popey> taiebot: can you pastebin the output of "adb shell sudo -u phablet click list"
[21:06]  * mrjazzcat just got a Nexus 7 (2013).  Should I put Android 4.4 on it, since that appears to be the latest target of work?
[21:07] <mrjazzcat> that is, before I put dualboot Touch.
[21:08] <taiebot> popey:http://pastebin.com/gmqCUm4d
[21:13] <ZeeO> nexus 5 support yet?
[21:19] <taiebot> popey: should i uninstall and reinstall through the store?
[21:26] <taiebot> Shit desinstalled music app and its not present on the store.
[21:27] <taiebot> Well no music for me :)
[21:27] <popey> hmm
[21:27] <elcuco> eventually i used schroot to get a working ubuntu and from there I executed the commands.
[21:28] <elcuco> on second thought, I could "fastboot flash" and that would have been easier...
[21:28] <elcuco> but hey, now I have an schroot for ubuntu :)
[21:28] <popey> taiebot: so according to the paste you had version 1.3.389 right?
[21:30] <taiebot> Certainly. I have removed it to upgrade via store to see if the app could start but i do not see the app.
[21:30] <popey> ok, lets see if we can manually install it
[21:30] <popey> http://popey.mooo.com/mirror/clicks/2014-03-21-100001/com.ubuntu.music_1.3.389_armhf.click
[21:30] <popey> download that
[21:31] <popey> i have 389 on my #250 phone and it starts fine
[21:31] <taiebot> remind me what i should put on on adb shell?
[21:31] <taiebot> to install
[21:31] <popey> hang on
[21:32] <popey> dont install yet
[21:32] <popey> adb shell sudo -u phablet click list | grep music
[21:32] <popey> anything show?
[21:33] <taiebot> nope
[21:34] <popey> how did you uninstall it?
[21:34] <taiebot> hold on app uninstall.
[21:34] <popey> ok
[21:36] <popey> taiebot: so if you search for music you dont see it?
[21:36] <popey> on the apps lens?
[21:36] <taiebot> NO get eyrie panpipe uclick, but no music app
[21:37] <popey> hm
[21:37] <taiebot> I have 16 app showing when i search music but no music app
[21:38] <popey> i dont quite understand why you can't see it
[21:38] <popey> adb shell system-image-cli --info
[21:38] <popey> what version does it say?
[21:39] <popey> current build number: 250
[21:39] <taiebot> current build number: 250
[21:39] <taiebot> correct thats what i get
[21:42] <taiebot> installed utudu and it worked as expected
[21:45] <taiebot> trying windows fix (rebooting ...) :)
[21:48] <popey> heh
[21:48] <taiebot> popey: do you want me to try if i get same behaviour with other app which do not start?
[21:48] <popey> yes, lets focus on one app
[21:48] <popey> find one that wont start, then find the log in /home/phablet/.cache/upstart
[21:49] <popey> most recent log file in that directory will probably have the app name in it
[21:50] <taiebot> there is lots of logs there.
[21:50] <popey> ls -ltrha
[21:50] <popey> after you start the app
[21:51] <popey> e.g. application-click-com.ubuntu.calendar_calendar_0.4.214.log
[21:52] <taiebot> mm will need more explanation i am in upstart directory what do i do now sudoku app do not start
[21:53] <popey> ok, so cd /home/phablet/.cache/upstart
[21:53] <popey> ls -ltrha
[21:54] <popey> look for the file at the end of the list
[21:54] <popey> probably called application-clickp-com.ubuntu.sudoku..... something
[21:55] <taiebot> well the problem it is not there if i start the app.
[21:56] <popey> are you logged in as phablet or root?
[21:56] <taiebot> i have last five unity8.log, dbus.log hud.log
[21:57] <taiebot> tried with an app which start and its there.
[21:57] <Tassadar> I can reproduce that with my N5 - calculator app simply won't start, just shows white screen. It doesn't create any log file in /home/phablet/.cache/upstart, unless I'm blind and the log file doesn't have "calc" in it's name
[21:57] <Tassadar> taiebot: which device do you have?
[21:58] <taiebot> N4
[21:58] <popey> ok
[21:58] <popey> what version of calculator do you have installed?
[21:58] <Tassadar> on the other hand, sudoku works for me
[21:58] <popey> click list | grep calculator
[21:58] <Tassadar> com.ubuntu.calculator   1.3.235
[21:59] <Tassadar> and my sudoku is 1.0.177
[21:59] <Tassadar> image 250, no updates in the click update app
[22:00] <popey> 235 is latest calculator
[22:00] <popey> hmm
[22:00] <Tassadar> grepping for "calc" in the logs folder reveals "hud.log:Attempt to remove window 0 from non-existent application "com.ubuntu.calculator_calculator_1.3.235""
[22:02] <Tassadar> I think I've updated the calc app via the click update app on one of the previous images, if that's relevant
[22:04] <Tassadar> same for clock app, which doesn't start as well, I've updated that one just now, when the device was running image 250 already
[22:05] <Tassadar> but clock app won't even show the white screen, it just does nothing after tapping the icon in the launcher
[22:05] <popey> can you try adb shell dmesg -T | grep DEN
[22:05] <popey> an see if you get any DENIED lines?
[22:06] <taiebot> nothing for me
[22:06] <Tassadar> https://paste.tinyw.in/index.php/view/raw/14807256
[22:06] <Tassadar> only for the sudoku app, which opens
[22:08] <popey> jdstrand: ^^
[22:08] <popey> hmm
[22:08] <popey> I'm perplexed
[22:09] <Tassadar> oh, the clock app got uninstalled by the click update app, I guess
[22:10] <popey> it shouldnt
[22:10] <Tassadar> I suppose it failed to update it for some reason
[22:10] <popey> no the update doesn't work like that
[22:10] <popey> there is two places the app can be
[22:10] <Tassadar> wait, I'll give you logs
[22:10] <Tassadar> https://paste.tinyw.in/index.php/view/raw/99809711
[22:10] <popey> in /opt/click.ubuntu.com/<appname>
[22:11] <popey> or /usr/share/click/preinstalled/<appname>
[22:11] <Tassadar> and its icon disappeared
[22:11] <popey> what versions are in there?
[22:11] <popey> and also in /home/phablet/.local/share/applications do you have a .desktop file for the app?
[22:12] <Tassadar> in opt is 1.0.369 and in usr 1.0.373
[22:12] <Tassadar> and I have a desktop file, com.ubuntu.clock_clock_1.0.373.desktop
[22:14] <Tassadar> I have had this installation for quite some time, and it's trusty-proposed, it might have got corrupted during that click update problems last week (or was it the one before that?)
[22:14] <popey> ok
[22:14] <popey> so the version in 373 should take precidence
[22:15] <Tassadar> the updated versions go to /opt, right? why did it install 369 in there, then? Oo
[22:18] <Tassadar> /opt contains older version of calculator as well, 0.1.3.224, and I'm quite sure I updated that one on one of the previous images
[22:19] <Tassadar> taiebot: by the way, are you using any kind of multiboot?
[22:20] <taiebot> no normal install
[22:20] <Tassadar> try to ls /opt/click.ubuntu.com/ on the device, are all the apps which you can't open in there?
[22:21] <taiebot> cd /opt/click.ubuntu.com/
[22:21] <taiebot> ls
[22:21] <taiebot> sorry wrong place :-D
[22:23] <taiebot> there is lots of apps but some work some do not
[22:24] <popey> what you get in /usr/share/preinstalled comes with the read-only image
[22:24] <taiebot> music is in there? i thought i desinstalled it?
[22:24] <popey> what you get in /opt is what comes from the store
[22:25] <popey> you probably had 369 in /opt from a previous install from the store
[22:25] <popey> then updated to 250 which brought in the new one in preinstalled
[22:25] <taiebot> can i delete this file and it should reupdate it then?
[22:26] <popey> delete what file?
[22:27] <taiebot> com.ubuntu.music in /opt/click.ubuntu.com
[22:27] <Tassadar> but the click update app was saying there is an update available, after I upgraded to 250, so I clicked "update", it completed successfully, it shows no more updates, but the clock app is broken
[22:27] <popey> i wouldn't manually futz with files
[22:27] <popey> yes, it shows no more updates because you have latest in usr
[22:28] <Tassadar> why did it show an update when I had it in there already?
[22:28] <popey> i dont understand the question
[22:28] <popey> bear with me...
[22:29] <Tassadar> it showed the update is available _after_ I installed image 250
[22:29] <popey> oh.. really?
[22:29] <Tassadar> yeah
[22:31] <Tassadar> maybe it was caching something from the previous image? Like, there is a "check again" button after you install all updates, so I suppose the checks are initiated only at certain moments..?
[22:33] <popey> not so sure
[22:34] <Tassadar> anyway, I'm sorry, but I'm gonna head to bed - it's gonna be midnight here soon. Do you want me to get you some more logs before I leave?
[22:41] <popey> Tassadar: no, I'll investigate more
[22:41] <robert1_> same problem here, after i update to r237 (14.04), the terminal-app doesnt work, after uninstall, i cant find it for reinstallation. after i install (downgrade) to rev236, in the update-manager-app i get "Command Error" for some apps.
[22:41] <popey> Tassadar: feel free to ping over the weekend
[22:41] <Tassadar> k, thanks & gn
[22:42] <popey> robert1_: update to 250
[22:42] <robert1_> popey, ok, i will try, thanks
[22:43] <jonahbron> Does anyone know the status of the desktop HUD working with a QML app?
[23:06] <robert1_> popey, rev250 is installed, but not the terminal-app, in storage i see 2 entries "Terminal", 436.2kB&461.8kB.
[23:26] <robert1_> in /opt/click.ubuntu.com/, i have a folder, com.ubuntu.terminal with files from 28.02.2014
[23:30] <robert1_> in /usr/share/click/preinstalled/com.ubuntu.terminal, i have files from 21.03.2014 (0.5.44)
[23:31] <robert1_> in /opt/click.ubuntu.com version 0.5.40