[00:24] <Lyaa> cjwatson: well thanks - keep up the good work! :) off to bed.. ;-)
[01:10] <CIA-35> user-setup: cjwatson * r212 ubuntu/ (debian/changelog user-setup-apply):
[01:10] <CIA-35> user-setup: Fix automatic login on situations where custom.conf didn't exist
[01:10] <CIA-35> user-setup: already on the target.
[01:12] <CIA-35> user-setup: cjwatson * r213 ubuntu/debian/changelog: releasing version 1.28ubuntu3
[08:22] <CIA-35> wubi: evand * r511 hardy/ (data/isolist.ini data/settings.nsh debian/changelog): Bump Ubuntu desktop images to 8.04.4
[08:54] <CIA-35> ubiquity: superm1 * r3683 ubiquity/ (bin/ubiquity debian/changelog):
[08:54] <CIA-35> ubiquity: Drop old hack for copying ^xserver-xorg onto the target system. No
[08:54] <CIA-35> ubiquity: longer necessary as thse variables don't exist in current installs.
[08:57] <ev> nice catch
[11:46] <ev> michaelforrest: have you had a chance to look at the installer page transition stuff from yesterday?
[11:47] <michaelforrest> ev: do you have a minute to talk me through it?
[11:48] <michaelforrest> ev: I'm not sure I understand the rationale behind the changes
[11:48] <ev> michaelforrest: sure
[11:48] <ev> michaelforrest: there were two bugs associated with this, both filed by mpt:
[11:48] <ev> https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/414912
[11:48] <ev> https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/336751
[11:49] <michaelforrest> ev: I see
[11:49] <michaelforrest> ev: I think we can certainly improve this visually!
[11:50] <michaelforrest> ev: the full screen spinner is definitely not the way to go, but I think we can make some minor tweaks to make it a bit less in-your-face
[11:50] <ev> michaelforrest: great
[11:51] <ev> what are your thoughts on the spinner on the advanced partitioning page, just to the right of the partition buttons.  Is that okay?
[11:52] <ev> http://people.canonical.com/~evand/tmp/transitions.html if you lost the link
[11:52] <michaelforrest> ev I think we should make the other transitions match that style
[11:53] <michaelforrest> I disagree with mpt's idea to hide everything instantly. greying out maybe, but all it really needs is a spinner like you have in the partitioning page
[11:53] <ev> right, cjwatson mentioned yesterday the idea of having something of that style on the window for all of the transitions, but we were at a loss of where to put it
[11:53] <ev> ah, indeed
[11:53] <michaelforrest> to be honest, I don't think we need much more than a greying out of the Forward button, especially given that the mouse pointer spins
[11:54] <ev> it already greys out
[11:54] <ev> so are we already set then :) ?
[11:54] <michaelforrest> I think a message would relieve the 'disconcertingness' of it
[11:55] <michaelforrest> (just looking at how it used to work)
[11:55] <cjwatson> thought: could we put a spinner on one of the buttons?
[11:55] <michaelforrest> yeah I thought that too
[11:55] <cjwatson> hmm, don't get a message that way though
[11:56] <michaelforrest> in case the user is using the keyboard
[11:56] <cjwatson> we disable the buttons anyway
[11:56] <michaelforrest> and didn't click the button but pressed enter
[11:56] <cjwatson> I'm thinking of the case where we're entering the timezone page, when we access the network to sync up the clock; in that case a message is nice since it might take a while
[11:56] <cjwatson> for ordinary page transitions a spinner on Forward or Back as appropriate might doo the job
[11:57] <cjwatson> do
[11:57] <cjwatson> maybe I'm inventing too many alternatives here
[11:57] <michaelforrest> it's common behaviour on the web for the button to grey out
[11:57] <michaelforrest> but you'd see the ilttle globe spinning or whatever
[11:57] <cjwatson> yeah, we do that already
[11:57] <michaelforrest> but we see the mouse pointer spinning here
[11:57] <cjwatson> (grey out)
[11:57] <michaelforrest> I think the bug is invalid, to be honest!
[11:57] <ev> hooray
[11:57] <michaelforrest> the important one is not to ever spawn a new window
[11:58] <cjwatson> right, that's bug 336751
[11:58] <ev> so do we get rid of the progress dialogs then?
[11:58] <michaelforrest> we need a consistent location to put this progress stuff, I think
[11:58] <michaelforrest> I'll get otto to help me with a layout
[11:58] <cjwatson> the question is how to convey the information in the progress dialogs (or cut-down versions of that information, as appropriate) without dialogs
[11:58] <ev> right
[11:58] <michaelforrest> we need to bring the dialogues into the body of the page instead of spawning a new window
[11:59] <ev> michaelforrest: please keep me in the loop on that layout as this is a work item for me for 9.10
[11:59] <cjwatson> for bug 414912, my feeling is that we should leave it open until we're in a position to be able to switch to the new page layout immediately
[11:59] <michaelforrest> I still haven't had a chance to show Mark the work I've done on the installer, but I am in a meeting with him today.
[11:59] <cjwatson> that's what that bug really is, not dodgy workarounds with progress information :)
[12:01] <ev> cjwatson: can you expand on that a bit?  I'm not sure I follow.
[12:02] <cjwatson> on Forward, we finish off the backend work for the current page, start up the backend for the new page, then flip the UI
[12:02] <cjwatson> hmm, there's some justification for this though
[12:03] <cjwatson> the reason is that the backend gets to determine whether a page is going to be displayed at all (e.g. automation)
[12:03] <cjwatson> so maybe this isn't a viable change
[12:04] <ev> ah, indeed
[12:04] <cjwatson> so I guess ignore my mutterings. :)
[12:15] <CIA-35> ubiquity: cjwatson * r3684 ubiquity/.bzrignore: ignore po/*.gmo
[12:17] <CIA-35> ubiquity: cjwatson * r3685 ubiquity/bin/ubiquity: revert incorrect VERSION change from r3683
[13:16] <dpm> hi ev1, I'm trying to sort out the xkeyboard-config template in the translations import queue in LP. Has the path of the generated template been changed from po/xkeyboard-config.pot to debian/xkeyboard-config.pot?
[13:22] <dpm> cjwatson, superm1, we've also got quite a lot of templates of type d-i/source/clock-setup/debian/po/templates.pot, d-i/source/preseed/debian/po/templates.pot, etc. for ubiquity in the imports queue. Are this merged into the main ubiquity template and thus can I safely block them from being imported?
[13:23] <cjwatson> block 'em
[13:23] <cjwatson> they're merged into debian-installer
[13:43] <dpm> cjwatson, ok, blocked, thanks
[13:46] <cjwatson> ev1: do you know what's going on with bug 488599?  I've seen that in my own tests
[13:46]  * ev1 looks
[13:46] <cjwatson> I assume that win_size_req can't work properly until the window is realised or something, but I can't work out the correct fix
[13:50] <ev1> I haven't noticed it yet.  Hrm, are you able to reproduce this?
[13:52] <cjwatson> I could yesterday
[13:52]  * cjwatson fires up another VM, yay for lots of RAM
[13:53] <cjwatson> BTW, we should do a ubiquity upload at some point today - Scott's autotests are running into the bug Mario fixed in user-setup last night
[13:53] <ev1> my initial thought is perhaps that callback fires more than once, and we can work around the problem by checking for a gdk window?
[13:54] <ev1> indeed, will do
[13:56] <cjwatson> damn.  now I'm not seeing it.  sorry
[13:56] <ev1> it's okay
[13:56] <ev1> I'll keep digging and see if I can find a definitive answer as to why that's happening
[13:56] <cjwatson> I was seeing it literally every run yesterday
[14:18] <CIA-41> ubiquity: cjwatson * r3686 ubiquity/ (debian/changelog ubiquity/filteredcommand.py):
[14:18] <CIA-41> ubiquity: Initialise FilteredCommand.ui_loop_level earlier, just in case
[14:18] <CIA-41> ubiquity: (LP: #484452).
[14:21] <CIA-41> console-setup: evand * r121 console-setup.ubuntu/ (7 files in 3 dirs):
[14:21] <CIA-41> console-setup: * Merge support for translated keyboard names from Debian.
[14:21] <CIA-41> console-setup: * Update ckb/rules/base.xml to point at the new location.
[14:24]  * ev shakes his fist at Keybuk for not pushing his console-setup changes to trunk
[14:29] <ev> erm, actually
[14:31] <ev> cjwatson: are we using lp:ubuntu/console-setup instead of lp:~ubuntu-core-dev/console-setup/ubuntu now?
[14:32] <cjwatson> not as far as I'm concerned
[14:32] <ev> okay, good
[14:32] <cjwatson> I have an outstanding request open with james_w to make them identical, but in the meantime Keybuk is probably just being overly opinionated :)
[14:34] <saispo> hi all
[14:34] <ev> lol, always a safe assumption
[14:34] <saispo> cjwatson: i try to bypass unauthenticated gpg package in preseed but if i have a personnal lsb-release and libldap, i got a red screen, he don't want to install them, it's normal ?
[14:35] <cjwatson> I don't know
[14:35] <saispo> ok
[14:38] <cjwatson> if you want me to debug, I need full logs with DEBCONF_DEBUG=developer
[14:45] <ev> cjwatson: before I go ahead and fix this with bzr diff -r70..72 | patch -p0 -d ../console-setup.ubuntu, do you know of any way to reconcile this as a proper bzr merge?
[14:46] <ev> I tried merge -r70..72, but that failed miserably
[14:48] <michaelforrest> ev: what can I do to see the installer from my normal desktop? I installed the ubiquity package which seemed promising..
[14:48] <ev> michaelforrest: yeah, I would avoid doing that
[14:48] <michaelforrest> ev: avoid looking at the installer?
[14:48] <ev> sorry, avoid running it on your system
[14:48] <michaelforrest> ev: or avoid installing the ubiquity package?
[14:49] <michaelforrest> ev: I want to see it with the new theme-in-progress
[14:49] <michaelforrest> ev: can't I just run it as though I was on a live cd?
[14:49] <ev> michaelforrest: are you able to run it under a virtual machine?
[14:50] <michaelforrest> ev: can't I just run it normally? what's the problem?
[14:51] <michaelforrest> ev: I don't want to be maintaining yet another vm instance, especially since my ubuntu laptop doesn't have a cpu that supports virtualisation
[14:51] <ev> michaelforrest: you can technically run it normally up to the point where it would start copying files
[14:51] <michaelforrest> ev: yeah that's all I want to do
[14:51] <ev> as that depends on files only present on the CD
[14:51] <michaelforrest> I just want to quickly get a feel for how it looks
[14:51] <ev> some things will still not work just right (such as getting the release name, as that relies on /.disk/info from the CD)
[14:52] <michaelforrest> so given that I am prepared for glitches, can I do it?
[14:52] <ev> sure
[14:52] <ev> just be careful to not resize a partition and then hit next and confirm the dialog, or get to the summary page and press install.
[14:52] <michaelforrest> yeah I'm not gonna do that, don't worry ;)
[14:52] <CIA-41> ubiquity: cjwatson * r3687 ubiquity/ (3 files in 2 dirs): merge lp:~dylanmccall/ubiquity/lp-476269
[14:52] <michaelforrest> so what do I need to do?
[14:52] <ev> sure, just covering my bases
[14:53] <ev> installing ubiquity-frontend-gtk should be enough
[14:53] <michaelforrest> don't worry - I'm a responsible adult ;)
[14:53] <cjwatson> ev: I don't think you can do it as a proper merge
[14:53] <ev> cjwatson: patch it is.  Just wanted to be sure you weren't aware of any black magic.
[14:53] <cjwatson> ev: only thing I'd suggest is to commit the patches one by one so you can use --author
[14:53] <michaelforrest> ev:  perfect, thatnks
[14:53] <ev> ah, will do
[14:53] <michaelforrest> *thanks
[14:54] <cjwatson> michaelforrest: the installer *will* change the configuration of your system even before you get to Install
[14:54] <cjwatson> in particular the keyboard layout stuff
[14:54] <ev> might want to have a console open with setxkbmap us or something similar
[14:54] <ev> queued up, that is
[14:55] <michaelforrest> cjwatson: that's fine. I just want a peak so as long as it's not doing something serious in the background it's fine
[14:55] <michaelforrest> I've got what I need now anyway.
[14:55] <michaelforrest> ev: do you think it would be productive for me to look at glade files?
[14:55] <michaelforrest> ev: (assuming there are glade files for the interface screens)
[14:55] <CIA-41> ubiquity: cjwatson * r3688 ubiquity/ubiquity/frontend/ (base.py gtk_ui.py): style
[14:55] <ev> michaelforrest: can you be more specific?
[14:56] <ev> there are, though some are filled out by the installer at runtime
[14:56] <ev> the partition pages in particular
[14:56] <ev> if you have a bzr branch, they're in gui/gtk; otherwise, look in /usr/share/ubiquity/gtk
[14:56] <michaelforrest> ev: that's okay -I'm more interested in giving some of of the simpler pages a little love
[14:56] <ev> awesome
[14:57] <michaelforrest> ev: are they somewhere logical that I could view them in glade?
[14:57] <ev> michaelforrest: /usr/share/ubiquity/gtk
[14:57] <michaelforrest> ev: I will understand that there are localisation issues and so on - if you point me to the right repository I shouldn't need to bother you too much :)
[14:58] <michaelforrest> ah, perfect
[14:58] <CIA-41> ubiquity: cjwatson * r3689 ubiquity/ubiquity/frontend/kde_ui.py: sync KDE frontend with Dylan's slideshow changes
[14:59] <ev> ubiquity.ui contains the main window that each step gets added to
[14:59] <michaelforrest> ev: already there
[14:59] <michaelforrest> doesn't look like there's much I could do here :(
[14:59] <ev> each stepPageName.ui file contains the ui specific for that page
[14:59] <ev> oh?
[15:00] <michaelforrest> ev: well - not something that wouldn't be easier to achieve with mockups
[15:01] <ev> gotcha
[15:09] <robbiew> ev: do you know why Keybuk's daily installer and boot charts have stopped?
[15:09] <ev> robbiew: there was a bug in user-setup that superm1 has since fixed
[15:09] <ev> we're going to upload a new ubiquity today to fix it
[15:10] <robbiew> ev: okay.  I actually don't mind that it broke, was more worried Keybuk's scripts were broken :P
[15:10] <ev> nope :)
[15:10] <robbiew> seems that the tool is doing its job then :D
[15:10] <robbiew> thanks
[15:12] <cjwatson> he was also having trouble syncing his output to the new people.canonical.com
[15:13] <cjwatson> and couldn't easily deal with it while on a radically different timezone from most of IS
[15:13] <ev> indeed, I think we'll be in a much better place with respect to automation of ubiquity than we've been in previous releases
[15:14] <saispo> cjwatson: i can send you the full debug if you want
[15:14] <cjwatson> saispo: sure
[15:14] <saispo> ok, i grab it and where i can send it to you ?
[15:15] <cjwatson> ubuntu-installer@lists.ubuntu.com
[15:15] <cjwatson> can't promise to debug everyone's personal customisation problems though.
[15:15] <saispo> i understand, no problem
[15:17] <CIA-41> ubiquity: cjwatson * r3690 ubiquity/ (debian/changelog ubiquity/components/ubi-timezone.py): merge lp:~mterry/ubiquity/refresh-timezones
[15:18] <CIA-41> console-setup: evand * r122 ubuntu/debian/ (changelog console-setup.initramfs-hook rules):
[15:18] <CIA-41> console-setup: * debian/console-setup.initramfs-hook: There's no harm having the hook
[15:18] <CIA-41> console-setup:  run in the non-framebuffer case, it just copies things into the
[15:18] <CIA-41> console-setup:  initramfs which may be useful.
[15:18] <CIA-41> console-setup: * debian/rules: That means we can copy the hook into scripts/panic as
[15:18] <CIA-41> console-setup:  well (stripping the OPTION from it), so when we need a shell, we'll
[15:18] <CIA-41> console-setup:  load the keymap.
[15:22] <CIA-41> console-setup: evand * r123 console-setup/debian/changelog: releasing version 1.34ubuntu6
[15:24] <ev> unless there are any objections, I'm going to release a new ubiquity in a few minutes
[15:24] <saispo> cjwatson: sending, thanks
[15:29] <saispo> cjwatson: my messages is in hold because the size is over than required
[15:30] <saispo> it's a problem or you can moderate it ?
[15:34] <ev> mterry: anything else you want to land?
[15:34] <ev> ah sorry
[15:34] <ev> didn't realize that was a merge at first
[15:34] <mterry> ev, yeah, that patch has been sitting around since karmic released.  I don't have anything recent
[15:34] <ev> okay cool
[15:35] <CIA-41> ubiquity: evand * r3691 ubiquity/ (d-i/manifest debian/changelog):
[15:35] <CIA-41> ubiquity: Automatic update of included source packages: localechooser
[15:35] <CIA-41> ubiquity: 2.12ubuntu3, user-setup 1.28ubuntu3.
[15:48] <CIA-41> ubiquity: evand * r3692 ubiquity/debian/changelog: releasing version 2.1.12
[16:21] <CIA-41> console-setup: evand * r124 console-setup/ (Keyboard/KeyboardNames.pl debian/changelog): releasing version 1.34ubuntu7
[17:15] <CIA-41> partman-uboot: cjwatson * r8 ubuntu/debian/ (partman-uboot.templates po/templates.pot): fix up .pot file a bit
[17:17] <CIA-41> partman-uboot: cjwatson * r9 ubuntu/ (4 files in 3 dirs):
[17:17] <CIA-41> partman-uboot: Use partman-basicfilesystems/mountpoint_manual rather than
[17:17] <CIA-41> partman-uboot: partman-uboot/mountpoint_manual; there's no need for a different
[17:17] <CIA-41> partman-uboot: template here, and it saves having to teach ubiquity about the extra one
[17:17] <CIA-41> partman-uboot: (LP: #462798).
[17:21] <CIA-41> partman-uboot: cjwatson * r8 2.1/ (commit.d/format_uboot debian/changelog):
[17:21] <CIA-41> partman-uboot: mkfs.ext2 with -I 128 and not -b 4096 as this is what Marvell recommends
[17:21] <CIA-41> partman-uboot: to work around a bug in older Uboots.
[17:22] <CIA-41> partman-uboot: cjwatson * r10 ubuntu/ (commit.d/format_uboot debian/changelog): merge partman-uboot 2.1
[17:23] <CIA-41> partman-uboot: cjwatson * r11 ubuntu/debian/changelog: releasing version 3
[17:45] <CIA-41> ubiquity: cjwatson * r3693 ubiquity/ (bin/ubiquity bin/ubiquity-dm debian/changelog):
[17:45] <CIA-41> ubiquity: Don't crash if something races with ubiquity or ubiquity-dm to create
[17:45] <CIA-41> ubiquity: /var/log/installer (LP: #458806).
[17:47] <superm1> what else would be making /var/log/installer?
[17:58] <cjwatson> two simultaneous runs of ubiquity
[17:58] <cjwatson> before it acquires the lock
[17:59] <cjwatson> note that ubiquity-dm creates /var/log/installer, and that's outside ubiquity's main lock
[17:59] <cjwatson> anyway, didn't seem that interesting to figure out exactly why, I just wanted to get another off the list
[18:02] <superm1> oh i guess a real world scenario is if someone goes crazy clicking the icon a bunch because it's not opening instantly
[18:05] <cjwatson> backtrack needs to deal with their own freaking bugs
[18:31] <cjwatson> ev: have you seen bug 368060?  scary ...
[18:39] <cjwatson> ev: bug 337306 may relate to the oem-config troubles you were having
[18:41] <cjwatson> ev: or maybe just look at how the server frontend does it
[19:04] <CIA-41> grub-installer: cjwatson * r831 ubuntu/ (debian/changelog grub-installer):
[19:04] <CIA-41> grub-installer: Don't check for LVM when we've already worked out that we're installing
[19:04] <CIA-41> grub-installer: on SATA RAID.
[19:05] <CIA-41> grub-installer: cjwatson * r832 ubuntu/debian/changelog: releasing version 1.49ubuntu2
[20:57] <ev> cjwatson: thanks for the pointers
[20:57] <ev> and yeah, yikes
[21:30] <ev> cjwatson: shall I ask Ken to mock up something else?
[21:32] <ev> not sure how else to represent it given that the time zone ends at that border.  We could just remove Kashmir, but I imagine that would make people just as angry.
[22:30] <cjwatson> ev: I'm not sure - I haven't looked at it in detail
[22:30] <cjwatson> ev: IIRC other implementations fuzz the line around there somehow
[22:30] <ev> good call, I'll see what others do here
[22:46] <superm1> cjwatson, how would you feel about something like this: http://pastebin.com/f76a9d3e1  ?  I think that would allow multiple files to be preseeded (as additional arguments)
[22:48] <cjwatson> superm1: looks good to me except that it flips the override order of variables specified on the command line vs. those in files
[22:48] <cjwatson> superm1: I think I'd recommend keeping the list of locations and processing them all at the end, to avoid inadvertently breaking some weird case or other
[22:49] <superm1> cjwatson, okay, i'll flip that around.  i think either way, the order will suddenly matter at least for stacked preseed files
[22:49] <superm1> not much of a way to avoid that
[22:50] <cjwatson> I don't think that's true, this script isn't recursive
[22:50] <cjwatson> just processing them all at the end would keep the same ordering semantics but permit specifying any or all of preseed/file= file= url=
[22:52] <superm1> well i mean if multiple preseed files are specifying the same key, then it's entirely possible that the order they were specified on the command line will determine which one's setting of that key would take effect since they would still be individually loaded in via debconf-set-selections
[22:58] <cjwatson> certainly
[22:58] <cjwatson> but that's OK, I think
[22:58] <superm1> Ok.
[22:58] <superm1> in trying to get dmraid sorted out, i think this is gonna be necessary for our implementation of it
[22:58] <cjwatson> I don't mind new handling being a bit odd, I just don't want to perturb existing handling
[22:58] <superm1> Ok
[23:16] <ev> has anyone actually been able to get the kubuntu lucid images to work in kvm?
[23:21] <ev> ah, my bad
[23:21] <ev> -vga std, in case anyone else runs into it
[23:30] <dmarkey_> is it possible to disable ext4 in the installer
[23:30] <dmarkey_> using preseed, etc
[23:31] <smagoun> dmarkey_: 'd-i partman/default_filesystem string ext3' should set the filesystem to ext3
[23:31] <dmarkey_> thats excellent, thanks
[23:32] <CIA-41> casper: superm1 * r734 casper/ (debian/changelog scripts/casper-bottom/24preseed):
[23:32] <CIA-41> casper: Support multiple preseed file/urlarguments on the kernel commandline
[23:32] <CIA-41> casper: rather than just selecting the last one and going with that.
[23:32] <dmarkey_> smagoun: how about force grub1?
[23:32] <smagoun> dmarkey_: d-i grub-installer/grub2_instead_of_grub_legacy boolean false
[23:33] <dmarkey_> are these documented anywhere
[23:33] <cjwatson> but please tell us why you don't want grub2 (in a bug report) so that we can fix whatever it is.
[23:33] <smagoun> dmarkey_: you mean besides the source? :) I am not sure
[23:33] <cjwatson> the first is documented in the installation guide
[23:33] <CIA-41> casper: superm1 * r735 casper/debian/ (changelog control): debian/control: Set Vcs-Bzr.
[23:33] <cjwatson> the second isn't documented at the moment AFAICS
[23:34] <dmarkey_> cjwatson: this is for a xen domu, pygrub doesnt support grub2 yet
[23:34] <dmarkey_> not an ubuntu bug as such
[23:34] <cjwatson> superm1: please use lp:ubuntu/casper not lp:casper, as discussed on #ubuntu-devel 2010-01-05
[23:35] <cjwatson> dmarkey_: ok
[23:35] <superm1> cjwatson, lol.  here i thought this one was right.  okay i'll push  there
[23:35] <cjwatson> 16:51 <cjwatson> superm1,pitti,ev: please note for future commits that casper is in lp:ubuntu/casper now rather than lp:caspper
[23:36] <dmarkey_> cjwatson: i think i was talking to you about a year ago about getting the ubuntu installer to work proberly under xen paravirt
[23:39] <CIA-41> ubiquity: evand * r3694 ubiquity/ (6 files in 4 dirs): Support the new translated keyboard names in console-setup.
[23:39] <cjwatson> dmarkey_: might have been - I'm afraid it hasn't been much of a priority for me to improve
[23:39] <dmarkey_> but its so close
[23:40] <dmarkey_> all it needs is the xen modules included
[23:40] <cjwatson> "all"
[23:40] <cjwatson> that needs a consistently maintained Xen kernel ...
[23:40] <CIA-41> casper: superm1 * r745 casper/ (debian/changelog scripts/casper-bottom/24preseed):
[23:40] <CIA-41> casper: Support multiple preseed file/urlarguments on the kernel commandline
[23:40] <CIA-41> casper: rather than just selecting the last one and going with that.
[23:40] <dmarkey_> nope
[23:40] <dmarkey_> it doesnt need any seperate kernel
[23:41] <CIA-41> ubiquity: evand * r3695 ubiquity/debian/changelog: LP bug reference for previous commit.
[23:41] <CIA-41> casper: superm1 * r746 casper/debian/ (changelog control): debian/control: Set Vcs-Bzr.
[23:42] <cjwatson> dmarkey_: do you mean xen-blkfront, xen-netfront, and netxen-nic?
[23:42] <dmarkey_> yup
[23:42] <dmarkey_> not sure about the 3rd, but the 1st 2 anyway
[23:42] <cjwatson> neither xen-blkfront nor xen-netfront appears to be available in the lucid generic kernel
[23:43] <dmarkey_> 64bit?
[23:43] <cjwatson> i386
[23:43] <dmarkey_> well they are in the vanilla kernel since .22
[23:44] <dmarkey_> i think i seen this before, try 64bit, i bet they are there
[23:45] <cjwatson> sure, but I'd rather keep d-i consistent.  why aren't they in the i386 generic build?
[23:45] <cjwatson> the config for those appears to be common
[23:45] <dmarkey_> im not sure
[23:47] <cjwatson> config XEN
[23:47] <cjwatson>         depends on X86_64 || (X86_32 && X86_PAE && !X86_VISWS)
[23:47] <cjwatson>         depends on X86_CMPXCHG && X86_TSC
[23:47] <cjwatson> maybe that's it
[23:47] <dmarkey_> oh, PAE only?
[23:48] <cjwatson> well, if it's 64-bit only, so be it; it would require a change to our kernel packaging to add those modules to the appropriate udebs
[23:48] <dmarkey_> what are udebs
[23:48] <cjwatson> (d-i's i386 build comes from -generic not -generic-pae, it doesn't get to use PAE bits; and in any case those modules don't seem to be in our -generic-pae build either)
[23:48] <cjwatson> google please!
[23:49] <cjwatson> anyway, file a bug against the 'linux' package in Ubuntu asking for those to be added
[23:49] <cjwatson> refer them to me for the details if you like
[23:49] <dmarkey_> oh, i'll do it tomorrow, bed time for me now
[23:49] <cjwatson> from the arrangement in Debian, xen-blkfront goes in scsi-modules, xen-netfront in nic-modules, and netxen_nic in nic-extra-modules
[23:49] <dmarkey_> thanks!
[23:49] <dmarkey_> i see
[23:50] <dmarkey_> would i include all this in the bug?
[23:50] <cjwatson> netxen_nic is already in there
[23:50] <cjwatson> yes
[23:50] <dmarkey_> NetXen Multi port (1/10) Gigabit Network Driver
[23:50] <dmarkey_> thats unrelated
[23:50] <cjwatson> ok, skip that then
[23:51] <dmarkey_> cool, talk tomorrow, thanks!