[02:07] <xtalmath> Hi, not sure if this is the right place to ask, I want my application to generate a system wide dialog prompt, so the user can not switch to a browser (its for productivity software). what library or system call do I need? I assume I will be using C++
[02:08] <xtalmath> i.e. the user needs to process the prompt dialog, to enjoy freedom again
[09:13] <greyback> davmor2: hey, could you move the QA testing card for silo27 to be unblocked? All branches are approved now
[09:28] <davmor2> greyback: thanks
[12:37] <dandrader> so lp:unity8/overlay is not being used anymore?
[12:37] <dandrader> mzanetti, ^
[12:46] <mzanetti> dandrader, yes it is
[12:47] <greyback> mzanetti: are we not dual landing? How does overlay branch fit in now?
[12:47] <mzanetti> greyback, yes, dual landing... just using overlay branch still
[12:47] <mzanetti> reason is that overlay branch has jenkins running for vivid+overlay
[12:48] <greyback> ah
[12:48] <mzanetti> we asked CI to move that to trunk, but afaik that didn't happen yet
[12:48] <greyback> so we target MPs to ...?
[12:48] <mzanetti> overlay
[12:48] <greyback> ok
[12:48] <mzanetti> I'll merge them to trunk after it landed
[12:48] <greyback> dandrader: sorry, my bad
[12:49] <mzanetti> note that landing only means building packages and merge to the branch they are targetted to
[12:49] <mzanetti> dual-landing means build packages for both distros, still merges the code to the branch it is targetted
[12:49] <mzanetti> lanidng doesn't care about the branch name
[12:51] <greyback> mzanetti: sure, I just thought we abandoned the '2 trunks' idea
[12:51] <mzanetti> we kinda did... using only overlay atm :D
[12:52] <mzanetti> I hope we'll get CI running on trunk soon and can drop that
[12:53] <pstolowski> mzanetti, hey, still fighting with silo 4. all the projects except for unity-scopes-shell are now dual-landable, because of that i think the only way around it is to set the silo to 'wily' only, and then when it lands, make another silo for vivid overlay where all the stuff is just binary-synced from wily, but shell plugin has a separate MP. i just talked to sil2100 and this is possible with current infra
[12:54] <pstolowski> mzanetti, any objections/ideas?
[12:54] <mzanetti> in general, yes, I object the idea to land to wily only
[12:54] <mzanetti> but if there's no way out... dunno.... hate this mess
[12:55] <mzanetti> why can't we dual land unity-scopes-shell?
[12:55] <mzanetti> I mean... we should fix that really
[12:55] <pstolowski> mzanetti, because of different symbols files
[12:55] <mzanetti> not really sure what that means tbh :D
[12:55] <pstolowski> mzanetti, that's fixable, though a lot of work around debian packaging which i don't really understand tbh...
[12:56] <mzanetti> the packages are built twice
[12:56] <mzanetti> so the symbols in the libs should be fine
[12:56] <pstolowski> mzanetti, c++ symbols are different with gcc4.9 and gcc5
[12:56] <greyback> lots of people in theory should have this same issue
[12:56] <pstolowski> mzanetti, no, because symbols file live in the source tree
[12:56] <mzanetti> sure... but dual landing builds two packages
[12:56] <pstolowski> mzanetti, so they were re-generated for wily
[12:57] <pstolowski> greyback, only affects libs and plugins
[12:57] <greyback> alan_g: how is mir dealing with different symbols between vivid+overlay & wily?
[12:58] <alan_g> greyback: it isn't
[12:58] <mzanetti> first time I see such a symbol file as part of the packaging
[12:58] <pstolowski> mzanetti, look at debian/*symbols in any lib package
[12:58] <mzanetti> yeah... that's what I'm doing
[12:59] <mzanetti> not sure what this is good for tho
[13:00] <mzanetti> pstolowski, can't we land this first and the the other branches? or the other way round?
[13:00] <pstolowski> mzanetti, it should prevent unexpected abi breakages. in theory. in practice it's far from perfect, but lack of symbols raises red flag whenever you try to land something ;)
[13:00] <pstolowski> mzanetti, sorry, what do you mean?
[13:00] <alan_g> mir ensures that wily packages supersede vivid (non-overlay) ones and we don't try to deal with folks with "a random ppa" confusing things
[13:02] <pstolowski> mzanetti, everything needs to land together because of the magic version number of unity-api which we bump, and both unity8 and unity-plugin-scopes depend on the extact number
[13:02] <mzanetti> pstolowski, well, I know if saviq would be here he'd say fix the symbols file
[13:03] <mzanetti> this is gonna be hitting us all the time again if we don't fix it
[13:03] <pstolowski> mzanetti, fair point
[13:06] <tsdgeos> mzanetti: pstolowski: wasn't there some plan to have an "overlay repo" with just the debian folder to build for a different release (vivid/wily) ?
[13:06] <mzanetti> sil2100 said something like this. don't think it actually happened. not sure...
[13:08] <pstolowski> tsdgeos, i've never heard of that
[13:08] <greyback> alternative method was mentined in the ML, to tag the symbols
[13:09] <pstolowski> greyback, interesting, do you have a pointer to the ML?
[13:12] <tsdgeos> tedg: any progress on the fd leaking? any help i can provide?
[13:13] <tedg> tsdgeos: Progress, but nothing to report. It is kinda weird. :-/
[13:13] <tsdgeos> :/
[13:13] <tedg> tsdgeos: Trying to get a minimal viable breakage to see what is wrong.
[13:37] <mzanetti> dandrader, hey, about the mail I wrote, regardingt he assertion in the DDA
[13:38] <dandrader> mzanetti, haven't looked into it yet
[13:38] <mzanetti> ah ok. no worries
[14:34] <Saviq> pstolowski, there isn't a special branch for unity-api as lp:unity-api/trunk-15.04 was just ahead of lp:unity-api
[14:34] <Saviq> pstolowski, so it's a simple push from /trunk-15.04 to lp:unity-api
[14:35] <pstolowski> Saviq, i'm not sure what are you referring to? in any case both should be the same now, I updated lp:unity-api yesterday
[14:35] <Saviq> pstolowski, I'm just in from vacation, so replying to pings that happened throughout the week...
[14:36]  * Saviq reads up on the symbols issue
[14:36] <pstolowski> mzanetti, Saviq i may have a solution for unity-scopes-shell build from single tree
[14:37] <mzanetti> nice
[14:37] <pstolowski> mzanetti, Saviq following what michi did in unity-scopes-api/singletree, only simpler because the plugin is simpler
[14:37] <pstolowski> we will see if distro guys like it.. :/
[14:38] <Saviq> pstolowski, mzanetti, if there's reasons to keep two branches, fine by me, as long as there is a reason, and they're both landed as close to one another as possible
[14:38] <pstolowski> Saviq, the only reason is symbols really, no diff in features
[14:38] <Saviq> pstolowski, mzanetti, so that the two-branch issue does not go viral (as it did because of gcc5)
[14:41] <Saviq> pstolowski, about CI for unity-api, what we should have is have it run on both wily and vivid+o
[14:42] <Saviq> pstolowski, but since vivid+o is the more important target now, I'd say we should switch to that if we can't have both
[14:42] <Saviq> still need to talk to ci folk about that
[14:42] <mterry> I think old tags got into lp:unity8/overlay again
[14:42] <Saviq> is /overlay alive still?
[14:42] <pstolowski> Saviq, ok, makes sense. i didn't know the former is even possible
[14:42] <mterry> (they are not in lp:unity8
[14:42] <Saviq> if silo 14 landed, /overlay should be killed with fire
[14:42] <mterry> Saviq, mzanetti: guh, ok.  I thought we were still using it
[14:42] <tsdgeos> Saviq: noooooo, it's the only place we get proper CI :D
[14:43] <tsdgeos> mterry: something's up with the .po files in your MR
[14:43] <tedg> tsdgeos: Okay, I think that branch cleans up the FD now. At least it does in my tests :-)
[14:43] <mterry> tsdgeos, yeah I accidentally branched from lp:unity8, proposed into overlay
[14:43] <mterry> tsdgeos, I set it to WIP while I clean up
[14:43] <Saviq> tsdgeos, should be easy to switch that onto trunk, I'll try and find out what can be done this afternoon
[14:44] <tsdgeos> tedg: cool, want me to try it up?
[14:44] <tedg> tsdgeos: Yes please
[14:44] <tsdgeos> tedg: https://code.launchpad.net/~ted/ubuntu-app-launch/lp1495871-unref-context ?
[14:46] <tedg> tsdgeos: si
[14:51] <mzanetti> Saviq, well. that would kill our jenkins runs
[14:51] <mzanetti> Saviq, but yes, once jenkins is fixed, definitely kill that branch
[14:52] <mzanetti> Saviq, note, there's one silo waiting for QA which targets overlay still (dual landed tho)
[14:52] <Saviq> mzanetti, there's no jenkins runs on trunk? or you mean they're for wily and not vivid+o?
[14:52] <mzanetti> the latter
[14:52] <Saviq> mzanetti, kk, so once that lands we can kill, I'll try and sort out CI before then
[14:52] <mzanetti> ta
[15:12] <mterry> ltinkl, I filed bug 1496436
[15:16] <ltinkl> mterry, ye thx
[15:22] <mterry> ltinkl, is it possible to put lp:~mterry/unity8/tutorial-redesign in your OOBE silo for design?
[15:22] <tsdgeos> tedg: seems to fix it for me :)
[15:22] <mterry> ltinkl, it's a very rough cut of the redesign, but she asked if she could see it as is
[15:24] <ltinkl> mterry, I can't personally (not being on the approved list) but you could ask mzanetti/greyback
[15:25] <ltinkl> mterry, good idea definitely
[15:26] <mzanetti> mterry, on it
[15:26] <mzanetti> mterry, need an MP
[15:26] <mzanetti> can be WIP tho
[15:26] <greyback> I'm starting to think we shouldn't be using silos for demoing stuff to designers
[15:27] <mzanetti> I think that was one of the goals of the whole thing
[15:27] <mzanetti> the plan was even that it spits out ready-to-flash images just for this purpose
[15:27] <greyback> I'd be ok with a non-landing silo system for that kind of thing
[15:27] <mzanetti> well, testing/deming in general, not just with designers
[15:27] <greyback> but I don't want to start using up landing silos on teams who need them
[15:33] <tedg> tsdgeos: \o/
[15:34] <Saviq> greyback, that's the airline plan all along, with ephemeral on-demand PPAs
[15:34] <greyback> Saviq: sure, but we're still on the train :)
[15:39] <Saviq> greyback, there's quite a bit of cars these days though (like 40 or something?)
[15:39] <kgunn> and they do tell us to clean when it gets tight
[15:39] <Saviq> looks more like 60 these days
[15:39] <Saviq> but...
[15:40] <Saviq> 55 assigned
[15:43] <greyback> Sure. I'm just wary of taking more than our fair share, whatever that is
[16:30] <mterry> mzanetti, whoops, went to lunch.  Here's an MP: https://code.launchpad.net/~mterry/unity8/tutorial-redesign/+merge/271342
[16:31] <mzanetti> mterry, ack, will add it
[20:37] <dandrader> mterry, are you familiar with unity8-desktop-session-mir package?
[20:37] <mterry> dandrader, yeah...
[20:38] <mterry> installs u-s-c as I recall
[20:39] <dandrader> mterry, I installed in wily. when I use it, it's all black and unity8.log shows "QXcbConnection: Could not connect to display"
[20:39] <mterry> dandrader, humph
[20:39] <dandrader> mterry, to clealy the environment is wrong
[20:39] <mterry> dandrader, I haven't tested it myself recently
[20:39] <dandrader> s/to/so
[20:39] <dandrader> but it works fine on vivid+overlay
[20:39] <dandrader> I wonder if there are any differences
[20:39] <dandrader> between the two
[20:40] <dandrader> mterry, does it use /usr/share/upstart/sessions/unity8.conf like on the phone? even though desktop is now systemd
[20:42] <mterry> dandrader, the package works fine on vivid+overlay?  the way I remember it, it installs a couple packages (like u-s-c) and a config file to set up lightdm to use it
[20:43] <dandrader> mterry, yes
[20:43] <dandrader> mterry, have been using it for a while now
[20:44] <mterry> dandrader, looks like it installs a whole new desktop session.  Uses /usr/share/lightdm/sessions/unity8-mir.desktop
[20:45] <dandrader> mterry, I thought you were the author of this package :)
[20:45] <mterry> dandrader, it's been a long time!
[20:46] <mterry> dandrader, actually, I'm not even in the debian changelog...  Was trying to see the last time I touched it
[20:47] <dandrader> mterry, so, the question is: where's the place that sets the environment where unity8 runs?
[20:47] <dandrader> mterry, I'm totally lost in this lightdm world...
[20:47] <mterry> dandrader, /usr/bin/lightdm-unity8-session is installed by that package and looks like it does some setup
[20:50] <dandrader> "If no X server is available" <- this blows my mind. what the heck xserver has to do with unity8 and mir....
[20:50] <dandrader> and the environment it sets there is for client apps.....
[20:52] <dandrader> but then, it's the same in vivid...
[21:16] <dandrader> mterry, well... now it decided to work... go figure
[21:17] <mterry> dandrader, huh
[22:13] <xtalmath> suppose I want to generate a system wide dialog prompt, to force me to handle some priority, how do I generate this? which permissions will the application need? i.e. something similar to the password prompt, but I'd like to have a different window/dialog appear...
[22:39] <xtalmath> Im trying to make a productivity manager, that stops me from using the computer after a timeout, unless I get back to the planned schedule