[00:00] <RAOF> sturmflut: You can install the mesa packages to ~/.local and it's entirely safe (you then need to export LD_LIBRARY_PATH=$HOME/.local/lib to run things)
[00:02] <sturmflut> thomi, RAOF: Okay, thanks. I think I'll go to sleep for today (it's 1 am here in europe) and if the packages are not ready for my next try I'll look into building my own Mesa
[00:04] <thomi> sturmflut: unless something goes very wrong they should be there for your morning
[00:04] <sturmflut> New day, new Mesa
[00:13] <sturmflut> thomi: Looks like mesa-9.1~rc2-0ubuntu0+mir2-jenkins18 failed on amd64 and i386, or am I reading the results wrong?
[00:13] <robert_ancell> cgoldberg, nice, thanks!
[00:14] <thomi> sturmflut: yes, it seems it can't find mir_client_library.h
[00:14] <thomi> I wonder if that file has moved recently
[00:15] <robert_ancell> thomi, it has moved to <mir_toolkit/mir_client_library.h>
[00:15] <thomi> robert_ancell: hmm, then it looks like the mesa source hasn't been updated?
[00:16] <robert_ancell> thomi, probably likely
[00:16] <thomi> dri/src/egl/drivers/dri2/egl_dri2.h line 69
[00:17] <thomi> robert_ancell: who's the best person to fix that in mesa?
[00:17] <robert_ancell> thomi, I think RAOF or alf?
[00:17]  * thomi looks pointedly at RAOF
[00:25] <thomi> hmmm, ok, so there's some odd setup on our jenkins machine - we don't appear to be pulling down new mesa sources at all.... unless it's hidden away in a cron job somewhere
[00:35] <RAOF> thomi: I *did* test-build the mesa changes locally :)
[00:36] <thomi> RAOF: yeah, there's something really funky happening here :-/
[00:37] <thomi> it looks like someone had some fun getting around the fact that the jenkins server can't access freedesktop.org :)
[00:39] <RAOF> It doesn't need to access freedesktop.org? Just github.
[00:40] <thomi> RAOF: http://www.mesa3d.org/repository.html lists the mesa repository as git://anongit.freedesktop.org/git/mesa/mesa - is that innacurate?
[00:40] <RAOF> No, that's accurate. But that's not where the branches for Mir are.
[00:41] <RAOF> Because I don't have commit access there :)
[00:41] <RAOF> thomi: You're looking for https://github.com/RAOF/mesa - mir-ppa and mir-ppa-quantal branches.
[00:46] <thomi> RAOF: is that mirrored on launchpad at all?
[00:47] <RAOF> thomi: No
[00:48] <RAOF> thomi: Because it can't, because you can't import not HEAD branches.
[00:48] <thomi> oh :(
[00:49] <RAOF> It'd apparently be a couple of weeks work to fix bzr-git enough so that it worked, but we don't invest in bzr-git anymore :(
[00:49] <thomi> yeah :(
[00:50] <thomi> I'm looking at building a source package manually and dputing that to the PPA for today,a nd I'll find out what the story is here
[01:07] <kdub> hey duflu, could you give https://code.launchpad.net/~mir-team/mir/consolidate-crossbuild-scripts/+merge/154762 another look?
[01:08] <duflu> kdub: Will do, today
[01:08]  * duflu goes to get coffee
[01:08] <kdub> duflu, thanks
[01:44] <sturmflut> RAOF: I'll wait until the mesa packages are updated in the PPA, I built Mesa from your github repository branch but after setting LD_LIBRARY_PATH i get "symbol lookup error: /usr/lib/x86_64-linux-gnu/libGLESv2.so.2: undefined symbol: _glapi_tls_Dispatch" upon running anything
[01:45] <RAOF> sturmflut: That suggests that you either haven't installed it into the right path, or you haven't built it with the right options. Mesa has approximately 3 hojilion build options, so that's not hard. :/
[01:45] <sturmflut> Hooray
[01:45] <sturmflut> I foolishly thought I could get away with ./configure --prefix=/opt/mesa --with-egl-platforms=mir
[01:48] <sturmflut> RAOF: Okay, I forgot --enable-gles2
[01:52] <RAOF> You may wish to add --with-dri-drivers=i965 --with-gallium-drivers= (if you've got intel) or --with-dri-drivers= --with-gallium-drivers=r600 (or r300, or nouveau, if you've got one of those)
[01:53] <RAOF> For reference, my most recent build:
[01:53] <RAOF>  PKG_CONFIG_PATH=$HOME/.local/lib/pkgconfig ./autogen.sh --prefix=$HOME/.local/ --enable-gles1 --enable-gles2 --with-dri-drivers=i965 --with-gallium-drivers=swrast --enable-shared-glapi --enable-glx-tls --with-egl-platforms=drm,mir,x11
[02:01] <sturmflut> RAOF: Thanks, it is finally working again!
[02:02] <RAOF> Sorry for having it broken for so long. I'm going to break it again soon; hopefully not for as long :)
[02:06] <sturmflut> At least now I can confirm that glmark2 works on Mir
[02:11] <duflu> robert_ancell: Seems I'm not getting new Mir bug mail now... ?
[04:01] <duflu> RAOF: Much badness :(  https://bugs.launchpad.net/mir/+bug/1161196
[04:03] <RAOF> duflu: PPA skew. The latest mesa isn't built in there. If you build from github you'll get a working GL.
[04:04] <RAOF> Man, we really need eye-tracking-based focus detection.
[04:04] <duflu> RAOF: Umm, kay. What are the options for not having to build Mesa from source? The old rocket-scientists PPA worked
[04:05] <RAOF> The old rocket-scientists PPA won't work now; racarr's EGL changes landed, which were incompatible with the previous Mir EGL platform.
[04:05] <duflu> RAOF: OK, so same question :)
[04:06] <RAOF> duflu: Options include: having *me* build from source for you, or debuilding out of the mir-ppa branch on github; that'll get you packages you can install.
[04:06] <duflu> RAOF: Ah, OK. debuild is less painful
[04:06] <duflu> RAOF: So what do we expect the public to do if the public PPA no longer works?
[04:07] <RAOF> We expect the public PPA to work.
[04:07] <RAOF> The fact that it currently doesn't is (a) a bug, and (b) transitory.
[04:07] <RAOF> thomi's working on restoring the mesa autobuild, which silently broke.
[04:08] <duflu> RAOF: Sweet, ta. I will work around it till after Easter
[04:09] <RAOF> Actually, I can help there - I'll just upload to the PPA. We don't have to wait for autolanding.
[04:11] <duflu> RAOF: How goes Mesa upstreaming progress?
[04:11] <RAOF> Waiting on landing the dma-buf branch.
[04:12] <RAOF> Since that changes the client ABI there's little point in landing in mesa before that.
[04:13] <RAOF> Oh, boo. That's right. Stupid jenkins versioning.
[04:22] <duflu> RAOF: It's OK. demo_client_unaccelerated suffices for me today
[04:22] <thomi> RAOF: new mesa packages are now in the PPA for i386 and amd64
[04:23] <thomi> it might be a few days before the autobuild is back up and running. In the mean time, I can manually dput new mesa packages if you need them
[04:35] <RAOF> duflu: Yeah, -jenkins19 in the PPA now should work, I think.
[04:35] <RAOF> Care to test?_
[04:36] <RAOF> GAH! Eye-tracking based focus, please!
[04:50] <duflu> RAOF: Yeah will test it soon thanks
[04:59] <racarr|lunch> https://code.launchpad.net/~robertcarr/mir/enable-inprocess-egl/+merge/155888 exists
[04:59] <racarr|lunch> Oh wow...racarr|lunch
[05:00]  * RAOF presumed racarr was just having a super-long lunch :)
[05:00] <racarr> best lunch EVER
[05:11] <duflu> RAOF: EGL works ta
[05:41] <RAOF> Time for a last burst of SWIV:ANH-driven-development.
[05:42] <racarr> ?
[05:42] <RAOF> Does anyone else see the unittests sometimes failing to complete?
[05:42] <RAOF> racarr: Star Wars IV: A New Hope.
[05:43] <racarr> ah!
[05:43] <RAOF> An excellent way to add atmospheric music to your test runs!
[05:43] <racarr> "Christopher, we see you've disabled your test runs is everything alright?
[05:43] <racarr> "
[05:44] <RAOF> "Everything's fine" :)
[05:45] <smspillaz> the next big thing:
[05:45] <smspillaz> http://scottberkun.com/2007/asshole-driven-development/
[05:45] <smspillaz> productivity up 200%!
[05:50] <RAOF> Dear C++: I wish you didn't have to recompile all the reverse-dependencies when I change a private member.
[05:50] <smspillaz> RAOF: don't expose private members in header filex kthxbye
[05:50] <smspillaz> *files
[05:50] <smspillaz> (even under private:)
[05:50] <smspillaz> :p
[05:50] <RAOF> But pimpl is such a drag!
[05:51] <RAOF> It even _sounds_ bad :)
[05:51] <smspillaz> I think that's why nobody uses it
[05:51] <smspillaz> someone though "haha, pimpl, thats a funny name"
[05:51] <smspillaz> and then the image that it puts in your head
[05:51] <smspillaz> makes you not want to use it
[05:52] <RAOF> Which is odd, because it's the _obvious_ implementation pattern for C.
[05:52] <smspillaz> RAOF: I want to invent a language that:
[05:53] <smspillaz> 1) has a very clear distinction between object and value types. Value types have public members, objects always have private members held by indirection
[05:53] <smspillaz> 2) Doesn't allow for global variables or side-effects. All changes must happen throuhg interfaces provided in either the object's constructor or the function signature
[05:54] <smspillaz> basically C++ the right way and no other way
[05:54] <smspillaz> the problem is that the "right way" is a fluid concept
[05:54] <duflu> Funnily enough, pimpl is widely used in C APIs. Except it's not called pimpl, it's just called good API design
[05:54] <RAOF> Exactly my point :)
[05:54] <smspillaz> also it should allow you to implement an interface and delegate that entire interface to a held object
[05:55] <smspillaz> so that composition is not a total pain to write
[05:55] <RAOF> smspillaz: The latter constraint sounds like you're secretly after a functional language :)
[05:55] <duflu> smspillaz: You're asking for Go, right?
[05:55] <smspillaz> duflu: kinda
[05:55] <smspillaz> I don't really like the "you implement an interface implicitly" thing in Go
[05:55] <duflu> smspillaz: Or Lisp for a purely functional language for doing your head in
[05:56]  * RAOF needs to prod #debian-cli to upload F# to experimental
[05:56] <smspillaz> you should be able to say "I am implementing this interface, but I want to delegate my implementation to this object"
[05:58]  * RAOF isn't sure how useful that would really be
[05:59] <smspillaz> RAOF: incredibly useful
[05:59] <duflu> smspillaz: I've been thinking recently that maybe the problem is that an "interface" is too coarse. Maybe you should be able to delegate interface methods
[05:59] <smspillaz> duflu: right, that would be the idea
[06:00] <smspillaz> so if you had a Interface { public: virtual ~Interface () {} virtual void bar () = 0; virtual void baz = 0; };
[06:00] <duflu> smspillaz: Which you can do in C and C++. Just not as part of the primary syntax
[06:01] <smspillaz> duflu: right, you have to use function pointers to do it
[06:01] <RAOF> That sounds to me like syntactic sugar for something that's already pretty sweet.
[06:01] <smspillaz> and then an Object : public Interface { public: virtual void bar (); virtual void baz (); }
[06:01] <smspillaz> And then a MultipleObjectsInConcept : public Interface { private Object o; }
[06:01]  * duflu goes off to try do work instead of finding more bugs in Unity and Mir
[06:02] <smspillaz> It would be nice to have something in the language that said - "Every function that I say I provide in Interface should be routed directly to my member Object"
[06:02] <smspillaz> and then you can override the interface partially for where you needed to customize
[06:02] <smspillaz> rather than having to implement every single method, then call the method from Object
[06:03] <RAOF> smspillaz: But that's like three lines per method in the interface, including whitespace. I'm not sure that it's particularly onerous.
[06:03] <smspillaz> RAOF: its just more typing that doesn't need to happen really
[06:04] <smspillaz> and then every time you add a new method to that interface
[06:04] <smspillaz> you have interface sensitivity, and all the object that were just implementing it by delegating to a member have to go implement that method
[06:04] <duflu> Whoa... Maclisp existed a decade or two before the Mac ;)
[06:05] <smspillaz> RAOF: my ideal language would also support templates, but reduce the amont of code generation by making it so that template members had to conform to a statically determined interface, and then for shifting points around, the entire thing was treated as void * in the underlying code
[06:06] <smspillaz> so you could generate the code for std::list once (instead of per-type)
[06:06] <smspillaz> and then if the template needed to call methods on the objects, you generate the code once per interface and not once per derived type
[06:06] <RAOF> So, C# generics then.
[06:06] <smspillaz> yes
[06:06] <duflu> smspillaz: Yes I invented such an STL a few years ago. But then found prior art documented in Dr Dobbs magazine too
[06:06] <smspillaz> I think what I want
[06:06] <smspillaz> is Go#
[06:07] <smspillaz> duflu: ah cool. Link ?
[06:07] <duflu> smspillaz: Not handy
[06:07] <RAOF> I'm going to work through "Statistics for programmers" in F# once everything's landed for that to actually happen. I suspect it might match many of your desires. I'll tell you how it goes. :)
[06:09] <duflu> smspillaz: Though I do have a working re-implementation (not owned by IBM), I'm not willing to share that yet
[06:11] <smspillaz> duflu: this is the point where you quit your job and make lots of money :p
[06:11] <duflu> smspillaz: No that's a different project, which for legal and financial reasons I have not touched in ~2 years
[06:11] <smspillaz> I figured it was something like that
[06:12] <duflu> I know! Let's make an app for the braindead. Those make squillions!
[06:13] <smspillaz> duflu: I'm always disappointed by the market
[06:14] <duflu> Bah, marketing is about understanding people. Not what is arguably right...
[06:14] <smspillaz> the people who come up with solutions to trap and collect plastic in the oceans get less attention than people who make apps
[06:14] <smspillaz> duflu: I watched the interview on 7:30 last night
[06:14] <smspillaz> I loved the bit where he was like "I had this idea ... so I hired a bunch of really smart people"
[06:14] <smspillaz> and the headline is
[06:14] <smspillaz> "PERSON MAKES LOTS OF MONEY"
[06:15] <duflu> Heh, I'm not talking about one particular person. But the repeating theme...
[06:15] <smspillaz> yeah
[06:16] <smspillaz> duflu: I was tempted to go into app development after I left canonical but I couldn't bear the idea of the fact that its a seemingly-luck based get-rich-quick scheme
[06:17] <duflu> Yeah, there's a lot of luck. But you'll always increase your luck with more skill too
[06:17] <smspillaz> hmmm
[06:17] <smspillaz> nux must kick something that the nouveau driver doesn't like
[06:18] <duflu> The GPU. nouveau doesn't like those
[06:18] <smspillaz> I always get a little frightened when I see them rewrite it once every few months
[06:31] <duflu> smspillaz: Any more nouveau complaints, the maintainer just logged on to ubuntu-desktop ;)
[06:32] <smspillaz> I'm sure they've heard enough alread :p
[06:32] <smspillaz> *alrady
[06:32] <smspillaz> *already
[06:32] <smspillaz> me english good
[07:18] <robert_ancell> hikiko, welcome!
[07:18] <hikiko> hi :)
[07:18] <hikiko> hi robert_ancell
[08:00] <robert_ancell> alf_, are you familiar with pkg-config? (in relation to the changes for glmark2)
[08:03] <alf_> robert_ancell: yes, it's already being used, but I don't think that pkg-config could help us in this case, since it's not just the base include path that changed.
[08:16] <alf_> duflu: @composite-on-demand, so if I change status to Approve autolanding will fail?
[08:16] <duflu> alf_: Yeah usually. But try it anyway
[08:16] <alf_> duflu: ok, let's see...
[08:17] <duflu> alf_: Because there are "unapproved" changes
[08:39] <duflu> alf_: Frustratingly it might build the proposal and *then* tell you there are unapproved changes. Taking several hours
[08:41] <robert_ancell> alf_, it was also the mir -> mir_tookit change?
[08:45] <alf_> robert_ancell: right
[08:45] <robert_ancell> alf_, ok, thought so. I just wanted to check the pkg-config changes weren't causing any problems
[08:49] <robert_ancell> duflu, Had the /usr/include/mir-1.0 vs /usr/include/mircommon-1.0 discussion with alan_g - The main issue with the former are it makes it much harder to package (because you have to list each subset of headers per package instead of listing a directory*). Also
[08:50] <robert_ancell> * = though of course clever scripting can get around this it would be nice to avoid
[08:51] <duflu> robert_ancell: Not sure what the great hurdle will be but will assume you're right for now :) At least till I try and propose any changes
[08:51] <robert_ancell> duflu, make sure you debuild to test them
[08:51] <duflu> robert_ancell: I do. In fact, it's other people who don't debuild
[08:52] <duflu> alf_: Merged! (?)
[08:52] <duflu> That's not meant to happen though...
[08:53] <alf_> duflu: perhaps it only blocks when you resubmit a proposal?
[08:55] <duflu> robert_ancell: No one's going to answer your questions posed in bugs unless they have a bug comment subscription ;)
[08:55] <duflu> So it's prolly just me
[08:56] <robert_ancell> duflu, meh, I don't think there's any real supporters for it anyway - just propose a branch and see if people complain
[08:56] <duflu> robert_ancell: The danger with this one is that tvoss or alan_g might have a reason for keeping it
[08:56] <duflu> Ask them
[08:57] <tvoss> robert_ancell, supporters for what?
[08:57] <duflu> But I agree it would be nice for people to disagree with something in bug discussions before it reaches proposal
[08:57] <robert_ancell> duflu, I just talked to alan_g and he's OK with it.
[08:57] <duflu> tvoss: https://bugs.launchpad.net/bugs/1160741
[08:57] <robert_ancell> tvoss, remove binder support since it's broken and we don't have a requirement for it
[08:58] <tvoss> robert_ancell, fine with me, but check with Alan, please
[08:58] <robert_ancell> tvoss, already done
[08:58] <robert_ancell> duflu, kill it!
[08:58] <duflu> robert_ancell: In other news, on-demand rendering just landed. You can finish VT switch support
[08:59] <robert_ancell> duflu, yeah, I've already been talking with alf_ about this
[08:59] <duflu> robert_ancell: Yeah I can probably "kill it" before finishing up this evening
[09:04] <alf_> alan_g: Good morning! What do you think about the signalfd idea in reuse-run_mir? It seems it's going to be useful for proper handling of other signals too (e.g., for VT switching).
[09:10] <alan_g> alf_: there's also some boost stuff tvoss used in an earlier version (IIRC that didn't work in the NDK)
[09:11] <tvoss> alan_g, alf_ there is a generic signal handler in process iirc
[09:16] <alf_> alan_g: tvoss: even better then
[09:21] <alan_g> alf_: are you happy with https://code.launchpad.net/~alan-griffiths/mir/improved-MessageProcessorReport/+merge/155746
[09:22] <alf_> alan_g: I missed the update, checking...
[09:29] <alf_> alan_g: ok
[09:29] <alan_g> alf_: ta
[09:37] <tvoss> katie, ping
[09:39] <duflu> alan_g, tvoss: How sure are we that "binder" is not required/used on Android?
[09:39] <alan_g> duflu: it worked with the NDK, but we've dropped support for that
[09:39] <duflu> Righto
[09:40] <alan_g> We have version control if we ever want it vack
[09:40] <alan_g> *back
[09:40]  * alan_g doesn't want to think about libhybris support for binder
[09:41] <alf_> duflu: can you still reproduce lp #1123824?
[09:41] <duflu> alf_: Not sure. Twas only reliable on Nexus 7 and I haven't had time or luck with anything on Nexus recently
[09:42] <duflu> Assume incomplete if you like
[09:44] <alf_> duflu: I will try to reproduce locally, and mark as incomplete if I don't manage to
[09:44] <katie> tvoss pong
[09:45] <duflu> alf_: If you're in the mood for fixing failing tests, there are a few bugs relating to failures when built with clang :)
[09:46] <alf_> duflu: I want a change of pace for today... I will focus on bug fixing, so I will probably take a look.
[09:53] <duflu> OK, that's enough
[09:53]  * duflu -> supermarket, Easter
[11:33] <alan_g> alf_:Are you happy with this version? https://code.launchpad.net/~alan-griffiths/mir/reuse-run_mir/+merge/155196
[11:39] <alf_> alan_g: Isn't there still the possibility of a deadlock? For example, if stop() is called from the signal handler (from the same thread as run()) while run() isn't yet waiting on the condition variable.
[11:40]  * alan_g checks
[11:42] <alan_g> alf_: AFAICS exit will be true when run tests it.
[11:43] <alan_g> alf_: sorry just understood what you meant
[11:54] <tvoss|lunch> mpt, katie, nothing to sync on my side
[11:55] <katie> tvoss|lunch, mpt, nothing from here either
[12:02] <mpt> Rheet!
[14:00] <alan_g> alf_:Are you happy with this version? https://code.launchpad.net/~alan-griffiths/mir/reuse-run_mir/+merge/155196
[14:00] <racarr> Morning
[14:01] <alf_> alan_g: looking
[14:05] <alan_g> racarr: morning
[14:22] <alf_> alan_g: I am happier (although there still is a "hidden" thread that dispatches the signals). Let's see how well this way serves us for handling VT changes, and reevaluate then.
[14:22] <racarr> alan_g: Did you see: https://code.launchpad.net/~robertcarr/mir/enable-inprocess-egl/+merge/155888
[14:22] <alan_g> alf_: you can't avoid a self-race without using two threads
[14:23] <racarr> I have a feeling the continuous part of the part of this merge is DisplayServer::surface_factory and the move of src/shell/surfaces.h to include/...
[14:24] <alan_g> alf_: boost.Asio can also hook into signals - but again there's a "hidden" thread
[14:25] <alan_g> racarr: I don't spend time second guessing WIP
[14:25] <racarr> ok :)
[14:25] <tvoss> kgunn, ping
[14:25]  * alan_g wonders if "continuous" is contentious
[14:26] <racarr> contentious yes
[14:26] <alan_g> racarr: want me to review?
[14:26] <racarr> alan_g: That would be good when you have time. I think it's "Done"
[14:26] <racarr> I just don't really expect it to land on the first iteration
[14:27] <racarr> because of the surface bits, etc...
[14:27] <alf_> alan_g: The point of using signalfd or boost asio + signal_set (if it can manage signals without extra threads) is that everything would happen synchronously inside a thread that is already doing nothing (the main thread, currently mostly waiting on exit_cv). That is, we would move to a limited event loop structure.
[14:28] <kgunn> tvoss: pong
[14:31] <alan_g> alf_: That just seemed like more work (as it affects how DisplayServer::run()/stop() operate).
[14:33] <alan_g> tvoss: will you have time to chat about edge-type this afternoon?
[14:33] <tvoss> alan_g, in ~30 minutes for max 30 minutes
[14:34] <alan_g> tvoss: I hope it won't take that long. ;)
[14:35] <tvoss> alan_g, cool :)
[14:36] <alan_g> alf_: are you happy to approve and revisit later?
[14:36] <alf_> alan_g: yes
[14:36] <alf_> alan_g: although later may be sooner than you think :)
[14:36]  * alan_g thinks "after Easter"
[14:37] <alf_> alan_g: No easter for me yet, so for me maybe even sooner ;)
[14:37] <racarr> I heard from a homeless man that they cancelled easter.
[14:37] <racarr> Not sure where he got his info.
[14:38] <alan_g> alf_: I'm around tomorrow - swapped it for the following Friday
[14:40] <racarr> investigating building input stack in clang so receive-input-in-clients can pass continuous integration
[14:42] <alf_> alan_g: I doubt I will have reached a conclusion by tomorrow. I still need to investigate how VT switching behaves exactly, and what we need to do (pause compositor, give up). There is also the complication that VT switching exists only on GBM, so we need to handle the difference between the platforms elegantly. One idea is to make e.g. SIGUSR1 mean pause()/play() regardless of the platform, and just connect it to VT switching on GBM.
[14:43] <alf_> alan_g: s/give up/give up drm permissions/
[14:44]  * alan_g wishes he were clever enough to understand
[14:47] <alf_> alan_g: a little background: we can tell the kernel to send us a signal when the user changes to/away from our VT. When we lose our VT we need to pause compositing, and also give up our priveleged access to the graphics device (drm) so that others can render (e.g. X11)
[14:47] <alf_> alan_g: and vice versa when we regain VT "focus"
[14:47] <alan_g> alf_: that helps. ;)
[14:48] <alan_g> alf_: I can see why you'd then want to rethink signal handling
[14:50] <racarr> alan_g: alf_: We talked yesterday in meeting (us/aus/nz) about removing MIR_DISABLE_INPUT after fixing clang build
[14:50] <racarr> seem sensible?
[14:51] <alan_g> racarr: my understanding is that we'll still need null input for the system compositing case
[14:51]  * alan_g has been wrong before
[14:52] <alf_> racarr: related question... what will it take to make the input thread not spin?
[14:52] <racarr> where does lightdm get input?
[14:52] <racarr> alf_: Is the input thread spinning again
[14:52] <racarr> which one do you mean?
[14:52] <racarr> sever or client
[14:52] <alf_> racarr: did it ever stop? :)
[14:53] <racarr> Yeah!
[14:53] <racarr> I remember...
[14:53] <racarr> *scratches head*
[14:53] <racarr> sort of
[14:53]  * alf_ rechecks to ensure he hasn't lost any episodes
[14:53] <racarr> I dunno! Ill figure out too
[14:54] <racarr> oh yay memcheck problems in receive-input too
[14:54] <racarr> going to fix those first I guess
[14:55] <alan_g> racarr: just wondering does the run_mir signature in https://code.launchpad.net/~alan-griffiths/mir/reuse-run_mir/+merge/155196 solve the same problem as the_ready_to_run_handler()?
[14:59] <alf_> racarr: reconfirmed, InputDispatcher thread is spinning on the desktop
[15:00] <racarr> alf_: Ok I will check it out soon
[15:00] <racarr> thanks :)
[15:00] <alf_> racarr: great :)
[15:00] <racarr> alf_: ready_to_run_handler needs to run after the
[15:00] <racarr> hmm
[15:01] <racarr> err alan_g ^
[15:01] <racarr> was going to say, after the server components are started
[15:01] <racarr> but maybe not really
[15:02] <alan_g> I wasn't sure either - that's why I asked
[15:03] <racarr> alan_g: I will figure out, I thought that for sure it had to run after the various components are started
[15:03] <racarr> but I think this is some piece of information I collected from a few months ago and forgot why
[15:03] <racarr> and it might not really be true now that I look...
[15:03] <racarr> shouldn't be true. just te DisplayServer:: needs to be initialized
[15:08] <kdub> good morning folks, working on the android graphics integration tests today (will drive integrating the nexus4 display)
[15:15] <alf_> racarr: do you want me to file a bug for the spinning thread so we can keep track of this better?
[15:18] <alan_g> racarr: I've done a quick pass and highlighted my main concerns. Grab me if they don't make sense.
[15:19] <alan_g> kdub: racarr  - please review https://code.launchpad.net/~alan-griffiths/mir/reuse-run_mir/+merge/155196
[15:19] <kdub> alan_g, ok
[15:20] <alan_g> status: getting bits of cleanup landed, reviewing and thinking about which work item to steal next
[15:26] <racarr> alf_: That would be great!
[15:26] <racarr> alan_g: Want to steal hardware cursor?
[15:26] <racarr> its kind of cool, self contained, I can show you the drm/gbm APIs you need
[15:27] <alan_g> racarr: sure. Let me grab a drink first.
[15:32] <racarr> alan_g|tea: Ok sounds good :)
[15:35] <alf_> racarr: lp #1161456
[15:43] <racarr> alf_: Thanks :)
[15:43] <racarr> hmm
[15:44] <racarr> the input manager from the testing server configuration in test_client_input.cpp
[15:44] <racarr> is leaking...
[15:44] <alan_g> racarr: what's best? Hangout? email with links and chat?
[15:45] <racarr> alan_g: For cursor? Either way it's pretty simple. probably easiest is just jumping on a hangout quickly and I can quickly take you through what is there/what needs to happen
[15:46] <alan_g> racarr: let's do that then
[15:46] <racarr> ok starting a hangout
[16:06] <racarr> literally everything is leaking in this test
[16:06] <racarr> somehow exit must not be clean
[16:09] <alan_g> racarr: does it use the test framework?
[16:09] <alan_g> racarr: does it use the mir test framework?
[16:09] <alan_g> Because the server and client processes do not exit cleanly
[16:14] <racarr> alan_g: Yes. It does...but why don't the other tests report leaks then?
[16:16] <alan_g> racarr: the parent test process should be clean, it is the server and client process that exit abruptly
[16:17] <racarr> alan_g: Parent is clean yeah. server detects the input manager and all its dependencies (i.e. the whole android input stack)
[16:17] <racarr>  as definitely lost
[16:17] <racarr> but this doesn't happen for any other tests
[16:34] <alf_> racarr: I am not sure if/how it is related, but I currently trying to debug why the server doesn't shut down properly after a client has connected (and disconnected). The use count of our mg::Display shared_ptr<> is larger than expected at the end and thus our display it's not destroyed properly.
[16:35] <alf_> racarr: I am still investigating why we lose (or rather don't lose) shared_ptr references
[16:40] <racarr> alf_: Ah...strange
[16:40] <racarr> no ideas from top of my head
[16:42] <alf_> racarr: just mentioned it in case it's somehow related to your issues and might help you with debugging
[16:42] <alf_> racarr: debugging = figuring out what's going on
[16:44] <racarr> thanks
[16:53] <alan_g> alf_: that sounds like a circular dependency. :(
[17:00] <alf_> alan_g: Yes. An interesting clue that it only happens after at least one client has connected (and possibly disconnected, doesn't matter), never before.
[17:07] <cecilpierce> /part
[17:16] <alf_> alan_g: racarr: kdub: enjoy your holidays, talk to you next week (well, except Alan)!
[17:17] <kdub> you too alf_ !
[17:22] <racarr> Bye alf
[17:22] <racarr> enjoy :)
[17:23] <alan_g> alf_: see you tomorrow!
[17:23] <alf_> alan_g: :)
[18:29] <racarr> "Why is "MirEventDelegate const *event_handler" a separate parameter and not a member of MirSurfaceParameters?" - Alan on receive-input-in-clients
[18:29] <racarr> anyone have any opinions?
[18:29] <racarr> My thought is that MirSurfaceParameters are surface creation parameters, whereas the event delegate is more something attached to a created surface
[18:29] <racarr> ...but thats really only kind of in terms of the server/client interaction
[19:05] <racarr> not convinced that fsync works correctly under valgrind
[20:45] <sturmflut> I finally got glmark2 running on Mir and took a short video: http://www.youtube.com/watch?v=Kjb8a8ISKWY
[20:45] <sturmflut> Could be useful for marketing purposes


[07:41] <Guest71509> Hello! Anybody speak Russian?
[07:45] <xubuntu335> Hello! Anybody speak Russian?
[07:46] <xubuntu335> I have a problem with Xubuntu 12 - with the panel moowing
[07:46] <xubuntu335> anybody can help me? may be in Russian
[07:48] <xubuntu335> есть тут русские?
[07:52] <micahg> !ru | xubuntu335
[08:27] <knome> updated http://xubuntu.org/irc/ with a paragraph on languages
[10:56] <thomas____> Hello everyone, I'm not sure if this is the right place to post suggestions
[10:56] <thomas____> but here goes, I hope the devs see this: https://lists.ubuntu.com/archives/xubuntu-users/2012-April/003593.html
[10:57] <thomas____> and also the fact that libreoffice in xubuntu needs to install libreoffice-gtk with it.
[10:58] <thomas____> thanks for your time and efforts
[11:33] <ochosi> knome: ping
[11:34] <ochosi> knome: mkay, anyway, i think i'll go with this look for selected items. i prefer subtle to the single-shadow suggestion of yours: http://www.zimagez.com/zimage/screenshot-04232012-013400pm.php
[11:35] <ochosi> knome: the focus is there because of the label-box anyway and the font is #fff instead of #eee, also: the label isn't ellipsized when selected, so i think enough highlighting for the currently selected item
[11:55] <ochosi> : knome let me know if you have serious concerns, otherwise i'll push this to git
[13:12] <ochosi> bbl
[13:38] <knome> ochosi, worksforme
[14:06] <ochosi> ok, i'll push it then
[14:07] <knome> quantal quetzal
[14:07] <knome> if you didn't hear already
[14:08] <ochosi> ?
[14:08] <knome> 12.10
[14:08] <ochosi> what?
[14:08] <ochosi> seriously?
[14:08] <knome> yes
[14:08] <knome> http://www.markshuttleworth.com/archives/1121
[14:09] <ochosi> woah :)
[14:09] <ochosi> hard to believe
[14:09] <knome> On the cloud front, the new virtualized network madness called Quantum will make its appearance.
[14:09] <knome> probably pretty much explains the article
[14:10] <ochosi> mmh, i guess
[14:10] <ochosi> whoever manages the g+ group/page seems pretty excited about the desktop tweaks
[14:10] <knome> heh :)
[14:11] <knome> see http://open.knome.fi/2012/04/23/call-for-feedback-on-the-wordpress-plugins/, especially the comment :)
[14:15] <ablomen> knome, are you interested in (javascript) syntax enhancements?
[14:16] <knome> ablomen, well any feedback is welcome
[14:16] <knome> for me personally the most important thing is that the plugins work :)
[14:16] <ochosi> knome: ah, nice comment :)
[14:17] <ochosi> knome: tell him that if they want to use the plugin, they have to put up weekly interactive images of xubuntu/xfce ;)
[14:17] <knome> ochosi, hah :P
[14:23] <ablomen> knome, well just a few optimizations here and there, nothing major
[14:23] <knome> ablomen, i'd love to hear those suggestions :)
[14:30] <ablomen> knome, i'v sent you a patch
[22:25] <knome> i'm off for today
[22:25] <knome> see you later
[22:53] <pleia2> knome: after some more careful reading of the trademark policy, I'm convinced we fall under the "Community advocacy" use of the xubuntu trademark
[22:54] <pleia2> so for -Q I think we move forward with xubuntu merchandise (I'll be sure to include big signs declaring "we don't make money from this and we aren't affiliated with the company making this product " ie non-commercial)
[22:54] <pleia2> er, -Quantal :)
[23:40] <pleia2> oh, and I'll work on some new screenshots for -p


