[01:07] <Saviq> cihelp
[01:07] <Saviq> hey, anyone - seems all maguros are down http://<IP_ADDRESS>:8080/job/generic-mediumtests-runner-maguro/ ?
[01:07] <Saviq> ah, they're being flashed are they...
[01:08] <Saviq> it seems the flash process has failed, then...
[01:08] <Saviq> http://<IP_ADDRESS>:8080/job/touch-flash-maguro-014E058C18015006/183/console
[03:32] <doanac> Saviq: i don't have access to those systems. I'm going to email the ci mailing list and hopefully someone can get them online
[03:32] <Saviq> doanac, thanks, it might be that the image is completely b0rked or something, if all of them fell down
[03:34] <veebers> doanac: oh hey, can you add to your email that I've modified http://<IP_ADDRESS>:8080/job/generic-mediumtests-trusty-touch/ -> I removed generic-mediumtests-runner-maguro  from the queue
[03:34] <doanac> veebers: shure
[03:34] <veebers> doanac: awesome thanks
[03:46] <Saviq> veebers, so new jobs will pass?
[03:46] <Saviq> veebers, or at least ignore maguro?
[03:46] <veebers> Saviq: well, new jobs won't use the maguro runner so will get further
[03:46] <veebers> Saviq: yes :-)
[03:46] <Saviq> veebers, that's useful, thanks
[03:47]  * Saviq cancels all the hanging unity8 jobs
[03:47] <veebers> Saviq: we will either have to kill the current jobs or wait for them to timeout
[03:47] <veebers> Saviq: heh
[03:47] <Saviq> veebers, how long the timeout?
[03:47] <Saviq> veebers, they've been at it for 10hrs now or something...
[03:50] <veebers> Saviq: ugh right, not sure but 10 hours is too long
[03:50] <Saviq> veebers, yeah....
[03:53] <Saviq> doanac, FWIW, I'm not sure ssh alone would've helped in that case... there's no adb to the devices (as a result of failed flashing), so unless they're stuck in bootloader, and willing to listen to fastboot reboot, they need physical intervention...
[03:54] <Saviq> doanac, there was talk of a supposedly standard 3.5mm jack contraption for low level access to the hardware
[03:56] <doanac> Saviq: usually i just see devices stuck in the bootloader.  ie - i haven't seen to many stuck
[03:57] <Saviq> doanac, do they then accept `fastboot reboot` and such?
[03:57] <doanac> Saviq: i normally just do a "fastboot reboot" and it boots
[03:57] <Saviq> doanac, right
[03:57] <doanac> note: if its really stuck, a serial console might not be much help either
[03:58] <doanac> you really need to be able to hold the power button down somehow
[08:09] <Mirv> FYI I've been doing the needed hoops to transition to libmirserver10 this morning
[08:11] <sil2100> 10 already?
[08:11] <sil2100> How time flies...
[08:39] <sil2100> At least all the FTBFS problems right now seem to be related to the mir transition...
[08:43] <Mirv> sil2100: not all
[08:48] <sil2100> Right, unity7 and indicators are still real problems
[09:06] <Mirv> sil2100: indicators not, should be hopefully fixed now, but mir unity-system-compositor + unity7 yes
[09:06] <sil2100> Mirv: is unity8 stack ready for re-build? It was failing because of libunity-mir-dev : Depends: libunity-mir1 (= 0.1+14.04.20131104-0ubuntu1)
[09:07] <sil2100> Mirv: well, there was a chroot problem besides the mir transition problem in indicators, but I guess that got fixed with the subsequent run
[09:07] <sil2100> Mirv: so it wasn't just mir problems in indicators ;)
[09:07] <sil2100> Mirv: for unity7 I'm still waiting for updates from bregma
[09:09] <Mirv> sil2100: it's not failing because of unity-mir, but because unity-mir FTBFS
[09:09] <didrocks> thomi_: not sure if you are around, but can we proceed with step 1, are you ready for transitioning to 1.4 tomorrow?
[09:10] <Mirv> hi didrocks!
[09:10] <didrocks> hey Mirv!
[09:10] <sil2100> Hi didrocks!
[09:10] <didrocks> morning sil2100 :)
[09:10] <Mirv> didrocks: we've a problem with mir again I think. I've been rebuilding stuff to transition to libmirserver10, but unity-system-compositor and unity-mir FTBFS against it (bugs filed)
[09:10] <didrocks> Mirv: Mir was pulled to trunk?
[09:10] <Mirv> didrocks: so it'd be the usual deadlock, can't publish, can't rebuild
[09:10] <sil2100> Mirv: oh, I see now that unity-mir looks like a 'real' compilation problem, missing/removed include it seems?
[09:10] <didrocks> without warning us?
[09:11] <Mirv> didrocks: I guess so, new commits in there
[09:11] <didrocks> Mirv: please revert trunk
[09:11] <didrocks> and remove everything from the ppa that built against it
[09:11] <sil2100> Mirv: did you fill in the bugs to "Stack status" ?
[09:12] <Mirv> sil2100: yes
[09:12] <Mirv> didrocks: ok
[09:12] <sil2100> Oh, it might not be needed soon
[09:12] <popey> didrocks: AIUI thomi_ was travelling yesterday so wasn't online, and won't be until ~20 UTC
[09:12] <Mirv> didrocks: I need to somehow find what the trunk used to be before the pull
[09:12] <didrocks> popey: ok, thanks :)
[09:12] <popey> np
[09:13] <didrocks> Mirv: you do have that info, right? the changelog + merge back should point to a rev?
[09:14] <Mirv> didrocks: sure
[09:27]  * ogra_ -> coffee ... brb
[09:27]  * Mirv removed hud, indicator-location, mir, platform-api, qtubuntu, ubuntu-keyboard, unity-mir from PPA
[09:28] <sil2100> ;/
[09:31] <didrocks> popey: coming?
[09:32] <popey> ya
[09:32] <popey> stupid browser
[10:50] <xnox> didrocks: Hello! =) i made a merge proposal, and the merger is test-building my package against "trusty", but i need "trusty-proposed" enabled as well.
[10:51] <didrocks> xnox: you mean about the upstream merger, not daily release, right?
[10:51] <xnox> didrocks: i believe so, yes. Let me get URL.
[10:52] <xnox> https://code.launchpad.net/~xnox/ubuntu-keyboard/libpinyin4/+merge/193859
[10:52] <xnox> and
[10:52] <xnox> https://jenkins.qa.ubuntu.com/job/ubuntu-keyboard-ci/210/
[10:52] <didrocks> xnox: ok, yeah, upstream-merger: that would be for vila or fginther I guess ^^ (cu2d is using -proposed enabled)
[10:59] <vila> didrocks, xnox: We'll need fginther indeed :-/ But I'm surprised that -proposed is not enabled, that would diverge from cu2d and will break far more often no ?
[11:00] <didrocks> vila: IIRC, it's indeed not enabled. There were strong argument in both cases
[11:00] <didrocks> in practice, enabling -proposed isn't too much troublesome for cu2d, so I guess it won't for upstream merger
[11:01] <cjwatson> well, clearly needs to be *possible* to enable it at least
[11:01] <didrocks> but we still need a way to enable/disable it easily
[11:01] <didrocks> yeah
[11:02] <xnox> didrocks: vila: does upstream merger have any PPAs enabled? e.g. same ones that cu2d is using? Maybe pinyin from trusty-proposed can be copied into one of those?
[11:02]  * xnox only needs libpinyin4-dev from trusty-proposed.
[11:03] <didrocks> xnox: well, I would prefer that we fix it properly, let's see once fghinter is around. But otherwise yes, from what I know, it's using the daily-build ppa, so we can copy it there if needed
[11:04] <xnox> I did file a bug against ci-services.
[11:04] <xnox> https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1247992
[11:05] <vila> xnox: perfect
[11:06] <asac> didrocks: so from what i know upstream merger uses ppa-purge etc. to get back to a pristine state... do you know if ppa-purge feature is usable with -proposed? otherwisxe the devices would accumulate all kind of not-wanted stuff - or would always need a complete reinstall, which would be time consuming:)
[11:06] <asac> maybe we need proposed-purge - if that doesnt work :)
[11:06] <vila> xnox: I'll make sure to ping fginther about it, also, use 'cihelp' to get vanguard attention
[11:07] <didrocks> asac: ? upstream merger doesn't use ppa apart from daliy-build one?
[11:07] <didrocks> asac: it's using a local repo from what I know
[11:07] <didrocks> not sure what ppas you are refering to :)
[11:07] <cjwatson> I would hope that the upstream merger is using a clean chroot each time, rather than relying on purging
[11:08] <asac> didrocks: hmmm.... good point :)
[11:08] <didrocks> cjwatson: from what I know it's a clean chroot + a local repo + daily-build ppa
[11:08] <didrocks> (local repo being mostly "per stack")
[11:09] <ogra_> asac, hey, happy jetlag :)
[11:09] <asac> didrocks: so guess we would still need something like proposed-purge as we would basically have to do one run of installing all deps that might come from proposed
[11:10] <asac> ogra_: thx. I really think it's over now :)
[11:10] <ogra_> heh
[11:10] <xnox> asac: why? cu2d is running with -proposed enabled, and so should the upstream merger.
[11:10] <asac> well, to a bearable degree
[11:10] <asac> xnox: its different :)
[11:10] <ogra_> didrocks, did you file a bug against friends ? else i'll do
[11:10] <didrocks> ogra_: I didn't, please feel free :)
[11:10] <asac> xnox: a) yues, we should install the depends from proposed for testing in upstream merger
[11:10] <ogra_> will do then
[11:10] <didrocks> ogra_: assign robru to it, I guess he was the one to release it
[11:11] <ogra_> ok
[11:11] <xnox> asac: .... but without inheritting all other uninstallables... true.
[11:11] <asac> xnox: b) no, its not very simple
[11:11] <asac> :)
[11:11] <asac> xnox: right. we want exactly all the depends and nothing else (as that might be broken and what not)
[11:12] <asac> xnox: and since we dont reflash devices, we need a reliable way to get back to the current clean archive/image :)
[11:12]  * didrocks doesn't understand the "we want the depends thing", that's how sbuild is working: installing only the build-deps from what we want to build
[11:12] <asac> i relaly think a feature in ppa-purge to disable proposed would be helpful
[11:13] <asac> didrocks: installing is simple, yes. but we need to uninstall those things as we dont have the time to reflash devices for every run
[11:13] <didrocks> I guess it's more in the new infra world "we want to freeze the deps" (but still be able to test against latest)
[11:13] <asac> uninstall -> revert
[11:13] <didrocks> asac: ah, on the device, avoiding reflashing?
[11:13] <asac> didrocks: in the new world thats an additional feature, yes
[11:13] <didrocks> not related to upstream merger, it doesn't build on the device
[11:13] <asac> didrocks: upstream merger doesnt reflash so it can keep up with the big amount of merge proposals coming in
[11:13] <didrocks> but yeah, I think we should "just" remove the delta rw part
[11:14] <asac> right
[11:14] <asac> so i think:
[11:14] <asac> 1. devices get auto flashed if a new proposed (or released?) image is available
[11:14] <asac> 2. we add proposed into /etc/apt/sources.lists.d/
[11:14] <asac> 3. install stuff from sbuild with proposed deps
[11:14] <asac> 4. test
[11:15] <asac> 5. ppa-purge --proposed  :)
[11:15] <ogra_> asac, how do you make sure to not accidentially get other deps pulled in from proposed ?
[11:15] <didrocks> well, I think 5 is more reset-to-vanilla-image
[11:15] <didrocks> which remove the rw part
[11:15] <asac> ogra_: well, we get all the depends from what we work on... which is sane i think
[11:15] <ogra_> you need a per -ackage copy mechanism, not enable proposed altogether
[11:15] <asac> ogra_: we dont run apt-get dist-upgrade
[11:15] <asac> or upgrade
[11:15] <asac> just apt-get update
[11:15] <ogra_> but apt-get install
[11:16] <asac> apt-get install mycipackage
[11:16] <asac> ogra_: that will pull in all the deps
[11:16] <asac> afaict
[11:16] <asac> but nothing else... e.g. exactly what we want
[11:16] <asac> or very close at least :P ... no?
[11:16] <ogra_> well, i would find it safer to have them copied into a PPA first
[11:17] <asac> i dont think that adds safety unless we dont want to install all dependcs that are dangling in proposed
[11:18]  * ogra_ would also not apt-get install but build a complete image from the PPA ...
[11:18] <asac> assuming that ppa-purge --proposed does the right thing
[11:18] <ogra_> making the image writable might taint your results
[11:18] <asac> ogra_: read backlog :)
[11:18] <asac> ogra_: we dont have the luxury to install complete images
[11:18] <asac> ogra_: yeah. wauit
[11:18] <ogra_> why not ?
[11:18] <asac> ogra_: so later we SHOULD indeed have the image delat produced and use system image updates
[11:19] <ogra_> build an image with the change, flash the device/emulator with it, run the tests
[11:19] <asac> but right now we dont have all of that in upstream merger code
[11:19] <asac> ogra_: flashing on device takes too long for upstream merger
[11:19] <asac> ogra_: too many merge requests
[11:19] <cjwatson> TBH, this is a problem you have regardless of whether -proposed is involved; -proposed exacerbates it but that's all
[11:19] <asac> cjwatson: right.
[11:20] <cjwatson> Consider the case of one stack that introduces a new dependency, and another stack with an unstated reliance on that new dependency
[11:20] <cjwatson> If you aren't arranging for a clean environment then the latter will pass tests when it shouldn't
[11:20] <cjwatson> So you shouldn't think of this as something specific to -proposed
[11:20] <asac> cjwatson: i am not :)
[11:20] <cjwatson> Good :)
[11:21] <ogra_> testing with apt-get'ed packages on a rw image isnt really getting you the same results i think ... that was the point i was making ... independently of where the packages come from
[11:21] <asac> cjwatson: i was just explaining that we would something like ppa-purge --proposed feature if we wanted to apply the concept used in upstream merger currently
[11:21] <asac> ogra_: thats a separate problem
[11:21] <didrocks> ogra_: this won't be the case in the "new CI world"
[11:22] <asac> ogra_: yes, we will produce more images and we can then use the image delta and system image approach
[11:22] <cjwatson> Sure, and I'm just saying that option name would either be misdescribing what the code does, or not really solving the problem :)
[11:22] <asac> would require a system image revert feature though if we dont want to reflash all :)
[11:23] <ogra_> revert feature ?
[11:23] <cjwatson> Similar problem for autopilot testing in general
[11:23] <ogra_> yes
[11:24] <ogra_> in any case we need the emulator first ...
[11:25] <ogra_> and the thing we have doesnt seem to be suiting our needs as it is ... i guess getting this into shape to even be remotely usable will still take quite some time
[11:25] <asac> ogra_: what do you mean?
[11:25] <asac> upstream merger?
[11:25] <ogra_> asac, emulator
[11:26] <ogra_> to get more test facilities that arent HW bound
[11:26] <asac> xnox has a short term problem that he cannot merge due to upstream merger not pulling in proposed bits.
[11:26] <asac> :)
[11:26] <ogra_> yes, i know, i was more referring to the general part of oour conversation :)
[11:27] <asac> hehe
[11:27] <asac> right. all the funky bits are blocked on emulator
[11:27] <ogra_> right
[11:27] <asac> and the ability to produce many images from everywhere :)
[11:27] <ogra_> that one we'll have with LP buildds
[11:31] <asac> yeah. thats the hope. I don't think we have super sharp plans on that aspect though. e.g. we also have to invest in our image tooling so it can be effectively run in such a scalable env.
[11:31] <asac> etc.
[11:33] <asac> anyway, didrocks pulling through CI team for the featutes needed to get to his vision will ensure that we get there - once we have the emulator :)
[11:33]  * asac stops distracting channel
[11:36] <ogra_> right, but that "one we have" is imho in a far future ... at least regarding the current emulator we have ... the hardware it emulates is very far from our minimal specs
[11:36] <ogra_> s/one/once/
[11:38] <psivaa> didrocks: ogra_: almost done with image 11 and friends-service is the one that's causing the pass rate to be lower than image 10
[11:38] <ogra_> yeah
[11:38] <psivaa> both gallery and friends app tests fail systemsettle after for friends server taking up processor resource
[11:39] <ogra_> yup, as discovered in the meeting ... they either need to re-upload a rolled back version or a proper fix before we do a new image buuld
[11:40] <ogra_> it is very intresting that it oly affects mako though
[11:41] <cjwatson> FWIW I got the slave side of livefs-in-LP done over the weekend (pending review)
[11:41] <ogra_> oh
[11:41] <ogra_>  [ Robert Bruce Park ]
[11:41] <ogra_>   * Save battery life by decreasing default polling frequency. (LP:
[11:41] <ogra_>     #1238083)
[11:42] <ogra_> i would guess that is what bites us
[11:42] <ogra_> bug 1238083
[11:42] <cjwatson> Bug 1247461 is tracking this work now
[11:42]  * ogra_ subscribes
[11:42] <didrocks> psivaa: ok, nice to know what's the cause :)
[11:43] <didrocks> psivaa: we'll need to talk with robru/ken I guess
[11:43] <psivaa> didrocks: ack
[11:43] <didrocks> psivaa: the regression we saw on maguro is as well due to it?
[11:44] <psivaa> didrocks: ogra_ yes, only in one attempt it's unity8 that's causing and the rest it's friends-service
[11:44] <psivaa> http://<IP_ADDRESS>:8080/job/trusty-touch-maguro-smoke-friends-app-autopilot/13/artifact/clientlogs/top_after.log/*view*/
[11:46] <psivaa> also i logged into the device and it's friends that's at the top
[11:46] <didrocks> psivaa: ok, nice to know that all those regressions are due to one and only one component :)
[11:46] <didrocks> psivaa: is there a way for you to downgrade the version of friends in one device and restart those tests?
[11:47] <psivaa> didrocks: was about to try that :)
[11:47] <didrocks> great ;)
[11:48] <ogra_> didrocks, psivaa asac bug 1248143
[11:48] <ogra_> (pleas someone confirm :) )
[11:48] <psivaa> will do
[11:49] <ogra_> thx
[12:01] <psivaa> didrocks: confirmed that with the older version the issue does not occur: https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/job/trusty-touch-maguro-smoke-friends-app-autopilot/14/
[12:01] <didrocks> psivaa: \o/
[12:01] <didrocks> Mirv: mind you step ahead and revert friends?
[12:02] <didrocks> I guess we have enough elements now
[12:03] <didrocks> thanks for the hunt psivaa :)
[12:03] <psivaa> didrocks: yw, ogra_ found it first :)
[12:04] <ogra_> thanks for verifying !
[12:04] <ogra_> :)
[12:04] <psivaa> :)
[12:05] <didrocks> ogra_: sharing the congrats of finding the guilty component ;)
[12:11] <Mirv> didrocks: is that lp:friends revert to previous release, rebuild, and release?
[12:12] <Mirv> some decrease of polling frequency is the only non-test change there
[12:12]  * Mirv notes that ogra quoted that commit in particular
[12:13] <Mirv> ok then, understanding enough, reverting that one commit
[12:15] <Mirv> didrocks: before I forget what I was doing before that, can you check process-cpp from platform stack is whitelisted for publishing?
[12:15] <Mirv> we finally got it working
[12:15] <didrocks> Mirv: excellent! checking :)
[12:15] <ogra_> right, seems to be just a gconf key change after all
[12:16] <didrocks> Mirv: yeah, whitelisted
[12:16] <Mirv> didrocks: thanks
[12:16] <didrocks> yw
[12:18] <didrocks> sil2100: did you get in saucy download-manager?
[12:19] <sil2100> didrocks: it's in the unapproved queue
[12:19] <didrocks> sil2100: did you poke the SRU team? It needs to be in quickly as there is the 7 days period and we need to kick an image after that
[12:21] <sil2100> Didn't get an aswer yesterday, but I'll poke people directly today :)
[12:21] <didrocks> sil2100: thanks!
[12:30] <Mirv> didrocks: process-cpp in NEW queue
[12:30] <didrocks> Mirv: checking
[12:32] <didrocks> include/posix/linux/proc/process/state.h: LGPL (v3)
[12:32] <didrocks>   [Copyright: 2012-2013 Canonical Ltd]
[12:32] <didrocks> (mutliple of them)
[12:32] <didrocks> when debian/copyright states only 2013
[12:32] <didrocks> nitpicking, not important, but just FYI Mirv $
[12:32] <didrocks> ^
[12:34] <didrocks> -doc should suggests the -dev IMHO (but again, not that important)
[12:34] <didrocks> and the long description is quite short…
[12:36] <didrocks> Mirv: otherwise sounds good (didn't change that much since my first checking and pass/reject). Can you make tvoss aware of those for a future fix? ^
[12:36] <didrocks> (accepted)
[12:38] <Mirv> didrocks: ok, I'll let him know.
[12:38] <Mirv> or better yet, make a quick branch
[12:39] <didrocks> thanks ;)
[13:43] <sil2100> didrocks: what to do in case when I get test failures for calendar-app? The trunk calendar-app has much more tests than the one on the image, but still it's a solid 4-reproducible-failures
[13:43] <sil2100> didrocks: (bug filled)
[13:43] <didrocks> sil2100: ok, please ping upstream as well, but there is no regression, right?
[13:44] <sil2100> didrocks: I guess not, those tests are new as far as I see (will double check)
[13:44] <didrocks> sil2100: ok, I think it's okish to push then
[13:46] <sil2100> didrocks: ok, as for pushing... how do we actually 'release' click packages ;p?
[13:46] <didrocks> sil2100: it's click only? I think just ping sergio
[13:47] <didrocks> sil2100: how did you test it then? from the ppa?
[13:47] <didrocks> (it overrides the click ones?)
[13:49] <sil2100> didrocks: popey gave us instruction on how to test it ;)
[13:49] <didrocks> sil2100: oh, do you have a link?
[13:50] <sil2100> didrocks: the click packages are being built on jenkins, so you download them from there, reconfigure and test
[13:50] <sil2100> Yes, let me fetch it
[13:50] <sil2100> http://<IP_ADDRESS>:8080/view/click/?
[13:50] <sil2100> We wouldn't know if not for popey ;p
[13:50] <didrocks> sil2100: ah ok, sorry, I thought those were with daily releases
[13:50] <didrocks> sil2100: so, that's why I gave them to you
[13:51] <sil2100> No, those are click-only core-apps
[14:00] <Mirv> didrocks: sil2100: how do I get the removed packages back to the PPA? each of the removed ones seem to be in a state that 'build' jobs consider them building but they're not there in daily-build PPA and the build jobs get stalled. I tried force rebuild already (with qtubuntu)
[14:01] <cjwatson> you can copy a removed package back in (with binaries) as long as you haven't later done something that the copy would conflict with
[14:02] <Mirv> cjwatson: the PPA packages were removed for reason (mir transition that was wanted), I'm wondering why the dput the cu2d should be doing doesn't seem to be working
[14:02] <Mirv> not wanted
[14:03] <Mirv> now that the rebuilds are tried
[14:06] <cjwatson> cu2d does a copy rather than a dput, I'd have thought.  But anyway, what package name and version number is this?
[14:09] <fginther> morning
[14:16] <Mirv> cjwatson: I'm talking about cu2d -> PPA, not PPA -> archive
[14:17] <Mirv> didrocks: sil2100: anyway, feel free to fix if you find out what's the problem.
[14:18] <cjwatson> Mirv: OK; still happy to dig out the failure reason from logs if I know what I'm looking for (package name, version number)
[14:21] <Mirv> cjwatson: ok I think I'm now seeing the problem already without checking the logs, it's trying to upload a package with the version number
[14:21] <Mirv> the same version number as previous
[14:21] <Mirv> didrocks: sil2100: so next step, if you can think of why force rebuild does not increment the number, feel free to fix.. otherwise I guess the first build of tomorrow will work for all
[14:22] <Mirv> I'll cancel platform, services, indicators ongoing runs now
[14:22] <sil2100> Ok, I'll backtrack the discussion in a moment
[14:23] <cjwatson> Mirv: that would certainly do it
[14:25] <didrocks> Mirv: interesting, do you have logs with FORCE_REBUILD not incrementing numbers?
[14:25] <Mirv> didrocks: http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/Platform/job/cu2d-platform-head-1.1prepare-qtubuntu/472/console
[14:28] <didrocks> Mirv: IIRC, ppas were taking back the same version if the previous one was removed, didn't they?
[14:29] <didrocks> https://launchpad.net/~ubuntu-unity/+archive/daily-build/+builds?build_text=qtubuntu&build_state=all I don't see the reupload of  0.52+14.04.20131105-0ubuntu1, did we got an email with the reject?
[14:29]  * didrocks didn't see one in mails
[14:29] <cjwatson> didrocks: no, you can't reupload the same version
[14:29] <cjwatson> even if the previous one was removed
[14:30] <didrocks> interesting, I should have dream that ppa was enabling that now
[14:30] <cjwatson> it's possible to *copy* the previous one back in if that's necessary
[14:30] <didrocks> well, I need to fix cu2d to even considered deleted version then
[14:30] <cjwatson> and you can upload an older version after a removal, I believe
[14:30] <cjwatson> but I don't expect we'll ever consider it desirable to reupload the same version
[14:31] <didrocks> cjwatson: no worry, I juts thought that was now handled on the LP side, I'll just add the logic to consider those versions
[14:36] <didrocks> cjwatson: I'm using dest.getPublishedSources(status="Published", exact_match=True, …), is there a way to get Published or Deleted with the same query for instance? (I was reluctant, maybe for no good reason on looping on all sources disregarding their state)
[14:37] <cjwatson> Sadly not, bug 845486
[14:39] <didrocks> cjwatson: ok, so you would suggest I should just disregard the status (and have more api calls then when looping over all sources), and just take the highest version?
[14:40] <cjwatson> You should have some arrangement to avoid iterating over the entire collection, probably
[14:40] <didrocks> what do you mean?
[14:40] <didrocks> actually, I'm just interested in "getting the higher version that ever existed for that source in this ppa"
[14:40] <didrocks> highest*
[14:41] <cjwatson> Do you actually need to walk over all publications?  You should generally get the most recent first
[14:41] <didrocks> generally == ensured? ;)
[14:41] <cjwatson> Well, it's always most recent first; that's guaranteed to be highest version first AS LONG AS people aren't playing tricks to wind versions backward
[14:42] <didrocks> ok, so, in that case, even the removed version (which is the highest) will be the first one?
[14:42] <cjwatson> If I understand things correctly then yes
[14:43] <cjwatson> You get them in reverse order of publication
[14:43] <cjwatson> If that's what you need then you can avoid the full traversal
[14:43] <didrocks> ok, making sense. I can just try relying on that without looping over
[14:43] <cjwatson> If it's not then you probably just have to walk everything
[14:43] <didrocks> thanks cjwatson
[14:43] <cjwatson> Oh, in fact, it's better than that
[14:43] <cjwatson> if version is not None:
[14:44] <cjwatson>     ...
[14:44] <cjwatson> else:
[14:44] <cjwatson>     orderBy.insert(1, Desc(SourcePackageRelease.version))
[14:44] <cjwatson> So you get them in descending version order
[14:45] <didrocks> nice! I'll definitively use that
[14:45] <cjwatson> The full ordering will be by source package name, then by descending version, then by id (~= most recent first)
[14:52] <didrocks> Mirv: around?
[14:54] <sil2100> cu2d updated? :)
[14:54] <didrocks> yep, I'm trying with that on qtubuntu right now
[14:55] <didrocks> at least, we now see it:
[14:55] <didrocks> 2013-11-05 14:54:14,731 INFO A version in the ppa (0.52+14.04.20131105-0ubuntu1) is higher than the proposed version in bzr (0.52+13.10.20131016-0ubuntu1) (previous tests/builds failing?). Basing on that one.
[14:55] <didrocks> Uploading to ppa (via ftp to ppa.launchpad.net):
[14:55] <didrocks>   Uploading qtubuntu_0.52+14.04.20131105.1-0ubuntu1.dsc: done.
[14:55] <didrocks> ok, seems to be fine :)
[14:55] <didrocks> Mirv: not sure what you wanted to rebuild, but qtubuntu is done and cu2d now supports it
[14:55] <didrocks> (with the tests updated as well)
[14:56] <sil2100> I guess he wanted to rebuild it against the old mir, I think?
[14:56]  * sil2100 isn't sure
[14:56] <didrocks> sil2100: I think so
[14:56] <didrocks> qtubuntu in rebuild anyway
[14:56] <sil2100> But as long as it's possible now, then good! Since this was also blocking ubuntu-keyboard sadly ;)
[14:56] <didrocks> sil2100: you can relaunch then :)
[14:56] <sil2100> \o/ Thanks! Can I use jenkins UI?
[14:57] <didrocks> sure
[14:58] <sil2100> FORCE_REBUILD is required, or without it will work as well?
[14:58] <didrocks> sil2100: if there is no diff with distro, FORCE_REBUILD is required
[15:21] <didrocks> sil2100: any news on the other apps, apart from ubuntu-ui-toolkit, gallery-app, ubuntu-keyboard, unity8 are under progress?
[15:22] <sil2100> didrocks: I'll take care of notes-app in the meantime if you don't mind, it wasn't on the list but I guess those will be done when 'ready'
[15:23] <didrocks> sil2100: notes-app is a click app, isn't it?
[15:23] <sil2100> didrocks: we have it in cu2d, so I don't know?
[15:23] <sil2100> I was never entirely sure about the status of that one
[15:23] <didrocks> sil2100: ok, please release it anyway, just in case
[15:24] <didrocks> I think some are both in the archive and in click
[15:24] <didrocks> not sure why sergio kept them like that
[15:42] <Mirv> didrocks: I can rebuild the rest. do we have a team meeting / telco in 18min? as seb128 e-mailed today, the UTC time should not be change so in winter time now it'd be 1h "earlier"
[15:44] <Mirv> and they're having their half of the meeting at the moment
[15:57] <sil2100> hm, I think ours is scheduled for like in an hour still, didn't see any mention of us using the old time
[15:58] <seb128> sil2100, we decided previous cycle to used a fixed UTC time, that should apply to your half of the meeting as well
[15:58] <seb128> didrocks doesn't seem to be around though
[15:58] <sil2100> Indeed
[16:02] <Mirv> sil2100: we don't have "ours" scheduled in calendar, since it has been lately replaced by the CI call. but on the other hand I don't know whether it makes sense for me to join the evening call once a week if it hasn't got anything to do with what used to be team chats before.
[16:04] <Mirv> I mean I can of course, but that's again 12h after I started my day
[16:04] <didrocks> seb128: in a hangout
[16:04] <sil2100> Mirv: I consider that as 'ours', since this basically replaced our weekly meetings
[16:05] <sil2100> As we didn't have a normal weekly meeting since this was scheduled
[16:06] <didrocks> ogra_: cyphermox: sil2100: robru: kenvandine: cyphermox: ready to have the meeting now?
[16:06] <sil2100> Mirv: the timing is not too good for you I guess indeed anyway
[16:06] <ogra_> didrocks, no
[16:06] <cyphermox> didrocks: I'm in the phonedations one
[16:06] <ogra_> didrocks, i always have another meeting at this time
[16:07] <didrocks> ok, 2 people not available, let's postpone in one hour?
[16:07] <ogra_> (same as cypher)
[16:07] <sil2100> Mirv: ^
[16:07] <kenvandine> sure
[16:07] <Mirv> sil2100: I've no problem with that as such, I just guess the Tuesday telco is no different from other days, so it's not as much of a "weekly"
[16:07] <didrocks> sorry Mirv :)
[16:07] <sil2100> ;)
[16:08] <sil2100> didrocks: publishing notes-app and gallery-app now - there are 2 gallery-app failures, but those do not happen on my local device, I had all green
[16:09] <Mirv> didrocks: no problem. I'm just interested in clarification that indeed once a week we have this one telco that we invite everyone to, while on other days just those who are around at that time normally?
[16:09] <didrocks> sil2100: great!
[16:10] <didrocks> Mirv: exactly my thoughts
[16:10] <sil2100> didrocks: packaging ACK needed! http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/Apps/job/cu2d-apps-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_notes-app_1.4+14.04.20131104.2-0ubuntu1.diff <- seems like migration of the naming parts to be more click-click
[16:10]  * Mirv snoozes alarm for 50mins
[16:10] <didrocks> sil2100: hum, is the .mo picked up then?
[16:10] <didrocks> and no more binary?
[16:10] <didrocks> thanks Mirv
[16:11] <sil2100> didrocks: no binary, the desktop file opens qmlscene directly
[16:12] <didrocks> sil2100: is it already translated, did you check that the translation are loaded up?
[16:13] <sil2100> Let me change the locale and check, one moment
[16:18] <sil2100> didrocks: the app is translated, so I guess all works ok?
[16:20] <didrocks> sil2100: +1 then :)
[16:20] <didrocks> sil2100: you started them from the package? how were you sure? ;)
[16:21] <sil2100> I'm not! But I checked that notes-app installed the .desktop file, and unity8 uses desktop files for launching the app, so I think I ran the right thing ;p
[16:22] <didrocks> sil2100: ok, trusting you, it's all fuzzyness for me TBH ;)
[16:23] <sil2100> Same here, I want some docs for this!
[16:23] <didrocks> sil2100: do you think you'll have time for doing ubuntu-keyboard and unity8 before the meeting?
[16:23] <didrocks> sil2100: +1000
[16:23] <didrocks> I guess lool has the best understanding, maybe he can help
[16:23] <sil2100> didrocks: doing ubuntu-keyboard now, will try finishing unity8 too
[16:23] <didrocks> thanks
[16:24] <lool> didrocks, sil2100: Actually this should just be covered in https://wiki.ubuntu.com/Touch/Testing#Testing_your_Ubuntu_Touch_Code_before_submission
[16:24] <lool> see Running Click tests
[16:27] <didrocks> lool: but if we install a .deb for testing for a click package
[16:27] <didrocks> like this notes-app
[16:27] <didrocks> when we have both
[16:27] <didrocks> clicking on unity8 to start it
[16:27] <didrocks> will it starts the click version
[16:27] <didrocks> or the debs one?
[16:36] <sil2100> didrocks: there is an extrapackage issue for unity8 on cu2d, but I won't be wasting time to fix that now as I anyway run the unity8 AP tests on my phone if you don't mind
[16:36] <lool> didrocks: I dont know!
[16:37] <lool> didrocks: but it seems a bad idea to have both
[16:37] <didrocks> sil2100: sure
[16:37] <lool> didrocks: it's not a real life use case to have both .deb and .click (it might be when desktop converges though  :-/)
[16:37] <didrocks> lool: well, I agree, but it seems that we want to have .debs and click for some cases
[16:37] <didrocks> lool: and we need to know how to test both then
[16:37] <didrocks> lool: can you clarify this up with sergio? I'm all for dropping the .debs if we can
[16:37] <lool> didrocks: Maybe we want to add a mode to force usage of this or that set of tests from phablet-test-run
[16:38] <lool> e.g. phablet-test-run --click-only, and --deb-only
[16:38] <lool> which would mangle sys.path in the right way
[16:38] <lool> Hmm no Sergio here
[16:38] <didrocks> lool: that would be enough to me :)
[16:38] <lool> didrocks: I'm about to step out, but I will followup with Sergio either over email or on Thursday
[16:39] <didrocks> lool: thanks
[16:47] <tedg> This branch didn't get a Jenkins review.  I'm not sure why: https://code.launchpad.net/~marcustomlinson/libdbusmenu-qt/virtual_base_destructors/+merge/193879
[16:56] <tedg> doanac, Do you know how I can figure out what's up? ^
[16:56] <doanac> tedg: i'm investigating with fginther right now
[16:56] <fginther> tedg, the owner of the MP wasn't on the whitelist, that's been fixed
[16:57] <tedg> Ah, okay.  I thought all ~canonical was on the whitelist?
[16:57] <sil2100> didrocks: unity8 tests still running sadly, had a device reset inbetween strangely
[16:58] <didrocks> sil2100: no worry, keyboard is good?
[16:59] <sil2100> didrocks: been dogfooding it, looked good but wanted to see unity8 tests if those are ok with it
[17:00] <sil2100> didrocks: we doing the meeting in a hangout?
[17:00] <sil2100> Or IRC?
[17:00] <didrocks> sil2100: hangout
[17:00] <didrocks> kenvandine: cyphermox: joining?
[17:00] <didrocks> plars:  ^
[17:06] <cyphermox> es
[17:06] <cyphermox> yes
[17:06] <sil2100> didrocks: unity8 is GREEN, so ubuntu-keyboard as well
[17:06] <sil2100> didrocks: can I publish?
[17:10] <sil2100> didrocks: http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/Services/job/cu2d-services-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-keyboard_0.99.trunk.phablet2+14.04.20131105.1-0ubuntu1.diff <- packaging change, but still browsing through it - the changes seem ok, although I need to dig in deeper to understand some changes
[17:16] <sil2100> didrocks: seems ok, there is one line in copyright that I don't understand (the first +"License: LGPL-3" under Format:)
[17:19] <ogra_> kenvandine, robru i'll be around ofr at least another 2h (probably even 4) if you want the image triggered ...
[17:19] <didrocks> sil2100: general license of the package, not really useful, but not harmful
[17:19] <didrocks> sil2100: +1 then
[17:19] <kenvandine> ogra_, thx
[17:19] <robru> ogra_, ok, will let you know
[17:20] <sil2100> ACK :)
[17:25] <didrocks> robru: kenvandine: cyphermox: resent the instructions by email
[17:25] <didrocks> hope they all make sense :)
[17:26] <robru> didrocks, ok, thanks
[17:26] <didrocks> yw!
[17:26] <cyphermox> ok
[17:45] <Mirv> phew, ok now really gone again. I may have had click intervening the ui toolkit results, but the sdk team is meanwhile investigating the maguro failures they have (without any click-setup) and robru is testing ui-tk + apps on his maguro.
[17:46] <Mirv> complex
[17:46] <Mirv> bug #1248264 is for the UITK probs
[19:10] <robru> ogra_, still around? i'll be releasing ubuntu-ui-toolkit soon if you want to kick a build in 30 mins or so?
[19:13] <kenvandine> robru, it might take longer than that for it to make it to the release pocket
[19:13] <robru> oh, right
[19:13] <robru> it'll just be in proposed. ugh
[19:15] <ogra_> yeah, so in ~1h or so then
[19:15] <ogra_> no prob :)
[19:18] <robru> ogra_, ok, great, just finished the publish job
[19:19] <ogra_> k
[19:32] <robru> kenvandine, cyphermox, thomi_, Mirv, can somebody confirm that this is the correct way of enabling ap 1.4 in qa stack? https://code.launchpad.net/~robru/cupstream2distro-config/autopilot-1.4/+merge/193994
[19:33] <thomi_> robru: I *think* that's correct, but I'm not the right person to ask really
[19:33] <thomi_> robru: will you let us know when we can start merging 1.4 branches to trunk?
[19:33] <kenvandine> robru, so the 1.4 branches merged into trunk?
[19:33] <robru> thomi, it will be really soon that you can start those merges.
[19:33] <kenvandine> thomi, i guess once we get the qa stack built
[19:34] <thomi> robru: sweet! \o/
[19:34] <thomi> kenvandine: cool
[19:34] <robru> thomi, maybe 30 minutes
[19:35] <robru> thomi, i guess my question is "trunk means 1.4, right?"
[19:36] <kenvandine> robru, approved
[19:36] <robru> kenvandine, oh, i realized that target_branch was redundant, please re-review
[19:37] <kenvandine> oh right... good catch
[19:39] <robru> kenvandine, cyphermox: ok, i kicked the build
[19:39] <robru> kenvandine, cyphermox: I guess we need to publish qa stack before thomi's team can start landing branches?
[19:39] <robru> or is the PPA enough?
[19:39] <kenvandine> PPA should be enough
[19:39] <kenvandine> right thomi?
[19:40] <kenvandine> robru, remember to check the prepare logs on the build
[19:40] <kenvandine> make sure there isn't merge problems
[19:40] <thomi> kenvandine: robru: I think the idea was to get a clean image published with 1.3, then do one with 1.4
[19:40] <thomi> I'm not sure I understand the question though
[19:40] <thomi> so...
[19:40] <thomi> :)
[19:41] <kenvandine> i'd suspect the prepare will have problems since we switched branches
[19:41] <kenvandine> thomi, yeah... cu2d will build the qa packages into the daily ppa
[19:41] <kenvandine> then you can start working on getting all the other branches merged building against that
[19:41] <robru> thomi, ok, but I mean like, lp:autopilot trunk contains v1.4. there's not some separate 1.4 branch somewhere, right?
[19:43] <thomi> robru: that's correct. trunks (for the four AP-related projects) are all 1.4
[19:43] <thomi> 1.3 lives in a separate series
[19:43] <robru> thomi, ok, perfect. so we're building those in the PPA now. after ogra builds an image we can land them in distro.
[19:43] <thomi> robru: so the MP you linked above should work
[19:43] <thomi> cool
[19:43] <thomi> robru: well, so once they're in the PPA, we need to merge all the 1.4 changes to the various projects
[19:43] <thomi> then ogra can build an image :)
[19:44] <thomi> so... let us know when we can start merging :)
[19:44] <robru> thomi, well, we still need an image pre-1.4 i think
[19:44] <robru> thomi, do you need autopilot 1.4 in distro or just in PPA?
[19:44] <thomi> robru: ahh, yes. understood
[19:45] <thomi> robru: ultimately in the distro. what happens while we merge is up to you guys I guess, as long as it's used in the upstream-merger job runs
[19:45] <robru> fginther, do you know if autopilot gets pulled from the daily-build ppa during CI, or does it have to be in distro for that?
[19:45] <fginther> robru, most jobs use the daily-build ppa
[19:46] <robru> fginther, but i mean specifically for the autopilot packages too? or just whatever package is being built?
[19:48] <fginther> robru, sorry, I'm not following. Are you talking about an $app-autopilot package?
[19:49] <fginther> like galler-app-autopilot?
[19:49] <fginther> like gallerr-app-autopilot?
[19:49] <fginther> like gallery-app-autopilot?
[19:54] <robru> fginther, sorry
[19:55] <robru> fginther, I mean, if I propose a branch against lp:gallery-app, and it runs the autopilot test, will it install autopilot itself from the PPA, or does it get autopilot from distro?
[19:57] <thomi> Hey guys - we have good reason to believe that the python-autopilot package in the daily-build-next ppa is borked
[19:57] <thomi> it seems to be version ed 1.4.X, but is built from the 1.3 sources.... which is odd
[19:58] <thomi> robru: any ideas?
[19:59] <fginther> robru, gallery-app is backed by the daily-build ppa so it would resolve dependencies from there
[19:59] <robru> thomi, stop using daily-build-next? that's only used during final release freeze before ubuntu+1 opens. trusty is open now, so please use daily-build ppa instead
[19:59] <robru> fginther, ok, thanks
[20:00] <fginther> robru, all projects should be building against the daily-build ppa (there may be 1 or 2 exceptions)
[20:00] <fginther> thomi, I'm trying to understand the problem
[20:01] <fginther> thomi, are you referring to this? http://<IP_ADDRESS>:8080/job/autopilot-testrunner-otto-trusty/434
[20:01] <robru> thomi, ok, it looks like autopilot* and xpathselect 1.4 all just landed in the PPA as of 3 minutes ago. I think that should be good enough to get CI working, so please land one branch just to see what happens, and if it works then you can go ahead and land all your AP branches now. let me know of any problems
[20:03] <fginther> thomi, ohhhhhhh
[20:06] <thomi> fginther: robru: ummmm
[20:07] <thomi> fginther: the trusty/ap 1.4 test job you set up for us uses daily-build-next
[20:07] <thomi> fginther: which is causing problems for us
[20:07] <thomi> robru: I'll try an experimental merge now
[20:08] <robru> fginther, hm, yeah, shouldn't be -next anymore I don't think?
[20:08] <robru> unless we're starting on ubuntu 14.10 already ;-)
[20:09] <fginther> thomi, it's using ppa:ubuntu-unity/daily-build
[20:10] <thomi> fginther: ugh, sorry - yes
[20:10] <fginther> whew
[20:10] <thomi> fginther: I still think that AP package is busted though
[20:10] <fginther> thomi, I did see the version mismatch thing
[20:10] <ogra_> [20:10] <thomi> yeah
[20:10] <davmor2> ogra_: woop woop! \o/
[20:10] <thomi> fginther: /var/local/autopilot/autopilot.log: 19:47:16.560 INFO autopilot:141 - Autopilot Source Version: 1.3.1
[20:11] <thomi> fginther: sure;y that's wrong?
[20:11] <robru> cyphermox, can you confirm this change? you did a manual upload that is confusing jenkins. https://code.launchpad.net/~robru/autopilot/fix-changelog/+merge/194002
[20:12] <cyphermox> done
[20:12] <robru> thomi, oh, yes, it's possible that autopilot package is wrong. i see in the jenkins job that the changelog has some inconsistencies so the new version didn't build yet
[20:12] <thomi> robru: OK. that would explain the oddities that elopio has seen
[20:12] <thomi> robru: can you please fix and ping me when I should retry?
[20:12] <robru> thomi, that mp ^^ should fix it, once that lands i'll rebuild soon
[20:13] <robru> thomi, ok
[20:13] <thomi> robru: thanks man
[20:13] <robru> thomi, no worries
[20:15] <ogra_> argh !
[20:15] <ogra_> crap
[20:15] <robru> ogra_, what?
[20:15] <ogra_> robru, lillipilly was rebootedm so proposed migration didnt happen
[20:15] <ogra_> i guess we need an image 13 right afterwards ...
[20:15] <robru> ogra_, ok well we are doing all this AP stuff in the PPA so the archive should be safe for an image build whenever you can.
[20:16] <ogra_> yeah
[20:16]  * ogra_ only ran "rmadison -S ubuntu-ui-toolkit|grep proposed" ...
[20:16] <ogra_> but rmadison hasnt been updated either
[20:16] <ogra_> (since it runs on lillipilly too)
[20:17] <ogra_> checking without the grep actuallye revels that it didnt even end up in proposed yet
[20:17] <ogra_> *actually reveals
[20:22] <kenvandine> it's pending in proposed
[20:23] <ogra_> yes, it shouldnt
[20:23] <ogra_> it was copied 1h ago
[20:30] <popey> should #12 be available?
[20:32] <ogra_> popey, yes, but not with the expected new ui toolkit
[20:32] <ogra_> that seems to be stuck entering proposed
[20:40] <robru> ogra_, anything I can do to help ubuntu-ui-toolkit along? need me to republish in jenkins?
[20:41] <ogra_> robru, stgraber is looking into it in #ubuntu-release
 last publisher failed because of missing access to the seeds
 yeah, the publisher looks stuck
