[12:53] <zul> BenC: ping
[12:54] <zul> ...if you arent watching football
[01:13] <infinity> BenC: Yeah, I could do with another fgrlx version bump.  I'll prepare it today.
[03:08] <BenC> zul:games over, skins won
[03:08] <BenC> zul: what's up?
[03:18] <zul> BenC: whats with the ubuntu-edgy gits
[03:33] <infinity> zul: Tollef fixed some arch includes in your xen git tree, apparently.  Mind doing an upload of that, so xen-restricted-modules doesn't FTBFS?
[03:34] <zul> infinity: sure
[03:34] <zul> oh btw the new git archive is http://dev.laptop.org/git.do?p=projects/ubuntu-xen-2.6.17;a=summary
[03:35] <infinity> Not much plan here to do anything with it.  I was only fixing xen-r-m for you, out of the kindness of my heart (or because I was bored yesterday; pick one)
[03:36] <zul> i would like to think its kindness but im picking bored :)
[03:41] <infinity> In the future, try to remember to use the LRM orig.tar.gz for XRM... Uploading 90 MB to make a few K of fixes was unfun. :)
[03:41] <infinity> (I'll rev XRM for you when I bump fglrx in LRM)
[03:41] <zul> thanks
[03:42] <zul> sorry...wont happen again
[03:43] <infinity> Is your git tree synced with the main kernel?
[03:44] <infinity> If so, I was wondering if it might not be a bad idea to artificiall bump your ABI to match, so people know that the xen kernels have the same set of fixes/drivers.
[03:44] <infinity> If the source isn't even close to common, then don't do that, obviously. :)
[03:45] <zul> no it hasnt been synced up yet unforuntaely..
[04:24] <BenC> zul_: ubuntu-edgy gits are where edgy kernel is coming from now
[04:24] <BenC> I'm taking some time to merge ubuntu-2.6 to latest kernel
[04:24] <BenC> start getting out some daily builds early for bleeding edgy fools like me :)
[04:25] <BenC> 2.6.19 development is probably going to lead out about 2 months into our next release, so I want to get a head start...have packages ready the day edgy+1 opens up
[04:25] <BenC> plus make packages available for jbailey and doko for edgy+1 toolchain
[05:34] <fabbione> BenC: ping?
[06:33] <fabbione> BenC: dude.. you didn't pull the PROM_CONSOLE patch in 10.25...
[06:33] <fabbione> we need that to fix the CPU softlookups on NIagara
[01:21] <tonfa> is there a reason for using git instead of quilt/quilt-like for the ubuntu kernel tree ?
[01:21] <tonfa> I see other distro are using a quilt like process
[01:22] <tonfa> and that way you can cleanly see the different features they added
[01:24] <infinity> Much easier to cherry-pick changes from upstream with git.
[01:25] <tonfa> but couldn't it be converted to a patch ?
[01:25] <infinity> "it"?
[01:25] <tonfa> cherry-pick is just patch importing + 3-way merge, right
[01:25] <tonfa> the cherry-picked changeset
[01:26] <infinity> You want a massive "ubuntu" patch to see against the upstream kernel, or you want every one of our patches broken out?
[01:26] <infinity> The latter is a serious pain, because then you can't easily use git anymore to merge as both we and upstream move.
[01:26] <zul> infinity: could you kick 3.0.3~rc1 in the butt its still stuck in binary-new
[01:26] <tonfa> that's the same workload as akpm
[01:26] <infinity> (for instance, Ben is currently merging our 2.6.17 with upstream's 2.6.19... Much simpler without dealing with hundreds of patches outside of git)
[01:27] <tonfa> quilt pop -a  ; update to upstram ; quilt push -a
[01:27] <tonfa> *upstream
[01:27] <infinity> Erm, no.  You're not quite grasping it.
[01:27] <tonfa> you will have to resolve conflicts during the push, of course
[01:28] <infinity> If you have a revision history that says "I pulled changeset 1234 from 2.6.18", and 2.6.19 has the same in its history, the merge is seamless.  If we have a bunch of patches, we have to hand-merge them or examine each one to see if we should discard it.
[01:28] <infinity> The latter is far more effort, for very little gain.
[01:28] <infinity> zul: I'll poke it in a sec.  I've been pitti's bitchs with mangling security builds for a while.
[01:29] <zul> infinity: coolio...thanks
[01:30] <infinity> zul: Are you going to give me an unbroken xen-source-2.6.17? :P
[01:31] <zul> i just uploaded it last night
[01:31] <zul> argh...it timed out on me..
[01:31] <zul> yeah ill upload it again
[01:31] <infinity> Kay.  xen-3.0 processed.
[01:32] <zul> thanks..
[01:40] <tonfa> infinity: but you can first drop all the backports, when merging to the upstream version
[01:41] <zul> right im off to work
[01:43] <infinity> tonfa: This implies we only have one upstream.
[01:43] <tonfa> what is the other upstream ?
[01:43] <infinity> tonfa: We merge patches from all over, and prefer to merge from git repos that all merge to<->from linus, so it all sort of self-resolves (with exceptions, of course)
[01:44] <tonfa> so upstream is linus-2.6
[01:44] <infinity> tonfa: We're certainly not just backporting from one branch, is my point.
[01:45] <infinity> Anyhow, not much point in arguing it, the decision was made during the dapper cycle, it's worked well for us, I don't think Ben (who has to do the majority of the work) is itching to switch.
[01:45] <tonfa> ok, I understand that it makes the work easier for you
[01:46] <tonfa> (but not necessarly for other people, distro)
[01:46] <infinity> yes, we're aware that patch-digging becomes a bit more difficult.
[01:46] <infinity> But that's not really our number one goal either.
[02:11] <tonfa> utrace looks interesting for implementing apport
[02:44] <zul> god...i love monday mornings dns died at work
[02:45] <BenC> fabbione: ping
[02:59] <zul> BenC: ping
[03:03] <BenC> zul: pong
[03:06] <zul> BenC: the kernel-package patch i was talking about is at http://70.29.61.171/ubuntu/kernel-package-debdiff.patch
[03:13] <BenC> zul: thanks
[03:15] <AnAnt> there is a bug in the kernel I think
[03:15] <AnAnt> when I insert my MMC card it doesn't get mounted
[03:15] <AnAnt> I have to manually modprobe tifm_sd 
[03:17] <BenC> mmc layer isn't very hotplug friendly
[03:18] <AnAnt> huh ?
[03:18] <AnAnt> BenC: but it used to work in 2.6.15 when I patched the kernel
[03:19] <AnAnt> BenC: I patched the kernel for MMC4
[03:19] <AnAnt> it was a couple of lines only
[03:19] <AnAnt> I don't think that this patch did anything to hotplug, and it worked in Dapper
[03:20] <BenC> by hotplug I mean that the drivers either provide the right information so that hotplug knows to load the module, or it loads the module itself
[03:21] <BenC> tifm wasn't in dapper, IIRC
[03:21] <AnAnt> hmm
[03:21] <AnAnt> so it won't be fixed at stable release ?
[03:24] <ivoks> hi
[03:26] <zul> BenC: i could upload the fix if you want
[03:38] <fabbione> BenC: pong
[03:50] <fabbione> BenC: i need to take my son out for a walk. will try to pass by later
[03:59] <AnAnt> zul: the fix you talk about is for the MMC ?
[04:00] <zul> wha?
[04:00] <AnAnt> zul: nevermind
[04:00] <zul> i need the context
[04:02] <zul> BenC: what are the chances of getting xen into the edgy+1 kernel?
[04:02] <zul> i mean i can do the necessary grunt work though
[04:05] <BenC> zul: Well, I'm starting from scratch on the edgy+1 kernel
[04:05] <BenC> I want to take a different route with some of the stuff we've been doing
[04:05] <tonfa> BenC: will you consider using a queue of patches ?
[04:05] <BenC> mainly, I want all our external drivers in an ubuntu/ sub directory to keep things cleaner
[04:05] <BenC> tonfa: no
[04:06] <tonfa> ok
[04:06] <zul> BenC: ah ok so what like debian is doing now
[04:06] <BenC> tonfa: But the subdirectory for our custom drivers will make it easier to diff things and such
[04:06] <BenC> s/custom/third-party/
[04:06] <zul> heh well let me know when you have something and i can beat it in
[04:07] <BenC> there's way too many conflicts when I go from one major version to another
[04:22] <Keybuk> BenC: we've never mounted /proc/bus/usb with special permissions to give other people write access
[04:22] <Keybuk> that would be bad
[04:27] <fabbione> BenC: re
[04:28] <BenC> Keybuk: I don't disagree with the permissions, but I disagree that doing it that way would solve the problem
[04:28] <BenC> fabbione: where can I pull your kenrel upload changes from?
[04:28] <fabbione> BenC: the patch is the same as the one i did send via email to you and davem.
[04:29] <fabbione> i had to do the upload without git, because you created the edgy branch and i wasn't sure from which one you did release 10.24
[04:29] <BenC> fabbione: most likely from edgy? :)
[04:29] <fabbione> BenC: kernel.org/git doesn't show any history for that branch.. only 2 commits
[04:29] <fabbione> that's why...
[04:29] <fabbione> otherwise i would have done it :)
[04:30] <fabbione> i admit i got confused
[04:30] <BenC> no problem
[04:30] <fabbione> but i can resend you the debdiff
[04:30] <BenC> you did use the .orig.tar.gz, right?
[04:30] <fabbione> yes
[04:30] <BenC> excellent
[04:30] <fabbione> i used apt-get source 
[04:30] <fabbione> + the patch + changelog
[04:30] <fabbione> of course mv debian/abi/foo to match the upload
[04:31] <fabbione> no more no less
[04:31] <Keybuk> BenC: which problem?
[04:37] <BenC> Keybuk: The problem where vmware can't access USB devices
[04:37] <Keybuk> I've no idea what vmware does to that directory
[04:37] <Keybuk> then they had that problem with dapper
[04:37] <BenC> it reads/writes to the dev entries
[04:37] <Keybuk> dapper didn't give anything other than root access to them
[04:38] <BenC> I'm not arguing that
[04:38] <Keybuk> the fix is easy
[04:38] <Keybuk> make vmware look in /dev/bus/usb first
[04:38] <Keybuk> and then the user running vmware will have permission to write to any usb devices that the user has permission to write to
[04:39] <BenC> if vmware were configurable to do that, we wouldn't be discussing this :)
[04:39] <BenC> I personally don't care either way, and I'm not pushing for a real fix
[04:39] <Keybuk> the whole point of our relationship with vmware is that we can get them fix this kind of thing, no?
[04:40] <BenC> I'm just saying that if proc/bus/usb gets mounted like you are saying, there's no point in doing so
[04:40] <Keybuk> the reason /dev/bus/usb was *invented* was this problem - giving non-root users access to usb devices
[04:40] <BenC> I'm out of the loop on this
[04:40] <BenC> like I said, I'm just pointing out that it's useless to mount it with 0600 perms if it's not going to help
[04:41] <BenC> I'm not saying mount it with other perms, just don't mount it at all if the security issues are the case
[04:41] <Keybuk> haven't people claimed that mounting it (with the default 644 perms) fixes it?
[04:41] <BenC> yes, it does
[04:41] <Keybuk> how does that fix it?
[04:41] <Keybuk> it can't write to the devices still
[04:41] <BenC> err, well not really
[04:41] <BenC> 644 allows vmware to see the device, but not use it
[04:43] <Keybuk> ok
[04:43] <Keybuk> doesn't vmware just use its kernel modules of doom to do this kind of thing?
[04:44] <BenC> Keybuk: how does one get perms for /dev/bus/usb/ devices?
[04:44] <Keybuk> /etc/udev/rules.d
[04:44] <BenC> Keybuk: no, it doesn't use the kernel module since the internal API changes a lot more than the userspace one does
[04:44] <Keybuk> e.g. /etc/udev/rules.d/45-libgphoto2.rules
[04:46] <BenC> I wish dev/bus/usb had a devices file, we could just bind mount it
[04:48] <Keybuk> we could probably fake one :p
[04:48] <Keybuk> have a udev rule that updates it every time a usb device is added or removed
[04:48] <Keybuk> reads from sysfs
[04:48] <Keybuk> and writes out the file
[04:49] <zul>  /win 11
[04:49] <zul> oops
[04:49] <BenC> probably easier to just mount usbfs somewhere hidden, bind mount /dev/bus/usb to /proc/bus/usb and copy the file when usb devices are added or removed
[04:51] <BenC> for some reason my vmware has started running slow as balls
[04:52] <BenC> loadavg is 0.00, and vmware is crawling
[04:52] <BenC> Keybuk: copying the file and bind mount dev/bus/usb to proc/bus/usb seems to let vmware see the device
[04:53] <BenC> I'm trying to test if it actually can use it after I manually changed the perms
[04:57] <Atthar> hi room
[04:58] <Atthar> i want to download linux driver for my modem, what is kernel of 6.06 LTS version?
[04:59] <BenC> Atthar: uname -a
[05:00] <Atthar> im in windows now!
[05:00] <zul> its 2.6.15
[05:02] <Atthar> tnx, but plz see this page: http://www.linuxant.com/drivers/hsf/full/downloads-ubuntu-x86.php i need full number of kernel
[05:02] <BenC> Atthar: that's why you need to use that command: uname -a
[05:03] <BenC> or atleast uname -r
[05:03] <Atthar> ok, tnx BenC
[05:03] <BenC> there are at least 5 different kernels types (flavours) in dapper x86, and depending on if you have the latest kernel version, at least 4 revisions
[05:05] <Atthar> ok, firs i will install the ubuntu and then use uname -a, tnx and good luck :)
[05:07] <BenC> Keybuk: also, why do you want to make proc/bus/usb 0600, when the devices under dev/bus/usb are 0664?
[05:07] <Keybuk> I don't suggest making it anything?
[05:07] <Keybuk> it'd probably be whatever the default is
[05:07] <Keybuk> which appears to be 0644
[05:08] <BenC> your first email said 600
[05:08] <BenC> devmod=600 is what you sent
[05:08] <Keybuk> oh, maybe I was on crack for that one
[05:09] <BenC> Keybuk: I think the bind mount and coping of the devices list is going to be our best bet if you are willing to implement it
[05:09] <Keybuk> where to mount it though?
[05:10] <BenC> hide mount usbfs somewhere with really strict perms, and bind mount dev/bus/usb to proc/bus/usb, copying the devices file on events
[05:10] <BenC> dev/bus/usb/.usbfs ?
[05:12] <Keybuk> *nods*
[05:12] <Keybuk> can do that in mountdevsubfs
[05:17] <tonfa> what was linux-meta ?
[05:17] <tonfa> (that's mentionned in : https://wiki.ubuntu.com/KernelTeam)
[05:19] <BenC> tonfa: linux-meta is a set of meta packages that makes sure you always have the latest kernel and associated packages with it
[05:20] <tonfa> ok, thanks
[05:27] <AnAnt> I removed the quiet option to get boot messages
[05:28] <AnAnt> the problem is that it corrupts the scroll bar
[05:28] <AnAnt> is there a way to change the position in which the boot messages appear ?
[05:28] <BenC> more of a question for #ubuntu
[05:28] <AnAnt> I'm talking about Edgy not Dapper
[05:28] <BenC> remove the splash option too
[05:29] <AnAnt> BenC: but I won't get splash screen then ?
[05:29] <BenC> dapper or edgy, it's still an issue of #ubuntu...not kernel related :)
[05:29] <AnAnt> oh
[05:29] <BenC> AnAnt: nope
[05:29] <AnAnt> BenC: nope = I won't get splash screen ?
[05:29] <BenC> correct
[05:30] <AnAnt> thanks
[06:25] <Keybuk> BenC: devmode only takes effect for the devices themselves, not for the "devices" file
[06:27] <BenC> Keybuk: right
[06:27] <BenC> devices file is the listmode= option
[06:28] <BenC> there's {dev,bus,list}{uid,gid,mode}
[06:28] <BenC> dev is the files, bus is the subdirs, and list is the "devices" file itself
[06:28] <Keybuk> so we could just symlink it :)
[06:30] <Keybuk> drwxr-xr-x 2 root root  40 2006-10-02 17:29 .usbfs/
[06:30] <Keybuk> drwxr-xr-x 2 root root  80 2006-10-02 08:21 001/
[06:30] <Keybuk> drwxr-xr-x 2 root root  60 2006-10-02 08:21 002/
[06:30] <Keybuk> drwxr-xr-x 2 root root  60 2006-10-02 08:21 003/
[06:30] <Keybuk> lrwxrwxrwx 1 root root  14 2006-10-02 17:30 devices -> .usbfs/devices
[06:30] <Keybuk> ah, sub-mounts don't follow bind mounts
[06:30] <Keybuk> boo
[06:34] <BenC> Keybuk: Ah, true
[06:35] <BenC> link it to /dev/bus/usb/.usbfs/devices directly would work too
[06:35] <Keybuk> link which to?
[06:35] <Keybuk> oh, I see
[10:03] <zul> right later
[10:29] <poptones> hello?
[10:40] <gnomefreak> is there a known issue with nvidia-glx working on -10-386 and not -10-generic?
[10:43] <jldugger> how bad is it that "modprobe toshiba_acpi" segfaults?
[12:05] <gnomefreak> who works with nvidia-glx in here?