[07:44] <ogasawara> apw: just fyi, I'll cover us at the release meeting tomorrow.  gcc should just about be done building by then so I plan to do one last kernel upload to pull in what we have in master-next for Alpha-1.
[07:49] <open-nandra> hi
[07:50] <open-nandra> after upgrading to ubuntu 11.04 (for 10.10) i have troubles with my SD card reader integrated in acer extensa 5635
[07:50] <open-nandra> simply put SD card in usb device (some realtek reader ) is recognized but then after some seconds is disconnected
[07:50] <open-nandra> very strange
[07:51] <open-nandra> works fine with 2.6.35
[07:51] <open-nandra> any ideas or it is known pb?
[08:05] <apw> open-nandra, nothing i've heard about no
[08:05] <apw> pls file a bug against linux
[08:24] <smb> morning
[08:24] <jjohansen> morning smb
[08:25] <ppisati> morning
[08:25] <apw> morning
[08:26] <jjohansen> morning: ppisati, apw
[08:26] <apw> jjohansen, late one for you
[08:27] <jjohansen> heh yeah, Ian had a late nap, so he will be up for at least a couple more hours so I am writing
[08:27] <smb> code or documentation?
[08:27] <jjohansen> smb: documentation after a fashion, its a paper
[08:29] <apw> anyone else running natty with an external monitor, and if so, are the indicators on the external monitor creaping off the right slowly over time?
[08:30] <smb> apw, Well I run it on my desktop...
[08:30] <apw> this is over days i am noticing it moving off, the power button me menu and clock have gone now, and a few pixels of the envelope now
[08:30] <jjohansen> apw: I get indicators being half drawn/covered and indicators disappearing, not seen going off the right
[08:31] <smb> But the indicators stay I think (if they show up at all, though that could have been because when booting there was an external networking issue)
[08:31] <apw> yestrerday i only had the date, no time from the time app, now the date is gone as well
[08:32] <ohsix> are any of the migration applets in the empty space
[08:32] <jjohansen> apw: fun, have you tried killing compiz, and or unity to see if it restores them
[08:32] <smb> Hrm, only got the time there ... and the settings thre brings up ... nothing
[08:33] <ohsix> er if it's unity then it's not a real panel and nevermind me :]
[08:33] <soren> apw: I do have an external monitor, but I switch between it and the laptop's LCD a couple of times a day, and I don't see this happen at all.
[08:33] <RAOF> apw: That's an *awesome* bug.  That I've not experienced with my external monitor and oneiric.
[08:34] <apw> soren, yeah i suspect if i unplug and replug it'll get fixed 
[08:34] <soren> apw: If only there was a way to find out...
[08:34] <apw> the one on the LCD is fine, its just my external
[08:34] <soren> :p
[08:34] <smb> Great, no changing time and date settings today... at least not with the ui
[08:50] <c2tarun> My kubuntu's performance is getting poor when I try to run my laptop on battery. Is there any way to improve it. I tried everything from power management and everywhere but, its not improving. I think its a kernel issue. Can anybody please help?
[08:52] <jjohansen> c2tarun: that is rather vague, you need to collect more information
[08:52] <c2tarun> jjohansen: what kind of information?
[08:54] <jjohansen> c2tarun: well, some firm performance figures showing how things are slower would be good
[08:54] <jjohansen> a bug with logs, etc
[08:55] <jjohansen> maybe some runs with powertop, latencytop, ..
[08:55] <c2tarun> jjohansen: hmm... how can I get log for getting system slow? I can feel it, opening any window and closing it, switching workspaces, openening widgets, everything is getting slower. :(
[08:58] <jjohansen> c2tarun: right, but your feel of things getting slower isn't something we can debug against
[08:59] <jjohansen> filing a bug, that collects the logs and system information gives some basic information to start from.
[08:59] <c2tarun> jjohansen: yeah, you are right, actually I was looking for something that can enhance my system's performance and not fix a bug.
[08:59] <ohsix> c2tarun: do you see intel_idle in the output of lsmod?
[09:01] <c2tarun> ohsix: nope here is pastebin for my lsmod http://paste.kde.org/75217/
[10:09] <jjohansen> g'night
[10:11] <apw> ppisati, how goes your cve fun
[10:12] <ppisati> apw: it goes :)
[10:12] <ppisati> apw: i'm piling up the patches
[10:12] <apw> ppisati, heh, how far through are you?
[10:14] <smb> apw, If you do not hear us you are buggy
[10:14] <apw> arrg
[10:14] <apw> now i hear
[10:20] <smb> yep
[10:47] <ppisati> apw: down 15, i'm applying all of them now
[10:48] <apw> ppisati, nice ... that'll help out stats
[10:48] <ppisati> apw: yep
[10:48] <ppisati> apw: i really didn't know of the existence of that page...
[10:49] <apw> ppisati, heh no worries, that page is really the stable teams input for cves
[10:49] <apw> and until karmic went dead fsl-imx51 at least was a rebase onto that, now its not we need some other solution
[10:50] <apw> and you are the solution there, so its a new requirement just since release
[10:50] <apw> so you not knowing isn't supprising
[11:08] <ppisati> kernel is compiling
[11:08]  * ppisati rushes out to het some food
[11:13] <ghostcube> hi friend of mine has a 10.04 lts server with ecc ram and gets spammed by edac mc0 errors is there any solution
[11:13] <smb> ghostcube, Yeah, better RAM
[11:13] <ghostcube> heh
[11:14] <smb> But really, had the same and had to find the module that was faulty. 
[11:15] <smb> Those messages tell you that there is a problem. Usually like correctable ecc errors. There is some hints about the location too, but it can be a bit tedious to map them to the physical slots
[11:17] <ghostcube> seems to be an edac bug
[11:17] <ghostcube> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/367774
[11:17] <ubot2> Launchpad bug 367774 in linux "EDAC spam in dmesg, edac-utils shows no erros" [Undecided,Expired]
[11:17] <ghostcube> his ram isnt faulty he testet it
[11:30] <apw> ghostcube, in that bug all of the users seem to have indicated that quick boot was not clearing the memory out leading to the eec errors
[11:30] <apw> somone has to write to all of ram before eec can be safely enabled
[11:35] <ghostcube> yeah he tried this, but its still spamming errors its strange 
[11:35] <ghostcube> one hint is just to blacklist edac modul
[11:35] <apw> yep stops reporting but they are still there i am sure
[11:36] <ghostcube> nope, he tried debian 6 hdd and bootet in slow boot now no more errors
[11:36] <ghostcube> hmm
[11:37] <apw> and does that kernel even have the edac module for his h/w ?
[11:37] <apw> they are quite new in some cases
[11:37] <ghostcube> its a asus pb5v
[11:38] <ghostcube> p5bv
[11:40] <ghostcube> http://buttersideup.com/edacwiki/Uninitialized_ECC_bits  found this
[11:42] <ghostcube> https://bugzilla.redhat.com/show_bug.cgi?id=564274  and this
[11:42] <ubot2> bugzilla.redhat.com bug 564274 in kernel "fake EDAC errors on i3210" [High,Closed: notabug]
[11:42] <ghostcube> ok seems to be a bios prob
[11:43] <apw> ghostcube, thats what it sounds like
[12:14] <cjwatson> could somebody advise me on what to do about bug 785394?  reserving 128MiB of RAM seems like an awful lot, and I wonder why the kdump kernel is taking quite so much memory to boot
[12:14] <ubot2> Launchpad bug 785394 in grub2 "Hard-coded crashkernel=... memory reservation in /etc/grub.d/10_linux is insufficient" [Undecided,New] https://launchpad.net/bugs/785394
[12:23] <cjwatson> It looks like it's OOMing while unpacking the initramfs ... hmm
[12:23] <cjwatson> $ zcat /boot/initrd.img-2.6.38-9-generic | wc -c
[12:23] <cjwatson> 44324864
[12:35] <apw> cjwatson, the kernel en-toto is pretty huge, initramfs coming straight out of ram, both compressed and uncompressed
[12:36] <apw> cjwatson, do we use a standard kernel for the kexec kernel?  ie. do we not strip the initramfs at all
[12:38] <cjwatson> I was hoping one of you lot would know
[12:39] <apw> i can have a look
[12:39] <cjwatson> it does have to mount the rootfs, so it seems to me that it would have many of the same requirements
[12:39] <apw> cjwatson, and the complaint there is that it won't fit into 64M in that bug
[12:39] <cjwatson> though maybe we could use MODULES=dep for the kdump initramfs, if it's possible for it to be different
[12:40] <apw> which with a 40M initrd, ... its not going to i suspect
[12:40] <apw> cjwatson, right that was what i was thinkng, you kexec initrd really doesn't need to be portable
[12:41] <cjwatson> I don't know if it's possible for it to be separate, though
[12:41] <apw> cjwatson, me either, shall i take a look ?
[12:41] <cjwatson> if you could, that'd be great
[13:08] <ppisati> lucid -proposed is stuck due to ec2 bug, right?
[13:08] <ppisati> i mean linux (2.6.32-32.62)
[13:08] <ppisati> https://launchpad.net/ubuntu/lucid/+source/linux/+changelog
[13:36] <herton> ppisati: yes, was put on hold because of ec2 issue
[13:44] <ppisati> herton: i see
[14:29] <apw> cjwatson, so its is a simple configuration to change which kernel kdump uses, defaulting to the current kernel, whats not so obvious is how we might maintain more than one initrd for a kernel via the normal mechanisms.   i don't know if we could consider having on fixed kernel for kdump, as using the likely crashing one to dump itself is a little scarey
[15:11]  * apw pops out to collect a bag
[16:37] <ppisati> what was the script that updated the changelog?
[16:37] <herton> ppisati: debian/rules insertchanges ?
[16:38] <ppisati> herton: i mean, the kteam tools
[16:38] <ppisati> herton: i think it's startnewrelease
[16:38] <JFo> I'm going to take a bit of an extended lunch. need to run some errands and check on my truck in the shop.
[16:38] <JFo> may not be gone very long, but wanted to let you know anyway :)
[16:38] <herton> ppisati: ah sorry, should be maintscripts/maint-startnewrelease
[16:39] <ppisati> herton: yes, that one
[16:52] <ppisati> herton: but it doesn't update the changelog
[16:52] <ppisati> uhm
[16:52] <herton> ppisati: yep, it just adds a boilerplate and insertchanges updates it after you commit your changes
[16:53] <ppisati> so...
[16:53] <ppisati> the process is
[16:53] <ppisati> startnewlrelease
[16:53] <ppisati> debian/rules insertchanges
[16:53] <ppisati> and then a commit UBUNTU: Ubuntu-2.6.X-Y.Z
[16:56] <herton> yep, from what I read from KernelMaintenance page in wiki
[16:56] <ppisati> ah, the wiki... :)
[16:56] <herton> ppisati: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
[17:09] <herton> but it seems to me we should always use maint-startnewrelease instead of startnewrelease rule, correct? (at least that is the procedure on stable proposed releases)
[17:10] <ppisati> herton: yep
[17:10] <ppisati> herton: maint-startnewrelease
[17:10] <ppisati> herton: apply stuff
[17:10] <ppisati> herton: and then close it
[17:10] <ppisati> i will tatoo these steps on my right arm so i won't forget it anymore
[17:11] <herton> hehe
[17:11]  * herton --> lunch
[17:11] <smb> herton, ppisati maint-startrelease also gets you the abi files and applies them to the commit
[17:27] <ppisati> sorry, but still can't get my changelog updated
[17:30] <ppisati> e.g. http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=538abd32e3b8b1fb152927c9dfbd7b43f301e377
[17:30] <ppisati> i miss the modification to changelog that this commit has
[17:30] <ppisati> i know, i did it in the past
[17:30] <ppisati> but i don't remeber how i got the stuff there
[17:31] <ppisati> is there some magic script? or what else?
[17:31] <bjf> ppisati, i can walk you through it
[17:32] <ppisati> bjf: ok
[17:32] <ppisati> i know i did it
[17:32] <bjf> ppisati, did the "maint-startnewrelease" do the right things?
[17:32] <ppisati> yep
[17:32] <apw> ppisati, thats the fdr insertchanges  t
[17:32] <bjf> did you do a "fdr insterchanges" ?
[17:32] <apw> that makes those changes
[17:32] <apw> -  CHANGELOG: Do not edit directly. Autogenerated at release.
[17:32] <apw> -  CHANGELOG: Use the printchanges target to see the curent changes.
[17:32] <apw> -  CHANGELOG: Use the insertchanges target to create the final log.
[17:33] <ppisati> yes
[17:33] <apw> the key lines are those and need to be there
[17:33] <ppisati> that's what i get
[17:33] <apw> also does fdr printchanges print anything
[17:33] <ppisati> nothing
[17:33] <ppisati> empty
[17:33] <apw> as that is what gets inserted instread
[17:33] <ppisati> printchanges i mean
[17:33] <apw> ok then that likely means your previous commit has the wrong format
[17:33] <apw> printchanges looks backwards for the UBUNTU: Ubuntu-xxxx line
[17:33] <apw> and if thats not formatted right in the previous version it breaks
[17:34] <ppisati> the tree is this one:
[17:34] <ppisati> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=shortlog;h=refs/heads/fsl-imx51
[17:34] <apw> commit 861bf6eb84e2b72966a881ce523661ae850b43ef
[17:34] <apw> Author: Tim Gardner <tim.gardner@canonical.com>
[17:34] <apw> Date:   Thu Mar 10 01:57:49 2011 -0700
[17:34] <apw>     Ubuntu-2.6.31-608.25
[17:34] <apw> and indeed its wrong
[17:34] <ppisati> shall i... amend it?
[17:34] <apw> it is missing the UUBNTU: prefix
[17:35] <apw> i would ammend it yes
[17:35] <ppisati> ok
[17:35] <ppisati> let me try...
[17:35] <apw> bjf, you have a script for checking a tree tip has been correctly closed i think?
[17:36] <bjf> apw, yes, "verify-release-ready"
[17:36] <apw> ppisati, ^^ that is a good thing to use
[17:36] <ppisati> ok
[17:37] <ppisati> any way to amend the -16 commit?
[17:37] <apw> w
[17:37] <apw> ppisati, which one ?
[17:37] <ppisati> the broken one
[17:37] <apw> oh you mean the one which is 16 back from HEAD
[17:37] <ppisati> yes
[17:37] <apw> git rebase -i HEAD~16
[17:37] <apw> then change the first line to edit
[17:38] <apw> then git commit --ame
[17:38] <apw> then git rebase --cont
[17:38]  * ppisati tries...
[17:42] <bjf> ppisati, is that commit on master branch and was it in a release?
[17:42] <smb> sconklin, Hey Steve, you still need me to write a request to revert that max_pfn_mapped patch for Lucid and Maverick or will it be done just based on the failure
[17:43] <apw> bjf, its on an fsl-imx51 branch
[17:43] <bjf> apw, yes, but if that commit was part of a release, that history shouldn't be re-written
[17:43] <sconklin> smb I already reverted it for both
[17:43] <smb> sconklin, Ah ok good
[17:43] <apw> bjf, that specific commit is safe as it is now in a tag
[17:44] <bjf> ok
[17:44] <apw> and all of our arm kernels are rebase anyhow
[17:44] <apw> so that having a non-linearaity isn't a big deal
[17:47] <ppisati> everytime i close a release
[17:48] <ppisati> i need a tracking bug?
[17:48] <ppisati> i mean
[17:48] <ppisati> since there's a big pile of cve
[17:48] <ppisati> i wanyed to do it in steps
[17:48] <ppisati> so, now i'm doing this
[17:48] <ppisati> with some cves
[17:48] <ppisati> and i'll ask for a pull
[17:48] <ppisati> but i don't want an upload
[17:49] <apw> well we don't have to close the release to do a pull of it
[17:49] <ppisati> cool :)
[17:49] <apw> so just do the startnewrelease, add gthe patches
[17:49] <apw> and then just ask for a pull
[17:49] <ppisati> ok
[17:49] <apw> just leave it open
[17:49] <ppisati> k
[17:49] <ppisati> so, everytime we close, we upload and thus i need a tracking bug
[17:50] <apw> yeah thats a pretty accurate
[17:50] <bjf> ppisati, https://wiki.ubuntu.com/KernelTeam/StableHandbook/StablePatchApplication
[17:50] <bjf> ppisati, that explains all the steps
[17:50] <apw> ppisati, but for the meantime we can leave it not closed,
[17:50] <apw> we often don't have it closed in the repo
[17:50] <apw> with things sitting there waiting for more before the release gets closed
[17:51] <ppisati> ok, so let's see it the other way around
[17:51] <ppisati> i have a backlog of...
[17:51] <ppisati> 50? 60? patches waiting to be applied
[17:52] <ppisati> whats' the best policy?
[17:52] <apw> well you are applying about 15 a day
[17:52] <ppisati> s/policy/strategy/
[17:52] <ppisati> yes
[17:52] <apw> i would apply them as i go, pushing the branch to zinc in my public repo ready for pulling
[17:52] <apw> then say weekly ask for it to be pulled
[17:52] <apw> when _all_ are applied we can close it and give it stable for handling out
[17:53] <ppisati> so the there will be just one big test session at the end
[17:53] <apw> yeah most of these cves are 1) generic and 2) already tested
[17:53] <apw> so the chance of regression for any which are just cherry-picks is pretty low
[17:53] <ppisati> ok
[17:53] <ppisati> deal
[17:53] <apw> i would test them at the end and cross my fingers :)
[17:54] <ppisati> actually i don't have the hw
[17:54] <ppisati> so from time to time i compile a kernel and "ship" it to someone to do, at least, a boot
[17:54] <apw> i would probabally produce one weekly as i went and ask #arm to test it
[17:54] <ppisati> k
[17:54] <apw> as it takes hours to build :(
[17:55] <ppisati> well
[17:55] <ppisati> i do it in about 15/20 minutes
[17:55] <ppisati> i cross compile
[17:55] <ppisati> all the other arm guys do native compilation
[17:55] <ppisati> but it's really too slow
[17:55]  * ppisati start a new recompilation...
[18:06]  * apw wanders off to the pub
[18:19]  * smb wanders off into the weekend
[18:33] <JFo> <-jealous :)
[20:34] <kees> apw: so, what happened with CVE-2010-3880 and maverick, exactly?
[20:34] <ubot2> kees: net/ipv4/inet_diag.c in the Linux kernel before 2.6.37-rc2 does not properly audit INET_DIAG bytecode, which allows local users to cause a denial of service (kernel infinite loop) via crafted INET_DIAG_REQ_BYTECODE instructions in a netlink message that contains multiple attribute elements, as demonstrated by INET_DIAG_BC_JMP instructions. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3880)
[20:44] <bjf> kees, it's in the changelog as having been fixed, will look at the commit
[20:46] <bjf> kees, the commit is there, it points at bug 711865
[20:46] <ubot2> Launchpad bug 711865 in linux-fsl-imx51 "CVE-2010-3880" [Undecided,In progress] https://launchpad.net/bugs/711865
[20:46] <bjf> kees, do you believe there is an issue with the commit?
[20:57] <kees> bjf: I don't know, apw's script flipped it from released to "pending" with no version
[21:02] <bjf> kees, _that_ i have no idea about
[21:07] <kees> bjf: yeah, I'm scratchin' my head too :) it was the only thing I saw in the latest merge that looked funny
[23:29] <Quintasan> Um, hi there. I'm running Kubuntu Natty and I'm experiencing strange freezees (seemingly at random but mostly occur when playing a video). The video stops, I can kill the player, but if I try to type someting in for ex. konsole it doesn't respond, then everything stops responding (can't run anything, can't close anything) so I can only do SysRq + RSEIUB -> http://paste.ubuntu.com/613947 <- kernel log from before the freeze, what is 
[23:29] <Quintasan> exatcly going wrong there?