| === bjf is now known as bjf[afk] | ||
| chrismsnz | hey guys - just dropping in to ask about a bug | 00:01 |
|---|---|---|
| chrismsnz | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/586897 | 00:01 |
| ubot2 | Launchpad bug 586897 in linux-2.6 (Debian) (and 2 other projects) "stex driver (Promise SuperTrak 8350/4650,etc) produces drastic I/O errors/corruption with 10.04 or later (affects: 3) (heat: 18)" [Unknown,Unknown] | 00:01 |
| chrismsnz | there has been a fix committed to the kernel tree apparently - it's a fairly serious bug (as it's a fairly common card) and I'd just like to pass on the fact that it's fix now for possible backport to the lucid kernel and inclusion on new installation media for lucid(10.04.2) and natty | 00:02 |
| JFo | chrismsnz, do you have a link to the discussion or a SHA1 I can use? | 00:11 |
| chrismsnz | the kernel discussion? | 00:12 |
| JFo | where they discussed the issue on the LKML | 00:12 |
| chrismsnz | this was in linux-scsi: http://marc.info/?l=linux-scsi&m=129021716922966&w=2 | 00:12 |
| JFo | or a SHA1 of the fix as it exists in the kernel tree | 00:12 |
| chrismsnz | i may have another one, stand by | 00:13 |
| chrismsnz | here is lkml: http://www.linux-archive.org/device-mapper-development/459117-data-corruption-stex-promise-hw-raid-driver-device-mapper.html | 00:14 |
| chrismsnz | ah, that actually looks like dm-devel D: | 00:14 |
| JFo | chrismsnz, looks like that is still an ongoing discussion | 00:14 |
| JFo | yeah | 00:15 |
| JFo | from the rest of the thread, this is still being discussed | 00:15 |
| chrismsnz | sorry JFo: here is the actuall diff: http://marc.info/?l=dm-devel&m=129070330506836&w=2 | 00:15 |
| JFo | k | 00:15 |
| JFo | yeah, that is his proposed change | 00:16 |
| JFo | the conversation looks like they are trying still to determine the best way to address the problem | 00:16 |
| JFo | hmm | 00:16 |
| JFo | wait a sec... | 00:16 |
| JFo | nevermind | 00:17 |
| JFo | I read the patch wrong | 00:17 |
| JFo | :) | 00:17 |
| * JFo is tired | 00:17 | |
| * jjohansen steps away for a bit | 00:17 | |
| === jjohansen is now known as jj-afk | ||
| JFo | chrismsnz, let me have a look at this tomorrow and I will see where it stands and talk to the team about its possible inclusion based on the current state | 00:18 |
| chrismsnz | i can't see where it was committed :\ | 00:18 |
| chrismsnz | okidoki - feel free to drop in on/update the bug there were a couple others watching it too | 00:18 |
| JFo | yeah, the last message in the thread seems to indicate it is still in flux | 00:18 |
| chrismsnz | when you have some answers, I mean :) | 00:18 |
| JFo | http://marc.info/?t=129070303200002&r=1&w=2 | 00:19 |
| JFo | looking there ^ | 00:19 |
| JFo | ok | 00:19 |
| JFo | will do | 00:19 |
| firewave | Hi everybody ! | 05:20 |
| firewave | I've just received a new kernel update on my server | 05:20 |
| firewave | Someone could tell me how to print the changelog in a terminal ? | 05:21 |
| firewave | LOL... yeah ok.. aptitude changelog... I'm a bit a looser this night | 05:23 |
| firewave | sorry | 05:23 |
| === LibertyZero is now known as _LibertyZero_ | ||
| === smb` is now known as smb | ||
| * apw marvels at the funny white stuff falling from the sky | 08:50 | |
| smb | apw, Has it made its way to your place then? :) | 08:51 |
| * smb waits for messages of chaos from the island | 08:51 | |
| === jj-afk is now known as jjohansen | ||
| apw | smb, yep, i expect we'll be closed before long | 08:55 |
| jjohansen | snow again, but they just had some last year | 08:55 |
| apw | at least fibre works under water | 08:55 |
| apw | jjohansen, this is _settling_ thoug | 08:56 |
| smb | apw, The bits could freeze | 08:56 |
| apw | heheh | 08:56 |
| smb | apw, And did you not have the settling last year too? | 08:56 |
| apw | my bits could freeze | 08:56 |
| apw | smb, yeah we did, but this is the very first we've seen and its settling | 08:56 |
| smb | Ah you mean with an inserted "this year" ;9 | 08:57 |
| smb | :) | 08:57 |
| smb | Though I try to remember when it was that I barely made it there in between strike and snow... | 08:58 |
| * smb remembers walking in the snow in London and he usually does not remember that long | 08:59 | |
| * smb wonders whether cking can hear him through all that snow | 09:04 | |
| apw | smb, heh yea, /me goes out to see how deep it is | 09:05 |
| smb | apw, Hope we see you again | 09:06 |
| cking | 1 cm of snow here | 09:12 |
| smb | cking, Wasn't it 1 inch a minute ago? :) | 09:12 |
| cking | heh, my initial guess was inaccurate and based on defunct non-metric measurements | 09:16 |
| smb | cking, Interesting question: do you think metric and convert or the other way round? | 09:17 |
| cking | smb, I was educated in metric but I think in both imperial and metric and select the one that gives me best 1 unit measurements, e.g. if it's ~2.5cm, I call it an inch, if it's ~30cm I call it a foot, but if it's ~3 foot I call it a meter | 09:20 |
| RAOF | apw: I'm looking at the kernel delta assigned to me - the nouveau noaccel quirking patches. We should drop those and see if anything breaks. | 09:24 |
| smb | RAOF, He may still have some fun in the snow at the moment | 09:25 |
| RAOF | Mmm, snow. | 09:26 |
| smb | You know that strange pieces of fluffly frozen water | 09:27 |
| RAOF | Not *all* of Australia is tropical or sub-tropical :P | 09:28 |
| RAOF | We have such wonders in Tasmania, also. | 09:29 |
| cking | smb, http://www.amd64.org/support/microcode.html | 09:30 |
| smb | cking, ta | 09:31 |
| smb | RAOF, Yeah, probably we always think of AUS as far far south. Must be hot there. :) | 09:32 |
| RAOF | Heh. | 09:32 |
| * smb looks around for apw | 09:52 | |
| apw | RAOF, heh, i was going to ask you abut those tosay | 10:04 |
| apw | had to pop to pick something up, which took longer than i imagined | 10:04 |
| apw | seems its is slippy slidey out there under foot | 10:05 |
| smb | apw, We were about to send the rescue team. :-P | 10:05 |
| apw | smb, thanks :) | 10:06 |
| RAOF | :) | 10:08 |
| apw | RAOF, ok those are gone from the next upload | 10:08 |
| apw | RAOF, we also have this one: UBUNTU: SAUCE: i915 -- disable powersave by default | 10:09 |
| apw | i seem to remember that one was to stop some odd screen quivering we were seeing | 10:09 |
| RAOF | Yeah. | 10:09 |
| apw | want to think about that one with your X buddies and make a recommendation on it? | 10:11 |
| RAOF | Sarvatt knows more about that; I'll ping him tomorrow. | 10:11 |
| apw | RAOF, i have marked your task done for the ubuntu delta :) | 10:12 |
| RAOF | Ta. | 10:12 |
| smb | apw, Is there any way to get from the generic release status to the personal item summary? I fail to see it if there is | 10:23 |
| apw | smb, there is not, i know of now way to get there. i tend to use the personal _bit_ of the overall burndown myself | 10:23 |
| apw | smb, http://people.canonical.com/~platform/workitems/natty/canonical-kernel-team.html | 10:24 |
| apw | and scroll down to your name (the second occurance) | 10:24 |
| smb | apw, Cool. Actually, couldn't we just add that link to the natty links? | 10:24 |
| apw | we might be able to i guess | 10:25 |
| smb | apw, I can do that if it is ok with you | 10:25 |
| apw | smb, i am not sure there is an overall cycle personal version, which seems wrong | 10:25 |
| smb | apw, Oh actually it is there | 10:27 |
| apw | smb, hmmm where ? | 10:27 |
| smb | Just called "overall burndown chart" | 10:27 |
| smb | Under milestonded features | 10:27 |
| smb | stoned | 10:27 |
| apw | oh that link is there yes, but i pointed you tot | 10:28 |
| apw | to that one earlier ... | 10:28 |
| smb | apw, Like a few minutes ago. :) But I could not even guess from the title that this is the team based list. And yes, you seem to have sent me a link to a personal burndown page as well which seems to be produced by the same stuff. now I just need to find how to get there | 10:31 |
| apw | there are no links to the u/ prefixes as far as i know yet, i wonder why the names in the main pages do not go there | 10:33 |
| apw | i may propose changing those links to that | 10:33 |
| smb | Yeah, that would be more helpful than the launchpad blueprint assignment page | 10:33 |
| smb | apw, One thing to improve imo would be to include the previous tasks at least in the overall page (which is naturally named ubuntu-11.04 instead of natty *grrr*) | 10:38 |
| apw | ubuntu-11.04 is not overall, it is the stuff for the release milestone | 10:39 |
| apw | stuff milestoned after the beta | 10:39 |
| apw | there seems to be a missing global one under just your name which there in the other views | 10:39 |
| apw | the u/ stuff is very new, and a little broken i think | 10:39 |
| smb | Ah ok. | 10:40 |
| === ogra_ac_ is now known as ogra_ac | ||
| ogra_ac | apw, i guess you have seen cooloney's mail | 10:51 |
| cooloney | ogra_ac: i've talked with apw already, heh | 10:52 |
| ogra_ac | (i dont expect any other outcome from our tests to be honest) | 10:52 |
| ogra_ac | ah cool | 10:52 |
| ogra_ac | i just want to know whats the way forward now that we have positive results | 10:52 |
| cooloney | ogra_ac: i might need a xM machine for testing. | 10:52 |
| apw | ogra_ac, indeed | 10:52 |
| cooloney | ogra_ac: i just have a beagle c3 | 10:52 |
| apw | ogra_ac, i really have little idea of the scope of omap3, ie what boards you expect it to work on other than beagle | 10:53 |
| ogra_ac | cooloney, i actually expect their kernel to run better on XM | 10:53 |
| apw | ogra_ac, to put it another way i am not sure what our acceptance criteria will be | 10:53 |
| ogra_ac | apw, well, we can only put one bootloader into the images by default anyway | 10:53 |
| ogra_ac | so i would expect beagle to be the default and for others we might provide u-boot binaries that you can easil exchange on the created SD card | 10:54 |
| ogra_ac | apw, i would keep the supported set of boards as narrow as we can, everything you can do additionally through replacing bootloaders would be optional and unsupported (also untested) by us | 10:55 |
| apw | ogra_ac, so it is fair to say that 'works on beagle satisfactorly' is the criteria | 10:55 |
| ogra_ac | yes | 10:55 |
| apw | ogra_ac, ok cool, is someone from your side going to try the swapping in of this kernle into the CD image and give it a test ? | 10:55 |
| ogra_ac | there are requirements for IGEP2 boards, buit imho thats really up to linaro (i.e. if it works at release time its fine, i wouldnt do SRUs for them) | 10:56 |
| ogra_ac | apw, as soon as we a) have images again and b) gruemaster has his setup ready | 10:56 |
| ogra_ac | i'll bring it up in the arm IRC meeting today | 10:56 |
| apw | ogra_ac, excellent, did the meta shenaegens sort you out image wise | 10:56 |
| ogra_ac | partially | 10:57 |
| ogra_ac | there are other packages blocking atm | 10:57 |
| ogra_ac | we have a bunch of dektop packages that depend on kde which currently doesnt build at all on arm | 10:57 |
| ogra_ac | s/depend/build depend/ | 10:57 |
| ogra_ac | we're sorting that remaining stuff this week | 10:58 |
| apw | ogra_ac, thats a little annoying, i wonder why we'd want to install kde requiring apps by default on the gnome images | 10:58 |
| apw | ogra_ac, but the kernel is out of your way | 10:58 |
| ogra_ac | *build depend* ... we dont install any kde stuff | 10:58 |
| ogra_ac | but i.e. transmission builds a kde client from the same source | 10:59 |
| apw | ogra_ac, ahh i see, now that does make sense | 10:59 |
| ogra_ac | so it is ftbfs currently because kdelibs doesnt exist | 10:59 |
| ogra_ac | i will unseed it from our image for A1 | 10:59 |
| ogra_ac | similar stuff happens to ubuntuone | 10:59 |
| apw | such is the life of an A1 CD | 11:00 |
| ogra_ac | heh, yeah | 11:00 |
| tseliot | apw: how can I get the source for this kernel? (the source package is empty): http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.11-lucid/ | 11:07 |
| apw | tseliot, that is not easy, back there the source packages were broken, later we have included the patches so you can recreate it more easily | 11:08 |
| apw | i may have the branch in the repository though | 11:09 |
| apw | the master source for it would be v2.6.32.11 from the stable tree of course | 11:09 |
| apw | tseliot, what do you need to use it for, so i can work out what the best way to help you is | 11:09 |
| tseliot | apw: a friend of mine needs the sources for that vanilla kernel with the ubuntu packaging scripts | 11:10 |
| apw | tseliot, ok i've pushed the patches that are on that branch into the result directory like the later versions | 11:13 |
| apw | so he'd need v2.6.32.11 and then apply the 4 patches there | 11:13 |
| tseliot | apw: what branch is that? | 11:14 |
| apw | tseliot, ignore the branch, the builder leaves some mess arround for debugging which i looked at is all | 11:15 |
| apw | i've pushed the delta to the results directory | 11:15 |
| tseliot | apw: ah, ok, so he should get the vanilla kernel from upstream and apply those patches. Thanks | 11:17 |
| apw | tseliot, yes that is exactly what the build system does, well it generates the patches but you get the idea | 11:19 |
| tseliot | apw: I've learnt something new :) | 11:19 |
| apw | tseliot, some of the older ones are missing the patches cause we thought the source packages were useful, but they arn't and actually the patches are simpler so we switched over relativly recently | 11:20 |
| apw | if i have the build branches i can convert an old result, as i have for this one, but its not worth the effort unless someone whines | 11:21 |
| tseliot | apw: yes, I agree | 11:22 |
| rsalveti | apw: cooloney: ogra_ac: I have a beagle-xm and can test if everything works fine | 11:54 |
| rsalveti | but it should, as it's already being used by linaro's image | 11:54 |
| ogra_ac | rsalveti, that would be helpful | 11:54 |
| cooloney | rsalveti: great, man | 11:54 |
| ogra_ac | we need to know if jasper behaves etc | 11:54 |
| rsalveti | if they are merging the ubuntu sauce on top of the tree, it should work basically the way we're expecting | 11:54 |
| ogra_ac | thats a part that cooloney cant test with rootstock images | 11:54 |
| cooloney | rsalveti: yeah i think so. | 11:54 |
| rsalveti | cooloney: did you change the config or used the default one? | 11:55 |
| cooloney | rsalveti: it contains all the ubuntu delta sauce patches | 11:55 |
| cooloney | rsalveti: i didn't change any code in there tree. | 11:55 |
| cooloney | rsalveti: it just works | 11:55 |
| rsalveti | ogra_ac: we can easily test with jasper at the moment we have any image around | 11:55 |
| rsalveti | then we can just replace the important pieces and we're ok | 11:55 |
| cooloney | rsalveti: you can build it from their source code. | 11:55 |
| rsalveti | cooloney: cool | 11:55 |
| rsalveti | cooloney: sure | 11:56 |
| ogra_ac | rsalveti, there are images from the 19th | 11:56 |
| rsalveti | cooloney: would be good to compare the config options with our omap3 debs | 11:56 |
| ogra_ac | for jasper testing that should suffice | 11:56 |
| ogra_ac | (i think X wont start on these though) | 11:56 |
| rsalveti | ogra_ac: cool, if nothing that important changed since then, I think we're ok | 11:56 |
| rsalveti | ok, np | 11:57 |
| cooloney | rsalveti: yeah, will do it soon. | 11:57 |
| rsalveti | but it should work basically the same way, don't expect much of new features, but new bugs could be around :-) | 11:57 |
| rsalveti | they merged most of our omap specific patches and ubuntu sauce | 11:57 |
| rsalveti | ogra_ac: and for now let's just produce beagle compatible images, should be enough for most omap 3 boards around | 11:59 |
| rsalveti | beagle and beagle xm should work with same kernel and boot loader | 11:59 |
| rsalveti | then for igep we just build instructions, should be fine | 11:59 |
| ogra_ac | yes | 12:00 |
| ogra_ac | thats what i said above | 12:00 |
| ogra_ac | with beagle being the QAed and officially supported platform | 12:00 |
| rsalveti | yeah | 12:02 |
| ogra_ac | what we need to make sure is that john doesnt cut down the config | 12:03 |
| ogra_ac | (i know he planned to) | 12:03 |
| rsalveti | otherwise we need our own config | 12:04 |
| ogra_ac | i.e. we want all usb dvb drivers, all usb wlan drivers etc etc | 12:04 |
| ogra_ac | everything you could potentially plug in | 12:04 |
| Dabian | Darn, channel is logged? Where is my privacy? :P | 12:13 |
| Dabian | OK .. joke aside ... | 12:14 |
| Dabian | I'm on Ubuntu GNU/Linux. Today my updatemanager tells me to upgrade kernel for security reasons. CVE-2010-3848, CVE-2010-3849 and CVE-2010-3850 ... but these are only proposed .. and secret (reserved) .. anyone know about those? | 12:15 |
| ubot2 | Dabian: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3848) | 12:15 |
| ubot2 | Dabian: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3849) | 12:15 |
| ubot2 | Dabian: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3850) | 12:15 |
| Dabian | ubot2: Thats what I am say'in, d'oh! | 12:15 |
| ubot2 | Dabian: Error: I am only a bot, please don't think I'm intelligent :) | 12:15 |
| Dabian | I dont, lol. :) | 12:15 |
| maco | better patched than vulnerable? | 12:16 |
| Dabian | maco: Question is .. vunerable to what? | 12:16 |
| Dabian | Usually I like to know what kinda patches I'm installing. :) | 12:16 |
| maco | you could view the source | 12:16 |
| maco | get the current and previous source packages off of launchpad and diff them | 12:17 |
| Dabian | Can I apt-source a vunerable package? | 12:17 |
| maco | or look at the git trees on kernel.ubuntu.com | 12:17 |
| maco | apt-get source package=version | 12:17 |
| Dabian | the latter looks more convenient, I guess git trees have diff? | 12:17 |
| maco | yep | 12:18 |
| Dabian | maco: Do you know where I find the main branch? | 12:20 |
| maco | the one thats named ubuntu.maverick or ubuntu.lucid (whatever you're on) would be it | 12:20 |
| Dabian | maverick is the perfect ten, right? | 12:20 |
| maco | with no developers' names attached | 12:21 |
| maco | yeah | 12:21 |
| Dabian | There is no developer named "ubuntu"? | 12:22 |
| maco | http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=summary | 12:22 |
| Dabian | right just found it | 12:22 |
| Dabian | Leann is also mentioned as the last comitter. | 12:22 |
| Dabian | hmm .. bad Leann .. using goto :P | 12:23 |
| Dabian | :D | 12:24 |
| Dabian | Hmm .. I dont understand why he doesn't make the check earlier in the code? | 12:25 |
| maco | he who what? | 12:26 |
| Dabian | Leann .. when he patch this. | 12:26 |
| Dabian | He might have a good reason, I'm not expirienced kernel developer. | 12:26 |
| maco | er..."leann" is a woman's name | 12:26 |
| Dabian | In russia? | 12:27 |
| maco | no, she's not russian | 12:27 |
| Dabian | OH .. cool, we have female kernel-devs now? B) | 12:27 |
| maco | yeah...theyve existed for a long while... | 12:27 |
| Dabian | Cool | 12:28 |
| maco | im a lady with a patch in the kernel too :P | 12:28 |
| Dabian | Neat :) | 12:28 |
| Dabian | Ahh .. Mackenzie :) | 12:28 |
| Dabian | I think I recognice your name from Ubuntu-Women? :) | 12:29 |
| maco | yes | 12:29 |
| maco | i imagine she checks it there in order to keep the check near the reason its needed... ie, the fact that saddr is about to show up on the right side of an = | 12:29 |
| Dabian | Its been a while since I have been active there. (As if I were ever active there, but I used to follow the mailing-list some) | 12:29 |
| Dabian | maco: Yeah .. the code seems a bit bit complicated though .. I think I'll copy it to emacs to get a better view. | 12:30 |
| Dabian | maco: Funni thing is ... there is already a check in the code for saddr. | 12:34 |
| Dabian | Oh .. now I get it .. its legal to call this with saddr that is NULL. | 12:34 |
| Dabian | Thats probably why she doesn't check earlier. | 12:36 |
| maco | the other time in that struct that saddr shows up to the right of a = is inside a if (saddr == NULL) {} else { /* right here */ } -- so that one is checked | 12:39 |
| maco | s/struct/function/ cant read | 12:39 |
| maco | hm though line 506... | 12:41 |
| Dabian | yeah | 12:42 |
| maco | ogasawara: when you're around, is there a possibility of a null-pointer dereference down at line 506 on [ubuntu/ubuntu-maverick.git] / net / econet / af_econet.c like the one you fixed up above it? | 12:43 |
| === jjohansen is now known as jj-afk | ||
| Dabian | maco: I fear you might be right, if CONFIG_ECONET_NATIVE is not defined, then Leanns check is never passed. | 12:48 |
| Dabian | maco: (Otherwise we return in line 414) | 12:50 |
| maco | her check takes place inside an if() anyway | 12:50 |
| Dabian | Yeah .. if the that if is false, then CONFIG_ECONET_NATIVE wont be defined. | 12:50 |
| Dabian | I am babling. | 12:51 |
| apw | CONFIG_* comes from outside | 12:51 |
| Dabian | Its the if that is deciding, you're right. | 12:51 |
| maco | hmm? the define takes place elsewhere | 12:51 |
| Dabian | But if the if is false, her check is skipped. | 12:51 |
| maco | im referring to this: if (dev->type == ARPHRD_ECONET) | 12:51 |
| Dabian | maco: Exactly .. thats the culpit. :) | 12:51 |
| maco | the null pointer dereference she catches is inside that if. there's another case of that pointer being used after the if ends. thats teh one im worried about | 12:52 |
| Dabian | maco: just before the #if. | 12:52 |
| Dabian | (Which is not significant here) | 12:52 |
| Dabian | maco: Right. | 12:52 |
| maco | i dont know where youre looking now... | 12:52 |
| Dabian | maco: I just confused both of us, I agree with you. :) | 12:52 |
| maco | hah ok | 12:53 |
| maco | apw: down at line 506...is that one ok? | 12:53 |
| maco | apw: or were you just interjecting about the macros without looking at what we are? | 12:53 |
| Dabian | maco: He was just pointing out that I was babbling, I think. :) | 12:54 |
| Dabian | ze :) | 12:54 |
| maco | you got it right this time | 12:54 |
| Dabian | lol | 12:54 |
| apw | Dabian's statement was that the CONFIG_ would change based on an if, which doesn't sound right, not looked at the code no | 12:54 |
| Dabian | I have no idea what ARPHRD is. :) | 12:55 |
| maco | apw: oh ok. i think Dabian just mixed up #ifdef and #define | 12:55 |
| Dabian | apw: You're right. I confused the #if with the "if". | 12:55 |
| maco | ah | 12:55 |
| Dabian | Well, actualy I assumed that both if and #if would act the same, which is even worse, lol. | 12:56 |
| Dabian | If the #if is false | 12:59 |
| Dabian | ahh never mind. | 13:00 |
| Dabian | maco: I think you found a problem, unless we know that if saddr == NULL then udpsock == NULL. | 13:02 |
| maco | Dabian: the line im pointing to is not inside an if statement at all | 13:02 |
| Dabian | maco .. no | 13:03 |
| Dabian | maco but look at line 420 | 13:03 |
| Dabian | maco: I assume that line has to be passed before you reach line 506 | 13:03 |
| maco | ah because it returns | 13:03 |
| Dabian | :) | 13:03 |
| Dabian | But I am not sure we know that udpsock is NULL, if saddr is NULL. | 13:04 |
| Dabian | I'm not a kernel developer. | 13:04 |
| Dabian | I just find it interesting to look at the code sometimes. :) | 13:05 |
| Dabian | maco: In any case, I would probably do something like: | 13:08 |
| Dabian | eb = (struct ec_cb *)&skb->cb; | 13:08 |
| Dabian | if(saddr == NULL) | 13:08 |
| Dabian | kernel_panick("Line 506, af_econet - saddr == NULL"); | 13:08 |
| Dabian | 13:08 | |
| Dabian | before "eb->cookie = saddr->cookie;", just to be sure. | 13:08 |
| Dabian | (Not sure of the syntax for kernel_panic). | 13:08 |
| Dabian | maco: To me it looks like udpsock comes from outside the function, so I am guessing you found a real problem. | 13:14 |
| Dabian | saddr, on the other hand, comes from "msg->msg_name" which is passed as argument to the function, in line 266. | 13:16 |
| apw | sconklin, you might want to review this above conv as it may indicate a further issue with one of our CVEs | 13:26 |
| Dabian | apw: Nice that ARM is better secured than other platforms for once though, right? :) | 13:28 |
| smb | apw, ogasawara was driving those. But yes, all of those did touch econet | 13:28 |
| smb | But no arm release was done | 13:28 |
| apw | Dabian, heh yeah by mostly being unbootable on any actual h/w :) | 13:28 |
| Dabian | lol | 13:28 |
| smb | Dabian, The whole conversation is too big to quickly read. Is what you see on arm or something else? | 13:29 |
| Dabian | smb: It was maco that pointed out that line ... (lemme check) might lead to null-pointer problem. | 13:30 |
| maco | smb: line 506 on http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=blob;f=net/econet/af_econet.c;h=174c106ec95ac04a0c46a3cf8cf5d499bdfe390a;hb=00a70d00666bbe8e7035f582ac5674827e351870 | 13:30 |
| Dabian | Thanks :) | 13:30 |
| maco | smb: further up at 357 ogasawara checked for null before dereferencing that saddr pointer. at 506 it's dereferenced again without a null check. the first null check took place inside an if though, so may not have been run when 506 is reached | 13:31 |
| Dabian | (And 506 is apparently reached, unless udpsock is NULL). | 13:32 |
| smb | maco, Sounds about right. I just need a minute to grab the changes to have the whole picture | 13:32 |
| Dabian | (udpsock seems to be external) | 13:32 |
| smb | I was just wondering about the arm statement | 13:33 |
| maco | smb: i think Dabian is watching -meeting | 13:33 |
| maco | and my brain refuses to keep the two smb's straight -_- | 13:33 |
| smb | There is only one on my side. :) | 13:33 |
| Dabian | smb: The first check, which is committed, only concerns platforms with ARM hardware, I guses, according to the "#IF". | 13:34 |
| Dabian | What is -meeting? | 13:34 |
| maco | different channel | 13:34 |
| maco | Dabian: can you use line numbers? | 13:34 |
| smb | Dabian, Ah, well arm was those topic branches not released (at least for Lucid, but there is Maverick with at least one arm inside the master) | 13:34 |
| Dabian | Sure. | 13:35 |
| === doko_ is now known as doko | ||
| Dabian | smb: But the problem maco points out, applies to all platforms, as far as I can tell. | 13:35 |
| maco | there are 3 places saddr is used. 315, 362, 506 | 13:35 |
| maco | what makes you think any of them are arm-specific? | 13:36 |
| Dabian | maco: Lemme find the line number. I might be wrong though. :) | 13:36 |
| Dabian | line 341: #ifdef CONFIG_ECONET_NATIVE | 13:37 |
| Dabian | 13:37 | |
| Dabian | I think only ARM has native econet? | 13:37 |
| maco | oh. no idea about that | 13:37 |
| Dabian | I am just guessing. | 13:37 |
| Dabian | maco: Line 506 is outside that "if" though. | 13:38 |
| Dabian | (#if, even) | 13:38 |
| maco | yes | 13:38 |
| Dabian | So while Leanns fix maybe applies to ARM only, yours is general. | 13:39 |
| Dabian | Its inside the line 417: #ifdef CONFIG_ECONET_AUNUDP | 13:39 |
| Dabian | 13:39 | |
| smb | Actually I do not really see that line which does not check for NULL getting added. Rather seemed to be there before | 13:41 |
| Dabian | smb: 506 | 13:41 |
| smb | But its a bit hard from the patch and a function that stretches on for miles | 13:41 |
| maco | smb: yes it was thre before. she added a check for near line 357, and im worried that she should also have added one to 06 | 13:41 |
| maco | *506 | 13:41 |
| Dabian | smb: Yeah .. the code is pretty long, I wonder if the function could be refactored. | 13:42 |
| smb | maco, Maybe. I am not that good to understand the flow that quickly. :) | 13:43 |
| smb | Give me a minute | 13:43 |
| apw | Dabian, not for a backported fix, minimum changes only | 13:44 |
| Dabian | smb: Its actually not as hard as you think. The problem is if the "if" at line 339 is false (dev->type != ARPHRD_ECONET), then code-flow skips Leanns check in line 358, and if udpsock != NULL (checked in line 420), the code will hit line 506, with a possible null-value in saddr. | 13:45 |
| Dabian | (Assuming the "#ifdef"'s allow it). | 13:46 |
| maco | its just a single C function thats got as many lines as my senior project did of python :P | 13:46 |
| Dabian | apw: Right .. but maybe an idea for development branch. :) | 13:48 |
| smb | So ok, yes, for that other case /#ifdef it seems missing | 13:48 |
| smb | But has so before | 13:49 |
| Dabian | smb: Which doesn't make it right, though. :) | 13:49 |
| smb | Nope | 13:49 |
| smb | The question is just whether it is in the class of security oh my god | 13:49 |
| Dabian | I think maco found a new problem, of same natuer. | 13:49 |
| smb | or just "normal" it crashes | 13:49 |
| maco | smb: from leann's commit message on her change it seems like a normal-it-crashes with unknown security implications | 13:50 |
| smb | maco, The thing is that all three were passed down as a bundle of sorts | 13:50 |
| Dabian | 3 cve's though? | 13:51 |
| smb | maco, You found a true other case of brokeness. I just would avoid a security update for it if possible | 13:51 |
| maco | ok | 13:51 |
| smb | Which would be required if we broke something new | 13:51 |
| maco | so how to handle discovery of brokenness? | 13:52 |
| Dabian | smb: When crashing and network is involved .. I'd say we're close to a security issue. Question is if its remotely exploidable, I guses? | 13:52 |
| smb | Dabian, Right. I would not be sure at the moment. | 13:52 |
| smb | On the other hand that econet protocol is not loaded by default and I don't know the use of it either. | 13:53 |
| smb | maco, I'd probably go and contact the original author about it | 13:53 |
| Dabian | smb: Then again, i guess even if its only locally exploitable, it will still be security issue, unless you need priviledges to call the function. | 13:54 |
| smb | Err | 13:54 |
| smb | Which was in this case Leann. | 13:54 |
| maco | heh | 13:54 |
| smb | Guess she sent that somewhere. So maybe we ask her where | 13:55 |
| === yofel_ is now known as yofel | ||
| sconklin | maco, smb: Just wandering in . . . econet is essentially unmaintained, so these patches were arrived at through a group effort | 14:01 |
| smb | maco, sconklin Ijust checked Linus upstream. | 14:01 |
| smb | Seems that what went there is different and exists early | 14:02 |
| smb | Instead of checking for NULL multiple times | 14:02 |
| Dabian | Heh .. that was my original idea, to exit early. | 14:04 |
| Dabian | But I don't know what the code actually does. | 14:04 |
| Dabian | It seems like its possible to do "something" useful, even if saddr is NULL, but I am not sure what. | 14:05 |
| Dabian | smb: I guess that explains why the code missed the check later in the code. | 14:06 |
| maco | i was guessing it was more to do with the spaghetti... | 14:06 |
| smb | Dabian, I think (but I cannot say for sure) that we may have a patch that evolved later before hitting upstream | 14:06 |
| Dabian | "a patch that evolved later, before hitting upstream"? (Im not native english, what does this mean?) | 14:08 |
| smb | Dabian, It means it changed | 14:09 |
| smb | And in Linus tree there is a different change that we have now | 14:09 |
| Dabian | smb: As in .. you made a patch, but changed it before shipping it upstream? | 14:09 |
| smb | As in we got the patch from someone (at least the other two) and maybe found the issue and told it the other person and on the way to upstream it changed even more but nobody told us | 14:10 |
| smb | We just now see it in Linus tree | 14:10 |
| Dabian | Ahh ok ... so .. you got Linus.A code .. patched it to Linus.Ap1 .. sending it upstream, when Linus.B code is available, the changes dosen't match the Linus.Ap1 code. | 14:11 |
| Dabian | Hmm .. I guess this means we have to check the Linus.B code, to see if it checks correctly? | 14:12 |
| Dabian | and if it does, then eventually adopt it? | 14:12 |
| smb | As far as I see it is safer as it does the check right at the beginning of the function and immediately returns with an error if saddr is NULL | 14:13 |
| smb | So mostly it is checking whether the other two patches are the same as we got or different/better and replace the changes made in our tree whenever needed | 14:14 |
| Dabian | smb: Thats safe. However, if something useful can be done, even if saddr is NULL, maybe Leanns patch is supior (with a check added for line 506) | 14:14 |
| smb | Dabian, Maybe, though that sounds like something to discuss with those upstream people working with that as an additional patch. This one mainly targets to prevent an oops | 14:17 |
| Dabian | smb: Right. I guess the code is viewable on http://kernel.org ? | 14:20 |
| smb | Dabian, Yes. I saw it in the git tree | 14:21 |
| Dabian | You don't happen to have the url handy? | 14:21 |
| Dabian | Is the change in linux-next, mainline, snapshot or stable? | 14:22 |
| smb | Dabian, I mainline. But as I use git I forget the url. A second | 14:23 |
| Dabian | aah ok. | 14:23 |
| smb | http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git | 14:24 |
| smb | http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa0e846494792e722d817b9d3d625a4ef4896c96 | 14:24 |
| smb | Dabian, the second link is the actual commit for that | 14:25 |
| Dabian | smb: Right, they just exit if saddr is null, or msg->msg_namelen is short. if msg or msg->namelen is NULL, they still have a problem though. Not sure if thats possible. | 14:31 |
| Dabian | I also wonder why they set the mutex before the check. | 14:31 |
| Dabian | Why not change line 291 to: | 14:32 |
| apw | jdstrand, hiya | 14:33 |
| Dabian | if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_CMSG_COMPAT)) || (saddr == NULL || msg->msg_namelen < sizeof(struct sockaddr_ec)) | 14:33 |
| Dabian | that way they can skip line 300-303 | 14:33 |
| apw | they have likely gone for clarity over performance, as this is a dead protocol anyhow | 14:34 |
| smb | Dabian, Just personal feeling but this does look a bit like more spagetti | 14:34 |
| Dabian | change line 288 to: * Check the flags and verify address. | 14:34 |
| jdstrand | hey apw | 14:34 |
| apw | was it you who was asking me something something last night? | 14:34 |
| Dabian | smb: Well, you could add a line after 292, with a nice comment, and another if. That would look ugly to me, but personal taste differs, and it would be equally good. In both cases, you don't have to lock the mutex. | 14:35 |
| Dabian | There might be a reason they lock the mutex first though, but I can't guess what it might be. | 14:36 |
| Dabian | smb: At any rate, this GNU patch solves the problem maco spottet. | 14:37 |
| smb | I guess the mutex is held for being able to make the changes on success. But right, it will fix that problem. And i am probably lazy there but I'd leave improvements to people actually using that protocol. :-P | 14:39 |
| apw | jdstrand, was it you who was asking me something something last night? | 14:44 |
| jdstrand | apw: I did. hold on... | 14:44 |
| Dabian | I have no idea what the protocol is used for. :) | 14:45 |
| jdstrand | 13:52 < jdstrand> apw: hi! I'm looking at bug #507148, but you gave maverick kernels for a bug in lucid | 14:45 |
| ubot2 | Launchpad bug 507148 in xserver-xorg-video-ati (Ubuntu Lucid) (and 4 other projects) "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500 (affects: 8) (heat: 46)" [High,Invalid] https://launchpad.net/bugs/507148 | 14:45 |
| jdstrand | 13:53 < jdstrand> apw: in other words, mdeslaur and I reported the problem back in the lucid cycle, and I followed up on it a lot and it was fixed in lucid. was the regression on lucid or maverick? | 14:45 |
| jdstrand | 13:57 < jdstrand> apw: based on http://bugs.freedesktop.org/show_bug.cgi?id=26302#c27, it looks like a problem on the lucid kernel. would you mind making lucid kernels available for testing? | 14:45 |
| jdstrand | 14:03 < jdstrand> apw: acutally, it seems both lucid and maverick, but a lucid kernel would be most appreciated, and I could confirm whether or not reverting/going with upstream causes a regression on lucid release | 14:45 |
| ubot2 | Freedesktop bug 26302 in Driver/Radeon "[M7 LW] desktop runs out of video memory on ATI Radeon Mobility 7500" [Major,Resolved: fixed] | 14:45 |
| apw | jdstrand, ok the issue is that the fix as applied has been identified to cause a separate regression and therefore is bad. in theory there is a 'proper' fix to your issue which should fix you and not introduce this additional regression... | 14:47 |
| apw | jdstrand, ahh so you want a lucid kernel. i'll see about that | 14:47 |
| * jdstrand nods | 14:47 | |
| jdstrand | apw: I care most about not regressing the fix for my wife's laptop, and she runs lucid ;) | 14:48 |
| apw | jdstrand, i care about finding out if the replacement fix works for you too :) | 14:49 |
| jdstrand | apw: it would be most great if it was on the latest lucid-security kernel that went out yesterday | 14:49 |
| apw | as it happens i am building lucid ones for that, so i'll get you a link once they appear | 14:49 |
| jdstrand | apw: great, thanks | 14:49 |
| apw | the utter slowness of launchpad is a major detrement to the ammount of work i can get done, sigh | 14:56 |
| JFo | yep | 14:59 |
| cking | +1 | 14:59 |
| sconklin | apw: I've thought about a browser plugin that will accumulate the time I spend waiting for launchpad page loads | 14:59 |
| apw | i would be made very depressed by the results | 15:00 |
| JFo | oh please no | 15:00 |
| cking | sconklin, charge it to the LP team ;-) | 15:00 |
| JFo | that would end up making me a part-time employee ;-P | 15:00 |
| JFo | especially on Tuesday when I am gathering metrics for the meeting | 15:01 |
| apw | JFo, didn't you already do this: tag bugs 605614, 608429, 612626 and other similar bugs and monitor for new | 15:01 |
| ubot2 | Launchpad bug 605614 in linux (Ubuntu Maverick) (and 3 other projects) "[ATI] GPU lockup with gfxpayload=keep (affects: 10) (heat: 50)" [Undecided,Won't fix] https://launchpad.net/bugs/605614 | 15:01 |
| ubot2 | Launchpad bug 608429 in linux (Ubuntu) (and 1 other project) "black screen after grub menu (affects: 3) (heat: 32)" [Undecided,Incomplete] https://launchpad.net/bugs/608429 | 15:01 |
| ubot2 | Launchpad bug 612626 in linux (Ubuntu) (and 1 other project) "start in low graphic mode for nvidia card (affects: 1) (heat: 30)" [Undecided,Incomplete] https://launchpad.net/bugs/612626 | 15:01 |
| apw | yeah thanks ubot2 | 15:01 |
| JFo | heh | 15:01 |
| JFo | apw, I think those were the ones we needed to decide on a tag for | 15:02 |
| JFo | so I have not tagged them as yet | 15:02 |
| JFo | and I need to write something that will help me find any more | 15:02 |
| JFo | or any new ones | 15:02 |
| apw | as i am calling the bug list you are making the 'key bugs' list, how about kernel-key-gfxpayload | 15:03 |
| JFo | think that gfxpayload=keep was the search term used | 15:03 |
| apw | and kernel-key for our purposes | 15:03 |
| JFo | works for me | 15:03 |
| JFo | so kernel-key are the bugs on our list? | 15:03 |
| JFo | or just these bugs? | 15:03 |
| apw | i was thinking kernel-key was our equivalent of pcert as an input to the lsit | 15:04 |
| JFo | and we are eliminating the kernel-needs-review, kernel-candidate and kernel-reviewed tags? | 15:04 |
| JFo | ok | 15:04 |
| apw | JFo, i suspect we will but i have not though about those at all in this context | 15:04 |
| JFo | since we are no longer doing the top 50 | 15:04 |
| JFo | ok | 15:04 |
| * apw notes that your list is now updating regularly ... goood stuf | 15:05 | |
| JFo | :) | 15:07 |
| JFo | cron FTW! | 15:08 |
| === bjf[afk] is now known as bjf | ||
| JFo | tgardner, any thoughts on bug 676245 ? | 15:51 |
| ubot2 | Launchpad bug 676245 in linux (Ubuntu) "Broadcom NetXtreme II BCM5709 -- no network found on ISO install (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/676245 | 15:51 |
| JFo | the qa guys tell me that it worked on this box in the past | 15:51 |
| JFo | this is for Alpha 1 testing | 15:51 |
| tgardner | JFo, looking... | 15:52 |
| JFo | sorry, found during rather | 15:52 |
| JFo | thank you sir | 15:52 |
| apw | jdstrand, ok test kernels are in the bug | 15:52 |
| JFo | apw, any more thoughts on bug 670181 ? | 15:52 |
| ubot2 | Launchpad bug 670181 in linux (Ubuntu) "Dell Precision M6300 SD Card Reader (Ricoh R5C592 memory stick) Will Not Mount After Upgrade To 10.10 (affects: 2) (heat: 12)" [Medium,Triaged] https://launchpad.net/bugs/670181 | 15:52 |
| JFo | looks like the guy isn't even using an XD card | 15:53 |
| * JFo grows old waiting for LP to churn | 16:01 | |
| === jj-afk is now known as jjohansen | ||
| bjf | ## | 16:09 |
| bjf | ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting | 16:09 |
| bjf | ## agenda: https://wiki.ubuntu.com/KernelTeam/Meeting | 16:09 |
| bjf | ## | 16:09 |
| === diwic is now known as diwic_afk | ||
| === amitk is now known as amitk-afk | ||
| jdstrand | apw: thanks | 16:14 |
| smoser | jjohansen, ping here. | 16:30 |
| smoser | pv-on-hvm :-( | 16:30 |
| jjohansen | yeah | 16:30 |
| jjohansen | so if things verify out, it would be no pv-on-hvm in -virtual kernel | 16:30 |
| smoser | you think that is not a solvable problem ? | 16:32 |
| smoser | because that would basically force us to have separate cluster compute images (as they'll require pv-on-hvm) | 16:32 |
| smoser | can we pv-on-hvm as a module ? or is that not possible ? | 16:33 |
| jjohansen | it is already a module | 16:33 |
| bjf | ## | 16:38 |
| bjf | ## Kernel team meeting in 20 minutes | 16:38 |
| bjf | ## | 16:38 |
| smoser | jjohansen, it is ? | 16:42 |
| smoser | i swear i saw 'Y' yesterday | 16:42 |
| smoser | grep HVM /mnt/boot/config-2.6.37-5-virtual | 16:43 |
| smoser | CONFIG_XEN_PVHVM=y | 16:43 |
| smoser | or is that really just an option to something else that is a module (i only looked at the config) | 16:43 |
| JFo | sconklin, great find on that article | 16:55 |
| sconklin | I imagine that it made some people frown | 16:56 |
| JFo | I imagine so | 16:56 |
| apw | o/ | 17:00 |
| apw | heh missed | 17:00 |
| sconklin | http://www.techeye.net/software/nokias-meego-is-doomed | 17:04 |
| sconklin | apw: ^^ | 17:04 |
| apw | sconklin, tgardner, smb, summary in your inbox | 17:09 |
| smb | apw so it is | 17:09 |
| JFo | <-lunch | 17:33 |
| apw | sconklin, tgardner i have realised that when you hard push a branch it reports atomically where it was before in the return | 17:33 |
| apw | so you can tell if you could have lost anything when you push ... obvious | 17:34 |
| ogasawara | bjf, sconklin: have either of you started rebasing the master-next branches yet? just want to make sure I don't duplicate effort here. | 17:35 |
| apw | sconklin, another good reason for a master-merging or something, a marker that you are doing the rebase | 17:35 |
| bjf | ogasawara, i've done a first pass on maverick, we are still discussing | 17:36 |
| sconklin | apw: that may not be obvious or visible to people, since they may push without realizing that a new branch has been added | 17:36 |
| bjf | apw, i'm not sure what you are suggesting at this point | 17:37 |
| ogasawara | bjf: ack, I'll wait till you guys give me the green light. | 17:37 |
| albatros | i just wanted to report that bug 676644 has been fixed indeed, have been running tests for about 20 hours now without any errors | 18:03 |
| ubot2 | Launchpad bug 676644 in linux (Ubuntu Maverick) (and 1 other project) "sata-via: read errors, slowdowns with VIA VT6420 (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/676644 | 18:03 |
| albatros | whereas previously these tests resulted in thousands of errors | 18:04 |
| albatros | I just wondered if a fix for that issue in Maverick would be issued for lucid as well | 18:04 |
| apw | albatros, indeed i have marked it released for natty | 18:09 |
| apw | albatros, i was going to propose it for maverick, not sure about lucid | 18:09 |
| apw | albatros, i have not tried to backport that far | 18:09 |
| albatros | OK, not critical to me t all, thank you for working to fix things so quickly. | 18:11 |
| albatros | I'll just switch to maverick then. | 18:12 |
| albatros | bb | 18:13 |
| apw | jjohansen, hello | 18:15 |
| jjohansen | hey | 18:15 |
| apw | jjohansen, this i386 not working thing that might be the pvops on hvm thing | 18:15 |
| jjohansen | right | 18:15 |
| apw | jjohansen, seem this is a blocker for server | 18:15 |
| apw | jjohansen, have we confirmed this option is the issue ? | 18:16 |
| tgardner | apw, jjohansen is OTP | 18:16 |
| jjohansen | apw: no, I was testing last night, and I need to verify today | 18:16 |
| jjohansen | I had one of my tests fail | 18:16 |
| jjohansen | but I think that was my mistake | 18:16 |
| apw | jjohansen, ok ... we need to make a call in the next hour ish whether to turn it off, as its blocking server for alpha1 | 18:18 |
| apw | so talk to me when you are done with the phone | 18:19 |
| jjohansen | apw: I already talked to smoser about that, the answer is no | 18:20 |
| jjohansen | leave it for alpha 1 | 18:21 |
| apw | jjohansen, so they are happy with the status quo ... i'll feed that back | 18:21 |
| jjohansen | apw: I wouldn't say happy, but smoser doesn't want pv-on-hvm disabled either | 18:21 |
| apw | jjohansen, yep got you ... | 18:22 |
| apw | jjohansen, and thanks | 18:22 |
| smoser | apw, well, i'm not happy that i386 and t1.micro do not work | 18:23 |
| smoser | but turning off pv-on-hvm is not something i'm going to suggest should happen as it will cause other fallout that i dont want to deal with. | 18:24 |
| apw | smoser, a bit of a mess and no mistake | 18:24 |
| jjohansen | apw: the hope is that either my testing was bad, or we can work around it | 18:24 |
| smoser | well, i dont thin its likely that the honorable jjohansen has bad testing, so i'm crossing fingers for work around | 18:25 |
| smb | At least proving that this is the cause gives a better hint to where to search as the "no messages" before | 18:25 |
| smoser | and alpha2 having cluster-compute instances (which require hvm) and t1.micro and i386 all from the same -virtual kernel | 18:25 |
| apw | jjohansen, ok if we need to make any kernrel changes for alpha-1 it needs to be 'now' as we are already in freeze | 18:27 |
| jjohansen | apw: yeah, no requests from me, we will get it fixed for alpha2 | 18:28 |
| alex88 | after committing a change to natty kernel on http://kernel.ubuntu.com/git how much time it would be in the natty daily build? | 18:29 |
| apw | alex88, normally withing 24 hours in the pre-proposed builds, a few days in the main archive | 18:35 |
| alex88 | apw, you've commited that change that i need :) the marvell driver.. btw, pre-proposed builds means those here: http://cdimage.ubuntu.com/daily-live/current/ ? | 18:41 |
| alex88 | sorry for asking..can you please reply? I have to go in ten minutes.. | 18:48 |
| apw | alex88, no i mean the ones in the pre-proposed PPA | 18:53 |
| apw | we won't be putting that particular fix into a kernel on a CD until after alpha-1 | 18:54 |
| alex88 | oh, and what about the natty daily? i've tried to change the kernel into the live cd to let me install but i'm having problems with casper | 18:54 |
| apw | alex88, its not easy indeed. the natty daily CDs won't change until after the alpha releases now | 18:54 |
| alex88 | ok thank you very much.. | 18:55 |
| * tgardner --> lunch | 19:03 | |
| bjf | apw, what was that wiki formatting bug that you filed? (the bullet items were all the same level) | 19:09 |
| apw | bjf, hrm | 19:11 |
| apw | https://bugs.launchpad.net/ubuntu-website/+bug/675611 | 19:18 |
| ubot2 | Launchpad bug 675611 in ubuntu-website "with new ubuntu theme all bullet items are rendered off the left of the pane and at the same indent regardless of list indent (affects: 2) (heat: 17)" [Undecided,Fix released] | 19:18 |
| apw | bjf ^^ | 19:18 |
| bjf | apw, thanks | 19:18 |
| === diwic_afk is now known as diwic | ||
| * jjohansen -> lunch | 19:59 | |
| tgardner | apw, re: bug #681727, have you actually pushed patches to the list? | 20:07 |
| ubot2 | Launchpad bug 681727 in linux-meta (Ubuntu) "linux-backports-modules-wireless-maverick-generic not available for kernel 2.6.35-23 (affects: 2) (heat: 12)" [High,In progress] https://launchpad.net/bugs/681727 | 20:07 |
| apw | tgardner, in theory at least | 20:09 |
| tgardner | apw, hmm, I can't remember them | 20:09 |
| tgardner | nothing in patchworks either | 20:09 |
| apw | i can't see them in my outbox either ... let me check | 20:09 |
| apw | tgardner, i've pushed send again ... got t | 20:10 |
| apw | got them now ? | 20:10 |
| hallyn_ | does anyone here know offhand whether aufs tries to mark fields with a particular poison (i.e. maybe 66010101)? | 20:10 |
| apw | hallyn_, is that not 'list poison' ? | 20:10 |
| apw | tgardner, too many interruptions it seems | 20:11 |
| tgardner | apw, yeah, they are trickling in now | 20:12 |
| tgardner | at least [0/2] so dar | 20:12 |
| tgardner | far* | 20:12 |
| apw | tgardner, dunno if i did it wrong or just didn't get to the actual pressing return ... perhaps it was when i clicked an lost my screen the first time | 20:12 |
| tgardner | apw, np, I was just noticing some noise on the wireless mailing list about this bug | 20:13 |
| apw | hallyn_, not list poison then ... /me lets grep search for him | 20:13 |
| apw | tgardner, thanks for the kick up the ass | 20:13 |
| * apw needs to be more methodical | 20:13 | |
| tgardner | apw, I think your second patch is wrong, you're futzing with alsa: | 20:18 |
| tgardner | -Depends: ${misc:Depends}, linux-backports-modules-alsa-${kernel-abi-version}-generic-pae | 20:18 |
| tgardner | +Depends: ${misc:Depends}, linux-backports-modules-compat-wireless-2.6.36-RELEASE_NAME-generic-pae (= ${binary:Version}) | 20:18 |
| apw | tgardner, crap | 20:18 |
| * apw goes fix it | 20:18 | |
| apw | that happened cause i had to redo it following finger trouble | 20:18 |
| JFo | ogasawara, got a sec? | 20:19 |
| JFo | if not that is cool | 20:19 |
| jdstrand | apw: fyi, followed on bug #507148 | 20:19 |
| ubot2 | Launchpad bug 507148 in xserver-xorg-video-ati (Ubuntu Lucid) (and 4 other projects) "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500 (affects: 8) (heat: 46)" [High,Invalid] https://launchpad.net/bugs/507148 | 20:19 |
| jdstrand | err | 20:19 |
| jdstrand | I followed up on that bug | 20:19 |
| ogasawara | JFo: sure, just gimme 5min to finish up a rebase | 20:19 |
| JFo | k | 20:19 |
| hallyn_ | apw: that's the thing, i've grepped for it with no luck, which seems weird :) but ok, thanks, will keep looking | 20:20 |
| apw | tgardner, V2 in the pipe ... | 20:23 |
| tgardner | apw, ack | 20:24 |
| robbiew | apw: regarding https://bugs.launchpad.net/ubuntu/+source/linux/+bug/669496, is it blocking the use of the i386 ISOs or just all the i386 ec2 instances | 20:31 |
| ubot2 | Launchpad bug 669496 in linux (Ubuntu Natty) (and 1 other project) "natty fails ec2 boot on i386 or t1.micro (affects: 1) (heat: 12)" [Critical,Confirmed] | 20:31 |
| robbiew | from the title and the bug comments, I was assuming just ec2 | 20:32 |
| apw | i believe the latter, jjohansen ^^ | 20:32 |
| jjohansen | later just i386 instances on ec2, not uec | 20:33 |
| robbiew | jjohansen: thnx | 20:33 |
| robbiew | skaet_: ^^^^^ ;) | 20:33 |
| skaet_ | robbiew, jjohansen, ack. :) | 20:34 |
| * robbiew returns Server threat level to Defcon 1 | 20:35 | |
| * maco tries to remember whether defcon levels go up or down | 20:35 | |
| ohsix | can anyone explain the physical sector size discrepancy here: http://paste.ubuntu.com/538409/ ? | 20:36 |
| ogasawara | JFo: sorry, taking longer than I expected and have to run to my dr apt. can I ping ya when I get back in an hour or so? | 20:39 |
| JFo | ogasawara, after thinking a bit more, I'll likely send you an e-mail for you to look at when it is convenient :) | 20:42 |
| JFo | is that cool? | 20:43 |
| ogasawara | JFo: cool, works for me | 20:43 |
| JFo | good deal | 20:43 |
| * ogasawara back in a bit | 20:44 | |
| === _LibertyZero_ is now known as LibertyZero | ||
| bdmurray | apw: bug 511747 looks fixed to me is that right? | 21:10 |
| ubot2 | Launchpad bug 511747 in xf86-input-evtouch (Ubuntu Lucid) (and 3 other projects) "support for Acer 1420P (affects: 6) (heat: 40)" [Medium,Triaged] https://launchpad.net/bugs/511747 | 21:10 |
| jasonlife | I'm trying to upload my patched kernel to my ppa, and it seems uploading kernel to ppa is different than normal packages.. After I changed changelog and ran debuild -S -sa, I noticed .dsc and .diff.gz doesn't have the suffix I used during changelog update.. Anyone has an idea about uploading custom kernel to ppa? | 21:14 |
| tgardner | skaet_, bug #676245 won't make it into A1 unless we re-upload the kernel. | 21:26 |
| ubot2 | Launchpad bug 676245 in linux (Ubuntu Natty) (and 1 other project) "Broadcom NetXtreme II BCM5709 -- no network found on ISO install (affects: 1) (heat: 6)" [High,Fix committed] https://launchpad.net/bugs/676245 | 21:26 |
| apw | bdmurray, yeah from the testing responces there it is fixed for linux (Ubuntu) | 21:28 |
| apw | bdmurray, do feel free to make it Fix Released | 21:28 |
| bdmurray | apw: and the evtouch parts? | 21:29 |
| apw | bdmurray, that would have to be referred to cnd | 21:29 |
| skaet_ | tgardner, anything else in the kernel along with it? | 21:29 |
| skaet_ | s/it/bug 676245 fix/ | 21:30 |
| tgardner | skaet_, well, the rebase to -rc4 | 21:30 |
| ubot2 | Launchpad bug 676245 in linux (Ubuntu Natty) (and 1 other project) "Broadcom NetXtreme II BCM5709 -- no network found on ISO install (affects: 1) (heat: 6)" [High,Fix committed] https://launchpad.net/bugs/676245 | 21:30 |
| * apw looks at skaet_ | 21:30 | |
| * skaet_ is thinking of what can go wrong vs. getting it fixed... | 21:31 | |
| tgardner | skaet_, I've smoke tested -rc4 on a server, but thats about it | 21:31 |
| * apw hasn't even boot tested it yet | 21:31 | |
| cnd | bdmurray, the Ubuntu utouch stack will not use xf86-input-evtouch | 21:32 |
| cnd | I've never looked at it really | 21:32 |
| cnd | so I don't have any more information for you | 21:32 |
| tgardner | skaet_, the difference between whats in the archive and the next upload is _only_ a couple hundred patches. | 21:33 |
| * apw wonders why bnx2 is so important | 21:34 | |
| tgardner | dell servers | 21:34 |
| cnd | bdmurray, on a cursory glance, I think the bug should be marked as invalid for evtouch | 21:34 |
| cnd | it's really an issue that has been fixed in the kernel | 21:34 |
| apw | tgardner, and why indeed do the damn names of the files change every week; this must be the 3rd time this particular issue has appered | 21:34 |
| skaet_ | tgartner, _only_, huh. | 21:35 |
| tgardner | apw, firmware file names seem to be fungib;e | 21:35 |
| apw | tgardner, are those ? in our module udeb thingy? | 21:35 |
| tgardner | apw, nope, they are firmware file names need in the nic-modules d-i file. | 21:36 |
| apw | tgardner, supprised the build doesn't fail when they change name in that case | 21:36 |
| tgardner | apw, the names were'nt there in the first place. I had to add them so tha the bnx2 driver could load its firmware | 21:37 |
| tgardner | from a udeb | 21:37 |
| tgardner | skaet_, glp v2.6.37-rc3..v2.6.37-rc4|wc -l | 21:37 |
| tgardner | 393 | 21:37 |
| apw | tgardner, hrm, didn't we have that issue in lucid too though, so am supprised they arn't there already | 21:37 |
| skaet_ | tgardner, thnx. | 21:37 |
| apw | but ... never mind, an issue for anohter time | 21:37 |
| tgardner | apw, I dropped them in the early natty rebase 'cause upstream had build errors wherein they didn't convert the firmware files correctly | 21:38 |
| apw | tgardner, ahhh then it makes sense, /me forgets about it | 21:38 |
| skaet_ | tgardner, any way the fix can just be applied to the kernel that's already uploaded? | 21:38 |
| tgardner | apw, I should have filed a bug so I didn't forget about it (as I clearly did) | 21:38 |
| tgardner | skaet_, for you we'll do anything :) | 21:39 |
| apw | tgardner, as everything is on master-next (right?) we could just slam master to the tag and cherry that one perhaps | 21:39 |
| tgardner | apw, my thinking exactly | 21:39 |
| apw | tgardner, you or me ? | 21:39 |
| tgardner | apw, you're EOD, right? | 21:39 |
| apw | tgardner, t'is pretty late yep | 21:40 |
| tgardner | apw, I can take care of it. should only take a bit. | 21:40 |
| apw | tgardner, ok ... i suspect its not an abi bumper so it should be low impact, but drop me a note if there are any time delay things to do | 21:41 |
| skaet_ | thanks tgardner, apw! :) | 21:41 |
| apw | skaet_, don't expect it for 7 hours or so! | 21:41 |
| tgardner | apw, skaet_: I'll get it uploaded in the next hour or so. | 21:41 |
| apw | (as it takes that long to build) | 21:41 |
| skaet_ | :) | 21:42 |
| * skaet_ looking forward to seeing when it shows up now... | 21:42 | |
| skaet_ | please post in ubuntu-release when its ready ;) | 21:42 |
| tgardner | skaet_, how about I post when its uploaded? I'll be in bed when its 'ready' | 21:43 |
| skaet_ | heh. fair nuf. just want a record there so cjwatson knows what's going on, when I'm in bed. ;) | 21:44 |
| apw | skaet_, i assume we are in freeze still, so it'll block on accept ? | 21:46 |
| tgardner | apw, soft freeze still | 21:47 |
| skaet_ | apw soft freeze for alphas | 21:47 |
| apw | ahh ok | 21:47 |
| skaet_ | it should get picked up by the autobuilder for tomorrows images if all goes well. | 21:48 |
| * tgardner is outta here | 23:13 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!