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