[00:54] <FurretUber> Hi, did someone faced something like bug 1963600? I'm getting consistently on upgrade
[00:54] <FurretUber> I've tested with Lubuntu, and the upgrade worked correctly. However, with Xubuntu, I got 100% failure so far, going from Focal to Jammy
[07:05] <JackFrost> Does anyone care about the 'daily build' docs I upload?
[10:10] <FurretUber> I didn't, because I didn't know it existed at all. Now, I may read it :)
[19:06] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: orage 4.16.0 released @ http://www.mail-archive.com/xfce-announce@xfce.org/msg00657.html


[01:30] <studio-user434> Hello !
[16:02] <Script_Rx> Hey everyone! I have a quick question if anybody has had a similar issue. I have an HP Spectre x360 touchscreen laptop I have installed Ubuntu Studio on and I am having issues clicking on things using the touchscreen. My question is, is there anything I can do to make my OS more tablet style friendly?
[16:04] <ErichEickmeyer> Script_Rx: Ubuntu Studio comes with Xfce as a desktop environment, which is not very touchscreen friendly, nor is it designed to be. GNOME Shell or KDE's Plasma would be much more touchscreen friendly, with GNOME Shell being ready for touchscreens out-of-the-box. ...
[16:06] <ErichEickmeyer> I'd give you instructions on how to install that, but my resources are limited right now. Someone in #ubuntu might be able to get you going with that since GNOME Shell is the default desktop environment for Ubuntu.
[16:07] <Script_Rx> That answers my question perfectly. thank you! I have used UbuntuStudio for a while now and just havnt looked into what would work. I can install it. Thank you very much!!
[16:07] <ErichEickmeyer> You bet!
[16:07] <ErichEickmeyer> :)
[21:45] <studio-user974> hi
[21:46] <studio-user974> hi
[21:46] <studio-user974> can anybody hack my computer hu?¿


