=== vanhoof_ is now known as vanhoof
=== MTecknology is now known as billmeye
=== billmeye is now known as MTecknolgoy
=== MTecknolgoy is now known as MTecknology
=== sconklin-gone is now known as sconklin
=== sconklin is now known as sconklin-gone
=== MTecknology is now known as pfSensory
=== pfSensory is now known as MTecknology
=== lag` is now known as lag
fairuzhow to use dma functions to flush caches?07:39
fairuzsimple question, we use > to write the output to a file08:23
fairuzhow to append the output to the existing content of the file08:23
apwfairuz, >>08:24
fairuzapw: ok ty08:28
=== smb` is now known as smb
_rubenweird .. the link local address "oddity" with sit tunnels i see also on an old SLES9 box (2.6.5 based kernel) .. yet my sixxs interface (created by aiccu) doesn't seem affected somehow .. bah08:42
fairuzi use flush_cache_all() in kernel space to flush L1 cache, do similar function exist in user space?08:51
smbapw, In a quiet minute, maybe you have a pointer for that booty thing you mentioned08:57
apwcommit 299c56966a72b9109d47c71a6db52097098703dd09:04
apwAuthor: Don Zickus <dzickus@redhat.com>09:04
apwDate:   Mon Feb 7 23:25:00 2011 -050009:04
apw    x86: Use u32 instead of long to set reset vector back to 009:04
apwsmb ^^09:04
smbapw, ta09:04
smbapw, Looks like one of those things you hope other people know what they are doing. When setting its done high, then low. And when resetting its just writing 32bit, which would be low, then high...09:14
apwi think that in thory we can spin on it not being 0 or something, so there is magic going on09:16
smbIt is probably so old magic, that it might be documented in my ancient tome of pc internals... :)09:16
apwheh yeah.  i think on reset they jump to a routine which is doing:09:17
apwwhile (!reset_vector);09:17
nuschI asked yesterday about searching for regresions in kernel, I'm working with bug https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/66200909:45
nuschI tested it and last working kernel-ppa version is and in 2.6.35-rc2-maverick which is next sound it's already broken. What next, should I compile kernel from git?09:45
ubot2Launchpad bug 662009 in alsa-driver "[Lenovo Y530 - Realtek ALC888] Regression from 10.04: No sound with snd_hda_intel model=lenovo-sky" [Undecided,Triaged]09:45
nuschI asked yesterday about searching for regresions in kernel, I'm working with bug https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/66200909:45
nuschI tested it and last working kernel-ppa version is and in 2.6.35-rc2-maverick which is next sound it's already broken. What next, should I compile kernel from git?09:45
nuschI asked yesterday about searching for regresions in kernel, I'm working with bug https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/66200909:45
nuschI tested it and last working kernel-ppa version is and in 2.6.35-rc2-maverick which is next sound it's already broken. What next, should I compile kernel from git?09:45
nuschI asked yesterday about searching for regresions in kernel, I'm working with bug https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/66200909:50
nuschI tested it and last working kernel-ppa version is and in 2.6.35-rc2-maverick which is next sound it's already broken. What next, should I compile kernel from git?09:50
ubot2Launchpad bug 662009 in alsa-driver "[Lenovo Y530 - Realtek ALC888] Regression from 10.04: No sound with snd_hda_intel model=lenovo-sky" [Undecided,Triaged]09:50
apwnusch, yes we saw that the previous 3 times you said it too!09:51
apwas you have now a small range v2.6.34..v3.6.35-rc2 on mainline it seems appropriate to do a bisect between them09:51
nuschapw: sopry my irc client is bugged id didn't show send message after presing enter09:52
nuschand is there a way to not compiling it such long? I left compilation of Ubuntu-2.6.35-1.1 for night, and after few hours it stopped due to no space left on hdd.09:57
nuschI'm compiling with this line DEB_BUILD_OPTIONS=parallel=2 AUTOBUILD=1 NOEXTRAS=1 skipabi=true fakeroot debian/rules binary-generic am I compiling more than my amd64 architecture or this is normal?09:57
nuschAlso is there a method to shorten compile time while switching betwwen git tags - to not compile again modules which didn't changed ? Are there such modules ?09:57
apwnusch, what are you trying to compile on09:57
apwi have some faster kit i could do a build on for you09:57
apwand what release are you running09:58
apwnusch, ok so v2.6.34 is good and v2.6.35-rc2 s bad ... correcet ?09:59
nuschor maybe I should also test compiled vanilia kernels to test if the bug was introduced by ubuntu o r kernel maintainers?10:00
apwyou tested the ones in the mainline archive i pointed you to right ?10:02
nuschand this http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-rc2-maverick/CHANGES says only 2 people were involwed in snd_hda_intel 10:02
apwnusch, ok so you did test virgin upstream builds, those have no ubuntu ness applied to them10:02
apwnusch, are you 32 or 64 bit ?10:03
nuschso if the bug was introduced by ubuntu devs it should be quite easy to locate10:03
nuschI tested ones from  http://kernel.ubuntu.com/~kernel-ppa/mainline10:03
apwright ... those _are_ mainline virgin builds without any ubuntu sauce10:03
apwthat is the point of them, they don't have anything we do applied so we can tell if its our fault10:04
apw32 or 64 bit builds ?10:04
nuschso why they have maverick in the name ?10:04
apwbecause that tells me which configuration was used, which release they are most likely to work on10:04
* apw notes that this is described in the faq10:04
nuschok, so I used thos virgin build from there for 64bit and only tagged as maverick10:05
apwthats fine, we can do this using bisect from here10:05
nuschshould I continue Ubuntu-2.6.35-1.1 build or wait for your script ?10:07
apwnusch, normally it takes about half an hour a build here, so i shouuld have something to test in that kind of time10:08
apwnusch, this is a sound issue right?10:09
nuschahould I also do something with alsa?10:09
apwi think a bisect is our best hope, it says 207 revisions to test, 8 steps so it shouldn't take forever to get through10:10
nuschso simpy I should compile every time tag good/bad with bisect and compile again until I find revisions ? And shouldn't I compile alsa also every time ? Doesn't alsa need to fit currently running kernel ?10:12
apwnusch, alsa is part of the kernel10:12
apwand nusch i was volunterring to use my fast build box to make the kernels for you10:12
nuschI'd be grateful10:13
nuschand what's  about userspace as alsamixer, I had issue that after installing new kernel all channels in sound card were muted so I need restore it once10:14
apwnusch, yep it often does that, you'll need to check the basics like that every time10:15
nuschSo i need to compile alsa-tools also ?10:16
apwno you should need to do nothing other than check the mixers are not muted when testing the kernels i provide10:16
apwnusch, ok first test kernel at: http://people.canonical.com/~apw/bisect-maverick/10:46
nuschok, I don't have any irc bnc so I'll be back after testing10:47
nusch\query apw the one you provided is ok, waiting for next11:01
apwnusch, ack11:01
apwnusch, ok second set there ( the later numbered ones in the same place)11:23
nuschapw, this one was bad11:44
apwnusch, ack11:45
apwcking, smb how does this look: http://people.canonical.com/~apw/misc/key.html11:47
ckinggreat. Should "critical" be red and "high" be orange?11:49
apwcking, oh the colours are someone elses fault :)11:55
apwbut possibly, i got distracted before i pointed out the change11:55
apwwhich is to include all tasks of a bug, but sqashed on status where they match, se 600453 as an example11:56
* cking looks11:56
=== zul__ is now known as zul
apwnusch, next one is up12:15
nuschapw, thx I'll check12:16
nuschapw, this one is broeken in early boot, last message it says is usb 2-5: new high speed USB..12:30
nuschno errors or, warning, i unplugged all usb but know my laptop camera also uses USB bus12:31
nuschafter presing ctrl alt del  i get md: stopping all md devices and blinking curor - at this stage even SysRq doesn't work12:31
nuschapw, I must left for a while, if it won't be a problem please prepare more than one most probable build, I'll test all and provide you with results12:35
apwnusch, thats annoying as we don't know whether it is good or bad to tell bisect12:36
apwnusch, two new builds in the bucket ... please test both and report back13:17
=== shadeslayer_ is now known as shadeslayer
=== herton_ is now known as herton
fairuzthe function flush_cache_all() flushes all cache or only L1 cache?14:00
fairuzit's from asm/cacheflush.h14:01
=== sconklin-gone is now known as sconklin
nuschapw, first of these also not booting to the end, testing second14:54
apwnusch, bah thats most unhelpful as it provides no information14:54
nuschbut did you changed anything, i tested some times ago one of the most recent kernels in mainline build and it booted to the end (without sound)14:55
nuschI'll try second one, be back in a moment14:56
apwnusch, those two are as if the former one was bad and good respectivly14:57
apwas the original did not boot far enough for us to know14:58
nuschapw, second one did boot15:01
nuschbut no sound15:01
apwcrap that is worst outcome as we have no idea where the good has gone15:02
nuschi mean bisect201103011259 booting, no sound, bisect201103011238 not booting can't check15:02
apwyep, indeed the worst possible combination of results15:03
bjf## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting15:34
bjf##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting15:34
=== zul__ is now known as zul
apwnusch, ok we are likely wasting our time here, with such a big hole in the bisect, but here is another one to test15:59
apwnusch, let me know if it works or not16:00
JFoapw, we aren't done with alpha 3 yet are we, just in the freeze bit?16:03
* JFo brain isn't cooperating today16:03
* JFo digs for the schedule16:03
apwyeah we are frozded for it16:03
apwas of today, releasing thursday16:03
JFok, thought so16:04
JFothank you sir :)16:04
=== herton is now known as herton_lunch
apwbjf,  i have some further updates for lpltk for your consideration: lp:~apw/arsenal/python-launchpadlib-toolkit-milestones-etal16:15
apwbjf, been playing with the task oriented view of our tasks, ending up with a hybrid which collapses common status: http://people.canonical.com/~apw/misc/key.html16:18
apwbjf, note 600453 has two nominations, what do you think16:18
apwmanjo, about?  did you get a chance to test the natty pre-proposed kernel; to confirm it fixes your s/r issues16:32
bjfapw, looking it over, looks pretty good, personally, the "Summary of bugs" at the top just wastes space and I don't care about "Closed bugs" but they are at the bottom and I can ignore them16:36
apwbjf, not really sure myself what we use that for, i've not touched that bit yet16:37
apwbjf, does the multiple nominations bit make sense 16:37
bjfapw, i like the "Pending" pulled out16:37
bjfapw, yes, i think it makes sense16:37
bjfapw, if you needed the room, for nominations you could use a single capital letter16:38
apwi was thinking the milestones and noms might merge into one16:38
apwas they are logically pairs, Lucid:lucid-updates, stylee16:39
bjfcan you have mileston: lucid-updates without being nominated: Lucid ?16:41
bjf## Kernel team meeting in 20 minutes16:41
apwbjf, sort of, if the linux (Ubuntu) task is given a milestone16:41
=== herton_lunch is now known as herton
apwthough i actually think that that is stupid and any linux (ubuntu) task which is not actually nominated should be converted to Natty16:41
apwas really thats what i means16:41
apwwe already have to elide those when they are nom'd to natty, else you get duplicates16:42
bjfapw, now what i want is for us to come up with a "kernel heat" index that we add to each bug based on criteria that matter to us16:44
apwbjf, any idea what the criteria would be 16:44
bjfapw, there are a few "Incomplete" up in the "Active" section16:45
apwyes, those are correct, they are Incomplete (with response) ie ... active16:46
bjfapw, so not really incomplete16:46
apwwe haven't got the auto flipper working yet, thats on my list to sort16:46
apwright, they need flipping into another state, but lp doesn't do that by default16:47
apwi have a prototype that knows how to do it, just not had time to verify its not going to spack up all our bugs16:47
apwbefore letting it loose16:47
bjfso anything "incomplete" but "active" needs some manual love16:47
bjffor right now16:47
apwyeah, its on jfo's list of 'daily' tasks to flip them back16:48
apwthe key is its hard to flip them to the right place16:48
apwyou have to look at the activity log for hte bug to know where they have come from, then use some magic to convert that to an appropriate place16:48
JFothat and I haven't even touched the list yet this week16:49
apwthe prototype also handle the New bugs, for when people flip an Incomplete back to New (as thats the only place they can) it can then flip them back to trigaed or whatever they should be16:49
JFoheaded for some lunch17:14
skaet_apw, kernel version for A3 is 2.6.38-rc__ ?17:25
* skaet_ started into the TechOverview docs now...17:25
apwskaet_, -rc617:33
skaet_thanks apw,  adding now.   Can you give me a nice summary paragraph of the changes for this release to add to the Tech Overview?17:35
apwskaet_, will do17:35
=== bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - March-08 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
=== sforshee is now known as sforshee-lunch
apwsconklin, http://people.canonical.com/~apw/lp658307-natty/18:05
JFobrb, gonna step over and hit the big red update button on my Natty netbook18:25
keesbjf: tgardner is gone at the moment, can you maybe check a CVE in his absence? nelhage noticed an issue18:48
nelhagebjf: I noticed that http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2653.html claims the CVE only affects ppc, because of CONFIG_HVC_CONSOLE18:49
ubot2nelhage: Race condition in the hvc_close function in drivers/char/hvc_console.c in the Linux kernel before 2.6.34 allows local users to cause a denial of service or possibly have unspecified other impact by closing a Hypervisor Virtual Console device, related to the hvc_open and hvc_remove functions. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2653)18:49
nelhageBut the affected file is hvc_console.c, and looking at the Makefile: obj-$(CONFIG_HVC_DRIVER)+= hvc_console.o18:50
nelhageAnd CONFIG_HVC_DRIVER is enabled x8618:50
nelhageer, on x8618:50
nelhageI'm guessing someone just checked the wrong config option (the naming is certainly confusing), but maybe there's some reason HVC_CONSOLE matters anyways?18:51
bjfkees, nelhage will look into it18:56
keesbjf: cool; thanks18:56
smbbjf, Sounds sensible to me. I remember that ppc had a console driver named hvc and xen also has one of the same name. So I guess for that cve both drivers were confused and it affects x8618:59
smbkees, It looks like it should probably be re-activated (the cve tracker file), so we will look at it again19:00
=== sforshee-lunch is now known as sforshee
nuschapw, for last kernel you provided I've got panic at early boot stage, swapper tainted - not syncing attempted to kill init and ~ following backtrace http://pastebin.com/JJi289qf (written from screen)19:12
keesbjf: btw, for uct, it's just "released", not "fix-released"19:15
bjfkees, sorry, got mixed up hopping between lp and the cve tracker files19:15
keesbjf: but, I'm curious, since you have it as "released" but without a version.19:15
keesbjf: where was it fixed?19:16
bjfkees, let me look ...19:16
keesbjf: do you mean "not-affected"?19:16
bjfkees, if it was already fixed as part of a upstream stable release, is that "not-affected" or "released"19:17
keesbjf: if it's part of upstream stable release, it must still be included in -security and announced in a USN.19:17
keesbjf: i.e. it must show up in the changelog19:18
keesbjf: it should be marked "pending" so that we flip it to "released" on USN19:18
keesbjf: if it's already in an earlier release, then the first version that fixed it should be listed.  released (2.6....-abi.m)   19:18
keesand if a package started its life with it fixed, it would be not-affected19:20
bjfkees, fixed up the active status file and pushed the changes19:30
keesbjf: cool; thanks. pulling now19:30
keesbjf: I'm about to publish USNs for lucid and maverick. have all the CVEs fixed in those two been called out in the changelog?19:30
bjfkees, as far as i know19:31
bjfkees, i didn't go through every commit and verify19:31
keesbjf: well, I mean, last time there were CVEs fixed in the stuff that came from stable, and people yelled at me for leaving CVEs out of the USN.19:31
keesbjf: did all the open CVEs get compared to the stable patches? sounds like no?19:32
bjfkees, we just apply the stable commits as is, if they don't have the proper "CVE-xxxx-yyyy" line in the commit then they don't make it into the changelog19:32
bjfkees, we have no control over upstream19:33
keesbjf: right, but we need to have the CVEs actually reported as fixed. that's part of the triage. (this was in my email after the last maverick USN)19:33
bjfkees, that means that i'd have to go through all the outstanding CVEs and see if they were fixed in a stable upstream release that we are applying and we don't do that19:34
bjfkees, we only look at the CVE as we work them19:34
keesbjf: right, this was the process change I requested last time.19:35
jdstrandbjf: you don't have control over upstream's changes, but you do over your changelog. if you have already verified that upstream has fixed it, then you need to update the changelog, otherwise no one (not us, not other kernel team members, not ksplice, not users, no anyone) knows what was fixed19:36
jdstrandI thought this was already worked out?19:40
bjfjdstrand, not to my knowledge19:40
jdstrandwell, it is pretty clear from an accounting perspective that we need to correlate fixes coming in with CVEs even if upstream isn't doing it19:40
jjohansenjdstrand: you just look in the git tree ;P19:40
bjfjdstrand, if a CVE was fixed in some previous release and we just now find out about it as we work the cve from our end, you want us to update the changelog ?19:40
bjfjdstrand, we update the cve tracker status, that is the accounting we are correlating19:40
jdstrandbjf: if it is the same release, yes19:40
jdstrandbjf: that works for part of the accounting, but not the part that users see19:40
bjfjdstrand, that's not the issue19:40
jdstrandif something was vuln in lucid, but not maverick, then maverick's kernel doesn't need it19:40
bjfjdstrand, however it could be, we don't look at all the outstanding CVEs when we apply a stable release19:40
keesthere are two cases. I outlined them both in my email: stuff that is so late to get a CVE it was in a prior release, and CVE fixed in stable patch series for current release19:40
keeswhere "release" means publication of an update19:40
keesthe former case requires manually editing the USN database. the latter requires manually editing the kernel changelog.19:40
keesboth require code inspection during tirage19:40
bjfkees, if i get a set of stable patches today, i apply them. I do not go through the list of outstanding cves and see which of them got fixed in that batch of upstream stable commits19:41
=== zul_ is now known as zul
jdstrandbjf: sure, but when you are looking at CVEs, you are presumably verifying if maverick is affected19:41
jdstrandbjf: and you do that by looking at the commits19:41
keesbjf: right; that's the process I asked to be fixed. the merging of security and stable requires it, else we're not accurately reporting what CVEs have been fixed.19:42
jdstrandbjf: when you see maverick has the commit, you update the changelog19:42
bjfjdstrand, correct and i update the cve tracking bits, i do not rework the commit of a stable upstream commit to add the CVE verbage19:42
bjfjdstrand, nope, we don't do that19:42
bjfjdstrand, our changelog is updated via script that culls the commits between versions19:43
jdstrandbjf: you need to be adjusting the debian/changlog in some manner to indicate that it has CVE-20XX-NNNN19:43
bjfjdstrand, we are not doing that and i am not committing to doing that19:43
jdstrandbjf: whether that is part of the automated commit message you guys do, or somewhere up above or below the automated ones, it doesn't matter19:43
jdstrandbjf: how are user's supposed to know if their kernel is fixed?19:44
jdstrandbjf: how are USNs supposed to be written?19:44
jdstrandI suppose the USNs could be written based on the status of the CVE in the tracker, but users don't know19:44
jdstrandbjf: I don't understand why a stanza can't be added to the debian/changelog when you have all the info19:45
jdstrand* CVE fixes as part of stable tree merge:19:45
jdstrand  - CVE-2011-NNN119:46
bjfjdstrand, if a cve was fixed as part of a stable upstream commit pulled into one of our releases, two updates ago users didn't know that the cve got fixed19:46
jdstrand  - CVE-2011-NNN219:46
bjfjdstrand, because we didn't go through the entire list of outstanding cves looking for them19:46
jdstrandbjf: when you pull the commits, there needs to be review of what is fixed19:46
bjfjdstrand, no19:46
keestwo updates ago is a separate issue that we can fix separately by pulling from UCT and stuffing it into the USN db.19:46
jdstrandbjf: if it went into upstream stable, there is already a CVE in the CVE database19:46
jdstrandthat CVE in the database already has a commit19:47
jdstrandbjf: no as in 'no, you are not doing it'?19:47
bjfkees, the issue is no different in my mind whether it was a commit two releases ago or this one now19:47
keesjdstrand: no, UCT will have upstream not stable commit id19:47
bjfjdstrand, no we are not reviewing all the patches from stable upstream releases19:48
keesbjf: the difference is that if the CVE is known to the world now, and it has been fixed now, it must be announced as fixed now.19:48
keesbjf: if it was fixed in the past, and the CVE identified now, then we can only update the historical USN19:48
bjfkees, it was fixed in the past, known in the past but we (the kernel team) had not gotten to it yet19:48
jdstrandbjf: I am not asking for review of every commit. I am saying look at the open CVEs which have commit ids. correlate those to what was just pulled in19:48
bjfkees, therefor we don't know that it was fixed in a stable release19:49
bjfjdstrand, you are asking us to review every cve that we have not already applied against every stable upstream release19:49
jdstrandbjf: yes? that is how one determines if that release is affected by a CVE19:50
jdstrandand that is something you need to know anyway, for what to fix19:50
keesbjf: correct. "had not gotten to it yet" is the problem. in the past, CVE triage always happened before stable updates, so all CVE fixes were already identified prior to do the stable patch series.19:50
* jdstrand feels like he is missing something19:50
jdstrandbjf: I realize that during the 'catch-up phase' there needs to be some understanding that there will be accounting issues. I get that. However, the only way I see to make sure that things don't go awry is if triage happens before stable release commits. if that happens, then it is easy to add the non-automated changelog stanza I mentioned19:54
bjfkees, i don't know how CVE triage was done in the past, i know that i do it by trying to apply the patch and if it fails, looking at why19:54
smbkees, bjf I would say it never was guaranteed. Just because application of patches was slow with all the review and limited resources, it may have ended up that way19:55
sconklinstable release updates come in asynchronous to any work we do with CVEs and will arrive after some and before others19:56
jdstrandbjf: well, that works for isolated commits to prior releases. but it doesn't work for wholesale stable updates from upstream, because they are bug fixes *and* security fixes19:56
keesI'm just saying we have a responsibility to report what was actually fixed.19:56
jdstrandI mean, at some point, someone has to say-- "this doesn't affect maverick because it is already part of the stable release patches"19:57
smbkees, Would it not be possible to scan a cve file when moving it to inactive and check for the released status?19:58
sconklinwe do that. At the moment we triage a CVE and try to apply it to a kernel, we learn whetehr it has been previously applied19:58
bjfjdstrand, and i'm saying i find out it doesn't affect maverick because it is already part of a stable release patches because i just tried to apply it and i see that it already has been patched19:58
jdstrandsince users need to know if their kernels are vulnerable, not to mention comparisons of our kernels ot other distros and 3rd parties like ksplice, why can't the applying of the stable patches be done in accordance to CVE triage, if CVE triage is out of date19:58
sconklinThere is no mapping of stable upstream commits to CVEs19:59
jdstrandbjf: perhaps the answer is do do CVE traige immediately after applying the stable patches?19:59
sconklinThere is a mapping of CVEs to Linus's commits19:59
jdstrandthere has to be a correlation between Linus' commits and the upstream stable commits20:00
bjfjdstrand, if that was what we were doing, there would be no backlog of CVEs needing to be worked and all CVEs would be processed before we see stable updates20:00
jdstrandbjf: I'm sorry, I don't follow you20:01
bjfjdstrand, i think the disconnect is what you call "cve triage" and how we do "cve triage"20:02
jdstrandbjf: there is initial triage and 'for reals' triage20:03
jdstrandbjf: for a non-kernel update, our team gets the initial CVE, see it probably affects our releases, and gets a priority20:03
jdstrandbjf: someone is assigned to it and they dig down and see what releases it really affects20:04
jdstrandbjf: and then we fix, etc, etc20:04
jdstrandbjf: we do the intial, you guys do the 'for reals'20:04
bjfjdstrand, i only do "for reals" triage and I do it by applying a patch if the patch applies, i update a tracking bug, post the patch and the patch goes in20:04
jdstrandbjf: yes20:05
jdstrandbjf: why can't the changelog be a part of that?20:05
bjfjdstrand, when I "apply" a patch, i first take the upstream commit, and add the necessary text so that when it gets applied, and we run "insertchanges" it gets picked up20:06
bjfjdstrand, that will add it to the changelog20:06
sconklinour changelog is generated just before building our package, by a script that processes the git log. It isn't a manual incremental process20:07
jdstrandbjf: but you aren't adding the CVE reference. you said that20:07
bjfjdstrand, that's not what i said20:07
bjfjdstrand, i said i don't go back and add it for stable release commits20:07
jdstrandalright, when you do 'for reals' and send it up, you ignore whatever it doesn't apply to20:07
jdstrandI see that20:08
bjfjdstrand, oh and by the way, since we now get stable updates at different frequencies for different series, lucid may get a cve fixed before maverick20:08
jdstrandbut, this is a real problem. it isn't us just whining and asking for busy work20:08
jdstrandeg, ever since Ubuntu issued security updates, the changelogs include CVEs references. this dates back to before Ubuntu far back into Debian20:09
jdstrandpeople look at changelogs to decide if the update is worth upgrading for20:09
jdstrandmany people won't apply updates without CVE references in them20:09
jdstrandso people remain vulnerable because they don't know they need to upgrade20:09
sbeattie(or won't reboot into the new kernel without them)20:10
bjfjdstrand, and it still includes CVE references, we just don't guarantee that it's for all the CVEs that were fixed in a particular release (and we never did guarantee it)20:10
jdstrandthe USNs try to help with that, but we don't know what was fixed because the CVEs aren't in the changelog20:10
jdstrandbjf: I understand it will have some. I understand you are saying you never guaranteed that. I am saying that is a problem20:10
sconklinBut it was the case before that this happened20:10
jdstrandall other packages do this20:10
jdstrandbefore is neither here nor there20:11
jdstrandthe problem seems exacerbated lately, but if it was broke before and now, it still needs to be fixed now20:11
bjfjdstrand, it is "worse" now because of the two week cadence and that most releases now have at least one cve in them and you are looking closer20:12
jdstrandI'm not sure what the fix is, and I want to reiterate that the work being done is not lost on me. I very much appreciate it and have been quite public about prasing all the hard work you guys have been doing20:12
jdstrand(to management and others)20:12
jdstrand(and that includes your manager_20:13
jdstrandupstream stable commits are not going into -proposed without other SRU or CVE bugs are they?20:14
bjfjdstrand, yes, we take them wholesale20:14
sconklinwith or without, whenever they land we take them20:15
jdstrandso it is possible that a kernel will hit -proposed with no open CVEs or SRU bug fixes?20:15
bjfjdstrand, that is correct20:15
sconklintheoretically yes20:15
jdstrandso, after everything is caught up, there won't be such a backlog of CVEs20:16
sconklinand it's almost happened - we've had kernels with dozens of patches and only one open bug that needed verification20:16
jdstrandtherefore, it should not be hard to then apply the stable commits, then go through the open CVEs and try to apply the patch. this happens before the upload to -proposed. then you can add an non-automated 'CVE stanza' before uploading to -proposed20:17
jdstrandthis is not 'extra work' because this is work that you will be doing anyway20:18
bjfjdstrand, then there would be no backlog of cves right ?20:18
sconklinexcept that we'd have to go through ALL the unapplied CVEs20:18
jdstrandsconklin: I said 'after everything is caught up'20:18
sconklinwhen pigs fly20:18
jdstrandbjf: there isn't a 'backlog', but there might be open CVEs20:18
bjfjdstrand, i don't see a day when there won't be a backlog20:19
sconklinDespite the rapid rate at which we're working, I don't see the backlog getting a whole lot smaller20:19
jdstrandbjf: define backlog. I am talking about all the CVEs that didn't get fixes. it is my understanding that these are getting fixed and people are helping out20:20
bjfjdstrand, http://people.canonical.com/~apw/cve/pkg/linux.html20:20
jdstrandsconklin, bjf: you need to talk to your manager if you can't catch up. if you can't catch up, any hiccup means you can't keep up20:20
bjfjdstrand, everything on that page that says "needs-triage" is backlog20:20
jdstrandbjf: yes, I am familiar with that page20:20
jdstrandbjf: you have already gone through almost all the 2010 CVEs20:21
sconklinjdstrand: we're working on that as a separate issue ;)20:21
bjfjdstrand, you asked me to define backlog and i just did20:21
jdstrandthere is one outstanding 2011 CVE on that page20:21
jdstrandbjf: k20:21
jdstrandI have been very encouraged by how much you guys have been catching up20:21
jdstrandthat page looked much worse 10 days ago20:22
jdstrandwe are getting caught up on the wrong things20:22
bjfjdstrand, so, we are making progress, that has nothing to do with what started this discussion20:22
sconklinjdstrand: is it the case that for every CVE we care about that's in yoru CVE tracker, we know the upstream commit ID?20:22
jdstrandif part of the work is triaging a CVE by trying to apply it to a branch, then when you do that isn't 'extra work', it is 'rescheduled work'20:23
keesbjf: btw, given that the sru-report is empty for dapper hardy karmic, why are there "pending" on http://people.canonical.com/~apw/cve/pkg/linux.html ?20:23
keessconklin: not always, that assumes there is a fix20:23
bjfkees, no idea20:24
keessconklin: or assumes that the location of this fix was known during triage20:24
jdstrandtherefore, if you reshedule CVE triage to 'right after' you pull stable upstream commits, you can both adjust the changelog, accurately reflect the state of that kernel, etc, etc20:24
bjfkees, i'm assuming we are not merging with your updated active files20:25
jdstrandkees: isn't it now part of our process to push our updates to the kernel team?20:26
jdstrandkees: (our new CVEs)20:26
keesbjf, jdstrand: we pull the kernel team tree daily.20:26
keess/daily/at every CVE triage cycle, which is supposed to be daily/20:26
sconklinjdstrand: yes, but CVE triage has now been redefined to mean 'review every open CVE, determine the upstream commit identified with it, and see if we applied the same patch'20:26
sbeattiekees: right, but how often does the kernel team pull from our tree?20:27
keessbeattie: not sure20:27
jdstrandsconklin: ok. whatever you call it, can't you just do what I suggested for trees that pull upstream stable updates? it would completely solve the problem for those kernels, and wouldn't hurt the full triage done for the others. plus, you could conceivably add that commit id to the tracker as a pointer on where to look later, so it could make it easier down the road20:29
jdstrandI really don't see how that adjusted workflow would adversely affect you guys. that work has to be done regardles20:30
sconklinI'm questionin the premise that this must be done20:31
apwjdstrand, that is maybe true, but you are adding an ordering constraint which does not exist currently20:31
jdstrandsconklin: see backscroll for users trying to decide on updating. USN publication, 3rd parties like ksplice. accurate accounting. comparison with other distros20:31
jdstrandit is an important change20:32
jdstrandpeople are confused20:32
sconklinAnd I'm sorry, I'm not intending to avoid discussion, but I have four more kernel packages I have to get built today so I'm going to have to get to those20:32
apwhow do you do it for packages where you do not control uploads20:33
jdstrandapw: not to mention, it is the same people applying upstream stable commits as fixing CVEs: the kernel stable team20:33
apwwhen grub2 gets a 'sync'd with debian' how do you ensure it has USN numbers in it before it is uploaded20:33
bjfjdstrand, how about someone from security team doing a rotation onto the kernel team ?20:33
jdstrandapw: we don't sync from Debian for stable releases. we backport patches. we don't write USNs for the devel release. the devel release is ok to have only 'released' or 'not-affected' in the CVE20:34
apwwhat i don't see is how it differs from when a CVE is discovered after the fix was accidentally applide to natty20:34
apwor any release20:34
jdstrandbjf: I'm not sure where you are going with that20:34
apwthere the fix preceeds the USN, why can we not postumously indicate a previous release has a fix20:35
jdstrandapw: because people don't run the devel release in production?20:35
apwas we triag and find the fix, and mark it released (xxx)20:35
apwignore the word natty, it just came out20:35
bjfjdstrand, i'm suggesting that that to properly understand each others point of view and the work involved, perhaps someone should do a rotation onto the kernel team20:35
apwso if we apply .11 and the next week you tell us about a cve that was already released20:35
apwhow do we handle that, that must be a situation we have a process for20:36
keesapw: it's two situations, a CVE being identified months after a fix is published already and a fix being applied when the CVE is already known.20:36
jdstrandbjf: no trying to be daft, but we have worked very closely with the kernel team for years on this20:36
keesthe latter is what needs to be fixed, as it is causing a lot of confusion now since merging stable and security updates20:36
apwkees, well i'd say if its not been triaged, its not know yet20:36
keesapw: that might be true for you, but for people who watch public CVEs, this is not true.20:36
apwtill thats done we don't know if the random sha1's in the CVE report even are the right fix20:36
keesapw: it looks like Ubuntu is "silently fixed" CVEs20:37
jdstrandbjf: sometimes the patching, etc was more on us, and sometimes on the kernel team. there are too many kernels for us to maintain20:37
bjfjdstrand, ah, nevermind, thought we were in disagreement about something, guess i was wrong20:37
apwkees, right but that does happen, we sometimes do pull in a fix for a bug and push it20:37
apwwithout knowing it also fixes a cve20:37
apwit is bound to happen isn't it ?20:37
keesapw: we have a responsibility to announce what CVEs are fixed. that means we must always compare the shipped code against the known CVE fixes.20:38
jdstrandsure, occassionally, but now it is guaranteed to happen20:38
keesapw: having no CVE back log helps that greatly, of course.20:38
keesapw: in the past, all CVE work was finished before doing stable updates.20:38
keesapw: so this never happened20:39
apwkees, actually smb disagrees that that was guarenteed20:39
keesapw: well, it never had multiple people yelling as us for inaccurate USNs20:39
apwkees, then someone needs to make the decision that we don't ship updates till the triage backlog is comlplete20:39
apwbecause until the cve's are triaged and we know the SHA1's are accurate we have nothing to work with20:40
jdstrandapw: or we reorder the work, which seems not a hard thing to do?20:40
* jdstrand really doesn't understand the problem there20:40
pgranerjdstrand, reordering is not possible20:40
jdstrandpgraner: why?20:40
apwjdstrand, to do what you ask, which is to know all of a stable update is a CVE we need to know the information in20:40
keesapw: you have the code...20:40
apwit is accurate, which means it needs to be triaged.  this neceesarily moves CVE triage before all releases20:41
apwkees, no i have a report with text, and some possible sha1's20:41
jdstrandbjf stated that his triage consists of trying to apply a patch20:41
apwthat does not tell me those patches are cve patches till i read them20:41
jdstrandso, apply all of stable upstream commits. then try to apply the commits that we know about in the CVE tracker20:41
keesapw: right, you go through the CVE list, not the stable patch list20:41
apwso does that not mean i need to triage all cves before i can do that matching?20:41
keesapw: if the CVE fix appears in the stable patch list, mark it up, etc20:42
keesapw: yes.20:42
apwkees, right ... and right now we do not triage all CVEs before we apply any patches to the krenl20:42
keesapw: you need to identify all the CVEs that have fixed, and know what the fixes are.20:42
apwto move to that model is an ordering change20:42
keesapw: you have identified the problem. :)20:42
pgranerjdstrand, kees, to do that we can't keep up the schedule20:42
apwkees, i thought triage of cves came from the security team20:42
keespgraner: but schedule should be secondary to correctness20:42
apwbut ignoreing that, its a still an ordering change20:43
apwwe have never checked that a patch for a bug was a cve fix to my knowledge20:43
keesapw: no, you have the knowledge to be able to understand when/if CVEs apply to which trees20:43
jdstrandpgraner: but it isn't extra work, it is only reshuffling the work that is done. I am not proposing to do all triage for all previous releases immediately after apply upstream cstable20:43
apwand you are asking us to do that now20:43
jdstrandapw: you do do that every time you mark something 'released' or 'not-affected' in the tracker20:44
apwjdstrand, yes when i triage a cve i mark the tracker, but i do that when biting of a cve and fixing it20:44
apwi don't do all of the triage for all of them, then apply one20:45
* jjohansen -> lunch21:18
=== sconklin is now known as sconklin-gone
=== nusch_ is now known as nusch
anon^_^any issues persisting with latest kernel updates for 10.04 in update manager?23:52
anon^_^dummy files are showing up, but not the binaries23:53

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!