=== thomi|lunch is now known as thomi === slangase` is now known as slangasek === jono is now known as Guest90083 [06:09] Mirv: hey, how are you? [06:11] smspillaz: I am calling the new dev series 0.9.10 unless you want to change the theme... [06:16] didrocks: hello, fine, just "jetlagged" from the daylight saving time switch.. === tvoss|easter is now known as tvoss [06:18] Mirv: :) I started qtcreator this morning to follow http://developer.ubuntu.com/resources/app-developer-cookbook/mobile/currency-converter-phone-app/ [06:18] Mirv: rather jasoncwarner poked me about it :) [06:18] Mirv: I don't have "Qt Quick UI" in the new project dialog [06:18] only Qt Quick 1 UI [06:18] any idea what I'm mising? [06:19] missing* [06:22] didrocks: possibly some Quick 2 dependencies like qtdeclarative5-dev qtdeclarative5-qtquick2-plugin. only ubuntu-sdk depends on everything needed, so as not to pull everything for qtcreator installers who want mainly Qt 4 development [06:22] Mirv: I installed ubuntu-sdk though? [06:23] Mirv: both of those are installed for me [06:23] qtdeclarative5-dev qtdeclarative5-qtquick2-plugin [06:23] Mirv: any other idea? way to debug this :) [06:23] didrocks: ok if you have ubuntu-sdk, then it's not about packages. it might be about Qt Creator old configuration and/or concurrent installation of qt4-qmake - https://bugs.launchpad.net/ubuntu/+source/qtcreator/+bug/1135336 [06:23] Launchpad bug 1135336 in qtcreator (Ubuntu) "Qt Creator misconfigures itself if qt4-qmake is installed or if the whole ubuntu-sdk isn't installed before the first run" [Undecided,Confirmed] [06:24] so one needs to either configure Qt Creator to have it note the Qt5 if it didn't do that automatically, or reset the configuration [06:25] Mirv: ok, I have qt4-qmake installed, how can I reset my configuration? [06:25] didrocks: if you want to keep qt4-qmake installed, resetting does not help (Qt Creator will autoconfigure itself again to Qt4-only) but you need to configure Qt Creator manually [06:26] didrocks: to reset, see the "Automatically fixing Qt Creator settings by resetting configuration" in bug report [06:26] to keep qt4-qmake and add Qt5 configuration, see the manual route [06:27] Mirv: I don't really calls this rm automatic but well :-) [06:27] Mirv: indeed, I have it now, any ETA once you will get something to fix it? [06:27] didrocks: May I make "0.9.10" the active dev series for lp:compiz? [06:27] duflu: sounds good to me [06:28] didrocks: it's automatic in the sense of not going into configuration dialogs of Qt Creator. the problem seems complex, and upstream seems to lack proper reconfiguration of itself in case system changes. [06:29] Mirv: any way we can workaround it? [06:29] the Qt4 preference could be maybe fixed, though [06:29] didrocks: I don't have permission :( [06:30] duflu: sam should I guess? [06:30] Mirv: ok, so now I have the same issue than jason… [06:30] didrocks: I've one idea of trying to find how the upstream detects /usr/bin/qmake-qt4 and make it prefer whatever is symlinked at /usr/bin/qmake. it'd only affect first runs however. [06:30] Mirv: Starting /usr/lib/x86_64-linux-gnu/qt5/bin/qmlscene /home/didrocks/CurrencyConverter/CurrencyConverter.qml [06:30] didrocks: No it's pspmteam [06:30] QQmlComponent: Component is not ready [06:32] Mirv: so my error? Following the tutorial, it's exactly what Jason is getting as well. Any idea? [06:32] didrocks: I haven't heard about that problem, CurrencyConverter seems to continue starting for me [06:32] Mirv: we both have only distro and not the ppa [06:32] and I have only distro packages [06:33] mmrazik, didrocks, Mirv: Could one of you please change the "Development focus" to "0.9.10"? https://launchpad.net/compiz [06:33] duflu: ack [06:33] Mirv: seems there is a package missing then, if at least 2 persons can reproduce it, do you want a bug report? [06:33] duflu: done [06:34] mmrazik: Thanks [06:34] didrocks: yes, although I'm not sure against which project if it's now the new ubuntu-sdk that may be giving problems [06:34] Lots of people have permission, but I don't :) [06:34] didrocks: the new ubuntu-sdk meta package is also missing the ubuntu plugin, and I should contact loic about it [06:35] didrocks: if you come up with a package to file the bug against, please tell me so that I can also file bugs.. [06:35] Mirv: I can help debugging, but I think it's something you should track [06:36] ubuntu-touch-meta I think? [06:36] Mirv: just tell me what I should do to get more info for you [06:36] Mirv: as basically, on relatively fresh install, following the tutorial doesn't work [06:40] Mirv: https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1158246 [06:40] Launchpad bug 1158246 in Ubuntu UI Toolkit "Tutorial code needs to be updated to use the latest UITK version" [High,Confirmed] [06:44] I'm trying to ask some SDK people if they've an understanding of the problem. weird that I don't have even the warning showing up. [06:46] it seems at least clear that David would need to update the tutorial [06:46] didrocks: it's probable that there are no missing dependencies, though. I compared the new ubuntu-sdk to the old and it seems good enough. [06:49] Mirv: can we ensure in the future that the sdk team is working with David to update the tutorial when they change their API? [06:52] didrocks: yes, API changes are already something that needs to be carefully handled from now on. I'll mention this again to bzoltan. [06:53] Mirv: thanks [06:53] Mirv: you will tell dpm to make the update? [06:53] Mirv: also, we need more integration tests I guess [06:54] didrocks: pinging him as well [06:54] Mirv: thanks a lot, keep me posted on the qt4-qmake stuff :) [06:54] didrocks: ok [07:17] duflu: FYI: https://code.launchpad.net/~vanvugt/compiz/back-to-raring/+merge/156459/comments/342220 [07:19] didrocks: I kept the 0.9.9 branch as the target because all later branches need a common ancestor that can be found for merging [07:19] Would just adding to the changelog be enough? [07:20] duflu: yeah, so dch -i (keep UNRELEASED) [07:20] duflu: and add the marker line with the last common rev [07:24] didrocks: What is "the marker line" ? [07:25] duflu: "Automatic snapshot from revision xxx" [07:26] Oh comment [07:26] duflu: it's what you need to put in the new changelog [07:26] didrocks: Yep. And version still "daily" ? [07:30] duflu: yeah, don't care about the version, just let what dch -i has set [07:30] (check you do have UNRELEASED preferably) [07:31] Done [07:32] duflu: no [07:32] duflu: yo ureally need to write the Marker in changelog [07:32] so instead of: The last common revision was r3629 [07:33] you need to set * Automatic snapshot from revision 3629 [07:33] duflu: as the workflow is screwed anyway, we'll probably get some bugs listed twice in the changelog in the end, but oh well… [07:40] Cimi, come here, btw [07:40] Cimi, one good thing happened - we're building for raring, too ;) [07:40] Saviq, ok [07:41] so we won against CI in the phablet-mods-cherrypick at last :D [07:44] tsdgeos, Albert, did you manage to upgrade to raring with unity? [07:44] Cimi: sure === alan_g is now known as alan_g|afk [07:45] tsdgeos, do-release-upgrade -d? [07:45] hey tsdgeos [07:45] Cimi: i did a plain s/quantal/raring in my /etc/apt/ [07:45] Saviq: hi [07:46] tsdgeos, I heard the world will collide on that [07:46] maybe [07:46] it worked for me (TM) [07:46] tsdgeos, (I'm scared of out dozens of PPAs) [07:46] *s/out/our/g [07:47] Cimi: ah, well, i only have the autopilot one, the phablet-tools one and the phablet-desktop one [07:48] didrocks: Done. Maybe. I think.... [07:48] guys here will break unity [07:48] I will upgrade, uninstalling maybe unity and X [07:49] will be back asap! [07:50] duflu: good! [07:50] Argh, not enough whitespace [07:50] Do we care? [07:51] duflu: no, that's fine [07:51] you will maybe get a double [ Daniel…] [07:51] that's all [07:51] in the changelog automated generation [07:51] (you didn't need to add it btw) [07:51] just as I told: [07:51] dch -i [07:51] -> edit to add the marker line [07:51] was enough [07:51] no need to bump the changelog or anything ;) [07:52] It was confusing. Because you were asking me to create incorrect information (wrong date) [07:53] didrocks: should we have libindicate in head/indicators.cfg? And what about the daily release? (I'm just doing some cleanup of jobs that were not yet migrated to cupstream2distro-config) [07:54] mmrazik: libindicate is deprecated [07:54] mmrazik: so better to leave it die [07:54] duflu: ? [07:54] duflu: you don't care about the date [07:54] duflu: it's bumped when doing a daily release [07:54] didrocks: do you mind if I create a "deprecated" release then? [07:54] didrocks: I always care about accuracy. And I don't yet understand how/what is automated... [07:54] i.e. it would live in stacks/deprecated/indicators.cfg [07:54] If anything else needs fixing, let me know [07:55] duflu: well, if you were accurate, then /raring would become 0.9.9 as we shipped it as it [07:55] mmrazik: I don't really like it as there is no commit since 2012-09-07, what would that be used for? [07:56] mmrazik: I prefer we avoid too many "releases" view [07:56] didrocks: to generate the "new-style" autolanding jobs instead of maintaining the "old style" (aka non based on cupstream2distro-config) [07:56] mmrazik: don't autoland it anymore [07:56] didrocks: ok [07:56] mmrazik: if something is committed to it, it's an error, so better to detect it that way :) [07:56] ack [07:59] didrocks: regarding too many release views -- you probably won't like this then: https://code.launchpad.net/~mrazik/cupstream2distro-config/community/+merge/156479 [08:00] the issue is that we already accidentally deployed the jobs on the wrong jenkins [08:00] mmrazik: urgh, yeah, let's keep all that in head [08:00] didrocks: its in phablet/ right now [08:00] didrocks: in that case I'll just move it to a different branch TBH [08:00] mmrazik: we are going to remove phablet in the end [08:00] mmrazik: everything in head [08:00] once bootstrap [08:01] with stack names [08:01] mmrazik: so if it's only transitory, fine by me, we should just coordinate when moving one project after another [08:01] didrocks: its not really transitory. the config as such is most likely here to stay. But the autolanding/ci jobs are running on different jenkins [08:02] http://91.189.93.125:8080/ [08:02] so they are a bit different [08:02] mmrazik: will we be able to move them to a head/? [08:02] didrocks: we can add something to the yaml file so the deployment tool is a bit more intelligent and knows where to deploy [08:02] (stack will probably not be a one to one mapping as waiting for sergio on giving feedback here) [08:02] mmrazik: yeah, I think this will be needed [08:02] didrocks: ok. then let me reject that MP [08:03] thanks mmrazik :) [08:03] mmrazik: oh, btw, today I'm working with francis to just have one autopilot jenkins job [08:03] I've done the prepatory job on my side to pass everything in a parameter [08:03] didrocks: yup. I've seen the MP yesterday [08:04] didrocks: thanks for doing it. It was on my TODO but not too high :-/ [08:04] mmrazik: no worry, it's kind of needed for me now that we have release/ and head/ anyway ;) [08:04] so that we don't double the number of jobs === alan_g|afk is now known as alan_g [08:11] Saviq: do you specially want boiko's review in https://code.launchpad.net/~saviq/unity/phablet.rename-phone-icon/+merge/155944 ? Or can i just go ahead and approve it [08:11] ? [08:11] tsdgeos, go on [08:15] Saviq: so what's the plan in the lisview serach crash, are we reporting a Qt bug upstream? [08:15] tsdgeos, yeah, we need to dig in, unless we can find a simple way to reproduce [08:15] oka [08:16] would be best to fix, of course ;) [08:16] tsdgeos, do you remember if that crash was similar to what we had before the Carousel? [08:17] tsdgeos, IIRC it was [08:17] similar in nature yes, don't really remember the backtrace to be honest [08:28] do you guy know how to get "x86_64-linux-gnu"? i.e. the part that gets appended to /usr/lib/ when installing [some] libs? [08:29] get from a bash script that is [08:34] tsdgeos, https://code.launchpad.net/~saviq/unity/phablet.fix-hud-build/+merge/156486 [08:34] ah that :D [08:35] Saviq: i just approved https://code.launchpad.net/~dandrader/unity/phablet_hud_build/+merge/156402 you'll probably have to "rebase" into it [08:35] i think it's too late to stop autolanding [08:35] * tsdgeos checks [08:35] tvoss: did you see that? http://kentonv.github.com/capnproto/ [08:36] didrocks, nope, reading into it, thanks for pointint out [08:36] tsdgeos, let's supersede dandrader's [08:38] tsdgeos, I've stopped autolanding for it [08:38] oka [08:40] Saviq: fwiw this still won't make ./run work [08:40] tsdgeos, huh? [08:40] tsdgeos, does, here [08:40] need to find out how to make this better [08:40] Saviq: http://paste.ubuntu.com/5669827/ i need this [08:41] let me try again [08:41] actually let me try [08:41] Saviq: make sure you kill your uity_build stuff [08:41] hud is installing into "new paths" [08:41] tsdgeos, yeah, need to drop the prefix [08:41] so you may be using the old one [08:42] tsdgeos, some of it might be not needed post https://code.launchpad.net/~pete-woods/hud/cmake-cleanup/+merge/156488 [08:42] Saviq: you mean my lib-paths or some of your changes? [08:42] tsdgeos, mine [08:43] tsdgeos, yours shouldn't be needed [08:43] didrocks: Hmm, no autolanding since it's not lp:compiz any more? :) [08:43] Saviq: but i need them :D [08:43] tsdgeos, sure, but they should not be needed ;) [08:43] Saviq: why you say they shouldn't? [08:43] duflu: oh, right, as we changed the branch, we need to change the stack configuration file [08:43] tsdgeos, local install shouldn't install in multiarch [08:43] duflu: normally, you should coordinate that with mterry though, let me do it for this time… [08:44] tsdgeos, I _think_ [08:45] Saviq: the only thing the local_install thing does in hud does afaik is install some gconf files to the local dir instead of always trying to put them in /usr [08:45] don't see why local_install should disable multiarch [08:46] i mean you could still have two archs in your local path, no? [08:48] mmrazik: rev 135, (for the raring release) [08:48] duflu: ^ [08:49] didrocks: OK, thanks [08:51] tsdgeos, pushed a fix [08:51] tsdgeos, should be fine now [08:51] goodie :-) [08:52] didrocks, duflu: can the autolanding jobs wait for couple of hours (for fginther)? [08:52] didrocks: the unity stack is (I believe) not yet on cupstream2distro-config [08:52] but it looks like fginther already did some work there [08:52] mmrazik: fine with me [08:52] mmrazik: Yep [08:53] ok. I'll drop an e-mail to fginther so its not forgotten [08:53] duflu: the 0.9.9 branch is safe for raring, right? [08:53] duflu: we can land that without any fear [08:53] didrocks: After my proposal it is identical to lp:compiz/raring (plus changelog additions) [08:53] Not sure about before [08:54] duflu: hum, so you mean, we shouldn't use it for raring? [08:54] duflu: I understood you wanted us to use it [08:54] didrocks: Sorry, yes. Both are raring-friendly [08:54] and that you tested it [08:54] duflu: ah ok, so we are switching on that one [08:54] didrocks: I only diff'd it to make sure there's no diff [08:54] ok :) [08:54] thanks duflu [08:55] Trevinho: hey, did you fix the FTBFS due to the bamf tests vs new glib? [08:55] Trevinho: I don't see it in the vcs [08:56] Trevinho: also, I guess cyphermox asked you to add an entry to the vcs for rev 525 [08:57] tsdgeos, pushed another tweak to take https://code.launchpad.net/~pete-woods/hud/cmake-cleanup/+merge/156488 into account (will review that hud change, unless you want to take over?) [09:00] Saviq: i can take it and approve both at the same time if you want [09:00] tsdgeos, sure, works for me [09:00] oki [09:06] tsdgeos, pushed a change to rm -Rf $BUILD_DIR if --clean is passed to unity_buld [09:06] +i [09:07] ok [09:10] tsdgeos, aaand... two more commits (init CLEAN to false and add -c/--clean to ./build, too) [09:10] :D [09:11] tsdgeos, sorry :) [09:11] tsdgeos, that should be the last of it [09:12] Saviq: "initialize CLEAN to false in clean_unity" is a typo and you meant build_unity, no? [09:12] tsdgeos, yes [09:16] Saviq: do we really need two different bzr clean-tree calls? [09:16] tsdgeos, unfortunately, yes [09:16] weird [09:16] tsdgeos, let me verify [09:16] tsdgeos, yes [09:16] tsdgeos, --ignored deletes _only_ ignored [09:16] ah [09:16] i see [09:17] ah wahy [09:17] --unknown --ignored [09:17] tsdgeos, will fix [09:17] ok [09:19] mzanetti: you there? [09:20] tsdgeos, he's off until the 4th [09:20] oki [09:20] tsdgeos, fixed [09:50] Saviq: i'm approving https://code.launchpad.net/~saviq/unity/phablet.add-coding-import-path/+merge/155259 i guess kgunn forgot to top approve? [09:50] tsdgeos, or didn't feel powerful enough ;) [09:52] :D [09:52] ok [10:00] tsdgeos: Saviq ...you mean i can approve stuff ...watch out ;) [10:01] kgunn, jeez man, don't you sleep? [10:01] Saviq: like an old man...early :) [10:05] Saviq: where do i get Unity.Notifications for https://code.launchpad.net/~saviq/unity/phablet.notification-interface-tests/+merge/155914 ? [10:05] or is this just a "mockup" MR? [10:06] tsdgeos, isn't the description... descriptive... enough? [10:06] tsdgeos, generally we want to try this approach where we (shell UI) write tests like that [10:07] tsdgeos, that fail initially, that will drive the shell-facing Unity APIs [10:07] tsdgeos, i.e. a merge of Unity APIs for Notifications needs to make those tests pass [10:08] Saviq: who reads descriptions nowadays.... [10:08] :D [10:08] Saviq: then i think we should be running them [10:08] tsdgeos, ;) [10:08] but using the fail keyword [10:08] so that when they actually pass they fail and we have to turn the test on [10:09] not sure if that last sentence made any sense [10:09] it made inside my head [10:09] tsdgeos, kind of did [10:09] tsdgeos, we can do that under qmltestrunner? [10:10] i'm hoping [10:10] let me check [10:11] Saviq: yep [10:11] expectFail as in the QtTest C++ side [10:11] expectFailContinue is probably what we want [10:13] tsdgeos, yeah, but we can't even load that QML yet [10:13] ah right [10:13] tsdgeos, 'cause of missing imports [10:13] ok [10:14] let's just not forget to turn the tests on later :D [10:14] tsdgeos, yeah, part of the actual implementation MP :) [10:43] paulliu1, you around? === MacSlow is now known as MacSlow|lunch [11:38] Saviq: yeah. === paulliu1 is now known as paulliu === jhodapp|afk is now known as jhodapp === MacSlow|lunch is now known as MacSlow [12:12] fginther: hey, once you are around! :) === alan_g is now known as alan_g|lunch === ZarroBoogs is now known as Pici === _salem is now known as salem_ === alan_g|lunch is now known as alan_g [13:08] Is it possible to only select a sub-range of a model to be passed to a ListView/Repeater etc? === alan_g is now known as alan_g|reboot [13:22] hey davidcalle! [13:23] didrocks, hey :) [13:25] davidcalle: small question: what is blocking the publishing to the certified ppa is that we don't have one project for each scope [13:25] davidcalle: do you know when you will create them? [13:27] didrocks, hmm. I should have time for that between tonight and tomorrow (catching up on my other job backlog this week) [13:27] davidcalle: tracking list: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/view/head:/stacks/experimental/100scopes.cfg [13:27] davidcalle: thanks! [13:27] didrocks, np ;) [13:28] davidcalle: not sure if we can screenscrap with the 2 factors auth to batch the creation easily [13:29] didrocks, the client side list is still quite small, I'll do it manually. [13:29] davidcalle: ok ;) [13:32] dandrader, standup? [13:33] Saviq, ah yeah sorry! [13:33] dandrader, that's fine [13:34] Saviq, damn. resinstalled my machine yesterday (now on 13.04). I still have still mumble though :( [13:34] s/still/install [13:34] dandrader, sure, we're going, join when ready [13:42] fginther: still not around? ;) [13:43] didrocks, good afternoon. just finishing up something [13:44] fginther: ok, tell me once you are ready ;) (I'll be away for an hour in 15 minutes, would be nice to sync before) [13:44] didrocks, in that case, let's start [13:44] fginther: so, basically my changes worked with the daily release [13:44] so oif/indicators are passing the right parameters [13:45] good [13:45] fginther: I think merging both are quite easily, they should be exactly the same now [13:45] easy* [13:45] fginther: I guess, the question is unity and the 100scopes unity one [13:45] and how they can use the same job with indicator/oif [13:46] fginther: the 100scope is unity with another ppa instead, so already covered as we'll pass the ppa parameter [13:46] didrocks, the autopilot-release jobs are all created from the template with no manual changes, correct? [13:47] mmrazik: ^ [13:47] fginther: but the unity ones are different than the oif/indicators one [13:47] fginther: for me the unity one should have: [13:47] - a ppa parameter [13:47] - no package set (so empty parameter) [13:48] - the tests can be provided as "unity" for autopilot [13:48] so basically a "check with whole ppa" with ont test: unity, which is launchpad all autopilot unity tests? [13:48] didrocks: fginther: can you rephrase the question for me? I don't understand what is being asked [13:49] didrocks, yes 'unity' == all autopilot tests [13:52] fginther: so, how can I help you? We should maybe create a new generic autopilot job from scratch [13:52] for all cases [13:52] and plugging in the different cases? [13:53] didrocks, I think building up from the oif and indicators test shouldn't be too hard [13:53] * fginther starts to see the differences [13:54] fginther: ok, do you want to hang out, or having a first pass and we continues from there? [13:54] fginther: would be nice to do it today so that we can move on then [13:55] jibel: small question, the distribution of tests results per // is done by the -check job, right? nothing linked to autopilot jobs (if we are going to only use one for all releases/stacks, it's fine?) [13:55] didrocks, I think I can do a first pass, let me discuss some with marting [13:56] fginther: great! [13:58] didrocks, correct. Precisely it is done by cu2d-autopilot-report which is called in the last build step of -check jobs. [13:59] jibel: excellent, that's what I read, but I was double checking (I change a little bit the -check job yesterday) [13:59] jibel: thanks! [13:59] yw [14:03] Saviq, that was an easy fix... works now [14:03] MacSlow, cool :) === rsalveti_ is now known as rsalveti [14:12] dandrader, you wrote the Stage tests, can you please have a look at the test I've added in https://code.launchpad.net/~saviq/unity/phablet.apps-lens-real-installed/+merge/156571 [14:12] dandrader, I'm out of ideas why it fails [14:13] Saviq, sure. doing it now [14:16] build -s doesn't work in raring [14:16] I mean, immediately [14:16] probably requires extra deps [14:19] Cimi: what error do you get? [14:19] Is there a way to obtain the default value of an item-property, say Button.color in QML? [14:20] tsdgeos, I'm rerunning it now [14:20] MacSlow: you mean the original property before you changed it? as far as i know no [14:20] tsdgeos, yes [14:21] https://docs.google.com/a/mms-projects.net/spreadsheet/viewform?formkey=dHdFV2Fyd0xnRU52a2o0TWg1Z1VRZVE6MQ [14:21] tsdgeos, hm... then how can I conditionally assign a value instead? [14:24] MacSlow: unless the Button.color provides you a way to get the original color the only easy way i can think of is a Component.onCompleted JS to get the original color and store it yourself [14:24] and then just color: boolean ? myColor : originalColor [14:24] seems a bit lame to be honest :D [14:24] tsdgeos, ok... wanted to avoid that... but if that's the only way... so be it :) thx [14:24] tsdgeos, hud doesn't have autogen.sh [14:25] paulliu: ping [14:26] Saviq, the screenshot components are being replaced by tst_Stage.qml. That's why changes made to their real implementations won't affect the test [14:26] Saviq, see tst_Stage.qml lines 164 - 173 [14:26] dandrader, ah, /me faile [14:26] -e [14:27] dandrader, right [14:27] dandrader, thanks, makes perfect sense [14:27] gusch: hi [14:27] dandrader, I will talk to the internal Fake ones, then :) [14:27] paulliu: what is "X-Ubuntu-Touch=true" in the desktop file doing? [14:28] gusch: We will use that field to filter out the apps that is for phone only. [14:28] paulliu: ok - thx - approving [14:28] gusch: So the app lens on phone will only provide those apps with -true. [14:28] gusch: wait. [14:28] gusch: I'm adding debian/changelog. [14:28] gusch: for image. [14:28] paulliu: ah - ok [14:28] paulliu: but then there is one file you could remove [14:29] paulliu: debian/gallery-app.links [14:29] paulliu: as that adds links (was introduced for the renaming) [14:30] paulliu: but these links will cause the gallery to appear twice (as there are 2 .desktop files then) [14:30] paulliu: so please remove that old compatibility file as well [14:30] Saviq, and no need to use findChild to get the screenshots as they're properties [14:30]