* Nils Rennebarth
| Instead of creating lots of different kernel-image packages what about
| a package that can create a kernel-image from source and gives you a list of
| some more or less generic kernel to choose from?
Abusing debconf, since it is such a nice interface. ;)
I'd prefer if Herbe
On Tue, May 01, 2001 at 01:38:38PM +0200, Torsten Landschoff wrote:
> Anyway, I would like to have an smp kernel readily available in Debian.
> Mandrake for example installs the SMP kernel by default if the target
> machine is a smp box. If another kernel-image is needed to support that
> I can lif
On Tue, May 01, 2001 at 12:19:29AM +1000, Craig Sanders wrote:
> > This is the point where I disagree. I really hate having to build my
> > own kernel just to do some tests with a fresh installation.
>
> so you have spent good money on a high-end SMP machine but you're not
> willing to put in 5(*)
* "Vince Mulhollon"
| But what happens when people provide / request / demand optimized
| versions of Gnome, KDE, and Apache for every possible combination of
| optimization?
You point them to pentium-builder, or Debian moves to a 'make world'
paradigm. Or we bloat the archives a lot. I hope f
On Thu, Apr 26, 2001 at 05:39:34PM +0200, Kenneth Vestergaard Schmidt wrote:
> If instead, you were able to type something akin to "update-kernel" or
> whatever, and then have a kernel built suited to your arch, but with the
> "default" Debian-options (ie. lotsa modules), wouldn't that be better?
On 04/30/2001 03:21:55 PM "Christopher C. Chimelis" wrote:
>> Basically, I can understand everyone's desires for a kernel that covers
>> their cases (SMP, UP, 686, 386, etc), but the bloat issue that initially
I can't understand that desire for such a small gain, but whatever.
>> this thread ge
* Daniel Stone <[EMAIL PROTECTED]> [010424 07:03]:
> ONE HUNDRED AND TEN MEGABYTES PER KERNEL RELEASE DOES NOT HELP MIRRORS WHICH
> HAVE
> OUT OF SYNC PACKAGES FILES AND ACTUAL PACKAGES HALF THE TIME.
Being a maint. of two debian mirrors, I don't get your point. :)
Could you please turn this in
On Mon, 30 Apr 2001 [EMAIL PROTECTED] wrote:
> Unfortunately it seems that a kernel that supports both i386 and SMP
> would have to use very slow methods for locking since instructions
> allowing faster locking only came in with the 486 and above.
I'm wondering when this whole discussion will in
On Mon, Apr 30, 2001 at 12:41:22PM +0200, Torsten Landschoff wrote:
> This is the point where I disagree. I really hate having to build my
> own kernel just to do some tests with a fresh installation. I think
> the standard kernel should support SMP. I don't know if it causes
> any problems with UP
On Mon, Apr 30, 2001 at 12:41:22PM +0200, Torsten Landschoff wrote:
> On Mon, Apr 30, 2001 at 05:19:12PM +1000, Craig Sanders wrote:
> > anyone running SMP ought to have enough of a clue to compile their
> > own kernel.
>
> This is the point where I disagree. I really hate having to build my
> own
Hi Craig,
On Mon, Apr 30, 2001 at 05:19:12PM +1000, Craig Sanders wrote:
> > I won't go below that as an SMP kernel is always required,
>
> no it's not.
>
> anyone running SMP ought to have enough of a clue to compile their own
> kernel.
This is the point where I disagree. I really hate havi
On Sat, Apr 28, 2001 at 02:15:50PM +1000, Herbert Xu wrote:
> Please also consider that if the user were to compile his own kernel,
> he would face the problem of having to recompile the modules packages
> if they're needed.
use kernel-package and all the module packages are compiled automaticall
On Thu, Apr 26, 2001 at 07:48:02PM +1000, Herbert Xu wrote:
> I won't go below that as an SMP kernel is always required,
no it's not.
anyone running SMP ought to have enough of a clue to compile their own
kernel.
why should everyone else pay the price for their cluelessness?
> and the 686 fl
Herbert Xu wrote:
> With properly constructed dependencies, finding matching packages shouldn't
> be an issue. Please also consider that if the user were to compile his own
> kernel, he would face the problem of having to recompile the modules
> packages if they're needed.
Please explain how prop
On Sun, Apr 29, 2001 at 10:34:03AM +0800, zhaoway wrote:
>
> i vote for alot of binary kernels. but i'd rather see someone comes
> out will better ideas.
if we are voting here, i'd vote for the very minimul number of stock
kernels. if someone wants something more tuned, then roll your own, or
the
> > What about other kernel modules packages that are part of debian?
> > Will we need 6 or 7 pcmcia-modules-2.2.3-* packages, for example?
that's difficult to resolve. take alsa for example.
if user compiles their own kernel, then they will have to compile
their own alsa. since the protocol use
Herbert Xu wrote:
> > Now, my gut instinct says that, as of this moment in time, no one has
> > addressed the building of this initrd, to use at boot time, AFTER
> > installation. Yes, we may have an installation initrd, but, in almost all
> > circles, that is going to be different that what is us
I'm coming in a bit late, but I have not seen this addressed in the
thread: What about other kernel modules packages that are part of
debian? Will we need 6 or 7 pcmcia-modules-2.2.3-* packages, for
example?
If so, that quickly grows beyone unweildly, both in archive size
(Craig's complaints are m
On Fri, Apr 27, 2001 at 09:46:26PM -0400, Joey Hess wrote:
> I'm coming in a bit late, but I have not seen this addressed in the
> thread: What about other kernel modules packages that are part of
> debian? Will we need 6 or 7 pcmcia-modules-2.2.3-* packages, for
> example?
Yes. However, we alrea
On Thu, Apr 26, 2001 at 04:20:46PM +1000, Craig Sanders wrote:
> On Wed, Apr 25, 2001 at 02:18:30AM +1000, Daniel Stone wrote:
> > I could disagree pretty heavily by pointing that this would be shit as
> > it would add an hour to the install. Why not just provide a stock i386
> > kernel and let peo
On Thursday 26 April 2001 08:20, Craig Sanders wrote:
> the point at issue is whether there should be dozens of kernel-image and
> kernel-headers packages when one is enough to do the job.
I'm just a humble Linux-user, but still compile my own kernel. However, I do
this because I'm also a control
On Wed, 25 Apr 2001, Adam Heath wrote:
> On Wed, 25 Apr 2001, Dale Scheetz wrote:
>
> > On Wed, 25 Apr 2001, Wichert Akkerman wrote:
> >
> > > Previously Dale Scheetz wrote:
> > > > Then you break things for no good reason. These "module builders" you
> > > > speak of should be using the same hea
On Wed, Apr 25, 2001 at 08:27:18PM -0400, Josh Huber wrote:
>
> Yes, which is different -- we have 4 kernel-image packages for
I'm open to suggestions as to which of the images can be dropped.
As far as I can see, there are two arguments against the present organisation
on i386:
1. The kernel i
Aaron Lehmann <[EMAIL PROTECTED]> wrote:
> I've said before that over 2000 kernel configuration options exist and
Most of which can be decided at runtime once you start using initrd.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home
On Thu, Apr 26, 2001 at 04:15:24PM +1000, Craig Sanders wrote:
>On Wed, Apr 25, 2001 at 09:56:58PM -0500, Rob Browning wrote:
>> Just in case anyone else was confused, I'm still in favor of having at
>> least *one* precompiled kernel per-architecture, so no one *has* to
>> compile a kernel,
>
>i th
On Wed, Apr 25, 2001 at 02:18:30AM +1000, Daniel Stone wrote:
> I could disagree pretty heavily by pointing that this would be shit as
> it would add an hour to the install. Why not just provide a stock i386
> kernel and let people compile it later on? Some people need to patch
> in mm/swap patches
On Wed, Apr 25, 2001 at 09:56:58PM -0500, Rob Browning wrote:
> Just in case anyone else was confused, I'm still in favor of having at
> least *one* precompiled kernel per-architecture, so no one *has* to
> compile a kernel,
i think everyone is in favour of that.
the issue is whether it's appropr
On 25 Apr 2001 21:56:58 -0500, Rob Browning wrote:
>
> Just in case anyone else was confused, I'm still in favor of having at
> least *one* precompiled kernel per-architecture, so no one *has* to
> compile a kernel, but if they want a customized kernel, then,
> presuming the idea has merit, they wo
Dave Benson <[EMAIL PROTECTED]> writes:
> i'm an idiot. i wasted bandwidth and answered my own question.
Don't worry about it.
Just in case anyone else was confused, I'm still in favor of having at
least *one* precompiled kernel per-architecture, so no one *has* to
compile a kernel, but if they
[from rob browning]
> > prevent us from having a minimal set of kernel packages per arch,
> > maybe even just one, and then having a kernel-custom package that pops
> > up a debconf gui when installed, listing all the available
[from myself]
> [*] now, in fairness i often use the stock kernel anywa
> I think someone else suggested something similar, but what would
> prevent us from having a minimal set of kernel packages per arch,
> maybe even just one, and then having a kernel-custom package that pops
> up a debconf gui when installed, listing all the available
> configurations[1], and once
David Schleef <[EMAIL PROTECTED]> writes:
> I develop/maintain several packages that compile kernel modules
> outside the kernel source, and understand a lot about what is
> necessary to compile modules outside the kernel. I have yet to see
> a header package in any distro that is actually useful
On Wed, Apr 25, 2001 at 08:27:18PM -0400, Josh Huber wrote:
> now what do we have?
>
> kernel-image-version--
To be more complete we could have:
kernel-image
I've said before that over 2000 kernel configuration options exist and
it's obviously not feasable to make a standard binar
On Wed, Apr 25, 2001 at 07:33:50PM -0400, Daniel Jacobowitz wrote:
> On Wed, Apr 25, 2001 at 06:07:50PM -0400, Josh Huber wrote:
> > Craig Sanders <[EMAIL PROTECTED]> writes:
> >
> > > i am, and always have been, talking about the bloated number of
> > > kernel-{image,headers} packages.
> >
> > I
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> Actually, we do have equivalent kernel packages for most of the (e.g.)
> PowerPC variants. There it is a little more necessary than here, since
> the kernels only boot on one flavor. There'll be even more when I
> start building kernel packages on
On Wed, Apr 25, 2001 at 06:07:50PM -0400, Josh Huber wrote:
> Craig Sanders <[EMAIL PROTECTED]> writes:
>
> > i am, and always have been, talking about the bloated number of
> > kernel-{image,headers} packages.
>
> I have to admit, I strongly disagree with having separate packages for
> every fla
> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes:
Herbert> I doubt the increase is going to be that significant.
Herbert> Since most of these will eventually become part of the
Herbert> mainstream kernel or get dropped.
I hope that is not actually the trend we see.
>> im
Craig Sanders <[EMAIL PROTECTED]> writes:
> i am, and always have been, talking about the bloated number of
> kernel-{image,headers} packages.
I have to admit, I strongly disagree with having separate packages for
every flavor of i386 machines. What about the other architectures as
well? Should
On Wed, Apr 25, 2001 at 01:16:51AM -0500, Adam Heath wrote:
> A kernel-module must be built with the EXACT SAME environment as the kernel
> being run. This means they need an EXACT match of headers. The ones that are
> included with glibc are generic, and will NEVER match the running kernel(even
On Wed, 25 Apr 2001, Dale Scheetz wrote:
> On Wed, 25 Apr 2001, Wichert Akkerman wrote:
>
> > Previously Dale Scheetz wrote:
> > > Then you break things for no good reason. These "module builders" you
> > > speak of should be using the same headers as glibc.
> >
> > Absolutely definitely not. User
On Wed, 25 Apr 2001, Wichert Akkerman wrote:
> Previously Dale Scheetz wrote:
> > Then you break things for no good reason. These "module builders" you
> > speak of should be using the same headers as glibc.
>
> Absolutely definitely not. Userland is different from kernelspace,
> and headers need
Previously Dale Scheetz wrote:
> Then you break things for no good reason. These "module builders" you
> speak of should be using the same headers as glibc.
Absolutely definitely not. Userland is different from kernelspace,
and headers need not match at all. Feel free to search debian-devel
or lin
On Wed, 25 Apr 2001, Herbert Xu wrote:
> On Wed, Apr 25, 2001 at 08:54:33AM -0400, Dale Scheetz wrote:
> > On Wed, 25 Apr 2001, Herbert Xu wrote:
> >
> > > That is the raison d'etre for kernel-headers. However, the new per-image
> > > kernel-headers exist solely for the benefit of module builder
On Wed, Apr 25, 2001 at 08:54:33AM -0400, Dale Scheetz wrote:
> On Wed, 25 Apr 2001, Herbert Xu wrote:
>
> > That is the raison d'etre for kernel-headers. However, the new per-image
> > kernel-headers exist solely for the benefit of module builders.
>
> Then you break things for no good reason.
On Wed, 25 Apr 2001, Herbert Xu wrote:
> On Wed, Apr 25, 2001 at 08:18:00AM -0400, Dale Scheetz wrote:
> >
> > The whole purpose of kernel-headers is to provide one, most stable, kernel
> > interface for the distro to build against. The idea was that, by choosing
> > the kernel to compile against
On Wed, Apr 25, 2001 at 08:18:00AM -0400, Dale Scheetz wrote:
>
> The whole purpose of kernel-headers is to provide one, most stable, kernel
> interface for the distro to build against. The idea was that, by choosing
> the kernel to compile against you have the best chance of things working
> corr
On Wed, 25 Apr 2001, Herbert Xu wrote:
> There two discussions here:
>
> 1. The number of kernel flavours.
> 2. The need for kernel-headers for each flavour.
>
> I was talking about 2.
>
The whole purpose of kernel-headers is to provide one, most stable, kernel
interface for the distro to build
ce things back to the point.
> > > You seem to be confusing the kernel-header discussion with the
> > > kernel-image discussion. Please go back and reread the thread.
> >
> > they're one and the same. "kernel-{image,headers} package bloat" has
> >
Please go back and reread the thread.
>
> they're one and the same. "kernel-{image,headers} package bloat" has
> been the topic of this thread from the beginning.
In that case, you're mixing them up as well.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Emai
ead.
they're one and the same. "kernel-{image,headers} package bloat" has
been the topic of this thread from the beginning.
craig
--
craig sanders <[EMAIL PROTECTED]>
GnuPG Key: 1024D/CD5626F0
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
On Tue, Apr 24, 2001 at 10:57:18AM -0500, Adam Heath wrote:
> On Wed, 25 Apr 2001, Daniel Stone wrote:
>
> > > Who says you have to compile debian packages on only machines you own?
> >
> > So tell elmo to get me through, and not, not do anything for 2 months. The
> > only other faster machines I
On Wed, 25 Apr 2001, Daniel Stone wrote:
> > Who says you have to compile debian packages on only machines you own?
>
> So tell elmo to get me through, and not, not do anything for 2 months. The
> only other faster machines I have access to, run RedHat or Mandrake, and I
> can't afford anything be
On Wed, Apr 25, 2001 at 02:40:27AM +0200, Wichert Akkerman wrote:
> Previously Daniel Stone wrote:
> > Linux Kernel Developer
>
> I love this.. the only mention of 'daniel.*stone' in the entire
> kernel is a trivial patch to drivers/sound/sb_card.c..
Plus, numerous Netfilter things, which I have
On Tue, Apr 24, 2001 at 09:33:13AM -0500, Adam Heath wrote:
> On Wed, 25 Apr 2001, Daniel Stone wrote:
>
> > On Wed, Apr 25, 2001 at 09:15:09AM +1000, Herbert Xu wrote:
> > > I think your concerns are not well-founded. If you have a sane build
> > > system, then building them is as simple as a fo
Previously Daniel Stone wrote:
> Linux Kernel Developer
I love this.. the only mention of 'daniel.*stone' in the entire
kernel is a trivial patch to drivers/sound/sb_card.c..
Wichert.
--
/ Generally uninteresting signature - i
On Wed, 25 Apr 2001, Daniel Stone wrote:
> On Wed, Apr 25, 2001 at 09:15:09AM +1000, Herbert Xu wrote:
> > I think your concerns are not well-founded. If you have a sane build
> > system, then building them is as simple as a for loop. Have look at the
> > way kernel-image-i386 is built if you do
On Wed, Apr 25, 2001 at 10:31:06AM +1000, Daniel Stone wrote:
> On Wed, Apr 25, 2001 at 09:15:09AM +1000, Herbert Xu wrote:
> > I think your concerns are not well-founded. If you have a sane build
> > system, then building them is as simple as a for loop. Have look at the
> > way kernel-image-i38
On Tue, Apr 24, 2001 at 05:26:27PM -0700, Aaron Lehmann wrote:
>
> Ok, so why did this come up at all in the discussion of the kernel
> package bloat? It seems to me that providing optimized kernels is a
Because someone asked why the kernel-headers necessary. Their presence
allows both our modul
On Wed, Apr 25, 2001 at 09:15:09AM +1000, Herbert Xu wrote:
> I think your concerns are not well-founded. If you have a sane build
> system, then building them is as simple as a for loop. Have look at the
> way kernel-image-i386 is built if you don't understand what I'm talking
> about.
Not ever
On Wed, Apr 25, 2001 at 09:47:14AM +1000, Herbert Xu wrote:
> No, but they can at least compile one for i386 easily as we're providing
> matching kernel-headers. You're in exactly the same situation
> (i.e., without binary modules) anyway if you compile your own kernel so
> IMHO it's a moot point.
Michael Stone <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 25, 2001 at 09:19:29AM +1000, Herbert Xu wrote:
>> I'm actually referring to all binary modules. But for binary-only modules
>> in particular, since you don't have the luxuary of being able to recompile
>> them, it's even more important to sup
On Tue, Apr 24, 2001 at 04:32:03PM -0700, Aaron Lehmann wrote:
>
> But if I could ask a favor from you, why don't you post a list of
> affected files, and hopefully some description of these and why they
> are changed? There seems to be much confusion about the differences
I won't bore everyone h
On Wed, Apr 25, 2001 at 09:17:35AM +1000, Herbert Xu wrote:
> > One file, composing of a few kilobytes, is an autogenerated header
> > consisting of #define correctives enumerating the configuration.
>
> I think it's fairly clear that you were trying suggest that this is the
> ONLY difference betw
On Wed, Apr 25, 2001 at 09:19:29AM +1000, Herbert Xu wrote:
> I'm actually referring to all binary modules. But for binary-only modules
> in particular, since you don't have the luxuary of being able to recompile
> them, it's even more important to supply the builder with enough information
> assu
On Tue, Apr 24, 2001 at 04:10:51PM -0700, Aaron Lehmann wrote:
>
> "Binary-only" is a misnomer, since one could translate them to ASCII
> or EBDIC if they wanted to. I'm not quite sure whether you're
> describing non-free kernel modules or kernel modules distributed in
> precompiled form (or both
On Tue, Apr 24, 2001 at 04:14:18PM -0700, Aaron Lehmann wrote:
> On Wed, Apr 25, 2001 at 09:06:21AM +1000, Herbert Xu wrote:
> > Bullshit. Why don't you do a diff instead of talking about something that
> > you have no idea about?
>
> Do you deny that the file named autoconf.h contains precicely
On Tue, Apr 24, 2001 at 03:34:40PM -0400, Sam Hartman wrote:
>
> placed by this scheme. My assumption is that there will be different
> modversions for each kernel configuration and that as such, I will
That's correct.
> then my module-specific concerns go away. Even if you accept that the
> b
On Wed, Apr 25, 2001 at 09:06:21AM +1000, Herbert Xu wrote:
> Bullshit. Why don't you do a diff instead of talking about something that
> you have no idea about?
Do you deny that the file named autoconf.h contains precicely what I
suggested? I did not attempt to present an exhaustive description
On Wed, Apr 25, 2001 at 09:05:42AM +1000, Herbert Xu wrote:
> On Tue, Apr 24, 2001 at 02:10:48PM -0700, Aaron Lehmann wrote:
> > If they're binary-only, I doubt much compilation will be necessary.
>
> They don't just come out of nowhere you know...
"Binary-only" is a misnomer, since one could tra
On Tue, Apr 24, 2001 at 02:14:40PM -0700, Aaron Lehmann wrote:
> On Wed, Apr 25, 2001 at 12:33:25AM +1000, Craig Sanders wrote:
> > On Tue, Apr 24, 2001 at 07:30:47PM +1000, Herbert Xu wrote:
> > >
> > > Kernel-headers-2.4.2 is built with the default config file, and the
> > > other ones are built
On Tue, Apr 24, 2001 at 02:10:48PM -0700, Aaron Lehmann wrote:
> On Tue, Apr 24, 2001 at 08:01:39PM +1000, Herbert Xu wrote:
> > So that they can compile them? If you don't understand why we should do
> > that, then there's no point in us two arguing about it.
>
> If they're binary-only, I doubt m
On Wed, Apr 25, 2001 at 12:33:25AM +1000, Craig Sanders wrote:
> On Tue, Apr 24, 2001 at 07:30:47PM +1000, Herbert Xu wrote:
> >
> > Kernel-headers-2.4.2 is built with the default config file, and the
> > other ones are built with their respective config files.
>
> so, what's the difference betwe
On 24 Apr 2001, zhaoway wrote:
> Your point is ridiculous. You think linux kernel compiling is
> something as fundmental as tying shoelaces. rotfl. sorry.
If tying shoelaces was so easy, then why do we have velco shoes?
On Tue, Apr 24, 2001 at 07:30:47PM +1000, Herbert Xu wrote:
> On Tue, Apr 24, 2001 at 08:47:44AM +1000, Craig Sanders wrote:
> >
> > what is the DIFFERENCE between kernel-headers-2.4.2 and all the other
> > 2.4.2 kernel headers packages?
>
> Kernel-headers-2.4.2 is built with the default config f
On Tue, 24 Apr 2001, Aaron Lehmann wrote:
> On Tue, Apr 24, 2001 at 07:27:42PM +1000, Herbert Xu wrote:
> > In any case, binary modules are a fact of life I'm afraid.
>
> Bull. We are Debian, not fucking RedHat or Mandrake. We strive to
> exist without non-free software and using its existance as
On Wed, Apr 25, 2001 at 12:33:25AM +1000, Craig Sanders wrote:
> On Tue, Apr 24, 2001 at 07:30:47PM +1000, Herbert Xu wrote:
> > On Tue, Apr 24, 2001 at 08:47:44AM +1000, Craig Sanders wrote:
> > > what is the DIFFERENCE between kernel-headers-2.4.2 and all the other
> > > 2.4.2 kernel headers pack
On Tue, Apr 24, 2001 at 08:01:39PM +1000, Herbert Xu wrote:
> So that they can compile them? If you don't understand why we should do
> that, then there's no point in us two arguing about it.
If they're binary-only, I doubt much compilation will be necessary.
On Tue, Apr 24, 2001 at 07:27:42PM +1000, Herbert Xu wrote:
> In any case, binary modules are a fact of life I'm afraid.
Bull. We are Debian, not fucking RedHat or Mandrake. We strive to
exist without non-free software and using its existance as an excuse
to make your packages far worse is a compl
[I'm responding to Herbert directly to draw attention to this question
and make sure I get a response from him. I have also read the rest of
this thread even though I am responding to a fairly early message. ]
I'm approaching this as the maintainer of the openafs package, which
has a kernel mod
On Wed, Apr 25, 2001 at 12:36:17AM +1000, Craig Sanders wrote:
> On Sun, Apr 22, 2001 at 09:18:33AM -0500, Adam Heath wrote:
> > [...good stuff deleted...]
> >
> > Now, it doesn't take a genius, to see how this will cascade.
> >
> > [...more good stuff deleted...]
> >
> > The best way to handl
On Sun, Apr 22, 2001 at 09:18:33AM -0500, Adam Heath wrote:
> [...good stuff deleted...]
>
> Now, it doesn't take a genius, to see how this will cascade.
>
> [...more good stuff deleted...]
>
> The best way to handle all this, is to train users how to compile a kernel,
> or, let them pick the
On Tue, Apr 24, 2001 at 07:30:47PM +1000, Herbert Xu wrote:
> On Tue, Apr 24, 2001 at 08:47:44AM +1000, Craig Sanders wrote:
> >
> > what is the DIFFERENCE between kernel-headers-2.4.2 and all the other
> > 2.4.2 kernel headers packages?
>
> Kernel-headers-2.4.2 is built with the default config f
On Tue, Apr 24, 2001 at 10:39:14PM +1000, Herbert Xu wrote:
> On Tue, Apr 24, 2001 at 10:34:24PM +1000, Daniel Stone wrote:
>
> > Oddly enough, I now *start* to see his point. BTW, I have neither the time
> > (p100 with 48meg? multiple kernel builds, each time you build the package,
> > and that'
On Tue, Apr 24, 2001 at 10:34:24PM +1000, Daniel Stone wrote:
> Oddly enough, I now *start* to see his point. BTW, I have neither the time
> (p100 with 48meg? multiple kernel builds, each time you build the package,
> and that's bound to be a few, because of testing?) or the space (multiple
> ker
On Tue, Apr 24, 2001 at 10:30:22PM +1000, Herbert Xu wrote:
> On Tue, Apr 24, 2001 at 10:27:18PM +1000, Daniel Stone wrote:
> >
> > No argument there, but this is where necessity and duplication comes into
> > play. These documentation packages, don't have 14 copies of the same file
> > now, do th
On Tue, Apr 24, 2001 at 10:27:18PM +1000, Daniel Stone wrote:
>
> No argument there, but this is where necessity and duplication comes into
> play. These documentation packages, don't have 14 copies of the same file
> now, do they?
Well, why don't you start writing a patch? And please submit the
On Tue, Apr 24, 2001 at 10:20:33PM +1000, Herbert Xu wrote:
> On Tue, Apr 24, 2001 at 10:14:12PM +1000, Daniel Stone wrote:
> >
> > Let me restate the facts. Again. Very slowly.
> >
> > ftp.au.debian.org was broken.
> > mirror.aarnet.edu.au was broken.
> > Both of the above had outdated packages,
On Tue, Apr 24, 2001 at 10:14:12PM +1000, Daniel Stone wrote:
>
> Let me restate the facts. Again. Very slowly.
>
> ftp.au.debian.org was broken.
> mirror.aarnet.edu.au was broken.
> Both of the above had outdated packages, for their Packages file.
> The kernel packages take up 110meg.
> More meg
On Tue, Apr 24, 2001 at 10:07:03PM +1000, Herbert Xu wrote:
> On Tue, Apr 24, 2001 at 10:02:54PM +1000, Daniel Stone wrote:
> >
> > > That's not what you were claiming though. You said:
> > >
> > > > The thing is, by including all these headers, you're helping break
> > > > stuff for
> > > > ev
On Tue, Apr 24, 2001 at 10:02:54PM +1000, Daniel Stone wrote:
>
> > That's not what you were claiming though. You said:
> >
> > > The thing is, by including all these headers, you're helping break stuff
> > > for
> > > everyone. But you're also helping a small percentage of people who don't
>
On Tue, Apr 24, 2001 at 09:33:52PM +1000, Herbert Xu wrote:
> On Tue, Apr 24, 2001 at 08:45:11PM +1000, Daniel Stone wrote:
> > On Tue, Apr 24, 2001 at 08:20:43PM +1000, Herbert Xu wrote:
> > >
> > > FUD. Show me what's actually broken.
> >
> > Mirrors. Slow. Out-of-sync.
>
> It's still FUD unt
On Tue, Apr 24, 2001 at 08:45:11PM +1000, Daniel Stone wrote:
> On Tue, Apr 24, 2001 at 08:20:43PM +1000, Herbert Xu wrote:
> >
> > FUD. Show me what's actually broken.
>
> Mirrors. Slow. Out-of-sync.
It's still FUD until you produce the evidence that it's caused by the kernel
images.
> > Prov
On Tue, Apr 24, 2001 at 08:20:43PM +1000, Herbert Xu wrote:
> Daniel Stone <[EMAIL PROTECTED]> wrote:
>
> > The thing is, by including all these headers, you're helping break stuff for
> > everyone. But you're also helping a small percentage of people who don't
>
> FUD. Show me what's actually b
On Tue, Apr 24, 2001 at 08:21:28PM +1000, Herbert Xu wrote:
> On Tue, Apr 24, 2001 at 08:18:42PM +1000, Daniel Stone wrote:
> >
> > I can understand why you might say that that's a valid point, but IMHO, we
> > shouldn't fuck up current users (by overloading mirrors), just so we can
> > support LA
On Tue, Apr 24, 2001 at 08:18:42PM +1000, Daniel Stone wrote:
>
> I can understand why you might say that that's a valid point, but IMHO, we
> shouldn't fuck up current users (by overloading mirrors), just so we can
> support LAZY users to compile something THAT IS NOT EVEN IN DEBIAN.
Do you actu
Daniel Stone <[EMAIL PROTECTED]> wrote:
> The thing is, by including all these headers, you're helping break stuff for
> everyone. But you're also helping a small percentage of people who don't
FUD. Show me what's actually broken.
> ftp.au.d.o is currently missing several packages, as is
> mirr
On Tue, Apr 24, 2001 at 08:01:39PM +1000, Herbert Xu wrote:
> On Tue, Apr 24, 2001 at 08:00:01PM +1000, Daniel Stone wrote:
> > If we don't distribute them, why in hell are we breaking mirrors by
> > supporting them? Sounds dodgy to me.
>
> So that they can compile them? If you don't understand wh
On Tue, Apr 24, 2001 at 07:49:48PM +1000, Herbert Xu wrote:
> On Tue, Apr 24, 2001 at 07:47:48PM +1000, Daniel Stone wrote:
> >
> > They still suck, and they're still non-free.
>
> Who said that we were going to distribute them?
If we don't distribute them, why in hell are we breaking mirrors by
On Tue, Apr 24, 2001 at 07:50:34PM +1000, Herbert Xu wrote:
> On Tue, Apr 24, 2001 at 07:49:45PM +1000, Daniel Stone wrote:
> >
> > If you're including the entire headers in every package, this is an awful
> > fallacy. Why not just do something like this:
> > kernel-headers-2.4.3-common: all the 2
On Tue, Apr 24, 2001 at 08:00:01PM +1000, Daniel Stone wrote:
> On Tue, Apr 24, 2001 at 07:49:48PM +1000, Herbert Xu wrote:
>
> > Who said that we were going to distribute them?
>
> If we don't distribute them, why in hell are we breaking mirrors by
> supporting them? Sounds dodgy to me.
So that
1 - 100 of 177 matches
Mail list logo
