[01:32] <nolan> I added the kernel PPA to my sources, but there doesn't seem to be any kernel available from it.  Is that PPA stale?
[04:12] <strix> apologies if this is OT, but: how do I rebuild a kernel as distributed by ubuntu? (more accurately, that generates the same uname -r )?
[04:12] <strix> and is there any difference between getting sources with 'aptitude install source kernel-image' and 'aptitude install kernel-source'?
[04:13] <strix> otherwise, i've found the docs that describe how to build with fakeroot make-kpkg etc
[08:48] <Kano> hi, anybody awake?
[08:52] <Kano> when can i expect that dvb will be readded to 2.6.26?
[13:40] <Kano> hi rtg 
[13:41] <Kano> some problems with new kernel
[13:41] <rtg> Kano: do tell.
[13:41] <Kano> first of all you disabled dvb
[13:42] <Kano> also you have lots of new alsa drivers  - at least one of it does interfere with my dvb cards
[13:42] <Kano> you can a) disable it or b) blacklist it, but you can not leave it as is
[13:42] <rtg> Kano: which kernel are we talking about? Intrepid?
[13:42] <Kano> yes
[13:43] <Kano> CONFIG_SND_AW2=m
[13:43] <Kano> disable or
[13:43] <rtg> Kano: you'll have to talk to Ben. I'm still working on Hardy
[13:43] <Kano> blacklist snd-aw2
[13:43] <Kano> but i saw your commit when you disabled v4l, then somebody partly enabled v4l and forgot to enable dvb
[13:44] <Kano> UBUNTU: Disable V4L until the build issues get ironed out. Ignore: yes
[13:44] <Kano> your commit
[13:44] <Kano> and the result was that it was forgotten to reenable
[13:45] <Kano> # CONFIG_DVB_CORE is not set
[13:45] <rtg> Kano: perhaps, but it was awhile ago. How about a synopsis of your comments in an email to the kernel team mailing list?
[13:45] <Kano> next thing is: do you really need to enable xen for default kernel
[13:46] <Kano> i see currently no working patch for nvidia 173.xx which would allow the use of it
[13:46] <Kano> without xen you can compile 173.x
[13:47] <Kano> i modded the kernel config on the fly, i enabled highmem64gb -> pae enabled + disabled xen
[13:47] <Kano> then at least nvidia works
[13:48] <Kano> pae i enabled because mem is relatively cheap and lots of users have 4gb and more
[13:48] <Kano> but that change is optional
[13:48] <Kano> also do you drop the way with the lum package? as you added now dmraid4-5 directly?
[13:49] <Kano> if you would rename the module to dmraid45 it would be even better
[13:49] <rtg> Kano: did you miss the part about email to the kernel team mailing list? You are wasting your time with me. I'm _not_ working on Intrepid.
[13:49] <Kano> why do you commit changes then?
[13:50] <Kano> the dmraid rename could be done in lum too
[13:50] <Kano> i think there was a modded version already, dont know where however
[13:53] <Kano> rtg: could you give me adress where to send mail?
[13:54] <rtg> kano: kernel-team@lists.ubuntu.com
[13:54] <Kano> ok
[14:03] <Kano> so mail sent
[14:09] <Kano> hmm forgot one thing, well the rename of dmraid4-5 but maybe talk about that with the one who did the hotfix, dont remember who it waas
[14:52] <BenC> Good morning everyone
[14:55] <rtg> BenC: Kano has some suggestions for you on the kernel team mailing list.
[15:00] <BenC> rtg: We need to talk about the 4G vs. 64G issue
[15:00] <BenC> there's a good reason I disabled it (it prevents other things from working)
[15:00] <rtg> BenC: not only that, but it causes performce issue, doesn't it?
[15:01] <BenC> yeah
[15:01] <BenC> lots of overhead for the few people that use want > 4G + 32-bit kernel
[15:01] <BenC> I'm of the opinion we take a strong stance for this people to use 64-bit kernel
[15:02]  * BenC needs coffee
[15:02] <rtg> BenC: is there any reason for them not to use the 64 bit kernel?
[15:02] <BenC> just woke up, been sick since I got back from london
[15:02] <rtg> bummer.
[15:02] <BenC> rtg: I'm using it, and I have found no problems
[15:02] <BenC> in fact, I would say it's a little snappier than 32-bit on the same machine
[15:03] <rtg> yeah, I have both 32 and 64 on the same platforms with no noticeable differences, but that entirely subjective.
[15:04] <mjg59> 64-bit kernel with 32-bit userland breaks various things
[15:04] <BenC> mjg59: We don't want to give them 32-bit userland :)
[15:04] <mjg59> Yeah, if you can push them entirely to 64-bit then that works better
[15:04] <BenC> but if they need 32-bit userland for some legacy/proprietary reason, it can work
[15:05] <BenC> e.g. adobe-flash player, or some codecs
[15:05] <rtg> all that stuff seems to work fine for me.
[15:05] <rtg> granted, i'm not an intensive user of flash et al.
[15:07] <cjwatson> was it intentional that the ide-modules udeb has been dropped in the 2.6.26 packages?
[15:08] <cjwatson> also, is linux-ubuntu-modules likely to arrive soon for 2.6.26? I'd like to start building d-i against .26
[15:08] <rtg> cjlum has been folded back into the kernel package.
[15:08] <rtg> cjwatson: ^^
[15:09] <maks_> cjwatson: from watching BenC is making a big monolithic exploding package
[15:09] <rtg> maks_: perhaps, but it solves some ABI skew issues
[15:09] <cjwatson> rtg: in that case, there seems to be no ubuntu-modules udeb now
[15:09] <cjwatson> so that has intentionally gone away, I guess?
[15:09] <cjwatson> I suppose that makes sense actually
[15:09] <maks_> rtg: i had a post for you last day
[15:10] <rtg> cjwatson: dunno. BenC has been working hard on it this last week or so.
[15:10] <maks_> hmm no longer in backlog
[15:10] <rtg> maks_: you mean the patches sent to akpm?
[15:11] <maks_> irclogs/OPN/#ubuntu-kernel.2008-06-13.log:13:41 <maks_> rtg f448b9a70cda0ed9878d
[15:11] <maks_> b485de30363f9c9db6e1 is a dup
[15:11] <maks_> 13:41 <maks_> you'll find the same entry below in blacklist with proper desc
[15:12] <maks_> 13:47 <maks_>  speaking of ubuntu hardy tree, as you might have guessed ;)
[15:12] <BenC> we only had 64G enabled on i386 server anyway
[15:12] <BenC> in which case, I even more strongly suggest people go 64-bit
[15:14] <cjwatson> hmm. 2.6.26-1 d-i boots but without keyboard input
[15:14] <BenC> 64G disables DMA_ENGINE, which server people would be pissed at
[15:14] <BenC> cjwatson: hmm...USB keyboard?
[15:14] <cjwatson> BenC: kvm
[15:15] <rtg> maks_: I cannot figure out what you're talking about? perhaps a bit more context. my memory seems bit porous this morning.
[15:15] <BenC> cjwatson: so atkbd...that should be all good
[15:15] <cjwatson> atkbd doesn't seem to be modular, so shouldn't be a udeb issue
[15:15] <BenC> rtg: ur not supposed to have rum in your coffee on weekdays
[15:16] <rtg> BenC: I know you've you've told me that before, but I just keep forgetting.
[15:16] <BenC> cjwatson: right...anyway to test 2.6.26-1 under kvm (not d-i)?
[15:16] <cjwatson> err. you're the kernel specialist ;-)
[15:17] <BenC> hehe
[15:17] <cjwatson> I can give you the d-i .iso I have if that would help
[15:17] <BenC> cjwatson: I was hoping you had an existing rig...requires setup for me
[15:17] <BenC> cjwatson: yeah, that would be a good start, thanks
[15:17] <cjwatson> I'm just running 'kvm -cdrom dest/netboot/mini.iso -boot d'
[15:17] <BenC> cjwatson: what's the status on alpha-1?
[15:17] <maks_> rtg: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commitdiff;h=c1712ff3d8002a5070dd13c8fb6d7b77c9bd2516;hp=f448b9a70cda0ed9878db485de30363f9c9db6e1
[15:18] <cjwatson> dunno if you'll be able to do much without keyboard input though ...
[15:18] <BenC> cjwatson: is this holding it up?
[15:18] <maks_> that adds a dup entry rtg
[15:18] <maks_> just look at current drivers/bluetooth/hci_usb.c
[15:18] <cjwatson> BenC: critical path = me, but I could release with 2.6.24 if need be - would rather not if possible
[15:18] <rtg> maks_: now I understand.
[15:18] <cjwatson> this isn't the only thing holding it up, but getting the installer out of the way is definitely on the list
[15:19] <maks_> rtg: sorry for mixing hardy and intrepid
[15:19] <maks_> you release to often :P
[15:19] <BenC> cjwatson: we are still missing a few bits for 2.6.26 to be good on livecd...(firmware in lrm-common, etc, linux-meta)
[15:19] <rtg> maks_: many folks think thats an advantage :) release frequently and often.
[15:20] <BenC> maks_: yeah, my debian background really made it hard for me to get used to frequent releases too :)
[15:20] <cjwatson> BenC: just to give us an idea, how far off are these?
[15:21] <cjwatson> I wouldn't necessarily mind releasing with 2.6.26 just for the installer on alternate/server CDs; it can usually cope with installing a different kernel version
[15:21] <cjwatson> though the effects can sometimes be a little weird so that's not entirely desirable
[15:21] <cjwatson> but I figure the more early kernel testing the better
[15:21] <cjwatson> BenC: http://people.ubuntu.com/~cjwatson/tmp/mini.iso
[15:21] <BenC> cjwatson: I can get lrm together today
[15:22] <BenC> linux-meta is ready, just needs upload
[15:22] <cjwatson> BenC: it's a stock kernel and you can unpack and repack the initrd if need be; udebs are irrelevant for this particular purpose
[15:22] <cjwatson> the initramfs is built with 'find . | cpio --quiet -o -H newc | gzip -9c'
[15:22] <BenC> cjwatson: thanks, downloading
[15:23] <rtg> maks_: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=b8e6e9b08265826ec89bf97f30bb10db78cf9663
[15:24] <BenC> cjwatson: done
[15:25] <maks_> rtg: thanks makes it easier to watch out for patches on your next rebase :)
[15:25] <rtg> maks_: yep - thanks for the note.
[15:25] <cjwatson> bizarrely, if I boot without 'quiet', it hangs, but if I boot with 'quiet', it gets as far as the first screen of d-i
[15:26] <rtg> maks_: I'm always happy to dump SAUCE patches.
[15:26] <cjwatson> (last thing on the screen is "Freeing unused kernel memory)
[15:26] <cjwatson> "
[15:27] <cjwatson> oh, and if I use BOOT_DEBUG=3 then I have keyboard input
[15:27] <cjwatson> maybe it's a d-i problem after all ...
[15:29] <cjwatson> keyboard input only for a while, though, then it hangs. This feels like a lockup more than lack of keyboard input, actually
[15:29] <cjwatson> it's unreliable, but on one boot I got "BUG: soft lockup - CPU#0 stuck for 184s! [events/0:6]"
[15:30] <BenC> cjwatson: ah, sounds more like a hang than lack of keyboard to me too
[15:30] <cjwatson> anything I can pass on the kernel command line to make it spit out lots and lots of output or something?
[15:31] <BenC> cjwatson: try with -nokvm(?)
[15:31] <cjwatson> so just qemu basically?
[15:31] <BenC> So as to exclude it being an lguest/kvm interaction
[15:31] <BenC> yeah
[15:31] <cjwatson> Ubuntu does not support running KVM without hardware acceleration. Sorry.
[15:31] <BenC> I have the iso now, so I'll start checking it out
[15:31] <cjwatson> I think I need to run qemu explicitly
[15:33] <cjwatson> BenC: yes, it seems much happier with qemu
[15:34] <cjwatson> I've got far enough to run into the bits I left out of the installer to make it buildable
[15:42] <BenC> cjwatson: There's also noreplace-paravirt kernel param that might make it work under kvm (but without paravirt)
[15:44] <cjwatson> BenC: still hangs after a short while
[15:45] <cjwatson> (qemu's faster in that case anyway, I think :-) )
[15:50] <BenC> cking: Can you add a BOM file for ubuntu/dm-loop/ please?
[15:50] <BenC> cking: there's one in the other directories if you need a template
[15:51] <cking> BenC: Will do.
[15:51] <BenC> thanks
[15:53] <BenC> cjwatson: they should pimp that as a feature :)
[15:54] <BenC> cking: And please install the git hooks from build scripts :)
[15:54] <BenC> cking: config changes should be a separate commit from the code
[15:54] <BenC> just to make it easier to separate things out, and do reverts independent of each other
[15:55] <cking> BenC: OK apologies for no understanding that. Will do in future.
[15:56] <BenC> cking: I'm not sure it's documented, so not your fault
[15:57] <cking> BenC: call it organic documentation
[15:57] <cking> ..its in someone's head
[15:57] <cjwatson> BenC: I think it's a bit of both actually. It's slower at device detection but faster at screen refreshes
[16:06] <BenC> cjwatson: you should be good enough with d-i not to need a head to do the install :)
[16:59] <asac> rtg_: iwl4965 from your PPA works great so far (scan_capa > 0 \o/)
[16:59] <rtg_> asac: you get the one from this morning? Its based on 2.6.26-rc6
[17:00] <asac> rtg_: err ;) ... not sure. i just added your hardy PPA and upgraded
[17:00] <BenC> Checking ABI for generic...check FAILED (nice one Tonto, go get the Lone Ranger)
[17:00]  * BenC marks intrepid for an ABI bump
[17:01] <asac> at least i hae scan_capa now and NM 0.7 without workarounds connects quick
[17:02] <rtg_> asac: great. its the absolute bleeding edge wireless support.
[17:03] <asac> rtg_: is there anything we can do for hardy?
[17:03] <asac> i think the workarounds that more or less works well for iwl4965 dont help that good for iwl39xx
[17:03] <asac> at least i saw ken not being able to connect at all at UDS ;)
[17:04] <rtg_> asac: I'm confused. the LBM package you are loading _is_ for hardy.
[17:04] <asac> rtg_: yeah it is. buts its from PPA :)
[17:04] <rtg_> asac: oh, I see. I'm waiting to upload until after the point release.
[17:04] <asac> rtg_: or is that ment to go to -proposed at some point?
[17:05] <rtg_> asac: it is, but Steve asked that I wait until the point release CDs are pressed.
[17:06] <asac> kk
[17:09] <asac> rtg_: but lum wont see a fix for scan_capa right?
[17:10] <asac> which is still the default i guess
[17:12] <rtg_> asac: yes, I can probably get that done. I think there is an LP report open on it, right?
[17:12] <asac> rtg_: about missing scan_capa? i think so ... unless it was closed by accident ;)
[17:14] <asac> rtg_: we can use bug 200950
[17:14] <asac> probably should be reopened for  backport-modules 
[17:14] <asac> too
[17:14] <rtg_> asac: perhaps it never made it on ogasawara's list? In that case I might not have seen it recently.
[17:15] <asac> rtg_: you closed that bug with: "* iwlwifi: Update to iwlwifi-1.2.25 and mac80211-10.0.4 - LP: #200950
[17:16] <rtg_> asac: ok, I'll review it and try to figure out what happened. In the meantime I've gotta fix some CVE FTBSs for kees
[17:17] <asac> rtg_: sure. ill reopen it for lbm and add lum to that bug
[17:18] <rtg_> asac: k
[17:18] <asac> and bump severity to medium (high?) and set it to triaged
[17:18] <asac> ;)
[17:30] <asac> rtg_: resume works well with your packages
[17:31] <asac> only thing is that iwl4965 still has its own will in associating to some AP i never connected before after resume
[17:31] <asac> (thats with NM 0.7 - aka without hacks and workarounds)
[17:32] <rtg_> asac: I've never had prblems with that, but I'm using NM straight from the Hardy archive.
[17:33] <asac> rtg_: yeah. that one has several hacks. i hope i can upload NM 0.7 to PPA in the next days
[19:59] <Kano> http://rafb.net/p/U71w8c27.html
[19:59] <Kano> thats the problem with xen + latest nvidia
[20:00] <Kano> lastest git code
[20:56] <Kano> BenC: dont forget module-init-tools
[20:56] <Kano> and the modules abi bump
[20:57] <Kano> so ne module-init-tools in d-u
[21:06] <BenC> another hit and run
[21:06] <BenC> and I've no idea what most of that meant
[21:08] <BenC> and that doesn't look like a xen+nvidia bug...looks more like a paravirt+nvidia bug
[21:11] <munckfish> BenC: Hi, could I pester you about that zinc account?
[21:17] <munckfish> BenC: I'm concerned that the main Ubuntu linux source is getting so far ahead of the linux-port that we'll have a problem catching up.
[21:18] <munckfish> I really need somewhere to upload a tree to so I can get some feedback on the changes I'm making. If zinc isn't the best place for that just now, just say and I'll look at alternative GIT hosting.
[21:18] <BenC> munckfish: linux-ports is 2.6.25 based
[21:18] <BenC> munckfish: there is no skew
[21:18] <munckfish> BenC: did you update it quite recently then?
[21:18] <BenC> munckfish: update what?
[21:18] <munckfish> I last touched it on Friday night
[21:19] <munckfish> oops sorry misread
[21:19] <munckfish> now I mean you're moving on to 2.6.26 now
[21:19] <munckfish> that's what you're targeting for Intrepid right?
[21:19] <BenC> i386 and amd64 are going to be 2.6.26
[21:19] <BenC> I was leaving linux-ports at 2.6.25
[21:20] <munckfish> Ok, I just thought we would try to sync as close to i386/amd64 as poss
[21:20] <BenC> but that's entirely up to who ever wants to maintain it...I can't see the need for 2.6.26, but it's someone elses effort, not mine...just remember it affects 4 architectures + the -386 flavour :)
[21:22] <munckfish> BenC: ok
[21:23] <BenC> munckfish: I'll get your request processed...note, I don't do it myself, I just process them through our IS team
[21:23] <munckfish> ok that's fine I just wanted to know the score really
[21:32] <BenC> score is You - 1, Me - 0 :)
[21:33] <BenC> balls in my court, I'll get it taken care of
[21:52] <lamont> "Q: what is the command for ejecting a DVD from the drive after a drive error? A: /sbin/reboot"
[21:52]  * lamont would love to help fix that
[22:11] <munckfish> BenC: hang on, i386, what's that in ports for? Is that just so we can build on x86 to test?
[22:11] <mjg59> munckfish: i386 rather tha -generic
[22:12] <mjg59> -generic x86 is still mainline
[22:14] <BenC> munckfish: it's the old -386 flavour from mainline
[22:14] <BenC> it's not needed for primary use, so we stuck it in ports
[22:14] <BenC> linux-ports may become the place for things like binary-custom flavours (rt/xen/openvz)
[22:15] <BenC> which is why it needs to be handled with care, and not just have tons of patches dumped into it
[22:20] <munckfish> BenC, mjg59: ok so I take it -generic is more like i486+ (or is that stupid)?
[22:34] <munckfish> ok so I'll take it that's correct :)
[22:39] <munckfish> BenC: I have a very simple patch which allows me to cross build the powerpc64-smp kernel on x86.
[22:39] <munckfish> Just allows setting of the CROSS_COMPILE variable so it can be passed to the kernel makefile
[22:40] <munckfish> that plus running eval `dpkg-architecture -apowerpc -s` is all that was needed
[22:41] <munckfish> are there likely to be any objections to including that in the packing scripts on linux-ports?
[22:41] <munckfish> Surely it would be useful for the other arches too?
[22:41] <munckfish> BenC: over
[22:47] <BenC> munckfish: definitely...sounds like a good addition
[22:48] <munckfish> BenC: cool
[23:09] <munckfish> I have a script I wrote to intelligently compare/diff two kernel configs. Is that something that other folks would find useful? If so I'll mail it in.
[23:10] <munckfish> However, I note most of the script the kernel team use are in Perl. My script is in Python, would that be a problem?
[23:20] <munckfish> For anyone who may be interested I've just written in a PS3 project status update email. Includes progress on the kernel.
[23:20] <munckfish> https://lists.ubuntu.com/archives/ubuntu-cell/2008-June/000122.html
[23:21] <munckfish> That's my day over. Bye all.
[23:37] <BenC> whoop
[23:37] <BenC> lrm for intrepid is done
[23:37] <BenC> pushed, and ready to upload
[23:37] <Nafallo> ooh. does it include support for that eeepc wireless thingie? :-)
[23:38] <Nafallo> cause in that case, it's time to dist-upgrade soon ;-)
[23:41] <BenC> is that a madwifi svn thing?
[23:41] <Nafallo> yea. that weird chipset that needs a new hal or something like that.
[23:42] <BenC> then no :)
[23:42] <BenC> same as the madwifi that's in hardy
[23:42] <Nafallo> I'm stuck on gutsy then :-P
[23:42] <BenC> Nafallo: I'd be willing to introduce an eeepc only madwifi that has just the PCI id's needed
[23:43] <Nafallo> if you do, I would be happy to test it :-)