[01:36] <Atlantic777> Hey, what's happening with unity 2d? Is really discontinued?
[01:37] <Atlantic777> A bet is in question. :D
[01:49] <Daekdroom> Atlantic777, yes
[01:49] <Daekdroom> It is supported on those versions of Ubuntu that shipped with it by default and are still in support.
[01:49] <Atlantic777> So, I've just lost a bet and have to pay a lunch. :/
[01:50] <Atlantic777> I don't get how I missed that fedora guys did that thing with gallium and and that unity-2d is now == unity 3d
[01:51] <Atlantic777> Ok, thanks Daekdroom. If you see some way how can I get out of trouble, be free to share it with me. :D
[04:13]  * hyperair wishes there was still a single-keybinding way of opening the messaging menu.
[05:58] <veebers> didrocks: ping
[05:59] <didrocks> pong veebers
[05:59] <veebers> didrocks: Hi, I've just been looking at this None.ogv issue and I'm having trouble re-producing
[06:00] <didrocks> veebers: it seems to be everytime you run all the unity tests though
[06:00] <didrocks> veebers: seeing the logs, I wonder if it's not installed by autopilot-gtk
[06:00] <veebers> didrocks: also, because I haven't kept abreast of the Otto development, I'm not entirely certain where to look to see what and how things are done (i.e. what's installed and what autopilot command is used)
[06:01] <didrocks> veebers: see http://10.97.0.1:8080/job/autopilot-saucy-daily_release/27/label=autopilot-ati/
[06:01] <didrocks> veebers: look at the artefacts, and tell me if those don't make sense :)
[06:01] <didrocks> veebers: but they should be ordered in a logical way ;)
[06:02] <didrocks> veebers: you will see as well that there are lot more ogv that we found than failing tests
[06:02] <veebers> didrocks: sure will do. What's the autopilot command that used? is it something like autopilot run autopilot?
[06:03] <didrocks> veebers: http://10.97.0.1:8080/job/autopilot-saucy-daily_release/27/label=autopilot-ati/artifact/results/autopilot/testsuites
[06:03] <didrocks> everything should be listed in the artefacts ;) tell us if anything is missing ;)
[06:03] <didrocks> veebers: another issue we have is with recordmydesktop in general
[06:03] <didrocks> not sure it's because you record more ogv
[06:03] <didrocks> but it's exploding in memory
[06:03] <didrocks> like 4G when a test takes time
[06:03] <veebers> wow :-\
[06:04] <didrocks> we had to disable it (yesterday, so way after this run)
[06:04] <didrocks> we need to find a way so that it doesn't impact on the tests
[06:04] <veebers> agreed
[06:05] <veebers> didrocks: so that testsuites file shows me which tests were run (autopilot), can I see somewhere which autopilot command line options were used>
[06:06] <didrocks> veebers: ah, sure: http://bazaar.launchpad.net/~otto-dev/otto/testsuite_autopilot-unity/view/head:/target-override/usr/local/bin/run-autopilot.sh#L85
[06:06] <veebers> didrocks: awesome, thank you
[06:06] <didrocks> yw ;)
[06:06] <didrocks> AP_OPTS="-v -r -rd $AP_ARTIFACTS -f xml"
[06:06] <didrocks> in this run FYI
[06:07] <didrocks> then, because of the recordmydesktop issue we are using "-v -f xml" now
[06:07] <veebers> sure, makes sense
[06:14] <didrocks> veebers: I think you should maybe focus first on why more ogv than failing tests are generated?
[06:14] <didrocks> veebers: maybe the None.ogv will just jump from there ;)
[06:15] <veebers> didrocks: sure, at the moment I'm hoping to replicate it so I can debug :-)
[06:15] <didrocks> yep ;)
[06:37] <sil2100> didrocks: good morning \o/ It seems that Michal and Martin were able to locate the issue \o/ Should we re-build the scopes with the new vala?
[06:37] <sil2100> Actually, rebuild libunity
[06:37] <didrocks> hey, I don't know what we should rebuild
[06:38] <didrocks> sil2100: I'm waiting first for this vala version to be in the release pocket
[06:38] <didrocks> (not the case yet)
[06:38] <didrocks> sil2100: then, grabbing what we need rebuild would be interesting
[06:38] <didrocks> sil2100: something else, almost everything is green :)
[06:38] <didrocks> sil2100: but indicators has a lot of failures
[06:38] <didrocks> http://10.97.0.1:8080/job/autopilot-saucy-daily_release/label=autopilot-ati/44/
[06:39] <sil2100> Ah, ok, let's wait for that ;) Let me fire up the VPN
[06:39] <didrocks> I rerun with the videos
[06:39] <didrocks> I fixed the first issue (import issue for gtk-module-test)
[06:39] <didrocks> so the test will run on the next run
[06:39] <didrocks> but it seems we have 'menu_proxy_module_load': gedit: undefined symbol: menu_proxy_module_load
[06:39] <didrocks> that's why all tests are failing I gues
[06:39] <didrocks> *s
[06:39] <didrocks> if you can investigate… :)
[06:40] <didrocks> sil2100: I guess it's the last thing blocking us right now, I reran all the rest (apart from rebuilding what needs to be rebuilt)
[06:41] <sil2100> Those things look like real regressions indeed
[06:41] <sil2100> Seems like a problem with u-g-m
[06:41] <didrocks> sil2100: I would bet on a stupid dep missing!
[06:41] <sil2100> didrocks: could be, let me see that
[07:04] <sil2100> didrocks: damn, those videos show the unity panel doing crazy stuff
[07:04] <didrocks> sil2100: does it seem that the menu is exported?
[07:04] <sil2100> didrocks: not sure, because the panel is blinking and unity seems to spout crazy error messages
[07:04] <didrocks> urgh
[07:05] <sil2100> Checking dependencies again, might be that something is missing that's really making the panel go crazy
[07:06] <didrocks> maybe…
[07:09] <didrocks> sil2100: logging out and back with latest ppa content
[07:11] <didrocks> sil2100: I confirm it on my machine
[07:11] <didrocks> sil2100: same, panel is going crazy
[07:11] <didrocks> with menu beeing exported/not exported/exported…
[07:12] <didrocks> I have this:
[07:12] <didrocks> (gedit:14303): Gtk-WARNING **: Failed to load type module: (null)
[07:12] <didrocks> 'menu_proxy_module_load': gedit: undefined symbol: menu_proxy_module_load
[07:13] <didrocks> I don't have appmenu-gtk nor appmenu-gtk3 installed
[07:13] <didrocks> but unity-gtk3-module is installed
[07:14] <sil2100> didrocks: huh, I have unity-gtk3-module installed (no appmenu-gtk) and all is ok, hm
[07:15] <sil2100> What indicator-appmenu do you have?
[07:17] <sil2100> Since on the videos I see it tries to export the appmenu but can't
[07:18] <didrocks> yeah, same issue here
[07:19] <didrocks> sil2100: 13.01.0daily13.06.05-0ubuntu1
[07:21] <didrocks> sil2100: you do have latest and greatest from the ppa as well?
[07:23] <sil2100> didrocks: doing a full upgrade now
[07:23] <sil2100> didrocks: before I upgraded indicator-appmenu and unity-gtk-module, but this didn't break anything
[07:23] <didrocks> sil2100: ok :)
[07:23] <sil2100> I'm getting the (gedit:14303): Gtk-WARNING **: Failed to load type module: (null) errors, but it doesn't break the menus
[07:24] <sil2100> But let's see after the big upgrade
[07:25] <didrocks> sil2100: let's wait for mhr3 at the same time for the rebuild :)
[07:29] <pstolowski> sil2100, didrocks: hey! are we good with the fix mhr3 did to vala?
[07:30] <didrocks> pstolowski: hey hey! the fix is migrating to the release pocket as we speak
[07:30] <didrocks> pstolowski: now, we would need the list of things to rebuild
[07:30] <didrocks> only gdrive?
[07:30] <sil2100> pstolowski: hi! I think we should be good, I knew that you guys would be able to help ;)
[07:30] <didrocks> or all the other vala scopes/lenses?
[07:30] <sil2100> libunity as well
[07:30] <didrocks> and what to do with libunity? dee?
[07:30] <didrocks> :p
[07:31] <didrocks> so many questions!
[07:31] <sil2100> didrocks: we need to rebuild libunity I think?
[07:31] <pstolowski> didrocks: all vala scopes
[07:31] <didrocks> sil2100: not really sure what part of the code is impacted
[07:31] <didrocks> pstolowski: libunity/dee?
[07:31] <pstolowski> didrocks: and libunity, yes
[07:31] <sil2100> pstolowski, didrocks: where's mhr3 ;p ?
[07:32] <pstolowski> didrocks: dee is C, not vala
[07:32] <pstolowski> sil2100, didrocks: mhr3 is in london, so -1h
[07:32] <sil2100> Aaah
[07:32] <sil2100> ;)
[07:35] <sil2100> didrocks: ok, still after the upgrade cannot reproduce ;/ It seems I might have something installed that's fixing the issue
[07:36] <didrocks> sil2100: maybe a race, just upgrading to latest gtk in a ppa
[07:38] <didrocks> sil2100: you did restart your session since you upgraded?
[07:39] <sil2100> didrocks: yes, tested on a guest session
[07:41] <didrocks> ok, latest gtk didn't work
[07:41] <didrocks> let me revert to appmenu-gtk
[07:41] <didrocks> and see
[07:42] <didrocks> sil2100: the vala fix is available
[07:42] <didrocks> sil2100: mind running the unity stack, rebuild all vala scopes?
[07:42] <didrocks> sil2100: I'm fighting the revert meanwhile
[07:43] <sil2100> didrocks: ok, will do that in a minute, I'm checking something on my guest session
[07:43] <sil2100> pstolowski: when there is a new libunity, do the scopes need to be rebuilt, or not?
[07:46] <didrocks> sil2100: found it
[07:47] <didrocks> sil2100: unity-panel-service keeps crashing
[07:48] <sil2100> didrocks: but that's from unity, right?
[07:48] <sil2100> unity-services
[07:49] <sil2100> didrocks: I have the latest unity-services installed, hmm
[07:49] <pstolowski> sil2100: I think vala scopes need to be rebuild, but give us a moment, davidcalle is now doing some tests
[07:49] <sil2100> pstolowski, davidcalle: ACK, give me a sign what you think should be re-built exactly
[07:50] <sil2100> didrocks: the test environment also had the latest unity-services, so maybe some back-dep of that?
[07:50] <didrocks> sil2100: before getting a stacktrace, I'll try removing the network-indicator
[07:50] <didrocks> sil2100: as if one indicator is broken, the whole process segfault
[07:51] <sil2100> oh!
[07:51] <sil2100> Wait! I don't have indicator-network installed at all!
[07:51] <sil2100> So maybe that's it
[07:51] <sil2100> (since indicator-network is installed during the test-run)
[07:51] <didrocks> \o/
[07:51] <didrocks> \o/
[07:51] <didrocks> \o/
[07:52] <didrocks> it's THE one ;)
[07:52] <didrocks> sil2100: ok, last test… I'm moving back to unity-gtk-module
[07:52] <sil2100> didrocks: yess!
[07:52] <sil2100> \o/
[07:52] <didrocks> (I'm with appmenu-gtk now)
[07:52] <sil2100> It works! (I mean, it's broken)
[07:52] <didrocks> ahah
[07:52] <didrocks> :)
[07:52] <sil2100> didrocks: I have u-g-m and indicator-network and it crashes ;)
[07:53]  * didrocks moves back to u-g-m
[07:53] <sil2100> Ok, so, it's basically a bug with indicator-network
[07:53] <didrocks> sil2100: don't worry, indicator-network and appmenu-gtk is as bad :p
[07:53] <didrocks> no discrimination!
[07:53] <sil2100> didrocks: ;)
[07:53] <sil2100> Who's upstream for that so that we can poke?
[07:54] <didrocks> sil2100: bzr says Ted
[07:55] <didrocks> sil2100: ok, removing from the stack tests
[07:55] <didrocks> for indicators
[07:56] <didrocks> at least, it explains why the other stacks work, even with dist-upgrade
[07:56] <didrocks> and why Mirv and you didn't get it
[07:57] <didrocks> sil2100: mind annoting the spreadsheet meanwhile with one more item for cyphermox_?
[07:57] <sil2100> didrocks: ok, let's remove it until it gets fixed
[07:58] <sil2100> didrocks: noting ;)
[07:58] <didrocks> meanwhile, I'm editing so that we don't upload it
[08:00] <didrocks> launching indicator-network tests again
[08:01]  * tsdgeos got a cold :-'(
[08:02] <didrocks> tsdgeos: now that the weather is finally mostly fine in europe? :)
[08:02] <tsdgeos> didrocks: i think that's the reason
[08:02] <tsdgeos> went from 2 long sleeves to 1 long sleeve
[08:02] <tsdgeos> too soon
[08:03] <sil2100> It's still cloudy here, they even started heating again :o
[08:03] <sil2100> Since it was so cold
[08:03] <didrocks> sil2100: argh :/
[08:04] <didrocks> sil2100: btw, how were the otto logs?
[08:04] <didrocks> sil2100: the package list
[08:04] <didrocks> autopilot.log
[08:04] <didrocks> console output
[08:04] <didrocks> testsuite ran
[08:04] <didrocks> videos
[08:04] <sil2100> didrocks: awesome, it was intuitive, and I like the idea there are 2 package lists
[08:04] <didrocks> the hierarchy made sense?
[08:04] <didrocks> great! :)
[08:04] <sil2100> Yes, it's good to have it all in categories, since at least I knew right away where to look for the AP videos
[08:04] <didrocks> sil2100: we had long debate with jean-baptiste to find a good organization of artefacts :)
[08:05] <didrocks> debates*
[08:05] <didrocks> sil2100: if you have any improvment to propose, do not hesitate
[08:05] <didrocks> you see that every logs that are mixed (as it's in realtime) in the console can be found separated in the logs/ dir
[08:05] <didrocks> (once the build finishes)
[08:06] <sil2100> didrocks: I think right now it's ok, it's even good that there are AP logs both in logs/ and autopilot/
[08:06] <didrocks> yep :)
[08:06] <sil2100> davidcalle: any luck with the tests?
[08:08] <didrocks> sil2100: you're rebuilding the vala scopes already?
[08:08] <didrocks> ah david is doing tests
[08:08] <didrocks> ok, nevermind :)
[08:08] <davidcalle> sil2100, I installed the new vala packages, rebuilt libunity. The segfault is still there, maybe I'm missing a step?
[08:09] <sil2100> uuuuu
[08:09] <sil2100> davidcalle: ok, so, let's wait for mhr3 to appear
[08:10] <didrocks> sil2100: silly me, relaunched indicator without republishing the stack change :/
[08:10] <sil2100> didrocks: happens ;) I guess the check step will finish real quickly anyway
[08:11] <didrocks> yeah, it's not long
[08:11] <sil2100> davidcalle: but I was hoping rebuilding and reinstalling libunity would help ;/
[08:12] <mardy> after updating, since this morning Unity doesn't run in my Virtualbox (compiz crashes). Is it a known problem?
[08:12] <didrocks> mardy: hum, not sure about virtualbox, do you have any ppa?
[08:12] <didrocks> mardy: like the daily-build one?
[08:12] <sil2100> mardy: updating to what state? What PPA?
[08:13]  * didrocks lets sil2100 handling :)
[08:13] <mardy> sil2100: deb http://ppa.launchpad.net/ubuntu-unity/daily-build-next/ubuntu saucy main
[08:13] <sil2100> mardy: ah, we don't use daily-build-next anymore ;)
[08:14] <sil2100> mardy: try switching that to daily-build for saucy, we're using that now after the switch
[08:14] <didrocks> and nobody should use it, it's either "next" or distro
[08:14] <didrocks> daily-build-* are intermediates dangerous states
[08:14] <sil2100> mardy: ^ right
[08:14] <didrocks> only people who knows what to do should use them
[08:14] <didrocks> :p
[08:14] <sil2100> mardy: so just add ppa:ubuntu-unity/daily-build instead
[08:14] <sil2100> (if you want bleeding edge)
[08:15] <didrocks> (but with risks)
[08:15] <didrocks> sil2100: if the <blink> tag still existed, I would put that in the launchpad page for the ppa description :p
[08:15] <mardy> sil2100: thanks!
[08:19] <didrocks> sil2100: also, maybe see with james?
[08:20] <sil2100> haha ;)
[08:20] <didrocks> jamesh: hey!
[08:20] <davidcalle> didrocks, please never say beetlejuice :)
[08:20] <didrocks> davidcalle: ahah :)
[08:20] <sil2100> Ah! He's also on this channel ;)
[08:21] <sil2100> jamesh: hello!
[08:21] <sil2100> jamesh: we need a hand with the vala<->python3 thing we encountered with the unity-scope-gdrive
[08:22] <jamesh> sil2100: I'm setting up a test env to get a better look at the problem (didn't have a Saucy install available)
[08:22] <sil2100> jamesh: davidcalle can brief you more besides the e-mail that had been forwarded to you (probably?)
[08:22] <sil2100> jamesh: thanks :)
[08:22] <didrocks> jamesh: you will need the ppa:ubuntu-unity/daily-build ppa FYI
[08:22] <jamesh> okay
[08:30] <didrocks> mardy: oh, speaking of issues, when I'm not logged into my accounts, I'm getting on every dash click a blank page opened in chromium
[08:30] <didrocks> mardy: is that known?
[08:30] <didrocks> basically annoying when the accounts are timeouted :/
[08:35] <mardy> didrocks: Saviq reported the same issue; however, there isn't a bug for it files yet
[08:35] <mardy> didrocks: it would be interesting to know which scope is triggering this
[08:35] <Saviq> mardy, google docs
[08:35] <didrocks> mardy: I would bet the gdrive scope ;)
[08:35] <mardy> didrocks: and indeed this points to a problem in signon-ui as well
[08:35] <Saviq> yup
[08:36] <mardy> Saviq, didrocks: can either of you kill signon-ui, then run it from a terminal with "SSOUI_LOGGING_LEVEL=2 signon-ui" and see what it says when you type in the dash?
[08:37] <Saviq> pstolowski, bad timing :D we just moved lp:unity/phablet to lp:unity/8.0 and reset the history...
[08:37] <didrocks> sure
[08:37] <Saviq> pstolowski, I'm looking for a way to rewrite a set of commits on a new tree, will let you know
[08:37] <didrocks> Saviq: oh btw, once all those touch and unity 7 landed into saucy, we should coordinate on how to go forward on unity 8/MIR in saucy
[08:37] <Saviq> pstolowski, there's some conflicts already, though
[08:37] <didrocks> Saviq: and moving to a separate projects I guess
[08:37] <Saviq> didrocks, sure
[08:38] <didrocks> Saviq: hopefully either EOW or next Monday :)
[08:38] <Saviq> didrocks, separate project?
[08:38] <Saviq> didrocks, do we have to?
[08:38] <Saviq> didrocks, unity 8 is... just unity 8, we'd like to not stick any temporary name on it
[08:38] <didrocks> Saviq: there are pros and cons. Pros are time saving when branching without any history, separated and authenticated bug list
[08:38] <didrocks> Saviq: cons are what you told
[08:38] <didrocks> Saviq: I just think we should discuss and decide :)
[08:39] <Saviq> didrocks, ok will do
[08:39] <Cimi> mzanetti, ping
[08:39] <Saviq> brb
[08:40] <didrocks> mardy: ok, so lauching signon-ui opened this tab
[08:40] <didrocks> mardy: let me get you the logs
[08:40] <pstolowski> Saviq: uh, ok
[08:41] <Saviq> mardy, I can't reproduce now
[08:42] <mardy> Saviq: did you re-authenticate your account recently?
[08:42] <Saviq> mardy, it's not authenticated now
[08:42] <Saviq> mardy, but I did reauth several times in between
[08:47] <mardy> didrocks: ?? browser-request.cpp 121 acceptNavigationRequest  QUrl( "about:blank" )
[08:47] <mardy> browser-request.cpp 160 urlIsBlocked Scheme not allowed: "about"
[08:47] <mardy> didrocks: google wants to open the "about:blank" page, apparently...
[08:49] <asac> who owns the dash topic?
[08:49] <didrocks> mardy: and that's what I get
[08:49] <didrocks> mardy: the about:blank page
[08:49] <didrocks> asac: defines dash topic, there is the backend, the frontend, unity 7 and unity 8 :)
[08:50] <didrocks> mhr3_: hey hey!
[08:50] <didrocks> mhr3_: I think you already know the news :p
[08:50] <mhr3_> didrocks, that it didn't fix it?
[08:50] <mardy> didrocks: can you please file a bug? No need to attach the logs
[08:50] <mhr3_> yea, that's what i'm hearing right now
[08:51] <didrocks> mhr3_: yep, davidcalle tested it
[08:51] <asac> didrocks: whoever owns such goals: Phone dash utilizing 13.04 backend
[08:51] <mhr3_> i need bt
[08:51] <asac> apps and music scope preview
[08:51] <asac> etc.
[08:51] <mhr3_> didrocks, talking to david already
[08:51] <mhr3_> didrocks, will update you once there's something new
[08:51] <asac> i guess technical big picture person for dash is what i am looking for
[08:52] <didrocks> asac: there is some part which are backend, this is thostr_'s team (mhr3 and pstolowski are in that team) and for the graphical part, kgunn's team
[08:52] <didrocks> asac: Saviq is the tech lead for the frontend part
[08:52] <didrocks> mhr3_: thanks dude!
[08:52] <Saviq> asac, hey, how can I help?
[08:52] <didrocks> mhr3_: all the other issues (and newest ones from this morning) are now fixed! *Just* this last one :)
[08:52] <asac> hey
[08:53] <asac> Saviq: wanted to check about goals vs. reality starting from what was said in oakland :)
[08:53] <mardy> didrocks: one more thing: can you please try editing /usr/share/accounts/providers/google.provider and append a ",'about'" to the AllowedSchemes key?
[08:53] <asac> Saviq: will send you a /msg
[08:53] <Saviq> asac, sure
[08:53] <didrocks> mardy: sure
[08:53] <mardy> didrocks: you might need to restart the gdrive scope, I'm not sure
[08:54] <didrocks> ok
[08:54] <didrocks> mardy: well, starting the online-account deamon alone opens the page
[08:54] <didrocks> so I'll first try just restarting it
[08:55] <didrocks> mardy: no, didn't work, still have this about:blank page opened
[08:57] <mardy> didrocks: what about restarting the scope?
[08:58] <didrocks> mardy: I can't say 100% for sure as I'm in the middle of transition and can't restart the scope (because of the vala segfault)
[08:58] <didrocks> mardy: I'll keep you posted
[08:58] <didrocks> once the vala impacting gdrive issue is fixed
[08:59] <dednick> Saviq: ping
[08:59] <mardy> didrocks: vala? isn't the scope written in python?
[09:00] <didrocks> mardy: yeah, but libunity is in vala and the binding are making the scope segfaulting
[09:00] <didrocks> mardy: long story ;-)
[09:00] <mmrazik> didrocks: what is the status of daily release of dbus-cpp and location-service?
[09:00] <mmrazik> didrocks: I see rev 375 (from sergio) which adds daily_release
[09:00] <mmrazik> but then its not in trunk
[09:00] <didrocks> mmrazik: not our priority right now as per my email on ubuntu-devel and ubuntu-phone
[09:01] <mmrazik> and it seems like bzr blame is blaming you for the daily_releasE: False :)
[09:01] <didrocks> mmrazik: will be dealt after saucy landing
[09:01] <didrocks> mmrazik: right, he added that and was approved withot the packaging reviewed
[09:01] <didrocks> so we can't have that landed before sanity checking is done
[09:01] <mmrazik> didrocks: the thing is that previously (prior sergio added daily release) we were dputing into ppa so location-service can be built
[09:01] <didrocks> mmrazik: will be done before EOW
[09:01] <didrocks> mmrazik: see my email on the public ML ;)
[09:01] <mmrazik> now dbus-cpp is nowehere to be found for building location-service on saucy
[09:02] <didrocks> but please, don't add stuff to daily release that we didn't ack/reviewed the packaging
[09:02] <didrocks> (made the same remark to ken who approved some)
[09:02] <mmrazik> didrocks: ok. so I will just re-enable the PPA.
[09:02] <mmrazik> didrocks: thats why I"m asking ;)
[09:02] <didrocks> mmrazik: sounds good, I'll tell you once done
[09:02] <didrocks> mmrazik: can you ensure fginther is aware about it as well?
[09:02] <didrocks> mmrazik: he approved a new component the same way
[09:02] <sil2100> mhr3_: !
[09:03] <sil2100> mhr3_: good to see you around ;)
[09:03] <sil2100> jamesh, davidcalle, mhr3_: give us an update once something is known
[09:03] <didrocks> sil2100: as I think the issue is in good hands, are you continuing on the new components? mind if I make the list 1 bigger? :)
[09:03] <nic-doffay> Saviq, I'm getting loads of errors trying to build -s related to the hudclient...
[09:03] <nic-doffay> (On saucy)
[09:03] <Saviq> dednick, nic-doffay, will be with you in 5
[09:04] <didrocks> sil2100: would be good to have those first packaging reviewed done before EOD so that we can enable daily release as the next step
[09:04] <sil2100> didrocks: sure, I was just doing that - location-service fails to merge but we're resolving that
[09:04] <didrocks> sil2100: great, I'm adding the new extra one!
[09:04] <mmrazik> didrocks: let me just drop him (fginther) an e-mail so I don't forget
[09:04] <sil2100> didrocks: since I modified the packaging according to Mirv's reviews, but I need to get those in, which might take a moment
[09:04] <sil2100> didrocks: ACK ;)
[09:05] <didrocks> mmrazik: thanks a lot :)
[09:05] <didrocks> sil2100: I suggest once those listed are done that we:
[09:05] <didrocks> 1. go over everything in head which will still have daily_release: False
[09:06] <didrocks> (shouldn't be a lot)
[09:06] <didrocks> 2. go over the ones in phablet/ and see if they need to stay there or not
[09:06] <didrocks> (some double sanity checking, normally it's only the things we don't want in distro/not ready yet for it)
[09:10] <Saviq> nic-doffay, I've built from scratch yesterday, worked fine, did you merge trunk? there were some fixes to the build scripts for saucy yesterday
[09:10] <Saviq> dednick, pong
[09:11] <dednick> Saviq: is there currently anything telling us in the shell what type of platform we're running on? ie "phone" or "desktop". Like a global property. I believe the .indicator files are now going to have dbus paths dependent on the platform (or rather dependent on profile).
[09:11] <dednick> I know there is QT_QPA_PLATFORM. Is this suitable?
[09:11] <nic-doffay> Saviq, there haven't been any changes as of yet.
[09:12] <nic-doffay> I did a pull now before attempting.
[09:12] <Saviq> dednick, no, the qpa plugin will be the same
[09:12] <Saviq> dednick, FORM_FACTOR should be "phone" or "tablet" on them
[09:12] <Saviq> dednick, at least for now
[09:13] <Saviq> nic-doffay, try dropping ../unity_build and start from scratch
[09:13] <Saviq> nic-doffay, if that fails, please pastebin me the errors
[09:13] <dednick> Saviq: ok. i'm guessing this doesnt exist yet?
[09:13] <Saviq> dednick, it does
[09:13] <Saviq> dednick, or it should
[09:14] <nic-doffay> Saviq, https://pastebin.canonical.com/92254/
[09:15]  * hyperair grumbles about the blue messaging menu icon not being visible enough.
[09:16] <Saviq> nic-doffay, did you drop the previous build? it build fine here :/
[09:16] <hyperair> mpt: https://bugs.launchpad.net/indicator-messages/+bug/1136780 <-- can we have a configuration option for this pretty please?
[09:16] <Saviq> nic-doffay, try ./build_unity --clean
[09:16] <hyperair> mpt: i don't care if it's stuffed in gconf, i just don't want to keep not noticing my IMs for 20 minutes at a time.
[09:16] <hyperair> s/gconf/gsettings/
[09:17] <mhr3_> didrocks, so for some reason the vala patch doesn't seem to have effect
[09:18] <mhr3_> but looking at the diff in the pkg and buildlog it looks fine
[09:18] <mhr3_> will dig deeper
[09:18] <mhr3_> sil2100 ^
[09:19] <Saviq> nic-doffay, I just went for the ./build_unity --clean and it went fine
[09:19] <sil2100> mhr3_: thanks!
[09:19] <sil2100> mhr3_: when you tried the patch locally (when you were creating the patch), was it working then?
[09:19] <Saviq> nic-doffay, except for the people lens, but that's ok
[09:20] <didrocks> mhr3_: don't blame it so easily on pitti! :
[09:20] <didrocks> ;)
[09:20] <mhr3_> sil2100, sure, but i tested it with vala master, not 0.18, maybe that's the problem
[09:21] <mhr3_> but it shouldn't be really
[09:25] <nic-doffay> Saviq, no luck.
[09:26] <Saviq> nic-doffay, did you try dropping the whole of ../unity_build?
[09:26] <nic-doffay> I've removed the build dir
[09:26] <nic-doffay> Saviq,
[09:26] <mhr3_> sil2100, didrocks, applied the patch on top of stock valac-0.18.1, it works fine
[09:26] <nic-doffay> I'll try branching trunk again
[09:27] <Saviq> nic-doffay, make sure to remove the "unity_build" dir
[09:27] <nic-doffay> Saviq, that's what I've been doing.
[09:27] <Saviq> nic-doffay, it's there _below_ your branch
[09:27] <Saviq> nic-doffay, ok, I'm lost then :/
[09:28] <Saviq> mhr3_, any idea about https://pastebin.canonical.com/92254/ ?
[09:29] <mhr3_> didrocks, sil2100, i think the deb vala patch needs to contain also the patched .vala, not just the updated .c, cause valac builds itself
[09:30] <sil2100> hmmm
[09:30] <sil2100> mhr3_: would make sense, could you try that and build the package then locally?
[09:35]  * greyback reboots
[09:42] <mhr3_> Saviq, hmm, looks like the vapigen is trying to parse dee's gir instead of just using the vapi
[09:42] <mhr3_> i do remember seeing this problem long long time ago, not sure how was it fixed
[09:42] <mhr3_> probably just flags...
[09:43] <mhr3_> --pkg dee-1.0 to vapigen?
[09:43] <Saviq> mhr3_, any idea what could be different between mine and nic-doffay's setup that would cause this for him?
[09:43] <nic-doffay> Saviq, I may have fixed it...
[09:43] <Saviq> nic-doffay, oh good
[09:43] <mhr3_> Saviq, hard to say.. something locally built :)
[09:44] <nic-doffay> Saviq, nope.
[09:44] <mhr3_> nic-doffay, `locate dee-1.0.vapi`?
[09:51]  * tsdgeos updates to saucy
[09:51] <tsdgeos> wish me luck :D
[09:54] <tsdgeos> guys, when moving to saucy do i still need any of these ppa? qt-proper, phablet-team/tools, autopilot/ppa, ubuntu-sdk-team/ppa?
[09:54] <tsdgeos> Saviq: ↑↑
[09:55] <Saviq> tsdgeos, sdk yes
[09:55] <Saviq> tsdgeos, qt yes
[09:55] <Saviq> tsdgeos, at least for now
[09:55] <Saviq> tsdgeos, until sdk moves to daily release
[09:55] <tsdgeos> oka
[09:55] <Saviq> tsdgeos, well, qt could be omitted, probably
[09:56] <greyback> I disabled the qt PPA, but I've still mostly raring packages installed for it
[09:59] <Saviq> pstolowski, ok I have a way to rebase branches on top of the new history
[09:59] <Saviq> pstolowski, can I take your branch?
[10:00] <pstolowski> Saviq: great, sure, but you're going to MP it again so it's still reviewed?
[10:00] <Saviq> pstolowski, yeah, I'll resubmit it
[10:00] <Saviq> pstolowski, there was a conflict, though, did you merge?
[10:00] <pstolowski> Saviq: yes, I merged
[10:00] <Saviq> pstolowski, k
[10:40] <Saviq> pstolowski, yeah, it works! https://code.launchpad.net/~unity-team/unity/8.new-libunity/+merge/167733
[10:40] <Saviq> pstolowski, the only difference is that I've dropped the // line from plugin.cpp
[10:40]  * Saviq loves git :D
[10:41] <mhr3_> Saviq, shushhh, you can't say those three letters here!
[10:42] <pstolowski> Saviq: great. for a moment I thought you managed to install and test all this stuff :)
[10:42] <Saviq> mhr3_, yes I can, I just rewrote a bunch of commits on top of a new history
[10:42] <mhr3_> :-O
[10:42] <Saviq> mhr3_, and exported that to bzr
[10:42]  * mhr3_ breathes heavily
[10:42] <Saviq> ;D
[10:44] <Saviq> pstolowski, that's next on my TODO, I just need to throw all these branches onto the new history first
[10:45] <mmrazik> didrocks: I would need some help :-/ ppa:ubuntu-unity/daily-build-next has webbrowser-app 13.06.04 but there is no trace of those changes in trunk
[10:45] <mmrazik> e.g. this changelog is completely missing
[10:45] <mmrazik> https://pastebin.canonical.com/92259/
[10:45] <mmrazik> I wonder how that can happen
[10:45] <mmrazik> the pacakges from that ppa are built from trunk, aren't they?
[10:46] <mmrazik> i.e. only after the snapshot is merged and in trunk, right?
[10:46] <didrocks> mmrazik: interesting, let's have a look at the build
[10:46] <didrocks> mmrazik: ah, daily-build-next
[10:47] <didrocks> mmrazik: yeah, the merge back is only done once it's published
[10:47] <didrocks> so either daily-build -> distro
[10:47] <didrocks> or daily-build-next -> next
[10:47] <didrocks> mmrazik: btw, we moved back to daily-build -> distro right now
[10:47] <didrocks> and we are about to start publishing in a couple of hours
[10:48] <mmrazik> didrocks: so the changelog must be in trunk
[10:48] <mmrazik> and it is not :-/
[10:48] <didrocks> mmrazik: no
[10:48] <didrocks> mmrazik: it's only if you see it in the next ppa
[10:48] <didrocks> which is the publication phase
[10:48] <mmrazik> oh
[10:48] <didrocks> daily-build-next is a staging area
[10:48] <didrocks> as daily-build is
[10:48] <mmrazik> so there was a merge proposal which was then taken back?
[10:48] <mmrazik> (I couldn't find any)
[10:48] <didrocks> mmrazik: if it wasn't published, there is no merge back
[10:49] <didrocks> mmrazik: and we rebuild the day after with the old + new content
[10:49] <didrocks> mmrazik: basically daily-build-next and daily-build are "internal implementation" ppa
[10:49] <didrocks> people shouldn't use them
[10:49] <didrocks> they should use next or distro
[10:49] <mmrazik> didrocks: we are using them (don't know why) for the autopilot testing that is happening during merge proposal
[10:49] <didrocks> which is when those components are published (meaning, validated)
[10:49] <mmrazik> and right now it breaks it because 13.06.04 is higher than the version in trunk
[10:50] <mmrazik> mzanetti: ^^ is there any specific reason why we use the ppa in generic-mediumtests ?
[10:50] <didrocks> mmrazik: I guess it's because it's closer to the "staging" side
[10:50] <mmrazik> om26er: fyi ^^^
[10:50] <didrocks> so you don't wait for a full publication being done
[10:50] <didrocks> but really, the answer is a local repo I guess
[10:52] <didrocks> sil2100: do you have the MIR bug # for the scopes?
[10:52] <didrocks> seb128: do you know if there has been one for unity-gtk-module?
[10:53] <didrocks> oh right, there is one
[10:53] <didrocks> fix committed :)
[10:53] <didrocks> awesome
[11:10] <sil2100> didrocks: uno momento ;)
[11:10] <sil2100> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1185050
[11:11] <sil2100> didrocks: I didn't make one for unity-gtk-module, but I saw someone create it
[11:13] <didrocks> yeah, it's fine and done :)
[11:13] <didrocks> thanks for the link!
[11:14] <didrocks> sil2100: oh, it's not approved yet? can you ping mterry once he's around?
[11:14] <sil2100> didrocks: we got rid of the evolution scope?
[11:14] <didrocks> sil2100: you need to drop the evolution scope as well
[11:14] <sil2100> didrocks: just been asking about that :D
[11:14] <didrocks> sil2100: and please recheck the list against the MIR :)
[11:14] <didrocks> heh
[11:14] <sil2100> Since I was in the middle of editting the bug desc
[11:14] <didrocks> sil2100: I had to remove in the list the shopping lens, you kept it and it was making the tests failing (as home scope conflicts with it)
[11:15] <sil2100> Ouch, ok, sorry about that
[11:15] <sil2100> hm
[11:15] <sil2100> Maybe the home scope should conflict with the shopping lens then? In packaging?
[11:16] <didrocks> sil2100: it's already done
[11:16] <didrocks> I've done that a while ago
[11:16] <didrocks> the issue was the tests then trying to apt-get install both
[11:16] <didrocks> sil2100: that's why it wasn't listed in the experimental ppa ;)
[11:16] <sil2100> ;) Ok, my bad then!
[11:20] <greyback> Saviq: any tips on rebasing branches in bzr? Use git?
[11:21] <Saviq> greyback, yes, I'm doing
[11:21] <Saviq> greyback, gimme a branch if you want
[11:21] <sil2100> didrocks: hm, why did the build step of the unity stack pass 8 hours ago? How did the gdrive scope build correctly without the correct fix?
[11:21] <Saviq> greyback, I'm streamlining
[11:22] <greyback> Saviq: well I'd like to know how you're doing it. But lp:~gerboland/unity/refactor-wm-and-test/
[11:22] <sil2100> How can that beee?
[11:22] <Saviq> greyback, so... git-bzr-ng
[11:23] <Saviq> greyback, once: git bzr import lp:unity/8.0; git bzr import lp:unity/phablet
[11:23] <didrocks> sil2100: because I cheated :p
[11:23] <Saviq> greyback, for each: git bzr import $branch; git checkout $branch; git rebase phablet; git checkout 8.$branch 8.0; git cherry-pick phablet..$branch; git bzr push lp:~unity-team/unity/8.$branch
[11:24] <Saviq> greyback, resubmit
[11:24] <didrocks> and my evil plans are now discovered!
[11:24] <didrocks> sil2100: I moved the marker tracking what was uploaded for the gdrive scope so that we can have the -check job running the integration tests
[11:24] <sil2100> Oh noes!
[11:24] <greyback> Saviq: thanks, will give it a go
[11:25] <didrocks> sil2100: but good point, I need to move it back, I thought that we were going to rebuild it :)
[11:35] <mhr3_> sil2100, which ppa has latest unity that's installable on saucy? i tried daily-build-next, but it wants to remove unity
[11:37] <sil2100> mhr3_: no no, we dropped that one
[11:37] <sil2100> mhr3_: if you want the 'bleeding edge' thing right now, use ppa:ubuntu-unity/daily-build for saucy
[11:37] <mhr3_> thx
[11:38] <sil2100> mhr3_: just remember, that as always we can't guarantee if it's working or not, as it's not recommended to use the build PPA's ;)
[11:39] <mhr3_> no worries i can handle :)
[11:39] <seb128> didrocks, hey (sorry was eating), yeah there was one fix commited as you figured out ;-)
[11:40] <didrocks> seb128: yeah, and everything we want is approved it seems
[11:40] <didrocks> will just ping mterry once he's around
[11:45] <seb128_> didrocks, re, sorry wifi acting out there
[11:45] <sil2100> didrocks: the scopes MIR has most of the packages approved, as mterry approved it in the comments
[11:45] <sil2100> didrocks: but I guess he can top-approve it now too
[11:52] <didrocks> seb128_: no worry, I was telling:
[11:52] <didrocks> 13:40:35   didrocks | seb128: yeah, and everything we want is approved it seems
[11:52] <didrocks> 13:40:42   didrocks | will just ping mterry once he's around
[11:52] <didrocks> sil2100: right
[11:52] <seb128> didrocks, ok, let me know if I can help for anything
[11:53] <didrocks> seb128: not yet, I'm waiting for vala to be build to rebuild libunity
[11:53] <didrocks> published*
[11:53] <didrocks> and then running the integration tests
[11:53] <didrocks> (and running outside at the same time ;))
[11:53] <didrocks> seb128: I'm afraid it will be rather ready at 15h30
[12:09] <didrocks> sil2100: hum, as the hud needs the platform-api and pocket-sphinx, sphinx, sphinx-voxforge to build, we need those in main thinking about it
[12:09] <didrocks> sil2100: as well as gtester2xunit
[12:10] <didrocks> sil2100: which also means, we need hybris in mind
[12:10] <sil2100> Wasn't sphinx in main already?
[12:11] <didrocks> can be, I'm just listing the potential culpurits :)
[12:11] <sil2100> Need to check pocket sphinx though, I don't know if I checked it
[12:11] <didrocks> sil2100: sphinx3 is in universe
[12:12] <sil2100> Funny, I thought I checked that
[12:12] <sil2100> Ah, ok, I see now that I was checking for sphinx-common
[12:13] <sil2100> Ok, let me prepare a MIR for those - can I create one MIR for all of them? (just with all the components added)
[12:14] <Saviq> nic-doffay, remove vala-0.18, install vala-0.20
[12:15] <Saviq> paulliu had your issue and this ^ fixed it
[12:15] <nic-doffay> Saviq, awesome. Thanks a lot!
[12:15] <nic-doffay> paulliu, ^5 !
[12:17] <didrocks> sil2100: if sphinx 1 is in main, we can move sphinx 3 to main without any issue
[12:17] <didrocks> Saviq: but better to check all the voxforge things
[12:18] <didrocks> and pocket-*
[12:18] <sil2100> Ok, so for sphinx3 no MIR required?
[12:18] <didrocks> + platform-api, gtester2xunit and hybris
[12:18] <didrocks> sil2100: if it's an update from sphinx1 which is in main
[12:19] <Saviq> didrocks, :P
[12:19] <didrocks> oh no!
[12:19] <didrocks> I don't get why on this one…
[12:19] <didrocks> Saviq: sorry ;)
[12:21] <Saviq> greyback, are you doing lp:~gerboland/unity/refactor-wm-and-test ?
[12:21] <greyback> Saviq: slowly, yes
[12:21] <Saviq> greyback, if it's too complicated, just flatten it
[12:22] <Saviq> greyback, i.e. patch -p0 `bzr diff`
[12:22] <greyback> Saviq: I've rebased ok I think
[12:22] <greyback> Saviq: just the last steps have confused me
[12:22] <Saviq> greyback, ok, if you've rebased then you need to checkout 8.0
[12:22] <Saviq> greyback, so `git checkout -b 8.refactor-wm-and-test 8.0`
[12:22] <Saviq> that will make a copy of the 8.0 branch
[12:23] <greyback> yep done
[12:23] <Saviq> greyback, and then cherry pick into that
[12:23] <Saviq> greyback, so git cherry-pick phablet..refactor-wm-and-test
[12:23] <Saviq> which will cherry pick everything between phablet and refactor-wm-and-test
[12:23] <Saviq> greyback, and git bzr push, that's it
[12:27] <paulliu> nic-doffay: ./build -s installs back vala-0.18. Currently I'm doing sudo update-alternatives --config valac and manually assign it to vala-0.20...
[12:29] <Saviq> nic-doffay, there's no need for -s later
[12:29] <Saviq> nic-doffay, you can just go ./build_unity --clean after you've removed vala-0.18 and installed vala-0.20
[12:29] <Saviq> paulliu, ^
[12:30] <paulliu> Saviq: ah..ok
[12:36] <greyback> Saviq: fuck it I'm flattening, this will take me too long
[12:36] <Saviq> greyback, yeah, if it doesn't rebase ~cleanly
[12:36] <Saviq> greyback, just flatten, it doesn't matter
[12:37] <Saviq> greyback, OTOH after it's rebased, it should be just fine
[12:38] <greyback> Saviq: cherry-picking was full of conflicts. I may have screwed something up
[12:38] <Saviq> greyback, /me tries
[12:43] <Saviq> greyback|food, yeah, too many conflicts, not worth it
[12:47] <nic-doffay> Saviq, I'm in business again.
[12:47] <Saviq> nic-doffay, awesome
[12:47] <nic-doffay> Saviq, ah wait
[12:47] <nic-doffay> Something I assume relates to the PeopleLens.
[12:47] <nic-doffay> PeoplePreview.h?
[12:47] <nic-doffay> Getting errors...
[12:48] <nic-doffay> It's still being included.
[12:48] <nic-doffay> By peoplepreviewdata.h
[12:50] <Saviq> nic-doffay, drop build/CMakeCache.txt
[12:50] <Saviq> nic-doffay, or ./build -c
[12:53] <paulliu> nic-doffay: seems to me that libunity fails to build. -> PeoplePreview.h missing -> error in unity.
[12:53] <paulliu> I'm checking..
[12:54] <mardy> Saviq, didrocks: I reproduced the "about:blank" bug myself, I'll fix it soonish
[12:56] <Saviq> mardy, cool
[13:05] <olli> didrocks, ping
[13:06] <seb128> olli, he's out for some exercice, he should be back in 45min or so
[13:06] <seb128> olli, can I help?
[13:06] <olli> seb128, thx
[13:06] <olli> seb128, was just curious about things landing in S
[13:06] <olli> as usual
[13:08] <seb128> olli, most of the technical issues have been resolved but it turns out that hud2 pulls new stuff in (sphynx3, platform-api, gtester2xunit) that are in universe
[13:09] <seb128> olli, so those will need to go through main inclusion review/promoted, didrocks said he would work on that with mterry when he's back
[13:09] <seb128> olli, but that might push the landing to tomorrow
[13:09] <olli> seb128, alrighty, thanks for that - not necessarily what I wanted to hear, but oh well ;)
[13:10] <seb128> olli, yw, check out for specifics with didrocks when he's back but I think that's the big picture
[13:11] <seb128> olli, I opted in for the ppa this morning, the new dash is still quite buggy :/
[13:11] <seb128> like typing command + enter doesn't work half of the time
[13:12] <seb128> it doesn't take the enter, I need to go and click on the first choise
[13:12] <seb128> choice
[13:12] <olli> I need to update that and see where we are myself
[13:12] <seb128> and it takes often > 5s to list apps
[13:12] <olli> thanks for that information
[13:12] <seb128> or any result
[13:12] <seb128> yw, let me know if I can provide infos
[13:15] <paulliu> nic-doffay: to make libunity build.. quick fix. http://paste.ubuntu.com/5738715
[13:16] <paulliu> nic-doffay: I'm still checking why that sed is needed.
[13:19] <nic-doffay> paulliu, is a ./build_unity --clean sufficient after?
[13:19] <Saviq> mterry, ping
[13:19] <mterry> Saviq, hello
[13:19] <paulliu> nic-doffay: no. Saviq do you know who I can discusss the libunity with?
[13:20] <nic-doffay> paulliu, that's what I was afraid, because ./build won't work...
[13:20] <Saviq> paulliu, if we need to cherry-pick something from lp:libunity
[13:20] <Saviq> paulliu, lp:libunity/phablet is the thing we're using
[13:20] <Saviq> for a week or so still
[13:20] <paulliu> Saviq: ok..
[13:21] <Saviq> paulliu, any idea why everything would build fine here?
[13:22] <paulliu> Saviq: I don't know. Do you have any obsoleted packages installed? I do remove those packages in aptitude.
[13:23] <Saviq> paulliu, checking
[13:23] <paulliu> Saviq: what is your version of gobject-introspection and vala?
[13:24] <Saviq> paulliu, 1.36.0-2 and 0.18.1-0ubuntu4, respectively
[13:25] <pstolowski> seb128, olli: I've installed a new box today (raring -> saucy + ppa) after didrocks told me about those issues, and it works fine here.. and also for mhr3_.  I'd like to understand where the diff is coming from?
[13:26] <seb128> pstolowski, maybe you guys live in a world when internet bandwith is great and latency low where we don't?
[13:26] <pstolowski> seb128: I'm doing this in vbox
[13:26] <seb128> that doesn't change your internet latency afaik
[13:26] <pstolowski> seb128: and it's not exactl super fast. plus I've intel gfx
[13:27] <mhr3_> Saviq, eek, no, libunity doesn't like valac-0.20, don't
[13:27] <paulliu> Saviq: hmm. Current vala-0.18 is 0.18.1-0ubuntu9. But I think we did need vala-0.20 because 1.36.0-2 gobject-introspection doesn't work well with vala-0.18.
[13:27] <paulliu> The file format is a bit upgraded.
[13:27] <seb128> pstolowski, I'm not speaking about rendering issues, but long times to get results from the internet
[13:27] <seb128> pstolowski, the video driver shouldn't impact on that
[13:27] <Saviq> mhr3_, our libunity does
[13:27] <pstolowski> seb128: yeah, but 5 secs for apps?
[13:27] <Saviq> mhr3_, we're still in 13.04 libunity
[13:27] <mhr3_> Saviq, nope your doesn't either
[13:28] <pstolowski> seb128: online results - agree, this can vary
[13:28] <Saviq> mhr3_, but, but... but!
[13:28] <seb128> pstolowski, I got a few instances of 5-10s empty dash before getting a result, it's not doing it every time but I ran in it a couple of times in a morning
[13:28] <Saviq> mhr3_, ;(
[13:28] <seb128> pstolowski, also the main dash screen doesn't list custom commands anymore
[13:29] <mhr3_> Saviq, you upgraded because of the HudClient thing?
[13:29] <olli> do we have bugs for these issues yet?
[13:29] <olli> seb128, pstolowski
[13:29] <seb128> pstolowski, I've some custom launchers in ~/.local/share/applications since the update the dash home doesn't list those
[13:29] <Saviq> mhr3_, ah wait - yes, 0.18 _does_ like it
[13:29] <Saviq> mhr3_, I have no issues
[13:29] <Saviq> mhr3_, but yeah, hud wouldn't build with 0.18
[13:29] <mhr3_> let me try that
[13:29] <pstolowski> seb128: well, that's app lens thing, not sure how/why we regressed here... please file a bug
[13:30] <seb128> pstolowski, the app lens works fine, it lists it, it's the home lens which doesn't
[13:30] <seb128> pstolowski, @bug: sure
[13:30] <paulliu> mhr3_: wait.. what's your arch?
[13:30] <mhr3_> paulliu, 64
[13:30] <seb128> olli, not sure what we have bugs for, I will check and report bugs that are not filed yet
[13:30] <paulliu> nic-doffay: your arch?
[13:30] <seb128> olli, didrocks reported a few of the issues already from what I understood
[13:31] <nic-doffay> paulliu, i386
[13:31] <paulliu> mhr3_: wait. That could be arch problem. I'm also i386.
[13:31] <mhr3_> hmm, interesting
[13:32] <mhr3_> paulliu, so what fails for you? hudclient as well?
[13:32] <paulliu> mhr3_: I met a same bug other place.
[13:32] <nic-doffay> mhr3_, hud-client is fine now.
[13:32] <mhr3_> so what's failing guys? :)
[13:32] <paulliu> mhr3_: only on amd64 on Debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707404
[13:33] <paulliu> mhr3_: yeah, same hud-client.
[13:33] <Saviq> greyback|food, ok, go without me
[13:33] <Saviq> greyback|food, something's bad here
[13:34] <mhr3_> paulliu, valac --version?
[13:34] <paulliu> mhr3_: 0.18 failed. 0.20 works for me.
[13:34] <paulliu> mhr3_: currently it is Vala 0.20.1 and it builds.
[13:34] <paulliu> mhr3_: But Vala 0.18.1 doesn't work.
[13:34] <mhr3_> what was the one that was failing?
[13:35] <mhr3_> need exact pkg name
[13:35] <mhr3_> cause -ubuntu7 was probably broken, -ubuntu9 should work
[13:35] <paulliu> mhr3_: vala-0.18 version: 0.18-1-0ubuntu9
[13:35] <mhr3_> ubuntu7 was in the archives only for a while this morning
[13:35] <pstolowski> seb128: regarding "I got a few instances of 5-10s empty dash before getting a result, it's not doing it every time but I ran in it a couple of times in a morning", was it when you were getting online results? or local results (files, apps) were delayed too?
[13:35] <mhr3_> paulliu, did up upgrade since the failure?
[13:36] <seb128> pstolowski, I'm opening the dash, typing something and having nothing listed for 5 to 10s
[13:36] <seb128> no local, no remote
[13:36] <pstolowski> seb128: and when it eventually shows up, it's both local & remote content?
[13:36] <paulliu> mhr3_: wait, let me re-confirm it.
[13:38] <paulliu> mhr3_: still failed to build with vala-0.18
[13:38] <mhr3_> paulliu, pls pastebin the error
[13:38] <paulliu> ok wait.
[13:40] <paulliu> mhr3_: http://paste.ubuntu.com/5738769/
[13:40] <mhr3_> paulliu, and this is -ubuntu9?
[13:40] <seb128> pstolowski, I jus tried with "gedit"
[13:40] <seb128> pstolowski, I get local content from folders, but no app lens nor gedit app
[13:40] <seb128> then remote content
[13:41] <paulliu> mhr3_: yes
[13:41] <seb128> pstolowski, hum, trying to make screencast but gtkrecormydesktop is unhappy
[13:41] <mhr3_> paulliu, ok, maybe we need -ubuntu10 :)
[13:41] <paulliu> mhr3_: what's the problem there?
[13:41] <mhr3_> i need to check to be sure, give me sec
[13:42] <mhr3_> paulliu, but fwiw, as long as you build libunity with 0.18, you're free to build the rest with 0.20
[13:42] <mhr3_> that should work for now
[13:42] <seb128> pstolowski, mhr3_: the app lens activate twice on enter for me, is that known?
[13:42] <pstolowski> seb128: I'm just trying to find out if your query matches only online content  in which case a slow network response would be the culprit
[13:43] <seb128> like app lens -> type a name (gedit, eog ,...) + enter, 2 instances open
[13:43] <paulliu> mhr3_: ok.
[13:43] <seb128> pstolowski, my queries are "gedit" and "eog" in those tests
[13:43] <pstolowski> seb128: ah, ok
[13:43] <seb128> pstolowski, they should match the corresponding apps?
[13:43] <mhr3_> seb128, works fine here
[13:43] <pstolowski> seb128: sure, apps should show up immediately
[13:43] <pstolowski> seb128: single enter works for me as well
[13:43] <mhr3_> wait
[13:43] <mhr3_> terminal does open twice
[13:44] <seb128> in the app lens?
[13:44] <mhr3_> home
[13:44] <seb128> ok, I'm trying in app
[13:44] <seb128> list super-a + gedit + enter
[13:44] <seb128> opens gedit with 2 tabs
[13:44] <sil2100> kenvandine: ping!
[13:44] <pstolowski> seb128: wow, indeed
[13:44] <seb128> pstolowski, ah, I'm not crazy ;-)
[13:44] <kenvandine> sil2100, pong
[13:45] <seb128> pstolowski, let me open a bug
[13:45] <seb128> pstolowski, on the app lens?
[13:45] <mhr3_> yea, i can repro too
[13:45] <pstolowski> seb128: no, unity
[13:46] <sil2100> kenvandine: do you have a moment for 2 quick reviews ;) ?
[13:46] <sil2100> kenvandine: https://code.launchpad.net/~sil2100/dbus-cpp/packaging_review/+merge/167286 (besides packaging fixes, it also has a FTBFS fix in the source)
[13:47] <sil2100> kenvandine: https://code.launchpad.net/~sil2100/location-service/packaging_review/+merge/167327 (this won't go in until dbus-cpp is in)
[13:47] <kenvandine> ok, i'll look
[13:47] <seb128> mhr3_, pstolowski: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1188191
[13:47] <seb128> mhr3_, pstolowski: do you have a tag for bugs on the new scopes?
[13:47] <sil2100> kenvandine: it seems Mirv also reviewed those, but if you find them ok, could you top-approve?
[13:48] <sil2100> kenvandine: thanks :)
[13:48] <kenvandine> sil2100, sure, so they are both ready?
[13:48] <mhr3_> seb128, use 100scopes
[13:50] <sil2100> kenvandine: yes ;)
[13:51] <sil2100> kenvandine: it's just that probably the location-service one won't merge yet, but top-approving won't hurt
[13:52] <Mirv> kenvandine: yes, but you can check once more of course
[13:52] <dandrader> Saviq, is the term "Unity Next" dead. Should we just use "Unity 8.0" from now on?
[13:52] <Saviq> dandrader, yes
[13:53] <Saviq> dandrader, it's stillborn, more ;)
[13:53] <greyback> Good old metacity
[13:53] <mhr3_> seb128_, can you record a video of your no-local-results for quite some time pls?
[13:54] <seb128_> mhr3_, I'm trying but gtk-recordmydesktop record a blank area
[13:54] <seb128_> mhr3_, I've a meeting in 5 minutes but will try again after than ... didrocks said he did a video though I think?
[13:55] <mhr3_> his video is completely broken too
[13:56] <mhr3_> use kazam guys, that actually works with compositing
[13:56] <mhr3_> and 3d
[13:57] <seb128_> k, gtk-recordmydesktop used to work
[13:57] <seb128_> it's the first time I get that issue
[14:03] <didrocks> sil2100: do you have the links for the MIR?
[14:06] <didrocks> mhr3_: are you working on bug #1188191?
[14:07] <didrocks> mhr3_: I think it's a blocker for the landing
[14:07] <mhr3_> guess i will in that case
[14:08] <didrocks> mhr3_: we'll need a test I guess for it :p
[14:11] <pstolowski> seb128: can you record your session with bustle when the problem of no local results for 5secs happens?
[14:11] <didrocks> mterry: around? do you have a minute?
[14:11]  * didrocks would have prefer sil2100 to be around before pinging mterry
[14:11] <mterry> didrocks, I'm around but give me a few
[14:12] <kenvandine> sil2100, not blocking merging this, but did you see the CI failure for location-service?
[14:12] <kenvandine> No such ppa: 'nexta'.
[14:12] <kenvandine> looks like a typo in the ppa name
[14:13] <sil2100> o/
[14:13] <sil2100> didrocks: MIR for the sphinxes?
[14:13] <sil2100> didrocks: or for 100 scopes?
[14:13] <sil2100> kenvandine: I know, but we don't use next anyway
[14:13] <didrocks> sil2100: sphinx, libhybris, gtester2xunit
[14:14] <kenvandine> yeah, not related to this merge
[14:14] <sil2100> kenvandine: I told you, it won't merge ;) Since dbus-cpp is missing
[14:14] <didrocks> kenvandine: so, on dee
[14:14] <sil2100> didrocks: I have for sphinx, one moment
[14:14] <sil2100> didrocks: https://bugs.launchpad.net/ubuntu/+source/pocketsphinx/+bug/1188203
[14:14] <didrocks> kenvandine: I don't remember if it was sil2100 or davidcalle who tested it, but they told me in site-packages it works
[14:14] <sil2100> Quickly adding the rest (seperate MIRs I guess)
[14:14] <didrocks> kenvandine: did you try to move it in dist-packages?
[14:15] <didrocks> kenvandine: stop speaking! :p
[14:15] <didrocks> sil2100: yeah, separate please :)
[14:15] <kenvandine> didrocks, well it's the only override  in that directory
[14:16] <mhr3_> paulliu, the error in HudClient was because of ubuntu7, it builds fine with 9, you just need to rebuild it
[14:16] <kenvandine> same on both of my saucy boxes
[14:16] <kenvandine> and it breaks CI for the friends stack
[14:16] <mhr3_> nic-doffay, what error are you getting now? or you're all good now?
[14:16] <kenvandine> didrocks, ^^
[14:16] <didrocks> kenvandine: can you try moving it to dist-packages locally?
[14:16] <didrocks> kenvandine: and tell me if this works?
[14:17] <didrocks> kenvandine: I don't know why autotools are installing them in site-packages
[14:17] <nic-doffay> mhr3_, still $£%£$%£$
[14:17] <kenvandine> didrocks, so maybe if the other packages get rebuilt they'll get moved too?
[14:17] <mhr3_> nic-doffay, still the hudclient thing?
[14:17] <didrocks> kenvandine: with python 3.3 yeah, but they will FTBFS
[14:17] <paulliu> mhr3_: really?
[14:17] <nic-doffay> mhr3_, no. Will pastebin you now...
[14:17] <didrocks> kenvandine: thanks to --fail-missing :p
[14:18] <didrocks> kenvandine: that's how I noticed the directory move
[14:18] <didrocks> kenvandine: just move it locally and keep me in touch
[14:18] <mhr3_> nic-doffay, thx
[14:18] <nic-doffay> mhr3_, https://pastebin.canonical.com/92274/
[14:18] <kenvandine> didrocks, yes, if i move it to /usr/lib/python3/dist-packages/gi/overrides/ it works
[14:19] <mhr3_> nic-doffay, where do you have unity-core from? rather which rev do you have?
[14:19] <paulliu> mhr3_: I think nic-doffay's problem is this http://paste.ubuntu.com/5738715/
[14:19] <kenvandine> didrocks, this is one going to keep us from getting the friends stack fixed :)
[14:19] <paulliu> mhr3_: I have to remove that line to get libunity build, then I can have PeoplePreview.h
[14:19] <didrocks> kenvandine: ok, let me do it badely then :p
[14:19] <kenvandine> didrocks, thanks :)
[14:20] <mhr3_> paulliu, no, you're changing libunity, that has nothing to do with unity-core
[14:20] <paulliu> mhr3_: unity-core depends on libunity.
[14:20] <pstolowski> seb128: can you record your session with bustle when reproducing the problem with local results not showing up immediately?
[14:20] <paulliu> mhr3_: if libunity doesn't build, unity-core doesn't build.
[14:20] <seb128> pstolowski, will do after that meeting
[14:20] <paulliu> mhr3_: thus phablet will complain about missing unitycore headers.
[14:20] <mhr3_> paulliu, right but it does build :)
[14:20] <pstolowski> seb128: cool, thanks, do you need a hand with it?
[14:21] <mhr3_> paulliu, or doesn't it?
[14:21] <seb128> pstolowski, no, I think I should figure it
[14:21] <paulliu> nic-doffay: Can you ls ../unity_build/build/include and paste it?
[14:21] <mhr3_> the build "system" phablet is using could maybe stop on build errors
[14:21] <paulliu> mhr3_: I think it doesn't.. let's check with nic-doffay.
[14:22] <nic-doffay> paulliu, libhud-1  libhud-client-2  libhud-gtk-1  unity
[14:22] <paulliu> mhr3_: ^ I got the same error if I don't patch libunity.
[14:22] <mhr3_> nic-doffay, fwiw i just did completely clean build of phablet, with ./build -s && ./build and things did build successfully (minus people lens i think)
[14:23] <paulliu> mhr3_: libunity isn't there. And thus UnityCore isn't there.
[14:23] <Cimi> Saviq, on the calendar, how would you write the models for the events? (highlighting if a day has an event or not)
[14:24] <Saviq> Cimi, I think the calendar needs to request a list of highlighted dates for the currently displayed span
[14:24] <mhr3_> paulliu, "unity" is libunity
[14:24] <Cimi> Saviq, from each day, I have the date
[14:25] <Cimi> Saviq, might need a property containing all the highlighted days
[14:25] <Saviq> Cimi, yes
[14:25] <Cimi> and if date is in this property -> highlight
[14:25] <mhr3_> paulliu, but yes Unity-6.0 is not there, so unity-core failed
[14:25] <Cimi> makes sense
[14:25] <Saviq> Cimi, yup
[14:26] <mhr3_> nic-doffay, got a log from `./build -s` when it's building lp:unity?
[14:26] <nic-doffay> mhr3_, doing another ./build -s now
[14:26] <nic-doffay> will pastebin...
[14:26] <mhr3_> k
[14:27] <mterry> Saviq, did you say you had an easy way to rebase on unity8.0 branch?
[14:27] <Saviq> mterry, depends, is there a lot of merges and such?
[14:27] <mterry> Saviq, yeah
[14:27] <Saviq> mterry, then no, not worth it - just flatten
[14:28] <Saviq> mterry, i.e. `bzr diff > diff; patch -p0 < diff`
[14:28] <Saviq> mterry, bzr really hates rebasing
[14:29] <Saviq> mterry, I can try, though, which branch?
[14:29] <mterry> Saviq, no worries, I'll flatten
[14:29] <paulliu> bzr-rewrite is obsoleted..
[14:30] <paulliu> Is there another rebase plugins for bzr?
[14:31] <Saviq> paulliu, yes, git :D
[14:32] <sil2100> didrocks: https://bugs.launchpad.net/ubuntu/+source/gtester2xunit/+bug/1188216 https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1188213
[14:32] <Saviq> paulliu, but the real problem is that bzr discourages it, so you start merging, and then there's no rebasing at all, really
[14:32] <sil2100> didrocks: I'll poke mterry once he's arounda bout those
[14:32] <mterry> sil2100, didrocks hello
[14:32] <didrocks> sil2100: thanks!
[14:32] <mterry> available now
[14:33] <sil2100> mterry: could you take a look at the 3 MIRs I pasted?
[14:33] <sil2100> (i.e. also this:
[14:33] <mterry> sil2100, so many mirs, ok
[14:33] <sil2100> https://bugs.launchpad.net/ubuntu/+source/pocketsphinx/+bug/1188203
[14:33] <sil2100> )
[14:33] <sil2100> And the 100 scopes MIR as well ;)
[14:33] <sil2100> mterry: sorry about that!
[14:33] <mterry> sil2100, is there new stuff on the 100 scopes one?
[14:33] <mterry> I thought those were all done
[14:33] <sil2100> mterry: no, it's done, but we thought you could maybe top-approve it ;)
[14:33] <sil2100> Or something ;p
[14:34] <didrocks> mterry: we need the new hud for new unity
[14:34] <didrocks> mterry: and it's building on armhf with touch support
[14:34] <didrocks> hence those
[14:34] <didrocks> sil2100: I'll take care of gtester2xunit
[14:34] <didrocks> mterry: ^
[14:34] <mterry> k
[14:34] <didrocks> mterry: libhybris has a review already for NEW, but I would prefer we ask for a Security review
[14:34] <didrocks> mterry: so prepromotion (jdstrand isn't around) and we don't install it by default for now
[14:35] <didrocks> if you can handle sphinx quickly, that will unblock us (I plan to land everything early tomorrow)
[14:35] <mterry> didrocks, where's jdstrand?
[14:35] <didrocks> mterry: vacations
[14:35] <mterry> bummer
[14:35] <didrocks> isn't it?
[14:35] <didrocks> mterry: do you think you have time to look at that now?
[14:35] <mterry> didrocks, sphinx?  sure
[14:37] <didrocks> mterry: *sphinx* I meant (seems 3 sources ;))
[14:37] <didrocks> thanks!
[14:39] <mterry> didrocks, yar
[14:39] <nic-doffay> mhr3_, no luck for me.
[14:39] <nic-doffay> ./build -s completes though.
[14:39] <mhr3_> nic-doffay, log pls?
[14:39] <mhr3_> nic-doffay, and as i said, ./build is stupid and doesn't stop on errors
[14:43] <sil2100> didrocks: regarding address-book-service
[14:44] <sil2100> didrocks: would you mind if I rename the source package name to address-book-service? Since currently it's galera-contact-service
[14:44] <sil2100> Or, the other way around (if sounds better)
[14:45] <didrocks> sil2100: maybe #ubuntu-touch? so that they pick one :)
[14:45] <didrocks> sil2100: I have no strong opinion between the 2 :)
[14:45] <sil2100> Will discuss ;)
[14:45] <didrocks> sil2100: did you file the MIR for platform-api?
[14:47] <Cimi> Saviq, tedg, I'm working on the timezone component, how shall we display times? we have like a string for the location and a string for the time or it will have to handle the calculation of time?
[14:47] <Cimi> (like you give BST and it calculates the time, then "europe/Rome" and etc)
[14:48] <Saviq> Saviq, if you ask me, I expected the backend to provide the current time for Rome, not the UTC offset

