[01:18] <cjohnston> dobey: not a clue
[01:18] <cjohnston> Saviq: your unity-mir issue should be fixed
[01:19] <Saviq> cjohnston, may I ask what's the resolution?
[01:21] <cjohnston> Saviq: the workaround provided by didrocks
[01:21] <cjohnston> not using the ppa
[01:22] <Saviq> cjohnston, ok yeah, still need mir to be published, since the unity-mir built in the mbs / local upstream merger repo already has unity-mir built against mir 0.1.2
[01:22] <Saviq> cjohnston, that will help us long-term, though
[01:23] <cjohnston> Saviq: I don't think I have the ability to do anything with that
[01:23] <Saviq> cjohnston, yeah, for that we'll just have to wait, thanks
[01:23] <cjohnston> and I believe it still requires code work on the Mir side
[01:29] <Saviq> cjohnston, yeah, I'm just building / testing the whole mir stack to confirm it's working
[03:25] <Ursinha> tedg, ogra_, et al.: I'm using r34 and still experience bug 1253703
[08:45] <didrocks> ogra_: hey, seeing you online, mind kicking a new image?
[08:45] <ogra_> [08:46] <ogra_> wow
[08:46] <ogra_> r34 on mako looks *really* bad
[08:46] <ogra_> and only 3 packages changed ...
[08:46] <didrocks> yeah
[08:47] <didrocks> not sure if it's just because of "not enough relaunch" or something else
[08:47] <didrocks> let's wait on psivaa :)
[08:47] <ogra_> well, maguro improved ...
[08:47] <didrocks> ogra_: I guess webbrowser-app is for a lot
[08:47] <didrocks> (on mako)
[08:48] <didrocks> basically half of the failures
[08:48] <ogra_> yeah
[08:48] <ogra_> and notes is stuck once again
[08:48] <didrocks> I bet something horrible happened
[08:48] <didrocks> yeah
[08:49] <didrocks> I think psivaa needs to talk to Osomon
[08:49] <didrocks> as Bill is on holidays
[08:49] <didrocks> so that this is looked at
[08:49] <ogra_> i wonder if it is related to the bug above
[08:58] <psivaa> morning
[08:59] <psivaa> didrocks: ogra_ : let me take a look at mako runs
[08:59] <didrocks> hey psivaa! thanks
[09:24] <didrocks> ogra_: browser app sounds good to me on mako
[09:24] <didrocks> just trying locally
[09:26] <ogra_> do you mean regarding the bug or regarding the tests ?
[09:28] <didrocks> regarding the tests
[09:28] <didrocks> I'm trying to reproduce the same here
[09:29] <sil2100> :q
[09:29] <sil2100> Damn, wrong window
[09:29] <didrocks> hey sil2100 :)
[09:30] <popey> landing call?
[09:30] <sil2100> \o/
[09:30] <sil2100> Hello!
[09:36] <ogra_> bug 1253703
[09:40] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/20131128.changes
[09:40] <ogra_> changes of r35 ^^^
[09:53] <ogra_> [10:01] <psivaa> didrocks: ogra_: could not complete the notes app test on mako with r34 because the tests have started with r35
[10:01] <didrocks> psivaa: ok, let's take that one as the base
[10:01] <psivaa> didrocks: ack
[10:49] <Saviq> psivaa, hey, we need to enable the daily-build ppa for a merge on unity8 and unity-mir, I've added the hook when starting the job, but it doesn't seem like it's executed http://s-jenkins.ubuntu-ci:8080/job/unity-mir-trusty-armhf-ci/30/console ?
[10:49] <Saviq> ah builder_hooks?
[10:49] <psivaa> Saviq: let me take a look
[10:50] <Saviq> hmm no, that's not a parameter that I have access too
[10:50] <Saviq> -o
[10:58] <Saviq> psivaa, cjohnston changed the default configuration of the unity-mir- jobs to not include the daily-build ppa, maybe that's of interest (bug #1255578)
[11:00] <psivaa> Saviq: ok, this is for otto run. not sure how that impacts here.
[11:01] <Saviq> psivaa, well, otto run is affected, the hooks were global on both -ci and -autolanding jobs
[11:01] <Saviq> psivaa, i.e. unity-mir got built against daily-build, so then no job in the unity8 stack, that doesn't include the daily-build ppa, would fail
[11:12] <psivaa> vila: would you mind helping me out on the Saviq's req please. fginther being on holiday i dont want to make a change that i dont fully understand :)
[11:15] <vila> psivaa: not sure I know more than cjohnston there, I've been mostly involved in [re]setting otto nodes rather than the cu2d part that drive them.
[11:15] <vila> so,
[11:16] <vila> my understanding was that a wrong package version was put in a ppa (is that correct ? which ppa ?)
[11:17] <vila> and that cjohnston's MP will do the right thing by *not* referring to that ppa
[11:17] <vila> Saviq: ^
[11:17] <Saviq> vila, no
[11:17] <Saviq> vila, the problem was: unity-mir-autolanding ran against ppa:ubuntu-unity/daily-build - by default
[11:18] <Saviq> vila, the resulting package got put in the mbs repo for unity8 stack
[11:18] <vila> mbs ?
[11:18] <Saviq> vila, those are local repositories built per stack from -autolanding jobs
[11:19]  * vila nods
[11:19] <Saviq> vila, so whatever was trying to use that mbs repo and install libunity-mir1 for that, would fail if it didn't also have ppa:ubuntu-unity/daily-build enabled
[11:19] <Saviq> vila, hence the bug
[11:20] <vila> Saviq: oh, the other way around then ? An additional ppa needs to be added ?
[11:20] <Saviq> vila, the solution applied (correctly) was that unity-mir-ci nor -autolanding would run against daily-build
[11:20] <vila> Saviq: lacking context, I'm trying to understand what the fix should be, cleaning a ppa ? Adding a ppa as a parameter somewhere ? Rebuild something ?
[11:21] <vila> bumping a revision to override the mess ? ;)
[11:21] <Saviq> vila, misunderstanding
[11:21] <Saviq> vila, the above bug is fixed long-term
[11:21] <vila> Saviq: how ?
[11:21] <Saviq> vila, by removing the ppa from unity-mir-ci and -autolanding jobs
[11:21] <vila> in cu2d-config for that stack ?
[11:22] <Saviq> vila, I think so, yes
[11:22] <vila> Saviq: ok, progress, that was cjohnston work and MP right ?
[11:22] <Saviq> vila, yes
[11:22] <vila> ok, at least I've followed some bits
[11:22] <Saviq> vila, now, I triggered http://s-jenkins.ubuntu-ci:8080/job/unity-mir-ci/169/rebuild/?
[11:22] <Saviq> vila, with *manually added* daily-build ppa
[11:22] <Saviq> vila, i.e. D09add_ppa~ubuntu-unity~daily-build
[11:23] <vila> Saviq: as a one-off or should that become the default ?
[11:23] <Saviq> vila, one-off
[11:23] <Saviq> because we need to transition to mir 0.1.2, which is only daily-build
[11:23] <Saviq> vila, and here comes the issue:
[11:23] <Saviq> vila, the hook wasn't executed it seems
[11:23] <Saviq> vila, http://s-jenkins.ubuntu-ci:8080/job/unity-mir-trusty-armhf-ci/30/console
[11:24] <vila> O_o
[11:24] <Saviq> vila, it's there in hooks=D09add_ppa~ubuntu-unity~daily-build
[11:24] <Saviq> vila, but not in Pbuilder_hooks any more
[11:24] <Saviq> and there's basically no mention of it past the parameter printing
[11:25] <vila> http://s-jenkins.ubuntu-ci:8080/job/unity-mir-trusty-armhf-ci/30/parameters/? mentions it right
[11:25] <Saviq> vila, as opposed to http://s-jenkins.ubuntu-ci:8080/job/unity-mir-trusty-armhf-ci/27/console - which was yesterday, and had the same hook by default
[11:25] <Saviq> vila, yes, it's even mentioned in the console output at the top
[11:25] <Saviq> vila, which leads me to think the hook got removed completely, and was hence ignored?
[11:25] <vila> right, I can see that (thanks)
[11:25] <vila> Saviq: removed from what ?
[11:26] <Saviq> vila, from wherever the hooks are picked up from
[11:26] <Saviq> vila, I mean the hook as in the actual script
[11:26] <Saviq> vila, that's just a suspicion, no reason to believe me :)
[11:26] <vila> hmm, deployment issue you mean ? (As in, the jobs are correct but rely on stuff installed on the slaves)
[11:26] <vila> ha
[11:27] <vila> psivaa: did you look at the playbook ?
[11:28] <psivaa> vila: hmm no, sorry my bad
[11:28] <vila> psivaa: oh, now, just wanted to check if you knew something I didn't ;)
[11:29] <Saviq> vila, psivaa, going for food, biab or ping me if needed
[11:29] <vila> Saviq: Disable unity-mir use_stack_ppa until Mir transitions their ABI. rings a bell ?
[11:29] <vila> Saviq: that's the last config that has been deployed http://s-jenkins.ubuntu-ci:8080/job/deploy-cupstream2distro-config/113/
[11:30] <vila> Saviq: ha, hmm, well, I'd better do the same to maximize the overlapping then ;)
[11:30] <vila> psivaa: when do you intend to lunch ? ;)
[11:32] <psivaa> vila: normally in about 90 mins.. but could move it to suite :)
[11:32] <vila> psivaa: up to you, if you prefer to keep digging that one, just leave notes here
[11:32] <Saviq> vila, well, it's not "until", but it should just not be enabled by default - daily-build is unsafe, as things there might never end up in distro, if they fail QA
[11:33] <psivaa> vila: ack, will do a bit more..
[11:33] <vila> Saviq: fginther knows about that ? I'm quite surprised this hasn't been encountered in the past and I'd feel better if mir was a special case instead :-/
[11:34] <vila> Saviq: but let's have lunch first ;)
[11:48] <psivaa> Saviq: i added D09add_ppa~ubuntu-unity~daily-build as a builder hook and re-running the job. http://s-jenkins.ubuntu-ci:8080/job/unity-mir-trusty-armhf-ci/31/console
[11:48] <psivaa> looks like that's progressing and i have not made any changes to the configs since this is one off
[11:57] <psivaa> Saviq: vila: and that run has succeeded.
[11:58] <Saviq> psivaa, what's the difference between hooks and builder_hooks?
[11:58] <Saviq> psivaa, and how can I supply builder_hooks?
[11:58] <psivaa> Saviq: i dont know the difference between them yet, i could findout
[11:58] <psivaa> Saviq: builder_hooks was part of the rebuild parameters,
[12:01] <Saviq> psivaa, do you have it here http://s-jenkins:8080/job/unity-mir-ci/169/rebuild/? ?
[12:01] <Saviq> psivaa, I only see "hooks"
[12:01] <Saviq> psivaa, maybe that's the problem then?
[12:01] <Saviq> that that parameter isn't "published"
[12:02] <Saviq> psivaa, from the names I'd assume hooks was used for otto runner, for example, where builder hooks were used by builders
[12:02] <Saviq> psivaa, so the hook basically needs adding in both, but I don't see builder_hooks as a parameter I can modify
[12:06] <psivaa> Saviq: yes, i dont see it in the master job. may be builder_hooks is not intended to be a published parameter.
[12:06] <psivaa> not sure if there was a reason for that and the builder hooks should not vary between runs
[12:07] <Saviq> psivaa, at least some time ago we were able to add hooks to "hooks" parameters and they would get picked up everywhere - for both builders and runners
[12:08] <Saviq> psivaa, so something changed there :/
[12:08] <Saviq> psivaa, let me file a bug
[12:11] <Saviq> psivaa, bug #1255948
[12:11] <psivaa> Saviq: thanks. looks like the change has happened after 26th.
[12:12] <Saviq> psivaa, please let me know if you don't find a reason/solution you're comfortable with, we'll have to force push the two MPs for unity8 and unity-mir
[12:14] <psivaa> Saviq: ack
[12:22] <vila> psivaa: \o/
[12:23] <vila> psivaa: all good for the short term ?
[12:23] <psivaa> vila: not yet completely, the parameters are not propogated to the child jobs
[12:23]  * vila thinks a bug is the right thing to do here, this seems like a deeper issue
[12:24] <vila> psivaa: yup, but you are able to trigger the required jobs to unblock Saviq right ?
[12:24] <Saviq> vila, no, you can only trigger the downstream jobs correctly
[12:24] <psivaa> vila: yep ^
[12:25] <Saviq> vila, so no way to run the whole -ci or -autolanding job, as there's no way to add the hook to builder_hooks there
[12:26] <vila> Saviq: I got that, hence the bug. How many job triggers do you need ? 1, 2 ? Or is this something you need for the coming days, weeks ?
[12:26] <Saviq> vila, 2 MPs
[12:26] <vila> Saviq: fginther is in vacations until next Monday and I'm far from sure we can fix that properly until then...
[12:26] <Saviq> vila, so we'll just merge manually
[12:27] <vila> Saviq: right, so manual workaround should get you out of trouble right ?
[12:27] <Saviq> vila, yes
[12:31]  * vila blinks
[12:31] <vila> Saviq: hmm, how about     hooks: H05set_package_version D00mbs_archive A10checklicenseheaders
[12:32] <Saviq> vila, what about it? that's the default hooks?
[12:32] <vila> Saviq: tha'ts in cu2d-config/stacks/unity8.cfg with some different ones for unity-api and unity-mir
[12:32] <vila> Saviq: and that doesn't match your needs ?
[12:33] <Saviq> vila, default is fine
[12:34] <Saviq> vila, problem was with one-off changes
[12:34] <Saviq> s/was/is/
[12:34] <Saviq> vila, when you want to override the defaults for whatever reason
[12:34] <Saviq> vila, you can't - 'cause the "hooks" param does not propagate to "builder_hooks"
[12:34] <Saviq> so, in effect you can't override builder_hooks
[12:35] <vila> Saviq: ok, let's wait for fginther , was just having a look at the config in case it provides a different workaround but that would require two deployments, not good for 2 landings ;)
[12:36] <Saviq> vila, yeah, doesn't make sense to deploy just for this
[12:37] <didrocks> ogra_: that's not really accurate
[12:37] <didrocks> "
[12:37] <didrocks> As some might have noticed we recently had a few bad image releases into
[12:37] <didrocks> the Trusty channel that contained regressions. "
[12:37] <didrocks> we landed one images with some regressions
[12:37] <didrocks> then, we only get images to fix some of them
[12:37] <ogra_> three if i didnt miscount
[12:38] <didrocks> they didn't add more regressions
[12:38] <ogra_> (two of them to fix the rehgressions but still knowingly shipping others)
[12:38] <didrocks> ogra_: shipping new regressions?
[12:38] <ogra_> no
[12:38] <didrocks> ogra_: that's what you are implying
[12:38] <didrocks> in your email
[12:39] <ogra_> we had trhee regressions and released one image that still had two and one image that still had one
[12:39] <ogra_> which makes multiple images with regressions
[12:39] <ogra_> (and we had regressed images before, its just one current example)
[12:40] <didrocks> ogra_: hum, "a few images with regressions" sound like we have new images promoted regressing previous promoted image
[12:40] <ogra_> but thats not what i said
[12:40] <didrocks> that's how it can be read :)
[12:40] <seb128> didrocks, let's not focus on unprecise wording, that's not the main point of that email
[12:40] <didrocks> seb128: still, I think that set a false perception
[12:41] <didrocks> but anyway
[12:41] <seb128> yeah, it is
[12:41] <ogra_> my main point is that i want public meetings with community testers participating ... and that i want to take load off the landing team
[12:41] <seb128> not worth arguing over though, it's written/send and hopefully a detail people are not going to stop on
[12:41] <didrocks> let's see…
[12:42] <ogra_> and if that isnt coming out clear i'll correct this in a followupü
[12:42]  * didrocks waits now on managers reaction "why did we land multiple images with regressions"
[12:42] <didrocks> well, that will be be direct pings I guess
[12:42] <ogra_> because we didnt wait with releaseing until all regressions were fixed
[12:42] <didrocks> ogra_: which was a good thing, right?
[12:42] <ogra_> but fixed them one by one
[12:42] <didrocks> or we will still wait
[12:43] <ogra_> not sure ... i would presonally have waited but i didnt want you to have even more pressure from above
[12:43] <ogra_> (which is what a community based team should solve as well)
[12:43] <ogra_> (as long as there are clear policies)
[12:43] <didrocks> let's see
[12:46] <ogra_> in any case i think the release process deserves a lot more attention ... and i also think the landing team doesnt need to have 2 2h meetings just because of that ... which is why i propose a new team with wider participation and more focus
[12:47] <didrocks> ogra_: 2h meetings?
[12:48] <didrocks> most of our meetings are under 20 minutes, if not 15
[12:48] <ogra_> didrocks, going through the buglist one by one, collecting info from more testers and other teams etc ...
[12:48] <ogra_> that would add up
[12:48] <didrocks> ah, you mean, if we collected
[12:48] <ogra_> right
[12:49] <ogra_> we have a huge community and i bet we can get a ton of people to participate more in testing if we would give them a voice in a public meeting
[12:49] <ogra_> these two points make me suggest a new team
[12:50] <ogra_> (and the hope that it frees up landing resources)
[13:05] <psivaa> Saviq: vila: i could not modify the config of the master job to pass the new parameter with rebuilds.. but the child jobs pass individually when the parameter is passed to them
[13:06] <psivaa> so if you want to force merge the MP, i have no objections
[13:06] <Saviq> psivaa, yeah, I will just trigger generic-land manually
[13:06] <Saviq> psivaa, once mir gets published, we're back on track
[13:07] <Saviq> psivaa, bug still needs fixing, but we're unblocked at least
[13:07] <psivaa> but i've assigned the bug to fginther, ill subscribe to it/
[13:07] <psivaa> sorry could not help more
[13:07] <psivaa> s/but//
[13:15]  * didrocks goes for a run
[14:42]  * ogra_ files bug 1255999
[14:47] <didrocks> ogra_: let me upgrade and reproduce
[14:47] <didrocks> ogra_: can't reproduce on image r32 on mako FYI
[14:48] <ogra_> how long did you run it yet
[14:48] <vila> ogra_: bonus points for triple 9 ?
[14:48] <didrocks> ogra_: since this morning
[14:48] <didrocks> I'm still on image 32, didn't reboot
[14:49] <didrocks> ogra_: and you don't tell it's not from the start
[14:49] <vila> ogra_: can't reproduce in messaging (nor anything I tried since I installed r34)
[14:49] <ogra_> didrocks, well, on my mako it runs since we promoted it ...
[14:49] <vila> ogra_: but I've seen it here on there for ages
[14:49] <didrocks> ogra_: so, maybe you should tell that it's after a while :)
[14:49] <didrocks> and try to find a reproducer :p
[14:49] <didrocks> ogra_: did you switch your language?
[14:49] <ogra_> well, i see it on two devices
[14:49] <ogra_> the maguro was updated this morning
[14:49] <vila> ogra_: which app ?
[14:50] <ogra_> any
[14:50] <ogra_> settings app, searching in the shell
[14:50] <ogra_> browser too
[14:50] <vila> shell and browser ok here
[14:51] <ogra_> is your device properly set up in french and all ?
[14:51] <didrocks> ogra_: can you tell it's after a while and not on startup? Otherwise, people will close it with not reproduceable here
[14:51] <didrocks> ogra_: I get that in French for a while, it's in english right now
[14:51] <vila> settings ok too :-/
[14:52] <ogra_> yep, just rebooted the maguro ... no kbd coming up
[14:53] <ogra_> let me reboot the mako
[14:53] <vila> ogra_: I've subscribed to the bug (and commented), I won't call it a regression though
[14:54] <ogra_> i didnt have that issue every with image 10
[14:54] <ogra_> *ever
[14:55] <didrocks> ogra_: I've always seen that randomly, I can ensure you
[14:55] <ogra_> so to me thats clearly a regression
[14:55] <didrocks> even with 1.0
[14:55] <didrocks> maybe it's more often now
[14:55] <didrocks> but would be interesting to know exactly how you trigger it
[14:55] <didrocks> so that upstream can fix
[14:55] <ogra_> i didnt do anything special
[14:56] <didrocks> I don't do anything special and have it
[14:56] <didrocks> ogra_: is your system in German?
[14:56] <ogra_> my mako was ugraded to 32 when we released that ... i must admit i didnt use it much since ... but it constantly ran ... today i tried to search in it for the first time
[14:56] <ogra_> yes
[14:57] <ogra_> (thats why i asked if you guys use french setup)
[14:57] <didrocks> ogra_: ok, yeah, on that one, but it was even before image 10
[14:57] <didrocks> like I saw it on 1.0
[14:57] <didrocks> I reswitched to english since
[14:57] <ogra_> i have never had it
[14:57] <didrocks> let me try to switch to French
[14:57] <ogra_> on a stable image
[14:57] <didrocks> I got it, not 100%, but got this
[14:58] <ogra_> (i have seen it on -proposed images before for sure ... )
[14:58] <didrocks> ok, switched to French
[14:58] <didrocks> no issue
[14:58] <didrocks> let me reboot
[15:01] <didrocks> (long to boot…)
[15:01] <vila> ogra_: english setup here
[15:01] <ogra_> apport ...
[15:01] <didrocks> ogra_: confirming in French
[15:01] <didrocks> let me see if there is a crash file
[15:02] <ogra_> my maliit log is empty :(
[15:02] <didrocks> yeah, no crash either :/
[15:02] <didrocks> maliit-server is running
[15:02] <ogra_> here as well
[15:04] <didrocks> ogra_: WARNING: no dictionary to turn on spellchecking
[15:04] <didrocks> I wonder if that can be it
[15:04] <ogra_> oh, where is that from ?
[15:04] <didrocks> ogra_: ~phablet/.cache/upstart/maliit-server.log
[15:04] <didrocks> do you confirm?
[15:04] <ogra_> no
[15:04] <ogra_> as i said above
[15:04] <ogra_> mine is empty
[15:05] <ogra_> root@ubuntu-phablet:/# cat /home/phablet/.cache/upstart/maliit-server.log
[15:05] <ogra_> __pthread_gettid -2
[15:05] <ogra_> __pthread_gettid -2
[15:05] <ogra_> __pthread_gettid -2
[15:05] <didrocks> I have that one top
[15:05] <didrocks> before the classic:
[15:05] <didrocks> WARNING: QOpenGLShader::link: "--From Fragment Shader:
[15:05] <didrocks> --From Vertex Shader:
[15:05] <didrocks> Link was successful.
[15:05] <didrocks> "
[15:05] <ogra_> well, thats all i have
[15:05] <didrocks> hence "classic" ;)
[15:06] <ogra_> no, i mean the above is all thats in there
[15:06] <ogra_> only the hybris noise
[15:06] <didrocks> ah…
[15:06] <didrocks> ogra_: ok, clearly, local-dependant
[15:07] <ogra_> right
[15:07] <didrocks> ogra_: adding infos to the bug report
[15:08] <didrocks> done
[15:09] <ogra_> thx
[15:10] <didrocks> ogra_: nice catch btw, I think it's not the same bug that vila and I were talking about
[15:10] <didrocks> like, sometimes, the keyboard will never ever come up again
[15:10] <didrocks> and you have to reboot
[15:10] <ogra_> havent had that on the stable one
[15:10] <ogra_> my mako explicitly only runs trusty, not proposed
[15:10] <didrocks> you were lucky, I was using French all the time, and after 10 minutes of playing, I clearly had that
[15:11] <ogra_> wow
[15:11] <ogra_> but you also have that dictionary error
[15:11] <didrocks> yeah, I wonder if that's really linked or the previous session
[15:11] <ogra_> i wonder how german and french langpacks differ here
[15:11] <didrocks> do you know about upstart session job?
[15:11] <ogra_> well, rm the log and reboot
[15:12] <didrocks> like, the logs are reset at each login?
[15:12] <didrocks> yeah
[15:12] <ogra_> i dont think they are
[15:12] <didrocks> doing that, hoping that upstart won't be upset by that
[15:12] <ogra_> they are just adding up until logrotate rotates them i think
[15:12] <didrocks> ok
[15:12] <didrocks> so no handler on the file?
[15:12] <didrocks> (done, and rebooting)
[15:12] <ogra_> probably while the session runs
[15:13] <ogra_> but not before or after
[15:13] <didrocks> ok
[15:13] <didrocks> ogra_: yeah, that came from an english session I guess
[15:13] <didrocks> nothing anymore apart from the libhybris one
[15:14] <ogra_> right, so the same as i see
[15:14] <didrocks> yep
[15:14] <didrocks> so, let's extrapolate anything != english
[15:14] <didrocks> that would be easy for them to reproduce
[15:14] <ogra_> yeah
[15:14] <ogra_> btw, does your clock show a proper 24h time ?
[15:15] <didrocks> no, it's 4:15
[15:15] <didrocks> I didn't konw I worked that long :p
[15:15] <ogra_> yeah :(
[15:15] <ogra_> a recent change made it drop the AM/PM ...
[15:16] <ogra_> but the format is still wrong it seems
[15:16] <didrocks> right
[15:16] <didrocks> indicator-datetime maybe?
[15:16] <ogra_> which now makes it look really weird
[15:16] <didrocks> we really need to have tests for those
[15:16] <ogra_> i had a bug open and just transferred it into a whishlist for session-migration today
[15:16] <ogra_> seems i was to fast
[15:17] <didrocks> oh! let me look at it
[15:18] <didrocks> ogra_: ah, session-migration is just a helper
[15:18] <ogra_> bug 1255530
[15:18] <didrocks> ogra_: it doesnt' contain any script
[15:18] <didrocks> so indicator-datetime contains the script and use session-migration
[15:18] <ogra_> it uses scripted backends, doesnt it ?
[15:18] <didrocks> yeah, and those are just scripts :)
[15:18] <ogra_> right
[15:19] <didrocks> so, indicator-datetime just ship a script
[15:19] <didrocks> call dh_migration
[15:19] <ogra_> well, that wont help the above case
[15:19] <ogra_> unless pam starts shipping such a script
[15:19] <ogra_> s/case/bug/
[15:20] <didrocks> yeah, that's the idea
[15:20] <didrocks> hum, btw, session-migration won't work on the phone, that's the issue
[15:20] <didrocks> we need to hook it into upstart
[15:20] <ogra_> we have it installed :)
[15:20] <didrocks> (it was hooked in gnome-session)
[15:20] <didrocks> I doesn't do a lot I guess then :p
[15:21] <ogra_> well, we should have another bug for that one then ;)
[15:21] <didrocks> yep ;)
[15:21] <didrocks> ogra_: we should rewrite it in Go as well ;)
[15:22] <didrocks> ah no, it's C, it's fine :p
[15:22] <ogra_> i dont think it is overly important right now
[15:22] <didrocks> (with, hem, perl, for debhelper)
[15:22] <ogra_> but we should look at it before the next stable goes out
[15:22] <ogra_> (before release)
[15:22] <ogra_> so that such bits are catched when people do stable -> stable upgrades
[15:24] <didrocks> yeah
[15:25] <didrocks> ogra_: but soon systemd will implement it ;)
[15:25] <ogra_> shudder
[15:26] <didrocks> ogra_: if you don't mind, can you open the other bug so that I hook up session-migration into upstart?
[15:28] <ogra_> ok
[15:33] <pitti> hello
[15:34] <pitti> could someone please update the "Proposed" link on http://ci.ubuntu.com/ for s/Saucy/Trusty/ ?
[15:35] <Ursinha> cihelp, ^
[15:39] <vila> pitti: noted, the relevant people are giving thanks (or something)
[15:40] <pitti> thanks; far from urgent, it just caught my eye
[15:41] <vila> pitti: agreed, I've asked it to be added to our 'newrelease' wiki page
[16:29] <Saviq> psivaa, vila, care to confirm the bug please https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1255948 ?
[16:29] <Saviq> and https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1253198 too, for that matter
[16:31] <Saviq> and https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1252386
[16:33] <psivaa> Saviq: I've done for the first one. leaving the second one to vila due to me not knowing the history
[17:01] <didrocks> cyphermox: ogra_: coming?
[17:02] <cyphermox> right
[17:02] <ogra_> on my way
[17:10] <ogra_> [17:11] <popey> \o/
[17:11] <ogra_> not many changes ... but pitti uploaded a new python
[17:14] <cyphermox> didrocks: https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/new-depdns/+merge/197104
[17:15] <didrocks> cyphermox: approved!
[17:22] <cyphermox> didrocks: can you explain to me why it failed? I'm failing at parsing the log: http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/label=qa-intel-4000/655/console
[17:24] <didrocks> cyphermox: /var/local/autopilot/autopilot.log: Autopilot Package Version: 1.4+14.04.20131128.1-0ubuntu1
[17:24] <didrocks> /var/local/autopilot/autopilot.log: I: No test left to run
[17:24] <cyphermox> right
[17:24] <didrocks> None of the test reports contained any result
[17:24] <didrocks> Build step 'Publish JUnit test result report' changed build result to FAILURE
[17:24] <didrocks> I think it's something for cihelp ^
[17:25] <cyphermox> alright
[17:25] <didrocks> I would say autopilot run <test> did nothing
[17:25] <cyphermox> didrocks: in any case, at least now it gets to start, since I'm going to be running the tests manually anyway
[17:26] <cyphermox> I started unity-system-compositor, just left with unity8 when that's done and we'll be ok to start testing
[17:28] <didrocks> cyphermox: yeah, I think you will need to
[17:28] <didrocks> great!
[18:56] <cyphermox> robru: ok to start testing nao
[19:07] <robru> cyphermox, ok great. just having late breakfast, will start asap
[20:13] <robru> psivaa, ok, now I am seeing that exact same error when trying to run unity8-autopilot locally: http://paste.ubuntu.com/6491104/