[02:31] <zeroprog> hey guys....im having a problem...i read the first 4 chapters of allesandro rubini driver book and still have no clue how to use what ive learned  or how to apply it to my device...is there a simple source in the kernel that i may be able to decipher
[06:26] <samir_> hello there, i just wanna downgrade my kernel to 2.6.26*
[06:26] <samir_> so i just have to install linux-image-2.6.26* ??
[06:31] <anubhav> samir_: that should work
[06:37] <samir_> anubhav : plus, that will install 2.6.26 modules for me? that's what i'm interested in
[06:40] <anubhav> samir_: yes 
[06:41] <anubhav> samir_: but i am not sure if .26 is present in the ubuntu repository
[06:43] <samir_> anubhav maybe in packages.ubuntu.com
[11:03] <apw> NCommander, am looking at the ports issue
[11:13] <apw> bah all the configs are in the toilet
[11:13] <apw> TheMuso, you about?
[11:39] <StevenK> apw: Given the time, TheMuso is probably dinner-ing
[11:40] <apw> yeah, i have a handle on the mess now thankfully
[11:42] <StevenK> apw: This will be another .30?
[11:42] <StevenK> apw: You should also be aware that i386 failed to upload (there's a new state for you) due to version number fun
[11:43] <apw> is that the linux-doc breakage?
[11:43] <StevenK> Yup
[11:54] <apw> yeah can't fix that until rtg gets in as he has the tree, but we are aware
[14:13] <apw> rtg the GEM/PAE changes we were testing seem good, and indeed airlied has merged them already.  in theory that makes 2.6.31-rc1 capable of KMS on PAE too
[14:14] <rtg> apw: I have a test system. where have you stashed test kernels? your PPA?
[14:15] <apw> yeah in a ppa .... https://edge.launchpad.net/~apw/+archive/red
[14:15] <apw> (gah edge is slow today)
[14:48] <apw> rtg i note that the effect of pulling all the ports kernels back into our kernel has slipped the 386 kernel over to non-ports status
[15:19] <rtg> mdz: if I respun linux-meta and uploaded linux-meta_2.6.30.9.9 (with your linux-doc patch), then the existing linux-doc package would eventually get reaped, right? That should clear up any conflicts in case there is another 2.6.30 kernel upload (which I think we should do)
[15:21] <mdz> rtg: did you see my message to kernel-team@ from yesterday?  that's #2 out of the 3 options I suggested for how to fix it.  the trouble is that the old linux-doc package wouldn't get reaped right away, and might require manual Launchpad hackery, so Colin was (understandably) not thrilled with that idea
[15:23] <rtg> mdz: why would it need manual intervention?
[15:23] <mdz> rtg: when a source package stops building a binary package, Launchpad doesn't just delete the old one.  it hangs around for a grace period
[15:24] <mdz> "didn't get built" has different semantics from "was explicitly removed"
[15:24] <mdz> rtg: this is because it's hard for LP to tell the difference
[15:24] <mdz> "maybe this source package doesn't built that binary package anymore, or maybe it just hasn't built yet"
[15:24] <mdz> s/built/build/
[15:25] <rtg> mdz: what is the grace period? a couple days?
[15:25] <mdz> rtg: I think it's on the order of days, but I can't say for sure. cprov or bigjools or somebody could tell for sure
[15:25] <soren> Really? They get automatically deleted eventually?
[15:26] <soren> I thought they always had to be explicitly removed by an archive admin.
[15:30] <rtg> mdz: how about if I just restore the kernel package naming convention for linux-doc for now, then deal with the new linux-doc package name when we update to 2.6.31 next week?  In the meantime, I'll respin linux-meta and let the reaper do its thing.
[15:31] <mdz> rtg: fine with me
[15:32] <mdz> rtg: I just followed up to the list with a suggestion for the upload order
[15:32] <rtg> mdz: cool, I'd really like to get the new i386 pae flavour propagated.
[15:41]  * Keybuk is having strange behaviour today
[15:41] <Keybuk> nc -q0 ip port | dd of=/dev/sda bs=1M
[15:42] <Keybuk> just hangs eventually
[15:42] <mdz> Keybuk: on the network side or the sda side?
[15:42] <Keybuk> sda side
[15:51] <Keybuk> seems to be hung deep inside the io scheduler
[15:54] <rtg> apw: care to review ubuntu-karmic-meta.git for me before I upload it?
[15:55]  * apw looks
[15:56] <apw> rtg, i see 9.9 at the tip?
[15:56] <rtg> apw: yes
[15:57] <Keybuk> wow
[15:57] <Keybuk> it really looks like it screwed the scheduler
[15:58] <apw> so this is just the meta change for mdz's change
[15:59] <rtg> apw: correct. next week you'll have to bumop the ABI when you do 2.6.31
[16:02] <rtg> apw: now, back to your comment about 386 becoming a non-ports package. Isn't that a function of the archive admin overrides?
[16:02] <apw> so the plan is to drop it from meta, but not add it to the kernel yet
[16:02] <rtg> correct
[16:02] <apw> then when its cleared the archive, add it back into the kernel?  with the next abi update
[16:02] <rtg> correct
[16:03] <apw> sounds reasonable, and appears ok to me
[16:03] <apw> as for the ports comment i was more referring to the fact it ends up being updated
[16:03] <apw> config wise with the other x86 flavours
[16:03] <rtg> oh
[16:04] <apw> as the ports split we end up with is basically by architecture
[16:04] <apw> we'd need to do a bit more work to make the different
[16:04] <apw> thought perhaps thats not a negative thing overall
[16:05] <apw> as there is probabally some benefit to us at least updating the configs for distro and ports at the saem time
[16:05] <apw> always taking defaults for ports, and reporting them to the ports maintainers
[16:05] <apw> else they will always fail to build
[16:05] <apw> with a dirty config, if we don't
[16:06] <rtg> after looking at your 'family' [atch, its not clear that 386 would build at all. there is no '386' flavour.
[16:07] <apw> hmmm ... so have i lost it or did the ports fixes lose it?
[16:08] <rtg> apw: methinks the ports fixes lost it, [PATCH 1/2] UBUNTU: split out the ports configs into their own family
[16:10] <apw> hmm but the family changes are just at the top level
[16:10] <apw> by which i mean the arch level
[16:12] <apw> there is no config.flavour.386 at all in this origina commit:
[16:12] <apw>     UBUNTU: [Config] ports - Add configuration files for ports architectures
[16:12] <apw> so i think we never brought it over
[16:13] <rtg> apw: that is the conclusion I was just coming to as well.
[16:13] <apw> want me to sort that out?
[16:14] <apw> i suspect it just got forgotten
[16:14] <apw> inserting a new complete config into the split configs is an interesting game, which i just did for the ports ones
[16:15] <rtg> apw: yeah, go ahead and sort it out. I've just pushed one more commit (reverting the linux-doc patch)
[16:18] <rtg> apw: can you make 386 it's own arch?
[16:18] <apw> it does appear the kernel arches are not the same as build arches right?
[16:19] <rtg> apw: hmm, I think 386 gets built on an i386 chroot
[16:19] <apw> will have a play
[16:26] <apw> rtg what we care about is keeping 386 merging with ports configs 
[16:26] <apw> otherwise its fine?
[16:28] <rtg> apw: I dunno if its fine, but yeah, 386 should be part of the ports family of configs.
[16:30] <mvo> hello! I noticed that there is a linux-image-debug-`uname -r` package on ddebs.ubuntu.com - but it appears to be not part of the Packages.gz file - is that intentional (the deb is pretty big)
[16:31] <rtg> mvo: I believe so. It keeps the mirrors from picking it up.
[16:32] <mvo> ok, thanks 
[16:32] <rtg> apw: the original patch set from Luke simply didn't contain a 386 config
[16:32] <apw> yeah or indeed anything about 386 at all
[16:33] <rtg> apw: ok, I'd say just drop him a note about it and lets move on with other work
[16:34] <apw> can do that, i feel the 386 ports port is the one that is worth a tiny bit of our attention just cause its an x86.  but you are likely sensible there
[16:36] <apw> i t
[16:37] <apw> rtg ok one question, if its a flavour of x86 and it gets built on i386, i suspect that will make it part of the common i386 build and therefore that one can have greater dammage to our build process than the other builds
[16:37] <rtg> apw: it could, but I'm gonna let Luke figure it out
[16:37] <apw> ok
[16:43] <apw> rtg ok, i've emailed him and copied u-k-t
[16:49] <rtg> apw: so, to test the KMS/PAE combination with your test kernels, I want https://edge.launchpad.net/~apw/+archive/red/+files/linux-image-2.6.30-9-server_2.6.30-9.10kms9_i386.deb, right?
[16:49] <apw> rtg yeah thats the one that should exhibit it
[16:50] <apw> i've personally tested some of the other combinations, which still work at least but would never have been affected
[16:51] <rtg> apw: I take it these are upstream cherry-picks?
[16:56] <apw> rtg, the patches on that kernel, one was direct from lkml from airlied and the other was mine.  since the equivalent of both has merged into what will be .31-rc1
[16:56] <apw> i think dave got sick of them and just merged them
[16:57] <rtg> apw: well, can we easily cherry-pick from Linus tree, or should we just ignore the PAE problem until 2.6.31 ?
[16:58] <apw> the only urgency is if we are pushing people to -pae at all during upgrades, if not then there is none
[16:59] <apw> i saw the whole testing of gem and pae and these two patches as a response to the 'blocker' if we were pushing people to -pae by default.  i cannot recall the outcome, or indeed if there was an outcome without this infrmation
[16:59] <rtg> apw: fresh installs will have the problem if > 4GB RAM. Otherwise, upgrades ought to be OK.
[16:59] <apw> so i think ... they can sensibly fall into the 'will wait for upstream to have them' bucket to my eye
[17:00] <rtg> apw: works for me. I'm gonna package and upload then.
[17:00] <apw> ok
[17:03] <apw> that should get us at least an upload with the new flavours me thinks
[17:03] <rtg> thats my goal
[17:08] <Keybuk> rtg: can I ask a question?
[17:09] <rtg> Keybuk: always
[17:09] <rtg> whether I can answer...
[17:09] <Keybuk> rtg: I have an image file
[17:09] <Keybuk> and I'm trying to write it to the disk
[17:09] <Keybuk> but every time, the kernel hangs inside the I/O scheduler
[17:09] <Keybuk> is there a simple way to change that so I can use a different I/O scheduler
[17:09] <Keybuk> (and worry about filing the bug later :p)
[17:10] <rtg> Keybuk: yeah, there is a way to change the I/O scheduler dynamically. just need to remember how.
[17:10] <Keybuk> rtg: what's a good "just do it" I/O scheduler?
[17:10] <rtg> deadline?
[17:13] <rtg> Keybuk: find /sys|grep sched
[17:13] <rtg> cat /sys/devices/pci0000:00/0000:00:1f.1/host0/target0:0:0/0:0:0:0/block/sda/queue/scheduler
[17:13] <rtg> This is a server install, so the default is deadline.
[17:13] <Keybuk> ok
[17:13] <Keybuk> great
[17:13]  * Keybuk tries that
[17:14] <rtg> Keybuk: try noop also, which is the simplest
[17:14] <rtg> IIRC
[17:19] <noptys> anyone familiar with recent changes to the e1000 driver?  It seems that in gutsy (2.6.22-14-generic), the 82573 wouldn't support jumbo frames, but with jaunty (2.6.28-11-generic), it lets you enable jumbo frames, but gets swapper allocation failures under network load
[17:22] <rtg> noptys: perhaps you should email Jesse Brandenburg about that
[17:22] <noptys> can do
[17:29] <Keybuk> rtg: the deadline scheduler worked
[17:29] <rtg> Keybuk: is Ingo the I/O scheduler dude?
[17:32] <rtg> Keybuk: maybe Jens Axboe <axboe@kernel.dk> (block/cfq-iosched.c)
[17:32] <apw> ingo is cpu scheduler to my mind
[17:33] <rtg> apw: Jens did the CFQ scheduler
[17:34] <apw> rtg he is also the maintainer of BLOCK in general, so a good starting point
[20:27] <wjblack> Hello!
[20:29] <wjblack> So I recently backported the 2.6.30 version of the r8169 driver to 2.6.28 and am wondering how to go about packaging it for e.g. a PPA.  The actual "how to put it in a package" details aside, I want to make sure I don't step on anyone's toes.  Should I just call it "r8169-backport-driver-2.6.28....*" or similar?
[20:30] <wjblack> Am I going about this the wrong way entirely?
[20:31] <rtg> wjblack: is it a DKMS based package?
[20:31] <wjblack> Nope.  Modified vanilla kernel.org.
[20:32] <wjblack> Literally, it's a patch to the 2.6.30 r8169.c that allows it to compile/run on 2.6.28
[20:32] <wjblack> (the 2.6.30 version has a slightly different api but a fix for a rather nasty MSI bug)
[20:33] <rtg> wjblack: the best way to package it so that you don't have to deal with ABI dependencies is to use DKMS
[20:34] <wjblack> Hmm.  Okie-dokie.  Is there an Ubuntuish way to do that, or do I do generic dkms stuff?
[20:34] <wjblack> (never used DKMS before, obviously ;-) )
[20:35] <rtg> wjblack: there is a bit of a learning curve, but its not too bad once you grok things. here are some good example driver packages, e.g., bcmwl.
[20:35] <rtg> s/here/there/
[20:35] <wjblack> Aah, so the bcmwl package that's available via apt-get somewhere uses dkms?  Excellent.
[20:35]  * wjblack learns best by example ;-)
[20:36] <rtg> wjblack: yes, the maintainer is Alberto Milone (tseliot)
[20:36] <rtg> wjblack: in Karmic its called bcmwl-kernel-source
[20:37] <wjblack> I'm thinking this particular backport will have an effective lifespan of, er, rather short since >=2.6.30 should be in the main distro at some point...
[20:37] <wjblack> Right on.  I'll give it a looksee.  Thanks!
[20:37] <rtg> wjblack: 2.6.30 is in the Karmic archive right now, 2.6.31-rc1 soonish
[20:39] <wjblack> Hmm.  Still might be nice to have a PPA for Jaunty.  I'll check out this rabbit hole and see if I can handle its depth. ;-)
[21:29] <bullgard4> Update Manager differentiates 'distriution updates' and 'security updates'. What is the difference? Does every single DE program package have a flag for that?
[21:30] <bullgard4> s/DE/DEB/
[21:30] <_ruben> not every bugfix relates to security issues
[21:32] <bullgard4> _ruben: Yes. --  So it depends solely on the maintainer's judgement?
[21:39] <zeroprog> hey guys im a little confused as to what a module can do other than a device driver(which i cant figure out either)...could somebody explain to me some of the more useful modules
[21:43] <johanbr> a module can do pretty much anything
[21:43] <johanbr> think of it as a plugin for the kernel
[21:50] <zeroprog> johanbr: i get that but....i dunno im having trouble understanding what modules do what....like i want to look at specific device drivers(webcam, audio, anything i can find) but i dont know which source does what 
[21:50] <zeroprog> in the module programming guide they said we can write a module that says "Hey that tickles" everytime i delete something....but how would i do that you know what i mean?
[21:51] <johanbr> look at the kernel source for sth simple
[21:51] <zeroprog> ok
[21:53] <zeroprog> do you know where thats located?
[23:29] <dtchen> zeroprog: www.kernel.org, git.kernel.org, kernelnewbies.org, kernel.ubuntu.com/git
[23:29] <dtchen> zeroprog: see also #kernelnewbies on irc.oftc.net