[00:42] <bfiller> robru: seems to be some problem with the publishing on silo 4
[00:42] <bfiller> with notes-app?
[01:18] <robru> bfiller, oh hey, sorry, was running some errands. indeed it looks like nobody bothered to build notes-app. building it now
[01:18] <bfiller> robru: cool, thanks
[01:19] <robru> bfiller, you're welcome
[01:34] <robru> but queuebot I just built notes-app!
[01:54] <dobey> is it just me, or is jenkisn broken on arm?
[01:56] <robru> dobey, which jenkins are you referring to?
[01:56] <dobey> robru: https://jenkins.qa.ubuntu.com/job/pay-service-utopic-armhf-ci/25/console
[01:57] <dobey> looks like maybe the vm/chroot it's using got left in an unclean state?
[02:00] <robru> dobey, hmmm maybe fginther knows more about that one, sorry ^
[02:04] <imgbot> [03:34] <imgbot> [03:34] <imgbot> [03:39] <bfiller> robru: publish for silo 4 yet?
[07:06] <popey> http://people.canonical.com/~ogra/touch-image-stats/111.changes is 0 bytes long.. ogra_ ?
[07:08] <seb128> popey, it's a stable image :p
[07:09] <popey> haah
[08:06] <asac> plars: psivaa: health-check tests are not run anymore? dont see results on mako for last two images
[08:07] <psivaa> plars: there is one ongoing now. i saw one of the earlier builds failed to flash with some network error between our server and system-image-server
[08:07] <asac> thanks for checking this out .... not sure if we could improve the dashboard to always have an entry for health-check
[08:07] <asac> so we always spot if the test doesnt run etc.
[08:07] <asac> thanks
[08:08] <asac> psivaa: was that for me? :)
[08:08] <psivaa> asac: yea, it was. sorry
[08:08] <asac> hehe
[08:08] <asac> ok cool
[08:08] <psivaa> still waking up :)
[08:08] <asac> me too :P
[08:09] <psivaa> asac: i'll ask if it's possible include a placeholder for health check in the dashboard
[08:09] <ogra_> popey, fixed, sorry
[08:13] <ogra_> stgraber, only core-devs have access to build images  iirc ...
[08:13] <popey> thanks ogra_
[08:18] <ogra_> ugh, the browser4 does not look happy
[08:18] <ogra_> -4
[08:19] <ogra_> cant find its toolbar it seems
[08:27] <sil2100> Yeah, he's not only not happy, he looks pissed off real nice
[08:28] <brendand> sil2100, it's really frustrating. *still* not reproducible locally
[08:29] <brendand> sil2100, ever
[08:29] <sil2100> ;/
[08:29] <sil2100> At least we know that Mir didn't cause any of those regressions, because we had that Mir-specific image that was rather fine
[08:30] <popey> will be late, doorbell
[08:30] <brendand> sil2100, 110?
[08:30] <sil2100> Yes
[08:38] <Chipaca> robru: thank you :)
[08:38] <Chipaca> ogra_: liar liar pants for hire :D
[08:39] <Chipaca> plants*
[08:40] <ogra_> heh
[08:41] <ogra_> oh, crap,, i didnt write the endorsement ...
[08:41]  * ogra_ blushes
[08:42] <Chipaca> ogra_: :)
[08:58] <thostr_> sil2100: when can we expect silo 4 packages published so that we are really unblocked to build the other silos
[09:00] <popey> Saviq: I understand you had a super new landing with new suru icons for some of the system apps?
[09:00] <ogra_> thostr_, once the clicks have been produced and landed for the apps in there
[09:00] <popey> Saviq: the apps which are click packages need uploading to the store, because some of your changes aren't going to land in the phone image otherwise.
[09:00] <Saviq> popey, yeah I know
[09:01] <Saviq> popey, it only landed (not completely yet) this morning
[09:01] <popey> ok. xnox can probably help you upload the clicks.
[09:01] <popey> ah okay ☻
[09:01] <popey> super
[09:01] <Saviq> popey, I'll leave it to bfiller, not sure how they build the clicks
[09:03] <ogra_> Saviq, hmm, we wanted to build an image with the changes before landing other stuff ...
[09:03] <Saviq> ogra_, I really dunno how they build the clicks :|
[09:03] <ogra_> (i guess we need to re-work the landing process a bit that clicks land alongside in the future)
[09:04] <ogra_> Saviq, there should be a jenkins build somewhere afaik
[09:04] <ogra_> (now dont ask me where :P )
[09:04] <Saviq> ogra_, where?
[09:04] <ogra_> hah
[09:05] <Saviq> ogra_, anyway
[09:05] <Saviq> ogra_, the app changes are minimal
[09:05] <Saviq> ogra_, just the icons
[09:05] <ogra_> well, do they still work with the old ones after the trheme switch ?
[09:06] <Saviq> ogra_, yeah, the old theme is a fallback for the new one
[09:06] <ogra_> sil2100, ^^^
[09:06] <popey> Saviq: i know where ☻
[09:06] <ogra_> so i guess we could start an image build and just live with the old icons til the clicks land
[09:06] <ogra_> oh
[09:06] <popey> http://s-jenkins.ubuntu-ci:8080/view/click/
[09:06] <popey> which specific apps and I'll get you clicks
[09:07] <Saviq> popey, https://launchpad.net/~ci-train-ppa-service/+archive/landing-004
[09:07] <Saviq> {address-book,camera,dialer,gallery,messaging,notes}-app
[09:07] <popey> not all of those are clicks
[09:07] <popey> only camera, gallery, notes
[09:07] <Saviq> popey, yup, we only need those
[09:08] <popey> ok, will get them for you
[09:08] <sil2100> thostr_: we're working on getting them migrated stilll, but I suppose around noon it should be all ok
[09:08] <Saviq> rsalveti, we got a regression in autopkgtest for uitk-gles
[09:08] <popey> oh, hang on
[09:08] <popey> these changes haven't landed in trunk? jenkins wont do that
[09:08] <popey> needs bfiller..
[09:08] <sil2100> ogra_, Saviq: good to know this
[09:09] <Saviq> popey, yeah, the silo didn't land yet
[09:09] <ogra_> sil2100, hmm, didnt you add code that prevents landing of unmerged changes ?
[09:09] <Saviq> popey, blocked in proposed
[09:09] <ogra_> oh just not merged back
[09:09] <ogra_> k
[09:09] <ogra_> what is blocking it ?
[09:10] <sil2100> ogra_: I added code that prevents landing unapproved changes
[09:10] <psivaa> sil2100: https://bugs.launchpad.net/ubuntu/+source/urfkill/+bug/1337227 is the rfkill crash bug
[09:10] <sil2100> psivaa: thank you!
[09:10] <psivaa> yw :)
[09:11] <Saviq> ogra_, uitk-gles
[09:11] <ogra_> rsalveti, ^^^
[09:11] <Saviq> ogra_, it's uploaded already
[09:12] <ogra_> oh ok
[09:12] <Saviq> ogra_, but there's a regression in one of the autopkgtests
[09:12] <Saviq> but from what I can see it could just use a re-run if possible
[09:12] <Saviq> 'cause it's some timing issue (and passed on i386)
[09:12] <ogra_> right i see that
[09:13] <ogra_> who can re-run these ? release team ?
[09:13] <Saviq> pitti seems to have already done so
[09:13] <Saviq> http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/76/console
[09:13] <ogra_> oh, cool
[09:13] <Saviq> yeah, it's a flaky test
[09:13] <Saviq> autopkgtests and flaky tests is nasty
[09:14] <ogra_> definitely :/
[09:15] <Saviq> fail again :|
[09:16] <ogra_> sigh
[09:16] <brendand> psivaa, what are you going to modify, so i know what to give you. is it what's under /home/phablet/autopilot/?
[09:17] <psivaa> brendand: let me check where webbrowser tests are copied to in the device when running the tests
[09:20] <psivaa> brendand: /usr/lib/python3/dist-packages/webbrowser_app/tests/
[09:20] <Saviq> SUCCESS
[09:20] <Saviq> ogra_, bug #1336650 btw
[09:21] <ogra_> Saviq, https://code.launchpad.net/~elopio/ubuntu-system-settings-online-accounts/clean_tests/+merge/225437
[09:21] <ogra_> perhaps ?
[09:22] <brendand> Saviq, those aren't flaky, they're downright broken
[09:22] <Saviq> brendand, yeah, sure :)
[09:22] <brendand> Saviq, me and elopio were looking at them yesterday
[09:23] <Saviq> brendand, just looking at elopio's MP
[09:26] <brendand> psivaa, ok you need to replace the __init__.py there with this: http://paste.ubuntu.com/7741088/
[09:27] <psivaa> brendand: ok, let me first run webbrowser on a separate device and then copy this over
[09:39] <rsalveti> Saviq: it seems it's all sorted out already, right?
[09:40] <Saviq> rsalveti, yes
[09:40] <Saviq> rsalveti, as you were
[09:41] <Saviq> looks like it should migrate real soon
[10:14] <psivaa> brendand: the tests failing still with the ^ __init__.py : http://q-jenkins.ubuntu-ci:8080/job/psivaa-utopic-touch-mako-smoke-daily-webbrowser/4/console
[10:18] <brendand> psivaa, ok
[10:59] <brendand> sil2100, i reproduced a web browser failure!
[10:59] <sil2100> brendand: HOLY SH..!
[10:59] <sil2100> brendand: how?
[10:59] <brendand> sil2100, it happens if the orientation is wrong
[11:00] <sil2100> ah ha! So it's related to the thing ogra_ mentioned?
[11:00] <brendand> sil2100, the phone was flat but when AP launched the browser it was landscape
[11:00] <sil2100> Ah
[11:00] <sil2100> hm
[11:00] <brendand> sil2100, didn't he say it only stayed like that temporarily?
[11:00] <ogra_> it flicks for a moment
[11:00] <ogra_> but i'm holding it in portrait while that happens
[11:02] <brendand> ogra_, no this is lying flat, and it's stuck the whole time on landscape
[11:02]  * popey notes the FirefoxOS lab has all their phones upside down it seems. http://imgur.com/a/eOIeu
[11:02] <ogra_> right, might be the same but i'm not seeing it because i hold it in portrait where it immediately switches to
[11:02] <popey> which is odd
[11:03] <brendand> ogra_, when i ran it locally in the morning it stayed in portrait. i wonder why not it suddenly wants to be in landscape?
[11:04] <brendand> ogra_, except where i hold it up in front of me
[11:04] <brendand> ogra_, then it stays portrait
[11:04] <ogra_> right
[11:04] <ogra_> and for me it sometimes flicks half way into landscape and flicks back immediately
[11:04] <brendand> but if i lay it flat, right now it is always in landscape
[11:05] <brendand> so why can't the toolbar be revealed in landscape? surely that's a bug
[11:05] <ogra_> as i said, ricmm knows about it and will look after the sprint ... not sure if we can do much on our side here
[11:05] <ogra_> because where the toolbar would be the shell has either the launcher or the app selector
[11:06] <brendand> ah yes
[11:06] <ogra_> and overrides ...
[11:06] <brendand> ogra_, so we need to talk to the lab people and try and make sure the devices are standing
[11:06] <brendand> and not take any excuses about 'we might not catch orientation related bugs'
[11:07] <ogra_> well, we need ricmm to make the rotation use the device default on app startup
[11:07] <ogra_> as the proper fix
[11:07] <ogra_> but yeah, having them upright might work around it for now
[11:07] <sil2100> ;)
[11:08] <brendand> sil2100, ogra_ - at least we know why now :)
[11:08] <ogra_> yeah
[11:08] <sil2100> Yeah...
[11:08] <brendand> i'll raise a webbrowser-app bug
[11:13] <Saviq> seb128, is there anything else blocking silo 4 in proposed?
[11:14]  * Saviq has no idea where to look
[11:14] <brendand> https://bugs.launchpad.net/webbrowser-app/+bug/1337284, for the landing email
[11:14] <sil2100> I just checked and it seems to make ubuntu-touch uninstallable
[11:14] <sil2100> Saviq: ^
[11:14] <sil2100> so hmmm
[11:14] <brendand> I still feel like there might be some other issues with webbrowser app, but we need to get that one out of the way to make it easier to diagnose the others
[11:14] <seb128> Saviq, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt still lists ubuntu-touch unhappy in i386/amd64
[11:15] <seb128> let me try in a pbuilder
[11:17] <Saviq> pbuilder? you're so 2010
[11:18]  * sil2100 is also using pbuilder
[11:18] <sil2100> What is the new hip way?
[11:18] <sil2100> ;)
[11:20] <seb128> Saviq, bah
[11:20] <Saviq> sil2100, schroot/sbuild
[11:21] <seb128> Saviq, the issue is unity8
[11:21] <seb128> +               qtdeclarative5-ubuntu-ui-toolkit-plugin (>= 0.1.48),
[11:21] <seb128> on i386 qtdeclarative5-ubuntu-ui-toolkit-plugin-gles Provides qtdeclarative5-ubuntu-ui-toolkit-plugin
[11:21] <seb128> but provides are not versionned
[11:21] <Saviq> seb128, ugh
[11:21] <Saviq> so |
[11:22] <seb128> so it can't resolve the >= requirement
[11:22] <Saviq> seb128, can you upload a fixed package directly? I'll merge back to trunk
[11:22] <seb128> Saviq, yep, seems to be what rsalveti did to other components
[11:22] <seb128> Saviq, unity8? sure
[11:23] <Saviq> seb128, ubuntu-settings-components has the same
[11:23] <seb128> Saviq, k, doing that as well
[11:23]  * Saviq looks through the other merges
[11:24] <psivaa> brendand: so i'll release the device to the pool that i allocated to webbrowser testing?
[11:25] <brendand> psivaa, i don't know what that means :)
[11:26] <sil2100> ;)
[11:26] <brendand> psivaa, which device, which pool?
[11:26] <Saviq> seb128, yeah, that's it
[11:26] <psivaa> brendand: ohh?
[11:26] <psivaa> brendand: i was allocating a device to run this specific webbrowser test with your changes,
[11:27] <psivaa> brendand: that's what i said in the meeting
[11:27] <brendand> psivaa, oh yes - we don't need that anymore
[11:27] <psivaa> brendand: so out of curiousity.. if lying flat is causing the failure.. how comes you are not able to reproduce?
[11:27] <brendand> psivaa, i am now
[11:27] <psivaa> ok
[11:27] <brendand> psivaa, it's not lying flat itself. it's running in landscape mode
[11:28] <brendand> psivaa, but for some reason, when lying flat, it will launch in landscape mode some/most of the time
[11:29] <seb128> Saviq, http://paste.ubuntu.com/7741516/ ?
[11:29] <psivaa> brendand: ok, was wondering how missed that before :)
[11:29] <Saviq> seb128, yeah
[11:29] <seb128> Saviq, looks good to you?
[11:29] <seb128> great, uploading
[11:30] <brendand> psivaa, yeah i'm not sure either
[11:31] <brendand> psivaa, here's what's stranger. when i launch it from the shell it launches in portrait mode, but the test launches in landscape
[11:33] <psivaa> brendand: ohh? i assume AP does not enforce that?
[11:33] <seb128> Saviq, u-s-c uploaded as well, let's see how that goes
[11:33] <Saviq> seb128, thanks
[11:33] <seb128> yw!
[11:33] <brendand> psivaa, i think i might have an idea why. still doesn't explain everything though
[11:34] <psivaa> brendand: ack, leaving it to you :), good that you're able to repro locally
[11:34] <brendand> my thoery was wrong :)
[11:48] <brendand> ogra_, if you sit the device even a little bit up, like resting it on the edge of the laptop (mine is quite thin anyway), then it never opens in landscape
[11:48] <brendand> ogra_, so literally they just need to put a little phone-pillow in the lab for each device :)
[11:51] <ogra_> heh
[11:51] <ogra_> well, for me it still does half a rotation sometimes
[11:53] <brendand> ogra_, when you sit it up?
[11:53] <ogra_> when i hold it upright and start a webapp
[11:54] <ogra_> or the browser
[11:54] <brendand> ogra_, i haven't gone near web-apps yet
[11:54] <ogra_> it doesnt happen every time, but often enough to notice throughout the day
[12:37] <cjwatson> mind if I assign a silo for line 44?  should be able to land it fairly quickly
[12:43] <camako> Is there a way to perform conflict-free merge of the changelog? I.e. Developers mod the changelog at/around the same location, and when their MPs get merged to trunk, they could step on each others' toes. Any pointers?
[12:51] <mvo> cjwatson: if you give me ~10min I can fix the branch for the hook test otherwise I can assign it
[12:51] <cjwatson> mvo: oh, sure, go ahead.  (and I can assign too :) )
[12:52] <sil2100> mvo: hey! Maybe you could assign a silo for cjwatson? :)
[12:53] <sil2100> And there seems to be one package for publishing which you could try
[12:53] <mvo> cjwatson: I need to learn it, I'm on landing team duty now
[12:55] <cjwatson> mvo: aha
[12:57] <mvo> cjwatson: branch updated
[12:57] <mvo> sil2100: let me find out which one that is :)
[12:58] <sil2100> cjwatson: ah! You didn't set it to Ready: Yes! ;p
[12:58] <cjwatson> sil2100: how do I do that?  just type in the third column?
[12:58] <cjwatson> but that says "auto-updated, do not touch"
[12:58] <sil2100> cjwatson: no no, there's column I entitled "Ready(...)"
[12:58] <sil2100> cjwatson: you need to set it to 'Yes' there :)
[12:59] <sil2100> Once it's set like that, the landing team will be able to see it (and will get pinged by the CI Train choo choo as well)
[13:00] <cjwatson> sil2100: oh, away off to the right
[13:02] <sil2100> Yeah, hidden from evil eyes
[13:02] <cjwatson> prodded
[13:02] <sil2100> mvo: could you try assigning a silo?
[13:03] <pmcgowan> sil2100, seb128 qofono has landed, can we move on Ken's branch now?
[13:03] <sil2100> \o/
[13:03] <mvo> sil2100: sure, givem me  sec
[13:03] <sil2100> pmcgowan: where's the branch?
[13:03] <seb128> pmcgowan, we can yes, it just needs somebody with free slots to pick that up I guess
[13:03] <seb128> e.g not me today
[13:03] <seb128> but I can have a look tomorrow
[13:04] <cjwatson> mvo: I'll just merge that before I hit build then
[13:04] <mvo> cjwatson: cool, thanks, I assign a silo now
[13:04] <pmcgowan> seb128, we are off in the US tomorrow otherwise I could test, but I ran his branch for two weeks prior
[13:05] <seb128> pmcgowan, ok, thanks, that's useful testing info
[13:07] <bregma> sil2100, could I get you to look at https://code.launchpad.net/~bregma/cupstream2distro/lp-1321755/+merge/225467 -- that bug is very high priority for us
[13:07] <mvo> cjwatson: your silo is assigned now
[13:08] <sil2100> bregma: ACK, taking a look now
[13:09] <cjwatson> mvo: ta
[13:15] <Saviq> sil2100, does the publication-migration job consider newer packages that go into destination, or does it require == version?
[13:17] <sil2100> Saviq: it's looking for == version...
[13:17] <Saviq> sil2100, ok, so we'll have to force M&C
[13:17] <Saviq> "accepted: unity8"
[13:17] <sil2100> Saviq: ah, since you published a new unity8, right?
[13:17] <Saviq> YES
[13:17] <sil2100> Yeah
[13:17] <sil2100> :>
[13:18] <Saviq> sil2100, yeah, we pushed fixed packaging
[13:18] <Saviq> directly to distro
[13:18] <Saviq> didn't want to delay any longer
[13:18] <sil2100> Right
[13:20] <Saviq> sil2100, seb128, it says "Pending" into release here https://launchpad.net/ubuntu/+source/unity8/7.90+14.10.20140701.2-0ubuntu2/+publishinghistory
[13:20] <Saviq> sil2100, can I M&C?
[13:20] <seb128> Saviq, you can m&c
[13:21] <Saviq> WHOO HOO HOO HOOOOO
[13:21] <sil2100> Saviq: I would say it's a good time now for this, yes!
[13:21] <seb128> Saviq, well done ;-)
[13:21] <Saviq> I can push a button! I can push a button!
[13:22]  * Saviq needs therapy
[13:22] <Saviq> popey, stuff's pushing to trunk now, will jenkins click pick them up automagically?
[13:22] <Ursinha> josepht: did I start vanguard earlier than I should?
[13:23] <popey> Saviq: if not, I can poke it to build them
[13:23] <josepht> Ursinha: I think so
[13:23] <Saviq> popey, it's pushed, so you might as well
[13:23] <Ursinha> josepht: oops :) doing this almost everyday is confusing hehe, sorry
[13:23] <josepht> Ursinha: no worries :)
[13:24] <popey> Saviq: all of them? camera, gallery, notes?
[13:24] <Saviq> popey, yes
[13:25] <popey> Saviq: all building now
[13:26] <Saviq> popey, rad
[13:26] <davmor2> sil2100: in your next email can you move the ringer bug out of the blocker section and into the other section, and the dialer app issue I hav e confirmed I can not reproduce on 111 so might of been a glitch in an image but seems fine now :)
[13:26] <Saviq> the funny thing in "rad" is it means "happy" in PL as well ;)
[13:27] <Saviq> only not as extremely
[13:28] <dbarth> o/ hi, can i have a silo for line 45?
[13:28] <popey> I did think we'd stepped into the 80's.
[13:29] <davmor2> popey: I've seen you cartoon and music tastes you never left the 80's, same as me ;)
[13:30] <popey> heh
[13:31] <mvo> dbarth: sure
[13:34] <mvo> dbarth: you should have landing-018
[13:45] <davmor2> bfiller: I confirmed I couldn't reproduce the issue with the dialer app in 111 so marked it invalid
[13:45] <bfiller> davmor2: good
[13:49] <sil2100> bregma_: ok, I'm checking out the branch right now and it seems more or less ok, although I think there can be multiple commiters and authors, yes?
[13:49] <sil2100> bregma_: Didier was splitting that by ','
[13:50] <sil2100> But I'm not sure now if that's a real case in bzr
[13:53] <Laney> that's a nice settings landing ;-)
[13:53] <bregma> sil2100, mm, I had thought about that case and I see I forgot about it in my solution, let me go back and think for a bit again
[13:58] <davmor2> mvo: this seems somehow appropriate https://www.youtube.com/watch?v=we7UfubNeqM
[14:10] <popey> Saviq: http://people.canonical.com/~alan/clicks/
[14:11] <popey> Saviq: if those three clicks match the bzr revs you want uploaded, then ping balloons and he can upload to store for you ☻
[14:15] <mvo> davmor2: hehe, yeah, also we play different music now it seems :)
[14:15] <Saviq> popey, balloons, it's good, please upload
[14:15] <Saviq> ogra_, do we need to upload anywhere else or is store enough for preinstalled?
[14:16] <ogra_> Saviq, sergiusens usually cares for landing clicks ...
[14:16] <ogra_> iirc he needs to update a list
[14:16] <sergiusens> Saviq: ogra_ I don't take care of the daily landing of clicks; each owner does that now
[14:16] <davmor2> mvo: well r 'n' b and rock 'n' roll they both got 'n' s in the middle so they can't be that different right?
[14:17] <sergiusens> I only add/remove from the image and help when it comes to it.
[14:17] <ogra_> sergiusens, ah, so click_list is updated automatically ?
[14:17] <mvo> davmor2: :)
[14:17] <Saviq> sergiusens, ok, I'll ping bfiller
[14:17] <balloons> Saviq, popey which clicks?
[14:17] <sergiusens> ogra_: if it's approved in the store; yes
[14:17] <Saviq> balloons, http://people.canonical.com/~alan/clicks/
[14:17] <sergiusens> Saviq: what do you need?
[14:17] <popey> the three there
[14:17] <popey> balloons: ^
[14:17] <Saviq> sergiusens, ↑↑
[14:17] <Saviq> ↑
[14:17] <sergiusens> Saviq: ah, balloons is taking care
[14:18] <bfiller> Saviq: we'll be release gallery and camera clicks today, so no need for you guys to do it
[14:18] <bfiller> about to land some changes on those
[14:18] <popey> heh
[14:18] <popey> balloons: ignore us.
[14:19] <balloons> popey, done.. :-)
[14:19] <bfiller> balloons: you can do notes-app if you don't mind
[14:19] <bfiller> I'm not touching that one
[14:20] <Saviq> bfiller, FWIW ogra_ wanted an image with just the suru switch
[14:20] <ogra_> well, the landing team did :)
[14:21] <ogra_> i only spoke up :)
[14:21] <sil2100> ;)
[14:22] <bfiller> Saviq, ogra_ : up to you guys, we are going to land some silos today regardless and don't really want to delay
[14:22] <balloons> popey, "You don't have permission to access /~alan/clicks/com.ubuntu.notes_1.4.272_armhf.click on this server."
[14:22] <Saviq> bfiller, I don't think it affects you in any way
[14:23] <Saviq> bfiller, it's just a question whether there will be the interim (new icon only) versions in the next image or not
[14:23] <Saviq> ogra_, ↑ your call guys
[14:24]  * Saviq hates queuebot for resizing my window all the tie
[14:24] <Saviq> time
[14:24] <ogra_> Saviq, bfiller, well, i dont reallly care for that specific image, what i do care for is that our landing process is broken, the silo should never have landed without the clicks being available alongside, we need to redefine the policy here ... i suspect the icon updates wont cause issues anyway
[14:25] <popey> balloons: hang fire
[14:26] <stgraber> Saviq: I just dropped printing the old status so that should save some space, I'll also switch it to printing less stuff and shorter status messages using the new state values introduced by sil2100 yesterday
[14:28] <Saviq> ogra_, that's agreed
[14:28] <Saviq> stgraber, it's actually just the name "-queuebot/#ubuntu-ci-eng-" that causes the handle column to resize
[14:29] <Saviq> stgraber, so it's probably xchat-gnome's fault
[14:29] <cjwatson> Make your client handle notices better, indeed :)
[14:29] <ogra_> bfiller, Saviq, the impression in the landing meeting this morning was that everything was landed so we decided to have a stop gap image build ... when we decided that we didnt know something was stuck in proposed and the clicks werent there, i dont think that image is overly important
[14:30] <stgraber> Saviq: ah, right, some IRC clients do that for notices
[14:30] <ogra_> Saviq, just ise a non-castrated xchat then ;)
[14:30] <cjwatson> Mine has a similar display for notices, but it doesn't try to align the start of everybody's text to the same left margin
[14:30] <bfiller> ogra_: yes we really need clicks to be released by the silo
[14:30] <stgraber> Saviq: irssi doesn't have that problem (by not printing a user list) :)
[14:30] <ogra_> and plain xchat has an option for this ;)
[14:31] <stgraber> cjwatson is way too fast for me today... :)
[14:40] <bfiller> sil2100: silo 2 ready for publishing
[14:41] <sil2100> o/
[14:41] <sil2100> mvo: want to land this as well ^ :)
[14:41] <mvo> sil2100: sure
[14:41] <sil2100> Thanks!
[15:20] <ogra_> robru, password auth is disabled ... nontheless my ssh key works everywhere if i ever attached via phablet-shell (even on different devices)
[15:21] <robru> ogra_, what?phablet-shell copies your ssh key down when you connect, but it's not magical across devices. not sure what you maen
[15:21] <ogra_> i.e. my laptop has never connected to the device in my basement directly ... only to my flo via phablet-shell ... nontheless i can ssh into a freshly flashed test device i never had attached to
[15:22] <robru> ogra_, define 'freshly flashed', your ssh key is stored in /home/phablet/.ssh so it won't get wiped in a flash unless you choose --bootstrap --wipe
[15:22] <ogra_> robru, thats surely another bug ... nontheless logging out of phablet-shell should not leave sshd runnign ... an dphablet-shell shouldnt fire up a global ssh daemon
[15:23] <ogra_> robru, i flash with --bootstrap ... but that device was never connected to my laptop i still can ssh in
[15:23] <robru> ogra_, well your ssh key got in there somehow
[15:23] <ogra_> that device never left my basement in the last year ... and i never connected directly to it
[15:24] <ogra_> anyway, this is not about keys
[15:24] <ogra_> but about sshd
[15:24] <robru> ogra_, I don't know how to make sshd only listen on local interface, there doesn't seem to be an option for that
[15:25] <ogra_> you use the cmdline options for it and start it directly instead of using upstart
[15:25] <robru> ogra_, please show me the commandline option that says 'only connect on lo' because i don't see it in the man page
[15:26] <robru> ogra_, looks like I need to munge sshd_config or something
[15:26] <ogra_> robru, dunno, i know there is a "listen address" option you can use in the config
[15:26] <ogra_> so there should be an equivalent on the cmdline
[15:26] <robru> $ adb shell /usr/sbin/sshd -4 -o 'Port 22' -o 'ListenAddress 127.0.0.1'
[15:26] <robru> /etc/ssh/sshd_config line 5: ports must be specified before ListenAddress.
[15:27] <robru> ogra_, ^ it doesn't work super well
[15:27] <ogra_> use -p
[15:27] <robru> $ adb shell /usr/sbin/sshd -4 -p 22 -o 'ListenAddress 127.0.0.1'
[15:28] <ogra_> robru, also dont use 22 please
[15:28] <robru> Could not load host key: /etc/ssh/ssh_host_ecdsa_key
[15:28] <robru> Could not load host key: /etc/ssh/ssh_host_ed25519_key
[15:28] <ogra_> right
[15:28] <ogra_> you will need your own host keys for this
[15:28] <ogra_> or run as root ;)
[15:28] <robru> ogra_, adb shell does run it as root
[15:28] <robru> $ adb shell id
[15:28] <robru> uid=0(root) gid=0(root) groups=0(root)
[15:28] <ogra_> thats weird, then it has permissions to read the keys
[15:29] <ogra_> do those kesys even exist ?
[15:29] <robru> ogra_, ecdsa does
[15:30] <ogra_> i wonder why it cant read it then
[15:30] <robru> ogra_, oops, sorry, I was looking at my host for a second there. no neither of those files are on the device
[15:30] <ogra_> good, as long as sshd starts ...
[15:30] <robru> but it didn't
[15:31] <ogra_> weird
[15:37] <robru> ogra_, yeah dunno, those two keys are listed in /etc/ssh/sshd_config. if I comment them out those errors go away but still won't connect
[15:37] <ogra_> robru, well, probably ask the ssh maintainer :)
[15:38] <ogra_> robru, though i think cjwatson is pretty busy this week
[15:39] <robru> ogra_, well i just checked the upstart job to see what magical incantation is necessary and the only option passed in is -D, which is precisely the opposite of what I want (keeps sshd in foreground)
[15:40] <cjwatson> That just means that lxc-android-config or whatever it is isn't creating them
[15:40] <cjwatson> ./etc/init/ssh-keygen.conf:6:    [ ! -e /etc/ssh/ssh_host_rsa_key ] && \
[15:40] <cjwatson> ./etc/init/ssh-keygen.conf:7:            ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa >/dev/null 2>&1
[15:40] <cjwatson> ./etc/init/ssh-keygen.conf:8:    [ ! -e /etc/ssh/ssh_host_dsa_key ] && \
[15:40] <cjwatson> ./etc/init/ssh-keygen.conf:9:            ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa >/dev/null 2>&1
[15:40] <cjwatson> That much shouldn't actually be harmful though
[15:40] <robru> cjwatson, ok but commenting them out doesn't make sshd actually start working though
[15:40] <cjwatson> I think that's a red herring
[15:41] <robru> yeah
[15:41] <cjwatson> robru: -D is correct under upstart
[15:41] <robru> cjwatson, right but not helpful for launching it manually
[15:42] <cjwatson> so is there anything in /var/log/upstart/ssh.log?
[15:42] <ogra_> cjwatson, right waht we need ios a dedicated sshd that only listens on loopback (preferably also on a port not 22)
[15:42] <cjwatson> err I'm confused about what the root problem here is
[15:42] <cjwatson> I thought that robru was unable to get sshd to start
[15:42] <ogra_> cjwatson, phablet-shell runs "start ssh" and does a loopback ssh connection
[15:43] <robru> cjwatson, right, so ogra told me to start sshd manually instead of with upstart. i'm trying that and its not working
[15:43] <ogra_> cjwatson, if you now disconnect and even diaable adb your sshd will keep running and allow connections from wlan
[15:44] <cjwatson> then surely you precisely want to run it in the foreground so that you can easily stop it ...
[15:44] <robru> cjwatson, UGH, if I call sshd with -d, it connects and listens it seems
[15:44] <robru> cjwatson, well not exactly, since it blocks my whole script...
[15:44] <cjwatson> anyway, I don't think you need me really :)
[15:44] <ogra_> i'm not sure if this setup will work at all once we removed root from adbd though ...
[15:44] <cjwatson> robru: well you need some concurrency, of course
[15:44] <ogra_> (which i was just asked to work on)
[15:49] <robru> ogra_, surely there's a way we can start sshd as not-root?
[15:49] <ogra_> robru, definitely ... on an unprivileged port etc
[15:50] <robru> ogra_, I guess I can poke at that now while I'm looking at this
[15:50] <ogra_> but you will need your own host keys too etc
[15:50] <cjwatson> I'm not at all convinced you can start sshd as non-root sanely
[15:50] <ogra_> robru, no hurry ... as long as we have it proper by RTM all is fine
[15:51] <ogra_> cjwatson, well, then we could have a dbus triggered upstart job or some such that provides this special sshd
[15:51] <cjwatson> I guess it must work to some extent because the regression test suite uses it I think, but it defeats the privsep mechanisms ...
[15:51] <ogra_> there are surely solutions to all of this :)
[15:52] <cjwatson> Something like that would be a lot saner IMO, yes
[15:52]  * ogra_ just wants the current behavior gone 
[15:52] <robru> cjwatson, ogra_ hmm, passing -D makes it work
[15:52] <ogra_> great
[15:52] <robru> just need to kill it at the end
[15:53] <ogra_> yeah
[15:53] <ogra_> just use a TRAP ... in your script
[15:53] <sil2100> It's a TRAP
[15:53] <ogra_> :)
[15:53] <cjwatson> Don't do it with a shell script.  Use something where you can explicitly fork and control the process hierarchy more explicitly ...
[15:54] <robru> cjwatson, ... the script is already a shell script. don't think I care to switch languages at this point
[15:54] <ogra_> cjwatson, well, its a script running on the host operating everything via adb shell commands
[15:54] <cjwatson> Not that I'm opposed to using shell for some fairly exotic things, but I wouldn't touch it for anything where reliable process management and signal handling was a critical security property!
[15:54] <ogra_> you wont even get a proper exit state from the commands you run there
[15:55] <ogra_> because adb swallows them
[15:55] <cjwatson> I don't care about that
[15:55] <ogra_> it would only work if you have the "tool" to handle all subprocesses running on the device
[15:55] <cjwatson> It's the process management at the device end that matters
[15:56] <sil2100> ogra_: hm, did we kick a new image with the suru bits? :)
[15:56] <ogra_> right but we dont have actual access to that without having some bits on the phone
[15:56] <cjwatson> For safety you want something on the device end that notices that the adb connection has gone away and stops sshd, or similar
[15:56] <ogra_> right
[15:56] <cjwatson> There's no way to do it otherwise - imagine if somebody just pulls the cable out
[15:57] <ogra_> that doesnt exist today
[15:57] <cjwatson> I know :)
[15:58] <ogra_> as i said before i really wonder if it is worth the hassle right now since adbd will change a lot and drop root etc ... so this implementation will look totally different in the end anyway
[15:59] <ogra_> sil2100, i was waiting for the clicks to land ...
[16:00] <sil2100> Ah, those didn't land yet?
[16:00] <ogra_> not sure, i dont think they did
[16:01] <ogra_> sil2100, what is worse though is that someone landed the re-designed camera-app ... which doesnt have video recording support ... which in turn breaks the work of people trying to get video recording fixed
[16:19] <imgbot> [16:36] <sil2100> Ok guys, I need to jump out for some moments, once I'm back I'll finish up the e-mail
[16:39] <bfiller> robru: around? need silo for line 49
[16:39] <robru> sure
[16:40] <robru> bfiller, conflicts with silo 9, can you merge them?
[16:40] <robru> or override/
[16:40] <robru> ?
[16:41] <bfiller> robru: override I think, silo 9 looks experimental
[16:41] <bfiller> this is a a one liner that we overlooked that should be pushed out very quickly
[16:42] <robru> bfiller, ok you got silo 2
[16:42] <bfiller> robru: cheers then :)
[16:42] <robru> bfiller, you're welcome
[16:43] <robru> damn queuebot rocks ;-)
[16:56] <elopio> cjohnston: can you help me figuring out if the ubuntu-system-settings-online-accounts autopilot tests are being run on MPs?
[16:56] <cjohnston> elopio: link?
[16:56] <elopio> I think not, but I've seen some other projects whose tests are hard to find on the jenkins comment.
[16:56] <elopio> cjohnston: https://code.launchpad.net/~elopio/ubuntu-system-settings-online-accounts/clean_tests/+merge/225437
[16:59] <brendand> sil2100, this browser bug has become crazy weird
[16:59] <brendand> sil2100, but i *think* i know exactly why it's happening
[16:59] <davmor2> brendand: spill don't keep us in suspense
[17:00] <brendand> sil2100, it's something to do with the testability driver being loaded + loading a specific page
[17:00] <brendand> it happens with:
[17:00] <brendand> /usr/bin/webbrowser-app -testability --desktop_file_hint=/usr/share/applications/webbrowser-app.desktop http://people.canonical.com/~brendan-donegan/browse.html
[17:00] <brendand> but not with:
[17:00] <brendand> /usr/bin/webbrowser-app --desktop_file_hint=/usr/share/applications/webbrowser-app.desktop http://people.canonical.com/~brendan-donegan/browse.html
[17:01] <brendand> or with:
[17:01] <brendand> /usr/bin/webbrowser-app -testability --desktop_file_hint=/usr/share/applications/webbrowser-app.desktop
[17:01] <brendand> so bizzare
[17:01] <davmor2> brendand: \o/
[17:01] <dobey> is there a bug for the new mirclient crash?
[17:02] <cjohnston> elopio: I don't see the tests in that MP being run.. maybe fginther would know better?
[17:02] <brendand> davmor2, any chance you can help me confirm that? by running those commands with the phone laying flat
[17:02] <brendand> in case i might be mental
[17:03] <davmor2> brendand: incase, dude I think we both know you are long past that ;)
[17:03] <davmor2> brendand: yeap give me 2 seconds
[17:04] <elopio> cjohnston: I see the tests are added as autopkgtests
[17:04] <brendand> davmor2, you're mental
[17:04] <elopio> and there's https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/
[17:04] <elopio> but I'm not sure when is that run.
[17:04] <davmor2> brendand: of course I work in QA don't I, Ask elopio rule 1 are you crazy
[17:06] <brendand> davmor2, they didn't ask me that in the interview. maybe they just knew
[17:09] <dobey> ev_: hey. how long between the .uploaded file being written on the client by whoopsie, and the crash report showing up on e.u.c?
[17:10] <ev_> dobey: the report should show up pretty much immediately. Cassandra is blazingly fast at writes and we don't do much on top of it.
[17:11] <ev_> If you're asking how long it takes for a binary crash to retrace and show up on the front page, much longer.
[17:11] <ev_> Depending on the architecture.
[17:12] <ev_> Bdmurray or webops can give you a better idea of current queue sizes there (I'm on my phone walking to a talk)
[17:12] <dobey> ev_: i'm looking at the /user/$VERYLONGHASH page that the "Previously submitted reports" on the phone sends me to
[17:12] <dobey> but am not seeing all the crashes there that it uploaded
[17:12] <ev_> Yes, that should be immediate.
[17:13] <dobey> ok. wonder why they're missing
[17:13] <ev_> Oh strange.
[17:13] <ev_> Yeah
[17:13] <dobey> well, enjoy the talk :)
[17:13] <ev_> Thanks. Do follow up with Brian. He should be able to poke the db for you.
[17:17] <dobey> hmm, found one in the global list
[17:17] <davmor2> sil2100: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-07-03-181500.png
[17:18] <brendand> davmor2, for you it rotates to the bottom left but for me it's the top right, odd
[17:18] <davmor2> brendand: let me keep trying
[17:20] <fginther> cjohnston, elopio looking
[17:21] <elopio> thanks fginther
[17:27] <bfiller> robru: silo 2 good to be published
[17:28] <Saviq> robru, silo 5, too! ;)
[17:28] <robru> stgraber, need a core dev ack in silo 5, you around? https://ci-train.ubuntu.com/job/landing-005-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity8_7.90+14.10.20140703.1-0ubuntu1.diff
[17:28] <robru> bfiller, published
[17:29] <bfiller> robru: thanks
[17:29] <Saviq> robru, thanks!
[17:29] <robru> bfiller, you're welcome!
[17:30] <robru> Saviq, you're welcome. did you get a chance to review my phablet-tools fix MP?
[17:32] <Saviq> robru, hmm didn't see it, checking
[17:32] <robru> Saviq, https://code.launchpad.net/~robru/phablet-tools/dont-delete-silos
[17:33] <Saviq> robru, btw, wanted to mention one more thing - device-purge complaining about ppa-purge not being installed is an excuse, isn't it? you just added a ppa and installed packages from it! ;D
[17:34] <robru> Saviq, not sure what you mean
[17:34] <Saviq> robru, `citrain device-purge` says it doesn't work because ppa-purge is not installed on the device
[17:35] <Saviq> robru, feels like a lame excuse when you just added a PPA and installed packages, you could've installed ppa-purge just as well, couldn't you? ;)
[17:35] <robru> Saviq, right, so do you want me to install ppa-purge on the device?
[17:35] <Saviq> robru, and even purge it afterwards if you feel that's better
[17:35] <Saviq> robru, I see no reason why not, do you?
[17:35] <elopio> cjohnston: can you add the -n option to phablet-test-run in the ubuntu_experience_tests ?
[17:35] <elopio> looking for the link...
[17:35] <robru> Saviq, dunno, was trying not to mess with the device too much
[17:36] <elopio> https://code.launchpad.net/~elopio/ubuntu-autopilot-tests/fix_packaging/+merge/225426
[17:36] <elopio> http://jenkins.qa.ubuntu.com/job/ubuntu-autopilot-tests-ubuntu-experience-tests-ci/10/
[17:36] <Saviq> robru, I think that ship sails as soon as you make it writable and start using apt :)
[17:38] <Saviq> robru, http://pastebin.ubuntu.com/7742992/
[17:38]  * Saviq preps mp
[17:40] <Saviq> robru,
[17:40] <Saviq> https://code.launchpad.net/~saviq/phablet-tools/fix-pep8/+merge/225529
[17:41] <fginther> elopio, tests for ubuntu-system-settings-online-accounts appear to never have been added. working on it now
[17:42] <fginther> elopio, also we're we ever able to get unity-click-scope tests working?
[17:43] <elopio> fginther: I'm almost sure the problem was that dpkg-architecture -c was not working.
[17:44] <elopio> fginther: I was going to ask you to try to run the tests with this branch:
[17:44] <elopio> https://code.launchpad.net/~elopio/unity-scope-click/split_scope/+merge/224926
[17:44] <elopio> I think I can do it, but now I can't find the jenkins job we were using.
[17:44] <fginther> elopio, we can try a new one
[17:44] <imgbot> [17:44] <imgbot> [17:51] <dbarth> robru: just a heads up; you can free the silo 18, to make room for oSoMoN branches
[17:52] <bfiller> robru: silo 14 read for publishing as well
[17:52] <dbarth> robru: also, there are those 2 chrome and firefox extension updates that can be SRUed now; both landed afaik
[17:58] <fginther> elopio, testing your unity-scope-click MP here: http://s-jenkins.ubuntu-ci:8080/job/unity-scope-click-ci/480/
[17:59] <fginther> elopio, also started testing ubuntu-system-settings-online-accounts - s-jenkins.ubuntu-ci:8080/job/ubuntu-system-settings-online-accounts-ci/132/
[18:01] <robru> dbarth, thanks
[18:02] <robru> dbarth, can you email me with the list of changes to SRU? I already started the google auth SRU
[18:04]  * sergiusens wonders if his computer is self sentient and started to do landngs for him
[18:04] <robru> sergiusens, could be
[18:05] <sergiusens> :-)
[18:05] <elopio> fginther: thank you and thank you!
[18:06] <bfiller> robru: need a silo for line 31 as well when you have a chance
[18:06] <robru> bfiller, ok, just waiting for 2 to free
[18:06] <robru> because there literally are zero
[18:07] <bfiller> robru: np
[18:10] <davmor2> Saviq: \o/ new ICONS!!!!!!
[18:12] <boiko> robru: silo 3 fully tested and ready to land
[18:13] <boiko> robru: dialer-app and messaging-app were already rebuilt to include Saviq's changed
[18:13] <robru> boiko, thanks
[18:16] <Saviq> davmor2, indeed :)
[18:26] <elopio> fginther or cjohnston: http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-utopic/1101/artifact/results/autopilot/artifacts/online_accounts_ui.tests.test_online_accounts_ui.OnlineAccountsUiTests.test_create_account_with_form%20%28with%20mouse%29.ogv
[18:26] <elopio> that's online accounts failing because it needs a password for the keyring.
[18:26] <elopio> do we have a way to work it arond?
[18:27] <fginther> elopio, I remember a discussion, but I thought we ultimately ran into a wall :-/
[18:28] <fginther> elopio, I think there was some solution, but getting it to work with otto was not trivial. I'd have to go back through my irc logs perhas
[18:29] <fginther> elopio, does the mako test work?
[18:29] <fginther> oh, still running
[18:29] <elopio> fginther: currently they are skiped. But I'm going to enable them, it seems the reason is now solved.
[18:30] <elopio> fginther: will these tests run on MPs now?
[18:30] <fginther> elopio, ok, I'll set it up to just run the mako tests
[18:31] <Saviq> robru, could we get a recon on silo 6 please
[18:31] <Saviq> ubuntu-system-settings got added
[18:31] <Saviq> robru, conflict can be ignored
[18:31] <robru> ok
[18:32] <robru> Saviq, it's happening: https://ci-train.ubuntu.com/job/prepare-silo/883/console
[18:32] <robru> brb
[18:32] <pmcgowan> Saviq, what got added to settings?
[18:33] <Saviq> pmcgowan, they got added to the QtCompositor silo
[18:33] <pmcgowan> Saviq, how come? what changed?
[18:34] <elopio> fginther: Loic is the maintainer of a package called python-gnomekeyring that might help.
[18:34] <elopio> I'll prepare a branch to get the tests working on mako.
[18:34] <Saviq> pmcgowan, the welcome wizard needed to be adapted
[18:34] <Saviq> pmcgowan, as its a shell of its own
[18:35] <pmcgowan> vg
[18:35] <sergiusens> fginther: plars hey did you guys get around to adding the --developer-mode toggle to ubuntu-device-flash?
[18:36] <plars> sergiusens: I keep meaning to reply to that thread and keep forgetting. Yes I added it on the smoke side, but I'm not sure if fginther has it for the autolanding stuff yet
[18:36] <fginther> sergiusens, let me double check
[18:36] <plars> fginther: if not, I'd be happy to put it in there if you can point me at the right branch. I don't have a good way of testing it though, and istr you said you were seeing some strangeness when you tried to add it before?
[18:37] <sergiusens> plars: ok; I'm not flipping any switch; it's a hard one to unflip if done wrong ;)
[18:37] <plars> fginther: fwiw, I *did* try it on one of my devices attached to okiku and it worked ok for me
[18:37] <plars> sergiusens: right
[18:37] <fginther> plars, yeah, I just need to try again. I think the failure I saw was just a coincidence
[18:49] <elopio> yay, tests work on mako!
[18:49] <Saviq> robru, who else can we bug for ACKing silo 5?
[18:49] <Saviq> greyback, I'll slip settings for now until it migrates and gets merged
[18:49] <Saviq> skip
[18:51] <Saviq> will add it once the others are safely building in the PPA
[18:53] <fginther> elopio, what test are you referring to?
[18:53] <elopio> fginther: online accounts:
[18:53] <elopio> https://code.launchpad.net/~elopio/ubuntu-system-settings-online-accounts/test_mako/+merge/225543
[18:54] <fginther> elopio, nice
[18:54] <oSoMoN> robru, have you seen dbarth’s message earlier saying that silo 18 could be freed in favour of my landing request at line 30 ?
[19:00] <robru> Saviq, any core dev
[19:00] <robru> oSoMoN, oh yeah, sorry, got distracted
[19:05] <robru> cyphermox_, mterry: anybody around for a packaging ack? https://ci-train.ubuntu.com/job/landing-005-2-publish/44/artifact/packaging_changes_unity8_7.90+14.10.20140703.1-0ubuntu1.diff
[19:07] <cyphermox_> in a few minutes yes
[19:07] <robru> cyphermox_, cool thx
[19:08] <mterry> robru, the addition of libhardware2 and pay-service I suspect are unnecessary
[19:08] <mterry> robru, but nothing harmful
[19:08] <mterry> *the addition of ... as Depends
[19:09] <robru> mterry, why would they be unecessary? are they seeded? isn't it better to be explicit about deps?
[19:09] <mterry> robru, because libhardware2 should come in via ${shlibs:Depends}
[19:10] <robru> ah, magic, got it
[19:10] <mterry> robru, and I would have expected libpay1 to Depend on pay-service, but apparently it doesn't.  So that's not unnecessary (but I'm thinking libpay1 probably should handle that dep for its downstreams)
[19:11] <robru> mterry, but that's no reason to block here, right? we can publish this and then fix libpay1 later?
[19:12] <mterry> robru, sure, like I said, nothing harmful that I see
[19:12] <robru> mterry, great, thanks
[19:14] <robru> sergiusens, think i can publish silo 20? changes are relatively minor and tested by saviq already
[19:15] <sergiusens> robru: I thought that was the purpose of trains; not preventing people from doing stuff ;-)
[19:15] <sergiusens> robru: I trust you did the right thing
[19:15] <robru> sergiusens, yeah but I just don't want to step on your toes since it's your project and all ;-)
[19:15] <robru> sergiusens, thanks
[19:16] <sergiusens> robru: no worries; it's just a bad thing to break as it breaks ci if we screw up ;)
[19:16] <Saviq> mterry, robru, I actually asaked dobey about these deps
[19:17] <Saviq> about pay, that is
[19:17] <dobey> er?
[19:17] <mterry> Saviq, and was it good that they didn't auto-depend?
[19:17] <dobey> oh
[19:18] <Saviq> mterry, here's dobey to explain
[19:18] <dobey> mterry: i asked ted about libpay1 not depending on pay-service and what he said to me was that he was told it shouldn't do that. don't know by who
[19:18]  * mterry shrugs
[19:18] <mterry> OK
[19:18] <dobey> feel free to bug him on monday about it
[19:18] <dobey> i don't like it the way it is now either :)
[19:19] <Saviq> mterry, hardware2 would indeed be automagicked by shlibs it seems
[19:19] <mterry> You'd think..
[19:20] <Saviq> it is linked, at least
[19:20]  * Saviq checks
[19:20] <Saviq> mterry, fwiw it comes from https://code.launchpad.net/~renatofilho/unity8/blue-led/+merge/224899
[19:21] <mterry> If that is the cost for blue leds, I'm happy to pay it  ;)  But seriously, we can just clean it up down the road
[19:22] <Saviq> mterry, k, let's
[19:23] <elopio> robru: can you add the -n option to phablet-test-run in the ubuntu_experience_tests ?
[19:23] <elopio> https://code.launchpad.net/~elopio/ubuntu-autopilot-tests/fix_packaging/+merge/225426
[19:23] <elopio> http://jenkins.qa.ubuntu.com/job/ubuntu-autopilot-tests-ubuntu-experience-tests-ci/10/
[19:24] <robru> elopio, hmmmmmm
[19:24] <robru> elopio, do what now?
[19:24] <elopio> robru: this tests restart unity, so they need to start without unity.
[19:24] <elopio> that's what phablet-test-run -n does.
[19:25] <robru> mhhhmmmmmm
[19:25] <elopio> this should be similar to how the unity autopilot tests are configured.
[19:25] <robru> elopio, do you have the VPN link for that jenkins job? I can't do anything with the public URL
[19:25] <elopio> let me see..
[19:26] <robru> elopio, or even if you know which jenkins instance that is, i have no idea ;-)
[19:26] <elopio> robru: http://s-jenkins.ubuntu-ci:8080/job/ubuntu-autopilot-tests-ubuntu-experience-tests-ci/ ?
[19:28] <robru> welp, I have no idea
[19:28] <robru> fginther, ^^ do you  know what elopio is talking about?
[19:28] <robru> I mean I know the -n option but I have no idea where I'm supposed to poke that in to make it go
[19:29] <fginther> robru, elopio, that's handled by the test runner, but maybe we can poke it by adding '-n' to the test suite string
[19:30] <robru> fginther, where's the code for that? i don't know the first thing about the experience tests
[19:31] <fginther> robru, in this case it's handled by a fork of the smoke test runner
[19:31] <Saviq> mterry, yeah, confirmed, can be dropped
[19:31] <fginther> robru, the code for that is here - lp:~fginther/ubuntu-test-cases/mp-testing
[19:31] <robru> fginther, is there a branch I can MP?
[19:31] <robru> fginther, oh your own branch huh? :-P
[19:32] <fginther> robru, yeah, let me fix that first :-/
[19:33] <robru> fginther, are you talking about run-autopilot-tests.sh?
[19:33] <fginther> robru, that's probably where it is... I know there is something in there to handle unity differently
[19:34] <fginther> unity8 thatis
[19:34] <robru> fginther, yep, there's a check if it's testing unity8 and then sets -n already
[19:34] <robru> fginther, ok so I guess it needs to check for ubuntu_experience_tests as well?
[19:35] <fginther> robru, that's the most straightforward way to do it
[19:36] <robru> fginther, elopio: https://code.launchpad.net/~robru/ubuntu-test-cases/mp-testing/+merge/225555 i guess this is it
[19:36] <elopio> robru, fginther: I could also stop unity8 during the set up of the tests, if you prefer that solution
[19:36] <robru> oops, MP into wrong place
[19:37] <Saviq> hmm who can restart autopkgtests?
[19:38] <fginther> elopio, ideally the tests will have to handle this itself, but I can't really push this method until we support testing these with autopkgtest
[19:39] <elopio> it could be a litte problematic if you are not expecting the tests to restart unity.
[19:39] <robru> fginther, elopio: https://code.launchpad.net/~robru/ubuntu-test-cases/mp-testing/+merge/225557
[19:40] <elopio> robru: thansk, looks good. But I really have no context, so I'll leave the approval to fginther.
[19:40] <robru> elopio, hehe, me either
[19:41] <fginther> robru, approved, merging now
[19:41] <robru> fginther, thanks
[19:41] <elopio> to extend Saviq's question, when are autopkgtests run? What triggers them?
[19:42] <Saviq> elopio, uploads to proposed
[19:42] <robru> elopio, I believe those get run in -proposed, which means, they're run every time a package is published
[19:42] <Saviq> elopio, they're also run for reverse dependencies
[19:43] <fginther> Saviq, what do you need to have rerun?
[19:43] <fginther> robru, these run on http://d-jenkins.ubuntu-ci:8080/
[19:43] <elopio> oh, so nice. I want more of them.
[19:43] <Saviq> fginther, http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/lastBuild/?
[19:43] <Saviq> elopio, we should move *all* of them to autopkgtests
[19:43] <Saviq> elopio, like we should only have autopkgtest jobs in jenkins
[19:44] <Saviq> elopio, no testrunners, no qmluitests runners
[19:44] <Saviq> just dep8 runners
[19:44] <fginther> robru, are you able to login to d-jenkins? All you need to do is rebuild that job
[19:44] <Saviq> I can log in, can't do anything in there though ;)
[19:45] <elopio> Saviq: so, we shouldn't run qml tests  on dh_auto_test?
[19:45] <Saviq> elopio, no, in autopkgtests
[19:45] <robru> fginther, logged in, but what job?
[19:45] <fginther> robru, http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/
[19:45] <Saviq> elopio, or well, it depends
[19:45] <elopio> Saviq: hum, I was trying to put the address book qml tests in autopkgtests, and pitti recommend to move them to build time.
[19:46] <elopio> maybe we can run them twice?
[19:46] <robru> fginther, uh ok, building...
[19:46] <Saviq> elopio, can they run without X?
[19:46] <Saviq> (or xvfb)
[19:46] <Saviq> robru, thanks
[19:46] <robru> Saviq, oh you're welcome. I thought this was elopio's thing still ;-)
[19:47] <fginther> sergiusens, --developer-mode is a go. I've update the jobs on s-jenkins and they are working
[19:47] <fginther> plars, ^
[19:47] <sergiusens> fginther: great thanks
[19:47] <plars> cool
[19:47] <sergiusens> fginther: plars I'm going to probably do this on Monday since you guys are going to be out tomorrow
[19:47] <elopio> Saviq: I think not. We are using xvfb.
[19:47] <sergiusens> I assume that at least
[19:47] <elopio> oh, I missed your parentheses. Yes, xvfb.
[19:47] <plars> sergiusens: well, apparently we have an outage on Monday
[19:47] <sergiusens> and this would give time for ogra_ to land it in the ui
[19:48] <sergiusens> plars: lol
[19:48] <Saviq> elopio, so, pitti might tell you otherwise, but I thought it's a waste of builders time to run them all
[19:48] <sergiusens> plars: perfect timing :-)
[19:48] <plars> sergiusens: the adb hosts will be affected
[19:48] <sergiusens> yeah, I saw the email, just not the date :-)
[19:48] <Saviq> robru, hit me again!
[19:48] <plars> sergiusens: so that could make it a good, or a bad time depending on your perspective :)
[19:48] <Saviq> http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/79/console
[19:49] <plars> sergiusens: depending on when you land it, it may not get tested until much later
[19:49] <sergiusens> plars: sort of good; the toggle is on the android side so ci support for the transition is a tricky one
[19:49] <elopio> Saviq: as long as they run on the MPs, I don't care if it's during the build, from a jenkins job or from the autopkgjobs.
[19:49] <elopio> but currently we are not running autopkg on MPs, I think.
[19:49] <sergiusens> makes sense
[19:49] <sergiusens> I'll discuss with ogra_ tomorrow then
[19:50] <plars> sergiusens: if we have --developer-mode in the udf we have now, will there be an updated one we need to make it really do something useful? or does it completely hinge on the android change
[19:51] <Saviq> elopio, we're not, but we should
[19:52] <Saviq> elopio, all autopilot tests should be put in autopkgtests
[19:52] <Saviq> IMO
[19:52] <Saviq> and well, vila says so, too!
[19:52] <elopio> Saviq: agree to that.
[19:52] <Saviq> robru, thanks again :)
[19:52] <elopio> Saviq: I'll ask pitti tomorrow to see if we can make a clear distinction of what should go where.
[19:52] <robru> Saviq, you're welcome
[19:53] <oSoMoN> robru, hey, any idea what failed there? https://ci-train.ubuntu.com/job/landing-018-1-build/93/console
[19:53] <oSoMoN> it looks like the source package never made it to the PPA, not sure why
[19:54] <elopio> ping plars: Chris Gagnon is writing a long-running tests suite to collect crashes from random autopilot gestures
[19:54] <elopio> I think they should run on the daily image just like the health check tests you recently added.
[19:54] <elopio> Any thoughts?
[19:54] <plars> elopio: how long would it run?
[19:55] <robru> oSoMoN, well the silo is empty so I'm guessing the package upload failed or was rejected...
[19:55] <robru> though no idea why
[19:55] <plars> elopio: also, did he take it over from someone? istr someone talking about this tool at the client sprint
[19:56] <plars> but it wasn't chris
[19:56] <robru> fginther, do you know where the rejection emails go for ci train silo builds? I never get those
[19:57] <elopio> plars: that was thomi's demo on the sprint.
[19:57] <elopio> Currently, we can get them running for ~20 minutes or until the first crash occurs.
[19:58] <elopio> when we are not able to find crashers for 20 minutes, we should increase that time.
[19:58] <plars> elopio: ok, just making sure we don't have multiple people working on it and not talking :)
[19:58] <dobey> Saviq, mterry, robru: so is landing-013 being landed now?
[19:58] <plars> elopio: 20 min. isn't horrible, but we should talk about it
[19:58] <fginther> robru, the should go to the lp user who signed the package I would assume
[19:58] <thomi> plars: yeah, I handed it over :)
[19:59]  * mterry defers to robru
[19:59] <plars> thomi: it's cool stuff, I've been hoping for something like this for a while. Similar concept to monkey for android
[19:59] <thomi> plars: elopio: but please bear in mind that we already had this discussion about running these tests, and the lack of hardware was the blocker
[19:59] <thomi> plars: ack
[19:59] <elopio> plars: I think with the current status, it would never run the full 20 minutes. But we'll have to see.
[19:59] <robru> dobey, nobody indicated silo 13 was ready for release
[19:59] <plars> I'm told that OEMs say "ship it" when they can finesse their way to a 24 hour monkey run on a device
[19:59] <robru> fginther, so ps-jenkins?
[19:59] <thomi> plars: elopio: so the compromise we came to was to get chris gagnon to run tem at his house, since it required less up front work
[19:59] <dobey> robru: oh. i thought that's why you were asking about the pay-service dep :)
[20:00] <plars> elopio: so the big questions that stick out for me are things like "how do we treat pass/fail on it?" "can it ever run more than 20 min?"
[20:00] <thomi> plars: I'm pretty sure you were there for that meeting? It was ev, jfunk, myself and you (I thought)
[20:00] <dobey> robru: anyway, it's good. so please land it :)
[20:00] <robru> dobey, no it was unity8 release in silo 5 that has that pay service dep
[20:00] <robru> dobey, ok
[20:00] <plars> thomi: yep
[20:00] <fginther> robru, perhaps, I thought the ci-train had a different bot user, but my memory is fuzzy
[20:00] <robru> dobey, oh actually you'll have to rebuild unity8 in silo 13 after silo 5 lands
[20:00] <fginther> robru, ps-jenkins email goes to a mailing list and I think I'm still on it
[20:00] <dobey> oh
[20:00] <plars> thomi: I think there were other concerns about why at the time, I don't recall the detail though
[20:01] <robru> fginther, can you check for a recent rejection in silo 18?
[20:01] <fginther> only 36000 emails there
[20:01] <robru> fginther, IIRC I applied for that ML but was never approved
[20:01] <dobey> why did silo 5 have a pay-service dep
[20:01] <fginther> robru, found it
[20:01] <plars> elopio: my assumption is that it would not be boxed in at 20 min. right? we should try to run as long as possible?
[20:01] <elopio> thomi: hum, jfunk asked me to try to get this running and showing results on the dashboard, which I think would be great.
[20:01] <elopio> I think having to wait 20 more minutes for the results in order to collect crashes in a systematic way it's worth it.
[20:01] <robru> dobey, no idea
[20:01] <elopio> plars: until we have a mako 24/7 for this tests, we can just define a good time limit.
[20:01] <thomi> elopio: ok, maybe he forgot the discussion we had in malta, or maybe he has some other plan
[20:01] <fginther> robru, I forwarded the email
[20:01] <elopio> to start, 20 minutes sounds reasonable for me.
[20:02] <robru> fginther, thanks
[20:02] <dobey> oh
[20:02] <jfunk> elopio: plars: I am not sure I asked for it to be pass / fail on the dashboard
[20:02] <plars> elopio: the other thing is how to gauge the result
[20:02] <thomi> elopio: I agree that it'd be a good thing to do, I'm just making sure you're aware of the previous discussions we've had
[20:02] <jfunk> elopio: plars: or at least, not blocking
[20:02] <dobey> robru: with silo 5 landing, we can just drop unity8 from silo 13.
[20:02] <plars> jfunk: yeah, that's what I'm driving at... we could put a result there, which has the distinct advantage of being more visible
[20:02] <robru> oSoMoN, oh derp, so ci train gave your webbrowser-app build and dbarths' the same version umber, force rebuild should fix it
[20:02] <dobey> robru: the payments-button MP is in silo 5 too it looks like
[20:02] <elopio> plars: pass will be 20 minutes without failure. But this should not block for now, just as the health checks.
[20:02] <plars> jfunk: but the result is likely always going to be "fail"
[20:03] <jfunk> elopio: plars: thomi: yeah, I would just like to run these every time with the crashers going up
[20:03] <oSoMoN> robru, ok, thanks
[20:03] <elopio> plars: not always :) If we make sure that the crashes are fixed, it will tend to green.
[20:03] <plars> elopio, jfunk: are you happy with the test in it's current state? do you believe it's ready for us to be running it in ci now?
[20:03] <elopio> plars: no, not yet.
[20:04] <elopio> we first have to package them and put them on the archive.
[20:04] <elopio> Chris is working on that.
[20:04] <plars> elopio: yeah, but then we get to 25 min. and it crashes, and eventually a full day
[20:04] <elopio> plars: at that point, maybe we can look for stats. How long do people run their phones without it getting locked?
[20:05] <plars> based on android results for a similar test, my gut tells me we won't have to worry about *truly* long runs
[20:05] <plars> elopio: yeah, I think if it starts running too long, we figure out how to make it more abusive
[20:06] <elopio> plars: yes, it would not be a really useful test if it runs for 3 hours without crashes. It consumes too many test resources, without a lot of value.
[20:06] <plars> indeed
[20:06] <elopio> at that point it might be better to start looking at the crashes that the users send.
[20:06] <thomi> plars: elopio, please make sure you submit the TTF to the nfss system
[20:06] <thomi> which should be deployed by then :)
[20:06] <plars> elopio: send me some information and I'll start poking at it and figure out a strategy for integrating it into ci
[20:07] <elopio> thomi: so many letters to remember :)
[20:07] <thomi> elopio: too many TLAs?
[20:07] <elopio> plars: thanks. I'll keep you on the loop of Chris's progress.
[20:07] <plars> elopio: ah, while I'm thinking about it though... I was noticing that memevent that jcollado worked on a while back is no longer working on utopic
[20:07] <plars> elopio: do you have someone on your team that could take a look at fixing it? http://q-jenkins.ubuntu-ci:8080/job/memevent-utopic-touch-armhf-default-mako/
[20:08] <elopio> jfunk: ^
[20:08] <plars> elopio: it's another one that might make a good candidate for nfss as well
[20:08] <plars> maybe
[20:08] <elopio> agree. I'm not sure we have people though. Maybe after Chris finishes with this one he would like to take over memevent.
[20:08] <dobey> robru: can you drop the unity8 mp from silo 013 then, and land it with just the pay-service bits?
[20:09] <robru> dobey, oh is it redundant? yeah i can do that
[20:09] <dobey> robru: yeah
[20:09] <dobey> it got included in silo 005 too
[20:10] <robru> dobey, awesome.
[20:11] <robru> dobey, this is my favorite part about letting people have a component in more than one silo at a time
[20:11] <dobey> heh
[20:11] <dobey> quantum silos
[20:14] <Saviq> dobey, oh sorry, thought mhr3 took care of removing that
[20:14] <Saviq> robru, http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/ failed again
[20:16] <dobey> oh right, i added a couple recommends
[20:16] <dobey> robru: ^^ that should be a trivial ack :)
[20:16] <robru> dobey, yep ;-)
[20:17] <dobey> whoot
[20:17] <robru> Saviq, greyback, mzanetti, so unity8 just got published from silo 5, you guys wanna rebuild your unity8s in silos 9 and 6?
[20:17] <Saviq> robru, yup, will do
[20:17] <robru> Saviq, thanks
[20:19] <robru> oSoMoN, ugh, webbrowser-app is gonna fail again, same version number again
[20:20] <robru> oSoMoN, going to give you a different silo
[20:38] <Saviq> robru_, still failed :| those tests are really bad
[20:38] <robru_> Saviq, yeah i have no idea what's going on there
[20:38] <Saviq> robru_, well, I do
[20:39] <Saviq> robru_, bug #1336650
[20:39] <robru_> Saviq, yeah, but why? why are they flaky? ;-)
[20:39] <Saviq> robru_, because they're badly written ;)
[20:39] <Saviq> robru_, https://code.launchpad.net/~elopio/ubuntu-system-settings-online-accounts/clean_tests/+merge/225437
[20:42] <oSoMoN> robru_, thanks for the new silo!
[20:42] <robru_> oSoMoN, you're welcome
[20:44] <fginther> elopio, looks like it works now: http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-mako/1825/testReport/
[20:45] <elopio> fginther: \o/
[20:45] <elopio> thanks!
[20:45] <elopio> next, I'll put it in the archive.
[20:46] <fginther> elopio, cool
[20:46] <elopio> fginther: will we have auto-landing to trunk?
[20:46] <fginther> elopio,unity-scope-click is still not all passing http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-utopic/1104/
[20:47] <fginther> elopio, yes, autolanding is enabled for the time being
[20:48] <fginther> elopio, I'm going to keep the unity-scope-click tests enabled, but they are set to not fail the overall -ci job
[20:48] <elopio> fginther: same keyring problem :(
[20:48] <fginther> :-(
[20:49] <elopio> fginther: I can skip the tests that use credentials there, for now.
[20:49] <elopio> fginther: another thing, can these jenkins runners access the internet?
[20:53] <fginther> elopio, no, they cannot due to the default firewall rules
[20:54] <elopio> ok, that's good. That's what's causing the other error.
[20:54] <elopio> For now, I'll just skip everything that will make it fail, and then enable then one by one.
[21:13] <bfiller> popey: new versions of camera and gallery uploaded to store, AP tests working for both
[21:14] <popey> bfiller: k
[21:14] <popey> bfiller: approved both
[21:19] <bfiller> popey: thanks
[21:19] <popey> np
[22:02] <oSoMoN> robru, can silo 5 be published, please?
[22:10] <elopio> robru or fginther: can you help me figuring out why this failed?
[22:10] <elopio> https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/1829/console
[22:10] <elopio> could not import package online_accounts_ui: No module named online_accounts_ui
[22:14] <fginther> elopio, I don't know at the moment. It looks like phablet-test-run is trying to use autopilot 1.4. Are these python3 tests?
[22:15] <elopio> ahh, right. Same error with the warning probably.
[22:17] <elopio> fginther: how do you know when it's tring to run py2?
[22:18] <fginther> elopio, 21:29:46.666 INFO run:216 - Autopilot Source Version: 1.4.0
[22:19] <elopio> ah, it should be autopilot 1.5
[22:19] <elopio> ok, got it.
[22:27] <fginther> elopio, I don't quite understand, the prior run used 1.5: http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-mako/1824/console
[22:28] <elopio> fginther: for what branch is that one? I probably started getting the warning when I refactored the tests.
[22:29] <elopio> that's the branch that's a prerequisite for this one, not yet landed.
[22:30] <fginther> elopio, ahh, the one that used 1.5 was a test against trunk