| hallyn | feh. btrfs just went readonly for no good reason | 01:00 |
|---|---|---|
| RAOF | It's trying to save you :) | 01:01 |
| hallyn | no doubt | 01:03 |
| hallyn | i guess that rsync from a debootstrapped image into a subvolume was just a bit too fast | 01:03 |
| RAOF | Hm. Now that we run fsck.btrfs, booting takes a *loooong* time. In an hour or so that system might be ready! | 01:17 |
| Jerub | g'day. this bug is marked as closed/fix-released: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/630748 | 04:19 |
| Jerub | but i can replicate it on the same hardware as the original bug reporter's hardware with the very latest natty debs | 04:19 |
| Jerub | it looks like from the notes made by 'Tim Gardner' that he was told by an intel engineer that it should be fixed, but no report of anyone saying that any changes effected a change. | 04:28 |
| jjohansen | Jerub: hrmm update the but with your information | 04:51 |
| Jerub | i did. i'm the last two comments on the ticket. but it's still marked as 'fix-released', instead of 'confirmed' | 04:52 |
| Jerub | i guess what i've said isn't very clear, i could spam the ticket more if you want. | 04:54 |
| jjohansen | Jerub: it would be good, to be explicit has to which kernel (version # not latest), and what exactly you are seeing. | 05:16 |
| jjohansen | Maybe even doing an apport-collect 630748 | 05:17 |
| jjohansen | to add your information | 05:17 |
| Jerub | okay, doing that now | 05:18 |
| Jerub | i can't do apport-collect because the bug is closed. | 05:19 |
| Jerub | i've added specific version numbers and my uname -a to the ticket, and noted that i cannot run apport-collect due to the bug being marked as closed. | 05:22 |
| === _LibertyZero is now known as LibertyZero | ||
| === smb` is now known as smb | ||
| magcius | I have two support questions: one about FS not working, one about network not working. If there's a better place, please tell me :D | 09:26 |
| magcius | 1. Sometimes the FS causes a complete failure where "sync" refuses to work. | 09:27 |
| magcius | If I run "sync", and then do a cat /proc/$(pidof sync)/stack | 09:27 |
| magcius | I get "call_rwsem_down_read_failed" at the top of the stack. There is a fixed kernel bug about this, but it's still happening. | 09:28 |
| magcius | I have a somewhat borked external, and it's happened across two different hardware computers, so I'm not sure what's happening. | 09:28 |
| magcius | 2. e1000e fails to work if I don't do proper shutdown when I reboot | 09:28 |
| apw | magcius, what filesystem format is the drive wh | 09:29 |
| apw | with the issue | 09:29 |
| apw | and with which kernel for that matter | 09:30 |
| smb | The main problem with those kind of question is the lack of information. What fs, what drive, what release... | 09:30 |
| magcius | NTFS | 09:30 |
| magcius | I believe | 09:30 |
| magcius | I have no idea, the stack trace doesn't give me much info. | 09:30 |
| magcius | I have about 4 or 5 filesystems on this thing | 09:30 |
| magcius | I'm running Ubuntu 11.04 right now, but I've had this problem for a while. | 09:31 |
| apw | can you get a picture of the problem? | 09:31 |
| magcius | "picture"? | 09:31 |
| magcius | And I'm trying to dig up the exact error message from e1000e, but not having much success since my dmesg log has been scraped | 09:31 |
| smb | I guess it is an external usb drive, but thats only guessing | 09:31 |
| magcius | It was something like "probe failed with error code 5" | 09:31 |
| magcius | smb, indeed. | 09:31 |
| magcius | The NTFS drive, at least. | 09:31 |
| magcius | I have no idea *if* it's that filesystem that's failing. | 09:31 |
| smb | The stack only says that sync wanted a semaphore which is already taken | 09:32 |
| magcius | Right. | 09:32 |
| smb | This can be a communication problem with the external usb case | 09:32 |
| magcius | OK. | 09:32 |
| smb | So something tries to write and does not complete | 09:32 |
| magcius | Right. | 09:32 |
| smb | then the next access just locks up waiting | 09:33 |
| ohsix | i've had fuse do some funny things like that :D | 09:33 |
| magcius | could be fuse or ecryptfs | 09:33 |
| smb | givien that it is ntfs there is likely fuse involved here too | 09:33 |
| smb | Probably one thing to look for is usb reset messages in dmesg | 09:34 |
| magcius | When it happens the next time, is there anything I can or should do to check for the filesystem? | 09:34 |
| magcius | what should I grep for? | 09:34 |
| smb | Not sure about the exact message but something about reset of usb device bla | 09:35 |
| smb | then there could be the automatic softlockup message. maybe it triggers for the other process too. Though with writes going into the background those usually doent show | 09:36 |
| magcius | just check /var/log/dmesg the next time it happens? | 09:37 |
| smb | magcius, Its dmesg (as a command) | 09:37 |
| magcius | Is there a difference? :P | 09:38 |
| smb | That does not depend on the filesystem working. /var/log is the written output. dmesg directly reads the buffer | 09:39 |
| magcius | aha | 09:39 |
| apw | smb, any feel for where in his cycle gregkh is? for stable-38? | 09:50 |
| smb | apw, The was a larger dump between yesterday and today. He might be preparing to fire the next review/release | 09:51 |
| apw | good | 09:52 |
| fairuz | Hi, if I want to build packages, can I cross compile? | 10:33 |
| apw | most packages in debian/ubuntu are not really cross compile capable | 10:36 |
| apw | the kernel is partially cross-compilable | 10:36 |
| fairuz | apw: So the manual way is to cross compile the kernel, cross compile modules, and do modules_install on target machine? | 10:37 |
| apw | no, i was trying to say that some of the build doesn't work, iirc the tools package doesn't build well in a cross compile environment | 10:38 |
| apw | we use cross-compilation for build verification and architecture boot strappng so we haven't cared to fix these remaining issues | 10:38 |
| magcius | debian multiarch? | 10:50 |
| apw | ? | 10:50 |
| magcius | isn't that the cross-compilation work? | 10:50 |
| apw | nope, multiarch is cross arch installation | 10:51 |
| magcius | huh, I thought they were at least planning to do cross-compilation | 10:51 |
| apw | multiarch is all about installation, as far as i know, it would be a handy tool as a basis for cross compilation but i don't beleive that is its function | 10:54 |
| === yofel_ is now known as yofel | ||
| === diwic is now known as diwic_afk | ||
| bullgard4 | Is the Natty kernel thread aio generated thorough the source code file /usr/src/linux-source-2.6.38/fs/aio.c? | 12:24 |
| bullgard4 | -o | 12:24 |
| ohsix | bullgard4: look for something that creates the kthread, like create_singlethread_workqueue | 12:26 |
| bullgard4 | '~$ locate create_singlethread_workqueue' does not produce any output. | 12:28 |
| tayyabali1 | how to learn kernel compilation any resources ? | 14:30 |
| apw | https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel | 14:30 |
| JFo | tayyabali1, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel | 14:30 |
| apw | jinx | 14:30 |
| JFo | :P | 14:31 |
| apw | JFo, not on mumble ? | 14:34 |
| JFo | not yet, charging my headset | 14:35 |
| JFo | realized a bit ago that it was dead | 14:35 |
| JFo | should be ready soon, it has been on a while | 14:35 |
| hallyn | apw: fwiw on the kvm soft interrupt bug just got a more affirmative reply from avi, so he might be sending a patch soon. | 14:39 |
| hallyn | (bug 747090 that is) | 14:40 |
| apw | hallyn, ok keep me in the loop, on the patch, sounds like its a nasty one ... any idea what the trigger for 'sometimes' is | 14:40 |
| JFo | where in the heck is ubotu? | 14:41 |
| hallyn | apw: i think the trigger is just when you notice :) | 14:41 |
| apw | needs inviting in again i suspect | 14:41 |
| hallyn | apw: it must always happen on softint | 14:41 |
| apw | ahh that kind of sometimes | 14:41 |
| hallyn | right. for the most part 'who cares' if you do the interrupt twice :) | 14:41 |
| apw | i thought you could just invite ubottu, but it seems not | 14:43 |
| JFo | hmmm | 14:43 |
| smb | I sort of had hoped that this one was "employed" by #is and would not leave with somebody leaving | 14:44 |
| JFo | it looks to still be in other channels | 14:44 |
| * JFo goes to investigate | 14:44 | |
| smb | hallyn, Hm, is that the two backport patches or something different? I was wondering about the other things just today | 14:45 |
| hallyn | smb: ? | 14:51 |
| hallyn | smb: you mean the kvm bug? | 14:51 |
| apw | hallyn, is that conversation on the original thread or elsewhere> | 14:51 |
| hallyn | apw: in the kvm mailing list | 14:51 |
| smb | hallyn, I think I was messing things up in my memory. Yes, some kvm bug with clock going backwards, I just sent a nag mail round | 14:52 |
| hallyn | smb: <shrug> i don't know enough about softints to know if it could cause that. but it sure should cause some funky stuff | 14:52 |
| apw | hallyn, whats the subject on the contination ... the archives of the kvm list only show your original and one replay | 14:53 |
| apw | reply | 14:53 |
| hallyn | smb: so every 'INT 0xYY' will be called twice | 14:53 |
| apw | hallyn, now how is it that its twice and not thrice? | 14:53 |
| apw | or 10000 times | 14:53 |
| hallyn | apw: Subject: Re: buggy emulate_int_real | 14:53 |
| smb | hallyn, Oh its surely not the only kvm bug. Just got reminded of the other one | 14:53 |
| hallyn | apw: because I assume after the first time, regular instruction stepping happens. | 14:53 |
| hallyn | apw: i did wonder that myself, and am not sure | 14:53 |
| hallyn | all right, since there's no patch from him yet, i'll start one now | 14:54 |
| apw | ahh its there on gmane not other archives, odd | 14:54 |
| apw | yeah it seems its something like if it page faults taking the int, it then runs the int again | 14:55 |
| * ogasawara back in 20 | 15:29 | |
| apw | JFo, looking at the key bugs list we have a large number in New and Undecided status, arn't those supposed to get fixed by the scripts | 15:29 |
| * apw grins at ogasawara | 15:29 | |
| JFo | apw, what do you mean? | 15:30 |
| JFo | oh the arsenal scripts | 15:30 |
| apw | yeah | 15:30 |
| apw | at least the New bit? | 15:30 |
| JFo | I stopped running the 'new' one because it is improperly tagging some bugs as found by myself and bjf | 15:30 |
| apw | and i thought we were concentrating on ensureing there was no Unspecified priorities on that list | 15:30 |
| JFo | he has a new one that he is testing | 15:31 |
| JFo | that does the basics and gets them to confirmed | 15:31 |
| apw | ok cool. the priorities we should be fixing | 15:31 |
| === herton is now known as herton_lunch | ||
| JFo | yes, indeed | 15:31 |
| apw | else how can we tell which to care about | 15:31 |
| JFo | I just haven't gotten to those yet. | 15:31 |
| JFo | they are next on my list | 15:32 |
| apw | JFo, chat time ? | 15:32 |
| JFo | sure, whenever you like | 15:32 |
| moustafa | Hi, sorry to pop in, but I was wondering if it would be possible to backport the intel i915 video modules to Lucid? I'm sure a number of users would enjoy the improvements to the driver code on their LTS machines | 15:50 |
| apw | moustafa, we do offer lts backports kernels on lucid, offering the maverick, and soon the natty kernel for lucid | 15:51 |
| apw | though they are only officailly supported for servers, they are complete | 15:51 |
| moustafa | apw: So, enabling the backports should technically allow a user to update to a more recent version of the kernel as well as the available open source drivers? | 15:52 |
| apw | moustafa, they are separate from the -backports, they are elective installs via a separate meta package | 15:53 |
| apw | linux-image-generic-lts-backport-maverick ... -natty (once natty releases) | 15:54 |
| moustafa | apw: Since I haven't tried this myself, is there any place I can read more about doing that? | 15:55 |
| apw | now that is a good question, i am unaware of any speciic documentation other than the announcement | 15:55 |
| apw | JFo, can you remember if there is any specific docs on the LTS backports kernels? | 15:55 |
| JFo | not that I am aware of apw | 16:00 |
| JFo | and I can't find anything in the brief search I did | 16:00 |
| moustafa | apw , JFo so how would it work exactly? just type in linux-image-generic-lts-backport-(name of release)? Or am I missing something? | 16:01 |
| moustafa | I remember reading an annoucement, but didn't get the details of how far along it was | 16:01 |
| JFo | I recall the announcement, but I thought we documented the method | 16:01 |
| JFo | I'm just not finding it | 16:01 |
| apw | moustafa, apt-get install linux-image-<flavour>-lts-backports-<release> | 16:03 |
| JFo | found the blueprint, but still no docs | 16:03 |
| apw | where flavour is the one your machine normally uses, and release is the release for the kernel | 16:03 |
| moustafa | apw JFo : Perfect, thanks | 16:04 |
| JFo | apw, was this always the description for this blueprint? https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-new-kernel-on-lts | 16:05 |
| JFo | oh wait | 16:06 |
| JFo | no, that is a feedback request or something | 16:06 |
| apw | the description is right yes, just hidden | 16:06 |
| JFo | yeah, I just realized :) | 16:07 |
| JFo | sorry about that | 16:07 |
| bjf | ## | 16:07 |
| bjf | ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting | 16:07 |
| bjf | ## agenda: https://wiki.ubuntu.com/KernelTeam/Meeting | 16:07 |
| bjf | ## | 16:07 |
| === Sarvatt is now known as Sarvatt|2 | ||
| === Sarvatt_ is now known as Sarvatt | ||
| apw | bjf, yo ... i hear you have a new New bug frootle script for the arsenal ? | 16:08 |
| bjf | apw, for generating regression reports | 16:09 |
| apw | bjf not for handling the triage phase ? | 16:09 |
| bjf | apw, oh, right now it is just looking at bugs that have the required logs and bumping them from "New" to "Confirmed" | 16:10 |
| bjf | apw, it's not running via cron yet, but will be soon | 16:10 |
| apw | bjf, ahh ok, so that is the one i mean | 16:10 |
| apw | if they don't have the required logs will it ask? | 16:11 |
| bjf | apw, right now no, i'm taking it one step at a time, but that would be the next step | 16:11 |
| apw | bjf, ok cool, as long as its coming, as our bugs are getting in a mess :) | 16:14 |
| bjf | apw, tell me about it | 16:15 |
| apw | bjf, i would say, if it has the required logs, then it hsould be going Triaged shouldn't it ? | 16:15 |
| apw | confirmed means more than one person has seen it, triaged means it has the needed data | 16:15 |
| bjf | apw, according to "our rules" we need to ask for "upstream testing" first, | 16:16 |
| apw | oh i see ... hmm | 16:16 |
| bjf | apw, you need to look at our bug triage status wiki page | 16:16 |
| apw | (i try not too :)) | 16:16 |
| bjf | apw, not sure i agree with what is says, just following it for now | 16:16 |
| bjf | apw, this is the page i'm referring to : https://wiki.ubuntu.com/Kernel/BugTriage/BugStates | 16:17 |
| apw | bjf, something odd is happening with apport ... which you might need to be watching out for ... like bug #758400 | 16:17 |
| apw | has needs-upstream-testing as a tag on it, but ... its never been requested in the bug | 16:18 |
| apw | and i think apport may have done it | 16:18 |
| apw | (and it may be an error in fact for it to have done so) | 16:18 |
| bjf | apw, http://people.canonical.com/~kernel/reports/24.html | 16:19 |
| smb | apw, FYI Review for 2.6.38.3 was more or less just sent out, ending on Thursday | 16:19 |
| apw | smb, cool. that'd be good timing | 16:20 |
| bjf | apw, yes, those are apport, been doing it all along, you just haven't noticed | 16:20 |
| bjf | apw, we talked sunday about gutting our part of apport | 16:21 |
| apw | bjf, i think the now broken scripts also used that tag too, but either way i think that we should be reinforcing it via a direct comment in the bug | 16:21 |
| apw | as it would only have been in a dialog box and without any hint as to how to actually do it | 16:21 |
| bjf | apw, i'm pretty sure the scripts, when they add it, add a comment, apport does not | 16:22 |
| apw | right ... and i think it is really a mistake to have it in both places ... my opinion of course | 16:22 |
| bjf | apw, right, it needs to come out of apport and we need to be smarter about it in the scripts | 16:23 |
| apw | bjf, so where are you accumulating the new smaller leaner scripts ? | 16:24 |
| bjf | apw, me thinks we need someone on the team to "own" our part of apport | 16:24 |
| * apw looks at you significantly | 16:25 | |
| bjf | apw, wanted to talk to you about that, we said something about a structure under kteam-tools but I couldn't remember what we agreed on | 16:25 |
| apw | bjf, i think we were at that vague level yes | 16:25 |
| bjf | apw, i have it in a local kteam-tools under "bugs" directory | 16:25 |
| apw | bjf, i have one here which shortly will handle the 'New' and 'Incomplete (with response)' onces and puts them back into the right state | 16:25 |
| apw | bjf, that or arsenal seem logical to me | 16:26 |
| bjf | apw, have you looked at http://people.canonical.com/~kernel/reports/ ? | 16:27 |
| apw | nope, they are all new since i was off i think | 16:28 |
| bjf | yes | 16:28 |
| bjf | they are running automatically via "cron" from the "kernel" user on people | 16:28 |
| apw | do i have access there? and are we going to run the arsenal there too ? | 16:29 |
| bjf | apw, you do have access (everyone on the team should) | 16:30 |
| apw | cool | 16:30 |
| bjf | apw, we can run there or on cranberry, the reports run there because they are public and people can talk to LP via the api | 16:31 |
| bjf | apw, my pref would be to do it all in one place | 16:31 |
| apw | seems an appropriate place to run everything then (to me) | 16:31 |
| apw | snap | 16:31 |
| * apw notes that this green against grey/black is not good to look at, its hard for me to see the text and the background on the same plane, the letters float oddly | 16:32 | |
| apw | why are all our pages not the normal -verse | 16:32 |
| bjf | apw, you are the first to complain, others have like it and it works for the author | 16:33 |
| * apw will have to persuade you to generate both -verses so i can view the other one :) | 16:34 | |
| * JFo reads back | 16:48 | |
| * smb wonders whether we got our meeting warning already | 17:00 | |
| smb | Otherwise it might be over before we realize it started | 17:01 |
| JFo | looks like bjf got dropped | 17:01 |
| smb | Usual conference quality | 17:02 |
| JFo | :) | 17:03 |
| jjohansen | heh well the sever team looks to be using our meeting time any ways :) | 17:08 |
| smb | jjohansen, ? Isn't ours not due in an hour? | 17:09 |
| jjohansen | smb: oh cripes so it is, /me is so confused by daylight savings time still | 17:09 |
| smb | jjohansen, Wow I thought we now all changed for two weeks now. :-P I was somewhat surprised there had been a relative smooth transition | 17:10 |
| jjohansen | smb: well that doesn't mean /me is used to it. /me still expects meets at 9am local and now they are at 10am. By the time I get used to it, it will switch back | 17:11 |
| === herton_lunch is now known as herton | ||
| apw | jjohansen, it does change only twice a year | 17:12 |
| jjohansen | apw: yeah I know, only 6 months to adjust :) | 17:13 |
| apw | bjf, how does one tell that a bug has had upstream testing ? | 17:15 |
| apw | (programatically) | 17:16 |
| bjf | apw, that's a really good question | 17:16 |
| apw | i suspect we cannot tell at the moment, as we ask them to remove needs-upstream-testing | 17:16 |
| bjf | apw, i don't have a good answer and am wondering if we can really blanket spam bugs | 17:16 |
| apw | hmmm, as i am already looking at the activity log to work out the 'previous state' i might be able to work out if it was on there and removed | 17:17 |
| apw | and use that as indicator | 17:17 |
| bjf | apw, but if they don't remove the tag but have done the testing what do you do ? | 17:17 |
| apw | bjf, how are you detecting 'has apport data' | 17:17 |
| apw | bjf well in that case the automation should assume they have done it, and it'll end up in a state saying we should look | 17:18 |
| bjf | apw, i'm looking to see if the original bug submitter has attached, specific logs | 17:18 |
| apw | and if we find it missing we ask again and re-add the tag | 17:18 |
| bjf | apw, bot comes along, changes status to "Incomplete", adds "needs-upstream-testing" tag and adds comment asking for upstream testing | 17:20 |
| bjf | apw, user does upstream attachment, adds comment, may not change from "Incomplete" to "Triaged/Confirmed" and may not remove "needs-upstream-testing" tag | 17:21 |
| bjf | apw, s/upstream attachment/upstream testing/ | 17:21 |
| bjf | apw, is the bot going to look at all "Incomplete" status bugs to see if testing was done? how does it know ? | 17:22 |
| bjf | apw, if the status has been changed but the tag still exists, how do you know if the testing was done ? | 17:22 |
| apw | well look at this way round ... | 17:23 |
| apw | i am looking at things which were imcomplete and want to change, ie incomplete (with response) | 17:23 |
| apw | i would think it should occur as part of that processing | 17:23 |
| apw | as from there it should go to 'new' (with no data), 'confimed (with apport data), or triaged with apport and with testing done | 17:24 |
| apw | so the trigger to care is incomplete (with response) or 'new' | 17:24 |
| apw | as those are the only places it can go to if they say something | 17:24 |
| apw | bjf mumble ? | 17:25 |
| bjf | at ELC | 17:25 |
| apw | oh yeah, no chance | 17:25 |
| apw | as you say we cannot rely on moving or not moving to New | 17:25 |
| apw | but we can handle that i think | 17:25 |
| bjf | i think your approach is the right one, i'm just wondering how a bot is going to look at the last comment and decide that the testing was done | 17:26 |
| apw | and i thiknk if they test but don't remove the tag (which we explicitly ask them to do) then we lose them, and they get expired | 17:26 |
| apw | i think we only look at the absence of the tag | 17:26 |
| apw | ie, was it added and then removed | 17:26 |
| apw | ie. was it on there, and is not now | 17:27 |
| apw | that says they removed it | 17:27 |
| apw | if the history says it was tagged, and bug.tag('needs....') == false | 17:27 |
| bjf | i was thinking the same, but concerned that relying on users to remove tags is problematic | 17:27 |
| apw | it is not clear how we can do it using text | 17:28 |
| apw | as there is no common way to say it | 17:28 |
| apw | the text the script inserts says how to remove the tag etc, JFo can confirm i think | 17:28 |
| bjf | bottom line, do it the way you are thinking (which i agree with) but we need to keep an eye on it to see if it's "working" | 17:28 |
| apw | click the pencil, remove the text 'needs....' | 17:29 |
| apw | yep, so i think if they have either apport data, or have removed the tag (ie done upstream testing) but not both we go to Confirmed, if both then to Triaged | 17:29 |
| apw | and keep an eye on things lingering in Confiirme | 17:29 |
| bjf | agreed | 17:30 |
| apw | do you have a function to determine if we have apport data I can steal ? | 17:30 |
| * apw notes we need a library of useful snippets to share shortly | 17:31 | |
| bjf | yes | 17:31 |
| bjf | will push soon | 17:31 |
| bjf | working on pushing, right now | 17:31 |
| apw | bjf, i suspect that this processing i am doing right now is so allied with the 'ask for data' and 'ask for upstream testing' we are going to end up merging them | 17:32 |
| apw | but ... anyhow :) | 17:32 |
| apw | we can likely work out how long we have been waiting for needs-xxx to be removed, and add comments to hastle people | 17:33 |
| * JFo curses xchat | 17:37 | |
| bullgard4 | What does "MRU" stand for in /usr/scr/linux-source-2.6.38/fs/xfs/xfs_mru_cache.c? | 17:38 |
| bjf | apw, pushed, look at bugs/proc-new-regressions and ktl/bugs.py | 17:39 |
| apw | bullgard4, (guesses at) most-recently-used ? | 17:39 |
| bullgard4 | apw: hm | 17:40 |
| JFo | I think for the test to see if they actually did test upstream, it may come to a point where we have a script compile for me a list of bugs to look at. I am not above that. | 17:40 |
| JFo | in fact, it will make what I need to be doing a ton easier | 17:40 |
| apw | * inserted at the head of the current most-recently-used list. | 17:40 |
| JFo | still thinking about the 'keeping an eye on confirmed | 17:41 |
| apw | bullgard4, looks like that is what it is | 17:41 |
| JFo | ' | 17:41 |
| JFo | I have an opinion, but it isn't making a lot of sense right now. :) | 17:41 |
| sforshee | has anyone noticed this thread about bluetooth borkage: https://lkml.org/lkml/2011/3/19/80 | 17:42 |
| sforshee | someone sent a backport to the stable list today, maybe we want to get it into natty | 17:42 |
| sforshee | unfortunately I have nothing to test with | 17:43 |
| apw | sforshee, is that the version of bluetooth we use? there are two and i can never remember which is which | 17:43 |
| apw | manjo normally knows | 17:43 |
| bullgard4 | apw: It seems your guess is correct: http://en.wikipedia.org/wiki/Cache_algorithms | 17:43 |
| sforshee | apw, had no idea there were two versions, and also no idea which one we use | 17:44 |
| apw | sforshee, seems we do use bluez | 17:46 |
| sforshee | apw, that's the conclusion I was coming to as well | 17:46 |
| sforshee | I see one bug that might be related | 17:46 |
| sforshee | https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/700292 | 17:46 |
| apw | sforshee, thanks, adding a linux task in case | 17:48 |
| bjf | ## | 17:55 |
| bjf | ## Kernel team meeting in 5 minutes | 17:55 |
| bjf | ## | 17:55 |
| * JFo stretches | 17:55 | |
| ppisati | o/ | 17:56 |
| * apw thinks ppisati missed | 17:59 | |
| smb | apw, me too | 18:00 |
| ppisati | uat? | 18:01 |
| ppisati | ops, wrong channel :) | 18:01 |
| === sforshee is now known as sforshee-lunch | ||
| JFo | <- lunch | 18:07 |
| * apw goes find some dinner ... | 18:48 | |
| === sforshee-lunch is now known as sforshee | ||
| GrueMaster | JFo: What more data would you like on bug 758961? The oops text is there and the kernel devs that actually have these platforms can easily reproduce this. | 19:47 |
| JFo | well, the norm is to gather all of the apport-collect data, that way there is (usually) no need to ask for anything further. | 19:49 |
| * jjohansen -> lunch | 20:03 | |
| skaet | JFo, ogasawara - could you have a look at https://launchpad.net/bugs/759115? | 20:43 |
| skaet | its hitting in Ubuntu Alternate and Edubuntu images. | 20:44 |
| ogasawara | skaet: hrm, and I assume this wasn't the case for Beta 1 | 20:45 |
| JFo | ugh, LP taking forever for me :) | 20:46 |
| skaet | ogasawara, discussion going on in u-release, looks like security update early this month. | 20:46 |
| lifeless | JFo: doing what ? | 20:48 |
| JFo | lifeless, it is a connection issue for me, not LP's fault | 20:48 |
| JFo | :) | 20:48 |
| lifeless | JFo: well, that could because of our ISP or whatever choosing poor routes | 20:49 |
| JFo | I'm pulling an ISO at the same time, so my connection is slow | 20:49 |
| ogasawara | skaet: Author: Kees Cook <kees@ubuntu.com> | 20:51 |
| ogasawara | Date: Wed Mar 23 13:17:13 2011 -0700 | 20:51 |
| ogasawara | UBUNTU: [Config] packaging: adjust perms on vmlinuz as well | 20:51 |
| ogasawara | 20:51 | |
| ogasawara | Since kernel symbols are resolvable internally to the kernel, the kernel | 20:51 |
| ogasawara | itself has a map of the symbols. Continuing the tradition of frustrating | 20:51 |
| ogasawara | off-the-shelf kernel exploits, make vmlinuz unreadable for non-root, just | 20:51 |
| ogasawara | like has been done for System.map, etc. | 20:51 |
| ogasawara | 20:51 | |
| ogasawara | Signed-off-by: Kees Cook <kees.cook@canonical.com> | 20:51 |
| ogasawara | Signed-off-by: Tim Gardner <tim.gardner@canonical.com> | 20:51 |
| kees | I thought alternate was already fixed? | 20:52 |
| kees | stgraber is working on edubuntu, iiuc | 20:52 |
| skaet | ogasawara, yup. LTSP impacted in alternate and edubuntu. | 20:52 |
| kees | skaet: stgraber is working on it (was just talking to him about it in #ubuntu-hardened) | 20:53 |
| skaet | kees, yup, he started the discussion off in ubuntu-release, and the question of "why" came up. | 20:53 |
| kees | skaet: for "frustrating off-the-shelf kernel exploits" | 20:54 |
| stgraber | kees, skaet: The easiest, most maintenable and fastest way for me to fix it is to release a new LTSP upstream. I can have one released with a fix in 5 minutes or so. Other upstream diff is bugfix only and minimal. | 20:54 |
| skaet | kees: lol, indeed. | 20:54 |
| kees | skaet: less tersely, it is to stop non-root users from being able to trivially resolve kernel symbols when performing local kernel exploit attacks. | 20:55 |
| kees | skaet: it doesn't stop a dedicated attacker, but it does stop script-kiddies, which has real-world benefits. | 20:55 |
| skaet | stgraber, ok, let pitti know its coming and why. | 20:56 |
| * skaet crosses fingers bug fixes only means bug fixes and no regressions. | 20:56 | |
| skaet | thanks kees | 20:57 |
| kees | skaet: np, sorry for the trouble! | 20:58 |
| ogra_ | lets just tell the script kiddies to grow up :) | 21:01 |
| JFo | I wish | 21:05 |
| gondoi | I seem to be missing my quota modules in -virtual | 22:04 |
| gondoi | is this expected? | 22:04 |
| gondoi | btw, I'm running maverick | 22:05 |
| === emma_ is now known as em | ||
| === BenC__ is now known as BenC | ||
| === sconklin is now known as sconklin-gone | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!