[00:28] <jono> http://www.reddit.com/r/LinuxActionShow/comments/1alqka/regarding_matt_and_the_monkey_suit_its_on_like/
[00:29] <jono> probably best to not let this guy down ^
[00:29] <jono> :-)
[00:41] <RAOF> Used by default in a non-Ubuntu distro is a ballsy call.
[01:32] <robert_ancell> Has anyone compiled qmir before?
[01:32] <robert_ancell> qmake ; make doesn't seem to do it for me
[02:09] <smspillaz> RAOF: oh cool, you got buffer age working
[02:10] <RAOF> smspillaz: Yeah. Next up: actually using it in XMir.
[02:10] <RAOF> Actually, before that is probably ‘extend __DRIbuffer to allow me to pass prime fds to dri drivers, damnit’
[02:11] <smspillaz> RAOF: I wonder how you got it to work - the DRI drivers don't really make any guaruntees about what buffer you're going to get next
[02:11] <smspillaz> its all very driver specific
[02:11] <smspillaz> some drivers with copy-back-to-front on swap, others will swap, others triple buffer
[02:12] <smspillaz> though I guess that all happens within the xserver bits
[02:12] <RAOF> *Mir* knows exactly what buffer it's going to send to the client.
[02:12] <smspillaz> yeah I figured as much
[02:12] <RAOF> Right. Each buffer the client receives has a (client-)unique id; it's reasonably easy to implement age tracking on that ;)
[02:12] <smspillaz> RAOF: how do you handle the discrepancies between the drivers though ?
[02:13] <RAOF> Which discrepancies between drivers? We exclusively pageflip, and handle n-buffering ourselves.
[02:14] <RAOF> We don't use any of the X bits; we're not using the DRI2 protocol.
[02:15] <RAOF> Nothing ever gets a SwapBuffers request, except egl/platform_mir, which we own.
[02:15] <smspillaz> RAOF: remind me - do the Xorg bits of dri2 have driver-specific things there ?
[02:16] <smspillaz> I looked into doing this in X a while ago and remembered there was some driver-specific stuff that would have made it difficult, but it was a while ago
[02:16] <RAOF> Yes - the X bit of SwapBuffers calls into the DDXes SwapBuffers function.
[02:16] <smspillaz> ah okay that makes sense
[02:17] <RAOF> I think for X you would indeed need to push this all the way down to the DDX, or _possibly_ hook into the bits generating intel swap events.
[02:17] <smspillaz> RAOF: it was a total PITA
[02:18] <RAOF> This is not an uncommon sentiment when working with X :)
[02:18] <smspillaz> yeah it was this stuff here http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/intel_dri.c#n838
[02:19] <RAOF> I tried to factor a bunch of that stuff out into the X server at one point.
[02:19] <RAOF> Because all 3 of the drivers were doing the _exact_ same thing, and they had exactly the same segfault bug.
[02:20] <smspillaz> heh
[02:20] <smspillaz> I think nouveau works a little differently
[02:20] <smspillaz> intel has the optional triple-buffer thing
[02:20] <smspillaz> nouveau didn't
[02:20] <smspillaz> I remember that much
[02:21] <RAOF> Yeah. At one point -ati and -nouveau had just copy&pasted the -intel code and run a sed over the names; it's diverged a bit from there :)
[02:21] <smspillaz> felt like it
[02:21] <smspillaz> Also I830
[02:21] <smspillaz> heh
[02:21] <smspillaz> Party like its 2002
[02:21] <racarr> smspillaz: !
[02:21] <smspillaz> racarr: hi'
[02:21] <racarr> RAOF: Just left some comments on buffer age...
[02:22] <smspillaz> no I'm not writing any code for you :p
[02:22] <racarr> Hi :)
[02:22] <racarr> thats what you say now
[02:22] <smspillaz> seriously, I'm not
[02:22] <smspillaz> :)
[02:22] <racarr> I know :)
[02:24] <smspillaz> also, you guys need to fix the privacy settings
[02:24] <smspillaz> I can't see half the merge proposals
[02:30] <racarr> wip
[02:30] <smspillaz> racarr: no, as in I click on them and I get a page that says "go away"
[02:31] <smspillaz> example: https://code.launchpad.net/~robertcarr/mir/prepare-for-inprocess-egl-clients/+merge/153889
[02:31] <smspillaz> (you'll need to log out)
[02:31] <RAOF> I _think_ it might be the merges or the branches that were set up prior to going public?
[02:31] <RAOF> It's not clear how to make them public.
[02:32] <smspillaz> RAOF: I think the lp settings are that projects are private or public, not branches
[02:32] <smspillaz> so something is broken somewhere
[02:32] <RAOF> Incorrect! lp:~raof/mir/client-side-buffer-age was a private branch.
[02:33] <RAOF> And now that it's a public branch the merge proposal is also public.
[02:33] <RAOF> Ok.
[02:33] <smspillaz> RAOF: I don't see the MP
[02:33] <smspillaz> its not public :)P
[02:33] <RAOF> https://code.launchpad.net/~raof/mir/client-side-buffer-age/+merge/151869
[02:33] <RAOF> ?
[02:33] <smspillaz> RAOF: so I can see if if you give me the link
[02:34] <smspillaz> but it doesn't turn up in +merges or +activereviews
[02:35] <RAOF> That might take a little while to propagate?
[02:35] <smspillaz> should be instant
[02:37] <racarr> I think it will be fixed once we get all the mps through
[02:41] <smspillaz> yeah
[02:42] <RAOF> racarr: Thanks for the review.
[02:47] <racarr> RAOF: Sorry its kind of scattered
[02:47] <RAOF> That's ok.
[02:47] <racarr> I am really tired...have been a little too full stream all around last 3-4 days :)
[02:47] <racarr> I thought I would try and say something though
[02:47] <racarr> and overall it makes sense :)
[02:49] <RAOF> What do you think of pulling the age() related bits into ClientBuffer; the implementation shouldn't be different between AndroidClientBuffer and GBMClientBuffer.
[02:51] <RAOF> I'm leary of mixing interface and implementation there.
[03:02] <RAOF> Woo! Android build builds!
[03:05] <tehcloud> does having an Android build mean Mir has been tainted with Java?
[03:05] <TheMuso> tehcloud: No
[03:06] <TheMuso> tehcloud: Java is only used for apps on android, I believe all the infrastructure stuff is C/++.
[03:06] <TheMuso> C/C++ even.
[03:13] <RAOF> And we're not even using that; we're using the android kernel and GLES drivers.
[03:23] <TheMuso> I know that, just clarrifying that java is only used at the app/UI level.
[03:23] <RAOF> Yeah, I presume you did, but tehcloud probably didn't :)
[03:24] <tehcloud> yeah, I'm not exactly an expert in this subject matter
[03:24] <smspillaz> TheMuso: brb, off invention "++"
[03:24] <smspillaz> its C++ with the C bits removed
[03:24] <smspillaz> oh wait that's Java, never mind
[03:25] <smspillaz> *inventing
[03:25] <TheMuso> lol
[03:25] <smspillaz> They should have called Java "++"
[03:25] <smspillaz> that would have ended up in so much hilarious confusion
[03:26] <tehcloud> in an ideal world there would be no Java
[03:26] <TheMuso> Java has its place, just like all languages.
[03:26] <TheMuso> I don't use it myself.
[03:26] <TheMuso> But can understand, accept and respect its usefulness.
[03:26] <tehcloud> that's why you think that way ;)
[03:26] <tehcloud> try using it at work
[03:27] <smspillaz> Java would be useful if we didn't have AWT
[03:33] <RAOF> Man, the ubuntu touch images don't even have rsync in them!
[03:37] <racarr> RAOF: "tsyncninja" A touch based file synchronization utility based on the popular fruit slicing mini game
[03:38] <RAOF> Hm. “make style_check” isn't really very useful, is it ☺
[03:38] <RAOF>  ~/Canonical/Mir/mir/build ⮀ make style_check 2>&1 | wc -l
[03:38] <RAOF> 1031
[03:38] <racarr> RAOF: I always grep for the files I modified
[03:39] <racarr> and just fix those
[03:39] <racarr> "always"->"on good days"
[03:51] <racarr> RAOF: I kind of like pulling the age related bits in...(just catching backscroll)
[03:51] <racarr> the mixing implementation and interface is a red flag though
[03:51] <racarr> the other red flag is the
[03:51] <racarr> implementation of the ageing semantics on the mock buffer with the expectations
[03:51] <racarr> in one of the tests
[03:51] <RAOF> Yeah, that's rather awkward.
[03:51] <racarr> which says that really there is
[03:51] <racarr> another object
[03:52] <racarr> BufferAgeTracker (complete strawman name)
[03:52] <racarr> and its an integration test
[03:52] <racarr> but...eh
[03:52] <racarr> I am not sure how strongly I feel about it
[03:52] <duflu> racarr: Orange flag at most. If there's no real testing value gained by mocking systems code then I think it's often OK to mix implementation with interface
[03:53] <racarr> Sure, orange flag :)
[03:53] <racarr> Maybe Buffer has a member
[03:54] <racarr> type BufferAge
[03:54] <RAOF> ClientBuffer could well have a public uint32_t age, yes.
[03:54] <duflu> On the other hand... being able to test code natively is preferable to mocking. And if you can do that, then you don't need to separate interface from implementation
[03:54] <racarr> RAOF: No I mean a
[03:54] <racarr> BufferAge age, and then the methods increment_age, mark_as_submitted, age()
[03:54] <racarr> etc
[03:54] <racarr> move to BufferAge definition
[03:54] <racarr> and out of the platform code
[03:55] <RAOF> Possibly. I *think* the Buffer might actually want to do something on mark_as_submitted(), though.
[03:55] <racarr> duflu: Here the interface is seperated because it actually has multiple implementations
[03:56]  * duflu stops generalizing about code he hasn't seen yet
[03:56] <racarr> RAOF: does it have to do with the age
[03:56] <racarr> duflu: Hehe. my number 1 hobby!
[03:56] <RAOF> racarr: No, not to do with age.
[03:56] <racarr> RAOF: Then I would imagine
[03:56] <duflu> Generally speaking... we should use Go.
[03:56] <racarr> buffer.submit() does that thing and
[03:56] <racarr> also calls buffer_age.mark_as_submitted()
[03:57] <RAOF> racarr: The *age* interface doesn't actually have multiple implementations, though.
[03:58] <racarr> RAOF: In what tense? Right now it does i.e. increment_age is implemented in the test, the android buffer and the gbm buffer
[03:58] <racarr> so the idea is to just move the implementation to a single shared BufferAge type
[03:58] <RAOF> racarr: In the sense that it's ever sensible to have different behaviour there.
[03:58] <racarr> mm
[03:58] <racarr> so I mean it's a concrete type
[03:58] <racarr> its just to avoid mixing implementation in to the ClientBuffer API
[03:59] <racarr> I guess there is still some :)
[03:59] <RAOF> Alternatively, ClientBuffer abstract, AgeableBuffer concrete, {GBM,Android}ClientBuffer inherits from both?
[04:00] <racarr> RAOF: Mm
[04:01] <racarr> RAOF: Anyway...I don't feel strongly enough about any of these to feel like
[04:01] <racarr> blocking on it...but maybe if you think one is a particularly good idea or europe has a good idea :)
[06:08] <RAOF> Hm, it seems that our coding style has a significant exception in the tests.
[06:17]  * duflu would prefer to call it a coding /fashion/
[06:19] <RAOF> Coding /ambiance/
[06:32] <tvoss> uRAOping
[06:32] <tvoss> RAOF, ping
[06:32] <RAOF> Yo!
[06:36] <RAOF> tvoss: What's up?
[06:37] <tvoss> RAOF, good morning :) looking at your buffer age branch, did you run it with XMir, yet?
[06:37] <RAOF> tvoss: No, haven't yet done the xmir bit.
[06:37] <tvoss> RAOF, ah, was just curious. I remember you mentioning that the buffer age stuff might help
[06:38] <RAOF> XMir is currently in a bit of flux, too; it's half way through being adjusted to lp:~raof/mir/use-dma-buf
[06:41] <tvoss> RAOF, ah cool :)
[06:41]  * tvoss is going to review racarr's branch now
[06:45] <RAOF> It should help with XMir performance though, yeah.
[06:45]  * RAOF has performance-parity third on his TODO list, under finish-buffer-age and use-dma-buf
[06:45] <RAOF> That's going to be _all manner of fun_
[06:48] <tvoss> RAOF, \o/
[08:55] <duflu> Hurray... mir just overflowed it's first page of bugs in Launchpad (75 per page) :/
[08:55] <duflu> *its
[08:57] <RAOF> A fair number of those are "fix committed", though.
[08:58] <duflu> Yeah, first comment still holds. But I wonder when the "0.0.2" release should be tagged and we move on to more meaningful milestone numbers...
[08:59] <duflu> Oh great. 0.0.2 is already marked as released, but also still active
[08:59] <duflu> That needs fixing
[09:00] <duflu> tvoss: What should our next milestone be? 0.0.3? 0.1.0?
[09:01] <duflu> Assuming 0.0.3. We can change it later...
[09:02] <RAOF> Are those milestones at all meaningful?
[09:03] <duflu> RAOF: No. I just realized....
[09:04] <duflu> RAOF: We need to fix up our branch-to-series relationships before milestones make sense
[09:04] <duflu> I'll bug Robert about it when he's online tomorrow
[09:09] <tvoss> duflu, yeah, talk to Robert or kgunn please
[09:09] <duflu> tvoss: Writing detailed email...
[09:10] <tvoss> duflu, thank you
[09:14] <alan_g> Good morning. (It is snowing!)
[09:16] <duflu> alan_g: Morning. Not sure whether to be jealous.
[09:17] <alan_g> duflu: don't be - it'll just make everything wet and cold
[09:19] <alan_g> duflu: we need to reach consensus about include (directory) names as Europe and Australia seem to think differently. Have you seen the thread on mir-devel?
[09:19] <duflu> alan_g: Keep forgetting to subscribe to that. Too many other mediums of Mir discussion. Will do so now
[09:21] <alan_g> duflu: A choice of mediums isn't bad.
[09:22] <duflu> Well, only if one is more effective than another and it's not being used
[09:26] <RAOF> alan_g: I'd be interested to hear your thoughts on the great "where to put buffer aging implementation"fest of '13 racarr & I had in backscroll, too.
[09:27]  * alan_g wonders where to find it
[09:30] <RAOF> alan_g: Ah, you don't have backscroll? Let me pastebin
[09:32] <RAOF> alan_g: http://paste2.org/p/3228842
[09:32] <alan_g> RAOF: Looking...
[09:36] <duflu> alan_g: As part of "breaking the dependency on Android input", doesn't that mean that desktop builds should not enter any *android* directories?
[09:36] <alan_g> RAOF: ...need to remind myself what the code looks like...
[09:36] <duflu> "[alan-griffiths] Input refactoring (don't depend on Android): DONE"
[09:38] <alan_g> duflu: It was porting the input stack to use std/boost instead of android equivalents.
[09:38] <duflu> alan_g: But still desktop builds enter a couple of *android* dirs?
[09:38] <alan_g> duflu: yes
[09:39] <duflu> That's a bit confusing.
[09:39] <duflu> Hmm
[09:41] <alan_g> duflu: we've adopted more android code than just the input stack
[09:42] <duflu> alan_g: Even the android input stack still seems to be required for desktop input. Is that right?
[09:42] <alan_g> duflu: we've forked the android input stack for use on all platforms
[09:43] <alan_g> duflu: and reduced its dependency on other android stuff to a bare minimum
[09:43] <duflu> Ah, OK. So there will be no escaping the 3rd party code generating all those errors/warnings that clang dislikes
[09:44] <alan_g> duflu: not without work
[09:44] <duflu> Heh
[09:48]  * RAOF heads bedwards
[10:36]  * duflu heads kitchen-wards
[10:57] <tvoss> katie, ping
[10:57] <katie> tvoss pong
[10:59] <tvoss> katie, hey, got anything to sync up?
[11:00] <katie> tvoss, a couple of things, yes.. shall we jump on a hangout?
[11:01] <tvoss> katie, sure, let me grab coffee :)
[14:23] <alan_g> alf_: ping
[14:36] <alf_> alan_g: pong
[14:36] <alan_g> alf_: do you want to do any more on render-surfaces-use-display-server or shall I set it to approved?
[14:37] <alf_> alan_g: I am ok for now, I prefer to do any additional enhancements in another MP
[14:43]  * alf_ prepares himself mentally for a review of lp:~robertcarr/mir/send-input-to-clients
[14:48]  * alan_g has just finished the mornings reviews. alf_, send-input-to-clients isn't the worst on the brain.
[14:48] <alan_g> *morning's
[14:49] <alf_> alan_g: I haven't checked in detail, I just saw the +1066 diff :)
[15:42] <kdub_> hey all, status, still up north at the gpu conference, will be back to a normal day tomorrow
[15:47] <alan_g> kdub: hope you're having fun!
[15:51] <kdub_> alan_g, thanks! picking up on some useful info, a lot of emphasis on gpu compute though
[15:52] <alan_g> kdub: that doesn't surprise me. I know a lot of folks that believe that is what GPUs are for.
[15:52] <alan_g> (That's what comes of working with investment banks.)
[16:07] <racarr> Morning
[16:10] <alf_> status: changed render-surfaces to use DisplayServer, reviewing, investigating test failure in VM CI and VM autolanding.
[16:21] <racarr> alan_g: for comments on send-input-to-clients
[16:22] <racarr> are you thinking just
[16:22] <racarr> msh::Surface implements mi::InputTarget or some such
[16:22] <racarr> or something else...
[16:22] <racarr> I thought about that but then it escaped my mind XD
[16:23] <alan_g> racarr: that sounds sensible
[16:28] <racarr> Ok :)
[16:30] <alf_> alan_g: racarr: @send-input-to-clients, in the same spirit as Alan's comment, I think that FocusSelector belongs in shell::, not in input::
[16:33] <alan_g> alf_: true
[16:37] <racarr> alf_: Yeah sounds right
[16:40] <racarr> alan_g: Lots of reinterpret_casts removed in r515 for prepare-for-inprocess-egl
[16:40] <alan_g> racarr: excellent!
[16:46] <racarr> alan_g: alf_: Do you guys need review on anything this morning before I sink in to
[16:46] <racarr> send-input-to-clients
[16:47] <alan_g> racarr: no - there were too many reviews for me to write any code
[16:48] <racarr> *whistles innocently*
[16:49] <tvoss> kdub, ping
[16:50] <alf_> racarr: no pending MPs for me, thanks!
[16:53] <racarr> Next feature branch for me btw is, clients-receive-input.
[16:53] <racarr> which is going to look like. MirSurface, takes a MirEventDelegate containing bool handle_event(...,MirEvent,...)
[16:54] <racarr> constructs an InputReceiverThread from it. InputReceiverThread uses epoll to wake when there is data on the FD and uses the InputReceiver to consume
[16:54] <racarr> pending events and hand them out to the callback
[16:54] <racarr> if anyone has any
[16:54] <racarr> thoughts/alternatives/etc
[17:37] <racarr> alan_g: I am struck trying to decide on the name of the
[17:37] <racarr> interface msh::Surface exposes to the InputManager
[17:37] <racarr> there also has to be one for msh::Session
[17:37] <racarr> input::Surface is just more trouble XD
[17:38] <alan_g> racarr: you had mi::InputTarget earlier. Changed your mind?
[17:38] <racarr> oh
[17:38] <racarr> alan_g: Well only because there are two
[17:38] <racarr> and SessionTarget reads weird
[17:39] <racarr> but really the session interface is not used as an input target (it doesn't have an FD) it's just for info
[17:39] <racarr> so mi::ApplicationInfo
[17:39] <racarr> mi::Target
[17:39] <racarr> set_input_focus_to(ApplicationInfo, target)
[17:39] <racarr> it feels redundant to write mi::InputTarget, etc.
[17:40] <alan_g> Does "Application" belong there? Or is it a more general "Session"?
[17:40] <racarr> alan_g: It's hard to say
[17:40] <racarr> we create a
[17:40] <alan_g> A little redundancy can help clarity
[17:40] <racarr> droidinput::InputApplicationHandle
[17:40] <racarr> from it
[17:42] <alan_g> Yeah, but android input stack wasn't quite our use case
[17:42] <racarr> mm
[17:42] <racarr> I think its probably closer to a session
[17:43] <alan_g> racarr: we can rename things in the input stack to bring it into line
[17:43] <racarr> set_input_focus_to(mi::SessionTarget, mi::SurfaceTarget)?
[17:43] <racarr> mm
[17:43] <alan_g> racarr: but lets do that later
[17:43] <racarr> yes aybe a good task for next week if we can land the basics of input this week
[17:43] <racarr> then clean up, (espescially down in droidinput)
[17:43] <racarr> next week once it is under end to end test
[17:44] <racarr> and ITERATE!
[17:45] <racarr> alan_g: Just realizing also...I guess msh::SingleVisibilityFocusMechanism needs to work in terms
[17:45] <alan_g> racarr: yes, and we can lose MIR_INPUT_USE_ANDROID_TYPES after that too
[17:46] <racarr> of msh::Session
[17:46] <racarr> and not mf::Surface :)
[17:46] <racarr> so it can see the SessionTarget type
[17:46] <alan_g> racarr: ack
[17:49] <racarr> ugh but there is no msh::Session anymore
[17:50] <racarr> just application session
[17:50] <racarr> which if you use that get back to the point where you cant mock session for the focus mechanism.
[17:50] <alan_g> racarr: there is, it is in the src directory
[17:50] <alan_g> racarr: sorry, you're right
[17:50] <racarr> alan_g: session not surface I got it
[17:50] <racarr> backwards too
[17:51] <alan_g> racarr: we're missing more than one interface around this area
[17:51] <racarr> mm
[17:52] <racarr> trying to find a way to proceed for this branch without tearing apart shell again aha
[17:53] <racarr> I dont like using the ApplicationSession interface for the FocusMechanism set_focus_arg because then it becomes cumbersome to mock
[17:54] <racarr> (need constructor args, etc...its weird)
[17:54] <racarr> but also don't like defining
[17:54] <racarr> hmm
[17:54] <racarr> at first I didn't like it...msh::ApplicationSession implements msh::Session implements mf::Session
[17:54] <racarr> but maybe that's really how it is.
[17:54] <racarr> default_surface for example
[17:54] <racarr> is part of
[17:55] <racarr> msh::Session
[17:55] <racarr> but not mf::Session
[17:56] <alan_g> racarr: yes, but that *ought* to be part of an interface, not just in an implementation
[18:00] <racarr> alan_g: Yes msh::Session is the interface
[18:00] <racarr> msh::ApplicationSession is the implementation
[18:00] <racarr> default_surface is introduced at msh::Session
[18:01] <alan_g> racarr: I'm sure you'll sort it all out while I take my wife out for a meal.
[18:01] <alan_g> ;)
[18:05] <racarr> alan_g: Have a good evening :)
[18:05] <racarr> ill sort it out
[18:05] <racarr> I have this suspiscion that (not for this branch)
[18:05] <racarr> but maybe really mf::Surface and mf::Sessio don't exist
[18:05] <racarr> and SessionStore::create_session and create_surface_for
[18:05] <racarr> return
[18:05] <racarr> SessionIPCPackage and SurfaceIPCPackage
[18:05] <racarr> except then how do you advance the buffer ;)
[18:06] <racarr> for now msh::Session I believe
[18:08] <alan_g|life> racarr: they exist, but they're not quite correct yet
[19:05] <racarr> This is a difficult refactoring
[19:06] <racarr> because...
[19:06] <racarr> hmm well if you introduce msh::Session inbetween mf::Session and ApplicationSession
[19:07] <racarr> the SessionManager wants to deal with things in terms of msh::Session (to say pass to the focus mechanism)
[19:07] <racarr> but has to take mf::Session as input and as output
[19:32] <racarr> mer...
[19:33] <racarr> feel stuck on a good solution. espescially one that doesn't double the diff size of this branch so breaking for lunch
[19:33] <racarr> thai should be coming any minute now...
[20:20] <racarr> if mf::SessionStore::open/close session used the same style as mf::Session open/close/get with ID.
[20:20] <racarr> then the internals (session container, focus mechanism including bridge to input) can work in terms of msh::Session (inherits mf::Session) which can implement
[20:21] <racarr> InputTarget...
[20:21] <racarr> the problem is app_container->remove_session/create_session has to take the same type (or a mapping must be maintained) as session_store open/close
[20:26] <racarr> nvm that is just weird. because the SessionMediator only accesses one instance of session
[20:26] <racarr> per instance
[20:39] <racarr> the only thing I can come up with, is
[20:39] <racarr> eeeeerrrr...no nvm
[20:39] <racarr> *facepalm*
[21:16] <CodyS> hello???
[21:16] <kgunn> robert_ancell: i swear i thot you changed this...i'm going bp crazy https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-phone
[21:16] <kgunn> can you make it mir-team drafter ^
[21:16] <kgunn> CodyS: hello
[21:17] <robert_ancell> kdub, yeah, I'm sure I changed that too..
[21:17] <CodyS> ok thanks...i wasn't sure if i was lagging too bad...
[21:17] <kgunn> robert_ancell: arrgggg....cached webpage
[21:17] <robert_ancell> no, I just updated it then
[21:17] <kgunn> nevermind (sheepishly)
[21:18] <kgunn> oh
[21:30] <kgunn> robert_ancell: got another one https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-inter-app-data-transfer
[21:30] <robert_ancell> kgunn, done
[22:09] <kdub_> racarr, for in-process-egl mp, i'm a bit hazy as to what eglNativeDisplayContainer is an interface to
[22:10] <kdub_> also hooray for android build ci!
[22:19] <robert_ancell> racarr, I'm reading alan_g|life's ML post about the use of mir_toolkit for server processes - when you use Qt in process does it need a special interface to compile against? i.e. an interface that is different to the server and the client interfaces
[23:00] <racarr> robert_ancell: I dont thinks o but some of the interfaces are shared between the server and client
[23:00] <racarr> I havent fully processed that ML discussion yet


