Re: what is the whole purpose of kernel-image-di?
libdetect. Someone KILL libdetect. It has fledgling PPC support, but it's (A) hacked together awfully (B) a little lacking in correctness (C) nowhere near compiling. I got it to build once, with two hours work, but not function. hmm.. drow, I'd like to talk to you about this more... am looking into doing autodetection stuff for woody b-f using libdetect, but that might not be such a good idea if it's very i386 specific. cdebconf. Randolph, please do something about the warning and error I showed you from the preinst (?)! been on a road a lot this last few weeks. will fix on tuesday when i get back. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the whole purpose of kernel-image-di?
On Fri, Feb 16, 2001 at 10:56:24AM -0700, Randolph Chung wrote: libdetect. Someone KILL libdetect. It has fledgling PPC support, but it's (A) hacked together awfully (B) a little lacking in correctness (C) nowhere near compiling. I got it to build once, with two hours work, but not function. hmm.. drow, I'd like to talk to you about this more... am looking into doing autodetection stuff for woody b-f using libdetect, but that might not be such a good idea if it's very i386 specific. In fact, I just saw that other message in which you mentioned the idea and was about to answer... libdetect COULD be made more cross-platform friendly, by giving it some sane rewriting. It's a mess. cdebconf. Randolph, please do something about the warning and error I showed you from the preinst (?)! been on a road a lot this last few weeks. will fix on tuesday when i get back. Thanks. Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the whole purpose of kernel-image-di?
On Wed, Feb 07, 2001 at 05:07:28PM +1100, Glenn McGrath wrote: I just tried compiling stuff by hand for hurd-i386, the following components form cvs compile fine anna cdebconf choose-mirror main-menu udpkg wget Can you compile and upload the packages? There is currently no functional autobuilder for the Hurd (because of a network server bug). I tried dpkg-buildpackage on a couple of these they fail because they need debhelper which i couldnt install because it depends on dpkg which conflicts with dpkg-hurd, no doubt this is why autobuilders would fail. I havent look any deeper yet. (I saw your other mail where you say dpkg-hurd-dev and dpkg-dev). dpkg-hurd-dev is long obsolete, using dpkg-dev should work just fine. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
what is the whole purpose of kernel-image-di?
I'm sitting here looking at an obvious build failure for kernel-image-di on the sparc buildd, and I'm wondering what the heck this package is for anyway. I mean, is this thing supposed to be portable? If it is, it sucks at doing so, and if it's not, then is it the intention that non-i386 is left out of this loop? Are the debinst folks not even considering non-i386 ports during this development process? Am I going to have to go through all of the installer and hack it to bits to make it work on sparc, just as I had to do with boot-floppies, or is debian-installer being developed so that all I have to do is create a boot-block installer, and a set of kernel-image*.udeb packages to get it working on sparc? I'm very concerned that portability is becoming an afterthought. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the whole purpose of kernel-image-di?
Ben Collins wrote: I'm sitting here looking at an obvious build failure for kernel-image-di on the sparc buildd, and I'm wondering what the heck this package is for anyway. I mean, is this thing supposed to be portable? If it is, it sucks at doing so, and if it's not, then is it the intention that non-i386 is left out of this loop? Are the debinst folks not even considering non-i386 ports during this development process? Am I going to have to go through all of the installer and hack it to bits to make it work on sparc, just as I had to do with boot-floppies, or is debian-installer being developed so that all I have to do is create a boot-block installer, and a set of kernel-image*.udeb packages to get it working on sparc? I'm very concerned that portability is becoming an afterthought. Network install to a i386 was/is the initial focus of development, but the modular nature of d-i should make it easy(or easier) to overcome any difficulties with a specific architecture, or even a different type of kernel (native Hurd install). Because installer modules are deb packages architecture dependent packages for the installer can be handled in the same way an installed system handles it. The boot kernel is supposed to be very modular with only enough features to work, its not neccesarily supposed to be the kernel that will be used post install. Probably a lot of people (me included) arent aware of the difficulties of specific architectures, can you go into a bit of detail about what kernel config doesnt work for sparc ? To answer your last question specifically, portability isnt an afterthought, its part of the design due to modularity. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the whole purpose of kernel-image-di?
On Wed, Feb 07, 2001 at 02:12:43PM +1100, Glenn McGrath wrote: Ben Collins wrote: I'm sitting here looking at an obvious build failure for kernel-image-di on the sparc buildd, and I'm wondering what the heck this package is for anyway. I mean, is this thing supposed to be portable? If it is, it sucks at doing so, and if it's not, then is it the intention that non-i386 is left out of this loop? Are the debinst folks not even considering non-i386 ports during this development process? Am I going to have to go through all of the installer and hack it to bits to make it work on sparc, just as I had to do with boot-floppies, or is debian-installer being developed so that all I have to do is create a boot-block installer, and a set of kernel-image*.udeb packages to get it working on sparc? I'm very concerned that portability is becoming an afterthought. Network install to a i386 was/is the initial focus of development, but the modular nature of d-i should make it easy(or easier) to overcome any difficulties with a specific architecture, or even a different type of kernel (native Hurd install). I can understand it being the first milestone, but it seems to be the only focus, and nothing is being considered as to how it affects other ports. Probably a lot of people (me included) arent aware of the difficulties of specific architectures, can you go into a bit of detail about what kernel config doesnt work for sparc ? For sparc, there has to be atleast two different boot kernels. One for sun4cdm (32bit CPU), and one for sun4u (64bit CPU). SPARC also supports native netbooting (via RARP/TFTP). My main concern is whether or not it is being documented as to how other ports need to handle getting the installer working for it. Is there a checklist of what a port needs in order to have support in the installer, such as a minimum of required packages (boot loader setup, kernel-images, etc.)? Note, every arch is different, which was the main reason for so much speciality and hacking in the boot-floppies. It's held together by ducktape and string. Have the issues involved in the boot-floppies struggle with multi-platform support been brought into consideration of the debinst design? To answer your last question specifically, portability isnt an afterthought, its part of the design due to modularity. Sorry, but modularity does not beget portability. This assumption will end up biting us in the ass later, if it is the only premise for "portability". -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the whole purpose of kernel-image-di?
Ben Collins wrote: For sparc, there has to be atleast two different boot kernels. One for sun4cdm (32bit CPU), and one for sun4u (64bit CPU). SPARC also supports native netbooting (via RARP/TFTP). My main concern is whether or not it ^ One of the things we should be working out. I sweated for quite a few hours to get my second i386 box netboot. It would be great if we could have the system use netboot on platforms where it's possible. As you mention, the complexities involved in porting may be overwhelming if we leave porting as an afterthought. I'd guess that some documentation would be in order. Can not we extract the dependencies and problems with different architectures from the existing boot-floppies docs and source somehow? Perhaps then some sort of a checklist for ports might be done, not enough time to re-invent the wheel. Another thing concerning me would be keeping linuxisms to a minimum and see if we can support hurd in a good way. That would even help freebsd and other exotic ports (cygwin anyone?) out there. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the whole purpose of kernel-image-di?
On Wed, Feb 07, 2001 at 06:34:59AM +0200, Eray Ozkural (exa) wrote: Ben Collins wrote: For sparc, there has to be atleast two different boot kernels. One for sun4cdm (32bit CPU), and one for sun4u (64bit CPU). SPARC also supports native netbooting (via RARP/TFTP). My main concern is whether or not it ^ One of the things we should be working out. I sweated for quite a few hours to get my second i386 box netboot. It would be great if we could have the system use netboot on platforms where it's possible. The installer does not need to directly support net booting, atleast not on sparc. All it needs is for the rootfs image, and a kernel image. Then it boots the same as if it were an initrd. However, creating this needs to be done somehow, and done from a scripted setup (IOW, in a reproducable way). -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the whole purpose of kernel-image-di?
Ben Collins wrote: I can understand it being the first milestone, but it seems to be the only focus, and nothing is being considered as to how it affects other ports. That's not entirely true; I know of a group (who I cannot name or go into any detail on since they told me about this privatly) who is using the the basic debian-installer design and code as the base for something (very cool) involving installation on powerpc. The pa-risc porters were also looking at using d-i some months back, but it wasn't far enough along at that point. For sparc, there has to be atleast two different boot kernels. One for sun4cdm (32bit CPU), and one for sun4u (64bit CPU). As Glenn said, the kernel-image-di kernel is intended to have initrd and ext2 built in, plus anything else needed to boot the system from initrd and get a console. Everything else should be configured as a module. As I told Daniel Jacobowitz when he asked about powerpc (unrelated to thing above), send me a .config file and any logic necessary to detect the arch (and subarchitectures), and I will integrate it into the package. I will also need various lists of module names, like a list of common NIC card modules and so on. Oh by the way Dan has been involved earlier in porting most of the d-i modules to the powerpc, or rather, compiling them on the powerpc. They seemed to work ok, but this was a while back, before the system did anything. A glance at the debian archive shows that this many udebs have been ported: joeyh@auric:/org/ftp.debian.org/ftp/dists/sid/main/debian-installerfor dir in * ; do echo -n $dir ; grep Package: $dir/Packages |wc -l ; done binary-alpha 9 binary-arm 6 binary-hppa 1 binary-hurd-i386 1 binary-i386 22 binary-ia64 1 binary-m68k 4 binary-mips 3 binary-mipsel 1 binary-powerpc 11 binary-s390 1 binary-sh 1 binary-sparc 8 This is one of the nice things about the debian-installer using standard debian sources that generate deb files: autobuilders automatically treat d-i modules just like regular packages. Anyone want to go check the build logs for problems to see if some of the missing items failed to build or have just not need attempted yet? (Good grief, I didn't know binary-ia64 had made it into the archive already..) My main concern is whether or not it is being documented as to how other ports need to handle getting the installer working for it. Is there a checklist of what a port needs in order to have support in the installer, such as a minimum of required packages (boot loader setup, kernel-images, etc.)? Breifly: a. Autobuild all the udebs. File RC bugs on any that fail to build, per the usual. If you just want to build a few, build those listed in build/lists/base, although you'll need at least one additional set, like build/lists/net to actually have a useful system. b. Send me an appropriate kernel config and related information, and build kernel-image-di once I integrate it. c. Some things such as network card involve hardware autodetection. We have concentrated on i386 since it has the most variety (and crap) hardware. udebs are generally available which let the user specify it manually instead of using hardware autodetection. Other than those and some minor crossovers, other architectures are on their own, and someone will have to work on it. d. The build/ directory is what builds actual bootable media. That code is currently flagged: # Create a bootable floppy image. i386 specific. FIXME Obviously that will need to be fixed, on a case-by-case basis. I personally flag anything I do that is i386-specific as such, although I haven't had to do that much so far. But we're really all too busy writing this thing to have ready-made checklists yet. I'm scrambling to keep the existing design documentation current. Note, every arch is different, which was the main reason for so much speciality and hacking in the boot-floppies. It's held together by ducktape and string. Have the issues involved in the boot-floppies struggle with multi-platform support been brought into consideration of the debinst design? You're not going to magically get a new installer for your architecture dropped in your lap, it will take work. Anyone is free to jump in and make support for another architecture happen *now*, while we are still in the middle of writing the thing. Or you can wait and complain after the fact about us not anticipating the needs of every architecture. Up to you. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the whole purpose of kernel-image-di?
On Tue, Feb 06, 2001 at 09:09:28PM -0800, Joey Hess wrote: b. Send me an appropriate kernel config and related information, and build kernel-image-di once I integrate it. Well sparc needs three kernels. sun4cdm, sun4dm-pci and sun4u. I can get you configs, but the problem being that I have no idea what kernel source you are building. I would hope that you plan to integrate to 2.4.x sooner or later, but how will you notify ports of this new change? No one asked about such configs yet. I guess what I am saying is that it would be nice if you could communicate this outside of the debian-boot list (say to the nice [EMAIL PROTECTED] alias I have made :) c. Some things such as network card involve hardware autodetection. We have concentrated on i386 since it has the most variety (and crap) hardware. udebs are generally available which let the user specify it manually instead of using hardware autodetection. Other than those and some minor crossovers, other architectures are on their own, and someone will have to work on it. Well sparc is quite simple in this regard. We have the special ability to just build all the standard NIC drivers right into the main image. The only modules I can think of needing are for the gigabit, but I imagine those are not needed for the installer, since nearly every sparc has one of the standard cards built-in. d. The build/ directory is what builds actual bootable media. That code is currently flagged: # Create a bootable floppy image. i386 specific. FIXME Obviously that will need to be fixed, on a case-by-case basis. I personally flag anything I do that is i386-specific as such, although I haven't had to do that much so far. But we're really all too busy writing this thing to have ready-made checklists yet. I'm scrambling to keep the existing design documentation current. That's fine, but is it even a concern to have such a checklist, or is me bringing it up the first of it's discussion? Are you expecting porters to do all the work trying to figure out what they need to do once the installer is nearly complete? Note, every arch is different, which was the main reason for so much speciality and hacking in the boot-floppies. It's held together by ducktape and string. Have the issues involved in the boot-floppies struggle with multi-platform support been brought into consideration of the debinst design? You're not going to magically get a new installer for your architecture dropped in your lap, it will take work. Anyone is free to jump in and make support for another architecture happen *now*, while we are still in the middle of writing the thing. Or you can wait and complain after the fact about us not anticipating the needs of every architecture. Up to you. I'm not asking for a free-installer. What I'm asking for is concentration on porting specifics. Not all porters can keep up with the entire installer code base, and simply want to know "what do I have to do to get support for my arch in the installer?". If I have to go through the whole source tree searching for "i386.*FIXME", it's going to be slow and tedious. I'm not expecting anyone to do the work for me, but as the developers of the software, I would hope that keeping known concerns about porting in the focus of the project would be a main concern. Obviously if I jump up and say "well arch foo needs 10 special udeb's, why don't you have them!", well piss on me. But if I turn around and see that there is no way for me to even have subarch (sun4cdm, sun4u) support, then piss on debinst. One issue that comes to mind was the past discussion about using the module utilities from busybox, which would have totally killed some ports (sun4u being one of them). Things like that need the concern of more than just one or two archs. The other is the nano editor, which has asm for i386 only (or maybe some other archs, but surely not sparc). This means we don't get the space savings that i386 does (it has to link to libc). Other choices may include things like parted, which doesn't support all archs, but I hear it is a likely candidate for a partion program. Yet more things to shutdown certain ports from using the standard install. Of course it isn't a reason not to use it, just that concerns need to be raised. Please don't think I am complainging about what work I will have to do, or that you guys aren't doing enough, I'm just concerned about a lot of work being done without enough consideration for the effects on other ports. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the whole purpose of kernel-image-di?
On Tue, Feb 06, 2001 at 09:09:28PM -0800, Joey Hess wrote: Ben Collins wrote: I can understand it being the first milestone, but it seems to be the only focus, and nothing is being considered as to how it affects other ports. That's not entirely true; I know of a group (who I cannot name or go into any detail on since they told me about this privatly) who is using the the basic debian-installer design and code as the base for something (very cool) involving installation on powerpc. The pa-risc porters were also looking at using d-i some months back, but it wasn't far enough along at that point. blink Now I'm curious, curse you! Oh by the way Dan has been involved earlier in porting most of the d-i modules to the powerpc, or rather, compiling them on the powerpc. They seemed to work ok, but this was a while back, before the system did anything. And I'm going to go back to this shortly, now that we've got an x86 bootable floppy. PowerPC is not big on bootable floppies (or floppies at all) but I can probably get a nice ramdisk going, and maybe a netboot... This is one of the nice things about the debian-installer using standard debian sources that generate deb files: autobuilders automatically treat d-i modules just like regular packages. Anyone want to go check the build logs for problems to see if some of the missing items failed to build or have just not need attempted yet? libdetect. Someone KILL libdetect. It has fledgling PPC support, but it's (A) hacked together awfully (B) a little lacking in correctness (C) nowhere near compiling. I got it to build once, with two hours work, but not function. cdebconf. Randolph, please do something about the warning and error I showed you from the preinst (?)! b. Send me an appropriate kernel config and related information, and build kernel-image-di once I integrate it. 2.4.1 kernel.org does not build on PPC. Sigh. c. Some things such as network card involve hardware autodetection. We have concentrated on i386 since it has the most variety (and crap) hardware. udebs are generally available which let the user specify it manually instead of using hardware autodetection. Other than those and some minor crossovers, other architectures are on their own, and someone will have to work on it. Other architectures will want a radically simplified detection scheme. PPC (mostly) has no legacy ISA or such; everything should show up in the kernel's PCI probes. That should make things much nicer. Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the whole purpose of kernel-image-di?
Joey Hess wrote: Ben Collins wrote: I can understand it being the first milestone, but it seems to be the only focus, and nothing is being considered as to how it affects other ports. A glance at the debian archive shows that this many udebs have been ported: joeyh@auric:/org/ftp.debian.org/ftp/dists/sid/main/debian-installerfor dir in * ; do echo -n $dir ; grep Package: $dir/Packages |wc -l ; done binary-alpha 9 binary-arm 6 binary-hppa 1 binary-hurd-i386 1 binary-i386 22 binary-ia64 1 binary-m68k 4 binary-mips 3 binary-mipsel 1 binary-powerpc 11 binary-s390 1 binary-sh 1 binary-sparc 8 This is one of the nice things about the debian-installer using standard debian sources that generate deb files: autobuilders automatically treat d-i modules just like regular packages. Anyone want to go check the build logs for problems to see if some of the missing items failed to build or have just not need attempted yet? I just tried compiling stuff by hand for hurd-i386, the following components form cvs compile fine anna cdebconf choose-mirror main-menu udpkg wget The hardware detection stuff doesnt apply to hurd as it all at least in part depends on /proc which is a linux, so any hardware detection for the hurd is going to have to be native, configuring may also have to be somewhat different as well as the Hurd uses a translators to setup some hardware. I tried dpkg-buildpackage on a couple of these they fail because they need debhelper which i couldnt install because it depends on dpkg which conflicts with dpkg-hurd, no doubt this is why autobuilders would fail. I havent look any deeper yet. A previous holdup for the Hurd was partitioning software, work is underway to port parted, so that should fix that problem. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the whole purpose of kernel-image-di?
Glenn McGrath wrote: I tried dpkg-buildpackage on a couple of these they fail because they need debhelper which i couldnt install because it depends on dpkg which conflicts with dpkg-hurd, no doubt this is why autobuilders would fail. I havent look any deeper yet. i should have said dpkg-dev and dpkg-hurd-dev instead of depk and dpkg-hurd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the whole purpose of kernel-image-di?
Ben Collins wrote: Well sparc needs three kernels. sun4cdm, sun4dm-pci and sun4u. I can get you configs, but the problem being that I have no idea what kernel source you are building. I would hope that you plan to integrate to 2.4.x sooner or later, but how will you notify ports of this new change? No one asked about such configs yet. I guess what I am saying is that it would be nice if you could communicate this outside of the debian-boot list (say to the nice [EMAIL PROTECTED] alias I have made :) kernel-image-di is using for 2.4.0, will build for 2.4.1 once source for that enters the debian archive. See its build dependancies; the build dependancies will ensure it is autobuilt with the right kernel. c. Some things such as network card involve hardware autodetection. We have concentrated on i386 since it has the most variety (and crap) hardware. udebs are generally available which let the user specify it manually instead of using hardware autodetection. Other than those and some minor crossovers, other architectures are on their own, and someone will have to work on it. Well sparc is quite simple in this regard. We have the special ability to just build all the standard NIC drivers right into the main image. The only modules I can think of needing are for the gigabit, but I imagine those are not needed for the installer, since nearly every sparc has one of the standard cards built-in. The reason to use modules is mainly one of space on the boot media. If that is not a concern on sparc they could be built in. That's fine, but is it even a concern to have such a checklist, or is me bringing it up the first of it's discussion? Are you expecting porters to do all the work trying to figure out what they need to do once the installer is nearly complete? No, I'm really expecting porters to jump in now and help us. We have a very small group working on this. support, then piss on debinst. One issue that comes to mind was the past discussion about using the module utilities from busybox, which would have totally killed some ports (sun4u being one of them). Things like that need the concern of more than just one or two archs. The other is the nano editor, which has asm for i386 only (or maybe some other archs, but surely not sparc). This means we don't get the space savings that i386 does (it has to link to libc). Other choices may include things like parted, which doesn't support all archs, but I hear it is a likely candidate for a partion program. Yet more things to shutdown certain ports from using the standard install. Of course it isn't a reason not to use it, just that concerns need to be raised. As far as I can see, they have been. After all we didn't wander off and use the busymox insmod, iirc the issues with parted have been brought up before, and now I know about nano (which exists as a udeb just because its mtaintainer wanted to do it iirc; we haven't really talked about editors yet). I encourage you and anyone else to read this list and keep us in line if we begin to wander off into i386 la-la land. I also encorage people involved in other architectures to begin participating in the creation of debian-installer *now* so they can have a hand in making it work well on those platforms. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the whole purpose of kernel-image-di?
Daniel Jacobowitz wrote: 2.4.1 kernel.org does not build on PPC. Sigh. 2.4.0 is ok, right? I guess I'll hold off of 2.4.1 for now.. Other architectures will want a radically simplified detection scheme. PPC (mostly) has no legacy ISA or such; everything should show up in the kernel's PCI probes. That should make things much nicer. Hardware detection is a place where despite Ben's protests, modularity really does work. For i386 network cards, we have ethdetect which autoprobes the card and loads the driver. For sparc we can have an essentially dummy package that makes sure one of the drivers built into the kernel found something. For ppc we can do something else. Other modules that need to actually make use of the network connection then depend on a virtual package that is provided by all of the above. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the whole purpose of kernel-image-di?
On Tue, Feb 06, 2001 at 10:34:52PM -0800, Joey Hess wrote: Daniel Jacobowitz wrote: 2.4.1 kernel.org does not build on PPC. Sigh. 2.4.0 is ok, right? I guess I'll hold off of 2.4.1 for now.. 2.4.0 is even worse (read useless) on powerpc. (linus merged some 2.4 powerpc code in 2.4.1 but obviously not enough) at the moment the only 2.4 kernel code that works on powerpc is the forked bk trees. 2.2.18 kernel.org however is fully powerpc functional. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
