[00:09] <cyphermox> np
[00:19] <racarr> cyphermox: Ok left some comments. changelog updated...I guess since we are getting another review from trainguards I will go ahead and flip on the spreadsheet
[00:20] <racarr> Thanks :)
[02:05] <imgbot> [03:05] <imgbot> [03:40] <imgbot> [03:40] <imgbot> [04:15] <imgbot> [04:15] <imgbot> [04:35] <elopio> ping cihelp: can somebody please take look at the runner machines? I'm getting:
[04:36] <elopio> ssh: Could not resolve hostname bazaar.launchpad.net: Name or service not known
[04:36] <elopio> like here: http://s-jenkins.ubuntu-ci:8080/job/ubuntu-sanity-tests-vivid-amd64-autolanding/31/console
[04:52] <bzoltan_> is anybody from the QA team here?
[04:57] <racarr> trainguards: Mir and friends ready to land in silo 12
[06:04] <Mirv> racarr: looking (and morning)
[06:14] <Mirv> racarr: needs archive admin approval since adds new binary packages. I'm asking on #ubuntu-release, or you could ask if you know someone from https://launchpad.net/~ubuntu-archive/+members is online
[06:58] <michi> cihelp:
[06:58] <michi> Looks Jenkins CI has a problem.
[06:58] <michi> Can’t resolve bazaar.launchpad.net
[06:59] <michi> See unity-scopes-api build #570
[06:59] <michi> Can anyone help with that?
[07:00] <michi> That’s s-jenkins.ubunutu-ci:8080/job/unity-scopes-api-ci
[07:21] <vila> michi: s/ubunutu/ubuntu/ you got me there ;) But joke aside, you've already retried that job right ?
[07:21] <michi> vila: Yes, I have.
[07:21] <michi> Failed the second time too, the same way.
[07:21] <michi> Check the console log
[07:22] <vila> michi: err, it's still running http://s-jenkins.ubuntu-ci:8080/job/unity-scopes-api-ci/571/
[07:22] <michi> Yes. And the amd and 386 builds have failed already.
[07:22] <michi> Check the console log for amd64, for example.
[07:23] <vila> ha right
[07:30] <vila> michi: digging, pretty weird so far as going to the worker where the job run I can ping bazaar.l.n ...
[07:30] <michi> vila: Thanks for checking. I have no idea why it’s failing, obviously.
[07:35] <bzoltan_> michi:  do you know why the silo9 is acting as the MR would not be approved? It is top approved ages ago.
[07:35] <michi> Looking...
[07:36] <michi> bzoltan_: Sorry, I have no idea.
[07:40] <bzoltan_> Mirv:  do you know why the silo9 is acting as the MR would not be approved?
[07:42] <vila> michi: http://s-jenkins.ubuntu-ci:8080/job/unity-scopes-api-vivid-amd64-ci/99/console (rebuilding just that job) show some progress but still ... fails in the end
[07:42] <michi> Looking...
[07:42] <vila> michi: ping from the worker itself has hiccups
[07:43] <Mirv> bzoltan_: the run is from yesterday
[07:44] <Mirv> bzoltan_: now it's publishing
[07:44] <michi> vila: Looks like the same error again, but later.
[07:44] <vila> michi: yup
[07:44] <vila> michi: it's the network
[07:44] <bzoltan_> Mirv:  thanks
[07:45] <michi> I’m getting that same BzDir.open_2.1 here occasionally when I pull or push a branch.
[07:45] <michi> It’s been happening for weeks.
[07:45] <michi> On and off.
[07:46] <vila> michi: really ? Literally that error means that bzr can't connect to launchpad or that launchpad close the connection
[07:46] <michi> Yes.
[07:46] <michi> I’ve been seeing this since late last year.
[07:46] <michi> Not all the time, but occasionally.
[07:46] <michi> Usually, it recovers.
[07:46] <michi> Launchpad has been running like dog today.
[07:46] <vila> michi: and this is supposed to happen only when lp goes down for upgrades or a long ssh connection is cleared
[07:46] <michi> I’ve been getting something like 10-30 kBs when pulling.
[09:02] <pete-woods> hi trainguards: I figured you might be the sort of folks who could tell me where ddebs for CI train PPAs go?
[09:05] <Mirv> pete-woods: tough question :) you mean, you'd like to have ddebs before publishing, during PPA testing?
[09:06] <Mirv> sil2100: is it that we don't have that feature, I think?
[09:06] <pete-woods> Mirv: yeah. if there is a crash after installing the PPA, I'd really like to have debug symbols, without having to spend a long time rebuilding all the packages on my phone
[09:06] <Mirv> ddeb creation could be enabled for PPA:s via LP infra guys, but I think it would then mess up with copying to archives
[09:07] <Mirv> pete-woods: without hearing from sil my answer would be to install ddebs for everything you can from the normal http://ddebs.ubuntu.com/ and then rebuild the hopefully one package in PPA on the phone..
[09:07] <pete-woods> sure, it just takes like 2 hours to build many packages on the phone
[09:08] <Mirv> ouch
[09:08] <Mirv> ..and qt, libc etc have -dbg packages as well
[09:08] <pete-woods> yeah
[09:08] <Mirv> I wonder if that could be helped by copying the PPA contents to some special ddeb enabled PPA to have them created
[09:08] <sil2100> hm, I don't remember we had ddebs enabled for our train PPAs
[09:09] <pete-woods> I'm certain that it's possible to make this work
[09:09] <Mirv> pete-woods: which PPA, which package?
[09:09] <pete-woods> it's just the amount of effort
[09:09] <pete-woods> it's not actually for me, in this particular instance
[09:09] <pete-woods> but it would be super helpful if this feature was generally enabled
[09:09] <Mirv> yeah, it's also the general feature
[09:10] <Mirv> sil2100: if I remember correctly, having the ddebs in the PPA causes problem when publishing is tried to be done
[09:10] <Mirv> since I tried to do that with Qt a long time ago
[09:10] <Mirv> I'm not sure how that could be resolved, like removing the ddeb:s from the PPA at the time of publishing
[09:10] <sil2100> Mirv: I think I saw this mentioned by William once somewhere as well
[09:14] <pete-woods> if you guys could figure out some way of enabling it, I would be very grateful
[09:26] <Mirv> pete-woods: sil2100: filed bug #1420185 at least for now
[09:26] <Mirv> I think we might need to consult Colin or someone on that though, for an idea to have them without downsides
[09:30] <popey> landing call?
[09:31]  * ogra_ lands in the call 
[09:32] <sil2100> davmor2: landing meeting!
[09:35] <popey> ffs, browser died
[09:48] <vila> michi: got some feedback from bootstack support. They think it was a glitch. I've seen better results and I've re-run http://s-jenkins.ubuntu-ci:8080/job/unity-scopes-api-ci/573/console
[09:48] <sil2100> jibel: what about silo 7?
[09:49] <michi> vila: Thanks for following up on that!
[09:49] <michi> So, I guess it should work again now
[09:49] <michi> ?
[09:49] <vila> Mirv: they'll keep an eye on it but the current theory is a nameserver issue that nobody has been able to observe yet...
[09:49] <jibel> sil2100, rejected by om26er with this comment: "This is not working for me. My SIM perfectly works on 3G on slot1 but whenever I swap my SIMs and put SIM1 into SIM2(and SIM2 into SIM1) slot, 3G does not work, only 2G does."
[09:49] <michi> OK. Thanks for your help! I’ll shout if it’s still not working.
[09:50] <vila> michi: so, yeah, crossing fingers and reporting to support if it happens again in the current route :-)
[09:50] <vila> michi: right
[09:50] <michi> Looks like it’s compiling fine now, so should be good.
[09:51] <sil2100> Wellark_, awe__, abeato: hey, did you see QA comments on silo 7?
[09:52] <sil2100> I'm bumping the silo to not tested again
[09:53] <sil2100> Mirv: archiving landing requests
[09:53] <abeato> jgdx, ^^
[09:53] <Mirv> sil2100: ok
[10:00] <jgdx> abeato, it's working, but maybe the indicator is not?
[10:01] <jgdx> I'm seeing hspa on ril_1 and 2g in my indicator
[10:01] <jgdx> gah
[10:01] <abeato> jgdx, hmm, must be indicator, Wellark_ ^^
[10:15] <sil2100> john-mcaleely: I promoted the image to ubuntu-touch/rc/bq-aquaris.en
[10:15] <sil2100> john-mcaleely: you should see an update coming in soon
[10:15] <john-mcaleely> sil2100, cool
[10:15]  * john-mcaleely waits excitedly
[10:25] <jgdx> sil2100, john-mcaleely, silo 7 failed due to [1] it seems. There's a fix in the works. [1] https://bugs.launchpad.net/barajas/+bug/1378778
[10:26] <jgdx> but might need that bug prioritized at the same level as bug 1379850 and friends
[10:29] <john-mcaleely> jgdx, ack. will review. can you comment on that bug please?
[10:38] <jgdx> john-mcaleely, commented why I removed the duplicate link. Anything else you need in there?
[10:40] <john-mcaleely> jgdx, I've added your comment about silo7, so that should be fine
[10:40] <john-mcaleely> sil2100, phone upgraded to 17. looks good!
[10:46] <mandel> sil2100, what was the trick to sync a package from vivid to trusty in the spreadsheet?
[10:46] <mandel> sil2100, I have something to land for both and there is no delta between them (vivid and trusty for ciborium)
[10:55] <davmor2> sil2100: so you know in that nice email I sent you where I said I wouldn't be in on Friday or Monday and might not make some of the meetings in the morning :P ;)
[11:01] <vila> michi: http://s-jenkins.ubuntu-ci:8080/job/unity-scopes-api-ci/573/ \o/
[11:01] <michi> vila: sweet, thank you! :)
[11:06] <sil2100> mandel: hey!
[11:07] <mandel> sil2100, hello! did you see my message, I just want to create two ppas, one for trusty other for vivid, same mr
[11:07] <sil2100> mandel: ok, try writing this in the 'additional packages to land': sync:ubuntu,vivid ciborium
[11:07] <sil2100> mandel: in the trusty PPA
[11:07] <sil2100> Oh
[11:07] <mandel> sil2100, ok
[11:07] <sil2100> So you want to first land the thing for vivid?
[11:07] <sil2100> Or is it already landed there?
[11:08] <mandel> sil2100, I want to land it in both
[11:08] <mandel> sil2100, so that we support rtm and we have it in vvid
[11:08] <mandel> sil2100, I guess, first vivid and then trusty
[11:08] <sil2100> mandel: ok, so first prepare the normal silo for vivid
[11:09] <sil2100> mandel: then I'll create all the bits for you for trusty, since if you want to sync from a PPA it can be a bit more tricky
[11:09] <sil2100> mandel: (since we have easy syntax only for ubuntu <-> ubuntu-rtm silo syncs :) )
[11:10] <mandel> sil2100, ok, done, thx!!!
[11:10] <sil2100> mandel: you can of course land it for vivid first and then request a sync from the vivid archive to trusty (with the syntax I mentioned above)
[11:10] <sil2100> But I suppose we can do it in parallel
[11:10] <mandel> sil2100, I'd like to have it in a ppa for testing, is related to sd card formatting.. I don't want to screw up
[11:13] <sil2100> mandel: ok, let me prepare everything for you
[11:13] <sil2100> One moment :)
[11:14] <mandel> sil2100, you rule! thx!
[11:18] <sil2100> mandel: ok, vivid silo assigned, but ciborium is in silo 005 as well
[11:19] <mandel> sil2100, agh.. great, I'll try to unblock that
[11:30] <sil2100> mandel: ok, the trusty silo is setup, once your packages have built successfully in the vivid one, just go to silo 007 (trusty) and press the build button
[11:30] <mandel> \o/
[11:45] <cjwatson> michi: Which silo is it you're talking about?
[11:45] <michi> cjwatson: 021
[11:45] <cjwatson> michi: ubuntu or ubuntu-rtm?
[11:45] <michi> Fails on the phone with a segfault.
[11:45] <oSoMoN> trainguards: hey, can I haz a silo for line 60, please?
[11:46] <michi> crash dump shows me a stack trace, but without symbols.
[11:46] <michi> ubuntu, as far as I know.
[11:46] <cjwatson> I wonder why the ddebs in question aren't on ddebs.ubuntu.com anyway.
[11:46] <cjwatson> I'm sure they used to be for silos.
[11:47] <michi> https://ci-train.ubuntu.com/job/ubuntu-landing-021-1-build/66/console
[11:47] <michi> I have no idea.
[11:47] <michi> But, basically, without symbols, I’m screwed, because I can’t make sense of the core dump.
[11:47] <michi> Same MRs work fine in CI.
[11:47] <michi> Might be an ABI issues, or a compiler change, or a real bug.
[11:48] <michi> But I have no way of finding out if I’m staring at a black box.
[11:48] <cjwatson> michi: I can extract them for you manually
[11:48] <michi> That would be really useful, thank you!
[11:48] <michi> But we need a way to get symbols when a silo build fails on the phone.
[11:48] <michi> Otherwise, we just don’t know what’s happening.
[11:49] <cjwatson> michi: I understand, but this is the best I can do for you for now.
[11:49] <michi> Sure! I’m *very* appreciative of your help!
[11:49] <cjwatson> michi: We're very close to having something generically better.
[11:49] <michi> That would be truly useful.
[11:49] <michi> As is, any core dump after applying a PPA on the phone is likely to be useless.
[11:50] <cjwatson> (As in, William implemented it a year or two ago and since then it's been blocked on infrastructure issues)
[11:50] <michi> I hear you :)
[11:53] <cjwatson> michi: http://people.canonical.com/~cjwatson/tmp/unity-scopes-api_0.6.13+15.04.20150209-0ubuntu1_armhf_ddebs.tar - please let me know when you've grabbed it so I can free space
[11:56] <michi> cjwatson: Bloody brilliant, thank you!
[11:56] <michi> I have a copy now, so you can blow yours away.
[11:56] <michi> I haven’t looked at it yet. How do I use it?
[11:59] <sil2100> oSoMoN: suar
[12:01] <oSoMoN> sil2100, thanks!
[12:02] <cjwatson> michi: It's a tarball of some .ddeb files.  You should be able to plug it into https://wiki.ubuntu.com/DebuggingProgramCrash somehow
[12:02] <cjwatson> Worst case manually install them with dpkg -i in whatever context is appropriate, and remove afterwards
[12:02] <michi> OK, cool, I think I can handle that :)
[12:02] <michi> Thanks heaps for  your help!
[12:02] <cjwatson> np
[12:11] <sil2100> lool: hey! Just poking to see if maybe you had some time for the custom tarball modification :)
[12:18] <Mirv> thanks colin for all the help to michi
[12:19] <michi> Mirv, cjwatson: Hell, yes! :)
[12:19] <Mirv> pete-woods: so the end result in that bug discussion was that there has been something brewing for a long time and hopefully available in the next few weeks
[12:19] <michi> Mirv: I sincerely hope so.
[12:19] <michi> We have a similar issue with tests dumping core only on CI, but not locally.
[12:20] <michi> If they dump core on CI, I can see that there was a segfault, but the buck stops right there.
[12:20] <michi> What we really need is (a) the stack trace for all threads as part of the CI test run and (b), the core, so we can look where it blew up in detail.
[12:22] <pete-woods> Mirv: yes, read the bug report. sounds positive to me :)
[13:29] <Mirv> ^ rtm-000 not really, I set qa approval to required now
[14:11] <Mirv> om26er: so the whatever test plan related issue related to rtm-005 (if I remember correctly from jibel) was resolved and the silo is good to go?
[14:13] <om26er> Mirv, yes, I found a bug in the fix, they fixed it and now its good to go
[14:14] <Mirv> om26er: ok, thank you
[14:27] <sil2100> ogra_: just a curiosity question: you have access to lillypilly, or is it only for archive-admins?
[14:27] <ogra_> sil2100, ssh people.canonical.com
[14:27] <ogra_> you shoudl too ;)
[14:27] <sil2100> Uh, argh
[14:27] <sil2100> Somehow I mixed up lillypilly with snakefruit
[14:28] <sil2100> ogra_: thanks for reminding me ;)
[14:28] <ogra_> ah, no idea about snakefruit :)
[14:31] <davmor2> sil2100: slap your forehead and say "D'oh!"
[14:33] <Mirv> cihelp you might want to make a note that Qt autolander jobs are somehow broken see for example https://code.launchpad.net/~ricmm/kubuntu-packaging/qtdeclarative-opensource-src_532-implement-jit-cache/+merge/248381
[14:34] <Mirv> oh well, that's not a good example since I ran the autolander job myself since it was to an unusual branch :) https://code.launchpad.net/~timo-jyrinki/kubuntu-packaging/qtdeclarative_crashers_fixes_trigger_CI/+merge/243974 is better
[14:34] <Mirv> if the release is in archives it shouldn't try to fetch from upstream (and fail for whatever reason)
[14:36] <fginther> Mirv, thanks for the notice. Will have a look into this
[14:37] <om26er> jgdx, hey
[14:37] <jgdx> om26er, yo
[14:38] <om26er> jgdx, I again went out for some field testing. Even though the technology of the SIM slot changes, 3G does not work on the second SIM
[14:38] <jgdx> om26er, what's used as indicator that it works/not work?
[14:38] <om26er> It always stays on 2G plus I have tested the speed to ensure that the icon is not lying
[14:39] <om26er> jgdx, Have you tested it on your device ?
[14:40] <om26er> jgdx, perhaps we have a way to iquire which band is working right now ? Something similar to what the indicator-network uses to know the band in use.
[14:43] <jgdx> om26er, yeah, I've tested it, but I've just confirmed that I see hspa in ConnectionManager.Bearer.
[14:44] <jgdx> which I do, on ril_1 (second SIM)
[14:44] <om26er> jgdx, give me the command so I could verify that as well
[14:44] <jgdx> om26er, /usr/share/ofono/scripts/list-modems
[14:44] <jgdx> takes a while
[14:45] <om26er> jgdx, "Model = Fake Modem Model" looks sane ?
[14:45] <jgdx> yeah
[14:50] <jgdx> abeato, is there a 100% sure way of knowing, on the phone, whether or not you're on a '3g' connection?
[14:51] <abeato> jgdx, you can check the ConnectionManager interface in ofono
[14:51] <jgdx> abeato, and look at Bearer?
[14:51] <abeato> jgdx, yes
[14:52] <jgdx> abeato, thanks
[14:52] <abeato> np
[15:02] <racarr> trainguards: Hey. Mir 0.11 has landed but the assosciated mp still hasn't, what could be going on? https://code.launchpad.net/~mir-team/mir/0.11/+merge/248221 and was silo 12
[15:02] <sil2100> racarr: looking, but I might have an idea why
[15:03] <racarr> sil2100: We have an idea as well aha, I made a mistake with the changelog and there is
[15:03] <racarr> a commit updating debian/changelog
[15:03] <racarr> that didn't make it in to the PPA
[15:03] <sil2100> Yeah
[15:03] <Mirv> hmm
[15:03] <sil2100> Exactly
[15:03] <sil2100> We need to add a check for that to the train
[15:03] <racarr> -.-...sorry I didn't know the packages were copied I thought they built again in archive or something
[15:04] <racarr> Hmm, so what should we do? It's just the text content change (as opposed to version number or something) so its probably pretty harmless
[15:04] <sil2100> No, it's basically what you have in the silo you release to the archive, this way we make sure that what you test is what will be on the devices
[15:05] <racarr> mm
[15:06] <sil2100> Since the only missing change is a changelog update, not much we can do here without re-releasing
[15:06] <sil2100> I would say let's mark the merge as merged manually and just leave it as it is
[15:06] <racarr> sil2100: Mm. Sounds good to me.
[15:07] <Mirv> sil2100: hey, I'd need some help https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-005-3-merge-clean/33/console
[15:07] <racarr> sil2100: Thanks :)
[15:08] <Mirv> sil2100: bzoltan pointed the gles branch to a wrong (vivid) branch of gles, and I'm trying to fake the branch for CI Train so that the clean job would work, after which I'd split it properly to gles-rtm
[15:08] <om26er> jgdx, hey
[15:08] <om26er> jgdx, I am out doing fielding testing, so it seems the icon is lying
[15:08] <jgdx> om26er, hay
[15:08] <jgdx> om26er, have you seen https://bugs.launchpad.net/barajas/+bug/1378778
[15:08] <Mirv> sil2100: but I push --overwrite:d what it'd like to see (rev 39), but it still claims there'd be 41 available
[15:08] <jgdx> om26er, it is that issue, I think.
[15:08] <om26er> jgdx, well in my case it does say 2G *always*
[15:08] <sil2100> Mirv: hmm, let me look
[15:09] <Mirv> sil2100: oh, wait
[15:09] <Mirv> sil2100: it might be that it was just LP being slow.
[15:09] <om26er> jgdx, wouldn't the silo make more sense with that fix in ?
[15:09] <Mirv> sil2100: yeah, some query was cached even though rev contents already showed 39
[15:09] <sil2100> Mirv: is it ok now?
[15:09] <Mirv> sil2100: problem solved, thanks!
[15:09] <Mirv> sil2100: yes.
[15:09] <sil2100> Yaay! ;)
[15:09] <Mirv> manual hacking ftw
[15:10] <Mirv> bzoltan_: so, I've now created a proper gles-rtm branch + series for you, which was previously not existing
[15:13] <jgdx> om26er, it would, but seems that fix was never made. It's supposedly in progress right now.
[15:14] <om26er> jgdx, hmm, ok. I'll start with TestPlan now that the feature is known to be working.
[15:14] <jgdx> om26er, thanks
[15:14] <cjwatson> Mirv: You were probably on a database slave.
[15:15] <Mirv> sil2100: btw, when a job fails to merge something like that, it seems it retries it automatically somehow ad infinitum every 5 minutes, creating something like this... https://code.launchpad.net/~system-settings-touch/gsettings-ubuntu-touch-schemas/trunk
[15:15] <sil2100> Shit, I thought robru fixed that
[15:15] <Mirv> so if something like that would be left alone overnight, the bzr log would be quite noisy :)
[15:16] <sil2100> robru: ^ remember this bug we reported when the auto-merge functionality got introduced?
[15:16] <sil2100> robru: wasn't that fixed?
[15:16] <sil2100> robru: i.e. when a push to some branch is failing, CI Train re-pushes to branches it already pushed into
[15:17] <sil2100> robru: we had that when ci-train-bot didn't have the right perms
[15:36] <bzoltan_> Mirv: Thank you
[15:41] <sil2100> Sadly the train's merge job wasn't meant to be ran in a loop :D
[15:44] <sil2100> robru: I'll have a quick merge for that soon
[16:13] <anpok_> ping cihelp
[16:13] <anpok_> i have a build failure in silo-000 for arm64, whithout a log
[16:14] <anpok_> https://ci-train.ubuntu.com/job/ubuntu-landing-000-1-build/267/console
[16:14] <boiko> sil2100: any idea why there is no build log here: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-013/+build/6962978 ?
[16:15] <sil2100> boiko: wow, that's something new
[16:15] <sil2100> boiko: let me retry, maybe it's some transient LP issue
[16:15] <boiko> sil2100: the two arches that failed are in that state
[16:16] <sil2100> boiko: hm, ok, then let's poke launchpad-ops
[16:17] <anpok_> sil2100: had the sme on silo-000
[16:17] <camako> sil2100, I think anpok's issue is the same as boiko's.
[16:19] <rvr> pstolowski: ping
[16:21] <pstolowski> rvr, pong
[16:21] <rvr> pstolowski: Silo 2
[16:22] <rvr> pstolowski: I created an account in System Settings > Online Accounts, and I expected that the Instagram scope would show the photos instead of "Add your account" message.
[16:22] <sil2100> camako, anpok_: I poked the right people, let's see what they say
[16:23] <sil2100> Maybe there's some work going on LP
[16:24] <anpok_> thx
[16:26] <sil2100> anpok_, camako: cjwatson reports it seems to be some network problem in the datacenter
[16:26] <sil2100> So we can retry by rebuilding later
[16:27] <cjwatson> There isn't active maintenance, but I'm retrying
[16:27] <pstolowski> rvr, could you please add a comment in the spreadsheet and I'll ask marcustomlinson to check
[16:29] <rvr> pstolowski: Ok
[16:30] <boiko> cjwatson: sil2100: thanks
[16:30] <sil2100> ogra_, jibel, davmor2, popey, robru: let's skip todays meeting as always
[16:30] <ogra_> yup, fine with me
[16:31] <pstolowski> rvr, thanks!
[16:31] <davmor2> sil2100: no you skip martial arts for a change ;)
[16:31] <davmor2> sil2100: :D  have a good evening dude :)
[16:36] <rvr> I'll attend as I haven't been noticed ;)
[16:56] <cjwatson> sil2100: chasing on #webops
[17:01] <boiko> cjwatson: sil2100: can I rebuild silo 13? (the one that failed with no logs), renato added some more stuff to address-book-app in there
[17:01] <cjwatson> boiko: There's no point yet
[17:01] <boiko> cjwatson: ok, would you mind letting me know when it is fine to build again?
[17:01] <cjwatson> boiko: I don't know exactly what it is but we have a couple of architectures out of operation.  I've raised it, hopefully it will be fixed soon
[17:02] <cjwatson> boiko: Sadly I have to leave pretty much now so it may be rather later, unless somebody is keeping an eye on #webops
[17:02] <cjwatson> I'll be back in ~6 hours for an LP team meeting ...
[17:03] <boiko> cjwatson: that's fine, don't worry :)
[17:20] <om26er> jgdx, which section here I should be running exactly ? https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-system-settings
[17:30] <dobey> fginther: hey. can you re-run the autopilot job for pay-ui against that same branch again? thanks
[17:31] <fginther> dobey, restarted
[17:38] <jgdx> om26er, tests under Cellular (Single SIM) and Cellular (Dual SIM) perhaps. Not sure what your policy are, but I ran those two.
[17:52] <dobey> ok, so fails there with the same issue. need to figure out a solution for that
[17:57] <dobey> i wonder if just running "apparmor-exec qmlscene blah blah" will work
[17:57] <robru> Mirv: sil2100: I cleaned up the errant commits from http://bazaar.launchpad.net/~system-settings-touch/gsettings-ubuntu-touch-schemas/trunk/changes
[17:58] <robru> Mirv: sil2100: yeah I remember this happening before but I can't remember what I did about it then. possibly I just did something to mitigate it, not a full solution. I think the best solution would be for the 'Resync trunk' code to check if the resync commit is empty before committing it.
[18:03] <wxl> hey folks. i understand this the place to be for touch image testing?
[18:11] <robru> wxl: you could say that
[18:12] <wxl> robru: so, where can i find information on the process?
[18:13] <robru> wxl: depends, what do you want to do?
[18:14] <wxl> robru: well, i figure image testing is needed, no?
[18:14] <robru> wxl: sure but there's lots of different things to do. are you an upstream developer wanting to test changes to the image before they get in the image?
[18:15] <john-mcaleely> sil2100, so, heads up. I will make a device tarball for ww07 tonight (can land as normal)
[18:15] <robru> wxl: or you just want to take whatever image and look for bugs in it?
[18:15] <john-mcaleely> sil2100, it seems likely there may be another late tomorrow, which will need discussion about if it can go in ww07
[18:16] <robru> wxl: generally speaking I guess you're looking for https://wiki.ubuntu.com/QATeam/TouchTesting
[18:18] <wxl> robru: so ultimately, ubuntu-quality should be who i touch base with?
[18:19] <robru> wxl: yeah, they often hang out here.
[18:19] <wxl> robru: thx
[18:19] <robru> wxl: you're welcome
[18:19] <wxl> i'll leave you guys to whatever it is that you're doing :)
[18:24] <om26er> jgdx, a few more bugs: http://paste.ubuntu.com/10161950/
[18:27] <om26er> jgdx, issue#2 in that paste is critical since the user won't know if Data is enabled or not.
[18:32] <om26er> Wellark_, Hey! I think you are a stakeholder in silo 7 as well. There are a few issues found in that silo.
[18:32] <om26er> Wellark_, http://paste.ubuntu.com/10161950/
[19:53] <bfiller> robru: can you publish ubuntu silo 4 please
[19:54] <robru> bfiller: done
[19:54] <bfiller> robru: thanks
[19:54] <robru> bfiller: you're welcome
[19:58] <robru> cjwatson: hey I'm seeing some strange build failures that are missing build logs, any idea what's going on here? https://launchpad.net/~ci-train-staging-area/+archive/ubuntu/landing-003/+build/6964351
[19:59] <robru> cjwatson: also https://launchpad.net/~ci-train-staging-area/+archive/ubuntu/landing-000/+build/6964208
[20:08] <john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150210-4b918db.tar.xz
[20:08] <john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150210-4b918db.changes
[20:08] <john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-testresults-20150210-4b918db.ods
[20:09] <john-mcaleely> sil2100, ^ new device tarball for rtm. will do spreadshee t & email shortly
[20:19] <jgdx> om26er, ping
[20:19] <om26er> jgdx, pong
[20:20] <jgdx> om26er, in [1], did you by any chance not reboot after hot swapping the SIMS? [1] http://paste.ubuntu.com/10161950/
[20:20] <jgdx> om26er, also, 2. is equal to the first issue you found. :)
[20:22] <om26er> jgdx, I am not sure, I think I did. trying again this time with a reboot
[20:22] <om26er> jgdx, also indicator-network just crashed
[20:23] <om26er> :(
[20:23] <om26er> https://errors.ubuntu.com/oops/c4eb9ca8-b15e-11e4-9e19-fa163e525ba7
[20:24] <om26er> jgdx, even after reboot issue #1 persists.
[20:27] <jgdx> om26er, for 1. could you pm the output of /usr/share/ofono/scripts/list-modems ?
[20:27] <jgdx> and steps to reproduce
[20:29] <jgdx> om26er, crash does not look like a regression in this silo though
[20:32] <sil2100> john-mcaleely: ACK, that's for this milestone?
[20:33] <john-mcaleely> sil2100, yup
[20:36] <om26er> jgdx, might sound a lil silly, right now that issue#1  is not happening. Perhaps some kind of race or something ?
[20:37] <om26er> jgdx, FWIW indicator-network never crashed for me before. So that crash makes me a little nervous.
[20:38] <om26er> jgdx, also sorry for being pain in the arse, this landing changes core part of the stack so I am trying to be extra cautious.
[20:38] <om26er> :)
[20:47] <jgdx> om26er, I think you're just being thorough, and that's critical. :) If you need some more eyes on #1 I can help.
[20:47] <kenvandine> om26er, we do appreciate that!
[20:47] <jgdx> but I'm a bit back/forth.
[20:47] <kenvandine> please be thorough :)
[20:48] <sil2100> robru: hey, you around today? :)
[20:48] <sil2100> robru: ah, I see you are
[20:48] <robru> sil2100: yeah, why?
[20:48] <sil2100> cyphermox: ^ :)
[20:49] <robru> sil2100: build.py rewrite is really close to done, just cleaning up some small regressions I found. I'm soooo stoked for this.
[21:07] <robru> sil2100: cyphermox: do you guys need me?
[21:12] <om26er> jgdx, so here a  way: Make sure you only have a SIM in slot2 (Slot1 should be empty). clean flash, install silo. You will only have 2G you cannot change to 3G.
[21:13] <om26er> unless you insert a SIM into slot1 you can never enable 3G on SIM slot 2.
[21:17] <sil2100> robru: we just need someone on train duty :) Great news with that build redesign
[21:17] <sil2100> robru: did you add sync support?
[21:18] <sil2100> Anyway, really need to run now
[21:18] <sil2100> o/
[21:30] <robru> lunch!
[21:37] <john-mcaleely> anyone object to a vicid tarball push in ~30-60 mins?
[21:37] <john-mcaleely> vivid, even
[21:37] <john-mcaleely> ogra_, ? ^
[22:23] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20150210-95b6a9f.tar.xz
[22:23] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20150210-95b6a9f.changes
[22:23] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-testresults-20150210-95b6a9f.ods
[22:24] <john-mcaleely> vivid tarball incoming
[22:26] <john-mcaleely> pushed
[22:37] <cjwatson> robru: it should be fixed now, apparently it related to an ntp upgrade that made launchpad-buildd very sad indeed.  just retry any you see
[22:37] <cjwatson> boiko: ^-
[22:38] <cjwatson> robru: though I plan to write something before I go to sleep to track down at least a respectable set of the failures and mass-retry them
[22:49] <robru> cjwatson: thanks
[22:51] <cjwatson> Hm, this is harder than usual because these builds don't show up in builder history so I can't use my usual workaround for LP not having a sensible global way to search for builds
[22:52] <robru> cjwatson: no worries on my end, I can just retry them as I see them.
[22:52] <ToyKeeper> dbarth ... isn't around.  D'oh.
[22:53] <robru> cjwatson: there were only 3 or 4 that I cared about.
[22:53] <cjwatson> Sure, but there were gazillions globally
[22:54] <robru> cjwatson: true
[22:54] <cjwatson> let me see, maybe I can at least pare the script down to taking a list of archives or something
[23:02] <ToyKeeper> Well, it fixed an issue or two and doesn't appear to have broken anything...
[23:14] <robru> mardy: dbarth: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-000-2-publish/28/console need merges approved in order to publish
[23:16] <cjwatson> hmm.  gross hack, but on the webapp /builders/+build/ID redirects to the canonical URL of that build, so I can do that from a script and then figure out the webservice URL from that
[23:16] <cjwatson> ugh ugh ugh will be hideously slow
[23:16] <cjwatson> my kingdom for getByIds or something
[23:18] <ToyKeeper> Cool, can't publish due to unapproved merges.  Why does this still happen?  Isn't there a landing checklist before submitting a silo for its final steps?
[23:29] <robru> ToyKeeper: people are supposed to approve the merges before they send for QA, but after they've had the silo assigned and had a chance to test that the built packages behave as they expect. The train  unfortunately has no way to enforce that until you click 'publish', which comes after QA.
[23:30] <ToyKeeper> Yeah, I mean...  a manual checklist.  Not sure if that exists or if people normally use it.
[23:31] <robru> ToyKeeper: it is mentioned at https://wiki.ubuntu.com/citrain/LandingProcess but evidently not everybody reads this every time ;-)
[23:35] <robru> ToyKeeper: wow, in this case, all three MPs don't even have any review at all, much less top-approved. if they had regular reviews approving them I might have overlooked the lack of top approvals, but yikes.
[23:39] <ToyKeeper> In theory, it needs to land within a few hours to get in before the window closes...  but that'd be easier if people were around.