[03:33] <tedg> trainguards, it seem like silo vivid/0 is in a weird state.
[03:33] <tedg> It is packages/built and landed at the same time.
[03:34] <tedg> trainguards, can we just publish silo 0 then?
[03:34] <tedg> Think the spreadsheet is what is screwed up.
[03:37] <robru> tedg: yes the spreadsheet is balls.
[03:39] <tedg> robru, Yeah, I thought it was EOL'd here soon, no?
[03:40] <robru> tedg: yeah we've had a lot of setbacks. I'm hoping it dies so, so soon
[03:41] <tedg> Zombie spreadsheet, it eats brains and just won't die.
[03:42] <tedg> robru, Thanks for pushing it along.
[03:47] <robru> tedg: I appreciate the recognition, thanks.
[03:50] <imgbot> [03:50] <imgbot> [04:13] <tedg> trainguards, can we get a rtm silo for line 65 please?
[04:13] <robru> tedg: rtm 8
[04:14] <tedg> robru, Great, thanks!
[04:14] <robru> tedg: you're welcome
[08:25] <mardy> hi! Is there any way to see the test logs from https://launchpadlibrarian.net/192178675/buildlog_ubuntu-vivid-arm64.libsignon-glib_1.12%2B15.04.20141209-0ubuntu1_FAILEDTOBUILD.txt.gz ?
[08:27] <seb128> mardy, did you try to build it locally on vivid?
[08:27] <seb128> mardy, I was also having a failing test when I did (already with the archive version when trying to rebuild)
[08:29] <seb128> oh, that one is just on arm64?
[08:29] <mardy> seb128: I did with pbuilder too, and it works; in fact, it seems that it's the arm64 build which is failing
[08:29] <mardy> seb128: I found the test errors, and they should now be fixed upstream too
[08:30] <seb128> k
[08:49] <seb128> mardy, builds fine in a porter box, maybe get somebody to retry the build?
[08:57] <sil2100> Does anyone know if the system-image importer is enabled back up?
[09:18] <Mirv> sil2100: image #50 DONE in the morning for vivid
[09:19] <Mirv> but no rtm.
[09:19] <Mirv> I'd guess importer is up
[09:21] <sil2100> cihelp: does anyone know if krillin builds for ubuntu-rtm will work now? Francis mentioned they're partially enabled, whatever that means
[09:22] <Wellark> hey, could I please get a rtm silo for line 53
[09:22] <Wellark> 52 already has vivid silo
[09:22] <vila> sil2100: I'm currently trying to assess what the current status is
[09:22] <Wellark> these are ota-1 fixes
[09:23] <sil2100> vila: thanks
[09:23] <sil2100> Wellark: o/
[09:23] <sil2100> Wellark: sure
[09:23] <Wellark> sil2100: thanks!
[09:23] <Mirv> mardy: retrying the arm64 build https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-001/+build/6630068
[09:23] <Mirv> sil2100: robert mentioned something about spreadsheet being broken, not sure in which why and if still
[09:23] <sil2100> Wellark: huh, I actually wonder why this wasn't assigned
[09:24] <sil2100> Mirv: oh? Did he say what was broken?
[09:24] <Wellark> sil2100: np. accidents happen :)
[09:25] <Mirv> sil2100: I didn't figure that out
[09:29] <sil2100> I suppose Robert also didn't modify the spreadsheet scripts to enable my version number storage for commitlogs ;/
[09:32] <sil2100> davmor2: ping
[09:43] <Mirv> mardy: it seems it succeeded with a rebuild! so it's just a flaky test.
[09:43] <Mirv> running watch_only
[10:24] <davmor2> sil2100: ogra is never on holiday is he?
[10:25] <sil2100> davmor2: never!
[10:25] <sil2100> But today he has some technicians at home I think
[10:25] <davmor2> sil2100: ah so his Internet is down again then ;)
[10:26] <sil2100> Not sure if they're related to the internet, but he said he'll be available in some hours
[10:26] <davmor2> sil2100: he only pretends to have holidays to make the company not feel bad I'm sure of it :)
[10:26] <sil2100> But that guy should really get a holiday next week!
[10:27] <davmor2> sil2100: no Christmas we are all off he'll have no one to talk to.....I bet he codes the entire Holiday though :D
[10:27] <sil2100> Next week is still a work week, so I thought maybe he should take that off
[10:27] <sil2100> Since damn, I don't remember ogra having even one week free this year!
[10:27] <sil2100> :O
[10:27] <sil2100> He's like a machine
[10:29] <davmor2> sil2100: he hasn't he has had national days off and nothing else
[10:29] <sil2100> This calls for an intervention
[10:29] <sil2100> Let's gather all together and have a serious talk with him
[10:29] <sil2100> ;p
[10:29] <davmor2> sil2100: why do you think I took out his internet ;)
[10:30] <davmor2> sil2100: he needs a stronger Woman in his life that tells him we are going on holiday NOW!
[10:47] <john-mcaleely> any news on krillin builds yet?
[10:48] <pstolowski> trainguards, Mirv hello, may I ask for a silo for #49 (please see my update/comment explaining the change)
[10:50] <cjwatson> oh yikes, I hadn't realised tachash was down so autopkgtests aren't getting triggered
[10:50] <cjwatson> I guess that's due to the 1SS move
[11:01] <sil2100> vila: any news?
[11:03] <cjwatson> jibel: Is tachash known to be down at the moment, or might there be a firewall bug?
[11:04] <jibel> cjwatson, yes, and last new I have are "no ETA, it's in DCE/GSA hands" I'll ask CI again about the status
[11:04] <jibel> news*
[11:04] <cjwatson> jibel: OK, thanks, I couldn't find anything relevant in RT from a simple search but https://rt.admin.canonical.com/Ticket/Display.html?id=76455 is clearly pretty large
[11:09] <Mirv> pstolowski: ok! I don't even try to track your silo logic, just do what you do and don't conflict with each other :)
[11:12] <pstolowski> Mirv, thanks & sorry for any confusion
[11:14] <vila> sil2100: replied in #phablet
[11:37] <Saviq> sil2100, uh oh, I reconfigured vivid silo 3 to remove indicator-network, but it was not removed?
[11:38] <Saviq> indicator-power that is
[11:39] <Saviq> https://ci-train.ubuntu.com/job/ubuntu-landing-003-0-reconfigure/22/console says "Removing indicator-power from silo." but apparently it did not
[11:39] <sil2100> Saviq: uh, hmm, I remember we had problems with that before as well
[11:39] <sil2100> Saviq: let me remove it manually just in case
[11:41] <sil2100> Saviq: done
[11:41] <Saviq> sil2100, thanks
[11:48] <Saviq> sil2100, btw, any idea about bug #1400502
[11:49] <Saviq> python3-xdg is an Arch: all Depends of indicator-network, that's a dep of libconnectivity-qt1-dev → libconnectivity-qt1
[11:49] <Saviq> which leads to it being uninstallable for the non-default arch as it tries to install e.g python3-xdg:i386
[11:49] <cjwatson> I think it's a bit more than that
[11:50] <cjwatson> You don't want to be going down the indicator-network:target -> unity8:target path either
[11:50] <Saviq> cjwatson, shouldn't python3-xdg:i386 be fulfilled by python3-xdg that's Arch: all?
[11:50] <cjwatson> no, because it has no multi-arch field
[11:50] <cjwatson> but I think that is a red herring
[11:50] <Saviq> or should indicator-network have python3-xdg:any in its Depends (does it make sense for a Depends at all)?
[11:50] <cjwatson> shouldn't indicator-network be Multi-Arch: foreign instead?
[11:51] <Saviq> ok, I'll shut up now
[11:51] <Saviq> Wellark, ↑
[11:51] <cjwatson> that would cause libconnectivity-qt1's dependency on it to be fulfilled by the native architecture
[11:51] <Saviq> cjwatson, sure, if that's the right solution
[11:51]  * Saviq no gets Multi-Arch fully, yet
[11:51] <cjwatson> (https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages)
[11:52] <cjwatson> It depends on the kinds of technical interfaces that indicator-network provides to its dependencies
[11:53] <cjwatson> If it provides only architecture-independent interfaces - that is, *from the point of view of the things depending on it* it doesn't matter what architecture indicator-network is as long as it's runnable - then it should be Multi-Arch: foreign
[11:53] <Saviq> cjwatson, indeed, it's only accessed via DBus afaict
[11:54] <Saviq> cjwatson, thanks, that makes sense
[11:55] <cjwatson> I'm not 100% clear on why that dependency is there since connectivity-api has no matches for "indicator" outside the control file and changelog
[11:55] <cjwatson> I guess maybe it's artificial in some way?
[11:55] <brendand> strange, i'm being asked for the zope username when trying to bzr branch on the phone
[11:56] <Saviq> brendand, you're being hacked ;P
[12:09] <jgdx> sil2100, ping
[12:10] <sil2100> jgdx: pong
[12:10] <sil2100> What's up?
[12:10] <jgdx> sil2100, hi, could you give me write acc to the citrain spreadsheet?
[12:10] <sil2100> jgdx: sure, I'll give you access to the build jobs too
[12:11] <jgdx> sil2100, great, thanks!
[12:13]  * sil2100 off to the dentist
[12:14] <popey> is s-jenkins back?
[12:25] <cwayne_> popey, yeah, but it looks like nusakan doesn't have access to it, so no images still
[12:25] <cwayne_> but it is back up and building stuffs
[12:25] <popey> well, i cant get to it over the vpn either
[12:25] <popey> PING mayura.ubuntu-ci (10.100.0.4) 56(84) bytes of data.

