[02:04] === trainguards: IMAGE 236 building (started: 20140911 02:05) === === fginther changed the topic of #ubuntu-ci-eng to: Train support: trainguards | Vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: robru is sick, please ping cyphermox or rsalveti for landings. [02:44] cihelp: were are hitting an issue with the mir autolander [02:44] cihelp: /runscript: line 10: mk-build-deps: command not found [02:45] cihelp: https://jenkins.qa.ubuntu.com/job/mir-clang-utopic-amd64-build/1717/console [02:45] AlbertA2, looking [02:45] fginther: ack [02:49] AlbertA2, I've made a change to fix this and am retesting. I enabled some new build slaves today and it appears they aren't properly setup for these jobs yet. I've reconfigured them to run only on the old hardware until I can fix the missing dependencies [02:50] AlbertA2, This applies to the mir-android-utopic-i386-build job as well [02:50] fginther: ok thanks! [02:50] AlbertA2, sorry for the inconvenience, I'll add these jobs to my test set for the next round of slave updates [02:51] fginther: np [03:04] === trainguards: RTM IMAGE 30 building (started: 20140911 03:05) === [03:45] mornings [03:49] === trainguards: IMAGE 236 DONE (finished: 20140911 03:50) === [03:49] === changelog: http://people.canonical.com/~ogra/touch-image-stats/236.changes === [03:50] ToyKeeper: I git might nightly tests with the RTM image -> http://people.canonical.com/~bzoltan/ap-2014_09_10-19_29_44/ Check the ap-2014_09_10-19_29_44.MAIN-LOGS.tests for the summary. I think it has the same failures as th stock image without the release candidat UITK. [03:51] ToyKeeper: it was on RTM image #32 [04:07] Mirv: I have two RTM silos waiting for QA signature... the first one I tested on #22 and the second on #32 [04:10] bzoltan: ok. it'd be useful to get the utopic release published first. [04:11] Mirv: that one is a clear case after I have now top approved the MRs [04:11] bzoltan: ok, thanks. I'll try publishing it then. [04:12] not that QA would look at the second rtm landing anyhow before the first one is done, of course.. [04:12] Mirv: thank you. I will bug the QA folks to take the RTM UITK in queue. [04:13] Mirv: I do not see any point of releasing the first one to be honest. Or of course it is OK to releas it and in 5 seconds later release the second one. The first one can even cause killer regression because the second will fix it :D One think would be total waste of that ... re-validatinng both [04:14] Mirv: I think the UITK is the only project what does this level of pre-release testing -> http://people.canonical.com/~bzoltan/ap-2014_09_10-19_29_44/ [04:35] bzoltan: that's indeed probable.. [04:52] cyphermox_: just so you know, your upstart publishing did not publish anything, another "new normal" for CI Train. you need to watch that there's that rsync generated, otherwise you'll need to go to build watch_only and possibly reconfigure dance. [04:53] robru: ^ so that's another example of how rtm landings don't land. [04:54] I know to watch for it, but not necessarily all people doing publishing [05:24] bzoltan: Do you have the camera app tests enabled? Everything looked good except for a new failure on the camera app. [05:28] ToyKeeper: the camera app tests have not even started [05:30] bzoltan: Okay, just wondering because it looked like it didn't run. [05:30] ToyKeeper: I hav attempted to run the camera app tests 50+ times this week. It hangs or does not even start. So I removed it from the test lists. It should not block the UITK [05:31] looks like ToyKeeper has conquered the mountain of validating UITK release [05:31] ToyKeeper: http://people.canonical.com/~bzoltan/ap-2014_09_10-19_29_44/ap-2014_09_10-19_29_44-camera_app-1.tests as you see [05:31] bzoltan: I haven't had issues getting the camera tests to run, but it was 1/12 failed pre-silo and 2/12 post-silo. [05:32] and mtp too, and I get to do the so-called "train dance" again it seems [05:32] ToyKeeper: Mirv: But I am still on the opinion that the QA validation should not repeat what I do . [05:32] I then tested that part of the camera's functions manually and it seems fine so I passed it anyway. [05:32] it's a secretive ritual where packages get published with a ceremony of jobs [05:32] which vary from case to case [05:33] bzoltan: The reason UITK was delayed was because the test results didn't match, so I investigated why. I found out that what you were running was very different than the test plan given to QA, which makes it an automatic fail. But instead of failing it, I tried to resolve the issue. Still working on that, actually. [05:34] ToyKeeper: keep in mind that I am testing 20+ apps ... 800+ test cases. Flakiness and instability of apps causes surprises all the time. If any random app's random test would bock the UITK then we stil would be on the 0.000011 version :) [05:35] ToyKeeper: No, I have run exactly the test plan. [05:35] I found some pretty significant differences, big enough to invalidate the results. Like installing bits from the wrong package feed. [05:36] ToyKeeper: the test plan was to run the AP tests for a list of apps ... the test plan does not define for any test plan how the tests are run [05:36] ToyKeeper: what bits and what package feed? [05:37] please ignore the train comments. mtp was ~easy, the uitk needs bigger weapons [05:37] The click setup was pulling files from the non-rtm feed, then testing them on a rtm image, producing meaningless results. [05:37] Mirv: :) OK [05:38] ToyKeeper: that is a phablet-click-test-setup bug ... [05:38] ToyKeeper: this is not the first time that a phable tool bites the SDK [05:39] ToyKeeper: I wish to have a test plan and QA validation for the phablet tools ... I cook from what is given to me. [05:40] bzoltan: You might want to talk with jfunk or perhaps asac about the intended role for QA in the landing process. The idea isn't for developers to test some parts and QA to test the other parts. [05:40] ToyKeeper: But I got your point. The 05.09 landing I have validated with the right click setup. [05:41] The reason for traincon 0 (and the similar rtm landing process) was because people weren't even running the tests, or didn't understand what needed to happen, so QA got involved to fix the process issues and help get everyone on the same page. [05:41] ToyKeeper: You do awesome job to secure the quality. [05:41] ToyKeeper: fixing the problems I would start releasing proper tools what the devs should use to validate their MRs [05:42] bzoltan: I hear there is an effort in progress to run the CI tools against every MP so it'll have those results before landing. [05:42] Not quite the "make CI work for individual use on local devices" I had in mind, but still good. [05:42] ToyKeeper: I am running the tests 24/7. In the last 24 hours I have 5 tims the ful UITK test plan. But unreliable test tools and flaky AP tests can indeed show strange results. [05:43] ToyKeeper: But devs are expected to run tests locally [05:45] I'm hoping the tools will also be made robust for personal use. [05:47] ToyKeeper: We had talked about it with the QA team on the last sprint. I have proposed to require the same quality standards from the phablet tools as we require from the apps and other components. [05:47] QA has had a lot less time for tooling lately though, due to the need to check each silo. :( [05:48] ToyKeeper: for example I did not know that phablet-click-test-setup does not work on the RTM image with the default parameters as it works on the ubuntu image. [05:49] A lot of rtm infrastructure was put together in a hurry, I'm not surprised the auto-detection didn't get implemented. [06:19] Mirv: can you elaborate on this "new normal"? I thought the issue was that it reports successful migration immediately, and then you unsuspectingly free the silo before it is really copied. I'm not aware of any issues where it fails to publish even if you just give it time before freeing. [06:19] Aren't we expecting sil back today? Shouldn't he be on by now? [06:27] Mirv: Ooooooooooh, just saw your email, thanks for that [06:29] robru: you're welcome :) [06:29] those are the usual cases [06:30] sil2100 should be around today, but he usually is around in about 30min - 1h from now [06:46] Ah OK [06:49] o/ [06:51] sil2100: Heyo [06:52] sil2100: welcome back, i hope you had a restful week ;-) [07:13] sil2100: welcome back! [07:14] dbarth: shall we get the testing done for rtm silo 017 today? since it's blocking that already (upstream) tested unity8 landing from going to QA signoff phase [07:33] Mirv: hi [07:34] Mirv: i need to ask someone else with an rtm installed; hold on [07:34] robru: hey! You feeling better now? [07:36] sil2100: yeah but just barely, thanks [07:39] sil2100: I didn't get as much done with the train as I'd wanted, but I fixed some stuff and I got some tests in. Please skim over my recent commits when you get a break from the landing craziness [07:39] robru: thanks, will do! Did you manage to do the big args-to-env change? [07:40] sil2100: that was the first thing I accomplished ;-) so happy to see that code gone! [07:40] dbarth: thanks [07:42] hmm [07:42] something got seriously out of sync ... [07:42] rtm images failed [07:42] sil2100: you won't recognize the deploy script ;-) just wish I had been healthy enough to make those kinds of changes everywhere [07:44] seems ubuntu-touch is uninstallable in rtm [07:44] sil2100: OK, bedtime for me, good luck today! [07:44] robru: no worries, let me take a look - we'll have time to do that next week still [07:44] robru: goodnight! :) [07:45] ogra_: oh, does it say why? [07:45] well, apt is as informative as ever :P [07:45] http://paste.ubuntu.com/8316717/ [07:46] bzoltan, i see you have another silo ready - i would *really* appreciate those logs for the tests you ran - please [07:46] brendand: as we agreed yesterday: http://people.canonical.com/~bzoltan/ap-2014_09_10-19_29_44/ [07:46] 5.8G ./var/lib/jenkins/silos/ubuntu-rtm/landing-017 [07:46] That's a lot for this system [07:47] bzoltan, great! keep doing that :) [07:48] bzoltan, as a reward i will test your silo :) [07:49] brendand: I will do that from now. Thanks for testing the silo. if you need any help please shoot. [07:50] bzoltan: Quick question... silo rtm/landing-009 says it was tested on rtm image 32, but image 30 is still building. How did that happen? [07:50] ToyKeeper, mako probably [07:50] bzoltan, we really do prefer you test on krillin if possible, but if not mako is acceptable [07:51] brendand: I would happily test on krilling if I would have one. It is coming as I have heard. [07:51] Spads: it's Oxide in there at the moment.. [07:51] bzoltan, you could add a reference to that location on the test plan [07:51] Mirv: is it going to go out any time soon? [07:51] bzoltan, fair enough then - no problem [07:52] and yeah: 3.6G ./var/lib/jenkins/silos/ubuntu-rtm/landing-017/build/oxide-qt [07:52] Spads: as soon as possible we hope, but upstream tests it today and then QA needs to test and sign it off [07:52] I only ask because it makes the backups unusually large as well, and that builds up over a week [07:52] but if this is the normal operating size of things for ci-train, maybe the backup policy needs to be revisited [07:53] brendand: If you prefer, I could start the UITK tests running before I go to bed. I still have everything open and set up from last time. [07:53] brendand: If not, you might want to look at this for some possibly-helpful changes: lp:~toykeeper/ubuntu-ui-toolkit/test-plan-qa-changes [07:53] ToyKeeper, if you're confident there won't be any hiccups, sure [07:54] brendand: No, not really confident. There are a *lot* of test failures each time, and many of them change with each test run. It's difficult to get silo-vs-baseimage results which can be compared. [07:55] ToyKeeper, i may as well do it then [07:55] ToyKeeper, should that script just run unattended? [07:55] ogra_: it looks like rsyslog from last night's landing is stuck in rtm proposed [07:55] Mirv, gah [07:56] thanks for spotting that [07:56] ToyKeeper, where does it install the silo? [07:56] did we have a new UITK ? [07:56] brendand: Bottom section of this: https://wiki.ubuntu.com/Process/Merges/TestPlan/ui-toolkit [07:56] seems that dropped 200 tests [07:57] ogra_: in rtm, only after the image build [07:57] Mirv, right, i'm looking at 235 [07:57] which had it before [07:58] bzoltan, http://ci.ubuntu.com/smokeng/utopic/touch/mako/235:20140910:20140903.1/10335/ubuntuuitoolkit/ [07:58] Total tests: 27 [07:58] i assume that should be one or the other test more [07:58] brendand: The provisioning for UITK tests is a little more complicated than other projects, and some things need to happen in a different order. [07:59] ogra_: yeah, a few more ... like 270+ more [07:59] heh, thought so [07:59] ToyKeeper: brendand: for the UITK testing I would recommend the script in the UITK project. [08:00] bzoltan: Indeed. Just not necessarily the provisioning / commissioning parts. [08:00] ToyKeeper: I would say that especially that one [08:01] ToyKeeper: the most important is to remove the UITK tests from the ~phablet/autopilot/ [08:02] ToyKeeper: so that you actually test with the release candidate and not with the archive AP tests [08:02] ToyKeeper: also, the gallery-app bug can still cause surprises .. so removing the cache could save a day [08:04] ToyKeeper, see ogra_ 's comment - did you notice that? [08:04] brendand: ToyKeeper: but the killer of all automatic provisioning is this one -> https://bugs.launchpad.net/ubuntu-rtm/+source/base-files/+bug/1361213 [08:04] Ubuntu bug 1361213 in software-properties (Ubuntu RTM) "add-apt-repository doesn't work" [High,New] [08:04] bzoltan, you don't need to tell me - look at the reporter :/ [08:04] brendand: I know :) [08:04] bzoltan: That add-repo bug is trivial to work around. [08:05] ToyKeeper: Good to know :) [08:05] ToyKeeper, yeah it's not difficult but still annoying [08:05] ToyKeeper: would you please share :) [08:05] echo URL > /etc/apt/sources.list.d/foo.list ; apt-get update [08:05] ogra_: no UITK release in #235, I wonder why we only got 27 tests there [08:06] Mirv, so i wonder if we could just sync dbconfig-common from utopic, that should release rsyslog [08:07] ToyKeeper: ehh.. I though there is a real one :) That one I know [08:07] echo "deb http://ppa.launchpad.net/ci-train-ppa-service/landing-$silo_number/ubuntu-rtm 14.09 main" > /etc/apt/sources.list.d/rtm-"$silo_number".list [08:11] brendand, davmor2, seen bug 1367916 ? [08:11] bug 1367916 in messaging-app "Phone freezes when trying to active the dialer app from the messaging menu" [Undecided,New] https://launchpad.net/bugs/1367916 [08:12] ogra_: brendand : Mirv: sorry dint read all the backlogs, but do you see issues seen in flashing devices with utopic-proposed both krillin and mako (rtm -29 and utopic-236? [08:13] psivaa, i did an OTA ... whats your issue ? [08:13] ogra_, can't say i have, but i'll check [08:13] ogra_, what i did see though is that something broke trust-store location prompts [08:13] again ?!? [08:13] geez [08:13] Okay, updated the wiki page for UITK test plan, fixed two things I missed while writing it. [08:13] ogra_, this time on krillin [08:13] ogra_, before it was only mako [08:14] oh, i thought it was there on krillin too [08:14] at least during the tests [08:14] ogra_, depends on the issue we're talking about [08:14] ogra_: this was fresh flashing with --wipe, we have 6 devices out during flashing [08:14] ogra_: 3 krillins and 3 makos [08:15] ogra_, i'm talking about the one we found when we promoted the last mako image [08:15] psivaa, damn [08:15] ogra_: yea, curious if someone try locally and send out an email if it's confirmed? [08:15] psivaa: only 6 ? nagios seems to report far more than 6 no ? Including flo [08:16] psivaa, flashing utopic? [08:16] brendand, yeah [08:16] Are there problems with flashing utopic? [08:16] vila: i haven't crawled my way upto flo yet [08:16] haven't tried that recently [08:16] brendand: yes [08:17] psivaa, mako too? [08:17] brendand: yes [08:17] brendand: both krillin (with image-29) and mako (with image 236) [08:18] psivaa: flo and manta are ok? [08:18] sil2100: i haven't yet checked them, but vila reports they are down too [08:18] sil2100: and welcome back [08:19] psivaa: thanks :) [08:19] The UITK run for #235 looks strange [08:22] sil2100, there was a landing [08:22] ToyKeeper, still here? [08:22] brendand: Yes, briefly. [08:22] brendand: I checked the changelog and commitlog for #235 and there was nothing [08:22] brendand: at least not directly touching UITK [08:24] sil2100, oh so it didn't land there? [08:24] ToyKeeper, when did you pass uitk? [08:24] brendand: we're talking about utopic here [08:24] Not RTM [08:25] brendand: After the image started building. But I didn't see that there was another UITK silo until afterward. [08:25] psivaa, bah, doesnt boot [08:25] sil2100, oh i see [08:26] psivaa, sitting at the google logo [08:26] sil2100, well i wipe my hands of your utopic :) [08:26] ogra_: right, i think that's the issue that we are seeing. 14 devices with upstream merger jobs too [08:26] damn [08:26] ogra_: dbconfig-common? utopic has a version of it from 2011 [08:26] ogra_: yes I can reproduce that bug, The number is being added to the emergency dialer which is why it looks like it is frozen, if you exit the emergency dialer and log in the number is in the dialer in the real session and works as expected [08:27] Mirv, well, rmadison doesnt think it is in rtm ... and rsyslog-mysql|-psql depends on it [08:27] ogra_: right, it doesn't exist _at all_ in rtm [08:27] davmor2, sound like i heard that before, is that an old bug ? [08:27] so hmm I guess that'd be it [08:28] right [08:28] just pull it in and we should be good [08:28] ogra_: not that I'm aware of [08:28] k [08:29] * ToyKeeper -> sleep [08:30] psivaa, it booted now ... butu it took very very long [08:32] psivaa, hmpf, i fear thats my fault ... the emulator fix seems to turn off adb on boot [08:33] ogra_: ack, that means we have a fix on the way :) [08:34] ogra_: how to turn the developer mode on with the #236? [08:34] bzoltan, see above ... there is a bug [08:35] bzoltan, test with 235 [08:35] Mirv is the first outsider to comment on our trello board! [08:36] davmor2, we need to give him a prize [08:37] a prize \o/ [08:38] sil2100: do you see any problems in excluding the silos/ directory from backups of the train? We can easily re-create their contents, correct? [08:38] trying to get out of this disk space hole [08:38] brendand: he gets to keep his cat we stop sil2100 steeling it [08:38] ogra_: I just flashed 236 :( [08:42] ogra_: is there a way to enable adbd in the treminal app? [08:42] brendand, sure [08:42] davmor2: thanks for the protection :) [08:42] andr enable adb [08:42] ;) [08:43] anything simpler? :) [08:44] you could try a hammer ... but i wont promise success :) [08:46] ogra_: ohhh... I just tried. It broke my device. :D [08:48] ubuntu-device-flash doesnt work for us anymore :) [08:48] ubuntu-device-flash --channel=devel-proposed with a mako connected [08:49] but guess tvoss asked elsewhere already [08:49] so /me will wait for his answer [08:49] ogra_, i can't repro that bug in RTM [08:49] asac, yes it's broken [08:49] brendand, which bug ? [08:50] brendand: broken? [08:50] how come? [08:50] ogra_, the messaging app one [08:50] who broke? [08:50] brendand, ah [08:50] asac, i'll let them confess :) [08:50] hehe [08:50] well. how ? [08:50] upload of ubuntu-device-flash? [08:50] or server busted? [08:50] asac, adb not being started [08:50] adbd [08:50] dev mode? [08:50] asac, looks like a system-image server issue if you ask me [08:50] brendand, unrelated [08:50] ogra_, really? [08:50] yes [08:51] oh, wait, probably not [08:51] are you on it? [08:51] ogra_, i didn't see all the details of asacs issue [08:51] brendand, i got tvoss' details [08:51] sudo ubuntu-device-flash --channel=ubuntu-touch/devel-proposed [08:51] 2014/09/11 10:47:11 Expecting the device to expose an adb interface... [08:51] 2014/09/11 10:47:11 Device is |/bin/bash: /root/.bash_profile: Permission denied [08:51] mako| [08:51] 2014/09/11 10:47:11 Device /bin/bash: /root/.bash_profile: Permission denied [08:51] mako not found on server https://system-image.ubuntu.com channel ubuntu-touch/devel-proposed [08:51] thast what i see [08:52] I see the same [08:52] right, the last message confused me [08:52] surely a follow up from the stuff before [08:52] or at least very likely [08:52] then its the last lxc-android-config landing [08:52] i see whats wrong and have a fix, [08:52] thx [08:52] does this affect ability to upgrade? [08:52] for thos taht have something installed? [08:52] not OTA, no [08:53] ok [08:53] so just newcomers cannot flash [08:53] and infrastructure [08:53] and u-d-f will work from reciovery [08:53] asac, right, i'm aware since 30min [08:54] ogra_: so this explains all (almost, 14 at least and counting ;) the devices in the infra being busted ? [08:55] ogra_: with image #236 that is [08:55] vila, yes, see the backlog and my conversation with psivaa [08:57] ogra_: I could boot to recovery and now i am fahsing 235 with bootstrap [08:57] bzoltan, yeah, that will work fine [08:57] (as well as just enabling adb with the above command in the terminal) [08:58] ogra_: ... and the hummer [08:58] lol [08:58] that works always ... I was told today by my 5yo [09:02] tvoss: non-approved https://code.launchpad.net/~thomas-voss/dbus-cpp/fix-int64-signature/+merge/232511 [09:03] Mirv, done, and sorry [09:04] thostr_: note line 32 is not marked as Ready?, should it be? (rtm fix apparmor settings) [09:05] tvoss: why does libmedia-hub-common2.symbols only have one symbol while the common1 had many? https://ci-train.ubuntu.com/job/ubuntu-landing-004-2-publish/12/artifact/packaging_changes_media-hub_2.0.0+14.10.20140910.2-0ubuntu1.diff [09:06] Mirv, I added a symbols.map to prevent weak stl symbols bleeding into the exposed set of symbols [09:06] Mirv, we are doing that for almost all projects now, media-hub is one of the remaining ones [09:07] tvoss: oh, stopping bleeding is good indeed [09:07] sil2100: there's a need for MOTU here https://ci-train.ubuntu.com/job/ubuntu-landing-004-2-publish/ [09:07] my motu meeting is in 1.5 weeks ;) [09:08] Mirv: looking :) [09:09] Mirv: well, there's no way you won't become a MOTU ;) So it's just a matter of time [09:09] sil2100, can you help me out with a couple of silos? [09:11] sil2100: hehe [09:11] Mirv: looks good, although it's really fishy that the symbols-count for the -common library fell down so much ;) But I guess since it builds, then it has to mean everything is OK [09:11] Mirv: so a +1 [09:11] brendand: what's up? [09:12] sil2100, i tested silo 14 earlier this week and found an issue [09:12] sil2100, the lander prepared a fix which they already landed in utopic [09:13] sil2100, that fix is in silo 15 now [09:13] sil2100, but it fixes a bug that only exists in silo 14 [09:13] sil2100, is that ok, or is it going to cause issues? [09:15] maybe i need to test and land them together? [09:16] Mirv: line 32 is ready... seems I overlooked it [09:17] cjwatson: hey! If I would like a new package in ubuntu-rtm which is available in ubuntu, can I simply publish it to ubuntu-rtm? [09:17] cjwatson: or do we need something else to make sure ubuntu-rtm recognizes it? [09:18] brendand: let me read up, one moment :) [09:19] brendand: so, in other words... there are two rtm silos with the same component, right? 14 and 15? [09:21] sil2100: thanks! yes I checked the symbols with thomas [09:22] thostr_: ok, thanks! [09:24] brendand: since because you say that the packages that are in silo 15 are already in utopic, what we can do is simply rebuild unity-scope-mediascanner in silo 14 [09:25] brendand: then silo 14 will have everything that you need [09:25] brendand: since it will have the 2 other packages for itself + the latest of the latest from silo 15 [09:26] sil2100, yeah i would rather have everything in one place [09:26] pete-woods, ^ [09:27] brendand: oh, I see it's no longer a sync silo [09:27] brendand: ok, let me get everything you need into one silo anyway :) [09:28] brendand: okay, so what do you need me to do? [09:28] am I rebuilding the mediascanner silo? [09:28] pete-woods, i don't *think* you need to do anything [09:29] pete-woods, just waiting for those test results [09:30] pete-woods: no worries, I'm handling everything :) [09:30] pete-woods: I'm making sure that everything is in silo 14 that's needed [09:30] Mirv: for silo 17 testing, either i need to wait for alex-abreu later today, or maybe i can stand by during the qa signoff to speed that up? [09:32] ev: hmm, from first thought it might be ok, but let me double check something in a moment [09:33] :) [09:34] okay [09:35] Mirv: could you please upload http://s-jenkins.ubuntu-ci:8080/job/sudoku-app-click/lastSuccessfulBuild/artifact/com.ubuntu.sudoku_1.1.282_all.click to the store? [09:36] cjwatson: for now I'll try using a silo to sync it up [09:36] Mirv: http://s-jenkins.ubuntu-ci:8080/job/weather-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.weather_1.1.365_all.click also please [09:38] dbarth: what do you mean by stand by? maybe you could negotiate whether QA would be ready to start testing the silo without your approval, or that you would mark it as "tested" (the utopic equivlent was) to get it progressing? [09:41] popey: noted. my click-toolbelt just decided python doesn't have datetime module, so might need some time [09:41] oof [09:44] Mirv: have QA start testing to confim the silo; quicker easier, it's a set of bug fixes [09:45] dbarth: right. please talk to brendand davmor2 about that (this is about silo 017) [09:45] let me know who gets started on that and i can just help drive the test in a hangout [09:45] dbarth: they have currently it and silo 010 on hold until 017 would be marked as ready for signoff testing [09:45] ok clear [09:49] dbarth, could you look at https://bugs.launchpad.net/ubuntu-facebook-app/+bug/1367704 to check if it's assigned to the right component (it's a bug from jane) [09:49] Ubuntu bug 1367704 in Ubuntu Facebook App "Facebook account not recognised by Facebook webapp" [Undecided,New] [09:51] seb128: it's not; but ok, taking care of it [09:51] dbarth, thanks [09:57] sil2100: you can just copy it, sure [09:58] sil2100: context? [09:58] sil2100: is this rsyslog? === psivaa changed the topic of #ubuntu-ci-eng to: Train support: trainguards | Vanguard: psivaa | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: robru is sick, please ping cyphermox or rsalveti for landings. [10:02] cjwatson, yeah [10:02] it broke image builds today [10:04] dbarth: we can't touch silos till they are listed for QA sign off [10:04] sil2100: using a silo for this is pointless - we should either force it, or else just do a direct binary copy into 14.09-proposed [10:04] * ogra_ would do the latter [10:04] pete-woods, i think silo 14 should be retested [10:05] sil2100: why did you rebuild this package? [10:05] sil2100: seriously, let's stop doing pointless source-only copies when we just want to get the dependencies satisfied [10:06] davmor2: i marked it test pass but left the #, does that help? [10:06] apparently the queuebot noticed ;) [10:07] dbarth: we'll find out in a second thanks [10:08] ok, let me know if you want to open a hg; it's a quick test (apart from your own test round) [10:08] 17 is ready now [10:11] davmor2, brendand: I posted an update on https://bugs.launchpad.net/unity8/+bug/1367400 about the bug in launching music-app for music on the SD card: in short, the fix to switch to music:/// has not made it to ubuntu-rtm yet [10:11] Ubuntu bug 1340952 in url-dispatcher (Ubuntu) "duplicate for #1367400 Video and Music scopes should provide non-file:/// based URIs" [High,In progress] [10:11] jamesh, is it in silo 14? [10:12] cjwatson: can you just do a direct binary copy then? [10:12] brendand: doesn't look like it. [10:12] jamesh, oh ok [10:13] cjwatson: it's a package from main so I have no power over it besides through a silo [10:13] brendand: was blocked waiting for QA approval for a landing to utopic, which looks like it has completed now [10:13] pete-woods, jamesh - so can we agree that you'll rerun the localmediascopes test plan for silo 14 and record the results somewhere? [10:13] cjwatson: I can do a binary copy to the silo and then release, but yeah... [10:13] sil2100: done [10:13] $ copy-package --from=ubuntu --from-suite=utopic --to=ubuntu-rtm --to-suite=14.09-proposed -b dbconfig-common [10:13] cjwatson: thanks! [10:14] cjwatson: well, in theory I can't do that for a main package, right? [10:14] indeed [10:14] cjwatson: or can I? [10:14] I don't believe you'll be able to [10:14] bug: sil2100 is not core-dev :) [10:14] ;p [10:15] even if you need to use a silo, though, please just binary-copy from ubuntu for this kind of thing [10:16] the reversioning and rebuilding gains us nothing, and potentially even introduces issues (e.g. if somebody has a >= dependency on the latest version of the thing we're copying) [10:16] the source of this issue was a bug in the original ubuntu-rtm copying script [10:17] I followed through dependencies on everything we actually needed, of course; but I didn't follow dependencies of other binaries built by the same source as binaries we actually needed [10:18] ACK o/ [10:18]