[03:30] <hxu> Hi! In include/linux/mqueue.h, per-uid limit of kernel memory used by mqueue is set to 819200, but why do I always get -1(infinity) by getrlimit(2)  for both soft and hard limit of mqueue?
[09:07] (kraut/#ubuntu-kernel) moin
[11:54] <dholbach> can somebody look at bug 82343? I'm not sure who to assign it to or if it makes sense at all
[12:05] <IntuitiveNipple> dholbach: I guess it's mostly hal since it is hal scripts that are run by gnome-mount to run cryptsetup, but after that it is gnome-volume-manager (which starts gnome-mount)
[12:05] <dholbach> also bug 57755
[12:13] <IntuitiveNipple> I'm not sure on that one, but it *looks* like udev from those patches
[12:17] <dholbach> I don't have a clue about either of them, so it'd be nice if somebody of the kernel team reviewed and sponsored them
[12:18] <IntuitiveNipple> I did some hacking with hal and gnome-mount for cryptsetup over the weekend, so I'm sure about that one
[12:19] <dholbach> if you comment on the bug it will make it easier for somebody who sponsors the patch to review it
[12:19] <dholbach> I'm happier if I don't touch those parts :-)
[12:19] <IntuitiveNipple> which one, 82343 ?
[12:19] <dholbach> both :)
[12:20] <IntuitiveNipple> *sniggers
[12:41] <dholbach> can somebody also check out bug 129828?
[01:57] <lamont> head->wall
[02:52] <lamont> waiting for builds is such a pain
[02:56] <Riddell> anyone want to fix linux-source-2.6.22-10.26?
[02:56] <Riddell> "make: *** [/build/buildd/linux-source-2.6.22-2.6.22/debian/stamps/stamp-custom-prepare-xen]  Error 2"
[03:02] <lamont> Riddell: i386, I expect?
[03:02] <Riddell> lamont: yes
[03:03] <lamont> ah, it wasn't just hppa then
[03:04] <laga> hello. dev/rtc/max-user-freq is currently set to the default value of 64 which is rather low for multimedia applications. would it be possible for you kernel guys to increase the default value to 1024 as recommended by mplayer/mythtv documentation or would i have negative side effects?
[03:05] <xhaker> mjg59, thanks for the patch, i have udma5 now :)
[03:05] <xhaker> BenC, could you please apply http://www.leetcorp.net/xhaker.diff
[03:07] <abogani> laga: Why someone want use RTC when kernel offer High Resolution Timers at no cost? :-|
[03:08] <laga> abogani: um, might be a legacy item. i still wonder if there are negative side effects.. if not, we can just enable it ourselves in mythbuntu
[03:09] <lamont> Riddell: test i386 build running now
[03:09] <lamont> fix is committed in lamont/hppa-ia64 (xen kernels and hppa were missing CONFIG_MSS)
[03:10] <Riddell> thanks
[03:16] <xhaker> bummer, the kernel was uploaded already! :D
[03:18] <zul> xhaker: send me the patch and ill get it in for the next one
[03:18] <xhaker> zul, here http://www.leetcorp.net/xhaker.diff
[03:19] <zul> got it thanks
[03:19] <xhaker> zul, mjg59 sent me that yesterday. I added the description in front
[04:00] <zul> is there still a meeting today?
[04:07] <lamont> Riddell: I think it'll build.. :-)
[04:09] <Riddell> exciting
[04:10] <lamont> uploaded
[04:10] <lamont> s/ed$/ing/
[04:10] <Riddell> so when you say think, hopefully you're understating?
[04:11] <lamont> yeah.
[04:12] <lamont> it was past the scary part on a previously-afflicted architecture
[04:17] <Riddell> accepted, many thanks lamont 
[04:19] <lamont> yep.  built. :-)
[04:25] <xhaker> hmm, i386 failed to build?
[04:25] <xhaker> the last kernel upload, that is
[04:25] <lamont> -10.27 can't have failed yet
[04:26] <xhaker> zul, will -10.27 have that patch i sent you earlier? maybe i got lucky
[04:26] <zul> xhaker: uh no
[04:27] <lamont> .27 is nothing but the ftbfs
[04:28] <xhaker> lamont, ok.
[04:32] <infinity> Oh, nevermind, it just finishd.
[04:36] <dholbach> I also subscribed the kernel team to bug 125834
[04:36] <dholbach> seems that the team is not bug contact for linux-ubuntu-modules
[04:36] <dholbach> linux-ubuntu-modules-2.6.22
[04:39] <dholbach> also bug 114793
[04:39] <dholbach> and bug 124855
[04:40] <infinity> They're the contact now.
[04:40] <dholbach> rock and roll
[04:40] <dholbach> gracias, monsieur conrad
[04:40] <infinity> You're mixing languages.
[05:12] <zul> atheros is lum isnt it?
[05:13] <rtg_> zul: lrm
[05:21] <lamont> BenC: you around?
[05:28] <bdmurray> rtg_: what package is iwl4965?
[05:29] <rtg_> Gutsy l-u-m
[05:29] <rtg_> bdmurray: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy-lum.git;a=summary
[05:30] <BenC> lamont: yeah
[05:31] <bdmurray> great, thanks
[05:32] <lamont> BenC: so since I suck at unbreaking things... is it preferable to have changelog claim that 10.28 immediately follows 9.25, or to renumber 10.{26,27} to 9.{26,27}?
[05:33] <BenC> lamont: that's what kyle was working on
[05:33] <kylem> so. really shouldn't have uploaded that.
[05:33] <lamont> kylem: sorry.
[05:33] <kylem> and everyone else is kind of stupid for approving it.
[05:33] <lamont> and while you're fixing zen, please fix debian/hppa/config too
[05:33] <lamont> s/zen/xen/
[05:33] <kylem> especially given i was sleeping on the couch about 10 feet away
[05:33] <kylem> with my mobile phone
[05:34] <lamont> I think we were trying to let you sleep
[05:35] <kylem> well, i wasn't at the time it ftbfs.
[05:35] <kylem> anyway. wha tbroke now?
[05:35] <lamont> same bug as xen
[05:35] <lamont> -10.27 is top of my hppa-ia64.git tree
[05:36] <lamont> and dies in abicheck, because I suck
[05:36] <kylem> eh?
[05:36] <kylem> oh.
[05:36] <kylem> right.
[05:36] <kylem> ok, i'll just bump to 10.28 and upload.
[05:36] <lamont> i386 was ftbfs because of CONFIG_MSS.  ditto hppa
[05:36] <kylem> yes.
[05:36] <kylem> i know, i got the email...
[05:37] <lamont> and I screwed up things for abicheck when I did -10.27
[05:37] <kylem> yeah, it's fine.
[05:37] <kylem> i'd have made the same mistake probably.
[05:37] <lamont> but if you want the history, it's in my tree... :(
[05:37] <kylem> ok, i pulled the patch from your tree
[05:38] <lamont> and I had a -10.28 prepared, but hadn't committed it or uploaded yet...  and now it's your baton.
[05:40] <kylem> lamont, there's nothing wrong with the commit though, right? it will succeed now?
[05:42] <lamont> right
[05:43] <kylem> ok, thanks.
[05:43] <lamont> what I changed but did not commit was: changelog (rename .26,27 to -9), and rename debian/abi/2.6.22-9.25 -> 27
[05:43] <kylem> the odds are astronomically high that i'm goign to fuck this up.
[05:43] <lamont> want me to just upload a .28?
[05:44] <kylem> no, it's fine
[05:44] <kylem> why would you rename the abi?
[05:45] <kylem> there is no abi to compare it to
[05:45] <lamont> ah, good point.
[05:45] <lamont> as long as it's -9.27 for the previous in changelog.  got it.
[05:45] <lamont> EOVERKILL
[05:45] <kylem> yeah, sorry, i should have nuked it when i was preparing it in the first place.
[05:46] <lamont> anyway, sorry for screwing up .27 and making more work.
[05:47] <lamont> and feel free to make that .27 guy lamont@u.c, or not. :-)
[05:54] <kylem> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy.git;a=commitdiff;h=a5691db7134fd4566504a38c3a3d812658452665
[05:54] <kylem> hopefully it doesn't fail because i capitalize urgent or something
[05:56] <infinity> Processing..
[05:58] <infinity> kylem: Processed and approved.
[05:58] <lamont> kylem: as an FYI, debian/rules updateconfigs changes config/i386/*
[05:59] <kylem> yeah
[05:59] <kylem> i expect that
[05:59] <lamont> I expected that you did
[05:59] <lamont> I also noticed that at least one of those config vars was =y and =m in diff config.* files, and merged into =y... 
[06:00] <kylem> hand editing them generally a bad idea
[06:00] <lamont> uh.... that's what I do.  and then I run updateconfigs so that amitk doesn't yell at me.
[06:03] <ogra> BenC, ping
[06:04] <BenC> ogra: ?
[06:04] <ogra> BenC, about bug 130330
[06:04] <ogra> meh, no ubotu :P
[06:04] <ogra> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/130330
[06:04] <ogra> i was told you have concerns with that ?
[06:06] <BenC> ogra: ...
[06:07] <mjg59> ogra: Which hardware?
[06:07] <kylem> i'm working on fixing up alsa on them.
[06:07] <kylem> slowly.
[06:08] <elmo> oh, right, I need to report my feisty-hates-usb bug
[06:08] <ogra> mjg59, kaluha specifically and there is a driver for sis7019 that we dont have but thats available as unlicensed source that needs various bits of the oss stack thats missing as well
[06:08] <mjg59> ogra: Yeah, I think the "unlicensed source" bit is probably more of a problem
[06:09] <ogra> right
[06:09] <mjg59> We shouldn't be distributing kernel options for the sole reason of letting someone breach copyright
[06:09] <ogra> i have it building fine here, but cant use it, its a shame
[06:09] <ogra> well, i think its up to the user and i want to enable them at least to make their HW work
[06:11] <amitk_> ogra: we have worse - a GPL driver that we can't include becase of crazy firmware licensing: http://www.marvell.com/drivers/driverDisplay.do?dId=178&pId=38
[06:12] <BenC> ogra: ah, right...we'll end up re-enabling oss where needed
[06:12] <ogra> amitk_, well, i dont care about inclusion since i wont be able to, but i care that the user can solve it himself ....
[06:13] <amitk_> ogra: point taken
[06:13] <mjg59> amitk_: 2.2(ii) seems to grant permission to redistribute the firmware?
[06:14] <elmo> mjg59: but not sell it, and check out the export/nuclear crack clause towards the end
[06:16] <ogra> BenC, i'll get a list and attach it to the bug .... for now kahlua is the most important one i know of, but i'm sure there are more, these embedded chipsets suck in that regard
[06:16] <mjg59> elmo: It says that we can't sell the firmware, not that we can't sell the product it's incorporated into?
[06:17] <mjg59> elmo: I suspect that the export stuff is a matter of law anyway. I'd go slightly further and suggest that we've never made any real guarantees about anyone's right to use anything in l-r-m
[06:18] <elmo> mjg59: if we sell an Ubuntu DVD with this on it, how is that not selling the firmware?  where does the license make the distinction between the firmware and the product it's integrated into
[06:18] <elmo> mjg59: that export stuff is not a matter of law
[06:18] <elmo> "any party engaged in nuclear, chemical/biological weapons or missile proliferation activities "
[06:19] <elmo> " may not, in the absence of authorization by U.S. and local law and regulations, as required, be used by or exported or reexported"
[06:19] <elmo> is something I can't even parse, but under at least one reading seems to say 'in soviet russia, US law applies YOU'
[06:20] <mjg59> elmo: That section starts "are subject to US export control laws"
[06:20] <mjg59> If authorization by US and local law and regulations /isn't/ required, it sounds fine
[06:21] <elmo> I really don't see how you're reading it that way
[06:22] <elmo> '  In addition to the above' <- above being are subject to US export control laws
[06:22] <elmo> ' may not, in the absence of authorization by U.S. and local law and regulations, as required, [... a whole bunch of prohibitive restrictions] '
[06:22] <BenC> ogra: ok
[06:23] <mjg59> I read that as "You may not do these things without the authorization of US and local law (as required)"
[06:23] <mjg59> Where there's no requirement, you may do them
[06:26] <mjg59> elmo: The "You may not sell this" bit also claims "You may not distribute it", which is clearly at odds with 2.2 - the only way for that to make sense is for it to be fine to distribute or sell it as part of the licensee's product, but not on its own
[06:26] <mjg59> Which is a restriction that we've had on other things in the past
[06:26] <elmo> err, like what?
[06:27] <elmo> oh, you mean selling in aggregrate
[06:27] <elmo> sure we've had that before
[06:27] <mjg59> Yeah
[06:27] <elmo> but I don't buy the whole 'this is the whole sane reading of the license -> we'll use that' argument at all
[06:27] <elmo> we've been bitten by that before with e.g. pine
[06:28] <mjg59> 2.2(ii) makes it clear that you can distribute as part of licensee's product, whereas 2.3(ii) states that you can't distribute the proprietary deliverables
[06:28] <elmo> and we've certainly got a history of rejecting internally inconsistent licenses
[06:29] <mjg59> Heh. Have you guys asked for clarification?
[06:30] <elmo> I dunno - I haven't been dealing with them/don't know who is.  amit?
[06:31] <elmo> 'All Derivatives of the Open Source Deliverables shall be licensed back to Marvell' is another interesting one
[06:31] <infinity> kylem: Old builds killed, new builds on the way.
[06:31] <kylem> thanks hot stuff.
[06:31] <mjg59> elmo: Surely that's an inevitable consequence of them being GPLed?
[06:32] <elmo> not if I don't  distribute it to them, it's not
[06:33] <mjg59> Hm. Yes, I can see that being an issue.
[06:48] <amitk_> elmo: mjg59: I haven't dealt with Marvell directly. I got a request from Pepper to include this driver. And since the license was too much for my comprehension of law, I asked around (mdz, elmo, rtg_)
[06:50] <amitk_> but if you know who has done these sorts of negotiations before, we could take this forward
[06:52] <amitk_> actually it was Mithrandir instead of rtg_
[07:11] <zul> BenC: maybe there should be a wiki page on patches from the community (ie what is needed, etc)
[07:41] <BenC> zul: basically it's the same as upstream kernel
[08:05] <IntuitiveNipple> Anyone familiar with the TCP keepalive code? I'm trying to confirm that code I'm looking at in net/ipv4/tcp_minisocks.c in tcp_check_req() is the bit responsible for sending the keepalive ACK - around line 585 "req->rsk_ops->send_ack(skb, req);"
[08:30] <xhaker_> zul, that bit about patches from the community was related to the patch i linked you earlier? It was mjg59 who did that patch, not me, i just added the /**/ comment
[08:30] <zul> xhaker_: can you update it then
[08:31] <xhaker_> i've added it to my own branch
[08:31] <xhaker_> what info do you need? the commit message?
[08:31] <zul> signed off description etc
[08:32] <xhaker_> can i export my diff with that info attached?
[08:32] <xhaker_> git-*
[08:32] <zul> sure email me it ill try to get it upstream as well
[08:33] <zul> zulcss@ubuntu.com
[08:34] <zul> or even better yet send it to the kernel-team ml
[09:00] <xhaker_> I will do that.. after a reboot
[09:45] <zul> later