[07:17] <didrocks> mmrazik: it's already in split mode FYI (I checked it)
[07:17] <didrocks> mmrazik: but yeah for source 1, see my comment :)
[07:18] <didrocks> the real issue though is the "native package" thing
[07:18] <mmrazik> didrocks: I didn't notice your other comments earlier. I was just getting some failures from jenkins
[07:18] <mmrazik> so I just commented on some obvious stuff
[07:18] <didrocks> mmrazik: yeah, launchpad comment doesn't use ajax to refresh comments…
[07:18] <mmrazik> didrocks: FYI -- some of the qtubuntu* project don't build on i386
[07:18] <mmrazik> like qtvideo-node
[07:19] <didrocks> mmrazik: really? mzanetti was telling me everything was running on the destkop
[07:19] <mmrazik> and one more where I disabled the i386 builds yesterda...
[07:19] <didrocks> desktop*
[07:19] <didrocks> so amd64
[07:19] <didrocks> but not i386?
[07:19] <mmrazik> didrocks: didn't try amd64. I doubt it builds there
[07:19] <didrocks> mmrazik: can you clarify this with mzanetti please? We should fix it anyway
[07:19] <mmrazik> didrocks: qtvideo-node and qtubuntu-media don't build on i386
[07:20] <mmrazik> mzanetti: ^^^
[07:20] <didrocks> thanks ;)
[07:21] <mmrazik> didrocks: in matter of fact qtvideo-nodes's packaging explicitely says its armel|armhf
[07:21] <mmrazik> but should be fixed
[07:21] <mmrazik> was talking with jhodapp yesterday and it looks like nobody recalls why this stuff is there
[07:21] <didrocks> mmrazik: yeah, let's see with him
[07:21] <didrocks> ok
[07:21] <didrocks> mmrazik: do you have the local repository btw?
[07:21] <didrocks> mmrazik: https://code.launchpad.net/~unity-team/unity-scope-home/master-scopes/+merge/153440 was rejected because of that I guess
[07:22] <mmrazik> didrocks: not really :-/ I want to work on it today but it needs some refactoring so its all in cupstream2distro-config
[07:22] <mmrazik> got some pointers from fginther yesterday
[07:22] <didrocks> mmrazik: ok, let's see, it's blocking them I'm afraid
[07:23] <didrocks> mmrazik: at least, if they don't add new API, today daily should unblock them
[07:24] <mmrazik> didrocks: I really have a feeling that something in our dev process is not good when we change API every day :-/
[07:24] <mmrazik> but anyway... going to work on the local repo instead of complaining
[07:24] <didrocks> mmrazik: well… don't tell me
[07:24] <didrocks> mmrazik: but that's how I ended up with this local repo
[07:24] <mmrazik> didrocks: and that is why I'm a bit reluctant to do it :) as I see it more of a workaround to broken dev process
[07:25] <didrocks> mmrazik: agreed, well, this can happen, but not *that* often :)
[08:48] <seb128> hey
[08:48] <seb128> happy friday
[08:49] <seb128> sil2100, hey, the unity-team-stating ppa keeps spamming me about failing quantal builds, shouldn't we just stop building for quantal at this point?
[08:50] <didrocks> we should stop building for quantal and raring
[08:50] <didrocks> removing the ppa (WI from UDS)
[08:50] <didrocks> as we have the dailies now
[08:50] <didrocks> but not the first time I'm arguing for that ;)
[08:55] <didrocks> davidcalle: hey!
[08:55] <davidcalle_> didrocks, hey!
[09:34] <mzanetti> didrocks: hey. I said apps would run fine, yes
[09:35] <mzanetti> didrocks: never said all libraries would build everywhere. But some of the libraries are just not needed on anything else then android
[09:35] <didrocks> mzanetti: ah, we need the list then ;)
[09:36] <didrocks> mzanetti: and why they are not needed on other archs ;)
[09:36] <mzanetti> because they are for the android layer adaption
[09:36] <mzanetti> didrocks: ^
[09:36] <mzanetti> didrocks: no need to have bindings to libhybris on desktop
[09:37] <mzanetti> didrocks: its mostly Qt backends
[09:37] <didrocks> mzanetti: do you mind documenting all the packages from the list in the whiteboard as well?
[09:37] <didrocks> mzanetti: that will be shared with the whole team that way :)
[09:37] <mzanetti> didrocks: well... I think I can help you but I am actually in the shell team its not that we don't have anything to do there
[09:38] <mzanetti> :)
[09:38] <mzanetti> didrocks: I think someone from that team should just know which ones don't build
[09:39] <didrocks> mzanetti: yeah, but you have the knowledge of why things don't need to build, so if you or ricmm can provide the info as requested in the WI, the whole project will gain some time
[09:39] <didrocks> rather than rediscovering everything…
[09:40] <mzanetti> yeah, ok... I'll try to find out
[09:40] <didrocks> mzanetti: thanks :)
[09:40] <didrocks> mzanetti: on the busy thing -> we all are. If you want my schedule from the previous days, it's more 12/14 hours a day for the 100 scope thing with no break
[09:40] <didrocks> and it's something happening regularly for the 3 years I'm working here ;)
[09:40] <didrocks> so, we all are busy :)
[09:41] <mzanetti> didrocks: yeah sure... just realized that I have opened todos all over the place and wanted to start getting those done before opening new ones :)
[09:42] <didrocks> mzanetti: yeah, well, TBH, that was part of the WI we discussed about the other day :)
[09:42] <didrocks> (and blocking other people)
[10:04] <tvoss> MacSlow, Saviq, a first cut at the NotificationSource: http://collabedit.com/5ngav
[10:05] <MacSlow> tvoss, taking a loook... thx
[10:11] <didrocks> mmrazik: pull last commit from cupstream2distro-config, there is a new scope to add (the gdrive one)
[10:12] <mmrazik> mhm... the scope config is a bit broken ATM :-/
[10:12] <didrocks> mmrazik: why?
[10:12] <mmrazik> didrocks: some of the local repo changes landed yesterday but not all
[10:12] <mmrazik> anyway...
[10:12] <mmrazik> lets see
[10:13] <mmrazik> maybe I'll just test what I did for the local repo in production :)
[10:13] <didrocks> mmrazik: isn't it what people do here? :p
[10:13] <didrocks> mmrazik: I'm adding it to daily release
[10:13] <mmrazik> ok
[10:13] <didrocks> mmrazik: from what I heard, there is changes for more to come FYI
[10:14] <mmrazik> didrocks: ok. I was hoping I'll make the local repo changes, test it locally and let fginther review in the afternoon
[10:14] <didrocks> mmrazik: ok, for now, I don't see changes coming to gdrive TBH
[10:14] <mmrazik> ok
[10:14] <mmrazik> then I'll just keep it as it is
[10:15] <mmrazik> didrocks: if there is an (approved) merge proposal my watchdog will complain and I'll see it
[10:15] <mmrazik> its nice that you can add stuff to the watchdog :)
[10:15] <didrocks> mmrazik: sounds good! :)
[10:15] <didrocks> heh
[10:16] <didrocks> and nice to have a config file for all projects/branches
[10:18] <didrocks> mhr3: I saw that home scope is merged now, I shold rerun asap with that one, right?
[10:18] <didrocks> mhr3: then, we'll start to see some of the new scopes
[10:19] <mhr3> didrocks, it's mostly about the server intergration atm
[10:19] <didrocks> ok
[10:19] <mhr3> but yea, it'll be better (tm)
[10:19] <didrocks> mhr3: I'll keep you posted once the current builds finishes and that we have the home scope in the ppa
[10:19] <didrocks> mhr3: © ;)
[10:19] <tvoss> MacSlow, what's the well-known name for the notification service?
[10:20] <tvoss> MacSlow, as in DBus well-known name
[10:20] <larsu> tvoss: org.freedesktop.Notifications
[10:21] <MacSlow> tvoss, from /usr/share/dbus-1/services/org.freedesktop.Notifications.service "org.freedesktop.Notifications"
[10:23] <tvoss> larsu, MacSlow thanks
[10:37] <didrocks> mmrazik: oh, I just realized on the ps-unity-autopilot-release-testing
[10:37] <didrocks> mmrazik: I need the ppa to by dynamically set
[10:37] <didrocks> mmrazik: what should we do for the 100 scopes projects? should we just duplicate it in a hurry?
[10:40] <mmrazik> didrocks: I would clone the job and then do some sed-ing on resources/preseed.cfg
[10:40] <didrocks> mmrazik: thanks, give me the job I should add once done :)
[10:40] <mmrazik> seems to be the least error prone solution ATM
[10:41] <mmrazik> didrocks: like job name?
[10:41] <mmrazik> or should I create it?
[10:41] <mmrazik> didrocks: what is the ppa?
[10:41] <didrocks> mmrazik: agreed on the least risky for now
[10:41] <didrocks> mmrazik: ppa is https://launchpad.net/~ubuntu-unity/+archive/experimental-prevalidation
[10:41] <mmrazik> ok
[10:41] <mmrazik> on it
[10:41] <didrocks> thanks!
[10:44] <mmrazik> didrocks: ps-unity-100scopes-experimental-autopilot-release-testing
[10:44] <mmrazik> sounds like a german word or something :)
[10:44] <didrocks> mmrazik: ahah, exactly! :-)
[10:44] <didrocks> thanks!
[10:48] <didrocks> mhr3: rebuilding the home scope
[10:49] <mhr3> didrocks, do we have a bunch of testers of that ppa?
[10:50] <didrocks> mhr3: well, not as long as it's not 35% functional :)
[10:50] <didrocks> mhr3: but I have a crew ready for it
[10:50] <didrocks> :)
[10:50] <mhr3> didrocks, k, let's hope it will really work on 35% :)
[11:10] <didrocks> mhr3: unity-home-scope failed :(
[11:10] <didrocks> or rather unity-scope-home
[11:10] <didrocks> https://launchpadlibrarian.net/134261766/buildlog_ubuntu-raring-amd64.unity-scope-home_6.8.0daily13.03.15.2ubuntu.unity.experimental.certified-0ubuntu1_FAILEDTOBUILD.txt.gz
[11:10] <didrocks> mhr3: seems a test not passing ^
[11:11] <didrocks> (similar that what happened when I gave the list to thomas yesterday)
[11:11] <didrocks> No such file or directory for tests/fake-server/fake-sss-server.py
[11:13] <didrocks> Trevinho: hey!
[11:37] <mmrazik> didrocks, mhr3: I'm going to deploy the local archive stuff even though the related MP is not yet review/landed. I'll be watching the jobs but ping me if there is something urgent.
[11:37] <mmrazik> its likely few MPs will fail
[11:37] <mmrazik> as I'm not 100% sure what needs to be configured server-side (where the local archive lives)
[11:37] <mmrazik> never done it before
[11:38] <didrocks> ok, thanks for updating us :)
[12:04] <Trevinho> didrocks: hey
[12:05] <didrocks> how are you?
[12:06] <Trevinho> allright... you?
[12:06] <didrocks> busy, but fine :)
[12:07] <didrocks> Trevinho: I'm on the 100 scopes ppa, so not synchronized with latest changes in unity, but is the "pressing enter should shutdown the machine after clicking on shutdown in the indicator-session or same with logout, when clicking on logout" known/fixed?
[12:08] <Trevinho> mh, no..
[12:08] <Trevinho> didrocks: so you basically want the selected action to be key-focused by default?
[12:08] <didrocks> Trevinho: exactly, makes sense regarding the previous behavior, isn't it?
[12:09] <seb128> the order of the actions changed as well which is weird
[12:09] <didrocks> yeah
[12:09] <seb128> and we still have the old dialogs on the greeter
[12:09] <seb128> I wonder if those changes are an improvement at the end
[12:09] <seb128> Trevinho, no offense to your work, you just followed the design
[12:10] <seb128> I should probably complain to JohnLea about that ;-)
[12:10] <seb128> we also had a fix for the "shutdown doesn't work when other users are logged in" ready to merge for the gtk dialog
[12:11]  * Trevinho got an unwanted reboot :o
[12:11] <Trevinho> anwayy..
[12:11] <JohnLea> seb128, Trevinho, didrocks; yes, that's an omission from the original change request from design, hitting enter should action the selected item
[12:11] <Trevinho> didrocks: well, yes... it could I just didn't get the design input for that
[12:11] <Trevinho> JohnLea: ^
[12:12] <didrocks> \o/
[12:12] <Trevinho> JohnLea: ah you was fast:)
[12:12] <Trevinho> JohnLea: so... do you want the default icon to be selected also, isn't it?
[12:12]  * JohnLea ;-)
[12:12] <Trevinho> (i.e. highlighted)
[12:12] <seb128> JohnLea, what design recommend to happen when you pick shutdown with other users logged in?
[12:12] <JohnLea> Trevinho; yes
[12:13] <Trevinho> JohnLea: ok
[12:13] <Trevinho> seb128: about the lightdm thing, I know... But it was not my scope :)
[12:14] <Trevinho> didrocks: could you please quickly open a bug so that I can track it?
[12:14] <didrocks> Trevinho: sure sure
[12:14] <didrocks> Trevinho: I have also a bug in the launcher reveal
[12:14] <didrocks> Trevinho: who should I assign it to?
[12:15] <Trevinho> didrocks: try with andyrock
[12:15] <Trevinho> (i would look at it as well, but I've already a bunch of things in my list)
[12:15] <didrocks> Trevinho: sure :)
[12:15] <didrocks> ok, andyrock, I have a lovely autohide bug for you :)
[12:15] <andyrock> didrocks, link?
[12:15] <didrocks> let me open the bug or find one
[12:16] <Trevinho> didrocks: or also brandon when he's back
[12:16] <didrocks> andyrock: try to set your launcher to autohide
[12:16] <didrocks> go to 0x0
[12:16] <didrocks> well, make it reveal first
[12:16] <didrocks> go to 0x0
[12:16] <didrocks> then go outside the launcher
[12:16] <didrocks> the launcher hide
[12:16] <didrocks> try to reveal it with the mouse again
[12:16] <didrocks> -> can't
[12:18] <andyrock> didrocks, can't reproduce here
[12:19] <Trevinho> JohnLea: also we have some timeout now for the tooltips.. It's set to 1 second, but imho is too much... what about lowering to 500ms?
[12:19] <didrocks> andyrock: I have two screens
[12:19] <Trevinho> didrocks: any input on that? ^
[12:19] <didrocks> Trevinho: oh definitively agree it's a little bit too long
[12:19] <andyrock> didrocks, ah I'm on single monitor setup
[12:19] <JohnLea> Trevinho; go for it if you think that makes them feel better ;-)
[12:19] <didrocks> andyrock: that's weird as I can reproduce it even in one desktop
[12:19] <didrocks> andyrock: and I saw other people complaining about it
[12:20] <Trevinho> JohnLea: nice... :)
[12:20] <andyrock> Trevinho, timeout lenght is not the only problem
[12:20] <didrocks> Trevinho: https://bugs.launchpad.net/unity/+bug/1155589
[12:20] <didrocks> yeah, the length is weird as well
[12:20] <didrocks> Trevinho: ^
[12:20] <Trevinho> didrocks: yep, i already commented /assigned it :)
[12:20] <didrocks> Trevinho: the new bug or the length?
[12:21] <Trevinho> didrocks: the bug...
[12:21] <didrocks> ah :)
[12:21] <Trevinho> didrocks: oopps, we had one before bug #1155562
[12:21] <andyrock> didrocks, 0x0 is top-left corner or bottom-left corner for you?
[12:21] <andyrock> top-left for mr
[12:21] <andyrock> *me
[12:21] <didrocks> andyrock: top left
[12:21] <didrocks> Trevinho: feel free to dup it
[12:22] <didrocks> andyrock: so, have the launcher
[12:22] <didrocks> andyrock: reveal it by pushing the mouse on the border
[12:22] <didrocks> go to 0x0
[12:22] <andyrock> didrocks, the launcher hides when I go to 0x0
[12:22] <didrocks> then, go the right
[12:22] <didrocks> andyrock: right
[12:22] <didrocks> and try pushing again against the edge
[12:23] <Trevinho> didrocks: sorry for wasting your time :(
[12:23] <didrocks> Trevinho: no worry ;)
[12:23] <didrocks> Trevinho: do you see what I mean by the length of the labels?
[12:24] <didrocks> Trevinho: like in the launcher, for me, Terminal is stuck on the left
[12:24] <Trevinho> didrocks: oh, I lost the msg I think
[12:24] <didrocks> Trevinho: and I have a lot of blank spaces on the right
[12:24] <Trevinho> didrocks: tooltips?
[12:24] <didrocks> right
[12:24] <Trevinho> didrocks: yes, that's what I've fixed tonight
[12:24] <didrocks> Trevinho: brilliant!
[12:24] <Trevinho> ;)
[12:24] <didrocks> thanks :)
[12:24] <didrocks> andyrock: do you want a vidéo?
[12:24] <didrocks> video*
[12:25] <andyrock> didrocks, yep
[12:25] <andyrock> it will help me
[12:25] <andyrock> didrocks, ok i reproduced it
[12:25] <Trevinho> On parle fraçais ici... Donc, on doit utiliser les accentes!
[12:25] <didrocks> andyrock: argh
[12:26] <didrocks> andyrock: the video doesn't work
[12:26] <Trevinho> :)
[12:26] <didrocks> because gtk-record-mydesktop is stealing the top pixel :)
[12:26] <didrocks> Trevinho: ah, mais c'est vrai! :-)
[12:26] <andyrock> didrocks, np I reproduced it
[12:26] <didrocks> andyrock: great, want a bug?
[12:26] <didrocks> Trevinho: après ubuntu-desktop, on s'attaquera à ubuntu-unity pour passer tout ubuntu en français !
[12:27] <andyrock> didrocks, yes why not? :P
[12:27] <didrocks> andyrock: I was sure you would love it! :-)
[12:27] <Trevinho> didrocks: oui... c'est la route!
[12:27] <didrocks> héhé
[12:28] <Trevinho> andyrock: have a French course! :)
[12:28] <didrocks> andyrock: ça sera bientôt obligatoire ! Prepares-toi le futur ;)
[12:28] <didrocks> pour*
[12:29] <andyrock> Trevinho, i ahad a French course in high schools :P
[12:29] <andyrock> *had
[12:30] <didrocks> andyrock: https://bugs.launchpad.net/unity/+bug/1155598
[12:33] <mmrazik> didrocks: so the local repo doesn't seem to be working (yet) but  at least its not blocking autolanding (just the last step silently fails)
[12:34] <mhr3> didrocks, weird, how come the previous build worked?
[12:34] <didrocks> mhr3: no build worked in the builders
[12:35] <didrocks> mhr3: that's part of the list I sent to thomas of things failing
[12:35] <didrocks> mmrazik: ok :) at least, relying on the ppa should fit the requirement for now
[12:37] <didrocks> mhr3: needing help to debug?
[12:37] <mhr3> pstolowski, ^
[12:38] <pstolowski> didrocks: yep, definately, help would be appreciated. it works locally for me with a clean checkout (and it worked before in avani)
[12:40] <mhr3> david forgot to update the .scope files with the /usr/lib -> /usr/share move :/
[12:40] <didrocks> pstolowski: did you try on a pbuilder, does the error message makes sense at least?
[12:40] <pstolowski> didrocks: it needs #!/usr/bin/python
[12:40] <didrocks> pstolowski: ah, easy then, a branch to fix it? :)
[12:40] <pstolowski> didrocks: not sure if this is an issue? (python3 vs 2?)
[12:40] <didrocks> pstolowski: I wonder why it's failing in the chroot, maybe a missing dep?
[12:40] <didrocks> pstolowski: can be, yeah
[12:41] <pstolowski> didrocks: python is not listed in the deps
[12:42] <didrocks> pstolowski: let me try in a pbuilder
[12:43] <pstolowski> didrocks: ok, thanks
[12:48] <mhr3> didrocks, david gave me scope ids, but some don't seems to have a matching pkg in our json file
[12:48] <mhr3> didrocks, should those be added?
[12:48] <mhr3> i see for example foursquare
[12:48] <didrocks> mhr3: interesting. What thomas is saying about those?
[12:48] <mhr3> songkick
[12:48] <mhr3> evolution
[12:48] <didrocks> yeah, I want a final ack if we add them
[12:49] <mhr3> and isgd
[12:49] <didrocks> crazy we can't have one single list of scopes we want by default
[12:49] <mhr3> didrocks, k
[12:49] <didrocks> and it's changing everyday
[12:49] <didrocks> I asked clearly for the list on Tuesday… :/
[12:49] <mhr3> i think that's what he's been asking us for yesterday and today :)
[12:55] <didrocks> pstolowski: bash: /tmp/buildd/unity-scope-home-6.8.0/tests/fake-server/fake-sss-server.py: /usr/bin/python: bad interpreter: No such file or directory
[12:55] <didrocks> pstolowski: yeah, python is not installed
[12:55] <didrocks> it needs to build-dep on it
[12:55] <didrocks> mmrazik: are your upstream merger installing python? ^
[12:55] <didrocks> mmrazik: it should have failed there as well
[12:55] <mmrazik> didrocks: we do :-/ We need it for gcovr :-/
[12:55] <mmrazik> i.e. coverage
[12:56] <didrocks> mmrazik: but coverage is ran even once you merge?
[12:56] <mmrazik> python is one of the very few additional deps we have
[12:56] <didrocks> pstolowski: all tests are passing
[12:56] <didrocks> mmrazik: sufficient to screw us ;-)
[12:56] <didrocks> pstolowski: I'm proposing a branch, one sec
[12:56] <mmrazik> didrocks: yes, as the autolanding job then gives you the time-history (the pre-merge is fairly random)
[12:56] <pstolowski> didrocks: awesome, thanks
[12:58] <didrocks> pstolowski: https://code.launchpad.net/~didrocks/unity-scope-home/add-python-dep/+merge/153547
[13:09] <mmrazik> didrocks: unity-scope-home_6.8.0-0ubuntu2bzr60pkg0raring3_amd64.deb is in the local repo
[13:09] <didrocks> mmrazik: great! :-)
[13:49] <didrocks> pstolowski: mhr3: home scope built from the ppa
[13:49] <didrocks> pstolowski: mhr3: video and music scopes building
[14:00] <MacSlow> mzanetti, so these Q_SOMETHING are pure c++-preprocessor syntactic sugar more or less
[14:00] <MacSlow> ?!
[14:01] <mzanetti> MacSlow: yes, rather more then less. Those were all there in the early Qt days already when noone even immagined QML yet
[14:02] <mzanetti> MacSlow: however, QML of course makes use of them... if you have a C++/Qt slot (which is nothing else then a invokable method) then you can invoke that also from QML
[14:02] <MacSlow> mzanetti, I'll have to work through the "extending QML with C++" anyway now... then my mental image will become clearer
[14:02] <mzanetti> MacSlow: I'd recommend to completely read the QObject doc. Even though its C++ only all of it applies to QML too
[14:04] <mzanetti> MacSlow: especially the parenting mechanism and signal/slot invokation are really a must-know for anything Qt
[14:06] <MacSlow> mzanetti, btw "slot" meaning "signal-callback" iirc
[14:07] <mzanetti> MacSlow: the moc code holds a table of invokable (by method name as a string) methods. Declaring a method as slot or Q_INVOKABLE causes it to be in there.
[14:07] <mzanetti> MacSlow: the table basically holds the name as a string and a function pointer to it
[14:08] <mzanetti> MacSlow: then there is a second table that holds all signals. in your C++ code you just declare signals, don't implement its functionality and can "emit methodName()" them
[14:08] <mzanetti> the content of them will be autogenerated in the moc object
[14:08] <mzanetti> then there is a 3rd table which holds signal/slot connections
[14:09] <MacSlow> mzanetti, got it thx
[14:09] <mhr3> didrocks, cool, i was about to ping you about those once i fix music
[14:09] <mhr3> ...which didn't happen yet :P
[14:09] <mzanetti> when you write "emit someSignal()" the generated signal code will walk through the connection table and invoke the connected slots
[14:10] <MacSlow> mzanetti, so my "translation" is basically correct... just helpful for moving mindset from glib to qt
[14:11] <mzanetti> MacSlow: yeah.. while moving your mindset, move away from the callback pattern altogether :D
[14:12] <mzanetti> it sucks and is not Qt'ish
[14:12] <mzanetti> :D
[14:12] <kgunn> MacSlow: mzanetti : i was thinking about this yesterday as well....found this http://qt-project.org/wiki/Connect_a_complex_signal_from_QML_to_Qt
[14:12] <mzanetti> MacSlow: if you want to talk in design patterns, think of it more like a observer instead of a callback notifier
[14:13] <MacSlow> mzanetti, I see
[14:14] <MacSlow> kgunn, thx
[14:14] <seb128> sil2100, got another round of quantal's unity ppa fail to build spams...
[14:14] <kgunn> MacSlow: i'm totally new to it as well :)
[14:15] <mzanetti> kgunn: MacSlow: hehe... well get you up and running soon
[14:15] <mzanetti> we will
[14:15] <MacSlow> kgunn, it the thing were you read once about certain patterns... and then for a looong time never came across the need to actually use them... until the need actually does show up :)
[14:16] <sil2100> seb128: ;/ I'll ping Francis to disable quantal builds
[14:16] <sil2100> Since it makes no sense
[14:17] <MacSlow> mzanetti, the fundamentals for drawing/rendering with QML an Qt I've sorted... the boilerplate and connecting-the-dots is up next
[14:17] <mzanetti> kgunn: regarding the link you posted. this works, but usually its cleaner to export the whole object to the QML context and just call its slots like regular function calls.
[14:18] <mzanetti> kgunn: if you start manually connecting each signal/slot between Qt and QML you'll end up in chaos soon
[14:18] <seb128> sil2100, thanks
[14:19] <kgunn> mzanetti: got it...
[14:20] <MacSlow> mzanetti, so one tries to keep as much on QML-side as possible
[14:20] <mzanetti> MacSlow: not really... I prefer keeping as much as possible in C++ and really only to the painting in QML
[14:20] <mzanetti> MacSlow: that said, opinions may differ on this
[14:21] <mzanetti> MacSlow: I for one think QML is awesome to paint on the screen, but javascript sucks to implement logic
[14:21] <MacSlow> mzanetti, hm... I guess that's a preference I still have to develop as I learn
[14:22] <MacSlow> mzanetti, although my guts tell me something similar... C++ is code... JavaScript is... *cough* ;)
[14:22] <mzanetti> MacSlow: +1
[14:38] <mterry> didrocks, what is the PPA we're using for the phablet autobuilding stuff?
[14:57] <didrocks> mterry: we don't use a PPA yet for dailies (as it's not bootstrapped)
[15:03] <mterry> didrocks, but we want to get bootstrapped.  Do we have a planned PPA?  (I guess my question is, how close are we to being able to bootstrap a package for raring?)
[15:03] <didrocks> mterry: I would use the experimental ppa for this
[15:03] <didrocks> mterry: https://launchpad.net/~ubuntu-unity/+archive/experimental-prevalidation
[15:03] <didrocks> as those are new components
[15:03] <didrocks> just use that one
[15:03] <mterry> didrocks, heh, maybe throw -donotuse on the end too for good measure
[15:04] <didrocks> You shouldn't run this ppa.
[15:04] <didrocks> in the description :p
[15:04] <didrocks> mterry: can you coordinate with steve about the platform packages?
[15:04] <didrocks> like qtubuntu or platform api
[15:04] <didrocks> mterry: sorry, I'm burried on the 100 scopes stuff
[15:04] <mterry> didrocks, I ask because I have a few components to get autolanding, but wasn't sure if we could start actually enabling them once I cleaned up packaging
[15:04] <didrocks> mterry: if you can track that, it will be of great help!
[15:04] <mterry> didrocks, OK
[15:05] <didrocks> mterry: oh, they do work? you don't depends on platform api and so on?
[15:05] <didrocks> mterry: yeah, we should start creating the experimental stack
[15:05] <mterry> didrocks, well that's another problem too  :)
[15:05] <didrocks> mterry: right, hence the "ping steve" :-)
[15:05] <mterry> yup
[15:05] <didrocks> thanks a million!
[15:05] <didrocks> if not a bazillion :p
[15:08] <sil2100> fginther: ping!
[15:14] <fginther> sil2100, yo!
[15:24] <sil2100> fginther: could you maybe disable unity staging auto-landing? Or at least disable it for quantal?
[15:27] <fginther> sil2100, I should be able to do that
[15:28] <sil2100> Since unity trunk won't build on quantal anymore sadly, and it indeed is spamming us full with e-mails
[15:30] <fginther> sil2100, done :-)
[15:31] <didrocks> fginther: even raring? \o/
[15:32] <fginther> didrocks, I knew you were going to ask that :-) It's still high on my todo list
[15:32] <didrocks> :)
[15:32] <didrocks> fginther: I got a 30 minutes discussions with webops this morning because of that btw
[15:32] <didrocks> fginther: they are really eager for us to remove it
[15:33] <fginther> didrocks, I guess we can make things a little better by removing quantal from all the staging projects
[15:33] <fginther> didrocks, a quick fix
[15:36] <mzanetti> mterry: autopilot tests should now be totally robust even on slow systems
[15:37] <mzanetti> mterry: if they still fail for you its something else I guess
[15:38] <mterry> mzanetti, will try again
[15:39] <mterry> mzanetti, using your phablet-fix-autopilot branch?
[15:39] <mzanetti> mterry: that should kill the very last issues. whats currently in trunk should be 90% stable
[15:44] <didrocks> fginther: ok, I can't wait for you to kill staging at least for where we have daily releases!
[15:47] <bregma> if i bump Unity to 7.0.0, does debian/changelog need to have the 7.0.0daily13.03.15.1-0ubuntu1 format, or will he autolander work with 7.0.0-0ubuntu1 and add its own cruft just fine?  Will the autolander diddle inappropriately with the upstream version like it does elsewhere?
[15:48] <fginther> didrocks, moved to top of stack
[15:49] <didrocks> \o/
[15:49]  * didrocks loves stack
[15:49] <didrocks> bregma: please don't do that with the 100 scope projects
[15:49] <didrocks> bregma: or remerge the 100 scope branch with it
[15:50] <didrocks> bregma: but it's already difficult to track those parallel changes, so don't add complexity
[15:50] <didrocks> bregma: the answer to your question is https://wiki.ubuntu.com/DailyRelease/FAQ :)
[15:50] <didrocks> btw :p
[15:50] <didrocks> (bumping the changelog to 7.0.0-0ubuntu1)
[15:50] <didrocks> bregma: no path change, no asset missing?
[16:20] <seb128> didrocks, https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1155684 btw
[16:21] <didrocks> confirmed
[16:21] <didrocks> bribe someone now
[16:22] <didrocks> ;)
[16:27] <popey> using the snappy named unity-scope-chromiumbookmarks-0.1daily13.03.15.1ubuntu.unity.experimental.certified.. it's hard wired to search /.config/chromium/Default/Bookmarks - which is okay if you only use one profile. no good if you have more than one...
[16:28] <popey> in fact I dont seem to get any results from it even if I search for stuff that is in the default profile
[16:46] <didrocks> bregma: I wonder if we shouldn't bump unity to 7 with this 100 scope features
[16:46] <didrocks> bregma: it seems people want that :p
[16:48] <bregma> (1) bump package to 7.0.0 (2) merge 100 scopes (3) branch for raring, with post-raring development on head
[16:48] <didrocks> bregma: I meant
[16:48] <didrocks> in the 100 scopes branch, bump package to 7.0.0
[16:48] <didrocks> and then, one we release that, yeah, branch for raring
[16:48] <didrocks> bregma: wdyt? ^
[16:50] <bregma> I don;t think the order of the first two matter so much, as long as it's done and we branch before raring release
[16:50] <bregma> the advantage of bumping to 7.0 first is it makes reverting slightly, but only very slightly, easier
[16:51] <didrocks> bregma: yeah, but people are expecting "next unity" to be the smart scope one
[16:51] <didrocks> bregma: just a question of marketing :p
[16:51] <bregma> the advantage of bumping after is that downstreams can get the 100 scopes easier, and yes there are downstreams
[16:51] <didrocks> and no, bumping 7.0 first is making is harder in fact as we have to merge back to 100 ;)
[16:52] <didrocks> bregma: I'm afraid about the confusion, just that
[16:52] <bregma> so with the 100 scopes, you've forked the codebase and you're going to merge upstream into the fork, or what?
[16:53] <didrocks> "you" is not me :)
[16:53] <didrocks> it's a feature branch
[16:53] <didrocks> and no
[16:53] <didrocks> it will be the other way around
[16:53] <bregma> feature branches should be merged into trunk and not the other way around
[16:53] <didrocks> the feature branch will be merged back in trunk
[16:53] <didrocks> that's what I meant
[16:53] <didrocks> did I say the contrary?
[16:54] <bregma> if we have to merge 7.0 back to 100, that's merging trunk to the branch
[16:54] <didrocks> bregma: it's resynchronizing the feature branch with trunk
[16:54] <didrocks> if you don't do that
[16:54] <didrocks> and bump the version in distro
[16:54] <didrocks> and not in the ppa
[16:54] <didrocks> how will people test unity in the ppa?
[16:54] <didrocks> the version in the distro will have a higher version
[16:56] <bregma> OK, I see
[16:56] <didrocks> bregma: but the finale move, will be in case:
[16:56] <didrocks> bzr branch trunk
[16:56] <didrocks> bzr branch feature
[16:56] <didrocks> cd trunk
[16:56] <didrocks> bzr merge ../feature
[16:56] <didrocks> bzr commit
[16:56] <didrocks> bzr push
[16:56] <didrocks> in some way :)
[16:57] <didrocks> in any* case
[16:57] <didrocks> it's just that it's good to resync the "feature branch" on trunk sometimes
[16:57] <didrocks> so that code doesn't diverge
[16:58] <bregma> so from an upstream (me) point of view, the merge order doesn't matter but from a distro point of view (you) it's important
[16:59] <bregma> so let's plan to bump to 7.0 after the 100 merges
[16:59] <didrocks> bregma: sounds good to me ;)
[16:59] <didrocks> bregma: yeah, it's because are testing it
[16:59] <didrocks> bregma: btw, did you try it? there is no asset-path based?
[16:59] <bregma> I'm still verifying my bump change doesn't break anything unexpected (rebuilding and installing is slow on my local network)
[16:59] <didrocks> sure :)
[17:00] <didrocks> thanks bregma
[17:00] <didrocks> bregma: look at the asset in the dash in particular
[17:00] <bregma> do we have a schedule for when the 100 scopes will be merged?
[17:00] <didrocks> bregma: that's those in a versionned path IIRC
[17:00] <didrocks> bregma: the 25th
[17:01] <bregma> mkay
[17:04] <gusch> Cimi: I broke the loop https://code.launchpad.net/~unity-team/unity/phablet-people-delegate-loader/+merge/152944
[17:06] <dandrader> mzanetti, I need you to check this https://code.launchpad.net/~dandrader/unity/phablet_tst_FilterGrid/+merge/153599
[17:06] <mzanetti> dandrader: ack
[17:06] <dandrader> as I've reorganized the way qmluitests are executed
[17:07] <dandrader> this might have to consequences on the CI machinery
[17:07] <dandrader> s/to/some
[17:09] <mzanetti> dandrader: not totally happy with it
[17:09] <mzanetti> dandrader: its too much efforts to add a new test this way imho
[17:09] <dandrader> mzanetti, but how do I solve the import of conflicting plugins?
[17:10] <mzanetti> dandrader: can you create a method like add_qml_test(target qmlfile importargs)
[17:10] <mzanetti> dandrader: so that someone adding a test just adds that one line
[17:11] <dandrader> mzanetti, sounds good. I'll try that
[17:11] <mzanetti> and that one executes the add_custom_target, adds it to the depends and whatnot
[17:12] <mzanetti> dandrader: the rest looks great. Should I be worried that you deleted the delegate? without investigating I could immagine its used somewhere
[17:13] <mzanetti> dandrader: like the apps grid or home grid maybe
[17:13] <dandrader> mzanetti, all uses of this component provide their own delegate
[17:14] <mzanetti> dandrader: ok. fine then. just wanted to make sure you have checked it
[17:14] <mzanetti> :)
[17:14] <dandrader> mzanetti, ensuring sanity :)
[17:17] <didrocks> mhr3: to handle the shopping lens transition: https://code.launchpad.net/~didrocks/unity-scope-home/replace-shopping/+merge/153602
[17:18] <didrocks> mmrazik: I think issues like that one should have integration tests (hint hint, maybe time to build on that? ;)) https://code.launchpad.net/~mzanetti/autopilot-qt/workaround-xpathselect/+merge/153544
[17:18] <didrocks> cyphermox: FYI ^
[17:19] <mzanetti> didrocks: yes. I agree
[17:20] <mmrazik> didrocks: I know :-/ I was talking about exactly the same with om26er this morning.
[17:20] <mmrazik> didrocks: autopilot actually works (existing tests). Its vis that is broken (thus hard to write new tests)
[17:20] <dandrader> mzanetti, another thing: will the CI scripts check all .xml files (with test results) in the root build dir? Or does it check for specific filenames?
[17:21] <didrocks> mmrazik: ah, ok
[17:21] <mmrazik> dandrader: it checks for *test*.xml (recursively in all dirs IIRC)
[17:21] <mzanetti> mmrazik: didrocks: I think the very first thing is to clean up the libxpathselect mess
[17:21] <dandrader> mmrazik, ah, good
[17:21] <mzanetti> the whole autopilot/ppa is quite a mess right now imho
[17:22] <didrocks> mzanetti: I agree
[17:22] <mmrazik> dandrader: find . -name '*test*.xml' -exec cp '{}' "$RESULT_DIR" \;
[17:27] <didrocks> cyphermox: mterry: btw, no luck in releasing the stacks? we have some in manual upload mode because of packaging changes, other where we need to know why UTAH is failing…
[17:27] <didrocks> some to relaunch because lp:indicator-bluetooth wasn't correctly set?
[17:28]  * didrocks sees at les oif, qa, webapps
[17:28] <didrocks> kenvandine:  ^
[17:28] <didrocks> least*
[17:28] <mzanetti> tsdgeos: can you re-review: https://code.launchpad.net/~mzanetti/autopilot/faqs/+merge/152864
[17:29] <kenvandine> didrocks, i won't be able to look at it until after my sdk session
[17:29] <didrocks> kenvandine: sure, (webapps is blocked for some days though ;))
[17:29] <kenvandine> days... feels like i just looked at that!
[17:30] <kenvandine> i suck at watching web pages :)
[17:30] <kenvandine> didrocks, i'll work on getting that into my routine first thing in the morning :)
[17:30] <didrocks> kenvandine: do you know what we can do for making that better?
[17:30] <didrocks> I think as told the other day mails are not an option
[17:31] <didrocks> should we have an indicator?
[17:31] <didrocks> or something like that?
[17:31] <didrocks> kenvandine: I'm opened to any suggestion :)
[17:32] <mterry> didrocks, the past two runs of the unity stack failed due to an xorg crash, which I haven't been able to get bryce or RAOF to look at yet
[17:32] <mterry> didrocks, actually the the past two but one.  The latest run had too many nvidia failures
[17:32] <didrocks> mterry: thanks for the info, so I guess the indicator issue on nvidia is the same?
[17:33] <mterry> sil2100, any guesses on the recent nvidia issues?  http://10.97.0.1:8080/job/ps-unity-autopilot-release-testing/label=autopilot-nvidia/116/testReport/
[17:33] <mterry> didrocks, probably?  The xorg crashes were nvidia too
[17:33] <didrocks> yeah
[17:33] <didrocks> thanks mterry, wasn't sure it was looked at :-)
[17:33] <didrocks> mterry: can you check with cyphermox about the QA/OIF?
[17:33] <mterry> didrocks, the xorg crash actually seems to have stack symbols, which is suprising
[17:33] <mterry> didrocks, but not sure there's anything we can do, being nvidia and all
[17:33] <didrocks> mterry: really? no no no, I don't believe you now! :)
[17:34] <didrocks> yeah :/
[17:34] <sil2100> Looking!
[17:35] <mterry> sil2100, oh!  that's not just nvidia, but across the board
[17:35] <mhr3> didrocks, btw did you notice we're installing some scopes by default for apps that aren't installed by default?
[17:35] <didrocks> mhr3: yeah, I think that's fine
[17:35] <didrocks> mhr3: it's like "the hooks are there"
[17:35] <mhr3> is it?
[17:35] <didrocks> isn't it?
[17:35] <didrocks> mhr3: the scope doesn't depends on the app
[17:36] <didrocks> so I guess/hope the code is design to only try to fetch the info if the app is installed
[17:36] <mhr3> but the master scopes might run them
[17:36] <didrocks> right, but the app is not there
[17:36] <mhr3> like music master scope will query all music scopes
[17:36] <sil2100> I'll just finish building something, since I need to restart my session
[17:36] <didrocks> so as long as the scope doesn't crash if the app is not installed…
[17:36] <mhr3> which will spawn all the useless python processes
[17:37] <didrocks> mhr3: yeah, maybe the scope should declare what it deps on
[17:37] <didrocks> mhr3: and the smart scope should be smarter :p
[17:37] <didrocks> mhr3: but I don't think this is for this cycle
[17:37] <didrocks> I heared you are a little bit busy :)
[17:47] <Cimi> gusch, can you test it on the tablet?
[17:47] <Cimi> does it work?
[17:47] <gusch> Cimi: ok - one sec
[17:50] <gusch> Cimi: it shows the logo - do we have the posting time in the data?
[17:52] <Cimi> mmm
[17:52] <Cimi> gusch, the delegate supports it
[17:53] <gusch> Cimi: I'll check the old delegate again
[17:54] <Cimi> gusch, but not the lens
[17:54] <Cimi> gusch, data doesn't arrive
[17:54] <gusch> Cimi: yes - old looks the same
[17:58] <gusch> mzanetti: wow - what happened here? https://jenkins.qa.ubuntu.com/job/unity-phablet-quantal-armhf-ci/42/console
[18:01] <cyphermox> mterry: sorry I was out, yeah, I'll finish up oif/qa/indicators, I think indicator-bluetooth should be good to rerun now
[18:02] <Cimi> gusch, I'll approve when jenkins won't complain :)
[18:03] <gusch> Cimi: well you could approve anyway - but ok
[18:04] <gusch> Cimi: any idea what went wrong? Some Libs missing?!?
[18:06] <Cimi> gusch, I didn't look :)
[18:06] <gusch> Cimi: I guess I need the help of an QA guy - mzanetti mmrazik ? https://jenkins.qa.ubuntu.com/job/unity-phablet-quantal-armhf-ci/42/console
[18:07] <mzanetti> gusch: I'm checking...
[18:07] <gusch> mzanetti: thx
[18:07] <mmrazik> mzanetti: isn't it the thing where Saviq has a fix in another branch?
[18:07] <mzanetti> mmrazik: ah.. right...
[18:07] <Saviq> gusch, mzanetti, yes
[18:07] <mzanetti> I saw a comment somewhere. one sec
[18:08] <Saviq> mzanetti, gusch https://code.launchpad.net/~unity-team/unity/phablet.release-162/+merge/153578 needs to merge
[18:08] <Saviq> (should be some 5 mins yet)
[18:17] <gusch> Cimi: I submited again with the other branch as prerequisite https://code.launchpad.net/~unity-team/unity/phablet-people-delegate-loader/+merge/153612
[19:02] <gusch> mzanetti: still problems on intel https://code.launchpad.net/~unity-team/unity/phablet-people-delegate-loader/+merge/153612
[19:03] <dandrader> mzanetti, done. added a macro called add_qml_test() (https://code.launchpad.net/~dandrader/unity/phablet_tst_FilterGrid/+merge/153599)
[19:07] <mzanetti> gusch: I think it just needs to be propagated through the ppa
[19:08] <mzanetti> dandrader: awesome
[19:08] <gusch> mzanetti: hmm - ok  - but I can't restart on that jenkins server
[19:08] <mzanetti> gusch: I'll do
[19:09] <gusch> mzanetti: thx
[19:11] <mzanetti> gusch: there are 5 in the build queue... Saviq just started all failing ones again
[19:11] <Saviq> mzanetti, gusch yeah, they should've worked already, the last one only failed on i386 for some reason
[19:13] <Saviq> mzanetti, gusch, we only have one armhf builder now, though :/
[19:21] <Saviq> mterry, please wait for jenkins to vote Approve on MRs before top-approving
[19:22] <mterry> Saviq, I top-approved to poke jenkins to re-test
[19:22] <Saviq> mterry, top-approve means it will try and merge, won't run all the CI
[19:23] <Saviq> mterry, I retriggered the CI jobs anyway
[19:23] <gusch> ok bye - have a nice weekend
[19:23] <Saviq> gusch, you too
[19:24] <mterry> Saviq, that's not how I've believed it works.  Can I get a sanity second opinion?  - my understanding is top-approval when jenkins has most recently rejected the branch will still wait for a jenkins approval, and kick jenkins to do so
[19:24] <Saviq> mterry, nope, there's two jobs - -autolanding and -ci
[19:24] <Saviq> mterry, -autolanding doesn't wait for a -ci vote
[19:25] <Saviq> mterry, -ci will be triggered by new merge request or new commits in the to-be-merged branch
[19:25] <Saviq> mterry, or manually of course, via the link on the comments
[19:26] <Saviq> mterry, -autolanding will be triggered as soon as a merge request is top-approved
[19:26] <mterry> (which doesn't work, last I talked to fginther)
[19:26] <Saviq> yeah, you need to go to the private instance, unfortunately
[19:27] <mterry> Saviq, oh.  so wait.  What did I do wrong then?  -ci already approved.  -autolanding failed because of a transient error.  I was re-approving to kick -autolanding
[19:27] <Saviq> mterry, yeah, in that case I re-trigger CI before top-approving
[19:28] <Saviq> 'cause the transient error might have impacted what CI does, but not what autolanding does
[19:28] <mterry> Saviq, I guess I'm confused on that point.
[19:29] <mterry> Saviq, there were no code changes, so I'm not sure what -ci would do differently (I mean, trunk has changed...)
[19:29] <mterry> but that's a race condition regardless
[19:29] <mterry> which I imagine is what -autolanding is for
[19:30] <Saviq> mterry, at least IIUC, CI can run more tests than -autolanding
[19:30] <Saviq> mzanetti, unless you can clear me on the above ^?
[19:30] <mterry> Saviq, sure...  but -ci already approved the branch
[19:31] <mterry> Saviq, you seem to be saying that when -autolanding fails, always re-run both for safety's sake?
[19:31] <Saviq> mterry, yeah, but there was a problem with autolanding - some dependencies changed in that instance
[19:31] <Saviq> mterry, I just like to see green in the votes table before top-approving
[19:32] <Saviq> mterry, and yeah, re-run CI to see if everything's back to normal - only then top-approve again
[19:32] <mterry> Saviq, and to restart -autolanding without top-approving, I would need to poke someone?
[19:32] <Saviq> mterry, no, restart just -ci
[19:32] <mterry> Or you're saying, restart -ci by poke, then top-approve?
[19:32] <Saviq> yes
[19:33] <Saviq> autolanding will fail anyway if there's no top-approve
[19:33] <mterry> OK...  I guess I'm still a little unclear on when one knows to restart -ci, but will try your suggestion of "always"
[19:33] <Saviq> mterry, yeah, if there's "Needs fixing" from Jenkins - investigate and re-trigger, always :)
[19:33] <Saviq> only then top-approve
[19:34] <mterry> Saviq, sure, but the needs-fixing was from -autoland, not -ci
[19:34] <mterry> they both use the same continuous-integration review tag
[19:35] <Saviq> mterry, but the failure comment shows what failed
[19:35] <Saviq> anyway, it's Approved now from -ci anyway ;)
[19:35] <Saviq> -anyway
[19:36] <mterry> yar, just top-approved again
[19:37] <mterry> Saviq, sorry anyway, was trying to be helpful  :)
[19:37] <Saviq> mterry, that's fine
[19:38] <mterry> Saviq, if it's "bad" to top-approve without a more recent -ci run, can we disallow skipping that?  (I mean, have a top-approval with a failed -autolanding trigger both -ci and -autolanding instead of just -autolanding)
[19:38] <mterry> Seems dangerous to have developers accidentally skipping safety protocols
[19:38] <Saviq> mterry, good question, we could make sure all votes are "Approve" before autolanding
[19:39] <Saviq> or at least that Jenkins's vote is Approve, will raise that with QA next week