[07:16] <Mirv> plars: I forgot to mention but I filed a bug about that maguro qmlscene crasher, but I just didn't get a good retrace bug #1269080
[07:17] <Mirv> the tracer service's trace at least goes somewhere inside Mir
[08:23] <vila> qa-intel-4000 crashed ~1h ago and has been power-cycled, seems fine now
[08:24] <vila> https://wiki.canonical.com/UbuntuEngineering/CI/IncidentLog/2014-01-15-qa-intel-4000-crashed for details
[09:05] <sil2100> didrocks: morning! A strange incident took place in cu2d which caused a lot of check jobs and build jobs to fail
[09:05] <didrocks> sil2100: hey, what happened?
[09:05] <sil2100> didrocks: the symptoms are as follows: it can be seen that a prepare job for a project prepares the source package and uploads it to the PPA, then:
[09:06] <sil2100> didrocks: the packages do not show up in the PPA (as if they were never uploaded), the build job wants to check for the status of those packages, but it cannot, since those are not uploaded
[09:07] <sil2100> didrocks: so the build job fails - do you know if we had a problem like that before?
[09:07] <sil2100> didrocks: it's not a single case, since many stacks failed in the same way: phone, apps, settings etc.
[09:07] <sil2100> didrocks: for instance, the dialer-app prepare job says it uploaded: Uploading dialer-app_0.1+14.04.20140115-0ubuntu1_source.changes: done.
[09:08] <didrocks> sil2100: not sure, can you try dputing manually to the ppa?
[09:08] <sil2100> didrocks: but the PPA: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages?field.name_filter=dialer-app&field.status_filter=published&field.series_filter= (nothing)
[09:08] <didrocks> I guess we'll need to check if launchpad rejected the uploads
[09:08] <didrocks> fginther has access to the emails
[09:08] <didrocks> from ps-jenkins
[09:08] <sil2100> ACK
[09:13] <asac> balloons: hey
[09:13] <asac> balloons: have you tried backing out all the components?
[09:26] <Mirv> it would be cool to add more cores to brains
[09:27] <sil2100> Amen
[09:29] <sil2100> didrocks: a direct manual dput of any package to the PPA worked fine
[09:30] <sil2100> didrocks: it might have been some LP/PPA strangeness for a period of time, but I guess we'd need some logs to know for sure
[09:30] <didrocks> sil2100: ok, I guess we need fghinter access to ps-jenkins emails then
[09:30] <didrocks> sil2100: can you try building something and see if it was transiant?
[09:31] <sil2100> didrocks: ok, I'll start one of the stacks maybe
[09:31] <sil2100> didrocks: btw. the hangouts session says 'This party is over' o_O ?
[09:31] <didrocks> sil2100: you should have a wrong link I guess
[09:31] <didrocks> sil2100: https://plus.google.com/hangouts/_/calendar/Y2Fub25pY2FsLmNvbV91cTRvNmQyMWJvNmJ0bm1mcW9xZWtsNTdnOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t.us2orfbhb8ssqjui2u15tajj3s
[09:32] <sil2100> didrocks: the same here, hm
[10:05] <psivaa> didrocks: reverting hud from 13.10.1+14.04.20140108-0ubuntu1 to 13.10.1+14.04.20131205-0ubuntu1 made the maguro messaging ui test to pass.
[10:06] <didrocks> can you give details to thorst?
[10:06] <didrocks> on #ubuntu-touch?
[10:38] <vila> sil2100: do you have an estimated time on when your ppa issue occurred ? There seem to have been an issue with lp ~14 hours ago on http://q-jenkins.ubuntu-ci:8080/job/trusty-touch-maguro-smoke-install-and-boot/162/ .
[10:39] <sil2100> vila: when I was looking at this issue in the mornign, I saw that jobs that were started 2 hours ago (back then) had the issues - so from now it's around 4 hours ago when the issues happened
[10:40] <vila> sil2100: hmm, probably unrelated then, never mind.
[10:40] <sil2100> vila: how long did those LP issues been happening?
[10:40] <vila> sil2100: no idea, the one I referred to looks like a transient one
[10:41] <didrocks> sil2100: are the latest jobs better?
[10:43] <sil2100> didrocks: it looks better now, the all-job kicked in now even
[10:43] <sil2100> And I see that so far dputting works
[10:43] <sil2100> So I'm crossing fingers that all the stacks will be ok this time
[10:44] <didrocks> sil2100: ok, seems we had a launchpad outage then
[10:54] <cjwatson> or a transient network glitch, or ...
[10:54] <cjwatson> (no record of a general outage around that time)
[10:57] <sil2100> I want cu2d to move through those stacks that failed last time, I want to see if it wasn't anything strange with some selected stacks by some strange coincidence
[11:04] <didrocks> sil2100: also, something else to track when you have time, can you check why http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg indicator-datetime recommends indicator-applet which is in universe?
[11:05] <sil2100> didrocks: looking into that
[11:05] <didrocks> thx!
[11:10] <seb128> didrocks, sil2100: that's because of ppc64el
[11:11] <seb128> didrocks, sil2100: the indicator recommends and indicator-renderer, our preferred one is unity but it didn't build yet on ppc64el so component mismatch resolves the available alternative option
[11:11] <sil2100> seb128: ah... thanks for the information
[11:12] <sil2100> Indeed, I see it's dep-waiting on libunity stuff for ppc64el
[11:14] <sil2100> https://launchpad.net/ubuntu/+source/libunity-misc/4.0.5daily13.06.05-0ubuntu1 <- hmm
[11:14] <mandel> morning, I'm wondering if there is a way to fix the following CI fails https://jenkins.qa.ubuntu.com/job/ubuntu-download-manager-trusty-amd64-ci/161/console that are due to the speed of jenkins instead of increasing the timeout, is a little ugly to keep increasing the timeout when in a local machine there are no issues
[11:15] <cjwatson> component-mismatches(-proposed) is processed by humans for exactly this kind of reason; there are often issues with new ports and all kinds of other things
[11:16] <cjwatson> That libunity-misc build failure looks like something that would happen on all architectures if retried, though
[11:18] <seb128> cjwatson, right, another package doing Werror and hitting GTK deprecations it seems
[11:18] <sil2100> cjwatson: indeed, while it only got re-built for ppc64el since the others were already from trusty I guess
[11:18] <cjwatson> saucy, but yes
[11:18] <vila> mandel: that's.... a delicate one :-/ From the CI side, what timeout should be used ? If I were to change that, I will ask the project devs for advice and even then, I doubt there is a valid value for all tests.
[11:18] <sil2100> Right, saucy ;) Typo
[11:19] <seb128> sil2100, cjwatson: let me propose a fix for that ftbfs
[11:19] <sil2100> cjwatson, seb128: I guess I'll try fixing that, as Neil is not around anymore
[11:19] <sil2100> Oh, ok
[11:19] <cjwatson> bits of the unity stack will still fail until we're on Qt 5.2
[11:19] <cjwatson> (anything that needs qtdeclarative)
[11:19] <mandel> vila, the main issue I have is that I can increase the timeout but there is no guarantee that it will be valid in the future, that is, the servers might be slower and then the fail will be back :-/
[11:19] <vila> mandel: short of making the CI network at least as fast as your local one, how do we know the test correctly succeeds ?
[11:20] <sil2100> cjwatson: at least unity7 bits will move forward with this one fixed, as those are qt5 independent
[11:20] <cjwatson> right
[11:20] <cjwatson> well, except somebody needs to fix zeitgeist
[11:21] <cjwatson> oh, pitti did, good
[11:21] <mandel> vila, indeed, in this case I'm worried because I have been writing integration tests that spawn dbus daemons and http severs and is a bad idea to wait for ever for a dbus signal, for example
[11:21] <vila> mandel: yeah, I see your point, but I fail to see how to fix that :-/ Other than letting you control what a valid timeout is...
[11:21] <vila> mandel: yeah, tricky, but again, that requires internal knowledge of what the test expects
[11:22] <mandel> vila, well, I'll keep increasing it since it does not make the tests to be slower in the local machines, the code is testing the value of the var until is equal or the timeout is reached and fails
[11:22] <mandel> vila, so, technically my changes are not breaking the devs work
[11:22] <vila> mandel: yup, I was about to mention that: when tests succeed, the timeout is irrelavant
[11:22] <vila> irrelevant even
[11:23] <vila> mandel: but that's an area where I have little advice to provide except that test that rely on timeouts are inherently brittle ;-/
[11:24] <cjwatson> hmm, also, url-dispatcher is architecture-restricted but various indicator-* packages build-dep on it
[11:24] <mandel> vila, agreed, but when you are dealing with the emission of signals from qt is unavoidable :-/
[11:24] <vila> mandel: even trying to guess some values on the fly by exercising various parts (CPU, network), it's hard to scale
[11:24] <cjwatson> maybe that won't matter for this
[11:25] <vila> mandel: yeah, I know it's hard. The only workarond I can think of is having the test be purely event based instead of polling, but that's hard to reach
[11:26] <vila> mandel: increasing the timeouts is hardly satisfying either but it's still the only pragmatic solution I can think of
[11:26] <mandel> vila, yeah.. and in this precise tests I'm testing that the signal is used and a cb used.. well, I'll do my best to get this to work.. bummer
[11:27] <vila> mandel: have you tried with the emulator ? It's said to be slow and that may help you to get a behavior closer to what happens in CI ?
[11:27] <mandel> vila, not yet, it is in my plans for the system image updates in a week or two, atm I'm focusing on getting full integration tests
[11:28] <vila> mandel: you may also want to talk to QA about that timeout issue, they probably encounter it too
[11:28] <mandel> vila, ok, will do
[11:29] <mandel> thx for the info
[11:29] <mandel> vila, I have another question related to CI, I'm spawning a http server to listen to 8080 and will increate the port number about 10 times in case the port is used
[11:30] <mandel> vila, does CI do something to avoid tests on a project breaking other tests, for example, the chromium tests also spawning a server in 8080
[11:30] <vila> mandel: yeah, a bad idea ;) socket.bind(0) can be used to get an unused port
[11:31] <mandel> vila, dammed.. I'll try to take a look at that using simplehttpserver :-/
[11:31] <vila> mandel: nope, we don't AFAIK (not sure how we would try... putting that in my background to think about it)
[11:32] <vila> mandel: bzrlib.test.http_server should have examples
[11:32] <mandel> vila, I'm dealing with cpp :P
[11:32] <mandel> vila, is not that easy to know the port etc.. anyway, is my job to find a decent way :)
[11:32] <seb128> sil2100, https://code.launchpad.net/~seb128/libunity-misc/wno-error-deprecated-declarations/+merge/201755
[11:33] <vila> mandel: ? you mean simplehttpserver is written in cpp ?
[11:33] <sil2100> seb128: thanks! Test-building and reviewing
[11:33] <seb128> sil2100, that code is deprecated, it feels like it's not worth trying to update to not use deprecated functions, let's just not error out on those
[11:33] <mandel> vila, no, I'm starting it via cpp so I need to look on how to get the port it is using
[11:33] <mandel> vila, not to worry, I'll take a look later on how to fix this
[11:33] <sil2100> seb128: makes sense, we're not actively maintaining those parts of code anyway
[11:34] <vila> mandel: ha right, yeah, the idiom is to output the port used on stdout or stderr in that case
[11:34] <vila> mandel: so 1) you start the server, 2) you get the port 3) you give the port to your clients 4) you don't forget to stop the server when done ;)
[11:35] <mandel> vila, yeah, something of the kind with no timeouts etc..
[11:35] <vila> 4 includes error handling ;)
[11:35] <vila> mandel: right, 2 is also a way to make sure the server is already listening and can be used by clients
[12:04] <psivaa> didrocks: just an update, no luck still yet on rssreader failure reverts. working on the list still.
[12:04] <didrocks> psivaa: thanks for the update, good luck for the rest :)
[12:16] <seb128> sil2100, can you get libunity-misc released?
[12:20] <sil2100> seb128: sure, just waiting for the stack runs to finish - once that's cleared, I'll release it because it's a bit critical
[12:20] <sil2100> So I think of it as an exception from our 'blocking' rule
[12:21] <seb128> sil2100, thanks (it also doesn't affect touch so shouldn't get didrocks angry either ;-)
[12:49] <sil2100> didrocks: hmm... it happened again ;/
[12:49] <didrocks> sil2100: maybe try #webops?
[12:50] <didrocks> to debug and with cihelp ^
[12:50] <didrocks> to know if it's a network issue, a launchpad issue or anything else
[12:56] <sil2100> didrocks: the repository size!
[12:56] <sil2100> didrocks: we have too many packages!
[12:56] <sil2100> 2.0 GiB (100.00%) of 2.0 GiB
[12:56] <ahayzen> Hi, I'm having an issue landing the branch https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/199906 ... when looking at the logs https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4675/console it appears tht the process isn't even starting, is Jenkins broken in some way? Thanks in advance.
[12:56] <sil2100> cihelp ^
[12:56] <sil2100> I poke #webops now
[12:56] <didrocks> sil2100: needs cleaning old ones then ;)
[12:57] <sil2100> didrocks: webops are bumping the size for us now, but a cleanup would be good anyway
[12:57] <didrocks> sil2100: yep
[12:59] <sil2100> Bumped to 8G \o/
[12:59] <didrocks> great, please look if we can autoclean some though ;)
[13:05] <cjohnston> ahayzen: look at the crashes.. https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4675/
[13:05] <ahayzen> cjohnston, the process ends before it even has a chance? 'appears process has already exited.'
[13:06] <sil2100> didrocks: sure :)
[13:07] <cjohnston> ahayzen: qmlscene crashed
[13:08] <sil2100> didrocks: if you don't mind, I'll re-run all the stacks, since there's too many singular-cases
[13:08] <ahayzen> cjohnston, ah ... surely can't be from 3 line changes?
[13:08] <didrocks> sil2100: ok, fine
[13:09] <cjohnston> ahayzen: it could be, it could be that there is a problem elsewhere that's causing the crash.
[13:09] <sil2100> seb128: I published libunity-misc, it should be in proposed pretty soon I guess?
[13:10] <ahayzen> cjohnston, it passed once before if u look at the MP https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/199906
[13:10]  * sil2100 has to jump out for lunch and some errands, be back soonish
[13:10] <seb128> sil2100, https://launchpad.net/ubuntu/+source/libunity-misc/4.0.5+14.04.20140115-0ubuntu1
[13:10] <seb128> sil2100, thanks, enjoy lunch!
[13:10] <seb128> sil2100, seems it already built fine on some arch and is building ppc64el atm, let's see how that goes
[13:11] <cjohnston> ahayzen: did trunk change between the two? did something else change between the two? is it maybe something being flaky?
[13:11] <ahayzen> cjohnston, well we thought it was tht so i pulled trunk yesterday but still fails :/
[13:12] <cjohnston> ahayzen: not sure what to tell you. someone will need to investigate the crashes
[13:12] <ahayzen> cjohnston, ok who is best to do tht?
[13:12] <cjohnston> probably the developers for the things that are crashing?
[13:13] <ahayzen> cjohnston, ok, thanks for ur help :)
[14:11] <fginther> morning
[14:12] <timp> cjohnston: about https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/199906
[14:12] <timp> cjohnston: do you have an idea why CI is not running for the changes? (only autolanding which fails)
[14:13] <timp> I'm used to seeing new CI results for each change committed in an MR
[14:13] <cprov> fginther: good morning and thanks for the pointer on the PP upload notifications.
[14:13] <cjohnston> timp: I believe because the person is not Canonical.. fginther ^
[14:13] <cprov> fginther: although, I do not have access to that ML yet
[14:16] <timp> cjohnston: is there a way to trigger it anyway? it would be useful here to get CI results.
[14:18] <cjohnston> timp: I'm not sure about that... its failing because of crashes, so more than likely if those crashes aren't fixed, it's going to keep failing..  it doesn't look like anything has changed since the last time autolanding was run
[14:21] <timp> cjohnston: maybe.
[14:21] <fginther> cjohnston, timp, to answer at least one question, CI jobs are only automatically executed for Canonical people. Further, an MP from a non-Canonical submitter has to be top approved by a member of Canonical.
[14:21] <timp> cjohnston: I duplicated the MR here - https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/201784
[14:22] <timp> so I will see if CI fails there.. if yes, I revert the changes and if CI passes then, that means the original MR is broken.
[14:22] <timp> (in the code).
[14:22] <timp> fginther: yes, I top approved it but it fails. I don't see how the changes can break anything, but perhaps I am missing something.
[14:22] <timp> let's see what happens with my MR
[14:22] <cjohnston> timp: I still believe its failing due to crashes, that may not be from the changes in the MP
[14:22] <timp> cjohnston: yes, it seems like *something* is crashing
[14:23] <fginther> timp, I'm looking for the last known crasher bug, maybe it's rearing its ugly head here
[14:23] <cjohnston> timp: there are a few things crashing
[14:24] <timp> we had some merges in ubuntu-ui-toolkit trunk that passed autolanding these days. just this branch doesn't like to go in for a while now
[14:27] <fginther> cjohnston, timp, This is the bug I was looking for: https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1262982
[14:27] <fginther> cjohnston, timp, It appears to cause what appear to be random crashes. I can't say that is what is causing the failures in the uitk MP, it would need crash analysis to confirm
[14:42] <timp> fginther: the autolanding failures here seem quite consistent. but that could be a coincidense
[14:42] <timp> *coincidence
[15:00] <balloons> sergiusens, didrocks fyi, I have a mp in the works for rssreader
[15:34] <didrocks> balloons: great, with the local xml I guess? just tell us and we'll kick an image once done
[15:37] <ogra_> didrocks, what do we do about calendar ?
[15:39] <didrocks> ogra_: calendar regressed? Sorry a lot going on, couldn't follow latest results
[15:42] <ogra_> didrocks, one qmlscene crash, 10 test failures in the latest image
[15:42] <ogra_> seems a bunch of people looked into it already, but i havent seen the golden shot for a fix yet
[15:43] <didrocks> sergiusens: is it related to the calendar release you wanted? ^
[15:46] <ogra_> didrocks, https://bugs.launchpad.net/unity8/+bug/1268693
[15:47] <ogra_> seems to have come in with the Mir update
[15:47] <didrocks> ogra_: ah, that one is a flakyness issue with Mir, right?
[15:48] <didrocks> psivaa: plars: can you try relaunch the calendar AP tests? To know if it's a flaky issue
[15:48] <ogra_> well, according to davmor2 only 3 out of 10 test runs of calendar passed for him
[15:48] <didrocks> ogra_: Mir didn't change and run on previous isos
[15:48] <didrocks> so, maybe it's a Mir locking up
[15:48] <didrocks> let's see
[15:49] <psivaa> didrocks: ack, just a sec
[15:49] <didrocks> hum
[15:49] <didrocks> yeah, rev 126 was better
[15:49] <didrocks> bue not 125
[15:49] <ogra_> didrocks, well, seems calendar is flaky since 119
[15:50] <ogra_> (according to davmor2 )
[15:50] <didrocks> ogra_: yeah, I'm fetching history back
[15:50] <didrocks> ogra_: which is the latest Mir release
[15:50] <ogra_> right
[15:50] <didrocks> so not a "regression" from latest promoted imagfe
[15:50] <didrocks> just something to put on the list to track
[15:50] <didrocks> sounds legit?
[15:50] <davmor2> didrocks, ogra_: from what I understand it is a mix of possibilities from mir and gfx memory, to system memory, to race in unity app launcher.  And back to mir and gfx memory again
[15:50] <ogra_> well, not sure we can claim that just because we missed the error all the time
[15:51] <cjwatson> seb128: libunity-misc/ppc64el passed, but now unity/ppc64el fails.  Also doesn't look ppc64el-specific, but I'm not sure as I don't really speak C++
[15:51] <didrocks> ogra_: yeah, but we only compared 2 promoted images
[15:51] <ogra_> davmor2, yeah, but we can nail it to a certain time
[15:52] <ogra_> didrocks, the point is, can we call it "not a regression" just because we were lucky and the tests passed for some days by sheer luck
[15:52] <didrocks> ogra_: I didn't tell "not a regression" but "not a regression from latest promoted image"
[15:53] <davmor2> ogra_: it might just be that there is some more memory in use now that wasn't before and that is enough to stop the app running correctly
[15:53] <didrocks> which means, not an image promotion blocker
[15:53] <didrocks> but put on the high priority list as a regression from saucy
[15:53] <ogra_> didrocks, well, that might be true
[15:53] <ogra_> from saucy ?
[15:53] <ogra_> from image 118 rather :)
[15:53] <didrocks> yeah, but in general, I mean ;)
[15:54] <sergiusens> didrocks, calendar only fixes tests; the qmlscene crashes seem to come from the image; I'm losing free ram ;-)
[15:54] <ogra_> didrocks, right, we seemingly released 121 with that
[15:54] <didrocks> sergiusens: buy more! :)
[15:54] <didrocks> ogra_: yeah, thanks for the hilight, I'm adding that to the list
[15:54]  * ogra_ hands sergiusens a soldering iron
[15:54] <didrocks> let's wait on balloons for rssreader and we'll kick an image
[15:54] <ogra_> ++
[15:55] <sergiusens> ogra_, I need someone who understands memory mapping on the emulator ;-)
[15:55] <davmor2> didrocks: he is on the emulator just provide it with more ram surely no need to buy some :D
[15:55]  * ogra_ hands sergiusens an emulated soldering iron then
[15:55] <didrocks> heh
[15:56] <davmor2> sergiusens: blame ogra_ it works for me
[15:56] <ogra_> sergiusens, i dont think the arch used i the emulator understands more than mapping 512M ... we would need a newer qemu version in there
[15:56] <davmor2> sergiusens: please note, it doesn't fix it, it just means you got to blame someone :D
[15:56] <ogra_> iirc rsalveti researched that when we started the emulator work
[16:06] <rsalveti> ogra_: yeah, there's a fix that lool did a few years ago that we might be able to use
[16:06] <rsalveti> but max is still 7xx
[16:06] <ogra_> yeah
[16:06] <rsalveti> other than that it'll overwrite the kernel memory
[16:07] <ogra_> http://people.canonical.com/~lool/qemu-buildd/linux-patches/
[16:08] <psivaa> didrocks: calendar app test rerun has finished with 5 failures (earlier there were 10 failures)
[16:09] <didrocks> yeah, so the flakyness ones
[16:09] <didrocks> ok, thanks for confirming psivaa ;)
[16:09] <psivaa> yw :)
[16:09] <didrocks> rsalveti: balloons: any news on rssreader?
[16:09] <silDroid> Hi guys
[16:10] <balloons> didrocks, I'm stuck in meetings all morning :-( But I want to push the quick fix in
[16:10] <silDroid> I might be a bit late for the meeting, I'm stuck in Katowice right now waiting for a train
[16:10] <silDroid> The last errand left me stranded here :/
[16:11] <didrocks> balloons: do you mean, you are working in parallel? You know that all ubuntu touch work is blocked on that issue, right?
[16:11] <balloons> didrocks, bien sur!
[16:11] <silDroid> We're trying to get home now somehow
[16:11] <didrocks> balloons: merci!
[16:11] <didrocks> silDroid: ok, keep us posted, at worse, read emails :)
[16:12] <silDroid> Sure I think we'll be back in an hour or so, sorry for not being aroun
[16:12] <silDroid> D
[16:12] <silDroid> Ok, time to leave the wifi area
[16:13] <ogra_> didrocks, time you allow him to expense a car ;)
[16:13] <didrocks> ogra_: ahah! I would hate that :p I'm so happy to not have one myself ;)
[16:13] <didrocks> (just renting, like next Saturday, for 3 hours for instance)
[16:14] <ogra_> but he seems to drive cross country by train all the time :)
[16:14] <didrocks> I'm not sure how far Katowice is from him
[16:14] <didrocks> but yeah ;)
[16:14] <ogra_> (my car is rotting in the grarage too ... not the job to have one)
[16:15] <didrocks> exactly
[16:17] <popey> heh, same here
[16:17] <popey> i got in it the other day and all the windows were frozen
[16:17] <popey> (on the inside)
[16:17] <ogra_> heh
[16:18] <didrocks> popey: it was "frozener" in the inside? ;)
[16:18] <popey> it was chuffing cold!
[16:18] <didrocks> (sorry, couldn't resist)
[16:18] <ogra_> really ? i thought the uk is only wet thee days
[16:18] <ogra_> *these
[16:19] <popey> its certainly very wet, yes
[16:19] <popey> cold now and then in the morning
[16:19] <popey> not that I drive it in the morning ☻
[16:19] <ogra_> germany seems to have switched to eternal autumn ... 6°C constantly since 6 weeks
[16:19]  * popey enjoys the commute from upstairs to downstairs
[16:19] <ogra_> and grey
[16:19] <didrocks> ogra_: 6! we had 12-13 here ;)
[16:19] <popey> hey! grey is our colour!
[16:19] <ogra_> popey, heh, me too, my only sports i do
[16:20] <didrocks> 8 today (and gree)
[16:20] <didrocks> but back to 12 on Friday
[16:20] <ogra_> didrocks, we had short warm bumps of 1-2 days ... but the average is 6 ... and that still goes on
[16:20] <didrocks> anyway, it's crazyness…
[16:20] <ogra_> usually it would be -10 or so
[16:21] <didrocks> hah, really cold for you. The average temperature is 3 here in January
[16:21] <ogra_> i'm ~400m high here
[16:22] <didrocks> 162m here ;)
[16:22] <didrocks> well, on one of the 2 hills, it's 305m! :)
[16:22] <didrocks> (and 600 stairs)
[16:22] <ogra_> heh, stairs
[16:22] <didrocks> I was so thin when I was a student, climbing them everyday
[16:22] <didrocks> in the end, I was just reading books and bypassing people in those stairs
[16:23] <ogra_> haha
[16:24] <didrocks> http://dvalot.free.fr/pictures/escaliers/Montee_des_Chazeaux_DSD_0464.jpg (part 1 of the stairs)
[16:25] <ogra_> we only have some fake stairs up the hill here http://de.wikipedia.org/wiki/Bergpark_Wilhelmsh%C3%B6he
[16:25] <didrocks> ah right, it's more for the style than being useful :)
[16:25] <ogra_> in summer they are water cascades
[16:25] <didrocks> oh nice
[16:26] <ogra_> but its all fake ...
[16:26] <ogra_> first disneyland in the world
[16:27] <didrocks> interesting… is that the city as a whole in that spirit?
[16:27] <ogra_> nope ... i think it was but it was completely bombed down in WW2
[16:28] <ogra_> there are no old parts in this city, everything was built after 1950
[16:28] <ogra_> (and it looks like you imagine ... 50-70 architecture is awful)
[16:28] <didrocks> yeah… so less "historical" sense
[16:29] <ogra_> definitely
[16:29] <didrocks> I prefer to not give my so bad option about the 70s architecture :p
[16:29] <didrocks> opinion*
[16:29] <ogra_> heh
[16:29] <balloons> sergiusens, can you check, and approve if it runs ok for you? https://code.launchpad.net/~nskaggs/ubuntu-rssreader-app/fix-add-topic-test/+merge/201809
[16:31] <balloons> popey, perhaps ^^?
[16:31] <popey> sure thing
[16:31] <popey> doing now
[16:39] <seb128> cjwatson, yeah, seems like an issue with zg maybe, something for the unity team to look at, I'm going to ping them
[16:39] <cjwatson> nod, thanks
[16:39] <slangasek> didrocks: hi, so asac has indicated that the rssreader test failure may be fixed now, is that true?
[16:40] <slangasek> didrocks: or do you need more support yet tracking it down?
[16:40] <balloons> slangasek, just testing out on the mp: https://code.launchpad.net/~nskaggs/ubuntu-rssreader-app/fix-add-topic-test/+merge/201809
[16:40] <didrocks> slangasek: it's figured out (I'm going to send an email about it), balloons has a fix, but we need popey/sergio to publish it
[16:40] <didrocks> (to the click store)
[16:40] <slangasek> didrocks: ok cool
[16:41] <didrocks> thanks for proposing the help :) (and yeah, the more testing, the better)
[16:41] <seb128> cjwatson, good news, they already have a fix for the issue up for review
[16:42] <popey> balloons: http://paste.ubuntu.com/6757070/  rss tests failed twice
[16:43] <balloons> popey, your click build didn't push.. look at the version ;-)
[16:43] <ogra_> slangasek, the test used an actual feed (from canonical.com) ... the xml of the feed changed
[16:43] <balloons> popey, you built com.ubuntu.shorts_0.2.163_all.click but ran com.ubuntu.shorts_shorts_0.2.152
[16:44] <popey> hmm
[16:44] <slangasek> didrocks: fwiw, I'm glad to see the mail to ubuntu-devel about this, but I think there was insufficient information included for most people to know where to start looking for regressions - would be great if part of the stop the line procedure could include a pointer to the delta in package versions when the regression was introduced
[16:44] <popey> wonder why
[16:44] <popey> balloons: your script ☻
[16:44] <slangasek> ogra_: right, the last time rssreader had a test failure (for 3 months) was due to a similar issue on the canonical.com rss feed... I would've loved to replace this with local test data, but the qml api doesn't support it :P
[16:45] <balloons> popey, got some tweaks for that to pass on soon ;-)
[16:45] <ogra_> slangasek, well, autopilot should just ship a minimal local webserver ... and mangle the rssreader config to point to localhost
[16:46] <balloons> rss reader is not the only app that has network dependencies
[16:46] <didrocks> slangasek: yeah, I copied that on IRC, should add that to the email, I'll ensure next time we have it
[16:46] <balloons> nor is it the last.. reminders is on the docket to be added to CI (you may not know it yet hah!), and depends on evernote
[16:46] <didrocks> slangasek: btw, do you know why I can't post to ubuntu-devel? I was moderated in each email telling I posted as a Non developer from my @ubuntu.com address
[16:46] <didrocks> slangasek: I tested, I still have uploads rights (thanks to the HUD reverts :p) Nobody demoted me (yet ;))
[16:47] <balloons> popey, running my branch in the emulator too.. did you retry the script?
[16:47] <slangasek> ogra_: installing a local webserver on the phone for autopilot testing? ARGH
[16:48] <didrocks> balloons: we really need autopilot to provide an emulator to factorize this code…
[16:48] <ogra_> slangasek, #/bin/sh ...
[16:48] <balloons> didrocks, we've spoken about this in the past.. we are trying to reduce our dependence, but there isn't a simple answer to be found as of yet
[16:49] <ogra_> slangasek, while true; do { echo -e 'HTTP/1.1 200 OK\r\n'; \
[16:49] <ogra_> #       cat rss.cml; } | nc -l 80; done
[16:49] <balloons> it's definitely on my mind
[16:49] <ogra_> err
[16:49] <ogra_> .xml indeed
[16:49] <slangasek> ogra_: ok, so something we can run from the autopilot dir without having to install a webserver package, that's fine :)
[16:49] <didrocks> balloons: well, not telling you should be the one doing it :)
[16:49] <ogra_> slangasek, yeah, indeed i didnt mean to install apache, just something that returns a file on port 80
[16:50] <slangasek> didrocks: posting to ubuntu-devel> no idea at all, sorry, not an admin on u-d
[16:50] <didrocks> time to look at who is in the admin configuration
[16:53] <popey> balloons: i tried twice
[16:53] <popey> three times in fact
[16:53] <balloons> popey, is it not building the click app?
[16:54] <popey> Successfully built package in './com.ubuntu.shorts_0.2.163_all.click'.
[16:54] <balloons> log perhaps?
[16:54]  * popey fiddles
[16:55] <popey> got it
[16:55] <popey> i had a click in /tmp
[16:55] <popey> and i think your script assumes it generated the only click in /tmp
[16:55] <balloons> the older script yea has some poor assumptions :-)
[16:56] <popey> ok, running 163
[16:56] <balloons> :-) perfect
[16:57] <popey> Ran 3 tests in 117.524s
[16:57] <popey> OK
[16:58] <balloons> woot
[16:59] <sergiusens> slangasek, webbrowser and notes have local webservers as part of their tests; should be doable
[16:59] <slangasek> sergiusens: oh, excellent :)
[17:03] <didrocks> sil2100: cyphermox: kenvandine: robru: around/coming?
[17:03] <robru> didrocks, link? when i try to join the hangout it tells me it's over already
[17:03] <didrocks> https://plus.google.com/hangouts/_/calendar/Y2Fub25pY2FsLmNvbV91cTRvNmQyMWJvNmJ0bm1mcW9xZWtsNTdnOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t.cg7k3h1nmqml7psc1nn68223i0
[17:04] <robru> didrocks, "This party is over.... but you can start a new one"
[17:04] <popey> balloons: Ran 3 tests in 113.386s
[17:04] <popey> OK
[17:04] <kenvandine> didrocks, sorry, in another meeting
[17:04] <popey> good to me
[17:05] <balloons> k, so sergiusens can you push rss reader in? :-)
[17:05] <sergiusens> balloons, yes; the lunch and then I might add that mocking for the webserver if you want
[17:06] <sergiusens> balloons, your MR hasn't merged yet
[17:07] <balloons> sergiusens, :-( Ok.. I blame jenkins bot
[17:07] <balloons> ty popey and sergiusens
[17:07] <sergiusens> fginther, can you speed it up?
[17:07] <balloons> it's running, http://91.189.93.70:8080/job/ubuntu-rssreader-app-autolanding/
[17:07] <fginther> sergiusens, ditto
[17:08] <sergiusens> cheerio
[17:09] <fginther> sergiusens, merged
[17:20] <didrocks> sergiusens: we're at you!
[17:20] <didrocks> looking*
[17:20]  * didrocks shouldn't eat words
[17:20] <sergiusens> didrocks, I'm here
[17:20] <sergiusens> just building the click
[17:20] <didrocks> sergiusens: just tell us once publish and I'll kick an image
[17:20] <didrocks> thanks man :)
[17:23] <sergiusens> popey, https://myapps.developer.ubuntu.com/dev/click-apps/155/
[17:23] <sergiusens> np
[17:26] <popey> sergiusens: ack
[17:28] <sergiusens> didrocks, do you have access to snakefruit?
[17:29]  * sergiusens thinks he asked this already
[17:29] <popey> sergiusens: approved
[17:30] <didrocks> sergiusens: yeah
[17:36] <sergiusens> didrocks, you can force sync the click packages for building if you want; there's a cronned click-sync.py in there
[17:37] <sergiusens> if not, I think it will trigger at :10 or :43 iirc
[17:37] <didrocks> sergiusens: do you know if it's in the archive admin one?
[17:37] <didrocks> account?
[17:38] <cjwatson> it is
[17:38]  * didrocks looks
[17:38] <cjwatson> it's at 11,41 * * * *
[17:38] <didrocks> ok, no need to win 3 minutes then ;)
[17:38] <didrocks> (seeing it)
[17:44] <sergiusens> didrocks, seems ok to trigger now
[17:44] <sergiusens> the image build
[17:44] <didrocks> sergiusens: done!
[17:44] <didrocks> balloons: FYI ^
[17:45] <didrocks> plars: can you please ensure we are getting results for images 130? it's an important one :)
[17:45] <didrocks> (once built of course :p)
[18:13] <plars> didrocks: will do
[18:15] <sil2100> kenvandine: hello! Do you have a moment for https://code.launchpad.net/~sil2100/cupstream2distro-config/extra_packages_for_stacks/+merge/201820 ? ;)
[18:23] <timp> cjwatson: so my copy of the MR that was crashing gets good results for CI
[18:23] <timp> cjwatson: see https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/199906 and https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/201784
[18:23] <timp> cjwatson: the .crash files don't tell me more :s
[18:24] <robru> sil2100, approved
[18:24] <sil2100> robru: thank you! ;)
[18:25] <robru> sil2100, you're welcome
[18:25] <timp> robru: perhaps you have an idea? something (qmlscene?) is crashing here for autolanding https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/199906
[18:25] <timp> CI passes on my copy of the MR, so maybe I can get that one merged... but still it is weird.
[18:27] <timp> perhaps we need a unity developer to have a look at it?
[18:27] <robru> timp, very weird. the traceback looks like it has something to do with autopilot's interactions with dbus. beyond that I couldn't say why.
[18:27] <robru> timp, maybe you should ping thomi about it
[18:29] <timp> robru: ok. at what time does he usually come online?
[18:29] <robru> timp, hmmm, not sure. maybe email him for now?
[18:29] <timp> okay
[18:29] <ahayzen> timp, for the past two days he has been in meetings at this sorta time
[18:30] <ahayzen> timp, i was talking to him about other autopilot issues lol
[18:30] <timp> it seems like he is in new zealand where it is 7:30 in the morning now
[18:30] <timp> if I were him, I would be sleeping
[18:30] <timp> I'll mail him :)
[18:31] <timp> ahayzen: what's your e-mail address? I can cc you
[18:31] <ahayzen> timp, ahayzen@gmail.com
[18:36] <fginther> timp, ahayzen, if you're talking about https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/199906, the autopilot trace backs are caused by the app not being there, probably because of the qmlscene crash
[18:37] <timp> fginther: yes that is what we are talking about
[18:37] <timp> fginther: I copied the same MR here, and there CI passes https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/201784
[18:38] <timp> fginther: what does it mean the app not being there? which app is that? the UITK gallery app? or something else?
[18:40] <timp> fginther: which log file are you looking at?
[18:40] <fginther> timp, I don't know the exact mechanics, the process launched is qmlscene which matches the crash file
[18:40] <fginther> the log file is https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4675/consoleFull
[18:40] <fginther> the messages "testcase:566 - Appears process has already exited." indicates the process died before autopilot finished the test
[18:41] <timp> so qmlscene is missing?
[18:41] <timp> can be that it crashed immediately after starting?
[18:41] <fginther> it crashed: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4675/artifact/results/crash/_usr_lib_arm-linux-gnueabihf_qt5_bin_qmlscene.32011.crash
[18:41] <timp> I have to leave now unfortunately. it is late here.
[18:41] <fginther> timp, yes, it could have crashed first thing
[18:42] <fginther> timp, as I mentioned earlier, this bug is believed to cause these type of random crashes: https://bugs.launchpad.net/unity-mir/+bug/1262982
[18:42] <fginther> but someone would need to trace the crash to confirm
[18:43] <fginther> timp, have a good night
[18:51] <ahayzen> timp, fginther, thanks for ur help so far guys
[19:45] <thomi> fginther: A while ago you forwarded me an email thread containing instructions to retrace crash files from the phone...
[19:45] <thomi> I'm trying to use those instructions to retrace crash files produced by the medium tests runner
[19:46] <thomi> but it seems the first step (apport-cli) needs to be run on the device
[19:46] <thomi> so... is there any way I can get a stack trace from the crash files here? https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4675/
[19:51] <ahayzen> thomi, tht branch tht was failing just landed https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/199906 .. guess it was a random error then?
[19:55] <thomi> ahayzen: oh, ok, I'll stop looking into it then :)
[19:55] <thomi> but I think this is a pretty serious issue that we need to fix in general, even if we've landed that one branch
[19:55] <ahayzen> thomi, probably tht Mir bug?
[19:56] <ahayzen> thomi, meanwhile i didn't manage to get any further with the other issue i was having, with the MediaPlayer not appearing :/
[19:57] <thomi> ahayzen: I did start looking at it yesterday, but ran out of time. I should be able to get back to it today
[19:57] <ahayzen> thomi, cool thanks
[19:57] <ahayzen> thomi, is there a bug for it?
[19:58] <thomi> ahayzen: not AFAIK, feel free to file one against autopilot-qt
[19:58] <ahayzen> thomi, will, shall i link both the music-app and the simple example branches to it?
[20:02] <thomi> ahayzen: yes pelase
[20:03] <ahayzen> thomi, awesome...i'll ping u the bug number when done :)
[20:03] <thomi> thanks
[20:06] <jdstrand> lines 199 and 200 of the landing asks state that dbus and apparmor are in the landing plan, line 377. line 377 does not exist
[20:08] <jdstrand> I'll adjust
[20:09] <ahayzen> thomi, https://bugs.launchpad.net/autopilot-qt/+bug/1269578 ... think i've done it right
[20:09] <thomi> ahayzen: thanks
[20:12] <fginther> thomi, I need to that retrace added to the touch testing, but at the moment, you don't require it, correct?
[20:26] <thomi> fginther: sorry, took me a moment to parse that :)
[20:26] <thomi> fginther: today, the specific issue I was looking at has been fixed
[20:26] <thomi> fginther: but I imagine it'll come up again./.. and agian, and again :)
[20:27] <fginther> thomi, agreed (man I wish I had oodles of time)
[20:27] <thomi> heh, me too
[22:06] <cjwatson> timp: I don't know anything about the pieces involved in your CI failure earlier; I see it's Merged now so I guess you got it sorted out
[22:06] <dobey> do i need to ping someone to poke at approving a NEW package?
[22:06] <dobey> for the whole landing process thing
[22:09] <robru> dobey, are you talking about ubuntu-purchase-service? i thought didrocks was supposed to take care of that, but I think he forgot. in general we need an archive admin, but i worry that didrocks might be the only person who knows what to do
[22:10] <cjwatson> I know how to NEW things in general but I'm reluctant to touch something that I know didrocks was already in the process of reviewing
[22:11] <dobey> robru: i am
[22:12] <cjwatson> So it's more about not wanting to step on toes than about lack of knowledge
[22:12] <robru> cjwatson, well, didrocks already reviewed and approved it, but when I published it, it didn't get into -proposed. so whatever archive robot is responsible for taking daily_release publications and uploading them into -proposed, that piece of the puzzle is missing. do you know how to fix it? if so, please do, as didrocks already approved everything.
[22:12] <cjwatson> (That said, I have no real idea how the whole preNEW process works, but ubuntu-purchase-service is apparently past that)
[22:12] <cjwatson> robru: no, it's not a robot's job at this point
[22:12] <cjwatson> robru: it's awaiting *manual* review
[22:13] <dobey> right, didrocks reviewed a previous package and we fixed the issues and a new version is up
[22:13] <cjwatson> robru: it's 10pm here; if somebody hasn't done it by tomorrow morning then I'll look at it, but I'm not up for it now
[22:13] <robru> dobey, yeah, and then he saw my MR and said "great, publish that once it lands" which sounds like an approval to me
[22:13] <dobey> cjwatson: go rest :)
[22:14] <dobey> robru: right; but you're not an archive admin :)
[22:14] <robru> cjwatson, ha, ok.
[22:14] <cjwatson> https://launchpad.net/ubuntu/trusty/+queue?queue_state=0&queue_text=ubuntu-purchase-service <- here it is awaiting manual review
[22:14] <dobey> nor am i
[23:31] <timp> cjwatson: I don't know why the autolanding on that MR failed before, or why it passed now. It may be some random crash that is not fixed yet.
[23:31] <timp> cjwatson: I'll summarize it like this: I have no idea what's happening