[12:26] <ogra_> yeah, same from nusakan
[12:26] <popey> ok
[12:26] <ogra_> though ping might be off in the firewall
[12:26] <cwayne_> popey, i couldn't get to it until i setup the company-wide vpn
[12:26] <cjwatson> port 8080 works over the VPN
[12:26] <cjwatson> despite ping not working
[12:26] <ogra_> just not from nusakan :)
[12:26] <cjwatson> right
[12:27] <cjwatson> somebody should RT that then
[12:27] <popey> not here it doesn't.
[12:27] <ogra_> there is an rt for that ...
[12:27] <popey> http://s-jenkins.ubuntu-ci:8080/job/music-app-click/ never loads
[12:27] <ogra_> should all be in the works already
[12:27] <cjwatson> popey: wfm, perhaps I'm in different groups
[12:27] <cwayne_> popey, try setting up the company-wide vpn (that's what did it for me)
[12:27] <popey> ugh
[12:27] <popey> ok.
[12:27] <cjwatson> oh, yeah, I'm using the company-wide VPN
[12:28] <cjwatson> it's a vast improvement in just about all respects
[12:28] <cwayne_> popey, yeah, less than ideal for sure to have to go through it, but like cjwatson said it is quite a bit better
[12:28] <cjwatson> sorry I assumed that's what you meant when you said VPN, not the old thing
[12:28] <popey> https://wiki.canonical.com/InformationInfrastructure/IS/HowTo/CompanyOpenVPN this thing?
[12:28] <cjwatson> ogra_: that's as may be but https://rt.admin.canonical.com/Search/Simple.html?q=nusakan doesn't show it?
[12:28] <cjwatson> popey: yes
[12:28] <popey> thanks
[12:29] <ogra_> cjwatson, https://rt.admin.canonical.com/Ticket/Display.html?id=77276 ... not sure it mentions nusakan explicitly
[12:29] <cjwatson> ogra_: do you have a ticket number?
[12:29] <cjwatson> ok, thanks
[12:29] <ogra_> it was pointed out on #is that it is the same issue
[12:29] <cjwatson> ah, it misspells "nusakan"
[12:29] <ogra_> hah
[12:30] <cjwatson> popey: from that ticket it sounds like this stuff is all behind rapid now rather than batuan, so it indeed wouldn't be surprising that the old batuan VPN no longer works for it
[12:30] <cjwatson> my understanding is that the intent is to kill off the batuan vpn/jumphosting stuff
[12:31] <cjwatson> (long-term, perhaps, don't know)
[12:32] <popey> \o/ that works
[12:32] <popey> thanks cjwatson cwayne_
[12:43] <pmcgowan> are image builds back up?
[12:45] <popey> no, firewall problem apparently
[12:45] <cjwatson> pmcgowan: https://rt.admin.canonical.com/Ticket/Display.html?id=77276
[13:19] <om26er> oSoMoN_, Hi! how do i reproduce bug 1384460 ?
[13:24] <oSoMoN_> om26er, the high-level use case is to browse to a page that has a "tel:" link on it (e.g. google search results for a restaurant in your area), tap on it and verify that it opens the dialer-app with the phone number pre-filled
[13:24] <oSoMoN_> om26er, if that works, then the bug is fixed :)
[13:28] <om26er> oSoMoN_, aah, works then
[13:28] <om26er> oSoMoN_, it shouldn't be too difficult to automate, I think.
[13:29] <oSoMoN_> om26er, last I checked it wasn’t really possible to write autopilot tests that involved more than one app, or has this changed?
[13:30] <om26er> oSoMoN_, that has been possible for a while, though the tests need to be in an independent project
[13:31] <oSoMoN_> om26er, also, note that the browser side of things is already unit-tested, and so is the url-dispatcher side of things, so I would think that adding a telephony-app unit test (if there isn’t one already) should be enough
[13:31] <oSoMoN_> s/telephony-app/dialer-app/
[13:34] <om26er> oSoMoN_, while unittests are great, integration tests have their own worth for these cases. We can go ahead with landing this I guess since we have a manual case added to the TestPlan
[13:35] <pmcgowan> cjwatson, thanks for the ticket, are you monitoring it with them? or should I ping someone
[13:36] <cjwatson> pmcgowan: I'm not, I just heard about it here
[13:36] <cjwatson> pmcgowan: but there was literally just an update on #is
[13:36] <pmcgowan> cjwatson, indeed
[13:41] <oSoMoN_> om26er, I agree, integration tests are valuable too in this kind of case, but indeed I wouldn’t block on it in this specific instanc
[13:41] <oSoMoN_> instance
[13:50] <greyback> trainguards: can I get a reconfigure on vivid silo14 please. Added the -gles twin
[13:50] <cjwatson> pmcgowan,cwayne_: hm, were you expecting the system-image importer to immediately start doing something once the firewall was fixed?
[13:51] <sil2100> greyback: o/
[13:51] <greyback> sil2100: hey!
[13:51] <cwayne_> cjwatson, no, but i'd expect it to be able to reach s-jenkins, so could get the custom tarballs that already exist
[13:51] <cjwatson> cwayne_: had they changed?
[13:52] <sil2100> greyback: reconfigured :)
[13:52] <cwayne_> cjwatson, no
[13:52] <greyback> sil2100: thank you kindly good sir
[13:53] <cjwatson> cwayne_: ok, thanks.  I guess that means image building should be functional again now, anyway
[13:53] <sil2100> greyback: you are most welcome
[13:54] <cjwatson> and sounds like autopkgtests should be back up too
[13:57] <pmcgowan> yay
[13:57] <sil2100> \o/
[13:57] <pmcgowan> sil2100, when do we kick a build
[13:58] <sil2100> pmcgowan: well, autopkgtests will be back soon, krillin builds not yet
[13:58] <sil2100> pmcgowan: I poked CI and they say they're still working on it with top priority...
[13:58] <pmcgowan> sil2100, I just heard krillin builds should work now
[13:59] <sil2100> pmcgowan: but I had a talk with jibel and they anyway would need to have a new image during our EU evening, so we still have some time
[13:59] <pmcgowan> fine
[13:59] <pmcgowan> just want to be sure its all working
[13:59] <sil2100> pmcgowan: Ursinha in #ci mentioned that the ETA is today, but not sure if it's ok now
[14:00] <pmcgowan> sil2100, so following in #is they fixed the fw configs
[14:00] <Ursinha> sil2100: pmcgowan, it's being worked on now, we have a series of RTs that are being processed to fix the network glitches that are left
[14:00] <pmcgowan> Ursinha, I am thinking they are fixed but trying to confirm
[14:00] <Wellark> cjwatson: i-network does not provide any libraries
[14:00] <Ursinha> pmcgowan: the CI vanguard team is working on it
[14:00] <Wellark> all of the interaction happens over D-Bus
[14:01] <Wellark> so I will change the Multi-Arch to foreign then, right?
[14:01] <cjwatson> Wellark: right, so Multi-Arch: foreign should do the job then
[14:01] <cjwatson> thanks
[14:01] <cjwatson> (sometimes interfaces have architecture-dependent elements even if there are no libraries involved, but those are kind of special cases)
[14:01] <Wellark> cjwatson: still it's weird that python3-xdg gets into uninstallable state
[14:01] <Wellark> any idea what's causing that?
[14:01] <cjwatson> Wellark: makes complete sense to me
[14:01] <Wellark> well, you are the master :)
[14:02] <cjwatson> Wellark: it's an architecture: all package with no multi-arch field ...
[14:02] <cjwatson> so see the spec I quoted earlier :)
[14:02] <cjwatson> Wellark: it really is a red herring though, even if you rearranged that one thing you'd still run into a whole pile of other issues trying to install i-network from a foreign arch
[14:02] <pmcgowan> Ursinha, IS just fixed several issues and I was told we should be able to build krillin now, so what is it they are working on?
[14:03] <Ursinha> pmcgowan: yesterday other several issues were fixed as well, but that wasn't enough, it's been an interactive process to figure out what's left
[14:03] <cjwatson> Wellark: the art of fixing multiarch installation issues is generally in finding the right place in the stack to change; it often *isn't* the case that you want to go all the way to the bottom
[14:04] <cjwatson> (unlike with many single-arch installation bugs)
[14:04] <Ursinha> pmcgowan: what I know is that one remaining problem to access snakefruit was being worked on, and our team is checking if things are working as they're supposed to
[14:04] <pmcgowan> Ursinha, thats what was just fixed
[14:04] <cjwatson> you need to think about each point in the stack and work out what makes sense at each step, and if you manage to fix something higher up (as in this case) you can entirely avoid having to deal with messes below that
[14:05] <cjwatson> pmcgowan: it's probably reasonable to assume that we don't know everything yet :)
[14:05] <Wellark> ack.
[14:05] <Ursinha> pmcgowan: exactly, there's work in our side to ensure if things are working with the unblocked firewall
[14:05] <pmcgowan> ok
[14:05] <Ursinha> cjwatson: exactly, thanks :)
[14:05] <cjwatson> Ursinha: would it help to run through a full test build?
[14:05] <pmcgowan> right thats where I was heading
[14:06] <pmcgowan> lets make sure its working
[14:06] <Ursinha> cjwatson: I wasn't working directly on this, let me check with the ci people that are, they are most likely on it already, one minute
[14:06] <Ursinha> pmcgowan: we're working on that
[14:06] <Ursinha> making sure it's working
[14:06] <pmcgowan> right got it
[14:07] <cjwatson> autopkgtests are being triggered again, but are broken because they can't talk to ftpmaster.internal
[14:07] <Wellark> cjwatson: so, this is the current debian/control of i-network: http://bazaar.launchpad.net/~indicator-applet-developers/indicator-network/trunk.14.09/view/head:/debian/control
[14:07] <cjwatson> jibel: ^- are you folks aware of http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-bowtie/lastBuild/ARCH=amd64,label=adt/console and similar failures?
[14:07] <Wellark> cjwatson: now I'm not completely sure what I should modify, sorry :D
[14:07] <ogra_> grmbl ... dsl sucks ...
[14:08] <cjwatson> Wellark: insert "Multi-Arch: foreign" on a line of its own after line 44
[14:08] <cjwatson> (or anywhere in that stanza, but I usually put it next to Architecture)
[14:08] <Wellark> cjwatson: ack.
[14:08] <Wellark> cjwatson: thanks!
[14:08] <cjwatson> np
[14:09] <jibel> cjwatson, this is new. another FW issue maybe
[14:10] <cjwatson> jibel: will you chase that or do I need to?  I'm not sure which hosts are involved
[14:10] <jibel> cjwatson, I'm on it
[14:10] <Wellark> cjwatson: another related question: this is the connectivity-api debian/control
[14:10] <Wellark> http://bazaar.launchpad.net/~unity-api-team/connectivity-api/trunk.14.10/view/head:/debian/control
[14:11] <Wellark> libconnectivity-qt1-dev pulls in libconnectivity-qt1 whích now Depends on i-network
[14:11] <Wellark> which in turn pulls in unity8 (long story)
[14:12] <Wellark> cjwatson: would changing the Depends indicator-network to Recommends indicator-network stop the full chain being pulled when installing the dev package ?
[14:15] <cjwatson> Wellark: depends on the exact context; recommends are installed by default, although they're not installed for example when satisfying build-deps in package builds
[14:15] <cjwatson> jibel: thanks
[14:15] <cjwatson> Wellark: I wasn't totally clear why that dependency was there in the first place
[14:15] <cjwatson> it does seem an odd thing for a library to depend on
[14:16] <fginther> cjwatson, is kicking off a krillin test build something you can do?
[14:16] <cjwatson> fginther: I can kick off an ubuntu-rtm/14.09-proposed build for all devices it builds
[14:17] <cjwatson> I don't know if you'd call it a test build
[14:17] <cjwatson> (ok, sorry, I used that term earlier)
[14:17] <Wellark> cjwatson: i-network provides the dbus service that connectivity-qt1 uses at runtime. so in order for the library to work the service (now provided by i-network) must be installed or the api is useless
[14:18] <cjwatson> Wellark: hm, I grepped for such things and couldn't find it, but maybe the dbus service doesn't contain the substring "indicator"
[14:18] <Wellark> we are working on separating i-network and the connectivity-service
[14:18] <Wellark> but now for $reasons they are provided by the same process
[14:19] <sil2100> robru: hm, your changes haven't been redeployed yet in production?
[14:19] <cjwatson> fginther: (I won't do so without confirmation that I should, though)
[14:19] <sil2100> robru: since I don't see pkgversionlists generated during publish ;/
[14:19] <Wellark> cjwatson: for now, it would be just fine if i-network would not be installed as build-dep when something depends on connectivity-qt1-dev
[14:20] <sil2100> robru: it's really breaking everything right now
[14:20] <cjwatson> Wellark: Recommends would likely achieve that
[14:20] <sil2100> robru: commitlogs are crucial for our analysis of the differences between ubuntu and ubuntu-rtm
[14:20] <Wellark> cjwatson: ok. will do that for now. the real fix is to separate the indicator and the service into two different packages
[14:20] <Wellark> cjwatson: thanks again! :)
[14:20] <fginther> cjwatson, understood. I asked because I thought that it may be just a 'throw away' build. If it actually generates a new build, maybe not a good idea
[14:21] <cjwatson> fginther: I possibly could do a throwaway cdimage build but I'd rather not confuse things, and we want to test the system-image side of things anyway; the cdimage side is not the side that's been at risk recently
[14:22] <cjwatson> fginther: I cannot currently think of any part of the image build process other than what I've already tested and confirmed to work that might have been broken by the lab move, though
[14:23] <cjwatson> The lab is not heavily involved in image building
[14:23] <fginther> cjwatson, ok, do we know that any part is broken? I was asleep and may have missed the part where a krillin build was started and failed
[14:24] <ogra_> and we should really cache the tarballs locally on nusakan for the future
[14:24] <fginther> cjwatson, but I'll poke on the rest of the team
[14:24] <sil2100> robru: phew, ok, scratch that
[14:24] <ogra_> (so that it doesnt fail the build but uses the last good tarball instead)
[14:25] <cjwatson> fginther: the only thing I know to have been previously broken was the acquisition of custom tarballs from s-jenkins during system-image imports, and that should now be fine
[14:25] <sil2100> robru: it just took a while to get the json blob synced
[14:25] <ogra_> the importer is running atm ... we should know in a few mins :)
[14:25] <sil2100> robru: thanks for getting it deployed!
[14:25] <sil2100> ogra_: \o/
[14:25] <cjwatson> in that "w3m http://s-jenkins.ubuntu-ci:8080/" works from nusakan
[14:25] <cjwatson> ogra_: ah yes, good
[14:26] <fginther> cjwatson, ack. I also see the RT to update the firewall for nusakan to s-jenkins should be working... and you confirmed
[14:26] <ogra_> genearlly we need somme caching though ... so that this doesnt bite us anymore in the future
[14:26] <cjwatson> ogra_: last good tarball> from experience with cdimage, that can be a mixed blessing
[14:26] <ogra_> cjwatson, well, still better than not being able to build images at all
[14:26] <cjwatson> ogra_: you then switch to a different problem, where you can fail to notice parts of the system being broken and end up using old image contents when you thought you should be using new ones
[14:27] <cjwatson> ogra_: my experience has been that that cure is worse than the disease
[14:27] <davmor2> tedg I'll let rsalveti to stop looking at it then shall I :)   thanks for the comment on the bug though :)
[14:28] <davmor2> s/let/tell
[14:28] <tedg> Oh, yeah. It's a bash/dash difference :-(
[14:28] <tedg> I'll patch it.
[14:30] <davmor2> tedg: so indicator disappears cause one thing is faster than another so the fact it worked for me at all is pure fluke right?
[14:30] <tedg> davmor2, Yeah, we were trying to pause when that race happens, which it turns out we didn't really do.
[14:30] <tedg> davmor2, Because dash doesn't do the expansion, it only checks once.
[14:31] <davmor2> tedg: man that is sucks :(
[14:34] <ogra_`> yipiie ... after 6 days with wonky DSL they *finally* found the error
[14:39] <tedg> Wow, so on image 50 it seems Pulse is taking 1.7s to start.
[14:50] <imgbot> [14:50] <imgbot> [14:50] <sil2100> o/
[14:50] <ogra_`> \o/
[14:50] <sil2100> YAAY
[14:50] <sil2100> Yaaaaay
[14:50] <sil2100> YAAAAAAAAAAY
[14:50] <ogra_`> hooray
[14:50] <ogra_`> back in business
[14:50] <john-mcaleely> oooh
[14:50] <sil2100> pmcgowan: ^ builds work fine now
[14:51] <davmor2> sil2100: is this the real build or the power build
[14:51] <john-mcaleely> and which of the three tarballs I have do you want next?
[14:51] <john-mcaleely> ;-)
[14:51] <ogra_`> asl QA :)
[14:51] <ogra_`> *ask
[14:52] <john-mcaleely> QA: which tarball do you want
[14:52] <john-mcaleely> :-P
[14:52] <davmor2> john-mcaleely: NONE!!!!!!
[14:52] <john-mcaleely> somehow, I guessed that davmor2
[14:52] <davmor2> john-mcaleely: which tarball for what device on what distro?
[14:53] <john-mcaleely> davmor2, well, there are three queued for RTM, and I could queue one for vivid
[14:53] <sil2100> john-mcaleely: ugh, 3? :o
[14:53] <john-mcaleely> since tarballs are cumulative, we could skip two for RTM
[14:53] <sil2100> john-mcaleely: do those fix the critical issues for the OTA milestone?
[14:53] <john-mcaleely> sil2100, yes
[14:53] <sil2100> Daaamn
[14:54] <sil2100> :>
[14:54] <john-mcaleely> sorry :-)
[14:54] <sil2100> Ok, we still have time for one I guess?
[14:54]  * ogra_` does a jedi wave ... 
[14:54] <ogra_`> there are no issues
[14:54] <sil2100> I'll finish up the transition after UE Live is over
[14:54] <cwayne_> sil2100, davmor2 will need a custom tar run soon
[14:55] <davmor2> cwayne_: definitely not :P
[14:55] <sil2100> AaaaaAAa
[14:55] <cwayne_> ha
[14:55] <davmor2> sil2100: see this is what happens when you open you mouth about image builds working :P
[14:57] <sil2100> Ok then, so I publish ubuntu-keyboard silo now, let's get at least one device tarball in (if possible) and we kick a new image
[14:57] <davmor2> jibel: so it looks like I will be testing tarballs for the rest of the day :)
[14:57] <ogra_`> davmor2, balme imgbot, not sil2100's fault
[14:57] <ogra_`> *blame too
[14:57] <davmor2> ogra_`: why the tick on the tail
[14:57] <sil2100> Then I land the transition and we kick the 'promotion candidate'
[14:57] <ogra_`> davmor2, dsl outages on and off for the last days
[14:57] <sil2100> davmor2: you have time now for a device tarball? When would you be done with it btw.?
[14:58] <davmor2> ogra_`: no nobody notice the buildbot appart from me and sil2100 but he got excited about it :)
[14:58] <ogra_> haha
[14:58] <john-mcaleely> I noticed the buildbot ;-)
[14:58]  * ogra_ too ... since my nick is in the url it pastes i even get an audible ping
[14:58] <john-mcaleely> lol
[14:59] <ogra_> still no notification on my krillin :(
[14:59] <popey> me neither
[15:00] <davmor2> ogra_: wiat till 16:06
[15:00] <ogra_> yeah, i will give it some time
[15:00] <ogra_> it usuall ytakes 10-15min
[15:01] <davmor2> ogra_: I thought the push notification system happens at 5 minutes passed the hour may I was reading the crontab wrong though :)
[15:02] <rsalveti> davmor2: tedg: thanks, will give that a try
[15:02] <rsalveti> no other reason for pulse to take more time to start though
[15:02] <ogra_> well, the imgbot might be ahead of it (it also runs at 5min intervals) ... then i was told that i only get the notification once the image has actually downloaded to the phone already
[15:02] <ogra_> so that will take some extra time
[15:02] <rsalveti> unless we have more stuff starting up at the same time
[15:03] <tedg> rsalveti, Yeah, it does seem odd. But we should fix this anyway.
[15:03] <rsalveti> yeah
[15:03] <tedg> rsalveti, Wonder if it's just the dbus module.
[15:03] <tedg> Does Pulse lazy load them?
[15:03] <john-mcaleely> 174 running on my device. nice
[15:03] <rsalveti> tedg: not actually, it starts when pulse starts itself
[15:03] <davmor2> tedg: just blame thin air if all else fails ;)
[15:03] <rsalveti> but that might slow things down for sure
[15:03] <rsalveti> as it's yet another module to load
[15:04] <rsalveti> will migrate the indicator code to use the native calls, should help on that
[15:04] <tedg> Yeah, but we've had it for a while. No reason for it to change in the last few images.
[15:04] <rsalveti> yeah
[15:04] <rsalveti> crap, so many issues with latest firefox
[15:07] <tedg> rsalveti, So I'm playing with that code now, do you have a pointer on the native interface? I can do that conversion.
[15:08] <davmor2> ogra_: I has notification now
[15:08] <popey> notification arrived here
[15:09] <pmcgowan> woot
[15:09] <ogra_> davmor2, same for me
[15:09] <ogra_> yay
[15:09] <davmor2> ogra_: told you 5 minutes passed the hour :)
[15:09] <rsalveti> tedg: get the code for pulse and check src/pulse/ext-stream-restore.h
[15:09] <ogra_> bah
[15:10] <tedg> rsalveti, Cool, thanks!
[15:10] <ogra_> opening system-settings ... device hangs :(
[15:10] <ogra_> argh
[15:10] <ogra_> and now the session restarts
[15:10] <sil2100> hmmm, maybe I needed to revert system-settings as well
[15:10] <sil2100> Ah, wait, I did
[15:10] <sil2100> nvm
[15:10] <ogra_> note, i'm still on 173
[15:10] <sil2100> AH
[15:10] <sil2100> ok
[15:11] <ogra_> trying to upgrade
[15:11] <sil2100> 2x nvm
[15:13] <davmor2> sil2100, ogra_: so we have 2 tarballs to test and land and a fix for powerd to get in will these two goals clash at all?
[15:14] <davmor2> john-mcaleely: where is your cumulative tarball at for rtm?
[15:14] <sil2100> I was hoping we at least get one tarball in
[15:14] <sil2100> And then I try landing the powerd/upower transition
[15:14] <john-mcaleely> davmor2, http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20141209-cae2b5f.tar.xz
[15:14] <ogra_> yeah
[15:14] <john-mcaleely> davmor2, you'll need a new install instruction though, because it enables gpg signature checking
[15:14] <Mirv> greyback: I reconfigured it in case you didn't get the reconfigure yet
[15:15] <davmor2> john-mcaleely: I don't want it then ;)
[15:15] <john-mcaleely> http://pastebin.ubuntu.com/9444425/
[15:15] <john-mcaleely> contains the script you need
[15:15] <john-mcaleely> save it somewhere handy, and then supply it to u-d-f with --run-script
[15:15] <john-mcaleely> --run-script path/to/that/script.sh
[15:16] <john-mcaleely> so, ubuntu-device-flash touch --bootstrap --channel ubuntu-touch/ubuntu-rtm/14.09-proposed --device-tarball tarbal.tgz --run-script script.sh
[15:16] <john-mcaleely> davmor2, ^
[15:17] <davmor2> john-mcaleely: thanks
[15:24] <om26er> abeato, Hi! can you tell whats the fix for bug 1397997 supposed to look like ?
[15:24] <om26er> before installing the silo I was getting:
[15:24] <om26er> Error creating thumbnail: Failed to preroll.
[15:24] <om26er> I am still getting that error after installing the silo that contains the fix.
[15:25] <abeato> om26er, the error was that in many cases vs-thumb was not finishing with the attached video
[15:25] <om26er> abeato, as in kept waiting ?
[15:26] <abeato> om26er, with the patch that does not happen, although the thumbnail is still not generated depending on race conditions
[15:26] <abeato> om26er, right
[15:26] <om26er> abeato, ok, I couldn't reproduce the original bug though.
[15:27] <abeato> om26er, I guess it does not happen always, are you using mako or krillin?
[15:27] <om26er> abeato, krillin
[15:27] <abeato> I got the error in krillin
[15:28] <abeato> om26er, and are you using the command line as described in the bug?
[15:28] <om26er> abeato, yes, I am using the exact command.
[15:29] <abeato> om26er, ok, I guess it depends a lot on the environment
[15:31] <tedg> trainguards, note that silo vivid/15 will need a packaging review but that was done by kenvandine on the original MR.
[15:41] <sil2100> tedg: ACK
[15:50] <Mirv> ack ack
[15:52] <sil2100> brendand: hey, could you maybe check rtm silo 007 as well?
[15:52] <sil2100> brendand: it's the same thing as in silo 16 but with all the desktop dependencies added
[15:52] <Mirv> pete-woods: pstolowski: not approved https://code.launchpad.net/~marcustomlinson/unity-scopes-shell/oa_ui_policy/+merge/244264
[15:53] <Mirv> psivaa_: pete-woods not approved https://code.launchpad.net/~unity-team/unity-scopes-api/staging/+merge/244159
[15:53] <Mirv> kenvandine: not approved https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/cellular-radio-bug-related-to-1378812/+merge/243804
[15:53] <kenvandine> Mirv, yeah... hang on
[15:53] <Mirv> ... this top-approval system does not really work, but I think trainguards cannot really do but by default expect that they should be done, otherwise errors could happen
[15:54] <sil2100> Mirv: yeah, it seems to be a problem in overall, maybe we need to mention that publicly somewhere that we would appreciate if all those get top-approved before even assigning a silo
[15:55] <kenvandine> i try to check those, but missed it this time
[15:55] <pstolowski> Mirv, both #56 and #49 approved now
[15:56] <rsalveti> 2014-12-10 15:55:33,876 ERROR No silo is available
[15:56] <rsalveti> :-)
[15:56] <rsalveti> got it why
[15:56] <Mirv> sil2100: yes the process could be (somehow..) clearer on that
[15:56] <rsalveti> forgot to set the series
[15:56] <Mirv> pstolowski: thanks!
[15:57] <Mirv> rsalveti: oh, no silos for Ubuntu /dev/null :)
[15:57] <rsalveti> yeah, too bad :P
[16:00] <kenvandine> Mirv, i just realized mandel's mem-leak-fix might have a minor problem... i dropped it until we can investigate
[16:00] <mandel> kenvandine, what is the issue?
[16:01] <mandel> kenvandine, I mean, is ensuring that pointers are not leaked..
[16:01] <kenvandine> mandel, installing click updates hits 100% but never goes away
[16:01] <kenvandine> i confirmed the update finished
[16:01] <kenvandine> mandel, yeah, that fix looked sound to me
[16:02] <Mirv> kenvandine: right. well, I'm used to you publishing your own landings anyway, so I'll give you the honor also this time.
[16:02] <mandel> kenvandine, hm.. that is weird, I'll double check the code, that means that the cpp was working by "luck" lord.. I'm going to kill diego, I'll take a look on what is his mem management doing..
[16:03] <kenvandine> mandel, that code is a real mess btw
[16:03] <kenvandine> i'm sure you noticed :)
[16:03] <mandel> kenvandine, yes, I'm trying to clean it up...
[16:03] <kenvandine> mandel, i really want to refactor it to have an enum for tracking update state
[16:03] <kenvandine> instead of like 3 different bool state values
[16:03] <mandel> kenvandine, he did a very bad job
[16:03] <mandel> kenvandine, yes, the bool states.. oh my god
[16:04] <pstolowski> trainguards, may I ask for silo for #51?
[16:04] <kenvandine> i'd rather have an enum for Available, Downloading, Installing, Installed
[16:04] <kenvandine> something like that
[16:04] <kenvandine> and Downloaded
[16:04] <mandel> kenvandine, yes, is just bad bad code
[16:05] <kenvandine> i fixed a ton of stuff there already, but it needs lots of love still
[16:05] <kenvandine> like before we literally had over 4 instances of UpdateManager instantiated
[16:05] <mandel> kenvandine, I'll do the following, I have a strong feeling that he is connecting more than once to the signals, something that will get f*** up with a delete, will use a deleteLater and will ping you asap to take a look
[16:05] <kenvandine> and signals emitted all over the place
[16:06] <kenvandine> i made it a singleton
[16:06] <kenvandine> yeah
[16:06] <kenvandine> could be
[16:06] <kenvandine> or could be in the QML code
[16:07] <kenvandine> mandel, i thought it finished installing properly the first time i tested it... but after i marked the silo as tested i clicked update on several updates and noticed this
[16:07] <mandel> kenvandine, no worries, is the code that sucks, I'll do my best to refactor all this crap
[16:08] <kenvandine> but it's also possible that i got distracted after i saw it hit 100% and went on to something else
[16:08] <mandel> kenvandine, give me 5 mins and I'll push an update
[16:08] <kenvandine> mandel, thanks!
[16:08] <kenvandine> mandel, although... i was hoping we could most of this code and reuse this update service thing i keep hearing about... that is being written for a backend to the click scope
[16:09] <kenvandine> we really need this code in one place
[16:09] <kenvandine> s/we could/we could remove/
[16:09] <mandel> kenvandine, agreed, I just mantain udm.. and I can do better cpp than diego, but I'm out of the loop regarding the click scope
[16:09] <mandel> kenvandine, alecu should be able to help
[16:10] <kenvandine> i heard someone from thostr_'s team is working on some backend
[16:10] <kenvandine> which we should be able to reuse too
[16:12] <fginther> ogra, I wanted to triple check if all the pieces and network firewall rules are in place for the next krillin build. From what I know, everything should be in place. Are there any verification steps we can do prior to the build being kicked?
[16:12] <sil2100> brendand: hey, you around?
[16:12] <ogra_> fginther, yeah, we had a successful build already
[16:13] <mandel> kenvandine, new rev pushed, can you trigger a rebuild in the silo, or did we loose it?
[16:13] <ogra_> seems all is fine
[16:13] <fginther> ogra_, awesome, thanks!
[16:14] <kenvandine> mandel, lost it for now... sorry
[16:14] <kenvandine> i'll get it in the next landing
[16:14] <mandel> kenvandine, no worries, we can wait for the bot to build an armhf deb to test with in the mean time
[16:15] <kenvandine> mandel, is the bot online again?
[16:15] <mandel> kenvandine, I prefer to be late and right that otherwise, so good job :)
[16:15] <mandel> kenvandine, is it not? I was on holidays for 4 days, I expected it to be hehe
[16:15] <kenvandine> it's been down for days :/
[16:15] <sil2100> jibel: hey, I'm looking for someone from QA to help pre-signing off silo 007
[16:16] <sil2100> jibel: it's the same as silo 16 basically, just with proper version numbers and all the desktop bits
[16:16] <kenvandine> mandel, which REALLY hurts for settings...
[16:16] <mandel> kenvandine, yes
[16:16] <mandel> kenvandine, what a PITA :-/
[16:19] <brendand> sil2100, yep
[16:19] <sil2100> brendand: were you the one testing silo 16 previously?
[16:20] <brendand> sil2100, yes
[16:20] <sil2100> brendand: could you have a look at silo 007 then? It's basically the same thing, just added all deps required for proposed migration (for desktop)
[16:21] <brendand> sil2100, ok
[16:22] <sil2100> brendand: thanks! Since I might need to include some other desktop packages, but I won't know that before I don't publish everything that's in this silo first ;)
[16:22] <thostr_> kenvandine: alecu is on vacation, so you might want to ping dobey on anything about click scope
[16:23] <dobey> hrmm?
[16:24] <kenvandine> thostr_, not really the scope, but the backend to install the clicks
[16:24] <Mirv> pstolowski: done
[16:24] <kenvandine> i heard there were plans to create something outside of the scope itself for doing that
[16:24] <kenvandine> with a proper API
[16:24]  * Mirv and gone
[16:24] <thostr_> yes, that was the plan
[16:24] <thostr_> but we put on ice for now
[16:25] <kenvandine> thostr_, that makes me sad
[16:25] <kenvandine> i wanted to re-use that in system-settings :/
[16:25] <pstolowski> Mirv, thanks!
[16:25] <thostr_> after we talked to mvo who mentioned that they rethink click packaging...
[16:25] <kenvandine> that code is fragile
[16:25] <thostr_> so we decided to hold our horses for now
[16:29] <dobey> kenvandine: it makes me sad too. i want to get all the networking and such out of the scope itself
[16:31] <kenvandine> dobey, yeah, and we have lots of fragile code in settings to deal with it
[16:31] <dobey> kenvandine: eh?
[16:32] <kenvandine> checking for updates, downloading clicks... calling out to pkcon, etc
[16:32] <dobey> i don't understand why the code in settings would be particularly fragile. mostly it should just be duplicate and thus annoying in that sense
[16:32] <kenvandine> well, it wasn't well done to start with
[16:32] <pstolowski> Mirv, anything wrong with #51?
[16:32] <kenvandine> and needs lots of refactoring to not suck
[16:32] <kenvandine> i'd rather just delete it :)
[16:32] <Chipaca> could I have a silo for #69 pretty please?
[16:32] <dobey> yeah, i feel that way about some things
[16:35] <Chipaca> um, it's now #68 (or i can't count)
[16:36] <Chipaca> sil2100: Mirv: ^^ please?
[16:37] <sil2100> Chipaca: o/
[16:37] <Chipaca> sil2100: heya! :)
[16:40] <ralsina_> there's IIRC three different implementations of "get the list of installed click packages" in settings, none of them use the recommended means, which is libclick
[16:40] <Chipaca> ooohh, silo 000!
[16:40] <Chipaca> ralsina_: we should fix that :)
[16:40] <ogra_> the secret one ;)
[16:40] <ralsina_> Chipaca: I only wrote one! ;-)
[16:42] <Chipaca> sil2100: any idea why on my first build i'd get a “You already tried to build everything.” error?
[16:44] <sil2100> Chipaca: on the first build? That's a bug for sure - is it the first build after assignment, right?
[16:44] <Chipaca> sil2100: and the first build of the day
[16:44] <Chipaca> sil2100: yes
[16:45] <Chipaca> waaaait
[16:45] <Chipaca> sil2100: i clicked the wrong 'build'
[16:45] <sil2100> huh?
[16:45] <sil2100> ;)
[16:45] <Chipaca> sil2100: i clicked the one below the info, instead of the one above
[16:46] <pstolowski> trainguards is there anything wrong with #51, or somebody accidentally hit strikethrough?
[16:46] <sil2100> pstolowski: hm, I think this is some accident, no worries
[16:46] <ogra_> we have a #51 ?
[16:47] <pstolowski> ogra_, we do, row in the spreadsheet ;)
[16:47] <pstolowski> sil2100, cool, thanks
[16:47] <ogra_> lol
[16:47] <sil2100> pstolowski: I think Mirv fixed it ;)
[16:47] <ogra_> pstolowski, usually #nnn refers to image numbers :P
[16:47] <ogra_> at least in here
[16:48] <pstolowski> ogra_,  I know; i've also been using that format when requesting silos, and so far no one complained ;)
[16:49] <ogra_> no worries :)
[16:49] <sil2100> ;)
[16:55] <Mirv> sil2100: no, I couldn't, since I already announced I'm not here anymore!
[16:55] <sil2100> Mirv: hah!
[16:56] <Chipaca> can't go breaking causality and doing stuff when you're not here
[16:56] <Chipaca> that would not do
[16:58] <ogra_> sil2100, dont distract him from his snappy !
[16:58] <sil2100> Uh oh!
[17:03] <pmcgowan> sil2100, silo 7 seems fine here
[17:04] <brendand> sil2100, silo 7 seems sane
[17:04] <pmcgowan> :)
[17:18] <ogra_> sil2100, hitting the button
[17:18] <ogra_> (uless you scream "nooo" now)
[17:20]  * ogra_ hears no scream and hits enter 
[17:20] <ogra_> triggered
[17:22] <sil2100> Nooooo ;)
[17:22] <sil2100> Just kidding
[17:22] <ogra_> :P
[17:22] <sil2100> ogra_: thanks!
[17:25] <imgbot> [17:26] <brendand> sil2100, so you want me to sign off silo 7?
[17:27] <sil2100> brendand: yes, please ;) We'll publish it once the rootfs for 175 finishes building
[17:27] <sil2100> brendand: thanks!
[17:31] <alex-abreu> robru, L69 is in silo 18 right? (the stylesheet hasn't been updated w/ the silo #)
[17:32] <robru> alex-abreu: yeah
[17:33] <robru> alex-abreu: sorry I usually say so when i assign it but just a bit busy today
[17:33] <alex-abreu> np
[17:35] <sil2100> jhodapp: hey!
[17:35] <jhodapp> sil2100, hey
[17:35] <sil2100> jhodapp: did you have time to take a look at LP: #1398961 ?
[17:36] <sil2100> jhodapp: not sure if that's completely something you can help with, but still ;)
[17:36] <sil2100> jhodapp: it's from vivid
[17:36] <jhodapp> sil2100, yes, I can't reproduce that
[17:36] <sil2100> jhodapp: you have a manta device handy?
[17:37] <jhodapp> sil2100, oh wait, sorry I overlooked manta
[17:37] <jhodapp> sil2100, no, don't have a manta
[17:37] <sil2100> jhodapp: could you comment in the bug if anything? Then davmor2 can certainly help you out with debugging
[17:37] <jhodapp> sil2100, yeah I have no ideas on that bug without playing with it myself
[17:38] <jhodapp> sil2100, I'll add some comments to ask dave for more info
[17:38] <jhodapp> sil2100, but it's a very low priority bug
[17:38] <bfiller> trainguards: can I have a reconfigure of ubunt silo 8 please (added a new package)
[17:38] <sil2100> bfiller: o/
[17:38] <davmor2> jhodapp: :)
[17:40] <robru> bfiller: 8 is boiko's. did you mean 7?
[17:40] <jhodapp> davmor2, there we go, take a look at the bug comments
[17:40] <bfiller> robru: no it's 8, boiko and I have been testing (I'll add my name)
[17:42] <robru> bfiller: ok, can do
[17:46] <sil2100> ogra_: can you disable the importer in system image? We might want to push a device tarball to the image :)
[17:50] <ogra_> sil2100, done
[17:52] <john-mcaleely> ogra_, sil2100 should I push a tarball now then?
[17:52] <sil2100> ogra_: thank you :)
[17:52] <sil2100> john-mcaleely: wait for a final +1 from davmor2
[17:52] <john-mcaleely> sil2100, ack
[17:52] <sil2100> ogra_: when we re-enable the importer, it will spit out one image, right?
[17:52] <sil2100> (that has our changes + the tarball?)
[17:53] <ogra_> yes
[17:53] <davmor2> john-mcaleely, sil2100: okay so everything it say it fixes seems to be good the base image already passed so I'm happy
[17:54] <john-mcaleely> yay
[17:54] <sil2100> yay
[17:54] <john-mcaleely> ogra_, sil2100 so, I should push then?
[17:54] <sil2100> john-mcaleely: ok, push teh tarballz!
[17:54] <sil2100> ogra_: if that's fine with you?
[17:54] <ogra_> what are the bribes i have to expect ?
[17:54] <ogra_> do we have an average rate ?
[17:55] <davmor2> ogra_: I don't blow up you house and car?
[17:55] <cwayne_> that escalated quickly
[17:55] <john-mcaleely> gosh
[17:55] <ogra_> pfft ...
[17:56] <ogra_> john-mcaleely, under that thread, yes, please push it
[17:56] <john-mcaleely> ogra_, ack
[17:56] <davmor2> jhodapp: added it to my needs to be done list
[17:57] <john-mcaleely> ogra_, sil2100 davmor2 pushed
[17:57] <john-mcaleely> thank you all
[17:57] <ogra_> :)
[17:59] <davmor2> ogra_: did they fix my breakage in your internet line?  I figured it was the only way to make you have a holiday ;)
[18:00] <ogra_> haha, it wasnt a holiday at all ...
[18:00] <ogra_> i was the coffee bitch for the guys all day
[18:00] <davmor2> ogra_: hahaha
[18:00] <john-mcaleely> you loved it really
[18:01] <sil2100> ogra_: hah! But in all seriousness, you should take next week off!
[18:01] <sil2100> Like, srsly man
[18:01] <ogra_> i will take vacation from next week to next year
[18:01] <ogra_> 4 weeks ... to burn all my left holidays
[18:01] <sil2100> Burrn them all
[18:02] <davmor2> burn them with fire
[18:02] <davmor2> wait no no don't then you have no holiday and will have to work
[18:02] <ogra_> i fear i wont manage to burn them all :)
[18:03]  * ogra_ never does ... trying that since years 
[18:08] <cwayne_> man, we don't even get 4 weeks in US :)
[18:09] <ogra_> in germany you get two days added per year or some such
[18:09] <ogra_> or one
[18:10] <jhodapp> davmor2, cool
[18:15] <dobey> jibel: ping re pay-ui.
[18:16] <dobey> though i guess you may be gone already, being in europe and all
[18:31] <sil2100> ogra_: is the rootfs done? :)
[18:31] <ogra_> sil2100, already importing :)
[18:31] <sil2100> ogra_: ok, so it should be fine if I try to 'break the world' again, right? ;)
[18:32] <ogra_> well, i wouldnt push a custom or device tarball while the importer is runnign ...
[18:32] <ogra_> but yeah, go wild on the archive :)
[18:37] <sil2100> Ok, trying, expect breakages in teh rtm archive!
[18:37] <sil2100> ;)
[18:37]  * ogra_ ducks and covers
[18:39] <davmor2> ogra_: you know this is rtm right?  Saying go wild is the one thing we are trying to avoid ;)
[18:39] <ogra_> davmor2, but we dont want to take all the fun out for you
[18:39] <ogra_> there has to be some excitement
[18:40] <imgbot> [18:40] <imgbot> [18:40] <sil2100> Come on, breaking stuff is part of our job, don't take that away from us
[18:40] <sil2100> \o/
[18:40] <ogra_> moar keeeboard
[18:41] <davmor2> sil2100: no breaking things is part of our job fixing them is yours
[18:56] <sil2100> ogra_: ugh, wowo
[18:57] <sil2100> ogra_: ...or nevermind, scratch that
[18:57] <john-mcaleely> now has 175 goodness on my phone :-)
[19:00]  * ogra_ scratches
[19:08]  * sil2100 waits for -proposed migration to work on ubuntu-rtm
[19:08] <sil2100> Last update_output was "Generated on: 2014.12.10 18:41:42 +0000"
[19:09] <sil2100> Is it supposed to be so slow?
[19:21] <robru> sil2100: I'm timezonally deficient, is that more than an hour lag you're seeing?
[19:22] <kenvandine> brendand, is rtm silo 2 blocked?
[19:23] <kenvandine> i don't see any comments about it being blocked, but it has the blocked status
[19:24] <sil2100> Ok, bleh, bleh bleh
[19:24] <sil2100> Transition needs even moar work ;)
[19:24] <ToyKeeper> kenvandine: I've been bugging people about exactly that sort of communication issue...  but it's an uphill battle.  :(
[19:25] <kenvandine> yeah, i just don't know if it is waiting for me or anything?
[19:25] <kenvandine> it got moved back into under testing
[19:25] <kenvandine> but still shows blocked
[19:27] <ToyKeeper> kenvandine: Personally, I think it should have a lane for "ready" (a.k.a. waiting on QA), "blocked", (waiting on someone outside QA), "under testing" (actively being tested right now), plus passed/failed...  but as things are now, the lanes are mostly irrelevant and the tags specify status.
[19:27] <ToyKeeper> Except the tags are confusing and people are bad about adding clear comments and ... so on.  :(
[19:28] <ToyKeeper> sil2100: Can you confirm which rtm image is the promotion candidate, and (if not 175) when it might start building?
[19:29] <alex-abreu> bzr
[19:31] <sil2100> ToyKeeper: well, still trying to get the packages migrated
[19:32] <sil2100> ToyKeeper: so for now it still might take time - if it takes too long, we'll use 175
[19:32] <ToyKeeper> sil2100: Okay, let me know.  :)
[19:36] <sil2100> huh
[19:38] <sil2100> ogra_: so the upower stuff does not install because of some problems with language packs, huh
[19:39] <sil2100> cjwatson: hey! Are you still around? :)
[19:40] <ogra_> hmm
[19:40] <sil2100> Oh, no, wait
[19:40] <sil2100> We just need new ones
[19:40] <ogra_> just ...
[19:40] <sil2100> grrr
[19:40] <sil2100> We need a massive copy-package for those ;/
[19:41] <ogra_> i'm not sure who can trigger them ... either wgrant or pitti would be your contact
[19:41] <ogra_> oh, you mean desktop ones ?
[19:41] <sil2100> Yeah, desktop ones
[19:41] <ogra_> crap
[19:42] <bfiller> robru: can you press the publish button on ubuntu silo 7 please?
[19:42] <sil2100> ogra_: do you think you could update those, or should I use teh silo?
[19:43] <sil2100> Since they're main packages ;/
[19:43] <ogra_> ugh
[19:43] <sil2100> hm, maybe I'll use teh silo
[19:43] <sil2100> Just copy the binaries over
[19:44] <ogra_> ogra@styx:~/Devel/ninja/generic/linux-3.16.0$ apt-cache search language-pack|grep -v touch|grep -v kde|wc -l
[19:44] <ogra_> 340
[19:44] <sil2100> apt-get only mentions like 5 missing, but hm, that might not be enough
[19:45] <sil2100> On my rtm machine
[19:45] <ogra_> well, try with the 5 first
[19:45] <sil2100> Yeah, let me  push those - just to make sure: both language-pack-gnome-*-base and language-pack-*-base langpacks are not used on our phones, right?
[19:46] <ogra_> nope
[19:46] <sil2100> Phew, then let the pushin' begin'!
[19:46] <robru> bfiller: sure
[19:46] <ogra_> http://cdimage.ubuntu.com/ubuntu-touch/ubuntu-rtm/14.09/daily-preinstalled/20141210.1/14.09-preinstalled-touch-armhf.manifest only touch  ...
[19:47] <bfiller> robru: thanks, and silo 8 while you're at it :)
[19:51] <sil2100> ogra_: aww fuuudge
[19:51] <ogra_> you need all 340 ?
[19:51] <sil2100> No, actually I found the root problem
[19:51] <sil2100> Moar transitioning ;<
[19:52] <ogra_> oh man
[19:53] <sil2100> Why do we have nautilus in the rtm branch anyway?!
[19:53] <ogra_> some dep
[19:53] <ogra_> i guess
[19:55] <sil2100> This is bullshit, damn it
[19:56] <ogra_> well, what a luck you are doing this now ... imagine we would have found that out when someone had an rtm specific patch to upower
[19:57] <ogra_> (i.e. as a semi-planned thing)
[20:01] <brendand> kenvandine, sorry for the late response
[20:02] <brendand> kenvandine, as i mentioned to jgdx earlier today, i'd really like to hear mpt's feedback on (his own) design
[20:02] <jgdx> haven't heard from him all day
[20:02] <jgdx> hope he's ok
[20:02] <jgdx> (or on a beach somewhere)
[20:04] <sil2100> Let me try something then
[20:04]  * sil2100 is a transition noob
[20:04] <sil2100> ogra_: ok, this might take a bit longer - what would you say if we do regression testing on 175 for now?
[20:05] <sil2100> I guess upower/powerd got some attention already earlier, so it *should* be safe
[20:05] <sil2100> As otherwise I'll be delaying this even further
[20:08] <robru> alex-abreu: https://code.launchpad.net/~abreu-alexandre/ubuntu-html5-theme/add-oxide-switch-flag/+merge/244337 please approve your mp
[20:08] <sil2100> ogra_: is there an easy way to fetch sources from ubuntu-rtm for a specific version number from the commandline?
[20:08] <ogra_> sil2100, yeah, i'd say lets go with 175
[20:08] <alex-abreu> robru, done, thx
[20:09] <ogra_> uh, not sure, i never had to mass-fetch ... i usually pulll them from LP
[20:09] <sil2100> ogra_: sorry about this, I missed the last bit and this caused we need another batch of rebuilds...
[20:09] <sil2100> ToyKeeper: hey! Can you start your testing for 175?
[20:09] <ogra_> sil2100, no worries, no harm done
[20:09] <pmcgowan> sil2100, are you still trying to land upower
[20:10] <ogra_> should i disable the cron job ?
[20:10] <sil2100> pmcgowan: yes, doing that all the time now
[20:10] <ogra_> pmcgowan, yes, its a painfully huge transition
[20:10] <pmcgowan> so it seems
[20:10] <sil2100> ogra_: yes please
[20:10] <pmcgowan> yikes
[20:10] <ogra_> well, only dependencies that we dont even install
[20:10] <pmcgowan> thats awful
[20:11] <ogra_> yup
[20:11] <ogra_> but unavoidable
[20:11] <ogra_> see bug 1330037
[20:11] <pmcgowan> omg
[20:11] <ogra_> (we dont need all of this luckily)
[20:12] <pmcgowan> why do i suspect the new upower broke apis
[20:12] <ogra_> heh
[20:12] <renatu> sil2100, I am getting this error on jenkins: file:///tmp/buildd/telephony-service-0.1+15.04.20141121.1bzr975pkg0vivid13/Ubuntu/Telephony/tests/tst_PhoneNumberField.qml:24:1: UbuntuTestCase is not a type
[20:12] <renatu> sil2100, and this "UbuntuTestCase" is part of qtdeclarative5-ubuntu-ui-toolkit-plugin
[20:13] <renatu> which is listed on debian control build dep
[20:13] <renatu> sil2100, this is the MR: https://code.launchpad.net/~renatofilho/telephony-service/fix-1372548/+merge/243997
[20:19] <ToyKeeper> sil2100: Not expecting 176 to build any time soon?
[20:19] <ogra_> ToyKeeper, nope
[20:20] <ToyKeeper> sil2100: I can definitely get started on 175, just prefer to avoid re-doing everything if a new image comes out right away.
[20:20] <ogra_> the transition will take longer and we cant build an image before it is done
[20:20] <ogra_> (or we shouldnt at least)
[20:21] <sil2100> I think 175 is fineish
[20:22] <sil2100> Victor mentioned he wanted to have that released, even before we had upower silo ready
[20:25] <robru> kenvandine: mterry: anybody around for a packaging ack? got a new binary package: https://ci-train.ubuntu.com/job/ubuntu-landing-006-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-keyboard_0.99.trunk.phablet2+15.04.20141209.1-0ubuntu1.diff
[20:30] <sil2100> ogra_: ok, if all goes well now, we only will need those rebuilds and it should be fine
[20:30]  * sil2100 hopes so
[20:30] <mterry> robru, looks fine, sure
[20:30] <robru> mterry: thanks
[20:32] <pmcgowan> sil2100, this is like when mterry tried to land split greeter :)
[20:32] <sil2100> hah ;)
[20:32] <mterry> pmcgowan, be careful man, I've got PTSD
[20:33] <pmcgowan> lol
[20:33] <pmcgowan> I bet
[20:45] <ogra_> sil2100, well, let me know if you are done and need an image ... i thought you stopped for the evening now
[21:03] <kenvandine> brendand, thanks, can you comment on trello or something?
[21:03] <alesage> trainguards, I'm ready for my Job/Build permission :) , for allanlesage
[21:03] <sil2100> Packages almost built \o/
[21:03] <alesage> kenvandine will endorse me trainguards :)
[21:04] <kenvandine> :-D
[21:13] <robru> alesage: oh hey, you want to be able to trigger builds in silos?
[21:13] <alesage> robru, yes please
[21:13] <robru> alesage: ok one sec, gotta fix the train first
[21:13] <alesage> robru, no rush, thanks
[21:14] <robru> alex-abreu: hey are you around? I need you to add ci-train-bot to this team: https://launchpad.net/~ubuntu-html5-theme-devs somewhat urgently
[21:15] <robru> mhall119: if you're around, please ^
[21:15] <robru> alex-abreu: mhall119: and delete ps-jenkins from the team while you're at it
[21:16] <ToyKeeper> sil2100, robru: Do you know if 176 has anything special going in?  Like, should we pause silo tests until 176 is out?
[21:16] <robru> alesage: ok, added you. do you have a silo yet?
[21:16] <robru> ToyKeeper: dunno, sil2100 or ogra_ would know I guess
[21:16] <sil2100> No no
[21:16] <alesage> robru, came up because of a silo just passed, thanks
[21:16] <sil2100> ToyKeeper: please continue, 176 will only have the upower/powerd stuff, but let's not wait for that
[21:17] <robru> alesage: right you're welcome
[21:17] <ToyKeeper> Okay, I won't hold up other silos then.
[21:17] <robru> sil2100: ugh we have another branch that can't be pushed to
[21:18] <robru> sil2100: I've temporarily disabled check-publication-migration so that we don't get a trunk full of 'remerge trunk' commits again.
[21:18] <alex-abreu> robru, done
[21:18] <robru> alex-abreu: thanks
[21:19] <robru> alex-abreu: ok, success great ;-)
[21:19] <robru> sil2100: no worries, fixed now
[21:22] <robru> score
[21:23] <robru> brb, fooood
[21:31] <mhall119> robru: looks like alex-abreu beat me to it
[21:46]  * sil2100 waits for CI Train build job to finally do his job
[21:57] <robru> mhall119: Ooooooooooh yeah thanks
[22:00] <sil2100> robru: what's up with this? https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-007-1-build/71/console
[22:00] <sil2100> robru: I ran a watch-only build on my silo 007 and it's like that since a while now
[22:00] <sil2100> Since 15 minutes at least...
[22:03] <sil2100> Ok, finally
[22:03] <sil2100> It took ages
[22:22]  * sil2100 prepares to make the situation even worse
[22:30] <sil2100> robru: hm, just out of curiosity - do yuou handle the case not to re-release already published packages in the new publisher script?
[22:34] <robru> sil2100: why do you ask? ;-)
[22:34] <sil2100> robru: since I republished and it seems the train just re-released all the packages
[22:35] <robru> sil2100: indeed when you publish it will republish already-published packages. how did you get into that state though? it shouldn't be half-publishing a silo in the first place.
[22:36] <sil2100> robru: well, the previous publisher was smart enough not to do that ;) Since we were re-publishing silos multiple times - sometimes you publish a silo, and then you for instance need to just modify slightly one component and republish the silo
[22:36] <sil2100> The train needs to only republish the thing that got rebuilt or is new in the silo
[22:36] <sil2100> Not a big deal here, as proposed will just have to re-validate the already uploaded stuff
[22:36] <robru> sil2100: hm. is there any specific harm in republishing something already publish? probably proposed will just reject the copy, right?
[22:37] <robru> sil2100: actually there is a check for the package version at the destination, if it changed since prepare then it will fail the publish.
[22:37] <sil2100> Well, unneeded traffic and confusion, since if a package already migrates from -proposed to the archive there will be a rejection
[22:38] <robru> sil2100: ok well file a bug and assign it to me, I can re-add that check a bit later. right now the priority is on getting the charm working (we're close, but it needs to be reviewed by IS and might need some modifications with their guidance)
[22:39] <sil2100> Sure
[22:39] <pmcgowan> sil2100, is that a silo or a new archive!  looks like ubuntu-touch/sil2100
[22:40] <sil2100> Almost there...
[22:40] <sil2100> ;)
[22:40] <pmcgowan> sorry couldnt resist
[22:41] <robru> sil2100: oh also, regarding the build job log you linked, that error indicates that the script could not find any version of indicator-keyboard in the PPA. I see it's in there now, but I guess you ran the job too soon and the package wasn't in the PPA at the time (there's only a 20 minute window to upload the packages after you start the watch_only job, best
[22:41] <robru> to upload the package first and then watch_only after)
[22:42] <sil2100> robru: I know, I was asking about before this message popped up
[22:42] <sil2100> robru: since it wrote like 4 times "INFO Checking PPA for source packages..."
[22:43] <sil2100> robru: and took 20 minutes to actually write that it's meeting indicator-keyboard
[22:44] <robru> sil2100: I'm pretty sure watch_ppa was always like that, even before my rewrite? it has a 20 minute window in which it scans the PPA every 5 minutes looking for the packages and versions it expects.
[22:44] <robru> sil2100: are you saying you want it to report what's missing every 5 minutes rather than waiting until the end of the 20 minutes? that should be a simple change, please file a bug ;-)
[22:44] <sil2100> But it wasn't able to find anything, it's not that it was actually mentioning that some packages are building every 5 minutes - it was standing there and seemingly doing nothing for 20 minutes ;p
[22:45] <robru> sil2100: well it is literally standing there and doing nothing. it's waiting for the package to appear in the PPA, which should be uploaded either manually or by a previous build job.
[22:46] <sil2100> The problem is that all packages were already uploaded and built - there was one that missed an upload, but don't tell me it had to wait 20 minutes to actually notice that it's not there, as for all other silos this was happening almost instantly ;)
[22:47] <sil2100> Maybe it was due to the PPA having a lot of packages
[22:48] <robru> sil2100: when I was rewriting watch_ppa, I found that often LP was actually quite slow to report the PPA contents. waiting 5 minutes and then checking, it would often not report some packages, or only report old versions of some packages. so I broke it down into two phases. there's a sort of "collection" phase where it just waits for the right packages and
[22:48] <robru> versions to appear in the PPA. and then there's a "reporting" phase where it reports the build status for those packages. usually the collection phase only needs one or two iterations before it moves on to the reporting phase. but in this case indicator-keyboard was not present at all and so the collection phase timed out and reported that error.
[22:49] <robru> sil2100: anyway I'm open to changing this behavior if you can recommend a specific change. but I don't really see a problem so far.
[22:53] <sil2100> robru: we'll think about that later indeed
[22:53] <sil2100> ogra_, pmcgowan, cjwatson: ok, this transition is a nightmare
[22:54] <pmcgowan> sil2100, and I suppose we couldnt just remove all those packages we dont use from the archive
[22:54] <sil2100> pmcgowan: this is the problem - and now we have some conflicts, and from what I see they're caused by some stupid requirements for language-packs
[22:55] <pmcgowan> frankenrepo
[22:55] <sil2100> And I'm afraid that once I sync up those langpacks, some other conflicts will appear because of applications that might require older ones (not sure if that's indeed possible)
[22:55] <pmcgowan> hmm
[22:56] <pmcgowan> and is upower the root cause of all this?
[22:57] <pmcgowan> nm I have no solution
[22:57] <robru> pmcgowan: heh, guess you've never seen one of Mirv's qt silos. easily triple this size.
[22:57] <sil2100> Yeah, since upower started the whole chain... upower 0.99 broke API and requires changes in all clients to enable that, so we had to pull in new versions of those from vivid
[22:57] <sil2100> And this pulls in new dependencies, and dependencies pull in dependencies
[22:57] <pmcgowan> sil2100, was thinking we make a upower-touch package for us and leave everything we dont need happy
[22:57] <sil2100> It's hell on earth
[22:59] <sil2100> hm, that might be one option, but that might require some work
[22:59] <sil2100> The transition was actually the 'easy way'
[22:59] <pmcgowan> so we change the deps for the packages we actually install, which might be like 4 or 5?
[22:59] <pmcgowan> dunno just an idea
[23:02] <pmcgowan> sil2100, so I installed 4 packages to test that the update worked, so seems we can work around this and its all dependency nonsense
[23:02] <sil2100> Might be possible, although I'm a bit weary of doing another split package
[23:02] <sil2100> In any way, I'll work on this more tomorrow, today is too late anyway
[23:02] <pmcgowan> indeed, call it a day
[23:02] <sil2100> I need some archive admin now that would remove those packages from proposed for now
[23:02] <sil2100> ;)