[00:23] <mterry> robert_ancell, heyo.  So I started on a dbus api branch for the greeter.  But...  I ran into some problems, partly terminology, partly unsure if u-s-c is just very incomplete now
[00:23] <robert_ancell> mterry, hi
[00:23] <mterry> robert_ancell, I have some IRC questions, but if interested, my simple branch is here: https://code.launchpad.net/~mterry/unity-system-compositor/greeter-api/+merge/173592
[00:24] <mterry> robert_ancell, so (A) mir::Surface vs mir::Session inside of Mir.  Let's say I want the object that equals the whole user session image.  What is that called in Mir?
[00:24] <mterry> mir::Session seemed to be app-oriented, but contain sub surfaces
[00:25] <robert_ancell> mterry, mir::Session is a single connection to Mir. In the case of a shell/XMir they only have one mir::Surface. So mir::Session is the object that uniquely defines a user session
[00:27] <mterry> robert_ancell, hmm, OK.  Each session is assigned a name.  The only place I could see that being set was creating ApplicationSessions, which seemed to be the app name.  What might those user mir::Session names be?  (I'm trying to see how to find a given session based on user name)
[00:27] <robert_ancell> mterry, lightdm gives them a name so it can recognise them when they reconnect. At the moment it's just '0', '1', ...
[00:28] <robert_ancell> though there is now a new feature where we get the PID for each session, so might switch to that
[00:28] <mterry> robert_ancell, I couldn't find anything in mir or u-s-c that related to users, uids, or names
[00:29] <robert_ancell> mterry, the ID is passed to XMir with the -mir flag xserver_local_get_mir_id() in lightdm
[00:29] <robert_ancell> and that's used in the mir_connect call
[00:30] <robert_ancell> see SystemCompositor::set_active_session for accessing that name - mir::shell::Session::name()
[00:31] <robert_ancell> mterry, u-s-c doesn't know about users, but lightdm does. So I think the greeter is going to have to get that mapping from or via lightdm
[00:32] <mterry> robert_ancell, ok
[01:34] <duflu> This is crazy
[01:34]  * duflu checks NBN rollout schedule
[01:45] <thomi> robert_ancell, all: the mir docs upload job is broken. It's a known issue, and will be fixed in the next 24 hours - I'm just waiting on a new SSH keypair from Francis.
[01:45] <robert_ancell> thomi, ta
[01:45] <thomi> so the docs won't get updated, but I'm on it :)
[01:46] <robert_ancell> mterry, still there?
[01:46] <mterry> robert_ancell, yeah
[01:46] <robert_ancell> mterry, was thinking more about the transition, can you do a call?
[01:48] <mterry> robert_ancell, err, not easily
[01:48] <robert_ancell> mterry, ok, np
[01:50] <robert_ancell> mterry, the session being logged into needs to show  when the user starts authenticating for that session right? Is there a reason lightdm doesn't pick that up and notify u-s-c?
[01:51] <robert_ancell> Are there more complicated cases where we need to synchronize the greeter with u-s-c?
[01:53] <mterry> robert_ancell, not yet, but that puts u-s-c support into lightdm, which may not be ideal from an abstraction POV
[01:54] <robert_ancell> mterry, I'm thinking this would just be contained to seat-unity.c, which would be acceptable in that sense
[01:54] <mterry> robert_ancell, there's already special unity support?   I see, that wouldn't be any worse then
[01:54] <mterry> robert_ancell, so sure, no need to involve the greeter then
[01:55] <mterry> robert_ancell, and that means we don't have to poke a DBus hole for the lightdm user
[01:55] <robert_ancell> mterry, yeah, the "unity" seat type is named like that so we can put whatever is appropriate in there
[01:55] <robert_ancell> mterry, correct, we'd just use the link that lightdm has already to u-s-c which would be simpler
[01:55] <robert_ancell> It would be more difficult if we need a more complex interaction, but I'm not seeing that at present
[01:55] <mterry> robert_ancell, is there a u-s-c branch of lightdm for me to look at?
[01:55] <robert_ancell> mterry, it's on trunk now
[01:55] <mterry> k
[02:03] <smartboyhw> robert_ancell, mterry http://paste.ubuntu.com/5857176/ ?
[02:03] <smartboyhw> Freshly pulled from bzr
[02:04] <robert_ancell> smartboyhw, you need a modified version of mesa, best got from https://launchpad.net/~mir-team/+archive/system-compositor-testing
[02:04] <smartboyhw> robert_ancell, I do have that ppa installed
[02:04] <smartboyhw> robert_ancell, I think that it is the problem of a new X version in archive
[02:05] <robert_ancell> RAOF, ^ Do those recent naming changes match up in the PPA?
[02:05] <robert_ancell> smartboyhw, you might be hit by this change http://bazaar.launchpad.net/~mir-team/mir/trunk/revision/821
[02:06] <robert_ancell> heh, in saying that. I just compiled and I'm hitting the same problem :)
[02:07] <smartboyhw> robert_ancell, HAH HAH HAH
[02:10] <RAOF> robert_ancell: Just back from a run; I'll check in a moment.
[02:32] <duflu> robert_ancell, smartboyhw: system-compositor-testing will not only have likely linkage problems, but crashes too: https://bugs.launchpad.net/bugs/1197260
[02:33] <smartboyhw> duflu, uh
[02:33] <duflu> Seems RAOF has updated staging but not system-compositor-testing yet
[02:33] <RAOF> Oh, that would be right.
[02:36] <duflu> Ugg, more raring FTBS regressions
[02:36] <duflu> FTBFS
[02:41] <robert_ancell> RAOF, what's stopping up updating X in the PPA to 1.14?
[02:41] <RAOF> robert_ancell: It already is 1.14 in staging; I'm in the process of fixing XMir on hybrid systems, then I'll update the testing-ppa too.
[02:42] <robert_ancell> RAOF, ok
[02:42] <robert_ancell> thomi, is the raring mesa in https://launchpad.net/~mir-team/+archive/system-compositor-testing/+packages still coming from the autolanding system? Can we disable it if not?
[02:46] <robert_ancell> racarr, around?
[02:51] <smartboyhw> robert_ancell, you are in ~bug-control right?
[02:52] <robert_ancell> smartboyhw, LP doesn't seem to have a group called that...
[02:52] <smartboyhw> robert_ancell, ~ubuntu-bug-control?
[02:53] <robert_ancell> smartboyhw, that doesn't seem to exist either
[02:53] <smartboyhw> robert_ancell, just the Ubuntu Bug Control team...
[02:54] <robert_ancell> ~ubuntu-bugcontrol
[02:54] <robert_ancell> LP says I am an indirect member of that team, yes
[02:55] <smartboyhw> robert_ancell, alright.
[03:02] <thomi> robert_ancell: hmmm, will take a look. I didn't think we autolanded anything in there, but it seems we do
[03:09] <duflu> thomi: Please keep raring open in staging at least. I'm using it :)
[03:10] <thomi> duflu: it looks like it's not even building in raring
[03:11] <thomi> I'll leave it along, since I didn't even know it was enabled, unless robert_ancell asks me to disable it again, in which case he wins ;)
[03:11] <robert_ancell> thomi, ok, I'll delete the package, and bug you if it turns up again :)
[03:11] <duflu> thomi: I'm talking about PPAs. I believe we already banished raring from autolanding and CI
[03:11] <duflu> Because I remember the argument :)
[03:12] <thomi> duflu: yeah, I'm talking about PPAs as well - the system-compositor-testing PPA in this instance
[03:13] <thomi> I remember this argument as well, I also seem to get mixed instructions about raring support, so I'm not really sure what to do about that, beside give priority to the last request
[03:13] <duflu> thomi: I only ask that you don't delete it from staging
[03:14] <duflu> Although if I want a stable machine then one could argue I'm stupid for using PPAs
[03:14] <thomi> duflu: ok, I'm not going to delete it from anywhere, but you'll need to upgrade to saucy and join the cool kids one day ;)
[03:14] <duflu> thomi: I have several saucy machines. But I like raring
[05:10] <robert_ancell> RAOF, any ETA on updating the system-compositor PPA?
[05:14] <RAOF> robert_ancell: Everything's building in mir-team/staging now.
[05:14] <robert_ancell> RAOF, k
[05:32] <tvoss> thomi, ping
[05:34] <tvoss> RAOF, ping
[05:41] <thomi> tvoss: Hi
[05:54] <tvoss> didrocks, ping
[05:58] <RAOF> tvoss: Pong.
[06:00] <didrocks> tvoss: pong
[06:01] <tvoss> didrocks, hey there :) any update on the unity-gmock branch?
[06:01] <tvoss> didrocks, also: a review of https://code.launchpad.net/~thomas-voss/platform-api/add-location-service-api-take-2/+merge/173457
[06:01] <tvoss> would be highly appreciated
[06:01] <didrocks> tvoss: it's building as we speach
[06:01] <didrocks> tvoss: will have a look
[06:01] <tvoss> didrocks, thanks :)
[06:01] <didrocks> tvoss: do you know if bregma got to the nux branch btw?
[06:02] <tvoss> didrocks, nope, no idea. Will ping him today
[06:02] <didrocks> thx
[06:05] <didrocks> tvoss: hum, you didn't fix the MP since I pinged you, right?
[06:06] <didrocks> https://code.launchpad.net/~thomas-voss/platform-api/add-location-service-api-take-2/+merge/173457/comments/387948
[06:06] <tvoss> didrocks, forgot to push ;)
[06:07] <didrocks> :)
[06:11] <tvoss> didrocks, pushed
[06:11] <didrocks> tvoss: thanks, looking
[06:13] <didrocks> tvoss: I don't understand your package naming convention
[06:13] <tvoss> didrocks, why not?
[06:13] <didrocks> libplatform-hardware-api1-hybris installs libubuntu-platform-hardware-api1
[06:13] <tvoss> didrocks, yup, I would like to fix it, but in another MP
[06:13] <didrocks> I guess your intend is that it's the platform hybris flavor?
[06:14] <didrocks> tvoss: hum, you are introducing those new packages, wouldn't it be better to fix them right now?
[06:14] <didrocks> rather than delivering another package that will have again a transition path needed?
[06:14] <tvoss> didrocks, I would rather prefer to have that MP land as is in accordance with the rest of the packaging setup
[06:14] <tvoss> didrocks, and clean it up in one go
[06:15] <didrocks> tvoss: can we wait to land that one + cleanup the same day then?
[06:15] <didrocks> 95 This package provides the hybris implementation of the hw-access parts of the Platform API.
[06:15] <didrocks> -> this is > 80 characters, won't fit in some UIs
[06:16] <didrocks> (same with -headers)
[06:17] <didrocks> tvoss: please look at the lintian warnings, you have quite a lot on the -doc package as well
[06:17] <tvoss> didrocks, can I just split the lines?
[06:17] <didrocks> tvoss: sure, as long as it's not the short description, this is possible
[06:17] <tvoss> didrocks, dpkg-buildpackage gives me the lintian warnings?
[06:17] <didrocks> tvoss: debuild or bzr bd does
[06:17] <didrocks> tvoss: you can launch manually as lintian *.deb
[06:20] <didrocks> tvoss:          libplatform-hardware-api1-hybris | libplatform-hardware-api1,
[06:20] <didrocks> ok… let's wait for the package reshaping for that one… :)
[06:21] <didrocks> tvoss: just summed that up as https://code.launchpad.net/~thomas-voss/platform-api/add-location-service-api-take-2/+merge/173457/comments/388392
[06:42] <tvoss> didrocks, for the comments: I wonder why this mp raises those concerns as the previous one that landed actually introduced the changes you are commenting (if I understand correctly)
[06:43] <duflu> RAOF: ping
[06:43] <RAOF> duflu: Fong.
[06:44] <duflu> RAOF: Why don't I see, or why don't we need to set_crtc to a new DRM FB ID when the display's buffer object changes?
[06:45] <didrocks> tvoss: the new packages are added in that MP, isn't it?
[06:45] <didrocks> tvoss: the splitting in 2 packages
[06:46] <RAOF> duflu: Because we drmModePageFlip instead.
[06:47] <RAOF> (See kms_page_flipper.cpp
[06:47] <RAOF> )
[06:47] <didrocks> tvoss: the unity build failed, can you try to have your branch merged against trunk to ensure you have the barriers fix?
[06:50] <tvoss> didrocks, nope, that's the branch you already approved :)
[06:51] <didrocks> tvoss: that doesn't make the arg invalid. I'm reviewing 30+ branches a day, can do mistakes :)
[06:51] <tvoss> didrocks, fair point :) I was just confused
[06:54] <tvoss> didrocks, I fixed the lintian warnings and addressed your comments
[06:55] <didrocks> tvoss: looking good, let me look at a last rebuild
[06:55] <RAOF> Aaaand everything's deadlocked in the kernel again.
[06:55] <tvoss> RAOF, \o/
[06:56] <tvoss> didrocks, updated the unity mp
[06:58] <didrocks> tvoss: so, approved with a missing long description fix (would be nice to do that) and waiting on the followup MP to get both landing
[06:58] <didrocks> pulling unity
[07:00] <tvoss> didrocks, I will take the package renaming discussion to ricmm and rsalveti once they are awake
[07:02] <didrocks> tvoss: great :)
[07:26] <dholbach> good morning
[07:34] <didrocks> tvoss: hum, still has the same issue than with my branch
[07:34] <didrocks> for unity
[07:34] <didrocks> no target check-headless
[07:34] <didrocks> tvoss: did you try running bzr bd on your branch?
[07:39] <tvoss> didrocks, it fails locally, too
[08:44] <tvoss> didrocks, still building locally :)
[08:44] <tvoss> greyback, ping
[08:45] <didrocks> tvoss: waow, you need ccache I guess :)
[08:47] <tvoss> didrocks, yup
[08:47] <tvoss> didrocks, I need a distcc cloud :)
[08:49] <didrocks> heh
[08:49] <didrocks> I did that some years ago on my machine
[08:49] <didrocks> and then, became lazy
[08:49] <ogra_> get faster hardware :P
[08:50] <tvoss> ogra_, why not juju deploy massive-distcc-cloud
[08:50] <greyback> tvoss: pong
[08:50] <ogra_> tvoss, heh, feel free ....
[09:00] <tvoss> katie_, ping
[09:01] <katie_> tvoss, hi
[09:01] <tvoss> katie_, can you add me to the hangout?
[09:01] <katie_> tvoss, i'm in the hangout
[09:01] <katie_> sure
[09:16] <tvoss> didrocks, so there is no target check-headless, and make check fails due to an assertion in g_main_loop
[09:16] <didrocks> tvoss: yeah, the check-headless target is only generated when unity successfully detected gtests and so on
[09:16] <didrocks> from what I saw in cmake
[09:17] <tvoss> didrocks, yeah, looking into that, too
[09:54] <tvoss> didrocks, found the issue, final dpkg-buildpackage run to check that all is good
[09:54] <didrocks> tvoss: ah, excellent! tell me once you pushed :)
[10:35] <tvoss> didrocks, package build successful, pushed the changes
[11:40] <didrocks> tvoss: built fine here as well, please link to the bug and make a MP
[11:40] <didrocks> tvoss: oh, please add the version in google-mock build-dep
[11:40] <didrocks> the only remaining one for new gmock is thus nux now
[11:44] <tvoss> didrocks, done: https://code.launchpad.net/~thomas-voss/unity/new-gmock/+merge/173450
[13:37] <greyback_> kdub: ping
[14:22] <xjunior> Morning guys. Since yesterday I'm not being able to start X/XMir
[14:22] <xjunior> it starts to initialize (I even see Mir's big arrow at the top-left corner)
[14:22] <xjunior> Then crashes. Anybody having this issue?
[14:31] <greyback_> xjunior: first I've heard of it. Would you mind following this guide on helping us figure out such problems: http://bazaar.launchpad.net/~mir-team/mir/trunk/view/head:/doc/debug_for_xmir.md
[14:32] <xjunior> sure!
[14:35] <greyback_> xjunior: appreciated, thank you
[14:36] <smartboyhw> Hmm RAOF isn't here, so I can't ask him on the progress on building new X version
[14:37] <xjunior> greyback_: the logs in /var/logs/lightdm seem way more useful than Xorg.0.log
[14:37] <xjunior> greyback_: found this
[14:37] <xjunior> Switching to Mir session 0
[14:38] <xjunior> Logging to /var/log/lightdm/x-0.log
[14:38] <xjunior> Can't launch X server X -core, not found in path
[14:38] <xjunior> :P
[14:38] <smartboyhw> :O
[14:39] <greyback_> xjunior: did you pin the xmir packages, as described in http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html ?
[14:39] <xjunior> xserver-xorg was removed by an update
[14:39] <xjunior> not manually
[14:39] <xjunior> yep
[14:39] <greyback_> interesting.
[14:39] <xjunior> greyback_: I didn't install that mir-demos package though
[14:39] <xjunior> is it important? what's that?
[14:40] <smartboyhw> xjunior, try installing xserver-xorg and see what will it remove...
[14:40] <xjunior> I installed following another step-by-step
[14:40] <greyback_> xjunior: a set of mir-demos, not vital IMO (only recommended as it pulls in all libmir* packages)
[14:40] <xjunior> so, xserver-xorg has unmet dependencies
[14:40] <smartboyhw> xjunior, what unmet dependencies?
[14:40] <smartboyhw> !paste | xjunior
[14:41] <xjunior> xserver-xorg-core (>= 2:1.11) but it is not going to be installed
[14:41] <xjunior> xserver-xorg-video-all but it is not going to be installed or xorg-driver-video
[14:41] <smartboyhw> xjunior, if you install xserver-xorg-core what shows up?
[14:41] <xjunior> boom
[14:41] <smartboyhw> xjunior, ?
[14:42] <greyback_> xjunior: you're not the first with the issue: https://lists.ubuntu.com/archives/ubuntu-devel/2013-July/037450.html
[14:42] <xjunior> xserver-xorg-core : Depends: libmirclient1 (>= 0.0.6bzr828saucy0) but 0.0.6bzr798saucy0 is to be installed
[14:42] <smartboyhw> Ah, I remembered that
[14:42] <smartboyhw> xjunior, :O
[14:42] <xjunior> smartboyhw: :D any idea?
[14:43] <smartboyhw> xjunior, um, I
[14:43] <smartboyhw> 'm looking @ the PPA
[14:43] <xjunior> is there a base pack I can remove to uninstall everything, then I install all over again?
[14:43] <smartboyhw> What happened it seems
[14:43] <greyback_> xjunior: I'd first apt-get update, then try to install xserver-xorg-core, and then follow apt's recommendation to "apt-get -f install" - hopefully it'll downgrade the mirclient package and let you re=isntall xorg
[14:44] <xjunior> greyback_: I've done dozens of apt-get update last hour
[14:44] <tvoss> xjunior, best approach would be to purge the ppa from your system, reboot and readd the ppa
[14:44] <smartboyhw> greyback_, xjunior the new xorg RAOF uploaded lists libmirclient bzr828 as dep
[14:44] <ogra_> sounds like you had saucy-proposed enabled ...
[14:44] <xjunior> apt-get -f install didn't help =/
[14:44] <ogra_> never ever do that
[14:44] <tvoss> xjunior, sudo ppa-purge ppa:mir-team/system-compositor-testing
[14:44] <smartboyhw> But, obviously the PPA only has bzr798
[14:44] <smartboyhw> It's PPA's fault
[14:44] <tvoss> smartboyhw, mind filing a bug against mir?
[14:44] <xjunior> ogra_: I have what?
[14:45] <smartboyhw> tvoss, let the bug reporter file the bug himself
[14:45] <ogra_> xjunior, do you have the saucy proposed archive enabled ? (you shouldnt)
[14:45] <tvoss> smartboyhw, ah sorry, I thought you had encountered the issue, too
[14:45] <xjunior> ogra_: I don't think I do
[14:45] <ogra_> k
[14:45] <ogra_> (it is just that we had someone yesterday who had that and X was completely removed due to that)
[14:46] <xjunior> tvoss: ok, so I'll purge, update, upgrade and reboot?
[14:46] <tvoss> xjunior, ppa-purge does the job of update and upgrade, only reboot should be required after that
[14:47] <xjunior> nice
[14:47] <smartboyhw> Well, hopefully someone will move latest mir into the testing PPA
[14:48] <ogra_> heh, hopefully Mir will land in the archive soon instead
[14:48] <xjunior> smartboyhw: do you think it will happen yet today? I don't mind waiting
[14:48] <smartboyhw> xjunior, not sure, I need to ask RAOF
[14:48] <smartboyhw> Who isn't here
[14:48] <ogra_> australia sleeps :)
[14:49] <smartboyhw> Yeah
[14:49] <smartboyhw> I did meet him earlier in the afternnon
[14:49] <smartboyhw> *afternoon
[14:49] <tvoss> xjunior, mind if I file a bug against Mir?
[14:49] <xjunior> slackers :)
[14:49] <xjunior> tvoss: be my guest :) I wouldn't know how to do that
[14:49] <xjunior> ogra_: couldn't find package list for PPA: mir-team
[14:49] <xjunior> system-compositor-testing
[14:51] <kgunn> bregma: ping
[14:52] <kgunn> xjunior: https://launchpad.net/~mir-team/+archive/system-compositor-testing
[14:52] <xjunior> ogra_: well. that's odd
[14:52] <xjunior> but the ppa's source list was all commented out
[14:54] <xjunior> it's doing its job now. I'll wait until tomorrow to try again the ppa.
[14:59] <kdub> morning folks
[14:59] <kdub> greyback_, pong
[15:02] <xjunior> ogra_, tvoss, smartboyhw: back to g'old xorg
[15:02] <smartboyhw> xjunior, good, wait for a few days then:)
[15:03] <tvoss> xjunior, yup, filing the bug now :) we usually update the ppa during my mornings
[15:03] <smartboyhw> Heh, the two pointers thing is quite annoying for me, ogra_ when will the fix land?
[15:03] <xjunior> smartboyhw: I'm trying to get the PPA back and actually pay attention to what it upgrades
[15:04] <greyback_> kdub: hey, let me unping you for a bit :)
[15:04] <smartboyhw> tvoss, BTW why do you guys mark 0.0.6 as done but without actually releasing it?:P
[15:05] <tvoss> xjunior, for your tracking pleasure https://bugs.launchpad.net/mir/+bug/1199399
[15:05] <xjunior> thanks a bunch, tvoss
[15:05] <tvoss> smartboyhw, not entirely sure, best if you check with robert_ancell or duflu
[15:06] <xjunior> tvoss: I re-enabled the PPA, apt-get update, installed unity-system-compositor
[15:06] <xjunior> now apt-get upgrade
[15:06] <xjunior> it doesn't want to remove my stuff now
[15:06] <xjunior> let's see where this takes me
[15:07] <tvoss> xjunior, let's see :9
[15:07]  * smartboyhw raises eyes at xjunior 
[15:07] <xjunior> alright
[15:08] <xjunior> it seem to have installed and didn't remove anything
[15:08] <xjunior> but xserver-xorg-core is being kept back
[15:09] <xjunior> do y'all work at canonical, tvoss, smartboyhw ?
[15:09] <tvoss> xjunior, I'm working at Canonical, yes
[15:09] <smartboyhw> xjunior, not me
[15:09] <smartboyhw> I'm a Ubuntu member though
[15:09] <xjunior> ok, it broke again :)
[15:09] <xjunior> got it
[15:09] <smartboyhw> xjunior, ouch
[15:09] <xjunior> at least it's consistent. I like consistency
[15:10] <smartboyhw> xjunior, great
[15:10] <smartboyhw> Well let's get that sorted shall we
[15:10] <smartboyhw> tvoss, ^
[15:10] <tvoss> smartboyhw, xjunior I think it's best to wait for RAOF to put the ppa in a consistent state again
[15:11] <smartboyhw> tvoss, yeah
[15:11] <greyback_> kdub: unping for now.
[15:12] <xjunior> tvoss: indeed. I could track all that with you guys, but I'm working on an android app in that computer. can't be without it for now
[15:12] <smartboyhw> xjunior, backup:p
[15:12] <xjunior> smartboyhw: absolutely :)
[15:12] <xjunior> git FTW
[15:12] <xjunior> I know you guys like bazaar, though :P
[15:12] <smartboyhw> Sorry, it's bzr+nano FTW for me
[15:13] <smartboyhw> git is OK too
[15:13] <smartboyhw> No SVN plz
[15:13] <xjunior> SVN was great in the past.
[15:13] <xjunior> smartboyhw: hey, which advantages do you see of bzr over git?
[15:13] <smartboyhw> xjunior, less commands? Easier merging? Cleaner CLI?
[15:15] <xjunior> Got it…
[15:15] <xjunior> don't fully agree with all of them, but cleaner CLI is very likely to be true ;)
[15:16] <xjunior> tvoss: do you guys work remotely at canonical?
[15:16] <smartboyhw> xjunior, well probably due to my age I don't like too complicated things (albeit I know quite a lot on packaging and QA and sort)
[15:17] <kdub> greyback_, ok :)
[15:17] <xjunior> smartboyhw: I never actually tried bzr, so I can't say much. I admit I had a lot of difficulties with git in the beginning, but after I learned it it's just an awesome tool
[15:18] <smartboyhw> I like cleaner tools
[15:18] <xjunior> specially if you've developed in C, or C++. The object model is quite interesting
[15:18] <smartboyhw> And I appreciate those who made it
[15:18] <xjunior> indeed. I'll take some time to try out bzr for sure
[15:19] <tvoss> xjunior, yup
[15:19] <xjunior> is it my impression, or does Mir/XMir looks sharper than Xorg alone?
[15:19]  * smartboyhw does want to join Canonical (or better still Google) one day
[15:21] <ogra_> Google means you need to move ... Canonical doesnt :)
[15:21] <tvoss> ogra_, +1 :)
[15:21] <smartboyhw> ogra_, I would rather move there to work
[15:21] <xjunior> that's a big thing
[15:22] <xjunior> I'm a former ThoughtWorker. Worked there for some years. Left because I wanted to be more home.
[15:23] <smartboyhw> If I work @ Canonical, the only thing I wouldn't want to touch is Mir:P
[15:23]  * smartboyhw rather likes kernel or QA
[15:23] <xjunior> really? Seem like an interesting project
[15:23] <smartboyhw> Well, maybe talk about it 10 years later or so
[15:23] <smartboyhw> Still too young to be employed:P
[15:23] <xjunior> I see where you're coming from.
[15:24] <smartboyhw> xjunior, where?
[15:24] <xjunior> smartboyhw: I mean, about rather working with Kernel and QA
[15:24] <smartboyhw> xjunior, oh
[15:24] <smartboyhw> Well, these are more *fun*
[15:25] <xjunior> Just different kind of work. I like visual things… I'd work with Mir/Unity
[15:25] <xjunior> also a big fan of dev-tools
[15:26]  * smartboyhw likes sticking to a terminal
[15:31] <bregma> kgunn, pong
[15:31] <kgunn> bregma: hey...i was chatting w tvoss earlier...he was indicating now valgrind is up on arm...but now runs oom
[15:32] <kgunn> bregma: i was trying to square this with what you were originally proposing
[15:32] <kgunn> e.g. disabling the test
[15:32] <kgunn> for arm
[15:32] <bregma> kgunn, valgrind on qemu gets OOM on startup, but it runs fine on my N7
[15:33] <kgunn> bregma: ah...so to parse it finer...disable for qemu ?
[15:34] <bregma> no, the problem is actual tests are deadlocking on at least the N7, I'm proposing to just not run the integration tests on ARM because they exercise the Android drivers
[15:34] <bregma> at least in the packaging, in Jenkins it's a different story
[15:42] <ChrisTownsend> Hey all, I followed the directions here: http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html and now my system is in a bad state.  After plymouth, I see a big mouse cursor and then a black screen with a steady cursor in the upper left part of the screen.  Also, I cannot switch to any VT's.  Any ideas?
[15:45] <bregma> ChrisTownsend, the big cursor is a good sign...  but it sounds like you have a broken Xorg somewhere, check /var/log/Xorg.0.log and /var/log/lightdm/* for signs of trouble
[15:45] <ChrisTownsend> bregma: The problem is I cannot do *anything* right now.
[15:46] <alan_g> ChrisTownsend: can you ssh in from another box?
[15:46] <ChrisTownsend> I suppose I can boot a live stick and mount that partition and check.
[15:46] <bregma> well, you can reboot into safe mode, too
[15:46] <ChrisTownsend> alan_g: Umm, I'm not sure what the IP is and I can't check.
[15:47]  * ChrisTownsend Tries recovery move
[15:47] <ChrisTownsend> Err, mode
[15:49] <bregma> if you can use recovery mode to comment out the type=unity line in /etc/lightdm/lightdm.conf, you should be good to go
[15:50] <ChrisTownsend> bregma: Alright, I'll see if I can do that.
[15:50] <smartboyhw> bregma, when is that big cursor going to disappear?
[15:51] <ChrisTownsend> bregma: I don't have the line "type=unity" in /etc/lightdm/lightdm.conf
[15:53] <ChrisTownsend> bregma: I think I found it in /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf
[15:53] <smartboyhw> ChrisTownsend, that's correct
[15:54] <ChrisTownsend> Yay, it works
[15:54] <ChrisTownsend> bregma: Thanks
[15:54] <smartboyhw> It should:) ChrisTownsend now you're back at your normal X
[15:55] <bregma> ...and all you need to do is figure out why lightdm doesn;t come up!
[15:55] <ChrisTownsend> Oh, I see.  Well...
[15:56] <bregma> smartboyhw, is one cursor is good, more is better
[15:56] <smartboyhw> bregma, well, that's a bug actually
[15:56] <smartboyhw> But it will take sometime to fix
[15:57] <smartboyhw> I don't know the ETA
[15:57] <bregma> it has to be gone by mid-August
[15:57] <smartboyhw> DISCLAIMER: I'm NOT on the Mir Development Team or associated by Canonical by anyway, so don't ask me when it will fixed:P
[15:57] <smartboyhw> bregma, I think the guys will be able to fix it by then
[15:59] <bregma> right now we're sort of using the supernumerary cursor as a kind of watermark to indicate the Mir system compositor is running
[15:59] <smartboyhw> bregma, yeah
[16:05] <ChrisTownsend> Strange, it seems that the non Mir version of xserver-xorg-core is being held back.
[16:08] <ChrisTownsend> So, the version of xserver-xorg-core in the Mir PPA depends on libmirclient1 >= 0.0.6bzr828saucy0, but the version of libmirclient1 in the PPA is 0.0.6bzr798saucy0.
[16:09] <ChrisTownsend> Any ideas when this will be fixed?
[16:10] <tvoss> ChrisTownsend, bug is filed: https://bugs.launchpad.net/mir/+bug/1199399
[16:11] <tvoss> ChrisTownsend, RAOF will take care of it as soon as he comes nline
[16:18] <dandrader> can I parallel-build (e.g. -j10) with cross-compile-chroot.sh?
[16:21] <kdub> dandrader, it won't accept the parameter
[16:21] <dandrader> kdub, so, when cross-compiling, I have to stick to one thread?
[16:22] <kdub> the script is more useful for understanding how to set things up and for CI purposes
[16:22] <kdub> dandrader, all it does really is set up the partial arm chroot, cmake, make
[16:22] <dandrader> kdub, ah, ok, so I can just call make directly
[16:22] <kdub> so you can go into the build directory and make -jX there
[16:23] <dandrader> kdub, ok, thanks!
[16:50] <greyback_> Anyone with XMir finding typing gets strange after a few hours? If I type 10 characters quickly, the first 9 come out reasonably fast, but the last after a delay of almost1/2  a second
[16:50] <greyback_> tvoss: ever heard of that? ^^
[16:54] <kgunn> greyback_: i had
[16:55] <greyback_> kgunn: Xorg memory usage seems to be growing slowly too.
[16:55] <kgunn> it seemed (seems) to relate to having a google hangout & flash having been run
[16:55] <kgunn> at least some deduction around that
[16:55] <greyback_> I've not had a hangout today
[16:55] <kgunn> but honestly...it corrected itself sometime ago...
[16:55] <greyback_> but if that reproduces it, great
[16:56] <kgunn> yeah...yours might be new
[16:56] <alan_g> greyback_: I've seen the same occasionally, but only without XMir.
[16:57] <alan_g> Never found a pattern
[16:58] <greyback_> well I've not experienced this before. I switched to XMir just today.
[17:18] <xjunior> greyback_, kgunn: I experienced a lot of memory leak in hangout, but that's happening in OSX as well.
[17:18] <xjunior> I blame google
[17:19] <kgunn> xjunior: yeah...i've heard all sort of complaints about hangouts in recent updates (but strangely....its rock solid for me)
[17:19] <greyback_> xjunior: but I've not used hangout today, so something else is the culprit
[17:20] <xjunior> kgunn: my laptops are always on, also I use hangout daily for hours. I guess that helps to perceive the leak
[17:20] <kgunn> greyback_: fwiw, i had that issue for like 1 day....but then magically disappeared as an issue
[17:20] <greyback_> kgunn: well I'm logging it: https://bugs.launchpad.net/mir/+bug/1199450
[17:21] <greyback_> I can't give more info than that unfortunately
[17:23] <xjunior> is it just my impression or ubuntu/unity details looks sharper when running on XMir?
[17:27] <ChrisTownsend> tvoss: Ack, thanks
[17:44] <om26er> when do we move to mir on mako as default ?
[18:45] <kgunn> bregma: have you seen the oom for arm mir builds happen on pandas ?
[18:45] <kgunn> ricmm_: ^
[18:45] <kgunn> bregma: or was it only on the qemu ?
[19:10] <kdub> some of our functions are only used in example code, sorta frustrating
[19:10] <kdub> unless...
[19:10] <kdub> well, i suppose some of what the shell team is using could be touching those
[19:55] <racarr> recessitating client_ocus_notifications is running in to insane test failures...
[19:56] <racarr> some of the changes in session mediator ended up doing something very weird in the tests... :(
[19:56] <kdub> session mediator?
[19:59] <kdub> racarr, with input tests, there's this bug https://bugs.launchpad.net/mir/+bug/1196744
[20:25] <racarr> kdub: Ill investigate ater I ifnish client-focus-notiications
[20:26] <kdub> racarr, i'm curious the path the notification takes through the system
[20:26] <kdub> but maybe I should just be patient until an MP :)
[20:40] <racarr> kdub: Same as surface states
[20:49] <testingmir> Hi All! I am testing 13.10 with Mir (from PPA). Got an AMD/ATI card, r600.
[20:50] <testingmir> How do I verify that Mir is actually running? Dash is much slower (unaccelerated?) compared to vanilla 13.10.
[20:51] <testingmir> Anything interesting that I should try out, like testing app?
[20:52] <mlankhorst> sounds more like the mesa regression thing
[20:53] <mlankhorst> in 9.1.X we reverted a bunch of patches to fix it, but the mesa in mir ppa probably doesn't have it
[20:53] <mlankhorst> oh wait ati.. all memory is pinned in system memory unless you're using a recent drm-next kernel
[20:53] <testingmir>  /usr/lib/nux/unity_support_test -p   shows  that llvmpipe is running, "Gallium 0.4 on llvmpipe (LLVM 3.2, 128 bits)".
[20:54] <testingmir> How do I verify that Unity runs under Mir?
[20:55]  * testingmir running Linux 3.10.0-2-generic.
[20:55] <bschaefer> testingmir, a sign is there is a second cursor, also "ps aux | grep mir" should tell you if mir is running in the background
[20:56] <bschaefer> testingmir, also checking your /var/log/Xorg.0.log could help you know why your driver failed to load
[20:57] <testingmir> bschaefer: no 'mir' process is running, so this is not Mir. This is a fresh 13.10 installation (today's CD image), and the system booted OK with the radeon driver).
[20:57] <bschaefer> testingmir, have you followed: http://www.olli-ries.com/running-mir/
[20:57] <bschaefer> ?
[20:58] <ChrisTownsend> testingmir: Unfortunately,if you installed today, the Mir PPA is out of sync: https://bugs.launchpad.net/mir/+bug/1199399
[20:59] <bschaefer> there's also that problem :)
[20:59] <testingmir> bschaefer: I configured my 13.10 with those instructions, http://www.olli-ries.com/running-mir/ (fresh install of 13.10)
[21:00] <bschaefer> testingmir, I would wait until tomorrow unfortunately, for that ppa to get fixed up
[21:00] <bschaefer> (hopefully by tomorrow!)
[21:00] <olli> bschaefer, isn't it ps auf | grep unity-system-compositor?
[21:00] <testingmir> ChrisTownsend: I see. On my initial boot of the system, I managed to see an oversize curson as soon as Mir got started, then a blank screen.
[21:01] <olli> testingmir, sorry for the messed up PPA, we are all waiting for RAOF to get up and fix it
[21:01] <bschaefer> olli, yeah that will tell you if unity system compositor is running, the other way I said will pick up if the mir server is running
[21:01] <ChrisTownsend> testingmir: Yep, that's what I had too.  Wait for the PPA to get updated as bschaefer said.
[21:01] <testingmir> bschaefer: ok. Is there a way to easily revert to the vanilla 13.10 for now, and try out Mir again tomorrow? Shall I ppa-purge when I need to switch?
[21:02] <bschaefer> testingmir, yup! at the bottom of ollis blog, purge the ppa :)
[21:02]  * bschaefer re-reads the blog just to be sure
[21:03] <testingmir> bschaefer: nice. Olli's page is good. Thanks!
[21:04] <bschaefer> testingmir, cool, yup :). np! Good luck tomorrow :), you can also check with the bug to see if its been resolved!
[21:19] <olli> mterry, ping
[21:20] <mterry> olli, hi
[21:20] <olli> hey mterry is there a BP for the system compositor/flicker free boot work?
[21:21] <mterry> olli, I'm not sure, I believe robert_ancell is working on that
[21:21] <mterry> robert_ancell, did you see the question?  Looks like you logged in twice
[21:22] <mterry> robert_ancell_, ^
[21:22] <olli> mterry, I thought kgunn told me you are looking into getting mir in at boot time as system compositor
[21:22] <robert_ancell_> mterry, been having network connection problems, seems better now
[21:22] <olli> well, let me refine... you are working on the transitions
[21:22] <robert_ancell_> mterry, can you repeat?
[21:22] <mterry> olli, I've been helping test it, but not doing the work work
[21:23] <mterry> olli, yeah, I'm looking at how to let the greeter transition into the session right now
[21:23] <olli> robert_ancell_, do we have a BP for mir as system compositor/flicker free boot
[21:23] <robert_ancell_> olli, https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-system-compositor
[21:23] <olli> awkward
[21:23]  * olli could have found that himself
[21:23] <robert_ancell_> :)
[21:23] <olli> thanks robert_ancell_
[21:23] <robert_ancell_> too many blueprints!
[21:24] <olli> nah, didn't bother looking
[21:24] <olli> ;)
[21:24] <mterry> robert_ancell_, speaking of transitions, so I was looking at the current Mir API that u-s-c uses.  Notably, FocusSetter::set_focus_to
[21:26] <mterry> robert_ancell_, do you want a new API proposal that's more targeted, like FocusSetter::set_underneath (or something better named) or something more generic, that lets a client reorder the stack in general?
[21:26] <olli> kgunn, is there a BP that specifically addresses input device compatibility between X & Xmir?
[21:26] <robert_ancell_> mterry, my gut feel is something more generic would be appropriate
[21:26] <kgunn> olli: i think so...but need to dig
[21:26] <kgunn> olli: altho, its probably something akin to "make sure input devices work"
[21:27] <olli> heh
[21:27] <olli> oki
[21:27] <mterry> robert_ancell_, maybe in FocusSequence
[21:27] <kgunn> and i suspect we'd want to be a bit more specific
[21:27] <robert_ancell_> mterry, oh, sorry - I was thinking you meant the lightdm -> u-s-c API
[21:28] <mterry> robert_ancell_, oh, for that, I was thinking we can be more specific, since it's closer to the feature
[21:28] <robert_ancell_> racarr, ^ mterry needs to set the surface below the active one, what sort of API do you recommend for that?
[21:28] <robert_ancell_> mterry, I was pushing for the shell just providing the sort function so you could handle cases like this easily. But no-one listens to me :)
[21:29] <robert_ancell_> shell = u-s-c in this case
[21:29] <mterry> robert_ancell_, for lightdm->u-s-c I was thinking a new message ID that meant "set_next_session" to mirror the "set_active_session"
[21:29] <robert_ancell_> mterry, yeah, that sounds about right
[21:30] <mterry> robert_ancell_, but can't seem to implement that in u-s-c with current Mir API, so would like some guidance from you or racarr
[21:31] <robert_ancell_> mterry, racarr has been the one working on that API, so I'll have to defer to him at the moment. My feel is based on the current API we should just have a set_above / set_underneath
[21:38] <racarr> robert_ancell_: mterry: Was picking up lunch :)
[21:38] <racarr> I think I agree set_above/set_underneath
[21:38] <racarr> What is the case here?
[21:38] <kgunn> bregma when can we expect to have the arm valgrind tests disabled & close out that "entering saucy" bug ?
[21:39]  * kgunn looks for a brighter future away from ppa hell
[21:39] <bregma> kgunn, working on the gmock thing first, arm is queued next
[21:40] <kgunn> bregma: thanks....think it'll be before weeks end ? (trying to balance how much tinkering we need to do on ppa automation)
[21:40] <bregma> definitely
[21:40] <bregma> hopefully by end of tomorrow for the lot
[21:41] <kgunn> \o/
[21:44] <olli> robert_ancell_, can you pls update me when the PPA is good again (mail)
[21:45] <robert_ancell_> thomi, the version of u-s-c in the testing PPA is using one version older than libmirserver - is there a new version being built currently?
[21:45] <olli> jono has a post waiting on that
[21:45] <robert_ancell_> olli, will do
[21:45] <olli> robert_ancell_, thx
[21:45] <thomi> robert_ancell_: on a call, one moment
[21:58] <mterry> racarr, sorry, my service is spotty apparently.  The use case for set_above/set_underneath is the greeter wanting to superimpose its surface on top of the user's session surface
[21:58] <mterry> racarr, along those same lines, is there easy support for adding transforms like "blur this surface" to surfaces?
[22:00] <kdub> mterry, no support for that yet
[22:05] <mterry> kdub, understood
[22:12] <racarr> mterry: The greeter is always above the session surface right?
[22:12] <racarr> So you can give the greeter, DepthId{1}
[22:12] <racarr> nd show/hide it
[22:12] <racarr> then give all the user sessions DepthId{0}, then you can raise the user sessions, etc
[22:12] <racarr> but the greeter will always be on top
[22:13] <mterry> racarr, I didn't notice the API to futz with DepthId
[22:14] <kdub> ms::SurfaceController needs some refinement, i think
[22:14] <racarr> mterry: you can override the_surface_builder and assign them at construct time. it's slightly awkward perhaps (just in that the interface name is wrong)
[22:14] <racarr> mterry: Let me find an example
[22:15] <racarr> mterry: lp:~robertcarr/+junk/with-depth-ids
[22:15] <racarr> unity-mir/surfacebuilder.cpp
[22:18] <racarr> I have an intermittent test failure and I don't even know how to figure out if it's in the client or the server :( the client seems to block endlessly in one of mir_connection_release/mir_connection_sync
[22:18] <racarr> but adding
[22:18] <racarr> any prints or turning on logging makes it go away
[22:19] <mterry> racarr, hrmm..   I'm not sure I fully understand DepthIds
[22:19] <racarr> likewise gdb (even ignoring the difficulty of attaching to the child process)
[22:19] <racarr> mterry: If there are two surfaces with DepthId X and Y and X > Y
[22:19] <racarr> then X will always be on top of Y
[22:19] <racarr> you can call
[22:19] <racarr> raise(Y), and Y will be moved to the top of all surfaces with DepthId <=Y
[22:19] <mterry> racarr, always meaning, even if I use FocusSetter::set_focus_to or some such?
[22:20] <racarr> but still be under X
[22:20] <racarr> mterry: Yes
[22:20] <racarr> its like Layers
[22:21] <mterry> racarr, OK.  I remember looking at them in the API, but they only were used at creation.  It makes sense now that you say I can override the surface builder
[22:22] <racarr> excellent :)
[22:23] <kdub> racarr, that hang you mention... in what tests?
[22:28] <racarr> kdub: create_surfaces/create_surfaces_async
[22:28] <racarr> it seems to also be in the input tests
[22:28] <racarr> but I am trying to fix it in these first
[22:39] <racarr> kdub_: Mine ends up being a deadlock on the client side mir connection
[22:40] <racarr> it gets to MirSurface::release_surface which acquires the recursive lock on the MirSurface
[22:40] <racarr> then calls MirConnection::release_surface
[22:41] <robert_ancell> RAOF_, I've just copied over the staging mir, mesa and u-s-c into the compositor testing PPA, any reason why I shouldn't have done that?
[22:41] <racarr> which trys to acquire the lock, but blocks because an RPC thread is
[22:41] <racarr> has called MirConnection::handle_event
[22:41] <racarr> taking the lock
[22:41] <kdub_> hmm, with the input ones, i have a fix i've been using (it was the difference between surface creation/input callback registration)
[22:41] <racarr> but MirConnection::handle_event tries to call
[22:41] <kdub_> haven't hit that one though
[22:41] <racarr> MirSurface::handle_event
[22:41] <racarr> but the Surface is already locked from the
[22:41] <racarr> original thread
[22:41] <racarr> *deep breath*
[22:42] <robert_ancell> thomi, RAOF, others, the system-compositor PPA seems to upgrade now, can you check if you can run XMir from it?
[22:42] <robert_ancell> kgunn, ^
[22:43] <kdub_> racarr, that sounds like it would be plausible though for the other deadlock
[22:45] <RAOF_> robert_ancell: Not that I'm aware of.
[22:46] <robert_ancell> RAOF, can you test the updated PPA asap? We have been in a broken state overnight
[22:46] <RAOF> What blew up?
[22:47] <RAOF> I tested the new X bits in the staging PPA, then copied them to -testing. Which shouldn't have blown up -testing.
[22:47] <robert_ancell> RAOF, xorg depended on an old version of Mir I think, I can't remember the exact mismatch
[22:48]  * robert_ancell looks through his logs
[22:48] <RAOF> Hm. Xorg may have depended on a *new* version of Mir, I guess.
[22:48] <robert_ancell> RAOF, yeah, that was it
[22:48] <thomi> robert_ancell: hey, sorry - that was a long call
[22:48] <thomi> robert_ancell: the problem resolved itself?
[22:49] <RAOF> Ok. Time to actually generate a symbols file for libmirclient, so this doesn't happen again.
[22:49] <robert_ancell> thomi, I rebuilt u-s-c in the -testing PPA so it matched, though the staging PPA still seems mismatched
[22:49] <thomi> I wonder if autolanding failed
[22:49]  * thomi checks
[22:50] <robert_ancell> thomi, does it wait until the mir build completes, or is published? Since it's one version behind perhaps it doesn't wait long enough to rebuild
[22:51] <thomi> robert_ancell: no, the autolanding stuff uses it's own internal archive
[22:51] <thomi> so anything that's been autolanded is avaialble
[22:51] <robert_ancell> to clarify - u-s-c 0.0.1bzr33saucy0.144 is built against mir 0.0.6bzr831saucy0 , but 0.0.6bzr832saucy0  is the latest (7 hours old)
[23:00] <thomi> robert_ancell: I'll have to ask about that
[23:01] <racarr> kdub_: That was in fact the first hang :) I may have a seperate input hang, or perhaps yours is related and the client bit just appears to solve it
[23:01] <racarr> in the key hndling tests, there is  race between the InputRegistrar in the test fixture saying "Surface ready for input"
[23:01] <kdub_> right
[23:01] <racarr> which happens right after the ms::Surce being creted
[23:01] <racarr> and the
[23:01] <racarr> surface actually receiving
[23:01] <racarr> keybord focus
[23:02] <racarr> which happens after the msh::Surface has been created later in the shell
[23:02] <racarr> so key events are being dropped on
[23:02] <racarr> the server side
[23:02] <racarr> Ill change the test fixture to ...do something better
[23:03] <robert_ancell> RAOF, thomi, are you able to test the system-compositor-testing PPA? I need some confirmation before I can announce it fixed
[23:04] <RAOF> Looks like it *should* work from my end, but I get terrible bandwidth from the archive. thomi, can you pull from launchpad at > 30kbsec?
[23:05]  * RAOF is testing, but it'll take a while to verify.
[23:07] <robert_ancell> RAOF, thanks
[23:10] <kdub_> racarr, i have a branch that pulls the pipe based cross ipc synchronization out of some of the integration tests that fixes that test fixture input race
[23:10] <kdub_> just not sure if we want to make that the way all our tests with fork()'s in them have sync yet :)
[23:18] <thomi> RAOF: I'm on mobile broadband until this afternoon :(
[23:19] <RAOF> We win the bandwidth award!
[23:21]  * RAOF has noticed people doing what appears to be feeding fibre into the pits in the next street. C'mon NBN. Rollout here!
[23:22] <racarr> kdub_: I think I have fixed it in the server side
[23:23] <racarr> the notification "its ok to inject input" is now done right before returning the SurfaceId from the_frontend_shell
[23:23] <racarr> and it's all fine
[23:35] <jono_> olli, hey
[23:35] <jono_> is the PPA fixed now?
[23:35] <jono_> ahhh RAOF, are you on the PPA issue?
[23:36] <RAOF> jono_: Yes.
[23:36] <jono_> RAOF cool, when it is resolved can you ping me, I will be afk for a bit and then I can move forward with a post I was going to make
[23:36] <jono_> thnaks
[23:36] <RAOF> Well, robert_ancell queued the rebuilds. I'm checking that it works now, hampered by my 30kb/sec bandwidth to Launchpad.
[23:36] <jono_> thanks
[23:36] <jono_> 30kb/sec
[23:36] <jono_> wow
[23:36] <jono_> raging
[23:37] <robert_ancell> jono_, if you're using the PPA, please update and check
[23:37] <robert_ancell> jono_, I think it works, I just need confirmation
[23:37] <jono_> robert_ancell, I removed the PPA when I couldn't boot earlier ;-)
[23:37] <robert_ancell> jono_, :(
[23:37] <jono_> it turned out that X was removed
[23:37] <robert_ancell> jono_, you did a dist-upgrade without checking?
[23:37] <jono_> when I installed xorg everything worked again
[23:38] <jono_> robert_ancell, indeed, I got lazy with everything working so reliably
[23:38] <jono_> I won't make that mistake again :-)
[23:38] <robert_ancell> jono_, yeah, I've been burned by cases like that before
[23:38] <jono_> ok gotta go and work out
[23:38] <jono_> trying to get my fat ass in shape :-)
[23:38] <robert_ancell> We really need a "are you really really sure" message if ubuntu-desktop is marked for uninstallation - that would stop these cases
[23:40] <RAOF> Hm. Has my scheduler died again?
[23:43] <bschaefer> yay the mir ppa i working again
[23:43] <bschaefer> s/i/is
[23:45] <RAOF> bschaefer: The system-compositor-testing PPA?
[23:45] <bschaefer> RAOF, yup
[23:46] <RAOF> jono_: ^^ Looks like it works again :)
[23:46]  * RAOF 's laptop is still in the process of verifying that.