=== chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === pitti` is now known as pitti === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === duflu_ is now known as duflu [08:12] good morning [08:16] mvo_: I lost the pastebin link to the codelet what you suggested for the qt5-qmake-arm-linux-gnueabih. In my hack I simple listed it in teh frameworks, but I remember your suggestion was more civilized. [08:16] bzoltan: no worries, I still have it, thanks [08:17] mvo_: If you post it again I will carry on with the click/oxide stuff ... [08:17] mvo_: and let you suffer from whatever you suffer :D [08:23] bzoltan: https://launchpadlibrarian.net/190980713/click_0.4.35-1~0ubuntu1~0trusty1_0.4.35-1~0ubuntu1~0trusty2.diff.gz - but I talk to asac, the mail from Pat sounds urgent enough to justify spending a bit of time on this to unblock you guys [08:26] mvo_: the story with the China training is that they need a snapshot of a very recent and bugfree Ubuntu SDK tools with qmake support (more simple than cmake) for that i need to release the trunk of our project to the SDK PPA. But i do not want to release my hack. [08:30] mvo_: err :) that diff from my hack [09:23] bzoltan: just to double check (sorry, I'm sure you answered this already but I forgot): qt5-qmake-cross-armhf is only for ubuntu-sdk-15.04+ - correct? it won't be backported to 14.04 and 14.10? or will it? [09:24] mvo_, i had to upload livecd-rootfs, you had un-uploaded changes there, hope it was ok to upload them along [09:25] mvo_: no, it would be too much to SRU the qtbase to Utopic and Trusty [09:29] mvo_: we have pushed the oxide-qt to the silo13 and expect it to land on vivid as soon as it can be verified -> https://launchpadlibrarian.net/191665109/oxide-qt_1.3.5-0ubuntu1_1.3.5-0ubuntu2.diff.gz [09:30] ogra_: yeah, that was fine [09:30] mvo_: I would like to add the MR to the lp:click with the qt5-qmake support to that silo. [09:30] bzoltan: oh? is chriscoulson ok with the idea? if so, great [09:31] bzoltan: I thought he had some concerns that these are real dependencies etc [09:31] mvo_: I do not know... he will have the right to say ok/nok once the silo is ready to land [09:31] * mvo_ nods [09:32] mvo_: this issue is pending for 2 months ... the China training freeze is this week's Friday. [09:32] mvo_: :) I thought creating a ready to land package will be a good alert :D [09:32] bzoltan: heh [09:33] mvo_: are these oxide packages actually ever apt-get installed/upgraded on a real device? [09:40] bzoltan: I don't know :) ideally we would make them co-isntallable [09:41] bzoltan: and thats probably not too hard, its just takes *time* [09:41] bzoltan: I already have a idea how to make it in a simple way [09:46] mvo_: I would be happy to see an ideal solution to land .. straight after we unblocked the SDK ;) [09:56] Good morning all; happy Giving Tuesday! :-D [09:58] Hello JamesTait [09:59] mvo_: so will you create a branch for the native qt5-qmake-cross-armhf or should I do it. I would simple put in the fw the native qt5-qmake-cross-armhf package, what is a less pretty solution. [10:02] bzoltan: https://code.launchpad.net/~mvo/click/qt5-qmake-cross-armhf [10:02] mvo_: thank you [10:03] mvo_: note that the qt5-qmake-arm-linux-gnueabihf is not just useless on armhf arch, but it does not exist, so attempting to install it will fail [10:04] mvo_: that is why i am not fully happy with my own hack, because I do the same.. I do not know if we will ever support native arrmhf chroots [10:25] mvo_: but as I see the click code, it knows only the target arch and does nothing with the host arch ... so should we just ignore that problem? [10:26] bzoltan: it does not care much about the host arch right now - and yes, it break armhf -> armhf chroots, but we can fix it once we support that [10:26] bzoltan: this is mostly to unblock you, its not prefect [10:27] mvo_: I am happy with it.. we never said that we support armhf based environment for the SDK :D === greyback__ is now known as greyback [10:58] ogra_, are you in image 45 on vivid? does the check for updates in system settings work? [11:05] mandel, only RTM on my devices atm ... ask davidcalle [11:05] err [11:05] ask davmor2 [11:06] mandel: how are you on 45? [11:06] davmor2, do you have vivid 45? I'm testing the system image updates and it never stops checking, is get stuck for ever [11:07] davmor2, well, that is the img number I get from the "About this phone" page [11:07] davmor2, Ubuntu 15.04 (r45) [11:08] mandel: image 39 is the latest devel-proposed image so I don't know if you are on a different channel [11:08] mandel: image 40 is building currently [11:08] davmor2, wtf?? that is weird [11:08] ogra_: ^ I'm not dreaming this right [11:09] davmor2, mandel, different arches, different numbers ;) [11:10] someone doesnt use mako here ;) [11:10] I'm sure is 45 [11:11] davmor2, 39 is on mako, 45 on another arch [11:11] jibel: yeap solved === _salem is now known as salem_ === dandrader is now known as dandrader|afk === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [11:36] mvo_: how is the click landing procedure? I assume you wish to see cjwatson's nod on that MR for merging it to thde click/devel branch. [11:37] bzoltan: He should feel free to go ahead without that, since I'm moving out of click development [11:38] cjwatson: Good for you :) bad for us [11:38] There are other members of ~click-hackers if you (plural) want to get a review, and probably a good habit to be in === MacSlow is now known as MacSlow|lunch === chihchun is now known as chihchun_afk === dandrader|afk is now known as dandrader [11:53] cjwatson: good point === chihchun_afk is now known as chihchun [12:06] out of morbid curiousity, do you guys still have surfaceflinger running in some form on your mir images? [12:07] mvo_: would you take the risk :) to add me to the ~click-hackers team? I could help with integration and testing as start. [12:08] Stskeeps: no [12:08] good [12:08] heh [12:08] although I note the binary is still in the image [12:08] I guess so you can switch to it optionally if you want to [12:08] yeah, always good for testing environment === Ursinha is now known as Ursinha-brb === Ursinha-brb is now known as Ursinha === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === alan_g is now known as alan_g|lunch === MacSlow|lunch is now known as MacSlow === alan_g|lunch is now known as alan_g === dandrader is now known as dandrader|lunch === pstolowski is now known as pstolowski|lunch === dandrader_ is now known as dandrader [14:34] jdstrand: are apparmor denials logged by default, or do I have to do something to enable them? [14:35] mardy: they are logged by default, but two things might affect logging: kernel rate limiting and explicit deny rules [14:35] mardy: when doing policy debugging, I do this: sudo sysctl -w kernel.printk_ratelimit=0 [14:37] mardy: you might do a 'grep deny /path/to/profile' to see what explicit denials there are. explicit denials silence logging (if you see 'audit deny', that is an explicit deny that will be logged) [14:37] jdstrand: oh, and actually I just notice that the problem I'm debugging is unconfined, so I guess I can safely rule apparmor issues out :-) [14:37] heh, yes === ryukafal1 is now known as ryukafalz [14:47] alan_g: hi! To start a client inside a trusted session, does the client process need to be a fork of the process which created the trusted session? [14:49] mandel: ping [14:50] barry, pong, yes landing today, testing first in the following silo => https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004 [14:50] mardy: no it just needs to use the socket provide by the helper [14:50] barry, if you can give it a +1 I'll appreciate it :) [14:50] mandel: thanks! i'll test it [14:51] forking is one way to pass it the needed fd - but is hardly a convenient approach if you've any threads running [14:51] alan_g: I get an error that the connection to Mir server failed; any hints on how to debug it? the MIR_SOCKET is set to "fd://12" [14:52] but 1396559 [14:52] bug 1396559 [14:52] Error: Launchpad bug 1396559 could not be found === pstolowski|lunch is now known as pstolowski [14:53] How do I upgrade the version of Ubuntu running in the emulator I've created? [14:53] mardy: how are you passing the fd to the client? Over dbus? [14:55] aquarius: i think the advice I have seen is "destroy it and make it again" [14:56] alan_g: OK, that might be the issue: I'm not passing it at all :-) [14:57] mardy: that would be a good starting point. ;) [14:57] tedg: is there a way to pass an fd with ubuntu-app-launch? how do you share the fd between the pay-service and the pay-ui? [14:58] alan_g: thanks! It may be that forking then is the easiest way to get it working... [14:59] popey, oh. really? :( [15:00] aquarius: rsalveti may know more [15:00] mardy: FWIW system() also inherits FDs === chihchun is now known as chihchun_afk [15:02] mardy, No, I use dbus to share it. But you could use any socket connection. [15:02] mardy, Reality is that you need something that is in the same process chain as the final executable, so it's hard to pass through the phases of Upstart. [15:02] http://payripo.com/?share=7080 If any of you is looking for an online job, this is your website. I've earned like 70 dollars for the last 4 days. [15:04] mardy, https://wiki.ubuntu.com/Pay/Architecture#Trusted_Prompt_Sessions [15:04] charles, did you ever track down that indicator-power/unity8 freeze? [15:04] charles, it's blocking my greeter-profiles branch [15:05] tedg: ah, thanks! [15:05] mardy, http://bazaar.launchpad.net/~indicator-applet-developers/pay-service/trunk.15.04/view/head:/service/mir-connection-demangler.c [15:05] mterry, argh, no I sidetracked myself onto other things. I didn't realize it was blocking you! [15:05] mardy, Also, make sure to do this. That one line cost me 3 days :-) http://bazaar.launchpad.net/~indicator-applet-developers/pay-service/trunk.15.04/view/head:/service/mir-connection-demangler.c#L105 [15:06] mterry, is the change you made to the indicator profile configuration file not enough to unblock? [15:06] charles, oh sorry yeah. My branch to actually enable different indicator profiles can't land if we keep freezing the UI :) [15:06] charles, it would be I think, but then we don't get the nice greeter profile for the power indicator [15:06] But I could move forward at lesat [15:06] And we'd get greeter profiles for other indicator [15:06] s [15:06] So probably a win [15:07] tedg: however, I think I might be better off without UAL, using just QProcess makes things simpler [15:07] tedg: QProcess + aa_change_profile [15:07] mardy, It makes things simpler from the process part, but you need all the cgroups support etc to ensure PIDs don't leak. [15:08] mterry, I'll resume that right now then so we can get you unblocked [15:09] charles, ok thanks, yeah just fixing the power indicator should be enough for now === chihchun_afk is now known as chihchun [15:10] popey: aquarius: right, unfortunately image updates is not yet supported by the emulator [15:11] rsalveti: is it on the roadmap? [15:13] rsalveti, so, the way to get a new emulator is to just delete the old one(s) and create a new one from scratch? [15:14] aquarius: yes [15:14] popey: yup [15:14] Which channel should I use to have an up-to-date emulator? [15:15] it depends if you want to use vivid or RTM, they are different series [15:15] vivid is the latest, but not necessarily stable [15:15] RTM is more stable in general [15:15] right, vivid is develoiper playground [15:15] no warranty :) [15:15] my options appear to be: devel, devel-proposed, stable, rtm-14.09, rtm-14.09-proposed, and "custom". I'd like to use whatever's going to be most reminiscent of an Ubuntu device which hits the market. :) [15:16] whereas that lengthy warranty on the rtm channel... [15:16] :D [15:17] aquarius, ubuntu-rtm/devel or ubuntu-rtm/devel-proposed are what you want ... [15:17] ogra_, so, I should use "custom" and enter "ubuntu-rtm/devel"? [15:17] both should be similarly stable, -propoased has more fixes and a bit less QA [15:18] custom ? [15:18] ogra_, and if tomorrow some changes have done into ubuntu-rtm/devel, I need to destroy my emulator and re-create it? [15:19] yeah, currently you have to [15:19] ogra_, the options I have are those above. Is "devel" the same thing as "ubuntu-rtm/devel"? [15:19] no, devel is vivid ... ubuntu-rtm/devel is the same as rtm-14.09 (where do these names come from ?) [15:20] no idea where they come from -- they're what I get in Ubuntu SDK in the "Create emulator" popup. [15:20] oh [15:21] no idea about the SDK [15:21] i use vi for my apps :P [15:21] (and the emulator natively if i need it) [15:21] popcorn.gif [15:21] silent.wav [15:23] jgdx, did you see my less_flaky branch? it includes some of the steps to be more inline with the page object model we want and makes some of our really flaky tests less flaky [15:24] jgdx, next i want to prune the autopilot tests of the tests that should be qml tests, then refactor the remaining tests [15:26] kenvandine, I just looked at it. Good stuff. :) [15:27] right, that would remove 10+ tests right off the bat [15:28] jgdx, at least... i hope :) [15:28] which would reduce the number of tests we need to refactor [15:28] jgdx, but i wanted to do something to make it more reliable... landing that silent mode branch drove me insane... [15:29] every CI run had different failures... crazy! [15:29] kenvandine, wut? The one just now? ted's? [15:29] last week [15:29] or week before [15:29] but i was seeing like datetime failures every 3rd CI run, etc [15:30] completely unrelated [15:30] switching to use the go_to_page model helps stabilize that [15:31] jgdx, one thing i've been beating my head against the desk over is test_phone.py [15:31] kenvandine, what's happening? [15:31] we have the test case there for dialpad sounds, which is based on SoundBaseTestCase [15:31] not the ofono one [15:31] it passes fine if i run that one test case [15:31] but if i run all the tests in there [15:31] most of them fail [15:32] it's like the setUp and tearDown has issues [15:32] it basically stops getting input [15:32] actually, that reminds me of an error I hit a while back [15:32] kenvandine, do you get a timeout? [15:32] no obvious timeout [15:32] but i suspect it is [15:33] if i run PhoneSoundTestCase and PhoneTestCase separately they pass 100% of the time [15:33] but if i run test_phone [15:33] okay, I found that if I tried to change a readonly interface *something* broke down, and that manifested itself like how you explain [15:33] some random number of the total tests fail every time [15:35] kenvandine, could you paste the log for the most common way it fails? [15:51] kenvandine, updated my cellular "manual persist" branch btw, addressing your comment. [15:51] jgdx, thx [15:51] i'll get a log in a bit [15:51] i already moved the test out :) [15:52] but i would like to know wtf is up! [15:56] jgdx, http://paste.ubuntu.com/9346242/ === om26er is now known as om26er|dinner === yorick_ is now known as yorick [16:39] mardy, is http://developer.ubuntu.com/apps/platform/guides/online-accounts-developer-guide/ out of date? There doesn't seem to be a Setup element any more [16:40] mardy, and when I create an AccountServiceModel, my QML app throws an error: "Error opening accounts DB: unable to open database file. Manager could not be created. DB is locked" [16:40] mardy, and applicationId no longer seems to exist on an AccountServiceModel either [16:49] dbarth_, do you know about online accounts stuff? [16:52] hey all, is it possible to take screenshots directly on the phone now, without phablet-screenshot? [16:52] rickspencer3: press vol+ and vol- together [16:52] rsalveti, press bpth vol keys [16:52] *both [16:52] thanks popey [16:52] you get a popup unfortunately [16:55] popey, yeah, so, no way to turn off the volume notification? [16:56] you can crop it out with gimp afterwards ... leaves a hole though :P [16:56] lol [16:56] (no, there isnt) [16:56] aquarius: hi; yes i may be able to help [16:56] I think the idea is that you can share the pic from your phone [16:56] there is a bug open for that though [16:56] aquarius: ah, sorry ready the logs [16:56] thanks ogra [16:57] aquarius: if you are developing an app, the best is too take a look at the slide deck from UOS [16:57] aquarius: https://docs.google.com/a/canonical.com/presentation/d/1_BnaAASynFES-kwHoiIh2e9V2nBpYak5h_vmLfAbSIA/edit#slide=id.g1877ebb12_6_0 [16:58] which contains the latest from mardy on how to use the API and the various configuration files [16:58] ogra_: aquarius: they are the emulator channels. The same as the device channels, but they are i386 [16:59] rickspencer3: known bug [16:59] aquarius: more specifically: there is still a setup element; that's what we use to request account creations [16:59] thanks popey [17:00] aquarius: for another working example, you can look into the reminders app code: it does query the account db, and offers to create accounts if needed [17:00] aquarius: otherwise goes on to request an access token with the evernote api === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem === mozzarel1 is now known as mozzarella === om26er|dinner is now known as om26er === _salem is now known as salem_ [17:52] dbarth_, http://developer.ubuntu.com/api/qml/sdk-14.10/Ubuntu.OnlineAccounts/ does not mention a Setup element? [17:55] Chipaca or ralsina_, ping about push message handlers and the network [18:00] kenvandine, any objection to landing the drop-wizard branch soon? === alan_g is now known as alan_g|EOD === salem_ is now known as _salem [18:08] mterry, no real objection [18:09] kenvandine, now you made me worried about your fake objections [18:09] i think we have some wizard related fixes in vivid that we'll land in rtm soon [18:09] so we should land those first [18:09] to ease backporting [18:09] unless the wizard add to unity8 is planned for ota-1 :) [18:16] kenvandine, I doubt it :) -- ok well then. I guess let me know when I can land [18:16] Chipaca, ralsina_, __lucio__, specifically: when a push notification comes in, my app's message handler gets run to process it even if my app isn't running (I think?). Can my handler reply to the network and so my server and my app have a little conversation without user intervention? [18:16] mterry, so after we're done with the backports to rtm [18:16] mterry, i am quite excited about landing that :) [18:17] kenvandine, that's not in a silo yet? [18:19] <__lucio__> aquarius, you have ~10seconds to do whatever permissions the helper gets [18:19] <__lucio__> aquarius, then we kill it [18:19] __lucio__, ooh. Does "talk to the network" come under the handler's permissions? [18:20] <__lucio__> aquarius, not sure. maybe Chipaca can tell you. [18:21] __lucio__, what I want to do is talk to a server and say "hey, server, my unique token is XYZ; remember it". But the server doesn't know whether I'm lying about that. So my thought was, the server then sends back a push notification to that token saying "ok, prove you're you: the magic word is 'ahaha'". And then the push helper gets that message and says to the server "the word is 'ahaha'" without telling the use [18:21] r or showing any visible notification... [18:23] <__lucio__> aquarius, the idea is that the app that sends the token has the login information for the user (or something like that) [18:23] __lucio__, sure, but there's nothing stopping you just making a curl request from your desktop to myserver/register?token=ABCDEF [18:23] __lucio__, and I'm trying to avoid having the user actually have to *sign up*, because there's no need :) [18:25] <__lucio__> aquarius, that token is a) going to be invalid, b) generated in the device or with the users account + device id [18:25] <__lucio__> so, if you have the users u1 credentials, it should be ok for you to fake his tokens [18:26] __lucio__, the server doesn't *know* that it's invalid, though. I want the server to verify it's valid by sending a push notification to it, and having my app respond to that push notification; make sense? [18:26] <__lucio__> aquarius, your server will know as soon as it tries to push the first notifications [18:26] <__lucio__> aquarius, push "{}", check for the token to be valid, in the helper ignore it [18:27] __lucio__, aha, the push server will tell my server if a token is invalid? nice [18:27] I didn't know that :) [18:27] <__lucio__> aquarius, we are working on more docs :) [18:28] __lucio__, ya, I was just about to note that I didn't know it because the documentation doesn't mention it :P [18:29] <__lucio__> Chipaca, ^ something to mention in the docs [18:29] Chipaca, yeah: "how does my server verify that a token it's been given is real" would be a good thing to have === _salem is now known as salem_ === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [19:50] aquarius: hi! The guide is new and correct but the API reference is way outdated [19:51] mhall119: is it possible to update our api docs there? [19:52] aquarius: __lucio__: I seem to have missed out on some excitement over dinner; what's going on? [19:53] Chipaca, see scrollback :) [19:54] aquarius: i've got a lot of that :) from when? [19:55] mardy: which API doc? [19:55] Chipaca, summary: I was worried about being told the push token by a client but being lied to, but __lucio__ says that the push server will throw an error if I supply a bad push token with a message, which is lovely but undocumented ;) [19:56] aquarius: well... you could be given somebody else's token, if we're getting mitm'ed somehow i guess? [19:56] Chipaca, also, an extra question from above: can my push helper talk to the network? in particular, can my server send a push message to my phone and my push helper on the phone connect back to my server without the user seeing anything and without my app being open? [19:56] aquarius: not at all reliably [19:56] aquarius: and i'd have to check with jamie as to whether it's allowed at all; i think not [19:57] aquarius: if i don't remember wrong, the *only* thing you can have as a push helper is the push helper bits [19:57] Chipaca, right, but I am assuming that I'm not given someone else's token, because tokens are secret like passwords, so if someone else gets my token they can already sod me up and I'm not making it any worse. It's more whether I have to verify a token that I'm handed or whether I can just say, well, if you lie to me about what your token is, you don't get any messages, and that's OK [19:58] aquarius: yeah, lying isn't a problem [19:59] unless you're a very unlucky liar :) [19:59] Chipaca, I can do a verify dance, where you say "this is my token", and I say "oh really? prove it: I'll push a secret message to that token and you tell me what the secret message is and I'll believe you" [19:59] but if I don't have to do that then I won't :) [19:59] aquarius: and if user A can convince you that they're actually user B and you use A's token meaning to talk to B, that's all you [19:59] mhall119: accounts-qml-module-doc and qml-module-ubuntu-onlineaccounts-client-doc [20:00] aquarius: there's an easier way, i think, that you could do [20:00] aquarius: as a reply to the client telling you their token, you give them a public key [20:00] aquarius: crypt the notification contents with the private key [20:00] nah, that's OK -- I don't think I need it [20:01] aquarius: store the public key in one of the package-accessible directories [20:01] mardy: are the docs you want in utopic's archive? [20:01] aquarius: the helper can then decrypt [20:01] aquarius: but yeah, it's taking it a bit far :) [20:01] qtdeclarative5-online-accounts-client-doc_0.4+14.10.20141006-0ubuntu1 [20:01] anyway, i've got to evict somebody from a bathtub [20:01] ttfn! [20:01] Chipaca, is there anything I can guarantee about the tokens? like, how long they are, or which characters they contain? [20:03] Chipaca, ok cheers :) [20:03] mardy: check http://91.189.92.89/api/qml/sdk-14.10/ and if it looks correct I'll publish to production [20:04] Chipaca is either a parent, of a very bad landlord [20:04] s/of/or/ [20:05] mhall119: or both [20:05] that's one way of describing parenthood :) [20:14] mhall119: they are correct, please publish :-) [20:17] mhall119: aquarius: https://www.youtube.com/watch?v=t-PFNHQAh5s [20:17] davmor2: ^ also [20:17] anyway [20:17] aquarius: why would you want to know that about a token? [20:17] (i do have a non-question answer, but i need to know :) [20:21] Chipaca: man only one hand, you're not strict enough as a landlord, with no hand no damage ;) [20:21] davmor2: i know, but what're you going to do, they're family [20:23] Chipaca: hahaha [20:29] aquarius: u1 auth tokens? they are the same as oauth1.0a tokens. [20:33] well [20:33] we changed the length of tokens generated with the 2.0 SSO api from the 1.0 api === greyback_ is now known as greyback [20:35] mardy: pushed to production [20:37] kenvandine, apart from the different error message, that paste describes what happened to me. Not to send you out on a wild-goose chase… [20:38] yeah... the output isn't really helpful [20:38] i think the "Connection closed" bits are the real problem [20:38] kenvandine, check the mock delta and see if anything is not supposed to be touched from a lib point of view [20:38] like dbus getting yanked out from uner it [20:39] what do you mean? [20:39] beuno: the token, or the secret? or both? [20:39] dobey, I'm going to say token === salem_ is now known as _salem [20:40] kenvandine, in my case I made a change in a modem property that was readonly from ofono and libqofono's POV. [20:40] which then caused dbus to just say "nope" to all requests [20:40] i didn't make any changes there... [20:40] in fact, i hadn't made any changes to the mock's at all [20:41] actually, oauth1.0[a] spec doesn't specify exactly what the contnet of the token would be [20:42] jgdx, does the tests in test_phone work for you on desktop? [20:43] jgdx, i just tried trunk and got the same problem [20:43] but, as it is used in HTTP request parameters and/or the headers, it has to be ascii, and not contain certain special chars which are used by HTTP in those two instances [20:44] kenvandine, hang on [20:44] jgdx, what really drives me nuts is that test_phone.PhoneSoundTestCase passes and test_phone.PhoneTestCase passes [20:44] but test_phone together doesn't [20:44] test_phone.PhoneDualSimTestCase passes too [20:44] so it's pretty much [a-z0-9]+ most every case [20:44] not that a random application using u1 auth should care or need to know [20:45] jgdx, it's only a problem when i include PhoneSoundTestCase, which inherits from SoundBaseTestCase, with the ofono based tests [20:47] kenvandine, no failures in trunk @1215 [20:47] or rather, one actually [20:47] but that's the one we're seeing on jenkins [20:48] jgdx, ok... fails on my desktop [20:48] well that's annoying :) [20:48] have you tried rebuting it [20:51] Chipaca, I'd like to know it because I need to store them in a database, probably, and if tomorrow you turn around and make them a 2 kilobyte PGP key or something you'll sod up my DB schema :) [20:52] aquarius: if your db schema can't deal with arbitrarily long access token strings, then you're schema is already sodded up ;) [20:53] dobey, well, perhaps. I'm just trying to get a sense of what the deal is with them; at the moment they're a relatively short string. Are they likely to roughly stay that way? [20:56] aquarius: i can't say for sure, but i wouldn't expect them to change length often. but i can't guarantee that we don't wake up one day with a fancy security hack and we suddenly have to destroy all existing tokens and generate new ones that are 4096 bytes long. :) [20:56] dobey, yeah -- I can understand that, and if that happens then everyone's token gets invalidated, my app breaks, and I fix the server :) [21:00] aquarius: the trick is to write your app/server to deal with invalid tokens [21:06] aquarius: sorry, was afk. tokens are base64-encoded [21:08] aquarius: your server needs to deal with invalid tokens, btw [21:09] aquarius: our server will say "oi, that token? garbage" (actually more often: unknown). So you nuke it. [21:10] yep [21:10] invalid ones I don't mind [21:20] aquarius: if we change token length, all prior tokens will invalidated on our server, and thus be invalid. handle invalid tokens, and if you need to store the token for some reason, don't be dumb and limit possible length of the token string. and you'll be fine :) === ryukafal1 is now known as ryukafalz === beuno_ is now known as beuno [23:10] mterry, ping [23:10] charles, heyo [23:10] mterry, https://code.launchpad.net/~charlesk/indicator-power/show-phone-menu-in-phone-greeter/+merge/243473 [23:11] mterry, it doesn't affect the workaround you opted for (and which I agree with), but FYI I tracked down the lockup problem [23:11] charles, oh nice! [23:11] mterry, it's written up in that MP which I assigned to you for review [23:11] mterry, (as you'd expect, it's just a one-liner in com.canonical.indicator.power switching the phone_greeter's menu) [23:12] mterry, the better news is: [23:12] charles, ah that's a nice one-liner :) [23:12] mterry, since nobody else uses com.canonical.indicator.basic, we shouldn't have any subsequent issues in other indicators popping up down the road [23:12] charles, ok cool [23:13] charles, so unity8 doesn't seem to handle types it doesn't know well I guess? :) [23:13] mterry, looks like it. I'm not sure it's worth reporting a follow-on bug for that :/