[00:57] My custom kernel spits out a wierd mountall and plymouth error [01:02] could not connect to upstart: could not open socket: address family not supported by protocol === jk-- is now known as jk- [08:51] * apw yawns [08:52] * smb is beyond thatzzzzz [08:55] * amitk throws resistors into apw's gaping mouth [08:56] that's all I had lying around :) [08:56] amitk, Amazing what kind of stuff _you_ have lying around. :) [08:56] its a while since i had any of those [08:57] or indeed a use for the [08:57] them [09:00] heh [09:04] > #ifdef BTN_TRIGGER_HAPPY [09:04] * apw reminises ... how did you get that past them [09:04] * smb just proposed... [09:05] ... and apparently there was no better name for the need of more than 40 buttons on a joystick [09:06] * apw smiles about the name [09:14] smb, oh while i remember ... did that email go out abuot the SATA ALPM ? === smb` is now known as smb [11:28] apw: Would you guys object terribly to including the netfilter ipset patch in the kernel? [11:29] soren, which one is that, got a pointer ? and in which kernel? [11:30] apw: Natty (and onwards, possibly). [11:30] * soren finds link [11:30] http://ipset.netfilter.org/ [11:30] is it going upsteream? [11:30] and what does it do, why do we need it [11:31] It's a more efficient way to apply an iptables filter to a (large) set of IP's. [11:32] Instead of having a rule per IP, you have a rule pointing to the ip set. [11:32] The ip sets are implemented using more efficient data types. [11:32] Like a hash or whatnot. [11:33] So instead of having to traverse through hundreds of individual iptables rules, you just have one with a very efficient lookup. [11:33] mostly out acceptance of that kind of thing depend on it being something which is on its way upstream, that it is not intrusive and is well maintained; and there is someone asking for it [11:34] It's not intrusive at all. It can build completely out-of-tree. [11:35] so i wonder if a dkms package might be more appropriate ... [11:35] I'm not sure if it's on its way upstream. I tried asking upstream at some point, but never got a response. It's actively maintained, though. [11:35] DKMS is certainly possible. [11:35] but the normal first step is to propose the thing o [11:35] on kernel-team@, preferablly including the patch [11:35] Sure. [11:36] hows it all going ? obviously got a lot of machines if you need that :) [11:36] I was just trying to float the idea to gauge whether I should bother at all :) [11:37] even if we say no, at least noone else needs to ask the reasons if we have them in public [11:37] Indeed. [11:38] I try to avoid hardware. It's nice and quiet in my office without server fans drilling into my ears. [11:38] :) === Quintasan_ is now known as Quintasan === sconklin-gone is now known as sconklin === herton is now known as herton_lunch [15:24] tgardner, Rhetorical question: the last time you did an ABI bump in Hardy was longer time ago, wasn't it? [15:25] smb, um, I think I pushed one recently. lemme check [15:25] tgardner, Yep, that is the one you broke. :) [15:25] smb, what do you mean? [15:25] smb, is hardy the one we still ahve the result files checked in? [15:26] * smb reminds tgardner that Hardy has all this generated files checked into the tree still [15:26] yep, [15:26] I got things here, will fix it up [15:26] at least we have -next rebase allowed ness now [15:26] smb, I've been building hardy, so I thought it was correct. what did I miss? [15:27] Yeah, [15:27] tgardner, the issue is if you clean it works just fine [15:27] tgardner, Oh just those control control.stub and d-i stuff [15:27] but if you just make it can leave the unchanged files ... all depends on dates [15:27] frick [15:27] Just give me a second and next is good [15:27] JFo, shall we dance on the balcony [15:28] sure [15:29] tgardner, done [15:30] smb, pulled [15:30] smb, did I get dapper right? [15:30] tgardner, Not build tested yet. That will be next [15:32] tgardner, It looks right though [15:32] will wonders never cease ? [15:40] you're just that good tgardner :) [15:48] smb, new version checked in and pushed, give it a try [15:48] smb, if i can get it working for you, i figure it will work for the others as well :-) [15:48] tgardner, Would you want the honors? I am done with my CVE this week... :-P [15:49] smb, I'll try it with the next one. [15:49] smb, if you use the "--staging" flag, you can use the same cve number and it will create the bug on the staging server [15:49] bjf, Right, true. Ok, a sec [15:52] bjf, lpltk.service.LaunchpadServiceError [15:53] smb, ok, let me do some real debugging and not just some hacking [15:53] bjf, Ok, it seems the error comes from reset in lpltk so it could be just lp being broken [15:54] Oh wait that _is_ the default isn't it. :) === herton_lunch is now known as herton [16:14] smb, the staging server is: "Code Update In Progress", took me a bit to run that down [16:15] bjf, Ph well, so broken by default was true. Thanks for digging into that [16:23] GrueMaster, Lucid linux-mvl-dove is built at https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages. Please test it. thanks. [16:24] Already loaded. Just getting ready to head to the basement to verify console screen output. Thanks. [16:24] yay interlock is working [16:26] * JFo goes to check on the updates on his natty netbook. brb [16:28] tgardner: Still not right. Same console screen corruption. [16:30] GrueMaster, hmm, you're _really_ sure the previous kernel doesn't exhibit this issue? I wonder if I rebuilt the previous version using current Lucid toolchain etc if it would also have the console problem. [16:32] I just rebooted and reverified (lots of stairs were involved). [16:33] The working kernel for lucid on dove is 2.6.32-209.25 [16:33] I wonder if there is something that needs to be done for plymouth? [16:34] GrueMaster, well shit, 2.6.32-209.25 isn't exactly the previous kernel. there are at least 4 versions after that. I wonder which one broke the console? [16:37] The only one that apt-cache shows in between 209 and 214 is 211. I was never notified of it, but I can install and test it. [16:37] GrueMaster, do you have 210.26, 211.27, 212,28, or 213.29 ? I can rebuild them if not. [16:37] linux-image-2.6.32-211-dove_2.6.32-211.27_armel.deb is the one being pulled from archive. [16:38] GrueMaster, probably 'cause they never got promoted. Are you pulling from -proposed? [16:38] Let me see if it passes or fails, then we can go from there. [16:39] Yes I am. But my system is in the basement in a rack cabinet now, and unless I am notified of updates, I don't test them. [16:39] GrueMaster, does _anyone_ else have this HW? Someone in the community? [16:40] I think the only other hw I know of is OEM, but it is not marvel test platform. They have an OEM system. [16:40] I'm wondering why I'm spending time on it otherwise [16:40] I haven't heard of any dove based systems in the wild yet. [16:40] heh, same here. :P [16:41] lemme chat up David. [16:41] (which is also why I recommend ignoring karmic). [16:41] karmic is already abandoned [16:41] for mvl-doce that is [16:41] yea! [16:41] dove* [16:42] That saves me a LOT of headache. I don't have an image atm. Not even a mirrored copy to boot with. I would have to start from scratch. [16:45] Ok, relocated to basement. linux-image-2.6.32-211-dove_2.6.32-211.27_armel.deb is running with no console corruption. [16:48] tgardner: I'll setup my panda systems to do builds and test the kernels in between pass & fail (unless I can find them on lp). [16:48] I can build faster than the buildds. [16:49] GrueMaster, I can cross-compile or use qemu to build in just a few minutes. [16:49] Wel, that would be even faster then. :P [16:50] GrueMaster, I'm emailing David to verify we even need to do this. [16:50] He's in #arm is you want to ping him directly. [16:52] GrueMaster, I can't type that fast, so I'll just annoy him with email [16:56] heh [17:00] k, gonna try to grab some lunch on time today for a change. :-) [17:00] bbiab [17:06] tgardner: Looks like 2.6.212 also fails. That narrows it down. I got it here: https://launchpad.net/ubuntu/+source/linux-mvl-dove/2.6.32-212.28/+buildjob/2064004 [17:26] apw, hi, just had some time for bug 721389 i cloned the branch that got merged (which definitely is the first bad commit in linus' tree) and it doesn't show the problem [17:26] Launchpad bug 721389 in linux "Boot time regression 2.6.38" [Undecided,New] https://launchpad.net/bugs/721389 [17:27] should i now incrementally test all 33 commits that were part of that merge on linus' tree (after the last good commit)? [17:27] htorque_, you should be able to bisect the branch too [17:27] but yes [17:28] apw, the last commit of that branch is good, so i don't know what to bisect for [17:28] ? [17:28] oh hrm [17:28] wibble [17:28] so an interaction between the two, does the commit itself have any diff ? [17:29] could it be a merge error [17:29] htorque_, ok what prolly would do next [17:30] then as the branch is fine, but the merge of it is not [17:30] is to checkout the commit before the merge, then cherry-pick all of the 33 onto the top, not merge them [17:30] and then test that, if it fails, you can then bisect over that [17:31] apw: thanks, will do :-) === jjohansen is now known as jj-afk [17:32] back in a bit === bo is now known as Guest92541 === sforshee is now known as sforshee-lunch [18:35] bjf, Traceback (most recent call last): [18:35] File "./create-cve-tracker", line 219, in [18:35] app.main() [18:35] File "./create-cve-tracker", line 167, in main [18:35] bug = self.lp.create_bug(project='ubuntu', package='linux', title=title, description=description, tags=tags) [18:35] TypeError: create_bug() got an unexpected keyword argument 'tags' === jj-afk is now known as jjohansen [18:44] apw: if i haven't screwed up: after applying all the patches the resulting kernel doesn't show the bug [18:45] wibble [18:51] * tgardner --> lunch === sforshee-lunch is now known as sforshee === bjf is now known as bjf[afk] [19:49] im trying to build the ubuntu maverick kernel from git, but it keeps telling me to run "make mrproper", which blows out the debian/ directory, which means the command "fakeroot debian/rules binary-generic" from https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel fails. how do I build a .deb file of the ubuntu kernel by just using make? [19:50] blag: you have something messed up, this happens occasionally [19:50] if you are in the git tree this trick usually works [19:50] run make mrproper and then do a git checkout -f [19:51] it will restore the debian directory, and you should be able to build [19:57] jjohansen: looks like it worked, thanks! [20:02] * jjohansen -> lunch [20:09] blag, I usually use 'git clean -xfd' in that situation, which seems a little easier and also won't blow away local changes === herton_ is now known as herton [20:14] sforshee: ill have to try that [20:22] sforshee, blag: git clean -dxf will delete untracked files, unless I'm mistaken [20:22] so try it in a place you don't care about ;) [20:23] sconklin, isn't that the point? [20:23] it's no worse than 'make mrproper' as was suggested before [20:23] sorry I misread "local changes" [20:23] yeah, if you have new files they will be blown away, that's a good clarification to throw in [20:24] http://twitter.com/#!/ubuntustatus [20:24] ^^ don't upgrade Natty rigth now [20:25] ugh [20:27] sforshee, I use a sledge hammer to make sure my trees are clean. This works across all versions of git: [20:27] git checkout -f [20:27] git clean -f -d [20:27] git ls-files --others --directory |xargs rm -rf [20:27] rm -rf .git/rebase* [20:28] tgardner, that's certainly thorough :) [20:32] which package sets up the 'Restart Needed' notification after certain kernel upgrades? [20:32] janimo, ask in #ubuntu-devel 'cause I can't remember. [20:34] tgardner, ah so it is not part of the kernel packaging then? Not one of your dpkg hooks? [20:35] janimo, I'm sure its a hook somewhere in the packaging, I just can't remember where. [20:42] bjf[afk], the nominations fix works for me [20:51] quick question hopefully :) [20:51] right now if you file a kernel bug, it lands under 'linux', which is the latest release, natty [20:51] famous last words vanhoof [20:52] true [20:52] sub tasks can be opened against prior releases ... maverick, lucid, etc [20:52] yep [20:52] now say something doesnt get fixed in natty (linux) at this point in time [20:52] you can open a Natty task now as well [20:52] after the natty release, would those tasks be moved to a sub task of natty, and the original task migrated to the 'o' release? [20:52] and the main task will show "Status tracked in Natty" [20:52] no, you would need to add it [20:53] ah ok [20:53] it would be nice to have that [20:53] :-) [20:53] heh [20:54] im just looking at historical data for bugs we've got fixed, sometimes things get filed under linux (applied in natty), and then fix released [20:54] i'm wondering if i go back in time, will i be able to find those by searching under natty [20:54] no [20:54] sounds like if i want that data i need to have natty tasks opened as well [20:54] I wish, but no [20:55] yep, that would be the best way [20:55] best== easiest [20:55] cool, thanks JFo :) [20:55] my pleasure vanhoof :) === bjf[afk] is now known as bjf [21:24] * tgardner has pretty much had his fill of CVE tedium [21:25] bjf, so, are you considering adding all of the relevant linux package names to create-cve-tracker ? [21:26] yes, it's on my todo list [21:26] tgardner, ^ [21:26] bjf, cool. see you Tuesday. === ogra is now known as Guest40503