=== Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [01:07] cihelp [01:07] hey, anyone - seems all maguros are down http://10.97.0.26:8080/job/generic-mediumtests-runner-maguro/ ? [01:07] ah, they're being flashed are they... [01:08] it seems the flash process has failed, then... [01:08] http://10.97.0.26:8080/job/touch-flash-maguro-014E058C18015006/183/console [03:32] 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] doanac, thanks, it might be that the image is completely b0rked or something, if all of them fell down [03:34] doanac: oh hey, can you add to your email that I've modified http://10.97.0.26:8080/job/generic-mediumtests-trusty-touch/ -> I removed generic-mediumtests-runner-maguro from the queue [03:34] veebers: shure [03:34] doanac: awesome thanks [03:46] veebers, so new jobs will pass? [03:46] veebers, or at least ignore maguro? [03:46] Saviq: well, new jobs won't use the maguro runner so will get further [03:46] Saviq: yes :-) [03:46] veebers, that's useful, thanks [03:47] * Saviq cancels all the hanging unity8 jobs [03:47] Saviq: we will either have to kill the current jobs or wait for them to timeout [03:47] Saviq: heh [03:47] veebers, how long the timeout? [03:47] veebers, they've been at it for 10hrs now or something... [03:50] Saviq: ugh right, not sure but 10 hours is too long [03:50] veebers, yeah.... [03:53] 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] doanac, there was talk of a supposedly standard 3.5mm jack contraption for low level access to the hardware [03:56] Saviq: usually i just see devices stuck in the bootloader. ie - i haven't seen to many stuck [03:57] doanac, do they then accept `fastboot reboot` and such? [03:57] Saviq: i normally just do a "fastboot reboot" and it boots [03:57] doanac, right [03:57] note: if its really stuck, a serial console might not be much help either [03:58] you really need to be able to hold the power button down somehow === Ursinha-afk is now known as Ursinha [08:09] FYI I've been doing the needed hoops to transition to libmirserver10 this morning [08:11] 10 already? [08:11] How time flies... [08:39] At least all the FTBFS problems right now seem to be related to the mir transition... [08:43] sil2100: not all [08:48] Right, unity7 and indicators are still real problems === psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - [09:06] sil2100: indicators not, should be hopefully fixed now, but mir unity-system-compositor + unity7 yes [09:06] 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] 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] Mirv: so it wasn't just mir problems in indicators ;) [09:07] Mirv: for unity7 I'm still waiting for updates from bregma [09:09] sil2100: it's not failing because of unity-mir, but because unity-mir FTBFS [09:09] 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] hi didrocks! [09:10] hey Mirv! [09:10] Hi didrocks! [09:10] morning sil2100 :) [09:10] 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] Mirv: Mir was pulled to trunk? [09:10] didrocks: so it'd be the usual deadlock, can't publish, can't rebuild [09:10] Mirv: oh, I see now that unity-mir looks like a 'real' compilation problem, missing/removed include it seems? [09:10] without warning us? [09:11] didrocks: I guess so, new commits in there [09:11] Mirv: please revert trunk [09:11] and remove everything from the ppa that built against it [09:11] Mirv: did you fill in the bugs to "Stack status" ? [09:12] sil2100: yes [09:12] didrocks: ok [09:12] Oh, it might not be needed soon [09:12] didrocks: AIUI thomi_ was travelling yesterday so wasn't online, and won't be until ~20 UTC [09:12] didrocks: I need to somehow find what the trunk used to be before the pull [09:12] popey: ok, thanks :) [09:12] np [09:13] Mirv: you do have that info, right? the changelog + merge back should point to a rev? [09:14] 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] ;/ [09:31] popey: coming? [09:32] ya [09:32] stupid browser [10:50] 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] xnox: you mean about the upstream merger, not daily release, right? [10:51] didrocks: i believe so, yes. Let me get URL. [10:52] https://code.launchpad.net/~xnox/ubuntu-keyboard/libpinyin4/+merge/193859 [10:52] and [10:52] https://jenkins.qa.ubuntu.com/job/ubuntu-keyboard-ci/210/ [10:52] xnox: ok, yeah, upstream-merger: that would be for vila or fginther I guess ^^ (cu2d is using -proposed enabled) [10:59] 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] vila: IIRC, it's indeed not enabled. There were strong argument in both cases [11:00] in practice, enabling -proposed isn't too much troublesome for cu2d, so I guess it won't for upstream merger [11:01] well, clearly needs to be *possible* to enable it at least [11:01] but we still need a way to enable/disable it easily [11:01] yeah [11:02] 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] 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] I did file a bug against ci-services. [11:04] https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1247992 [11:04] Ubuntu bug 1247992 in Ubuntu CI Services "upstream merger builds do not have -proposed enabled" [Undecided,New] [11:05] xnox: perfect [11:06] 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] maybe we need proposed-purge - if that doesnt work :) [11:06] xnox: I'll make sure to ping fginther about it, also, use 'cihelp' to get vanguard attention [11:07] asac: ? upstream merger doesn't use ppa apart from daliy-build one? [11:07] asac: it's using a local repo from what I know [11:07] not sure what ppas you are refering to :) [11:07] I would hope that the upstream merger is using a clean chroot each time, rather than relying on purging [11:08] didrocks: hmmm.... good point :) [11:08] cjwatson: from what I know it's a clean chroot + a local repo + daily-build ppa [11:08] (local repo being mostly "per stack") [11:09] asac, hey, happy jetlag :) [11:09] 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] ogra_: thx. I really think it's over now :) [11:10] heh [11:10] asac: why? cu2d is running with -proposed enabled, and so should the upstream merger. [11:10] well, to a bearable degree [11:10] xnox: its different :) [11:10] didrocks, did you file a bug against friends ? else i'll do [11:10] ogra_: I didn't, please feel free :) [11:10] xnox: a) yues, we should install the depends from proposed for testing in upstream merger [11:10] will do then [11:10] ogra_: assign robru to it, I guess he was the one to release it [11:11] ok [11:11] asac: .... but without inheritting all other uninstallables... true. [11:11] xnox: b) no, its not very simple [11:11] :) [11:11] xnox: right. we want exactly all the depends and nothing else (as that might be broken and what not) [11:12] 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] i relaly think a feature in ppa-purge to disable proposed would be helpful [11:13] 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] 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] uninstall -> revert [11:13] asac: ah, on the device, avoiding reflashing? [11:13] didrocks: in the new world thats an additional feature, yes [11:13] not related to upstream merger, it doesn't build on the device [11:13] didrocks: upstream merger doesnt reflash so it can keep up with the big amount of merge proposals coming in [11:13] but yeah, I think we should "just" remove the delta rw part [11:14] right [11:14] so i think: [11:14] 1. devices get auto flashed if a new proposed (or released?) image is available [11:14] 2. we add proposed into /etc/apt/sources.lists.d/ [11:14] 3. install stuff from sbuild with proposed deps [11:14] 4. test [11:15] 5. ppa-purge --proposed :) [11:15] asac, how do you make sure to not accidentially get other deps pulled in from proposed ? [11:15] well, I think 5 is more reset-to-vanilla-image [11:15] which remove the rw part [11:15] ogra_: well, we get all the depends from what we work on... which is sane i think [11:15] you need a per -ackage copy mechanism, not enable proposed altogether [11:15] ogra_: we dont run apt-get dist-upgrade [11:15] or upgrade [11:15] just apt-get update [11:15] but apt-get install [11:16] apt-get install mycipackage [11:16] ogra_: that will pull in all the deps [11:16] afaict [11:16] but nothing else... e.g. exactly what we want [11:16] or very close at least :P ... no? [11:16] well, i would find it safer to have them copied into a PPA first [11:17] 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] assuming that ppa-purge --proposed does the right thing [11:18] making the image writable might taint your results [11:18] ogra_: read backlog :) [11:18] ogra_: we dont have the luxury to install complete images [11:18] ogra_: yeah. wauit [11:18] why not ? [11:18] ogra_: so later we SHOULD indeed have the image delat produced and use system image updates [11:19] build an image with the change, flash the device/emulator with it, run the tests [11:19] but right now we dont have all of that in upstream merger code [11:19] ogra_: flashing on device takes too long for upstream merger [11:19] ogra_: too many merge requests [11:19] TBH, this is a problem you have regardless of whether -proposed is involved; -proposed exacerbates it but that's all [11:19] cjwatson: right. [11:20] Consider the case of one stack that introduces a new dependency, and another stack with an unstated reliance on that new dependency [11:20] If you aren't arranging for a clean environment then the latter will pass tests when it shouldn't [11:20] So you shouldn't think of this as something specific to -proposed [11:20] cjwatson: i am not :) [11:20] Good :) [11:21] 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] 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] ogra_: thats a separate problem [11:21] ogra_: this won't be the case in the "new CI world" [11:22] ogra_: yes, we will produce more images and we can then use the image delta and system image approach [11:22] 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] would require a system image revert feature though if we dont want to reflash all :) [11:23] revert feature ? [11:23] Similar problem for autopilot testing in general [11:23] yes [11:24] in any case we need the emulator first ... [11:25] 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] ogra_: what do you mean? [11:25] upstream merger? [11:25] asac, emulator [11:26] to get more test facilities that arent HW bound [11:26] xnox has a short term problem that he cannot merge due to upstream merger not pulling in proposed bits. [11:26] :) [11:26] yes, i know, i was more referring to the general part of oour conversation :) [11:27] hehe [11:27] right. all the funky bits are blocked on emulator [11:27] right [11:27] and the ability to produce many images from everywhere :) [11:27] that one we'll have with LP buildds [11:31] 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] etc. [11:33] 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] 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] s/one/once/ [11:38] 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] yeah [11:38] both gallery and friends app tests fail systemsettle after for friends server taking up processor resource [11:39] 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] it is very intresting that it oly affects mako though [11:41] FWIW I got the slave side of livefs-in-LP done over the weekend (pending review) [11:41] oh [11:41] [ Robert Bruce Park ] [11:41] * Save battery life by decreasing default polling frequency. (LP: [11:41] #1238083) [11:42] i would guess that is what bites us [11:42] bug 1238083 [11:42] bug 1238083 in friends (Ubuntu) "friends-dispatcher is a little busy doing data updates on idle systems" [Undecided,Fix released] https://launchpad.net/bugs/1238083 [11:42] Bug 1247461 is tracking this work now [11:42] bug 1247461 in Ubuntu CD Images "Move live filesystem building into Launchpad" [High,Triaged] https://launchpad.net/bugs/1247461 [11:42] * ogra_ subscribes [11:42] psivaa: ok, nice to know what's the cause :) [11:43] psivaa: we'll need to talk with robru/ken I guess [11:43] didrocks: ack [11:43] psivaa: the regression we saw on maguro is as well due to it? [11:44] didrocks: ogra_ yes, only in one attempt it's unity8 that's causing and the rest it's friends-service [11:44] http://10.97.0.1:8080/job/trusty-touch-maguro-smoke-friends-app-autopilot/13/artifact/clientlogs/top_after.log/*view*/ [11:46] also i logged into the device and it's friends that's at the top [11:46] psivaa: ok, nice to know that all those regressions are due to one and only one component :) [11:46] psivaa: is there a way for you to downgrade the version of friends in one device and restart those tests? [11:47] didrocks: was about to try that :) [11:47] great ;) [11:48] didrocks, psivaa asac bug 1248143 [11:48] bug 1248143 in friends (Ubuntu) "the fix for Bug #1238083 seems to cause the systemsettle tests on mako to fail, blocking image releases" [Undecided,New] https://launchpad.net/bugs/1248143 [11:48] (pleas someone confirm :) ) [11:48] will do [11:49] thx [12:01] 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] psivaa: \o/ [12:01] Mirv: mind you step ahead and revert friends? [12:02] I guess we have enough elements now [12:03] thanks for the hunt psivaa :) [12:03] didrocks: yw, ogra_ found it first :) [12:04] thanks for verifying ! [12:04] :) [12:04] :) [12:05] ogra_: sharing the congrats of finding the guilty component ;) [12:11] didrocks: is that lp:friends revert to previous release, rebuild, and release? [12:12] 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] ok then, understanding enough, reverting that one commit [12:15] didrocks: before I forget what I was doing before that, can you check process-cpp from platform stack is whitelisted for publishing? [12:15] we finally got it working [12:15] Mirv: excellent! checking :) [12:15] right, seems to be just a gconf key change after all [12:16] Mirv: yeah, whitelisted [12:16] didrocks: thanks [12:16] yw [12:18] sil2100: did you get in saucy download-manager? [12:19] didrocks: it's in the unapproved queue [12:19] 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] Didn't get an aswer yesterday, but I'll poke people directly today :) [12:21] sil2100: thanks! [12:30] didrocks: process-cpp in NEW queue [12:30] Mirv: checking [12:32] include/posix/linux/proc/process/state.h: LGPL (v3) [12:32] [Copyright: 2012-2013 Canonical Ltd] [12:32] (mutliple of them) [12:32] when debian/copyright states only 2013 [12:32] nitpicking, not important, but just FYI Mirv $ [12:32] ^ [12:34] -doc should suggests the -dev IMHO (but again, not that important) [12:34] and the long description is quite short… === greyback is now known as greyback|lunch [12:36] 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] (accepted) [12:38] didrocks: ok, I'll let him know. [12:38] or better yet, make a quick branch [12:39] thanks ;) === psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - === greyback|lunch is now known as greyback [13:43] 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] didrocks: (bug filled) [13:43] sil2100: ok, please ping upstream as well, but there is no regression, right? [13:44] didrocks: I guess not, those tests are new as far as I see (will double check) [13:44] sil2100: ok, I think it's okish to push then [13:46] didrocks: ok, as for pushing... how do we actually 'release' click packages ;p? [13:46] sil2100: it's click only? I think just ping sergio [13:47] sil2100: how did you test it then? from the ppa? [13:47] (it overrides the click ones?) [13:49] didrocks: popey gave us instruction on how to test it ;) [13:49] sil2100: oh, do you have a link? [13:50] didrocks: the click packages are being built on jenkins, so you download them from there, reconfigure and test [13:50] Yes, let me fetch it [13:50] http://10.97.0.26:8080/view/click/? [13:50] We wouldn't know if not for popey ;p [13:50] sil2100: ah ok, sorry, I thought those were with daily releases [13:50] sil2100: so, that's why I gave them to you [13:51] No, those are click-only core-apps [14:00] 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] 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] 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] not wanted [14:03] now that the rebuilds are tried [14:06] cu2d does a copy rather than a dput, I'd have thought. But anyway, what package name and version number is this? [14:09] morning [14:16] cjwatson: I'm talking about cu2d -> PPA, not PPA -> archive [14:17] didrocks: sil2100: anyway, feel free to fix if you find out what's the problem. [14:18] 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] 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] the same version number as previous [14:21] 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] I'll cancel platform, services, indicators ongoing runs now [14:22] Ok, I'll backtrack the discussion in a moment [14:23] Mirv: that would certainly do it [14:25] Mirv: interesting, do you have logs with FORCE_REBUILD not incrementing numbers? [14:25] didrocks: http://10.97.0.1:8080/view/cu2d/view/Head/view/Platform/job/cu2d-platform-head-1.1prepare-qtubuntu/472/console [14:28] Mirv: IIRC, ppas were taking back the same version if the previous one was removed, didn't they? [14:29] 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] didrocks: no, you can't reupload the same version [14:29] even if the previous one was removed [14:30] interesting, I should have dream that ppa was enabling that now [14:30] it's possible to *copy* the previous one back in if that's necessary [14:30] well, I need to fix cu2d to even considered deleted version then [14:30] and you can upload an older version after a removal, I believe [14:30] but I don't expect we'll ever consider it desirable to reupload the same version [14:31] 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] 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] Sadly not, bug 845486 [14:37] bug 845486 in Launchpad itself "cannot pass sequence to Archive.getPublishedSources through API" [High,Triaged] https://launchpad.net/bugs/845486 [14:39] 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] You should have some arrangement to avoid iterating over the entire collection, probably [14:40] what do you mean? [14:40] actually, I'm just interested in "getting the higher version that ever existed for that source in this ppa" [14:40] highest* [14:41] Do you actually need to walk over all publications? You should generally get the most recent first [14:41] generally == ensured? ;) [14:41] 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] ok, so, in that case, even the removed version (which is the highest) will be the first one? [14:42] If I understand things correctly then yes [14:43] You get them in reverse order of publication [14:43] If that's what you need then you can avoid the full traversal [14:43] ok, making sense. I can just try relying on that without looping over [14:43] If it's not then you probably just have to walk everything [14:43] thanks cjwatson [14:43] Oh, in fact, it's better than that [14:43] if version is not None: [14:44] ... [14:44] else: [14:44] orderBy.insert(1, Desc(SourcePackageRelease.version)) [14:44] So you get them in descending version order [14:45] nice! I'll definitively use that [14:45] The full ordering will be by source package name, then by descending version, then by id (~= most recent first) [14:52] Mirv: around? [14:54] cu2d updated? :) [14:54] yep, I'm trying with that on qtubuntu right now [14:55] at least, we now see it: [14:55] 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] Uploading to ppa (via ftp to ppa.launchpad.net): [14:55] Uploading qtubuntu_0.52+14.04.20131105.1-0ubuntu1.dsc: done. [14:55] ok, seems to be fine :) [14:55] Mirv: not sure what you wanted to rebuild, but qtubuntu is done and cu2d now supports it [14:55] (with the tests updated as well) [14:56] I guess he wanted to rebuild it against the old mir, I think? [14:56] * sil2100 isn't sure [14:56] sil2100: I think so [14:56] qtubuntu in rebuild anyway [14:56] But as long as it's possible now, then good! Since this was also blocking ubuntu-keyboard sadly ;) [14:56] sil2100: you can relaunch then :) [14:56] \o/ Thanks! Can I use jenkins UI? [14:57] sure [14:58] FORCE_REBUILD is required, or without it will work as well? [14:58] sil2100: if there is no diff with distro, FORCE_REBUILD is required === Ursinha is now known as Ursinha-afk [15:21] sil2100: any news on the other apps, apart from ubuntu-ui-toolkit, gallery-app, ubuntu-keyboard, unity8 are under progress? === Ursinha-afk is now known as Ursinha [15:22] 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] sil2100: notes-app is a click app, isn't it? [15:23] didrocks: we have it in cu2d, so I don't know? [15:23] I was never entirely sure about the status of that one [15:23] sil2100: ok, please release it anyway, just in case [15:24] I think some are both in the archive and in click [15:24] not sure why sergio kept them like that [15:42] 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" === gatox is now known as gatox_lunch [15:44] and they're having their half of the meeting at the moment [15:57] 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] sil2100, we decided previous cycle to used a fixed UTC time, that should apply to your half of the meeting as well [15:58] didrocks doesn't seem to be around though [15:58] Indeed [16:02] 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] I mean I can of course, but that's again 12h after I started my day [16:04] seb128: in a hangout [16:04] Mirv: I consider that as 'ours', since this basically replaced our weekly meetings [16:05] As we didn't have a normal weekly meeting since this was scheduled [16:06] ogra_: cyphermox: sil2100: robru: kenvandine: cyphermox: ready to have the meeting now? [16:06] Mirv: the timing is not too good for you I guess indeed anyway [16:06] didrocks, no [16:06] didrocks: I'm in the phonedations one [16:06] didrocks, i always have another meeting at this time [16:07] ok, 2 people not available, let's postpone in one hour? [16:07] (same as cypher) [16:07] Mirv: ^ [16:07] sure [16:07] 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] sorry Mirv :) [16:07] ;) [16:08] 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] 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] sil2100: great! [16:10] Mirv: exactly my thoughts [16:10] didrocks: packaging ACK needed! http://10.97.0.1: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] sil2100: hum, is the .mo picked up then? [16:10] and no more binary? [16:10] thanks Mirv [16:11] didrocks: no binary, the desktop file opens qmlscene directly [16:12] sil2100: is it already translated, did you check that the translation are loaded up? [16:13] Let me change the locale and check, one moment [16:18] didrocks: the app is translated, so I guess all works ok? [16:20] sil2100: +1 then :) [16:20]