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