[05:33] <CIA-23> ubiquity: superm1 * r2433 ubiquity/debian/ (ubiquity-frontend-mythbuntu.links changelog): add forgotten links file
[10:02] <xivulon> cjwatson: we used to have some code to disable suspend-to-ram/disk in lupin-support that was moved upstream. Do you happen to remember where to?
[10:03] <xivulon> suspend is quite a labyrinth
[10:06] <cjwatson> xivulon: I put it in powermanagement-interface
[10:07] <cjwatson> xivulon: somebody should check that it's still there in pm-utils (which has largely replaced pmi), though
[10:08] <xivulon> I am asking because suspend-to-ram works as expected but suspend-to-disk is still active
[10:08] <xivulon> thanks I will have a look
[10:24] <xivulon> The code in pmi/pmi.acpi seems correct, but grepping for fuse and host within pm-utils does not return anything
[10:25] <xivulon> still suspend is disabled on loopinstallations in hardy :?
[10:25] <xivulon> suspend-to-ram that is
[10:27] <cjwatson> the pmi patch probably needs to be ported over to pm-utils
[10:28] <xivulon> that makes sense, though, as mentioned suspend-to-ram is disabled anyway, not sure why
[10:28] <xivulon> do not have a loopinstallation to check that now
[10:28] <xivulon> I'll make a note
[10:34] <xivulon> bug #187463
[10:34] <ubotu> Launchpad bug 187463 in wubi "Disable hibernate button" [Medium,Confirmed] https://launchpad.net/bugs/187463
[10:34] <xivulon> I'll attach that to pm-utils as well
[11:24] <CIA-23> ubiquity: cjwatson * r2434 ubiquity/ (configure configure.ac): bump to 1.7.7
[12:02] <xivulon> evand can you go through https://bugs.launchpad.net/wubi/+bugs?field.tag=wubi again?
[12:03] <stgraber> cjwatson: The computer with the oem install problem is at home, I'm trying to reproduce in a VM. Though, why is there a password box if the user will auto-login ? (just for sudo ?)
[12:04] <xivulon> I refreshed the list, in particular 188460 is urgent, 140458 and 176112 are there as a reminder to poke other devs
[12:47] <cjwatson> stgraber: that, and I wasn't willing to do as many hacks to make passwordless users work on an installed system as we do on the live CD
[14:01] <evand> xivulon: sure, but I have other things I need to work on today, so I cannot get to it immediately.
[14:13] <xivulon> evand 188460 should be a quick (but important) one, it's a couple of line changes as indicated in patch
[14:15] <xivulon> it involves replacing the existing if-block in grun-installer line #570 with the one provided
[14:22] <evand> xivulon: please use debdiffs for your patches.  Rough estimations of line numbers and only the code going in make it difficult to immediately see what the changes are.
[14:23] <cjwatson_> alias diff='diff -u' # if you find it hard to remember ;-)
[14:26] <evand> you don't have to do it for this particular case, but please remember to do so in the future
[14:36] <evand> xivulon: I'd much rather get to the bottom of why grub-install doesn't like loopdevices rather than special case them with the block of code you suggest.
[14:37] <xivulon> evand sure, I did like that since had no linux when I submitted the patch
[14:37] <evand> ok
[14:38] <xivulon> the block of code was already there by the way, that is the part that make it skip grub-install for loop devices
[14:38] <xivulon> I believe cjwatson added that in gutsy
[14:38] <xivulon> my code simply generates the device.map if one is not present
[14:42] <xivulon> if you want to run grub-install on loopdevice, set bootdev=$disc_offered
[14:44] <xivulon> disc_offered should be set correctly to /dev/loopX at that point (you might want to run some safety checks).
[14:47] <xivulon> note that in loopinstallation grub-installer/bootdev_directory is set in the preseed and hence the block is always triggered
[15:07] <evand> xivulon: ah, indeed.  Have you tested this patch?
[15:10] <xivulon> I have tested in that it correctly generates device.map, but did not have time to change my testing rig so that the target is not on (hd0,0)
[15:12] <evand> ok
[15:14] <evand> xivulon: were you ever able to get in touch with TheMuso about the accessibility options?
[15:14] <xivulon> ah no
[15:15] <xivulon> on that respect, can you make sure that boot arguments for different categories are accepted?
[15:15] <evand> I'd try emailing him.  IRC is going to be difficult given the vast time differences.
[15:15] <xivulon> I might pass: accessibility=v1 accessibility=m2
[15:15] <xivulon> ok
[15:16] <evand> His email address is listed on https://launchpad.net/~themuso
[15:16] <xivulon> what is the role of TheMuso wrt to accessibility?
[15:16] <xivulon> should email henrik as well...
[15:18] <cjwatson> TheMuso wrote most of the scripts you're looking at
[15:18] <evand> He's the contact point for accessibility issues in Ubuntu
[15:18] <xivulon> ok then
[15:20] <xivulon> can some of you remind slangasek of bug #140458 ? I did msg on ubuntu-devel to no effect
[15:20] <ubotu> Launchpad bug 140458 in wubi "Provide official Ubuntu metalink files on a public webserver" [Low,Confirmed] https://launchpad.net/bugs/140458
[15:21] <xivulon> I'd like to implement remote metalink support before beta, so that we can address hardcoded isolist info
[15:21] <cjwatson> (a) I already did so end of last week (b) until right at the very end of last week, he was dealing with release management of alpha 4 which was much more important (c) he's not awake yet
[15:21] <cjwatson> please reduce the frequency of nagging
[15:22] <xivulon> nagging == ubotu?
[15:23] <cjwatson> err ... nagging == reminding people about bugs and asking when they will be fixed
[15:23] <xivulon> well we skipped a few deadlines in the past...
[15:24] <xivulon> wold like to avoid last-day-rush this time around
[15:24] <cjwatson> asking somebody about a bug while they are asleep, and then complaining that they haven't replied yet when they are still asleep, is not a very productive way to go about things
[15:25] <cjwatson> it is on Steve's list, and as his manager I will ensure that he is reminded
[15:25] <cjwatson> please get off his back for a bit
[15:25] <xivulon> sure
[16:10] <evand> xivulon: you tested this in a loopinstall?  In mine it does not produce a mapping for the hard drive when I run grub --batch --device-map="/boot/grub/device.map"
[16:11] <xivulon> it has to be grub --batch --device-map="/target/boot/grub/device.map
[16:11] <xivulon> and you also want "echo quit | grub ..." or grub shell will stay on
[16:12] <evand> xivulon: this is post-install, /target does not exist.  And yes, I left out the echo quit for the sake of brevity.
[16:13] <xivulon> hmm $device_map does point to /target
[16:13] <xivulon> I am quite sure /target is there at that point
[16:15] <evand> the location that you stick the device map in doesn't matter for the bug that I'm seeing
[16:16] <xivulon> you mean that if you run grub --batch --device-map="mydevmap" and quit you see nothing in mydevmap?
[16:18] <evand> I see fd0, but no hd0
[16:18] <xivulon> strange
[16:18] <xivulon> make sure there is no pre-existing device.map
[16:22] <evand> there isn't
[16:23] <xivulon> $grub_shell --batch $no_floppy --device-map=$device_map <<EOF >$log_file
[16:24] <xivulon> this is the grub-install command that generates the device map
[16:25] <xivulon> maybe setting --no-floppy makes a difference?
[16:25] <evand> nope, but I cannot debug this further right now.
[16:26] <xivulon> are you running in chroot mode maybe?
[16:26] <xivulon> not sure if access to /proc & co is required
[16:26] <evand> post-install
[16:27] <xivulon> try to run the command before even starting ubiquity
[16:48] <xivulon> evand I think the problem is that you are not running it as root
[16:49] <xivulon> that of course would not be an issue within grub-installer
[16:51] <evand> ah, wow.  Sorry about that.
[16:52] <xivulon> np
[17:44] <kushal> xivulon, ping
[17:58] <xivulon> pong
[17:58] <xivulon> kushal^
[17:58] <kushal> xivulon, hi
[17:58] <xivulon> can I help?
[17:58] <kushal> xivulon, I just came to know about wubi
[17:59] <xivulon> great stuff isn't it :)
[17:59] <kushal> xivulon, yup
[17:59] <kushal> xivulon, I want write something like that for Fedora
[17:59] <kushal> xivulon, so, need guidance
[18:00] <xivulon> in short: the front-end can be used almost as is
[18:00] <xivulon> with some changes to preseeding and menu.lst arguments and branding
[18:00] <kushal> xivulon, can you explain me how it works ?
[18:00] <xivulon> I plan to clean it up a bit by the way
[18:00] <kushal> xivulon, I am starting with zero knowledge
[18:01] <xivulon> the front-end (windows) basically, detects settings, and then decides whether to download an ISO or use an existing ISO/CD
[18:01] <xivulon> it then generates bootfiles and preseed using the information gathered
[18:01] <xivulon> then it installs grub4dos and adds a boot option to the windows grub menu
[18:02] <xivulon> such menu option will in practice chainload to grub4dos which will load up an appropriate menu.lst
[18:02] <xivulon> the menu.lst contains arguments that instruct the installer to use an HD ISO and preseed file
[18:03] <xivulon> which is similar to do an unattended installation
[18:03] <xivulon> this is it on the windows side
[18:03] <kushal> ok
[18:04] <xivulon> on the linux side you need to patch a few upstream files so that you can install targeting a loopfile, set grub, bindmount as necessary, boot from a loopfile, shutdown...
[18:05] <xivulon> In ubuntu those patches are now mostly in, so what is left is the windows frontend
[18:05] <kushal> xivulon, are the patches sent back to the upstreams ?
[18:06] <xivulon> Originally I had to modify the installer initrd which would in turn patch the installer and the installed system
[18:06] <xivulon> as far as ubuntu goes yes, not sure whether debian was receptive so far.
[18:06] <kushal> it seems I am going to learn too many new things  :)\
[18:07] <kushal> xivulon, is there any step by step wiki kind of thing ?
[18:07] <kushal> xivulon, as most of it went over my head
[18:07] <xivulon> hm not really, but if I am around feel free to ask
[18:08] <kushal> xivulon, so, just tell me from I should start reading ?
[18:08] <xivulon> you may read about the original lupin project
[18:08] <kushal> xivulon, see, my skill set is python and pyqt
[18:08] <xivulon> that was ~ mine when I started
[18:08] <xivulon> but no python (unfortunately)
[18:09] <kushal> ok :)
[18:09] <kushal> xivulon, can you point me to some links?
[18:09] <xivulon> to merge things upstream you need the consent of fedora core developers
[18:10] <kushal> xivulon, that will not be a problem
[18:10] <xivulon> otherwise you will have to use overrides
[18:11] <xivulon> basically have a look at the launchpad projects for wubi (windows side, hardy branch) and lupin (linux side)
[18:11] <kushal> xivulon, can you give me any svn co links ?
[18:11] <xivulon> in lupin the devel branch is the old one containing overrides, the new one only contains a few hooks and assumes upstream changes
[18:11] <xivulon> you find the code in launchpad
[18:11] <kushal> xivulon, I saw the wubi , but don't know how to fetch it
[18:12] <xivulon> https://launchpad.net/wubi and https://launchpad.net/lupin
[18:12] <xivulon> as mentioned there is not much left of lupin since most of the code is upstream
[18:12] <kushal> xivulon, ok
[18:12] <xivulon> you need bzr
[18:14] <kushal> xivulon, ok, just found that :)
[18:16] <kushal> xivulon, let me get the code first
[18:17] <xivulon> In a few days I should have a cleaned up version of wubi, and was planning of moving to scons, any help there is welcome
[18:18] <xivulon> I'd also be glad to change the source so that is more "platform" neutral (at least on the windows side)
[18:18] <xivulon> In the sense that it is easier to reuse by other distros
[18:20] <kushal> xivulon, :)
[18:23] <xivulon> As for the upstream changes you should look at the launchpad bugs with a wubi tag
[18:24] <kushal> xivulon, ok
[18:24] <xivulon> Plus partman-auto-loop + lupin + initramfs-tools (look for the loop boot parameter)
[18:25] <kushal> ok
[18:27] <kushal> xivulon, how big is the wubi code ?
[18:27] <kushal> xivulon, bzr is taking too much time
[18:28] <xivulon> it contains subprojects, since I have slightly modified version of grub4dos and we do have an embedded downloader
[18:28] <kushal> xivulon, ok
[18:28] <kushal> xivulon, now I am really confused :D
[18:28] <xivulon> plus there were far too many changes which make things heavier
[18:28] <xivulon> by what?
[18:29] <xivulon> If you are a python programmer you aren't going to like nsis...
[18:30] <kushal> xivulon, by all the things you told me :)
[18:31] <xivulon> well copy the irc log and come back to it... I'll speed up the cleanup to alleviate your pain.
[18:32] <kushal> xivulon, :D
[18:51] <kushal> xivulon, good night
[20:37] <bdmurray> evand / cjwatson: Could you explain bug 150930 to me?
[20:37] <ubotu> Launchpad bug 150930 in ubiquity "Black screen, and bad usplash.conf" [Medium,In progress] https://launchpad.net/bugs/150930
[20:42] <cjwatson> bdmurray: ubiquity copies the live filesystem to the hard disk during installation. Since the live filesystem is generated centrally, anything in it that should depend on the installed system's hardware will be incorrect and ubiquity has to adjust it after it's copied everything over. The bug was that we forgot to do this for usplash, which has a configuration file containing the display size to use.
[20:44] <bdmurray> So a bug where somebody does not see usplash when booting is not a duplicate of that bug.  That bug would appear after installing and then rebooting correct?
[20:44] <bdmurray> "when booting off the Live CD" that is
[20:46] <cjwatson> right
[20:46] <cjwatson> I'm going to post to the bug explaining further
[20:47] <bdmurray> Great, thanks!  What will / can happen to the Gutsy task?
[20:48] <cjwatson> probably not much, I don't think a point release is planned right now
[20:49] <cjwatson> I'm leaving it open in case it happens, in which case we'd want to do this
[20:49] <bdmurray> Okay, that makes sense to me now
[20:50] <bdmurray> Thanks for clearing that up - I'll be unmarking some duplicates then
[20:52] <cjwatson> https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/150930/comments/129
[20:52] <ubotu> Launchpad bug 150930 in ubiquity "Black screen, and bad usplash.conf" [Medium,In progress]
[20:55] <cjwatson> I've edited the description too for good measure
[20:57] <bdmurray> great, I added "after installation" to the summary
[20:58] <cjwatson> ok
[21:28] <CIA-23> ubiquity: cjwatson * r2435 ubiquity/ (4 files in 4 dirs):
[21:28] <CIA-23> ubiquity: * Prevent apt-install from installing packages directly unless
[21:28] <CIA-23> ubiquity:  install_extras has been run (previously, it would do so once apt was
[21:28] <CIA-23> ubiquity:  configured, which produced some confusing error messages).
[21:31] <CIA-23> ubiquity: cjwatson * r2436 ubiquity/bin/ubiquity: small refactoring