| * apw struggles into the land of the living | 08:21 | |
| infinity | apw: It's an overrated land. | 08:39 |
|---|---|---|
| apw | infinity, seemingly so indeed | 08:39 |
| * ppisati -> reboot | 08:39 | |
| rbasak | Have you guys seen: https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037134.html ? | 08:46 |
| rbasak | Seems like a reasonable question - should he be directed to the kernel-team list? | 08:46 |
| infinity | rbasak: Mainline kernel builds aren't (quite) the same as Ubuntu configs. I assume the bump to 3.10 will also involve a config review and turning on all the new shiny. | 09:07 |
| infinity | rbasak: But I don't speak for apw/rtg on this one, so perhaps bouncing it to the kernel list would be helpful. *shrug* | 09:07 |
| apw | rbasak, yep bounce that to the kernel-team and we can answer it, i would likely find it on u-d eventually | 09:19 |
| apw | for clarity the reason it is off is that our saucy hasn't got the functionality turned on, so the config which carries over won't have it. when we move saucy to 3.10-rcN then we'll turn it on no doubt there and the mainline kernels will get it | 09:20 |
| apw | basically it is hard to enable everything | 09:20 |
| apw | we ask the build system to take the defaults for everything new, and the default for that must be N | 09:20 |
| apw | so it it probabally untested crap :) | 09:20 |
| apw | it appears to not indicate a default so i would expect that to default off | 09:25 |
| apw | Block device as cache (BCACHE) [N/m/y/?] (NEW) | 09:25 |
| apw | yeah, it defaults off so we default it off | 09:25 |
| rbasak | apw: I'm going to need moderation on both lists so will cause other people effort if I try to stick my nose in. Would you mind replying to him as appropriate, please? | 09:44 |
| rbasak | apw: or just C&P this channel if you're feeling nosy :) | 09:44 |
| rbasak | nosy? | 09:44 |
| rbasak | lazy. | 09:44 |
| davmor2 | Morning all. I upgraded from Raring to Saucy last week and it broke secure boot. I'm running a couple of things that cjwatson suggested but feel free to fire off suggestions here too :) | 12:13 |
| rtg_ | henrix, how about a pull request for your CVE patches ? | 12:16 |
| rtg_ | I assume you have them all in one place. | 12:16 |
| henrix | rtg_: yep, i have. i'll send the request | 12:16 |
| rtg_ | henrix, thanks, saves me some typing, something I'm wretchedly bad at. | 12:17 |
| henrix | rtg_: heh, sure no prob | 12:17 |
| henrix | is anyone else receiving an annoying email from naver.com after sending an email the the kt mailing list? | 12:39 |
| henrix | looks like someone from that domain subscribed the ML and that email was deleted from the domain | 12:39 |
| henrix | *really* annoying | 12:39 |
| rtg_ | henrix, why are you getting it ? | 12:39 |
| henrix | rtg_: i believe its because my 'Reply-To:' | 12:40 |
| henrix | rtg_: in the email header | 12:40 |
| henrix | it started last week | 12:40 |
| rtg_ | I'm the admin, lemme check. | 12:41 |
| henrix | here's a sample: http://paste.ubuntu.com/5683555/ | 12:41 |
| henrix | it contains the email address, so maybe you can just unsubscribe it...? | 12:42 |
| rtg_ | henrix, thats what I'm gonna do | 12:42 |
| henrix | rtg_: cool. thanks. but am i the only one seeing this? | 12:42 |
| rtg_ | henrix, I haven't seen it, but then I have not sent anything since about thurs | 12:43 |
| rtg_ | henrix, that email address is now unsub'd | 12:43 |
| henrix | rtg_: thanks | 12:44 |
| diwic | I haven't seen it either | 12:44 |
| henrix | yeah, it started late last week. let me check... | 12:44 |
| henrix | ok, first time i saw that was last friday, when i spammed the ML with the 3.5.y emails | 12:45 |
| diwic | henrix, maybe that overflowed the relevant email inbox or something, causing the error | 12:45 |
| henrix | diwic: yep, its possible :) | 12:46 |
| rtg_ | apw, thought I'd start on maguro today. seems like grouper/manta/mako have all settled a bit. | 13:05 |
| apw | rtg_, great | 13:05 |
| ogra_ | yay | 13:07 |
| * rtg_ bounces tangerine for kernel update | 13:33 | |
| rtg_ | cking, 'wipe' is estimating 5 years to clean this USB 2.0 disk. is there something else I can use to test this disk ? I was getting some random failures and haven't been able to pin down where. | 13:51 |
| cking | rtg_, no immediate idea for fast exhaustive exercising such devices | 13:52 |
| cking | how about plain old dd'ing to it to see if that easily trips the issue? | 13:53 |
| rtg_ | cking, maybe just writing withh dd will trigger it | 13:53 |
| rtg_ | :) | 13:53 |
| cking | indeed | 13:53 |
| cking | just make sure bs = something large :-) | 13:53 |
| rtg_ | cking, yeah, block size makes a giant difference | 14:00 |
| infinity | rtg_: What sort of failures were you seeing? | 14:09 |
| infinity | rtg_: Be warned that if you were seeing random *read* failures, dding over the disk will magically paper over that, as attempts to *write* those sectors will trigger auto-remapping magic. | 14:10 |
| infinity | rtg_: Though, that's still an interesting datapoint. If you can convince something like smartmontools to spew out disk info before and after a full dd, if your remap count goes up, your disk is dying. | 14:12 |
| rtg_ | infinity, random failures to read from the file system resulting in hung threads. | 14:13 |
| rtg_ | apw, the linux 3.9.0-2.7 build for i386 is busted whilst some doc-utils carnage is being fixed. | 14:57 |
| apw | rtg_, ook, ok | 14:58 |
| rtg_ | apw, I think the release team will just restart the build once that is fixed | 14:58 |
| apw | rtg_, ahh that kind of carnage, ok | 14:59 |
| rtg_ | apw, they ointed out that our build chroots should have -proposed enabled, but I'm kind of unwilling to do that on tangerine/gomeisa lest it impede everyone because of some silly archive inconsistency. | 15:00 |
| rtg_ | point* | 15:00 |
| apw | rtg_, indeed, i have two chroots for sbuild, well a special frig that allows one to ask for -proposed to be enabled when sbuilding things | 15:01 |
| apw | which i use for this very reason. if we have those kind of chroots too, you could at least confirm finally with an sbuild that it was a chroot issue | 15:01 |
| rtg_ | hmm | 15:01 |
| apw | but for the statuc c | 15:01 |
| apw | static chroots we have, not so easy | 15:02 |
| rtg_ | it happens so seldom that i wonder if its worth it. | 15:02 |
| apw | probabally not in my opinion, i should publicise the other ones, and make them consistently across the buildders | 15:02 |
| apw | so people can at least go 'ummm, i wonder, -proposed, lets see' | 15:02 |
| rtg_ | apw, _we're _ the only people interested in -proposed I think. | 15:03 |
| apw | yeah prolly, then i'll tell you :) | 15:03 |
| apw | rtg_, ahh crap you applied luis' pull request; but didn't mention it on the patches, so i have reviewed them needlessly | 15:04 |
| rtg_ | apw, yeah, I just used his pull request and ACK'd that | 15:05 |
| rtg_ | I guess I just assumed ... | 15:05 |
| apw | ahh well, you have a second ack, even if it is not in the applied commits | 15:05 |
| henrix | apw: sorry, i guess i should have sent the pull request as a reply to the patches... | 15:06 |
| rtg_ | they all looked pretty straightforward | 15:06 |
| apw | yep tey all are indeed | 15:06 |
| apw | henrix, rtg_, *shrug* noones fault | 15:06 |
| rtg_ | cking, the Q/A folks were talking about using lttng as a general mechanism for tracking some stuff. do you know of they received your results about lttng overhead ? | 15:10 |
| cking | rtg_, I did send a copy to gema | 15:10 |
| rtg_ | cking, cool | 15:10 |
| cking | not heard any reponse yet | 15:10 |
| cking | *response even | 15:10 |
| apw | jsalisbury, yo ... you were working on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1112652, did you confirm that those two patches in stable were the fix ? | 15:21 |
| ubot2 | Ubuntu bug 1112652 in linux (Ubuntu Raring) "[raring] no ethernet with "auto" default power option with 82579LM" [High,In progress] | 15:21 |
| infinity | E: linux source: build-depends-on-essential-package-without-using-version build-depends: util-linux | 15:24 |
| infinity | rtg_, apw: ^--- Really? | 15:24 |
| infinity | Evidently, no one ever runs lintian on the kernel. | 15:25 |
| cking | or nobody ever looks at the lintian errors | 15:25 |
| infinity | Hey, I never lintian the kernel either. :P | 15:25 |
| infinity | Just saw that in passing while helping some poor sod who's trying to build a patched kernel. | 15:26 |
| apw | infinity, heh, you know us, cowboys the lot of us | 15:26 |
| apw | cowpersons | 15:26 |
| * rtg_ didn't know he was supposed to care | 15:26 | |
| apw | i think that is somewhat his point :) | 15:28 |
| rtg_ | apw, well, I _do_ know someone that would like to fix all the lintian warnings. | 15:28 |
| infinity | It's mostly harmless, but {Build-,}Depends on essential packages can cause some resolver oddities and other messes. | 15:28 |
| apw | infinity, has that changed to be essential, or have we always been bust | 15:29 |
| apw | rtg_, shhh he will hear | 15:29 |
| infinity | apw: It's always been essential. | 15:29 |
| apw | oops | 15:29 |
| apw | rtg_, i'll go zap it in saucy at least | 15:29 |
| rtg_ | infinity, so you're saying it shouldn't be in build-depends list at all ? | 15:29 |
| infinity | rtg_: Right. | 15:29 |
| rtg_ | well, tats an easy one | 15:30 |
| infinity | rtg_: Unless, of course, there was a reason to have a versioned build-dep, but you don't have such, so that seems unlikely. :P | 15:30 |
| apw | infinity, its not recent, so any version would be balls by now anyhow | 15:30 |
| rtg_ | infinity, the last versioned build dep was for file-utils IIRC | 15:30 |
| rtg_ | I'm sure we can drop that by now as well | 15:30 |
| rtg_ | findutils | 15:31 |
| infinity | Oh, you mean that build-conflict? | 15:31 |
| rtg_ | yeah, its a conflict, not a depends | 15:31 |
| rtg_ | apw, fix the Vcs-Git whilst you're mucking about | 15:32 |
| apw | yep | 15:32 |
| infinity | rtg_: Given that that version predates lucid, you're probably safe dropping the build-conflict, yeah. :P | 15:32 |
| rtg_ | apw, ^^ | 15:33 |
| apw | ack ^2 | 15:33 |
| infinity | It also never shipped in any release. | 15:33 |
| apw | nice | 15:33 |
| infinity | It was only in karmic for 3 days. :P | 15:33 |
| * apw bets it was infinity's fault ... | 15:34 | |
| infinity | Don't look at me, I didn't work here during the karmic release. | 15:34 |
| infinity | I don't think. | 15:34 |
| rtg_ | we'll blame it on Ben | 15:36 |
| infinity | He didn't work here either. | 15:36 |
| cking | he did | 15:36 |
| infinity | *cough* | 15:36 |
| cking | ah | 15:36 |
| * apw remembers why we don't run lintian very often on this package ... omg it takes a long time | 15:44 | |
| * cking wonders if that's because it's gone off and committed suicide because of the quantity and type of errors it's found | 15:45 | |
| apw | i think perhaps the machine i ran it on has ... sigh | 15:45 |
| apw | W: linux source: unknown-architecture armhf | 15:45 |
| apw | W: linux source: unknown-architecture arm64 | 15:45 |
| apw | oh come on ... i hate lintian | 15:46 |
| infinity | That'd be an old lintian. | 15:46 |
| apw | yeah, and ... well just ... and .. | 15:46 |
| manjo | hey you guys seen this with 13.04 ? | 15:49 |
| manjo | [ 5.710629] BUG: unable to handle kernel paging request at ffff8804075a3fe0 | 15:49 |
| manjo | [ 5.710659] IP: [<ffffffffa04ac820>] patch_generic_hdmi+0xe0/0x550 [snd_hda_codec_hdmi] | 15:49 |
| infinity | apw: http://paste.ubuntu.com/5684150/ | 15:49 |
| apw | manjo, yep, that should have been diwic's fix i think | 15:50 |
| infinity | apw: The only one there (other than the one you fixed) that looks potentially scary is they unsafe symlink one. | 15:50 |
| rtg_ | manjo, yes, the fix is in the pipeline | 15:50 |
| infinity | manjo: That should be fixed in the -proposed kernel. | 15:50 |
| manjo | apw, cool thanks ... I lost sound as well ... | 15:50 |
| apw | infinity, there is 2 or 3 there that diserve a wiggle, i'll get the sorted out | 15:51 |
| apw | infinity, these binary-control-... ones are they something we do wrong, or something ubuntu does diff to debian | 15:52 |
| infinity | apw: Note that P (pedantic) and I (informational) ones aren't really errors, per se. | 15:52 |
| infinity | apw: But it's hinting that binaries that don't declare section/priority inherit from the source stanza, so it's a waste of effort to declare it every time. | 15:53 |
| infinity | apw: Due to the way you build your control files, being overly declarative is likely not a bad thing, since the snippets live on their own and it's easier to keep track of them as self-contained units. *shrug* | 15:53 |
| apw | infinity, i actually suspect it is kernel-wedge in that case | 15:54 |
| infinity | apw: Nah, it's all your kernel image packages from control.d | 15:54 |
| infinity | apw: (It does list the binary stanza at the end of each of those lines) | 15:55 |
| apw | infinity, so it does... | 15:56 |
| infinity | apw: Now, you can blame the pedantic spew on kernel-wedge. | 15:57 |
| infinity | apw: The xc-package-type-in-debian-control thing. | 15:58 |
| infinity | apw: Oh, the duplicate description thing is entirely valid too. linux-image-extra really should mention that it's addon modules or something, not claim to be a kernel image. | 16:00 |
| apw | infinity, already fixed that last one | 16:01 |
| apw | infinity, as indeed it is just wrong | 16:01 |
| infinity | (And the gfdl test is a no-op for Ubuntu, we consider the GFDL "free enough", while Debian doesn't) | 16:01 |
| apw | ahh | 16:02 |
| apw | infinity, to be clear the lintian errors about the symlink would have to be talking about a specific file in the source package, rather than a binary package | 16:07 |
| apw | lrwxrwxrwx 1 apw warthogs 33 2013-05-20 16:05 ./arch/microblaze/boot/dts/system.dts -> ../../platform/generic/system.dts | 16:07 |
| apw | which as far as i can see is a false positive | 16:08 |
| infinity | apw: Yeah, that's supposed to warn on symlinks that escape the source tree, but that one doesn't seem to. Weird. | 16:15 |
| infinity | apw: liintian bug, I guess. | 16:15 |
| apw | yep ... /me looks at standards version, we have ignored it too long | 16:16 |
| ppisati | brb | 16:32 |
| apw | infinity, you will be pleased to know we can move to the latest standards version. | 16:42 |
| apw | like it matters any | 16:42 |
| apw | infinity, ok i have pushed up some fixes, seems to cover the egregious ones, and leaves the ones you indicated were benign or debian eske | 16:46 |
| === awe_ is now known as awe|lunch | ||
| * rtg_ -> lunch | 17:23 | |
| jsalisbury | apw, re: bug 1112652 I didn't identify the specific patch that fixed the bug. Many people affected by the bug reported 3.8.13 fixed the bug, so I was going to ask for confirmation once Raring gets those updates | 17:35 |
| ubot2 | Launchpad bug 1112652 in linux (Ubuntu Raring) "[raring] no ethernet with "auto" default power option with 82579LM" [High,In progress] https://launchpad.net/bugs/1112652 | 17:35 |
| apw | jsalisbury, there are two likely sounding patches to the e1000e driver in .13 (well at least one sounds believable as it talks about power management) | 17:36 |
| apw | jsalisbury, sounds good, thanks. we nom'd it to raring and closed out saucy based on the testing done | 17:36 |
| jsalisbury | apw, cool, thanks | 17:37 |
| bjf | manjo, since you have -proposed enabled (you _do_ don't you?) you should have picked up the change for that issue | 17:42 |
| manjo | bjf, yes got it though proposed | 17:43 |
| bjf | manjo, so you are running the -proposed kernel *and* you saw the hdmi issue your reported above? | 17:44 |
| bjf | manjo, i'm trying to find out if the bug you saw is in the -proposed kernel | 17:46 |
| manjo | bjf, no proposed fixed it for me. I was not running proposed when I hit the bug | 17:51 |
| bjf | manjo, ok, good to hear, thanks | 17:51 |
| manjo | cool np | 17:51 |
| * rtg_ -> EOD | 20:18 | |
| === kentb is now known as kentb-out | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!