[02:04] <imgbot> [03:04] <imgbot> [03:29] <imgbot> [03:29] <imgbot> [04:19] <imgbot> [04:19] <imgbot> [06:23] <robru> Mirv: up yet?
[06:25] <Mirv> robru: sure
[06:25] <Mirv> already 2nd cup of coffee
[06:25] <Mirv> robru: how's the train?
[06:25] <Mirv> new publisher \o/
[06:27] <Mirv> I actually woke up 5.30am to get my car serviced
[06:27] <robru> Mirv: yeah! so during my whole shift there was only one publish run, and it worked, so that's good but obviously there's a huge potential for regression there.
[06:28] <robru> Mirv: but the new publisher has 100% test coverage and had a lot of success in the staging instance, so I'm pretty confident in it
[06:28] <robru> Mirv: reverting it will be tricky as it makes some changes to the format of the .project files that the train uses to track publishings, so eg if you revert the old code won't be able to read the new format and there might be some data loss / silos in inconsistent state there.
[06:29] <robru> Mirv: so I'm gonna stay up a bit late to make sure your first few publishings are ok
[06:29] <robru> Mirv: but really it should be fine.
[06:29] <Mirv> robru: ok, good to know. I don't think there necessarily are anything to publish for many hours since most of the EU people start working only in a couple of hours
[06:30] <Mirv> robru: but I fortunately also have sil2100 around today so I'm not alone if there are problems. but I'd guess if one publishing went well (and the code has good test coverage), it's likely it'll work just fine
[06:30] <robru> Mirv: most of the "regressions" will be in the form of safety checks removed, so if anything it'll err on the side of publishing things when it shouldn't (don't hit publish if you don't mean to publish ;-). I'm not aware of any regressions where it'll fail to publish something it should.
[06:32] <Mirv> ok :)
[08:12] <bzoltan> ogra_: I am checking out  the clich chroot stuff for vivid. mvo has changed the chroot to pull the ubuntu-sdk-libs:armhf and ubuntu-sdk-libs-dev:armhf  packages
[08:12] <Saviq> trainguards, lin 45 has some weird state in the spreadsheet, it landed, but spreadsheet says "Merging" still
[08:12] <Saviq> +e
[08:12] <bzoltan> ogra_: well that later is not really good http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.vivid/view/head:/sdk-libs-dev
[08:13] <bzoltan> ogra_:  i would separate this package to the real -dev packages and sdk-build-tools
[08:13] <Mirv> Saviq: hm
[08:13] <Saviq> Mirv, thanks
[08:13] <bzoltan> ogra_: because  nobody will need the -dev:armhf and the pythot:armhf :D in a chroot ...
[08:14] <robru> Saviq: Mirv let me take care of that, some race condition with the slasher while merging now
[08:14] <Mirv> Saviq: I marked it as Landed manually
[08:14] <Mirv> Saviq: ok undo
[08:14] <Mirv> I'll let robru handle it correctly :)
[08:14] <robru> Thanks
[08:14] <mvo> bzoltan: see #ubuntu-touch, this is making good progress
[08:15] <Mirv> Saviq: and thanks, unity8 is now no-change rebuild against Qt 5.4 (now Release Candidate)
[08:15] <Saviq> Mirv, sure, we still need to understand the missing symbol though?
[08:15] <ogra_> bzoltan, the point of that package is to provide everything the framework supports so my hand written Qt/C++ app can depend on that package to fully match everything the framework supports ... if you can make sure that still works, sure, go ahead and split it
[08:16] <bzoltan> ogra_:  Yes, we have to split it
[08:16] <ogra_> that wasnt my question :)
[08:17] <ogra_> can you split it in a way that the package can still fulfil its purpose ?
[08:17] <robru> Mirv: Saviq: should be good and shouldn't happen again ;-)
[08:17] <Saviq> robru, tx
[08:17] <robru> Saviq: you're welcome!
[08:18] <bzoltan> ogra_:  I am sure, but note that this package is broken right now .. it supports only x86 target development on x86 host
[08:18] <Mirv> Saviq: yes probably, I haven't been able to test yet and some packages will be missing in action because of new problems with the RC.
[08:18] <Saviq> ok
[08:19] <bzoltan> ogra_:  so the sdk-lib-dev is no good for crossbuild
[08:19] <Mirv> no oxide is the biggest new problem, but maybe after that unity8 now finishes building one can at least try something
[08:19] <ogra_> bzoltan, hmm, how would a split help with th arch issue ?
[08:20] <ogra_> also, did you explain that issue to mvo ?
[08:20] <bzoltan> ogra_:  in click chroot I would pull the libs-dev:armhf nd the sdk-build-tools:x86
[08:20] <bzoltan> ogra_:  yes, mvo is on the same page
[08:21] <ogra_> i dont really get that ... so you have a chroot ... enter that chroot and "apt-get install ubuntu-sdk-libs-dev" installs sdk-build-tools:x86 in the chroot ?
[08:22] <ogra_> oh, you could just have pointed to the other channel :P
[08:22] <bzoltan> ogra_: no, in my vew the -dev will not and should not pull the build tools.
[09:08]  * sil2100 wonders what nseeed means
[09:09] <ogra_> it's a boygroup
[09:24] <brendand> Mirv, silo 22 is a lot of code :)
[09:24] <Saviq> trainguards, can you please reconfigure vivid silo 1 for me, added some cmake goodness there
[09:24] <sil2100> Saviq: sure!
[09:30] <Mirv> brendand: yes it is, it's basically largely a rewrite of the backend that wasn't touched by upstream for 3 years since no-one used it.
[09:30] <davmor2> ogra_: Dec  2 15:45:06 ubuntu-phablet kernel: [   18.351167] type=1400 audit(1417535106.615:64): apparmor="DENIED" operation="open" profile="/usr/bin/mediascanner-service-2.0" name="/dev/video0" pid=1902 comm="gst-plugin-scan" requested_mask="w" denied_mask="w" fsuid=32011 ouid=1000  gets repeated 6 times and counts for 12 of the 13 DENIED in the syslog
[09:32] <sil2100> ogra_: hey hoo, you busy?
[09:32] <brendand> Mirv, SHIP IT!
[09:34] <Mirv> brendand: on the plus side Lorn is the original author of that code too
[09:37] <brendand> Mirv, well if testing checks out it can land
[10:11] <pstolowski> brendand, ping
[12:48] <jdstrand> why is mediascanner2 (via gst-plugin-scanner all of a sudden writing to /dev/video*?
[12:49] <jdstrand> was there a gstreamer update?
[12:52] <rsalveti> sil2100: it seems the spreadsheet is not getting updates from proposed migration
[12:52] <rsalveti> line 59 for example
[12:52] <rsalveti> it migrated 9h ago
[12:53]  * sil2100 checks
[12:53] <rsalveti> same for goget-ubuntu-touch
[12:53] <rsalveti> but that migrated just a few minutes ago
[12:54] <sil2100> rsalveti: yeah, it seems that after robru's modifications, it seems there's still a race that CI Train 'removes' the landing by auto-merge-and-cleaning before the spreadsheet can notice
[12:54] <sil2100> So the spreadsheet doesn't notice that it landed
[12:54] <rsalveti> hm, ok
[12:55] <sergiusens> rsalveti: btw, the other bug from that crazy proposed issue for goget-ubuntu-touch is that the spreadsheet marked the silo as landed even if it was stuck on proposed (aside from publishing something not marked as tested yes and the fact that the sync took place for a version number lower than the one in the release pocket)
[12:56] <rsalveti> right
[12:56] <rsalveti> can't trust spreadsheet no more
[12:59] <sil2100> Sadly...
[12:59] <Ursinha> sil2100: so, the silo files are gone from jenkins before the spreadsheet scripts can find it?
[13:00] <sil2100> Ursinha: yes, as the spreadsheet updates every 5 minutes
[13:00] <sil2100> Which is enough time for most silos to merge&clean
[13:00] <sil2100> I thought robru fixed that somehow
[13:01] <Ursinha> sil2100: is that information displayed on the dashboard somehow?
[13:02] <sil2100> Ursinha: it's only showing the status when it's merge and cleaning, then it disappears
[13:04] <bzoltan> sil2100: would you please educate me on a landing process related issue? I have two MRs for the UITK, both are 10-20 lines changes, so bitesize. Do I really have to ask for two silos and run the tests twice? Or is there a possibility to land them together?
[13:05] <bzoltan> sil2100:  I understand that RTM silos should deliver fixes for single issues.. but in my case the process does not sound logical
[13:05] <Ursinha> sil2100: okay, because it doesn't store information... so, as we move away from that we can change citrain scripts to update the ticket system when they are done, that can be easily done and the information will be displayed there
[13:10] <om26er> pstolowski, Hi!
[13:10] <om26er> pstolowski, regarding silo 6, I am not able to reproduce the bug.
[13:11] <sil2100> bzoltan: you mean related to the new 'silo bugfixes count' concept?
[13:11] <bzoltan> sil2100: yes
[13:11] <bzoltan> sil2100:  what is the drill?
[13:12] <sil2100> bzoltan: so, jibel should be able to tell you more as he's the person that's negotiating it with others - from what I remember, everyone starts off in the second group, so you can have approx ~3 fixes in a silo
[13:13] <sil2100> jibel: ^ ?
[13:13] <om26er> marcustomlinson, ^
[13:14] <pstolowski> om26er, hi! if it's about OA then yeah, best person to ask is marcustomlinson
[13:15] <om26er> pstolowski, its bug 1361221 so not OnlineAccounts
[13:15] <marcustomlinson> om26er: so you enable flight mode, then reboot the phone. Go to manage dash and you won't see Amazon for example. Then disable flight mode again. after about 10-20s the remote scopes (e.g. Amazon should pop up)
[13:17] <marcustomlinson> om26er: see the "Test remote scopes:" section of: https://wiki.ubuntu.com/Process/Merges/TestPlan/scopes
[13:18] <jibel> bzoltan, sil2100 that's the idea, start with 3 fixes. and if you can do several landings in a row without regression then you can land more stuff. It doesn't change that the fixes must have been accepted by the project team and targeted to a milestone.
[13:20] <bzoltan> jibel: For RTM I have 4 fixes unscheduled all together ... to Vivid I am landing dozens of fixes in bundle withour regression on weekly base.
[13:23] <bzoltan> jibel: In the vivid branch of the UITK we have fixed 50+ bugs since the last RTM release. It would be actually super cool to create and RTM silo for the trunk of the UITK and make a massive QA workshop on it. I did run 10+ full set AP tests on that and I am using the vivid release of the UITK for weeks. It brings values.
[13:25] <om26er> marcustomlinson, no, still can't reproduce :/
[13:26] <marcustomlinson> om26er: well you won't reproduce it on vivid nor with the silo applied on rtm. Just checking you're not using either of those?
[13:26] <om26er> marcustomlinson, no, I have rtm with no silo
[13:26] <marcustomlinson> om26er: you're saying the Manage Dash refreshes and Amazon appears when you disable flight mode?
[13:27] <om26er> marcustomlinson, finally, reproduced it :)
[13:27] <marcustomlinson> om26er: k good :)
[13:42] <sil2100> bzoltan: are all of those fixes approved by the product team?
[13:42] <bzoltan> sil2100: only one .. and that i just put in the rtm silo15
[13:43] <bzoltan> sil2100:  so it is a theoretical question as it came out :D
[13:44] <sil2100> bzoltan: we would love to get all fixes into RTM sooner or later, but every big batch of fixes carries risk - especially when the delta between vivid and ubuntu-rtm is huge, which is the case here
[13:45] <bzoltan> sil2100:  the only way to reduce the risk is to reduce the gap... and that can only be done by starting migration from vivid to RTM, at least the core components like UITK
[13:47] <bzoltan> sil2100:  yet again :) my old ranting .. we would need an RTM/staging ... like Debian has stable/testing/unstable ubuntu has lts/stable/dev
[13:47] <bzoltan> sil2100: but silos are kind of staging areas ...
[13:48] <om26er> marcustomlinson, Hi! I am looking at the code changes. Why is the silo fixing multiple bugs ?
[13:49] <om26er> https://code.launchpad.net/~unity-team/unity-scopes-api/staging-rtm/+merge/242050
[13:49] <marcustomlinson> om26er: why? because it is
[13:49] <marcustomlinson> om26er: not sure why thats a bad thing
[13:49] <marcustomlinson> pstolowski: ^
[13:50] <om26er> marcustomlinson, I thought for the rtm branch only approved bugs should go in ?
[13:50] <marcustomlinson> om26er: I'm pretty sure all of those are approved bugs
[13:54] <om26er> marcustomlinson, I talked to jibel and he thinks its fine to land it. Previously we had a strict rule of landing very limited changes.
[13:55] <marcustomlinson> om26er: cool thanks, that one's been sitting around for a while :)
[14:04] <bzoltan> sil2100: do you know what the status of the new ubuntu-seeds to vivid? mvo said that he push one and it will need an archive admin's ack.
[14:04] <sil2100> bzoltan: hm, didn't hear anything regarding this
[14:05] <bzoltan> sil2100:  what is the place where the queue can be followed?
[14:06] <sil2100> bzoltan: when was this discussion?
[14:07] <cjwatson> bzoltan: archive admin ack already happened
[14:07] <sil2100> bzoltan: normally all can be followed here:
[14:07] <cjwatson> 13:02 -queuebot:#ubuntu-release- New: accepted ubuntu-touch-meta [amd64] (vivid-proposed) [1.202]
[14:07] <cjwatson> 13:02 -queuebot:#ubuntu-release- New: accepted ubuntu-touch-meta [i386] (vivid-proposed) [1.202]
[14:07] <cjwatson> 13:02 -queuebot:#ubuntu-release- New: accepted ubuntu-touch-meta [armhf] (vivid-proposed) [1.202]
[14:07] <sil2100> https://launchpad.net/ubuntu/vivid/+queue
[14:07] <bzoltan> cjwatson: thank you
[14:07] <sil2100> Ok, excellent
[14:08] <cjwatson> It migrated in the last proposed-migration run, so will be publishing at the moment
[14:08] <cjwatson>  ubuntu-sdk-libs-tools | 1.202 | vivid-proposed/universe | amd64, armhf, i386
[14:09] <bzoltan> cjwatson: super ...one step closer to enable vivid development :)
[14:13] <bzoltan> rsalveti: do you know if there is a plan to promote a vivid emulator to the devel channel ?
[14:17] <pstolowski> marcustomlinson, all sorted out?
[14:17] <marcustomlinson> pstolowski: yes
[14:17] <sil2100> bzoltan: it's the plan as well
[14:18] <sil2100> bzoltan: we're trying to prepare for vivid promotion, and ten we'll promote for all our supported platforms
[14:18] <sil2100> bzoltan: so mako, krillin, manta, flo and emulator
[14:18] <bzoltan> sil2100:  do you know when we can expect it?
[14:18] <sil2100> bzoltan: we hope this week still
[14:18] <sil2100> davmor2: how's sanity testing going?
[14:18] <davmor2> sil2100: slowly
[14:20] <bzoltan> sil2100:  sounds good. I tell why it is important. There will be a  major training event in China and it would be important  to use the latest and the greatest of the images/tools. The organizers want to freeze the sdk (emulator and click chroots) included this week for that training.
[14:20] <sil2100> bzoltan: oh, so they want to use the devel images and tools for this? Not ubuntu-rtm based?
[14:23] <bzoltan> sil2100:  well.. let's not freak out anybody.. but our app dev story has a single weak point. The device image is Ubuntu RTM, the emulator is Ubuntu RTM, but the click chroot and the framework in it is Utopic :) more the previously discussed gap grows between Utopic and Ubuntu RTM bigger the  risk grows that an app compiled in the utopic chroot will noy work on an RTM emulator. That is what behind my talk.
[14:24] <bzoltan> sil2100:  So i would flag out this ... I hope nobody plans to run the Ubuntu RTM for long
[14:25] <bzoltan> sil2100:  so the Chinese trainging I would suggest to use 15.04 emulator with 15.04 images and 15.05 click chroots. If that is possible ...
[14:26] <sil2100> bzoltan: there are a few different problems everywhere indeed, but I'm still not sure what are the plans for an eventual rebase to devel for RTM
[14:26] <sil2100> While we're almost sure that RTM will stay around in one way or another
[14:29] <bzoltan> sil2100:  i do not want to freak out anybody :) I just hope that RTM will either be upgraded or dropped sooner than later
[14:29] <sil2100> It will be upgraded for sure ;) But the timeline for that might be a bit tricky
[14:37] <mterry> sil2100, hello!  I'm looking at the silo state for vivid/3 (line 57) and it says some packages failed to build.  But that's just unity8 on some arches, which I thought was expected behavior
[14:37] <mterry> (missing libpay2-dev or libhardware-dev depending on arch)
[14:41] <sil2100> mterry: oh, wait, let me take a look
[14:41] <sil2100> mterry: there's possibility that the new watch-ppa from robru is still causing trouble...
[15:13] <john-mcaleely> sil2100, want a vivid device tarball?
[15:14] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20141202-201baf8.changes
[15:14] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20141202-201baf8.tar.xz
[15:14] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-testresults-20141202-201baf8.ods
[15:21] <davmor2> john-mcaleely: no
[15:21] <sil2100> john-mcaleely: oh oh!
[15:25] <john-mcaleely> davmor2, ha
[15:25] <davmor2> john-mcaleely: I got enough to do thanks :)
[15:25] <sil2100> davmor2, brendand, jibel: I suppose those don't need QA sign-off for vivid, right? :)
[15:25] <john-mcaleely> so, this looks like some change for cyphermox , and a hybris fix for media playback
[15:26] <john-mcaleely> it has a test pass from me to bless it on its way
[15:26] <john-mcaleely> for what that's worth
[15:26] <davmor2> jibel: up to you dude :)
[15:30] <jibel> sil2100, right, we don't verify vivid device tarballs, just the complete image.
[15:30] <sil2100> john-mcaleely: ship-it!
[15:30] <john-mcaleely> sil2100, excellent thank you
[15:30] <john-mcaleely> ogra_, sil2100 is now ok from the machinery point of view?
[15:31] <ogra_> dunno ... sil2100 what did he break again ?
[15:31] <ogra_> :P
[15:31] <sil2100> ;)
[15:31] <ogra_> john-mcaleely, indeed, just go for it :)
[15:32] <john-mcaleely> ogra_, sil2100 gone for it. shipped.
[15:32] <john-mcaleely> thank you
[15:56] <sil2100> jibel, om26er: so, regarding silo 006 - I see that at least 2 bugs there don't seem to be approved from PT in the specific project part
[15:56] <sil2100> jibel, om26er: you guys sure that this silo is landable in rtm right now?
[15:58] <jibel> sil2100, yes, we don't want to waste dev time for silos that were ready to test and tagged ota-1. I added CSI tasks for these bugs, but they are not targeted to a milestone.
[16:07] <sil2100> jibel: so hm, it's not ready for landing then, right?
[16:18] <tedg> trainguards, vivid silo for line 62 pleas
[16:18] <tedg> please
[16:23] <sil2100> tedg: o/
[16:23] <sil2100> tedg: assigned
[16:24] <tedg> sil2100, Thanks!
[16:58] <sil2100> mterry: so, sorry it took so long (got distracted), but it seems you have added ubuntu-touch-meta as an additional source package to land in the silo
[16:58] <sil2100> mterry: and I think after robru's modifications, it expects this package to be around in the PPA during build
[16:58] <sil2100> robru: ^ ?
[16:59] <mterry> sil2100, ah...  I was just trying to document that there's an associated distro upload to go with the silo
[16:59] <sil2100> mterry: let's put that in the comments field I guess
[16:59] <sil2100> In the past it wouldn't fail, but now hm, I think the rules changed
[17:02] <robru> sil2100: really? old watch_ppa wouldn't fail if you specified a source package and then didn't upload it to the silo? that doesn't sound right to me at all. the older code was obsessed with checking things and failing if things were missing / unexpected.
[17:03] <sil2100> robru: I think that was the case, not completely sure - the publish job would fail though
[17:03] <sil2100> plars: ping
[17:04] <sil2100> popey: meeting, just in case!
[17:04] <popey> sorry, meeting over-running
[17:07] <robru> mterry: anyway, regardless of what old behavior used to be, currently if you list a source package in the sources column, the train expects to find that package in the silo. So just drop that from the spreadsheet column, then we can reconfigure and WATCH_ONLY rebuild and the silo should be fine.
[17:09] <mterry> robru, ok reconfiguring and will rebuild
[17:39] <robru> mterry: looking good? I saw the job succeeded, not sure why you're rebuilding unity8
[17:46] <balloons> ogra_, so I can't assign it to you, but https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1398913. Should be easy to grab those I hope
[17:48] <ogra_> balloons, great, triaged and assined
[17:48] <balloons> ty ty
[17:53] <mterry> robru, oh it's fine yah, I just wanted to make a dependency change, so rebuilt.  I'm still waiting on final merge approval
[17:53] <dobey> fginther: hey. any update on getting jenkins jobs running for unity-scope-click/rtm-14.09?
[18:02] <fginther> dobey, the work is blocked on properly creating the pbuilder chroots necessary to do these builds. I've completed some investigation, but need to do some follow up
[18:03] <fginther> dobey, I'll follow up when I have better info
[18:05] <dobey> fginther: oh, chroots for ubuntu-rtm?
[18:06] <dobey> fginther: yeah, that's also a problem in the SDK too. the click chroots are utopic, not ubuntu-rtm 14.09 :-/
[18:06] <bzoltan> dobey: fginther: I am already working on it
[18:07] <dobey> fginther: could we get them set up on utopic chroots to get it going, and get the rtm chroots issue pushed up to top end of priority list perhaps?
[18:21] <bzoltan> robru:  could you please publish the oxide from the silo13?
[18:22] <robru> bzoltan: done
[18:22] <bzoltan> robru:  Thank you
[18:22] <robru> bzoltan: you're welcome
[18:27] <robru> ogra_: so what's the deal with the three rtm silos that have qa approval? How do I tell which ones are really approved for publishing?
[18:30] <ogra_> robru, well, we discussed 6 and 7 in the meeting, they should both be good to go
[18:30] <ogra_> not sure about 10 ... that wasnt signed off when we had the meeting
[18:30] <ogra_> but if both linked bugs have the ota-1 tag that should be fine too ... please check that first
[18:31] <robru> ogra_: there's a big red note from sil2100 saying not to land 6 ;-)
[18:31] <sil2100> robru: yeah, it's not valid anymore ;)
[18:31] <ogra_> yes and thats why we had the meeting discussion
[18:31] <robru> ok
[18:31]  * sil2100 removed teh comment
[18:32] <sil2100> It seems it had Pat's blessing
[18:32] <sil2100> So all is cooool
[18:32] <robru> ogra_: neither of the bugs for silo 10 say ota1 but they both say rtm14
[18:32] <ogra_> yeah, we'll blame pat
[18:35] <ogra_> robru, hmm, better ask olli or pmcgowan, i see both of them have CSI tasks but dont seem to have been triaged there yet
[18:35] <robru> olli: pmcgowan: what's the status for silo rtm 10? neither of the linked bugs say ota1 but they both say rtm14. please let me know if that's clear to land
[18:36]  * sil2100 drives home
[18:36] <sil2100> Will send out the e-mail from home
[18:36] <sil2100> o/
[18:36] <robru> sil2100: goodnight
[18:36] <ogra_> robru, btw, the new thing is the CSI tasks ... the tags are dead
[18:36] <robru> ogra_: the whichy-whats?
[18:37] <ogra_> well, look at the bug :)
[18:37] <ogra_> the CSI tasks are supposed to replace the spreadsheet
[18:37] <ogra_> or rather https://bugs.launchpad.net/canonical-devices-system-image is sopposed to replace it
[18:37] <robru> ogra_: ah, neat
[18:38] <ogra_> that should make a lot of stuff easier
[18:38] <ogra_> there is a ML thread about it
[18:38] <ogra_> "improving bug management"
[18:38] <robru> ogra_: replace which spreadsheet?
[18:38] <ogra_> the "ollis list" one
[18:38] <robru> ah
[18:39] <robru> glad to hear more spreadsheets are going away ;-)
[18:39] <ogra_> better read the mail :)
[18:39] <ogra_> it has some details about milestones etc you need to know to check if a silo can land
[18:40] <ogra_> (obviously not executed for the silo 10 bugs yet, but they are on the list at least)
[18:42] <pmcgowan> robru, looking
[18:42] <robru> pmcgowan: thanks
[18:52] <robru> brb, early lunch while the sun is still shining
[18:54] <fginther> dobey, We can try with utopic, will let you know how it goes after a test
[18:57] <pmcgowan> robru, I acked silo 10 as we had previously oked for wishlist
[18:59] <dobey> fginther: ok, great. thanks. have just been building it locally on utopic in development anyway, because it's not clear how to create an lxc or sbuild chroot for ubuntu-rtm
[19:25] <robru> pmcgowan: thanks
[19:27] <cyphermox> what's that? ^^
[19:27] <pmcgowan> cyphermox, your urfkill crash fixes
[19:27] <cyphermox> ah, the old ones
[19:28] <pmcgowan> old hah, like a few weeks
[19:28] <cyphermox> yeah
[20:15] <davmor2> sil2100: manta has issues, flo, krillin, mako are good so far, just emulator to fire up
[20:16] <sil2100> Thanks!
[20:29] <davmor2> sil2100: emulator works as expected need to mod the tests in moztrap for that though so will fill it in tomorrow, too late now :)
[20:34] <tvoss__> trainguards, could someone please reconfigure silo 11?
[20:53] <robru> tvoss: OK done
[21:14] <tvoss> robru, ping
[21:15] <robru> tvoss: hey what's up?
[21:15] <tvoss> robru, hey :) could you reconfigure silo 11 for me?
[21:16] <robru> tvoss: like, again? I just did ;-)
[21:16] <tvoss> robru, oh sorry :)
[21:16] <tvoss> robru, and thanks
[21:16] <robru> tvoss: you're welcome
[21:16] <robru> tvoss: ah, looks like you quit irc and didn't see my message earlier
[21:17] <robru> No worries
[21:17] <tvoss> robru, yup, highly likely :)
[23:02] <cjwatson> The issues with old binaries never being removed from disk for ubuntu-rtm PPAs should be fixed now.
[23:04] <cjwatson> cjwatson@carob:/srv/launchpad.net-logs/production/haetae/lp_publish$ grep 'Total bytes freed' derived-process-death-row.log | sed 's/.*: //' | awk '{ total += $0 } END { print total }'
[23:04] <cjwatson> 39313045850
[23:04] <cjwatson> Not bad
[23:15] <robru> cjwatson: impressive
[23:16] <cjwatson> robru: that'll be since ubuntu-rtm was created, since process-death-row had never previously run for it
[23:16] <robru> fun
[23:16] <cjwatson> So that probably explains a number of incidents of needing quotas increased.
[23:17] <rsalveti> fginther: robru: does that mean I can't create new silos, and probably not landing new changes?
[23:17] <robru> cjwatson: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-003/+packages heh, 0 of 4GBs used.
[23:18] <cjwatson> right, that was particularly bad, looks like it was previously over even its expanded quota.
[23:18] <robru> rsalveti: well assignment might work, but builds definitely will fail. anything to do with citrain touching launchpad is disabled.
[23:18] <rsalveti> sigh
[23:18] <robru> rsalveti: if you're in a rush you can upload manually to the PPA.
[23:18] <cjwatson> and https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-022/+packages, good grief
[23:19] <rsalveti> robru: publishing will be broken anyway
[23:19] <cjwatson> cranked up to 10GB
[23:19] <rsalveti> so only way to make that work is by dputting into the archive directly
[23:19] <rsalveti> robru: fginther: what is the ETA to get it working again?
[23:20] <robru> rsalveti: two separate outages coinciding ;-) citrain will return once wgrant has completed a security audit of all recent train uploads as we've discovered the GPG key was compromised.
[23:20] <rsalveti> haha, and what is the ETA for that audit?
[23:20] <rsalveti> just to know if I should still care to land my stuff to day still
[23:21] <rsalveti> *today
[23:21] <wgrant> It's unlikely to happen today.
[23:21] <wgrant> Also, I'll take "things you don't say in public channels while the compromise isn't totally diagnosed yet"
[23:21] <robru> rsalveti: oh actually now that I think about it I guess the security audit is also causing fginther's issue, same deal because those different bots use the same lp account
[23:21] <robru> wgrant: but it's shut down though, no further harm can come from the old key
[23:22] <rsalveti> yeah, guess we shouldn't talk much more about it on public