=== sconklin is now known as sconklin-gone
=== kamalm is now known as kamalm-away
[05:13] <h00k> I think I'm having a kernel problem in Lucid and I figured this be the qualified place to ask, can I post my dmesg where I started to have problems?
[05:17] <h00k> It may be related to the current x problem, but I'm using the proprietary driver
[05:19] <persia> hook: You'd do best to file a bug with all the info, and then ask about the bug.
[05:19] <persia> saves fussing with pastebints for a selection of commonly-required information.
[05:21] <h00k> persia: I'll try to get as much info as possible, thanks.
[05:22] <h00k> persia: if I can get this usable enough, I may have to restart
[05:22] <h00k> persia: well, what would be useful at this time if it's locking up?
[05:22] <h00k> if I restart, I have a feeling it'll take a few hours to get it like this again
[05:22] <persia> `ubuntu-bug linux` usually sends a decent default set of data.
[05:22] <h00k> I'd like to try and grab as much as I can atmoment
[05:23] <h00k> right, I'll try to grab a copy of my free mem, too, because I think it's mem related, the kernel doesn't seem to be able to allocate anything and that's why it's severely thrashing
[05:27] <h00k> is there anything special that would be needed when it's in the 'thrashing' stage? I was able to get $ free from an ssh session I opened
[06:13] <jk-> h00k: might be https://wiki.ubuntu.com/X/Testing/GEMLeak
[06:14] <h00k> jk-: I considered that, but I am using the proprietary nvidia driver
[06:14] <jk-> ah! it
[06:14] <h00k> and the GEM leak does not apply, apparently
[06:14] <jk-> 's probably not that then :)
[06:14] <h00k> but this is most-definitely reproducable on this machine
[06:15] <h00k> I wrote up a nice descriptive report but edge decided to lose it. *sigh* so I'm writing it up with edge redirection disabled.
[06:17] <h00k> now to see if it saved all the other information ubuntu-bug grabbed. Yes.
[06:17] <h00k> cool.
[06:18] <h00k> bug 56818
[06:18] <ubot3> Malone bug 56818 in ubiquity "Installer Crashed (dup-of: 55019)" [Undecided,Confirmed] https://launchpad.net/bugs/56818
[06:18] <ubot3> Malone bug 55019 in ubiquity "Edgy installer crashes when installing on VMWare" [Undecided,Fix released] https://launchpad.net/bugs/55019
[06:18] <h00k> bug 568818
[06:18] <ubot3> Malone bug 568818 in linux "Lucid memory leak, proprietary driver" [Undecided,New] https://launchpad.net/bugs/568818
[06:18] <h00k> turns out I need sleep.
[06:20] <h00k> In there, I see 'Failed to allocate SKB buffer with GFP_ATOMIC. Only 0 free buffers remaining.'
[06:23] <h00k> So, I guess we'll see what happens. Thanks for your time.
[08:40] <amitk> ericm__: Yes things that appear in only one config also show up in common, That was something apw implemented
[08:41] <amitk> ericm__: so to start a new flavour, it is best to copy the config of an existing flavour and the make changes
[08:45] <apw> you can also put a complete config at the leaf and fdr genconfigs and the right thing will happen
[08:52] <ikepanhc> apw: sorry missing some messages, you just talk about put the complete config on the leaf, do you mean put them on debian.xxx/configs/<arch>/config.<flavour>?
[08:52] <apw> smb, so i assume you are back in your normal location?
[08:53] <smb> apw, For the moment, yes
[08:53] <apw> ikepanhc, yeah if you put a complete config there it will get merged in correctly
[08:53] <ikepanhc> thanks a lot :)
[08:53] <apw> generally not a good idea as you won't get the common overrides that way
[08:53] <apw> so it needs thought
[08:54] <amitk> apw: how so?
[08:55] <apw> if you put a complete config in the leaf it will ensure the config as merged will generate exactly that config
[08:55] <apw> so if you take a vendor defconfig it still won't have 'CONFIG_UBUNTU_NEEDS" things turned on 
[08:56] <amitk> apw: starting from a vendor config is painful from the POV of ubuntu'ification
[08:56] <amitk> vendor configs are very sparse
[08:56] <cooloney> can I talk here
[08:56] <amitk> I typically start from the closes in-tree config we have
[08:56] <EricMiao> amitk, that's true, usually without most drivers, only necessary
[08:57] <cooloney> perfect
[08:57] <amitk> cooloney: no you can't :-p
[08:57] <ikepanhc> cooloney: I heard you
[08:57] <apw> indeed
[08:57] <EricMiao> amitk, and those drivers are mostly built-in
[08:57] <apw> just trying to make it clear what putting it there means
[08:57] <apw> it means 'make the config exactly this' not 'base the config on this'
[08:57] <amitk> so for omap, I picked mvl or fsl config, copied it to omap
[08:58] <amitk> and then changed the fsl-specific to omap-specific stuff
[08:58] <apw> amitk, what we should have done really is work out which items we must have and put those in a list
[08:58] <apw> so that you could put a vendor config in there, shove the must have list at the bottom, and run updateconfigs
[08:58] <apw> and have a half way sensible starting point
[08:59] <amitk> apw: agreed. That is not very obvious (shoving at bottom overrides previous settings) but useful
[09:00] <apw> there is now actually an debian.foo/config/OVERRIDES file now, which if you add things there they get forced into the config
[09:00] <apw> (something like that need to check)
[09:00] <amitk> apw: so all the enfore stuff should be there then
[09:00] <apw> which lets you set a few options for all configs when doing updates
[09:01] <apw> its not intended for long term use, but perhaps it should be
[09:01] <apw> no it can't be as some are 'programatic' ... different per arch
[09:01] <apw> though we could generate it from the enforce perhaps ... i'll add that to the config thinking list
[09:02] <amitk> apw: to me, enforce is more intuitive. It warns me about missing stuff and forces me to fix my configs.
[09:02] <amitk> OVERRIDES will do so behind my back
[09:02] <amitk> we just need to populate enforce a bit better
[09:03] <persia> I'd like to see some set of forced defaults that match the core userspace requirements (mountall, udev, installer, etc.): that would save a number of per-arch (or per-kernel) bugs we encounter.
[09:03] <apw> amitk, OVERRIDES is not for use in the general case it is for the updates case
[09:04] <apw> 'i want to change foo' 
[09:04] <apw> if you put it in OVERRIDES and run updates configs it gets set everywhere
[09:04] <apw> otherwise you have to add it to all leaf files and run update
[09:04] <apw> which is harder
[09:04] <amitk> apw: so you don't 'commit' changes to OVERRIDES?
[09:04] <EricMiao> apw, so it's actually something common to all flavors?
[09:04] <apw> persia, if people can tell us those linkages we have a way to record them
[09:04] <EricMiao> or enforced to all flavors
[09:05] <apw> amitk, right its purley a convienience for doing global changes, and is used by the mainline builds for that
[09:05] <amitk> persia: we have an 'enforce' script now, that checks for some of these settings. We're populating them as we find more stuff
[09:05] <apw> i use it when i do rebases for example
[09:05] <amitk> understood
[09:05] <persia> apw: Heh, well understood.  I'll see if I can get a partial list.  Too many folks seem to assume the i386/amd64 configs apply everywhere.
[09:05] <apw> EricMiao, its designed to let it be easy to override a setting to something when we need to change it, nothing more it should not have any content on commit ever
[09:06] <apw> persia, yep
[09:06] <apw> but yes the config enforcer is for exactly this.  it contains the list of options we must have, and human commentry as to WHY so that we don't lose them over time
[09:06]  * amitk suspects we need a README in our buildsystem now
[09:06] <apw> amitk, yeah i suspect so
[09:07] <amitk> apw: to your paper notes
[09:07] <amitk> :)
[09:07] <apw> heh they are all on the sprint wiki now
[09:07] <apw> i'll add that too
[09:10] <amitk> http://paste.ubuntu.com/420890/ <--- another enforce apw
[09:11] <persia> I'm thinking http://launchpadlibrarian.net/45034888/buildlog_ubuntu-lucid-powerpc.qemu-kvm_0.12.3+noroms-0ubuntu8_FAILEDTOBUILD.txt.gz might be a kernel config/patch issue.  Anyone able to confirm that it is/isn't? (missing prototype: when I search for the prototype, I get mail archives with kernel patches)
[09:11] <apw> amitk, yes i was literally just opening an editor to add that
[09:12] <apw> please push it to kernel-team@ and i'll get it applied
[09:13] <apw> persia, depends if that is a kernel function ... /me looks
[09:14] <apw> persia, does that build for other arches?
[09:14] <persia> Yep.
[09:15] <persia> Works on i386/amd64/armel
[09:15] <persia> Note that there might be a missing patch that never got upstream: I just wanted someone more familiar to confirm if it was a kernel thing.
[09:17] <apw> does powerpc even spport kvm
[09:20] <persia> Uhh, sometimes.
[09:20] <persia> Depends on the chip.  440s and 970s work fine.
[09:20] <persia> real POWER processors have something else, and kvm upstream doesn't target those.
[09:20] <persia> And qemu works on a variety of stuff even when KVM isn't available.
[09:24] <apw> kvm_arch_handle_exit doesn't seem to be a kernel thing at all
[09:24] <apw> so i assume it is a local arch specific thing which is missing
[09:25] <persia> Then just false-positive based on mail-threads.
[09:25] <persia> Thanks.  I'll go hunt it somewhere else.
[09:25] <apw> i suspect you should find it defined in the package for other arches
[09:36] <apw> smb, i am seeing people complaining about sd cards as root and not working on reboot, do you see that on your card based installs?
[09:37] <smb> apw, That was one of the things I wanted to test today, after having upgraded to the latest code base (including the official kernel)
[09:37] <smb> apw, Oh wait. Slightly different problem. Ok, I can check that too. But I think that has worked
[09:38] <apw> sounds good
[09:38] <apw> smb, yesterday i put together some code to upload pre-proposed kernels automatically from the tree tips ... enabled for lucid only right now
[09:39] <smb> apw, Ah, thats why there are these uploads I noticed
[09:40] <apw> yeah ... the ones with the huge preNNNN numbers are the automated ones
[09:40] <apw> well 'one' so far
[09:41] <smb> Right, there was another one with a more manual number.
[09:42] <apw> yeah that was me, starting to do them manually
[09:42] <apw> as i decided we would have caught the EC: issue if there was a lucid pre-proposed 
[09:42] <apw> so i think its worth having and worth being automatic if we can
[09:42] <apw> hense the experiment
[09:43] <smb> We definitely want such a thing soon / after release
[09:45] <apw> well i have lucid doing it 'now'
[09:45] <apw> basically if the tip is UNRELEASED and it changes, it gets uploaded
[09:45] <apw> i assume if its is released that its in the release pocket
[09:45]  * apw wakes smb up
[09:49] <soren> persia: The problem isn't the missing prototype.
[09:50] <soren> persia: That's just a warning.
[09:51] <persia> soren: Ah, but ->-server :)
[11:10] <amitk> EricMiao: was the kexec fix a backport from 2.6.33?
[11:14] <EricMiao> amitk, I think so - some of them are already upstreamed
[11:39] <amitk> anybody know why I don't need fakeroot to build a kernel anymore in lucid?
[11:40] <amitk> I get the error shown here: http://www.mail-archive.com/debian-glibc@lists.debian.org/msg37588.html
[11:40] <amitk> if I do use fakeroot
[11:52] <apw> amitk, i do all my kernel builds with fakeroot
[11:54] <apw>                         fakeroot debian/rules clean &&
[11:54] <apw>                         fakeroot debian/rules "$build" ||
=== jussi01 is now known as jussi
[12:00] <amitk> i wonder if it has to do with my cross-compiles then?
[12:00] <amitk> CROSS_COMPILE=arm-none-linux-gnueabi- debian/rules binary-omap
[12:01] <persia> apw: Does `debuild -b` not just work for you?
[12:02] <amitk> persia: debuild -b will build _everything_. debian/rules are useful to do only a single flavour build
[12:02] <persia> Ah, $build is a flavour.  Yeah, that makes sense :)
[12:05] <apw> persia, right else it takes several hours to make a kernel, nightmare
[12:05] <persia> Yeah.
[12:09] <AStachowski> Hi guys. Just wanted to thank you for your hints for preparing a custom ppa kernel. https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
[12:10]  * AStachowski was to stupid to read properly (bash debian/scripts/misc/getabis)
[14:01] <tgardner> smb, 544254 has been maked fix released
[14:02] <smb> tgardner, Oh, hm. Somehow I had the impression there were replies about still having problems but maybe I dreamt
[14:06] <smb> tgardner, I must have been dreaming about that one. Well better that way.
[14:06] <tgardner> smb, np
=== sconklin-gone is now known as sconklin
=== kamalm-away is now known as kamalm
[16:58] <achiang> so, i have two bugs that i think are SRU candidates for lucid.
[16:59] <achiang> https://bugs.launchpad.net/oem-priority/+bug/532374
[16:59] <ubot3> Malone bug 532374 in oem-priority "Lenovo Thinkpads with Core i5 and i7 suspend/resume (with kernel oops) once then fail horribly on next suspend" [Critical,In progress] 
[16:59] <achiang> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/566149
[16:59] <ubot3> Malone bug 566149 in linux "Lucid: No USB after resume on Thinkpad X201, T410, T510, W510" [Undecided,New] 
[16:59] <achiang> the second one has a patch that has been accepted by maintainer ; not yet pushed to linus but will be soon ; and already got a verbal ack from gregkh about taking it into -stable
[17:00] <achiang> should i wait until landing in -stable before sending a patch to ubuntu-kernel-list?
[17:00] <achiang> and the first one is likely in the same boat, but the maintainer is AWOL for a bit. :-/
[17:01] <smb> achiang, When they land in stable (and I think I saw some) they will just get pulled from there
[17:02] <achiang> smb: huh -- i was under the impression that even with -stable, we still cherry-picked from that tree
[17:02] <achiang> iow, not everything in -stable goes directly into lucid?
[17:02] <achiang> smb: is that incorrect?
[17:02] <smb> achiang, yes
[17:03] <smb> achiang, We will pull everything from stable in 
[17:03] <achiang> smb: ok, so lucid is a superset of stable, thanks
[17:03] <achiang> great, that helps me avoid SRU process. ;)
[17:05] <smb> achiang, If you can, then have BugLink keywords referencing the LPs in them. This helps closing the right bugs automatically when those things come in via stable. ;-)
[17:05] <achiang> smb: sorry, not fully following you. you mean BugLink in the upstream patch commit?
[17:07] <smb> achiang, Yes, if you are the one sending a patch upstream, and you put it in, then its still visible when it comes back via stable. And also it allows people to look at associated bugs too
[17:07] <achiang> smb: ok, too late for the 2nd one, but i can fix up the 1st one since i have to resubmit anyway
[17:09] <smb> achiang, That would be cool. Its quite hard to keep the related bugs up to date otherwise. If you know about something and you see a mail about pulling stable in, I welcome any feedback about which patches might close what bugs, too. :)
[17:10] <achiang> smb: will keep an eye out for the future. for this time, i just assigned both bugs to myself, and will close them when -stable gets pulled into lucid
[17:11] <smb> achiang, Great, thanks.
[17:14] <achiang> smb: BugLink keyword can appear anywhere in commit message? or does it need to be near the top?
[17:14] <achiang> smb: i put it in column 0, but near the bottom of the commit log
[17:15] <smb> achiang, It can be anywhere. It just must be at the start of a line
[17:15] <achiang> great, thanks
[17:15] <smb> Some place it right above the signed-of-by area
[17:17] <achiang> yup, that's what i did
[17:19] <smb> achiang, Thats perfect then
[17:33] <apw> JFo, this bug #496093, am i right in thinking that the backport that the Ricardo's kernel has in it is a 2.6.31 backport?  would not that mean that an LBM install should be as good?
[17:33] <ubot3> Malone bug 496093 in linux "[lucid] rt2860 frequently fails to connect to mixed mode WPA/WPA2 secured wireless networks" [Unknown,Confirmed] https://launchpad.net/bugs/496093
[17:37] <tgardner> apw, bug #567016
[17:37] <ubot3> Malone bug 567016 in linux "Wireless won't work on Lenovo Thinkpad T510" [Undecided,New] https://launchpad.net/bugs/567016
[17:37] <apw> tgardner, good as long as we arn't looking at the same thing
[17:38] <tgardner> apw, its a wretched vendor driver
[17:38]  * apw sighs ... we get so panned for this crap, and its not even in our control
[17:39] <tgardner> I'm gonna try and update it. lots of changes wince we incorporated it
[17:39] <apw> is that an ubuntu driver or something?
[17:39] <tgardner> apw, yep - ubuntu/rtl8192se
[17:40] <apw> damn
[17:42] <apw> tgardner, don't suppose you have one to test on
[17:42] <tgardner> apw, no - that would be too easy
[18:03]  * apw notes it is beer + 1 o'clock
[18:03] <tgardner> apw, get lost. I'll see you Monday
[18:18] <bjf> apw, what's that synchronization software you use to keep your home dirs in sync?
[18:19] <apw> bjf, unison
[18:19] <apw> tgardner, yeah see you then for some catchup beering
[18:19] <bjf> apw, right! got to go figure that out
[18:22] <apw> let me know when you are getting in
[18:22] <tgardner> apw, I'll be at Millbank mid-afternoon
[18:24] <apw> just in time :)
=== yofel_ is now known as yofel
=== sconklin is now known as sconklin-gone