First of all, I would like to appologise for the tone of my previous message - it was out of line. You have put a lot of work into this - and I should be thanking you.
On Thu, 2005-03-03 at 08:51, Micah Anderson wrote: > Crash is distributed with Debian, its currently in Sid and in Woody, > it hasn't progressed into Sarge because of a build problem on Alphas. OK, I didn't look beyond Sarge's Contents.gz. > No, its not a reason to exclude it, but having it for all achitectures > is going to make the chances for including it much more. If it only > works for two architectures then the instructions in lkcdutils > actually get more complex, rather than simpler. We'd have to tell > people that if they are using i386/S390 then they can do this, if they > are using other architectures, they will have to do this. What we are talking about here is adding a line of them form: Note: on some architectures Kerntypes is included in the compiled kernel's binary package, and will be installed into /boot for you. It isn't a big deal. > Or you can do what I always do -- put on the seatbelt when I first > enter the car. In kernel building speak that translates to: After > building any kernel, I always copy the .config to a safe spot > (/boot/config-kernel-rev), copy out the kerntypes, the System.map and > the boot image. But, I agree, not everyone does this, just like not > everyone puts on their seatbelt before they throw themselves down the > road in their relatively destructible metal container. Driving without seat belts is illegal here in Australia, and as a result people don't do it. This has the interesting side effect of reducing the size of explosive needed in an air bag. Since Australian designers can assume people in cars are wearing seat belts, they can use less explosive. The nett effect is that in Australia we have less injuries due to air bags. So if you hear someone say that wearing a seat belt is purely a personal decision that effects no one else, you can correct them! Anyway, back to the point: yes, you can try and remember to copy Kerntypes to /boot. People who read README.Debian may do so. People who don't, won't know of course. As a rule I only read the stuff under /usr/share/doc if I run into problems. I automatically think others do things the same way - but perhaps not. People who install the kernel from a binary .deb (such as those on my web site), don't have a choice - they can't - there is no Kerntypes available to install if it isn't in the kernel binary .deb. > and it is wrong, thanks for pointing that out... that was true in the > old version, but a lot has changed, and still is changing with lkcdutils > (soon to be known as dumputils), so it is not a surprise that this is > out of date. I've changed the manpage to reflect this, although the > replacement of lkcdutils with dumputils may make that change not > appear in the archive. Yes, I did notice the patches are changing rapidly. What is causing all the changes? > I've talked with upstream about it and they are considering it, > probably will be able to do it pretty quickly. Thanks. > > - The man page is wrong - Kerntypes isn't installed for you. > > A wrong manpage bug is not an "important" severity, it would be > "normal" or "minor", but thats not what this bug was, this bug was > asking to include the patches that you have to provide Kerntypes in > /boot, which is a different issue, one that I consider a wishlist bug, > and now has been forwarded to upstream. Actually - I was looking at it from the reverse angle - it was a feature that has been removed and should not of been. But as you point out - this was an upstream decision, not yours - you are merely reflecting what upstream has done. In that context I agree the priority I assigned it was wrong. > > But anyway (and after calming down and thinking about it in > > a more constructive fashion), that is all beside the point to > > some extent. The real issue is that the system is much easier > > to use, and more robust (as in Kerntypes is actually present > > when you need it), when Kerntypes is installed automatically. > > For that reason alone Debian should strive to install it. > > But not other operating systems? Do you mean other distributions? This is to large extent a packaging issue - that is whether Kerntypes in included in the final kernel binary package or not. That is the province of the distribution (Debian, Red Hat, or whatever). It is unlikely we could influence what they do even if we wanted to, except perhaps by leading by example. > I'm going to wait to see what the upstream thinks before I do anything > on this. If you'd like to figure out if dpatch would work and provide > a dpatch that would be the debian way of adding this feature, I'd > consider figuring out the dpatch coexistence with kpatches and how to > make a diff from your changes after I've heard from upstream. If you'd > like to figure this out faster than I can, I'll be happy to integrate > it. If the choice is between upstream and dpatches, this is the right way to proceed. > > Then see if you can't convince the maintainer of > > kernel-package to look in utils/kerntypes.o for Kerntypes > > for 2.6 kernels. (This may not be necessary as I notice > > kernel-package does run scripts in: > > <kernel-root>/debian/image.d/ > > during the build. Perhaps you can alter what included in > > the .deb by adding a script. This would be much cleaner - > > but you will have to stop using dh_installkpatches and > > write you own patch install script.) Once you have done > > all that, by all means stop building Kerntypes. > > You should file a bug against kernel-package asking for this. I was surprised when I saw an lkcd specific hack in /usr/share/kernel-package/rules. kernel-package should know nothing about specific patches, IHMO, except possible kernel-patch-debian. This leads me to think the *right* way to do this is to bother neither the maintainers of kernel-package, nor upstream - if that is possible. Instead kernel-patch-lkcd should put a script into <kernel-source-root>/debian/image.d that includes utils/kerntypes.o as /boot/Kerntypes-VERSION. If this is possible, it would require you to abandon using dh_installkpatches, and provide kernel-patch-lkcd specific apply and unpatch scripts instead. I am happy to write these for you. Would you consider going down this path? I have not looked in detail at what scripts in image.d can do. If they can't effect what gets put into the kernel binary package, then the right think to do would be to ask the kernel-package people to provide hooks that can - and remove the lkcd specific stuff they currently have. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
