| apw | soren, if its not that then git cat-file -p $SHA:path/to/file | 00:12 |
|---|---|---|
| === smb` is now known as smb | ||
| ricotz | apw, hello :), do you know if there is a package of Ubuntu-lts-2.6.35-25.44 for lucid already available? | 09:10 |
| apw | ricotz, it does not appear so yet, it seems that kernel is lagging, with a previous version not yet promoted to -updates | 09:13 |
| smb | The archive seems ok, but I guess nobody uploaded | 09:13 |
| smb | I mean git | 09:13 |
| apw | smb, yep, i know the previous one only just got promoted yesterday, and a newone uploaded, but it seems to be behind still | 09:15 |
| ricotz | ok, thanks, so it will be available soon | 09:16 |
| apw | i suspect the stable team has not gotten it in their process, and tim is still doing them when he has time | 09:16 |
| smb | apw, lilely. as the repo is up to date. I guess we should/could just upload the latest version | 09:17 |
| ricotz | smb, this would be nice | 09:18 |
| ohsix | where can i get a hand with the information i've gathered trying to troubleshoot suspend problems | 09:18 |
| ohsix | is there like a go-to guy or is it jus down to filing a bug | 09:18 |
| apw | smb, yeah in general i think we can do that, but i suspect its better to get the stable peeps to do it, to make sure they are remembering | 09:18 |
| apw | ohsix, its always worth getting all of it attached to a bug, file one with ubuntu-bug linux as that gets the machine info | 09:19 |
| smb | apw, Yeah, probably | 09:19 |
| smb | ricotz, That would be a few more hours | 09:20 |
| apw | smb, i wonder if the mainline builder should be at least shoving the latest tags into the kernel-ppa ppa | 09:21 |
| apw | as i keep forgetting to do natty as well | 09:21 |
| smb | For Natty surely. Maverick, maybe. Though probably it just should be on the list of steps when uploading a Maverick to proposed | 09:23 |
| smb | apw, Are you still doing the mainlines on zinc? | 09:24 |
| apw | smb, yep ... | 09:24 |
| smb | poor machine. :) | 09:24 |
| apw | smb, i am thinking both, that it should be something on the checklist for maverick, but also whether we could get the things uploaded | 09:24 |
| apw | well it doesn't have to do so much for a PPA upload, just make the source deb and upload it | 09:24 |
| ricotz | smb, alright | 09:24 |
| apw | smb, i suspect if that mav kernel contains security then it should be expedited into lucid anyhow | 09:25 |
| smb | apw, It might be something slightly less often. Ie only if there is a new closing tag | 09:25 |
| apw | right | 09:25 |
| smb | I guess as the process seems mostly automatic anyway, maybe the upload could go directly to the proposed staging ppa instead of kernel-ppa | 09:27 |
| smb | Then there is one thing less to think about in the normal case for the stable team | 09:27 |
| apw | smb, perhaps so, it is tricky to know if the automated build will work | 09:27 |
| apw | but as yet it has not failed for me | 09:27 |
| smb | apw, We should brig that up. Maybe there is a wiki page about that already, of which nobody has heard. :-P | 09:28 |
| apw | heheh probabally | 09:29 |
| ohsix | hrm i have the symptoms on this bug running the natty kernel https://bugs.launchpad.net/ubuntu/+source/linux/+bug/592780 going to try some of the stuff they said worked | 09:39 |
| ubot2 | Launchpad bug 592780 in linux "[Lucid] kernel suspend + resume works only once, 2nd timesystem freezes" [Undecided,Fix released] | 09:39 |
| ohsix | it's probably my card reader; is there anything more finegrained than usbcore.autosuspend? like; do the separate drivers have knobs for it | 09:42 |
| apw | ohsix, what system is affected | 09:43 |
| ohsix | you mean model number? compaq cq60 | 09:44 |
| apw | ohsix, from the bug it seems worth checking out that usbcore.autosuspend thing | 09:57 |
| ohsix | yea | 09:58 |
| ohsix | i'm having a problem with the mav kernel too; it'll suspend but not wake up, it starts with some hd activity but doesn't get anywhere | 10:01 |
| ohsix | yea, no dice on the usb thing | 10:12 |
| ohsix | i gathered this earlier with netconsole http://paste.ubuntu.com/558898/ | 10:15 |
| ohsix | it's the successful suspend followed by the failure; and it consistently says its stopping the disk the second try | 10:15 |
| ohsix | hrm, the pm_trace thing on the failed sleep always turns up in drivers/base/power/main.c:605 | 10:53 |
| apw | ohsix, that disk line being different is plain odd | 10:54 |
| apw | ohsix, you definatly have a different cause to your issue than them then, i would recommend a new bug | 10:54 |
| apw | and add that pastebin to it | 10:54 |
| apw | ohsix, which kernel? lucid ? | 10:55 |
| ohsix | the natty kernel, 2.6.37-12 or something | 10:55 |
| apw | ohsix, well that line is a resume line | 10:58 |
| apw | ohsix, what is the whole of the magic line in the next boot ? | 10:58 |
| ohsix | ya i looked at it already; too bad it doesn't say which device it's resuming | 10:59 |
| apw | ohsix, can you paste the MAGIC line you got that from ? | 11:00 |
| ohsix | do you mean the magic number? there are no further or more specific matches, the numbers are 0:900:740 | 11:00 |
| ohsix | hm, i assued the tracepoints were automatic, reading s2ram.txt says i might have to add some | 11:04 |
| ohsix | 3rd number in the magic is supposed to be the device? dunno how to look it up if it could'nt look it up already | 11:08 |
| ohsix | out of time for this today, i'll be back later | 11:10 |
| ohsix | if you find any information i should digest when i pick it back up, msg me, bye :] | 11:12 |
| rocky2 | Hey can anyone help me with kernel debugging... using kgdb? | 11:22 |
| * apw doesn't recall every using kgdb | 11:29 | |
| apw | but ask your question, someone might know | 11:29 |
| apw | ohsix, get that bug filed, i suspect some more debugging needs enabling in suspend/resume as it appears that the machine started resuming which implies a failed suspend | 11:30 |
| apw | rocky2, but ask your question, someone might know | 11:31 |
| rocky2 | Question is... the test kernel not waiting with kgdbwait parameter in grub. What could be the problem... | 11:31 |
| === cking is now known as cking-afk | ||
| stefanlsd | apw: just to let you know i'll test your kernels for bug #552311 - needed it for a while for kvm passthru | 12:50 |
| ubot2 | Launchpad bug 552311 in linux "CONFIG_DMAR is not set " [Medium,Incomplete] https://launchpad.net/bugs/552311 | 12:51 |
| apw_ | sl | 12:54 |
| apw_ | stefanlsd i had about given up on getting testing for that one ... missed tgis upload either way | 12:56 |
| === yofel_ is now known as yofel | ||
| stefanlsd | apw_: yeah, sorry. was subscribed to the other bug about it. will still do | 12:58 |
| apw_ | remin me of the big number would you | 12:59 |
| stefanlsd | apw_: bug #639712 | 12:59 |
| ubot2 | Launchpad bug 639712 in qemu-kvm "PCI Pass Through via libvirt cannot remap IRQ's" [Medium,Triaged] https://launchpad.net/bugs/639712 | 12:59 |
| === rsalveti is now known as rsalveti_ | ||
| === rsalveti` is now known as rsalveti | ||
| noodles775 | Hi! I want to trouble-shoot resume from suspend which broke recently on my maverick box... is http://ubuntuforums.org/showthread.php?t=1228332 the best place to start? | 13:30 |
| === cking-afk is now known as cking | ||
| tgardner | smb, tangerine:/home/rtg/kern/hardy/kern-64/ubuntu-hardy/debian/build/custom-source-xen | 13:52 |
| smb | tgardner, So I think my and your version are functionally the same. The only difference is that I tried to make it look the same as the mercurial latest code | 14:00 |
| tgardner | apw, https://kernel-tools.canonical.com/srus.html | 14:21 |
| apw | cking, https://edge.launchpad.net/~kernel-ppa/+archive/pre-proposed/+packages | 14:25 |
| apw | sconklin, hey | 14:49 |
| sconklin | apw: hi | 14:49 |
| apw | mumble ? | 14:49 |
| apw | sconklin, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/705845 | 14:54 |
| ubot2 | Launchpad bug 705845 in linux "Suspend on Thinkpad X200s worked in 2.6.35-24-generic but no longer in 2.6.35-25-generic" [High,New] | 14:54 |
| apw | http://reports.qa.ubuntu.com/reports/jfo/kernel-buglist-by-team.html | 15:00 |
| JFo | \o/ | 15:00 |
| JFo | :) | 15:00 |
| apw | JFo, i think we need to include all of the regression-potential bugs on the kernel-key list | 15:07 |
| apw | possibly regression-updates, but i suspect not yet as i suspect we are going to drown | 15:07 |
| JFo | regression-potential has been deprecated, do you mean regression[proposed? | 15:10 |
| JFo | err regression-proposed that is | 15:10 |
| apw | i do indeed proposed | 15:10 |
| JFo | ok | 15:10 |
| apw | mean proposed yes | 15:10 |
| JFo | I can definitely do that | 15:10 |
| * JFo makes some minor tweaks | 15:10 | |
| JFo | I expect I shall have that up today (in the next little bit) so we can see those and the kernel-key ones as well | 15:11 |
| apw | JFo, mumble ? | 15:14 |
| JFo | one sec... was listening to some music :) | 15:15 |
| === bjf[afk] is now known as bjf | ||
| apw | JFo, i think we need to get someone to run through all of the bugs on the key that are New and get them Triaged, and a priority assigned | 15:53 |
| JFo | yep, I am looking at that now | 15:53 |
| JFo | apw, want me to do that? | 15:54 |
| apw | if you have time, that'd be great | 15:54 |
| apw | these need special handling as we need to know wherre they worked previously and testing with the latest proposed/updates rather than necessarily upstream testing | 15:55 |
| apw | that the current arsenal would request | 15:55 |
| apw | we might want to special case t | 15:55 |
| apw | the ones with regression-xxx on them in what we ask for | 15:55 |
| apw | sconklin, bjf, the key kernel bug list now has all the regression-proposed bug enumerated on it | 15:56 |
| apw | JFo, i also wonder if we need to target them to the release they are reported on | 15:56 |
| JFo | I was thinking that too | 15:56 |
| JFo | I think it is a good idea | 15:56 |
| JFo | hmmm | 15:57 |
| JFo | looks like the only problem with that is that it doesn't show up in the overall list | 15:57 |
| apw | as in if the natty task is gone then they are gone ? | 15:57 |
| JFo | I see one that has a Natty task, but the buglist just shows it with everything else | 15:57 |
| JFo | no, what I mean is, we are only able, currently, to show what they are milestoned for | 15:58 |
| JFo | the script isn't giving us the release they are tasked for | 15:58 |
| apw | JFo, hrm | 15:59 |
| JFo | yeah | 15:59 |
| JFo | I hadn't really noticed that before | 15:59 |
| apw | JFo, yeah it is, thats the nomnation column, its separate from the milestone col ? | 15:59 |
| JFo | hmmm | 15:59 |
| JFo | yep, you are right | 16:00 |
| JFo | I guess it is just broken for natty | 16:00 |
| * JFo thinks that should be a relatively simple fix | 16:00 | |
| JFo | ok, I have added all that should be needed | 16:02 |
| JFo | let me do some testing to make sure I didn't break something | 16:02 |
| JFo | and I'll get this change committed and pushed | 16:02 |
| manjo | sforshee, git clone git://kernel.ubuntu.com/ubuntu/kteam-tools.git | 16:06 |
| manjo | sforshee, https://wiki.ubuntu.com/KernelTeam/SuspendResumeTesting | 16:06 |
| bjf | JFo, on this "key kernel buglist" page, i'd like to see a key which explains what the "comments" mean, for example, do I care about "cert team blocker"? "cert team pcert" ? | 16:07 |
| JFo | those are just an enumeration of what tag we pulled those from | 16:08 |
| JFo | I think we care, to varying degrees, about all of them :) | 16:08 |
| JFo | but I do see what you mean bjf | 16:08 |
| JFo | let me see what I can do | 16:08 |
| JFo | I should be able to add some sort of legend to the page | 16:09 |
| bjf | JFo, and "regression-proposed" is printed twice in the comments | 16:13 |
| JFo | yeah, I've fixed that already | 16:13 |
| JFo | thanks for pointing it out though | 16:13 |
| bjf | JFo, i'd suggest dropping the image link at the top left of the page since it's broken and just takes up space | 16:14 |
| JFo | huh, I hadn't noticed that. | 16:15 |
| JFo | thanks | 16:15 |
| JFo | huh, that is a launchpad librarian icon | 16:16 |
| bjf | JFo, i'll wager that with the new corporate style, there is a different logo link | 16:18 |
| JFo | I was just thinking that | 16:19 |
| JFo | wonder where it is... ah well, I'll get it later | 16:19 |
| bjf | JFo, don't think we really need it, just taking up useful space | 16:20 |
| JFo | yeah, was just prettification | 16:20 |
| maks_ | just saw the 2.6.32.28.13 | 16:24 |
| maks_ | there are some drm patches we fwd from 2.6.35, that you'd could also be interested | 16:25 |
| === Quintasan_ is now known as Quintasan | ||
| maks_ | in total they were eleven | 16:26 |
| tgardner | smb, ^^ | 16:26 |
| maks_ | smb: they are found in Debian 2.6.32-30. | 16:26 |
| maks_ | 2.6.35 longterm support forward ported them mostly fine. | 16:27 |
| maks_ | they are not all in bwh's git mirror, as it seem out of sync | 16:31 |
| maks_ | :/ | 16:31 |
| JFo | hiya skaet :) | 16:37 |
| JFo | let me know if you have any new bugs for me. | 16:37 |
| JFo | :-) | 16:37 |
| smb | maks_, Hi, if there are drm patches for the combined tree, feel free to send them to our kernel-team mailing list. Unfortunately stable is so busy by now that one easyily overlookes things | 16:38 |
| maks_ | smb: asked bwh to sync git mirror | 16:43 |
| cr3 | hi folks, what might this mean in the udevadm output for a serial input device: E: PRODUCT=11/2/8/7321 | 16:43 |
| smb | maks_, Yup saw it. | 16:43 |
| maks_ | afterwards I can send a combined mail with the sha1sum | 16:43 |
| maks_ | but really no time to fwd them each | 16:43 |
| smb | maks_, I sked him to ping me when I can look. :) | 16:43 |
| maks_ | ok cool. | 16:44 |
| smb | cr3, what udevadmn command? Did it fail? Otherwise it means that the environment variable PRODUCT has this value. :-P | 16:48 |
| cr3 | smb: udevadm info --export-db, nothing failed, just wondering what those numbers assigned to the PRODUCT environment variable mean: 11/2/8/7321 | 16:49 |
| smb | could be bus numbers as well as vendor product subvendor subproduct... Need to look at one example here | 16:51 |
| cr3 | smb: when comparing against lshal output, it seems that the "2" might mean hotplug_type, but nothing seems obvious about the other numbers | 16:52 |
| apw | smb, a bit short for vendor etc arn't they | 16:52 |
| cr3 | smb: if it were vendor product subvendor subproduct, I wonder against which table those values can be looked up. since this is a serial input device, I don't think it maps to pci.ids, usb.ids and probably not pnp either | 16:52 |
| smb | apw, Though it seems that they are | 16:52 |
| smb | just shortened | 16:53 |
| apw | shortened, as in 0011/0002 | 16:53 |
| smb | P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input5 | 16:53 |
| smb | E: PRODUCT=19/0/6/0 | 16:53 |
| smb | E: MODALIAS=input:b0019v0000p0006e0000-e0,1,kE0,E1,E3,F0,F1,F2,F3,F4,F5,ramlsfw | 16:53 |
| JFo | k, apw natty shows up in the nominations now | 16:55 |
| JFo | and there are currently 86 bugs :-/ | 16:55 |
| JFo | I'm going through the new ones now | 16:55 |
| smb | nSo we have <bus>/<vendor id>/<product id>/<version> | 16:57 |
| cr3 | smb: hm, where can those identifiers be looked up? | 16:58 |
| apw | cr3 ... looking | 16:58 |
| tgardner | bjf, can you review 'Karmic/Hardy SRU: thinkpad-acpi: lock down video output state access, CVE-2010-3448' ? | 16:58 |
| ubot2 | tgardner: 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:58 |
| cr3 | apw: I looked at http://www-pc.uni-regensburg.de/hardware/TECHNIK/PCI_PNP/pnpid.txt, can't seem to map that to smb's output above | 16:58 |
| apw | cr3, i think they are mostly fake | 17:01 |
| cr3 | apw: wild goose chase.. I prefer chasing sheep | 17:03 |
| JFo | sforshee, don't forget to change status on your bugs so they reflect the latest. :) | 17:04 |
| apw | cr3 ok think i have them | 17:04 |
| apw | P: /devices/platform/i8042/serio1/input/input9 | 17:04 |
| apw | E: MODALIAS=input:b0011v0002p0008e0000-e0,1,2,k110,111,112,r0,1,amlsfw | 17:04 |
| apw | #define BUS_I8042 0x11 | 17:04 |
| apw | so that mouse is on 'b0011' bus ID 11, which is BUS_I8042 | 17:05 |
| apw | include/linux/input.h | 17:05 |
| cr3 | apw: ok, so at least the <bus> part doesn't seem to be fake | 17:06 |
| apw | 'fake' in the sense its an internal to the kernel numbering thingy | 17:06 |
| apw | input_dev->id.bustype = BUS_I8042; | 17:06 |
| apw | input_dev->id.vendor = 0x0002; | 17:06 |
| apw | input_dev->id.product = psmouse->type; | 17:06 |
| apw | input_dev->id.version = psmouse->model; | 17:06 |
| apw | so for a mouse it does that ... | 17:06 |
| apw | clearly 0x2 has no name | 17:06 |
| bjf | tgardner, looking | 17:06 |
| apw | but it is possible all mice are 2 there | 17:07 |
| sforshee | JFo, trying to, but sometimes I forget, or maybe don't know that they require an update | 17:07 |
| sforshee | any in particular you're referring to? | 17:07 |
| apw | dev2->name = "PS/2 Touchpad"; | 17:07 |
| apw | dev2->id.bustype = BUS_I8042; | 17:07 |
| apw | dev2->id.vendor = 0x0002; | 17:07 |
| apw | dev2->id.product = PSMOUSE_LIFEBOOK; | 17:07 |
| apw | dev2->id.version = 0x0000; | 17:07 |
| JFo | sforshee, heh, no problem | 17:07 |
| apw | cr3 that for a touchpad | 17:07 |
| JFo | sforshee, when you ask for information, you can mark the bug incomplete | 17:07 |
| JFo | and when you take actively working the issue, you can set it to In Progress, incomplete, etc. | 17:08 |
| JFo | it is just so I can tell what the current state is | 17:08 |
| sforshee | JFo, yeah, I know I've forgotten that a couple of times, I'll try to remember | 17:08 |
| JFo | and if something has been incomplete for a while it gets automatically expired after a time | 17:09 |
| JFo | sforshee, it isn't a big deal :) | 17:09 |
| JFo | just wanted to remind | 17:09 |
| cr3 | apw: except for smb, he seems to have a vendor of 0 | 17:09 |
| apw | cr3, his i think was not a mouse | 17:09 |
| cr3 | apw: and I think to have version 7321, which seems like a heck of a high version | 17:10 |
| smb | The random pick I made seems to be my acpi graphics device | 17:11 |
| apw | input->name = acpi_device_name(video->device); | 17:11 |
| apw | input->phys = video->phys; | 17:11 |
| apw | input->id.bustype = BUS_HOST; | 17:11 |
| apw | input->id.product = 0x06; | 17:11 |
| apw | cr3, so i think his is his video card | 17:12 |
| apw | you might find the other things more useful than the alias though | 17:12 |
| smb | yep so guessed | 17:13 |
| apw | E: MODALIAS=input:b0019v0000p0006e0000-e0,1,kE0,E1,E3,F1,F2,F3,F4,F5,ramlsfw | 17:13 |
| apw | P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input12 | 17:13 |
| apw | for example that is my video card | 17:13 |
| apw | cr3 perhaps we might turn this round and ask what you are trying to work out | 17:14 |
| jjohansen | rebooting | 17:14 |
| apw | E: PRODUCT=11/2/8/7321 | 17:15 |
| apw | E: NAME="AlpsPS/2 ALPS GlidePoint" | 17:15 |
| apw | from my dell | 17:15 |
| cr3 | apw: trying to accurately detect touchpad devices. I'm in the process of referring to capabilities/key under the input device in sysfs but, in doing so, I noticed the PRODUCT variable which I thought might provide additional information of interest. | 17:15 |
| JFo | <- lunch | 17:17 |
| tgardner | jjohansen, since you're somewhat xen qualified, please have a look at the Hardy xen SRU request on the k-t list. | 17:38 |
| jjohansen | tgardner: hehe, yeah already looking at it | 17:38 |
| tgardner | cool. thanks | 17:38 |
| === sforshee is now known as sforshee-lunch | ||
| apw | JFo, we seem to have lost some closed bugs ... did we look at getting the tag searcher to keep closed bugs too ? | 18:05 |
| JFo | apw, hmmm that may have been from me removing the ones that were in the manual list | 18:06 |
| apw | JFo, i think that search for tags i gave you is selecting open only, and prolly a one liner to fix that | 18:07 |
| JFo | yeah, I think that is possible | 18:07 |
| apw | JFo, what was it called anyhow? i seem to have lost it | 18:07 |
| JFo | I have it on my todo | 18:07 |
| JFo | list-tag.py | 18:08 |
| JFo | it is stored in the canonical-qa-tracking bzr branch | 18:08 |
| JFo | apw, do you also want to see Invalid and Won't Fix? | 18:17 |
| apw | JFo, i'd say so to start with, as those are dispositions of a sort | 18:17 |
| JFo | ok | 18:17 |
| apw | i suspect we need to work out how to make them dissappear like a month after they go closed | 18:18 |
| apw | but we can work on that separate | 18:18 |
| bdmurray | bug 708690 looks important | 18:21 |
| ubot2 | Launchpad bug 708690 in linux "Kernel 2.6.35-25-generic boots into command prompt rather than GUI" [High,New] https://launchpad.net/bugs/708690 | 18:21 |
| apw | bdmurray, nvidia binary drivers i suspect | 18:21 |
| kees | sconklin, bjf: so, another kernel with security fixes landed in -updates without any notification to the security team. :( | 18:22 |
| kees | (lucid) | 18:22 |
| kees | where are maverick, karmic, and hardy? or is there no plans to do lock-step updates? | 18:22 |
| apw | maverick was promoted this morning i think | 18:23 |
| tgardner | kees, isn't this an archive admin issue? they are the ones doing the pocket copies. Or do you need to do the copy to -security as well? | 18:23 |
| kees | tgardner: we have to copy to -security, publish USNs, possibly do ABI-tracked bumps, etc. | 18:24 |
| kees | tgardner: this is the second time there has been no notification to the security team about kernels with CVE fixes :( where is this process dropping the ball? is the security team supposed to be watching something, the kernel team pinging us, or the archive admins pinging us? | 18:25 |
| tgardner | kees, well, until we work through the backlog of CVEs, this is likely to happen with every promotion to -proposed, so we'd better figure out how to coordinate. | 18:26 |
| tgardner | kees, how would you like to be notified? | 18:26 |
| kees | tgardner: in a perfect world, all kernels for all releases would promote at the same time. is that possible? | 18:26 |
| kees | tgardner: I'd like to know the day before it's planned to go out. if there is a fixed schedule, that works too. | 18:26 |
| tgardner | kees, well, its up to the AA ding the pocket copying. | 18:27 |
| tgardner | doing* | 18:27 |
| kees | so it's not like "on the 2nd thursday of the cadence, kernels are published"? | 18:27 |
| apw | bdmurray, yeah this guy says "I am using the most recent Nvidia graphics driver, obtained directly from Nvidia" so I assume he needs to know what the heck he is doing | 18:28 |
| tgardner | kees, well, I think sconklin _does_ request pitti to do the copy, but it doesn't always happen like clockwork. | 18:28 |
| sconklin | kees: no, releases are not and can't be synchronized | 18:28 |
| kees | sconklin: okay, we'll find a way to adjust our USN practices. | 18:29 |
| sconklin | even beyond that, with the new process, there's no guarantee that the same CVE gets applied to all kernels at the same time | 18:29 |
| kees | sconklin: what I'd really like is for USNs to be timed to pocket copies, but that requires advanced notice of the pocket copying | 18:29 |
| sconklin | also, in most cases, the pocket copies are done when cert is done or there's enough time in -proposed. we don't ask for it | 18:30 |
| kees | okay, so it sounds like this notification does not need to be in the hands of the kernel team. | 18:30 |
| kees | now, I'd like USNs to be proactive instead of reactive, so that needs to be coordinated with the pocket copying. | 18:30 |
| bdmurray | apw: okay, thanks | 18:30 |
| kees | who has traditionally done the copying? is it any archive admin, or is someone dedicated to the kernel cadence? | 18:31 |
| tgardner | kees, I think its only pitti to date | 18:32 |
| kees | okay, I will go pester him, thanks! | 18:32 |
| kees | tgardner: what's the eta on hardy and dapper? | 18:35 |
| tgardner | kees, I just pushed a xen commit for Hardy, CVE-2010-3699 | 18:35 |
| ubot2 | tgardner: The backend driver in Xen 3.x allows guest OS users to cause a denial of service via a kernel thread leak, which prevents the device and guest OS from being shut down or create a zombie domain, causes a hang in zenwatch, or prevents unspecified xm commands from working properly, related to (1) netback, (2) blkback, or (3) blktap. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3699) | 18:35 |
| kees | cool | 18:35 |
| tgardner | kees, there is also one pending for dapper | 18:36 |
| sbeattie | tgardner: same one or something different? | 18:36 |
| kees | tgardner: right, but I mean, hardy and dapper weren't published in the last cadence cycle. | 18:36 |
| tgardner | kees, not sure when sconklin et all will wrap those up in a bow | 18:36 |
| tgardner | sbeattie, something different, CVE-2010-4078 | 18:37 |
| ubot2 | tgardner: The sisfb_ioctl function in drivers/video/sis/sis_main.c in the Linux kernel before 2.6.36-rc6 does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via an FBIOGET_VBLANK ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4078) | 18:37 |
| tgardner | kees, since dapper/hardy aren't really part of the 2 week cadence, we can likely coordinate them better. | 18:38 |
| kees | sconklin: in the future, can you merge unpublished changelogs (and just bump the version forward) to avoid things like Lucid's current changelog? | 18:38 |
| sconklin | hardy, karmic, and dapper are sitting in proposed, waiting to be published. We don't really decide when. Usually at the point we are ready to put new ones in -proposed, we'll remind pitti that they are there | 18:38 |
| kees | tgardner: why are the LTSes not part of the cadence? | 18:38 |
| kees | so it sounds like pitti needs to be on this too? | 18:38 |
| tgardner | kees, no test capacity with cert and qa | 18:38 |
| sconklin | the cadence is interlocked with cert and QA, and they only test lucid and Maverick | 18:39 |
| * kees starts crying | 18:39 | |
| jdstrand | whoa, seriously? | 18:39 |
| sconklin | it's been coincidence so far that the pther match up, and we'd like to keep it that way, but it probably won't happen | 18:39 |
| jdstrand | so security patches could conceivably go out without testing? | 18:39 |
| tgardner | jdstrand, as they always have... | 18:40 |
| tgardner | kees did the only testing | 18:40 |
| sconklin | I love it when people first clue in to that . . . | 18:40 |
| jdstrand | tgardner: well, they are going through -proposed now, and then pushed without the security team's knowledge | 18:40 |
| kees | kernel team did boot testing, and I did regression testing. that's not "untested" | 18:40 |
| jdstrand | tgardner: in the past, someone either from the kernel team or the security team would test | 18:40 |
| sconklin | yeah, that's one of the major drivers for putting security fixes into the normal patch handling process | 18:40 |
| tgardner | jdstrand, not always. we've had some regressions. | 18:41 |
| jdstrand | kees: ok, I was under the impression that you were not aware of those kernels | 18:41 |
| kees | jdstrand: "those"? | 18:41 |
| jdstrand | 12:40 < kees> kernel team did boot testing, and I did regression testing. that's not "untested" | 18:41 |
| kees | I meant "In the past, kernel team did boot testing, and I did regression testing. that's not "untested"" | 18:41 |
| kees | not with these | 18:42 |
| jdstrand | ah | 18:42 |
| kees | with the "new process", QA does the boot and regression testing | 18:42 |
| jdstrand | right, except not for anything before lucid | 18:42 |
| kees | but now I'm told there is no QA team for anything other than stable and LTS | 18:42 |
| kees | (er, most recent stable...) | 18:42 |
| jdstrand | but the kernels are stilling using the same -proposed process | 18:42 |
| jdstrand | which means they could miss at least our team's regression testing | 18:43 |
| sconklin | kees: I think that cert and qa have been testing other releases as they can, but I don't think there's any guarantee | 18:43 |
| kees | I just don't know any other way to say this: we need CVEs fixed in all the releases. this happened in the past, and it needs to keep happening, regardless of the process. I don't much care what the process is. | 18:43 |
| jdstrand | if there isn't coordination, which there has been a problem with lately | 18:43 |
| kees | if QA is doing the testing, and using qrt (which they say they are), I'm happy with that. | 18:44 |
| jdstrand | kees: that assumes that the CVE fix/regression tests get run, which we have to know about them to write them and they have to be public | 18:45 |
| kees | jdstrand: right, this whole process is only for public CVEs, and we write the test cases as we can. | 18:46 |
| jdstrand | kees: which sorta implies we need to write the tests as soon as we see a CVE (if possible), and the 1 day alert that you mentioned | 18:46 |
| kees | very few of the CVEs end up with viable test cases | 18:47 |
| jdstrand | I'm also a little concerned about the comment about a CVE might be fixed in maverick, but not lucid | 18:47 |
| jdstrand | that ec2 CVE is a prime example of why that can be a problem | 18:48 |
| jdstrand | (rather the CVE for linux-ec2) | 18:48 |
| tgardner | jdstrand, we attempt to fix the vulnerability in all the applicable kernels | 18:48 |
| tgardner | that we support | 18:48 |
| jdstrand | it seems all of this will a) get better with more coordination b) become a lot easier once the CVE backlog is caught up | 18:50 |
| tgardner | jdstrand, yeah, we've still got 30 or more left | 18:50 |
| kees | I'm worries that the older stable releases are not part of the cadence. I think that needs to be fixed first. | 18:50 |
| jdstrand | so, as long as we are striving to work together (along with the pocket copying AA), things will improve | 18:50 |
| kees | s/ies/ied/ | 18:51 |
| kees | but it sounds like that's primarily a QA time issue? | 18:51 |
| jdstrand | kees: it sounds like the kernel team is patching them | 18:51 |
| jdstrand | kees: if they have only security fixes, the kernel team can upload those fixes to their ppa at the same time | 18:52 |
| kees | steps are triage (security), patching(kernel+security), building(kernel), testing(qa), publishing(archiveadmin+security). | 18:52 |
| jdstrand | kees: as the others. then just mention it to QA to test. if they can't, we can do qrt and publish through -security | 18:52 |
| === bjf is now known as bjf[afk] | ||
| * tgardner --> lunch date | 18:54 | |
| === sforshee-lunch is now known as sforshee | ||
| komputes | JFo: Could you please have a look at this bug. Seems like an ACPI issue which causes the laptop to be seen as a desktop: https://bugs.launchpad.net/bugs/701561 | 19:08 |
| ubot2 | Launchpad bug 701561 in indicator-applet "IBM ThinkPad X31 not seen as laptop - battery status not available" [Undecided,New] | 19:08 |
| * JFo looks | 19:08 | |
| komputes | JFo: do we have an ACPI expert? | 19:08 |
| apw | define seen as a desktop ... just no battery you mean? | 19:09 |
| apw | i know of no 'desktop/laptop' differentiator in acpi | 19:09 |
| komputes | apw: yes, plus laptop-detect report no indication that it is a laptop | 19:10 |
| kamal | dmidecode provides a "Chassis Type" which indicates desktop vs laptop ... | 19:10 |
| komputes | apw: oh ok, I must have been mistaking. Anyhow the applet always shows a thunderbolt (no battery/battery+AC icon) | 19:10 |
| apw | kamal, so there is | 19:11 |
| apw | and thats what the latop thing uses first | 19:11 |
| kamal | I've seen a laptop that had that set wrong in some BIOS table, which led to various problems relating to lid/battery ... | 19:11 |
| apw | dmitype=$(dmidecode --string chassis-type) | 19:11 |
| apw | what does that say on it komputes | 19:11 |
| JFo | huh | 19:11 |
| JFo | komputes, also, it would be really helpful to get the apport-collected data here | 19:12 |
| vanhoof | vanhoof@downer:~$ sudo dmidecode --string chassis-type | 19:12 |
| vanhoof | Lunch Box | 19:12 |
| vanhoof | lulz | 19:12 |
| apw | komputes, could we get sh -x /usr/sbin/laptop-detect | 19:13 |
| apw | vanhoof, is that the machine or something else? | 19:13 |
| JFo | vanhoof, :) | 19:13 |
| JFo | mine says Notebook | 19:13 |
| apw | Portable | 19:14 |
| apw | for mine, but thats ok too | 19:14 |
| vanhoof | that was run on a mac mini | 19:14 |
| vanhoof | Lunch Box ... | 19:14 |
| kamal | komputes: just the output from this would be good: sudo dmidecode --string chassis-type | 19:14 |
| JFo | huh, for my desktop it says Unknown | 19:14 |
| apw | komputes, oh and remember to tun laptop-detect with sudo | 19:15 |
| apw | vanhoof, as in "out to `sudo dmidecode --string chassis-type`" | 19:15 |
| vanhoof | apw: yup | 19:16 |
| komputes | How does one find out the driver being used by a USB network card - I would like to add an entry to https://help.ubuntu.com/community/HardwareSupportComponentsWirelessNetworkCardsBelkin#USB | 19:43 |
| komputes | apw: i will and let you know if the result is different | 19:44 |
| apw | komputes, does lsusb -vv tell you ? can't remember | 19:44 |
| komputes | apw: idProduct and idVendor and a lot of verb info but no module. I never understood why lsusb doesn't have a -k feature for kernel module (like lspci) | 19:47 |
| === bjf[afk] is now known as bjf | ||
| * jjohansen -> lunch | 20:35 | |
| * tgardner notes that the dapper build does not parallelize correctly | 21:25 | |
| === sconklin is now known as sconklin-gone | ||
| kees | oops, I broke cpu hotplug | 23:05 |
| apw | kees, tsk, let me guess ... nx | 23:14 |
| kees | apw: well, related to that, but actually my ignore-the-bios-filter-for-nx code. https://lkml.org/lkml/2011/1/27/345 | 23:15 |
| apw | kees, bad kees | 23:25 |
| kees | apw: whee | 23:26 |
| apw | kees, could you email me any resolution as i will be pushing the A2 kernels very early next week at the latest | 23:28 |
| apw | and i want to make sure that is in | 23:28 |
| kees | apw: yeah, for sure. I'm under an OOo update at the moment, but if someone else doesn't confirm my fix, I'll try it. | 23:29 |
| apw | ok | 23:29 |
| jjohansen | back on later | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!