[04:33] <cavedon> hi all!
[04:34] <cavedon>  I am testing jaunty beta, but I have an annoying regression:
[04:34] <cavedon> when I reboot or halt, it stops at "will now halt" or "will now reboot" most of the times: any idea of how to debug that?
[04:34] <cavedon> https://bugs.edge.launchpad.net/ubuntu/+bug/349778
[04:34] <ubot3> Malone bug 349778 in ubuntu "[jaunty] Dell Inspiron 1525 sticks on "System will now halt", works with 2.6.29" [Undecided,New] 
[14:10] <ogasawara> rtg: kees has got a patch for bug 350789 he'd like to see get in for jaunty final
[14:10] <ubot3> Malone bug 350789 in linux "AppArmor Debug: Hook being called from interrupt context" [Medium,Triaged] https://launchpad.net/bugs/350789
[14:10] <ogasawara> rtg: should he submit it to the kernel-team ml as well?
[14:11] <rtg> ogasawara: I looked at this, but I'm not wild about it. it seems like a hack to cover for a poorly written blue tooth driver.
[14:12] <ogasawara> kees: ^^
[14:18] <amitk> lool: https://bugs.edge.launchpad.net/ubuntu/+source/linux/?field.searchtext=&orderby=-importance&field.tag=arm&search=Search
[14:18] <amitk> lool: current status of arm bugs. Anything else you need fixed _urgently_? 
[14:24] <NCommander> sconklin, I kicked the updated lpia configuration files to the list last night, which fixes d-i on ARM
[14:33] <amitk> NCommander: lpia config fixed d-i on arm?
[14:33] <NCommander> wow
[14:34] <NCommander> I think my brain crapped out half way through that sentence
[14:34] <NCommander> lpia config to fix d-i on lpia :-/
[14:34] <amitk> hehe...
[14:34]  * NCommander needs coffee .... lots of it
[14:37] <sconklin> NCommander: I responded on list
[14:50] <manjo> sconklin, try this http://meandubuntu.wordpress.com/2008/11/18/real-64-bit-flash-on-amd64/
[16:09] <ChinoChano> hi guys,
[16:10] <ChinoChano> one question: in kernel 2.6.28, is WideView WT-200U and WT-220U (pen) DVB-T USB2.0 support (Yakumo/Hama/Typhoon/Yuan) avail in this kernel?
[16:14] <kees> rtg: jj said a similar thing when he saw the bug.  perhaps a small modification to leave the "BUG" report and to correctly handle the memory allocation method just to reduce possible instability?
[16:15] <sconklin> Please use and update as needed - https://wiki.ubuntu.com/GitCheatSheet
[16:26] <k-s> hi there, compiling custom kernel for macbook4.1
[16:26] <k-s> all good, just need some info on how to get pretty package names
[16:26] <k-s> today I'm doing nasty hack, just replace config and let it generate
[16:26] <k-s> but generates as 2.6.28-11-GITHASH-generic
[16:27] <k-s> I guess it would be better to have it as 2.6.28-11-macbook41 (flavor=macbook41)
[16:27] <k-s> manjo mentioned to me I should update debian/changelog
[16:28] <k-s> but do I need a git-tag with the name within parenthesis?
[16:29] <manjo> you could change the 1st line on debian/changelog to something like ::: linux (2.6.28-10.33~lp326621manjo1) UNRELEASED; urgency=low
[16:29] <k-s> did it already
[16:29] <manjo> k
[16:29] <k-s> but before generating, I would like to know what more do I need
[16:30] <k-s> ie: why changing the config will lead to hash in the name? since I have debian/changelog it should use that top line, no?
[16:30] <k-s> so I'm guessing it does some git<->changelog mapping somehow
[16:31] <ChinoChano> guys, does the 2.6.28 have the support for WideView DVB pen usb receiver?
[16:31] <ChinoChano>  WideView WT-200U and WT-220U (pen) DVB-T USB2.0
[16:42] <manjo> k-s, apw might know more abt git<->changelog stuff
[16:43] <k-s> manjo: ok, it's not possible to have '~' in tag name, so I suppose you don't do a tag and still have the package name correctly
[16:43] <k-s> maybe it was like that because I had uncomitted git changes, let's see if it works now with changelog + git commit
[16:44] <k-s> manjo: and thanks for your time, I know you're quite busy there
[16:44] <manjo> apw, ^^^
[16:44] <manjo> k-s, apw is the git guru 
[16:44] <k-s> apw: hey :-)
[16:45] <infinity> smb_tp: How long does the ltp suite take?
[16:45] <apw> huh there is lots of info here, what was the question?
[16:45] <k-s> apw: if you have some time, it's more related to debian/ubuntu packaging than anything else, from what I've read I need to create a custom "flavor" to live side by side with "generic"
[16:45] <apw> wahts the difference between your new kernel and generic?
[16:45] <k-s> apw: I want to have a custom macbook41 flavor, since I know all the hw it's there (except pluggable usb/firewire)
[16:45] <smb_tp> infinity, depending on the hw pretty long. never measured it
[16:46] <infinity> smb_tp: Minutes, hours, or days? :)
[16:46] <smb_tp> infinity, hours
[16:46] <infinity> Ow.
[16:46] <k-s> apw: I'm using it for some time already, compiles really fast (so no trouble to maintain) and works better, no need for initramfs and thus boots fast
[16:46]  * infinity kisses artigas goodbye for a bit.
[16:46] <k-s> also I like to have my own kernels, it's an old habit
[16:47] <apw> so you want to stop is our kernel updates eating your kernel?
[16:47] <manjo> infinity, what was the question abt ltp ? 
[16:47] <smb_tp> infinity, might be something in the size of 3hrs, but as said, I usually fired it up on a machine and looked back later
[16:47] <smb_tp> manjo, how long it is running
[16:48] <k-s> apw: no, just want to have a nice package name ;-)
[16:48] <k-s> apw: I already disabled my kernel being replaced in config files, that's fine
[16:48] <k-s> apw: but I'd like to have something better than 2.6.28-11-1c2a1a-generic
[16:48] <apw> hrm, then i guess a flavour name is reasonable thats what a flavour is, a different config combination
[16:49] <manjo> depends on how you run it also... ie if you have genload running in the background it might take longer
[16:49] <manjo> genload will run if you run with system load options in runltp
[16:50] <k-s> apw: yep, but I tried to have my own flavour and it didn't work, at least followed a wiki+blog and it did not work, maybe I missed something obvious since I was in a hurry, AFAIR it was related to some files it expected in debian/ not being there like old version symbols or so
[16:51] <k-s> apw: also, what's annoying now is that it will always add -GITHASH to name, so I need to go there and update control{,.stub}
[16:51] <apw> githash is addwhen when your tree is dirty
[16:53] <k-s> apw: I just do git clean -fxd before running debian/rules
[16:53] <apw> there is an optiion somewhere, _AUTO in the config which triggers the addition
[16:55] <k-s> apw: which config? kernel or debian/*?
[16:57] <apw> kernel config, in debian/configs/*
[17:00] <k-s> apw: from debian/rules.d/2-binary-arch I see that it will forcely disable it
[17:03] <k-s> ok, tried with git committed and changelog, still no luck
[17:04] <k-s> my cmdline reads: ./debian/rules binary-generic AUTOBUILD=1 NOEXTRAS=1 CONCURRENCY_LEVEL=2 no_dumpfile=1 
[17:26] <CarlFK1> how do I make this auto inc so that it shows up as a default for new data?    db.Field( 'seq', 'integer', ),
[17:27] <CarlFK1> um.. that sounds weird...
[17:29] <CarlFK1> woa.. wrong #chan
[17:59] <lool> amitk: the FSL stuff is urgent, and is in your inbox
[17:59] <amitk> lool: it is already *in*
[18:02] <lool> amitk: (I couldn't tell since I got no update via email)
[18:03] <lool> I pulled the git tree now and I see some
[18:40] <infinity> smb_tp: Your kernel boots on artigas, userspace and dmesg seem happy, running ltp now to compare to the previous kernel.
[18:40] <infinity> smb_tp: (I'm comparing to -51-, since that's what was installed... If you need a comparison against -53- so we're only isolating your changes, I can do that later)
[18:42] <smb_tp> infinity, Err, I am a bit slow catching, by the numbers this sounds like hardy, which architecture is artigas?
[18:42] <infinity> smb_tp: Dapper.  Even.  Sparc.  Testing your "omg, syscall tables completely rewritten" kernel.
[18:43] <smb_tp> infinity, Ah, cool.
[18:44] <smb_tp> Oh, yeah. For dapper its -53 and for hardy 24.52. That confused me 
[19:44] <mathiaz> hi - how can I make sure that a certain changeset is the jaunty kernel?
[19:44] <mathiaz> hi - how can I make sure that a certain changeset is *in* the jaunty kernel?
[19:45] <mathiaz> I'm looking for changeset c073b2db006ba9370be1eecc36a1be1d9ce31310
[19:46] <manjo> git log | grep 
[19:46] <manjo> c073b2db006ba9370be1eecc36a1be1d9ce31310
[19:59] <neuralis> hi, folks. with the desktop kernel turning non-preemptible, are there significant differences other than tick frequency and numa support between the desktop and server kernels?
[20:03] <manjo> neuralis, http://www.ubuntu.com/products/whatisubuntu/serveredition/features/kernel
[20:08] <neuralis> manjo: aha, neat. wasn't aware of that page. thanks!
[20:09] <manjo> np
[20:31] <liw> any kernel hackers knowledgeable about the SATA subsystem? #257790 is bothering me (I have four new SATA disks I'd like to use), and I'd be glad to help debugging this
[20:53] <manjo> liw, does it work with jaunty ? 
[20:54] <manjo> liw, have you tried the jaunty live cd to see if it works ? 
[20:55] <liw> manjo, as I said in the bug, I've tried everything from gutsy onwards; gutsy works, nothing later does
[21:26] <manjo> liw, can you try with kernel option iommu=soft ? 
[21:44] <infinity> smb_tp: Still around?
[21:44] <smb_tp> infinity, yep
[21:44] <infinity> smb_tp: http://lucifer.0c3.net/~adconrad/ltp-results/
[21:45] <smb_tp> infinity, looking quickly, it looks like no diff which sounds good
[21:46] <infinity> smb_tp: 53 and 54 are identical.  From 51 to 53, there were changes, which I'm not sure were intentional.
[21:47] <smb_tp> infinity, Have only been looking at the summary, so the overall was equal
[21:48] <smb_tp> infinity, have to get it downloaded and look
[21:50] <infinity> smb_tp: Still, given all the ridiculous mangling in your test kernel, the lack of regression from 53 to 54 is comforting. :)
[21:51] <smb_tp> infinity, true enough :) Either there are not many dapper users or nobody really had bad experience with that other change
[21:52] <infinity> smb_tp: Well, there were two fixes (pty and pwrite), and then the writev flip-flopping, I'd have to check to see what the test is actually doing to see if it's a regression, fix, or a wash.
[21:52] <infinity> smb_tp: But it seems fine to me.
[21:53] <smb_tp> kees, ^^^ I would be fine with it as -51 is quite some time ago
[21:53] <infinity> smb_tp: In a day or two, we won't be running dapper/sparc in the DC anymore either (I've been in the process of ugrading all our sparc machines to hardy), so the point's somewhat moot to me.
[21:55] <kees> smb_tp: yeah, I'm fine with the -51 to -53 regresssions -- no one else seemed to notice.  it's the -53 to -54 we need to study, and so far so good.
[21:56] <infinity> kees: Like I said, the test output for 53 and 54 were identical on artigas, and it seemed pretty happy with the whole thing.
[21:56] <kees> smb_tp: I'm happy with the LTP output we've seen.  shall I shove dapper into the build queue too?
[21:56] <kees> infinity: yeah
[21:57] <infinity> smb_tp: If any of the patches touched smp-specific bits, might want to make sure sparc64-smp is also in good shape, but it's a thumbs-up here for UP.
[22:02] <kees> sbeattie: you said you had a single test regression on your ultra60?  is it smp?
[22:05] <smb_tp> infinity, O am not aware of anything smp specific out of my head.
[22:08] <sbeattie> kees: it is.
[22:09] <kees> sbeattie: can you spin a few more tests on -53 and again on -54?
[22:09] <sbeattie> I've reproduced the oops; running ltp *outside* of screen seems to trigger it; I ran my -53 test under screen, so I'm seeing if it reproduces there.
[22:10] <sbeattie> kees: sure thing; like I said, it just takes a little while.
[22:11]  * kees nods
[22:12] <kees> ironically, oopsing on -53 is okay in this case.  :P
[22:12] <sbeattie> kees: indeed! I'd do a happy dance if it oopsed on -53. :-/
[22:12] <sbeattie> alas, it appears not to. :-(
[22:14] <kees> oh.  dang
[22:14] <infinity> sbeattie: And this is actually reliably reproducible in -54?
[22:15] <smb_tp> There could be a chance this is related to "sparc: Fix mremap address range validation." as well
[22:29] <rtg> smb_tp: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=blobdiff;f=drivers/bluetooth/btusb.c;h=d4ec9a98fb19a2cefccd4a0f71f22826dcd11fb6;hp=3b0545ba59f204301e1191dd27acc5e7816e4568;hb=1bb9aba826e75a31c719e5ef60ba616e53ae09bd;hpb=66f550e4f758fc8a0f78f35395d283d526dc9c37 has a compile error
[22:37] <infinity> smb_tp: If you do any more work on that kernel and need a re-test on artigas, let me know.
[22:39] <smb_tp> infinity, Ok, will do. Thanks
[22:45] <dtchen> amitk: follow up on 351924 is appreciated
[23:01] <sbeattie> bah; every time I think I have a grip on reproducing this oops, I then can't reproduce it.
[23:02] <DaemonFC> has anyone pulled these?
[23:02] <DaemonFC> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=395d73413c5656c6d7706ae91dcb441f9b7e3074
[23:03] <dtchen> DaemonFC: you can check yourself in ubuntu-jaunty.git
[23:04] <DaemonFC> I was asking Eric Sandeen about that cause I just crashed a few hours ago
[23:04] <amitk> dtchen: will try to have it for you by tomorrow. Not near the machine currently
[23:04] <DaemonFC> and lost some data that hadn't been committed
[23:04] <dtchen> amitk: that's fine, thanks
[23:54] <Kano> hi, i found a missing firmware for 2.6.28+ for a dvb-s2 card for hauppauge
[23:55] <Kano> dvb-fe-cx24116.fw
[23:55] <Kano> should i write to the list?
[23:55] <Kano> or does somebody directly want to add it..