[00:24] <xivulon> cjwatson, on #188492 my tests went well and gb layoutcode worked out of the box!
[00:29] <TheMuso> xivulon: Anything in particular you want me to target for this round of wubi testing for the ISOs, noting that atm I can only test i386.
[00:34] <xivulon> thanks the Muso, as mentioned on #ubuntu-testing:
[00:34] <xivulon> 1) installation with physical CD (you can use an emulate CD) with and without internet connection
[00:35] <xivulon> 2) installation with a local ISO in the same folder as wubi.exe and without CD (should not download the ISO, but you must use an ISO with lates daily md5)
[00:35] <xivulon> 3) no ISO and no CD
[00:35] <xivulon> 1, 2, 3 only on the windows side no need to reboot
[00:35] <xivulon> check that the uninstaller works
[00:36] <xivulon> then reboot and go through the linux side installation
[00:36] <xivulon> check shutdown and suspend and try to install a different kernel
[00:36] <TheMuso> Ok.
[00:37] <xivulon> that would be great! thanks a bunch in advance
[00:39] <TheMuso> np
[00:46] <bdmurray> xivulon: what rev of Wubi is supposed to be on the images now?
[00:47] <xivulon> 495 (hopefully)
[00:58] <bdmurray> So I've a 20080422.3 KDE4 disc and I ran Wubi and it said 487 and didn't end well but using 'strings umenu.exe' the first thing I find is 495.  Do you have md5sums for umenu.exe or some other way to verify the version?
[01:10] <bdmurray> xivulon: the log is rev 487 too
[01:14] <xivulon> arg
[01:14] <xivulon> evand does the build: http://people.ubuntu.com/~evand/wubi/
[01:15] <xivulon> I guess we can compare with the md5 off the above url
[01:16] <bdmurray> htm
[01:17] <bdmurray> the md5sum of 495 != the md5sum of wubi off the cd I have
[01:17] <evand> uh odd, I did a make clean before the build too.
[01:18] <xivulon> yes it 487!!!
[01:18] <bdmurray> yeah, that's the match I get
[01:19]  * xivulon off to ubuntu-release
[01:19] <evand> how on earth did that happen?
[01:20] <evand> r495 was linked to stable as of 16:27 British time
[02:37] <xivulon> bdmurray thanks a lot for the heads up!
[02:37] <bdmurray> xivulon: no problem, I'm glad it got sorted and early at that
[02:38] <TheMuso> Yeah its on the latest set of live images now.
[02:39] <xivulon> haven't downloaded them, going to bed now
[02:39] <xivulon> rev495 md5 is a96aa69961f3ed80dd7a88fae1e28196
[09:39] <doug2266778822>  im running ubuntu gutsy gnome and i can not get my head phoen jack to work. can anyone help me?
[09:52] <doug2266778822>  im running ubuntu gutsy gnome and i can not get my head phone jack to work. can anyone help me?
[09:54] <doug2266778822>  im running ubuntu gutsy gnome and i can not get my head phone jack to work. can anyone help me?
[09:55] <grrrreg> not me
[09:55] <grrrreg> not me
[09:55] <grrrreg> not me
[10:21] <soren> doug2266778822: Repeating the same question over and over again will win you no friends.
[10:21] <soren> doug2266778822: Especially when the question doesn't belong in the channel in question.
[10:30] <xivulon> cjwatson, evand, for the first kernel upgrade or anything that would involve update-initramfs or update-grub after final, would it possible to have a procedure in place so that the changes are tested on loopinstallation before release?
[10:30] <xivulon> (if that is not already in place)
[10:40] <cjwatson> you'd need to talk to heno, I guess. What would we do if that failed?
[10:41] <xivulon> well the user should be able to boot with an old kernel right?
[10:42] <xivulon> so far it seems to have worked, but I'd welcome a few extra tests, at least for the first new kernel
[11:10] <TheMuso> xivulon: Well as part of my wubi testing today, I was able to install another kernel alongside the generic kernel, in this instance I used the rt kernel.
[11:11] <TheMuso> And I had no issues, both kernels were bootable, no errors on package install.
[11:11] <xivulon> thanks TheMuso, that is in line with my own testing
[11:55] <xivulon> arg bdmurray reopened #204128
[13:00] <james_w> Hi all.
[13:00] <cjwatson> yo
[13:00] <james_w> Under what circumstances would lilo be chosen over grub?
[13:01] <james_w> I just did an alternate install with manual partitioning, and set up LVM, and ended up with lilo.
[13:01] <cjwatson> if /boot is on LVM; if /boot is on DM-RAID; if /boot is on XFS; if you preseeded grub-installer/skip=true
[13:02] <cjwatson> yep, that's expected
[13:02] <cjwatson> did lilo work properly?
[13:02] <james_w> yeah
[13:02] <james_w>  /boot is not on LVM though
[13:02] <james_w> I *think*, let me check
[13:04] <TheMuso> cjwatson: It would not matter if /boot was on dmraid as to whether lilo or grub is used, as at that point, the BIOS is still managing the disks.
[13:04] <TheMuso> As its a BIOS fakeraid.
[13:04] <TheMuso> i.e the BIOS is used to set it up.
[13:04] <TheMuso> ...or you meant device mapper raid... My ad.
[13:04] <TheMuso> bad
[13:04] <cjwatson> well, no, I meant fakeraid
[13:04] <TheMuso> speech not speaking hyphens in some circumstances.
[13:05] <cjwatson> I'm just explaining the code, though, I didn't write it :-)
[13:05]  * TheMuso nods.
[13:05] <cjwatson>   * Add support for installing GRUB to a Serial ATA RAID disk. Currently this
[13:05] <cjwatson>     is only possible by using a semi-manual procedure that executes commands
[13:05] <cjwatson>     in the grub command environment (grub-install cannot be used).
[13:05] <cjwatson>     The current implementation assumes that teh SATA RAID disk will be listed
[13:05] <cjwatson>     as the first boot device in the BIOS.
[13:05] <cjwatson> according to the changelog
[13:05] <cjwatson> oh, I'm sorry, I misunderstood the code
[13:05] <TheMuso> Right. This is the stuff we'll need to look into for intrepid in any case.
[13:05] <cjwatson> scratch the /boot on DM-RAID condition, I missed a negation
[13:09] <james_w> ok, ext3 /boot, swap, xfs on lvm for /
[13:17] <james_w> that doesn't seem to fit the criteria, but it is similar in places (lvm, xfs), so could it be a bug?
[13:30] <cjwatson> possibly, if /boot isn't on XFS
[13:30] <cjwatson> er, on LVM
[13:31] <james_w> no, it's a separate partition.
[13:31] <james_w> Would you like a bug report?
[13:38] <CIA-1> apt-setup: cjwatson * r129 apt-setup/ (debian/changelog generators/50mirror.ubuntu):
[13:38] <CIA-1> apt-setup: * Remove restricted from cdrom entry if apt-setup/restricted is false
[13:38] <CIA-1> apt-setup:  (LP: #220805).
[13:38] <cjwatson> james_w: yes please, on grub-installer with /var/log/syslog and /var/log/partman attached
[13:39] <james_w> I don't have the latter, do I need to do something to make sure they are saved?
[13:40] <cjwatson> if you've completed installation, both of those will be in /var/log/installer/
[13:41] <james_w> yup, thanks.
[13:42] <james_w> "/boot is an lvm volume, cannot install grub"
[13:43] <james_w> I think this may be even more unlikely to be a problem, as this was an installation after I had to reboot the host, and I picked up an existing LVM setup, which I then started again.
[15:46] <isgleas> hi everybody
[15:47] <isgleas> how can I customize profiles on the live cd? I'm trying with sabayon profiling, but it does not work
[15:48] <isgleas> it doesn't seem to work with live session user
[16:23] <bdmurray> xivulon: I added some more info to the bug
[16:39]  * xivulon reading
[16:41] <xivulon> ah I think I know
[16:41] <xivulon> that's probably because the wubi executable is on the CD which you are ejecting
[16:42] <xivulon> the strange part is that the executable should be fully unpacked into the temp folder so there shouldn't be any need to access wubi.exe anymore
[16:44] <xivulon> but I am quite sure this is it, and that is why it is not an issue when you test wubi in stand-alone mode
[16:44] <xivulon> when you tested 488 successfully that wasn't on the CD was it?
[16:45] <xivulon> hmm I have always tested with virtual CD roms
[16:45] <xivulon> can we please have more testing with real CDs?
[16:46] <xivulon> can someone post on #ubuntu-testing?
[16:46] <xivulon> bdmurray: ^
[16:48] <xivulon> a quick workaround would be to have umenu copy wubi on the tmp folder and then run it from there
[16:48] <bdmurray> xivulon: to be clear you want more testing of Wubi off of real CDs correct?
[16:48] <xivulon> absolutely
[16:50] <xivulon> basically I would like to understand if it is a one off or if it affects every real CD installation
[16:51] <xivulon> cjwatson ping
[16:51] <xivulon> bug #204128
[16:51] <ubotu> Launchpad bug 204128 in wubi "After install completed bar wasn't all green and installer hung" [Low,Confirmed] https://launchpad.net/bugs/204128
[17:03] <xivulon> hi evand ^^^
[17:03] <evand|treo> howdy.
[17:03] <evand|treo> what's the issue?  im on my mobile and hitting lp would exit me from the irc client.
[17:04] <xivulon> it might be that wubi jams on eject when real CDs are used
[17:05] <evand|treo> ugh, how on earth could we miss something like that?
[17:05] <evand|treo> davmor2 did test with real cds on real hw
[17:07] <xivulon> because if you run wubi off the CD (e.g. wubi.exe is on C:) then it would work fine
[17:07] <evand|treo> I imagine its far too late for a fix.  does this affect all wubi users?
[17:07] <bdmurray> I'm talking to him now and his Vista isn't fully up to date
[17:07] <xivulon> evand we do not know yet
[17:07] <xivulon> but it might affect all wubi users off CD
[17:07] <evand|treo> ok
[17:07] <xivulon> so it is RC IMO
[17:08] <xivulon> unfortunately yesterday I asked all testers to use the binary off your site because the one on the CD was an old version!
[17:08] <xivulon> arggg
[18:25] <evand> so my understanding is that we're going to release note this.  Is that correct?
[18:38] <cjwatson> it sounds to me like a valid workaround is to tell people with Vista SP3 (or whatever it is) to download wubi from the network and use that?
[18:38] <bdmurray> evand: that's the impression I have
[18:39] <evand> cjwatson: sounds right, they just cannot have an Ubuntu CD in the drive
[18:39] <evand> at least that's my understanding
[18:39] <evand> wubi is supposed to end up on ubuntu.com for the release, so that should make things a little easier
[18:39] <bdmurray> I've found 2 possible workarounds
[18:40] <evand> oh?
[18:40] <bdmurray> evand: Well as you mentioned running Wubi off the Vista system works.
[18:42] <cjwatson> evand: my understanding was that it would work provided that you didn't run wubi off the CD
[18:42] <cjwatson> since xivulon has been saying that copying it to a temporary directory on the hard disk first is a workaround
[18:42] <bdmurray> Another, messier way, is to reinsert the CD, click the close button in Wubi.  Then choose "Close the program" when you are presented with the Windows dailog that "Wubi is not responding".
[18:42] <evand> cjwatson: yeah; just re-read the conversation in -release, I take back what I said.
[18:46] <evand> "With only the minimum amount of memory available, the installation process will take longer than normal, but will complete successfully, and the system will perform adequately once installed. Low-memory systems may be able to use the desktop CD to install by adding the only-ubiquity boot option to run just the installer rather than the whole desktop. "
[18:47] <evand> Shouldn't that instead reference the "Install Ubuntu" option, rather than requesting the user muck around with the kernel command line?
[18:47] <evand> from w.u.c/HardyReleaseNotes
[18:48] <cjwatson> yes, I'll edit, thanks
[18:52] <bdmurray> I documented my workaround in bug 204128
[18:52] <ubotu> Launchpad bug 204128 in wubi "After install completed bar wasn't all green and installer hung" [Low,Confirmed] https://launchpad.net/bugs/204128
[19:52] <cjwatson> hmm
[19:52] <cjwatson> (oops, echan)
[20:36] <bdmurray> evand: I'm experiencing bug 218973 again
[20:36] <ubotu> Launchpad bug 218973 in ubiquity "20080417.1 Guided resize failed" [Low,Confirmed] https://launchpad.net/bugs/218973
[20:37] <evand> is it reproduceable?  If so, can you attach partman and syslog
[20:39] <bdmurray> It fails and in partman I see to run 'e2fsck -f /dev/sda8'.  I ran an fsck after exiting ubiquity, started again and now I'm told to run fsck again.  Should I run the fsck while ubiquity is still open?
[20:40] <cjwatson> that shouldn't be necessary (or indeed helpful)
[20:45] <bdmurray> I've uploaded the syslog
[21:24] <bdmurray> evand: I've added /var/log/installer/debug to the bug too
[21:27] <evand> bdmurray: ok
[22:23] <CIA-1> ubiquity: cjwatson * r2674 ubiquity/ (debian/changelog scripts/install.py): * Fix ownership of /home/oem/Desktop in OEM installations (LP: #209683).