[07:22] <tsdgeos> Mirv: hi, just to be sure, what's the best "Qt 5.3 ppa" to use? daily?
[07:29] <Mirv> tsdgeos: the best PPA is to read the _description_ of qt5-beta2 PPA page, which I update if the recommendation changes. so, qt5-beta2 again now, and it has now thanks to late night hacking final versions of qtbase, qtxmlpatterns and qtdeclarative (no difference on the various bugs, though)
[07:30] <tsdgeos> Mirv: well you told me to use daily before so i was using that one :D
[07:30] <tsdgeos> i'll update to beta2 then
[07:31] <Mirv> tsdgeos: but many of the issues seem to come down to a read only property of a thing already revealed by (now disabled) UITK unit test, and UITK team (timp/zsombi) already had some idea that it doesn't seem like too hard. music-app has a type error, and webbrowser is using a private symbol that has disappeared
[07:31] <tsdgeos> oki :)
[07:31] <Mirv> tsdgeos: yeah well it's complicated, sorry :) sometimes I know qt5-daily has newer stuff (now it's pretty much equal to qt5-beta2) so I mentioned it so that you'd get stuff earlier. but the general idea is to get everything that works to qt5-beta2
[07:32] <tsdgeos> ok, i'll switch to beta2
[07:32] <tsdgeos> no worrie
[07:32] <tsdgeos> s
[07:32] <Mirv> yeah there's no problem switching
[07:33] <Mirv> the media playback is more of a mystery, there's no clear error although jhodapp will hopefully continue looking at it today. and then there's the black launcher and black (background) rectangle in clock app
[07:33] <Mirv> but it's still possible a majority of the problems comes down to 2-3 fixable ~small problems, rebuilds of stuff using private headers etc
[07:38] <tsdgeos> Mirv: nice :)
[07:38] <tsdgeos> Cimi:can you have a quick look at https://code.launchpad.net/~aacid/unity8/noiconpreviewheader/+merge/219502 ?
[07:46] <tsdgeos> Mirv: don't we need a sudo in front of apt-add-repository ppa:canonical-qt5-edgers/qt5-beta2 in https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/
[07:48] <Cimi> tsdgeos, ok
[07:50] <tsdgeos> tx
[07:51] <Mirv> tsdgeos: true, for desktop, fixing
[07:51] <dednick> greyback: howdy. having some trouble with a unity-mir test. The application manager is starting a non-existing desktop file, and the test isn't ending.
[07:52] <greyback> dednick: the test is hanging, or fails?
[07:52] <greyback> dednick: this with trunk, or your own branch?
[07:52] <dednick> greyback: hanging. due to a forked process from the mock task manager i think.
[07:53] <dednick> greyback: it's the mir 0.2 change branch
[07:53] <greyback> dednick: lemme see
[07:54] <dednick> greyback: not sure which mir branch unity-mir/devel builds against
[07:55] <greyback> dednick: mir0.2 built anywhere? And which test is the failing one?
[07:55] <greyback> ..
[07:56] <dednick> greyback: hm. give me a minute. i'm going to try build unity-mir/devel
[07:56] <dednick> and see if the problem exists there as well.
[07:56] <greyback> dednick: there's no difference between unity-mir and devel right now
[07:56] <dednick> greyback: yeah, but there is with the mir0.2 change
[07:57] <greyback> dednick: unity-mir is the one the mir0.2 change will be merging in to anyway
[07:57] <greyback> ah I see what you mean.
[07:58] <dednick> greyback: so the problem doesn't seem to always manifest in the lp:~mir-team/unity-mir/mir-0.2.0-compatibility-changes.
[07:58] <dednick> but if i only run ApplicationManagerTests.SuspendingAndResumingARunningApplicationResultsInOomScoreAdjustment it does.
[07:59] <dednick> maybe need to kill children on ~MockApplicationController
[08:00] <dednick> not sure how core::posix::fork works
[08:00] <greyback> nor am I, but all it's doing is writing a value to a file in proc
[08:01] <dednick> greyback: just wondering if the process is cleaned up on destruction.
[08:01] <greyback> dednick: I hope so, but I've only basic grasp of gmock, so can't be sure
[08:02] <dednick> greyback: i meant the destruction of core::posix::ChildProcess
[08:03] <greyback> dednick: in that case: no idea
[08:03] <dednick> greyback: checking now
[08:04] <dednick> greyback: nope. doesnt look like it. And i guess that explains all the application_manager_test processes i have in ps list.
[08:06] <dednick> not sure why it's working in trunk/CI though
[08:06] <greyback> dednick: what isn't clear to me is that we mock the ProcessController::OomController completely, it should not be using processcpp at all
[08:07] <dednick> MockApplicationController::doStartApplicationWithAppIdAndArgs forks a process
[08:08] <greyback> oh so it does
[08:10] <mhr3> process-cpp has child observers
[08:11] <mhr3> which screw with signals, so it's likely to break qt's process handling
[08:11] <dednick> mhr3: yeah, i see that. we're not actually doing much with the children though
[08:12] <mhr3> well you still need to waitpid them
[08:12] <mhr3> although... if it's a test... meh
[08:12] <dednick> mhr3: you mean to ensure they've shut down?
[08:13] <dednick> mhr3: auto child = core::posix::fork([]() { while(true); return ... }
[08:13] <dednick> :)
[08:13] <mhr3> i guess you do kill them at some point
[08:13] <mhr3> and then they'll be zombies
[08:13] <dednick> mhr3: um. yeah, well... no
[08:13] <mhr3> ah... interesting test :P
[08:14] <greyback> I would guess once 'child' is deleted, the process is destroyed
[08:14] <mhr3> i don't think so
[08:16] <dednick> need to use Signalable::send_signal(sig_kill) ?
[08:17] <mhr3> marcustomlinson, do you know if process-cpp auto-kills a process when the instance goes out of scope?
[08:17] <dednick> greyback: nope. http://bazaar.launchpad.net/~phablet-team/process-cpp/trunk/view/head:/src/core/posix/child_process.cpp#L341
[08:17] <marcustomlinson> mhr3: looking
[08:17] <dednick> http://bazaar.launchpad.net/~phablet-team/process-cpp/trunk/view/head:/src/core/posix/process.cpp#L55
[08:17]  * greyback surprised
[08:17] <mhr3> yea, that's a definite no
[08:18] <mhr3> think it's cause send_signal can throw
[08:18] <mhr3> and destructors can't
[08:18] <greyback> http://bazaar.launchpad.net/~phablet-team/process-cpp/trunk/view/head:/src/core/posix/child_process.cpp#L301
[08:18] <greyback>  ~Private()               ::kill(original_child_pid, SIGKILL);
[08:19] <marcustomlinson> mhr3, greyback: yup, I saw that too^
[08:19] <marcustomlinson> mhr3: so ja, looks like it should
[08:22] <dednick> ah, didnt see that
[08:22] <mhr3> alright
[08:23] <mhr3> still not waitpid()ing in that case though
[08:24] <mhr3> but back to my original point, try not mixing qt and process-cpp, it will cause trouble
[08:24] <dednick> greyback: looks like the test is thowing an assert. destructor not called?
[08:25] <dednick> http://pastebin.ubuntu.com/7496455/
[08:26] <greyback> dednick: ah, you compiled in debug mode?
[08:26] <dednick> greyback: ah. yeah.. that's it
[08:26] <dednick> heh.
[08:26] <tsdgeos> Cimi: Saviq: can you reproduce in https://bugs.launchpad.net/unity8/+bug/1319907 that when the header is not there if you start changing to another scope it will come back?
[08:27] <greyback> dednick: assert on file not found bit overkill really... old code, needs refreshing
[08:27] <Saviq> tsdgeos, "it" will come back? the header or overlay?
[08:27] <tsdgeos> Saviq: well header and overlay are the same thing in this case :D
[08:27] <tsdgeos> so both :D
[08:28] <Saviq> tsdgeos, ah, thought page header
[08:28] <Saviq> tsdgeos, yes, it comes back
[08:30] <Cimi> tsdgeos, Saviq yes I have that
[08:30] <Cimi> tsdgeos, it started with your branch
[08:31] <tsdgeos> Cimi: i'm not asking if you have that
[08:31] <Cimi> hold on
[08:31] <tsdgeos> Saviq: that's pretty confusing :/
[08:32] <Saviq> tsdgeos, indeed, it feels like a frame isn't pushed to the screen?
[08:32] <tsdgeos> i'd say that
[08:32] <Cimi> tsdgeos, not pretty helpfuyl, but this revision started to have the issue for me http://bazaar.launchpad.net/~cimi/unity8/carousel-shadow/revision/884
[08:32] <tsdgeos> but it's one of those "almost impossible to prove" things
[08:33] <tsdgeos> Cimi: dude, do you realize i made you an specific question and you're answering lots of things which are not what i asked?
[09:09] <mhr3> uuuh
[09:09] <mhr3> scary
[09:09] <mhr3> QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
[09:09] <mhr3> kill the lib that causes that!
[09:09] <mhr3> with fire!
[09:09] <mhr3> or you know... fix it
[09:10]  * didrocks would love to see that mhr3 discovers it's on of his libs :p
[09:10] <mhr3> didrocks, i'm sure it isn't :P
[09:10] <mhr3> we don't do evil stuff
[09:10] <mhr3> not this kind of evil anyway :)
[09:13] <didrocks> :)
[09:14] <tsdgeos> mhr3: it's kind of unfixable
[09:14] <tsdgeos> mhr3: all kde stuff does this and the Qt dbus guy said "oh yeah, that, will fix it for Qt5"
[09:14] <tsdgeos> but maybe happens in Qt5 too?
[09:16] <mardy> greyback: hi! I just updated https://code.launchpad.net/~mardy/unity-mir/signonui-with-oxide/+merge/216845 to remove the test
[09:16] <greyback> mardy: thanks! Will give it a look now
[09:17] <greyback> mardy: yep, that's exactly what was needed, thank you
[09:19] <mhr3> tsdgeos, ehm, it means a lib is statically initializing something that uses DBus, doesn't sound that hard to fix to me
[09:20] <tsdgeos> mhr3: i'm just relaying second hand info, i may be wrong :)
[09:20] <mhr3> last time i checked, signon-qt was doing it
[09:20] <mhr3> but i suppose it's not the only one
[09:38] <Saviq> Mirv, did we not get a fix for the transitional packages re: multi-arch?
[09:38] <Saviq> Mirv, http://paste.ubuntu.com/7496672/
[09:42] <tsdgeos> mikenagle: is the departments supposed to be visible all the time or just when at the top of the view? i.e. if i scroll up do they hide or stay there?
[09:42] <Mirv> Saviq: we did, we did
[09:43] <Saviq> tsdgeos, it's meant to be part of the page header
[09:44] <Mirv> Saviq: that's armhf now for example https://launchpad.net/ubuntu/utopic/armhf/qtdeclarative5-qtquick2-plugin
[09:44] <Saviq> Mirv, is it M-A: foreign, too?
[09:48] <Mirv> Saviq: both the new package name and the transitional package are M-A: same
[09:49] <Saviq> Mirv, xnox said they should be foreign I think?
[09:49] <Saviq> Mirv, in any case... x-resolution of unity8 build deps still doesn't work because of something there :/
[09:50] <Mirv> Saviq: hmm, no, an amd64 compiled QML plugin cannot work on armhf
[09:50] <xnox> Saviq: transitional package, must match the target. in terms of Architecture & Multi-arch fields.
[09:50] <Mirv> right, that was done for the modules in qtdeclarative-opensource-src
[09:50] <Saviq> Mirv, sure, it's only a B-D for testing, and we're not running tests when x-compiling
[09:50] <xnox> Saviq: thus "empty" transitional packages for libraries are typically Architecture:any & Multi-Arch: same.
[09:51] <Saviq> Mirv, but we can't B-D on packages "only for testing" can we :|
[09:51] <Saviq> and well, it was working before the rename...
[09:51] <xnox> Saviq: sure, but that's a property of your use-case, package themself needs to declared things. And a compiled qt modules are Multi-arch:same.
[09:52] <Saviq> xnox, Mirv, false alarm
[09:52] <Saviq> mzanetti, it builds fine for me...
[09:52] <Saviq> mzanetti, ah that's scopes
[09:52] <mzanetti> Saviq: unity8 had the same for me
[09:52] <Saviq> mzanetti, builds fine here
[09:53] <Saviq> mzanetti, you sure your source chroots are apt-updated correctly (and/or you don't have apt-update disabled in the chroot?)
[09:53] <mzanetti> Saviq: ah no. its slightly another issue
[09:53] <mzanetti>  qtdeclarative5-ubuntu-ui-toolkit-plugin:armhf : Depends: libqt5qml-graphicaleffects:armhf but it is not installable or
[09:53] <mzanetti>                                                           libqt5graphicaleffects5:armhf but it is not installable
[09:53] <Saviq> mzanetti, that's an issue that should be resolved by now
[09:53] <Saviq> mzanetti, make sure to update your chroots
[09:54] <mzanetti> ack
[09:54] <Saviq> u8 builds fine here now, just trying scopes
[09:56] <Saviq> xnox, that's what I got for unity-scopes-shell, could you have a look please http://paste.ubuntu.com/7496738/ ?
[09:57] <Saviq> xnox, here's the relevant control for unity-scopes-api which fails to install http://bazaar.launchpad.net/~unity-team/unity-scopes-api/trunk/view/head:/debian/control
[09:58] <mzanetti> Saviq: I upgraded the chroot. still the same here
[09:59] <Saviq> mzanetti, can you paste the whole log from sbuild? there should be a file in wherever you pointed sbuild to put the logs in?
[09:59] <Saviq> mzanetti, $log_dir in ~/.sbuilrc
[09:59] <mzanetti> ack
[10:00] <xnox> Saviq: well figure out why.
[10:01] <Saviq> xnox, ah, the scopes problem is apparmor
[10:01] <xnox> Saviq: libunity-scopes1 conflicts with libunity-scopes0, do you have old one installed?
[10:01] <Saviq> xnox, libunity-scopes1:armhf : Depends: apparmor:armhf but it is not going to be installed
[10:01] <Saviq> xnox, no, clean chroot
[10:01] <Cimi> tsdgeos, what do I need to have scopes in unity8 desktop?
[10:01] <tsdgeos> anyone knows why the PageHeader has a Flickable  ?
[10:01] <Cimi> tsdgeos, I reviewed your code, I am trying to test it
[10:01] <xnox> Saviq: right, i do wonder if we should make apparmor foreign....
[10:01] <xnox> Saviq: also why is it dependencing on apparmor?
[10:01] <tsdgeos> Cimi: should work?
[10:01] <Cimi> tsdgeos, but I have no scopes in scopes scope
[10:02] <Cimi> in scope scopes I meant xD
[10:02] <xnox> Saviq: libraries should not depend on runtime packages.
[10:02] <Saviq> xnox, indeed, that looks weird
[10:02] <xnox> Saviq: and apparmor does not provide any shared libraries as far as i can tell.
[10:02] <xnox> Saviq: can you find out who is adding these apparmor dependencies and why?
[10:02] <Cimi> tsdgeos, to swipe left/right
[10:02] <tsdgeos> Cimi: the bug is not about scopes, it's about the music scope previews
[10:02] <Saviq> xnox, yup, will do
[10:02] <Cimi> tsdgeos, I am talking about your mascot MR
[10:03] <tsdgeos> Cimi: yes, bug is just in the music previews
[10:03] <tsdgeos> previews
[10:03] <tsdgeos> not scope
[10:03] <tsdgeos> but still
[10:03] <dednick> Saviq: dont suppose you know if we can get osk to appear on unity8 desktop launch?
[10:03] <Cimi> ah sorry
[10:03] <tsdgeos> Cimi: you should have scopes
[10:03] <tsdgeos> Cimi: so you only have the apps one?
[10:03] <mzanetti> Saviq: http://paste.ubuntu.com/7496753
[10:03] <Cimi> tsdgeos, I thought it was the padding in scopes
[10:03] <Cimi> tsdgeos, I have nothing
[10:03] <Saviq> xnox, possible we need to split libunity-scopes1
[10:04] <Cimi> I upgraded to utopic last night
[10:04] <Cimi> and now BAM
[10:04] <Saviq> xnox, since they rely on aa-exec to contain scope processes
[10:04] <Cimi> :D
[10:04] <Cimi> I guess I can blame Saviq
[10:04] <Cimi> I need to blame someone :D
[10:04] <tsdgeos> Cimi: so read the bug in https://code.launchpad.net/~aacid/unity8/noiconpreviewheader/+merge/219502 again, see how it says Preview Header ;)
[10:05] <tsdgeos> Cimi: now
[10:05] <tsdgeos> $ initctl list | grep scope
[10:05] <Cimi> smart-scopes-proxy start/running, process 22503
[10:05] <Cimi> scope-registry start/running, process 22545
[10:06] <Saviq> xnox, here's where the dep was introduced http://bazaar.launchpad.net/~unity-team/unity-scopes-api/devel/revision/303
[10:06] <tsdgeos> Cimi: can you define "nothing"? you have no tabs or you have tabs but scopes show no contents?
[10:07] <Cimi> no content
[10:07] <xnox> Saviq: reading.
[10:07] <Cimi> but I have packages to upgrade
[10:07] <Cimi> hold on
[10:07] <tsdgeos> Cimi: then don't say you have nothing ;)
[10:07] <Saviq> xnox, but libunity-scopes1 ships executables as well as libs, so that's probably what would need fixing - it should be split
[10:07] <Cimi> tsdgeos, still no content aFTER UPGRADE
[10:07] <Cimi> ops caps lock
[10:07] <tsdgeos> Cimi: merge the branch with unity8
[10:08]  * Cimi rebuilds
[10:08] <Cimi> ok :D
[10:09] <Cimi> I read you merged from the branch log and I thought was up to date
[10:09] <Cimi> my bad
[10:09] <Saviq> mzanetti, get into the chroot (schroot -r -c session:utopic-amd64-armhf-2317cbf4-ba50-43d1-900f-c7555f9a41c6 -u root)
[10:09] <xnox> Saviq: well the code does exec ("/usr/sbin/aa-exec")
[10:09] <xnox> Saviq: so the dep is legit.
[10:10] <xnox> Saviq: i'll check if we can fix it in apparmor.
[10:10] <Saviq> xnox, thanks
[10:11] <Cimi> tsdgeos, one, next, overlay bug
[10:11] <tsdgeos> Cimi: do, no, understand
[10:11] <tsdgeos> :D
[10:11] <tsdgeos> Cimi: can you add some verbs and stuff to that sentence?
[10:12] <Cimi> hah
[10:12] <Saviq> mzanetti, then apt-cache policy libqt5qml-graphicaleffects
[10:12] <Cimi> tsdgeos, I approved your branch
[10:12] <Cimi> tsdgeos, moving over the next one, the overlay bug
[10:12] <tsdgeos> Cimi: cool tx
[10:12] <Cimi> tsdgeos, I confirm it does not happen on the desktop
[10:13] <Saviq> Mirv, ah, how about qtgraphicaleffects? did that get fixed for multi-arch?
[10:13] <tsdgeos> Cimi: oki, tx
[10:13] <tsdgeos> Cimi: https://code.launchpad.net/~aacid/unity8/noiconsfakeunity/+merge/219478 should be a pretty easy one too
[10:13] <Saviq> dednick, just start maliit-server should be enough
[10:13] <Saviq> dednick, I don't think it checks for hw keyboard yet
[10:15] <Saviq> Mirv, looks like not
[10:15] <Saviq> mzanetti, yeah, I used a non-clean chroot
[10:15] <Saviq> mzanetti, that's why it worked for me
[10:15] <Mirv> Saviq: that one did not, it's a direct sync from Debian so no Ubuntu changes at the moment
[10:15] <Saviq> mzanetti, and qtgraphicaleffects isn't fixed for M-A
[10:16] <Saviq> Mirv, so yeah, that breaks X-building of unity8
[10:16] <Saviq> but we probably discussed this
[10:16] <Mirv> Saviq: Debian's going to drop the transitional packages, though, so I guess we need to diverge a bit anyhow. Debian didn't have a release with Qt 5 unlike we did.
[10:16] <Mirv> Saviq: I can fix that, hopefully that'd be enough
[10:16] <Saviq> Mirv, yeah, so we should fix the dep in UITK?
[10:16] <Saviq> Mirv, or that
[10:16] <Saviq> if you want to touch the package
[10:17] <Mirv> Saviq: oh, we could fix UITK instead? yes please let's fix UITK. I actually thought there was a branch for that already earlier
[10:18] <davmor2> Mirv: where you at?
[10:18] <Saviq> Mirv, I believe so, if we make qml-module-graphicaleffects the default dep in UITK
[10:18] <Mirv> Saviq: https://code.launchpad.net/~timo-jyrinki/ubuntu-ui-toolkit/allow_new_qml_package_names/+merge/218605
[10:18] <Saviq> Mirv, indeed ;)
[10:18] <Mirv> Saviq: can you approve it at least and let's maybe ping SDK Team about it?
[10:18] <Mirv> davmor2: 2 C
[10:19] <Saviq> Mirv, yeah, let me test it out
[10:19] <Saviq> mzanetti, ↑↑ grab packages from there
[10:20] <Saviq> mzanetti, https://wiki.ubuntu.com/SimpleSbuild#Local_packages
[10:20] <Saviq> mzanetti, and it should work
[10:20] <mzanetti> interesting.
[10:20] <mzanetti> this seems quite useful for other situations too
[10:22] <Cimi> mhr3, dednick office this afternoon or not?
[10:23] <Cimi> I am going
[10:23] <dednick> Cimi: nope.
[10:23] <mhr3> Cimi, not 100% sure yet :)
[10:23] <Saviq> mzanetti, it's very useful - build-your-own-silo-style ;)
[10:24] <dednick> too nice outside. going to sit in garden!
[10:24] <mhr3> i'm kinda knackered
[10:24] <mhr3> dednick's fault
[10:27] <Saviq> my eyes!
[10:27] <Saviq> mzanetti, I kicked a rebuild on jenkins, since distro packages are newer than those
[10:27] <Saviq> mzanetti, you'll have to wait for that
[10:27] <mzanetti> ack. just failed here
[10:27] <Saviq> mzanetti, in any case
[10:27] <mzanetti> Saviq: the wiki says "Drop packages (with .dsc)..."
[10:27] <Saviq> mzanetti, .dsc not necessary
[10:27] <mzanetti> Saviq: there is no .dsc in those jenkins created pacakges
[10:27] <mzanetti> ok
[10:27]  * Saviq fixes
[10:28] <Saviq> mzanetti, in any case
[10:28] <Saviq> mzanetti, all that you can solve by installing deps by hand
[10:28] <Saviq> mzanetti, and then making dpkg-buildpackage just ignore with -d
[10:29] <mzanetti> ok... will try
[10:31] <Cimi> tsdgeos, confirmed your comment
[10:32] <Cimi> tsdgeos, all we need to do now is to put a console.log when the overlay should appear
[10:32] <Cimi> tsdgeos, and see if it actually is a rendering issue
[10:32] <tsdgeos> Cimi: you mean an onVisibleChanged in the overlay?
[10:32] <tsdgeos> i did that
[10:32] <tsdgeos> it changes to true
[10:35] <Cimi> tsdgeos, yep
[10:35] <Cimi> tsdgeos, tried async false?
[10:36] <tsdgeos> Cimi: i did
[10:36] <tsdgeos> Cimi: but give it another try
[10:51] <Saviq> /food
[10:58] <Cimi> tsdgeos, so
[10:59] <tsdgeos> yes?
[10:59] <Cimi> tsdgeos, I tried having the loader always visible: true
[10:59] <Cimi> tsdgeos, the shader is shown, but not the overlay text
[10:59] <tsdgeos> Cimi: which loader?
[10:59] <tsdgeos> the overlay one?
[10:59] <Cimi> tsdgeos, yes
[10:59] <tsdgeos> the text is somewhere else
[10:59] <Cimi> tsdgeos, so is not a loader issue
[11:00] <Cimi> tsdgeos, shader or so
[11:00] <tsdgeos> Cimi: you can just set showHeader to true all the time (commenting the code in CardCarousel) and you'll see all get the header
[11:04] <tsdgeos> greyback: should i do that thing you did for the red rectangle on 5.3?
[11:05] <greyback> tsdgeos: yes please, would help identify if the GL calls are different, which might be the cause
[11:06] <tsdgeos> greyback: ok, doing
[11:07] <Cimi> tsdgeos, yeah, I removed the connection of the titlelabel with the loader
[11:07] <Cimi> tsdgeos, I think is a rendering issue
[11:19] <tsdgeos> pete-woods: i can still reproduce the hud going crazy :/
[11:19] <tsdgeos> pete-woods: i was thinking if it can be firefox+grooveshark maybe?
[11:20] <pete-woods> tsdgeos: I have a branch that
[11:20] <pete-woods> that's under SRU that should stop it
[11:20] <tsdgeos> a
[11:20] <tsdgeos> cool
[11:20] <pete-woods> crossing all fingers + toes
[11:38] <mzanetti> tsdgeos: hey, have been testing the use-unity-api branches
[11:38] <mzanetti> tsdgeos: seems to work but I think I get more of those: file:///home/phablet/shell/builddir/plugins/Dash/createCardComponent:40:51: Unable to assign [undefined] to QString
[11:38] <tsdgeos> mzanetti: hi
[11:38] <tsdgeos> mzanetti: that's already there on trunk
[11:38] <tsdgeos> there's a fix by Cimi
[11:38] <mzanetti> tsdgeos: ack
[11:38] <tsdgeos> mzanetti: https://code.launchpad.net/~cimi/unity8/carousel-shadow-fixes/+merge/220213
[11:40] <tsdgeos> greyback: Saviq: so the traces are defenitely different, not enough gl knowledge in my side to understand if that can be the problem
[11:41] <greyback> tsdgeos: can you share? I'm not much of an expert either, but I'd like a look
[11:41] <tsdgeos> greyback: Saviq attached it to the bug :D
[11:41] <tsdgeos> greyback: http://paste.ubuntu.com/7496983/
[11:44] <mhr3> xnox, can i use the click chroot with sbuild?
[11:44] <mhr3> xnox, i just tried sbuild -A -d click-ubuntu-sdk-14.10-armhf --host armhf unity-scopes-api_0.4.7-0ubuntu1.dsc
[11:44] <mhr3> and it failed :)
[11:45] <mzanetti> Saviq: should I commit a workaround for this? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1302761
[11:46] <mzanetti> Saviq: or should we increase priority and still hope for th SDK to fix it eventually?
[11:46] <xnox> mhr3: for some value of can =)
[11:47] <mhr3> xnox, got http://paste.ubuntu.com/7497060/
[11:47] <xnox> mhr3: well, Saviq above was working really hard to enable cross-compilation of that package.
[11:48] <xnox> mhr3: not sure if it was yet.
[11:48] <xnox> mhr3: try cross building $ pull-lp-source hello ?
[11:48] <xnox> to see if it works with the click chroot (it should)
[11:49] <mhr3> xnox, inside the chroot?
[11:49] <mhr3> i guess not
[11:50] <greyback> tsdgeos: might be handy to set QSG_INFO=1 and run the qml file again. It'll output some handy GL info
[11:50] <greyback> tsdgeos: no need for the apitrace bit
[11:50] <tsdgeos> Saviq: do you do it ↑↑↑ ?
[11:50] <mhr3> xnox, same error
[11:51] <xnox> mhr3: pull-lp-source on the host, to get dsc, and then use above you used to cross-build unity-scopes-api but instead cross-building hello*.dsc
[11:51] <mhr3> xnox, yea, that's what i did, same error
[11:52] <dednick> Saviq: indicators "not to reach bottom". wtf... haven't noticed that this happens for a year?
[11:52] <xnox> mhr3: hello does not build-depend on systemtap.... so it shouldn't be the same error, unless the chroot is broken.
[11:52] <mhr3> xnox, oh you meant hello literally, i just grabbed scopes-api :)
[11:54] <xnox> mhr3: yes, we have "GNU Hello world" package. Which is excellent test-case for cross-building =) we know it cross-builds et.al. thus it should validate if "cross-building random .dsc should work with click chroot".
[11:54] <xnox> mhr3: not everything cross-builds. and i don't think unity-scopes-api is cross-buildable yet, but i might be wrong.
[11:54] <xnox> mhr3: hence the hello test.
[11:55] <mhr3> xnox, hello_2.9-1_armhf.deb
[11:55] <mhr3> so it works it seems
[11:56] <xnox> yeah.
[11:56] <xnox> mhr3: talk to Saviq about enabling cross-building things. i think he was working on unity-scopes*
[11:57] <mhr3> since it's complaining about lttng, i think it's about that right now
[11:58] <mhr3> or well.. systemtap
[12:11] <Saviq> dednick, don't even start...
[12:13] <mhr3> Cimi, nope, not coming
[12:13] <Saviq> mzanetti, it's actually fixed in SDK, but not in 5.2
[12:13] <Cimi> mhr3, lazy!
[12:13] <Cimi> mhr3, see you sunday
[12:13] <Saviq> mzanetti, we'd need to backport the patch as linked in one of the comments, or say that this is going to be fixed with 5.3
[12:14] <mhr3> Cimi, lazy indeed :) will come there on friday
[12:14] <mzanetti> Saviq: mhm... well, for now I've built on the phone
[12:14] <mhr3> Cimi, ...maybe :)
[12:14] <Cimi> mhr3, I won't be here friday
[12:14] <Saviq> greyback, tsdgeos, yeah, let me
[12:15] <mhr3> Cimi, here == office, or london?
[12:15] <Cimi> mhr3, office
[12:16] <Cimi> I'm going this afternoon
[12:16] <Saviq> greyback, https://bugs.launchpad.net/unity8/+bug/1321189/comments/7
[12:17] <Saviq> mhr3, so what's your x-build issue?
[12:18] <mhr3> Saviq, pete-woods is getting the uninstallable apparmor
[12:18] <mhr3> Saviq, i'm getting uninstallable lltng-dev because systemtap-...-dev is not installable
[12:18] <greyback> Saviq: ok nothing obviously broken afaics. Best ask a Mir person for more help
[12:19] <Saviq> mhr3, pete-woods, yeah, xnox was to try fixing that in apparmor, by marking it M-A appropriately
[12:19] <pete-woods> python3:armhf : Depends: dh-python:armhf but it is not installable seems to be the underlying package
[12:19] <Saviq> pete-woods, that's because apparmor pulls in python armhf, while your own build deps pull in the amd64 version
[12:20] <pete-woods> I haven't asked for any amd64 debs from apt-get
[12:20] <Saviq> pete-woods, well, you're talking about cross-building are you not?
[12:20] <pete-woods> this is with just libunity-scopes-dev:armhf added to the "extra packages" list of click
[12:20] <pete-woods> this happens at the stage of creating the actual chroot
[12:21] <pete-woods> I am talking about cross-building, yes
[12:21] <Saviq> pete-woods, it's a cross-build chroot, most of the packages there will be amd64, other than libs
[12:21] <pete-woods> ahh
[12:21] <pete-woods> that's a very good point
[12:21]  * pete-woods didn't really employ his brain fully
[12:22] <Saviq> pete-woods, solution would be to install apparmor:amd64 instead, and that's what xnox is looking to make possible in apparmor's packaging
[12:22] <Saviq> pete-woods, another solution would be to not depend on apparmor from libunity-scopes1 if possible
[12:23] <Saviq> pete-woods, probably by splitting out the executables
[12:23] <pete-woods> and, indeed, any other python tool
[12:23] <mhr3> we actually should split the registry into a separate pkg
[12:23] <pete-woods> that isn't multi-arch aware
[12:23] <xnox> pete-woods: python is fine. it's multi-arched properly.
[12:23] <mhr3> although the scoperunner needs to be bound to the soversion
[12:25] <mhr3> then again registry is the one that needs apparmor binaries
[12:25] <pete-woods> yeo
[12:25] <Saviq> mhr3, yeah, but registry isn't required for building
[12:26] <Saviq> mhr3, so if registry was split out, it could depend on apparmor
[12:27] <Saviq> or well, if you only need aa-exec, and it's a python tool, that one could be split into a properly M-A package, and that's what you'd depend on, and not on the whole of apparmor
[12:28] <mhr3> i didn't realize aa-exec is a python tool
[12:28] <Saviq> dunno, thought that what pete-woods said
[12:28] <mhr3> would make more sense to use the lib directly
[12:29] <Saviq> lol
[12:29] <Saviq> it's actually a perl tool ;)
[12:29] <mhr3> oh god
[12:29] <mhr3> pete-woods, kill it! :)
[12:29] <Saviq> agreed, you should use libapparmor or whatever
[12:30] <Saviq> and aa-exec-click is bash
[12:30] <mhr3> oh but that needed touching process-cpp cause it doesn't do pre-fork hook
[12:30] <Saviq> but that's just a wrapper around aa-exec
[12:30] <pete-woods> mhr3: it's not that easy, we need a separate binary for it because process-cpp handles all the forking for us
[12:30] <pete-woods> so we could use libapparmor
[12:30] <mhr3> pete-woods, ^^^
[12:30] <pete-woods> but we'd need to make our own binary
[12:30] <pete-woods> ah yes
[12:30] <pete-woods> .me reads
[12:30] <mhr3> or... that hook
[12:31] <mhr3> or rather pre-exec hook
[12:40] <mhr3> Saviq, btw why doesn't gotoScope/openScope work in the -tool?
[12:41] <Saviq> mhr3, probably because we didn't move enough of the dash in there
[12:41] <mhr3> karni, so that's why ^
[12:42] <karni> roger
[12:42] <Saviq> karni, mhr3, we'll soon be moving dash to be a standalone app, the tool will then wrap that whole dash effectively
[12:43] <mhr3> not sure how i feel about that
[12:43] <Saviq> mhr3, about what?
[12:43] <mhr3> but surely you have reasons :)
[12:43] <mhr3> Saviq, making it an app
[12:43] <Saviq> mhr3, yes, dash is meant to *become* an app
[12:43] <Saviq> mhr3, be part of the spread etc.
[12:43] <Saviq> mhr3, only that you won't be able to stop it
[12:46] <Saviq> mhr3, it simplifies right-edge+side-stage+dash a lot
[12:46] <mhr3> ok
[12:46] <mhr3> what does it complicate though?
[12:46] <Saviq> actually it doesn't complicate much
[12:46] <mhr3> AppManager i guess
[12:46] <Saviq> mhr3, gone from dash
[12:47] <Saviq> mhr3, app management goes into spread (swipe app away to close)
[12:47] <Saviq> mhr3, so we're losing the "recent" in dash completely
[12:47] <Saviq> mhr3, so! we can get rid of quite some code
[12:47] <mhr3> i meant that AppManager will have to special case the dash app
[12:47] <Saviq> mhr3, like special categories and such
[12:47] <Saviq> ah yeah, that
[12:47] <Saviq> a bit
[12:47] <Saviq> but not a whole lot
[12:48] <Saviq> just needs to inject the dash in the running apps list
[12:48] <Saviq> and identify it for the shell to know which one it is
[12:48] <mhr3> alright, i'm not questioning that, just wanted to hear the rationale
[12:48] <Saviq> so that it doesn't close it and goes to it when pressing buttons etc.
[12:49] <Saviq> mhr3, https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AseY_FZZ1z7IdENvN1BiY3h0c05wTEZjbjZZSk9EQXc&usp=drive_web#gid=0 vs. https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AseY_FZZ1z7IdEJsVGJ2WXB1alREYV82WXZkV0lPT1E&usp=drive_web#gid=0
[12:49] <Saviq> mhr3, 27 vs. 72 permutations for right edge behaviour on the tablet
[12:50] <Saviq> and 5 vs. 10 on phone
[12:51] <mhr3> holy ....!
[12:51] <Saviq> inded
[12:51] <Saviq> e
[12:56] <Saviq> Cimi, what's the status of infographics, didn't you say you had them ready?
[13:12] <Cimi> Saviq, I have them yes, but there are no apps... writing tests
[13:13] <Saviq> Cimi, camera app is ported already
[13:13] <Cimi> Saviq, let me see if it works with my branch
[13:17] <tsdgeos> Saviq: the qmluitests are not being run ^_^
[13:17] <tsdgeos> Saviq: see https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-utopic/53/consoleFull "env: xvfb-run: No such file or directory"
[13:17] <tsdgeos> fginther: ping
[13:19] <fginther> tsdgeos, looking
[13:19] <tsdgeos> fginther: thanks :)
[13:23] <fginther> tsdgeos, this has been the case for some time, see - https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/1582/consoleText
[13:24] <tsdgeos> fginther: well it's wrong for some time then :D
[13:26] <fginther> tsdgeos, it appears the x bit was not set on the hook file. This has possibly never worked right :/
[13:27] <tsdgeos> fginther: which hook file?
[13:27] <fginther> tsdgeos, fixed that, let's see if it works now
[13:27] <fginther> tsdgeos, the job creates a pbuilder hook file to install xvfb during the pbuilder build
[13:27] <tsdgeos> ah
[13:27] <tsdgeos> so in the CI side?
[13:27] <fginther> tsdgeos, yes
[13:31] <Cimi> Saviq, now they are merged? landing 10 is empty
[13:38] <Cimi> mhr3, damn you
[13:38] <Cimi> mhr3, you hit me with laziness and I'll keep working from here
[13:38] <Cimi> xD
[13:38] <mhr3> lol
[13:38] <Cimi> might come friday then
[13:40] <Cimi> pete-woods, could you please remember me how to test infographics on desktop?
[13:40] <pete-woods> Cimi: sure, you'll need to setup a fake data source
[13:41] <Cimi> pete-woods, handy list of commands? :)
[13:41] <pete-woods> e.g. touch ~/.local/share/libusermetrics/sources/foo.json
[13:41] <Cimi> done
[13:42] <pete-woods> APP_ID=foo usermetricsinput banana "%1 bananas today" "no bananas today" "" 1.0 2.0 3.0 0.1 2.4
[13:42] <pete-woods> APP_ID=foo usermetricsinput apple "%1 appls today" "no apples today" "" 2.0 1.0 4.0 0.0 5.0 1.0 2.1
[13:42] <pete-woods> that will add two data sets to the fake "foo" data source
[13:45] <Cimi> pete-woods, is there a silo for it?
[13:45] <pete-woods> Cimi: er, should be, maybe it got flushed?
[13:45] <Cimi> yeah...
[13:45] <pete-woods> yeah, it got freed
[13:45] <Cimi> was 10
[13:45] <pete-woods> it's not hard to build, at least
[13:46] <Cimi> pete-woods, which branch?
[13:46] <pete-woods> Cimi: lp:~unity-team/libusermetrics/file-based-infographics
[13:46] <mterry> Saviq, hello!  So yesterday I was investigating your silo 002 findings.  I ran autopilot myself and they seemed fine.  And the "clicking through edge to hit greeter" bug is present in trunk.  I made the SIM unlock background be correct (but there is a gap between it and the edge of the screen I haven't figured out yet).  The new users is due to a dropped patch in AccountsService I'll follow up with Laney about.  I have had little success tracki
[13:46] <mterry> ng the cpu usage problem -- still working on that
[14:11] <Mirv> Saviq: re: black launcher, SDK team knows that various overriding of parameters has changed so that the overriding doesn't work, so that eg. sliders are black instead of orange etc. also, the launcher actually works (which I just heard, I hadn't realized), it's just black.
[14:13] <tsdgeos> Mirv: sure, we know it's a painting problem
[14:13] <tsdgeos> Mirv: but still the painting should work :)
[14:16] <Cimi> pete-woods-lunch, how do I debug now?
[14:20] <Mirv> alrighty
[14:41] <mterry> Saviq, I replied to your MP comments by the way.  Will investigate some of them, but I'm still trying to figure out the cpu issue as I mentioned
[15:03] <Cimi> pete-woods, how do I debug now? where are generated svg?
[15:03] <pete-woods> Cimi: I take it nothing is appearing in /var/lib/usermetrics/$UID ?
[15:04] <Saviq> mterry, can you come back for a sec?
[15:04] <Cimi> pete-woods, nope
[15:04] <pete-woods> Cimi: status usermetricsservice ?
[15:05] <Cimi> pete-woods, I started it now
[15:05] <pete-woods> Cimi: any luck?
[15:06] <Cimi> pete-woods, ok creates the file
[15:06] <Cimi> pete-woods, I am working on unity side now
[15:06] <pete-woods> :D
[15:07] <Cimi> pete-woods, did you add get methods?
[15:07] <Cimi> I tried with model.get(index).display but doesn't seem to work
[15:08] <pete-woods> Cimi: er, can you try just model.get(index)?
[15:09] <pete-woods> that method should just return a string
[15:10] <Cimi> pete-woods, empty
[15:10] <pete-woods> bah
[15:13] <Cimi> pete-woods, works as ListView
[15:13] <Cimi> pete-woods, so get doesn't seem to work
[15:13] <Cimi> or I have the wrong branch
[15:15] <pete-woods> Cimi: no you don't have the wrong branch, I obviously did something wrong
[15:15] <Cimi> ok
[15:15] <Cimi> hah :)
[15:15] <Saviq> dednick_, the bug is gone already btw ;)
[15:15] <Saviq> dednick_, the half-high indicators
[15:15] <dednick_> Saviq: yeah. just saw that
[15:19] <Saviq> tsdgeos, what were you saying about qmluitests btw?
[15:19] <tsdgeos> Saviq: tests are not run
[15:19] <tsdgeos> xvfb-run is not installe
[15:20] <tsdgeos> Saviq: see chat around 15:17:16 - 15:27:45
[15:20] <tsdgeos> fginther: is it now fixed?
[15:20] <Saviq> tsdgeos, so we had green runs without actual tests being run did we?...
[15:21] <tsdgeos> Saviq: yeah
[15:21] <Cimi> mzanetti, Saviq can you review http://bazaar.launchpad.net/~unity-team/libusermetrics/file-based-infographics/revision/169 and see what is wrong in this get method?
[15:21] <mzanetti> ack. I got it
[15:22] <mzanetti> eh. food is ready. Cimi, can it wait half an hour?
[15:22] <pete-woods> Cimi: okay, I've just tried it out with a simple QML test, and I have the old "works for me?
[15:22] <Cimi> mzanetti, food? which timezone are you? :D
[15:22] <pete-woods> source: dataModel.model.get(index);
[15:22] <pete-woods> does what I expect
[15:23] <mzanetti> I only eat once usually... and breakfast
[15:23] <mzanetti> so the time varies
[15:23] <Cimi> pete-woods, paste the whole file
[15:23] <Cimi> pls
[15:24] <pete-woods> Cimi: http://paste.ubuntu.com/7497803/ <— Greeter.qml
[15:24] <pete-woods> Cimi: http://paste.ubuntu.com/7497805/ <— Pager.qml
[15:24] <pete-woods> Cimi: QML2_IMPORT_PATH=/usr/lib/x86_64-linux-gnu/unity8/qml qmlscene Greeter.qml
[15:31] <pete-woods> Cimi: just so you know, the function returns an empty string if you give it an index that's out of range
[15:31] <fginther> tsdgeos, thanks for the reminder. I chmod'd the wrong file. Fixed it and trying again now
[15:33] <tsdgeos> tx :)
[15:35] <Cimi> pete-woods, your qml works for me
[15:35] <Saviq> early EOD, talk later/tomorrow folks o/
[15:35] <Cimi> pete-woods, I am trying to see what's wrong in mine then
[15:36] <pete-woods> Cimi: okay, cool, I'm interested to know what the problem is
[15:37] <Cimi> pete-woods, first of all, without the listview doesn't work
[15:38] <pete-woods> Cimi: well the model is loaded asynchronously, so perhaps when you're calling the get() method, the data isn't there yet
[15:38] <pete-woods> the ListView obviously handles all that for you by following the list model signals
[15:39] <Cimi> mmm
[15:39] <Cimi> how do I load the model then?
[15:39] <Cimi> this is a qml question
[15:39] <pete-woods> it starts loading as soon as you set the UID
[15:40] <pete-woods> and then dispatches standard QAbstractListModel type signals
[15:40] <pete-woods> I have no idea how you do the QML part outside of standard LiewView type stuff
[15:40] <pete-woods> my QML-fu is weak
[15:41] <mhr3> Saviq, great, so the :native thing doesn't work in recipes
[15:41] <mhr3> Saviq, https://launchpadlibrarian.net/176048730/buildlog.txt.gz
[15:50] <dandrader> greyback,  do you think supportedOrientations look like an application or a surface property?
[15:52] <dandrader> I would say surface, although I cannot think of an app that has multiple surfaces with differing support
[15:58] <mzanetti> Cimi: pete-woods: is that get method still a problem?
[15:59] <pete-woods> mzanetti: I would guess so, I'm not sure I can help Cimi out here
[16:05] <mzanetti> pete-woods: ack. I'll have a look... any easy way to reproduce?
[16:09] <pete-woods> mzanetti: I think you'd have to look at Cimi's code, I haven't seen it yet
[16:09] <pete-woods> mzanetti: the example I'm using piggybacks off a ListView still
[16:09] <mzanetti> ack
[16:10] <mhr3> dednick_, is it desired that the brightness indicator doesn't work when using auto-brightness?
[16:10] <dednick_> mhr3: :/
[16:10] <dednick_> mhr3: dunno. probably a question for design/indicator-team
[16:11] <mhr3> charles, ^?
[16:12] <Cimi> pete-woods, you're right with the loaded model
[16:15] <greyback> dandrader: I can't think of a good use-case for different surfaces of the same application supporting different orientations
[16:24] <Cimi> pete-woods, we were thinking of adding a count property to the model
[16:24] <Cimi> pete-woods, so I can listen to the count changed and call get
[16:25] <pete-woods> Cimi: that wouldn't be enough
[16:25] <Cimi> mzanetti, ^
[16:25] <pete-woods> you'd need to know when any individual entry updated
[16:25] <pete-woods> I guess I really don't quite understand why the usual QML model signals aren't enough
[16:26] <mzanetti> pete-woods: because you can't really access them in qml I think
[16:26] <mzanetti> pete-woods: they have that QModelIndex as params we can't work with
[16:26] <pete-woods> I thought QML was all about models
[16:27] <mzanetti> the ListView/Repeater/etc is a c++ implementation which connects to it
[16:27] <mzanetti> and makes magic happen in qml
[16:27] <pete-woods> fair enough
[16:27] <pete-woods> so what we do is reimplement all that in QML?
[16:27] <mzanetti> hmmm
[16:28] <mzanetti> Cimi: how do you know which index do you need?
[16:28] <Cimi> mzanetti, I don't now
[16:28] <Cimi> mzanetti, maybe looping?
[16:29] <mzanetti> Cimi: huh? but afaiu your code calls get() with some certain index on startup, no?
[16:29] <Cimi> mzanetti, yes, but I am starting with 0 :D
[16:30] <Cimi> mzanetti, then I will figure out if we want to store and start from a better one
[16:30] <mzanetti> so its always 0 at startup and then if you need another one you'll call it again later?
[16:30] <mzanetti> in that case I guess having a count property would be enough
[16:30] <mzanetti> so Cimi could just listen to countChanged, if(count > 0) get(0)
[16:30] <pete-woods> but how will you know when to re-call the function?
[16:31] <mzanetti> does this stuff change at runtime in the backend?
[16:31] <pete-woods> of course
[16:31] <mzanetti> ah ok
[16:31] <Cimi> onModelChanged works?
[16:31] <pete-woods> sure, it should do
[16:31] <mzanetti> dataChanged, yeah, but that has a QModelIndex again
[16:31]  * pete-woods feels the effort of minimising diffs to the model signals was wasted effort now
[16:32] <mzanetti> well, if its not used as a model, sort of, yes
[16:32] <mzanetti> pete-woods: could the get() return a QObject with a property for that string?
[16:33] <pete-woods> mzanetti: it could do, sure
[16:33] <mzanetti> so cimi would to a get(index).propertyName which in turn would update stuff when changing
[16:33] <pete-woods> mzanetti: well that's not quite the same thing
[16:33] <pete-woods> this is QStringListModel
[16:34] <pete-woods> it has QStrings in it
[16:34] <mzanetti> meh...
[16:34] <pete-woods> can I just be made to understand why we aren't able to use Repeater, et al?
[16:34] <pete-woods> what's so broken with it
[16:35] <mzanetti> because it would instantiate all the items, while cimi only needs one apparently
[16:35] <pete-woods> mzanetti: okay, but the user is going to tap through these things
[16:35] <mzanetti> I don't really know the code around it tho
[16:35] <Cimi> we only have one infographics on screen
[16:35] <Cimi> we don't need all of them
[16:35] <Cimi> pete-woods, we can use a crossfadeImage for that
[16:36] <pete-woods> this is basically a totally different API than I was asked for
[16:36] <mzanetti> Cimi: don't you have all those items in a repeater already? couldn't you just get it from there?
[16:36] <pete-woods> I could have made a thing with a QString next(); method
[16:37] <mzanetti> well, I really don't know enough of the whole thing around it to say which way to go
[16:37] <mzanetti> Cimi: where is this code? is it the inforgraphics code in unity8?
[16:38] <Cimi> mzanetti, I cannot see the point of using a repeater if we only display one image at once
[16:38] <Cimi> mzanetti, in a separate branch, but is the pastebin I gave you
[16:38] <Cimi> mzanetti, just using crossfadeImage with the path I obtain from the model
[16:39] <mzanetti> Cimi: and where will this be?
[16:39] <mzanetti> in the end
[16:39] <Cimi> mzanetti, GreeterContent.qml
[16:39]  * mzanetti reads some code
[16:40] <Cimi> mzanetti, my idea is to connect a CrossFadeImage with the model.get(index)
[16:40] <Cimi> (that prodives an url)
[16:41] <mzanetti> Cimi: sure... but we've seen thats troublesome. So I'm trying to find something else which gives you the same data without you having to use a Repeater
[16:41] <Cimi> mzanetti, I don't know anything apart from listview and repeater :(
[16:42] <mzanetti> Cimi: what I mean is, there is already a Repeater in the infographics. if we can connect to that one instead of connecting to the model directly it might help us
[16:42] <Cimi> mzanetti, there is no repeater anymore
[16:43] <mzanetti> oh...
[16:43] <mzanetti> so the whole inforgraphic changed?
[16:43] <Cimi> mzanetti, yes
[16:43] <Cimi> mzanetti, we obtain a list of SVGs
[16:43] <Cimi> mzanetti, so a list of images
[16:43] <mzanetti> pete-woods: that's probably why we try to use it different than before ^^
[16:43] <Cimi> mzanetti, we display one image
[16:43] <Cimi> mzanetti, and we want to crossfade between them
[16:44] <Cimi> mzanetti, I can only think of a crossfadeimage with the source of that svg file
[16:44] <pete-woods> Cimi: I can rework the API so that there's a simple "image" property
[16:44] <pete-woods> that changes whenever you call "next"
[16:44] <pete-woods> it sounds like that's what you *actually* need
[16:45] <pete-woods> as opposed to the listmodel I was asked for
[16:45] <mzanetti> pete-woods: I think the listmodel might not be that bad after all
[16:45] <mzanetti> but rather a QAbstractListModel holding QObject's instead of a QStringListModel
[16:46] <pete-woods> but is that really what you want?
[16:46] <pete-woods> this API would be really simple
[16:46] <mzanetti> not for this use case...
[16:46] <pete-woods> well unity8 is my only use case
[16:46] <mzanetti> but you know... the infographic might look different again next week
[16:46] <pete-woods> no joke
[16:46] <pete-woods> I have had to totally reimplement the service
[16:46] <pete-woods> to use generated SVGs now
[16:47] <pete-woods> anyway, I think I will change the API to be how Cimi needs it
[16:47] <mzanetti> so the model with QObjects would offer everything, even though not the easiest way for this representation
[16:47] <pete-woods> yeah, I want everything to be really easy
[16:47] <mzanetti> but yeah... I'm really to far off the whole topic to tell you where to go
[16:47] <pete-woods> it's easier for both me and Cimi
[16:47] <mzanetti> ack
[16:48] <pete-woods> if we need a listmodel I'll just add one back again, it's easy enough
[16:49] <mzanetti> probably yes.. given that overall its still a quite easy topic with not much interaction between ui and model
[16:49] <Cimi> pete-woods, let's talk tomorrow with Saviq
[16:49] <Cimi> but my current need is indeed just an image
[16:52] <pete-woods> sounds like a good plan
[17:06] <Wellark> hey, anyone around who knows about unity8 translation process?
[17:06] <Wellark> is the update-unity8-pot run manually?
[17:07] <Cimi> Wellark, yes
[17:07] <Cimi> Wellark, usually when we add translatable strings
[17:07] <Wellark> Cimi: so it's the responsibility of the developer who changes the source string to run "make po/pot_file"
[17:08] <Wellark> and include the changes .pot diff in his MR+
[17:08] <Wellark> then, how are the .po files updated?
[17:08] <Wellark> there is a LP bot that uploads them automatically to trunk periodically?
[17:10] <Cimi> Wellark, I don't know this part
[17:10] <Cimi> Wellark, but I know that if the developer adds strings, he should run the script
[17:13] <Wellark> Cimi: ok. thanks!
[17:55] <charles> mhr3, dednick_: actually the plan is for the brightness slider to disappear from the indicator
[17:55] <charles> so that's another way of resolving the inconsistency >:)
[18:13] <darklight_> ChrisTownsend, Is it you I talked about the shortcuts/hotcorners issue ?
[21:31] <Saviq> mhr3, ugh'
[21:38] <Saviq> mhr3, I wonder if this is because of trusty... mhr3 ultimately we could probably do apparmor:native | apparmor
[21:38] <Saviq> mhr3, I'll talk with xnox tomorrow
[21:39] <xnox> Saviq: please don't do stuff to apparmor.
[21:40] <xnox> Saviq: i've agreed with security team to mark apparmor foreign, then everything will need to simply build-depend or depend on "apparmor" and it will just work.
[21:40] <Saviq> xnox, oh ok, so we'll need to revert the :native then
[21:41] <xnox> Saviq: problem is that at the moment, M-a:same library that depends on apparmor tries to install apparmor:armhf, whereas some other native things depend on apparmor and thus try to install apparmor:amd64.....
[21:41] <Saviq> hmm but that won't be backported to trusty...
[21:41] <xnox> Saviq: and since apparmor does not declare any M-a co-installability it fails with a cryptic message.
[21:41] <xnox> Saviq: why not? we've backported a tonne load of multiarchification into precise, post precise release.
[21:42] <Saviq> xnox, I was told no packaging changes for SRUs ;)
[21:42] <Saviq> xnox, in that case we're good
[21:42] <Saviq> just need some wait time
[21:42] <xnox> Saviq: ....................... that is so not true. Read the StableReleaseUpdate policy with what is acceptable and what is not acceptable as an sru.
[21:43] <Saviq> xnox, thanks, maybe I misunderstood
[21:44] <xnox> Saviq: SRUs must be minimal and only to fix a given problem in the most minimalistic way.
[21:44] <xnox> Saviq: and there are srus that change significant things. Cosmetic/cleanup changes are not welcomed for example.