[07:03] <MacSlow> veebers, ping
[07:14] <mzanetti> Saviq: morning
[07:14] <mzanetti> Saviq: hey, I did a dist-upgrade and autoremove and now my GLX extension doesn't work any more.
[07:15] <mzanetti> do you know which packages I need (or which I must remove) in order to get it back on an an intel-chip?
[07:19] <MacSlow> mzanetti, should be xserver-xorg-core
[07:19] <MacSlow> mzanetti, that's what "dpkg -S /usr/lib/xorg/modules/extensions/libglx.so" is telling me here on my all-intel laptop
[07:19] <mzanetti> MacSlow: no... I'm only missing the GLX extension, not the whole x server
[07:20] <mzanetti> MacSlow: yeah... I have this lib
[07:20] <mzanetti> still, glxinfo says this: Xlib:  extension "GLX" missing on display ":1".
[07:20] <mzanetti> the same does any qml2 app
[07:21] <mzanetti> weird thing is, I think the glx module tries to load the nvidia chip even though it should use the intel one
[07:21] <mzanetti> and all howtos regarding bumblebee or vga_switcheroo just don't work
[07:21] <MacSlow> mzanetti, Optimus-based system?
[07:21] <mzanetti> MacSlow: no clue what optimus is, but yeah, have a nvidia and a intel chip
[07:21] <Saviq> mzanetti, there's an update-alternatives for this I think
[07:22] <Saviq> mzanetti, OTOH my Skype fails no finding libGL.so.1 since yesterday, too
[07:24] <MacSlow> Saviq, since yesterday apt wanted to remove unity and ubuntu-desktop... which I managed to avoid... but now libunityshell.so keeps segfaulting
[07:25] <Saviq> mzanetti, $ update-alternatives --list x86_64-linux-gnu_gl_conf ?
[07:25] <mzanetti> Saviq:
[07:25] <mzanetti> /usr/lib/nvidia-304-updates/ld.so.conf
[07:25] <mzanetti> /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf
[07:25] <mzanetti> Saviq: I just switched it over to the mesa one
[07:25]  * mzanetti reboots
[07:25] <mzanetti> brb
[07:26] <Saviq> MacSlow, libunityshell.so is the unity compiz plugin/
[07:26] <Saviq> ?
[07:26]  * Saviq tries to upgrade
[07:26] <MacSlow> Saviq, I know
[07:26] <Saviq> MacSlow, that was a question, not a statement ;)
[07:27] <MacSlow> Saviq, just saying... since yesterday some odd things happen with regards to the package-db :)
[07:27] <Saviq> MacSlow, apt-cache policy unity? says 7.0.1+13.10.20130703-0ubuntu1
[07:27] <Saviq> MacSlow, nothing weird here
[07:27] <paulliu> Saviq: Please help reviewing? https://code.launchpad.net/~paulliu/unity8/activate3/+merge/173071
[07:28] <Saviq> paulliu, yes, I saw it, it's in my queue if no one else gets onto it
[07:28] <paulliu> Saviq: ok.. thanks.
[07:28] <Saviq> paulliu, although if you can get someone else to review, probably gonna be quicker
[07:28] <paulliu> Saviq: ok.
[07:29] <mzanetti> nope :/
[07:29] <mzanetti> funny thing is, starting unity8 I get Xlib:  extension "NV-GLX" missing on display ":1".
[07:29] <mzanetti> now that I switched it FROM nvidia TO mesa
[07:34] <MacSlow> to any autopilot-experts... I keep getting http://pastebin.ubuntu.com/5845923
[07:38] <Saviq> mzanetti, ldconfig -p | grep libGL?
[07:38] <mzanetti> http://paste.kde.org/789530
[07:38] <Saviq> mzanetti, you might need to `sudo ldconfig` to update the ld database
[07:38] <mzanetti> Saviq: ^
[07:38] <Saviq> mzanetti, yeah, still finds the nvidia one
[07:39] <Saviq> mzanetti, you want to switch i386_, too
[07:39] <mzanetti> Saviq: right....I did the sudo ldconfig and its gone now
[07:39] <mzanetti> Saviq: huh? i386?
[07:39] <Saviq> mzanetti, libGL.so (libc6) => /usr/lib32/nvidia-304-updates/libGL.so
[07:39] <mzanetti> Saviq: ah... that line is gone after the sudo ldconfig
[07:40] <Saviq> mzanetti, gone completely?
[07:40] <mzanetti> http://paste.kde.org/789536
[07:40] <Saviq> mzanetti, or just linking to the mesa ones?
[07:40] <mzanetti> Saviq: gone completely
[07:40] <Saviq> ok yeah, that looks good if you don't want i386
[07:40] <Saviq> mzanetti, should be good now, I'd sa
[07:40] <Saviq> y
[07:40] <mzanetti> ok... bbiab
[07:46] <veebers> MacSlow: Pong, re: your paste bin it looks like you're missing: python-ubuntu-platform-api,
[07:47] <veebers> MacSlow: although that gobject error is a new one for me at this stage
[07:47] <MacSlow> veebers the odd thing is... I don't have that package at all... and a fresh checkout of unity8 does work with all autopilot-tests... so python-ubuntu-platform-api is not needed apparently
[07:47] <veebers> MacSlow: odd
[07:48] <mzanetti> Saviq: better... Now all desktop effects like wobbly windows etc work again, but when they are enabled, the panels and context menus stay black :/
[07:48] <MacSlow> veebers, just when I use self.touch = Touch.create() in my own code I start getting this failure
[07:48] <Saviq> mzanetti, man, what did you do
[07:48] <Saviq> mzanetti, to get to that state? :)
[07:49] <mzanetti> Saviq: I had this state already when I initially installed ubuntu
[07:49] <MacSlow> veebers, and then all other autopilot-test also keep failing
[07:49] <veebers> MacSlow: but the unity8 tests run fine?
[07:49] <Saviq> mzanetti, ah, do you have optimus enabled, then?
[07:49] <mzanetti> Saviq: and I just used XRender in Sept and Oct
[07:49] <mzanetti> didn't need QtQuick 2.0 back then
[07:49] <Saviq> mzanetti, i.e. do you use the nVidia chip or the Intel one?
[07:49] <mzanetti> Saviq: at some point xrender usage became crashy and I tried openGL. worked fine as of then
[07:49] <mzanetti> Saviq: I want only the intel one
[07:50] <MacSlow> veebers, not after I ran my own test... even just selecting one of the other unity8 autopilot-tests has them failing then
[07:50] <Saviq> mzanetti, you need to enable Optimus in the BIOS then
[07:50] <mzanetti> Saviq: whats a bios? :P
[07:50] <Saviq> mzanetti, ;)
[07:50] <mzanetti> no need for that legacy shit
[07:50] <Saviq> mzanetti, what do you call it now? ;)
[07:50] <Saviq> mzanetti, system setup?
[07:51] <mzanetti> Saviq: I have an EFI loader. thats it
[07:51] <MacSlow> veebers, I'm wondering where autopilot maybe writes something to a cache-file in the unity8 directory that could cause this... because  a fresh checkout of unity8 makes the tests there work again
[07:51] <veebers> MacSlow: This is on your desktop?
[07:51] <Saviq> mzanetti, that's different
[07:51] <MacSlow> veebers, desktop yes
[07:51] <Saviq> mzanetti, I mean the thing where you set up your hardware
[07:51] <Saviq> F2 or something
[07:51] <mzanetti> Saviq: don't have that
[07:51] <mzanetti> its a mac
[07:51] <Saviq> mzanetti, uh, right
[07:51] <veebers> MacSlow: no, autopilot shouldn't write any cache file like that
[07:52] <Saviq> mzanetti, and you do have two GPUs there?
[07:52] <mzanetti> Saviq: yep
[07:52] <veebers> MacSlow: you're on saucy and you've updated recently? (just trying to narrow down possibilities)
[07:52] <Saviq> mzanetti, well, it's probably enabled then :)
[07:52] <MacSlow> veebers, yes... on a saucy system...
[07:52] <mzanetti> Saviq: in Archlinux vga_switcheroo somewhat worked to power down the nvidia one
[07:52] <mzanetti> Saviq: never managed to get that working in ubuntu
[07:53] <MacSlow> veebers, pulling updates (in the hope to fix this by updating packages, since I'm not sure about the cause of the failure) messed up my unity on my main machine... still got the laptpo
[07:53] <mzanetti> Saviq: oh... and our build -s miserably fails if you don't have qt libs installed
[07:53] <mzanetti> so does just ./build
[07:54] <Saviq> mzanetti, suggests we're missing deps
[07:54] <Saviq> mzanetti, but then we'd know
[07:54] <Saviq> mzanetti, as it wouldn't build on jenkins
[07:54] <mzanetti> yeah... well. let me check more exactly
[07:54] <Saviq> mzanetti, ./build -c
[07:55] <mzanetti> Saviq: ah... damn it...
[07:55] <mzanetti> Saviq: yeah... ofc
[07:55] <Saviq> mzanetti, it only installs the build deps if builddir/unity8-build-deps*deb is older than debian/control
[07:55] <Saviq> or doesn't exist
[07:56]  * mzanetti wonders why ./build wants to install nvidia-current-updates
[07:58] <Saviq> mzanetti, libgl1-mesa-dev[!armhf] | libgl-dev[!armhf], probably
[07:58] <Saviq> mzanetti, but then you should be able to remove all nvidia things
[07:58] <MacSlow> veebers, I'll have to dig into this myself it seems.
[07:58] <Saviq> mzanetti, if you don't want to use it
[07:59] <mzanetti> Saviq: re what I did to get to this state: I got conflicts because I had some mesa lib from the mir ppa around.
[07:59] <Saviq> mzanetti, right
[07:59] <veebers> MacSlow: I'm just doing an update to see if I can reproduce
[07:59] <mzanetti> Saviq: installing the released version of that package removed my whole kde
[07:59] <Saviq> mzanetti, lol
[07:59] <mzanetti> Saviq: I did that, then dist-upgraded as I had like 500 outdated packages
[07:59] <mzanetti> Saviq: and then reinstalled kde
[08:03] <mzanetti> Saviq: FWIW, not only kde... it removed everything with a dependy to X
[08:03] <mzanetti> dependency
[08:04] <Saviq> mzanetti, I'd probably just rinse & reinstall
[08:04] <Saviq> that reminds me, I wanted to enable EFI on my laptop
[08:04] <greyback> Saviq: why, you water cooling your laptop now?
[08:05] <Saviq> greyback, no, I just switched away from nVidia ;P
[08:05] <Saviq> greyback, as it was the GPU that was overheating
[08:05] <Saviq> greyback, still need to call a Dell technician in to come and fix it
[08:05] <greyback> Saviq: ah really? Boo
[08:05] <Saviq> greyback, when did you last do that with your Mac?
[08:05] <greyback> Saviq: I haven't needed to, strangely enough
[08:06] <Saviq> greyback, you just throw away and buy a new one?
[08:06] <mzanetti> what, call a technician?
[08:06] <Saviq> mzanetti, I can't be bothered, I got 4yrs door-to-door warranty
[08:06] <Saviq> mzanetti, not even d-t-d
[08:06] <Saviq> mzanetti, next business day someone comes over and fixes it
[08:06] <mzanetti> I had to replace the main board 4 times at my previous one... He didn't come here to my place, but I could watch him while replacing it in his shop in the city center
[08:06] <Saviq> replacing the mobo, CPU< whatnot
[08:07] <mzanetti> but I opened and repaired my gf's macbook 3 days ago... display was flickering...
[08:07] <mzanetti> they're beautyful even on the inside :D
[08:08] <mzanetti> enough... need to get productive.. thanks Saviq for the libgl help
[08:08] <MacSlow> veebers, it has to be some side-effect with introducing pynotify to the autopilot-tests
[08:08] <MacSlow> veebers, again... did a fresh checkout and ran the test... all went fine...
[08:08] <Saviq> mzanetti, ;)
[08:09] <Saviq> mzanetti, it's Friday, it's not like you gonna do anything today anyway! :D
[08:09] <veebers> MacSlow: Interesting, the examples I linked you (that I put in the wrong place) worked fine with pynotify
[08:09] <MacSlow> veebers, I added the smallest bit of code to trigger a notification from it, it fails...
[08:09]  * Saviq wonders if I can use the efi partition for /boot
[08:09] <MacSlow> veebers, it's a combination of pynotify and the Touch class...
[08:10] <greyback> Saviq: think EFI has to be FAT{,32}
[08:10] <Saviq> greyback, yeah, problem?
[08:10] <MacSlow> veebers, if I don't to self.touch = Touch.create() it doesn't happen
[08:10] <Saviq> greyback, it's not like /boot is anything advanced
[08:10] <greyback> Saviq: no I suppose not
[08:10] <greyback> grub can read it
[08:13] <MacSlow> veebers, that... or removing all the pynotify-related code and getting rid of the .pyc and re-running test it'll work agian
[08:14] <veebers> MacSlow: can you do something for me, open a terminal and start ipython (or python) and try this: from autopilot.input._uinput import Touch
[08:14] <veebers> then Touch()
[08:15] <veebers> MacSlow: also, are you able to show or pastebin the test file that the error comes from?
[08:16] <Saviq> tsdgeos, I like your influence on our test count :D
[08:17] <tsdgeos> :)
[08:17] <MacSlow> veebers, http://pastebin.ubuntu.com/5845996 http://pastebin.ubuntu.com/5846005
[08:18] <Saviq> pstolowski, I don't like your influence on our coverage, though ;P
[08:19] <pstolowski> Saviq: mhm. where can I see it?
[08:19] <Saviq> pstolowski, http://s-jenkins:8080/job/unity8-autolanding/31/cobertura/
[08:19] <Saviq> pstolowski, that's when activation-and-previews merged
[08:20] <veebers> MacSlow: It's to do with the pynotify module
[08:20] <Saviq> pstolowski, hmm we're missing source code, though, for some reason
[08:21] <Saviq> pstolowski, but you can `make coverage` locally
[08:21] <Saviq> pstolowski, to build the html
[08:21] <Saviq> mzanetti, do you have ideas why we're still not seeing source code in our C++ coverage?
[08:21] <Saviq> mzanetti, http://s-jenkins:8080/job/unity8-autolanding/36/cobertura/plugins_Unity/genericpreview_h/
[08:22] <veebers> MacSlow: try this in ipython: from autopilot.input import Mouse, Touch, Pointer <\n> Touch.create() <\n (this works)> import pynotify <segfault>
[08:22] <MacSlow> veebers, I need this tough... I would not like to have use DBus directly with python just to fire some notifications
[08:22] <veebers> MacSlow: what's odd is that it seemed to work fine on the device when I was trying it out
[08:22] <mzanetti> Saviq: yeah... thing is, jenkins gets that from the work dir
[08:23] <mzanetti> Saviq: so 1st it only works in the qmluitests job
[08:23] <mzanetti> Saviq: and 2nd, it only works for the last build
[08:24] <mzanetti> Saviq: only way to improve that would be to modify the jenkins cobertura plugin to copy the work dir to some persistent place
[08:24] <nic-doffay> Cimi, did you have a look at my branch yet?
[08:24] <nic-doffay> Still got barely any idea about the styles.
[08:27] <pstolowski> Saviq: ok. we'll try to improve it with time. but let's not forget plugins/Unity area didn't have tests at all before that branch :P
[08:28] <MacSlow> veebers, just tried a very few calls (inside ipython) with plain dbus... that doesn't sefault...
[08:28] <Saviq> pstolowski, ;)
[08:28] <veebers> MacSlow: hmm, it seems to be some lowerlevel gobject <something> happening perhaps
[08:28] <MacSlow> veebers, this is not looking good... in terms of efficency...
[08:29] <Saviq> pstolowski, no worries, dednick will have even worse impact with https://jenkins.qa.ubuntu.com/job/unity8-ci/124/cobertura/? ;)
[08:29] <MacSlow> veebers, I'm not very fluent with plain dbus... even worse if it has to be in python.
[08:29] <Saviq> pstolowski, OTOH the Indicators plugin will get under your team jurisdiction soon enough, too :D
[08:30] <MacSlow> veebers, but I've to go that path as it seems unfortunately
[08:31] <pstolowski> Saviq: I didn't see that, you're breaking up :P
[08:31] <Saviq> lol
[08:32] <veebers> MacSlow: I think there might be a solution to this issue, I'm just having a quick explore
[08:32] <Saviq> pstolowski, it's ok, we've moved a lot of the functionality down to QML as compared to lp:indicators-client
[08:33] <MacSlow> veebers, that would be great, if there's a better/faster workaround... or even fix for it
[08:33] <Saviq> or up to QML?
[08:34] <Saviq> Cimi, btw, this was your issue with the background color, right https://bugreports.qt-project.org/browse/QTBUG-32238 ?
[08:35] <Saviq> Cimi, here's a dirty workaround FYI https://code.launchpad.net/~loic.molinari/ubuntu-ui-toolkit/ubuntu-ui-toolkit-ternary-op-color-fix/+merge/173072
[08:35] <MacSlow> veebers, btw... I wonder why pynotify even needs gtk+-2.x at all
[08:37] <veebers> MacSlow: I'm not sure at all. Just a though, I seem to recall that there is a standalone binary that you can use to generate a notification? (just as a stand in for right no, not needing to do raw dbus stuff)
[08:37] <MacSlow> veebers, you're talking about "notify-send"?!
[08:38] <veebers> MacSlow: that sounds like the one I was thinking of
[08:39] <MacSlow> veebers, hm... a bit clumsy... but could work... passing hints also works with that... code will look a bit ugly... but sure why not... giving it a try.
[08:39] <veebers> MacSlow: yeah I agree not the nicest, but it should allow you to get tests written now, and once we sort out this issue with pynotify we can swap out the subprocess calls
[08:42] <MacSlow> veebers, only callbacks (e.g. for interactive or snap-decisions) won't be covered by this
[08:45] <Saviq> ooh creepy, my maguro was always displaying just the empty-battery-charging animation...
[08:46] <Saviq> but `adb shell` took me straight to Ubuntu running inside :?
[08:46] <MacSlow> veebers, ok... I just verified that using os.system() with notify-send works
[08:48] <veebers> MacSlow: sweet, although I would probably use: http://docs.python.org/2/library/subprocess.html
[08:48] <mzanetti> tsdgeos: ping
[08:48] <MCR_> smspillaz, hi - bad news - another intolerable regression with window sizes made it into trunk :(
[08:48] <tsdgeos> mzanetti: hi
[08:49] <veebers> MacSlow: it looks like something pynotify is doing with the gi.repository/gobject + static objects
[08:49] <mzanetti> tsdgeos: did you already create a bug report or submit the patch to gerrit?
[08:49] <tsdgeos> 75%
[08:49] <tsdgeos> why?
[08:49] <MacSlow> veebers, yeah
[08:49] <MacSlow> veebers, I'll look into this subprocess call from python then
[08:49] <mzanetti> tsdgeos: just trying to find a reference for the FIXME in in the comment where I disable the test
[08:50] <MCR_> smspillaz, bug #1198000
[08:50] <tsdgeos> mzanetti: https://bugreports.qt-project.org/browse/QTBUG-32251
[08:50] <mzanetti> tsdgeos: cheers
[08:50] <veebers> MacSlow: cool, I'll fire off an email re: this bug and see if we can get any further with. I need to get going though
[08:51] <veebers> MacSlow: let me know how you get on with the subprocess/notify-send stuff
[08:51] <MacSlow> veebers, ok... just wanted to let you know... at least we've a way to trigger notifications from the right spot now...
[08:51] <MacSlow> veebers, I'll see how far I can get with the current examples and moving them over to autopilot
[08:51] <veebers> MacSlow: also, just out of interest, the pynotify stuff will work on the device because the code path it takes doesn't import from the gi.repository stuff
[08:52] <MacSlow> veebers, perhaps :)
[08:52] <veebers> MacSlow: Ack, Those examples that I put up should be (hopefully) helpful
[08:52] <MacSlow> veebers, I only know that the stand-alone python-examples work on the device
[08:53] <MacSlow> veebers, until now I've never seen pynotify crap out like this
[08:53] <Saviq> tsdgeos, nice one :)
[08:53] <tsdgeos> mzanetti: the other one you found is https://bugreports.qt-project.org/browse/QTBUG-32258
[08:54] <mzanetti> tsdgeos: awesome
[08:55] <veebers> MacSlow: ack, the tests in that branch will check the display outputs of the notifications regardless of how they are generated
[08:56] <MacSlow> veebers, I'll merge something together... you'll get a summary of the results/branch via eMail by my EOD
[08:56] <MacSlow> veebers, thanks and have a cool weekend
[08:56] <veebers> MacSlow: awesome
[08:58] <Saviq> mzanetti, so if I add indicators_client to http://s-jenkins:8080/job/unity8-ci/124/rebuild/? it should run the two suites?
[08:58] <mzanetti> Saviq: yep. separated by a space
[09:01] <Saviq> let's see :)
[09:03] <Saviq> mzanetti, did you see my question about Jenkins not finding the source code in coverage reports?
[09:03] <mzanetti> Saviq: yep. appears you missed my answer tho :)
[09:03] <Saviq> mzanetti, !
[09:03] <mzanetti> tsdgeos: FYI: this should be ok now: https://code.launchpad.net/~mzanetti/unity8/launcher-improve-flicking-behavior/+merge/172648
[09:03] <mzanetti> [10:22] <mzanetti> Saviq: yeah... thing is, jenkins gets that from the work dir
[09:04] <mzanetti> [10:23] <mzanetti> Saviq: so 1st it only works in the qmluitests job
[09:04] <mzanetti> [10:23] <mzanetti> Saviq: and 2nd, it only works for the last build
[09:04] <mzanetti> [10:24] <mzanetti> Saviq: only way to improve that would be to modify the jenkins cobertura plugin to copy the work dir to some persistent place
[09:04] <Saviq> mzanetti, :/
[09:04] <Saviq> mzanetti, last build would be fine, since we're most interested in trunk
[09:05] <mzanetti> Saviq: the bad thing is now that if a new build starts, it discards the old working dir
[09:05] <Saviq> mzanetti, but I'm not sure I get the "work dir" issue
[09:05] <Saviq> mhm
[09:05] <Saviq> how can that ever work, then?
[09:06] <mzanetti> Saviq: but might be better on the public jenkins as I believe it syncs the work dir there and only updates once a new build is actually finished
[09:06]  * mzanetti check
[09:06] <mzanetti> s
[09:07] <mzanetti> nope.. not there either :/
[09:07] <Saviq> mzanetti, yeah, you would expect it to be in https://jenkins.qa.ubuntu.com/job/unity8-autolanding/lastBuild/cobertura/plugins_Unity/applicationpreview_cpp/ at least
[09:08] <Saviq> mzanetti, might it be that we're not really doing anything in the -autolanding jon?
[09:08] <Saviq> job
[09:08] <Saviq> mzanetti, i.e. the -autolanding doesn't really touch any code
[09:08] <mzanetti> Saviq: phone... brb
[09:16] <Saviq> mhr3, didrocks, we now have unity-scopes-runner (and all the unity-{lens|scope} things) as part of the touch seed, should we not drop it from the seed and let the recommends take care of it?
[09:16] <mzanetti> Saviq: re
[09:16] <didrocks> Saviq: yeah, good point
[09:17] <Saviq> mhr3, didrocks, for unity-scopes-runner the scopes / lenses don't depend on it - they should, right?
[09:17] <mzanetti> Saviq: mhm... tbh I'm a bit confused why I can't find it at all right now... Each time I asked mmrazik about this he came up with a link where the code was there... but I never find it myself
[09:17] <didrocks> Saviq: hum… in fact, some scopes can be installed on the client or server
[09:18] <didrocks> maybe better to discuss with mhr3 about it
[09:18] <Saviq> didrocks, right
[09:18] <Saviq> didrocks, I plan a diff like so to the touch seed http://pastebin.ubuntu.com/5846145/
[09:18] <Saviq> the -runner might need to remain, though
[09:19] <mhr3> sec, in a hangout
[09:19] <mzanetti> Saviq: hah.... its there now: http://s-jenkins:8080/job/unity-phablet-qmluitests-saucy/422/cobertura/tests_mocks_LightDM/Greeter_h/
[09:19] <didrocks> Saviq: the scopes deps on the runner in fact
[09:20] <Saviq> mzanetti, yeah, in qmluitests, but not in -ci?
[09:20] <didrocks> the python ones
[09:20] <didrocks> Saviq: so it should be pulled as needed
[09:20] <mzanetti> Saviq: yeah... we don't copy the qmluitests work dir to the -ci job
[09:20] <Saviq> didrocks, right, the others are not python
[09:21] <didrocks> Saviq: the seed diff looks good to me, I'm happy to commit it and generating the touch meta package
[09:23] <Saviq> didrocks, https://code.launchpad.net/~saviq/ubuntu-seeds/ubuntu-touch.saucy.clean-unity8/+merge/173162
[09:25] <didrocks> Saviq: the touch image pulls the recommends, right?
[09:26] <didrocks> (as those are recommends)
[09:28] <didrocks> Saviq: rather than wondering, I'm cheating and trying to regenerate the metapackage using your branch :)
[09:28] <Saviq> didrocks, :)
[09:29] <tsdgeos> mzanetti: so the bug about the folded angle was already there, right? not a regression?
[09:29] <mzanetti> tsdgeos: yeah
[09:29] <mzanetti> tsdgeos: but until this merge I actually didn't realize its a but in ListView
[09:29] <mzanetti> s/but/bug/
[09:32] <MCR_> andyrock, hi. How is your testing of Compiz trunk working out ?
[09:32]  * MCR_ has not seen any new bug reports
[09:32] <andyrock> MCR_, good... we need to release compiz 0.9.19
[09:32] <andyrock> *.10
[09:33] <MCR_> yep
[09:33] <MCR_> andyrock, we have unfortunately one regression we should not really tolerate
[09:33] <andyrock> MCR_, do you have a bug?
[09:33] <MCR_> bug #1198000
[09:35] <MCR_> andyrock, we have several MPs, which have been checked by 4 or more eyes - it would be good to land those...
[09:35] <andyrock> MCR_, no please
[09:36] <andyrock> it will make my life harder
[09:36] <MCR_> andyrock, do you need a PPA to test
[09:36] <MCR_> ?
[09:36] <Saviq> dednick, "Show password" doesn't seem to work in the new indicators - I get dots all the time
[09:36] <Saviq> nic-doffay, can you confirm ↑ when you get to it?
[09:36] <MCR_> Fortunately smspillaz  was so nice to set them up
[09:36] <didrocks> Saviq: it's not that easy to fake though :/
[09:36] <andyrock> MCR_, it's not about that
[09:36] <didrocks> (using the seed_base for multiple things)
[09:37] <dednick> Saviq: ah. probably just a bug i introduced changing up the password field
[09:37] <andyrock> MCR_, it's about running AutoPilot to check for regression
[09:37] <MCR_> andyrock, aha
[09:37] <MCR_> andyrock, could you give me an ETA then... ?
[09:38] <MCR_> blocking trunk for a long time is not nice for any contributor...
[09:38] <andyrock> MCR_, that's why I want to release 0.9.10
[09:38] <andyrock> you "block" 0.9.10 and unblock trunk
[09:38] <MCR_> Can I help you ?
[09:39] <andyrock> if you want... ;)
[09:39] <MCR_> Sure, but I need some instructions
[09:39] <tsdgeos> pete-woods: commented in https://code.launchpad.net/~unity-team/unity8/older-months/+merge/172860
[09:40] <tsdgeos> or maybe not, my internet is acting funny
[09:40] <MCR_> I guess all milestones will have to be changed manually...
[09:40] <MCR_> to 0.9.10.2 ?
[09:40] <Saviq> dednick, the messaging icon remained blue after I've "used" a missed call entry, that's probably a backend bug?
[09:40] <tsdgeos> Saviq: do you have https://code.launchpad.net/~aacid/unity8/remove28403workarounds/+merge/172608 in your schedule or should i try to trick someone else to review it?
[09:40] <andyrock> MCR_, well to be honest  I've no idea on how  to do it ;)
[09:40] <andyrock> MCR_, I'm waiting Sam
[09:40] <Saviq> tsdgeos, that's an easy one, harass someone to do it
[09:41] <dednick> Saviq: possibly backend. does it clear it?
[09:41] <MCR_> andyrock, I have read some instructions by duflu in the source on how to do it
[09:41] <Saviq> dednick, yeah, the message itself is gone
[09:41] <Saviq> dednick, but the icon remains blue
[09:41] <dednick> Saviq: and does it clear the blue when you clear all using button at bottom?
[09:41] <Saviq> dednick, +1
[09:41] <dednick> Saviq: probably backend in that case.
[09:42] <Saviq> dednick, yeah, it did clear when I replied to a text
[09:42] <Saviq> dednick, I mean it cleared the icon
[09:44] <tsdgeos> Saviq: ok
[09:45] <pete-woods> tsdgeos: I have added some instructions, that hopefully will allow you to try out the fix :)
[09:45] <tsdgeos> tx
[09:47] <mhr3> didrocks, Saviq, the scope-runner is for the python scopes atm, so any python scopes should dep on it
[09:47] <didrocks> mhr3: yeah, we figured it out and checked, it's fine. Thanks! :)
[09:50] <Saviq> pstolowski, paulliu who broke video previews? the image is half-height on the phone
[09:53] <pstolowski> Saviq: you're testing this branch I presume: https://code.launchpad.net/~paulliu/unity8/activate3/+merge/173071 ?
[09:53] <Saviq> pstolowski, no, trunk
[09:54] <pstolowski> Saviq: hmm, looking. our changes shouldn't take affect then
[09:55] <Saviq> pstolowski, ok, will try and pinpoint the revision
[09:56] <Saviq> dednick, it worked fine on a freshly flashed manta, didn't work on fresh maguro + your branch - indicators
[09:57] <dednick> Saviq: re broken controls, i'm not sure about that. There's nothing different from the power indicator (ie it uses default page), and the controls seem to work there.
[09:57] <dednick> Saviq: I'll take a look and try see if the commands are getting through
[09:57] <Saviq> dednick, yeah I know, investigating now
[09:58] <Saviq> dednick, will run your branch against the same setup to see if it affects anything
[09:58]  * greyback bbiab
[10:03] <Saviq> dednick, yeah, it's the sound backend, it's broken bad on the latest image - sound is distorted a lot
[10:03] <Saviq> mzanetti, I think I found a bug in the greeter
[10:03] <Saviq> mzanetti, I managed to get into typing mode for the Guest user...
[10:04] <Saviq> mzanetti, and now there's no greeter at all
[10:04] <mzanetti> Saviq: hmm... more details please
[10:04] <Saviq> mzanetti, manta, I think I dragged the list slightly before tapping on it
[10:04] <Saviq> mzanetti, must've went out of "button-mode"
[10:05] <Saviq> mzanetti, and it wen't into "password-mode"
[10:05] <Saviq> mzanetti, then, when tapped again on the text entry, it unlocked
[10:05] <Saviq> mzanetti, and now it doesn't lock back
[10:05]  * Saviq tries to repro
[10:06] <mzanetti> Saviq: hmm... seems some LightDM auth issue. Mind reporting to mterry?
[10:07] <Saviq> mzanetti, yeah, if only I could reproduce...
[10:07] <Saviq> will keep an eye on it
[10:07] <nic-doffay> Saviq, sorting it now.
[10:26] <nic-doffay> Saviq, having the phone's being a pain.
[10:26] <nic-doffay> *the phone's being a pain
[10:26] <Saviq> nic-doffay, ?
[10:26] <nic-doffay> Going for a reflash now.
[10:29] <tsdgeos> Mirv: do you remember me ever filing a bug saying qtgui should links against xcb so dead keys work on qt5?
[10:29] <tsdgeos> i clearly remember it
[10:29] <tsdgeos> but can't find it :-/
[10:33] <Cimi> mzanetti, http://paste.ubuntu.com/5846273/
[10:33] <Cimi> mzanetti, tests seem to pass...
[10:33] <Cimi> wondering if it's correct :)
[10:34] <mzanetti> Cimi: hmm... push stuff to the branch and I'll do a review in a bit
[10:34] <Cimi> mzanetti, I think it's missing to rebuffer
[10:34] <Cimi> like, I remove items and I should append items on the other side maybe
[10:34] <tsdgeos> Mirv: can you have a look at https://bugs.launchpad.net/ubuntu/+source/qtdoc-opensource-src/+bug/1198131 too ?
[10:35] <tsdgeos> pete-woods: what provides usermetricsinput ?
[10:35] <tsdgeos> ah
[10:35] <tsdgeos> can't read
[10:36] <pete-woods> tsdgeos: ;)
[10:38] <Mirv> tsdgeos: yep, I wanted it to be tested on saucy which is about only now possible with the flipping work done https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1163687
[10:38] <Mirv> on saucy device, that is
[10:38] <tsdgeos> Mirv: doesn't even work in my pc
[10:38] <tsdgeos> is that in 5.0.2+dfsg1-7ubuntu1 ?
[10:38] <Mirv> tsdgeos: 11981831 is being fixed in all modules
[10:38] <Mirv> tsdgeos: no, in beta2 PPA as mentioned in the bug report
[10:39] <tsdgeos> ahh
[10:39] <tsdgeos> where?
[10:39] <tsdgeos> :D
[10:41] <Mirv> tsdgeos: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1163687/comments/10
[10:41] <tsdgeos> ah
[10:41] <tsdgeos> i was looking at https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1177496
[10:41] <tsdgeos> not https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1163687
[10:42] <Mirv> tsdgeos: ah, yes that libxkbcommon-dev build-dep is already included (although rejected by Debian :( ), but was not enough
[10:42] <tsdgeos> rejected by debian?
[10:42] <tsdgeos> by who?
[10:42] <tsdgeos> why?
[10:42]  * tsdgeos knows a few DD he can smack if needed
[10:43] <Mirv> tsdgeos: it was some time ago, but because there was no clear reason why the BD was added as it didn't fix the bug it was intended to fix in the first place, if I recall correctly
[10:43] <tsdgeos> well, the fact that the configure checks for it
[10:43] <tsdgeos> seems like a good reason enough to me :D
[10:43] <tsdgeos> fwiw dead keys work on my self compiled 5.1
[10:43] <tsdgeos> which is nto worth much probably tbh :D
[10:44] <Mirv> oh actually, it was not that reason
[10:44] <Mirv> that reason was for the deps Ken added, those were added for wrong reasons even though they kind of fixed the problem
[10:44] <Mirv> libxkbcommon-dev was rejected because that's still in experimental in Debian, it can be considered adding back when it's in unstable
[10:45] <Mirv> (and well now it's in unstable it seems)
[10:45] <Mirv> I can propose it to be added back then at some point.
[10:45] <Mirv> whenever next resync is done
[10:46] <tsdgeos> but yeah doesn't seem to fix the bug
[10:46] <Saviq> mzanetti, https://lists.ubuntu.com/archives/ubuntu-devel/2013-July/037450.html
[10:46] <mzanetti> Saviq: ???
[10:46] <Mirv> tsdgeos: so if you can test the beta2 PPA version and see if it works, it would help
[10:46] <Saviq> mzanetti, do you have saucy-proposed enabled?
[10:47] <mzanetti> Saviq: nope
[10:47] <Saviq> mzanetti, k, thought that might be why you had your "kde was removed" issue
[10:47] <Mirv> tsdgeos: I marked the doc bug as fix released, you should be able to install qtbase5-doc now and others will follow + will be added to the meta pacakge deps
[10:47] <mzanetti> Saviq: but does that mean its going to be removed from the repos?
[10:47] <Saviq> mzanetti, no
[10:47] <mzanetti> Saviq: that seems weird to me
[10:48] <tsdgeos> Mirv: cool!
[10:48] <Saviq> mzanetti, it's just a transitional issue with the whole new X stack
[10:48] <Saviq> mzanetti, but will land in distro in one atomic go
[10:48] <Saviq> mzanetti, but -proposed is not as stable
[10:49] <mzanetti> Saviq: yeah... it also seems to mess up autopilot installation... thats where MacSlow was stuck yesterday.
[10:50] <mzanetti> Saviq: so I'll stay away from saucy-proposed
[10:50] <Saviq> mzanetti, it'll get into distro soon enough ;)
[10:50] <Saviq> mzanetti, but I think the AP issue was mentioned there and is being fixed
[10:50] <mzanetti> yeah... but only once dependency issues are resolved
[11:17] <dandrader> greyback, ping
[11:17] <greyback> dandrader: pong
[11:31] <mzanetti> Saviq: I fear I messed up
[11:31] <Saviq> mzanetti, with?
[11:31] <mzanetti> Saviq: I lost track over all the merge proposals that are still open
[11:31] <mzanetti> Saviq: and now they are merged into one big one :/
[11:32] <Saviq> mzanetti, you mean the launcher ones?
[11:32] <mzanetti> Saviq: yeah
[11:32] <mzanetti> Saviq: because I continued to work on it... and would have created a 4th. depending one
[11:33] <Saviq> mzanetti, tough luck, /our fault for not reviewing it quicker
[11:33] <mzanetti> Saviq: now I pushed all the stuff to the wrong one... I'm not sure if it makes sense to split them apart again
[11:33] <mzanetti> Saviq: yeah... when I say "working with full speed on something" I mean it
[11:33] <mzanetti> :P
[11:35] <mzanetti> Saviq: so, this adds QuickList support to the API: https://code.launchpad.net/~mzanetti/unity-api/launcher-api-pinning/+merge/173064
[11:36] <Saviq> mzanetti, cool
[11:36] <mzanetti> Saviq: but because this breaks the current API a little bit, this one gets obsolete: https://code.launchpad.net/~mzanetti/unity8/launcher-follow-unity-api
[11:37] <Saviq> mzanetti, mark it so
[11:37] <mzanetti> Saviq: however, this one updates to the new API already: https://code.launchpad.net/~unity-team/unity8/launcher-backend/+merge/172772
[11:37] <mzanetti> Saviq: unfortunately it also does a bit more work in the plugin itself... so it mixes 2 somewhat unrelated things
[11:37] <Saviq> mzanetti, if you can split easily, do, if not, don't sweat it
[11:38]  * Saviq wants git
[11:43] <mzanetti> Saviq: so its those 2: https://code.launchpad.net/~mzanetti/unity-api/launcher-api-pinning/+merge/173064 and https://code.launchpad.net/~unity-team/unity8/launcher-backend/+merge/173189
[11:43] <mzanetti> Saviq: the second one won't compile until the first one is relesed
[11:43] <mzanetti> Saviq: I think I'm going to stop working on this now until both are merged :D
[11:44] <Saviq> mzanetti, yeah, go review some stuff :P
[11:44] <mzanetti> Saviq: ack
[11:45] <mzanetti> Saviq: if possible, I'd like to get them merges asap because Wellark_'s work also depends on this. So if there is a chance to prioritize those I'd be thankful
[11:45] <mzanetti> Saviq: I'll take away all other reviews from you in the meantime
[11:45] <Saviq> mzanetti, cool, want to push indicators-client out the door and I'll go there
[11:46] <mzanetti> ack
[11:46] <Saviq> mzanetti, if you look at lp:~mhr3/unity8/use-dee-filtermodel
[11:46] <Saviq> mzanetti, I didn't review the tests, you can start with that
[11:55] <mzanetti> Saviq: ack
[11:56] <Saviq> mhr3, re: http://pastebin.ubuntu.com/5846478/ - are we sure the values will be correct?
[11:59] <mhr3> Saviq, for now, yes, if we expose those in unity-core or somewhere, we'll change it to that
[12:00] <Saviq> mhr3, I just wonder if we should be explicit (= 1, = 2 etc.) there
[12:01] <Saviq> pstolowski, I actually think the preview issue was an SDK issue that got fixed/reverted
[12:01] <mhr3> Saviq, no need imo
[12:01] <Saviq> mhr3, k
[12:01] <mhr3> compiler is pretty good at counting :)
[12:01] <Saviq> mhr3, "Michał Hruby" ;)
[12:02] <Saviq> mhr3, "// FIXME: need to clean up unused filters on countChanged" is that handled now?
[12:02] <mhr3> Saviq, heh, need better contrast in my comment color profile :)
[12:02] <mhr3> Saviq, yep, search for "delete"
[12:02] <Saviq> mhr3, cool
[12:03] <mhr3> Saviq, fixed my name :P
[12:03] <Saviq> ;)
[12:05] <pstolowski> Saviq: ok thanks for update
[12:05] <seb128> didrocks, Mirv, mhr3, pstolowski: unity trunk has dash/preview issues, running a command from a preview turns on filter's display
[12:05] <Saviq> mhr3, btw, why the quotes in CMake?
[12:05] <seb128> e.g they are showed next time you open the dash
[12:05] <seb128> if you hide them they come back on next opening
[12:05] <mhr3> Saviq, cause raring cmake doesn't work without them
[12:06] <Saviq> mhr3, ah, and they're there everywhere else?
[12:06] <mhr3> Saviq, it didn't complain otherwise :)
[12:06] <Saviq> mhr3, ok ;)
[12:09] <pstolowski> seb128: looking at bzr log, looks like rev 3404 may be related?
[12:09] <seb128> bregma, ^
[12:10] <seb128> pstolowski, seems it could yes
[12:11] <Saviq> mzanetti, plugins/Unity/Launcher/quicklistmodel.cpp	UNKNOWN	*No copyright*
[12:11] <mzanetti> ouch
[12:11]  * mzanetti is fixing
[12:11] <Saviq> mzanetti, even you're not using your own bzr hook ;)
[12:11] <mzanetti> Saviq: I do
[12:11] <mzanetti> Saviq: but the copyright check in there does not work
[12:11] <Saviq> mzanetti, don't we have a copyright checker there?
[12:11] <Saviq> mzanetti, oh interesting
[12:11] <mzanetti> Saviq: well. not sure if we even have one
[12:12] <mzanetti> Saviq: but the one in unity-api for example checks the build dir and bails out on generated code
[12:12] <mzanetti> Saviq: I think thats the reason we didn't have that in unity8
[12:12] <Saviq> mzanetti, we fixed that in unity8 at some point
[12:12] <Saviq> mzanetti, nvm
[12:12] <Mirv> seb128: right, I noticed the filters appearing separately, but I only ran single ap tests which individually succeeded
[12:13] <mzanetti> Saviq: anyways... the new hook is quite cool. Now I really use it. and it saved me from comitting whitespaces quite often already.
[12:14] <Saviq> mzanetti, yeah, I'm not sure I like the fact that it lets the commit through, with qcommit it'd be better if it didn't
[12:14] <Saviq> mzanetti, as it will let you fix and remember the msg internally
[12:15] <mzanetti> I could change that I guess... But the old hook annoyed me so much when discarding all the commit stuff that I didn't want that any more
[12:15] <mzanetti> but now with the saved commit message it would be an option again
[12:18] <mzanetti> ci is amazingly fast today, isn't it?
[12:28] <dandrader> mzanetti, I'm rather idle at the moment. do you need a hand with your code reviews
[12:28] <dandrader> or anyone, for that matter
[12:30] <mzanetti> dandrader: same situation here. but I'm still at the use-dee-filtermodel one. so feel free to pick any other mp
[12:31] <didrocks> pstolowski: do you think we should try reverting that rev?
[12:31] <dandrader> Saviq,  mzanetti, ok, I'll take this one then https://code.launchpad.net/~nick-dedekind/unity8/plugins.qmltypes/+merge/172517
[12:34] <Saviq> dandrader, cheesr
[12:36] <mzanetti> Saviq: what happened to the merge where I moved the fake plugins into the mock dir?
[12:36] <Saviq> mzanetti, it got merged?
[12:36] <Saviq> mzanetti, it was packaging-cleanup, no?
[12:37] <mzanetti> yeah. I thought that one was merged yesterday
[12:37] <pstolowski> didrocks: it's just my wild guess based on the description of the change... I looked at the diff, but can't say if it causes the issue. dednick, do you know?
[12:39] <didrocks> Mirv: reverted and relaunched an unity build ^
[12:41] <pstolowski> dednick: fyi, unity trunk has dash/preview issues, running a command from a preview turns on filter's display. e.g they are showed next time you open the dash. if you hide them they come back on next opening.looks like rev 3404 may be related?
[12:48] <Saviq> mzanetti, it was, are you not seeing some change you wanted to see?
[12:50] <Mirv> didrocks: ok, let's hope for the best this time
[12:52] <seb128> Trevinho_, there?
[12:52] <bregma> pstolowski, seb128, that rev definitely looks like the cause, I'll have brandon revisit it when he comes in
[12:54] <mzanetti> Saviq: got tricked by the fact that the dee-filtermodel branch is not yet merged and jenkins didn't realize it yet
[12:54] <seb128> bregma, thanks
[12:54] <Saviq> dednick, the password hidden vs. password shown logic is flipped
[12:54] <Saviq> mzanetti, yeah, it should conflict, though, right?
[12:54] <mzanetti> Saviq: yes. it will
[12:54] <Saviq> mzanetti, I usually review locally, having merged the branch-to-be-merged into current trunk
[12:59] <Saviq> mzanetti, find all the conflicts this way
[13:05] <larsu> dednick: hey, you pinged me yesterday but were already gone when I saw it
[13:11] <dandrader> mzanetti, on the greeter: I press on the right side. greeter bounces (hint animation). then I slide my finger to the left half of the greeter. Launcher bounces (hint animation). Is that way it should behave?
[13:28] <Saviq> mzanetti, oh, bzr showed some smarts? ;)
[13:29] <mzanetti> Saviq: yeah... totally hit me unprepared
[13:30] <Saviq> Cimi, standup
[13:31] <mzanetti> Saviq: no... its "Cimi: notes!"
[13:31] <Saviq> mzanetti, maybe, maybe
[13:31] <mzanetti> :P
[13:31] <Saviq> paulliu, standup?
[13:31] <Saviq> and the winner is?
[13:35] <nic-doffay> Saviq, the bugs are fixed, shall I do a code review too?
[13:36] <Saviq> nic-doffay, no, just make sure everything works functionally
[13:37] <nic-doffay> Saviq, functionality wise it's fine.
[13:38] <Saviq> nic-doffay, what about the "show password" checkbox for joining wifi? does it work fine?
[13:38] <nic-doffay> Saviq, yep.
[13:38] <nic-doffay> Tried a lot of stuff re the wifi indicator.
[13:39] <nic-doffay> Mainly just connecting and disconnecting
[13:39] <nic-doffay> And typing passwords.
[13:39] <Saviq> nic-doffay, sorry, that was a trap
[13:39] <Saviq> nic-doffay, it doesn't work - when you check the "show password" checkbox
[13:39] <Saviq> nic-doffay, it actually switches to "hidden password" mode
[13:40] <mzanetti> Saviq: meanie
[13:40] <mzanetti> :P
[13:40] <Saviq> nic-doffay, the checkbox logic is reversed
[13:40] <nic-doffay> Saviq, http://s.lunaticoutpost.com/upload/big/2013/06/06/51b11f23cc41a.jpg
[13:40] <Saviq> nic-doffay, exactly!
[13:41] <nic-doffay> Saviq, you're right it's reversed.
[13:41] <Saviq> nic-doffay, yeah, but if you didn't manage to break it, then +1 on the MP
[13:41] <Saviq> nic-doffay, I already commented about that checkbox issue
[13:42] <nic-doffay> Saviq, I haven't attempted connecting to a network I know the password for yet.
[13:42] <nic-doffay> Without it doing so automatically.
[13:42] <Saviq> k
[13:42] <nic-doffay> Saviq, should that be tested too?
[13:47] <Saviq> nic-doffay, it worked for me, but yeah, would be nice if you tested it
[13:48] <Saviq> nic-doffay, basically just give the indicators a bashing
[13:48] <Saviq> nic-doffay, and report any issues you find
[13:48] <Saviq> didrocks, mzanetti had a valid question
[13:48] <Saviq> didrocks, if packages within a stack depend on each other (there's two merges that need to happen in sync)
[13:48] <Saviq> didrocks, how does that work with daily builds?
[13:49] <Saviq> didrocks, what that means is we can't get things past CI
[13:49] <Saviq> didrocks, until one of them gets released somewhere
[13:50] <Saviq> didrocks, and we build against that
[13:53] <mzanetti> Saviq: I guess having a stack-ppa would solve it. daily releasing would release into that, even breaking things. but from there to distro it needs to work together.
[13:53] <mzanetti> Saviq: jenkins, and only jenkins, would also include that ppa in its jobs
[13:53] <Saviq> mzanetti, yeah, but we should release more often into that ppa
[13:53] <Saviq> mzanetti, and there'd have to be a per-stack PPA there
[13:54] <mzanetti> Saviq: yes. it needs to be per-stack
[13:54] <Saviq> mzanetti, so we only build against released versions of other things
[13:54] <Saviq> but within a stack stuff can build against trunkc
[13:54] <Saviq> *trunks
[13:54] <mzanetti> Saviq: and at my previous workplace every commit that passed ci was automatically released into that stack-ppa
[13:54] <Saviq> mzanetti, TBH I'm sure it's described in the FAQ... just never made it to reading it yet
[13:54] <mzanetti> hehe
[13:56] <Saviq> mzanetti, hum, https://jenkins.qa.ubuntu.com/job/unity8-ci/129/ had two suites
[13:56] <Saviq> mzanetti, but it only resulted in the one in https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/673/parameters/? ?
[13:58] <mhr3> mzanetti, not sure if you need info from me on my branch or from Saviq
[13:58] <Saviq> :)
[13:58] <mzanetti> Saviq: http://s-jenkins:8080/job/unity8-saucy-i386-ci/129/parameters/?
[13:58] <mhr3> re the question about the testing
[13:58] <mzanetti> mhr3: I'd like to have your opinion too
[13:59] <Saviq> mzanetti, yeah, but it's only valid for autopilot (mediumtests), no?
[13:59] <mzanetti> Saviq: yeah... sorry. wrong link.. but its the same in mediumtests
[13:59] <mzanetti> Saviq: what I meant is that the inidcators_client is in project_name, not test_suite
[14:00]  * mzanetti has no clue what project_name does btw
[14:00]  * mzanetti just knows it doesn't break anything if you mess it up :D
[14:00] <mhr3> mzanetti, might be a bit overkill to create a real scope just to be able to add a few tests
[14:01] <Saviq> mzanetti, oh, so I fooked
[14:01] <mzanetti> mhr3: I don't feel comfy with not having tests at all for that scope+categories+filter thing...
[14:01] <mzanetti> mhr3: I'd say in the end we need to have it
[14:01] <mzanetti> mhr3: if it should be part of this merge or not... thats a different question
[14:03] <mzanetti> mhr3: I would actually prefer to have it right here. Makes sure we won't forget it. But otoh I don't want to steer this merge towards a never ending story
[14:03] <mhr3> should be autopilot thing imo
[14:04] <mzanetti> true actually
[14:04] <Saviq> greyback, can you point me to the latest unity8-mir integration branch?
[14:04] <Saviq> greyback, is it
[14:04] <Saviq> lp:~unity-team/unity/unity8-integrate-mir/
[14:04] <Saviq> ?
[14:04] <greyback> Saviq: yes.
[14:05] <Saviq> greyback, can you do hangout?
[14:05] <greyback> Saviq: sure
[14:05] <mhr3> mzanetti, but then there aren't too many real scopes that autopilot can be checking
[14:06] <mzanetti> mhr3: what would an autopilot test for this look like? Tbh I didn't fully understand what it does
[14:06] <greyback> olli: lp:~unity-team/unity/unity8-integrate-mir/
[14:07] <mhr3> mzanetti, go to the scope page, search for something, preview it, activate it...
[14:07] <greyback> olli: lp:~gerboland/+junk/qml-demo-shell/
[14:08] <mzanetti> mhr3: whats the scope page?
[14:08] <mhr3> mzanetti, the view where the scope is displayed
[14:08] <mhr3> mzanetti, as in "Home" / "Apps" / ...
[14:10] <mzanetti> mhr3: whats the name of the apps scope?
[14:10] <mzanetti> mhr3: the backend
[14:10] <mzanetti> nvm
[14:11] <mzanetti> mhr3: not following... I can't preview apps, and I cant activate stuff that I can preview
[14:13] <mhr3> mzanetti, but soon it will be possible :)
[14:15] <didrocks> mzanetti: Saviq: back to you in a sec, but basically "it works"
[14:15] <didrocks> mzanetti: Saviq: more details in few minutes
[14:15] <didrocks> pstolowski: the revert didn't work
[14:15] <didrocks> bregma: pstolowski: mhr3: so, unity have now 30 tests failures on one config
[14:15] <didrocks> has*
[14:15] <mhr3> didrocks, maybe the filter thing seb128 mentioned?
[14:16] <didrocks> bregma: pstolowski: mhr3: I can --overwrite the revert
[14:16] <didrocks> mhr3: I think it's what makes the previews test failing, right
[14:16] <didrocks> mhr3: the thing is that the new xorg is stuck in proposed because of that
[14:16] <didrocks> any idea how to unblock the situation?
[14:16] <didrocks> dednick: if you are around as well
[14:16] <mhr3> didrocks, oh you reverted it already, and there's still 30failures?
[14:16] <bregma> you mean the revert causes more tests to fail?
[14:16] <didrocks> mhr3: there were 20
[14:17] <didrocks> now 30
[14:17] <didrocks> bregma: yep :p
[14:17] <didrocks> so, let's me uncommit the revert
[14:17] <didrocks> and --overwrite
[14:17] <dednick> didrocks: ?
[14:17] <didrocks> sounds find to you?
[14:17] <didrocks> dednick: we have a lot of AP tests failing
[14:17] <didrocks> and really need to release today to unblock proposed
[14:17] <bregma> worth a try, but I can't see how the revert would cause _more_ tests to fail
[14:18] <didrocks> seb128 saw some artefacts (the filters staying up)
[14:18] <mhr3> didrocks, are you sure the testing behaved fine?
[14:18] <didrocks> bregma: same here, maybe due to nux?
[14:18] <didrocks> mhr3: it took latest unity build with the revert from what I see
[14:18] <mhr3> didrocks, maybe the dbus thing again?
[14:19] <seb128> well, what I see here is that the filter UI is always on when opening the dash, after you used the preview screen to run an app once
[14:19] <didrocks> mhr3: no, it's not a dbus thing (in fact, it's a lack of memory one) and we didn't have it, the tests run in one hour
[14:19] <didrocks> I'm sure it's due to what seb128 is seeing (for the impacted tests)
[14:19] <bregma> I can repro the filters problem every time, the revert should fix (just) that
[14:19] <dednick> didrocks: which jenkins job?  ps-unity-autopilot-trunk ?
[14:19] <didrocks> dednick: http://10.97.0.1:8080/job/autopilot-saucy-daily_release/label=autopilot-intel/lastCompletedBuild/testReport/ with the revert
[14:22] <didrocks> http://10.97.0.1:8080/job/autopilot-saucy-daily_release/label=autopilot-intel/343/
[14:26] <mhr3> didrocks, could we run something to give us dbus stats per tests run?
[14:26] <mhr3> didrocks, like number of calls etc
[14:27] <mhr3> maybe something is spamming dbus and that's why things sometimes fail
[14:27] <didrocks> mhr3: if you have something to propose, yeah :)
[14:27] <mhr3> bustle-count would work, but it doesn't seem to be available anymore :/
[14:27] <dednick> most of the preview failures are because there are no results.
[14:28] <didrocks> dednick: you think a network issue?
[14:29] <didrocks> (run 345 if you want to follow)
[14:34] <dednick> didrocks: doubtful it's network. should have local results.
[14:34] <dednick> mhr3, didrocks: maybe scope is crashing?
[14:35] <didrocks> possible as well…
[14:35] <didrocks> jibel: I can't access /var/crash?
[14:36] <didrocks> didn't we have the core files reported in the host?
[14:36] <mhr3> it's not just scopes, it's also hud that is not working and bamf
[14:36] <mhr3> so very much a global dbus thing
[14:39] <jibel> didrocks, apport is not installed
[14:39] <jibel> done
[14:40] <didrocks> mhr3: weird that both machines went down at the same time, let's see with this one
[14:40] <didrocks> we can't tell anything, it's a fresh reboot, nothing run before
[14:44] <Saviq> mzanetti, https://code.launchpad.net/~mzanetti/unity-api/launcher-api-pinning/+merge/173064/comments/387309
[14:45] <mhr3> didrocks, maybe they found a way to reproduce it 100% :)
[14:45] <didrocks> mhr3: ahah
[14:45] <mhr3> anyway, i gotta leave early today, hopefully the second run will be fine :)
[14:45] <didrocks> Saviq: mzanetti: ok, while it's running the tests, so about the version
[14:45] <mhr3> cyas
[14:46] <didrocks> mhr3: enjoy your week-end!
[14:46] <Saviq> mhr3, cheers
[14:46] <mhr3> didrocks, you too
[14:46] <didrocks> so you have A which deps on a new version of B, right?
[14:46] <seb128> didrocks, mhr3: weird, not sure if that's the same issue, but http://10.97.0.1:8080/job/autopilot-saucy-daily_release/344/label=autopilot-ati/testReport/ubuntu_html5_theme.tests.test_rss_reader/UbuntuThemeRSSReaderTestCase/test_appDoesLoads/
[14:46] <mzanetti> mhr3: bye bye
[14:46] <seb128> "    raise RuntimeError("Search criteria returned no results")"
[14:46] <didrocks> seb128: no, it's a missing dep I guess
[14:46] <seb128> I wonder if something is broken with dbus
[14:46] <Saviq> didrocks, yeah, but A won't build until B is released
[14:47] <didrocks> Saviq: https://wiki.ubuntu.com/DailyRelease/FAQ#My_package_B_depends_on_a_new_symbol_I_just_added_on_A_or_needs_to_be_rebuilt_against_an_ABI_breakage_in_A
[14:47] <Saviq> s/but/and/
[14:47] <didrocks> you follow that, right?
[14:47] <didrocks> normally, it shouldn't need a release
[14:47] <tsdgeos> greyback: mzanetti: Saviq: all: This is my patch idea (haven't tried it yet) for the creation of delegates of part of a listview and not its full height http://paste.kde.org/~tsdgeos/789926/ any quick comment?
[14:47] <tsdgeos> not really happy with the naming
[14:47] <didrocks> so, let's see B is at 0.41
[14:47] <Saviq> didrocks, didn't read through that yet, but was sure it's going to be there :|
[14:47] <mzanetti> didrocks: its not only a new symbol... its changed existing symbols
[14:48] <didrocks> mzanetti: ah, this is an ABI break then
[14:48] <didrocks> mzanetti: https://wiki.ubuntu.com/DailyRelease/FAQ#I_need_to_break_an_API.2BAC8-ABI :)
[14:48] <mzanetti> didrocks: ofc :)
[14:48] <didrocks> ;)
[14:48] <didrocks> so, basically, this should work
[14:48] <didrocks> you bump the upstream versoin
[14:48] <didrocks> like 0.42.1+13.10.20130815-0ubuntu1 (or 0.42.1-0ubuntu1)
[14:48] <didrocks> and bump B to 0.42.2-0ubuntu1
[14:48] <didrocks> in debian/changelog
[14:49] <didrocks> the upstream merger will append bzr<rev>
[14:49] <didrocks> so 0.42.2bzr<rev>…
[14:49] <mzanetti> didrocks: right... we thought about versioning too... but hoped to get along without it for a bit as breakage will happen on a frequent basis for another month or 2
[14:49] <didrocks> meaning that once you build-dep against << 0.42.2
[14:49] <didrocks> you will have it in the upstream version :)
[14:49] <didrocks> mzanetti: yeah, if don't bump the soname of the libs, it's the only sane way to deal with it without breaking everyone I'm afraid
[14:49] <didrocks> bumping the version + Breaks
[14:50] <didrocks> mzanetti: please do not hesitate to tell me if the description is obscure (and it's a wiki, feel free to improve it ;))
[14:50] <mzanetti> didrocks: sure
[14:50] <greyback> tsdgeos: I was thinking "viewPort{Begin,End}" but it's not really the viewport is it
[14:51] <Saviq> didrocks, so the new ABI version will get pushed through daily release manually?
[14:51] <Saviq> didrocks, as it will break the stack, because A didn't yet land (CI didn't pass)
[14:51] <didrocks> Saviq: hum, no, it should be automagic :)
[14:51] <Saviq> didrocks, and so it won't build
[14:51] <didrocks> Saviq: you need to land both the same day
[14:51] <didrocks> you don't need to wait for a day to release the other one
[14:51] <Saviq> didrocks, yeah, but we can't land A
[14:51] <didrocks> why?
[14:51] <tsdgeos> greyback: well in our case it will be, but it's not necessarily it
[14:51] <Saviq> didrocks, because CI fails for it
[14:51] <didrocks> Saviq: you do have a local repo for the upstream merger, right?
[14:51] <Saviq> didrocks, because B isn't released yet
[14:52] <didrocks> so it should pick the latest?
[14:52] <greyback> tsdgeos: exactly
[14:52] <Saviq> didrocks, not sure what "a local repo for the upstream merger" means
[14:52] <didrocks> ok, let's take an example
[14:52] <Saviq> didrocks, sure, we have one
[14:52] <didrocks> ah, better, send the links :)
[14:52] <Saviq> didrocks, https://code.launchpad.net/~mzanetti/unity-api/launcher-api-pinning/+merge/173064
[14:52] <Saviq> didrocks, https://code.launchpad.net/~unity-team/unity8/launcher-backend/+merge/173189
[14:53] <didrocks> ok, and so unity-api is breaking ABI, right?
[14:53] <Saviq> didrocks, yes
[14:53] <greyback> tsdgeos: crazy idea: change cacheBuffer to be cacheBufferBegin & cacheBufferEnd. And allow negative values :)
[14:53] <tsdgeos> lol
[14:54] <didrocks> ok, so:
[14:54] <didrocks> unity-api is at 7.80.2+13.10.20130703ubuntu.unity.next-0ubuntu1
[14:54] <didrocks> unity8 at 7.81.3+13.10.20130704ubuntu.unity.next-0ubuntu1
[14:55] <didrocks> in unity-api:
[14:55] <didrocks> dch -i
[14:55] <didrocks> change the version to 7.80.3-0ubuntu1 (for instance)
[14:55] <didrocks> then, in debian/control
[14:55] <tsdgeos> greyback: that'd make it even harder to get it accepted upstream
[14:55] <didrocks> on libunity-api0 binary package:
[14:55] <didrocks> Breaks: unity8 (<< 7.81.4)
[14:56] <tsdgeos> since it'd be not only a feature they probably don't want, but also a API break
[14:56] <greyback> tsdgeos: I know. But part of me likes it :)
[14:56] <didrocks> this is the first MP
[14:56] <didrocks> then, on unity8:
[14:56] <didrocks> dch -i
[14:56] <Saviq> tsdgeos, why you decided against QRect? could be useful for GridView?
[14:56] <didrocks> change the version to 7.81.4
[14:56] <tsdgeos> Saviq: because the thing is not made to support rects
[14:56] <didrocks> so 7.81.4-0ubuntu1
[14:56] <tsdgeos> and it's a much more invasive change
[14:56] <tsdgeos> Saviq: that we don't need anyway
[14:56] <didrocks> Saviq: mzanetti: making sense? ^
[14:56] <Saviq> tsdgeos, ah, so even in a gridview it's just "above" and "below"?
[14:57] <Saviq> tsdgeos, or "to the left/right"?
[14:57] <tsdgeos> Saviq: i.e. children of itemview have to implement the addVisibleItems(from, to)
[14:57] <greyback> tsdgeos: I dunno, name is hard. delegateVisible{Begin,End} - subViewPort...
[14:57] <tsdgeos> Saviq: exactly
[14:58] <mzanetti> didrocks: hmm... in unity-api we need to set "Breaks: unity8"?
[14:58] <didrocks> mzanetti: yeah, to ensure you can't upgrade unity-api without having the right unity8 version
[14:58] <tsdgeos> greyback: i think i'll leave like it for the moment, test if it works, and if we get the luck they accept this upstream just use the name they want, if we have to distro patch it, then we can discuss the name a bit more :D
[14:58] <mzanetti> didrocks: that sounds a bit scary, given that in theory you can't know who is using you and what breaks
[14:58] <didrocks> mzanetti: yeah, that's why APIs normally have soname versioning
[14:58] <mzanetti> didrocks: wouldn't it make more sense to depend on a exact version of unity-api in unity8?
[14:59] <didrocks> but I guess as long as we are in flux, that's why I came with the simplified version
[14:59] <greyback> tsdgeos: you asked upstream if they're interested in it? I got the impression they want to leave it alone, and come up with something more abstract in future
[14:59] <didrocks> mzanetti: there is another way…
[14:59] <didrocks> mzanetti: dark hack :p
[14:59] <Saviq> didrocks, mzanetti unity-api doesn't break unity8
[14:59] <tsdgeos> greyback: not yet
[14:59] <mzanetti> didrocks: ok... if thats temporary I'm fine with it
[14:59] <Saviq> didrocks, mzanetti as it doesn't link to it
[14:59] <tsdgeos> greyback: but i want to do a test + use case first
[14:59] <tsdgeos> so i can have something to sell it
[14:59] <mzanetti> Saviq: well, I do (currently)
[14:59] <greyback> tsdgeos: understood
[14:59] <mzanetti> ah no
[14:59] <mzanetti> sorry
[14:59] <didrocks> ah? :p
[14:59] <Saviq> mzanetti, no you don't
[14:59] <didrocks> do you break or not? ;)
[14:59] <Saviq> didrocks, break, but not there
[14:59] <mzanetti> didrocks: we break at runtime
[14:59] <tsdgeos> greyback: because otherwise isolated like this seems like a "why do you need this at all?" feature
[14:59] <didrocks> so if you don't break, no need for the breaks
[15:00] <didrocks> ah, so yeah, it's a break ;)
[15:00] <Saviq> mzanetti, no we don't!
[15:00] <greyback> tsdgeos: gotcha
[15:00] <mzanetti> ah dammit.
[15:00]  * mzanetti shuts up
[15:00] <Saviq> mzanetti, there's on libunity-api that we link to
[15:00] <didrocks> snif
[15:00] <didrocks> :-)
[15:00] <Saviq> mzanetti, as we're using the source code directly
[15:00] <didrocks> ah
[15:01] <didrocks> you statically link?
[15:01] <mzanetti> didrocks: unity-api has only headers
[15:01] <Saviq> didrocks, not even, just using the .h as our local source
[15:01] <didrocks> ah ok :)
[15:01] <didrocks> so no need for the breaks:
[15:01] <Saviq> uff
[15:01] <didrocks> just bumping and changing debian/control build-dep version
[15:01] <didrocks> so, in that case:
[15:01] <didrocks> - bump the version of unity-api
[15:01] <Saviq> mzanetti, didrocks the API version is what's supposed to make sure unity8 and backend implementation to stay in sync
[15:02] <didrocks> - in unity8, just bump the build-dep against latest unity-api
[15:02] <mzanetti> right... now I fits what I would have expected
[15:02] <mzanetti> ok. will do
[15:02] <didrocks> and that's it :)
[15:02] <didrocks> thanks mzanetti :)
[15:02] <mzanetti> no, thank you didrocks
[15:02] <didrocks> yw!
[15:02] <Saviq> mzanetti, in that case let's bump the internal API version, too
[15:02] <Saviq> mzanetti, in CMakeLists
[15:02] <mzanetti> Saviq: ack
[15:02] <Saviq> mzanetti, also
[15:03] <Saviq> mzanetti, make unity8-private Provides: unity-launcher-impl, unity-launcher-impl-$the_new_api_version
[15:03] <didrocks> Saviq: where is the backend implementation right now? because the breaks are against those, then?
[15:03] <Saviq> didrocks, in lp:unity8 ;)
[15:03] <Saviq> didrocks, unity8-private
[15:03] <didrocks> ok then :)
[15:04] <Saviq> mzanetti, and make unity8 Depend: on unity8-private | unity-launcher-impl, unity-launcher-impl-$the_new_api_version
[15:04] <didrocks> Saviq: I don't remember, do we extract $the_new_api_version from cmake?
[15:04] <Saviq> didrocks, not yet
[15:04] <Saviq> didrocks, well, I ship a .pc
[15:04] <didrocks> I can work on this if you want
[15:04] <didrocks> that will automate at least
[15:04] <Saviq> didrocks, and we need to have some snippets to make the Provides automagical
[15:05] <didrocks> yeah, it's what I've done for compiz, nux…
[15:05] <Saviq> didrocks, we'll get there
[15:05] <Saviq> didrocks, not a req right now
[15:05] <didrocks> sure, at least, that will ensure that frontend and backend are in sync
[15:05] <didrocks> and built against the same unity-api
[15:05] <Saviq> didrocks, I expect you to have more pressing matters
[15:06] <didrocks> Saviq: that's not untrue TBH ;)
[15:07] <didrocks> Saviq: just, while I'm thinking about it, what is contained in libunity-api0? as the backend/frontend directly includes the .h and communicates directly then?
[15:07] <Saviq> didrocks, other things
[15:07] <Saviq> didrocks, that nothing uses yet, AFAIK
[15:07] <didrocks> ok
[15:07] <Saviq> didrocks, but even then, will we need a Breaks: for every rdepend?
[15:08] <Saviq> didrocks, what if we don't know the rdepend?
[15:09] <didrocks> Saviq: if you bump the virtual dep with the api version, the virtual package trick will ensure we don't need the Breaks:
[15:09] <didrocks> (once we have done the trick ;))
[15:09] <Saviq> didrocks, ok good
[15:09] <didrocks> and I think at some point, we'll treat the soname as it should, bumping with libunity-api1… and so on :)
[15:10] <Saviq> didrocks, ok one last thing
[15:11] <Saviq> didrocks, we don't have the case right now, but let's assume later we might have
[15:11] <Saviq> didrocks, if unity-api would release with the new ABI
[15:11] <Saviq> didrocks, it would break the stack
[15:11] <Saviq> didrocks, because unity8 wouldn't be there yet ('cause it didn't pass CI)
[15:12] <didrocks> Saviq: the part I don't understand is why it didn't pass CI?
[15:12] <didrocks> within the same sday
[15:12] <didrocks> day*
[15:12] <didrocks> baiscally, you bumped the version of unity-api
[15:12] <Saviq> didrocks, yeah, but we're not building against trunk of unity-api
[15:12] <didrocks> from 7.80.2+13.10.20130703ubuntu.unity.next-0ubuntu1 to 7.80.3
[15:12] <Saviq> didrocks, but against a released version
[15:13] <Saviq> didrocks, unless I don't know something?
[15:13] <didrocks> Saviq: hum, that's an issue, not sure how your CI is different from the other configs
[15:13] <didrocks> Saviq: for unity and so on, we have a "local repository"
[15:13] <Saviq> didrocks, I'm not saying it is :D
[15:13] <Saviq> didrocks, until now it was like that
[15:13] <didrocks> I did that some times ago and I think that's what is used (not sure it's used everywhere still)
[15:13] <Saviq> didrocks, with the phablet-land
[15:13] <didrocks> so basically:
[15:14] <didrocks> -> unity-api builds, the version becomes 7.80.3bzr<rev>-0ubuntu1
[15:14] <didrocks> for instance
[15:14] <didrocks> the unity MP is approved, build-dep against 7.80.3
[15:14] <didrocks> it founds it in the local repo and build against it
[15:14] <didrocks> (we had the case tons of time between compiz/nux/unity)
[15:14] <didrocks> then, you have the generic-medium-tests
[15:14] <didrocks> not sure if they use this local repo?
[15:16] <didrocks> http://10.97.0.1:8080/job/autopilot-saucy-daily_release/label=autopilot-intel/345/?
[15:16] <didrocks> better, but still some previews issues
[15:16] <Saviq> didrocks, ah, local *dpkg* repo
[15:17] <didrocks> seb128: pstolowski: bregma: dednick: ^
[15:17] <didrocks> Saviq: right :)
[15:17] <Saviq> didrocks, yeah, that's exactly what we thought should happen :)
[15:17] <Saviq> didrocks, is that per-stack repo or global?
[15:17] <didrocks> Saviq: per-stack
[15:17] <Saviq> didrocks, exactly!
[15:17] <didrocks> ;)
[15:17] <Saviq> didrocks, DONE
[15:17] <didrocks> ahah
[15:17] <Saviq> didrocks, thanks
[15:17] <didrocks> yw!
[15:21] <Saviq> mzanetti, ↑ see, they did it already how we said it should be done ;)
[15:21] <Saviq> mzanetti, only thing is they both need to land the same day
[15:22] <Saviq> mzanetti, between that every stack has a local dpkg repository with the latest landed things
[15:22] <didrocks> Saviq: yeah, landing everything within the same day (before 00 UTC) is the only contract with dailies :)
[15:22] <mzanetti> ah. cool
[15:23] <mzanetti> Saviq: https://code.launchpad.net/~mzanetti/unity-api/launcher-api-pinning/+merge/173064/comments/387336
[15:23] <pstolowski> didrocks: no videos?
[15:23] <didrocks> pstolowski: no, see the discussion above why
[15:24] <didrocks> pstolowski: I think we can reenable it for one run, but it will be already EOD
[15:27] <kgunn> Saviq: ping
[15:27] <Saviq> kgunn, pong
[15:42] <mzanetti> didrocks: mind verifying how badly I messed up?
[15:42] <mzanetti> didrocks: this would the breaking api: https://code.launchpad.net/~mzanetti/unity-api/launcher-api-pinning/+merge/173064/
[15:43] <didrocks> mzanetti: sure :)
[15:43] <didrocks> "bump the version a bit more" <- love it :)
[15:43] <mzanetti> didrocks: I assumed that daily releasing will add the +<data>... etc on its own again
[15:43] <didrocks> mzanetti: right
[15:44] <didrocks> mzanetti: hum, it should be 7.80.3-0ubuntu1
[15:44] <didrocks> rather than 7.80.2-0ubuntu1
[15:44] <dednick> Saviq: how are the plugins imported by unity8 nowadays? ie how does it know where to find them
[15:44] <didrocks> 7.80.2 < 7.80.2+blabla
[15:44] <mzanetti> didrocks: note that the -0ubuntu1 wasn't there before. so this would increase it already. but I don't know
[15:44] <didrocks> mzanetti: no no, you need to bump the upstream version
[15:44] <mzanetti> didrocks: ok
[15:45] <didrocks> mzanetti: btw, it's -0ubuntu1 (not -ubuntu1)
[15:45] <didrocks> did I mess up the doc?
[15:45] <mzanetti> didrocks: no
[15:45] <mzanetti> didrocks: you didn't mess up. I did
[15:45] <didrocks> mzanetti: ok, I'll add a blink tag then! :p
[15:45] <mzanetti> didrocks: do I actually need the -0ubuntu1 at all then?
[15:45] <mzanetti> it wasn't there before
[15:46] <didrocks> mzanetti: daily release should deal with native version, but you will have a lintian warning until then
[15:48] <mzanetti> didrocks: and the depending would be "libunity-api-dev (>= 7.80.3)", correct?
[15:48] <didrocks> mzanetti: exactly :)
[15:49] <Saviq> dednick, same as usual, TBH not sure why autopilot complained
[15:50] <Saviq> dednick, as Unity.Indicators is installed to ${SHELL_PRIVATE_LIBDIR}/qml correctly
[15:50] <Saviq> dednick, otherwise it would fail when simply ran
[15:52] <Saviq> dednick, if you can't figure it out, I will Monday
[15:52] <Saviq> EOW
[15:52] <Saviq> o/
[15:52] <dednick> Saviq: ok. have a good weekend
[15:55] <pstolowski> didrocks: ping
[15:56] <dednick> Saviq: how is the qml imported normally? how does it know to look in x86_64-linux-gbu/unity8/qml ?
[15:57] <dednick> could be because the executable isn't unity8? rather it's looking in x86_64-linux-gbu/indicator_client/qml
[15:57] <pstolowski> didrocks, seb128: quick question - can you run /usr/share/software-center/software-center-dbus in S?
[15:58] <seb128> pstolowski, do you get the bug Laney was just mentioning in #ubuntu-desktop?
[15:58] <didrocks> pstolowski: running here
[16:00] <pstolowski> seb128, didrocks: yes. this break App Scope results. and at least two of the AP tests
[16:00] <seb128> oh ok
[16:00] <seb128> that makes sense!
[16:00] <pstolowski> seb128, didrocks: 'More suggestions' category is missing in Apps. And all app previews miss data
[16:00] <dednick> anyone know how to get qml to output the import paths when you run an app?
[16:00] <didrocks> pstolowski: that starts to make sense with the hypothesis "it's the dist-upgrade from proposed" which breaks things
[16:01] <didrocks> pstolowski: I'm rerunning right now with new xorg, but nothing else dist-upgraded
[16:01] <mhr3_> dednick, QML_IMPORT_TRACE=1
[16:02] <dednick> mhr3_: ta.
[16:02] <dednick> bit extreme though ;)
[16:30] <dednick> Saviq: think i got it. forgot the fallback imports, so wasn't looking in unity8/qml when installed
[21:56] <RS> Hello - I was wondering if someone could give me some assistance please?  :-)
[21:57] <RS> I installed Lubuntu 10.x because my old laptop does not have pae - i upgraded and now have ubuntu 12.04 - but my desktop still shows Lubuntu and not Unity
[21:58] <RS> I would really like Unity but not sure how to get this now
[23:31] <RS> hi
[23:32] <RS> hi
[23:33] <RS> hi robotfuel
[23:34] <robotfuel> hi RS
[23:34] <RS> hi - I have a question - I am a new user - are u familiar with Ubuntu/Lubuntu?
[23:35] <RS> I mean can u help me with a technical question
[23:35] <robotfuel> RS: maybe you are interested in the #ubuntu channel, if you don't have a question about unity?
[23:36] <RS> this was the link for me to go to it said on another page - this is the ubuntu-unity room?
[23:37] <RS> http://webchat.freenode.net/?channels=#ubuntu-unity
[23:40] <RS> ?
[23:41] <RS> I am trying to use Unity
[23:41] <RS> but it is not working
[23:42] <arsson> http://askubuntu.com/questions/110516/is-there-a-way-to-install-unity-or-gnome-shell-along-with-lubuntu
[23:47] <RS> thank you arsson - I will check out the link
[23:51] <arsson> it may be risky