[00:44] <robru> ToyKeeper, any luck?
[00:48] <ToyKeeper> robru: Yes, just having a slow time of it because today is apparently full of stupid.
[00:48] <robru> ToyKeeper, no worries! don't be so hard on yourself
[00:48] <ToyKeeper> In any case, currently trying to figure out which parts of this test plan are expected to fail, and why a click app isn't installing, and if there are any test cases for the i18n bug the change is intended to fix.
[00:49] <cyphermox> test cases, what are those?
[00:49] <ToyKeeper> https://wiki.ubuntu.com/Process/Merges/TestPlan/unity-scope-click
[00:49] <cyphermox> was rethorical ;)
[00:50] <ToyKeeper> But for now I'd settle for a bug with info on reproducing the i18n issue, or even a package name which is known to render incorrectly.
[00:50] <robru> ToyKeeper, hummmmm
[00:50] <robru> ToyKeeper, what i18n bug are we talking about?
[00:51] <ToyKeeper> landing-012's description is: Add i18n support to click scope, display more apps on unity8 desktop
[00:51] <robru> ToyKeeper, oh ok, well the branch is here: https://code.launchpad.net/~dobey/unity-scope-click/translated/+merge/214182 (with linked bug)
[00:51] <ToyKeeper> (IIRC, there was an issue with some text displaying as '?' in the scope)
[00:52] <robru> ToyKeeper, it's not clear to me that there actually is an app that has translations to test, I think it's more a case of "we added code, make sure it doesn't break anything"
[00:52] <cyphermox> are there even apps right now with translated description or name?
[00:53] <robru> was just thinking not ;-)
[00:53] <cyphermox> right :)
[00:53] <ToyKeeper> Okay, I'm probably thinking of the wrong issue.
[00:53] <cyphermox> well, no, it's a very valid thing to test for i18n
[00:54] <ToyKeeper> In any case, I've been looking for a way to reproduce a symptom, to verify it no longer happens.
[00:55] <robru> ToyKeeper, not sure about that, sorry
[00:56] <cyphermox> well we could come up with a click package that has special characters
[00:57] <cyphermox> it's not really going to test the scope though
[00:58] <ToyKeeper> While looking for that, I attempted to go through the unity-scope-click test plan, and thus far haven't successfully been able to install any apps.  It could just be really slow today though, since even just doing a search takes more than 60 seconds to get a result.
[00:59] <ToyKeeper> I don't have baseline image tests for this version though, so it's possible the base image is broken.
[01:00] <cyphermox> I see
[01:02] <ToyKeeper> Okay, that worked.  Took about 5 minutes to install a 72K app.
[01:02] <ToyKeeper> Usually it goes by fast enough I miss it if I blink.
[01:11] <dobey> my branch has nothing to do with apps being translated or not
[01:11] <dobey> it's to enable translation of strings in the scope itself, not of the apps (which is a whole completely different problem that needs a lot more work to enable)
[01:12] <dobey> the '?' issue was fixed in an earlier branch that's already merged and in the archive
[01:13] <dobey> ToyKeeper: if you want to test the '?' issue, it was happening with the one chinese app that's in the store for curator.im
[01:14] <dobey> the icon is red and the name is in chinese text (until you install it, then it's "Curator.im" or something)
[01:14] <ToyKeeper> Okay, good to know.
[01:15] <ToyKeeper> dobey: Any idea if this part of the test plan is supposed to fail?  "Verify you can go back and forth in the dash and progress still works"
[01:15] <ToyKeeper> ( https://wiki.ubuntu.com/Process/Merges/TestPlan/unity-scope-click )
[01:19] <dobey> ToyKeeper: yes, which is why there's a bug # next to it. hopefully will have that fixed soon though. the requisite branch for fixing that was supposed to land in ubuntu-download-manager today
[01:23] <ToyKeeper> dobey: Thanks, it does indeed appear to be fixed (Curator.im app display), and it looks (so far) like my app install issues aren't related to this silo.
[01:24] <dobey> what's your issue?
[01:24] <ToyKeeper> Mostly, that it's going really slow.  But I'm getting the same thing on the base image, and bad ping times.
[01:25] <dobey> oh
[01:25] <ToyKeeper> 45 packets transmitted, 39 received, +42 duplicates, 13% packet loss
[01:25] <ToyKeeper> rtt min/avg/max/mdev = 91.454/2067.209/8079.955/1633.519 ms
[01:25] <dobey> maybe it's related to the DoS that happened earlier
[01:26] <ToyKeeper> Investigating a bit further, it looks like it might be local wireless congestion.
[01:26] <dobey> ah
[01:27] <dobey> very likely too
[01:27] <ToyKeeper> I'm half-tempted to either build a Faraday cage around my home, or build an EMP gun.
[01:29] <dobey> or?
[01:29] <dobey> both is more fun!
[01:30] <dobey> man, my new bandwidth is awesome
[01:34] <dobey> wifi is still meh though
[01:35] <ToyKeeper> Well, looks like channel 13 won't work...  phone doesn't support it.
[01:38] <ToyKeeper> It seems channel 11 isn't congested right now though...  positively zippy compared to what I was doing earlier.
[01:44] <ToyKeeper> It's amazing how much faster things go with a functional network.
[01:44] <ToyKeeper> robru, dobey: Silo 012 tested and signed off.
[01:44] <robru> ToyKeeper, sweeet!
[01:45] <ToyKeeper> Sorry for all the delays and hand-holding; nothing seems to be going right today.
[01:45] <robru> ToyKeeper, no worries!
[01:45] <dobey> i thought the testing was already done
[01:45] <dobey> i guess the "it's done" got dropped somewhere
[01:45] <robru> dobey, new rules for TRAINCON-0
[01:46] <ToyKeeper> Anything which doesn't fix a blocker currently must go through an additional brand-new process.
[01:51] <ToyKeeper> ... and reflashing to test silo 015.
[01:54] <thomi> robru: still around? Silo 11 is ready to land!
[01:55] <robru> thomi, does that mean what I think it means?
[01:55] <thomi> it sure does brain
[01:55] <dobey> Among the maxims on Lord Naoshige's wall there was this one: "Matters of great concern should be treated lightly."
[01:56] <robru> thomi, well you got yourself a publish... we'll see how the release team feels about that
[01:56] <thomi> robru: I don't understand
[01:56] <robru> thomi, well we're past final freeze
[01:57] <robru> thomi, so they might take issue. but since it's just dropping vestigial stuff, I quite like it
[01:57] <thomi> d'awww... my FFE has run out of mojo!
[02:04] <jhodapp> robru: ping
[02:04] <robru> jhodapp, hello
[02:05] <imgbot> [02:05] <jhodapp> hey, could you do me a favor with the CI train?
[02:05] <robru> jhodapp, maybe...
[02:05] <robru> what's up?
[02:05] <jhodapp> robru: landing silo 017...the MP's listed there, can you change all of them to be phablet-team instead of jhodapp...do that to all of them except for the qtubuntu-media-signals MP?
[02:06] <robru> jhodapp, you mean just change the URLs in the spreadsheet? or like, move the branches myself>
[02:06] <jhodapp> robru: just change it in the spreadsheet and reconfigure
[02:06] <robru> jhodapp, ok
[02:06] <jhodapp> robru: and kick off a build for all of those to make sure it works ok
[02:08] <robru> jhodapp, i'm not sure this will work... won't the MP #'s all be different? remember these URLs are MPs, not just branches
[02:08] <jhodapp> robru: ricmm claims the MPs will still be valid
[02:08] <jhodapp> I'm trusting his experience here
[02:09] <robru> jhodapp, well I'll be.... https://ci-train.ubuntu.com/job/landing-017-1-build/25/console
[02:09] <ToyKeeper> Grr...  mirscreencast isn't cooperating any more.
[02:09] <jhodapp> robru: awesome, that's great
[02:11] <ToyKeeper> Okay, that's better.  Apparently it no longer defaults to the, er, default mir socket.
[02:38] <robru> any core devs around to ack https://ci-train.ubuntu.com/job/landing-012-2-publish/9/artifact/packaging_changes_unity-scope-click_0.1+14.04.20140410.1-0ubuntu1.diff ?
[02:49] <ToyKeeper> bfiller: I don't have the slightest clue how to test the telephony-service change in silo 015.  The SMS changes are straightforward, but this has two MPs and I only know what one actually does.
[02:49] <bfiller> ToyKeeper: https://wiki.ubuntu.com/Process/Merges/TestPlan/telephony-service
[02:50] <bfiller> I'll add it to the sheet
[02:50] <ToyKeeper> bfiller: Are the two MPs independent of each other?
[02:51] <bfiller> ToyKeeper: no, the messaging app fixes need the fixes in the telephony-service, that's why it's in the same silo
[02:51] <ToyKeeper> 'k.
[02:52] <ToyKeeper> bfiller: In the telephony-service test plan, I'm not sure how to do this step: "Ensure that all unit tests pass on the device."
[02:53] <ToyKeeper> ... full autopilot test suite?  That will probably take several hours.
[02:53] <bfiller> ToyKeeper: that's kind of bogus
[02:53] <bfiller> ToyKeeper: all the unit tests run in CI, should probably say ensure unit tests pass in CI
[02:53] <bfiller> I'll update it
[02:54] <ToyKeeper> Okay.  In any case, I haven't gotten to a point where I can run the CI tests yet.
[02:55] <bfiller> ToyKeeper: well they've already run when the MR was submitted and all passed
[02:56] <bfiller> ToyKeeper: so you just need to verify that CI passed on the MR
[02:56] <bfiller> (which it has)
[02:56] <ToyKeeper> bfiller: Is this silo supposed to pull in this many packages?  http://pastebin.ubuntu.com/
[02:57] <bfiller> ToyKeeper: you pasted an empty pastebin link
[02:57] <ToyKeeper> Haha...  /me is full of fail today.  ;P
[02:58] <ToyKeeper> http://pastebin.ubuntu.com/7233320/
[02:58] <ToyKeeper> (seriously, today has been ... dumb)
[03:00] <bfiller> ToyKeeper: so no, all these packages are not required. your update is pulling in everything that has landed in the archive plus the changes in silo 15
[03:00] <ToyKeeper> Either the silo packages pulled in a bunch of extras, or the silo installation script I copied from robru is a bit buggy.
[03:01] <bfiller> ToyKeeper: apt-get update will get the latest from the archive plus the silo you added
[03:01] <ToyKeeper> wget -qO- http://ppa.launchpad.net/ci-train-ppa-service/landing-$silo_number/ubuntu/dists/devel/main/source/Sources \
[03:01] <ToyKeeper>   | perl -ne 's/,//g; s/^Binary: // && print' \
[03:01] <ToyKeeper>   | xargs apt-get install --yes
[03:01] <bfiller> ToyKeeper: hmmn, don't know
[03:01] <bfiller> ToyKeeper: here is the list of packages you can install that are needed:
[03:01] <robru> ToyKeeper, I use that all the time, it scans the PPA for binary packages and installs all it finds.
[03:03] <bfiller> robru: looks like she's getting stuff not specifically in that ppa that are not depends
[03:03] <robru> ToyKeeper, hm, silo 15 is telephony-service and messaging-app, that'd be for testing on the phone, not the desktop
[03:03] <ToyKeeper> Yes, exactly.
[03:03] <bfiller> robru: like other updates that have landed in the archive
[03:03] <robru> ToyKeeper, the command you pasted says "apt-get install --yes", it's installing it on your desktop
[03:03] <ToyKeeper> I can restart and do it manually, just wasn't sure what triggered the extra packages.
[03:04] <ToyKeeper> robru: This is running on the phone.
[03:04] <robru> hmm
[03:04] <bfiller> ToyKeeper: sudo apt-get install messaging-app telephony-service qtdeclarative5-ubuntu-telephony0.1
[03:04] <bfiller> ToyKeeper: that's all you need
[03:05] <ToyKeeper> Thanks.  I'll try it with everything currently in the silo...  but will do it manually to avoid surprises.
[03:07] <robru> ToyKeeper,
[03:07] <robru> $ wget -qO- http://ppa.launchpad.net/ci-train-ppa-service/landing-015/ubuntu/dists/devel/main/source/Sources | perl -ne 's/,//g; s/^Binary: // && print'
[03:07] <robru> telephony-service qtdeclarative5-ubuntu-telephony0.1
[03:07] <robru> messaging-app messaging-app-autopilot
[03:07] <robru> not sure where you're getting all those other packages from, unless they were dependencies indirectly somehow
[03:08] <ToyKeeper> bfiller: When touching an URL-ified phone number, it's supposed to launch the dialer app and populate it with the phone number, yes?
[03:09] <bfiller> ToyKeeper: yes
[03:09] <ToyKeeper> bfiller: I'm getting the dialer app, but the number is getting lost somewhere.
[03:11] <ToyKeeper> bfiller: Also, I suspect the extra deps may have been pulled in by messaging-app-autopilot, which is in the silo.
[03:11] <bfiller> ToyKeeper: should start dialing the number in the dialer - that's what I'm seeing
[03:12] <bfiller> ToyKeeper: if messaging-app-autopilot is installed none of the text messaging stuff will work unless you "sudo stop ofono-phonesim"
[03:13] <bfiller> installing this package uses the emulator and your phone won't be able to send or receive messages or phone calls
[03:13] <robru> ToyKeeper, just looking at your pastebin, comparing it to the existing silos, looks kinda like you slurp'd silo 13 instead of 15.
[03:14] <ToyKeeper> robru: In http://pastebin.ubuntu.com/7233320/ , I only see references to http://ppa.launchpad.net/ci-train-ppa-service/landing-015/ubuntu/
[03:14] <ToyKeeper> bfiller: Okay, after stopping ofono-phonesim, it does indeed call the number.
[03:15] <robru> ToyKeeper, yes, but it's installing ofono and ofono-phonesim, which are in silo 13. strange
[03:15] <ToyKeeper> (though I personally prefer when this sort of thing merely pre-populates and then lets me click 'call' or access other functions such as 'add contact')
[03:16] <robru> ToyKeeper, nm, the versions don't match, can't be silo 13.
[03:16] <robru> ToyKeeper, no idea why it's getting those extra deps. the code for sure is parsing the ppa sources file correctly though
[03:17] <ToyKeeper> robru: Because of the autopilot package in the silo.
[03:17] <ToyKeeper> I'm not sure what the correct approach is here; include autopilot packages which shouldn't actually be installed, or put those into a different ppa, or ...
[03:18] <ToyKeeper> (in general, any packages which won't actually be part of the default image could cause issues during silo testing, but it seems weird not to include them in the silo)
[03:19] <robru> ToyKeeper, I don't see how we could keep them out of the silo. silos are just PPAs, we upload a source package then it builds the binaries in the silo. we'd have to take all the -autopilot code and put them in different source packages or something.
[03:19] <ToyKeeper> Okay, makes sense.
[03:19] <ToyKeeper> So, more careful slurping.
[03:21] <ToyKeeper> bfiller: I don't suppose there's any chance we could make it populate dialer-app but not actually start the call?  That's how every other SMS app I've tried handles phone numbers.
[03:22] <bfiller> ToyKeeper: this is how design spec'd it
[03:22] <ToyKeeper> Hmm.  I can't say I agree with design very often...  but that's my problem, not everyone else's.  :)
[03:24] <ToyKeeper> I'll finish the test plans and then I think it can be approved.
[03:28] <ToyKeeper> Looking again, this actually makes more sense...  because our dialer app has no 'add contact' or other functions which can be performed on an entered number.  Just calling.
[03:34] <ToyKeeper> bfiller: This step seems no longer relevant: "Test deleting message details"
[03:35] <ToyKeeper> Oh, nevermind.  That function is still available as select -> delete.
[03:35] <bfiller> ToyKeeper: or swipe to delete on an indiviual message
[03:35] <ToyKeeper> Not sure why though; I haven't deleted a text message since I had an ancient phone with a history limit of like 20 messages.
[03:36] <ToyKeeper> Right, that funky swipe-to-delete thing.  It's in the alarm clock, too.  I had half a dozen different people try to figure out how to cancel or delete an alarm, and not one could do it.
[03:40] <imgbot> [03:40] <imgbot> [03:41] <ToyKeeper> bfiller: This is failing: "Ensure that no telephony* processes are running by default after rebooting phone"
[03:41] <bfiller> ToyKeeper: which ones are running? that might be normal and the test plan is out of date
[03:42] <ToyKeeper> ... though I suspect the error is in the test plan, not the software.
[03:42] <ToyKeeper> phablet   2116  0.9  0.5  81832 10820 ?        Ssl  21:40   0:00 /usr/bin/telephony-service-indicator
[03:42] <ToyKeeper> https://wiki.ubuntu.com/Process/Merges/TestPlan/telephony-service
[03:42] <bfiller> ToyKeeper: that's fine, test plan wrong. will update it
[03:43] <ToyKeeper> I suspect all the steps about unit tests and autopilot tests should probably be removed too, since that requires so much extra junk to be installed on the phone (and invalidates the manual test results).
[03:48] <ToyKeeper> So...  a few hiccups aside, silo 015 is approved.
[03:59] <Mirv> morning
[04:01] <Mirv> ToyKeeper: excellent, I'll publish it then
[04:10] <Mirv> (or robru tried, I'll seek for packaging ack)
[04:11] <robru> Mirv, yeah sorry, just hit that, was about to ask for packaging ack when you got here.
[04:11] <Mirv> asked on #ubuntu-devel
[04:17] <Mirv> someone had apparently accidentally deleted the MP list of that landing. for preserving history, I copy-pasted them back from the build logs.
[04:18]  * Mirv needs more coffee
[05:47] <Mirv> didrocks: hello. two packaging acks are waiting from QA signed off landings, https://ci-train.ubuntu.com/job/landing-015-2-publish/10/artifact/packaging_changes_messaging-app_0.1+14.04.20140410.1-0ubuntu1.diff (maybe it should be "or", although in this case it does not hurt it's dual-licensed?)
[05:47] <Mirv> and https://ci-train.ubuntu.com/job/landing-012-2-publish/9/artifact/packaging_changes_unity-scope-click_0.1+14.04.20140410.1-0ubuntu1.diff
[05:48] <didrocks> Mirv: hello! oh, but you tried to publish already?
[05:48] <didrocks> so I guess the status to get QA sign off isn't clear?
[05:48] <didrocks> or ToyKeeper is working on them?
[05:48] <Mirv> didrocks: well robru did just before I he went to sleep. before that ToyKeeper set the 015 to Yes and 12 already was
[05:48] <Mirv> -I
[05:49] <didrocks> Mirv: ah, so they are signed off?
[05:49] <Mirv> didrocks: ah, parser error... so "are waiting" (for you) while being "from QA signed off"
[05:49] <Mirv> or writer error, impossible to parse!
[05:50] <didrocks> ok ok :)
[05:50] <Mirv> but both are QA signed off, yes, and both just need packaging acks
[05:50] <didrocks> our parsers were not aligned :p
[05:50] <didrocks> reviewing the diff!
[05:51] <didrocks> Mirv: +1 on messaging-app (but it's weird we are getting code in trunk that aren't canonical owned)
[05:51] <didrocks> but from a packaging pov, it's fine :)
[05:53] <didrocks> Mirv: +1 on scope
[05:53] <Mirv> yes we won't want to bundle random JS libraries all around in general probably, or at least we'd need some policies like what are allowed to be ued
[05:54] <Mirv> thanks
[05:54] <didrocks> Mirv: agreed ;)
[05:54] <didrocks> thanks to you!
[06:39] <ToyKeeper> didrocks: Yes, sorry, those were both approved.  Is there anything else I should do to mark them as such?
[06:42] <didrocks> ToyKeeper: no, all is perfect! thanks for it
[07:08] <bzoltan1> Mirv: didrocks: we are done with the silo3 ... it is good to land
[07:13] <didrocks> hum
[07:13] <didrocks> bzoltan1: In silo landing-003. Build failed: Some packages failed to build.
[07:15] <Mirv> there's some weird socket error in the log
[07:16] <Mirv> maybe watch only run to make sure
[07:16] <Mirv> everything is correctly built in the PPA itself
[07:17] <Mirv> watch only running
[07:17] <didrocks> interesting, hey, I'll let you Mirv handling that :)
[07:17] <didrocks> sweet!
[07:17] <didrocks> maybe it was during the firewall issue?
[07:17] <Mirv> probably, or some other timeout issue
[07:19] <Mirv> succeeded
[07:19] <sil2100> We had another firewall issue?
[07:21] <Mirv> didrocks: some more packaging acks, related to the NEW package reviewed earlier (-remotelinux) and then some other CMake changes: https://ci-train.ubuntu.com/job/landing-003-2-publish/lastSuccessfulBuild/artifact/packaging_changes_qtcreator-plugin-cmake_3.0.1+14.04.20140410.1-0ubuntu1.diff  +  https://ci-train.ubuntu.com/job/landing-003-2-publish/lastSuccessfulBuild/artifact/packaging_changes_qtcreator-plugin-ubuntu_3.0.1+14.04.20140410.1-0ubuntu1
[07:22] <sil2100> Mirv: I see you're assigning already for seb128 ? ;)
[07:22] <didrocks> Mirv: remind me, did I new -remote?
[07:23] <didrocks> Mirv: and the FFe was acked and so on?
[07:23] <Mirv> didrocks: FFe was acked, you preNEWed when it was in a bit unfortunate shape still (lacked .bzr-builddeb, not set to UNRELEASED, short descriptions wrong)
[07:23] <bzoltan> didrocks:  there is no failure... the sheet is wrong. All the packages are built well in the Silo3
[07:24] <didrocks> Mirv: so, I didn't really rereview it, right?
[07:24] <Mirv> sil2100: ah, yes :)
[07:24] <Mirv> didrocks: I think you said "ok" for my pull request but then didn't comment anymore
[07:24] <didrocks> bzoltan: well, you needed to relaunch with "watch only ppa" if sheet is wrong :p
[07:24] <didrocks> bzoltan: Mirv has done it
[07:24] <didrocks> (due to previous firewall issues)
[07:24] <Mirv> the branch was lp:~bzoltan/qtcreator-plugin-remotelinux/join_the_train
[07:25] <didrocks> Mirv: let me do a quick recheck now that the fixes are in
[07:25] <Mirv> ok, good
[07:25] <didrocks> +1 on the 2 others, but let me confirm on that one
[07:25] <Mirv> yep
[07:32] <didrocks> Mirv: ok, all good, +1
[07:32] <Mirv> great
[07:33] <Mirv> bzoltan: landing-003 published
[07:48] <circ-user-EFf23> imgbot, status 287
[07:49] <imgbot> Image 287 test results on mako - Total: 684, Pass: 684, Crashes: 0, Rate: 100%
[07:49] <sil2100> Woohoo
[07:50] <Mirv> didrocks: I should have included this manual package upload packaging diff too: https://launchpadlibrarian.net/172321604/qtcreator_3.0.1-0ubuntu3_3.0.1-0ubuntu4.diff.gz
[07:52] <Mirv> sil2100: again very suspicious! :) 0 failures, 0 crashes
[07:53] <Mirv> did you discuss #286's 0 crashes yesterday evening?
[07:53] <sil2100> Mirv: yeah, 0 crashers = yes, but 0 failures is like 'yaay' \o/
[07:53]  * sil2100 wonders why it's still syncing
[07:54] <sil2100> psivaa: what do you think ^ ?
[07:54] <Mirv> yeah we'll need psivaa to check that out
[07:54] <Mirv> I don't think #286 should be crash-free
[07:54] <Mirv> #287 would have better chances as there are actual crash fixes
[07:55] <Mirv> I wonder when there'll be the day that 0 crashes is not an error :)
[07:55] <sil2100> It's not crash free for sure, as the status is 'Syncing' all the time ;)
[07:55] <psivaa> sil2100: Mirv: i'll take a look
[07:55] <sil2100> psivaa: thanks!
[07:56] <didrocks> status 286
[07:56] <didrocks> imgbot, status 286
[07:56] <didrocks> Mirv: so, it was 0 on 286?
[07:57] <Mirv> didrocks: yes, that seems wrong and probably #287 either did not fix all crashes
[07:57] <imgbot> Image 286 test results on mako - Total: 675, Pass: 673, Crashes: 0, Rate: 99.6%
[07:57] <Mirv> either
[07:59] <didrocks> yeah
[07:59] <didrocks> that's weird
[07:59] <sil2100> Jenkins is still syncing the artifacts
[07:59] <didrocks> plars: we'll need your expertise!
[07:59] <didrocks> sil2100: for 286?
[07:59] <sil2100> Yeah... I thought it's temporary, but it seems to do it for eternity ;|
[08:00] <didrocks> ah, so let's see if logging into the device works or not
[08:02] <didrocks> psivaa: tell us when you got something on it please ^
[08:02] <psivaa> sil2100: didrocks: the crashes are present but the dashboard is not syncing them yet
[08:02] <didrocks> psivaa: seems we got the same on 286?
[08:02] <didrocks> which sounds weird
[08:02] <didrocks> psivaa: what did crash btw?
[08:03] <didrocks> normally the unity8 one should be gone
[08:04] <psivaa> didrocks: yes, the results are in 'syncing' state. i checked the dialer-app test to see if there are crashes and there are crashes in it
[08:04] <psivaa> didrocks: during unity8 systems-settings has crashed with 287
[08:04] <didrocks> ok, but no unity8 itself crashed?
[08:06] <psivaa> didrocks: yea unity8 also has crashed with 287
[08:06] <didrocks> argh
[08:06] <didrocks> psivaa: mind giving something for Saviq?
[08:07] <psivaa> didrocks: you mean a bug with apport-bug ?
[08:07] <didrocks> yeah
[08:07] <psivaa> didrocks: ack, will do
[08:08] <didrocks> thanks
[08:16] <ogra_> OMG !
[08:16] <ogra_> trusty-changes exploded over night
[08:16] <didrocks> ogra_: yeah, after-freeze, kde accepted
[08:17] <ogra_> ah, sigh, right
[08:17] <ogra_> KDE is always 150 packages :/
[08:17] <popey> 50 are KDE the other 100 are clocks.

