| === ogasawara_ is now known as ogasawara | ||
| === _LibertyZero is now known as LibertyZero | ||
| ppisati | morning | 07:29 |
|---|---|---|
| === ericm|ubuntu is now known as ericm-afk | ||
| * apw yawns at ppisati | 08:08 | |
| * smb finishes glancing over most past email | 08:51 | |
| apw | smb, heh that was quick | 08:53 |
| smb | apw, Yeah, not well done but quick | 08:54 |
| apw | ppisati, yeah can hear | 08:54 |
| ppisati | apw: ping | 09:35 |
| apw | ppisati, yo | 09:35 |
| apw | ppisati, lp:~canonical-kernel-team/ubuntu-cve-tracker/kernel-team/ | 09:39 |
| * apw steps out | 12:04 | |
| jwi | hm, was 2.6.38-10.44 copied to {lucid,maverick}-proposed by mistake? | 13:05 |
| apw | jwi i would say so | 13:07 |
| apw | jwi, thanks for the heads up, will investigate | 13:08 |
| apw | commit 7467571f4480b273007517b26297c07154c73924 upstream. | 14:13 |
| apw | ogasawara, yo ... you have added things to dublin adgenda, could you pm me a link? | 14:26 |
| ogasawara | apw: yep, lemme get it | 14:27 |
| apw | ogasawara, i think the janitor scripts could do with a slot if its not already there | 14:27 |
| apw | ogasawara, good its already on there | 14:28 |
| elmo | did lucid ever get anything newer than a maverick kernel as a backport? | 14:33 |
| tgardner | elmo, Natty should be there by now. I'd have to check if its in updates yet. apw? | 14:34 |
| apw | yeah i'd expect that to be in proposed by now | 14:35 |
| apw | hmmm | 14:35 |
| apw | hmmm not showing up, sconklin did say he was picking it up this round | 14:36 |
| === Quintasan_ is now known as Quintasan | ||
| apw | smb, subject: xhci: Fix full speed bInterval encoding. | 14:39 |
| apw | tgardner, elmo ok the natty branch was held up as it needs re-building for the USB 2.0 regression, i am going to sort that with steve | 14:40 |
| elmo | apw: cool, thanks | 14:41 |
| Protector1981 | why does not exist an x86 3.0 kernel? or must i self compile? | 14:48 |
| * ogasawara back in 20 | 14:52 | |
| jwi | sforshee: re bug 787590 - you sure about that? latest -proposed seems to be based on 2.6.38.7, but the nvidia-fixup landed in 2.6.38.8 | 14:53 |
| ubot2 | Launchpad bug 787590 in linux "USB power not turned off using nForce 590 SLI chipset" [Medium,Fix committed] https://launchpad.net/bugs/787590 | 14:53 |
| sforshee | jwi, you're right. I must have been on the wrong branch when looking at the changelog, I'll add a correction to the bug. | 14:56 |
| apw | ogasawara, hey 3.0-rc2 is in the house ... | 15:06 |
| ogasawara | apw: am already rebasing it :) | 15:06 |
| apw | why am i not supprised, hopefully it'll fix my hp mini | 15:07 |
| ogasawara | apw: yah, was gonna test it on there first thing | 15:07 |
| apw | ogasawara, i'll get back to testing modprobe changes | 15:09 |
| ogasawara | apw: were you able to get the fix applied and uploaded? | 15:10 |
| ogasawara | apw: the m-i-t bits that is | 15:11 |
| apw | ogasawara, in the intermin debian released a new m-i-t with the fix, and the recommendation was to sync whith that, which is complete and looking good, but the actual binaries need testing in anger | 15:11 |
| apw | and i need to get someone to review the bzr branch to make sure i did the merge right so that future merges work right | 15:12 |
| apw | hope to get it in today | 15:12 |
| apw | ogasawara, actually if the -rc2 boots on the mini that would help my efforts a lot | 15:15 |
| smb | sconklin, Hm, could the create-tracker-script be affected by the lp api change you mentioned, too? It seemed at least quite unhappy when I called it... | 15:15 |
| apw | sconklin, i am wo | 15:16 |
| sconklin | possibly but I doubt it's the same problem. Can you pastebin the failure? | 15:16 |
| apw | wondering what changed there, thats a little worrying that we're being broken without apparent warning | 15:16 |
| smb | sconklin, http://pastebin.ubuntu.com/619966/ | 15:17 |
| sconklin | ok, there were actually two problems - firstly, people who fetched the lpltk during a certain window got a bad validation check that resulted in a validation failure. That was subsequently fixed, and grabbing a new lpltk fixes it | 15:18 |
| sconklin | The second is that launchpad used to return task names like this "kernel-sru-workflow hyphenated-task-name" | 15:19 |
| sconklin | and now it started using the display name like this: "Kernel SRU Workflow hyphenated-task-name" | 15:19 |
| sconklin | which broke my task name parsing | 15:19 |
| apw | oh thats so very helpful | 15:20 |
| sconklin | I was so pleased to discover that at 9PM on a Sunday. | 15:20 |
| sconklin | or maybe it was only 7PM. | 15:20 |
| sconklin | smb: that's the first problem. Fetch the newest python-launchpad-toolkit and reinstall | 15:21 |
| smb | Ok, so I had been pulling kteam-tools before trying that. Now I pulled the lpltk... | 15:21 |
| smb | looks better | 15:22 |
| sconklin | Apparently code changes to the lpltk are not accompanied by unit tests . . . | 15:22 |
| smb | at least it takes a looong time now... :) | 15:22 |
| apw | tgardner, ppisati just notived that the fix we have committed for CVE-2010-4076/4077 is actually the fix for CVE-2010-4075 ... looks like you did that one, can you remember at all | 15:42 |
| ubot2 | apw: The rs_ioctl function in drivers/char/amiserial.c in the Linux kernel 2.6.36.1 and earlier does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4076) | 15:42 |
| ubot2 | apw: The uart_get_count function in drivers/serial/serial_core.c in the Linux kernel before 2.6.37-rc1 does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4075) | 15:42 |
| tgardner | apw, hmm, looking... | 15:44 |
| apw | ppisati, as the right fix for 4076/77 was applied via stable for natty and oneiric i think the right thing to do is just flip that one back en-toto and re-run over it | 15:44 |
| apw | (which i can do once tgardner confirms our findings) | 15:45 |
| apw | tgardner, if so, i will flip the bits back in the tracker so it gets done by somone | 15:45 |
| sconklin | apw, ogasawara: you'll probably also want to make sure that the patch mentioned in my email is in the development kernel asap | 15:46 |
| ogasawara | sconklin: which patch? /me checks email | 15:47 |
| sconklin | [PRESTABLE] [PATCH] xhci: Fix full speed bInterval encoding. | 15:47 |
| sconklin | https://patchwork.kernel.org/patch/837082/ | 15:47 |
| sconklin | ogasawara: ^^ | 15:47 |
| ogasawara | sconklin: yep, we got it when we rebased to 3.0-rc1 (not yet uploaded though) | 15:49 |
| sconklin | ok, cool | 15:49 |
| tgardner | apw, the commit referenced by http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4076 appears to be the commit that was applied for 'tty: Make tiocgicount a handler, CVE-2010-4076, CVE-2010-4077'. Looks like the same commit _also_ fixes CVE-2010-4075. | 15:50 |
| ubot2 | tgardner: The rs_ioctl function in drivers/char/amiserial.c in the Linux kernel 2.6.36.1 and earlier does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4076) | 15:50 |
| ubot2 | tgardner: The rs_ioctl function in drivers/char/amiserial.c in the Linux kernel 2.6.36.1 and earlier does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4076) | 15:50 |
| ubot2 | tgardner: The ntty_ioctl_tiocgicount function in drivers/char/nozomi.c in the Linux kernel 2.6.36.1 and earlier does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4077) | 15:50 |
| ubot2 | tgardner: The uart_get_count function in drivers/serial/serial_core.c in the Linux kernel before 2.6.37-rc1 does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4075) | 15:50 |
| apw | tgardner, ok thats not what the cve tracker says | 15:50 |
| apw | active/CVE-2010-4075: upstream: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d281da7ff6f70efca0553c288bb883e8605b3862 | 15:51 |
| apw | active/CVE-2010-4076: upstream: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0587102cf9f427c185bfdeb2cef41e13ee0264b1 | 15:51 |
| apw | active/CVE-2010-4077: upstream: http://git.kernel.org/linus/0587102cf9f427c185bfdeb2cef41e13ee0264b1 | 15:51 |
| ubot2 | apw: The uart_get_count function in drivers/serial/serial_core.c in the Linux kernel before 2.6.37-rc1 does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4075) | 15:51 |
| ubot2 | apw: The rs_ioctl function in drivers/char/amiserial.c in the Linux kernel 2.6.36.1 and earlier does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4076) | 15:51 |
| ubot2 | apw: The ntty_ioctl_tiocgicount function in drivers/char/nozomi.c in the Linux kernel 2.6.36.1 and earlier does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4077) | 15:51 |
| * apw slaps ubot2 | 15:51 | |
| tgardner | apw, both cve.mitre.org reports reference the same commit | 15:51 |
| apw | ok so one or other is wrong ... will try and figure out which | 15:51 |
| apw | tgardner, only 75 has CONFIRM: next to it tho, the others are MISC: | 15:53 |
| apw | tgardner, but what you are syaing is that fix is the _one_ fix for 75 76 and 77, and the error is that 75 is not mentioned | 15:53 |
| tgardner | apw, I think thats the case. | 15:54 |
| ppisati | ok, so the fix in master actualy fixes all thrre | 15:54 |
| ppisati | three | 15:54 |
| tgardner | if indeed d281da7ff6f70efca0553c288bb883e8605b3862 _does_ fix 75 | 15:54 |
| tgardner | or rather, if indeed it _does_ fix 76/77 (which are _not_ maked CONFIRM) | 15:55 |
| * ppisati -> linaro conf call | 15:58 | |
| ogasawara | apw: no joy for me on the hp-mini | 16:02 |
| apw | ogasawara, dammit thats annoying, we'll prolly have to actually debug that one if its broke in -rc2 | 16:03 |
| apw | in my brief testing it was loading i915 which bust it | 16:03 |
| apw | (in -rc1) | 16:03 |
| * ogasawara will try to dig in further | 16:03 | |
| ppisati | apw tgardner: so what was the outcome? i apply the fix in master and be done with all 3 (75/76/77)? | 16:05 |
| apw | ppisati, give me another 5 mins, i am just confirming it does fix all three really | 16:06 |
| apw | then i can fix the tracker too | 16:06 |
| ppisati | apw: no rush, i'm in a conf call now | 16:06 |
| apw | tgardner, ok confirmed we need both commits for 76 and 77 to be fixed, i'll update the tracker to that effect | 16:17 |
| tgardner | apw, ack | 16:18 |
| sconklin | apw, you wrote the update-from-natty-master script? | 16:21 |
| apw | sconklin, tim mostly, but i know it well, wassup | 16:23 |
| apw | sconklin, in theory you just use that and it finds the latest tag on <series>/master and uses that | 16:24 |
| apw | as a base for the rebase | 16:24 |
| apw | once run you do need to commit the result | 16:24 |
| sconklin | apw: I may just look myself if I have time - it copied the changelog (as it should) but it leaves in the release tracker bug. If that were not removed manually it could cause some very confusing things to happen on our status pages | 16:25 |
| apw | sconklin, ahh ok, then that probabally should be fixed | 16:25 |
| sconklin | it's working fine, this is more a feature request | 16:25 |
| apw | how to detect the one to remove i wonder | 16:25 |
| sconklin | well, you can safely remove them all I think. And the text near it is generated by a script so is consistent | 16:26 |
| apw | sconklin, that sounds doable | 16:27 |
| apw | ppisati, so that fix actually only fixed 4075, so when you copy it over mark it so | 16:30 |
| ppisati | apw: k | 16:32 |
| herton | I had one problem with update-from-*-master scripts too, its match usage was breaking mawk (which came by default in my natty install) | 16:34 |
| herton | if (match($0, /UBUNTU: (Ubuntu-2\.6\.[0-9][0-9]*-([0-9][0-9]*)[^ ]*)/, a)) { | 16:35 |
| herton | mawk doesn't have the third parameter, 'a' | 16:35 |
| apw | mawk! wtf | 16:35 |
| * apw notes that'll all break hideously with 3.0 as welll sigh | 16:35 | |
| herton | it was default on natty, had to install gawk manually :) | 16:36 |
| apw | herton, did you work out a sensible non ,a form we could use which works with mawk or did you install gawk | 16:36 |
| apw | heh :) | 16:36 |
| herton | just installed gawk, don't know what could be done about mawk | 16:36 |
| herton | apw: ", a" isn't being used, so could be removed | 16:40 |
| apw | herton, ahh ok, will look at that when i am fixing the 2.6 issue | 16:41 |
| ppisati | but why did they switch awk interpreter? | 16:44 |
| herton | dunno, probably it's faster, and to break scripts :) | 16:48 |
| smb | coolness... :.P | 16:48 |
| smb | and its smaller... | 16:48 |
| ppisati | actually i just found out that it's there since end of 2007 | 16:49 |
| ppisati | at least | 16:49 |
| ppisati | http://ubuntuforums.org/showthread.php?t=619985 | 16:49 |
| apw | pgraner, btw, that "30% power" issue may be found and a patch in stable | 17:10 |
| pgraner | apw, oh nice, what was it? | 17:10 |
| apw | rounding error in a time calculation leading to miss calculation on whether its worth slipping into lower c states | 17:11 |
| pgraner | apw, cool | 17:13 |
| === ikonia_ is now known as ikonia | ||
| apw | ogasawara, have a serious performance issue on kernel install with the new m-i-t, still working on them | 17:26 |
| ogasawara | apw: ack | 17:26 |
| apw | and the -rc1 kernel doesn't work on either of my atoms, 32 and 64 bit respectivly | 17:27 |
| ogasawara | apw: yuck | 17:27 |
| apw | ogasawara, which is making mit testing very hard too | 17:28 |
| apw | ogasawara, given all the problems i am likely going to just bodge the current mit and upload that | 17:28 |
| apw | ogasawara, to unblock you and then i can fix mit at my leisure | 17:28 |
| apw | ogasawara, though if we can't boot this on any atom i am worried about uploading it, as they are common scrappers for testing | 17:29 |
| ogasawara | apw: yep, not sure if we really want to upload knowing it fails to boot on some common cases | 17:29 |
| ogasawara | apw: I can at least work around the hp-mini booting with i915.modeset=1 | 17:30 |
| apw | ogasawara, i managed to get it half working by booting init=/bin/bash, then it dies when modprobe i915 | 17:30 |
| apw | with =1 ? | 17:30 |
| ogasawara | err =0 | 17:30 |
| apw | which disabled i915 doesn't it? | 17:31 |
| apw | ogasawara, but thats useful for testing here for mit | 17:31 |
| apw | ogasawara, are you going to attmept to debug the mini while i finish mit ? i presume i am not blocking you till then | 17:42 |
| ogasawara | apw: yep gonna keep debugging, you're not blocking me | 17:44 |
| sconklin | smb: please let us know when the ec2 branch is finished, and whether it's test built and been test booted? Then we can package it | 17:44 |
| apw | ogasawara, ok will keep working this perf issue for the moement and get it uploaded my morning when i have reviewers | 17:44 |
| smb | sconklin, Well test booted not really yet (though I did that before the uhci addition) and its nearly compile done in the ckt ppa | 17:45 |
| smb | Just waiting for i386 currently | 17:45 |
| smb | sconklin, branch and meta branch pushed back already | 17:46 |
| kees | apw: for 720189, I thought the thing we agreed on was to make a new bug instead of reopening the old one? | 17:48 |
| apw | kees, hmmm good point, i'll un bork that | 17:49 |
| smb | sconklin, Ok, lucid-ec2 is prepared. Seems ec2-meta is waiting for some publishing step but should be there soon | 17:54 |
| sconklin | smb: ok, thanks | 17:55 |
| mpoirier | ogasawara: good morning | 18:00 |
| ogasawara | mpoirier: morning | 18:00 |
| apw | ogasawara, i can confirm you i915.modeset=0 'fix', which concurs with my feeling it was loading that which broke stuff | 18:00 |
| mpoirier | I took a look at the patches you identified | 18:00 |
| mpoirier | vdd_sdi, for omap processors. | 18:00 |
| mpoirier | ogasawara: those patches have been refused upstream. Arnd wanted an change to how the display subsystem was discovering the output, somehting I couldn't do. | 18:01 |
| mpoirier | ogasawara: I'm sure it was fixed by someone but I don't have the HW anymore. | 18:02 |
| ogasawara | mpoirier: do you know who has hw now? | 18:02 |
| mpoirier | ogasawara: no clue - mobile team most likely. | 18:02 |
| ogasawara | mpoirier: if it was indeed fixed, we could probably drop those patches, but would be good to test and confirm first. | 18:03 |
| mpoirier | ogasawara: ya, I'd like to test before giving the go ahead. | 18:03 |
| ogasawara | mpoirier: thanks, I'll make a note to carry them for now and drop only after testing | 18:03 |
| mpoirier | ogasawara: ok. on another front, | 18:04 |
| mpoirier | ogasawara: on https://wiki.ubuntu.com/KernelTeam/Specs/KernelOneiricUbuntuDeltaReview it is said that we carry 534 patches on top of mainline. | 18:05 |
| mpoirier | ogasawara: what is the suite of instruction you did to come up with that ? | 18:05 |
| ogasawara | mpoirier: we have a script we use, it's in kteam-tools, lemme find the exact name | 18:06 |
| mpoirier | cool. | 18:06 |
| ogasawara | mpoirier: kteam-tools/devel/reconcile-generic | 18:07 |
| mpoirier | ogasawara: ok, I'll take a look - thanks. | 18:07 |
| * tgardner --> lunch and server room | 18:36 | |
| * ppisati -> gym | 19:01 | |
| CarlFK | "Could you add "pciehp.pciehp_debug" to kernel parameter" add that to APPEND line, or stuff in some /etc conf file? | 19:07 |
| ohsix | theres /etc/default/grub, but people typically mean editing the command line from grub, then booting with it | 19:09 |
| CarlFK | ah right. thaks | 19:09 |
| ohsix | if you modify /etc/default/grub you'll want to run update-initramfs | 19:10 |
| CarlFK | Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.39-3-generic root=UUID=7a5a1e63- | 19:29 |
| CarlFK | 8e75-443f-b732-522709dd36d6 ro vt.handoff=7 pciehp.pciehp_debug | 19:29 |
| CarlFK | any idea why I don't see anything new in dmesg? | 19:29 |
| sconklin | sarahsharp: hi! | 19:29 |
| sarahsharp | sconklin: hello! | 19:29 |
| CarlFK | One of these did it: kernel ... pciehp=pciehp_debug -- pciehp.pciehp_debug | 19:34 |
| mpoirier | ogasawara: can you show me the cmd line you used when calling reconcile-generic ? | 19:37 |
| ogasawara | mpoirier: for example: reconcile-generic master v2.6.39 | 19:39 |
| mpoirier | master being the ubuntu code base ? | 19:40 |
| ogasawara | mpoirier: yes | 19:41 |
| kees | I sent two patches for the kteam-tools branch but they haven't gotten in; can those get pulled? | 19:45 |
| kees | sconklin: where can I find the scripts that are processing the workflow bugs? | 19:46 |
| tgardner | kees, I bugged him about getting them reviewd | 19:46 |
| bjf | kees, i added part of the patch and commented on it | 19:46 |
| kees | I just wanted to see how he was fetching the list of open bugs for a given series | 19:46 |
| sconklin | kees: one sec | 19:46 |
| bjf | kees, kteam-tools/stable/sru-workflow-manager | 19:47 |
| sconklin | I'm multitasking badly | 19:47 |
| bjf | sconklin, np, i got it | 19:47 |
| kees | bjf: ah, sorry, I didn't see the email reply. | 19:47 |
| sconklin | thx | 19:47 |
| kees | bjf: ah, I see, you rewrote the verbosity bits. the CVE speed up wasn't added, should I resend that part? | 19:49 |
| bjf | kees, you could reply to my email about the patch :-) | 19:49 |
| kees | bjf: i will :) | 19:50 |
| kees | apw: any thoughts on https://lists.ubuntu.com/archives/kernel-team/2011-May/015693.html ? | 19:56 |
| bjf | kees, my questions about that patch were: 1, why have we not run into any problems using linkCVE ? and 2, you are turning that into a manual step for all CVEs is that overkill? | 20:02 |
| kees | bjf: because you've only created bugs after the CVE appeared in mitre and was imported into LP already. if I'm going to be using this, it may include CVEs that are not yet in mitre | 20:03 |
| bjf | kees, what does it do if you try to use linkCVE and the CVE doesn't exist? | 20:03 |
| bjf | kees, does it throw an exception or does it fail silently? | 20:04 |
| kees | bjf: one sec (phone) | 20:04 |
| sforshee | tgardner, bjf: can one of you approve my nomination on bug #762987? | 20:08 |
| ubot2 | Launchpad bug 762987 in linux-firmware "RT2870 WLAN Stick (D-Link DWA 140) not working. firmware does not support detected chipset" [Undecided,Fix released] https://launchpad.net/bugs/762987 | 20:08 |
| bjf | sforshee, done | 20:08 |
| sforshee | bjf, thanks | 20:08 |
| kees | bjf: afair, it throws an exception | 20:15 |
| bjf | kees, then wouldn't it be better to handle that exception, using linkCVE when we can and only adding the "comment" when necessary? | 20:16 |
| kees | bjf: walking the CVE list takes forever, though. doing a comment will hook the back-end logic that actually creates the link, so it's the best way to go, imo | 20:17 |
| * jjohansen -> lunch | 20:18 | |
| bjf | kees, you've worn me down, and i'll apply the patch, though it sounds like the justification is "LP is slow so do it manually" | 20:19 |
| bjf | kees, and it would seem that rule would apply to most LP things | 20:20 |
| kees | bjf: the problems are LP: #322560 and LP: #439470 | 20:20 |
| kees | if 322560 was fixed, you could instantly look up a given CVE. instead, you're force to the the time-consuming walk | 20:21 |
| kees | if 439470 was fixed, you could just link immediately | 20:21 |
| kees | so, basically, we just skip both, and do a comment. it'll attach the CVE no matter what. | 20:21 |
| bjf | kees, it's a script, i don't care how long it takes to walk it | 20:21 |
| kees | bjf: heh. well, since I'll be using it, I'd like it to be fast since I'll be manually adding CVEs while doing CVE triage | 20:22 |
| bjf | kees, applied and pushed | 20:24 |
| kees | bjf: cool, thanks! | 20:24 |
| === yofel_ is now known as yofel | ||
| === htorque__ is now known as htorque | ||
| sconklin | tgardner: do you know what's required for packaging lts-backports kernels? I have a few questions. Do we use the tarball from the first upload as the .orig or do we upload full source each time? | 21:53 |
| sconklin | and, we include the entire changelog each time because of the way it's rebased, right? | 21:54 |
| tgardner | sconklin, I think I did the full source upload. I can check though. gimme a sec. | 21:54 |
| bjf | ogasawara, questions about the meeting agenda | 21:56 |
| tgardner | sconklin, there is no orig tarball in the archive | 21:56 |
| ogasawara | bjf: sure | 21:57 |
| sconklin | tgardner: so basically package it without using -v and upload it . . . | 21:57 |
| tgardner | sconklin, I'd use the -v option 'cause there is always a delta from the package in -updates. It'll do the right thing using the -sa option, even when there is no orig tarball | 21:57 |
| sconklin | ok, great, thanks | 21:58 |
| * tgardner --> EOD | 22:00 | |
| === Quintasan_ is now known as Quintasan | ||
| ohsix | hi, getting panics i was getting on .39 on the newly released .38-10: http://img847.imageshack.us/img847/2017/dscn0955v.jpg | 22:37 |
| ohsix | ok i can make it happen with some regularity if i write something to the drive (cat /dev/zero > /media/blah/temp for a few seconds), kill it then eject | 23:13 |
| ohsix | how do i translate these numbers to something i can look at in git? 2.6.38-10.44 (other is -9.43, trying to track down something related to that panic) | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
