| Saviq | Mirv, hey, any progress on Qt migration? | 08:40 |
|---|---|---|
| Mirv | Saviq: a pkg-kde-tools upload from Kubuntu broke half of the autopkgtests, so the night was pretty much wasted. otherwise it was sounding promising yesterday evening with me and xnox removing possibly the last blockers - even though the Qt migration is now mixed with poppler transition and s390x architecture transitions | 08:41 |
| Mirv | Saviq: unfortunately the xenial is ever moving target... | 08:41 |
| Saviq | Mirv, ack | 08:43 |
| Saviq | Mirv, silos 12+59 still good enough for testing things on top, though> | 08:50 |
| Saviq | ? | 08:50 |
| === nudtrobert1 is now known as nudtrobert | ||
| Mirv | Saviq: should be yes (for phone) | 10:04 |
| Mirv | Saviq: latest qtbase changes are just test and s390x fixes | 10:05 |
| Mirv | (in proposed) | 10:05 |
| Saviq | Mirv, why the qtmir-gles change btw? the added dependency on libqt5test5? plain qtmir doesn't have that? | 10:23 |
| Saviq | is it because of the -gles dependencies? | 10:24 |
| Mirv | Saviq: some autopkgtest cmake error was seen that seemed like missing test library: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/q/qtmir-gles/20151207_224906@/log.gz - even though it doesn't show up in normal recompilation | 10:25 |
| Mirv | Saviq: so I did a blind upload based on that error and then it seemed fixed https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/q/qtmir-gles/20151208_213113@/log.gz (until this pkg-kde-tools broke it again but that's another story) | 10:25 |
| Mirv | Saviq: not really sure of the real cause, but the failure was only seen with qtmir-gles. some of the -gles packages earlier have needed more hand-guiding apt than the normal packages. | 10:27 |
| Saviq | Mirv, ack | 10:27 |
| Mirv | Saviq: hey btw I'm not sure what's the level of interest but I'm quite far with Qt 5.5 backport to vivid-overlay at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-028/+packages | 10:38 |
| Mirv | Saviq: not for landing but if anyone is interest in even giving a thought if it's a possibility one day. | 10:38 |
| Saviq | Mirv, ack | 10:39 |
| Saviq | tsdgeos, mzanetti, rc-proposed/silo22 has listviewforreviews, but Telegram preview still blocks for a long time when I first try to scroll... ideas? | 11:00 |
| mzanetti | hmm, really | 11:01 |
| mzanetti | was quite smooth for me when I tried in the review | 11:01 |
| * mzanetti tries | 11:01 | |
| mzanetti | Saviq, while you're on rc-proposed. is authenticator working for you? | 11:01 |
| mzanetti | it locks up for me when I click on the "generate pin" button | 11:02 |
| mzanetti | indeed, tg reviews locking up here too | 11:02 |
| tsdgeos | Saviq: no ideas | 11:02 |
| mzanetti | much longer than when I tested that branch | 11:02 |
| tsdgeos | let me flash it | 11:02 |
| Saviq | mzanetti, yeah, auth works | 11:04 |
| mzanetti | dafuq | 11:04 |
| mzanetti | it happened to me already a month ago | 11:04 |
| mzanetti | noone else complained | 11:05 |
| mzanetti | then it recovered | 11:05 |
| mzanetti | now it locks up again for me | 11:05 |
| Saviq | tsdgeos, mzanetti, yeah when I tested the preview in silo 4 before, it was good, too | 11:06 |
| Saviq | it's like something else made it worse | 11:06 |
| Saviq | gah | 11:07 |
| Saviq | aaargh why do I have silo 4 | 11:07 |
| Saviq | tsdgeos, as you were, citrain'ed wrong silo | 11:08 |
| Saviq | mzanetti, ↑ | 11:08 |
| tsdgeos | Saviq: and mzanetti? | 11:09 |
| mzanetti | ? | 11:09 |
| Saviq | good question, mzanetti, apt-cache policy unity8? | 11:09 |
| === vrruiz_ is now known as rvr | ||
| mzanetti | 8.11+15.04.20151126-0ubuntu1 | 11:10 |
| mzanetti | update in the queue | 11:12 |
| Saviq | mzanetti, that's from silo 22? | 11:15 |
| mzanetti | gaaah | 11:16 |
| mzanetti | I thought it would be in rc-proposed | 11:16 |
| mzanetti | released already, I mean | 11:17 |
| Saviq | mzanetti, ok so yeah, as you were, my bad | 11:19 |
| Saviq | biab | 11:25 |
| pete-woods | mzanetti / Saviq: hey. was hoping for some QML advice. I've cooked up a quick app to do VPN connection editing | 11:27 |
| pete-woods | one of this things I want to do is have a (apparently complicated) combo box | 11:27 |
| pete-woods | I can't get the ubuntu one to behave itself | 11:27 |
| mzanetti | pete-woods, | 11:27 |
| pete-woods | I've had no trouble with the QtQuick one | 11:27 |
| pete-woods | http://paste.ubuntu.com/13856153/ | 11:27 |
| mzanetti | have a snippet of code I could test? | 11:28 |
| pete-woods | mzanetti: is the full file http://paste.ubuntu.com/13856197/ | 11:28 |
| pete-woods | if I try and use Ubuntu's OptionSelector, the layouts don't work | 11:29 |
| pete-woods | it stays 1 "widget" high | 11:29 |
| pete-woods | instead of expanding | 11:29 |
| pete-woods | tbh I don't really want it to expand the whole view at all | 11:29 |
| pete-woods | I just want it to hover over the top | 11:29 |
| pete-woods | like a normal combo box | 11:29 |
| pete-woods | (like the QtControls one does) | 11:29 |
| mzanetti | we're talking about "Virtual device type" right? | 11:30 |
| pete-woods | yeah | 11:30 |
| mzanetti | ack. gimme a few | 11:30 |
| pete-woods | there's other funky stuff like if you stick an OptionSelector in a Row element, you get an infinite loop | 11:32 |
| pete-woods | but it at least doesn't crash with RowLayout | 11:32 |
| pete-woods | I'd be happy using QtQuick controls | 11:32 |
| pete-woods | but it's not installed on the phone | 11:32 |
| pete-woods | apologies also that the connection object has an absolute crap ton of properties | 11:34 |
| pete-woods | it seems like we avoid all these widgets in the ubuntu system settings app | 11:35 |
| pete-woods | and have a whole page with a listview in it | 11:35 |
| pete-woods | instead of a combo box | 11:36 |
| mzanetti | yeah... | 11:36 |
| pete-woods | maybe I need to do the same | 11:36 |
| mzanetti | pete-woods, one option would be this: http://paste.ubuntu.com/13856360/ | 11:38 |
| mzanetti | (not sure if you have a design that says you need to use the other) | 11:38 |
| pete-woods | mzanetti: no design here | 11:41 |
| pete-woods | this is just a hacked up thing to show my QML bindings work to QA | 11:41 |
| pete-woods | (and also to have a bit of a practise with QML) | 11:41 |
| pete-woods | I have other combo boxes that have a lot of options in, btw | 11:42 |
| pete-woods | this one just happens to have two | 11:42 |
| pete-woods | I think what I really need to do is make everything into clickable columns | 11:42 |
| pete-woods | flickable | 11:42 |
| pete-woods | like they do in the settings app | 11:42 |
| pete-woods | and stop the manual layout stuff | 11:43 |
| pete-woods | oh, you've done something with z | 11:43 |
| pete-woods | I guess that puts it on the top, or something | 11:43 |
| mzanetti | pete-woods, this is with OptionSelector: http://paste.ubuntu.com/13856449/ | 11:44 |
| mzanetti | I agree it's not nice... the OptionSelector is known to be quite bad | 11:44 |
| mzanetti | pete-woods, well, I did use the z:2 because the popup for the combobox would otherwise be behind the items below | 11:45 |
| mzanetti | which I'd say is a bug in the SDK | 11:45 |
| pete-woods | right now I don't have the experience with QML or the brain space to take on bugs like that | 11:45 |
| pete-woods | but if your fix works then that's fantastic :) | 11:45 |
| mzanetti | yeah, I guess a report for the SDK guys would be a good start :) | 11:45 |
| mzanetti | in your layout I think the ComboButton option looks better | 11:46 |
| mzanetti | yeah, you could also drop the manually added text | 11:47 |
| mzanetti | and put everything in a phone-style column | 11:47 |
| mzanetti | dunno. | 11:47 |
| pete-woods | if I'd known what I was doing, I've have used the phone style column from the start | 11:49 |
| pete-woods | hmm, combobox needs a lot of massaging | 11:56 |
| pete-woods | it doesn't close when you pick an item | 11:56 |
| === greyback__ is now known as greyback | ||
| === marcusto_ is now known as marcustomlinson | ||
| greyback | tsdgeos: having network issues? | 13:33 |
| tsdgeos | greyback: yeah :/ | 13:40 |
| mterry | ltinkl, are you using clang or something instead of gcc? (am I? /me checks) | 14:28 |
| mterry | Just curious why I didn't see the warnings | 14:28 |
| ltinkl | mterry, it's OK, scratch that... I don't see any warnings | 14:29 |
| mterry | Oh good | 14:29 |
| ltinkl | mterry, I reverted the change | 14:29 |
| mterry | ltinkl, about the translations in your diff -- did you say a bot did that automatically? I didn't think the bot ran on non-trunk branches | 14:30 |
| ltinkl | mterry, ye... it came as a surprise to me as well but it must have run somehow | 14:30 |
| ltinkl | mterry, the updated PO files contain the newly added strings (which I reverted since then so it should return back to normal, hopefully) | 14:31 |
| mterry | revno: 2035 | 14:31 |
| mterry | committer: Lukáš Tinkl <lukas.tinkl@canonical.com> | 14:31 |
| mterry | branch nick: oobe | 14:31 |
| mterry | timestamp: Mon 2015-12-07 15:14:40 +0100 | 14:31 |
| mterry | message: | 14:31 |
| mterry | update POT | 14:31 |
| mterry | ltinkl, ^ | 14:31 |
| ltinkl | mterry, that's POT, not PO | 14:31 |
| Saviq | ltinkl, ltinkl, we're updating .pot now in the train | 14:32 |
| Saviq | *translations* get pushed to trunk directly by LP | 14:32 |
| ltinkl | mterry, I only updated the template so that the translators could do their work once this has been merged | 14:32 |
| Saviq | ltinkl, no need to do that btw ↑ | 14:32 |
| ltinkl | Saviq, ye OK but still... how did the translations end up in a non-trunk branch? | 14:33 |
| mterry | ltinkl, they come from your merges. But you shouldn't have a diff from that | 14:33 |
| ltinkl | Saviq, you still need to update the _template_ right? | 14:33 |
| mterry | ltinkl, I'm doing (bzr log po/ia.po) | 14:33 |
| Saviq | ltinkl, no, template is now updated automagically on release | 14:33 |
| ltinkl | Saviq, that is too late | 14:34 |
| Saviq | ltinkl, no it's not, people can't translate before anyway (not via LP at least) | 14:34 |
| ltinkl | Saviq, it means the moment you release the stuff with new strings you still have not up-to-date translations | 14:34 |
| mterry | ltinkl, translators aren't seeing your branch before it lands in trunk anyway... | 14:34 |
| Saviq | ltinkl, and avoids conflicts | 14:34 |
| mterry | ltinkl, we have a string freeze | 14:35 |
| ltinkl | ok | 14:35 |
| ltinkl | still doesn't explain how the new translations landed in a non-trunk branch | 14:35 |
| * ltinkl is puzzled | 14:35 | |
| mterry | ltinkl, also I still am not sure how you're out of sync with translations -- but maybe do a bzr pull in a trunk branch and copy all the po files over to get back in sync | 14:35 |
| ltinkl | mterry, yeah, guess I'll do that... then we'll rely on the bot to do the merge again, once it lands in trunk | 14:36 |
| mterry | ltinkl, or do a bzr revert -r for a trunk revision, if you can untangle the bzr mess | 14:36 |
| Saviq | ltinkl, fwiw http://bazaar.launchpad.net/~ci-train-bot/unity8/unity8-ubuntu-xenial-landing-022/revision/2096 this is what the bot does after it merges all branches and such | 14:36 |
| ltinkl | Saviq, so it lands the translations and _then_ updates the POT file? | 14:37 |
| mterry | ltinkl, no it updates POT file, we release | 14:37 |
| ltinkl | ah ok | 14:37 |
| mterry | ltinkl, then a separate bot periodically updates translations | 14:37 |
| Saviq | ltinkl, not translations, translations are put on top to trunk directly | 14:37 |
| mterry | directly to trunk | 14:37 |
| ltinkl | I see, ok :) | 14:37 |
| mterry | ltinkl, so can you ask the ofono folks if they know if that mcc table exists anywhere already, and if not, where might be a good place to add it? | 14:43 |
| mterry | I bet some other component will want it at some point | 14:44 |
| mterry | System Settings for example? | 14:44 |
| ltinkl | mterry, sure, any idea who do I talk to? | 14:44 |
| * mterry wracks his brain... tiagosh? I can't remember who all works on it today | 14:46 | |
| mterry | ltinkl, ^ | 14:46 |
| ltinkl | mterry, pushed the trunk translations, the diff now looks much better :) | 14:47 |
| mterry | Looked him up on directory, his title is "Telephony & Messaging Engineer" so that sounds right :) | 14:47 |
| mterry | ltinkl, nice | 14:47 |
| mterry | :) | 14:47 |
| ltinkl | mterry, still doesn't fit but well... half of the size gone | 14:47 |
| mterry | ltinkl, hah, I'll take what I can get | 14:48 |
| Saviq | hmm hmm, greyback, dandrader, I've noticed a few times now with silo 22 that an app surface is all black until I interact with the phone, I'm thinking fillMode has an issue, wdyt? | 15:00 |
| greyback | Saviq: would be likely culprit. Anything printed in the unity8.log? | 15:00 |
| Saviq | qtmir.surfaces: MirSurface[0xc1bc68,"messaging-app"]::dropPendingBuffer() dropped=0 left=2 - failed to upate texture | 15:01 |
| Saviq | not sure that's it though | 15:01 |
| Saviq | as it was dialer this time | 15:01 |
| Saviq | qtmir.surfaces: MirBufferSGTexture: bind() called but there's no mir buffer to bind to | 15:02 |
| Saviq | greyback, how's that look ↑? | 15:03 |
| * Saviq tries to repro | 15:05 | |
| greyback | dandrader: ^^ you wrote that code, any ideas | 15:11 |
| greyback | I personally think it's a mir problem, there should never be a situation where there's no buffer available after first frame posted | 15:11 |
| tsdgeos | dandrader: https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/fixSwipeAreaPrivateLeak/+merge/280039 | 15:16 |
| Saviq | greyback, in other news, https://code.launchpad.net/~saviq/qtubuntu/wrap-sort/+merge/279778 please? | 15:21 |
| Saviq | greyback, and corresponding https://code.launchpad.net/~phablet-team/qtubuntu/gles-sync/+merge/279779 | 15:21 |
| ltinkl | tsdgeos, why not make UCSwipeAreaPrivate a QScopedpointer instead? | 15:22 |
| tsdgeos | ltinkl: why make it a QScopedPointer? | 15:22 |
| ltinkl | tsdgeos, if it is already a QObject, then ye, it makes sense what you did; I thought it wasn't | 15:23 |
| tsdgeos | ltinkl: if it wasn't a QObject I could not do what i did | 15:23 |
| Saviq | mzanetti, double-check https://code.launchpad.net/~unity-team/qtmir/surfaceItemFillMode/+merge/279757 for me please? it's just a resubmission | 15:25 |
| Saviq | greyback, same for https://code.launchpad.net/~unity-team/qtmir/multiSurfaceApp/+merge/279759 please | 15:26 |
| Saviq | dandrader, don't see an approval on https://code.launchpad.net/~dandrader/unity8/multiSurfaceApp/+merge/279112 or the ones it supersedes? | 15:27 |
| Saviq | or https://code.launchpad.net/~dandrader/unity8/surfaceItemFillMode/+merge/279010 | 15:27 |
| Saviq | tsdgeos, you were having a look at https://code.launchpad.net/~saviq/unity8/in-train-pot-update/+merge/279100 - others agree it's fine | 15:29 |
| dandrader | Saviq, how common is tha black window issue | 15:30 |
| Saviq | dandrader, seen it 3-4 times now | 15:31 |
| tsdgeos | Saviq: sure, want me to top approve¿? | 15:31 |
| Saviq | tsdgeos, yes please | 15:31 |
| mzanetti | Saviq, want me to test it again? | 15:33 |
| Saviq | mzanetti, no, rather just sanity-check the diff | 15:34 |
| mzanetti | Saviq, ok. done | 15:38 |
| Saviq | dandrader, so yeah, it does look like the bind() message is related, IIUC before we'd bind anyway, unless built with asserts? | 15:40 |
| Saviq | obviously no steps to repro :/ | 15:40 |
| Saviq | greyback, so wdyt ↑? while I understand it's a Mir issue, the result of https://code.launchpad.net/~unity-team/qtmir/surfaceItemFillMode/+merge/279757#diff-line-58 is that we're getting black | 15:43 |
| dandrader | Saviq, greyback I was getting this black frames issue all the time after merging trunk in fillModes weeks ago, after having that branch lying around for quite a long time. turned out to be a small detail in the merge (aka bad merge) | 15:44 |
| Saviq | where before we'd just go "meh, let's bind anyway" | 15:44 |
| dandrader | Saviq, greyback hopefully it's something similar again | 15:44 |
| greyback | dandrader: have you time to look into it? Or should I? | 15:44 |
| dandrader | greyback, you would be the safest option. I only have a couple of hours till EOW | 15:45 |
| greyback | ok | 15:45 |
| Saviq | greyback, thanks, IMO that's blocking silo 22 now | 15:45 |
| greyback | Saviq: what device you testing on, in case it's more easily repro-ed on that | 15:45 |
| Saviq | greyback, only seen on krillin | 15:45 |
| greyback | Saviq: ok | 15:45 |
| Saviq | greyback, will start AP on mako and monitor unity8.log | 15:45 |
| Saviq | oh fun, stopped unity8 mid-rotation :) | 15:46 |
| Saviq | greyback, grepping through unity8.log I can see a few dozen of those messages on either krillin or mako | 15:48 |
| greyback | hrmph | 15:49 |
| greyback | this displeases me | 15:49 |
| Saviq | and yeah already got 3 of those after having started u8 ap tests | 15:50 |
| Saviq | can't confirm it's ending up black, but reading the code it has to, doesn't it | 15:50 |
| Saviq | as the texture's bound to 0 | 15:50 |
| Saviq | so it's like hasBuffer() is lying? | 15:51 |
| Saviq | since everything is fine if we ignore its output? | 15:51 |
| dandrader | Saviq, can't reproduce it on N7 | 16:59 |
| Saviq | dandrader, yeah I wasn't able to find steps to repro, but the bind() message gets printed relatively often | 17:03 |
| Saviq | greyback, the app lifecycle ap tests seem to be a semi-reliable way to see the bind() msg, not necessarily black app, though | 17:04 |
| Saviq | but that's likely because I don't notice it, not that it's not there | 17:05 |
| greyback | Saviq: ack, have got it myself | 17:06 |
| === bschaefer_ is now known as bschaefer | ||
| Saviq | josharenson, ok, so it seems to be as simple as that: cmake -DCMAKE_BUILD_TYPE=Release and it won't build | 23:00 |
| Saviq | josharenson, we're building Debug by default | 23:01 |
| josharenson | Saviq: yup can confirm | 23:01 |
| Saviq | josharenson, now that doesn't sound like a valid situation though | 23:01 |
| josharenson | it breaks | 23:01 |
| Saviq | /methinks it warrants a bug against the toolchain | 23:02 |
| josharenson | agreed | 23:03 |
| Saviq | josharenson, so according to doko (our toolchain expert) this might very well happen | 23:32 |
| Saviq | hmm clearing one thing up | 23:34 |
| Saviq | josharenson, doko asked for us to file a bug anyway to clear this up, I'll try and create a minimal project that shows the issue tomorrow | 23:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!