| smspillaz | slangasek: you'll need to talk to the people from distro about it | 02:10 |
|---|---|---|
| === mmrazik is now known as mmrazik|afk | ||
| didrocks | hey duflu! | 06:08 |
| duflu | didrocks: Good morning | 06:10 |
| didrocks | duflu: FYI, the 0.9.9 wasn't that raring compatible, you missed 2 new features that were in and not in raring + a string break | 06:12 |
| didrocks | duflu: has to finish really late to convince the release team to get it in on Friday :/ | 06:12 |
| duflu | didrocks: Hmm. The diff said I had a clean copy of lp:compiz/raring :/ ... | 06:13 |
| duflu | OK, please point out what's missing and I can fix it | 06:13 |
| didrocks | duflu: well, it's in now, but from: https://lists.ubuntu.com/archives/raring-changes/2013-April/008744.html | 06:14 |
| didrocks | duflu: there are: | 06:14 |
| didrocks | * Showdesktop plugin: Wishlist/Feature-Request: Implement "Random" | 06:14 |
| didrocks | movement direction option (LP: #1161343) | 06:14 |
| ubot5 | Launchpad bug 1161343 in Compiz "Showdesktop plugin: Wishlist/Feature-Request: Implement "Random" movement direction option" [Undecided,Fix committed] https://launchpad.net/bugs/1161343 | 06:14 |
| didrocks | and * [needs-packaging] Wishlist: Missing plug-In: Freewins (Freely | 06:15 |
| didrocks | Transformable Windows) (LP: #1012194) | 06:15 |
| ubot5 | Launchpad bug 1012194 in compiz (Ubuntu) "[needs-packaging] Wishlist: Missing plug-In: Freewins (Freely Transformable Windows) -> not shipped in any .install file in raring" [Wishlist,Fix released] https://launchpad.net/bugs/1012194 | 06:15 |
| didrocks | (the second is a false listing I guess) | 06:15 |
| didrocks | duflu: also, there is in those merge Show desktop -> Show Desktop | 06:15 |
| didrocks | duflu: I think this is breaking translation, so should be reverted | 06:15 |
| duflu | didrocks: I'm confused. That stuff was never in lp:compiz/raring ... | 06:16 |
| didrocks | duflu: no, it was in 0.9.9 | 06:16 |
| didrocks | duflu: we landed /raring in raring | 06:16 |
| duflu | I didn't go missing. It just moved to lp:compiz/0.9.10 | 06:16 |
| didrocks | and you wanted us to land 0.9.9 | 06:16 |
| didrocks | so, the content of 0.9.9 needed to be raring compatible | 06:16 |
| didrocks | what I asked and you told me yes before I moved to that branch | 06:17 |
| slangasek | didrocks: hi, wrt bug #763148, how do you want this merge proposal for 0.9.9? Smash everything into a single cherry-pick commit? | 06:20 |
| ubot5 | bug 763148 in compiz (Ubuntu) "Adding/Removing an external monitor causes open windows to move to another workspace" [Medium,In progress] https://launchpad.net/bugs/763148 | 06:20 |
| didrocks | slangasek: hey, still awake? ;) yeah, a single commit is fine, you can just reference the other one in lp:compiz if you wish in the comment | 06:21 |
| slangasek | didrocks: ok, cool | 06:24 |
| mzanetti | Saviq: good morning | 07:36 |
| Saviq | mzanetti, hey | 07:36 |
| mzanetti | Saviq: https://code.launchpad.net/~mzanetti/unity/more-stats/+merge/157441 | 07:36 |
| mzanetti | :D | 07:36 |
| tsdgeos | mzanetti: why this | 07:48 |
| tsdgeos | ? | 07:48 |
| tsdgeos | -if(buildtype_lower MATCHES coverage) | 07:48 |
| tsdgeos | +IF(CMAKE_BUILD_TYPE MATCHES [cC][oO][vV][eE][rR][aA][gG][eE]) | 07:48 |
| Saviq | tsdgeos, 'cause we're lowering the build type? | 07:48 |
| tsdgeos | Saviq: read the +/. | 07:48 |
| tsdgeos | +/- | 07:48 |
| mzanetti | Saviq: that was working previously too | 07:48 |
| Saviq | tsdgeos, before it matched cOvErAgE, too | 07:49 |
| mzanetti | tsdgeos: because all other projects use it this way and our jenkins hooks use this string to identify if a project supports coverage | 07:49 |
| Saviq | tsdgeos, I can't see nothing wrong with that? | 07:49 |
| tsdgeos | it's making something more complex for no reason? | 07:49 |
| Saviq | tsdgeos, | 07:49 |
| Saviq | ug | 07:50 |
| mzanetti | tsdgeos: you think I should change the jenkins hook instead? that would be possible too. I opted for this for consitency with apps | 07:50 |
| Saviq | mzanetti, no | 07:50 |
| tsdgeos | what's wrong with "if(buildtype_lower MATCHES coverage)"? | 07:50 |
| Saviq | mzanetti, that will work ^ | 07:50 |
| * Saviq has eyes problems | 07:50 | |
| mzanetti | are you guys getting my messages? | 07:50 |
| Saviq | mzanetti, yes | 07:50 |
| tsdgeos | we are | 07:50 |
| mzanetti | :) | 07:50 |
| Saviq | mzanetti, we have the "buildtype_lower" var | 07:50 |
| Saviq | mzanetti, that's CMAKE_BUILD_TYPE.toLower() | 07:50 |
| mzanetti | Saviq: yeah... as I said... I either revert this change and change our jenkins hooks | 07:51 |
| Saviq | mzanetti, and the empty endif() is "new style" | 07:51 |
| === alan_g is now known as alan_g|afk | ||
| Saviq | mzanetti, why would you change it? | 07:51 |
| mzanetti | dude | 07:51 |
| Saviq | mzanetti, there's no need to change? | 07:51 |
| mzanetti | because all other projects use it this way and our jenkins hooks | 07:51 |
| tsdgeos | cOvErAgE is properly lowercased to coverage, no? | 07:51 |
| mzanetti | copy paste not working either | 07:51 |
| Saviq | mzanetti, or do you just mean for the sake of consistency? | 07:52 |
| mzanetti | yes | 07:52 |
| mzanetti | Saviq: ^ | 07:52 |
| mzanetti | Saviq: I can revert the change here and change the jenkins hooks | 07:52 |
| Saviq | mzanetti, then yeah, the "new way" is to lowercase it | 07:52 |
| Saviq | and match the exact string | 07:52 |
| mzanetti | ok | 07:52 |
| tsdgeos | sorry... :D | 07:54 |
| Saviq | mzanetti, tsdgeos, does make testIndicatorRow work for you? | 07:58 |
| * mzanetti checks | 07:58 | |
| tsdgeos | it did on friday | 07:58 |
| Saviq | tsdgeos, but it's using ChewieUI directly | 07:59 |
| tsdgeos | and it doesn't now | 07:59 |
| * tsdgeos scratches head | 07:59 | |
| mzanetti | no... doesn't work | 08:00 |
| mzanetti | note for myself: we need to enable the qmluitests in CI asap... | 08:01 |
| tsdgeos | yes we do :D | 08:02 |
| tsdgeos | Saviq: it's not using chewieui | 08:04 |
| Saviq | dednick, actually, wanted to ask here | 08:04 |
| Saviq | tsdgeos, yeah, I see | 08:04 |
| tsdgeos | it's using a fake one | 08:04 |
| tsdgeos | maybe the problem it's not finding it | 08:04 |
| tsdgeos | ? | 08:04 |
| Saviq | dednick, do the IndicatorRow tests work for you? | 08:04 |
| tsdgeos | ahh, i think i see the problem | 08:07 |
| tsdgeos | it has to do with the move of builddir != srcdir | 08:08 |
| Saviq | dednick, yes | 08:08 |
| Saviq | dednick, ^ | 08:08 |
| tsdgeos | yesser | 08:08 |
| tsdgeos | i'll propose a MR | 08:08 |
| Saviq | tsdgeos, cheers | 08:08 |
| Saviq | dednick, tsdgeos is on it | 08:09 |
| dednick | ok | 08:09 |
| === alan_g|afk is now known as alan_g | ||
| dednick | if you're testing using qmltestrunner, you need to include the test dir import path. But it should be working using make qmluitests. | 08:10 |
| tsdgeos | Saviq: dednick: https://code.launchpad.net/~aacid/unity/make_indicator_row_test_work_again/+merge/157600 | 08:13 |
| mzanetti | Saviq: tsdgeos: updated https://code.launchpad.net/~mzanetti/unity/more-stats/+merge/157441 | 08:13 |
| mzanetti | Saviq: tsdgeos: requires this now too: https://code.launchpad.net/~mzanetti/pbuilderjenkins/update-some-hook/+merge/157599 | 08:13 |
| Saviq | mzanetti, hmm, the grep won't match, will it? | 08:14 |
| dednick | tsdgeos: i think the hud may need the same? | 08:15 |
| tsdgeos | dednick: nope | 08:15 |
| mzanetti | Saviq: I changed buildtype_lower to cmake_build_type_lower to at least allow a little bit of consistency | 08:15 |
| tsdgeos | dednick: hud is actually compiling things | 08:15 |
| Saviq | mzanetti, yeah, I see | 08:15 |
| dednick | ah | 08:15 |
| Saviq | mzanetti, nice hack, btw :D | 08:15 |
| mzanetti | Saviq: for what? | 08:15 |
| Saviq | mzanetti, the hook | 08:15 |
| Saviq | mzanetti, the grep through CMakeLists.txt ;) | 08:16 |
| mzanetti | Saviq: that was here before my :) I think mmrazik created those initially | 08:16 |
| Saviq | mzanetti, is there autolanding for lp:pbuilderjenkins ? | 08:16 |
| Saviq | mzanetti, yeah, I'm not saying it's yours, don't you worry ;) | 08:17 |
| mzanetti | Saviq: autolanding yes. but I need to manually upgrade the package on all jenkins nodes | 08:17 |
| Saviq | mzanetti, but that's why we didn't understand the need to update the hook ;) | 08:17 |
| mzanetti | Saviq: hehe, yeah | 08:17 |
| dednick | Saviq, tsdgeos: ah, my cmake files were old. hadn't updated to use builddir. wihch is why it was working for me. All fixed. | 08:20 |
| dednick | does anyone know why when i load an item in the testrunner it's smaller thatn the size set? loading with qmlscene sets the correct size. | 08:25 |
| Saviq | dednick, did you set the size on the top level component? | 08:30 |
| dednick | Saviq: yes | 08:30 |
| Saviq | dednick, hum, not sure, qmltestrunner is just a QQuickView as any other... | 08:31 |
| dednick | Saviq: seems to happen with all the qmluitests | 08:35 |
| mzanetti | dednick: Saviq: yep... known bug | 08:35 |
| mzanetti | dednick: should be fixed in Qt 5.1 | 08:36 |
| mzanetti | dednick: shouldn't cause issues with tests though... | 08:36 |
| mzanetti | Saviq: there's no reason you didn't top-approve except the order of merging, right? | 08:37 |
| Saviq | mzanetti, I usually wait for Jenkins to do its thing | 08:37 |
| dednick | mzanetti: ok. thanks. | 08:37 |
| mzanetti | Saviq: ack | 08:37 |
| mzanetti | which is now... all fine... I'll top-approve | 08:38 |
| Saviq | mzanetti, beat me to it :P | 08:39 |
| mzanetti | Saviq: sorry... I forget that every time... may I ask you to approve this as mmrazik is ooo today? https://code.launchpad.net/~mzanetti/pbuilderjenkins/update-some-hook/+merge/157601 | 08:41 |
| Saviq | mzanetti, sure | 08:42 |
| tsdgeos | mzanetti: just wondering, what's missing for the qmluitests integration thingie? | 08:44 |
| mzanetti | tsdgeos: the MP with the coverage thingie from before | 08:44 |
| tsdgeos | so almost there? | 08:45 |
| mzanetti | tsdgeos: yep | 08:45 |
| tsdgeos | cool :) | 08:45 |
| Saviq | mzanetti, approved | 08:49 |
| mzanetti | cheers | 08:49 |
| tsdgeos | Cimi: ping | 08:51 |
| Cimi | tsdgeos, pong | 08:51 |
| tsdgeos | Cimi: if running tst_ResponsiveFlowView.qml with qmlscene can you open the comboboxes? | 08:51 |
| Cimi | tsdgeos, mmm not if Iremember | 08:52 |
| tsdgeos | may be that it used to work for the other test? | 08:52 |
| tsdgeos | i do remember playing with that manually | 08:53 |
| tsdgeos | was i dreaming | 08:53 |
| tsdgeos | ? | 08:53 |
| Cimi | tsdgeos, try responsivegridview | 08:53 |
| tsdgeos | doesn't work either | 08:53 |
| tsdgeos | maybe the ui toolkit changed?¿ | 08:54 |
| Cimi | tsdgeos, asksdkguys? | 08:55 |
| tsdgeos | sure | 08:55 |
| tsdgeos | what i am asking here is | 08:55 |
| tsdgeos | it should open, right? | 08:56 |
| tsdgeos | do you see any reason it should not? | 08:56 |
| * Cimi reads code | 08:56 | |
| tsdgeos | need to reboot, back in a sec | 09:01 |
| mzanetti | Saviq: hehe... that was too easy after all: https://code.launchpad.net/~mzanetti/unity/dont-halt-on-test-failure/+merge/157607 | 09:04 |
| Saviq | mzanetti, orly? | 09:07 |
| Saviq | mzanetti, `make check` doesn't need it | 09:07 |
| Saviq | mzanetti, it only runs make test | 09:07 |
| mzanetti | oh right... we changed that... lemme check | 09:08 |
| mzanetti | Saviq: updated | 09:10 |
| Saviq | mzanetti, you should update runtests for the move from in-tree builds to builddir | 09:15 |
| mzanetti | Saviq: where is builddir? | 09:15 |
| Saviq | mzanetti, "builddir" | 09:15 |
| Saviq | mzanetti, if you go ./build | 09:15 |
| Saviq | mzanetti, it will build in builddir now, out of tree | 09:16 |
| mzanetti | Saviq: runtests supports in-source and builddirs in the root | 09:16 |
| mzanetti | e.g. source-dir at .. | 09:16 |
| Saviq | mzanetti, ah, so ../runtests.sh, got it | 09:16 |
| mzanetti | Saviq: yeah... jenkins builds in a subdir too... so thats supported already | 09:17 |
| mzanetti | Saviq: the only thing not supported is build dirs totally outside the source... that would require passing a parameter for the src-dir I guess | 09:17 |
| Saviq | mzanetti, we could always just .cmake it | 09:18 |
| Saviq | mzanetti, but it's fine for now | 09:18 |
| === mmrazik is now known as mmrazik|afk | ||
| Cimi | tsdgeos, it's weird | 09:35 |
| Cimi | tsdgeos, I'm trying the one in the ubuntu-ui-toolkit demos | 09:35 |
| Cimi | tsdgeos, not sure how is it supposed to behave | 09:35 |
| tsdgeos | i pinged zsombi in #ubuntu-touch and got half an answer :-/ | 09:35 |
| tsdgeos | ASSERT failure in QList<T>::at: "index out of range", file /home/tsdgeos/qt5/build/qtbase/include/QtCore/../../../../qtbase/src/corelib/tools/qlist.h, line 452 | 09:36 |
| tsdgeos | wops :D | 09:36 |
| nic-doffay | Hey guys, still getting build errors with my branch, Jenkin's reports a success though. https://pastebin.canonical.com/88624/ | 09:42 |
| tsdgeos | nic-doffay: that's build -s ? | 09:43 |
| nic-doffay | It is tsdgeos | 09:43 |
| tsdgeos | nic-doffay: is it a clean build? | 09:44 |
| nic-doffay | It was tsdgeos | 09:45 |
| tsdgeos | nic-doffay: can you try build -s -c just to make sure? | 09:45 |
| nic-doffay | sure, I'll let you know when it's completed. | 09:45 |
| tsdgeos | nic-doffay: you have the version of build_unity that contains stuff like | 09:47 |
| tsdgeos | HUD_REV=365 | 09:47 |
| tsdgeos | right? | 09:47 |
| nic-doffay | I'm not sure tsdgeos | 09:47 |
| tsdgeos | nic-doffay: open the file and check the first lines of the file | 09:48 |
| nic-doffay | tsdgeos, that's the version I have. | 09:48 |
| tsdgeos | nic-doffay: you were on quantal? | 09:49 |
| nic-doffay | tsdgeos, correct | 09:49 |
| tsdgeos | maybe there's a linking issue in the hud code in quantal | 09:49 |
| nic-doffay | tsdgeos, why would it affect quantal but not raring? | 09:53 |
| tsdgeos | it might | 09:53 |
| tsdgeos | pulse libraries may have different libs linked in or whatnot | 09:53 |
| nic-doffay | Who should I talk to about this? | 09:55 |
| nic-doffay | tsdgeos, ^ | 09:56 |
| tsdgeos | nic-doffay: try pete-woods | 09:57 |
| tsdgeos | or tedg when he wakes up | 09:57 |
| nic-doffay | Thanks tsdgeos, will do. | 09:57 |
| tsdgeos | nic-doffay: otoh maybe you want to update to raring? | 09:57 |
| nic-doffay | How stable is it atm tsdgeos ? | 09:58 |
| tsdgeos | works fine here | 09:58 |
| nic-doffay | Cool, I'll just update then. | 09:58 |
| Cimi | on Tile.qml, there's a GridView.onRemove, what's that? | 10:24 |
| tsdgeos | Saviq: about the carousel-listview crash, at the moment i'm doing the evil eyes at dee-qt, can't prove is its fault (yet) but it's doing nasty stuff afaics | 10:27 |
| Cimi | tsdgeos, where is it crashing? | 10:28 |
| tsdgeos | Cimi: deep inside modelview code in Qt | 10:28 |
| Saviq | Cimi, http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-gridview.html#onRemove-signal | 10:28 |
| Cimi | Saviq, yes but why inside tile? | 10:29 |
| Cimi | Saviq, it is catched if tile has a gridview as direct parent? | 10:29 |
| Saviq | Cimi, not a direct one, any parent | 10:30 |
| Cimi | mmm | 10:30 |
| Saviq | Cimi, but indeed it should probably be in http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-gridview.html#remove-prop instead | 10:30 |
| Saviq | Cimi, Gerry should be able to comment on why he did put it in Tile | 10:31 |
| Cimi | Saviq, also, line 86 of that file, it changes the GridView.delayRemove property of AbstractButton? | 10:32 |
| Cimi | ok | 10:32 |
| Saviq | Cimi, GridView is an attached property of GridView delegates | 10:33 |
| Saviq | Cimi, so yeah, scratch my "any parent" comment | 10:33 |
| Cimi | Saviq, what will happen if I use Tile outside a gridview? | 10:33 |
| Saviq | Cimi, so changing GridView.delayRemove on root means it will change delayRemove on that | 10:33 |
| Saviq | Cimi, http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-gridview.html#delayRemove-prop | 10:33 |
| Cimi | just warnings I suppose | 10:34 |
| Saviq | Cimi, it will complain about missing GridView | 10:34 |
| Cimi | ok | 10:34 |
| Cimi | is that ok to accept? | 10:34 |
| Saviq | Cimi, the Tiles were only ever supposed to be GridView delegates | 10:34 |
| Saviq | Cimi, so sounds like yeah, it's fine | 10:35 |
| === alan_g is now known as alan_g|tea | ||
| Saviq | tsdgeos, about https://code.launchpad.net/~michihenning/unity/declspec/+merge/157578/comments/345009 | 10:42 |
| tsdgeos | yep? | 10:42 |
| Saviq | tsdgeos, we'll be moving/splitting the shell under "src/shell", "qml/shell" folders | 10:42 |
| Saviq | tsdgeos, and the rename I believe is to prevent naming confusion | 10:43 |
| tsdgeos | ah | 10:43 |
| tsdgeos | makes sense | 10:43 |
| Saviq | tsdgeos, so yeah, all source goes under src/ | 10:43 |
| Saviq | all (some? we'll have to see) QML+JS goes under qml/ | 10:43 |
| Saviq | public headers go under include/ | 10:44 |
| Saviq | etc. | 10:44 |
| tsdgeos | ok | 10:45 |
| === alan_g|tea is now known as alan_g | ||
| Saviq | MacSlow, ping | 10:48 |
| mzanetti | Il'l modify the jenkins ci job now.. please ping me if you encounter unexpected failures | 10:49 |
| Saviq | mzanetti, yay | 10:51 |
| MacSlow | Saviq, pong | 10:54 |
| === MacSlow is now known as MacSlow|lunch | ||
| tsdgeos | qt 5.1 alpha out | 11:15 |
| Cimi | tsdgeos, did we change something to the build system? | 11:30 |
| Cimi | tsdgeos, after doing build in root of unity phablet | 11:31 |
| Cimi | and I go to qmluitests, run make test or make testTile (working on Tile), it complains of no rule or target | 11:31 |
| tsdgeos | Cimi: yes, we changed some things | 11:31 |
| tsdgeos | Cimi: we have a builddir now | 11:31 |
| tsdgeos | cd builddir | 11:31 |
| tsdgeos | and make test there | 11:31 |
| Cimi | mm where? | 11:32 |
| Cimi | in builddir root? | 11:32 |
| Cimi | yep | 11:32 |
| Cimi | tsdgeos, how to run qmluitests? | 11:32 |
| tsdgeos | same way | 11:32 |
| tsdgeos | make qmluitests | 11:32 |
| tsdgeos | in the builddir | 11:32 |
| tsdgeos | mzanetti: wrong link https://code.launchpad.net/~unity-team/unity/phablet.test_responsiveflowview/+merge/157343/comments/345112 | 11:41 |
| tsdgeos | mzanetti: still contains s-jenkins on it | 11:42 |
| Cimi | question. I am in Tile.qml and I need to test the animation that happens when I remove a tile | 11:42 |
| Cimi | what I do is getting the item before removing the element (var ItemRemoved = gridView.itemAt(units.gu(4), units.gu(4)) | 11:42 |
| Cimi | then I do model.remove(0,1) (I can see the element removing with the animation) | 11:43 |
| Cimi | but the line after that is tryCompare(itemRemoved, "opacity", 0) which is undefined because the item was remvoed | 11:43 |
| Cimi | *removed | 11:43 |
| Cimi | what's the best way to deal with that? | 11:44 |
| mzanetti | tsdgeos: oops. my IRC client was detached... anyways, its fixed now | 11:54 |
| mzanetti | anyone a small test review? https://code.launchpad.net/~mzanetti/unity/phablet-tile-tests/+merge/157630 | 11:55 |
| Saviq | dandrader, you around? | 12:02 |
| Cimi | mzanetti, I was testing Tile as well, do you know how to test the gredview remove? | 12:08 |
| mzanetti | Cimi: in a meeting right now... | 12:08 |
| Cimi | ok | 12:08 |
| mzanetti | I'll ping you when done | 12:08 |
| sil2100 | didrocks: hi! I still see quite a lot of failures on the generic autopilot job, I'll be looking into those now | 12:18 |
| === MacSlow|lunch is now known as MacSlow | ||
| smspillaz | sil2100: are we parallelizing the compiz ci builds ? | 12:27 |
| sil2100 | smspillaz: now I have no idea ;/ Maybe fginther` would know | 12:31 |
| sil2100 | fginther`: ping, you around? | 12:31 |
| === alan_g is now known as alan_g|lunch | ||
| Walther | Note to developers: Unity doesn't seem to handle a portrait display too well - when changing desktops the "splash screen" that shows consists of landscaped screens, in Appearances / background screen the display is in landscape mode, etc | 12:47 |
| smspillaz | Walther: file a bug against compiz stating that the wall plugin doesn't handle the portrait case | 12:51 |
| smspillaz | (for the live previews) | 12:51 |
| === _salem is now known as salem_ | ||
| Walther | smspillaz: thanks for the specifics | 12:52 |
| didrocks | sil2100: excellent! thanks. I think it's the 100scopes jobs you are talking about | 12:55 |
| mzanetti | Cimi: hey | 13:03 |
| smspillaz | sil2100: hey, so just do double check | 13:07 |
| smspillaz | sil2100: if you do something like ctest -D ExperimentalMemCheck -R .Xorg. all those tests that are being marked as failed in valgrind in CI pass locally right ? | 13:08 |
| * cyphermox publishes indicators to raring | 13:08 | |
| didrocks | cyphermox: \o/ | 13:08 |
| sil2100 | smspillaz: let me double check that - but I was doing make test before with integration tests enabled and all was green | 13:10 |
| smspillaz | There is a condition I know about which might cause them to fail under valgrind | 13:10 |
| smspillaz | but I haven't seen it recently | 13:10 |
| mzanetti | cyphermox: hey... any news regarding the autopilot-qt tests? we would need to add some more tests but would like to get that one merged first | 13:11 |
| cyphermox | mzanetti: remind me what you mean by that? | 13:12 |
| mzanetti | cyphermox: https://code.launchpad.net/~mzanetti/autopilot-qt/add-tests/+merge/153695 | 13:12 |
| cyphermox | mzanetti: ok, just waiting for ubuntu-release to review | 13:14 |
| cyphermox | (approving the bug) | 13:14 |
| seb128 | cyphermox, thanks for publishing indicators! | 13:15 |
| cyphermox | np | 13:15 |
| mzanetti | Saviq: https://jenkins.qa.ubuntu.com/job/unity-phablet-ci/ | 13:18 |
| mzanetti | isn't it beautiful? | 13:18 |
| Saviq | mzanetti, I love our test count :D | 13:18 |
| Saviq | kgunn, ^ | 13:18 |
| mzanetti | only 250 to go until we overtake Mir :D | 13:19 |
| * smspillaz takes his 1414 tests and goes home | 13:19 | |
| smspillaz | #humblebrag | 13:19 |
| kgunn | mzanetti: Saviq ...that feels pretty good to see :) | 13:19 |
| sil2100 | smspillaz: I got one failure when running the tests with the command you specified, let me paste it to you on priv | 13:19 |
| davmor2 | Saviq: ah you have 666 then :) | 13:24 |
| Saviq | davmor2, no, not really ;) | 13:24 |
| davmor2 | Saviq: that or 1337 | 13:24 |
| Saviq | davmor2, we just went up from ~20 to ~160 in one go :D | 13:24 |
| fginther` | sil2100, smspillaz, compiz-ci should be built in parallel | 13:29 |
| sil2100 | fginther`: thanks! | 13:31 |
| davmor2 | Saviq: Ha nice :) | 13:35 |
| === alan_g|lunch is now known as alan_g | ||
| mzanetti | Saviq: I just came across all those small files like VideosFilterGrid, VideosCarousel | 13:49 |
| mzanetti | Saviq: they basically don't add functionality in respect to FilterGrid, Carousel etc | 13:49 |
| Saviq | mzanetti, yeah, they just use it | 13:49 |
| sil2100 | didrocks: so anyway, currently the generic autopilot job is for 100scopes, yes? Is it high-priority to get those fixed, or is it pushed back now that 100scopes didn't go in? | 13:49 |
| mzanetti | Saviq: however, if we're clever we _could_ run the FilterGrid tests ON them and see if it still works | 13:49 |
| Saviq | mzanetti, true | 13:49 |
| didrocks | sil2100: no, the generic autopilot job is… generic | 13:50 |
| didrocks | sil2100: so used for oif, indicators, unity, both raring and head, as well as 100scopes | 13:50 |
| sil2100 | didrocks: ah, so it varies between builds | 13:50 |
| didrocks | sil2100:right ;) | 13:50 |
| sil2100 | Good to know *notes it down* | 13:50 |
| didrocks | sil2100: you can look at the parameters | 13:50 |
| didrocks | sil2100: you have the job, release, ppa parameters specified | 13:50 |
| sil2100 | didrocks: since I saw that 100scopes was the latest, though the failures are more generic | 13:50 |
| sil2100 | i.e. the latest build was from 100scopes | 13:51 |
| didrocks | sil2100: yep, maybe we should remerge first unity against it | 13:51 |
| didrocks | dednick: do you have some time for that? unity trunk latest rev has good results… ^ | 13:51 |
| dednick | didrocks: sure. | 13:53 |
| didrocks | thanks :) | 13:53 |
| didrocks | sil2100: so, let's look tomorrow's result with those latest tests | 13:53 |
| === dandrader is now known as dandrader|afk | ||
| dednick | didrocks: r3283 ? | 13:55 |
| Cimi | mzanetti, do you know how to test the gridview remove for the tile? | 13:55 |
| Cimi | mzanetti, there is an animation | 13:56 |
| didrocks | dednick: exactly :) | 13:56 |
| mzanetti | Cimi: create a GridView and call model.add() and remove() on its model | 13:57 |
| tsdgeos | Saviq: do you have a second to confirm you can reproduce the crash on my simple test? | 13:57 |
| sil2100 | didrocks, dednick: some failures will go away since lp:unity had the dash-overlay-button fixes reverted | 13:57 |
| Saviq | tsdgeos, hit me | 13:57 |
| sil2100 | Which was causing some failures (the dash maximized bug) | 13:57 |
| didrocks | sil2100: yeah, that's my guess, so let's wait for tomorrow :) | 13:57 |
| mzanetti | Cimi: and use a tryCompare for the SequentialAnimation in there for finish | 13:57 |
| Cimi | mzanetti, yes I did that | 13:57 |
| Cimi | mzanetti, but it removes the item | 13:57 |
| didrocks | sil2100: but latest time we synced that with trunk, it was a release, not a random # | 13:57 |
| Cimi | mzanetti, so I don't have the item anymore | 13:58 |
| Cimi | mzanetti, to test the funcion | 13:58 |
| sil2100 | Ok ;) | 13:58 |
| sil2100 | Let's see where it will lead us then | 13:58 |
| tsdgeos | Saviq: https://chinstrap.canonical.com/~aacid/qml_model_crasher.tar.gz | 13:58 |
| mzanetti | Cimi: right... | 13:58 |
| Cimi | mzanetti, http://paste.ubuntu.com/5689471/ | 13:58 |
| seb128 | sil2100, hey, do you know why https://code.launchpad.net/~seb128/autopilot/correct-majhongg-name/+merge/157372 didn't get merged, didrocks approved it on friday | 13:58 |
| Cimi | mzanetti, line 6 fails | 13:58 |
| mzanetti | Cimi: you could make sure that the item does not get deleted immediately, but only after the time the animation takes | 13:58 |
| Cimi | mzanetti, what? | 13:59 |
| didrocks | seb128: I think fginther` didnt' redeploy head for qa with it? | 13:59 |
| Cimi | mzanetti, I believe fakeModel.remove takes the time for the animation also | 13:59 |
| Saviq | tsdgeos, yup | 13:59 |
| seb128 | didrocks, oh, ok | 13:59 |
| mzanetti | Cimi: remove() blocks? no... | 13:59 |
| * Cimi puts a console.log | 14:00 | |
| mzanetti | Cimi: anyways... not really sure how much sense it makes to test this... | 14:00 |
| Cimi | mzanetti, you're right | 14:00 |
| Cimi | mzanetti, ok | 14:00 |
| Cimi | I'll just approve yours then | 14:00 |
| tsdgeos | Saviq: so that's it, i can't find anything you could blame in that code, so it's a Qt bug, not that it matters much, still crashing :D | 14:00 |
| mzanetti | Cimi: sorry again for the collision... :/ | 14:00 |
| Cimi | mzanetti, no worries, I was losing time ttrying to test this :) | 14:01 |
| Cimi | mzanetti, you think we should add // for testing | 14:01 |
| Cimi | mzanetti, next to objectName = "" in the Tile.qml file? | 14:02 |
| mzanetti | Cimi: hmm... I think objectNames are in 99% of the cases used for testing | 14:02 |
| Cimi | ok | 14:02 |
| tsdgeos | Saviq: the trick is the double remove and using the listView.count as part of the delegate | 14:02 |
| mzanetti | Cimi: besides, if you remove it Jenkins will tell you that it was needed for testing | 14:02 |
| sil2100 | seb128: I know about it, I was poking fginther` about it just a few minutes ago | 14:03 |
| tsdgeos | Saviq: so what's the next step, want me to try finding a fix or just report the bug and walk away? | 14:03 |
| sil2100 | seb128: and he's on it right now | 14:03 |
| seb128 | sil2100, ok | 14:03 |
| seb128 | sil2100, shame that you dupped work there :-( | 14:03 |
| === fginther` is now known as fginther | ||
| sil2100 | seb128: that's just like a one liner ;p Still have that branch there, need to remove it | 14:03 |
| Saviq | tsdgeos, report, try and fix, please | 14:04 |
| tsdgeos | oka | 14:04 |
| Saviq | tsdgeos, you decide when you've had enough | 14:04 |
| tsdgeos | :D | 14:04 |
| mzanetti | Cimi: you had tests for DashBar, right? | 14:04 |
| Cimi | mzanetti, yes | 14:04 |
| sil2100 | seb128: so no problem ;) | 14:04 |
| Cimi | mzanetti, but we're waiting SDK | 14:05 |
| mzanetti | Cimi: ah ok... was just wondering why stats still say no tests for it | 14:05 |
| * fginther growns | 14:05 | |
| mzanetti | Cimi: do you have a link for the MP? | 14:05 |
| mzanetti | fginther: hey ho | 14:05 |
| * fginther and groan as well | 14:06 | |
| Cimi | mzanetti, https://code.launchpad.net/~unity-team/unity/phablet.dashBar_bottomswipe/+merge/150847 | 14:06 |
| fginther | didrocks, the "to_transition" bit is throwing off the auto-merger tools | 14:08 |
| * fginther starts work on a fix | 14:09 | |
| didrocks | fginther: coordinate with cyphermox for the QA stack | 14:09 |
| didrocks | I think it can be transitionned, but better to check | 14:09 |
| fginther | didrocks, ack | 14:09 |
| didrocks | at least for autopilot :) | 14:09 |
| cyphermox | yeah, just need to finish it up | 14:09 |
| fginther | didrocks, we really need to treat the 'to_transition' projects as regular projects, we want to keep auto-merge these even if they aren't being built for the daily release | 14:10 |
| === dandrader|afk is now known as dandrader | ||
| didrocks | fginther: no, because look at unity in raring for instance | 14:11 |
| didrocks | fginther: it's still treating lp:unity, not any branches | 14:11 |
| didrocks | fginther: and in the transition guideline, we only move stuff back when the 2 branches diverges | 14:11 |
| didrocks | so at the same time, change lp:unity/raring to raring for instance | 14:11 |
| didrocks | and reenable lp:unity in head | 14:11 |
| tsdgeos | Saviq: https://bugreports.qt-project.org/browse/QTBUG-30555 | 14:11 |
| Saviq | tsdgeos, cheers | 14:12 |
| fginther | didrocks, hmm. I see your point | 14:13 |
| didrocks | fginther: so, normally, all steps are done in sync ;) I guess it's a little funky until we really get to have this habit | 14:13 |
| didrocks | fginther: btw, I don't remember if I sent it to you: https://wiki.ubuntu.com/DailyRelease/MovingNewRelease | 14:13 |
| fginther | didrocks, thx | 14:14 |
| didrocks | yw ;) | 14:15 |
| dednick | didrocks: https://code.launchpad.net/~nick-dedekind/unity/smart-scopes.merge-trunk-3283/+merge/157665 | 14:20 |
| fginther | sil2100, seb128, we figured out why lp:autopilot is not auto-merging, just need to sync some transition items | 14:22 |
| cyphermox | fginther: do you have sufficient access to attach branches to series? | 14:22 |
| Cimi | dednick, are you writing tests for searchindicator of panel, right? | 14:22 |
| fginther | cyphermox, I can try | 14:23 |
| cyphermox | I'd finish fixing up the autopilot bits that aren't properly split to feature branches? | 14:23 |
| cyphermox | basically, there is -gtk, -qt, dbus-test-runner, gtester2xunit, pyruntest, xpathselect and window-mocker | 14:24 |
| dednick | Cimi: i'm trying to only write tests at a file level. so Indicators.qml in one test, Panel.qml in another. I havent got on to the panel yet, but i dont think it'll include the searchIndicator at this time. That would be another test case. | 14:24 |
| fginther | cyphermox, and they all need /raring branches? (or some equivalent)? | 14:24 |
| cyphermox | yeah those need raring branches. basically trunk.13.04 as per tradition | 14:25 |
| cyphermox | (I'm finishing up checking to make sure they don't already have them) | 14:25 |
| sil2100 | fginther: thanks! | 14:25 |
| sil2100 | :) | 14:25 |
| Cimi | dednick, I'll write it then | 14:26 |
| didrocks | cyphermox: better to check with QA upstream, because it seems there are using another way or versionning though | 14:26 |
| dednick | Cimi: be my guest :) | 14:26 |
| didrocks | as per what I'm seeing in autopilot | 14:26 |
| cyphermox | yeah | 14:26 |
| cyphermox | didrocks: I'd let fginther or mmrasik deal with the branching and series things though | 14:27 |
| cyphermox | I certainly don't have access for it | 14:27 |
| didrocks | cyphermox: just sync with them for deploying head once ready ;) | 14:27 |
| cyphermox | dbus-test-runner is the only one that is already split up, just needs that I update the config | 14:28 |
| cyphermox | didrocks: what do you mean? | 14:28 |
| didrocks | cyphermox: updating the config and deploying both raring/ and head stacks because they start pushing new features in their trunk :) | 14:28 |
| didrocks | cyphermox: hence, the "it needs coordination" | 14:29 |
| cyphermox | yeah yeah :) | 14:29 |
| didrocks | thanks cyphermox :) | 14:29 |
| cyphermox | fginther: are you going to create the branches, or should I speak with mmrasik before? | 14:30 |
| fginther | cyphermox, I'll work with thomi to get this sorted out, then notify you | 14:30 |
| cyphermox | ok! | 14:30 |
| fginther | cyphermox, didrocks, does a project need to be split (into a maintanence and trunk branch) if there are no new features being developed? | 14:32 |
| cyphermox | fginther: not really | 14:32 |
| cyphermox | but then perhaps make sure we're aware so we remove the project from head assuming it's not going to be in the next release | 14:32 |
| didrocks | fginther: it's upon upstream request, when they want to do develop new features and so, need to split the branches | 14:32 |
| Saviq | tsdgeos, reading more into your test code, it only happens with a QAbstractListModel? | 14:34 |
| fginther | cyphermox, didrocks, and if upstream does not split, we run the risk of accidentally pushing a feature change to the maintenance release, correct | 14:34 |
| === alan_g is now known as alan_g|tea | ||
| didrocks | fginther: right, but they got an email telling to not do that :) | 14:35 |
| didrocks | fginther: so if everyone is rigorous, that shouldn't happen | 14:35 |
| didrocks | (as we have a submitter and a reviewer) | 14:35 |
| cyphermox | fginther: we do, although that's why I also insist on reviewing all changes for raring :) | 14:35 |
| fginther | didrocks, right! | 14:35 |
| didrocks | also, cyphermox and other people from ~ubuntu-unity are watchdogs ;) | 14:35 |
| cyphermox | fginther: mzanetti can confirm we've blocked merges in the past :) | 14:36 |
| Saviq | tsdgeos, shouldn't using a ListModel { } expose the same crash? | 14:36 |
| cyphermox | didrocks: on that subject, do you have the power to review https://code.launchpad.net/~mzanetti/autopilot-qt/add-tests/+merge/153695 and the FFE for it? | 14:36 |
| tsdgeos | Saviq: not sure, maybe, haven't tried | 14:36 |
| Saviq | tsdgeos, would be good to get rid of the cpp code | 14:36 |
| didrocks | cyphermox: I'm not on the release team, but I would say that's not a FFe to add tests ;) | 14:37 |
| didrocks | ah, new package | 14:37 |
| cyphermox | didrocks: I disagree. it's a feature though one we should be happy to easily include :) | 14:37 |
| didrocks | cyphermox: maybe get someone from the release team for a quick ack? | 14:37 |
| mzanetti | Saviq: do you think I'm good enough to judge on the greeter stuff or do you want to join the hangout? | 14:37 |
| Saviq | mzanetti, what about it? | 14:38 |
| didrocks | cyphermox: so, once you add that, you will have the integration tests running for the QA stack, right? | 14:38 |
| cyphermox | didrocks: I think that's the plan yeah | 14:38 |
| mzanetti | Saviq: well, we have a meeting now on how to fully integrate with lightdm etc | 14:38 |
| Saviq | mzanetti, you're good | 14:38 |
| mzanetti | ok | 14:38 |
| tsdgeos | Saviq: let me try to kill the cpp code | 14:38 |
| didrocks | cyphermox: not sure what I should review, I think you should review the packaging and let in your capable hands. Tell me if you need help to setup the integration tests then ;) | 14:38 |
| tsdgeos | Saviq: but i doubt anyone can shift the blame to my 3 lines of cpp code | 14:39 |
| Saviq | tsdgeos, ;) | 14:39 |
| Saviq | mzanetti, just ping me if you need me | 14:39 |
| cyphermox | didrocks: the packaging looked fine although I'm unsure about the same for the package | 14:39 |
| mzanetti | Saviq: ack | 14:39 |
| didrocks | cyphermox: sorry, I don't get you, if the packaging looked fine, what about the package? | 14:40 |
| cyphermox | same == name :) | 14:40 |
| cyphermox | the naming for the new binary :) | 14:40 |
| cyphermox | did we ever agree on a naming scheme for the autopilot tests packages? | 14:41 |
| tsdgeos | Saviq: yep, the cpp code is not needed | 14:41 |
| didrocks | cyphermox: <binary-component-pkg-name>-autopilot | 14:41 |
| tsdgeos | i'll update the attachment | 14:41 |
| Saviq | tsdgeos, cool | 14:42 |
| Saviq | somewhat | 14:42 |
| cyphermox | didrocks: then we're good | 14:42 |
| cyphermox | I just wasn't sure we had reached an agreement | 14:42 |
| didrocks | cyphermox: awesome, maybe ping Laney for a quick release team review? | 14:42 |
| cyphermox | I just mentioned it in #ubuntu-release | 14:43 |
| didrocks | cyphermox: well, I think it's the easiest naming we can fine :) | 14:43 |
| didrocks | excellent! | 14:43 |
| cyphermox | I'll wait until release team decides and take the time to get some stuff planned for protocol stacks | 14:44 |
| didrocks | yep | 14:44 |
| tsdgeos | Saviq: http://paste.kde.org/~tsdgeos/718802/ the new one | 14:44 |
| Saviq | tsdgeos, yup | 14:44 |
| Saviq | tsdgeos, good work | 14:45 |
| tsdgeos | tell me that when i fix it :D | 14:45 |
| Saviq | tsdgeos, I will! | 14:45 |
| didrocks | bregma: FYI, fixing bug #1164915 made bug #1108956 to be reverted | 15:11 |
| ubot5 | bug 1164915 in Unity "dash doesn't close when pressing <super> on a specific lens" [Undecided,Fix committed] https://launchpad.net/bugs/1164915 | 15:11 |
| ubot5 | bug 1108956 in unity (Ubuntu) "The dash closes when trying to switch from Command lens to home lens" [Low,In progress] https://launchpad.net/bugs/1108956 | 15:11 |
| bregma | hardly surprising, given the intricacies of all the keypress handling | 15:11 |
| didrocks | yep ;) | 15:12 |
| Cimi | mzanetti, on the name property of Test elements, sometimes we use the suffix Test and sometimes not, shall we write a mail on the ML about always adding it? | 15:13 |
| Cimi | of TestCase elements | 15:14 |
| mzanetti | Cimi: yeah, feel free to do so. I haven | 15:14 |
| mzanetti | I haven't figured what exactly it changes... but I think it makes it easier to identify failures etc | 15:14 |
| didrocks | Trevinho: when you are going to get nux merged who broke the ABI, please ensure you follow https://wiki.ubuntu.com/DailyRelease/FAQ#My_package_B_depends_on_a_new_symbol_I_just_added_on_A | 15:15 |
| didrocks | hey mterry! | 15:15 |
| Trevinho | didrocks: ah | 15:15 |
| didrocks | mterry: do you think we can get a new Unity publication today? ;) | 15:15 |
| didrocks | Trevinho: basically, it's whenever you do an ABI break | 15:16 |
| mterry | didrocks, ah let me see | 15:16 |
| Trevinho | didrocks: fine, thanks | 15:16 |
| didrocks | Trevinho: in fact, it's rather in https://wiki.ubuntu.com/DailyRelease/FAQ#I_need_to_break_an_API.2BAC8-ABI :) | 15:16 |
| didrocks | Mirv: still around? | 15:18 |
| Trevinho | didrocks: so to make nux to trigger a rebuild of unity... what should be added? | 15:20 |
| didrocks | Trevinho: did you read about bumping the build-dep in unity against latest nux? | 15:20 |
| didrocks | Trevinho: and bump the version in debian/changelog of nux? | 15:20 |
| Trevinho | didrocks: mh, yeah.. I read... ok | 15:21 |
| mterry | didrocks, published | 15:21 |
| didrocks | mterry: \o/ | 15:21 |
| didrocks | thanks | 15:21 |
| Trevinho | didrocks: I should add it with debchange -i, irght? | 15:21 |
| Trevinho | I mean, as a new unreleased version | 15:22 |
| didrocks | Trevinho: no | 15:22 |
| didrocks | Also, please do think to bump the version in debian/changelog as well (this will be for next release). | 15:22 |
| didrocks | If there is already an UNRELEASED content, change it from | 15:22 |
| didrocks | '''0.42.1daily83.13.09-0ubuntu1''' (or '''0.42.1-0ubuntu1''') | 15:22 |
| didrocks | to: | 15:22 |
| didrocks | '''0.42.2-0ubuntu1''' for instance (you don't need to strip the daily part, if you do, the daily release will readd it at next successful release) | 15:22 |
| didrocks | from the FAQ | 15:22 |
| Cimi | mzanetti, sometimes we put TestCase/UnityTestCase before the components, sometimes after... guideline? | 15:22 |
| mzanetti | Cimi: I don't have a strong opinion on that... | 15:23 |
| Cimi | mzanetti, me neither, but let's decide or anarchy will reign :) | 15:23 |
| mzanetti | Cimi: well, usually one would put TestCase as the root item | 15:23 |
| mzanetti | Cimi: sometimes we need another Item to wrap it.. | 15:23 |
| mzanetti | Cimi: so for me the logical order would be TestCase first | 15:24 |
| Cimi | mzanetti, ok | 15:24 |
| Trevinho | didrocks: mh, yeah, but there's not an ureleased version in nux, that's why I asked | 15:24 |
| didrocks | Trevinho: I'm adding: | 15:25 |
| didrocks | Or run '''$ dch -i''' and change the version to match this (ensure you have UNRELEASED content and not "raring" or any version in the first line). | 15:25 |
| didrocks | does it make sense? | 15:25 |
| kgunn | nic-doffay: hey...wrt defining what app info you need for infographics | 15:25 |
| Trevinho | didrocks: yes | 15:25 |
| kgunn | nic-doffay: i would recommend following a model like notifications used | 15:25 |
| kgunn | https://code.launchpad.net/~saviq/unity/phablet.notification-interface-tests | 15:25 |
| kgunn | nic-doffay: ^ basically use a test to define/negotiate your api | 15:26 |
| Trevinho | didrocks: also, if there are multiple abi changes, I don't want to change version to 4.0.1 -> 4.0.2 ... WHat about 4.0.0.1 -> 4.0.0.2 instead? | 15:26 |
| didrocks | Trevinho: why not 4.0.1? | 15:26 |
| didrocks | Trevinho: you know, normally breaking ABI would even force bumping the soname :) | 15:27 |
| Trevinho | didrocks: If I've two branches changing the ABI in the same minor release | 15:27 |
| didrocks | Trevinho: if you land them in the same day, bumping once is enough | 15:27 |
| Trevinho | didrocks: ok | 15:27 |
| didrocks | Trevinho: as just one branch for unity is enough | 15:27 |
| didrocks | Trevinho: basically, everything needs to land in the same day, before next daily | 15:27 |
| didrocks | Trevinho: FYI: https://wiki.ubuntu.com/DailyRelease/FAQ?action=diff&rev2=17&rev1=16 | 15:28 |
| Trevinho | didrocks: yeah, that was my guess... But I was thinking to edge cases | 15:28 |
| didrocks | I would prefer we avoid version of 4kms long :) | 15:28 |
| Trevinho | didrocks: nice | 15:28 |
| Saviq | kgunn, nic-doffay, we need a chat with pete-woods before then to agree on an overall architecture | 15:30 |
| kgunn | yep...just asked Pete to join | 15:30 |
| kgunn | thostr_: pete-woods just to get on the same page | 15:31 |
| kgunn | I was proposing nic-doffay use Saviq's model for capturing frontend/backend interface | 15:31 |
| kgunn | like so https://code.launchpad.net/~saviq/unity/phablet.notification-interface-tests | 15:32 |
| === alan_g|tea is now known as alan_g | ||
| kgunn | pete-woods: nic-doffay of course not done in a vacuum...whatever you 2 can negotiate up first, as Saviq said, agree on some basic overall arch | 15:33 |
| thostr_ | kgunn: yes, we can use that, but after iteration 0 as discussed on Friday | 15:33 |
| kgunn | thostr_: sure | 15:33 |
| kgunn | iteration0 = quick and dirty | 15:33 |
| kgunn | integration to learn some things...only to turn around and capture in the test | 15:34 |
| thostr_ | kgunn: yes. but if guys have a good unterstanding I wouldn't be opposed to start with iteration 1 | 15:34 |
| thostr_ | kgunn: I think we are in learning phase... I'm open let's see which approach works better in the end (having iteration 0 vs not) | 15:34 |
| thostr_ | kgunn: as we learned: most important part there is anyway people actually talking to each other | 15:35 |
| Saviq | thostr_, kgunn it also depends on the scope (pun intended) of the api | 15:35 |
| kgunn | thostr_: i think nic-doffay did at least have a set of data he needs from apps... | 15:35 |
| thostr_ | Saviq: true | 15:36 |
| Saviq | thostr_, kgunn, infographics should be very thin, it's a list of values, a label and a button after all | 15:36 |
| nic-doffay | kgunn, yeah I've just seen a list of wanted data. | 15:36 |
| nic-doffay | Who shall I share the doc to? | 15:36 |
| kgunn | nic-doffay: pete-woods | 15:36 |
| pete-woods | nic-doffay: I'm obviously interested | 15:36 |
| Saviq | nic-doffay, /me, too | 15:37 |
| nic-doffay | Ok great, I'll share that over now. | 15:37 |
| pete-woods | basically what I'm expecting to create is a service with two APIs | 15:39 |
| pete-woods | one for the infrographic to interrogate | 15:39 |
| kgunn | nic-doffay: can you add what i presume is a link to this doc ? | 15:39 |
| pete-woods | and another for apps to register what they have to say | 15:39 |
| kgunn | https://docs.google.com/a/canonical.com/document/d/1gjKLIKfInaJ0kho6HWWI7oTHfkFCnmxcItQqXyRVyKI/edit | 15:39 |
| kgunn | nic-doffay: ^ | 15:40 |
| nic-doffay | Sure kgunn | 15:40 |
| kgunn | ta | 15:40 |
| Cimi | mzanetti, /Panel/IndicatorItem.qml [EASY] | 15:44 |
| Cimi | test position of label / icon | 15:44 |
| Cimi | mzanetti, reading the coordinates? | 15:44 |
| Cimi | reference? | 15:44 |
| nic-doffay | kgunn, it's there already | 15:45 |
| nic-doffay | right at the bottom. | 15:45 |
| nic-doffay | Under the greeter tab. | 15:45 |
| nic-doffay | (In that doc you linked) | 15:45 |
| kgunn | nic-doffay: yep...saw it...just didn't know if it was a dup | 15:45 |
| nic-doffay | pete-woods, Saviq https://docs.google.com/a/canonical.com/document/d/1VajNkWbBH61iVixXJAmOvNGiG__GWQTMXGNOZijXWJw/edit#heading=h.dxyj97l61sl7 | 15:46 |
| Saviq | pete-woods, I love that high-level architecture! :D | 15:46 |
| nic-doffay | pete-woods, page 20 is what data the designers want to access for the infographics. | 15:46 |
| nic-doffay | Which will influence the display. | 15:46 |
| Saviq | nic-doffay, I think one interesting question is: who decides on the colour of the infographic? | 15:47 |
| pete-woods | yes, I was thinking about this too, do apps get to say what color their notifications are? | 15:47 |
| Saviq | pete-woods, s/notifications/infographics/ | 15:48 |
| Saviq | pete-woods, to avoid confusion | 15:48 |
| pete-woods | correct! | 15:48 |
| sil2100 | seb128: fginther merged in that mahjongg-rename branch | 15:48 |
| seb128 | sil2100, fginther: thanks | 15:49 |
| nic-doffay | I guess we should start by adding the infographics where ever they need to be in the code, then take things from there. | 15:51 |
| nic-doffay | Saviq, could you direct me with this? | 15:51 |
| Saviq | nic-doffay, on the contrary, you should start creating the component with some mock data behind it as a component | 15:52 |
| pete-woods | definitely this was round | 15:52 |
| Saviq | nic-doffay, and build tests for it | 15:53 |
| Cimi | if someone approves this, I don't have to make newer branch depending :) https://code.launchpad.net/~unity-team/unity/phablet.test_Panel-searchIndicator/+merge/157679 | 15:53 |
| pete-woods | nic-doffay: I would hope to work with you to get an API that gives you what you need right from the start | 15:53 |
| nic-doffay | Saviq, ok great. | 15:53 |
| pete-woods | even if it gives nonsense data | 15:53 |
| Cimi | Saviq, I put the first test for SearchIndicator under a Panel subdirectory | 15:53 |
| Saviq | Cimi, k | 15:53 |
| nic-doffay | Agreed pete-woods the sooner that we have that, the better even if it's nonsense. | 15:53 |
| Cimi | Saviq, if you want, I can move all components tests under a Components dir | 15:54 |
| Saviq | Cimi, separate MP, but yeah, you can prepare one that moves the tests in the correct paths | 15:54 |
| Cimi | Saviq, obviously a separate one | 15:54 |
| Cimi | doing now | 15:55 |
| Saviq | pete-woods, can you set up a quick (half hour should be enough) hangout tomorrow morning? | 15:55 |
| Saviq | pete-woods, so that we look at it from a birds-eye view and think what's needed? | 15:55 |
| pete-woods | Saviq: who do you want in the hangout? you me and nic-doffay? | 15:55 |
| pete-woods | or more? | 15:55 |
| Saviq | pete-woods, yup, should be enough | 15:55 |
| pete-woods | okay! | 15:56 |
| Saviq | pete-woods, I'll then sit with nic-doffay and prepare the tests for the API | 15:56 |
| mzanetti | Cimi: the question still valid? | 15:56 |
| Cimi | mzanetti, yes | 15:56 |
| Cimi | mzanetti, the question was what you meant there | 15:57 |
| Cimi | mzanetti, on that file | 15:57 |
| Cimi | mzanetti, my MR is for SearchIndicator | 15:57 |
| nic-doffay | Saviq, about the PageHeader control test. Shall I keep that assigned to me and just prioritise the Infographics work? | 15:57 |
| mzanetti | Cimi: hmm... Saviq wrote that... I think he meant to check if the label is only visible if non-empty etc | 15:58 |
| Cimi | ok will think about it | 15:58 |
| dandrader | greyback, ping | 15:59 |
| greyback | dandrader: pong | 15:59 |
| dandrader | greyback, about the "close apps from dash" story: seems you made it so that if the user taps anywhere over the app thumbnail/tile (as opposed to only over its close icon) it will cause the application to close | 16:00 |
| dandrader | greyback, what the reasoning behind it? | 16:00 |
| pete-woods | Saviq: where do you see tests for the "infrograpic" API existing? | 16:01 |
| mzanetti | tsdgeos: would you consider all files in HUD tested sufficiently? | 16:01 |
| greyback | dandrader: was design request | 16:01 |
| dandrader | greyback, ahh... so we did have some design on that feature after all :) | 16:01 |
| dandrader | greyback, And how do I dismiss the close mode? | 16:02 |
| dandrader | greyback, switch do another dash? | 16:02 |
| greyback | dandrader: by request I mean I was showing it off to designers and was told to do that :) Nothing written down unfortunately | 16:02 |
| dandrader | s/do/to | 16:02 |
| greyback | dandrader: I recall that in delete mode, the other visible areas of the dash are dimmed. Then you could dismiss delete mode by tapping darkened bits (including the header) or opening launcher/indicators, or switching to different lens | 16:03 |
| greyback | dandrader: that's from memory. Mika was the UX designer I was working with, and Jouni the visual designer. | 16:05 |
| pete-woods | Saviq: because obviously if I'm writing an API someone else has already written tests for that's like developer heaven ;) | 16:05 |
| greyback | mzanetti: too late :) | 16:06 |
| greyback | mzanetti: tsdgeos has a physical power-off timer switch on his machine that fires at 6pm :) | 16:06 |
| mzanetti | greyback: what? | 16:06 |
| mzanetti | ah | 16:07 |
| mzanetti | hehe | 16:07 |
| mzanetti | greyback: I bet I can reach him using mzanetti@kde.org :D | 16:07 |
| greyback | mzanetti: but that'll not be the tsdgeos we know and.. tolerate. He'll be some KDE mutant twin | 16:07 |
| mzanetti | greyback: that fits me quite well :P | 16:08 |
| greyback | mzanetti: actually while I got you, in testing ListViewWithPageHeader, I was having some trouble moving the Flickable a tiny bit. I know of your mouseFlick method, but I couldn't make it move the content just a little bit. Any tip? | 16:09 |
| greyback | mzanetti: I can emulate a small flick manually with a bunch of mouseMove calls, but it ain't pretty | 16:10 |
| mzanetti | greyback: I fear thats the only way :/ | 16:10 |
| greyback | mzanetti: ok, it works so I'll leave it | 16:11 |
| mzanetti | greyback: iirc there are some comments in Flickable's codebase that describe this... you have to interpolate your flick yourself, otherwise it won't do | 16:11 |
| greyback | mzanetti: yep, I've been reading hte source too, saw that | 16:11 |
| greyback | mzanetti: ok, that's 3 hours too much time I've spent at that :( | 16:11 |
| mzanetti | greyback: probably it would make sense fix our mouseFlick() method to enable it for that | 16:11 |
| greyback | mzanetti: yep, I'm considering it | 16:12 |
| greyback | mzanetti: would be a fun bit of maths :) | 16:12 |
| mzanetti | yes, Herr Doktor | 16:13 |
| dandrader | greyback, another thing: why did you also add a CloseIcon to Tile (besides RunningApplicationTile) | 16:13 |
| greyback | mzanetti: :P | 16:14 |
| greyback | dandrader: in case in future it was wanted. Say to uninstall applications. | 16:14 |
| greyback | dandrader: no need for you to agree with that tho | 16:14 |
| kgunn | pete-woods: i don't think there is an API....and that was the idea, nic-doffay could help you out in a way...while at the same time defining the api :) | 16:15 |
| === dandrader is now known as dandrader|lunch | ||
| kgunn | pete-woods: oops...by API...i meant both API & free test :) | 16:15 |
| greyback | dandrader: note there's 1 bad thing I did in that code. I placed the close button with negative anchor margins. That can sometimes cause redraw issues when the delegate is being animated, as I discovered later. | 16:16 |
| pete-woods | kgunn: I'm not sure I follow? I guess I was expecting to be implementing an API that nic-doffay would be interrogating for infrographic data | 16:16 |
| * mzanetti is sad that now that we have fancy statistics noone proposes any MP's any more :D | 16:16 | |
| Saviq | nic-doffay, we'll take over the PageHeader test | 16:17 |
| mzanetti | Saviq: should I finish that one? | 16:17 |
| pete-woods | kgunn: and that I'd have to define another API for app developers to register their information to appear in the infrographic | 16:17 |
| Saviq | mzanetti, sure, have at it | 16:17 |
| nic-doffay | Ok Saviq, shall I delete the MP and make a branch on unity-team? | 16:17 |
| nic-doffay | pete-woods, that was the impression I got too :) | 16:17 |
| Saviq | nic-doffay, mzanetti'll take care of it | 16:17 |
| nic-doffay | Saviq, ok. | 16:18 |
| kgunn | pete-woods: i'm overloading terms...i just meant the interface between infographics & backend | 16:18 |
| mzanetti | nic-doffay: no problem. I'll just pull yours and continue on that | 16:18 |
| nic-doffay | cool cheers mzanetti | 16:18 |
| Saviq | mzanetti, you can always retrigger all of the outstanding ones :D | 16:22 |
| mzanetti | haha | 16:23 |
| mzanetti | Saviq: I think they need to be merged with trunk again to pass ci | 16:23 |
| Saviq | mzanetti, right | 16:23 |
| Saviq | pete-woods, the shell-facing API tests will be written in QML and live in lp:unity/phablet (where your API for infographics will later live, too) | 16:25 |
| Saviq | pete-woods, they will be very small, though | 16:26 |
| === salem_ is now known as _salem | ||
| Saviq | pete-woods, just verifying that the API exposes all the needed properties / methods / whatever | 16:27 |
| pete-woods | Saviq: would you want the service implementation in there too? I'm expecting it to be a dbus service | 16:27 |
| Saviq | pete-woods, I don't care it being a dbus service or not ;) | 16:27 |
| sil2100 | ChrisTownsend: hi! About the SRU timeline for quantal and precise | 16:27 |
| Saviq | pete-woods, and the implementation itself should live outside of lp:unity/phablet | 16:28 |
| sil2100 | ChrisTownsend: we will try preparing releases till the EOW, but from what Didier said, it might take a while for them to get uploaded | 16:28 |
| sil2100 | Up to 1 month | 16:28 |
| pete-woods | Saviq: okay, so something like a Qt API living somewhere else? and a QML API in the unity tree? | 16:29 |
| Saviq | pete-woods, no, the APIs will all live in the unity tree | 16:29 |
| Saviq | pete-woods, both shell-facing and app-facing | 16:29 |
| Saviq | pete-woods, but the implementation of the service | 16:29 |
| Saviq | pete-woods, will, if possible, live outside | 16:30 |
| tedg | Saviq, The implementation of the service needs to live in the same repo as the APIs to it are used. | 16:30 |
| pete-woods | Saviq: so it will become very important we sync the version of the service to the version of unity then | 16:30 |
| tedg | Saviq, We don't want things like dbus interfaces spanning repos. | 16:30 |
| Saviq | tedg, of course we don't, but we can abstract from it | 16:31 |
| tedg | Saviq, So you want lib -> lib, lib -> service -> lib, lib -> lib ? | 16:31 |
| Saviq | tedg, but the unity repo might only include mock implementations of the service | 16:32 |
| tedg | Saviq, Basically so the dbus interface is with teh service. | 16:32 |
| pete-woods | Saviq: if you want it in the unity tree just to make sure it has test coverage, you need not worry, wherever I put it, it will be well tested | 16:32 |
| Saviq | pete-woods, no it's not that, it's about syncing changes in the API - we want changes to API to break the shell straight away | 16:33 |
| Saviq | pete-woods, not only when it's built in distro / PPA | 16:33 |
| pete-woods | Saviq: is the shell even going to be using the API? | 16:34 |
| Saviq | pete-woods, some API, yes | 16:34 |
| Saviq | pete-woods, for the shell it's going to be a QML API, but built on top of some C++ one | 16:34 |
| tedg | Saviq, But, let's say there's another API that's delivered by the service's repo. When that changes it'd break your build the same. | 16:35 |
| pete-woods | Saviq: of course that's how I'll build it, but I'm just interested which part of the API you see the shell using? | 16:35 |
| tedg | Saviq, They only way you get that is to copy the entire world into the Unity repo. | 16:35 |
| Saviq | tedg, not if the Unity repo defines just the interfaces that the service then implements | 16:36 |
| tedg | Saviq, So you want to supply the -dev package and have the service provide the lib package? That seems a bit insane to me. | 16:37 |
| Saviq | pete-woods, not sure what parts do you have in mind | 16:38 |
| Saviq | tedg, I'm not opposed to implementation living within the Unity repo, but we don't want, as you put it, to "copy the whole world" there | 16:39 |
| pete-woods | Saviq: well I see it very superficially as a service with an IN and an OUT | 16:39 |
| Saviq | pete-woods, yeah, the OUT part is what the shell will be interested in | 16:40 |
| pete-woods | Saviq: the OUT is very much the territory of the infrographic | 16:40 |
| Saviq | pete-woods, and the IN part is what the apps will be interested in | 16:40 |
| pete-woods | Saviq: which isn't part of the shell? | 16:40 |
| pete-woods | the OUT I mean | 16:40 |
| tedg | Saviq, At some point there is going to be an interface between your repo and the other repo. That can/will break. Just making sure you realize that :-) We can put as many fancy words around as we want :-) | 16:41 |
| pete-woods | the infrographic is in the greeter | 16:41 |
| Saviq | pete-woods, it's actually in the welcome screen | 16:42 |
| pete-woods | Saviq: surely that shouldn't be part of the shell? | 16:42 |
| Saviq | pete-woods, depends | 16:42 |
| pete-woods | Saviq: what about when we change user? | 16:42 |
| Saviq | pete-woods, that's actually the login screen | 16:42 |
| Saviq | pete-woods, that design folks is thinking of splitting out of the welcome screen | 16:42 |
| Saviq | pete-woods, but anyway I was simplifying by including the greeter in the shell | 16:42 |
| kgunn | upgrading to raring... | 16:42 |
| Saviq | it's not part of the shell as in the session shell | 16:43 |
| Saviq | but part of the shell as in the system shell | 16:43 |
| Saviq | tedg, sure, but we can try and minimize the impact | 16:43 |
| pete-woods | Saviq: okay, well if the shell is consuming the OUT API, I can understand why you care about it | 16:44 |
| pete-woods | Saviq: I would tend to agree with tedg that you can't expect to have all your APIs in the shell tree, though | 16:44 |
| pete-woods | Saviq: for example if I implement the service out of tree, then it's the DBUS API that breaks, and you only notice at run / test time, instead of compile time | 16:45 |
| Saviq | pete-woods, either way it's going to be a Unity API and whether it's going to be consumed by the shell or the greeter doesn't really matter | 16:45 |
| Saviq | pete-woods, tedg why could the interfaces (as in abstract classes) not be with the shell tree | 16:46 |
| tedg | Saviq, How do you change them in sync with a release of the service? | 16:46 |
| pete-woods | Saviq: I mean tbh I'll do it whichever way you think works best, I just worry about missing API breakages by keeping it all separate | 16:46 |
| Saviq | tedg, same as usual, just pray ;) | 16:47 |
| Saviq | tedg, and depend on the libunity-api version you built the service against | 16:47 |
| tedg | Saviq, Well, we don't pray. We version the package and make sure the binary versions are the same through packaging requirements. | 16:47 |
| tedg | I mean, sure, it just seems like it's making life more difficult. | 16:48 |
| tedg | The goal being "make unity never break" which I think we've shown really isn't achievable anyway. | 16:49 |
| Saviq | tedg, the thing is that, if the interfaces live with the shell, before you can build the service, you'll have to make sure that the updated APIs don't break the shell | 16:50 |
| Saviq | tedg, and you can't actually check in any API change that would, 'cause CI would prevent that | 16:50 |
| nic-doffay | Saviq, would infographics be considered a part of /Components? | 16:51 |
| Saviq | nic-doffay, not really, /Greeter, I'd say | 16:51 |
| nic-doffay | Saviq, doh! didn't see it! | 16:51 |
| tedg | Saviq, All you're guaranteeing is that Unity C++ remains buildable, not that it works or links properly. It seems like a silly optimization to me. If it makes you happy, that's fine. | 16:53 |
| Saviq | tedg, don't get me wrong, first of all, I'm not saying "do it like that!", I'm trying to find a solution | 16:56 |
| Saviq | tedg, second, I'm not opposed to putting the service implementations with the shell, but that's not going to be possible at times (like scopes, for example) | 16:57 |
| pete-woods | Saviq: eventually you have to deal with API breakages outside your package, in my experience you control the versions of your dependencies in CI to either ensure you have the bleeding edge ones, or stable ones | 16:58 |
| === _salem is now known as salem_ | ||
| ChrisTownsend | sil2100: Ok, thanks! Any idea why the delay in the uploads? | 17:09 |
| sil2100 | smspillaz: yay! It went through CI correctly this time \o/ | 17:09 |
| sil2100 | smspillaz: do you mind that I approved the quickfix merge globally? | 17:09 |
| sil2100 | ChrisTownsend: didrocks said he will be only able to do the uploads during his next patch pilot, which is in 4 weeks - we might try poking other people, but in the worst case Didier will take care of it in a month | 17:10 |
| Saviq | pete-woods, sure, but our current issue is that if the service defines and holds the API definition, it can be changed at will | 17:10 |
| Saviq | pete-woods, and we can try to alleviate that with versioning, but the fact is that when that happens shell development will be blocked until the API change is addressed | 17:11 |
| pete-woods | Saviq: only if some joker looks after the API, aren't we all supposed to have, like, well defined ABIs? | 17:11 |
| pete-woods | surely I should be saying, hey Saviq, API breakage coming.. | 17:12 |
| ChrisTownsend | sil2100: Ok, thanks, makes sense. Really hope it can make it sooner since it seems to have a pretty big impact on Steam users and other apps that use undecorated windows. | 17:12 |
| Saviq | whereas if the interfaces are defined with the shell, it's the shell / libunity-api that will be changed first | 17:12 |
| === alan_g is now known as alan_g|life | ||
| pete-woods | Saviq: well you don't really have to convince me, as I'll just go along to be honest | 17:13 |
| Saviq | pete-woods, sure I do ;) I'm fishing, here, too | 17:13 |
| Saviq | pete-woods, we definitely need a discussion (and soon) | 17:13 |
| pete-woods | Saviq: I'd rather we all pull in the same direction even if I don't agree with it | 17:14 |
| Saviq | to come up with a plan | 17:14 |
| tedg | Saviq, But if there is an API or ABI bump, and the packages are parallel installable, development wouldn't be stopped until someone removes the old package, right? | 17:15 |
| tedg | Saviq, So shouldn't our goal be to make everything parallel installable? | 17:15 |
| tedg | Saviq, And that would, in effect, solve your problem. | 17:15 |
| tedg | (and others) | 17:15 |
| pete-woods | tedg: is it common that packages are parallel installable? | 17:15 |
| pete-woods | (I have never heard of this feature) | 17:16 |
| Cimi | I need a little help with a Makefile I guess lp:~unity-team/unity/phablet.moving_tests | 17:16 |
| tedg | pete-woods, Not always, but they can be. | 17:16 |
| Cimi | the Hud test doesn't work with my new hierarchy | 17:16 |
| tedg | pete-woods, It's something we've almost got with hud, but I found a bug in it last week :-( | 17:16 |
| Cimi | who can help me and have a little look? | 17:16 |
| Saviq | tedg, if you upgrade a package in distro, will the old version still be available for installation? | 17:17 |
| Saviq | tedg, surely you don't mean that the package will provide multiple versions? | 17:17 |
| tedg | Saviq, If someone depends on it, and then when no one depends on it, for about a week. | 17:17 |
| tedg | Saviq, No, the binary package. | 17:17 |
| tedg | source -> bin1, then in the future, source -> bin2. bin1 will live as long as there's a dep. | 17:18 |
| tedg | Interesting question on build-dep though.... | 17:18 |
| tedg | Let's ask. | 17:19 |
| mzanetti | Saviq: is it wanted that the SearchHistory stores stuff in lowercase or did the test reveal a bug? | 17:20 |
| Saviq | mzanetti, wanted | 17:20 |
| mzanetti | ok | 17:20 |
| Saviq | mzanetti, well, both | 17:20 |
| Saviq | mzanetti, it should display the exact string entered (stripped) | 17:20 |
| mzanetti | I typed "Humppa" | 17:20 |
| Saviq | mzanetti, but compare lowercase | 17:20 |
| mzanetti | and model.get(0).query returns "humppa" | 17:20 |
| Saviq | mzanetti, bug, then, I'd say | 17:21 |
| mzanetti | muahaha | 17:21 |
| Saviq | mzanetti, just tested on the phone | 17:22 |
| Saviq | mzanetti, it stored the same case | 17:22 |
| Saviq | mzanetti, looking at the code, it doesn't even do case-insensitive comparison | 17:24 |
| mzanetti | Saviq: yeah... thats why I asked... | 17:24 |
| mzanetti | doh! | 17:24 |
| Saviq | mzanetti, so to that extent it's broken, but it does store the same case query | 17:24 |
| mzanetti | found the issue | 17:24 |
| mzanetti | keyClick("H") only presses "h", not shift | 17:25 |
| Saviq | ;) | 17:25 |
| Saviq | tedg, yeah, if we can build against an old version of the API, and everything that came out of the corresponding source package is kept | 17:25 |
| Saviq | tedg, then we should be good either way | 17:26 |
| tedg | Saviq, I put a question in #ubuntu-devel to ask about how that purge happens. It's possible from a technical perspective, but not sure how fast the archive garbage collector detects garbage. | 17:26 |
| Saviq | tedg, but the other point was that keeping the APIs separate from the implementations would allow for drop-in replacements | 17:27 |
| tedg | Saviq, Hoping build-deps are considered, but I'm not 100% sure. | 17:27 |
| tedg | Saviq, Sure, that's what Provides: are for :-) | 17:27 |
| Saviq | tedg, well, yeah, but then you have to copy the interface between implementations | 17:28 |
| Saviq | or at least depend | 17:28 |
| Saviq | on some "blessed" implementation | 17:28 |
| tedg | Which is really the same thing as you'd have to depend on the interface in Unity. | 17:28 |
| tedg | It doesn't matter where the interface is, you'd have to depend on it either way. | 17:28 |
| tedg | Perhaps I'd like a drop in replacement for Unity? ;-) | 17:29 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| Saviq | tedg, we did that already! ;) | 17:32 |
| === dandrader|lunch is now known as dandrader | ||
| === jhodapp is now known as jhodapp|bbiab | ||
| Saviq | aaanyway - we definitely need to agree on something, and soon... | 17:38 |
| mzanetti | Saviq: https://code.launchpad.net/~mzanetti/unity/phablet-pageheader-tests/+merge/157711 | 17:47 |
| Saviq | mzanetti, go away, it's past your bedtime (and mine, too, trying to get up for over an hour now ;P) | 17:47 |
| mzanetti | hehe... yeah... I just finished this task | 17:47 |
| mzanetti | will go away now | 17:47 |
| mzanetti | Saviq: btw... I discovered a bug in the History Popup. Seems to be the popuputils not our code. couldn't write a testcase for it because the popup is not a child of any of our objects | 17:48 |
| mzanetti | but if you make the window small enough that the popup doesn't fit below the textfield, but next to it, clicking on it doesn't work any more :D | 17:49 |
| mzanetti | will report a bug tomorrow | 17:49 |
| mzanetti | see you all tomorrow | 17:50 |
| Saviq | mzanetti, cheers | 17:50 |
| Saviq | mzanetti, and I think it's actually our bug | 17:51 |
| mzanetti | is it | 17:51 |
| Saviq | mzanetti, there's an InverseMouseArea around the popup | 17:51 |
| mzanetti | Saviq: well, clicking the popup does work, and the popup closes, but it doesn't restore the text | 17:51 |
| Saviq | mzanetti, but it only supports the popup being below the text input | 17:51 |
| Saviq | mzanetti, yeah, because you're actually dismissing the popup | 17:52 |
| Saviq | not clicking it | 17:52 |
| mzanetti | right... | 17:52 |
| Saviq | mzanetti, anyway, have a good evening | 17:52 |
| mzanetti | yep... unfortunately I couldn't really test it as I have no chance to findChild() the popup | 17:52 |
| Saviq | yeah | 17:52 |
| Saviq | freakin' qtcreator | 17:53 |
| tedg | Saviq, So it seems that the garbage collection process is an actual human, and they check the build-deps. So as long as we can make things parallel installable, you should be good. | 18:10 |
| Saviq | tedg, really? a human? yikes | 18:10 |
| * tedg is a bit surprised it is a human, but glad it's not him. | 18:10 | |
| tedg | Saviq, Yeah, I know. They're messy and hard to duplicate! | 18:11 |
| davmor2 | Hey guys music still isn't opening in RB unless RB is open. With RB closed. Open Dash on Music Lens select a track. expect RB to open and track to start playing Raring is the only system not doing this | 18:45 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === jhodapp|bbiab is now known as jhodapp | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| tedg | Saviq, Okay, more info. | 20:22 |
| tedg | Basically everything will get blocked in proposed. | 20:22 |
| tedg | So let's say there's a libhudclient2 but unity is still depending on libhudclient1 | 20:22 |
| tedg | Until Unity migrates from libhudclient1 to 2, hud won't land nor will unity land. | 20:23 |
| tedg | Everything ends up waiting for a complete change set. | 20:23 |
| tedg | So if you're developing Unity, until Unity trunk has the merge to update to libhudclient2, libhudclient1 will always be available in the archive. | 20:24 |
| tedg | Once trunk has it, you should update your dev branch. | 20:24 |
| tedg | But I'm guessing that is uncontroversial. | 20:24 |
| Saviq | tedg, got it, a followup question - how does library SONAME relate to the API version, then? | 20:31 |
| tedg | Saviq, It doesn't. It only relates to the ABI version. | 20:31 |
| tedg | Saviq, In HUD and dbustest we're keeping them separate and managing the dev packages appropriately. | 20:31 |
| Saviq | tedg, right, that's what I thought, so whatever ends up in the _package_ name is the API version | 20:32 |
| tedg | Saviq, So then when you update to libhudclient2 you change your builddep | 20:32 |
| tedg | Saviq, Of the dev package name is the API version | 20:32 |
| Saviq | tedg, and the lib package name? | 20:34 |
| tedg | Saviq, That will be the ABI version. But, really, you don't care about that as dpkg discovers the right version for you. | 20:35 |
| Saviq | tedg, yeah I know, just trying to get the hang of it | 20:35 |
| Saviq | tedg, so libhudclient2-dev might very well relate to libhudclient50? | 20:36 |
| Saviq | or the other way round, rather | 20:36 |
| tedg | Well, they could be either way really :-) | 20:36 |
| tedg | In theory you'd always change ABI when you change API. | 20:37 |
| * tedg tries to think of a way you could change API without changing ABI... | 20:37 | |
| tedg | I guess if you changed #define values or enums. | 20:37 |
| === francisco is now known as Guest87879 | ||
| === salem_ is now known as _salem | ||
| slangasek | bregma: hey, so if https://code.launchpad.net/~vorlon/compiz/lp.763148-0.9.9/+merge/157584 is merged onto lp:compiz/0.9.9, do you know when I should see this show up in raring? | 22:48 |
| bregma | slangasek, probably tomorrow, after the autolander has run | 22:55 |
| bregma | I'm not sure what time they schedule that for exactly | 22:56 |
| slangasek | bregma: ok, that was going to be my next question ;) since nearly a full day has passed since it was merged already | 22:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!