[01:46] <DanaG> What's with all the 0x0f?
[01:49] <RAOF> Note to self:  When renaming LVM volumes, fstab is *not* the only place you need to change :)
[02:48] <AnRkey> can anyone tell me why Ubuntu uses dash instead of bash
[02:48] <RAOF> Because it's substantially faster.
[02:49] <RAOF> And anything which has a #!/bin/sh shebang line *should* run in dash as well as bash.
[02:50] <RAOF> Otherwise the script-writer is lying.
[02:50] <DanaG> Once I ran into an issue of dash not expanding wildcards: {} *
[02:50] <DanaG> A commandline:  cp *.{c,h}
[02:51] <DanaG> looked for a file literally named *.{c,h}, or rather \*.\{c\,h\} (or something like that)
[02:51] <RAOF> Woah, cool.
[02:51] <DanaG> It was under Make, and the failing command was cp.
[02:52] <crimsun> DanaG: that's not an "issue of dash" - that's a bashism.
[02:53] <crimsun> i.e., it's a bug that should be fixed either by explicitly using /bin/bash after the hash-bang, or by removing the {}s.
[02:53] <Enverex> No scripts I've ever found work in Dash, first thing I do when I get Ubuntu is switch it back to bash
[02:53] <crimsun> that's because people tend to be sloppy script writers.
[02:54] <crimsun> that's definitely not a dash issue; that's a lazy-human issue.
[02:54] <Enverex> VirtualBox, ATi drivers and I think the nVidia drivers too
[02:54] <DanaG> aah.
[02:55] <DanaG> But if you select "no" to using dpkg-reconfigure dash, what does it use?  Bash, or something else?
[02:55] <crimsun> dash is used for 1) faster boot, 2) testing shell script compliance
[02:55] <crimsun> the former is obviously (and trivially) more important
[02:56] <crimsun> zsh tends to be the "heaviest" in terms of memory footprint, but I find it hugely time-productive as a user shell.
[02:56] <crimsun> of course YMMV
[02:57] <RAOF> I should really learn zsh.  It seems awesome.
[02:58] <crimsun> it's sick what you can do with it
[02:59] <RAOF> I've watched jml do something like "grep foo **/*.py".  That's usefull :)
[03:01] <DanaG> what is **?
[03:01] <RAOF> I think it's "all subdirectories of this one"
[03:06] <crimsun> it's easier to simply pass -r to grep
[03:07] <RAOF> Yeah, the though did just occur to me
[03:11] <DanaG> hmm, http://www.dailytech.com/article.aspx?newsid=7510
[03:18] <Ashbringer> Hello, can I compile the kernel I fetch from git with the methods that I'd use to compile linux-source? I've tried a few times and it exits on a cryptic error.
[03:19] <Ashbringer> **make-kpkg exits, that is
[03:29] <crimsun> no, use the source package method.
[03:29] <crimsun> debian/rules.  Read it.
[03:32] <Ashbringer> Okay
[03:32] <Ashbringer> will that fix the compilation errors in ubuntu/ms/memstick.c?
[03:33] <crimsun> what?
[03:33] <crimsun> I need more details.  That's a contextless question.
[03:34] <Ashbringer> If I use that method, will ubuntu/ms/memstick.c not have a few pages of errors?
[03:34] <crimsun> I need to see the actual errors.
[03:34] <crimsun> We can't read minds here. :-)
[03:35] <Ashbringer> well
[03:35] <Ashbringer> I have probably between fifty to a hundred "derefrencing pointer to incomplete type"
[03:35] <RAOF> crimsun: You don't have a psychic pony?  Give me your address, I'll post you one.
[03:36] <crimsun> RAOF: I'm still awaiting the pony that bddebian promised me...
[03:36] <Ashbringer> hold on, lemme pastebin
[03:39] <DanaG> Oh yeah, what exactly is softmac?
[03:39] <crimsun> you can google that.
[03:40] <Ashbringer> http://paste.uni.cc/16082
[03:40] <Ashbringer> have fun with that
[03:41] <DanaG> Aah, not relevant for ipw3945.
[03:42] <Ashbringer> reactions?
[03:46] <Ashbringer> Also, what should I be reading in debian/rules?
[03:48] <RAOF> Ashbringer: My reaction is "memstick.h" should exist.  I don't know why it doesn't, though.
[03:48] <Ashbringer> Yeah, I was thinking the same thing
[03:49] <RAOF> Maybe the git kernel doesn't actually build at the moment?
[03:49] <Ashbringer> That's very irritating.
[03:50] <Ashbringer> What exactly would account for the abrupt disappearance of that file?
[03:50] <DanaG> Oh, where was the how-to of alsa-hg?  I don't want to recompile the kernel this time as I usually like to.
[03:53] <Ashbringer> So should this be posted to somewhere?
[03:53] <RAOF> That you can't build the kernel from git?  I wouldn't think so.
[03:54] <Ashbringer> Sarcasm, or will people just know?
[03:55] <RAOF> Not sarcasm.  I just don't really expect a non-released kernel to do anything good :)
[03:55] <Ashbringer> But it probably should
[03:56] <RAOF> Possibly one of the kernel team is hacking on stuff now?
[03:56] <Ashbringer> How would that account for a file not existing?
[03:56] <RAOF> If they're hacking on stuff by removing an ubuntu-specific patch?
[03:58] <Ashbringer> but it isn't a patch, its a file, and wouldn't they only push to the repo once they were done?
[03:58] <RAOF> Maybe.  Maybe they thought they were done.  Maybe it builds on their system.
[03:59] <Ashbringer> I kinda doubt it, the file isn't there and all of the implementation is based on it
[04:00] <RAOF> Maybe the implementation isn't built with their config?
[04:00] <RAOF> Why are you building from git anyway?
[04:00] <Ashbringer> I want the latest kernel
[04:00] <Ashbringer> While still being feisty
[04:00] <Hobbsee> twitch
[04:01] <Ashbringer> That, and I'm due for a recompile because I swapped out mobos and some of the buttons on my laptop now have lost functionality. I figure if a new kernel doesn't fix it, I should just send back the mobo.
[04:01] <RAOF> ...
[04:01] <Ashbringer> Don't *ever* buy HP.
[04:02] <DanaG> Note: you may have just been unlucky.
[04:02] <RAOF> Well... I'd try a non-git kernel before deciding that the *motherboard* is broken!
[04:02] <Ashbringer> No, I'm running on a binary from apt-get now
[04:02] <DanaG> I have a friend who has a MacBook, and has had to send it back 5 times for various issues.
[04:03] <Ashbringer> And I've tried kernels that I've compiled on my pre-mobo-swap lappy that have had the same issues. I'm starting to think it may in fact be the mobo again, but I just got this back and I'm not sure if I want to give it up for another two weeks.
[04:04] <DanaG> Hmm, try doing xev or showkey
[04:04] <Ashbringer> If I'm going to be compiliing a kernel, I want to compile a *new* kernel, not some outdated trash from apt. I've been doing this on and off all day, it may as well have a purpose.
[04:05] <Ashbringer> DanaG: the buttons in question are the screen brightness and two of the HP QuickLaunch buttons, they're not exactly standard
[04:05] <DanaG> Aah, well, brightness may be ACPI brightness.
[04:05] <DanaG> tail /var/log/acpid
[04:05] <DanaG> er, tail -f
[04:06] <Ashbringer> it says it completes everything
[04:06] <DanaG> Vista now mandates that manufacturers implement standard ACPI brightness controls.
[04:06] <Ashbringer> but my screen is still the same
[04:06] <DanaG> Do you see any "acpi video ...." lines?
[04:06] <Ashbringer> [Sun Jun  3 22:05:55 2007]  completed event "video LCD 00000087 00000000"
[04:06] <Ashbringer> [Sun Jun  3 22:05:55 2007]  received event "video LCD 00000087 00000000"
[04:06] <DanaG> So it IS getting the keys, then.
[04:07] <Ashbringer> Yeah, but the brightness is the same. Incidentally, nothing detects when I close the screen.
[04:07] <DanaG> hmm, try cat /proc/acpi/video/VGA/lcd/brightness
[04:07] <DanaG> or s/lcd/LCD/ or whatever is at that level.
[04:08] <Ashbringer> levels:  100 60 20 28 36 44 52 60 68 76 84 92 100
[04:08] <Ashbringer> current: 0
[04:08] <DanaG> And now there's backlight sysfs support ... /sys/class/backlight/ ....
[04:09] <DanaG> sudo -i to get a root shell, then echo -n some numbers to the brightness file.
[04:09] <DanaG> and look at what actual_brightness shows.
[04:10] <DanaG> Odd, my dmesg shows a bunch of  "set_level status: 0"
[04:10] <DanaG> I'd think that debug statement would've been disabled.
[04:12] <Ashbringer> I'd rather not screw with it right now
[04:12] <Ashbringer> I have a feeling its a hardware issue
[04:12] <Ashbringer> (I don't have my keyboard until an "Nvidia boot agent" crashes and grub loads)
[04:14] <DanaG> nvidia boot agent?  Oh, a SATA boot ROM.
[04:14] <DanaG> nForce.
[04:16] <Ashbringer> yup
[04:19] <RAOF> Hm.  Does anyone else find that using pulseaudio totally breaks volume control?
[04:28] <DanaG> s/no longer/dis/
[04:31] <Hobbsee> DanaG: you ever did?
[04:33] <DanaG> I had an nForce2 board and liked the low CPU usage of the MCP-T (even though I used the analog, and I now realize that the analog sucked).
[04:34] <DanaG> But then I ran into driver issues.
[04:36] <RAOF> Anyone else use pulseaudio here?
[04:36] <RAOF> I just want to eliminate PEBCAK before filing a bug :)
[04:38] <DanaG> Make sure the Gnome mixer is set to the hardware device, not pulseaudio.
[04:39] <RAOF> DanaG: Yup, done so.
[04:39] <RAOF> Tried *all* possible mixers, and "alsamixer"
[04:39] <DanaG> Odd.
[04:40] <RAOF> The mute works, but not the volume.
[06:09] <DanaG> Setting up automake (1:1.10+nogfdl-1) ...
[06:09] <DanaG> Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 602.
[06:11] <crimsun> ignore it
[06:19] <Paladine> anyone alive?
[06:24] <RAOF> Yeah.
[06:24] <Paladine> still having problems getting this nvidia module to load
[06:25] <Paladine> I can load it manually no problem, but it will not load automatically on boot
[06:25] <RAOF> You installed the nvidia.com drivers, right?
[06:25] <Paladine> yup
[06:25] <RAOF> And *don't* have linux-restricted-modules.
[06:26] <Paladine> nope
[06:26] <RAOF> And have run "sudo depmod -a" at some point in the last couple of reboots
[06:26] <Paladine> nope
[06:26] <RAOF> Maybe you should run that.  It might be what's preventing the kernel from autoloading your module.  Maybe.
[06:26] <Paladine> haven't come across that in any of the dozens of threads  I have read on the issue
[06:27] <Paladine> I will give it a try
[06:27] <Paladine> brb
[06:31] <Paladine> that fixed it thanks ROAF
[06:32] <RAOF> Bwa ha ha!
[06:32] <RAOF> You should probably tell the nvidia guys to fix their installer, then.
[06:32] <Paladine> trust it to be something simple
[06:32] <Paladine> yeah they should have done that in the installer
[06:33] <Paladine> would that fix it without having to remove linux-restricted-modules
[06:34] <RAOF> Well, you could just add DISABLED_MODULES="nv" to /etc/default/l-r-m-c, and it would, yes.
[06:35] <Paladine> yeah that explains why adding DISABLED_MODULES in feisty worked with the old drivers but not in gutsy with the new ones
[06:35] <Paladine> which was puzzling me :)
[06:35] <Paladine> thanks again man appreciated
[06:35] <RAOF> NP-complete!
[06:39] <Paladine> allowed me to help someone with the same problem on the forums too :)
[06:40] <RAOF> :)
[06:40] <Paladine> http://ubuntuforums.org/showthread.php?p=2777440#post2777440
[06:50] <DanaG> ALSA lib pcm.c:2019:(snd_pcm_open_conf) type is not defined
[06:50] <DanaG> arecord: main:545: audio open error: No such file or directory
[06:50] <DanaG> using alsa-hg.
[06:50] <DanaG> For alsa-lib and alsa-utils.
[06:54] <DanaG> Perhaps am I missing PREFIX= somewhere in ./hgcompile?
[06:58] <DanaG> Okay, so apparently I have missing symbols.
[07:01] <DanaG> ALSA lib simple_abst.c:81:(try_open) Unable to open library 'plugindir/smixer/smixer-hda.so'
[07:01] <DanaG> amixer: Mixer register error: No such device or address
[07:04] <DanaG> it seems to be alsa-lib that is broken.
[07:04] <RAOF> What does hgcompile do?
[07:04] <RAOF> Presumably it downloads the source with mercurial, then builds everything in the right order, with the right prefix (which should probably be /usr, for sanity and ease of breaking everything else)
[07:05] <DanaG> You have to have already downloaded the source.
[07:06] <RAOF> So it just builds everything?  That seems a little bit trivial for a script :)
[07:06] <RAOF> for I in alsa-base alsa-lib alsa-utils ; do cd $I && ./autogen.sh && etc
[07:06] <RAOF> :)
[07:06] <crimsun> DanaG doesn't read --help
[07:07] <crimsun> we no longer compile all pcm plugins by default
[07:07] <crimsun> (in hg)
[07:07] <crimsun> you need to specify them explicitly when using ./hgcompile or ./configure
[07:07] <DanaG> hgcompile has no --help, it seems.
[07:07] <crimsun> because it's just a wrapper around automake && autoconf
[07:08] <crimsun> ./configure --help  to see what's default now.
[07:08] <DanaG>   --with-pcm-plugins=<list>
[07:08] <DanaG>                           build PCM plugins (default = all)
[07:09] <DanaG> Nope, even if I explicitly specify all, I get the error.
[07:10] <DanaG> ALSA lib pcm.c:2019:(snd_pcm_open_conf) type is not defined
[07:10] <crimsun> what error?
[07:10] <crimsun> everytime you upgrade alsa-lib, you have to refresh your default conf
[07:11] <crimsun> e.g., remove /etc/asound.conf and ~/.asoundrc*
[07:11] <DanaG> Aah, I had a customized .asoundrc.
[07:13] <DanaG> Hmm, there's a new slider, "Digital", under capture.
[07:15] <DanaG> arecord -fS16_LE -r44100 -c2 -Dhw:0                gives
[07:15] <DanaG> Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
[07:15] <DanaG> RIFF$WAVEfmt Ddata
[07:15] <crimsun> -fcd is equivalent.
[07:16] <DanaG> No matter what format I use, I get that gobbledygook.
[07:16] <DanaG> 24/192, 24/96, 24/48, 16/...you get it.....
[07:17] <crimsun> "gobbledygook" being?
[07:18] <DanaG> The invalid characters.  It gives no more than those, and then quits with a read error after a while.
[07:18] <DanaG> Is there any way to shorten the paths given by the debug statements?   This looks rather long:
[07:18] <DanaG> [ 2430.528000]  ALSA /home/dana/downloads/alsa-hg/alsa-driver/pci/emu10k1/../../alsa-kernel/pci/emu10k1/io.c:222: Writing to ADC failed!
[07:18] <crimsun> why are you using hw: instead of plughw: anyhow?
[07:19] <crimsun> sure, pass the appropriate parameters to --configure
[07:19] <crimsun> not that it matters
[07:19] <DanaG> Even plughw gives the same.
[07:19] <crimsun> what are you concerned about, the charset?
[07:20] <DanaG> Oh, and the error arecord quits with: arecord: pcm_read:1349: read error: Input/output error
[07:20] <crimsun> I see no real error
[07:20] <DanaG> The redundant path bugs me, though I can just ignore it.
[07:20] <crimsun> that's impossible to diagnose without further info.  Right now you're giving me nothing.
[07:21] <DanaG> Hmm, what should I add?
[07:22] <crimsun> well, what do you want me to do?
[07:22] <crimsun> I can't guess what you're trying to accomplish or what you want me to help you with.
[07:23] <DanaG> I'm trying to get capture working on the STAC9250.
[07:24] <DanaG> Oh, one nice thing: the Audigy Notebook kernel oops seems to have been fixed!   Sweet.
[07:24] <crimsun> it does work.  Do you mean it's inaudible?
[07:24] <crimsun> Doesn't work-> possible hardware problem, possible pin misrouting, possible pin misinit, etc.
[07:25] <crimsun> Inaudible-> possible pin misrouting, possible pin misinit
[07:25] <crimsun> very big difference
[07:27] <DanaG> It seems to not give me anything -- pulseaudio meter shows nothing, and the command line arecord stalls and then aborts.
[07:27] <crimsun> strace -fF it.
[07:29] <crimsun> if you passed --with-debug=full --enable-verbose-printk to ./hgcompile for alsa-driver, you may have more in the kernel ring buffer
[07:29] <DanaG> I'm not sure if I did verbose-printk, but I did enable full debug.
[07:30] <DanaG> Last 2 lines of strace (after the RIFF ---- data  thingy):
[07:30] <DanaG> ioctl(4, 0x4142, 0)                     = 0
[07:30] <DanaG> poll(
[07:30] <crimsun> that's less than helpful without the rest of it.
[07:31] <DanaG> I'll pastebin it.
[07:32] <RAOF> Hm.  Killing pulseaudio fixes the mixer.  Restarting pulseaudio kills the mixer.  I'll call that a pulseaudio bug then.
[07:32] <crimsun> not necessarily, RAOF.
[07:32] <crimsun> pulseaudio does lock certain mixer elements.
[07:33] <DanaG> dmesg:    alsa-kernel/core/pcm_lib.c:2000: capture read error (DMA or IRQ trouble?)
[07:33] <crimsun> however, I have no idea what you mean by "kills the mixer".
[07:33] <crimsun> DanaG: have you _completely_ ruled out ACPI bugs?
[07:33] <crimsun> e.g., are you using a custom DSDT?
[07:33] <DanaG> Not completely.
[07:34] <DanaG> I'm no longer using a custom DSDT.  I also downgraded back to a pre-(broke Windows XP suspend) BIOS.
[07:34] <RAOF> crimsun: When pulseaudio is running, alsa's mixer doesn't work.  At all, as far as I can tell, it seems stuck on 100%.  Gnome's volume control doesn't change the output volume, no matter which mixer I select.  alsamixer doesn't change the volume.
[07:34] <crimsun> Ok, that last sentence is meaningless to me, but sure.
[07:35] <crimsun> RAOF: it certainly changes here.  Which elements seem nonresponsive with `alsamixer -c#' ?
[07:35] <DanaG> http://pastebin.ca/535796
[07:36] <crimsun> DanaG: that's not an alsa-lib issue for certain.
[07:36] <crimsun> DanaG: AFAICT, it's not alsa-{kernel,driver} either
[07:37] <DanaG> I fixed the -lib issue earlier -- that was the .asoundrc.
[07:37] <RAOF> crimsun: Everything except for the master mute button.
[07:38] <crimsun> RAOF: you haven't mentioned whether you're using an asoundrc and whether you've got gconf entries for gnome-volume-control
[07:38] <RAOF> crimsun: I just removed my asoundrc, since the DebuggingSound problem suggested it (because the volume control *does* still control the GDM screen drums)
[07:39] <crimsun> RAOF: gdm uses aplay.  Unless you're using a system-wide pulseaudio daemon instance, that's irrelevant.
[07:40] <crimsun> i.e., if you're using pulseaudio-esound-compat with Software Sound Mixing enabled in GNOME, then that has naught to do with gdm, since pA isn't even running at that point.
[07:40] <RAOF> crimsun: And I've got a bunch of gconf entries for gnome-volume-control, and the mixer applet.
[07:40] <RAOF> Yeah, fair enough.
[07:40] <crimsun> then you've hit the pulseaudio<->gnome-volume-control bug
[07:41] <DanaG> That's odd: I'm trying to increase pulseaudio's input volume, but it jumps back to middle.
[07:41] <RAOF> So why doesn't alsamixer work?
[07:41] <crimsun> RAOF: how are you invoking alsamixer?
[07:41] <DanaG> Aah, I see, it goes from 0% to 100% to who-knows-where.  It's AT 100 already.
[07:41] <crimsun> why am I pulling teeth here?
[07:41] <crimsun> both of you know to provide more detail when asking questions...
[07:43] <RAOF> "alsamixer -c 0" from a terminal.  The gconf entries for g-v-c and the mixer applet all point to HDA Intel (Alsa mixer)
[07:43] <crimsun> RAOF: and which mixer control are you adjusting in alsamixer -c0?
[07:45] <RAOF> Um, I tried all of them.
[07:45] <crimsun> then that can't be a pA bug.
[07:46] <crimsun> pA will only lock the primary PCM element.
[07:47] <crimsun> although I did just spot a control-center bug
[07:47] <crimsun> it's not killing esd/pulseaudio correctly
[07:47] <RAOF> Ah, but there isn't any other relevent volume element.  My hda-intel doesn't have a "master" volume control, just a mute.  And "PCM" is the only output control.
[07:48] <crimsun> so the only control exposed in the playback perspective [of alsamixer -c0]  is 'PCM'?
[07:48] <RAOF> PCM, CD, Mic, PC Beep, and a Master which only acts as a mute.
[07:48] <RAOF> Yes.
[07:48] <RAOF> Of those controls, PCM is the only one which actually changes the output.  At least, the output that I care about, which is rhythmbox/banshee.
[07:49] <crimsun> mute-only?  You don't have a Conexant, then.  Realtek or Sigmatel?
[07:49] <DanaG> Hmm, perhaps thae microphone is just broken.......
[07:49] <RAOF> No.  I could probably find the bug I filed to get support for it, though.
[07:49] <crimsun> RAOF: you could also just pager /proc/asound/card0/codec*
[07:50] <RAOF> Even better :)
[07:51] <RAOF> I can't pastebin, 'cause the laptop isn't connected to the internet (stupid uni).  It's a Realtek ALC660, though.
[07:52] <crimsun> the top 5 lines would be useful.
[07:53] <RAOF> Actually, I could pastebin that.  Yay for usb sticks.
[07:54] <RAOF> I'll just pastebin all the stuff from the AudioDebugging wiki page, shall I.
[07:54] <crimsun> DanaG: if it works in another OS, I suspect ACPI and _then_ alsa-kernel.
[07:54] <crimsun> RAOF: unnecessary.  I only need codec#0
[07:55] <RAOF> Ok, I'll just get that then.
[07:55] <DanaG> Hmm, I use a patch cable from audigy to audigy, and play with pulseaudio and watch the line-in with pulseaudio,
[07:55] <DanaG> I do get activity.
[08:00] <RAOF> Stupid uni computer.  Here are the top 5 lines crimsun http://paste.ubuntu-nl.org/24016/ .  If you need more, I'll need to restart to get the usb key mounted properly.
[08:00] <DanaG> Odd, with the loopback, I'm piping parec on the audigy into paplay on the onboard.
[08:00] <DanaG> It's giving me random short bursts of static.
[08:02] <DanaG> I'll try without pulseaudio, later.
[08:03] <crimsun> RAOF: what's the 0403 SSID entry from lspci -nv ?
[08:06] <RAOF> Assuming SSID == subsystem, 1043:1338.  Otherwise I can copy out that whole block, but it'll be slow :(
[08:06] <crimsun> ASUS F2/3?
[08:06] <crimsun> asus boards make me sad.  Very Sad.
[08:06] <RAOF> F3Jm
[08:07] <RAOF> Really?  And it looked kinda good before I bought it. :(
[08:07] <crimsun> that's ok, even crap looks interesting before you find out what it is.
[08:07] <crimsun> not your fault - you couldn't have known a Realtek sat in it.
[08:07] <RAOF> Right. :/
[08:08] <RAOF> System 76 don't ship to .au, and none of the local "linux friendly" shops I could google seemed to have made a webpage since 1997.
[08:08] <crimsun> ok, so you've got one primary mixer control for output, which explains the "lock"
[08:08] <crimsun> unfortunately this means there's no free control for pA by default
[08:09] <RAOF> Oh.
[08:10] <RAOF> And pA *has* to lock one output to 100%?  This seems odd.
[08:10] <RAOF> Then again, so does not having any form of "master" volume control, I suppose.
[08:11] <crimsun> it's used as a base.
[08:11] <crimsun> the control you then use through pA is software-scaled, essentially equivalent to the pcm softvol plugin provided through alsa-lib.
[08:11] <crimsun> _however_
[08:12] <crimsun> if you have a free control, say, 'Master', the control uses _that_ instead.
[08:12] <RAOF> So you want full volume in pA to correspond to full volume, so you need it set to 100%.  Fair enough.
[08:12] <crimsun> well, a reasonable full volume.
[08:13] <crimsun> I wouldn't push beyond 90%.  Most will distort horribly.
[08:13] <RAOF> Yes.  Mine certainly does.
[08:13] <crimsun> unless you're lucky enough to use usb or firewire audio.
[08:14] <RAOF> Are USB audio cards actually good?  Wow.
[08:15] <crimsun> there are quite a few excellent ones.
[08:16] <RAOF> Hm.  But they cost money :)
[08:16] <RAOF> So, there's probably a bug to file in all this, although maybe a wishlist bug only.  Where should it go?  The alsa driver?  pA?
[08:16] <crimsun> a good base is the M-Audio Transit USB.  I purchased one three years ago for US$70.
[08:17] <crimsun> pulseaudio.
[08:18] <RAOF> And the bug is "when alsa exports only the PCM mixer element, pulseaudio locks the volume to 100%", or thereabouts?
[08:20] <crimsun> that's not a bug
[08:21] <crimsun> I think you mean "unable to effect alsamixer -c# changes when pulseaudio is active"
[08:21] <RAOF> Much better.
[08:28] <DanaG> Oh, and I just noticed something:
[08:29] <DanaG> BIOS bug: multiple APIC/MADT found, using 0
[08:29] <DanaG> [    0.000000]  ACPI: If "acpi_apic_instance=2" works better, notify linux-acpi@vger.kernel.org
[08:30] <DanaG> APIC 3FE81DFF, 0068 (r1 GATEWA M685     20060906 LOHR       5A)
[08:30] <DanaG> APIC 3FE81F0D, 0068 (r1 GATEWA M685     20060906  LTP        0)
[08:32] <RAOF> Where would we be without buggy APIC and ACPI implementations?
[08:32] <DanaG> I wonder which one XP uses, and which one Vista uses.
[08:33] <DanaG> I have posted the changelog of the 72.14 BIOS.  I'm using 72.09.
[08:34] <DanaG> http://www.csc.calpoly.edu/~dgoyette/gateway_pa6_bios_7214.txt
[08:38] <DanaG> And anything newer than 72.09 seems to break sleep even in XP.
[08:53] <DanaG> Bye.
[09:06] <lightrush> !upgrade
[09:06] <ubotu> For upgrading, see the instructions at https://help.ubuntu.com/community/UpgradeNotes
[09:44] <coNP> heya fellow ubuntueros, what a lovely day to let a monkey ruin my system :)
[09:45] <crimsun> then don't play with monkeys if you value your system.  I say monkeys are more valuable, but YMMV.
[09:46] <coNP> okay, I am not so serious
[09:46] <coNP> anyway, I love to use testing systems
[09:46] <coNP> crimsun: you mean monkey is usable for you now?
[09:47] <crimsun> considering the amount of love I put into my configuration, yes.
[09:47] <crimsun> YMMV.
[09:47] <coNP> okay, MMCV :)
[09:48] <Tm_T> YMCVBNM
[09:48] <RAOF> One of my LVM volumes is now officially "gusty-root"
[09:48] <RAOF> Tm_T: your milage may vary but not much?
[09:48] <RAOF> :)
[09:48] <coNP> 36% so far...
[09:48] <coNP> Need to get 1174MB/1174MB of archives on a DSL line...
[09:48] <Tm_T> RAOF: more like "I use fist with shift"
[09:49] <RAOF> :D
[09:49] <Tm_T> coNP: I downloaded ~500 MB on dialup
[09:49] <Tm_T> that took only two days or so
[09:50] <crimsun> two days? psht. It'd take me the better half of a week.
[09:50] <coNP> I also did that some years ago
[09:50] <coNP> debian sid and every day some new packages on dialup
[09:50] <Tm_T> crimsun: I remind you, my connection is 5 kb/s max
[09:50] <coNP> I hated the days with new LaTeX packages :)
[09:51] <crimsun> Tm_T: mine's half that.
[09:51] <Tm_T> crimsun: lovely :)
[09:51] <Tm_T> I wouldn't mind the speed otherwise but this ssh is bit jumpy and cutty
[09:53] <crimsun> latency doesn't bother me, and I can handle the jitter.
[09:53] <Tm_T> yup
[09:53] <Tm_T> as said, other is fine, but ssh is unconfortable
[10:44] <Enverex> Does anyone know if the rt2x00 driver is in 2.6.22-6?
[10:48] <gnomefreak> Enverex: try either filing a bug report or asking in #ubuntu-kernel (filing bug report is the better way)
[10:52] <Enverex> Filing a bug just for a quick question seems a bit wasteful
[10:56] <crimsun> Enverex: http://preview.tinyurl.com/2qr65w
[10:56] <crimsun> please look before asking :)
[10:57] <MmikeMRMA> does anyone know how to boot gutsy live-cd without the splash screen? (btw, live-expert kernel image does not exists)
[10:58] <crimsun> if you disable the framebuffer, usplash is disabled.
[10:58] <gnomefreak> MmikeMRMA: if you mean expert install its on alternate cd
[10:58] <crimsun> likewise, you can attempt appending nosplash
[10:58] <Enverex> crimsun, Erm, wasn't aware of that page, heh
[10:59] <MmikeMRMA> crimsun, if I do 'live fb=false' i still get the uslpash....
[10:59] <crimsun> Enverex: all our kernel source is online :)
[10:59] <crimsun> MmikeMRMA: err, the vesa option?
[10:59] <MmikeMRMA> gnomefreak, I downloaded gutsy daily cd image... when I press f2-f3-f4 there is suggestion that I could do 'live', 'live-expert', and 'memtest'... live and memtest work fine, live-expert gives me 'nonexistant kernel image' error...
[11:00] <MmikeMRMA> crimsun, erm... huh? :)
[11:00] <gnomefreak> MmikeMRMA: you might want to wait until tribe one. the ISO's have been broken since the first daily not sure if its been fixed yet
[11:01] <gnomefreak> as of last week i heard alternate is almost fixed (nothing about desktop cd
[11:01] <MmikeMRMA> gnomefreak, oh... I'll wget alternate CD then, 10x :)
[11:02] <MmikeMRMA> gnomefreak, it's just... here: http://cdimage.ubuntu.com/daily-live/current/, there is no alternate CD (or I'm developing strange blindness)
[11:02] <gnomefreak> MmikeMRMA: it may not work either (almost fixed means its not totallly fixed and i dont know what the issues were to begin with)
[11:02] <gnomefreak> MmikeMRMA: the part of link that says daily-live would be the reason
[11:03] <gnomefreak> http://cdimage.ubuntu.com/daily/current/
[11:03] <MmikeMRMA> gnomefreak, well, this image I have I try to boot in vmware... as soon as the splash shows up, few seconds after I'm back to BusyBox... I guess there is an error, I just can't see it because of the splash....
[11:03] <gnomefreak> MmikeMRMA: try that
[11:04] <MmikeMRMA> gnomefreak, thnx, willl do
[11:04] <gnomefreak> MmikeMRMA: live and alternate have been broken
[11:05] <gnomefreak> MmikeMRMA: your best bet if you are determined to use gutsy this soon is to wait till thursday friday ish and install tribe 1
[11:06] <gnomefreak> atleast at that point the ISOs should work (they are tested atleast)
[11:06] <MmikeMRMA> well, I'm part of the loco team, and I'd like to see what needs to be done in gutsy.... thnx for the suggestion :)
[11:06] <MmikeMRMA> will wait then :)
[11:09] <gnomefreak> MmikeMRMA: normally if your not a developer it not recommended to use gutsy most of us use gutsy in chroot anyway
[11:09] <MmikeMRMA> gnomefreak, that's why I'm booting it in vmware, no worries, I know what i'm doing :)
[11:10] <gnomefreak> MmikeMRMA: sorry i dont know these things (i cant read minds)
[11:16] <MmikeMRMA> gnomefreak, :) I'm sorry ! :) thank you for your help!
[11:20] <johnnybuoy> hi all!
[11:21] <johnnybuoy> I'm trying to get banter to compile, and have got some trouble with it
[11:21] <johnnybuoy> I have unmet deps, one I can't get through is gnome-keyring-sharp
[11:22] <johnnybuoy> it seems gutsy doesn't have the libgnome-keyring-cil package, and the feisty version doesn't seem to work
[11:22] <johnnybuoy> does anyone have an idea?
[11:25] <gnomefreak> johnnybuoy: yes wait until gutsy is a bit more stable or if you are building it for gutsy ask in #ubuntu-motu (more than likely it was replaced by a differnet name and the version you are building isnt compatible with that version0
[11:26] <johnnybuoy> okay, I'll check in ubuntu-motu
[11:26] <johnnybuoy> thx
[11:27] <johnnybuoy> c y'all
[12:40] -ChanServ(ChanServ@services.)- You do not have channel operator access to [#ubuntu-boot] 
[12:40] -ChanServ(ChanServ@services.)- [#ubuntu-server]  Ubuntu Server Discussions (development and support)
[12:40] -ChanServ(ChanServ@services.)- [#ubuntu-ops]  Welcome to #ubuntu-ops - Home of the operators for official K/X/Ed/Ubuntu channels. Questions, requests and complaints about Ubuntu related channels and their people can be filed here"
[12:40] -ChanServ(ChanServ@services.)- [#ubuntu+1]  Please read the topic. Especially if things are broken!
[01:32] <dballester> hi to all
[03:29] <DanaG> That's odd: I just hit my volume key, and gnome-setting-daemon crashed and then restarted.
[03:59] <ToHellWithGA> Setting up xserver-xorg (1:7.2-3ubuntu1) ...
[03:59] <ToHellWithGA> /var/lib/dpkg/info/xserver-xorg.postinst: 2197: Syntax error: "then" unexpected (expecting "fi")
[04:00] <ToHellWithGA> ;)
[04:00] <ToHellWithGA> i noticed mini.iso is ready to rock for gutsy now
[04:04] <gnomefreak> ToHellWithGA: its known
[04:04] <ToHellWithGA> mkay
[04:05] <ToHellWithGA> how's it with you, man?
[04:05] <gnomefreak> busy as crap
[04:05] <gnomefreak> and yourself?
[04:05] <ToHellWithGA> housesitting
[04:05] <ToHellWithGA> i'll kick back extra for you
[04:11] <gnomefreak> ToHellWithGA: give it a few hours the problem was found and is being worked on
[04:12] <ToHellWithGA> it's cool man.  i can't reboot anyway
[04:12] <ToHellWithGA> the new kernel isn't playing nice with my wireless card
[04:12] <gnomefreak> i dont really think reboot will hurt
[04:12] <gnomefreak> but ill let you knwo ina  sec
[04:12] <ToHellWithGA> i won't report a bug until i figure out if it is just a result of frequent dist-upgrading
[04:12] <ToHellWithGA> too many little upgrades make my system kinda unstable
[04:17] <gnomefreak> tonyyarusso: X works fine after restarting X
[04:17] <gnomefreak> not tonyyarusso  ToHellWithGA
[04:18] <ToHellWithGA> thanks for checking that out, man
[04:18] <ToHellWithGA> i'm ssh'd so i have to be careful what i do remotely
[04:18] <ToHellWithGA> i'd hate to lose my connection to that computer by starting an angry kernel
[04:19] <gnomefreak> eh ssh is too much fun to be careful ;)
[04:19] <ToHellWithGA> remotely executing init 6 only to find out that the network card driver is rough around the edges kinda sucks
[04:20] <ToHellWithGA> i was so amped about a new kernel with new features about which i could read and possibly never use
[04:22] <ToHellWithGA> .me mails gnomefreak vinyl records in manilla envelopes
[04:22] <gnomefreak> no not that
[04:23] <ToHellWithGA> .me launches gnomefreak marbles as model rocket payload
[04:23] <gnomefreak> :)
[06:00] <Peaker> anyone else gets a syntax error in the xserver-xorg.postinst script?
[06:00] <Peaker> Its in line 2197, according to the shell trying to run it, but that line is empty :P
[06:01] <Peaker> does it use 0-based line indices?
[06:01] <Peaker> nah if I stick a bunch of syntax errors in some line, it seems to pinpoint the correct line number
[06:01] <Peaker> weird
[06:04] <Peaker> okay, bash is totally buggy about the line numbers of if/fi/then syntax errors
[06:04] <Peaker> oops, its dash
[06:04] <Hobbsee> Peaker: known
[06:06] <Peaker> ah I found their bug
[06:06] <Peaker> stupid dash line numbers :)
[06:06] <Peaker> elif must start on its own line or after ; mustn't it?
[06:06] <Hobbsee> no idea, my bash isnt too brilliant
[06:07] <Peaker> ah, cool. fixed.
[06:07] <Peaker> If you try to dist-upgrade now, xserver-xorg is going to fail :P  But its trivial enough that I am not sure a bug report is necessary
[06:09] <KooGooShii> anyone able to help me getting dvds to work in fiesty? ive updated my libdvdread/libdvdcss already but it doesnt seem to work
[06:09] <Peaker> I thought #ubuntu+1 was for gutsy
[06:10] <Peaker> KooGooShii: I think #ubuntu is for feisty now
[06:10] <KooGooShii> ah sorry, looks like it autojoined me here
[06:11] <Hobbsee> Peaker: the guy knows about it, and will upload the fixed version soon
[06:12] <Peaker> okay cool
[06:12] <Peaker> so the dash thing about line numbers is known also because of that? :)
[06:12] <Hobbsee> not sure
[06:13] <Hobbsee> Peaker: this isnt much breakage
[06:13] <Peaker> no, not just that. kcontrol is completely broken, for a while now
[06:13] <Hobbsee> Peaker: X still works, the machine still boots.  even gnome/kde run.  this is good for gutsy
[06:13] <Hobbsee> yeah, system settings is borked somehow.
[06:13] <Peaker> X disables direct rendering every once in a while
[06:13] <Peaker> not sure when exactly
[06:14] <Hobbsee> you have a working X.
[06:14] <Peaker> I just find its off and restart X
[06:14] <Peaker> scipy doesn't work at all - but that may not be gutsy's fault (the newest upstream tarballs don't even compile)
[06:14] <Hobbsee> hah.  helpful
[06:14] <Hobbsee> Peaker: how's kcontrol broken, as opposed to the system settings breakage?
[06:17] <Peaker> Hobbsee: You can only see a couple of the kcontrol modules inside kcontrol. But weirdly, if you tell "kcmshell" to load a module by name it works (kcmshell can load kcontrol modules directly)
[06:18] <Hobbsee> which can you see?
[06:18] <Peaker> The System Settings menu is broken in the same way - same modules
[06:18] <Hobbsee> system settings segfaults on start
[06:18] <Hobbsee> at least here
[06:18] <Peaker> OBEX devices is the only one you see (under Peripherals). In KControl you also see and empty Network folder
[06:19] <Peaker> Also, I think when I ran kcontrol from the command line - I believe it said something about incompatible versions of the kcontrol modules, but I am not sure (that may be why its refusing to load them by default)
[06:19] <Hobbsee> sounds local
[06:19] <Hobbsee> i cant reproduce that
[06:19] <Hobbsee> although others in bug reports have
[06:19] <Hobbsee> i wonder why that only occurs for some people...
[06:20] <hwilde> anybody have a suggestion for software crash every sunday morning 7:35am ?  (i disabled weekly crontab already)
[06:30] <Peaker> Hobbsee: if it just segfaults in others, it may be that the hidden modules are a global bug thing, but there's a local segfault bug that masks it :)
[06:30] <Hobbsee> it segfaults on startup anywhere, which is what's odd to me
[06:30] <Hobbsee> but true
[06:32] <IdleOne> how do I upgrade to gutsy or should I wait till Herd1?
[06:35] <Hobbsee> IdleOne: if you have to ask, you shouldnt be running it.
[06:35] <IdleOne> makes sense
[06:35] <IdleOne> :)
[06:49] <ToHellWithGA> IdleOne: i don't think it'll be called a herd this time
[06:49] <ToHellWithGA> if you want to dist-upgrade into gutsy you could try.  not much breaks if you do it now
[06:50] <ToHellWithGA> it will get breaky later though.  not a good idea unless you only need your computer for tinkering
[06:50] <IdleOne> ToHellWithGA, well whatever they decide to call it. on the site it looks like it will be called Tribe1-2-3....
[06:51] <ToHellWithGA> if you wanted to dist-upgrade to it, you could do it pretty quickly via CLI
[06:51] <IdleOne> think I'll wait tilllate August/ early September
[06:51] <ToHellWithGA> sudo sed -i "s/feisty/gutsy/g" /etc/apt/sources.list && sudo aptitude update && sudo aptitude dist-upgrade
[06:51] <ToHellWithGA> then hold on to your hat
[06:51] <Peaker> Hobbsee: btw: I thought you meant the system settings menu - the 'systemsettings' executable does segfault here
[06:53] <Hobbsee> oh, right
[06:53] <Hobbsee> it's tribe this time, yes.
[06:54] <Peaker> and there's no usable traceback too
[06:54] <Peaker> how do you get gdb to demangle C++ names?
[07:00] <Peaker> well, there are no symbols in systemsettings, so its hard to debug it :P
[07:01] <Peaker> will typical ubuntu packages have debug symbols anywhere in a "debian/rules binary" build?
[07:02] <Hobbsee> not sure
[07:02] <Hobbsee> i'm sure i should knwo, though
[07:02] <Peaker> worst case I comment out dh_strip from the rules makefile
[07:04] <Peaker> it uses a super-weird rules makefile, that just includes everything, but it doesn't seem to tell "binary" what to build
[07:09] <Peaker> arrg. It has a --disable-debug switch I changed to --enable-debug and its still using --disable-debug :) I think this is the 2nd out of 2 times I encounter such a debug switch that's actually fiction
[07:09] <Peaker> What does this do?   "cdbs_curpkg = $(filter-out %/,$(subst /,/ ,$@))"
[07:10] <Peaker> ah I should have used --enable-debug=full I guess
[07:11] <Peaker> nope, still uses disable
[07:12] <Peaker> ah, finally got it with DEB_BUILD_OPTIONS=nostrip
[07:15] <Peaker> arrg. need noopt too for stack trace to work :)
[07:15] <Peaker> it crashes inside Qt and surprisingly stack trace works in there, as if qt is not compiled with optimizations?
[07:16] <Peaker> oh, its not, gdb thinks it work but it doesn't
[07:16] <coNP> do someone use gutsy and ATI? how can I get my card working?
[07:18] <Peaker> there aren't no-optimization packages for common libraries, are there?
[07:23] <ToHellWithGA> Peaker: what are you saying, man?
[07:24] <ToHellWithGA> i catch a hint of an inkling about a clue regarding your discussion of your efforts to rebuild some package of something
[07:24] <coNP> Peaker: I guess the standard libraries compiled without -O<n> gcc flag
[07:24] <coNP> sorry, Peaker, I meant ToHellWithGA
[07:25] <Peaker> well I am trying to see why systemsettings is segfaulting
[07:25] <ToHellWithGA> so it's a toolchain problem instead of a problem with the individual package?
[07:25] <Peaker> but its backtrace is foobared, because qt is compiled with optimizations
[07:25] <Peaker> and so is systemsettings itself
[07:26] <Peaker> and it could be nice to have not only -dbg packages with symbols, but maybe to have -dbg packages be unoptimized (for stack dumps to work) and replace the lib
[07:26] <Peaker> or maybe -dbg, and -dbgnoopt :P
[07:37] <Peaker> okay, compiling qt with debug seems like quite a chore
[07:37] <Peaker> Its probably even easier to decipher a stack dump by hand
[07:40] <coNP> is there a repository to install adobe reader from?
[07:41] <ToHellWithGA> coNP: does evince not work?
[07:41] <Peaker> weird, its normal ebp frames and gdb messes up the stack trace
[07:41] <coNP> evince does work but I want to install adobe reader :)
[07:41] <ToHellWithGA> how very non-free of you :p
[07:43] <coNP> (or something that is not freedonm-free)
[07:49] <ToHellWithGA> freedom to break laws with freely-available mandatory and optional punitive consequences is great
[08:05] <Peaker> gdb is supposed to use files from -dbg packages automatically right?
[08:05] <Peaker> I'm not getting debug symbols when gdb'ing system-settings
[08:06] <Peaker> I think its in kdelibs (of which I have a -dbg package)
[08:07] <Peaker> I also get all the C++ mangled names
[08:20] <Peaker> could be nice if not _everyone_ had their own ./configure, but some shared system compatibility database existed somewhere, and everyone used that. could save a looong build step from everyone possibly without large modifications, and could avoid regenerating makefiles (which may mean less "make clean" running when changing stuff)
[08:27] <Peaker> ah. finally managing to source-level debug systemsettings
[08:29] <Peaker> ok its probably crashing because it can't find the systemsettings service group
[08:44] <Peaker> gdb is INSANELY slow at debugging these kde things
[09:13] <alex_mayorga> hi, how do I get to gutsy from feisty? is it usable?
[09:14] <borschty> it is likely to break often and requires some work to fix it
[09:15] <borschty> you can consider it usable when it gets released
[09:21] <Peaker> debugging systemsettings without knowing all the KDE terminology and architecture is too hard for me :P
[09:21] <alex_mayorga> I'm used to the normal breakage, is it just a dist-upgrade away?
[09:22] <Peaker> gutsy is pretty broken now, imo
[09:23] <Alexandre> Hey guys, Where i do the download this version?!?!?!?
[09:23] <alex_mayorga> Alexandre, +1
[09:24] <Alexandre> alex_mayorga: i don't understand, i want this nwe version
[09:24] <alex_mayorga> Alexandre, me too =)
[09:25] <alex_mayorga> but people it's a bit secretive on how to update to it
[09:26] <borschty> alex_mayorga: change feisty to gutsy in sources.list
[09:26] <alex_mayorga> borschty, thanks how broke is it as of now?
[09:26] <Alexandre> borschty: only this?!?!?!
[09:26] <Alexandre> borschty: thanks
[09:27] <borschty> Alexandre: then apt-get update and dist-upgrade
[09:27] <Alexandre> borschty: ok, (hahaha, i know this, hahaha)
[09:27] <Alexandre> borschty: not a ISO?!?!
[09:28] <borschty> alex_mayorga: as of now it boots and i can run the programs i need... but from feisty i know things can break even in the last week (the kernel did then iirc)
[09:28] <timing> I just asked this in #ubuntu-bugs: Hey i'm running gutsy gibbon and have some problems writing to my swap partition. everytime when my memory is almost full, all the memory allocation is still done on the RAM. Then, when the ram is completely full and more mem is needed, my system freezes. I need to reset my laptop to continue.
[09:28] <borschty> Alexandre: maybe there are already daily/nightly isos out, you have to ask google
[09:28] <timing> hy pointed me here
[09:28] <timing> *they
[09:29] <borschty> timing: free | grep Swap
[09:33] <borschty> what result does that give you?
[09:33] <timing> Swap:      1622524          0    1622524
[09:33] <timing> Mem:        710016     623184      86832          0      62620     358896
[09:33] <timing> i still have a bit of mem
[09:33] <timing> but starting the gimp would freeze everything now
[09:33] <timing> i tried swapoff/on already
[09:33] <borschty> maybe an ulimit, but that would rather kill the app than freeze the whole pc
[09:33] <timing> hmm
[09:33] <timing> the something else causes the freeze
[09:33] <timing> okay let's start the gimp then
[09:33] <timing> brb :-)
[09:33] <timing> hmm i need more
[09:34] <borschty> maybe broken ram?
[09:35] <timing> hmm
[09:35] <timing> it's writing to my swap now
[09:35] <alex_mayorga> timing, have you gone trough the memtest at boot time
[09:35] <timing> it might be a coincidence those freezes happen with full mem usage
[09:36] <timing> k swap is not the problem i think
[09:36] <timing> i'll be back when i can reproduce the freezes better!
[09:37] <timing> bye
[09:40] <alex_mayorga> borschty, how's the wireless networking in gutsy?
[09:41] <borschty> alex_mayorga: i can't tell you, have no wireless hardware on my desktop pc and my laptop stays feisty since i need one stable pc ;)
[09:41] <Peaker> alex_mayorga: It works for me
[09:41] <Peaker> alex_mayorga: but it did change "wlan0" to "eth1" so I had to fix my settings in /etc/network/interfaces
[09:42] <alex_mayorga> Peaker, are you in broadcom stuff?
[09:42] <Peaker> broadcom?
[09:42] <Peaker> Using zd1211 dongle
[09:43] <alex_mayorga> like https://bugs.launchpad.net/ubuntu/+source/bcm43xx-fwcutter/+bug/92088
[09:43] <ubotu> Launchpad bug 92088 in bcm43xx-fwcutter "this does not work with dell 1390" [Undecided,Confirmed] 
[09:44] <ToHellWithGA> lol what a horrid bug name
[09:45] <DanaG> WTF?   (process:6953): Gtk-WARNING **: This process is currently running setuid or setgid.    This is not a supported use of GTK+. You must create a helper program instead. For further details, see:
[09:45] <DanaG> Oh, and does it tell you WHAT program is trying to run setuid?  NOPE.
[09:46] <clever> but its process 6953
[09:46] <clever> DanaG: try ps aux|grep 6953
[09:46] <DanaG> But that process dies immediately thereafter, so I can't find it.
[09:46] <clever> lol
[09:47] <clever> strace -e trace=fork,exec programname
[09:47] <clever> that might do it
[09:47] <DanaG> It's something started by gnome-session.
[09:47] <clever> i think it may also need a -f on strace
[09:47] <clever> strace can do alot
[09:47] <clever> ahhh:(
[09:49] <DanaG> Kind of a useless error message, though, isn't it?
[10:52] <so1> hi
[10:53] <so1> i'm just wondering why people keep updating fglrx 8.34.x although the driver won't work anymore
[10:53] <so1> because the lastest xserver update (1.3) needs at least 8.37.x
[11:02] <so1> someone here?
[11:02] <gnomefreak> so1: drivers are always updated with l-r-m
[11:08] <so1> mh...
[11:08] <so1> that seems quite likely ...
[11:08] <so1> yes, i think there was a new kernel today ... that could be the reason ...
[11:08] <gnomefreak> and with Xorg but not all xorg updates get the non-free driver updates
[11:08] <bipolar> does gutsy have xorg 7.3-beta packages in it yet?
[11:09] <gnomefreak> so1: they need help with packaging drivers
[11:09] <gnomefreak> 7.2-3ubuntu3
[11:09] <so1> currently i'm holding back xserver 1.3 because i need fglrx (even vesa won't work)
[11:09] <gnomefreak> no not xorg
[11:09] <so1> mh?
[11:09] <gnomefreak> vesa should work if you disable FB
[11:10] <so1> mh okay...
[11:10] <so1> maybe i'll just wait until 8.37 arrives ...