[05:01] <Rezwan> hello MMukherjee
[05:02] <Rezwan> উবুন্টু বাংলা চ্যানেলে স্বাগতম
[05:02] <Rezwan> :)
[07:45] <MMukherjee> :o
[07:45] <MMukherjee> Rezwan: :)
[09:06] <Rezwan> MMukherjee, উবুন্টু ইউজার? :)
[09:06] <MMukherjee> Houzar mane?
[09:06] <Rezwan> "ইউজার"
[09:06] <MMukherjee> Ami ekhono ektu "fag-type" e moto acchi :p
[09:06] <MMukherjee> No bengali fonts here :c
[09:07] <Rezwan> সেটা আবার কী জিনিস?
[09:07] <Rezwan> Bangla porte parchen na?
[09:07] <Rezwan> ahhh!
[09:07] <Rezwan> MMukherjee, kun distro?
[09:07] <MMukherjee> Ami parchi
[09:07] <MMukherjee> Ubuntu 14.04.1 ;)
[09:08] <Rezwan> tahole to Bangla porte porte shomossha howar kotha na
[09:08] <Rezwan> porte*
[09:09] <MMukherjee> Hmm, sotti, kintu ektu Monitor e problem acche.
[09:09] <MMukherjee> :9
[09:09] <Rezwan> plenty of Bangla fonts get installed with Ubuntu
[09:09] <Rezwan> or maybe the problem in your IRC client
[09:10] <Rezwan> MMukherjee, browser e Bangla font kemon ashe?
[09:11] <MMukherjee> Hmm, bhalo e ase, kintu onek somaye sob bojha jaye na, ei bekar Monitor er jonno.
[09:11] <MMukherjee> Ami sob jaye ga tei Ubuntu bhabo har k'ri.
[09:12] <MMukherjee> ;)
[09:12] <Rezwan> English proten kuno shomossha hoy?
[09:12] <Rezwan> tahole buja jabe problem ta monitor e
[09:12] <MMukherjee> Server, PC teo.
[09:12] <MMukherjee> Hmm, hoi.
[09:12] <Rezwan> okay :)
[09:12] <Rezwan> monitor change kore felen tahole
[09:13] <MMukherjee> Haa, khub tara tari kinbo!
[09:13] <MMukherjee> Ei Diwali Bumper Offer e! ;)
[09:13] <Rezwan> haha good :)
[09:14] <Rezwan> apni Kolkatay thaken?
[09:17] <MMukherjee> Haa.
[09:17] <MMukherjee> Na, asole.
[09:17] <MMukherjee> Ami Chandannagar e thaki.
[09:17] <MMukherjee> Sudhu 10 years boyes amar :p
[09:17] <MMukherjee> Kintu puro Ubuntu ke bhabokar k're niye chi
[09:19] <Rezwan> MMukherjee, apnar boyosh 10?!
[09:21] <MMukherjee> Ha.
[09:21] <MMukherjee> Kono problem? :p
[09:22] <Rezwan> no problem at all :)
[09:23] <MMukherjee> ;)
[09:24] <Rezwan> MMukherjee, you have a server running Ubuntu?
[09:24] <MMukherjee> Yup
[09:24] <Rezwan> wow
[09:24] <MMukherjee> On powerkiller.no-ip.biz
[09:25] <MMukherjee> I'm hosting a IRC Server atm :p
[09:25] <Rezwan> you are the youngest person I know running an Ubuntu server!
[09:25] <MMukherjee> :o, really?!
[09:25] <Rezwan> probably :)
[09:25] <MMukherjee> You can connect to see/verify
[09:25] <Rezwan> sure.
[09:26] <MMukherjee> Join #aeclan
[09:26] <MMukherjee> It's the place.
[09:26] <Rezwan> on what server
[09:26] <MMukherjee> powerkiller.no-ip.biz
[09:26] <MMukherjee> I host a InspIRCd there.
[09:28] <Rezwan> MMukherjee, awesome :)
[09:28] <MMukherjee> :D
[09:35] <Rezwan> MMukherjee, ekhon kun class e poro? (hope I can call you "tumi" now :P )
[09:35] <MMukherjee> Ami ekhon 4 e pori.
[09:36] <Rezwan> nice
[09:37] <Rezwan> aj school bondho chilo?
[09:39] <MMukherjee> Hmm.
[09:39] <MMukherjee> Class 10 ar 11 er Oral Exam hocche.
[09:44] <MMukherjee> Eta kirohom ekta support chara ektu ektu chatroom er moto hoye gacche :p
[09:45] <Rezwan> hahaha
[09:45] <Rezwan> it works as both support and chatroom for the ubuntu users :P
[09:46] <MMukherjee> :p
[09:46] <MMukherjee> Tumi kothay thako?
[09:47] <Rezwan> ami thaki Sylhet e
[09:47] <Rezwan> Syhet chino?
[09:47] <MMukherjee> Na.
[09:47] <MMukherjee> Sudho 10 bochor boyes, ki ar hote pare.
[09:50] <Rezwan> MMukherjee, Sylhet Bangladesh er ekta shohor. google e search dile jaante parbe
[09:50] <MMukherjee> 'kk
[09:51] <Rezwan> anyway, amio Chandannagar ashole kuthay jani na! :P
[09:52] <MMukherjee> :o
[09:52] <MMukherjee> Hoogly te.
[09:52] <MMukherjee> :p
[09:54] <Rezwan> okay :)
[09:58] <Rezwan> MMukherjee, kotodin dhore Ubuntu use korcho?
[09:58] <MMukherjee> Mhm, 1-2 bochor.
[09:58] <MMukherjee> Prothom e VirtualBox e bhabo har k'rtam
[09:58] <MMukherjee> Tar por directly niye elam.
[10:01] <Rezwan> Ubuntu er agay ki use korte?
[10:02] <MMukherjee> Win. 7.
[10:04] <Rezwan> ahh
[10:05] <Rezwan> prothom kobe computer use kora shuru korle? :)
[11:28] <MMukherjee> Onek din age.
[11:28] <MMukherjee> Kicchu bochor age.
[11:29] <MMukherjee> Jokhon ami class 1 e portam
[12:40] <Rezwan> MMukherjee, tumi acho?
[12:40] <MMukherjee> Hm acchi
[12:40] <MMukherjee> Ei atheme er kag holo ;)
[12:41] <MMukherjee> Ses holo*
[12:41] <Rezwan> atheme টা কি জিনিস?
[12:41] <Rezwan> accha tumake ki name dakbo boloto? tumar dak naam ki? :P
[12:42] <Rezwan> MMukherjee
[12:43] <MMukherjee> Rizu
[12:43] <MMukherjee> Atheme ekti IRC services
[12:43] <Rezwan> IRC client?
[12:43] <MMukherjee> Freenode eta bhabohar k're.
[12:43] <MMukherjee> ChanServ Ekti IRC services' bot.
[12:44] <Rezwan> bahh
[12:44] <Rezwan> Rizu khub shundor naam. kintu eta to meyder naam! ;-P
[12:44] <MMukherjee> Na.
[12:44] <MMukherjee> Rizu mane "straight"
[12:45] <MMukherjee> Ami chele ;-@
[12:45] <Rezwan> LOL ok ok
[12:45] <Rezwan> thik ache
[12:45] <MMukherjee> :D
[12:45] <MMukherjee> AFK, ebar khai-dai ar porte jai ;)
[12:46] <MMukherjee> Ese IRC Bot er opor code k'rte h'be.
[12:46] <Rezwan> okkay :)