[08:18] <ogra_> haha
[08:19] <sil2100> ;)
[08:21] <didrocks> ogra_: btw, the Touch image is taking -updates by default?
[08:21] <didrocks> for building
[08:21] <didrocks> a lovely
[08:21] <didrocks> and nice
[08:21] <didrocks> Touch
[08:21] <didrocks> image
[08:21] <didrocks> :p
[08:21] <sil2100> ;p
[08:22] <seb128> you and your touch image
[08:22] <seb128> everybody should focus on fixing desktop bugs for the lts this week ;-)
[08:22] <didrocks> seb128: it's not a touch image
[08:22] <didrocks> it's a Touch image
[08:22] <didrocks> :)
[08:22] <seb128> didrocks, it's TheTouchImage(tm)
[08:22] <didrocks> :p
[08:22] <didrocks> "Ze"
[08:27] <ogra_> didrocks, hmm, no idea, i dont think so
[08:27]  * ogra_ checks sources.list
[08:28] <ogra_> well, at least the sources.list says so, but i will have to check build logs
[08:28] <psivaa> didrocks: Saviq: bug 1306453 is for the unity8 crash with image 287 during unity8 tests
[08:29] <didrocks> thanks psivaa
[08:29] <psivaa> yw :)
[08:44] <psivaa> didrocks: seb128: https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1306465 for system-settings crash with 287
[08:45] <seb128> psivaa, thanks
[08:45] <seb128> didrocks, psivaa: sigabrt in libqubuntumirclient.so
[08:46] <seb128> we had some of those on e.u.c some weeks ago, I pinged Saviq & others about it
[08:46] <seb128> not sure we ever figured those out/debugged the issue
[08:46] <seb128> could somebody get a debug bt?
[08:54] <dbarth> didrocks: so for the final freeze, how can we release non-critical bug fixes in a different pocket?
[08:54] <dbarth> didrocks: you mentioned a discussion; is there a mail about that already?
[08:54] <seb128> dbarth, well, you can do SRUs for trusty
[08:56] <dbarth> right, where do we relese a silo content?
[08:56] <dbarth> by default it goes to the archive / unapproved queue, and until it's released we can't free the silo
[08:57] <ogra_> dbarth, that should be transparent to you ... packages should go to -updates
[08:57] <dbarth> oh, nice
[08:57] <ogra_> (once thats all sortted with the release team)
[08:57] <dbarth> well, let's keep going then
[08:57] <dbarth> ah
[08:58] <dbarth> and that "once" is when?
[08:58] <ogra_> not sure what needs to be set up there +
[08:58] <didrocks> dbarth: it was discussed with cjwatson on IRC. i'm waiting on him to get to it to see what we are going to do
[08:58] <ogra_> i assume its a minro switch or simething to make packages end up in -updates instead of the archive
[08:58] <didrocks> (as I poked on #ubuntu-release before his start of day, let's see when he's catching up)
[09:01] <dbarth> ok, nw
[09:01] <dbarth> now that we have a nice electric train, we're just eager to play more
[09:01] <dbarth> ;)
[09:06] <seb128> Saviq, nice, we got a debug bt
[09:07] <seb128> Saviq, https://launchpadlibrarian.net/172567842/Stacktrace.txt
[09:07] <seb128> who would be the right people to ping about QUbuntuMirIntegration issues?
[09:11] <seb128> psivaa, ^
[09:11] <psivaa> seb128: i'm not sure. may be Mirv knows?
[09:16] <Mirv> psivaa: not on that one
[09:26] <ogra_> dbarth, hmm, https://code.launchpad.net/~abreu-alexandre/webbrowser-app/better-control-webengine-lib-loaded/+merge/215280 didnt make it in the last upload ?
[09:26] <didrocks> dbarth: if it's ready, I would suggest we throw away previous upload
[09:27] <didrocks> get everything in one request
[09:27] <didrocks> that would be less work for Laney & co
[09:27] <didrocks> in reviewing
[09:29] <ogra_> yeah, that might be a good step forward here, the change definitely contributes to fix the blocker
[09:31] <didrocks> dbarth: thoughts?
[09:32] <dbarth> ogra_: nope, but this would be a good one to land
[09:32] <didrocks> dbarth: so, do you prefer to merge the changes?
[09:32] <dbarth> didrocks: you mean with osomon's silo?
[09:32] <didrocks> yeah
[09:32] <didrocks> and just do one landing
[09:32] <didrocks> with both fixes
[09:33] <dbarth> and you think you could land it faster?
[09:33] <didrocks> that will be faster for sure
[09:34] <didrocks> (if it lands and is accepted)
[09:34] <didrocks> what we don't know for both
[09:39] <popey> bug 1306496 is new to me (and probably hard for someone other than me to reproduce)
[09:41] <ogra_> didrocks, dbarth, hmm, well, jenkins failed on the MP above, so someone needs to fix it first
[09:42] <popey> bug 1306499
[09:42] <didrocks> ogra_: they are dealing with it
[09:42] <ogra_> ah, k
[09:42] <ogra_> popey, hmm, i think i have seen that bug reported before
[09:42] <popey> ah, i couldn't see it in the list
[09:43] <ogra_> well, i might misremember ... old man etc ...
[09:47] <popey> is the store broken for anyone else? I see no apps on my phone
[09:47] <popey> can't search
[09:47] <popey> http://popey.com/~alan/phablet/device-2014-04-11-104725.png
[09:48] <ogra_> i see apps but search doesnt work here either
[09:48] <popey> once you use search they disappear
[09:48] <ogra_> bah, you could have told me before :P
[09:48] <popey> ☻
[09:48] <ogra_> :)
[09:49] <popey> its local, not the store
[09:49] <popey> my stable phone is fine
[09:49] <dbarth> ogra_: we're loading it in the silo right now
[09:49] <ogra_> cool !
[09:52] <dbarth> ogra_: feels like a timeout issue, all of the other tests pass
[09:53] <ogra_> i have had that with one landing yesterday iirc
[09:53] <ogra_> that also had constant timeouts
[09:55] <Chipaca> who should I pester about https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1304265 ?
[09:55] <popey> ogra_: started working again here
[09:55] <ogra_> popey, same
[09:55] <popey> glitch in the matrix
[09:55] <ogra_> i guess it was actually the server then
[09:57] <popey> root@ubuntu-phablet:/var/log/upstart# cat ubuntu-location-service.log
[09:57] <popey> /proc/self/fd/9: 5: [: =: unexpected operator
[09:57] <popey> Instantiating and configuring: gps::Provider
[09:57] <popey> uh
[09:58] <ogra_> lovely
[09:58] <cjwatson> sounds like missing quoting
[09:58]  * popey embuggens
[10:00] <cjwatson> can't say I see anything relevant in lp:location-service though
[10:01] <ogra_> there is an override job
[10:02] <ogra_> oot@ubuntu-phablet:~# dpkg -S /etc/init/ubuntu-location-service.override
[10:02] <ogra_> lxc-android-config: /etc/init/ubuntu-location-service.override
[10:02] <ogra_> yeah
[10:02] <ogra_> missing quote around a getprop call
[10:02] <sil2100> uh
[10:02] <ogra_> http://paste.ubuntu.com/7234210/
[10:02] <popey> yup
[10:03]  * popey adds to bug
[10:04] <ogra_> popey, against lxc-android-config please ... that will take a while to land, lxc-android_config is blocked in the telephony silo
[10:04] <ogra_> assign me
[10:04] <popey> ok
[10:05]  * ogra_ fears with all that stuff piling up there will be quite a big lxc-android-config change after that silo lands :(
[10:05] <popey> bug 1306515
[10:06] <ogra_> thanks
[10:07] <popey> np
[10:07] <cjwatson> ogra_: ah yes
[10:07] <cjwatson> (#1 rule of shell scripting: put "" around every $-expansion unless you have an explicit reason not to)
[10:08] <ogra_> popey, you might want to try this http://paste.ubuntu.com/7234228/
[10:08] <cjwatson> I think the reasons I can think of where they aren't needed are in case statements and (I recently-ish learned) on the RHS of assignments
[10:11] <Saviq> seb128, could use the .log file to see the abort message
[10:12] <Saviq> seb128, I'd start with ricmm to see who owns qtubuntu these days...
[10:13] <Saviq> psivaa, didn't 1256360 show up as possible duplicate? 'cause it is
[10:13] <sil2100> ogra_: I hope the silo lands today, since otherwise I would propose landing all the lxc-android-config fixes in a separate silo first and then asking them for a rebuild
[10:14] <ogra_> sil2100, well, i would just stack their stuff on top of that upload and re-upload to the silo
[10:15] <seb128> Saviq, thanks
[10:16] <seb128> psivaa, ^ can you get the info Saviq mentioned there?
[10:17] <psivaa> Saviq: i do not remember seeing that prompted as a dupe.
[10:17] <Saviq> psivaa, anyway, fixed with incoming Mir 0.1.8
[10:18] <psivaa> Saviq: ack, the log files are in https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/240/artifact/clientlogs/unity8/ if in case you need any
[10:20] <Saviq> hmm we really need to add a hook so that unity8 apport collects the log there and then...
[10:20] <Saviq> psivaa, do you know how to do ↑?
[10:21] <psivaa> Saviq: no, sorry not sure how to do that
[10:22] <seb128> Saviq, psivaa: the log has a could not create application instance ... mir issue?
[10:23] <ogra_> seb128, yes, and allready fixed in trunk (as usual ...)
[10:23] <seb128> psivaa, ^
[10:23] <seb128> ogra_, psivaa, didrocks: see, those settings report are not our fault :p
[10:24] <ogra_> seb128, yours are the ones on flo :P
[10:24] <ogra_> trying to show an IMEI where none is
[10:24] <seb128> lol
[10:24] <seb128> I've no flo, can't test that
[10:25] <ogra_> thats why we have automation doing it ;)
[10:25] <psivaa> seb128: ahh. ack :)
[10:26] <ogra_> http://ci.ubuntu.com/smokeng/trusty/touch/flo/287:20140411:20140331/7675/ubuntu_system_settings/1011195/
[10:26] <ogra_> :)
[10:26] <seb128> rrrright
[10:26] <seb128> joke aside we have a branch that fixes that which is getting ready for landing
[10:27] <ogra_> ah, cool
[10:27] <ogra_> your manager should get you a flo too :)
[10:29] <ogra_> hmm, the dashboard seems ot have issues syncing the logs
[10:30] <ogra_> even 286 is still in "Syncing" state
[10:30] <ogra_> that makes us miss the crash files
[10:35] <ricmm> psivaa: hi there
[10:35] <ricmm> psivaa: is https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1306465 reproducible?
[10:35] <ricmm> are there steps to do it
[10:37] <psivaa> ricmm: this occurred during the unit8 AP tests, i could rerun to see if that's reproducible
[10:38] <ricmm> please
[10:40] <Mirv> bzoltan: cleaning landing-003 for you as it has reached release pocket. so the trunks should be updated now.
[10:40] <popey> didrocks: #287 is probably the best image we've had for some time.
[10:40] <ogra_> ++
[10:40] <ogra_> if only webapps would work now
[10:41] <Mirv> bzoltan: right, seems to have worked, also for the new package's trunk. success!
[10:42] <didrocks> popey: excellent! way snappier as well?
[10:42] <didrocks> like not more hanging?
[10:43] <popey> yeah
[10:43] <ogra_> definitely
[10:43] <popey> i have 14 apps open and still feels snappy
[10:44] <sil2100> seb128: m&c'ing 001!
[10:45] <seb128> sil2100, thanks
[11:10] <psivaa> ricmm: that's reproducible: https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/241/artifact/clientlogs/unity8/
[11:11] <ricmm> psivaa: happens every time?
[11:12] <psivaa> ricmm: yes happened on both occasions when i ran
[11:12] <psivaa> brb
[11:15] <bzoltan> Mirv: awesome! Thank you!
[11:24] <sil2100> sergiusens: hello! Any plans for landing media-hub today? :)
[11:26] <sergiusens> sil2100: heh; I hope; but fwiw, it's a joint effort; more upto rsalveti and jhodapp|afk
[11:28] <t1mp> gallery-app doesn't start for me in image 278
[11:28] <t1mp> *287
[11:29] <t1mp> does anyone else have that issue?
[11:30] <t1mp> neither from the apps scope or from the button in camera-app
[11:32] <didrocks> hum
[11:32] <didrocks> t1mp: starting here
[11:32] <didrocks> popey: click updates work btw?
[11:33] <popey> didrocks: just testing
[11:33] <t1mp> didrocks: thanks for checking
[11:34] <didrocks> t1mp: I just have one photo though
[11:34] <sil2100> t1mp: gallery-app works fine here as well
[11:34] <didrocks> t1mp: is your database quite full?
[11:34] <popey> didrocks: nope, i see no updates
[11:34] <t1mp> didrocks: no it is not
[11:34] <didrocks> popey: and there are some?
[11:35] <popey> didrocks: yes, i installed old versions of some apps
[11:35] <didrocks> popey: told you, the frenchies are lying!
[11:35] <didrocks> seb128: wth!
[11:35] <didrocks> fix it :p
[11:35] <popey> and I know there are newer ones
[11:35] <seb128> popey, you are logged into u1?
[11:36] <seb128> popey, is update-manager listing the updates?
[11:36] <popey> yes, no.
[11:36] <t1mp> didrocks: I installed a gallery-app click package yesterday, but that should be wiped when I do a new ubuntu-device-flash right?
[11:36] <seb128> popey, "no" for update-manager?
[11:36] <popey> http://popey.com/~alan/phablet/device-2014-04-11-123628.png
[11:36] <popey> ^ "no"
[11:36] <popey> "yes", logged into U1.
[11:36] <seb128> popey, what about the update-manager standalone app?
[11:36] <t1mp> I'll try an ubuntu-device-flash --wipe
[11:36] <seb128> well the old app
[11:37] <seb128> does it list the updates?
[11:37] <didrocks> t1mp: if you install manually the click package, your will take precedence I think
[11:37] <popey> yes http://popey.com/~alan/phablet/device-2014-04-11-123716.png
[11:37] <didrocks> if the version is higher in particular
[11:37] <seb128> gatox, hey
[11:37] <seb128> gatox, any idea about ^?
[11:37] <t1mp> didrocks: I did that before re-flashing, so I thought what I installed would be gone after flashing
[11:41] <popey> seb128: settings was open already, should I restart it maybe?
[11:41] <popey> ooh errors...
[11:42] <ogra_> t1mp, always use --bootstrap and --wipe
[11:42] <popey> seb128: http://paste.ubuntu.com/7234535/
[11:44] <seb128> gatox, ../../../../lib/SignOn/connection-manager.cpp 106 setupSocketConnection p2p error: QDBusError("org.freedesktop.DBus.Error.FileNotFound", "Failed to connect to socket /run/user/32011/signond/socket: No such file or directory") 1
[11:44] <seb128> is that a known issue?
[11:45] <seb128> mandel, mardy: ^
[11:47] <mardy> seb128: yes, there's a branch to suppress that warning and turn into a debug info
[11:47] <mardy> seb128: it's harmless
[11:47] <seb128> mardy, hum, ok :/
[11:53] <popey> seb128: need me to file a bug?
[11:53] <didrocks> popey: yes please
[11:53] <didrocks> we are looking at it (can reproduce as well)
[11:54] <popey> kk
[11:57] <popey> dammit. laptop just completely wedged
[11:58]  * popey REISUBs
[12:18] <popey> didrocks: bug 1306569
[12:19] <didrocks> thanks popey!
[12:19]  * didrocks stares at seb128 now
[12:19] <seb128> BAH
[12:19] <seb128> those french people
[12:20] <didrocks> yeah, unbelievable!
[12:20] <popey> pas de problème
[12:28] <om26er_> dbarth, ping
[12:33] <plars> didrocks: hi, what's up? looks like the latest results aren't showing up right from what I see in the backscroll?
[12:34] <didrocks> plars: there is no .crash file synced in the dashboard
[12:35] <plars> didrocks: hmm, that makes no sense
[12:35] <plars> there are .crash files getting copied to jenkins
[12:35] <plars> https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/240/artifact/clientlogs/dialer_app/
[12:36] <plars> josepht: can you check the dashboard logs? is something blocking the sync
[12:37] <josepht> plars: looking
[12:56] <Chipaca> bregma: do you have a minute or five? Wondering about https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1304265
[13:01] <ogra_> didrocks, do you know who is our QA person today ?
[13:02] <didrocks> ogra_: should be om26er_, why?
[13:02] <ogra_> didrocks, because my team looks for someone to test media-hub
[13:02] <ogra_> seems it passed all internal tests
[13:06] <didrocks> ok, so yeah, om26er_ :)
[13:06] <om26er_> yay!
[13:07] <ogra_> :)
[13:08] <bregma> Chipaca, that's a longstanding compiz problem, although I can't tell you more than that, if I could I would have fixed it already
[13:08] <Chipaca> bregma: but ... it worked before trusty
[13:09] <Chipaca> maybe your 'longstanding' isn't as long as mine :)
[13:09] <om26er_> didrocks, the status for silo 008 is orange i.e. needs QA sign-off but I have figured multiple things missing there. which color should I change the status to ?
[13:10] <didrocks> om26er_: don't change the color, just set QA sign off to No
[13:10] <didrocks> in the silo sheet
[13:10] <om26er_> the 'Test plans to  run' section does not explain its third point on how to do that. and the silo ppa is missing a webapps-core version which is necessary to test
[13:10] <didrocks> and put a comment to explain why
[13:10] <didrocks> the color will change back
[13:10] <didrocks> and ping upstream
[13:11] <pmcgowan> wow 287 has a lot of changes
[13:11] <ogra_> 287 is a beauty
[13:12] <popey> 287 is pretty nice
[13:12]  * pmcgowan updates
[13:12] <pmcgowan> nice
[13:12] <popey> i have had 15 apps open for the last 3 hours or so
[13:12] <didrocks> that's a teaser :p
[13:12] <didrocks> popey: but not webapps though :(
[13:12] <ogra_> yeah
[13:12] <popey> well, no.
[13:12] <ogra_> you can use them one by one though
[13:13] <ogra_> as long as you use the quit function they clean up nicely
[13:13] <sil2100> didrocks: oSoMoN's landing doesn't need QA sign-off? (besides the FFe block) Since it has a feature in it, right? Is it because it's isolated?
[13:13] <didrocks> sil2100: yeah, I think so (I didn't spot the feature the first time)
[13:24] <bregma> Chipaca, I have no problem reproducing that bug on a fully-updated Saucy
[13:25] <Chipaca> bregma: on intel vid hw?
[13:25] <bregma> Chipaca, on nVidia hw
[13:25] <Chipaca> darn & drat
[13:25] <bregma> it got worse after the most recent x.org backport
[13:25] <Chipaca> bregma: ah, maybe it's that -- in any case, sounds like nobody cares enough to get it fixed :(
[13:26] <Chipaca> i guess i won't be using unity 7 again then, which sucks because i quite like it
[13:26] <bregma> "care" may not be the right word so much as "has the time and knowledge"
[13:26] <Chipaca> bregma: you could say it's a heavily nuanced usage of the word "care" :)
[13:33] <pmcgowan> did I just see a push notification on my phone?
[13:33] <ogra_> could be :)
[13:34] <pmcgowan> although I think it lied to me
[13:34] <popey> i saw one but then i blinked
[13:34] <popey> and it was gone.
[13:35] <ogra_> what did it say ? "don't blink" ?
[13:36] <didrocks> doctor who reference!
[13:36] <didrocks> spotted
[13:36] <didrocks> DEFCONF1!
[13:38] <ogra_> heh
[13:39] <didrocks> pmcgowan: it lied, but it was there!
[13:39] <pmcgowan> didrocks, yeah told me there was an update available that I just got that allowed me to see what updates were available
[13:41] <dobey> hey guys. does CI train support landing by having packages pushed to -updates instead of the main release archive?
[13:41] <didrocks> pmcgowan: yeah, that's what I saw as well
[13:41] <didrocks> dobey: yeah, it does
[13:41] <didrocks> why ?
[13:42] <dobey> didrocks: because we're in final freeze and wondering if we'll be able to land things
[13:42] <ogra_> we are
[13:42] <ogra_> for touch stuff only indeed
[13:42] <didrocks> dobey: yeah, that was already thought, no worry ;)
[13:43] <ogra_> for everything else consult the release team first
[13:44] <dobey> ok
[13:47] <cjwatson> dobey: fwiw it's not actually something ci train itself does, the release team will need to sort out the alternate copy path
[13:47] <cjwatson> ci train just copies stuff into proposed
[13:47] <dobey> cjwatson: i thought the jenkins waited for stuff to show up in release?
[13:48] <didrocks> I guess his question was more "will it track the right pockets"?
[13:48] <ogra_> well, and even without CI train consulting the release team first in a final freeze is always a good idea ;)
[13:50] <dobey> didrocks: yeah, i don't know exactly how it works. i mainly want to know how blocked we are for landing things
[13:51] <cjwatson> dobey: oh I see what you mean, I think didrocks made it check -updates too
[13:51] <didrocks> yeah, it does
[13:52] <cjwatson> cupstream2distro r583, right
[13:52] <dobey> ok
[14:25] <alex-abreu> didrocks, ping
[14:25] <didrocks> alex-abreu: pong
[14:27] <alex-abreu> didrocks, having a small issue w/ a migration session script, ... just login of the session should launch it right?
[14:30] <dbarth> while you're at webapps, could i get a reconfig of silo 6, i just added a branch for the firefox regression we spotted this morning
[14:30] <dbarth> didrocks, or sil2100 ^^
[14:30] <sil2100> dbarth: sure
[14:31] <sil2100> dbarth: excellent, doing that now o/
[14:31] <dbarth> cool
[14:32] <sil2100> dbarth: done, you can build the new packages
[14:33] <alex-abreu> didrocks, here is the branch w/ the migration script if you have like 2 mns http://bazaar.launchpad.net/~abreu-alexandre/webapps-applications/update-migration-script-to-remove-local-cruft/files
[14:33] <didrocks> alex-abreu: yeah, it's launching it once
[14:33] <didrocks> and only once
[14:33] <alex-abreu> didrocks, the script works, but does not seem to be triggered (for robru)
[14:33] <didrocks> did you try once?
[14:34] <didrocks> and the fix it
[14:34] <alex-abreu> didrocks, ah ... mmmh so since we use the same name
[14:34] <didrocks> and didn't see the fix
[14:34] <didrocks> yeah
[14:34] <alex-abreu> the thing is that I reuse an old script
[14:34] <alex-abreu> didrocks, it might consider that it was launched before right?
[14:34] <didrocks> alex-abreu: yeah, you shouldn't reuse an old script
[14:35] <didrocks> if people who executed the old script needs to reexecute it
[14:35] <dbarth> sil2100: ok
[14:35] <rsalveti> sil2100: we're missing someone from QA to sign it
[14:37] <alex-abreu> didrocks, yeah
[14:37] <seb128> gatox, mandel, popey: ok, the issue was in settings, Laney has a fix
[14:38] <popey> yay
[14:40] <sil2100> rsalveti: you mean, the media-hub?
[14:40] <rsalveti> sil2100: yup
[14:40] <sil2100> rsalveti: maybe om26er could help? I guess he's around...
[14:40] <sergiusens> cihelp I can't connect to s-jenkins ; is it just me?
[14:41] <sil2100> rsalveti, sergiusens: but you guys already tested the feature from the silo, right?
[14:41] <cjohnston> sergiusens: I can connect, but please use the vanguard
[14:41] <sergiusens> ty
[14:41] <rsalveti> sil2100: sure, but still would like someone from QA to sign it :-)
[14:41] <rsalveti> so we can share the responsibility if something is broken :P
[14:41] <sil2100> rsalveti: yeah, just wanted to know if it can be set to 'tested -> yes', since QA sign-off is another switch ;p
[14:42] <rsalveti> sil2100: right, for that we're good
[14:42] <sil2100> rsalveti: if you set the landing to tested: yes, then QA can see that it requires action from them and perform counter-signing ;)
[14:42] <rsalveti> can be moved to tested (by the team)
[14:42] <om26er> sil2100, yes I am, currently trying to work with media-hub changes
[14:42] <sil2100> om26er: awesome o/
[14:43] <sil2100> Let me upgrade my device as well
[14:58] <jdstrand> can I have a silo for oxide-qt? it fixes some crashers and oxideqt-codecs not working, which is important for desktop (note, oxideqt-codecs-extra continues to work fine)
[14:58] <jdstrand> this is another binary pocket copy from ubuntu-security-proposed
[14:58] <jdstrand> whoops
[14:59]  * jdstrand updates the spreadsheet first
[15:00] <jdstrand> ok, line 27
[15:04] <didrocks> jdstrand: all yours! silo 003
[15:04] <sil2100> jdstrand: looking o/
[15:04] <sil2100> ...done by didrocks o/
[15:04] <sil2100> ;)
[15:04] <jdstrand> thanks!
[15:05] <popey> balloons: when you get a moment can you please upload com.ubuntu.terminal_0.5.45_armhf.click from jenkins to the store. I have already tested it. Just needs approving.
[15:05] <balloons> popey, sure thing
[15:07] <balloons> done popey ;-)
[15:09] <popey> balloons: approved
[15:09] <popey> BOOM!
[15:09] <popey> thats the turnaround I like.
[15:15] <imgbot> [15:15] <ogra_> oooh !
[15:15] <balloons> oO OO
[15:15] <ogra_> didrocks, didnt you want to wait for webbrowser-app ?
[15:16] <didrocks> ogra_: yeah, but it's not going to be unblocked soon
[15:16] <ogra_> :(
[15:16] <didrocks> and I want to see eventually side-effects or dropping python2 from AP
[15:16] <didrocks> of*
[15:16] <ogra_> pfft
[15:16] <ogra_> AP
[15:16] <didrocks> yeah yeha I know
[15:16] <ogra_> :)
[15:16] <didrocks> "everything will be fine"
[15:16] <didrocks> :p
[15:16] <ogra_> ++
[15:20] <sil2100> rsalveti: when trying to run mediaplayer-app tests from the PPA (with media-hub and bits installed) I get the error "Cannot get volume without a valid media-hub player session" - maybe you know what package I'm missing from the PPA?
[15:20] <sil2100> Since I'm guessing I simply missed something during upgrading
[15:21] <rsalveti> sil2100: hm, interesting
[15:21] <rsalveti> jhodapp: ^^
[15:22] <jhodapp> sil2100: interesting, let me try it again
[15:22] <jhodapp> sil2100: are the tests failing as a result?
[15:24] <sil2100> jhodapp: yes, all 6 tests failed here
[15:24] <jhodapp> sil2100: k, I'll take a look
[15:24] <sil2100> jhodapp: do you have maybe the full list of packages I should upgrade from the PPA?
[15:24] <jhodapp> sil2100: http://paste.ubuntu.com/7227996/
[15:26] <didrocks> Chipaca: hey
[15:26] <didrocks> Chipaca: I was wondering, we are seeing ubuntu-system-settings being started while unity8 tests were running, can push notification start a process?
[15:27] <rsalveti> ricmm: ^
[15:27] <Chipaca> didrocks: I'd be surprised, because we don't point at it directly
[15:27] <Chipaca> didrocks: we go through url-dispatcher
[15:28] <didrocks> but you can issue a command that would start it?
[15:28] <sil2100> jhodapp: thanks!
[15:28] <ricmm> sil2100: are you sure media-hub-server is running?
[15:29] <Chipaca> didrocks: it's ... i'm going to say "no", because it's shorter, but i can also tell you the whole thing if you want :)
[15:29] <Chipaca> didrocks: i'm uncomfortable with just saying 'no' however, because i haven't looked into that particular aspect of it. I'd be, as I say, surprised if that happened.
[15:29] <sil2100> jhodapp: ok, now I guess this is what I was missing, since I could not find any public information on what to upgrade to test this, so I thought maybe only a PPA upgrade is necessary
[15:29] <didrocks> Chipaca: ok, so in your opinion, it's "no" :)
[15:29] <Chipaca> didrocks: we talk to url-dispatcher over dbus, and tell it to open system settings, but only by direct user interaction
[15:30] <jhodapp> sil2100: yeah, you need a new android side
[15:30] <ricmm> sil2100: you'd also need to install media-hub
[15:30] <rsalveti> ricmm: he said he had media-hub installed
[15:30] <sil2100> ricmm: media-hub is installed
[15:30] <ricmm> oh
[15:30] <didrocks> Chipaca: ok, let's see if we reproduce that constantly
[15:30] <rsalveti> but yeah, it might be the lack of the new android bits
[15:30] <sil2100> ricmm: just the android bits are old I guess
[15:30] <rsalveti> and media-hub is probably crashing
[15:30] <ricmm> alright
[15:30] <ogra_> om26er, ^^^^
[15:30] <rsalveti> check for crashes in /var/crash
[15:30] <ricmm> probably
[15:30] <Chipaca> didrocks: if and when we do, we log that, so if you look at ~/.upstart/ubuntu-push-client.log, you should see it
[15:30] <ogra_> om26er is reporting something similar
[15:30] <rsalveti> to install media-hub you need to follow http://paste.ubuntu.com/7227996/
[15:30] <sil2100> om26er: in case you need that, http://paste.ubuntu.com/7227996/ has all the instructions
[15:31] <sil2100> Let me add that to the landing, this is important stuff
[15:31] <om26er> sil2100, yeah I  have that
[15:31] <didrocks> Chipaca: oh
[15:32] <didrocks> I think it's you
[15:32] <didrocks> https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/240/artifact/clientlogs/unity8/ubuntu-push-client.log/*view*/
[15:32] <didrocks> any idea why?
[15:32]  * Chipaca looks
[15:32] <didrocks> (ubuntu-system-settings crashed when starting and we shouldn't have it starting u-s-s while we do unity8 AP run :p)
[15:33] <Chipaca> didrocks: fuuu. Let me look and i'll tel you.
[15:33] <Chipaca> that log makes no sense
[15:34] <Chipaca> didrocks: that log gets printed from the click handerl. That means we're getting a clicked notification over dbus.
[15:34] <Chipaca> didrocks: but there's no logs for the notification being displayed
[15:35] <Chipaca> didrocks: can you tell me a little bit more about what's going on?
[15:35] <didrocks> Chipaca: all unity8 AP tests are running, let me try to check locally
[15:39] <didrocks> Chipaca: do you know what kind of click on notification will end up into that state?
[15:39]  * Chipaca gets a nasty feeling of dread
[15:39] <Chipaca> didrocks: sorry, i didn't quite parse that
[15:39] <Chipaca> didrocks: however, my feeling of dread is because
[15:40] <Chipaca> didrocks: one way i imagine this happening
[15:40] <Chipaca> is if we're getting notified for all clicks, not just the ones we created
[15:40] <Chipaca> i'm looking into replicating that
[15:40] <didrocks> clicks as? new click packages in store?
[15:41] <didrocks> or clicks as click from the user on notifications?
[15:41] <didrocks> or on indicators?
[15:41] <Chipaca> didrocks: click from the user on notifications
[15:43] <didrocks> Chipaca: I'm pretty sure unity8 AP tests are doing that
[15:43] <didrocks> Chipaca: still flashing afresh before running them
[15:45] <Chipaca> AUGH
[15:45] <Chipaca> so that's a massive
[15:45] <Chipaca> bug
[15:46] <Chipaca> that we haven't caught :(
[15:46] <didrocks> oh?
[15:46] <Chipaca> didrocks: look no further. It is I.
[15:46] <didrocks> so…
[15:46] <Chipaca> (OTOH, it boggles my mind that we're getting those notifications :( )
[15:46] <Chipaca> anyway
[15:46] <jhodapp> sil2100: I see 2 tests fail for mediaplayer-app ap
[15:46] <didrocks> what do you suggest?
[15:46] <didrocks> should we remove push client from the seed?
[15:46] <didrocks> for now
[15:46] <didrocks> then, get it back with the fix?
[15:46] <Chipaca> didrocks: yes
[15:47] <Chipaca> didrocks: assuming that is quicker than stopping it
[15:47] <didrocks> Chipaca: ok, doing, (and sorry)
[15:47] <didrocks> yeah
[15:47]  * Chipaca returns the champagne
[15:47] <sil2100> jhodapp: uh, not good then, we have no failures currently on the images
[15:48] <jhodapp> sil2100: right...it's probably timing though since control goes over dbus now...the autopilot tests might be too fast
[15:48] <jhodapp> sil2100: because things are event driven
[15:55] <jhodapp> sil2100: I've heard there are possibly some AP test issues on flo?
[15:55] <didrocks> jhodapp: I guess sil2100 is talking about mako
[15:55] <jhodapp> sil2100: this first test failure I'm looking at makes no sense...it simply brings up the mediaplayer-app and make sure the controls are visible...they should be visible whether media-hub is there or not
[15:55] <didrocks> jhodapp: on mako, there is no none flaky test on mediaplayer-app
[15:55] <didrocks> you should compare to the dashboard for flo
[15:56] <jhodapp> didrocks, ok, I don't have a mako...only flo
[15:56] <jhodapp> didrocks, got a link to that?
[15:56] <sil2100> jhodapp: ah, flo
[15:56] <didrocks> yep, fetching it
[15:56] <didrocks> (someone still needs to confirm on mako though)
[15:56] <jhodapp> indeed
[15:56] <didrocks> sorry, slow dashboard
[15:56]  * sil2100 waits for dashboard as well ;/
[15:57] <didrocks> hum
[15:57] <didrocks> so…
[15:57] <sil2100> http://ci.ubuntu.com/smokeng/trusty/touch/flo/287:20140411:20140331/7675/
[15:57] <didrocks> latest image
[15:57] <didrocks> let's check 2/3
[15:57] <sil2100> 2 failures on 287
[15:57] <sil2100> For mediaplayer-app
[15:58] <jhodapp> same two I'm seeing
[15:58] <jhodapp> great, it's not media-hub then
[15:58] <didrocks> same on 286
[15:58] <popey> balloons: i am testing calendar 240 and it's failing 8 or 18 tests... my phone isn't clean (it has google calendar entries) do you have a clean phone you can test on?
[15:58] <didrocks> (the same 2)
[15:59] <balloons> popey, om26er said something similar yesterday. Not sure where he got. I intended to check it out today after I got caught up on everything :-)
[15:59] <om26er> popey, balloons it was failing on my desktop as well, try there
[16:00] <balloons> popey, om26er I assumed it was all the new stuff landing that caused it
[16:00]  * balloons is just confused how it landed without passing
[16:01] <popey> well it could be my shonky phone
[16:01] <popey> i need another phone to have clean for testing
[16:01] <popey> 2 isnt enough ☻
[16:01] <balloons> haha
[16:01] <popey> ☻
[16:03] <didrocks> robru: coming?
[16:05] <sergiusens> popey: emulator :-) slow to boot but good for testing
[16:06] <popey> hmm
[16:06] <popey> ok, I'll do that now to test.
[16:19] <Chipaca> didrocks: just to not do double work, did you file a bug for this?
[16:21] <Chipaca> didrocks: https://bugs.launchpad.net/ubuntu-push/+bug/1306709
[16:26] <didrocks> Chipaca: no, I didn't (sorry, was in the landing meeting)
[16:27] <Chipaca> didrocks: no worries :)
[16:27] <Chipaca> didrocks: had you said on monday "sorry, was past beer o'clock" that would've been fine too
[16:28] <didrocks> Chipaca: oh, I didn't, unfortunately, yet :p
[16:28] <didrocks> but I'm going to fix it!
[16:28] <Chipaca> :)
[16:28] <sil2100> Ok, EODing, need to go to the pharmacy
[16:28] <sil2100> See you next week!
[16:28] <sil2100> o/
[16:29] <didrocks> see you guys!
[16:35] <imgbot> [16:35] <imgbot> [16:36] <ogra_> hmm, less dropped python2 packages than expected i guess
[16:38] <robru> hm
[16:49] <ogra_> ok, meta is in, i triggered the next build ...
[16:49] <asac> meta? feels dangerous :)
[16:50] <ogra_> a revert
[16:50] <popey> sergiusens: ogra_ "adb reboot" doesn't work on the emulator, should it?
[16:50] <asac> hah
[16:50] <asac> i knew it :)
[16:50] <asac> dont do meta
[16:50] <asac> that dangerous
[16:50] <ogra_> lol
[16:50] <asac> always causes issues. i thinkb ecause noone really knows how to test that stuff
[16:50] <asac> or because its just too difficult
[16:50] <asac> must be a reason
[16:50] <popey> ogra_: sergiusens http://paste.ubuntu.com/7235712
[16:50] <ogra_> rrrright
[16:50] <popey> when i adb reboot
[16:51] <ogra_> popey, yeah, might have issues simply because the kernel and initrd live outside of the VM
[16:51] <ogra_> popey, i suppose it shuts down properly ?
[16:52] <ogra_> asac, the revert was for the push service that causes AP crashes in unity8
[16:52] <ogra_> (by starting ubuntu--system-settings unconditionally)
[16:52] <popey> no, been sat there for 5 mins
[16:52] <asac> ogra_: sure. so noone tested that
[16:52] <asac> or not correctly
[16:52] <ogra_> might be, i didnt follow push services
[16:52] <ogra_> only saw it first when it landed yesterday
[16:52] <asac> sergiusens: can we please make phablet-test-run fail on crashes  unless one passees --warn-about-crashes
[16:53] <ogra_> and it works actually fine it seems
[16:53] <asac> or even seed that deeper into AP :)
[16:53] <ogra_> it is just that the AP test of unity8 isnt expecting that it starts
[16:53] <asac> but in the past I never managed to convince anyone from AP team to do anything, hence, i guess phablet-test-run would be the path of least resistance sothat testers dont miss crasehs
[16:54] <asac> ogra_: right. but i think we have a pattern of seeing more crash regressions landing than actual AP failures
[16:54] <asac> given the fact that neither AP, nor phablet-test-run doesnt even tell the user there is a crash
[16:54] <asac> this might be a low hanging fruit
[16:54] <asac> sergiusens: so please :).. .thx
[16:54] <ogra_> popey, try if a normal reboot works (or at least shuts down) ... adb just uses a kernel signal ... pretty much like hitting a reset button
[16:54] <imgbot> [16:55] <popey> ogra_: normal reboot?
[16:55] <asac> sergiusens: just if there is anything in the /var/crash directly (changed), bail out
[16:55] <popey> its torn down, I have to close it now
[16:55] <ogra_> popey, yes, adb shell reboot
[16:55] <asac> or rather have a non-zero return code at the end
[16:55] <popey> will try that next time
[16:55] <asac> with big error message
[16:55] <ogra_> yeah, with a fresh instance
[17:03] <popey> sergiusens: have you actually run AP tests on music app in the emulator? It's painful
[17:04] <sergiusens> popey: don't run the multimedia ones there
[17:04] <sergiusens> popey: ogra_ you can't reboot the emulator
[17:05] <sergiusens> asac: what if the crashes are unrelated?
[17:05] <popey> oh ffs
[17:05] <ogra_> sergiusens, right, but i would at least expect a working shutdown
[17:05] <popey> you asked me to run music-app tests and said I should use the emulator :þ
[17:05] <ogra_> at least with upstart
[17:05] <ogra_> adb will fail for sure
[17:05] <asac> sergiusens: doesnt matter
[17:05] <asac> sergiusens: if you run a test
[17:05] <asac> sergiusens: you remember exactly what is in /var/crash at start
[17:05] <asac> sergiusens: whatever changes after test ends is related to test
[17:05] <asac> sergiusens: thats the same with our infra
[17:06] <asac> and is pretty reasonable - even if not 100% of course
[17:06] <ogra_> sergiusens, just monitor /var/crash for new crash files that appear during or right after the test
[17:06] <asac> right
[17:06] <sergiusens> asac: why wasn't this added to phablet-test-run initially then? :-/
[17:06] <asac> you could a) copy them out at the beinning and report them
[17:06] <asac> then remove them
[17:06] <asac> c) then run and if something appears its a failyure
[17:06] <ogra_> we didnt have that many crashes in the past
[17:06] <asac> sergiusens: people forgot
[17:06] <ogra_> nowadays we have more crashes than AP issues
[17:06] <asac> sergiusens: i thoguth it would get done for 6 month
[17:06] <asac> but noone did it
[17:06] <ogra_> and it sticks out
[17:07] <asac> because i go through managers :)
[17:07] <ogra_> you should stop that
[17:07] <asac> now i talk to the real guys because i am getting annoyed that we still have blind fllights
[17:07] <asac> crash-blind landings
[17:07] <ogra_> fully flat hierarchy FTW :)
[17:07] <sergiusens> asac: bug reports get stuff done ;-)
[17:07] <asac> no
[17:07] <asac> people are not doing it
[17:07] <asac> bugs are just a "calm down place"
[17:07] <asac> problem ist hat i cannot track the non-activity of bugs
[17:08] <asac> i can only track the activity
[17:08] <asac> so i file a bug, noone does anything, i will never remember
[17:08] <asac> so i have to implement a timeout trigger anyway, and then i dont need bugs anymore
[17:08] <sergiusens> robru: cyphermox can you reconfigure silo 13 and create a silo for l29-> u-d-m?
[17:08] <robru> on it
[17:09] <asac> sergiusens: the problem is that some folks are good at processing bugs, some are bad, some prefer something else, hence i rather speak to folks and they can use whatever tracking method they prefer
[17:09] <sergiusens> asac: well the people you tell have to write it down somewhere anyways to remember
[17:09] <asac> e.g. you can file a bug
[17:09] <asac> or a TODO in a text file
[17:09] <ogra_> asac, well, bugs concentrate info around the issue
[17:09] <ogra_> they are not a bad thing :)
[17:09] <asac> sergiusens: sure, but i had often enough wasted time
[17:10] <asac> so i think the people that know what info they want are best to creatwe it :)
[17:10] <asac> anyway, to be clear, i sometimes create bugs
[17:10] <sergiusens> asac: I blame that to the fact that we moved to packaging bugs; upstream doesn't own them :-)
[17:10] <asac> no
[17:10] <asac> its a general pttern
[17:10] <asac> some guys like bugs
[17:10] <robru> sergiusens, ok, silo 13 reconfigured, and for l29 you got silo 11
[17:10] <asac> they are good at it
[17:10] <asac> some prefer TODO lists
[17:10] <asac> spreadsheets
[17:10] <asac> etc.
[17:10] <asac> :)
[17:11] <sergiusens> ok; let me add those items to my todo
[17:11] <asac> and forcing them to do bugs, will not work
[17:11] <asac> cool :)
[17:12] <ogra_> ricmm, see the last comment on bug 1303676 ... does that clearify things for you ?
[17:13]  * ogra_ updates to 288
[17:28] <ogra_> wow, this thing just got useful ... calendar sync works, mail works (well, reading at least) the webapps are snappier than androids ..
[17:29] <popey> sergiusens: i had to kill the emulator and now it won't start, it comes up but unity never starts, and when i log in I can't even run top
[17:29] <popey> just hangs
[17:29] <popey> tempted to destroy and start again...
[17:30] <popey> does anyone actually successfully use the emulator for testing?>
[17:30] <sergiusens> popey: can you started again? there's a bug where i/o gets blocked
[17:30] <sergiusens> popey: did you get a chance to run the music app tests btw?
[17:30] <sergiusens> on a mako?
[17:30] <popey> not yet, trying to get this emulator working
[17:30] <popey> will do music while it boots
[17:30] <popey> i now have two broken emulators on different computers
[17:34] <popey> sergiusens: started this time
[17:39] <popey> sergiusens: ok, running now
[17:41] <chrisccoulson> ogra_, good to hear ;)
[17:41] <ogra_> yeah
[17:54] <popey> sergiusens: that passed, feel free to upload it
[18:00] <sergiusens> popey: ty
[18:03] <popey> sergiusens: can you wait for 417?
[18:03] <sergiusens> popey: what's in that?
[18:03] <sergiusens> I can
[18:03] <popey> sergiusens: actually, wait for a bit.. might be a couple more merges
[18:03] <sergiusens> ok
[18:03] <popey> replacing the empty track artwork
[18:03] <popey> devs are online, hang out in #ubuntu-touch-music if you want to lurk
[18:04] <sergiusens> popey: whichever you want, but if those don't pass; let's at least get 416 in
[18:04] <popey> absolutely, I'll re-test whatever, but we know this passes so we have a fallback
[18:04] <imgbot> [18:05] <imgbot> [18:21] <popey> sergiusens: calendar fails spectacularly in emulator, 14 of 18 fail
[18:22] <popey> dbus timeouts
[18:22] <sergiusens> popey: nice! it's slower so that can be it
[18:22] <ogra_> thats 4 passing ... think positive ...
[18:22] <sergiusens> now people can optomize their apps
[18:22] <sergiusens> ogra_: most apps work fine
[18:22] <sergiusens> under ap
[18:22] <ogra_> yeah
[18:22] <sergiusens> calendar is one of the ones that doesn't; it's sort of slow
[18:23] <om26er> who is the didier equivalent in the US time ?
[18:23] <Chipaca> robru, cyphermox, rsalveti, could I have a slot for row 30 please?
[18:23] <Chipaca> silo, not slot, sorry :)
[18:23] <popey> om26er: robru
[18:23] <robru> om26er, hi
[18:23] <robru> Chipaca, yes
[18:24] <Chipaca> robru: ta
[18:24] <robru> Chipaca, you got silo 12, you're welcome
[18:25] <Chipaca> :)
[18:25]  * Chipaca waits for the spreadsheet to realise
[18:26] <robru> Chipaca, no need to wait actually, you can go right to the tab for silo 12 and click build. because that link goes to jenkins, and jenkins already knows even though the spreadsheet hasn't caught up yet ;-)
[18:27] <Chipaca> robru: noted :)
[18:30] <robru> ToyKeeper, ping? need your ack on silo 17
[19:26] <popey> sergiusens: building music 418 in jenkins, will test and let you know
[19:27] <Chipaca> robru, cyphermox, rsalveti, could I have a landing for silo 12 please?
[19:27] <robru> on it
[19:28] <Chipaca> robru: thanks :)
[19:28] <cyphermox> too fast!
[19:28] <Chipaca> cyphermox: here, have a consolation beer
[19:29] <robru> Chipaca, you're welcome
[19:32] <Chipaca> robru: thrice thank you :)
[19:38] <boiko> robru: landing-004 ready to go
[20:22] <robru> boiko, need QA signoff on that. ToyKeeper silo 4?
[20:23] <boiko> ToyKeeper: just a heads up, if calls don't work or don't have sound, that's the pulseaudio thing being debugged already
[20:23] <popey> fginther: can you push https://code.launchpad.net/~vthompson/music-app/update-to-cover-art/+merge/215498 please?
[20:23] <boiko> ToyKeeper: salem is doing a bugreport on that already
[20:23] <ToyKeeper> boiko: I'm in the middle of testing that, actually.
[20:23] <fginther> popey, sure
[20:23] <ToyKeeper> robru: ... then testing silo 017, then re-testing it when a bugfix is added.
[20:24] <boiko> ToyKeeper: in case you need, salem_ on #ubuntu-app-devel has a backtrace and some more info related to that already
[20:24] <robru> ToyKeeper, great, thanks
[20:24] <ToyKeeper> boiko: rsalveti is getting a pulseaudio crash fix into silo 017 right this moment.
[20:25] <rsalveti> ToyKeeper: boiko: will also push it to the archive
[20:25] <rsalveti> so we can unblock other people
[20:25] <boiko> rsalveti: would you mind letting me know when that is built? tiago and I can give it some testing on dialer-app (we have a few cases already)
[20:25] <rsalveti> hopefully part of the next image
[20:26] <rsalveti> if all goes well
[20:26] <ToyKeeper> rsalveti: Do we need to do anything special to issue an Android fix as part of a new image?  (same update process as usual, or something special?)
[20:26] <sergiusens> popey: testing still ongoing?
[20:27] <popey> sergiusens: just pushing that last rev to take music to 419 then we're ready
[20:27] <popey> once that click builds you're good to upload
[20:27] <rsalveti> ToyKeeper: if you want to test the proposed fix, you need to update the android system.img
[20:27] <rsalveti> which is not necessarily trivial
[20:28] <rsalveti> need to put a script for that in phablet-tools
[20:28] <rsalveti> got one but part of our android build scripts
[20:28] <rsalveti> https://code-review.phablet.ubuntu.com/#/c/196/
[20:30] <ogra_> rsalveti, ++ for the script ... i also want a resize script
[20:30] <ogra_> rsalveti, feel free to file a whishlist bug and assign to me
[20:30] <rsalveti> ogra_: sure
[20:40] <popey> sergiusens: music 419 is ready to go
[20:44] <sergiusens> popey: uploading now
[20:46] <popey> thanks
[20:52] <rsalveti> android is currently building already, will trigger a new image once it's published
[20:54]  * ogra_ still doesnt get where it comes from 
[20:54] <ogra_> looking through all changes for the last few images there is nothing touching sound
[20:55] <rsalveti> ogra_: right, would be interesting to investigate, but anyway, fix on the day
[20:55] <rsalveti> way
[20:55] <ogra_>  - Change M_CHECK_ACTION to abort if first MALLOC_CHECK_ bit is set.
[20:55] <ogra_> hmm
[20:55] <pmcgowan> rsalveti, out of curiosity, what fixed it?
[20:55] <ogra_> libc change
[20:55] <rsalveti> pmcgowan: android
[20:55] <rsalveti> ogra_: yeah
[20:56] <rsalveti> that might be the cause
[20:56] <rsalveti> but who knows
[20:56] <ogra_> well, that went into 288
[20:56] <ogra_> and the pulse issue was malloc related
[21:00] <cjwatson> ogra_: I can't imagine anything in touch is setting MALLOC_CHECK_, though.  That's a debugging flag.
[21:01] <ogra_> cjwatson, well, i cant really imagine any other change from http://people.canonical.com/~ogra/touch-image-stats/288.changes
[21:01] <cjwatson> *shrug* Just sayin', chances of it being the quoted libc change seem pretty minimal
[21:01] <ogra_> at least nothing that low level that it would affect pulse talking to android
[21:02] <rsalveti> let me try to flash an older image
[21:02] <rsalveti> not sure if dual boot supports that
[21:03] <cjwatson> that change was effectively just
[21:03] <cjwatson> +-      __libc_message (action & 2, "*** Error in `%s': %s: 0x%s ***\n",
[21:03] <cjwatson> ++      __libc_message (action & 3, "*** Error in `%s': %s: 0x%s ***\n",
[21:03] <cjwatson> +                       __libc_argv[0] ? : "<unknown>", str, cp);
[21:03] <popey> sergiusens: problems?
[21:03] <sergiusens> popey: yeah, distractions!
[21:03] <cjwatson> If that breaks anything, then (a) they were already setting a debugging environment variable and (b) they already had malloc corruption
[21:03] <sergiusens> one sec :-)
[21:03] <popey> ah okay ☻
[21:04] <cjwatson> And there would be a pretty clear abort message in a log
[21:05] <ogra_> well, the fix in android that ricardo did is valid ... it just didnt affect us until now
[21:05] <sergiusens> popey: https://myapps.developer.ubuntu.com/dev/click-apps/143/
[21:06] <rsalveti> flashing 280
[21:06] <ogra_> rsalveti, i would just try 287 ...
[21:06] <popey> sergiusens: approved
[21:07] <ogra_> someone on the ML specifically complains about 288 so i guess 287 was good for him
[21:07] <rsalveti> right, just grabbing an older to make sure, but will flash 287 after
[21:08] <rsalveti> now we wait ~1h for the package to be built & published
[21:08] <ogra_> yeah ...
[21:09] <rsalveti> your initrd changes should be in next image as well
[21:09] <rsalveti> hopefully that will not break anything ;-)
[21:09] <rsalveti> ogra_: did we remove hud at some point?
[21:10] <ogra_> nope
[21:10] <rsalveti> it's useless atm
[21:10] <ogra_> i use it several times a day
[21:10] <ogra_> for closing apps
[21:10] <rsalveti> right, but that's not really hud
[21:10] <rsalveti> is it?
[21:10] <ogra_> it has a quit option in many aps :)
[21:10] <ogra_> *apps
[21:11] <ogra_> the hud is the thing you slide in from the bottom
[21:11] <rsalveti> right, but that's just the interface
[21:11] <rsalveti> wonder if the hud integration is indeed working
[21:11] <ogra_> you can even see a nice animation if you tap the mic and say something
[21:12] <rsalveti> oh, then it's working again
[21:12] <rsalveti> cool
[21:12] <rsalveti> I know it was broken for months
[21:12] <ogra_> well, it never returns anything useful for me
[21:12] <ogra_> but i see a rotatong circle with orange dots ...
[21:12] <ogra_> then it returns to the input
[21:23] <rsalveti> ogra_: 280 is fine
[21:24] <ogra_> yeah, thought so
[21:24] <ogra_> i bet 287 too
[21:24] <rsalveti> will flash that one now
[21:25] <ogra_> oh
[21:25] <ogra_> look
[21:25] <ogra_> http://ci.ubuntu.com/smokeng/trusty/touch/mako/288:20140411.1:20140331/7690/dialer_app/
[21:25] <ogra_> a pulse crash at the bottom
[21:25] <ogra_> dialer-app didnt fail since a while
[21:25] <ogra_> so it is definitely 288 specific
[21:26] <rsalveti> telephony-service from 0.1+14.04.20140407-0ubuntu1 to 0.1+14.04.20140410.1-0ubuntu1
[21:26] <rsalveti> messaging-app from 0.1+14.04.20140327-0ubuntu1 to 0.1+14.04.20140410.1-0ubuntu1
[21:26] <rsalveti> what changed in there?
[21:27] <ogra_>   * get accountIds from handler when appropriate to start apps faster.
[21:27] <ogra_>     set application names .
[21:27] <ogra_> thats telephony
[21:27] <rsalveti> hm
[21:27] <ogra_> messaging has some UI fixes
[21:27] <ogra_> (press and hold interaction)
[21:27] <rsalveti> I know the voice call shutdown process seems faster now
[21:28] <rsalveti> that might be what triggered the bug
[21:28] <rsalveti> will know in a few minutes
[21:29] <ogra_> hmpf, looks like 289 killed a mako in the lab
[21:29] <ogra_> plars, ^^^
[22:04] <ogra_> robru, if you have a spare silo, i wouldnt mind one for line 31
[22:05] <robru> ogra_, ok, you got silo 12!
[22:05] <ogra_> thanks !
[22:05] <robru> you're welcome!
[22:16] <rsalveti> ogra_: yeah, 287 is fine
[22:17] <ogra_> right
[22:17] <ogra_> rsalveti, btw, would be good to wait til silo 12 and the webbrowser-app upload are landed before rolling an image
[22:17] <ogra_> that should get us working webapps again
[22:18] <rsalveti> silo 12 is not yet tested it seems
[22:18] <ogra_> its building atm
[22:18] <rsalveti> sure, android will be published in a few minutes
[22:18] <ogra_> was already tested by ted and me, i just need to do a test of the package once it built
[22:19] <ogra_> to make sure the build didnt change anything :)
[22:20] <ogra_> rsalveti, what bothers me more is that we seem to have lost the mako in the lab ... that means no test results over the weekend :/
[22:20] <rsalveti> can't we have someone to get there?
[22:21] <rsalveti> kind of important the weekend before the release
[22:21] <ogra_> well, the landing team has nobody planned for the weekend either
[22:22] <ogra_> (so we cant really land anything (unless someone from the team is occasionally around))
[22:23] <rsalveti> but it'd be nice to have the test results by monday morning
[22:23] <cjwatson> I was going to try to land click, but only a "click chroot" change to belatedly flip the default framework to 14.04
[22:23] <cjwatson> So I guess we don't need runtime results for that
[22:24] <cjwatson> Oh, hmm, https://code.launchpad.net/~cjwatson/phablet-tools/click-buddy-pass-framework/+merge/214744 hasn't landed
[22:24] <cjwatson> Don't suppose there's any chance we could get that?
[22:24] <cjwatson> Maybe I'll have to do all this in SRUs :-/
[22:24] <ogra_> hmm, where is sergio
[22:25] <rsalveti> he's brb
[22:25] <ogra_> yeah
[22:26] <ogra_> hmm, i really dont get along so well with the new design of the icon highlighting in the desktop launcher
[22:26] <ogra_> i always miss it with the new design
[22:34] <cjwatson> Ah, apparently MALLOC_CHECK_ is actually 1 by default, I was wrong
[22:41] <rsalveti> yeah, it seems the crash started to happen with the new libc
[22:41] <rsalveti> using 287 + new libc
[22:41] <rsalveti> able to generate the crash
[22:41] <infinity> rsalveti: What is the crash?  I missed context here.
[22:42] <rsalveti> infinity: a double free made pulse to crash
[22:42] <cjwatson> So apparently libc had a brief period of not aborting on this sort of thing, from 23 Feb to 9 Apr
[22:42] <rsalveti> we always had the double free in the code, which I just fixed
[22:42] <infinity> rsalveti: It should probably not do that.
[22:42] <infinity> rsalveti: I question "always".  This would have aborted before Feb 23 as well.
[22:42] <cjwatson> Doesn't seem long enough for much in the way of misbehaviour to sneak in, but long enough for one or two, perhaps
[22:43] <rsalveti> well, the abort doesn't happen with yesterday's image
[22:43] <cjwatson> See above
[22:43] <rsalveti> right
[22:43] <infinity> rsalveti: Yes, I know.  Between Feb 23 and Apr 09, libc didn't abort on double free.  Blame sbeattie and I for regressing that. :/
[22:44] <infinity> But the fact that it does again is a feature, not a bug. ;)
[22:44] <rsalveti> I know :-)
[22:44] <rsalveti> we just curious about what made the real bug to appear now
[22:44] <cjwatson> We must have been pretty lucky that it didn't cause pulse to explode in strange ways later on.
[22:44] <cjwatson> Or maybe it did and we didn't notice or work out why.
[22:44] <rsalveti> right
[22:44] <cjwatson> Since that's usually the result of ignoring a double-free.
[22:46] <rsalveti> ogra_: ChickenCutlass: ricmm: so that explains why we got the bug with 288 ^
[22:47] <ogra_> yeah
[22:47] <infinity> rsalveti: Sorry for the annoyance.  But amazing that someone snuck in a malloc bug in the month and a half when they could. ;)
[22:47] <ogra_> so my guessing wasnt so wrong then :)
[22:47] <ChickenCutlass> rsalveti: ah
[22:47] <ChickenCutlass> well
[22:47] <cjwatson> Sorry for doubting you
[22:47] <ChickenCutlass> good we found it
[22:47] <rsalveti> infinity: no worries, at least we fixed a real bug :-)
[22:47] <ogra_> yeah
[22:48] <cjwatson> (I was misled by the lying documentation)
[22:48] <cjwatson> (in part)
[22:48] <ogra_> well, I was just guessing ... could as well have been rong
[22:48] <ogra_> *wrong
[22:55] <ogra_> robru, silo12 and be published
[22:55] <ogra_> s/and/can/
[22:55] <ogra_> tsk
[23:03] <robru> ogra_, done!
[23:03] <ogra_> yay
[23:03] <ogra_> now we got working webapps again :)
[23:03] <robru> yay!
[23:03] <rsalveti> can I haz a new image?
[23:04] <robru> whoa whoa, it's not even in proposed yet
[23:04] <robru> just hit publish 10s ago ;-)
[23:04] <rsalveti> alright, then we wait
[23:06] <ogra_> rsalveti, well, in 3h there is a cron build anyway, just go ahead
[23:08] <rsalveti> I can wait more 20 minutes
[23:29] <robru> ogra_, ok! wanna kick an image build?
[23:29] <ogra_> yeah
[23:30] <ogra_> rsalveti, i'm triggering one
[23:30] <rsalveti> ogra_: thanks!
[23:34] <imgbot> [23:36] <popey> oooh
[23:57] <ogra_> jdstrand, ^^^
[23:57] <jdstrand> ogra_: thanks! :)