[00:00] <sergiusens> robru: the superseeding in the MP was because I merged trunk one MP into the other as they diverged between themselves
[00:04] <sergiusens> robru: if I switch the mp in the spreadsheet, what else do i need to do?
[00:07] <robru> sergiusens: if you change the MP, you need to run 'Recon' on the dashboard. If you add a new MP that brings in a new source package, then you need *me* to re-prepare the silo
[00:09] <sergiusens> robru: it's a new mp; but from the same branch
[00:09] <sergiusens> robru: adding a prereq so the code looks nice sadly requieres superseeding
[00:10] <robru> don't worry about that, you can just 'recon'fig it
[00:10] <sergiusens> robru: great
[00:11] <sergiusens> robru: ok, I retriggered the reconfig for that one and just finished testing the rtm one as well
[00:12] <robru> sweet
[00:15] <sergiusens> also updated the testplan with the powerd changes
[00:16] <sergiusens> will be back in a bit
[02:05] <imgbot> [02:21] <sergiusens> robru: so what I mentioned above is ready to handover to whoever needs to look into it (publishing or qa)
[02:21] <sergiusens> night
[02:23] <robru> sergiusens: thanks! You mean the rtm silo is ready for qa?
[02:24] <robru> ToyKeeper: ^^ rtm-5 for you
[03:35] <imgbot> [03:35] <imgbot> [03:46] <Mirv> mornings
[06:58] <mardy> Mirv: hi! If a package which I have in a silo requires rebuilding of other packages, should I put them in the silo as well?
[06:58] <Mirv> mardy: yes, then the rebuilt packages will be landed together with the actual changes
[06:59] <Mirv> mardy: you can do an empty MP against the other package's trunk and include that empty MP in your landing
[06:59] <mardy> Mirv: OK, thanks, will do like this
[07:43] <tvoss> sil2100, hey there :)
[07:43] <sil2100> Hey
[07:43] <tvoss> sil2100, line31 on the spreadsheet is a bit weird
[07:43] <tvoss> sil2100, packages are in silo 5
[07:43] <tvoss> sil2100, and I would like to set "testing done" to ture
[07:43] <tvoss> true
[07:44] <sil2100> And you can't?
[07:46] <sil2100> tvoss: hm, ok, let me fix that up
[07:47] <sil2100> tvoss: so, somehow this data vanished from the spreadsheet, but I re-added it now
[07:57] <brendand> tvoss, hey - i'm back from holidays - did you get all the needed info on the location issue?
[07:57] <tvoss> brendand, I *think* so :)
[07:59] <sil2100> Mirv: are you waiting on something on silo 008?
[07:59] <sil2100> :)
[08:00] <sil2100> Oh, I see a new soname
[08:01] <tvoss> brendand, and welcome back
[08:03] <Mirv> sil2100: 008? 014 would need acking, but I thought you as a MOTU could probably do it :)
[08:03] <Mirv> since mediascanner2 and the scope are in universe
[08:03] <sil2100> Ah! 14 right ;)
[08:13] <robru> sil2100: lots of problems with the spreadsheet losing state today, had to copy dashboard back to spreadsheet several times. Keep an eye for that
[08:13] <sil2100> robru: ok, thanks for the notice... google *sighs*
[08:15] <robru> sil2100: also queuebot completely puked on the spreadsheet today. I managed to reproduce the issue locally but it's totally bizarre, no idea why the code isn't working. Stephane had to disable it until i can fix it, so you'll get Jenkins silo pings but you won't get spreadsheet pings
[08:16] <robru> sil2100: have fun! I'm off to bed ;-)
[08:16] <sil2100> huh
[08:16] <sil2100> Something wrong with csv then?
[08:16] <sil2100> Or unrelated?
[08:17] <sil2100> Crazy stuff!
[08:17] <sil2100> robru: goodnight!
[08:17] <robru> sil2100: nope, csv is fine. Just the data structure that queuebot uses to track what pings it pinged is being wonky and it's re pinging the same ping over again every 30 seconds, total channel spam
[08:19] <robru> Ta ta!
[08:23] <brendand> ogra_, a quick question about the incident that happened last week with the regression in local scopes
[08:23] <brendand> ogra_, were the dependencies removed by the silo itself, or by another silo?
[08:23] <ogra_> brendand, by the silo itself ... the packages dropped the dep
[08:24] <sil2100> brendand, ogra_: remember that the regression was not caused by dropped dependencies
[08:24] <ogra_> sure
[08:24] <brendand> sil2100, oh?
[08:24] <sil2100> brendand, ogra_: we confirmed that reinstalling the deps didn't help
[08:24] <sil2100> brendand, ogra_: the dropped deps broke music-app I think?
[08:24] <ogra_> well, it helped fpor the thumbnailer
[08:24] <sil2100> But not the scope
[08:24] <ogra_> yeah
[08:25] <brendand> ok - that complicates things
[08:25] <sil2100> The scope was b0rked by an unity-scopes-api and unity-scopes-shell landing
[08:25] <sil2100> Which we had to revert to get it working :)
[08:25] <ogra_> the thumbnailer seems to use something in the backend for its https requests that seems to realy on curl-nss
[08:25] <ogra_> *rely
[08:26] <ogra_> i havent dug to the bottom of this, but there are https requests that dont get through with the dep dropped
[08:26] <ogra_> it was definitely not an issue for the scopes themselves
[08:27] <ogra_> (the dep seems to be missing on a very low level somewhere(
[08:27] <brendand> sil2100, oh that got reverted?
[08:28] <ogra_> yes, in the next image
[08:28] <brendand> i'd like to verify that i should have seen it when installing that silo
[08:28] <ogra_> you wouldnt
[08:28] <brendand> ogra_, why not?
[08:28] <ogra_> unless you would have manually purged the dropped package
[08:29] <brendand> ogra_, but you just said it wasn't because of the dropped package?
[08:30] <sil2100> It wasn't related to leftover packages
[08:30] <ogra_> music app breakage was and i'm not actually sure you would see any artwork with the thumbnailer not working
[08:30] <sil2100> Yeah, music-app breakage you would see, yes
[08:30] <sil2100> I mean
[08:30] <sil2100> You wouldn't see the music-app breakage, heh
[08:30] <sil2100> Anyway, after installing the silo you should have seen the scope broken
[08:31] <sil2100> If installing
[08:31] <Mirv> sil2100: we're missing only you :)
[08:47] <tvoss> trainguards, could I have a silo for line 45?
[08:50] <Mirv> tvoss: you haven't selected the target distro
[09:02] <sergiusens> trainguards fwiw http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-001 is in testing passed state on the spreadsheet
[09:03] <sergiusens> and http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=landing-005 is in qa sign off mode since last night
[09:03] <sil2100> sergiusens: oh! Right, I didn't see it changing as there seem to be some issues
[09:03] <sergiusens> sil2100: yeah, I told robru last night; but it seems he missed or forgot :-)
[09:04] <sil2100> With the spreadsheet
[09:04] <sil2100> sergiusens: aaaand I see why we don't see it, your landing got erased from the spreadsheet :| We seem to be having issues with entries disappearing since yesterday
[09:05] <sil2100> Let me re-add that and publish
[09:05] <sergiusens> har har
[09:05] <Mirv> sergiusens: ah, a watch only would have helped to bring the colors right
[09:05] <Mirv> sil2100: hmm, the line 26 looks good to me
[09:05] <Mirv> other than there has been a reconfigure after last build
[09:06] <sil2100> hm, right, let me dig in further
[09:06] <Mirv> oh, I started that watch only build, usually the quickest solution unless there's something fishy
[09:07] <sergiusens> Mirv: I reconfigured on robru's suggestion; since I merged one of the branches into the other to avoid a merge conflict and since I force myself to look at neat MPs I added a prereq to not get the full contents of what I just merged into view
[09:07] <Mirv> looking good
[09:07] <Mirv> sergiusens: but you didn't then rebuild after that, would that have been required?
[09:07] <sergiusens> Mirv: no, the branches didn't change
[09:07] <sergiusens> Mirv: only the "view"
[09:07] <Mirv> oh, ok..
[09:08] <sergiusens> Mirv: adding a prereq sadly forces you to rehash the MP
[09:08] <Mirv> yeah, now fixed
[09:08] <Mirv> sil2100: do you want to publish it or shall I?
[09:09] <sergiusens> Mirv: ok, now I see; reconf and build watch
[09:09] <sergiusens> thanks
[09:09] <sergiusens> Mirv: sil2100 not sure if it's worth to get the qa sign off on silo 5 for rtm first though
[09:10] <sergiusens> these are all new procedures :P
[09:11] <sil2100> sergiusens: we were thinking about that too! QA still needs to exactly define all the processes here, but I guess we can publish for ubuntu anyway ;) In case it fails verification for RTM then, well, no deal - the next upload with the 'fix' will upload both versions ;p
[09:13] <sergiusens> sil2100: ok, just keep in mind I piggybacked things that "missed the sync"; the sign off would take care of that landing correcly
[09:15] <sil2100> brendand: do you know who we have available in our timezone for QA RTM sign-off?
[09:15] <sil2100> brendand: are you one of the people assigned for that?
[09:16] <Mirv> sil2100: now I wish I'd have started that MOTU process earlier.. landing-012 looks also like reviewable by you
[09:16] <brendand> sil2100, yep
[09:16] <sil2100> Mirv: when will your acceptance meeting happen? Next week?
[09:16] <sergiusens> Mirv: hehe, I have that on my task list as well; ppu still doesn't work on the train :-)
[09:17] <Mirv> sil2100: month! yesterday was the previous suitable for me, but a) it was too quick b) the meeting didn't happen. the next one doesn't suit for me, and the next one is four weeks from now.
[09:18] <bzoltan> Mirv: sil2100: Would you please reconfigure the silo9? I have added there the browser fix branch.
[09:18] <Mirv> but oh well, only myself to blame anyhow
[09:18] <Mirv> bzoltan: ok
[09:18] <bzoltan> Mirv: thanks
[09:18] <sil2100> Mirv: could you? Thanks :)
[09:18]  * sil2100 assigns a silo for tvoss 
[09:18] <tvoss> sil2100, thank you
[09:18] <Mirv> bzoltan: and cool, for the browser fix
[09:19] <bzoltan> Mirv: yes, and once that fix is verified we can land the UITK
[09:20] <Mirv> dbarth__: bzoltan: note that you've conflicting silos now  (landing-009 and landing-007), but since the OA landing doesn't build UITK will most probably go in first and then the webbrowser in OA landing will need to be rebult
[09:20] <Mirv> bzoltan: reconfigured
[09:25] <brendand> sil2100, agh why can't i reproduce the problem :/
[09:25] <brendand> sil2100, music_app right?
[09:25] <brendand> sil2100, btw which silo am i being begged to QA?
[09:25] <sergiusens> brendand: maybe you have the right subset of music ? :-P
[09:26] <sergiusens> as in music collection
[09:26] <brendand> sergiusens, the device is just flashed
[09:26] <brendand> sergiusens, no SD card here either
[09:26] <sergiusens> brendand: yeah, I mean; maybe your music collection has album art embedded
[09:26] <sergiusens> so there are no network fetch needs
[09:27] <brendand> sergiusens, i just have what the test installs
[09:27] <brendand> sergiusens, there's no music of my own on here
[09:27] <sergiusens> ah, not sure if that triggers it
[09:27] <sergiusens> but if ci failed atm, then it should
[09:28] <sergiusens> or maybe someone sneaked in the fix in some other package and the only way to reliably reproduce is to go back to the image where it was seen
[09:33] <sil2100> brendand: strange, I'm flashing the latest of the latest
[09:33] <sil2100> And will make sure it's also broken there
[09:37] <brendand> sil2100, so who wants a silo?
[09:37] <brendand> first come first served
[09:37] <brendand> (silo tested)
[09:38] <sil2100> brendand: I think sergiusens has a silo that needs QA sign-off
[09:38] <sil2100> (as per http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q= )
[09:39] <sil2100> brendand: there's bfiller as well, but I guess he'll be around later
[09:39] <sil2100> So Sergio's can go first
[09:40] <sergiusens> let's call it ralsina's ;-)
[09:40] <sergiusens> I just made a dbus service there :-P
[09:40] <brendand> sergiusens, do you know where the wiki page with details on how to install powerd is?
[09:40] <brendand> i'll need that before starting
[09:40] <sergiusens> brendand: on mako it was just apt get
[09:41] <sergiusens> brendand: on krillin I found it to be complicated
[09:41] <sergiusens> brendand: and not really, that's not really part of what we want added, but something that "missed the sync"
[09:42] <ogra_> sergiusens, what makes it more complicated ? the bind mounts ?
[09:42] <sergiusens> brendand: should be the same as installing lxc
[09:43] <sergiusens> ogra_: the powerd profile is bind mounted on krillin
[09:43] <ogra_> iirc krillin bind mounts the configs
[09:43] <ogra_> yeah
[09:43] <sergiusens> s/lxc/lcx-android-config
[09:43] <ogra_> that will hit us wiath way more packaged
[09:43] <sergiusens> we really need image builds :-)
[09:43] <ogra_> once more configs move into the device tarball
[09:43] <brendand> sergiusens, i was testing another silo for rsalveti i think and had to follow some instructions to make powerd install
[09:44] <ogra_> which in turn means that the config interfaces may never change for any of these packages
[09:44] <brendand> sergiusens, that was on mako too
[09:44] <brendand> sergiusens, i'll see if i hit it now
[09:44] <ogra_> else the rootfs will stop working with the device tarball
[09:44] <sergiusens> ogra_: yup
[09:44] <sergiusens> brendand: this is what I do https://gist.github.com/sergiusens/17d11843b9605feeb6bf
[09:44] <brendand> sergiusens, how come there are no MP links on the silo dashboard?
[09:45] <brendand> sergiusens, oh yeah it was something like that
[09:45] <sergiusens> brendand: this will hit a bunch of packages as well
[09:45] <sergiusens> system ones
[09:45] <brendand> nobodies looked at my add-apt-repository bug still
[09:47] <sergiusens> brendand: I consider that a foundations bug :-P
[09:49] <brendand> sergiusens, do you have a test plan for accounts-polld?
[09:50] <sergiusens> brendand: it's in the list
[09:50] <sergiusens> or not?
[09:50] <sergiusens> i thought it was
[09:50] <sergiusens> at least in the one we created; not sure how sil2100 does the line copy for rtm
[09:50] <brendand> sergiusens, got it
[09:50]  * sergiusens checks the spreadsheet he hates
[09:51]  * sil2100 hates it in a very similar way
[09:51] <sergiusens> sil2100: it's nothing personal ;-)
[09:51] <sergiusens> I just don't like it :)
[09:51] <brendand> sergiusens, listing non-existent test plans :) https://wiki.ubuntu.com/Process/Merges/TestPlan/account-polld
[09:51] <brendand> sergiusens, that's a new low :P
[09:51] <sil2100> And I personally hate it ;p
[09:52] <sergiusens> brendand: add an s to TestPlan's'
[09:52] <sergiusens> or remove it
[09:52] <brendand> sergiusens, ah
[09:52] <sergiusens> brendand: huge discrepancy there, not sure how it started
[09:52] <sergiusens> I hope someone in QA gets tht sorted
[09:52] <sil2100> I even proposed us trying to get rid of the spreadsheet
[09:53] <sergiusens> brendand: that's why I was hoping for the impossible task of having them "auto linked" fro the projects
[09:53] <brendand> sergiusens, why should we - the majority are under TestPlan
[09:53] <brendand> sergiusens, any others are just typos
[09:53] <sil2100> But since the Airline thought close back then, we decided not to waste time on that
[09:53] <mardy> asac: hi! The Jenkins coverage rules for signon are wrong; can I talk about them to you? https://jenkins.qa.ubuntu.com/job/signon-utopic-amd64-ci/4/consoleFull
[09:53] <dbarth__> Mirv: ack
[09:59] <sergiusens> brendand: well the original communication was with an 's' https://docs.google.com/a/canonical.com/presentation/d/1LiDK3nVWUFKPbOCOPQEWdpXuTVpIQNU2SWjTiQaIGxE/edit#slide=id.g258bded9d_0110
[09:59] <asac> mardy: me?
[09:59] <asac> mardy: dont even know this feature of our jenkins job. would suggest to wait for fginther or someone else from cihelp who knows about this
[09:59] <sergiusens> brendand: and the template is also under /TestPlans/ https://wiki.ubuntu.com/Process/Merges/TestPlans/Template?action=show&redirect=Process%2FMerges%2FTestPlans%2FCommon
[10:00] <brendand> sergiusens, ugh
[10:00] <sergiusens> brendand: so while the majority have no 's', they are the typos ;-)
[10:00] <sergiusens> and it's all thanks to https://lists.launchpad.net/ubuntu-phone/msg06307.html
[10:01] <brendand> sergiusens, UGH
[10:01] <brendand> FML
[10:02] <brendand> sergiusens, well as long as the links are correct on the spreadsheet that's the best we can do
[10:02] <sil2100> Curse you Ted!
[10:02] <sergiusens> brendand: yeah, adding the links to a spreadsheet is not really an exiting task :-P
[10:02] <sergiusens> exciting even
[10:03] <brendand> sergiusens, Errors were encountered while processing:
[10:03] <brendand>  /var/cache/apt/archives/powerd_0.16+14.10.20140819-0ubuntu1~rtm1_armhf.deb
[10:03] <brendand> E: Sub-process /usr/bin/dpkg returned an error code (1)
[10:04] <sergiusens> brendand: yeah I dpkg-deb -x'ed it
[10:04] <sergiusens> ogra_: ^^
[10:04] <sergiusens> any idea what's up with that?
[10:04] <brendand> sergiusens, ? what you mean you removed it?
[10:05] <ogra_> not with that little information, no
[10:05] <ogra_> pastebin the full log with the actual error :)
[10:05] <sergiusens> ogra_: the postinst or preinst script does some default init checks
[10:05] <sergiusens> brendand: full pastebin for ogra_?
[10:05] <davmor2> morning all
[10:06] <ogra_> ah, you would have to deny that somehow ... we used to do that via policy-rc.d
[10:06] <ogra_> but i think there is a new method
[10:06] <ogra_> (that i dont know)
[10:06] <sergiusens> ogra_: isn't that autogenerated trough the packaging though?
[10:07] <sergiusens> through
[10:07] <ogra_> well, what does it call ?
[10:08] <ogra_> ah, i see
[10:08] <ogra_> update-rc.d and invoke-rc.d
[10:08] <ogra_> that comes from packaging, yes
[10:08] <ogra_> dh_installinit iirc
[10:08] <sergiusens> ogra_: so there's not a fun way to avoid this and I bet it doesn't happen during image build
[10:09] <sergiusens> ogra_: which will probably just confuse qa
[10:09] <ogra_> it doesnt happen during image build because policy-rc.d gets mangled to forbid it
[10:09] <sergiusens> brendand: dpkg-deb -x extracts the deb into a path (/)
[10:09] <ogra_> (or whatever the current method is)
[10:09] <ogra_> yeah, use that
[10:09] <sergiusens> which avoids the scripting to run
[10:09] <ogra_> right
[10:12] <davmor2> sil2100: you got 5 minutes for a quick hangout?
[10:12] <sil2100> 5 minutes, yes! 10 minutes, no!
[10:12] <sil2100> ;)
[10:13] <psivaa> mardy: you might have already seen this.. but:
[10:13] <psivaa> + make coverage-html
[10:13] <psivaa> make: *** No rule to make target 'coverage-html'.  Stop.
[10:13] <oSoMoN> sil2100, do you know who in the QA team I need to ping to get an ack for RTM silo 6 ?
[10:14] <sil2100> oSoMoN: it's queued :) brendand is the current person on duty
[10:14] <sil2100> But he's signing-off something already
[10:14] <oSoMoN> excellent, thanks
[10:14] <brendand> sil2100, davmor2 is here now!
[10:14] <psivaa> mardy: ^ that's what i'm seeing and not sure how we could set the rule in jenkins.. i'd guess the rule is inside the packages itself?
[10:19] <sergiusens> psivaa: check jenkins; there should be a hook to enable coverage
[10:19] <psivaa> sil2100: the tests with 208 are now complete, with almost the same results as we saw earlier except filemanger has 1 failure
[10:19] <sergiusens> adds the targets and all
[10:19] <sergiusens> and it's probably broken
[10:19] <brendand> sergiusens, how do you run that?
[10:19] <sergiusens> psivaa: ask alesage
[10:19] <sergiusens> brendand: run what?
[10:20] <sergiusens> brendand: dpkg-deb -x package.deb / ?
[10:20] <sergiusens> if slash is the root of course
[10:20] <sergiusens> which it generally is
[10:21] <brendand> sergiusens, http://paste.ubuntu.com/8148725/
[10:21] <sergiusens> brendand: from recovery still
[10:21] <sergiusens> brendand: most all system packages would need to be installed from recovery soon due to the bind mounts
[10:22] <sergiusens> until we get images built per silo
[10:22] <ogra_> but thats V material
[10:23] <brendand> sergiusens, ah right - so run the code on the gist you posted?
[10:23] <ogra_> just follow the lxc-android-config testplan
[10:23] <sergiusens> brendand: well, similar, depending if they add an init script or not a dpkg -i will work or not
[10:23] <ogra_> it has the proper install instructions for such packages
[10:24] <sergiusens> ogra_: well if dpkg is doing more in the postinst; I don't want it to be the default way long term (dpkg-deb -x)
[10:24] <sergiusens> ogra_: we might miss things
[10:24] <brendand> ogra_, where is that?
[10:25] <ogra_> somewhere on the testplan wikispace
[10:25]  * ogra_ hasnt needed it in ages 
[10:25] <sergiusens> brendand: when someone mentions test plan it's usually the tesplan base link + source package name
[10:26] <brendand> sergiusens, yep - but i checked in both pluralities and it doesn't seem to be there with that name
[10:27] <brendand> sergiusens, https://wiki.ubuntu.com/Touch/Testing/lxc-android-config
[10:27] <brendand> yet another path :)
[10:27] <sergiusens> that should be moved!
[10:28] <ogra_> where to ?
[10:34] <brendand> ogra_, mount: mounting /dev/block/loop0 on /mnt failed: No such file or directory
[10:34] <brendand> ogra_, do i have to create /mnt?
[10:35] <sergiusens> brendand: ogra_ for mounting, use the gist I gave you
[10:35] <sergiusens> it is dfferent on krillin!
[10:36] <sergiusens> ogra_: lxc-android-config is incorrect
[10:36] <sergiusens> brendand: the test plan ogra gave you tells you to do exactly what fails that we just discussed
[10:36] <sergiusens> ogra_: this will fail 'adb shell chroot /mnt /usr/bin/env PATH=/bin:/sbin:/usr/bin:/usr/sbin dpkg -i /tmp/lxc-android-config_*_all.deb'
[10:37] <ogra_> no, it has been tested various times
[10:37] <ogra_> if it fails now thats because something underneath changed recently
[10:37] <sergiusens> ogra_: well it looks exactly like my gists
[10:38] <thostr_> sil2100: anything we need to do to land silo 12 or will you take over?
[10:39] <ogra_> sergiusens, i guess all the init changes cause this ... iirc mathieu used these instructions after malta annd they worked fine
[10:39] <sergiusens> ogra_: well it used to work for me too
[10:39] <sergiusens> but doesn't anymore
[10:40] <sergiusens> so dpkg-deb -x with careful checking of the post/pre scripts is what you have to do
[10:40] <psivaa> sergiusens: the coverage hook and qmakecoverage are enabled in the jenkins job already.. (H10enable_coverage and B09qmakecoverage)
[10:40] <sergiusens> psivaa: yeah; I'm saying that enablement "hook" is probably broken
[10:41] <psivaa> sergiusens: ack ack
[10:43] <brendand> sergiusens, i don't have /usr when in recovery
[10:44] <sergiusens> brendand: follow my gist, but change dpkg -i to dpkg-deb -x powerd_package.deb /
[10:45] <sergiusens> brendand: you don't need /usr and you won't see it unless you chroot
[10:46] <brendand> sergiusens, chroot: can't execute '/usr/bin/dpkg-deb': No such file or directory
[10:46] <sergiusens> brendand: did you mount?
[10:47] <brendand> sergiusens, yep
[10:47] <ogra_> erm ... why dpkg-deb ?
[10:47] <ogra_> just dpkg -x should work fine
[10:47] <sergiusens> ogra_: yeah, works too
[10:47] <brendand> sergiusens, how can i reset and try again? just reboot?
[10:47] <sergiusens> brendand: anything you write to /mnt will stick until you reflash
[10:48] <sergiusens> ogra_: dpkg-deb should still be there...
[10:48] <ogra_> and it is
[10:48] <ogra_> (since the dpkg package ships it)
[10:49] <sergiusens> brendand: ogra_ http://paste.ubuntu.com/8148916/
[10:49] <sergiusens> that is proof I guess...
[10:50] <brendand> sergiusens, i guess i did something wrong then
[10:51] <thostr_> Mirv: what about silo 12?
[10:52] <sil2100> thostr_: sorry, was in a meeting
[10:52] <Mirv> thostr_: I was asking sil to look at that, but I just before you mentioned started asking on #ubuntu-devel for it
[10:52] <sil2100> thostr_: looking :)
[10:52] <thostr_> Mirv: sil2100: thanks
[10:52] <Mirv> sil2100: also, landing-014
[10:53] <Mirv> thostr_: I've now finally put my MOTU application in so I can publish a bit better later on, but it'll take four weeks
[10:53] <Mirv> good timings for all us three, for asking about the silo and being back :)
[10:53] <Mirv> all withing 1 minute or so
[10:55] <thostr_> Mirv: also, line 15 in ci sheet is missing silo 3 which is tested and good and can be published
[10:56] <thostr_> Mirv: apparently robru executed some script yesterday that removed the silos from ci sheet
[10:57] <sil2100> thostr_: from what robru mentioned, the spreadsheet has been removing some entries by itself (?), so some might need to be brought back into the spreadsheet
[10:58] <Mirv> thostr_: ok, found it
[10:58] <thostr_> sil2100: yeah. anyway it's just a ci sheet problem, silo build and testing is fine
[10:59] <Mirv> thostr_: added back the id which luckily was still possible to find and it's now fixed
[10:59] <thostr_> Mirv: perfect
[10:59] <Mirv> thostr_: but, MP not approved https://code.launchpad.net/~jpakkane/thumbnailer/embedded-album-art/+merge/231207
[11:00] <Mirv> (top approved)
[11:00] <thostr_> Mirv: I thought I had seen that approved yesterday... my bad... will quickly get one
[11:02] <mardy> psivaa: no, the rule is in Jenkins: it does a "make coverage-html", but there is no Makefile there
[11:03] <mardy> psivaa: it needs to do a "cd build/qt5" first, because signon is built in that directory
[11:04] <sergiusens> mardy: yeah, I was telling psivaa that the jenkins job is assuming the wrong thing
[11:04] <mardy> psivaa: I believe that the hook is B09qmakecoverage
[11:05] <mardy> sergiusens: yep. I'm not sure how these rules work, please let me know if there's something needed on my side
[11:06] <satoris> psivaa: any idea what could be causing this Jenkins failure: https://jenkins.qa.ubuntu.com/job/thumbnailer-utopic-amd64-ci/20/console
[11:06] <sil2100> thostr_: just wanted to confirm one thing - did you make sure that both libmediascanner-2.0-1 and libmediascanner-2.0-2 can be installed at the same time?
[11:06] <sil2100> (actually it looks fine, as it only installs the .so file)
[11:07] <psivaa> satoris: just a sec please.. trying to see if i could fix mardy's issue. will take a look in a bit
[11:07] <sil2100> thostr_: anyway, approved, let me publish
[11:08] <satoris> Ok, thanks.
[11:11] <psivaa> sergiusens: mardy: so http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/view/head:/stacks/head/webcred.cfg is the cfg for that job and i dont see how we could in jenkins effect that 'cd build/qt5'  change in here in jenkins.
[11:11]  * psivaa is trying to understand :)
[11:12] <psivaa> probably need to workaround that in B09qmakecoverage script?
[11:15] <mardy> psivaa: where is the B09qmakecoverage script? maybe having a look at it will help, there might be some variable that we can modify in the configuration
[11:17] <psivaa> mardy: http://bazaar.launchpad.net/~private-ps-quality-team/pbuilderjenkins/trunk/view/head:/hooks/B09qmakecoverage.in
[11:18] <mardy> psivaa: maybe that $BUILD_DIR variable...
[11:28] <psivaa> mardy: that's not something we set in jenkins i suppose, but its being set http://bazaar.launchpad.net/~private-ps-quality-team/pbuilderjenkins/trunk/view/head:/hooks/build_and_result_path_logic
[11:30] <sergiusens> psivaa: whoever added the hook to that specific jenkins job should fix it imo
[11:36] <psivaa> sergiusens: ack, will talk to fginther about it. thanks
[11:37] <brendand> sergiusens, i execute exactly what's in your gist after reflashing and it still tells me /usr/bin/dpkg does not exist
[11:37] <brendand> rsalveti, are you there?
[11:38] <sergiusens> brendand: are you using new partitions?
[11:38] <brendand> sergiusens, might there be something different about my krillin?
[11:38] <brendand> sergiusens, not as far as i know
[11:38] <sergiusens> brendand: I assumed no one is supposed to use old partitions anymore
[11:38] <sergiusens> brendand: from the communication
[11:39] <sergiusens> brendand: old partitions don't get anymore updates
[11:39] <brendand> sergiusens, ok i'll update and try again
[11:39] <sergiusens> brendand: the mount is probably mounting something else
[12:04] <psivaa> satoris: btw, i've cleaned up the thumnailer workspace and running that job again. hopefully that should get that going
[12:10] <satoris> psivaa: ack, thanks.
[12:21] <oSoMoN> brendand, davmor2: is anyone looking at RTM silo 6 ?
[13:00] <davmor2> oSoMoN: I can have a look at that as soon as I file a bunch of bugs
[13:02] <Mirv> sergiusens: what about the line 17, does it need a silo?
[13:03] <sil2100> ogra_: btw.!
[13:03] <sil2100> ogra_: what's  the status of ubuntu-rtm changes files?
[13:03] <Mirv> Saviq: line 22 marked as tested, silo not seen anywhere...
[13:03] <sergiusens> Mirv: that was cancelled: "Gave up this landing. Cleaning silo."
[13:03] <sergiusens> raw status says that too
[13:03] <sergiusens> which is what I pasted
[13:03] <Saviq> Mirv, yeah, somethings shonky there
[13:04] <oSoMoN> davmor2, thanks, I’d appreciate if we can land it today
[13:04] <Mirv> sergiusens: ok, let's remove the line then
[13:04] <Saviq> Mirv, the description does not match MPs
[13:04] <Saviq> Mirv, and those mps landed
[13:04] <sergiusens> Saviq: spreadsheet got busted last night
[13:04] <Saviq> ah, explains
[13:04] <Mirv> Saviq: ah, that confused me too, I saw there were landings of that
[13:04] <Mirv> Saviq: marked as landed
[13:05] <pstolowski> sil2100, Mirv hey, is there a problem with silo12? do you need any action on our side?
[13:06] <Mirv> pstolowski: no actions needed, we just need to get packaging acks and sil was meaning to do that but he's stuck in meeting spree
[13:07] <sil2100> Oh, I only checked the mediascanner one ;)
[13:07] <pstolowski> Mirv, ack, thanks
[13:07] <pstolowski> thostr_, ^
[13:07] <sil2100> This one I didn't notice, and queuebot doesn't help!
[13:08] <Mirv> :)
[13:10] <sil2100> Let me take a look
[13:12] <ogra_> sil2100, didnt i say in the meeting "by end of the week" ?
[13:12] <sil2100> :<
[13:14] <sil2100> pstolowski: I don't want to be the meanie here but I would most probably prefer not to publish silo 12 right now
[13:15] <sil2100> pstolowski: the reason: the unity-scopes-api changelog says nothing of the changes in it
[13:15] <sil2100> pstolowski: if you could ask upstreams to give more info then 'Sync with devel' and rebuild, then I can publish that just fine
[13:16] <sil2100> pstolowski: as all other changes seem sane
[13:16] <sil2100> pstolowski: sorry for that
[13:18] <pstolowski> sil2100, hmm i see. i was assuming that the 'fixes:' commit there would be picked up automatically, but apparently this is not the case..
[13:19] <sil2100> pstolowski: CI Train takes only the descriptions and bugs attached to the MR that you release, so in case of a sync merge it only takes what you give it there
[13:20]  * sil2100 goes back to code
[13:23] <Wellark> sil2100, jfunk, brendand: happy to tell you that Jussi fixed the #1 crasher
[13:23] <Wellark> https://code.launchpad.net/~jpakkane/indicator-network/grace/+merge/232194
[13:24]  * ogra_ hugs Wellark 
[13:25] <jfunk> \o/
[13:25] <sil2100> Which one?!
[13:26] <ogra_> sil2100, indicator-network
[13:26] <sil2100> The one we whitelisted yesterday? :O
[13:28] <Wellark> sil2100: no
[13:28] <Wellark> the #1 crasher on device
[13:28] <ogra_> on errors.u.c
[13:28] <Wellark> yeah, although recent refactoring does not update the original report
[13:28] <Wellark> but there should be another that is piling up fast
[13:28] <Wellark> but anyway
[13:28] <Wellark> it's fixed.
[13:29] <sil2100> Wellark: thanks :) !
[13:29] <sil2100> Yay!
[13:29] <Wellark> ogra_: you should hug satoris
[13:29]  * ogra_ hugs satoris too 
[13:29]  * sil2100 hugs satoris too
[13:30] <brendand> sergiusens, time to start actually testing the silo :)
[13:31] <ogra_> omg
[13:31] <ogra_> an rtm landing you mean ?
[13:31] <Saviq> trainguards, I've line 35 set to testing: pass, the status / dashboard doesn't seem to reflect that though :/
[13:31] <sergiusens> great
[13:31] <ogra_> :D
[13:32] <sil2100> Saviq: :| Yeah, not sure what's going on with that
[13:33] <sergiusens> ogra_: fwiw I can't install openssh-server in my chromebook's chroot either due to the initscripts under utopic ;-)
[13:33] <ogra_> sergiusens, ask pitti :)
[13:33] <ogra_> since malta he knows the init process in and out ... backwards if required
[13:34] <sil2100> hmmm
[13:34] <sil2100> Saviq: yeah, so it seems that you got hit by the spreadsheet eating up random fields
[13:35] <sil2100> I put it back up again ;/
[13:35] <Saviq> sil2100, ktxbai
[13:52] <popey> sil2100: do we have a blocker for the welcome screen being broken?
[13:53] <sil2100> popey: not sure, davmor2 has a big list of new blockers that he will pass to me before the evening meeting, so maybe that's in it as well
[13:53] <sil2100> davmor2: ^ ?
[13:53] <sil2100> popey: how is it broken?
[13:53] <popey> sil2100: the stats on the welcome page " you have 2 sms" etc - don't work anymore
[13:54] <popey> been broken for a while.
[13:55] <sil2100> Oh, confirmed
[13:57] <davmor2> popey: infographics you mean
[13:58] <davmor2> popey: I think brendand or jibel filed one for that iirc
[13:58] <popey> yes
[13:59] <davmor2> popey: I seem to recall it being brought up before at least
[14:12] <satoris> cprov: could you look into why this fails (psivaa already tried something but apparently that did not work): https://jenkins.qa.ubuntu.com/job/thumbnailer-utopic-amd64-ci/24/console
[14:13] <cprov> satoris: sure, let me have a look
[14:13] <satoris> Thanks.
[14:16] <psivaa> satoris: cprov: https://jenkins.qa.ubuntu.com/job/thumbnailer-utopic-amd64-ci/23/console run succeeded but the issue propped back again
[14:17] <cprov> psivaa: any idea what's is causing it ?
[14:18] <psivaa> cprov: not really.. looks like this is specific to that thumbnailer job. the same issue occurred in two hosts, genie and kinnara.
[14:18] <kgunn> sil2100: hey, can i get a silo for line48 ?
[14:19] <psivaa> i was under the assumption that some temporary permission issue and force cleaned up the workspace but it looks like that was a temp fix
[14:20] <sil2100> kgunn: sure, one moment
[14:22] <kgunn> ta
[14:22] <sil2100> thostr_: hey!
[14:22] <sil2100> thostr_: I see you proposed an RTM landing :)
[14:23] <sil2100> thostr_: regarding that, I want to let you know you have a choice on how to proceed with RTM-based landings (I will send out an annoucement for that in the nearest time)
[14:24] <sil2100> thostr_: so, in case your project is RTM-focused and when you actually plan to include EVERY commit in RTM, you can live without an rtm branch of your code
[14:24] <cprov> satoris: psivaa: fginther will cleanup the workspace manually and retry the last job, let's see if it gives us a better idea about what is broken.
[14:24] <thostr_> sil2100: good to know
[14:24] <thostr_> sil2100: and, yes, all our projects are rtm focused for now
[14:24] <sil2100> thostr_: so we're actually experimenting (and working) on an approch here where you can try living without the additional branch and just requesting src copies of what you release into ubuntu
[14:25] <thostr_> sil2100: that would be great
[14:25] <camako> fginther, good morning.. I've created the upcoming stable branch for Mir (lp:~mir-team/mir/0.7). Would you please provision it for CI when you get a chance?
[14:25] <sil2100> thostr_: something like that will be somewhat automated in CI Train soon (working on that), but for now what I can recommend for you is giving you a silo with only source-packages that I will copy into the silo PPA for you
[14:25] <sil2100> thostr_: this way you won't have to maintain a separate branch
[14:26] <popey> brendand: jibel do you have a bug for broken infographics?
[14:26] <sil2100> thostr_: would you want a source-package only silo then?
[14:26] <brendand> popey, what?
[14:27] <satoris> cprov: ok, thanks.
[14:27] <thostr_> sil2100: when would that be available or when do we need to decide
[14:27] <popey> brendand: look at a locked phone. infographics aren't updated with sms / music played / calls made etc
[14:27] <popey> brendand: davmor2 suggested you may have already reported a bug
[14:27] <popey> its been broken for a while
[14:28] <sil2100> thostr_: so, the automated bits will take some time to do, but I can anyway do that source-only silo for you and do everything for you manually
[14:28] <brendand> popey, it's not broken at all here on the rtm branch
[14:28] <sil2100> thostr_: you'll only have to test the silo in the end
[14:28] <brendand> popey, depends on the definition of a while then :)
[14:28] <popey> brendand: do you have a pin lock set?
[14:28] <brendand> popey, ah nope
[14:28] <sil2100> thostr_: you can decide if you want to have a separate branch anytime you want I guess
[14:28] <thostr_> sil2100: so, being more specific for the requested silo: what do I need to do now
[14:28] <popey> set one#
[14:29] <davmor2> popey: I'm on rtm I see 1 call made today
[14:29] <davmor2> popey: I have pin code in place
[14:29] <ogra_> thostr_, the rtm silo needs QA signoff anyway ... so depending how much you trust QA you can only test the utopic silo and leave the rtm one to QA
[14:29] <sil2100> thostr_: if you want it to be dealt without the RTM bzr branch, then all you have to do is tell me and I'll do everything needed with the silo
[14:29] <popey> well I am not on rtm and don't know how to be on rtm..
[14:30] <sil2100> thostr_: and you'll get an RTM silo with all the contents in it
[14:30] <thostr_> sil2100: I don't need a rtm branch
[14:30] <brendand> popey, that's broken
[14:30] <ogra_> popey, by selecting the right channel :)
[14:30] <popey> define "right"
[14:30] <sil2100> thostr_: ok then, so I'll prepare everything for you now
[14:30] <ogra_> ubuntu-device-flash --list-channels
[14:30] <popey> alan@wopr:~$ ubuntu-device-flash --list-channels | wc -l
[14:30] <popey> 53
[14:30] <ogra_> grep rtm :)
[14:30] <sil2100> thostr_: btw. you only want mediascanner to be in that silo? No need for unity-scope-mediascanner?
[14:30] <popey> so, my question is, should everyone switch to the rtm channel?
[14:31] <popey> (also, repeating myself, where was this announced?)
[14:31] <ogra_> popey, theoretically yes
[14:31] <ogra_> practically not much has landed in rtm yet ... so it is a bit behind
[14:33] <fginther> camako, yes, I can get that added shortly
[14:33] <camako> fginther, thanks
[14:37] <alesage> psivaa, did you get your coverage question answered?
[14:38] <fginther> cprov, satoris, psivaa, I found a file "/tests/chinese_text/图片.JPG", that could potentially be the source of the jenkins problem. I've specifically removed that file and re-triggered the job
[14:39] <psivaa> alesage: yea, fginther suggested that we remove coverage hooks for signon for now and let you decide how to go ahead with adding it back
[14:39] <rsalveti> brendand: I'm now
[14:39] <alesage> psivaa, no objection, the system is getting a bit of an overhaul as we speak :) , sorry for the trouble
[14:40] <sil2100> thostr_: ok, so for now I only copy mediascanner there
[14:40] <psivaa> fginther: so with that thumbnail job, i cleaned up the workspace on both kinnara and genie and kicked off a build. it worked once and probably because that file is branched/produced in the workspace, it failed again.
[14:40] <psivaa> alesage: no problem. i've just done an MP to remove the hooks
[14:40] <plars> uhoh
[14:40] <thostr_> sil2100: that's not sufficient as the MP also contains unity-scope-mediascanner
[14:41] <plars> psivaa: balloons: sil2100: ubuntu-clock-app - something strange happened with the bzr branch: bzr: ERROR: Server sent an unexpected error: ('error', 'ValueError', 'requested revno (492) is later than given known revno (67)')
[14:41] <psivaa> plars: which job is this.. thinking where i missed this
[14:42] <sil2100> thostr_: how? The landing has only one MP and it's for mediascanner2, so there's no unity-scope-mediascanner there?
[14:42] <satoris> fginther: there have been tens of thumbnailer jobs with that file without problems.
[14:42] <balloons> plars, likely the series was changed to point at the reboot branch
[14:42] <balloons> let's look
[14:42] <thostr_> sil2100: let me check...
[14:43] <plars> psivaa: it looks like something just changed in the branch, so it will be any job from here on out
[14:43] <sil2100> thostr_: anyway, I'll copy both mediascanner2 and unity-scope-mediascanner packages to that PPA then
[14:43] <thostr_> great
[14:44] <thostr_> sil2100: and since we don't have a branch we don't need to worry about the MP, right
[14:44] <sil2100> Right :)
[14:44] <thostr_> cool
[14:44] <psivaa> plars: ahh, ack. ack
[14:45] <oSoMoN> davmor2, have you had a chance to test RTM silo 6 yet? sorry if I sound insistent, but I’d really like to be able to land it today
[14:45]  * sil2100 got a very nice idea for CI Train now
[14:46] <balloons> plars, yes that's exactly what happened. It causes the clock tests to fail right, as the manifest is wrong
[14:46] <sil2100> thostr_: ok, bad luck, google has some issues right now, this might take a few minutes...
[14:46] <thostr_> sil2100: why am I not surprised :)
[14:46] <plars> balloons: it causes setup for the entire test run to fail because phablet-click-test-setup chokes
[14:47] <plars> balloons: so probably ALL tests don't even run until we get a new ubuntu-clock-app rebuild with the proper branch revno in the manifest, or the branch gets put back how it was
[14:47] <davmor2> oSoMoN: trying to install it now
[14:47] <balloons> plars, right yes I know exactly what would happen
[14:47] <oSoMoN> davmor2, cool, thanks!
[14:48] <balloons> plars, so I'm thinking we could modify the manifest and re-upload the click, or upload the reboot click
[14:48] <balloons> plars, let me see what they would like to do
[14:48] <plars> balloons: thanks!
[14:51] <camako> fginther also the 0.5 branch is now obsolete and can be decommissioned from CI, in case you feel like cleaning up as you go...
[14:52] <davmor2> oSoMoN, sil2100, ogra_: you guys any idea why I would be seeing this form the ppa I added? http://paste.ubuntu.com/8150538/
[14:53] <oSoMoN> davmor2, how did you add the PPA?
[14:53] <ogra_> davmor2, that url is wrong
[14:53] <ogra_> drop the ubuntu after ubuntu-rtm
[14:53] <davmor2> ogra_: it's the rtm silo I'm testing
[14:54] <davmor2> oSoMoN: apt-add-repository ppa:ci-train-ppa-service/landing-006
[14:54] <ogra_> yeah, doesnt work yet
[14:55] <oSoMoN> davmor2, you’ll need to modify the file it created under /etc/apt/sources.list.d/ to point to the right sources
[14:55] <ogra_> cjwatson said wgrant works on fixing apt-add-repository ... that needs some LP love first apparently
[14:55] <oSoMoN> davmor2, "deb http://ppa.launchpad.net/ci-train-ppa-service/landing-006/ubuntu-rtm 14.09 main "
[14:55] <balloons> plars, so apparently the migration to reboot should take place as soon as QA a-ok's it
[14:55] <davmor2> oSoMoN: thanks
[14:56] <dobey> sil2100: hi. any further with the syncing through silos?
[14:56] <plars> balloons: ack
[14:57] <sil2100> dobey: still working, battling off distractions in forms of meetings and discussions
[14:57] <dobey> ok
[14:57] <sil2100> dobey: but I'll try deploying an half-solution, like the first step in complete automation
[14:58] <dobey> sil2100: ok. i'm just anxious to use it :)
[15:00] <davmor2> sil2100: so some of the issues still exist you'll be glad to know :(
[15:08] <davmor2> oh god the cruelty of a million lang packs
[15:11] <brendand> rsalveti, the last test case here is redundant, right? https://wiki.ubuntu.com/Process/Merges/TestPlans/Powerd
[15:13] <bzoltan> fginther:  I as wrong, the UITK gles rules is correct.. it is the main UITK where some arch types should skip the tests
[15:13] <bzoltan> fginther:  the uitk-gles tests simple fails on i386 and amd64, what is nonsense
[15:14] <fginther> bzoltan, so it sounds like that requires a upload and rebuild of the main UITK in that silo?
[15:14] <bzoltan> fginther:  No, I do not think so.. the main UITK as built for half a dozen of archs, tested and passed all the ~900 autopilot tests of 20+ other projects
[15:15] <rsalveti> brendand: why redundant?
[15:15] <fginther> bzoltan, should "ubuntu-ui-toolkit-gles" just be an armhf package? (I'm just throwing out suggestions at this point)
[15:16] <bzoltan> fginther:  no, that is a package for the i386 emulator
[15:16] <bzoltan> fginther:  the -gles packages are only for i386
[15:16] <brendand> rsalveti, well that script doesn't exist in that location
[15:16] <brendand> rsalveti, so unless it's changed location or name...
[15:16] <rsalveti> guess it probably changed
[15:17] <rsalveti> we had that because that was the script used to unlock the screen in our test infra
[15:17] <fginther> sil2100, can you help out bzoltan and I with silo 9? ubuntu-ui-toolkit-gles fails to build due to it's tests
[15:18] <fginther> sil2100, tests which should not execute on i386/amd64 if I understand correctly
[15:18] <bzoltan> fginther:  it could run those tests... but they fail and that is nonsense ... the main uitk was built and tested.
[15:19] <fginther> bzoltan, oh, so they should pass, I misunderstood
[15:19] <thostr_> sil2100: can you also try to publish silo 12... this will then unblock saviq
[15:19] <sil2100> thostr_: did you fix the changelog?
[15:19] <thostr_> sil2100: yes. and rebuild and retested
[15:19] <sil2100> thostr_: I pointed out my concerns to pstolowski - if it's ok then I can try publishing...
[15:20] <sil2100> Thanks
[15:20] <sil2100> fginther: uh?
[15:20] <Saviq> tedg, ah 'The content of the "APP_ID" environment variable'
[15:20] <bzoltan> fginther: sil2100: hold on, i am sorting it out with zsombi
[15:20] <sil2100> fginther: I'll try to look into that, but I'm currently chased down by urgent things
[15:20] <sil2100> k
[15:20] <fginther> sil2100, thx
[15:21] <Saviq> tedg, oops, sorry for jumping channels
[15:21] <tedg> Saviq, Ah, you should be able to just set that to "unity8-dash"
[15:21] <Saviq> tedg, yup, did that
[15:28] <brendand> sergiusens, your silo is good to go
[15:28] <brendand> who's next?
[15:28] <thostr_> sil2100: I don't get the failure of silo 12 publishing... it clearly shows changes in the changelog
[15:29] <sil2100> thostr_: all seems ok, no worries, just was double-confirming everything
[15:29] <thostr_> so, why is the test still failing then?
[15:29] <sil2100> thostr_: I hope you made sure the music still works for local files, right?
[15:30] <thostr_> yes, local music and local videos work
[15:30] <sil2100> Then excellent
[15:38] <kenvandine> brendand, did you see i updated settings in silo 1 for rtm?
[15:45] <bzoltan> fginther:  thanks for your quick  response. The problem was in the control file. I pushed the fix and now building.
[15:45] <fginther> bzoltan, good to hear
[15:48] <Saviq> huuuh can't get SIM in mako r208 anyone?
[15:58] <bdmurray> plars: yesterday we had talked about adding whoopsie.log for failed tests, I don't see it here http://ci.ubuntu.com/smokeng/utopic/touch_stable/mako/7:20140826:20140811.1/9958/camera_app/. Am I looking in the wrong spot?
[16:03] <plars> bdmurray: no, I didn't get a chance yesterday, but I *will* add it today
[16:03] <balloons> fginther, re: autolanding core apps on devices, both calendar and reminders suffer from needing depends. Any chance you can use autopkgtest to run these instead?
[16:03] <plars> bdmurray: all the tests are broken right now though until we get a new clock app upload
[16:05] <fginther> balloons, I was going to try that for reminders, I'll also try for calendar
[16:06] <balloons> fginther, pitti has made it really simple now to run
[16:06] <nik90> plars: sry, I am working on resolving that
[16:06] <fginther> balloons, cool. and I've been meaning to retry reminders now with your fix from last week. sorry for making such slow progress on this
[16:07] <balloons> fginther, if you install the click on the device, all you need to do is run 'adt-run --click com.ubuntu.XXXX --- ssh -s adb﻿'
[16:07] <balloons> fginther, autopkgtest will read the manifest for the depends and for the test info, grab the tests from source as well
[16:08] <fginther> balloons, just curious, where does it grab the tests? I'm working with a merged branch
[16:08] <fginther> balloons, nevermind, I seam to recall that can be specified
[16:09] <balloons> fginther, as specified in the manifest. the branch and the revno
[16:09] <balloons> fginther, you can still pass the click source if you wish as well
[16:09] <balloons> or override the manifest and pass it something else. it's really flexible
[16:09] <bdmurray> plars: okay thanks, I'll be more patient. ;-)
[16:10] <bzoltan> fginther:  hmm.. it seems I still need some help
[16:10] <fginther> balloons, yeah, I do remember those options. Just need to put some code around it
[16:10] <balloons> so fginther autopkgtest 3.4 has landed today which has this stuff in it
[16:11] <bzoltan> fginther: I have added the qml-module-qt-labs-settings to the build deps in the rev 21 of the uitk-gles and it is visible here -> https://ci-train.ubuntu.com/job/ubuntu-landing-009-1-build/26/console
[16:11] <bzoltan> fginther: But in the build logs it is not listed as installed https://launchpadlibrarian.net/183202521/buildlog_ubuntu-utopic-amd64.ubuntu-ui-toolkit-gles_1.1.1214%2B14.10.20140825-0ubuntu1_FAILEDTOBUILD.txt.gz
[16:12] <bzoltan> fginther:  should I bump the version of the -gles?
[16:13] <fginther> bzoltan, looking
[16:13] <bzoltan> fginther:  it looks like that the jenkins job could not dput the new source to the PPA
[16:14] <ev> bdmurray: shouldn't that be syslog? Does whoopsie send anything interesting to its own log anymore?
[16:15] <bdmurray> ev: since it is running in the foreground now it uses the upstart log file /var/log/upstart/whoopsie.log
[16:15] <ev> ah of course
[16:16] <fginther> bzoltan, that looks like the problem, the package version is the same as the one already in the ppa
[16:17] <fginther> bzoltan, a version bump of the source package should fix it
[16:17] <fginther> trainguards, is that right ^? does bzoltan need to increment the package version for silo 9
[16:20] <bzoltan> fginther:  I try that
[16:20] <robru> fginther: bzoltan: yeah it sounds like a version bump is in order.
[16:30] <oSoMoN> davmor2, how is rtm silo 6 doing in your tests?
[16:31] <davmor2> oSoMoN: got caught up in meetings still running test but nearly done
[16:32] <oSoMoN> davmor2, cool, thanks!
[16:39] <ogra_> sergiusens, yay https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-August/thread.html
[16:39] <ogra_> at least it landed finally
[16:49] <bzoltan> rsalveti:  are you around? I am not getting anywhere with that uitk-gles package.. I had to modify the debian/control but if I bump the version then it complains and if I do not touch the version then it does not dput to the PPA.
[16:49] <sil2100> robru: oh, so, the spreadsheet still seems to have some issues from time to time ;/
[16:49] <sil2100> Like barfing with csv errors every now and  then
[16:50] <robru> ugh
[16:54] <bzoltan> sil2100: robru: there is a problem with the silo9 ... the -gles needed a fix, if I do not increase the changelog version then the new source is not loaded to the PPA and so the change does not take place. If I increase the version number then the -gles falls out of version sync and complains that there is no uitk source package with that version.
[16:55] <robru> bzoltan: yeah you have to bump both the version numbers in sync.
[16:55] <bzoltan> robru:  like the main UITK too?
[16:55] <robru> bzoltan: yes, it's the only way. the version numbers need to be in sync but the PPA won't accept the -gles with the same version
[16:56] <bzoltan> robru:  but it is the CI job what sets the main version number
[16:56] <robru> bzoltan: right, so run a force rebuild on that, and then use the resulting version number for -gles
[16:57] <bzoltan> robru:  and that takes hours :( Anyway, I see what should I do...
[16:57] <robru> bzoltan: yeah, but there's no other way unfortunately
[16:57] <pstolowski> sil2100, hey, re silo 12, is there still an issue with changelog or is the comment referring to the first rejection?
[16:58] <bzoltan> robru:  it is OK, thanks
[16:59] <robru> bzoltan: you're welcome
[17:01] <rsalveti> bzoltan: you can bump the packaging version I guess
[17:01] <rsalveti> like ubuntu1,2,3, etc
[17:01] <rsalveti> that would allow the upload
[17:01] <rsalveti> the only version that needs to be in sync is the upstream one
[17:01] <bzoltan> rsalveti:  I tried to add ~0build1 and it did not help
[17:02] <rsalveti> bzoltan: what was the error?
[17:02] <rsalveti> I'd just bump to 0ubuntu2 actually
[17:02] <bzoltan> rsalveti: INFO Some source packages were never published in the ppa: ubuntu-ui-toolkit-gles (1.1.1214+14.10.20140825-0ubuntu1~0build1)
[17:02] <rsalveti> bzoltan: right, need to ping someone that gets the reject email to know why
[17:03] <bzoltan> rsalveti: My taste is that for just building and hacking bumps I do not touch the numbers in ubuntuX
[17:03] <bfiller> robru: can silo 1 and 16 be setup to copy into rtm silo's as well, or does that have to be done at creation time?
[17:03] <bzoltan> rsalveti: anyhow, I forced a main source rebuild as robru suggested
[17:03] <rsalveti> well, you don't want ~0build1 to land in the archive
[17:03] <rsalveti> bzoltan: building with 0ubuntu2 is also fine
[17:04] <bzoltan> rsalveti: OK, I will do that in the future
[17:04] <rsalveti> or 0ubuntu1build1, something like that
[17:04] <rsalveti> alright, ping me again if you still get any issues with it
[17:04] <robru> bfiller: it's all manual, I can copy those for you a bit later once you tested them in utopic (no point copying them before you test them, because it's a lot of extra work and you might need to rebuild)
[17:05] <bfiller> robru: ack
[17:07] <bzoltan> rsalveti:  I forced a rebuild of the main uitk package, that will give us the 1.1.1214+14.10.20140826-0ubuntu1 version... the builds are just under work. Do you think that I could start a -gles build with the synced version? I would expect yes, because the ubuntu-ui-toolkit_1.1.1214+14.10.20140826.orig.tar.gz is already there.
[17:08] <rsalveti> a rebuild will create 1.1.1214+14.10.20140826.1, right?
[17:08] <robru> sil2100: just figured out the problem with queuebot. it indexes statuses based on the description column, which is no longer unique because people are copy&pasting that field for utopic vs rtm.
[17:08] <robru> so statuses are getting clobbered and it's re-reporting the same status over and over
[17:08] <rsalveti> bzoltan: oh, yeah, sorry
[17:09] <rsalveti> bzoltan: just saw in the ppa
[17:09] <rsalveti> bzoltan: yeah, once the orig tarball is available (you can check by accessing the http address), you should be good to trigger the gles one
[17:09] <bzoltan> rsalveti:  cool, i do that
[17:10] <bzoltan> rsalveti:  LOL ... Jenkins is soooo sequential :) one can not fire up parallel builds
[17:11] <rsalveti> bzoltan: right :-)
[17:12] <thostr_> robru: stupid question: why are the rtm ppa's named the very same way as the utopic ones?
[17:13] <thostr_> robru: ah, never mind
[17:13] <robru> thostr_: because that's the way it was done.
[17:26] <thostr_> robru: if I just add the landing ppa then it seems to take the one from utopic rather than rtm one
[17:32] <thostr_> robru: ok, fixed it manually.
[17:32] <ogra_> thostr_, there are still some implementation bits missing, so that manual step is needed
[17:32] <ogra_> asac should have mentioned that in his mail actually
[17:33] <thostr_> ogra_: would be nice to document those missing pieces somehwere...
[17:33] <ogra_> yes
[17:33] <robru> thostr_: yeah the RTM ppas are messed up. in theory you should be able to do 'add-apt-repository ppa:ci-whatever/landing-xxx' and get the right one (RTM if you're on an RTM image, etc) but it doesn't work yet
[17:33] <thostr_> and not in mail
[17:33] <thostr_> can't we have a proper wiki page so that things are more sticky and can be updated?
[17:33] <ogra_> thostr_ well, mail would have been a start at least :)
[17:34] <ogra_> but i dont think we have anything of this documented anywhere yet
[17:34] <ogra_> its all to new
[17:35] <ogra_> thostr_, looks like you could add your findings to the bottom of https://wiki.ubuntu.com/citrain/RTMLandingApproaches ...
[17:35] <thostr_> sure, but how can we force everybody to use it when nobody really  knows how?
[17:35] <ogra_> in a testing section or so
[17:35] <ogra_> thostr_, no, thats why there are so heated discussions
[17:35] <sil2100> We should have an RTM-testing-for-landers wiki page somewhere
[17:36] <sil2100> Since that would be nice to have
[17:36] <thostr_> sil2100: yes, that should have been there since last week... seriously...
[17:36] <sil2100> thostr_: +100
[17:36] <ogra_> sil2100, yes, especially since add-apt-repository doesnt work at all
[17:36] <ogra_> (without hacking up stuff)
[17:36] <sil2100> Well, even dput by default doesn't work, so duh
[17:36] <ogra_> right
[17:37] <sil2100> Theres SO much paperwork to do that I just want to hang myself ;)
[17:37] <ogra_> don't !
[17:37] <sil2100> Well, not really, I just want to move away from the PC soon
[17:37] <ogra_> same here
[17:38] <olli> asac, ^
[17:38] <olli> well, sorry, but testing the branching was supposedly done prior to the actual branching
[17:38] <olli> so I can see why there is frustrations of these using the infrastructure
[17:38] <olli> but... it is what it is now
[17:43] <thostr_> sil2100: can you do also the src package copying for line 51
[17:43] <thostr_> sil2100: same as you did for mediascanner earlier on?
[17:44] <sil2100> thostr_: sure :) I think I'll molest poor robru about that
[17:44] <sil2100> robru: ^
[17:44] <sil2100> robru: can you? I guess that script might be useful for now ;)
[17:44] <thostr_> fine with me :)
[17:44] <robru> sil2100: thostr_ yeah I can get to that in a second
[17:44] <thostr_> thanks
[17:46] <robru> thostr_: ok sorry, what copy do you want? if I'm reading it right, you want a new rtm silo, and then copy everything from utopic silo 12? you don't need anything from utopic archive?
[17:46] <thostr_> correct
[17:47] <thostr_> just doing the src copy so that I don't need new MPs
[17:49] <robru> thostr_: right
[17:49] <robru> bfiller: and sorry what did you want copied?
[17:49] <ev> bdmurray: thanks for the review
[17:53] <bdmurray> ev: no problem, I'll try and upload it this week
[17:53] <ev> cheers
[18:10] <awe_> robru, I also need a silo src copy for line 18 / silo-020  ( ofono ) please
[18:14] <robru> awe_: please be more specific. copy from where to where?
[18:14] <awe_> an rtm silo?
[18:14] <sil2100> robru: awe_ is requesting an ubuntu-rtm silo
[18:14] <sil2100> With the contents from silo 20
[18:15] <robru> awe_: ok but you don't have your rtm silo yet? and you don't need anything from the archive, just from silo 20?
[18:15] <sil2100> robru: get used to such requests until the automation is done ;<
[18:15] <ogra_> awe_, next time just change your nick ... awe_requesting_rtm_silo  :)
[18:15] <robru> sil2100: I'm writing a script right now
[18:15] <sil2100> Good
[18:15] <ogra_> awe_, we try to improve the process constantly :P
[18:15] <awe_> correct, I don't need anything from the archive, just the contents of 020
[18:16] <robru> excellent, thostr quit
[18:16] <olli> robru, what's up
[18:17] <robru> olli: oh he had asked me to sync some packages, which I did, wanted to let him know so he can start testing them
[18:19] <olli> alecu, ^
[18:20] <olli> robru, thx!
[18:20]  * alecu looks
[18:22] <alecu> robru: are those the silos rtm-007 and rtm-008?
[18:25] <robru> alecu: no. if it was rtm it would say rtm. if it doesn't say rtm it's not rtm
[18:25] <robru> wait
[18:25] <robru> what are we talking about?
[18:26] <alecu> robru: " had asked me to sync some packages, which I did, wanted to let him know so he can start testing them"
[18:30] <robru> alecu: ok those are in rtm 8
[18:32] <robru> awe_: ok where's your rtm landing request?
[18:32] <sil2100> robru: you'll have to add it
[18:33] <sil2100> :|
[18:34] <awe_> sil2100, your script will do this automatically in the future, correct?
[18:34] <sil2100> robru: so the deal is, whenever someone asks a landing for ubuntu, you prepare a landing for ubuntu-rtm for them
[18:34] <robru> awe_: ok you got rtm-9, copying soon
[18:34] <awe_> robru, thanks!!!
[18:35] <sil2100> awe_: yeah, I would say tomorrow - at least parts of it will be automated
[18:36]  * sil2100 hugs robru 
[18:40] <bzoltan> sil2100: robru: I am done with the UITK. The silo9 is good to go from my point. We had to fix to webbrowser_app and the UITK on the way, but now it is fine. Anyway, because of the central role of the UITK I would be happy to get a QA sign off.
[18:41] <bzoltan> sil2100: robru: the packages have debian/ changes, so it will require an extra round as usual.
[18:41] <robru> bzoltan: for utopic?
[18:48] <robru> sil2100: http://paste.ubuntu.com/8152325/ this is a thing now
[18:48] <sil2100> robru: that's awesome ;)
[18:48] <sil2100> It works, I assume?
[18:48] <sil2100> Looks like it works
[18:49] <robru> sil2100: yes, see https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-009
[18:49] <sil2100> robru: I think there was a quote in one of the first Zelda games: "it's dangerous to go alone, take this!"
[18:49] <robru> sil2100: the only sore point is that you have to manually find the URLs for the dsc files. Didn't feel like writing a screen scraper in bash
[18:50]  * sil2100 imagines robru being the person giving him a sword
[18:50] <plars> bdmurray: can you confirm that it's /var/log/whoopsie.log you were looking for? I don't see that on my device, and I don't even see it defined in the rsyslog config
[18:50] <robru> if there's some easy way to programmatically get a list of the full URLs to dsc files in PPAs, I'd love to hear it
[18:50] <sil2100> Not sure if that's easy to do from the shell level
[18:50] <robru> sil2100: oh and just make sure you set $DEBEMAIL to an email address that matches your gpg key.
[18:51] <sil2100> robru: anyway, thanks! This should be enough for you as well to survive the day
[18:51] <sil2100> So see you tomorrow :)
[18:51] <robru> sil2100: yes hopefully
[18:51] <robru> sil2100: goodnight
[19:13] <bdmurray> plars: no, its /var/log/upstart/whoopsie.log
[19:16] <bzoltan> robru:  yes, first to utopic and then in 9-10 hours I will make an RTM request
[19:20] <plars> bdmurray: ah, ok thanks :)
[19:48] <robru> ToyKeeper: brendand: we need qa acking on rtm silos 3, 4, 9, and 10, when you get some time, thanks
[19:53] <brendand> robru, all of them at once :)
[19:53] <brendand> robru, 3 is on my plate right now
[19:53] <brendand> or was it 4?
[19:53] <brendand> it's 3
[20:01] <robru> infinity: if you can please ^
[20:01] <robru> brendand: oh, and don't forget utopic 9 as well.
[20:01] <robru> thanks
[20:02] <infinity> robru: Looks fine.
[20:02] <robru> infinity: thanks
[20:02] <brendand> robru, we're not testing utopic silos except in traincon-0
[20:03] <robru> bzoltan: ^^
[20:03] <robru> bzoltan: so I'm publishing then! yippee kay-ay!!
[20:09] <robru> brendand: ok, landing from utopic 9 is now building in rtm 5, that's gonna need qa signoff when you can! thanks!
[20:10] <bfiller> robru: silo 1, 6, and 16 are ready for publish and can also be copied into rtm silos
[20:11] <robru> bfiller: ok I just have to eat something and then I'll do yours asap
[20:11] <bfiller> robru: no prob
[20:13] <ToyKeeper> robru: Sorry for the lack of sign-off yesterday.  I didn't manage to find legit rtm images and partitioning info until this morning, so I had nothing to test on.
[20:14] <brendand> rsalveti, hey
[20:15] <ToyKeeper> robru: It looks like brendand claimed silo 3, and the todo list shows 1, 2, 4, 5, and 7.  I guess I should add 9 and 10 to the list?  (are 1/2/5 no longer relevant?)
[20:15] <brendand> ToyKeeper, 1,2,5 are still relevant
[20:19] <brendand> rsalveti, you gave me some instructions a while ago for installing powerd in recovery - where are they?
[20:20] <brendand> ah i don't need them
[20:22] <rsalveti> brendand: http://paste.ubuntu.com/8092473/
[20:23] <rsalveti> brendand: but on a repartitioned device you now need to mount /system instead, and chroot into there
[20:39] <robru> ToyKeeper: no worries, you cannot be blamed for a lack of images
[20:40] <elopio> robru, balloons, popey, plars, nik90: The new clock looks good to me. There are a couple of weird things that nik90 already is tracking and will fix soon.
[20:40] <elopio> I tested all the UI buttons and widgets, the integration with indicators, the sound, the volume, the recurrence, the notification, phone locked and unlocked.
[20:40] <elopio> tested on krillin, freshly flashed with the rtm image.
[20:40] <robru> elopio: what silo are you talking about?
[20:40] <nik90> robru: no silo, its a click package
[20:40] <robru> Ahhhhhhhhhhhhhh
[20:40] <elopio> robru: no silo. Just what we discussed with lukasz on the meeting.
[20:40] <robru> OK
[20:40] <nik90> robru: we are replacing the old clock app (purple background) with the new clock reboot
[20:41] <nik90> YAY
[20:41] <robru> Cool
[20:43] <dobey> robru: hi. is it possible to get a sync of ubuntuone-credentials to ubuntu-rtm from utopic? how should i add that to the spreadsheet, since it's not got any MPs to land, and we just want what's in utopic to get synced over?
[20:51] <plars> elopio: awesome
[20:58] <robru> dobey: yes, please add a row for that. Leave the MPs blank and there's a spot to list source packages
[21:01] <dobey> robru: and qa signoff is "required" or "n/a"?
[21:01] <robru> dobey: depends if it's a feature or a bugfix
[21:01] <dobey> isn't everything :)
[21:06] <robru> bfiller: alright we're in uncharted trritory here. I hope your dialer-app in utopic 1 includes the changes that are in rtm 3! if not, this upload is gonna revert it!
[21:07] <bfiller> robru: let me check
[21:09] <bfiller> robru: you mean ubuntu silo 16 should include the changes that are already in ubuntu-rtm silo 3 right? Well it should as the changes in ubuntu-rtm 3 are already in trunk
[21:09] <bfiller> robru: so I guess we nuke that ubuntu-rtm 3 silo then? not sure how this all works
[21:10] <robru> bfiller: rtm3 is being verified, no need to interfere with that
[21:11] <robru> bfiller: i just tried to assign you an rtm silo for dialer-app and saw that it conflicted. wasn't sure what the statuses were, so if your latest landing doesn't include rtm3 then uploading it to rtm will revert the one from rtm3. but it's it already in trunk then it should be fine, thanks for checking
[21:11] <bfiller> robru: ok thanks, I think we should be good then
[21:15] <robru> bfiller: ok, in order to conserve precious RTM silos, I merged your three landings into a single one, and I've uploaded the packages. they'll build shortly and then require QA
[21:16] <bfiller> robru: great, thanks!
[21:17] <robru> bfiller: you're welcome!
[21:19] <renatu> hey guys I noticed that on messaging debian rules there is this:
[21:19] <renatu>  override_dh_auto_configure:
         dh_auto_configure -- -DCMAKE_BUILD_TYPE=Debug
