[00:10] <nealmcb> How do we find out what changed in the recent kernel update (to 2.6.32-22-generic #35-Ubuntu)?
[00:10] <nealmcb> The changelog just seems to cover abi changes
[00:10] <nealmcb>  (I was looking in /usr/share/doc/linux-image-generic/changelog.gz - that may not be the right place....)
[00:17] <Squideshi> Does the kernel ever get updated before the next version of Ubuntu is released? For example, will there be a kernel update before Maverick?
[00:18] <jpds> Squideshi: https://wiki.ubuntu.com/KernelFreeze
[00:18] <ogasawara> nealmcb: https://edge.launchpad.net/ubuntu/+source/linux and click the drop down for 2.6.32-22.35
[00:19] <ogasawara> nealmcb: although there was a kvm regression, so that patch was backed out and an updated 2.6.32-22.36 kernel is in the process of being uploaded
[00:20] <nealmcb> ogasawara: thanks!
[00:25] <Squideshi> Maybe I should just ask the question I really want to know: I'm having a really difficult time troubleshooting the video on my system, because I think I have at least three different problems. First, Compiz doesn't work at all--had to be uninstalled. Second, the stock kernel that ships with Lucid has some problem with my Intel 845G that causes some display glitches and constant GPU lockups....
[00:25] <Squideshi> ...Third, my screen often goes blank (backlight not lit) with a reboot being the only recovery, which I think is a separate problem from the last.
[00:25] <Squideshi> Good news is that I installed a drm-intel-next kernel and the second problem appears fixed.
[00:26] <Squideshi> Although, I wish I knew how to find out WHEN it was fixed (i.e. with what patch) so I could tell you guys.
[00:26] <Squideshi> All of this isn't very easy to log as a bug because I don't know what's really affecting what.
[00:27] <Squideshi> I figure that the GPU lockups with the stock Lucid kernel has already been fixed in newer kernels.
[00:27] <Squideshi> I don't know if there's anything I should do about that.
[00:27] <ogasawara> Squideshi: you could test the latest 2.6.35-rc1 mainline builds to see if it
[00:28] <ogasawara> 's resolved
[00:28] <Squideshi> My guess is that I should start looking at the blank (no backlight) problem.
[00:28] <kees> nealmcb: to answer your specific question, you can find the changelog in /usr/share/doc/linux-image-$(uname -r)/changelog.Debian.gz
[00:28] <ogasawara> Squideshi: https://wiki.ubuntu.com/X/Bugs/Lucidi8xxFreezes might also help
[00:28] <Squideshi> ogasawara: What's the difference between the drm-intel, drm-intel-next, and mainline kernels?
[00:30] <ogasawara> Squideshi: drm-intel and drm-intel-next I presume are staging trees for patches which eventually get pushed to mainline assuming no ill effects
[00:30] <Squideshi> ogasawara: Is blacklisting Intel 8xx hardware for KMS going to work, considering that Intel has removed ALL user mode setting in the newer drivers?
[00:31] <RAOF> Squideshi: Yes, because you'll get VESA - or, if you install it, an old forked -intel driver from Universe.
[00:32] <Squideshi> Hmmm... That's a shame because it seems fixed with the newer kernel I installed.
[00:32] <Squideshi> The glitching and GPU lockups that is.
[00:33] <nealmcb> kees: ding ding ding - just what I hoped for....  thanks :)
[00:33] <kees> nealmcb: np :)
[00:34] <RAOF> Squideshi: I'm surprised.  The GTT incoherency bug is still open upstream, and didn't appear to be being worked on.  You'll still be able to enable KMS and use the new intel drivers if you want - we only change the default, not forcibly disable KMS.
[00:34] <Squideshi> RAOF: I don't know if "GTT incoherency" is the same thing that I'm experiencing.
[00:35] <RAOF> Squideshi: You will be, but it's possible that it's sufficiently infrequent for it to appear as background noise.
[00:36] <Squideshi> RAOF: Like I said, it's difficult to separate everything out. I was so happy when the newer drm-intel-next kernel I installed resolved the flicker and GPU lockups that I thought I might be able to jut focus on the frequent screen blanking (no backlight.)
[00:37] <Squideshi> RAOF: After those two, I thought only then would it be appropriate to figure out Compiz.
[02:27] <stenten> Is there a kernel parameter to set the dmesg font during boot? Trying to catch a trace that keep scrolling off the screen.
[08:53] <lag> http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-67881
[09:02]  * hughhalf steps away for a bit
[09:02] <cking> lag, http://kernel.ubuntu.com/git?p=cking/debug-code/.git;a=blob;f=led-flash-user-space/led.c;h=61131fc7caefcebc50326f48b630726e77e402b3;hb=ebb3c4b8e2c5ff1628f8b42076e6b9e969ed5f52
[09:25] <lag> http://frommel.net/weblog/images/htc-desire.jpg
[09:53] <rafiyr> what's kzalloc?
[09:54] <rafiyr> oh, nm, found the desc
[09:55] <rafiyr> strange though
[09:55] <jk-> strange?
[09:56] <rafiyr> there was a comment from dmitry on linux input suggesting kcalloc instead of kzalloc
[09:56] <rafiyr> seems to me they are pretty damn similar
[09:57] <rafiyr> only thing I see is the potential to take advantage of the knowledge of array structure in the future if calloc is used
[09:58] <rafiyr> well that and I guess one extra check for kcalloc against ULONG_MAX
[10:02] <jk-> just makes it explicit that you're allocating for an array of stuff
[10:50] <rafiyr> Oh, right there's the whole question of readability too :)
[10:50] <rafiyr> I was thinking in terms of implementation and possible optimizations.
[10:51] <rafiyr> For example, if you were to run a kernel on an FPGA, you can actually do something useful knowing that a block of memory is actually an array
[10:53]  * apw discovers xchat is not running ... hrm ... i thought you lot were very quiet
[11:06] <amitk> jk-: around? care to join #linaro?
[11:30] <l3on> Hi all, someone of you can tell me if there is something wrong/missing in bug 589598?
[11:30] <ubot2> Launchpad bug 589598 in linux (Ubuntu) "B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card does not work anymore (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/589598
[11:47] <ogra> apw, amitk, https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/589624 for your radar
[11:47] <ubot2> Launchpad bug 589624 in linux (Ubuntu) "omap flavour does not work on beagle XM board (affects: 1) (heat: 8)" [High,New]
[11:48] <amitk> ogra: ack
[11:48] <amitk> ogra: I thought you said it worked before
[11:50] <apw> amitk, i suspect that is a bug in the omapfb driver ... as it failed to init, but the cursor flash timer is running
[11:52] <ogra> amitk, nope, i was thinking i see the typical "no rootfs found" oops here, but after apw had me verify it with an actual rootfs in place it showed its really a bug
[11:53] <amitk> I'm not surprised if it is a DSS2 bug
[11:53] <ogra> yeah, i hope we get that working in time for all these different devices
[11:53] <apw> amitk, are you still owning omap, or do i need to lean on someone else
[11:53]  * ogra has to actually try the touchbook and zoom
[11:54] <amitk> apw: I don't _own_ it. Mathieu and cooloney-afk do. I'll just help them with bits and pieces. In this case I have the HW.
[11:56] <apw> amitk, ok so i'll hastle them then
[11:56] <amitk> apw: I am obviously interested though. So what will you hassle them about? ;)
[11:57] <apw> amitk, it not working obviously :)
[11:57] <apw> s/hastle/make sure they are aware it is an issue and needs fixing/
[11:57] <amitk> heh
[11:57] <apw> ogra, does it work on a regular beagle ?
[11:58] <ogra> apw, havent tried yet :)
[11:58] <ogra> will do after the release meeting, but i would expect so
[12:26] <apw> ogra, is the release meeting on ?  seems to be gone from my cal
[12:57] <ogra> apw, according to a mail i got from davidm i have to attend
[12:57] <ogra> apw, but i dont see it on my cal either
[12:57] <apw> ogra, seems to be gone and i have this email
[12:58] <apw> From: Robbie Williamson <robbie.williamson@canonical.com>
[12:58] <apw> To: Andy Whitcroft <andy.whitcroft@canonical.com>
[12:58] <apw> Subject: Canceled Event: Maverick Weekly Release Meeting @ Weekly from 16:00
[12:58] <apw> so i think its not there any more ...
[12:58] <apw> i don't have agenda either
[12:59]  * apw asks on #ubuntu-release
[13:05] <apw> ogra, seems not till next week
[13:06] <ogra> sweet !
[13:06] <ogra> extra free hours with that wonderful weather !
[13:06] <apw> yeah indeed so
[14:24] <apw> JFo, about ?
[14:24] <JFo> I am indeed apw
[14:24] <apw> JFo, roomies for sprint ?
[14:24] <JFo> sounds good to me :)
[14:25] <apw> cool i'll put you in then ... i note you are missing from the list right now
[14:25] <JFo> ah yes, still hashing out travel with Atlas
[14:25] <JFo> ;-/
[14:26] <apw> come on, you'd love to row all the way
[14:28] <apw> jjohansen, about?
[14:45] <dupondje> JFo: commented my bug again, added another dmesg output. Totally other error .. guess my BIOS/Mobo if00bar :)
[14:46] <JFo> heh, it happens sadly enough :-/
[14:46] <dupondje> Its a new bios that supports new cpu's, but seems like its quite bad support :(
[14:46] <dupondje> ah well, I close the bug as 'Invalid' ?
[14:48] <ogra> apw, so i'm seeing the ARM meeting minutes on the kernel ML, thats not talking about our kernel we ship on the ubuntu images, is it ?
[14:50] <apw> ogra, thats talking about how the linaro kernels might make it into the archive
[14:50] <ogra> apw, ok, but in separeated out binaries please
[14:50] <apw> so that should be 'all' the arm branches but not those in master
[14:50] <ogra> i dont want to risk image stability for omap3/4 images
[14:51] <apw> ogra, right this is not fixing the 'one actual binary to rule the world' issue
[14:51] <apw> its likely the package would produce 5-6 binary image sets
[14:51] <ogra> thats fine as long as i have a stable version for omap3 and a stable version for omap4
[14:52] <ogra> i just dont want experimental kernels in my images
[15:00] <JFo> dupondje, sounds good
[15:01] <JFo> who could blame you ogra :)
[15:25] <bjf> moin all
[15:28] <apw> moin
[15:32] <JFo> moin bjf
[15:43] <JFo> apw, did you get the chance to create my testing directory on the kernel PPA?
[15:43] <JFo> or was it you I was even talking with about it?
[15:43]  * JFo forgets
[15:46] <Kano> hi apw 
[15:47] <Kano> is there a custom enforce file too? that i dont need to change the other one that will override the default enforce?
[15:47] <apw> JFo, can't remember ... can do it now
[15:47] <apw> Kano, not currently there is just one per series
[15:47] <JFo> if you like, was just trying to remember if we had discussed it at all
[15:48] <apw> JFo, the scripts running as you i assume yes
[15:48] <Kano> apw: it would be a good idea however, something thats used after the default, so i could put my changes in there
[15:48] <JFo> I didn't want to blindside you with it if we hadn't
[15:48] <JFo> apw, think they are running as bjf
[15:48] <JFo> but I defer to him
[15:48] <Kano> apw: the n value is for unset or?
[15:48] <Kano> usually there is no n
[15:48] <apw> Kano, yes n means #FOO is not set
[15:48] <bjf> JFo, which scripts?
[15:49] <JFo> the createiso stuff
[15:49] <JFo> bjf, was seeing if apw minded setting us up a dir in the PPA
[15:49] <JFo> for the testing ISOs
[15:49] <apw> yep seems fine
[15:49] <apw> 1) what you want to call it ?
[15:49] <bjf> JFo, apw yes they are running as a personal cronjob on emerald
[15:49] <apw> 2) who needs to be able to write to it
[15:50] <Kano> apw: do you know why mantis driver has still no pci ids enabled
[15:50] <JFo> testing is fine with me, what do you think bjf?
[15:50] <Kano> apw: echo "MODULE_DEVICE_TABLE(pci, mantis_pci_table);" >> v4l/mantis_cards.c
[15:50] <Kano> something like that would add those
[15:50] <JFo> as to who writes to it, hmmm I assume bjf will be copying over.
[15:50] <apw> Kano, no idea, not something i've run into
[15:50] <JFo> apw, I think he is generating them on emerald
[15:50] <apw> JFo, will play a minute thanks
[15:50] <JFo> so they just need to copy over iirc
[15:50] <Kano> thats stupid because when you are used to dvb-s2 lip
[15:51] <JFo> k
[15:51] <Kano> then there was always a pci-id table
[15:51] <Kano> just the normal mantis in the kernel does not
[15:51] <bjf> that's a pretty broad name, as far as who, we can make it anyone, is this something I am going to own or is someone else going to take ownership (doesn't matter to me)
[15:51] <JFo> I actually prefer not to lock it down to you now that you mention
[15:51] <JFo> bus test and all, God forbid
[15:53] <bjf> do we have a non-real user launchpad user that this could run as?
[15:53] <JFo> kernel-janitor
[15:53] <achiang> does anyone know if the latest released security kernel has other fixes from -stable?
[15:54] <JFo> achiang, apw knows... poor man
[15:54] <apw> achiang, it has only the single revert
[15:54]  * JFo fixes apw a large beer
[15:54]  * apw thanks JFo 
[15:54] <JFo> my pleasure
[15:55] <achiang> apw: hm, i wasn't paying attention to what was released yesterday. it only had some patch that broke kvm and no -stable updates? and now the most recent kernel reverts that single patch. do i understand that correctly?
[15:56] <apw> .35 had about 5 security related updates, .36 reverted just one of them
[15:56] <apw> there was no -stable in either of them
[15:56] <achiang> apw: ok, thanks
[16:12] <manjo> JFo, 1/2 day bug day is morning or afternoon? are we just picking bugs at random from the list ? 
[16:12] <JFo> either morning or afternoon
[16:12] <JFo> you work through the ones on the Top50
[16:12] <JFo> to get them moved off if possible
[16:14] <apw> bjf got a sec ?
[16:14] <apw> manjo, whenever you want
[16:15] <manjo> apw, yep I just started looking at some so was not sure 
[16:15] <manjo> JFo, ^
[16:15] <JFo> cool
[16:19] <bjf> apw, what can i do for you? (i cringe at the thought)
[16:20]  * apw mumbles at you
[16:20] <JFo> heh
[16:21] <bjf> apw, give me a sec. mumble non-responsive
[16:21] <apw> bjf, heh what fun
[16:21]  * JFo realizes he's not mumble ready... sitting here with the headset on for no reason apparently
[16:22] <JFo> sad given I've had a pot of coffee already today
[16:22] <apw> no sleep for you
[16:22] <apw> JFo, doh
[16:22] <JFo> didn't get any last night
[16:22] <JFo> that is the reason for the coffee
[16:22] <JFo> :(
[16:24] <JFo> stupid headache
[16:25] <JFo> ogasawara, are you around yet?
[16:25] <ogasawara> JFo: yep, here
[16:25] <JFo> cool
[16:25] <JFo> I am going through my list of things not to forget...
[16:26] <JFo> did I tell you that James Westby asked me if we wanted him to turn on kerneloops again?
[16:26] <JFo> or something like that
[16:26] <JFo> it is what I have written down from UDS
[16:26] <apw> we norally have it on for development
[16:26] <JFo> right
[16:27] <ogasawara> JFo: we can, it's your call now :) usually we'd crank in on around alpha1
[16:27] <JFo> ok, I'll ping him on it then :)
[16:27] <JFo> he made it seem as if it was my call, but I wanted to verify before I made the change
[16:28] <ogasawara> JFo: go for it
[16:28] <JFo> cool
[16:33] <JFo> tgardner, you around?
[16:35] <tgardner> JFo, yo
[16:36] <JFo> tgardner,  cjwatson indicates that the bnx2 module was broken in bug 589304
[16:36] <ubot2> Launchpad bug 589304 in linux (Ubuntu) "Broadcom bcm5708 ethernet not initialized during install (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/589304
[16:36] <JFo> was just wondering what my next step should be
[16:36] <JFo> and I wanted to ask you based on your intimate familiarity :)
[16:37] <cnd> apw: http://kernel.ubuntu.com/git?p=cndougla/hedley.git;a=shortlog
[16:38] <tgardner> JFo, looking...
[16:38] <JFo> k, thanks
[16:38] <tgardner> JFo, its a missing firmware problem. seems like a regression, but I dunno why.
[16:39] <JFo> he seemed to think it was just broken... and at that point I was lost :)
[16:40] <JFo> tgardner, looks like fader removed and reinserted the firmware but that didn't help
[16:40] <JFo> so it looks like it was there, just not functional for some reason
[16:41] <tgardner> JFo, looks like the maverick driver wants an updated firmware file which we donot yet have.
[16:41] <JFo> ah, I see
[16:44] <tgardner> JFo, I've updated the LP report and taken ownership
[16:45] <JFo> thank you sir
[16:48] <manjo> apw, http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current this is correct? I get 404
[16:49] <apw> manjo, i removed one to rebuild it so current may currently not point anywhere while it builds
[16:50] <manjo> apw, ah so it will come back later ? 
[16:50] <manjo> what version are you building right now ? so that I can put that in my report 
[16:53] <apw> so it will come back later yes in theory
[16:53] <apw> what report ?
[16:58] <apw> ogasawara, if you see a late build failure related to aliases, let me know (with your new kernel)
[16:58] <apw> ogasawara, i think i know what it is and am working on it
[16:58]  * apw pops out
[16:58] <ogasawara> apw: building cleanly for me on i386 and amd64, just failing on the ports
[17:04] <jjohansen> apw: whats up?
[17:09] <cnd> git rebase --onto mvl-dove branchpoint merge
[17:29] <tgardner> JFo, have you seen any bugs complaining about server consoles selecting the wrong display resolution if there is a KVM in the way? I have a case where the KVM supports up to 1680x1024, but the attached monitor only supports 1024x768.
[17:29] <tgardner> 1680x2048*
[17:29] <tgardner> or something....
[17:30] <JFo> tgardner, not off the top of my head, but I can look
[17:30] <JFo> actually, I think i have seen some
[17:30] <tgardner> thanks
[17:30] <JFo> let me dig a bit
[17:33] <cnd> when upgrading, 2.6.32-22.21~v1 is seen as later (i.e. newer, should be upgraded to) than 2.6.32-22.21
[17:33] <cnd> correct?
[17:33] <tgardner> cnd, yep
[17:33] <cnd> tgardner: thanks
[17:34] <Kano> usually ~ is before
[17:34] <tgardner> cnd, lemme retract, 2.6.32-22.21~v1 is ealier
[17:34] <Kano> - after
[17:34] <cnd> wait, so I have it backwards?
[17:34] <tgardner> yes
[17:34] <cnd> ok
[17:34] <tgardner> the tilde is like a minus
[17:35] <cnd> is the ~ special?
[17:35] <tgardner> yes
[17:35] <cnd> ohhhh
[17:35] <cnd> so I would have been right if I appended 'v1' instead of just '~v1'?
[17:35] <tgardner> a tilde lexicographically subtracts from the version
[17:35] <cnd> ok
[18:31] <JFo> any reason why we haven't built 2.6.31.13 in the mainline PPA or do we stop doing that at a certain point?
[18:32] <apw> JFo, hrm not sure
[18:33] <JFo> saw the question in a bug and thought I'd ask... after verifying that there was, in fact, a .13 version :)
[18:35] <apw> JFo, but there is a 2.6.31.13
[18:36] <JFo> hmmm
[18:36] <JFo> .me looks in mainline
[18:37] <JFo> ah, it is the http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html which doesn't show it
[18:38] <JFo> only has one image and one header while the others have 2 of each. that sound correct apw?
[18:38] <JFo> errr in some cases 3 of each
[18:38] <apw> ahh you meant its there and its broken
[18:38] <JFo> could be
[18:39]  * JFo is not sure what he means today
[18:39] <JFo> been a very bad day
[18:48] <apw> JFo, ok its not obvious that its not a bad buids, so rebuilding it
[18:48] <JFo> k, thanks apw
[19:31]  * bjf[afk] -> lunch
[19:31]  * kees starts using ccache ...
[19:46] <jjohansen> -> lunch
[19:53] <cking> manjo, did you get that PC?
[20:01] <manjo> cking, was just receiving it 
[20:01] <manjo> cking, that is fast shipping 
[20:15] <cking> manjo, note that it's already pre-installed with karmic - so it may be a good idea to see how that's configured 
[20:15] <kassah_> what does the extra minor version mean on proposed kernels? i.e. 2.6.32.14.5 (The last .5)
[20:15] <cking> if you have any questions, send me an email, I'm having to finish up for the day now
[20:15] <cking> ^^ manjo
[20:15] <manjo> cking, yep will power it up as soon as I get a  power cable
[20:16] <manjo> cking, play with it over the weekend and ping you on Monday
[20:16] <cking> manjo, perhaps we can find time next week to walk through it
[20:16] <manjo> cking, good idea
[20:16] <cking> cool - have a good weekend!
[20:16] <manjo> cking, you too
[20:16] <cking> ta! bye!
[20:22] <kees> what's the best way to keep my ubuntu-maverick git tree on zinc up to date ?
[20:31] <sconklin> kees: it depends - do you just want to keep the branches from the origin updated, or do you want to rebase your own branches or anything like that?
[20:32] <sconklin> kees: I haven't done it on zinc, but I have run cron jobs on my server at home to fetch from upstreams
[20:32] <kees> sconklin: well, I think I've sorted it with the alternate file
[20:33] <kees> sconklin: but I'm curious how to push from my local git, in a branch named "maverick-ptrace" to my remote maverick's master.
[20:33] <sconklin> git push remotename localbranchname:remotebranchname
[20:34] <sconklin> so git push remotename maverick-ptrace:master
[20:34] <kees> ah-ha, colon.  more man page fail.
[20:34] <sconklin> yeah, that one was not obvious at all to me
[20:35] <kees> okay.
[20:35] <sconklin> be aware (I think) that this is one of the situations where pushing a blank branch name deletes the remote branch.
[20:35] <kees> http://kernel.ubuntu.com/git?p=kees/ubuntu-maverick.git;a=summary  <- the tag for 5.14 is missing here, and I don't know why
[20:36] <sconklin> oh, ask apw but I think unless you push the tag as the identifier or push --tags, they don't all go. But --tags can push a lot of crud you don't want, since tags are across all branches
[20:37] <kees> hm
[20:37] <sconklin> I need to reread that chapter in the book, actually
[20:37] <kees> heh
[20:41] <apw> sconklin, kees, right you have to push them explicitly which may mean ogasawara didn't push it
[20:42] <ogasawara> oops, /me check
[20:42] <kees> no, it's my tree that is missing it
[20:43] <apw> kees, i have seen tags get lost on fetch
[20:43] <kees> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=summary vs http://kernel.ubuntu.com/git?p=kees/ubuntu-maverick.git;a=summary
[20:43] <apw> you only get a tag if the tag points to a commit when you get that commit
[20:43] <apw> so if ogasawara pushed, you fetch then she pushed the tag you may not get it
[20:44] <apw> kees, git fetch --tags origin should get you any missing ones
[20:45] <kees> ah, so I have a single local repo that has both linux-2.6 and ubuntu-maverick as remotes.  How do I get both sets of tags?
[20:46] <kees> sounds like I just want to add --tags to my "fetch" uses
[20:46] <apw> kees, normally you should get them automaticall
[20:46] <apw> it should get any tags pointing to any new commits you get, i've only seen it out of sync once or twice and used --tags to fizx
[20:46] <apw> fix
[20:50] <kees> hunh, still can't seem to push the tags.
[20:51] <kees> if I add --tags to the push, it tries to upload the entire change history.
[21:04] <JFo> ogasawara, kerneloops re-enabled now per James_w
[21:26] <apw> JFo, that 31.13 finished ok this time
[21:27] <JFo> yep, I saw it. Thank you sir :)
[22:05] <lag> Night all!
[22:05]  * lag is sleepy!