[02:04] <imgbot> [03:04] <imgbot> [03:29] <imgbot> [03:29] <imgbot> [04:24] <imgbot> [04:24] <imgbot> [12:33] <tedg> trainguards, could I please get a silo for line 82?
[12:34] <Mirv> tedg: just a second
[12:35] <tedg> Mirv, Cool, thanks!
[12:36] <Mirv> tedg: rtm-002
[12:36] <tedg> Mirv, Great, thanks!
[12:40] <davmor2> cwayne, ogra_, sil2100: custom tarball is good to go :)
[12:41] <ogra_> whee !
[12:42] <cwayne> davmor2, thanks for testing :)
[12:43] <cwayne> sil2100, let me know when I'm allowed to push the magic button :)
[12:43] <davmor2> cwayne: sorry I didn't finish it last night but with everything going on I ran out of day :)
[12:44] <cwayne> davmor2, no worries at all man
[13:08] <sil2100> cwayne: hey!
[13:08] <sil2100> Sorry, I'm in meetings now ;)
[13:09] <sil2100> ogra_: any reasons not to push the custom tarball right now?
[13:09]  * sil2100 is disconnected from the world
[13:09] <ogra_> sil2100, i think it should be fine ... we are still trying to solve the issues the dropping of AP caused
[13:10] <ogra_> (seems there si some dependency mess we might need to have solved via plars )
[13:11] <mterry> elopio, did I see you say that the latest unlock-device race fixes didn't fix all of the issues we see in CI?
[13:11] <plars> ogra_: sorry I missed the conversation, I was pinging him on irc when you were talking to him, but I'm in another session right now
[13:11] <mterry> plars, or was it you?  ^
[13:11] <plars> ogra_: what's the issue? was he able to spot it?
[13:11] <elopio> mterry: wasn't me. I think plars.
[13:11] <plars> mterry: we have a lot of other issues too right now, let's fix those then we'll see
[13:11] <ogra_> plars, dropping AP-touch means a bunch of deps are now missing ...
[13:11] <mterry> plars, ok
[13:11] <plars> mterry: did that land everywhere? I thought it couldn't land yet
[13:12] <ogra_> sil2100, line 84 and 85 should help us
[13:12] <mterry> plars, oh goodness you're right, it hasn't landed yet
[13:12] <plars> ogra_: why are those not installed by phablet-test-run though? I thought it was installing ap-touch?
[13:12] <sil2100> cwayne: ok, please push the button for now
[13:12] <mterry> plars, sorry man, early morning for me
[13:12] <sil2100> ogra_: looking
[13:12] <veebers> olli: ping, I have 2 lines in the spreadsheet that I need to clarify perhaps. It is a packaging fix for removing autopilot from the image (sitting here with ogra_ attempting to sort it out)
[13:12] <ogra_> plars, and i thought you said installuing unity8-ap would pull in all necessary bits ;)
[13:12] <mterry> plars, if you want it to land sooner, advocate for higher priority on bug 1370644  :)
[13:12] <plars> ogra_: no, wasn't me
[13:13] <ogra_> plars, well, someone claimed it in the meeting
[13:13] <plars> ogra_: someone claimed that phablet-test-run installs everything, but I don't see where
[13:13] <ogra_> plars, could we try to re-run some broken tests after pulling ap from one of the silos into the infra ?
[13:13] <ogra_> phablet-test-run doesnt install anything on its own :)
[13:14] <ogra_> unless you hand it to the -p option
[13:14] <plars> ogra_: I'm confused how anything is working at all then :)
[13:14] <ogra_> plars, well it worked because we shipped half the wolrd of available tests and tools before :)
[13:15] <plars> ogra_: no, I mean how any of the tests work now
[13:15] <ogra_> now we dont anymore
[13:15] <plars> ogra_: but some don't
[13:15] <ogra_> plars, seems all click tests work fine
[13:15] <ogra_> and everything else doesnt
[13:15] <plars> so like on webbrowser, we get like 15 tests instead of 50, but some actually pass?
[13:15] <ogra_> (on a first glance)
[13:15] <ogra_> yeah
[13:15] <cwayne> sil2100, pushed :)
[13:16] <ogra_> plars, http://people.canonical.com/~ogra/touch-image-stats/20141021.1.changes ... qttestability-autopilot ... i guess thats the issue
[13:16] <ogra_> ap-touch used to pull some extra deps in
[13:16] <plars> ogra_: veebers: so is there a single package to install that would fix it? autopilot-touch?
[13:16] <plars> python3-autopilot?
[13:16] <veebers> plars: yeah autopilot-touch should do it
[13:16] <ogra_> plars, veebers just requested a silo ... i had to move one file from ap-touch into dbus-property-service
[13:17] <sil2100> ogra_: ok, I'll assign silos for those
[13:17] <ogra_> plars, so ap-touch is uninstallable til that silo lands (which drops the file from ap-touch)
[13:17] <veebers> plars: it is already pulling in python3-autopilot, autopilot-touch pulls in qttestability-autopilot
[13:17] <plars> ogra_: ok, what's the ppa? I can test something
[13:18] <ogra_> plars, if sil2100 stops slacking
[13:18] <ogra_> ;)
[13:18] <pete-woods> trainguards: hi guys. is there anything I can do to get a silo assigned for line 50 of the CI sheet? (fixes a bug that makes location-dependent scopes blank at startup)
[13:18] <sil2100> ogra_: I'm not slacking! I'm being active on a meeting!
[13:18] <ogra_> plars, no ppa yet ... we're waiting ...
[13:18] <plars> heh, ok
[13:18] <ogra_> sil2100, yeah yeah ... i claim that too all the time :P
[13:19] <sil2100> ogra_: but yeah, I wonder - we'll do it for RTM
[13:19] <ogra_> (we should have pinged robru though ... and let you do your meeting ;) )
[13:19] <sil2100> ogra_: I think robru is still sleeping ;)
[13:19] <ogra_> sil2100, first we need it for utopic wheer we can then test ... by plars installing the silo package
[13:20] <ogra_> sil2100, how dare he !!!
[13:21] <sil2100> ogra_: hm, since basically we cannot release it for utopic right now, but ok - let me do the utopic silo first, sync to the rtm one and then only release RTM, waiting for utopic (or vivid) later on
[13:21] <ogra_> sil2100, right, thats why we need plars, he can pull from the PPA and manually trigger a test
[13:22] <ogra_> sil2100, once we see that brings things back to normal we then can do all the same steps for rtm (and actually land there properly) ... i'll take care to have olli approve it and have a bug etc etc
[13:22] <ogra_> for utopic it will simply stay stuck in utopic-proposed (archive wise)
[13:23] <sil2100> ogra_: silos assigned
[13:23] <sil2100> ogra_, veebers: the RTM silo is a sync silo, so build the utopic one first
[13:23] <veebers> sil2100: cool thanks, I'll click build now
[13:24] <ogra_> awesome
[13:25] <veebers> ogra_: 2 things to confirm :-) , apparmor/click.rules willstill be installed (via dbus-servie-properties right?) secondly I didn't actually remove the file in that MP so I'm doing that now (then will build)
[13:31] <Mirv> pete-woods: sure, assigning, it's even on the List so no problem. we just need pinging atm.
[13:31] <pete-woods> Mirv: okay, just pinged a few times and got nothing, so thought there must be a reason :)
[13:31] <pete-woods> thanks for the assign!
[13:32] <veebers> sil2100: ugh, failed build: https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/80/console
[13:32] <Mirv> pete-woods: oh, but you probably don't want to land to utopic anymore since the release is tomorrow and I think they asked to move to SRU mode nowish already.
[13:32] <Mirv> pete-woods-afk: so I'll change that to rtm if not a problem.
[13:32] <Mirv> pete-woods-afk: just the sprint hecticness and weariness I assume
[13:33] <thomi> ruh roh
[13:33] <veebers> ugh I know why
[13:33] <Mirv> and then the next release to vivid when it opens possibly on Friday
[13:33] <sil2100> veebers: looking, but hm, maybe there was something released but not merged in?
[13:34] <veebers> thomi, sil2100 : I made those changes to trunk not 1.5. I'll redo this in 1.5 (as there are things in trunk not released yet)
[13:34] <thomi> veebers: ahh, of course.
[13:34] <sil2100> veebers: ah, ok - just modify the MRs and let's reconfigure the silo
[13:34] <sil2100> And rebuild
[13:34] <thomi> veebers: we're still on track for the things in trunk to release this week tho, right?
[13:35] <thomi> sil2100: either way we need the changes in both trunk & 1.5 of course
[13:35] <veebers> thomi: trying to, currently blocked with getting this CI test passing still
[13:36] <veebers> thomi: I should remove debian/autopilot-touch.dirs as well as .install right?
[13:37] <ogra_> veebers, only in utopic yet
[13:37] <veebers> ogra_: sorry I don't understand that comment
[13:37] <ogra_> veebers, dbus-property-service (and the removal of AP from the image) only happened in utopic yet
[13:38] <ogra_> veebers, for rtm we should add dbus-property-service to your silo and also make sure to pull the ubuntu-touch-meta changes that remove AP in at the same time ... so for now, focus on utopic only
[13:38] <veebers> ogra_: ack, thanks
[13:39] <ogra_> until we verified it all works there
[13:41] <veebers> thomi, ogra_: if you could approve this MP I'll update the spreadsheet etc. https://code.launchpad.net/~veebers/autopilot/1.5-fixing-packaging-image-removal/+merge/239192
[13:42] <thomi> veebers: done
[13:42] <veebers> thanks thomi
[13:42] <sil2100> veebers: can I reconfigure now?
[13:42] <veebers> sil2100: is it cool if I just swap out the MRs in the spreadsheet that I've already filled in?
[13:42] <sil2100> Yeah
[13:42] <sil2100> :)
[13:43] <veebers> sil2100: heh, yep I've just updated the MR links now
[13:52] <ToyKeeper> tedg, charles: Any chance of an update on the silent-mode silo?  It has a couple issues: https://trello.com/c/1SD2iXGn/260-ubuntu-rtm-landing-025-indicator-sound-tedg
[13:53] <charles> ToyKeeper, /me looks
[13:59] <ToyKeeper> charles: Nothing appears to be an actual regression though, so we could probably land it if the test plan is updated to cover all the relevant behavior and expectations, then fix the three issues later.
[13:59] <veebers> trainguards, re: the exception error I see in my silo build, should I just try a re-build? (https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/81/console)
[13:59] <brendand> charles, if they have appropriate bugs raised already
[13:59] <charles> ToyKeeper, completely agree with you wrt the lack of manual tests, I commented on that in my merge review as well
[14:00] <charles> ToyKeeper, what I'm looking at now is trying to see what the state of the systems-settings <--> indicator sync bug is
[14:00] <sil2100> veebers: hm, yeah, I think this was some connection error
[14:00] <sil2100> Check if a re-run will help
[14:00] <charles> ToyKeeper, I believe this is yet another manifestation of https://bugs.launchpad.net/indicator-location/+bug/1336715
[14:00] <veebers> sil2100: ack, thanks
[14:01] <charles> ToyKeeper, which has been marked as fixed
[14:01] <charles> ToyKeeper, so I'm going to re-run https://code.launchpad.net/~nick-dedekind/unity8/lp1336715-checkable-bindings/+merge/234503/comments/582588 to see if that sync test works now
[14:02] <ToyKeeper> charles: If the sync issue requires other packages (system-settings) to fix, that can be landed later.  We should make sure there's a bug for it and that it's on olli's list somewhere.
[14:02] <ToyKeeper> charles: I'm filing the keyboard/dialpad silencing bug now.  Probably won't be fixed by rtm.
[14:03] <charles> yes, I know this is on dednick's and kgunn's TODO list. I don't see it tracked elsewhere so I'm going to re-open bug #1336715 for tracking
[14:03] <bdmurray> sil2100: What need to happen next with apport?
[14:03] <sil2100> bdmurray: ah, sorry, so many things going on
[14:04] <sil2100> bdmurray: so, you have a krillin ubuntu-rtm by any chance?
[14:04] <sil2100> bdmurray: if yes, then if you could just test install the package from the silo PPA and check if all is ok
[14:05] <charles> dednick, ToyKeeper, kgunn: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1336715/comments/14
[14:06] <ToyKeeper> charles: https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1384274  (needs triage)
[14:09] <ToyKeeper> charles: Thanks.  Could you update the indicator-sound test plan?  I think that's the last item remaining before it can land.
[14:11] <charles> ToyKeeper, I think ted is the better person to do that, but I will track him down and pester him to do that
[14:13] <charles> ToyKeeper, ...and he just walked in the door! Consider him nagged :)
[14:14] <ToyKeeper> tedg, charles: It just needs to verify the indicator's functions, expected behavior, and current bugs which interfere with anything it's supposed to do.
[14:20] <pete-woods-afk> Mirv: thanks, yes, that was a mistake
[14:29] <plars> sergiusens: that u-d-f is not backwards compatible at all
[14:29] <plars> sergiusens: I just tried it locally
[14:35] <ogra_> plars, what does that mean ?
[14:35] <ogra_> all official channnels should be installable with it
[14:36] <plars> ogra_: right, but it requires command line change, so we have no backwards compatibility with a deprecation plan - it just has to change all at once. This is what we talked about not wanting to do
[14:37] <plars> ogra_: it appears that we just need to specify the subcommand 'touch' now, but if you don't then it doesn't work
[14:37] <sergiusens> plars: weird, what command are you running?
[14:37] <plars> so it breaks us unless we simultaneously change the provisioning script
[14:37] <plars> ubuntu-device-flash --password ubuntuci --bootstrap --developer-mode --channel ubuntu-touch/devel-proposed
[14:37] <plars> unknown flag `password'
[14:37] <Saviq> trainguards, can I have a reconfigure on rtm silo 15 please
[14:38] <sergiusens> plars: ack, I'll fix; was something I missed
[14:38] <plars> sergiusens: thanks :)
[14:40] <dednick> charles: https://bugs.launchpad.net/indicator-network/+bug/1336715/comments/15
[14:42] <sergiusens> plars: so I see what's going on; mandel asked me to split the review and I messed up when splitting :-/
[14:43] <plars> sergiusens: no problem, I'm just trying it locally for now and I'll work on getting a regular job against this soon, so it will just test as part of the MP in the future
[14:47] <veebers> trainguards: What's the expected time taken to build a silo? Perhaps I'm being impatient. (https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/82/console)
[14:48] <sil2100> veebers: so, all packages are built now but are pending publication in the PPA still
[14:48] <veebers> sil2100: ah I see, thanks
[14:48] <sil2100> So it should be any minute now :)
[14:48] <veebers> sweet
[14:50] <sil2100> veebers: if, of course, the release guys didn't do something that just makes the publishers really busy
[14:50] <sil2100> Or something
[14:51] <veebers> sil2100: heh, understood
[14:59] <plars> veebers: concerning https://code.launchpad.net/~veebers/autopilot/1.5-fixing-packaging-image-removal/+merge/239192 - I notice it removes the click.rules
[15:00] <plars> veebers: does something else put those in place? iirc we need to use those during the testing process for autopilot to work properly
[15:00] <plars> maybe it's not needed anymore, but tradtionally we've had to call 'sudo aa-clickhook -f --include=/usr/share/autopilot-touch/apparmor/click.rules' to get things working properly
[15:01] <veebers> plars: right, this makes autopilot-touch a meta package that installs the dependencies. ogra_ has confirmed that that file is in a diffrent package now that is in the image
[15:01] <veebers> plars: ah ok, so  perhaps the path might change? ogra_ can you confirm?
[15:01] <ogra_> plars, dbus-property-service actually uses the file for the apparmor setup ... so it should ship it
[15:02] <ogra_> the path should still be the same
[15:02] <plars> ogra_: ack - that's good, as long as it comes from somewhere :)
[15:02] <ogra_> plars, right, and you shouldnt call aa-clickhook yourself
[15:02] <ogra_> phablet-config does that for you
[15:03] <plars> ogra_: so it looks like unity8-autopilot only recommends autopilot-touch, so we'll still need to force installation somewhere
[15:03] <ogra_> (whould be good to use it that way in smoke testing too, soo we see it in case  there is something wrong with it once)
[15:03] <ogra_> hmm, right
[15:04] <ogra_> plars, can we do that somewhere in utah ?
[15:08] <ToyKeeper> pete-woods: Not sure if you saw yesterday, but the thumbnailer silo (rtm-003) failed testing.  It doesn't appear to fix video rotation at all.
[15:09] <plars> ogra_: I can do it somewhere, but as we start to move to adt, I'm hopeful that it will get easier... iirc pitti said that just works in adt
[15:10] <ogra_> plars, right, we just need an interim solution for now
[15:11] <ogra_> and making ap-touch a hard dep of unity8-ap will likely break other stuff
[15:11] <cjwatson> sil2100: there was an accidental firewall downage earlier apparently
[15:11] <cjwatson> so that might have delayed stuff
[15:11] <cjwatson> veebers: ^-
[15:12] <sil2100> cjwatson: oh, ok, then something did happen to make it slower
[15:12] <balloons> woot, ogra_ I see ap dropped on the new image :-)
[15:12] <sil2100> cjwatson: thanks for the info, we're still waiting for the binaries to publish
[15:12] <ogra_> balloons, yeah, causing a lot of havoc in smoke testing :)
[15:12] <ogra_> it all comes at a price ;)
[15:13] <balloons> ogra_, right I saw the commentary. My expectation is some tests don't list autopilot as a proper dependency
[15:13] <ogra_> right
[15:13] <ogra_> well, in fact autopilot-touch
[15:13] <ogra_> (which pulls in the other bits as deps)
[15:14] <balloons> so why the concern listing ap-touch as a depends will break something?
[15:15] <ogra_> balloons, because it might break unity8 tests on desktop
[15:15] <ogra_> there must be a reason it was made only a recommends and not a depends
[15:16] <ogra_> (if there isnt it should indeed be bumped up to a hard dep)
[15:16] <ogra_> for now we first need to get test going again though ... we can then look into the rest
[15:16] <ogra_> *testing
[15:24] <veebers> cjwatson: ah I see, thanks
[15:25] <ogra_> veebers, i added proper paperwork to bug 1383479 ... so olli knows where your landing belongs to
[15:25] <veebers> ogra_: excellent, thanks for doing that
[15:29] <sil2100> cjwatson: btw. do you know if the firewall issue got fixed?
[15:29] <sil2100> cjwatson: since I see that the autopilot packages still didn't get published
[15:29] <cjwatson> sil2100: where should those be?
[15:30] <sil2100> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004/+packages
[15:30] <sil2100> We're waiting for the publisher to pick them up since over 40 minutes
[15:30] <cjwatson> ok that does seem rather bad
[15:30] <cjwatson> let me look
[15:37] <pete-woods> ToyKeeper: thanks. just pinging the tester (satoris) about it
[15:38] <ToyKeeper> pete-woods: I'm actually retesting it now with rtm-016 added, to see if the changes are more visible together.
[15:39] <cjwatson> sil2100: working on it with IS, was stuck due to firewall outage earlier
[15:39] <sil2100> cjwatson: ah, ok, thanks a lot :)
[15:43] <cjwatson> sil2100: unwedged; you should see things moving soon
[15:44] <pete-woods> ToyKeeper: according to Satoris, you definitely need both for it to be fixed
[15:47] <satoris> ToyKeeper: so the reason they were proposed separately was that at the time there was no clear timeline when the gstreamer changes would land and having the fix in thumbnailer would make it immediately obvious to jhodapp whether he is doing the right thing.
[15:47] <satoris> Should have explained this better in the silo request. Sorry about that.
[15:53] <veebers> plars, ogra_ sweet, looks like the ppa now has the packages from the silo build
[15:53] <jdstrand> can I have a silo for line 86?
[15:58] <ToyKeeper> pete-woods, satoris: Test results for rtm-003 + rtm-016 look good.  I hear that 16 has a bug and may need some changes, but it seems fine for 3 to land by itself.
[15:58] <Mirv> what's wrong with jenkins hmm..
[15:58] <Mirv> ToyKeeper: excellent! I'll publish 003 then
[15:59] <ToyKeeper> pete-woods, satoris: For similar changes in the future though, please include a note that it depends on another silo in order to function.  :)
[15:59] <veebers> plars, ogra_: That's all we need to run a test right?
[15:59] <pete-woods> ToyKeeper: noted!
[16:00] <brendand> ToyKeeper, i think they should land together
[16:01] <ToyKeeper> brendand: rtm-003 doesn't break anything, it just allows later changes to work.
[16:02] <ToyKeeper> brendand: It'd be ideal to land everything as one logical change, but in this case it seems there no harm in landing thumbnailer first by itself.
[16:02] <satoris> brendand: silo 3 is basically "if someone has set the orientation tag, use it". So if there are videos that already have that then they will work.
[16:03] <satoris> Silo 16 is then about setting the tag inside gstreamer for files created by the phone.
[16:03] <alecu> ToyKeeper: thanks for finding out that our silo contains branches for bugs that we are not supposed to land yet. We are reconfiguring it and we will follow the testplan on it as soon as the trains rebuilds. Sorry for the annoyance; we'll ask you to re-review it later today.
[16:04] <brendand> ToyKeeper, satoris - true i guess. and 16 should land soon hopefully
[16:07] <Mirv> Saviq: reconfig done. the automatic function was somehow broken, needed to type in stuff manually.
[16:07] <Mirv> sil2100: ^ for some reason the reconfig (prepare-silo) just gave me an empty page no matter what I did, after clicking the Proceed button
[16:08] <ToyKeeper> alecu: Ah, I actually was hoping to land all of that since it all seemed important.  For today's bug review meeting, I recommended landing the whole silo...  but I haven't heard yet what was decided.
[16:14] <alecu> ToyKeeper: ah, that sounds great. We'll have to re-rebuild the silo anyway...
[16:15] <ToyKeeper> alecu: Not my call though; waiting on olli to confirm what's landable.
[16:50] <plars> ogra_: doesn't look like it worked :( http://paste.ubuntu.com/8629765/
[16:51] <plars>  *** 1.5.0+14.10.20141022-0ubuntu1 0
[16:51] <plars>         500 http://ppa.launchpad.net/ci-train-ppa-service/landing-004/ubuntu/ utopic/main armhf Packages
[16:53] <plars> ogra_: here's the other relevant portion from when it installed autopilot-touch: http://paste.ubuntu.com/8629802/
[16:53] <plars> see if I can grab thomi later and ask him since veebers is offline now
[17:25] <veebers> plars: hey touching base re: the autopilot removal from image testing. (was offline for a bit). Any luck with that?
[17:26] <sil2100> brendand, davmor2, elopio: just making sure that's known - silo 24 got an approval from product team that it can land
[17:26] <sil2100> ToyKeeper: ^
[17:26] <sil2100> So if you have a moment, please move it to the 'Needs testing' in your trello-board
[17:27] <brendand> sil2100, ok
[17:28] <plars> veebers: no, it didn't seem to work: see http://paste.ubuntu.com/8629765/ and http://paste.ubuntu.com/8629802/
[17:29] <ogra_> plars, autopilot-qt4 ??
[17:30] <ogra_> how does that get there ?
[17:32] <veebers> ogra_, plars: yeah not sure where autopilot-qt4 comes from, autopilot-touch depends on autopilot-qt5 & qttestability-autopilot
[17:33] <plars> veebers: ogra_: no idea -maybe unity8-autopilot?
[17:34] <ogra_> i dont see it in the Depends line
[17:34] <plars> yes, looks like
[17:34] <veebers> plars: I don't see autopilot-touch in that pastebin at all
[17:34] <plars> ogra_: but that's when it's getting installed, when it asks for unity8-autopilot
[17:34] <plars> veebers: it's in the first one
[17:34] <ogra_> yes, i see the log
[17:34] <veebers> plars: ah I see oops
[17:34] <ogra_> i just dont get why .... there are no Qt4 deps anywhere
[17:35] <ogra_> Depends: gir1.2-glib-2.0, libautopilot-qt (>= 1.4), libqt5test5, libqt5widgets5, python-autopilot, python-evdev, python-fixtures, python-gi, python-mock, python3-autopilot, python3-evdev, python3-fixtures, python3-gi, ubuntu-ui-toolkit-autopilot, unity8 (= 8.00+14.10.20141013.2-0ubuntu1), unity8-fake-env (= 8.00+14.10.20141013.2-0ubuntu1), url-dispatcher-tools, python3:any (>= 3.3.2-2~), python (>= 2.7), python (<< 2.8)
[17:35] <plars> ogra_: according to rdepends - libautopilot-qt
[17:36] <plars> which I think is required for unity8-autopilot
[17:36] <plars> veebers: so is autopilot-qt4 what's messing it up?
[17:36] <ogra_> ogra@styx:~/Devel$ apt-cache show libautopilot-qt|grep Depends
[17:36] <ogra_> Depends: autopilot-qt4, autopilot-qt5, qttestability-autopilot
[17:37] <ogra_> why is that not an | dependency
[17:37] <veebers> ogra_: I think the lack of libautopilot-qt5 is causing the error
[17:37] <veebers> due to the testability library not being loaded
[17:38] <veebers> (see line 449 in that first pastebin)
[17:38] <ogra_> veebers, well, but unity8-ap seemingly has a hard dep on libautopilot-qt ... which in turn will always pull in the qt4 stuff .... which sounds like at least a waste if it doesnt do harm
[17:39] <plars> veebers: ogra_: I can easily try installing libautopilot-qt5 and see if it works with that
[17:39] <veebers> ogra_: right, it does sound like a wast
[17:39] <ogra_> plars, ++
[17:39] <veebers> plars: sounds good
[17:39] <plars> oh
[17:39] <plars> E: Unable to locate package libautopilot-qt5
[17:39] <plars> ?!
[17:39] <ogra_> wow
[17:40] <ogra_> try without "lib" perhaps
[17:40] <plars> ogra_: autopilot-qt5 is already installed
[17:40] <ogra_> (that at least exists )
[17:40] <balloons> the toolkit brings in qt4 stuff
[17:41] <balloons> if i remember correctly
[17:43] <ogra_> hmm
[17:43] <balloons> specifically the ubuntu-ui-toolkit-autopilot, due to legacy stufff
[17:44] <ogra_> the second paste looks quite okay ... what is that from ?
[17:45] <veebers> ogra_, plars: rats, I think that was a wild goose chase, now that I look closer I see "Testability driver loaded. Wire protocol version is "1.4"." (which indicates that it's loaded fine)
[17:46] <jdstrand> mandel: hi! it turns out we are missing an apparmor rule for apps to successfully use download manager: bug #1384349
[17:47] <ogra_> are we sure webbrowser actually worked in recent images ?
[17:47] <sil2100> ToyKeeper: yea, so 24 doesn't have a general test plan as it's a very low level component that usually lands straight into the archive
[17:47] <veebers> plars: I see this "pull: /var/crash/_usr_bin_autopilot3.32011.crash" is there anything of interest in that?
[17:47] <veebers> ogra_: that is a good question too
[17:47] <ToyKeeper> sil2100: I'm looking into more details now; might be able to find a way to test it.
[17:47] <mandel> jdstrand, ok, will look at it asap
[17:47] <jdstrand> mandel: I wanted to confirm that ~/.local/share/ubuntu-download-manager/<click pkgname> is intended
[17:47] <sil2100> ToyKeeper: normally it would land without QA sign-off even, but elopio wanted to make double sure it's not breaking anything
[17:47]  * ogra_ twiddles thumbs ... slow dashboard is slow
[17:47] <jdstrand> mandel: nah, it is for me to fix
[17:48] <sil2100> ToyKeeper: the bug should have all the details for the bug itself I guess
[17:48] <jdstrand> mandel: I just wanted to double check with you before adding it
[17:48] <cjwatson> sil2100: everything all well now from the point of view of PPA publishing?
[17:49] <sil2100> cjwatson: thanks, all seems to go smoothly now :)
[17:50] <ogra_> plars, http://ci.ubuntu.com/smokeng/utopic/touch/mako/293:20141020:20141017.2/11059/webbrowser_app/ looks like it failed since a while already ... (thats 293) ... i guess we should pick another package
[17:52] <cjwatson> sil2100: cool
[17:54] <plars> ogra_: ah, good catch. I'll try unity8 instead
[17:55] <ogra_> yeah
[17:58] <jdstrand> mandel: so, I was thinking these would be the rules I would apply:
[17:58] <jdstrand> owner @{HOME}/.local/share/ubuntu-download-manager/@{APP_PKGNAME}/   r,
[17:58] <jdstrand> owner @{HOME}/.local/share/ubuntu-download-manager/@{APP_PKGNAME}/** rk,
[17:59] <veebers> ogra_: good catch
[17:59] <jdstrand> mandel: ie, read-only access. this is what we do with content hub for example. does this sound reasonable?
[18:05] <robru>  fginther / cihelp:  any known issues with jenkins? https://code.launchpad.net/~robru/cupstream2distro/obliterate-preprod-bs/+merge/239143 is waiting on CI for nearly 1.5 hours
[18:09] <ogra_> traffic jam ?
[18:09] <ogra_> :)
[18:09] <robru> ogra_: http://s-jenkins.ubuntu-ci:8080/job/cu2d-choo-choo-ci/ ci job hasn't ran in 12 hours
[18:09] <ev> robru: please don't ping people directly - that's why we have the vanguard
[18:09] <plars> ogra_: hmm, I just noticed that unity8 probably won't tell us much - that one was working
[18:09] <plars> even in 296
[18:10] <robru> ev: i pinged the vanguard ;-)
[18:10] <ev> robru: and Francis :)
[18:11] <ogra_> plars, system-settings ?
[18:12] <ogra_> or address_bok
[18:12] <ogra_> *book
[18:20] <plars> ogra_: ok, this is the one where we see the infinite loop of:
[18:20] <plars> 18:19:50.277 DEBUG _uinput:541 - Dragging from 270,481 to 270,325
[18:20] <plars> ogra_: I'm reproducing it locally even with the new autopilot, so no improvement there, but this could be a test case issue
[18:20] <plars> ogra_: I can confirm the screen is unlocked though, so this has nothing to do with the screen unlock status
[18:21] <plars> ogra_: sil2100: I'm starting to think we just have a whole lot of test issues that need to be tracked down
[18:22] <plars> sil2100: ogra_: fwiw, in the ubuntu-system-settings case, it seems to be sitting on the "Cellular" screen in u-s-s, waiting for something that never happens
[18:22] <plars> ubuntu_system_settings.tests.test_cellular.DualSimCellularTestCase.test_changing_sim1_name is the test
[18:22] <psivaa_> robru: i'll take a look at that
[18:23] <plars> the screen I'm looking at doesn't seem to be a slider though, it's a checkmark next to sim1 or sim2, so I'm not sure why it's trying to drag?
[18:23] <plars> I think this is just a test that needs fixing
[18:23] <sil2100> Yeah, our tests have gone bad
[18:23] <robru> psivaa_: thanks
[18:25] <barry> mandel: hiya
[18:30] <jdstrand> mandel: so, the rules I pasted work for beru. can you confirm they are ok and what you expect?
[18:31] <mandel> jdstrand, give me a few second
[18:34] <boiko> trainguards: can I get a silo for row 87? not urgent if low on silos (no critical bugs, just regular rtm/ota bugfixes)
[18:36] <plars> ogra_: veebers: it's worth noting that ubuntuuitoolkit seems to get that same error as webbrowser app on krillin, so it doesn't seem isolated to one test
[18:37] <ogra_> plars, hmpf
[18:37] <veebers> plars: :-\ hmm do you have pastebin of the output?
[18:38] <plars> veebers: http://paste.ubuntu.com/8629765/
[18:38] <veebers> thanks
[18:38] <ogra_> plars, again ... it has that on 293 too
[18:38] <ogra_> (uitk)
[18:39] <plars> ogra_: I know, but we're seeing a lot of failures, are we really sure that there was a regression with this autopilot removal?
[18:39] <veebers> plars: that looks like webbrowser tests not uuitk (unless I missed something)
[18:39] <ogra_> plars, not at all :P
[18:40] <ogra_> veebers, https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/1062/consoleFull thats the console log from 293 (before dropping AP)  ... it has the UITK pfailure there
[18:41] <ogra_> plars, we have two probs now .... utopic is closed ... and i'm scared to make the same change in rtm without knowing we actually didnt cause a regression
[18:41] <ogra_> plars, but i fear thats the only way to go now
[18:41] <ogra_> plars, UITK has a fix from ricmm in some silo i think
[18:42] <cjwatson> you can still land things in utopic provided that they absolutely do not touch the other images
[18:42] <cjwatson> at least to some extent
[18:42] <ogra_> oh, wait, but thats something different
[18:42] <veebers> ogra_, plars: So I'm seeing passing tests in that link, so things aren't completly broken (i.e _something_ works)
[18:42] <plars> ogra_: we should talk to sil2100, but from my perspective, we have plenty of issues to deal with even without the removal of autopilot, and while nice to have, I don't think there's any critical need to remove it immediately
[18:42] <plars> ogra_: sil2100: I think we should get people huting down these ap test regressions asap though
[18:42] <ogra_> cjwatson, right, but we're not sure if anything will help and i dont want to break it even more and then be trapped by hard freeze
[18:42] <plars> veebers: yes, it seems a few will pass, then a traceback
[18:43] <cjwatson> ogra_: Yeah
[18:43] <ogra_> plars, yeah ... but i'm a bit unhappy to have the distros out of sync now ...
[18:43] <ogra_> and AP dropping will give us pleanty of space
[18:44] <ogra_> *plenty
[18:44] <ogra_> krillin 122 looks actually pretty good
[18:44] <ogra_> plars, did you have to manually intervene there ?
[18:44] <veebers> plars: hmm, I'm looking through to see if there are passing tests that use taps and/or drags etc. in case the input stuff is broken somehow
[18:44] <bdmurray> Does the fix for bug 1339916 need to be added to the wishlist spreadsheet?
[18:45] <sil2100> plars, ogra_: yeah, so we should do that, but not sure if we'll get those down this week
[18:45] <ogra_> bdmurray, yes, talk to olli or pmcgowan to get it added ... you need to mark it critical and tag it wwith rtm14
[18:46] <ogra_> sil2100, plars are you guys at the same place atm ?
[18:46] <plars> ogra_: nope, I didn't touch the 122 run
[18:46] <ogra_> plars, wow
[18:46] <ogra_> thats pretty good news then
[18:46] <sil2100> ogra_: I'm on the 'Click packaging and CI' meeting
[18:46] <plars> ogra_: no, but I just saw the time, I think I'm missing a session
[18:46] <ogra_> k
[18:46] <bdmurray> ogra_: talk to them and change the bug?
[18:46] <ogra_> bdmurray, right
[18:47] <ogra_> sil2100, plars, i think we should discuss that in person once we have a min to sit down
[18:47] <sil2100> ogra_: we have a landing meeting today, we can have a quick chat during that
[18:47] <psivaa_> robru: please check those two mp's. it could be that both the proposed branch and the pre-requisite branch being updated being the reason for the jenkins not triggering
[18:47] <ogra_> sil2100, ok
[18:48] <robru> psivaa_: it seems they've both run now, thanks for looking
[18:48] <ogra_> psivaa_, i assume you didnt touch rtm krillin 122 either ?
[18:48] <ogra_> (just to make sure)
[18:50] <pmcgowan> bdmurray, dont tag it just put it in the spreadsheet in the email
[18:51] <jdstrand> trainguards: may I have a silo for line 86?
[18:52] <robru> boiko: oopps, i tried to assign yours but there were conflicts: https://ci-train.ubuntu.com/job/prepare-silo/2886/console
[18:52] <boiko> robru: let me check what is in other silos
[18:53] <boiko> robru: in any case, this is not landing anytime soon, so conflicts are fine
[18:53] <robru> boiko: ok
[18:53] <robru> jdstrand: rtm 3
[18:53] <plars> ogra_: ah, I know one reason things did better on that run - it looks like dropping letters is gone from that image now too - so no infinite loop
[18:53] <ogra_> plars, thats weird, i wonder who removed it without telling anyone
[18:53] <plars> ogra_: which means the test didn't take hours before getting the job killed and taking out the tests after it
[18:54] <boiko> robru: on a different topic, I have a silo that was targetting utopic, would it be possible to change it to target rtm?
[18:54] <plars> ogra_: at least from the dropping letters result, it looks like it's not there
[18:54] <robru> boiko: well we'd have to toss the silo and reassign. which one?
[18:54] <ogra_> plars, given that we can still add/remove stuff in rtm i would really like to do the change there though ... since there we definitely have the option to roll back
[18:54] <boiko> robru: row 40 (utopic silo 001)
[18:54] <robru> boiko: ok line 87 got rtm 26
[18:55] <boiko> robru: nice! thanks!
[18:55] <ogra_> plars, especially now that we have a complete run and can judge it based on this
[18:55] <ogra_> (which we had not in weeks for utopic)
[18:57] <robru> boiko: so row 40 is just a sync? row 39 implies the same stuff already landed in rtm
[18:57] <boiko> robru: oh, wait, hmm
[18:57] <robru> boiko: heh, I already freed it. sorry
[18:58] <boiko> robru: sorry for the confusion, I was not checking the spreadsheet, I was using the dashboard :/
[18:59] <robru> boiko: but still there was some reason you wanted to give up landing in utopic? can it wait for vivid perhaps?
[18:59] <boiko> robru: not really, it is just that I didn't realize it was already landed in rtm and I was going to land it there first :)
[18:59] <robru> boiko: ok so you want me to reassign the sync then?
[19:00] <boiko> robru: I think so, if that's not much trouble for you
[19:00] <robru> boiko: no worries
[19:00] <robru> boiko: you'll just have to resync
[19:00] <robru> (rebuild)
[19:03] <robru> boiko: sorry, 'sync:2' syntax was stale, started syncing somebody else's silo. assigning real sync silo now
[19:04] <robru> boiko: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-016 ok you're in 16 now, please hit build to trigger a binary copy from rtm to utopic
[19:05] <boiko> robru: thanks!
[19:05] <robru> boiko: you're welcome~!
[19:05]  * robru -> lunch
[19:07] <psivaa_> ogra_: nope, i dint touch rtm krillin 122 :)
[19:07] <ogra_> \o/
[19:07] <ogra_> thats awesome :)
[19:08] <mandel> jdstrand, the download manager should be downloading files to the following dir for confined apps => QStandardPaths::DataLocation/APP_ID/Downloads
[19:08] <mandel> jdstrand, the path ~/.local/share/ubuntu-download-manager/Downloads is for unonfined apps
[19:08] <jdstrand> oh
[19:08] <jdstrand> huh
[19:08]  * jdstrand scratches head
[19:09] <mandel> jdstrand, let me check the bug
[19:09] <jdstrand> cause the denial is for ~/.local/share/ubuntu-download-manager/@{APP_PKGNAME}/
[19:09] <jdstrand> mandel: ^
[19:10] <jdstrand> and said app is clearly confined (you can tell by profile name in the bug's denial
[19:11] <jdstrand> mandel: note: I chopped off Downloads/ from the path, but it is there in the denial
[19:12] <mandel> jdstrand, yes, sorry QStandardPaths::DataLocation defaults to /home/phablet/.local/share/ubuntu-download-manager/ so you are correct
[19:12] <jdstrand> ah, ok
[19:12] <mandel> jdstrand, should be /home/phablet/.local/share/ubuntu-download-manager/ + APP_ID
[19:12] <jdstrand> mandel: and read-only is ok by you?
[19:13] <jdstrand> mandel: (readonly worked for beru)
[19:13] <mandel> jdstrand, well, we have an issue if it is readonly, if it is readonly the app will not be able to delete the files and the user will have to do manually
[19:14] <jdstrand> that makes sense
[19:14] <jdstrand> ok, thanks
[19:14] <veebers> ogra_: so looking at the link of yours (before ap removal) and the results of the run plars did, I'm not sure the removal of ap from the image introduced any regressions, the are so many failures etc. in the run before hand it's hard to tell
[19:14] <jdstrand> it's app-specific, so that's cool
[19:14] <mandel> jdstrand, read-write sounds goods since the path is only for the application and that way they can delete the downloads that are not longer needed, right?
[19:14] <om26er> bzoltan, ^
[19:14] <jdstrand> mandel: ok, thanks! I'm on it
[19:14] <mandel> jdstrand, awesome!
[19:14] <jdstrand> mandel: yes, it's fine security wise, just different from content-hub so wanted to double check if write was needed
[19:15] <ogra_> veebers, right, this is why i would like to do it in rtm ... with the successfull test run of image 122 we have a good datapoint to look at tomorrow then ... and decide to roll back or keep the change
[19:15] <ogra_> veebers, but i want sil2100 and plars to agree to that plan :)
[19:15] <plars> veebers: do you know if this timeout option in autopilot ever landed, so that tests won't run forever?
[19:16] <veebers> ogra_: ah I see, sorry I'm caught up now :-)
[19:16] <sil2100> Which plan? I'm a bit all around the place today
[19:16] <veebers> plars: I'm wanting to land that this week (somewhere) but it hasn't landed yet sorry
[19:16] <mandel> jdstrand, no idea on the file management by the content-hub, I just want to make sure that we don't have phones that are full of downloads and the user has to manually deal with them
[19:16] <ogra_> sil2100, *the* plaaan !
[19:16] <plars> ogra_: I'd prefer to see more of a trend - I think we got lucky in 122 because of the mysterious dropping_letters removal
[19:16] <veebers> plars: but that code exists in an approved MP, just not release yet
[19:17] <ogra_> plars, i'll try to find oout how it got removed
[19:17] <plars> ogra_: and I'd really prefer to get some autopilot test experts on figuring out what can be done about these failing tests - we've built up a bit of a backlog of those
[19:17] <plars> veebers: I've heard that phablet-test-run will need to pass it some new parameters when that lands?
[19:17] <ogra_> plars, you mean on utopic ? we cant really do much anymore ... in less than 24h utopic will close down
[19:18] <ogra_> plars, we will have to look at rtm only for now
[19:18] <plars> ogra_: on everything
[19:18] <veebers> plars: yes. It adds the command line option "--test-timeout=<seconds>" inwhich it attempts to kill and fail the test after <seconds>.
[19:19] <bzoltan> om26er: Thank you. kalikiana will explain what the system settings should do in order to fix that dialog.
[19:19] <ogra_> plars, the thing is, if we dont do the AP removal here where we are all on the same TZ, i fear we wont be able to easily do it at all ... and it only costs us a roll-back if it isnt successful
[19:19] <plars> ogra_: I could probably reduce the noise a bit by adjusting systemsettle if we really got approval on that - I don't think I ever heard confirmation
[19:19] <ogra_> i dont think it was ever properly discussed with the mgmt
[19:20] <plars> ogra_: is that less of a pain if we are all traveling vs doing it remotely though?
[19:20] <ogra_> (i know you said you brought it up somewhere but we never heard back)
[19:20] <plars> ogra_: no, sil2100 said it was ok'd but I don't recall details of someone saying this
[19:20] <ogra_> plars, it is less of a pain when doing it today, see if the results differ from 122 and roll back tomorrow
[19:20] <ogra_> i wouldnt do it on friday indeed :)
[19:21] <plars> ogra_: indeed, I'm fine with that if sil2100 is
[19:21] <sil2100> Wait, is this about the threasholds, or about something else?
[19:21] <plars> sil2100: both
[19:21] <ogra_> sil2100, this is about AP removal ...
[19:21] <ogra_> sil2100, and the threshold
[19:22] <sil2100> ogra_: so, about the thresholds asac said a +1 on adjusting them some time ago
[19:22] <sil2100> The AP removal seems to work nicely on utopic now, right?
[19:22] <ogra_> sil2100, the rob with the AP removal in utopic is that we cant really tell anything ... which makes me think i would really like to do them in rtm
[19:23] <sil2100> Due to tests being broken?
[19:23] <ogra_> sil2100, no idea, we havent had any older results to actually make a judgement on
[19:23] <ogra_> right
[19:23] <ogra_> utopic was to broken for to long to actually pinpoint if the AP removal had any actual effect on tests
[19:24] <sil2100> ogra_: do we need to land any autopilot changes when doing that, or just removing the AP-packages is enough by itself?
[19:24] <ogra_> sil2100, OTOH rtm has the first complete test run since days today
[19:24] <sil2100> (as per the earlier AP change proposed, but I think that wasn't required?)
[19:24] <ogra_> which gives us a nice datapoint to compare with
[19:24] <ogra_> sil2100, AP, dbus-property-service and an ubuntu-touch- meta change
[19:25] <ogra_> sil2100, when we do it today while we are all here it will be way easier to coordinate the roll back if needed
[19:25] <sil2100> Ok then, let's make the final decision on the landing meeting, but so far I think we can take the risk, since I see that those should be easily revertable
[19:25] <ogra_> right
[19:26] <sil2100> ANd we don't have any image required to build for propotion anyway
[19:26] <sil2100> *promotion
[19:26] <ogra_> right
[19:26] <sil2100> Ok, I need to find slangasek now
[19:26] <sil2100> brb
[19:29] <jhodapp> sil2100, rtm silo 16 is ready for landing (brendand gave QA approval)
[19:30] <jhodapp> or robru ^
[19:33] <jdstrand> mandel: re full uploads> yep, ack. on it
[19:38] <Mirv> jhodapp: so it seems according to trello, spreadsheet is slightly broken again with its status update feature
[19:39] <Mirv> jhodapp: ^ https://code.launchpad.net/~jhodapp/qtubuntu-media/orientation/+merge/238357 is not top-approved
[19:40] <jhodapp> Mirv, ok, let me get someone to approve
[19:43] <jhodapp> Mirv, ok, it's approved now
[19:50] <Mirv> jhodapp: ^ done
[19:50] <jhodapp> Mirv, thanks!
[19:51] <Mirv> brendand: om26er: rtm-007 claims to be QA Sign-off:d, but I don't find that to be the case on trello?
[19:52] <Mirv> better just to not mark it Granted, , as it's in the Blocked column
[19:53] <brendand> Mirv, might have been a mistake on my part
[19:53] <brendand> Mirv, maybe i got the wrong row
[19:54] <Mirv> it's line 32
[19:56] <veebers> plars, ogra_: I went offline during the discussion re: removal of ap from image. Where do we currently stand, are we waiting for tomorrow for a test run?
[19:57] <ogra_> veebers, verdict was that it should be discussed at the landing team meeting (in ~30min)
[19:57] <ogra_> but we seem to be all in favour of doing it now rather than later
[19:57] <veebers> ogra_: ah ok, please let me know the result :-)
[19:58] <ogra_> veebers, indeed :) (if you have time you could even attend ... )
[19:59] <ogra_> sil2100, plars , so i asked asac about the systemsettle adjustment and he suggested we should let it sign off by QA
[20:00] <plars> ogra_: ok, davmor2?
[20:00] <ogra_> hehe
[20:00] <plars> :)
[20:01] <davmor2> plars: not one for me, you'll want jibel for that
[20:01] <ogra_> lol
[20:01] <ogra_> pass the bucket :)
[20:03] <sil2100> )
[20:03] <sil2100> ;)
[20:04] <veebers> ogra_: sorry just in the middle of something
[20:05] <brendand> Mirv, 25 signed off?
[20:05] <ogra_> yeah, was just an offer :)
[20:05] <brendand> ah yeah
[20:07] <Mirv> brendand: apparently by ToyKeeper, yes
[20:07] <brendand> Mirv, yeah that's ok
[20:07] <Mirv> nice
[20:07] <brendand> Mirv, i missed it on our board
[20:15] <mandel> sil2100, can you please get me asilo for line 88 asap, is quite important for the location service
[20:16] <Mirv> mandel: may I? :) ping trainguards in general
[20:16] <sil2100> Sure ^ I'm in a meeting now
[20:16] <mandel> Mirv, sure, sorry, I'm used "bully" him hehe
[20:16] <mandel> sil2100, sorry!
[20:17] <Mirv> mandel: heh. rtm-024.
[20:17] <mandel> Mirv, argh, autocomplete
[20:19] <brendand> alecu, there's a problem with silo 5
[20:22] <ToyKeeper> brendand, Mirv: Yes, rtm-025 just needed some test plan updates.  There are bugs, but no regressions, and they can be fixed later.
[20:23] <ToyKeeper> brendand: Last I heard, alecu is building silo 5 with the original packages it had yesterday, so they can all land.  What is the problem with it?
[20:24]  * alecu listens intently
[20:24] <brendand> and now the problem is gone
[20:24] <brendand> weird
[20:24] <alecu> awesome! I love the kind of problems that go away by themselves
[20:25] <alecu> brendand: I just rebuilt the package with the four branches from yesterday, perhaps it was finishing the build and that made things weird on the spreadsheet or on the dashboard
[20:26] <brendand>  alecu , maybe
[20:26] <brendand> alecu, it seems ok now
[20:26] <alecu> great
[20:27] <sil2100> robru: you around for the meeting in 3 minutes?
[20:28] <robru> yep
[20:28] <robru> sil2100: hm, the event doesn't have a video thing
[20:28] <sil2100> robru: we'll use one of the old HO and send you a link, want everyone to gather first
[20:28] <sil2100> (maybe someone will have a charger)
[20:29] <robru> sil2100: ah, i added a video thing... if that doesn't work then send me a link i guess
[20:33] <Mirv> robru: https://plus.google.com/hangouts/_/canonical.com/landing-task?authuser=1
[20:33] <brendand> alecu, are you confident your test plan is up-to-date with tests for the bug fixes?
[20:33] <sil2100> ogra_: istambul!
[20:34] <brendand> alecu, it hasn't been updated in a couple of weeks
[20:35] <ogra_> sil2100, yeah, next to las vegas
[20:35] <ogra_> (americans and geography ... )
[20:42] <kenvandine> robru, what's the current rule for landings in utopic?  can we still publish silos for fixes that are on the allowed list?
[20:43] <robru> kenvandine: not sure, ask cjwatson? IIRC you can land stuff as long as it doesn't touch the desktop image or any *buntu images)
[20:43] <kenvandine> just making sure it's ok to land in utopic then sync to rtm
[20:44] <kenvandine> not in the desktop image
[20:57] <ToyKeeper> alecu: silo 5 might take a bit longer to start testing; most of the testers are about to be in a big and possibly long meeting.
[20:57]  * ToyKeeper biab
[21:00] <slangasek> ogra_: http://people.canonical.com/~lzemczak/landing-team/ubuntu/289.commitlog
[21:02] <bzoltan> elopio: Mirv: That desktop file fix is good
[21:11] <veebers> wait, I don't remember adding that line to the spreadsheet.
[21:11]  * veebers looks at ogra_
[21:12] <robru> veebers: oh yeah I'm shuffling that around a bit at the request of ogra
[21:12] <cjwatson> robru: that's correct yeah
[21:12] <ogra_> veebers, to land it we need the new meta and dbus-property service land in parallel
[21:12] <cjwatson> though there will be a practical cutoff pretty soon
[21:13] <ogra_> veebers, meta gets pushed to rtm-proposed directly via copy-package from utopic once the silo lands
[21:13] <robru> ogra_: Mirv: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-014-1-build/35/console mp building in rtm & sync should happen after that builds
[21:13] <ogra_> robru, cool
[21:14] <veebers> ogra_, robru: It looks like there was a decision about removing autopilot from the image? (as per ubuntu/landing-004 (veebers) Gave up this landing)
[21:14] <ogra_> cjwatson, do we go on pushing into utopic-proposed to then sync into vivid from that ? (that is how i imagine the process after release at least)
[21:14] <robru> veebers: well the decision was to land it just in rtm without utopic
[21:14] <cjwatson> err no, should be pushing to vivid
[21:15] <ogra_> cjwatson, oh, is it open already ?
[21:15] <cjwatson> there'll be a day or two where everything will be held in queues, as short as we can make it
[21:15]  * ogra_ wasnt aware
[21:15] <ogra_> ah, k
[21:15] <cjwatson> I thought you meant after release
[21:15] <ogra_> no, i meant thhis week :)
[21:15] <cjwatson> from now until vivid opens you should go on pushing to utopic-proposed, but no guarantees of acceptance
[21:15] <ogra_> k
[21:15] <cjwatson> but you did say "that is how i imagine the process after release at least"
[21:15] <cjwatson> after this release we open the next release ASAP
[21:16] <ogra_> heh, well, after tomorrow til vivid opens
[21:16] <ogra_> sorry, i wasnt clear
[21:16] <cjwatson> normally we just don't accept anything in that window
[21:16] <ogra_> k
[21:16] <cjwatson> but we will see, better to push to utopic than nowhere I guess ... might confuse us
[21:16] <ogra_> (fine with me ... and less work for th elanding team)
[21:17] <cjwatson> apparently there are rather few if any relevant toolchain changes pending
[21:17] <cjwatson> so my guess is that opening will be pretty quick this time round
[21:20] <sil2100> cjwatson: ping :)
[21:20] <cjwatson> sil2100: hi
[21:20] <cjwatson> oh /msg
[21:20]  * sil2100 likes whispering
[21:21] <Mirv> secrets!
[21:27] <ogra_> sil2100, hmm, the click_image_tests broke a wwhile ago it seems ... i assume thats related to slangasek and cjwatson moving the clicks around ?
[21:27] <sil2100> ogra_: might be? How is it failing?
[21:28] <ogra_> sil2100, no idea, i only checked the tests for the last few images
[21:29] <ogra_> (results i mean)
[21:34] <ogra_> sil2100, click_image_tests seem to have been successfull in 106 last
[21:35] <sil2100> hmm
[21:35] <ogra_> oh, wait, i'm wrong
[21:35] <sil2100> Later? Or earlier?
[21:35] <ogra_> 108 last
[21:35] <ogra_> failed in 109 for the first time and constantly since
[21:37] <sil2100> ogra_: do you know if we list whenever we remove click packages from the rootfs?
[21:37] <sil2100> Since I've been trying to find out when the click-strip-off happened, since I guess it was around those images
[21:37] <ogra_> nope, only upgrades of them
[21:38] <ogra_> no, it was later
[21:38] <ogra_> iirc it was the night before we promoted the candidate
[21:38] <ogra_> 110 to 114 somewhere
[21:39] <ogra_> sil2100, but there is a bzr tree somewhere where you need to commit the change when removing a package
[21:39] <ogra_> (i use it so rarely that i forgot again where)
[21:39] <alecu> ToyKeeper: just finished my run of the testplan for silo rtm-5
[21:39] <alecu> dobey: ^
[21:41] <sergiusens> ogra_: sil2100 lp:click-sync
[21:41] <ogra_> ah, right
[21:41] <Saviq> asac, can't parse your comment in https://bugs.launchpad.net/ubuntu-rtm/+source/unity8/+bug/1348557/comments/19
[21:41] <ogra_> sil2100, that should have all commits for added/removed packages
[21:42]  * ogra_ cant even parse the title :P
[21:43] <cjwatson> sil2100: it's actually in lp:livecd-rootfs
[21:43] <cjwatson> that has code for moving specific packages from rootfs to custom - click-sync isn't involved here
[21:43] <ogra_> sil2100, to match the moving of the click packages you would have to match livecd-rootfs to an image number
[21:44] <ogra_> i see that was on the 14th
[21:44] <ogra_> (from utopic-changes)
[21:44] <ogra_> which puts it around image 104
[21:44] <ogra_> or 105
[21:46] <ogra_> (there were two other uploads that will match 105)
[21:46] <ogra_> so not related most likely
[21:46] <cjwatson> win
[21:46]  * cjwatson dodges bullets
[21:46] <ogra_> :)
[21:54] <ogra_> brendand-nexus5, moo
[21:55] <brendand-nexus5> ogra_ - baa?
[21:55] <ogra_> brendand-nexus5, soo ... there is silo rtm 14 ... that has the AP removal stuff ... we want to land this, build an image, see the smoke tests and if needed roll it back ...
[21:56] <ogra_> brendand-nexus5, (as discussed before)
[21:56] <dobey> brendand-nexus5: btw, it seems there are 2 cards for landing-005 in the trello now, as you added a second one
[21:56] <ogra_> brendand-nexus5, to land the silo i would like to get QA nod-off indeed (since i want to be a good citizen) :)
[21:57] <ogra_> brendand-nexus5, i dont think there is anything to sign off or test actually since the test is actually the next smoke test run (and we are prepared to completely undo the change)
[22:01] <ogra_> brendand-nexus5, and to have enough time to revert all this tomorrow if needed i would like to land it now so it makes the next image
[22:01] <brendand-nexus5> ogra_ - sure
[22:01] <ogra_> cool, thanks !
[22:03] <jhodapp> Mirv, utopic silo 24 doesn't seemed to be synced right from my previous rtm silo 16
[22:05] <ogra_> argh !
[22:05] <ogra_> veebers, ^^^^
[22:06] <ogra_> please get the MP top approved asap
[22:06] <veebers> ogra_: argh, wait this it the dbus-property-service? Who would be best to top approve it?
[22:06] <ogra_> no, this is your MP
[22:06] <ogra_> dbus-property-service was a source pakcgae sync
[22:06] <Mirv> jhodapp: utopic 24 has been last build two weeks ago
[22:07] <jhodapp> Mirv, yeah, ogra_ informed me about the situation...I'll just wait until v opens up
[22:07] <ogra_> veebers, do you have thomi somewhere around so he could quickly do that ?
[22:07] <Mirv> jhodapp: right, that's what I was going to say next :)
[22:07] <jhodapp> Mirv, thanks :)
[22:07] <veebers> ogra_: thomis not beside me :-\ Who has perms to approve that MP?
[22:08] <ogra_> veebers, seems "autopilot hackers" owns that branch
[22:08] <veebers> ogra_: oh wait, is it just the autopilot MP? I get confused as it says dbus-propery-
[22:08] <veebers> ogra_: this one right? https://code.launchpad.net/~veebers/autopilot/1.5-fixing-packaging-image-removal/+merge/239192
[22:08] <ogra_> yep
[22:08] <ogra_> just needs top approval
[22:08] <veebers> ogra_: sorry about that :-P Yeah it's top approved now
[22:09] <ogra_> thanks
[22:09] <veebers> I thought that it was a branch against dbus-property-service
[22:09] <ogra_> nah
[22:09] <ogra_> that package just ships the removed file now so it needs to go in alongside
[22:10] <veebers> Ahhhh I understand now
[22:10] <veebers> ogra_: do I need to do anything else for this before I go offline for dinner?
[22:10] <ogra_> no, just go, i'm working on it
[22:11] <veebers> ogra_: awesome, thank you for that
[22:12] <ogra_> phew ... done
[22:14] <ogra_> aaand ubuntu-touch-meta copied too
[22:14] <ogra_> and on that note ...
[22:14]  * ogra_ goes to find dinner
[22:15] <ogra_> sil2100, ^^^
[22:15] <sil2100> \o/
[22:15] <sil2100> Those are still migrating, right?
[22:15] <ogra_> 123 will have the changes so we can look tomorrow (its only 3h til the cron build starts anyway)
[22:15] <sil2100> ogra_: will you kick a new image once those do? (after dinner ;) )
[22:15] <sil2100> Ah
[22:15] <sil2100> Right, different TZ
[22:15] <ogra_> :)
[22:16] <sil2100> I keep forgetting that..
[22:16] <ogra_> haha, me too
[22:16] <ogra_> anyway, all in ... cross your fingers
[22:16] <ogra_> off to the bar :)
[22:16]  * ogra_ waves
[22:47] <robru> nooo
[22:47] <robru> we gave that one up


[04:39] <elkng> http://www.trendnetestore.com/index.php?route=product/product&product_id=2836 is there a way to install ubuntu on this "PRESTIGIO MultiPad 3170 Pro 7.0",800x480,4GB,Android 4.0.3" ? it has "CPU = ARM Cortex A5 (Telechips TCC8923)"
[04:56] <mstinson> Greetings. Stopping by before bed. Has anyone heard if Ubuntu ARM will be coming to the Nexus 10? The Nexus 7 appears to have closed nVidia blobs while the N10 uses a Mali GPU which has BSD licensed kernel drivers.
[04:58] <mstinson> I'm holding out for Nexus 10. It would be sweet if I could kick Android and use it as my second machine/screen.
[06:20] <SoulShadow> seems like a rather expensive second screen
[08:37] <mjrosenb> I recently apt-get installed a 3.4 kernel on my pandaboard, and since then, it has been locking up a few minutes after booting
[08:38] <mjrosenb> apt-get remove NEWEST_KERNEL_VERSION should just kick me back to a 3.2 kernel, right?
[08:56] <discopig> mjrosenb, assuming you didn't apt-get remove the old one, yes
[08:56] <discopig> should default to the one left ther
[08:56] <discopig> e
[08:59] <mjrosenb> yeah, removing old kernels is usually a bad idea
[14:48] <VarmVaffel> I got a custom board running plain linux, and whenever I try to connect a Huawei USB-modem it instantaniously reboots
[14:48] <VarmVaffel> no error message, just a reboot
[14:48] <VarmVaffel> if I keep the USB modem in at startup, it reboots immediately when it initializes the USB system
[14:49] <VarmVaffel> anyone have any experiences with this kind of happenings?
[14:50] <VarmVaffel> my kernel is <IP_ADDRESS>
[15:56] <ben1066> VarmVaffel: do I know you from somewherE
[15:57] <VarmVaffel> oh hey ben1066 :P
[15:57] <VarmVaffel> hlcoders amirite?
[15:57] <ben1066> ##electronics ... and hlcoders
[15:57] <VarmVaffel> oh electronics as well
[15:57] <VarmVaffel> I'm not very active there...
[15:57] <ben1066> Neither am I, I just did a whois though :P
[15:57] <VarmVaffel> ah :P
[15:57] <ben1066> Isn't that more of a #linux question?
[15:58] <VarmVaffel> yeah I asked there as well
[15:58] <VarmVaffel> but they didn't answer
[15:58] <VarmVaffel> :(
[15:58] <ben1066> Ah :(
[16:15] <ben1066> The internet is apparently huge...I don't believe it
[16:15] <VarmVaffel> O_o
[16:32] <ben1066> I keep recognizing people in other channels...
[19:32] <ieatlint> anyone know if the nvidia tegra3/cardhu openmax lib (libnvomx.so) can be obtained with its symbols intact? (not stripped)
[19:36] <FrankWMiller> greetings
[19:36] <FrankWMiller> anyone here?
[19:50] <SailorMoon> you guys exist!
[19:50] <SailorMoon> Nexus 7? Rom file?
[19:50] <SailorMoon> Why you no exist?
[19:50] <FrankWMiller> there hasnt been much activity in the last 10 minutes or so
[19:52] <SailorMoon> i want this Q~Q
[19:52] <SailorMoon> Perhaps its because androids rom installer is used to 100 to 200MB rom files, not 700 lol
[19:52] <SailorMoon> or perhaps its because the internal memory gets formated
[19:53] <SailorMoon> or perhaps they just dunno how to make a rom
[19:57] <k1l_> SailorMoon: just boot a live-usb ubuntu and install it. if you dont want to use ubuntu on a pc o_O
[19:59] <SailorMoon> ubuntu doesnt work with my wireless
[19:59] <SailorMoon> or i would have by now lols
[19:59] <SailorMoon> id also like more detail on if this does anything to the recovery partition of the tablet
[19:59] <SailorMoon> i assume it does, wich is why it says a full recovery is needed
[20:00] <SailorMoon> so nvm that last question
[20:01] <SailorMoon> i dunno how much you know about this installation process, k1l_, but would virtualbox's usb host mode thingy suffice?
[20:04] <k1l_> SailorMoon: i would go with a live-usb. i can not imagine of a wirelesscard not working under ubuntu. or you could stick a cable in it for the 5mins. but the virtualbox way should work, too
[20:08] <SailorMoon> i know it doesnt work, it hasnt worked since ubuntu 6 or something, i try every ubuntu version when they come out. i have to install a special broadcom package and then it stops working when i run apt-get update or whatever
[20:08] <SailorMoon> anyways, gotta go. Thanks for the chat :3 bye
[20:25] <FrankWMiller> anyone still here?
[20:26] <FrankWMiller> i'm interested in advice on porting ubuntu server to a new arm board we are designing
[20:26] <FrankWMiller> freescale i.mx6d
[20:26] <FrankWMiller> which is cortex a8
[20:26] <FrankWMiller> sata disk
[20:26] <FrankWMiller> gb eth 4 G ram
[20:27] <FrankWMiller> i'll be able to build a kernel using a freescale provided bsp
[20:27] <FrankWMiller> er a9
[20:27] <FrankWMiller> sorry
[20:28] <FrankWMiller> do i just build a rootfs as mentioned in the arm section?
[20:28] <FrankWMiller> i'm thinking that uboot would go in flash
[20:28] <FrankWMiller> then i'd like to boot from the sata disk
[22:21] <KenBW2> not sure if this belongs in #ubuntu-arm. I'm trying to get gnome-shell running on my Nexus 7, is this possible?
[22:26] <GrueMaster> possibly.


[01:17] <joern> i may be stupid or blind, but somehow i cannot find documentation about when exactly "emits" is processed
[01:18] <joern> is it before the exec, directly after the exec, a second later,...?
[01:18] <broder> "emits" is just metadata - it doesn't cause an event to get emitted
[01:18] <broder> (it's intended to annotate, e.g., "the executable i'm about to call is going to emit these events at some point")
[01:19] <broder> it's used by things like initctl show-config and initctl check-config for verification
[01:19] <joern> so the executable has to do whatever initialization and then somehow emit this event
[01:19] <broder> but if you want to emit some event, you should use initctl emit in the exec/script line
[01:19] <joern> ok
[01:20] <joern> and for "started foo", when is that event generated?
[01:20] <broder> that's emitted when the job changes states from "starting" to started
[01:20] <broder> when that happens depends on the expect line and whether it's marked as a task or not
[01:20] <broder> possibly other things, too
[01:21] <joern> so with "expect fork", as soon as fork(2) returns, i take it?
[01:22] <broder> or possibly when fork is called. i don't recall
[01:23] <joern> i would imagine there could be nasty race conditions then - although very hard to hit
[01:24] <joern> anyway, thanks!  i believe i have enough rope to hang myself now
[01:24] <broder> well, you just have to make sure your daemon is actually ready whenever you trigger that transition
[01:24] <broder> so do all your setup (binding to ports, setting signal handlers) before you fork
[01:25] <joern> and maybe spend a night reading all existing /etc/init/*.conf files before writing my own
[01:26] <broder> if you're writing a daemon/binary targeted at upstart specifically, i'm a fan of "expect stop"
[01:26] <broder> then you just do "raise(SIGSTOP);" whenever you're done with setup
[01:28] <joern> i would actually like not to have any dependencies on upstart.  we currently have tons of subtle dependencies and my unwritten job description is to find them all and remove them - or at least make them explicit
[01:28] <joern> would be nice if i was the last person to suffer this pain
[01:29] <broder> you should check out the upstart cookbook, btw, if you haven't
[01:50] <joern> 4.3.1 seems to be the answer to most of my questions.  thanks!
[18:07] <lamal666> Hi, im trying to write an upstart job to execute a script but when i run it- nothing happens
[18:09] <lamalex> http://paste.ubuntu.com/770327/
[18:10] <lamalex> ha clearly i cp'd another conf file..
[18:10] <lamalex> sudo start coverity
[18:10] <lamalex> coverity start/running, process 2518
[18:10] <lamalex> is what i get
[18:11] <lamalex> but the server doesn't really start
[18:13] <ion> http://upstart.ubuntu.com/cookbook/#obtaining-a-log-of-a-script-section
[18:15] <lamalex> ion, so i dont have a script stanza- i just have exec
[18:15] <lamalex> can i just put this above the exec line
[18:15] <lamalex> or do i need script stanza
[18:18] <xaka> hi! is anyone from dev team here?
[18:22] <ion> lamalex: Change
[18:22] <ion> exec foo
[18:22] <ion> to
[18:22] <ion> script
[18:22] <ion>   exec >/path/to/log 2>&1
[18:22] <ion>   set -x
[18:22] <ion>   exec foo
[18:22] <ion> end script
[18:28] <lamalex> ion, also is it possible to write a custom stop job?
[18:28] <ion> Use pre-stop.
[18:30] <lamalex> ah cool thanks
[18:33] <xaka> is there any way to specify dependencies? like i want to start service A on runlevel 2345, but after service B has been started
[18:35] <ion> A: start on started B, stop on stopping B
[18:35] <ion> B: start on runlevel [2345], stop on runlevel [!2345]


[10:47] <_mup_> Bug #830995 was filed: default-instance-type and default-image-id are unhelpful <Ensemble:New> < https://launchpad.net/bugs/830995 >
[10:52] <_mup_> Bug #830999 was filed: cannot specify machine constraints <Ensemble:New> < https://launchpad.net/bugs/830999 >
[13:18] <fwereade> I need to learn to pay attention to my status :/
[13:20] <_mup_> Bug #831058 was filed: cobbler FileStorage assumes no authentication required <Ensemble:New> < https://launchpad.net/bugs/831058 >
[13:38] <niemeyer> Hello all
[13:38] <niemeyer> Good week kickoffs for everybody
[13:49] <fwereade> niemeyer: heyhey!
[13:49] <fwereade> niemeyer: how's it going?
[13:51] <niemeyer> fwereade: Hey!
[13:51] <niemeyer> fwereade: Very nice
[13:51] <niemeyer> fwereade: Had a good relaxing weekend
[13:51] <niemeyer> fwereade: You?
[13:51] <fwereade> niemeyer: pretty good thanks
[13:51] <fwereade> niemeyer: keeping half an eye on libya, what with it being right in my back yard
[13:52] <niemeyer> fwereade: :(
[13:53] <fwereade> niemeyer: it seems to me like a tentative ":)" at the moment, but who knows what's coming :/
[13:54] <fwereade> niemeyer: and we didn't give back his fighters, so I doubt we have much to fear from the new lot :p
[13:54] <fwereade> niemeyer: anyway :)
[13:54] <fwereade> niemeyer: I've been wondering about bug importance and milestones
[13:54] <niemeyer> fwereade: Yeah.. worth paying some attention to
[13:55] <niemeyer> fwereade: Ok
[13:55] <fwereade> niemeyer: there are a few bugs marked "high" but not assigned to eureka -- is that explicit notice that we shouldn't be worrying about them now?
[13:58] <niemeyer> fwereade: It's a good hint they might either a) be misplaced; or b) be miscategorized
[13:58] <fwereade> niemeyer: hm, ok :)
[13:58] <fwereade> niemeyer: I've been a little reluctant to go around assigning priorities and suchlike, what with still being pretty new
[13:59] <fwereade> niemeyer: which is why 90% of my branches have been fixes to "uncategorized" bugs
[13:59] <fwereade> niemeyer: should I perhaps be taking a different approach?
[14:00] <niemeyer> fwereade: I would guess this happens due to our overuse of bugs to mean "task"
[14:00] <niemeyer> fwereade: You're working on a single High priority problem
[14:00] <niemeyer> fwereade: Getting physical deployments working
[14:00] <fwereade> niemeyer: similarly, when I report a bug, I don't usually assign a milestone; I only do that when I'm actually working on something, but I'm suddenly worrying that they'll just fly under the radar
[14:01] <niemeyer> fwereade: You can tons of uncategorized bugs because they are simply a path to get pieces of that work landed
[14:01] <niemeyer> s/You can/You get/
[14:01] <fwereade> niemeyer: makes sense
[14:01] <niemeyer> fwereade: The bug priority is most interesting when it's an actual issue we want to stash away without an assignee
[14:01] <niemeyer> fwereade: Because it tells the next guy what he should be paying attention to
[14:03] <fwereade> niemeyer: I probably kinda mostly see
[14:03] <fwereade> niemeyer: as an example, there's this idea that we should be able to specify more about what sort of machines are used in certain circumstances
[14:04] <fwereade> niemeyer: a bug for that didn't leap out at me, so I filed one this morning, as a general "we should do this sometime" note
[14:04] <niemeyer> fwereade: That sentence gives such a positive feeling :-)
[14:04] <fwereade> niemeyer: haha :)
[14:05] <fwereade> that's lp:830999, which has no importance, assignee, or milestone
[14:06] <fwereade> niemeyer: should it maybe be High, None, Eureka?
[14:06] <niemeyer> fwereade: Definitely not Eureka
[14:06] <niemeyer> fwereade: I'd personally qualify that as a Medium, non-Eureka
[14:06] <niemeyer> fwereade: Eureka has a short time span (as usual ;-)..
[14:06] <fwereade> niemeyer: I feel vindicated in my reluctance to go around categorizing things myself ;)
[14:07] <fwereade> niemeyer: I don't think I know when eureka actually is targeted to... LP thinks it was 1/1/2011, which I suspect to be incorrect (:p)
[14:07] <niemeyer> fwereade: As far as physical deployment goes, Eureka is about finishing the barebones
[14:07] <niemeyer> fwereade: Making it work reliably
[14:08] <niemeyer> fwereade: Rather than getting fancy features in
[14:08] <niemeyer> fwereade: Eureka is 11.10
[14:08] <fwereade> niemeyer: that's fine by me ;)
[14:08] <niemeyer> fwereade: End of September, pretty much
[14:09] <fwereade> niemeyer: ok, makes sense, and we have some sort of special dispensation to release whatever we have done (while most things have already passed the deadline to get in) ...right?
[14:10] <niemeyer> fwereade: Kind of.. this is actually the real deadline
[14:10] <niemeyer> fwereade: For everyone
[14:10] <niemeyer> fwereade: Or rather.. for everyone in similar circumstances
[14:11] <niemeyer> fwereade: E.g. Ensemble is in universe, it's already there right now, etc
[14:20] <hazmat> i think the close out of the milestone is scheduled right before the final testing freeze
[14:20] <hazmat> hmm.. actually its not, i should move it up
[14:21] <hazmat> the final freeze is sept 22nd
[14:21] <hazmat> er 29th
[14:21] <hazmat> 22nd is beta 2
[14:37] <niemeyer> hazmat: SpamapS requested us to land things by Sep 22nd for testing..
[14:37] <niemeyer> hazmat: We can close the milestone with 29th
[14:38] <niemeyer> hazmat: and have that week for testing on our side too
[14:38] <niemeyer> Still within Eureka
[15:04] <jcastro> negronjl: ok, I tried a few times over the weekend and just now, still getting this "error: { "$err" : "not master", "code" : 10107 }" every time
[15:28] <niemeyer> Lunch time..
[15:34] <jcastro> Ensemble is on devops cafe! http://devopscafe.org/show/2011/8/22/devops-drop-004.html
[15:36] <robbiew> nice
[15:40] <robbiew> jcastro: did they talk about it?
[15:40] <jcastro> yeah
[15:40] <jcastro> it's a short podcast, worth a listen
[15:43] <robbiew> jcastro: interesting..thanks
[16:02] <_mup_> ensemble/expose-cleanup r328 committed by<EMAIL_ADDRESS>[16:02] <_mup_> Initial refactoring per review
[16:03] <_mup_> ensemble/expose-cleanup r329 committed by<EMAIL_ADDRESS>[16:03] <_mup_> Merged trunk
[16:07] <negronjl> jcastro:  I'll look into it.
[16:07] <jcastro> negronjl: ok I tried some other things and that didn't work either
[16:08] <jcastro> I have the instance up and running now if you want to check it out
[16:08] <negronjl> sure.  add my ssh-id ( negronjl )
[16:24] <SpamapS> lol... John Willis
[16:24] <SpamapS> love his monitoring lightning talk
[16:27] <niemeyer> jcastro: How is it in the podcast?
[16:27] <SpamapS> starts around 4:50 in
[16:28]  * niemeyer downloads
[16:28] <niemeyer> Mostly curious about what the take was
[16:28] <niemeyer> and what's the "ironic twist" :)
[16:28] <SpamapS> Not sure
[16:28] <SpamapS> still listening
[16:30] <jcastro> I have like a minute of silence in mine
[16:31] <SpamapS> yeah
[16:31] <SpamapS> thats a quote
[16:31] <SpamapS> turn it up
[16:31] <SpamapS> its from Fast Times @ Ridgemont High
[16:31] <SpamapS> whoa I got a silence at 8:49 too
[16:32] <SpamapS> right at the juicy part ;)
[16:32] <SpamapS> its like the missing fuzz on the nixon tapes. ;)
[16:34] <SpamapS> yeah that missing minute is really weird
[16:40] <niemeyer> Nice.. quite positive overall
[16:43] <jcastro> clearly he'll have to do another one with more detail. :)
[16:43] <SpamapS> Maybe one of his listeners will write a formula w/ Chef. ;)
[17:10] <hazmat> ensemble team, wikimedia, check emails
[17:10] <hazmat> happening now
[17:38] <_mup_> ensemble/expose-cleanup r330 committed by<EMAIL_ADDRESS>[17:38] <_mup_> Added mock tests with respect to refactoring of remove_security_groups
[17:54] <RoAkSoAx> fwereade: ping...
[17:54] <RoAkSoAx> fwereade: has something change whithin the code that generates the cloud-init user data?
[18:04] <adam_g> w/in 14
[18:11]  * SpamapS cheers for adam_g's w/inning
[18:14] <_mup_> ensemble/expose-cleanup r331 committed by<EMAIL_ADDRESS>[18:14] <_mup_> PEP8, PyFlakes, call remove_security_groups more robustly
[18:44] <robbiew> so dumb question:  have we tried testing ensemble against Oneiric images in EC2/OpenStack...or are we still using Natty-based amis
[18:54] <hazmat> robbiew, we've tried it, its not the default
[18:55] <SpamapS> bug 816169 has broken a few peoples' formulas..
[18:55] <_mup_> Bug #816169: When using Ensemble, add-apt-repository no longer functions properly <ensemble (Ubuntu):Confirmed> <python2.7 (Ubuntu):Confirmed> <software-properties (Ubuntu):Confirmed> < https://launchpad.net/bugs/816169 >
[18:55] <SpamapS> need to tak a look at that pronto
[18:56] <hazmat> we should probably switch that to oneiric, there's a bug open about using the default package distros instead of the ppa
[18:56] <hazmat> SpamapS, i thought i merged the fix for that
[18:56] <hazmat> oh.. nevermind
[18:56] <robbiew> might be good to switch it once beta is out
[18:57] <hazmat> SpamapS, there was another bug about pythonpath env variable leaking to executed hooks, and causing issues with package installation. that's no longer the case though
[19:00] <niemeyer> SpamapS: Do you know why they broke?
[19:00] <niemeyer> SpamapS: There's a thread with some questioning around that
[19:01] <niemeyer> adam_g mentioned the interactivity, but Michael Vogt mentioned it actually checks for the tty presence
[19:01] <niemeyer> Not sure about what's happening there
[19:02] <adam_g> niemeyer: its actually cloud-init that was screwing with the tty check
[19:02] <SpamapS> I have not looked at it, just followed the thread.
[19:03] <adam_g> SpamapS: just fixed that cloud-init bug, will check on the other python problems soon
[19:04] <adam_g> niemeyer: the interactivity change is unrelated to #816169 that SpamapS mentioned
[19:04] <_mup_> Bug #816169: When using Ensemble, add-apt-repository no longer functions properly <ensemble (Ubuntu):Confirmed> <python2.7 (Ubuntu):Confirmed> <software-properties (Ubuntu):Confirmed> < https://launchpad.net/bugs/816169 >
[19:16] <adam_g> SpamapS: looks like that is no longer an issue. seems there was some weirndess in the python environment that has since settled? im going to wait for cloud-init to be updated in images so i can bootstrap+deploy without hacking before confirming 100%
[19:17] <SpamapS> adam_g: so since we don't really know where the problem was.. maybe just close all the tasks as Invalid once you've confirmed it doesn't exist anymore?
[19:17] <adam_g> SpamapS: will do
[19:19] <SpamapS> adam_g: sweet thx!
[19:26]  * robbiew needs to eat...back in a bit
[19:36] <RoAkSoAx> fwereade: when you are around pelase give me a shout
[19:51] <hazmat> adam_g, yeah.. it was probably fixed as part of bug 816264
[19:51] <_mup_> Bug #816264: PYTHONPATH causing corrupt environment <Ensemble:Fix Released by hazmat> < https://launchpad.net/bugs/816264 >
[19:58] <adam_g> hazmat: ah, nice
[20:31] <niemeyer> I'll break for some coffee
[20:31] <niemeyer> biab
[20:34] <robbiew> niemeyer: your Google GOpher just arrived at my house
[21:02] <niemeyer> robbiew: Hah :)
[21:02] <robbiew> niemeyer: I'll be sure to bring it to UDS
[21:02] <robbiew> squishable.com....never heard of them before
[21:03] <robbiew> but apparently they are pretty popular
[21:03] <robbiew> the GOpher must be "special"
[21:03] <robbiew> lol
[21:04] <niemeyer> robbiew: They are, somehow.. :-)
[21:05] <niemeyer> robbiew: Thanks for feeding it, meanwhile ;)
[21:05] <robbiew> lol...sure thing
[21:10] <niemeyer> I thought they were going to send the gopher here as they asked for my home address, but if they actually sent the gopher to the original address I provided, I wonder what they've put in the mail now..
[21:40] <niemeyer> Today was remarkably unproductive
[22:43] <_mup_> ensemble/lxc-lib-merge r323 committed by<EMAIL_ADDRESS>[22:43] <_mup_> merge lxc-lib
[22:45] <_mup_> ensemble/formula-state-with-url r315 committed by<EMAIL_ADDRESS>[22:45] <_mup_> parameterize trunk in ENSEMBLE_TRUNK env variable for makefile
[22:45] <_mup_> ensemble/formula-state-with-url r316 committed by<EMAIL_ADDRESS>[22:45] <_mup_> link reference doc for s3 auth url
[23:02] <_mup_> ensemble/formula-state-with-url r317 committed by<EMAIL_ADDRESS>[23:02] <_mup_> formula urls are required, also seed ec2 test provider base class with fake credentials
[23:03] <_mup_> ensemble/formula-state-with-url r318 committed by<EMAIL_ADDRESS>[23:03] <_mup_> merge trunk
[23:06] <_mup_> ensemble/trunk r323 committed by<EMAIL_ADDRESS>[23:06] <_mup_> merge formula-state-with-url [r=niemeyer,bcsaller][f=761053]
[23:06] <_mup_> Formula states are now created in an enviroment with a url to their
[23:06] <_mup_> location in provider storage. This is to enable machine agents not to
[23:06] <_mup_> need access to the provider for deploying formulas.
[23:14] <_mup_> ensemble/machine-agent-uses-formula-url r316 committed by<EMAIL_ADDRESS>[23:14] <_mup_> merge trunk
[23:21] <_mup_> ensemble/trunk r324 committed by<EMAIL_ADDRESS>[23:21] <_mup_> merge machine-agent-uses-formula-url [r=niemeyer,fwereade][f=828189]
[23:21] <_mup_> Machine agents download formulas using the formula url, instead of
[23:21] <_mup_> retrieving them directly from provider storage, when deploying units.
[23:27] <_mup_> Bug #831688 was filed: Openstack compatibility is needed <Ensemble:New> < https://launchpad.net/bugs/831688 >
[23:31] <niemeyer> Can someone please have a second review on this: https://code.launchpad.net/~fwereade/ensemble/cobbler-zk-connect-error-messages/+merge/72033?
[23:32] <_mup_> ensemble/stack-crack r326 committed by<EMAIL_ADDRESS>[23:32] <_mup_> formulas are published with a formulas- prefix instead of a formulas/, per workaround for bug 829880
[23:44] <_mup_> ensemble/flex-origin r323 committed by<EMAIL_ADDRESS>[23:44] <_mup_> Fix test that was depending on hash ordering in dict


[16:09] <meena> https://bugs.launchpad.net/cloud-init/+bug/1990070 and another one
[16:09] <meena> should help with the others…
[16:21] <meena> actually, i think it's better to split this out into two
[16:21] <meena> https://bugs.launchpad.net/cloud-init/+bug/1990070
[16:21] <meena> and https://bugs.launchpad.net/cloud-init/+bug/1990071
[16:48] <meena> and another one: https://bugs.launchpad.net/cloud-init/+bug/1990072


[03:18] <Lord_Athur> hi
[03:31] <Lord_Athur> is there anybody?
[03:44] <Burgundavia> hmm
[04:34] <tclong> Happy New Year!
[07:50] <Lord_Athur> hi
[07:52] <Lord_Athur> Banux
[08:58] <Lord_Athur> hi
[08:58] <Lord_Athur> I've got a problem, is there anybody?
[05:06] <Lord_Athur> hi
[05:17] <jouni__m> hi. any chemist here?
[07:06] <tinsleyc> Anybody working with Dapper Edubuntu?
[07:10] <tinsleyc> Rejoining.  Anybody working with edubuntu version of Dapper?
[07:12] <tinsleyc> I had one daily build that would attempt to load but today it fails on release notes so it must be getting too old.  The latest builds generally fail on detecting the right kernel and then no network interface.  Dapper daily seems to work fine.
[07:13] <tinsleyc> Welcome to 2006.  Anybody awake out there?
[07:14] <tinsleyc> Hello jinty
[07:15] <jinty> hey tinsleyc
[07:15] <tinsleyc> Welcome to 2006.
[07:15] <jinty> whatsup?
[07:15] <jinty> to yu too
[07:16] <tinsleyc> I am trying to find out if anyone is trying to load the edubuntu daily build version of Dapper.
[07:16] <jinty> never tried myself...
[07:17] <tinsleyc> 5.10 works fine.  An early build would try and almost finsihed but today, it won't download the release notes from the mirror and fails.  Later builds fail.
[07:17] <tinsleyc> Dapper daily will load okay.
[07:18] <tinsleyc> What's up with you?
[07:18] <jinty> me, well I mostly work on schooltool,but just hang out here as a lurker
[07:19] <tinsleyc> I guess we both be lurking...  What is the status of schooltool?
[07:19] <jinty> soon to release the first alpha versions of schooltool 2006
[07:20] <jinty> so in heavy development part of the release cycle.
[07:20] <tinsleyc> Is it possible to define soon?
[07:21] <jinty> we have a roadmap: http://www.schooltool.org/products/schooltool-2006/roadmap
[07:21] <tinsleyc> thanks
[07:22] <jinty> and nightly tarballs: ftp://ftp.schooltool.org/pub/schooltool/releases/nightly/
[07:25] <tinsleyc> You are working on the "discussed" features for "Christmas"?
[07:28] <jinty> yeah, it seems the last commits were about one of those points
[07:28] <jinty> I am actually more involved with the packaging and build system than the coding
[07:30] <jinty> Don't have an infinity of free time
[07:31] <tinsleyc> Understand.
[07:38] <tinsleyc> Hello blue-frog.
[07:41] <blue-frog> hi
[07:42] <tinsleyc> Welcome to 2006.
[08:53] <tinsleyc> Anybody working with edubuntu version of Dapper?
[09:00] <spacey> tinsleyc, only as thinclient chroot
[09:18] <tinsleyc> 5.10 works fine.  An early build would try and almost finsihed but today, it won't download the release notes from the mirror and fails.  Later builds fail.
[09:18] <tinsleyc> I can't get Edubuntu Dapper to install.
[09:19] <tinsleyc> I am trying to find out if anyone is trying to load the edubuntu daily build version of Dapper.
[09:32] <tinsleyc> The silence is, well, deafening...
[09:59] <tinsleyc> mhz_BBL, let me know how it goes?  TIA
[10:00] <mhz> tinsleyc: sure
[10:01] <mhz> I downladed that daily built as my edubuntu-dapper 1st try
[10:01] <mhz> and the results will be wikied under wiki:MauricioHernandez
[10:04] <tinsleyc> I will check.  I can't get it to install even thought 5.10 installs fine.  My results have been, with an earlier daily, it almost installed after stumbling on the kernel but today it wouldn't even get beyond the download of release notes from the mirro and the last few daily's, including today's, give a kernel match erorr and then fail on finding a netework card.  I can install the Dapper daily fine.
[10:04] <mhz> tinsleyc: would it be better if we make a wiki page for testing results ?
[10:05] <tinsleyc> I am wondering what I am doing wrong.    It fails later on the network card.
[10:06] <mhz> okis, I am on it now
[10:12] <tinsleyc> I have also noticed that the size of the daily build vary quite a bit, anywhere from 620 MB to almost 700.
[10:13] <mhz> mine is 622 mb
[10:18] <tinsleyc> Today's is 658 MB according to the website 01/02/2006, yesterdays was around 623, prior days were at 658.  I am wondering if my I might have better results from the daily DVD.  Going to try that.
[10:19] <tinsleyc> What kind of hardware are you installing on?
[10:19] <tinsleyc> be nice if one could rsync the daily builds.
[10:20] <mhz> 1 GHz Celeron, 192 RAM, 80 GB
[10:21] <mhz> tinsleyc: I tried once ... but rsync insisted on downloading all the thing again
[10:21] <mhz> so I gave up
[10:21] <mhz> but havent tried since then
[10:21] <tinsleyc> I am working on newer hardware but not new, 2 years old, AMD 2200+ 758 MB of Ram, Onboard Nic.
[10:22] <tinsleyc> And like I reported, 5.10 installs without any problems and updates well.
[10:23] <mhz> weired
[10:23] <mhz> have you told ogra about it?
[10:23] <tinsleyc> How do I do that?
[10:24] <tinsleyc> You need to do that offline, my email clintin at linuxmail.com
[10:24] <tinsleyc> Oops, make that linuxmail.org
[10:29] <mhz> hehhe
[10:29] <mhz> when you see ogra here, you tell him
[10:29] <mhz> OR
[10:29] <mhz> you can send an email to edubuntu-devel list
[10:33] <tinsleyc> okay.  I think I am on the devel list but haven't seen a lot of activity there lately; have to double check.
[10:36] <tinsleyc> I am on the devel list.
[11:22] <mhz> tinsleyc: nope
[11:22] <mhz> daily wont install
[11:23] <mhz> :(
[11:23] <mhz> we're 2 now ;)
[11:23] <mhz> (looking the positive side of it)