[21:19] <renatu> what I understand is that this will enable the debug compilation by default
[21:19] <renatu> which will cause some qt flags to be enabled causing the app to no be fully optimized
[21:20] <renatu> is that correct?
[21:20] <renatu> can I remove this?
[21:27] <dobey> robru: oh, i guess clicking "build" in the dashboard for the sync isn't what i'm supposed to do?
[21:27] <robru> dobey: sure isn't!
[21:28] <dobey> oops :)
[21:28] <robru> dobey: you have to wait for me to manually upload the package, which I haven't done yet
[21:28] <robru> dobey: don't worry, you didn't do any harm
[21:28] <dobey> ah ok
[21:28] <asac> win3
[21:28] <robru> dobey: also this process is horribly undocumented so i can't even blame you!!
[21:28] <dobey> i don't blame me either :)
[21:31] <oSoMoN> robru, hey, where do the contents in rtm silo 5 come from? I’m not seeing any MRs
[21:33] <robru> oSoMoN: fairies and pixie dust my friend!
[21:33] <robru> oSoMoN: it was source-copied from utopic silo 9, no MPs
[21:33] <robru> oSoMoN: like it's exactly the same as silo 9, just s/utopic/14.09/ literally
[21:34] <oSoMoN> robru, that doesn’t sound right, at least not for webbrowser-app, the diff is messed up :/
[21:35] <oSoMoN> robru, or is it a new general policy that we’re doing source copies for everything now?
[21:35] <robru> oSoMoN: yes, check the recent mails from asac. it's source copies all the way down
[21:36]  * oSoMoN reads
[21:36] <robru> oSoMoN: http://paste.ubuntu.com/8152711/ here's the script I used to create the source copy. as you can see from the sed it only changes the first line of debian/changelog, nothing else. what weird diff are you seeing?
[21:36] <oSoMoN> robru, lots of po file changes, which were not in the rtm branch (but that’s ok, it’s just that I didn’t understand where they came from)
[21:37] <pmcgowan> robru, would it be possible to make this (target both and do src copy) the default and not need to request to do rtm, but rather to request not to?
[21:38] <pmcgowan> robru, maybe even sync the silo usage so its clear
[21:38] <robru> pmcgowan: that is the default, read asac's mail. sil is working on making citrain do this automatically but for now it's up to me to do it all by hand.
[21:38] <asac> yes, thats what we said in the mail
[21:38] <asac> automation will have to wait
[21:39] <asac> ack
[21:39] <pmcgowan> asac, ack, my bad did not pick that up
[21:39] <asac> no problem
[21:40] <oSoMoN> robru, so this new procedure renders the rtm-14.09 branch obsolete, right?
[21:42] <oSoMoN> by that I mean e.g. my lp:webbrowser-app/rtm-14.09 branch, as it won’t get changes merged back to it with source copies, right?
[21:44] <robru> oSoMoN: that's right, we're ramming trunks through utopic into rtm
[21:45] <oSoMoN> so if at some point we ever want to diverge, we’ll need to branch again, and ensure we don’t use source copies anymore, right?
[21:45] <robru> oSoMoN: that's right, you should just delete your rtm branch, and if you need to diverge later, re-branch and we'll stop doing source copies for you
[21:49] <oSoMoN> robru, ok, thanks for explaining!
[21:51] <robru> oSoMoN: you're welcome!
[22:14] <dobey> how the heck do i flash the rtm image to the n4?
[22:16] <robru> dobey: ubuntu-device-flash --channel=ubuntu-touch/ubuntu-rtm/14.09-proposed --developer-mode
[22:40] <ToyKeeper> robru: BTW, I can't mark it in trello until someone grants me permissions, but silo 10 is almost done.
[22:40] <robru> ToyKeeper: cool. I don't really care about trello, just mark it 'granted' in the spreadsheet when you're done please
[22:40] <ToyKeeper> Will do.
[22:40] <robru> ToyKeeper: thanks!
[22:43] <camako> fginther, Can I get a silo for row 61 please.
[22:47] <camako> or rather
[22:48] <camako> robru, can I get a silo for row 61 please..
[22:52] <robru> camako: ok you got 1
[22:52] <camako> thanks!
[22:52] <robru> camako: you're welcome!
[22:59] <camako> robru, so sorry, one of the branches changed name and I had to resubmit the MP. Do you have to reconfig silo 1? I update the spreadsheet.
[22:59] <camako> updated*
[22:59] <robru> camako: you can run the reconfig job in the dashboard.
[22:59] <camako> oh ok thanks
[22:59] <robru> camako: you're welcome
[23:17] <robru> stgraber: https://code.launchpad.net/~robru/queuebot/fix-rtm-dupes/+merge/232335 if you're around I fixed queuebot
[23:23] <robru> cyphermox: you got utopic silos 2 and 6
[23:24] <cyphermox> robru: thank you!
[23:24] <robru> cyphermox: you're welcome!
[23:25] <robru> awwwwww yiss
[23:25] <robru> stgraber: thanks!
[23:25] <cyphermox> very cute
[23:26] <stgraber> robru: hopefully that'll do the trick, I'll have to run away soon so won't be able to kill it if it goes wrong (well, you can always text me so I know I have to come kill it when I have a minute :))
[23:26] <robru> stgraber: it should be good, i tested it pretty well, fudging the spreadsheet to recreate the conditions etc
[23:27] <robru> I'm also running out to dinner, will be back in a couple hours though!
[23:27] <stgraber> that's some early dinner unless you're not on your usual timezone :)
[23:28] <robru> stgraber: it is a little early ;-)
[23:41] <ToyKeeper> ... so close!  Just need to figure out if copy/paste was already broken or if that's new.
[23:48] <sergiusens> wow; everyone got kicked; or was I shoved to a parallel universe ?
[23:51]  * popey pretends he can't hear sergiusens 
[23:53]  * ToyKeeper wonders how nobody managed to notice copy/paste not working, even though it's on the manual test plan for mir
[23:55] <thomi> ToyKeeper: this was found in silo testing?
[23:55] <ToyKeeper> thomi: Yes, but broken pre-silo.
[23:57] <thomi> ToyKeeper: ok, so probably someone didn't run their test plan properly
[23:57] <ToyKeeper> kgunn: Did you notice any copy/paste issues during your tests for rtm silo 10?