=== chihchun_afk is now known as chihchun === charles_ is now known as charles [06:55] Mirv: the version separation MR is still having problems ... feels a but strange https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/2285/console [07:14] bzoltan: looks like a job for cihelp [07:14] network problems [07:15] bzoltan: oh, that was probably during the break that was announced [07:16] bzoltan: once again it's rebuilding [07:54] Mirv: thanks [08:08] Mirv: Do you think if it is possible that the UITK packages built by CI/Jenkins are incompatible with the fresh image with the overlay PPA? [08:10] bzoltan: no, I don't know if MP:s are built using overlay PPA:s correctly or not [08:11] Mirv: ok...do you know which channel has the standard vivid image without the overlay ppa? [08:12] Mirv: or maybe I just need to purge the PPA on the device [08:12] bzoltan, there is no such thing [08:13] ogra_: Good to know.. so CI/jenkins builds against a rootfs what is equivalent with the vivid+overlay? [08:13] yes, indeed, since that is what we work with [08:13] dropping the overlay PPA would mean going backwards in time ... to release day [08:14] we shouldnt have called it overlay :) it is an extension of the archive in this case [08:15] ogra_: I see. Thanks for the clarification... in this case my build artifects are to blame :) if something does not work after I install them [08:16] bzoltan: oh yes, the CI/jenkins definitely uses the latest image which include overlay, that's ture [08:28] ^ ignore that ;) [09:20] jibel: i was told that silo 39 would automagically appear in https://trello.com/b/AE3swczu/qa-testing-requests-for-questions-ping-eu-jibel-us-jfunk-or-ubuntu-qa-on-ubuntu-ci-eng because it's set as "QA needs to sign off" in the CI train spreadsheet, but maybe i missed something? [09:20] is there something i need to do? [09:54] tsdgeos: it should, but maybe the bot has some trouble today [09:55] ok :/ [09:55] jibel: maybe the yesterday's switch of the bot got things broken? [10:14] sil2100, no I didn't push it into production. [10:15] sil2100, brendand_ disabled it because we cannot login to LP from the instance it is running on [10:15] jibel: oh? What happened? Firewall changes? [10:16] sil2100, it seems to be an issue in wadllib on precise [10:18] tsdgeos, ^^ as soon as the bot is back the card will be created [10:18] ogra_: hey! We seem to be missing the .changes file for 192 :) [10:18] oops, will fix [10:23] imgbot, status 192 vivid [10:24] Status: succeeded, Started: 2015-05-07 02:03:11 UTC, Finished: 2015-05-07 02:55:51 UTC [10:24] Build URL: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/+build/26200 [10:24] Changelog: http://people.canonical.com/~ogra/touch-image-stats/192.changes [10:24] fixed :) [10:31] o/ [10:31] Thanks :) [10:36] sil2100: ogra_ says fixed, what that actually means is until you look away from the screen or need to use it ;) [10:44] trainguards: hi guys. could I get wily silo 34 reconfigured please? I've added a new MR for cmake-extras [10:47] pete-woods: on it [10:47] sil2100: thanks! [10:49] pete-woods: should be done, yw! [10:51] jibel: that seems a little improbable - e.g. snakefruit is a very heavy user of launchpadlib and is on precise === MacSlow is now known as MacSlow|lunch [11:00] fginther: hey, again the i386 machine is broken, I tried to reuse the snapshot revert job to bring it up again, but seems it didn't want to start the jenkins slave job (ps-trusty-desktop-revert-snapshot-daily/1182/console). This job started successfully multiple times yesterday, not sure what happened… [11:03] random question, but does anyone know what LP is actually up to when packages are built, but not published in a PPA? [11:04] are we waiting on some sort of cron timer or something like that? [11:04] pete-woods: from what I know, there is a cron timer going over all ppas and doing the actual archive publication [11:05] (and so, the time depends on how many ppas need to publish new binary packages, a little bit similar than the archive itself) [11:05] I guess there's also a fair amount of if you git the start of a "tick" you wait a long time [11:05] but if you are near the end, then great [11:05] *hit [11:05] yeah, depends if you are lucky or not :) [11:05] that's one of the reason the train (if that part didn't change) is actually checking the archive file itself to say "published" [11:06] right, that explains that then :) [11:06] Indeed. The publisher takes non-zero time. [11:06] And there are a lot of PPAs. [11:20] * sil2100 off to prepare lunch === alan_g is now known as alan_g|lunch [12:28] sil2100, john-mcaleely: krillin vivid device tarball is good [12:28] cwayne: did you update the vivid krillin custom tarball at all? [12:28] davmor2, o/ [12:29] john-mcaleely: you can push! [12:31] sil2100: there were a couple of issues highlighted but they already exist in the default image, mms/3g fails if there is no password in the apn config and the video issue that jhodapp is getting the blame for even if it is qtmedia :D [12:32] sil2100: these won't block this landing but would block ota4 just as a heads up [12:32] davmor2, ha...confirmed that it is qtmultimedia...I found the build number that introduced that regression so now I'm trying to figure out what broke it [12:33] sil2100: see told you he'd blame qt, I still say it's all jhodapp 's fault cause it's multimedia and leave it at that ;) [12:33] davmor2, no comment [12:33] jhodapp: nice work thought on a plus side :) [12:33] though even [12:34] davmor2, thanks :) [12:36] hah ;) [12:36] Blame Mirv ! [12:37] davmor2, i built the proposed one at the same time as the other one yesterday [12:38] cwayne: so the one in vivid is good then cool, I'll test that after an emulator and mako sanity run [12:38] davmor2, sil2100: btw ogra_ brought to my attention some missing translations from the new custom we pushed the other day :/ I have a fix ready in case it's critical [12:39] cwayne: uh, missing translations in RTM? [12:39] sil2100, yeah :/ [12:40] cwayne: are those missing for all languages? [12:42] sil2100, 1 string, yeah [12:42] sil2100, I am blaming Mirv :) === _salem is now known as salem_ [12:45] Mirv, ping [12:46] jhodapp: pong [12:47] Mirv, hey, the last qtmultimedia upload on krillin vivid image #193 broke playback of ubuntu touch camera recorded videos [12:47] Mirv, what was that update for? [12:48] jhodapp: don't ask me, I wasn't involved ;) rsalveti's landing [12:48] debian/patches/debian/patches/qgstreamercapturesession_avoid_race_eos.patch [12:49] Mirv, ok :) [12:49] so a fix to bug #1433563 [12:49] bug 1433563 in Canonical System Image "QAudioRecorder recording hangs" [High,Confirmed] https://launchpad.net/bugs/1433563 [12:49] Mirv, oh right [12:49] Mirv, I'll talk to him thanks [12:50] rsalveti, let me know when you're online [12:50] it moves one line around https://code.launchpad.net/~rsalveti/kubuntu-packaging/qgstreamercapturesession_avoid_race_eos/+merge/256881 [12:51] jhodapp: Mirv: just krillin? [12:51] rsalveti, yeah [12:51] that was required to fix audio recording [12:52] doesn't make any sense [12:52] to be device specific [12:52] rsalveti, yeah, but it seems to have broken video playback [12:52] but that code is only executed in the end of the pipeline [12:52] or when pausing [12:52] did we really validate that reverting that package fixes it? [12:52] rsalveti, I traced it using gdb and then confirmed by finding the build number [12:52] rsalveti, not yet, about to do that === MacSlow|lunch is now known as MacSlow [12:53] easy to rebuild that package and change that line [12:54] rsalveti, ok...I'm on krillin image 192 right now and it doesn't display this broken behavior...so I'm going to upgrade just this package next [12:56] imgbot: map 190 [12:56] imgbot: map 190 vivid [12:56] nah [12:56] imgbot, map 190 vivid [12:56] mako ubuntu version: 190 maps to krillin version: 203" [12:56] mako ubuntu version: 190 maps to generic_x86 version: 192" [12:56] imgbot, map 180 vivid [12:56] mako ubuntu version: 180 maps to krillin version: 193" [12:56] mako ubuntu version: 180 maps to generic_x86 version: 182" [12:57] imgbot, map 179 vivid [12:57] mako ubuntu version: 179 maps to krillin version: 193" [12:57] mako ubuntu version: 179 maps to generic_x86 version: 182" [12:57] imgbot, map 178 vivid [12:57] mako ubuntu version: 178 maps to krillin version: 191" [12:57] mako ubuntu version: 178 maps to generic_x86 version: 180" [12:57] no 192 for krillin haha [12:57] * davmor2 takes away rsalveti 's right to abuse the bot [12:58] rsalveti, hmm, it downloaded and installed a 192 === alan_g|lunch is now known as alan_g [13:06] jhodapp: that probably means we had a device tarball update [13:06] which would cause the version bump [13:06] rsalveti, hmm, ok...so it's not your qtmultimedia update but it is something in that build # [13:07] that would be my guess [13:07] rsalveti, just upgraded the packages for qtmultimedia and it still plays [13:07] rsalveti, yeah looking at your change there's no way it could be that [13:07] so we need to understand what changed at the device tarball side [13:07] rsalveti, the bug is in a different part of qtmultimedia...it's not creating the QSGVideoNode instance [13:08] rsalveti, yeah, where do you see those changes? [13:08] jhodapp: would need to track barajas [13:08] jhodapp: john-mcaleely might be able to help you [13:09] john-mcaleely, ping [13:09] jhodapp, pong [13:10] john-mcaleely, trying to track the device tarball changes for krillin build #193 [13:10] john-mcaleely, how/where can I see what changed? [13:10] #193 on which channel? [13:11] john-mcaleely, vivid-proposed [13:12] jhodapp, Description: ubuntu=20150507,device=20150326-f0c5ba5,custom=20150507,version=205 [13:12] not 192 [13:13] john-mcaleely, not 192? [13:14] 192 is not latest in ubuntu-touch/vivid-proposed [13:14] for krillin [13:14] john-mcaleely, right, trying to trace a bug [13:14] aha, ok [13:15] jhodapp, that device tarball is [13:15] http://people.canonical.com/~jhm/barajas/master/device_krillin-20150326-f0c5ba5.changes [13:15] Description: ubuntu=20150421,device=20150326-f0c5ba5,custom=20150421,version=192 [13:16] john-mcaleely, what's the version after that? [13:16] john-mcaleely, can I see that too? [13:16] jhodapp, http://people.canonical.com/~jhm/barajas/master/device_krillin.build [13:16] shows that is the current device tarball [13:17] there's one I'm *about* to publish [13:17] ok [13:17] but it's not live [13:17] john-mcaleely, the latest has no description inline [13:17] just a hash [13:18] there should be a matching .changes file in the same dir ... [13:18] ogra_, don't see one for latest [13:18] jhodapp, the hash matches [13:19] jhodapp, (otp) [13:19] http://people.canonical.com/~jhm/barajas/master/device_krillin-20150326-f0c5ba5.changes [13:19] that is the one matching the build id [13:20] oh I get it [13:20] right [13:20] 5f3d334 Disabling CONFIG_VT_CONSOLE_SLEEP to avoid the flood of vt-switch events from logind [13:20] perhaps this ? [13:20] nops [13:20] no nothing in there looks suspicious [13:20] (assuming you look for rge black video issue) [13:20] I think it's just easier to bisect the barajas tree [13:20] yeah, playing recorded videos [13:21] rsalveti, why nops, how do you know dropping that option doesnt perhaps disable other CONSOLE options in the config ? [13:21] sil2100, so with the phone images staying on vivid, is there a plan to keep the pre-merge CI on vivid as well? Or should trunks move to wily and we should create SRU branches for vivid? [13:22] (perhaps one that affcts the codecs) [13:22] ogra_, well the issue is qtmultimedia isn't creating the QSGVideoNode instance [13:22] ogra_, that much I know already [13:22] fginther: hey, so I don't have any definite guidelines from higher-ups and I don't want to enforce my own policies [13:23] ogra_: because I did that change :-) [13:23] heh, ok [13:23] and that is also on RTM [13:23] what was ppl_agent again ? [13:23] sil2100, heh :-). I've been poking steve about this, but his apparently been busy with other things [13:23] fginther: so for now let's leave CI on vivid until we have a clear understanding ;) [13:23] rsalveti, why do you think the culprit might be in the device tarball for this bug? [13:23] jhodapp: because there is no rootfs update for 192 [13:23] fginther: yeah, he mentioned that we still need to figure it out [13:24] when we get a version bump like this, it is either device tarball or custom tarball updates [13:24] since we don't have a custom in there [13:24] rsalveti, right but 192 works fine [13:24] imgbot, map 178 vivid [13:24] rsalveti, it's 193 that is broken [13:24] imgbot, map 179 vivid [13:24] mako ubuntu version: 178 maps to krillin version: 191" [13:24] mako ubuntu version: 178 maps to generic_x86 version: 180" [13:24] mako ubuntu version: 179 maps to krillin version: 193" [13:24] mako ubuntu version: 179 maps to generic_x86 version: 182" [13:24] oh, 192 is fine? [13:24] yes [13:25] but you updated the package and still worked right? [13:25] yes [13:25] there is no changelog for 179 [13:25] http://people.canonical.com/~ogra/touch-image-stats/180.changes [13:25] just 180 [13:25] rsalveti, yeah, it's 180 [13:25] so 179 was a device or custom tarball [13:25] http://people.canonical.com/~ogra/touch-image-stats/180.changes [13:26] right, which is why I was thinking it was an issue with the device tarball [13:26] rsalveti, let me try upgrading the rest of the packages from the 180 diff and see if any of those break it...if not then yes I agree it's device or custom [13:26] cool, alright [13:27] rsalveti, 180 was a custom tarball [13:27] well, 179 i mean [13:27] hmm [13:28] actually ... 180 was custom and rootfs at the same time [13:28] 179: version_detail": "ubuntu=20150409,device=20150326-f0c5ba5,custom=20150409,version=179" [13:28] 180: "version_detail": "ubuntu=20150410,device=20150326-f0c5ba5,custom=20150410,version=180" [13:28] device didnt change at all [13:29] do we get any denials? [13:30] rvr, you're the last to comment on the card for vivid silo 15, it's still under testing, not blocked but nobody is assigned? [13:30] rvr, did it get forgotten? :-p [13:30] kenvandine: It's confusing... That's actually a trick to calculate how much time does it take to test silos. [13:31] jhodapp, sorry [13:31] jhodapp, did you find what you needed? [13:31] kenvandine: The QA team was busy doing other things these days [13:31] ogra_: jhodapp: if we get denials it could be related with custom [13:31] or still seeking? [13:32] rvr, ok, just making sure it's not forgotten. that wasn't clear [13:32] john-mcaleely, still trying to narrow down what caused the bug...I'm good for now but will probably have another question soon [13:32] rsalveti, apparmor denials? [13:32] john-mcaleely, i think we're fine ... device didnt change around the time the issue started [13:32] jhodapp: yes [13:32] rsalveti, let me check that next [13:32] ah, right. ok [13:33] I'm slightly off the hook then [13:33] john-mcaleely, for now ;p [13:33] sil2100, so, I got distracted. is now a good time still for the new vivid krillin tarball? [13:39] rsalveti, nope, none of those packages cause the regression [13:40] rsalveti, if I download the device and custom tarballs for 193, how do can I manually flash those? [13:51] jhodapp: there is a device argument in ubuntu device flash [13:51] rsalveti, alright [13:52] --device-tarball [13:52] there is also one for custom [13:52] just flash without --wipe/bootstrap [13:52] rsalveti, awesome thanks [13:52] then you can easily test and validate your environment [13:53] rsalveti, indeed [14:02] sil2100, slangasek, we really need an answer on how to handle this vivid-wily transition. It's blocking other wily work and may lead to confusion for the upstream teams as well until we have a clear direction. I'm happy to discuss alternative approaches. [14:02] fginther: +1 [14:18] didrocks, the i386 node is working again. I had to fix a larger problem of a full disk :-( [14:22] sil2100, davmor2 krillin-vivid tarball pushed [14:23] john-mcaleely: \o/ thanks :) [14:23] john-mcaleely: \o/ [14:54] hey guys since, jenkis is not in a good shape (most of autopilots tests fail to run due some wrong configuration or network errors) can we disable the autopilots on jenkins and just keep the output debian files? This will save us a lot of time [14:55] cihelp ^ [14:57] renatu, can you point to a specific example so that I know which tests you are referring to? [14:57] trainguards, could I get silos for spreadsheet rows 61 and 62? I added these to the spreadsheet earlier but looks like the silo request fell in the bitbucket [14:58] eg, no request ids for those rows [14:59] yay [15:00] charles: 16 and 35 [15:01] renatu: opa :) we're investigating the networking issues now (things got bad after the rack move yesterday), if you point us to the failing jobs we can have a look [15:01] robru, thanks :) [15:01] charles: you're welcome [15:02] robru: you woke up for the meeting? :) [15:02] trainguards Silo 021 testing done. You can publish. [15:03] alan_g: ACK! [15:03] sil2100: well it's not like I can read meeting cancellation emails while I sleep! [15:03] hmmm [15:03] robru: don't publis silo 21 [15:03] alan_g: hm, why is it set to not needing QA sign-off? [15:04] because camako set that. (He says only needed for RTM) [15:04] fgimenez, Ursinha, ok let me try a new build, I will ping you if still falling. Thanks [15:04] alan_g: it's a big landing, right? Anything that's not a 100%-risk-free change shouldn't land without QA sign-off [15:05] alan_g: no, we require sign-off for vivid since 2 months ;) Since we'll be switching our stable branch to vivid in the next weeks [15:05] alan_g: only landings to wily currently don't need QA [15:05] But wily is more like hm, a playground right now [15:05] sil2100: ack [15:05] alan_g: anyway, no harm done :) [15:06] alan_g: if anything, the https://wiki.ubuntu.com/citrain/LandingProcess docs are up-to-date with current policies [15:27] alesage: Mirv: slangasek: https://code.launchpad.net/~robru/phablet-tools/fix-overlay-pinning/+merge/258514 can you guys take a look at this one-liner? [15:30] robru: looks goodish, but just in case I wouldn't put the pin priority that high ;) But that's just cosmetics [15:31] sil2100: yeah I wasn't sure what a good number would be. needs to be at least 1002 to beat the overlay ppa pin, but then i thought maybe some space inbetween would be prudent [15:41] robru, just taking it for a spin [15:41] alesage: thanks [15:43] alesage: so you should expect a mix of overlay PPA packages and silo ppa packages, perhaps similar to http://paste.ubuntu.com/11011081/ [15:43] fginther: argh, anything I can do to help preventing this? [15:43] fginther: and thanks! [15:44] didrocks, the host system is just missing some active monitoring. It was a different VM that had become out of control and was consuming too much disk [15:45] fginther: ah ok, not those vm's faults then! Good to know and that explains why I couldn't restart it myself :) [15:46] sil2100: just checking my understanding: the policy you referred me to says QA sign-off for /1/ "TRAINCON-0" and /2/ "For all landings to the ubuntu-rtm branch". Is it wrong? [15:46] alan_g: hah! Ok, you found one place where it's not modified ;) The landing instructions in the first section have it explained [15:47] alan_g: thanks for mentioning, let me change that, this part was always managed by QA [15:48] sil2100: yw :) === chihchun is now known as chihchun_afk [16:15] jibel: http://people.canonical.com/~platform/citrain/?C=M;O=A raw json with mp lists [16:20] trainguards: can i get a reconfig for ubuntu/landing-022 please? had to do a merge and resubmit for one MP to resolve a conflict [16:21] dobey: you have permission to reconfigure as long as you're not adding a new project [16:22] robru: how do i reconfigure then? i don't see a link for that on the dashboard or in the spreadsheet [16:23] dobey: "Landing Tools" menu in the spreadsheet. just click the right row first. [16:24] "This app needs authorization to run" [16:25] oh, i have to log in again in google, ok [16:29] hmm [16:29] i guess it didn't work [16:56] hmm [17:11] cihelp: are the silo PPAs being cross-compiled for arm? [17:13] nothing is cross compiled in the official infra [17:13] it is always native [17:14] there are virtualized armhf PPAs though ... i dont think the silos are vitrual [17:15] hmm [17:16] dobey: silos are definitely devirt, that's a security requirement for publishing in ubuntu archive. [17:16] dobey: also silos >30 are new, are you seeing a problem there? hopefully they weren't misconfigured when they were created. [17:16] this error doesn't make any sense then; and i'm not sure why it's happening. and i don't have a wily on arm anywhere to really test it [17:16] robru: this is in 22 [17:17] https://launchpadlibrarian.net/205880848/buildlog_ubuntu-wily-armhf.unity-scope-click_0.1.1%2B15.10.20150507.1-0ubuntu1_BUILDING.txt.gz [17:17] dobey: definitely devirt then [17:18] dobey: hmm, that is tricky. the only way I know to fix those is to have it installed on a device and poke at it with apt. time to do-release-upgrade on a phone? ;-) [17:18] yeah; the error makes sense to me only in the context of cross-build though; and a new version of ubuntuone-credentials was even released last night into wily without any problems :-/ [17:19] robru: yeah, i guess i'll have to debootstrap a chroot on a phone to see [17:19] also, debootstrap is a weird name for a tool that actually bootstraps something :P === alan_g is now known as alan_g|EOD [17:21] dobey: heh [17:21] dobey: oh, the ubuntuone-credentials was only published 4 hours ago, maybe this is a transient error due to running the build before the package fully published? might be worth trying the build one more time before mucking with debootstrap [17:22] oh, is publishing to the ports archive that slow? [17:23] dobey: well I'm not sure exactly at what time your build was started. [17:24] robru: very recently; and i've already tried to rebuild once [17:24] dobey: oh if you already rebuilt it then I dunno, sorry. yeah try debootstrap [17:28] brb [17:29] yeah, and looking at ports server, the packages are already there; and these are coming from ftpmaster.internal anyway (though maybe ftpmaster.internal is behind?) [17:30] imgbot, map 181 vivid [17:30] mako ubuntu version: 181 maps to krillin version: 195" [17:30] mako ubuntu version: 181 maps to generic_x86 version: 184" [17:34] well, at least making a wily chroot isn't too bad; i already had a vivid chroot, so just copying it and then tweaking sources.list and doing dist-upgrade works well enough to get a chroot fairly quickly [17:44] robru: so fun. in a wily chroot on my nexus4, i added the landing-022 ppa, and did apt-get build-dep unity-scope-click, and it's installing everything just fine :-/ [17:45] so trying to build again :-/ [17:54] bah, it's still failing :( [17:56] dobey: sorry, that's gone beyond my skill level. maybe infinity or cjwatson can give some more insight into that. [17:57] yeah, or wgrant when he shows up [17:57] would be nice if the lp builders were configured to output verbose apt error messages for these things [18:23] ogra_: even virtualised PPAs aren't cross-compiled [18:24] cjwatson, thats what i said [18:24] (i think) [18:24] ogra_: you implied that virtualisation or not was somehow relevant to dobey's question; it isn't, neither virt nor devirt are cross-compiled [18:25] dobey: heh, the problem is you can't really get apt to be very verbose in a useful way without considerable logic [18:26] dobey: easiest way is to build a chdist instance locally with the appropriate sources.list and play with that [18:26] cjwatson: chdist would be different from my existing wily chroot somehow? [18:27] yes, you can easily set one up for a different architecture etc. [18:27] can't seem to get it to go wrong here though [18:28] well i've got the chroot on my phone, so it's armhf already. but i can't get it to fail there either :-/ [18:30] so i don't know what else to do at this point [18:31] I'm continuing to investigate in between evening stuff [18:31] cjwatson: ok, thanks [18:43] dobey: it seems OK here too, retrying [18:44] i've rebuilt (via ci train dash) 3 times now with the same failure [18:44] dobey: looking at recent archive changes, there's a pretty good chance that this was due to arch skew in -proposed with https://launchpad.net/ubuntu/+source/glib-networking/2.45.1-1, which only just built ~50 minutes ago [18:44] prior to that there were several hours where it was skewed on amd64 vs. armhf [18:45] oh, is -proposed being pulled in here too? [18:45] yes [18:45] did your chroot include that? [18:45] anyway, it's building now [18:45] and is past the previous failure [18:45] ah, ok. no, i don't have -proposed in my chroot [18:46] i thought the PPA builders didn't have proposed enabled [18:46] this isn't a property of the builders [18:46] it's a property of the PPA [18:46] and all the silos are configured with -proposed enabled by default, because otherwise there is no way to execute library transitions involving silos [18:46] ok. well now i know that the silos are configured that way :) [18:47] it can be turned off temporarily if need be, but usually better not to [18:47] thanks again [18:48] dobey: here's the chdist procedure: http://paste.ubuntu.com/11013254/ [18:48] you can then play around fairly arbitrarily with apt-get's resolver; you just can't actually install any packages, so say no to its prompt [18:50] ok [19:45] cjwatson: thanks for following that up, so i guess i was right originally, just needed time before rebuilding? How can i check that in the future? === salem_ is now known as _salem [20:34] slangasek, another ping on the vivid to wily transition question. I see that some projects (like lp:indicator-sound) have already moved to wily and have created 15.04 SRU branch, but most have not. Is this just something that needs to be transition on a case-by-case basis? [21:40] fginther: ok, so I finally found time to look up https://wiki.ubuntu.com/citrain/LandingProcess#Landing_your_change_to_Ubuntu_RTM [21:41] fginther: the policy shouldn't change, just the names; so projects can either have a single branch landing both places, or use separate branches === _salem is now known as salem_ [21:43] slangasek, cool, so if I understand correctly, the first action is to land the change into the development release (which is now wily). To me that implies that everything should be wily based and then use a separate branch only in cases where it is needed. [21:47] fginther, are you talking phone releases? if so everything needs to land i the vivid PPA as we won't release from wily [21:48] pmcgowan, that is what I'm talking about. [21:48] pmcgowan, will the upstream projects ignore wily at this time? [21:48] fginther, ok so we will pretty much land everythign both places from what I undestand [21:49] pmcgowan, ok, that clarifies things a bit [21:49] fginther, but landing to vivid will not be the exception, so sounds like single branch two landings [21:50] or whatever the project wants I suppose [21:50] pmcgowan, it's sounds like the preferred approach would be to build single branches against both wily and (vivid + overlay_PPA) [21:50] I suspect so [21:51] default case [21:51] pmcgowan, thanks [21:57] pmcgowan: is that a final decision? I mean, I guess that's one way I understood it, but I want to know if that's the guideline [21:57] Since I heard multiple conflicting things [21:59] sil2100, we need to keep wily up to date or we will suffer later, I am not sure how much testing we will devote to it [21:59] sil2100, but we release from vivid for the foreseeable future [22:04] hey sil2100, was wondering who should do the NM copy per slangasek's last email. I can do, but wasn't sure if I had permissions to do so? We also probably want to copy from vivid-security as opposed to vivid [22:05] ( I think as vivid-security and vivid-updates both have 4ubuntu15.1 vs 4ubuntu15 in vivid ) === salem_ is now known as _salem [22:12] awe: I can do it if anything, not sure if I'll be able to do the copy today still since it's past midnight, but I'll try [22:12] If not then I'll copy it tomorrow in the morning if you don't mind :) [22:15] sil2100, yea...no worries about doing it tomorrow, that'd be fine thanks [22:15] get some sleep1 [22:29] robru: hey, can you try assigning silo for line 69? [22:29] not really able to load the page to assign silos here [22:29] not sure if slow, but trying to load the configure page for more than 2 minutes already [22:33] fginther: I wonder if something changed in the lab that you might need vpn to access ci-train.ubuntu.com [23:16] robru: best is probably to follow the paste I showed so that you can dig through things with apt-get [23:16] robru: I don't have a straightforward script for you though [23:41]