=== cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-installer [12:12] brendan__: that's what evand's working on for gutsy. It's not possible in feisty. [12:13] (sorry if Evan already answered you and I missed due to local network trouble) [12:13] brendan__: (well, obviously anything's possible by editing the source, but it would take a fair bit of work.) === cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-installer === cynics [n=freeflyi@211.94.35.200] has joined #ubuntu-installer === freeflying [n=freeflyi@211.94.35.200] has joined #ubuntu-installer === cr3 [n=marc@bas5-montreal02-1167961527.dsl.bell.ca] has joined #ubuntu-installer === cynics [n=freeflyi@ubuntu/member/freeflying] has joined #ubuntu-installer === gellevi [n=gellevi@208.72.153.130] has joined #ubuntu-installer [01:24] ubiquity: cjwatson * r2162 ubiquity/debian/changelog: should be UNRELEASED [01:31] ubiquity: cjwatson * r2163 ubiquity/ (debian/changelog ubiquity/components/partman.py): * Fix crash related to partitions without a method set (LP: #110269). [01:34] ubiquity: cjwatson * r2164 ubiquity/ (debian/changelog ubiquity/components/partman.py): revert r2163, wrong approach === gellevi [n=gellevi@208.72.153.130] has left #ubuntu-installer [] === cr3 [n=marc@modemcable178.77-70-69.static.videotron.ca] has joined #ubuntu-installer [04:27] evand: ahh! look at https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/123364/comments/5 [04:27] evand: evidently something was closing ubiquity's stderr === evand 's eyes widen [04:29] gksudo? [04:30] the only changes in gksu from feisty to gutsy were translations [04:30] ah, then no === cjwatson checks libgksu [04:31] + - now uses a less dumb way of relaying child's stdout/stderr, [04:31] + thus not requiring so many wakeups (Closes: #425679) === cjwatson wonders ... === evand resumes the failing VM [04:36] 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] that might explain why it takes a while to crash [04:45] 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 ' on it [04:45] evand: and then stick gksudo.trace somewhere [04:46] cjwatson: will do [04:47] evand: also dpkg -l libgksu2-0 in the failing VM [04:47] 2.0.5-1ubuntu2 seems to have been an attempt to fix this, maybe === cacaupt [n=cacau@bl7-110-152.dsl.telepac.pt] has joined #ubuntu-installer [04:52] 2.0.5-1ubuntu2 is installed and it still occurs. [04:52] try reverting to 2.0.5-1ubuntu1? [04:52] will do [04:53] http://launchpadlibrarian.net/8081627/libgksu2-0_2.0.5-1ubuntu1_i386.deb [04:53] hey folks, is it possible to somehow call "sudo nvidia-glx-config enable" at install time (pxe/preseed)? [04:53] d-i preseed/late_command string ? [04:55] d-i preseed/late_command string chroot /target nvidia-glx-config enable [04:55] assuming it doesn't need X to be running [04:55] you don't need sudo, you're root at that point [04:55] nah - it's console cmd ta === Elwell wonders if he can be bothered to reboot / reinstall to test seeing as the LVM takes 3 mins/par [04:56] to timeout :-( [04:56] evand: first reported on the 27th some days after 2.0.5-1ubuntu2 was uploaded, so it's possible [05:06] wow, it does not like that version one bit [05:06] ? [05:07] oh whoops, it seems like I need to revert some dependencies as well [05:07] 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] heh [05:20] evand, i wanted to give you a friendly reminder re merge my branch from a few days ago [05:20] oh wow, sorry about that [05:20] that completely slipped my mind [05:20] I'll take care of that as soon as I'm done battling gksu === superm1 throws an extra sword in the ring on evand's side to give evand the advantage :) [05:22] heh === superm1 [i=malimonc@ubuntu/member/superm1] has joined #ubuntu-installer [06:17] 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] fwiw, http://evalicious.com/ubiquity.trace [07:35] I should've read the changelog [07:54] woo! [07:55] so it's an issue between libgksu2 2.0.3-3ubuntu5 and libgksu2 2.0.5-1ubuntu2 [07:56] but it's definitely in libgksu2 (at least for the bug I'm seeing) [07:56] I'll continue to poke around and see if I can come up with a patch [07:58] evand, what is the issue with gksudo? [07:59] superm1: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/122645 === superm1 [i=malimonc@ubuntu/member/superm1] has joined #ubuntu-installer === cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-installer [09:48] evand: yeah, stracing a set-id program causes it to become non-set-id [09:48] evand: you need to trace as root, but then that might cause gksudo to behave differently, so it gets tricky [09:49] you can work around that by temporarily creating a setuid-root copy of strace [09:49] ahhhh [09:53] 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] ah === cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-installer === cjwatson1 [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-installer === cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-installer