[03:27] <jbailey> Nice.  What does it do?
[03:28] <zul> adds module_version to some network drivers
[03:32] <zul> mmm....spiffy...System of a Down - Mezmerize - BYOB _Bring Your Own Bombs_.mp3
[05:13] <fabbione> morning
[05:30] <dilinger> good evening
[05:31] <lamont> morning fabbione 
[05:47] <fabbione> hey dilinger 
[05:47] <fabbione> make_kpkg is shitting on me
[05:47] <fabbione> dpkg-gencontrol: error: package linux-xen0-2.6.10-5-386-xen0 not in control info
[05:47] <fabbione> why on earth does it change linux-image into linux-xen0
[05:56] <lamont> hrm... so who should 8189 really be assigned to, rather than kernel-team, I wonder
[06:07] <dilinger> uh
[06:07] <dilinger> i have no idea, that's really odd
[06:08] <dilinger> 'linux' is set via --stub, the image bit should be from kernel-package.. 
[06:08] <dilinger> you built it w/ kernel_image?
[06:09] <fabbione> dilinger: i used the same way we build the kenrels in ubuntu
[06:10] <dilinger> i have no idea, i've never seen kernel-package do that
[06:10] <dilinger> i need to get to bed, job interview tomorrow at 8:30 :(
[06:11] <fabbione> dilinger: good night and good luck
[06:11] <fabbione> lamont: 8189 is mostlikely our
[06:11] <dilinger> thanks
[06:11] <fabbione> usb-massstorage is teh sux
[06:23] <lamont> fabbione: yeah, but we assign them to debzilla or to an individual
[06:23] <lamont> rather than polluting kernel-team
[06:24] <lamont> kernel-bugs already gets them (qa contact is cc'ed...)
[06:24] <lamont> 99% sure.. :0)
[06:24] <fabbione> right
[06:25] <fabbione> night lamont
[08:35] <unifi> hey is anyone around?
[08:35] <unifi> I am trying to figure out where my kernel is
[08:36] <fabbione>  /boot
[08:37] <unifi> ok thanks... then what is in /lib/modules?
[08:38] <fabbione> the modules that the kernel or the user can load on demand
[02:59] <zul> hey
[03:01] <zul> bleah since when did ati do ide
[03:01] <fabbione> hi zul
[03:02] <zul> hey fabbione how is it going?
[03:07] <fabbione> not too bad
[03:07] <fabbione> i committed some stuff in experimental you want to look at :)
[03:07] <zul> like what?
[03:08] <fabbione> xen?
[03:08] <zul> ah...where again?
[03:08] <fabbione> see /topic
[03:09] <zul> ah sweet!
[03:09] <zul> i didnt see that just woke up ;)
[03:10] <fabbione> it has been there for a few days now :)
[03:11] <zul> heh it shows you how observant i am
[03:14] <zul> whats the difference between xen0 and xenu
[03:19] <fabbione> i still need to improve the descriptions and fix the header packages
[03:19] <fabbione> but basically xen0 is the kernel the boots the machine
[03:19] <fabbione> xenu is the one that boots the virtual machines
[03:20] <zul> ah ok
[03:26] <fabbione> i am still not sure if we are handling xen properly...
[03:26] <fabbione> right now i consider it a special cased flavour of i386
[03:27] <fabbione> but i think we will need to treat it as a separate arch
[03:27] <fabbione> otherwise fixing the headers will be a royal mess
[03:28] <zul> gotcha
[03:55] <fabbione> zul: your updates to external drivers are bogus :)
[03:55] <fabbione> that file matches what is in the kernel
[03:55] <fabbione> not what is upstream
[04:00] <zul> ah ok
[04:00] <zul> well they should be in experimental then ;)
[04:03] <fabbione> as soon as you update a driver, you update that file too
[04:03] <fabbione> so you know what is in and what's not
[04:03] <zul> ah got it
[04:25] <fabbione> build time for i386 is almost doubled
[04:30] <zul> hah hah
[05:17] <lamont> but we don't have a buildd for Architecture: xen
[05:17] <lamont> so it probably has to build on i386
[05:19] <fabbione> it can only build on i386 :)
[05:19] <fabbione> atm
[05:20] <fabbione> lamont: i have been puzzled about adding xen as arch/i386/*-xen* flavours
[05:20] <fabbione> or add arch/xen-i386/$flavours
[05:20] <fabbione> both cases have pro/cons at build time
[05:20] <fabbione> right now i am just curious to get these test images out
[05:21] <fabbione> we can always change the internal build at anytime
[05:24] <lamont> right - either way involves abusing things a little bit
[05:24] <lamont> actually, arch/i386/*-xen* (*.xen?) is probably the way to go, otherwise i386 needs to know how to build for 2 architectures, which is ugiler than having extra configs
[05:25] <fabbione> well i was hoping in a xen-amd64 soon to be hounest
[05:25] <fabbione> it alredy supportes x86_64 to certain degrees
[05:25] <fabbione> lamont: there are still hacks around tbh
[05:26] <lamont> right.  But either xen builds on 1 platform, or we have xen flavors of various platforms
[05:26] <fabbione> like we need to build a special linux-headers package for Arch: "xen-i386"
[05:26] <lamont> ah
[05:26] <fabbione> eitherway it needs to be built :)
[05:26] <fabbione> well i mean that the standard headers are not ok for xen
[05:26] <fabbione> since include/asm-xen is missing in the standard ones
[05:26] <lamont> so it sounds almost like there's a xen-i386 architecture, and i386 knows to build both i386 and xen-i386
[05:27] <fabbione> exactly
[05:27] <fabbione> if you want to look at it from a pure theoretical point of view
[05:27] <fabbione> than the Arch is xen-i386
[05:27] <fabbione> or even better: Arch: xen built on i386
[05:28] <fabbione> but clearly we can handle as we want internally
[05:28] <fabbione> we are not introducing a brand new source, just a patch on top of what already exists
[05:28] <fabbione> it's almost like we do for hppa
[05:31] <lamont> coolness
[05:31] <lamont> end of week?
[05:32] <fabbione> i can't remember
[05:36] <zul> ooh...i fucked up my palm
[08:44] <fabbione> YAY
[08:44] <fabbione> first full build of XEN packages
[08:44] <fabbione> approx 4 hours
[08:44] <zul> oi...thats alot
[08:44] <fabbione> on i386 + distcc + ccache and -j 15
[08:45] <fabbione> well probably ccache got outdated
[08:45] <fabbione> or something
[09:01] <zul> fabbione: motu team has been asking me about the kernels in universe since they are not installable anymore should be tell tem to sync with debian for only arches we support?
[09:03] <fabbione> zul: they should be able to decide themself. either solutions work for me
[09:03] <fabbione> and the xen kernels are not compiled properly
[09:03] <zul> okie dokie
[09:03] <fabbione> damn make_kpkg
[09:03] <zul> hehe
[09:03] <fabbione> they build, but they can't boot
[09:04] <fabbione> file xen-linux-2.6.10-5-686-xen0 
[09:04] <fabbione> xen-linux-2.6.10-5-686-xen0: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
[09:04] <fabbione> tsk
[09:04] <zul> hehe
[09:06] <zul> ill tell them to sync 386,686,686-smp,k7,k8 any others?
[09:06] <fabbione> powerpc? ia64? sparc?
[09:06] <zul> oh yes...
[09:06] <zul> not on my radar ;)
[09:07] <fabbione> lamont: do you care about hppa?
[09:11] <lamont> fabbione: sure
[09:12] <lamont> or do you mean something specific?
[09:12] <fabbione> lamont: sync from debian -> universe
[09:12] <lamont> syncing what?
[09:13] <lamont> 2.6.11?
[09:14] <zul> 2.6.8
[09:18] <lamont> 2.6.8 is ancient for hppa, unless kyle has been busy...
[09:21] <kylem> i've not uploaded anything recently.
[10:08] <zul> fabbione: sync debian's 2.4 stuff as well...i wouldnt think so because of initrd-tools and the like
[10:09] <zul> because if i can recall jbailey said they havent been tested
[10:09] <fabbione> whatever :)
[10:10] <jbailey> zul: I'm guessing by now I would've heard some bitching if initrd-tools in Ubuntu was b0rked on 2.4
[10:10] <zul> ok thats cool..
[10:13] <lamont> the debian 2.6.8 kernel for hppa is the one with the "expect bug"
[10:14] <lamont> so probably not a good idea to sync that one
[11:13] <zul> later