[09:08] <ev> heads up - releasing a new ubiquity to take care of the slideshow variable issue
[09:10] <CIA-41> ubiquity: evand * r3705 ubiquity/ (d-i/manifest debian/changelog):
[09:10] <CIA-41> ubiquity: Automatic update of included source packages: console-setup
[09:10] <CIA-41> ubiquity: 1.34ubuntu7, grub-installer 1.49ubuntu2, partman-uboot 3.
[09:17] <CIA-41> ubiquity: evand * r3706 ubiquity/bin/ubiquity-dm: Found another missing exception parameter.
[09:36] <CIA-41> ubiquity: evand * r3707 ubiquity/debian/changelog: releasing version 2.1.13
[09:46] <davmor2> cjwatson: is today a good day to look at that grub issue in hardy, although I need to take the MIL off to hospital in a bit so it won't be till after that
[09:52] <davmor2> cjwatson: Bug 185878
[09:52] <ubottu> Launchpad bug 185878 in grub "GRUB installation fails if installing to certain non-ext3 filesystems" [High,Fix committed] https://launchpad.net/bugs/185878
[09:54] <cjwatson> davmor2: hope so but I'm not sure yet
[09:56] <CIA-41> ubiquity: evand * r3708 ubiquity/debian/ (changelog control): Add missing build dependency on keymapper.
[09:56] <davmor2> cjwatson: as I say it won't be till later any how I'll give you a shout when I get back :)
[10:00] <CIA-41> ubiquity: evand * r3709 ubiquity/d-i/update-control: Put keymapper build dependency in the right place.
[10:09] <ev> superm1: I'm not sure I understand the motivation for splitting out install_misc, given that the only place it's used is in the Install subclass.
[10:21] <CIA-41> ubiquity: evand * r3710 ubiquity/debian/changelog: releasing version 2.1.14
[11:56] <dmarkey> sorry for repeating myself, but is there a way to get the LVM partitioner to place /boot on the first partition
[11:58] <cjwatson> probably not automatically
[11:58] <cjwatson> I'm sure you can do it using the manual partitioner
[11:59] <cjwatson> or using a custom recipe
[11:59] <dmarkey> ok, well in that case can i disable the lvm partitioner
[11:59] <cjwatson> sure, please see the installation guide
[11:59] <cjwatson> why does it matter which partition /boot is on?
[12:00] <dmarkey> ah, xen specific issue, pygrub can only read menu.lst off the 1st partition
[12:01] <cjwatson> you could take the default recipe and edit it to add $primary{ } to the /boot stanza
[12:01] <cjwatson> I think that would do it
[12:01] <cjwatson> looks like the reason it isn't the first partition is that the LVM envelope is always set as primary (which is probably a bug in itself) and thus /boot doesn't need to be as far as partman-auto is concerned
[12:04] <dmarkey> cool, i'll do some research, is https://help.ubuntu.com/9.10/installation-guide/i386/preseed-contents.html my best reference?
[12:04] <cjwatson> yes
[12:05] <neriberto> hi people
[12:06] <cjwatson> dmarkey: I've changed partman-auto-lvm upstream to not enforce that the LVM envelope is primary
[12:07] <neriberto> someone can help me?
[12:07] <cjwatson> neriberto: see the topic - "don't ask to ask, just ask"
[12:08] <neriberto> i've been download a ISO of source...how can I rebuild this?
[12:08] <dmarkey> cjwatson: cool, so the plhsical volume will be sda5?
[12:08] <dmarkey> physical*
[12:08] <cjwatson> neriberto: could you please ask on #ubuntu?  none of our usual installation methods work this way so it doesn't really make sense on this channel
[12:09] <cjwatson> dmarkey: should be.  dunno if this will be in lucid though
[12:09] <dmarkey> cjwatson: sorry for being a pain, but where would i get the default recipe
[12:10] <neriberto> cjwatson but i am talking about ubuntu-server install
[12:10] <neriberto> from source
[12:13] <cjwatson> neriberto: the supported way to install ubuntu-server is from binaries
[12:13] <cjwatson> we aren't Gentoo :)
[12:14] <cjwatson> dmarkey: it's in the partman-auto source package, recipes/atomic
[12:14] <neriberto> tks
[12:21] <dmarkey> so i add $primary{ } and put the whole lot into: d-i partman-auto/expert_recipe?
[12:23] <davmor2> cjwatson: right I'm back
[12:23] <dmarkey> or is there partman-auto/atomic_recipe
[12:24] <cjwatson> dmarkey: it's in the installation guide
[12:25] <cjwatson> davmor2: I think I'm going to have to reproduce this before I'm able to comment
[12:26] <davmor2> cjwatson: Ah okay in that case I'll get on with some desktop testing just give me a ping if you find a cure :)
[12:28] <cjwatson> which gets back to the "my laptop's hard disk is too small" problem.  aargh.
[12:28] <cjwatson> roll on May ...
[12:38] <dmarkey> cjwatson: doesnt seem to be having an affect
[12:38] <cjwatson> ok, I'm not sure then, sorry
[12:39] <dmarkey> cool, thanks
[12:41] <davmor2> cjwatson: can you not just buy a bigger harddrive?
[12:41] <cjwatson> dmarkey: feel free to file a bug / send a mail or something with full logs; best if the installation in question was booted with DEBCONF_DEBUG=developer
[12:41] <cjwatson> davmor2: I suck at hardware maintenance, don't make me do more of it ;-)
[12:42] <cjwatson> I'll get a new laptop in May on our hardware refresh programme, so I'll just make sure it has an enormous disk
[12:43] <ev> NAS + NFS for the win
[12:44] <davmor2> ev: samba share here
[12:46] <cjwatson> ev: yeah, I sort of use that for some things
[12:46] <cjwatson> I may start using it a bit more, but it does mean that I'm restricted when working remotely
[12:46] <ev> I just copy a few images and CDs over for that case
[12:47] <ev> but it means that I don't have to worry about deleting daily-live CDs, or where I'm going to put yet another image.
[12:47] <ev> copy over to my laptop, that is
[12:47] <cjwatson> yeah.  I do have more disk than I can conveniently contemplate using on my fileserver.
[12:47] <ev> heh
[12:48] <cjwatson> as in I haven't even allocated half of it to LVs yet
[12:48] <cjwatson> need to renumber UIDs on my fileserver to make NFS really convenient, though :-(
[12:54] <dmarkey> cjwatson: you could use nfsv4
[13:00] <cjwatson> yeah, I probably could
[13:01] <cjwatson> should look into that in fact, thanks
[13:15]  * ev bangs his head against the proverbial wall; this debconf_ui stuff is proving to be difficult to understand.
[13:15] <ev> cjwatson: is there a simple answer to why debconf_ui needs to run under a debconf frontend?  Also, am I barking up the wrong tree here, given that it doesn't seem to make use of the passthrough frontend.
[13:16] <ev> if you're busy, no worries.
[13:22] <cjwatson> ev: debconf-communicate isn't up to the task of providing a UI - you need a proper debconf frontend for that
[13:22] <cjwatson> and debconf_ui's purpose is to just let debconf do all the UI stuff
[13:22] <ev> ah, duh, right
[13:22] <cjwatson> ev: you may be barking up the wrong tree, I guess - remind me what you're trying to do?
[13:23] <ev> work around the fact that the debconf database is locked when I'm trying to install packages in do_install
[13:23] <ev> (in oem-config)
[13:23] <cjwatson> ah, yeah, you don't want debconf_ui for this
[13:25] <cjwatson> I think you should involve debconf-apt-progress somehow
[13:25] <ev> yeah, I was looking at that as well
[13:25] <cjwatson> there's an example in the man page that you should be able to adapt
[13:25] <cjwatson> the reason oem-config gets away with it is that it uses tasksel to install packages, which in turn uses debconf-apt-progress
[13:26] <ev> ah
[13:26] <cjwatson> but I don't think you should need to use tasksel necessarilty
[13:26] <cjwatson> -t
[13:27] <ev> cool, thanks for the pointers, and sorry for this taking so long for me to wrap my ahead around.
[13:34] <ev> just to clarify, this isn't to get debconf PROGRESS commands, but to be able to install packages to ask questions (postfix, in my test case).  I suspect this will require more than involving debconf-apt-progress as is, correct?
[13:34] <ev> err that call INPUT
[13:47] <cjwatson> no, that should be OK, debconf-apt-progress also shunts other debconf commands through passthrough
[13:47] <cjwatson> that's how packages get to ask questions during pkgsel in d-i
[13:51] <ev> cool, thanks
[14:16] <ev> awesome, I think I'm definitely on the right track now
[14:16] <ev> thanks a million, cjwatson
[14:18] <cjwatson> yw
[14:26] <dmarkey> cjwatson: it does work, pebkac
[14:26] <dmarkey> i was missing "$"
[14:26] <dmarkey> :(
=== robbiew_ is now known as robbiew
[16:31] <CIA-41> partman-iscsi: cjwatson * r46 ubuntu/ (debian/changelog finish.d/iscsi_settings):
[16:31] <CIA-41> partman-iscsi: Remember the default network interface and record it in ISCSI_NETDEVICE
[16:31] <CIA-41> partman-iscsi: in iscsi.initramfs (LP: #473036).
[17:01] <CIA-41> partman-iscsi: cjwatson * r47 ubuntu/debian/changelog: releasing version 12
[17:05] <CIA-41> grub-installer: cjwatson * r833 ubuntu/ (debian/changelog grub-installer):
[17:05] <CIA-41> grub-installer: Add $partition_offset to $bootpart when deciding which partition to make
[17:05] <CIA-41> grub-installer: active based on GRUB-style device names (found while testing fix for LP
[17:05] <CIA-41> grub-installer: #185878).
[18:02] <superm1> ev, it's because it can then be usable in other plugins.  each of those functions are currently used in some fashion in mythbuntu_install.py
[18:02] <superm1> ev, i figured this is the easiest way to get them access to them without code duplication
[23:10] <ev> But where are they or would be used that's not already a subclass of Install and can thus access them already?  Mind you, I'm not criticizing the approach, just trying to understand the rationale.
[23:10] <ev> superm1: ^
=== robbiew is now known as roobiew_