[12:49] <darkbyte> Hi all !
[12:50] <darkbyte> Anyone knows how I can recompile the current dapper kernel without modifying version number (2.6.15-26-386) to be able to use the current restricted modules available ?
[12:52] <crimsun> sorry, but the question's confusing. Why would you need to recompile the current Dapper kernel to use the current [Dapper]  l-r-m?
[12:54] <darkbyte> I need to modify the ide-probe.c driver file to be able to use a Promise TX4 card with my VIA chipset motherboard. And I would to use as much as posible of the repository packages, as the linux restricted modules.
[12:54] <darkbyte> If I can rebuild the kernel only with the patched ide driver I don't need to touch enything else.
[12:56] <crimsun> do said modifications to ide-probe.c export additional symbols or anything of the like? If so, you'll still need to bump the ABI, which means you'll end up recompiling l-r-m
[12:56] <darkbyte> I only need to comment 3 lines of code
[12:57] <crimsun> then just recompile using the infrastructure you get via ``apt-get source linux-image-$(uname -r)''
[12:57] <crimsun> it's documented on the wiki (see topic) afair
[12:58] <darkbyte> I don't see this (glups) ...
[01:00] <darkbyte> downloading rith now, thanks crisum a try it ...
[01:01] <darkbyte> right, I try
[07:52] <crimsun> BenC: hi, hope the tourney went well. The patches sent to the list should be applied to Dapper's and Edgy's linux-sources. There are enough fixes in alsa's tree that syncing the aoa driver to Edgy's linux-source is recommended.
[08:31] <TheMuso> C
[12:57] <thom> right, i guess i get to find out in a while whether i've fixed #37452 finally
[01:19] <rodarvus> BenC, ping
[02:31] <zul> hey
[02:49] <zul> BenC: how was the tournament?
[03:32] <BenC> rodarvus: pong
[03:32] <BenC> zul: didn't play the tournament, just played for some cash
[03:33] <rodarvus> BenC, I have two FTBFS, depending on (theoretical) updates to l-k-h, do you think you can spend some time on these issues today? (or soon)
[03:34] <rodarvus> in both cases, missing include files
[03:34] <rodarvus> BenC, I talked with fabbione last week, but he wanted to talk to you, before adding/changing stuff on l-k-h
[03:35] <rodarvus> BenC, http://librarian.launchpad.net/3640193/buildlog_ubuntu-edgy-sparc.xorg-server_1%3A1.1.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[03:35] <rodarvus> and
[03:35] <rodarvus>  gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -Wall -Wall -g -O2 -DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -I/usr/include/xorg -I../../src -MT evdev_drv_la-evdev.lo -MD -MP -MF .deps/evdev_drv_la-evdev.Tpo -c ../../src/evdev.c  -fPIC -DPIC -o .libs/evdev_drv_la-evdev.o
[03:35] <rodarvus> In file included from ../../src/evdev.c:66:
[03:35] <rodarvus> ../../src/evdev.h:74:24: error: asm/bitops.h: No such file or directory
[03:35] <rodarvus> ../../src/evdev.c: In function 'EvdevReadInput':
[03:35] <rodarvus> ../../src/evdev.c:95: warning: format '%ld' expects type 'long int', but argument 6 has type 'unsigned int'
[03:35] <rodarvus> ../../src/evdev.c: In function 'EvdevParseBits':
[03:35] <rodarvus> ../../src/evdev.c:348: warning: implicit declaration of function 'set_bit'
[03:35] <rodarvus> make[3] : *** [evdev_drv_la-evdev.lo]  Error 1
[03:36] <rodarvus> (the second one was from xserver-xorg-input-evdev, which I didn't uploaded yet, due to the FTBFS be happening on all archs)
[03:40] <rodarvus> the two are rather serious: the first prevents xorg-server (and and thus *all* drivers) to be built on sparc
[03:40] <rodarvus> the second basically prevents anyone from using evdev on current Edgy
[03:40] <zul> BenC: ah cool..
[03:41] <BenC> rodarvus: ok, I can fix that
[03:43] <BenC> rodarvus: bitops.h is a bogus include
[03:44] <BenC> well, it is on some arch's anyway
[03:44] <BenC> on sparc, it's wrapped in __KERNEL__, so it's blank
[03:44] <BenC> if all it's using is set_bit(), then evdev should just define that locally using a generic one
[03:46] <BenC> rodarvus: look in include/asm-generic/bitops/atomic.h for a version of set_bit that evdev.c can use locally
[03:47] <BenC> rodarvus: as for kbio.h:
[03:47] <BenC> $ find include/ -name kbio.h
[03:47] <BenC> $
[03:48] <BenC> there is no such file, so that definitely is bogus
[03:50] <rodarvus> BenC, so just remove asm/kbio.h from xorg-server, then?
[03:51] <BenC> yeah
[03:51] <rodarvus> BenC, I'll do it - thanks!
[03:55] <infinity> BenC: Have you tried to push -fno-stack-protector upstream yet?
[03:56] <infinity> BenC: It'd be swell if upstream sources built on the edgy toolchain unmodified by the time we release.
[03:58] <BenC> infinity: someone grabbed it from Ubuntu source and sent it upstream, but I don't know if it got accepted
[04:01] <zul> there was a patch to fix the kernel so it can compile with ssp
[04:01] <zul> hey jeff
[04:02] <jbailey> Heya Zul
[04:02] <jbailey> There was something you asked me the other day.
[04:02] <jbailey> hmm
[04:02] <zul> the xen stuff..
[04:02] <jbailey> I replied, and someone else had stolen your nick  /me checks for logs.
[04:02] <jbailey> Right!
[04:03] <jbailey> I confused some guy because he wanted to know why a stranger was asking for straces of ls on his bsd system.
[04:03] <zul> hmmm..
[04:03] <zul> thats weird
[04:04] <jbailey> I'll paste the conversation to you.  It was amusing.
[04:04] <zul> heh ok
[04:06] <BenC> I had to switch my nick to secure because if I'm off for > 12 hours, there's always this same guy that grabs my nick and I end up having to /kill him from nickserv
[04:06] <zul> jbailey: lol
[04:06] <jbailey> BenC: Is that the auto-kick if you don't identify stuff?
[04:07] <zul> same here..
[04:07] <BenC> jbailey: if I understand correctly, /m nickserv set secure on, makes it so you have to identify or you get /kill'd
[04:07] <jbailey> Nice!  I should set that.
[04:08] <BenC> I should let one of you guys take my nick for a minute to see if it works :)
[04:09] <jbailey> Sure.  I'll use my jb-home account.
[04:10] <BenC_> jbailey: ok
[04:10] <benc> -NickServ- This nickname is owned by someone else
[04:10] <benc> -NickServ- If this is your nickname, type /msg NickServ IDENTIFY <password>
[04:10] <benc> So let's see. =)
[04:11] <BenC_> it's been > 60 seconds
[04:11] <infinity> This feature seems lacking.
[04:12] <BenC_> very
[04:12] <infinity> Yay!
[04:12] <BenC_> lol
[04:12] <benc> Even that wasn't enough to shock the system into working
[04:12] <benc> Clearly defective.
[04:12] <BenC_> specially, darwin :)
[04:12] <thom> BenC_: 15:12 <thom> set kill on
[04:12] <thom> 15:12 -NickServ(NickServ@services.)- Kill Protection is disabled on this network
[04:12] <benc> Suck
[04:13] <thom> so i don't think secure on will kill, regardless
[04:13] <zul> need to reboot again
[04:14] <jbailey> zul: Send me the strace, please ;)
[04:14] <BenC> that sucks because this same guy is always taking my nick if I disconnect for a half a day or more
[04:14] <BenC> and I /kill him everytime and he doesn't seem to get it...to not, like, use my nick and such
[04:15] <jbailey> thom, infinity: Hello btw. =)
[04:15] <BenC> maybe he's just a masochist
[04:15] <infinity> BenC: Same thing happens to me.  Always the same guy as well.
[04:15] <infinity> But in my case, I'm usually connected for weeks at a time.
[04:15] <infinity> And if I'm off for more than a few minutes, he's got my nick.
[04:16] <BenC> same here...it's just times like when I travel
[04:16] <infinity> Bizarrely antisocial behavious.
[04:16] <infinity> behaviour, too.
[04:16] <thom> infinity: irc
[04:16] <infinity> thom: yeah, but it's not eactly efnet.
[04:16] <BenC> hehe...efnet
[04:16] <thom> infinity: true 'dat
[04:17] <BenC> it's strange that I can go on there every few months or so and see ppl that I used to chat with 6-7 years ago still hanging out in the same channels
[04:17] <infinity> it's hard to give up one's channel list.
[04:18] <infinity> I have a 25 year old friend who still hangs in "#12-15teenz", cause he founded it (ironically, when we was 11)
[04:18] <BenC> lol
[04:19] <BenC> those are the kinds of channels just begging for pedaphiles :)
[04:20] <infinity> I'm pretty sure no one in there is 12-15 anymore, since it's been the same group of friends from around the globe since its inception, and no one else seems to poke their heads in.
[04:20] <infinity> THough I made the same comment, when I first saw it on his channel list.
[04:21] <zul> jbailey: once i get it working :)
[04:57] <BenC> mdz: ping
[04:57] <mdz> BenC: pong
[05:09] <BenC> mdz: nm, you replied via email
[05:09] <BenC> thanks
[05:14] <jbailey> BenC: BTW,  last kernel I tried on the G5 still had the sata_ whatever problem and the kernel panic (if you turn off quiet and splash)
[05:15] <jbailey> BenC: Got magic smoke out the back of the power supply on Friday, though, so it might be a bit before I can test again.
[05:15] <jbailey> I had planned this weekend to copy down the oops and post it.  Oh well.  =/
[05:19] <kbyrd> mdz: just got your email.
[05:19] <BenC> jbailey: ok
[05:19] <mdz> kbyrd: welcome
[05:20] <kbyrd> thanks. 
[05:20] <kbyrd> So, I completely misunderstood the l-r-m packages. I thought it was a single user-installable package containg a bunch of .ko files.
[05:21] <BenC> kbyrd: mostly it is, but we can create separate module .deb's from it if needed
[05:22] <kbyrd> perfect. 
[05:22] <mdz> kbyrd: currently it builds one binary package per kernel ABI containing kernel modules, plus a few extra things (like X drivers) which aren't tied to a kernel ABI
[05:22] <BenC> but being built from a common source package means we can keep the ABI in sync more easily
[05:23] <mdz> kbyrd: what will complicate things is needing to keep things in sync as the kernel ABI changes
[05:23] <kbyrd> That sounds like the right spot then. The player package we handed off to mvo builds both a binary and source package (so people can use module-assistant)
[05:23] <mdz> kbyrd: we handle that with metapackages built from linux-meta which pull in the rgiht versions
[05:23] <mdz> this will mean two additional metapackages for the vmware modules, which is doable but not very convenient
[05:24] <kbyrd> Since there is not vmware-server yet (our legal team is doing it's thing right now), what can I do to help get vmware-player-kernel in the l-r-m build?
[05:25] <infinity> Fix the license to not require a click-through.
[05:25] <infinity> That's the only thing preventing me from rolling it in.
[05:26] <infinity> Cause I refuse to require a click-wrap on all of LRM, for the sake of one module.
[05:26] <kbyrd> I didn't do the original player-kernel package, I didn't realize the player-kernel package had a EULA. That's not right. 
[05:26] <infinity> (Well, fix the license, fix your policy regarding the license, whichever. :))
[05:26] <kbyrd> inifinity: I agree. 
[05:27] <infinity> The guy who originally did the packaging was told from on high that he had to do it that way.  He also violently disagreed with the whole idea.
[05:27] <kbyrd> So, we'll still have a click thru on vmware-player, just not on vmware-player-kernel. That work?
[05:27] <infinity> Yeah, that would be fine.
[05:27] <kbyrd> Yea, we're fighting that from that ground up.
[05:27] <infinity> I'd be happy to roll it into LRM as soon as we can do so, which was discussed in the dapper cycle.
[05:28] <kbyrd> (maybe we'll get the modules open sourced here if we get what we want).
[05:28] <kbyrd> but not soon.
[05:28] <infinity> It would be amazingly cool if the modules were not only open-sourced, but shared a common code-base between player/workstation/server, but that'll be a while to co-ordinate, I suspect.
[05:28] <infinity> (Cause it would be pretty cool if we shipped the "right modules" out of the box for any of your products)
[05:30] <kbyrd> infinity: For us, those are two different problems. VMware has never had a good, co-install story. The code is all very similar, just different branches for QA / support reasons.
[05:30] <infinity> Yeah, I know, I've discussed this in the past. :)
[05:30] <infinity> But it's a shame, that's all.
[05:30] <kbyrd> embarrassing actually.
[05:31] <kbyrd> When I've got a non-click thru vmware-player-kernel package source, should I just come back here?
[05:31] <kbyrd> thanks all.
[06:02] <BenC> wow, we are totally not ready to have ubuntu work on pSeries machines...having trouble even doing a boot with our stuff that expects a lot of mac'isms
[06:03] <zul> BenC: send me one and i can help ;)
[06:15] <mdz> BenC: any objection to me tightening the linux-meta dependencies as discussed?  it only affects the top-level metapackages which depend on -image-foo and -restricted-modules-foo
[06:16] <mdz> BenC: also, can we make linux-686-smp and linux-k7-smp transitional packages now?  they seem obsolete
[06:18] <BenC> mdz: yeah, sounds good
[06:28] <kbyrd> infinity: you around?
[06:34] <kbyrd> anyone else then... Earlier, infinity said the thing holding up vmware-player-kernel being built as part of l-r-m was that it had a click-thru EULA. I just downloaded the package and checked it out. I found nothing requiring user interaction. I bet we had something like this originally, but it's not in the current version. There is still a click-thru EULA for vmware-player, just not the kernel mod
[06:34] <kbyrd> ules. 
[06:43] <BenC> kbyrd: if that's the case, then we can just pull it into lrm for edgy no problem
[06:45] <kbyrd> BenC: 1) Can one of you confirm I'm not crazy? If I'm wrong, I'd rather find out now and fix it now. 2) Is there any way to get it done before the next kernel ABI update for Dapper? 
[06:46] <BenC> doubtful that it will happen for dapper
[06:48] <BenC> I just need to add vmware modules to my list of things to update for dapper kernel ABI bumps...but since those wont happen very often (if ever again), then I don't expect it to be a problem there
[06:49] <kbyrd> BenC: hmmph. Ok, any way to get notified when an kernel ABI change is in the queue for Dapper before  it hits the repository?
[06:51] <kbyrd> That "ever again" thing worries me. Since it happened twice pretty quickly so far. 
[06:51] <kbyrd> Since you said that out loud, it's sure to happen again ;-)
[06:51] <BenC> that's because we had a lot of updates for dapper that just didn't make release
[06:52] <BenC> heh, well, even if it does, we always get it our within a day or two of the update, or likely at the same time now
[06:54] <kbyrd> Cool, thanks. Ok, last thing for now. Is someone looking at my *-9 update that I sent last week? That'll fix the  bug about module-assistant builds not working.
[06:56] <BenC> ping zul, he did the last few uploads of the modules, which by law makes him responsible for everything after that with the package :)
[06:58] <kbyrd> Nice, sort of like when I comment on some code in our source. I'm forever destined to fix all future bugs about it even it it's not my code.
[06:59] <BenC> you've experienced this development model before...excellent :)
[07:00] <kbyrd> I just msg'd zul, is his email @ubuntu.com as well?
[07:01] <BenC> zulcss@gmail.com I think
[07:23] <zul> or zulcss@ubuntu.com
[07:26] <zul> since when was i responsible :)
[07:39] <thom> BenC: wrt #37452 i at least have a built kernel with the two patches i mention. I'll test them tomorrow morning.
[07:42] <BenC> thom: ok
[07:43] <zul> BenC: oh yeah im entering in a tournament tonight
[07:43] <BenC> private or casino?
[07:43] <BenC> or online?
[07:44] <zul> casinoish...its at a restatunt/bar
[07:44] <zul> i should last about an hour ;)
[07:46] <BenC> is it a freeroll?
[07:50] <zul> yeah
[07:53] <BenC> ah, those are mainly an all-in fest
[07:53] <BenC> no skill involved :)
[07:54] <zul> yeah but i rather play live than online
[07:54] <BenC> play tight...if you get aces, just go all-in, someone will call you
[07:54] <BenC> no doubt
[08:09] <jbailey> BenC: Did you read about the world strip poker championships going on next month?
[08:10] <jbailey> I have a feeling that's one tournament I wno't watch...
[08:10] <zul> if they have women in it i would watch
[08:10] <BenC> heh, I imagine I wont be watching it either :)
[08:11] <BenC> High Stakes Poker on Game Show Network has become my new Poker TV addiction
[08:11] <BenC> it's much more exciting and the game play is much more realistic to what you normally see in a live game
[08:12] <BenC> ppl watching World Poker Tour and WSOP tend to think you play poker just like those guys, but it's a totally different situation than most poker games that ppl play :)
[08:12] <jbailey> Right.  As opposed to "Let the bear win" type of strategy. =)
[08:38] <mdz> BenC: any reason to keep l-s-2.6.15 and l-r-m-2.6.15 around in edgy?
[08:47] <BenC> mdz: none
[08:49] <mdz> BenC: please request their removal via ubuntu-archive then, so that we don't forget before the release and pitti doesn't cry
[08:50] <BenC> mdz: ubuntu-archive@lists.ubuntu.com?
[08:50] <mdz> BenC: file it in Malone and subscribe ubuntu-archive to the bug
[08:51] <BenC> ok
[08:55] <BenC> mdz: done
[08:56] <mdz> thanks
[09:26] <zul> ouch...BLK_LOOP is compiled into the kernel
[10:10] <jbailey> BenC: Got a checkout of reasonably current upstream git handy and a sec to look something up for me?
[10:11] <zul> later folks
[10:11] <jbailey> g'n chuck
[10:32] <BenC> jbailey: sure
[10:33] <jbailey> BenC: I managed to trace it, sorry for the noise.
[10:40] <BenC> np
[11:10] <makx> hmm bogl uses PAGE_SIZE inside of asm/page.h
[11:10] <makx> is that still exported?
[11:15] <BenC> there's nothing in it
[11:15] <BenC> at least not on ppc
[11:16] <makx> yup it's failing to build on ppc debian buildd
[11:17] <BenC> PAGE_SIZE is a little ambiguous on ppc
[11:18] <BenC> depends on 32-bit or 64-bit kernel, so even if it's 32-bit userspace, if you are really concerned about what the kernel is using, then you cannot be sure
[11:18] <BenC> I suggest getpagesize(2)
[11:19] <makx> yup will do
[11:21] <jbailey> live checks, good. =)