[00:59] <MaynardWaters> I have an asus eeepc very low power net book
[01:00] <MaynardWaters> I can log in and either get hydrogen playing or sometimes recordings through my tascam us-122
[01:00] <MaynardWaters> if I don't start hydrogen I can use flashplayer in a web brouser
[01:00] <MaynardWaters> I'd like to push it further and get mixxx going...
[01:00] <MaynardWaters> i think the graphics are the limiting factor
[01:01] <Sakrecoer> MaynardWaters: you don't need flashplayer for mixxx
[01:02] <Sakrecoer> you can use jack for both hydrogene and mix
[01:03] <MaynardWaters> any suggestions on other ways to use this tiny machine for interesting music ?
[01:03] <MaynardWaters> have you ever used rosegarden
[01:04] <Sakrecoer> no i havn't would you recomend it?
[01:05] <MaynardWaters> yea, if you are just trying to sequence
[01:05] <MaynardWaters> it works with midi tracks
[01:05] <MaynardWaters> so I've tried finding free midi covers online
[01:06] <MaynardWaters> but I haven't quite got the sound fonts figured out yet
[01:06] <Sakrecoer> well... you can assign midi data to pretty much any sound generator :)
[01:07] <Sakrecoer> i have done that too a couple of times :)
[01:07] <Sakrecoer> but i am not so much into covers...
[01:08] <Sakrecoer> actualy only one time recorded... a david bowie cover :D 'let's dance' ... not so free maybe oops
[01:10] <Sakrecoer> i used synth for everything, removed alot of sysex data but let the notes... anyways, you wont get original solo feel with midi... hard part is drum... and in that sens hydrogene is a goldmine.
[01:11] <MaynardWaters> why oops?
[01:11] <Sakrecoer> sorry... i mean, i cite a song i've made, which is not having the freedom it should.
[01:11] <MaynardWaters> sometimes hygrogen loses the pitchshift function at the bottom on me :(
[01:12] <MaynardWaters> did you post it somewhere or play it live for people?
[01:13] <Sakrecoer> i think i have it online...
[01:13] <MaynardWaters> give him props in the posting?
[01:14] <Sakrecoer> yeah... but undercover, for Mr Bowie, not for google <3
[01:14] <Sakrecoer> http://sakrecoer.com/reset/log/xmas-bowie/
[02:56] <caodepalha> hi everyone! is it advisable to change the settings in the cli to allow real time privilieges to jack? anyone knows about this? thanks
[03:00] <cfhowlett> caodepalha, with realtime kernel in 12.04,  I don't think it's necessary.  If no response here, ask #opensourcemusicians
[03:02] <caodepalha> ok thanks alot
[03:12] <holstein> caodepalha: you can look in the messages window and see if you are getting realtime privs
[03:12] <caodepalha> where can i do that?
[03:12] <holstein> you shouldnt have to change any settings
[03:12] <holstein> caodepalha: the messages window
[03:13] <caodepalha> so you say that in ubuntustudio that is not necessary?
[03:13] <holstein> caodepalha: correct.. out of the box, ubuntustudio should be setup as it needs to be
[03:13] <holstein> caodepalha: we dont ship a realtime kernel.. its a lowlatency kernel
[03:13] <holstein> you may or may not need/want to tweak further
[03:13] <cfhowlett> holstein, d'oh!  that's what I meant to say.
[03:14] <holstein> cfhowlett: i figured you meant "low latency".. its a type of realtime kernel, i suppose :)
[03:14] <caodepalha> ok! its not as if I'm experiencing problem of any sort. I was just having a look at the ardour manual where it suggest to do so
[03:15] <holstein> caodepalha: if it ain broke
[03:15] <holstein> aint*
[03:15] <cfhowlett> :0
[03:16] <caodepalha> if it aint broke dont fix it
[03:16] <cfhowlett> New Cool Blue UbuntuStudio wallpaper I worked up > http://ubuntuone.com/14PqUXQMhIP9yqRXxyv9AP
[03:17] <holstein> cfhowlett: nice
[03:23] <`Fibz`> needs more of an ethereal feel. like some evanescence or aurora
[03:24] <holstein> cfhowlett: you mind if its downloaded?
[03:24] <caodepalha> i agree! it's nice though
[03:25] <caodepalha> here's one of my first recording using ardour; https://soundcloud.com/caodepalha/fairground-voodoo-mix-cheap
[03:27] <cfhowlett> holstein, of course!  I got it from the archives ... twas a .blender.  I'll load it up to the spreadubuntu later.
[03:32] <holstein> `Fibz`: you can grab it and add whatever you feel it needs...
[03:32] <`Fibz`> :)
[03:44] <caodepalha> I have another question. I dunno how but my ardour is half in portuguese half in english. how can i make it full on english?
[03:46] <cfhowlett> caodepalha, you must have set you system settings to Portuguese.  Change it to English.
[03:46] <caodepalha> you mean on the log in?
[03:47] <caodepalha> I mean when i log in to ubuntu
[03:47] <cfhowlett> caodepalha, no.  I'm on xubuntu, so my set-up is a little different.  should be ubuntu > settings > language support
[03:49] <caodepalha> I'm in ubuntustudio
[03:50] <cfhowlett> caodepalha, 12.04?
[03:51] <caodepalha> yes
[03:52] <cfhowlett> caodepalha, so settings > language support > english
[03:52] <caodepalha> ok let me check! do I have to restart the shell or something?
[03:53] <cfhowlett> caodepalha, reboot and verify
[03:54] <caodepalha> back in a second. rebooting
[04:03] <caodepalha> Great! everything is in english now! thanks alot!
[04:03] <cfhowlett> caodepalha, have fun, be safe
[04:03] <caodepalha> :)
[04:22] <caodepalha> shouldn't ardour 3have option next to window on the menu?
[04:22] <caodepalha> mine doesn't
[04:24] <caodepalha> I have: session, transport, edit, region, track, view, JACK, window and help
[04:24] <caodepalha> no option
[04:24] <caodepalha> by this i mean how do i add midi controllers
[04:24] <caodepalha> ?
[04:25] <cfhowlett> caodepalha, patchage
[04:26] <caodepalha> ok its different than with ardour 2 then
[04:26] <caodepalha> laditray does it too?
[04:27] <cfhowlett> caodepalha, I don't know as I never used them, I just remember seeing that patchage handles midi
[04:28] <caodepalha> ok
[14:40] <SonikkuAmerica> I forgot whether or not Studio comes with an office suite or not. A friend of mine is going to install it and was wondering.
[14:41] <teknico> if it does not, it'll be easy enough installing one, with a net connection
[14:47] <cub> SonikkuAmerica, no there's no office suite included in the main installation. But as teknico wrote it's easy to install manually afterwards. Libre Office is popular (and what I use both at home and work)
[14:48] <SonikkuAmerica> cub: Of course. That's what he wanted to have anyway. :-)
[15:32] <MaynardWaters> Sakrecoer: I just listened to your track. Sounds rad. What all did you use to put it together?
[15:32] <Sakrecoer> hi MaynardWaters! tahnks!
[15:34] <MaynardWaters> do we have a bot which can forward messages to people when they return to this channel?
[15:34] <MaynardWaters> cfhowlett, I liked your wallpaper
[15:35] <MaynardWaters> cfhowlett one suggestion:take the center of the white fade and move it to the top of the blue or to the left
[15:35] <Sakrecoer> well i edited the midi file in muse if i remember correct, and then i put it in my mpc500 and assigned the tracks to various sound generated by my waldorf blofeld. The drums is what i am having a hard time remeber...
[15:35] <MaynardWaters> center perhaps
[15:38] <Sakrecoer> i don't think it was my machindrum... actualy maybe i did it with cubase... 2009 is the year i switched from babylon OS to ubuntustudio....
[15:40] <Sakrecoer> so it could well be... anyways the process is the same exactly with muse: you reassign the midi tracks to your own soundgenerators :)
[15:50] <MaynardWaters> Sakrecoer: mpc500 have a keyboard?
[15:51] <MaynardWaters> what is waldorf blofeld?
[15:53] <Sakrecoer> it's a hardware digital synthesizer... it's very handy for this stuff because it can playback 16 synth on different midichannels simultaneously
[15:53] <MaynardWaters> rad i imagine it to look and act similar to my mini moog
[15:53] <Sakrecoer> no, mpc500 have pads... but if you load a midi file in it, then the notes are problaby already entered :)
[15:54] <Sakrecoer> well sounds.... almost... :) it's digital and can be polyphonic
[15:54] <Sakrecoer> looks nont att all the same :)
[15:54] <Sakrecoer> its a small white and quite ugly little desktop thing :)


