[04:57] <ggabriel96> hey guys
[04:58] <ggabriel96> i got a problem here
[04:58] <ggabriel96> after running steam on big picture mode, now there are 2 steams on the launcher
[04:58] <ggabriel96> as if i was running 2 steam clients
[04:59] <ggabriel96> but im actually running only 1, ofc, and there is only the main window open
[04:59] <ggabriel96> i went to #ubuntu-steam and they said it was a unity bug
[04:59] <ggabriel96> look: http://oi43.tinypic.com/2wpulj6.jpg
[04:59] <ggabriel96> do u guys know how i can fix this?
[05:02] <ggabriel96> well, i gotta go. later on i come back to ask for help
[07:33] <sil2100> Saviq: hi! unity8 FTBFS on armhf, it seems it had problems finding libunity-core, but I see all is ok
[07:33] <sil2100> Saviq: so re-running the build
[07:39] <veebers> MacSlow: ping
[07:42] <didrocks> sil2100: arch mistmatch I guess
[07:43] <sil2100> didrocks: yep, it's builtind now so I re-run the stack
[07:43] <didrocks> greatness!
[08:24] <jamesh> sil2100: hi.  I filed https://bugs.launchpad.net/ubuntu/+source/lucene++/+bug/1207584 about the lucene++ bug I mentioned last night
[08:24] <jamesh> sil2100: since then, I built some test packages with that change and was able to successfully build the media scanner
[08:31] <tsdgeos> mzanetti: the fidnChild landing failed :-/
[08:33] <mzanetti> tsdgeos: ;(
[08:33] <tsdgeos> want to have a look at why? or reapprove?
[08:33] <mzanetti> tsdgeos: hmm... the CI job passed and its exactly the same issue I've seen yesterday with trunk
[08:34] <mzanetti> tsdgeos: its not this MR's fault, but I actually hoped it would improve things
[08:34] <tsdgeos> i see
[08:34] <tsdgeos> let's reapprove then
[08:34] <mzanetti> tsdgeos: what happens is that the MIR vm is so disk IO intensive that swapping in the other VM's basically stalls
[08:35] <tsdgeos> :/
[08:35] <mzanetti> (which is still unclear to me how that huge server cannot handle 6 vm's)
[08:50] <olli__> mhr3, ping
[08:52] <mhr3> olli__, pong
[09:12] <mzanetti> MacSlow: howdy
[09:12] <mzanetti> MacSlow: for what reason do you want to keep all the scenarios?
[09:13] <MacSlow> mzanetti, size/position (per form-factor) checks would really be nice imo
[09:13] <mzanetti> MacSlow: whats the difference of the notifications on different form factors?
[09:14] <mzanetti> MacSlow: afaics they always appear at the same position, with the same size
[09:14] <MacSlow> mzanetti, position for the most part... and size.. hm... well that's for later to be honest (when snap-decisions can stack up and collapse/expand)
[09:15] <mzanetti> MacSlow: and that will look different on a phone than on a desktop?
[09:15] <mzanetti> MacSlow: in any way, then we should only run the snap decision tests on different form factors
[09:15] <MacSlow> mzanetti, not right now
[09:15] <mzanetti> MacSlow: we're not in the position to waste jenkins time, really
[09:16] <MacSlow> mzanetti, to trim down the ap-tests there we can ignore it for the time being
[09:16] <MacSlow> mzanetti, but at some point that should be tested too
[09:16] <mzanetti> MacSlow: yeah... right now its always the same. so right now tests should be adjusted for that
[09:17] <MacSlow> mzanetti, so just the phone case then... updating branch
[09:36] <MacSlow> mzanetti, ok... senario-selection added
[09:36] <mzanetti> MacSlow: cheers. will re-review in a few
[09:37] <MacSlow> mzanetti, I'm using a string instead of a enum... hope that's the Python-way to do it
[09:42] <mzanetti> MacSlow: I've no clue... did you google for "python enums"?
[09:44] <MacSlow> mzanetti, it's a Python 3.4 feature... and I don't think we can/should make our tests depend on that just for proper enums
[09:44] <mzanetti> probably not...
[09:44] <MacSlow> mzanetti, all examples I've seen do some odd function-calls
[09:45] <MacSlow> mzanetti, I like the simple and straight-forward way with the strings
[09:46] <mzanetti> MacSlow: no, we don't want some hacks just for this...
[09:50] <mzanetti> dednick: hey... I've been able to reproduce that battery draining bug
[09:51] <mzanetti> dednick: indeed, once the network indicator flickers because of a backend crash (which happens most of the times when you add a new network) and then unity starts spinning the CPU
[09:51] <dednick> mzanetti: hm. that's not good
[09:51] <mzanetti> indeed :D
[09:52] <mzanetti> dednick: unfortunately its not reproducable by killing chewie-network-menu-server
[09:52] <mzanetti> dednick: it only happens when it crashes on its own
[09:52] <mzanetti> dednick: but that happens quite often, at least here
[09:53] <dednick> mzanetti: yeah, i think it crashes when you connect/disconnect a bit.
[09:53] <mzanetti> yep
[09:53] <dednick> mzanetti: i'll take a look at it today
[09:53] <mzanetti> dednick: awesome. You would make me very happy with fixing this
[09:53] <Cimi> dednick, could you give me a hand importing the plugin in my app?
[09:54] <dednick> Cimi: sure. which part do you need to import?
[09:55] <Cimi> dednick, well, you wrote it so you probably know better :)
[09:55] <Cimi> dednick, I need wifi, location, username, language
[09:55] <Cimi> dednick, I believe you only have wifi and maybe location?
[09:55] <Cimi> actually only wifi more likely
[09:56] <dednick> Cimi: yeah, only network
[09:56] <Cimi> but does it really still make sense to do it?
[09:56] <dednick> Cimi: you're going to need to import the IndicatorManager.
[09:56] <Cimi> sounds better to use just use system settings
[09:57] <dednick> Cimi: actually, probably just the IndicatorsModel.
[09:57] <dednick> Cimi: what system settings?
[09:57] <davmor2> Hey guys on Saucy the photos scope says There are no photos currently available on this computer, there are about 600-800 in Pictures, is there anything that should trigger this, is it a known issue, is there anything I can do to debug it?
[09:57] <Cimi> dednick, the app
[09:58] <dednick> Cimi: you need to import everything that has a welcome profile right?
[09:58] <Cimi> dednick, yes
[09:58] <Cimi> dednick, the wizard needs to set those things
[09:58] <Cimi> dednick, I can write my own plugins
[09:58] <Cimi> dednick, or set through another plugin
[09:59] <dednick> Cimi: set what things?
[09:59] <Cimi> dednick, location
[09:59] <Cimi> dednick, username
[09:59] <Cimi> dednick, wireless
[09:59] <Cimi> dednick, language
[10:00] <dednick> Cimi: i'm not sure indicators is what you want. it's probably more related to the system settings.
[10:00] <Cimi> dednick, totally
[10:01] <dednick> Cimi: in which case you dont want to import my plugin.
[10:01] <Cimi> yes
[10:01] <Cimi> dednick, but I don't understand what seb128 told me
[10:02] <dednick> Cimi: which channel and when?
[10:02] <seb128> what did I say?
[10:03] <seb128> dednick, I probably said that we want to re-use the indicator backends through unitymenumodel for e.g the list of wifi
[10:03] <seb128> dednick, export a wizard profile from the indicator and load it through unitymenumodel
[10:03] <seb128> dednick, does that make sense?
[10:04] <Cimi> seb128, but how about the language etc?
[10:04] <dednick> seb128: yeah, that's what you're doing for the settings right? (default-plugin)
[10:04] <seb128> dednick, yes
[10:04] <Cimi> seb128, to me makes more sense that code will be shared between the two
[10:04] <Cimi> seb128, a settings library
[10:04] <seb128> Cimi, well, those need to be refactored/put in a shared location (or just import the SystemSettings plugin)
[10:04] <Cimi> seb128, 3 actually
[10:05] <Cimi> we should have a settings library
[10:05] <dednick> seb128:i think the system settings should be inbetween the welcom and indicators.
[10:05] <Cimi> used by indicators, setting app
[10:05] <Cimi> and maybe others
[10:06] <seb128> yeah, that would made sense, at least for settings/wizard
[10:06] <seb128> indicators just go through their own backend and unitymenumodel
[10:06] <seb128> I don't think they need to import anything from us
[10:08] <dednick> seb128, Cimi: we need to discus the common components between indicators and settings at some point. At the moment we have multiple implementations of the menu items.
[10:09] <dednick> seb128, Cimi: and i think we should be using the same to keep the look-and-feel.
[10:09] <seb128> dednick, do we have several ones?
[10:09] <seb128> dednick, where are the different versions?
[10:10] <dednick> seb128: there are some in unity8/indicators, and others in ubuntu-settings-components and i believe there are others in the system settings as well ?
[10:11] <seb128> dednick, we don't have the system settings one done yet, mardy is looking at it
[10:11] <seb128> dednick, but yeah, we should only have a one implementation
[10:11] <dednick> seb128: right. and i dont think ubuntu-settings-componentsw is in play yet either.
[10:11] <seb128> dednick, I though that the stuff you are working on was going to give us a "turn that menumodel in a qml UI" that we can reuse
[10:13] <dednick> seb128: "turn that menumodel in a qml UI" can you re-phrase?
[10:14] <dednick> seb128: but yeah, the menumodel sourced ui should be re-usable. it's all just in unity/indicators for the time being.
[10:15] <seb128> dednick, hum, my understanding was that we have "indicator-service builds a gmenumodel description of the menu layout -> dbus -> unitymenumodel -> qt representation of the menu"
[10:15] <dednick> seb128: correct
[10:15] <seb128> dednick, e.g "unitymenumodel is turning a gmenumodel description into a qt UI" right?
[10:16] <seb128> which seems exactly what we need in the wizard and settings for some of the stuff as well
[10:16] <dednick> seb128: no, unitymenumodel is still just a model, but it represents the layout for the qt ui
[10:16] <dednick> the indicator page in unity8 takes the unitymenumodel and constructs the appropriate UI
[10:17] <seb128> ok
[10:17] <seb128> is there anything specific to the indicators in that "indicator page in unity8" ?
[10:17] <seb128> or can we just make that a shared "turn a model into an UI" component
[10:17] <seb128> and re-use it as it is for e.g settings?
[10:18] <tsdgeos> oh lol
[10:18] <dednick> seb128: it's separate.
[10:18] <tsdgeos> we have a
[10:18] <tsdgeos> ryCompare(gridLoader, "status", Loader.Ready, "Loader couldn't load " + data.component);
[10:18] <tsdgeos> 4th parameter is "timeout"
[10:18] <tsdgeos> :D
[10:19] <seb128> dednick, well anyway I think we all agree, having a shared implementation used by indicators/settings/wizard would be nice, so we have consistent UIs (and less custom code/copies)
[10:19] <dednick> seb128: ie, it can be shared for settings.
[10:19] <seb128> great, let's do that then ;-)
[10:19] <seb128> mardy, ^ are you following?
[10:20] <tsdgeos> javascript is nice :D
[10:20] <tsdgeos> you can do
[10:20] <tsdgeos> "Loader couldn't load Video/VideosFilterGrid.qml" < 0
[10:20] <tsdgeos> and it's false
[10:20] <dednick> seb128, Cimi, mardy: it should maybe be moved to ubuntu-settings-components
[10:21] <mardy> seb128: yep
[10:24] <mzanetti> mardy: unity8.shell.tests.test_notifications.InteractiveNotificationBase.test_sd_incoming_call fails here
[10:24] <mzanetti> mardy: sorry... was for MacSlow ^^
[10:25] <MacSlow> mzanetti, hm...
[10:25] <Cimi> Saviq, a name for the welcome wizard in lp
[10:26] <Cimi> Saviq, choose between ubuntu-welcome-wizard or meet-ubuntu
[10:29] <mzanetti> MacSlow: seems the notification is click-through. it opens the phone app when clicking on reject
[10:32] <MacSlow> mzanetti, doh... I need the notify-plugin in xhcat when running the ap-tests...
[10:32] <MacSlow> mzanetti, got to re-run it again...
[10:37] <MacSlow> mzanetti, only one of the 10 notification tests failed, because the phone-shell didn't start
[10:37] <MacSlow> mzanetti, running each individually they all pass
[10:38] <mzanetti> MacSlow: I see 2 issues here: the click on "decline" launches the phone app which is behind the button
[10:39] <mzanetti> MacSlow: no... I've been wrong
[10:39] <mzanetti> MacSlow: that works, but the click on the second button is too fast (the notification is not fully expanded yet)
[10:40] <mzanetti> MacSlow: that's what launches the phone app and also makes the test fail because the second button is not clicked any more
[10:42] <MacSlow> mzanetti, that's working fine here ... passing every time
[10:42] <mzanetti> MacSlow: so the removal of the sleep makes it fail here. you need to adjust the assert to wait for the button to be shown
[10:42] <mzanetti> MacSlow: buy a faster PC and it'll start failing :D
[10:42] <MacSlow> mzanetti, I'm using an Eventually() there already
[10:44] <MacSlow> mzanetti, I can add a time.sleep(1) there again
[10:44] <mzanetti> MacSlow: no sleeps
[10:44] <MacSlow> mzanetti, I wonder if it fails on jenkins
[10:44] <mzanetti> MacSlow: they will fail at some point for sure
[10:45] <MacSlow> mzanetti, speaking off... *sigh³*
[10:45]  * MacSlow goes and looks for something to kill 
[10:49] <MacSlow> mzanetti, could you pull again and see if test_sd_incoming_call() still fails for you?
[10:50] <mzanetti> MacSlow: nope. still failing
[10:51] <mzanetti> MacSlow: I'd rather go for opacity = 1 instead of visible true
[10:51] <mzanetti> MacSlow: as when opacity is 0.0000000001, visible is already true, but you want to wait until its fully opaque
[10:53] <MacSlow> mzanetti, the buttons don't fade but slide in... actually the are just revealed by animating the height of the notification (using clipping)
[10:53] <mzanetti> MacSlow: even if clipped visible is still true
[10:54] <MacSlow> mzanetti, sure... I'm looking for another condition to assert instead
[11:13] <tsdgeos> guys, easy one https://code.launchpad.net/~aacid/unity8/fixTryCompareCall/+merge/178260
[11:14] <mzanetti> tsdgeos: how come this test succeeded so far?
[11:14] <tsdgeos> mzanetti: i'm guessing it just doesn't need the tryCompare
[11:14] <tsdgeos> i.e. it's basically doing  compare
[11:15] <mzanetti> probably
[11:15] <mzanetti> approved
[11:15] <tsdgeos> since "string" in timeout basically gets converted to 0
[11:15] <tsdgeos> well it doesn't get converted
[11:15] <tsdgeos> but acts like if it was a 0
[11:16] <mzanetti> yay for mixing a typeless engine with a typed language :D
[11:18] <MacSlow> ich hab der "Behavior on implicitHeight" einen objectName gebeben...
[11:18] <MacSlow>     Behavior on implicitHeight {
[11:18] <MacSlow>         id: heightBehavior
[11:18] <MacSlow>         objectName: "heightBehavior"
[11:18] <MacSlow>         enabled: false
[11:18] <MacSlow>         UbuntuNumberAnimation {
[11:18] <MacSlow>             duration: UbuntuAnimation.SnapDuration
[11:18] <MacSlow>         }
[11:18] <MacSlow>     }
[11:19] <MacSlow> und im Test dann folgedes hinzugefugt...
[11:19] <MacSlow>         self.assertThat(
[11:19] <MacSlow>             notification.select_single(objectName="heightBehavior").animation.running,
[11:19] <MacSlow>             Eventually(Equals(False))
[11:19] <MacSlow>         )
[11:19] <tsdgeos> mzanetti: well, it's typed, just loosely typed :D
[11:19] <MacSlow> Aber für "notification.select_single(objectName="heightBehavior").animation.running" bekomme ich den Fehler "AttributeError: 'NoneType' object has no attribute 'animation'"
[11:19] <MacSlow> sorry... never mind.. that wsa meant for mzanetti :)
[11:20] <mzanetti> MacSlow: yeah... same issue as I fixed for qmltests yesterday
[11:21] <mzanetti> MacSlow: animations are non-visible items which are threated differently in the object hierarchy
[11:21] <mzanetti> lemme check if I can patch autopilot-qt to support it too
[11:24] <sil2100> jamesh: thanks! I'll look at it, assign me and fix - I already have all the package bits, but last test build I did failed because of other changes I wanted in
[11:27] <sil2100> jamesh: at least now we won't have to be afraid we won't make it in time for FF
[11:27] <sil2100> ;)
[13:07] <mzanetti> tsdgeos: hey, this one fails like every third run: ListViewWithPageHeaderTestSection.testCreationDeletion
[13:07] <mzanetti> tsdgeos: is this another one that will get more stable with qt5?
[13:08] <mzanetti> 5.1 that is
[13:08] <tsdgeos> don't remember about it when i tried on the jenkins machines tbh
[13:08]  * tsdgeos reads the code
[13:08] <tsdgeos> err
[13:08] <tsdgeos> lol that does nothing :D
[13:09] <tsdgeos> just the initial setup
[13:09] <tsdgeos> i mean
[13:09] <tsdgeos> every single test goes through that code
[13:09] <tsdgeos> it's weird this is the only one failing
[13:11] <tsdgeos> but yes we need to move asap
[13:11] <tsdgeos> and convince those that want to stick with 5.0
[13:11] <tsdgeos> noOoOoOoOo
[13:11] <mzanetti> tsdgeos: why would anyone want to stick with 5.0?
[13:11] <didrocks> mterry: hey!
[13:12] <mterry> didrocks, hi!
[13:12] <didrocks> mterry: small question, is there any way for testing purpose to tell to the greeter "please don't show up"
[13:12] <didrocks> (on touch, of course)
[13:13] <mterry> didrocks, yeah, let me get back to you after testing my proposal
[13:13] <didrocks> mterry: thanks, keep me posted please ;)
[13:13] <mterry> didrocks, edit /usr/share/unity8/Shell.qml
[13:14] <mterry> didrocks, find the "Greeter {" section
[13:14] <didrocks> mterry: I'm starting to be disappointed :p
[13:14] <mterry> didrocks, edit shown: true to shown: false
[13:14] <didrocks> mterry: would that be stable?
[13:14] <didrocks> I think we'll try to implement that as a gsettings key?
[13:14] <mterry> didrocks, no...  long term probably just using the autologin key of lightdm
[13:15] <didrocks> mterry: I can help implementing it if you wish
[13:15] <didrocks> (we'll use the hack for now for daily release testing)
[13:15] <mterry> didrocks, why, what's wrong with the greeter?
[13:15] <didrocks> just want to ensure that it's ported once we get the greeter being separated
[13:15] <didrocks> mterry: oh, just if we want to run the app autopilot tests
[13:16] <didrocks> we need to have access to the session
[13:16] <didrocks> so better to not having any greeter blocking us :)
[13:16] <mterry> didrocks, you can't just swipe the greeter to remove it?
[13:16] <didrocks> mterry: jibel did a script for that
[13:16] <didrocks> but it seems the inputs are not always plugged in, and so, it's racy
[13:16] <didrocks> would be better to be able to start the phone in a developper mode without greeter
[13:17] <jibel> mterry, that's what I do, but it doesn't always work, like if the greeter is not receiving the drag event
[13:17] <didrocks> like what we do for desktop daily release, with autologin
[13:21] <didrocks> mterry: thanks a lot man ;)
[13:21] <jibel> mterry, works like a charm, thanks!
[13:28] <Saviq> sil2100, thanks
[13:28] <Saviq> Cimi, your call
[13:32] <sil2100> Saviq: back home already?
[13:32] <sil2100> ;)
[13:33] <Saviq> sil2100, no, in LPL, waiting for the flight back
[13:48] <xkiz> is it possible to move Unity's Launcher Bar, or Dock to the bottom of the screen, on ubuntu 12.04 ?
[13:48] <tsdgeos> no
[13:54] <jbicha> hi, could https://code.launchpad.net/~jbicha/unity/adjust-to-ubiquity-desktop-rename/+merge/178152 be reviewed?
[13:55] <jbicha> I don't know if you want to do another Unity upload today for that but at least we know Unity is buildable :)
[13:56] <bregma> jbicha, we'll get to the review eventually, most of the Unity team is not around right now
[14:09] <mzanetti> mterry: ping
[14:09] <mterry> mzanetti, hello
[14:09] <mzanetti> mterry: I've approved this one https://code.launchpad.net/~mterry/unity8/lockscreen-autopilot/+merge/177225
[14:10] <mzanetti> mterry: however, autolanding failed 3 times because of a hud test
[14:10] <mterry> mzanetti, I just updated that
[14:10] <mzanetti> ah ok
[14:10] <mterry> mzanetti, I actually made a code change to fix that hud test though, so you may want to just quickly re-review
[14:10] <mzanetti> I will
[14:10] <mterry> mzanetti, not sure why that test suddenly decided to blow up because of it.  The code change should have blown up things before...
[14:10] <mzanetti> mterry: and another one: Saviq said I could/should help you running the camera in the greeter somehow
[14:10] <mterry> I mean, the reason for the code change
[14:11] <mzanetti> mterry: is that still valid?
[14:11] <mterry> mzanetti, OK.  I hadn't started worrying too much about camera yet, but that's still needed, yeah
[14:11] <mzanetti> mterry: whats the plan there? embed it into the greeter process?
[14:12] <mterry> mzanetti, currently, yeah
[14:12] <mzanetti> mterry: interesting... ok. I'll give it a quick shot to check if there's trouble upcoming or not
[14:12] <mterry> mzanetti, there is a slight chance we will merge u-s-c and the greeter
[14:12] <mterry> mzanetti, but if not, we will run the camera app as a qml plugin
[14:12] <mzanetti> u-s-c?
[14:12] <mterry> mzanetti, unity-system-compositor
[14:12] <mzanetti> ah
[14:13] <tsdgeos> ubuntu-software-center !
[14:13] <mzanetti> haha
[14:13] <tsdgeos> stop creating names with the same letters :D
[14:15] <Saviq> mzanetti, mterry phone is prio
[14:15] <Saviq> mzanetti, mterry camera is good to have
[14:15] <mzanetti> right
[14:15] <Saviq> but not something that should push other tasks
[14:15] <mzanetti> well, I guess finding the way to embedding is the job... which app it is shouldn't matter too
[14:15] <mzanetti> much
[14:16] <mzanetti> Saviq: sure... but launcher is a bit stalled and PIN entry is mostly done
[14:17] <Saviq> mzanetti, yeah, why I'm saying it's fine to work on putting phone in greeter and leave camera for later
[14:17] <mzanetti> ack
[14:21] <mzanetti> Saviq: err... just thinking about this... how would that work? Do we want to allow people to make phone calls even though the device is locked?
[14:24] <Saviq> mzanetti, the main usecase is incoming call
[14:24] <Saviq> mzanetti, and emergency
[14:25] <mzanetti> ok... yeah. boiko just told me... was a bit worried :)
[14:25] <Saviq> mzanetti, so yeah, it needs to "know" and limit itself
[14:25] <sil2100> jamesh: hi!
[14:27] <sil2100> jamesh: you still around?
[14:27] <sil2100> jamesh: I think I'm getting an error during build I think in lucene++
[14:49] <tsdgeos> mzanetti: hmmmm
[14:49] <tsdgeos> reading https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-saucy/888/consoleFull i wonder if the
[14:49] <tsdgeos> QWARN  : ListViewWithPageHeaderTestSection::testCreationDeletion() QXcbConnection: XCB error: 148 (Unknown), sequence: 148, resource id: 0, major code: 140 (Unknown), minor code: 20
[14:49] <tsdgeos> has anything to do with the subsequent error
[14:49] <mzanetti> o_O
[14:49] <mzanetti> this is the bad one, yes
[14:50] <tsdgeos> and where those come from
[14:51] <mzanetti> tsdgeos: hmm... the workaround seems to fail :/ You should see this error when the job starts qmlscene in the beginning... but its not showing up there, instead blocking the test later on
[14:51] <tsdgeos> :/
[14:55] <mzanetti> tsdgeos: ok. I increased the time the qmlscene app runs and added some openGL instructions in the hope it will always trigger the bug
[14:56] <tsdgeos> x-finders
[14:56] <tsdgeos> x-fingers
[14:56] <mzanetti> ?
[14:56]  * tsdgeos crosses his fingers
[14:56] <tsdgeos> good luck
[14:56] <tsdgeos> and sfutt
[14:56] <tsdgeos> stuff
[14:56] <tsdgeos> :D
[14:56] <mzanetti> heh
[14:56] <mzanetti> I thought you mean something related to X11
[14:56] <tsdgeos> :D
[14:56] <mzanetti> some tool that would trigger this for sure or the like
[14:56] <tsdgeos> ped x-ing
[14:57] <tsdgeos> this one has always made me laugh
[14:57]  * mzanetti has no clue what tsdgeos is talking about
[14:57] <tsdgeos> it's a sign you find a lot in the USA
[14:57] <mzanetti> ah
[14:57] <mzanetti> really?
[14:57] <tsdgeos> took me a while to understand what it meant
[14:57] <tsdgeos> yeah
[14:57] <mzanetti> shorted like this?
[14:57] <tsdgeos> yep
[14:58] <mzanetti> this is so crazy... I bet less than half of the population understands it
[14:58] <tsdgeos> :D
[14:59] <tsdgeos> it was funny since english is a pretty "compact" language
[15:08] <NikTh> Eventually, what will (in GOD) happens with unity version in 14.04 LTS ? Will you ship 14.04 with Full Mir and Unity 8, or full mir and unity 7 ? Of course I refer to Desktop.
[15:08] <sil2100> jamesh:
[15:08] <sil2100> I mean
[15:08] <sil2100> jamesh: are you here?
[15:11] <bregma> NikTh, 14.04 is a long way off; there is opportunity for community discussion on this at several vUDS between now and feature freeze for 14.04
[15:14] <mzanetti> dednick: I've assigned you the CPU spinning bug
[15:15] <jamesh> sil2100: hi
[15:15] <jamesh> what's the problem?
[15:16] <NikTh> bregma:  According to Olli → http://www.olli-ries.com/i-have-to-try-this/ , will not gonna make it. I've heard ( read ) lot of times that 14.04 will be released with Unity 8 and Mir.. but now.. hmm..
[15:20] <bregma> NikTh, it's the community that ultimately decides, and the time for that decision has not yet come...  Unity 8 and Mir will be available for 14.04 but it's still early days for committing to what the default desktop will be
[15:23] <sil2100> jamesh: hi! It seems that when building with -DENABLE_STANDARD_ALLOCATOR:BOOL=ON I get some unresolved symbols
[15:23] <sil2100> I mean, like a lot
[15:25] <jamesh> sil2100: oh?  It built without issue for me.
[15:25] <sil2100> hmm
[15:26] <sil2100> jamesh: you only added this one flag to configure?
[15:26] <jamesh> sil2100: I replaced the two occurences of -DLPP_USE_ALLOCATOR:BOOL=OFF in debian/rules with -DENABLE_STANDARD_ALLOCATOR:BOOL=ON
[15:27] <sil2100> hmmmm
[15:27] <jamesh> sil2100: do you have a build log?  I can't guarantee I'll be able to understand the error, but it might help
[15:29] <sil2100> jamesh: sadly I think I overwrote it with a build without that flag
[15:54] <dednick> hm. valgrinding unity8 is a bit slow :(
[15:54] <sil2100> jamesh: http://paste.ubuntu.com/5940571/
[15:54] <sil2100> jamesh: here's the log from the error
[16:07] <dednick> mzanetti: i have been unable to find out where network indicator is going wrong as of yet. although issue seems to occur in the indicators-client as well.
[16:07] <jamesh> sil2100: I'm not really sure what the problem is then.  It sounds like it got all the way through to building the tests though, so perhaps the error is in how it links one of the libraries
[16:07] <jamesh> sil2100: it's a bit late here, so I don't really have time to investigate it tonight