[14:48] <Saviq> Cimi, ^
[14:48] <Saviq> not only am I talking to myself, but also asking myself
[14:48] <Cimi> ok
[14:48] <Cimi> so the component will be basically a list item with two labels
[14:48] <Cimi> that's it
[14:48] <sil2100> didrocks: it seemed to be in main?
[14:49] <sil2100> didrocks: ah, wait, sorry ;p
[14:49] <Cimi> tedg, code is live here lp:~cimi/indicators-client/system-components
[14:49] <sil2100> didrocks: damn, I really should look better, since it was in main in daily-build
[14:49] <Saviq> Cimi, yes, the widgets are to be more or less dumb
[14:50] <sil2100> -_-
[14:50] <Cimi> Saviq, so I think it's mostly done then
[14:50] <Cimi> Saviq, I need reviews
[14:50] <Cimi> and timezone will require to drop the timers
[14:51] <Saviq> Saviq, can you drop me an email with what we're to look at?
[14:51] <sil2100> didrocks: the thing is, hm, is it in universe at all?
[14:51] <tedg> Cimi, We were just talking about that in the system settings call :-)
[14:51] <Cimi> cool
[14:51] <tedg> Cimi, Do we need that to be it's own project?
[14:51] <mmrazik> didrocks: I'm just talking with Wellark and wondering in which stack should I put lp:unity-action-api
[14:51] <Cimi> tedg, my branch is from scratch
[14:51] <mmrazik> it also looks like lp:unity-scopes-api is not covered anywhere
[14:51] <Cimi> Saviq, ^
[14:51] <Saviq> tedg, we just need it to be share-able between settings app and shell, right?
[14:52] <tedg> Cimi, Sure, I was more thinking for daily builds and getting in distro, etc.
[14:52] <Cimi> yes
[14:52] <Saviq> tedg, so we just need it to be packaged so that both can depend on it
[14:52] <didrocks> sil2100: it will be tomorrow
[14:53] <didrocks> sil2100: that's part of what we are going to upload
[14:53] <didrocks> mmrazik: what is depending on it?
[14:53] <tedg> seb128, Can you tag someone on your team to help out here? ^
[14:53] <seb128> pstolowski, mhr3_: ok, I'm done with my meeting what do you need? bustly log?
[14:53] <Saviq> tedg, I don't care either way, TBH
[14:53] <mmrazik> Wellark_: ^^
[14:53] <pstolowski> seb128: bustle log, yeah, that could help
[14:53] <sil2100> didrocks: hm, I'll have to fill it against the upstream project
[14:53] <seb128> tedg, help on what?
[14:53] <sil2100> didrocks: since downstream project is empty, so it cannot be assigned
[14:53] <mhr3_> seb128, yea, that will work
[14:54] <tedg> seb128, Getting Cimi's system components packaged and with dailies into distro.
[14:54] <tedg> seb128, Sorry the ^ made more sense when I started typing :-)
[14:54] <Cimi> seb128, I need like a day to move them in a new project before
[14:54] <seb128> tedg, ah, that's a job for kenvandine/didrocks
[14:54] <Cimi> can do that tomo
[14:55] <seb128> kenvandine, ^ can you help on getting the system components in the daily rolling machine?
[14:55] <mmrazik> didrocks: Wellark_ is joining but I was told it will be part of the sdk offering
[14:55] <didrocks> sil2100: please opened against upstream, we'll deal with it
[14:55] <sil2100> https://bugs.launchpad.net/platform-api/+bug/1188223
[14:55] <Wellark_> mmrazik, didrocks: nothing depends on it ATM, but the UITK will use it
[14:55] <sil2100> mterry, didrocks: ^
[14:56] <Wellark_> and also the upcoming launcher and appindicator QML APIs
[14:56] <didrocks> Wellark_: the sdk team will own it?
[14:56] <Wellark_> didrocks: unity-api-team owns it
[14:56] <mterry> sil2100, so many new things!
[14:56] <sil2100> mterry: sorry about thaat!
[14:56] <sil2100> ;p
[14:56] <Wellark_> didrocks: we are providing the unity api's
[14:56] <didrocks> mterry: let's see who finishes first :p
[14:56] <mmrazik> Wellark_: oh.. there is unity-api-team? The trunk should probably go there then?
[14:57] <kenvandine> seb128, i can do that
[14:57] <didrocks> Wellark_: is it the same team than sdk?
[14:57] <mterry> didrocks, did you want platform-api?
[14:57] <didrocks> Wellark_: or another one?
[14:57] <seb128> kenvandine, thanks
[14:57] <Wellark_> mmrazik: I don't think we have a team set up in launchpad
[14:57] <seb128> tedg, ^
[14:57] <Cimi> kenvandine, I'll give you details tomorrow
[14:57] <mmrazik> Wellark_: https://launchpad.net/~unity-api-team
[14:57] <kenvandine> Cimi, thanks
[14:57] <didrocks> mterry: not sure, get christmas time here, let's see once I'll have finished what I have, ok?
[14:57] <mterry> didrocks, sure, I can take it too
[14:57] <tedg> seb128, kenvandine, thanks guys!
[14:57] <Cimi> I'll aft a bit, catch later
[14:57] <Wellark_> mmrazik: oh, tedg has created the team :)
[14:58] <Wellark_> mmrazik: but that team has only 12 members
[14:58] <didrocks> Wellark_: I don't care in term of launchpad team, I think it can be platform or sdk depending with who you are working the most closely :)
[14:58] <nic-doffay> mhr3_, sorry for the delay: https://pastebin.canonical.com/92287/
[14:59] <Wellark_> didrocks: I think unity-team would be the most appropriate one
[14:59] <didrocks> Wellark_: no
[14:59] <didrocks> Wellark_: the sdk don't dep on unity
[14:59] <didrocks> unity dep on the sdk
[14:59]  * mmrazik votes for sdk
[15:00] <didrocks> mmrazik: let's put in sdk, seems the most logical to me as well :)
[15:00] <Wellark_> this API will be part of our SDK offerings, but the sdk-team does not maintain it
[15:00] <mmrazik> didrocks: do you want to review the MP or as long as there is "daily_release: False" you don't care much ?
[15:00] <didrocks> Wellark_: just be good citizen, if one of the components break, none will be publish :)
[15:00] <Wellark_> and by "SDK offerings" meaning an API we will commit to for our app deelopers
[15:00] <didrocks> mmrazik: no, as we discussed it together in term of stack, as long as there is False for daily_release, I'm fine :)
[15:01] <mhr3_> nic-doffay, you have valac-0.20, so libunity failed to build, which made unity-core fail, which makes phablet fail
[15:01] <mmrazik> didrocks: ok
[15:01] <didrocks> thanks!
[15:01] <nic-doffay> mhr3_, I see.
[15:01] <mmrazik> Wellark_: I think I have all I need now. I'll create a test MP (with a clear statement "please do not approve") to test the coverage reporting etc
[15:01] <didrocks> sil2100: hum, did you check the MIR before filing it? :/
[15:01] <mmrazik> I'll ping you once everything is up and running
[15:01] <nic-doffay> mhr3_, I needed valac-0.20 to get around the last build error though :/
[15:02] <didrocks> sil2100: python-junitxml is in universe, isn't it?
[15:02] <seb128> pstolowski, mhr3_:  bustle log will have to wait, I had to reboot in the middle of that meeting because my laptop frozen and now my dash behave without delay
[15:02] <Wellark_> didrocks: so you have some notion of stack which affects the autolanding?
[15:02] <mhr3_> nic-doffay, that issue was temporary (you could only get this this morning from 5:48am to 10:37am), it works now :P
[15:02] <Wellark_> as I said, the API is not used by anyone right now
[15:03] <Wellark_> but it will be by the end of this month
[15:03] <mmrazik> Wellark_: the stack affect the landing to distro
[15:03] <Wellark_> and the primary user will be UITK
[15:03] <didrocks> Wellark_: right, see https://wiki.ubuntu.com/DailyRelease/StackPublish
[15:03] <mhr3_> nic-doffay, ie don't forget to apt-get upgrade if you didn't since then
[15:03] <pstolowski> seb128: sure. but you did reboot before (after you upgraded unity & scopes from the ppa)?
[15:04] <seb128> pstolowski, no, but I restart my session (logout to lightdm and log-in) and tested with a test user
[15:04] <seb128> pstolowski, that should be enough "restart", I don't think the dash has anything running as system services?
[15:04] <pstolowski> seb128: right, restarting session is enough
[15:05] <nic-doffay> mhr3_, can I have both valac packages side by side?
[15:05] <sil2100> didrocks: python-junitxml is in universe as well, *sigh*, let's get that to main, otherwise python-autopilot doesn't make sense
[15:05] <mhr3_> nic-doffay, sure, only one will be default though
[15:05] <mhr3_> nic-doffay, as for which... i'm not sure... seb128? ^
[15:05] <mhr3_> valac default on S? 18 or 20?
[15:06] <mhr3_> or it is whatever you install first?
[15:06] <didrocks> sil2100: well, then, you need to check for python-junitxml
[15:06] <didrocks> sil2100: is has some components in universe
[15:06] <didrocks> sil2100: filing bugs for MIR is just not filing bugs, it's checking it's meeting the MIR criterias dude :/
[15:06] <Wellark_> didrocks: ok. I'm a bit uncertain to which stack this project should belong to
[15:06] <didrocks> not the first time
[15:06] <didrocks> Wellark_: sdk sounds fine
[15:06] <didrocks> sil2100: I'm annoyed by python-support
[15:07] <Wellark_> didrocks: ok. can we change it later if needed?
[15:07] <didrocks> Wellark_: yeah
[15:07] <sil2100> didrocks: will correct all those, sorry about that, just want to finish this packaging review
[15:07] <nic-doffay> mhr3_, would you recommend going back to valac 0.18?
[15:07] <didrocks> sil2100: right now, TBH, putting things for release is more important
[15:08] <mhr3_> nic-doffay, yes
[15:10] <didrocks> mmrazik: there is an issue with gtester2xunit
[15:10] <didrocks> mmrazik: as some package are using it, we need it in main
[15:10] <mmrazik> mhm
[15:10] <didrocks> mmrazik: but python-junitxml is in universe
[15:11] <didrocks> mmrazik: and seeig the number of deps, especially python-support, we can't promote it to main
[15:11] <didrocks> so either it's convert it to dh_python2
[15:11] <didrocks> or remove the python-junitxml build-dep
[15:11] <mmrazik> didrocks: I think we can do the later if preferred
[15:11] <seb128> nic-doffay, mhr3_: default is vala 0.18 atm, you can change it with "sudo update-alternatives --config valac"
[15:11] <mmrazik> didrocks: it only needs python-junixml to run the tests
[15:12] <mmrazik> well... just to generate the xml when running the tests
[15:12] <mmrazik> so we can still run tests without it
[15:12] <didrocks> mmrazik: can you handle it? we can't push anything to distro without that
[15:12] <nic-doffay> mhr3_, giving it a go thanks!
[15:13] <didrocks> mmrazik: cjwatson is converting it
[15:13] <mhr3_> nic-doffay, just make sure `apt-cache policy valac` says ubuntu9
[15:14] <mmrazik> didrocks: so what should I handle and what is cjwatson doing?
[15:14] <nic-doffay> mhr3_, I actually had both side by side
[15:14] <didrocks> mmrazik: that's fine, but please, next time, and that's a general rule for PS, look at the deps you are introducing if they are not in main
[15:14] <didrocks> we need to do a checker for that I guess
[15:15]  * mmrazik is confused
[15:15] <mhr3_> nic-doffay, then you probably had the one from morning (ubuntu7) which broke all this
[15:15] <mmrazik> didrocks: is there anything I need to do?
[15:15] <didrocks> mmrazik: no, cjwatson is handling the transition
[15:15] <mmrazik> (besides change the autolanding jobs as they will fail if they won't find junit)
[15:15] <mmrazik> didrocks: ok
[15:15]  * sil2100 is now checking all the stupid MIR's he filled in
[15:16] <paulliu> mhr3_: ok. yeah. It builds right now.
[15:17] <didrocks> sil2100: python-junitxml, you can assume that it doesn't depend on python-support
[15:17] <sil2100> didrocks: platform-api and libhybris are clean, besides depending on eachother
[15:17] <didrocks> sil2100: use check-mir
[15:17] <didrocks> it's a useful binary
[15:17] <sil2100> :O
[15:17] <didrocks> ok
[15:20] <sil2100> Ok, this is a really useful binary
[15:21] <didrocks> isn't it?
[15:21] <didrocks> doesn't check everything
[15:21] <didrocks> but better than doing it by hand
[15:22] <sil2100> Shit...
[15:23] <sil2100> didrocks: there's also a problem with sphinx - we don't want python-support in main, right?
[15:24] <didrocks> sil2100: right
[15:27] <didrocks> mhr3_: keep me posted once I need to rebuild anything
[15:27] <didrocks> mhr3_: so that we can have a clean state before EOD
[15:27] <mhr3_> didrocks, fwiw i have branch
[15:27] <mmrazik> mterry: the gmail fix was released. Can you let me know if it works now?
[15:27] <mmrazik> (eventually)
[15:27] <didrocks> mhr3_: is it unity?
[15:27] <mterry> mmrazik, it's been working great!
[15:27] <mmrazik> cool
[15:27] <mhr3_> didrocks, yea, trying to figure out how to test it
[15:28] <didrocks> mterry: ok, I'm taking platform-api
[15:28] <mhr3_> but the fix is there and works
[15:28] <sil2100> didrocks: then sphinx is generally risky ;/ sphinx3 requires sphinxbase which depends on python-support ;/
[15:28] <didrocks> mterry: ^
[15:28] <didrocks> need to port sphinxbase to dh_python :/
[15:28] <mterry> didrocks, ok, just found some issues with pocketsphinx, but going to lunch
[15:28] <didrocks> ok
[15:28] <mterry> posted in the bug
[15:28] <mterry> tests + pysupport
[15:29] <didrocks> sil2100: having a look ^ ?
[15:29] <sil2100> didrocks: yes
[15:29] <sil2100> mterry: thanks!
[15:30] <sil2100> mterry: I also added sphinxbase to the list of MIR's
[15:32] <nic-doffay> mhr3_, still the same error.
[15:33] <mhr3_> nic-doffay, hudclient? or the peoplepreview one?
[15:33] <nic-doffay> mhr3_, peoplepreview one
[15:33] <nic-doffay> hudclient is cool now
[15:33] <mhr3_> nic-doffay, did you rebuild libunity && unity-core?
[15:33] <nic-doffay> I got rid of the build dir
[15:34] <nic-doffay> mhr3_, ^
[15:34] <mhr3_> nic-doffay, hm, can you pastebin this run's log?
[15:34] <paulliu> mhr3_: I got it build with patched libunity. Is that sed line sounds?
[15:34] <mhr3_> paulliu, no, it can break python scopes
[15:36] <sil2100> mterry: in the meantime, I'll try converting sphinxbase
[15:50] <nic-doffay> mhr3_, https://pastebin.canonical.com/92301/
[15:55] <didrocks> sil2100: ok, approving platform-api
[15:55] <didrocks> sil2100: needing help for sphinxbase?
[15:56] <sil2100> didrocks: I think I'm fine, should I do a MR against lp:ubuntu/sphinxbase ?
[15:56] <tsdgeos> oh yeah, saucy unity segfaults like mad :D
[15:56] <sil2100> tsdgeos: the one from daily-build or from the archives?
[15:57] <tsdgeos> archive i guess
[15:57] <tsdgeos> 7.0.0daily13.04.18~13.04-0ubuntu1
[15:58] <didrocks> sil2100: is the ubuntu branch up to date?
[15:58] <didrocks> pete-woods: around by any chance?
[15:59] <didrocks> sil2100: send me a debdiff, I'll sponsor it
[15:59] <dandrader> hmm, http://qt-project.org seems to be offline again
[16:00] <didrocks> sil2100: then you are doing the same with pocketsphinx or do you need help?
[16:00] <didrocks> (and running the tests)
[16:01] <sil2100> didrocks: I can, since mterry seems to be away still, I'll see what I can do there
[16:01] <sil2100> Let me generate the debdiff
[16:04] <sil2100> didrocks: http://paste.ubuntu.com/5739183/
[16:04] <sil2100> didrocks: that's the first time I switch from python-support to dh_python2
[16:04] <sil2100> didrocks: wait one moment
[16:04] <didrocks> sil2100: thanks!
[16:04] <didrocks> ah?
[16:04] <didrocks> |o|
[16:06] <didrocks> sil2100: you need a X-Python-Version: >= 2.4 I think
[16:06] <didrocks> like http://launchpadlibrarian.net/141801287/pyjunitxml_0.6-1_0.6-1ubuntu1.diff.gz
[16:06] <pete-woods> didrocks: hi
[16:07] <sil2100> didrocks: oh, ok! Thought that XS-Python-Version is enough
[16:07] <didrocks> pete-woods: hey, I saw you have made some upload to some sphinx* package, just to tell you we are converting to dh_python
[16:07] <didrocks> sil2100: ah, remove that one
[16:07] <didrocks> sil2100: and prefer the X-P*
[16:07] <pete-woods> didrocks: cool, that sounds good to me!
[16:08] <didrocks> ok ;)
[16:09] <sil2100> didrocks: correcting that, checking something and re-uploading ;)
[16:11] <didrocks> ok :)
[16:11] <sil2100> didrocks: http://paste.ubuntu.com/5739206/
[16:11] <sil2100> didrocks: I had to check if files are installed ok also in the python-sphinxbase package, not only libsphinxbase1
[16:11] <sil2100> But it seems ok
[16:13] <didrocks> ok
[16:13] <didrocks> sil2100: so on the next one now?
[16:13] <didrocks> sil2100: I'm looking and sponsoring this one meanwhile :)
[16:13] <sil2100> didrocks: yes, doing that ;)
[16:17] <didrocks> sil2100: I would stop shipping .la files as well
[16:17] <didrocks> sil2100: let me add that
[16:18] <didrocks> sil2100: python-sphinxbase is empty, did you see the lintian warning?
[16:19] <sil2100> didrocks: how empty? I just checked and there are files in it, like ./usr/lib/python2.7/dist-packages/sphinxbase.so
[16:20] <didrocks> sil2100: dpkg-deb -c python-sphinxbase_0.8-0ubuntu6_amd64.deb
[16:20] <didrocks> -> empty, just the share/doc here
[16:21] <sil2100> http://paste.ubuntu.com/5739224/
[16:21] <sil2100> But I built it with bzr bd
[16:21] <didrocks> interesting…
[16:21] <sil2100> Using lp:ubuntu/sphinxbase as the base, hmmm
[16:21] <didrocks> sil2100: ok, should have something in the cache, I rm the dir
[16:21] <didrocks> dpkg-source -x again
[16:21] <didrocks> and it's fine
[16:21] <mhr3_> nic-doffay, sorry it took a while, you did try to rebuild everything, but it used the stuff from the previous failed build
[16:21] <didrocks> should be a buggy debclean as we see sometimes
[16:22] <sil2100> Phew!
[16:22] <mhr3_> nic-doffay, ie, failed again
[16:22] <didrocks> sil2100: yeah, phew! ;) I just removed the .la files
[16:22] <nic-doffay> mhr3_, what stuff?
[16:22] <sil2100> didrocks: thanks! Well, indeed it was pointless to serve them ;)
[16:23] <sil2100> didrocks: I'm working on pocketsphinx now
[16:23] <didrocks> sil2100: it was even dangerous
[16:23] <sil2100> mterry: ^
[16:23] <mhr3_> nic-doffay, you did ./build-unity --clean, yet that doesn't seem to clean anything
[16:23] <didrocks> sil2100: see the lintian error :)
[16:23] <nic-doffay> mhr3_, I got rid of the build dir.
[16:23] <didrocks> sil2100: because they were not empty
[16:23] <mhr3_> nic-doffay, well that wasn't enough
[16:24] <mhr3_> nic-doffay, apparently some deps do not build in the build dir
[16:24] <didrocks> sil2100: sphinxbase sponsored. mterry please look at -0ubuntu6 for your review
[16:25] <sil2100> didrocks: \o/ thanks!
[16:25] <nic-doffay> mhr3_, ok, I'll get a fresh trunk.
[16:25] <mterry> didrocks, sil2100: back
[16:26] <sil2100> mterry: ACK, just repeating: I'm currently converting pocketsphinx and fixing the test issue (at least trying)
[16:26] <sil2100> mterry: sphinxbase is done
[16:28] <mhr3_> nic-doffay, also, try http://paste.ubuntu.com/5739240/
[16:28] <mhr3_> Saviq, ^^ maybe you want to mp that?
[16:39] <sil2100> mterry, didrocks: I added the tests, just doing a test build now (those tests take A LOT of time to finish)
[16:41] <didrocks> mardy: I don't have after a reboot the issue anymore, seems your patch did it :)
[16:41] <didrocks> mardy: just need to be in trunk now, to ignore that one :)
[16:43] <didrocks> mterry: sil2100: pyjunitxml -> done
[16:44] <sil2100> didrocks: perparing debdiff for pocketsphinx
[16:44] <didrocks> mterry: do you prefer reviewing sil2100's debdiff directly? ^
[16:44] <sil2100> mterry: I have a bzr branch as well ;p
[16:46] <sil2100> mterry: http://paste.ubuntu.com/5739287/ please be gentle /o\
[16:47] <nic-doffay> mhr3_, you're right it must have been some of the files somewhere in the other dir. Sorted now, cheers :)
[16:48] <mhr3_> nic-doffay, cool, sorted out right before eod.. lol
[16:48] <didrocks> kenvandine: can you relaunch a build of unity in the unity stack when mhr3_'s branch will be merged?
[16:48] <didrocks> kenvandine: then, if possible (not too late for you) a run with "check with whole ppa"
[16:49] <nic-doffay> mhr3_, yeah mega win, right? :/
[16:49] <didrocks> kenvandine: so basically: 1. ONLY the prepare_unity (directly in jenkins), 2. the head with "check with whole ppa"
[16:52] <mterry> sil2100, looking at diff
[16:52] <mterry> sil2100, there also seemed to be a 'make test' target as well as check?
[16:53] <sil2100> mterry: I tried make test but it just said 'test is up-to-date'
[16:54] <kenvandine> didrocks, sure
[16:55] <didrocks> mhr3_: you will keep kenvandine up to date?
[16:55] <mterry> sil2100, ah...  because it's also a directory and they didn't mark it as PHONY
[16:55] <didrocks> kenvandine: sweetness of sweetness! :)
[16:56] <mhr3_> didrocks, sure
[16:56] <mterry> sil2100, but it's clearly doing things in the toplevel Makefile.am.  ah well
[16:56] <sil2100> ;)
[16:56] <mterry> sil2100, anyway seems reasonable
[16:56] <sil2100> mterry: \o/
[16:57] <sil2100> mterry: thank you!
[16:57] <mterry> sil2100, sphinxbase seems to have the same problem?  not running the check target
[16:58] <sil2100> mterry: ah, didn't check that one for that
[16:58] <sil2100> hmm
[16:59] <olli> bregma, I just added "enable debugging" to the U8/mir 13.10 blueprint
[16:59] <didrocks> mterry: are you fine with the remaining one or can I help more?
[16:59] <olli> not sure if it was obvious to you, wasn't to me thus making it explicit
[16:59] <sil2100> mterry: would it be much trouble if you could add that? Since Didier already made some changes to the debdiff I made to remove the .la files
[17:00] <mterry> didrocks, with sphinx3?  I can do that
[17:00] <didrocks> mterry: like, you will be able to handle them with sil2100? (as we need to push tomorrow morning european time)
[17:00] <didrocks> mterry: if there is any big blocker, please send me an email :)
[17:00] <mterry> didrocks, ok
[17:00] <sil2100> mterry: with sphinxbase I mean
[17:00] <didrocks> thanks a lot again mterry and sorry for the short notice, I discovered this hud2 case today :)
[17:01] <sil2100> mterry: since you said make check is not called ;)
[17:01] <mterry> sil2100, sure I can look at that
[17:01] <sil2100> mterry: bit thanks!
[17:01] <sil2100> *BIG
[17:01] <sil2100> kenvandine: ping
[17:02] <sil2100> kenvandine: free for a packaging review? https://code.launchpad.net/~sil2100/address-book-service/packaging_review/+merge/167812
[17:02]  * kenvandine looks
[17:06] <kenvandine> sil2100, why not rename the binary too?
[17:07] <sil2100> kenvandine: not sure if they're not dep'ing on that name anywhere, we would have to check
[17:07] <sil2100> kenvandine: hm, let's maybe wait for renato to pop up, he might comment on that more
[17:08] <kenvandine> ok, i'll comment on the MP
[17:09] <kenvandine> i think it would  make sense to rename the binary too
[17:14] <mhr3_> kenvandine, fwiw here's the branch that unity is waiting on - https://code.launchpad.net/~mhr3/unity/no-double-activate/+merge/167788 it's acked, just didn't land to trunk yet, it's waiting for the goblins to turns the gears
[17:15] <kenvandine> mhr3_, thx
[17:17] <sil2100> mterry: any blockers up until now?
[17:18] <mterry> sil2100, not yet
[17:18] <didrocks> mterry: just sign at the bottom of this blank paper, everything will be fine :)
 :p
