| === fbond [n=fab@pool-71-161-210-173.burl.east.verizon.net] has joined #ubuntu-kernel | ||
| fbond | hi | 03:09 |
|---|---|---|
| fbond | i see the dpatch system has been dumped for the ubuntu kernel | 03:10 |
| fbond | what is the new method? | 03:10 |
| infinity | We're maintaining it directly in git now. | 03:16 |
| fbond | right | 03:17 |
| === johanbr [n=j@d154-20-230-40.bchsia.telus.net] has joined #ubuntu-kernel | ||
| infinity | https://wiki.ubuntu.com/KernelGitGuide | 03:17 |
| fbond | i guess I can assume git is not much like other version control systems | 03:17 |
| infinity | Are any of them like the others? :) | 03:17 |
| fbond | heh | 03:18 |
| infinity | It's a distributed revision control system, perhaps like arch/baz/bzr, but not at all like them at the same time. :) | 03:18 |
| fbond | hmm | 03:18 |
| fbond | I found the old system convenient | 03:18 |
| fbond | to package a custom-patched kernel | 03:18 |
| infinity | (But git is what's used by kernel.org, so it's simplest for us to also use it to do rapid merging and cherry-picking of patchsets) | 03:18 |
| fbond | i just needed to add a patch to the debian/patches dir | 03:18 |
| fbond | ok | 03:18 |
| fbond | I guess I'll go learn that then | 03:18 |
| infinity | It speeds up our development a fair bit to be able to track upstream changes without doing it all manually. | 03:19 |
| fbond | this makes sense | 03:19 |
| fbond | upstream releases diffs though, too, eh? | 03:19 |
| fbond | :) | 03:19 |
| infinity | Massive monolithic diffs. | 03:20 |
| infinity | If you want to track small changesets, or one specific branch of a driver, you either get to do it all by hand, or you do it with git. | 03:20 |
| fbond | i see | 03:20 |
| infinity | With git, we get branch history (and tracking) for free, so we can udate a specific driver to current, or cherry-pick a fix here and there without worrying about patch conflicts and other craziness. | 03:21 |
| fbond | ok ok i'm sold enough | 03:21 |
| fbond | :) | 03:21 |
| fbond | infinity | 03:49 |
| fbond | okay, i'm back | 03:49 |
| fbond | I'm looking at this git stuff, and wondering how I can use it to git the diff from vanilla 2.6.15 to ubuntu 2.6.15? | 03:49 |
| fbond | er not git the diff ... get the diff | 03:50 |
| fbond | or generate it, anyway | 03:50 |
| dilinger | that's a nice rally cry. git the diff! | 04:00 |
| fbond | yes, well git is complex enough that i can't relate to your positivity here | 04:02 |
| fbond | svn diff -r 0:HEAD seems easy | 04:02 |
| fbond | git diff ??? HEAD ? | 04:02 |
| fbond | what is ??? | 04:02 |
| fbond | if I want to have a diff from 2.6.15 to Ubuntu's 2.6.15? | 04:02 |
| infinity | If you want to generate the diff with git, you need to know the tag that represents 2.6.15 | 04:25 |
| infinity | Alternately, you could just diff against a tarball. :) | 04:25 |
| fbond | hmm, well I can see how git makes it easier to apply patches, but it certainly doesn't make it very easy to figure out what's already been applied, unless I'm missing something | 04:51 |
| fbond | and I should think the tag representing 2.6.15 would be fairly standard info to want... | 04:51 |
| fbond | and I can't seem to find it anywhere | 04:51 |
| dilinger | v2.6.15? | 04:52 |
| fbond | brilliant | 04:53 |
| fbond | with dpatch, it was clear what each incremental patch accomplished | 04:53 |
| dilinger | more likely, you want v2.6.15.5 or something | 04:53 |
| dilinger | http://kernel.org/git/?p=linux/kernel/git/chrisw/linux-2.6.15.y.git;a=summary | 04:54 |
| fbond | how can I see the incremental patches that were applied by the ubuntu devs? | 04:55 |
| === fbond is now known as fbond|away | ||
| === fabbione [i=fabbione@gordian.fabbione.net] has joined #ubuntu-kernel | ||
| === doko [n=doko@dslb-084-059-115-131.pools.arcor-ip.net] has joined #ubuntu-kernel | ||
| === cmvo [n=cmvo@62.225.11.174] has joined #ubuntu-kernel | ||
| === crimsun [n=crimsun@pdpc/supporter/silver/crimsun] has joined #ubuntu-kernel | ||
| === smurf [n=smurf@run.smurf.noris.de] has joined #ubuntu-kernel | ||
| === doko [n=doko@dslb-084-059-069-105.pools.arcor-ip.net] has joined #ubuntu-kernel | ||
| === Keybuk [n=scott@82.108.80.245] has joined #ubuntu-kernel | ||
| === mgalvin [n=mgalvin@host-66-202-95-170.spr.choiceone.net] has joined #ubuntu-kernel | ||
| mjg59 | BenC_: Sent | 03:43 |
| BenC_ | thanks | 03:44 |
| mjg59 | BenC: Argh. ipw3945 requires newer ieee80211 | 04:08 |
| BenC | usual story :/ | 04:08 |
| mjg59 | I'll send a patch anyway | 04:08 |
| BenC | is that the new intel pro wireless driver? | 04:13 |
| BenC | the one that requires a binary-only daemon? | 04:13 |
| mjg59 | Yeah | 04:14 |
| mjg59 | That'll need to go in restricted somewhere | 04:15 |
| BenC | probably just add it to restricted-modules package so we don't have to create a new package | 04:15 |
| === CataEnry [n=cataenry@host83-39.pool8248.interbusiness.it] has joined #ubuntu-kernel | ||
| === fbond|away is now known as fbond | ||
| fbond | Hi | 04:47 |
| fbond | Shouldn't the ubuntu kernel be maintained as a separate branch in git? | 04:47 |
| fbond | in other words, shouldn't master be upstream? | 04:47 |
| fbond | it's very difficult to isolate the ubuntu changes in a meaningful way | 04:48 |
| fbond | c | 04:55 |
| BenC | doing it in a branch wouldn't help | 05:02 |
| fbond | I'm having a bit of a hard time working with git to do what I want | 05:03 |
| BenC | you can always git-fetch the mainline kernel into a local branch of an ubuntu-2.6 clone | 05:03 |
| BenC | that's what I do | 05:03 |
| fbond | okay | 05:03 |
| fbond | and then do git diff to see the differences? | 05:03 |
| fbond | but that creates a VERY large diff | 05:03 |
| BenC | git-diff-tree | 05:03 |
| BenC | git-log, and look for UBUNTU | 05:04 |
| BenC | all of our changes have UBUNTU in the summary | 05:04 |
| fbond | there's one pretty severe complication, I think | 05:04 |
| fbond | back when dpatch was the norm, I could easily see the differences between 2.6.12, and 2.6.12-ubuntu | 05:04 |
| fbond | now, that's difficult because the git repo includes ubuntu changes made prior to 2.6.15 | 05:05 |
| BenC | all the git changes were done during 2.6.15 development | 05:05 |
| fbond | ok | 05:05 |
| fbond | will ubuntu sync with upstream's git repo at every new minor version? | 05:06 |
| BenC | it's not really the intention of the repo to make it easy to disect each individual patch between our kernel and mainline | 05:06 |
| fbond | i figured that out already | 05:06 |
| BenC | yes, after dapper, we will move on to 2.6.17-git | 05:06 |
| fbond | I had packaged an alternative kernel (-ck) on breezy | 05:07 |
| fbond | it was much easier then | 05:07 |
| BenC | most of the local changes will be rebased (so deltas are against newer changes) | 05:07 |
| BenC | why is it so hard now? | 05:07 |
| BenC | you apply a diff, and recompile | 05:07 |
| fbond | not really | 05:07 |
| fbond | with larger patch sets it's likely you will have two incompatible patches | 05:07 |
| fbond | or more than two | 05:08 |
| fbond | it's nice to be able to selectively remove patches | 05:08 |
| fbond | for instance, try to package an -mm kernel using the ubuntu git repo | 05:08 |
| fbond | that is more complicated than anything i'm doing | 05:08 |
| BenC | our repo isn't really meant for that type of thing | 05:08 |
| fbond | yeah... using dpatch it was much easier. what approach would be the closest approximation, using the new git repo? | 05:09 |
| BenC | using dpatch was much harder for us | 05:09 |
| fbond | i can see that | 05:09 |
| fbond | it makes sense ultimately, given the priorities | 05:10 |
| BenC | right, it was stricly a maint decision | 05:10 |
| BenC | plus being able to interoperate with upstream was a huge bonus | 05:10 |
| fbond | yes, I understand the benefits. Trying to do what I'm trying to do is maddening, though. | 05:11 |
| fbond | Any advice you might have as to how I can simplify this would be appreciated. | 05:11 |
| BenC | what sort of patches are you incorporating? | 05:11 |
| fbond | I had done -ck on breezy. This is is a patchset for reducing latency. | 05:11 |
| fbond | Now I'm looking at -rt, which is more aggressive. | 05:12 |
| fbond | It's a fairly significant patch set | 05:12 |
| fbond | And needs to be applied before the Ubuntu changes, IMO | 05:12 |
| fbond | Otherwise, resolving conflicts is very difficult, and likely to lead to a broken kernel | 05:12 |
| === smurf [n=smurf@run.smurf.noris.de] has joined #ubuntu-kernel | ||
| BenC | IMO, that -rt patch is not a good idea against our kernel at all | 05:27 |
| BenC | it touches a lot of drivers, and all of our non-stock drivers would be left broken | 05:27 |
| BenC | IMO, it would be best to have it against a stock kernel | 05:27 |
| BenC | 2.6.15.5 for example | 05:27 |
| fbond | hmm | 05:28 |
| fbond | perhaps -ck is a better choice in the first place, then | 05:28 |
| BenC | I looked at that patch before, and it was not trivial at all | 05:28 |
| fbond | No. But if it was, it wouldn't be worth creating an alternative package for :) | 05:28 |
| BenC | you could use stock 2.6.15.5, copy our configs, and rebuild for generic systems (i386, k7, 686, smp) | 05:29 |
| BenC | using make-kpkg | 05:29 |
| fbond | Well, my ultimate goal is to keep as many non-stock drivers as possible | 05:30 |
| fbond | You do a great job creating a kernel package with extremely good compatibility | 05:30 |
| fbond | I want to preserve that work ,if possible | 05:31 |
| fbond | My breezy machine at home runs 2.6.12-ck6, and it runs extremely well. Almost all Ubuntu changes to stock 2.6.12 are preserved. Splash screen works still. Etc. It's much more ideal than creating an anti-Ubuntu -rt kernel package. | 05:32 |
| fbond | And it builds just like the Ubuntu packages. apt-get source linux-source-2.6.12-ck6 ... dpkg-buildpackage -rfakeroot ... | 05:33 |
| BenC | the only thing I can suggest is just fixing the failed patch chunks and rediffing | 05:38 |
| BenC | I mean, we haven't create a lot of incompatible changes to our kernel, so your most likely problem is just patch offsets, or slight variations in portions of the code | 05:39 |
| fbond | hmm. ok. for the record, i disapprove. :) thanks for your help. | 05:41 |
| === fbond is now known as fbond|away | ||
| === CataEnry [n=Enrico@host83-39.pool8248.interbusiness.it] has joined #ubuntu-kernel | ||
| === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-kernel | ||
| jbailey | BenC: ping? | 06:28 |
| BenC | jbailey: pong | 06:30 |
| jbailey | BenC: Do we have a wiki page on the Right Way to build your own drivers from source? | 06:30 |
| jbailey | Like, with all the packages that need installing, etc? | 06:30 |
| BenC | not that I know of, but basically it involves installing the linux-headers-2.6.15-VER-FLAVOUR you want to build for | 06:31 |
| BenC | apt-get install build-essential linux-headers-`uname -r` | 06:31 |
| BenC | that should do it | 06:31 |
| BenC | probably don't even need build-essential, but it helps cover things | 06:32 |
| jbailey | 'kay. The sets up the /lib/modules/`uname -r'/build links and everything? | 06:32 |
| BenC | yep | 06:32 |
| jbailey | Without build essential, they won't get far anyway. =) | 06:32 |
| BenC | probably not | 06:32 |
| BenC | I don't think linux-headers depends on gcc, binutils, or make | 06:33 |
| jbailey | BenC: Got a sec to preview: https://wiki.ubuntu.com/KernelSourceDriver ? | 06:48 |
| BenC | jbailey: .. | 06:48 |
| jbailey | BenC: I'd like to be able to point them at a web page that has the instructions. That way it's something a little warm and fuzzy. Documentation almost always feels cuddly. | 06:49 |
| BenC | looks good | 06:50 |
| makx | jbailey: ubuntu uses the smp alternatives patch for x86 and amd64 surprises me that you speak of up/smp flavours | 06:50 |
| makx | thought they would only be left for ppc | 06:50 |
| jbailey | makx: Think breezy. | 06:50 |
| makx | ok. | 06:51 |
| jbailey | I guess I could make that more clear, though. | 06:51 |
| jbailey | I mostly want to drill into people that "Integration is good. Try hardest to do that. Life will suck less." | 06:51 |
| BenC | jbailey: drill it more that they should go upstream to linus instead of "can you include this in ubuntu" | 06:53 |
| BenC | like use an impact chisel to pound it in :) | 06:54 |
| BenC | we, (dist kernel developers) usually catch a lot of flack from upstream for including non-stock drivers in the dist, because it prolongs the driver from getting into upstream | 06:55 |
| jbailey | BenC: Refresh and reread the top part? I'm wondering that that change is enough. | 06:56 |
| makx | only missing the review part of the submission cycle | 06:58 |
| BenC | * Getting your driver integrated into upstream means it will not break because of kernel API changes, it also means all of your users (single and distribution) will always have access to the latest version. | 06:58 |
| makx | but i guess that's what those are afraid of | 06:58 |
| BenC | that's a separate doc that I am writing | 06:58 |
| BenC | jbailey: that kind of combines two of your other points, so feel free to ignore it :) | 06:59 |
| jbailey | Does upstream commit to fixing your driver on api changes? | 06:59 |
| jbailey | ACtually, I think it's probably enough. Most people will probably just ignore that section anyway. | 07:00 |
| cjb | jbailey: In general? Yes, the proposer of a new API is expected to patch drivers using the old one. | 07:00 |
| jbailey | Ah, interesting. | 07:01 |
| cjb | "The Kernel ABI can change from time to time." # What does this mean, syscalls? | 07:01 |
| jbailey | Driver ABI | 07:03 |
| cjb | Syscalls don't change during a kernel series. The API can change, but that's the whole point. You might want to link to Documentation/stable_api_nonsense.txt . | 07:03 |
| jbailey | Well, IIRC syscalls are simply supposed to never change. | 07:03 |
| BenC | cjb: ABI is not syscalls | 07:10 |
| BenC | ABI is any function that is EXPORT_SYMBOL'd for use by modules | 07:11 |
| BenC | if the calling conventions change, then the driver/module ABI changes, which means modules have to be recompiled | 07:11 |
| BenC | it's the whole basis for the linux-image-2.6.15-ABI-ARCH naming | 07:11 |
| cjb | I see. | 07:22 |
| === crimsun [i=crimsun@pdpc/supporter/silver/crimsun] has joined #ubuntu-kernel | ||
| cjb | BenC: Did you know that the driver maintainer document you just posted to lkml has broken wrapping? | 07:57 |
| === mxpxpod [n=BryanFor@unaffiliated/mxpxpod] has joined #ubuntu-kernel | ||
| === lmanul [n=manu@dan75-4-82-239-58-38.fbx.proxad.net] has joined #ubuntu-kernel | ||
| === mkrufky [n=mk@68.160.103.77] has joined #ubuntu-kernel | ||
| mkrufky | BenC: cI just saw your LKML documentation update ..... it's difficult to review it in blob form though... Is this a new document, or a new version of an already existing one? | 08:06 |
| mkrufky | (i thought Ive seen this before, but not compeletely sure) | 08:07 |
| BenC | cjb: my email client probably wrapped different then my editor | 08:13 |
| === JaneW [n=JaneW@dsl-146-154-109.telkomadsl.co.za] has joined #ubuntu-kernel | ||
| BenC | mkrufky: update of a document I posted previously | 08:13 |
| BenC | mkrufky: it's never been included anymore, so it's basically "new" | 08:15 |
| BenC | s/anymore/anywhere/ | 08:15 |
| mkrufky | ah, ok makes sense... i'll read it over then... i'll rreply if i have any comments | 08:18 |
| mkrufky | thanks | 08:18 |
| Mithrandir | BenC: it seems like readahead and unionfs aren't too friendly, especially not in vmware. | 08:24 |
| BenC | Mithrandir: that's the unionfs/squashfs oops that's been occuring all along on ppc | 08:29 |
| Mithrandir | BenC: I see it on i386 too, though | 08:29 |
| BenC | mkrufky: thanks | 08:29 |
| BenC | Mithrandir: yeah, it's a condition that isn't ppc specific, it's just racey and arbitrary | 08:29 |
| Mithrandir | unsure if it's there on real hardware or not, but it's definitively there under vmware, to the point of having the live cd unusable with readahead. | 08:30 |
| Mithrandir | any chance we can get it fixed or should I disable readahead? | 08:30 |
| BenC | I have a bug report about it on actual x86 hw | 08:30 |
| BenC | Mithrandir: just use squashfs 3 :) | 08:30 |
| BenC | that fixed it on ppc | 08:30 |
| BenC | other than that, the squashfs author is looking into why unionfs and squashfs are acting like this | 08:30 |
| BenC | s/acting/interacting/ | 08:31 |
| Mithrandir | yeah, it'd be nice to have it resolved | 08:33 |
| === cmvo [n=cmvo@62.225.11.174] has left #ubuntu-kernel ["Konversation] | ||
| === fbond|away is now known as fbond | ||
| === j_ack [n=nico@p508D8C0C.dip0.t-ipconnect.de] has joined #ubuntu-kernel | ||
| === fbond is now known as fbond|away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!