[12:22] <zelrik>  hello 
[01:12] <BenC> mjg59: ping
[01:20] <mjg59> BenC: Hi
[01:20] <BenC> mjg59: You seem to be the right guy to talk to about usplash_write :)
[01:21] <BenC> mjg59: I have a script that is using INPUTENTER, and the second call doesn't seem to wait for an enter key...any ideas?
[01:21] <mjg59> I didn't write that code, I'm afraid
[01:22] <BenC> Ah, then the manpage is misleading
[01:22] <BenC> or maybe you're the author of the manpage
[01:22] <mjg59> Oh, I wrote the rest of it
[01:22] <mjg59> Just not the input stuff
[01:22] <BenC> ah
[01:59] <mdz> BenC__: I'm sure I"ve asked this before, but I don't remember...can I use either of the sets of prebuilt vmware modules with VMWare workstation?  if so, which one?  if not, what's my alternative?
[02:00] <lifeless> its the same modules for both workstation and server no ?
[02:00] <BenC__> mdz: Either -player or -server should work with workstation
[02:01] <mdz> BenC: I have the server modules installed, but can't get workstation to run
[02:01] <BenC> mdz: It's not simple getting it to use them though
[02:01] <mdz> vmware-config.pl tries to build the modules and fails (they don't compile)
[02:01] <BenC> mdz: is this workstation 5 or beta6?
[02:02] <mdz> BenC: 5
[02:02] <mdz> is it easier with 6?
[02:02] <BenC> mdz: No, but I have beta6 tarballs that build
[02:02] <BenC> you can probably snag the tarballs in lrm and put them in /usr/local/lib/vmware/modules/source/
[02:02] <mdz> I only have a license for 5
[02:02] <mdz> maybe it's time to try kvm
[02:03] <BenC> grep vmx /proc/cpuinfo
[02:03] <BenC> if that doesn't show anything you might as well use qemu
[02:03] <mdz> it doesn't (this is an amd64)
[02:03] <BenC> Oh, I forget what the amd64 flag is
[02:04] <mdz> open /dev/kvm: No such file or directory
[02:04] <mdz> Could not initialize KVM, will disable KVM support
[02:04] <BenC> but "modprobe kvm-amd" should only work if you support it
[02:04] <BenC> you have to load the module manually
[02:04] <BenC> and you'll need to add yourself to the kvm group to access /dev/kvm
[02:05] <mdz> doesn't load, oh well
[02:08] <BenC> qemu works pretty well
[02:09] <BenC> not sure what you are using it for, but I used it for some install/kernel testing
[02:35] <BenC> usplash seems to be just dieing when I use INPUTENTER
[02:42] <BenC> mjg59: is there an easy way to test usplash from command line?
[03:03] <mjg59> BenC: Easiest is to ssh in
[03:32] <BenC> confirmed...using any sort of input junk just fucks usplash all up
[03:32] <BenC> if it doesn't crash immediate, it will shortly after
[03:39] <mjg59> BenC: Probably some buffer overrun in there
[03:39] <mjg59> BenC: Tried valgrinding it?
[03:40] <BenC> not yet
[03:40] <pkl_> mdz: BenC: the am64 VT flag is svm ...
[03:46] <BenC> mjg59: valgrind doesn't show anything useful
[03:47] <BenC> I think it might just be the fifo getting closed
[03:51] <BenC> mjg59: Found it...close(fifo_outfd) gets called when fifo_outfd isn't initialized to anything know
[03:51] <BenC> betting it's closing random fd's
[03:55] <mjg59> BenC: Oh, urgh.
[03:55] <mjg59> BenC: It's in bzr - feel free to commit a fix :)
[04:01] <TheMuso> c
[05:01] <BenC> lol
[05:01] <BenC> char inputbuf[PIPE_BUF] ;
[05:01] <BenC> free(inputbuf);
[05:05] <mjg59> Oops.
[05:08] <BenC> This thing is whacked...usplash_write "INPUTENTER ..." doesn't block, but usplash does until it gets input
[05:11] <kylem> heh.
[05:15] <BenC> the broken part is that the outfifo doesn't get anything when INPUTENTER is used
[05:25] <BenC> yay, it's working
[05:28] <BenC> three bugs in one function
[05:32] <BenC> mjg59: Got the bzr url for usplash?
[05:32] <mjg59> Not to hand
[05:32] <mjg59> It's on Launchpad
[05:39] <BenC> sweet, the fixes give me working usplash stuff for driver-updates
[05:42] <mjg59> Win
[07:01] <fabbione> BenC: still around?
[08:22] <mdz> BenC: it's in ~ubuntu-core-dev I believe
[07:18] <pwnguin> BenC: toshiba-acpi appears to be fixed now
[07:18] <BenC> pwnguin: excellent, thanks for checking it
[07:18] <pwnguin> BenC: ive also noted this on launchpad.
[07:19] <pwnguin> (and removed it from my laptop testing page)
[09:50] <zul> BenC: quintela the redhat guy is having a hell of a time port Xen to 2.6.20 fyi
[10:05] <zul> later
[10:30] <nemro> erm
[10:54] <_MMA_> BenC: Can you still use the -lowlatency kernels in Edgy?
[10:54] <BenC> _MMA_: Current kernels have problems with older hal
[10:54] <_MMA_> :(
[10:55] <BenC> you can use it, but some things stop working (like inserted a CD or usb-storage drive wont auto-mount)
[10:55] <_MMA_> Ok. Ill let them know.
[10:55] <_MMA_> I have someone who wants to try it.
[10:55] <BenC> you could pull in the newer hal with the rest of the deps that feisty kernel needs
[10:55] <_MMA_> Thanx.
[10:55] <_MMA_> Ok.
[10:56] <BenC> hal, udev, module-init-tools, initramfs-tools
[10:56] <BenC> that should cover it
[10:56] <_MMA_> It should just do it right? As a depend?
[10:56] <_MMA_> The update.
[10:56] <BenC> kernel doesn't depend on too many things like it's supposed to
[10:56] <_MMA_> Well it mess with a Edgy kernel?
[10:57] <BenC> I can conflict with older hal, but then it might cause older hal to get removed, so I don't do it
[10:57] <_MMA_> If they go back that is.
[10:57] <BenC> not sure
[10:57] <_MMA_> Ok.
[10:57] <BenC> actually it does a little
[10:57] <BenC> initramfs-tools wont generate initrd's for edgy kernels
[10:57] <_MMA_> hmm...
[10:58] <BenC> I should probably fix that, so that might not be true for feisty release
[10:58] <_MMA_> Ok. I have a guinea pig but this might deter them.
[11:12] <lifeless> isn't there a DRI ABI incompatability across edgy <-> feisty ?