[20:42] <ogra_> its an infrastructure issue ...
[20:42] <robru> thomi, ok, i fixed that one issue with the old autopilot version and kicked some new builds. you can watch their progress here: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages?field.name_filter=autopilot&field.status_filter=published once you see some green checkmarks there, then you can try proposing branches again. i gotta head for lunch, will be back in a bit
[20:43] <thomi> ok, thansk
[20:43] <thomi> *thanks
[21:19] <elopio> thomi, I see green checkmarks, I'll rebuild the job.
[21:26] <thomi> elopio: thanks
[21:42] <thomi> fginther: robru: I tried this MP as a test landing: https://code.launchpad.net/~elopio/ubuntu-calculator-app/autopilot-1.4/+merge/192643
[21:43] <thomi> fginther: robru: but it failed... I wonder if you guys could help me figure out what went wrong?
[21:43] <thomi> the error is in here: http://<IP_ADDRESS>:8080/job/generic-mediumtests-trusty/58/console
[21:43] <thomi> "ImportError: No module named ubuntu_calculator_app"
[21:43] <thomi> looks like the test suite was never installed?
[21:43] <fginther> thomi, looking
[21:44] <thomi> thanks
[21:45] <fginther> thomi, ubuntu-calculator-app-autopilot : Depends: libautopilot-qt (>= 1.4) but 1.3+13.10.20130814-0ubuntu1 is to be installed
[21:45] <fginther> now to figure out why
[21:45] <thomi> oh, I missed that
[21:45] <thomi> well, it seems the AP 1.4 stuff hasn't fully landed in the right places yet
[21:45] <fginther> thomi, oh, I know why. need the daily ppa
[21:45] <fginther> one momento
[21:47] <thomi> fginther: apparently unity8 doesn't use the daily PPA either (according to Saviq), so that might be a problem for us down the line as well
[21:47] <robotfuel> I just had this happen in my webbrowser app MP, it's not suppose to be 1.4 WireProtocolVersionMismatch: Wire protocol mismatch at <session bus org.freedesktop.Application /com/canonical/Autopilot/Introspection>: is 1.4, expecting 1.3
[21:48] <robotfuel> https://code.launchpad.net/~chris.gagnon/webbrowser-app/troubleshoot-select-many-noorder/+merge/193988 from this Merge proposal
[21:48] <Saviq> fginther, should we be using the daily ppa in the jobs at all? I thought it's dangerous since things from daily release are built there, even if down the line they're not published, and if another stack gets published, built against daily-build, it might get broken dependencies, at best
[21:49]  * popey updates to 12
[21:49] <thomi> robotfuel: We're landing 1.4 fixes now
[21:49] <thomi> robotfuel: so AP is version 1.4 for everyone
[21:50] <thomi> robotfuel: so maybe merge that branch with the 1.4 compatibility one
[21:50] <thomi> and merge them together
[21:50] <thomi> s/merge/land/
[21:51] <robotfuel> thomi: ack
[21:54] <fginther> Saviq, using the daily ppa is the only way to resolve dependencies that are inflight and must be released together. For example, in this case we need to release autopilot 1.4 and the apps with updates to 1.4 tests at the same time. As a result, we have to use the daily ppa to resolve that dependency
[21:55] <fginther> Saviq, yes, as a result we can end up building a MP with a dependency that is never published.
[21:56] <Saviq> fginther, well, we could push ap 1.4 through to the distro first, and then publish other projects without the need for daily-build PPA
[21:56] <Saviq> fginther, obviously unless there's something preventing ap 1.4 from getting into distro
[21:58] <Saviq> fginther, anyway, if that's an exception, I'm fine with it :)
[22:01] <thomi> fginther: let me know when I can re-approve that MP eh?
[22:03] <robru> thomi, fginther: sorry just got back from lunch
[22:04] <robru> thomi, yeah, looks like autopilot built ok but it looks like there was some issue building autopilot-gtk and autopilot-qt. not sure what. retrying...
[22:05] <fginther> thomi, it's building now
[22:05]  * thomi needs to be more patient
[22:05] <robru> thomi, https://launchpadlibrarian.net/155909983/buildlog_ubuntu-trusty-amd64.autopilot-gtk_1.4%2B14.04.20131105.1-0ubuntu1_FAILEDTOBUILD.txt.gz does this failure mean anything to you?
[22:05] <thomi> robru: yes, it's using autopilot 1.3, instead of 1.4
[22:06] <fginther> Saviq, that's sort of the problem, autopilot couldn't move to the archive until all of it's rdepends have been updated
[22:06] <robru> thomi, hmmm, maybe it's just a staging issue then. 1.4 is in the ppa now so hopefully simply retrying it will fix it
[22:06] <thomi> so either it's not finding the new AP package, or it's using the borked package from this morning
[22:06] <thomi> robru: hopefully
[22:06] <Saviq> fginther, got it
[22:06] <fginther> Saviq, but I think this model is being designed away by didrocks new release model
[22:07] <Saviq> fginther, yeah, it should be better with flight control ;)
[22:07] <fginther> Saviq, AIUI we would only depend on this monster PPAs when necessary
[22:07] <robru> thomi, oh yeah, looking closely it's using 1.4+14.04.20131105 which is the borked one, it really needs 1.4+14.04.20131105.1 to work
[22:07] <fginther> and not for ever MP
[22:08] <elopio> cihelp, what does this mean? "bzr: ERROR: Error parsing trunk.recipe:2:2: Indent not a multiple of two spaces."
[22:08] <elopio> http://<IP_ADDRESS>:8080/job/generic-mediumtests-builder-trusty-armhf/463/console
[22:10] <kenvandine> ogra_, robru:  uitk published in release pocket
[22:11] <fginther> crap ppa-purge failed me
[22:11] <robru> kenvandine, excellent
[22:14] <fginther> thomi, plan b, will try again in a moment
[22:14] <thomi> fginther: ok
[22:14] <fginther> elopio, there are extra spaces in front of the job parameters
[22:15] <elopio> fginther: ah, found it. Thanks.
[22:19] <ogra_> kenyeah, but didnt arrive yet
[22:20] <ogra_> ogra@chromebook:~/Desktop$ rmadison -S ubuntu-ui-toolkit|grep proposed|wc -l
[22:20] <ogra_> 6
[22:20] <ogra_> next publisher run is ours
[22:21] <ogra_> ogra@chromebook:~/Desktop$ rmadison -S ubuntu-ui-toolkit|grep proposed|wc -l
[22:21] <ogra_> 0
[22:21] <ogra_> and there we go :)
[22:22] <fginther> thomi, building again
[22:22] <ogra_> [22:25] <thomi> fginther: ok :)
[22:25] <fginther> thomi, \o/ merged
[22:26] <thomi> I can re-approve that MP?
[22:26] <thomi> oh
[22:26] <thomi> you did it already, I see now
[22:26] <thomi> fginther: sweet
[22:26] <thomi> I'll start approving some others.
[22:27] <thomi> fginther: do you guys have permission to top-approve everything?
[22:27] <thomi> like, are you in some super-team?
[22:28] <fginther> thomi, I happen to be part of lots of teams, but no super team
[22:28] <thomi> hmmm
[22:28] <thomi> some of these MPs I don't have permissions to approve
[22:29] <fginther> thomi, I should
[22:29] <fginther> or balloons
[22:30] <balloons> I can top-approve..
[22:32] <plars> ogra_: 13? 12 is still not done testing even
[22:33] <plars> but things are looking pretty decent so far
[22:35] <robru> plars, yeah, 12 got kicked prematurely, it didn't have the uitk fix we needed. so 13 is what 12 was supposed to be; ignore 12.
[22:36] <robru> thomi, looks like autopilot-gtk build is fixed, so it looks all good on my end. are you having success with your merges now?
[22:36] <thomi> robru: one merged OK, kicked off a few more
[22:37] <robru> thomi, k, great. i'm around for 3 more hours, let me know of any problems you encounter.
[22:38] <thomi> thanks
[23:40] <thomi> robru: what's happening with the friends app MP? I notice you re-approved it...
[23:41] <elopio> cihelp, do we have a hook that installs qtdeclarative5-nemo-qml-plugin-folderlistmodel ?
[23:46] <fginther> elopio, shouldn't that just be a dependency? or do you need the ppa?
[23:46] <fginther> elopio, link to job or mp?
[23:47] <elopio> fginther: here's the failure: http://<IP_ADDRESS>:8080/job/autopilot-testrunner-otto-trusty/444/console
[23:47] <elopio> I suppose I need the ppa.
[23:48] <thomi> fginther: do you have permissions to top-approve this? https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/autopilot-1.4/+merge/192574
[23:48] <fginther> elopio, yep, I think so. you can add it with the hook "D09add_ppa~ubuntu-touch-coreapps-drivers~daily"
[23:48] <elopio> just what I was looking for.
[23:48] <elopio> fginther: ty
[23:49] <fginther> thomi, that's the one team I'm not a member of :-(
[23:49] <thomi> hmmm
[23:49] <fginther> thomi, maybe robru ^ ?
[23:49]  * fginther goes offline for a bit
[23:56] <robru> thomi, sure
[23:57] <thomi> robru: If you can, can you please add me to the relevant team so I can do that myself?
[23:57] <robru> thomi, not sure about the friends merge, the failure log indicated that wait_select_single was missing, I assume that's new API in 1.4, which means that it was just running with 1.3 there. re-approved in the hopes that it'd get 1.4
[23:58] <thomi> robru: your conclusion sounds correct. Are you sure that borked 1.4 package from this morning isn't still hanging around somewhere?
[23:58] <robru> thomi, not sure; was hoping a simple re-approve would flush it out ;-)
[23:59] <robru> thomi, I don't seem to have permissions to add you, but a great team to be in is https://launchpad.net/~ubuntu-unity
[23:59] <thomi> ok
[23:59] <thomi> well, I hope youdon't plan on sleeping in the next 24 hours :)
[23:59] <robru> thomi, that's the super-team that is a member of almost all canonical-run teams, I seem to be able to push directly to trunk on almost any branch ;-)