[02:11] <shtylman> mterry: are you working on the installer in general or more the oem side of things? curious to know if I should try to update the oem-installer with a similar themeing as the new (or hopefully new) kubuntu installer?
[02:13] <mterry> shtylman, I'm working on stuff in general, but I have an oem background, so am interested in those issues
[02:13] <mterry> shtylman, since oem-config got merged, any theming improvements should also affect oem-config
[02:14] <shtylman> mterry: they won't effect it unless I load up the propper style sheet files... and make sure it all applies right to the oem.ui (qt terms)
[02:14] <shtylman> mterry: have you seen the screens for my recent work on the kde ubiquity side?
[02:15] <shtylman> mterry: I was hoping to do something similar for the oem side
[02:15] <mterry> shtylman, I've not seen the screens.  I know qt a bit, so the terms aren't unusual.  I just didn't know the kde frontend used a special oem.ui
[02:16] <shtylman> it may not... but for some reason I was distinctly under the impression that it did...
[02:16] <shtylman> http://shtylman.com/stuff/kubuntu_installer/version4/
[02:16] <mterry> shtylman, I hope after my merge, it doesn't.  :)
[02:17] <mterry> shtylman, It should use the same pages as the normal installer (modulo a few widgets that are hidden or skipped)
[02:17] <shtylman> mterry: gotcha... ok
[02:17] <mterry> shtylman, You can test by running oem-config in a recent build of ubiquity
[02:18] <mterry> shtylman, just have to install oem-config-kde
[02:18] <shtylman> k
[02:18] <mterry> shtylman, looks nice.  :)
[02:18] <shtylman> will do that and make sure my branch is kosher with oem-config as well
[02:38] <shtylman> mterry: I had to hide a few side items...but other than that looks good...what is the command to run the ubiquity installer in oem-config mode? versus just the oem-config which sets up the end user?
[03:57] <sean5446> hey im trying to install ubuntu and 8.04 gives me busybox, 9.04 goes to a black screen with blinking white cursor
[10:09] <Ng> http://mairukipa.tenshu.net/2009-07-21-grubfail2.png - after a preseeded install I get that (presumably because it can't find the UUID it was given. I've booted the system manually and /dev/disks/by-uuid shows the right thing. looking at the installation guide's preseed stuff I don't see a way to force grub to not use the UUID.. halp! ;)
[10:57] <evand> A bit confused on bug 401919.  It's using ubuntu as the hostname because that's the default value.  I initially thought returning the default value in response to get was a new thing in debconf, but according to blame, it's been there since day one.  Equally so for "ubuntu" as the default hostname.  I have a patch that checks the seen flag before trying to get netcfg/get_hostname, but I'm keen to find out what changed to cause this in the first 
[11:06] <CIA-3> ubiquity: evand * r3327 ubiquity/ (debian/changelog ubiquity/components/usersetup.py):
[11:06] <CIA-3> ubiquity: Debconf GET returns the default value if no value is set on a
[11:06] <CIA-3> ubiquity: question. As an undesirable default is set for netcfg/get_hostname,
[11:06] <CIA-3> ubiquity: check the seen flag to see if the value returned by GET was inputted
[11:06] <CIA-3> ubiquity: by the user (LP: #401919).
[13:14] <davmor2> evand: the link on the desktop for ubiquity isn't showing up
[13:14] <davmor2> on 20090721
[13:19] <evand> davmor2: okay, I'll pull it down now and look into it
[13:56] <rgreening> evand: hey
[13:57] <evand> davmor2: confirmed.  Entirely my fault.  Fixing now.
[13:57] <evand> rgreening: hi
[13:57]  * rgreening is knocking on evand's door
[13:57] <rgreening> :)
[13:57] <evand> indeed
[13:57] <rgreening> hah
[13:57] <evand> going to try to find time to upload the existing package out of trunk today
[13:57] <rgreening> heh
[13:57] <evand> have not found any time lately to work on the devicekit backend
[13:58] <rgreening> ok
[13:58] <evand> I've been 100% on the windows frontend and backend
[13:58] <rgreening> np
[13:58] <evand> (which is in cleanup if you find that sort of thing interesting)
[13:58] <rgreening> worst case scenario, we end up with supporting HAL one best case, we get devicekit later
[13:59]  * rgreening had a look and got lost
[13:59] <rgreening> :)
[13:59] <rgreening> I'm stuck trying to get an authentication package (tacacs) into karmic for $WORK
[14:00] <evand> heh
[14:00] <CIA-5> casper: evand * r658 casper/ (debian/changelog scripts/casper-bottom/10adduser):
[14:00] <CIA-5> casper: Remove erroneous /root prefix on the ubiquity desktop files in
[14:00] <CIA-5> casper: 10adduser.
[14:00] <rgreening> evand: as long as we get this in in some shape, we can work on it during alpha4/5. if we don't get it in before freeze.. hooped.
[14:02] <evand> indeed
[14:03] <davmor2> evand: have a quick word with pitti he was running a respin it might not of gone through though :)
[14:05] <evand> indeed, will do
[14:06] <CIA-5> casper: evand * r659 casper/scripts/casper-bottom/10adduser: Clean up path separators.
[14:12] <CIA-5> casper: evand * r660 casper/debian/changelog: releasing version 1.183
[14:59] <superm1> cjwatson, ping.  can you follow up on bug 341526 at some point soon? I wanted to make sure this didn't slip off radars again this cycle
[15:26] <superm1> evand, in http://launchpadlibrarian.net/29326432/casper_1.182_1.183.diff.gz any particular reason you are only doing it on the file in Desktop?  shouldn't it just be done on the original file to fix the menus and the file that ends up on the Desktop?
[15:46] <evand> superm1: good call, thanks
[15:46] <CIA-5> casper: evand * r661 casper/ (debian/changelog scripts/casper-bottom/10adduser): Apply the Ubuntu release version to the installer menu entries as well.
[16:59] <sean5446> hey is it bad if i install ubuntu on an extended partition?
[17:01] <evand> sean5446: no, why do you ask?
[17:01] <evand> are you having trouble doing so?
[17:02] <sean5446> because i am trying to install windows 7, ubuntu, and hackintosh on 1 computer and i just accidently installed ubuntu on an extended partition
[17:03] <evand> okay
[17:04] <sean5446> is there an easy way to get info about my ram and motherboard? i tried using 'lshw' and installing 'hwinfo' but its not really detailed
[17:05] <sean5446> id like to get the type and speed of the memory so i can buy mroe
[17:05] <sean5446> and the motherboard name so i can research which type of hackintosh to install
[17:38] <CIA-5> ubiquity: evand * r3328 ubiquity/ (bin/ubiquity debian/changelog): Do not try to run Migration Assistant for the KDE frontend.
[17:41] <CIA-5> ubiquity: evand * r3329 ubiquity/ (d-i/manifest debian/changelog):
[17:41] <CIA-5> ubiquity: Automatic update of included source packages: partman-base
[17:41] <CIA-5> ubiquity: 132ubuntu1, partman-target 62ubuntu1.
[17:50] <CIA-5> ubiquity: evand * r3330 ubiquity/debian/changelog: releasing version 1.99.1
[18:18] <Svenstaro> I'll have a second go at this: Can anybody tell me what kinds of features are currently in ubiquity trunk for: tours, plugins and media during the installation? Can I write a plugin to choose an installation profile, for example, or will I have to modify trunk altogether?
[19:22] <superm1> actually looking through oem-config-firstboot, there is a comment with a TODO there too :)
[19:22] <mterry> superm1, Ah, OK.  So at least no regression?  :)
[19:23] <superm1> mterry, well it's not working for me currently, but i didn't want to point the finger at that until I was confident that was the root cause
[19:23] <superm1> oem-config -q segfaults when DISPLAY isn't set though, so I can't imagine how oem-config-firstboot can proceed
[19:24] <mterry> superm1, ah.  OK, let me play with that
[19:25] <superm1> yeah that's definitely what's breaking it.  changing FRONTEND to "gtk_ui" rather than that shell call out allows oem-config-firstboot to get further
[19:27] <mterry> superm1, good...  I assume I made -q depend on X, where before it didn't?
[19:27] <superm1> mterry, most likely.
[19:27] <superm1> that --query gets passed through a lot of code for how simple it's return is
[19:28] <mterry> superm1, agreed.  I tried to copy oem-config's use of it, but must have missed a difference.
[19:30] <CIA-5> ubiquity: superm1 * r3331 ubiquity/ (bin/oem-config-firstboot debian/changelog): Correct a minor spacing typo in oem-config-firstboot.
[19:30] <superm1> ^(unrelated to the root cause, but still should have been fixed)
[19:40] <CIA-5> ubiquity: mterry * r3332 ubiquity/bin/ubiquity: print query value slightly sooner
[19:42] <mterry> superm1, ok, that commit should have fixed query mode.  i'm gonna reboot and test the whole oem-config-prepare cycle
[19:42] <superm1> mterry, okay cool thanks
[19:43] <superm1> might want to check with pitti to see if it's too late to get these into a3 iso's otherwise any oem cases are shot
[19:43] <superm1> (test cases that is)
[19:43] <mterry> sigh
[20:10] <mterry> superm1, k, now oem-config-firstboot can get through the end of the oem-config pages, but when the progress bar is supposed to appear at the end, it just crashes instead with "GLib-ERROR **: The thread system is not yet initialized." and loops back to oem-config.  running it in my session seems fine
[20:14] <superm1> mterry, hmm weird. i got the progress bar and made it through.
[20:14] <superm1> i'm running in debug mode though, so might not happen if that mode isn't present
[20:14] <mterry> superm1, oh, really?  Ok...  So the latest bzr works for you...
[20:14] <superm1> well not latest bzr
[20:15] <mterry> superm1, might be related to webkit?  searching the error gave me a hit on that, and that's a new thing between when i pushed this stuff in and now
[20:15] <superm1> this is what was on my archive mirror with that patch applied
[20:15] <superm1> so it's 1.99.0
[20:15] <mterry> hmm, that's an old hit actually
[20:15] <mterry> ok
[20:16] <superm1> so yeah that's before webkit stuff was added
[20:16] <superm1> let me see if i can manually pull newer stuff
[20:24] <superm1> mterry, works with 1.99.1 + that patch for me too
[20:26] <mterry> superm1, hmm, I have to add a call to threads_init.  working on that now
[20:31] <mterry> superm1, not quite sure why i have to call threads_init if you don't.  you see the progress dialog and the slideshow's 404 message?
[20:37] <CIA-5> ubiquity: mterry * r3333 ubiquity/ubiquity/frontend/gtk_ui.py: initialize threads at start of gtk frontend for webkit
[20:38] <CIA-5> ubiquity: mterry * r3334 ubiquity/debian/changelog: whoops, update changelog for my recent changes
[20:48] <mterry> superm1, sorry for breakage.  seems I didn't run -firstboot after finishing.
[20:49] <mterry> superm1, but should work now...  just need pitti to get back to me about breaking freeze
[20:49] <Svenstaro> I'll have a second go at this: Can anybody tell me what kinds of features are currently in ubiquity trunk for: tours, plugins and media during the installation? Can I write a plugin to choose an installation profile, for example, or will I have to modify trunk altogether?
[20:50] <mterry> Svenstaro, there is the beginnings of a slideshow in trunk.  I'm working on plugins in a branch.  Don't know what you mean by media
[20:50] <Svenstaro> Well, videos, but I guess a slideshow is fine.
[20:50] <Svenstaro> How about actual plugins to alter the installation process itself?
[20:51] <Svenstaro> Imagine profiles that install different sets of packages.
[20:52] <mterry> Svenstaro, different sets of packages...  I suppose you could do that with a plugin once I'm done with plugin support, but for now, you could do whatever the derivatives people do right now.  I'm not sure what that is, though
[20:53] <Svenstaro> mterry, what is it that the derivatives people do right now?
[20:54] <mterry> Svenstaro, like I said, I'm not sure.  Create a new CD based off a non-standard seed, I believe
[20:54] <Svenstaro> mterry, that won't allow the user to choose the selection at installtime.
[20:55] <mterry> Svenstaro, ah.  yeah.  wait for plugins I guess?
[20:57] <Svenstaro> mterry, mh, create a branch rather, I suppose.
[20:57] <mterry> Svenstaro, sure, that works too.  :)
[20:57] <Svenstaro> Okay thanks, now I only have to cope with Ubuntu's administration overhead before actually getting things done.
[20:59] <mterry> superm1, so for alpha 3, you suggest poking pitti to make sure it's ok to push?
[21:34] <superm1> mterry, yeah i think pitti needs to re-roll anyway because of a user-setup bug
[21:34] <superm1> so shouldn't be out of the question