[01:58] <TheMuso> 
[02:13] <mjg59> BenC: Around?
[02:14] <mjg59> BenC: Something seems to have gone very wrong with psmouse - it's referencing dmi_get_system_info for some reason
[02:15] <mjg59> And failing to load as a result
[02:15] <mjg59> I'm guessing it's coming from the synaptics/dynabook patch, but...
[02:16] <mjg59> That duplicates near identical code baove
[02:18] <BenC> hmm
[02:21] <BenC> mjg59: how long will you be around?
[02:21] <mjg59> BenC: An hour or so?
[02:21] <BenC> I can do another build minus that patch and see what it does
[02:21] <BenC> probably take longer than an hour
[02:23] <BenC> that patch looks pretty harmless though
[02:23] <mjg59> Yeah
[02:23] <mjg59> But I'm getting "Unknown symbol dmi_get_system_info"
[02:23] <BenC> or do you mean that it has a missing symbol?
[02:23] <BenC> ah
[02:24] <BenC> let me see if I can fix that
[02:26] <BenC> dmi_get_system_info wasn't exported until 2.6.13
[02:26] <BenC> it's been there though
[02:26] <BenC> let me just add the export symbol
[02:27] <mjg59> Hrm. But how did that work, then?
[02:28] <mjg59> There was already an entry there
[02:29] <BenC> I don't see any other user of dmi_get_system_info() in there
[02:29] <mjg59> Oh, argh. I'm sorry, I'd entirely missed that section of the diff.
[02:29] <mjg59> Fuckit. Entirely my fault.
[02:30] <BenC> no problem, I've already got a diff for dma_scan.c to export the symbol
[02:30] <mjg59> Ok
[02:58] <jbailey> dilinger: klibc just accepted to Debian.  initramfs-tools hopefully a day behind it.
[02:59] <jbailey> dilinger: I was talking with maks earlier.  I'm going to twiddle the code soon to be non-native so that only the rules files need to be different between Debian and Ubuntu.
[03:21] <mjg59> BenC: Other than that, it all looks very good indeed!
[03:32] <BenC> cool
[03:37] <BenC> fix is in the repo
[03:37] <BenC> I've got amd64, i386 and ppc all building
[03:39] <mjg59> Rocking
[04:03] <zul> heylo
[04:04] <zul> heh..i watched my first episode of lost tonight...i dont get it
[04:06] <mkrufky> it's a good show... i always forget to watch it
[04:28] <zul> heh big brother is over so i have to get hooked on something ;)
[05:59] <fabbione> morning guys
[06:31] <BenC> hey fabbione
[06:31] <BenC> and good night :)
[06:31] <BenC> current baz archive should build for you, I've done i386, amd64 and ppc builds already
[06:40] <fabbione> BenC: it's building already on sparc
[06:40] <fabbione> i will let you know before you wake up
[10:51] <fabbione> BenC: the kernel builds on sparc!
[10:52] <fabbione> BenC: if you don't change anything fancy it should be ok
[02:09] <zul> heylo
[02:09] <fabbione> yo
[02:14] <zul> how goes the battle?
[02:15] <fabbione> as usual :)
[02:15] <fabbione> and you?
[02:29] <zul> ditto
[02:29] <zul> oh oh..its Kamion duck!
[02:30] <zul> bleah..
[02:30] <Kamion> just thought I should be here, since it seems I'm blocking the next Colony release on the next kernel upload
[02:30] <Kamion> (which is fine, but just means I need to know what's going on)
[02:32] <zul> Kamion: heh all we do here is make fun of the motu team ;)
[02:33] <Kamion> oh, here too? ;-)
[02:36] <zul> lol
[02:41] <zul> so when can we started on the next kernel version?
[02:41] <zul> 2.6.14 isnt it?
[02:42] <zul> er...2.6.14-rc..blah
[02:42] <zul> my mind is numb
[02:45] <janimo> is there a getting started on the ubuntu kernel sort of doc on the wiki?
[02:45] <janimo> I am interested in tracking the current work of the kernel team
[02:46] <janimo> and do local changes in the right way (baz branch, make-kpkg etc.)
[02:47] <janimo> the url referenced in the channel topic seams to be an archive of the debian/ dir only
[02:47] <janimo> do I need to work with the linux-sources package?
[02:48] <zul> janimo: not really..what i do is is the following:
[02:48] <zul> apt-get source linux-source-2.6.X
[02:48] <zul> rm -rf debian directory
[02:48] <zul> baz get kernel-team@ubuntu.com--2005/kernel-debian-preX debian
[02:48] <zul> cd debian
[02:48] <zul> baz branch <your local arch>
[02:49] <zul> do what you want
[02:49] <zul> debuild
[02:49] <zul> or something like that
[02:49] <janimo> so everything happens in the debian/ dir because of dpatch so the upstream source is never touched right?
[02:50] <janimo> and you export you local debian/ baz branch if you want to publish your changes
[02:51] <janimo> I once dpkg-buildpackage-d linux-source and it took a loooong time because it made images and whatnot for all archs
[02:51] <janimo> does debuild do the same thing?
[02:52] <zul> janimo: yeah remove the config for the arches you dont want in debian/config
[02:52] <zul> debuild does the same thing
[02:52] <janimo> and when a new linux-source package is available go to step 1?
[02:52] <janimo> thanks, very helpful so far :)
[03:21] <infinity> janimo : debuild calls dpkg-buildpackage, so of course it owuld do the same thing.
[03:26] <BenC> jeez, just when I thought we'd have a kernel upload today
[03:33] <zul> hmm?
[03:38] <BenC> couple of security patches
[03:38] <BenC> nice thing to find in your inbox when you wake up planning a kernel upload :)
[03:38] <Kamion> ouch
[03:39] <BenC> zul: btw, I have i386 kernels at http://people.ubuntu.com/~bcollins/kernels/ if you want to test vmware
[03:39] <Kamion> what sort of timescale are we looking at? if it's multiple days, I'll do the beta release this afternoon; if it's relatively quick, I'd rather wait so that we have a beta release with the final-ish kernel
[03:39] <BenC> Kamion: pushes it from this morning to later this afternoon is all
[03:39] <BenC> they are small patches, so quick to review
[03:40] <BenC> Kamion: oh, this is an ABI changing upload, I'll need your assistance today if possible
[03:40] <Kamion> ah, ok, that's not too bad
[03:41] <BenC> merging those two patches, and getting the abi file into the kernel .deb's is all I have to do for release
[03:41] <Kamion> BenC: yes, fabbione warned me - I should be available, with the possible exception of about 18:00-20:00 UTC tonight
[03:42] <BenC> should be done way before then, so that works out
[03:42] <Kamion> cool
[03:42] <fabbione> BenC: are you going to merge the security patches now?
[03:44] <BenC> yes
[03:44] <BenC> doing it as we speak :)
[03:46] <BenC> fabbione: so sparc64 built, did it boot? 
[03:48] <fabbione> BenC:  it did build.. i am confident that it boots
[03:48] <fabbione> i will test with final as soon as you commit all the changes
[03:53] <fabbione> BenC: also.. it's time to update libraw1394 :)
[03:53] <fabbione> isn't it?
[03:54] <BenC> do you mean upstream, or packaged?
[03:54] <fabbione> package :)
[03:55] <fabbione> upstream is at 1.2.0 so.8.something
[03:55] <fabbione> the package is 0.10. so.5
[03:55] <fabbione> i have 1.2.0 ready, but quite a bunch of pkgs need a rebuild
[03:55] <fabbione> so it's not for breezy
[03:55] <fabbione> that will allow us to build libiec61883-1.0.0
[03:55] <fabbione> and finally enable mythtv firewire support :)
[03:57] <BenC> mythtv has firewire support now!?
[03:58] <BenC> do you know if there's a mythtv plugin for Roku boxes now?
[03:58] <BenC> I need to get my Roku setup again so I don't have to burn all these mp4's and stuff
[03:58] <BenC> would be nice if the vlan client worked
[03:59] <fabbione> no idea..
[03:59] <fabbione> i am at the first install of mythv in my life
[04:00] <fabbione> it supports firewire.. that's sure
[04:00] <fabbione> i dunno about the Roku
[04:23] <zul> BenC: heh i was making them last night but i got tired...got vmware installed and at the time was downloading the iso
[04:35] <BenC> any make-kpkg experts here
[04:36] <mx|gone> is it too late to get the bluetooth hid patch into the ubuntu kernel?
[04:36] <mkrufky> i thought YOU were the expert ;-)
[04:36] <BenC> I need a way to prepare a kernel image, and just before it gets dpkg-deb --build, add a file to it
[04:36] <BenC> I'm "knowledgable" :)
[04:36] <BenC> mx|gone: maybe not, point me to it
[04:36] <mkrufky> benc: i think there's an easy way to do that
[04:37] <mkrufky> on debian's howto page for building custion kernel:
[04:37] <mkrufky> where it explains how to build the pcmcia modules
[04:37] <mkrufky> i'll go look, brb
[04:37] <mx|gone> BenC: http://www.holtmann.org/linux/kernel/patch-2.6.12-mh3.gz
[04:37] <mx|gone> BenC: it adds mouse wheel support for bluetooth mouses among other things
[04:38] <mkrufky> http://www.us.debian.org/releases/stable/i386/ch08s05.html.en
[04:38] <mkrufky> im not sure if it builds the modules into the same package, or if it ends up being a separate .deb
[04:38] <BenC> that's a big patch
[04:38] <fabbione> BenC: yes.. there is a way..
[04:38] <fabbione> BenC: just a sec that i dig it up
[04:39] <mx|gone> BenC: let me know if that'll be able to go in
[04:39] <BenC> mx|gone: is the bt_cb() function part of the patch that makes the mouse wheel work?
[04:39] <fabbione> BenC: look at debian/notification-install
[04:39] <mkrufky> hmmm.... ok, after further reading, i can tell that it builds it as separate package, so maybe that doesnt help u... sorry
[04:39] <BenC> that's most of the patch
[04:40] <fabbione> BenC: the mechanism is a bit complex
[04:40] <mx|gone> BenC: you'd have to contact marcell holtmann about it
[04:40] <BenC> mx|gone: doubtful this patch, as-is, will even get into breezy, much less this next kernel upload
[04:40] <fabbione> that file is copied into debian/build/build-$flavour/debian/postinstall.d (or something like that)
[04:40] <fabbione> and it is executed when building the deb by make-kpkg
[04:40] <BenC> mx|gone: if you can get it down to just the part that makes the mouse wheel work, then there's a possibility
[04:40] <mx|gone> hmm, ok
[04:40] <fabbione> BenC: you can use a similar thing to copy the abi
[04:40] <fabbione> it's like an hook
[04:40] <BenC> fabbione: ok, thanks
[04:41] <fabbione> BenC: you need to modify debian/rules in the same places as where notification* is mentioned
[04:41] <fabbione> and in the same way
[04:41] <fabbione> i am pretty sure if you duplicate it, it will just work
[04:41] <BenC> debian/image.d
[04:41] <BenC> got it
[04:42] <mx|gone> BenC: hmm, it looks like bt_cb is just a define to a structure in an already defined structure
[04:43] <janimo> how hard would it be to provide  vmlinux for x86 at least as a separate deb?
[04:44] <BenC> mx|gone: yeah, but it makes the patch really hard for me to review
[04:44] <janimo> I think make-kpkg has support for this,but probably puts it in the same .deb as linux-image
[04:44] <BenC> janimo: why do you need vmlinux?
[04:44] <mx|gone> BenC: ok, that's fair... I'll talk to marcel and see if it's possible to just get the mouse wheel stuff... if not, I'll just compile a kernel for another 6 months
[04:45] <mjg59> jbailey: Hmm. My initramfs doesn't seem to be loading the fan modules.
[04:46] <janimo> BenC for oprofile
[04:46] <BenC> oprofile can't use vmlinux, or System.map?
[04:46] <janimo> that's the usual reason, there's also a year old debian bug on the subject I think
[04:46] <BenC> vmlinuz I mean
[04:46] <janimo> no it needs the symbols
[04:47] <janimo> I don;t think one can create the original vmlinux elf image from the bootable vmlinuz
[04:47] <jbailey> mjg59: Ah.  Any idea  why? =)
[04:48] <jbailey> Oh hmm
[04:48] <janimo> but as if oprofile could be modified to use vmlinuz+zyztem.map that;s beyond me :)
[04:48] <jbailey> mjg59: I don't see anything in here that would cause them to get loaded.
[04:49] <jbailey> There must be because of the guy who was bitching about it though.
[04:50] <jbailey> In my tree I have init-premount/acpid
[04:50] <jbailey> No, it's there.
[04:50] <jbailey> Perhaps I'm just insane
[04:50] <mjg59> jbailey: Hm.
[04:51] <jbailey> Is it loading thermal?
[04:53] <mjg59> Nope
[04:55] <jbailey> Is /usr/sahre/initramfs-tools/scripts/init-premount/acpid chmod +x'd?
[04:58] <mjg59> Yup
[05:02] <Kamion> mx|gone: you probably want to get it sorted out in the dapper kernel in about one month's time, rather than six months' time. :-)
[05:08] <fabbione> BenC, jbailey: after the new kernel with the ABI change is uploaded.. remember to upload klibc with the new B-D
[05:10] <mx|gone> Kamion: good point :)
[05:26] <infinity> Great, I upgraded an amd64 machine that hadn't been upgraded for ages, and with the current kernel, I get that wonderful "USB or your network, pick one, but not both" bug.
[05:28] <zul> irq conflict?
[05:29] <infinity> Is there such a thing in the modern world?
[05:29] <zul> you never know :)
[05:29] <infinity> (And it worked fine with the older -6- kernel I had installed, upgrading to the curen -8- breaks it)
[05:30] <infinity> http://www.spinics.net/lists/usb/msg02643.html
[05:30] <zul> i didnt do it :)
[05:30] <infinity> These are the error messages I get (no, haven't tried the workaround yet, but odd that I never needed it before now)
[05:30] <fabbione> infinity: yes there is such a thing
[05:32] <infinity> Well, not on the same IRQ anyway, so that rules that out.
[05:32] <BenC> irq's can be shared anyway
[05:32] <infinity> USB1.0/1.1 works fine (my mouse works), but if I plug in a USB2.0 device, the network dies.
[05:32] <BenC> unless the driver is broken
[05:32] <infinity> BenC : And yes, I know that.
[05:32] <infinity> And on boot, if I have a USB2.0 device plugged in, I get:
[05:33] <infinity> usb 5-3: device descriptor read/64, error -71
[05:33] <BenC> I read another bug report similar to that
[05:33] <infinity> Repeatedly.
[05:33] <infinity> (And the network driver no workie)
[05:33] <BenC> would be nice to know which kernel version started causing that
[05:33] <BenC> any way you could backup in kernel revisions until the problem is fixed?
[05:33] <infinity> I jumped a bit too far ahead ot be of use there.
[05:34] <infinity> Unless we have a repository of old kernel binaries somewhere.
[05:34] <BenC> I should start keeping them :)
[05:34] <BenC> would be easy to build them, just time consuming
[05:34] <BenC> we keep the old source atleast
[05:34] <infinity> I went from -6.7 to -8.13... So, that's 6 revisions.
[05:35] <BenC> yeah, that's a crap load of changes and also predates me starting to maint the kernel
[05:35] <BenC> so there's a lot that was done that I don't know about
[05:36] <infinity> Rather, yes.
[05:36] <infinity> I wouldn't have even bothered mentioning it, except ISTR someone whining on the lists about a very similar issue, so I suppose I'm not isolated.
[05:36] <BenC> I can try to get you the first -7 built
[05:36] <BenC> start in the middle and go from there
[05:37] <BenC> I'll do a build of -X.10
[05:38] <infinity> Given that this is (supposedly) a long-standing issue (since 2.6.9-bk7?), I wonder if maybe a patch got dropped that was fixing/changing this behavior...
[05:38] <infinity> Then again, that list post may be a red herring.   I suppose I should try the workaround and see.
[05:39] <infinity> Though, I should also ifnish testing lrm, upload it, and go to bed.
[05:39] <infinity> (My girlfriend's been yelling at me to stop working for hours...)
[05:40] <BenC> listen to her :)
[05:40] <infinity> If you want to build a mess of test kernels, though, it's amd64-k8, and I can pick 'em up in the morning and run with them. :)
[05:40] <BenC> sure, I can start a few builds tonight
[05:40] <BenC> keep an eye on http://people.ubuntu.com/~bcollins/kernels/infinity/
[05:41] <BenC> I'll put them there
[05:41] <infinity> Rock.
[05:44] <fabbione> BenC: what's the situation with the baz archive?
[05:44] <BenC> fabbione: it's stable right now
[05:45] <BenC> I am just working on the abi file in the .deb
[05:45] <BenC> once that's done, I'll be doing an upload
[05:45] <BenC> the two CAN patches are in
[05:46] <BenC> fabbione: getting a file into the .deb is easy...getting the right information to the script that runs is not
[05:46] <fabbione> BenC: ok
[05:46] <fabbione> two?
[05:46] <fabbione> there were 3 patches
[05:46] <BenC> I only saw two
[05:46] <BenC> ...
[05:46] <fabbione> there are 3
[05:47] <fabbione> one with CAN, 2 without
[05:47] <fabbione> + the info about an old CAN needs renumbering
[05:47] <BenC> ah, I see now
[05:56] <BenC> I don't see any reference to the obsolete CAN in changelog or in patches/*
[05:59] <fabbione> it probably didn't affect breezy
[06:05] <BenC> ah, cool
[06:05] <BenC> the first CAN isn't needed, it's already in there
[06:06] <fabbione> BenC: perfect...
[06:07] <fabbione> so everything is in the repo..
[06:07] <BenC> hold a sec
[06:07] <BenC> let me commit the abi file chang
[06:07] <BenC> and that will be 100% 
[06:07] <infinity> Does that mean you're about to upload?  Or are you going to rest on it for a bit?
[06:08] <infinity> I'm in the last steps of testing lrm, but if you're about to push a new kernel, I don't see the point in two lrm uploads in a few hours.
[06:08] <BenC> going to sit on it for about an hour while I start a test build on i386 and amd64
[06:08] <BenC> then I'll upload
[06:08] <BenC> lrm == linux-restricted-modules?
[06:08] <infinity> Yeah.
[06:08] <BenC> cool
[06:09] <BenC> 2.6.12-9.14 is the kernel release version, FYI
[06:09] <infinity> Not really.  Have you looked at it?
[06:09] <BenC> yes, cool that I wont have to do it :)
[06:10] <mkrufky> BenC: your 2.6.12 kernel will contain the 2.6.12.y patches, correct?
[06:10] <infinity> yeah, I'll just do two uploads, though, cause I'll definitely beat you to it, and I need sleep.
[06:10] <BenC> it has 2.6.12.6
[06:10] <infinity> So I'll upload lrm for the ABI bump in the morning (which should be around when all the kernels are finally built anyway)
[06:10] <BenC> infinity: ok, sounds good
[06:10] <mkrufky> ok perfect... there's something in 2.6.12.3 that i want to be sure that all the distros get
[06:10] <BenC> fabbione: done
[06:11] <BenC> hmm, hold a sec
[06:12] <fabbione> BenC: ok...
[06:14] <BenC> ok, update and fire away
[06:14] <BenC> i386 and ppc builds going
[06:15] <fabbione> roger that
[06:31] <fabbione> BenC: building now
[07:27] <zul> jbailey: ping
[07:46] <jbailey> zul: pong
[08:03] <fabbione> BenC: -rw-r--r-- root/root    151375 2005-09-22 19:47:41 ./boot/abi-2.6.12-9-sparc64
[08:03] <fabbione> i guess it works
[08:03] <fabbione> ;)
[08:03] <fabbione> and it boots
[08:04] <fabbione> BenC: for what is my concern, you are good to go
[08:07] <BenC> sweet
[08:07] <BenC> thanks
[08:19] <fabbione> no problem
[08:26] <zul> jbailey: you know that email i sent you about the libc stuff? you never got back to me me thinks
[08:30] <jbailey> zul: Crap, right sorry.
[08:45] <zul> no problem..
[08:46] <zul> i know you kind of have been busy
[08:50] <jbailey> By shared memory locks, do you mean page locks from mlock, or are you talking posix locks / semaphores?
[08:54] <jbailey> zul: ^^ (In case you need a nick highlight)
[09:04] <jbailey> dilinger: Around?
[09:04] <jbailey> dilinger: I remember you had a magic solution of some sort for cdbs taht didn't involve me doing a weird set -x or whatever at the top of each function.
[09:04] <jbailey> I'm trying to remember what you had done...
[09:04] <jbailey> I need something like it for initramfs-tools
[09:06] <zul> posix locks
[09:11] <jbailey> Hmm.
[09:11] <jbailey> If I do exec >/tmp/debug 2>&1
[09:12] <jbailey> And then later I exec init, those will persist, won't they?
[09:12] <jbailey> I already do:
[09:12] <jbailey> exec run-init ${rootmnt} ${init} "$@" </root/dev/console >/root/dev/console
[09:13] <jbailey> Do I need to add a 2>&1 to that to get fd2 reset?
[09:16] <dilinger> jbailey: convince shell authors to make set -x global ;)
[09:16] <dilinger> clint chagned posh's behavior to do that
[09:16] <dilinger> although it's partially incorrect
[09:16] <jbailey> It being, making it global?
[09:17] <dilinger> anyways, what i was doing was having a variable at the top of each function that actually executed set -x, but shells are too inconsistent for that to really work correctly
[09:17] <jbailey> I also wish that a "set - foo bar baz" didn't reset set -x, which it seems to for all of them
[09:17] <dilinger> yes
[09:17] <dilinger> it being making it globally
[09:17] <dilinger> i meant to ping clint about that, though; it's buggy
[09:18] <dilinger> foo() { set -x; bar; }   bar() { x=1; }
[09:18] <dilinger> foo
[09:18] <dilinger> x=2
[09:18] <jbailey> Wha?
[09:18] <dilinger> xtrace is turned on in foo, and bar inherits it, but after foo is finished running, xtrace is back off
[09:18] <dilinger> in posh
[09:18] <dilinger> which is not really global :)
[09:19] <jbailey> You get an x=2 in there?
[09:19] <dilinger> no, i'm putting an x=2 in there to show that xtrace doesn't diplay it
[09:19] <jbailey> Oh, I thougt you were saying that was output. =)
[09:19] <jbailey> I was like, umm, yeah, that's serious. =)
[10:00] <zul> right im off..
[10:36] <spayne> hi people
[10:36] <spayne> still got this ndiswrapper.ko bug
[10:36] <spayne> when seems to be related to USB and hotplug
[10:36] <spayne> is anyone around to help?
[10:41] <jbailey> I know nothing. =)
[10:42] <jbailey> <voice who="Manuel" Show="Faulty Towers"/>
[10:44] <spayne> Ka?
[10:44] <spayne> Ce?
[10:45] <spayne> http://bugzilla.ubuntu.com/show_bug.cgi?id=14147
[10:48] <BenC> what sort of bug?
[10:53] <spayne> it is assinged to you :)
[10:53] <spayne> read the bug link
[10:54] <spayne> basically, ndiswrapper.ko isn't being loaded for some USB WiFi devices
[10:54] <spayne> as the USB stack needs to be loaded before ndiswrapper
[10:54] <spayne> it is either related to
[10:54] <spayne> a.) USB stack
[10:55] <spayne> b.) the kernel
[10:55] <spayne> c.) hotplug/udev
[10:57] <spayne> BenC: any ideas?
[10:59] <BenC> probably hotplug
[10:59] <spayne> yeh
[11:00] <BenC> the kernel wouldn't know anything about it directly
[11:00] <spayne> any thoughts on fixing it?
[11:00] <BenC> if the right information is being exported, hotplug should handle it
[11:00] <BenC> I know nuteeng of this hotplug magic
[11:00] <spayne> need to go
[11:00] <spayne> bye
[11:00] <BenC> good luck
 dilinger: fix uploaded
[11:11] <dilinger> jbailey: apparently a brand spanking new posh in debian's incoming :p
[11:14] <jbailey> Ahaha, sweet.