[12:04] <gary_poster> benji, frankban gmb, my older son lost more than a cup of blood today from a mongo nose bleed.  (On Sunday a friend of his pushed him off a trampoline and he landed on his nose, which may be related.)  I'm not sure what my schedule is yet--the bleed has stopped, but we're trying to get a dr appt for him asap.  In any case, whether it's with me or not, the people who are available for a call in a bit over an hour
[12:04] <gary_poster> should have a call
[12:06] <benji> gary_poster: will do; good luck with the nose bleed
[12:08] <gary_poster> thank you
[12:58] <gary_poster> frankban, I'm going to file a bug for the testrepository unicode issue and then you can offer your branch as a possible solution.  Have you or gmb started a juju instance or shall I?
[12:59] <gmb> gary_poster, I haven't; I'm having juju bootstrap problems after upgrading.
[12:59] <gmb> (again)
[12:59] <gary_poster> gmb, the one I mentioned yesterday, with the booleans?
[13:00] <gary_poster> I ended up removing all charms except the buildbot ones from the local repo
[13:00] <gmb> gary_poster, No, bootstrap just hangs, at least for ec2.
[13:00] <gary_poster> ugh
[13:00] <gmb> I need to actually poke it with a stick to find out what's going on.
[13:00] <gmb> s/stick/strace/
[13:00] <gary_poster> :-)
[13:00] <gary_poster> gmb, I'll see if I dupe
[13:03] <gary_poster> gmb, so, you mean, you say "juju bootstrap" and the command never exits?  If so, that's not happening for me
[13:04] <gmb> gary_poster, Yeah, that's what I mean. Hmm. I'll break out strace after a call.
[13:04] <gmb> s/a/the
[13:04] <gary_poster> ok
[13:09] <benji> gmb and frankban: the horde awaits: https://talkgadget.google.com/hangouts/extras/canonical.com/goldenhorde
[13:10] <benji> gary_poster: you probably aren't here, but you can join too if you are
[13:10] <gary_poster> thank you all.  I'll be able to attend too.  ignore the sounds of baby crying in the background
[13:10] <gary_poster> dr appt is 10:45
[13:14] <gmb> gary_poster, Firefox went bye-bye.
[13:16] <gmb> In fact  it looks like a lot have things have gone  a bit sideways...
[13:16] <gary_poster> ack gmb :-/
[13:47] <gmb> Yay, power socket.
[13:54]  * gmb -> lunch
[14:11] <benji> gary_poster: have you seen this in any of your test runs?
[14:11] <benji> **********************************************************************
[14:11] <benji> Could not communicate with subprocess
[14:11] <benji> **********************************************************************
[14:12] <gary_poster> benji I don't think so but will search through tee'd results from yesterday, one sec
[14:12] <benji> gary_poster: oops, it looks like the OOM killer got me
[14:12] <gary_poster> benji, oh :-/
[14:13] <gary_poster> benji, actually, yes
[14:13] <gary_poster> benji, twice in my run, not in yours
[14:14] <benji> hmm
[14:15] <gary_poster> benji, http://pastebin.ubuntu.com/883280/
[14:15] <gary_poster> benji, I'm making a card for that
[14:15] <gary_poster> benji, could be xvfb issue
[14:17] <gary_poster> benji, it would be very interesting to have you run list 1 locally *not* in an lxc
[14:17] <gary_poster> to see if that shows up
[14:18] <benji> gary_poster: yep
[14:18] <benji> gary_poster: I may have an opportunity to do that soonish (I might have just fixed the read-only problem (with a one-line change to a test tearDown))
[14:18] <gary_poster> go you, benji  :-)
[14:19] <benji> :)
[14:19] <gary_poster> though the read-only thing is a run list 2 issue
[14:20] <benji> gary_poster: right, I meant that once I fix this (list 1) issue, I could do a run of list 2
[14:20] <gary_poster> There was something else like that I saw yesterday that I did not put a card in for...looking through results again
[14:21] <benji> er, swap 1 and 2 above
[14:22] <gary_poster> cool :-)
[14:22] <frankban> gary_poster: should I handle the subtle differences in leases path between lucid and oneiric/precise in setuplxc? Or can I just assume the lxc is lucid?
[14:24] <gary_poster> frankban...it would be nice to handle precise because that will be what we use within a few months.  If it is not easy now, put a card in slack time for the precise version
[14:24] <gary_poster> Maybe that's the right thing to do either way; I'll leave it up to you
[14:25] <frankban> gary_poster: ok thanks
[14:25] <gary_poster> np
[14:26] <gary_poster> gmb, I hain't fergotten ya.
[14:26] <gary_poster> (that's in "random silly accent Gary made up" to be clear)
[14:26] <gary_poster> Almost ready, hopefully
[14:28] <gmb> gary_poster, Okay. I've not finished lunch yet though :)
[14:28] <gary_poster> gmb, lol, ok
[14:34] <gary_poster> benji, this happend on my testlist 2 run (yours) locally, but did *not* show up in the buildbot failure output from two days ago.  Did you see anything like this? http://pastebin.ubuntu.com/883307/
[14:34]  * benji looks
[14:34] <gary_poster> s/ my testlist 2 run (yours)/ my testlist 2 run (the one you ran first)/
[14:35] <benji> gary_poster: I haven't seen that failure.
[14:35] <gary_poster> ok, benji, I'll say it was unique to something on my system then.  Thanks
[14:51] <gary_poster> barry's absence will make it difficult to pick his brain
[14:58] <gary_poster> gmb, I'm doing a bzr branch lp:~gmb/charm-tools/add-charm-helpers on the assumption that this is the right thing to do
[14:59] <gmb> gary_poster, It is; you'll also need to get lp:~gmb/ubuntu/precise/charm-tools/new-packaging for the debian stuff that I'm currently using
[14:59] <gmb> (Since charm-tools has separate source and packaging branches)
[14:59] <gary_poster> ah ok
[15:00] <gmb> https://code.launchpad.net/~gmb/+recipe/charm-tools-daily has some of the details.
[15:00] <gary_poster> ack
[15:01]  * gary_poster decides he's still sick enough to be allowed to sit down while staring at build logs
[15:05] <benji> The review season begins.
[15:05]  * gary_poster doesn't understand why a "successful build" would contain something that failed to build
[15:06] <gmb> gary_poster, Because the recipe built successfully - creating the source package - but the binary didn't :)
[15:06] <gary_poster> gmb, bah :-)
[15:07] <gmb> :)
[15:22] <gary_poster> benji frankban gmb, I added miscellaneous, high priority, dated cards to represent the work each of us needs to do for the reviews.  We should look at this on every call to make sure we are making sufficient and timely progress on it.
[15:22] <benji> k
[15:22] <gary_poster> We now, relatively suddenly, have a *lot* of miscellaneous cards. :-) To get rid of one...
[15:23] <gary_poster> gmb, what's up with lp2kanban?  Did you get that running, or is Brad still doing it, or...?
[15:23] <gmb> gary_poster, I got it running; let me check it.
[15:23] <gary_poster> thanks
[15:23] <gary_poster> the "..." cards from Francesco ought to have had their titles filled afaik
[15:26] <gary_poster> frankban, I'm trying to decide whether I feel qualified reviewing your branch. ;-) Meanwhile though, I did see one thing that I learned this week.  In this line...
[15:26] <gary_poster> while [ $delay -gt 0 -a ! -s {leases1} -a ! -s {leases2} ]
[15:26] <gary_poster> I suggest quoting "$delay"
[15:26] <gary_poster> If you do not, in some edge cases the "[" command will get upset and confused, in my experience and per some advice I've read recently.
[15:27] <gary_poster> (in particular, the case in which $delay is empty...which will probably never happen here since I assume 0 is not empty, but it is supposedly just good practice to quote substitutions because of this kind of fragility)
[15:27] <frankban> gary_poster: humm, maybe when $delay is something starting with "-"?
[15:27] <gary_poster> yeah maybe that too
[15:28] <frankban> gary_poster: ok thanks for the hint
[15:29] <gary_poster> sure
[15:29] <gmb> gary_poster, I've run it manually; looks like it's not running on cron for some reason; I'll poke around.
[15:29] <gary_poster> thanks gmb
[15:29] <gmb> Anyway; /me -> afk for a short while
[15:29] <gmb> (Bus home)
[15:31] <gary_poster> What the heck, I'll claim this review frankban :-)
[15:31] <frankban> :-D
[15:31] <gary_poster> frankban, what does this mean: "truncate -c -s0 {leases1}"
[15:32] <frankban> gary_poster: if the file exists, truncate it at size 0, otherwise, do nothing
[15:32] <gary_poster> gotcha
[15:32] <gary_poster> back in a few
[16:25]  * gary_poster is lunching now
[16:57] <gmb> gary_poster, Okay, so I'll catch you when you get back, but interesting aside: if I build the package manually using Brad's steps, I get something that actually installs the python files. Not to anywhere useful, but it does _actually_ install them instead of ignoring them.
[16:57] <gmb> s/you/I/
[16:58] <gary_poster> gmb, I'm here, but reviewing and emailing and stuff
[16:58] <gary_poster> and, interesting
[16:58] <gmb> gary_poster, Ah, okay. I'm going to be heading out shortly anyway. Haven't spoken to Barry yet; I'll ping him now and see if he'll be free for a chat later.
[16:59] <gary_poster> gmb, cool.  barry doesn't seem to be around today
[16:59] <gmb> gary_poster, Ah, yes, I just noticed. Darnit.
[16:59] <gary_poster> gmb, so what should our plan be?
[17:00] <gmb> gary_poster, My first choice is to get the python stuff out of charm tools and package that. This other way is proving unrewarding.
[17:00] <gary_poster> and in particular, what are our goals for the handover, and what are our goals for when I'm working.
[17:00] <gary_poster> gmb, that's fine with me, but Clint is the maintainer of the charm helpers project
[17:00] <gary_poster> so I'd like to convince him
[17:01] <gary_poster> I'm happy to give him an ultimatum, of sorts:
[17:01] <gary_poster> either focus on helping us get his preferred approach to work, or let us do what you propose
[17:02] <gary_poster> we've spent (via you primarily and brad secondarily) a *lot* of time on this
[17:02] <gary_poster> and we should wrap it up one way or the other
[17:02] <gary_poster> I'm happy to speak managerially about this to Clint ;-)
[17:03] <gary_poster> also, what is your schedule for the next few hours work-wise, again?
[17:03] <gmb> gary_poster, Okay. I agree with you. My thought was that having a separate package that works would be a nice convincer :).
[17:03] <gary_poster> heh
[17:03] <gmb> gary_poster, I'll be afk until about 20:30 UTC, and will then finish my day ~1h.
[17:03] <gary_poster> gmb, afk starting when? now-ish?
[17:04] <gmb> But TBH I'll likely be around quite late; Sarah's got reports to write, so she pretty much needs me to shut up and get on with other things.
[17:04] <gmb> gary_poster, Yes.
[17:04] <gary_poster> :-)
[17:04] <gary_poster> ok gmb, I'll see if I can corral SpamapS while you are gone
[17:04] <gmb> Thanks :).
[17:04] <gary_poster> :-) welcome.  ttyl
[17:04]  * gmb -> exeunt to divers alarums
[17:04] <gary_poster> heh
[17:11] <gary_poster> frankban, bash-as-programming-language frightens me more and more as I learn more and more about it ;-) but what you've done looks very good.  There are some constructs that I understand from context but will simply trust you on (case in point: why the initial dollar sign in "delay=$(( $delay - 1 ))"?  Why can't it be "delay=( $delay - 1 )"?)
[17:12] <gary_poster> So, will approve :-)
[17:13] <gary_poster> Done
[17:13] <frankban> gary_poster: thanks. that block was taken as is from start-ephemeral... so, no idea either, and I am not curious...
[17:13] <gary_poster> lol
[17:13] <gary_poster> cool
[17:14] <gary_poster> I'm somewhat amazed that people still program in this stuff :-)
[17:14] <frankban> yes, only perl is worse than this...
[17:15] <frankban> ;-)
[17:15] <gary_poster> heh
[17:23] <frankban> gary_poster: landing, and, I am not a buildout expert, so maybe you could take a quick look at https://code.launchpad.net/~frankban/lpsetup/add-buildout/+merge/97466
[17:27] <gary_poster> frankban, will do.
[17:27] <frankban> ty gary_poster
[17:54] <gary_poster> frankban, approved buildbot branch conditionally
[17:54] <gary_poster> ./bin/test doesn't work
[17:55] <gary_poster> other ideas in my reply
[17:56] <frankban> gary_poster: we still don't have unit tests in lpsetup: it is actually the next step. Having test, bin/test should work
[17:56] <gary_poster> frankban, :-) ok cool
[17:59] <frankban> gary_poster: buildout was suggested by benji (basically to have a test runner for free I think). I think pip is already supported (setup.py), once the project will be registered to PyPI
[18:00] <gary_poster> frankban, ok cool
[18:00] <frankban> ty gary_poster, EOD, have a nice evening
[18:00] <gary_poster> you too frankban, bye
[18:20] <benji> ok, my list is down to 36 failures and 126 errors; submitting MP for read-only fix now
[19:16] <gary_poster> awesome benji!
[19:16] <gary_poster> very large number
[19:16] <gary_poster> but not as large as 3000 :-)
[19:16] <benji> gary_poster: I'm persuing making bugs for all of the test isolation failurs, but I wonder if that's the right thing to do.  Thoughts?
[19:17] <gary_poster> benji, that's fine as long as it doesn't take too long.  I've identified four "high" priority cards
[19:17] <gary_poster> you and frankban have addressed two
[19:18] <gary_poster> the other two on board are, as you'd expect, the next things I'd like to see
[19:18] <gary_poster> because they prevent us from getting a true full run of test
[19:18] <gary_poster> s
[19:19] <benji> I am in a state of kanban conflict: the board is now not over the limit (with me moving my branch into landing) but we can't add anything else without going back over
[19:19] <gary_poster> benji, if there is a high card, there is clear visible reason for why we would do so
[19:20] <gary_poster> I don't normally encourage this
[19:20] <gary_poster> but the high cards, and the reasoning/concern behind them, warrant it in my opinion
[19:20] <benji> ok, that sounds reasonable to me; I'll take one of the two remaining high cards
[19:20] <gary_poster> cool
[19:31] <gary_poster> benji, does test list 2 still hang at the end even with your isolation fix?  It would have been nice if... :-)
[19:31] <benji> gary_poster: if test list 2 is tmpXctd5i, then no
[19:32] <benji> so, you're suggesting that bug 954384 may already be fixed?
[19:32] <_mup_> Bug #954384: test teardown can hang <paralleltest> <Launchpad itself:Triaged> < https://launchpad.net/bugs/954384 >
[19:32] <gary_poster> benji, it doesn't hang?  yes!  that is what I am suggesting!  With glee in my heart!
[19:33]  * benji watches as gary_poster skips through a meadow and whistles with songbirds.
[19:33] <gary_poster> :-)
[19:33] <gary_poster> yeah, I've been kind of a ball of tension this week for one reason and another.
[19:33] <gary_poster> this relieves a big reason
[19:34] <benji> I can say definitively that it didn't hang, but I can't say for sure that it hung before my fix.... hmm, or can I; let me look at something.
[19:34] <gary_poster> right, it could still be lxc
[19:35] <gary_poster> unless it hung for you before
[19:36] <benji> nope, I don't have any evidence that it hung before
[19:37] <benji> I can do another test run, maybe late tonight (because it takes forever, 199 minutes last time) to try to get it to hang (running the pre-fix code).
[19:37] <benji> all this casts doubt on whether or not I can or should work on 954384 (which I planned on doing)
[19:38] <benji> I could try to reproduce the hang wiht a smaller test subset.  That seems like a smart thing to do.
[19:38] <benji> I also really need to get a precise lxc or vm up.
[19:41] <gary_poster> benji, why don't you do the precise vm/lxc
[19:42] <gary_poster> If we don't have the hang anymore then trying to repro doesn't make a lot of sense to me
[19:42] <gary_poster> oh
[19:42] <gary_poster> right
[19:42] <gary_poster> you don't have any evidence that it hung before
[19:42] <gary_poster> which means it could still be an lxc thing
[19:43] <benji> right, since I haven't provoked it, we can't be sure that me not seeing it is evidence that it is gone
[19:44] <benji> but the not having a vm thing is really hurting me too, for example, I can't land the fix for the read-only bug until I have one.  I have to depend on the kindness of strangers, hint hint.
[19:45] <benji> speaking of, is lpsetup supposed to work?  I get TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' when I run it
[19:49] <gary_poster> benji, lpsetup it is not supposed to work
[19:50] <gary_poster> benji, kindness of strangers, lol, ok
[19:50] <benji> ok, good, I guess :)
[19:50] <benji> thanks!
[19:50] <gary_poster> benji, I am setting up my juju buildbot to run your branch, then will land
[19:51] <gary_poster> I mean, I will land it once I have started the tests, not after they have run
[19:51] <gary_poster> well
[19:51] <gary_poster> oh heck, yes
[19:52] <gary_poster> lxc-wait is really a drag
[19:54] <benji> heh
[20:03] <benji> ok... it is apparently both required that we devleop on precise (because we can't land otherwise) and impossible to set LP up on precise (email thread started by
[20:04] <benji> Deryck
[20:04] <benji> bang! bang!
[20:04]  * benji shoots the ferral tabs that got in here.
[20:05]  * benji is orthographically challenged, but can still spell "orthographically challenged"
[20:38] <gary_poster> benji, lxc works :-)
[20:39] <benji> gary_poster: I don't follow.
[20:39] <gary_poster> benji, which is what I do (precise host, lucid lxc instances)
[20:39] <gary_poster> and that appears to work
[20:39] <gary_poster> benji, on another note
[20:39] <gary_poster> lxc-start-ephemeral is adding to the number of days of my life that I have lost this week from stress :-P
[20:39] <benji> heh
[20:40] <benji> wait, you develop on lucid?  I thought we were supposed to use precise?
[20:40] <gary_poster> benji, I edit my code on precise.  I run my tests and my dev tools on lucid
[20:41] <gary_poster> which is AOK
[20:41] <gary_poster> benji, back on my stress-inducing topic...take a glance at http://ec2-50-16-1-238.compute-1.amazonaws.com:8010/builders/lucid_lp/builds/2/steps/shell_8/logs/stdio
[20:41] <benji> oh!  I needed that bit of info!  I'll try to set up a lucid lxc container then.
[20:42] <gary_poster> notice the __init__ complaint, #1.  Where the heck did that come from?
[20:42] <benji> hmm "exit code 3"
[20:42] <gary_poster> #2, I try to run the given command on the slave
[20:42] <gary_poster> This fails, complaining that xvfb fails
[20:43] <gary_poster> #3, I try to run the "start a ephemeral container and then I'll log into it".  This works.  Then I log in, become buildbot, and run the other part of the command.  This succeeds
[20:43] <benji> ooh, I didn't see that.  That is odd.
[20:43] <gary_poster> So...I'm about to try duping the ssh command
[20:45] <gary_poster> And all I *really* want to do is verify that frankban's fix from yesterday fixes our problem, and verify that your fix from today fixes the majority of our tests, and might or might not fix the hang problem
[20:45] <gary_poster> but instead I keep getting "one step forward two steps back" issues
[20:45] <gary_poster> ok, venting over.  thanks benji. ;-) now I'll go back to trying to do the ssh
[20:46] <benji> good luck :)
[20:46] <gary_poster> ;-) thanks
[20:50] <gary_poster> benji argh:
[20:50] <gary_poster> ssh -n -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i /var/lib/buildbot/.ssh/launchpad_lxc_id_rsa<EMAIL_ADDRESS>-- 'xvfb-run --error-file=/var/tmp/xvfb-errors.log --server-args=-screen 0 1024x768x24 -a /var/lib/buildbot/slaves/slave/lucid-devel/build/bin/test --subunit'
[20:50] <gary_poster> notice the lack of quotes that we so carefully added
[20:50] <benji> pfft
[20:50] <gary_poster> benji, what did we do to fix that again?  I forgot
[20:51] <benji> I'm trying to remember.
[20:53] <benji> gary_poster: I think this was the very long line and regex to remove extra spaces in setuplxc.
[20:54] <gary_poster> benji, this is what we are producing now, from the setuplxc script:
[20:54] <gary_poster> lxc-start-ephemeral -u buildbot -S /var/lib/buildbot/.ssh/launchpad_lxc_id_rsa -o lptests -- xvfb-run --error-file=/var/tmp/xvfb-errors.log --server-args='-screen 0 1024x768x24' -a /var/lib/buildbot/slaves/slave/lucid-devel/build/bin/test --subunit
[20:54] <gary_poster> IOW, it is good
[20:54] <gary_poster> afaict
[20:54] <gary_poster> I'm going to try random quoting in lxc-start-ephemeral...
[20:57] <benji> gary_poster: I don't think that's good.  Remember that ssh handles the arguments incorrectly, we need to put everythin after -- in double-quotes.
[20:58] <gary_poster> benji, well...
[20:59] <gary_poster> benji, maybe that's what we did.  I don't remember, but we could dig it up.  BUT...
[20:59] <gary_poster> If I call this
[20:59] <gary_poster> lxc-start-ephemeral -u buildbot -S /var/lib/buildbot/.ssh/launchpad_lxc_id_rsa -o lptests -- xvfb-run --error-file=/var/tmp/xvfb-errors.log --server-args='-screen 0 1024x768x24' -a /var/lib/buildbot/slaves/slave/lucid-devel/build/bin/test --subunit
[20:59] <gary_poster> then ISTM that lxc-start-ephemeral ought to be able to quote everything itself
[21:00] <gary_poster> however
[21:00] <gary_poster> if you run that command
[21:00] <gary_poster> $@ (in lxc-start-ephemeral) is this
[21:01] <gary_poster> xvfb-run --error-file=/var/tmp/xvfb-errors.log --server-args=-screen 0 1024x768x24 -a /var/lib/buildbot/slaves/slave/lucid-devel/build/bin/test --subunit
[21:01] <gary_poster> that is, the quotes have been lost already
[21:01] <gary_poster> before we even get to ssh
[21:02] <benji> well, not exactly, the "--server-args=-screen 0 1024x768x24" bit is in a single arugment, but $@ formats the arguments as a string, loosing the grouping information which is then re-interpreted by ssh (incorrectly)
[21:03] <benji> setuplxc on devel looks like it should do the right thing to me.  I suggest looking at the setuplxc on your box to be sure it has the latest code
[21:06] <gary_poster> benji, what I believe is supposed to be the fix is there:
[21:06] <gary_poster> http://pastebin.ubuntu.com/883900/
[21:07] <benji> gary_poster: yeah, that looks right to me... hmm, at one point we also put double-quotes around the $@ passed to ssh inside lxc-start-ephemeral; I can't remember if that was part of the fina fix or not, but that'd be the next thing I try
[21:09] <benji> this is irritating, reasoning about this stuff shouldn't be this hard
[21:09] <gary_poster> benji, on late team lead call
[21:21] <gary_poster> benji, I'm still on call
[21:21] <gary_poster> but
[21:21] <gary_poster> oh
[21:21] <gary_poster> I bet you have stopped :-)
[21:22] <benji> gary_poster: I'm trying to stop. ;)
[21:22] <gary_poster> benji, :-) ok.  So, I think that might have been a red herring.  I'll explain last :-)
[21:23] <gary_poster> later I mean
[21:42] <gmb> gary_poster, So, did you hear anything back from Spamaps?
[21:43] <gary_poster> gmb, ugh, no, I've been deep into my private hell of buildbot no longer working, sorry.  Let me see if he is still around
[21:43] <gmb> gary_poster, No worries. Seems like this week is a week of private hells.
[21:43] <gary_poster> yeah :-/
[21:43] <gmb> If we all had a hangout, at least we'd be toasty together.
[21:43] <gary_poster> heh, yeah :-)
[22:00] <gary_poster> gmb, you on #juju?
[22:01] <gmb> gary_poster, yes; I was looking at the wrong #juju :)
[22:01] <gary_poster> :-)
[22:01] <gmb> gary_poster, Awesomesauce.
[22:02] <gmb> Also, never saying "awesomesauce" again.
[22:02] <gary_poster> lol
[22:03] <gary_poster> gmb, do you have any champagne?
[22:05]  * gary_poster steps away
[22:11] <gmb> gary_poster, No, but I'll sleep better tonight :)
[22:11] <gary_poster> gmb, cool :-)


