[01:21] smb: thanks for "breaking it down" to me I find that helpful, those messages are confusing to me without the explanation === bjf is now known as bjf[afk] [03:36] ping? [03:36] could use advice about getting more detailed debug info [06:19] http://qdb.us/224378 [06:24] Thought you guys might enjoy that one a little. [06:37] well, this story tells us that installing openssh-server on my desktop is very important === amitk-afk is now known as amitk === smb` is now known as smb === doko_ is now known as doko [11:37] cking_: is there a reason why you didn't include this patch in Maverick's kernel? http://pastebin.ubuntu.com/507154/ [11:59] tseliot, 'cos it's only just been accepted upstream, and I was waiting to see if it was the best solution [12:00] it cycled a few changes and is expected to land mid october [12:01] cking_: ok, is the patch fine as it is on pastebin? [12:02] for 2.6.35, that is [12:02] nope, I will submit it as a SRU once I'm sure it's landed in acpica [12:04] cking_: I'm asking only because I'd like to include it in my kernel (not in maverick). Can you point me to a more updated version of the patch, please? [12:05] tseliot, I'll mail you the patch [12:05] cking_: thanks a lot [12:07] sent === xfaf is now known as zul === ivoks-afk is now known as ivoks === bjf[afk] is now known as bjf [14:06] going to be out a bit this morning... serious insomnia issues last night. medication finally deciding to kick in it seems [14:06] only 8 hours late [14:23] pmatulis, Re: LVM, tried a few things with the current lucid kernel and lvm and did not see any issues. There has been someone mentioning an error message which would be fixed by a patch currently also missing in lucid. But I was not able to reproduce it. [14:35] ogasawara, tgardner, hey [14:36] ogra_ac, dude [14:36] tgardner, dod cooloney already contact you ? [14:36] *did [14:37] ogra_ac, about what? [14:37] we have an x-loader change for omap4 that requires an in-sync kernel upload [14:37] wiht a small patch [14:37] tgardner, yeah, just wanna talk with you [14:37] ogra_ac, we need to make sure the audio patch will upload [14:37] release team is fine with omap4 changes at this time (we made that clear in advance) [14:37] JFo: Where is the most recent top50? [14:37] cooloney, I was just about to upload your ASOC changes. [14:38] the audio patch can go in worst case as sru its not as critical as the booting [14:38] tgardner, yeah, i was also just got another important patch fixing the display issue today [14:38] will post it out soon [14:38] tgardner, hold on then, we just got another (way smaller) patch from TI Nice [14:39] cooloney, ogra_ac: I've pushed to the git repo, but haven't uploaded. I'll just wait until I see your next patch set? [14:40] tgardner, thanks a lot. please wait for a while for my post [14:40] cooloney, will do [14:40] tgardner, thanks a lot, man [14:40] * ogra_ac hugs tgardner [14:40] ogra_ac, no hugging in the kernel team. [14:41] we let dholbach take care of all our hugging duties :) [14:43] lol === xfaf is now known as zul [14:48] I think we should have a prettier 'hugger' [14:48] tgardner: Where is the latest and greatest Top50? [14:50] * cooloney think kissing is more popular than hugging in kernel team. lol [14:50] smb: ok. fyi, henninge is the warthog that was bitten [14:53] cooloney: Remind me not to share a room with you at sprint [14:53] apw: Top50? [14:54] Someone, anyone? [14:54] I have this one: http://reports.qa.ubuntu.com/reports/ogasawara/kernel-buglist-top50.html [14:54] But it appears to be out of date: May 26 2010 0:18 UTC [14:55] lag: http://reports.qa.ubuntu.com/reports/jfo/kernel-Top50.html [14:56] That's better [14:56] Thanks Brad [14:56] lag: look at: https://wiki.ubuntu.com/Kernel/Tagging [14:56] lag, from there is the link to what needs to be reviewed as well as the top 50 [14:57] Lovely, thanks! [15:10] diwic, so what would you propose wrt sound on omap4/panda ? [15:11] do you think calling alsactl init is to hackish ? [15:12] * ogra_ac thinks its the least ugly workaround [15:13] ogra_ac, are you running pulseaudio at all? [15:14] diwic, all i do is put the file into /usr/share/alsa/init, apply the one line patch to 00main and put alsactl init into rc.local (so it gets executed on boot) [15:14] the whole rest of the system is completely unmodified [15:14] so yes, pule works fine [15:14] *pulse [15:15] note that all sound is compiled in in this kernel [15:15] no modules here [15:15] ogra_ac, so pulse saves and restores volumes, enabling users to change it on the fly. But then it can't handle all the crazy control names this chip has [15:15] right [15:16] and device 0 isnt linked up to a codec by default [15:16] pules only uses device 0 by default [15:16] *pulse [15:16] ogra_ac, so are there any volume controls that pulse actually control? [15:17] ogra_ac, have you written a custom PA mixer profile? [15:17] it controls hw 0,0 once alsa is active [15:17] no [15:17] i didnt touch pulse [15:17] i only initialize alsa [15:17] ogra_ac, I'm just trying to figure out what pulseaudio should do and what alsactl init should do here, to make sure they don't collide [15:17] one of these controls lins hw 0,0 to a codec it seems [15:18] *links [15:18] https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/637947/+attachment/1673694/+files/omap4 [15:18] Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 2) (dups: 1) (heat: 26)" [High,Confirmed] [15:19] (dont ask me which though, i just took TIs .conf file and adapted it to an init file) [15:19] the way TI does it currently is to hack up default.pa [15:20] and to use an amixer shellscript [15:20] ogra_ac, so yes, try alsactl init, that would probably be best [15:20] using the "init way" i dont need to touch pulse at all [15:21] ogra_ac, after that, test if you can modify volume in pulse, that it actually affects playback volume, and that the new volume is remembered across reboots [15:21] * ogra_ac tries to find a way to call it from a udev rule though [15:21] um, that should be easy I think [15:21] diwic, it definitely controls it, i'm not sure its persistent over reboots [15:22] RUN+="alsactl init" [15:22] diwic, well, there is not much info the soundcard exposes, i want thet rule to only affect this card indeed [15:22] heh [15:22] yeah, i know what to do to exec it [15:22] but if i want the rule in libasound2 it needs to be specific enough to not call it for all sound devices [15:23] and there are not many things exposed to udev it seems [15:23] aha, but it should be something in sysfs you could use? [15:23] that would allow me to distinguish the parent device [15:24] prob is that the sysfs tree just uses soc-audio as parent [15:24] I think you usually trigger on /dev/snd/controlC0 [15:24] right [15:24] but thats to general for my taste [15:24] i dont want to call the rule for intel hda :) [15:24] * ogra_ac goes digging [15:25] would you mention at the bug that the alsactl init way looks ok from a sound guy's perspective ? [15:25] (so i can get an sru) [15:26] 80-alsa.rules calls alsa-utils [15:26] yep [15:28] look at /sbin/alsa-utils , function preinit_levels_on_card - seems to be a place where you can put in hacks? ;-) [15:28] heh, thanks [15:29] * ogra_ac tests reboot persistence now [15:32] yay, works fine :) === jj-afk is now known as jjohansen [16:40] tgardner, so if cooloneys patch hits the git tree, feel free to upload, i just pushed the x-loader patch [16:42] ogra: in progress [16:44] tgardner, err, bryan just says its not in the git tree yet [16:45] ogra: like I said, its in progress. I'll get it pushed soon, then upload thereafter. [16:45] ah, it just only hit the ML [16:45] ok, thanks [16:45] * ogra_ac clams down a bit :) [16:45] (calms too) [16:45] tgardner: thanks :-) [16:47] ogra, rsalveti: pushed (you'll need to rebase). I'll upload in a bit. [16:49] tgardner: cool, thanks a lot [16:49] tgardner: we own you a beer for sure [16:50] rsalveti, :) I'm having one as we speak. [16:51] tgardner: oh, I wish I could haha [16:51] but we're at TI [16:51] we're all dressed and behaving well [16:52] rsalveti, I guess thats the advantage of working at home. [16:52] I'm neither dressed, nor do I behave well. [16:52] tgardner: for sure [16:53] hehe [16:59] tgardner, any thoughts on the mail I sent you regarding the 2 slots ? [17:00] * cooloney just crashed his macbookpro, since it is lucid. [17:00] * cooloney is upgrading it to maverick, shame [17:02] manjo, patience lad. I referred it to pgraner. [17:02] :) [17:03] manjo, schedule is not set yet I've got it on the list [17:03] pgraner, thanks [17:11] ah, better do some blueprints myself === amitk is now known as amitk-afk [17:20] * cking_ tries to figure out how much H/W he needs to take to the office tomorrow [17:21] eek, too much [17:21] When bisecting, is there any way to make the builds faster? [17:21] cking_, bring it in a roller bag [17:21] roller bag(s) [17:21] lag, nap while building [17:22] heh, no multi tasking then? [17:22] lag, aren't you using the "--build-faster" flag? [17:22] lag: -j n on make or DEB_BUILD_OPTIONS=parallel=n for parallel builds [17:22] A user has mentioned creating a script which configures the .config for current HW [17:22] Thus only building necessary functionality [17:23] Feasible? [17:24] lag: maybe create some STAMP file in debian build directory [17:24] To do what? [17:24] i was just told before, never tried that [17:25] But what would it achieve? [17:25] tgardner, cking_ or bjf might know that [17:26] lag: do you wanna to just build some specific driver files after your whole building? [17:26] lag, you can rebuild fairly quickly by removing the stamp file [17:26] tgardner: yeah, i mixed them [17:27] tgardner: I have done that in the past, but it won't work for large diff bisecs for ~1yr [17:27] lag: oh, that large change won't help build faster. [17:28] Which is my point [17:28] lag: that's painful. maybe building on our build machine? [17:45] tgardner: Can you install the latest kernel-package on our build machine please? [17:45] lag, wtf are you talking about? [17:45] tgardner: I don't know how to say it any clearer :) [17:46] lag, in a schroot? [17:46] apt-get install kernel-package [17:46] I am currently in an i386 chroot yes [17:46] lag, which schroot? maverick? lucid? [17:47] Maverick please [17:51] lag, installed. [17:52] lag, why are you using this? I'm not particularly interested in supporting make-kpkg [17:53] tgardner: I'm building a Linus kernel [17:55] tgardner: in the cross compiling patch you just pushed into our tree, there is a typo in the comment [17:55] dpk- should be dpkg- [17:55] cooloney, um, what? [17:56] cooloney, I'll get apw to fix it. [17:56] tgardner: np, :) [17:56] cooloney, I really want him to add it the debian commonization [17:57] * manjo sees trouble ahead with Maverick on Toshiba NB305... [17:58] manjo, most toshiba machines are problematic [17:58] yep [17:59] this one especially coz we are hung on splash screen [17:59] cking_, dude, you coming to Millbank tomorrow? [18:01] cooloney, you need some apple juice [18:02] apw, do i need to take care (we're about to leave for lunch) [18:02] ogra_ac, the error is in a comment ... nothing to worry about [18:03] apw, i meant about the apple juice [18:04] ogra_ac, heh no ... === vanhoof is now known as turk` === turk` is now known as vanhoof [18:04] * cooloney likes apple juice, [18:04] cooloney, try it with titos [18:05] tgardner, yep, I'm packing my bags right now [18:05] had a hospital appointment today, so that threw the spanner in the works [18:06] manjo: what's titos? [18:06] cooloney, fine vodka made in Austin [18:06] rats, not enough room for lego auto-finger [18:07] cking_, is it the same spanner apw keeps referring to ? [18:07] apw: for cross compiling my ti-omap4, i just need to run dpkg-buildpackage -B -aarmel? [18:07] manjo, possibly [18:07] manjo: great, man. let's drink tonight. [18:08] :) [18:08] hrm, my 10Kg transformer is too big to pack. [18:10] cooloney, maybe :) [18:11] cooloney, echo "dpkg-buildpackage -B -aarmel"|schroot -c maverick-amd64 [18:11] kernel guys submitting blueprints: stop for a minute please! [18:11] cooloney, turn off tools building [18:11] we need to fix your naming convention [18:11] jcastro, whick kernel guys? smb? [18:12] andy, bader so far. [18:12] I am not doing anything anymore [18:12] jcastro, his name is spelled 'smb' [18:12] but if you're working on them I am sending a mail to -devel in a minute so we don't waste your time [18:12] woo, I'll fix them for you [18:12] * cking_ postpones to tomorrow then [18:13] tgardner and apw, got it, building on server now [18:27] vanhoof, around? [18:32] ok, sorry for the confusion, I've fixed the blueprints, mail sent to -devel explaining it === ppetraki is now known as ppetraki-lunch [19:17] names [19:24] bah, my gigabit ethernet NIC only works at 100 Mbit/s, seems like that's a common & recurring issue with the e1000e driver? :-( [19:29] bjf: ping? [19:29] jcastro, hi [19:29] jcrigby, sorry, hi [19:30] jcastro, just ignore me, nothing to see here [19:30] bjf, in your kernel team notes it says something about queuing patches for Maverick SRU [19:31] jcrigby, which notes are you referring to? and yes we are [19:31] meeting notes from kernel team list [19:31] As mentioned last week, we've been queuing patches for Maverick SRU which includes the latest 2.6.35.5, 2.6.35.6, and 2.6.35.7 stable updates. [19:32] quote^^ [19:32] ah yes, [19:32] but I don't see those in git [19:32] jcrigby, ogasawara, probably has them queued in her personal repo [19:32] is there a different tree for this? [19:33] oh she is here [19:33] jcrigby: yep, not pushed the official Maverick repo in case some last minute patches need to get applied and uploaded I didn't want to have to deal with the hundreds of stable patches [19:33] I was looking for wrong nick [19:34] jcrigby, git:/kernel.ubuntu.com/git/ogasawara/ubuntu-maverick.git [19:34] ogasawara, bfj: ok I see now [19:35] so if I wanted to work ahead I could do a new linaro tree based on that, but of course it might change [19:35] jcrigby: Am actually getting ready to re-base my tree to be against the latest official Maverick tree (had some last minute patches come in this morning that need to go in the day-0 upload) [19:35] so what is target day for day-0 [19:35] ogasawara: is the stable rebasing necessary for ti-omap4, do you think? [19:35] we want to do one last linaro based on your day-0 [19:36] jcrigby: hopefully Oct 10 is the target day for day-0. ie they'll officially release Maverick and then approve the day-0 upload right after. [19:37] ok, thanks [19:38] jcrigby: I'm finishing up some test builds for the day-0 patch set and then will re-push to the official Maverick linux master [19:38] jcrigby: I can ping you when it's ready so you can get a head start [19:39] ogasawara, thanks! [19:40] cooloney: I haven't been touching the ti-omap4 branch unless requested by yourself or others (ie I've not been automatically applying the stable patch sets to the ti-omap4 branch) [19:41] cooloney: and for the most part, I've been letting tgardner maintain the ti-omap4 branch [19:41] ogasawara: yeah, i understand. i will try to rebase stable things after your work. [19:41] cooloney: ack [19:41] cooloney: thanks [19:42] ogasawara: since there are some important arm related fixing in stable releasee === ivoks is now known as ivoks-afk === ppetraki-lunch is now known as ppetraki [21:06] bjf: do you know if you absolutely have to be part of the kernel team to pull something from zinc ? [21:07] mpoirier, depends how you are trying to pull something, but anyone should be able to access git://kernel.ubuntu.com [21:08] will someone from linaro be able to get a pull request hosted on kernel.ubuntu.com ? [21:09] mpoirier, i don't know what the rules are for that but I think so [21:10] bjf: on zinc, under /srv/kernel.ubuntu.com/git/ubuntu/, we only have references for ubuntu trees. [21:11] how hard/feasible is it to add the linaro tree ? [21:14] mpoirier, the linaro tree is a topic branch in the maverick tree [21:16] bjf: ti-omap4 is also a topic branch in maverick [21:16] mpoirier, you are correct [21:16] bjf: and they have to go through the SRU process if they want to add something in there. [21:16] mpoirier, still don't get your point [21:17] bjf: when tim and I talked about the ftrace feature, we agreed to put it in the linaro tree. [21:18] bjf: that is all I want to do. [21:19] bjf: I was under the impressin that having a pull request for the linaro topic branch in ubuntu would subject me to the SRU process. [21:19] bjf: and if I used their tree, I wouldn't. I could be mistaking. [21:22] mpoirier, what about using git://git.linaro.org/kernel/linux-linaro-2.6.35.git? [21:23] mpoirier, cloning it in your public area on zinc, apply your patches there and submit a pull request from it? [21:25] bjf: hold on a sec, checking something... [21:26] bjf: this morning i tried multiple time to get git://git.linaro.org/ubuntu/linux-linaro.git [21:26] it failed pathetically. [21:26] but it think it was a connectivity issue 'cause now it works. [21:27] I was trying to find other ways to do just that. [21:27] bjf: you can void the last 10 minutes from your memory. [21:28] mpoirier, heh [21:41] * ogasawara lunch === bjf is now known as bjf[afk] [22:05] bjf: now I remember what the problem was... [22:05] bjf: you can't git clone git://git.linaro.org/ubuntu/linux-linaro.git from zinc === bjf[afk] is now known as bjf [22:07] bjf: would you have a suggestion ? [22:07] mpoirier, do you want to end up with a pull request against the official linaro kernel or the linaro topic branch in maverick (and I don't know what the diff between the two is) [22:08] official linaro kernel. [22:08] mpoirier, then I'd probably make a local clone and then rsync that git tree to my public area on zinc and then I can clone from that [22:09] mpoirier, it's kind of round-about but it would work [22:09] can you rsync from tangerine ? [22:09] mpoirier, i think you can but you would have to give it a try to know for sure [22:10] bjf: ya, I was about to write... ok I'll give it a shot. I wasn't sure is there wasn't another way. [22:10] bfj: rsync it is then. === bjf is now known as bjf[afk] [22:19] apw, good news! [22:19] someone posted a patch to a utouch bug that enables multitouch support on synaptics trackpads [22:19] real multitouch [22:20] and I think I can fix up the patch so that we can make things work properly AND allow use of the entire touchpad surface! [22:21] cnd: do you lose tapping? that's kind of the deal breaker, can't imagine using any of my laptop touchpads with the buttons [22:21] Sarvatt, no loss of tapping [22:21] nice! [22:22] it's all in my head right now, how to make this work though [22:22] cnd, cool man. [22:22] so I need to sit down and try it out [22:22] cnd, so we can use it in macbook pro [22:22] cooloney, unibody macs have their own MT capable driver already [22:23] so unless you're thinking of a rather old macbook pro, this isn't relevant [22:23] my idea is that with MT support you do two things: [22:23] 1. you have single touch emulation where the first touch on the touchpad controls the cursor [22:23] cnd, ok, i just upgrade my mbp to maverick [22:24] * Sarvatt hopes the person that posted the patch agrees to copyright assignment [22:24] 2. if the first touch is in the button area as a button goes down, then the touch disappears [22:24] Sarvatt, this is kernel code, no assignment needed :) [22:25] if you implement both of those, I think you can get all the functionality of the touchpad back [22:25] and add in support for two finger scrolling and the like [22:26] cnd, most of this work are in which part of our user space? [22:26] cooloney, what I'm talking about right now is in psmouse in the kernel [22:26] we don't have to touch userspace [22:27] one might make the argument that code for part 2 shouldn't be in the kernel [22:27] but I'm not convinced quite yet [22:28] cnd, got it. [22:29] you said unibody macs have the MT version psmouse driver in kernel? [22:29] they have bcm5984 [22:30] which has MT support since lucid [22:30] ok, so can we enable MT on my unibody mbp in Maverick, how? [22:31] it's already there, but the only app we have enabled out of the box on maverick is unity [22:32] cnd, got it. man [23:05] I can confirm with my own eyes that we can do MT with the synaptics driver [23:05] :) [23:05] but it needs to be fixed up [23:05] I patched my psmouse module and tested it out, but it only emitted MT events instead of emitting both MT and ST (single touch) events [23:05] so X didn't know what to do [23:05] and the touchpad became useless :) === ivoks-afk is now known as ivoks