[02:04] === trainguards: IMAGE 297 building (started: 20141023 02:05) === [03:04] === trainguards: RTM IMAGE 123 building (started: 20141023 03:05) === [03:24] === trainguards: IMAGE 297 DONE (finished: 20141023 03:25) === [03:24] === changelog: http://people.canonical.com/~ogra/touch-image-stats/297.changes === [04:14] === trainguards: RTM IMAGE 123 DONE (finished: 20141023 04:15) === [04:14] === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/123.changes === === gatox is now known as gatox2 [12:43] YIPPPIE !!! [12:43] the dashboard for 123 looks just AWESOME ! [12:43] * ogra_ dances [12:43] and we shoved off 30MB from the rootfs tarball [12:44] ogra_: sounds like the autopilot removal went well [12:44] yeah, there are a few more failures ... [12:44] but not significantly more [12:45] ogra_: Right, that sounds like test issues themselves not deps etc. [12:45] yep [12:50] ogra_: [12:50] ogra_: \o/ [12:50] ogra_: and the test results don't look so bad [12:51] There was a new toolkit in this image so that can also be the cause of some [12:51] sil2100, yeah [12:52] mvo, http://dashboard.ubuntu-ci:8080/smokeng/utopic/touch_stable/krillin/123:20141023:20141015-32e0f27/618/click_image_tests/ ... [12:53] (click on "testcase_test" to see some details or on consoleLog for a full log [12:53] trainguards: hi guys! could I get RTM silo 019 reconfigured? it has an extra project in it now (and a bunch more bugs associated) [12:58] ToyKeeper: hi. are you testing landing-005 unity-scope-click? i see it's still "under testing" on the board [12:59] dobey: It wasn't really supposed to be in that lane overnight, but yes, I'm about to start on it again. [13:00] pete-woods: sure [13:00] ToyKeeper: ok, thanks [13:01] Mirv: thanks :_ [13:01] :) [13:21] ogra_, moo [13:25] kenvandine: I see two silos from you for the same package. Does one include the changes from the other? Are they divergent branches? Can one be removed? [13:26] ToyKeeper, 14 includes 13 [13:30] mandel: ^ hey, I've requested an utopic silo for ubuntu-download-manager even if I dont fully understand where the utopic landing go (I guess bzr only? or -proposed for -updates?); I've never landed ubuntu-download-manager though, would one have to run the full test plan I've linked to? [13:30] the test plan is big, I wonder whether we should group landing of d-m [13:35] olli: hey, we've identified 3 security updates that should go to rtm. my thinking is this: we file 3 bugs (one for each), mark then critical with rtm tag. I then request 3 rtm silos (again, one for each) and then we upload to them, test and publish. does this sound reasonable? [13:35] olli: also, should I be pinging you for all of this all of the time? :) [13:35] I always seem to feel like I have exceptional cases... [13:39] brendand, baaa [13:42] ogra_, the ap silo doesn't need our sign-off, that's ok [13:45] lol [13:45] brendand, that landed long ago, but thanks :P [13:45] kenvandine: Thanks, it looks like we can just land 14 and ignore 13 (unless something specific to 14 fails). [13:45] ToyKeeper, cool, thanks [13:46] 13 was super low risk, 14 should be fine too but not trivial like 13 [13:50] jdstrand, yes re 3 sep bugs/silos [13:51] jdstrand, I think it makes sense to escalate security updates, not to impose control but to assure they don't get blocked [13:53] ogra_: so I had a chat with the music-app devs just a few moments ago [13:53] ogra_: they have been informed and will try to reproduce and fix, but they knew that there was something bad happening [13:53] plars: hey! :) [13:53] sil2100, awesome ! [13:53] sil2100: hi [13:53] plars: do you know why we don't have full test results for mako on ubuntu-rtm? Is it that badly broken? [13:53] sil2100, we've just reproduced so we can see what 'bad things' are happening :) [13:53] olli: ok, in process of doing the bugs/siloing. how does the escalation process work, what I just did? [13:54] sil2100, i'll update you if we make any progress [13:54] ahayzen: awesome :) [13:54] sil2100: let me look [13:59] sil2100: strange, it was split between 3 jobs running in parallel, one got as far as the usual looping test case on dropping letters: [13:59] 13:21:21.430 DEBUG dbus:352 - Selecting objects of type QQuickRectangle with attributes: {'objectName': 'gametilebox'} === boiko_ is now known as boiko [13:59] sil2100: but the other 2 failed to even come up in bootloader mode, so they didn't get installed. I'm retrying them now and will watch them carefully [14:01] Ouch [14:01] plars: thanks! [14:02] trainguards: hi folks. could I get another reconfigure of silo 019? (added another MR to it, but no new projects this time) [14:02] (that's RTM) [14:03] pete-woods: sure, doing [14:03] :) [14:03] jdstrand, sort of, got the 3 bug ids? [14:06] woo! [14:14] brendand, hey, I already tested silo 16, which solves https://bugs.launchpad.net/barajas/+bug/1356330 [14:14] Error: ubuntu bug 1356330 not found [14:15] brendand, I need now QA signoff [14:19] abeato, just waiting for it to arrive in our queue [14:19] brendand, ack [14:20] abeato, it should get picked up soon, i'll let you know [14:20] brendand, great, thanks [14:28] olli: yes. nss - 1384718, apt - 1384720, bash - 1384721 [14:28] bug 1384718, bug 1384720, bug 1384721 [14:28] bug 1384718 in nss (Ubuntu RTM) "Update to 3.17.1 to fix security issues and update certs" [Undecided,New] https://launchpad.net/bugs/1384718 [14:28] bug 1384720 in apt (Ubuntu RTM) "Update apt to 1.0.9.2ubuntu2 to fix security issues" [Undecided,New] https://launchpad.net/bugs/1384720 [14:28] bug 1384721 in bash (Ubuntu RTM) "Update bash to 4.3-11ubuntu1 to fix shellshock" [Undecided,New] https://launchpad.net/bugs/1384721 [14:30] kenvandine: I got a chance to look at the details for silos 13+14, and the bugs fixed in 13 aren't on olli's landing whitelist. [14:30] ToyKeeper, pat said he OK'd them [14:30] kenvandine: This means you'll either need to build 14 minus the changes in 13, or get special approval. [14:30] kenvandine: patmcgowan approved it? [14:31] yes [14:32] ToyKeeper, i have an email from him to confirm it [14:32] olli: also, I have an approved silo, but I didn't actually get an answer from the PM team on bug 1384349. did it show up on your list yesterday? if not, what should I be doing differently so I stop bothering you? [14:32] bug 1384349 in apparmor-easyprof-ubuntu (Ubuntu RTM) "apparmor denies app-specific download directory" [Critical,New] https://launchpad.net/bugs/1384349 [14:33] kenvandine: I think we can probably move ahead with it, just had to check. [14:33] ToyKeeper, thanks [14:34] ToyKeeper, kenvandine which bug is that [14:35] olli, 1376286 1382416 1377929 and 1383836 [14:36] all trivial and no risk fixes that were nice to get in [14:37] kenvandine: Wait, four of them? I thought there were only two plus a crit. [14:37] pmcgowan, good timing :) [14:37] ToyKeeper, well it's 4 bug fixes, one was just a translators comment [14:38] and another one got rid of a gvariant warning [14:38] nothing to test there [14:38] i thought all the bug numbers were on there though [14:39] kenvandine, yes we blessed those 4 for landing [14:40] pmcgowan: Thanks, wasn't sure since they weren't on the last whitelist I received for today's milestone. [14:43] ToyKeeper, they should be there, and if they have rtm14 with a touch-date tag they are good [14:48] robru: sil2100: line 32 is not reflecting the proper status [14:49] can i pester somebody for a silo for line 93? [14:49] yes, please :) [14:49] * Chipaca should learn manners from the bot [14:50] rsalveti: looking [14:50] rsalveti: yeah, google (or someone) ate teh formula for it [14:50] Restored [14:50] sil2100: cool, thanks [14:51] Actually, it even ate 2 formulas [14:58] cjwatson: hey, I'm getting file:///usr/share/unity8/Shell.qml:21:1: plugin cannot be loaded for module "Unity.Application": Cannot load library /usr/lib/i386-linux-gnu/qt5/qml/Unity/Application/libunityapplicationplugin.so: (dlopen: cannot load any more object with static TLS) [14:58] on RTM [14:58] cjwatson: do you remember what was the fix you had for utopic? [14:58] we might need to mirror that into RTM [14:59] rsalveti: yeah, you probably will. copy https://launchpad.net/ubuntu/+source/glibc/2.19-10ubuntu2 in with binaries [14:59] (no point rebuilding it, it's not as if there's a userspace ABI below glibc that it might be incompatible with) [14:59] cjwatson: great [15:00] ToyKeeper, sil2100 I updated https://docs.google.com/a/canonical.com/spreadsheets/d/1vtSSJZTIVEki9WsxTH_UxbE_PhdsEJl3Z0mn-UyDat0/edit#gid=0 [15:00] trainguards? [15:01] Chipaca? [15:01] Mirv: hi! [15:02] Mirv: i asked for a silo a few minutes back, am i being too impatient? :-/ [15:03] Chipaca: no, no, feel free to ping, most of our irc clients do not notice the queuebot's pings anyway, and I don't see a queuebot reacting to your new line anyway [15:03] Mirv: -queuebot/#ubuntu-ci-eng- trainguards, please assign line 93 for Chipaca [15:03] Chipaca: oh, right, there it is. [15:03] Chipaca: rtm-012 [15:03] Mirv: thanks [15:04] When sprinting it's hard to keep track of IRC when you're moving or in meetings ;) [15:04] So please feel free to ping when you see you're not getting the proper service [15:04] yes, less time spent looking at the scrollback [15:04] davmor2, hi! can uou please take a look at the silo 24 for rtm? is a fix for location service to deal with a race condition in the license acceptance [15:04] davmor2, it does not fix all the bugs that we have but it does remove that issue [15:08] abeato, your card didn't appear yet did you mark it as testing passed? [15:08] brendand, yes [15:08] brendand, line 32 in the spreadsheet [15:09] brendand, ah, not marked as QA sign-off required [15:09] brendand, we had a problem with the silo and moved the changes, so that messed things a bit [15:10] marked as QA aign-off required [15:10] sil2100: ogra_: I need to sync latest glibc from utopic into RTM in order to get emulator working again for RTM, and the change is minimal: https://launchpadlibrarian.net/186134877/glibc_2.19-10ubuntu1_2.19-10ubuntu2.diff.gz [15:10] sil2100: what is the process to follow in this case? [15:11] sil2100: get a silo, ask sign off and etc, or just copy them over? [15:11] rsalveti, lol, thats quite some comment for such a small change [15:11] rsalveti: let's make product management and QA aware of this [15:11] this is a bit of a facepalm for me, I remember pondering at the time whether we should preemptively sync it into RTM [15:11] ogra_: because it's a workaround [15:11] * ogra_ would just sync after asking QA for approval [15:12] because there wasn't a single obvious change that triggered the problem, we just tripped over a limit [15:12] rsalveti: normally I would just upload it directly, but I know QA doesn't like when that's happening for components that are used by so many other things [15:12] rsalveti: so I would opt for the silo way [15:12] davmor2, brendand, elopio, ToyKeeper: ^ [15:12] right, we all think and know it's safe enough, but I don't want to get managers calling me names later on :-) [15:12] rsalveti: exactly ;p [15:13] olli: Thanks, I'll use that spreadsheet to check bugs against. [15:14] rsalveti: anyway, if you can then prepare a landing for this and we can get it assigned [15:14] sil2100: done, silo 25 [15:14] olli: do we get permission to sync latest glibc to ubuntu-rtm? [15:14] olli: it's to fix the emulator, which IMO is pretty critical [15:15] asac, ^ [15:16] glibc? ... if that's going to need testing, I'd be happy to volunteer someone *else* to test it. ;P [15:16] rsalveti, cjwatson - can you confirm whether the affected component is even used on devices? [15:16] rsalveti, cjwatson - it reads to me like it's not, but i'm not 100% sure [15:16] brendand: glibc? hahahahaha [15:16] brendand: it's used everywhere (libc), but the change is minimal and just a bump into the TLS slots [15:17] brendand: glibc is the system's fundamental C library [15:17] but if you want to test what it affects, that's basically everything [15:17] :-) [15:18] sil2100: how can we assess the impact? [15:18] rsalveti: ? [15:19] rsalveti, what testing have you done? === charles_ is now known as charles [15:19] asac, well ... if the system still runs it is good :) [15:19] ogra_: sil2100: can it be backed out? [15:19] * ogra_ doubts you can really assess it [15:19] indeed, we could roll back worst case [15:19] in case it goes havoc? [15:20] easily? [15:20] https://launchpadlibrarian.net/186134877/glibc_2.19-10ubuntu1_2.19-10ubuntu2.diff.gz [15:20] iits just a number in a variable [15:20] see the diff, it's just bumping the amount of TLS slots [15:20] tiny enough to back out if needed [15:20] sil2100: could you reconfigure rtm silo 11 please? I added a new package [15:20] brendand: tested with the emulator and with the device [15:20] Whenever I see "glibc update", I suddenly feel like calling in sick. ;P [15:20] opened apps, used the system, no issues [15:20] rsalveti: with this, will emulator work flawlessly? [15:21] asac: it'll boot [15:21] e.g. whats the gain we get from it?> [15:21] asac: emulator is completely broken on RTM [15:21] asac, a working emulator [15:21] rsalveti: what broke it? [15:21] asac: we started having more processes using TLS slots [15:21] then we got into glibc's limit [15:22] probably caused by our graphic stack [15:22] rsalveti: do we leak threads? [15:22] asac: it's not leak [15:22] asac: read the diff [15:22] asac: https://launchpadlibrarian.net/186134877/glibc_2.19-10ubuntu1_2.19-10ubuntu2.diff.gz [15:22] rsalveti, which part of the graphics stack? [15:22] brendand, qtmir [15:22] brendand: mir and qt [15:23] rsalveti: well i understand waht the patch does [15:23] rsalveti: i wonder why we hit that bound in our stack suddenly [15:23] rsalveti, the diff calls out X11 and Mesa [15:23] rsalveti: which component consumes so many TLS slots [15:23] and if we checked that thats the expected behaviour of that component [15:23] not sure which component started doing that, could be caused by base changes on other packages, mir, qtmir, qt [15:23] hard to know [15:24] rsalveti: isnt this a per process limit? [15:24] if so we should see which process isnt getting enough slots [15:24] asac: I tried to track down the precise cause at the time and failed, but I'm nevertheless confident that it's the proper fix [15:24] I believe it is a system-wide limit [15:24] so it's extremely difficult to track down, but the landing of this glibc change in utopic was a non-event [15:25] asac: this happens when loading all the libraries, and in this case, this was the one that gave the error (when starting unity8): [15:25] file:///usr/share/unity8/Shell.qml:21:1: plugin cannot be loaded for module "Unity.Application": Cannot load library /usr/lib/i386-linux-gnu/qt5/qml/Unity/Application/libunityapplicationplugin.so: (dlopen: cannot load any more object with static TLS) [15:25] brendand, also python ... they are just examples ... in fact everything using TLS could be added there [15:25] ok. for the record i think its fine. just thought maybe we see a bug here that we might want to also nail while we see it (like mir leaking threads that consume more and more slots) [15:25] and yes, we can trivially back this out if it fails [15:25] absolutely trivially [15:25] copy the old version back in [15:25] yeah [15:26] it would be the responsible thing to do to try it out in a silo of course [15:26] but it will be fine [15:26] well, in a silo or by just installing the packages directly from utopic, whatever [15:26] cjwatson: does infinity know if this is per-process or system wide? if it system wide i am fully +1; otherwise would be nice to talk to the compnent owner that does it [15:26] we can build an image to have it isolated to test [15:26] but still +1 [15:26] olli: ^ [15:26] if that makes feel people better [15:26] yeah, so i am sure brendand will test the silo [15:27] asac: my understanding from the Fedora bug was that it is system-wide, but I'm checking [15:27] it's static TLS when loading the libs, you can track down by each lib [15:27] and see who actually is using more now [15:27] asac, we can give the silo a quick test [15:27] but hard to track as it could be a change in cpp related components [15:27] and not sure how worthy is it [15:27] rsalveti: do we know when this started? [15:28] asac: I think it started with a new qtmir upload, but I didn't track that down in details [15:28] rsalveti: when was that? who did that upload? [15:28] asac: it's not necessarily something that started and used by qtmir itself [15:28] i guess lets land and file a bug for qtmir to give us a story what is going on [15:29] not sure if boost could affect that or whatever [15:29] hmm [15:29] I don't think it's reasonable to try to pin this down to a specific process [15:29] working around it will be worse than just bumping the limit in glibc [15:29] in this case [15:29] yeah [15:29] it might be a quite complicated fix [15:29] https://sourceware.org/ml/libc-alpha/2014-10/msg00134.html has more technical details, and it is too complicated for me [15:29] sourceware.org bug 2014 in translator "cannot use backslash for escape sequences" [Normal,Resolved: fixed] [15:29] davmor2: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-012/+packages [15:29] thank you ubot5 go away [15:29] ok, well. as i said I am +1 on landing this in all cases [15:30] just wonder if its worth spinning a foloow up effort to get us a good explain [15:30] we *think* it is a per-process limit but it's hard to tell for sure [15:30] I'm not sure we have company-internal expertise on this ... [15:30] I acknowledged at the time that I was cargo-culting from Fedora :) [15:31] :-) [15:31] anyway, silo is ready to be tested [15:31] sil2100: ^^ [15:31] silo 25 [15:31] the upstream glibc discussion goes into suggestions of better fixes involving TLS Descriptors [15:32] again I'm afraid it quickly gets into territory I'm not familiar with though [15:32] cjwatson: rsalveti: is there a bug that we should approve to follow process? [15:32] talking to olli [15:32] abeato, https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1378397 did not get approval for landing this week [15:32] Ubuntu bug 1378397 in gst-plugins-base1.0 (Ubuntu) " video thumbnails are not generated for some divx files " [High,Confirmed] [15:32] asac: originally was bug 1375555 [15:32] rsalveti: who owns qtmir? [15:32] bug 1375555 in glibc (Ubuntu) "global static TLS slot limit breaks the x86 emulator" [Critical,Fix released] https://launchpad.net/bugs/1375555 [15:32] asac: yes, we can have a bugtask for RTM [15:32] brendand, it was on the list [15:32] ok thats fine [15:33] asac: kgunn [15:33] the one in the email [15:33] kgunn: around? [15:33] brendand, 10/23 planning [15:33] olli: asac: there's a bug task for RTM in there (bug 1375555) [15:33] bug 1375555 in glibc (Ubuntu RTM) "global static TLS slot limit breaks the x86 emulator" [Critical,Confirmed] https://launchpad.net/bugs/1375555 [15:34] brendand, it is actually https://bugs.launchpad.net/ubuntu/+source/mediaplayer-app/+bug/1355095 [15:34] Ubuntu bug 1355095 in Media Hub "mediaplayer hangs on fast-forward" [Critical,Triaged] [15:34] rsalveti: brendand: please start testing silo; we want to brief victor on this before hitting publish [15:34] but think there wont be an issue [15:34] yup [15:34] rsalveti: and yes, please add an RTM task [15:35] abeato, well you can help speed things up by mentioning the right bug *somewhere* in the silo (description, changelog, anywhere) [15:35] abeato, thanks for clarifying though [15:35] brendand, sorry, it is a bit messy because there are replicated bugs in barajas [15:36] asac: rsalveti qtmir, yep...what's needed? [15:37] kgunn: read bug 1375555 [15:37] bug 1375555 in glibc (Ubuntu RTM) "global static TLS slot limit breaks the x86 emulator" [Critical,Confirmed] https://launchpad.net/bugs/1375555 [15:37] kgunn: one qtmir update started to use more tls static slots [15:37] might be caused by an update on some other components, optimizations, or cpp/boost related [15:38] static slots for graphic is used everywhere for optimizations [15:38] kgunn: check the last comment in bug https://launchpad.net/bugs/1375555 [15:38] Ubuntu bug 1375555 in glibc (Ubuntu RTM) "global static TLS slot limit breaks the x86 emulator" [Critical,Confirmed] [15:38] kgunn: scared that we see symptoms of something that we can't explain vs. can explain [15:38] cant explain might mean we have a bug like a threads leaking etc. [15:39] this is not threads leaking [15:39] ok :) [15:39] but not sure :)... really just trying to see if there is something really in it that we are now covering with the libc patch [15:40] kgunn: guess rsalveti is better to tell you what this is about [15:40] it's not threads leaking, I think it's more like more things using dlopen [15:40] as far as I remember from looking at this last, this could be triggered by an object of the right kind (handwave) having an extra dlopen call [15:41] cjwatson: iirc the static slots are allocated when loading the library [15:41] or rather, loading an extra library with dlopen [15:41] josharenson: ^ [15:41] I'm guessing a bit, just saying I really don't think it's anything of the nature of a leak [15:41] kgunn: josharenson: bug was reported end of september ... not sure what happened then [15:41] yeah [15:41] it's more analogous to the structure of the object code [15:41] asac: at the time I checked RTM and the problem wasn't present there [15:42] presumably something that propagated in since then [15:42] probably with qtmir as well [15:42] the Fedora bug is more useful reading here [15:43] though read it all the way through if you're going to read any of it since it goes through a fair bit of diagnosis [15:43] there are many things that could cause the use of more TLS slots. Even something using more boost code. [15:43] https://bugzilla.redhat.com/show_bug.cgi?id=1124987 [15:43] yeah; i think IF this is really a qtmir caused symptom then qtmir folks are best to know what happened since then [15:43] and can make sense out of it [15:44] kgunn: josharenson: ^ [15:45] asac: right, to me it's simply a double check of is this what we expected [15:45] give us some time [15:46] kgunn: yeah for me this is just a post-process thingy... won't block the landing because of that investigation [15:46] kgunn: as long as it happens its fine [15:46] think we are aligned === karni is now known as Guest94428 === Guest94428 is now known as karni_ [15:56] mdeslaur: ^ [15:57] I wonder why mdeslaur is listed as the lander for bash [15:57] isn't* [15:57] thanks [15:58] jdstrand: because cell b93 is left blank [16:00] abeato, my krillin is totally stuck [16:00] brendand, :/ [16:00] abeato, and unity 8 just rebooted [16:01] asac, cjwatson, so victor is a bit concerned about that change [16:01] brendand, ah... it actually took a lot of time for me to get unity 8 after flashing this morning [16:01] no idea way [16:01] asking whether we have something similar to a device tarball for the emulator [16:01] robru: weird, I see it as filled in hear [16:01] rsalveti, ^ [16:01] here [16:01] weird typo [16:01] * jdstrand updates the cell [16:02] olli: yes we have, but that can contain any change related with glibc [16:02] jdstrand: must be some sync glitch in the spreadsheet then [16:02] robru: well, or network. the spreadsheet was stuck on 'Working' for quite a while [16:03] Yeah [16:03] because this is a core part of the rootfs [16:03] robru: I removed a letter then added it back and pressed 'Enter'. hopefully it is there now [16:03] rsalveti, "can't contain" then [16:03] makes sense [16:03] olli: ask him to read the bug and patch [16:07] kenvandine_: Silo rtm-014 appears to fix all four low-priority bugs, but does *not* seem to fix the launcher reset bug. It still has the "needs a reboot" text and doesn't update until after a reboot. [16:08] ToyKeeper, that's what is expected now [16:08] jdstrand: doesn't look like it worked, but i put the name in and reconfigured for you, try reloading the page i guess [16:08] ToyKeeper, it's only part of the bug fix === chihchun_afk is now known as chihchun [16:08] without it, it doesn't reset the launcher at all now [16:08] kenvandine_: Is there any change in behavior at all yet? [16:08] weird [16:08] robru: thanks [16:08] ToyKeeper, there is a unity8 landing that fixes the other [16:08] jdstrand: you're welcome! [16:08] ToyKeeper, nope... just fixes resetting the launcher [16:09] kenvandine_: Okay. So, it *does* reset the launcher after a reboot with rtm-014 installed, and it doesn't appear to break anything. [16:09] ToyKeeper, once the unity8 fix lands, we can land another branch that removes the reboot text [16:09] ToyKeeper, great... it's broken without it :) [16:10] kenvandine_: Okay, that wasn't clear, I thought this included the complete fix for bug 1376707. [16:10] bug 1376707 in unity8 (Ubuntu RTM) "Launcher needs to dynamically respond to reset" [Critical,In progress] https://launchpad.net/bugs/1376707 [16:10] ToyKeeper, sorry about that, it still matched the test plan [16:10] i'll update the test plan when we are landing the reboot text change [16:10] abeato, second try to launch the video - mediaplayer hanging again [16:11] abeato, pegging the cpu [16:12] brendand, which video are you trying? [16:13] abeato, the one in the bug [16:13] abeato, now it plays but that was twice it failed badly [16:14] kenvandine_: ^ I assume you're publishing 14 but i can if you're busy/not around [16:14] robru, i got it [16:14] cool [16:14] robru: could you please rconfigure silo 11 for rtm (line 19) as we added a new package [16:15] sure [16:15] brendand, when doing fast forward? [16:15] abeato, no just when loading the video [16:15] abeato, the first time unity8 rebooted [16:15] abeato, the second time the video never started to play [16:16] bfiller: done [16:16] abeato, i'll see how reproducible it is [16:16] trainguards: can i get a silo for row 95 [16:17] brendand, ok, I'm trying too [16:17] kgunn: sure [16:17] abeato, and now the video stopped playing [16:17] and media hub is pegging the cpu [16:18] kgunn: although, no MP:s in tehre or anything [16:18] robru: thanks [16:18] bfiller: you're welcome [16:18] Mirv: heh I just noticed that too ;-) [16:19] robru: morning! :) [16:19] it's lunch time here [16:19] Mirv: hello! [16:21] abeato, i don't think this is okay [16:21] I just got this trying to upload to a silo: Rejected: Signer has no upload rights to this PPA. [16:21] abeato, i haven't succesfully played the video for more than 5 minutes yet [16:21] fyi, I've been the primary lander for the security team, but am training mdeslaur now [16:22] mdeslaur: asac or slangasek will need to add you to ~ci-train-ppa-service [16:22] mdeslaur should be on the team so he can (also) provide security updates via the citrain mechanism [16:23] cjwatson, jdstrand, mdeslaur, asac: done [16:23] slangasek: thanks [16:25]