=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
[02:05] <imgbot> === IMAGE 90 building (started: 20150205-02:05) ===
[03:05] <imgbot> === IMAGE RTM 227 building (started: 20150205-03:05) ===
[03:30] <imgbot> === IMAGE 90 DONE (finished: 20150205-03:30) ===
[03:30] <imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/90.changes ===
[04:25] <imgbot> === IMAGE RTM 227 DONE (finished: 20150205-04:25) ===
[04:25] <imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/227.changes ===
[05:42] <bzoltan> where my MRs went from the "Landing documentation" cell of the CI sheet
[05:42] <bzoltan> Mirv: robru ^
[05:43] <bzoltan> I reentered
[05:54] <robru> bzoltan: hm?
[05:56] <robru> bzoltan: do you have a silo you want assigned? i don't see it
[06:03] <bzoltan> robru:  I am ready to release the silo23
[06:05] <bzoltan> robru:  hmm... ci sheet is playing with me
[06:05] <bzoltan> now it is OK
[06:06] <Mirv> bzoltan: someone pressed delete accidentally?
[06:07] <bzoltan> Mirv:  I have seen few times that when my local sheet gets out of sync it pushes changes I do not intend once the net comes back.
[06:09] <Mirv> bzoltan: google does that too.. sometimes waiting more helps, sometimes not
[06:12] <bzoltan> Mirv: yes... Strange that there is no notification abuut that line here. WOuld you publish the silo23 please?
[06:13] <Mirv> bzoltan: done.
[06:19] <bzoltan> Mirv: thanks
[06:26] <Mirv> hmm, where did the queuebot go..
=== marcust__ is now known as marcustomlinson
[07:02] <Mirv> and it's back
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
[07:35] <fginther> robru, the problem with doing POST requests is that the entity doing the POST must also supply credentials as part of the request.
[07:36] <robru> fginther: right, thanks
[07:37] <fginther> robru, oh, you're still awake :-)
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
[08:02] <robru> fginther: only barely. goodnight!
[08:24] <kgunn> trainguards can i get reconfig on vivid silo 0
[08:24] <kgunn> please
[08:37] <bzoltan> Mirv:  I would need a vivid silo for a super important QtC hot fix
[08:38] <Mirv> bzoltan: ok
[08:38] <Mirv> kgunn: ok
[08:39] <Mirv> kgunn: something funky again with reconfiguring
[08:40] <Mirv> kgunn: what's the idea of having "sync:ubuntu/vivid qtsystems-opensource-src" for a vivid silo?
[08:42] <Mirv> kgunn: seems to work by removing the sync part of it
[08:43] <Mirv> kgunn: now done
[10:03] <satoris> ping cihelp, what seems to be going wrong here (this is my first SRU, so the package setup might be wrong): https://ci-train.ubuntu.com/job/ubuntu-landing-020-1-build/82/console
[10:04] <vila> satoris: trainguards should work better for that
[10:04] <sil2100> satoris: let me take a look in a moment
[10:05] <satoris> Thanks.
[10:38] <popey> jibel: so was that a "yes" or "no" to adding music to the trello? :)
[10:39] <jibel> popey, it's added to the trello
[10:39] <popey> thank you!
[10:46] <Saviq> Mirv, we had the sync: for libevdev (new dependency, just want to make the silo citrain-tool-friendly), sorted that out already and dropped the sync: again
[10:46] <Saviq> just FYI
[10:46] <Saviq> Mirv, oh, and welcome back!
[10:47] <Mirv> Saviq: thanks!
=== alan_g is now known as alan_g|reboot
[10:50] <sil2100> satoris: interesting failure, need to take a look if there's anything wrong with the 14.04 chroot, but so far it seems you're doing everything alright
[10:52] <sil2100> satoris: oh, no, wait
[10:58] <sil2100> satoris: ok, found the problem
[10:58] <sil2100> satoris: so, it seems the lp:thumbnailer/trusty branch is not train ready
[10:59] <sil2100> satoris: you are missing the .bzr-builddeb/default.conf with the split option there
[11:00] <sil2100> satoris: this basically means that when the train tries to build your package, it does not generate a new tarball off from your source code (which it has to do) because of this missing config file
[11:00] <sil2100> satoris: best if you add it to your merge
[11:00] <sil2100> And then rebuild
[11:03] <pstolowski> trainguards hello, could you please reconfigure rtm-landing-002 (new project added)?
[11:08] <sil2100> pstolowski: sure
[11:10] <sil2100> pstolowski: done
[11:13] <pstolowski> thanks
[11:39] <satoris> sil2100: check, the file is in trunk but for some reason not in that branch. Fixing.
=== MacSlow is now known as MacSlow|lunch
[12:25] <mzanetti> sil2100: mind reconfiguring silo vivid/000 for us please?
[12:26] <sil2100> mzanetti: no problem
[12:26] <mzanetti> ta
[12:27] <sil2100> mzanetti: wow, getting bigger and bigger ;)
[12:30] <sil2100> mzanetti: done
[12:32] <mzanetti> sil2100: thanks. yes, it's getting bigger and bigger, but its *awesome* :D
[12:44] <sil2100> lool: hey! Did you upgrade or remove the terminal-app from the ubuntu-rtm custom tarball for mako by any chance?
=== alan_g is now known as alan_g|lunch
[12:52] <bzoltan> sil2100:  would you be so kind to publish the silo3, please?
[12:52] <sil2100> Oh! Missed it, on it now
[12:56] <sil2100> lool: from what I see that didn't happene yet - if you could do any of the two in the nearest time it would be most awesome ;)
=== chihchun_afk is now known as chihchun
[13:06]  * sil2100 off to lunch
[13:17] <Mirv> kenvandine: seb128: I heard you had been asking for newer qtsystems-opensource-src? it also removes StorageInfo class, would you want to land ubuntu-system-settings together with it, or alternatively if I'd land the new qtsystems as part of Qt 5.4 maybe do a build time check for 5.4 instead?
[13:18] <seb128> Mirv, no strong preference, whatever works best for you
[13:18] <davmor2> seb128: I'll sort you out a log after lunch
[13:18] <seb128> davmor2, thanks
[13:19] <davmor2> seb128: I'm just running through qt5.4 to see waht is broken by it currently so there might be a few more but that looks like the only view broken in uss
[13:19] <seb128> davmor2, k
[13:20] <Mirv> seb128: kenvandine: well then I could include the ubuntu-system-settings MP in the Qt 5.4 silo.
[13:21] <seb128> Mirv, is there one or does somebody needs to work on that?
[13:21] <Mirv> seb128: the silo is ready for all practical developer purposes https://wiki.ubuntu.com/Touch/QtTesting
[13:21] <seb128> Mirv, included u-s-s changes or is that todo?
[13:22] <Mirv> seb128: oh, that, I only know u-s-s is broken by new qtsystems so yes it's a todo. I thought since you had requested new qtsystems you might know already what needs to be changed in the About page.
[13:23] <seb128> Mirv, no, but I can have a look, we requested it because the battery changes stopped to be reported with the new upower
[13:24] <Mirv> seb128: oh, ok. thanks if you could have a look at that bug then!
=== alan_g|lunch is now known as alan_g
[13:43] <davmor2> seb128: hahaha, of course I would love to to get you logs unfortunately the developer mode switch is in the about the phone page ;)  I'll see if it is still enabled :)
[13:44] <Mirv> davmor2: it is after simply updating the PPA :) I got the log now to the u-s-s bug because I updated the qtsystems build in the PPA and wanted to make sure it looked same still (yes it did)
[13:45] <Mirv> so yes, the u-s-s fix needs to go with Qt 5.4 since the replacement for what was removed from qtsystems is only available in qtbase 5.4
[13:46] <davmor2> Mirv: nice, I added a before log for seb128 so he can see the difference then :)
[13:47] <Mirv> actually, that might need something a bit extra... if the new class is in qtbase, that means there's nothing for QML
[13:47] <Mirv> anyhow, that's how it is, the feature is gone
=== marcusto_ is now known as marcustomlinson
[14:13] <Laney> Mirv: do you know anything about this change in particular?
[14:14] <Laney> looks like StorageInfo::DeviceType has no equivalent now ...
[14:14] <Laney> or DriveType or whatever it's called
=== MacSlow|lunch is now known as MacSlow
[14:32] <Mirv> Laney: no, I don't know anything particular, other than qtsystems is not supported by upstream so they are free to also remove features
[14:34] <Laney> bleh
[14:35] <dbarth> trainguards, hey, can i get a new rtm silo on line 65 ?
[14:36] <Mirv> davmor2: done
[14:38] <dbarth> thanks
=== marcusto_ is now known as marcustomlinson_
=== marcustomlinson_ is now known as marcustomlinson
[15:08] <pstolowski> trainguards hey, could you please purge unity-scopes-api from rtm-002 (we've reconfigured the silo and rebuilt without it, but it still in the ppa)
[15:08] <sil2100> pstolowski: on it!
[15:08] <sil2100> pstolowski: yeah, we have a bug for that
[15:08] <pstolowski> sil2100, thanks!
[15:20] <kenvandine> rvr, don't forget to mark silo 3 as verified on the spreadsheet :)
[15:20] <rvr> kenvandine: I'm on it :)
[15:20] <kenvandine> rvr, thx :)
[15:21] <rvr> kenvandine: Your silo is approved. Make sure the strings get to in Launchpad for translation in RTM.
[15:23] <kenvandine> rvr, i don't think i need to do anything for that
[15:23] <kenvandine> or maybe i do... i can't remember :)
=== slangase` is now known as slangasek
=== marcusto_ is now known as marcustomlinson_
[16:59] <Chipaca> trainguards, at your earliest convenience please to publish silo #7 / row 58
[17:10] <robru> Chipaca: done
[17:11] <Chipaca> robru: thanks muchly
[17:11] <robru> Chipaca: you're welcome
=== chihchun is now known as chihchun_afk
[17:52] <brendand> robru, hey about that silo diff code
[17:53] <brendand> robru, we've been finding out recently that part of the diff is inaccurate for some reason, might be something to check out if you're going to make it a part of the citrain itself
[17:54] <brendand> robru, it's the debian/changelong that is wrong, for some reason it ends up with extra content
[17:54] <brendand> i'm not sure why
[17:55] <pstolowski> trainguards hey, the branches from silo 8 are now all be approved and it should be ok to publish
[17:55] <sil2100> brendand: hey! Still around?
[17:56] <brendand> sil2100, yes :)
[17:56] <brendand> sil2100, i've not disappeared
[17:57] <sil2100> brendand: excellent - so I have prepared some changes to the old spreadsheet to enable tracking of click/tarballs
[17:58] <brendand> sil2100, yeeees
[17:58] <sil2100> brendand: every entry will get an UID after a landing team member approves it - and I decided that the magic string of [non-citrain] will be present in the comments field (can be inside of the string)
[17:58] <brendand> sil2100, ok. i think we might need to co-ordinate a bit on pushing these changes
[17:59] <brendand> sil2100, can we try and do that tomorrow, or some other time not today?
[17:59] <sil2100> Tomorrow seems fine
[18:19] <robru> brendand: wrong in what way? like stuff appears in the diff that doesn't appear in the uploaded package? or the changelog is just wrong all around.
[18:20] <robru> brendand: changelog generation code is known to be pretty horrible...
[18:21] <robru> mterry: kenvandine: anybody around for a packaging ack? https://ci-train.ubuntu.com/job/ubuntu-landing-008-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-scopes-api_0.6.13+15.04.20150205.1-0ubuntu1.diff/*view*/
[18:21] <jdstrand> dbarth: ok, I added apparmor-easyprof-ubuntu to line 65 of the spreadsheet (rtm silo 000). I'll prepare a package and get it in there a bit later
[18:24] <dbarth> jdstrand: thank you!
[18:29] <boiko> robru: silo 13 is showing some packaging changes in dbus-test-runner?!?!
[18:32] <robru> boiko: https://ci-train.ubuntu.com/job/ubuntu-landing-013-2-publish/lastSuccessfulBuild/artifact/packaging_changes_dbus-test-runner_15.04.0+15.04.20150116-0ubuntu1.diff/*view*/ looked pretty trivial to me
[18:34] <boiko> robru: the thing is, there was no dbus-test-runner on the silo :)
[18:44] <robru> boiko: was there previously?
[18:44] <boiko> robru: you mean since I got the silo? nope
[18:44] <robru> boiko: yeah, like did you add it and then remove it or something. guess not
[18:45] <robru> boiko: k, i have no idea where that diff came from, but at least the packagelist looks sane: https://ci-train.ubuntu.com/job/ubuntu-landing-013-2-publish/lastSuccessfulBuild/artifact/packagelist_rsync_landing-013-vivid/*view*/ this means that dbus-test-runner wasn't actually published with the silo, so nothing to worry about.
[18:45] <robru> boiko: did you have this silo since before last friday? could be a glitch from the new production rollout.
[18:46] <boiko> robru: yes, I have it since before the update
[18:47] <boiko> robru: but ok, if it was not published I guess it is fine
[18:47] <robru> boiko: yep, not even in the PPA either. just some inconsistent state in the jenkins server somehow. my only guess would be a glitch when syncing silo contents from the old server to the new one but I'm not sure how it would happen.
[18:48] <brendand> robru, well stuff appears in the changelog that is *already* in the uploaded package
[18:50] <robru> brendand: but like, the changelog as it appears in the upload matches the changelog as it appears in the diff right? the diff is accurate, it's just the changelog that's wrong?
[18:51] <brendand> robru, seems to be just the changelog - the changes that are mentioned in the changelog don't appear in the diff
[18:51] <mterry> robru, looking at that packaging diff...
[18:51] <mterry> robru, python-tornado got added?  for tests?
[18:52] <robru> mterry: no idea ;-)
[18:52] <mterry> robru, who do I ask about that?  (I'd also like to advocate to them to use python3-tornado if possible)
[18:53] <robru> mterry: that would be pstolowski
[18:53] <mterry> robru, I don't like this method of packaging-ack -- it's so far after the MPs land, if there is a suggestion like this, it's a pain to correct, so I feel like I should just say OK and fix it in post
[18:53] <robru> mterry: but the MP didn't land? this ack is pre-publication
[18:54] <mterry> robru, well but it's post silo-bundling.  Which is a bunch of work that someone has already done -- and blocking one change like this blocks the rest of the silo.  Vs at MP-review time
[18:54] <robru> brendand: sounds like you're describing http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/view/head:/citrain/build.py#L547 this... thing. I will be touching that code today but I'm not really sure how to improve upon that in particular.
[18:55] <robru> mterry: I agree, it's definitely suboptimal. I'm going to be making some changes today that makes the diffs appear at build time rather than publish time, so maybe that can alleviate your worries. other than that I'm not sure how we'd get core dev acks pre-build.
[18:57] <mterry> robru, if we were pulled in at MP time.  Just have the project not pre-approve anything that touches debian/ until a dev reviews
[18:57] <mterry> *top-approve
[18:57] <kenvandine> so maybe a packaging ack before the MP is approved
[18:57] <kenvandine> before the silo
[18:57] <robru> mterry: that's something you'd have to work out at a per-project level though. the train doesn't enforce top approving MPs until publish time.
[18:58] <robru> mterry: like, the train has no way to enforce any sort of policy *before* you get a silo ;-)
[18:58] <mterry> robru, but I could imagine at the same time it enforced top-approving, it could check that there was an approved review labelled "packaging" -- if projects new they'd be rejected unless they had that...  they'd make it happen at MP time
[18:59] <mterry> *knew
[18:59] <kenvandine> it would be to their best interest anyway
[18:59] <robru> kenvandine: agreed, but the issue is how can we communicate that to them.
[18:59] <kenvandine> knowing if the packaging got nack'd would mean more work later
[18:59] <kenvandine> understand
[19:00] <kenvandine> i just think mterry has a good point
[19:00] <kenvandine> a nack after all the time has been spent getting through silo testing
[19:00] <kenvandine> just to have to redo all that
[19:00] <kenvandine> kind of sucks
[19:00] <robru> mterry: kenvandine: i agree with your points, I think you should raise this with slangasek and we can schedule a more in depth meeting on the topic. right now I'm sort of just putting out fires and can't really change this behavior today.
[19:00] <mterry> It's a lot of (silent) social pressure on the reviewer to approve
[19:00] <kenvandine> robru, understood
[19:01] <mterry> robru, sure didn't mean to add to your load  :)
[19:01] <kenvandine> i know i feel the same way, i feel bad giving a nack
[19:02] <kenvandine> although, i haven't found many i wanted to nack though
[19:02] <robru> kenvandine: yeah I hear you, I've also felt that pressure even just asking for acks, especially in rtm, it's like "qa just spent 3 hours verifying this, don't you dare nack it"
[19:02] <mterry> robru, as for that review itself, I mean, sure.  It doesn't seem to be doing anything insane, so ACK.  But I would like to converse with pstolowski when he's around
[19:02] <robru> mterry: thanks.
[19:02] <mterry> kenvandine, but just a conversation point -- things that aren't so bad as to NACK but should be fixed ideally
[19:03] <kenvandine> indeed
[19:09] <robru> mterry: kenvandine: https://bugs.launchpad.net/cupstream2distro/+bug/1418699 filed a bug for you guys
[19:09] <ubot5> Launchpad bug 1418699 in CI Train [cu2d] "Packaging ACK workflow is sub-optimal." [Undecided,New]
[19:10]  * mterry hugs robru
[19:10] <robru> ;-)
[19:14] <jdstrand> dbarth: fyi, I uploaded apparmor-easyprof-ubuntu to rtm silo 000 and it successfully built, but the silo needs to be configured
[19:14] <jdstrand> dbarth: I tried to do it myself but it failed
[19:14] <jdstrand> ERROR apparmor-easyprof-ubuntu was not in the initial list of components for that silo. Please ask the trainguards to reconfigure this silo for you.
[19:14] <jdstrand> seems I used to be able to do that...
[19:15] <jdstrand> s/configured/reconfigred/
[19:15] <robru> jdstrand: you're a core dev right? you should be able to reconfigure. the error you quoted is from the build job though
[19:15] <robru> or, wait...
[19:15] <jdstrand> I am
[19:15] <jdstrand> I'm not the lander though... perhaps that is the issue?
[19:16] <jdstrand> robru: yes, that is from the console output
[19:16] <jdstrand> robru: I clicked the Reconfigure link from the spreadsheet and it took me to a page that had 'Build' at the bottom
[19:16] <robru> jdstrand: oh right. you have permission to do this you're just calling the wrong job.
[19:16] <jdstrand> everything looked ok in that jenkins page, so I tried
[19:16] <dbarth> so you can reconfig the silo?
[19:17] <dbarth> (i don't have the rights for adding new branches myself)
[19:17] <robru> jhodapp: the 'reconfigure' link is the unpriviledged one that non-core-devs use, it doesn't let you add packages. you should go to the 'landing team tools -> assign silo' menu and it'll do a super-reconfigure for you
[19:17] <robru> jdstrand: ^
[19:17] <robru> jhodapp: unping, sorry
[19:17] <jdstrand> robru: ok, looking
[19:18] <jdstrand> robru: where are landing team tools?
[19:19] <jdstrand> I feel like I have done this before...
[19:19] <robru> jdstrand: in the menubar right next to 'help'
[19:19] <jdstrand> ah
[19:20] <robru> jdstrand: just make sure you select a cell on the row you want to reconfigure before clicking that, and it should do the right thing
[19:20] <jhodapp> robru, np :)
[19:21] <robru> stupid j<tab> completing the wrong name ;-)
[19:23] <robru> jdstrand: got it working? it should pop up a little dialogue confirming which spreadsheet row you're acting on, then a link that says 'click here then click build' or something like that.
[19:23] <jdstrand> robru: yes, seems to have worked
[19:23] <robru> cool
[19:23] <jdstrand> Finished: SUCCESS
[19:23] <jdstrand> robru: thanks!
[19:24] <robru> jdstrand: you're welcome
[19:24] <jdstrand> that's what I was looking for ^
[19:24] <jdstrand> dbarth: ok, I think we are in business
[19:24] <jdstrand> dbarth: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=landing-000
[19:25]  * jdstrand is performing the build step now
[19:27]  * jdstrand is working to fix that ^
[19:28] <robru> that's curious, I'm not sure why it would report that error *after* reporting it was ready to build. seems out of order
[19:28] <jdstrand> I went to tht ebuild step and put apparmor-easyporf-ubuntu in the list to rebuild with watch only
[19:28] <robru> rather, it *is* out of order, I'm just not sure how it got that way
[19:28] <jdstrand> that was a mistake
[19:29] <jdstrand> so now I'm building with only watch only
[19:29] <robru> jdstrand: oh I see, yes "rebuild" and "watch" are mutually exclusive. that makes more sense.
[19:29] <robru> jdstrand: I was thinking that status was a stale leftover from when you were having trouble reconfiguring.
[19:31] <dbarth> jdstrand: sweet !
[19:32] <dbarth> i'll take the silo for testing tomorrow morning, thanks for adding the package
[19:36] <jdstrand> ok, everything look ok now. the job was successful, the bot picked it up, just the spreadsheet and the dashboard need to catch up
[19:45] <davmor2> pmcgowan: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1418707 this may not be unity8 but I thought it a reasonable place to start :)
[19:45] <ubot5> Launchpad bug 1418707 in unity8 (Ubuntu) "Vivid Random lockups" [Undecided,New]
[19:46] <pmcgowan> davmor2, we always blame unity8, kgunn  lovers that
[19:46] <pmcgowan> loves even
[19:49] <davmor2> pmcgowan: I blame Saviq for most things anyway and when it's not his fault it is normally ogra_ 's it's winds up getting sorted in the end, this time though I think it is lower in the stack to be honest it's too random and on too many things for it to just be unity8 but it is a good start point, I think you might be onto something with a hal/dbus issue possibly
[19:50] <pmcgowan> davmor2, need to chat with rsalveti on that
[19:50]  * rsalveti reading
[19:50] <rsalveti> it's probably unity8 :P
[19:51] <davmor2> rsalveti: yeah blame Saviq ;)
[19:51] <rsalveti> davmor2: is it locking up completely?
[19:51] <rsalveti> I mean, can you see unity8 after pressing power coming from a suspended phone?
[19:51] <rsalveti> is the clock stuck
[19:52] <rsalveti> because I got some serious lock ups with rtm as well
[19:53] <rsalveti> davmor2: also, could you use adb normally?
[19:53] <davmor2> rsalveti: clock has been stuck, and clock missing from the welcome screen,  apps randomly stop functioning and eventually close, scopes will stop taking input and the scope will restart or unity8 will and so on
[19:53] <rsalveti> oh, sounds like it's quite broken indeed
[19:53] <davmor2> rsalveti: it's completely random as to what dies and when
[19:53] <rsalveti> davmor2: is that only happening with qt 5.4?
[19:54] <rsalveti> davmor2: got your syslog?
[19:54] <davmor2> rsalveti: no mako had no QT5.4 and was doing the same
[19:54] <davmor2> rsalveti: that's the weird thing there isn't much showing up anywhere
[19:54] <davmor2> let me grab logs for you
[19:55] <rsalveti> right, guess I'd need to use and see what happens
[19:55] <rsalveti> phablet@ubuntu-phablet:~$ ifconfig
[19:55] <rsalveti> h�ؾ(��
: error fetching interface information: Device not found
[19:55] <rsalveti> that's interesting
[19:55] <rsalveti> vivid/mako
[19:55] <rsalveti> cyphermox: ^
[19:55] <davmor2> yeah crazy crap like that :)
[19:56] <davmor2> rsalveti: that might be because the sim stuff is totalled maybe
[19:58] <davmor2> rsalveti: adding syslog from mako (none Qt5.4) now
[19:58] <cyphermox> yikes
[19:59] <cyphermox> rsalveti: so something gets borked on the system at a very low level
[19:59] <rsalveti> yeah
[19:59] <pmcgowan> rsalveti, could there be some mismtach between rootfs and android hal stuff
[19:59] <rsalveti> ioctl(4, SIOCGIFCONF, {96, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"wlan0", {AF_INET, inet_addr("192.168.1.61")}}, {"h���", {AF_INET, inet_addr("191.18.192.182")}}}}) = 0
[19:59] <cyphermox> is that always the case on mako, latest image or just on your system?
[19:59] <rsalveti> ioctl(4, SIOCGIFADDR, {ifr_name="dummy0", ???}) = -1 EADDRNOTAVAIL (Cannot assign requested address)
[19:59] <rsalveti> ioctl(5, SIOCGIFFLAGS, {ifr_name="h���", ???}) = -1 ENODEV (No such device)
[19:59] <rsalveti> write(2, "h\244\367\276: error fetching interface i"..., 61h���: error fetching interface information: Device not found
[20:00] <rsalveti> yeah, just installed latest on mako + apt-get update/upgrade
[20:00] <cyphermox> any changes to android?
[20:00] <rsalveti> cyphermox: nops
[20:00] <rsalveti> for months
[20:00] <cyphermox> kernel then?
[20:00] <rsalveti> pmcgowan: nothing really changed
[20:00] <cyphermox> I don't see why else you'd have an interface with a corrupt name
[20:00] <rsalveti> latest kernel change happened on jan 20
[20:01] <davmor2> rsalveti: krillin syslog attached too
[20:01] <cyphermox> ifconfig doesn't work, but does ip link ?
[20:01] <rsalveti> cyphermox: yes: http://paste.ubuntu.com/10078645/
[20:01] <rsalveti> davmor2: thanks
[20:01] <rsalveti> let me reflash latest
[20:02] <cyphermox> wow
[20:02] <cyphermox> so something got broken in ifconfig
[20:03] <rsalveti> usual whoopsie respawn
[20:03] <rsalveti> this needs to be fixed asap
[20:04] <cyphermox> hrm, no recent change to net-tools
[20:04] <rsalveti> yeah, reflashing to make sure
[20:04] <cyphermox> it must have been a bad flash, I see no other reason\
[20:08] <davmor2> rsalveti, cyphermox: it could always be part of the issues that I have been fighting all day :)
[20:10] <rsalveti> cyphermox: nah, latest mako, flashed with --bootstrap, same issue
[20:11] <rsalveti> mako v90 vivid
[20:11] <rsalveti> let me first revert this annoying whoopsie change
[20:12] <davmor2> rsalveti: my ifconfig looks quite normal :(
[20:13] <rsalveti> davmor2: weeerrid
[20:13] <davmor2> rsalveti, cyphermox: http://paste.ubuntu.com/10078785/
[20:14] <rsalveti> yeah, wonder if that might be might device somehow
[20:14] <rsalveti> but nothing really changed here
[20:14] <rsalveti> will flash another image and see
[20:14] <rsalveti> rtm should be working
[20:15] <davmor2> rsalveti: did you see anything interesting in the syslogs by the way?
[20:16] <rsalveti> davmor2: nothing major, no
[20:16] <davmor2> rsalveti: I'm off tomorrow but jibel has had a similar experience with his mako on vivid today
[20:17] <rsalveti> davmor2: sure, will give it a try and see
[20:17] <rsalveti> we need to get vivid to work
[20:17] <rsalveti> boiko: any news for silo 9?
[20:18] <rsalveti> just before you go EOD, wanted to land this today still
[20:21] <boiko> rsalveti: back from coffee, silo 13 landed, let me rebuild telephony-service
[20:21] <rsalveti> great, thanks
[20:41] <dobey> cihelp: can we get autopilot tests enabled for MPs to lp:pay-ui in the same way we have for lp:unity-scope-click? lp:pay-ui has a "make autopilot" target to run them. thanks.
[20:45] <rsalveti> tedg: what are we missing still in order to be able to land silo 3?
[20:49] <cyphermox> rsalveti: in that case I'll flash my mako now see if I get that too
[20:50] <tedg> rsalveti, I haven't gotten to testing it yet
[20:50] <rsalveti> tedg: alright, will give it a try
[20:50] <rsalveti> really wanted to land that as well
[20:50] <tedg> I am too. :-)
[20:51] <tedg> rsalveti, Just FYI, I can still break it in a couple cases, but this makes the phone much more usable. I think we need a bigger fix to get to 100%.
[20:52] <rsalveti> tedg: what are the use cases that are still broken?
[20:52] <rsalveti> right, we can still land this if it improve things at least
[20:52] <tedg> rsalveti, I can get it to show a notification when changing levels in machine-vs-machines, but not on every bullet like before.
[20:54] <rsalveti> cyphermox: yeah, got that with rtm as well, something is really broken with my device
[20:54] <rsalveti> will reflash android again
[20:57] <tedg> Hmm, the music app is crashing for me... anyone else?
[20:57] <tedg> Oh, is this the delete the cache thing?
[20:58] <ahayzen> tedg, if it says unsupported schemas then yes
[20:59] <ahayzen> tedg, instructions here https://lists.launchpad.net/ubuntu-phone/msg10939.html
[20:59] <josepht> dobey: I'll add a task to our sprint backlog for that
[21:01] <tedg> Yup, that was it.
[21:02] <boiko> rsalveti: silo approved ^
[21:02] <dobey> josepht: no way to bribe for expedited enablement there? something i can make a branch for myself and propose?
[21:03] <josepht> dobey: lemme check, I think it's a pretty simple thing to do.
[21:04] <rsalveti> boiko: awesome, wiell land
[21:04] <rsalveti> *will
[21:04] <tedg> rsalveti, It works for me, are you seeing the same?
[21:05] <rsalveti> tedg: waiting my device to flash and will check
[21:07] <cyphermox> rsalveti: I don't get an issue with ifconfig but I booted and got no wifi device
[21:08] <rsalveti> hm
[21:12] <josepht> dobey: pay-ui is an app not a unity-scope, right?
[21:12] <dobey> josepht: it is a click package not a deb, yes. it's sort of an app. it is technically neither an app nor a scope
[21:15] <jgdx> cihelp: I'm seeing a ap test failure in u-s-s on mako [1] which I cannot reproduce on my own mako. Seems to fail consistently too; not sure what I should do. [1] https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/1038/
[21:16] <cyphermox> rsalveti: nevermind, it's good after a reboot
[21:16] <jgdx> and here's the same again https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/992/
[21:34] <josepht> dobey: I've got an MP out to add autopilot testing to pay-ui.  It might not get deployed until fginther wakes up though.
[21:34] <dobey> ok
[21:35] <dobey> thanks josepht
[21:39] <josepht> dobey: my pleasure
[22:01] <tedg> rsalveti, good?
[22:03] <rsalveti> tedg: music-app seems fine here, testing your package now
[22:03] <robru> Time is an illusion. Lunchtime, doubly so.
[22:13] <rsalveti> tedg: yeah, still got a few issues with it
[22:13] <rsalveti> sometimes showing when pause/playing
[22:13] <rsalveti> when jumping to the next song
[22:13] <rsalveti> but something else is seriously broken here
[22:14] <tedg> I think the issue is that we're getting a "hickup" of things connecting and disconnecting.
[22:14] <tedg> So each song Pulse sees as a new connection.
[22:15] <tedg> What I think we need is a little more perspective, and not only using Pulse to decide when we change roles.
[22:25] <tedg> rsalveti, Anyway, don't consider this the full fix, but wanted to get something landed that made things better.
[22:26] <rsalveti> it didn't improve much for me though
[22:26] <rsalveti> still investigating
[22:26] <rsalveti> but I got other serious issues with my system
[22:26] <rsalveti> one time after rebooting I had 3 pulseaudio running as phablet
[22:26] <rsalveti> and indicator-sound failed to start
[22:27] <rsalveti> pulse will just tell what is the current role
[22:30] <tedg> Well, not really. It tells us who the last person connected was and their role.
[22:31] <rsalveti> right, sorry, by current I wanted to say the last one active/connected
[22:31] <tedg> I think the problem is that we're getting multiple active/connected per app.
[22:31] <tedg> i.e. machines-vs-machines there's a different for background and effects.
[22:32] <tedg> So I think looking at the last connected is what the source of the problem is.
[22:32] <tedg> We need to be a bit more clever
[22:33] <rsalveti> oh, ok, got it
[22:33] <rsalveti> yeah