=== jmknsd is now known as jakemp-home === kentb is now known as kentb-out === smb` is now known as smb [07:38] * apw waves to smb [07:40] * smb waves back to apw [08:11] apw: 302983e9059e9ef5de3ca7671918eeb237c5971e in drm-intel-fixes says ‘Hi, I fix that diagonal crazyness bug’ [08:12] RAOF, got the bug number for that one by any chance ? [08:14] apw: bug #753994 [08:14] Launchpad bug 753994 in linux "[arrandale] Display is slanted when using 1360x768 resolution" [Medium,Confirmed] https://launchpad.net/bugs/753994 [08:14] ta [08:22] RAOF, has drm-intel moved again? i don't see that in ickles tree [08:22] Yeah. Keith's now managing drm-intel, and has been for some months. [08:23] damn [08:23] It occurs to me that the drm-intel-next autobuilds might be a little bit stale… :) [08:24] RAOF, ok wahts the official right URL so i can fix these up :) [08:25] url = git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git [08:27] RAOF, ok i've switched the mainline builds to that tree too [08:34] smb, is .38 stable dead already? [08:34] apw, yup [08:34] RAOF, are commit ids stable in drm-intel-fixes ? i am suspecting not [08:35] apw: I am uncertain. [09:13] ppisati, can i assume you are not doing any CVEs ? we have no bugs right now as kees has not made them [09:13] so we have no way to interlock till he sorts that === Quintasan_ is now known as Quintasan [09:59] apw: yep. doing other stuff [10:00] ppisati: hey, man. your 3.0 omap4 kernel rocks [10:03] cooloney: save these words for when it will panic :) [10:05] * apw wonders if sound works [10:06] apw and ppisati, i only player server image like headless without testing sound [10:07] nope, sound is broken [10:07] at the kernel level [10:08] and pulseaudio is so stupid that, in case a dsp device doesn't react correctly to an open+ioctl [10:08] it keeps retrying like an idiot [10:08] sucking 100%cpu [10:08] so in entirely disabled snd* [10:09] apw, Would you consider installing linux-tools from a different release for debugging a valid use case? There is bug #783660 and the change of linking libfd statically may be acceptable... If we think that should be supported [10:09] Launchpad bug 783660 in linux "linux-tools: perf should link statically to libbfd" [Low,Triaged] https://launchpad.net/bugs/783660 [10:09] smb, a different release, so for that you'd need to be using a different kerenl from a different release [10:09] and we don't really support that either [10:11] I guess the usage is mainly to debug issues with newer/or against newer kernels, yeah. It is certainly not normal use [12:03] * ppisati -> out for lunch === hcfd__ is now known as hcfd [12:23] smb, reading the bug in full it seems that this represents a policy violation so i'll probabally do something about it [12:24] At least something that should not be done with debian yeah [12:24] Trying to check the suggested approch atm [12:24] well ubuntu policy is very much unchanged from debian in the general case [12:25] Yeah, agreed. Downside for us is that this will be something we will then carry as a deviation [12:26] apw, I came in on the 2nd half. what y'all talking about? [12:27] tgardner, bug #783660 [12:27] Launchpad bug 783660 in linux "linux-tools: perf should link statically to libbfd" [Low,Triaged] https://launchpad.net/bugs/783660 [12:27] we are linking perf against a dynamic library, which 1) doesn't work in all installs and 2) is (liely) a policy violation [12:27] apw, has it done this from the start ? [12:27] yep [12:28] apw, Was the violation actually any dynamic lib ? [12:28] smb, no it seemed to be libbfd specifically [12:29] apw, seems like a straightforward fix. do wee need to add a build dependency? [12:29] or is libfd already there somewhere [12:30] we are already dep on htat [12:30] tgardner, smb i think is testing the patch at th mo [12:30] apw, tgardner At first it looks straight forward enough [12:31] apw, smbremember tangerine is liekly to disappear today [12:31] Just strangely I do seem to not get what I think I should get from that print-file-name [12:32] tgardner, Thanks. Not yet doing something there but reminding me not to try even [12:34] apw, For some reason it looks to me as -print-file-name=x just outputs whatever x is. /me wonders whether it would not then be simpler to just replace -lbfd with libbfd.a [12:34] kees, what tz are you on today i wonder [12:34] smb, doesn't it have to be a full path name [12:34] if its not -l [12:35] apw@dm$ gcc -print-file-name=libc.a [12:35] /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/../../../libc.a [12:35] Could be and that is what man gcc suggests... [12:35] smb, that looks like it does the right kind of thing [12:35] wtf... [12:36] apw@dm$ gcc -print-file-name=libtic.a [12:36] /usr/lib/libtic.a [12:36] Great it prings the full path name if it exists and whatever you type if not... [12:36] apw: I'm in central and up early [12:38] apw, Ok, guess its then failing later and if it works then you got the full pathname... [12:38] kees, wondering how we are getting on with making bugs for those cves, i'd like to wack some of them but they have no bugs [12:39] apw: I'm about 30 minutes from having it automated, but I can shove them in manually now if you want? [12:39] (oneiric-i386)apw@dm$ gcc -print-file-name=libbfd.a [12:39] /usr/lib/libbfd.a [12:39] smb, ^^ i [12:39] smb, ^^ in a chroot [12:39] gcc -print-file-name=thisistupid [12:39] thisistupid [12:40] kees, no as long as they are soon [12:40] okay, cool [12:40] smb, right when its not found it returns just the name [12:40] apw, That confused me a bit... but as said it likely fails at some point in that case [12:42] smb, right it should just error cause the file is missing, but the tool should only use it when it is available anyhow iirc [12:42] apw, So it looks ok, then I will try test build and forward it to the list [12:42] smb, thanks [12:47] hello everyone..whn upgrading my ram from 1g to 2g, the system (ubuntu 11.04) becomes unusably slow. windows not affected, other distros not affected, booting from live cd not affected..can someone help? [12:49] <_ruben> sounds like a coincidence to me [12:50] it is reproducible [12:53] I suspect a relation to video mode setting because grub is also affected, only works at normal speed when used in text mode [12:54] where is the extra ram placed by the bios? that info is in the e820 dump in dmesg [12:55] also could you give us a hint as to what unusably slow means? particularly in grub which isn't doing anything much [12:57] sure, slow grub means that switching the cursor from one menu entry to another takes a second, editing an entry takes 10 seconds to load the edit screen [12:57] I have put together all dmesg and lshw memory output here: [12:57] https://bugs.launchpad.net/ubuntu/+bug/816035 [12:57] Ubuntu bug 816035 in ubuntu "Memory upgrade makes Ubuntu painfully slow" [Undecided,New] [13:02] I'd love to believe that this is just a flawed BIOS, but other OS seem to have no problem with that. And I really don't want to drop ubuntu :( [13:04] linuxR, what linux distros did work and which boot loader did they use [13:04] apw, I installed fedora15 [13:05] and which boot loader does that use [13:05] gotta check that [13:06] linuxR, ok i'd say the problem is almost cirtainly the bios setup of the MTRRs [13:07] with 1GB of ram you have: [13:07] [ 0.000000] 0 base 000000000 mask FC0000000 write-back [13:07] and with 2GB you have: [13:07] [ 0.000000] 0 base 000000000 mask F80000000 write-back [13:08] oh hmm maybe that is right ... argle they hard to decode [13:11] seems not fundamentally wrong to me [13:15] interestingly the timings are very very similar if not faster on the 2g machine well into kernel init [13:18] is there anything more I can provide to narrow down the problem? [13:21] linuxR, you could try booting with enable_mtrr_cleanup mtrr_cleanup_debug [13:21] linuxR, i am suspicious there are overlapping mtrrs with the same type and a lot of the things you cannot do that with in mtrrs [13:22] the processor just gets it wrong [13:22] [ 0.000000] 1 base 07E800000 mask FFF000000 uncachable [13:22] [ 0.000000] 2 base 07F800000 mask FFF800000 uncachable [13:22] particularly 2 there, is that not overlapping with the first half of 1 [13:23] linuxR, the other thing being what bootloader does F15 use as that is not affected and grub2 is [13:25] linuxR, and you said that a liveCD was not affected even with 2g of ram. that uses syslinux, so doesn't help bootloader side, but a dmesg there may also be eligntening [13:27] oh... [13:27] I booted with "enable_mtrr_cleanup" and it booted FAST [13:28] ok ... so it is very likely those overlapping mtrrs which are causeing the issue [13:28] ok could you add that info and the dmesg for 2g with that option to the bug [13:29] what does mtrr_cleanup" do? is the problem solved by this? [13:29] i suspect that the bootloader may be fixing those in the F15 case, so finding out what that uses is also useful [13:29] I'll just attach the new dmesg [13:31] linuxR, it is designed to make more space in your mtrrs (there are only a handful) for bad bioses, it does this by combining those that it can and removing the unnecessary ones [13:31] this will likley remove the overlapping one i am worried about [13:31] which is why i wanted you to test with it [13:32] apw: wasn't the cve tracker LP tag changed from kernel-cve-tracking-bug to kernel-cve-tracking ? [13:32] it doesn't appear so [13:33] okay [13:33] kees, thuough i'd based that on whatever the script puts on [13:33] yeah, looks like it's still -bug from all the scripts [13:33] actually... [13:33] elif 'kernel-cve-tracker' in lp_bug.tags: state = 'cve-tracker' [13:33] elif 'kernel-cve-tracking-bug' in lp_bug.tags: state = 'cve-tracker' [13:34] both show up in the sru-report, but create-cve-tracker uses kernel-cve-tracking-bug [13:34] is there a preference? [13:34] maybe they are meant to be switching, hrm ... i'd have to refer you to bjf/sconklin [13:34] i am assuming we use whatever the script does [13:34] okay [13:35] linuxR, is that dmesg coming ? [13:36] in a sec [13:37] its there [13:41] linuxR, ok its wrapped the dmesg with the debug, could you reboot with just enable_mtrr_cleanup and paste a dmesg of that [13:41] and perhaps the output of cat /proc/mtrr, could you paste that in privmsg so i can look at it while you do that :) [13:44] oh sure, wait :) [13:46] added /proc/mtrr to the bug [13:50] apw, new dmesg uploaded [13:54] linuxR, thanks, so yeah that shows the new layout is without any overlaps but covering the same range i think [13:54] so the problem can be considered as solved now I guess [13:56] i thought that grub2 could clean up the mtrrs but i don't know if thats something that got slipped, or has to be enabled by default [13:57] i beleive the underlying issue is the bios producing invalid mtrr settings and that freaks the cpu out which is likely effectivly disabling the cache on the cpu for all of ram [14:00] is this "mtrr cleanup" something persistent that grub could do and would still be correct when the kernel is started? [14:01] the kernle uses whatever mtrrs are set up before it starts normally, unless you ask it to cleanup [14:03] so grub would have to do this on its own [14:06] i don't believe any mtrr support has been added to grub2 as yet, as the bios is expected to do the right thing [14:06] it is required to do the right thing [14:07] now i wonder why the CD isn't affected [14:11] apw, is there a reason we don't enable mtrr cleanup by default? [14:11] sforshee, its not something the kernle does by default i assume [14:12] apw, it looks like can be enabled by setting CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1 [14:12] interesting, maybe that is the difference [14:13] where is jj and his magic comparison table when i need it [14:13] apw, would that be in jj's spreadsheet ? [14:15] tgardner, yeah did he email that out ? [14:15] tgardner, my quick googles say it is on by default in fc12 at least [14:16] apw, perhaps we ought to have a look at it [14:16] tgardner, yep am doing so now [14:21] apw: if it helps, people.canonical.com/~jj/amd64-default.ods [14:22] ogasawara, thx [14:23] ok so on in FC and off in SLES [14:25] tgardner, what do you think about enabling same in oneiric as an experiment [14:25] apw, seems like a good idea. I assume its not experimental ? [14:29] sforshee, hi! someone released a patch to fix the problem with weaver output: https://bugs.freedesktop.org/show_bug.cgi?id=38750#c9 [14:29] Freedesktop bug 38750 in DRM/Intel "[Arrandale] Intel Core i3 External Monitor Wavy Output" [Normal,New] [14:29] sforshee, is there any date to that patch will be applied in lucid? [14:31] mfilipe, I've been monitoring the comments. It's looking good for those affected by the problem, but I'm unsure whether or not it could cause regressions for others. [14:31] mfilipe, it would be nice to have some comment from the upstream developers. Maybe I'll poke at them and see if we can get some feedback. [14:33] tgardner, no not experimental [14:33] i'll enable it for oneiric then i think and see what happens [14:33] sforshee, please. thanks a lot [14:33] apw, ack [14:34] * ogasawara back in 20 [14:35] bjf, hey! [14:36] * tgardner pushes a natty build fix 'cause he didn't do his homework first. [14:36] sconklin, herton, ^ bug 811745 [14:36] Launchpad bug 811745 in linux "Whole system freeze after safely remove external usb drive" [Undecided,Confirmed] https://launchpad.net/bugs/811745 [14:36] bjf, I am still not 100% positive, but it seems like there's a regression in 2.6.32-33 (bug #811745) [14:36] * sconklin looks [14:36] bjf, I have not reproduced it myself, but I work with someone who confirmed it [14:37] bjf, it is not in the bug, but I am vaguely suspecting it might be NTFS-specific [14:37] gosh EtienneG, could you be a little more vague ? [14:37] sconklin, bjf: I have asked the person who can reproduce the bug to check if non-NTFS removable storage also trigger the bug. Waiting to hear back from him. [14:38] tgardner, sorry! :) [14:38] EtienneG, it's the usual story, let's reproduce and then we can bisect and test [14:38] EtienneG, have you been able to repro the problem? [14:38] if its ntfs sticks which blow then it should be easy to check [14:38] bjf, sure. I will let you know if/when we have it confirmed. Just wanted to give you a heads up. [14:39] EtienneG, have you tried formating a usb memory stick to NTFS [14:39] EtienneG, sure, thanks [14:39] bjf, apw: I have not reproduced the problem myself, it's a second hand account. That's what I am working on now. [14:43] looking at the kernel changelog, the same scsi change that brought regressions into natty is applied on lucid after 2.6.32-32 [14:43] so probably it's it causing issues (bug 811745) [14:43] Launchpad bug 811745 in linux "Whole system freeze after safely remove external usb drive" [Undecided,Confirmed] https://launchpad.net/bugs/811745 [14:44] herton, sconklin was muttering dark thoughts about that patch last week [14:48] tgardner: that patch that was bisected on natty and reverted ("put stricter guards on queue dead checks") is applied on lucid also, can likely be issue here [14:48] herton, I'd say its a likely candidate [14:49] there was a long thread of possibly related noise on lkml, i believe this is were it started: https://lkml.org/lkml/2011/7/1/335 [14:50] I'll build a lucid kernel with the reverts and ask for testing on that bug report (may take some time if tangerine is offline) [14:50] herton, use tyler [14:51] thanks apw for solving the mtrr memory issue! I need to have a drink now :) [14:52] tgardner: is it tyler.buildd? [14:55] apw: so, it looks like there are only 6 open CVE tracking bugs. can you confirm that? [14:56] kees, before your new ones? [14:56] apw: right. currently in LP. [14:56] apw: actually, that seems low. where is ogasawara's CVE bug report? [14:57] kees: http://people.canonical.com/~kernel/reports/kernel-cves.html [14:57] hmmm. that's more than 6 :) [14:57] ogasawara: can I see the code you're using to generate that list? [14:57] ogasawara: I want to make sure I'm doing the same thing... which it seems i'm not [14:57] kees, you arn't making the mistake of searching for open ones are you ? [14:58] kees: sure, do you have a copy of our kteam-tools repo? [14:58] yup [14:58] apw: maybe? [14:58] kees, you have to sarch for all of them and ignore the closed ones [14:59] when you search for 'open' against linux you are searching for open in devel only [14:59] you either have to search for all bugs and ignore the closed ones [14:59] or you have to search in ubuntu/oeniric/linux ubuntu/lucid/linux etc and merge the results [15:00] kees: look at kteam-tools/cvescripts/kernel-cves.py [15:00] kees, you should find i put a could of the bug numbers in the cve files when i made them at the end of last week [15:00] kees, so you should have some lknkage already [15:00] kees: basically I'm starting by looking at all bugs tagged kernel-cve-tracking-bug [15:01] ogasawara, are you searching in 'ubuntu' [15:01] apw: yep [15:01] and including closed ones [15:01] ubuntu = lp.distributions['ubuntu'] [15:01] cves = ubuntu.searchTasks(tags=['kernel-cve-tracking-bug']) [15:01] apw: and then I just basically loop all bug tasks for each bug [15:01] and that doesn't make LP nearly collapse oh no :) [15:02] ogasawara: ah, yes. ubuntu.searchTasks. I was doing ubuntu.getSourcePackage(name='linux').searchTasks [15:02] adjusting... [15:03] I'm actually using this: ubuntu.searchTasks( [15:03] tags=['kernel-cve-tracker','kernel-cve-tracking-bug'], [15:03] tags_combinator='Any', [15:03] omit_duplicates=True): [15:03] we'll see if it comes out the same [15:03] okay, much better. found 20 [15:03] kees, i thought we were just putting hte bugs numbers in the cve tracker [15:04] apw: I am. but I need to find the bugs to avoid creating duplicates. [15:04] apw: and when I find the LP bug, I add it to the tracker [15:05] ## [15:05] ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [15:05] ## agenda: https://wiki.ubuntu.com/KernelTeam/Meeting [15:05] ## [15:11] sforshee, http://pastebin.com/AjeiNxm5 [15:11] :( [15:12] I'm thinking buy a displayport monitor but they are expensive in Brazil :( [15:13] mfilipe, yeah, I was just reviewing the patch prior to pinging Chris but was coming to the conclusion that it would probably have the same problems as the one Chris originally supplied [15:13] mfilipe, have you tried passing lvds_use_scc=0 on the command-line? I'm not sure whether or not it would help, but might be worth trying. [15:15] nop [15:15] I will try [15:16] but I don't know where the best place to add these argument [15:16] where? [15:16] mfilipe, if the fundamental problem is with disabling ssc when plugging in the external panel, it might help since it should keep ssc off [15:16] mfilipe, you need to modify /etc/default/grub [15:16] mfilipe, add that parameter in GRUB_CMDLINE_LINUX [15:17] mfilipe, then run 'sudo update-grub' [15:17] mfilipe, that makes it permanent... [15:17] aff [15:17] but if you want to try it first you can modify the command line from grub as well [15:17] my driver version hasn't that option: http://pastebin.com/bDm0jisK [15:18] I'm using 2.6.35 yet [15:18] backport of maverick [15:18] I see that you released the backport of Natty [15:19] so, I will use it [15:19] do you know if it has that option in module? [15:19] mfilipe, sounds good [15:19] mfilipe, let me check... [15:20] mfilipe, yes, natty's driver has that parameter [15:25] mfilipe, actually you probably need to use i915.lvds_use_ssc=0 [15:29] I will reboot [15:30] apw: so, I have a sync question ... 2010-3448 is tracked in 706999. it doesn't show up in ogasawara's report -- it's missing lts maverick in the tracker still. [15:30] what should be done here? [15:30] any idea why its not in her report ? [15:31] looks like all the bug tasks are closed. (i.e. it's missing the lts-maverick task) [15:31] because all the bug tasks states are in a closed state (eg Fix Released or Invalid) [15:31] I skip all close bug states [15:31] kees, probabally the backport didn't get added back then [15:31] i would add it now and it should close anyhow [15:31] yeah [15:32] or else appear on leanns list, which is good [15:32] it's already pending, but I wonder if the sync tool should add the missing task [15:32] i suspect its not necessary as you'll make them right in the first place no ? [15:32] we could just fix the broken ones by hand [15:32] i cna help do that [15:33] * kees wonders about adding new LTS backports ... [15:33] kees: I notice that bug is also only tagged kernel-cve-tracker, should I be looking at that tag too? [15:33] ogasawara: yes. see stable/sru-report -- it seems to look for both tags [15:33] ogasawara, i think it is probabally ppisati who made it :) [15:33] ogasawara: no idea why there isn't just one [15:33] kees: ack, will add that to my script [15:33] kees, confusion i suspect, and there should be, and we should get sconklin to chose one and fix it [15:36] apw: I'm not aware that we have ever picked a standard tag for CVEs, nor do we (stable team) have any scirpts which deal with them as far as I know (But I could be wrong). [15:36] sconklin: there are multiple scripts that use the two tags :) [15:36] sconklin: including the bug-creation script [15:37] ok, well, I'll investigate when I finish today's meeting prep [15:37] sconklin, apw, when i wrote the original script i started putting "kernel-cve-tracker" on all of them, what happens now, I don't know [15:38] it seems to have become perverted into kernel-cve-tracking-bug, possibly to mirror the stable trackers [15:38] bjf, ^^ [15:39] LP API is soooo slow [15:39] apw, i see, i could have done that, don't remember [15:40] kees, it is wonderful, sexy, and all powerful and dont you forget it [15:40] (else it may come round and hide your toys in the night) [15:40] heh [15:50] sforshee, ldvs_use_ssc=0 without solution :( [15:50] mfilipe, too bad [15:50] it was worth a shot [15:51] ldvs_use_scc* [15:51] mfilipe, wait... [15:51] did you see my message about using i915.lvds_use_ssc instead? [15:51] we need something like enable that code when we use ldvs_use_scc=0 [15:51] " mfilipe, actually you probably need to use i915.lvds_use_ssc=0" [15:52] your last message [15:52] mfilipe, run 'sudo cat /sys/module/i915/parameters/lvds_use_ssc' and see what the value is [15:53] lol [15:53] I will boot again with the argument [15:53] one minute [15:53] mfilipe, catting the value will tell you whether or not you need to test again [15:53] tgardner, I might have missed you wall message.. is tangerine coming back up soon ? [15:54] sforshee, but I rebooted without the arg [15:54] I added it in grub [15:54] boot grub* [15:54] mfilipe, okay, that won't work then :) [15:54] manjo, tangerine is gone for a couple of days. I've been sending out regular notices that tangerine will be down for disk maintenance. [15:54] one minute [15:55] tgardner, ok looks like I did not read those... np [15:57] tgardner, just an idea ... probably you could put that in motd next time ... my bad anyway for not reading the notice by email [15:57] sudo cat /sys/module/i915/parameters/lvds_use_ssc => 0 [15:58] manjo, like yuo'd read the motd anyways... [15:58] with weave output [15:58] sforshee, thanks for your time, it was a good shoot :) [15:58] mfilipe, np, sorry it didn't work [15:59] sforshee, you don't need apologize us but Intel yes :P [16:00] a basic function without a solution 1+ year ago :( [16:01] ## [16:01] ## Kernel team meeting in one hour [16:01] ## [16:02] they don't gave nothing answer... they can answer something like "we don't know the solution but we have a employee working fulltime in this problem" [16:02] but nothing [16:02] 1+ year with nothing [16:03] sorry for my english [16:03] hehe [16:15] kees, bjf, apw: I'm starting to look at unifying the CVE tagging throughout our tools [16:15] sconklin: cool [16:15] apw, I assigned you to bug #816035 since you'r already working it [16:15] Launchpad bug 816035 in linux "Memory upgrade makes Ubuntu painfully slow" [Undecided,In progress] https://launchpad.net/bugs/816035 [16:18] * herton -> lunch [16:18] ubuntu.searchTasks(search_text='CVE-2010-3448', omit_duplicates=True, status=["New","Confirmed","Triaged","In Progress","Fix Committed","Fix Released"]) returns nothing :(:( [16:18] kees: drivers/platform/x86/thinkpad_acpi.c in the Linux kernel before 2.6.34 on ThinkPad devices, when the X.Org X server is used, does not properly restrict access to the video output control state, which allows local users to cause a denial of service (system hang) via a (1) read or (2) write operation. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3448) [16:18] hmm, the bot has sharp eyes [16:26] ogasawara: any clue on that? I can't find any closed tasks... [16:26] * ogasawara scrolls back [16:27] ogasawara: just before the bot spew [16:27] kees: what's the actual bug # it should return [16:27] 706999 [16:28] kees: I think the search_text= capabilities are crap. I recall apw saying it was utterly stupid. [16:30] ogasawara: as in, it doesn't search titles? [16:30] kees: even when I go to https://bugs.launchpad.net/ubuntu/+bugs and put "CVE-2010-3448" in the text box to search, it returns nothing [16:30] ogasawara: drivers/platform/x86/thinkpad_acpi.c in the Linux kernel before 2.6.34 on ThinkPad devices, when the X.Org X server is used, does not properly restrict access to the video output control state, which allows local users to cause a denial of service (system hang) via a (1) read or (2) write operation. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3448) [16:30] ogasawara: greeaaat [16:30] this is a total show-stopper for sane tracker/LP sync :( [16:31] * smb thinks to remember apw saying, he got told hypens are not lps best friend [16:31] and I can't search for all statuses with tags=['kernel-cve-tracker','kernel-cve-tracking-bug'],tags_combinator='Any' because the search times out [16:31] pft, lovely [16:32] this is stupid [16:32] okay, so new requirement: if the bug isn't linked in the tracker, it doesn't count. :P [16:32] of interest to all of us who develop scripts using the LP API: [16:32] http://blog.launchpad.net/coming-features/no-more-monthly-90-minute-downtime [16:33] "If you have API scripts running against Launchpad, you may want to build in a retry mechanism to deal with up to a few minutes of downtime." [16:34] kees: when the bugs get created, would it help to tag them CVE-####-#### so you could look them up by tag, rather than having to search the title? [16:34] ogasawara: well, since I can't search by title, I guess that's the only option [16:35] ogasawara: actually, no [16:35] ogasawara: that won't help because it needs to be in an open state to find them [16:35] ogasawara: I can't find closed bugs is the problem [16:35] so, in the case of 2010-3448, the sync tool (if it didn't have a manual entry) would just build another bug [16:37] kees: but you could tell the search to include the closed states as well right? [16:38] kees: status=["New","Confirmed","Triaged","In Progress","Fix Committed","Fix Released", "Won't Fix", "Invalid"] tags=['CVE-2010-3448'] [16:38] ogasawara: drivers/platform/x86/thinkpad_acpi.c in the Linux kernel before 2.6.34 on ThinkPad devices, when the X.Org X server is used, does not properly restrict access to the video output control state, which allows local users to cause a denial of service (system hang) via a (1) read or (2) write operation. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3448) [16:38] or does that time out as well [16:39] ogasawara: it times out [16:39] what a POS [16:39] kees, then you should be talking to them in #launchpad [16:39] ogasawara: I was trying to just look up all the tagged bugs, but it can't do "all", just "open" [16:39] kees, that's really not acceptable [16:39] tgardner, thanks, pushed [16:40] kees, you can't search based on titles [16:40] if they have '-'s in them [16:40] bjf: hundreds of things about LP are not acceptable. usually they ignore "special" requests. https://wiki.canonical.com/Security/Malone has multi-year old platform-blocking bugs listed [16:40] apw: is there a bug open for that? [16:40] kees, so we don't talk to them about it? [16:41] kees, timeouts are one of if not the highest priority for LP [16:41] kees, i think so, someone pointed me to it, i think it was <100k though so no much chance of it ever being actually fixed [16:42] i gave up when they showed me 4 bugs in what i was trying to do, ie stopping me [16:42] thats when i started just looking them all up and eliminating them by hand and sod the performance consquences [16:42] bjf: we do, and i will, but it won't be fixed for literally years, so it's not high on my list to do [16:43] kees, for example i iterate over all the cve tasks in bugs/proc-cve-bugs [16:43] kees, it wouldn't time out if you were using GO [16:43] which applys the equivalent of DNE to all the tasks [16:43] bjf: hahah [16:43]