[12:12] <cjwatson_> brendan__: that's what evand's working on for gutsy. It's not possible in feisty.
[12:13] <cjwatson_> (sorry if Evan already answered you and I missed due to local network trouble)
[12:13] <cjwatson> brendan__: (well, obviously anything's possible by editing the source, but it would take a fair bit of work.)
[01:24] <CIA-19> ubiquity: cjwatson * r2162 ubiquity/debian/changelog: should be UNRELEASED
[01:31] <CIA-19> ubiquity: cjwatson * r2163 ubiquity/ (debian/changelog ubiquity/components/partman.py): * Fix crash related to partitions without a method set (LP: #110269).
[01:34] <CIA-19> ubiquity: cjwatson * r2164 ubiquity/ (debian/changelog ubiquity/components/partman.py): revert r2163, wrong approach
[04:27] <cjwatson> evand: ahh! look at https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/123364/comments/5
[04:27] <cjwatson> evand: evidently something was closing ubiquity's stderr
[04:29] <evand> gksudo?
[04:30] <cjwatson> the only changes in gksu from feisty to gutsy were translations
[04:30] <evand> ah, then no
[04:31] <cjwatson> +  - now uses a less dumb way of relaying child's stdout/stderr,
[04:31] <cjwatson> +    thus not requiring so many wakeups (Closes: #425679)
[04:36] <cjwatson> I'm wondering if it's something like gksu crashing or otherwise closing stderr if the child doesn't emit anything to stderr within a certain amount of time
[04:36] <cjwatson> that might explain why it takes a while to crash
[04:45] <cjwatson> evand: if you can reproduce it, my recommendation is to find the gksudo process after launching ubiquity, and run 'strace -f -o gksudo.trace -s 1024 -p <pid>' on it
[04:45] <cjwatson> evand: and then stick gksudo.trace somewhere
[04:46] <evand> cjwatson: will do
[04:47] <cjwatson> evand: also dpkg -l libgksu2-0 in the failing VM
[04:47] <cjwatson> 2.0.5-1ubuntu2 seems to have been an attempt to fix this, maybe
[04:52] <evand> 2.0.5-1ubuntu2 is installed and it still occurs.
[04:52] <cjwatson> try reverting to 2.0.5-1ubuntu1?
[04:52] <evand> will do
[04:53] <cjwatson> http://launchpadlibrarian.net/8081627/libgksu2-0_2.0.5-1ubuntu1_i386.deb
[04:53] <Elwell> hey folks, is it possible to somehow call "sudo nvidia-glx-config enable" at install time (pxe/preseed)?
[04:53] <Elwell> d-i preseed/late_command string ?
[04:55] <cjwatson> d-i preseed/late_command string chroot /target nvidia-glx-config enable
[04:55] <cjwatson> assuming it doesn't need X to be running
[04:55] <cjwatson> you don't need sudo, you're root at that point
[04:55] <Elwell> nah - it's console cmd ta
[04:56] <Elwell> to timeout :-(
[04:56] <cjwatson> evand: first reported on the 27th some days after 2.0.5-1ubuntu2 was uploaded, so it's possible
[05:06] <evand> wow, it does not like that version one bit
[05:06] <cjwatson> ?
[05:07] <evand> oh whoops, it seems like I need to revert some dependencies as well
[05:07] <cjwatson> I'm trying to figure out what mvo's patch was designed to achieve. I think I've found one bug in it that might be relevant but I always need more coffee to deal with code involving waitpid.
[05:08] <evand> heh
[05:20] <superm1> evand, i wanted to give you a friendly reminder re merge my branch from a few days ago
[05:20] <evand> oh wow, sorry about that
[05:20] <evand> that completely slipped my mind
[05:20] <evand> I'll take care of that as soon as I'm done battling gksu
[05:22] <evand> heh
[06:17] <evand> So reverting to that version of libgksu causes gksudo to die in the background which in turn causes ubiquity to bail out after the first page.  If I run it with strace it complains about needing to be suid root, but /usr/bin/sudo is already suid root.
[06:17] <evand> fwiw, http://evalicious.com/ubiquity.trace
[07:35] <evand> I should've read the changelog
[07:54] <evand> woo!
[07:55] <evand> so it's an issue between libgksu2 2.0.3-3ubuntu5 and libgksu2 2.0.5-1ubuntu2
[07:56] <evand> but it's definitely in libgksu2 (at least for the bug I'm seeing)
[07:56] <evand> I'll continue to poke around and see if I can come up with a patch
[07:58] <superm1> evand, what is the issue with gksudo?
[07:59] <evand> superm1: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/122645
[09:48] <cjwatson_> evand: yeah, stracing a set-id program causes it to become non-set-id
[09:48] <cjwatson_> evand: you need to trace as root, but then that might cause gksudo to behave differently, so it gets tricky
[09:49] <cjwatson> you can work around that by temporarily creating a setuid-root copy of strace
[09:49] <evand> ahhhh
[09:53] <cjwatson> the kernel functionality used to implement strace ("ptrace") is able to modify the program as well as inspecting it, so the ability to ptrace set-id programs as non-root would be an obvious security hole
[09:53] <evand> ah