=== Traxer|off [i=traxer@shell6.powershells.de]  has joined #ubuntu-kernel
[12:37] <infinity> Is the kernel planning on liking gcc4 well enough to be stable for 5 years?
[12:37] <infinity> And is it going to do so in the next month?
[12:37] <infinity> If not, I think we're stuck with gcc3.4 :)
=== TheMuso [n=luke@dsl-202-173-132-131.nsw.westnet.com.au]  has joined #ubuntu-kernel
=== crimsun_ [i=crimsun@pdpc/supporter/silver/crimsun]  has joined #ubuntu-kernel
=== zul [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
[01:40] <zul> everninng
=== doko_ [n=doko@dslb-084-059-064-213.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== _maydayjay_ [n=maydayja@ip101109.101.nas.net]  has joined #ubuntu-kernel
=== JaneW [n=JaneW@wbs-146-167-38.telkomadsl.co.za]  has joined #ubuntu-kernel
=== JaneW [n=JaneW@wbs-146-167-38.telkomadsl.co.za]  has joined #ubuntu-kernel
=== Yagisan [n=jamie@60-240-74-97-nsw-pppoe.tpgi.com.au]  has joined #ubuntu-kernel
=== _native_ [n=intuit@cpe-66-87-4-181.ut.sprintbbd.net]  has joined #ubuntu-kernel
=== _native_ [n=intuit@cpe-66-87-4-181.ut.sprintbbd.net]  has left #ubuntu-kernel ["Leaving"] 
=== Yagisan [n=jamie@60-240-204-233.tpgi.com.au]  has joined #ubuntu-kernel
[02:37] <zul__> everybody still on holiday?
[02:37] <fabbione> hey zul
[02:39] <BenC> hey
[02:39] <fabbione> hey Ben
[02:40] <fabbione> BenC: i finally got the git export properly
[02:40] <BenC> fabbione: cool
[02:40] <fabbione> but i can't manage to push it to my server
[02:40] <fabbione> David was talking about gitd or rsync
[02:40] <fabbione> but git push rsync:// farts on me
[02:40] <BenC> why doesn't git push ssh:// work?
[02:41] <fabbione> Cannot push to rsync://
[02:41] <fabbione> there is a specific exception in git-push script
[02:41] <fabbione> no idea why
[02:41] <BenC> what does it say when you do "git push ssh://people.ubuntu.com/..." ?
[02:42] <fabbione> i can try that.. gimme a sec
[02:42] <BenC> make sure you supply ubuntu-2.6.14 after the url, so it pushes the right branch
[02:42] <fabbione> ssh: ssh: Name or service not known
[02:42] <BenC> show me your command line?
[02:43] <BenC> git-send-pack people.ubuntu.com:/home/bcollins/public_html/repos/ubuntu-2.6.git ubuntu-2.6.14
[02:43] <fabbione> AHHH
[02:43] <BenC> give that a try aswell
[02:43] <fabbione> git push ssh://rookery.warthogs.hbd.com/
[02:43] <fabbione> fatal: / doesn't appear to be a git directory
[02:43] <fabbione> Killed by signal 1.
[02:43] <fabbione> fatal: unexpected EOF
[02:43] <BenC> git push ssh://people.ubuntu.com//home/bcollins/public_html/repos/ubuntu-2.6.git ubuntu-2.6.14
[02:44] <BenC> that is the right push line
[02:44] <fabbione> that's if i want to push into your archive... right?
[02:44] <fabbione> what if i want to branch...
[02:44] <fabbione> and expose my archive for you to pull from
[02:44] <BenC> then use your branch name at the end
[02:45] <BenC> git branch fabbione-2.6.14
[02:45] <fabbione> ok..
[02:45] <BenC> git checkout fabbione-2.6.14
[02:45] <BenC> (do work)
[02:45] <BenC> then push
[02:45] <fabbione> so we need to land into the same repo
[02:45] <fabbione> i cannot publish it let say in my home dir on people
=== fabbione is utterly confused by git atm
[02:45] <BenC> yeah, you can do that aswell
[02:46] <BenC> hold a sec...
[02:46] <fabbione> sure
[02:47] <BenC> git clone -n -l -s /home/bcollins/public_html/repos/ubuntu-2.6.git fabbione-2.6.14
[02:47] <BenC> mv fabbione-2.6.14 fabbione-2.6.14.git
[02:47] <BenC> do that on rookery
[02:47] <BenC> and it will create a git repo for you with shared objects with mine (reduces space usage)
[02:47] <BenC> then you can push your stuff there
[02:48] <BenC> mv fabbione-2.6.14/.git fabbione-2.6.14.git
[02:48] <BenC> use that line second
[02:51] <fabbione> ok it seems to work
[02:51] <fabbione> i don't need a real branch
[02:51] <fabbione> just the option to work on the same tree
[02:51] <fabbione> but push to you async for crack
[02:52] <fabbione> error: remote 'refs/heads/ubuntu-2.6.14' object 180a764cccdd44c16050c25716a9f814c1955a47 does not exist on local
[02:52] <fabbione> crap
[02:53] <fabbione> git push ssh://rookery.warthogs.hbd.com/home/fabbione/public_html/archives/fabbione-2.6.14.git ubuntu-2.6.14
[02:53] <fabbione> so i didn't change branch.. just pushing like you said
[02:55] <BenC> hold a sec
[02:55] <fabbione> sure
[02:55] <BenC> ah
[02:55] <BenC> do a pull
[02:56] <fabbione> done i am already in sync
[02:56] <BenC> still getting the message?
[02:56] <fabbione> trying again
[02:56] <fabbione> take into account that i did this in my tree
[02:56] <BenC> it's saying that a revision on the remote doesn't exist in your local copy
[02:56] <fabbione> pull from you
[02:57] <fabbione> ok.. let me explain what i did first
[02:57] <fabbione> pull from you
[02:57] <fabbione> pull from linus
[02:57] <BenC> where did you clone from?
[02:57] <fabbione> pull from davem
[02:57] <fabbione> you
[02:57] <fabbione> i did clone from you
[02:57] <BenC> why the pull from linus and davem?
[02:58] <fabbione> BenC: for fun? i need to stretch my wings on git
[02:58] <fabbione> and then i want to publish this tree somewhere else other than your
[02:58] <fabbione> since i don't want to mess it up
[02:59] <BenC> ok, you're going to need to take your local .git/ directory and copy it to rookery
[02:59] <BenC> make that your initial repo and push to it
[02:59] <fabbione> oook..
[02:59] <fabbione> that's crack :)
[03:00] <BenC> it's weird that your missing an object that the remote has :)
[03:01] <fabbione> $ cd linux-2.6
[03:01] <fabbione> $ rsync -a --verbose --stats --progress \
[03:01] <fabbione>    rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
[03:01] <fabbione>    .git/
[03:01] <fabbione> this is according to the guide.. could it make sense that we need to do it from you too?
[03:02] <fabbione> actually.. no i want to get this right in the right way
[03:02] <fabbione> not with hacks
=== fabbione kills his local repos
[03:02] <BenC> yeah, that guide is for ancient git bins
[03:03] <BenC> me personally, I did "git clone ssh://people.ubuntu.com/home/bcollins/public_html/repos/ubuntu-2.6.14"
[03:03] <fabbione> git clone ssh://rookery.warthogs.hbd.com/home/bcollins/public_html/repos/ubuntu-2.6.git ubuntu-2.6.14
[03:04] <fabbione> starting from here now
[03:04] <BenC> then I did some work, and periodically I do "git push"
[03:04] <fabbione> yes, but you push in your own archive :)
[03:04] <fabbione> that's already there
[03:04] <BenC> actually, what you want first is to do the local clone on rookery
[03:04] <BenC> then on your desktop do the clone from your personal git repo
[03:05] <fabbione> right
=== BenC writes all this down for the doc
[03:05] <fabbione> BenC: we also need to think one second how do we want to keep pathes in git
[03:05] <fabbione> i don't think .dpatch is efficent anymore
[03:05] <fabbione> not if we want to push changes upstream
[03:06] <BenC> as of this moment, everything is going to be in the repo
[03:06] <BenC> no patches, directly applied
[03:06] <fabbione> BenC: exactly what i was thinking...
[03:06] <BenC> so far I have merged almost all the external drivers
[03:06] <BenC> read "git log" and you'll see the format for the log messages
[03:06] <fabbione> in the newest versions? or just from .12?
[03:06] <BenC> newest versions
[03:06] <fabbione> cool
[03:07] <fabbione> i need to push you the new redhat and ocfs2 crack
[03:07] <BenC> 2 or 3 of them have been merged in 2.6.14-rc, so they just got left alone
[03:07] <fabbione> BenC: yes.. some of them were there already in .13 like sc
[03:07] <fabbione> and idiotify
[03:07] <BenC> where is the latest cluster patch? I couldn't find anything as new as what was listed in external-drivers?
[03:08] <fabbione> BenC: sources.redhat.com
[03:08] <doko> fabbione: found the biarch sparc thing
[03:08] <fabbione> but let me deal with it
[03:08] <BenC> doko: sweet
[03:08] <fabbione> BenC: because their upstream is really really messy
[03:08] <BenC> fabbione: sure
[03:08] <fabbione> doko: cool, send it here
[03:08] <fabbione> BenC: they have like a few branches and they manage to get confused by themselves
[03:08] <BenC> doko: is gcc4.1 expected to compile the kernel?
[03:09] <fabbione> BenC: like fixes that goes in STABLE branch are not propagated and viceversa
[03:09] <BenC> fabbione: hehe
[03:09] <infinity> BenC : Probably, but are we willing to risk a "supported for 5 years on servers" release on a compiler that may produce panicking kernels?
[03:09] <fabbione> BenC: it took me a month or 2 of fights with them to get that right
[03:10] <fabbione> BenC: and they still manage to miss the STABLE branch
[03:10] <infinity> BenC : I'd push for 3.4 in dapper, and 4.x as the kernel compiler in dapper+1, even if it's not ready (cause dapper+1 is good place to be testing shit that might break hideously)
[03:10] <BenC> infinity: servers are going to be 2.6.12 based anyway
[03:10] <fabbione> BenC: no no no
[03:10] <infinity> BenC : Ugh, we're not going with jdub's crackful suggestion on that, are we?
[03:10] <fabbione> who said .12?
[03:10] <infinity> That's nuts.
[03:11] <BenC> where is this all being discussed?
[03:11] <fabbione> BenC: i just had a big fight with jdub about that crack
[03:11] <fabbione> ubuntu-devel mailing list
[03:11] <infinity> Maintaining two kernel branches is confusing to users, and a pain for us.
[03:11] <fabbione> infinity: that's my Copyright :P
[03:11] <BenC> only thing I've read about it so far is what mark emailed to ask me
[03:11] <infinity> Anyhow, jdub's just spouting opinions, not policy, we'll all get to yell about this at UBZ in person.
[03:11] <BenC> I'm not sure supporting a kernel for 5 years is sane in any case
[03:12] <fabbione> eheh exactly
[03:12] <BenC> 5 years ago, 2.2.7 was released
[03:12] <BenC> try supporting that now
[03:12] <infinity> Hey, 2.2.7 was solid, dude.
[03:12] <infinity> :)
[03:12] <fabbione> still better than 2.2.11
[03:12] <BenC> yeah, on your grandma's hardware :)
[03:12] <fabbione> after that the 2.2 serie was crack
[03:13] <infinity> I suspect we may need to come up with a point-release plan to update stuff like kernels (for server/desktop) and X drivers (for desktop) occasionally, while not compromising overall stability.
[03:13] <infinity> Thankfully, modular X is making the latter job easier.
[03:13] <infinity> Hopefully rolling kernel driver updating shouldn't be too much hell either.
[03:14] <infinity> RHEL manages to get away with point releases for hardware updates and such, so I'm sure we can manage.
[03:15] <fabbione> infinity: well we get back to the same point...
[03:15] <BenC> I'm hoping that a revamped development model for our kernel will make it easier for us to move from one version to the next
[03:15] <fabbione> developing release foo + preparing service pack X for bar
[03:15] <fabbione> we don't have the resources :)
[03:16] <infinity> Well, we shouldn't be changing much of anything in dapper except for installability support.
[03:16] <infinity> IMO.
[03:16] <infinity> So, hardware support, and nothing else (other than the usual security and critical -updates)
[03:16] <infinity> So, assuming we can get our act in gear enough for that, we're okay.
[03:16] <BenC> personally, I think the kernel should have two branches, one that is targeted for next release, and if there needs to be, a second that is following the latest upstream release
[03:17] <fabbione> BenC: we did try that in hoary
[03:17] <BenC> e.g., when 2.6.14 becomes final, we keep that branch for dapper, and immediately start on 2.6.15-rc1 just to follow the code
[03:17] <fabbione> it was horribly confusing
[03:17] <BenC> but 2.6.15-rc branch doesn't have to be uploaded
[03:17] <infinity> And it can be parallelized a bit.  Say, a month after dapper+1 releases, we decide dapper+1's kernel looks pretty stable and well-tested, we push it back into Dapper-revision1
[03:17] <fabbione> BenC: that will help to release .15
[03:17] <BenC> just kept up-to-date
[03:18] <BenC> just thinking that moving to the next kernel will be a lot easier if we don't wait so long for the code to diverge from our working setup
[03:19] <BenC> we're at 2.6.12, and starting this whole 2.6.14 thing is a real pain (but a good experience, since I have an excuse to scrap as much as I want :)
[03:20] <fabbione> BenC: we did the "following code very close game"  when we did open hoary
[03:20] <fabbione> with a 2.6.12-rc2 i think
[03:20] <fabbione> and started with that
[03:20] <BenC> so breezy's kernel was being worked on during hoary?
[03:20] <fabbione> the main issue is that when we approach release, there is really not so much time to play around in syncing
[03:20] <fabbione> BenC: immediatly after hoary was released
[03:20] <BenC> ah
[03:21] <BenC> well, for 2.6.15, it will be mostly just doing "git pull"
[03:22] <BenC> you can even be in the 2.6.15 branch, and do a pull from the 2.6.14 branch to make sure we have all the little security fixes merged
[03:23] <BenC> it's not that I expect that the branch will build, just keeping the code in sync so it isn't so hard to merge stuff later (easier to merge from day one, than jump from 2.6.14 -> 2.6.16-rc3)
[03:23] <fabbione> yup
[03:24] <makx> fabbione: will you use the debian unified packaging?
[03:24] <makx> i mean you were the first to introduce that model..
[03:24] <fabbione> makx: probably.. 
[03:25] <fabbione> we are changing sort of RCS and way of handling patches and so on
[03:25] <fabbione> makx: so perhaps yes, perhaps no
[03:25] <makx> i read the git part. :)
[03:25] <fabbione> it depends how it fits :)
[03:26] <BenC> what is debian unified packaging?
[03:26] <makx> well before you had the separeted source and images debs xu build stuff
[03:26] <infinity> Building all the arch-specific kernels from one source package, I assume.
[03:26] <infinity> And scrapping that would be dumb.
[03:27] <fabbione> BenC: the old DEbian system was -> upload source -> wait -> upload pkg that b-D on source to create -image- -> wait -> upload d-i stuff to update .udebs
[03:27] <fabbione> BenC: we do all from the same pkgs
[03:27] <makx> it works quite good for anyone beside the mips/mipsel maintainer.
[03:27] <fabbione> and that's what debian did adopt except for the .udeb side
[03:27] <BenC> ah
[03:28] <BenC> yeah, I don't think we'll change the way the build works :)
[03:28] <fabbione> BenC: we will stick to that model of building everything, but we might want to look at the Debian way of building
[03:28] <fabbione> last time i checked it was more polished than ours
[03:29] <fabbione> dunno right now, given the amount of people hacking in it
[03:29] <infinity> That's not surprising.  Debian's "arguing about stuff for 12 months before, during, and after implementation" method may be slow, but it produces polish eventually.
[03:29] <makx> fabbione: do you build uml?
[03:29] <fabbione> makx: no
[03:29] <jbailey> What's the value in uploading a binary "source" deb?
[03:30] <makx> isn't that a dpkg limitation.
[03:30] <infinity> Has nothing to do with dpkg.
[03:30] <BenC> jbailey: back when ports were way out of sync, and had wildly different "upstream" kernel versions, it was the only way to do things
[03:30] <jbailey> BenC: Ah, okay.
[03:30] <jbailey> I had always assumed it was something to do with making custom kernels easier.
[03:30] <infinity> It has to do with people wanting our source to build custom kernels, without having to "apt-get source" and figure out how to build with the maintainer scripts.
[03:30] <infinity> Which is scary and weird for most people.
[03:31] <BenC> that's true too
[03:31] <jbailey> I'd love to see all hacks that make custom kernels easier go away.
[03:31] <jbailey> But that's my hatred of custom kernels and the bugs they cause. =)
[03:32] <infinity> I run custom kernels built from upstream source.
[03:32] <infinity> <shrug>
[03:32] <infinity> But I can see why people may prefer to use our source.
[03:32] <fabbione> infinity: that's becuse you are australian
[03:32] <infinity> (close tracking of security issues, for instance)
[03:32] <infinity> fabbione : I'm Canadian, dude.
[03:32] <fabbione> EVEN WORST
[03:32] <fabbione> and you live in .au
[03:32] <fabbione> tsk tsk :P
[03:32] <jbailey> Right, but if people do their own kernels, we can make no promises about things running.
[03:32] <infinity> My granmother was Sicilian, does that help?
[03:32] <fabbione> infinity: no
[03:33] <fabbione> ;)
[03:33] <jbailey> Our bits are all tested as one piece together.
[03:33] <infinity> jbailey : Yes, and?
[03:33] <infinity> jbailey : You can't stop them from making custom kernels, so making it pointlessly hard is silly.
[03:33] <makx> we had scary questions about allowing the user to nitpick the applied patches.
[03:34] <fabbione> that won't happen with git :)
[03:34] <jbailey> infinity: I think it actually makes it harder for hacking on our kernels to do it this way.  For any other package, apt-get source, hack, debuild, is enough.
[03:34] <fabbione> one tree with all patches applied :)
[03:34] <infinity> jbailey : apt-get source, hack, debuild works for the kernel.
[03:34] <makx> btw a scary tree yours. :-P
[03:35] <infinity> jbailey : But it produces a bunch of images, with our default configs.  And is nonintuitive for people to make one custom image out of.
[03:36] <makx> fabbione: nice than you wont need the patch apply business of the current targets.
[03:37] <makx> it should cope with empy debian-patches dirs.
[03:38] <jbailey> If someone can't figure out which .deb to install, they're probably not clueful enough about their system to spend time building their own kernel.
[03:38] <infinity> It's not about which deb.
[03:38] <infinity> It's about the build taking 8 hours.
[03:38] <jbailey> Although a hack to debi to only install packages that are already installed might be nice. =)
[03:38] <fabbione> i am off
[03:38] <fabbione> later guys
[03:39] <fabbione> BenC: i will come back as soon as the git clone is done
[03:39] <fabbione> connection to the DC sucks
[03:39] <infinity> And I still prefer "make menuconfig && fiddle around && make-kpkg foo" to mucking around in the linux-source-2.6.12 source package for the sake of one image build.
[03:40] <infinity> We should fix our copy of make-kpkg to use '--stem linux' as the default, though, instead of '--stem kernel'
[03:40] <infinity> But, y'know.  That's cosmetic.
[03:41] <infinity> I'm all about discouraging users from building custom kernels if they don't have to (I'm running the breezy kernel on my laptop, and the freedom to not care is a bit nice), but poeple have reasons to do so at times.  Such is life.
[03:42] <infinity> Discouraging people from doing out-of-band kernel builds is good thing (ie: make bzImage && make install), but we can't PREVENT that, only educate people about the joys of make-kpkg.
[03:56] <jbailey> Mmm.
[03:57] <jbailey> I guess I'd like to eventually see us move the kernel to being part of ubuntu-standard
[03:57] <jbailey> That way if we add an inotify patch or whatnot, there's always that promise that these patches are there on a running system.
[03:57] <jbailey> And to be able to commit to that sort of tight integration.
[03:59] <infinity> Still doesn't stop me from booting another kenrel if I so choose.
[03:59] <infinity> The insaller does install the linux-$(arch) metapackage that pulls in automatic upgrades, we can't do much better than that.
[04:31] <BenC> we could force a signature in the kernel that grub verifies :)
[04:31] <BenC> then people would have to replace grub in order to boot a custom kernel
[04:32] <BenC> for "supported" systems, I almost think it would be vital to have such a feature
[04:32] <BenC> especially something in dmesg or ksymoops output (like tainted does now for unsupported modules)
=== lamont__ [n=lamont@15.238.7.17]  has joined #ubuntu-kernel
[04:48] <infinity> And now I'm rebuilding the kernel and the bootloader, pushing me from one unsupported package to two.  Yay.
[04:49] <BenC> the grub thing isn't so much to keep them from booting a custom kernel, just to make it easier for us to know about it
[04:51] <BenC> get grub to spit out a message that says "YOU ARE BOOTING AN UNSUPPORTED KERNEL. YOU DO SO AT YOUR OWN RISK"
[04:51] <infinity>  /proc/version is all you need to know it's a custom kernel.
[04:51] <infinity> Not sure how grub will help you, since you're not watching them boot.
[04:51] <BenC> not if they use our source and add stuff to it
[04:51] <infinity> (Also, every system I build custom kernels on doesn't have a head, so I'd never notice the bootloader anyway) :)
[04:51] <infinity> I run supported kernels on desktops.
[04:52] <infinity> BenC : Erm, even if they use our sources, /proc/version will tell you it's custom.
[04:52] <infinity> it won't be tagged as being built on our buildds, for one.
[04:52] <infinity> And the build date won't be one of ourss, etc.
[04:53] <BenC> that's true
[04:53] <Yagisan> infinity: can't I just manually patch that in :)
[04:54] <infinity> If you manually patch your kernel to look just like one of ours, you're probably not going to be blaming us if it doesn't work either.
[04:54] <BenC> would be nice if we could have the buildd's so that when it built an ubuntu kernel, it would force the build date and builder to that of the changelog entry for the version
[04:54] <infinity> Seriously.  These sorts of countermeasures are to prevent idiots from begging for support on unsupported configs, not to prevent EVERYONE from using their computers effectively.
[04:55] <infinity> BenC : That would have to be done in debian/rules, and then it would also apply for people rebulding from apt-get source.
[04:55] <BenC> wouldn't have to be
[04:56] <infinity> Well, we do already do DC-specific things by way of really broken hacks (like checking that /CurrentlyBuilding exists), but we shouldn't.
[04:56] <infinity> CurrentlyBuilding may not be around forever, as it is also a hideous hack.
[04:56] <jbailey> Especially since you know you'll see in the forums about 2 days after "I don't know why, but if I mkdir /CurrentlyBuilding it works MUCH BETTER"
[04:57] <BenC> lol
[04:57] <infinity> Every once in a while, I consider a DDoS on the forums.
[04:57] <infinity> But then I think better of it.
[04:57] <infinity> What with the whole "I could get fired" thing and all.
[04:58] <jbailey> Well.  It would be your fault for using all of the DC machines to do the DDoS. =)
[04:58] <infinity> *cough*
[04:58] <infinity> I wouldn't JUST use DC machines.  I'd jeopardize my Debian account by using every Debian host I have access to as well, sheesh.
[04:58] <infinity> THINK, MAN, THINK.
[04:58] <Yagisan> What's the most common reason that people build their own kernels ? I build mine for sec patches that will never go mainstream
[04:59] <jbailey> Yagisan: My opinion?  I think themost common reason is that people assume that a new kernel will fix all of their troules.
[04:59] <infinity> I build for stability on server systems.
[04:59] <jbailey> So they grab a new one and just build it.
[04:59] <jbailey> Basically insufficient shinyness.
[04:59] <infinity> On the desktop, I only build new kernels when playing with new features (testing new DRI, etc)
[05:00] <infinity> So, yeah, on the desktop it's all about either development work or bling.
[05:00] <infinity> On the server side, I feel I have real justification to build new kernels.
[05:01] <Yagisan> I had a proposal for universe kernels based on the main kernel + sec patches up for discussion for MOTU
[05:01] <infinity> Like PaX and grsec and such?
[05:01] <Yagisan> exactly
[05:02] <jbailey> Is it possible to work those patches in a way to allow them to be runtime selectable?
[05:02] <infinity> If you could maintain the forked flavours in complete lockstep with the main sources, including building lrm packages for multiverse, I'd not have too many issues with it.
[05:02] <infinity> But I'd want to see a commitment to maintaining lockstep source reuse.
[05:02] <Yagisan> jbailey: for many of them - no
[05:02] <jbailey> Ah, too bad.
[05:02] <Yagisan> infinity: I'm only interested in doing it - if the patches apply to mains kernel
[05:03] <infinity> Yeh, they'd have to apply cleanly, obviously.  But more than that, MOTU would have to commit to doing releases to -security each time we do a release of the main kernel to -security, either.
[05:03] <Yagisan> infinity - for myself I need pax, and possibly rsbac (to provide an alternative for selinux)
[05:03] <makx> Yagisan: irc grsec doesn't cope with the 2.6 release speed.
[05:03] <infinity> In practice, people are horrible at separating supported from unsupported, and the kernel is not a good place to test that.
[05:04] <jbailey> Reminds me that ajmitch is supposed to send me selinux bits for initramfs-tools this week
[05:04] <Yagisan> makx: I know, but they do have cvs releases
[05:05] <makx> Yagisan: and that's against latest stable?
[05:05] <Yagisan> makx: they have a cvs against .12
[05:05] <makx> bleeh that's old.
[05:05] <Yagisan> makx: but I don't use it - I use pax
[05:06] <Yagisan> makx: well - I said I don't use it - I see a pax against .14rc
[05:06] <makx> Yagisan: i thougt the main dev of pax quited..
[05:06] <makx> # blah to many typos sorry.
[05:06] <Yagisan> makx: nope - he discovered he is human
[05:08] <Yagisan> infinity: when the first dapper kernels appear in the archive - I'll see if I can do up a proof of concept
[05:08] <Yagisan> that can pull it in, and create hardened kernels - so only a kernel-patch-foo package is needed in universe
[05:19] <johnm> Yagisan: makx: I just pushed out a release (not ubuntu related) which is grsec against 2.6.13.4, the only reason it skipped .12 was because of a massive internals rewrite. mostly related to rbac.
[05:24] <makx> johnm: not that i would thouch that piece.
=== makx was just curious..
[05:27] <Yagisan> johnm: I'm interested, but unless I can patch it against the main kernel, and pass the motu revu - I can't submit it
[05:40] <johnm> Yagisan: that shouldn't be any problem at all imo.
[06:48] <BenC> fabbione:? 
=== zul_ [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
[06:53] <zul_> gday
[06:56] <BenC> hey
=== hkais [n=dpalic@dslb-084-056-082-061.pools.arcor-ip.net]  has joined #ubuntu-kernel
[06:56] <hkais> hello
[06:58] <hkais> anyone here who works with xen in ubuntu/debian?
[06:58] <hkais> I'm looking to support if necessary, but I do not know how and what to do for the XEN
[07:07] <hkais> hmm really nobody here?
[07:09] <BenC> probably just no one could answer you :)
[07:18] <zul_> BenC: i finally have git going
[07:19] <zul_> and i have made a change last night yay...but how do we push stuff to you?
[07:22] <BenC> are you able to put a git repo where I can pull from it?
[07:22] <BenC> if not, you'll have to send me git pushes via email
[07:36] <zul_> ok..
[07:36] <zul_> so i can mailbomb you ;)
[07:51] <BenC> git-mailsplit will help a lot :)
[07:52] <zul_> heh...actually i can place the patches on my homepage if you want and you can get them from there
[08:09] <BenC> fabbione: ping
[08:16] <BenC> zul_: emailing me a legit git push object would be best
[08:16] <BenC> that way when you merge it and you pull, it will reflect properly
[08:16] <BenC> when I merge it, and you pull, that is
[08:33] <zul_> ok...not a problem
=== spiekey [n=spiekey@p549D1B46.dip0.t-ipconnect.de]  has joined #ubuntu-kernel
[08:49] <spiekey> hiho
[08:50] <hkais> hi
[08:53] <hkais> next try...
[08:53] <hkais> I am searching for someone who is currently working with/on XEN in combination with ubuntu or debian unstable, anyone here?
[08:53] <hkais> I want to support if necessary for a port XEN3
[08:58] <hkais> hmm okay i will try it in the debian kernel channel
[09:14] <fabbione> BenC: pong?
[09:15] <fabbione> Unpacking 101726 objects
[09:15] <fabbione> fatal: unable to read e9066604fd66fe0be7600f74d295b95e8fac474c
[09:15] <fabbione> Killed by signal 1.) done
[09:15] <fabbione> fatal: early EOF726) done
[09:15] <fabbione> fatal: git-unpack-objects died with error code 128
[09:15] <fabbione> BenC: that's the result of several hours of pulling :/
[09:21] <fabbione> BenC: that's weird.. doing a fresh pull now
[09:22] <fabbione> there are like 4000 objs less?
=== hkais [n=dpalic@dslb-084-056-082-061.pools.arcor-ip.net]  has left #ubuntu-kernel [] 
[11:33] <lamont__> why doesn't the breezy kernel find my sound card??? huh???
[11:33] <lamont__> ew
[11:33] <lamont__> Neomagic Corporation NM2200
=== lamont__ consults the forums, feeling dirty
[11:37] <crimsun> well, there's snd-nm256, but I don't think that's yours