[00:45] <mkrufky> mrec__: might be a good idea for you do to a DKMS package
[00:45] <mkrufky> mkrufky: and make your package remove any pre-existing em28xx
[00:45] <mkrufky> oops, i meant mrec__ ^
[00:46] <mkrufky> i *highly* suggest using the in-kernel dvb-core rather that installing your own... otherwise you'll break somebody else's driver
[00:47] <mkrufky> i did this by using the headers in /lib/modules/`uname -r`/build/drivers/media/dvb/dvb-core/*.h
[00:47] <mkrufky> ...and you can depend on their presence if you are doing a DKMS build
[02:20] <apt_get> Hi
[10:36] <BenC> fair warning...rebasing on -rc6 now, so I would hold off pushing anything to the repo
[10:42] <BenC> rtg: -rc6 included a fix to xen/time.c...different than mine, but fixed the same problem
[10:42] <BenC> so it wasn't just us
[10:43] <rtg> BenC: cool. how did they fix it?
[10:46] <BenC> rtg: They used iter_div_u64_rem()
[10:50] <rtg> BenC: gotta go. home gain, home again, jiggety jig.
[12:41] <maks_> what's the irc nick of tim gardner?
[12:43] <amitk> maks_: it is 'rtg'
[12:43] <maks_> ok thanks
[12:43] <maks_> rtg f448b9a70cda0ed9878db485de30363f9c9db6e1 is a dup
[12:43] <maks_> you'll find the same entry below in blacklist with proper desc
[12:49] <maks_>  speaking of ubuntu hardy tree, as you might have guessed ;)
[12:49] <maks_> hmm rtg is not here
[12:49] <maks_> will repost
[13:41] <pgraner> maks_: rtg is traveling today, he will be back online prob Monday
[14:51] <BenC> mjg59: Do you recall this patch: hostap: send events on data interface as well as master interface
[14:52] <BenC> mjg59: I'm wondering if it's still needed
[14:52] <mjg59> I expect so, but haven't tested
[15:02] <BenC> mjg59: is it something that should go upstream?
[15:02] <mjg59> Conceivably
[15:02] <mjg59> Probably best to check it with Dan Williams
[15:03] <BenC> Ok
[15:04] <BenC> -rw-r--r-- 1 bcollins bcollins 48234 2008-06-13 09:45 ubuntu-stuff.diff
[15:04] <BenC> That our current delta against 2.6.26-rc2
[15:05] <BenC> good chunk of that is vesafb modular
[15:05] <BenC> err, 2.6.26-rc6
[15:30] <qense> Can someone help me out a bit with bug 222703?
 Launchpad bug 222703 in linux "Suspend fails after first time" [Undecided,Incomplete] https://launchpad.net/bugs/222703
[15:31] <qense> I can't determine the cause
[15:31] <qense> should I just mark it as confirmed and leave it to you, or do you want some more informaton?
[18:02] <pgraner> BenC: ping
[18:03] <BenC> pgraner: Yes?
[18:03] <pgraner> BenC: hey, I want to work on a adding a patch and building. Specifically this one http://marc.info/?l=linux-usb&m=121080766320582&w=4
[18:04] <pgraner> BenC: its upstream and I actually need it I'd like to build a custom pkg just for me. Where do we start, I can't seem to find the one page to get me started.
[18:06] <munckfish> pgraner: https://wiki.ubuntu.com/KernelTeam/KnowledgeBase
[18:06] <munckfish> KernelMaintenance page has a lot of good info
[18:07] <munckfish> or
[18:07] <munckfish> https://help.ubuntu.com/community/Kernel/Compile
[18:07] <smb_tp> pgraner: If you want a patch on top of the current git in a ppa, I could push you a script as well
[21:18] <kees> kirkland: (switching here) yeah, I think the problem is discussed in the bug you found
[21:18] <kirkland> kees: the problem that pitti mentioned?
[21:19] <kees> (95089)  yeah
[21:19] <kirkland> okay, i've asked Serge Hallyn to add some comments to the bug
[21:20] <kirkland> kees: in case there's something we're missing
[21:21] <kees> kirkland: yeah, it wasn't entirely obvious to me, but after looking at CAP_SETPCAP, I tended to agree with pitti.
[21:21] <kees> kirkland: if CONFIG_SECURITY_FILE_CAPABILITIES could operate without it, that'd be nice
[21:21] <kirkland> kees: right, i think hallyn will be able to clarify what is/isn't possible
[21:24] <kees> if you look at the code for where CAP_SETPCAP is defined, it is clearly ifdef'd with CONFIG_SEC.._FILE_CAP.. but I don't know why
[21:26] <kirkland> kees: hallyn added some info to https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/95089
[21:27] <kees> heya hallyn, thanks for the details -- this is an area I'm much less familiar with.  :)
[21:28] <hallyn> np
[21:28] <hallyn> i'm not quite clear on the history
[21:29] <hallyn> at the start of the thread, were file capabilities enabled and cap-setpcap turned off, or was it just a regular kernel without file capabilities?
[21:30] <kees> hallyn: I'm a bit unclear myself.  I think the issue is with the #ifdefs that seem to allow CAP_SETPCAP when CONFIG_SEC.._FILE_CAP..=yes
[21:30] <kees> and without additional context, it seems dangerous
[21:30] <hallyn> is there a gitweb site or something where i can see the current code and .configs for default builds?  I assume not, just would be kick-ass if so...
[21:30] <kees> there is, yes, kernel.ubuntu.com
[21:30] <mjg59> kees: Should get to your libx86 stuff next week, I've just got nv40 suspend/resume working
[21:30] <mjg59> (without any libx86 stuff. Hurrah!)
[21:31] <hallyn> kees: cool!  thanks.
[21:31] <kees> mjg59: nice!  how does it work without need to talk to the bios??
[21:31] <kees> hallyn: current hardy: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=summary current intrepid: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=summary
[21:31] <mjg59> kees: Uses nouveau's bios table interpreter
[21:32] <hallyn> kees: yes, seeing cap-setpcap enabled would set off warning bells :)  though we did try to comment it in include/linux/capability.h
[21:32] <kees> mjg59: niiiice.  I'm so glad that project is coming along.
[21:32] <mjg59> kees: nvidia and AMD both have tables that are used by the drivers, and just have a small x86 interpreter for it that sits in the bios
[21:33] <mjg59> Execute the init table, restore a couple of magic values that would be programmed by the platform bios, run the lvds init code, restore the registers and wham!
[21:33] <hallyn> kees: excellent, so I can take a look at the apparmor/caps integration.  What about .configs?  available?
[21:33] <mjg59> An entirely broken console, but working X
[21:33] <kees> hallyn: the configs are in the debian/configs directory
[21:33] <hallyn> excellent
[21:34] <kees> hallyn: though depending on build options, they are merge together.  other folks here might be more helpful in describing that, though.
[21:34] <kees> hallyn: so, in comment 4, pitti is correct?
[21:36] <kees> hallyn: this page may be useful for you as well, if you're going to build modified ubuntu kernels: https://help.ubuntu.com/community/Kernel/Compile
[21:37] <hallyn> kees: was hoping not to build, just figure out the state of the current kernel
[21:38] <hallyn> i.e. i'm afraid one or two apparmor lines may need tweaking
[21:39] <kees> hallyn: that's fine -- intrepid doesn't have apparmor in it yet, I'm waiting for upstream to finish their port to the current linus tree.
[21:39] <kees> hallyn: but they're quite responsive about patches
[21:39] <hallyn> kees: pitti == martin pitt?  If so, he's only right if CONFIG_SECURITY_FILE_CAPABILITIES=n
[21:39] <kees> hallyn: check in on oftc in #apparmor
[21:39] <kees> hallyn: okay.  so if I boot a CONFIG_SECURITY_FILE_CAPABILITIES=y kernel, I should still get the same output he's showing?
[21:40] <hallyn> kees: no, bc cap_setpcap should then be in root's sets
[21:40] <hallyn> kees:  "debian/configs directory" -> can' tfind it, what is the url?
[21:41] <kirkland> hallyn: is there a potentially security vulnerability if CONFIG_SECURITY_FILE_CAPABILITIES=n ?
[21:41] <kees> hallyn: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=tree;f=debian/config;hb=HEAD
[21:41] <kees> hallyn: pitti seems to be saying that have cap_setpcap in root's sets is, in itself, dangerous.
[21:44] <hallyn> kees: cap_setpcap means something different if file caps are on
[21:45] <hallyn> kirkland: do you mean if cap_setpcap is allowed?  yes.
[21:45] <kees> ah-ha -- that's the piece that wasn't obvious to me.
[21:45] <hallyn> kees: so yes it looks like apparmor would need some changes - at least for setxattr - to support file caps.  
[21:45] <hallyn> I'll look at it some more next week.
[21:45] <kees> hallyn: I'm sure they'd be open to it.
[21:45] <kees> hallyn: okay, cool.
[21:46] <hallyn> kees: where would I send a patch?
[21:46] <hallyn> i guess i can just join #apparmor next week
[21:47] <kees> hallyn: yeah, that's probably the best place to start
[21:47] <kees> hallyn: they have some public mailing lists too, but IRC is good.  If you don't get any response, email me and I'll go ping them directly via email.
[21:49] <hallyn> ok, thanks.
[21:50] <kees> cool, thanks for digging into this -- I've been curious about what was needed for sane filecap support but hadn't had time to look into it.
[21:52] <kirkland> kees: hallyn: hey, thanks for taking the time to connect
[22:11] <dupondje> 'Collin King' happen to be here ? :)
[22:30] <dupondje> somebody here that is able to include a patch into Hardy kernel ? :(
[22:34] <kees> dupondje: best to open a bug report with the details and the patch
[22:35] <dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/235889
[22:35] <dupondje> enjoy
[22:35] <dupondje> :)
[22:36] <kees> dupondje: looks like it's already being discussed there.  :)
[22:36] <dupondje> its taking such a huge time to get solved :(
[22:36] <dupondje> the patch is there
[22:36] <dupondje> I tested it .. it works :(
[22:37] <kees> hallyn: if you're still around, jjohansen is one of the AppArmor upstreams.
[22:37] <hallyn> thanks kees
[22:38] <hallyn> jjohansen: i haven't look at it enough, but i think in order for apparmor (in ubuntu) to work with filecaps, apparmor will need a few tweaks, such as calling the cap setxattr hook
[22:40] <kees> dupondje: it can take time -- but it looks like it's progressing.
[22:40] <jjohansen> yes, the apparmor hook needs to call cap_inode_setxattr its a fix that is pending
[22:41] <infinity> dupondje: The hardy kernel is currently frozen for the 8.04.1 point release, but I suspect your patch and bug will be addressed shortly after that.
[22:41] <hallyn> jjohansen: oh ok, saves me some time :)  thanks
[22:41] <infinity> dupondje: I also have a patch queued for after the point release.  I realise it's frustrating, but QA processes just can't allow for last-minute changes. :/
[22:41] <jjohansen> hallyn: np.
[22:42] <dupondje> its a fucking deathlock :( kinda important
[22:42] <dupondje> that controller is used in ALOT of servers
[22:42] <infinity> dupondje: Swearing won't help much, nor will it make us delay a point release for a bug (no matter how important that bug may be to some people)
[22:45] <dupondje> I know, but I just think its kinda an important bug, as its a verry common used controller in servers
[22:46] <dupondje> if your server in a datacenter crashes because of it, its not that funny :)
[22:50] <infinity> I never claimed it was funny.  Just that, unfortunately, we have release priorities that mean that you might have to carry a local patch/fork for a bit until after 8.04.1 is out (much like I also have to).
[22:50] <dupondje> when is 8.04.1 comming out tho ?
[22:52] <infinity> It's scheduled for end-of-month, barring any massive setbacks.
[22:52] <infinity> Because the devel team is split between intrepid and hardy right now, the hardy point release test cycles are long and careful.
[22:53] <dupondje> what they test btw ? :p
[22:53] <dupondje> I just test its not working good ;)