[02:04] <imgbot> [03:04] <imgbot> [03:24] <imgbot> [03:24] <imgbot> [04:14] <imgbot> [04:14] <imgbot> [12:43] <ogra_> YIPPPIE !!!
[12:43] <ogra_> the dashboard for 123 looks just AWESOME !
[12:43]  * ogra_ dances
[12:43] <ogra_> and we shoved off 30MB from the rootfs tarball
[12:44] <veebers> ogra_: sounds like the autopilot removal went well
[12:44] <ogra_> yeah, there are a few more failures ...
[12:44] <ogra_> but not significantly more
[12:45] <veebers> ogra_: Right, that sounds like test issues themselves not deps etc.
[12:45] <ogra_> yep
[12:50] <sil2100> ogra_:
[12:50] <sil2100> ogra_: \o/
[12:50] <sil2100> ogra_: and the test results don't look so bad
[12:51] <sil2100> There was a new toolkit in this image so that can also be the cause of some
[12:51] <ogra_> sil2100, yeah
[12:52] <ogra_> mvo, http://dashboard.ubuntu-ci:8080/smokeng/utopic/touch_stable/krillin/123:20141023:20141015-32e0f27/618/click_image_tests/ ...
[12:53] <ogra_> (click on "testcase_test" to see some details or on consoleLog for a full log
[12:53] <pete-woods> 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] <dobey> ToyKeeper: hi. are you testing landing-005 unity-scope-click? i see it's still "under testing" on the board
[12:59] <ToyKeeper> dobey: It wasn't really supposed to be in that lane overnight, but yes, I'm about to start on it again.
[13:00] <Mirv> pete-woods: sure
[13:00] <dobey> ToyKeeper: ok, thanks
[13:01] <pete-woods> Mirv: thanks :_
[13:01] <pete-woods> :)
[13:21] <brendand> ogra_, moo
[13:25] <ToyKeeper> 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] <kenvandine> ToyKeeper, 14 includes 13
[13:30] <lool> 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] <lool> the test plan is big, I wonder whether we should group landing of d-m
[13:35] <jdstrand> 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] <jdstrand> olli: also, should I be pinging you for all of this all of the time? :)
[13:35] <jdstrand> I always seem to feel like I have exceptional cases...
[13:39] <ogra_> brendand, baaa
[13:42] <brendand> ogra_, the ap silo doesn't need our sign-off, that's ok
[13:45] <ogra_> lol
[13:45] <ogra_> brendand, that landed long ago, but thanks :P
[13:45] <ToyKeeper> kenvandine: Thanks, it looks like we can just land 14 and ignore 13 (unless something specific to 14 fails).
[13:45] <kenvandine> ToyKeeper, cool, thanks
[13:46] <kenvandine> 13 was super low risk, 14 should be fine too but not trivial like 13
[13:50] <olli> jdstrand, yes re 3 sep bugs/silos
[13:51] <olli> jdstrand, I think it makes sense to escalate security updates, not to impose control but to assure they don't get blocked
[13:53] <sil2100> ogra_: so I had a chat with the music-app devs just a few moments ago
[13:53] <sil2100> ogra_: they have been informed and will try to reproduce and fix, but they knew that there was something bad happening
[13:53] <sil2100> plars: hey! :)
[13:53] <ogra_> sil2100, awesome !
[13:53] <plars> sil2100: hi
[13:53] <sil2100> plars: do you know why we don't have full test results for mako on ubuntu-rtm? Is it that badly broken?
[13:53] <ahayzen> sil2100, we've just reproduced so we can see what 'bad things' are happening :)
[13:53] <jdstrand> olli: ok, in process of doing the bugs/siloing. how does the escalation process work, what I just did?
[13:54] <ahayzen> sil2100, i'll update you if we make any progress
[13:54] <sil2100> ahayzen: awesome :)
[13:54] <plars> sil2100: let me look
[13:59] <plars> 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] <plars> 13:21:21.430 DEBUG dbus:352 - Selecting objects of type QQuickRectangle with attributes: {'objectName': 'gametilebox'}
[13:59] <plars> 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] <sil2100> Ouch
[14:01] <sil2100> plars: thanks!
[14:02] <pete-woods> trainguards: hi folks. could I get another reconfigure of silo 019? (added another MR to it, but no new projects this time)
[14:02] <pete-woods> (that's RTM)
[14:03] <sil2100> pete-woods: sure, doing
[14:03] <pete-woods> :)
[14:03] <olli> jdstrand, sort of, got the 3 bug ids?
[14:06] <pete-woods> woo!
[14:14] <abeato> brendand, hey, I already tested silo 16, which solves https://bugs.launchpad.net/barajas/+bug/1356330
[14:15] <abeato> brendand, I need now QA signoff
[14:19] <brendand> abeato, just waiting for it to arrive in our queue
[14:19] <abeato> brendand, ack
[14:20] <brendand> abeato, it should get picked up soon, i'll let you know
[14:20] <abeato> brendand, great, thanks
[14:28] <jdstrand> olli: yes. nss - 1384718, apt - 1384720, bash - 1384721
[14:28] <jdstrand> bug 1384718, bug 1384720, bug 1384721
[14:30] <ToyKeeper> 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] <kenvandine> ToyKeeper, pat said he OK'd them
[14:30] <ToyKeeper> kenvandine: This means you'll either need to build 14 minus the changes in 13, or get special approval.
[14:30] <ToyKeeper> kenvandine: patmcgowan approved it?
[14:31] <kenvandine> yes
[14:32] <kenvandine> ToyKeeper, i have an email from him to confirm it
[14:32] <jdstrand> 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:33] <ToyKeeper> kenvandine: I think we can probably move ahead with it, just had to check.
[14:33] <kenvandine> ToyKeeper, thanks
[14:34] <olli> ToyKeeper, kenvandine which bug is that
[14:35] <kenvandine> olli, 1376286 1382416 1377929 and 1383836
[14:36] <kenvandine> all trivial and no risk fixes that were nice to get in
[14:37] <ToyKeeper> kenvandine: Wait, four of them?  I thought there were only two plus a crit.
[14:37] <kenvandine> pmcgowan, good timing :)
[14:37] <kenvandine> ToyKeeper, well it's 4 bug fixes, one was just a translators comment
[14:38] <kenvandine> and another one got rid of a gvariant warning
[14:38] <kenvandine> nothing to test there
[14:38] <kenvandine> i thought all the bug numbers were on there though
[14:39] <pmcgowan> kenvandine, yes we blessed those 4 for landing
[14:40] <ToyKeeper> pmcgowan: Thanks, wasn't sure since they weren't on the last whitelist I received for today's milestone.
[14:43] <pmcgowan> ToyKeeper, they should be there, and if they have rtm14 with a touch-date tag they are good
[14:48] <rsalveti> robru: sil2100: line 32 is not reflecting the proper status
[14:49] <Chipaca> can i pester somebody for a silo for line 93?
[14:49] <Chipaca> yes, please :)
[14:49]  * Chipaca should learn manners from the bot
[14:50] <sil2100> rsalveti: looking
[14:50] <sil2100> rsalveti: yeah, google (or someone) ate teh formula for it
[14:50] <sil2100> Restored
[14:50] <rsalveti> sil2100: cool, thanks
[14:51] <sil2100> Actually, it even ate 2 formulas
[14:58] <rsalveti> 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] <rsalveti> on RTM
[14:58] <rsalveti> cjwatson: do you remember what was the fix you had for utopic?
[14:58] <rsalveti> we might need to mirror that into RTM
[14:59] <cjwatson> rsalveti: yeah, you probably will.  copy https://launchpad.net/ubuntu/+source/glibc/2.19-10ubuntu2 in with binaries
[14:59] <cjwatson> (no point rebuilding it, it's not as if there's a userspace ABI below glibc that it might be incompatible with)
[14:59] <rsalveti> cjwatson: great
[15:00] <olli> ToyKeeper, sil2100 I updated https://docs.google.com/a/canonical.com/spreadsheets/d/1vtSSJZTIVEki9WsxTH_UxbE_PhdsEJl3Z0mn-UyDat0/edit#gid=0
[15:00] <Chipaca> trainguards?
[15:01] <Mirv> Chipaca?
[15:01] <Chipaca> Mirv: hi!
[15:02] <Chipaca> Mirv: i asked for a silo a few minutes back, am i being too impatient? :-/
[15:03] <Mirv> 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] <Chipaca> Mirv: -queuebot/#ubuntu-ci-eng- trainguards, please assign line 93 for Chipaca
[15:03] <Mirv> Chipaca: oh, right, there it is.
[15:03] <Mirv> Chipaca: rtm-012
[15:03] <Chipaca> Mirv: thanks
[15:04] <sil2100> When sprinting it's hard to keep track of IRC when you're moving or in meetings ;)
[15:04] <sil2100> So please feel free to ping when you see you're not getting the proper service
[15:04] <Mirv> yes, less time spent looking at the scrollback
[15:04] <mandel> 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] <mandel> davmor2, it does not fix all the bugs that we have but it does remove that issue
[15:08] <brendand> abeato, your card didn't appear yet did you mark it as testing passed?
[15:08] <abeato> brendand, yes
[15:08] <abeato> brendand, line 32 in the spreadsheet
[15:09] <abeato> brendand, ah, not marked as QA sign-off required
[15:09] <abeato> brendand, we had a problem with the silo and moved the changes, so that messed things a bit
[15:10] <abeato> marked as QA aign-off required
[15:10] <rsalveti> 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] <rsalveti> sil2100: what is the process to follow in this case?
[15:11] <rsalveti> sil2100: get a silo, ask sign off and etc, or just copy them over?
[15:11] <ogra_> rsalveti, lol, thats quite some comment for such a small change
[15:11] <sil2100> rsalveti: let's make product management and QA aware of this
[15:11] <cjwatson> 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] <rsalveti> ogra_: because it's a workaround
[15:11]  * ogra_ would just sync after asking QA for approval 
[15:12] <cjwatson> because there wasn't a single obvious change that triggered the problem, we just tripped over a limit
[15:12] <sil2100> 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] <sil2100> rsalveti: so I would opt for the silo way
[15:12] <sil2100> davmor2, brendand, elopio, ToyKeeper: ^
[15:12] <rsalveti> 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] <sil2100> rsalveti: exactly ;p
[15:13] <ToyKeeper> olli: Thanks, I'll use that spreadsheet to check bugs against.
[15:14] <sil2100> rsalveti: anyway, if you can then prepare a landing for this and we can get it assigned
[15:14] <rsalveti> sil2100: done, silo 25
[15:14] <sil2100> olli: do we get permission to sync latest glibc to ubuntu-rtm?
[15:14] <sil2100> olli: it's to fix the emulator, which IMO is pretty critical
[15:15] <olli> asac, ^
[15:16] <ToyKeeper> glibc?  ... if that's going to need testing, I'd be happy to volunteer someone *else* to test it.  ;P
[15:16] <brendand> rsalveti, cjwatson - can you confirm whether the affected component is even used on devices?
[15:16] <brendand> rsalveti, cjwatson - it reads to me like it's not, but i'm not 100% sure
[15:16] <cjwatson> brendand: glibc?  hahahahaha
[15:16] <rsalveti> brendand: it's used everywhere (libc), but the change is minimal and just a bump into the TLS slots
[15:17] <cjwatson> brendand: glibc is the system's fundamental C library
[15:17] <rsalveti> but if you want to test what it affects, that's basically everything
[15:17] <rsalveti> :-)
[15:18] <asac> sil2100: how can we assess the impact?
[15:18] <asac> rsalveti: ?
[15:19] <brendand> rsalveti, what testing have you done?
[15:19] <ogra_> asac, well ... if the system still runs it is good :)
[15:19] <asac> ogra_: sil2100: can it be backed out?
[15:19]  * ogra_ doubts you can really assess it
[15:19] <ogra_> indeed, we could roll back worst case
[15:19] <asac> in case it goes havoc?
[15:20] <asac> easily?
[15:20] <rsalveti> https://launchpadlibrarian.net/186134877/glibc_2.19-10ubuntu1_2.19-10ubuntu2.diff.gz
[15:20] <ogra_> iits just a number in a variable
[15:20] <rsalveti> see the diff, it's just bumping the amount of TLS slots
[15:20] <ogra_> tiny enough to back out if needed
[15:20] <bfiller> sil2100: could you reconfigure rtm silo 11 please? I added a new package
[15:20] <rsalveti> brendand: tested with the emulator and with the device
[15:20] <ToyKeeper> Whenever I see "glibc update", I suddenly feel like calling in sick.  ;P
[15:20] <rsalveti> opened apps, used the system, no issues
[15:20] <asac> rsalveti: with this, will emulator work flawlessly?
[15:21] <rsalveti> asac: it'll boot
[15:21] <asac> e.g. whats the gain we get from it?>
[15:21] <rsalveti> asac: emulator is completely broken on RTM
[15:21] <ogra_> asac, a working emulator
[15:21] <asac> rsalveti: what broke it?
[15:21] <rsalveti> asac: we started having more processes using TLS slots
[15:21] <rsalveti> then we got into glibc's limit
[15:22] <rsalveti> probably caused by our graphic stack
[15:22] <asac> rsalveti: do we leak threads?
[15:22] <rsalveti> asac: it's not leak
[15:22] <rsalveti> asac: read the diff
[15:22] <rsalveti> asac: https://launchpadlibrarian.net/186134877/glibc_2.19-10ubuntu1_2.19-10ubuntu2.diff.gz
[15:22] <brendand> rsalveti, which part of the graphics stack?
[15:22] <ogra_> brendand, qtmir
[15:22] <rsalveti> brendand: mir and qt
[15:23] <asac> rsalveti: well i understand waht the patch does
[15:23] <asac> rsalveti: i wonder why we hit that bound in our stack suddenly
[15:23] <brendand> rsalveti, the diff calls out X11 and Mesa
[15:23] <asac> rsalveti: which component consumes so many TLS slots
[15:23] <asac> and if we checked that thats the expected behaviour of that component
[15:23] <rsalveti> not sure which component started doing that, could be caused by base changes on other packages, mir, qtmir, qt
[15:23] <rsalveti> hard to know
[15:24] <asac> rsalveti: isnt this a per process limit?
[15:24] <asac> if so we should see which process isnt getting enough slots
[15:24] <cjwatson> 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] <cjwatson> I believe it is a system-wide limit
[15:24] <cjwatson> so it's extremely difficult to track down, but the landing of this glibc change in utopic was a non-event
[15:25] <rsalveti> 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] <rsalveti> 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] <ogra_> brendand, also python ... they are just examples ... in fact everything using TLS could be added there
[15:25] <asac> 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] <cjwatson> and yes, we can trivially back this out if it fails
[15:25] <cjwatson> absolutely trivially
[15:25] <cjwatson> copy the old version back in
[15:25] <ogra_> yeah
[15:26] <cjwatson> it would be the responsible thing to do to try it out in a silo of course
[15:26] <cjwatson> but it will be fine
[15:26] <cjwatson> well, in a silo or by just installing the packages directly from utopic, whatever
[15:26] <asac> 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] <ogra_> we can build an image to have it isolated to test
[15:26] <asac> but still +1
[15:26] <asac> olli: ^
[15:26] <ogra_> if that makes feel people better
[15:26] <asac> yeah, so i am sure brendand will test the silo
[15:27] <cjwatson> asac: my understanding from the Fedora bug was that it is system-wide, but I'm checking
[15:27] <rsalveti> it's static TLS when loading the libs, you can track down by each lib
[15:27] <rsalveti> and see who actually is using more now
[15:27] <brendand> asac, we can give the silo a quick test
[15:27] <rsalveti> but hard to track as it could be a change in cpp related components
[15:27] <rsalveti> and not sure how worthy is it
[15:27] <asac> rsalveti: do we know when this started?
[15:28] <rsalveti> asac: I think it started with a new qtmir upload, but I didn't track that down in details
[15:28] <asac> rsalveti: when was that? who did that upload?
[15:28] <rsalveti> asac: it's not necessarily something that started and used by qtmir itself
[15:28] <asac> i guess lets land and file a bug for qtmir to give us a story what is going on
[15:29] <rsalveti> not sure if boost could affect that or whatever
[15:29] <asac> hmm
[15:29] <cjwatson> I don't think it's reasonable to try to pin this down to a specific process
[15:29] <cjwatson> working around it will be worse than just bumping the limit in glibc
[15:29] <cjwatson> in this case
[15:29] <rsalveti> yeah
[15:29] <rsalveti> it might be a quite complicated fix
[15:29] <cjwatson> https://sourceware.org/ml/libc-alpha/2014-10/msg00134.html has more technical details, and it is too complicated for me
[15:29] <Chipaca> davmor2: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-012/+packages
[15:29] <cjwatson> thank you ubot5 go away
[15:29] <asac> ok, well. as i said I am +1 on landing this in all cases
[15:30] <asac> just wonder if its worth spinning a foloow up effort to get us a good explain
[15:30] <cjwatson> we *think* it is a per-process limit but it's hard to tell for sure
[15:30] <cjwatson> I'm not sure we have company-internal expertise on this ...
[15:30] <cjwatson> I acknowledged at the time that I was cargo-culting from Fedora :)
[15:31] <rsalveti> :-)
[15:31] <rsalveti> anyway, silo is ready to be tested
[15:31] <rsalveti> sil2100: ^^
[15:31] <rsalveti> silo 25
[15:31] <cjwatson> the upstream glibc discussion goes into suggestions of better fixes involving TLS Descriptors
[15:32] <cjwatson> again I'm afraid it quickly gets into territory I'm not familiar with though
[15:32] <asac> cjwatson: rsalveti: is there a bug that we should approve to follow process?
[15:32] <asac> talking to olli
[15:32] <brendand> abeato, https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1378397 did not get approval for landing this week
[15:32] <cjwatson> asac: originally was bug 1375555
[15:32] <asac> rsalveti: who owns qtmir?
[15:32] <rsalveti> asac: yes, we can have a bugtask for RTM
[15:32] <abeato> brendand, it was on the list
[15:32] <asac> ok thats fine
[15:33] <rsalveti> asac: kgunn
[15:33] <abeato> the one in the email
[15:33] <asac> kgunn: around?
[15:33] <abeato> brendand, 10/23 planning
[15:33] <rsalveti> olli: asac: there's a bug task for RTM in there (bug 1375555)
[15:34] <abeato> brendand, it is actually https://bugs.launchpad.net/ubuntu/+source/mediaplayer-app/+bug/1355095
[15:34] <asac> rsalveti: brendand: please start testing silo; we want to brief victor on this before hitting publish
[15:34] <asac> but think there wont be an issue
[15:34] <rsalveti> yup
[15:34] <asac> rsalveti: and yes, please add an RTM task
[15:35] <brendand> abeato, well you can help speed things up by mentioning the right bug *somewhere* in the silo (description, changelog, anywhere)
[15:35] <brendand> abeato, thanks for clarifying though
[15:35] <abeato> brendand, sorry, it is a bit messy because there are replicated bugs in barajas
[15:36] <kgunn> asac: rsalveti qtmir, yep...what's needed?
[15:37] <rsalveti> kgunn: read bug 1375555
[15:37] <rsalveti> kgunn: one qtmir update started to use more tls static slots
[15:37] <rsalveti> might be caused by an update on some other components, optimizations, or cpp/boost related
[15:38] <rsalveti> static slots for graphic is used everywhere for optimizations
[15:38] <asac> kgunn: check the last comment in bug https://launchpad.net/bugs/1375555
[15:38] <asac> kgunn: scared that we see symptoms of something that we can't explain vs. can explain
[15:38] <asac> cant explain might mean we have a bug like a threads leaking etc.
[15:39] <rsalveti> this is not threads leaking
[15:39] <asac> ok :)
[15:39] <asac> 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] <asac> kgunn: guess rsalveti is better to tell you what this is about
[15:40] <cjwatson> it's not threads leaking, I think it's more like more things using dlopen
[15:40] <cjwatson> 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] <rsalveti> cjwatson: iirc the static slots are allocated when loading the library
[15:41] <cjwatson> or rather, loading an extra library with dlopen
[15:41] <kgunn> josharenson: ^
[15:41] <cjwatson> I'm guessing a bit, just saying I really don't think it's anything of the nature of a leak
[15:41] <asac> kgunn: josharenson: bug was reported end of september ... not sure what happened then
[15:41] <rsalveti> yeah
[15:41] <cjwatson> it's more analogous to the structure of the object code
[15:41] <cjwatson> asac: at the time I checked RTM and the problem wasn't present there
[15:42] <cjwatson> presumably something that propagated in since then
[15:42] <rsalveti> probably with qtmir as well
[15:42] <cjwatson> the Fedora bug is more useful reading here
[15:43] <cjwatson> 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] <ChickenCutlass> there are many things that could  cause the use of more TLS slots.  Even something using more boost code.
[15:43] <cjwatson> https://bugzilla.redhat.com/show_bug.cgi?id=1124987
[15:43] <asac> yeah; i think IF this is really a qtmir caused symptom then qtmir folks are best to know what happened since then
[15:43] <asac> and can make sense out of it
[15:44] <asac> kgunn: josharenson: ^
[15:45] <kgunn> asac: right, to me it's simply a double check of is this what we expected
[15:45] <kgunn> give us some time
[15:46] <asac> kgunn: yeah for me this is just a post-process thingy... won't block the landing because of that investigation
[15:46] <asac> kgunn: as long as it happens its fine
[15:46] <asac> think we are aligned
[15:56] <Mirv> mdeslaur: ^
[15:57] <jdstrand> I wonder why mdeslaur is listed as the lander for bash
[15:57] <jdstrand> isn't*
[15:57] <mdeslaur> thanks
[15:58] <robru> jdstrand: because cell b93 is left blank
[16:00] <brendand> abeato, my krillin is totally stuck
[16:00] <abeato> brendand, :/
[16:00] <brendand> abeato, and unity 8 just rebooted
[16:01] <olli> asac, cjwatson, so victor is a bit concerned about that change
[16:01] <abeato> brendand, ah... it actually took a lot of time for me to get unity 8 after flashing this morning
[16:01] <abeato> no idea way
[16:01] <olli> asking whether we have something similar to a device tarball for the emulator
[16:01] <jdstrand> robru: weird, I see it as filled in hear
[16:01] <olli> rsalveti, ^
[16:01] <jdstrand> here
[16:01] <jdstrand> weird typo
[16:01]  * jdstrand updates the cell
[16:02] <rsalveti> olli: yes we have, but that can contain any change related with glibc
[16:02] <robru> jdstrand: must be some sync glitch in the spreadsheet then
[16:02] <jdstrand> robru: well, or network. the spreadsheet was stuck on 'Working' for quite a while
[16:03] <robru> Yeah
[16:03] <rsalveti> because this is a core part of the rootfs
[16:03] <jdstrand> robru: I removed a letter then added it back and pressed 'Enter'. hopefully it is there now
[16:03] <olli> rsalveti, "can't contain" then
[16:03] <olli> makes sense
[16:03] <rsalveti> olli: ask him to read the bug and patch
[16:07] <ToyKeeper> 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] <kenvandine_> ToyKeeper, that's what is expected now
[16:08] <robru> 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] <kenvandine_> ToyKeeper, it's only part of the bug fix
[16:08] <kenvandine_> without it, it doesn't reset the launcher at all now
[16:08] <ToyKeeper> kenvandine_: Is there any change in behavior at all yet?
[16:08] <jdstrand> weird
[16:08] <jdstrand> robru: thanks
[16:08] <kenvandine_> ToyKeeper, there is a unity8 landing that fixes the other
[16:08] <robru> jdstrand: you're welcome!
[16:08] <kenvandine_> ToyKeeper, nope... just fixes resetting the launcher
[16:09] <ToyKeeper> 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] <kenvandine_> ToyKeeper, once the unity8 fix lands, we can land another branch that removes the reboot text
[16:09] <kenvandine_> ToyKeeper, great... it's broken without it :)
[16:10] <ToyKeeper> kenvandine_: Okay, that wasn't clear, I thought this included the complete fix for bug 1376707.
[16:10] <kenvandine_> ToyKeeper, sorry about that, it still matched the test plan
[16:10] <kenvandine_> i'll update the test plan when we are landing the reboot text change
[16:10] <brendand> abeato, second try to launch the video - mediaplayer hanging again
[16:11] <brendand> abeato, pegging the cpu
[16:12] <abeato> brendand, which video are you trying?
[16:13] <brendand> abeato, the one in the bug
[16:13] <brendand> abeato, now it plays but that was twice it failed badly
[16:14] <robru> kenvandine_: ^ I assume you're publishing 14 but i can if you're busy/not around
[16:14] <kenvandine_> robru, i got it
[16:14] <robru> cool
[16:14] <bfiller> robru: could you please rconfigure silo 11 for rtm (line 19) as we added a new package
[16:15] <robru> sure
[16:15] <abeato> brendand, when doing fast forward?
[16:15] <brendand> abeato, no just when loading the video
[16:15] <brendand> abeato, the first time unity8 rebooted
[16:15] <brendand> abeato, the second time the video never started to play
[16:16] <robru> bfiller: done
[16:16] <brendand> abeato, i'll see how reproducible it is
[16:16] <kgunn> trainguards: can i get a silo for row 95
[16:17] <abeato> brendand, ok, I'm trying too
[16:17] <Mirv> kgunn: sure
[16:17] <brendand> abeato, and now the video stopped playing
[16:17] <brendand> and media hub is pegging the cpu
[16:18] <Mirv> kgunn: although, no MP:s in tehre or anything
[16:18] <bfiller> robru: thanks
[16:18] <robru> bfiller: you're welcome
[16:18] <robru> Mirv: heh I just noticed that too ;-)
[16:19] <Mirv> robru: morning! :)
[16:19] <Mirv> it's lunch time here
[16:19] <robru> Mirv: hello!
[16:21] <brendand> abeato, i don't think this is okay
[16:21] <mdeslaur> I just got this trying to upload to a silo: Rejected: Signer has no upload rights to this PPA.
[16:21] <brendand> abeato, i haven't succesfully played the video for more than 5 minutes yet
[16:21] <jdstrand> fyi, I've been the primary lander for the security team, but am training mdeslaur now
[16:22] <cjwatson> mdeslaur: asac or slangasek will need to add you to ~ci-train-ppa-service
[16:22] <jdstrand> mdeslaur should be on the team so he can (also) provide security updates via the citrain mechanism
[16:23] <slangasek> cjwatson, jdstrand, mdeslaur, asac: done
[16:23] <mdeslaur> slangasek: thanks
[16:25] <sil2100> olli, rsalveti: so what's the final decision on the glibc change?
[16:25] <sil2100> Is it good to land in the end?
[16:26] <rsalveti> waiting managers to give a +1
[16:26] <ogra_> they really need to stop slacking
[16:26] <sil2100> So I proceed to grab some lunch then
[16:27] <ogra_> ... managers...
[16:27] <olli> sil2100, still discussing
[16:27] <ogra_> :)
[16:27] <olli> ogra_, ;)
[16:27] <olli> I think the big q atm is... what happens if we don't fix it... and what do we gain from fixing in OTA-1
[16:28] <ogra_> olli, if we dont fix it we dont have an emulator
[16:28] <ogra_> the current emulator images do not boot
[16:29] <olli> ogra_, is there any risk deploying the patch via OTA vs in the image
[16:29] <kgunn> trainguards: ok, how about a some mp's to go in that silo i was asking for .... row 95
[16:29] <ogra_> olli, OTA *is* "in the image"
[16:29] <ogra_> you cant see them distinct
[16:29] <olli> ogra_, I was trying to distinguish between shipping a glibc via air/update vs an image that goes to the factory
[16:29] <olli> not sure there is a difference
[16:30] <ogra_> olli, if you mean deplying it *later* ... well, that would mean having the emulator broken longer
[16:30] <olli> ogra_, OTA-1 is kind of a 0-day SRU
[16:30] <olli> i.e. the intention is to have OTA-1 live when the first customer opens the phone
[16:30] <ogra_> right, but OTA is also and image we build ... it is just a later one
[16:30] <olli> sure
[16:30] <olli> just making sure
[16:31] <olli> ogra_, so, it's "just" the emulator
[16:31] <ogra_> depends how long we want to block app developers that do not have devices
[16:31] <olli> the phone itself is not affected as far as we know today
[16:31] <ogra_> (like the maintainer of our only ebook reader in the store)
[16:32] <ogra_> olli, the change is tiny enough to immediately roll it back (it is just bumping a value of a variable to a higher threshold) ... and it would also not be a problem to build a separate image with only the change in it to asess the imapct
[17:15] <jgdx> haaalp
[17:15] <jgdx> are mako jenkins runs unstable? http://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-ci/1684/ e.g.
[17:24] <plars> ogra_: for image 104 on mako, it appears all 3 runs are stuck - ubuntuuitoolkit, reminders, and dropping letters (all things we've seen it get stuck on before though)
[17:25] <ogra_> plars, well, dropping letters isnt even there
[17:25] <ogra_> so we should just throw the test out
[17:25] <plars> ogra_: apparently it is on mako?
[17:25] <ogra_> thats weird
[17:26] <plars> oh no
[17:26] <plars> maybe not
[17:26] <plars> that could be another one it's stuck on
[17:26] <ogra_> yeah, trow oout the test
[17:26] <ogra_> *throw
[17:27] <ogra_> not sure what to do about uitk, i think ricmm's fix will help with that though
[17:27] <plars> strange, it is dropping letters but somehow it tries to run the test anyway? That makes no sense
[17:51] <popey> plars: just updated that flo from #96 to #98 and now it boots to black screen... expected?
[17:51] <popey> plars: binder_2 at 100%cpu
[17:54] <plars> popey: I didn't do anything with the image on it
[17:54] <robru> rsalveti: hey, what happened with media-hub in silo 8? ursinha fixed that bug, do you want to publish that silo? or did you manually copy it or something? lemme know so I can free that silo up
[17:54] <plars> popey: all I did was power it on and off a few times to test how long the buttons needed to be held
[17:55] <rsalveti> robru: manually landed it (I think I added a comment in there)
[17:55] <plars> popey: we have an instrumented flo in the lab now, and I just needed timings for forcing it to power off and enter fastboot
[17:55] <robru> rsalveti: so there's no branch to merge? i can just free that?
[17:55] <rsalveti> robru: merged by hand
[17:55] <cjwatson> FYI there'll probably be one more utopic publisher run after the current one and then we're done
[17:55] <ogra_> \o/
[17:56] <plars> popey: in ci, 98 seemed to get through quite a lot of the tests though, I'd suspect your battery which seemed to be consistently dead
[17:56] <cjwatson> so not trying to publish anything would be good to prevent us getting hideously confused
[17:56] <cjwatson> I'll stop proposed-migration
[17:56] <robru> rsalveti: cool thanks (and sorry)
[17:56] <cjwatson> Well, after one more run
[17:56] <cjwatson> (to make sure it's zero)
[17:57] <ogra_> olli, bug 1384841
[17:58] <ogra_> olli, already added it to the whishlist (line 56)
[17:58] <olli> ogra_, thx
[18:01] <Mirv> tvoss: rtm-013
[18:01] <Mirv> for line 99
[18:02] <tvoss> Mirv, thanks
[18:03] <nik90> Mirv, sil2100: Can we please get the follow bugs marked as critical for RTM please? -> https://code.launchpad.net/~charlesk/indicator-datetime/lp-1317861-handle-trigger-valarms-in-ical
[18:03] <nik90> Mirv, sil2100: In particular this bug https://bugs.launchpad.net/indicator-datetime/+bug/1362341 is very important for the clock app
[18:04] <ToyKeeper> olli: Still waiting on a decision about the glibc update.  Sounds like it's fairly low risk but also may require a full image test.
[18:05] <popey> plars: nah, it's booted, i can adb shell in
[18:05] <olli> ToyKeeper, I was told by victor that he was convinced by ogra_ & others to do it
[18:05] <olli> ogra_, is that your understanding
[18:05] <sil2100> \o/
[18:06]  * popey re-flashes
[18:08] <Mirv> nik90: hey! the 1317861 seems already handled - the same branch fixes eg. https://bugs.launchpad.net/indicator-datetime/+bug/1362341 which is already targeted
[18:08] <Mirv> nik90: oh, hey, that was that latter bug of yours :D so, yes, they are already targeted AFAIK
[18:08] <Mirv> or hmm
[18:09] <nik90> Mirv: are you sure it is approved since charles just informed that it needs to be marked critical before it can land in the rtm images
[18:09] <nik90> Mirv: either way that branch is super critical to the alarm feature and as such definitely needs to land.
[18:10] <Mirv> nik90: just a moment
[18:10] <Mirv> nik90: so yes, let me add to the wishlist spreadsheet we have.
[18:10] <nik90> Mirv: awesome thnx
[18:11] <Mirv> it has the tags, but it needs product team to comment on one of the bugs the branch fixes
[18:11] <Mirv> since the tags were added by charles
[18:11] <nik90> exactly
[18:11] <nik90> we need the approval for those bugs
[18:12] <charles> Mirv, ty for putting it on the wishlist
[18:12] <sil2100> That's why I preferred the LP project approach
[18:12] <sil2100> Then it would be instantly clear if an issue is accepted or not
[18:16] <Mirv> charles: nik90: I referred to 1361702 primarily and mentioned 1320880 + 1362341 being fixed by the same branch.
[18:16] <Mirv> so I'd expect some sort of comment eventually at 1361702
[18:16] <alecu> trainguards: hi! may I ask for silo for row 73?
[18:17] <robru> alecu: looking
[18:17] <nik90> Mirv: ack. I will keep an eye on it
[18:17] <bfiller> fginther, Ursinha : here is an MR that shows an example: https://code.launchpad.net/~osomon/webbrowser-app/hsbc-br-ua-override/+merge/238270
[18:17] <robru> alecu: so it's a bit late to release anything for utopic ;-) I guess you need to wait for vivid
[18:18] <bfiller> fginther: each run of jenkins shows different results without code changing
[18:18] <robru> alecu: happy to assign an rtm silo however if you need anything there
[18:19] <alecu> robru: good point :P It's a sync from rtm, so, should I keep landing stuff directly to rtm and then ask for a sync once vivid opens?
[18:19] <popey> plars: re-flashed flo and its okay now
[18:19] <robru> alecu: yeah that sounds like a plan.
[18:19] <ogra_> olli, yes
[18:20] <alecu> awesome, thanks.
[18:20] <ogra_> (sorry, was afk)
[18:20] <plars> popey: strange
[18:21] <ogra_> ToyKeeper, preferably we should build one image now, stop landings temporary, sync glibc and build an image just for this, then you can test just with this change ... if it shows any issues we can revert and the nighly build will have the reversion
[18:21] <ogra_> olli, ^^^
[18:21] <ogra_> sil2100, ^^^
[18:30] <robru> mdeslaur: oh sorry i didn't realize you had publish rights in the train. looks like we both his publish at the same time
[18:31] <mdeslaur> robru: ah! I see...whoops, I just hit it again also :P
[18:31] <robru> mdeslaur: disregard the error message, it's publishing
[18:31] <mdeslaur> cool, thanks robru
[18:31] <robru> mdeslaur: you're welcome!
[18:31] <robru> mdeslaur: but I'll let you publish the other three when you're ready ;-)
[18:40] <rvr_> ogra_, sil2100: I tested a glibc silo recently, directly with the ppa. It was a small smoke test + glibc test suite. How do you want to test this silo?
[18:40] <ogra_> rvr_, well, we want to be sure to catch any regressions in apps or image behavior with it
[18:44] <rvr_> ogra_: https://wiki.ubuntu.com/Process/Merges/TestPlan/glib2.0
[18:45] <ogra_> rvr_, we are talking about glibc
[18:45] <ogra_> ;)
[18:45] <ogra_> a *slight* bit different :)
[18:45] <rvr_> Oh, right, different beast
[18:45] <ogra_> (since it affects everything)
[18:45] <rvr_> Forget about what I told you above :P
[18:45] <cjwatson> although the points made by the test plan aren't actually dreadful
[18:46] <cjwatson> just expand the list of dependent packages to everything :)
[18:46] <sil2100> rvr_: ;)
[18:46] <sil2100> cjwatson: hah ;)
[18:46] <ogra_> lol
[18:46] <sil2100> Utopic released
[18:46] <sil2100> \o/
[18:46] <ogra_> yeah !
[18:46] <ogra_> :D
[18:46] <rvr_> Wee
[18:46] <davmor2> WooHoo!
[18:46] <cjwatson> soon we might even close the archive
[18:47]  * ogra_ notices the lock and chain behind cjwatson's back 
[18:55] <sil2100> robru: so, I didn't schedule an official meeting today for the sync up, but let's do it at the same hour today as well
[18:55] <sil2100> robru: I'll set up a manual calendar meeting for it
[18:56] <sil2100> We don't need a specific room for that, we can meet up somewhere on the couches here and just fetch you to the call
[18:56] <sil2100> ogra_: ^ what do you think?
[19:00] <brendand> abeato, so that video seems to be a problem
[19:00] <brendand> abeato, the one mentioned in the bug
[19:00] <brendand> abeato, another video i have seems to be ok
[19:00] <brendand> abeato, not sure is it a regression though
[19:00] <Mirv> utopic \o/
[19:02] <abeato> brendand, well, it is not a regression because previously divx directly did not work at all
[19:02] <abeato> in krillin
[19:02] <abeato> and this change makes fast forward work for mako
[19:02] <abeato> it is unfortunate that that video fails after playing for a couple of minutes :/
[19:03] <abeato> I tested with the videos pointed out in https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1378397
[19:03] <abeato> brendand, ...but no with that Amos one
[19:03] <abeato> brendand, so not really sure what to do
[19:04] <abeato> I'll investigate what is happening, but this change is better than nothing
[19:04] <brendand> abeato, so that video would not have worked on krillin at all?
[19:04] <abeato> right
[19:05] <abeato> well, actually I did test the Amos one, but did not left it playing for long
[19:06] <brendand> abeato, well if it didn't play at all and there are no problems with other videos then it should be ok
[19:07] <abeato> brendand, ack
[19:07] <abeato> it is just a matter of opening another bug to track this
[19:11] <Ursinha> sil2100: I think we need to talk anytime this week about further citrain changes :) as the spreadsheet is going away, the changes you would make would have to happen also on the engine side
[19:11] <lool> sil2100: hey
[19:12] <lool> sil2100: the build job to copy from ubuntu landing ppa 6 to ubuntu-rtm landing ppp 4 didn't work  :-(
[19:12] <lool> sil2100: I did pass location-service as package name, but it seemed to think it was already up-to-date
[19:12] <lool> sil2100: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-004-1-build/53/console
[19:12] <sil2100> lool: hm, let me take a look what's up
[19:12] <sil2100> Ursinha: which changes :) ?
[19:13] <Ursinha> sil2100: any :)
[19:16] <sil2100> lool: ah, the silo needs to be reconfigured
[19:16] <sil2100> lool: it's still trying to fetch from the archive now
[19:16] <sil2100> lool: let me reconfigure
[19:18] <kenvandine> ogra_, the removal of autopilot from the images also removed gir1.2-ubuntu-app-launch-2, which is needed by the sdk to launch on the device
[19:18] <sil2100> lool: reconfigured, try to re-run now
[19:19] <ogra_> kenvandine, can you file a bug so i can re-add it then ?
[19:19] <kenvandine> bug 1384877
[19:19] <kenvandine> bzoltan,  ^^
[19:19] <lool> sil2100: thanks
[19:19] <kenvandine> bzoltan, ogra_ will hook you up :)
[19:20] <bzoltan> kenvandine:  it feels i bit itchy to see it assigned to the UITK ;)
[19:20] <ogra_> heh
[19:20] <kenvandine> bzoltan, well that's where we feel the pain :)
[19:20] <ogra_> let me assign it properly and put it on "olli's list"
[19:20] <bzoltan> kenvandine:  it is more at the qtcreator-plugin ubuntu not the uitk
[19:20] <kenvandine> bzoltan, feel free to reassign
[19:20] <bzoltan> ogra_:  thanks
[19:21] <kenvandine> thanks guys
[19:21] <sil2100> Ursinha: ok, for now I'm busy with formalities and commitlogish stuff, but will inform you of any changes we plan on doing ;)
[19:22] <lool> sil2100: seems to have worked; thanks
[19:22] <sil2100> Cheers o/
[19:23] <kenvandine> ogra_, can we fix that for utopic too?
[19:23] <ogra_> kenvandine, nope
[19:23] <kenvandine> bummer... :/
[19:23] <ogra_> well, we could try to get an SRU in
[19:24] <ogra_> but that will take at least two weeks i recon
[19:24] <kenvandine> i'll add a utopic task
[19:24] <ogra_> i wonder why this was never explicitly seeded
[19:25] <ogra_> sil2100, i'm in meetings from 16:00 to 18:00
[19:25] <sil2100> Crap
[19:26] <sil2100> ogra_: so I'll have a chat with you beforehand, and then just connect with robru at 16:30
[19:26] <ogra_> sil2100, also we really need too make a decision how to get that glibc change in (preferably today so we can still roll back)
[19:26] <sil2100> ogra_: it's in a silo, right?
[19:26] <ogra_> not sure
[19:26]  * ogra_ checks
[19:26] <sil2100> ogra_: QA is looking into testing it from what I see
[19:26] <sil2100> As per #systems on the other IRC
[19:27] <ogra_> sil2100, ah, so they test from the silo then, fine
[19:27] <ogra_> yeah, i see it in 025
[19:33] <robru> sil2100: yes the meeting is in 1hr correct? it works for me
[19:36] <Chipaca> Mirv: hiya. Could you reconfigure rtm-012 please? bundling another branch in there
[19:40] <brendand> abeato, the divx video does play but it still has the same issue as before the silo
[19:41] <abeato> brendand, before the silo?
[19:41] <abeato> brendand, before the silo it played just a few frames
[19:42] <abeato> and those frames were played because of a change in the system image that I already introduced some weeks ago
[19:42] <abeato> otherwise it would simply not start playing
[19:42] <brendand> abeato, it seemed to play well for me
[19:43] <abeato> brendand, could you try the "Micayala Gatto" video from http://www.divx.com/en/devices/profiles/video ?
[19:44] <Chipaca> robru: hiya. Could you reconfigure rtm-012 please? bundling another branch in there
[19:44] <robru> Chipaca: sure but fyi if there's no new package you can reconfigure yourself with the link in the spreadsheet.
[19:45] <Chipaca> robru: clicked it, and it gave me an error message so i assumed i couldn't :)
[19:45] <Chipaca> there is no new package though
[19:45]  * Chipaca pokes at it
[19:45] <robru> Chipaca: what error message?
[19:45] <robru> http400?
[19:45] <Chipaca> robru: You must use POST method to trigger builds.
[19:45] <robru> Chipaca: yeah that's not an error, just click post
[19:45]  * Chipaca clicks
[19:46] <Chipaca> robru: thanks :)
[19:46] <robru> Chipaca: i never did figure out how to make that damn google spreadsheet submit POST requests. hopefully we'll be able to fix that in the new thing that replaces the spreadsheet soon
[19:46] <robru> Chipaca: you're welcome!
[19:53] <ToyKeeper> AlbertA: It looks like silo rtm-017 (media-hub) is on the bug whitelist now, and cleared for testing.  Do you think you might be able to create a test case for it, either in autopilot or the media-hub test plan?
[19:59] <ogra_> kenvandine, olli alloed me to fast-path the re-addition of gir1.2-ubuntu-app-launch-2 ... so the SDK team can do work tomorrow ;)
[19:59] <ogra_> *allowed
[19:59] <kenvandine> ogra_, woot... thanks!
[19:59] <Chipaca> robru: could you give me a hand with understanding that build failure?
[20:01] <robru> Chipaca: looks infrastructural, I'll retry
[20:04] <Chipaca> robru: http://i.imgur.com/eTic1wS.jpg
[20:05] <robru> lol
[20:05] <robru> cjwatson: https://launchpadlibrarian.net/188028125/buildlog_ubuntu-rtm-14.09-amd64.ubuntu-push_0.64.1%2B14.10.20141023.1~rtm-0ubuntu1_CHROOTWAIT.txt.gz any idea what's going on here?
[20:05] <robru> Chipaca: retry failed with the same error. no idea
[20:07] <cjwatson> robru: infinity's fixing the chroots nowish, thanks for the report
[20:07] <robru> cjwatson: ah ok thx
[20:07] <robru> Chipaca: ^^ just wait a bit
[20:07] <cjwatson> we moved the bootstrap archive aside 'cos we don't need it for utopic any more but rather for vivid, but forgot about the reference from the 14.09 chroots
[20:09] <Chipaca> robru: waiting a bit is within my competences
[20:09] <robru> ugh, line 100
[20:09] <robru> I remember when line 30 was a lot
[20:10] <cyphermox> yeah, me too
[20:10] <Ursinha> robru: why that many?
[20:11] <cyphermox> cleanup badly needed of landed stuff, I think
[20:11] <robru> Ursinha: partly because rtm caused a combinatorial explosion in landing requests.
[20:11] <cyphermox> not that it would reduce it that much though
[20:11] <robru> the thing is there are only 60 silos. so if there's 100 requests...
[20:11] <cyphermox> yes
[20:12] <robru> hold on to your butts, I'm gonna clear the landed requests.
[20:12] <cyphermox> stuff that got dropped and/or is fully landed is still in the spreadsheet
[20:12] <cyphermox> robru: perhaps we want to wait a bit to do that though...
[20:12] <cyphermox> since things are working properly atm wrt the spreadsheet.
[20:12] <robru> cyphermox: heh, well I'm here to clean up the fallout
[20:12] <cyphermox> alright then, you decide ;)
[20:14] <robru> wow, 66, that's almost reasonable. I mean it's still crazy, but that number minus the number of total silos is a small number ;-)
[20:16] <AlbertA> ToyKeeper: ok I have to rebuild though....it looks like some other media-hub landings occurred and the current silo is invalid
[20:16] <ogra_> cjwatson, i just did a meta upload to rtm that failed with the above issue too, do i need to manually trigger the re-build if the chroots are fixed or will it just re-try automatically ?
[20:16] <ToyKeeper> AlbertA: Yes, I just noticed the same thing...  it currently won't boot with the silo installed.
[20:17] <ToyKeeper> AlbertA: I think the bug only got "blessed" this morning, so it was stalled until very recently.
[20:17] <AlbertA> ToyKeeper: right
[20:18] <cyphermox> yay!
[20:18] <cjwatson> ogra_: I'll do a mass retry
[20:18] <ogra_> thx
[20:18] <sil2100> robru: you ARCHIVED THE LANDINGS?! How DARE you ;)
[20:18] <robru> sil2100: yes, i BANISHED them to the ABYSS!
[20:18] <ogra_> cjwatson, also, you did mark the seed mature ... do we need an ubuntu-rtm seed for the next weeks ?
[20:19] <ogra_> or do we just go on using this one but in mature state
[20:19] <ogra_> (i doubt there will be many seed changes)
[20:19] <cjwatson> ogra_: I marked utopic mature, not 14.09
[20:19] <cjwatson> or rather my script did
[20:19] <ogra_> hmm
[20:19] <cjwatson> but you can use it in mature state, sure
[20:19] <cjwatson> that's probably easier
[20:19] <ogra_> we have a 14.09 seed ?
[20:19] <cjwatson> no
[20:19]  * ogra_ wasnt even aware
[20:20] <ogra_> ah
[20:20] <cjwatson> probably simplest to just continue to use utopic for the moment
[20:20] <ogra_> yeah
[20:21] <cjwatson> Chipaca: why the rebuild of 012?
[20:21] <cjwatson> changelog looks identical
[20:22] <ogra_> because there was a button to press :)
[20:22] <Chipaca> cjwatson: ogra_: because the previous build failed
[20:22] <cjwatson> Chipaca: ok, please stop that
[20:22] <ogra_> see backlog
[20:22] <cjwatson> rebuild in citrain == new source upload
[20:22] <cjwatson> which is pointless, we can just retry once the LP issue is fixed
[20:22] <cjwatson> new source upload wastes resources
[20:23] <Chipaca> i was told to wait a bit, i waited a bit :(
[20:23] <cjwatson> wait forever please
[20:23] <sil2100> ;)
[20:23] <cjwatson> I'll mass-retry, then we can do watch-only builds
[20:23] <cjwatson> it's easier if people aren't hitting buttons in the meantime
[20:24] <Chipaca> ok
[20:24] <sil2100> robru: hmm, so what's the story with the cu2d jenkins bot? It didn't do CI on it yet, does the merger work?
[20:24] <sil2100> (it == my new branch)
[20:24] <davmor2> Chipaca: I got the ppa now but there are no packages why you break the packages ;)
[20:24] <robru> sil2100: i had a branch yesterday that took 1.5 hours to run. seems it's just slow
[20:25] <sil2100> Holy shit
[20:25] <robru> sil2100: I mean 1.5 hours before it even started
[20:25] <slangasek> mm?
[20:25] <ogra_> slangasek, do you highlight on "holy shit" ?
[20:25] <slangasek> no, I just have good timing
[20:25] <ogra_> hah
[20:25] <slangasek> so this bot is running where?
[20:26] <robru> slangasek: CI runs on lp:cupstream2distro branches have been slow this week. normally they run in 15 minutes, lately it can be 1.5 hours
[20:26] <robru> slangasek: s-jenkins
[20:26] <Chipaca> davmor2: do you have the link?
[20:26] <davmor2> Chipaca: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-012/+packages
[20:26] <robru> psivaa_: when you looked at the ci job for lp:cupstream2distro the other day, did you trigger a build manually? or did it just run after a while by itself?
[20:27] <cjwatson> davmor2: see scrollback, being fixed
[20:27] <Chipaca> davmor2: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-012/+build/6483823
[20:27] <cjwatson> davmor2: not Chipaca's fault
[20:27] <Chipaca> cjwatson: *everything* is Chipaca's fault
[20:27] <davmor2> cjwatson: but I enjoy blaming Chipaca ;)
[20:27] <psivaa_> robru: i did it manually
[20:27] <cjwatson> well yes but aside from that
[20:27] <Chipaca> davmor2: find packages at this link
[20:27] <robru> psivaa_: oh hrrmm... i wonder why it isn't running then? looks like sil has a branch now that it isn't running on. and no screwy prerequisite branch issue here
[20:28] <Ursinha> sil2100: how busy you are tomorrow? we can try to schedule some time in the afternoon to talk :)
[20:28]  * sil2100 likes vanilla merges
[20:28] <psivaa_> robru: ok, let me check, could i get sil2100's branch pls?
[20:28] <Chipaca> davmor2: oh, wait, you want armhf ones
[20:28] <robru> psivaa_: https://code.launchpad.net/~sil2100/cupstream2distro/remove_dual_landing/+merge/239452 thanks
[20:28] <Chipaca> davmor2: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-012/+build/6483822
[20:29] <davmor2> Chipaca: ta
[20:29] <sil2100> Ursinha: let me check the calendar
[20:31] <cjwatson> sil2100,robru: I've retried all the affected builds in LP; please run watch-only builds in citrain if it should be necessary
[20:31] <cjwatson> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-014/+build/6484432 seems to be doing OK so far e.g.
[20:31] <robru> cjwatson: thanks
[20:32] <robru> sil2100: meeting now? send me hangout link
[20:32] <sil2100> Ursinha: maybe we could catch up around 2 pm tomorrow? 30 minutes should be enough
[20:32] <sil2100> robru: ok, let me move to a different location
[20:33] <Ursinha> sil2100: 2-2h30 is good then :) I'll add to the calendar
[20:34] <sil2100> robru: https://plus.google.com/hangouts/_/canonical.com/landing-meeting
[20:39] <Ursinha> sil2100, we can call robru tomorrow and have a hangout so we discuss it together
[20:44] <Ursinha> robru: sil2100, ok, you are invited :)
[20:52] <brendand> abeato, that Amos video definitely works without the silo. i'm trying Micalaya (first try downloading it failed)
[20:53] <robru> Ursinha: thanks
[20:53] <abeato> brendand, interesting
[20:53] <abeato> especially taking into account that both video come from the same place
[20:53] <brendand> abeato, and in fact i can't reproduce the bug jibel reported
[20:54] <abeato> brendand, right, but as said that was partially solved when I did some changes on the system image
[20:54] <abeato> this gstreamer changed solved additional issues with divx
[20:55] <brendand> abeato, although there does appear to be some tearing
[20:55] <sil2100> Ursinha: sure :) Thanks!
[20:56] <Chipaca> davmor2: arm (and intel) ppa built btw
[20:57] <Chipaca> davmor2: also: https://twitter.com/liamosaur/status/506975850596536320/
[21:01] <kgunn> trainguards: can i get a silo reconfig on ubuntu-landing-001
[21:03] <bfiller> robru: can you reconfigure line 39 please? (rtm silo 6)
[21:03] <robru> kgunn: on it
[21:03] <robru> bfiller: one sec
[21:07] <ogra_> bzoltan, are you in any meeting atm ? or could you drop by in beverley (we are planning the developer mode for next cycle)
[21:07] <ogra_> bzoltan, or send someone from your team if you cant
[21:07] <bzoltan> ogra_: in a minute
[21:07] <robru> kgunn: bfiller: ok you're both ready to go
[21:07] <bfiller> robru: thanks
[21:07] <robru> bfiller: you're welcome!
[21:13] <AlbertA> trainguards: can I have rtm silo landing-017 reconfigured (sync media-hub from utopic)?
[21:17] <cyphermox> not sure if I'd need QA signoff for rtm silo 14?
[21:17] <cyphermox> ^^
[21:17] <robru> AlbertA: done
[21:17] <AlbertA> robru: great thanks!
[21:17] <robru> no wait, i failed
[21:17] <robru> AlbertA: ok now it's done. you're welcome ;-)
[21:18] <robru> cyphermox: I think everything in rtm requires qa signoff?
[21:18] <cyphermox> robru: I thought so too, but somehow the scripts decided to ignore the fact that the field isn't filled in
[21:19] <cyphermox> robru: it's also just so you know not to necessarily just publish it without checking :/
[21:19] <robru> cyphermox: "not filled in" isn't a valid state, it should be one of N/A, Required, or Granted
[21:19] <cyphermox> ah
[21:19] <cyphermox> then let me fix this
[21:19] <robru> cyphermox: I set it to required.
[21:20] <cyphermox> good
[21:20]  * cyphermox waits for a landing
[21:21] <robru> cyphermox: not worth fixing the spreadsheet to consider a blank field as equivalent to 'Required' because the spreadsheet is going away so deliciously soon!
[21:26] <cyphermox> robru: ok
[21:26] <cyphermox> robru: please don't land silo 14 even if it gets tested, there's still https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1384776 that needs to be appropriately blessed
[21:27] <cyphermox> sil2100: Mirv: ^
[21:27] <robru> cyphermox: k, please say so in the comment field so everybody knows
[21:27] <cyphermox> yup, just about to do it
[21:29] <sil2100> cyphermox: thanks for the heads up
[21:31] <AlbertA> trainguards: question.... in archive tab, line 1929, that fix landed on utopic and merged into media-hub trunk
[21:31] <AlbertA> trainguards: but I don't see it on the archive
[21:35] <robru> AlbertA: weird, I don't see it in the archive either, even though the branch is merged and trunk has the release commit. no matter now, the newer release includes the older release.
[21:39] <tvoss> robru, could you reconfigure silo rtm 13 please?
[21:40] <lool> ubuntu-qa, mind unblocking rtm silo 4 to put it back into needs qa?
[21:40] <lool> we've tested it on krillin now; it's ready for its second landing attempt
[21:41] <ToyKeeper> lool: It looks like the spreadsheet/dashboard aren't updated yet.
[21:42] <ToyKeeper> lool: Set the "Testing pass?" field there, and it'll unblock QA.
[21:42] <ToyKeeper> lool: It looks unlikely to get tested today though, since EOD is in 18 minutes.
[21:42] <lool> hmm thanks
[21:43] <robru> tvoss: ah sil2100  beat me to it
[21:43] <tvoss> robru, yup :)
[21:44] <lool> ToyKeeper: done
[21:50] <AlbertA> robru: the problem is I'm trying to sync from utopic to rtm... how do I do that now? because the packages don't have the right thing...
[21:50] <robru> AlbertA: not sure what you mean. the package versioned 20141020 will contain whatever was in 20141016
[21:51] <AlbertA> robru: I mean the package in utopic does not match what's in media-hub trunk
[21:51] <AlbertA> robru: and rtm is missing the last commit (i.e. the fix I'm trying to land in rtm)
[21:51] <AlbertA> robru: and the sync just uses the package source right?
[21:51] <robru> AlbertA: the sync would just grab from distro at this point, right
[21:52] <AlbertA> robru: so how do I solve this?
[21:52] <AlbertA> robru: a no change branch?
[21:53] <robru> AlbertA: trunk and distro look fine to me. looks like you had a case of two silos happening simultaneously and the train got a bit confused, but it looks fine now
[21:54] <AlbertA> robru: well the rtm silo landing-017 just built/synced does not match trunk
[21:54] <robru> AlbertA: this is the latest diff to go into utopic: https://launchpadlibrarian.net/187757982/media-hub_2.0.0%2B14.10.20141015.1-0ubuntu1_2.0.0%2B14.10.20141020-0ubuntu1.diff.gz and this is the latest commit on your trunk: http://bazaar.launchpad.net/+branch/media-hub/revision/82 looks the same to me. what's missing?
[21:55] <robru> AlbertA: looks totally fine to me.
[21:55] <AlbertA> robru: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-017/+files/media-hub_2.0.0%2B14.10.20141020.orig.tar.gz
[21:55] <AlbertA> robru: this does not match trunk...I don't know why...
[21:55] <robru> AlbertA: 20141020 is the latest in trunk and in utopic. what part of it doesn't match?
[21:58] <robru> AlbertA: the orig.tar doesn't really mean anything to me because I'm not familiar with the project. Can you produce a diff between what you expected to see and what you actually see? as far as I'm able to tell, the latest release to utopic matches the most recent commit in trunk
[21:59] <AlbertA> robru: yeah let me produce the diff I'm seeing
[22:07] <AlbertA> robru: http://pastebin.ubuntu.com/8646204/
[22:08] <AlbertA> robru: shouldn't the package generated in landing-017 match trunk? there should be no diff in src/
[22:11] <robru> AlbertA: it should only match trunk insofar as distro matches trunk, because it's copying from distro, not from trunk.
[22:13] <robru> AlbertA: anyway, if you want to do a trunk release rather than a sync from utopic, prepare an empty MP against trunk and the train can use that to trigger a fresh build from trunk
[22:13] <AlbertA> robru: ok