=== salem_ is now known as _salem === mmrazik is now known as mmrazik|afk [05:46] tsdgeos, can't sleep? ;) [05:46] nope [05:46] woke up 2 hours ago already [05:47] decided may as well start working instead of trying to go back to sleep [05:47] tsdgeos, yeah, I didn't sleep well either, started an hour ago... [05:47] omg, unity-2d sru finally pushed :D [05:47] :D [05:48] i fixed those bugs like 1 year ago [05:48] Saviq: https://bugs.launchpad.net/bugs/1176962 [05:48] Launchpad bug 1176962 in qtdeclarative-opensource-src (Ubuntu) "[PATCH] Backport ListView related crash fixes" [Undecided,In progress] [05:55] tsdgeos, cheers [05:56] qt 5.1 beta1 being prepared today [05:57] tsdgeos, you've distro-patched the QColor patch already, did you? [05:57] "yes" [05:57] for some value of "yes" [05:57] :D [05:57] it's in the 5.0.2 packages that are in the qt ppa [05:58] in the qt "beta" ppa [05:58] which means i can't still use it in the shell since those packages are still not hitting the device [05:59] but will, soon [05:59] yep [05:59] k [05:59] * tsdgeos is so happy he can type "ubuntu_chroot" instead of "ubutu_chroot shell" all the time :D === zniavre__ is now known as zniavre [06:10] tsdgeos, yeah, and I only discovered it by mistake recently ;D [06:13] gallery works again :-) === mmrazik|afk is now known as mmrazik [06:32] tsdgeos: oh, good to know :) [06:50] tsdgeos, I'm not sure I understand your comment for mterry's branch - getString gets a value for a role, not the name of the role [06:51] Saviq: i mean, we should be using the roleNames mapping [06:51] and just call for .infographic on the item [06:51] that will call data [06:51] no? [06:51] tsdgeos, that's what we had before [06:51] tsdgeos, but that meant returning a complete QVariantMap [06:51] which mterry found to be slow [06:52] what we had before was calling get() [06:52] that returned the whole variantmap [06:52] afaics [06:52] yeah [06:52] and that was slow (too slow, btw) [06:52] sure [06:52] but it's not what i suggest [06:53] what i suggest should not call, get() or should it? [06:54] i don't see why it should [06:55] he needs to get the item by index [06:56] well, that's the un-declarative way i am finding [06:56] shouldn't need it [06:56] yeah we've tried using currentItem [06:56] actually if he has the currentIndex should have a model somewhere with a currentItem with the model data [06:56] and? [06:57] and they change differently [06:57] currentIndex changes straight away [06:57] currentItem waits for the transition to finish [06:57] you may want to use the [06:58] forceLayout stuff [06:58] ah wait not [06:58] that's introduced in my patches [06:58] we are still not using that :D [06:58] and really, it's not QML-ish because LightDM isn't QML-ish [06:58] sure [06:58] it's a challenge-response mechanism [06:59] so the workflow is: authenticate(userName); wait-for-potential-prompt; onClicked: respond(password); onAuthenticationCompleted: login() [06:59] i know, i implemented the remote login in lightdm-gtk [06:59] good [06:59] vaaaala :D [07:00] so if you can look at it and find a way to make it more declarative-friendly, go for it, I failed last week [07:00] only thing I can think of right now is reacting onIndexChanged and using itemAt() [07:00] instead of reacting onCurrentChanged [07:01] it'd be "the same" i guess [07:02] what i wonder is what mterry mentioned about the variant unboxing [07:02] yeah [07:02] seems to me like it should just work [07:02] I didn't think that was an issue [07:02] wanted to try that myself [07:05] oki [07:05] you try that then? [07:05] yeah, trying [07:05] cool [07:08] Saviq: also should find a way not to duplicate the enums [07:09] tsdgeos, yeah +1 [07:09] looks like it'll break quickly [07:09] paulliu: any luck with the peoplepreview failing test? [07:09] tsdgeos, I'm generally of the opinion that enums should be wrapped in separate non-creatable classes [07:10] that's a way to get them around, yep [07:12] tsdgeos: not yet.. Still reading the code. [07:39] tsdgeos, I found no way to reuse the enums other than going "enum NewEnums { Role = OldEnums::Role, ... }" [07:40] that at least will let us know when stuff break [07:40] s [07:40] or exporting the "base model" [07:40] to qml [07:40] no? [07:40] or that, yeah [07:40] but that would mean it's otherwise accessible, not sure mterry wanted that, but I'll add a comment [07:41] we can export it uncreatable [07:41] should not hurt, no? [07:41] yeah [07:42] effectively doing what I mentioned above... [07:42] kind of, yes :D [07:47] tsdgeos, any idea why the QVariantMap approach could be so slow? [07:49] Saviq: it's creating the qpixmap with the background every time [07:49] :D [07:49] right [07:49] in UsersModel::data UsersModel::BackgroundRole [07:49] that *has* to be slow [07:50] yeah, just saw [07:50] sounds broken [07:51] well, the thing in models is that ideally you only get stuff when you need it/has changed [07:51] so having an expensive data "is ok-ish" [07:51] yeah [07:51] but the ::get function is breaking that assumption [07:51] hence the get() shouldn't even be there [07:51] we need to look through its uses [07:51] agreed [07:51] and make it go away [07:54] want me to do that? [07:55] shall we write it in the blueprint somwere [07:55] ? [07:55] +e+h [07:55] tsdgeos, yeah, drop it in a bp somewhere [07:56] done [07:57] thanks [07:58] hi guys! [07:59] tsdgeos, I think we can live with the data(int, int), though, what do you think? [07:59] Ah.. I think I need some help. [07:59] greyback, hey [08:00] greyback, how was your trip? [08:00] Just check every possible field like Item.visible, etc. Everything is ok there. [08:00] greyback, and how is your anti-jetlag? ;) [08:00] Saviq: yeah, data(int, int) and maybe data(int, string) so one can use the roleName if wanted [08:00] tsdgeos, only thing is... that adds to the ListModel API... [08:00] Saviq: not bad. Managed to sleep a few hours on the plane, and woke at 5.30 this morning. Jet-lag probably kick in later today [08:01] Let me push the non-proper fix first. [08:01] tsdgeos, which we might end up abusing [08:01] tsdgeos, and expect those to be implemented in all ListModels [08:01] true [08:03] but that's something we already have :D [08:03] i mean the code was using get() [08:03] what we can do is not have any of the get() [08:03] BTW, is there any way to make bzr push faster? Small changes but still needs to upload a lot of data. [08:03] is that what you meant? [08:04] paulliu: yes [08:04] use --stacked-on [08:04] bzr push --stacked-on bzr+ssh://bazaar.launchpad.net/+branch/unity/phablet/ lp:blablabla [08:05] Is lp:blablabla the branch that being stacked-on or it is a newly created branch? [08:05] paulliu, the new one [08:06] ok.. got it. [08:06] tsdgeos, seems the dri fix doesn't want to get merged? [08:06] Let me try that. [08:08] greyback, I got rerouted via CPH (SFO > FRA > CPH > WRO) [08:09] Saviq: yep, paulliu working on it [08:09] Saviq: ouch [08:09] the good thing about that is the easiest €250 earned in my life ;) [08:09] somehow the fact we actually render the test makes it unstable now [08:09] Saviq: Overbooked? So when did you actually get home? [08:09] greyback, 9pm Sunday [08:09] some 20hrs trip [08:10] Saviq: nasty [08:10] tsdgeos: Is this ok? bzr push --stacked-on lp:unity/phablet lp:~paulliu/unity/fix-tst-peopleview [08:10] tsdgeos: It told me that UnsupportedProtocol. [08:11] paulliu, no, copy the exact command from tsdgeos [08:11] paulliu, you need the full bzr+ssh://... [08:11] for the --stacked-on [08:11] Saviq: ok. [08:24] paulliu: i've commited the waits to my ~aacid/unity/jenkins_mesa_dri/ branch that fails all the time in CI [08:24] just to prove that it makes CI pass [08:24] then we can remove them and add a proper fix :-) [08:24] if we find it :D [08:27] tsdgeos: I'd like to find it. But I need some clue. [08:28] tsdgeos: 600 is actually a magic number for my slow machine. If I use my faster desktop machine, it only needs 300 or less. [08:28] i see [08:28] let's see if 600 works for the CI machines :D [08:32] sadly not even running it in valgrind makes it fail here [08:32] need a slower machine! [08:34] tsdgeos: waitForRendering(item,timeout) any use maybe? [08:34] not that I understand why such a thing is needed frankly [08:35] :D [08:35] no clue, paulliu can you give ↑↑ that a try? [08:36] * tsdgeos sets up a VM with only 40% of the CPU pwoer to try to reproduce the issue locally [08:37] tsdgeos: yeah.. I'll try it. [08:38] tsdgeos: paulliu: also that test would probably be a lot more robust if we used "tryCompare" instead of "compare" [08:39] greyback: hmm.. I've treied tryCompare.. not working there. [08:39] greyback: it is really not ready to get a mouse event. [08:39] greyback: trycompare won't help here [08:40] basically you either got the click or not [08:40] greyback, can you https://code.launchpad.net/~saviq/unity/phablet.tweak-build_unity/+merge/162730 [08:40] hmmm, would there not be a way to do something like "tryCompare(mouseArea, ready, true)" ? [08:40] Saviq: ack [08:44] greyback: the wait(600) have to be in front of mouseClick anyway. If we move it after mouseClick, it failed. [08:44] tryCompare is a loop and wait, isn't it? [08:44] paulliu: effectively, yes [08:45] paulliu: I'm more curious about what's actually happening in the declarative engine to make the test fail. [08:46] greyback: yeah, me too. [08:46] greyback: mousearea ready?¿ [08:46] tsdgeos: pseudo-code [08:46] ah :D [08:46] greyback: And I've tried to see those properties in Item. Is the child visible, or ready to accept events, or those. They are all true/ready. [08:46] tsdgeos: completed maybe? [08:47] greyback: thing is, if it's "there" it should be "ready" [08:47] there's no loader afaics [08:47] greyback, that's Component prop, not there on the actual item [08:47] not even prop, signal [08:47] the only thing I can think of would be to instrument the actual MouseArea [08:48] and first tryClick() in a loop until clicked() is emitted [08:48] and only then progress with the test [08:48] but then we do not always have direct access to the MouseArea [08:48] tsdgeos: yep. /me puzzled [08:50] * Saviq dislikes the fact that there's no "previous workitems" summary in LP [08:50] so after the month passes, there's no way to see the summary for them [08:52] we'll have to wait for kgunn to sort them out [08:53] +1 [08:53] i actually lost the unfinished items [08:54] and had to go looking at the blueprints to bring them to the next month [09:23] tsdgeos, yeah exactly [09:28] so yeah addig the wait definitely makes CI pass [09:37] greyback: sorry, what is waitForRender? [09:38] paulliu: I'm not entirely sure :) But it looked maybe relevant [09:47] Saviq, ping [09:48] tvoss, pong [09:52] greyback, you got the patch to run the shell in mir? [09:54] Saviq: is rough, but yeah [09:54] greyback, is fine [09:54] greyback, can you pastebin? [09:54] Saviq: use lp:~mzanetti/unity/phablet-integrate-mir/ [09:54] greyback, cheer [09:59] didrocks: ping [10:01] yay, test fails in the VM :-) [10:01] mmrazik: pong [10:03] didrocks: regarding the dashboard document. Who is actually supposed to be the end user of the functionality? [10:03] like who will be able to retrigger a release, etc [10:04] mmrazik: upstream would be the end user of the functionality [10:04] what is upstream? [10:04] mmrazik: the integration team will sometimes have to do "manual publication" [10:04] lets say for unit next [10:04] like kevin gunn? [10:04] mmrazik: right [10:04] or the engineers in his team? [10:04] (both?) [10:04] mmrazik: both, I guess [10:05] mmrazik: also, the management (upstream and integration) who wants a view on their status regarding the distro [10:05] didrocks: so what is wrong with having a link to jenkins to a specific job. You click there, the job gets triggered again... ? [10:05] like we do with CI [10:05] there are lots of downstream jobs [10:05] but there is a rebuild link to the "master" job [10:06] I assume you have something similar [10:06] mmrazik: because the whole workflow would be managed by celery [10:06] and not jenkins [10:06] jenkins isn't done for controlling workflow [10:06] we are just abusing it this way [10:06] and this lead to corner case and contentions [10:07] mhm.. I guess I just don't understand the problem here [10:07] so we are essentially reimplementing jenkins in celery? [10:08] * mmrazik is just reading about celery [10:08] mmrazik: no, jenkins is still used for running the jobs [10:09] mmrazik: celery would be used to control the workflow (job chained) [10:09] mmrazik: look at my latest comment on the document, there are multiple modes in daily release contrary to upstream merger [10:09] didrocks: so what is wrong on the way jenkins does that with upstream/downstream/etc ? [10:09] ok [10:09] mmrazik: look at the -generic job [10:09] mmrazik: for running tests [10:09] it's not easy to tell what -check triggered what -generic [10:09] for instance [10:10] also, we have some "control flow jobs" like, head, prepare, and so on… [10:10] let's imagine one job is stuck [10:10] the others are then pending, and we can end up having all the jobs stuck as the new subjobs is waiting on a free slot [10:10] to me it still sounds like all this functionality is in jenkins. We just have too many generic jobs so we have problems to tie them together (but even that is possible in the jenkins api) [10:10] but I'm still reading your comments [10:11] when I read about celery I have an impression like reading about jenkins [10:11] mmrazik: celery is about chaining jobs, jenkins isn't supposed to be able to run 10 subjobs and collecting the status [10:12] didrocks: why not? [10:12] mmrazik: see the contention point ^ [10:12] mmrazik: we can end up in a situation where the tracking jobs are stucked [10:12] but that is something you need to figure out in celery as well [10:12] or not? [10:13] (by having more workers like you would have in jenkins) [10:13] mmrazik: no, as celery doesn't have the concept of slots, basically, celery is like a grafcet, then you can run whatever you want from this grafcet (in that case, jenkins jobs) [10:14] didrocks: grafcet == petri net? [10:14] (can't find anything english for that term) [10:15] mmrazik: interesting, indeed, can find in spanish, deutch and french… [10:15] not really petri net though [10:16] you can see it as a workflow descriptor, chaining jobs on conditions [10:16] those jobs would be jenkins jobs [10:16] we are just going to move away the controller from the executor [10:16] I still think we are implementing our own jenkins that way... jenkins jobs will be made equivalent to shell scripts [10:17] but anyway... thats not my main concernt [10:17] greyback: and the prize goes to you [10:18] tsdgeos: waitForRender? [10:18] didrocks, if jenkins is still the executor, having an external does not help at all, as slots are still provisioned by the executor. Or am I missing something? [10:18] I'm just a bit concerned to spend time developing replacement for something where I (personally) don't see huge issues [10:18] greyback: yep, that fixes i [10:18] t [10:18] greyback: seems like the row was still "in flux" [10:18] not having really adapted all the sizes properly [10:18] the contention thing can be resolved by propper priorities and executors [10:18] and waitForRendering makes sure everything is stable [10:18] tvoss: the issue there is that the controller is provisionning executors, and it's executed as well [10:18] tsdgeos: interesting [10:18] didrocks: but that can be resolved in jenkins [10:18] tvoss: so you can have all slots taking bug controller jobs [10:18] i did printing of .x of the elements of a row [10:18] and got [10:18] 0 [10:18] -56 [10:19] mmrazik: apart by having more slots, how? [10:19] didrocks, how does an external controller solve that? [10:19] which was weird since the second element of the row can't be to the left of the first one :D [10:19] didrocks: priorities, more slots, "virtual" executor which executues controlling jobs only [10:19] tvoss: the external controller doesn't take jobs on jenkins and only execute real "jobs", not workflow controler jobs [10:19] tsdgeos: very interesting, I hadn't expected that [10:19] tvoss: mmrazik: having workflow control jobs as a jenkins jobs is a workaround to me [10:20] didrocks: e.g. our master jenkins only executes controlling jobs only and with ~25 execs it works just well [10:20] mmrazik: well, the main idea, before removing the executors is first to have a sensible global view of the stack [10:20] mmrazik: which isn't possible with jenkins [10:20] didrocks: but thats what jenkins is for. We can then just use shell scripts (which might be fine but I fear we will just run into new issues) [10:20] mmrazik: you don't have 50 jobs controlled by one executor job though [10:20] didrocks: ack. that is the dashboard thing -- aggregating information from varios sources into one cohesive view [10:21] thats what I 100% agree we need and thats what francis/allan are working towards [10:21] mmrazik: indeed, and having the executor at the same place definitively avoid having to recode the same "workflow view" twice [10:21] didrocks: are all 50 running at the same time? [10:21] it will be only in one place [10:21] mmrazik: yeah, we have stacks like webapps and unity with that many subjobs [10:22] didrocks: and they run in parallel ? [10:22] paulliu: can you confirm https://code.launchpad.net/~aacid/unity/jenkins_mesa_dri/+merge/162377 works for you too? [10:22] indeed [10:22] didrocks: and they are all control jobs? [10:22] * mmrazik doesn't get it [10:22] mmrazik: no, there is 3 control jobs [10:22] didrocks, do we have a prototype for celery driving jenkins? [10:22] didrocks: so its essentially 3 jobs that is not so bad [10:23] tvoss: well, the idea is to build that prototype, but I don't think it's that different from my first upstream merger which had tarmac driving jenkins [10:23] all the rest is doing actual work and will be translated to jenkins jobs anyway [10:23] mmrazik: indeed, but then, you recode the workflow once in jenkins [10:23] and then again in the dashboard [10:23] (for the presentation layout) [10:23] which is what can lead to issue, desynchronisation [10:23] having that in a coherent place makes more sense to me [10:24] didrocks, so do you plan on having a small quick prototype soon to verify that integration works as expected? [10:24] yeah.. this is the part I still don't understand... why I would need to reimplement the workflow in dashboard [10:24] I would just take the result of those 3 control jenkins jobs [10:24] tvoss: that's my goal, as soon as we finish with the utah replacement in 2 weeks with jibel, we are going to work on that [10:24] mmrazik: that doesn't work, you want to say "unity stack failed because of:" [10:24] - prepare failed [10:25] - build fail [10:25] - check failed [10:25] - publish in manual mode [10:25] - wait on this stack which is locked for… [10:25] so you have multiple cases, and you need to reimplement the workflow, knowing the orders of jobs and so on [10:25] and you do that in jenkins and the dashboard [10:25] didrocks: it still sounds similar to what we do in CI... we want to know that clang failed (as a downstream job) or coverity check failed [10:25] and e.g. coverity is just ageneric job [10:26] we just query jenkins for those relationships [10:28] didrocks, how do we plan on aggregating results from the different jenkins jobs if we do not explicitly model the relations in jenkins? [10:28] tvoss: this is what celery is getting to use, to "pilot" (hence using the word control) jenkins jobs [10:28] tvoss: so it will know the status and results [10:28] didrocks, but how so? purely on a filesystem level? [10:29] tvoss: ? using the REST api [10:29] didrocks, okay [10:29] tvoss: we do use the filesystem level as of today to coordinate stacks and status, as jenkins is forcing us doing that, and that's what wrong IMHO [10:29] like to know if you skip a step or not [10:29] this way, we'll remove that part [10:30] didrocks, in the usual jenkins setup or in the automerger setup? [10:30] tvoss: I'm speaking of daily release [10:31] didrocks, which jenkins setup does that use? I was of the impression that the jenkins setup mmrazik is talking about does not use the filesystem for job control purposes [10:32] tvoss: filesystem is used for two things: [10:32] - stack synchronization (knowing that a stack is running when another one should wait on it, and then finally getting the other stack status) [10:33] - and for the -generic PS test job to know if it needs to skip or run the tests (this skip file/flag on the FS was implemented by mmrazik IIRC) [10:33] * mmrazik can't recall what is the 2nd thing [10:34] (but I'm not saying I didn't do it :-)) [10:34] the skip part is something I would implement with a job param (but still can't think of when is that used) [10:34] the /tmp/autopilot.skip I guess (looking at the job) [10:35] I didn't do that [10:35] or I really can't recall at least [10:35] was a long time ago TBH… [10:35] but I'm more concern about the first case, which is stack synchronization [10:36] and having B waiting on A, being able to possibly force running B or detect that A is stuck [10:36] still getting the latest status from A [10:37] didrocks: still don't get how celery solves this problem [10:37] you would need to implement it there as well [10:37] in one way or another [10:38] while we seem to have it for jenkins [10:38] mmrazik: celery will have the whole workflow in memory, and with its django binding, we'll be able to reflect that directly in the dashboard [10:39] I see [10:39] mmrazik: if there was not this django <-> celery, I agree, the story would be different [10:40] I just see an opportunity to easily be able to reflect the workflow and a global status, in one unique place [10:40] by essentially replacing jenkins :) [10:40] good that sergio is not here. He would applaud :) [10:41] ahah :) [10:41] mmrazik: we'll still use jenkins, just not for controlling chaining tasks [10:41] didrocks: yeah... but we can just use shell scripts and upload the stdout/stderr to some random server [10:41] thats pretty much what you would use jenkins for [10:42] in this model [10:42] mmrazik: that's not untrue, but we'll still be able to have some different slots on different servers, so it's doing the load repartition as well [10:42] right [10:44] didrocks: well... still not entirely convinced. I think we should move the daily release stuff to the new infrastructure. Keep doing our work on dashboard (displaying stuff from jenkins, aggregatging e.g. coverage data, etc) and then talk in 2 weeks or so [10:44] maybe create a small prototype to see [10:44] but I would still try to do it separately from the dashboard [10:44] and we can just integrate those two when necessary [10:45] what's the new infrastructure? [10:45] mmrazik: but yeah, I didn't request help from your team before jibel and I implement a prototype to have celery controlling the workflow :) [10:46] I don't want to add that task on your shoes :) [10:46] didrocks: srry. I meant the utah replacement [10:46] mmrazik: ah yeah, we are clearly proritazing that :) [10:46] way more important as it will unblock a lot [10:49] greyback: can to approve https://code.launchpad.net/~aacid/unity/jenkins_mesa_dri/+merge/162377 ? [10:49] E_NO_GRAMMAR [10:49] tsdgeos: parse error [10:50] greyback: care to review https://code.launchpad.net/~aacid/unity/jenkins_mesa_dri/+merge/162377 ? [10:50] it's the waitForRendering stuff [10:50]