=== _salem is now known as salem_ [04:23] Good morning === salem_ is now known as _salem === chihchun_afk is now known as chihchun === roadmr_afk is now known as roadmr === roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr [08:54] Hello all, I have couple merge proposals (server test cases) any chance one of the commiters can look at them so I can get the bugs closed? [08:56] ki7mt: I'll look at them both in the next hour or so [08:57] elfy, Thanks, appreciate that. [08:59] welcome [09:40] ki7mt: there's a few issues with them still [09:42] elfy, Yes, I got your emails, I thought I had all those "Should's" out of there I guess I missed one. [09:42] mmm [09:42] wonder if I was looking at the right one then - there were a lot [09:42] The KB stuff was kind hard to explain, but going though the installer, it's the selections. [09:43] ok [09:43] I'll review them again, no probs and drop you a note tomorrow. [09:44] ok - mark it for review again - you can put elfy in the name - I'll notice that :) [09:44] Just to be clear though, I did a push to update the MP's do I need to resubmit the MP as well? [09:45] not as far as I know [09:46] Ok, was just checking, been since I did that. Ok will get on it. [09:46] been a while since .. .. [09:46] :) [10:24] jibel: OOI, why does adt-virt-ssh need the -H/-l/-p options? isn't that something the setup script needs to know and tell a-v-s? [10:25] pitti, it doesn't for adb, but it does for example is you use an existing ssh host that doesn't need a setup script [10:25] s/is you/if you/ [10:25] jibel: aah [10:25] jibel: so in that case we wouldn't have root or revert [10:26] pitti, right [10:26] well, we could have root but not revert [10:26] that's a case where sudo capability must be autodetected === roadmr is now known as roadmr_afk [11:01] jibel: ah right, with ASKPASS=/bin/true or so === _salem is now known as salem_ === roadmr_afk is now known as roadmr === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [14:07] pitti, any idea what fails here http://dmz-jenkins.ubuntu-ci:8080/job/hwe-eol-precise-desktop-amd64-lts-raring/5/console ? [14:07] I get this error frequently and a re-run usually fixes it [14:09] jibel: uh, is that a race condition? [14:10] jibel: I suppose this does use the adt-buildvm VM, i. e. it shoudl have a root shell? [14:11] fginther, balloons: yay, I just made autopkgtest's new "apt-get download test deps, unpack into /tmp/ and set $*_PATH" fallback for r/o system capable enough to work for the entire autopilot stack (including libautopilot-qt etc.) [14:11] pitti, yes with adt-buildvm, and another job works fine with the same base vm http://dmz-jenkins.ubuntu-ci:8080/view/HWE%20EOL/job/hwe-eol-precise-desktop-amd64-lts-saucy/2/console [14:12] fginther, balloons: in case we want to stop shipping autopilot on the phone :) [14:12] pitti, ohh, so if I update from your branch I'll get all those goodies? [14:12] balloons: haven't committed yet, but soon :) [14:12] pitti, yes I don't think autopilot should be part of the stack [14:13] balloons: I now have a --setup-commands script for starting an upstart user session, another one for switching apt/dpkg to read-only (to force the fallback to "local unpack"), both together approximates what's happening on a phone quite closely [14:13] pitti, very nice! [14:13] balloons: i. e. click stuff can be tested in a schroot or LXC [14:14] which might be enough for the odd merge proposal or automatic click verification, etc. [14:14] pitti, so what's the one the phone story look like/ [14:14] balloons: on the phone we don't need these setup scripts of course, you'd just call adt-run with the click source and binary [14:15] we need the ssh runner for that though, not the lxc/schroot/qemu runner [14:16] jibel: did you ever happen to watch this in real-time? do you have a rough feeling how much time there is between "adt-run: DBG: sending command to testbed: open" and the failure? [14:17] pitti, no only in jenkins. I'll try to run it directly on the host. [14:17] jibel: I'll add some time stamping to that in git, so that this is easier to debug [14:17] jibel: I never saw that for utopic-adt-*, so this is new to me, I'm afraid [14:18] jibel: but this is precise, right? maybe sysvinit/upstart behaved differently there, to start getty on ttyS0 earlier than the autopkgtest init.d script [14:18] jibel: hang on, I need a few minutes to empty my brain state [14:18] pitti, not urgent [14:19] I can press the rebuild button :) [14:20] and for the record, I don't like ubuntu-app-launch for testing.. it's waaaay too indirect and complicated [14:20] pitti, jibel how's the ssh runner coming? [14:22] balloons: all pushed now [14:23] balloons: the remaining bit that I now need to do is to interpret an x-test description "autopilot": "@AUTOPILOT_DIR@" adequately [14:23] balloons: so that we don't need to modify a lot of click packages with the diff I pasted a few days ago [14:24] jibel: how can I get into that VM? [14:24] jibel: I have an idea [14:25] pitti, it's on rabisu.ubuntu.ci, I think you have access. [14:26] jibel: wow, first login; I'm in [14:26] pitti, then /var/lib/jenkins/HWE-EOL/images [14:27] pitti, autopkgtest is in my home dir, but you can git pull it if you need to [14:27] ⟫ kvm -m 2048 -snapshot -drive file=adt-precise-amd64-cloud-server.img,if=virtio -nographic -monitor none [14:27] Could not access KVM kernel module: Permission denied [14:27] grrr [14:27] jibel: anyway, let me build a local one [14:28] jibel: is this just a bog standard adt-buildvm-ubuntu-cloud -r precise ? [14:29] pitti, not really [14:30] pitti, it's $AUTOPKGTEST_BASE/tools/adt-buildvm-ubuntu-cloud -s $DISKSIZE -a $ARCH -r $RELEASE --userdata $HWEDIR/hwe-eol/config/user-data.${RELEASE}.${FLAVOR} -v -o $HWEDIR/images/ [14:31] pitti, with this user-data file http://bazaar.launchpad.net/~jibel/+junk/hwe-eol/view/head:/config/user-data.precise.desktop [14:31] jibel: ah, so /etc/init/ttyS0.conf and /etc/init.d/autopkgtest both start for runlevel 2 [14:32] jibel: perhaps ttyS0.conf is faster, and it tries to get the shell too early [14:32] pitti, changes in user-data are adding a ppa and some addiotional packages [14:36] jibel: how often does that happen? i. e. after how many runs/days could you say that the problem is fixed? [14:36] jibel: http://paste.ubuntu.com/7700722/ is something which you could apply locally to the git checkout [14:36] jibel: this isn't a real fix of course, but if that works I can turn this into a proper poll loop with timing out [14:37] pitti, it's random but frequent, I need to restart the job like 2 to 4 times before it works [14:38] pitti, another bug http://dmz-jenkins.ubuntu-ci:8080/job/hwe-eol-precise-desktop-amd64-lts-raring/7/console when there is a ppa and proposed enabled [14:38] pitti, we sould probably restrict the rewriting to entries with *.ubuntu.com [14:38] should [14:39] jibel: oh, that's --apt-pocket=proposed? [14:39] pitti, yes + ppa:mvo/hwe-eol [14:39] defined in user-data [14:39] jibel: mind filing a bug about that? I'm running out of time today [14:40] pitti, heh, no problem, thanks for your time on this :) [14:40] jibel: yeah, that fix is a bit more involved, I want to test case this properly etc. === zequence_ is now known as zequence === salem_ is now known as _salem === _salem is now known as salem_ [17:50] balloons: FYI, the installer has been changed, the step by step instructions for the test cases are now out dated and need updating. === salem_ is now known as _salem === _salem is now known as salem_ [18:06] balloons or popey: this is ready for a review. It doesn't change anything to make reminders tests more stable, but will give better feedback: [18:06] https://code.launchpad.net/~elopio/reminders-app/fix_with_account/+merge/224221 [18:07] balloons: what about your branch with the reordered account manager? Should we merge it too? [18:07] phillw: do a bug report for it - I watch them [18:09] elfy: not too sure if I'm allowed to do official stuff. But, I will flag them up. [18:09] mmm [18:26] phillw, ty for the heads up. I'll echo elfy in that please do a bug report [18:26] the more detail the better ofc, but report it :-) [18:27] elopio, I was planning to make a go / no go decision on it this afternoon. It doesn't work without it for me, but I feel like there is a better way [18:33] balloons: can you merge mine and then see what the log looks for you in case of error? [18:34] elopio, yep that sounds like a plan [19:12] elfy, Hello, if your around, think I have all the syntax and other issues resolved on the two proposals. I used the tidy script to test them. Whenever you have time to review again, they've been pushed up. [19:20] ki7mt: cool - I'll grab that in the morning and get them tidied away then :) [19:31] elopio, btw do the tests with account work for you on your desktop? [19:32] balloons: on my laptop, yes. On my desktop it's still crazy, not even passing the account store. [19:32] balloons: before adding the logs, I could reproduce the error on delete like 1/20. [19:32] now with the logs, I haven't been able to reproduce it. [19:34] elopio, I feel it would be helpful to print the account info as a debug print [19:34] balloons: I was looking for that, but I'm not sure where is the oauth token stored. [19:35] I made tests for everything account-console show prints [19:35] elopio, is there not a call we can make? [19:35] which is not really useful, just "evernote" [19:36] elopio, well, you'd end up reading it out a db [19:36] my old branch has the location.. [19:37] balloons: which old branch? [19:37] elopio, looks like ~/.config/signond/signon.db and signon-secrets.db [19:38] lp:~nskaggs/reminders-app/oauth-ap [19:39] balloons: and how do I print that file? [19:40] elopio, it's an sqlite db [19:40] elopio, I was originally meaning just print the account info.. just what account console shows [19:40] but if you want more, you could query the db and print the output [19:41] balloons: I'm not sure what to query. I actually don't want anymore, as setting the oauth token has never failed. [19:41] but it was you that asked for more :) [19:42] elopio, yes I think it's overkill.. I was simply wanting account console to confirm the account was created in the debug log [19:42] with the tests I added, we are making sure that the evernote account is always added and enabled [19:42] show me a little something about it [19:42] I know, I just like to see it :-) [19:42] elopio, mostly I'm asking because your branch still fails for me on the desktop [19:43] balloons: but what does it show on error? [19:43] elopio, nope [19:43] that's what I wanted to see. [19:44] elopio, here's the run: http://paste.ubuntu.com/7702244/ [19:45] Notice it *seems* to create ok?, but reminders doesn't see it and it fails to delete but doesn't say why [19:46] it's still building in the chroot, I'll have a run from the device soon [19:46] ki7mt: in fact I just did it now - all merged/synced and fix released now - thanks :) [19:47] elfy, Thanks !! [19:47] thank you :) [19:47] elfy, phillw did we get a bug filed? I may have missed it [19:49] balloons: I will bug it tomorrow, it is a grey bug and testing for red bugs is the priority [19:49] I've not seen one yet - am watching for it [19:53] balloons: http://bazaar.launchpad.net/~elopio/reminders-app/fix_with_account/revision/170 [19:53] that's what we can gather easily. [19:53] looking at your paste... [19:54] balloons: I've been busy, I'll file the bugs :) [19:55] phillw, :-) [19:59] balloons: can you pull and run again please? === chihchun is now known as chihchun_afk [20:06] elopio, sure.. did you make qml changes [20:06] if not, re-running on device is much easier :-) [20:06] I didn't. [20:16] elopio, nice output :-) The account shows it's not enabled :-) [20:16] 16:16:07.269 DEBUG credentials:152 - enabled: False [20:18] nice. [20:18] now why on earth is that happening. [20:18] balloons: can you run the test_credentials.py ? [20:19] just a sec and yea I'll invesitgate [20:20] balloons: take a look at account.set_enabled(True) on _create_account [20:20] you can put a pdb there, and then inspect what account.get_enabled() returns after that [20:21] it's hard to inspect because it's async. But you could continue putting breakpoints to find where the account is disabled. [20:21] right [20:23] hmm.. no luck on device either.. back to desktop for a moment [20:25] elopio, it indeed shows false after get_enabled.. running set_enabled(True) and get_enabled still shows false [20:30] balloons: are you on desktop now? [20:30] elopio, yes.. looking at account-console it says it's enabled.. interesting.. [20:31] balloons: remember to do HOME=/tmp/... before account-consoel [20:31] elopio, I did.. id matches etc [20:31] makes no sense. [20:32] wild.. [20:38] elopio, I'm not seeing the method calls in Accounts.py you are using.. I'm missing something [20:44] elopio, could you list what account-console show shows? [20:45] Not that I think it will change anything [20:45] but yes, accounts console and the python are returning different thingds [20:50] yes I can. [20:50] one second. [20:50] elopio, it's odd, but your latests updates makes the app not launch on the device [20:51] the diff doesn't reveal anything.. hmm [20:54] elopio, so I deleted the account, but I can still print it afterwards [20:55] ahh I see the goodies are in account_service.get_auth_data() [21:02] balloons: yes, but that's information that we never set. It's taken from online accounts. Would you like to log it too? [21:02] balloons: pull, and you will see the list of all accounts. [21:03] elopio, I'll pull [21:04] I see something weird here. The ids of the accounts are sequential. They should all be 1, as there's no other account. [21:04] mine show up as 1, and indeed [21:05] elopio, magically I'm seeing things as enabled now [21:05] wtf [21:05] if I put a 10 seconds sleep, they all get the 1 id. [21:05] so I think the account_manager is not getting a new instance. [21:05] we might need to kill signond. [21:06] lookey there, test worked [21:08] elopio, ok, so seems there is a small sleep needed before anabling the service [21:08] the test works and prints enabled if I add a small sleep in _enable_evernote_service [21:16] elopio, that sleep actually is required after the self._join_main_loop(). I suspect you are correct about signond [21:16] a 1 second sleep is enough.. [21:20] elopio, I think I'm happy with a small sleep after you set the credentials and before you start the service [21:20] that seems nicer than stopping and starting things. What do you think? [21:20] I deleted my proposal to merge.. yours has everything we should need [21:20] balloons: even with the sleep I can't make it get all the accounts created to have id = 1 [21:22] elopio, you are only creating one account correct? Are you saying the account id isn't 1 when you run it? [21:23] balloons: test_credentials.py creates 4 accounts [21:23] all of them should have id = 1. [21:23] elopio, ohh, lol.. I'm still stuck on reminders ofc :-) [21:23] * balloons runs [21:25] ok, I see now.. indeed, they aren't all 1 [21:26] two are, two aren't. That's puzzling. [21:26] anyway, I think that you won't need the sleep if I kill the signond. [21:26] yep, I see that. I'll look with you.. my other tests with test_reminders with account look good now [21:27] could you try the branch I'm pushing without the sleep? [21:27] elopio, I agree.. I was arguing in favor of sleeping as opposed to killing the service [21:27] elopio, happy to try whatever [21:27] balloons: well, the service will be killed after 5 seconds of inactivity, according to mardy [21:27] so we are just giving it a quicker dead. [21:27] elopio, :-) ok [21:31] balloons: pushed. [21:32] got it [21:32] elopio, test_credentials run looks the same [21:34] elopio, I'd use subprocess and both check the output of pkill and wait for it to finish [21:34] elopio, can we stop it in a saner manner? it runs with initctl yes? [21:36] hum, you are right. This might not be the way to stop it. [21:37] elopio, so can we say subprocess.call(["stop", "signond"]) [21:37] or we can do a pidof kill -9 [21:38] and do we want to then start it up, using our environment? we can use initctl reset-env [21:38] or shall we assume it starts ok? [21:38] it will be started when we start calling things from gi. [21:38] yes.. just want to make sure it'll have the proper env when called from gi [21:38] stop signond will not work on desktop [21:39] it doesn't work on the phone either [21:40] $ pkill -9 signond works on the phone [21:40] subprocess.call('kill -9 `pidof /usr/bin/signond`') [21:40] mkay, if pkill works on the phone [21:42] balloons: and the problem with subprocess.check_call is that it will fail if the process doesn't exist. [21:44] elopio, we can use check_output if you want to check [21:44] balloons: I don't want to check. Ah, right, call will work. [21:44] :-) [21:45] however, I'm not getting what I want [21:46] weird.. it runs 1, 1, 2, 3 [21:46] heh [21:46] balloons: what do you want. [21:46] ? [21:46] elopio, for all the ids to be 1, as you said :-) [21:46] balloons: yes, I want that too :( [21:46] balloons: but did it work without the sleep? [21:47] my phone doesn't let me run the tests again. [21:47] elopio, no.. it has no effect on anything afaict [21:50] balloons: bah, so I'll just add the sleep between the account creation and the enablement. [21:51] elopio, yea, just after the _join_main_loop seems fine [21:51] but the credentials tests are still concerning [21:51] elopio, no other services running? nothing else that might need to be killed? [21:52] balloons: the other thing that mardy said was that we might be keeping an reference to Accounts.Manager [21:52] that's why we have the weird del statements. [21:54] * balloons watches processes [21:55] I'm concerned about initctl isolation [21:57] mm.. strace shows it's good [21:58] you are setting xdg too [21:58] balloons: pushed with the sleep. [21:59] balloons: I'm not sure what do you mean about initctl. [21:59] elopio, my concerns are unfounded.. looking at the trace it's all good [22:08] balloons: so, should I do something else on this branch? [22:10] elopio, it's better than it was [22:10] I'm not seeing anything else being launched [22:12] ohh you added so much more [22:12] * balloons pulls [22:15] elopio, I found a sleep(1) to be enough, but I guess the sleep(10) is fine [22:16] I'm happy to land it as-is.. There's still some lingering questions, but nothing to hold on [22:17] perfection isn't required :-) [22:18] are you happy? I'll top-approve if so [22:18] balloons: I'm not happy at all because the accounts are not all 1 :D [22:18] but yeah, if it fixes the issue for you, lets land it. [22:19] elopio, I'm ok with landing it, while continuing the fight on accounts not being 1 [22:19] there's some much good logging in it [22:19] balloons: so, just to confirm, now it works for you on the phone and on the desktop? [22:19] you no longer get an account disabled? [22:19] I'm trying the phone again.. it actually broke the phone earlier [22:20] I'm assuming that's fixed and it works again [22:21] bah, it's still happening.. [22:21] what? The account disabled? [22:22] http://paste.ubuntu.com/7702960/ [22:22] no it doesn't launch [22:23] and its attempting to launch the wrong version, which is why it doesn't launch i'll bet [22:23] ohh, nvm that is the right version [22:24] bah the keyfile [22:24] * balloons rebuilds [22:34] balloons: the same happens here. I thought it was my phone going crazy as it works on yours. [22:34] elopio, yea I think the key need to be inserted for phone.. but thats odd === salem_ is now known as _salem [22:37] elopio, yea, see I installed the original pkg back to the device, no dice [22:37] let me try trunk quickly for sanity [22:40] yep trunk starts properly.. I guess we have to blame the branch [22:40] elopio, ^^ [22:44] yep new build with trunks tests also work. [22:44] ( I mean the tests fail, but the app launches properly, etc ;-) ) [22:45] balloons: right, I can see it. I'll try removing some things. [22:47] elopio, it happened before the patch home fixture change.. really it was weird [22:49] elopio, should probably fix this too :-) BaseTestCaseWithTempHome [22:49] err 22:21:21.112 WARNING emulators:26 - The ubuntuuitoolkit.emulators module is deprecated. Import the autopilot helpers from the top-level ubuntuuitoolkit module. [22:50] balloons: what we are doing differently is that we are patching both then env var and the initctl env var [22:50] and it doesn't like it. [22:53] elopio, hehe, I think that's the problem I had with music then as well [22:53] works on desktop, not on phone [22:53] I also had to patch initctl [22:53] and I had to do it before I launched the app [22:54] balloons: well, it means that the patch home fixture is less ready than what I expected. I'll revert that change. [23:03] elopio, can you approve? https://code.launchpad.net/~nskaggs/reminders-app/fix-new-pep8/+merge/224536 [23:05] balloons: done. [23:15] balloons: oh, wait, I read it backwards. Getting color blind here. [23:15] why do you put an empty line between the class and its comment? [23:24] elopio, I noticed autopep8 wants to do that [23:24] i didn't change it back [23:24] I guess I'll undo i [23:25] mmm, no, you are right. [23:25] wait. [23:25] Insert a blank line before and after all docstrings (one-line or multi-line) that document a class [23:25] well the man himself barry doesn't consider autopep8 to be the bible on this [23:25] I didn't know about that one. [23:31] balloons: ok, my branch is ready again. [23:31] app launches, but now I'm getting that libaccounts-glib can't write on tmp. [23:33] ok, let me try it [23:36] (process:31524): accounts-glib-WARNING **: Cannot create directory: /tmp/tmpo52mb_sj/.config/libaccounts-glib [23:45] ok, seems to start just fine [23:59] so elopio on the phone run, the isolation didn't work and thus the app doesn't see the account [23:59] balloons: right. But the account seems to be created properly.