[12:26] <xivulon> evand, cjwatson have an issue when trying to use live cd initrd to boot from HD ISO
[12:28] <xivulon> the line in casper 'mount -t squashfs -o ro /dev/loop1 /filesystem.squashfs' fails with 'attempt to access beyond end of device'
[12:30] <xivulon> that's probably because /cdrom sits on loop0 in my case
[12:38] <superm1> evand, i think i'm missing something here.  with this new run() setup, how do the different pages get shown?  It's flying through all the debconf for all these pages without showing the GUI?
[12:40] <evand> xivulon: yikes
[12:41] <evand> superm1: when a question is asked, the associated page is shown
[12:41] <evand> superm1: the component has to call filteredcommand.run
[12:41] <superm1> hm that's odd.  that's what it should be doing then for me
[12:42] <superm1> how is the page associated with the component though other than load order?
[12:42] <superm1> *question associated with the page
[12:43] <superm1> because i see self.pages being declared, but it just lists the questions that are for each of the pages
[12:45] <evand> self.pages determines the order
[12:45] <evand> as the main loop in run iterates through that list
[12:45] <superm1> right that's what i see
[12:46] <evand> oh
[12:46] <evand> I misread
[12:46] <superm1> but say partman.Partman, it pulls in that filteredcommand and it's questions
[12:46] <superm1> but how does that relate to the loading of the glade file now
[12:46] <superm1> and setting that page in the GUI
[12:46] <superm1> since it used to be in process_step()
[12:49] <superm1> oh wait, it's done externally
[12:49] <superm1> via the set_page function isn't it
[12:49] <xivulon> evand at the moment I have a problem with a nested loop, any idea?
[12:49] <evand> a dbfilter is set in the main loop in run, that runs through until it hits a question that it would like to stop at.  It (the component) then calls filteredcommand.run(), which then calls set_page in the frontend (which actually changes the UI page) and enters the gtk main loop for event processing
[12:50] <evand> xivulon: can you elaborate?
[12:50] <superm1> evand, okay, i get it now, thx
[12:50] <evand> no problem
[12:53] <xivulon> evand, I am testing the find_iso code, the iso file gets mounted to /cdrom, then it tries to mount casper/filesystem.squashfs and it fails
[12:54] <evand> ohhh
[12:54] <xivulon> but I can mount nested loop devices under feisty
[12:54] <evand> xivulon: daily iso?  is mount segfaulting?
[12:55] <xivulon> yeah it's the same daily iso but it's not defaulting instead I have the error:
[12:55] <xivulon> attempt to access beyond end of device
[12:55] <evand> oh, hrm
[12:55] <xivulon> buffer i/o error on device loop0 (the one mounted on /cdrom)
[12:55] <xivulon> I tried to do the same operation from feisty and it works fine
[12:56] <evand> hrmm
[12:56] <xivulon> trying again from command line
[12:56] <evand> that looks like one for pkl or cjwatson
[12:57] <xivulon> by the way did you see the xinit thingy?
[12:57] <xivulon> it will start ubiquity in a barebone X session when launched with --automatic
[12:58] <evand> indeed.  I'm not sure how we're going to proceed with starting ubiquity automatically yet (there's more than one way to do it).  But should we go that route, I'll definitely use your patch.  Thanks!
[12:59] <xivulon> my reasoning was this
[01:00] <xivulon> users will run the windows wizard, which will install "stuff" and reboot
[01:00] <xivulon> if they reboot into a desktop environment, almost everyone will be lead to believe that the installation is completed
[01:00] <xivulon> when it actually did not even start
[01:01] <xivulon> that's the main reason to use a barebone x session with just ubiquity, but of course it is well possible to start ubiquity within a full gnome desktop
[01:08] <evand> xivulon: indeed, that thought crossed my mind as well
[01:34] <xivulon> /#join ubuntu-kernel
[01:34] <xivulon> ops
[10:11] <JD> Hi, I need to rebuild dapper's netboot image to include the bnx2 driver.
[10:14] <JD> I've got as far as knowing I need to rebuild the nic-modules udev. the question is how do I get that used in the d-i build rather than from the archive?
[11:00] <cjwatson> JD: you then have to grab the debian-installer source package from dapper (actually you probably want dapper-updates) and shove your nic-modules udeb in the localudebs directory there
[11:00] <cjwatson> and rebuild the initrd with that
[11:00] <JD> ah localudebs
[11:00] <JD> okay
[11:01] <JD> is there an updated nic-modules udeb with bnx2 already?
[11:01] <JD> https://launchpad.net/ubuntu/+bug/73647
[11:01] <JD> but I can't find the package it would be fixed in
[11:02] <cjwatson> give me a moment and I'll look that up
[11:02] <JD> cheers :)
[11:03] <cjwatson> ok, there is, but only in dapper-proposed with a weird ABI - I don't think you can actually use that
[11:03] <cjwatson> it's due to be done properly for 6.06.2
[11:04] <JD> but that's not going to be today is it?
[11:04] <JD> I'll rebuild the kernel package from source and then rebuild d-i
[11:04] <JD> it's okay.
[11:04] <JD> the localudebs bit is the bit I was missing
[11:08] <cjwatson> no, not today
[11:09] <JD> :)
[11:15] <cjwatson> JD: fwiw, re what fabbione said, definitely here and not #ubuntu-boot
[11:16] <JD> yeah, it was me and a bot. I got a little lonely :)
[01:03] <stgraber> cjwatson: Do you know if there is a way to use preseeding with the Minimal/Netboot image ?
[01:13] <cjwatson> stgraber: sure, see the installation guide, it's basically the same
[04:29] <xivulon> evand, cjwatson I'll be away for the next 4-5 days, if there is anything you'd like to discuss or you'd like me to do re lupin merge pls let me know.
[04:37] <cjwatson> xivulon: I've replied to your recent mail
[04:37] <xivulon> reading
[04:38] <cjwatson> <cjwatson@cairhien ~/src/ubuntu/lupin/gutsy/xinit-ubiquity/etc>$ sh -n init.d/xinit-ubiquity
[04:38] <cjwatson> init.d/xinit-ubiquity: 63: Syntax error: "fi" unexpected (expecting ";;")
[04:38] <cjwatson> (easy fix, remove the stray fi)
[04:39] <xivulon> cjwatson, find_preseed is needed to pass a preseed file which is not on the cdrom.
[04:39] <xivulon> In a typical case a run a windows wizard which generates a preseed files and leaves it on the hard disk
[04:40] <cjwatson> ah yes
[04:40] <cjwatson> sorry, obviously a brainfart on my part
[04:40] <xivulon> cjwatson, I did not fully test the scripts, partly because of lack of time, partly because I still have segfault issues
[04:40] <cjwatson> no worries, I'll fix them up
[04:40] <cjwatson> I think maybe 'automatic' as the boot option rather than '--automatic' would be more usual
[04:40] <xivulon> I agree,
[04:41] <cjwatson> or even 'automatic-ubiquity' to be more explicit
[04:41] <cjwatson> something like that anyway
[04:43] <xivulon> I'll write 2 init scripts when I am back, one to set sysctl and one to turn off hybernation/suspend
[04:43] <xivulon> None of those are really necessary, they could be installed by default, since they will just be skept if root is not on a loop device
[04:44] <cjwatson> hmm
[04:44] <xivulon> Something like: if / on loop file: set systcl, turn off hibernation
[04:44] <cjwatson> we could hack it in /etc/init.d/sysctl or whatever it is
[04:44] <cjwatson> probably better to have it clearly separated though
[04:46] <xivulon> I think that the hibernation/suspend check might be useful in other cases, so I'd probably have somethink like: /etc/init.d/checksuspend
[04:46] <cjwatson> acpi-support maybe
[04:48] <xivulon> acpi-support is overridden since when the sleep script is called it uses a --force parameter that ignores the ACPI_SLEEP/ACPI_HIBERNATE
[04:49] <xivulon> if you try to set ACPI_HIBERNATE=false, you can still hibernate from the power manager
[04:49] <cjwatson> I meant putting the init script there
[04:49] <xivulon> ahh
[04:49] <xivulon> yep it makes sense.
[04:50] <xivulon> could you chase mjg59 on suspend with fuse?
[04:50] <cjwatson> I think often one of the things that confuses people about Ubuntu (and indeed Debian) is that we try to spread things out among the packages that would ordinarily be responsible for those areas of functionality, rather than creating a new package for the modifications
[04:50] <cjwatson> yep
[04:50] <cjwatson> (I'll try anyway)
[04:51] <xivulon> that at the moment does not work because things are put to sleep in the wrong order, but it can probably be fixed, that would leave out only hibernation
[04:52] <xivulon> ok I'll take care of the acpi-support script and the sysctl initrd script when I am back.
[04:52] <xivulon> If those go in by default, and the other issues mentioned are addressed there should not be anything left of lupin
[04:53] <cjwatson> I'll beat you to it if I can ;-)
[04:53] <xivulon> hope so!
[04:54] <xivulon> launchpad is a bit moody today!
[04:56] <xivulon> anyway the script that disables hibernation/suspend is in http://codebrowse.launchpad.net/~lupin-team/lupin/devel/annotate/geza0kovacs%40gmail.com-20070807030133-r0qkfwbbzrou4n6c?file_id=postinst-20070516225906-ln9g3688zc5narr5-1
[04:57] <cjwatson> right
[04:57] <xivulon> Note that hibernation should always be avoided when swap is on a file, suspend should be avoided only when fuse is used to mount / (unless mjg59 can fix that)
[04:58] <cjwatson> hello, CIA, please respond
[04:58] <cjwatson> those do both seem like straight bugs
[04:58] <xivulon> So if you do a loopinstallation within an ext3 host, suspend should work
[04:58] <cjwatson> though I guess the former is conceptually tricky
[05:00] <cjwatson> 15:59 <cjwatson> anything feasible to be done
[05:00] <cjwatson> 15:59 <cjwatson> ?
[05:00] <cjwatson> 15:59 <mjg59> No
[05:00] <cjwatson> 15:59 <mjg59> There's some patches in .23 that /might/ help
[05:00] <cjwatson> 15:59 <mjg59> But the entire model is basically broken
[05:00] <cjwatson> so we'll just turn it off
[05:02] <CIA-20> ubiquity: cjwatson * r2196 ubiquity/debian/changelog: formatting
[05:03] <xivulon> re dd use to create the image file, I am not sure what is the end result when using dd on top of ntfs-3g/vfat, but that is something that might be worth testing, since zeroing the full image might take some time
[05:03] <evand> huh, shouldn't installer-for-windows be an approved spec for Gutsy?
[05:04] <cjwatson> probably
[05:04] <evand> also, any objections over me adding not being able to suspend to the release note on w.u.c/InstallerForWindows ?
[05:04] <cjwatson> fine by me
[05:04] <cjwatson> xivulon: yeah, it is a bit slow
[05:05] <cjwatson> on ext3, a sparse file won't actually take up space on the filesystem
[05:05] <cjwatson> so it would be possible to take up space with other files and then run out of space while trying to write to other bits of the sparse file
[05:05] <xivulon> a sparse file is not good
[05:07] <xivulon> when you use in a nested setup (ext3 inside a sparse file in ntfs3) performance is terrible, we had that in the past
[05:08] <xivulon> In windows there is a command to preallocate the disk space, and usually writing the last block will "reserve" the full file, not sure if there is an equivalent in linux
[05:10] <xivulon> I was hoping that something like `dd bs=1m seek=(n-1)m count=1` would do the trick, but I never tested that.
[05:11] <cjwatson> there's a posix_fallocate syscall but I don't know how widely it's implemented
[05:15] <xivulon> that would cut down installation time of a several seconds to a few minutes, but of course it's a feature in the nice-to-have camp
[05:16] <xivulon> re remounting loop files in rw, I could not do that even with good old ext3 (I am not using ntfs-3g at this stage).
[05:17] <xivulon> the issue seems to be that if you create the loop device on top of a ro filesystem, the loop device is in "write protected" mode, and you cannot undo that
[05:17] <xivulon> unless you losetup -d
[05:18] <cjwatson> have you tried blockdev --setrw?
[05:18] <xivulon> nope
[05:18] <cjwatson> might be worth a shot
[05:19] <xivulon> I won't be able to play with it for the next 4-5 days
[05:19] <cjwatson> ok
[05:19] <cjwatson> I'll give it a try, should be easy to set up a test
[05:20] <xivulon> great
[05:20] <xivulon> anything else you'd like to discuss?
[05:21] <cjwatson> I think I need to adapt that xinit-ubiquity thing to handle KDE too, but again that's fairly straightforward (I have the gist of it in oem-config-dm)
[05:22] <xivulon> By the way, I have not tested xinit-ubiquity at all ;P
[05:22] <cjwatson> heh
[05:22] <cjwatson> that's ok
[05:22] <cjwatson> I'm more than happy to be presented with even a gash implementation of something that's been on the wishlist for ages
[05:22] <xivulon> that suits me good
[05:22] <xivulon> One last thing.
[05:23] <xivulon> At the moment we check whether the target folder is vergin or not before installing, and if not we end it then and there
[05:23] <xivulon> Since we have an uninstallation mode, that is a handy feature
[05:24] <cjwatson> yeah, I saw your mention of that in mail
[05:25] <cjwatson> falling over with an error at that point is fine by me
[05:25] <xivulon> yep 8, I have an hook inside casper/casper-bottom/find-preseed
[05:26] <xivulon> but maybe the check should be done by autopartition-loop
[05:27] <xivulon> have to go now. have a nice day and a great w/e
[05:28] <cjwatson> you too
[05:28] <cjwatson> autopartition-loop was certainly where I was thinking of doing it
[05:28] <cjwatson> damn
[05:35] <JD> am I right in thinking I want to edit debian/d-i/shared/modules/nic-modules to add a new module to the nic-modules udeb?
[05:36] <JD> cos I'm sure I did that, but it's not in the resulting udeb and it's not in that file after the build
[05:39] <cjwatson> that's right
[05:39] <cjwatson> kernel-wedge might've spat out some log messages
[05:39] <cjwatson> ?
[05:39] <JD> erm where's that?
[05:40] <JD> log file?
[05:41] <JD> Use of uninitialized value in split at /usr/share/kernel-wedge/commands/gen-control line 36, <KVERS> line 2.
[05:41] <JD> is the only thing after "kernel-wedge gen-control > debian/control"
[05:41] <JD> also, is there anything I can do to make it only build the udebs?
[05:42] <JD> it's just taken over 3 hours to build
[05:46] <cjwatson> stderr ...
[05:46] <cjwatson> you might have to poke at debian/rules for that
[05:46] <cjwatson> I'm sure there's either a target for it, or you can just run the relevant commands
[05:47] <JD> cjwatson: I had a .build file. debuild++
[05:47] <JD> cheers
[05:52] <superm1> cjwatson, could you think of any cleaner of a method to skip pages for the mythbuntu UI other than calling ok_handler directly from set_page?  They shouldn't always be skipped, but just depending on when choices are made.
[05:52] <cjwatson> ask a fake question from somewhere?
[05:52] <superm1> well i still want the questions asked
[05:52] <superm1> but i dont want the user to sit at that screen to answer them
[05:53] <cjwatson> oh, I see, other way round
[05:53] <cjwatson> I think evand is closer to that than I am
[05:53] <evand> will reply in ~10 min
[05:55] <superm1> k
[05:56] <JD> cjwatson: apparently it seems if you change the config.foo files to config.foo.disabled, it won't build them
[05:56] <JD> I could be wrong and it could break horribly
[06:02] <evand> superm1: can you give more context?  when should they be skipped/not skipped?
[06:02] <superm1> evand, yes.  so one of the options i provide is a "standard" vs "advanced" install
[06:02] <superm1> the standard prefills a bunch of the options on other pages
[06:02] <superm1> so the user doesn't have to see them
[06:03] <superm1> the way i've been prefilling them previously was just calling the appropriate gtk widget filling functionality, and then "hiding" the page of the gtk notebook.  now that there is a debconf on every page, i can't do it that way anymore
[06:04] <evand> hrmm
[06:04] <superm1> well at least i can still fill the contents of the page using gtk widget filling functionality
[06:05] <superm1> and the debconf questions still get asked properly
[06:05] <superm1> but i'd like to still hide those pages
[06:09] <evand> can't you do something in set_page like if not in standard mode, set the current page to X?
[06:10] <superm1> well then you still have to hit "ok" to get through the debconf questions for the page your skipping
[06:11] <evand> is this updated code in trunk?
[06:11] <superm1> let me see if i pushed yet
[06:13] <superm1> yea it's pushed
[06:13] <evand> ok, I need a few minutes to finish up something else, and then I'll look through the code to get a better idea of how to handle this
[06:13] <superm1> if you are going to merge it though, ignore the version header at the top of debian/changelog
[06:14] <superm1> k
[07:10] <superm1> evand, i'm going to have to sign off for a bit.  i'll be back on within an hour or two
[07:57] <evand> superm1: It looks like I wont get time to look at it until much later in the day.  I'll keep you posted.
[07:57] <superm1> evand, okay.