[00:56] <alesage> elopio, I added a line to the automation proposal
[06:27] <pitti> elfy: good to know, thanks!
[06:46] <mgedmin> my periodic attempt to log into iso.qa.ubuntu.com failed again, with the same error: https://bugs.launchpad.net/ubuntu-qa-website/+bug/1418383
[14:10] <balloons> mgedmin, :-(
[14:10] <balloons> mgedmin, do you have a launchpad account?
[14:11] <mgedmin> yes
[14:11] <balloons> can you share?
[14:11] <mgedmin> ~mgedmin
[14:11] <mgedmin> I've been able to log in into iso.qa.ubuntu.com in the past
[14:11] <elopio> balloons: how can we get permissions to change the topic?
[14:11] <mgedmin> now it won't accept me back
[14:12] <elopio> balloons: we will try having a vanguard to answer to automation pings, and would like to put his name on the topc.
[14:12] <elopio> *topic
[14:12] <balloons> mgedmin, http://iso.qa.ubuntu.com/user/logout, then http://iso.qa.ubuntu.com/qatracker?destination=qatracker
[14:12] <balloons> elopio, ahh I have permission
[14:13] <balloons> elopio, for permission for you or for a bot or ?
[14:13] <elopio> balloons: for me, rhuddie, brendand, fgimenez and veebers, so we don't have to ping you everytime we change the vanguard.
[14:14] <balloons> elopio, let's hop over to #ubuntu-irc and see if they can help out
[14:14] <brendand> elopio, don't we just have a group name like ubuntu-qa
[14:14] <mgedmin> balloons, http://iso.qa.ubuntu.com/user/logout is an "Oops!  The resource you tried to access doesn't exist", after which http://iso.qa.ubuntu.com/qatracker?destination=qatracker gives me the front page with a Log In button on the left which continues not to work
[14:15] <brendand> elopio, and manage who is vanguard internally
[14:15] <mgedmin> in the manner described in my bug ("The name mgedmin is already taken")
[14:15] <mgedmin> (after a brief foray into Launchpad's SSO)
[14:15] <balloons> mgedmin, bah :-(
[14:15] <mgedmin> my crystal ball says something's messed up in the database with my user account
[14:15] <elopio> brendand: balloons: that works.
[14:16] <elopio> Instead of: For help with autopilot, try #ubuntu-autopilot
[14:16] <elopio> we can use: For help with automation, ping ubuntu-qa.
[14:16] <balloons> mgedmin, hmm.. Can you auth to other sites using ubuntu sso?
[14:17] <mgedmin> sites like bugs.launchpad.net?  yes
[14:17] <mgedmin> let me try again in an incognito window to remove all doubt
[14:17] <balloons> elopio, brendand sure that's simple I can update it now
[14:19] <balloons> mgedmin, ack
[14:19] <mgedmin> wiki.ubuntu.com -> login -> login.ubuntu.com: username, yes returning user here's my pw -> four checkboxes (tz fullname username email) -> looong timeout :/
[14:20] <balloons> mgedmin, so something might be up with you lp account then?
[14:20] <mgedmin> bugs.launchpad.net -> login -> login.launchpad.net: username, yes returning user here's my pw -> two checkboxes (fullname email) -> I'm logged in
[14:20] <balloons> elopio, look good?
[14:20] <mgedmin> and wiki.ubuntu.com _finally_ loaded and I'm logged in
[14:21] <elopio> balloons: without the #
[14:21] <mgedmin> iso.qa.ubuntu.com -> login -> login.ubuntu.com: (skips 1st page, shows the 2nd) two checkboxes (username email) -> iso.qa.ubuntu.com: "account registration failed: the name mgedmin is already taken"
[14:22] <mgedmin> it's as if I somehow have an account with iso.qa.ubuntu.com, but it's not linked to my launchpad openid
[14:22] <elopio> thanks balloons.
[14:22] <balloons> yw
[14:38] <elfy> mgedmin: that sounds to me like maybe you've got more than 1 sso account - see the same from people having issues logging into forum from time to time
[14:38] <elopio> fgimenez: brendand: rhuddie: do you have the ubuntu-qa highlight in your IRC clients?
[14:39] <brendand> elopio, i do
[14:39] <jibel> elopio, that's annoying
[14:39] <rhuddie> elopio, yes i do
[14:39] <elopio> jibel: that will be the vanguard highlight.
[14:39] <mgedmin> elfy, I have only one launchpad account, but I have two email addresses associated with it
[14:39] <jibel> too many notifications kills notifications, if you could choose another highlight
[14:40] <elfy> mgedmin: not talking about LP - but at login.ubuntu.com
[14:40] <balloons> elopio, true.. perhaps including vanguard in the highlight would be better
[14:40] <elopio> jibel: I would prefer for everybody to read when we get automation questions. Anybody from QA can reply, actualy.
[14:41] <mgedmin> elfy, is login.ubuntu.com the same as login.launchpad.net?  I get confused about these
[14:41] <elopio> the vanguard will just make sure that no pings go unanswered.
[14:41] <mgedmin> I signed up for a launchpad.net account years ago, before it even implemented an openid provider AFAICR
[14:41] <davmor2> elopio: I do and you ping me without cause again and I'm gonna hunt you down ;)
[14:41] <mgedmin> I'm guessing my account got migrated to the new sso infrastructure together with the rest
[14:41] <jibel> elopio, many people in the QA team cannot help with automation
[14:41] <elopio> davmor2: just saying hi.
[14:42] <jibel> and they get pinged
[14:42] <davmor2> elopio: you need a projects-team or qa-automation tag
[14:43] <elopio> jibel: I think that's a problem. Everybody from QA should be able to look at the logs at least, and from there know who to ping to get help, at least.
[14:44] <jibel> elopio, yeah, but people are busy with other stuff and cannot just stop everything when they are pinged about something they don't directly work on
[14:45] <elopio> jibel: that applies for everybody in the team, nobody is directly working on answering questions. So we need to share the load.
[14:45] <elopio> I think that this is not only a projects team job. We can be the main point of contact and reply to most of the questions, but I would like all the team to be involved and learn about reading logs and debugging errors.
[14:46] <elopio> but well, your opinion was heard. we'll talk about it on our standup.
[14:51] <elopio> we can change it to qahelp, and encourage everybody to get it as a highlight. But leave it optional.
[14:51] <elopio> I don't like the optional part :)
[14:52] <fgimenez> elopio: didn't have it, already set up
[14:53] <elopio> pitti: I haven't found the autopkgtest file that backs up the directory in /tmp and restores it. Any pointers?
[14:53]  * mgedmin afk
[14:58] <pitti> elopio: how do you mean "file"? that's done by adt-run itself
[14:59] <elopio> pitti: I would like to read the source file that does it.
[14:59] <pitti> elopio: lib/VirtSubproc.py, cmd_reboot()
[14:59] <elopio> thank you.
[15:00] <pitti> elopio: the actual mechanics of rebooting the testbed is left to the virt-runner-* implementation; that's the common code for saving/restoring
[15:00] <elopio> pitti: from your last email, only the reboot target won't work because we also need to reenable ssh.
[15:00] <elopio> unless we reenable ssh on every reboot, even when not needed.
[15:01] <pitti> elopio: yeah, I'm just doing that
[15:01] <pitti> elopio: you can't reenable ssh from the test itself
[15:01] <pitti> as that's running on the testbed, so you need ssh to run it :)
[15:02] <elopio> pitti: ah, of course :)
[15:02] <elopio> that's me uninstalling openssh-server in my remote server all over again.
[15:04] <pitti> elopio: hm, not sure if we ever had a rebooting test on touch
[15:05] <pitti> after reboot, adb is locked again
[15:05] <pitti> and you can't unlock it programmatically
[15:05] <pitti> as it needs unlocking the screen to re-enable adb
[15:05] <pitti> another one of ogra's lockdowns
[15:05] <elopio> pitti: it's working for me.
[15:05] <elopio> I flashed my krillin yesterday with vivid.
[15:05] <pitti> adb fails with "error: closed" right after (re)booting
[15:05] <pitti> you need to unlock the screen once, then it comes online
[15:06] <elopio> pitti: veebers had something similar, and he said: sudo touch /userdata/.adb_onlock
[15:07] <pitti> elopio: oh! that sounds like something which should go into the setup script, too :)
[15:07] <elopio> it hasn't happen to me.
[15:07] <pitti> it does to me, and it's by design; you're sure you dno't have that stamp file?
[15:08] <elopio> pitti: yes, I have it.
[15:08] <elopio> maybe it's added when I flash with developer-mode?
[15:08] <elopio> I did a --wipe yesterday, and didn't add it myself. I'm sure of that.
[15:09] <pitti> yeah, could be
[15:09] <pitti> I can't do that (dual boot)
[15:14] <elopio> barry: what if the dbus Apply script that you had in your mind calls /tmp/autopkgtest-reboot rebooted-mark and we leave the backup, restore, and wait until booted to adt ?
[15:15] <elopio> we could call /sbin/reboot -f recovery through the reboot command file. Or if that part is not critical, we can call adb reboot recovery with the target file.
[15:18] <elopio> ah, I see your last email. I don't fully understand the Applied signal, I thought we just needed to wait for the test to boot.
[15:18] <elopio> but that wait can be added to the test, I see no problem there.
[16:09] <pitti> elopio: the adb script now does /userdata/.adb_onlock, thanks for pointing out!
[16:29] <elopio> thanks to you pitti.
[16:32] <elopio> brendand: meeting
[16:58] <elopio> balloons: I have a meeting now with ci to talk about tests. So I can't attend the core apps one.
[17:00] <balloons> elopio, ack
[18:27] <elopio> jfunk: my main wish for the next MIR sprint is a mir virtual frame buffer.
[18:27] <elopio> https://bugs.launchpad.net/mir/+bug/1239872
[18:27] <elopio> reported more than a year ago. I really need it now.
[19:11] <jfunk> elopio: ack, let's see what I can do
[19:11] <jfunk> elopio: can you tell me a little bit what that is blocking in terms of test development
[19:24] <elopio> jfunk: all our test suites are slow, so when we run them in the same machine that we are programming, we have to wait until the tests finish. With a vfb, we could run the tests without losing control of the machine.
[19:24] <elopio> when running tests in a virtual test bed, we want to have the minimum requirements installed on that test bed. We don't want a full unity install in there if we don't need it. But in order to test things like trusted sessions and url-dispatcher, we need mir.
[19:24] <elopio> and if we run the tests that don't require mir in a x11 virtual frame buffer, we might miss issues that appear only when using mir.
[19:25] <elopio> jfunk: in this example, I want to test that I can open the messaging app from the dialer app. That needs url dispatcher and url dispatcher needs mir.
[19:26] <elopio> that's another item to add to somebody's backlog: Make url dispatcher work without mir. I'm asking who should do that.
[19:26] <elopio> I think unity apis.
[20:34] <elopio> veebers: do you like the cat empire?
[20:34] <elopio> that's from around the corner from your house.
[20:36] <veebers> elopio: uh, what? :-P I'm not sure what you're talking about sorry
[20:40] <elopio> veebers: https://www.youtube.com/watch?v=eiY3xMM4DSk
[20:54] <veebers> elopio: ah a bad, awesome. that statement that it was around the corner of my house confused me :-)
[20:55] <veebers> s/bad/band/
[20:55] <veebers> cool, thanks for the suggestion, I'll hit it up in spotify and give it a listen
[22:08] <wxl> pitti: so playing with systemd. installed systemd-sysv, which removed upstart as it was supposed to. however, upstart-bin is still hanging around and upstart is still being run. is that to be expected?
[22:11] <gQuigs> wxl: upstart's still used for the user session I believe
[22:11] <gQuigs> and I think there was going to be a boot option to revert to upstart
[22:12] <gQuigs> wxl: is it being run as: upstart --user ?
[22:13] <wxl> gQuigs: yep. there are some other upstart processes run, too.
[22:13] <wxl> gQuigs: i pointed that at pitti because i was thinking ahead to his FFe
[22:14] <wxl> gQuigs: others are upstart-event, upstart-dbus-bridge, and upstart-file-bridge
[22:15] <gQuigs> they should all have --user in them though right? and all should be under your user account
[22:15] <wxl> gQuigs: so is upstart going to be used for the user session ad infinitum?
[22:15] <wxl> gQuigs: yeppers. well. not upstart-event-bridge.
[22:16] <wxl> …but i think that makes sense
[22:16] <gQuigs> odd... I don't seem to have upstart-event-bridge
[22:17] <wxl> gQuigs: also a part of upstart-bin
[22:17] <gQuigs> ps -p1 shows systemd right?
[22:17] <wxl> yeppers
[22:18] <gQuigs> wxl: but yea, I think the long term goal is to move the user session too, but there isn't a rush for it (and I'm 90% sure it's out of scope for vivid)
[22:18] <wxl> okie dokie
[22:18] <wxl> thanks a bunch gQuigs :)
[22:18] <gQuigs> sure :)
[22:19]  * gQuigs now why don't I have event-bridge.... hmm
[22:19] <wxl> gQuigs: fwiw this is a fairly old vivid lubuntu that's been updated and then systemd-sysv added
[22:20] <wxl> s/updated/dist-upgraded/
[22:21] <wxl> ymmv with a newer vivid
[22:21] <wxl> i doubt that tho
[22:21] <gQuigs> interesting it's own the blueprint (https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration)  "
[22:21] <gQuigs> [xnox] port away from events-bridge / :sys:* events usage: DONE"
[22:22] <wxl> and i doubt that being lubuntu would make a difference
[22:22] <gQuigs> it's on
[22:22] <gQuigs> worth testing...
[22:23]  * wxl checks to see if the blueprint covers user sessions
[22:23] <gQuigs> wxl: under see also: https://blueprints.launchpad.net/ubuntu/+spec/core-1403-session-init-systemd-migration
[22:24] <wxl> danke gQuigs
[22:39] <barry> o/
[23:00] <veebers> Hi barry o/
[23:00] <veebers> barry: query, are there any good green cards to pick up that won't impede you at all?
[23:02] <barry> veebers: hi.  yep, you could take "script to ensure system-image-dbus is not yet running"
[23:02] <barry> veebers: i'll add some comments to the card
[23:03] <veebers> barry: awesome thanks. I'll pick it up and hit it today :-)