| TheMuso | bjf: When you get a minute, could you possibly kick the alsa modules daily builds over to new ABIs? | 00:57 |
|---|---|---|
| TheMuso | Thanks in advance. | 00:58 |
| === jjohansen is now known as jj-afk | ||
| bjf | TheMuso: lucid daily is already at -24 could do -25 for proposed | 01:37 |
| TheMuso | bjf: Ah ok, I don't think -25 matters for proposed at this point, but what is disturbing is that some users have filed audio bugs using the proposed 2.6.32-25 kernel. | 01:38 |
| === tm_ is now known as tm | ||
| === jj-afk is now known as jjohansen | ||
| === diwic is now known as diwic_afk | ||
| lag | Can someone test this for me? | 09:30 |
| smb | lag, this? | 09:31 |
| lag | cd to a git repo and issue: BRANCHES=$(git branch) && echo $BRANCHES | 09:31 |
| smb | maybe BRANCHES="$(git branch)"? | 09:31 |
| lag | Nope | 09:32 |
| smb | and echo "$BRANCHES" | 09:32 |
| smb | lag, The version with all "" works... now without | 09:33 |
| lag | I'm more interested to know where it's acquiring the directory listing from? | 09:33 |
| smb | Trying to find a logically sounding explanation but it has to do with shell expansion somewhat | 09:34 |
| smb | lag, ah because you have a * in the result | 09:35 |
| jk- | :D | 09:35 |
| lag | Ah! | 09:36 |
| lag | Well spotted | 09:36 |
| lag | BRANCH=`git branch | grep \*` && echo ${BRANCH#* } | 09:37 |
| lag | Woooooooo | 09:37 |
| smb | lag or BRANCH=$(git branch | awk '/^*/{print $2}') ;-) | 09:40 |
| lag | I'd just typed up a similar line using sed :) | 09:40 |
| lag | But I think yours is more readable, I'll use that | 09:40 |
| smb | At least it helps me that awk can look very much like C | 09:41 |
| lag | Really? | 09:42 |
| jk- | or | 09:42 |
| jk- | set -f; BRANCHES=$(git branch); echo $BRANCHES | 09:42 |
| jk- | i guess you don't want the * though.. | 09:43 |
| smb | heh, a hundred ways to do it | 09:43 |
| jk- | BRANCHES=$(git branch | tr -d '*'); echo $BRANCHES | 09:43 |
| smb | lag, Yeah, you could do a git branch | awk '/^*/{printf("%s\n", $2);}' as well | 09:43 |
| lag | I like smb's first one :) | 09:45 |
| lag | Have you all finished flexing your Bash muscles now? ;) | 09:45 |
| jk- | b=$(git branch); echo "${b/\*/}" <- one less fork | 09:45 |
| lag | Clearly not :) | 09:46 |
| jk- | :D | 09:46 |
| smb | The winner of most unintuitive code today is .... jk- ;-P | 09:46 |
| jk- | woot! | 09:46 |
| jk- | b=$(ls .git/refs/heads/) | 09:48 |
| smb | That would mean we understand how git actually works... | 09:48 |
| jk- | so +1 for a layering violation too? | 09:49 |
| smb | hehe, yeah. unfortunately you cannot trust it even when using the commands as apw and me found out for git remote show -r | 09:50 |
| === amitk is now known as amitk-afk | ||
| lag | I have a new favourite | 09:53 |
| lag | BRANCH=`git branch | grep \* | cut -d ' ' -f 2` | 09:53 |
| lag | Simple, effective | 09:53 |
| jk- | lag: you only want the current branch? | 09:54 |
| lag | Yeah | 09:54 |
| jk- | i'd go for the awk then :) | 09:55 |
| lag | I like the awk version | 09:56 |
| lag | But this one is easier to read: BRANCH=`git branch | grep \* | cut -d ' ' -f 2` | 09:56 |
| smb | It probably has more every-day-use commands. And having a third fork unlikely will really matter | 09:57 |
| lag | It'll only be run once for every compile | 09:57 |
| * apw starts his UHS prep ... with a haircut | 10:01 | |
| === diwic_afk is now known as diwic | ||
| lag | What do we have to wear for UHS? | 10:06 |
| AceLan_ | lag: I think you'll get a new t-shirt for it | 10:11 |
| jk- | pants | 10:12 |
| jk- | :) | 10:12 |
| lag | T-shirt sounds good | 10:13 |
| lag | :) | 10:13 |
| lag | AceLan_: Is your lecture prep'ed? | 10:13 |
| AceLan_ | lag: http://shop.canonical.com/index.php?cPath=14 # Ubuntu Polo Shirt (Black) | 10:13 |
| lag | Could be worse :) | 10:13 |
| lag | I'm assuming I don't have to pre-order it? | 10:14 |
| AceLan_ | lag: don't worry, I'm pretty sure you'll get one for free | 10:14 |
| lag | I still haven't spent my joining voucher | 10:15 |
| jjohansen | ha, I forgot all about the joining voucher, /me hasn't spent it either | 10:16 |
| AceLan_ | me neither :p | 10:18 |
| cooloney | Canoical shop doesn't ship goods to China, so me either | 10:19 |
| diwic | In addition, the shipping cost takes half the voucher | 10:39 |
| diwic | lag, the dress code is actually listed as "Smart trousers, not jeans" and ubuntu t-shirt, which I assume Fanny will provide when we get there | 10:40 |
| lag | Great, thanks David | 10:44 |
| lag | cooloney: You can always send it to me :) | 10:44 |
| cking | smart trousers? Hrm. | 10:45 |
| cooloney | lag: haha, yeah, i will ship an new iphone4 and ipad to you | 10:45 |
| jk- | woot, free gear | 10:45 |
| smb | diwic, I would treat the dress code with care. Its copied over regardless of occasion and you might look strange around the geeks. :) | 10:45 |
| cooloney | lag: and pls bring them to UDS for me | 10:45 |
| cking | does it specify smart socks too? Can I wear multi-coloured ones? | 10:46 |
| * smb does not want his clothing to be smarter than himself | 10:46 | |
| cking | dress code did not specify underwear | 10:48 |
| === diwic is now known as diwic_lunch | ||
| smb | diwic, Would you have an explanation on the feedback to bug 587546. It seems reported as the patch in proposed has no effect (must admit I have not looked really at details). | 10:52 |
| ubot2 | Launchpad bug 587546 in linux (Ubuntu Lucid) (and 3 other projects) "Pulseaudio fails after several seconds (affects: 1) (heat: 41)" [Low,Fix committed] https://launchpad.net/bugs/587546 | 10:52 |
| lag | cooloney: I didn't mean the goods, I meant the voucher | 10:53 |
| lag | cooloney: But if you want to ship anything to me, I'd be happy to bring it over to UHS/UDS | 10:53 |
| cooloney | lag: np, you are so kind. heh | 10:54 |
| cooloney | lag: anything you need we bring from China, just tell us | 10:54 |
| lag | All the tea | 10:56 |
| lag | Actually I'd quite like a 'Naja atra' | 10:56 |
| cooloney | lag: what's 'Naja atra' is green tea? | 10:58 |
| cooloney | you know green tea is common in China | 10:58 |
| lag | :D | 10:58 |
| lag | The first request was "All the tea", as in "All the tea in China" | 10:58 |
| lag | You will have to Google Naja atra for yourself :) | 10:58 |
| smb | lag, You have a big suitcase and know some people working for the airline and customs? ;-) | 11:04 |
| lag | For which item? | 11:06 |
| lag | :) | 11:06 |
| lag | I don't think I have a big enough suitcase for all the tea in China | 11:06 |
| lag | For a few Naja atra maybe :) | 11:07 |
| smb | Likely all of them. But especially the Naja atra I guess | 11:07 |
| smb | :) | 11:07 |
| smb | Probably cking and apw want a different plane than you back as well. :-P | 11:08 |
| === dmarkey_ is now known as dmarkey | ||
| === ivoks-afk is now known as ivoks | ||
| === smb is now known as smb-afk | ||
| === diwic_lunch is now known as diwic | ||
| diwic | bjf, guess what - it's ABI bumping time! | 11:35 |
| === ivoks is now known as ivoks-afk | ||
| apw | smb-afk, he'll be stuck in customs for the duration when they find out he is a purper | 12:13 |
| apw | diwic, heh bad boy | 12:16 |
| diwic | apw, ? | 12:17 |
| apw | bumping the abi | 12:18 |
| === amitk-afk is now known as amitk | ||
| diwic | apw, sounds like an inspiration for a rap song? | 12:36 |
| apw | diwic, so very true | 12:42 |
| === smb-afk is now known as smb | ||
| smb | diwic, Could it be inspirational enough to have a quick look into the question I asked before? :-P | 12:51 |
| diwic | smb, what question? Do you want me to repost the patch with a changed commit message? | 12:53 |
| smb | apw, Or stuck there for long on his way back should they find a "present" like that. | 12:53 |
| smb | replay: diwic, Would you have an explanation on the feedback to bug 587546. It seems reported as the patch in proposed has no effect (must admit I have not looked really at details). | 12:53 |
| ubot2 | Launchpad bug 587546 in linux (Ubuntu Lucid) (and 3 other projects) "Pulseaudio fails after several seconds (affects: 1) (heat: 41)" [Low,Fix committed] https://launchpad.net/bugs/587546 | 12:53 |
| diwic | smb, okay, I'll have a look as soon as I've done with another bug | 12:56 |
| smb | diwic, Thanks a lot | 12:56 |
| cking | apw, https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=ath9k&orderby=-importance | 13:10 |
| mapet | Can anyone tell me how I can add a custom version string to my kernel build, if I compile the official kernel with "debian/rules binary-generics"? I don't want it to be overwritten on each apt-get upgrade... | 13:29 |
| === ivoks-afk is now known as ivoks | ||
| apw | mapet, normally I exit the top of the debian.master/changelog and use my own version there | 13:43 |
| mapet | apw, iirc this didn't worked for me but I'll try it again. thank you | 13:46 |
| === cking is now known as cking-afk | ||
| diwic | In average, how many days does it take from I send a patch to stable@kernel.org to that the Lucid users can enjoy their fixed bug? | 14:50 |
| smb | diwic, That depends on quite a lot of variables to be giving a good average. How long from Greg accepting it to releasing it, how long from that till we get it into the archive and from that depends when its possible to upload to proposed and then how long it take to go to updates | 14:52 |
| tgardner | diwic, it can sometimes take weeks, which is why we often have a (pre-stable) inclusion. | 14:52 |
| smb | i guess a minimum can be at least three weeks on good days... | 14:53 |
| smb | (to get into updates) | 14:54 |
| diwic | tgardner, so how long is our own baking cycle compared do that? 7 - 14 days? | 14:54 |
| tgardner | diwic, roughly | 14:54 |
| smb | diwic, yes. as upstream stable updates usually are larger rather the 14 days in proposed | 14:54 |
| diwic | so waiting say 5 - 7 weeks in total is not unusual? | 14:55 |
| smb | Hopefully we can improve that a bit but at least it was | 14:55 |
| smb | But i'd say 3 to 4 weeks could be common | 14:56 |
| diwic | right, the long security-blocking-sru discussion | 14:57 |
| diwic | How do I know on what waiting list a stable patch actually is? | 14:58 |
| smb | Yes, that has some impact at least to the in the proposed to updates time. People can get patches quicker when installing at least proposed but even better pre-proposed | 14:58 |
| smb | diwic, When it has been released in an upstream stable release you can check when that gets applied to the master repo. When it is in there it moves on to proposed uploads (which you probably could check with git describe --contains on our master repo) | 15:00 |
| diwic | smb, someone should write up a wiki page on how to know where an update is | 15:03 |
| === cking-afk is now known as cking | ||
| diwic | smb, so my patch is currently present in stable-queue.git, queue-2.6.35 but not queue-2.6.32 | 15:04 |
| diwic | That's not good odds I assume | 15:04 |
| smb | diwic, Someone probably should | 15:05 |
| * smb looks innocent | 15:05 | |
| smb | diwic, And yes, that does not seem good | 15:05 |
| smb | diwic, Could it have failed to apply cleanly there? | 15:06 |
| smb | In that case Greg accepts bribes in form of backported patches | 15:06 |
| diwic | smb, I gave him a 2.6.32 backport but was perhaps too late | 15:06 |
| smb | It might just be pending another batch of applies from his inbox. Its hard to say | 15:07 |
| diwic | so after it has been in queue-2.6.xx for x days, it moves to another tree and is there for x days | 15:07 |
| smb | diwic, He may or may not move it into review-2.6.xx in that repo and sends out review mails, gives people about three days to reply or not and then takes the set that is there after that and imports it into the various 2.6.x.y trees | 15:10 |
| === ivoks is now known as ivoks-afk | ||
| diwic | smb, and then it moves into ubuntu-lucid (e g) | 15:14 |
| diwic | smb, and then to pre-proposed, then to proposed, then released | 15:16 |
| smb | diwic, Right, so when it is released in the 2.6.32.y tree we pick it up prepare a patchset with it and do the usual tracking bug and quick review, then apply it to the repo and from there an automatic script picks up the checkins and creates the pre-proposed. The proposed uploads are more manual as they need to take into account whether there is something in proposed we want to go to updates first, or whether a security update comes in soon an | 15:18 |
| smb | d such. But at some point it gets uploaded to proposed | 15:18 |
| smb | and then after about 2 weeks (if trere have been no regressions detected) it will get moved on | 15:19 |
| vanhoof | diwic: this has been helpful for me (if you've not seen it): http://people.canonical.com/~ubuntu-archive/pending-sru.html | 15:20 |
| smb | diwic, The upload itself also can get delayed as each package uploaded to the proposed pocket needs to be accepted manually by an sru team archive admin | 15:20 |
| smb | vanhoof, right this shows what bug reports are claimed to be fixed by a proposed upload. And red is a bad verification and green a good one | 15:21 |
| smb | blue is nobody cared (yet) | 15:21 |
| === ivoks-afk is now known as ivoks | ||
| smb | The sru team tries at least to have a certain percentage of the bugs successfully verified and no regressions before moving it to updates, even if it has been there for the two weeks | 15:22 |
| diwic | how often does greg do a "review round"? | 15:24 |
| smb | depends, sometimes every two weeks, sometimes it takes longer. Probably depends on the queue and his workload | 15:25 |
| diwic | vanhoof, thanks, it just shows the stuff in proposed, which has it's purpose. I'm trying to understand the patch flow (flowchart, anyone)? | 15:26 |
| smb | diwic, You know its the "new guys" job to fix the crap documentation of the old guys. ;-P | 15:27 |
| diwic | smb, oh, I just became much older ;-) | 15:27 |
| smb | :) | 15:28 |
| bjf | ## | 15:36 |
| bjf | ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting | 15:36 |
| bjf | ## agenda: https://wiki.ubuntu.com/KernelTeam/Meeting | 15:36 |
| bjf | ## | 15:36 |
| sconklin | http://www.pcpro.co.uk/news/361108/intel-unveils-sandy-bridge | 15:40 |
| vanhoof | sconklin: nooooooooooo | 15:57 |
| vanhoof | :D | 15:57 |
| * smb curses under his breath. tgardner could you fix a nomination for me please? bug 638115 | 15:59 | |
| ubot2 | Launchpad bug 638115 in linux-backports-modules-2.6.32 (Ubuntu) "linux-backports-modules-wwan-2.6.32 fails to upgrade properly (affects: 1) (heat: 6)" [Low,Triaged] https://launchpad.net/bugs/638115 | 15:59 |
| tgardner | smb, done | 15:59 |
| smb | tgardner, thanks | 15:59 |
| apw | vanhoof, heh, thats written by a friend of mine | 16:02 |
| vanhoof | apw: I was hoping it was all a dream | 16:02 |
| vanhoof | apparently its not :) | 16:02 |
| tgardner | apw, ogasawara: did you notice that gcc was uploaded _again_ ? | 16:20 |
| ogasawara | tgardner: wtf, again? | 16:21 |
| tgardner | about 30 minutes ago | 16:21 |
| apw | tgardner, thats 4.5 which version do we use ? | 16:21 |
| tgardner | I thought it was 4.5. | 16:21 |
| ogasawara | I though it was 4.4 | 16:21 |
| tgardner | hmm, don't have a maverick machine handy. | 16:21 |
| tgardner | ogasawara, you're right. it is 4.4 | 16:22 |
| apw | yeah looks like its 4.4. we are using by default, so i think we are ok | 16:23 |
| apw | tgardner, ogasawara, EXCEPT, 4.4 just got uploaded too | 16:24 |
| apw | 10 mins ago | 16:25 |
| tgardner | apw, thats what Mathias was referring to in the other channel | 16:25 |
| tgardner | looks like we should be OK | 16:26 |
| ogasawara | well, I was thinking of doing another upload today anyways to make sure the -virtual deb sizes shrink back down | 16:27 |
| tgardner | ogasawara, you have any other patches you'rethinking of taking? | 16:27 |
| ogasawara | tgardner: the others on the ml which are mainly pre-stable patches | 16:28 |
| tgardner | I guess that was a dumb question, huh? | 16:28 |
| ogasawara | tgardner: I'm also still hoping for 2.6.35.5 to land so we can sneak that in before kernel freeze too | 16:29 |
| tgardner | ogasawara, Thursday, right? thas gonna be tight. | 16:29 |
| ogasawara | tgardner: yah, we'll have to see. | 16:30 |
| cking | hrm, got this error on my server: | 16:35 |
| cking | [ 4655.729368] fwts: Corrupted page table at address 7fd769f1e606 | 16:35 |
| cking | [ 4655.729466] PGD 129845067 PUD 139e43067 PMD 12f527067 PTE bff6463abff64235 | 16:35 |
| cking | [ 4655.729625] Bad pagetable: 000d [#1] SMP | 16:35 |
| cking | [ 4655.729695] last sysfs file: /sys/devices/pnp0/00:05/rtc/rtc0/wakealarm | 16:35 |
| cking | [ 4655.729796] CPU 0 | 16:35 |
| ogasawara | manjo: do you think you're going be throwing any last minute patches my way re WD? | 16:36 |
| tgardner | cking, is it fwts detected that the page table is corrupted? | 16:36 |
| cking | tgardner, it trips that warning from the kernel | 16:36 |
| apw | heh no it was simply the victim | 16:36 |
| cking | dunno why as yet. Ah, it's repeatable. | 16:37 |
| tgardner | cking, well, thats the first step | 16:37 |
| apw | probabally you are looking somewhere nasty ... but ick | 16:37 |
| cking | hrm, only disassembling the DSDT | 16:37 |
| vanhoof | ogasawara: i have 20 patches I'm planning to submit tomorrow at 11pm ET | 16:38 |
| * vanhoof *hides* | 16:38 | |
| smb | ogasawara, I may be trying to pre-stable a little update that fixes a (not sure how minor) problem with /proc/<pid>/maps for you to decide. | 16:38 |
| * ogasawara slaps vanhoof | 16:38 | |
| tgardner | vanhoof _better_ hide. | 16:38 |
| vanhoof | haha! | 16:38 |
| * vanhoof is done w/ patches for maverick | 16:38 | |
| ogasawara | smb: ack | 16:38 |
| vanhoof | im glad i've not been slapped yet ;) | 16:38 |
| tgardner | vanhoof, thats apw's trick. | 16:39 |
| apw | ogasawara, i think that vanhoof just said you can ignore anything from him from now on :) | 16:39 |
| ogasawara | cking: I wanted to ask you about bug 612741 which is linked to your kernel-maverick-bios-test-automation blueprint... | 16:40 |
| ubot2 | Launchpad bug 612741 in acpi (Ubuntu) "uncommanded shutdown (affects: 1) (heat: 100)" [Medium,Incomplete] https://launchpad.net/bugs/612741 | 16:40 |
| ogasawara | cking: the bug isn't exactly about the fwts itself, but rather a bug where you had them run the fwts | 16:40 |
| ogasawara | cking: did you really want that linked to the blueprint? as it shows up as an open work item for you | 16:41 |
| cking | ogasawara, it should be removed | 16:41 |
| ogasawara | cking: cool, I'll remove it. | 16:41 |
| cking | ogasawara, you are too kind | 16:41 |
| cking | thanks | 16:41 |
| === BenC___ is now known as BenC | ||
| bjf | cking, i think i've fixed the issue with the daily iso building and it's building them now | 16:47 |
| cking | bjf, thanks! | 16:47 |
| === yofel_ is now known as yofel | ||
| tgardner | ogasawara, I'm looking at these powertop patches. the first one (at least) appears to be a backport. | 16:53 |
| tgardner | ah, guess Yong says tha in the into email | 16:53 |
| tgardner | intro* | 16:53 |
| ogasawara | tgardner: yah, the first is upstream. not sure about the status of the 2nd patch w/ regards to upstream. | 16:54 |
| tgardner | ogasawara, well, I'm making sure he got the backport right. it looks a bit different. | 16:54 |
| ogasawara | tgardner: he bodged the first attempt that's for sure | 16:54 |
| tgardner | which is why I'm looking at it a bit closer | 16:55 |
| tgardner | ogasawara, the 2nd patch has all of the SATA statistics gathering done within the interrupt handler. I'm not sure that''ll land upstream intact. | 16:59 |
| vanhoof | apw: hew now :) | 17:01 |
| apw | vanhoof, can't hear you :) | 17:01 |
| vanhoof | /mode +v vanhoof | 17:01 |
| vanhoof | :) | 17:02 |
| smb | ogasawara, apw Ok, pushed my little contribution. Though I am not completely sure about its importance or effect | 17:07 |
| ogasawara | smb: looks reasonable enough and seems you've tested it works | 17:11 |
| smb | Mostly. I think I was bad and tested before that it does not work right now and the change itself just repeats or reuses the changes from Linus for the rest. | 17:13 |
| JFo | vanhoof, what goodies do you want in my slide deck for UHS? | 17:13 |
| smb | ogasawara, And well a very similar change was used to get Xen working again on Hardy | 17:14 |
| JFo | I am outlining the general versus the private bug/group concept | 17:14 |
| apw | ogasawara, are you aware of the thread "Final Maverick i830, i845g, i855 support" ... they are likely to be asking us to revert some patches | 17:15 |
| ogasawara | apw: yep, was going to ping RAOF to get his final recommendation to drop the KMS disablement patches | 17:15 |
| ogasawara | apw: but I think he might be traveling today | 17:15 |
| apw | ogasawara, cool as long as you are aware i can go back to sleep | 17:15 |
| vanhoof | JFo: what do you mean | 17:19 |
| JFo | I'm building my slide deck for UHS | 17:20 |
| JFo | is there any OEM team/ HWE stuff you want me to add? | 17:20 |
| vanhoof | JFo: well what are you talking about | 17:20 |
| JFo | I'm writing about the bug process | 17:20 |
| vanhoof | ah | 17:20 |
| JFo | sorry | 17:20 |
| JFo | should have said | 17:20 |
| vanhoof | "vanhoof quit being dense?" | 17:20 |
| JFo | lol | 17:21 |
| vanhoof | JFo: bug process is not something that the OEM has to deal with, they file as normal, and i've put together a linking concept to track distro bugs | 17:22 |
| JFo | right | 17:23 |
| JFo | I left that bit out as I don't think it would be useful to them | 17:23 |
| JFo | basically I am proposing that, unless they have NDA or pre-announced hardware, that they use the general process | 17:24 |
| vanhoof | yeah thats a fair statement | 17:25 |
| JFo | k | 17:25 |
| * tgardner spams ogasawara with more patch mail | 17:37 | |
| === jsalisbury_ is now known as jsalisbury | ||
| === jsalisbury is now known as jsalisbury_brb | ||
| kstailey | good day (or whenever) | 18:32 |
| apw | good 'now' | 18:32 |
| JFo | hi kstailey :) | 18:32 |
| kstailey | hi jFo | 18:32 |
| apw | bug #563481 | 18:32 |
| ubot2 | Launchpad bug 563481 in linux (Ubuntu) "BUG: Bad page state in process soffice.bin pfn:111e42 (affects: 4) (dups: 1) (heat: 45)" [Undecided,Incomplete] https://launchpad.net/bugs/563481 | 18:32 |
| kstailey | I'm sure there are others. | 18:32 |
| * smb wonders whether he saw that mails on the stable list | 18:33 | |
| JFo | kstailey, is that patch in stable? | 18:33 |
| * JFo hasn't had the chance to look | 18:33 | |
| * kstailey checking | 18:33 | |
| smb | Me neither | 18:33 |
| ogasawara | it didn't look like it was upstream yet | 18:33 |
| ogasawara | so I assume it's not in stable | 18:33 |
| apw | kstailey, so are you looking for a test kernel with this patch in, ie, is this patch well tested yet? | 18:33 |
| smb | The description soehow sounds like I saw it somewhere, but as long as it is not upstrream it won't go stable | 18:34 |
| kstailey | now I am peeking at drivers/char/hpet.c in lxr | 18:34 |
| === bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - September-28 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! | ||
| smb | Seems that mail went to linux-acpi a month ago. But I don't seem to see a response | 18:36 |
| kstailey | it's not here http://lxr.linux.no/#linux+v2.6.35.4/drivers/char/hpet.c#L972 | 18:36 |
| kstailey | but maybe it should be | 18:38 |
| kstailey | :) | 18:38 |
| kstailey | I may have some more HP Proliant DL145 G2 systems to test on | 18:39 |
| JFo | I apologize, but I need food :) | 18:40 |
| JFo | bbiab | 18:41 |
| kstailey | I'm going to look for a server to test the patch on. | 18:42 |
| smb | Hm, it looks like this is a proposal to handle a bios bug. Might need some query upstream to get it moving probably | 18:42 |
| kstailey | The system we experienced this bug on is deployed by using the "nopat" kernel option in grub | 18:42 |
| kstailey | as a work-around | 18:43 |
| kstailey | http://en.wikipedia.org/wiki/Page_Attribute_Table | 18:43 |
| apw | kstailey, you good to make a test kernel ? | 18:45 |
| kstailey | I'm still looking for a machine to test on | 18:50 |
| kstailey | Is it OK to test on Lucid or are you particular about me testing on Maverick? | 18:50 |
| kstailey | I'd rather test on Lucid myself | 18:50 |
| smb | Well it seems it would be the same upstream | 18:50 |
| smb | You may try some of the more recent mainline kernels in lucid to compare against | 18:51 |
| kstailey | OK | 18:51 |
| kstailey | well first thing's first let me get my server | 18:51 |
| smb | Its a bit latish here to get my head around it now. The patch itself looks at least reasonable to me but I wonder why there has been no response upstream to it | 18:52 |
| kstailey | I'm also going to peek at RHEL6 to if Red Hat is workong on this | 18:55 |
| vanhoof | kstailey: http://rhkernel.org/RHEL6 | 18:58 |
| sconklin | thanks everyone for your support in the Developer Board meeting | 19:08 |
| tgardner | sconklin, like smb said, it'll be nice to not have to do your job :) | 19:10 |
| ogasawara | jjohansen: you'd mentioned you were planning to submit some Maverick patches? any eta for those? | 19:12 |
| jjohansen | ogasawara: yeah, sorry I'll post them today. They are done. I just need to get them pushed out | 19:13 |
| ogasawara | jjohansen: ack | 19:13 |
| jjohansen | that and I have been testing the amazon one | 19:13 |
| === jsalisbury_brb is now known as jsalisbury | ||
| ogasawara | tgardner: that first power top patch you re-did for yong, it doesn't look like the rtpm_status_show() originates from 8d4b9d1bfef117862a2889dec4dac227068544c9 | 19:47 |
| tgardner | oguh, lemme look | 19:50 |
| tgardner | ogasawara, ^^ | 19:50 |
| tgardner | ogasawara, hmm, what was I smoking? Did I get confused because he added it? | 19:52 |
| ogasawara | tgardner: it actually looks like his patch removed it? | 19:52 |
| tgardner | ogasawara, ok, now I'm totally confused. lemma go back and repeat what I did. | 19:53 |
| ogasawara | tgardner: I have a feeling yong isn't using our maverick repo | 19:53 |
| tgardner | ogasawara, no, likely its the Linaro repo | 19:54 |
| tgardner | ogasawara, ok, you cherry-pick it and see if you get anything different. | 19:57 |
| ogasawara | tgardner: ack | 19:57 |
| ogasawara | tgardner: if we cherry-pick 0fcb4eef8294492c8f1de8236b1ed81f09e42922 first, then 8d4b9d1bfef117862a2889dec4dac227068544c9 cherry-picks cleanly | 20:05 |
| tgardner | ogasawara, I only had minor, seemingly innocuous conflicts. huh. I guess I missed the dependency. | 20:05 |
| ogasawara | tgardner: 0fcb4eef8294492c8f1de8236b1ed81f09e42922 seems to fix up rtpm_status_show that we currently have in Maverick | 20:06 |
| tgardner | ogasawara, ok, well lets go that route. clean cherry-picks... | 20:07 |
| ogasawara | tgardner: ack, will respond to the list that I've gone the clean cherry-pick route | 20:07 |
| === ivoks is now known as ivoks-afk | ||
| sconklin | ogasawara: I'm only aware of one open work item that I had, does that match your reality? | 21:21 |
| ogasawara | sconklin: yep | 21:21 |
| sconklin | ok, I just postponed it. | 21:22 |
| ogasawara | sconklin: cool, thanks | 21:22 |
| sconklin | I'm not sure it's needed so much, Need to ask RAOF | 21:22 |
| * ogasawara lunch | 21:41 | |
| * tgardner has brcm80211 working in natty. seems to connect OK, but borks on removal. | 21:42 | |
| === mdeslaur_ is now known as mdeslaur | ||
| DoYouKnow | Hi. Anyone know if/when BCM4328 development support will be included in the kernel, or if it can be enabled in maverick? | 22:44 |
| kstailey | @DoYouKnow wrt Broadcom have you seen this http://thread.gmane.org/gmane.linux.kernel.wireless.general/55418 | 23:11 |
| ilmari | I had a quick look a that and couldn't find anything about BCM4328 support there (I have that chip in my work laptop) | 23:12 |
| kstailey | you didn't read the entire thread | 23:12 |
| ilmari | I did | 23:15 |
| ilmari | nothing about 4328 there, only 4329 and some other chipsets | 23:15 |
| ilmari | when I said "at that" I meant the driver source itself | 23:17 |
| === emma_ is now known as emma | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!