[00:01] <kdub> racarr, yeah i mean, there are some good things, but our renderer just does the simple stuff at the moment
[00:01] <kdub> wobbly windows would benefit
[00:01] <racarr> haha right
[00:02] <racarr> it has the
[00:02] <racarr> map buffer object stuff which is kind of cool
[00:02] <racarr> from opengl 4
[00:04] <kdub> yeah, its a cool improvement
[00:05] <kdub> sometimes i forget that opengl can do animations, and its not just an api for passing buffers into
[00:05] <racarr> I read some paper once about some technique with using like two mapped vbo arrays and fences
[00:05] <racarr> in order to do animations in this zero copy fashion (I mean, it still ahs to make it to the GPU depending on your architecture)
[00:06] <racarr> but it was basically double buffering the vertex data, so neither the animator, or the GPU ever has to block
[00:06] <racarr> and then I think using some nvidia fence extension
[00:06] <racarr> I don't remember the details :p
[00:06] <smspillaz> racarr: opengles3 has uniform buffer objects and transform feedback
[00:06] <racarr> mm
[00:06] <smspillaz> which is just great
[00:07] <racarr> I don't think transform feedback is super interesting to mir though really
[00:07] <smspillaz> racarr: actually the even cooler one
[00:07] <smspillaz> racarr: its interesting if you want to like
[00:07] <smspillaz> do wobbly windows
[00:07] <smspillaz> in hardware
[00:07] <racarr> ubu could be useful for some kind of optimizations </speculation>
[00:07] <racarr> well
[00:07] <racarr> right
[00:07] <racarr> lol
[00:07] <smspillaz> racarr: whats more interesting is opengl 4.4
[00:07] <smspillaz> with stuff like
[00:07] <smspillaz> bindless textures
[00:07] <smspillaz> and
[00:08] <racarr> haha
[00:08] <racarr> thats what I was going to say
[00:08] <racarr> (bindless textures)
[00:08] <racarr> thats some cool stuff
[00:08] <smspillaz> bind groups
[00:08] <RAOF> Grr.
[00:08] <smspillaz> or whatever it was called
[00:08] <smspillaz> RAOF: y u mad
[00:08] <RAOF> racarr: What's the least I can do to get stderr from mir_demo_server_shell to display?
[00:11] <racarr> RAOF: 2>&1 > foo.txt
[00:11] <thomi> racarr: any progress on the mir_stress bug thingy?
[00:12] <RAOF> racarr: No, I mean "what's the least I can do to make mir_demo_server_shell not eat stderr?" Because I'm running it from ssh, so I can totally see anything that actually makes it to the tty.
[00:13] <racarr> thomi: No, I haven't found the second bug yet
[00:14] <racarr> I forgot it and let it escape my todo though so thanks :)
[00:14] <racarr> RAOF: err
[00:14] <racarr> I didnt know it ate stderr
[00:14] <racarr> I redirect stderr to a file all the time
[00:14] <racarr> at least I think Id o
[00:14] <smspillaz> RAOF: gdb breakpoint on close () and see where it calls close(2) ? :p
[00:15] <racarr> I really dont think its
[00:15] <racarr> supposed to do that
[00:16] <RAOF> Hm. Ok.
[00:17] <racarr> RAOF: OH HEY! While I remember I keep on meaning to ask you about something that I am meaning to take on friday/next week
[00:17] <racarr> DPMS support
[00:17] <RAOF> racarr: Oh, cool.
[00:17] <racarr> my understanding, is: expose turning CRTC on /off from mir::graphics, expose over IPC, expose component that lets shell approve/dissaprove these requests
[00:18] <racarr> add component in U-S-C to be friends with X
[00:18] <racarr> then implement a bunch of hooks on
[00:18] <racarr> XMirDisplay
[00:18] <racarr> or whatever
[00:18] <racarr> it's called
[00:18] <racarr> by a bunch of hooks I mean like 2
[00:18] <RAOF> Do we want to expose it over IPC?
[00:18] <racarr> does that make sense? What is up with backlight, I looked aroudn xf86-video-intel a little bit and the backlight code seemed a little strange at first glance using
[00:18] <racarr>  /sys files or something
[00:18] <racarr> RAOF: Hmm, well how else will X request it of USC
[00:19] <racarr> you mean USC should provide a
[00:19] <racarr> non mir interface perhaps
[00:19] <racarr> ?
[00:19] <RAOF> By USC implementing its own interface.
[00:19] <RAOF> This, incidentally, is a reason why having the protocol being extensible would be really useful. :)
[00:19] <racarr> the_frontend_communicator() override
[00:19] <racarr> ;)
[00:20] <racarr> ok I understand
[00:20] <racarr> hmm
[00:20] <RAOF> Oh, and backlight is indeed a twisty maze of vendor hate.
[00:20] <racarr> I'm not sure in regards to over IPC / USC has it's own protocol
[00:21] <racarr> I...remember I leaned towards the mir protocol when Iw as thinking last week
[00:21] <racarr> but I think thats just because it wasnt clear to me what the protocol should be otherwise (DBus to X)
[00:21] <racarr> it's also. not entirely absurd that maybe this is reasonable client API.
[00:22] <RAOF> It should be over the mir socket, but it shouldn't be in the Mir protocol that we expose to clients.
[00:22] <RAOF> Hm. Under what circumstances is it reasonable for a client to ask the display server to turn off the displays?
[00:22] <racarr> Maybe it makes sense for certain kinds of presentation or media apps
[00:23] <RAOF> You mean to ask the display server to *not* turn off the display, right?
[00:23] <racarr> or a coniguration app
[00:25] <racarr> RAOF: Well maybe not! I dunno i.e. a video player which has a distraction free setting can automatically turn off your displays when you are streaming to your TV
[00:25] <RAOF> Eh, maybe?
[00:25] <racarr> or like, when you present, you want your laptop display off, on, or in presentation mode, so presentation apps on other platforms often include what basically amounts to a monitor configuration panel
[00:25] <racarr> yeah I dunno, maybe :p
[00:26] <racarr> I think both of these are kind of borderline absurd, but I was just trying to generate
[00:26] <racarr> ideas
[00:27] <kgunn> thomi: thanks for the response - so, if i want to quick glance at all the unity tests reported on for mir.....what do i look at ?
[00:27] <kgunn> prep'ing for iom sprint
[00:27] <thomi> kgunn: without runing he tests yourself you mean? like, on a dashboard somewhere?
[00:27] <racarr> RAOF: I thought about you last night because one of my friends is studying to be an actuary so he started talking to me about a series of probability problems he was doing
[00:28] <RAOF> Oh?
[00:28] <racarr> so then, he started explaining how to solve them with multidimensional integrals, etc, and my thought was that like, from a constructive perspective
[00:28] <racarr> integrals seem to be the wrong abstraction to build
[00:28] <racarr> probability on top of
[00:28] <racarr> because why do you even need
[00:28] <racarr> infinite sets?
[00:29] <racarr> a few minutes in to arguing this point I feel as if I had a flash of empathy with your previous advisor XD
[00:29] <thomi> kgunn: that's the correct job, but for some reason older builds reported waaaay too many tests. Newer builds look good though, for e.g.: http://<IP_ADDRESS>:8080/job/mir-saucy-amd64-ci/336/testReport/
[00:31] <racarr> RAOF: Anyway that's how I invented my new theory of probability and started to wonder if the whole aesthetic of mathematical philosophy was misgrounded.
[00:31] <racarr> but...lol...back to DPMS, um, so...not the mir protocol?
[00:31] <RAOF> :)
[00:31] <racarr> not the mir protocol but over the mir socket sounds difficult
[00:31] <thomi> kgunn: not sure if that answers your question or not
[00:31] <RAOF> Yeah, needing uncomputable numbers sounds like a silly thing for probability :)
[00:32] <RAOF> racarr: It can probably be in the protocol.
[00:32] <RAOF> racarr: I'd quite like it to be less difficult for protocol extensions to exist, though.
[00:32] <racarr> I'll think about that
[00:32] <racarr> I am trying to think about something inbetween
[00:32] <racarr> non extensible protocol
[00:32] <racarr> and everything is a ClientMessage
[00:33] <racarr> and yeah thats exactly what I mean! You don't need all that for probability, so maybe by dealing with it in the continuum and then using limits to reduce it back to a finite state system you are actually
[00:33] <racarr> developing a less...'reusable' theory of probability
[00:33] <racarr> haha
[00:33] <RAOF> I think we could actually manage it by making the frontend replacable.
[00:34] <racarr> http://en.wikipedia.org/wiki/Circle-ellipse_problem
[00:34] <racarr> I wonder if mathematicians had understood ideas from software engineering if math would have been architected differently ;)
[00:34] <racarr> Hmm well
[00:34] <racarr> the frontend is replaceable right?
[00:34] <racarr> It's ust all or nothing
[00:34] <RAOF> Hm, *or* passing in a ProtocolExtension to the frontend, so when it discovers a message it doesn't know about it delegates.
[00:35] <racarr> its probably possible to use
[00:35] <racarr> template trickery, so that adding a new message is as easy as putting it in the wire protocol
[00:35] <racarr> and providing an impl on SessionMediator
[00:35] <racarr> or something
[00:35] <racarr> um
[00:36] <RAOF> Yeah, something like that would be good.
[00:36] <kgunn> thomi: excellent!....that does answer it
[00:36] <racarr> It worries me a little at first response
[00:37] <RAOF> It's insane that the first thing that anyone does when trying to solve discrete problems is go "hm, is this sufficiently well approximated by an uncountably infinite set full of uncomputable numbers?"
[00:37] <racarr> does it complicate our wire versioning situation, etc...
[00:37] <kgunn> weird about those repeated reportings
[00:37] <thomi> yeah
[00:37] <racarr> RAOF: Haha, right, and that's what I mean by the misguided aesthetic
[00:37] <racarr> because before incompleteness results, people thought mathematics was just one single
[00:37] <racarr> totally complete and consistent system
[00:37] <racarr> so why not do that
[00:37] <racarr> so that was seen as like
[00:37] <racarr> elegant
[00:38] <RAOF> Protocol versioning: hm, maybe?
[00:38] <RAOF> The problem would come in when calls migrate from extension to core or visa-versa, right?
[00:39] <RAOF> We'd also need extensions to be versioned.
[00:39] <smspillaz> whatever you do
[00:39] <smspillaz> don't autogenerate
[00:39] <smspillaz> bindings from the protocol
[00:40] <kdub> hah :)
[00:40] <smspillaz> at least, don't make them inline
[00:40] <smspillaz> the crap I had to do in order to dlopen wayland-client and use it
[00:40] <smspillaz> was not fun
[00:41] <racarr> RAOF: Well, or just when, one mir supports protocol version 7 with unity extension version 8 that was backported to ubuntu 15.04 but the version in 15.10 supports protocol version 7 with unity version 9 + unity fixes version 2 and the 16.04 daily...
[00:41] <racarr> haha :p
[00:41] <racarr> we want to avoid that I think
[00:42] <smspillaz> the way wayland does it is ok
[00:42] <smspillaz> basically, if the client doesnt support some protocol
[00:42] <smspillaz> then the server doesnt send it events that match that protocl
[00:42] <smspillaz> and ignores requests from that protocol
[00:42] <smspillaz> (version)
[00:43] <racarr> Mm
[00:43] <racarr> the thing is, these methods aren't in the client library I guess or they would be int he real protocol
[00:43] <racarr> our client library doesn't present an abstraction of like
[00:43] <racarr> message
[00:43] <racarr> in the same way wayland does
[00:43] <racarr> maybe it should *shrug*
[00:46] <RAOF> You just need similar extension support in the client library.
[00:46] <RAOF> "just" ☺
[00:49] <racarr> right but I think to model that extension support
[00:49] <racarr> the client library first has to like
[00:49] <racarr> talk in terms of messages/protocol or something
[00:49] <racarr> which it entirely hides now
[00:52] <RAOF> Right. It could, however, export some of that, without exposing it to the C layer.
[00:52] <RAOF> mir_extension_register(mir_my_extension)
[00:53] <RAOF> mir_extension_foo_get() returns an opaque pointer to the C++ implementation bits needed to do the dispatch?
[00:57] <racarr> are all the combinations
[00:57] <racarr> of extensions sorted in to
[00:57] <racarr> 1 set of extensions used by USC
[00:57] <racarr> cients
[00:57] <racarr> 2. 1 set of extensions used by unity clients
[00:58] <racarr> in this case maybe its just libmirclient-system libmirclient-client, or its just libmiclient that has all of 1 but there are permissions and
[00:58] <racarr> platform-api exposes the rest
[00:58] <racarr> or....
[00:58] <racarr> why do I use "or...." in place of "."
[01:07] <racarr> Off to berkeley!
[01:07] <racarr> You can follow live (with 168 hour delay) at http://archive.org/details/StuAllenAndMarsHotel2013-07-17.flac16
[01:07] <racarr> :p
[01:12] <RAOF> With 168 hour delay?
[01:12] <RAOF> That's some serious "live" :)
[01:12] <RAOF> Have fun in Berkeley!
[01:19] <smspillaz> have fun racarr :)
[02:10] <RAOF> Yes!
[02:10]  * RAOF wins.
[02:10] <RAOF> Nothing wrong with xmir, Mir really is displaying frame N-1.
[02:13] <duflu> RAOF: \o/
[02:14] <duflu>  /o\
[02:14] <duflu> RAOF: If the surface has swapinterval=0 then Mir will use triple buffering on it
[02:15] <RAOF> It's not; this is simple double buffering.
[02:15] <duflu> Oh
[02:15] <duflu> RAOF: So the client says here's one new frame and the compositor still could delay indefinitely?
[02:16] <RAOF> The client says "here's one new frame" and the compositor says "thanks, I'll composite frame N-1 for you"
[02:16] <duflu> RAOF: Heh. Actually that's something I just rewrote and we're arguing in email. More work to come
[02:17] <RAOF> ...
[02:17] <RAOF> Client sub buffer{3}
[02:17] <RAOF> Client acquired buffer{4}
[02:17] <RAOF> Compositor acquired buffer{3}
[02:17] <RAOF> Compositing buffer{3}
[02:17] <RAOF> Client sub buffer{4}
[02:17] <RAOF> Compositor released buffer{3}
[02:17] <RAOF> ...
[02:17]  * duflu admires typing speed ;)
[02:17] <RAOF> ...
[02:17] <RAOF> Client acquired buffer{3}
[02:17] <RAOF> Client sub buffer{3}
[02:17] <RAOF> Compositor acquired buffer{4}
[02:17] <RAOF> Compositing buffer{4}
[02:17] <RAOF> Compositor released buffer{4}
[02:17] <RAOF> Client acquired buffer{4}
[02:17] <RAOF> Client sub buffer{4}
[02:17] <RAOF> Compositor acquired buffer{3}
[02:17] <RAOF> Compositing buffer{3}
[02:17] <RAOF> Compositor released buffer{3}
[02:17] <RAOF> ...
[02:18] <RAOF> At some point in this log we start compositing the N-1'th buffer submitted by the client, rather than the last one.
[02:18] <duflu> RAOF: Yes, it's cos the compositor chooses the front of the queue (oldest frame) even when there might be newer ones ready behind it
[02:18] <duflu> That's related to my current work
[02:19] <RAOF> This is actually a bit worse than that; the compositor is compositing using the buffer that the client currently owns.
[02:19] <RAOF> Oh, no it's not. Carry on.
[02:19] <duflu> RAOF: Also related. I now make that impossible
[02:19] <RAOF> Sweet.
[02:20] <duflu> Although there's a risk that you block the compositor, which needs to be eliminated
[02:20] <RAOF> Yes
[02:21] <duflu> RAOF: That's why I was confused. The lag should be impossible if nbuffers=2, unless the compositor is showing a buffer currently held by the client
[02:22] <duflu> Hmm, maybe there's a third possibility
[02:23] <duflu> RAOF: I will reconsider the issues you describe today and maybe give you a branch to try... ?
[02:24] <RAOF> That would be excellent.
[02:38] <robert_ancell> RAOF, we need a way to counter u-s-c being installed, but X not supporting Mir. LightDM can't easily tell this without trying to run X with -mir and reading the stderr error messages, so perhaps we can do it better. Can we make the patched X package provide something like xorg-server-xmir and then have u-s-c depend on that?
[02:38] <RAOF> robert_ancell: Yes.
[02:39] <RAOF> robert_ancell: We could even go so far as to split libxmir.so into xserver-xorg-xmir, so the core server doesn't gain Mir dependencies.
[02:39] <robert_ancell> RAOF, that would be even better!
[02:40] <robert_ancell> RAOF, but the core package still needs the patch to have -mir etc right? Do we assume if you have xserver-xorg-xmir then the core package matches that?
[02:40] <robert_ancell> This is a Universe blocker (apparently) so we need to get it fixed asap
[02:40] <RAOF> Ah, ok.
[02:40] <RAOF> Good. That's what I'll do after lunch, then!
[02:41] <robert_ancell> cool
[02:54] <duflu> robert_ancell: Skype? Hangout?
[02:54] <robert_ancell> duflu, hangout is best
[02:55] <duflu> Not for my earphone comfort :)
[03:48] <duflu> Woo, a day of fixing conflicts :/
[03:48] <robert_ancell> RAOF, does the N-1 you mention in bug 1199450 accumulate over time? i.e. so you end up with N-M
[03:49] <RAOF> robert_ancell: No, because there are only 2 buffers.
[03:49] <robert_ancell> ok, that's better :)
[03:49] <RAOF> Possibly if we were triple-buffering then you could get 2 buffers behind?
[03:49] <RAOF> Not really.
[03:49] <duflu> That's weird. bzr is giving lots of conflicts that really are not
[03:49] <RAOF> Although I guess that *most* people have something change on the screen reasonably frequently.
[03:50] <duflu> RAOF: Keep glxgears running in the corner :)
[03:50] <RAOF> But if you have just an xterm on the screen you'll forever be one-character behind.
[03:52] <duflu> Alternatively, keep a browser open with lots of ads. That's always a big contributor
[04:46] <robert_ancell> RAOF, any update on the X packaging?
[04:46] <RAOF> robert_ancell: Is now in mir-team/staging.
[04:47] <robert_ancell> RAOF, cool, what depends should I add to u-s-c, or have you already done that ;)
[04:47] <RAOF> Not yet.
[04:48] <robert_ancell> ok, I'll leave it with you then
[04:48] <RAOF> K.
[04:49] <RAOF> Ah. New xserver upload in saucy-proposed :/
[05:07] <RAOF> robert_ancell: https://code.launchpad.net/~raof/unity-system-compositor/debconfify/+merge/176858 enjoy.
[05:08] <robert_ancell> RAOF, odd branch name :)
[05:08] <RAOF> It accidentaly got pushed to the last branch I proposed ;)
[05:09] <robert_ancell> RAOF, I just realised strictly we don't need XMir to use the system compositor, but for current practical use case the dependency solves a bigger problem than this might cause
[05:09] <RAOF> Indeed, that was my thought too.
[05:10] <RAOF> Since there's currently nothing *but* XMir that can run in unity-system-compositor… ☺
[05:10] <robert_ancell> yep
[05:11] <robert_ancell> we'll blow that bridge up when we come to it
[05:11] <RAOF> Eh, when we get there we'll just drop the dep.
[05:13] <tvoss> good morning :)
[05:14] <RAOF> Hey ho.
[05:16] <tvoss> RAOF, hey there, how goes?
[05:20] <tvoss> RAOF, hey, did you see that the intel driver failed compiling in the staging ppa?
[05:20] <RAOF> Hm, no I didn't.
[05:20] <RAOF> I need to fix unrelated things in it anyway :)
[05:20] <tvoss> RAOF, ack
[05:28] <RAOF> tvoss: So, duflu was going to ping me with a branch that probably doesn't exhibit this behaviour.
[05:30] <tvoss> RAOF, okay, could you point me to the places in the code where you put the terminal outputs?
[05:31] <RAOF> tvoss: http://paste.ubuntu.com/5910065/ enjoy.
[05:32] <didrocks> RAOF: robert_ancell: excellent! this will be in today's build (I just rerun u-s-c)
[05:33] <didrocks> RAOF: robert_ancell: on a longer term, we can have a virtual package as well
[05:33] <RAOF> didrocks: On a longer term we'll want to just drop it; the system compositor doesn't really depend on anything being run inside it, any more than the Xserver depends on Unity.
[05:34] <didrocks> RAOF: hum, but something run X -mir, right?
[05:34] <RAOF> lightdm does, yes.
[05:34] <didrocks> but u-s-c add the -mir parameter? :)
[05:34] <RAOF> Actually, that's probably where the dependency should be, now that you mention it :)
[05:34] <didrocks> or it's lightdm?
[05:34] <RAOF> It's lightdm.
[05:34] <didrocks> ah…
[05:35] <didrocks> yeah, would be logical, not sure robert will be thrilled about it though :p
[05:35] <didrocks> anyway, we can figure about it later, the urgent part is covered
[05:56] <tvoss> greyback, ping
[06:02] <robert_ancell> RAOF, didrocks, but the problem is lightdm doesn't depend on u-s-c, because it runs fine without it
[06:03] <robert_ancell> it only depends on it when it's configured to use it, and that configuration is in the u-s-c package
[06:03] <robert_ancell> if we move that out to somewhere else, e.g. ubuntu-desktop then that would be the right place for the dependency
[06:48] <tvoss> alf__, ping
[06:48] <alf__> tvoss: pong
[06:58] <dholbach> good morning
[06:59] <duflu> RAOF: Try this out. Let me know if the lag is now fixed;  lp:~vanvugt/mir/switch
[07:02] <duflu> Morning dholbach
[07:03] <RAOF> duflu: Ta.
[07:04] <dholbach> hey duflu
[07:04] <dholbach> how are you all doing?
[07:04]  * dholbach hugs duflu, RAOF and the rest of the gang
[07:04] <RAOF> Hey duflu!
[07:05] <RAOF> Or even - hey dholbach!
[07:07] <dholbach> :)
[07:11] <tvoss> dholbach, berlin calling @fb?
[07:24] <dholbach> tvoss, yep :)
[07:37] <greyback> tvoss: pong
[08:01] <tvoss> didrocks, ping
[08:01] <didrocks> tvoss: pong
[08:02] <didrocks> on 3G
[08:02] <tvoss> didrocks, ack
[08:12] <robert_ancell> hikiko, can you do an earlier 1-1?
[08:13] <hikiko> sure robert_ancell
[08:13] <hikiko> do you want me to join now?
[08:27] <RAOF> duflu: Looks like that doesn't have the delay problem.
[08:28] <RAOF> duflu: It looks like it's triple buffering, though?
[08:28] <RAOF> tvoss: ^^^
[08:28] <duflu> RAOF: Good start, but can you be sure? And yes, I default to triple because bypass will need it
[08:29] <duflu> Also, frame-dropping is suboptimal without triple
[08:30] <RAOF> duflu: Well, no I can't be sure.
[08:30] <duflu> Alright, but still, good
[08:30] <RAOF> But the workload which reliably caused the problem no longer causes the problem.
[08:44] <tvoss> RAOF, could you quickly run phoronix-test-suite run pts/gaming-free with duflu's branch?
[08:45] <duflu> tvoss: It's just buffering changes. Bypass is not in that branch. You know that?
[08:45] <RAOF> tvoss: I've been using the openarena timedemo to test; I can do phoronix-test-suite too, if you like.
[08:45] <tvoss> RAOF, would be cool, that was my test-case
[08:47] <tvoss> RAOF, also: pbuilder create complains about W: Failure trying to run: chroot /var/cache/pbuilder/build/28791/. mount -t proc proc /proc
[08:47] <tvoss> W: See /var/cache/pbuilder/build/28791/./debootstrap/debootstrap.log for details
[08:47] <tvoss> E: debootstrap failed
[08:47] <tvoss> W: Aborting with an error
[08:47] <tvoss> I have had that issue a million times, but never remember how to solve it
[08:48]  * RAOF uses sbuild
[08:48] <RAOF> Sorry!
[08:59] <tvoss> duflu, yup, know that. Just want to make sure that we put heavy load onto the system
[08:59] <duflu> OK. It's a little unusual for other people to load test a branch that's not even ready to propose :)
[09:06] <alf__> RAOF: Can you test the input delay with the current trunk with triple buffer enabled (change 2->3 src/server/compositor/swapper_factory.cpp line 47). It would be good to know if this is solved by triple buffering, or some other change in duflu's branch.
[09:06] <RAOF> alf__: Sure.
[09:06] <duflu> alf__: I expect triple will make it worse. I did an explicit fix for the lag bug today
[09:10] <tvoss> duflu, on the current design?
[09:11] <duflu> tvoss: Either. The higher the number of buffers, the worse the lag will be. The fix was not the number of buffers, but was to drop frames when more than one was queued for composition
[09:11] <tvoss> duflu, ack, mind pinging me the branch?
[09:12] <duflu> tvoss: r937 onward: https://code.launchpad.net/~vanvugt/mir/switch
[09:12] <tvoss> duflu, can we backport that to trunk right now?
[09:13] <duflu> tvoss: Possibly. Alf should have the know-how
[09:13] <tvoss> alf__, ^?
[09:14] <duflu> It's easy to drop excess frames. But you just have to remember to change how you throttle synchronous clients at the same time
[09:18] <alf__> duflu: tvoss: RAOF: ...but this changes our compositor to drop frames always. Is XMir sending frames that it then wants to cancel/override with new ones instead of having a steady sequential stream?
[09:19] <tvoss> alf__, duflu sounds like that should be controllable with a policy
[09:19] <RAOF> xmir doesn't expect frame dropping.
[09:21] <RAOF> If we're *getting* frame dropping then Mir's behaving unexpectedly.
[09:28] <RAOF> Man, pts/gaming-free takes *some time* to download.
[09:30] <alf__> RAOF: We are not dropping frames normally. However the proposed solution involves dropping all frames but the latest, if understood it correctly. So if the compositor's queue contains CBA with C being the latest, with the proposed change mir drops B,A and gets directly to C. I don't know what's causing the problem really, but this feels like dealing with the symptom.
[09:32] <tvoss> alf__, the trigger is this bug: https://bugs.launchpad.net/mir/+bug/1199450
[09:33] <RAOF> alf__: I'm not sure how the compositor's queue ever gets more than one buffer in it?
[09:33] <RAOF> alf__: Because we're double buffering by default, and the client always has a buffer...
[09:34] <RAOF> And a buffer that the client has can't be in the compositor's queue.
[09:34] <RAOF> So, by my understanding, there can be at most one buffer in the compositor queue.
[09:37] <duflu> RAOF: Yeah like I said yesterday - the bug should be impossible with nbuffers=2 in theory
[09:37] <RAOF> But in practise it's quite easy to trigger :)
[09:37] <duflu> Oh universe, how you deceive us all
[09:38] <duflu> RAOF: Impossible if nbuffers=2 and they're being alternated fairly/evenly ;)
[09:39] <duflu> I wonder if I will get to cook real food or spend another evening hacking :/
[09:40]  * duflu finds middle ground and makes evening coffee
[09:40]  * RAOF finishes dinner and goes to clean up.
[09:40] <RAOF> Night all!
[09:41] <tvoss> RAOF, night all :) talk to you tomorrow
[09:41] <alf__> RAOF: duflu: I think there can be two buffers if the client is slow. Good night :)
[09:42] <tvoss> alf__, can we easily switch to triple buffering on current trunk?
[09:42] <duflu> Last I checked, it was a trivial 1 character change
[09:42] <duflu> Night RAOF
[09:42] <alf__> tvoss: yes, but we need to prove that this will help
[09:43] <tvoss> alf__, happy to do so ... just show me where
[09:43] <duflu> I think it would/should make it worse
[09:43] <tvoss> duflu, alf__ I'm happy to be the guinea pig here
[09:43] <duflu> tvoss: alf__ did... scroll back
[09:43] <alf__> tvoss: change 2->3 src/server/compositor/swapper_factory.cpp line 47
[09:43] <tvoss> alf__, thanks
[09:44] <tvoss> duflu, alf__ the good thing is: it is not subtle, but totally visible ;)
[09:46]  * tvoss is in love with sbuild
[10:27] <hikiko_> alf__, ping!
[10:57] <alf__> hikiko: pong
[10:58] <didrocks> tvoss: kgunn: FYI, I'm recopying the latest changes from RAOF to the daily-build-next ppa, we really need to be in distro ASAP…
[10:58] <hikiko> hi alf__ I was wondering about the internal clients
[10:59] <hikiko> and the internal display
[10:59] <didrocks> tvoss: kgunn: argh, his build failed on i386
[10:59] <tvoss> didrocks, ack, you referring to the xorg driver?
[11:00] <didrocks> (one test)
[11:00] <didrocks> tvoss: yeah, he changed the dep for mir
[11:00] <hikiko> I guess these should be initialized and live in the native platform, correct?
[11:00] <didrocks> but didn't copy in daily-build-next
[11:00] <didrocks> so we can't install mir anymore now in it
[11:00] <didrocks> tvoss: but anyway, one test failed from his xorg upload
[11:00] <tvoss> didrocks, hold on, cannot follow
[11:01] <tvoss> didrocks, did you just restart the build?
[11:01] <didrocks> tvoss: yeah
[11:01] <tvoss> didrocks, why is that? do you suspect a flaky builder?
[11:01] <didrocks> it seems to be a flacky xorg tests
[11:01] <didrocks> didn't fail on other archs
[11:02] <didrocks> and the diff is meaningless
[11:02] <didrocks> regarding to that failure
[11:02] <didrocks> then, if it pass, I'll copy to daily-build-next ppa
[11:02] <didrocks> as it's broken right now
[11:02] <didrocks> (u-s-c depends on a package that doesn't exist…)
[11:03] <tvoss> didrocks, ack ...
[11:03] <tvoss> didrocks, I'm testing the intel driver from staging manually now
[11:03] <tvoss> back in a few ... hopefully
[11:06] <alf__> hikiko: it could be that you can use the one returned by the native one, but I haven't really checked the details
[11:06] <alf__> hikiko: native one => native platform
[11:10] <tvoss_> alf__, okay, does not make it better with triple buffering
[11:11] <tvoss_> alf__, but it exposes some serious flickering
[11:11] <tvoss_> alf__, or better, occasional serious flcikering/hiccups
[11:12] <tvoss_> duflu, to test your branch: build and install, then rebuild of usc?
[11:13] <duflu> tvoss_: No sure about the context but it is a drop-in replacement for lp:mir
[11:13] <tvoss_> duflu, ack
[11:13] <duflu> And now it's late again
[11:13] <tvoss_> duflu, just sign off dude :)
[11:14] <duflu> Well, I had coffee instead of dinner. That was my first mistake
[11:14] <duflu> Going now
[11:26] <hikiko> alf__: that's what I thought I just wanted to check that my logic is correct
[11:26] <hikiko> thank you
[11:38] <tvoss_> didrocks, seems like the i386 build made it through :)
[11:38] <didrocks> tvoss_: yeah, just waiting a little bit before copying
[11:38] <tvoss_> didrocks, ack
[11:56] <tvoss> didrocks, ping
[11:56] <didrocks> tvoss: pong
[12:00] <tvoss> alf__, did you have a chance to look into the buffer issue?
[12:03] <tvoss> alf__, the buffers are overtaking each other sometimes
[13:35] <tvoss> mlankhorst, ping
[13:35] <mlankhorst> pong
[13:39] <tvoss> mlankhorst, hey there, we see an issue on ati with the following error message: [  2417.963] (II) UnloadModule: "radeon"
 [  2417.963] (EE) Screen(s) found, but none have a usable configuration.
