| === pgraner_ is now known as pgraner-lt | ||
| === smb_tp_ is now known as smb_tp | ||
| === doko_ is now known as doko | ||
| apw | smb_tp, when we were talking about kernel builds, we talked about how we did make debug version of the kernel somehow, and how they were done special and went somewhere else. got any pointers to how that works? | 11:20 |
|---|---|---|
| smb_tp | apw, Hm, not really. I try to remember but at the moment I don't get it... :( | 11:23 |
| apw | must ask benc | 11:23 |
| smb_tp | Yeah, and I should memorize his answer... | 11:25 |
| apw | nope it should be wikid | 11:25 |
| apw | Keybuk, hey ... mmc things | 13:09 |
| smb_tp | ^^^ talking mumble? | 13:10 |
| apw | i am far too sophisticated for that | 13:11 |
| smb_tp | good excuse :) | 13:12 |
| apw | smb_tp, so do we have any sort of builtin system for setting up modules specifically to a machine during install? | 13:48 |
| smb_tp | apw, Is there a specific example or case you look at? | 13:51 |
| apw | i have seen a number of bugs recently asking for specific module options for a particular machine | 13:51 |
| apw | (the one i saw today was about the acerhk driver) | 13:51 |
| apw | if the driver has pci'id detection or whatever then obviously we should be adding ids for that kind of thing | 13:52 |
| apw | but for other things, i just wondered if we had something which builds modprobe.d/* specific to the machine; i am assuming not | 13:52 |
| smb_tp | I was not aware of something getting added generically. But I might be missing a piece | 13:54 |
| smb_tp | It would have to be done in the installer, so we might ask cjwatson... | 13:55 |
| apw | it sounds like a dangerous thing to do probabally | 13:57 |
| apw | as if you move the disk to new h/w its wrong | 13:57 |
| smb_tp | Right, I would guess everything on a bus gets added if there is something with the right id. And other things should/would look for dmi information | 14:00 |
| * apw is not entirly clear which things we are able to do direct probes for | 14:02 | |
| apw | it seems the driver i am interested here is actually being superceeded upstream by a new driver which does do appropriate things | 14:23 |
| === thegodfather is now known as fabbione | ||
| dee | Hello. | 16:23 |
| dee | I've just build the Ubuntu Kernel like this: http://www.howtoforge.com/roll_a_kernel_debian_ubuntu_way | 16:23 |
| dee | Because there are no audio drivers build in I must compile linux-ubuntu-modules too. Here's the tutorial: https://help.ubuntu.com/community/Kernel/Compile | 16:24 |
| dee | Unfortunately the process do not recognize my new kernel and tries to use the old header files instead. | 16:24 |
| dee | The file /lib/modules/2.6.24-22-386/build/include/linux/version.h does not exist. | 16:24 |
| dee | Please install the package with full kernel sources for your distribution | 16:24 |
| dee | or use --with-kernel=dir option to specify another directory with kernel | 16:24 |
| dee | sources (default is /lib/modules/2.6.24.3-moto/source). | 16:24 |
| dee | Did anyone know how to solve this? | 16:25 |
| rtg | dee: https://wiki.ubuntu.com/KernelMaintenance, read 'Getting the source' and 'Performing builds', then install the linux-headers* packages | 16:27 |
| dee | Okay, another version of compiling ... I will try this one ... | 16:30 |
| dee | bye | 16:30 |
| fitzdsl | Salut tout le monde ! | 17:53 |
| fitzdsl | J'ai un petit problème, j'essaye d'installer xen a partir des paquets (ubuntu-xen-server) (je suis sous intrepid), l'instal se passe bien, mais il ne me créé pas de nouvelle entrée dans menu.lst | 17:53 |
| fitzdsl | j'ai bien un xen-3.3.gz dans /boot mais c'est la seule reference a xen | 17:53 |
| fitzdsl | pas de initrd ni vmlinuz | 17:53 |
| Nafallo | !fr | fitzdsl | 17:53 |
| Nafallo | meeh. lacking bot. | 17:54 |
| fitzdsl | sorry, i made a mistake | 17:54 |
| fitzdsl | so Hi | 17:54 |
| fitzdsl | i've got a problem to install ubuntu-xen-sever (i run intrepid), the install seems fine but it doesn't change my menu.lst | 17:55 |
| fitzdsl | i've got a xen-3.3.gz in /boot but it is the only file with xen reference | 17:55 |
| Nafallo | Ubuntu kernel development discussion ONLY <-- from the topic. you might want to try #ubuntu :-) | 17:55 |
| fitzdsl | i've got no initrd nor vmlinuz | 17:56 |
| fitzdsl | thx | 17:56 |
| apw | Nafallo, any idea whome to poke to get the bots back | 18:47 |
| Nafallo | apw: #ubuntu-ops I think :-) | 18:48 |
| tjaalton | apw: seems that upstream fixed the intel headers http://bugs.freedesktop.org/show_bug.cgi?id=19132 | 19:33 |
| tjaalton | but it's not going to end up in .28 | 19:33 |
| tjaalton | so you probably want to pull that | 19:34 |
| apw | tjaalton, thanks for the pointer | 19:47 |
| apw | whats the upshot of the change, that the kernel headers are now usable | 19:47 |
| tjaalton | apw: we should be able to drop the drm headers form libdrm-dev | 19:49 |
| tjaalton | *from | 19:49 |
| apw | ok ... will try and find it, knwo where the drm-intel-next tree hangs out? | 19:49 |
| tjaalton | but maybe wait until there's a new libdrm version out, which should be around the corner | 19:50 |
| apw | yeah won't rush into any change, the last one was dangerous enough | 19:50 |
| tjaalton | heh | 19:51 |
| tjaalton | I'm searching for the repo | 19:51 |
| tjaalton | apw: here git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git | 19:52 |
| tjaalton | drm-intel-next branch | 19:52 |
| tjaalton | AIUI, those are then merged to airlied's drm-next branch | 19:53 |
| tjaalton | in this case when .29 opens | 19:53 |
| apw | ok, its not clear if that is sufficient | 19:54 |
| apw | as in this fix fixes the interaction between the kernel headers and intel drm, but are any of the other consumers affected? how can we know? | 19:59 |
| apw | tjaalton, ^^ | 19:59 |
| tjaalton | apw: by building every driver, but I'd be surprised if the others would be affected. intel and ati are seeing most of the action these days (and nouveau of course, but it's not included) | 20:00 |
| tjaalton | er, every driver that uses those headers | 20:01 |
| tjaalton | so matrox, r128, savage, sis, openchrome | 20:01 |
| tjaalton | intel and ati are now known to work | 20:01 |
| apw | so intel plus that little fix, and ati with none work with the real kernel headers | 20:04 |
| tjaalton | ati needs one fix, but it was for the X driver | 20:25 |
| === asac_ is now known as asac | ||
| === jws141_ is now known as dashua | ||
| apw | tjaalton, can that fix move without the headers? ie. can we do all the userspace changes without changing the kernel headers from the ones in libdrm-dev ... when they are all out _then_ do the kernel header flip flop ??? | 23:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!