[00:32] <sergiusens> rsalveti, cyphermox, you around, need someone to publish https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=28
[00:32]  * rsalveti checks
[00:33] <rsalveti> looks fine, didn't test, but you tested it :-)
[00:33] <sergiusens> rsalveti, I did as ogra_
[00:33] <rsalveti> great
[00:34] <rsalveti> sergiusens: done
[00:34] <sergiusens> ty
[03:05] <imgbot> [04:25] <imgbot> [04:25] <imgbot> [04:26] <robru> rsalveti, gave you silo 12
[04:26] <rsalveti> robru: thanks
[04:27] <robru> rsalveti, you're welcome
[04:28] <veebers> robru: hey would you have a moment to help me with a silo reconfig?
[04:28] <robru> veebers, absolutely!
[04:28] <veebers> robru: awesome thanks :-) I have update the MPs on line 21
[04:29] <veebers> (as well as updating the description as requested)
[04:29] <robru> veebers, is it all just autopilot? any new projects there?
[04:29] <veebers> robru: no, just autopilot
[04:30] <robru> veebers, ok, you should be able to take care of that yourself. have you been trained on the reconfig job?
[04:30] <veebers> robru: ah right. No I haven't been trained to use it
[04:30] <robru> veebers, ok i'll give you a crash course
[04:30] <veebers> robru: do you mind stepping me through it now?
[04:30] <veebers> awesome cheers
[04:31] <robru> veebers, so in the spreadsheet, you'll see you're in silo 3. if you go to the 'landing-003' tab at the bottom of the spreadsheet, there'll be a bunch of big yellow buttons
[04:31] <veebers> robru: right, I'll go to reconfigure
[04:32] <robru> veebers, just remember you have to copy & paste the merge URLs into the reconfig job
[04:32] <veebers> robru: ah I see. I need to put the MRs there
[04:32] <robru> veebers, yeah
[04:32] <veebers> robru: do I need anything in the sources param?
[04:32] <robru> veebers, so that should work as long as you're not adding a new project that wasn't assigned to the silo before. if you need to add a new project, then it requires my help
[04:33] <robru> veebers, not in this case. sources is only for things that aren't hosted on lp where you might want to do a manual upload (such as xorg or android)
[04:33] <veebers> robru: right makes sense.
[04:33] <veebers> robru: thanks for that, I have used the train before, just not the reconfig. I guess I could have figured it out myself, but didn't want to break anything :-)
[04:34] <robru> veebers, just let me know if you have permission to do the config job. I don't have access to change the ACL so if it doesn't work for you, we need to ping didrocks and I'll just take care of the reconfig for right now
[04:34] <veebers> ugh, why doesn't it ask me for permissions _before_ I can see the jenkins job page :-\
[04:35] <veebers> robru: seems I have perms ok (I'm just watching the console output now)
[04:35] <robru> veebers, yeah, that bites me all the time. sorry :-/
[04:35] <veebers> heh no worries :-)
[04:36] <veebers> robru: as soon as that config job is done I'm good to go and build etc. right?
[04:37] <robru> veebers, yep. it might take a second to update the status in the spreadsheet, but that doesn't even matter. as long as the jenkins job says it's done, you can start the build job right after that (the script that updates the statuses in the spreadsheet has some lag, don't wait around for the spreadsheet if you care about efficiency)
[04:38] <veebers> robru: awesome, thanks again for the help
[04:38] <robru> veebers, you're welcome!
[05:00] <Mirv> morning
[05:10] <robru> Mirv, ah, you're here! goodnight ;-)
[05:11] <Mirv> :)
[07:00] <didrocks> Mirv: hey, FYI, don't assign any silo right now, I'm pushing the ID transition
[07:01] <Mirv> ok
[07:03] <didrocks> backend done, moving frontend
[07:22] <tvoss|afk> good morning
[07:40] <didrocks> frontend and sync available
[07:55] <Mirv> didrocks: so, I could try assigning a silo now?
[07:58] <didrocks> Mirv: I'm trying to assign some and see if there are any bugs before giving you the green light :)
[07:59] <Mirv> ok :)
[08:00] <sil2100> Are we migrated to the new way of silo assigment? ;)
[08:02] <Mirv> sil2100: tests ongoing
[08:02] <sil2100> \o/
[08:24] <didrocks> grrr, as there was a bug spawning with writes, it doesn't want to execute any other script now :(
[08:29] <Saviq> didrocks, hey, wecanhassilo for row 56 please?
[08:31] <Mirv> Saviq: not before didrocks gets less grrr
[08:32] <didrocks> Saviq: let me attribute it to you, this part is working
[08:32] <didrocks> Saviq: however, you won't get status feedback for now
[08:32] <Saviq> uh oh
[08:32] <Saviq> didrocks, thanks, will manage
[08:35] <didrocks> Saviq: landing-013
[08:36] <Saviq> didrocks, thanks
[08:39] <didrocks> frustrating, I introduced the bug when adding debugging :/
[08:49]  * ToyKeeper hugs chrome's "tabs outliner" add-on...  makes it so much easier to keep track of bugs which need re-testing!
[08:50] <didrocks> Saviq: status refresh are back!
[08:51]  * didrocks just need to fix one bug (so 2 bugs for 500 lines rewrites, not bad)
[08:52] <didrocks> auto assignement/removal works
[08:53] <sil2100> \o/
[08:55] <sil2100> So, when can we give it a spin too :D ?
[08:56] <Saviq> sil2100, icanhassilo for row 57?
[09:01] <sil2100> didrocks: can I try it out? ^
[09:07] <tvoss> sil2100, I did an exploratory testing with silo 14, looks good
[09:07] <sil2100> tvoss: I'm rebooting my phone now with those changes
[09:07] <tvoss> sil2100, great :)
[09:07] <tvoss> sil2100, once you are happy, I will set to testing -> yes
[09:11] <didrocks> sil2100: sure, you can :)
[09:12]  * sil2100 assigns!
[09:13] <sil2100> Woooo
[09:14] <didrocks> working all fine? :)
[09:16] <sil2100> Yes! Almost thought that something's wrong with assigning the silo in the spreadsheet, but it finally updated \o/ It's awesome!
[09:16] <sil2100> Saviq: assigned, silo 10
[09:17] <didrocks> sil2100: well, there is the 2 minutes delay at most to get infos from the backend
[09:17] <Saviq> sil2100, cools, what's new?
[09:18] <didrocks> Saviq: basically, no need to copy and paste all MPs ans sources, only a request id (and no need to reassign manually on the frontend the selected silo by the backend)
[09:18] <Saviq> didrocks, does that affect us (when reconfiguring), too?
[09:18] <didrocks> Saviq: it's quite a big change in the whole spreadsheet logic for this
[09:18] <Saviq> yup
[09:18] <didrocks> Saviq: for now, you will need to get the request id
[09:18] <didrocks> I'll change that after the landing meeting
[09:18] <didrocks> so that it's automagic
[09:19] <Saviq> okies cool
[09:19] <didrocks> so basically, you will just have to press "build"
[09:19] <didrocks> Saviq: FYI, siloMatrix is dead
[09:19] <didrocks> the whole assignement is in the pending spreadsheet
[09:20]  * didrocks removed ~120 functions calls with this
[09:20] <Saviq> :)
[09:20] <didrocks> sil2100: Mirv (if you ask yourself why the siloMatrix isn't there anymore) ^
[09:21] <Mirv> ok :)
[09:21] <sil2100> :D
[09:23] <didrocks> Saviq: seb128: if you need a reconfigure for now, just ping us to give you your requestID
[09:23] <didrocks> should be changes in < 1h hopefully
[09:23] <didrocks> changed*
[09:23] <seb128> didrocks, ok, thanks
[09:23] <didrocks> sil2100: Mirv: to get an existing ID, just select the line and choose in the menu "assign silo"
[09:23] <didrocks> it will give you an existing ID if it's already assigned
[09:24] <didrocks> generate a new one otherwise
[09:26] <sil2100> Ok, awesome
[09:29] <sil2100> tvoss: looking good seemingly, let's publish
[09:30] <tvoss> sil2100, ack
[09:30] <tvoss> sil2100, did you hit merge&clean, yet?
[09:32] <sil2100> tvoss: no no, I need to get a +1 on the packaging diff
[09:32] <sil2100> And then we need to wait for it to land in the archive
[09:32] <sil2100> didrocks: looks good, needing ACK -> http://162.213.34.102/job/landing-014-2-publish/lastSuccessfulBuild/artifact/packaging_changes_process-cpp_1.0.0+14.04.20140326.2-0ubuntu1.diff
[09:34] <tvoss> sil2100, okay, so you keep me posted, when I can hit the button?
[09:34] <sil2100> Sure
[09:39] <Mirv> didrocks: when you have time, I tried and apparently succeeded in getting a silo landing-016 for qtlocation http://162.213.34.102/job/prepare-silo/701/console but it's not showing in the spreadsheet
[09:42] <sil2100> Mirv: it might show up in a moment, how long did you wait already?
[09:43] <Mirv> sil2100: 15 min so far
[09:43] <Mirv> and yes so I looked from the discussion that it might take some time
[09:43] <Mirv> it's a special case with no MP:s and only manual upload package, so it might trigger something differently
[09:46] <sil2100> Mirv: it might be a bug then!
[09:49] <vila> didrocks: ff/gtalk/sound combo mess, did you see my msg about 263 being green ?
[09:49] <didrocks> vila: yeah, all fine, don't worry, thanks! :)
[09:49] <didrocks> and good luck for your issue
[09:49] <vila> didrocks: ack, thanks ;)
[09:52]  * vila grabs the shotgun
[09:57] <popey> where do we file bugs against individual scopes?
[09:57] <popey> (the new ones)
[09:59] <Saviq> sil2100, silo 13 can be published
[10:03] <sil2100> Publishing
[10:04] <sil2100> didrocks: do you have a moment for that packaging ACK ? :) (soname bump http://162.213.34.102/job/landing-014-2-publish/lastSuccessfulBuild/artifact/packaging_changes_process-cpp_1.0.0+14.04.20140326.2-0ubuntu1.diff)
[10:04] <didrocks> sil2100: oh right, I was looking at that, yeah, +1
[10:04] <didrocks> (and then forgot)
[10:04] <sil2100> didrocks: thank you!
[10:04] <didrocks> sil2100: all the rdepends are going are rebuilt?
[10:05] <didrocks> s/are going /
[10:05] <didrocks> to pick up the new soname?
[10:09] <didrocks> sil2100: ^
[10:09] <didrocks> tvoss: ^
[10:10] <tvoss> didrocks, it's only rdepends not reverse build depends
[10:11] <didrocks> $ reverse-depends libprocess-cpp0
[10:11] <didrocks> Reverse-Depends
[10:11] <didrocks> [10:11] <didrocks> * libdbus-cpp2
[10:11] <didrocks> * libprocess-cpp-dev
[10:11] <didrocks> * libunity-mir1 [amd64 armhf i386]
[10:11] <didrocks> * libunity-scopes0
[10:11] <didrocks> tvoss: so, you did rebuild dbus-cpp, unity-mir and unity-scopes?
[10:11] <didrocks> (I didn't watch the whole thing)
[10:11] <sil2100> didrocks: yes
[10:11] <didrocks> excellent :)
[10:12] <sil2100> didrocks: they were in the silo ;) That was the thing I noticed yesterday and we rebuilt it
[10:15] <didrocks> good work guys :)
[10:47] <didrocks> sil2100: Mirv: Saviq: seb128: ok, now the self-reconfigure doesn't take any parameter anymore, just click "build", enjoy :)
[10:47] <Saviq> didrocks, \o/
[10:52] <sil2100> Ouuu yeeea
[11:03] <dbarth> sil2100: hi, i have a policy question: one of our dependencies can't build on powerpc/arm64/etc. so webbrwoser-app will timeout building on those (dep-wait i guess)
[11:03] <Chipaca> i've got a question about the trunk branch wrt ci train landing: does it have to be 'trunk'? does it have to be the focus of development on launchpad? something else?
[11:03] <dbarth> so should we disable builds on the archs that won't work in the main package?
[11:04] <sil2100> dbarth: so, was that dependency available on ppc arm64 before?
[11:04] <cjwatson> dbarth: tell me about the specifics and I'll investigate
[11:04] <dbarth> v8 has no assembler for those, and v8 is in blink, which itself is in oxide
[11:04] <dbarth> so oxide won't build on those arches
[11:04] <cjwatson> webbrowser-app was built on arm64/powerpc/ppc64el before
[11:04] <sil2100> dbarth: oh, and that will make webbrowser-app unavailable for ppc again?
[11:05] <cjwatson> dbarth: fwiw if you actually need this overridden you need an archive admin, sil2100 isn't empowered to override it I'm afraid
[11:05] <dbarth> cjwatson: but is now moving to oxide as a /build-dep/ though
[11:05] <sil2100> dbarth: ok, so I guess cjwatson might help you here, he might be the best person to take a decision if we can remove it from the archive for those archs or not
[11:05] <cjwatson> jdstrand: did anyone consider the v8 portability story with oxide?
[11:05] <dbarth> cjwatson: ah ok
[11:05]  * sil2100 sadly has no power at all
[11:05] <sil2100> ;)
[11:05] <dbarth> cjwatson: was discussed yesterday or so, i think doko asked
[11:06] <cjwatson> and what was the answer?
[11:06] <dbarth> in the MIR for oxide (can't remember, i will just lookup the bug ;)
[11:06] <dbarth> https://bugs.launchpad.net/bugs/1293681
[11:06] <cjwatson> anyway, webbrowser-app has no rdeps on those architectures, so I can remove the binaries
[11:06] <davmor2> Morning all
[11:06] <cjwatson> dbarth: is there a landing PPA I can look at for more details though?
[11:06] <dbarth> see comment #4
[11:07] <cjwatson> I see.  It looks like a sad inevitability for now
[11:07] <dbarth> cjwatson: in summary, google may do it on v8 for certain arches, but not all of them
[11:07] <dbarth> right
[11:08] <cjwatson> Please try to avoid adding lots more dependencies on this to other existing packages though
[11:08] <cjwatson> The next case might not be easy to untangle
[11:08] <dbarth> we'd need to rely on qtwebkit for those then
[11:08] <dbarth> but that's just what we were trying to avoid to simplify the maintenance
[11:08] <cjwatson> I get that you might need it occasionally
[11:08] <cjwatson> I just don't want it leaking out all over the whole stack
[11:09] <cjwatson> I assume most of this is contained to the webapps/webbrowser elements
[11:09] <dbarth> yes
[11:09] <dbarth> but the dependncy chain may not be as simple
[11:09] <didrocks> we need to ensure that unity7 isn't going to dep on webapps then
[11:09] <dbarth> i can check how far it goes
[11:09] <didrocks> (which would be wrong)
[11:09] <cjwatson> didrocks: that'd want to be no stronger than recommends anyway, right?
[11:10] <didrocks> cjwatson: correct, but the first implementation 3 cycles ago was not optional, I think we need to check that's not coming back in another way
[11:11] <dbarth> cjwatson: the landing ppa is https://launchpad.net/~ci-train-ppa-service/+archive/landing-009/ if you need it
[11:11] <cjwatson> unity-webapps-service only depends on webapp-container on amd64 i386 armhf right now
[11:11] <cjwatson> so if we can carry on with that kind of bodge then we should be fine
[11:12] <dbarth> unity-webapps-service already limits the supported architectures you mean?
[11:12] <cjwatson> yes
[11:12] <dbarth> (looking up the branch)
[11:12] <dbarth> ah ok
[11:12] <cjwatson> in its dependency on webapp-container
[11:12] <cjwatson> dbarth: ok, is this otherwise ready to land?  I can remove the problematic binaries, but I don't want to do so until you're actually ready to land this because otherwise there's a risk I'll have to do the work twice
[11:12] <dbarth> we're not ready yet, nope
[11:13] <dbarth> the silo was for checking all bits work together
[11:13] <dbarth> and we caught this one
[11:13] <cjwatson> dbarth: give me a shout when you are, then
[11:13] <cjwatson> and otherwise consider this will-be-fixed
[11:13] <dbarth> but to make sure: should we modify the packaging of webbrowser-app?
[11:13] <cjwatson> I don't see why
[11:13] <dbarth> ok, so we just let some builds fail, and the landing is a manual step
[11:14] <cjwatson> they aren't even really failing, they're dep-waiting
[11:14] <dbarth> right
[11:14] <cjwatson> which is fine as long as it is made not to be a regression from trusty (which will happen by way of me removing the binaries)
[11:14] <dbarth> ok thanks Colin
[11:14] <dbarth> ah
[11:14] <cjwatson> in fact that's actually better than a hardcoded architecture list
[11:15] <dbarth> ok
[11:15] <cjwatson> they suck, they take ages to unwind when we port things
[11:16] <Chipaca> ahem. Sorry for the bad timing in asking my question, above :)
[11:16] <Chipaca> i'll repeat:
[11:16] <Chipaca> i've got a question about the trunk branch wrt ci train landing: does it have to be 'trunk'? does it have to be the focus of development on launchpad? something else?
[11:17] <didrocks> Chipaca: hey, that's what we do advise strongly during the bootcamp, yeah
[11:18] <didrocks> Chipaca: you have UDS session on CI Train about the reasoning, but mostly, it's about focus, being able to pick any MP and get it in
[11:18] <Chipaca> didrocks: thing is, i'd like to have a different branch where dev branches land, so the server work isn't blocked on the ci train
[11:18] <didrocks> Chipaca: for upstreams with a lot of branches, they are keeping up with it (even if the Airline is supposed to fix where you can end up with multiple MP conflicts)
[11:18] <Chipaca> and then have the ci train merge that
[11:19] <didrocks> Chipaca: your client and server are in the same branch?
[11:19] <Chipaca> didrocks: the server depends on the client (because the client has the protocol, and acceptance tests, and the basic server, yes)
[11:19] <didrocks> agreed, that for thing one, until we have the airline, it's more tricky
[11:19] <Chipaca> that is: the production server is a specialization of the demo/test server that's in with the client
[11:19] <didrocks> just to be clear, what we do want is:
[11:20] <didrocks> - in case of regression/failure, upstream being reactive to fix it (and not "I don't care because I continue to push to my own trunk")
[11:20] <didrocks> - a fix should be easy to pick from the devel branch without to have pulling the whole trunk
[11:20] <didrocks> s/pulling/to pull/
[11:21] <didrocks> (and if I mentionned both, it's because both happened and happens)
[11:24] <Chipaca> didrocks: as I see it, if the only difference between the pre-trunk branch and trunk is the manual process involved in landing things on trunk, both of those are just as satisfied as without it, and it unblocks people from waiting on the train
[11:25] <didrocks> Chipaca: depends on people I guess, but if you commit to not land into that, for your case, I think this can make sense
[11:27] <Chipaca> didrocks: ok. And I understand how this could fail if we don't truly commit to the above, but if you're willing to give it a try I'll set it up
[11:27] <didrocks> Chipaca: sure, you can do that :)
[11:27] <Chipaca> didrocks: thanks
[11:27] <didrocks> yw, thanks for the head's up :)
[11:28] <Chipaca> didrocks: can you think of a name that communicates "this is where dev branches land before manual testing and ci train merging"?
[11:29] <Chipaca> otherwise it'll be some variation of "staging" or "canary" :)
[11:29] <Chipaca> or maybe just pre-trunk
[11:30] <t1mp> Chipaca: we were discussing exactly the same for ubuntu-ui-toolkit
[11:31] <didrocks> t1mp: their case is a little bit different as they need protocol to be available for the server side
[11:31] <Chipaca> t1mp: ubuntu-ui-toolkit also has a server that might need a quicker turnaround than the client for security or performance reasons?
[11:31] <t1mp> Chipaca: no
[11:31] <didrocks> t1mp: btw, just telling, still no SDK requests… so I don't understand why you are blocked on getting MP in
[11:31] <Chipaca> t1mp: ah :)
[11:32] <didrocks> Chipaca: I'm not imaginative on names
[11:32] <t1mp> didrocks: because we run all the tests before happroving and before doing landing requests
[11:32] <didrocks> t1mp: yeah, and so, you are not passing tests and can't bundle them in one big requests?
[11:33] <didrocks> t1mp: the external communication seems that you are locked by us, I'm clearly unsure why
[11:35] <t1mp> didrocks: yes we are not passing tests for the individual MRs. I don't think the MRs are wrong (lets say an MR without changes will even fail)
[11:35] <t1mp> didrocks: so it is more a matter of our policies than not being able to create a landing request
[11:35] <didrocks> t1mp: they are passing on the dashboard though
[11:35] <didrocks> ok, please be clear in the communication then, it seems what I'm hearing back from your team telling to other people don't really match that
[11:36] <t1mp> didrocks: yes images 262 and 263 seem good. yesterday I spent time trying to get the ubuntu-test-cases scripts running locally for testing but I didn't finish
[11:37] <didrocks> t1mp: as told multiple times, (and during the bootcamp to the lander), the metric should be "do we have the same failures than in the dashboard and not more?"
[11:37] <didrocks> not "do we pass all tests"
[11:37] <didrocks> otherwise, you will be blocked on other people having their tests failing
[11:38] <didrocks> (of course, you need to check that the tests that are failing are exactly the same and due to the same cause)
[11:38] <t1mp> didrocks: yes that was the problem. So either I misunderstood our policies, or we have impossible policies for uitk MRs
[11:39] <didrocks> t1mp: TBH, you policy seems really impossible to me, let's see I do a wrong commit in unity8 AP tests
[11:39] <didrocks> then, sdk shouldn't be blocked on that
[11:39] <didrocks> sdk should just not "aggreviate" the issue
[11:39] <didrocks> (if that makes sense)
[11:39] <t1mp> didrocks: yes it makes sense
[11:40] <didrocks> the lower you are in the stack, the more responsabilities you have
[11:40] <didrocks> but don't punish yourself more than you have to ;)
[11:41] <didrocks> bzoltan: you should have a read here as well (the last 10 minutes) ^
[11:41] <t1mp> well the idea of having 100% OK on all app AP tests is nice, but clearly not working well
[11:41] <didrocks> yeah, clearly not reachable or you will release almost never
[11:41] <didrocks> and then, you end up with that status
[11:41] <didrocks> but for me, there was no ambiguity, I didn't know you have that policy
[11:42] <didrocks> (of course, an AP failure can hide another one, but I think that's rare enough that we can afford the risk)
[11:42] <t1mp> didrocks: still having a staging might make it possible. We don't require 100% for merging to staging, but before staging goes to landing/trunk we can wait for an image where we have 100%
[11:42] <didrocks> t1mp: you will almost still never release in distro
[11:42] <didrocks> t1mp: as from experience, we are not at 100% frequently
[11:42] <didrocks> so I guess you are not going to fix your problem
[11:43] <didrocks> just pushing it back on tree down the street
[11:43] <t1mp> didrocks: we had images 250 and 262 now 100% on mako. I hope 100% will only become more frequent :)
[11:44] <t1mp> but I cannot predict that of course
[11:44] <didrocks> t1mp: well, better to deal with the reality for now and not having you blocking on that
[11:44] <didrocks> and that's the policy that all other upstreams have btw
[11:44] <t1mp> okay
[11:44] <didrocks> or you won't be able to push code to distro and it won't be sustainable
[11:45] <t1mp> bzoltan: ^ we can start to work with that now and see from there if we need/can improve the process?
[11:45] <didrocks> t1mp: I guess the harder for you will be the first landing now that you have a lot of branches
[11:46] <didrocks> but then, I think you will be in a similar situation than other trunks with a lot of commits
[11:46] <t1mp> didrocks: we don't have to land all the branches at once, we can start with a few simple ones
[11:46] <didrocks> t1mp: agreed, you can try multiple batches
[11:46] <bzoltan> t1mp:  Would you join to Mumble?
[11:46] <t1mp> ok
[11:52] <t1mp> didrocks: I'm not a lander, so maybe I missed it, but what is the main argument against having a staging where the changes go first before landing them?
[11:52] <t1mp> didrocks: sorry if you had to explain it several times before already
[11:53] <didrocks> t1mp: bzoltan should have them, but you can see what I wrote 33 minutes ago on the same channel :)
[11:53] <t1mp> didrocks: to Chipaca or me? (I'm reading through the backlog now)
[11:54] <didrocks> to Chipaca
[11:54] <didrocks> basically decolloration of concerns and release early, release often
[11:59] <bzoltan> didrocks: decolloration?
[11:59] <didrocks> bzoltan: separation of concerns
[12:00] <bzoltan> didrocks:  pronouncing  it sounds ... hkhm... odd :D
[12:00] <didrocks> yeah, I mistyped
[12:00] <didrocks> decorrelation*
[12:00] <bzoltan> didrocks: OK :) dick coloration
[12:00] <didrocks> :p
[12:01] <t1mp> with a staging we still want release early & release often, but there will be a buffer (that we should keep small)
[12:02] <didrocks> t1mp: the question is why? it seems you argument was the 100% tests passing
[12:02] <didrocks> which won't get fixed by it
[12:03] <t1mp> didrocks: true
[12:04] <t1mp> well with the buffer we can wait for 100% before landing, but I'm not sure anymore if that's worth it
[12:05] <didrocks> well
[12:05] <t1mp> didrocks: it seems like we are too careful trying not to break anything
[12:05] <didrocks> you won't be able to land the buffer often I think
[12:05] <didrocks> as I told above :)
[12:06] <didrocks> and when you land your buffer, there is a higher chance that you are going to have regressions (harder to decipher then) with things not catched up by automation
[12:09] <jdstrand> cjwatson: re v8 portability> I'm not sure of the context of the question. if you are asking re MIR> yes, there is a question in the MIR bug with a statement. if re why in the 1st place> ppc64el didn't exist when the decision was taken and arm64 is expected from upstream
[12:09] <cjwatson> just wondering about ongoing prospects.  it looks like the MIR answers that (not really to my liking, but never mind)
[12:10] <jdstrand> as for the statement> as mentioned arm64 is expected. if we want ppc64el, we just have to work with upstream rather than distro patching
[12:10] <jdstrand> I have to believe upstream will want to support arm64 devices at some point
[12:11] <jdstrand> ppc64el I would think would be an easier port and more palatable to upstream than powerpc, but that is just a hunch
[12:20] <Saviq> sil2100, hmm "Migration: One package at least is not available at the destination. thumbnailer (1.0+14.04.20140327-0ubuntu1) is in the UNAPPROVED queue." what's that about?
[12:20] <Saviq> it's landing 013
[12:22] <sil2100> Saviq: beta freeze
[12:23] <sil2100> Saviq: because of beta freeze it seems thumbnailer is locked in unapproved
[12:23] <Saviq> sil2100, ah right
[12:23] <sil2100> Saviq: you can try bribing the release team to push it forward or simply wait for it to move on ;) Do you have another landing of thumbnailer nearing by or something?
[12:23] <Laney> You should put that in the general status
[12:23] <Saviq> sil2100, not that I know of, let me ask
[12:24] <dbarth> another one about oxide
[12:24] <Laney> The freeze is intended to stay on until the release, btw
[12:24] <dbarth> ah jdstrand maybe you can help
[12:24] <dbarth> should chris find a sponsor for uploading a new version of oxide
[12:24] <dbarth> or should we go via the silo/ppa now that it's going to main?
[12:25] <sil2100> A silo can be used for this if it's related to the landing
[12:25] <dbarth> and do we have /very fast/ arm builders?
[12:25] <sil2100> Then it will be pushed to the archive along the merge branches
[12:25] <dbarth> oxide is webkit/chrome and takes ages
[12:25] <sil2100> dbarth: our silo PPA's have the same builders as the archive has ;)
[12:25] <cjwatson> dbarth: highbank is pretty good
[12:25] <dbarth> so fast?
[12:26] <dbarth> ie native
[12:26] <cjwatson> silos are native, yes
[12:26] <dbarth> ok then
[12:26] <dbarth> ah cool
[12:26] <dbarth> jdstrand: that's the way to go right? i'm not sure if we're already in main or just about to
[12:26] <dbarth> (that should be the first new upload i guess)
[12:27] <jdstrand> dbarth: that is an open question. we have to define how to do landings. in the meantime, we can do whatever is easiest. I can sponsor for chris, or we can go the silos route
[12:27] <jdstrand> dbarth: what I've done with apparmor is have them upload to our security-proposed ppa, then I pocket copy from there to a silo after review
[12:28] <jdstrand> dbarth: don't we have this same issue with webbrowser-app though?
[12:28] <dbarth> ah
[12:28] <dbarth> hmm, yes as we were discussing with cjwatson earlier
[12:28] <jdstrand> dbarth: it isn't in main afaik-- it needs to be seeded or something needs to Depends/Build-Depends on it
[12:29] <dbarth> he proposed to take care of the webbrowser-app archive injection
[12:29] <dbarth> to avoid speical casing a build that should be kept clean of arch specific controls
[12:30] <dbarth> ah right
[12:30] <Saviq> sil2100, so, if the freeze is on until release, does that mean we can't land anything? or is thumbnailer just not exempt like other touch-only components?
[12:30] <dbarth> jdstrand: right now i need a newer build somewhere like in silo 009, universe or main to have the silo be landable
[12:31] <dbarth> or it just crashes webbapps
[12:31] <sil2100> Saviq: I think we need to discuss that with the release team, so that we can release that through the block
[12:31] <dbarth> jdstrand: i guess i should take oxide in the silo as well
[12:32] <jdstrand> dbarth: how do you handle webbrowser-app? is it ppu or is oSoMoN core-dev?
[12:32] <jdstrand> (that is another option btw, chris pursuing core-dev)
[12:33] <dbarth> webbrowser-app lands via a silo
[12:33] <jdstrand> I see
[12:33] <jdstrand> we aren't setup for autolanding yet
[12:33] <jdstrand> (via silo)
[12:33] <dbarth> ok nw
[12:34] <didrocks> Saviq: I need to rebuild landing-010
[12:34] <didrocks> sorry, my fault
[12:34] <didrocks> have you started the testing on it already?
[12:34] <jdstrand> dbarth: so we need to do source package upload. do you want that via the archive or the silo?
[12:34] <Saviq> didrocks, k, was about to test it, will wait then
[12:35] <dbarth> jdstrand: via archive i guess; then we avoid the extra build
[12:35] <jdstrand> sorry, I meant to say the other option is chris pursuing ppu (he could do core-dev too, but ppu should be much faster)
[12:35] <dbarth> yup
[12:35] <jdstrand> dbarth: I can avoid the build
[12:35]  * jdstrand can do a copy
[12:36] <dbarth> ah
[12:36] <t1mp> plars: any ideas what can be wrong here?
[12:36] <dbarth> jdstrand: but maybe we can stay in universe still this week and chris can upload right now
[12:36] <jdstrand> but, it seems that via the archive is fine too
[12:36] <jdstrand> that would work too
[12:36] <dbarth> then once the silo is ready we do the seed / depend dance
[12:36] <dbarth> and talk about silo landings again
[12:36] <didrocks> Saviq: building now :)
[12:37] <jdstrand> ftr, he can always upload to one of the security teams ppas. you then can ask me, an archive admin or a member of the citeam to copy the packages in
[12:37] <jdstrand> (in to the silo)
[12:37] <cjwatson> Saviq,sil2100: we'll be able to land thumbnailer after we're done with the beta
[12:37] <cjwatson> Saviq,sil2100: it's just on non-touch images so it would be disruptive to land it *right now*
[12:38] <jdstrand> dbarth: but, like I said in the email thread-- it is an open question how to do the landing since there will be multiple trees for dev, beta, stable, etc
[12:38] <Saviq> cjwatson, ok, I misunderstood Laney, then
[12:38] <dbarth> yup
[12:38] <jdstrand> dbarth: have you communicated with chris that we need an upload prepared?
[12:38] <sil2100> cjwatson: oh, ok, since I misunderstood Laney that the beta freeze is till the release, ok
[12:38] <dbarth> jdstrand: yes
[12:38] <sil2100> Thanks
[12:38] <jdstrand> ok
[12:38] <Laney> The *archive* freeze is
[12:38] <dbarth> jdstrand: this is when he asked me of the route to take
[12:38] <cjwatson> Laney is correct that the archive is still frozen until release, but we'll have more flexibility in accepting things past it after beta
[12:38] <Laney> So you're going to see things going to the unapproved queue, that's what I mean
[12:39] <jdstrand> sounds like just to the archive for today is fine. when it moves to main, we can do it via our ppas until we have an MP landing story
[12:39] <jdstrand> dbarth: ok, I'll communicate that to him
[12:40] <Saviq> Laney, cjwatson, got it
[12:40] <dbarth> jdstrand: ok thanks
[13:13] <sil2100> This freeze is even more troubling for the free-silo-count...
[13:14] <cjwatson> it should be only hours now
[13:15] <sil2100> cjwatson: phew ;)
[13:17] <cjwatson> I went through this morning to find things that were only on touch and not other images and accept them, but most such had already been auto-accepted
[13:27] <Mirv> sil2100: do you think line 7 should have some note about it being blocked by the oxide landing?
[13:28] <seb128> cjwatson, is there anything that is preventing bugfixes uploaded to be accepted to trusty-proposed during the freeze (I guess we have a britney lock in place like for other milestones?)
[13:28] <sil2100> Mirv: not sure, since it's obvious that webbrowser-app is simply locked
[13:29] <cjwatson> seb128: I don't know whether we do or not; I haven't really been involved in this beta so I'm a little reluctant to suddenly parachute in
[13:29] <Mirv> sil2100: yeah, I was more wondering if that landing has been discussed since it claims to be ready but doesn't have a silo (same goes for thostr's line 10)
[13:29] <sil2100> Mirv: line 10 is unassigned because there are no silos free
[13:29] <seb128> cjwatson, fair enough, thanks
[13:29] <cjwatson> seb128: I mean I tend to agree that's generally more sensible as a practice, I just don't want to break something at the last minute ...
[13:30] <sil2100> Mirv: 4 free silos means that we have like only 3 free and 1 preproduction
[13:30] <sil2100> And our policy says to leave 3-4 free for emergencies
[13:30] <seb128> cjwatson, yeah, agreed, we are unfreezing today anyway (if everything works out as planned)
[13:30] <Mirv> sil2100: yep, we quite often have that amount only nowadays :)
[13:30] <Mirv> but that should ease up later today like discussed
[13:30] <cjwatson> I'll check with infinity as soon as he appears; we can probably unfreeze fairly soon if everything seems golden
[13:30] <sil2100> Mirv: the landing line 7 was discussed but dbarth said that oxide landing is more high prio ;)
[13:30] <seb128> cjwatson, it just feels like some of the easy bugs fixes could have been let it between monday and today, and blocked in proposed
[13:30] <Mirv> 3 mor eislos
[13:30] <cjwatson> yeah, I get it
[13:30] <sil2100> Mirv: I hope so!
[13:30] <Mirv> sil2100: yeah, thanks
[13:31] <cjwatson> nobody seems to be panicking on #-release which is usually a good sign about now
[13:31] <seb128> ;-)
[13:31] <plars> t1mp: hi
[13:31] <plars> t1mp: what's the problem?
[13:33] <didrocks> Mirv: sil2100: the number of free silos don't count pre-prod
[13:33] <didrocks> doesn't*
[13:34] <sil2100> didrocks: oh :)
[13:36] <Mirv> so 4, thostr could get one then too maybe for url-dispatcher? :)
[13:36] <sil2100> Mirv: already assigned;)
[13:36] <Mirv> sil2100: great, waiting for it to refresh
[13:36] <Mirv> now the sheet is all covered again
[13:36] <sil2100> \o/
[13:37] <Chipaca> sil2100, Mirv, didrocks: Can I have a silo for row 32?
[13:37] <sil2100> Chipaca: uuuh
[13:38] <sil2100> Chipaca: is it a high urgency landing?
[13:38] <Chipaca> sil2100: I'm going to bite my tongue and say "no" :)
[13:39] <dbarth> sil2100: yes, we need that oxide silo please; we just have 1 at the moment
[13:39] <sil2100> Chipaca: because we're low on landings because of the beta freeze and other landers not pushing their landings forward - let's wait a little bit if any silos get freed and revisit then
[13:39] <Mirv> Chipaca: after beta gets released later today, it should be possible to get a silo from robru etc
[13:39] <Mirv> or well, it will probably be automatically given
[13:40] <Chipaca> fair enough
[13:40] <Chipaca> Mirv: sil2100: i'll pester y'awl later today then :D
[13:41] <sil2100> Chipaca: no worries, we'll assign a silo as soon as there's the possibility ;) We promise that it will not be too long!
[13:41] <Saviq> sil2100, silo 008 can be published please
[13:41] <sil2100> Saviq: awesome, thanks! Doing
[13:43] <Mirv> unity-scope-click shouldn't be seeded outside touch, so that silo can be also freed then soon
[13:43] <sil2100> Indeed
[13:44] <Saviq> Mirv, sil2100, do you know if/why thumbnailer is seeded outside touch?
[13:46] <Mirv> Saviq: yes
[13:46] <cjwatson> Saviq: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.trusty/rdepends/thumbnailer/libthumbnailer0
[13:46] <Saviq> cjwatson, thanks!
[13:46] <Saviq> right, that makes sense
[13:47] <Mirv> Saviq: thumbnailer -> UITK -> webbrowser-app -> unity-webapps-service -> bamfdaemon -> unity, about
[13:47] <Mirv> that's why I needed to rebuilt half the world of Qt 5 dependencies before I could upgrade to it on my desktop without losing Unity 7
[13:48] <Mirv> when migrating to Qt 5.2's libqt5core5a
[13:48] <sil2100> didrocks: so, packaging ACK - it's a big one, since it has the removal of automake and vala deps - the --buildsystem cmake doesn't seem required, but I guess it's no blocker:
[13:48] <sil2100> http://162.213.34.102/job/landing-008-2-publish/42/artifact/packaging_changes_unity-scope-click_0.1+14.04.20140326-0ubuntu1.diff
[13:50] <Saviq> didrocks, sil2100, here's the respective MP https://code.launchpad.net/~dobey/unity-scope-click/drop-vala/+merge/212505
[13:51]  * didrocks isn't going to argue on -Section: gnome
[13:52] <didrocks> +Section: x11
[13:52] <didrocks> but it's weird
[13:52] <t1mp> plars: hello
[13:53] <t1mp> plars: running *all* tests takes too long, so I was trying to run individual autopilot tests
[13:53] <plars> t1mp: ok
[13:53] <t1mp> plars: ah I forgot to paste the url when I asked for your help, let me look it up
[13:53] <plars> :)
[13:54] <t1mp> plars: http://pastebin.ubuntu.com/7162447/
[13:54] <plars> t1mp: uhoh... give me a minute
[13:54] <plars> t1mp: I think I may have a drive going bad
[13:54] <plars> need to reboot
[13:55] <t1mp> ok
[13:56] <bzoltan> Mirv: sil2100: I am good with the line 31 ... do we have any chance to get a silo?
[13:58] <t1mp> I cannot properly view that spreadsheet.. it seems its scrolling is discrete, I cannot go up and down in a single field
[13:58] <t1mp> a larger screen would solve that also :)
[14:00] <didrocks> Mirv: sil2100: as we are close from beta unfreeze, I think we can keep 1 silo for urgency (in addition to the preprod silo)
[14:00] <didrocks> sil2100: +1 on the packaging change
[14:00] <sil2100> didrocks: aye!
[14:00] <sil2100> didrocks: thanks ;)
[14:00] <Mirv> bzoltan: reading ^ yes, just a moment
[14:00] <sil2100> bzoltan: sure ;)
[14:01] <Mirv> sil2100: handling already
[14:01] <sil2100> Mirv: thanks ;)
[14:01] <sil2100> Saviq: ok, -click published o/
[14:02] <t1mp> didrocks: ^we're following your suggestions now and doing a landing
[14:02] <didrocks> t1mp: excellent news!
[14:04] <plars> t1mp: typing from my phone now, my laptop HD appears dead. Looks like you had some sort of adb problem. Check your device, make sure you can adb shell to it and retry
[14:04] <sil2100> Chipaca: assigning a silo for you as well
[14:05] <Chipaca> oh, noes!
[14:05]  * Chipaca grins
[14:05] <Mirv> bzoltan: landing-018, feel free to click Build when ready
[14:05] <bzoltan1> t1mp: didrocks: I still would be more relaxed to have each MR being tested against a good list of applications before even entering to the landing queue
[14:05] <t1mp> bzoltan1: yes, me too.
[14:06] <didrocks> bzoltan1: the thing is that we don't have applications tests which never failed
[14:06] <bzoltan1> Mirv: sil2100: thank you gents
[14:06] <t1mp> bzoltan1: in this case most of them were tested several times over the past days/weeks, but never with 100% OK in a qt52 image :(
[14:06] <didrocks> bzoltan1: so always compare to the dashboard results is the key I guess
[14:06] <bzoltan1> didrocks: that is a problem what we should fix :)
[14:07] <didrocks> bzoltan1: well, I'm spending hours everyday to try to ensure that stays green
[14:07] <t1mp> bzoltan1, didrocks having tests and not requiring them to be green makes them less useful. But I guess we all know that already
[14:07] <bzoltan1> didrocks:  I am sure you do and I know that your effort are above human capabilities to keep that train moving!
[14:08] <didrocks> t1mp: we do require, see the effort on the mailing list and blockers
[14:08] <t1mp> plars: adb works fine. I tried again, and I get more output now but it fails the same: http://pastebin.ubuntu.com/7162910/
[14:09] <t1mp> didrocks: yes, I saw that. That kind of inspired us to require the tests to pass for our MRs
[14:09] <Chipaca> 🚂🚃🚃🚃 choo choo
[14:11] <josharenson> fginther: Hi, I was told to get in touch with you regarding adding a test to the CI runs that occur for the Mir dev branch. Is this something you can help me with?
[14:12] <t1mp> plars: is gallery_app not a valid value to pass with -t ?
[14:13] <didrocks> ogra_: seems your bot didn't pick my new image build kick
[14:13] <ogra_> oops
[14:13] <ogra_> one sec
[14:13] <t1mp> plars: maybe it should be -a gallery_app
[14:13] <t1mp> me trying that
[14:13] <ogra_> |HELP
[14:13] <imgbot> I am the firendly image watchbot
[14:13] <ogra_> hmm
[14:14] <fginther> josharenson, yes, but in the future please ping the 'Vanguard' identified in the channel topic to make sure the request is properly handled (in case I'm not around)
[14:14] <ogra_> didrocks, when did you start it ? it only scans all 5 mon
[14:14] <ogra_> *min
[14:14] <ogra_> (not months)
[14:14] <didrocks> ogra_: hum… 7/8 minutes ago I would say
[14:14] <ogra_> lets give iit one more min
[14:14] <imgbot> [14:15] <didrocks> ahah :)
[14:15] <ogra_> heh
[14:15] <sil2100> ;)
[14:15] <ogra_> imaptient you are :)
[14:15] <didrocks> bfiller: davmor2: image building with the gallery-app click store revert ^
[14:15]  * sil2100 knows that in reality imgbot is just ogra_ typing in stuff manually on his separate IRC session
[14:15] <ogra_> there are two different cron jobs running for the check ... if they overlap it can take up to 10min
[14:15] <didrocks> yeah
[14:15] <didrocks> got it
[14:16] <ogra_> sil2100, nah, i got speech input :P
[14:16] <sil2100> hah ;)
[14:16] <t1mp> plars: IT WORKS! tests are running! :)
[14:16] <t1mp> kalikiana: ^^
[14:16] <t1mp> kalikiana: ./run-smoke -n -a gallery_app
[14:19] <ogra_> i would appreciate a silo for a direct upload for line 34 btw :)
[14:31] <plars> t1mp: ok, I have a somewhat usable desktop back - there was too much scrollback for my phone to be very useful but it looks like it's working now?
[14:33] <t1mp> plars: yes it looks like it. Still figuring out what is logged, like the versions of the apps and AP tests?
[14:36] <sil2100> ogra_: if you need a direct upload, just state in the sources field the source package name ;)
[14:36] <t1mp> kalikiana: I *guess* it checks the test version needed. I didn't tell any of the scripts to fetch gallery or its autopilot tests
[14:36] <sil2100> ogra_: the link to the debdiff you can leave in the comments then
[14:36] <t1mp> kalikiana: but I don't see it in the logs on my laptop
[14:37] <ogra_> sil2100, you mean in the merge proposals field ?
[14:43] <Chipaca> sil2100, Mirv, didrocks: Can I have a landing for silo 19?
[14:45] <didrocks> Chipaca: debian/control still has the multiarch tag, right?
[14:46] <Chipaca> didrocks: mutliarch:foreign, yes
[14:46] <didrocks> Chipaca: so, you want to remove that as the package isn't multiarch anymore
[14:46] <Chipaca> didrocks: the fix is that i was instlling the libexec as if it were mutliarch:somethingelse
[14:47] <Chipaca> didrocks: it isn't?
[14:47] <didrocks> Chipaca: let me check, but it's not into that diff
[14:48] <didrocks> Chipaca: https://code.launchpad.net/~ubuntu-push-hackers/ubuntu-push/automatic/+merge/213058 I don't see it
[14:49] <Chipaca> didrocks: sorry, what should you be seeing?
[14:49] <didrocks> Chipaca: removal of Multi-Arch: foreign
[14:49] <Chipaca> didrocks: but... why?
[14:49] <didrocks> you don't install any multi-arch files
[14:49] <Chipaca> I'm honestly confused, now
[14:49] <Chipaca> cjwatson: halp?
[14:50] <cjwatson> didrocks: that doesn't make sense
[14:50] <cjwatson> didrocks: you're thinking of Multi-Arch: same
[14:50] <didrocks> cjwatson would know more than I, but I'm pretty sure it needed to be removed
[14:50] <didrocks> cjwatson: oh right
[14:50] <cjwatson> didrocks: Multi-Arch: foreign is still fine here
[14:50] <didrocks> sorry, yeah, my bad
[14:50] <Chipaca> didrocks: this change is after talking with cjwatson; I know nothing :)
[14:50] <didrocks> as it's an executable service
[14:50] <Chipaca> *phew*!
[14:50] <cjwatson> right, the problem was that it was bogusly installing files as if it were M-A: same when it isn't :)
[14:50] <Chipaca> cjwatson: thanks :)
[14:50] <didrocks> cjwatson: yeah, thanks for clarifying
[14:51] <didrocks> Chipaca: published
[14:51] <Chipaca> whee :)
[14:51] <cjwatson> though that changelog version goes backwards
[14:51] <cjwatson> which is kinda weird
[14:51]  * sil2100 is back from lunch
[14:52] <Chipaca> there's something funny in the changelog; hopefully it'll settle now that we've switched
[14:52] <sil2100> So many landing, not enough free silos :<
[14:52] <didrocks> cjwatson: well, the version is overriden by daily-release
[14:52] <cjwatson> fair enough
[14:52] <didrocks> or ci train rather
[14:52] <Chipaca> i've got to go to my school run, will be back in an hour, feel free to merge&clean #19 while i'm away
[14:52] <Chipaca> otherwise i'll do it when i return
[14:52] <didrocks> Chipaca: seems you click "merge and clean" too soon btw :)
[14:53] <didrocks> yeah, we'll probably do that to free up the silo as soon as it's published
[14:53] <Chipaca> didrocks: yes :) hence my above :D
[14:53]  * Chipaca will bbl
[14:53] <didrocks> Saviq: m&c lines 24?
[14:54] <didrocks> sil2100: I guess you should do it so that you can reassign one ^
[14:55] <sil2100> Saviq: can you m&c silo 8?
[15:10] <sil2100> Saviq, tvoss: so, how's the discussion going with the Qt upstream regarding that event-queue bug/feature?
[15:11] <Mirv> did m&c for Saviq to get that silo into new use
[15:12] <sil2100> Mirv: thanks!
[15:25] <Saviq> Mirv, oh thanks
[15:26]  * Saviq was in a looong meeting
[15:26] <Saviq> sil2100, ↑ that
[15:27] <sil2100> It's freed \o/
[15:27] <sil2100> ogra_: let me assign a silo for you maybe
[15:27] <ogra_> as you like, i'm not in a hurry as long as i can upload today
[15:28] <ogra_> if there are more urgent bits, take them first
[15:28] <sil2100> ogra_: assigned, would be nice if you could upload today and release the silo soon ;p
[15:29] <ogra_> yep, after the meeting i'm currently having
[15:30] <tvoss> sil2100, we are still investigating, upstream has been quite helpful in understanding the underlying issue and greyback is working on a possible solution
[15:31] <sil2100> tvoss: that's excellent news \o/
[15:31] <sil2100> Thanks
[15:37] <Saviq> sil2100, I'll try and land unity8 asap, and then right edge, so two silos will hopefully be freed
[15:38] <sil2100> \o/
[15:39] <sil2100> Chipaca: could you m&c silo 19?
[15:39] <t1mp> plars: some times I have the issue again that i mentioned before
[15:40] <t1mp> plars: it seems that the script calls adb reboot, and then tries to do something before the device is back online
[15:41] <sil2100> Chipaca: ok, I'll press m&c then
[15:41] <t1mp> plars: http://pastebin.ubuntu.com/7163364/ the error comes before the device is back up
[15:41] <plars> t1mp: it's doing an adb-wait-for-device
[15:42] <plars> t1mp: we see those adb protocol faults very rarely in production, and not so much lately
[15:42] <plars> t1mp: it's not the same as a device that's missing (adb device not found error)
[15:42] <plars> t1mp: I'm not sure why you seem to get them so much though
[15:42] <plars> t1mp: I don't know if it would help, but you could also try specifying the adb serial with -s
[15:45] <t1mp> plars: same result with -s
[15:46] <plars> t1mp: you have the magic setup for reproducing these adb protocol faults then it seems. We had a lot of problems with them in the past, but they seemed to get better over time and nobody could explain them or even reproduce them reliably
[15:47] <t1mp> plars: so I have the perfect setup for debugging them :)
[15:48] <ogra_> plars, well, they happened when the USB gadget device was reconfigured for adb and mtp ... all code doing that (except for the android bits) was dropped recently
[15:48] <ogra_> protocol faults shouldnt happen anymore since a while already
[15:49] <plars> ogra_: yeah, we don't have problems with it in the lab for quite a while now
[15:49] <plars> ogra_: t1mp is hitting them regularly at home though
[15:49] <ogra_> t1mp, what image version and what device is that ?
[15:49] <t1mp> ogra_: mako 262
[15:49] <ogra_> plars, right, theoretically they cant happen anymore unless you use a broken cable or some such
[15:50] <ogra_> since the gadget never gets reconfigured
[15:51] <ogra_> t1mp, any other usb cable around you could try ?
[15:53] <t1mp> hmm does this tell anything? http://pastebin.ubuntu.com/7163424/
[15:53] <t1mp> ogra_: yes, I'll check now
[15:54] <t1mp> ogra_: same result
[15:54] <t1mp> interestingly, wait-for-device waits a while, then it fails. And if I check *immediately* after it fails, the device is back online
[15:55] <t1mp> so wait-for-device seems to fail in the moment the device is coming online again
[15:55] <t1mp> ogra_: in general I think the two cables I tried now are not broken, because I have been running a lot of autopilot tests over them which can last for hours, without cable problems
[15:56]  * t1mp gotta go, bbl
[15:57] <ogra_> t1mp, what android-tools-adb version do you run on your desktop
[15:58] <dbarth> sil2100: checking about silo statuses: we have some sdk improvements to land: how is that possible right now with silo availability and freeze?
[15:58] <dbarth> sil2100: that's phone html5/sdk; new apis
[15:59] <davmor2> ogra_: what happened to imgbot again?
[15:59] <ogra_> davmor2, nothing, anything wrong with it ?
[15:59] <sil2100> dbarth: hmmm, so...
[15:59] <ogra_> |HELP
[15:59] <imgbot> I am the firendly image watchbot
[15:59] <ogra_> davmor2, still there
[15:59] <davmor2> ogra_: I see image 264 Building but no 264 is done
[15:59] <sil2100> dbarth: currently we're a bit low on silos, but I hope we'll have more pretty soon, like around evening
[16:00] <davmor2> ogra_: and I've just upgraded to it so it is :)
[16:00] <ogra_> hrm
[16:00] <ogra_> it says it is done in its local log too
[16:00] <ogra_> bah, and it dropped at :35
[16:01] <davmor2> ogra_: haha
[16:01] <dbarth> sil2100: ok, so i'll prep a request for later today
[16:01] <dbarth> thanks
[16:03] <sil2100> dbarth: ok :) I'll make sure robru will assign it once we have free slots!
[16:09] <ogra_> davmor2, thanks for pointing it out ... i have adjusted some bits, hopefully it works better now
[16:09] <davmor2> ogra_: \o/
[16:13] <dbarth> sil2100: there is the question of whether we should land new APIs right now though; it's mostly for phone, but the packages are in main :/
[16:14] <dbarth> i guess we're not the only one landing new phone stuff, so what is the general policy?
[16:15] <sil2100> dbarth: if it's for touch only and is covered by the standing touch FFe, then we can land it
[16:15] <sil2100> We generally don't stop the line for touch specific features
[16:17] <sil2100> didrocks: ok, so, since I'm not sure if you're up-to-date on the Qt-bug status, but from what Thomass mentioned, Qt upstream was very helpful and now greyback is working on a solution that can resolve the bug
[16:18] <didrocks> sil2100: yeah, I saw it on the backlog, thanks for checking!
[16:18] <dbarth> sil2100: ah ok, so i think we're covered there then
[16:21] <sil2100> kenvandine, cyphermox: not to bother didrocks, could anyone of you guys take a look at https://code.launchpad.net/~sil2100/dee-qt/add_cpp_symbols/+merge/202679 and review? Upstream asked for some core dev to review it ;)
[16:21] <ogra_> sil2100, silo-008 can be released
[16:22] <josharenson> fginther: Are you still available? I apologize for dropping off, was having internet issues.
[16:22] <sil2100> \o/
[16:24] <sil2100> ogra_: published o/
[16:24] <fginther> josharenson, I'm in the middle of a meeting. if you have a well defined request, you can just add a bug under ubuntu-ci-services-itself.  If this needs discussion can come back to this in about 2 hours?
[16:24]  * sil2100 goes prepare for practice
[16:24] <ogra_> sil2100, thanks !
[16:27] <ogra_> plars, doanac, could we sit down some point next week and look how we get my bootchart script into your infra (http://paste.ubuntu.com/7162200/) ?
[16:27] <plars> ogra_: sure, sounds good - I saw something about it requiring a dedicated device?
[16:27] <ogra_> plars, well, it will need a fresh installation and will then hog the device for a while
[16:28] <ogra_> i wouldnt run it in the normal dashboard run but in parallel somehow
[16:28] <plars> sure
[16:28] <didrocks> hum
[16:28] <didrocks> ogra_: I don't see address-book-app listed
[16:28] <ogra_> (with dedicated device i meant it should be run standalone, i think i mis spelled that a bit)
[16:29] <didrocks> ogra_: on #264
[16:29] <didrocks> is it expected?
[16:29] <plars> ogra_: oh, I also wanted to ask you about ofono-phonesim and messaging-app tests on tablets - is that still an issue? Do we need to force installation of that?
[16:29] <plars> ogra_: I don't have a tablet at home to mess with
[16:30] <ogra_> plars, the tests look fine (same crashes as mako, no additional errors)
[16:30] <ogra_> didrocks, i dont see addressbook-app uploaded
[16:30] <didrocks> ogra_: it's been reverted in the store
[16:30] <didrocks> by popey
[16:30] <ogra_> hmm
[16:30] <didrocks> I wonder if the revert took effect then
[16:30] <ogra_> didrocks, and how would that help for a deb ?
[16:30] <ogra_> http://people.canonical.com/~ubuntu-archive/click_packages/click_list
[16:31] <didrocks> ogra_: bah
[16:31] <didrocks> I'm stupid
[16:31] <didrocks> I meant gallery-app
[16:32] <ogra_> what version should that be at ?
[16:32] <didrocks> 14:49:45          popey | "Changed published version to 2.9.1.934"
[16:32] <ogra_> hmm
[16:33] <ogra_> if dpkg --compare-versions "$newversion" gt "$version"; then
[16:33] <ogra_> :P
[16:33] <didrocks> ogra_: ahah, even with click?
[16:34] <ogra_> yes, for all lines in the manifest
[16:34] <didrocks> ogra_: how dare you comparing! we need to go backward sometimes :p
[16:34] <didrocks> ogra_: but ok, so the click revert is in?
[16:34] <ogra_> (the script is at the bottom of the page btw)
[16:34] <ogra_> gimme a sec, checking
[16:35] <ogra_> click:com.ubuntu.gallery	2.9.1.934
[16:35] <ogra_> yep
[16:36] <plars> ogra_: so I can close that one then?
[16:36] <ogra_> plars, yeah, happily
[16:37] <didrocks> ogra_: phew, all what counted to me :)
[16:37] <ogra_> :)
[16:50] <didrocks> kgunn: hey, are you coming to the landing meeting? You have some items on the blocker list and we didn't get an update
[16:50] <didrocks> bfiller_afk: same question (ont the telephony-service-indicator)
[16:56] <kgunn> didrocks: this conflicts for me today
[16:56] <didrocks> kgunn: ok, do you mind answering on the ML once I send the email?
[16:56] <kgunn> didrocks: yes..i'll try to address to my best whatever has my name on it
[16:57] <didrocks> kgunn: same than yesterday :)
[16:57] <didrocks> (so no surprise)
[16:57] <didrocks> thanks!
[17:03] <didrocks> plars: coming?
[17:03] <didrocks> cyphermox: ?
[17:03] <plars> didrocks: yes, I'm there now. I was on another call that was running over
[17:03] <plars> didrocks: I have to leave early though
[17:20] <Saviq> robru, hey, silo 10 can be published
[17:21] <robru> Saviq, great, thanks
[17:23] <Saviq> robru, I hope to clean one more silo today - 015 - need 010 to land first
[17:25] <robru> Saviq, ok, i hit publish. not sure how long it will take with the beta freeze, you might want to ask *really really nicely* in #ubuntu-release
[17:26] <Saviq> robru, :D
[17:26] <Saviq> robru, thanks, will do once it's in proposed and pkgtests are done with
[17:26] <robru> Saviq, ok. yeah, keep an eye on the spreadsheet. it might get stuck in UNAPPROVED which means then you really do have to poke release team about it
[17:27] <Saviq> robru, it probably will since we don't have all the arches
[17:27] <robru> ugh, oh yeah.
[17:27] <didrocks> robru: for things that are not seeded in any flavors participating beta, there is an autoapproval mechanism
[17:27] <robru> ahhh ok
[17:27] <didrocks> robru: Saviq: you can see it on #ubuntu-release
[17:27] <didrocks> FYI
[17:27] <didrocks> 18:25:43          -- | Notice(queuebot) -> #ubuntu-release: Unapproved: unity8 (trusty-proposed/universe)
[17:28] <didrocks> -> entering the unapproved queue
[17:28] <didrocks> 18:26:43          -- | Notice(queuebot) -> #ubuntu-release: Unapproved: accepted unity8 [sync] (trusty-proposed)
[17:28] <robru> so it's just when i'm working on webapps that stuff gets stuck ;-)
[17:28] <didrocks> -> the accept (which is an autoaccept)
[17:28] <didrocks> robru: not only that one, but mostly, seeded-in-ubuntu can help to know if it's going to be stuck in unapproved or not
[17:31] <Laney> I don't think you have to poke
[17:31] <Laney> Unless it's been a long amount of time and there is no milestone being prepared
[17:31] <didrocks> Laney: I keep telling the same thing for silo assignement… doesn't work :p
[17:32] <Laney> didrocks: You start deleting requests and I'll start rejecting packages :P
[17:32] <robru> didrocks, actually I love getting poked for silo assignment, it means I don't have to watch the spreadsheet... push notificatons > polling ;-)
[17:32] <didrocks> Laney: ahah ;)
[17:32] <didrocks> robru: I prefer polling over notifications, got too many of them
[17:33] <didrocks> but I guess different workflows and so on :)
[17:33] <Laney> Yeah, you guys give positive reinforcement to poking
[17:33] <didrocks> Laney: we should stay unresponsivness to being poked I guess :p
[17:33] <didrocks> unresponsive*
[17:33] <Laney> Correct, or tell people to wait their turn
[17:33] <Laney> I sometimes do that when I click on a bug that someone pinged about and see "Filed 5 seconds ago"
[17:34] <didrocks> ahah, internal timeout needed :)
[17:34] <Laney> talent management
[17:35] <Laney> I think the queues will start to get flushed soonish btw, it's probably too late to respin anything for beta now
[17:36] <seb128> right, they just confirmed that on #ubuntu-release
[17:36] <Laney> oh yeah, how about that
[17:36] <seb128> no respin, either you are good or you don't ship an image for beta
[17:36] <Laney> the borg has spoken
[17:36] <seb128> lol
[17:37] <didrocks> heh :)
[17:37]  * didrocks waves good evening
[17:37] <didrocks> (and good beta)
[17:37] <didrocks> ;)
[17:37] <seb128> didrocks, night
[17:43]  * t1mp back
[17:43] <t1mp>   Installed: 4.2.2+git20130218-3ubuntu22
[17:43] <t1mp>  [6~ogra_> t1mp, what android-tools-adb version do you run on your desktop
[17:43] <t1mp> ogra_: ^ that version
[17:44] <ogra_> trusty ?
[17:44] <t1mp> yes
[17:44] <ogra_> hmm
[17:44] <ogra_> any USB hubs involved ?
[17:44] <t1mp> ogra_: nope
[17:45] <ogra_> strange
[17:45] <t1mp> I'll try the other usb port on my laptop
[17:45] <ogra_> there s no technical reason that you even *could* get a protocol error
[17:46] <t1mp> same result with the other port
[17:46] <t1mp> the moment the device should come back online, I get the protocol error
[17:46] <ogra_> they only happen if the floor gets pulled out underneath adb ... i.e. if the usb gadget is removed or reconfigured
[17:46] <t1mp> and immediately after that it is back
[17:46] <ogra_> or if there is any hardware issue
[17:46] <t1mp> once the device is online, the connection is stable
[17:46] <t1mp> no problems with running 2 or 3h tests on device started via adb
[17:47]  * t1mp dinner, bbl
[17:47] <ogra_> right, but you seem to have at least one reconnect on boot there
[17:47] <ogra_> which shouldnt happen
[17:47] <cjwatson> https://launchpadlibrarian.net/170675785/account-plugins_0.11%2B14.04.20131126.2-0ubuntu2_0.11%2B14.04.20140325-0ubuntu1.diff.gz   quality changelog there
[17:47] <ogra_> yay
[17:48] <ogra_> i thought didrocks fixed that long ago
[17:48] <ogra_> (we were discussion it in jan. for the first time i think)
[17:48] <ogra_> *discussing
[17:49] <seb128> ogra_, cjwatson: that happens when there is no commit message on the mp I think
[17:49] <davmor2> popey: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1262711 does this effect you still since the home scope is gone?
[17:49] <ogra_> seb128, right, didrocks wanted to add a guard for that so the package is considered FTBFS when that happens
[17:50] <seb128> not sure how those projects are configured
[17:50] <seb128> on e.g indicators the "build" step fails CI on missing commit messages
[17:51] <ogra_> bug 1290771
[17:51] <ogra_> just recently filed
[17:53] <popey> davmor2: well, given it's gone, no. ☻
[17:53] <cyphermox> davmor2: I have a shiny new mtp in my ppa if you're looking for stuff to test :)
[17:54] <cyphermox> it doesn't yet show up properly in media players, but it now doesn't log as stupidly, and notices when you delete or take pictures and stuff, outside of the MTP protocol itself
[17:54]  * ogra_ hugs cyphermox 
[17:54] <cyphermox> ogra_: ppa:mathieu-tl/ppa
[17:55] <cyphermox> before I do a release with citrain though I'd like to make the media player support work
[17:55] <cyphermox> and perhaps add the thumbnails for images too
[17:55]  * davmor2 also hugs cyphermox but currently has his hands full I can test it first thing though
[17:55] <ogra_> well, as long as it happens before release :)
[17:55] <cyphermox> ogra_: it's on track, but yeah. there's also MMS stuff in NM I'm working on now
[17:56] <ogra_> right, but thats blocked from landing during freezes anyway
[17:56] <cyphermox> and urfkill which is getting in a better shape, but I still also need to look into reworking the bluetooth bringup :)
[17:56] <cyphermox> yes
[17:56] <cyphermox> I'm just saying there's lots in progress
[17:56] <ogra_> i wouldnt expect the BT changes for trusty
[17:56] <cyphermox> ogra_: ideally we probably should
[17:57] <cyphermox> or in any case, we should if we want to land urfkill too
[17:57] <ogra_> (like i dont plan to do the "move all HW specifics to android" switch before release)
[17:57] <cyphermox> yeah
[17:57] <cyphermox> it's a little complicated and high risk as we get closer to the release, given that we're changing how stuff happens at startup
[17:57] <ogra_> yeah
[17:58] <ogra_> while it is nice to roll with touch ... i kind of miss the freeze time where you only look at optimization and fixing
[17:58] <cyphermox> me too.
[17:58] <ogra_> with rolling we dont really have that time anymore
[17:59] <cyphermox> well, you need to take it
[17:59] <cyphermox> but I understand what you mean
[17:59] <ogra_> yeah, but meanwhile the world changes underneath you
[17:59] <cyphermox> it would be nice for a little less earth-shattering changes underneath, and more shininess
[17:59] <ogra_> yep
[18:00] <cyphermox> well, the mtp stuff is changes in that direction
[18:00] <cyphermox> nothing earth-shattering, but just works better
[18:00] <ogra_> yeah
[18:01] <cyphermox> so far I haven't managed to break it -- photos shows up if you refresh the file manager; and disappear as soon as they are deleted
[18:01] <cyphermox> I think that may be a limitation in gvfs / mtp; since I do send the proper events AFAIK
[18:01]  * ogra_ rarely uses it ... as long as it doesnt scatter my desktop with messages i'm happy :)
[18:01] <cyphermox> ahah
[18:02] <cyphermox> no, now only two messages at all on a standard install, it says it starts and how many items in the DB on startup
[18:02] <cyphermox> and you can easily make it as verbose as necessary if we need to debug stuff
[18:04] <ogra_> yeah
[18:04] <ogra_> thats cool
[18:05]  * ogra_ grumbles at cpu hotplugging 
[18:06] <ogra_> if i force all cores on i gain 3seconds boot time
[18:07] <ogra_> if i force them on and then later enable hotplugging again i lose them again ... i dont get why
[18:07] <ogra_> (the 3sec)
[18:09] <robru> seb128, ogra_, cjwatson: there is definitely a check to stop MPs with no commit message from even building. I see that fire all the time. citrain won't even build the MP if there's no commit message.
[18:09] <cjwatson> maybe it was non-empty but only whitespace, or something?
[18:09] <ogra_> robru, well, it just did :)
[18:09] <ogra_> and the bug above is still open
[18:09] <seb128> robru, ogra_, cjwatson: I don't think it's true, those checks are a CI thing and the CI is configured differently by projects
[18:10] <seb128> it's not from CI train, but from the CI that runs on mps
[18:10] <ogra_> right
[18:10] <robru> cjwatson, ogra_: i think it's more likely to be that the MP contained a debian/changelog with a release that wasn't UNRELEASED, last time I built a project with a changelog that said 'trusty' it made a +0.1 version with an empty bullet point
[18:10] <ogra_> thats why didier asked me to file the bug against cupstream2distro
[18:12] <robru> seb128, yes, there is *also* a CI thing that fails if no commit message is set. but I have *definitely*, *undoubtedly* on *dozens* of occaisions seen citrain report "build failed because no commit message was set"
[18:12] <seb128> robru, CI train is calling the upstream CI, which is different by project
[18:12] <seb128> robru, I know what you mean, but those checks come from the by-project CI, and not from the train
[18:13] <robru> seb128, http://162.213.34.102/job/landing-001-1-build/72/console
[18:13] <seb128> robru, I'm not discussing that, I hit those often
[18:13] <seb128> I'm just telling you it's no a check from the CI train itself
[18:14] <robru> seb128, how can it be defined per project? can you point at that code that chooses that?
[18:15] <robru> boiko, got you silo 8 btw
[18:15] <boiko> robru: nice! thanks!
[18:15] <robru> boiko, you're welcome
[18:15] <cjwatson> You should get a few silos clearing out soon
[18:17] <seb128> robru, no, I don't, and I might be wrong there, check with didrocks tomorrow
[18:17] <robru> cjwatson, thanks
[18:17] <robru> seb128, got you silo 19 for line 37 anyway. eep!
[18:17] <seb128> robru, thanks
[18:22] <t1mp> ogra_ / plars any ideas what I could look for that causes these protocol faults after adb reboot?
[18:23] <ogra_> how do you reboot ? "adb reboot" or from the logged in shell ?
[18:24] <t1mp> ogra_: adb reboot, but I just tried reboot from shell on device and that gives the same problem
[18:24] <ogra_> ok, i had hopes :)
[18:24] <t1mp> ogra_: with the ubuntu-test-cases scripts I have the problem also (that's when I first noticed it)
[18:24] <t1mp> yes me too, until 20s ago..
[18:36] <t1mp> plars: would the tests fail if I edit the reboot-and-wait script not to do anything? Then at least I can run some tests with the scripts now
[18:37] <ogra_> did you try just adding a sleep so adb waits a little ?
[18:39] <t1mp> nope, didn't try that
[18:40] <t1mp> I'm just getting started with these scripts https://code.launchpad.net/ubuntu-test-cases/touch and they use the adb wait-for-device
[18:40] <ogra_> sounds like a valid workaround
[18:55] <plars> t1mp: some of them might interfere with others, not sure
[19:45] <kgunn> cyphermox: robru....can i get some reconfig love on silo4 ? added a new mp
[19:46] <robru> kgunn, is it a new project?
[19:46] <kgunn> robru: nope just a new mp from mir
[19:46] <robru> kgunn, we got some new crack today ;-)
[19:46] <robru> kgunn, you can do the reconfig yourself, and you don't even have to copy&paste
[19:46] <robru> kgunn, just click reconfig and it does it all for you
[19:46] <kgunn> robru: oh...whoop whoop
[19:46] <robru> thank didrocks for that ;-)
[19:46] <kgunn> i recall the copy/paste...didnt realize new mp's as well
[19:47] <robru> kgunn, yeah, you can reconfig yourself as long as it's not a new project. any change within existing projects is fine (add/remove mps)
[19:47] <kgunn> sweet...ok, i'm off to try
[19:52] <jhodapp> robru, could you rekick land-006 to build again?
[19:53] <davmor2> cyphermox: I had 10 minutes befoer EOD \o/  so new mtp does indeed update when you remove stuff now \o/  Rhythmbox does indeed still just show unknowns but that is just for confirmations sake :)
[19:53] <robru> jhodapp, sure
[19:53] <jhodapp> thanks
[19:53] <cyphermox> davmor2: yeah, as soon as I'm more done with NM and urfkill and others I'll get back and fix that, I already have a good idea what to do and how to do it, just need to write it in code
[19:54] <cyphermox> I'll add thumbnails too so images should show up in nautilus
[19:55] <davmor2> cyphermox: go work so far at least :)
[19:55] <davmor2> s/go/good
[19:57] <davmor2> cyphermox: oh interesting, so it updated if you delete but I had to hit refresh to show the file I added via adb
[19:57] <cyphermox> yeah
[19:58] <davmor2> cyphermox: so that is expected?
[19:58] <cyphermox> I think that's broken in gvfs; going to need to dig deeper in that
[19:59] <davmor2> cyphermox: oh hang on of course this box is on saucy still I'll give it a go in trusty after I set my box up again
[19:59] <cyphermox> well I saw the same on trusty
[20:00] <davmor2> cyphermox: at least it actually refreshes though it didn't before on adding or removing files so +1 :)
[20:05] <robru> cjwatson, can I get you to push unity8 through proposed pretty please?
[20:10] <cyphermox> davmor2: confirmed that this is a limitation in gvfs -- I can fix now :)
[20:26] <bfiller> robru: landing-009 has been building for like 8 hours it seems
[20:26] <robru> hmm
[20:27] <bfiller> robru: don't think it's trying to rebuild oxide, but if it is that might explain it
[20:27] <bfiller> should just be building webbrowser-app
[20:28] <robru> bfiller, no, it looks like it's stuck in depwait for ppc64el, powerpc, and arm64.
[20:28] <robru> bfiller, precisely because oxide is unavailable there
[20:28] <robru> bfiller, the other arches are done building if you want to do some testing there
[20:29] <bfiller> robru: should we change webbrowser app so it doesn't try to build on those arches? don't think oxide supports those yet
[20:29] <robru> bfiller, that's fine by me
[20:29] <robru> bfiller, you might want to consult cjwatson about this though, he knows more about it and also bringing up those arches seems to be his personal mission
[20:31] <pmcgowan> bfiller, we should not support those arches anyway
[20:31] <pmcgowan> bfiller, none of our apps should target them
[20:31] <pmcgowan> was just wondering why that silo was still building
[20:32] <pmcgowan> well arm64 is ok
[20:32] <bfiller> robru: right, cjwatson webbrowser-app previously built on all the arches, but we're pushing a new version that using oxide backend instead of qtwebkit. oxide only builds for 3 arches
[20:33] <robru> bfiller, oh right, I forgot this is technically a regression. so yeah, we need cjwatson to clear the previous binaries out so that it allows us to not build on those arches
[20:33] <bfiller> pmcgowan: the apps don't target them specifically, but if arch set to "any" then it tries to build them if it has previosly
[20:38] <pmcgowan> bfiller, right, we should call out the specific ones we care about
[20:51] <bfiller> robru what's the syntax for specifying multiple specific arches in debian/control?
[20:51] <robru> bfiller, one sec
[20:53] <robru> bfiller, here's an example: https://code.launchpad.net/~bregma/unity8-desktop-session/restrict-target-arches/+merge/208397
[20:53] <robru> line 17 of the diff
[20:53] <boiko> robru: landing-008 tested and ready
[20:57] <bfiller> robru: thanks
[20:57] <robru> boiko, great!
[20:58] <robru> bfiller, you're welcoe
[20:58] <boiko> robru: you can leave my other request unassigned for now to not lock any silo (as I will only be able to build and test it tomorrow)
[20:59] <robru> boiko, ok, just don't set it 'yes' then
[20:59] <boiko> robru: well, it is ready, it is just that I am finishing my working day already :)
[20:59] <boiko> robru: I will set it to No and then tomorrow morning I set it to yes again
[20:59] <robru> boiko, ok :-P
[20:59] <robru> yes please
[20:59] <robru> thanks
[21:00] <boiko> :)
[21:00] <rsalveti> plars: robru: not sure if anyone wants to debug that: http://162.213.34.102/job/landing-007-1-build/60/console
[21:00] <rsalveti> Connection failed, aborting. Check your network [Errno -3] Temporary failure in name resolution
[21:00] <rsalveti> Traceback (most recent call last):
[21:00] <rsalveti>   File "/var/lib/jenkins/citrain/citrain
[21:00] <rsalveti> just triggered another rebuild
[21:01] <robru> rsalveti, yeah, sometimes the network is flaky, just rebuild
[21:01] <plars> retoaded: have you seen a lot of those lately?
[21:01] <plars> rsalveti: yeah, let me know if it happens again
[21:01] <rsalveti> sure, thanks
[21:01] <retoaded> plars, haven't seen many at all here lately.
[21:01] <robru> plars, i see it once a week maybe. not a huge problem, retry always works for me
[21:02] <retoaded> plars, I don't believe that jenkins instance uses the labs network infrastructure though.
[21:12] <Saviq> hmm robru, can you explain this failure http://162.213.34.102/job/landing-004-1-build/83/console ?
[21:13] <Saviq> ah maybe I know
[21:13] <robru> Saviq, this is due to having unity8 in more than one silo at a time
[21:13] <Saviq> robru, oh
[21:14] <robru> Saviq, in particular there's a version of unity that's in the archive, and not been merged yet.
[21:14] <Saviq> robru, right, we have one stuck in proposed...
[21:14]  * Saviq forces then
[21:14] <Saviq> it's a prelim silo anyway
[21:14] <robru> Saviq, yeah I guess force for now, but you will have to rebuild once that other one does merge & clean
[21:15] <Saviq> robru, of course
[21:15] <robru> ok
[21:23] <bfiller> robru: can you kill the build on silo 9? I'm going to reconfigure with a new MR that restricts the arches
[21:23] <robru> bfiller, ok
[21:56] <rsalveti> jhodapp|bbl: hm, you merged gst 1.2.3 in your branch
[21:56] <rsalveti> jhodapp|bbl: would be better if you could rebase your changes instead
[21:56] <rsalveti> otherwise it's a pita to know what really changed
[21:56] <rsalveti> with a rebase I can only do git diff <last-known-hash-from-upstream>..
[21:56] <rsalveti> and create the diff needed by our package
[21:57] <rsalveti> now I need to create another branch just with upstream
[21:57] <rsalveti> and compare both branches
[22:04] <cyphermox> davmor2: fixed the case for pictures showing up in MTP now :D
[22:20] <jhodapp> rsalveti, ok I'll keep that in mind going forward, had no idea it'd impact your part of the process since I didn't know exactly how you do things to push my changes
[22:20] <rsalveti> jhodapp: yeah, no worries, did a diff from upstream..master
[22:20] <rsalveti> jhodapp: seems it worked fine
[22:20] <rsalveti> jhodapp: it's also easier when upstreaming the changes
[22:20] <jhodapp> rsalveti, thank you, sorry for the extra trouble
[22:20] <rsalveti> as you just check whatever is on top
[22:21] <rsalveti> no worries
[22:21] <jhodapp> rsalveti, yeah, just my inexperience with git
[22:21] <rsalveti> yeah, it's almost impossible to do a rebase with bzr
[22:21] <rsalveti> but with git is so easy :-)
[22:23] <jhodapp> rsalveti, so you want rebase so that it mixes the upstream history with mine and keep things as distinct commits, right?
[22:23] <jhodapp> rsalveti, btw, the tests all pass for me but I see that it's failing on amd64
[22:23] <rsalveti> jhodapp: yeah, just upstream + your patches on top
[22:24] <rsalveti> hm, mediahub here failed for amd64, i386 and armhf
[22:24] <rsalveti> https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+packages
[22:24] <jhodapp> thanks, was looking for that link again
[22:24] <jhodapp> it fails for everything, crap
[22:25] <jhodapp> that output isn't that helpful as it just segfaults
[22:27] <jhodapp> rsalveti, oh hey, I just ran it in a schroot on amd64 and it segfaulted, so it's most likely the same thing
[22:27] <rsalveti> yeah
[22:29] <jhodapp> rsalveti, it's because it's trying to call into libhybris
[22:30] <bfiller> robru: landing 1 ready for release
[22:30] <rsalveti> jhodapp: right, thought it could be that
[22:30] <rsalveti> jhodapp: so we either need to change the test to not do that, or simulate the hybris environment
[22:30] <robru> bfiller, great
[22:30] <rsalveti> as it needs to be tested in the builder
[22:31] <rsalveti> jhodapp: gst-plugins-bad should be in the ppa in a few minutes
[22:31] <jhodapp> rsalveti, well I'm in the process of rewriting/updating the tests for everything, so for now so we can get a test image, I'm going to disabled them
[22:37] <robru> bfiller, just getting a core dev ack on the packaging changes
[22:37] <bfiller> robru: np
[22:42] <jhodapp> rsalveti, try the build again
[22:42] <rsalveti> jhodapp: alright
[22:43] <rsalveti> doing a rebuild
[22:43] <jhodapp> rsalveti, it makes sense that the tests passed for me on arm...it's an actual device :)
[22:43] <rsalveti> jhodapp: right :-)
[22:44] <jhodapp> rsalveti, I'm definitely going to have to do some libhybris mocking
[22:48] <jhodapp> rsalveti, be back in about 20 mins to check on the build
[23:15] <robru> ogra_, hey what's going on in line 43?
[23:16] <ogra_> nothing until you have a free silo for it :)
[23:16] <robru> ogra_, it's not filled out right though.
[23:16] <ogra_> what is missing ?
[23:17] <robru> ogra_, if you're just doing a source package upload, put the source package name in the source package column. your MP list is invalid
[23:17] <ogra_> you mean in the "additional" source packages ?
[23:18] <ogra_> i kind of thought it was for additional packages :)
[23:19] <robru> ogra_, it's for anything that isn't an MP...
[23:19] <robru> ogra_, ok you got silo 7
[23:20] <jhodapp> rsalveti, looks like media-hub passed now except for those 3 more obscure architectures due to missing libhybris-dev for those architectures
[23:20] <ogra_> robru, merci
[23:20] <robru> ogra_, you're welcome
[23:20] <robru> jdstrand, did you want a silo for line 40? it looks ready but you didn't mark 'ready: yes'
[23:22] <robru> bfiller, do you want a silo for line 42? looks ready but you didn't mark 'ready: yes'
[23:22] <jhodapp> rsalveti, and why couldn't qtubuntu-media find libmedia-hub-dev, it should be getting created
[23:22] <bfiller> robru: not yet, waiting to add another MR first
[23:22] <robru> bfiller, ok no worries
[23:30] <jhodapp> robru, how is the build order of MRs in a silo PPA determined?
[23:31] <robru> jhodapp, the MR's are merged in the order they're listed, but the build order is determined by python-dictionary-access-order, eg, random-but-repeatable.
[23:32] <jhodapp> robru, ok, because it almost seems like media-hub was built after qtubuntu-media in this landing ppa: https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+packages
[23:33] <jhodapp> robru, but that's not good because qtubuntu-media needs libmedia-hub-dev
[23:34] <robru> jhodapp, well it's entirely possible. if you need to specify a build order, then you should clarify the build dependencies in debian/control (eg, specify that one thing needs a specific new version of another thing). then the builds will happen in the right order.
[23:34] <jhodapp> robru, ok, so I'm not sure what version will result since this is the very first time media-hub has been built (my packaging foo is not strong)
[23:35] <jhodapp> robru, nevermind, scratch that
[23:35] <robru> jhodapp, just use whatever version number exists in the PPA already, but say > than that number
[23:36] <jhodapp> yeah ok
[23:37] <jhodapp> robru, could you kick that landing ppa for me again?
[23:37] <robru> jhodapp, you  mean the build job?
[23:38] <jhodapp> yeah
[23:38] <robru> jhodapp, which silo?
[23:38] <jhodapp> 006
[23:40] <robru> jhodapp, ok, building
[23:40] <jhodapp> thanks
[23:44] <robru> jhodapp, you're welcome
[23:55] <cjwatson> robru: unity8> done
[23:56] <robru> cjwatson, thank you!
[23:56] <cjwatson> bfiller: if you listed specific arches in webbrowser-app's debian/control, please revert that.  it's quite unnecessary
[23:57] <cjwatson> pmcgowan is technically wrong on this :)
[23:59] <cjwatson> bfiller,robru: I've removed qtdeclarative5-ubuntu-ui-extras-browser-plugin webapp-container webbrowser-app from arm64/powerpc/ppc64el on trusty, so nothing should block on that any more
[23:59] <robru> cjwatson, oh excellent, thanks again
[23:59] <robru> cjwatson, bfiller is probably EOD, I'll email him