[13:41] <mlankhorst> i'd need a full log for a picture.. plus dmesg if possible
[13:42] <tvoss> didrocks, ^
[13:42] <mlankhorst> and I'm just guessing it's a hybrid..
[13:42] <didrocks> mlankhorst: do you have access to the VPN?
[13:42] <didrocks> mlankhorst: would be easier to get what you want, you can poke that way
[13:42] <mlankhorst> meh lets see how to set that up again..
[13:48] <jibel> mlankhorst, dmesg http://paste.ubuntu.com/5911197/ , Xorg.log http://paste.ubuntu.com/5911199/
[13:49] <mlankhorst> [  2417.963] (EE) RADEON(0): [drm] failed to set drm interface version.
[13:49] <mlankhorst> shouldn't do that on xmir
[13:50] <tvoss> what about fbdevhw
[13:51] <mlankhorst> [  2417.963] (EE) Failed to load module "fbdevhw" (module does not exist, 0)
[13:51] <mlankhorst> eg harmless
[13:51] <mlankhorst> and it would have been disabled by xmir
[13:52] <tvoss> mlankhorst, what means shouldn't to that on xmir?
[13:52] <mlankhorst> the call that's failing shouldn't have been called at all..
[13:52] <tvoss> mlankhorst, ah, thanks :)
[13:53] <didrocks> tvoss: I think we have 2 issues
[13:53] <didrocks> tvoss: this call not be done
[13:53] <didrocks> tvoss: lightdm not retrying without the -mir option
[13:55] <tvoss> mlankhorst, can you gain any further insight from the pastebin'd logs?
[13:58] <mlankhorst> as I said, drm interface version call is failing, and that one should not be called at all with xorgMir..
[13:59] <tvoss> mlankhorst, okay, so we have the wrong driver in there
[14:00] <mlankhorst> meh what's the machine?
[14:01] <tvoss> didrocks, ^?
[14:01] <didrocks> tvoss: I checked, we have the same version than in the staging ppa
[14:01] <didrocks> tvoss: and it's the one installed
[14:01] <didrocks> is there any other one?
[14:02] <mlankhorst> so then it's calling drmSetInterfaceVersion in the ddx when it shouldn't..
[14:15] <tvoss> didrocks, seems like the ati driver from the staging ppa wasn't rebuild against the new xorg
[14:16] <tvoss> mlankhorst, ^, could that cause issues?
[14:17] <didrocks> tvoss: seeing the diff of xorg since yesterday, that doesn't cause an ABI break, right?
[14:17] <didrocks> tvoss: https://launchpadlibrarian.net/145833378/xorg-server_2%3A1.14.2-0ubuntu2%2Bxmir1_2%3A1.14.2-0ubuntu2%2Bxmir1.1.diff.gz
[14:21] <mlankhorst> tvoss: I already said what the issue is
[14:21] <mlankhorst> drmSetInterfaceVersion is called, and it shouldn't, you have the source so you should be able to say why..
[14:25] <tvoss> mlankhorst, I wonder why it ever worked then?
[14:30] <mlankhorst> there's no guarantee it did, tbh..
[14:37] <tvoss> mlankhorst, well, we have seen phoronix test suite running on ati
[14:39] <mlankhorst> sigh, have you tried removing the call or not
[14:44] <didrocks> tvoss: kgunn: on the "we stay in a broken (no ui) session story": https://bugs.launchpad.net/mir/+bug/1204936
[14:48] <didrocks> tvoss: kgunn: and bug #1204939
[14:48] <kgunn> didrocks: ack
[15:36] <didrocks1> tvoss: do you see anything weird in terms of versions: https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/label=autopilot-ati/618/artifact/results/sysinfo/dpkg-l.postsetup
[15:52] <tvoss> didrocks, can you do me a favor and try to install the system-compositor-testing ppa on the machine?
[15:52] <didrocks> tvoss: will be able to do that later on, I have an appointment, maybe sil2100 can help you? he should have access
[15:53] <tvoss> sil2100, ping
[15:53] <tvoss> didrocks, okay, no weird versions around
[15:53] <sil2100> tvoss: let me backlog and see what's what
[15:54] <tvoss> sil2100, ack
[15:54] <sil2100> tvoss: on what machine do you need it installed? ati?
[16:02] <tvoss> sil2100, ack
[16:02] <tvoss> sil2100, is there a monitor connected to the machine, or a kvm switch?
[16:22] <sil2100> tvoss: I only log there through ssh ;) That's all the access I have
[16:22] <tvoss> sil2100, where does the machine physically live?
[16:24] <sil2100> tvoss: not sure now, I would guess it's in Lexington? Let's ask the QA guys, one moment
[16:27] <sil2100> tvoss: yes, I was right, they're in the QA lab in Boston
[16:27] <sil2100> tvoss: so the QA guys should be able to physically access it and perform debugging
[16:33] <tvoss> sil2100, how is the machine called?
[16:35] <sil2100> tvoss: I know it by the name of dx-autopilot-ati
[20:02] <thomi> morning
[21:28] <racarr> I don't know what was up with feeling sick all night but feel excellent now :) almost done with surface configuration notification
[21:34] <thomi> racarr: how's that mir_stress bug?
[21:53] <racarr> thomi: The same...need to finish unblocking shell stuff first :)
[21:53] <racarr> OSK incoming :D
[21:55] <racarr> the osk needs to be able to hide/show over IPC
[21:55] <racarr> so do we add mir_surface_hide/mir_surface_show?
[21:55] <racarr> Is it a surface state
[21:55] <racarr> if it is, how is it different than minimized
[21:55] <racarr> (or the same question if it isn't)
[22:27] <racarr> http://www.kickstarter.com/projects/cradle-of-mir/the-cradle-of-mir-at-burning-man-2013-russian-team we are so popular
[22:27] <racarr> :p
[22:33] <racarr> Hide is the same as minimize
[22:33] <racarr> but show is not the same as restored
[22:52] <kdub> racarr, haha@ the kickstarter
[22:55] <kdub> downloading mir over bzr takes longer and longer as we get more revs
[22:55] <kdub> maybe i should upgrade my internet connection plan to accomodate :)
[22:59] <racarr> kdub: One day people will tell my story "He ventured to the desert to seek the cradle of mir. Witnesses report that after 3 days of meditation he stood and simply announced 'I have seen the scene graph', only to wander in to the desert and never be heard from again"
[22:59] <racarr> :p
[23:05] <racarr> hmm
[23:05] <racarr> I think I should have done the SurfaceConfigurator, with two methods...
[23:06] <racarr> i.e. configure_surface(surface, attrib, ref value)
[23:06] <racarr> and surface_configured(surface, attrib, value)
[23:06] <racarr> (ref requested_value in configure_surface) perhaps
[23:06] <racarr> I am thinking about, how the shell can implement the policy of minimized windows get hidden
[23:07] <racarr> and there is one place where the shell wants to say like, this window wants to be minimized, thats ok, or this window wants to be an overlay but thats prohibited
[23:08] <racarr> but this isn't where you want to actually implement your behavior (i.e. minimize the window at some point)
[23:08] <racarr> I think I dunno, it seems like you want to apply the behavior after you have actually called
[23:09] <racarr> msh::Surface::configure
[23:12] <racarr> Neither of these seem correct...so I start wondering if the shell should implement msh::Surface::configure


