Re: Storage (8*IDE HDs) any experiences?

[Brandon High]

On Thu, Apr 26, 2001 at 09:42:16PM -0400, [EMAIL PROTECTED] wrote:
> IDE causes a bit of a performance hit, I don't think we're talking high
> speed file access here though... cheap is the objective.

You'd be suprised at the performance hit. I had 2 drives/channel and
suffered from really bad performance with the on-board Ultra66 controller. I
installed a PCI controller (Promise Ultra 66) and put every drive on its own
channel. Things are much happier now and about 3x faster. The best part is
that the card only costs about $25.

You might be better off getting a more reliable motherboard, such as an ASUS
CUSL2 (for Intel) or ASUS A7V133 (For AMD) and putting PCI controllers in.

-B

-- 
Brandon High [EMAIL PROTECTED]
Money can't buy love. But it CAN rent a very close imitation.

Re: New X problems...

[Dale Scheetz]

Yes, I have no NFS, I have no NFS today...   ;-)

Ah, the joys of living under an IT department. I hear tales from my son
all the time. He works in development and has to defeat a lot of IT stuff
that keeps finding its way onto his machine every time he docks it at
work. (Better him than me ;-)

My xterm and bash windows come up just fine (don't crash like yours), but
they don't have any content. No prompt, no cursor, nothing but black.

With mozilla I could log into http://www.linuxbase.org/spec/ just fine,
but I couldn't download anything. The dialog box for choosing an alternate
file name and saving it, comes up just fine, but when you click on OK, it
reports "Connection refused ..."

After bumping into never before seen problems with an installation attempt
(I have other issues I'd like to resolve as well as this one) I did the
more obvious thing, and reverted to my previous 2.2.17 kernel.

Everything works peachy keen fine!

David, from your comments below, you seem to be using kpkg, while I use
make. I got my 2.2.19 source from ftp.kernel.org, and, after a bit of
unusual bother untarring it, did 'make mrproper ; make menuconfig'. At
this point I had to go get ncurses4-dev ... somehow it failed to upgrade
last time...

Anyway, I usually work through every option in the config menu. I like the
menuconfig option because it is easy to go back and forth between various
areas of configuration. I make as much as I can with modules (keeping only
enough to boot with as "built in"), and these days almost always have to
go back at least once to trim some fat out so I can get a zImage. (this
appears to be just a perverse bit of stubbornness on my part ;-)

So it looks like I need to go back and look at some of that "fat" I
trimmed and see what happens with a less anorexic kernel. I was just
hoping that someone would see the symptoms, and say "Oh, those things
depend upon bla-bla-bla so that's where the problem is." But I guess I'll
just have to put in the time...

David, see additional comments below:

On Thu, 26 Apr 2001, David A. Greene wrote:

> Dale Scheetz wrote:
> 
> > Now, when I bring up and xterm or a bash window, I get no cursor and no
> > keystrokes appear in the window. I'm also having very flaky problems with
> 
> I have had problems with this as well.  I tracked it down to
> NFS/amd not working properly.  This has been a problem on my
> laptop for about a year now but NFS is not so critical that
> I've had time to go fix the problem.  It seems odd, though,
> that maps provided by our IT department don't work on my
> woody laptop, but work on other machines on the network (running
> potato). I'm guessing this is a configuration problem on my end,
> though.  In any event, disabling amd solved it for me.

I don't use NFS myself, but from what others have said it is not the most
robust system because of various issues. YMMV

> 
> Hmm...After re-reading your message, I think I misunderstood you.
> My problem is that the terminal session hangs (nothing is displayed
> at all, and no, there are no references to NFS mounts in my
> startup files).  It sounds like you're having strictly input
> problems.

Well, we may actually have the same problem for different reasons. It
sounds like your symptoms match mine, although I'm not sure I'd use the
word "hangs", as I can close the window. There is just nothing in the
window, and not action at the keyboard changes that...

Switching kernels fixes it for me, so this isn't an X config issue.

> 
> > mozilla not being able to get into simple web pages and download material.
> > (I'm trying to get the current LSB spec)
> 
> Now _this_ I just recently (i.e. today) started seeing more
> often. My laptop (Dell Latitude CPx/J) has always had problems
> with the Vortex card after a BIOS resume.  For one thing, the
> routes take forever to come back (i.e. 'route' hangs for a
> minute or more before being able to resolve to DNS). Today,
> however, I saw something new.  I dist-upgraded testing and
> rebooted with a freshly-compiled 2.2.17 (no configuration changes,
> just a kpkg --revision change so it doesn't conflict with
> the standard packages).  After a BIOS suspend/resume cycle,
> the network was extremely flaky.  As usual, route took forever.
> Once I was able to ping a host, I left it running and used mozilla
> to access the network through both the WWW and IMAP clients.
> In both cases, as soon as mozilla took any action, the network
> was lost and the pings stopped going through.
> 
It sounds like you have a combination of complex local net that you must
"get out of", and possibly some flakey hardware. You also may not have
power management properly configured in your kernel.

> Strangely enough, I just now resumed the machine again and everything
> seems fine.  In general, the Vortex/Cardbus/SOMETHING has always
> been very flaky for me, but today was the first time I could
> _consistently_ bring the network down.  Until I suspended/resumed
> again, of course.  :(

Re: [doko@cs.tu-berlin.de: Bug#95285: Incorrect globbing under locales]

[Joey Hess]

Paul Martin wrote:
> Seems like it's documented behaviour for bash. Pity I had to file a bug
> to find this out.

RGHHH!

I'm cc-ing -devel to let others read about this ugly ugly thing. And
going to fix rpm's debian/rules file to use [:lower:] instead of [a-z].
Sigh.

> Looks like it would be a good idea to add "export LC_ALL=POSIX" to the
> default dh_make "rules" file.

Well, we _could_ do that. It would probably have nasty effects if you
expected to be able to build a package and see errors in your native
language though.

> - Forwarded message from Matthias Klose <[EMAIL PROTECTED]> -
> 
> Envelope-to: [EMAIL PROTECTED]
> From: Matthias Klose <[EMAIL PROTECTED]>
> To: Paul Martin <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Bug#95285: Incorrect globbing under locales
> 
> Paul Martin writes:
>  > Package: bash
>  > Version: 2.05-2
>  > Severity: important
>  > 
>  > This behaviour exists on my machine. However I ran these tests on one of
>  > the Debian machines, just to prove it wasn't any configuration fault of
>  > mine.
> 
> See the COMPAT file, 14:
> 
> 14. The behavior of range specificiers within bracket matching expressions
> in the pattern matcher (e.g., [A-Z]) depends on the current locale,
> specifically the value of the LC_COLLATE environment variable.  Setting
> this variable to C or POSIX will result in the traditional ASCII behavior
> for range comparisons.  If the locale is set to something else, e.g.,
> en_US (specified by the LANG or LC_ALL variables), collation order is
> locale-dependent.  For example, the en_US locale sorts the upper and
> lower case letters like this:
> 
> AaBb...Zz
> 
> so a range specification like [A-Z] will match every letter except `z'.
> 
> The portable way to specify upper case letters is [:upper:] instead of
> A-Z; lower case may be specified as [:lower:] instead of a-z.
> 
> Look at the manual pages for setlocale(3), strcoll(3), and, if it is
> present, locale(1).
> 
> You can find your current locale information by running locale(1):
> 
> caleb.ins.cwru.edu(2)$ locale
> LANG=en_US
> LC_CTYPE="en_US"
> LC_NUMERIC="en_US"
> LC_TIME="en_US"
> LC_COLLATE="en_US"
> LC_MONETARY="en_US"
> LC_MESSAGES="en_US"
> LC_ALL=en_US
> 
> My advice is to put
> 
> export LC_COLLATE=C
> 
> into /etc/profile and inspect any shell scripts run from cron for
> constructs like [A-Z].  This will prevent things like
> 
> rm [A-Z]*
> 
> from removing every file in the current directory except those beginning
> with `z' and still allow individual users to change the collation order.
> Users may put the above command into their own profiles as well, of 
> course.
> 
> - End forwarded message -
> 
> -- 
> Paul Martin <[EMAIL PROTECTED]> (work)
>   <[EMAIL PROTECTED]> (home)
> <[EMAIL PROTECTED]> (Debian stuff)

-- 
see shy jo, retching

Bug#95388: ITP: HP (HyperBuilder): dynamic HTML parser and generator with bindings in C, perl and Scheme

[Frederico S. Muñoz]

Package: wnpp
Severity: wishlist

Description: HB is an information system designed used to build web
sites dynamically. It is intended to be run by the web server, parsing
documents whenever they are requested (usually via HTTP). Using HB you
can create dynamic web content in a very easy (yet very powerful) way.
HB features support for multiple SQL databases (PostgreSQL and MySQL
at the moment) and can be extended using C, Perl and Guile (and there
are plans to support Java. Can be use to generate HTML content for
latter deployement in a server.

License: GPL v2

Homepage: http://bachue.com/hb/hb.cgi/

Download: http://bachue.com/hb/hb.cgi/download


Cheers,

fsm
Package: wnpp
Severity: wishlist

Description: HB is an information system designed used to build web
sites dynamically. It is intended to be run by the web server, parsing
documents whenever they are requested (usually via HTTP). Using HB you
can create dynamic web content in a very easy (yet very powerful) way.
HB features support for multiple SQL databases (PostgreSQL and MySQL
at the moment) and can be extended using C, Perl and Guile (and there
are plans to support Java. Can be use to generate HTML content for
latter deployement in a server.

License: GPL v2

Homepage: http://bachue.com/hb/hb.cgi/

Download: http://bachue.com/hb/hb.cgi/download


Cheers,

fsm

-- 
Frederico S. Mu?oz  GNU http://www.gnu.org
[EMAIL PROTECTED]   Debian  http://www.debian.org

http://sdf.lonestar.org - SDF Public Access Unix Systems


pgpfhjbOedoeM.pgp
Description: PGP signature

Re: Storage (8*IDE HDs) any experiences?

[mdanish]

On Thu, Apr 26, 2001 at 08:02:30PM -0500, Rahul Jain wrote:
> On Thu, Apr 26, 2001 at 01:39:01PM -0500, Dimitri Maziuk wrote:
> > Hi all
> > 
> > I notice there are these new-fangled motherboards with 2*ATA-100 and
> > 2*ATA-33 ports. With 75GB disks, that baby should give us 600GB of raw
> > disk space (8 drives) at around $2K US. Sounds attractive, considering
> > that el-cheapo RAID boxes of similar capacity are around $10K.
> > 
> > Anyone runs [Debian] Linux on an 8-drive box like that? Is that
> > supported at all? Any gotchas I should know about? The mobo I'm looking
> > at is ABIT BH6-II.
> 
> Be warned of the issues with having two hard drives per IDE channel. I know
> that there were reports of massive corruption when using DMA with specific
> models of WDC and Maxtor drives on the same channel in DMA mode. You'll also
I've heard bad things about WDC and Maxtor drives in general, been sticking
with IBM for the most part (except for this Quantum Fireball AS).

> face some pretty serious performance slowdowns when accessing both drives at
> the same time, since most IDE drives cannot do disconnect/reconnect like SCSI
> drives can. The best way would be to have one IRQ used for each IDE drive,
> which is pretty tough to do on an x86 system. Hopefully your BIOS can allow
> this sort of setup, since IRQ sharing still causes a bit of a performance hit.
IDE causes a bit of a performance hit, I don't think we're talking high
speed file access here though... cheap is the objective.

> 
> -- 
> -> -/-   - Rahul Jain -   -\- <-
> -> -\- http://linux.rice.edu/~rahul -=- mailto:[EMAIL PROTECTED] -/- <-
> -> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
> |--||--||-|--|-|-|-|
>Version 11.423.999.220020101.23.50110101.042
>(c)1996-2000, All rights reserved. Disclaimer available upon request.
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
;;
;; Matthew Danish email: [EMAIL PROTECTED] ;; 
;; GPG public key available from:'finger [EMAIL PROTECTED]' ;;
;;


pgp26gThDjtGC.pgp
Description: PGP signature

Re: Storage (8*IDE HDs) any experiences?

[Rahul Jain]

On Thu, Apr 26, 2001 at 01:39:01PM -0500, Dimitri Maziuk wrote:
> Hi all
> 
> I notice there are these new-fangled motherboards with 2*ATA-100 and
> 2*ATA-33 ports. With 75GB disks, that baby should give us 600GB of raw
> disk space (8 drives) at around $2K US. Sounds attractive, considering
> that el-cheapo RAID boxes of similar capacity are around $10K.
> 
> Anyone runs [Debian] Linux on an 8-drive box like that? Is that
> supported at all? Any gotchas I should know about? The mobo I'm looking
> at is ABIT BH6-II.

Be warned of the issues with having two hard drives per IDE channel. I know
that there were reports of massive corruption when using DMA with specific
models of WDC and Maxtor drives on the same channel in DMA mode. You'll also
face some pretty serious performance slowdowns when accessing both drives at
the same time, since most IDE drives cannot do disconnect/reconnect like SCSI
drives can. The best way would be to have one IRQ used for each IDE drive,
which is pretty tough to do on an x86 system. Hopefully your BIOS can allow
this sort of setup, since IRQ sharing still causes a bit of a performance hit.

-- 
-> -/-   - Rahul Jain -   -\- <-
-> -\- http://linux.rice.edu/~rahul -=- mailto:[EMAIL PROTECTED] -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--||--||-|--|-|-|-|
   Version 11.423.999.220020101.23.50110101.042
   (c)1996-2000, All rights reserved. Disclaimer available upon request.

Re: Problem with installing Postgres throught APT

[Rahul Jain]

On Thu, Apr 26, 2001 at 02:03:00PM +0100, Oliver Elphick wrote:
> It hasn't stopped its being installed on my system or on a number of others.
> I found the conflict was necessary to force the removal of libpgsql2, but
> it does indeed provide libpgsql2 to other packages that depend on that.
> 
> I feel there must be some other problem with your system.

I had a horrible time upgrading and I ended up removing some packages with
--force-depend, and then apt-get dist-upgrading. Would adding a replaces: to
some packages help? I know that the pgsql-pl and ecpg packages were merged, so
at least it will help there.

-- 
-> -/-   - Rahul Jain -   -\- <-
-> -\- http://linux.rice.edu/~rahul -=- mailto:[EMAIL PROTECTED] -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--||--||-|--|-|-|-|
   Version 11.423.999.220020101.23.50110101.042
   (c)1996-2000, All rights reserved. Disclaimer available upon request.

Re: Storage (8*IDE HDs) any experiences?

[Alvin Oga]

hi dima

think different motherboard uses different onboard ide controllers...
( dont know which one is which...

- promise card i was referring to is the Proise ata/100 series
  not the onboard controllers

yes... most 1U chassis comes with one 1 power supply...
( no physcial room in the back... 

-- sorta offtopic...but thought i'd add the comments 
-- and we can discuss offline if needed...

one 1u manufacturer put a powersupply in front and 
one powersupply in the back...

- a neater option would have been to use the newer mini-atx 
  motherboard...about 8"x8" square... which still have room
  for 2 1u powersupply in the back...

- even if you had 2 power supplies...
- most motherboards only has one atx power connector

- are the two power supplies properly doing load sharing...
- when/how does the redundant power circuit kill 
off the other dying/dead power supply

- if the motherboard did have 2 atx connectors...
- is it doing proper load sharing???
- can the 2nd power supply drive the motherboard
even if the other powersupply is dead

- if you had two power supplies...
- how does the disk gets it spower...
( need special circuitry to drive the disks
( minimally, 2 diodes for each of the power supply

fun stuff
alvin
http://www.Linux-1U.net ...

On Thu, 26 Apr 2001, Dimitri Maziuk wrote:

> On Thu, Apr 26, 2001 at 03:23:03PM -0700, Alvin Oga wrote:
> ...
> > your options for 6 or 8 disks are the promise cards
> > and/or 3ware ...
> 
> Well, unfortunately purchasing is a bit strange around here...
> That mobo (with HPT-370 controller) is the one we can buy
> _easily_ -- from the university's techstore. A mobo with
> promise is a bit more difficult...
> 
> > has anybody measured the +12V current needed when all
> > 8 drives start up...at the same time... hummm
> 
> Yes, n+1 PS sound like a good idea for this sort of work.
> I notice your 1U cases only have one PS. ;)
> 
> Thanks
> Dima
> -- 
> E-mail dmaziuk at bmrb dot wisc dot edu (@work) or at crosswinds dot net 
> (@home)
> http://www.bmrb.wisc.edu/descript/gpgkey.dmaziuk.ascii -- GnuPG 1.0.4 public 
> key
> We're sysadmins. Sanity happens to other people. -- Chris King in asr
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

Re: Referring what kernel-images to build to the technical committee?

[Rahul Jain]

On Thu, Apr 26, 2001 at 04:59:13PM +0200, Russell Coker wrote:
> If programs won't run at all (as in the case of MMX and 3DNow!) 
> then we should compile different kernels.  If they just don't run as fast 
> then we can let the users compile their own kernels.

I don't understand why MMX or 3dnow apps can't be used if the kernel isn't
compiled to support them. Only the K7 configuration adds 3dnow support, but
3dnow in mpg123 works (or at least seems to) on my k6-3 with k6 chosen for the
cpu type in the kernel config.

-- 
-> -/-   - Rahul Jain -   -\- <-
-> -\- http://linux.rice.edu/~rahul -=- mailto:[EMAIL PROTECTED] -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--||--||-|--|-|-|-|
   Version 11.423.999.220020101.23.50110101.042
   (c)1996-2000, All rights reserved. Disclaimer available upon request.

new libtool 1.4 released, packaged and uploaded

[Ossama Othman]

Hi,

I just uploaded a set of packages of the just released libtool 1.4.
>From what I understand, it fixes some of the release critical libtool
bugs.  If anyone has some time, can you please help me confirm this?

BTW, I uploaded the packages (1.4-0) for the experimental distribution.
Assuming all goes well with the 1.4-0 packages, I'll upload the 1.4-1
packages to unstable.

Thanks,
-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

Re: Storage (8*IDE HDs) any experiences?

[Dimitri Maziuk]

On Thu, Apr 26, 2001 at 03:23:03PM -0700, Alvin Oga wrote:
...
> your options for 6 or 8 disks are the promise cards
> and/or 3ware ...

Well, unfortunately purchasing is a bit strange around here...
That mobo (with HPT-370 controller) is the one we can buy
_easily_ -- from the university's techstore. A mobo with
promise is a bit more difficult...

> has anybody measured the +12V current needed when all
> 8 drives start up...at the same time... hummm

Yes, n+1 PS sound like a good idea for this sort of work.
I notice your 1U cases only have one PS. ;)

Thanks
Dima
-- 
E-mail dmaziuk at bmrb dot wisc dot edu (@work) or at crosswinds dot net (@home)
http://www.bmrb.wisc.edu/descript/gpgkey.dmaziuk.ascii -- GnuPG 1.0.4 public key
We're sysadmins. Sanity happens to other people. -- Chris King in asr

Re: Only one who have parse error in /var/lib/dpkg/available?

[Shaul Karl]

> --pgp-sign-Multipart_Fri_Apr_27_01:25:02_2001-1
> Content-Type: text/plain; charset=US-ASCII
> 
> 
> At Thu, 26 Apr 2001 00:14:01 -0500 (CDT),
> <[EMAIL PROTECTED]> wrote:
> > 
> > On Thu, 26 Apr 2001, Shaul Karl wrote:
> > 
> > > Yes there is:
> > >
> > > [12:36:41 /tmp]$ ls -l /var/lib/dpkg/available
> > > -rw-r--r--1 root root  2547713 Apr 25 00:46 
> > > /var/lib/dpkg/available
> > > [12:39:36 /tmp]$ od -cj 2547700 /var/lib/dpkg/available
> > > 11557764   c   e   9   1   8   0   f   a   4   2   d   f  \n
> > > 11560001
> > > [12:39:42 /tmp]$
> > >
> > > and
> > > dpkg -l doc-linux-text
> > > works too. I do not know what was changed.
> > 
> > No, there is no final new line.
> > 
> > debian-devel1:/# od -cj 5199880 /var/lib/dpkg/available
> > 23654010   r   d   .  \n  \n
> > 
> > It looks like the file got truncated.  Disk corruption?  What apt-cache
> > dumpavail(called from dselect [2]) interrupted?
> 
> I guess it is my fault. Maybe the description of ng-cjk lacks final new-line
> like below, and i guess that's the cause.
> 



I am quite sure it is not your fault. 
Although I do not know the cause I run an
apt-get update
for testing from another server. Now everything seems to be fine. There is 
here a problem with the local server and I hope that this, and not my machine, 
are the cause. In addition, no one else has reported to have the same problem.

[01:24:48 /tmp]$ grep -A20 '^Package: ng-cjk$' /var/lib/dpkg/available
Package: ng-cjk
Priority: optional
Section: editors
Installed-Size: 164
Maintainer: Yasuhiro Take <[EMAIL PROTECTED]>
Architecture: i386
Source: ng
Version: 1.4.3.1-1
Depends: libc6 (>= 2.2.1), libncurses5, ng-common
Filename: pool/main/n/ng/ng-cjk_1.4.3.1-1_i386.deb
Size: 73550
MD5sum: dcf8a20ce9180fa42df4bd7dc512d6f8
Description: Nihongo MicroGnuEmacs with CJK support.
 Ng is Nihongo Mg, MicroGnuEmacs. It is a small lightweight Emacs-like
 editor. It can handle both Latin and CJK.
 .
 ng-cjk can handle ISO-2022-JP, Shift-JIS, EUC-JP as well as EUC-KR and
 EUC-CN(GB only). Latin is not supported.

Package: ng-cjk-canna
Priority: optional
[01:24:51 /tmp]$ 



> sed 's/^ /+/' control | grep -A 11 '^Package: ng-cjk$'
> 
> Package: ng-cjk
> Architecture: any
> Depends: ${shlibs:Depends}, ng-common
> Description: Nihongo MicroGnuEmacs with CJK support. 
> +Ng is Nihongo Mg, MicroGnuEmacs. It is a small lightweight Emacs-like
> +editor. It can handle both Latin and CJK.
> +.
> +ng-cjk can handle ISO-2022-JP, Shift-JIS, EUC-JP as well as EUC-KR and
> +EUC-CN(GB only). Latin is not supported.
> +
> Package: ng-cjk-canna
> Architecture: any
> 
> 
> I'll fix this right now and dupload it.
> 
> Thanks,
> 
>   hirot
> 
> 
> --pgp-sign-Multipart_Fri_Apr_27_01:25:02_2001-1
> Content-Type: application/pgp-signature
> Content-Transfer-Encoding: 7bit
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQA66EvhfGUzr9MtPXERAoN0AKDKOojJg/Ooun07mLXhJc+6qE50sgCgrHZZ
> NoU5vW2XMI+BDAW+w62aHxE=
> =ru2q
> -END PGP SIGNATURE-
> 
> --pgp-sign-Multipart_Fri_Apr_27_01:25:02_2001-1--
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 

Shaul Karl <[EMAIL PROTECTED]>

Re: Storage (8*IDE HDs) any experiences?

[Alvin Oga]

hi ya...

good that these huge systems exists...

att is working on a 12disk ide system...

your options for 6 or 8 disks are the promise cards
and/or 3ware ...

has anybody measured the +12V current needed when all
8 drives start up...at the same time... hummm


we have a 1u chassis ( C2300 ) that fits 6 drives
we have 4 and 8 drive models in prototype stage... 
 

have fun raiding
alvin
http://www.Linux-1U.net .. 500Gb 1U raid5 ( ide or scsi3 )...


On Thu, 26 Apr 2001, Bryan Andersen wrote:

> Dimitri Maziuk wrote:
> > 
> > Hi all
> > 
> > I notice there are these new-fangled motherboards with 2*ATA-100 and
> > 2*ATA-33 ports. With 75GB disks, that baby should give us 600GB of raw
> > disk space (8 drives) at around $2K US. Sounds attractive, considering
> > that el-cheapo RAID boxes of similar capacity are around $10K.
> > 
> > Anyone runs [Debian] Linux on an 8-drive box like that? Is that
> > supported at all? Any gotchas I should know about? The mobo I'm looking
> > at is ABIT BH6-II.
> 
> It's supported.  I don't know about your motherboard.  I have a 
> Promise Ultra 100 on an older MB.  Just make sure your power 
> supply is up to it.  I patched a 2.2.18 kernel to add support 
> for the Ultra 100.  Beyond that it's stock.  Note, I had to make
> the /dev/hd[efgh]* devices.  Sofar I haven't done anything with
> raiding them.  A friend's experience shows that raid 0 and 1, 
> striping and mirroring, works quite nicely and fast while raid 
> 5 is slow.  This is due to the CPU having to calculate the raid 
> 5 checks blocks.
> 
> The major issue I've run into is finding places for my 6 HDs.  
> I ended up using a couple plates of metal to make a short tower 
> to hold 4 of them in front of a fan.
> 
> This is the df from my system.
> Filesystem   1k-blocks  Used Available Use% Mounted on
> /dev/hdc1   120995100189 14558  88% /
> /dev/hdc2  3937316531616   3205688  15% /tmp
> /dev/hdd2  3937316317652   3419652   9% /var
> /dev/hdc3 25486572   2089916  22878796   9% /usr
> /dev/hdd3 25486572  12028780  12939932  49% /home
> /dev/hde2 44171784  38973680   4307648  91% /data1
> /dev/hdg2 44171784  37325684   5955644  87% /data2
> /dev/hdh2 79227344  67338352  11093560  86% /data3
> /dev/hda5 11542670   9426807   2115863  82% /winE
> 
> 
> -- 
> |  Bryan Andersen   |   [EMAIL PROTECTED]   |   http://www.nerdvest.com   |
> | Buzzwords are like annoying little flies that deserve to be swatted. |
> |   -Bryan Andersen|
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

Re: New X problems...

[David A. Greene]

Dale Scheetz wrote:
Now, when I bring up and xterm or a bash window, I get no cursor and no
keystrokes appear in the window. I'm also having very flaky problems with
I have had problems with this as well.  I tracked it down to
NFS/amd not working properly.  This has been a problem on my
laptop for about a year now but NFS is not so critical that
I've had time to go fix the problem.  It seems odd, though,
that maps provided by our IT department don't work on my
woody laptop, but work on other machines on the network (running
potato). I'm guessing this is a configuration problem on my end,
though.  In any event, disabling amd solved it for me.
Hmm...After re-reading your message, I think I misunderstood you.
My problem is that the terminal session hangs (nothing is displayed
at all, and no, there are no references to NFS mounts in my
startup files).  It sounds like you're having strictly input
problems.
mozilla not being able to get into simple web pages and download material.
(I'm trying to get the current LSB spec)
Now _this_ I just recently (i.e. today) started seeing more
often. My laptop (Dell Latitude CPx/J) has always had problems
with the Vortex card after a BIOS resume.  For one thing, the
routes take forever to come back (i.e. 'route' hangs for a
minute or more before being able to resolve to DNS). Today,
however, I saw something new.  I dist-upgraded testing and
rebooted with a freshly-compiled 2.2.17 (no configuration changes,
just a kpkg --revision change so it doesn't conflict with
the standard packages).  After a BIOS suspend/resume cycle,
the network was extremely flaky.  As usual, route took forever.
Once I was able to ping a host, I left it running and used mozilla
to access the network through both the WWW and IMAP clients.
In both cases, as soon as mozilla took any action, the network
was lost and the pings stopped going through.
Strangely enough, I just now resumed the machine again and everything
seems fine.  In general, the Vortex/Cardbus/SOMETHING has always
been very flaky for me, but today was the first time I could
_consistently_ bring the network down.  Until I suspended/resumed
again, of course.  :(
At this point I can't tell whether this has something to do with my new
kernel, or is caused by something else. I'm pretty sure that once I got
things working the last time, I used an xterm with no problems, so my
suspicions lie heavily with the new kernel.
It's suspicious that I had a change in behavior after a kernel
recompile as well, but since I didn't change any configurations,
I'm assuming it lies with something in testing.  I suspect it
might be with the new (for me, at least) pcmcia-cs.
Thoughts?
-Dave
--
"Some little people have music in them, but Fats, he was all music,
and you know how big he was."  --  James P. Johnson

debian packages for corelinux 0.4.32

[Christophe Prud'homme]

dear corelinux/debian users,

the debian packages for corelinux0.4.32 have been created and uploaded for 
sid/unstable distribution

add this to your /etc/apt/sources.list 

deb http://corelinux.sourceforge.net/debian ./
deb-src http://corelinux.sourceforge.net/debian ./

right now only libcorelinux is available but libclfw and libclll will follow 
shortly
(older versions of ibclfw and libclll are available on the corelinux web site)

enjoy
C.
-- 
Christophe Prud'homme 
OOA and OOD for Linux
CoreLinux -- http://corelinux.sourceforge.net
Finite Element Method Codes
KFem  -- http://kfem.sourceforge.net

Re: RFC: Thoughts on building modules

[Sam Hartman]

> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes:

Herbert> Sam Hartman <[EMAIL PROTECTED]> wrote:
>> This is misleading.  The kernel-image-*-arch packages are much
>> simpler because they do not depend both on a kernel source
>> package and on a module deb package.  Also, note that this
>> maximizes work for the

Herbert> How does that make it more complex?  

It has two sets of factors driving changes.  Tools designed to make
this maintaince process easier will be more complex than tools
designed to make maintaining kernel source packages for a single arch
easy.  Well, at least you have a complexity vs manual effort tradeoff.
I argue that currently the tradeoff is way too far on the side of
manual effort and that  we need more complexity.

Note that all of the solutions I discussed involved this complexity.
I was objecting to your implication that setting up module source
packages was as simple as setting up arch-specific kernel image
packages, not saying the complexity was unnecessary.

>> issues.  Finally, it means that I cannot release a module for a
>> new arch without package-installation access to that arch.
>> It's my understanding that source-only uploads only work if
>> there is an existing binary package that depends on the source
>> package being installed, which is not the case for new package
>> source uploads.

Herbert> Well, kernels/modules have traditionally required this
Herbert> kind of access.  There's no way around it I'm afraid.  --


I'd buy that if all three potential directions I presented in my first
message weren't ways around this.  Module packages really aren't that
different from normal packages; there is a lot of kernel code that is
not arch specific.  I agree that kernel packages are arch specific and
you aren't going to get away from that.  However, my point is
partially that module packages have different constraints that kernel
packages.

Re: Lightweight Web browsers

[Christian Kurz]

On 01-04-26 Jérôme Marant wrote:
>   However, I found a simple HTML browser called Encompass
>   that takes far less memory than those I mentioned. Of course,
>   it does not have all the feature these browsers can offer
>   but it does handle HTML pretty well. I've build debs you can
>   find there:

May I ask why you don't mention that this is a web browser for Gnome?
This information would be helpful for people that look for a lightweight
HTML browser, but don't want to install Gnome. For those people this
browser will not be a alternative, since it pulls in the whole bunch of
gnome libs. :(

Christian
-- 
   Debian Developer (http://www.debian.org)
1024/26CC7853 31E6 A8CA 68FC 284F 7D16  63EC A9E6 67FF 26CC 7853


pgpPOddeUQNTn.pgp
Description: PGP signature

Re: Referring what kernel-images to build to the technical committee?

[Wichert Akkerman]

Previously Herbert Xu wrote:
> There is a file called /proc/cpuinfo you know.

And /proc/hardware on some architectures.

Wichert.

-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: Storage (8*IDE HDs) any experiences?

[Bryan Andersen]

Dimitri Maziuk wrote:
> 
> Hi all
> 
> I notice there are these new-fangled motherboards with 2*ATA-100 and
> 2*ATA-33 ports. With 75GB disks, that baby should give us 600GB of raw
> disk space (8 drives) at around $2K US. Sounds attractive, considering
> that el-cheapo RAID boxes of similar capacity are around $10K.
> 
> Anyone runs [Debian] Linux on an 8-drive box like that? Is that
> supported at all? Any gotchas I should know about? The mobo I'm looking
> at is ABIT BH6-II.

It's supported.  I don't know about your motherboard.  I have a 
Promise Ultra 100 on an older MB.  Just make sure your power 
supply is up to it.  I patched a 2.2.18 kernel to add support 
for the Ultra 100.  Beyond that it's stock.  Note, I had to make
the /dev/hd[efgh]* devices.  Sofar I haven't done anything with
raiding them.  A friend's experience shows that raid 0 and 1, 
striping and mirroring, works quite nicely and fast while raid 
5 is slow.  This is due to the CPU having to calculate the raid 
5 checks blocks.

The major issue I've run into is finding places for my 6 HDs.  
I ended up using a couple plates of metal to make a short tower 
to hold 4 of them in front of a fan.

This is the df from my system.
Filesystem   1k-blocks  Used Available Use% Mounted on
/dev/hdc1   120995100189 14558  88% /
/dev/hdc2  3937316531616   3205688  15% /tmp
/dev/hdd2  3937316317652   3419652   9% /var
/dev/hdc3 25486572   2089916  22878796   9% /usr
/dev/hdd3 25486572  12028780  12939932  49% /home
/dev/hde2 44171784  38973680   4307648  91% /data1
/dev/hdg2 44171784  37325684   5955644  87% /data2
/dev/hdh2 79227344  67338352  11093560  86% /data3
/dev/hda5 11542670   9426807   2115863  82% /winE


-- 
|  Bryan Andersen   |   [EMAIL PROTECTED]   |   http://www.nerdvest.com   |
| Buzzwords are like annoying little flies that deserve to be swatted. |
|   -Bryan Andersen|

Re: RFC: Thoughts on building modules

[Herbert Xu]

Sam Hartman <[EMAIL PROTECTED]> wrote:

> This is misleading.  The kernel-image-*-arch packages are much simpler
> because they do not depend both on a kernel source package and on a
> module deb package.  Also, note that this maximizes work for the

How does that make it more complex?

> issues.  Finally, it means that I cannot release a module for a new
> arch without package-installation access to that arch.  It's my
> understanding that source-only uploads only work if there is an
> existing binary package that depends on the source package being
> installed, which is not the case for new package source uploads.

Well, kernels/modules have traditionally required this kind of access.
There's no way around it I'm afraid.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Referring what kernel-images to build to the technical committee?

[Herbert Xu]

Steve Greenland <[EMAIL PROTECTED]> wrote:
>
> Confusion: Adding 8 (or whatever it is) variations of each kernel
> version is going to make it harder to select the appropriate one. There
> is some fraction of the target audience who won't know what kind of CPU
> they have, and we don't want to have to add to the Debian installation
> instructions: 

>"Now open your computer's case, and locate the large chip with fans
>hanging off of it. Write down the numbers and letters on top of the
>chip. Now look them up in this table to determine the best kernel
>for your machine."

There is a file called /proc/cpuinfo you know.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: auditd as logrotate replacement?

[Marco d'Itri]

On Apr 26, Alejo Sanchez <[EMAIL PROTECTED]> wrote:

 >I was only asking if release applications from debian
 >are allowed to have dlopen() (even if it isn't used
 >on most situations)
The patched mutt 1.2.x I maintain for debian does exactly this to
support SSL and kerberos.

-- 
ciao,
Marco

New X problems...

[Dale Scheetz]

I finally get my X system back into working order, find out I have memory
problems with my kernel and upgraded to the 2.2.19.

Now, when I bring up and xterm or a bash window, I get no cursor and no
keystrokes appear in the window. I'm also having very flaky problems with
mozilla not being able to get into simple web pages and download material.
(I'm trying to get the current LSB spec)

At this point I can't tell whether this has something to do with my new
kernel, or is caused by something else. I'm pretty sure that once I got
things working the last time, I used an xterm with no problems, so my
suspicions lie heavily with the new kernel.

Anyone have any ideas?

Thanks,

Dwarf
--
_-_-_-_-_-   Author of "Dwarf's Guide to Debian GNU/Linux"  _-_-_-_-_-_-
_-_-
_- aka   Dale Scheetz   Phone:   1 (850) 656-9769 _-
_-   Flexible Software  11000 McCrackin Road  _-
_-   e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308_-
_-_-
_-_-_-_-_-  Released under the GNU Free Documentation License   _-_-_-_-
  available at: http://www.polaris.net/~dwarf/

Re: Referring what kernel-images to build to the technical committee?

[David Schleef]

On Thu, Apr 26, 2001 at 10:13:01PM +0200, Russell Coker wrote:
> So a 386 compiled kernel can still support MMX, 3DNow! and MTRR?  In that 
> case we only need a 386 kernel, but it might be nice to have a PentiumMMX 
> compiled kernel as well (that should give better performance on all brands of 
> CPU that are better than 486).

Except that the PentiumMMX kernel won't run on a Pentium -- it
uses MMX instructions for memcpy().  (I now ramble into things
I only slightly remember, so please check before believing...)
I think the general consensus is that the original Pentium
instruction ordering is best all-around, whereas PentiumPro
is the worst.

> I am thinking of the various IDE options for dealing with broken drives and 
> controllers, PCI Quirks, etc.  These things will break some machines when set 
> one way and break other machines on the other setting.

I haven't heard of many problems like this recently.  But I'm sure
there will be such bugs during the lifetime of 2.4.

> So we ship half the kernel as binary and compile the other half after 
> installation?  Sounds terrible.  Why not just compile custom kernels for 
> every user?

(Yes, that doesn sound terrible.)  No, I meant to ship and install
one standard complete kernel.  If the user wants to run the
automatic kernel optimisation script and compile a new kernel,
cool.  But the idea is to make it as simple as "Do you want an
optimized kernel?"

> It wouldn't be that difficult to write a script that asks a dozen easy 
> questions, checks the /proc data, and then compiles an optimised kernel.

I tend to think that asking fewer questions is better -- a script
will better know how to optimise the kernel for someone that is
unprepared.  And the people that want more configuration options
should be compiling their own kernels anyway.




dave...

Formal request for review: [Sam Hartman ] Referring what kernel-images to build to the technical committee?

[Sam Hartman]

Hi.  I posted the following message to debian-devel last night and
have received agreement with the summary and apparently (it was not
explicitly stated) with the committee as a forum from Craig and
Herbert.  Thus I'd like to ask you to look at this issue.  There has
been some other discussion in the thread that the following message
starts and others have brought up some issues I did not cover in my
summary.  I recommend reading this discussion.


If there are any administrative hoops I need to jump through please
let me know.

--- Start of forwarded message ---
Resent-Date: Wed, 25 Apr 2001 20:30:46 -0400 (EDT)
Date: Wed, 25 Apr 2001 20:30:31 -0400 (EDT)
Message-Id: <[EMAIL PROTECTED]>
To: debian-devel@lists.debian.org
CC: [EMAIL PROTECTED],
[EMAIL PROTECTED] (module package maintainers),
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED] (kernel-image-i386 maintainer),
[EMAIL PROTECTED] (concerned about package size)
Subject: Referring what kernel-images to build to the technical committee?
Reply-to: debian-devel@lists.debian.org
From: Sam Hartman <[EMAIL PROTECTED]>
Resent-Message-ID: <[EMAIL PROTECTED]>
Resent-From: debian-devel@lists.debian.org
Resent-Sender: [EMAIL PROTECTED]


[cc list is an attempt at stakeholders for this issue.  If I missed
people, I'm sorry.  If I annoyed people by ccing them even though they
read the list, well I'm sorry too, but there are a fair number of
people who tend to want to be explicitly cc'd when an issue pertains
to them.]



Summary: Herbert has started building 8 different flavors of
kernel-image for i386.  These flavors correspond to CPU type; for
example there is an appropriate kernel for people with 386 machines to
run and an appropriate kernel for people with Athlon machines to run.
Several concerns have been brought up on debian-devel, and while I
believe that discussion has identified the tradeoffs involved, I do
not believe we have reached consensus on a direction to follow.

While Herbert is the maintainer of the kernel image for i386,I believe
the implications of this issue extend far beyond his packages and thus
this is an issue where the interests of different developers may come
into conflict.  Herbert's changes affect those who maintain module
packages like ALSA, PCMCIA, I2C and Openafs.  OSome have claimed these
decisions affect the installation by CDs by taking up a significant
chunk of a CD.  Concerns were raised about the bandwith and archive
space implications.

I believe that since debian-devel doesn't seem to be able to come to
consensus on this issue, we should refer the issue to a smaller group
than will fairly consider all the tradeoffs involved and come up with
a global direction for the project on this issue.  One concern I have
with Herbert's decision is that the i386 architecture is taking what
appears to be a different direction than other architectures.  I'd
rather have a global direction than have each architecture go off and
do their own thing.  Naturally, the tradeoffs may affect different
architcetures differently, so we may end up with a different set of
kernel images for each architecture, but the relative weights of the
tradeoffs and our overall goals could be decided globally.  I propose
the technical committee as an appropriate form to decide on this
issue, but I am open to other fora.

I'd like to summarize my understanding of the tradeoffs that we have
identified in the debian-devel discussion so that if we do turn this
issue over to the committee, they will know what concerns we have
already identified.  Please add to the following list if I have missed
something.  Note that I'm not trying to weight the tradeoffs here; I'm
trying to be fairly objective.  Comments of the form "That's not
important," are not appropriate at this time.  cThe goal is to
identify the issues and let whatever group we send this to evaluate
the weights of the issues.  Presumably such a group would ask for
public comment on the weightings if they would find that comment
useful.

performance: By having images optimized for each processor on i386
users should see better performance.  I don't believe performance
numbers were quantified in the discussion but quantifying performance
is probably important to evaluating this tradeoff.

Encouraging stock kernel use:  By having appropriate stock kernels
that meet people's needs we may encourage users to use the kernels.
This provides better/more consistent testing of our configurationas
well as easier upgrade.  Herbert indicated that previosly he did not
even use his own kernel image packages because they were not
optmized.  This should be considered separately from performance,
because even if there is not a significant performance win, if many
more users would use the stock kernel, the advantages  of doing so
might justify the change.  That is, the perception of whether
optimized kernels are needed influences whether people use them and
the value of this 

Re: Referring what kernel-images to build to the technical committee?

[Russell Coker]

On Thursday 26 April 2001 18:19, David Schleef wrote:
> > For 3DNow! we should have a kernel which supports it.
>
> All kernels, even if compiled with CONFIG_M386, will support
> MMX and 3DNow.  It just won't use memcpy_mmx() or memcpy_3d()
> as the implementation of memcpy().  The important part is
> saving the correct number of FP registers, which is done.
>
> > There is no need for a MTTR specific kernel.
>
> Right.  You compile kernels with CONFIG_MTRR=y, and the kernel
> will detect if the processor supports it at run-time.

So a 386 compiled kernel can still support MMX, 3DNow! and MTRR?  In that 
case we only need a 386 kernel, but it might be nice to have a PentiumMMX 
compiled kernel as well (that should give better performance on all brands of 
CPU that are better than 486).

> > (I am sure that I could find a list of a
> > dozen boolean options which are all needed to be in one state or another
> > for various broken hardware - we can't provide 2^12 kernels).
>
> If you were to report this as a kernel bug, it would probably
> be fixed quickly.  i386 CONFIG_ dependencies are designed
> reasonably enough that you can expect to build one kernel
> that runs on most hardware (apart from non-arch driver issues.)

I am thinking of the various IDE options for dealing with broken drives and 
controllers, PCI Quirks, etc.  These things will break some machines when set 
one way and break other machines on the other setting.

> I'd like to see a single binary kernel (or two, because I'm
> suspicious about CONFIG_M386), and an easy system that allows
> you to build one of a set of standard kernels, i.e., a kernel
> that has everything enabled as modules, but varies in optimized
> processor, SMP, high memory support, etc.  In particular, I don't
> think it's appropriate (in the idea I'm describing) to present
> the user with questions such as "Do you want APM support?" --
> compile it in or as a module, and figure it out at run-time.
> In fact, most of the options could be auto-detected from
> /proc/cpuinfo.

So we ship half the kernel as binary and compile the other half after 
installation?  Sounds terrible.  Why not just compile custom kernels for 
every user?

It wouldn't be that difficult to write a script that asks a dozen easy 
questions, checks the /proc data, and then compiles an optimised kernel.

-- 
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/   Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page

Re: Only one who have parse error in /var/lib/dpkg/available?

[Shaul Karl]

> On Thu, 26 Apr 2001, Shaul Karl wrote:
> 
> > Yes there is:
> >
> > [12:36:41 /tmp]$ ls -l /var/lib/dpkg/available
> > -rw-r--r--1 root root  2547713 Apr 25 00:46 
> > /var/lib/dpkg/available
> > [12:39:36 /tmp]$ od -cj 2547700 /var/lib/dpkg/available
> > 11557764   c   e   9   1   8   0   f   a   4   2   d   f  \n
> > 11560001
> > [12:39:42 /tmp]$
> >
> > and
> > dpkg -l doc-linux-text
> > works too. I do not know what was changed.
> 
> No, there is no final new line.
> 
> debian-devel1:/# od -cj 5199880 /var/lib/dpkg/available
> 23654010   r   d   .  \n  \n
> 
> It looks like the file got truncated.  Disk corruption?  What apt-cache
> dumpavail(called from dselect [2]) interrupted?
> 


I am not sure but the reason could also be a problem with a local server.
At least for now, after an apt-get update from another server, it looks O.K:
1) The size of the file has grown a lot.
2) Now there is the terminating \n\n. 
[22:49:47 /tmp]$ od -cj 4462910 /var/lib/dpkg/available
21014476   f   o   r   m   s   .  \n  \n
21014507
[22:52:04 /tmp]$ 
3) The Description is the last field.

I will watch it.
Thank you for the help.
-- 

Shaul Karl <[EMAIL PROTECTED]>

Re: libc6 broken?

[Taral]

On Thu, Apr 26, 2001 at 12:28:51PM +0200, Ulrich Wiederhold wrote:
> If I try a ./configure or a "make xconfig" with a new Kernel, I get this
> error-msg:
> /lib/libc.so.6: undefined reference to [EMAIL PROTECTED]'
> /lib/libc.so.6: undefined reference to [EMAIL PROTECTED]'

Uh, why do you have libc 2.2.3? We don't have libc 2.2.3 in the archive.

-- 
Taral <[EMAIL PROTECTED]>
Please use PGP/GPG encryption to send me mail.
"Any technology, no matter how primitive, is magic to those who don't
understand it." -- Florence Ambrose


pgpxKn6AQmsgr.pgp
Description: PGP signature

Formal request for review: [Sam Hartman ] Referring what kernel-images to build to the technical committee?

[Sam Hartman]

Hi.  I posted the following message to debian-devel last night and
have received agreement with the summary and apparently (it was not
explicitly stated) with the committee as a forum from Craig and
Herbert.  Thus I'd like to ask you to look at this issue.  There has
been some other discussion in the thread that the following message
starts and others have brought up some issues I did not cover in my
summary.  I recommend reading this discussion.


If there are any administrative hoops I need to jump through please
let me know.

--- Start of forwarded message ---
Resent-Date: Wed, 25 Apr 2001 20:30:46 -0400 (EDT)
Date: Wed, 25 Apr 2001 20:30:31 -0400 (EDT)
Message-Id: <[EMAIL PROTECTED]>
To: debian-devel@lists.debian.org
CC: [EMAIL PROTECTED],
[EMAIL PROTECTED] (module package maintainers),
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED] (kernel-image-i386 maintainer),
[EMAIL PROTECTED] (concerned about package size)
Subject: Referring what kernel-images to build to the technical committee?
Reply-to: debian-devel@lists.debian.org
From: Sam Hartman <[EMAIL PROTECTED]>
Resent-Message-ID: <[EMAIL PROTECTED]>
Resent-From: debian-devel@lists.debian.org
Resent-Sender: [EMAIL PROTECTED]


[cc list is an attempt at stakeholders for this issue.  If I missed
people, I'm sorry.  If I annoyed people by ccing them even though they
read the list, well I'm sorry too, but there are a fair number of
people who tend to want to be explicitly cc'd when an issue pertains
to them.]



Summary: Herbert has started building 8 different flavors of
kernel-image for i386.  These flavors correspond to CPU type; for
example there is an appropriate kernel for people with 386 machines to
run and an appropriate kernel for people with Athlon machines to run.
Several concerns have been brought up on debian-devel, and while I
believe that discussion has identified the tradeoffs involved, I do
not believe we have reached consensus on a direction to follow.

While Herbert is the maintainer of the kernel image for i386,I believe
the implications of this issue extend far beyond his packages and thus
this is an issue where the interests of different developers may come
into conflict.  Herbert's changes affect those who maintain module
packages like ALSA, PCMCIA, I2C and Openafs.  OSome have claimed these
decisions affect the installation by CDs by taking up a significant
chunk of a CD.  Concerns were raised about the bandwith and archive
space implications.

I believe that since debian-devel doesn't seem to be able to come to
consensus on this issue, we should refer the issue to a smaller group
than will fairly consider all the tradeoffs involved and come up with
a global direction for the project on this issue.  One concern I have
with Herbert's decision is that the i386 architecture is taking what
appears to be a different direction than other architectures.  I'd
rather have a global direction than have each architecture go off and
do their own thing.  Naturally, the tradeoffs may affect different
architcetures differently, so we may end up with a different set of
kernel images for each architecture, but the relative weights of the
tradeoffs and our overall goals could be decided globally.  I propose
the technical committee as an appropriate form to decide on this
issue, but I am open to other fora.

I'd like to summarize my understanding of the tradeoffs that we have
identified in the debian-devel discussion so that if we do turn this
issue over to the committee, they will know what concerns we have
already identified.  Please add to the following list if I have missed
something.  Note that I'm not trying to weight the tradeoffs here; I'm
trying to be fairly objective.  Comments of the form "That's not
important," are not appropriate at this time.  cThe goal is to
identify the issues and let whatever group we send this to evaluate
the weights of the issues.  Presumably such a group would ask for
public comment on the weightings if they would find that comment
useful.

performance: By having images optimized for each processor on i386
users should see better performance.  I don't believe performance
numbers were quantified in the discussion but quantifying performance
is probably important to evaluating this tradeoff.

Encouraging stock kernel use:  By having appropriate stock kernels
that meet people's needs we may encourage users to use the kernels.
This provides better/more consistent testing of our configurationas
well as easier upgrade.  Herbert indicated that previosly he did not
even use his own kernel image packages because they were not
optmized.  This should be considered separately from performance,
because even if there is not a significant performance win, if many
more users would use the stock kernel, the advantages  of doing so
might justify the change.  That is, the perception of whether
optimized kernels are needed influences whether people use them and
the value of this 

Re: RFC: Thoughts on building modules

[Sam Hartman]

> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes:


Herbert> BTW, this is how the kernel images are organised on
Herbert> alpha/i386/sparc.

This is misleading.  The kernel-image-*-arch packages are much simpler
because they do not depend both on a kernel source package and on a
module deb package.  Also, note that this maximizes work for the
module maintainer, which is a valid thing to do, although I'd like to
note that we seem to get a much better balance for other porting
issues.  Finally, it means that I cannot release a module for a new
arch without package-installation access to that arch.  It's my
understanding that source-only uploads only work if there is an
existing binary package that depends on the source package being
installed, which is not the case for new package source uploads.

Storage (8*IDE HDs) any experiences?

[Dimitri Maziuk]

Hi all

I notice there are these new-fangled motherboards with 2*ATA-100 and
2*ATA-33 ports. With 75GB disks, that baby should give us 600GB of raw
disk space (8 drives) at around $2K US. Sounds attractive, considering
that el-cheapo RAID boxes of similar capacity are around $10K.

Anyone runs [Debian] Linux on an 8-drive box like that? Is that
supported at all? Any gotchas I should know about? The mobo I'm looking
at is ABIT BH6-II.

TIA
Dima
-- 
E-mail dmaziuk at bmrb dot wisc dot edu (@work) or at crosswinds dot net (@home)
http://www.bmrb.wisc.edu/descript/gpgkey.dmaziuk.ascii -- GnuPG 1.0.4 public key
Well, lusers are technically human.   -- Red Drag Diva in ASR

Re: updating of /etc/rc?.d

[Will Lowe]

> That's a good hack, but I still think update-rc.d should support it
> directly. I was surprised to see portmap restarted after an ugrade when
> I'd previously done "update-rc.d -f remove portmap".

That was my feeling, that most users would probably wonder why it was
started again.

Re: updating of /etc/rc?.d

[Jason Lunz]

[EMAIL PROTECTED] said:
> At the very least, this should be documented in update-rc.d(8).

Actually, now that I look again, it is pretty well documented. never
mind.

Jason

Re: updating of /etc/rc?.d

[Jason Lunz]

[EMAIL PROTECTED] said:
> It is possible to disable a service simply by removing links in
> /etc/rc*.d .  So long as you leave at least one (/etc/rc0.d/K*package
> would seem to be a good candidate), update-rc.d when called by packages
> on upgrade is a no-op.  Something like:
> 
>   rm /etc/rc*.d/S*package
> 
> should generally do the trick.

That's a good hack, but I still think update-rc.d should support it
directly. I was surprised to see portmap restarted after an ugrade when
I'd previously done "update-rc.d -f remove portmap".

At the very least, this should be documented in update-rc.d(8).

> Note, now that netbase has changed the dependency on portmap to a
> `suggests' you may remove it anyway.

I want portmap and nfs, but I only want them working once a month or so
when I need them.

Jason

Re: Debian Afbackup

[Arthur Korn]

Salut Stephane

Stephane Leclerc schrieb:
> I've see that you uploaded 13 Apr 2001 a fix version of afbackup.

> Do you know the status of this package?. I've sent an email to the official
> maintainer and never got an answer.

I don't use afbackup myself, and from what I remember of the
changelog (/usr/share/doc/afbackup/changelog.Debian.gz) it's
regular maintainer hasn't made an upload for some years. It
looks like we have to find a new maintainer for afbackup :(.

> The .deb is really old, don't works very well and I'll looking for a .deb
> version of the up to date version. I currently use it directly from the
> tarball but it's a paint to maintain on many boxes. And on Alpha, it's realy
> hard to compile.
> 
> Thanks to let me know.
> 
> Stef...
> 
> 
> ..
> .  Linux - Debian - php4 - Apache - MySQL - Infogerance  .
> .   email: [EMAIL PROTECTED] - http://www.actionweb.fr   .
> . Tel: (0)141 906 100-Fax: (0)141 906 101.
> ..
> 

ciao, 2ri
-- 
Hardware, n.:
The parts of a computer system that can be kicked.

Re: updating of /etc/rc?.d

[Jason Lunz]

[EMAIL PROTECTED] said:
> What's wrong with adding an exit 0 to the init.d files?

dpkg will ask me whether I want to keep my changes each time I upgrade,
rather than just overwriting the script.

Jason

Re: Referring what kernel-images to build to the technical committee?

[Steve Greenland]

Good summary, Sam. I'd like to add a couple extra points:

On 25-Apr-01, 19:30 (CDT), Sam Hartman <[EMAIL PROTECTED]> wrote: 
> Should build custom:  Some argumed that users should build a custom
> kernel and the distribution was doing them a disservice by trying to
> provide kernels that met their needs.

There was also a slightly different argument: That *if* the user needs
the slight performance improvement offered by a CPU optimized kernel,
then *probably* that user is both capable of building his/her own, *and*
would gain further (and possibly more significant) performance benefits
by many other choices one could make when configuring a kernel (module
vs. non-module, etc.) 

Confusion: Adding 8 (or whatever it is) variations of each kernel
version is going to make it harder to select the appropriate one. There
is some fraction of the target audience who won't know what kind of CPU
they have, and we don't want to have to add to the Debian installation
instructions: 

"Now open your computer's case, and locate the large chip with fans
hanging off of it. Write down the numbers and letters on top of the
chip. Now look them up in this table to determine the best kernel
for your machine."

How larget that fraction is I don't know, but I'd wager it was larger
than 0.

> Archive Size:  
> CD Size:  
> Bandwith: 
> Module Multiplication, size, bandwidth: 

Someone (sorry, forget who) proposed that instead of actually
distributing a lot of different "stock" kernels, we distribute some sort
"kernel-tuner" package that included the various config files and made
it easy for a user to build a custom kernel that matched the Debian
stock kernel except for CPU specificity (and one could extend this to
a matrix of CPU/AGP/DRI choices). Perhaps it could present a menu of
choices ("pick the things you have") and then select (or generate) the
appropriate config file, use make-kpkg to build the new kernel, and then
install the new kernel.deb. Yes, it would take longer, but it doesn't
have any of the negative impacts on the archive, and it starts the user
on the path to custom kernel competency.

Steve
-- 
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)

Re: auditd as logrotate replacement?

[Alejo Sanchez]

Julian Gilbey wrote:
> 
> On Wed, Apr 25, 2001 at 08:35:51PM -0300, Alejo Sanchez wrote:
> > well, your version would do it the dlopen() way.
> > actually we were going to ask if there was a
> > restriction on depending on dlopen(), as it could
> > be possible on some non-dynamic plataforms.
> > (no shared libraries, no dl library)
> 
> You could look at libltdl from the libtool suite.  I guess you could
> always use configure tests to figure this sort of stuff out.
> 
>Julian

I was only asking if release applications from debian
are allowed to have dlopen() (even if it isn't used
on most situations)

AFAIK some OS don't, ie. OpenBSD.

Alejo

Re: Gnome bug 94684

[Steve Greenland]

On 26-Apr-01, 06:52 (CDT), "Jaldhar H. Vyas" <[EMAIL PROTECTED]> wrote: 
> On 25 Apr 2001, Thomas Bushnell, BSG wrote:
>> Second, I can't keep track of who "upstream" is for all the Debian
>> packages.
>>
> 
> Why not?  It's in the copyright file of each package.  If it isn't--that's
> a bug.
> 
> Zhaoway is right that you're a big boy and can talk to upstream
> developers without having to go through a middleman.

Yes, Thomas *could* report the bug upstream. However, he shouldn't have
to; one of the Debian developer's jobs is to deal with this kind of
stuff, even if "dealing with it" is only forwarding it upstream and
marking it as such in the BTS. Our user's have every right to expect
this.

Steve

-- 
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)

Re: Only one who have parse error in /var/lib/dpkg/available?

[Yasuhiro Take]

At Thu, 26 Apr 2001 00:14:01 -0500 (CDT),
<[EMAIL PROTECTED]> wrote:
> 
> On Thu, 26 Apr 2001, Shaul Karl wrote:
> 
> > Yes there is:
> >
> > [12:36:41 /tmp]$ ls -l /var/lib/dpkg/available
> > -rw-r--r--1 root root  2547713 Apr 25 00:46 
> > /var/lib/dpkg/available
> > [12:39:36 /tmp]$ od -cj 2547700 /var/lib/dpkg/available
> > 11557764   c   e   9   1   8   0   f   a   4   2   d   f  \n
> > 11560001
> > [12:39:42 /tmp]$
> >
> > and
> > dpkg -l doc-linux-text
> > works too. I do not know what was changed.
> 
> No, there is no final new line.
> 
> debian-devel1:/# od -cj 5199880 /var/lib/dpkg/available
> 23654010   r   d   .  \n  \n
> 
> It looks like the file got truncated.  Disk corruption?  What apt-cache
> dumpavail(called from dselect [2]) interrupted?

I guess it is my fault. Maybe the description of ng-cjk lacks final new-line
like below, and i guess that's the cause.

sed 's/^ /+/' control | grep -A 11 '^Package: ng-cjk$'

Package: ng-cjk
Architecture: any
Depends: ${shlibs:Depends}, ng-common
Description: Nihongo MicroGnuEmacs with CJK support. 
+Ng is Nihongo Mg, MicroGnuEmacs. It is a small lightweight Emacs-like
+editor. It can handle both Latin and CJK.
+.
+ng-cjk can handle ISO-2022-JP, Shift-JIS, EUC-JP as well as EUC-KR and
+EUC-CN(GB only). Latin is not supported.
+
Package: ng-cjk-canna
Architecture: any


I'll fix this right now and dupload it.

Thanks,

hirot



pgp0h8bN2Eevh.pgp
Description: PGP signature

Re: Referring what kernel-images to build to the technical committee?

[David Schleef]

On Thu, Apr 26, 2001 at 04:15:15PM +0200, Russell Coker wrote:
> On Thursday 26 April 2001 09:05, Andreas Metzler wrote:
> > _Afair_ it is necessary to run a k6 (or athlon) "optimized" kernel to
> > use 3DNow! in applications like xmms or lame. This probably applys to
> > ISSE, MTTR and MMX, too.

This is not correct.

> There is software available which only runs with MMX.  We should offer a 
> kernel with MMX support which requires Pentium-MMX to support running this.
> 
> For 3DNow! we should have a kernel which supports it.

All kernels, even if compiled with CONFIG_M386, will support
MMX and 3DNow.  It just won't use memcpy_mmx() or memcpy_3d()
as the implementation of memcpy().  The important part is
saving the correct number of FP registers, which is done.

> There is no need for a MTTR specific kernel.

Right.  You compile kernels with CONFIG_MTRR=y, and the kernel
will detect if the processor supports it at run-time.

> (I am sure that I could find a list of a 
> dozen boolean options which are all needed to be in one state or another for 
> various broken hardware - we can't provide 2^12 kernels).

If you were to report this as a kernel bug, it would probably
be fixed quickly.  i386 CONFIG_ dependencies are designed
reasonably enough that you can expect to build one kernel
that runs on most hardware (apart from non-arch driver issues.)

> Also I think that we should have an SMP kernel in the list.

We could have one kernel with CONFIG_SMP=y.  It doesn't conflict
with other things, although this is an option that is likely to
be on your list above.  CONFIG_M386 is one as well, since the
kernel can't use the better locking primitives that appeared
in the 486.

I'd like to see a single binary kernel (or two, because I'm
suspicious about CONFIG_M386), and an easy system that allows
you to build one of a set of standard kernels, i.e., a kernel
that has everything enabled as modules, but varies in optimized
processor, SMP, high memory support, etc.  In particular, I don't
think it's appropriate (in the idea I'm describing) to present
the user with questions such as "Do you want APM support?" --
compile it in or as a module, and figure it out at run-time.
In fact, most of the options could be auto-detected from
/proc/cpuinfo.

It could also be useful as a hardware tester at install time:
"Would you like to test your hardware (and get a kernel custom
build for your hardware at the same time)?  This process will
potentially take a long time."  (Yes, I realize this idea is
a bit crazier than average.)




dave...

Curious e-mails from yucom.be

[Steve Greenland]

Today I received several e-mails that were near duplicates of
interactions with the BTS last sunday, both from me and from others.
The originals had headers like this (I've trimmed the extraneous stuff):


Received: from gecko by master.debian.org with local (Exim 3.12 1 (Debian))
id 14rP8Z-0003SF-00; Sun, 22 Apr 2001 14:03:11 -0500   
Received: via spool by [EMAIL PROTECTED] id=B79711.98796614612819
  (code B ref 79711); Sun, 22 Apr 2001 19:03:08 GMT

The duplicate has:

Received: from btbntsys1.yucom.be (yucom.be) [212.8.180.1]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 14sj3f-00054p-00; Thu, 26 Apr 2001 05:31:35 -0500
Received: from mail pickup service by yucom.be with Microsoft SMTPSVC;
 Thu, 26 Apr 2001 12:27:07 +0200
Received: from murphy.debian.org ([216.234.231.6]) by yucom.be  with Microsoft  
+SMTPSVC(5.5.1877.197.19);
 Sun, 22 Apr 2001 21:01:12 +0200
Received: (qmail 22943 invoked by uid 38); 22 Apr 2001 19:03:31 -
Received: (qmail 22820 invoked from network); 22 Apr 2001 19:03:29 -
Received: from master.debian.org ([EMAIL PROTECTED])
  by murphy.debian.org with SMTP; 22 Apr 2001 19:03:29 -
Received: from gecko by master.debian.org with local (Exim 3.12 1 (Debian))
id 14rP8Z-0003SF-00; Sun, 22 Apr 2001 14:03:11 -0500
Received: via spool by [EMAIL PROTECTED] id=B79711.98796614612819
  (code B ref 79711); Sun, 22 Apr 2001 19:03:08 GMT

Note that the message id is the same; it just went to "yucom.be", who
held it for a 4 days and then respewed it back to me at master. Any
ideas what's going on? Or how I can make it stop?

Thanks,
Steve

PS Notice that I refrained from making any snide comments about
crappy Microsoft mail servers. 


-- 
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)

Lightweight Web browsers

[Jérôme Marant]

  Hi,

  I was looking for a lightweight web browser and I try tried
  all of those I could get in debs. Unfortunately, neither
  mozilla nor galeon nor konqueror are satisfactory in terms
  of memory usage (says less than 10 megs of RAM).

  However, I found a simple HTML browser called Encompass
  that takes far less memory than those I mentioned. Of course,
  it does not have all the feature these browsers can offer
  but it does handle HTML pretty well. I've build debs you can
  find there:

  deb http://people.debian.org/~jerome unofficial/

  Tell me if you are interested to see it in debian.
  Thanks. 

-- 
Jérôme Marant

Re: kernel-{image,headers} package bloat

[Kenneth Vestergaard Schmidt]

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-freak, and I like to know what is compiled 
into it. I also like to decide /what/ modules I have, instead of everything. 
But that's me.

If I understand this correctly, Herbert Xu wants to provide alternate 
kernel-* to make it easier for users to run a better suited kernel. However, 
doesn't that require the user to know more about his system? I would argue in 
/favor/ of the kernel-{helper,custom} package, since if you wanted to use a 
custom kernel, you still had to use apt/dselect/whatever to find the correct 
image for your system. And if you /REALLY/ want those last drops of 
performance, you still need to be something of a wizzard, using powertweak, 
or /proc-hacks, or whatever.

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? I 
mean, just make a note to the user, to switch to another console, or minimize 
the window in case of X. Then he'll get a kernel freshly built. IMHO, that's 
much better. It also means that they only have to download a small update 
each time there's a new kernel-release, instead of several megabytes. Dial-up 
users should love this.

In the end, I am not sure this matters. Herbert seems to have set his mind 
pretty strongly on this. I can't speak on behalf of him, of course, but it 
seems that "multiple flavours" are here to stay, for better or for worse...

Regards
Kenneth

Re: Only one who have parse error in /var/lib/dpkg/available?

[doogie]

On Thu, 26 Apr 2001, Shaul Karl wrote:

> Yes there is:
>
> [12:36:41 /tmp]$ ls -l /var/lib/dpkg/available
> -rw-r--r--1 root root  2547713 Apr 25 00:46 
> /var/lib/dpkg/available
> [12:39:36 /tmp]$ od -cj 2547700 /var/lib/dpkg/available
> 11557764   c   e   9   1   8   0   f   a   4   2   d   f  \n
> 11560001
> [12:39:42 /tmp]$
>
> and
> dpkg -l doc-linux-text
> works too. I do not know what was changed.

No, there is no final new line.

debian-devel1:/# od -cj 5199880 /var/lib/dpkg/available
23654010   r   d   .  \n  \n

It looks like the file got truncated.  Disk corruption?  What apt-cache
dumpavail(called from dselect [2]) interrupted?

Re: Referring what kernel-images to build to the technical committee?

[Vince Mulhollon]

On 04/26/2001 09:59:13 AM Russell Coker wrote:

>> On Thursday 26 April 2001 16:38, Ilya Martynov wrote:
>> > RC> There is no need for a MTTR specific kernel.  MTTR is not really
>> > RC> needed as there is no software written which is unable to run
>> > RC> without it.  Our goal here should be compatibility with software.
>> > RC> MTTR can increase speed significantly in certain situations, but
>> > RC> there's lots of other ways of doing that for less effort which we
>> > RC> aren't supporting.  MTTR can allow you to work around broken
>> > RC> hardware.  But we can't provide enough kernels to support all
>> > RC> combinations of broken hardware (I am sure that I could find a
>> > RC> list of a dozen boolean options which are all needed to be in one
>> > RC> state or another for various broken hardware - we can't provide
>> > RC> 2^12 kernels).
>> >
>> > I think you are wrong about 'MTTR is not really needed'. One good
>> > example is aviplay (player for avi files). It perfomance is seriously
>> > affected by MTTR option. This fact is mentioned in its docs and I've
>> > seen myself *significant* difference in its perfomance when I've
>> > compiled kernel with MTTR option. Probably perfomance of simular
>> > programs will be affected too.
>>
>> I've played many AVI files without MTRR support.  It will still work,
just a
>> bit slower.  If programs won't run at all (as in the case of MMX and
3DNow!)
>> then we should compile different kernels.  If they just don't run as
fast
>> then we can let the users compile their own kernels.
>>
>> If you want maximum video speed you want to compile your own kernel with
AGP
>> and DRI support etc...

Naw, lets just quadruple the number of kernels we have so we can have:

1) kernel without AGP or DRI
2) kernel with AGP and no DRI
3) kernel without AGP with DRI
4) kernel with AGP and with DRI

For each of the 30 or so processor revisions that can be compiled for.

After all, if half a dozen kernels for the i386 "port" of debian is OK
instead of 1, what's wrong with quadrupling it again?  The same arguements
apply to that case.

Eventually there will be so many kernels that newbies will find it quicker
and easier to navigate "make xconfig" that to navigate dselect.

And optimizations aren't just limited to playing AVIs.

I recall a few years ago a special version of mpg123 that was optimized for
a 486.  A 486-33 that could barely play a mono 22.1 K mpeg easily played
stereo 44.2 K mpegs with the optimizations, if I recall correctly.  We
desparately need to include that of course.  I'm sure similar optimizations
could be added to mpg123 that would reduce processor load on a P4-1ghz by
0.001 % so we need to include that of course.

If we are going to recompile everything to get 1% better performance, we
should have the guts to split the i386 port into all the little processor
families instead of this halfway stuff.

debian-devel´Ô ¾È³çÇϼ¼¿ä?

[¿Â¶óÀÎÄÚ¸®¾Æ]

¢Ä ¿À´ÃÀÇ À¯¸Ó ¢Å
¡á°ú½Ã¿åA girl got an 
engagement ring, and would seize every opportunity for 
calling attention to it.  In a 
group with girl friends no one noticed it.  Finally when herfriends 
were sitting around talking, she got up suddenly and said, "It's awfully hot in here. I think I'll take my ring 
off."
¡Þseize every opportunity for ~ ing : ±âȸ¸¸ ÀÖÀ¸¸é ~ 
ÇÏ´Ù.¡Þcall attention to : ~ ¿¡ ÁÖÀǸ¦ ȯ±â½ÃÅ°´Ù. ¡Þawfully : very 
¾àÈ¥¹ÝÁö¸¦ ¹ÞÀº ¾Æ°¡¾¾´Â ±âȸ¸¸ ÀÖÀ¸¸é »ç¶÷µé¿¡°Ô ±× ¹ÝÁö¸¦ º¸¿©ÁÖ·Á°í  
µé¾ú´Ù  ÇѹøÀº ¿©ÀÚÄ£±¸µé°ú ¾î¿ï·È´Âµ¥ ¾Æ¹«µµ ±× ¹ÝÁö¸¦ ´«¿©°Ü ºÁÁÖÁö ¾Ê¾Ò´Ù¸¶Ä§³» ¾Æ°¡¾¾´Â ´Ùµé µÑ·¯¾É¾Æ 
À̾߱⸦ ³ª´©°í ÀÖ´Â ÆÇ¿¡ ¹ú¶± ÀϾ¸é¼­ ¸»Çß´Ù."¾îÈÞ, ´õ¿ö¼­ ¸ø °ßµð°Ú³×. ³ª ¹ÝÁö¸¦ »©¾ß ÇÒ±îºÁ!"  

¢Ä ¿À´ÃÀÇ ¿µ¾î ÇѸ¶µð ¢Å
¢Ã °¨»çÀÇ ¸»À» ÇÒ ¶§¿Ü±¹ÀεéÀº ³²¿¡°Ô ¾ÆÁÖ 
ÀÛÀº µµ¿òÀ» ¹Þ¾Æµµ "Thank you.(°¨»çÇÕ´Ï´Ù.)"¶ó°í ¸»ÇØ¿ä. ÀÌ°ÍÀº ¾î·ÈÀ» ¶§ºÎÅÍ ±×·± ±³À°À» ¹ÞÀ¸¸é¼­ ÀÚ¶ó ¿Ô±â ¶§¹®¿¡ ¸ö¿¡ 
º£¾î ÀÖ¾î »ó´ë¹æÀÇ »ç¼ÒÇÑ µµ¿òÀ̳ª Ä£Àý¿¡µµ "Thank you."¶ó°í ¸»ÇÏ´Â ½À°üÀ» °®°Ô µÈ°Å °°¾Æ¿ä. ¹°·Ð, ¿ì¸®µµ 
¸¶Âù°¡ÁöÁö¸¸¿ä."Thank you."¿¡ ´ëÇÑ ÀÀ´äÀº "õ¸¸¿¡¿ä."¶ó´Â ¶æÀ¸·Î "You are welcome. /Don't 
mention it. /Not at all."µîÀÇ Ç¥ÇöÀ» ¾²ÁÒ. 
A: It was very kind of you to go to that trouble for 
me.B: It was no trouble at all. It was my pleasure.A: It's very kind of 
you to say so. A: Àú¸¦ À§Çؼ­ ±×·± ¼ö°í¸¦ ÇØ ÁÖ½Ã´Ï Á¤¸» °í¸¿½À´Ï´Ù.B: ¹¹ ¼ö°í¶ö °ÍÀÌ ÀÖ³ª¿ä. 
Á¦°¡ ÁÁ¾Æ¼­ ÇÑ ÀÏÀä.A: ±×·¸°Ô ¸»¾¸ÇØ ÁÖ½Ã´Ï Á¤¸» °í¸¿½À´Ï´Ù. ¡á°¨»çÀÇ 
±âº» Ç¥Çö¢Â Thank you. /Thanks.   ¢¹°¨»çÇÕ´Ï´Ù.¢Â Thanks a lot. 
/Thank you very much. /Thank you so much.   ¢¹´ë´ÜÈ÷ °¨»çÇÕ´Ï´Ù.¢Â I'd 
appreciate it.   ¢¹±×·¸°Ô ÇØ ÁÖ½Ã¸é °¨»çÇÏ°Ú½À´Ï´Ù.¢Â I appreciate it very 
much.   ¢¹±× Á¡ Á¤¸» °¨»çÇÕ´Ï´Ù.¢Â On behalf of our employees I'd like to 
thank you.   ¢¹ÀúÈñ ȸ»ç¿øµéÀ» ´ëÇ¥Çؼ­ ´ç½Å¿¡°Ô °¨»ç µå¸®°í ½Í½À´Ï´Ù. ¢Ä À߸ø ¾²ÀÏ ¼ö Àִ ǥÇö ¢Å ¢Ã ¿©±â¼­ 
1È£¼±À¸·Î °¥¾ÆŸ¼Å¾ß ÇÕ´Ï´Ù ¡áYou have to shift to 
the No.1 Line.¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡í(X)¡áYou'll have to 
transfer to the No.1 Line from here.¡ë¡ë¡ë¡í(O) ¢Áshift´Â ´ë°³ °ÅÁÖÁö³ª 
»ý°¢À» ¹Ù²Û´Ù´Â ¶æÀ̹ǷΠ¿©±â¼­´Â ¸ÂÁö ¾Ê¾Æ¿ä.   ±³ÅëÆíÀ» °¥¾ÆŸ´Â °ÍÀº º¸Åë transfer¶ó°í ÇØ¿ä. ±×¸®°í ³ë¼±À» 
°¥¾ÆŸ´Â   ȯ½Â¿ªµµ transfer¶ó°í Çϴµ¥, À̶§´Â ¸í»çÀÔ´Ï´Ù.   ºñÇà±â ¿©Çà Áß¿¡ °¥¾ÆŸ´Â ±âÂøÁö´Â 
stopover¶ó°í ÇØ¿ä. ¡ÞNow you have to switch to the No.1 Line.(¿©±â¼­ 1È£¼±À¸·Î 
°¥¾ÆŸ¼¼¿ä.)¡ÞYou have to get over to the No.1 Line.(1È£¼± ÂÊÀ¸·Î °¡¼Å¼­ Ÿ¼¼¿ä.)
¢Ä ¿À´ÃÀÇ ÀϾî ÇѸ¶µð ¢Å
¢ÂÀϺ»¾îµµ ¿µ¾î¿Í °°Àº ÇüÅ·Π±¸¼ºµÇ¾î 
ÀÖ½À´Ï´Ù.¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ëdebian-devel´Ô ¾È³çÇϼ¼¿ä? 
ÀúÈñ´Â ÀüÈ­¸¦ ÀÌ¿ëÇؼ­ °­»ç¿Í 1 : 1 ·Î ¿Ü±¹¾î ÇнÀÀ» 
ÇÒ ¼ö ÀÖ´Â ¢Ä Online Korea ¢Å ¶ó°í 
ÇÕ´Ï´Ù.¹Ì¸® Çã¶ô¹ÞÁö ¾Ê°í ÆíÁö µå·Á Á˼ÛÇÕ´Ï´Ù. ºÎµð ³Ê±×·¯¿ì½Å ¿ë¼­¸¦..
ÀúÈñ ȸ»ç¿¡¼­´Â ¿Ü±¹¾î(¿µ¾î,ÀϾî)¿¡ °ü½É ÀÖ´Â 
¸¹Àº ºÐµé²² ¸ÅÀÏ(¿ù-±Ý), ¿µ¾îÀ¯¸Ó¿Í »ýÈ°¿¡ ÇÊ¿äÇÑ È¸È­ ÇÑ ¹®À徿À» ¹«·á·Î º¸³» µå¸®°í 
ÀÖ¾î¿ä.
À§¿Í °°Àº ³»¿ëÀÇ ¼­ºñ½º¸¦ ¹Þ¾Æº¸±â ¿øÇÏ½Ã¸é ¡ì [EMAIL PROTECTED] ¡í·Î "yes"¶ó´Â ³»¿ëÀÇ ´äÀåÀ» Áֽñ⠹ٶø´Ï´Ù. 
±×¸®°í, ÀúÈñ ÀüÈ­ ¿Ü±¹¾î °­ÀÇ°¡ ±Ã±ÝÇϽŠºÐµéÀ» À§ÇØ, 1ȸ¿¡ ÇÑÇؼ­¢Â ¹«·á ½Ã¹ü°­ÀÇ ¢Âµµ ½Ç½ÃÇØ µå¸®°í ÀÖÀ¸´Ï Çѹø µé¾îº¸°í 
½ÍÀ¸½Ã¸é Áö±Ý ½ÅûÇØ ÁÖ¼¼¿ä.
¹«·á ½Ã¹ü°­ÀÇ ½Åû ¹æ¹ýÀº ¢º ÀÌ°÷ ¢¸ À» Ŭ¸¯ÇϽŠÈÄ °­ÀÇ ½Åû¶õ¿¡ 
Àִ½ùü°­ÀÇ ½Åû ÆûÀ» ÀÛ¼ºÇϼż­ º¸³» ÁÖ½Ã¸é µË´Ï´Ù.¹°·Ð, ÀüÈ­ 02-588-0510 
À¸·Îµµ ½ÅûÇÏ½Ç ¼ö ÀÖ±¸¿ä.
¾Æ¹«ÂÉ·Ï ÀÌ ÇнÀ¹ýÀÌ debian-devel´ÔÀÇ È¸È­ ½Ç·Â Çâ»ó¿¡ ÀÛÀº º¸ÅÆÀÌ µÇ¾úÀ¸¸é 
ÇÕ´Ï´Ù.
debian-devel´Ô²²´Â http://www.kr.debian.org/contact.hu.html¿¡ ÀÖ´Â ÁÖ¼Ò¸¦ º¸°í ¸ÞÀÏ µå·È´Âµ¥¿ä,ºÒÇÊ¿äÇÑ 
Á¤º¸¿´´Ù¸é Á¤¸» Á˼ÛÇÕ´Ï´Ù.¾ÕÀ¸·Î Çã¶ô¾ø´Â ¸ÞÀÏÀº µå¸®Áö ¾Êµµ·Ï ÇÏ°Ú½À´Ï´Ù.±×·³, ¾È³çÈ÷ 
°è¼¼¿ä.

Re: Referring what kernel-images to build to the technical committee?

[Ilya Martynov]

RC> I've played many AVI files without MTRR support.  It will still
RC> work, just a bit slower.

I think it depends on configuration. On my home PC aviplay is almost
unusable without MTRR. It looks like slide show instead movie. aviplay
docs mention that some people reported up to x3 increase in
perfomance. I've not seen such perfomance increase myself but it is
really significant. With MTRR it is *possible* for me to watch movies.

RC> If programs won't run at all (as in the case of MMX and 3DNow!)
RC> then we should compile different kernels.  If they just don't run
RC> as fast then we can let the users compile their own kernels.

I understand your point. I just want you to understand that MTRR
support in kernel can be more important than you think. Nowdays Linux
is much less hackers project. There is a lot of people who don't need
to know how recompile kernel. Many of them want to watch movies. Many
of them will wonder 'Why Linux is so slow?'.

RC> If you want maximum video speed you want to compile your own
RC> kernel with AGP and DRI support etc...

AFAIK both AGP and DRI can be compiled as modules so they should be
compiled anyway in stock kernel.

-- 
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Ilya Martynov (http://martynov.org/)|
| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80  E4AE BE1A 53EB 323B DEE6 |
| AGAVA Software Company (http://www.agava.com/)  |
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: Referring what kernel-images to build to the technical committee?

[Russell Coker]

On Thursday 26 April 2001 16:38, Ilya Martynov wrote:
> RC> There is no need for a MTTR specific kernel.  MTTR is not really
> RC> needed as there is no software written which is unable to run
> RC> without it.  Our goal here should be compatibility with software.
> RC> MTTR can increase speed significantly in certain situations, but
> RC> there's lots of other ways of doing that for less effort which we
> RC> aren't supporting.  MTTR can allow you to work around broken
> RC> hardware.  But we can't provide enough kernels to support all
> RC> combinations of broken hardware (I am sure that I could find a
> RC> list of a dozen boolean options which are all needed to be in one
> RC> state or another for various broken hardware - we can't provide
> RC> 2^12 kernels).
>
> I think you are wrong about 'MTTR is not really needed'. One good
> example is aviplay (player for avi files). It perfomance is seriously
> affected by MTTR option. This fact is mentioned in its docs and I've
> seen myself *significant* difference in its perfomance when I've
> compiled kernel with MTTR option. Probably perfomance of simular
> programs will be affected too.

I've played many AVI files without MTRR support.  It will still work, just a 
bit slower.  If programs won't run at all (as in the case of MMX and 3DNow!) 
then we should compile different kernels.  If they just don't run as fast 
then we can let the users compile their own kernels.

If you want maximum video speed you want to compile your own kernel with AGP 
and DRI support etc...

-- 
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/   Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page

Re: Referring what kernel-images to build to the technical committee?

[Ilya Martynov]

RC> There is no need for a MTTR specific kernel.  MTTR is not really
RC> needed as there is no software written which is unable to run
RC> without it.  Our goal here should be compatibility with software.
RC> MTTR can increase speed significantly in certain situations, but
RC> there's lots of other ways of doing that for less effort which we
RC> aren't supporting.  MTTR can allow you to work around broken
RC> hardware.  But we can't provide enough kernels to support all
RC> combinations of broken hardware (I am sure that I could find a
RC> list of a dozen boolean options which are all needed to be in one
RC> state or another for various broken hardware - we can't provide
RC> 2^12 kernels).

I think you are wrong about 'MTTR is not really needed'. One good
example is aviplay (player for avi files). It perfomance is seriously
affected by MTTR option. This fact is mentioned in its docs and I've
seen myself *significant* difference in its perfomance when I've
compiled kernel with MTTR option. Probably perfomance of simular
programs will be affected too.

-- 
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Ilya Martynov (http://martynov.org/)|
| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80  E4AE BE1A 53EB 323B DEE6 |
| AGAVA Software Company (http://www.agava.com/)  |
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: auditd as logrotate replacement?

[Julian Gilbey]

On Wed, Apr 25, 2001 at 08:35:51PM -0300, Alejo Sanchez wrote:
> well, your version would do it the dlopen() way.
> actually we were going to ask if there was a
> restriction on depending on dlopen(), as it could
> be possible on some non-dynamic plataforms.
> (no shared libraries, no dl library)

You could look at libltdl from the libtool suite.  I guess you could
always use configure tests to figure this sort of stuff out.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: Referring what kernel-images to build to the technical committee?

[Russell Coker]

On Thursday 26 April 2001 09:05, Andreas Metzler wrote:
> > performance: By having images optimized for each processor on i386
> > users should see better performance.  I don't believe performance
> > numbers were quantified in the discussion but quantifying performance
> > is probably important to evaluating this tradeoff.
>
> [...]
>
> Hello!
> _Afair_ it is necessary to run a k6 (or athlon) "optimized" kernel to
> use 3DNow! in applications like xmms or lame. This probably applys to
> ISSE, MTTR and MMX, too.

I agree that having kernels compiled with support for different features is a 
good idea.

We must provide an i386 kernel.

There is software available which only runs with MMX.  We should offer a 
kernel with MMX support which requires Pentium-MMX to support running this.

For 3DNow! we should have a kernel which supports it.

There is no need for a MTTR specific kernel.  MTTR is not really needed as 
there is no software written which is unable to run without it.  Our goal 
here should be compatibility with software.  MTTR can increase speed 
significantly in certain situations, but there's lots of other ways of doing 
that for less effort which we aren't supporting.  MTTR can allow you to work 
around broken hardware.  But we can't provide enough kernels to support all 
combinations of broken hardware (I am sure that I could find a list of a 
dozen boolean options which are all needed to be in one state or another for 
various broken hardware - we can't provide 2^12 kernels).

Also I think that we should have an SMP kernel in the list.

Another issue is support for all the different SCSI controllers and RAID 
controllers.  Perhaps we should spend more time working on initrd support?

-- 
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/   Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page

Re: Problem with installing Postgres throught APT

[Oliver Elphick]

=?iso-8859-1?q?J=E9r=F4me?= Marant wrote:
[copied to the list for comments]
  >> Can you find out why it wants to remove libpgsql2.1. postgresql-client nee
  >ds
  >> this.
  >
  >  Here is the problem:
  >
  >libpgsql2.1 provides libpgsql2
  >  
  >and conflicts with libpgsql2
 
It hasn't stopped its being installed on my system or on a number of others.
I found the conflict was necessary to force the removal of libpgsql2, but
it does indeed provide libpgsql2 to other packages that depend on that.

I feel there must be some other problem with your system.

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "Submit yourselves therefore to God. Resist the devil, 
  and he will flee from you."  James 4:7 

Re: Gnome bug 94684

[Jaldhar H. Vyas]

On 25 Apr 2001, Thomas Bushnell, BSG wrote:

> There's a good reason.
>
> First, it is the sort of thing that might well be correctly solved in
> the Debian package and not upstream; that is, the best solution might
> be to provide a Debian upgrade path rather than a Gnome upgrade path.
>

I agree.  Those are the little "value-added" things a Debian package adds
to the raw source.  And it sounds like this is a trivial kind of thing to
fix.  At the very least the maintainer should have a debconf screen
popup that says "Use KDE!"  :-)

> Second, I can't keep track of who "upstream" is for all the Debian
> packages.
>

Why not?  It's in the copyright file of each package.  If it isn't--that's
a bug.

Zhaoway is right that you're a big boy and can talk to upstream
developers without having to go through a middleman.

> Third, the BTS is an exceptionally useful placeholder for "work needed
> here".  If the bug remains open in the BTS, then it serves to indicate
> the existence of the problem until its solved, and someone might
> actually fix it.  With Christian Marillat's excessively eager
> bug-closing, one would never even know of such things.
>

This is true as well.  What is the point of a bug tracking system if not
to track bugs.

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>

Re: updating of /etc/rc?.d

[Brendan O'Dea]

On Wed, Apr 25, 2001 at 09:43:56PM -0400, Jason Lunz wrote:
>[EMAIL PROTECTED] said:
>> I've thought for a while that perhaps update-rc.d should have a
>> --persistant option that would do the same thing as "remove" AND add a
>> K symlink in /etc/rc9.d/ -- a valid but unused runlevel -- so that
>> users could permanently disable things in one swift commandline.
>
>This is dpkg bug #67095. Is there any progress on this? I would love it
>if I didn't have to re-disable nfs and portmap each time I upgraded
>their packages.

It is possible to disable a service simply by removing links in
/etc/rc*.d .  So long as you leave at least one (/etc/rc0.d/K*package
would seem to be a good candidate), update-rc.d when called by packages
on upgrade is a no-op.  Something like:

  rm /etc/rc*.d/S*package

should generally do the trick.

Note, now that netbase has changed the dependency on portmap to a
`suggests' you may remove it anyway.

Regards,
-- 
Brendan O'Deabod@compusol.com.au
Compusol Pty. Limited  (NSW, Australia)  +61 2 9810 3633

Re: Packages not making it into testing

[Domenico Andreoli]

On Thu, Apr 26, 2001 at 12:52:39PM +0200, David N. Welton wrote:
> Domenico Andreoli <[EMAIL PROTECTED]> writes:
> 
> > On Wed, Apr 25, 2001 at 03:53:15PM +1000, Anthony Towns wrote:
> 
> > > + gdb uploaded 250 days ago, out of date by 240 days!  doesn't
> > > build on sparc, see 86882
> 
> > i'd like to adopt this, i'll mail to the maintainer.
> 
> Do you have the resources to try and follow it on non-intel
> architectures as well?  Gdb is a hairy package...
> 
mmmh, i cannot follow other arches, i have access to i386 only :(

talking about resource to dig into it, i'm not so sure. if i
never try i never can figure this out. i don't want to rewrite
it all now, i'm *sure* i have not enough skills.

-[ Domenico Andreoli, aka cavok
 --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

Re: kernel-{image,headers} package bloat

[Dale Scheetz]

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 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 linux-kernel archives where that has been discussed way too
> > > often already.
> >
> > Kernel modules exist in kernelspace, not userland. Building them against
> > any other headers than those used by glibc does nothing to improve the
> > stability or usefulness of Debian.
> 
> Ah, self-contradictory statement.
> 
> 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
> across kernel versions, let alone flavors).
> 
> Dale, get a clue about kernel module building.  You are completely wrong on
> this.

You're right, I'm an idiot. I have no idea what I was thinking...

I also don't know why I got diverted from the issue of bloat. The idea of
"flavours" seems to go beyond the version connectedness required by kernel
drivers. We have always delivered a kernel-header package for each version
of the kernel that we deliver. What is there about the modules problem
that suggests there should be even more flavours? The difference in
architectures is a simple symlink to the proper asm routines. What else
needs to be "tailored" that can't be handled in postinst.

The last thing we need in this distribution is more packages...

Luck,

Dwarf
--
_-_-_-_-_-   Author of "Dwarf's Guide to Debian GNU/Linux"  _-_-_-_-_-_-
_-_-
_- aka   Dale Scheetz   Phone:   1 (850) 656-9769 _-
_-   Flexible Software  11000 McCrackin Road  _-
_-   e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308_-
_-_-
_-_-_-_-_-  Released under the GNU Free Documentation License   _-_-_-_-
  available at: http://www.polaris.net/~dwarf/

Re: Packages not making it into testing

[David N. Welton]

Domenico Andreoli <[EMAIL PROTECTED]> writes:

> On Wed, Apr 25, 2001 at 03:53:15PM +1000, Anthony Towns wrote:

> > + gdb uploaded 250 days ago, out of date by 240 days!  doesn't
> > build on sparc, see 86882

> i'd like to adopt this, i'll mail to the maintainer.

Do you have the resources to try and follow it on non-intel
architectures as well?  Gdb is a hairy package...

Ciao,
-- 
David N. Welton
Free Software: http://people.debian.org/~davidw/
   Apache Tcl: http://tcl.apache.org/
 Personal: http://www.efn.org/~davidw/
 Work: http://www.innominate.com/

Re: Packages not making it into testing

[Domenico Andreoli]

On Wed, Apr 25, 2001 at 03:53:15PM +1000, Anthony Towns wrote:
> Hello world,
> 
ciao

> 
> + gdb uploaded 250 days ago, out of date by 240 days!
>   doesn't build on sparc, see 86882
> 
i'd like to adopt this, i'll mail to the maintainer.



-[ Domenico Andreoli, aka cavok
 --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

Re: libc6 broken?

[Petr Cech]

On Thu, Apr 26, 2001 at 12:28:51PM +0200 , Ulrich Wiederhold wrote:
> Hello,
> I upgraded to unstable and now, my libc6 seems to be borken.

works fine here. it wasn't upgraded in quite a while

> If I try a ./configure or a "make xconfig" with a new Kernel, I get this
> error-msg:
> /lib/libc.so.6: undefined reference to [EMAIL PROTECTED]'
> /lib/libc.so.6: undefined reference to [EMAIL PROTECTED]'

any optimized libs in /lib/i586(or whatever?)

Petr Cech
-- 
Debian GNU/Linux maintainer - www.debian.{org,cz}
   [EMAIL PROTECTED]

 "Debian - 3 million penguins can't be wrong."

libc6 broken?

[Ulrich Wiederhold]

Hello,
I upgraded to unstable and now, my libc6 seems to be borken.

If I try a ./configure or a "make xconfig" with a new Kernel, I get this
error-msg:
/lib/libc.so.6: undefined reference to [EMAIL PROTECTED]'
/lib/libc.so.6: undefined reference to [EMAIL PROTECTED]'

If I try a "make menuconfig", I get:
debian:/usr/src/linux-2.4.3# make menuconfig
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
make -C scripts/lxdialog all
make[1]: Entering directory `/usr/src/linux-2.4.3/scripts/lxdialog'
/lib/libc.so.6: undefined reference to [EMAIL PROTECTED]'
/lib/libc.so.6: undefined reference to [EMAIL PROTECTED]'
collect2: ld returned 1 exit status

>> Unable to find the Ncurses libraries.
>>
>> You must have Ncurses installed in order
>> to use 'make menuconfig'

make[1]: *** [ncurses] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.3/scripts/lxdialog'
make: *** [menuconfig] Error 2


I reinstalled my ncurseslibs and my libc6 packages, libstdc++-2.10-glibc
and so on, but still get the same error.

Any ideas?
(Using an upgraded unstable from today, did a dist-upgrade too)

Uli

ITP: darj - arj archive unpacking tool

[Richard Braakman]

(I filed this as bug#95252, but used X-Debian-CC instead of X-Debbugs-CC.
Strange... I remember it being X-Debian-CC once.)

  darj - arj archive unpacking tool

I've started writing a free version of unarj.  I have unarj installed
in case I come across .arj files on the net or on old floppies, and
vrms listed it once too often :)

So this is more of an "intent to write" than "intent to package", but
I do intend to package it once it is done.

I will duplicate unarj's interface as closely as I can (except
for the banner), both for ease of regression testing and in case
there are scripts that parse unarj's output.  I considered going
the other way and making it behave like a proper unix utility, but...
maybe in version 2.

Its current state is that it can list the files in an archive, but
can't uncompress or extract them.  I'm not looking for help (I'm
having fun writing this), but if you have any unusual arj archives
lying around then I would appreciate a copy for testing.

When it's done I will release it under the GNU GPL.

Richard Braakman

Intent to package vcdimager.

[Viral]

Hello all,

I plan to package vcdimager.

From the README :
  This is GNU VCDImager, a VideoCD image mastering tool.
  This package contains GNU VCDRip, a VideoCD ripping tool, for ripping
  mpeg streams from VideoCD images and showing VideoCD information about
  the image.

There already exists cdrdao which can clone VCDs, and vcdtools, which can
create a VCD image from mpegs. vcdimager rips mpegs from the VCDs.

viral

-- 
"There is no dark side of the moon really. Matter of fact it's all dark."


pgpeeWM2PLzL9.pgp
Description: PGP signature

Re: Only one who have parse error in /var/lib/dpkg/available?

[Herbert Xu]

Shaul Karl <[EMAIL PROTECTED]> wrote:
>> 
>> Is there a final new line?
>> 


> Yes there is:

> [12:36:41 /tmp]$ ls -l /var/lib/dpkg/available
> -rw-r--r--1 root root  2547713 Apr 25 00:46 
> /var/lib/dpkg/available
> [12:39:36 /tmp]$ od -cj 2547700 /var/lib/dpkg/available
> 11557764   c   e   9   1   8   0   f   a   4   2   d   f  \n
> 11560001
> [12:39:42 /tmp]$

I'm not sure if this is your problem, but there should be two final
new lines.  One to terminate the the MD5sum line, and one to terminate
the record.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: updating of /etc/rc?.d

[Herbert Xu]

Jason Lunz <[EMAIL PROTECTED]> wrote:

> This is dpkg bug #67095. Is there any progress on this? I would love it
> if I didn't have to re-disable nfs and portmap each time I upgraded
> their packages.

What's wrong with adding an exit 0 to the init.d files?
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Referring what kernel-images to build to the technical committee?

[Herbert Xu]

On Thu, Apr 26, 2001 at 12:58:10PM +1000, Craig Sanders wrote:
> On Wed, Apr 25, 2001 at 08:30:31PM -0400, Sam Hartman wrote:
> > [...]
> 
> i think you've done a good job of summarising the issues.

I agree as well.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: kernel-{image,headers} package bloat

[Herbert Xu]

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 images provide no/little benefit for our users.

2. The kernel images impose a strain on the mirrors that we can do without.

1 is a matter of opinion, and one which I do not agree with.

I do understand that everyone is operating under constrained resources.  So
I'm always on the lookout for images that have little use or images that
can be merged.  In particular, pentium4 will go in the next release as
there is very little demand for it, and for those who actually have it,
I doubt compiling the kernel is very time consuming [1].

This will bring the number of images down to 7, or in terms of size, about
70MB.

I'm willing to further reduce that to as little as 3 with the removal of
586/586tsc/k6/k7.  However, I would like to see concrete evidence from
mirror operators that this 40M poses a significant problem for them before
I take this route as except k7, the three flavours take significant to
compile on their respective hosts.  I won't go below that as an SMP kernel
is always required, and the 686 flavour covers a very large chunk of the
i386 userbase.

As to the kernels on the alpha architecture which I also maintain, I have
no plans whatsoever to go down this optimisation route as there simply
aren't enough users to justify the costs involved.  It is also the case
that I simply to have an Alpha box that's sexy enough to do this :)

I cannot comment about the kernel maintainers on other architectures of
course.  But I'm sure they will make the most sensible decisions for them.

[1] The point of this exercise is not to make it easier for people who don't
know how to compile kernels to be able to use optimised kernels.  It is
for those who don't have a grunty box to keep up with the them.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Packages not making it into testing

[Hamish Moffatt]

On Wed, Apr 25, 2001 at 05:49:24PM -0500, Rahul Jain wrote:
> On Wed, Apr 25, 2001 at 11:57:50PM +1000, Hamish Moffatt wrote:
> > Doesn't the user have to belong to the relevant group anyway?
> > We already control access to things like floppy drives, sound
> > cards etc through groups, so cd burning is another good example.
> 
> I don't see how sgid cdrom will help here. Just make it non-sgid, and if
> they're a member of group cdrom, they can burn a cd, period. 

That's what I was saying we should do. That's what we do with other
special hardware like audio and floppy drives.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Only one who have parse error in /var/lib/dpkg/available?

[Shaul Karl]

> On Wed, 25 Apr 2001, Shaul Karl wrote:
> 
> > Package: ng-cjk
> > Priority: optional
> > Section: editors
> > Installed-Size: 164
> > Maintainer: Yasuhiro Take <[EMAIL PROTECTED]>
> > Architecture: i386
> > Source: ng
> > Version: 1.4.3.1-1
> > Depends: libc6 (>= 2.2.1), libncurses5, ng-common
> > Filename: pool/main/n/ng/ng-cjk_1.4.3.1-1_i386.deb
> > Size: 73550
> > MD5sum: dcf8a20ce9180fa42df
> > [22:46:18 /tmp]$ wc /var/lib/dpkg/available
> >   69953  307766 2547713 /var/lib/dpkg/available
> > [22:46:41 /tmp]$
> 
> Is there a final new line?
> 


Yes there is:

[12:36:41 /tmp]$ ls -l /var/lib/dpkg/available
-rw-r--r--1 root root  2547713 Apr 25 00:46 /var/lib/dpkg/available
[12:39:36 /tmp]$ od -cj 2547700 /var/lib/dpkg/available
11557764   c   e   9   1   8   0   f   a   4   2   d   f  \n
11560001
[12:39:42 /tmp]$

and 
dpkg -l doc-linux-text
works too. I do not know what was changed.

Shouldn't there be a Description field after the MD5sum?

-- 

Shaul Karl <[EMAIL PROTECTED]>

Re: RFC: Thoughts on building modules

[Herbert Xu]

Sam Hartman <[EMAIL PROTECTED]> wrote:

> I see three options.  We can have the modules built out of the main
> source package that also produces the architecture: all package
> containing the tarball for end users to use with kernel-package.
> Alternatively, we can have a separate modules source package for
> building only the module; this has the advantage of separating the
> module components from other components of the system, which is nice
> for things like PCMCIA and Openafs that have significant userspace
> components.  We could also try and get module building integrated into
> stock kernel source packages; this would have the advantage of

I personally prefer a variant of the second option, have a per-arch source
package which build-depends on a module-source .deb produced by the main
module source package.  The reason it has to be per-arch is given later in
your message, i.e., you don't want to recompile the i386 modules if the
alpha kernel gets updated.  The same per-arch package should build-depend
on the respective kernel-headers packages for the images that it wants to
build against.

BTW, this is how the kernel images are organised on alpha/i386/sparc.

If your module needs stuff outside kernel-headers, either it's doing
something wrong, or there's stuff in the kernel that needs to be moved
under include/.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: kernel-{image,headers} package bloat

[Herbert Xu]

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 Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

libc6 broken?

[Ulrich Wiederhold]

Hello,
I upgraded to unstable and now, my libc6 seems to be borken.

If I try a ./configure or a "make xconfig" with a new Kernel, I get this
error-msg:
/lib/libc.so.6: undefined reference to [EMAIL PROTECTED]'
/lib/libc.so.6: undefined reference to [EMAIL PROTECTED]'

If I try a "make menuconfig", I get:
debian:/usr/src/linux-2.4.3# make menuconfig
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
make -C scripts/lxdialog all
make[1]: Entering directory `/usr/src/linux-2.4.3/scripts/lxdialog'
/lib/libc.so.6: undefined reference to [EMAIL PROTECTED]'
/lib/libc.so.6: undefined reference to [EMAIL PROTECTED]'
collect2: ld returned 1 exit status

>> Unable to find the Ncurses libraries.
>>
>> You must have Ncurses installed in order
>> to use 'make menuconfig'

make[1]: *** [ncurses] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.3/scripts/lxdialog'
make: *** [menuconfig] Error 2


I reinstalled my ncurseslibs and my libc6 packages, libstdc++-2.10-glibc
and so on, but still get the same error.

Any ideas?
(Using an upgraded unstable from today, did a dist-upgrade too)

Uli

Re: kernel-{image,headers} package bloat

[Brendan O'Dea]

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 think everyone is in favour of that.
>
>the issue is whether it's appropriate to have a dozen or so kernel-image
>packages (and associated kernel-headers packages) per kernel version,
>when one(*) will do.

Don't forget the proliferation of kernel modules in that count.  This
has already started with alsa recently, and I expect that more will
follow before too long:

alsa-modules-2.4.3-386
alsa-modules-2.4.3-586
alsa-modules-2.4.3-586tsc
alsa-modules-2.4.3-686
alsa-modules-2.4.3-686-smp
alsa-modules-2.4.3-k6
alsa-modules-2.4.3-k7
alsa-modules-2.4.3-pentium4
alsa-modules-2.4.3-pentiumiii
alsa-modules-2.4.3-pentiumiii-smp
kernel-headers-2.4.3
kernel-headers-2.4.3-386
kernel-headers-2.4.3-586
kernel-headers-2.4.3-586tsc
kernel-headers-2.4.3-686
kernel-headers-2.4.3-686-smp
kernel-headers-2.4.3-k6
kernel-headers-2.4.3-k7
kernel-headers-2.4.3-pentium4
kernel-headers-2.4.3-sparc
kernel-image-2.4.3-386
kernel-image-2.4.3-586
kernel-image-2.4.3-586tsc
kernel-image-2.4.3-686
kernel-image-2.4.3-686-smp
kernel-image-2.4.3-k6
kernel-image-2.4.3-k7
kernel-image-2.4.3-pentium4

Regards,
-- 
Brendan O'Deabod@compusol.com.au
Compusol Pty. Limited  (NSW, Australia)  +61 2 9810 3633

Re: Referring what kernel-images to build to the technical committee?

[Andreas Metzler]

Sam Hartman <[EMAIL PROTECTED]> wrote:
[...]
> Summary: Herbert has started building 8 different flavors of
> kernel-image for i386.  These flavors correspond to CPU type; for
> example there is an appropriate kernel for people with 386 machines to
> run and an appropriate kernel for people with Athlon machines to run.
[...]
> I'd like to summarize my understanding of the tradeoffs that we have
> identified in the debian-devel discussion so that if we do turn this
> issue over to the committee, they will know what concerns we have
> already identified.  Please add to the following list if I have missed
> something. 
[...]
> performance: By having images optimized for each processor on i386
> users should see better performance.  I don't believe performance
> numbers were quantified in the discussion but quantifying performance
> is probably important to evaluating this tradeoff.
[...]

Hello!
_Afair_ it is necessary to run a k6 (or athlon) "optimized" kernel to
use 3DNow! in applications like xmms or lame. This probably applys to
ISSE, MTTR and MMX, too.

Please correct me if I am wrong.
 tia, cu andreas
-- 
Uptime: 10 seconds  load average: 0.00, 0.00, 0.00
vim:ls=2:stl=***\ Sing\ a\ song.\ ***

Re: ITP: ttf-japanese-kandata

[Osamu Aoki]

Thank you very much for checking facts.

(I think if there is more to be discussed on this copyright, it should
be moved to debian-legal list.)

With your statement as presented, I had to concur with Branden. But I
actually think this can be made into DFSG free package if you present
copyright issues properly to the public with further documentation from
Wakaba-san / Uchida-san.  If there still remain any issues in some part
of FONT, you can always remove those portions from package and replace
them with the other PD fonts.  If someone spend time in the future and
provide patch to make them as homogeneous feel, that will make good FREE
font set.

As far as Uchida-san's portion is concerned, they are clearly PD.

Big question is what did Mr. Wakaba used as the base of glyph.  And how
far modification later affected the total collection.  If he started
with then popular PC9800's ROM fonts with mere 16x16 bitmap fonts as
starting point of making TT fonts, it may be well within fair use.

This becomes more so, if heavy manual editing occurred to make these TT
fonts to look homogeneous and legal shape.  If he took these from TT MS
fonts, maybe not. (Here I am talking complicated KANJI where 7
horizontal lines need to be identified within this small 16x16 bitmap
space.  It is equivalent of 8x8 in English)  Documenting history of this
font set and making them into clean set is the worthy cause.

Following may be useful as a reference point for the copyright law.

If I remember correctly, basic shape of glyph is not be copyrighted
since it is common to all fonts and should be legible.  Also for dot
matrix fonts, mere coincident does not make a violation of copyright due
to limited possibility of choice.

Also note that, even with new copyright law, font itself is not covered
by the copyright law in Japan.  (Software is covered.) Japan has not
verified WIPO 1997 treaty on this typeface thing either.  (That is my
web search result. IANAL.) 

I remember reading that ADOBE created postscript fonts in such a way
that they can claim them as a "software" in which shape is programmed
into a code.  (This is to make sure they keep their right under most
legal system.)  So copyright of fonts are slightly different issue from
ordinary software copyright in legal term.

Regards,

Osamu

On Thu, Apr 26, 2001 at 12:22:46AM +, Takashi Okamoto wrote:
> document were not remained yet. Mr. wakaba said "I think there is no
> problem because I(wakaba) and Mr.UCHIDA remake a lot of glyphs and
> nobody point out the problem up to now. But I can't guarantee it."

-- 
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ 
+  Osamu Aoki <[EMAIL PROTECTED]>, GnuPG-key: 1024D/D5DE453D  +
+   Fingerprint: 814E BD64 3288 40E7 E88E  3D92 C3F8 EA94 D5DE 453D   +
+   http://www.aokiconsulting.com/ Cupertino, CA USA  +

Re: Gnome bug 94684

[Thomas Bushnell, BSG]

zhaoway <[EMAIL PROTECTED]> writes:

> The package maintainer is a volunteer, and he knows you are also a
> developer. That said, why don't you report the bug directly to the
> upstream, instead of insisting on this (bureaucratic) procedure of
> reporting bugs to debian then waiting that debian developer to forward
> upstream while both of you debian developers are pretty sure it's an
> upstream issue? I agree that if you're a noname random clueless mere
> user then the package maintainer shouldn't just close this usibility
> bug blindly.

There's a good reason.

First, it is the sort of thing that might well be correctly solved in
the Debian package and not upstream; that is, the best solution might
be to provide a Debian upgrade path rather than a Gnome upgrade path.

Second, I can't keep track of who "upstream" is for all the Debian
packages.

Third, the BTS is an exceptionally useful placeholder for "work needed
here".  If the bug remains open in the BTS, then it serves to indicate
the existence of the problem until its solved, and someone might
actually fix it.  With Christian Marillat's excessively eager
bug-closing, one would never even know of such things.

I'm happy if Christian doesn't have the time or expertise to fix the
bug himself.  He should leave it as a bug, or forward it.  But "I
don't know how to fix it" is not a reason for closing the bug.

Thomas

Re: Gnome bug 94684

[zhaoway]

You guys are getting more and more bureaucratic. That's sad.

The package maintainer is a volunteer, and he knows you are also a
developer. That said, why don't you report the bug directly to the
upstream, instead of insisting on this (bureaucratic) procedure of
reporting bugs to debian then waiting that debian developer to forward
upstream while both of you debian developers are pretty sure it's an
upstream issue? I agree that if you're a noname random clueless mere
user then the package maintainer shouldn't just close this usibility
bug blindly.

Bureaucracy sucks. Relying on bureaucracy sucks even more.

-- 
http://dim.sourceforge.net ... Debian Chinese Input Method
http://njlug.sourceforge.net  NanJing GNU/Linux User Group
http://cdlinux.sourceforge.net ... Debian running on Live! CDs
http://people.debian.org/~zw .. XEmacs Screenshots

Re: kernel-{image,headers} package bloat

[Craig Sanders]

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, netfilter patches, their own hacks, etc, etc.

please pay attention. 

nobody (at least as far as i can tell) has suggested getting rid of the
stock kernel-image package, so there will be no effect at all on people
who just want to install the system and run it.

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.

craig

--
craig sanders <[EMAIL PROTECTED]>

  GnuPG Key: 1024D/CD5626F0 
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57  52C3 EC32 6810 CD56 26F0

Re: kernel-{image,headers} package bloat

[Craig Sanders]

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 appropriate to have a dozen or so kernel-image
packages (and associated kernel-headers packages) per kernel version,
when one(*) will do.

(*) or whatever the minimum number is that will boot on all ia32 boxes.

craig
--
craig sanders <[EMAIL PROTECTED]>

  GnuPG Key: 1024D/CD5626F0 
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57  52C3 EC32 6810 CD56 26F0

Re: kernel-{image,headers} package bloat

[David Nusinow]

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 would need to install the
> kernel-custom package, make a selection, and wait a bit.
>

I'm going to have to agree on this one. I don't think anyone should be
forced to compile a kernel, but if you care enough to want the
optimizations then you should go through the process of doing it for
yourself. That way, things will keep working quite well for those who
want it to just work, and for those who want to shear off a few k of
memory, they can do it for themselves. Everyone has a working kernel,
module debate is moot, extra mirror load is nil, and most all the other
major points of contention go away as well.

Just my $0.02

- David Nusinow
   [EMAIL PROTECTED]

 

Re: Base Bug Week, 30th April to 6th May

[Gordon Sadler]

On Thu, Apr 26, 2001 at 02:52:11PM +1000, Brian May wrote:
> > "Martin" == Martin Michlmayr <[EMAIL PROTECTED]> writes:
> 
> Martin> Since the base system comprises our most important
> Martin> packages, virtually all of which are installed on any
> Martin> Debian system, your help is really needed!  While Bug
> Martin> Squashing Parties usually focus on Release Critical (RC)
> Martin> bugs, we should also try to get the number of normal (or
> Martin> even wishlist) bugs in the base as low as possible.  This
> Martin> involves writing patches or documentation -- everyone can
> Martin> help with this; also non developers are encouraged to
> Martin> participate.
> 
> What is the easiest way to upgrade only base packages without
> upgrading anything else (unless required?).
> 
> Ideally I would like to upgrade/install anything section==base or
> priority==required, but not anything else just yet (as I don't like
> upgrading to much stuff, partly because of the huge bandwidth
> required).
> 
> Is this possible without manually copying&pasting from dselect?
>
Just enter dselect, then on each category that you have packages
installed, except for base/required, choose to hold them '='.

Should be that simple, although I haven't run dselect in months.

Gordon Sadler