[12:37] mjg59: So it seems the patch killed any system without a swap partition, joy. [12:37] mjg59: I thnk I have it fixed. [12:37] =) [12:37] jbailey: Hrm? [12:38] The other suspend shell script had a guard to make sure that if the RESUME variable wasn't defined, that it didn't attempt to figure everything out. [12:38] This one didn't have the guard. [12:38] It turns out that [ -e ${RESUME} ] returns true when RESUME isn't defined. [12:39] Ah [12:39] Right [12:39] [ -e "${RESUME}" ] , however, returns false. [12:39] Hm [12:39] But it's still failing to resume, for some reason === mkrufky [n=mkrufky@user-12lcl1s.cable.mindspring.com] has joined #ubuntu-kernel === jorgp2 [n=jorgp@bnet-dial-32.bartnet.net] has joined #ubuntu-kernel [01:20] mjg59: Cerainly on my laptop resume doesn't seem to be defined. [01:20] But hopefully, I can kill all the critical bug reports at least. [01:20] *sigh* [01:30] jbailey: "defined"? [01:37] //sys/power/resume is 0:0 [01:38] Hm. When is this? After boot? [01:45] jbailey: Ok. If I panic immediately before the resume call, I have no disk devices [01:46] jbailey: Doing a udevstart gives me devices [01:46] jbailey: Argh. Yes, udevstart is run after load_modules has finished [01:47] Ahahahaha [01:47] Hm [01:47] But why didn't the second call catch it? [01:47] Dunno [01:47] It should at least still be set, since the suspend script is still there? [01:48] I think I want to spend another day thinking about how to lay this all out. [01:48] I'd prefer that we had something in the archive that worked, to be honest [01:48] Most people will have swap on lvm, I think. [01:48] Really? [01:48] IIRC, the installer does LVM by default now. [01:48] Uhm. [01:48] Not in my experience. [01:48] Unless you tell it to use the whole disk? [01:49] Dunno. [01:49] Hm. [01:49] All of my machines are whole-disk installs. [01:49] But I thought that it was doing LVM in general now. [01:49] Right. Hrm. [01:50] Oh, I'm told that it's easy to check if all the disks in an LVM are present [01:50] One of the vg commands will tell you [01:54] jbailey: Ok, yeah. A udevstart sorts it. [01:54] So in what order should this happen then? Attempt to walk the PCI bus, find card. Find ide-disk, sd, and friends. [01:54] udevstart [01:54] Yeah. [01:54] Mm, no, step before. [01:54] Start md, lvm, evms. [01:54] I'm wrong, those are after udevstart [01:54] udevstart needs to be before md and lvm [01:54] Yeah [01:54] Except we only want to start them if we have all member disks [01:54] Right, but that's a good hack to put the in lvm script anyway [01:55] Sure [01:55] Hurrah. Working hibernate. [01:55] Then walk the bus a second time, looking for usb and network drivers. [01:55] Yeah [01:55] start md, lvm, and evms. =) [01:55] Sorry udevstart. [01:55] Then start those. [01:56] Then attempt hibernate resume again in case the device was on one of those and it happens to work for people. [01:56] Yeah [01:56] Sick. [01:56] Heh [01:57] Mind you.. [01:57] I guess I can shortcut that second pass if I have swap and the root device. [01:58] All I need is USB at that point in case they drop to a shell. === doko_ [n=doko@dsl-084-059-067-020.arcor-ip.net] has joined #ubuntu-kernel [01:58] I wonder how many people will get screwed if I suddenly don't load their ethernet cards in the initramfs? === zul_ [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [01:59] heylo [01:59] mjg59: Are you getting lots of reports of fails to resume? [01:59] I have 15775 [01:59] jbailey: Well, it's broken with current initramfs-tools [01:59] As in, there's no way it can work [01:59] Right. I'm wondering if it's urgent enough that I should stay up, or if I can consider my workday over and dive in tomorrow. [01:59] I'd sortof like dinner and to see my belle. [02:00] Heh [02:00] Would it be possible to just add the one-line udevstart to fix some cases? [02:00] I'll take a look at the lvm stuff and let you know what I find === jbailey squirms. [02:01] It leaves things no worse than they are right now [02:01] Oh, I figured out why the suspend script isn't running. [02:01] It needs a chmod +x [02:01] Ah. heh. [02:02] When I recovered it from bzr, it didn't preserve that. [02:02] I'd really prefer to leave it until I can actually do a test run with it. [02:02] I've just done a test run with that case [02:02] I'm basically going to go offline for the night in a few minutes and don't want to look for more "OMG can't boot" bugs. =) [02:03] The one change I made was to add the udevstart [02:03] heh liar [02:03] mjg59: You have main upload privs, don't you? =) [02:03] jbailey: Heh. Indeed. [02:03] jbailey: Have you uploaded the one with the resume guard quotes? [02:03] mjg59: Feel free. That way they beat on your for touched-it-last priviledges. [02:04] mjg59: I have. If you're using bzr, I've updated that to 0.27 [02:04] jbailey: Hm. vgscan ought to return an error, I'm told [02:04] jbailey: Ok, where's your tree? [02:04] http://people.ubuntu.com/~jbailey/bzrtree/initramfs-tools [02:04] Thanks [02:05] vgscan doesn't take a vg as a parameter, though. [02:05] The root vg is the only thing that needs to promise to be present at boot time. [02:05] Other arrays and stuff could require fancier setup that requires an otherwise running system. [02:06] Hmm. Yes. [02:06] I wonder if vgdisplay has it. [02:06] There must be a reasonable way to get it out of the metadata. [02:06] With lvm, it's not obvious what's reasonable or not. === jbailey runs off for food. === mkrufky is now known as mkrufky-away [03:42] mjg59? [03:42] BenC: Hi === mkrufky-away is now known as mkrufky === TheMuso [n=luke@dsl-202-173-132-131.nsw.westnet.com.au] has joined #ubuntu-kernel [06:30] BenC; poke [06:40] morning guys === TheMuso [n=luke@dsl-202-173-132-131.nsw.westnet.com.au] has joined #ubuntu-kernel === Yagisan [n=jamie@220-244-253-135-nsw-pppoe.tpgi.com.au] has joined #ubuntu-kernel [07:43] BenC, jbailey: ping? === jorgp2 [n=jorgp@bnet-dial-32.bartnet.net] has joined #ubuntu-kernel === jorgp2 [n=jorgp@bnet-dial-32.bartnet.net] has joined #ubuntu-kernel === JaneW [n=JaneW@wbs-146-149-243.telkomadsl.co.za] has joined #ubuntu-kernel === jorgp2 [n=jorgp@bnet-dial-32.bartnet.net] has joined #ubuntu-kernel === jbailey [n=jbailey@testhaus.cns.utoronto.ca] has joined #ubuntu-kernel === jorgp2 [n=jorgp@bnet-dial-32.bartnet.net] has joined #ubuntu-kernel [02:43] morning [02:48] hey zul [02:51] hey fabbione how goes it? [02:51] zul: working as usual [02:51] you+ [03:01] ditto === jorgp3 [n=jorgp@bnet-dial-178.bartnet.net] has joined #ubuntu-kernel [03:20] Ah, hello fabbione. I just wanted to have a quick word with you about that kernel-package dependency thing. [03:20] Do you have a moment ? [03:22] Diziet: can you give me 5/10 minutes? [03:23] Sure. [03:30] Diziet: ok... [03:30] i am back [03:33] Diziet: ?? [03:33] Hello. [03:34] so remind me where we left the discussion [03:34] So this is about 15488. Can you remember what I was saying on Friday ? [03:34] yes [03:34] till we agree to stop for the day :) [03:34] kernel-package has a hardcoded value `gcc', which it inserts into the Depends of the source .deb's that it causes to be created. [03:35] mdz and the submitter seem to think just changing that to gcc-3.4 would be correct. [03:35] Diziet: one second that i am digging code and stuff... [03:35] Since when you use kernel-package with one of our kernels they end up trying to build against gcc-3.4. [03:36] Recommends: libc-dev, gcc, make [03:36] ok [03:36] gcc is only Recommended [03:36] not a Depends: [03:36] now we have 2 situations we need to analize [03:36] and that's why i didn't agree with your changes [03:37] 1) building our linux-source [03:37] Yes, I see what you were saying about my change which I agree was wrong. [03:37] 2) building a generic vanilla kernel [03:37] ok [03:37] let's take it again point by point [03:37] Right. [03:37] so we are sure we don't overlook anything [03:38] for the sake of release in 3 weeks :) [03:38] our kernel must be built with gcc-3.4 [03:38] this is hardcoded [03:38] so [03:38] the Package: linux-source-2.6.12 must Depends on gcc-3.4 [03:38] Hardcoded in the Makefile you get when you unpack one of our kernel source trees (no matter how you got it). [03:38] or Recommends: gcc-3.4 [03:39] and I agree with BenC that should be a Recommentds [03:39] Right. [03:39] Diziet: exactly [03:39] it's hardcoded in the makefile [03:39] When you say `the Package: linux-source-2.6.12' you mean _our_ `linux-source-2.6.12'. [03:39] But of course someone could sensibly use make-kpkg to make their own linux-source-2.6.12. [03:39] Diziet: we have a source called linux-source-2.6.12 that B-D on gcc-3.4 [03:39] That's one of the things it's for. [03:39] Right. [03:39] and a package that ships our source + patches that Recommends: gcc [03:40] the latter is wrong [03:40] Indeed so. === mkrufky [n=mk@68.160.103.77] has joined #ubuntu-kernel [03:40] so we all agree that P: l-s-2.6.12 must either Depends: gcc-3.4 or Recommends: gcc-3.4 [03:40] because i might download the source only for reading [03:40] _Our_ l-s-2.6.12, yes. [03:40] yes [03:40] Right. [03:40] our [03:40] i didn't talk about pint 2 at all [03:41] OK. [03:41] that's why i isolated the cases [03:41] i am still on point 1) [03:41] Carry on ... [03:41] so for 1) that's the only change required [03:41] now [03:41] 2) is more complex [03:41] it is way more complex [03:41] why: [03:42] a) we don't know what kernel the user is building [03:42] b) and we don't know why [03:42] so we can't force a gcc to him [03:42] he might be as well compiling a kernel with gcc-4.0 for debuggin [03:42] Currently, make-kpkg does do that. That is, if the user uses make-kpkg to make a linux-source.deb, it will say Recommends: gcc. [03:42] we have no idea [03:42] Right. [03:43] so i still believe that Recommends: gcc is the right solution [03:43] i see no winner in forcing a gcc [03:43] In this second case ? Certainly there shouldn't be a Depends. [03:43] ok.. [03:43] But yes, it seemed to me that either Recommends: gcc or nothing at all would be best. [03:43] and that's how the situation is [03:44] Nothing at all is a reasonable option - after all, the user knows what they're doing and we shouldn't trip them up. [03:44] also.. who compile its own kernel, needs to know what it is doing [03:44] Exactly. [03:44] Now, AIUI both of these cases are generated by the same code in make-kpkg. [03:44] so for me.. personally.. 15488 is NOTABUG :) === Seveas [n=seveas@seveas.demon.nl] has joined #ubuntu-kernel [03:45] Um, you're saying that _our_ linux-source packages are _not_ made with make-kpkg ? [03:45] Diziet: yes it is made with make-kpkg [03:45] So surely atm the dependencies are wrong ? [03:45] Diziet: yes. === Diziet goes to check. [03:46] but we need to fix it in debian/control in linux-source-2.6.12 [03:46] and not in kernel-package :) [03:46] our l-s-2.6.12 debian/rules is insane [03:46] But linux-source-2.6.12, if it is make with make-kpkg, has an autogenerated debian/control made by make-kpkg. [03:46] s/is make/is made [03:47] iirc it is overwritten [03:47] there are scripts that copies parts of debian/control to differnt packages [03:47] Scripts where ? [03:47] inside debian/ [03:47] In linux-source-x.y.z's source package ? [03:47] it's all contained in one dir (at least!) [03:47] yes [03:48] But make-kpkg makes up a source package out of whole cloth. [03:48] Diziet: be aware that our source doesn't call make-kpkg on itself [03:49] the source is copied/mangled/trashed/reconfigured several times [03:49] and that happens in debian/build [03:49] building our kernel is not only executing make-kpkg [03:49] there are plenty of more problems we need to address === Diziet reads debian/rules build in linux-source 2.6.12's source. Blimey. [03:50] Diziet: you also want to check the scripts that it calls [03:50] Yes, so I see. [03:50] kernel-wedge gen-control > debian/control [03:51] yes.. kernel-wedge is for udebs [03:51] control file is generated via control.stub [03:51] nothing too fancy [03:52] Diziet: line 162 [03:53] sorry 163 [03:53] cp debian/control $(srcdir)/debian [03:53] that one copies our control file into debian/build/linux-source-2.6.12/debian/ [03:53] Right. [03:53] the dir that will generate the source afterwards [03:53] But even debian/control.stub looks like it should be autogenerated. [03:54] It's full of version numbers. [03:54] Diziet: ALT [03:54] control.stub and control are only for udebs [03:54] ALT ? [03:54] ALT = STOP :) [03:54] sorry... [03:54] itaglish [03:54] you will learn that my itaglish > pure english :P [03:55] don't get confused by control.stub and control [03:55] that's not relevant for we need here [03:55] just think at them like debian/control [03:55] the mangling required for udebs is another story [03:56] (brb.. mother nature is calling ;)) [03:56] So when you update to a new upstream kernel, how to the version numbers get furtled in these control files ? [03:56] OK. [03:56] (= i need to take a piss ) [03:56] Yes, that's not itaglish :-). [04:01] Diziet: sed -i -e 's/2.6.12/2.6.whatever/g' debian/control.stup [04:01] and for a little bunch of more files [04:02] it's suboptimal [04:02] but I never had the time to rewrite that mess [04:02] so we can live with it... [04:02] and we should merge our build system with the Debian one [04:02] Ah, right. So the right answer is just to change control and control.stub and leave kernel-package alone. [04:02] exactly [04:02] control.stub is enough :) [04:03] control is regenerated [04:03] OK :-). [04:03] Do you want me to attempt to do that ? Is this stuff in arch or something or just normal uploads ? [04:03] Diziet: see /topic :) [04:03] i can do it.. it's one line change [04:04] Hey, I looked at the topic _yesterday_ :-). [04:04] yeah... [04:04] debian/ is in baz [04:05] Right. Well, I'll leave you to do it I think; probably quicker than me faffing, unless I'm going to turn into an actual kernel bod. [04:05] Diziet: that's ok.. [04:06] Diziet: it is important that we coordinate changes to the kernel build system all together [04:06] there are a lot of bits that need to fall down in the right place [04:06] otherwise we can wave kthxbye to it === doko [n=doko@dsl-084-059-067-020.arcor-ip.net] has joined #ubuntu-kernel [04:14] how much space is needed when compiling linux-source ? [04:14] I've tried to add a driver to my local copy, but it dies in my pbuilder complaining it is out of space. [04:18] Yagisan: it depends.. it can be quite a lot [04:18] up to 550MB for a build [04:19] sorry per flavour [04:19] ah [04:19] so my 11GB tmpfs wasn't enough [04:20] Yagisan: they should be plenty... [04:20] but well... if it complains about space, you must have done something wrong [04:22] well, all I did this morning was "sudo pbuilder build linux-source-2.6.12_2.6.12-8.13.dsc" [04:22] Yagisan: it depends how you did configure pbuilder [04:22] by default it uses /var/cache [04:23] so if your /var/cache/pbuilder/build is a tmpfs, than yes.. you were building in RAM [04:23] otherwise you were writing on fs [04:24] I set BUILDPLACE=/tmp/ in pbuilder and /tmp is tmpfs [04:25] so I think pbuilder is set up ok [04:25] I've never build anything this big in pbuilder though [04:25] Yagisan: just be sure it is really using /tmp than [04:46] ok. I've just freshly unpacked linux-source-2.6.12_2.6.12-8.13.dsc and confirmed it is building in /tmp, now to wait and see if it crashes again - this time with logging on. [04:51] fabbione: about v4l/dvb kernel updates (for breezy): what kernel should I patch against? [04:52] mkrufky: if you really want to spend your time on it, against our tree [04:52] but we are really too close to release to update an entire subsystem [04:52] i think it's more worth to start working from the dapper kernel [04:52] ah, then i wont bother... no big deal... [04:53] i guess that kernel will be ready in about a month, right? === Diziet [n=ian@xenophobe.extern.relativity.greenend.org.uk] has left #ubuntu-kernel [] [04:54] mkrufky: i think in 10 days we can start working on dapper kernel [04:54] we won't be able to upload it [04:54] but given that breezy is uber frozen [04:54] we can start playing around in a devel branch [04:55] hmmm..... so will i get access to this branch? [04:57] mkrufky: if you use baz yes of course [04:57] you won't be able to commit directly to it [04:57] but you can branch off [04:57] and publish your branch [04:57] and we can merge back [04:57] no big deal [04:58] zul did this for all the hoary release... [04:58] it did work pretty well [04:58] thats fine... i guess i have a new tool to learn then.... (never heard of baz, but there's always a good time to learn) [04:58] ehhe [04:58] apt-get install bazaar [04:58] there are plenty of howto's [04:58] got it [04:58] for basic stuff i can even help you :) [04:59] i'm downloading it now... will play around a bit [04:59] sure === jorgp3 [n=jorgp@bnet-dial-178.bartnet.net] has joined #ubuntu-kernel [05:25] i did what? [05:25] oh...heh [05:26] heh i wasnt special enough to get direct access ;) [05:27] dont be jealous... im not special enough either :-P [05:27] mjg59: ping [05:28] BenC: Hi [05:28] Hm. Are we allowed to break the ABI now? [05:28] hey, can I close 14790? [05:28] no :) [05:28] Shit. Right. [05:28] BenC: Yeah, looks like that can be closed [05:30] Argh. === mjg59 tries to figure out a way of doing this without breaking ABI [05:30] I fear it may be impossible [05:31] Right. It breaks ABI in the pcmcia socket driver [05:32] If we want to support recent TI PCMCIA chipsets properly, they need an extra prod to power up properly by the looks of it [05:32] mjg59: i cleaned up the patch a bit last night so it applies will be doing a test build tonight and will commit it to my archive tonight for BenC [05:32] Maybe I can just drop that hunk. [05:32] zul: Which patch? [05:34] meh breaking the abi is still possible, but mdz is not going to like it [05:34] I'll see if I can do this without it [05:36] BenC: i am working on fixing 15488, 14736 and 13506 [05:36] if you already did any of them, please let me know [05:38] mjg59: sk98lin [05:39] BenC: i have a patch for the buslogic stuff, i need to find a way to test it though [05:39] zul: Cool [05:41] buslogic == vmare fix? [05:42] yep..i added a struct for hotplug it seems the logical thing to do [05:43] based on previous examples [05:44] fabbione: cool, thanks [05:44] my vmware install is v5, so I can't test it [05:46] I have vmware 5.5beta [05:46] want a copy ? [05:48] Blah. [05:48] sure...just send me a key or something [05:48] Suck. [05:49] It looks like we need to break ABI if we want these controllers to work [05:49] Yagisan: bug shows in vmware v4 [05:49] (Which includes bsaically everything made by HP at the moment) [05:49] Sorry, my fault. I should have noticed this earlier. [05:49] meh...i have a key for vmware4 [05:49] mjg59: well, if it's that bug a deal, we will break it [05:49] They work if you boot with the card in, but there are no events for insertion/deletion [05:49] s/bug/big/ [05:49] BenC: I have 4.5.2 somewhere too [05:50] I think supporting cardbus on a large range of laptops qualifies as worthy of abi breakage [05:50] vmware 5 keys work in 5.5beta - that's part of the deal of being a beta tester [05:50] Yagisan: A copy of that would be nice, if it's not too much trouble [05:53] Yagisan: same here [05:53] lunch time [05:56] BenC: Mailed [05:56] mjg59: the ABI breaker? [05:56] Yeah [05:56] The break is in cs.c [05:57] ok, thanks [05:57] btw, did you resend a second sk98lin patch? [05:57] I only got one [05:57] the first one [05:58] Hrm. I did. [05:58] The only difference was that -Ia/drivers was replaced with -Idrivers in the EXTRA_CFLAGS statement === mjg59 wonders what's up with his mail [06:03] BenC: we need to add an extra package to upload when we break the ABI [06:03] BenC: klibc B-D [06:03] heh - I did it again. linux-source-2.6.12_2.6.12-8.13 again failed to build in pbuilder - cites "lack of space" [06:04] Yagisan: i blame pbuilder [06:05] fabbione: at least I have a log now [06:05] BenC: Did you get the patch I just mailed you? [06:08] I'll point pbuilder at a 600GB RAID array, start it up, and go to bed. If it isn't done by the time I get up - I'll file a bug on pbuilder. [06:08] mjg59: not yet, I did get the pcmcia patch though [06:09] BenC: Yes, that's the one I sent [06:09] Should I resend the sk98lin one? [06:10] nah, I can just add your change manually [06:11] Ok [06:13] I get spurious a's in my stuff too, I can deduce that you use vi :) [06:25] mjg59: are you sure the change to cs.c breaks the ABI? [06:26] the change is to socket_setup(), which is a static function [06:26] BenC: Sorry, I should have been clearer. It adds a new callback to struct pcmcia_socket (see ss.h) [06:26] So that changes the version [06:27] ah, ok [06:39] zul: ping [06:43] jbailey: fedora kernel people dont like my tree-merge solution, RE: missing dvb headers.... have you ever heard from the original bug poster? [06:43] jbailey: im hoping to get those moved into /include/linux/dvb .... hopefully for 2.6.15 [06:44] mjg59: does the pcmcia fix apply to bug 15734, or is that bug a dup of the one this fixes? [06:44] BenC: yo [06:45] Should be unrelated [06:45] zul: you have sk98lin in your tree, right? So I don't need to merge this directly? [06:45] apply directly I mean [06:45] mjg59: ok [06:45] what bugs is it [06:45] BenC: Don't have the number to hand, but it bites me here [06:46] BenC: it will be going in tonight when i get home, should i remove the other yukon driver patch? [06:46] zul: yeah, I'm dropping sky2 completely [06:46] 15196 looks likely, 15083 certainly is [06:46] if you pull it from your tree, even better, so I can just merge and take care of both [06:47] BenC: ah so ill add it tonight, im just doing a build now to make sure everything is hunky dory [06:47] zul: thanks [06:48] I plan on making tomorrow prep day for upload on Thurs [06:48] just FYI [06:48] ok..ill commit it tonight then ;) [06:48] BenC: One more easy patch for you, possibly a couple of more awkward ones [06:48] (won't break ABI) [06:50] mjg59: ok, I'm going to take those bugs, mark 15196 a dupe of 15083, and mark 15083 PEND [06:52] Ok, cool === jorgp3 [n=jorgp@bnet-dial-178.bartnet.net] has joined #ubuntu-kernel [07:24] whoops [07:26] Hurrah! [07:26] I may have found the solution. [07:27] pcmcia? [07:29] PCMCIA breaking hibernate [07:29] I'm afraid you're stuck with the ABI breakage :) [07:29] damnit :) [07:32] mkrufky: Ah, okay. I haven't taken a look at the script. [07:32] mkrufky: Basically what's in the bug report is all I've got. [07:33] mkrufky: Given that it's new files going in, is there no way to get them in for 2.6.14? [07:34] I win === fabbione commits fix for 15488 [07:37] guys .. one suggestion [07:38] i am reading here... kill sky2.. add sk98lin.. blabla [07:38] be aware that this might be the last kernel upload [07:38] and that somebody will have to support for 18 months [07:41] is the archive fucked up??? [07:42] oh fuck [07:42] Mithrandir: you blocked the kernel archive [07:43] Mithrandir: you need to set a proper umask on people [07:43] Mithrandir: /home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--preX,14--2.6.12/ [07:43] check for patch-5 and fix permissions [07:43] i guess i will commit later [07:47] fabbione: While it's bad to ship a kernel that's hard to support, it's worse to ship a kernel that doesn't actually work on useful hardware [07:47] BenC: I've just sent you pcmcia_hibernate.dpatch [07:47] BenC: This fixes hibernation when PCMCIA cards are physically present in the machine at hibernate time === dmk [n=dmk@81.156.25.127] has joined #ubuntu-kernel [08:12] fuck fuck.. [08:12] mjg59: cool, thanks === jorgp3 [n=jorgp@bnet-dial-178.bartnet.net] has joined #ubuntu-kernel [08:15] BenC: Another patch. Fixes reboot on HP laptops without affecting anyone else (I had one report of a desktop that didn't reboot with the reboot-thru-bios patch - this one should only hit affected machines) [08:16] : tfheen@rookery ~ > umask [08:16] 002 [08:18] fabbione: it looks sane to me === doko [n=doko@dsl-084-059-067-020.arcor-ip.net] has joined #ubuntu-kernel === jorgp3 [n=jorgp@bnet-dial-178.bartnet.net] has joined #ubuntu-kernel [08:31] BenC: Do you think it's safe to merge 10307 and 9115? [08:46] jbailey: looks like it's safe to move the headers... i just worked it out with the dvb maintainer [08:46] we should probably have them (officially) moved by 2.6.15 [08:46] mkrufky: Cool. [08:46] mkrufky: If you have a list of what headers are moving where, I can take care of it in Breezy. [08:47] Mithrandir: well the commit you did locked the archive [08:47] mkrufky: No chance of sneaking it in for 2.6.14? It's less invasive than the other crap that went in to -rc1 [08:47] those 5 .h files in /drivers/media/dvb/dvb-core [08:47] -rc2, rather [08:47] Mithrandir: remember tha scp/sftp needs umask very eary [08:47] early even [08:47] jbailey: I dont wanna push Linus' buttons [08:48] and... there are some out-of-tree dvb drivers that still depend on them to be in the current location [08:48] mkrufky: 'kay. Where will they go? [08:48] include/media/dvb [08:49] include/media? [08:49] A new subdir? [08:49] checking..... [08:49] Maybe include/linux/media or somethin [08:49] mkrufky: Is there another channel I should join? [08:50] nah, i took care of this over the linux-dvb mailing list [08:50] mkrufky: Right now there's stuff in /usr/include/linux/dvb [08:50] but the applicable channel is #linuxtv [08:50] Well, I'm not in a rush to add windows 76 on my irssi. =) [08:50] heh [08:51] looks like ur're right... that directory doesnt exist [08:51] i guess johannes wants to create the new directory [08:51] Mithrandir: i do set the umask from .bash_profile, because i think sftp doesn't load bashrc [08:51] jbailey: apparantly this has already been the plan, i just kicked it with a little jumpstart, thanks to you [08:51] hang on, i will show you the email thread [08:52] mkrufky: Tx. [08:52] If they're going under /usr/include/linux/dvb, I can do this no prob. [08:52] If he wants to create a new subdir, I need to wait for the flamewar, sadly. [08:53] hmm [08:53] would it cause any harm if u put them in include/linux/dvb ? [08:53] i doubt it. [08:53] mkrufky: None at all. =) [08:53] mkrufky: 'cept that if nothing is going to look for them there... [08:53] heh true [08:53] That's why I'd rather drop them into wherever they're going to wind up eventually. [08:54] well, i wouldnt start up a flame war just yet [08:54] http://linuxtv.org/pipermail/linux-dvb/2005-September/004861.html [08:54] But I imagine that there'll probably be some resistance to adding another directory to /usr/include from the kernel folks. [08:54] hmm [08:54] ya maybe it makes sense to wait on it for now [08:55] Dude, I see the words "are considered half-private i.e. not for userspace" [08:55] and tell your users to use the tree-merging scripts instead, as a temporary workaround [08:55] yes..... thats the same as any other kernel headers [08:55] but u see, those headers are needed for v4l compile , which is kernel space [08:55] Is it a kernel module? [08:55] v4l is a set of kernel modules [08:55] Hmm. [08:55] and so is dvb [08:56] ivtv is NOT a kernel module [08:56] Are those going to just be integrated eventually? [08:56] they are already integrated [08:56] the only difference is: [08:56] users find themselves updating their v4l / dvb drivers to take advantage of support for new hardware [08:57] Oh, hmm. [08:57] you see, i just wrote all these drivers for new hardware that came out last year [08:57] unfortunately, due to kernel release cycle, these drivers wont be available in a mainline kernel until 2.6.15 [08:57] BenC: ping? === jbailey reaches for his 'no sympathy' stick... [08:57] =P [08:57] so many users want to play [08:57] so they get cvs [08:58] now do u see ? [08:58] I do. It sounds very much like problem we can't solve. [08:58] no [08:58] it is easily solved [08:59] the user gets newer drivers from cvs [08:59] simple as that [08:59] benc, fabbione: What do we currently do for folks who want to compile their own out-of-tree kernel drivers? [08:59] about the missing headers, until we standardize the final location, the tree-merging scripts will suppice as a temporary workaround [08:59] s/suppice/suffice [09:00] Right. But whatever mechanism we provide for other kernel modules to be built out-of-tree should also be available for these things. [09:00] That might provide some hints for an esaier solution than the tree-merging scripts. [09:00] The userspace headers that I provide in linux-kernel-headers have all of the #ifdef KERNEL bits ripped out of them. [09:01] They can't be used for compiling kernel modules at all. [09:01] BenC: Fix for 13382 just emailed to you [09:01] Uh, 13882 [09:01] jbailey: we usually hand them a nice piece of RTFM :) [09:02] heh [09:02] mjg59: re 13506... [09:02] ahci is a scsi module... [09:02] why should it land in sata? [09:02] the tree-merging scripts do more that just fix this header problem [09:02] there are other (non-critical) dependencies that v4l has in dvb-kernel that is necessary fro hybrid analog/digital capture cards [09:03] oh, wait... it all just clicked... [09:03] fabbione: It's not a SCSI module. It's a sata one. [09:03] jbailey: did you at first think that v4l was userspace?!? [09:03] mkrufky: Yes. If I had known it was a kernel module, I would've asked Fabio the question earlier and not gone any further with it. =) [09:03] aaah [09:05] mjg59: ok added.. but i have no way to ensure it's loaded before ata_piix [09:05] fabbione: Well, we'll have to work that out later [09:05] That can be handled in userspace [09:05] mjg59: yup [09:05] but there is no much time to do it [09:06] so i rather suggest we talk with Kamion [09:06] Do I smell more initramfs magic? [09:06] jbailey: Sadly so [09:06] Greeat. [09:06] jbailey: Actually, probably module-init-tools magic. But it'll need to go in initramfs. [09:07] jbailey: We just need a modprobe.d that attempts to load ahci before ata_piix [09:07] fabbione: Which which FM shall I tell them to read when I smack this bug report with it? === jorgp2 [n=jorgp@bnet-dial2-243.bartnet.net] has joined #ubuntu-kernel [09:07] mjg59: 'attempts to'? [09:07] jbailey: so, i take it, that now that you know the true story... that ubuntu will frown upon such cvs module updates? [09:07] jbailey: Well, it may fail [09:07] mjg59: So anyone with ata_piix will have a stale ahci lying around? [09:07] jbailey: It can always attempt to rmmod it afterwards :) [09:07] mkrufky: No idea. It means that I'm not worried about it for the userspace headers. =) [09:08] Actually, I dunno if that would work [09:08] jbailey: It's better to have a stale ahci module than non-working systems, I think [09:08] mkrufky: That's why I'm asking Fabio which manual we send them to when they want to do their own modules? Between that and the tree merging scripts, hopefully they'll sort it out. [09:08] jbailey: it's called README + Makefile + Kbuild [09:08] jbailey: seriously... modules that are done properly use kbuild [09:09] if they use kbuild users needs only the headers for their running kernel and the correct gcc [09:09] jbailey: There are 4 Intel bridges that will work with *one* of ata_piix or ahci [09:09] And have identical PCI IDs [09:09] fabbione: Which package is kbuild in? [09:09] Actually, that's probably not true. ata_piix will probably drive them most of the time [09:09] mjg59: 'kay. Hmm. Right now I'm just copying modprobe into the initramfs, and not the config files. [09:10] jbailey: Yeah. We'll work something out. [09:10] mjg59: Do y ou think I should also take all of /etc/modprobe.d ? [09:10] jbailey: Not sure. Scripts there may call stuff that you don't have. [09:10] jbailey: linux-headers.. it's kernel build system :) [09:11] jbailey: but once you install the headers for your specific kernel [09:11] you also automatically get the generic and kbuild [09:11] BenC: Have we got the Apple touchpad driver? [09:12] jbailey: ah, gotcha [09:13] jbailey: this is exactly why i will backport the newer v4l/dvb code for the dapper kernel... hopefully users wont need to mess with cvs if all the latest support is already included in ubuntu's kernel [09:14] fabbione: anyway, is it correct now? [09:15] Mithrandir: yes.. thanks [09:15] at least i could commit [09:15] mkrufky: Ah, cool. I expect that it's quite late for getting an update into breezy with less than a month to ship. [09:16] mkrufky: I'll let you sort that out with BenC though. [09:17] mkrufky: I see that the kernel-headers-2.6.12-8 package does have an include/media directory [09:17] So this all makes sense now. =) [09:18] Getting the headers into there for Breezy is probably quite doable to keep everyone happy. (Again, it needs to go to BenC) [09:19] ah, cool [09:19] it DOES have include/media [09:20] but not include/media/dvb [09:20] (that is where they will end up going) [09:20] mjg59: don't think so [09:20] fabbione told me that he welcomes updates like i've mentioned, but yes, it probably IS too late for breezy [09:21] although if you guys are in fact interested, I can probably have a patch ready by tomorrow (or the next day) [09:21] BenC: i did commit fixes for 14736 and 13506 [09:21] BenC: the former needs a full test build on ppc [09:21] the latter on all arches [09:21] BenC: Want me to find the diff for you? [09:21] or at least ppc, i386, amd64 and ia64 [09:23] fabbione: thanks [09:23] mjg59: yes, please [09:23] BenC: no problem [09:24] dpatch is really slow for taking in a lot of small patches [10:27] mjg59: Hey, did you ever make it possible for usplash to handle input text? =) [10:27] I didn't [10:27] I have a wishlist bug with a patch attached for encrypted root. =) [10:27] Haha. [10:27] Prefix it with usplash_write "QUIT" [10:28] Sweet, that'll do nicely. =) [10:28] usplash_write "FOAD" === Seveas [n=seveas@seveas.demon.nl] has joined #ubuntu-kernel === jorgp3 [n=jorgp@bnet-dial-37.bartnet.net] has joined #ubuntu-kernel [11:40] BenC: Just sent you a patch to fix http://bugzilla.kernel.org/show_bug.cgi?id=3927 [11:40] (Well, "fix") === mkrufky [n=mk@68.160.103.77] has left #ubuntu-kernel [] [11:47] BenC: I've sent you a patch for #7904 (apple trackpad driver) === chmj [n=chmj@wbs-146-160-201.telkomadsl.co.za] has joined #ubuntu-kernel === apokryphos [n=apokryph@host-87-74-2-161.bulldogdsl.com] has joined #ubuntu-kernel === apokryphos [n=apokryph@host-87-74-2-161.bulldogdsl.com] has left #ubuntu-kernel ["So]