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