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