Saviq | pero, I meant that most people who can answer your question are sleeping, or at least enjoying their evening, so won't be able to answer you here | 00:47 |
---|---|---|
Saviq | pero, and a post to a mailing list is simply more persistent than a question on IRC | 00:47 |
pero | Saviq: thx | 02:13 |
=== _salem is now known as salem_ | ||
=== salem_ is now known as _salem | ||
=== duflu_ is now known as duflu | ||
=== tvoss_ is now known as tvoss|test | ||
=== tvoss|test is now known as tvoss | ||
Mirv | Saviq: regarding the patch you mentioned yesterday, upstream has some new delegateValidated related additions which prevent the patch from applying cleanly and also sound a bit related? | 07:27 |
Mirv | Saviq: I'm adjusting it now but just unsure if it's completely correct | 07:29 |
Mirv | Saviq: and the reason for it being "dropped" is simply that the last three releases to 5.0.2 have not been merged to the 5.1/5.2 packaging branch | 07:32 |
Mirv | syncing up, the other patches were merged upstream | 07:37 |
=== iahmad is now known as iahmad|afk | ||
tsdgeos | damn it seems my scopeview/genericscopeview merge is causing segfaults in the tests :-/ | 08:36 |
* tsdgeos tries to reproduce locally | 08:37 | |
=== iahmad|afk is now known as iahmad | ||
om26er | man this MR is hanging for a long time :/ | 09:24 |
om26er | https://code.launchpad.net/~om26er/unity8/unlocker_fix_non_working_code/+merge/194850 | 09:24 |
om26er | should we disable that qmltest ? | 09:24 |
tsdgeos | no | 09:26 |
tsdgeos | i'm going to fix it | 09:27 |
tsdgeos | as stated 1 hour ago | 09:27 |
tsdgeos | dednick: https://code.launchpad.net/~aacid/unity8/LVWPH_do_not_do_stuff_if_parent_gone/+merge/196070 | 09:30 |
tsdgeos | om26er: ↑↑↑ | 09:30 |
tsdgeos | dednick: remember the crashes we had in make testDash when i removed the fake scopeview from the tests and used the real one? | 09:31 |
tsdgeos | well they're still there | 09:31 |
tsdgeos | so i'm "more correctly" bypassing them than with a wait | 09:31 |
dednick | tsdgeos: ok | 09:33 |
dednick | tsdgeos: huh. why is there no parent context? | 09:34 |
tsdgeos | dednick: because the parent was just destroyed | 09:35 |
tsdgeos | and we''ll be destroyed asap | 09:35 |
tsdgeos | but somehow a painting/layout operation sneaked in | 09:35 |
tsdgeos | that's why we never see this crash "in real life" | 09:35 |
tsdgeos | because we don't destoy scopes there | 09:35 |
dednick | tsdgeos: hm ok. do you know why is the parent destroyed before the child? | 09:35 |
tsdgeos | but it happens a lot in the tests | 09:36 |
dednick | i c | 09:36 |
tsdgeos | not really :-/ | 09:36 |
tsdgeos | my only guess is that the qml stuff is not great | 09:36 |
tsdgeos | and hence the comment for 5.2 checking | 09:36 |
tsdgeos | since lots of stuff improved there and don't want to spend time chasing something that may have been already fixed | 09:37 |
tsdgeos | if not fixed in 5.2 | 09:37 |
tsdgeos | we need to put more time in understanding why this is happening | 09:37 |
dednick | tsdgeos: ok. well i guess it's the parentContext, not the actual parent. fine by me. | 09:38 |
tsdgeos | dednick: if you can approve that'd be great, this is blocking other merges from happening since it fails regularly in jenkins | 09:39 |
dednick | tsdgeos: done | 09:39 |
mhr3 | dednick, if you're able to reproduce the dee criticals, just do G_DEBUG=fatal_criticals and attach gdb | 09:39 |
tsdgeos | thumbsup! | 09:39 |
mhr3 | dednick, it will SIGTRAP when you get a critical | 09:39 |
mhr3 | or SIGABRT?... one of those | 09:39 |
dednick | mhr3: i can do it every time. :) | 09:39 |
tsdgeos | Mirv: you ended up in https://plus.google.com/104580575722059274792/posts :D | 09:40 |
mhr3 | dednick, you got me wondering now, are you running the glib-events dee-qt branch? | 09:40 |
dednick | mhr3: nope. | 09:40 |
mhr3 | hmm, weird then | 09:40 |
dednick | mhr3: leave it too me. I have some debugging in there. I'll sort it out. | 09:41 |
mhr3 | k | 09:41 |
dednick | there may be some finger pointing involved a bit later ;) | 09:41 |
mhr3 | now i'll be scared the whole day | 09:41 |
mhr3 | damn you! | 09:41 |
dednick | hehe | 09:41 |
mhr3 | dednick, one thing that i started wondering is whether we're passing correct changePos when inside the more complex transactions, that could indeed be a root cause of the failures | 09:43 |
Mirv | tsdgeos: yeah, I noticed, now I wish I'd have had something slightly better to show off :) | 09:45 |
dednick | mhr3: hmm. i dont think so. when i was debugging before, it seemed that we were getting the correct thing through. As much as I could tell from the updating result count anyway. | 09:46 |
mhr3 | oh well, i'll let you do som more debug | 09:49 |
Saviq | Mirv, re: the patch, it's tsdgeos's, and well tested, so we should be able to easily verify that it works (or not) | 09:59 |
tsdgeos | Saviq: Mirv: which one? | 10:00 |
Saviq | tsdgeos, delegate range | 10:00 |
tsdgeos | ah sure | 10:00 |
Saviq | tsdgeos, Mirv dropped it from 5.2 'cause thought it's merged | 10:00 |
tsdgeos | Mirv: ah no, unfortunately they don't want minor features in listview, will only accept a full rewrite with all the features + whatever we need | 10:01 |
tsdgeos | it's one of those sad situations | 10:01 |
tsdgeos | the gatekeeper is overworked and is basically saying no to anythinng that may make him more overworked in the future | 10:02 |
Mirv | Saviq: tsdgeos: yeah it's now just copied to the qt5-beta2 PPA so feel free to try out | 10:12 |
Mirv | (~test10) | 10:12 |
Saviq | Mirv, cool, that's what caused there to be no results in the dash | 10:14 |
tsdgeos | ah, yeah, probably | 10:14 |
* Saviq upgrades | 10:14 | |
om26er | tsdgeos, great :) | 10:24 |
Mirv | Saviq: it's better now (and yay! we've reached "just upgrade from PPA"!), but most icons look corrupted | 10:25 |
Saviq | Mirv, yeah I saw that yesterday | 10:25 |
Saviq | Mirv, they're all UbuntuShape, so that's probably why | 10:26 |
Saviq | Mirv, was hoping we don't have it rebuilt against 5.2, but unfortunately it seems we do :/ | 10:26 |
Saviq | Mirv, will verify and file a bug against UITK | 10:27 |
tsdgeos | Saviq: there's a bug already | 10:28 |
Saviq | tsdgeos, ah ok | 10:28 |
tsdgeos | florian opened it | 10:28 |
Saviq | bug ##1252736 | 10:28 |
tsdgeos | https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1252736 | 10:28 |
ubot5 | Ubuntu bug 1252736 in Ubuntu UI Toolkit "[Qt5.2] UbuntuShape content is incorrect, garbage shown" [High,Confirmed] | 10:29 |
tsdgeos | yess | 10:29 |
Saviq | yesterday they looked alarmingly like a spread-ed Ubuntu desktop (4 visible workspaces)... | 10:30 |
dednick | tsdgeos: you know anyway you can determine from a random object if we've gone back to the event loop between function calls? | 10:30 |
Saviq | oh, there's a fix already | 10:31 |
dednick | tsdgeos: ie. if we're in the same cycle or not. | 10:32 |
tsdgeos | dednick: /me thinks | 10:32 |
mhr3 | dednick, break on g_main_context_dispatch | 10:32 |
mhr3 | dednick, or on poll :) | 10:33 |
Cimi | can I define enums in qml? | 10:33 |
Cimi | tsdgeos, wanted to add an enum with the type of the dashrenderer | 10:34 |
Saviq | Cimi, no | 10:34 |
Saviq | Cimi, https://bugreports.qt-project.org/browse/QTBUG-14861 | 10:34 |
Cimi | strings then? | 10:34 |
dednick | mhr3: break? | 10:35 |
Saviq | Cimi, yeah, no other way | 10:35 |
mhr3 | dednick, oh you do printfs instead of gdb? :P | 10:35 |
Cimi | Saviq, you know what makes the opacity of the elements outside the preview (down) work? | 10:35 |
Saviq | Cimi, mzanetti | 10:36 |
dednick | mhr3: well if i break on dispatch, i'm going to get a hell of a lot of breaks | 10:36 |
mhr3 | dednick, https://sourceware.org/gdb/onlinedocs/gdb/Thread_002dSpecific-Breakpoints.html | 10:36 |
Cimi | dednick, I don't remember if you asked me to review something I didn't | 10:37 |
mzanetti | Cimi: Components/Tile.qml, line 31 | 10:37 |
mzanetti | Cimi: and Components/Carouse.qml, line 296 | 10:38 |
Cimi | mzanetti, it looks very weird with the carousel | 10:38 |
mhr3 | pstolowski, not what i meant | 10:38 |
Cimi | mzanetti, I'd change the global opacity | 10:38 |
Cimi | of the whole carousel instead | 10:38 |
mhr3 | pstolowski, i wanted the move inside the lib internals | 10:38 |
dednick | Cimi: https://code.launchpad.net/~nick-dedekind/unity8/lp1238182/+merge/192965 | 10:39 |
mzanetti | Cimi: well, you need to keep the current one highlighted | 10:39 |
mzanetti | opaque, that is | 10:39 |
Cimi | mzanetti, it is on the carousel though | 10:39 |
mzanetti | Cimi: so? | 10:39 |
Cimi | mzanetti, I mean, you see which one is highlighted because it's bigger | 10:40 |
mzanetti | hmm... the previews with the carousel seem broken in trunk | 10:40 |
dednick | mhr3: i need a break on dispatch after a condition in the deelistmodel becomes true. possible? | 10:40 |
Cimi | mzanetti, I have a branch | 10:40 |
mhr3 | pstolowski, do you know what i mean? cause otherwise the copy is happening there | 10:40 |
mzanetti | Cimi: well, you also see that in the row because the arrow points to it. still it's what design wants | 10:40 |
mhr3 | dednick, sure | 10:40 |
Cimi | mzanetti, ~unity-team/unity8/dash-renderers | 10:40 |
mhr3 | dednick, breakpoints are numbered, when you add one it'll be "1", you can then do enable / disable 1 | 10:41 |
Cimi | mzanetti, design doesn't want that on the carousel | 10:41 |
Cimi | mzanetti, I bet they don't | 10:41 |
Cimi | mzanetti, let me change the opacity of the highlighted index to 1.0 | 10:41 |
Cimi | global opacity to 0.6 | 10:41 |
mzanetti | Cimi: I don't think this should differ between grid and carousel... | 10:42 |
Cimi | mzanetti, then the other elements to 0.333 | 10:42 |
Cimi | 1*0.6 = 0.6 for highlighted index | 10:42 |
Cimi | 0.333*0.6 = 0.2 for not highlighted | 10:43 |
Cimi | while keeping the selected index fully opaque | 10:43 |
mhr3 | dednick, also "info breakpoints" | 10:43 |
Cimi | mzanetti, try the branch and see how weird it is | 10:43 |
Cimi | mzanetti, the highlighted index overlaps | 10:44 |
mzanetti | Cimi: the design spec says 0.6 for the active one, 0.2 for the others | 10:44 |
Cimi | mzanetti, ok so I'll do as I said | 10:44 |
Cimi | the end result is the same | 10:44 |
tsdgeos | dednick: so | 10:44 |
tsdgeos | dednick: the only way i can think of, is posting yourself an event (or a timer single shot 0) (or a qmetaobject call queued) and see what comes first if that call or the other function | 10:45 |
tsdgeos | not sure how good that is | 10:45 |
dednick | tsdgeos: yeah, that's what i was trying | 10:45 |
mzanetti | Cimi: there seems to ba Bhavior on opacity missing too | 10:46 |
Cimi | Saviq, do we have a preference for using == or === ? let's use === when possible? | 10:46 |
Cimi | mzanetti, we can add that | 10:46 |
Saviq | Cimi, === is type-safer | 10:46 |
mzanetti | Cimi: you should use whatever is correct in the particular case :D | 10:46 |
dednick | tsdgeos: actually, i was trying a looping postEvent. So every time i handle a posted event, I post another | 10:46 |
mzanetti | but yeah, if unsure === is probably the better choice | 10:46 |
Cimi | Saviq, you mean the opposite | 10:46 |
Saviq | Cimi, no, I mean that | 10:47 |
Cimi | Saviq, == doesn't care of the type | 10:47 |
Cimi | unless I completely misunderstood the two | 10:47 |
Saviq | Cimi, yes, so === is type-safe | 10:47 |
Saviq | r | 10:47 |
Saviq | Cimi, because it checks for the type | 10:47 |
Saviq | Cimi, it's not safer for *you*, but it's safer for the code ;) | 10:47 |
Cimi | hah | 10:47 |
Cimi | code, you owe me a beer then | 10:48 |
tsdgeos | argg, my stuff failed in autoland too | 10:50 |
tsdgeos | at least it did not crash like with the others :D | 10:50 |
tsdgeos | s/autoland/ci | 10:51 |
* tsdgeos tries to reproduce | 10:51 | |
Cimi | this is weird | 10:51 |
Cimi | so if I change the opacity of a parent | 10:52 |
Cimi | it changes the opacity of all children's? | 10:52 |
Cimi | like multiplying the opacity of each childrens with the opacity of the parent? | 10:52 |
Cimi | I supposed it was simply composing the opacity | 10:53 |
tsdgeos | it does multiply yes | 10:53 |
tsdgeos | what do you mean with composing the opacity? | 10:53 |
Cimi | tsdgeos, compiz transparency | 10:54 |
Cimi | tsdgeos, it changes the transparency of everything | 10:54 |
Cimi | tsdgeos, makes the texture containing the elements transparent, the parent | 10:55 |
Cimi | not changing the opacity of each of them | 10:55 |
tsdgeos | isn't this the same? | 10:55 |
Cimi | nope | 10:56 |
tsdgeos | it doesn't change the opacity of the children | 10:56 |
tsdgeos | it just changes its opacity | 10:56 |
tsdgeos | happens that children are inside | 10:56 |
Cimi | it changes the opacity of each children I believe | 10:56 |
Cimi | let me play with gimp | 10:56 |
tsdgeos | no | 10:56 |
tsdgeos | their opacity is still 1 | 10:56 |
Cimi | it's not | 10:56 |
Cimi | I have to see in gimp | 10:56 |
tsdgeos | of course they are painted at the 0.5 opacity if the parent is at 0.5 | 10:56 |
tsdgeos | but that's becuause you changed the opacity of the parent | 10:56 |
Cimi | this is wrong | 10:56 |
tsdgeos | no its not | 10:57 |
Cimi | it should be composited | 10:57 |
tsdgeos | it's totally reasonable | 10:57 |
tsdgeos | otherwise if i want to make something 0.5 transparent | 10:57 |
tsdgeos | i should go to all its children and make them 0.5 transparent | 10:57 |
tsdgeos | which makes no sense at all | 10:57 |
Cimi | I want a carousel semi transparent | 10:58 |
Cimi | I don't want all the children to be transparent!! | 10:58 |
Cimi | this is quay qml does | 10:58 |
Cimi | *what | 10:58 |
tsdgeos | what measn "a carousel semi transparent" | 10:58 |
tsdgeos | if you don't change the opacity of the children? | 10:58 |
Cimi | the whole component | 10:58 |
Cimi | I change the opacity of the texture of the carousel | 10:58 |
Cimi | not of all the damn children! | 10:59 |
tsdgeos | am i the only one here not understanding what Cimi is saying? | 10:59 |
Cimi | so If I change the opacity of the parent, it recurses in all children and multiply the opacity of the parent for the parent of the children | 10:59 |
tsdgeos | yes | 10:59 |
tsdgeos | and that's how it should be | 11:00 |
tsdgeos | otherwise you won't see anything transparent | 11:00 |
Cimi | of course I would | 11:00 |
Cimi | if it was composited | 11:00 |
tsdgeos | what would be transparent? | 11:00 |
tsdgeos | if the carousel draws nothing by itself | 11:00 |
tsdgeos | it's only the children that draw stuff | 11:00 |
Saviq | tsdgeos, think that failure could be unearthed by your "do-not-do-if-parent-gone" fix https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/349/? | 11:00 |
Cimi | so I need a shader | 11:01 |
tsdgeos | Cimi: don't think so | 11:01 |
Cimi | I think so, I need to composite | 11:01 |
tsdgeos | Saviq: don't think so either | 11:01 |
tsdgeos | Saviq: testing | 11:01 |
Saviq | tsdgeos, didn't see that failure yet | 11:01 |
Cimi | tsdgeos, ~unity-team/unity8/dash-renderers | 11:02 |
Saviq | tsdgeos, and landing failed the same test | 11:02 |
Cimi | tsdgeos, test the carousel preview | 11:02 |
Cimi | tsdgeos, see how badly the carousel tiles overlap with transparency | 11:02 |
Cimi | tsdgeos, this is because they are painted with the opacity of their parent | 11:02 |
tsdgeos | i don't see any problem | 11:03 |
tsdgeos | what would you expect to see? | 11:04 |
tsdgeos | ah wait i think i'm starting to understand you | 11:04 |
Cimi | tsdgeos, the tiles to be at 1 opacity with a global opacity set by the parent | 11:04 |
Cimi | tsdgeos, you can do this with a shader I believe | 11:05 |
Cimi | taking the texture of the whole carousel and painting with opacity of the parent | 11:05 |
Saviq | Cimi, tsdgeos not sure it applies here but qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-item.html#layer.enabled-prop layer helps with opacities doing unexpected things | 11:07 |
tsdgeos | Cimi: ok yes, sorry was not understanding you | 11:07 |
Saviq | Cimi, btw, your branch conflicts with trunk | 11:07 |
Cimi | Saviq, thanks! | 11:08 |
Cimi | Saviq, layer works! | 11:08 |
Saviq | Cimi, it needs to be used sparingly, though | 11:09 |
Cimi | Saviq, carousel? | 11:09 |
Saviq | Cimi, layer | 11:09 |
Cimi | Saviq, yeah, in carousel when highlight index is not -1? | 11:09 |
Cimi | can I? | 11:09 |
Saviq | Cimi, yeah, definitely only when the preview is happening | 11:09 |
Saviq | Cimi, what it does is render the whole item off-screen and then mapped as a whole to the right place | 11:10 |
Saviq | Cimi, which means it uses more memory | 11:10 |
tsdgeos | it's weird because http://paste.ubuntu.com/6452734/ breaks when enabling layer.enabled :S | 11:10 |
tsdgeos | ah, no geometry | 11:10 |
tsdgeos | silly me | 11:10 |
tsdgeos | yeah that's what cimi was describing and the stubborn in me wasn't understanding | 11:11 |
Cimi | Saviq, it looks like it clips outside though | 11:11 |
tsdgeos | Cimi: make sure the geometry of the item is defined correctly | 11:11 |
tsdgeos | or even use the layer.something property that is about the geometry of the layer | 11:12 |
Saviq | Cimi, it might indeed | 11:12 |
tsdgeos | Saviq: so that test that failed is one of the "hard" ones | 11:13 |
tsdgeos | basically we flick and then test that it's still moving | 11:13 |
tsdgeos | but what if the thing is ultra slow and it's not moving anymore? | 11:13 |
tsdgeos | the test fails | 11:13 |
Saviq | tsdgeos, are there simple ones? ;) | 11:14 |
Saviq | tsdgeos, right | 11:14 |
tsdgeos | anything that is not time dependant | 11:14 |
Saviq | tsdgeos, those are, unfortunately, run on VMs indeed | 11:14 |
mhr3 | sil2100, how far are we with unity-scopes-shell? | 11:17 |
tsdgeos | Saviq: not sure what we can do here, other than flick again if when i am asking if it's moving it's not | 11:17 |
dednick | mhr3: WTF is going on?! | 11:18 |
mhr3 | dednick, ehm, sounds like fun is?! :) | 11:18 |
Saviq | tsdgeos, real solution would be to override the time source | 11:19 |
dednick | mhr3: does the dee proxy post all the dbus events at same time? | 11:19 |
Saviq | tsdgeos, but that's something we won't do now - so if you can find a reliable workaround, do | 11:19 |
mhr3 | dednick, yes, that's what i said in the mp | 11:19 |
mhr3 | dednick, cause dbus-wise a transaction is a single signal | 11:20 |
dednick | server as well as proxy i mean. | 11:20 |
dednick | oh. hm | 11:20 |
dednick | ok | 11:20 |
dednick | mhr3: is it on a sep thread? | 11:20 |
mhr3 | dednick, nope, main | 11:20 |
dednick | mhr3: AHHH!!?!! | 11:21 |
dednick | wtf | 11:21 |
tsdgeos | Saviq: i'll try | 11:21 |
* tsdgeos sees tryCompareFunction and thinks we should contribute it upstream | 11:22 | |
dednick | mhr3: http://pastebin.ubuntu.com/6452782/ the incrementing number in the middle is the event loop count (static object posting event every cycle [i hope]). addr on right is just for grep | 11:22 |
dednick | mhr3: it's all in the same damn loop number. | 11:23 |
mhr3 | dednick, so you believe me now? :) | 11:23 |
dednick | mhr3: you mean that something funky is going on? | 11:23 |
dednick | mhr3: no, i don't believe you that it's all in same cycle. will not believe it! | 11:24 |
mhr3 | dednick, despite all the evidence?! did you start believing in unicorns and lepricons too? :P | 11:25 |
sil2100 | mhr3: unity-scopes-shell? We're in universe already with that | 11:25 |
dednick | more likely.... | 11:25 |
sil2100 | mhr3: I guess it's time for unity-scopes-api now, no? | 11:25 |
mhr3 | sil2100, yep | 11:26 |
mhr3 | sil2100, fwiw the control file should be cleaned up, i added some workarounds there since the zmqpp-dev was broken | 11:27 |
sil2100 | mhr3: will do that then ;) | 11:28 |
Mirv | Saviq: I filed bug #1253603 which should be retraced properly | 11:28 |
ubot5 | bug 1253603 in unity8 (Ubuntu) "Qt 5.2: unity8 crashed with SIGABRT in raise()" [Undecided,New] https://launchpad.net/bugs/1253603 | 11:28 |
Saviq | Mirv, will it know to use the PPA? also, unfortunately that's not going to give us much, I'm afraid ;/ | 11:29 |
Saviq | Mirv, SIGABRT always retrace to _GI_raise with no real info on what happened, or what the message was (as it's usually an assert) | 11:30 |
Saviq | but I'll keep an eye on it | 11:30 |
mhr3 | dednick, when do you print the "processing changes end"? | 11:30 |
mhr3 | dednick, inside flushChanges()? | 11:30 |
dednick | mhr3: at the end of processChange() | 11:31 |
Mirv | Saviq: yes, it failed out until I added the PPA deb+src url:s to the daisy configuration | 11:31 |
Saviq | Mirv, ok, let's see | 11:31 |
mhr3 | dednick, say what now? | 11:32 |
dednick | mhr3: "processing changes" is printed at start of processChange() function, and "processing changes end" is at the end of the function | 11:32 |
mhr3 | dednick, so all the invalid data() calls somehow happen between processChanged() and flushChanges()? | 11:32 |
dednick | mhr3: well, in between processChanged and the "changeset-finished" signal | 11:33 |
Mirv | Saviq: oh right, with "which should be retraced properly" I meant that theoretically I retraced it properly with my current know-how (using view on device once, then retracing with lp:daisy and PPA sources added on host machine, then sending) | 11:34 |
mhr3 | dednick, so what's the "flushing changes"? | 11:34 |
dednick | the changeset end. | 11:34 |
Saviq | Mirv, ah, you mean you retraced it locally, got it ;0 | 11:34 |
mhr3 | but there is "changeset end" | 11:34 |
Mirv | :) | 11:34 |
dednick | mhr3: but the print "changeset end " comes before flushChanges | 11:34 |
mhr3 | dednick, perhaps just pastebin the printing diff | 11:36 |
Saviq | tsdgeos, looking at https://launchpadlibrarian.net/157087510/Stacktrace.txt | 11:36 |
Saviq | tsdgeos, that's from bug #1253603 | 11:36 |
ubot5 | bug 1253603 in Unity 8 "Qt 5.2: unity8 crashed with SIGABRT in raise()" [Undecided,New] https://launchpad.net/bugs/1253603 | 11:36 |
Saviq | tsdgeos, it failed assert "m_nodes.contains(node)" | 11:37 |
tsdgeos | Saviq: that file has changed considerably since beta1 | 11:40 |
Saviq | tsdgeos, ok | 11:40 |
Saviq | tsdgeos, that's good news | 11:41 |
Saviq | Mirv, ↑↑ | 11:41 |
tsdgeos | Mirv: any chance you package the rc1 snapshot? | 11:41 |
tsdgeos | http://download.qt-project.org/snapshots/qt/5.2/5.2.0-rc1/2013-11-21_160/ | 11:41 |
tsdgeos | it's not official rc1 | 11:41 |
tsdgeos | but it's much better than what we have for testing | 11:41 |
Saviq | tsdgeos, how far away would 'official rc1' be/ | 11:41 |
Saviq | mooooom I want my rshift back ;9 | 11:41 |
Mirv | tsdgeos: yeah I'd hope for the real one which should be still out this week, originally Tuesday, but still.. | 11:42 |
tsdgeos | Saviq: "this week" | 11:42 |
tsdgeos | but today is thursday already :D | 11:42 |
dednick | mhr3: i think this will do it. http://pastebin.ubuntu.com/6452852/ | 11:42 |
Saviq | tsdgeos, Mirv, FWIW, the changes between the snapshot and official rc1 will probably be minimal | 11:43 |
Saviq | if any | 11:43 |
tsdgeos | Saviq: "a bit" was a bit of understatment :D | 11:43 |
tsdgeos | see http://pastebin.kde.org/pmkjmy8pc | 11:43 |
tsdgeos | 109 files changed, 3193 insertions(+), 1492 deletions(-) | 11:43 |
greyback | Saviq: that assert error fixed since beta1: https://bugreports.qt-project.org/browse/QTBUG-34311 | 11:43 |
Saviq | tsdgeos, right | 11:43 |
Cimi | Saviq, this clip is annoying... might use a shadereffect | 11:43 |
=== _salem is now known as salem_ | ||
Saviq | Cimi, that will clip, too | 11:44 |
Cimi | why? | 11:44 |
Cimi | because it's ouseide the item? | 11:44 |
Saviq | Cimi, because ShaderSource only looks within the bounds of the item it's sourcing from | 11:44 |
Saviq | Cimi, yes | 11:44 |
Cimi | Saviq, so if I use a container? | 11:44 |
Mirv | it'll be easier if it's enough to build qtbase + qtdeclarative or such | 11:45 |
mhr3 | dednick, but, but... that's impossible! | 11:45 |
Saviq | Cimi, if everything will be within the bounds of the item, layer will work just the same | 11:45 |
dednick | mhr3: I KNOW! | 11:45 |
Saviq | Cimi, layer is effectively just a shortcut to shadersource | 11:45 |
mhr3 | dednick, can you get full stacktrace of the "No row..."? | 11:45 |
=== MacSlow is now known as MacSlow|lunch | ||
mhr3 | who the hell calls that | 11:46 |
Cimi | mmm ok | 11:46 |
dednick | mhr3: er, yeah, but it sucks, so i'm currently building debug symbols for qtbase/declarative | 11:46 |
Saviq | Mirv, that would be a start, sure | 11:46 |
Saviq | Mirv, it's what we're using most anyway | 11:46 |
Cimi | Saviq, I'm not convinced of that | 11:46 |
mhr3 | dednick, why don't you just apt-get them? | 11:46 |
dednick | mhr3: um. where from? | 11:46 |
Cimi | Saviq, if I put layer.enabled = true | 11:46 |
Cimi | Saviq, on a container | 11:47 |
Cimi | it doesn't seem to apply layers on the children's too | 11:47 |
Cimi | so I can't really do that | 11:47 |
mhr3 | dednick, https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages | 11:47 |
dednick | mhr3: yeah, just looking now | 11:47 |
Saviq | Cimi, http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-item.html#layer.sourceRect-prop | 11:47 |
Cimi | Saviq, :D | 11:48 |
Cimi | Saviq, just now that I was happy to play with shaders :D | 11:48 |
Saviq | Cimi, tsdgeos told you to look over those before | 11:48 |
Cimi | Saviq, I missed that, yeah he told me | 11:49 |
Saviq | Mirv, so bug #1253603 is fixed past beta1, want to mark it somehow for that? | 11:50 |
ubot5 | bug 1253603 in Unity 8 "Qt 5.2: unity8 crashed with SIGABRT in raise()" [Undecided,New] https://launchpad.net/bugs/1253603 | 11:50 |
Saviq | we need a way to track upstream JIRA bugs in LP | 11:51 |
Saviq | /food | 11:53 |
dednick | mhr3: hm.. still not much help. http://pastebin.ubuntu.com/6452903/ | 11:58 |
mhr3 | dednick, that does not look like the main thread | 11:58 |
mhr3 | dednick, info threads | 11:59 |
mhr3 | where's the *? | 11:59 |
Cimi | Saviq, mmm no | 11:59 |
Cimi | Saviq, I'll tell you after your lunch | 11:59 |
dednick | mhr3: thread 1. "unity8" | 12:00 |
mhr3 | wtf just got wtf-er | 12:00 |
mhr3 | dednick, let's just say that your computer is broken, k? :P | 12:01 |
tsdgeos | lol | 12:01 |
dednick | mhr3: sounds like a plan to me | 12:02 |
ScopeParking | #ubuntu-unity, If someone could tell me what avant-window-navigator on WPD8 is ? seriously (I check the logs for this channel later - so tell myself) , that'd be great .. bye .. off for date night : avant-window-navigator | http://www.webupd8.org/2013/11/avant-window-navigator-gets-new.html | 12:02 |
ScopeParking | leaves. | 12:02 |
dednick | mhr3: something else a bit odd. This all happens on the first event cycle that the object is alive. | 12:08 |
dednick | mhr3: i mean, the first cycle it exists. | 12:09 |
mhr3 | dednick, object == the dee model, or the DeeListModel? | 12:10 |
dednick | mhr3: the DeeListModel | 12:10 |
mhr3 | hmmmm | 12:11 |
mhr3 | but that means that the model is already synchronized | 12:12 |
Mirv | Saviq: marked, and trying a build of qtbase snapshot now | 12:14 |
tsdgeos | grrr, now the test failed somewhere else | 12:22 |
tsdgeos | actually a different test | 12:24 |
mhr3 | dednick, idea - i think the read to this model is coming because of a change in a different model | 12:26 |
mhr3 | dednick, can you pastebin an unfilitered output? | 12:26 |
mhr3 | unfiltered* | 12:26 |
mhr3 | cause things are complicated in category models | 12:27 |
mhr3 | all the data is one sharedmodel, but that shared model has data for all categories, so results are split up by category in a filteredmodel | 12:28 |
mhr3 | so it's possible that one category emits flush, but that somehow triggers read in a different category which is in middle of transaction | 12:29 |
dednick | mhr3: http://pastebin.ubuntu.com/6453015/ | 12:29 |
mhr3 | and that would totally explain it | 12:29 |
mhr3 | exactly, flush in a different model right before the invalid reads | 12:29 |
dednick | mhr3: hm. i c | 12:30 |
mhr3 | dednick, we could update the count after each processChange(), that might actually fix it | 12:31 |
mhr3 | although a bit nasty | 12:32 |
dednick | mhr3: .. dont think so. you need to update the count between start/endAdd/Remove | 12:32 |
mhr3 | and not just a bit | 12:32 |
mhr3 | well.. you *should* :) | 12:32 |
dednick | i mean startRemoveRows / endRemoveRows | 12:32 |
dednick | mhr3: no, i think there are actually issues if you dont. | 12:32 |
dednick | hm. but we shouldnt be receiving reads from one model when another is flushed. | 12:34 |
mhr3 | dednick, well if the flush removes stuff, it might change the position of a different view so it might become visible | 12:35 |
mhr3 | dednick, more hack ideas - flush inside rowCount()? | 12:35 |
dednick | mhr3: rowCount is only called if it changes... | 12:36 |
mhr3 | dednick, or if it becomes visible :) | 12:36 |
dednick | mhr3: well, why are we receiving other model messages between the start/changes/end of a set anyway? | 12:36 |
dednick | mhr3: i thought you said it was sync ;) | 12:37 |
mhr3 | well.. yea :) | 12:37 |
dednick | NO!!! | 12:37 |
mhr3 | disregarded the master shared model thing | 12:38 |
dednick | finger pointing! | 12:38 |
=== alan_g is now known as alan_g|lunch | ||
dednick | mhr3: any way to make it sync? | 12:38 |
mhr3 | thinking | 12:38 |
mhr3 | i guess we'd need a demultiplexor that's dee-qt aware | 12:40 |
mhr3 | so that if a changeset is in progress in one submodel the changes are flushed if the next change is going to affect a different submodel | 12:41 |
dednick | um. hm. so the events are coming into the master interleaved? | 12:42 |
mhr3 | not necessarily, the problem is that the changeset-end is done in all submodels at the same time | 12:43 |
mhr3 | so the transaction is "shared" in all the submodels | 12:44 |
dednick | hm. | 12:45 |
mhr3 | which means that we'd need to turn the master transaction into multiple transactions in the filtermodels | 12:47 |
mhr3 | so... a real fix is to implement proper model demultiplexor inside unity-core | 12:49 |
mhr3 | not trivial, but not too hard either | 12:49 |
mhr3 | plus all the code could really go there, it'd just transparently work in the upper layers | 12:50 |
dandrader | Saviq, when do we get a new unity8 release? | 12:50 |
mhr3 | all it needs is to serialize and changesets for the submodels | 12:50 |
dandrader | Saviq, is CI still messed up | 12:50 |
dednick | mhr3: i'm presuming you're talking about the agreggator scope here right? | 12:53 |
mhr3 | dednick, i'm talking about the ScopeProxy::GetResultsForCategory() | 12:53 |
mhr3 | dednick, right now it just returns a bunch of DeeFilterModels, which are basically independent and share the transaction | 12:54 |
mhr3 | if there was this demultiplexor that would feed the data to them, it could make sure the transactions can't be active in parallel | 12:55 |
mhr3 | dednick, as a bonus it'd even be slightly more efficient ;) | 12:56 |
mhr3 | dednick, dunno if you want to take a stab at that | 12:56 |
dednick | mhr3: why bother with shared transactions in the first place? Seeing as they're going to turn into separate ones anyway. | 12:57 |
dednick | mhr3: or is it just a unity thing that it's separating them? | 12:57 |
dednick | as in if we just had a view with all the results, it would screw it up. | 12:58 |
mhr3 | dednick, i guess i didn't really think that through when implementing the changesets, if a FilteredModel is attached to a model, it will emit changeset-being and end when the parent model does | 12:59 |
dednick | mhr3: i c | 13:00 |
mhr3 | so if you have multiple filtermodels there.. yey.. shared transactions | 13:00 |
dednick | yeah | 13:00 |
mhr3 | but i don't really see a general way around that, what helps us is that we really want model demultiplexing - in our scenario you can't have one row present in multiple submodels, so the changesets can be fairly easily serialized | 13:04 |
dednick | mhr3: I'll take a look, but don't really get where the demultiplexer would fit in | 13:07 |
mhr3 | dednick, between the sharedmodel and the filtermodels | 13:07 |
mhr3 | dednick, right now the filtermodels just connect to the parent's row-added/removed etc, and decide if they want the row on each change | 13:08 |
dednick | mhr3: yup, i see that | 13:09 |
mhr3 | dednick, if a single demultiplexor connected to the row-changes, it could push the data to the filtermodel itself, and keep track on which was pushed to last, and if that changed, emit changeset-end on it | 13:09 |
=== dandrader is now known as dandrader|afk | ||
dednick | mhr3: and emit a changeset-start on that one again for it's next change presumably | 13:10 |
mhr3 | right | 13:10 |
dednick | mhr3: ok, i think i get it. | 13:10 |
mhr3 | fwiw it shouldn't need any new dee api :) | 13:11 |
mhr3 | unless you want to implement the demultiplexor inside dee itself | 13:11 |
mhr3 | which would actually be useful :) | 13:12 |
dednick | mhr3: how would i stop the signals being connected between the shared and filters model if i didnt add to dee api? | 13:13 |
mhr3 | dednick, hm, right... at the very least you could pass null to the notify functions | 13:15 |
mhr3 | then they wouldn't accept any rows | 13:15 |
mhr3 | ok NULL wouldn't work, but empty function would | 13:17 |
Saviq | dandrader|afk, well, we're still having some issues, but those shouldn't prevent a release | 13:21 |
Saviq | didrocks, if we wanted a unity8 release, landing ask as usual, still/ | 13:22 |
Saviq | ? | 13:22 |
didrocks | Saviq: yep | 13:22 |
didrocks | Saviq: just with the infra half-working, it's taking delays | 13:22 |
=== MacSlow|lunch is now known as MacSlow | ||
didrocks | Saviq: and there is a regression on the phone for wireless which block us FYI | 13:22 |
Saviq | didrocks, that's fine, was just wondering - are we ever going back to auto release? | 13:23 |
=== dandrader|afk is now known as dandrader | ||
=== alan_g|lunch is now known as alan_g | ||
Mirv | Saviq: basically as soon as the CI + autotesting on devices is working, so that we get the same results we now get manually | 13:45 |
Saviq | Mirv, ok, looking forward | 13:45 |
Mirv | and the current queue needs to be unlocked in a manaed way before, also | 13:46 |
Mirv | Saviq: me too :) | 13:46 |
Saviq | mzanetti, https://code.launchpad.net/~saviq/unity8/raise-sigstop/+merge/191212 has the test added | 13:48 |
mzanetti | Saviq: ack | 13:48 |
nic-doffay | tsdgeos, think this is ok now: https://code.launchpad.net/~nicolas-doffay/unity8/category-transition-speed-fix/+merge/195203 | 13:48 |
nic-doffay | I updated the FilterGrid test. | 13:48 |
Saviq | mzanetti, bear in mind it depends on https://code.launchpad.net/~gerboland/unity-mir/listen-for-server-start-stop-ready/+merge/191224 for Mir | 13:49 |
tsdgeos | nic-doffay: i'll review | 13:52 |
nic-doffay | ta tsdgeos | 13:52 |
Cimi | Saviq, the clipping is annoying | 13:52 |
Cimi | Saviq, I tried changing the rect of the layer, but it scales the texture | 13:53 |
Cimi | Saviq, I think I need to use a shader | 13:53 |
Cimi | well | 13:53 |
Cimi | actually no... | 13:53 |
Cimi | depends on what the shader gets | 13:53 |
Saviq | Cimi, I'm just trying to tell you that ShaderSource behaves exactly the same as layer does | 13:53 |
Cimi | Saviq, but why? | 13:54 |
Saviq | Cimi, or well, not exactly | 13:54 |
Cimi | Saviq, if I take a container | 13:54 |
Cimi | Saviq, the content of this container is like a texture, no? | 13:54 |
Cimi | like an image | 13:54 |
Saviq | Cimi, just stop drawing outside of the item bounds ;0 | 13:54 |
Cimi | Saviq, I am trying :-\ | 13:55 |
Saviq | grrrrr rshift | 13:55 |
Cimi | Saviq, it's the up scaling of the selected tile | 13:55 |
Cimi | it's scaled up by 1.1, 1.5 etc | 13:55 |
Cimi | *1.15 | 13:55 |
Cimi | so it goes outside the bounds | 13:56 |
Saviq | Cimi, using a transform? | 13:56 |
Cimi | Saviq, currently I have top and bottom margin | 13:56 |
Saviq | Cimi, you can override the ShaderEffect of the layert | 13:56 |
Cimi | let me try with transform | 13:56 |
Saviq | -t | 13:56 |
Cimi | I want to try with the shadereffect | 13:57 |
Cimi | in any case | 13:57 |
Cimi | let me realise I'm stupid | 13:57 |
=== dbarth__ is now known as dbarth | ||
dandrader | tsdgeos, do you know when qt 5.2 is going to be releases (upstream I mean) | 14:11 |
dandrader | released | 14:11 |
tsdgeos | dandrader: before end of year is the target i think | 14:11 |
dandrader | ok | 14:11 |
tsdgeos | http://qt-project.org/wiki/Qt-5.2-release | 14:11 |
tsdgeos | that's not true anymore | 14:12 |
tsdgeos | since the RC isn't there yet | 14:12 |
tsdgeos | but yeah | 14:12 |
dandrader | tsdgeos, interesting | 14:12 |
tsdgeos | it's supposed to be now-ish | 14:12 |
dandrader | tsdgeos, was reading the IRC log, the RC should be decided next Monday | 14:23 |
tsdgeos | ok | 14:24 |
tsdgeos | hmmm | 14:31 |
tsdgeos | has qtubuntu stopped linking? | 14:31 |
tsdgeos | Saviq: greyback: can you check? | 14:31 |
greyback | tsdgeos: which qt version? | 14:32 |
tsdgeos | 5.0.x | 14:32 |
greyback | ok, checking... | 14:32 |
tsdgeos | greyback: trusty up-to-date | 14:32 |
tsdgeos | /home/tsdgeos_work/phablet/qtubuntu/qtubuntu/src/platforms/base/context.cc:59: undefined reference to `eglDestroyContext' | 14:32 |
tsdgeos | seems we don't link to egl when we should | 14:32 |
greyback | hmm | 14:32 |
greyback | I had similar yesterday on my phone | 14:33 |
greyback | thoght it was my fault | 14:33 |
tsdgeos | probably mir or something stopped pulling it | 14:33 |
tsdgeos | but if we use it direcrly | 14:34 |
tsdgeos | we should be linking to it | 14:34 |
tsdgeos | not expect others to pull it | 14:34 |
* tsdgeos does a MR | 14:34 | |
Saviq | tsdgeos, sorry, in session, but see you're handling | 14:35 |
tsdgeos | yep | 14:35 |
tsdgeos | greyback: https://code.launchpad.net/~aacid/qtubuntu/egl_link/+merge/196120 | 14:42 |
greyback | tsdgeos: ta, but would that be set in a pkgconfig file somewhere? | 14:43 |
tsdgeos | greyback: why? | 14:43 |
tsdgeos | we're using it ourselves and not exposing it to anyone else (afaics) | 14:44 |
dandrader | tsdgeos, I was getting this linking error as well | 14:44 |
tsdgeos | so doesn't make much sense for it to be in an input pkgconfig nor in an output one, no? | 14:44 |
dandrader | tsdgeos, my solution was to manually modify the build files to refer to the missing lib | 14:44 |
tsdgeos | dandrader: getting it in qtubuntu or where? | 14:45 |
dandrader | tsdgeos, qtubuntu | 14:45 |
tsdgeos | ok | 14:45 |
dandrader | tsdgeos, I wondered why other people were not getting this error as well but did not investigate further | 14:46 |
tsdgeos | new mir landed yesterday, so probably changed the game | 14:46 |
dandrader | tsdgeos, that's what I had to do to have it working: http://paste.ubuntu.com/6453587/ | 14:47 |
greyback | tsdgeos: well that switch is set in /usr/lib/x86_64-linux-gnu/pkgconfig/egl.pc which is supplied by libegl1-mesa-dev, so let's just use that | 14:47 |
tsdgeos | greyback: ah you mean using the pkg-config of egl | 14:48 |
tsdgeos | sure, can do that | 14:48 |
greyback | tsdgeos: indeed. Sorry | 14:48 |
dandrader | is Dash::test_show_scope_on_load qmltest know to be unstable? | 14:50 |
dandrader | known | 14:50 |
dandrader | hmm, seems so. My MP is not the only one getting this failure... | 14:51 |
tsdgeos | dandrader: i'm on it | 14:53 |
tsdgeos | if you guys stop approving stuff | 14:53 |
tsdgeos | mine will get jenkins cycles faster | 14:53 |
tsdgeos | and we'll all be happier once it's merged | 14:54 |
dandrader | tsdgeos, ah, cool. you already have an MP for it? | 14:54 |
tsdgeos | dandrader: yessir | 14:54 |
dandrader | tsdgeos, link please | 14:54 |
tsdgeos | https://code.launchpad.net/~aacid/unity8/LVWPH_do_not_do_stuff_if_parent_gone | 14:54 |
tsdgeos | it's actually more about a different one | 14:54 |
tsdgeos | but i added some extra code for this one too | 14:54 |
tsdgeos | greyback: https://code.launchpad.net/~aacid/qtubuntu/egl_link/+merge/196120 | 14:55 |
dandrader | man, looks tricky | 14:55 |
greyback | tsdgeos: nice | 14:55 |
tsdgeos | dandrader: it is :-/ | 14:56 |
tsdgeos | let's hope my MR actually fixes it or at least gives good enough info of what's going on | 14:57 |
Saviq | tsdgeos, it's merging here http://s-jenkins:8080/job/unity8-autolanding/754/console | 15:01 |
tsdgeos | yep, following at http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-trusty/362/console | 15:01 |
=== dandrader is now known as dandrader|lunch | ||
=== alan_g is now known as alan_g|tea | ||
=== alan_g|tea is now known as alan_g | ||
tsdgeos | dandrader|lunch: did my reasoning convince you? | 15:33 |
tsdgeos | merged \o/ | 15:43 |
tsdgeos | now let's see if others merge too | 15:43 |
tsdgeos | and it's not only one time luck | 15:43 |
Saviq | tsdgeos, unity8 crash on shutdown https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1253685 | 15:46 |
ubot5 | Error: ubuntu bug 1253685 not found | 15:46 |
Saviq | tsdgeos, seen earlier? worth looking at at all? | 15:46 |
tsdgeos | Saviq: digging | 15:49 |
tsdgeos | don't remember it at first sight | 15:49 |
tsdgeos | Saviq: so it seems that the InputArea that received the destroyed signal was also destroyed, since its internal dptr is 0 ( isSignalConnected (signal_index=28, this=0x0) ) | 15:58 |
tsdgeos | but had a look at the code and can't see how that can happen | 15:59 |
tsdgeos | since when the inputarea is destroyed it says the world they don't care about them anymore | 15:59 |
Saviq | tsdgeos, mhm | 15:59 |
tsdgeos | or something else got borked in memory and what we're seeing is stuff that was already crashed before | 16:00 |
Saviq | tsdgeos, ok, let's see what happens under 5.2 | 16:00 |
tsdgeos | Saviq: i guess not reproduceable? | 16:01 |
Saviq | tsdgeos, easily | 16:01 |
Saviq | tsdgeos, just stop unity8 | 16:01 |
tsdgeos | really? | 16:01 |
tsdgeos | interesting | 16:01 |
Saviq | tsdgeos, run from the console | 16:01 |
tsdgeos | that used to work a while ago | 16:01 |
Saviq | tsdgeos, Ctrl+C | 16:01 |
Saviq | → crash | 16:01 |
tsdgeos | Saviq: want me to dig or wait for 5.2 update? | 16:02 |
Saviq | tsdgeos, nah | 16:03 |
Saviq | tsdgeos, got another one from 5.2, let's see how that looks like ;) | 16:03 |
tsdgeos | he he | 16:06 |
Cimi | Saviq, shader effect works btw | 16:30 |
Cimi | I don't like the code though :) | 16:31 |
tsdgeos | 3 CI successes in a row | 16:32 |
tsdgeos | \o/ | 16:32 |
Saviq | tsdgeos, kudos | 16:33 |
Cimi | Saviq, http://paste.ubuntu.com/6454131/ | 16:48 |
=== dandrader|lunch is now known as dandrader | ||
dandrader | tsdgeos, on the qtubuntu egl thing? Yeah, I don't have a strong option there to be honest | 16:51 |
Cimi | this one is probably easier to read http://paste.ubuntu.com/6454148/ | 16:52 |
tsdgeos | oki | 16:52 |
Cimi | Saviq, can I do that or it sucks? ^ | 16:52 |
Saviq | Cimi, not gonna be able to look at this today | 16:52 |
Saviq | Mirv, ping | 16:55 |
=== boiko_ is now known as boiko | ||
kgunn | alan_g: worked like a champ | 17:02 |
kgunn | i even verified what i built was really installed | 17:02 |
kgunn | alan_g: oops...wait a minute | 17:02 |
Mirv | Saviq: popong | 17:03 |
Saviq | Mirv, you somehow managed to get apport-cli to file a bug against 5.2 | 17:03 |
Saviq | Mirv, or well, apport, not necessarily 5.2 | 17:03 |
Saviq | Mirv, I got the retrace, but couldn't get apport to file the bug | 17:03 |
Saviq | Mirv, did you use some trick to get it up? | 17:05 |
Mirv | Saviq: vim file.crash, remove the line that has the message about why it can't be submitted :) | 17:05 |
Saviq | Mirv, lol | 17:06 |
Saviq | Mirv, nice one | 17:06 |
Mirv | you're welcome. I'd prefer some --project unity8 or such ie "just file it, just not against Ubunti" | 17:07 |
Cimi | tsdgeos, does finally 5.2 fix the flick velocity and deceleration? | 17:49 |
Cimi | otherwise let's patch!!! | 17:49 |
=== alan_g is now known as alan_g|EOD | ||
=== dandrader is now known as dandrader|afk | ||
=== dandrader|afk is now known as dandrader | ||
=== salem_ is now known as _salem |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!