| === lifeless_ is now known as lifeless | ||
| === GrueMaster_ is now known as GrueMaster | ||
| === lag` is now known as lag | ||
| * apw yawns | 08:45 | |
| * jjohansen waves goodbye | 09:46 | |
| apw | ppisati, morning | 10:16 |
|---|---|---|
| apw | ppisati, i see you looked at CVE-2011-1090, i assume you are just looking at the versions which are a straight cherry-pick there? | 10:17 |
| ubot2 | apw: The __nfs4_proc_set_acl function in fs/nfs/nfs4proc.c in the Linux kernel before 2.6.38 stores NFSv4 ACL data in memory that is allocated by kmalloc but not properly freed, which allows local users to cause a denial of service (panic) via a crafted attempt to set an ACL. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1090) | 10:17 |
| ppisati | apw: yep | 10:24 |
| ppisati | apw: actually when i posted it i just wanted a couple of acks, but an apply is even better :) | 10:24 |
| apw | ppisati, tim likes to get things moving along | 10:26 |
| ppisati | yep | 10:27 |
| apw | ppisati, i closed out your oldest active CVE, 2010-3859 turns out it was already applied when i fixed the upstream commits | 10:33 |
| ppisati | ok | 10:41 |
| ppisati | apw: CVE-2011-0711 is marked as "needs-triage" in fsl-imx51 but the fixes have already been committed | 10:50 |
| ubot2 | ppisati: The xfs_fs_geometry function in fs/xfs/xfs_fsops.c in the Linux kernel before 2.6.38-rc6-git3 does not initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via an FSGEOMETRY_V1 ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0711) | 10:50 |
| apw | ppisati, ok let me look at that | 10:51 |
| apw | ppisati, ok that was cause by the fact that there are two sha1s for the possible fixes upstream | 10:58 |
| apw | ppisati, and for lucid and lucid only someone used the other one for one patch | 10:58 |
| apw | ppisati, can and will fix it now | 10:59 |
| ppisati | apw: and i just noticed that i forgot one of the patches in maverick/ti-omap4... uhmmm.... | 10:59 |
| apw | ppisati, which is presumably why its also needs-triage | 10:59 |
| apw | ppisati, so just slap that one on the next pile and it will sort itself out | 11:00 |
| ppisati | yep | 11:01 |
| ppisati | and luckily mav/omap4 didn't go out... it seems SRU has enough work... | 11:01 |
| apw | ppisati, it actually doesn't matter, as the CVE would not be deemed fixed until the second patch was detected as applied so they would get half the fix (which in this case is useful and safe) but not an entire fix | 11:03 |
| ppisati | ok | 11:04 |
| apw | ppisati, this is one of the advantages of the new scripted detection, it really knows if you are done | 11:04 |
| ppisati | cool | 11:04 |
| apw | before you would have said "released" and the world is bluffed | 11:05 |
| apw | ppisati, ok 0711 is now fixed for fsl-imx51 | 11:08 |
| ppisati | k | 11:10 |
| ppisati | apw: http://bugs.launchpad.net/bugs/801083 | 11:10 |
| ubot2 | Ubuntu bug 801083 in linux-ti-omap4 "CVE-2011-1012" [Undecided,New] | 11:10 |
| ppisati | nominations | 11:10 |
| apw | ppisati, done | 11:10 |
| ppisati | btw, why don't i have the nominations right? i mean, this why i don't way to beg anyone | 11:11 |
| ppisati | this way | 11:11 |
| apw | ppisati, because stupidly nomination rights are part of being an uploader or a very very high up in release managment option | 11:11 |
| ppisati | ah | 11:11 |
| ppisati | uhm | 11:11 |
| apw | ppisati, which frankly makes no sense to me what so ever, but that is how it is | 11:11 |
| ppisati | so how do i become an uploader? | 11:12 |
| apw | i think there are plan afoot to split nomination off so we can ask for you to get that | 11:12 |
| ppisati | ok | 11:12 |
| apw | to be an uploader you need to learn all the stuff that herton is doing basically | 11:12 |
| ppisati | doh! | 11:13 |
| apw | then convince someone outside the group to let you | 11:13 |
| apw | (there is a committee) | 11:13 |
| apw | i am sure you will be asked to get that over time, but the nominations thing should be separate | 11:13 |
| ppisati | ok, let's hope for the rights split | 11:13 |
| apw | as it is simply very very anoying | 11:13 |
| ppisati | right | 11:13 |
| apw | it was worse when noone in our team in the EU had them, smb and i had to wait until tim woke up | 11:14 |
| apw | and that made us very mad | 11:14 |
| ppisati | what a waste of time | 11:14 |
| apw | ppisati, yeah and its on our "please fix this" list for launchpad, it should be a separate acl so we can add canonical-kernel-team to the nominations one | 11:16 |
| ppisati | apw: sounds logical | 11:20 |
| ppisati | btw, here's another one | 11:20 |
| ppisati | CVE-2010-4163 | 11:20 |
| ubot2 | ppisati: The blk_rq_map_user_iov function in block/blk-map.c in the Linux kernel before 2.6.36.2 allows local users to cause a denial of service (panic) via a zero-length I/O request in a device ioctl to a SCSI device. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4163) | 11:20 |
| ppisati | it's made of 2 patches | 11:20 |
| ppisati | but the second one supeseded the first one | 11:20 |
| ppisati | thus i apllied only the second one | 11:20 |
| ppisati | and the CVE matrix marks it as "needs-triage" | 11:20 |
| apw | ppisati, lookin | 11:23 |
| apw | ppisati, so does one get reverted or something? | 11:25 |
| apw | ppisati, ok i see so one adds it and the other moves it | 11:26 |
| apw | ppisati, so what did you do, just add it in the second place? | 11:27 |
| apw | in the second commit? | 11:27 |
| apw | if so then the new single commit should mention both sha1s as it is both | 11:27 |
| ppisati | apw: just committed the second one | 11:27 |
| ppisati | ah, ok | 11:27 |
| apw | but the second one is a move | 11:27 |
| apw | so it wouldn't apply without the first right? | 11:27 |
| ppisati | modified it | 11:27 |
| * apw will sort this out somehow | 11:28 | |
| ppisati | ok, thanks | 11:28 |
| apw | ppisati, ahh good its not been 'released' yet so i can just re-write it | 11:30 |
| ppisati | apw: can't you just fix the tracker? | 11:30 |
| apw | ppisati, i can only fix the tracker by telling it that your commit actually should say two things | 11:31 |
| apw | ppisati, and as this has not yet been closed i can rewrite it safly | 11:31 |
| apw | ppisati, so its simpler to fix the history so its accurate | 11:31 |
| ppisati | ok | 11:31 |
| apw | ppisati, i see why you only got half the fixes ... as only one is marked in the lucid history, as we got half via stable | 11:39 |
| apw | you do need to check the tracker for all the ids | 11:39 |
| ppisati | apw: and there's another one in the same state, somehow... | 11:43 |
| ppisati | CVE-2010-4655 | 11:43 |
| ubot2 | ppisati: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4655) | 11:43 |
| ppisati | it's made of 2 commits | 11:44 |
| ppisati | the first one was in lucid/master (and i cherry picked it) | 11:44 |
| ppisati | while the second one was made to resolve a conflict with nother commit (and we didn't import) | 11:44 |
| ppisati | so it was not committed in master | 11:44 |
| ppisati | and thus i didn't bring it in | 11:45 |
| apw | ppisati, ok so we are in the right place there (fsl-imx51 yes?) | 11:45 |
| ppisati | apw: yep | 11:45 |
| ppisati | apw: both fsl-imx51 and mav/omap4 | 11:46 |
| ppisati | but in the CVE tracker ios marked as "needs triage" | 11:46 |
| apw | yes as the tracker says you need both to make that CVE 'applied' | 11:46 |
| apw | for those i will tell the tracker applier those ones only needed the one sort of | 11:46 |
| ppisati | so, do i import the clashing commit and the second fix, or what? | 11:47 |
| ppisati | ok | 11:47 |
| apw | if we truly only need the first fix to fix the CVE then i can tell the tracker that | 11:49 |
| apw | ppisati, ^^ | 11:50 |
| ppisati | apw: as far as the CVE goes, yes, we need only the first one | 11:50 |
| apw | then good enough | 11:50 |
| apw | tgardner, any idea if lsattr is related to xattrs or if its something else | 13:29 |
| apw | stupid naming | 13:29 |
| tgardner | apw, haven't the faintest. | 13:31 |
| tgardner | lsattr - list file attributes on a Linux second extended file system | 13:31 |
| tgardner | doesn't seem to display extended attributes | 13:32 |
| apw | pwd | 14:27 |
| apw | pthhtht | 14:27 |
| ogasawara | smb`: can I mark your iscsitarget work item as done? | 14:33 |
| ogasawara | bah, forgot he's away today | 14:34 |
| tgardner | ogasawara, I applied his patch, so I would say yes | 14:35 |
| * ogasawara back in 20 | 14:36 | |
| tgardner | apw, do you remember which firmware bug number you pointed me at yesterday? the only update for Oneiric that I see is for iwlwifi-5000-5.ucode | 14:44 |
| apw | tgardner, hmmm | 14:44 |
| tgardner | apw, nm, I can probably find it through LP | 14:45 |
| apw | tgardner, i filed it so i should be able to find it pretty quick | 14:45 |
| tgardner | apw, bug #800678 | 14:46 |
| ubot2 | Launchpad bug 800678 in linux-firmware "ath9k firmware out of date for kernel 3.0" [Undecided,New] https://launchpad.net/bugs/800678 | 14:46 |
| tgardner | its ath9k, not iwlwifi | 14:46 |
| apw | tgardner, heh how did you find it quicker than i can from my own list ... bah | 14:46 |
| tgardner | apw, if you look at the package page (https://bugs.launchpad.net/ubuntu/+source/linux-firmware), it gives you a link to new bugs | 14:47 |
| apw | tgardner, point | 14:58 |
| tgardner | apw, ogasawara: where can I find the list implied in this work item: '[timg-tpi] review assigned set of Ubuntu delta patches and push upstream where applicable: TODO' | 15:04 |
| ogasawara | tgardner: https://wiki.ubuntu.com/KernelTeam/Specs/KernelOneiricUbuntuDeltaReview | 15:05 |
| ogasawara | Tim Gardner | 15:05 |
| ogasawara | ubuntulo1: SAUCE: Disable building the ACPI debugfs source | 15:05 |
| ogasawara | ubuntulo1: Sony laptop: Some Sony Vaia laptops do not enable wwan power by default. | 15:05 |
| tgardner | ogasawara, ack. thanks. you're as efficient as always :) | 15:06 |
| apw | ogasawara, do i see your nick completion getting out of wack there ? | 15:23 |
| * apw pops out to do some rally prep errands | 15:24 | |
| ogasawara | apw: nah, cut and paste from the wiki turned out weird | 15:25 |
| ogasawara | apw: s/ubuntulo1/UBUNTU/ | 15:25 |
| apw | ogasawara, i think thats nick completion though as that sub is actually a nick on this channel | 15:25 |
| apw | ogasawara, i suspect you have : as auto nick complete | 15:25 |
| ogasawara | hrm, /me check | 15:26 |
| apw | try typing tga:<space> | 15:26 |
| ogasawara | apw: you're right, it's set in my preferences | 15:27 |
| apw | right hairy backson | 15:27 |
| tgardner | apw, re :bug #800910 - are there any flavours other then -generic and -server that ought to have grub-efi as a bootloader ? I can't imagine any of the 32 bit platforms needing it. | 15:49 |
| ubot2 | Launchpad bug 800910 in linux "Kernel Upgrade forces removal of grub-efi due to missing recommends entry" [Undecided,In progress] https://launchpad.net/bugs/800910 | 15:49 |
| apw | tgardner, i wouldn't imagine so, if we had a -xen we might want it there | 16:54 |
| * apw is now officially shawn | 16:54 | |
| tgardner | apw, what is shawn? | 16:54 |
| apw | tgardner, it is what you do to a sheep | 16:55 |
| tgardner | oh, you got your ears lowered | 16:55 |
| apw | tgardner, i see we have grub-efi all the way back to hardy, i wonder if we should have that anywhere earlier than natty | 16:56 |
| tgardner | apw, what are the odds that machines will work with grub-efi in environments that old? | 16:57 |
| tgardner | will the kernels even work? | 16:58 |
| apw | tgardner, i assume we won't put it on by default just allow it to already be there, dunno if the kernels work of course | 16:58 |
| apw | heh | 16:58 |
| tgardner | I don't think kernels prior to Natty will support native EFI | 16:58 |
| apw | tgardner, i am a little worried about it being first, does that have any meaning | 16:59 |
| tgardner | apw, not as far as I can tell | 16:59 |
| apw | i am wondering if that is the one it would cause to be on the CD | 16:59 |
| tgardner | apw, its a recommends. we could always ask cjwatson or slangasek | 17:01 |
| apw | tgardner, ok the rule according to steve is the first one is the preferred one | 17:02 |
| apw | so if nothing else asks for anything then we only put on grub-efi | 17:02 |
| tgardner | apw, so I shold swap it | 17:03 |
| apw | i suspect that means we should put it second on natty at least | 17:03 |
| apw | tgardner, thats my take yes | 17:03 |
| tgardner | well, likely the same for oneiric | 17:03 |
| apw | yeah likely | 17:03 |
| tgardner | ok, I'll fix it up | 17:03 |
| apw | pgraner, what is it you use to keep your tunnels open | 17:21 |
| === cking_ is now known as cking | ||
| cjwatson | tgardner: grub-efi should definitely never be first | 17:42 |
| cjwatson | and "forces removal due to missing recommends" is nonsense | 17:42 |
| cjwatson | an unsatisfied recommends should not force removing a package | 17:42 |
| cjwatson | also, the real packages involved are grub-efi-amd64 and grub-efi-ia32 - grub-efi is a metapackage | 17:43 |
| cjwatson | good grief, that apt-get output is incredibly weird | 17:43 |
| cjwatson | tgardner: in my book, that's an apt bug and you should give mvo a task for it - adding non-first grub-efi-amd64 | grub-efi-ia32 Recommends won't hurt though | 17:44 |
| tgardner | cjwatson, well, should I reference the meta package, or the underlying package (since they are somewhat arch dependent, right?) | 17:44 |
| cjwatson | underlying | 17:44 |
| cjwatson | it doesn't matter if you recommend something that's missing | 17:44 |
| cjwatson | especially when it's one of several alternatives | 17:45 |
| tgardner | cjwatson, ok, can do | 17:45 |
| cjwatson | referring to the metapackage: consider the case where somebody has grub-efi-amd64 installed but not grub-efi | 17:45 |
| tgardner | makes sense | 17:45 |
| cjwatson | I still think it's not really your problem, but fixing apt's resolver in a stable release probably isn't happenng | 17:46 |
| pgraner | apw, gstm | 17:52 |
| apw | pgraner, ta | 17:56 |
| * tgardner is off to pack and get the road show organized, remembering the wifi AP for the hotel room. | 18:43 | |
| === tgardner is now known as tgardner-afk | ||
| apw | tgardner-afk, yeah wired only, how backward | 18:46 |
| * jjohansen -> lunch | 20:01 | |
| kees | apw: hm, why the not-affected -> pending changes? (rather, why was it ever not-affected?) | 20:20 |
| kees | -devel_linux-ti-omap4: not-affected | 20:20 |
| kees | +devel_linux-ti-omap4: pending (2.6.38-1309.13) | 20:20 |
| === Quintasan_ is now known as Quintasan | ||
| === yofel_ is now known as yofel | ||
| apw | kees, likely the version is it pending in is one from -release or before therefore not-affected ... after you do your usn processing | 20:59 |
| apw | kees, our agreed approach was move to pending if the version changes, so here it was n-a (no version) and now is (version) so it moves pending ... i assume you will process to n-a (version) and we are good | 21:00 |
| apw | or you will issue the usn cause it was wrong | 21:00 |
| kees | apw: but there are no USNs for devel releases | 21:01 |
| kees | apw: it was only the devel_* ones that I was curious about. | 21:01 |
| kees | apw: I would have expected them to just stay as "not-affected", but I guess once the tool found the commits, it made it "pending". | 21:02 |
| kees | I guess that's fine. our other script will fix this up as expected. okay. :) | 21:02 |
| kees | apw: heh. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/788684 changelog entry says "CVE-1011-..." time travel! :) | 21:33 |
| ubot2 | Ubuntu bug 788684 in linux "CVE-2011-2022" [Undecided,In progress] | 21:33 |
| kees | apw: where can I find the lucid mvl-dove tree? I'm trying to identify 'Revert "econet: fix CVE-2010-3848" | 22:04 |
| ubot2 | kees: Stack-based buffer overflow in the econet_sendmsg function in net/econet/af_econet.c in the Linux kernel before 2.6.36.2, when an econet address is configured, allows local users to gain privileges by providing a large number of iovec structures. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3848) | 22:04 |
| kees | ' in the changelog | 22:04 |
| kees | to make sure the fix came in from the upstream update, but I can't find the tree. (or rather, the one I know about doesn't have the revert) | 22:04 |
| kees | apw: oh-ho, I see it in master-next. | 22:05 |
| kees | is there an mvl-dove -next ? | 22:06 |
| kees | sconklin: do you know where I can find the -next trees for the other kernels? now I'm trying to hunt stuff for fsl-imx51 :) | 22:13 |
| === tgardner-afk is now known as tgardner | ||
| tgardner | kees, the only -next trees we carry are for the master branch because they are typically the only branches that have multiple committers | 22:22 |
| tgardner | rather, the only -next branches.... | 22:23 |
| sconklin | kees: what he said | 22:29 |
| kees | tgardner: okay, that makes sense. I guess I'm just trying to figure out how to review a kernel in -proposed when it one of the ports | 22:34 |
| tgardner | kees, check it out based on the tag ? | 22:35 |
| kees | tgardner: I'm not sure what you mean? for example, I was looking at mvl-dove, but it's tree didn't show that is in -proposed | 22:39 |
| tgardner | kees, well, the git repo doesn't really reflect the state of the package. is that the association you're trying to make ? | 22:41 |
| kees | yeah | 22:41 |
| sconklin | you have to check out the tag associated with the release | 22:41 |
| kees | it works for the master branches since there are versioned tags, etc | 22:41 |
| kees | sconklin: how would I do that for mvl-dove? I didn't see an associated tag | 22:42 |
| sconklin | which is especially necessary for branches like arm which are rebased | 22:42 |
| tgardner | about all you can say is that at each tag _something_ was uploaded, but it may not have been pocket copied from the c-k-t PPA | 22:42 |
| sconklin | kees: looking | 22:42 |
| sconklin | well, not 100% true, because things have been tagged and then failed to upload. But mostly true | 22:42 |
| apw | kees, there are tags for every upload so those should be the contents of the upload | 22:43 |
| apw | they are not linear on teh branches, but they should exist | 22:43 |
| kees | "not linear on the branches" | 22:43 |
| kees | ? | 22:43 |
| sconklin | branches which are rebased from other branches do not have a linear history across releases | 22:44 |
| apw | a rebased tree like mvl-dove is not linear in time, it jumps about, each release is tagged but you can only find the released version via the tag, as after rebase the commits it was made from are no longer findable from the head of the branch | 22:44 |
| kees | sconklin, apw: okay, so I see "Ubuntu-2.6.32-217.34" which is the version for mvl-dove, but I guess that tag isn't visible when I look at the mvl-dove branch? | 22:44 |
| sconklin | right | 22:45 |
| kees | aaah, so what I see in mvl-dove is basically the "next" rebase | 22:45 |
| kees | or, next next. | 22:45 |
| sconklin | so do a 'git checkout -b mybranch Ubuntu-2.6.32-217.34' | 22:45 |
| apw | kees, the tag has mvl-dove in it doesn't it? Ubuntu-mvl-dove-version | 22:45 |
| sconklin | or the last one | 22:45 |
| apw | but either way there is a tag and thats the way to get it | 22:45 |
| sconklin | apw: no, people have been very inconsistent in their tagging | 22:45 |
| apw | sconklin, yep and we are going to talk about htat at Rally, and i suggest fix them too | 22:46 |
| sconklin | apw: ack +1 | 22:46 |
| sconklin | sconklin@xps-1:/src/ubuntu/ubuntu-lucid$ git tag | grep mvl | 22:46 |
| kees | okay, so I guess what tripped me up is that I can't navigate those tags via the gitweb interface. | 22:46 |
| sconklin | Ubuntu-mvl-dove-2.6.32-416.33 | 22:46 |
| sconklin | Ubuntu-mvl-dove-2.6.32-417.34 | 22:46 |
| sconklin | sconklin@xps-1:/src/ubuntu/ubuntu-lucid$ | 22:46 |
| sconklin | never tried that. | 22:47 |
| apw | kees, ok, so of course you could checkout the bzr branches the importer is importing | 22:47 |
| kees | apw: right, I'll do that. the rebase confused me since I saw no tags after I looked into the branch. | 22:47 |
| kees | I feel saner now! :) thanks guys :) | 22:47 |
| apw | heh ... kees lets get together at rally and make sure you can find what you want | 22:47 |
| sconklin | kees: np, it does take a bit of head-wrapping | 22:47 |
| sconklin | generally, if in doubt you can take the version from the package without decoration, i.e. '2.6.32-416.33' and grep for that in the tags | 22:48 |
| kees | apw: well, see, that's the problem, I don't know what I don't know. I keep hitting these weird situations while going about what I thought was a standard process. heh | 22:48 |
| kees | sconklin: yeah, that's my way forward | 22:48 |
| sconklin | when we standardize our tags it will be easier | 22:49 |
| apw | kees, yeah thats how the cve tracker updater does it too | 22:49 |
| apw | sconklin, ^^ | 22:49 |
| * kees nods | 22:50 | |
| sconklin | all this reminded me that we should schedule some testing of running all the stable tools across a 3.0 kernel so we don't spend the week after release picking up pieces | 22:50 |
| apw | sconklin, oh you will :) | 22:50 |
| apw | sconklin, perhaps i should upload one into ckt for giggles | 22:50 |
| sconklin | apw: I know we will. I wrote some of the regex's we use . . . ;( | 22:50 |
| sconklin | apw: don't do it when I have easy access to you. | 22:51 |
| sconklin | meaning within a 12 hour flight | 22:51 |
| apw | sconklin, :) | 22:51 |
| sconklin | Although it will be easy enough to grab the development branch and try to prep a package | 22:52 |
| sconklin | it's going to explode hard | 22:52 |
| * apw wanders off again | 22:53 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!