[12:20] <evand> mebrown: how far back into the install do you need a callback for an error script?  That is, does this only need to be called if an error occurs in the install process or would you like it to be called if user intervention is reqired at any point during the install?
[12:20] <mebrown> well...
[12:20] <mebrown> in our factory, there wont *ever* be a possibility for user intervention
[12:20] <mebrown> there arent even mice/keyboards/monitors...
[12:20] <mebrown> the purpose of the late_command scripts:
[12:21] <mebrown> 1) hook into our factory process (needs to happen on success or failure) to tell it to move to the next step
[12:21] <mebrown> It will also need to know if it failed or succeeded, so there can possibly be separate command preseed values for failure/success
[12:21] <mebrown> 2) script fixes, and dell stuff
[12:22] <mebrown> for example, changing the firefox homepage
[12:22] <mebrown> 3) install any additional debs
[12:22] <mebrown> for example, modem driver deb.
[12:22] <mebrown> So, if user intervention is required at any point during the install, that is a failure.
[12:23] <mebrown> and the failure scripts should be called
[12:23] <evand> indeed.  To clarify what I meant with the first option, we would consider any kind of required user intervention an error.  But perhaps that's outside of the scope of the initial work?  I'll implement it in the install routine for now and discuss it further with cjwatson
[12:23] <evand> ah
[12:23] <mebrown> you have it, I think
[12:23] <evand> heh, ok
[12:23] <mebrown> any user intervention is a failure
[12:23] <mebrown> because we cannot possibly do a user intervention
[12:23] <xivulon> do you guys mean that early_command/late_command is supported by live iso?
[12:23] <mebrown> what I am doing:
[12:24] <xivulon> or at least early_command?
[12:24] <mebrown> copying live ISO contents to a partition on the hdd
[12:24] <evand> right, that's going to take more work, but it will eliminate the possibility of being left in a state where the computer is running without doing anything.
[12:24] <mebrown> and booting to it with a preseed
[12:24] <mebrown> evand, good.
[12:24] <mebrown> evand, if it sits there, it will continue to sit for hours until somebody notices
[12:24] <mebrown> == double plus ungood
[12:25] <evand> indeed
[12:25] <mebrown> but... I doubt that anything would come up like that after we get it going
[12:25] <mebrown> I mean, everything looks fine so far.
[12:25] <mebrown> I actually want to compliment you guys on how well-done it is.
[12:25] <mebrown> very, very speedy
[12:25] <mebrown> compared to the old alternative cd install
[12:25] <evand> thank you, though cjwatson deserves most of the credit for that.
[12:25] <mebrown> which I threw out because it was too slow
[12:26] <mebrown> and went with my own homegrown method for feisty
[12:26] <evand> yeah, copying files instead of installing packages was a brilliant idea
[12:26] <xivulon> mebrown, evand have a couple of questions if you do not mind
[12:26] <evand> the alternate installer is abysmally slow, as you said
[12:26] <evand> xivulon: sure
[12:26] <xivulon> 1) is early_command working in live ISO?
[12:26] <mebrown> xivulon, ?
[12:26] <mebrown> xivulon, not yet.
[12:26] <evand> xivulon: not yet, but it will be
[12:26] <mebrown> cjwatson, posted a patch
[12:26] <xivulon> great
[12:26] <mebrown> on Tuesday
[12:27] <xivulon> 2) is there a way to "import" files not in the initrd/iso but in the HD?
[12:27] <mebrown> are you booting to hdd or to live cd?
[12:27] <xivulon> hdd
[12:28] <mebrown> the way I did it, yes.
[12:28] <xivulon> in fact mebrown I think we have many things in common
[12:28] <mebrown> the hdd is mounted under /cdrom
[12:28] <xivulon> haa that's unfair
[12:28] <mebrown> basically, /dev/sda1 is the utility partition (dell)
[12:28] <mebrown> for us
[12:28] <mebrown> and /dev/sda2 is the "reinstallation partition"
[12:28] <xivulon> I'll be mounting the real ISO which sits on the HD
[12:28] <xivulon> I see
[12:28] <mebrown> where I basically just 'cp /mnt/cdrom /mnt/sda2'
[12:29] <mebrown> where I basically just 'cp /mnt/cdrom/* /mnt/sda2'
[12:29] <xivulon> mebrown do you need to repartation?
[12:29] <mebrown> I'm not actually using the iso image
[12:29] <mebrown> just the contents
[12:29] <mebrown> xivulon, not really, /dev/sda1 and /dev/sda2 stay there.
[12:29] <mebrown> This is the dell factory install
[12:29] <mebrown> and the customer OS gets put on the rest of the disk
[12:29] <mebrown> and there is a grub boot menu option
[12:30] <mebrown> "reinstall operating system"
[12:30] <mebrown> which boots to /dev/sda2 to re-install
[12:30] <xivulon> hmm but does that change the partition table?
[12:30] <mebrown> ?
[12:30] <mebrown> no
[12:30] <mebrown> just boots to the vmlinuz/initrd.gz on /dev/sda2
[12:30] <xivulon> so you already have a dedicated swap and root partition
[12:31] <xivulon> what I mean is that /dev/sda2 will launch ubiquity
[12:31] <mebrown> yes, they are /dev/sda3 (/boot), /dev/sda5 (swap) /dev/sda6 (root)
[12:31] <xivulon> ubiquity at some points runs partman
[12:31] <xivulon> which uses existing partitions or creates new ones
[12:31] <mebrown> Yes, right now, I am using early_command to delete existing partitions.
[12:31] <mebrown> :)
[12:31] <mebrown> which is why I needed early_command
[12:31] <xivulon> I see some trouble then
[12:31] <mebrown> and I also ask user "hey, we are going to wipe out your data, are you cool with that."
[12:31] <mebrown> ?
[12:32] <mebrown> It is working ok for me now.
[12:32] <xivulon> Hmmm
[12:32] <mebrown> I'm just about to test the wiping of pre-existing partitions as we speek
[12:32] <mebrown> speak
[12:32] <xivulon> As I understand, your HD will have a partition mounted
[12:32] <mebrown> parted works
[12:32] <xivulon> And if you change the partition table (like deleting and recreating the partition)
[12:32] <mebrown> it doesnt use "BLKRRPART" ioctl
[12:32] <mebrown> which wont work when a partition is mounted
[12:32] <mebrown> fdisk uses BLKRRPART and fails
[12:33] <mebrown> as long as you do "parted -s /dev/sda rm 3"
[12:33] <mebrown> "parted -s /dev/sda rm 4"
[12:33] <mebrown> it works just fine, even if /dev/sda2 is mounted
[12:33] <mebrown> :)
[12:33] <xivulon> I see
[12:33] <xivulon> In my case though it might need to resize the root partition
[12:34] <xivulon> which I think it's another ballpark game
[12:34] <mebrown> parted is wonderful
[12:34] <mebrown> man parted
[12:34] <mebrown>  /resize
[12:34] <mebrown> should work for you.
[12:34] <xivulon> not sure it can resize and use a partition which is mounted as /
[12:34] <mebrown> you are trying to resize the partition you have mounted?
[12:35] <xivulon> yeah
[12:35] <mebrown> then, use parted to resize the underlying device, and the online ext resizer
[12:35] <mebrown> I think parted might do that automatically, actually
[12:35] <xivulon> If it worked it would be very nice
[12:36] <xivulon> My partition is ntfs though (I know it can be resized, but according to colin online changes to the partition table might be problematic)
[12:36] <xivulon> I guess I'll have to try and see
[12:36] <mebrown> not sure you can do that online
[12:37] <mebrown> you are booting from the ISO loopback mounted on an NTFS image?
[12:37] <mebrown> you are booting from the ISO loopback mounted on an NTFS partition?
[12:37] <mebrown> and you want to resize the ntfs partition so you can install to the rest?
[12:37] <xivulon> yeah
[12:37] <mebrown> use the "copy ISO to memory" function so that it runs completely from RAM and you can unmount the ntfs partition
[12:38] <mebrown> just requires, iirc 1GB ram
[12:38] <xivulon> hmm that's an issue though
[12:38] <mebrown> fedora can do that.
[12:38] <xivulon> well they are discussing moving to wubi as well
[12:39] <mebrown> I have no idea what wubi is.
[12:39] <xivulon> my installer can install into a file within ntfs already
[12:39] <xivulon> http://wubi-installer.org
[12:39] <xivulon> I wanted to add the capability of also doing a dedicated installation
[12:39] <mebrown> ah.
[12:39] <xivulon> but that requires online resizing, 1GB ram, or some other clever trick
[12:40] <mebrown> online resize usually only works for growing a partition
[12:40] <mebrown> so I would highly doubt that you would be able to do anything with online resize to shrink (shrinking can usually only be done offline)
[12:41] <xivulon> You are probably right
[12:42] <mebrown> I was the lead dev on the Dell server installation cd for 5 years, and have written (from scratch, usually) the factory install for every Linux version Dell sells.
[12:44] <mebrown> I've been waiting for good NTFS tools for a long time. ntfs-3g is pretty nice, but there is only so much you can do... :)
[12:44] <xivulon> I'd better take your word for good then :
[12:44] <xivulon> It works okish for what we do
[12:44] <xivulon> I wish they had fschk
[12:46] <xivulon> do you have extensive experience with ntfs-3g?
[12:50] <mebrown> not really.
[12:50] <mebrown> I moved back to the Linux team at Dell right before I would have started using it
[12:50] <mebrown> and then the team that was going to use it decided <elided...>
[12:51] <mebrown> !#$@%%#
[12:51] <xivulon> I work in finance...
[12:51] <xivulon> ...and have to use windows all day...
[12:51] <xivulon> just managed to get a couple of dedicated ubuntu servers
[12:51] <mebrown> ah. I've mostly eliminated windows from my life
[12:52] <mebrown> at work, I havent had to use a windows machine for months
[12:52] <xivulon> as far as it depends on me, same thing here, at work I have no control
[12:52] <mebrown> and at home havent had a windows machine for a couple years
[12:56] <xivulon> nice to meet you and thanks for the answers above
[12:56] <xivulon> I was wondering in the past days if there was any useful overlap with what you where doing
[12:56] <xivulon> I guess it's mostly early_command
[12:58] <xivulon> evand, talking of early_command at what point does it come into play, can I use it to change it on the fly say /bin/autopartition-loop?
[12:58] <evand> casper
[12:58] <xivulon> after squashfs is mounted?
[12:59] <mebrown> yes
[12:59] <xivulon> perfect
[12:59] <mebrown> the squashfs is mounted at that point under /root
[12:59] <evand> xivulon: http://people.ubuntu.com/~cjwatson/tmp/early_command.diff is the current patch
[12:59] <xivulon> nice
[01:00] <xivulon> I will have to do a small edit to lupin as well
[01:00] <xivulon> so that I can import the files I require (since the will not be waiting for me inside of /cdrom)
[01:09] <xivulon> evand, bzr is stacked at "Submitting revision to CIA"
[01:09] <xivulon> when committing
[01:09] <xivulon> locally
[01:10] <evand> xivulon: CIA seems to be getting overloaded lately.  Your commit will be fine when the CIA plugin fails.
[01:10] <xivulon> can I ctrl+C or do I have to wait?
[01:11] <evand> it should've failed immediately
[01:11] <evand> odd
[01:11] <xivulon> I'll try ctrl+C
[01:11] <xivulon> bzr diff seems ok (nothing)
[01:21] <xivulon> done
[01:31] <xivulon> evand, when I boot from HD ISO (beta one), and shutdown I have unionfs errors
[01:31] <xivulon> Is the killall5 patch also working against the LiveCD?
[01:32] <evand> xivulon: can you post /var/log/syslog containing the errors?
[01:32] <xivulon> hmm difficult since I think what happens is
[01:32] <xivulon> that when you close, fuse is killed
[01:32] <xivulon> = no root
[01:32] <xivulon> = no logs
[01:32] <evand> ah
[01:33] <evand> how do you know you have unionfs errors then?
[01:33] <xivulon> because I have lots of messages about unionfs not able to read block XYZ
[01:33] <xivulon> and then I cannot do anything
[01:33] <evand> ah
[01:33] <xivulon> but I think that's because unionfs sits on top of ntfs which gets killed
[01:34] <evand> hrm, best to talk to cjwatson about that one, as I believe he wrote the killall patch, or did you?
[01:36] <xivulon> https://bugs.launchpad.net/bugs/87763
[01:36] <xivulon> the patch was from cjwatson
[01:37] <xivulon> evand, by the way, I'll be away till monday, if there is anything please send me an email
[01:44] <evand> xivulon: I have an eventful weekend, but I'll try to keep you posted on what happens when I am in front of the computer during it.
[02:10] <xivulon> evand, thanks
[02:10] <xivulon> was just testing the beta
[02:10] <xivulon> it also jams
[02:10] <xivulon> at mkfs.ext3
[02:11] <xivulon> but I am nailing it down...
[02:11] <evand> any new theories on that?
[02:11] <evand> awesome
[02:15] <xivulon> I am simply bisecting
[02:15] <xivulon> basically stopping autopartition-loop at different stages and trying to do the rest manually to see if it jams
[02:17] <xivulon> I can run mkfs ok just before setup_loop ()
[02:17] <xivulon> but inside that it fails
[02:17] <evand> hrm
[02:18] <xivulon> that makes foreach_partition guilty
[02:18] <xivulon> doing another run to confirm that
[02:24] <xivulon> hmm nope, inside of setup_loop() still works, need more work
[03:24] <xivulon> /xivulon KO
[03:25] <xivulon> :(
[03:25] <xivulon> will try again later
[03:27] <evand> heh
[03:28] <evand> yay, I think I've got these hooks polished and working
[03:29] <xivulon> I sent you an  email evand
[03:30] <xivulon> what I run is:
[03:32] <xivulon> set -x ; dd if=/dev/zero of="/host/ubuntu/disks/root.disk" bs="1MB" count=1 seek="3000" ; losetup -f /host/ubuntu/disks/root.disk ; mkfs.ext3 /dev/loop2	; sleep 5000
[03:33] <xivulon> inserting that at different points in autopartition-loop
[03:33] <xivulon> anyway have to go to sleep myself
[03:33] <xivulon> let me know if you find out anything
[03:34] <evand> thanks, will do
[03:34] <xivulon> night
[03:34] <evand> goodnight
[04:25] <superm1> well just as an experiment, i scp'ed in a freshly built ubiquity back onto an older (functional) disk
[04:26] <superm1> and it doesn't freeze at that apt stage
[04:26] <superm1> so something else appears to have caused the breakage
[04:38] <superm1> if i upgrade python-apt in the live env, does ubiquity take advantage of that and use it for its calls, or is the version that was from the read only filesystem that is used for its installation calls at that point?
[05:17] <evand> superm1: yes, it uses it
[05:17] <superm1> evand, well it looks like it is indeed unionfs stuff still then causing issues
[05:17] <evand> is it oopsing?
[05:17] <superm1> looking over pitti's report at https://launchpad.net/bugs/144395
[05:17] <superm1> well i got an oops once
[05:17] <superm1> at that time
[05:18] <evand> did you save it, by any chance?
[05:18] <superm1> every other time its a hang at the identical time period
[05:18] <evand> ah, wow
[05:18] <superm1> i've only gotten the oops once, and it was like the first time, so i didn't make much of it
[05:18] <evand> though it seems cjwatson was already aware of this some days ago
[05:18] <evand> or at least it ooping in that particular area
[05:19] <superm1> so i'm wondering how many multilingual installs of the normal ubuntu beta are going to encounter this
[05:19] <superm1> considering the frequency our daily builds are getting it still
[05:20] <superm1> i talked to kylem a few moments ago in -kernel, and he is going to try to track down that bug tomorrow morning hopefully
[05:20] <superm1> we were planning on doing our beta disk this week too, but with this issue looming it looks like it will have to be delayed
[05:25] <superm1> its too bad that the old kernels are removed from the archive.
[05:25] <evand> they're still on launchpad
[05:27] <superm1> oh they are?  Well maybe in an effort to just get these disks out i'll just use those then, and wget from LP in our build script
[05:27] <evand> sounds quite risky
[05:28] <superm1> hmm. well at very minimum its worth a shot
[05:34] <superm1> well scratch that idea anyhow.  the last known functional version of lum was 2.6.22-10.25.  the binaries are long ago removed from LP
[05:34] <evand> no, they're there
[05:34] <superm1> https://edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.22/2.6.22-10.25
[05:34] <superm1> i see a source package
[05:34] <superm1> but no binaries?
[05:35] <evand> https://launchpad.net/ubuntu/gutsy/i386/linux-ubuntu-modules-2.6.22-10-386/2.6.22-10.25
[05:36] <evand> http://launchpad.net/ubuntu/+builds
[05:36] <superm1> well clearly i'm not experienced in finding things on LP :)
[05:36] <superm1> thanks
[05:37] <evand> no worries, cjwatson pointed me at that recently
[01:50] <JD> morning. I'm possibly being slightly stupid, but my dapper preseeding insists on asking for the hostname, even though I have "d-i netcfg/get_hostname string unassigned-hostname" in the preseed file
[02:51] <JD> okay, apparently you need to add them to the kernel command line
[03:27] <evand> cjwatson: now that we're past beta, is it safe to commit to ubiquity trunk?
[03:28] <cjwatson> evand: yes
[03:28] <cjwatson> superm1_: ^--
[03:28] <evand> thanks
[03:56] <siretart> what part of d-i writes the UUIDs to $target/etc/fstab?
[03:56] <siretart> perhaps this is a better channel than #ubuntu-devel
[03:56] <cjwatson> siretart: partman-target
[03:57] <siretart> I've just looked at cryptsetup-udeb, and I wonder if and why the files in /lib are really necessary
[03:57] <cjwatson> which files in /lib?
[03:58] <siretart> of cryptsetup-udeb
[03:58] <cjwatson> *sigh* I'll go and look then if you won't tell me :)
[03:58] <siretart> http://paste.debian.net/38267
[03:58] <siretart> that are the file contents
[03:58] <siretart> of cryptsetup-udebv
[03:58] <siretart> ./etc seems pretty senseless to me as well
[03:59] <siretart> hm. maybe partman-crypto uses that. lets check
[03:59] <cjwatson> err, I have no idea, they don't seem trivially deletable
[03:59] <cjwatson> the init scripts at least are unlikely to be useful
[03:59] <cjwatson> is that stuff causing a problem?
[04:00] <siretart> no, I don't think so
[04:00] <siretart> I'm currently trying to solve the install on crypto problem
[04:00] <cjwatson> neither partman-crypto nor partman-auto-crypto seem to use them
[04:00] <siretart> and now I try to figure out how cryptsetup-udeb is supposed to work
[04:01] <cjwatson> I think its purpose is just to provide /sbin/cryptsetup
[04:01] <cjwatson> that's all that partman-crypto seems to use
[04:01] <cjwatson> so maybe the rest can be removed
[04:01] <siretart> *nod*
[04:01] <cjwatson> assuming that /sbin/cryptsetup doesn't use them itself
[04:01] <cjwatson> I haven't check
[04:01] <cjwatson> ed
[04:02] <siretart> I *think* that it would be easiest to not use UUIDs for crypto volumes, but the device nodes in /dev/mapper/
[04:02] <cjwatson> on phone, back later
[04:15] <CIA-18> ubiquity: evand * r2264 ubiquity/ (configure configure.ac): Bump to 1.5.19
[04:20] <CIA-18> ubiquity: evand * r2265 ubiquity/ (debian/changelog ubiquity/components/migrationassistant.py): * Slight improvement for automating migration-assistant.
[04:23] <CIA-18> ubiquity: evand * r2266 ubiquity/ (8 files in 3 dirs):
[04:23] <CIA-18> ubiquity: * Add preseed hooks for rebooting, install failure, and install
[04:23] <CIA-18> ubiquity:  success.
[04:40] <evand> cjwatson, superm1_: do you have anything else you want to land in 1.5.19 before I release it?
[04:40] <superm1_> evand, i just looked at your changes there
[04:40] <superm1_> should those be applicable to us too you think?
[04:40] <superm1_> with the reboot hooks
[04:41] <superm1_> that would be the only thing i'd think
[04:42] <evand> I put them in to stay consistent with the rest of the frontends.  Whether or not you use them is entirely up to you :)
[04:42] <superm1_> okay for now then i'll say don't worry about it, as long as the old method still works for us, no use breaking things uselessly yet :)
[04:42] <cjwatson> evand: translation update is all
[04:42] <evand> If you don't preseed those options, it should work exactly the same as before
[04:43] <superm1_> ok good
[04:43] <superm1_> yeah then i'm good with 1.5.19 being released
[04:43] <evand> cjwatson: ah, thanks for reminding me
[04:43] <cjwatson> evand: (I'm waiting for a Launchpad download now)
[04:50] <siretart> cjwatson: I think http://paste.debian.net/38271 should fix bug #144390
[04:50] <siretart> https://bugs.edge.launchpad.net/ubuntu/+source/cryptsetup/+bug/144390
[04:50] <siretart> but I'm not sure how to test that. I've never built d-i before :)
[04:51] <siretart> I hope that the patch does the following:
[04:51] <siretart> if there is an entry like /dev/mapper/sda5_crypt, leave it as it is
[04:52] <siretart> so crypto volumes shouldn't be mangled to UUID, which breaks the cryptroot script
[04:58] <cjwatson> siretart: afraid not, that would affect LVM too and pull us out of sync with what volumeid.postinst does
[04:59] <cjwatson> siretart: you don't need to build d-i - you can edit that file on the fly before it runs
[04:59] <cjwatson> if it's always *_crypt, that's easily detected
[04:59] <cjwatson> is it?
[05:05] <evand> cjwatson: I'm confused by your last statement to me.  You're waiting for a launchpad download of what?  Should I hold off on running debconf-updatepo?
[05:10] <cjwatson> evand: yes, please hold off
[05:10] <cjwatson> sorry, I was on the phone and thus distracted
[05:11] <cjwatson> translations are downloaded from Launchpad
[05:11] <evand> not a problem
[05:11] <cjwatson> the process is that you press a button and then it mails you the URL to a tarball when it's finished
[05:11] <cjwatson> so it usually involves a bit of a wait
[05:11] <cjwatson> I've got them now and will start mergeing
[05:11] <cjwatson> merging (argh!)
[05:11] <evand> yikes
[05:11] <cjwatson> the hooks you added shouldn't involve translations?
[05:12] <cjwatson> oh, but mythbuntu stuff does. GAH stop it :)
[05:12] <evand> ah, good point, that they do not
[05:12] <cjwatson> superm1_: any strings you add from this point on will not be translated
[05:13] <superm1_> cjwatson, that's okay
[05:13] <superm1_> at this point there shouldn't be any more added hopefully anyhow
[05:13] <superm1_> er from this point <i>forward</i> there shouldn't be
[05:21] <CIA-18> ubiquity: cjwatson * r2267 ubiquity/debian/ (79 files in 2 dirs): * Update translations from Rosetta.
[05:22] <cjwatson> evand: one more thing before debconf-updatepo ...
[05:22] <evand> ok
[05:23] <CIA-18> ubiquity: cjwatson * r2268 ubiquity/debian/ubiquity-frontend-mythbuntu.templates: mark ${PARTMAN_CHANGES} in mythbuntu/summary as untranslatable
[05:23] <cjwatson> evand: ok, all done
[05:24] <cjwatson> evand: how about bumping to 1.6.0 too?
[05:24] <cjwatson> I usually release with an even minor version and use odd during development
[05:24] <evand> for this release or the next?
[05:24] <cjwatson> somewhere around beta seems like a plausible time for that
[05:24] <cjwatson> evand: either, I don't mind
[05:27] <CIA-18> ubiquity: cjwatson * r2269 ubiquity/debian/rules: remove some commented-out rules cruft
[05:27] <evand> yay bound branches
[05:28] <cjwatson> heh
[05:30] <CIA-18> ow
[05:30] <evand> I'm never going to get tired of that.
[05:31] <CIA-18> ubiquity: evand * r2270 ubiquity/debian/po/ (79 files): debconf-updatepo
[05:31] <cjwatson> haha, I never noticed that before
[05:31] <evand> curious, I thought that CIA bit didn't go through
[05:31] <evand> yeah, I discovered it by mistake the last time he threw 500 errors at me
[05:31] <cjwatson> sometimes it doesn't quite manage to acknowledge it but sends it anyway
[05:32] <evand> odd
[05:33] <CIA-18> ubiquity: cjwatson * r2271 ubiquity/debian/ (changelog control):
[05:33] <CIA-18> ubiquity: * Set Maintainer to ubuntu-installer@lists.ubuntu.com and put Evan and
[05:33] <CIA-18> ubiquity:  myself in Uploaders.
[05:34] <superm1_> oh there's an ubuntu-installer ML?
[05:35] <evand> indeed
[05:36] <CIA-18> ubiquity: evand * r2272 ubiquity/ (configure configure.ac): bump to 1.6.0
[05:37] <evand> speaking of which, cjwatson is there a set policy on lists other than ubuntu-devel?  Specifically, do list admins usually approve reasonable messages from unsubscribed individuals?
[05:37] <cjwatson> it varies by list, but ubuntu-installer is only moderated to fend off spam
[05:38] <evand> I'm thinking about ubuntu-devel-discuss specifically
[05:38] <evand> I imagine the answer is yes
[05:38] <evand> but I just want to check before I go approving such emails
[05:38] <cjwatson> that's explicitly unmoderated; it might happen to have a moderation-like queue but again that's only to fend off spam
[05:38] <evand> ok, good
[05:39] <cjwatson> actually I tell a lie, it says "open for all to subscribe, posting moderated for non-subscribers"
[05:39] <cjwatson> I'm pretty sure it's meant to be unmoderated in spirit though
[05:39] <evand> so I should still approve reasonable posts, correct?
[05:40] <cjwatson> yeah
[05:40] <evand> ok
[05:41] <CIA-18> ubiquity: evand * r2273 ubiquity/debian/changelog: forgot to update changelog to 1.6.0
[05:42] <cjwatson> evand: thanks for that hooks work, looks great
[05:43] <evand> thanks
[05:45] <evand> any other changes before I update the manifest and send this to pbuilder?
[05:48] <cjwatson> none from me
[05:48] <cjwatson> (not urgent anyhow)
[05:49] <siretart> cjwatson: yes, they are always _crypt
[05:49] <siretart> cjwatson: that would be my 2nd guess
[05:49] <siretart> so (/dev/disk/*|/dev/fd[0-9] *|/dev/mapper/*_disk) would be it?
[05:49] <CIA-18> ubiquity: evand * r2274 ubiquity/ (d-i/manifest debian/changelog):
[05:49] <CIA-18> ubiquity: * Automatic update of included source packages: hw-detect 1.53ubuntu3,
[05:49] <CIA-18> ubiquity:  kboot-installer 0.0.1ubuntu5, partman-base 107ubuntu4, partman-
[05:49] <CIA-18> ubiquity:  basicfilesystems 54ubuntu4, user-setup 1.14ubuntu3, yaboot-installer
[05:49] <CIA-18> ubiquity:  1.1.11ubuntu2.
[05:51] <cjwatson> siretart: LVM disks aren't named like that - I think it needs two case entries unfortunately
[05:51] <evand> cjwatson: so there are some really old messages in the queue for this list, the current message I have up being from January of this year.  What would you say is a reasonable cut off for approving messages in the back log? 1 month? 2?
[05:52] <cjwatson> for the old messages, I'd start by trying to guess if they still apply
[05:52] <cjwatson> maybe two or three months
[05:52] <evand> ok, I'll check to see if they subscribed and posted as well
[05:52] <evand> thanks
[05:53] <cjwatson> beyond that I'd make sure the rejection message is soft - something like "Sorry we weren't handling the moderation queue at that point, but we are now; your message was very old, but if it still applies, please resend"?
[05:53] <evand> ah, good idea
[05:54] <cjwatson> siretart: putting together a possible diff now
[05:56] <siretart> thanks
[05:57] <siretart> has partman-crypto been disabled for beta? - if yes, where?
[06:01] <mebrown> evand, ping...
[06:01] <evand> mebrown: pong
[06:01] <mebrown> to test your late_command patch,
[06:02] <mebrown> I was thinking I could patch the python files
[06:02] <mebrown> and then copy them over in early_command
[06:02] <mebrown> instead of having to regen the entire squashfs
[06:02] <evand> sounds reasonable
[06:03] <cjwatson> siretart: yes, by moving it to universe
[06:03] <siretart> ah, okay
[06:03] <mebrown> evand, ok. I'm getting everything patched in now. Should have a test run in 30 mins or so...
[06:04] <evand> great, I'm working on getting the latest ubiquity out, and then hopefully a new cd build
[06:04] <cjwatson> yeah, early_command is actually a superset of all other hooks :-)
[06:04] <evand> uhh, curious.  Is gtk broken?
[06:04] <evand>   libgtk2.0-dev: Depends: libgtk2.0-0 (= 2.12.0-1ubuntu1) but it is not going to be installed
[06:04] <cjwatson> *blink*
[06:04] <evand> in pbuilder
[06:04] <cjwatson> sounds like mild desync
[06:04] <cjwatson> is your pbuilder fully updated?
[06:04] <evand> just updated
[06:05] <cjwatson> which arch?
[06:05] <evand> amd64
[06:05] <cjwatson> libgtk2.0-0 | 2.12.0-1ubuntu1 |         gutsy | amd64, hppa, ia64, powerpc, sparc
[06:05] <cjwatson> libgtk2.0-0 | 2.12.0-1ubuntu2 |         gutsy | i386, lpia
[06:05] <cjwatson> needs to build on amd64
[06:05] <evand> ah
[06:05] <cjwatson> the problem will be that:
[06:05] <cjwatson> libgtk2.0-common | 2.12.0-1ubuntu2 |         gutsy | all
[06:05] <cjwatson> archive reference-counting isn't quite as good as it ought to be
[06:06] <evand> should I just skip pbuilder and upload, or wait it out?
[06:06] <cjwatson> in an ideal world, -common -1ubuntu1 would stick around in the amd64 Packages files until the arch-dep binaries were built
[06:06] <evand> indeed
[06:06] <cjwatson> I'd skip pbuilder, I don't think we've made any changes that are likely to cause it to fail
[06:06] <cjwatson> hmm, fstab_hd_entries is bogus for loop
[06:07] <cjwatson> I'm not sure what I was thinking
[06:07] <CIA-18> ubiquity: evand * r2275 ubiquity/debian/changelog: releasing version 1.6.0
[06:08] <evand> cjwatson: if you have a moment, can you sponsor: http://people.ubuntu.com/~evand/upload/ubiquity_1.6.0.dsc
[06:09] <cjwatson> downloading
[06:11] <cjwatson> siretart: oh, I didn't look at the code closely enough
[06:11] <cjwatson> (/dev/disk/*|/dev/fd[0-9] *|/dev/mapper/*_crypt) would do fine
[06:12] <cjwatson> was your _disk above a typo?
[06:13] <siretart> err, right. that was what I meant
[06:13] <siretart> because that's what partman-crypto names the devices, as the cryptroot hook is expecting that
[06:14] <siretart> using a UUID of a crypted device doesn't make too much sense anyway, since you need the key to figure the uuid out
[06:14] <siretart> shall I upload that small diff?
[06:14] <cjwatson> siretart: I've got stuff in bzr
[06:14] <siretart> ok
[06:14] <siretart> then I'll commit to bzr, okay?
[06:14] <cjwatson> siretart: could you commit it to bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/partman-target/ubuntu/ and upload from there?
[06:15] <cjwatson> or I can upload, whichever
[06:15] <siretart> allright, on my way
[06:15] <cjwatson> siretart: please also get volumeid.postinst changed
[06:15] <cjwatson> it needs to match
[06:15] <siretart> aaah, right. okay
[06:18] <siretart> is udev bzr managed as well?
[06:18] <cjwatson> siretart: no
[06:18] <siretart> ok
[06:18] <cjwatson> (at least not AFAIK; check with Keybuk if he happens to be around, but otherwise I'd suggest just uploading
[06:18] <cjwatson> )
[06:18] <siretart> ok
[06:19] <siretart> last commit 67 commits ago. lets just assume 'no' :)
[06:19] <siretart> 67 weeks ago, even
[06:19] <cjwatson> evand: uploaded
[06:20] <cjwatson> yeah, he said he tried for a bit but it didn't work out
[06:20] <evand> cjwatson: thanks
[06:33] <siretart> cjwatson: partman-target and udev uploaded
[06:39] <cjwatson> cool, thanks
[06:42] <siretart> I guess this means that partman-crypto can be moved to main again
[06:52] <cjwatson> should be possible, check with pitti
[07:42] <evand> whoops, I forgot lp bug references for the hooks
[08:26] <mebrown> cjwatson, evand, not-script-related bug report
[08:26] <mebrown> I'm trying to get grub installed *not* in the MBR
[08:26] <mebrown> but, rather, in the PBR for /dev/sda3
[08:27] <mebrown> # the kernel command line should be:
[08:27] <mebrown>     /casper/vmlinuz preseed/file=/cdrom/preseed/dell.seed boot=casper apt-setup/use_mirror=false apt-setup/security_host= oem-config/enable=true automatic-ubiquity
[08:27] <mebrown> doh. (wrong copy/paste
[08:27] <mebrown> The preseed file contains:
[08:27] <mebrown> d-i grub-installer/only_debian boolean false
[08:27] <mebrown> d-i grub-installer/with_other_os boolean false
[08:27] <mebrown> d-i grub-installer/bootdev  string (hd0,2)
[08:28] <mebrown> but it is still doing "grub-install (hd0)", as read from the GUI, and it ends up overwriting my MBR
[08:28] <evand> yikes, components/install.py blindly overwrites those values
[08:28] <evand> I'll cook up a fix now
[08:28] <mebrown> ok, thanks.
[08:36] <siretart> are the buildlogs for the livecd publicy available? if so, where?
[08:36] <siretart> and for the alternate cd?
[08:36] <evand> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/
[08:37] <evand> http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/
[08:37] <evand> siretart: ^
[08:37] <siretart> aah, thanks
[08:37] <evand> you're welcome
[08:42] <siretart> just curious, is the script, that produces that output and creates the alternate cds, available somewhere by chance?
[08:44] <evand> http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/README
[08:44] <evand> there's also a branch of debian-cd in his bzr folder
[08:44] <evand> err directory
[08:44] <evand> too much windows
[08:44] <siretart> wow! thanks alot!
[08:59] <evand> mebrown: http://people.ubuntu.com/~evand/tmp/ubiquity_preseed_grub.diff
[08:59] <evand> untested, but that should work
[08:59] <mebrown> ok. I'll add it to my install.
[09:00] <mebrown> Just got the patched files into the install.
[09:00] <evand> great
[09:00] <mebrown> *just* finished first install with the patched files.
[09:00] <evand> heh
[09:00] <mebrown> trying to see evidence that it ran my scripts.
[09:00] <mebrown> ...
[09:00] <evand> it worked?
[09:00] <evand> ah
[09:01] <mebrown> looking...
[09:01] <mebrown> This line did not, apparently:
[09:01] <mebrown> ubiquity ubiquity/reboot boolean true
[09:01] <mebrown> because it kicked into live environment
[09:01] <mebrown> rather than rebooting
[09:01] <evand> hrmm, what do you mean by kicked into the live environment?
[09:02] <mebrown> when automatic-ubiquity was finished
[09:02] <mebrown> when it would normally put up reboot/continue live dialog
[09:02] <mebrown> it just exited
[09:02] <mebrown> and the live env came up.
[09:02] <evand> very odd, I'll look into it now
[09:03] <mebrown> and i'm not seeing evidence that my scripts ran, but need a couple mins
[09:03] <mebrown> to look more closeley
[09:03] <evand> ok
[09:03] <CIA-18> ubiquity: evand * r2276 ubiquity/configure.ac: bump to 1.6.1
[09:05] <mebrown> ah.
[09:05] <mebrown> Traceback (hand copied...)
[09:05] <evand> uh oh
[09:05] <CIA-18> ubiquity: evand * r2277 ubiquity/ (debian/changelog ubiquity/components/install.py): * Modified the install component to allow grub preseeding in automatic mode.
[09:05] <mebrown> /var/log/installer/debug
[09:06] <mebrown> in /usr/lib/ubiquity/ubiquity/frontend/base.py
[09:06] <mebrown> NameError: global name 'subprocess' is not defined
[09:06] <evand> UGH
[09:06] <mebrown> in "subprocess.call(['sh', '-c', self.success_cmd] )
[09:07] <evand> how did that fall out of my patch?  I remember typing that exact line.
[09:07] <mebrown> and then it fails similarly
[09:07] <evand> well, that's a simple fix
[09:07] <mebrown> on self.error_cmd
[09:07] <mebrown> well, at least we now know that the error_cmd works. :)
[09:07] <evand> heh, indeed
[09:08] <mebrown> missing one line?
[09:08] <evand> yup, just add import subprocess to the top of base.py
[09:08] <mebrown> an "import subprocess"? or something else?
[09:08] <mebrown> ok.
[09:08] <mebrown> just a sec and I'll test this with the grub fix
[09:08] <evand> sorry about that
[09:08] <mebrown> no problem.
[09:09] <CIA-18> ubiquity: evand * r2278 ubiquity/ (debian/changelog ubiquity/frontend/base.py): * Add missing subprocess import to base.py.
[09:11] <mebrown> question: any way from my scripts to update the progress bar text?
[09:11] <mebrown> (nice to have, not at all required)
[09:12] <mebrown> as in, if it doenst exist, dont go off and create it.
[09:12] <evand> ermm, I don't *believe* you can hijack debconf like that, but cjwatson might know of a way
[09:12] <mebrown> new install going right now with added import and grub fix
[09:13] <evand> I'm setting up my own testbed for this at the moment.
[09:13] <mebrown> I have a pretty nice setup. Everything copied to the hdd on one machine. edit the stuff on another and rsync over changes
[09:13] <evand> nice
[09:14] <mebrown> basically a 5 minute turnaround on script fixes.
[09:14] <cjwatson> mebrown: wouldn't think there's a progress bar up at the point when those are called
[09:14] <cjwatson> unless you mean a script that's calling ubiquity?
[09:15] <mebrown> the post stuff that evand just added
[09:15] <mebrown> I'm trying to test his patch right now
[09:15] <cjwatson> the progress bar should've been torn down by then
[09:15] <mebrown> ok, then.
[09:15] <mebrown> no big deal.
[09:15] <cjwatson> though I understand what you mean
[09:15] <mebrown> was going to use it for debugging, but I'll just echo to /dev/tty1
[09:15] <cjwatson> stdout/stderr should go to /var/log/installer/debug, FWIW
[09:16] <mebrown> ok, nice.
[09:16] <mebrown> just found that, myself.
[09:16] <cjwatson> actually, just stderr
[09:17] <cjwatson> evand: if you're conditionally preseeding grub-installer/bootdev, you should apply the same condition to with_other_os and only_debian
[09:17] <cjwatson> they're only preseeded so that the bootdev preseed is guaranteed to take effect
[09:17] <evand> ahh, I initially had it like that but I figured they were d-i specific
[09:17] <evand> err that wouldn't make sense anyway, nevermind, I'll fix it
[09:18] <cjwatson> might want to add a comment, it's clearly not obvious
[09:18] <evand> will do
[09:18] <mebrown> hmm... evand, it tried to reboot this time...
[09:19] <evand> isn't that a good thing?
[09:19] <mebrown> although, this daily build (24 sept) doesnt seem to actually reboot
[09:19] <mebrown> its good in that I think your preseed reboot screen might be working now
[09:19] <cjwatson> as in, gets nearly all the way down and then hangs?
[09:19] <mebrown> actually, yes.
[09:19] <evand> hit enter
[09:19] <evand> but yes, '
[09:19] <cjwatson> oh, that
[09:19] <evand> tis a bug
[09:19] <cjwatson> damnit
[09:19] <mebrown> yes, with some networkManager stuff
[09:19] <cjwatson> the n-m stuff is likely unrelated
[09:20] <mebrown> evand, your preseed thing for reboot works.
[09:20] <evand> \o/
[09:20] <mebrown> it was just crashing before that last time
[09:20] <mebrown> Now I'll need to check to see if my scripts ran...
[09:20] <mebrown> cjwatson, I was thinking it was probably unrelated.
[09:20] <mebrown> I was going to report it next week if it still was in the daily builds then...
[09:21] <mebrown> evand, and the grub preseed you sent worked for me...
[09:21] <mebrown> If you are going to update it, I can test the updated version as well if you would like
[09:21] <cjwatson> wonder how /etc/init.d/casper should go about checking that /cdrom is actually mounted off the hard disk
[09:21] <cjwatson> what do you pass on the command line to get it to do that?
[09:22] <mebrown> nothing
[09:22] <mebrown> it just finds it.
[09:22] <cjwatson> ah
[09:22] <mebrown> are you talking about the launchpad I entered?
[09:22] <mebrown> about the CDROM boot finding the hdd image?
[09:22] <cjwatson> I'm looking at how to stop it asking you to eject the CD on shutdown
[09:23] <mebrown> Well, it shouldnt be super-critical for me, personally,
[09:23] <cjwatson> you can just nobble the init script to take that out
[09:23] <mebrown> since we will most likely just have a 'reboot -fn' in our ubiquity/success_command
[09:23] <cjwatson> ah
[09:24] <cjwatson> why -n? wouldn't you want to sync first?
[09:24] <mebrown> maybe.
[09:24] <evand> heh
[09:24] <mebrown> will probably need to umount /target
[09:24] <mebrown> but the /cdrom fs is RO, anyways
[09:26] <CIA-18> ubiquity: evand * r2279 ubiquity/ (debian/changelog ubiquity/components/install.py):
[09:26] <CIA-18> ubiquity: * Respect preseeded values for grub-installer/with_other_os and
[09:26] <CIA-18> ubiquity:  grub-installer/only_debian.
[09:28] <evand> ubiquity ftbfs ftw
[09:33] <mebrown> evand, another traceback...
[09:33] <mebrown> I commented out the ubiquity/reboot command
[09:33] <mebrown> so that I could look at debug logs before it rebooted
[09:33] <evand> ok
[09:33] <mebrown> and now it traces back after creating fs
[09:33] <mebrown> DebconfError: (10, "ubiquity/reboot doesnt exist")
[09:34] <mebrown> line 96 of site-packages/debconf.py
[09:34] <mebrown> from line 60 of site-packages/debconf.py
[09:34] <mebrown> from line 63 of components/install.py
[09:34] <mebrown> reboot = self.db.get('ubiquity/reboot')
[09:34] <mebrown> fyi...
[09:34] <evand> yeah, it's expected to at least be there, just not set, as it gets created when ubiqutiy gets installed
[09:34] <evand> I'm assuming you removed it from debconf?
[09:35] <mebrown> No...
[09:35] <mebrown> I just removed it from my preseed
[09:35] <evand> ...interesting
[09:35] <evand> ohh
[09:35] <mebrown> I'll put it back, but leave it false for now
[09:35] <evand> it will be there automatically once we have updated CDs
[09:35] <evand> it's just that you're manually patching things in, so you're working with the old ubiquity templates
[09:36] <mebrown> ...
[09:36] <mebrown> I patched the template too
[09:36] <mebrown> with the patch you sent...
[09:36] <evand> and that only gets added to debconf when ubiquity is installed
[09:36] <evand> sorry, I should've mentioned that
[09:36] <cjwatson> you probably need to patch /var/cache/debconf/templates.dat as well
[09:36] <cjwatson> if you're doing it on the fly
[09:36] <mebrown> oh. ok.
[09:36] <mebrown> I wont worry about it then.
[09:37] <cjwatson> evand: the build failures are just fallout from uninstallables
[09:38] <mebrown> oh, btw, I can confirm that my ubiquity/failure_command did indeed work this time
[09:38] <mebrown> after the traceback, my command was run
[09:38] <mebrown> which happened to be a script with a 'sleep 60000' at the end
[09:39] <mebrown> :)
[09:39] <evand> cjwatson: indeed, I did notice that.  I was hoping to get new CDs out soon, but it looks like we'll need another ubiquity release at some point anyway.
[09:41] <evand> cjwatson: should we release note ubiquity being able to do preseeded installations?
[09:42] <evand> for the Gutsy announcement, that is.  Or is it not a big enough item to warrant it?
[09:42] <mebrown> pretty big deal for me... :)
[09:42] <evand> haha
[09:43] <evand> yeah, but you're just Dell ;)
[09:47] <mebrown> ok. I'm happy.
[09:47] <mebrown> my success_script is running now
[09:47] <mebrown> I just have to now debug from there (my problem)
[09:47] <mebrown> paths and whatnot have changed
[09:49] <evand> great
[10:38] <mebrown> evand, cjwatson so the success_command runs when the dialog is still up...
[10:38] <mebrown> and it looks like oem-config-prepare "helpfully" puts up a friendly dialog when run
[10:38] <mebrown> ugh.
[10:39] <evand> mebrown: which dialog?
[10:39] <evand> in the first case
[10:40] <mebrown> the progress dialog is up while my scripts run,
[10:40] <mebrown> but is not responsive to input.
[10:40] <mebrown> no big deal at all
[10:40] <mebrown> and I'll unset DISPLAY before running oem-config-prepare
[10:40] <mebrown> so it cant pop up a dialog
[10:40] <evand> ah, ok
[10:41] <mebrown> so, I think porting of all my scripts is basically done.
[10:41] <evand> I'll see if I can't fix that in ubiquity trunk
[10:41] <evand> great!
[10:41] <mebrown> I'll need to investigate /target unmounting next
[10:41] <mebrown> need to decide if I want to run my own reboot command
[10:41] <mebrown> or let ubiquity reboot things
[10:50] <ebrahim> Hi there! Why there is no package selection in the installer (and even no plan to include it)?!?
[10:51] <mebrown> evand, can you drop me a note when there is a daily build with your scripting hooks?
[10:52] <evand> ebrahim: No.  My understanding, and please note that I am *not* an authority on this, is that this is an Ubuntu design decision.
[10:52] <evand> mebrown: surely
[10:52] <mebrown> thanks.
[10:53] <evand> ebrahim: The idea is to present the user with a reasonable default.
[10:53] <mebrown> I'll be very happy to be able to "rm -rf TEMPORARY_FIXES   05-apply-temporary-fixes.sh"
[10:53] <evand> ebrahim: Ubuntu does this wherever possible, and lets the power users drill through the dialogs to change things, rather than make the average person drill through a bunch of options that they do not understand.
[10:53] <mebrown> evand, did you want a copy of my scrips/preseed, for reference?
[10:54] <ebrahim> evand, it could be a choice if you want to select packages or not, default to "no"!
[10:54] <evand> mebrown: actually, that would help quite a bit
[10:54] <mebrown> ok. I'll post a tarball for you in a bit. Just removing lots of unneeded debugging cruft.
[10:54] <evand> ebrahim: but that misses the point that the average user does not necessarily know what the option itself means.
[10:55] <evand> ebrahim: the same thing is done with compiz
[10:55] <ebrahim> evand, right!
[10:55] <evand> and there's a discussion about this on one of the mailing lists
[10:55] <evand> I think ubuntu-devel-discuss
[10:56] <evand> ebrahim: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-September/001793.html
[10:57] <evand> probably best to read through the entire thread.
[11:00] <ebrahim> evand, interesting!
[11:21] <mebrown> evand, http://linux.dell.com/libsmbios/download/meb-temp/
[11:21] <mebrown> my current script set
[11:21] <mebrown> and preseed
[11:21] <mebrown> nothing dell-proprietary in there...
[11:22] <mebrown> just posted -03, it will sync to the mirrors in about 10 mins.
[11:22] <mebrown> the -02 version is there now.
[11:24] <mebrown> evand, ping...
[11:26] <evand> mebrown: thanks, pong
[11:27] <mebrown> will need some help on monday with language packs
[11:27] <mebrown> need the following:
[11:27] <mebrown> d-i pkgsel/language-packs string ar pt cs da nl fi fr de el he hu it ja ko no nb nn pl ru zh cs sv tr
[11:27] <mebrown> but apparently it is trying to pull from the (nonexistent) apt repo
[11:27] <mebrown> will need to know how I can deal with that, because those langagues are what I need installed
[11:28] <mebrown> I believe it is already public knowledge that we are going to launch in non-us 'soon', and this is a prereq...
[11:28] <mebrown> I'm just finishing up for today, so no time to work on it.
[11:28] <mebrown> but will probably need a creative solution.
[11:29] <mebrown> For feisty, I just did an 'apt-get install language-pack-xx ..." and then copied the apt cache dir and installed all the debs in my post
[11:29] <evand> ok
[11:29] <mebrown> but was thinking there might be another (better) way
[11:29] <evand> the language packs are no longer include on the CD, which is why it's trying to pull them from a repo
[11:29] <evand> there wasn't enough space
[11:29] <mebrown> ah.
[11:30] <mebrown> does the DVD have them?
[11:30] <mebrown> if it does, I can just switch to the live DVD
[11:30] <evand> good question, I'd imagine so
[11:30] <evand> but I do not know for sure
[11:30] <superm1_> what grew so much that they dont fit any more?
[11:30] <evand> OpenOffice.org
[11:30] <mebrown> ok. Well, I'll leave that for monday, then.
[11:30] <superm1_> ah of course
[11:30] <mebrown> If you get a chance to ask somebody, would be great.
[11:30] <evand> it is an insatiable beast.
[11:31] <evand> mebrown: actually, I think I can check real quick here
[11:31] <mebrown> ok...
[11:31] <mebrown> I have ~29 minutes before I have to walk out the door
[11:31] <mebrown> :)
[11:31] <evand> mebrown: hrmm, they do not appear to be
[11:31] <evand> http://cdimage.ubuntu.com/dvd/20070925/gutsy-dvd-amd64.manifest
[11:31] <evand> I'll investigate further though
[11:31] <evand> but I'll let you go :)
[11:31] <evand> enjoy your weekend
[11:32] <mebrown> Thanks, you too.
[11:32] <mebrown> that manifest only has english language packs.
[11:32] <evand> indeed, that's what I'm pointing out
[11:32] <evand> they don't appear to be included on the DVD, which is odd
[11:32] <evand> but I'll ask cjwatson about it
[11:32] <mebrown> Is there a apt-repo on the DVD?
[11:33] <mebrown> I noticed that there is an apt repo on the CD
[11:33] <mebrown> might that contain lang packs?
[11:33] <evand> oh wow
[11:33] <evand> I'm an idiot
[11:33] <evand> good call
[11:33] <evand> http://cdimage.ubuntu.com/dvd/20070925/gutsy-dvd-amd64.list
[11:34] <mebrown> hey, I'm new to this whole debian thing...
[11:34] <evand> heh
[11:34] <mebrown> So, I've been trying to make sure I read everything I can from google before I open my mouth to stick in foot.
[11:35] <evand> no worries, I am quite ok with fielding questions
[11:35] <mebrown> will probably need some help configuring the installer to look for the apt repo from the hdd.
[11:35] <mebrown> monday.
[11:35] <evand> it should automatically
[11:35] <evand> but yes
[11:35] <mebrown> ok, then,
[11:35] <evand> I have to run as well
[11:35] <mebrown> I'll just switch to the DVD and try it then.
[11:35] <mebrown> see you later.