[04:20] <Eickmeyer> Not live yet, but definitely ready: https://help.ubuntu.com/community/UbuntuStudio/AudioHandbook/1.0
[19:26] <studio-devel668> Hello everyone
[19:27] <studio-devel668> I have just seen your announcement about your desperate need for volunteers
[19:28] <studio-devel668> And I would like to ask you what exactly are you looking for at the moment
[19:31] <tsimonq2> studio-devel668: What do you want to do? :)
[19:37] <studio-devel668> Hi tsimonq2, I actually don't really know. I never partecipated in a project like this. I can't put a lot of time in it because I am a student, but I would like to give you some help. I guess that I could use some old laptops for testing purposes, or maybe help with documentation (I am Italian BTW, maybe you could use an extra translator) or with quick tutorials (since I use some of the programs to make videos).
[20:02] <tsimonq2> studio-devel668: OK
[20:10] <Eickmeyer> studio-devel668: Hi! Welcome! It looks like you could be good to work on testing. To get started, go to https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel , sign-up for, and introduce yourself on our mailing list. If you don't already have one, open an account on launchpad.net and let us know in your intro email what it is.
[20:10] <Eickmeyer> That way we can add you to the team. :)
[20:12] <studio-devel668> OK
[20:16] <studio-devel668> Done
[20:19] <Eickmeyer> studio-devel668: Cool. Next step is to register an account on Freenode (this IRC network) with an IRC handle. You can add that handle to your launchpad account.
[20:20] <studio-devel668> OK, I have to create the Launchpad account first
[20:20] <Eickmeyer> *thumbsup*
[20:48] <studio-devel668> Launchpad account created
[20:48] <studio-devel668> I will introduce myself to the mailing list tomorrow, since it's getting late. See you soon!
[23:45] <Eickmeyer> OvenWerks: To aid with Plasma, I'm adding symbolic links to /usr/share/wallpapers pointing to our wallpapers at /usr/share/backgrounds/ubuntustudio.
[23:54] <OvenWerks> OK, I am realizing I need to call the desktop file in plasma seeds something different... in case things get turned into a meta.
[23:56] <Eickmeyer> Gotcha.


[11:54] <BluesKaj> Howdy all
[20:55] <blaze> https://i.imgur.com/7IuZhFX.jpg How do I get rid of this? Very very annoying
 Wait 1min 30s :P
 😂
 Because we do this for a living, that's why. smh...


[10:56] <zequence> cub: no hurry to update the website. We still need to do a change in the footer too
[10:57] <zequence> Canonical wanted a legal notice there, where we explain we aren't affiliated with them. Have it in a mail somewhere
[11:19] <zequence> Also, we should change the logo to the new one madeinkobaia made
[11:25] <cub> zequence: right, the same legal notice as ttoine updated on the spreadshirt site. I can push that later on this evening.
[12:28] <ttoine> zequence, I already updated the spreadshirt shop and https://ubuntustudio.org/merchandise/
[12:29] <ttoine> you can tell cub that he can use the same text for the footer. and then, we can remove the first sentence on the merchandise page
[18:32] <cub> I made the update to the web site footer and pushed the branch.