[00:03] <michi> robru: So, in my branch, the latest released version corresponds to revision 342
[00:03] <michi> The revisions on trunk and devel are not the same.
[00:03] <robru> michi: right, but this is going by devel because your MP targets devel.
[00:03] <michi> Because we use devel as a staging branch, bundling several changes, and then bulk-merge to trunk.
[00:03] <robru> michi: unless you want to make a different MP that targets trunk?
[00:03] <michi> Right, so I tried to tag my branch with 342
[00:03] <michi> bzr tag 1.0.0+15.10.20150821.3-0ubuntu1 -r 342
[00:03] <michi> bzr: ERROR: Tag 1.0.0+15.10.20150821.3-0ubuntu1 already exists.
[00:04] <robru> michi: can you show me the output of 'bzr tags' please?
[00:04] <michi> Sec
[00:05] <michi> Here are the last few: http://pastebin.ubuntu.com/12188812/
[00:05] <michi> So, I guess I need to use the final one?
[00:05] <michi> No, because that one’s there already.
[00:06] <robru> michi: were those already there? I don't understand why there aren't any on your devel branch
[00:06] <robru> and why the train would grab every commit ever.
[00:06] <michi> Let me check the tags on the devel branch. The ones I pasted are from the single-tree MR.
[00:07] <michi> These are on the devel branch: http://pastebin.ubuntu.com/12188826/
[00:07] <robru> michi: I don't understand how you got up to 621 revisions when the tag for r163 is dated a few days ago
[00:09] <robru> michi: anyway whatever
[00:09] <michi> I don’t get that either.
[00:09] <michi> But I don’t know how to fix the dch problem now.
[00:09] <robru> michi: I'm seeing http://paste.ubuntu.com/12188840/ in the log, maybe your build depends aren't quite right yet?
[00:10] <robru> slangasek: do you have any reccomendations for doing series detection? lsb is giving us some hassle ^
[00:10] <michi> robru: Oh, I get it :-(
[00:10] <michi> I added the build dep to control.in.
[00:10] <michi> But, of course, it uses control initially.
[00:10] <robru> oh haha
[00:10] <robru> yeah
[00:10] <michi> Not lsb_release’s fault
[00:10] <michi> I’ll do another push
[00:13] <michi> robru: done
[00:13] <robru> michi: ok one more go: https://ci-train.staging.ubuntu.com/job/ubuntu-landing-008-1-build/4/console
[00:14] <michi> Something is definitely fishy with those revision numbers.
[00:14] <michi> I’m seeing 625
[00:14] <michi> In the devel tree, the latest revision is 624, as you’d expect.
[00:15] <michi> But bzr tags on the devel tree shows 163 as the last one
[00:19] <robru> michi: it must be that you do that much extra devel on the devel branch and then only merge occaisionally into trunk or something
[00:19] <michi> Yes, that’s something we definitely do a lot.
[00:20] <robru> michi: still seeing "No lsb modules..."
[00:20] <michi> Shit
[00:20] <michi> I definitely added lsb-release to the build deps in control.
[00:21] <michi> Hmmm… From the log: http://pastebin.ubuntu.com/12188826/
[00:21] <michi> Sorry, wrong link
[00:21] <robru> michi: although actually hmmm. it might be working, that error might be a red herring
[00:21] <michi> Yes
[00:21] <michi> make[1]: Entering directory '/var/lib/jenkins/silos/ubuntu/landing-008/unity-scopes-api_+vivid'
[00:21] <michi> gen-debian-files: running lsb_release -a
[00:21] <michi> Distributor ID:	Ubuntu
[00:21] <michi> Description:	Ubuntu 15.04
[00:21] <michi> Release:	15.04
[00:21] <michi> Codename:	vivid
[00:21] <michi> dh_auto_clean
[00:22] <robru> michi: https://launchpad.net/~ci-train-staging-area/+archive/ubuntu/landing-008/+sourcepub/5325235/+listing-archive-extra scroll to the bottom here, are those the correct binary package names?
[00:23] <michi> Is this vivid or wily?
[00:23] <robru> michi: https://launchpad.net/~ci-train-staging-area/+archive/ubuntu/landing-008/+build/7833477 oh you're depwaiting in vivid.
[00:23] <michi> For vivid, this looks right
[00:23] <michi> Sorry, for *wily* this looks right.
[00:23] <robru> michi: right, that one is wily
[00:23] <robru> michi: the vivid one didn't built
[00:23] <michi> :(
[00:24] <michi> How come we need to wait here?
[00:24] <michi> Ah, OK, one of our build deps is currently being built.
[00:24] <robru> michi: no, not "waiting". "depwaiting". it means dependencies aren't available: https://launchpad.net/~ci-train-staging-area/+archive/ubuntu/landing-008/+build/7833477
[00:25] <michi> right. OK, that should be resolved in a few minutes, I would think?
[00:25] <robru> michi: no? why would you think that?
[00:25] <michi> Isn’t it building right now?
[00:25] <robru> michi: I'm not aware of anybody building libnet-cpp-dev anywhere
[00:25] <michi> https://launchpad.net/builders/lgw01-51
[00:26] <michi> Started 4 minutes ago
[00:26] <michi> That page is linked to from https://launchpad.net/~ci-train-staging-area/+archive/ubuntu/landing-008/+build/7833477
[00:26] <robru> michi: i don't see libnet-cpp-dev on that page?
[00:26] <michi> This is very strange.
[00:26] <michi> Check the second link I just pasted.
[00:27] <michi> It says that we are waiting for libnet-cpp-dev
[00:27] <michi> then follow the lgw01-51 link
[00:27] <robru> michi: the last link you pasted says the build is depwait, which is for the most part a failure mode. the builder you linked to is building emacs-snapshot of all things.
[00:27] <michi> Yes. Now why is that linked to from the page that says scopes-api is waiting on netcpp?
[00:28] <robru> michi: because the version of netcpp that you want is not available in vivid.
[00:29] <robru> michi: https://launchpad.net/ubuntu/+source/net-cpp vivid has 1.1
[00:29] <robru> michi: your deps say ">= 1.2"
[00:29] <michi> Ah...
[00:29] <robru> michi: depwait means "this has failed and here's why"
[00:29] <robru> nobody is building netcpp
[00:29] <michi> More conflicts between control and control.in, sigh...
[00:30] <michi> So, for vivid, the build deps are less stringent.
[00:30] <robru> michi: well, then you can update your control hackery to make it say >= 1.1 in vivid and >= 1.2 in wily
[00:31] <michi> robru: yes
[00:31] <michi> Except that we need to get the build-deps from control *before* it is generated, no?
[00:32] <robru> hmmm
[00:32] <michi> Or would it be good enough to generate the build-deps from the clean target
[00:32] <michi> If so, that’s not a problem.
[00:32] <robru> michi: no slangasek told me that the build deps are expected to be installed before you run the clean target.
[00:32] <michi> Sigh...
[00:33] <michi> Looks like I’m stuck again then
[00:33] <michi> Because we need different versions for some build deps on wily and vivid
[00:33] <michi> Hmmm...
[00:33] <michi> So, the solution would be to write control such it mentions the least-stringent build dep.
[00:34] <michi> Then, on wily, when the actual build dep is installed,
[00:34] <robru> michi: yeah I was just going to say
[00:34] <michi> it’ll pull the latest anyway.
[00:34] <slangasek> different versions of build-deps?
[00:34] <michi> slangasek: it seems so.
[00:34] <robru> michi: probably make the official control have >= 1.1 but then when wily generates it it can change to 1.2 later
[00:34] <slangasek> why? that's far from what I discussed with robru
[00:34] <michi> I don’t know right now.
[00:34] <robru> yeah that does seem weird.
[00:34] <michi> Need to check.
[00:34] <robru> I don't know why the same codebase would have different build deps on different releases.
[00:35] <michi> You’d think they should not differ because we are building the exact same code on vivid and wily
[00:35] <michi> Exactly
[00:35] <michi> this is probably some mistake that crept in somewhere.
[00:35] <slangasek> right
[00:35] <robru> michi: just set it to 1.1 then and see what happens.
[00:35] <michi> Will try that, thanks.
[00:35] <robru> slangasek: any thoughts on lsb release while you're around?
[00:35] <slangasek> robru: what about it?
[00:36] <michi> guess what?
[00:36] <slangasek> I just checked gcc source and it looks for lsb_release -cs
[00:36] <michi> There are *two* dependency lines for netcpp in control :(
[00:36] <robru> slangasek: well in the hangout you said something like "lsb_release isn't what I'd use but it's ok" and I don't even know what other options are available
[00:36] <robru> michi: I don't understand the problem? just set them both to 1.1?
[00:36] <slangasek> robru: turns out lsb_release is what everyone's using ;)
[00:36] <robru> heh
[00:37] <michi> robru: Well, there should be only one, for starters.
[00:37] <robru> michi: not necessarily? could have one as a build dep and one as a runtime dep. but I don't really know it well enough to say
[00:38] <michi> I would have thought it doesn’t make sense to list the same package with different versions in the *same* stanza
[00:38] <michi> The build deps for unity-scopes-api listed netcpp twice, with different version numbers
[00:38] <robru> michi: well yeah, that doesn't make sense. why can't you just set them both to 1.1?
[00:38] <robru> or just only have one...
[00:39] <michi> I’ve deleted the 1.2 one
[00:39] <michi> Yes. I mean, if two are better than one, three must be better than two? ;)
[00:39] <robru> michi: sorry I didn't realize you meant in the same stanza at first
[00:40] <robru> michi: also maybe use 'wrap-and-sort -a -t', it'll alphabetize your deps so that duplicate ones will be side by side, more obvious.
[00:40] <michi> Can hardly blame you, because that’s not supposed to happen :)
[00:40] <michi> You need to tell that to some of colleagues ;)
[00:40] <robru> michi: I'm a huge fan of wrap-and-sort but a lot of people don't like the noisy diff that you get the first time you use it as it shuffles everything around.
[00:41] <robru> michi: but since you're making a huge diff anyway, seems like a good time to throw that in there...
[00:41] <michi> Absolutely!
[00:41] <robru> michi: lol you should just call wrap-and-sort in your override_dh_auto_clean :-D
[00:42] <michi> :)
[00:42] <michi> robru: Just pushed again
[00:43] <michi> There is one more thing that’s wrong:
[00:43] <robru> oh?
[00:43] <michi> The conflicts section needs to list unity-scopes3 for wily, but not for vivid.
[00:43] <michi> But that’s just more hackery in my script.
[00:43] <michi> Without this, I think it’ll fail during a dist-upgrade from vivid to wily
[00:43] <slangasek> why are you overriding dh_auto_clean?
[00:43] <michi> slangasek: Because Didier told me to :)
[00:43] <robru> slangasek: that's how he calls is control-generating script
[00:44] <slangasek> hmm
[00:44] <robru> slangasek: I thought this is what we talked about in the meeting this morning?
[00:44] <slangasek> robru: I never said "auto_clean", I said "clean"
[00:44] <slangasek> this should probably be directly as part of a clean: target
[00:44] <michi> slangasek: Can you help me here and tell me what I should be doing instead? I’m a debian virgin :(
[00:45] <robru> slangasek: the train calls "clean" which calls "dh clean" which calls override_dh_auto_clean
[00:45] <slangasek> 'dh clean' calls a lot of things; this doesn't make override_dh_auto_clean the right place to encode this.
[00:45] <robru> slangasek: also his rules are legit, he passes through to the stock dh_auto_clean
[00:45] <robru> slangasek: oh I didn't think anything of it
[00:46] <slangasek> the meaning of 'dh_auto_clean' is 'run the upstream clean target to clean the source tree of build artifacts"
[00:46] <slangasek> s/"/'/
[00:46] <robru> slangasek: https://code.launchpad.net/~michihenning/unity-scopes-api/single-tree/+merge/268433 line 2161 of the diff if you want to comment
[00:47] <robru> michi: https://ci-train.staging.ubuntu.com/job/ubuntu-landing-008-1-build/5/console started
[00:47] <michi> Thanks. Watching with baited breath...
[00:48] <robru> slangasek: I'm not sure what other things 'dh clean' runs that would be sooner/more relevant
[00:50] <slangasek> well, what I was saying is that I thought it would be better as a clean: target
[00:50] <slangasek> however 'dh clean --no-act' tells me I'm wrong
[00:50] <slangasek> let's stick with override_dh_auto_clean for now
[00:53] <robru> ok
[00:53] <robru> michi: ok well we're past the depwait at least, now the real question is whether or not the builds succeed
[00:53] <robru> with the right binary package names
[00:54] <michi> robru: Yes. I know it works on wily at least.
[00:54] <michi> Not that this helps if it doesn’t on vivid...
[00:55] <robru> michi: https://launchpadlibrarian.net/215463338/buildlog_ubuntu-vivid-amd64.unity-scopes-api_1.0.1%2B15.04.20150825.1-0ubuntu1_BUILDING.txt.gz build failed in vivid, looks like you're missing a dependency.
[00:56] <michi> Looking, thanks!
[00:56] <robru> michi: ok I just went live with the train changes so you should be able to do builds in silo 10 from here on out
[00:56] <michi> Sweet.
[00:56] <michi> So, looks like there is another dep on netcpp 1.2 kicking around somewhere.
[00:57] <michi> Yes.
[00:57] <michi> Hmmm… I don’t know what happened there.
[00:57] <michi> How could this have ever built on vivid?
[00:57] <robru> michi: well, depends what you mean. if the debian/ package was depending on 1.2 it would have depwaited again. the fact that it built but failed implies that you really do need netcpp 1.2
[00:58] <michi> But, we’ve been building just fine for vivid and wily for ages.
[00:58] <robru> michi: I dunno man it's your thing ;-)
[00:58] <michi> But vivid doesn’t *have* 1.2
[00:58] <michi> robru: Too bloody right :)
[00:58] <michi> It’s not your problem, I know.
[00:58] <michi> I’ll check our respective trees...
[00:58] <robru> michi: heh, here to help of course, but yeah I don't know why how it used to work on vivid.
[00:59] <michi> I’ll check and see where and why this was changed.
[00:59] <robru> michi: backporting 1.2 to vivid (at least for the overlay PPA) is probably an option if it's too difficult to make your code build with 1.1
[00:59] <michi> I think I know.
[00:59] <michi> Maybe.
[01:00] <michi> I suspect that 1.2 is only in the overlay ppa
[01:00] <robru> michi: indeed
[01:00] <robru> michi: ohhhhhhh
[01:00] <robru> I see
[01:00] <michi> Well...
[01:00] <robru> michi: it's because the staging area doesn't have access to the production overlay ppa, it has a separate overlay ppa that doesn't have any packages in it
[01:01] <robru> michi: so this should Just Work if you trigger a build in production silo 10.
[01:01] <michi> Aha.
[01:01] <michi> Yes
[01:01] <robru> because the production silos include the overlay ppa
[01:01] <michi> And I need to change all the 1.1 deps to 1.2
[01:01] <michi> right
[01:01] <robru> yeah
[01:01] <michi> Phew!
[01:01] <robru> hehe. "backporting 1.2 is an option", except you already did that ;-)
[01:03] <michi> OK, about to kick the silo 10 build. Fingers crossed...
[01:06] <robru> michi: oh, what are you doing with 0replaceme?
[01:06] <michi> These are new symbols that were added by Pawel just recently.
[01:06] <michi> In the merge that was missing earlier.
[01:06] <michi> My branch was behind reality because Pawel merged something recently
[01:06] <robru> michi: but what is this tools/symbol_diff.in script doing?
[01:07] <michi> We use that script to help us keep the symbols file up to date.
[01:07] <michi> Among other things, it does a sort :)
[01:07] <michi> So the symbols file is in alphabetical order.
[01:07] <michi> So, if a build reports a problem with the symbols file, you run that tool.
[01:07] <michi> the tool generates a diff from the old and new symbols file.
[01:07] <robru> michi: oh ok. sorry I thought you were doing some magic with 0replaceme that was going to conflict with train magic, didn't realize you were *using* the train magic.
[01:08] <michi> If the diff looks good, you can then just patch the tree with it to bring the symbols file up to date.
[01:08] <michi> See the instructions in HACKING :)
[01:08] <michi> Yeah.
[01:08] <michi> The symbols file is the bane of our lives.
[01:08] <michi> It’s totally unsuitable for C++, unfortunately.
[01:09] <michi> It just creates a lot of maintenance work, and gives us very little protection against ABI breaks in return.
[01:09] <michi> It’s the wrong tool for the job.
[01:09] <michi> My next job is to come with something to automate abi-compliance-checker, which does a *far* better job at ferreting out ABI breaks.
[01:10] <robru> michi: ah, interesting. I know remarkably little about C/C++
[01:11] <robru> michi: was gonna say "but ABI breaks!", didn't know it doesn't work for C++
[01:11] <michi> robru: Even for C, the symbols file is extermely poor assurance against ABI breaks.
[01:11] <robru> really?
[01:11] <michi> Yes.
[01:11] <michi> There are dozens of ways you can break the ABI without it ever showing up the symbols file.
[01:11] <michi> For example:
[01:11] <robru> huh
[01:11] <michi> Change the return type of a function.
[01:11] <michi> Add a member to a struct.
[01:12] <michi> Change the order of members of a struct.
[01:12] <michi> Add an enumerator to an enumeration.
[01:12] <michi> Or change the order of enumerators.
[01:12] <michi> Change a #define.
[01:12] <robru> wow I had no idea
[01:12] <michi> Change the order of parameters of a function call, or change the type of any of the parameters.
[01:12] <michi> None of these things (in C) affect the symbols.
[01:13] <michi> With C++, it’s a little better, because parameter types are part of the mangled symbo.
[01:13] <michi> symbol.
[01:13] <robru> slangasek: ^ can you comment on this? why do we fuss over symbols files if they don't guarantee the whole ABI?
[01:13] <michi> But none of the other things I listed will be caught.
[01:13] <michi> the point of symbols files isn’t to establish whether the ABI was broken, although that is what people keep saying.
[01:13] <michi> They are wrong.
[01:13] <robru> heh
[01:14] <slangasek> no, that is exactly the purpose of symbols files
[01:14] <michi> the point of the symbols file is to record at which revision level each symbol was first added to the library.
[01:14] <slangasek> they aren't a complete solution for this
[01:14] <michi> slangasek: They don’t do it though.
[01:14] <michi> They miss so many things it’s not funny
[01:14] <michi> It is a completely and utterly inadequate check for ABI compliance.
[01:14] <slangasek> they *catch* so many things it's not funny
[01:14] <michi> That’s not good enough.
[01:15] <michi> We shouldn’t be focusing on the things it catches, but the ones it misses.
[01:15] <michi> abi-compliance-checker makes none of those mistakes.
[01:15] <slangasek> michi: your diff doesn't show abi-compliance-checker being used at package build time
[01:15] <michi> As far as I can see, the point of the symbols file is to record when each symbol was first added.
[01:15] <slangasek> is it?
[01:15] <robru> slangasek: not yet, he said that was the next thing he'd work on fixing
[01:16] <slangasek> ok
[01:16] <michi> Then, by looking at all the symbols that are unresolved in a dependee, I can automatically work out what the minimum revision level is that the dependee needs to link with.
[01:16] <michi> slangasek: acc reads the headers for the old and new version, and it reads the symbols for the new and old version.
[01:16] <michi> It then does an in-depth analysis
[01:17] <michi> It does a lot of very thorough stuff.
[01:17] <michi> Like analyzing the inheritance tree.
[01:17] <robru> michi: I'm a little bit concerned about the changelog here: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-010/+sourcepub/5325324/+listing-archive-extra it says it updated the symbols.in file rather than the symbols...
[01:17] <michi> Checking for reordering of bases with multiple inheritance.
[01:17] <michi> comparing vtbls
[01:17] <michi> checking enumerators.
[01:17] <michi> return types
[01:17] <michi> etc, etc.
[01:17] <michi> Looking...
[01:17] <slangasek> michi: I'm very familiar with abi-compliance-checker - including how difficult it is to manipulate in practice.  If you're going to do the work to integrate it with your packages in a way that ensures ABI breakage will be caught at package build time and fail the build, I have no objections to this
[01:18] <michi> slangasek: that’s the plan
[01:18] <michi> Yes, agree, it’s cumbersome to use.
[01:18] <michi> That’s what I’d like to improve.
[01:18] <michi> but, if we get that to work, I think it would be a big win.
[01:18] <slangasek> we currently require symbols files because it catches *most* ABI breakage; it's a minimum standard, not a mandatory interface
[01:18] <michi> Much better assurance that we haven’t broken anything, and much less maintenance work.
[01:18]  * slangasek nods
[01:18] <michi> Yes.
[01:19] <michi> But, frankly, we already have done things that technically have broken the ABI, but we’ve snuck it past the symbols file.
[01:19] <michi> the symbols file just doesn’t make the grade for C++ especially.
[01:19] <michi> There are *so* many more ways in C++ to break ABI than in C.
[01:20] <michi> robru: I’m not sure what the train is trying to tell me here.
[01:20] <robru> michi: yeah I'm just reading through the source code to figure it out myself, one sec
[01:21] <michi> We don’t have a symbols file anymore.
[01:21] <michi> Instead, we have symbols.in, which generates the symbols file.
[01:21] <michi> That’s because the soversion needs be part of the name of the symbols file.
[01:22] <robru> michi: I think it's ok. That changelog entry means "the train replaced 0replaceme with real version numbers in this file", I was worried it meant that it replaced it in your symbols.in instead of your symbols, but it does this before the package build so your symbols file generation magic should be running happily with the correct version number in the
[01:22] <robru> symbols.in file...
[01:23] <michi> Ah, OK
[01:23] <michi> That’s as it should be.
[01:23] <robru> michi: I was just surprised to see "symbols.in" in the changelog rather than "symbols"
[01:23] <michi> Yeah
[01:23] <michi> What I’m doing is a bit weird, I admit :)
[01:23] <michi> thank gcc...
[01:24] <michi> the problem really is that the gcc change has broken process left right and center.
[01:24] <michi> Nothing we use was ever designed to cope with something like that.
[01:24] <michi> Not debian, not citrain, not our build process
[01:24] <robru> yeah this is a pretty massive migration
[01:25] <robru> michi: what you're supposed to do is just only develop for wily and forget about vivid ;-)
[01:25] <michi> tell that to someone who needs to support a phone...
[01:25] <michi> doesn’t need to, I meant...
[01:25] <robru> michi: phone? what phone?
[01:25] <robru> michi: you mean like on the wall? ;-)
[01:25] <michi> Let me check, see if I can find it...
[01:26] <michi> there was something about a phone...
[01:26] <robru> nah
[01:26] <michi> So, I think the replaceme thing is fine.
[01:26] <michi> debian puts the correct version there.
[01:27] <michi> Then, when we back-merge from trunk onto devel after release, we pick up the right number.
[01:27] <robru> michi: well this MP is targetting devel already, so you'll need to merge it to trunk manually at some point
[01:27] <michi> Yes.
[01:27] <michi> right.
[01:27] <michi> Forgot.
[01:27] <michi> That’s Pawel’s job :)
[01:27] <robru> michi: can you confirm that these are the correct binary packge names for vivid? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-010/+build/7833612
[01:27] <michi> At least for unity-scopes
[01:27] <michi> Looking
[01:28] <michi> :(
[01:28] <michi> These all should have a 0.6.x version number :(
[01:28] <robru> michi: and this one for wily? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-010/+build/7833605
[01:28] <robru> no?
[01:28] <michi> Aargh
[01:28] <robru> michi: oh yeah, no, i told you the 0.6 thing isn't possible
[01:28] <robru> just the package names
[01:29] <michi> Hmmm...
[01:29] <michi> So, the libunityscopes3 thing is fine.
[01:29] <michi> Same with qt.
[01:29] <michi> Now...
[01:29] <michi> the dev package will have 1.0.1 on wily and vivid.
[01:29] <robru> michi: seems a bit weird that vivid is "3" while wily is "1.0"
[01:29] <michi> But the version following that will be different.
[01:29] <michi> robru: the 3 is historical.
[01:29] <robru> michi: yeah but it'll be 1.0.1+15.04 for vivid and 1.0.1+15.10 for wil
[01:30] <michi> I got sick of meaning less sonames
[01:30] <michi> Because when I see “3”, I have no bloody idea what release that corresponds to.
[01:30] <michi> So, as of wily, we’ve aligned the soname with the release version.
[01:30] <robru> ah ok
[01:30] <michi> So, when I look at an so, I can immediately tell what release it belongs with.
[01:31] <michi> So, the full package name then is different for vivid and wily.
[01:31] <michi> because it mangles the release version intot he name
[01:31] <michi> sweet, this looks really good!
[01:31] <robru> michi: great
[01:31] <michi> OK, so I’m not quite done yet with my branch.
[01:32] <michi> I’ll set it to “QA needed”
[01:32] <michi> Is that the right one?
[01:32] <michi> Or QA required?
[01:32] <michi> Anyway, once I have the final polish on it, I’ll put it through the normal process.
[01:32] <robru> michi: it depends. what are you trying to do? submit it to qa?
[01:32] <michi> No, not yet.
[01:32] <michi> I’m still working on it.
[01:32] <michi> There are a few more things I need to fix.
[01:32] <michi> But this has validated the concept.
[01:32] <robru> michi: then 'qa required'. and when youre ready, set it to 'ready for qa'
[01:33] <michi> robru, thank you so much again. this was just bloody awesome. There is no way I could have done this without your help!
[01:33] <robru> michi: you're welcome! glad it's saving you work, that's what I aim for, solve inefficiencies
[01:34] <robru> I wonder how many other people will want to do something similar.
[01:34] <michi> It sure as hell will make a big difference.
[01:34] <michi> unity-api
[01:34] <michi> unity-scopes-shell, probably
[01:34] <michi> maybe unity8
[01:34] <michi> Basically anything that builds a library that needs to work for both vivid and wily, if the library uses std::string or std::list anywhere in its interface.
[01:35] <michi> That’s almost every C++ library/module we build
[01:35] <michi> I think everyone has just gone and split their tree.
[02:06] <michi> robru, slangasek: The symbols file strikes again
[02:06] <michi> https://launchpadlibrarian.net/215466145/buildlog_ubuntu-vivid-armhf.unity-scopes-api_1.0.1%2B15.04.20150825-0ubuntu1_BUILDING.txt.gz
[02:08] <michi> For some reason, only on Armhf
[02:53] <robru> michi: uh
[02:55] <robru> michi: i have no idea why that would fail on only armhf
[02:57] <robru> michi: looks like some confusion between the wily and vivid versions in the symbols file...
[02:58] <robru> michi: I'm not sure, but the way duals work is they build wily first, then copy the result and build it again for vivid. So probably your symbols script is tripping up on itself when it's run the second time in vivid, you have to make sure it does the right thing in vivid.
[02:59] <robru> No wait, it copies before building
[02:59] <robru> But it does copy after the 0replaceme magic happens
[04:22] <michi> robru: if you are still around...
[04:22] <michi> it appears the version that is substituted is wrong for some reason
[04:23] <robru> michi: i wrote some messages an hour ago, did you see them?
[04:23] <michi> Yes.
[04:23] <michi> Sorry was AFK for a while
[04:23] <michi> So, the original version is  1.0.1+15.10.20150825.1
[04:23] <michi> All the symbol versions look like that.
[04:24] <michi> But what it add is this: 1.0.1+15.04.20150825.1-0ubuntu1
[04:24] <michi> Why  the ubuntu version at the end?
[04:24] <michi> And only on Arm?
[04:24] <robru> michi: that makes no sense, there's no code adding Ubuntu to the version only on arm
[04:24] <michi> Right
[04:25] <robru> michi: the train will put Ubuntu in the symbols version though, that should be the same on all arches
[04:26] <michi> Normally, there is no ubuntu version in the symbols file.
[04:26] <robru> michi: I'm not aware of any arch-specific code on the train, it should do everything the same on all arches
[04:26] <michi> This is exceedingly strange.
[04:26] <michi> It’s not Arm generally, only Armhf
[04:27] <michi> The build succeeded on everything else.
[04:28] <robru> michi: here is the code that handles merges: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/view/head:/citrain/recipes/merge.py#L56 this is what merges the branches and then updates the symbols, etc.
[04:28] <robru> it's not too magical
[04:28] <michi> Thanks!
[04:29] <robru> michi: so that would be for the wily build. then the vivid build is copied from that here: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/view/head:/citrain/recipes/secondary.py#L56
[04:29] <michi> So, the symbols file munging for replaceme is done by some debian tool, right?
[04:29] <michi> I wonder whether that tool is passed the wrong version number on Armhf for some reason
[04:31] <robru> michi: nope, that's train specific magic
[04:32] <robru> michi: that's done here: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/view/head:/cupstream2distro/packagemanager.py#L193 and that's called from Merge.collect_phase (first link)
[04:32] <michi> looking, thanks!
[04:33] <robru> michi: so the fact that the version is wrong is understandable, because the way the train works for a dual silo is this: 1. merge the merges, 2. update the symbols files, 3. copy the wily package to be a vivid package, 4. munge the vivid version into the changelog, 5. build wily & vivid source packages in parallel
[04:33] <michi> So, are you saying we are seeing this for Armhf only because of the order in which things finished happened to be this way?
[04:33] <robru> michi: what I don't understand is why this is actually a problem, if the symbols file in vivid gives a wily version number. what is checking that, what is breaking on that?
[04:34] <robru> michi: no I'm saying that this is absolutely the same, in python, on all arches. every build will have wily versions in the vivid symbols file
[04:34] <michi> It fails the Armhf build
[04:34] <michi> Aha
[04:34] <michi> Well, we only have a symbols file for Vivid.
[04:34] <michi> We don’t have one for Wily
[04:35] <michi> The build failure is here, near the very end: https://launchpadlibrarian.net/215470204/buildlog_ubuntu-vivid-armhf.unity-scopes-api_1.0.1%2B15.04.20150825.1-0ubuntu1_BUILDING.txt.gz
[04:36] <michi> Hmmm...
[04:36] <michi> I think I’ll try again locally with bzr bd.
[04:36] <michi> There may have gone something wrong with the patch for the symbols file.
[04:38] <robru> michi: oh actually weird, I'm reviewing the code, it should be stripping 0ubuntu1 from the symbols...
[04:38] <michi> Yes
[04:39] <robru> michi: according to http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/view/head:/cupstream2distro/packagemanager.py#L200 it calls "get_upstream" which rips the -0ubuntu1 off, and then later it uses that in the file.
[04:39] <robru> michi: so I don't know where that -0ubuntu1 is coming from, unless something broke on your end.
[04:39] <michi> Checking…
[04:40] <michi> waiting for my bzr bd to do its thing
[04:40] <robru> michi: does your code mangle the symbols files beyond adding 0replaceme? because "1.0.1+15.10.20150825.1" is what I would expect to see in the symbols file (even for vivid) given how the code is written.
[04:40] <michi> No, our code doesn’t do that.
[04:41] <michi> At least I’m pretty sure it doesn’t.
[04:41] <robru> michi: so it seems to me that you have a s/wily version/vivid version/ going on in your code somewhere
[04:41] <michi> Possibly
[04:47] <robru> michi: hum that's really strange. I don't see where it could possibly be coming from. checked train code AND your code.
[04:47] <michi> I can’t see it either right now.
[04:47] <robru> michi: train is definitely not doing it, for the vivid builds all it does it changes the first line of debian/changelog only, it doesn't touch symbols at all
[04:47] <michi> The update_widgets() method is new.
[04:47] <michi> I just added the replaceme entry for it.
[04:48] <michi> BTW, when I do a rebuild of a silo, I almost always need to hit “Build” twice.
[04:49] <michi> The first time it doesn’t do anything.
[04:49] <michi> Second time seems to always work.
[04:49] <michi> Not that this is important right now, just mentioning it.
[04:49] <michi> I’ve just kicked off another build after fixing a few other things. But I don’t expect it’ll magically fix this symbol issue.
[04:51] <robru> michi: yeah that's a known issue, the first time you click build you are getting redirected through SSO and back to the build form. then you click it a second time and it works again. for some reason jenkins times out logins after approximately 10 femtoseconds so you have to hit build twice almost every time.
[04:51] <michi> 10 femtoseconds… Impressive! :)
[04:52] <robru> michi: I've tried, I can't find any way to make jenkins keep the login for more than like 10 minutes, I'd prefer if it kept you logged in for 12 hours or so, then you only have to log in once per shift
[04:52] <michi> Interesting.
[04:52] <michi> The CI Jenkins doesn’t do that.
[04:52] <robru> michi: seriously I hate jenkins so much
[04:52] <michi> It ends to keep me logged in for ages.
[04:52] <robru> michi: replacing jenkins with something that doesn't suck is on the Big List Of Crap To Do One Day.
[04:52] <michi> robru: We should start a “Victims of Jenkins” help line.
[04:52] <michi> Well, I don’t mind Jenkins so much actually
[04:53] <michi> It’s been working pretty well for us the past two or three months.
[04:53] <michi> Not many hick-ups.
[04:53] <robru> michi: using it isn't horrible but adminning it has just just awful
[04:53] <michi> Ah
[04:53] <robru> michi: it's written in java so the tracebacks are about ten thousand lines long and tell me nothing about anything. and it tracebacks all the time
[04:53] <robru> but anyway
[04:54] <robru> michi: http://bazaar.launchpad.net/~michihenning/unity-scopes-api/single-tree/view/head:/tools/symbol_diff.in#L119 when does this get run? I wonder if you're calling that on the vivid build, and clobbering over the wily versions? which would be strange because the train doesn't actually do 0replaceme in vivid.
[04:55] <robru> or rather "doesn't do it in a dual silo on vivid". only the primary landing series has it's 0replaceme replaced.
[04:55] <michi> This is never run as part of a build.
[04:55] <michi> We run this by hand, if we have a symbols file errors.
[04:55] <robru> ah
[04:55] <michi> There is a symbols file only for Vivid.
[04:55] <michi> It’s generated by my script.
[04:55] <michi> there is no symbols file on Wily.
[04:55] <michi> Instead, on Wily, here is a shlibs file.
[04:56] <robru> michi: but the symbols.in file that you have, the 0replaceme part is replaced when processing the wily build, and then the resulting wily number is copied into the source tree of what is built in vivid.
[04:56] <michi> Hmmm…
[04:57] <michi> I *only* generate a symbols file on Vivid.
[04:57] <michi> If we are building on Wily, I don’t generate it, so there isn’t one.
[04:57] <robru> michi: well I *only* replace 0replaceme in wily :-P
[04:57] <michi> Sorry, not with you here.
[04:57] <michi> Copying a symbols file from one distro to another is a totally invalid thing to do.
[04:57] <michi> It can’t work.
[04:58] <michi> Because the symbol mangling for gcc 4.9 and 5.0 is different
[04:59] <robru> michi: k, here's how dual silos work: 1. all the merges are merged into one source tree and this is given a wily version number in debian/changelog, and 0replaceme is replaced with the wily version number in all files. 2. the resulting directory is copied into a secondary directory and debian/changelog alone is changed to reflect that this is now a vivid
[04:59] <robru> build. 3. these two directories are built and uploaded to the PPA.
[04:59] <michi> Hmmm...
[04:59] <michi> A wily symbols file cannot generally work on vivid.
[04:59] <michi> I’m pretty sure about that.
[04:59] <michi> The new ABI changes the name mangling for std::string
[05:00] <robru> michi: well it's not "a wily symbols file" I am not generating your symbols file. What I'm doing is replacing 0replaceme with the wily version number in your *symbols.in* that you then presumably do magic with once the vivid build starts.
[05:00] <michi> Ah.
[05:00] <michi> Well, that would be fine
[05:00] <michi> There is no magic for the symbols file.
[05:01] <robru> michi: that's why, if you remember from quite a bit earlier, I mentioned in your changelog it said "symbols.in" and I was surprised to see that.
[05:01] <michi> All we do is copy symbols.in to the correct target file (which needs the soname mangled into the file name)
[05:01] <michi> And we rewrite the first line.
[05:01] <michi> Hmmm...
[05:01] <robru> michi: "no magic" but you do *something* to convert symbols.in into the vivid symbols file.
[05:01] <michi> Maybe something is going wrong there.
[05:01] <michi> Let me check...
[05:02] <michi> No, that’s not it.
[05:03] <robru> michi: well I'm pretty stumped
[05:04] <michi> Same here.
[05:04] <michi> Waiting to see what the new build does.
[05:04] <michi> It’s just totally weird that this happens only an Armhf
[05:05] <robru> michi: http://paste.ubuntu.com/12190426/ when you see this in the diff, the minus line showing the wily version number without the -0ubuntu1, that's the result of what the train is doing, so that's what the package is expecting. for some reason whatever it's diffing against is coming out wrong.
[05:05] <robru> that is really weird.
[05:06] <michi> So, the build must have generated a DEBIAN/symbols file with the ubuntu version in it.
[05:06] <michi> Because that’s what the diff is agains.
[05:06] <michi> against.
[05:07] <robru> michi: yeah, I'm reading that a bit more. it's diffing against the output of dpkg-gensymbols.
[05:07] <robru> I'm not sure why that's including the 0ubuntu1
[05:08] <michi> So, dpkg-gensymbols is probably passed the wrong version
[05:08] <michi> Or picks up the wrong version from somehwere.
[05:12] <robru> michi: well, 10PM here, I gotta signoff I'm afraid. Can pick this up tomorrow if you're still stuck
[05:12] <michi> Yes, of course.
[05:12] <michi> Way too late to be working.
[05:12] <robru> goodnight!
[05:12] <michi> Thanks heaps for all your help!
[05:12] <michi> Nite, nite! ;)
[05:12] <robru> you're welcome!
[05:15] <Mirv> so much backlog :)
[05:18] <Mirv> michi: so feel free to continue with me, although I see your problem sounds like something that needs a bit heavier dose of coffee :)
[05:18] <michi> It ain’t pretty :)
[05:24] <Mirv> michi: I think you were pretty focused on what the train does, but the builders also normally give a symbol diff if they detect a mismatch, and there they always use the full ubuntu version
[05:24] <michi> Mirv: the strange thing is that this happened only on Armhf and nowhere else.
[05:25] <Mirv> michi: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-010/+builds?build_text=&build_state=all didn't it also happen on powerpc and i386, so in practice on all 32-bit?
[05:25] <michi> Looking
[05:26] <michi> Seems like you are right, it’s not just Armhf
[05:27] <michi> OK, I think I know.
[05:27] <Mirv> but vivid only fails? it seems to claim the vivid version has added by you 15.10 symbols but it notices they should be 15.04
[05:27] <michi> What version of gcc are we building with on these failing platforms?
[05:27] <Mirv> on vivid, all platforms are gcc 4.9
[05:28] <michi> Aha.
[05:28] <Mirv> oh but there are the new symbols too right, ZN5*
[05:29] <michi> Yes
[05:29] <Mirv> michi: ok, looking at the successful 64-bit logs https://launchpadlibrarian.net/215475575/buildlog_ubuntu-vivid-arm64.unity-scopes-api_1.0.1%2B15.04.20150825.2-0ubuntu1_BUILDING.txt.gz the 15.10/15.04 are not the fatal ones (they are only mentioned, but build is not aborted), so it's the addition of those ZN5/ZNK5* symbols on 32-bit archs on vivid that break it
[05:30] <michi> Yes.
[05:30] <michi> And that is because int64_t turns into long long on 32 bit
[05:30] <michi> Sigh.
[05:30] <michi> I’m just so bloody sick of this idiotic linker technology.
[05:30] <michi> This stuff is more than thirty years old.
[05:30] <michi> I suspect that we need architecture-specific tags.
[05:31] <Mirv> yeah, (arch=armhf i386 powerpc)
[05:33] <michi> Still doesn’t explain the other differences, where the version number changes
[05:33] <Mirv> michi: maybe (optional|arch=armhf i386 powerpc) if you want to share the same symbols files between wily/vivid...
[05:34] <michi> We don’t have a symbols file for wily, only one for vivid.
[05:34] <michi> Maintaining two is not feasible and wouldn’t help anyway.
[05:34] <michi> We are compiling the exact same source for both distros.
[05:34] <Mirv> michi: well it checks the libs for new symbols and when it finds them, it notices they should actually have a 15.04 version number that's being built, and not the 15.10 one
[05:34] <michi> But the name mangling has changed in gcc 5
[05:34] <michi> Sorry not following. *What* checks the libs?
[05:35] <Mirv> michi: yes, so in order for the updated vivid symbols file with the ZN5 symbols added to work you'd need to add them as optional then
[05:35] <michi> Yeah
[05:35] <Mirv> michi: dpkg-gensymbols
[05:36] <Mirv> which is run during the building
[05:36] <michi> Ah
[05:36] <michi> Right at the end of this:
[05:36] <michi> https://launchpadlibrarian.net/215475029/buildlog_ubuntu-vivid-i386.unity-scopes-api_1.0.1%2B15.04.20150825.2-0ubuntu1_BUILDING.txt.gz
[05:36] <michi> I don’t get this:
[05:36] <michi> - (c++)"unity::scopes::Result::operator==(unity::scopes::Result const&) const@Base" 1.0.1+15.10.20150825.2
[05:36] <michi> + (c++)"unity::scopes::Result::operator==(unity::scopes::Result const&) const@Base" 1.0.1+15.04.20150825.2-0ubuntu1
[05:36] <michi> Where does the 0ubuntu1 version come from?
[05:36] <michi> The source of that is DEBIAN/symbols, I believe
[05:37] <Mirv> if maintainer wouldn't supply .symbols files at all, dpkg-gensymbols would simply add its own and everyone would be (almost) happy, but we tend to like requiring that we maintain the symbols files on our own to detect changes.. with the silo / QA approach, one could argue of course that we wouldn't land anything broken anyway even if we wouldn't hand manage symbol files, but probably that wouldn't go t
[05:37] <Mirv> hrough
[05:37] <michi> Right.
[05:38] <michi> I’m working on doing something with abi-compliance-checker.
[05:38] <michi> Which is much more thorough than symbols files.
[05:38] <Mirv> michi: it's the package being built, the only version dpkg really knows has the symbol. so, for example it doesn't for sure known if this new symbol wasn't added in a distro patch and not the upstream version, so it adds the full version
[05:38] <michi> Once that works, we can ditch symbols files altogether.
[05:38] <michi> One step at a time...
[05:38] <Mirv> sounds good :)
[05:38] <michi> Mirv: why is it doing that for only some of the platforms?
[05:39] <michi> It works on amd64, for example.
[05:39] <Mirv> I just routinely feed the build logs to pkgkde-symbolshelper when I update Qt packages, and then check the result. I've some automation but I'd still need to fully automate the downloading of the build logs..
[05:39] <michi> I have a replaceme entry in the symbols file I provide.
[05:39] <Mirv> michi: it adds them for all platforms, if you look at the build logs, but it doesn't flag them as fatal problems like it would if there were missing/new symbols.
[05:39] <michi> It seems that it substitutes the version without the ubuntu version on some platforms, but not on others.
[05:39] <michi> Ah.
[05:39] <Mirv> so it lets the build finish even though it detects a wrong version number
[05:40] <michi> So you are saying that, for example, the diff for updated_widgets() is harmless?
[05:40] <michi> And it’s really just barfing because of the arm-specific Variant constructor?
[05:40] <Mirv> michi: yes, for example the arm64 log lists that too https://launchpadlibrarian.net/215475575/buildlog_ubuntu-vivid-arm64.unity-scopes-api_1.0.1%2B15.04.20150825.2-0ubuntu1_BUILDING.txt.gz but lets the build pass
[05:41] <michi> Wow!
[05:41] <michi> IO was barking up the wrong tree all along!
[05:41] <michi> Thanks for that!
[05:43] <Mirv> michi: you're welcome! :) so I think something like this http://paste.ubuntu.com/12190519/ in the correct place would work for all builds, vivid and wily
[05:44] <michi> Yes, thanks for that!
[05:44] <michi> I need to check that our symbol munging helper script can deal with it too.
[05:49] <michi> Mirv: So, this really is a pre-existing bug in our symbols file.
[05:49] <michi> We have arch-specific entries in there already: (c++|arch=amd64 ppc64el arm64)"unity::scopes::experimental::DateTimePickerFilter::create(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::bitset<6ul>)@Base" 0.6.16+15.04.20150410.3
[05:51] <Mirv> michi: ah, ok
[05:51] <Mirv> robru: so it was not a train thing, just dh* working as usual, dpkg-gensymbols adds the full version number to the symbols file it generates and compares the maintainer file to
[05:52] <michi> Mirv: So, they are not optional. They need to be there, it’s just that they end up with a different type on 32 bit.
[05:52] <Mirv> michi: right
[06:00] <michi> Mirv: So, I’ve patched the symbols file and kicked the build.
[06:00] <michi> Fingers crossed, we are really close now...
[06:00] <michi> I’ll be AFK for 30 minutes...
[06:04] <Mirv> hoping for the best..
[06:34] <Mirv> michi: dpkg-gensymbols: error: long)@Base is not a valid version
[06:35] <michi> Mirv: thanks, i’ll have a look.
[06:35] <michi> I *hate* the blood symbols file.
[06:38] <michi> Mirv: Missing double quotest.
[06:38] <michi> quotes
[06:38] <michi> Mirv: How can I abort the current build of the silo so I can start a new one?
[06:39] <michi> Is it OK to just click the “stop” widget on https://ci-train.ubuntu.com/job/ubuntu-landing-010-1-build/
[06:39] <michi> Or is there something else I need to do?
[06:43] <Mirv> michi: that's ok
[06:44] <michi> I just tried it, seeing that, if the widget is there, it probably won’t blow up all of the train, only parts of it :)
[06:44] <michi> Mirv: Do I need to wait until the dashboard shows the build as finished before I start another one?
[06:46] <Mirv> michi: no, the build job is enough
[06:46] <michi> OK, I’ll re-start the build
[07:18] <bzoltan_> Mirv:  I have just realized that the silo41 could not be published because i have forget to happrove the MR ... now corrected. Sorry
[07:18] <Mirv> bzoltan_: ok
[07:20] <Mirv> bzoltan_: now done! we'll probably want another image build soon.
[08:11] <boiko> is there still a vivid+overlay channel to flash manta?
[08:11] <oSoMoN> ubuntu-qa: good morning! do you guys have some time for silos not targetted at ota6? I wouldn’t mind if silo 14 landed
[08:12] <jibel> oSoMoN, not really, more likely tomorrow
[08:13] <oSoMoN> jibel, ok, good to know, thanks
[08:15] <boiko> jibel: how about silo 26, which is fixing an OTA6 targetted bug?
[08:49] <kenvandine> jibel, pulseaudio translation fix uploaded to silo 28
[08:50] <kenvandine> mandel, john-mcaleely: ^^
[08:50] <john-mcaleely> kenvandine, thank you
[08:54] <mandel> sil2100, jibel do you have any idea about what is going on with silo 57?
[08:55] <kenvandine> ignore silo 28... we'll have to create another one
[08:55] <mandel> sil2100, jibel I guess that is the work from abeato before he left
[08:55] <mandel> kenvandine, silos are cheap ;)
[08:56] <kenvandine> sorry, i'm spamming silos
[08:57] <kenvandine> but i need one that we haven't already uploaded pulseaudio too :)
[08:59] <kenvandine> jibel, translation fix is in silo 33 now :)
[09:02] <sil2100> kenvandine: hmmm, I don't see the new string in the current ubuntu-rtm/15.04 pulseaudio templates, but they were there yesterday\
[09:03] <kenvandine> grr
[09:03] <sil2100> kenvandine: did you publish a new pulseaudio?
[09:03] <kenvandine> i wonder what could have happened
[09:03] <kenvandine> no
[09:03] <sil2100> hmm
[09:03] <kenvandine> seb128, ^^ ideas?
[09:09] <Mirv> kenvandine: powerpc build failure https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-033/+sourcepub/5325817/+listing-archive-extra , if flaky just kick a retry?
[09:10] <Mirv> a test is failing
[09:10] <Laney> can I have a silo build for trusty and wily at the same time?
[09:10] <Laney> or do I need two for that?
[09:10] <Mirv> ogra_: would you execute https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.wily_remove_friends/+merge/267648 now that all approves are done?
[09:10] <Mirv> sil2100: ^ see Laney's question but I think the only dual supported is vivid+wily, so needs two silos
[09:10] <kenvandine> Mirv, it's been failing
[09:11] <kenvandine> Mirv, the latest revision in the overlay ppa failed on powerpc
[09:11] <kenvandine> so not a regression
[09:11] <Mirv> ok then
[09:11] <kenvandine> Mirv, needs to be fixed, but mandel isn't going to look at fixing that until after ota6
[09:11] <sil2100> Laney: sadly dual-landings is a 'hack' that only works for wily + overlay
[09:11] <Laney> Mirv: I think so, since the target is a property of the silo and not the upload
[09:11] <Laney> k
[09:11] <Mirv> kenvandine: think about all the poor powerpc phone owners
[09:12] <kenvandine> haha :)
[09:12] <sil2100> Laney: we didn't want to enable it this way for other cases as it's not really 'nice', so that's not something you'd like to use for main series
[09:12] <kenvandine> it neefs fixing for sure though
[09:12] <kenvandine> needs
[09:12] <sil2100> Since we only re-write the version of the top changelog entry
[09:14] <jibel> kenvandine, okay, let me know when it is ready for us
[09:14] <kenvandine> jibel, will do
[09:15] <kenvandine> jibel, silo 25 has the other fix for pulseaudio, as well as the translation fix
[09:15] <kenvandine> it won't need a rebuild after 33, it includes the version in 33
[09:16] <jibel> kenvandine, yeah but I'd like to land 33 first to unblock translation, then if we can land 25 it's a bonus
[09:16] <kenvandine> jibel, right
[09:16] <kenvandine> that's why i included the version in 33 in 25
[09:16] <kenvandine> so it won't need a rebuild
[09:18] <davmor2> kgunn: 38 passes, I'm still concerned about the one test but we'll leave that for design for ota7 you might want to chase that up while you are in London maybe :)
[09:31] <sil2100> kenvandine: hmm, did you ask someone to re-upload the pulseaudio template? ;p
[09:31] <sil2100> The string is back ;p
[09:32] <kenvandine> sil2100, seb128 did it
[09:32] <kenvandine> again
[09:32] <sil2100> Aah! seb128 thanks :)
[09:33] <kgunn> davmor2: ack thanks, did you write down the concern in our doc ?
[09:33] <seb128> yw
[09:34] <kenvandine> jibel, armhf binaries in silo 33, you can test
[09:35] <davmor2> kgunn: it is the one already raised in comments, I still think if the user taps the power button in front of them the screen blanks and doesn't turn back on but by the ear that behaviour is reversed, although technically correct for an end user one of those behaviours will feel wrong because as far as they are concerned the actions are the same.
[09:37] <kenvandine> mandel, and you have armhf binaries now in silo 25
[09:37] <davmor2> kgunn: but as I say I'm happy it is technically correct and await designs response to see what they think a user would expect :)
[09:37] <kgunn> davmor2: ack, thanks for the testing and feedback
[09:38] <jibel> rvr, can you check 33? there is no card on the trello board but there is an armhf build in the ppa
[09:38] <rvr> jibel: Ok
[09:39] <davmor2> kgunn: but to be honest I don't know many people who would actually tap the power button other than by mistake, I would imagine that most people would just put the device to their ear and be done and that behaviour work either way :)
[09:39] <jibel> rvr, the diff is a one line change for the translations
[09:40] <jibel> +-        "%1% wants to record audio.");
[09:40] <jibel> ++        _("%1% wants to record audio."));
[09:41] <rvr> I just translated that line in Launchpad
[09:42] <rvr> Silo 33 says "Failed to build: pulseaudio failed to build."
[09:42] <jibel> rvr, unless you havea powerpc phone you shouldn't worry about that
[09:42] <rvr> he
[09:42] <rvr> I see
[09:43] <davmor2> jibel: you mean these aren't powerpc damn that's what I've been doing wrong all this time
[09:43] <kenvandine> :-D
[09:43] <jibel> rvr, packages for armhf are there https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-033/+build/7834358
[09:43] <kenvandine> weird... citrain isn't installing them from the ppa yet
[09:43] <kenvandine> maybe they aren't published
[09:44] <mandel> kenvandine, meh, so  citrain device-upgrade 25 0000 ubuntu does not update any package :-/
[09:45] <kenvandine> mandel, yeah, i'm guessing the ppa hasn't published them yet
[09:45] <kenvandine> i guess try again in a few
[09:45] <mandel> kenvandine, probably
[09:45]  * kenvandine twiddles thumbs
[09:45] <davmor2> kenvandine: published 25 minutes ago
[09:47] <davmor2> kenvandine, mandel: I assume you are both using wily's citrain right or the pinning won't be right unless you did it manually
[09:49] <kenvandine> no... vivid
[09:51] <mandel> davmor2, I'm on willy
[09:51] <mandel> wily
[09:52] <davmor2> kenvandine: you may have to pin it, but mandel should be good :(
[09:53] <kenvandine> davmor2, no, it's found it now
[09:53] <davmor2> \o/
[09:53] <jibel> kenvandine, 33 LGTM
[09:54] <kenvandine> jibel, great, then i won't bother testing it :)
[09:54] <kenvandine> i'm not really familiar with testing pulse anyway
[09:54] <jibel> kenvandine, yeah, the string is there and the name of the service is correctly replaced
[09:55] <kenvandine> awesome
[09:55] <kenvandine> i just saw the prompt too, looks fine
[09:56] <jibel> that's the only change, if the package installs and the string is correct, no need to retest all of pulseaudio and the trust store
[09:56] <kenvandine> great, ship it!
[09:56] <kenvandine> :-D
[09:57] <jibel> sil2100, silo 33 is good
[09:57] <kenvandine> mandel, any luck with 25?
[09:57] <sil2100> \o/
[09:57] <mandel> kenvandine, yes, testing
[09:57] <sil2100> Shipping!
[09:57] <kenvandine> sil2100, rock on!
[09:59] <sil2100> kenvandine, jibel: wait a moment, retrying powerpc as the failure seems to be just a test-failure
[09:59] <kenvandine> no
[09:59] <kenvandine> retry won't fix it
[09:59] <kenvandine> and it's not a new failure
[09:59] <kenvandine> it's a real failure for powerpc
[10:00] <kenvandine> and needs to be fixed... but shouldn't block this since the last version in the overlay had the same failure
[10:01] <sil2100> Laney: hey! Can we get this merge reviewed and top-approved? https://code.launchpad.net/~laney/autopilot-gtk/tests-wait-not-visible/+merge/268928
[10:02] <sil2100> I would need the same for https://code.launchpad.net/~canonical-platform-qa/autopilot-qt/wily_fix-unittests/+merge/268990
[10:02] <Laney> sil2100: I'm just testing that in a VM, maybe pitti would be one to ping if the main autopilot team are all gone
[10:02] <Laney> is there a rush?
[10:03] <jibel> nuclearbob will be online in a few hours if it can wait that long
[10:03] <sil2100> No :) It can wait a bit, just good if there would be someone remembering about it and poking us once those are approved
[10:03] <sil2100> kenvandine: ACK
[10:06] <sil2100> kgunn, jibel, kenvandine: does this mean we only have one remaining blocker to fix?
[10:07] <jibel> sil2100, yes silo 25
[10:07] <kenvandine> :-D
[10:07] <kenvandine> john-mcaleely, ^^ translation fix landed, just the one remaining blocker
[10:07] <jibel> 4th silo for the same fix, hard to keep track of the numbers :)
[10:08] <sil2100> kgunn, bzoltan_: I have a question regarding the emulator fixes - all landed in the overlay, but my question is - would there be a problem if we only copied the UITK one to the phone snapshot PPA?
[10:08] <john-mcaleely> kenvandine, yay
[10:08] <kenvandine> mandel, we're all looking at you now
[10:08] <davmor2> sil2100: the were all tested on phone no issues
[10:08] <jibel> sil2100, we also verified on a phone
[10:09] <jibel> sil2100, and in particular that there is no impact on the edge demo
[10:14] <sil2100> jibel: so, you think we can copy all those to the snapshot? The unity8, UITK and mir? Or just UITK? Since the UITK fix we have to include in all images as it was published before the blocker fix
[10:16] <jibel> sil2100, yeah it's either all of them or none.
[10:16] <sil2100> Ok...
[10:16] <sil2100> I'll do the copies in a moment
[10:19] <jibel> sil2100, can you send build an image? without waiting for 25
[10:19] <jibel> s/send/then/
[10:20] <jibel> unless you want to wait for the translations
[10:20] <rvr> jibel: kenvandine: Silo 33 records video with audio ;)
[10:21] <kenvandine> it's only the translation fix...
[10:21] <jibel> rvr, what do you mean?
[10:21] <rvr> jibel: Looks good :P
[10:21] <jibel> rvr, not funny
[10:25] <rvr> kenvandine: $ parecord foobar.wav Error de flujo: Acceso negado (Access denied)
[10:28] <sil2100> jibel: will do
[10:28] <jibel> sil2100, what's left for the translation? approval in LP then export of the language packs?
[10:31] <sil2100> Yeah
[10:34] <sil2100> bzoltan_: hey, the deprecation warning fix - is that only for the non-gles version?
[10:34] <sil2100> Since I didn't saw a -gles upload with it
[10:35] <bzoltan_> sil2100: The gles package would conflict with the silo9  would not it?
[10:36] <sil2100> bzoltan_: I think silo 9 got force-merged
[10:36] <sil2100> bzoltan_: could you in your free time prepare a silo for syncing the -gles version with the latest fix? :)
[10:36] <bzoltan_> sil2100:  hold on a sec  :) The last thing we want is to patch out the freshly landed stuff
[10:37] <bzoltan_> sil2100: So first I would like to check that both landings go or have gone to the trunk
[10:37] <sil2100> ACK :)
[10:41] <sil2100> rvr: can we get someone to approve the pulseaudio translations for es?
[10:41] <sil2100> seb128, kenvandine: and it seems that the de and fr translations are gone again, we'd need to get those in as well...
[10:41] <rvr> sil2100: elopio
[10:42] <sil2100> Mirv: could you help translate here? https://translations.launchpad.net/ubuntu-rtm/15.04/+source/pulseaudio/+pots/pulseaudio/fi/+translate?batch=10&show=all&search=wants+to :) Thanks!
[10:43] <rvr> sil2100: Sending an email to the mailing list, to see if I get an approval before elopio is up
[10:44] <sil2100> rvr: thanks!
[10:44] <sil2100> I can manually hack that in if needed
[10:44] <sil2100> jibel, rvr: let me maybe kick a new image without the updated language packs for now, we can kick another one as soon as those are around
[10:45] <bzoltan_> sil2100:  so, here comes the problem... the warning disabler fix from silo41 does _NOT_ have the emulator fixing opengl fix from sil9.
[10:45] <sil2100> Or, kick it once we have the final fix
[10:45] <sil2100> bzoltan_: what? kenvandine said he rebuilt it
[10:45] <bzoltan_> sil2100: jibel: no bad feeling, but that is the dark side of the cherry picking what people consider as super safe way :)
[10:45] <sil2100> kenvandine: ^ ?
[10:46] <bzoltan_> sil2100: kenvandine: we are talking about two separate OTA6 blockers ... both fix, but not incrementally
[10:46] <kenvandine> yes
[10:46] <sil2100> bzoltan_: yeah, but the emulator fix got force-merged (from what I know) and then kenvandine rebuilt silo 41
[10:46] <kenvandine> i did a rebuild
[10:46] <sil2100> So that 41 had both the emulator fix + the warning one
[10:47] <kenvandine> after the merge of the emulator fix
[10:47] <sil2100> bzoltan_: is that not the case now?
[10:47] <bzoltan_> sil2100: kenvandine: force merged to where? Guys, we base all fixes on the UITK trunk
[10:47] <kenvandine> no...
[10:47] <kenvandine> the silo with the emulator fix was published
[10:47] <kenvandine> but in wily it was held in proposed
[10:47] <kenvandine> so it wouldn't get cleaned
[10:47] <kenvandine> i cleaned it, which would have merged the branch
[10:48] <kenvandine> that made the silo with the warnings fix dirty
[10:48] <kenvandine> i then rebuilt that silo
[10:48] <kenvandine> that silo wouldnt have been dirty if it hadn't merged
[10:48] <sil2100> bzoltan_: ^
[10:49] <bzoltan_> kenvandine:  sil2100:  look, the 1217 integrates the emulator fix to the UITK trunk -> https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk
[10:49] <bzoltan_> kenvandine: sil2100: and the branch in the silo41 was made before that ^ branch was merged to the trunk.
[10:50] <sil2100> bzoltan_: but kenvandine rebuilt the silo after that got merged into trunk!
[10:50] <kenvandine> yes... but silo 41 was rebuilt since the other branch was merged to trunk
[10:50] <kenvandine> so that would have included both
[10:50] <sil2100> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-041/+sourcepub/5325034/+listing-archive-extra <- this is what's in silo 41 PPA, it looks like it has the emulator fix
[10:51] <sil2100> Confusing, but I guess that's what happens when things are happening without coordination with the project landers ;)
[10:51] <sil2100> But I guess we should be okayish
[10:52] <bzoltan_> kenvandine: sil2100: OK, so the release candidate from silo41 does contain both fixes... that is cool. Let me push the -gles package to the silo41 now
[10:52] <kenvandine> indeed, that's how the tools work
[10:53] <sil2100> I guess next time this should be better coordinated with the silo lander :) But kenvandine was working on getting everything in on time
[10:53] <bzoltan_> sil2100: bahhh... I can not. The silo41 was emptied
[10:53] <kenvandine> yeah... sorry nobody else was around
[10:53] <sil2100> bzoltan_: ouch... but wait! ;)
[10:53] <bzoltan_> kenvandine:  I was around :)
[10:53] <kenvandine> didn't want to have to rebuild things today
[10:53] <sil2100> bzoltan_: you can use the overlay!
[10:54] <kenvandine> bzoltan_, we pinged you...
[10:54] <sil2100> bzoltan_: modify the watchfile to point to the overlay PPA, I once did that and it worked ;)
[10:54] <kenvandine> kgunn and i made the call last night to do the rebuild
[10:54] <bzoltan_> kenvandine: not hard enough :)
[10:54] <sil2100> So, instead of landing-041, change it to stable-phone-overlay
[10:54] <kenvandine> yeah, that should be fine
[10:58] <rvr> kenvandine: Do you know why parecord fails to work? It gives an "Stream error"
[10:58] <kenvandine> no idea
[10:59] <kenvandine> i know very little about pulseaudio :)
[10:59] <kenvandine> i was just handling uploads to the silo for mandel
[10:59] <rvr> kenvandine: Ah, thanks
[10:59] <kenvandine> sorry
[10:59] <mandel> what di dI do?
[10:59] <bzoltan_> sil2100:  here is the MR https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/optInDeprecationWarningsTrunk-gles/+merge/269043 where to put it?
[10:59] <rvr> mandel: I have a problem with a pulseaudio test case
[10:59] <rvr> mandel: parecord gives "stream error", do you know why?
[11:00] <rvr> This was working not long time ago
[11:00] <Mirv> sil2100: done, thanks!!
[11:01] <sil2100> bzoltan_: let's make a separate silo for it :)
[11:01] <sil2100> Looking good
[11:01] <sil2100> Mirv: thanks o/
[11:01] <seb128> sil2100, what translation is gone?
[11:01] <seb128> https://translations.launchpad.net/ubuntu-rtm/15.04/+source/pulseaudio/+pots/pulseaudio/fr/167/+translate
[11:01] <bzoltan_> sil2100:  OK, but it will need the main UITK package copied from the overlay
[11:01] <seb128> is still there
[11:01] <seb128> kenvandine, ^
[11:01] <sil2100> Ah, ok, so the de one is gone
[11:01] <mandel> rvr, there was a big update using master by abeato, which arch is this?
[11:02] <seb128> was it ever done?
[11:02] <sil2100> (I thought we had that one)
[11:02] <seb128> I don't think we did
[11:02] <rvr> mandel: I was checking silo 33
[11:03] <mandel> jibel, hello, so we have the following mr => https://code.launchpad.net/~mandel/ubuntu-touch-session/pulse-trust-store/+merge/269044 that is a resubmit from the branch proposed by abeto, he forgot a small param for the trust store
[11:03] <mandel> jibel, do you know if that is in a silo or not?
[11:03] <mandel> rvr, but does it fail in every arch or just powerpc?
[11:04] <mandel> john-mcaleely, we need a small update in the upstart job found here => https://code.launchpad.net/~mandel/ubuntu-touch-session/pulse-trust-store/+merge/269044
[11:04] <rvr> mandel: Oh, armhf, on the phone
[11:04] <mandel> john-mcaleely, but I can show it to you working :)
[11:05] <rvr> mandel: phablet@ubuntu-phablet:~$ parecord foobar.wav
[11:05] <rvr> Stream error: Access denied
[11:06] <mandel> rvr, yes, but I'm asking if it fails in armhf, amd64 etc..
[11:06] <bzoltan_> sil2100:  I can not assign silo to my request
[11:06] <rvr> mandel: armhf
[11:06] <sil2100> Oh! Probably low on silos, on it now
[11:06] <mandel> rvr, ok, that is bad
[11:07] <rvr> mandel: How bad? camera app is able to record video with audio
[11:07] <mandel> rvr, is bad as in we landed a lot of changes from master
[11:08] <sil2100> bzoltan_: I switched it to a dual-silo, since we'd want this to be on both distros
[11:08] <mandel> rvr, we should ask diwic he is the exert
[11:08] <mandel> expert
[11:08] <sil2100> Anyway, assigned silo 47
[11:08] <mandel> rvr, but that test does not fail in 25 which has pulse with the trust store fixes
[11:08] <sil2100> jibel, rvr: ok, kicking the image as mentioned above
[11:08] <rvr> sil2100: Ack
[11:10] <sil2100> Aaah
[11:10] <sil2100> hmmm
[11:12] <bzoltan_> sil2100:  I think I need help with this https://ci-train.ubuntu.com/job/ubuntu-landing-047-1-build/21/console I assume it needs the main orig.tar.gz as start... but maybe there are other problems too
[11:13] <sil2100> bzoltan_: I think there's something else here... will look in a moment, leave it to me
[11:13] <mandel> kenvandine, here you have the correct patch => https://code.launchpad.net/~mandel/ubuntu-touch-session/pulse-trust-store/+merge/269044
[11:15] <bzoltan_> sil2100:  I have added the URL to the orig.tar.gz ... Mirv: I remember you used to do that trick. Is the silo47 OK like that?
[11:16] <bzoltan_> Mirv: I am sure I add the UITK URL in a wrong way https://requests.ci-train.ubuntu.com/#/?req=259
[11:18] <Mirv> bzoltan_: actually I've had no idea what that Manual Download URLs field was for :D
[11:19] <Mirv> MP looks fine for an additional gles only build
[11:19] <bzoltan_> Mirv:  Hmm... somehow I need the main UITK source in the silo
[11:19] <Mirv> bzoltan_: well the watch url should be enough I'd guess
[11:19] <bzoltan_> Mirv:  preferable from the overlay PPA
[11:21] <Mirv> bzoltan_: so what if you just try without anything in the manual download URL, since you have the overlay PPA in the MP's watch file?
[11:23] <sil2100> bzoltan_: Mirv: everything should be fine in the silo config
[11:23] <bzoltan_> sil2100: Mirv: https://ci-train.ubuntu.com/job/ubuntu-landing-047-1-build/23/console
[11:24] <bzoltan_> Silo config is missing these packages: ubuntu-ui-toolkit
[11:24] <sil2100> bzoltan_: check the 'ignore missing twins' flag :)
[11:24] <bzoltan_> Mirv: sil2100: 2015-08-25 11:24:38,610 ERROR ubuntu-ui-toolkit-gles 1.3.1603+15.10.20150819.1-0ubuntu1 is missing from the changelog, which has up to 1.3.1603+15.04.20150824.1-0ubuntu1. Please sync destination version back to trunk.
[11:25] <bzoltan_> sil2100: Mirv ^ and that is BS ... that version is indeed there in the debian/changelog
[11:26] <bzoltan_> Mirv: bzr merge lp:ubuntu-ui-toolkit/gles says "nothing to do"
[11:27] <sil2100> bzoltan_: ah!
[11:27] <sil2100> bzoltan_: I think I see it - your changelog entry mentions 'vivid'
[11:28] <sil2100> The one you added
[11:28] <sil2100> I think it should be UNRELEASED
[11:28] <sil2100> Right?
[11:28] <sil2100> bzoltan_: in your MP of course
[11:30] <bzoltan_> sil2100:  just made it ... still the same error
[11:32] <Mirv> hmm
[11:33] <bzoltan_> Mirv: sil2100: I guess I have fixed it ...
[11:34] <bzoltan_> What a sensitive dramaqueen is this citrain :D
[11:36] <Mirv> \o/
[11:38] <kenvandine> sil2100, question... i see ubuntu-touch-session (0.108+15.04.20150814.1-0ubuntu1) has landed in the overlay ppa for vivid
[11:38] <kenvandine> but there doesn't seem to be a bzr branch merged for it
[11:39] <kenvandine> sil2100, that pulseaudio blocker fix in silo 25 also requires a fix in ubuntu-touch-session
[11:39] <Mirv> bzoltan_: now it's searching for a tarball with "15.10" in it, while the one in overlay has 15.04
[11:39] <kenvandine> sil2100, mandel proposed a branch fixing it that includes all of the fix that has already landed in the overlay plus the additional fix
[11:39] <bzoltan_> Mirv:  early happines ... https://ci-train.ubuntu.com/job/ubuntu-landing-047-1-build/26/console the watch might not be ok
[11:40] <bzoltan_> Mirv:  yes, but with 15.04 it was bitching about the version... nice catch22
[11:40] <kenvandine> sil2100, i need to reject that one, but what should we do to get the additional fix in?  a manual dput instead of MR?
[11:43] <rvr> sil2100: The Spanish translation for PulseAudio has been approved
[11:43] <sil2100> kenvandine: hmm
[11:43] <bzoltan_> Mirv: sil2100: guys.. I am out of idea
[11:44] <sil2100> kenvandine: give me 10 minutes, need to finish something up
[11:44] <kenvandine> sil2100, sure, i can't find mandel anyway :)
[11:44] <bzoltan_> Mirv: sil2100: I would simple copy both wily and vivid main source packages to that silo47 and use that
[11:45] <Mirv> bzoltan_: let's just upload it manually and sync to gles trunk manually
[11:45] <Mirv> this is a dual landing corner case dilemma
[11:48] <bzoltan_> Mirv: That is a good idea too... But I can not do that, as I have do not have dput rights to the overlay PPA. Would you be so kind to dput that branch?
[11:49] <Mirv> bzoltan_: I'm doing it atm
[11:49] <Mirv> bzoltan_: the lesson to learn here is: do not forget the dual package or you get trouble :)
[11:50] <bzoltan_> Mirv:  Thank you :) and yes...
[11:58] <Mirv> bzoltan_: ok mess starts to be sorted. I had to split into two silos since dual landings are not possible for manual uploads. the MP will need to be merged manually to trunk.
[12:13]  * sil2100 sighs
[12:16] <sil2100> mandel: hey! So regarding the ubuntu-touch-session in silo 25
[12:17] <sil2100> mandel: there are a few options of proceeding here...
[12:19] <jibel> sil2100, mandel I don't understand the ubuntu-touch-session part of the silo. How is it related to the application name fix?
[12:21] <jibel> and the 2 jobs are already on the image
[12:22] <sil2100> Indeed, didn't we need some other changes?
[12:23] <sil2100> mandel: anyway, I would propose a manual dput of the ubuntu-touch-session for now
[12:23] <jibel> sil2100, they look identical, let me check
[12:23] <sil2100> jibel: yeah, the branch that mandel proposed seems to be only a sync of what's in overlay to the trunk
[12:24] <sil2100> Since trunk, for some unknown reasons, doesn't have those changes
[12:24] <sil2100> But I thought there should be some other changes on top of it
[12:25] <sil2100> kenvandine: hey! :)
[12:25] <sil2100> kenvandine: so, I would propose two solutions here:
[12:25] <kenvandine> sil2100, sorry... any ideas?
[12:25] <sil2100> kenvandine: first, the 'easy way' - just prepare the package manually and dput, screw it, as someone already manually prepared the previous version...
[12:25] <kenvandine> sil2100, also... i have to run to a meeting, could you help mandel get something in either silo 25 for it or a new silo?
[12:26] <mandel> sil2100, so, what do you need from me?
[12:26] <kenvandine> that's the easy
[12:26] <kenvandine> way
[12:26] <sil2100> kenvandine: second: prepare a temporary vivid trunk, sync the change there and include the new changes
[12:26] <mandel> sil2100, where did abeato code land? or do we do a simple patch
[12:26] <jibel> sil2100, there is one difference  in pulseaudio-trust-stored.conf it adds --disable-whitelisting=yes to the exec
[12:26] <kenvandine> yeah, one line change
[12:26] <sil2100> ugh, it wasn't mentioned in the changelog or the commit message
[12:27] <mandel> jibel, sil2100 that line change is a must
[12:27] <sil2100> mandel: ok, so your merge has all required changes, yes?
[12:27] <sil2100> Ok, leave it to me then, let me prepare something
[12:27] <mandel> sil2100, and is not in the commit because the MR was not yet merged or approved as per lp
[12:27] <sil2100> Give me 10 minutes
[12:27] <kenvandine> sil2100, it does, but it also have stuff that landed already
[12:27] <mandel> sil2100, awesome,, that means that we unblock ota with this
[12:27] <mandel> sil2100, +silo 25
[12:27] <kenvandine> sil2100, with that line in ubuntu-touch-session, pulseaudio in silo 25 works :)
[12:28] <jibel> mandel, yeah the changelog is confusing because it says 'add upstart jobs...' but they are already there
[12:28] <kenvandine> jibel, yeah we need a new fix, but we don't  seem to have a branch to base that off of
[12:28] <kenvandine> i'm thinking manual dput
[12:29] <mandel> jibel, correct, but I though by looking at abeatos branch that it did not land
[12:29] <kenvandine> something landed with all of his stuff in that branch on 0817
[12:29] <kenvandine> anyway... we just need that one line change
[12:30] <kenvandine> so i'd say a manual upload
[12:30] <kenvandine> sil2100, seb128 will do the manual dput
[12:30] <kenvandine> mandel, jibel: ^^
[12:30] <sil2100> Wait
[12:31] <kenvandine> ok... you guys work it out
[12:31] <sil2100> I said, give me 10 minutes
[12:31] <sil2100> :)
[12:31] <kenvandine> i have to go to a meeting
[12:31] <kenvandine> sil2100, i was trying to get you off the hook :)
[12:31] <mandel> sil2100, that was 10 mins in a sprint
[12:31] <mandel> :P
[12:31] <kenvandine> seb128 showed up
[12:34] <mandel> seb128, http://paste.ubuntu.com/12192195/
[12:35] <seb128> mandel, thanks
[12:36] <sil2100> mandel: hey https://code.launchpad.net/~phablet-team/ubuntu-touch-session/stable-overlay <- could you target your latest changes (the one with whitelisting) to this branch?
[12:36] <mandel> sil2100, sure
[12:36] <seb128> sil2100, Ken said to check with you before uploading the ubuntu-touch-session change to the silo?
[12:37] <seb128> you want to do it through ci landing with the mp you just asked?
[12:38] <mandel> sil2100, new MR? same MR diff target?
[12:40] <sil2100> mandel: maybe create a different MR, a different branch based on this as 'trunk' with your whitelisting changes
[12:40] <mandel> sil2100, ack
[12:41] <sil2100> seb128: yeah, I want to use the train for it, as that's a typical train-released-package
[12:47] <mandel> sil2100, https://code.launchpad.net/~mandel/ubuntu-touch-session/stable-overlay-whitelist-apps/+merge/269055
[12:47] <mandel> sil2100, is that what you needed?
[12:48] <sil2100> mandel: yes! Let's add that to the MR list
[12:48] <mandel> sil2100, ok, and what do we do with silo 25? do we care about that?
[12:49] <mandel> sil2100, is of course needed
[12:49] <sil2100> Reconfiguring silo 25
[12:50] <sil2100> mandel: building ubuntu-touch-session in silo 25 :)
[12:50] <sil2100> Should be ok now
[12:51] <mandel> sil2100, sweet, that means that jibel can test everything using silo 25
[12:51] <sil2100> Yes :) Let's hope it builds correctly, but it should be ok
[12:51] <mandel> jibel, that silo contains the fix to ensure that if the camera app request the usage of the mic you get a prompted by the trust store and the app DOES appear in system settings as the camera app
[12:52] <jibel> mandel, understood, thanks
[12:53] <mandel> jibel, AFAIK that is the only blocker bug we had, correct?
[12:53] <jibel> mandel, yes, it is the last one
[12:54] <mandel> jibel, sweet, I'll try to get this patches landed in the git repo then and then will move to the next one
[12:58]  * sil2100 goes to finish his lunch
[13:00] <sil2100> cjwatson: hey! In the meantime, could I request a full translation export of ubuntu-rtm/15.04? :)
[13:03] <cjwatson> sil2100: This morning's wasn't enough?
[13:03] <cjwatson> I guess there's been a bunch of work on translations recently
[13:03] <sil2100> cjwatson: no... not all translations got in in time, and the pulseaudio template somehow got reverted to an old one
[13:04] <cjwatson> sil2100: I've asked webops for that.
[13:04] <sil2100> So we had to re-upload
[13:04] <sil2100> Thank you!
[13:18] <mzanetti> cihelp, looks like the VM for our qmltests is stale. We believe a dist-upgrade should get it done. Can someone with permission please check? Here's a log: https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/896/console
[13:35] <cjwatson> sil2100: Done
[13:35] <sil2100> \o/
[13:35] <sil2100> Thanks :)
[13:39] <mandel> sil2100, I tested silo 25 on my side, works like a charm, but if you guys have an issue let me know, I'm going to be fixing some location things in wily
[13:40] <sil2100> Ok, switching it to 'Ready for QA' then
[13:40] <jibel> mandel, sil2100 rvr is on it
[13:40] <sil2100> jibel, rvr, davmor2: ^ silo 25 ready for sign-off it seems!
[13:41] <mandel> sil2100, jibel  great, moving fwd, we need to clean the situation with pulse and the ci train, we cannot keep it like it is atm
[13:42] <mandel> sil2100, jibel I've sent the patches to be added to the git repo that has the packaging in debian for ubuntu
[13:44] <rvr> mandel: Any special tests for silo 25?
[13:44] <josepht> mzanetti: I've run dist-upgrade on that vm
[13:45] <mzanetti> josepht, thanks, will rerun the job
[13:45] <mandel> rvr, yes, one, let me write some notes for you
[13:49] <mandel> rvr, http://paste.ubuntu.com/12192653/
[13:49] <mandel> rvr, let me know if I'm not clear in any of the steps
[13:55] <rvr> mandel: That test case is ok
[13:55] <rvr> mandel: Checking now the test plan
[13:56] <mandel> rvr, superb, that is the one I was aiming to solve :)
[14:12] <rvr> mandel: jibel: Silo 25 is ok
[14:12] <rvr> mandel: There should be some visual feedback when the video is recording without audio
[14:13] <kenvandine> woot, silo 25 passed!
[14:13] <kenvandine> sil2100, are you publishing?
[14:27] <kenvandine> sil2100, i'll publish
[14:30] <kenvandine> silo 25 published!
[14:30]  * kenvandine does a dance
[14:30] <kenvandine> john-mcaleely, published the pulseaudio fix to vivid overlay
[14:30] <kenvandine> jibel, ^^
[14:54] <john-mcaleely> kenvandine, thank you!
[15:28] <sil2100> jibel: still need a few moments for the langpacks, need to check if all seems ok
[15:39] <sil2100> jibel, rvr: do you want to verify one of the langpacks before I upload them to the overlay?
[15:39] <sil2100> Or should I "just do it" (tm) ?
[15:41] <sil2100> I'll check pl on my phone as well
[15:41] <rvr> sil2100: I can check if you want
[15:42] <rvr> sil2100: How can I install them?
[15:43] <sil2100> rvr: let's do it like this - I'll upload es and pl to the overlay, let them build, we test them - if all is ok I copy the rest and then to the snapshot PPA
[15:44] <rvr> sil2100: Oki doki
[15:45] <sil2100> ...I'll copy all of them to save time, as time is of the essence, since we can always fix them in the overlay no problem - uploading now, we should have them soon
[15:52] <AlbertA> trainguards: any idea why this is failing? https://ci-train.ubuntu.com/job/ubuntu-landing-053-1-build/18/console
[15:55] <AlbertA> trainguard: I guess it's this? "mktemp: failed to create directory via template '/tmp/debsign.XXXXXXXX': No space left on device
[15:55] <AlbertA> debsign: Can't create temporary directory
[15:55] <AlbertA> Aborting..."
[15:56] <ogra_> looks pretty clear to me why it is failing :)
[15:57] <sil2100> uh
[15:57]  * ogra_ guesses someone needs to free diskspace on the machine 
[15:59] <sil2100> AlbertA: try re-running, but it's strange as the jenkins instance has a lot of space... maybe it's related to the cowbuilder?
[15:59] <AlbertA> sil2100: ack. I'll try again
[16:17] <rvr> sil2100: Overlay ppa ready with langpacks?
[16:30] <sil2100> rvr: yep :)
[16:30] <sil2100> Looks good on my phone
[16:32] <sil2100> rvr: does it look alrightish on your side? Waiting for an ACK and kicking the image
[16:32] <rvr> sil2100: Sorry, just installed the image
[16:33] <rvr> sil2100: Which address has the overlay PPA?
[16:33] <sil2100> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay <-
[16:33] <sil2100> ppa:ci-train-ppa-service/stable-phone-overlay
[16:38] <rvr> sil2100: apt-get upgrade does nothing... versioning hasn't changed?
[16:39] <sil2100> rvr: it changed - add ppa:ci-train-ppa-service/stable-phone-overlay, apt-get update and apt-get install language-pack-touch-es
[16:40] <sil2100> rvr: ah, remember that you need  to add the overlay, as currently the images are based off the snapshot
[16:40] <rvr> sil2100: Already installing it manually
[16:40] <rvr> sil2100: I added the overlay PPA, but nothing happened with update + upgrade
[16:41] <kenvandine> rvr, you need to add the pin too
[16:41] <kenvandine> or i'd suggest it
[16:41] <kenvandine> http://paste.ubuntu.com/12193672/
[16:41] <kenvandine> add that to a file in /etc/apt/preferences.d/
[16:41] <rvr> kenvandine: Aha, the pin
[16:42] <rvr> I used to do that for silos, but citrain takes care now
[16:42] <kenvandine> rvr, i'm heading out in a few to meet your brother for dinner :)
[16:42] <kenvandine> yeah
[16:42] <rvr> kenvandine: A little bird already told me :D
[16:43] <rvr> kenvandine: Have fun :))
[16:43] <kenvandine> we wil
[16:43] <kenvandine> +l
[16:43] <rvr> kenvandine: Take care, he has been assimilated by Red Hat!
[16:44] <kenvandine> yeah, we are going to get him a kids menu at the restaurant
[16:44] <kenvandine> can't hang with the big boys :)
[16:44] <rvr> lol
[16:45] <rvr> sil2100: The two trust prompts in Camera app are translated to Spanish, wee!
[16:49] <sil2100> rvr: ok, so good to copy?
[16:50] <rvr> sil2100: Yes, looks good
[16:50] <rvr> Another webbrowser-app menu item is also translated
[17:05] <pmcgowan> ogra_, what happened to imgbot?
[17:06] <pmcgowan> john-mcaleely, says ogra_ stunt
[17:06] <john-mcaleely> :-)
[17:07] <ogra_> pmcgowan, well, i rebooted my desktop and forgot to re-enable it ... it doesnt do much helpful anymore though since the channel re-org
[17:08] <pmcgowan> ah too bad
[17:15] <john-mcaleely> shame
[17:15] <john-mcaleely> oh well
[17:16] <ogra_> well, i can re-enable it again
[17:16] <ogra_> but the image numbers dont really point to anything useful anymore
[17:16] <ogra_> since they were all re-set when the channel re-org happened
[17:16] <ogra_> (so they are duplicated)
[17:17] <john-mcaleely> yeah, ho hum
[17:17] <john-mcaleely> time to move on then :-)
[17:17] <ogra_> it would need some serious re-write ... i started on that once but that was shortly before i moved to snappy
[17:17] <ogra_> if i find time on a weekend i'll finish that
[17:18] <john-mcaleely> fair enough. no urgency on my part
[17:18] <john-mcaleely> thanks!
[17:44] <sil2100> jibel, rvr: the rootfs still building, but I suppose it should be done soonish
[17:45] <sil2100> So maybe the final ETA is ~30 mins?
[17:46]  * sil2100 goes AFK now for a short while
[17:47] <ogra_> sil2100, today and nearby being completely empty with the latest image after boot is known ?
[17:47] <sil2100> ogra_: didn't hear anything about that
[17:47]  * ogra_ saw it on both devices here (krillin and arale ... ) after about 20 refresh cycles (each time waiting til the bouncy bar is gone) it worked again 
[17:47] <sil2100> It seemed to be ok on my rc-proposed krillin
[17:48] <sil2100> Works fine here
[17:48] <ogra_> well, then its prehaps only me
[17:48] <ogra_> was pretty odd though
[17:51] <AlbertA> trainguards: can you publish landing-053? thanks
[17:51] <robru> one sec
[17:52] <robru> AlbertA: need this guy top approved: https://code.launchpad.net/~mir-team/mir/0.15/+merge/269082
[17:52] <AlbertA> robru: aargh..sorry done...
[17:54] <robru> AlbertA: alright done
[17:54] <AlbertA> robru: thanks!
[17:54] <robru> AlbertA: you're welcome
[17:54] <robru> AlbertA: oh we are in beta freeze by the way so that might sit in proposed for a while.
[17:55] <AlbertA> robru: darn...ok
[18:52] <alesage> sil2100, I'll do a sanity flyby on arale when the image arrives FYI
[19:35] <sil2100> alesage: ACK! It should be around already
[19:35] <alesage> sil2100, in process thx
[19:35] <sil2100> Thanks :)
[19:35] <sil2100> o/
[21:16] <nuclearbob> cihelp: can somebody remind me where the silo status page is?
[21:16] <ev> nuclearbob: you want trainguards
[21:16] <nuclearbob> ev: thanks
[21:17] <nuclearbob> trainguards: can somebody remind me where the silo status page is?
[21:18] <robru> nuclearbob: you mean the dashboard? URL's in the channel topic, also: https://requests.ci-train.ubuntu.com/static/dashboard.html
[21:19] <nuclearbob> robru: thanks, I should have scrolled the topic to see more of it
[21:19] <robru> nuclearbob: you're welcome