| === marcusto_ is now known as marcustomlinson | ||
| tsdgeos | anyone has any clue how do i get the serach indicator? | 08:43 |
|---|---|---|
| tsdgeos | we have code for it | 08:43 |
| tsdgeos | but can't find how to make it show :D | 08:43 |
| tsdgeos | ah right the tablet mode | 08:45 |
| tsdgeos | and we don't do that anymore | 08:46 |
| tsdgeos | confused | 08:46 |
| tsdgeos | mzanetti: damnit didn't see your branch for the strings thing | 08:56 |
| mzanetti | tsdgeos, oops. sorry | 08:57 |
| tsdgeos | mzanetti: my fault, but since i have more things maybe we can take mine? | 08:57 |
| mzanetti | ack | 08:57 |
| Saviq | tsdgeos, does i18n.ctr even work https://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.i18n/ ? | 09:01 |
| * Saviq was used to // TRANSLATORS: | 09:02 | |
| tsdgeos | Saviq: it does, i made it | 09:03 |
| Saviq | tsdgeos, it does mean that i18n.ctr("Foo", "foo") and i18n.ctr("Bar", "foo") are treated separately, right? | 09:03 |
| tsdgeos | Saviq: correct | 09:04 |
| * Saviq wonders if LP works with msgctx | 09:04 | |
| tsdgeos | Saviq: basically https://code.launchpad.net/~aacid/dialer-app/AllIsNotAll/+merge/243049 | 09:04 |
| tsdgeos | it does | 09:04 |
| tsdgeos | Saviq: see https://translations.launchpad.net/dialer-app/trunk/+pots/dialer-app/es/+translate?batch=10&show=all&search=all | 09:05 |
| tsdgeos | 22 -> Todos | 09:05 |
| tsdgeos | 23 -> Todas | 09:05 |
| Saviq | mhm | 09:05 |
| tsdgeos | the other way around :d | 09:05 |
| * Saviq just wonders if it's abuse to use ctx when the point is to explain, not give context in the gettext sense | 09:06 | |
| Saviq | but maybe it's fine, we can always revisit when we see it a problem somewhere | 09:07 |
| tsdgeos | Saviq: it's not abusing it | 09:07 |
| tsdgeos | because when you get a "Lock" that is actually a "Lock" | 09:07 |
| tsdgeos | and not a "Do Lock" | 09:07 |
| tsdgeos | you want it to be translated differently | 09:07 |
| Saviq | tsdgeos, sure, this case is totally legit | 09:07 |
| Saviq | it just feels weird to have only one instance of a msgid and addint msgctx to it, but again, that's just me used to // TRANSLATORS: before msgctx | 09:09 |
| Saviq | OTOH if you have multiple instances of msgid, that you do want to keep the same, msgctx will break that | 09:09 |
| Saviq | unless you add it everywhere | 09:10 |
| Saviq | anyway, we probably don't have enough strings to have that problem | 09:10 |
| tsdgeos | or that you add different contexts | 09:10 |
| tsdgeos | like i did for "Search" | 09:10 |
| tsdgeos | Since they were maybe problematic already | 09:10 |
| tsdgeos | since one is a text hint and the other is a button | 09:11 |
| tsdgeos | first could be a noun and second a verb | 09:11 |
| Saviq | sure, when the context is different, ctx makes total sense | 09:11 |
| Saviq | but yeah, we have little translatables anyway | 09:11 |
| tsdgeos | Saviq: do you have any idea as to if we actually use SearchIndicator.qml at all? | 09:17 |
| Saviq | tsdgeos, we don't | 09:18 |
| tsdgeos | right | 09:18 |
| tsdgeos | makes sense i couldn't find where we did :D | 09:18 |
| Saviq | tsdgeos, we did, in the Panel, when scopes were still integrated with the shell | 09:19 |
| Saviq | way back when | 09:19 |
| tsdgeos | ok, i'll prepare a mr to remove it, on top of the ctr changes since otherwise it will all explode and conflict | 09:20 |
| Saviq | tsdgeos, or just drop it in the same MP... | 09:21 |
| tsdgeos | Saviq: ok | 09:21 |
| mzanetti | tsdgeos, hey, there are more strings in Dialogs.qml I'd say | 09:25 |
| mzanetti | you just updated the two from the bugreport afaics | 09:25 |
| tsdgeos | mzanetti: the only ones that i found could be either names or verbs | 09:25 |
| mzanetti | how's "Reboot" different than "Shutdown"? | 09:26 |
| * tsdgeos realizes we have shutdown and shut down | 09:30 | |
| tsdgeos | mzanetti: agreed shutdown should not need a context | 09:30 |
| tsdgeos | mzanetti: i can add context to them all if you prefer | 09:31 |
| mzanetti | I really don't know. not a translator | 09:31 |
| mzanetti | I just try to understand when exactly it is needed, to be better to translators in the future | 09:32 |
| mzanetti | right now still a bit confused tbh | 09:32 |
| tsdgeos | mzanetti: so basically context is needed when the word can be either a noun or a verb | 09:32 |
| tsdgeos | Lock | 09:32 |
| tsdgeos | Reply | 09:32 |
| tsdgeos | Call | 09:32 |
| mzanetti | but I guess it also depends on where it is used | 09:33 |
| mzanetti | or things like "Keep this short" or something as a hint for translators might be useful too at times | 09:33 |
| tsdgeos | i.e. is "Call" the fact that you got a Call or the button you press to start a call | 09:34 |
| mzanetti | yeah, the "call" example makes sense to me | 09:34 |
| tsdgeos | the keep it short is usually that our coding sucks and we put the burden on the translator, but yeah that's sometimes used too | 09:35 |
| mzanetti | tsdgeos, how about "Power"? | 09:36 |
| mzanetti | probably only a name... | 09:36 |
| mzanetti | but I guess for german that could use some context | 09:37 |
| tsdgeos | mzanetti: correct | 09:37 |
| mzanetti | could think of 3 words how to translate that | 09:37 |
| tsdgeos | right, usually if your string is only 1 word, it's a potential candidate to context | 09:37 |
| tsdgeos | since the target language may have multiple words that match back to that 1 word | 09:37 |
| mzanetti | yeah, that's why I added all of Dialog.qml to my MP... | 09:38 |
| mzanetti | but again... not that I would have had a real reason... just seemed sensible to me yesterday night | 09:38 |
| mzanetti | and I like your i18n.ctr() better than the TRANSLATORS comment too | 09:39 |
| tsdgeos | just that i messed up and forgot to add the c in some cases | 09:40 |
| tsdgeos | good thing the reporter realized | 09:40 |
| mzanetti | right... I saw that too | 09:40 |
| mzanetti | wanted to ask | 09:40 |
| mzanetti | a bit odd the compiler doesn't complain... does it use plural handling instead? | 09:41 |
| tsdgeos | yep | 09:42 |
| tsdgeos | so shutdown or shut down? | 09:47 |
| Saviq | tsdgeos, shutdown is noun | 09:51 |
| Saviq | http://dictionary.cambridge.org/dictionary/british/shutdown | 09:51 |
| tsdgeos | so shut down i guess | 09:51 |
| Saviq | shut down is verb | 09:51 |
| Saviq | http://dictionary.cambridge.org/dictionary/british/shut-sth-down?q=shut+down | 09:52 |
| tsdgeos | at least in the button | 09:52 |
| tsdgeos | not sure about the title one | 09:52 |
| tsdgeos | maybe the title one ought to be shutdown? | 09:52 |
| Saviq | tsdgeos, it really should be "Power off" :P | 09:52 |
| Saviq | shut down is abuse of the term | 09:52 |
| tsdgeos | Saviq: in the title or in the button? | 09:52 |
| Saviq | tsdgeos, I wouldn't change them without asking folks in London, for now I'd say "shut down" in both | 09:53 |
| Mirv | Saviq: tsdgeos: management tends to be on the safe side currently, so it's possible 5.4.1 will be blocked unless more convincing about the quality of it can be made (we're trying to get QA do sanity testing at least on it etc) | 09:54 |
| Mirv | Saviq: tsdgeos: it'd help if 5.4.1 fixes a known vivid blocker | 09:54 |
| tsdgeos | Mirv: it fixes making greyback_ happy | 09:54 |
| tsdgeos | that's a blocker to me | 09:54 |
| Mirv | tsdgeos: sounds indeed a blocker bug being fixed. I wonder what exactly in it makes greyback_ happy? | 09:55 |
| tsdgeos | OVERDRAW stuff not crashing | 09:55 |
| tsdgeos | i.e. actually one of the patches that is in for 5.4.2 and you cherry picked in declarative | 09:55 |
| Mirv | tsdgeos: so, get 1430337 escalated to the milestone? :) | 09:56 |
| Saviq | Mirv, it also fixes device pixel ratio bits mzanetti's working on | 09:56 |
| Mirv | Saviq: are there bugs about those? | 09:56 |
| Mirv | anyway, it'd be nice if you'd run 5.4.1 on your devices so that we get more and more experience on it | 09:57 |
| Mirv | it feels solid to me yesterday/today and I've been doing all kinds of stuff with it | 09:57 |
| Saviq | tsdgeos, it's "shut down" in the title and button in unity7, let's use that | 09:59 |
| tsdgeos | Saviq: perfect | 09:59 |
| Saviq | tsdgeos, btw, have a look at https://errors.ubuntu.com/bucket/?id=/usr/bin/unity8-dash%3A7%3AtestAndSetRelaxed%3AtestAndSetAcquire%3AtestAndSetAcquire%3AfastTryLock%3AQMutex%3A%3Alock please | 10:00 |
| Saviq | tsdgeos, Pat had scopes crashing reliably on mako rtm yesterday | 10:01 |
| tsdgeos | Saviq: ok | 10:03 |
| Saviq | tsdgeos, fwiw I couldn't reproduce, and it only happened on mako, so not crazy critical | 10:03 |
| Saviq | tsdgeos, and then it's Qt 5.3 still.. | 10:03 |
| tsdgeos | right :/ | 10:03 |
| === JMulholland_ is now known as JMulholland | ||
| tsdgeos | Saviq: who would we have to convince to get those errors to have the traces for all threads and not just the main one? | 10:19 |
| Saviq | tsdgeos, hmm Thread Stacktrace should have it all | 10:19 |
| Saviq | but obviously it doesn't | 10:20 |
| * Saviq checks if that's common | 10:20 | |
| Saviq | hyh | 10:21 |
| tsdgeos | afaik lately all the bugs we have | 10:21 |
| tsdgeos | they don't have the thread stacktrace | 10:21 |
| tsdgeos | and it's possible at some point i wondered why we had the stacktrace in two different places (i.e stacktrace vs thread stacktrace) | 10:22 |
| Saviq | tsdgeos, I think the purpose is to point out which thread crashed | 10:23 |
| tsdgeos | sure | 10:24 |
| Saviq | but then it should have a full trace | 10:24 |
| tsdgeos | that'd make sense if one them had them all | 10:24 |
| Saviq | tsdgeos, and it does say "Thread Stacktrace" in the middle of that page... just it shows the same, one, thread | 10:24 |
| Saviq | tsdgeos, Pat uploaded the .crash file, /me uploads to LP, hopefully the retrace there will be more interesting | 10:26 |
| Saviq | or t least complete | 10:26 |
| Saviq | +a | 10:26 |
| tsdgeos | he had one in LP that was incomplete | 10:30 |
| Saviq | so just one thread, too? or not retraced? | 10:31 |
| Saviq | tsdgeos, filed bug #1431796 | 10:32 |
| ubot5 | bug 1431796 in Daisy "Only one thread shown in Thread Stacktrace" [Undecided,New] https://launchpad.net/bugs/1431796 | 10:32 |
| tsdgeos | cool :) | 10:32 |
| Saviq | oooh... signal 7 btw? | 10:33 |
| Saviq | oh yeah, right | 10:35 |
| Saviq | ah crap, we won't get a retrace on LP probably | 10:35 |
| Saviq | maan /me retraces locally | 10:35 |
| tsdgeos | what's 7? | 10:36 |
| tsdgeos | sigbus? | 10:36 |
| tsdgeos | Saviq: the stracktrace on the crash seems quite clean, nothing obvious that would cause a crash | 10:39 |
| Saviq | tsdgeos, kk, let me retrace here and you'll have a look-see again | 10:41 |
| tsdgeos | Saviq: seems lp actually retraced it all | 10:50 |
| tsdgeos | https://i200112393.restricted.launchpadlibrarian.net/200112393/ThreadStacktrace.txt?token=HnqdgK3V6ktrjPBxgJ741CX4WWBzSNz9 | 10:50 |
| Saviq | oh good | 10:51 |
| tsdgeos | except it's wrong | 10:51 |
| tsdgeos | thread 1 can't be thread 1 | 10:52 |
| tsdgeos | wait maybe it can | 10:53 |
| tsdgeos | no | 10:53 |
| tsdgeos | #29 0xb67d1a8c in QQuickPixmapReader::run (this=0x146d2b0) at util/qquickpixmapcache.cpp:688 | 10:53 |
| tsdgeos | it's the QQuickPixmapReader thread | 10:53 |
| Saviq | which might explain why it's all confused | 10:54 |
| tsdgeos | Saviq: can you try to see if you actually get the proper thread 1? | 10:54 |
| Saviq | doubt it but will try | 10:54 |
| Saviq | it's not like I'd do anything else than the retracer, I could, however, get to gdb | 10:55 |
| tsdgeos | right | 10:57 |
| tsdgeos | E_TOO_MANY_THREADS | 10:58 |
| tsdgeos | can't find out what half of them are doing | 10:59 |
| tsdgeos | and then there's Thread 19 which has a broken backtrace | 10:59 |
| Saviq | tsdgeos, yeah, same first thread | 11:08 |
| tsdgeos | Saviq: do you get anything in thrad 19? | 11:09 |
| Saviq | tsdgeos, sec, going into gdb | 11:09 |
| Saviq | as I only got #1 from the retrace, too | 11:09 |
| Saviq | tsdgeos, no, ?? everywhere, likely android side | 11:11 |
| tsdgeos | may be | 11:11 |
| Saviq | tsdgeos, so yeah, everything looks the same in my retrace | 11:12 |
| Saviq | tsdgeos, I'll ask Pat for another .crash if he can get one later today | 11:12 |
| tsdgeos | ok :) | 11:16 |
| === MacSlow is now known as MacSlow|lunch | ||
| mzanetti | dandrader, hey, do you have an up-to-date silo0 installation? | 11:52 |
| mzanetti | dandrader, jouni says the right edge is not working there | 11:52 |
| dandrader | mzanetti, no | 11:52 |
| dandrader | mzanetti, Saviq, have you guys noticed that tst_PhoneStage is now segfaulting in trunk? | 11:53 |
| mzanetti | I haven't yet | 11:53 |
| dandrader | mzanetti, Saviq along with other qmltests errrors elsewhere. Must be due to some new qt release, I suppose | 11:53 |
| Saviq | dandrader, CI didn't have that problem | 11:53 |
| dandrader | Saviq, I have that in my own machine | 11:53 |
| dandrader | Saviq, and here: https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/595/#showFailuresLink | 11:54 |
| * Saviq tries silo 6 tarball | 11:54 | |
| Saviq | oh that's new | 11:54 |
| Saviq | dandrader, but it doesn't in here again https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/598/#showFailuresLink | 11:54 |
| dandrader | Saviq, I suspected all those failures which seem to be unrelated to the MP in question. Then I tried out "make testPhoneStage" in my own machine and it did crash, just like in jenkins, and also with lp:unity8 :/ | 11:55 |
| Saviq | dandrader, it did spin to 350% CPU here... | 11:58 |
| Saviq | under xvfb at least | 11:58 |
| Saviq | but didn't crash (yet) | 11:58 |
| dandrader | Saviq, and overall tests seem much slower to run | 11:58 |
| Saviq | dandrader, indeed, the job went up from 1h to 2h overnight | 12:00 |
| Saviq | dandrader, that was actually UITK release | 12:01 |
| dandrader | hmm | 12:02 |
| Saviq | dandrader, it didn't crash here, 1 failed though | 12:02 |
| * Saviq will try to bisect uitk then | 12:03 | |
| dandrader | Saviq, ok, keep me posted | 12:07 |
| === alan_g is now known as alan_g|lunch | ||
| Cimi | tsdgeos, I am wondering why in that test is stealing the events | 13:04 |
| Cimi | tsdgeos, the zoom out | 13:04 |
| Cimi | what might have changed in qt and / or what is broken | 13:04 |
| Saviq | dandrader, I think I found the culprit http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/revision/1122.1.16 | 13:37 |
| dandrader | Saviq, hmm, interesting. indeed last time it tried animators (for the shell rotation animations) they were buggy | 13:38 |
| dandrader | s/it tried/I tried | 13:38 |
| dandrader | Saviq, but it appears to have been released a while ago, 2015-01-20, so we should have noticed it before... | 13:42 |
| dandrader | Saviq, anyway, will try reverting that to see the difference | 13:43 |
| Saviq | dandrader, no, that got released there into rtm | 13:44 |
| Saviq | dandrader, it just got released into vivid a few days ago | 13:44 |
| dandrader | Saviq, ah, ok | 13:44 |
| Saviq | dandrader, and we do have the indicator running on top of all tests, to speed up waitForRendering() in case the wait should return straight away | 13:48 |
| Saviq | dandrader, yeah, and just confirmed, that's what's causing the slowdown | 13:49 |
| dandrader | Saviq, exactly | 13:49 |
| dandrader | Saviq, and the CPU hogging as well? | 13:50 |
| === MacSlow|lunch is now known as MacSlow | ||
| Saviq | dandrader, yeah | 13:51 |
| Saviq | dandrader, I think one thing to note is that if using an Animator, waitForRendering probably isn't influenced by that | 13:52 |
| === dandrader is now known as dandrader|afk | ||
| === alan_g|lunch is now known as alan_g | ||
| tsdgeos | Cimi: i don't know tbh | 14:28 |
| === dandrader|afk is now known as dandrader | ||
| Saviq | dandrader, FWIW it's not clear what happens with the activity indicator, in itself it doesn't seem broken wrt CPU usage | 14:49 |
| Saviq | dandrader, can you check out https://code.launchpad.net/~saviq/unity8/activity-workaround/+merge/252897 as a workaround | 15:23 |
| dandrader | Saviq, sure. right after I'm done with the task at hand | 15:26 |
| Saviq | dandrader, sure, CI is on it already | 15:26 |
| Saviq | dandrader, all in all it's xvfb that's influenced most: bug #1431957 | 16:32 |
| ubot5 | bug 1431957 in ubuntu-ui-toolkit (Ubuntu) "ActivityIndicator much more CPU intensive under xvfb" [Undecided,New] https://launchpad.net/bugs/1431957 | 16:32 |
| Saviq | dandrader, I was unable to reproduce your crash, and the tests, if ran outside of xvfb, run fine, if longer due to the waitForRendering() bit | 16:33 |
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| === alan_g is now known as alan_g|EOD | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!