Sorry missed your response, just picked it up now from the web archive.
> Are you working with bind 8.X or 9.X?
Jaldhar H. Vyas mentioned he has something working with 8.2.3. I was
only thinking myself with bind8.
As Jaldhar also mentioned, bind9 isn't something I trust yet. Even in a
chroot.
On Sun, Apr 22, 2001 at 07:27:56PM -0800, Ethan Benson wrote:
> put into a chroot is named and named-xfer, apparently named is not
> actually necessary.
Which was my point. Glad we got that settle. ;)
> /etc/init.d/sysklogd is a conffile, sysklogd cannot change it without
> the admin's perm
On Mon, Apr 23, 2001 at 03:11:41AM +0200, Adrian Bunk wrote:
> When a package was only uploaded to stable the bugs aren't closed but
> tagged "woody" instead. When the package goes into testing the bugs get
> closed.
You're cordially invited to work on enhancing the BTS to make this sort of
thing
[ i do read the list so i don't need a CC ]
On Mon, Apr 23, 2001 at 03:12:59PM +1200, Nicholas Lee wrote:
> On Sun, Apr 22, 2001 at 04:54:42PM -0800, Ethan Benson wrote:
> >
> > fine, no disagreement here, what im pointing out is that with at least
> > bind 8 (someone mentioned bind 9 works diffe
On Sun, Apr 22, 2001 at 09:36:23PM -0400, Jaldhar H. Vyas wrote:
>
> Ethan mentioned the method but it cannot be automated which is why I left
> it up to the admin.
Maybe there should be a discussion as to the possibility of a mechanism
to handle this.
Nicholas
On Sun, Apr 22, 2001 at 09:25:14PM -0400, Jaldhar H. Vyas wrote:
> Because I was following the instructions at
> http://www.psionic.com/papers/dns/linux-dns which suggests named and
> named-xfer should go there. I decided to throw the rest in there too. :-)
This is wrong.
>
> But if we don't ne
On Sun, Apr 22, 2001 at 09:43:52PM -0400, Jaldhar H. Vyas wrote:
>
> So change it to more-secure-bind then :-) Or /var/named, whatever is
> thought best.
I guess we'' see what the FHS says. Tho I have no experience with how
quick these guys are.
> Btw, Bdale (Debian Bind maintainer) suggest
On Sun, Apr 22, 2001 at 04:54:42PM -0800, Ethan Benson wrote:
>
> fine, no disagreement here, what im pointing out is that with at least
> bind 8 (someone mentioned bind 9 works differently) its not open to
> debate, you either have bind binaries in the chroot jail or bind
> doesn't work.
No, o
Hi,
I just uploaded a new set of imlib packages linked against xlibs
4.0.2-13. Again, sorry about the mix-up.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Hi,
As many have pointed out, the imlib packages I uploaded are depended
on pre-release debs of X. My apologies. My sources.list still had
Branden's apt site listed in it. I'll upload a new set of imlib
packages right now.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Comput
On Sun, Apr 22, 2001 at 10:15:28PM -0400, Simon Law wrote:
> I'm the lucky new owner of a dual Pentium Pro system. It seems,
> however, that compiling stuff just doesn't use my extra CPU. I know I
> can compile with 'make -j 2' to use the second processor; but I don't
> know how to convince kerne
Hello,
I'm the lucky new owner of a dual Pentium Pro system. It seems,
however, that compiling stuff just doesn't use my extra CPU. I know I
can compile with 'make -j 2' to use the second processor; but I don't
know how to convince kernel-package and dpkg-deb (apt-get source) to
do that
On Mon, Apr 23, 2001 at 03:11:41AM +0200, Adrian Bunk wrote:
> Hi,
>
> I think we have a new problem with the closing of bugs since there is
> testing: Currently, bugs get closed when a package goes into unstable.
> When we'll freeze testing we'll have to check whether the packages that
> closed t
On Sun, 22 Apr 2001, Ethan Benson wrote:
> as a sidenote i think this /var/secure-bind name is lame, it doesn't
> follow any conventions and frankly its naive to think that just
> because bind is chrooted and running as root that its now fully
> secure. more secure yes, a panacea no.
>
So change
On Mon, 23 Apr 2001, Nicholas Lee wrote:
>
> Which brings up an interesting point. Doesn't seem to be provision in
> secure-bind for syslog.
>
>
> In fact a quick test of the binary deb should its not loggin properly.
> I guess there might be two ways to fixing this:
>
> i) get secure-bind to lo
On Sun, Apr 22, 2001 at 09:59:42PM +1000, Craig Sanders wrote:
> >
> > I compile my own kernels, and have for a long time. But it's a pain to
>
> in that case, a far better solution is a package containing a bunch
> of pre-generated kernel .config files, plus a menu script to copy
>
> call it ker
On Sun, 22 Apr 2001 [EMAIL PROTECTED] wrote:
>
>
> Just two questions:
>
> i) Is there any reason why you decided to include the named binaries in
> the chroot?
>
Because I was following the instructions at
http://www.psionic.com/papers/dns/linux-dns which suggests named and
named-xfer should go
On Sat, 21 Apr 2001, Ethan Benson wrote:
> seriously though, it makes alot more sense for your chroot package to
> build a chroot jail, maybe do something about the config files, and
> then just divert the /etc/init.d/bind script elsewhere and replace it
> with one that installs the bind binaries
Hi,
I think we have a new problem with the closing of bugs since there is
testing: Currently, bugs get closed when a package goes into unstable.
When we'll freeze testing we'll have to check whether the packages that
closed the bugs made it into testing or not. This isn't very good. As a
solution
On Mon, Apr 23, 2001 at 11:07:03AM +1200, Nicholas Lee wrote:
>
> Note: I'm not subscribed to -devel at the moment, and probably not for a
> while since its unlikely I have time to read the volume. Please CC:
then please add:
lists debian-devel@lists.debian.org
to your ~/.muttrc so your Mail-
The old way, we had one kernel, optimized for the lowest denonimation of ia32
machine. Ie, i386. We then modified the drivers that were compiled into the
kernel.
Now, using an initrd, we no longer need to compile different variations of
drivers and modules into and out of the kernel. We can co
> this actually *helps* new users.
Why?
I can see your suggestion help mirrors (The trade-off is
questionable.) But I can't see why it could help users.
I certainly don't think that make users (even make the task easier) to
compile a kernel can do help to most of the users (That is *not* a
task
Note: I'm not subscribed to -devel at the moment, and probably not for a
while since its unlikely I have time to read the volume. Please CC:
Ethan Benson <[EMAIL PROTECTED]> mentioned:
> you have to have at least named-xfer.
Of course, but.
> yes there is.
Only named-xfer.
> the way
> I agree that it is not too hard to compile your own kernel.
> I never use Debian's standard kernel-image packages (except on
> my 68K Mac, where it takes too long to recompile).
Hey, hey, it's for you! Do you guys really expect all Debian users ==
Debian develoepers? What about k12 users? What a
On Sun, Apr 22, 2001 at 03:36:02PM -0700, Aaron Lehmann wrote:
> On Mon, Apr 23, 2001 at 08:33:43AM +1000, Craig Sanders wrote:
> > is there such a thing as cross-compilation for the kernel?
>
> Yes - porting to new architectures would be nearly impossible
> otherwise.
yep, true...but is it deep
On Mon, Apr 23, 2001 at 08:33:43AM +1000, Craig Sanders wrote:
> is there such a thing as cross-compilation for the kernel?
Yes - porting to new architectures would be nearly impossible
otherwise.
kernel-package even supports cross-compilation IIRC.
On Mon, Apr 23, 2001 at 08:00:50AM +1000, Hamish Moffatt wrote:
> I do that too; what's the oldconfig step needed for though? I just
> jump straight to menuconfig and it always seems OK.
i find it easier to deal with new config questions. it uses your old
answers as input for any questions, and on
On Sun, Apr 22, 2001 at 10:23:04PM +1000, Herbert Xu wrote:
> > in that case, a far better solution is a package containing a bunch
> > of pre-generated kernel .config files, plus a menu script to copy
> > [...]
> > that would be one package, taking maybe a few hundred kilobytes total.
> > call it
On Sun, Apr 22, 2001 at 10:16:36PM +1000, Herbert Xu wrote:
> We clearly disagree, so let's leave it at that.
no.
> > just as you stated you'd be filing bug-reports to get 2.2.17 kernel
> > image removed from the archive, i'll be filing "package should not
> > exist" bugs against all the excess k
On Sun, Apr 22, 2001 at 01:00:02PM +, Andreas Metzler wrote:
> What *is* the difference between eg. kernel-headers-2.4.3-686 and
> kernel-headers-2.4.3-k6?
not much:
[EMAIL PROTECTED] eb]$ diff -rq /usr/local/src/linux-2.2.19/include
/usr/src/kernel-headers-2.2.19/include
Only in /usr/src/ke
On Sun, Apr 22, 2001 at 01:24:43PM -0500, Taral wrote:
> I'm packaging acl2, which can take several hours to compile on a PPro
> 200. Would it be reasonable to exclude certain architectures as too
> slow? (acl2 is a theorem prover.)
eg your PPro 200? :-)
Hamish
--
Hamish Moffatt VK3SB <[EMAIL P
Package: wnpp
Severity: wishlist
Garlic, a free molecular visualization program written for unix and
unix clones. Garlic was written by Damir Zucic, at the University of
Osijek.
The latest version of garlic may be found at:
http://pref.etfos.hr/garlic
--
http://dim.sourceforge.net .
Package: wnpp
Severity: normal
drscheme has quite some porting related bugs. and the upstream is
moving fast to v200.
i hereby orphan this package for i didn't use it for a long time. and
i have to get more time work on other tasks which i have more
interests. (for now at least. ;)
thanks,
--
h
On Sun, Apr 22, 2001 at 09:59:42PM +1000, Craig Sanders wrote:
> btw, if you've been compiling your own kernels for a long time then you
> probably do somthing similar to what i do - copy in the .config from the
> previous version and run "make oldconfig" before "make menuconfig" and
> make-kpkg. i
Hi there,
On Mon, Apr 23, 2001 at 07:38:18AM +1000, Herbert Xu wrote:
> I think you've missed the point. We're not talking about what is going
> to be the standard kernel image for woody. We're discussing the way the
> kernel images are constructed on i386, which happens to only apply to
> 2.4 at
Steve M. Robbins <[EMAIL PROTECTED]> wrote:
> Independent of whether or not Xu uploads a dozen pre-compiled kernels,
> it would be nice to have their configs readily available. I would
> appreciate an easy way of seeing what tweaks are recommended to
> optimize for an i686 machine.
They already
Andreas Metzler <[EMAIL PROTECTED]> wrote:
> Are these *really* necessary? Who does need them, people who compile
Yes. By all module builders, especially those outside Debian.
> external kernel-modules (alsa, lm-sensors, ...)? Can't these
> people simply install kernel-source, extract it to /tm
David Spreen <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 22, 2001 at 10:16:36PM +1000, Herbert Xu wrote:
>> With the latest release, it's now down to about 80MB. In any case, we
>> never release with more than one old kernel, nor with experimental kernels,
>> so that would be 1 x 2.2.x, and at most 2
On 22 Apr 2001 20:22:10 +0200, Leon Breedt wrote:
> Hi,
>
> DopeWars is a kickarse curses based game that supports
> multiplayer, its under the GPL and can be found at:
>
> http://bellatrix.pcl.ox.ac.uk/~ben/dopewars/
>
> If no one objects, I'll package it.
>
Sweet! I'm kind of surprised no on
On Apr 22, Ethan Benson <[EMAIL PROTECTED]> wrote:
>> i) Is there any reason why you decided to include the named binaries in
>> the chroot?
>you have to have at least named-xfer.
Not with BIND 9. Another reason to use BIND 9.
--
ciao,
Marco
On Sun, Apr 22, 2001 at 02:47:36PM +0200, Roland Mas wrote:
> Nonono, we should automate it as much as possible. I envision a
> global Makefile somewhere, and a ports/ directory, and a
> make-world.sh, and... And then Debian GNU/BSD! Yay!
I've been spending a lot of time starting to design a po
On Sun, Apr 22, 2001 at 09:44:01PM +1000, Craig Sanders wrote:
> just as you stated you'd be filing bug-reports to get 2.2.17 kernel
> image removed from the archive, i'll be filing "package should not
> exist" bugs against all the excess kernel-image bugs.
Alternatively, you could bring it up wit
ALL RIGHT, YOU JACKASSES, STOP COMPILING AGAINST UNRELEASED PACKAGES.
Everyone else, please file serious bugs against any packages you find doing
this. "Cannot build from source" is exactly what they are, and that's a
release critical bug.
4.0.3-1 will be out when it's ready, which will hopefull
On Sun, Apr 22, 2001 at 08:31:55PM +0200, Wichert Akkerman wrote:
> Previously Taral wrote:
> > I'm packaging acl2, which can take several hours to compile on a PPro
> > 200. Would it be reasonable to exclude certain architectures as too
> > slow? (acl2 is a theorem prover.)
>
> No.
Argeed. Lots
>I'm packaging acl2, which can take several hours to compile on a PPro
>200. Would it be reasonable to exclude certain architectures as too
>slow? (acl2 is a theorem prover.)
No. The porters can make up their own minds about whether it's worth
compiling for their architecture. We already have p
Previously Taral wrote:
> I'm packaging acl2, which can take several hours to compile on a PPro
> 200. Would it be reasonable to exclude certain architectures as too
> slow? (acl2 is a theorem prover.)
No.
Wichert.
--
/ Genera
I'm packaging acl2, which can take several hours to compile on a PPro
200. Would it be reasonable to exclude certain architectures as too
slow? (acl2 is a theorem prover.)
--
Taral <[EMAIL PROTECTED]>
Please use PGP/GPG encryption to send me mail.
"Any technology, no matter how primitive, is magi
On Sat, 21 Apr 2001 10:39:02 -0400 (EDT), "Jaldhar H. Vyas"
<[EMAIL PROTECTED]> wrote:
>On 21 Apr 2001, Bdale Garbee wrote:
>> I have no great inspirations about where to park chroot's, either. I don't
>> think it is well handled, if at all, by current policy. The buildd machines
>> I've looked a
Hi,
DopeWars is a kickarse curses based game that supports
multiplayer, its under the GPL and can be found at:
http://bellatrix.pcl.ox.ac.uk/~ben/dopewars/
If no one objects, I'll package it.
Cheers,
Leon.
--
[EMAIL PROTECTED]
http://neverborn.org
fam, the File Alteration Monitor from SGI, will be used by both E 0.17
and the upcoming Nautilus 1.0.3 / 1.2, whatever they will finally call
it.
http://oss.sgi.com/projects/fam
Guess I'll take a stab at this. Will post the URL when done - I don't
intend to jumpstart anything, just avoiding dupli
On Sun, Apr 22, 2001 at 06:23:43PM +0200, Marco d'Itri wrote:
> On Apr 21, Yotam Rubin <[EMAIL PROTECTED]> wrote:
>
> >We could harden the default configuration with the following directives:
> >
> >version 'Not available';
> This does not harden anything and just makes debugging harder.
>
On Apr 21, Yotam Rubin <[EMAIL PROTECTED]> wrote:
>We could harden the default configuration with the following directives:
>
> version 'Not available';
This does not harden anything and just makes debugging harder.
Don't dare putting something like this in the default configuration of a
d
On Sat, Apr 21, 2001 at 11:50:44AM -0700, John H. Robinson, IV wrote:
> On Sat, Apr 21, 2001 at 11:41:56AM -0700, Alexander Hvostov wrote:
> > On Sat, 21 Apr 2001 11:40:15 -0700 "John H. Robinson, IV" wrote:
> >
> > > however, on something like boot-floppies, this might be a
> > > goddess-send.
>
On Sat, Apr 21, 2001 at 10:49:20PM -0700, Joseph Carter wrote:
> From then on (sorry, I know of no other way) you will simply have to get a
> list of installed packages (dpkg --get-selections, you can use cut or sed
> and grep or something to cut the list down to just the ones you want) and
> feed
Herbert Xu <[EMAIL PROTECTED]> wrote:
[snip]
>> P.S. Is a seperate kernel-headers package really necessary for
>> every CPU type? What are the differences between the headers in,
>> say kernel-headers-2.4.3-686 and kernel-headers-2.4.3-686-smp?
>> Or kernel-headers-2.4.3-k6 and kernel-headers-2.4.3
On Sun, 22 Apr 2001 06:02:30 -0800, Ethan Benson wrote:
> On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote:
> > If not, I suggest a debhelper command to add the necessary code to
> > the postinst. Packages that use this should, of course, depend on the
> > binary-compressing package,
On Sun, Apr 22, 2001 at 02:47:36PM +0200, Roland Mas wrote:
> Herbert Xu (2001-04-22 22:23:04 +1000) :
> > Craig Sanders <[EMAIL PROTECTED]> wrote:
> >
> > > that would be one package, taking maybe a few hundred kilobytes
> > > total. call it kernel-helper and make it depend on
> > > kernel-packa
On Sun, Apr 22, 2001 at 10:23:04PM +1000, Herbert Xu wrote:
> Craig Sanders <[EMAIL PROTECTED]> wrote:
>
> > in that case, a far better solution is a package containing a bunch
> > of pre-generated kernel .config files, plus a menu script to copy
> > your choice to the right subdirectory (e.g. /us
On Sun, Apr 22, 2001 at 09:59:42PM +1000, Craig Sanders wrote:
> On Sun, Apr 22, 2001 at 12:09:12AM -0500, David Starner wrote:
> > On Sat, Apr 21, 2001 at 09:28:02PM -0500, Rahul Jain wrote:
> > > Unless you care about performace. Which is the main reason to use
> > > different packages for each C
On Sun, Apr 22, 2001 at 09:59:42PM +1000, Craig Sanders wrote:
> On Sun, Apr 22, 2001 at 12:09:12AM -0500, David Starner wrote:
> > On Sat, Apr 21, 2001 at 09:28:02PM -0500, Rahul Jain wrote:
> > > Unless you care about performace. Which is the main reason to use
> > > different packages for each C
On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote:
>
> If not, I suggest a debhelper command to add the necessary code to
> the postinst. Packages that use this should, of course, depend on the
> binary-compressing package, which would provide the one-time question
why should they de
On Sun, Apr 22, 2001 at 10:16:36PM +1000, Herbert Xu wrote:
> With the latest release, it's now down to about 80MB. In any case, we
> never release with more than one old kernel, nor with experimental kernels,
> so that would be 1 x 2.2.x, and at most 2 x 2.4.x.
This sucks. Hopefully not only in
On Sun, 22 Apr 2001 00:57:54 +0200, <[EMAIL PROTECTED]> wrote:
> On Sunday 22 April 2001 00:45, Itai Zukerman wrote:
> > Why not compress the binaries in the postinst, maybe after asking the
> > admin for permission?
>
> Well, if I had to answer "no" to compression for binary in every new package
Herbert Xu (2001-04-22 22:23:04 +1000) :
> Craig Sanders <[EMAIL PROTECTED]> wrote:
>
> > that would be one package, taking maybe a few hundred kilobytes total.
>
> > call it kernel-helper and make it depend on kernel-package.
>
> > problem solved.
>
> But why not take this one step further, l
On Sat, 21 Apr 2001, Antti-Juhani Kaijanaho wrote:
> On 20010419T170915+0200, Santiago Vila wrote:
> > On 18 Apr 2001, James Troup wrote:
> > > making broken assumptions based on random things like the signature on
> > > the file.
> >
> > "A gpg signature is a random thing" --Debian gnupg maintain
Previously Roland Mas wrote:
> Call me stupid if you like, but I think "all goes into modules"
> won't work.
It does if you use initrd.
Wichert.
--
/ Generally uninteresting signature - ignore at your convenience \
| [EMAIL
Herbert Xu (2001-04-22 14:15:50 +1000) :
> Yes you should. But then most people would be happy to have all of
> the above as modules.
I used to put plenty of things in modules. I even put ext2 in a
module, three or four times. Wham, kernel panic at boot. Okay, I
thought I wouldn't do the same
Craig Sanders <[EMAIL PROTECTED]> wrote:
> in that case, a far better solution is a package containing a bunch
> of pre-generated kernel .config files, plus a menu script to copy
> your choice to the right subdirectory (e.g. /usr/local/src/linux or
> wherever)...then run "make menuconfig" or "make
On Sun, Apr 22, 2001 at 09:44:01PM +1000, Craig Sanders wrote:
>
> i disagree with you primarily because the cost of having so many
> kernel-image packages is too high.
That is your opinion, and I disagree with it.
> that cost is over 100MB per kernel version, that's several hundred MB
> with se
On Sun, Apr 22, 2001 at 12:09:12AM -0500, David Starner wrote:
> On Sat, Apr 21, 2001 at 09:28:02PM -0500, Rahul Jain wrote:
> > Unless you care about performace. Which is the main reason to use
> > different packages for each CPU type.
>
> I compile my own kernels, and have for a long time. But it
On Sun, Apr 22, 2001 at 01:38:42PM +1000, Herbert Xu wrote:
> > if the user needs a more specific kernel (e.g. with SMP or compiled
> > for a P2 or a K6 or whatever) then they can use manoj's excellent
> > kernel-package (one of debian's best features, IMO) to build a
> > custom kernel.
>
> This is
On Sun, Apr 22, 2001 at 08:50:45PM +1200, [EMAIL PROTECTED] wrote:
>
>
> Just two questions:
>
> i) Is there any reason why you decided to include the named binaries in
> the chroot?
you have to have at least named-xfer.
> There is no need for them to be there, since named does the chroot
Michael Banck <[EMAIL PROTECTED]> wrote:
> Fair enough. But what about the difference between machine-dependant
> optimisation? Perhaps the difference between i386 and PIII is so minimal
Please read the earlier messages in this thread. This has already been
covered.
--
Debian GNU/Linux 2.2 is o
Hello,
I apologise if this is considered off-topic - might be barking up the
wrong tree in the wrong forest here - but bringing up an old issue here
of release frequency, once the transition to using package pools and the
new debian-installer is done, would it be reasonable to expect Debian
releas
On Sun, Apr 22, 2001 at 01:38:42PM +1000, Herbert Xu wrote:
> IMHO, with the current 2.4.* setup, the difference between compiling your
> own and using the preexisting one is so minimal that most people will be
> able to use the precompiled one rather than building their own.
Fair enough. But wh
Hello,
I am running Sid (daily updated) and currently have a problem with Gnome:
Before I could access the programm menus with the keyboard shortcuts
(Alt + undelined_character). This worked with all Gnome apps under
any window manager. It still works with KDE apps, but since a few
days the Gnome
Just two questions:
i) Is there any reason why you decided to include the named binaries in
the chroot?
There is no need for them to be there, since named does the chroot
internal. In fact this might represent a security hole.
Consider some manages to break named and get access to the chroo
On Sun, Apr 22, 2001 at 12:37:16AM -0500, Rahul Jain wrote:
> use the distro kernels' config as a starting point.
Which wins me how much, over just starting from the defaults? You
still have to go over all the options, and wait for the kernel to
compile. It's still a lot easier to break stuff man
On Sat, Apr 21, 2001 at 07:42:00PM -0300, Carlos Laviola wrote:
> There is: just upx -d it. (you can even run md5sum before and after
> compression/decompression to find out for yourself that the decompressed file
> is the same as before.)
Will upx -d work on a binary that was compressed with an o
"WWT" == Wesley W Terpstra <[EMAIL PROTECTED]> writes:
[...]
WWT> Anyways, here's the easy fix. In configure.in find:
[...]
WWT> Anyways, you have a fix that works now. Please try it yourself and let me
WWT> know whether or not it works out. Oh, I had to tweak all the Build-Depends
WWT> to
> > > I should build my own kernel, right?
> >
> > Sure, you're a computer geek. But remember we don't expect our
> > users to be all computer elites. No, they're no dummies. Think
> > about scientists, etc. who just simply don't have that much enough
> > time sometimes to make oneself be familia
On Sun, Apr 22, 2001 at 12:07:37AM +0200, Klaus Reimer wrote:
> My harddisk containing /var has crashed (and I am a fool without a backup). I
> was able to recover /var/lib/dpkg/status but all other files in /var/lib/dpkg
> except some files from /var/lib/dpkg/info are gone. Is there any way to
On Sun, Apr 22, 2001 at 12:09:12AM -0500, David Starner wrote:
> On Sat, Apr 21, 2001 at 09:28:02PM -0500, Rahul Jain wrote:
> > Unless you care about performace. Which is the main reason to use different
> > packages for each CPU type.
>
> I compile my own kernels, and have for a long time. But i
On Sat, Apr 21, 2001 at 09:28:02PM -0500, Rahul Jain wrote:
> Unless you care about performace. Which is the main reason to use different
> packages for each CPU type.
I compile my own kernels, and have for a long time. But it's a pain
to go through all the poorly-documented options and takes quit
84 matches
Mail list logo
