| Napsong_boy | hi | 01:51 |
|---|---|---|
| Napsong_boy | any girls from jakarta in this room? | 01:52 |
| === foka_ is now known as foka | ||
| === thegodfather is now known as fabbione | ||
| === thegodfather is now known as fabbione | ||
| rtg | BenC: so whats the story with the Jaunty kernel? It looks like amit took the Intrepid -proposed kernel, added armel, then uploaded that (or someone did for him). | 13:45 |
| BenC | rtg: I wasn't expecting to get jaunty kernel done till after alpha1 went out | 13:51 |
| BenC | rtg: I've almost finished up the cleanup so I can send the summary to kernel-team | 13:51 |
| BenC | then I'll push and start some builds | 13:51 |
| rtg | BenC: actually, my curiosity was more about having to redo the armel work. | 13:52 |
| BenC | rtg: I'm not sure how amitk is handling arm kernels | 13:55 |
| BenC | rtg: I think that upload was mainly to get bootstrap started (linux-libc-dev) | 13:55 |
| rtg | BenC: well, lemme know if you need any help with Jaunty. | 13:56 |
| BenC | sure thing, thanks | 13:57 |
| BenC | it's pretty much grunt work at the moment | 13:57 |
| rtg | I think we're gonna have to figure out how to build armel using qemu until we get some porter machines. | 13:57 |
| apw | rtg perhaps we could make a qemu machine on an existing porter as a fake porter? | 14:29 |
| rtg | apw: ugh, that would take massive support from IS (which would also take awhile). | 14:30 |
| dholbach | hi guys :) | 14:30 |
| dholbach | did we have any bug reports about overactive fans on laptops like the lenovo x61s? | 14:31 |
| rtg | dholbach: sounds familiar | 14:31 |
| dholbach | fan speed is ~3800 when the machine is basically idling in gnome intrepid | 14:31 |
| rtg | amitk: don't you have one of these? ^^ | 14:32 |
| * soren wonders if the overactive fan is the problem or a symptom | 14:32 | |
| rtg | soren: ACPI is your friend :) | 14:33 |
| soren | rtg: Now I know you're lying :) | 14:34 |
| mjg59 | Thinkpad fans aren't ACPI fans | 14:34 |
| soren | I'm just thinking that the overactive fan is a symptom of the system being too hot for some other reason. | 14:34 |
| rtg | mjg59: direct sensor connect? | 14:34 |
| soren | s/is/might be/, I mean. | 14:34 |
| mjg59 | rtg: Under control of the embedded firmware | 14:35 |
| mjg59 | There's a Thinkpad ACPI method that lets you change embedded controller values, which lets you take over control of the fan | 14:35 |
| mjg59 | But that's not the default behaviour | 14:35 |
| soren | Interesting. | 14:35 |
| mjg59 | So an overactive fan generally indicates high temperature | 14:36 |
| mjg59 | thinkpad-acpi exposes an hwmon interface that should give you the temperatures | 14:36 |
| rtg | mjg59: is the embedded firmware running on an independent processor? | 14:36 |
| apw | i know the t40'ish ones nearly always needed the fan | 14:36 |
| apw | though my t61 seemed to turn it off, not got it any more to confirm | 14:37 |
| mjg59 | rtg: Yeah, there's a microcontroller | 14:37 |
| mjg59 | The embedded controller is generally the same hardware as the keyboard controller these days | 14:37 |
| dholbach | wow | 14:38 |
| dholbach | sensors-applet just added like 456765345678987654345678 temperature thingies to my panel | 14:38 |
| dholbach | they all seem to be between 25°C and 37°C | 14:39 |
| amitk | rtg: no lenovo here | 14:44 |
| amitk | rtg: I meant no lenovo x61s here | 14:45 |
| rtg | amitk: no problem. I didn't realize thermal control was independent. | 14:45 |
| dholbach | do you have any numbers on what your fans are running at when the machine is reasonably idle? | 14:45 |
| sconklin | ogasawara: if a LP bug is set to milestone:Later, that doesn't imply anything about whether I should pick it up from kernel team or not, does it? That gets set later in the process? | 14:58 |
| ogasawara | sconklin: when it's been milestoned for later that typically implies we couldn't get a fix into the current release but it should be considered for the next release. | 15:16 |
| ogasawara | sconklin: so if you'd like to work on the bug, feel free. | 15:16 |
| sconklin | ogasawara: ok, thx | 15:16 |
| Daviey | Is a 2.6.28 ppa upload planned soon? | 15:29 |
| rtg | Daviey: it'll likely be awhile yet. | 15:32 |
| Daviey | aww | 15:34 |
| Daviey | rtg: Any reason your git branch shouldn't build okay on PPA? | 15:35 |
| rtg | I don't have a 2.6.28 branch yet | 15:36 |
| Daviey | oh! | 15:37 |
| Daviey | sorry rtg, thought i saw you did | 15:38 |
| Daviey | my bad | 15:38 |
| rtg | its still in process. we should have a Jaunty kernel pretty soon, which will be 2.6.28 based | 15:39 |
| rtg | pgraner: if the stable update is referenced by a single SRU justification, then I didn't see the need to expand on the individual commit messages. | 15:42 |
| pgraner | rtg: I thought the reason was to ensure that they had all been looked at and were sane, were there any that were dropped or did we take it wholesale? | 15:43 |
| rtg | pgraner: I looked at each one, though not all apply because they are arch dependent. however, since the intrepid-ports kernel is based on intrepid, I felt it was important to carry even those patches that did not apply. | 15:45 |
| pgraner | rtg: Ah ok. perhaps next time drop that in the bug, keeps me from bothering you. | 15:45 |
| rtg | drop what in the bug? | 15:46 |
| pgraner | rtg: the explanation you just gave me, basically any relevant info about the patch set, why things are there (or not) etc... | 15:47 |
| rtg | pgraner: as one of my profs used to say, 'its intuitively obvious' | 15:48 |
| pgraner | rtg: ah... I'm more in the stupid proof camp... | 15:48 |
| pgraner | rtg: lots of people are reading these bugs and the more info as to why, is better. | 15:49 |
| rtg | pgraner: I'll get ogasawara to add it to the SRU stable update boiler plate. She's been creating the master bug for each stable update cycle. | 15:49 |
| pgraner | rtg: nice... leave it to you to automate it | 15:50 |
| rtg | I'm sure ogasawara likes being known as my automaton :) | 15:51 |
| rtg | apw: the more I think about it, merging the changelogs doesn't make sense because it does not accurately represent the changes that particular kernel went through. | 16:09 |
| apw | no what i did was keep the changelog unchanged, as its just a template | 16:10 |
| apw | and when i printchanges is includes changes from both branches | 16:11 |
| rtg | apw: I've a conf call I need to prepare for. I'll respond in detail on the mailing list. | 16:11 |
| smb_tp | rtg, I assume uploading the the next -proposed kernel with a well chosen -v on the dpkg_buildpackage would show all changes required... | 16:16 |
| rtg | smb_tp: its helps with the diff that you see in LP. | 16:16 |
| smb_tp | rtg, That was my guessing. Let's whether my idealistic thinking turns out true :) | 16:18 |
| apw | so if we have bug which we have actually generated a fix and pushed it upstream, but there is little pressure to back port that fix, so the sensible way forward is to wait for it to flow back down naturally ... | 16:46 |
| apw | what is the right state for that bug ... Will not fix ? | 16:46 |
| apw | or perhaps we mark it as a bug upstream and Fix Committed it there, and will not fix on our side | 16:59 |
| apw | ogasawara, ^^ ? | 16:59 |
| * apw asks the oracle | 17:00 | |
| BenC | apw: that sounds right | 17:11 |
| apw | thanks | 17:13 |
| ogasawara | apw: sorry was at the dentist, but yes Fix Committed likely for Jaunty and Won't Fix for Intrepid sounds reasonable | 17:27 |
| apw | i went for adding upstream and fix committed there, and won't fix for our task | 17:29 |
| apw | so that we don't have to worry about it at alll | 17:29 |
| ogasawara | apw: that works too | 17:29 |
| apw | in case jaunty doesn't end up with it, then our tasks would lie | 17:30 |
| apw | still we got something accepted upstream so thats good | 17:30 |
| apw | (trivial though it was) | 17:30 |
| apw | ogasawara, for something that looks like it will come down the pipe in mainline updates for jaunty, what is our bug handling for that | 17:32 |
| apw | straight to invalid if its against jaunty i guess? | 17:33 |
| apw | we really could do with a 'no change needed' status | 17:34 |
| apw | invalid just feels a little to much like 'submitter stupid' | 17:34 |
| ogasawara | apw: invalid always feels so harsh to me for those types of bugs. so I typically just post a note we'll get the fix for free with Jaunty and set the status to In Progress and assign it to myself. | 17:36 |
| apw | what then move it to fix released when the kernel goes out? | 17:36 |
| ogasawara | apw: then I know to keep an eye on the bug and flip to Fix Released when we do get the fix | 17:36 |
| ogasawara | apw: I think there's actually a few maybe on the bug list I sent you like that | 17:37 |
| apw | yeah its one of those i was looking to handle | 17:37 |
| apw | i've confirmed its in upstream and on its way to us ... | 17:37 |
| apw | so i'll do what you suggested here | 17:37 |
| ogasawara | as long as it's on the list I'm sure one of us will see it and remember to close it out | 17:38 |
| apw | oh do you have edit title priviledge | 17:38 |
| apw | bug #222324 has hardy in its title, but that makes little sense as the bug is now 'against' jaunty | 17:38 |
| ogasawara | apw: we all do, it's just not obvious. click on the little yellow circle icon next to the title | 17:40 |
| apw | heh ... oh ... strange ... this interface seems to resist understanding at times | 17:44 |
| sconklin | rtg: I'm backporting a touchpad driver into intrepid from Linus's tree. His commit didn't apply cleanly, but only had minor conflicts. Is this a sauce patch? | 18:06 |
| rtg | sconklin: not if it came from upstream. | 18:07 |
| rtg | sauce is for patches that we either expect to conflict, or will never go upstream. | 18:08 |
| sconklin | rtg: I just wondered because it needed a little fussing. Thanks. | 18:08 |
| sconklin | ok, got it | 18:08 |
| rtg | in actuality, the first case kind of abuses the notion of sauce. | 18:08 |
| sconklin | yeah, it's almost like we need a third name | 18:09 |
| BenC | I always took sauce as something that isn't in upstream | 18:54 |
| BenC | be it a patch we created, was pulled from an external tree, etc. | 18:54 |
| === Michiel__ is now known as Eghie | ||
| === TheMuso_ is now known as TheMuso | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!