[17:18] <sil2100> ;D
[17:24] <mterry> pete-woods, heyo
[17:24] <mterry> pete-woods, do you remember your packaging of sphinx3?
[17:26] <sil2100> mterry: I'll be around here to help out if anything, so if there's any problem, just poke me and I'll try to react
[17:26] <sil2100> Just going to grab a bite
[17:27] <mterry> sil2100, ok
[17:28] <mterry> sil2100, did you upload your pocketsphinx changes?
[17:29] <sil2100> mterry: what do you mean by 'upload'?
[17:29]  * sil2100 has no real permissions
[17:29] <sil2100> Didier was sponsoring sphinxbase, but pocketsphinx I don't think so
[17:30] <sil2100> Just the debdiff I posted
[17:30] <mterry> sil2100, oh OK, I can upload
[17:30] <sil2100> mterry: thank you!
[17:30] <sil2100> You're getting some beers on the nearest sprint
[17:30] <sil2100> ;)
[17:30] <pete-woods> mterry: yes, I think so
[17:30] <Saviq> mhr3_, yeah, thanks for that
[17:31] <Saviq> mhr3_, sorry that you had to switch to support us in this...
[17:31] <mterry> pete-woods, do you remember why you had to disable some failing tests?  Like, were they bogus tests or just didn't have time to figure them out?
[17:32] <pete-woods> mterry: so the package seems to be basically unmaintained
[17:32] <pete-woods> I had a go at fixing them, but just couldn't get them to pass reliably
[17:33] <pete-woods> mterry: the devs seem to have moved on to the Java-based sphinx4, but their training tool sphinxtrain still uses some sphinx3 components
[17:33] <pete-woods> which is the reason I packaged it
[17:34] <mterry> pete-woods, that sounds bogus
[17:35] <mterry> pete-woods, I mean, it sounds bad that we are relying on abandonware sphinx3
[17:35] <pete-woods> mterry: unfortunately there's not much choice, it's still the only way you can train models
[17:35] <pete-woods> fortunately it's only needed for model training, though
[17:36] <mterry> pete-woods, upstream still uses old sphinx3 for that?
[17:36] <pete-woods> mterry: they have Java based deployments for that
[17:36] <pete-woods> and it's still marked as unfinished
[17:37] <pete-woods> i.e. you should still use sphinx3, til they've finished it
[17:37] <mterry> pete-woods, :-(
[17:38] <mterry> sil2100, did you build pocketsphinx with your changes?  I'm getting a test failur
[17:38] <pete-woods> mterry: yeah, it does work, at least! I've put it through like 100s of hours of compute time
[17:39] <pete-woods> generating the acoustic models for the phablet image
[17:39] <pete-woods> and that ironed out all sorts of little things
[17:40] <pete-woods> anyway, EOD for me!
[17:44] <sil2100> mterry: yes, I did a bzr bd and it was fine here
[17:44] <sil2100> mterry: it took a looong time but it was all success
[17:44] <mterry> sil2100, hmm..  It's missing some build-depends for the gst test.  Builds fine locally, not in a pbuilder
[17:45] <sil2100> oh
[17:45] <sil2100> Ok
[17:45] <sil2100> Sorry about that!
[17:47] <sil2100> I could have tested that with pbuild
[17:47] <sil2100> The thing is, I didn't create a chroot for saucy yet
[17:53] <sil2100> mterry: any way I can help?
[17:54] <mterry> sil2100, no, I've almost got it
[17:55] <mterry> sil2100, 	resamp = gst_element_factory_make("audioresample", "resampler"); is returning NULL
[17:57] <mterry> sil2100, oh huh, gstreamer0.10-plugins-base isn't pulled in by the -dev package....
[17:58] <sil2100> uhhh
[17:59] <mterry> difference between the library and the plugins I guess
[18:05] <sil2100> mterry: so, simply adding that dependency helps?
[18:06] <mterry> sil2100, yeah, it fixes it.  I uploaded
[18:06] <sil2100> mterry: \o/
[18:06] <sil2100> mterry: anything left from the big list of mean MIRs?
[18:06] <mterry> sil2100, sphinx3 I think.  Almost done
[18:07] <sil2100> mterry: Didier handled libhybris and platform-api?
[18:07] <mterry> sil2100, platform-api for sure.  I can double check on libhybris
[18:07] <sil2100> (and the gtester2xunit I think)
[18:08] <sil2100> gtester2xunit is approved \o/
[18:08] <mterry> sil2100, yeah, libhybris is pre-approved, but it needs security review
[18:08] <sil2100> platform-api pre-approved as well, waiting on libhybris
[18:08] <sil2100> Ok, phew, so I think we're safe once sphinx3 is ready
[18:09] <sil2100> mterry: is there any way I can help with that or is it ok?
[18:10] <mterry> sil2100, eh, it's OK.  I'm just nervous about its maintained status
[18:10] <mterry> doing some research
[18:11] <sil2100> mterry: I need to reboot my system, as it's trashed badly - but I'll be back
[18:22] <mterry> sil2100, approved sphinx3, I think we're done
[18:23] <sil2100> mterry: \o/
[18:23] <sil2100> THANK YOU!
[18:23] <sil2100> ;)
[18:24] <mterry> sil2100, thank you!  :)
[19:28] <mterry> xnox, you around?
[20:20] <kenvandine> mhr3_, still around?
[20:20] <mhr3_> kenvandine, yep
[20:20] <kenvandine> awesome
[20:21] <kenvandine> mhr3_, https://code.launchpad.net/~ken-vandine/dee/pygi_overrides/+merge/167841
[20:21] <kenvandine> please review that :)
[20:21] <kenvandine> it fixes the problem that has been breaking pygi and dee
[20:21] <kenvandine> and holding up all my other branches :)
[20:22] <mhr3_> looks good to me
[20:22] <kenvandine> great
[20:23] <kenvandine> mhr3_, so that check in configure.ac for the overrides_dir has always failed
[20:23] <kenvandine> and the fallback was correct, we were just lucky
[20:23] <kenvandine> we need the build depends so it gets the correct dir
[20:24] <mhr3_> kenvandine, why are we no longer lucky? :)
[20:24] <kenvandine> the pyexecdir changed
[20:24] <kenvandine> so now we are installing the override in the wrong dir
[20:24] <mhr3_> i see
[20:25] <mhr3_> acked
[20:25] <kenvandine> thx!
[20:25] <kenvandine> this has been driving me insane!
[20:25]  * kenvandine needs a beer...
[20:26] <mhr3_> i see think pygi could use an envvar for the overrides
[20:26] <mhr3_> s/see/still/
[20:26] <kenvandine> yeah
[20:26] <kenvandine> perhaps
[20:26] <kenvandine> this works though
[20:26] <kenvandine> or
[20:26] <kenvandine> now it works :)
[20:26] <mhr3_> it never works with jhbuild, that's the problem :)
[20:26] <kenvandine> haha
[20:27] <kenvandine> nothing ever works in jhbuild :)
[20:27] <mhr3_> heh, nah, jhbuild is awesome :P
[20:27] <kenvandine> i've have hated jhbuild for many years now...
[20:27] <kenvandine> mhr3_, on the one day a year that the stars align... it's awesome
[20:28] <kenvandine> :-D
[20:28] <mhr3_> i do understand that, for making packages it's just making everything harder
[20:28] <mhr3_> and different
[20:28] <kenvandine> yeah
[20:47] <tedg> ChrisTownsend, Thanks for reviewing that last upstart patch!
[20:47] <tedg> Now I don't have to worry about Unity landing in saucy and screwing my desktop up ;-)
[20:53] <ChrisTownsend> tedg: Sure thing!
[20:54] <ChrisTownsend> tedg: I got trunk working and both merges worked fine.
[21:16] <Saviq> tedg, ping
[21:17] <Saviq> tedg, I _think_ I saw a post / blog / email from you about enabling Unity in upstart, can you please point me to it?
[21:19] <Saviq> or maybe! it's the description on the MP :)
[21:19] <Saviq> found it
[21:19] <tedg> Saviq, I don't think I have one on unity
[21:19] <Saviq> tedg, unping
[21:19]  * tedg uncomments
[21:19] <Saviq> ;)
[21:23] <Saviq> take that, compiz! now you can die all you want :P
[21:48] <tedg> Heh