[01:39] <zul> heylo
[03:47] <mjg59> Ooh ooh ooh
[03:47] <mjg59> Laptop docking support patches
[04:19] <dilinger> whee!
[04:23] <dilinger> (22:19:27) Ian Gulliver: hung on detecting and activating hardware
[04:23] <dilinger> (22:22:36) Ian Gulliver: 4 times now
[04:23] <dilinger> (22:22:45) Ian Gulliver: looks like 2.6.15 fixes that nasty it-actually-boots-sometimes bug
[04:23] <dilinger> heh.  there's some race in there
[02:55] <zul> heylo
[04:50] <doko> BenC: ping
[04:51] <BenC> doko: pong
[04:57] <doko> BenC: is there a way to influence the order how scsi disks are enumerated? I have one on a 3ware controller, which is the first in BIOS setup, but comes as third in the system (the two sata disks are first and second)
[04:58] <BenC> doko: it's all in how the kernel reports PCI devices to udev, which it in turn loads the controller drivers in that order
[04:58] <BenC> so it's all based on PCI ordering
[04:59] <BenC> lspci will show you what you can expect
[05:00] <BenC> if the sata controller comes before the 3ware one, then there's not much can so other than blacklist the sata controller from initramfs and have it load from the base system
[05:00] <doko> not nice ... the 3ware has the highest ID
[05:01] <doko> can this blacklisting be done persistant (for upgrades)?
[05:01] <Mithrandir> doko: you can't even be sure the ordering is consistent.  Why do you want to see the controllers in a particular order?
[05:02] <doko> remove the sata disks at some point and still have a bootable system
[05:02] <Mithrandir> use by-label or by-uuid?
[05:03] <lamont__> YES!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  _I_ _AM_ _INVINCIBLE_!!!!!!!!!!!!!!
[05:03] <doko> could somebody please kick out this robot ;-P
[05:03] <BenC> sweet
[05:04] <doko> Mithrandir: in grub?
[05:04] <BenC> lamont: so can ia64 and hppa go to initramfs now?
[05:04] <lamont__> just booted ia64 with initramfs
[05:04] <Mithrandir> doko: grub is on the first drive the BIOS sees, you can't really change that.
[05:04] <lamont__> BenC: now, for extra credit... tell me what magic is missing on both ia64 and hppa to have the network card autodetect and configure like it does on the first-class architectures...
[05:05] <doko> yes, but it has root=/dev/sda5 , so this should be changed to something else?
[05:08] <lamont__> BenC: and I'm just being blind today... can't see where that stupid question is coming from... (Install a boot block using the existing...)"
[05:08] <lamont__> that is, I can't see why the kernel postinst doesn't ask the same question with grub
[05:08] <lamont__> oh, wait.  that's sick.
[05:08] <lamont__> there's no /etc/grub.conf
[05:09] <lamont__> --> no question
[05:10] <lamont__> and no grub run.
[05:10] <lamont__> hrm.
[05:10] <lamont__> BenC: I think that kernel-package needs to be updated to use debconf.... and that really hurts to say that.
[05:11] <BenC> lamont: PCI devices need a MODULE_DEVICE_TABLE()
[05:11] <BenC> that will help udev to know which driver to load when it sees that PCI device id
[05:13] <lamont__> 0000:00:0c.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
[05:13] <lamont__> that doesn't have a DEVICE_TABLE???
[05:13] <lamont__> 0000:a0:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)
[05:13] <lamont__> I can believe that one's new enough not to.
[05:16] <lamont__> BenC: so, ia64 needs to depend elilo (>=3.6-1) and hppa/ia64 both need klibc-utils (>=1.1.16-1ubuntu1)
[05:17] <lamont__> and then the initrd-tools Depend can go away
[05:18] <lamont__> BenC: fresh boot shows eth0 present with a MAC addr, etc... but not configured.
[05:18] <lamont__> ifup eth0 and everything is happy
[05:18] <lamont__> so I think it's above the kernel...
[05:18] <lamont__> udevd[784] : get_netlink_msg: unable to receive kernel netlink message: No buffer space available
[05:18] <lamont__> I wonder if that's related... :-)
[05:19] <lamont__>  * Detecting and activating hardware...
[05:19] <lamont__> udevd[1726] : get_netlink_msg: unable to receive kernel netlink message: No buffer space available
[05:19] <lamont__>    ...done.
[05:19] <doko> Mithrandir grub lists root=/dev/sda5 as parameter, so this should be changed to something else?
[05:19] <lamont__> hrm... probably
[05:19] <Mithrandir> doko: if you use root=/dev/disk/by-uuid/$uuid-of-fs
[05:19] <lamont__> and shortly after that:
[05:19] <lamont__>  * Loading modules...
[05:19] <lamont__> Linux Tulip driver version 1.1.13 (May 11, 2002)
[05:19] <lamont__> tulip0: no phy info, aborting mtable build
[05:19] <lamont__> tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.
[05:19] <lamont__> eth0: Digital DS21143 Tulip rev 65 at 80001000, 00:10:83:7A:1F:35, IRQ 66.
[05:19] <lamont__>    ...done.
[05:22] <BenC> lamont: that's a auto etho0 to /etc/network/interfaces
[05:22] <lamont__> BenC: right.  But I don't need that on i386
[05:23] <lamont__> because of this:
[05:23] <lamont__> mapping hotplug
[05:23] <lamont__>         script grep
[05:23] <lamont__>         map eth0
[05:23] <lamont__> hence the "what magic is missing here" question
[05:24] <lamont__> or maybe it's not... :-(
[05:24] <lamont__> I just know that my i386, ppc, and amd64 boxen all autoconfig eth0, even without the 'auto eth0' in /etc/network/interfaces
[05:25] <Mithrandir> lamont__: autoconfiguration of networks is kinda broken in dapper now.
[05:26] <lamont__> Mithrandir: it didn't work in breezy either.
[05:26] <lamont__> Mithrandir: how soon will the known borkage be fixed?
[05:26] <Mithrandir> lamont__: ask scott
[05:27] <lamont__> BenC: can I leave fixing the kernel package depends to you?
[05:29] <lamont__> BenC: fwiw, klibc_1.1.16-1ubuntu1 is current everywhere but sparc, which is probably just an upload-not-done-yet thing
[05:30] <BenC> yeah, fabbione is away for awhile
[05:30] <BenC> I can do the kernel deps
[05:30] <lamont__> thanks
[05:31] <BenC> klibc is a initramfs-tools dep I think
[05:31] <BenC> it's not for linux-image-* or kernel-package
[05:53] <infinity> lamont__: I can bump the depends on klibc* in initramfs-tools for you.
[05:58] <lamont__> infinity: ah, yeah, that'd be the place, huh?
[05:59] <lamont__> infinity: or I can do it if you don't have an upload planned soon
.. I have the source sitting right here.
[06:00] <infinity> (>= 1.1.16-1) should be fine, yes?
[06:00] <infinity> (so it can go back to Debian like that too)
[06:02] <infinity> Uploaded.
[07:07] <makx> infinity: the evms hooks landed directly in evms with latest debian upload :)
[07:08] <makx> i see that i need to sync to your repo for some nice arch support and copy_exec fixes.
[07:09] <makx> i'm still wondering why ubuntu's modprobe has "-Qs"?
[07:09] <makx> and i don't see that in our m-i-t..
[07:13] <infinity> makx: I saw that.  Congrats.  I'll be merging that stuff in after my VAC.
[07:13] <infinity> makx: With any luck, we're down to pretty much no diff, except for bugfixes and doc changes passing back and forth.
[07:13] <infinity> (and some usplash junk)
[11:59] <infinity> BenC: Can you please sync ipw2100 to 1.1.4 if you have a chance?
[12:00] <infinity> BenC: (regarding: https://launchpad.net/products/network-manager/+bug/28544 )
[12:01] <BenC> sure
[12:01] <infinity> Danke.
[12:01] <mjg59> BenC: Did you see my pointer to the Marvell wireless driver?
[12:02] <BenC> I did, but it's lost in scrollback...can you email it to me where I know it will stay in my view?
[12:02] <mjg59> Ok
[12:02] <BenC> thanks
[12:02] <mjg59> BenC: Address?
[12:03] <BenC> bcollins@ubuntu.com
[12:03] <mjg59> Done
[12:03] <mjg59> Needs firmware, we probably want to ask for distribution rights