| === tsimpson_ is now known as tsimpson | ||
| smb | morning | 08:18 |
|---|---|---|
| cking | morning smb | 08:28 |
| ppisati | cool, last dist-upgrade broke empathy :( | 09:04 |
| smb | ppisati, Isn't that the "normal" behavior? | 09:08 |
| ppisati | brb | 09:38 |
| * apw reboots for 37M of new shiney bits | 09:58 | |
| === himcesjf1 is now known as himcesjf | ||
| alexbligh1 | is it intended to have a precise-backports kernel for lucid, the same way as we have a oneiric-backports and a natty=backports? | 11:10 |
| * ppisati -> out for lunch | 12:04 | |
| apw | alexbligh1, no, we are not intending to make that combination | 12:28 |
| === bladernr_afk is now known as bladernr_ | ||
| smb | herton, You reckon it is ok to also apply the changes for the cve to maverick master-next, even with a chance that it won't get released in case there is nothing urgent? I sort of completely managed to not read the announcement carefully enough that it should slowly go out of updates. | 13:34 |
| smb | Otherwise I'd go ahead and apply them (hopefully not clashing with tgardner ) | 13:35 |
| tgardner | smb, I've not started, so you've got the ball | 13:36 |
| herton | smb, hmm, may be we should wait, unless the CVE is critical enough to have a release | 13:36 |
| smb | tgardner, Okay will do | 13:36 |
| smb | herton, It is maybe in between | 13:36 |
| smb | Not really critical but on the other hand allows a normal user to crash a kvm guest (32bit) | 13:36 |
| smb | herton, But given it is unclear, I'll leave out M for now | 13:38 |
| herton | smb, ok, we have to see, if security thinks it should be released, I think bjf mentioned jj should do a review of CVEs that still are pending and should go | 13:40 |
| smb | herton, Yes, he did. Ok then, pushing all but M | 13:41 |
| * apw is unclear why we would not apply the thing and include it _if_ there is another upload | 13:41 | |
| apw | its most likely to get lost if you don't apply it, and if we have it, and we do another upload, i cannot see why we would not include it | 13:42 |
| apw | the review with jj is about which ones we can not bother with the effort to do them, if its no effort or already done ... | 13:42 |
| apw | plus you can always rebase them out of existance | 13:43 |
| herton | I don't see any problem as well in applying too, if no one bothers that may be what is in master-next will not be released | 13:43 |
| herton | yes, it could be rebased/removed later | 13:44 |
| smb | herton, apw Ok, so that means I should apply it and it can be decided later to drop it? (just wanting to confirm,) | 13:57 |
| herton | smb, yes, just apply it, in the worst case we can remove it from master-next later | 13:58 |
| smb | allrighty then | 13:58 |
| cba123 | I'm getting random freezes, on 11.10 (3.0.x kernel). In my logs I recall seeing "rcu_sched_state detected stall on CPU 0" which I've seen other people have too. They say they went to 3.2.x and the issue seems to have cleared. Can I go to the Precise repo for the kernel and go back, or is there an Oneric backport kernel repo I don't see? | 14:06 |
| apw | cba123, those may well show up in syslog so you might look there. there is no official 3.2 kernels for oneiric no | 14:12 |
| cba123 | apw, Yes, so I'd imagine that the rcu is the effect not the cause? | 14:14 |
| apw | yep, its just telling you something got stuck somewhere... though the stack trace can often help | 14:14 |
| apw | you might be able to get a stack trace with sysrq when it does hang | 14:15 |
| cba123 | What do I use for a stack trace, or sysrq? | 14:16 |
| desrt | good morning | 14:18 |
| desrt | who is the curator of all things drm? | 14:18 |
| * desrt is testing http://lists.freedesktop.org/archives/intel-gfx/2012-March/015486.html | 14:21 | |
| === elmo_ is now known as elmo | ||
| bullgard4 | 'man apt-cache': "blue lines are pre-depends, green lines are conflicts." How are »pre-depends« defined? | 14:49 |
| lamont | if I throw a 3.2 kernel on lucid, how much breaks? | 15:01 |
| tgardner | lamont, shuold work | 15:02 |
| tgardner | lamont, we've got 3.0 kernels on Lucid | 15:02 |
| lamont | well, I know there are userspace things that git a tad bit annoyed at != 2.6.X, no? | 15:02 |
| lamont | or is that mostly just build time issues | 15:03 |
| lamont | ? | 15:03 |
| tgardner | lamont, mostly build time issues, though IIRC there was a user space package that complained. Maybe DKMS ? | 15:03 |
| lamont | cool. I may try that step, or I may just shove the box into precise | 15:04 |
| smb | Though wasn't the problem more of a "who stole the third digit"? | 15:04 |
| apw | tgardner, are you or leann handling the upload the end of this week ? | 15:04 |
| tgardner | apw, leann said whe'd be around tomorrow long enough to do it. | 15:04 |
| lamont | Mar 15 08:53:21 wfg-gw kernel: [244607.623349] nf_ct_sip: dropping packetIN=eth0 OUT= MAC=00:0e:0c:5c:1c:78:00:0c:85:be:5a:85:08:00 SRC=192.168.133.192 DST=192.168.133.1 LEN=591 TOS=0x10 PREC=0x40 TTL=64 ID=57781 PROTO=UDP SPT=51374 DPT=5060 LEN=571 | 15:05 |
| lamont | mostly, I want to stop having logs full of that | 15:05 |
| tgardner | lamont, ah, you're still having that issue. | 15:05 |
| lamont | 72MB/day of that issue | 15:05 |
| lamont | 2.6.32-39-generic-pae | 15:05 |
| tgardner | well, 3.2 is worth a try | 15:06 |
| apw | lamont, i think ps will start moaning a bit about the kernel version | 15:09 |
| apw | lamont, mostly it was package building which was a bit suspect in that combination | 15:09 |
| lamont | right. upgrade it is then | 15:09 |
| apw | lamont, builds with checks for 2.6.x and similar in them | 15:10 |
| apw | there is a personality flag, which allows the kernel to report itself as 2.6.39+N i think it is | 15:10 |
| lamont | yeah | 15:10 |
| lamont | so lets say I have / on /dev/md2 (swraid1), and I want to migrate to having it on an LVM volume on the same thing... Can I: remove one drive from the array, mdadm create -f on it, pvinit it, pvcreate, vgcreate, lvcreate, mount, sync, reboot onto the half-there md3, and then mdadm --add the other drive and be all shiny and happy? or is that crazytalk? | 15:13 |
| lamont | (yes, backup first, because I care) | 15:13 |
| lamont | s/sync/rsync/ | 15:13 |
| tgardner | lamont, AFAIK each of those steps ought to work, though I think you'll be pioneering.... | 15:14 |
| lamont | tgardner: heh | 15:16 |
| lamont | my biggest concern is making sure that the *^)*^( swraid doesn't decide that it wants to readd the second drive backinto the original raid and trash all my work | 15:16 |
| lamont | but if it's already a new array, there's little risk of that | 15:17 |
| lamont | if lvm is installed, and root is not on lvm, does lvm get all its pretty hooks into the initrd still? | 15:17 |
| lamont | because not having lvm in the initrd on that reboot would suck | 15:17 |
| tgardner | lamont, that I can't tell you. I've mostly used mdadm. | 15:17 |
| lamont | np | 15:18 |
| smb | lamont, I think it is in there when it is installed | 15:18 |
| lamont | just one more thing to verify before the reboot | 15:18 |
| lamont | smb: that would be suitable for my interests | 15:18 |
| bullgard4 | [solved] | 15:18 |
| smb | lamont, Actually my local machine is done that way. So you should be ok. (after all those test installs I cannot remember reliably what I have done where) | 15:26 |
| === rbtz is now known as SaveTheRbtz | ||
| desrt | So I filed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/956046 and built a kernel package with the patch. It fixes the issue. | 16:01 |
| ubot2` | Launchpad bug 956046 in linux "intel driver fails to use dual-link LVDS if lid is down at boot" [Undecided,Confirmed] | 16:01 |
| desrt | not sure if it causes other issues, of course.... :) | 16:01 |
| ppisati | GrueMaster: 3.2.10 (that's in master-next) fixes the serial problem we have with omap3 | 16:32 |
| === bladernr_ is now known as bladernr_afk | ||
| GrueMaster | Cool, thanks. | 16:38 |
| === lifeless_ is now known as lifeless | ||
| === cos^_ is now known as cos^ | ||
| === bladernr_afk is now known as bladernr_ | ||
| hrw | hi team | 17:33 |
| hrw | can someone take a look at http://pastebin.com/LwtJ6jzm patch to kernel packaging? first hunk disables build of tools for cross compilation (we do not have all libraries multiarched for it yet), second is irrevelant now but will be needed when we will be able to cross build tools | 17:34 |
| * ppisati -> out | 17:48 | |
| tgardner | hrw, email it on kernel-team@lists.ubuntu.com where it'll likely get a bit more attention. | 17:54 |
| === tgardner is now known as tgardner-lunch | ||
| Laibsch | Can somebody please accept the lucid nomination for the critical bug 745836? This has caused data corruption and frequent crashes in essential pieces of software like OOo.org for more than a year now. Patch is available and landed in natty and beyond. | 18:21 |
| ubot2` | Launchpad bug 745836 in linux "encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [High,Confirmed] https://launchpad.net/bugs/745836 | 18:21 |
| tyhicks | The bug Laibsch is talking about was actually an eCryptfs bug, despite the confusing bug title. | 18:28 |
| tyhicks | It was a pretty simple patch, but I don't know how it applies to a kernel as old as Lucid's | 18:29 |
| ohsix | if it's a known bug, patch and SRU shouldn't be hard | 18:29 |
| Laibsch | ohsix: do you have upload rights to the kernel? My experiences with "patch served on a platter" for even highly important bugs has been less than good. | 18:33 |
| ohsix | eh, you mean important by your own criteria; or your own SRU requests? | 18:34 |
| Laibsch | highly important as in "mass-market netbook without wifi support for more than half a year" even though upstream kernel had a patch after two days | 18:35 |
| Laibsch | no amount of bugging and begging got anyone's behind moving :-( | 18:35 |
| ohsix | was there an SRU | 18:36 |
| ohsix | or was it discovered before a release | 18:36 |
| Laibsch | that was for lucid at the time it was in development | 18:36 |
| Laibsch | January 2010 | 18:36 |
| Laibsch | ohsix: will you also answer my question now: do you have commit rights? | 18:37 |
| ohsix | that question isn't relevant, but no; what would it even mean to have "commit rights", to the bzr on launchpad? people don't just shove things in there to get them into packages ...] | 18:38 |
| tyhicks | Laibsch: To be fair to the kernel team, this one was extremely hard to debug. IIRC, it wasn't known that it was an eCryptfs issue for quite some time and then once that was determined and I was notified, it took me quite a while to debug it and fix it upstream. | 18:39 |
| tyhicks | Reading back through the report, it seems that I stumbled upon the fix after removing some crufty code and noticed that the problem went away. That led me to the actual cause. | 18:40 |
| Laibsch | ohsix: if you consider commit rights irrelevant I'm not even sure there's a point to talk. That question is so obviously relevant, there's no need to discuss. tyhicks would fix the issue if he had the powers, but he doesn't. | 18:41 |
| cking | tyhicks, so this just needs backporting to lucid and testing then? I can look at that one | 18:41 |
| ohsix | heh why is there still so many random encrypt-x things in use when you can use dm | 18:41 |
| tyhicks | cking: It sounds like it | 18:42 |
| ohsix | Laibsch: there's a process, it doesn't sound like you know it; that might be a component of why something so important seemed ignored | 18:42 |
| Laibsch | tyhicks: I remember the troubles in pinpointing that problem. And I'm not faulting anyone for 745836. I'm just afraid that lucid might experience a repeat of the sluggish, non-response I've seen in other problems earlier. | 18:42 |
| cking | tyhicks, OK - I will slap it on my todo list then | 18:42 |
| tyhicks | cking: A couple helpful links... | 18:42 |
| ohsix | just because cking was here this time ... ! | 18:42 |
| tyhicks | A description of the problem: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/745836/comments/86 | 18:42 |
| ubot2` | Launchpad bug 745836 in linux "encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [High,Confirmed] | 18:42 |
| cking | nice, I can even write a testcase and add it to the ecryptfs tests | 18:43 |
| tyhicks | cking: A simple patch which should fix it in old releases if you don't want to backport the upstream changes that luckily solved the problem: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/745836/comments/87 | 18:43 |
| * tyhicks remembers that he needs to merge cking's latest test suite changes sometime this week | 18:44 | |
| cking | OK - I will see if I can get around to this tomorrow or monday | 18:44 |
| ohsix | cking: but do you have commit rights?!?!!1111 | 18:44 |
| cking | I can do the SRU work, do the testing etc, I've been doing ecryptfs SRU's over the past few weeks, so it's my bread-n-butter | 18:45 |
| * cking will give it the love it requires | 18:46 | |
| ohsix | nice, but i can't make the joke i was going to had you said yes | 18:46 |
| ohsix | well, thanks for speaking up; maybe i was explaining things poorly but it didn't seem to be getting any traction | 18:46 |
| === yofel_ is now known as yofel | ||
| cking | glad you mentioned it, somehow I missed that one, and I've looked a a bunch of these over the past few weeks | 18:47 |
| cking | tyhicks, is it OK just to use the simple patch in comment 87 rather than backport the other two patches? | 18:48 |
| * cking being lazy | 18:48 | |
| tyhicks | cking: Let me take another look at those two patches. My mind is going almost completely blank on this bug... | 18:49 |
| ohsix | who would have thought where you store your pages would be important | 18:49 |
| tyhicks | cking: Yes, it sounds like I was pretty confident that the simplified patch in comment 87 was the real fix and the upstream commits just covered everything up. I _know_ that I wouldn't have attached that patch without testing. | 18:52 |
| cking | sure - thanks for checking | 18:53 |
| lamont | tgardner-lunch: missing step: update mdadm.conf to reflect the new array, so that the vg is found | 18:56 |
| lamont | \o/ | 18:56 |
| tgardner-lunch | lamont, yeah, I always have to go to the wikipedia page for mdadm to remember that. | 18:57 |
| === tgardner-lunch is now known as tgardner | ||
| lamont | yeah, nothing quite like not finding the root partition | 19:00 |
| hrw | tgardner: sent | 19:26 |
| === bladernr_ is now known as bladernr_afk | ||
| === bladernr_afk is now known as bladernr_ | ||
| * tgardner -> EOD | 20:27 | |
| _ruben | EOD .. that's the dutch abrev for the bomb squad .. guess he hadda run ;) | 20:34 |
| unwired | Hi, just found a bug in kernel 3.0.0-17.30 from onieric-proposed, but I'm not sure where to report it... | 21:03 |
| === egon_ is now known as egon | ||
| === bladernr_ is now known as bladernr_afk | ||
| === bladernr_afk is now known as bladernr_ | ||
| === chrisccoulson_ is now known as chrisccoulson | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!