[00:12] <apw> soren, if its not that then git cat-file -p  $SHA:path/to/file
=== smb` is now known as smb
[09:10] <ricotz> apw, hello :), do you know if there is a package of Ubuntu-lts-2.6.35-25.44 for lucid already available?
[09:13] <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:15] <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:16] <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:17] <smb> apw, lilely. as the repo is up to date. I guess we should/could just upload the latest version
[09:18] <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:19] <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:20] <smb> ricotz, That would be a few more hours 
[09:21] <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:23] <smb> For Natty surely. Maverick, maybe. Though probably it just should be on the list of steps when uploading a Maverick to proposed
[09:24] <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:25] <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:27] <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:28] <smb> apw, We should brig that up. Maybe there is a wiki page about that already, of which nobody has heard. :-P
[09:29] <apw> heheh probabally
[09:39] <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:42] <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:43] <apw> ohsix, what system is affected
[09:44] <ohsix> you mean model number? compaq cq60
[09:57] <apw> ohsix, from the bug it seems worth checking out that usbcore.autosuspend thing
[09:58] <ohsix> yea
[10:01] <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:12] <ohsix> yea, no dice on the usb thing
[10:15] <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:53] <ohsix> hrm, the pm_trace thing on the failed sleep always turns up in drivers/base/power/main.c:605
[10:54] <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:55] <apw> ohsix, which kernel?  lucid ?
[10:55] <ohsix> the natty kernel, 2.6.37-12 or something
[10:58] <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:59] <ohsix> ya i looked at it already; too bad it doesn't say which device it's resuming
[11:00] <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:04] <ohsix> hm, i assued the tracepoints were automatic, reading s2ram.txt says i might have to add some
[11:08] <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:10] <ohsix> out of time for this today, i'll be back later
[11:12] <ohsix> if you find any information i should digest when i pick it back up, msg me, bye :]
[11:22] <rocky2> Hey can anyone help me with kernel debugging... using kgdb?
[11:29]  * apw doesn't recall every using kgdb
[11:29] <apw> but ask your question, someone might know
[11:30] <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:31] <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...
=== cking is now known as cking-afk
[12:50] <stefanlsd> apw: just to let you know i'll test your kernels for bug #552311   - needed it for a while for kvm passthru
[12:51] <ubot2> Launchpad bug 552311 in linux "CONFIG_DMAR is not set " [Medium,Incomplete] https://launchpad.net/bugs/552311
[12:54] <apw_> sl
[12:56] <apw_> stefanlsd i had about given up on getting testing for that one ... missed tgis upload either way
=== yofel_ is now known as yofel
[12:58] <stefanlsd> apw_: yeah, sorry. was subscribed to the other bug about it. will still do
[12:59] <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
=== rsalveti is now known as rsalveti_
=== rsalveti` is now known as rsalveti
[13:30] <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?
=== cking-afk is now known as cking
[13:52] <tgardner> smb, tangerine:/home/rtg/kern/hardy/kern-64/ubuntu-hardy/debian/build/custom-source-xen
[14:00] <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:21] <tgardner> apw, https://kernel-tools.canonical.com/srus.html
[14:25] <apw> cking, https://edge.launchpad.net/~kernel-ppa/+archive/pre-proposed/+packages
[14:49] <apw> sconklin, hey
[14:49] <sconklin> apw: hi
[14:49] <apw> mumble ?
[14:54] <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]
[15:00] <apw> http://reports.qa.ubuntu.com/reports/jfo/kernel-buglist-by-team.html
[15:00] <JFo> \o/
[15:00] <JFo> :)
[15:07] <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:10] <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:11] <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:14] <apw> JFo, mumble ?
[15:15] <JFo> one sec... was listening to some music :)
=== bjf[afk] is now known as bjf
[15:53] <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:54] <JFo> apw, want me to do that?
[15:54] <apw> if you have time, that'd be great
[15:55] <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:56] <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:57] <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:58] <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:59] <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
[16:00] <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:02] <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:06] <manjo> sforshee, git clone git://kernel.ubuntu.com/ubuntu/kteam-tools.git
[16:06] <manjo> sforshee, https://wiki.ubuntu.com/KernelTeam/SuspendResumeTesting
[16:07] <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:08] <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:09] <JFo> I should be able to add some sort of legend to the page
[16:13] <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:14] <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:15] <JFo> huh, I hadn't noticed that.
[16:15] <JFo> thanks
[16:16] <JFo> huh, that is a launchpad librarian icon
[16:18] <bjf> JFo, i'll wager that with the new corporate style, there is a different logo link
[16:19] <JFo> I was just thinking that
[16:19] <JFo> wonder where it is... ah well, I'll get it later
[16:20] <bjf> JFo, don't think we really need it, just taking up useful space
[16:20] <JFo> yeah, was just prettification
[16:24] <maks_> just saw the 2.6.32.28.13
[16:25] <maks_> there are some drm patches we fwd from 2.6.35, that you'd could also be interested
=== Quintasan_ is now known as Quintasan
[16:26] <maks_> in total they were eleven
[16:26] <tgardner> smb, ^^
[16:26] <maks_> smb: they are found in Debian 2.6.32-30.
[16:27] <maks_> 2.6.35 longterm support forward ported them mostly fine.
[16:31] <maks_> they are not all in bwh's git mirror, as it seem out of sync
[16:31] <maks_> :/
[16:37] <JFo> hiya skaet :)
[16:37] <JFo> let me know if you have any new bugs for me.
[16:37] <JFo> :-)
[16:38] <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:43] <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:44] <maks_> ok cool.
[16:48] <smb> cr3, what udevadmn command? Did it fail? Otherwise it means that the environment variable PRODUCT has this value. :-P
[16:49] <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:51] <smb> could be bus numbers as well as vendor product subvendor subproduct... Need to look at one example here
[16:52] <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:53] <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:55] <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:57] <smb> nSo we have <bus>/<vendor id>/<product id>/<version>
[16:58] <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
[17:01] <apw> cr3, i think they are mostly fake
[17:03] <cr3> apw: wild goose chase.. I prefer chasing sheep
[17:04] <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:05] <apw> so that mouse is on 'b0011' bus ID 11, which is BUS_I8042
[17:05] <apw> include/linux/input.h
[17:06] <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:07] <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:08] <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:09] <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:10] <cr3> apw: and I think to have version 7321, which seems like a heck of a high version
[17:11] <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:12] <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:13] <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:14] <apw> cr3 perhaps we might turn this round and ask what you are trying to work out
[17:14] <jjohansen> rebooting
[17:15] <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:17] <JFo> <- lunch
[17:38] <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
=== sforshee is now known as sforshee-lunch
[18:05] <apw> JFo, we seem to have lost some closed bugs ... did we look at getting the tag searcher to keep closed bugs too ?
[18:06] <JFo> apw, hmmm that may have been from me removing the ones that were in the manual list
[18:07] <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:08] <JFo> list-tag.py
[18:08] <JFo> it is stored in the canonical-qa-tracking bzr branch
[18:17] <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:18] <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:21] <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:22] <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:23] <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:24] <kees> tgardner: we have to copy to -security, publish USNs, possibly do ABI-tracked bumps, etc.
[18:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:31] <kees> who has traditionally done the copying? is it any archive admin, or is someone dedicated to the kernel cadence?
[18:32] <tgardner> kees, I think its only pitti to date
[18:32] <kees> okay, I will go pester him, thanks!
[18:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <kees> if QA is doing the testing, and using qrt (which they say they are), I'm happy with that.
[18:45] <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:46] <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:47] <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:48] <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:50] <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:51] <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:52] <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
=== bjf is now known as bjf[afk]
[18:54]  * tgardner --> lunch date
=== sforshee-lunch is now known as sforshee
[19:08] <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:09] <apw> define seen as a desktop ... just no battery you mean?
[19:09] <apw> i know of no 'desktop/laptop' differentiator in acpi
[19:10] <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:11] <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:12] <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:13] <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:14] <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:15] <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:16] <vanhoof> apw: yup
[19:43] <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:44] <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:47] <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)
=== bjf[afk] is now known as bjf
[20:35]  * jjohansen -> lunch
[21:25]  * tgardner notes that the dapper build does not parallelize correctly
=== sconklin is now known as sconklin-gone
[23:05] <kees> oops, I broke cpu hotplug
[23:14] <apw> kees, tsk, let me guess ... nx
[23:15] <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:25] <apw> kees, bad kees
[23:26] <kees> apw: whee
[23:28] <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:29] <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:46] <jjohansen> back on later