[00:27] fginther: hey. looks like lp:ubuntuone-credentials/rtm-14.09 is building on vivid? can you change it to build on rtm? [00:41] well, i need to go. later [00:46] mandel: You around? The pause-click-updates silo passed, but there's still a remaining bug in that UI flow... sometimes the "Update" button goes directly to "Resume" instead of "Pause". This happened before the silo though, so the silo can still land. [00:47] (tap "Update", progress bar starts to move, button label changes to "Resume"... tap it, the label changes to "Pause", and then afterward everything works as intended) [00:47] ToyKeeper, I am indeed around, yes, I did notice that without the silo too, very ugly indeed... but I'll have to fix that in next iteration [00:48] ToyKeeper, we need to re-do most of the logic there and did not want to add a huge delta so late [00:48] dobey: building where? in a silo? [00:48] mandel: Okay, just wanted to make sure you were aware of it. :) [00:48] ToyKeeper, yes, AFAIK ken knows too [00:49] ToyKeeper, we are re-writting this little by little.. the last developer did a poor job [00:49] Sorry it took so long; has been a very busy day so far. [00:49] ToyKeeper, no problem, as long as it gets there :) [00:50] ToyKeeper, is 2 am here, do you mind setting it to QA approved? I think that is the only thing left, right? [00:50] * mandel is a little tired [00:50] mandel: Already done. -queuebot/#ubuntu-ci-eng- trainguards, ubuntu-rtm/landing-019: Packages built. Testing pass. QA signed off. You can publish. [00:50] \o/ [00:50] ToyKeeper, thx! Then I'm off to bed [00:51] mandel: yep, just hit publish on that [00:51] robru, thx! [00:51] mandel: you're welcome [02:10] === IMAGE 73 building (started: 20150122-02:10) === [02:18] dobey, oops, sorry about that. Fixed and retriggered the two MPs that had already executed [03:10] === IMAGE RTM 208 building (started: 20150122-03:10) === [03:30] === IMAGE 73 DONE (finished: 20150122-03:30) === [03:31] === changelog: http://people.canonical.com/~ogra/touch-image-stats/73.changes === [04:20] === IMAGE RTM 208 DONE (finished: 20150122-04:20) === [04:20] === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/208.changes === === marcusto_ is now known as marcustomlinson_ === marcustomlinson_ is now known as marcustomlinson === chihchun_afk is now known as chihchun [08:15] trainguards morning! can somebody review the packaging changes in silo 15? [08:15] trainguards sorry, nvm. i've just been told this change is on hold atm === Guest54456 is now known as Laney [09:19] sil2100, hey, how are you? [09:20] sil2100, random question for you :-) [09:20] sil2100, is http://people.canonical.com/~lzemczak/landing-team/ubuntu-rtm/ generated manually? just wondering why it's at 205 when current image is 208 [09:24] seb128: hey! It's generated automatically on my machine currently, but I think I need to increase the sync period ;) [09:24] seb128: should be all there now [09:25] sil2100, thanks [09:25] sil2100, just curious, why are some versions missing? [09:25] seb128: this usually means that the given image is a result of a tarball upload [09:25] k [09:26] do we have the details about those tarball changes somewhere? [09:26] For instance 206 was a new custom and 207 was a new device tarball [09:26] there should be mails about them [09:26] (not sure to which of the MLs ) [09:26] Sadly nowhere formalized... we and the testers usually get e-mails regarding the tarball changes [09:27] ogra_: yeah, but for instance cwayne1 sends it to a CC list, not a ML [09:27] Maybe we should think about changing that [09:27] we definitely should [09:35] ogra_, is there an easy way to reproduce the conditions for this? https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1382767 [09:35] Launchpad bug 1382767 in ubuntu-system-settings (Ubuntu RTM) "Bluetooth device with no name leads to details page with no header, no way to go back" [High,In progress] [09:36] ogra_: just in case, meeting! ;) Not much for you though! [09:36] brendand, i think the name detection was fixed at some point ... [09:36] sil2100, ooops, sorry [09:36] ogra_, hmmm, that makes it hard to verify :) [09:50] satoris: once the thumbnailer migrates I'll assign the sync silo for you [09:51] sil2100: ack, thanks. === psivaa_ changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping psivaa | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: none === Elleo_ is now known as Elleo [10:47] satoris: as for silo rtm/14 - just make sure that after you build the packages that they're the ones that you expect it to be [10:47] i.e. that it's the version from today [10:49] sil2100: ack, will check. [10:57] mzanetti, hey - i'm trying to test silo 16 for RTM [10:57] mzanetti, it's supposed to reduce the time before sending SIGSTOP [10:57] mzanetti, but i have to say it still feels like 3 seconds with the silo installed [11:14] ogra_: the ubuntu-sdk-qmake-extras is landed so the https://code.launchpad.net/~bzoltan/ubuntu-seeds/qmake_enablers/+merge/247148 is now safe to land too [11:20] mzanetti, ping [11:21] brendand: hey [11:22] is it? [11:22] let me check [11:22] mzanetti, i tested using video playback in browser and a game (pathwind) [11:23] mhm... reading the code it does set the timer to 1.5 secs [11:26] brendand: I'm installing the silo atm, to give it another try [11:31] brendand: hey, you sure you have installed the correct package? [11:31] brendand: seems the citrain tool fails to install the ppa [11:31] mzanetti, yeah [11:32] mzanetti, i just reflashed without the silo and it seems like it might be a bit quicker with the silo [11:32] brendand: I actually thought it was 5 secs before [11:33] reading the code I see that the interval was changed from 3 to 1.5 [11:33] mzanetti, yeah it feels like 5 secs without and 3 secs with [11:33] yeah [11:33] mzanetti, maybe there's some overhead which makes it feel a bit longer in reality [11:33] trainguards, could i have a silo for row 64? [11:33] yeah, loading the greeter and lockscreen images for sure does take some resources [11:34] (those images are dropped from ram when not needed) [11:34] Chipaca: on it [11:34] sil2100: cheers [11:36] sil2100: thanks === barry` is now known as barry === MacSlow is now known as MacSlow|lunch [12:25] is there something wrong with the builders? the build is getting killed :( [12:26] fatal error: unexpected signal during runtime execution [12:27] that's either something killing it explicitly, or possibly an OOM [12:27] In the PPA? [12:27] yep [12:28] https://launchpadlibrarian.net/195549325/buildlog_ubuntu-vivid-i386.ubuntu-push_0.67%2B15.04.20150122.1-0ubuntu1_FAILEDTOBUILD.txt.gz fwiw [12:28] that's i386; arm and amd64 built ok [12:28] armhf* :) [12:29] Chipaca: signal 0xb, that's SIGSEGV [12:29] not a builder problem [12:29] cjwatson: what is it then? [12:30] segmentation fault [12:30] mzanetti, yeah so with the silo it's about 3 seconds and without about 4.5 seconds [12:30] i.e. invalid memory access in your program [12:30] cjwatson: yes, but why? [12:30] mzanetti, exactly 1.5 seconds difference [12:30] you get to debug it, have fun [12:30] mzanetti, but quite difficult to tell apart without comparing side-by-side [12:30] any number of reasons for segfaults [12:30] brendand: yep, I've counted that too [12:31] mzanetti, hardly seems worth it :) [12:31] dunno... afaik there was a huge discussion about it [12:31] I wasn't part of it [12:31] * Chipaca grumbles [12:31] brendand: in any case, this silo does more [12:32] mzanetti, i guess it can't be lowered too much or will cause some issues [12:32] brendand: the important part is to inhibit phone deep sleep while the app is "suspending" (not the -ing, not -ed) [12:32] Chipaca: since it would appear to be in malloc, perhaps native code somewhere has corrupted the malloc arena by way of a buffer overflow or similar. valgrind may help [12:32] narf... I really should re-read stuff before I press enter :D [12:32] brendand: the important part is to inhibit phone deep sleep while the app is "suspending" (note the -ing, not -ed) [12:33] forgetting one "e" kinda changes the whole thing :) [12:34] sil2100: please reconfig silo rtm/001, row 32 for me. We've added a telephony branch that should go together with the unity branch [12:34] cjwatson: yeah ... but that's golang, not me, doing the malloc [12:34] sil2100: I'll be syncing with boiko in order to queue telephony landings properly [12:34] cjwatson: that is, it's not _my_ native code :) [12:34] Chipaca: I know, but this kind of fault can cause a crash distant from the cause [12:35] cjwatson: and i've never seen it in testing here, hence why i suspected the builders [12:35] yeah [12:35] Chipaca: prior corruption in the malloc arena might only cause a crash somewhat later. that's why you use valgrind [12:35] Chipaca: and it can be somewhat non-deterministic. this is very unlikely to be a builder fault, you just need to look harder :) [12:36] Chipaca: I can assure you that we don't go around randomly SIGSEGVing stuff on builders for the fun of it [12:36] and OOMs don't cause SIGSEGV [12:36] * Chipaca looks into using valgrind with go [12:36] (well, not the OOM killer at any rate, of course if you get NULL back from malloc and fail to handle it then that could be a problem, but I doubt that's the case here; the builders have plenty of memory) [12:36] cjwatson: yeah, i hadn't realised it was a sigsegv when i asked at start [12:39] mzanetti: ok [12:44] cjwatson: go doesn't play well with valgrind at all (dies with rt_sigaction nonesense) [12:45] ta [12:47] yw! [12:54] sil2100: have you seen ogra_ today? [12:55] bzoltan_, i'm working nearly fulltime on snappy nowadays, please be patient, i'll try to get to it before EOW [12:55] bzoltan_: yes, he's here [12:55] ^ ;) [12:56] ogra_: No pressure :) I just need this package in the chroots very badly. [12:56] well, any core-dev can help you [12:56] sil2100: is there an easy way to try a rebuild of a package from vivid? getting a weird error, and realising it hasn't been rebuilt since some rather big changes elsewhere in the stack. === alan_g is now known as alan_g|lunch === MacSlow|lunch is now known as MacSlow [13:09] Chipaca: you mean, like a no-change rebuild for one architecture? [13:09] sil2100: changed the mp to a dummy one, reconfigured silo, forced rebuild worked for me. hope i'm not breaking anythign. [13:10] sil2100: both 32 bit architectures actually [13:10] there might be a problem with go in vivid on 32 bits [13:10] we'll see [13:10] there also might be a bug in our code, but if so it's a nasty one [13:10] :) [13:10] In this case it should be ok if you just want to rebuild the existing package without any new changes ;) [13:11] yeah, just to establish whether it's sane [13:11] before i go digging :) [13:18] so, ubuntu-push FTBFS on 32-bit x86 (at least) on vivid [13:18] and now what? [13:18] :((( [13:19] * Chipaca gives up and goes to live on a farm [13:20] Chipaca: when was the last time ubuntu-push was built in vivid? [13:20] sil2100: the day before golang 1.3 hit the archive [13:20] We need to check which dependencies changed and trying to triage what could be wrong [13:20] decemebr 11th [13:20] geh [13:20] indeedly [13:28] sil2100: I've approved that now ^. sorry, missed it before [13:30] mzanetti: uugh, I see some problems with publishing, one moment [13:30] err, wat? [13:31] Yeah... not sure what's wrong, need to dig deeper [13:32] ok. let me know if I can help [13:41] :| [13:42] Ok, the train again ate a whole directory, and with the new publisher just a watch-only rebuild doesn't help [13:42] And since I don't have access to the machine working around it would be the most painful thing ever [13:42] So let me try pushing it to the archive manually [13:43] Or wait, geh [13:46] mzanetti: ok, let me do all the merges and releases manually, since the only other way would be to re-built both packages [13:47] sil2100: did this break because of the not top-approved branch? [13:47] mzanetti: no, I doubt it, not sure what happened - something in the backend went really wrong [13:48] ok [13:50] Ah, I think I see the possible problem ;/ [13:51] mzanetti: so, it seems it wasn't the backend that broke it - you did a build once and aborted it half way when it was preparing the package, which is really really dangerous [13:51] mzanetti: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-016-1-build/75/console [13:52] ok [13:52] mzanetti: in this place it started branching the bzr qtmir branch but couldn't finish since it was aborted, and CI Train completely lost track of its state here [13:52] yes, I did that, I clicked build and noticed I forgot to reconfig first [13:52] ok, will be more careful with that [13:52] mzanetti: you should only abort the build job when the packages are created and pushed to the PPA, when it's waiting on them to finish building [13:52] ack [13:53] Since we can't make sure that we can abort at any place sadly ;) [13:53] Ok, anyway, let me try doing stuff manually === alan_g|lunch is now known as alan_g [14:02] cihelp: http://s-jenkins.ubuntu-ci:8080/job/calendar-app-click/ seems to build two clicks each time a merge lands. which is wrong/odd. [14:06] trainguards: can I have a silo for line 68, please? [14:07] oSoMoN: sure! At lunch now, but let me try quicky assigning [14:07] sil2100, no rush, have your lunch first! [14:08] popey, looking === psivaa_ changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: none [14:20] fginther: thanks [14:22] popey, it's fixed now. There was an older .click left in an old build directory. It just needed a proper cleanup. [14:22] haha, ok :) [14:22] thanks [14:36] sil2100: could you switch that silo over to rtm? i'd like to test this build against the rtm build deps [14:36] sil2100: this is a test build, not something for any archive [14:39] Chipaca: let me get you another test silo then [14:39] Since switching to rtm would mean I would have to free this one up and assign a new one [14:41] Chipaca: ok, created a new row - the other rtm row you have let's leave for the right RTM release [14:44] rsalveti, what's up with silo 18, the bluetooth agent stuff? [14:46] sil2100: thanks [14:47] fginther: i feel bad bothering you again...but we are seeing between 50% and 100% of building before failing for reasons unrelated to build or tests [14:48] e.g. http://jenkins.qa.ubuntu.com/job/mir-clang-vivid-amd64-build/1007/console [14:48] failures on cloud-worker-10 and cloud-worker-11 [14:49] rsalveti, i have other branches to land, can i pass by your's ? [14:50] ev: just a heads up i'm pestering francis again ^ [14:51] kgunn: cihelp is preferable. We don't have a vanguard in this slot today because Ursula is on holibobs [14:53] right [15:03] kgunn, I or someone from the team will have a look shortly. I didn't specifically make any modifications for mir-clang-vivid-amd64-build yesterday, but will have a closer look at this and the other mir jobs today [15:07] brendand, why is silo 4 blocked? do you need anything from jgdx or I? [15:08] kenvandine, there seems to be an issue with the manual operator selection [15:08] kenvandine, jgdx is looking at it [15:08] brendand, ok, thanks [15:08] as long as someone is on it ;) [15:34] :D [15:35] sil2100: could I get a silo for ^ [15:35] ricmm: sure! [15:36] ricmm: assigning, but it seems lool has platform-api also in silo 22 already [15:39] trainguards: can silo 14 be published, please? [15:43] sil2100: thank you [15:43] oSoMoN: sure, one moment! [15:44] mzanetti: ok, all bits landed manually - apologies if there are any mistakes [15:44] sil2100: ack, will check. thanks a lot [15:45] mzanetti: I already noticed a small typo in my commit-message, but I would call that a no-issue ;p [15:45] (sorry about that) [15:51] kenvandine: eek! [15:51] kenvandine: you need to rebuild silo 29 it seems [15:51] kenvandine: someone released something in the meantime from what CI Train says [15:51] what? [15:51] sil2100: don't worry about that :D [15:51] * kenvandine wonders how that could happen [15:52] sil2100, where does it say that? [15:52] kenvandine: ^ [15:52] sil2100, it uploaded fine [15:52] Ah [15:52] kenvandine: ok! I know what happened! [15:52] kenvandine: I pushed publish after you published the silo yourself ;) [15:53] kenvandine: sorry, forgot that you do all your publishing yourself! [15:53] hehe [15:53] yeah... sorry :) [15:53] i wish that status updated quicker... [15:53] kenvandine: anyway, nevermind me ;p Apologies from my side, simply forgot about this! [15:53] fortunately no harm can be done there :) [15:54] rsalveti, i'll rebuild 18 after this is merged [15:54] rsalveti, i went ahead and passed you :) === mvo_ is now known as mvo [16:01] sil2100: ah thanks for the reminder, I'll push this === chihchun is now known as chihchun_afk [16:15] kenvandine, do you know a way to test https://bugs.launchpad.net/ubuntu/+source/content-hub/+bug/1383732 ? [16:15] Launchpad bug 1383732 in Canonical System Image "E-book content type" [Undecided,In progress] [16:17] bfiller, ^^ mind passing on what Elleo gave you to brendand? [16:17] brendand: it's in the test plan for content-hub, linked in the sheet [16:18] even better :) [16:31] ogra_: hey, do you have time to seed that apparmor extension today? [16:33] cihelp : I need to switch the development focus of calculator to another branch, what steps are required to keep jenkins working? [16:34] rpadovani, we usually just need to know the branch name [16:35] fginther, lp:ubuntu-calculator-app: the actual focus is on trunk, we want to switch to reboot (lp:ubuntu-calculator-app/reboot) [16:38] rpadovani, that should be all we need, someone should be able to get this setup today [16:39] fginther, that's cool, thanks! Will you take care to change it on LP too or will you ping me and I'll change it? [16:39] rpadovani, hold on [16:40] rpadovani, switching branches around in LP is the project maintainer's responsibility... but it sounds like you want to completely switch lp:ubuntu-calculator-app to point to the reboot branch? [16:42] rpadovani, yes, it looks like I missunderstood [16:42] fginther, yes, isn't this what happen when you change the development focus on lp? [16:42] fginther, my only worry is about jenkins, it will need to take from lp:ubuntu-calculator-app and not lp:ubuntu-calculator-app/reboot anynore [16:42] *anymore [16:43] rpadovani, sorry about that. Yes, in this case, we just need to disable the jobs that look at the reboot branch [16:49] fginther, ok, great, so could I go or do I wait your ping? [16:50] trainguards: row 74 would be ready for a silo, but not in a hurry with it. so whenever some of you has some free minute [16:51] rpadovani, it's safe to switch now. I've disable the jobs so as not to result in double builds [16:52] mzanetti: o/ [16:53] thanks :) [16:54] fginther, thanks, done! [16:59] bfiller, thanks for silo 2 [17:03] kgunn, I've also moved the mir-clang and mir-android builds to the larger nodes. The clang job appeared to be hitting resource limitations [17:03] alan_g: camako ^ fyi [17:03] kgunn, will keep monitoring those larger nodes to make sure there is enough to go around [17:05] fginther: thanks [17:16] sil2100: I'm done with silo ubuntu-rtm/landing-015, thank you [17:19] Chipaca: excellent, let me free it up [17:19] confirmed the FTBFS is vivid-only, fwiw [17:30] sil2100: also if you want to clean up landing-016 (from row 64), i'm not going to use it [17:36] trainguards, could i have a silo for row 64 please? [17:36] o/ [17:36] *65* [17:36] sil2100: hi. I meant row 65; 64 is the one to nuke :) [17:36] because, ftbfs on vivid :( [17:37] Chipaca: hmmm, but we'll have to get this somehow to vivid anyway... [17:37] sil2100: yes, of course [17:37] One moment please, still OTP [17:37] ;) [17:37] sil2100: but for that we need to determine what in all that's changed in vivid has triggered the FTBFS (biggest candidate being golang 1.3) [17:51] robru: ping! [17:52] Chipaca: anyway, I'll leave this vivid silo assigned so that we don't forget that it needs to land for vivid as well [17:52] sil2100: ok ... i won't forget though, because it's already on our automatically-tested development "trunk", and that's all that gets pushed to vivid [17:53] sil2100: so as you wish. If you run short of silos, nuke it :) [17:54] Chipaca: yeah, let me leave a comment on that one ;) [18:04] sil2100: can I sync a package from vivid-proposed? [18:06] sergiusens: that's a good question - sadly I think not but let me do a quick check since I think we're copying it from the release pocket directly [18:06] sil2100: can you do a manual dput to a silo then? [18:06] sil2100: my problem is similar to Chipaca's but different, as I'm using gcc-go [18:07] sil2100: and the new gcc-go requires me to make packaging changes that will be bad for ubuntu-rtm as it doesn't have the latest gcc-go [18:07] sil2100: oh well, I guess I can setup an rtm branch too [18:07] sergiusens: yeah, if I confirm it cannot be done I'll do that for you then, will keep you updated [18:08] But an rtm branch might be a better solution in case this is a long-standing problem [18:08] sil2100: I don't expect ubuntu-rtm to survive that long :-P [18:08] hah ;) [18:08] sil2100: empty MP commits work fine still, right? [18:09] sergiusens: yeah [18:09] sil2100: ok, I'll give that a go [18:23] sergiusens: huh, it seems that it should be possible to do a sync from proposed [18:23] sil2100: hah, I just got the above setup [18:24] sil2100: line 58; but we can try do the sync [18:24] sergiusens: CI Train just uses getPublishedSources() without specifying the pocket argument, and in this case LP just returns everything [18:24] I don't have 100% guarantee, but it should just work since that's the only thing I see [18:24] sil2100: oh, needs code changes? [18:24] sil2100: then lets not experiment today :-) [18:24] No no, should just work ;) [18:24] sil2100: oh, what's the syntax? [18:24] Just saying that I can't say for 100% [18:25] sil2100: I already have everything staged the other way around, so it's easy to revert [18:25] Try simply writing in the source package name list: 'sync:ubuntu,vivid the_package_name' (nuntium I suppose?) [18:25] sil2100: let's give it a try [18:25] And at least we'll know for sure if this works ;) [18:25] sil2100: yup, nuntium, and it will sync from proposed? crazy :-) [18:25] Yeah ;p I think no one thought about the case that something might be stuck in proposed ;) [18:26] sil2100: if you want to setup line 58 we will know :-) [18:26] sergiusens: assigning, let's hope it works - at least there would be less additional work for everyone [18:26] At least for now [18:27] bfiller: could you top-approve https://code.launchpad.net/~renatofilho/address-book-app/fix-1411323-rtm/+merge/247142 ? [18:28] sil2100: done [18:29] sil2100: at least it picked the right one :-) [18:30] sergiusens: oh, so it works? ;) [18:30] bfiller: thanks! [18:40] sil2100: I'll need to sync in a package dep (build time only) [18:41] sergiusens: ah, missing from the rtm archive? Or need a different version? [18:41] sil2100: missing from the rtm archive [18:41] sergiusens: ok, wait, what package do you need? We'll just copy it over [18:41] sil2100: golang-go-flags-dev [18:42] thanks [18:44] robru, can you please land vivid silo 1? [18:44] jhodapp: publishing o/ [18:44] thanks sil2100 [18:45] jhodapp: robru is sick today, cyphermox will be your US trainguard for today :) [18:45] awesome, good to know [18:45] (once I EOD) [18:45] howdy [18:46] sil2100: did you make the copy though? [18:46] sergiusens: slangasek is copying it now, since we need an archive admin for things like this [18:46] Should be in the archive soon [18:46] sil2100: thanks! [18:47] sil2100: I give you permission to leave then :-P LOL [18:47] enjoy [18:47] Hah! No worries, still a few e-mails to write ;) [18:47] sil2100: in case you didn't notice, I fixed the emulator last night [18:48] sergiusens: thanks! Noticed that, I just finished mentioning it in the landing e-mail even [18:48] Makes things much easier for QA [18:49] sergiusens: ok, looks good -> https://launchpad.net/ubuntu-rtm/+source/golang-go-flags [18:49] So far at least [19:01] sil2100: so should I retrigger from ci train or someone else from the ppa itself? [19:01] sergiusens: hm, it's best if I simply rebuild it in the PPA [19:01] We'll save some resources this way [19:01] One moment [19:01] sergiusens: I'll add this 'rebuild in PPA' feature to the train once we have power of redeploying it once again [19:04] cyphermox: ok, I need to go EOD now really as it's latish here, leaving the train in your hands [19:04] sergiusens: rebuilt and it succeeded \o/ [19:04] alright [19:04] sil2100: thanks [19:04] any thing I need to be aware of before I break things? [19:04] cyphermox: just don't get too much frustrated if things start blowing up ;) The train does that [19:04] No no, all is ok [19:04] ack [19:05] anything that absolutely must not be landed? [19:07] No, QA makes sure to only sign-off things that are wanted in ubuntu-rtm [19:07] So just land anything that they +1 [19:07] No breakages in sight [19:08] Ok, see you tomorrow and thanks again! [19:08] o/ [19:12] ricmm, reviewed your MR, 2 minor fixes needed [19:34] cyphermox: may I ask you for a silo for line 74? [20:01] trainguards can someone publish rtm silo3 [20:02] sure [20:05] ricmm: need me to rebuild silo 8? [20:30] cyphermox: yes please something weird happened to it [20:30] or I can do it myself I guess [20:30] pushing buttons... [20:31] I think it should just work with a retry [20:55] thanks queuebot [21:02] cyphermox: actually...i see mzanetti has a vivid silo, i'll hop in that one, but it'll need a reconfig [21:02] too late ;) [21:02] well, not too late [21:02] which silo is that? [21:03] 14? [21:03] cyphermox: yes [21:03] trainguards: just testing my highlight [21:03] d'oh. [21:04] mzanetti: oh my..you're still on [21:04] kgunn: just let me know when you're ready for the reconfig [21:04] mzanetti: just fyi, gonna dump josh's screen shot fixes in there (usc included) [21:04] cyphermox: yep...ready [21:04] ack [21:07] kgunn: did someone review that? [21:07] mzanetti: usc branch yeah.... camako and kdub [21:08] kgunn: looking into the unity branch I'd say there is something to fix still... but should be easy (no architectural thing). lemme look if I can find him [21:08] yeah josh is on [21:50] rsalveti: kenvandine: have you had a chance to test and confirm my agent fixes? [21:50] cyphermox, i don't have a way to test it, i think rsalveti was supposed to do that [21:50] I got a bunch of failures, which were also happening in pure vivid [21:50] so couldn't really test that silo [21:50]