[03:27] <FuLgOrE> rsalveti: because ogra is not here, do you know about the changes regarding mounting /persist in the new 4.4er images? It's not working, maybe we can have a look
[03:28] <FuLgOrE> also brightness control doesn't work
[04:59] <Mirv> chrisccoulson: see the specific instructions I posted on ubuntu-phone
[04:59] <Mirv> chrisccoulson: the touch multimedia fork packages don't clean themselves up, that's why
[05:21] <Mirv> (or https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2 front page)
[06:51] <danny> will it be possible to run ubunto desktop apps on ubunto tablets?
[06:53] <danny222112> is it possible to run desktop apps on ubunto tablets?
[07:02] <tvoss> pitti, good morning :)
[07:02] <pitti> hey tvoss, how are you?
[07:02] <tvoss> pitti, pretty good, thank you :) travel was unevent-ful
[07:03] <tvoss> pitti, how are you?
[07:03] <pitti> tvoss: oh, you are already in London?
[07:03] <tvoss> pitti, oh, I spent Monday to Wednesday in London, now back home and in Brussels on Saturday
[07:04] <pitti> tvoss: ah, see you at FOSDEM then?
[07:04] <tvoss> pitti, I would think so :)
[07:04] <tvoss> pitti, when is your talk?
[07:05] <pitti> tvoss: I don't have any; I'm primarily going there to meet a few people again, I didn't really prepare much
[07:05] <pitti> tvoss: going there on my own dime and staying at a friend's in Leuven
[07:05] <tvoss> pitti, ah, now that's cool :)
[07:33] <dholbach> good morning
[07:44]  * FuLgOrE is available for testing on hammerhead
[08:07] <infinity__> need to know can i install ubuntu on my samsung galaxy note??
[08:08] <infinity__> is it stable can any one guide about this
[08:21] <pitti> lool: bonjour
[08:45] <M4dH4TT3r> support mips
[08:53] <pitti> xnox: hey Dimitry, already awake?
[08:58] <xnox> pitti: morning! Yes =) we are all in the office.
[08:58] <xnox> pitti: what's up? unless you are after ftpmaster.internal...
[08:58] <pitti> xnox: ah; good morning; I might have a question about your recent cmake upload, but need to verify something first
[08:59] <pitti> recently, "export CXX=g++-4.7" in debian/rules stopped working
[08:59] <pitti> which is why platform-api is now 'orribly broken
[08:59]  * pitti downgrades to previous cmake to verify
[09:00] <xnox> pitti: yeah, my cmake changes do not work with CXX=g++-4.7 =/
[09:00] <pitti> so, what I don't understand:
[09:00] <xnox> pitti: you can do -DCMAKE_C_COMPILER=gcc-4.7 -DCMAKE_CXX_COMPILER=g++-4.7
[09:00] <xnox> pitti: at the dh_auto_configure call, and that should work.
[09:00] <pitti> mkdir obj; cd obj; CXX=g++-4.7 cmake ..
[09:00] <pitti> that works
[09:00] <pitti> but above export doesn't (through dh_auto_configure)
[09:01] <xnox> pitti: right, my "crazy" patch-sets keys on variables exported by dpkg-architecture
[09:01] <pitti> argh
[09:01] <pitti> is that backwards compatible?
[09:01] <xnox> pitti: so CXX=g++-4.7 dpkg-architecture -aamd64 -c cmake => is probably broken at the moment.
[09:01] <j-b> 'morning
[09:02] <xnox> pitti: it's not backwards compatible with some existing debian/rules files, indeed.
[09:02] <pitti> xnox: I mean the -D syntax
[09:02] <xnox> pitti: why is platform-api using 4.7? to match hybris / android.
[09:02] <pitti> yes, 4.8 changed the float return ABI
[09:02] <xnox> pitti: -D is the standard cmake interface to provide configuration variables since forever.
[09:02] <pitti> it's apparenlty planned to change that soon, but it hasn't happened yet
[09:02] <pitti> xnox: yes, but export CXX has been the standard way for pakcages to set the compiler :)
[09:03] <pitti> xnox: anyway, that works for now; thanks
[09:03] <pitti> xnox: I take it  that is to be considered a workaround?
[09:03] <xnox> pitti: yeah, i guess i should invest into fixing / supporting $ENV{CXX}
[09:04] <pitti> at least we have something that unblocks that now
[09:04] <pitti> wow, that kept some four or five people busy for some hours :0
[09:04] <xnox> pitti: do you have more details about the "4.8 changed the float return ABI"? first time i hear about it.
[09:05] <pitti> xnox: I'm only parrotting, I'm afraid
[09:05] <xnox> pitti: well.... CMAKE_C_COMPILER / CMAKE_CXX_COMPILER are the _cmake standard_ way of setting compilers.... ;-)
[09:05] <pitti> xnox: but the effect is, if I build platform-api with 4.8 (which is what happened without us noticing), float return values are absolutely wrong
[09:05] <pitti> $ ./showsensors
[09:05] <pitti> accel: min 0 max 39.2266 res 0.00119019
[09:05] <pitti> ^ with current platform-api in trusty
[09:06] <pitti> accel: min 3.56854e+21 max 2.82612e+20 res 2.82612e+20
[09:06] <pitti> ^ with rebuilt platform-api (no change)
[09:06] <pitti> fortunately that has been caught by its new tests
[09:09] <pitti> didrocks: found it!
[09:09] <pitti> didrocks: err, "bonjour"
[09:09] <didrocks> pitti: \o/
[09:10] <didrocks> pitti: do you have a bug for it? I'm interested in the diff anyway
[09:10] <pitti> didrocks: and never again blame my tests! :-)
[09:10]  * didrocks hugs pitti
[09:10] <didrocks> I didn't blame your tests :p
[09:10] <pitti> didrocks: (just kidding)
[09:10] <pitti> didrocks: filing one now
[09:10] <pitti> didrocks: diff: http://paste.ubuntu.com/6842713/
[09:10] <pitti> didrocks: tvoss is applying it to his MP directly
[09:11]  * didrocks looks
[09:11] <pitti> didrocks: we were building with g++-4.8 without noticing
[09:11] <didrocks> perfect!
[09:11] <didrocks> oh
[09:11] <pitti> didrocks: I wrote a little test program that shows the actual (real iron) sensor data, and it was broken just the same way
[09:11] <pitti> didrocks: i. e. the tests were exactly right
[09:13] <didrocks> pitti: waow, it was an interesting… side-effect
[09:13] <didrocks> pitti: we are trying to release Mir, including platform-api
[09:13] <didrocks> I would appreciate a separate MP that we can bundle with the current rebuilds
[09:13] <didrocks> (if possible)
[09:14] <pitti> didrocks: but it won't build
[09:15] <didrocks> pitti: oh?
[09:15] <pitti> didrocks: as we don't have the previous dbus-cpp any more
[09:15] <pitti> didrocks: so we actually need to land
[09:15] <M4dH4TT3r> support mips
[09:15] <pitti> https://code.launchpad.net/%7Ethomas-voss/location-service/add_controller_and_service_configuration/+merge/199105
[09:15] <cyphermox> ChickenCutlass: https://code.launchpad.net/+branch/~mathieu-tl/+junk/nm-mms-support
[09:15] <didrocks> pitti: hum, it did build yesterday on the branch we sil2100 bundled ^
[09:15] <M4dH4TT3r> and gay marrige
[09:15] <didrocks> maybe this branch was part of the request
[09:15] <pitti> and https://code.launchpad.net/~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform/+merge/203298
[09:15] <pitti> didrocks: yes, that's what sil2100 told me
[09:15] <pitti> didrocks: hence tvoss will add the workaroud to the latter MP
[09:15] <tvoss> pitti, didrocks https://code.launchpad.net/~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform is updated
[09:15] <sil2100> pitti, didrocks: all was fine in our PPA, right?
[09:16] <sil2100> pitti: is the platform-api test issue fixed?
[09:16] <sil2100> :)
[09:16] <pitti> sil2100: yes
[09:16] <didrocks> sil2100: can you backlog first? :p
[09:16] <pitti> sil2100: http://bazaar.launchpad.net/~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform/revision/188 is the fix, tvoss just committed it
[09:16] <sil2100> \o/
[09:16] <pitti> sil2100: ugh, that was really confusing
[09:16] <didrocks> sil2100: apparently, it will fail to build though without tvoss's branch (what you didn't get in the ppa yesterday)
[09:16] <sil2100> Ok, so let me spin things!
[09:16] <pitti> sil2100: my tests showed a real problem \o/ :)
[09:16] <didrocks> pitti: nice catch btw, yeah, more than confusing :p
[09:17] <sil2100> didrocks: no proooblem, it's all under control
[09:17] <tvoss> pitti, didrocks we should file a bug against the cmake package in distro, too
[09:17] <sil2100> pitti, tvoss: just give me a moment and it will be all fine
[09:17] <pitti> tvoss, didrocks, sil2100, xnox : bug 1274430
[09:17] <M4dH4TT3r> really want ubuntu touch on my tablet
[09:17] <pitti> sil2100: let's please wait on the jenkins CI run on tvoss's updated branch, just to make sure?
[09:17] <xnox> pitti: i'll take it.
[09:17] <M4dH4TT3r> mips architecture
[09:18] <pitti> xnox: thanks
[09:18] <pitti> sil2100: but you can land https://code.launchpad.net/~thomas-voss/location-service/add_controller_and_service_configuration/+merge/199105 in the meantime, I guess
[09:21] <didrocks> pitti: I didn't know sil2100 already bundled tvoss's branch
[09:21] <didrocks> so now I understand :)
[09:21] <xnox> pitti: which package should I test my fix on?
[09:21] <didrocks> thanks again pitti! and well done :)
[09:21] <sil2100> pitti: all stuff will be bundled together, as one big coherent landing - no worries, it's *all* under control ;p
[09:21] <sil2100> pitti: thanks for fixing!
[09:22] <pitti> xnox: you can use current platform-api and check the cmake output; it should say "using g++4.7", not 4.8
[09:22] <xnox>  cool, thanks
[09:23] <pitti> -- The CXX compiler identification is GNU 4.8.2
[09:23] <pitti> xnox: ^ it currently says that
[09:23] <pitti> xnox: beware that current platform-api typoes "export C=gcc-4.7", should be "CC"
[09:24] <pitti> xnox: that's fixed in the MP, but you shold fix it locally to test your fix for CC too
[09:24] <pitti> sil2100: great
[09:24] <xnox> -- Check for working C compiler: /usr/bin/x86_64-linux-gnu-gcc -- works
[09:24] <xnox> -- Check for working CXX compiler: /usr/bin/g++-4.7 -- works
[09:24] <xnox> pitti: ^^^^
[09:25] <xnox> pitti: is that what you'd expect?
[09:25] <pitti> xnox: nice! and with C fixed to CC?
[09:25] <ogra_> rsalveti, bug 1160847
[09:26] <xnox> pitti: well, if CC or CXX or FC are in the environment, the will be honored.
[09:26] <pitti> xnox: right, that already worked
[09:27] <pitti> xnox: but for some reason not if debian/rules passes it through dh_auto_configure
[09:27] <xnox> pitti: that did not work, when running debuild.
[09:27] <xnox> =)
[09:27] <xnox> now it will again.
[09:27] <pitti> xnox: cheers, thanks for the fast fix!
[09:28] <pitti> xnox: not urgent any more for platform-api now, but I don't know know how many other packages use that
[09:28] <xnox> pitti: true.
[09:36] <tvoss> pitti, rsalveti pointed out that forcing gcc-4.7 might break cross build
[09:36] <tvoss> xnox, ^
[09:36] <pitti> tvoss: well, we don't even use gcc in platform-api, but we already force g++-4.7
[09:37] <xnox> tvoss: yes, it will. I can provide a patch to platform-api to do it properly.
[09:39] <xnox> tvoss: if one exports compiler, one should export compiler as $DEB_HOST_MULTIARCH-gcc-4.7 to be cross-compile safe.
[09:40] <cyphermox> ChickenCutlass: sbuild -d trusty -A --arch=armhf network-manager_0.9.8.8-0ubuntu2~mtrudel2.dsc
[09:42] <mardy> mzanetti, dpm: OK, so using the Evernote QML plugin I manage to get the username in the account plugin
[09:42] <mzanetti> mardy: \o/
[09:42] <dpm> excellent
[09:42] <mardy> mzanetti, dpm: is if OK if I file a merge proposal to merge the account plugin into the reminders app?
[09:43] <dpm> mardy, +100 (althouth I'd like to hear mzanetti's opinion)
[09:44] <cyphermox> ChickenCutlass: mk-sbuild trusty --arch=armhf
[09:44] <mzanetti> dpm: mardy: add another 100 :)
[09:44] <mardy> dpm, mzanetti: actually, I'm not sure how this would work with click; can we generate two click packages from the same repository?
[09:44] <mzanetti> mardy: thanks a lot. You're helping alot
[09:44] <mzanetti> mardy: yeah, we can
[09:44] <mardy> mzanetti: glad to be of help :-)
[09:45] <mzanetti> mardy: but: can we install account plugins through clicks already?
[09:45] <dpm> mardy, but we still can't run online account plugins off click, right? Wouldn't we build a debian package instead?
[09:45] <mzanetti> mardy: I thought that stuff still needs to be seeded with deb's
[09:45] <dpm> yeah, my thoughts too
[09:46] <mardy> mzanetti, dpm: right, currently we don't support having account plugins in click packages, but that will change soon
[09:46] <dpm> mardy, ack. Depending on how soon, we might still need to build a .deb package during the transition
[09:46] <mardy> mzanetti, dpm: however, you are right, it's probably better to wait for that to land, before merging the plugin
[09:46] <mzanetti> mardy: so given that click packages don't have any build recipe, we can do whatever we want
[09:46] <dpm> yeah
[09:47] <mzanetti> mardy: no... we can generate 2 debs from the repo too
[09:47] <mzanetti> please go ahead
[09:47] <mzanetti> mardy: just one thing: Check out the CMakeLists and in CLICK_MODE add install steps to install all of the plugins stuff to a separete new directory
[09:48] <mzanetti> then we can just add a second click create command for the second dir and we're good to go
[09:48] <mzanetti> right now we're also building .debs out of the app too
[09:48] <mzanetti> so everything is in place already
[09:50] <mardy> mzanetti: so, when the project is built as a deb, we should build: qtdeclarative-evernote-module, account-plugin-evernote and reminders app (with the latter to depending on the first). Correct?
[09:51] <mardy> mzanetti: when it's built as click packages, the qtdeclarative-evernote-module should be embedded in both the account plugin and reminders app
[09:51] <mzanetti> mardy: I for one wouldn't install the plugin as a module tbh
[09:51] <mzanetti> even with debs
[09:52] <tvoss> xnox, ack and thanks
[09:52] <mzanetti> mardy: hmm... well... given the fact we're sharing it between the plugin and the app... ok...
[09:52] <mardy> mzanetti: I'm not sure how we can install it in two debs... I guess I'll have to play with cmake a bit (I don't know cmake)
[09:53] <mzanetti> mardy: imo we should install it in the app/plugins data dir and set qml's import path to it
[09:53] <mzanetti> mardy: let me know if you need help with cmake
[09:54] <ChickenCutlass> cyphermox, http://pastebin.ubuntu.com/6842903/
[09:57] <barry> xnox: https://code.launchpad.net/~chris.gagnon/ubuntu-ui-toolkit/autopilot-python3-package/+merge/196358
[10:08] <tvoss> xnox, I think that it would make sense to fold the fix into https://code.launchpad.net/~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform
[10:11] <barry> xnox: https://code.launchpad.net/~chris.gagnon/ubuntu-ui-toolkit/autopilot-python3-package/+merge/196358/comments/476068
[10:23] <pitti> kalikiana, tvoss: I analyzed the crash in bug 1272294 and followed up with two possible solutions for fixing platform-api; do you have a particular preference, or should I just go with what I think is best?
[10:32] <mzanetti> dpm: hey, I think sergiusens is fine with that branch. I didn't change his stuff a lot anyways. can we get it landed?
[10:32] <mzanetti> the cleanup one, that is
[10:32] <xnox> fginther: what's up?
[10:33] <xnox> ogra_: what's up?
[10:33] <dpm> mzanetti, sounds good to me. I can top-approve if you want
[10:33] <mzanetti> dpm: please
[10:33] <ogra_> xnox, we need to move around the developer mode meeting
[10:33] <dpm> mzanetti, done
[10:34] <xnox> ogra_: =/
[10:34] <xnox> ogra_: sorry.
[10:35] <ogra_> xnox, looks like many people have conflicts today ... would tomorrow at the same time work for you ?
[10:37] <xnox> ogra_: i only had this meeting on the Ubuntu Core calendar.
[10:37] <xnox> ogra_: if you want me to be somewhere, it should be on the Ubuntu Core calendar =/ maybe ask michelle about it?
[10:38] <ogra_> xnox, moved to tomorrow, same time now
[10:38] <Laney> might come say hi at the office tomorrow
[10:38] <Laney> if i can get in early enough on my "super off peak"
[10:38] <ogra_> Laney, DOIT !
[10:38] <xnox> ogra_: today at 4:30 -> 6 ?
[10:38] <ogra_> xnox, bah, paperwork
[10:38] <Laney> eurostar to brussels is at ~1530
[10:38] <xnox> ogra_: tomorrow at 11 is free so far.
[10:39] <mardy> mzanetti: OK, question time (cmake): I need to define a couple of string variables in debian/rules (for the OAuth application key/secret), and make the available to cmake (which will use them in a configure_file)
[10:39] <ogra_> xnox, perfect
[10:39] <mardy> mzanetti: is it just -DVARIABLE="xxx"?
[10:40] <mzanetti> mardy: yeah, can do that
[10:40] <mardy> mzanetti: OK. By the way, I'm currently working on making the account plugin as a deb; I'll worry about the click build only once we actually support it
[10:41] <mzanetti> mardy: ok. I guess I can take care about the click too at some point. no worries about that
[10:41] <mzanetti> mardy: make sure everything builds fine when calling cmake with -DCLICK_MODE=1
[10:42] <Laney> could get there for 12ish
[10:46] <tvoss> pitti, looking at 1272294
[10:47] <tvoss> pitti, I would prefer the explicit call to check if a backend is available. I would like to keep the inner workings of IMPLEMENT_FUNCTION0 an implementation detail
[10:47] <tvoss> greyback, hey there
[10:47] <pitti> tvoss: you mean don't interpret a NULL return value as error?
[10:47] <greyback> tvoss: yo, just saw your reply to the MR
[10:47] <pitti> tvoss: still a bit sad that ua_sensors_accelerometer_new() just crashes then on platforms that don't have sensors
[10:48] <pitti> tvoss: well, we could at least make it an assertion then?
[10:48] <mardy> mzanetti: should I just re-approve this? https://code.launchpad.net/~mardy/reminders-app/register-error/+merge/203900
[10:48] <tvoss> pitti, sure, I would think that we could make _new() a bit more robust and don't use the macro to implement it
[10:49] <pitti> tvoss: that would copy&paste a lot of code
[10:49] <mzanetti> mardy: I will take care of it... the cleanup branch needs to land first
[10:49] <tvoss> pitti, sure, but you cannot always return NULL for IMPLEMENT_FUNCTION0 as it depends on the return type
[10:49] <pitti> tvoss: I'd actually think we should make a new macro like IMPLEMENT_FUNCTION0_NULLERR or so?
[10:50] <tvoss> pitti, that makes sense
[10:50] <pitti> tvoss: i. e. a new macro that we use for the constructors
[10:50] <pitti> tvoss: or just straight IMPLEMENT_CONSTRUCTOR0 (0 for zero args)?
[10:50] <tvoss> pitti, exactly, and consumers of the API have to check for errors
[10:50] <pitti> tvoss: right; but we currently define error as "returns NULL"
[10:50] <tvoss> pitti, I think an explicit CTOR macro is self-explaining
[10:51] <pitti> tvoss: ack, doing that then; thanks!
[10:51] <tvoss> pitti, yup :) thanks for the help
[10:51] <pitti> tvoss: yeah, that's indeed a bit annoying; it immediately crashes QtCreator on a desktop, which is a bit sad for app development
[10:52] <tvoss> yup
[10:54] <mardy> mzanetti: I cannot see how the icon is getting installed; is ICON a magic variable?
[10:55] <dpm> mzanetti, would you have some time today to create a click package from the latest branch of reminders and send it to Dani? I'm not sure if popey or I would manage today, and that would help Dani playing with the latest changes
[10:57] <mardy> mzanetti: forget it, I think I found how it works (installs it with SRC_FILES) ^
[11:01] <mzanetti> re
[11:02] <mzanetti> mardy: ok. let me know if there are any more things
[11:02] <mzanetti> dpm: ok
[11:03] <dpm> mzanetti, great, thanks. I'll then tell Dani to find someone in the office to help him install it from the command line
[11:03] <mzanetti> vesar: can you? ^
[11:08] <ogra_> FuLgOrE, so there is still an issue with the package publishing ... the /persist mount should be in the new zip i just published, powerd (brightness stuff) still is not
[11:08] <FuLgOrE> ok I see
[11:08] <FuLgOrE> thx, I will download and try immediately :)
[11:10] <ogra_> FuLgOrE, argh, seems i'm wrong, the persist stuff didnt make it either
[11:11] <vesar> mzanetti, sure I can
[11:11] <FuLgOrE> anything else to test?
[11:13] <mzanetti> dpm: however, the camera branch and the reminders branch are not reviewed yet
[11:13] <mzanetti> WebbyIT: hey ho! You can now go ahead and approve the textformat branch
[11:14] <FuLgOrE> ogra_: should I try something else on hammerhead?
[11:14] <WebbyIT> mzanetti, \o/
[11:15] <ogra_> FuLgOrE, well, the new zip has no changes at all ... we need to wait til the infrastructure is fixed
[11:15] <WebbyIT> mzanetti, last night I thinked about RTF format: well, there are much case I had not considered in first place, in next days I'll update you
[11:15] <ogra_> i'll do a rebuild as soon as that happened ... but i dont know when that will be
[11:15] <ogra_> (zip build takes ~70 min)
[11:16] <FuLgOrE> ogra_: okay, than I keep the "old" image on my phone
[11:16] <mzanetti> WebbyIT: yep, I guess there are a ton of corner cases, however, I guess we'll always hit them... writing a WYSIWYG editor is a tricky task
[11:17] <FuLgOrE> I guess we cannot do that on my hardware, right?
[11:18] <dpm> mzanetti, I think it's fine to pass him the camera and reminders branch, if it's just to test the UX. At least the camera branch was working for me the first time you submitted it, and for the latest changes perhaps we can actually have Dani as a tester :)
[11:18] <WebbyIT> mzanetti, Jenkins is not happy about your branch. If I top approve it, will tests run again?
[11:19] <dpm> mzanetti, but if you feel you shouldn't put them in the .click package, it's your call
[11:19] <mzanetti> WebbyIT: yes. if you want we can trigger ci first
[11:19] <mzanetti> dpm: no, its fine
[11:19] <WebbyIT> mzanetti, np, I top approve it
[11:19] <dpm> ok, cool
[11:29] <mzanetti> WebbyIT: hey, can you create a merge which reverts your fix again please?
[11:29] <mzanetti> WebbyIT: given that the bug it fixes is less bad than the bug it introduces :)
[11:30] <WebbyIT> mzanetti, yes, sure
[11:30] <mzanetti> thanks
[11:30] <mzanetti> I'd say we just get rid of the back button in the edit note and make the user always go through save, just like evernote itself does
[11:30] <mzanetti> dpm: ^
[11:35] <WebbyIT> mzanetti, https://code.launchpad.net/~rpadovani/reminders-app/revert-1273102/+merge/203926
[11:45] <mzanetti> WebbyIT: dpm: https://bugs.launchpad.net/reminders-app/+bug/1273102/comments/2
[11:45] <WebbyIT> mzanetti, I think it's a good idea to align our app to evernote one
[11:54] <pitti> tvoss: ok, working nicely now; I attached MP/patch, but it's blocked by landing your platform-api branch first
[11:54] <tvoss> pitti, ack
[11:55] <tvoss> sil2100, any update?
[11:55] <pitti> (no hurry from my side, that's just an FYI or if you have a minute to pre-review)
[11:56] <sil2100> tvoss: so... platform-api built fine in the slot PPA, but I'm waiting for mir armhf to finish
[11:56] <tvoss> sil2100, ack
[11:56] <sil2100> tvoss: the unit tests for this platform take really long, I wonder if it's supposed to be like that
[11:59] <popey> sergiusens: http://paste.ubuntu.com/6843404/ - what am I doing wrong here? trying to get a really old image from my mirror...
[12:00] <sergiusens> popey, use ubuntu-device-flash ;-)
[12:00] <pitti> sil2100: no, unit tests for platform-api are supposed to take < 2 seconds really
[12:01] <pitti> sil2100: I just built it a few times on my nexus 4, for above bug
[12:01] <tvoss> pitti, I think sil2100 refers to the mir tests
[12:01] <pitti> ah sorry
[12:01]  * pitti STFU
[12:01] <sergiusens> popey, I'm not sure tbh; let me look
[12:01] <tvoss> sil2100, not sure about testing time tbh
[12:02] <tvoss> sil2100, they certainly take some time but they shouldn't run fo rages
[12:02] <popey> sergiusens: alan@deep-thought:~$ ubuntu-device-flash -channel="trusty-proposed" -revision=45 -server="http://popey.mooo.com/mirror/system-image.ubuntu.com"
[12:02] <popey> 2014/01/30 12:02:07 Device is |mako|
[12:02] <popey> 2014/01/30 12:02:09 Failed to locate image 4
[12:02] <popey> there's a 5 there, but I mis-copied
[12:05] <sil2100> ;/
[12:06] <sergiusens> popey, you don't have Version: "45" in devel-proposed
[12:06] <popey> oh doh, it's in trusty-proposed
[12:06] <popey> thanks
[12:07] <popey> but thats what I specified
[12:07] <popey> sergiusens: and I do.. http://popey.mooo.com/mirror/system-image.ubuntu.com/devel-proposed/mako/ has version-45 in it
[12:08] <sergiusens> popey, what's important is what's in http://popey.mooo.com/mirror/system-image.ubuntu.com/trusty-proposed/mako/index.json
[12:08] <sergiusens> popey, that file itself isn't
[12:09] <popey> bah
[12:09] <popey> can I manually pull the files?
[12:09] <Piotrek_> hi, how much does ubuntu touch uses disk pace? I have nexus 4 and I'm wondering about cyagenomod dual boot with ubuntu touch
[12:18] <ogra_> Piotrek_, 2-3G
[12:19] <Piotrek_> ogra thanks
[12:29] <ogra_> FuLgOrE, looks like the archive is fine again, i started a zip build (in ~70min i should have a new zip ready)
[12:29] <lool> pitti: did you ping?  sorry didn't open IRC this morning!  :-/
[12:29] <FuLgOrE> ogra_: that sounds good! thx
[12:30] <lool> also, my rented server is unstable since yesterday, I might have missed messages yesterday
[12:35] <davmor2> popey, ogra_, sil2100: I'm on holiday and what do you do you break my n4 ;)  have you moved over to the 4.4.2 android base?
[12:36] <ogra_> davmor2, nope, thats still days away
[12:36] <ogra_> davmor2, in fact due to the archive issues we had no changes at all for the last few images
[12:37] <davmor2> ogra_: in that case there might be an issue updated today 29.7mb iirc and now my phone doesn't pass the google logo
[12:38] <davmor2> ogra_: I'll try a full fresh flash and see if that fixes it then
[12:40] <popey> sergiusens: so if I want to manually install http://popey.mooo.com/mirror/cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20131202/ that on my mako, can I still do that via the instructions at https://wiki.ubuntu.com/Touch/Install#Manual_Download_.26_Installation ?
[12:43] <pitti> lool: it's all good now, the platform-api issue is fixed
[12:46]  * popey tries
[12:47] <mardy> mzanetti: are you using Qt 5.2 in your machine?
[12:47] <mzanetti> mardy: no
[12:48] <mardy> mzanetti: cool. I'll now push my branch somewhere, would be very glad if you tried it; for some reason the reminders-app does not display the account displayName (even though it's there), and I'd be curious to know if this is because of me using Qt 5.2
[12:49] <mardy> mzanetti: or if it's really a bug in my accounts-qml-module
[12:49] <mzanetti> mardy: very unlikely because of 5.2
[12:49] <mardy> mzanetti: agreed; but it's very strange, the data() method in my QAbstractListModel isn't even called
[12:50] <mzanetti> mardy: I'm in the middle of something I'd like to finish first. will try a bit later
[12:52] <roman2861> What about 4.4.2 source code?
[12:57] <mardy> mzanetti: no hurry, I'll investigate
[12:57] <mardy> mzanetti, dpm: meanwhile, I just pushed the MR which brings in the account plugin (which correctly fetches the username)
[12:58] <mzanetti> mardy: cheers
[12:59] <dpm> awesome, thanks mardy. Are you still planning to add the trusted helper once that one gets merged?
[13:00] <mardy> dpm: sure
[13:01] <mardy> dpm: but that will need some coordination, because the trusted helper needs to land at the same time
[13:02] <dpm> mardy, yeah, good point. What's the landing plan for the trusted helper?
[13:04] <mardy> dpm: land as soon as the needed changes to reminders-app and friends-app have been approved :-)
[13:04] <dpm> mardy, that sounds like a great plan to me :)
[13:04] <dpm> mardy, note that reminders-app is not yet in the image, so while coordination is still needed, we're a bit more flexible.
[13:05] <dpm> so it's essentially up to the friends-app changes
[13:06] <davmor2> ogra_: fresh flash of 154 and it's still dead
[13:07] <mardy> dpm: ah, good to know
[13:14] <sergiusens> popey, you need to create an ubuntu_commands file
[13:15] <davmor2> ogra_: I'm flashing 152 now
[13:16] <sergiusens> popey, you can either do a normal flash and get that from where it's logged or you can look at https://wiki.ubuntu.com/ImageBasedUpgrades/Upgrader and follow that
[13:19] <popey> sergiusens: ok
[13:19] <popey> davmor2: 153 is good, 154 is bad
[13:19] <popey> see mailing list
[13:26] <davmor2> popey: cool thanks
[13:47] <FuLgOrE> ogra_: how is the status of your zip?
[13:48] <ogra_> FuLgOrE, my zip has the same issues as image 154 (see the mailing lists)
[13:49] <FuLgOrE> what a pitty
[13:50] <FuLgOrE> is it possible to take your zip and apt-get install libunity-mir1?
[13:53] <ogra_> FuLgOrE, it would be, but i dont really want to publish it like that (there might be people using it that arent as smart as you) ... i'll do a re-build as soon as didrocks and ricmm have uploaded the fix
[14:33] <nirmal> hi
[14:33] <nirmal> i woul like to install ubuntu touch in my Xolo Q800
[14:34] <nirmal> plz help me
[14:34] <nirmal> it has got Arm v7 quad core mediatech processor
[14:51] <elopio> ping barry: still having problems with the toolkit?
[14:51] <barry> elopio: yes, but now my stack is pushed down a few :)
[14:52] <elopio> barry: I asked them yesterday about your error, and they told me kalikiana might know more about it.
[14:52] <barry> elopio: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1274434
[14:52] <elopio> oh, nice.
[14:53] <elopio> barry: and changing the subject, when is a good date for your py2-3 lightning talk for the QA team?
[14:54] <barry> elopio: yeah, good question!  mid feb?
[14:55] <kalikiana> elopio: what error?
[14:55] <elopio> barry: we are sprinting the week of the 17th. So either the week before, or after that, would be perfect.
[14:55] <elopio> kalikiana: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1274434
[14:56] <barry> elopio: let's do the week after, the week before is too busy
[14:56] <barry> elopio: mon, tue, wed are all clear
[14:56] <barry> (feb 24,25,26)
[14:56] <kalikiana> elopio: actually I have a question for you: can autopilot verify if the screen is unlocked? https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1259476 was re-opened and I can only reproduce by locking the screen, so I got the idea this would be good to excluse as a non-cause
[14:58] <elopio> barry: ok, lets try wed 26. And 20:30 UTC is a good hour for you? I have no idea what are your working hours, I always find you at a different time.
[14:58] <elopio> kalikiana: you can if you restart unity with testability enabled.
[14:58] <kalikiana> elopio: is that something we can enable in our ci?
[14:59] <barry> elopio: :)
[14:59] <elopio> for my point of view, the toolkit tests should be as independent as possible, so I would prefer if we disable the greeter. But that's a bigger discussion.
[14:59] <barry> elopio: i'll be utc-5 then, so 20:30 is good (if i'm doing my utc math correctly :)
[15:00] <elopio> kalikiana: do you just want to give it a try to get debug information, or would you like to check that always?
[15:01] <elopio> alesage: wed 26th, 20:30 UTC, sounds good for you for the cobertura lightning talk?
[15:01] <alesage> elopio sure that'll be fine
[15:02] <alesage> elopio, thanks for the advance warning
[15:02] <kalikiana> elopio: I have no clue what causes the failure this time except on my device if I lock it. so knowing if that was the reason on Jenkins would narrow it down
[15:02] <elopio> alesage, barry: then we are all set. Thanks :)
[15:02] <barry> elopio: awesome
[15:02] <kalikiana> elopio: the earlier bug was resolved, but we never actually determined if it failed for the reason it was reproducible manually
[15:03] <kalikiana> except it was the exact same result
[15:03] <kalikiana> but now we have the same result again despite the fix
[15:03] <kalikiana> I hope this isn't too confusing
[15:03] <elopio> kalikiana: no, it is not, I'm just thinking.
[15:04] <elopio> kalikiana: so, if you look the device, it will fail because the field doesn't have the focus. You type, and the text goes somewhere else.
[15:04] <elopio> s/look/lock
[15:04] <kalikiana> yes
[15:05] <elopio> kalikiana: so, what if we just add a self.focus.wait_for(True) before righting on the textifield?
[15:05] <elopio> ahh, sorry
[15:05] <elopio> writing
[15:05] <elopio> :) I woke up too early today.
[15:05] <kalikiana> elopio: then it can still fail in the middle of that and we don't know why
[15:05] <kalikiana> and in one mr that indeed was what happened
[15:06] <kalikiana> so you get "foob" != "foobar"
[15:07] <elopio> kalikiana: it will discard the case that we just wrote too fast, before the text field was finishing getting the focus.
[15:07] <elopio> hum, that foob instead of foobar is a pretty different case from est instead of Test, or the empty string.
[15:07] <kalikiana> I don't get that, wrote too fast?
[15:07] <elopio> kalikiana: the thing is that there's no reason for the screen to lock while executing this test. Because you are constantly interacting with the device.
[15:08] <elopio> it's never idle, so it shouldn't look during the execution.
[15:08] <kalikiana> I don't have exact log for the mr which was in the middle of it, but it clearly was losing focus while typing letters
[15:09] <kalikiana> elopio: well, that is a fair assumption. I'm aware that short of any clue what really happens all of this is to narrow down what's left
[15:10] <elopio> kalikiana: I agree. We could just run the command that disables the lock screen on an MP to see if it keeps happening.
[15:10] <elopio> how often do you see this error?
[15:10] <kalikiana> often enough to be very annoying
[15:11] <elopio> ok, then if we rerun the suite on jenkins some times without the lock screen, it should give us better information.
[15:11] <elopio> now I don't remember who told me about how to disable the lock screen.
[15:12] <elopio> Saviq: do you know?
[15:12] <Saviq> elopio, lock screen or suspend?
[15:12] <Saviq> elopio, powerd-cli display bright on
[15:12] <Saviq> elopio, as root
[15:12] <elopio> that's it. oh, but as root. hum...
[15:12] <kalikiana> elopio: we did have plenty of lock screen related issues at some point in the past, that's why I wouldn't just assume it just works
[15:13] <kalikiana> same reason I wanted details on the osk in the logs
[15:14] <elopio> it's so bad that we can't get a screenshot from the phone.
[15:14] <kalikiana> despite the bug fix we get the exact same failures
[15:19] <elopio> kalikiana: for collecting debug information, we can ask CI to set up a job for us that starts killing unity, so we can start it with testability on the test and introspect it. Or that starts with suspend disabled.
[15:20] <elopio> kalikiana: but can we first try the focused.wait_for(True) ?
[15:23] <kalikiana> elopio: well, we can add it to the emulator, it doesn't hurt
[15:25] <tedg> sergiusens, This is a bug that is collecting all the bad icon errors in click packages bug 1267884
[15:25] <tedg> sergiusens, UAL doesn't seem the right place for it to be, is there a better one?
[15:25] <nxvl> hi, has someone tried to install Ubuntu Touch on a tablet?
[15:26] <nxvl> i have a Galaxy Tab (GT-P1010) which i can use to test
[15:26] <sergiusens> tedg, if it's the icons for preinstalled, they all have bug reporting enabled in launchpad
[15:26] <nxvl> or it's focused on Phone and Tablet are not looked for yet?
[15:27] <elopio> kalikiana: I piggybacked it here: https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1274240-gallery-textfield_helper/+merge/203831
[15:27] <elopio> what I hope with that branch is to get a clearer trace in case of error.
[15:28] <elopio> but also, the use of the focused_type context we have in the emulator might solve it.
[15:28] <tedg> sergiusens, I think so...  how does one get apport to report a bug on a click package?
[15:28] <tedg> sergiusens, Is there a click hook for apport config?
[15:30] <sergiusens> tedg, so if you look at vUDS august, ev suggested we used the comments/ratings for click issues and I'm not sure what was decided for direct bug reports
[15:30] <sergiusens> neither is implemented though
[15:31] <sergiusens> tedg, I'll go ask him is he's avail
[15:31] <tedg> I think that makes sense for non-preinstalled clicks
[15:31] <tedg> For pre-installs it seems there should be something different.
[15:34] <djbengan> Hello. What is the "window-manager" called in touch?
[15:35] <FuLgOrE> hey guys. I try to flash AOSP to try to flash ubuntu touch again, but fastboot doesn't work anymore. it cannot see my device. is there a way to activate debug mode in ubuntu?
[15:35] <sergiusens> tedg, so talked to ev; seems to be pitti's domain
[15:36] <FuLgOrE> ah I think I got it
[15:37] <pitti> sergiusens, tedg: we have no apport integration at all (that I'm aware of) for click ATM
[15:38] <sergiusens> pitti, yeah, he just told me that if anything is hooked up, you would know
[15:38] <kalikiana> elopio: makes sense. I just hope it doesn't merely happen to pass. in that case I'd consider re-running it twice to be sure
[15:38] <FuLgOrE> it's working now
[15:48] <cwayne> ogra_: hey, so where do we stand with that lxc-android-config MR? should we wait until we have a better way to do only-first-boot upstart jobs?
[15:52] <popey> cwayne: danielholm is having some trouble with a last.fm online accounts plugin.. would you have some time to help him?
[15:53] <tedg> pitti, Can apport detect if a crash comes from a click package?
[15:53] <cwayne> danielholm: popey: sure, what's up?
[15:54] <pitti> tedg: if there is a counterpart of dpkg -S, or some other way of associating a program to a package, then we can certainly teach it to
[15:55] <pitti> tedg: so far click+apport hasn't been discussed at all yet, and I don't yet know how click works
[15:55] <tedg> cjwatson, Does that exist? ^
[15:55] <tedg> Well, really it should be anything in /opt/click ...
[15:59] <cjwatson> tedg: no
[16:11] <sil2100> pitti: hi!
[16:11] <sil2100> pitti: we're actually getting something like that on our i386 platform-api build now: https://launchpadlibrarian.net/164362983/buildlog_ubuntu-trusty-i386.platform-api_0.20%2B14.04.20140130.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[16:11] <sil2100> It was fine in the morning
[16:13] <pitti> sil2100: hm, interaction with the new cmake again?
[16:13] <pitti> xnox: ^ does that ring a bell?
[16:13] <pitti> i386-linux-gnu-gcc-4.7: not found
[16:13] <pitti> err, what?
[16:13] <xnox> sil2100: already fixed between myself and tvoss
[16:13] <pitti> that looks like a cross-build
[16:13] <xnox> pitti: please ignore.
[16:13] <pitti> ack
[16:13] <xnox> sil2100: why are you pinging about it?
[16:13] <xnox> sil2100: it's a merge proposal at the moment, only.
[16:14] <xnox> sil2100: and pinging not the committer, e.g. tvoss or myself. What pitti has to do with it?
[16:14] <xnox> pitti: DEB_HOST_GNU_TYPE != DEB_HOST_MULTIARCH on i386 on ubuntu.
[16:14] <pitti> well, I was involved in debugging the previous fallout of https://code.launchpad.net/~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform/+merge/203298 :)
[16:14] <xnox> pitti: which i keep on forgetting.
[16:14] <sil2100> xnox: I'm pinging tvoss, actually talking with him all the time
[16:15] <sil2100> xnox: and I just remembered pitti talking something about that in the morning
[16:15] <pitti> and landing that MP is blocking other stuff and is urgent to fix platform-api, so I'm quite interested in its fate
[16:15] <pitti> sil2100: but it won't succeed anyway until https://code.launchpad.net/~thomas-voss/location-service/add_controller_and_service_configuration/+merge/199105 lands
[16:15] <sil2100> xnox: the current state of platform-api https://code.launchpad.net/~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform/+merge/203298 is resulting in this failure, and I would like this resolved as soon as possible
[16:15] <pitti> (building, I mean)
[16:15] <sil2100> pitti: that's what I'm trying to build exactly!
[16:16] <sil2100> The source from this merge is resulting in this i386 failure
[16:16] <pitti> sil2100: oh, really? location-api is broken, too?
[16:16] <xnox> sil2100: tvoss pinged me about it, i've fixed my compiler-fix branch, which he said will remerge.
[16:16] <sil2100> xnox: ok then, thanks!
[16:16] <pitti> PS jenkins seems happy with the location-api branch
[16:17] <sil2100> pitti: ah! Ignore me!
[16:17] <sil2100> pitti: location-service is ok, read 'platform-api' there
[16:17] <pitti> sil2100: heh; don't worry; I guess after wrestling with this all night and day it's too easy to lose track :/
[16:20] <tvoss> xnox, sil2100 merged and pushed xnox's changes
[16:23] <sil2100> tvoss: thanks! Excellent, already rebuilding
[16:23] <tvoss> sil2100, ack
[16:34] <kalikiana> elopio: weird failures in https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1274240-gallery-textfield_helper/+merge/203831 I wonder if that's to do with https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1274309 though not sure exactly what is broken in the lib
[16:35] <elopio> kalikiana: no, it's because the latest image is broken.
[16:36] <elopio> kalikiana: from ci: <fgint...> cjohns..., elopio, image 154 appears to be hosed
[16:36] <elopio> kalikiana: they already removed the ppa from the jenkins jobs, so that bug should be resolved.
[16:48] <annerajb> rsalveti, was the code for android 4.4 ever put on gerrit? it dosnt have a list of recently modified repositories like it had before so is hard to say.
[16:52] <rsalveti> annerajb: sorry, not yet, fixing a bug with the emulator right now, will publish everything once I get it to work
[16:53] <annerajb> rsalveti, ok
[17:00] <danielholm> cwayne: hi, well I am having some difficulty understanding the code of the auth and creating functions to call from the music app to scrobble and stuff. But I found your fitbit account code and having a look at that now. :)
[17:11] <mandel> barry, lp:ubuntu-download-manager/saucy
[17:12] <cwayne> danielholm: ah, well if you have any specific questions, feel free to ask :)
[17:13] <tvoss> mzanetti, around?
[17:13] <danielholm> cwayne: thank you :)
[17:14] <mzanetti> tvoss: hey
[17:25] <pmcgowan> any eta on a new build?
[17:29] <popey> all those disconnections looks like everyone went to the pub!
[17:55] <timppa>  is it still true if you have put ro image to rw mode and installed some packages to touch you cannot revert back to ro just bu removing the .writable_image file?
[17:56] <timppa> just curious because I had to install the libunity-mir1 with apt-get...
[17:57] <timppa> ok, 155 is just out... :)
[17:58] <timppa> seems to be working ok...
[18:25] <timppa> one thing that works now vs earlier builds is the indicator dropdown. It stays "open" once again which is very nice!
[18:41] <mterry> boiko, so should I merge that greeter-contacts branch into telephony-service myself?  Not sure who the gatekeeper is on your team
[18:41] <boiko> mterry: it's bfiller_afk
[18:42] <mterry> bfiller_afk, is it enough to leave the branch at Approved and you eventually sweep through and commit?  Or do I need to do something special?
[18:42]  * mterry is still getting used to how the new policies work on each team
[18:51] <SonikkuAmerica> So I've heard the Nexus 7 (2013) is the only officially supported TABLET left. So where's the Nexus 7 (2013) image? I see it nowhere on the wiki...
[18:52] <SonikkuAmerica> Or do I just use the daily-preinstalled images at cdimage.u.c ?
[18:53] <popey> SonikkuAmerica: dont think it's published yet
[18:53] <SonikkuAmerica> popey: Oh. :( Thanks...
[18:54] <SonikkuAmerica> They'd better hurry though... I'm itching for my 2013 Nexus 7 to play with the bleeding edge
[18:54] <SonikkuAmerica> :)
[18:54] <popey> ☻
[18:55] <popey> they're working hard on it
[18:56] <SonikkuAmerica> Ah, the person to ask for all things community. Hey jono!
[19:00] <popey> thats just a bot, the real jono is in a cryo-stasis tube on the moon.
[19:00] <jono> true
[19:00] <jono> hey SonikkuAmerica
[19:01] <jono> on the phone, will be there soon
[19:01] <SonikkuAmerica> popey: lol
[19:09] <bfiller> mterry: to get that released you need to do these steps in the checklist https://wiki.ubuntu.com/Process/Merges/Checklists/system-apps and run the test plan here: https://wiki.ubuntu.com/Process/Merges/TestPlan/telephony-service
[19:09] <bfiller> mterry: once you've verified all that let me know and I'll get it released
[19:10] <mterry> oh right, checklist happened after that was written
[20:51] <fermulator> Hi all, in https://wiki.ubuntu.com/Touch/Install#Supported_devices_and_codenames, I see that only the Nexus4 is supported (as the latest phone). Is it definitely true that Nexus5 would not work?
[20:56] <M4dH4TT3r> support mips
[20:58] <Tm_T> M4dH4TT3r: no need to repeat that
[20:59] <M4dH4TT3r> well if anyone had gotten it the first time i said it about 6mos ago i wouldnt ;)
[20:59] <popey> fermulator: no image yet
[21:37] <kenvandine> hey tedg!
[21:38] <kenvandine> i see ual now handles clicks on the desktop much better
[21:38] <fermulator> popey: thank you; are we /planning/ to support? (trying to decide if I should buy the nexus4 now, or wait for nexus5 support)
[21:38] <popey> nexus 4 works now, but you cant buy them anymore
[21:38] <popey> nexus 5 might work, but its not immediately on the list
[21:39] <tedg> kenvandine, Oh, really.  That's cool :-)  I've been running trunk from the PPA.  Archive is so far behind it's not been usable :-(
[21:39] <kenvandine> tedg, however, if the hub calls upstart_app_launch_stop_application on the APP_ID it gets in some weird state
[21:39] <kenvandine> upstart-app-list no longer lists it as running
[21:39] <kenvandine> but
[21:39] <kenvandine> status application APP_ID=....
[21:39] <kenvandine> does show it as running
[21:39] <kenvandine> so it can't start it again when needed
[21:39] <thomi> slangasek: veebers tells me I should talk to you abouyt my WIP branch to make autopilot use the libUAL gir bindings? Apparently there's a reason we shouldn't use gir bindings?
[21:40] <kenvandine> tedg, i can stop it with stop application APP_ID=...
[21:40] <kenvandine> then it all works fine again
[21:40] <tedg> kenvandine, Huh, like the application job itself hangs...
[21:40] <kenvandine> maybe
[21:40] <tedg> kenvandine, What does initctl list show ?
[21:42] <kenvandine> tedg, it doesn't show it anymore
[21:42] <kenvandine> but status does
[21:43] <kenvandine> application start/running, process 18767
[21:44] <kenvandine> yup... that process is running
[21:44] <tedg> kenvandine, initctl list?  not upstart-app-list, but the upstart one?  I don't think that's a possible state :-)
[21:45] <kenvandine> initctl list doesn't show it
[21:45] <kenvandine> upstart-app-list doesn't show it
[21:45] <kenvandine> but status application
[21:45] <kenvandine> does
[21:45] <tedg> That's crazy.
[21:45] <kenvandine> that pid is this
[21:45] <tedg> Calling it an upstart bug :-)
[21:45] <kenvandine>  /bin/sh -e /proc/self/fd/9
[21:51] <tedg> kenvandine, It'd probably be the shell script blocked on "start"
[21:54] <kenvandine> tedg,  it only happens when i stop it from the hub with upstart_app_launch_stop_application
[21:54] <kenvandine> with upstart-app-stop
[21:54] <kenvandine> it stops fine :/
[21:56] <tedg> kenvandine, Are you keeping a GDBus connection anywhere else?
[21:56] <tedg> Oh, wait, this is trunk.
[21:57] <tedg> Trunk is using the libnih connection.
[22:01] <M4dH4TT3r> would also be nice if image for HTC Desire CDMA were made too
[22:01] <popey> no CDMA support yet
[22:01] <M4dH4TT3r> ik
[22:02] <M4dH4TT3r> been waiting
[22:02] <M4dH4TT3r> and for MIPS support too
[22:02] <popey> cant see us doing mips anytime soon
[22:02] <popey> unless a handset manufacturer came along and wanted it
[22:03] <M4dH4TT3r> y not debian did and would be great
[22:03] <M4dH4TT3r> lots of MIPS tablets on the market
[22:05] <M4dH4TT3r> I hqave both MIPS tablets and phones
[22:05] <M4dH4TT3r> and CDMA phones
[22:05] <kenvandine> tedg, so the application-click job stops but then it leaves an application job running
[22:06] <kenvandine> before it calls stop, it shows up as an application-click job, and there is no application job
[22:07] <tedg> kenvandine, That's all really odd.  What happens with the untrusted-helper branch?
[22:07]  * kenvandine tries
[22:11] <kenvandine> tedg, same thing
[22:14] <tedg> kenvandine, Restarting help?
[22:14] <kenvandine> tedg, nope...
[22:14] <kenvandine> :/
[22:15] <tedg> kenvandine, Not sure how to recreate...  can you see if the DBus message is sent to upstart?  Bustle it?
[22:15] <kenvandine> ok
[22:53] <slangasek> thomi: hi there!
[22:53] <thomi> slangasek: hey - I was just about to hit send on an email instead :)
[22:53] <thomi> slangasek: tedg: I'd like to resolve the 'gir bindings vs system call' debate
[22:53] <thomi> so I don't waste my time
[22:54] <slangasek> thomi: well, a) I don't think the gir bindings provide any actual benefits over direct invocation in native python, but also b) the ual bindings haven't actually landed yet so aren't currently anything that autopilot can reasonably base on
[22:55] <slangasek> thomi: so, I have my own branch here which I think does what I think it should do; I've been in the process of trying to test it and finding that phablet-click-test-setup has had a behavior regression out from under me :-P
[22:56] <thomi> okay... the gir bindings give a much richer interface than I can get from a system call
[22:56] <thomi> unless I'm misisng something?
[22:56] <slangasek> thomi: richer yes, but why do you need richer?
[22:56] <thomi> how do I get the failed observer feature with a system call?
[22:57] <thomi> I'd like to know how/why an app failed to start
[22:57] <slangasek> well, I haven't seen evidence that ual gives you that
[22:58] <slangasek> if it does, then ok, I agree that it's better to not reimplement that parsing logic in two places and instead use the library
[22:58] <thomi> tedg: I can get that from libUAL, right?
[22:58] <slangasek> that leaves the other point, that I want this now and ual doesn't seem to be on track to land any time soon
[22:58] <tedg> thomi, Once the branches all land, yes.
[22:58] <slangasek> (OTOH, I'm not sure how relevant it actually is to autopilot to know the reason for a failure to start?)
[22:59] <thomi> slangasek: well, whatever we do we'll need to get it in an autopilot landing, so we'll need to push *something* through the landing process
[22:59] <tedg> slangasek, The reason that I'd prefer to see autopilot use the lib is because that's what Unity is using.
[22:59] <thomi> slangasek: it's pretty important to give accurate and precise feedback to the user when their app fails to start
[22:59] <tedg> The only person in production using the utilities is click, which I hope will go away with it's C rewrite.
[23:00] <tedg> slangasek, Is that still for 14.04?  If not, could we get click to use the GIR bindings?
[23:01] <slangasek> tedg: the click C rewrite is for 14.04, yes
[23:01] <cjwatson> right, I'm in progress on that
[23:01] <tedg> K, so then probably ual-tools will drop from the image then.
[23:01] <tedg> ?
[23:01] <cjwatson> and sure, if there are stable/working gir bindings then I'm quite happy to use them, even in advance of the C rewrite
[23:02] <cjwatson> ./click/database.py:88:        command = ["upstart-app-pid", app_id]
[23:02] <cjwatson> that's all I use
[23:06] <cjwatson> so from my point of view, this is only used when removing click packages; performance isn't particularly important there.  gir bindings are probably marginally better, but not much in it,
[23:06] <cjwatson> .
[23:07] <thomi> slangasek: tedg: so, are we in agreement? We use GIR bindings (need to get them landed ASAP then) - both in autopilot and in click?
[23:07] <tedg> Sure, probably parsing the GIR file is roughly the same cost :-)
[23:08] <slangasek> thomi, tedg: so I think I'm inclined to push for my autopilot changes to land ASAP on autopilot/1.4, because it addresses an immediate issue for me; after which I can look at helping to land the ual gir bindings and help rebase thomi's branch as neede
[23:08] <slangasek> +d
[23:09] <thomi> slangasek: I'm happy to land your branch on /1.4 as a shorter term fix. Ping me a MP and I'll look at it. In the mean time, I'll keep working on my gir-based branch.
[23:09] <thomi> can I leave it to you slangasek and tedg to get the gir branch landed? Is there anything I can do to help that along?
[23:09] <tedg> I put the GIR bindings on the CI Train.  I'm still allowed to edit that spreadsheet.  Not sure when a silo will be allocated.
[23:10] <tedg> thomi, Invent a better release process?  ;-)
[23:10] <thomi> tedg: inventing it is the easy part :)
[23:11] <slangasek> thomi: ack.  I'm still verifying locally that it works for a minimal test case, which is currently caught up on the script popey gave me for wrapping click tests having regressed ;P
[23:11] <slangasek> thomi: as soon as I do that, I'm going to push and raise an MP
[23:11] <thomi> slangasek: ok, cool. let me know if I can help
[23:14] <adminjs> hi guys I flashe today the new build 151 and Ubuntu Touch rocks
[23:21] <popey> adminjs: yay!
[23:29] <a_muva_> adminjs: 153 is available