[10:42] <tgreer> hrw: ping?
[11:20] <hrw> tgreer: pong
[11:36] <tgreer> hrw: tried setting that flag to Y
[11:37] <tgreer> but still getting the same issue
[11:37] <tgreer> was just wondering if you had any other tips
[11:38] <tgreer> although i ticked another few boxes so not sure if that made a mess or not
[11:39] <tgreer> Support for the traditional ATAGS boot data passing is selected
[11:39] <tgreer>  Provide old way to pass kernel parameters
[11:39] <tgreer> is selected
[11:39] <tgreer> as is Supplement the appended DTB with traditional ATAG informati
[11:45] <hrw> tgreer: but have you appended dtb to the kernel?
[11:45] <tgreer> er
[11:45] <tgreer> no idea
[11:45] <tgreer> how would i do that
[11:47] <tgreer> i think i can see the option for it in make menuconfig
[11:47] <tgreer> but no idea what to put
[11:47] <hrw> tgreer: https://patchwork.kernel.org/patch/1432321/
[11:51] <tgreer> hrw: so i need a dtbImage.... where would I get one of those?
[11:53] <tgreer> board-dt-tegra20.c << aha
[11:55] <tgreer> still no idea how to use it :(
[11:56] <hrw> marvin24: you know Tegra more than I do. can you help tgreer?
[12:00] <marvin24> tgreer: make dtbImage?
[12:00] <tgreer> oh that simple?
[12:01] <marvin24> I usually attach it "by hand"
[12:01] <marvin24> so I don't know, but it seems like this
[12:01] <tgreer> marvin24: so what make dtbImage
[12:01] <tgreer> and then flash that to the bootloader
[12:01] <tgreer> or is that not the right image?
[12:01] <marvin24> ah, there is a .<dt>
[12:02] <marvin24> tgreer: what do you want to do at all
[12:02]  * marvin24 didn't read the backlog
[12:02] <tgreer> tegra 250 harmony development board
[12:02] <tgreer> trying to get an updated kernel on it to include pcie and the wifi drivers
[12:03] <tgreer> currently running  3.1.10-g1ff6b94 that came with ubuntu core
[12:03] <tgreer> got the latest kernel source from ubuntu's git repo
[12:04] <tgreer> i have 2 questions: which are the right options under Boot options in make menuconfig
[12:04] <tgreer> and the 2nd is what commands should I run to get the relevant file
[12:04] <tgreer> normally i do make menuconfig
[12:04] <marvin24> ubuntu has a tegra kernel?
[12:04] <tgreer> and then make zImage
[12:04] <tgreer> marvin24: the armhf kernel boots on it
[12:04] <marvin24> you have to make dtbs target
[12:04] <marvin24> and then cat arch/arm/boot/dts/tegra20-harmony.dtb >> zImage
[12:05] <tgreer> is that after i make zImage?
[12:05] <tgreer> or instead of
[12:06] <marvin24> at the same time ;-)
[12:06] <tgreer> blah
[12:06] <marvin24> make zImage dtbs
[12:06] <tgreer> marvin24: ok thanks
[12:06] <tgreer> before i make the image again
[12:06] <tgreer> was just wondering if you could confirm if i have the right options ticked
[12:06] <marvin24> this dtbImage isn't upstreamed as it seems
[12:07] <tgreer> i will be documenting ALL of the things once i get it working
[12:07] <marvin24> tgreer: make tegra_defconfig should give you a usable config
[12:07] <tgreer> okay
[12:07] <tgreer> will just double check it has the right bits in it for pci-e and then boom we're on
[12:10] <tgreer> okay make zImage dtbs -j2 running just now
[12:10] <tgreer> and then will do the cat
[12:10] <tgreer> all going well i owe you some beer
[12:10] <tgreer> :)
[12:12] <marvin24> does you board run uboot or fastboot loader?
[12:12] <tgreer> fastboot
[12:13] <tgreer> the nvidia dev kit instructions to load u-boot onto it just make it KO
[12:13] <marvin24> tgreer: in this case you need to modify the tegra_defconfig defaults
[12:13] <marvin24> e.g. appended_dtb you know already
[12:13] <tgreer> damnittttt
[12:14] <tgreer> making clean and starting again
[12:14] <marvin24> no need to clean
[12:14] <tgreer> so set appended dtb to y
[12:14] <tgreer> and thats it?
[12:14] <marvin24> I think you also need COMPAT_ATAGS
[12:14] <marvin24> mmh, maybe not
[12:14] <marvin24> that's only for 3.1 and uboot
[12:15] <tgreer> ok set appended_DTB
[12:15] <tgreer> starting compiling again
[12:15] <marvin24> also ccache helps speedup kernel builds
[12:15] <tgreer> (for the record I'm not cross compiling)
[12:15] <tgreer>  Supplement the appended DTB with traditional ATAG information (ARM_ATAG_DTB_COMPAT) [N/y/?] (NEW)
[12:15] <tgreer> i'm getting propmpted for this
[12:15] <marvin24> fastboot isn't really supported on mainline
[12:16] <marvin24> tgreer: answer no for now
[12:16] <tgreer> okdaydoke
[12:16] <marvin24> mainline doesn't have atags
[12:16] <tgreer> is there a better kernel tree to use instead of the generic ubuntu one?
[12:17] <marvin24> I think the ubuntu kernel doesn't compile at all on arm, I mean the 3.10 one
[12:17] <marvin24> at least not last time I tried
[12:18] <marvin24> but that's because mainline is broken for multisoc
[12:18] <marvin24> tgreer: just try and find out
[12:18] <marvin24> tgreer: I have CONFIG_ARM_ATAG_DTB_COMPAT set in my config btw
[12:18] <ogra_> mainline broken for multisoc ?
[12:18] <ogra_> we ship it with multisoc
[12:19] <marvin24> well, mutlisoc + enabling all kinds of modules
[12:19] <marvin24> in 3.10
[12:19] <ogra_> for armadaxp, omap and highbank iirc
[12:19] <marvin24> (the saucy kernel)
[12:19] <marvin24> they are not build I guess
[12:19] <marvin24> at least now two weeks ago
[12:19] <ogra_> hmm, i thought they were
[12:19] <tgreer> marvin24: ok will try it without
[12:20] <marvin24> ogra_: some fixes are already upstreamed
[12:20] <marvin24> but I guess not all will make it in
[12:20] <marvin24> tgreer: you won't be able to supply kernel command line without
[12:20] <marvin24> or you need to compile in a command line
[12:20] <ogra_> well, i guess the kernel team will maintain them as sauce patches then
[12:20] <marvin24> yes, sad enough
[12:20] <ogra_> and aim for the next merge window for upstreaming
[12:21] <tgreer> marvin24: do i need to?
[12:21] <tgreer> marvin24: i dont supply any kernel command lines at the moment
[12:21] <marvin24> tgreer: well, you won't get far I think without (e.g. no root), but you can try
[12:22] <tgreer> hmmm
[12:22] <tgreer> ok will just stop and add it
[12:22] <marvin24> do you have hdmi output connected?
[12:22] <ogra_> (or a serial console)
[12:22] <tgreer> serial console
[12:23] <tgreer> no hdmi output working yet
[12:23] <marvin24> yes, serial console should work
[12:23] <tgreer> so added in CONFIG_ARM_ATAG_DTB_COMPAT=y
[12:23] <marvin24> hdmi should also work btw
[12:23] <tgreer> marvin24: getting nothing out on it currently
[12:23] <tgreer> but that's next on my hitlist...
[12:23] <ogra_> you will need fbcon and friends enabled in your config
[12:23] <tgreer> do i need to add anything else into the .config
[12:23] <ogra_> for hdmi
[12:23] <marvin24> tegra_defconfig should have them already
[12:23] <tgreer> i need what?
[12:24] <ogra_> framebuffer console
[12:24] <tgreer> neither of them are in the .config
[12:24] <marvin24> oh, it doesn't ;-)
[12:24] <tgreer> lets make menuconfig
[12:24] <tgreer> and find them
[12:24] <tgreer> where abouts are they
[12:24] <ogra_> device drivers ... graphics devices
[12:25] <ogra_> also take a look at character devices, youo want virtual terminals ... (i.e. if the config pmes originally from android thats always off)
[12:25] <ogra_> *comes
[12:25] <tgreer> they're enabled
[12:25] <tgreer>  <*> Framebuffer Console support
[12:25] <tgreer> as is  <*> NVIDIA Tegra DRM
[12:26] <marvin24> maybe I was looking at the wrong branch
[12:27]  * tgreer gets some air while it compiles
[12:27] <tgreer> i shall report back in when done
[12:27] <tgreer> thanks ogra_ marvin24 and hrw
[12:36] <marvin24> gl
[13:08] <tgreer> compiled :D
[13:11] <tgreer> moment of truth :)
[13:12] <tgreer> yuuussssssssssssss
[13:12] <tgreer> kernel booting :)
[13:12] <tgreer> root@tegra:~# uname -r
[13:12] <tgreer> 3.8.13
[13:12] <tgreer> WOOOOp
[13:12] <marvin24> concrats!#
[13:12] <tgreer> annoyingly i dont see the wireless card though
[13:13] <marvin24> you need to build the modules
[13:13] <tgreer> oh
[13:13] <marvin24> and install on mmc before booting
[13:13] <tgreer> i thought when it was * it was build directly into the kernel
[13:13] <tgreer> not as a module
[13:14] <marvin24> well, wifi cannot be in the kernel because it needs firmware
[13:14] <tgreer> damnit
[13:14] <marvin24> maybe this changed today, but I don't know
[13:14] <tgreer> ah right ok
[13:15] <tgreer> but the drivers in the kernel tree these days?
[13:16] <tgreer>   │ │    <*>   Atheros mobile chipsets support                            │ │
[13:17] <tgreer>   │ │    <*>     Atheros ath6kl SDIO support                              │ │
[13:17] <tgreer>   │ │    <*>     Atheros ath6kl USB support                               │ │
[13:17] <tgreer>   │ │    [*]     Atheros ath6kl debugging
[13:17] <marvin24> they should
[13:18] <tgreer> root@tegra:~/ubuntu-raring# modprobe ath6kl
[13:18] <tgreer> libkmod: ERROR ../libkmod/libkmod.c:554 kmod_search_moddep: could not open moddep file '/lib/modules/3.8.13/modules.dep.bin'
[13:18] <marvin24> yes, no modules installed
[13:18] <tgreer> derp
[13:18] <marvin24> copy them to a usb drive
[13:18] <marvin24> if you have usb-storage compiled in
[13:18] <tgreer> i havent built the modules
[13:18] <tgreer> also
[13:18] <marvin24> make modules ...
[13:18] <tgreer> all the kernel compilcation is on the live SDcard
[13:19] <tgreer> making it just now
[13:19] <marvin24> ah, lucky you
[13:23] <tgreer> do i need to do a make moduleinstall or something?
[13:24] <tgreer> make modules_install it seems
[13:27] <tgreer> usbcore: registered new interface driver ath6kl_usb hmmm
[13:31] <tgreer> you mentioned firmware... should i stick that in lib/firmware/ar6000?
[13:32] <marvin24> yes
[13:33] <tgreer> righto. so it cant be in the kernel because it needs firmware... so i should rebuild the kernel without that module in it...
[13:33] <tgreer> have it as an actual module
[13:33] <tgreer> and then modprobe it to get it in?
[13:33] <marvin24> it should auto probe
[13:33] <marvin24> so all should work as it is now
[13:33] <tgreer> right just by putting the firmware in the right place?
[13:34] <marvin24> if you installed linux-firmware it should be there already
[13:34] <tgreer> er dont think i have..
[13:34] <marvin24> check the dmesg, maybe you find some hint
[13:34] <marvin24> it should be automaticly installed
[13:35] <tgreer> usbcore: registered new interface driver ath6kl_usb is the only mention of it
[13:36] <marvin24> nothing before that line?
[13:36] <marvin24> do you have /lib/firmware/ath6k/AR6004 ?
[13:36] <tgreer> no.. but then i didnt have linux firmware... i had the firmware from the nvidia devkit
[13:36] <tgreer> let me install linux firmware and try again
[13:37] <marvin24> well, both should work
[13:37] <tgreer> root@tegra:~# ls /lib/firmware/ath6k/AR600
[13:37] <tgreer> AR6003/ AR6004/
[13:37] <tgreer> i think mine is a 6002
[13:37] <tgreer> i'll put my ar6002 folder in there
[13:39] <tgreer> only mention of ath is in: usbcore: registered new interface driver ath6kl_usb
[13:39] <marvin24> maybe you are still missing something
[13:46] <tgreer> no luck with the wifi...
[13:46] <tgreer> any ideas on getting hdmi out to work
[13:47] <tgreer> Error: Can't open /dev/nvhost-ctrl
[13:47] <tgreer> Opening channel failed 7
[14:13] <marvin24> tgreer: that's old userspace
[14:13] <marvin24> you need to remove it and install opentegra
[14:14] <marvin24> what's the output of lsusb? (to some pastebin please)
[14:16] <tgreer> http://pastebin.com/GS6GqNsT
[14:17] <marvin24> tgreer: there is no usb wifi
[14:17] <marvin24> only the 3g modem
[14:17] <tgreer> i've noticed..
[14:17] <tgreer> also: https://launchpad.net/~ac100/+archive/ppa/+build/4306566 << this one?
[14:17] <marvin24> yes
[14:18] <tgreer> https://wiki.ubuntu.com/ARM/TEGRA/AC100#Hardware says to use nvidia-tegra
[14:18] <tgreer> The nvidia-tegra package is not yet available for armhf. For now, just stay with the default open source driver.
[14:18] <tgreer> ignore me
[14:20] <marvin24> tgreer: the nvidia tegra package is for downstream kernels only (v3.1)
[14:21] <tgreer> ahhh
[14:21] <tgreer> removing and adding opentegra
[14:21] <marvin24> mainline uses a totally different driver (open source)
[14:23] <tgreer> damnit
[14:23] <tgreer> libudev0 is needed
[14:23] <tgreer> and isnt in raring packages
[14:28] <infinity> Nope, you can fish it out of quantal, if you really need it.
[14:28] <tgreer> oh its in raring-proposed it seems
[14:28] <infinity> But if you run into upstream binaries that link libudev0, please yell at them to recompile.
[14:29] <infinity> If it's in raring-proposed, that's NBS cruft, and I'll remove it. :P
[14:29] <tgreer> its not
[14:29] <tgreer> its gone now
[14:29] <tgreer> its the opentegra package thats linking it
[14:30] <infinity> Where does this opentegra come from?
[14:31] <tgreer> https://launchpad.net/~ac100/+archive/ppa
[14:31] <tgreer> only place i can find it
[14:32] <infinity> Oh, a simple rebuild might fix that.
[14:32] <infinity> marvin24: Want to rebuild that PPA upload? :P
[14:34] <tgreer> tegra-hdmi hdmi: cannot set audio to 44100 at 81620000 pclk
[14:34] <tgreer> well thats progresss
[14:34] <marvin24> tgreer: rebuild for saucy?
[14:34] <marvin24> tgreer: that's harmless
[14:35] <infinity> marvin24: The libudev0 -> libudev1 transition happened in raring, you probably want to rebuild https://launchpad.net/~ac100/+archive/ppa/+build/4307597
[14:35] <tgreer> marvin24: yes harmless
[14:35] <marvin24> infinity: I think I build on raring, should I change depends
[14:35] <tgreer> but still not output on hdmi
[14:36] <infinity> marvin24: You built on raring, but before the transition.  A no-change rebuild should fix it.
[14:36] <marvin24> ok
[14:37] <tgreer> xrandr gives me Can't open Display
[14:37] <tgreer> marvin24: do you have an example xrandr?
[14:38] <marvin24> tgreer: check Xorg.0.log first
[14:40] <marvin24> infinity: sorry, how to rebuild - I cannot find it in the web interface, do I need to bumb the version?
[14:41] <infinity> marvin24: Yeah, bump the version and reupload.
[14:42] <infinity> dch -i 'No-change rebuild for the libudev0 -> libudev1 transition.'
[14:42]  * marvin24 really hates launchpad for you cannot replace a package version ...
[14:42] <infinity> That's a feature, not a bug. :P
[14:42]  * marvin24 hates this "feature"
[14:42] <infinity> Having two different packages with the same filename/version is generally a Bad Thing.
[14:42] <marvin24> I know
[14:42] <marvin24> but I still hate it ;-)
[14:43] <infinity> Heh.
[14:49] <tgreer> http://pastebin.com/raw.php?i=h0iu2j4B
[14:49] <tgreer> output from startx
[14:57] <marvin24> tgreer: looks fine
[14:57] <marvin24> what kind of device is this "800x480" with hdmi?
[14:58] <tgreer> except nothing on display
[14:58] <tgreer> its a small touchscreen device
[14:58] <marvin24> change the console
[14:58] <tgreer> i need a keyboard for that
[14:58] <marvin24> chvt maybe
[14:59] <marvin24> btw, you can get rid of all the command line parameters except root= and rootwait
[15:00] <marvin24> they are all downstream kernel specific
[15:00] <marvin24> and console=ttyS0 of course
[15:02] <tgreer> still 0 on display
[15:02] <tgreer> its showing as no input
[15:03] <tgreer> if i plug it into my laptop works fine
[15:05] <marvin24> tgreer: hdmi is not hotplug capable yet
[15:05] <marvin24> did you rebooted?
[15:05] <tgreer> hmm yes but i'll try again
[15:06] <marvin24> maybe adding cma=64M may also help, but I think this is only required for large screens
[15:08] <tgreer> <.<
[15:08] <tgreer> let me try vga..
[15:09] <tgreer> still no signal :(
[15:10] <marvin24> tgreer: paste output of dmesg
[15:11] <tgreer> http://pastebin.com/CB6AFbkE
[15:12] <tgreer> i wonder if video=tegrafb  is the issue
[15:13] <marvin24> remove it
[15:13] <marvin24> remove everything not needed
[15:13] <tgreer> i dont know where thats set..
[15:13] <marvin24> something which created the bootimg
[15:13] <marvin24> mkbootimg ?
[15:15] <marvin24> vdd_ldo7,avdd_hdmi: disabling
[15:15] <marvin24> vdd_ldo8,avdd_hdmi_pll: disabling
[15:15] <marvin24> that's bad
[15:16] <tgreer> so remove videospec
[15:17] <marvin24> I'm off for now, but will come back in a few hours ...
[15:17] <tgreer> ok will try it without videospec and see what happens
[15:20] <tgreer> made no diff
[15:38] <tgreer> blahhragggeeeeeeeee
[15:43] <tgreer> would i be better off with u-boot as my bootloader?
[15:43] <tgreer> seems the fastboot binary has those details hardcoded
[15:50] <tgreer> this is so complex... tried changing the fastboot.bin and still same kernel command lines
[18:04] <marvin24> tgreer: how do you flash the kernel?
[18:04] <tgreer> using the flash.sh included in the nividia sdk
[18:19] <marvin24> tgreer: so I guess you need to edit this one


[09:54] <twiinz> hi there
[09:56] <twiinz> i'm planning to use upstart instances to manage subprocesses, i get the instance name from a database, im not sure what woud be the best approach to get all thoses instance to start automatically on a reboot, or on command
[09:58] <twiinz> so far i've worked out a system where my instances start on an event, and made second upstart conf file whose job is to loop throughout the list it got from the database and emits events
[10:00] <twiinz> but i've got a feeling there's an easier way to accomplish that, most of the examples i found about instance mention ttys, is there a built in way to say in the instance conf file, for the given runlevels iterate through this list of ttys [1, 2, 3, 4, 5, 6]?
[18:27] <BleSS> does upstart is only valid to use with shell scripts?
[18:28] <ion> Upstart can run and monitor any processes.
[18:28] <BleSS> I say because I'm changing my bash scripts to python since that bash is very cryptic and unmaintaneable
[18:31] <BleSS> ion: but in the next page http://upstart.ubuntu.com/getting-started.html says: shell script code that will be executed using /bin/sh
[18:31] <ion> The job definitions support scripting in sh, yes.
[18:32] <BleSS> so it isn't possible use python there, is it?
[18:35] <ion> Within job definitions? Not at the moment at least. But job definitions tend to be so simple sh is sufficient. Having a single interpreter for all job definitions is a good idea IMO, unless there’s a compelling reason to change that.
[18:42] <BleSS> thanks ion