[00:00] <gsamfira> so for anyone that cares: http://blogs.msdn.com/b/looking_forward_microsoft__support_for_secure_shell_ssh1/archive/2015/06/02/managing-looking-forward-microsoft-support-for-secure-shell-ssh.aspx
[00:00] <gsamfira> still waiting for the announcement saying that windows is adopting the linux kernel
[00:09] <wallyworld> waigani: thanks for fixing maas bug, auto pilot guys will be happy
[00:10] <menn0> wallyworld: are you sure that not fixing bug 1457225 for 1.24 is a good idea?
[00:10] <mup> Bug #1457225: Upgrading from 1.20.9 to 1.23.3 works, but error: runner.go:219 exited "machiner": machine-0 failed to set status started: cannot set status of machine "0": not found or not alive <cts> <sts-stack> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1457225>
[00:10] <menn0> wallyworld: seems pretty serious
[00:11] <wallyworld> menn0: from what i'm told, not really reproducable so the plan is to include in a point release if needed
[00:12] <menn0> wallyworld: let me have a quick poke at it
[00:12] <wallyworld> ok, ty
[00:12] <menn0> wallyworld: i can guess what it is
[00:12] <waigani> wallyworld: welcome. I've put my notes on the wiki, so next time will be a bit quicker: https://github.com/juju/juju/wiki/Update-Launchpad-Dependency
[00:12] <wallyworld> waigani: ty
[00:12] <wallyworld> menn0: i haven't looked into the bug in detail, just going on conversations, so if you can guess, that would be good
[00:13] <menn0> wallyworld: ok
[00:50] <wallyworld> natefinch-afk: when you are around, can you look at this bug which arose with the move conf files from logs work? https://bugs.launchpad.net/juju-core/+bug/1461246
[00:50] <mup> Bug #1461246: UpgradeSuite.TestUpgradeStepsHostMachine consistently fails on utopic <blocker> <ci> <regression> <unit-tests> <utopic> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1461246>
[01:01] <mup> Bug #1461339 was opened: rsyslog on bootstrap node causing instability <juju-core:New> <https://launchpad.net/bugs/1461339>
[01:18] <natefinch> wallyworld: I'll TAL
[01:18] <wallyworld> ty
[01:19] <menn0> wallyworld: I have been unable to reproduce bug 1457225 and i've requested more information
[01:19] <mup> Bug #1457225: Upgrading from 1.20.9 to 1.23.3 works, but error: runner.go:219 exited "machiner": machine-0 failed to set status started: cannot set status
[01:19] <mup> of machine "0": not found or not alive <cts> <sts-stack> <upgrade-juju> <juju-core:Incomplete by menno.smits> <https://launchpad.net/bugs/1457225>
[01:19] <menn0> wallyworld: dropping it from 1.24 is probably ok
[01:19] <wallyworld> thanks menn0, that matches my understanding also
[01:19] <menn0> wallyworld: it's not what I thought it was at least. it looks like the upgrade started but never completed for some reason.
[01:19] <wallyworld> yeah
[01:19] <wallyworld> good to check though
[01:20] <anastasiamac> axw_: allowing only count for storage constraints is only applicable to storage-add hook tool, rite?
[01:20] <axw_> anastasiamac: correct. "juju storage add" should be able to do whatever
[01:20] <anastasiamac> axw_: tyvm :D
[01:20] <axw_> anastasiamac: "storage-add" should just take a name and optional count, and take the rest from constraints
[01:21] <menn0> natefinch: I believe that the failing upgrade test runs all the upgrade steps
[01:21] <menn0> natefinch: it probably doesn't need to
[01:21] <menn0> natefinch: it's an old one
[01:21] <natefinch> menn0: ahh interesting
[01:21] <menn0> natefinch: mocking out the actual running of the upgrade steps and just confirming that they would be run is probably enopugh
[01:22] <menn0> natefinch: the steps and upgrade running infrastructure is all tested comprehensively elsewhere
[01:22]  * menn0 has to go for a bit
[01:39] <wallyworld> sinzui: tell me i'm crazy - i run "juju get-env" and the output includes secrets. why shouldn't we be masking those out by default?
[01:49] <anastasiamac> wallyworld: :(
[01:49] <mup> Bug #1461342 was opened: unit storage add should only accept count as constraint <juju-core:New for anastasia-macmood> <juju-core 1.24:In Progress by anastasia-macmood> <https://launchpad.net/bugs/1461342>
[02:07] <natefinch> wallyworld: the two tests that are marked as failing pass just fine on my machine (and I'm on utopic).  That specific test, when I run it, just says it's skipping all the copying of files, because they don't exist. But on the CI machine, it says there's one there that it doesn't have permission to remove.  Seems like an environmental problem - there's a file in /var/log/juju/ that shouldn't exist.
[02:07] <natefinch> wallyworld: given that it's only failing on utopic makes me suspicious that it's just that CI machine that has the errant file lying around, since the code isn't any different for different series.
[02:08] <wallyworld> natefinch: that makes sense i think
[02:08] <wallyworld> maybe mark the bug with a comment
[02:08] <wallyworld> natefinch: also, i recall a change with "-" in the branch?
[02:09] <wallyworld> with rsyslog config?
[02:09] <wallyworld> i just saw this, could be related? http://pastebin.ubuntu.com/11533025/
[02:09] <wallyworld> seems there's an extra "-" in front of machine-1
[02:09] <natefinch> weird... might have been an errant typo
[02:10] <wallyworld> natefinch: also. maybe the upgrade step should just skip files it can't move? witha warning?
[02:10] <wallyworld> more robust that way
[02:10] <menn0> wallyworld, natefinch: i was going to say what wallyworld just said
[02:11] <menn0> you don't want an upgrade completely failing b/c of this
[02:11] <natefinch> wallyworld: yeah, that makes sense.  No need to kill the upgrade step.. the whole reason we're moving the files is so that if you blow away the folder, you don't mess up our config... but we don't really care if the old files are there anymore or not.
[02:11] <wallyworld> yep
[02:13] <natefinch> I'll make a PR
[02:15] <wallyworld> natefinch: https://bugs.launchpad.net/juju-core/+bug/1461354 - i'm working another bug atm, but for your day tomorrow, if i don't get to this - could you look at it from the perspective it could be caused by the "-" change?
[02:15] <mup> Bug #1461354: invalid tag and panic seen in state server logs <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1461354>
[02:16] <natefinch> wallyworld: absolutely... though I don't know what the "-" change is, but I can look for it.
[02:16] <natefinch> oh, actually, I know what you're talking about
[02:16] <wallyworld> natefinch: in the log move work - you change rsyslog config
[02:16] <wallyworld> sorry, didn't know how to explain :-)
[02:17] <natefinch> yeah yeah... I made the Namespace not include the - in the field, but added it to the logic of writing out instead
[02:17] <wallyworld> i may be jumping to conclusions
[02:17] <wallyworld> but seems like a reasonable place to start looking
[02:17] <natefinch> it does seem suspicious
[02:19] <mup> Bug #1461354 was opened: invalid tag and panic seen in state server logs <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1461354>
[02:27] <natefinch> OMG export_test is the worst
[02:41] <natefinch> is the bot broken?
[02:45] <natefinch> ahh maybe just slow
[02:48] <natefinch> maybe it's just the reviewboard integration that's broken
[02:49] <natefinch> wallyworld, menn0: care to do a very quick review on github? https://github.com/juju/juju/pull/2476
[02:49] <wallyworld> ok
[02:49] <mup> Bug #1461358 was opened: Resource tags should be periodically updated to reflect reality <storage> <juju-core:Triaged> <https://launchpad.net/bugs/1461358>
[02:54] <wallyworld> menn0: you and i obviously think simiarly
[02:55] <menn0> wallyworld: well in one case.
[02:55] <menn0> then I found all the trivial stuff and you found what could be actual problems :)
[02:55] <wallyworld> well, you saved me from the gc.IsNil things :-)
[02:56] <natefinch> So, I almost put a comment in the actual code about not using PatchValue.  I'm not embedding whatever base suite has that... adding it would run a ton more code for the tests for no reason, and would actually add more lines of code to the file.... all to avoid doing my own defer.
[02:58] <natefinch> As for warning.... I don't know?  I guess I assumed that if we don't care if the old file is there.... we don't care.  No need to warn.   Warn is  something I feel is like "this may indicate there's a problem you should look at" .... but a file we can't delete that we don't read or care about is not really a problem for Juju.
[02:58] <natefinch> I started to write it as Warning and then changed to Info.  I'm only like 40% committed to it though, so if you guys think warning is more appropriate, that's fine.
[02:59] <menn0> natefinch: that BaseSuite embeds CleanupSuite which has PatchValue
[02:59] <natefinch> menn0: weird, I swear I tried to type it in and it complained at me.  Maybe I typoed it,.
[03:03] <natefinch> menn0: so it does... my autocomplete was not finding it for some reason.
[03:05] <natefinch> menn0, wallyworld: Fixes ready, do you want me to make the log message Warning?
[03:06] <wallyworld> yes please
[03:06] <natefinch> ok
[03:10] <natefinch> updated: https://github.com/juju/juju/pull/2476
[03:13]  * thumper is getting pretty grumpy at all the intermittent failures with the bot
[03:19] <wallyworld> waigani: ocr? trivial one please for ci blocker http://reviews.vapour.ws/r/1843/
[03:21] <waigani> wallyworld: shipit
[03:21] <wallyworld> tyvm
[03:25] <thumper> YAY (NOT) new intermittent test failure:  filter_test.go:146:   s.assertAgentTerminates(c, f)
[03:25] <thumper> uniter/filter
[03:27] <wallyworld> thumper: you running vivid?
[03:28] <wallyworld> our tests on vivid are worse
[03:37] <mup> Bug #1461150 changed: lxc provisioning fails on joyent <blocker> <ci> <joyent-provider> <lxc> <regression> <juju-core 1.24:In Progress by wallyworld> <https://launchpad.net/bugs/1461150>
[03:37] <mup> Bug #1461246 changed: UpgradeSuite.TestUpgradeStepsHostMachine consistently fails on utopic <blocker> <ci> <regression> <unit-tests> <utopic> <juju-core 1.24:In Progress by natefinch> <https://launchpad.net/bugs/1461246>
[03:44] <natefinch> wallyworld, menn0: care to check my update?  https://github.com/juju/juju/pull/2476/files
[03:44] <wallyworld> ok
[03:45] <wallyworld> natefinch: +1
[03:45] <natefinch> awesome
[03:51] <wallyworld> axw_: you resources pr - the provisioner version bump - it should be ok with an older env, and upgrades should work too, from what i can tell. i think?
[03:53] <axw_> wallyworld: the provisioner has a bit of code that loops while it gets a NotImplemented error
[03:53] <axw_> so I think it should be fine
[03:53] <wallyworld> ok
[03:54] <thumper> wallyworld: no
[03:54] <thumper> wallyworld: and that failure is from the bot
[03:54] <wallyworld> ah ok
[03:57] <wallyworld> axw_: lgtm, love the deleted code, much cleaner
[03:57] <axw_> wallyworld: cool, thanks
[05:25] <mup> Bug #1461385 was opened: apiserver/instancepoller: data race in test <juju-core:Confirmed for dave-cheney> <https://launchpad.net/bugs/1461385>
[05:55] <mup> Bug #1461393 was opened: worker/deployer: multiple data races <juju-core:Confirmed for dave-cheney> <https://launchpad.net/bugs/1461393>
[07:38] <axw> wallyworld: https://github.com/axw/juju/blob/resource-tags-units-storagename-etc/environs/tags/tags.go
[07:38] <axw> wallyworld: quick look over please, it was missing in the diff before
[07:39] <wallyworld> ok
[07:39] <axw> overzealous .gitignore
[07:39] <wallyworld> axw: actually i did wonder about not seeing that file in the PR
[07:40] <wallyworld> axw: LGTM
[07:40] <axw> ta
[08:43] <fwereade> anyone here got a graph theory background?
[08:49] <anastasiamac> fwereade: the answer depends on why u r asking :D
[08:49] <fwereade> anastasiamac, I'm wondering if there's any literature I should look at regarding *potential* cycles
[08:50] <fwereade> anastasiamac, i.e. I have a graph built up from a bunnch of successor lists which do not always agree, and may thus imply cycles
[08:50] <fwereade> anastasiamac, I know that each node appears at most once in each successor list
[08:50] <Spads> fwereade: so you're looking to run Tarjan's algorithm on your data set?
[08:51] <fwereade> Spads, not quite
[08:51] <fwereade> Spads, I'm lookinng to determin whether a data set will produce the same tarjan sort for all possible extensions of the original data
[08:51] <Spads> ahhhh
[08:51] <fwereade> Spads, given that the inputs can change in somewhat restricted ways
[08:52] <fwereade> Spads, I thought I had something and, well, the failure rate  on a workload designed to trigger the problem is down from 1 in 10k to 1 in 2m
[08:52] <fwereade> Spads, which is sort of good
[08:53] <fwereade> Spads, but sorta implies that I've missed something subtle, hence wondering if anyone remembers any related literature or anything :)
[08:54] <Spads> fwereade: this is outside my two-decade-old memory of my discrete methods/graph theory classes.  Let me poke someone who may know
[08:54] <fwereade> Spads, tyvm
[08:55] <fwereade> Spads, no rush, I have a meeting in a moment anyway
[08:55] <Spads> fwereade: yeah, she may need to go dig a bit anyway
[08:55] <fwereade> Spads, cheers
[08:57] <Spads> fwereade: are your rules aware of the tarjan weights of the nodes they're connecting to?
[09:02] <dimitern> voidspace, it's just you and me today :)
[09:03] <fwereade> Spads, I'm not aware of any weighting here
[09:09] <dimitern> voidspace, ping
[09:10] <voidspace> dimitern: sorry
[09:10] <voidspace> dimitern: was helping wife with car!!
[09:10] <voidspace> dimitern: omw
[09:11] <dimitern> voidspace, np
[10:47] <rogpeppe> anyone know what the Settings.NoProxy value means in github.com/juju/utils/proxy ?
[11:38] <rogpeppe> evilnickveitch: here's as far as i've got so far: http://paste.ubuntu.com/11541062/
[11:38] <rogpeppe> evilnickveitch: i've got descriptions for everything now, at least
[11:45] <evilnickveitch> rogpeppe, that looks good - I will update the table in docs accordingly
[11:45] <rogpeppe> evilnickveitch: i could probably generate the table automatically from that table if you'd like - might save a bit of time
[11:45] <rogpeppe> s/from that table/from that data/
[11:47] <evilnickveitch> rogpeppe, if you want to give that a go, i'm not stopping you :) the markdown syntax for tables is pretty straightforward
[11:47] <rogpeppe> evilnickveitch: should only take a minute or two
[11:47] <rogpeppe> evilnickveitch: i'm just formalising the defaults
[11:48] <evilnickveitch> cool
[12:13] <wallyworld> jam: got time for a brief chat about spec?
[12:14] <rogpeppe> evilnickveitch: http://paste.ubuntu.com/11541625/
[12:14] <rogpeppe> evilnickveitch: gist.github.com doesn't like it though, so it may well be invalid md syntax
[12:15] <rogpeppe> evilnickveitch: i left deprecated entries in there - you'll probably want to separate them out
[12:16] <rogpeppe> evilnickveitch: this is better: https://gist.github.com/rogpeppe/c7ce1f02258a39898d37
[12:16] <jam> wallyworld: I'm meeting with alexis now, can I chat with you after 30min or so?
[12:16] <wallyworld> sure
[12:18] <rogpeppe> voidspace: i'm led to believe you might know something about  github.com/juju/utils/proxy ... is that true?
[12:18] <evilnickveitch> rogpeppe, yup, that will certainly do the job.  thanks!
[12:18] <rogpeppe> evilnickveitch: np
[12:19] <rogpeppe> evilnickveitch: let me fix those multi-line descriptions first
[12:20] <evilnickveitch> ok
[12:25] <rogpeppe> evilnickveitch: this is better: https://gist.github.com/rogpeppe/8015a6c7122c85878b43
[12:27] <evilnickveitch> rogpeppe, it is. I will get this added shortly
[12:27] <rogpeppe> evilnickveitch: it really needs default values for all the other rows too
[12:27] <evilnickveitch> yes. I am not sure they all have them
[12:27] <evilnickveitch> rogpeppe, AFAIR, some keys simply don't exist if they aren't specified
[12:28] <rogpeppe> evilnickveitch: yeah, but at least all bool vals should document what the default bool is
[12:28] <evilnickveitch> perhaps they should definitively say 'none' in that case
[12:29] <evilnickveitch> agreed
[12:29] <rogpeppe> evilnickveitch: FWIW this is the code i used to generate the table (and check consistency with the real code): http://play.golang.org/p/6ci9O6GOz3
[12:29] <evilnickveitch> rogpeppe, ok, thanks, i am sure that will be useful in the future too
[12:30] <rogpeppe> evilnickveitch: the stuff after the ///// comment was pasted directly from the juju-core config code
[12:41] <mup> Bug #1461529 was opened: juju upgrade-charm has no effect for subordinate charms <juju-core:New> <https://launchpad.net/bugs/1461529>
[12:45] <wwitzel3> ericsnow: ping
[12:48] <Syed_A> Hello Folks,
[12:49] <Syed_A> I am trying to deploy HA openstack keystone in 3 lxc nodes.
[12:49] <Syed_A> I am getting this error: ERROR: grp_ks_vips: id is already in use
[12:56] <voidspace> rogpeppe: I don't believe so, no
[12:56] <rogpeppe> voidspace: ok, thanks
[12:58] <voidspace> :-)
[12:58] <voidspace> sorry
[13:09] <mup> Bug #1461534 was opened: presence.$cmd {getLastError} taking 100ms <mongodb> <juju-core:Triaged> <https://launchpad.net/bugs/1461534>
[13:17] <sinzui> mgz: I was about to try a reboot from the horzon console
[13:17] <rogpeppe> evilnickveitch: this also adds information on which attributes are immutable: https://gist.github.com/rogpeppe/cff7976fbf56f135af4b
[13:18]  * sinzui can move two jobs to another slave
[13:19] <evilnickveitch> rogpeppe, ah, useful! We may need to coordinate with web design again before making the table any bigger - there is precious little width to display the current info!
[13:19] <rogpeppe> evilnickveitch: that's your domain :)
[13:20] <evilnickveitch> I wish it were! But it is my domain to ask the people who can fix it, at least
[13:35] <ericsnow> wwitzel3: pong
[13:35] <natefinch> Syed_A: not a lot of open stack experts on here... try #juju
[13:36] <wwitzel3> ericsnow: hey, want to pair up?
[13:36] <ericsnow> wwitzel3: yep
[13:41] <wwitzel3> ericsnow: going to moonstone now
[13:45] <wwitzel3> jam: ping, you still around?
[13:47] <jam> wwitzel3: I'm 45 minutes past needing to help my son with homework, so I have to pretend I'm not here, sorry
[13:47] <wwitzel3> jam: understand completely :)
[13:48] <perrito666> we could do cooperative help with the homework and get you back faster? :p
[13:54] <sinzui> natefinch: can you triage bug 1461339? I see several related bugs tagged “rsyslog”. This is also an older juju; the issue might be fixed in newer juju
[13:54] <mup> Bug #1461339: rsyslog on bootstrap node causing instability <logging> <rsyslog> <juju-core:New> <https://launchpad.net/bugs/1461339>
[13:57] <natefinch> sinzui: that sounds a lot like what happened a couple weeks ago with that big customer problem.  I definitely think it's something we should be looking into addressing.  This is really katco's dept though :)  I'm just a code monkey now ;)
[13:58] <sinzui> natefinch: If you feel it is still a real issue, then we now the issue medium, and if we want to fix it in 1.25, it is high
[13:58] <sinzui> thank you natefinch
[13:58] <katco> sinzui: tal
[13:58] <wallyworld> natefinch: you going to look at bug 1461354?
[13:59] <mup> Bug #1461354: debug-log EOF: invalid tag and panic seen in state server logs <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1461354>
[13:59] <wallyworld> katco: you saw the credentials one in our fix - it's a one liner
[13:59] <katco> wallyworld: eh? context pls! :)
[14:00] <wallyworld> the cloudsigma crednetials leak bug we talked about this m orning
[14:00] <wallyworld> it's a private bug on beta6 - a few hours ago they added a note to the bug
[14:00] <katco> wallyworld: ah no i haven't looked at that
[14:00] <wallyworld> we need to change one line of code to fix
[14:01] <katco> wallyworld: ok, it sounds like it's proposed?
[14:01] <wallyworld> proposed?
[14:01] <wallyworld> oh on rb?
[14:01] <katco> yeah
[14:02] <wallyworld> not that i can see
[14:02] <wallyworld> but i've been busy on other bugs and things sadly and it was past my official eod when i saw the comment and then i had soccer
[14:02] <katco> wallyworld: ah ok. we'll try and get it fixed
[14:02] <wallyworld> ty :-)
[14:02] <wallyworld> past midnight here
[14:03] <katco> wallyworld: yipes, gtb!
[14:03] <wallyworld> will do, sorry for not fixing, thought it best to nag you at this stage of the evening :-)
[14:03] <katco> wallyworld: definitely :)
[14:04] <katco> wallyworld: share the load
[14:04] <wallyworld> and the only other one is the critical debug log issue i discovered today
[14:04] <wallyworld> debug log entries from machines != 0 are busted
[14:04] <wallyworld> the logged tag seems to have an extra "-" prepended
[14:05] <wallyworld> might? be syslog related, not sure
[14:05] <natefinch> wallyworld: I think I know the exact problem
[14:05] <wallyworld> awesome :-) so a fix is on the way?
[14:05] <natefinch> wallyworld: yep
[14:05] <wallyworld> tyvm :-)
[14:06] <wallyworld> so we can get beta6 out today, yay
[14:09] <wwitzel3> cherylj: ping, need a review when you have a moment, http://reviews.vapour.ws/r/1798/
[14:18] <cherylj> wwitzel3: looking now, but I am not a graduated reviewer yet.
[14:24] <mup> Bug #1461561 was opened: juju run fails with "Permission denied (publickey)" on manual provider <intermittent-failure> <manual-provider> <run> <juju-core:Triaged> <https://launchpad.net/bugs/1461561>
[14:32] <wwitzel3> cherylj: thats ok, it will help get the ball rolling, thank you
[14:51] <natefinch> jw4: you around?
[14:51] <jw4> natefinch: indeed
[14:53] <natefinch> jw4: what's up with juju action not taking the -e <env> flag until after the subcommand?  It's different from every other command we have, where you can do "juju deploy -e <env> [charm]" for example, but for action it's juju action do -e <env> [action
[14:53] <jw4> natefinch: that's weird
[14:54] <jw4> natefinch: I suspect it's because all of our commands are subcommands, and we don't have any top level command code
[14:54] <jw4> natefinch: "bug"
[14:59] <perrito666> omg, how is it possible that the chrome hangouts plugin still does not accept multi account
[15:42] <natefinch> abentley: addressed your concerns.  Should be a pretty quick review.  https://code.launchpad.net/~natefinch/juju-ci-tools/logrot/+merge/259750/+index
[15:42] <abentley> natefinch: Thanks.  On the phone.
[15:42] <natefinch> abentley: np
[15:42] <rogpeppe> anyone know which commit fixed the second issue mentioned in this comment? https://bugs.launchpad.net/juju-core/+bug/1339770/comments/2
[15:42] <mup> Bug #1339770: Machines are killed if mongo fails <canonical-is> <landscape> <maas-provider> <juju-core:Fix Released by wallyworld> <juju-core 1.18:Won't Fix> <https://launchpad.net/bugs/1339770>
[15:56] <natefinch> man what I wouldn't give to have issues on github so when I fix a bug I don't have to go through and copy and paste all the bug data into the comments.
[16:01] <natefinch> ericsnow: reviewboard doesn't seem to be picking up commits to 1.24... can you investigate?
[16:01] <ericsnow> sure
[16:01] <natefinch> wallyworld: fix for your issue: https://github.com/juju/juju/pull/2483
[16:01] <ericsnow> natefinch: is your 1.24 up-to-date?
[16:02] <natefinch> ericsnow: ish?
[16:03] <natefinch> ericsnow: I think I updated yesterday
[16:07] <natefinch> cherylj: can you review this?  https://github.com/juju/juju/pull/2483   fixes a bug I introduced here: https://github.com/juju/juju/pull/2458/files#diff-29cf702f1f3ee55354dc999b19a2e391R208
[16:07] <natefinch> (very quick review)
[16:08] <cherylj> natefinch: yeah, I'm finishing up a review for wwitzel3, give me a couple minutes.
[16:14] <natefinch> cherylj: np, thanks
[16:15] <ericsnow> natefinch: re: reviewboard, I'm not seeing a problem
[16:15] <ericsnow> natefinch: was it a particular PR?
[16:16] <natefinch> ericsnow: oh, no, maybe something is just really slow... the review is posted now
[16:17] <ericsnow> natefinch: k
[16:17] <ericsnow> natefinch: yeah, looks like RB is a little slow right now
[16:17] <natefinch> (where really slow might be anything greater than my patience level of ~20 seconds ;)
[16:23] <abentley> natefinch: r=me.  Shall I merge it for you?
[16:25] <natefinch> abentley: yes please
[16:25] <natefinch> abentley: thanks for all the time you spent reviewing the code.
[16:26] <abentley> natefinch: You're welcome.  Thanks for your follow-through.
[16:45] <mup> Bug #1461605 was opened: juju action commands require -e in the "wrong" place <actions> <juju-core:New> <https://launchpad.net/bugs/1461605>
[16:57] <mgz_> gsamfira: bug 1455627
[16:57] <mup> Bug #1455627: TestAgentConnectionDelaysShutdownWithPing fails <ci> <intermittent-failure> <lxc> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1455627>
[16:58] <gsamfira> mgz_: ahh. Cool. This was the only test that sometimes failed against Go 1.4.2
[16:59] <gsamfira> mgz_: tested on windows and Ubuntu. The rest all passed
[17:00] <gsamfira> mgz_: also did a live test. Bootstrapped new env and deployed a noop charm
[17:01] <gsamfira> on windows and ubuntu
[17:01] <gsamfira> all worked fine
[17:01] <mgz_> cool
[17:02] <gsamfira> mgz_: it should probably be tested for a couple of weeks in the CI before trusting that all is well, but initial tests looked okay :)
[17:38] <rogpeppe> if anyone fancies a review, here's a change to environs/config that starts us down the road that will let us create sensible UI forms for environment config attributes: https://github.com/juju/juju/pull/2487
[18:38] <natefinch_> gah... dammit ubuntu... first my screen freezes, now I reboot and my mouse cursor is invisible
[18:41] <natefinch> at least reviewboard didn't drop all my comments on the floor... that's ncie
[18:43] <perrito666> natefinch: well if it makes you feel better, each time I use my kb after taking a bath 2 finger scroll goes crazy
[18:43] <natefinch> That sounds like a euphemism for something
[18:46] <natefinch> gsamfira: I'd like to see tests with multi-byte characters... I wonder if those "interleaved nulls" are really just UTF16 padding for ASCII characters.
[18:48] <perrito666> natefinch: that does not sound right at all
[19:03] <natefinch> btw, evidently this was just released: https://github.com/aws/aws-sdk-go
[19:04] <natefinch> "aws-sdk-go is the official AWS SDK for the Go programming language"
[19:04] <natefinch> currently at "developer preview release"
[19:05] <natefinch> https://aws.amazon.com/blogs/aws/developer-preview-of-aws-sdk-for-go-is-now-available/
[19:06] <perrito666> natefinch: that sounds a lot like alpha :p
[19:06] <natefinch> "we have moved our GitHub repository from the awslabs organization to aws/aws-sdk-go. This signifies that this SDK is no longer in an experimental state."
[19:06] <natefinch> *shrug*
[19:46] <natefinch> dammit git
[19:48] <perrito666> natefinch: dont complain or we will make youuse bzr
[19:50] <natefinch> somehow it thought my branch was missing a whole buttload of commits... so it wouldn't let me repush
[19:55] <perrito666> did you rebase?
[19:56] <natefinch> perrito666: yes, and this is what I got: https://github.com/juju/juju/pull/2483
[19:56] <natefinch> only the first and last commit are supposed to be there
[19:57] <perrito666> ah because rebasing usually results on you not being able to push your branch if you had before
[19:57] <natefinch> that's ok, I just made a new branch and cherry-picked the right commits: https://github.com/juju/juju/pull/2489
[19:57] <perrito666> taht makes no sense
[19:57] <perrito666> all the commits there (which are mine) are merged into 1.24
[19:58] <natefinch> cherylj: if you have a second, this is the same as the last one you reviewed, but with an added test.  http://reviews.vapour.ws/r/1855/diff/#   (the key to the test is the "" in NewRsyslogConfigWorker.... we have another test that does the same thing, but with a non-empty namespace, but no test with an empty one.
[19:58] <perrito666> natefinch: there, it is fine now
[19:59] <perrito666> seems like github was having a bad day
[19:59] <cherylj> natefinch: looking now.
[20:06] <natefinch> perrito666: not sure what "there" means... still looks wrong to me
[20:07] <perrito666> natefinch: odd, it looks ook to me
[20:07] <perrito666> hard refresh?
[20:08] <natefinch> been trying that
[20:08] <natefinch> even incognito says it's still wrong.  It's ok.
[20:08] <natefinch> that;s what the other PR is for.
[20:08] <natefinch> only took a second, it's just annoying.
[20:09] <perrito666> natefinch: ah I am an idiot, I was seeing the new one
[20:09] <natefinch> lol
[20:09] <perrito666> natefinch: also, there is an error in your rebase, perhaps a merge in the middle, you can see how one of your commits is at the beginning of the list and the other at the end
[20:10] <perrito666> in a proper rebase all your commits are at the end
[20:10] <natefinch> I just did git pull --rebase  *shrug*
[20:10] <perrito666> so do remember that for git there are the nodes and the tree all those commits are there because you are changing the shape of the tree for that branch
[20:10] <natefinch> I don't know why there were any commits at all, given that I was on my own damn branch
[20:11] <perrito666> you need to take it lightly :) come to spend a couple of weeks here where everything works like s**t and you will see git with a different eye
[20:11] <natefinch> lol
[20:16] <natefinch> pretty sure the average sound level at my house has increased by about 20 decibels per child
[21:22] <thumper> sinzui: ping
[21:22] <thumper> or abentley ?
[21:23] <abentley> thumper: pong
[21:23] <thumper> abentley: hey there
[21:24] <thumper> abentley: where are we on adding a CI test for race conditions?
[21:24] <abentley> thumper: It's there.
[21:24] <thumper> abentley: I don't see it in the emails
[21:24] <abentley> thumper: http://juju-ci.vapour.ws/job/run-unit-tests-race/
[21:25] <abentley> thumper: It is in the emails, under Failed non-voting tests.
[21:26] <thumper> abentley: ah, I see it now
[21:26] <thumper> thanks
[21:26] <thumper> hopefully we can make it voting next week
[21:27] <abentley> thumper: That would be great.
[22:25] <thumper> wallyworld: is the container provisioner fix being back ported?
[22:25] <thumper> wallyworld: it should be
[22:26] <wallyworld> thumper: sec
[22:28] <wallyworld> thumper: not backported to 1.22 (CI didn't show an issue like it did for 1.24) and we are about the put 1.22.5 in trusty. But, there will almost certainly be a 1.22. release and as soon as that milestone is created, it will be backported
[22:29]  * thumper nods
[22:29] <wallyworld> it only affects joyent
[22:33] <thumper> ?!
[22:33] <thumper> ah... no
[22:38]  * thumper has read the bug, and I see it has been fixed...
[22:38]  * thumper goes to make coffee
[23:49] <thumper> WTF? ...
[23:50] <thumper> ERROR while stopping machine agent: exec ["stop" "--system" "juju-agent-tim-testlocal"]: exit status 1 (stop: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist)
[23:51] <thumper> it did destroy the environment, but this is a bit worrying


[03:15] <sirajperson> hey all
[03:15] <sirajperson> I have been google'n crazy to try and get VT100 to work right from the vga of my server install
[03:16] <sirajperson> I have an script that I want to use shades of colors to display information, but cannot get the monitor to use a VT100 terminal
[03:16] <sirajperson> anyone have any idea how to get VT100 without installing X?
[05:11] <stlu> Hi Again
[05:12] <stlu> Re my DNS project: I have left the home router out of the picture, because I really don't know whats under the hood, and it doesnt allow user-configuration of its DNS service.
[05:12] <stlu> So heres what I have:
[05:13] <stlu> domain is "myroom"
[05:14] <stlu> I have a desktop unit "dell.myroom"
[05:14] <stlu> 3 laptops which I have now separated into 3 VLANs
[05:14] <stlu> ...instead of 1.
[05:15] <stlu> dns.vbox1.myroom ubuntu1.vbox1.myroom
[05:15] <stlu> dns.vbox2.myroom ubuntu2.vbox1.myroom
[05:16] <stlu> dns.vbox3.myroom ubuntu1.vbox3.myroom
[05:16] <stlu> And they are bridged networking.
[05:17] <stlu> Question: should I make records in "dell.myroom" for "vbox_.myroom" pointing down to "dns.vbox_.myroom"?
[05:18] <stlu> ...oh, the virtual DNSs are also routers/gateways for the vlan
[05:20] <stlu> so for vbox2 it would have a WAN of <IP_ADDRESS> <-- dns.vbox2.myroom --> <IP_ADDRESS> (the VLAN)
[05:23] <stlu> Therefore, I am thinking I should add to dell.myroom's DNS database: vbox1 as <IP_ADDRESS>, vbox2 as <IP_ADDRESS>, vbox3 as <IP_ADDRESS>
[05:23] <stlu> ...And that's with my intention to let them share record information.
[05:25] <stlu> ... to clarify the question: is the 4th DNS server nessesary for the transfer of records?
[08:18] <yolanda> jamespage, zul : https://code.launchpad.net/~yolanda.robla/cinder/autopkgtests/+merge/183394
[08:23] <jamespage> yolanda, merged - thanks!
[08:23] <yolanda> np
[09:10] <jamespage> zul, adam_g: https://code.launchpad.net/~james-page/horizon/refresh-static-assets-fix-type/+merge/183400
[11:09] <zul> jamespage:  North America is on vacation today but I +1ed the horizon merge
[11:09] <jamespage> zul, ta
[11:09] <jamespage> zul, thanks
[11:18] <Katafalkas> hey, why locale is broken on  every image i try ?  i start a fresh ubuntu1204 64bit image on amazon - on apt-get upgrade - locale is broken. I do exactly the same on DigitalOcean - again. fresh image - locale is broken.
[11:36] <stlu> hey, sorry to repeat myself - if DNS servers want to exchange records, do they need the IP  of each other, the URL, either, or both?
[11:36] <stlu> And, am I doint
[11:37] <stlu> am I thinking the wrong way if I feel the need to have another DNS server to help the other DNS servers to find each other by URL?
[11:37] <stlu> *
[11:39] <andol> stlu: Not sure I fully understand the question, but assuming we are talking about zonetransfers I'd say the most common scenarion is them knowing each others ip addresses
[11:49] <stlu> andol: ok thanks.  So then, through 3 different VLANs, all I have to do is make sure routing is set up, and each DNS server will just need the IP of the other two.
[11:49] <stlu> right?
[11:50] <stlu> I keep getting tripped up thinking that the heirarchy of URLs must be strictly followed by the DNS server.
[11:52] <stlu> but like, technically, this means I could have each DNS server with a master database for one other VLAN, or even have a tossup where each DNS server has records for any random set of IPS...
[11:54] <stlu> Ok then, so if the VLAN has a domain vbox3.myroom, and addresses x.vbox3.myroom, what conventionally does one do with that URL?  should it point to something or nothing?
[11:54] <andol> stlu: Well, exactly what info is needed where might depend of what dns server you are running, and in what way you want the update chain to happen
[11:55] <andol> stlu: Unless you have any other preferenses, just take a look at BIND, and some of the examples in its configuration, and see whatever works for you.
[11:55] <stlu> andol: I have 3 VLANs side-by-side, under a LAN.  I don't care how they transfer information, I just want to learn the conventions.
[11:57] <stlu> but I want one DNS for each VLAN, since the VLAN is inside virtualBox on a laptop, and not all 3 laptops will be on all the tim.
[11:57] <stlu> *time
[11:58] <RoyK> why not one or two common DNS servers?
[11:59]  * RoyK works at a college with 20+ VLANs and two DNS servers
[12:00] <stlu> I may not be using 'VLAN' as it is supposed to be used, but what I have is a couple VMs running under virtualbox, in a laptop.
[12:01] <RoyK> you should be able to route between them nevertheless
[12:01] <stlu> If I do a common DNS server, it would have to be on hardware that is on all the time...
[12:01] <RoyK> or run dns server on your laptop :P
[12:02] <stlu> RoyK: and when that laptop is  off, the other two laptops will have no DNS!
[12:03] <RoyK> stlu: just trying to be a bit practical here :)
[12:03] <RoyK> stlu: do you have an official domain? if so, the isp should give dns as a service free of charge
[12:03] <RoyK> or whoever sold you the domain
[12:04] <stlu> no, I'm extremely minimalistic here, my domain is .myroom, and  the laptops are in my room.
[12:05] <stlu> there is home ISP service, but it isn't relevant for my learning project - I don't even know if the home modem/router would share its DNS information for the wifi lan.
[12:05] <RoyK> stlu: hm... can you afford a raspberry pi?
[12:06] <stlu> RoyK: yes, I could.
[12:06] <RoyK> that'd be a neat "dedicated server" ;)
[12:07] <stlu> That's a great idea.  Then it would be on 24/7, and any of the VMs could reach it, regardless of the other laptops being on/off.
[12:08] <RoyK> stlu: mhm - doesn't cost much either
[12:11] <stlu> to the next question: what would be the convention if I had pc1.vbox3.myroom, pc2.vbox3.myroom, pc3.vbox3.myroom, all together, but I tried to connect to vbox3.myroom itself, what should that point to?
[12:12] <RoyK> what do you mean"point to"?
[12:12] <RoyK> the easiest would be to run virtualbox in bridged mode and put them all on the same IP network
[12:12] <stlu> could be many things, say I open a web browser, or "ping" it, or email<EMAIL_ADDRESS>or ssh, or whatever.
[12:13] <RoyK> stlu: are you using rfc1918 addresses on your laptop?
[12:13] <RoyK> stlu: just run ifconfig to check
[12:14] <stlu> rfc1918?
[12:14] <RoyK> just pastebin ifconfig output
[12:14] <stlu> umm, I'll explain again the network diagram:
[12:14] <RoyK> http://en.wikipedia.org/wiki/RFC1918#Private_IPv4_address_spaces
[12:15] <stlu> ah yes, absolutely
[12:15] <RoyK> and all clients on the same IP network?
[12:15] <stlu> all laptops are on the <IP_ADDRESS>/24 network for my wireless home internet.
[12:16] <RoyK> then they should be able to ping oneanother without issues
[12:16] <RoyK> same applies to any VMs on those
[12:16] <stlu> each laptop has a virtualbox internal-only network 192.168.{101,102,103}.0/24 and pc1 is the gateway.
[12:16] <RoyK> if you're not using bridged mode networking, the VMs won't be reachable
[12:16] <RoyK> ic
[12:17] <RoyK> better make the pi the gateway when you get it
[12:17] <RoyK> eh
[12:17] <RoyK> no
[12:17] <RoyK> sorry
[12:17] <stlu> but the DNS server doesn't necessarily *have to* have a record for the domain vbox3.myroom, but I could make it anything or nothing.  what is the convention?
[12:17] <stlu> Sorry I can't seem to phrase this question in a way that makes it obviously simple as it is.
[12:18] <stlu> I have *no* issues with pinging the systems, I just wonder about the convention for the over-riding domain that all the VMs are part of.
[12:19] <stlu> pc1.vbox3.myroom = VM PC#1
[12:19] <stlu> pc2.vbox3.myroom = VM PC #2
[12:19] <stlu> pc3.vbox3.myroom = VM PC#3
[12:19] <stlu> all the VMs now have a URL
[12:19] <stlu> My question is, this remains:
[12:20] <stlu> vbox3.myroom = ???
[12:20] <stlu> ...
[12:20] <stlu> and I realized I'd better change the pc numbering to avoid confusion...
[12:21] <stlu> pc1.vbox1.myroom, pc2.vbox1.myroom, pc3.vbox.myroom
[12:21] <stlu> pc4.vbox2.myroom, pc5.vbox2.myroom, pc6.vbox2.myroom
[12:22] <stlu> pc7.vbox3.myroom, pc8.vbox3.myroom, pc9.vbox3.myroom
[12:22] <stlu> there.
[12:23] <stlu> I have several ideas, but I don't know which is most conventional/correct.
[12:25] <stlu> I could make that domain point to the gateway pc, on it's "wan" interface, so a web brower, a ping, or an ssh connection would go to that pc
[12:26] <stlu> or I could just pick one of the VMs as a web server and set it to that, say pc8.vbox3.myroom = www.vbox3.myroom = vbox3.myroom
[12:27] <stlu> or I could point it to the laptop itself, but that seems to have little use, since the laptop's OS isn't supposed to be part of the project.
[12:27] <stlu> RoyK?
[12:28] <stlu> do you have any of your 20 VLANs with similar subdomains?
[12:32] <RoyK> stlu: back
[12:33] <RoyK> stlu: no, we don't mix network structure and dns
[12:33] <RoyK> not that it should be a problem
[12:37] <stlu> ok, so to pick on zkxs, for example, I see that his URL is ip68-14-174-230.ok.ok.cox.net
[12:37] <stlu> so there doesn't have to be any relationship between those subdomains, this is what you're saying?
[12:43] <stlu> Well then, it seems that some of the subdomains don't matter: http://pastebin.com/8G26bcvp
[12:44] <stlu> RoyK: so this is an example of proper conventions?  If it isn't related to network structure, what might they have been thinking when they made the subdomains ok, and ok.ok ?
[12:47] <stlu> Hmm, If I were in charge of that DNS, I'd want to change it to something more informative, like *.customers.cox.net
[12:50] <stlu> I just looked at my own URL, bas16-toronto12-1088897118.dsl.bell.ca
[12:50] <stlu> At least that makes a bit more sense.
[12:51] <stlu> I think that "dsl." is just a way to separate the customer records from other systems, like their routers and office machines and stuff.
[12:52] <shauno> ok.ok.cox.net may be a very poor example; that could easily be $city.$state.cox.net, and Oklahoma City, OK has thrown you off
[12:54] <stlu> frick, I'll bet you're right!
[12:56] <stlu> dangit, zkxs, why'd you have to live in Oklahoma, confusing my noob brain?
[12:57]  * stlu that IP is in Oklahoma
[12:57] <shauno> actually, I might be wrong, I see a friend in san diego has sd.sd.cox.net.  there goes my logic
[12:58] <stlu> ok, well maybe they have other gear there, like x.routers.ok.cox.net?
[12:58] <stlu> ok.ok is like "general.ok"
[12:58] <stlu> or "customers.ok"
[13:00] <stlu> so then, in conclusion, if my subdomains "vbox1", "vbox2" and "vbox3" just help me to remember which laptop (equiv. to the city/state idea) the VM resides, then it would be perfectly acceptable to leave no DNS record for them.
[13:10] <shauno> name hierarchies can have as much or little meaning as you like.  eg, we have a bunch of machines that are server.foo.corp.com because their dns is handled by a load-balancer, so we can just delegate foo.corp.com
[13:11] <shauno> on the other hand, www.corp.com and mail.corp.com don't need to be on the same subnet, planet, etc, despite being at the same level
[13:15] <stlu> I'm having fun pinging all over the place.
[13:16] <stlu> www.ok.cox.net actually points to something, while ok.cox.net is nothing.
[13:18] <stlu> and cox.net is the same IP as for www.cox.net, which make a bit of sense.
[13:18] <stlu> mail.cox.net is nothing.
[13:19] <stlu> www.ok.ok.cox.net is also nothing
[13:19] <RoyK> stlu: I don't there are much naming convensions - that is - I'd say there are about as many convensions as there are sysadmins
[13:20] <stlu> thank you RoyK.  I can say that knowing there aren't any conventions is probably just as important as knowing when there are conventions.
[13:23] <RoyK> stlu: there are always convensions, and always arguments between sysadmins etc about which is the best ;)
[13:23] <stlu> you know what I mean :P
[13:24] <stlu> There isn't a hard and fast rule that everyone is all trying to reach for... they have a few, and reasons to use whichever one they like best.
[13:27] <stlu> because no sysadmin who still has a job would decide to say, assign a dotted-trio IP address to his systems, because he has a good argument for it!  "I think 55.44.33 is  a much better way to address the database server!"
[13:30] <stlu> ... omg... apparently 55.44.33 is translated into <IP_ADDRESS>... why oh why??? I just wanted to pick something impossible...
[13:33] <stlu> WTF? $ ping 64.2316494
[13:33] <stlu> PING 64.2316494 (<IP_ADDRESS>) 56(84) bytes of data.
[13:34] <stlu> I'm going to beat my forehead upon the nearest durable wooden surface... brb
[13:35] <stlu> $ ping 642316494
[13:35] <stlu> PING 642316494 (<IP_ADDRESS>) 56(84) bytes of data.
[13:36] <Patrickdk_> heh? I name my servers 4digit numbers
[13:36] <Patrickdk_> have to patch syslog-ng to even allow that
[13:36] <Patrickdk_> it keeps thinking my server name is a date
[13:37] <stlu> Patrickdk: I pity the poor soul that has to take over your job after you retire...
[13:38] <Patrickdk_> me?
[13:38] <Patrickdk_> the numbers make perfect sense :)
[13:38] <Patrickdk_> better than naming them all after greek gods or something
[13:39] <yolanda> zul, jamespage https://code.launchpad.net/~yolanda.robla/neutron/autopkgtests/+merge/183451
[13:40] <stlu> Finally: $ ping 2648F8CE
[13:40] <stlu> ping: unknown host 2648F8CE
[13:42] <stlu> Patrickdk: Oh, i though you meant you gave your servers some perverted IP address like 12.34 with only four digits.
[13:42] <baswazz_> i have set 'hdparm -y /dev/sd[b-g] for almost 24 hours works fine, but when i remove the '# spindown_time = 60' in /etc/hdparm.conf nothing happens no spindown. And i did a reboot.
[13:42] <stlu> I guess a nuumeric hostname isn't such a bad thing.
[13:43] <stlu> Of course, it has to make me wrong again, 12.34 is translated to <IP_ADDRESS>....
[13:43] <Patrickdk_> makes it simple, 8001, 8002, 8003, would be 3 web servers :)
[13:43] <Patrickdk_> bet you can't think of the email servers name
[13:43] <stlu> 2501, 2502, 2503?
[13:44] <stlu> And FTP servers at 2101, 2102, 2103...?
[13:44] <Patrickdk_> well, try to stick to sftp
[13:44] <RoyK> stlu: root@francesco:~# ping 0x2648F8CE
[13:44] <RoyK> PING 0x2648F8CE (<IP_ADDRESS>) 56(84) bytes of data.
[13:44] <stlu> FUUUUUUUUUUUUUUUUUUUUUUUUUUU
[13:44] <sgran> machines with both smtp and ssh are 4701, 4702 ?
[13:45] <sgran> stlu: what's the problem?
[13:45] <Patrickdk_> sgran, no, wouldn't combine servers like that, too much security risk
[13:45] <stlu> RoyK: you didn't seriously do that just now.
[13:46] <RoyK> stlu: just had to try to ping a hex address ;)
[13:46] <sgran> it's just a number :)
[13:47] <RoyK> sgran: an ip address is just a 32bit unsigned number too ;)
[13:47] <sgran> that's what I mean
[13:47] <RoyK> :)
[13:47] <sgran> try 'ping 0'
[13:48] <sgran> these are valid, if thankfully uncommon, ways to express IP addresses
[13:48] <stlu> PING 0 (<IP_ADDRESS>) 56(84) bytes of data
[13:48] <stlu>  O.O
[13:49] <RoyK> :)
[13:50] <sgran> also ping<PHONE_NUMBER>
[13:51] <sgran> steve@gashuffer:~$ echo $(( (74 << 24 ) + (125 << 16) + (136 << 8) + 113 ))
[13:51] <sgran><PHONE_NUMBER>
[13:51] <sgran> steve@gashuffer:~$ ping<PHONE_NUMBER>
[13:51] <sgran> PING<PHONE_NUMBER> (<IP_ADDRESS>) 56(84) bytes of data.
[13:51] <highvoltage> heh, strange how chromium turns that in to 'localhost' and not '<IP_ADDRESS>'
[13:53] <stlu> $ ping 0x1000000111001110100000001011110
[13:53] <stlu> that doesnt work
[13:54] <RoyK> stlu: that's a rather large number :P
[13:54] <RoyK> 0x => hex
[13:54] <stlu> oh
[13:54] <stlu> I wanted to make it interpret as binary
[13:54] <RoyK> don't think you can do binary directly from the shell
[13:54] <baswazz_> anyone who can help me out?
[13:55] <sgran> my telepathy is not working
[13:55] <sgran> perhaps with more detail, I could answer that
[13:56] <RoyK> well http://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/numerical-constants.html
[13:57] <RoyK> stlu: ping $((2#1000000111001110100000001011110))
[14:00] <stlu> RoyK: PING<PHONE_NUMBER> (<IP_ADDRESS>) 56(84) bytes of data.
[14:00] <stlu> mind=blown
[14:01] <stlu> is the double parantheses needed because its a bash arithmetic expression?
[14:01] <stlu> *are the
[14:02] <sgran> yes
[14:02] <sgran> $(( )) is integer arithmetic
[14:02] <sgran> 2#1000000111001110100000001011110 is an input to that that returns<PHONE_NUMBER>
[14:03] <stlu> I'm learning sh syntax and my mentor gets pissed every time I learn a new 'bash-ism' as he calls it.
[14:03] <stlu> But he's old-school and I'm not.
[14:06] <sgran> $(( )) is POSIX
[14:14] <stlu> ahah! So I can flaunt my arithmetic in my old-school mentor's face!
[14:15] <stlu> Anyway, for some reason I cannot email myself at adam@1604548979
[14:16] <stlu> gmail doesn't waaaaaant it.
[14:17] <mardraum> well, it's not a valid email address.
[14:17] <mardraum> or are you still being cute?
[14:19] <stlu> I'm noob.  No time for cute.
[14:19] <mardraum> then read about DNS and particularly MX records
[14:19] <stlu> but if thats not valid, how come sending email to<EMAIL_ADDRESS>is?
[14:19] <mardraum> (if you care about smtp and not arithmetic)
[14:20] <RoyK> sgran: sure it's posix? it works with bash/zfs, but not with dash/tcsh
[14:20] <sgran> steve@gashuffer:~$ dash
[14:20] <sgran> $ echo $(( (74 << 24 ) + (125 << 16) + (136 << 8) + 113 ))
[14:20] <sgran><PHONE_NUMBER>
[14:20] <mardraum> email to bare IPs, never guaranteed to work no matter how you got to the IP
[14:20] <RoyK> sgran: # echo $((2#01000100101))
[14:20] <RoyK> dash: 1: arithmetic expression: expecting EOF: "2#01000100101"
[14:20] <sgran> stlu: a valid smtp hostname is not the same thing as a valid IP
[14:20] <stlu> mardraum: ok then, I had a false notion.  I tried again and it came back bad.
[14:21] <sgran> RoyK: oh, yes 2# is a bash extension
[14:35]  * stlu feels slightly offended being called 'cute'
[14:36] <Patrickdk_> you troll
[14:40] <jamespage> smb, any good with seccomp?
[14:40] <jamespage> bug 1219857
[14:41] <smb> jamespage, hm not very good...
[14:42] <smb> jamespage, is there more hints or maybe some apparmour log
[14:42] <jamespage> smb, other than:
[14:43] <jamespage> Sep  2 14:25:51 vsftpd-debug kernel: [   15.517149] type=1326 audit(1378131951.002:12): auid=4294967295 uid=65534 gid=65534 ses=4294967295 pid=1402 comm="vsftpd" sig=31 syscall=96 compat=0 ip=0x7fffacf79dff code=0x0
[14:44] <smb> jamespage, I would probably try my luck in #security but not sure how many US/CA folks are around
[15:54] <baswazz_> can anyone assist me with hdparm /etc/hdparm.conf is not working
[15:54] <baswazz_> when i use hdparm -y the drives go in sleep
[15:54] <baswazz_> but when i set it up in hdparm.conf nothing happen even after a reboot
[16:57] <cocoa117> i am running ubuntu 12.10 server on Xen platform, how can I tell if that is right? i got uname -a
[16:57] <cocoa117> Linux ABCD 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[16:59] <Patrickdk_> virtwhat
[17:00] <cocoa117> Patrickdk_, ?
[17:01] <Patrickdk_> heh?
[17:01] <Patrickdk_> you asked a question, I gave you an answer, and you ? me?
[17:01] <Patrickdk_> hmm, actually, maybe that isn't in ubuntu
[17:02] <cocoa117> Patrickdk_, not sure what you mean by virtwhat
[17:02] <Patrickdk_> oh, virt-what, in ubuntu
[17:02] <cocoa117> Patrickdk_, command not found
[17:02] <Patrickdk_> install it
[17:02] <Patrickdk_> always helps
[17:03] <cocoa117> oh, ok, i try
[17:04] <cocoa117> Patrickdk_, got it, Xen, many thanx
[17:06] <cocoa117> should the ubuntu 12.10 server have empty folder in /proc/xen?
[17:06] <cocoa117> i want to figure out if i am running xen-domu or xen-hvm
[17:07] <cocoa117> this applogic thing is hard to figure things out
[17:15] <Patrickdk_> don't look in /proc/ use /sys
[17:29] <cocoa117> Patrickdk_, does the independent_wallclock still exist in 12.10 xen pv domU?
[17:31] <RoyK> cocoa117: is this a vm you got from somewhere?
[17:31] <cocoa117> RoyK, yes, this is a VM
[17:31] <RoyK> cocoa117: from an isp etc?
[17:32] <cocoa117> that's right
[17:32] <cocoa117> RoyK, in fact, i am pretty sure it is a Xen domU
[17:33] <cocoa117> it just didn't show the normal info off it, and i can't solve the time issue
[17:33] <RoyK> cocoa117: I haven't seen virt-what miss yet
[17:34] <cocoa117> xen as the answer
[17:36] <RoyK> cocoa117: then what are you trying to sort out?
[17:38] <Patrickdk_> it's impossible to make the clock stable
[17:38] <Patrickdk_> it won't happen
[17:39] <Patrickdk_> independent wallclock just makes it a mess, unless the host has LOTS of free cpu cycles
[17:39]  * RoyK mutters something about NTP
[17:39] <Patrickdk_> ntp will help with independent wallclock, but still, you need enough cpu cycles, or it will giveup


[06:12] <Ubugtu> New bug: #80500 in xorg (main) "intel 965 G1 graphics controller blurs during feisty-desktop-i386 install" [Undecided,Needs info]  https://launchpad.net/bugs/80500
[10:35] <Ubugtu> New bug: #80653 in xserver-xorg-video-sisusb (main) "SiS driver don't seems to work after upgrade" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80653


[08:14] <bryce> http://www.phoronix.com/scan.php?page=article&item=ubuntu_gui_randr&num=1
[08:38] <tjaalton> sweet
[08:52] <bryce> hey, tjaalton I don't remember if I showed you this already - http://bryceharrington.org/files/bisect.html
[08:52] <bryce> (prototype)
[08:53] <tjaalton> mm, looks useful
[08:55] <bryce> yeah, in analyzing bug upstreaming, I've noticed that much of the time upstream asks the user to do a git bisect
[08:55] <bryce> the vast majority of our users will go %-} at that point
[08:56] <bryce> so this is intended to make git bisecting user friendly for them
[08:56] <bryce> I've got like 90% of the scripting done to generate that page, and to generate the packages
[08:56] <bryce> unfortunately ppa is proving to be uncooperative.
[08:57] <bryce> anyway, once it's online I hope this will become a useful tool for us
[08:58] <tjaalton> will you make the commit-id's as links to the git commit?
[08:58] <bryce> I've got it committed in with tormod's packaging tools - https://code.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools
[08:59] <bryce> sure - in fact I wanted to bring this to your attention to gather suggestions like that
[09:00] <bryce> also, to cut down on the number of packages, I'm only listing every 8th commit.  If you think it'd be better to list more (or less), that'd be good to know
[09:02] <tjaalton> so you'll plan on making a package for every visible commit?
[09:02] <bryce> at this point I'm thinking every 8th commit
[09:03] <tjaalton> but the page shows every commit?
[09:03] <bryce> no, there are 7 "hidden" commits between each line
[09:04] <tjaalton> ah ok
[09:04] <bryce> I guess that's not clear enough
[09:04] <tjaalton> in that case it's probably not worth it to make the visible ones as links
[09:04] <bryce> c.f. to http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-intel.git;a=shortlog
[09:05] <bryce> would it be better to have every single commit?  I worry it might be too much disk space in the ppa
[09:06] <tjaalton> probably not, but maybe have a way to show the hidden commits between packaged versions?
[09:07] <tjaalton> then it might be easier to find the broken commit
[09:07] <bryce> true
[09:07] <bryce> yeah I plan to apply hefty javascript on top to help hide unnecessary clutter
[09:07] <bryce> some day
[09:07] <tjaalton> :P
[09:08] <bryce> first I must bend PPA to my will
[09:08] <bryce> so far the only way I can get it to accept my packages is to up the epoch to 3:
[09:08] <bryce> it won't accept packages that are "older" than what's currently in main
[09:08] <bryce> which seems silly but anyway.
[09:16] <tjaalton> yeah
[09:22] <bryce> bleah, some day I need to go through and close out all those displayconfig-gtk bugs
[09:25] <bryce> seb128: btw, 203897/204447 has a fix that's ready to upload
[09:25] <seb128> bug #203897
[09:25] <ubotu> Launchpad bug 203897 in control-center "monitor resolution panel won't fit on 640x480 screen" [Medium,Fix committed] https://launchpad.net/bugs/203897
[09:25] <seb128> bug #204447
[09:25] <ubotu> Launchpad bug 204447 in gnome-control-center "Display capplet's border is too big" [Low,Fix committed] https://launchpad.net/bugs/204447
[09:29] <seb128> bryce: the current hardy version already has those no?
[09:30] <seb128> bryce: it didn't get autoclosing because the bug is on control-center instead of gnome-control-center which is the new naming
[09:31] <bryce> oh, ah
[09:31] <bryce> ok, then I'll close those two
[09:31] <seb128> bryce: anything else which was waiting for upload while I'm in a sponsoring sprint? ;-)
[09:32] <seb128> bryce: thanks
[09:34] <bryce> no, the only other one is bug 203612, but I think I can take care of that one myself now.
[09:34] <ubotu> Launchpad bug 203612 in displayconfig-gtk "Screens and Graphics menu item in wrong section" [Medium,Fix committed] https://launchpad.net/bugs/203612
[09:36] <bryce> oh, and I'm also waiting on feedback from you for 199960.  I can easily make a patch to check for Xgl if you like.
[09:36] <bryce> I've no problem telling Xgl users that they're smoking crack though.
[09:36] <seb128> well, what doesn't work on xgl?
[09:36] <seb128> shouldn't the gnome-desktop upload I sponsored yesterday which traps the xerror fix the crash there?
[09:37] <bryce> I gather xrandr 1.2 isn't implemented (properly?) on xgl
[09:37] <seb128> or that's another call having the issue?
[09:37] <bryce> yeah it may.  I suspect we now have some redundant checks going on
[09:38] <seb128> let's see if that does the trick
[09:38] <seb128> I'm not in a hurry to fix xgl anyway
[09:38] <seb128> that's an universe thing and not supported
[09:38] <bryce> heh, you seem to have about as high of an opinion of xgl as I
[09:38] <seb128> ;-)
[09:38] <seb128> the good thing is that many of those users reported that they removed xgl
[09:39] <bryce> yup
[09:39] <seb128> and that compiz still works correctly on normal xorg and aiglx
[09:51] <tjaalton> bryce: aren't you a core-dev now? use the power! :)
[09:52] <bryce> tjaalton: yeah like I said I think I can take care of it now ;-)
[09:52] <seb128> oh, you are?
[09:53] <seb128> congrats!
[09:53] <bryce> thanks :-)
[09:53] <tjaalton> bryce: also, since I've been slacking with sponsoring lately, you can upload intel/displayconfig-gtk etc you have pending :)
[09:55] <bryce> thanks I will, although the only remaining pending uploads had some problems in testing I need to look into
[09:59] <bryce> ok, night.
[09:59] <tjaalton> night
[09:59] <tjaalton> I'll upload nv later today
[12:41] <ubotu> New bug: #208224 in xorg-server (main) "[hardy] right ctrl key does nothing (french layout)" [Undecided,New] https://launchpad.net/bugs/208224
[13:07] <ubotu> New bug: #208193 in xorg-server (main) "ATI 9200 fast users switching" [Undecided,New] https://launchpad.net/bugs/208193
[14:20] <ubotu> New bug: #208259 in pm-utils (restricted) "Ubuntu 8.04 don't resume from hibernate with nvidia GPU's" [Undecided,New] https://launchpad.net/bugs/208259
[17:09] <ubotu> New bug: #208247 in linux-restricted-modules-2.6.24 (restricted) "nvidia-glx-new crashes when using rt kernel" [Undecided,Incomplete] https://launchpad.net/bugs/208247
[17:39] <bryce> ok well looks like ppa doesn't allow having multiple versions of a given package
[18:22] <ubotu> New bug: #208368 in linux-restricted-modules-2.6.24 (restricted) "fgl_glxgears crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/208368
[19:17] <ubotu> New bug: #208353 in xorg-server (main) "{xorg-driver-fglrx} where is it on Ubuntu Hardy Heron (pre-release)????" [Undecided,New] https://launchpad.net/bugs/208353
[19:46] <ubotu> New bug: #208438 in xkeyboard-config (main) "compose doesn't work in console, br-dvorak " [Undecided,New] https://launchpad.net/bugs/208438
[21:36] <ubotu> New bug: #208486 in xserver-xorg-video-intel (main) "brighness controll with x3100" [Undecided,New] https://launchpad.net/bugs/208486
[21:39] <tjaalton> bryce: yep, they should be hosted somewhere else
[21:44] <bryce> yeah I'm setting up builds locally and will push to my people.ubuntu.com account.  *shrug*
[21:44] <bryce> I think if I push only the debs, and don't put up debug packages, it shouldn't occupy too much space