=== asac_ is now known as asac
[00:18] <emgent> heya
[03:36] <osmosis> how come this link doesn't show  linux-image-.2.6.24-19-server ?  http://packages.ubuntu.com/hardy/linux-image
[03:37] <crimsun_> because it doesn't pull from hardy-proposed.
[03:38] <osmosis> crimsun_: I dont see that im pulling from  hardy-proposed either in my source.list. But  linux-image-2.6.24-19-server  is the latest.
[03:38] <crimsun_> right, because it's now in hardy-updates
[03:39] <crimsun_> once packages.u.c executes its crontab (on whatever frequency), it will be listed.
[03:39] <osmosis> okay
[03:40] <osmosis> crimsun_: thanks for the clarification
[03:40] <crimsun_> yw
[03:40] <osmosis> crimsun_: is there any other way for me to view the chanelog, besides  packages.ubuntu.com
[03:41] <crimsun_> aptitude changelog linux-image-2.6.24-19-server
[03:41] <osmosis> saweet
[03:42] <crimsun_> you can also view https://launchpad.net/ubuntu/hardy/+source/linux/2.6.24-19.34
[03:42] <lamont> zinc (kernel.ubuntu.com) will be offline starting in about 18 minutes for an upgrade
[03:42] <lamont> officially it'll be down for < 4hours, practically speaking, it should be less than that by quite a bit
=== lamont changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.26-2.6 |  Latest news: Intrepid plans open: https://wiki.ubuntu.com/KernelTeam/UDS/May2008 | Next meeting: June 24, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com | kernel.ubuntu.com dist-upgrade in progress
=== lamont changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.26-2.6 |  Latest news: Intrepid plans open: https://wiki.ubuntu.com/KernelTeam/UDS/May2008 | Next meeting: June 24, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
[05:12] <lamont> kernel.ubuntu.com upgrade is complete.  enjoy.
[06:29] <osmosis> is a daemon required when using speedstep ?
=== dhaval is now known as dhaval_away
=== dhaval_away is now known as dhaval
[09:10] <berzerka> how is the CAP_SYS_RAWIO capability handled in ubuntu? i am developing a userspace USB driver and read with ioctl from /dev/bus/usb/*/*. on my gentoo machine, no problem. on ubuntu i get "Operation not permitted" and the only thing i can imagine is that the RAWIO capability is disabled. on the other hand, it doesn't even work using sudo. any ideas?
[09:21] <pwnguin> capability?
[09:21] <pwnguin> as in ACL, or as in kernel config?
[09:23] <berzerka> i think as in ACL
[09:23] <berzerka> i do raw io to device files, and read in the kernel USB documentation that i need the CAP_SYS_RAWIO capability.
[09:23] <pwnguin> afaik, ubuntu doesn't enable acls by default
[09:23] <pwnguin> check mount
[09:24] <berzerka> i am using the device files provided by udev, not usbfs.
[09:24] <berzerka> so what to look out for?
[09:24] <pwnguin> usually some option like acl
[09:25] <berzerka> udev on /dev type tmpfs (rw,mode=0755)
[09:25] <pwnguin> (im not sure udev has acls)
[09:25] <berzerka> this line? no acl...
[09:25] <pwnguin> the only time i bothered with ACL was when i was trying out a ThinkFinger patch
[09:26] <berzerka> well do i _need_ ACL when i want to do raw device io?
[09:26] <pwnguin> I don't know =(
[09:26] <berzerka> the strange thing is that it also doesn't work when i am superuser
[09:26] <berzerka> and i think i read the uid 0 has all capabilities set.
[09:27] <pwnguin> is it possibile that your feature is a gentoo patch?
[09:27] <berzerka> no, definitely not.
[09:27] <berzerka> i will try on a RHEL system, hang on...
[09:28] <berzerka> (will take ~5 minutes, have to go to the lab..)
[09:45] <berzerka> okay it took a bit longer.
[09:46] <berzerka> (had to fix some things first..)
[09:46] <pwnguin> im still here . might not be any help though
[09:46] <berzerka> result: on RHEL, it doesn't work too.
[09:46] <pwnguin> well I feel better
[09:46] <berzerka> hehe i thought so..
[09:47] <berzerka> hm okay i think i will have to read up on ACL and capabilities in general
[09:47] <berzerka> i will keep you informed..
=== cjwatson_ is now known as cjwatson
=== dhaval is now known as dhaval_away
=== dhaval_away is now known as dhaval
=== dhaval is now known as dhaval_away
=== dhaval_away is now known as dhaval
[15:27] <Kano> hi BenC ,did you see this: http://kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.26-rc8
[15:51] <BenC> Kano: yes, I did see it
[15:51] <Kano> fine
[15:53] <mkrufky> quick question ...  i have a driver in LUM (as of last week) and i've since fixed a number of trivial things, like codingstyle compliance, some small compiler warnings, changed all functions to static and other small things like that.  So I have a quilt series of a few patches that would update the driver in LUM.  Meanwhile, none of these fix actual bugs, so filling out a big report for each of them would be tedious and annoying.  What is the poli
[15:54] <mkrufky> er, bug report, i meant
[15:54] <BenC> mkrufky: if it doesn't fix bugs, then we generally don't want it in stable
[15:54] <rtg> BenC: its a new driver.
[15:54] <mkrufky> meanwhile, when real bug reports DO come in, i will fix them in my dev tree, which will end up merging to 2.6.27
[15:55] <mkrufky> and i will not want to backport each change to the older version
[15:55] <BenC> rtg: has it been released yet?
[15:55] <mkrufky> (im talking about sms1xxx)
[15:55] <mkrufky> sms1xxx is in LUM, but it is not in _any_ upstream kernel tree
[15:55] <mkrufky> its only in my dev tree on linuxtv.org
[15:55] <rtg> mkrufky: just send the updates on the kernel team mailling list. once its actually been uploaded, then we'll have to go through the SRU process.
[15:55] <mkrufky> i had to push it to LUM because Dell needed it for testing
[15:56] <rtg> BenC: sms1xxx is in LUM git, but not yet uploaded.
[15:56] <mkrufky> "once its actually been uploaded"  <-- what are you refering to?
[15:56] <mkrufky> oh, you mean released in a deb package?
[15:57] <rtg> mkrufky: right. once it hits the -proposed/-updates repo its gonna be subject to SRU policy.
[15:58] <mkrufky> so, does that mean that it is not subject to that policy yet?  
[15:58] <rtg> mkrufky: correct
[15:58] <mkrufky> ...in other words, am i best off just sending in a "sync to dev tree" patch now before it is uploaded?
[15:58] <rtg> mkrufky: yes
[15:59] <mkrufky> ok, in that case i have some merging to do ... bbiab :-)
[15:59] <BenC> mkrufky, rtg: Ok, if it's not uploaded, then updating it is ok
[15:59] <BenC> well, s/ok/fine by me/ :)
[15:59] <mkrufky> thanks
[15:59] <rtg> mkrufky: I won't upload LUM before about July 7.
[16:00] <mkrufky> ah, i didnt realize there was that much lead time... ok, cool
[16:00] <rtg> mkrufky: the point release is scheduled for Jult 3, and I'm off rafting through the 6th.
[16:01] <mkrufky> OK
[16:01] <mkrufky> also, looks like i will end up getting all the hvr950q performance tweaks into 2.6.26, so we will most likely not need it in intrepid LUM at all
[16:04] <BenC> mkrufky: nice
[16:20] <BenC> Ok, I stopped being a lazy bastard and rebased to -rc8 and pushed
[16:21] <Kano> nice boy
[16:22] <Kano> and you disabled XEN, nice for nvidia
=== mkrufky is now known as Guest59299
=== mkrufk1 is now known as mkrufky
[16:54] <zul> BenC: fyi redhat pushed their xen pvops/dom0 tree to 2.6.26 as well 
[16:59] <exodos> In some situations it is needed to run 32bit userland with 64bit kernel (we're running hardy under xen like this). Now you have to download deb packages and manually issue dpkg -i --force-architecture *.deb. In debian, in 32bit repositories they have package called linux-image-2.6-amd64, which is installing the latest 64bit kernel. Would it be possible to add similar funcionality to ubuntu kernel? 
[16:59] <mjg59> Only if you want certain things to break in bizarre ways
[17:01] <exodos> mjg59: what do you mean?
[17:02] <mjg59> CPUs in 64-bit mode aren't perfectly compatible with CPUs in 32-bit mode
[17:03] <exodos> mjg59: can you point me to more infos about this issue?
[17:03] <mjg59> exodos: The prime issue is that vm86 mode doesn't exist in 64-bit mode. That's probably not a huge problem
[17:03] <mjg59> exodos: The other one (which is a bug, but not always trivial to track down) is that ioctls need to be thunked from 32-bit to 64-bit
[17:04] <mkrufky> some (but not all) provide a compat_ioctl32 wrapper to handle that compat
[17:04] <mkrufky> oops, some but not all kernel subsystems, that is
[17:05] <BenC> usb printer I think is the main one that doesn't
[17:05] <BenC> but that may have changed recently
[17:07] <exodos> we're running it under xen, so now real hardware there...
[17:07] <BenC> exodos: but if I make a 64-bit kernel available to 32-bit userland, people wont use it just under xen :)
[17:08] <BenC> exodos: what purpose do you have of running 32-bit userland under a 64-bit kernel?
[17:08] <exodos> I would say its their problem
[17:08] <exodos> we have to use 64bit kernel with latest xen
[17:08] <exodos> 32bit kernels are just simply not working with it
[17:09] <exodos> and 32bit domU is used as a terminal server (LTSP)
[17:09] <BenC> well, you have an easy work around, so I say go with it :)
[17:10] <exodos> you mean with wget and dpkg ?
[17:10] <BenC> exodos: it would be pretty simple to automate dpkg-deb to convert the deb to amd64, and create a local repo to add to sources.list
[17:11] <BenC> some shell scripting from a cron job would ease your burden
[17:12] <BenC> which, to put it bluntly, is acceptable to me compared to the burden we would get from users trying to run a 64-bit kernel in 32-bit userland :)
[17:14] <exodos> ok, so to summarize: i shouldn't expect mentioned funcionality in interpid. Am I correct?
[17:14] <BenC> that's correct, but then maybe intrepid's 32-bit xen kernel will work better for you
[17:27] <exodos> thx for help, bye
[18:31] <kirkland> rtg: I'm running your linux - 2.6.24-20.35ubuntu kernel, but it doesn't appear to fix the ecryptfs issue
[18:32] <kirkland> rtg: can you confirm that that kernel has the cherry picked fix I identified?
[18:32] <kirkland> rtg: 2.6.24-20.35ubuntu3, to be precise
[18:38] <rtg> kirkland: I am ' dget http://ppa.launchpad.net/timg-tpi/ubuntu/pool/main/l/linux/linux_2.6.24-20.35ubuntu3.dsc' which has the last commit SHA1 noted in the changelog entry. However, I believe it has the ecryptfs commit: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=6f137e40d6d2456fd23b0f2f342eabd44c50656a
[18:39] <rtg> I'll know in a couple of minutes.
[18:41] <rtg> kirkland: last commit in that upload was 12c0aa7d1af0468d5c8941ee30056bc3e74c2c07, so the ecryptfs commit is definitely there.
[18:41] <kirkland> rtg: :-/
[18:41] <kirkland> rtg: bummer
[18:42] <kirkland> rtg: what kind of shape is the 2.6.26 kernel for intrepid it?  is it ready to run/boot?
[18:42] <rtg> kirkland: yep -  I think BenC has been running it for awhile.
[18:42] <kirkland> rtg: what about in a KVM?
[18:43] <kirkland> rtg: i've had no success running intrepid + 2.6.26 in a kvm
[18:43] <rtg> kirkland: likely, but I couldn't say for sure.
[18:54] <voicu> Hi, i have the kernel linux-2.6.24-19-generic and i'm trying to install vmware tools. they need to be compiled and require the headers
[18:54] <voicu> when configuring starts it says that the files in /usr/src/linux-headers-2.6.24-19-generic/include don't match the kernel
[18:55] <voicu> any ideas besides vmware's fault?
[18:55] <voicu> uh, is my question offtopic? :D
[18:56] <rtg> voicu: I think vmware supplies the binaries, so they should be providing an update any day now.
[18:56] <voicu> so they are in the repositories or something?
[18:57] <rtg> voicu: right, one of the partner repositories iirc.
[18:59] <voicu> rtg: what should i look for? xserver-xorg-video-vmware?
[18:59] <voicu> That's already installed
[18:59] <voicu> But the system doesn't work as fast as it used to when I had the compiled vmware-tools
[19:00] <rtg> voicu: dunno, I've not used vmware in a couple of years.
[19:00] <voicu> rtg: anyway, any ideas on the kernel version thing?
[19:00] <rtg> I have to do pretty much all of my work on bare metal.
[19:00] <voicu> I might need to compile stuff later too
[19:02] <rtg> voicu: I notified the right person at Canonical about the ABI change a couple of weeks ago (who should have contacted vmware). I guess you'll have to wait until vmware produces an ABI compatible package.
[19:03] <voicu> aham...
[19:03] <voicu> any way to change that? can't i put something in include/linux/version.h?
[19:03] <voicu> *quickfix
[19:04] <rtg> voicu: I have no idea. feel free to go exploring.
[19:04] <voicu> ok then, thanks for the info
=== mkrufk1 is now known as mkrufky
[21:50] <BenC> rtg: know anything about the heci driver in lum?
[21:51] <rtg> uh, what is heci?
[21:53] <rtg> BenC: its an Intel driver, is it already upstream?
[21:54] <rtg> guess not.
[21:55] <BenC> Doesn't look like it
[21:55] <BenC> it's the AMT_HECI
[21:58] <rtg> BenC: something related to http://www.intel.com/technology/platform-technology/intel-amt/ ?
[22:11] <BenC> yeah