Re: RFC: packaging kernel modules

[Wichert Akkerman]

Previously Branden Robinson wrote:
> For the sake of raging paranoia about namespace pollution, perhaps the
> directory is best called "kernel-modules".

Since we already have pcmcia packages use /usr/src/modules and nobody
seems to complain about that, I think it's save to use that.

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpAMuGth2SWO.pgp
Description: PGP signature

Re: RFC: monitoring maintainers' vacations

[peloy]

Yann Dirson <[EMAIL PROTECTED]> wrote:
[...]
> What would be nice is a mechanism which would allow us to tell the
> periods when we're expecting to be totally offline, or have a sparse
> connectivity, or ...
[...]
> This proposal is probably not fully optimal; I may have overlooked
> some interesting possibilities.
[...]

Sound like a very nice idea :-)

peloy.-

-- 

Eloy A. Paris
Information Technology Department
Rockwell Automation Venezuela
Telephone: +58-2-9432311 Fax: +58-2-9431645


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: packaging kernel modules

[Wichert Akkerman]

Previously Yann Dirson wrote:
> It does not seem that we have currently any conventions regarding the
> packaging of kernel modules.  I just tried the new alsadriver from
> slink, and, for the same reason I could not use the packaged joystick
> driver, this one too is useless to me.

Can you try recompiling the source package and use that? And what
kernel version are you using? (own compile, kernel version, etc.)

> 2) These packages only provide compiled modules for some special
> kernel version.  Eg, alsa install its modules for 2.0.33; joystick
> used to do it for 1 version I don't remember, and after a bug report,
> finally included the driver for 2 kernel versions, which even did not
> solve my problem, for the above-mentionned reason.

This is always a horny problem, which is inherrent to changing kernel
interface. I've compiled the ALSA-packages on my own 2.0.33 kernel (somewhat
patched), but it should work on other 2.0.33 kernels AFAIK.

> kernel-package, which seem to be the tool to build a kernel the Right
> Way on a Debian system, provides a framework to also build the
> relevant modules from /usr/src/modules/, which can IMHO be used to
> solve these problems.

I have no idea how flexibable kernel-package is with respect to other
modules, or how the interface works. If there is a general interface I
would be happy to incorporate it in the alsa-packages. 

> I think the various modules should be primarily packaged in source
> form, just as the kernel is, and installed under /usr/src/modules/.

And packaged compiled for the standard kernel-image packages, so we
can use them on the bootdisks if wanted.

> * The ultra, ibcs, ftape drivers also use the $(uname -r) string in
> the package name, but do not provide a source package for
> recompilation; most of them provide support for only one kernel
> version.

Probably the same thing is true for ntfs and smbfs(?). Some other
packages (autofs comes to mind) rely on kernel support but don't
include the modules themselves.

> Note that I had the idea of packaging alsa myself, but I wanted to
> discuss these issues first...

I guess you're a little too late :)
BTW: if anyone has any comments on the configure-script, please let 
me know. I nobody has any complaints I will sent it upstream.

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpRq5y7JTLB7.pgp
Description: PGP signature

Re: RFC: monitoring maintainers' vacations

[Wichert Akkerman]

Previously Yann Dirson wrote:
> What would be nice is a mechanism which would allow us to tell the
> periods when we're expecting to be totally offline, or have a sparse
> connectivity, or ...

Personally, I always install vacation when I'm away for an extended
period of time. Couldn't maintainers just install vacation on the
account on master? This way when someone mails them a reply
is automatically made stating the maintainer is away. More processing
could easily be added..

Of course, this only works for maintainers which use there debian.org-address
as their maintainer address, but I expect that people use other addresses
can install vacation locally.

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpfdgNMkQu51.pgp
Description: PGP signature

Re: RFC: packaging kernel modules

[Jason Gunthorpe]

On Wed, 10 Jun 1998, Yann Dirson wrote:

> It does not seem that we have currently any conventions regarding the
> packaging of kernel modules.  I just tried the new alsadriver from
> slink, and, for the same reason I could not use the packaged joystick
> driver, this one too is useless to me.

Hm, we should really talk to the kernel people.. but here is my thoughts,
  #1 - If person X compiles a module for kernel x.x.x and it doesn't work
   on your compile of x.x.x then you need to recompile your kernel.
   [General rule, most modules don't try to deduce what symbols are
available]
  #2 - Many modules will likely work on a series of kernels depending on 
   the extent of the interfaces used and other issues.

In the case of alsa I think it should compile for 2.0 and go into the 2.0/
modules directory that appears to be on my machine.

The proper solution is to simply get the kernel people to version the API
and allow modules to declare an API version requirement, or just stabalize
the module API.

Jason


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Boot Dependancies - a weird wacky wonderful new idea

[Robert Woodcock]

Hello, I have an idea (ok, maybe not an original idea, but bear with me :)

It involves the sysvinit (/etc/init.d/rcS and a lotta other stuff) and
dpkg packages. (update-rc.d) 

Parallelized booting. What this means is we run multiple bootup scripts
simultaneously. It's a *lot* faster on mid-to-higher-end machines, even
with just one CPU - it'd be wickedly fast with SMP.

"Hey wait a second that won't work!!! What if the netstd_nfs script runs
before the netbase script is done processing?"

Well, you're right, but I have another (slightly more original) idea that
will make it work. Boot-time dependancies.

* Instead of relying on those icky priority numbers we just had a flame
  war or two about, the packages tell us how they *really* feel and state
  precisely in a file (I'm thinking /etc/init.d/deps/[KS]packagename) what
  needs to be successfully running (or not running) before or after they
  can start. Do we need to make this information separate for each runlevel?
  (i.e. make it /etc/rc?.d/deps/[KS]packagename instead?)

* /etc/init.d/rc is modified to call a program that determines the order
  the scripts should be run in, on the fly. I figure this won't be much
  of a speed hit. Slrn can thread thousands of messages per second across
  a localhost news connection on my machine, sorting 30 scripts shouldn't
  take long either. Actually, we don't even need to thread, we can probably
  get away with just checking on script exit (any script exit) whether
  there's something else available to run or not - if there's nothing else
  available but there's still stuff that wants to be run, we can just run
  it anyway.

* Because a fatal error on bootup is simply not an acceptable option,
  dependancies are considered 'soft' - if a dependancy can not be met
  for whatever reason, it is simply ignored. (This is what our existing
  setup with priority numbers does anyway.) We'd want to keep a debugging
  flag in the works to reveal such a situation though.

* update-rc.d is modified to ignore priority numbers and keep things in
  the new format. (hmmm, perhaps we can be trickier than this.)

Problems looming:

* Installing new packages using the new dependancy format on older machines
  without thread-scripts needs to be handled - perhaps we can keep the NN
  switch to update-rc.d calls in new packages (at least for a while)

* Going back and forth from the old setup to the new one won't be a walk in
  the park. I'd need to make a conversion utility.

* My coding skills ;)

I still have yet to create proof-of-concept code for this but the general
idea has created such a buzz in #debian that we might just see something :)

As for the file formats of /etc/init.d/deps/[KS]packagename, I was
thinking something along the lines of:

After:   
Before:  

I feel this information absolutely positively must be admin-editable, which
dictates some type of text file format.

Perhaps we could give it the idea of psuedo-packagenames such as 'everything'
so we can have 'After: everything' for Srmnologin and Sxdm.

i.e. /etc/init.d/deps/Sbind would have:
-CUT-
After: sysklogd kerneld netstd_init
-CUT-

If we are ever going to do this it would require at least the agreement of
Miquel van Smoorenburg, Klee Dienes, and Ian Jackson (current sysvinit and
dpkg maintainers) and a good concensus among the Debian developers,
preceeded by a LOT of discussion, so I figured I'd throw it out onto
debian-devel and await the replies: "so... what *is* that you're smoking?" :)

Please let me know what you think of this.
-- 
Robert Woodcock - [EMAIL PROTECTED]
"Unix and C are the ultimate computer viruses" -- Richard Gabriel


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Hamish Moffatt]

On Wed, Jun 10, 1998 at 05:24:06PM -0400, Dale Scheetz wrote:
> kernel image files (some laptops still can't boot a bzImage) as well as
> some alternative root.bin choices. A more powerful rescue disk, separate
> from the installation disk would be a great place to start.

Can someone give me a quick summary of bzImage vs zImage and why Debian
needs to use bzImage on the root disks at all? Not only does it cause
problems with some notebooks, it causes problems my desktop -- spontaneous
reboots after "Uncompressing Linux" sometimes. 


Hamish
-- 
Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Jason Gunthorpe]

> Can someone give me a quick summary of bzImage vs zImage and why Debian
> needs to use bzImage on the root disks at all? Not only does it cause
> problems with some notebooks, it causes problems my desktop -- spontaneous
> reboots after "Uncompressing Linux" sometimes. 

Well. It goes like this.

When you boot the kernel it copies the Image from the disk to 0x1000
(about 64k). If the Image is beyond 600k then you have a problem because
it suddenly will not all fit in low memory.

A bzImage is more sinister. After it loads a few block in it makes some
bios calls to copy the blocks up to 1 meg where the 3rd stage boot loader
will run. After that it uncompresses the kernel to some location then 
copies it to it's proper placement at 1M. a zImage simply uncompresses the
kernel to 1M.

In theory, on a notebook the int calls are glitchy and crash the system.

If your kernel is > 600k you MUST use a bzImage and you MUST load it into
memory above a meg (ie protected mode). zImages work until that limit is
reached. 

I'm not sure how syslinux loads the ram disk, but I think it must load it
into high memory and it might use bios calls to do it.. It's also possible
that syslinux is unsing an incompatible way of fiddling into protected
mode that mucks things up, I've only looked at the kernel boot loader.

Jason 
Who just today got a 200k 2.0.34 zImage kernel to boot off flash on an
embedded AMD 586 from Octagon



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Hamish Moffatt]

On Wed, Jun 10, 1998 at 09:17:20PM -0600, Jason Gunthorpe wrote:
> When you boot the kernel it copies the Image from the disk to 0x1000
> (about 64k). If the Image is beyond 600k then you have a problem because
> it suddenly will not all fit in low memory.
> 
> A bzImage is more sinister. After it loads a few block in it makes some
> bios calls to copy the blocks up to 1 meg where the 3rd stage boot loader
> will run. After that it uncompresses the kernel to some location then 
> copies it to it's proper placement at 1M. a zImage simply uncompresses the
> kernel to 1M.
> 
> In theory, on a notebook the int calls are glitchy and crash the system.
> 
> If your kernel is > 600k you MUST use a bzImage and you MUST load it into

So is there any other advantage? 600k is pretty big for a default
kernel, especially since we are making heavy use of modules. My custom 2.0.34
is 300k odd, although obviously the Debian one needs a bunch of SCSI drivers.
If we are < 600k, why use it when it is problematic?

I've no idea why my desktop hates it. Everything else about the machine is
perfect, and it's a custom-built clone rather than some IBM or Compaq
box, the sought with weird BIOSen.

Hamish
-- 
Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Volunteer(s) wanted to help with owner@bugs.debian.org (fwd)

[M.C. Vernon]

Dear all,

I replied to this as well, but didn't cc to the list. Here is the
original message for reference.

Matthew

-- 
Elen sila lumenn' omentielvo

Steward-elect of the Cambridge Tolkien Society
Selwyn College Computer Support
http://www.geocities.com/Area51/Chamber/8841/
http://www.cam.ac.uk/CambUniv/Societies/tolkien/
http://pick.sel.cam.ac.uk/

-- Forwarded message --
Date: Wed, 10 Jun 1998 13:31:23 +0100 (BST)
From: "M.C. Vernon" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: Ian Jackson <[EMAIL PROTECTED]>
Subject: Re: Volunteer(s) wanted to help with [EMAIL PROTECTED]


> 1. Reading and responding to [EMAIL PROTECTED] mail.  Usually this
> is routine, and just means you have to mail people saying `you sent
> this to [EMAIL PROTECTED] when [EMAIL PROTECTED] was not the right place'.  
> Many
> messages are followups of various kinds to bug reports, and there are
> occasional messages with instructions for [EMAIL PROTECTED] sent there
> too.  This is not a technically skilled job, but some familiarity with
> the Debian Project's organisation would be necessary.

Ian,

I'll do this if you like, but: 
1)My connectivity over the summer vac is slow
2)I don't claim to be a technical wizard of any description
3)You might not want a student doing that sort of official stuff

But yes, I am quite happy to give it a go.

HTH,

Matthew

-- 
Elen sila lumenn' omentielvo

Steward-elect of the Cambridge Tolkien Society
Selwyn College Computer Support
http://www.geocities.com/Area51/Chamber/8841/
http://www.cam.ac.uk/CambUniv/Societies/tolkien/
http://pick.sel.cam.ac.uk/




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Jason Gunthorpe]

On Thu, 11 Jun 1998, Hamish Moffatt wrote:

> > If your kernel is > 600k you MUST use a bzImage and you MUST load it into
> 
> So is there any other advantage? 600k is pretty big for a default
> kernel, especially since we are making heavy use of modules. My custom 2.0.34
> is 300k odd, although obviously the Debian one needs a bunch of SCSI drivers.
> If we are < 600k, why use it when it is problematic?

If we are < 600k (they actually recommend 500k, but 590k is more like
it) then bz kernels are a very bad idea.

Manoj, does the kernel package always build bzimages or does it look at
the size of gzip -9 vmlinux and decide based on that?
 
> I've no idea why my desktop hates it. Everything else about the machine is
> perfect, and it's a custom-built clone rather than some IBM or Compaq
> box, the sought with weird BIOSen.

What is your boot loader? I've only inspected the kernel default (ie dd
if=bzImage of=/dev/fd0) no idea what lilo, grub, syslinux or loadlin do,
but the end results must be the same.

Jason


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Hamish Moffatt]

On Wed, Jun 10, 1998 at 09:39:01PM -0600, Jason Gunthorpe wrote:
> > I've no idea why my desktop hates it. Everything else about the machine is
> > perfect, and it's a custom-built clone rather than some IBM or Compaq
> > box, the sought with weird BIOSen.
> 
> What is your boot loader? I've only inspected the kernel default (ie dd
> if=bzImage of=/dev/fd0) no idea what lilo, grub, syslinux or loadlin do,
> but the end results must be the same.

Bog-standard lilo, latest version from hamm. The NT loader runs before
that but I doubt that makes a difference.


Hamish
-- 
Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Jason Gunthorpe]

On Thu, 11 Jun 1998, Hamish Moffatt wrote:

> On Wed, Jun 10, 1998 at 09:39:01PM -0600, Jason Gunthorpe wrote:
> > > I've no idea why my desktop hates it. Everything else about the machine is
> > > perfect, and it's a custom-built clone rather than some IBM or Compaq
> > > box, the sought with weird BIOSen.
> > 
> > What is your boot loader? I've only inspected the kernel default (ie dd
> > if=bzImage of=/dev/fd0) no idea what lilo, grub, syslinux or loadlin do,
> > but the end results must be the same.
> 
> Bog-standard lilo, latest version from hamm. The NT loader runs before
> that but I doubt that makes a difference.

Tried booting from a floppy created with dd?

Jason


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Rescue and Installation (was Re: VI reasons)

[Steve Shorter]

On Wed, 10 Jun 1998, Dale Scheetz wrote:

> I believe the right solution would be to design a separate, true, rescue
> disk (what we now call the rescue disk is, in fact, the installation boot
> disk) that has none of the installation software installed, but simply
> boots into a single user shell with an appropriate set of tools, like vi,
> fdisk, dd, ... so that the exprienced sys admin (or consultant) can come
> in and recover broken systems. This is fundamentally a different job from
> system installation. (in fact if the system installation is perfect you
> need no additional tools at all ;-)

Exactly! System "rescue" is fundamentally different from
"installation". It is logical and expedient to seperate the two functions.  

-steve


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Hamish Moffatt]

On Wed, Jun 10, 1998 at 09:44:53PM -0600, Jason Gunthorpe wrote:
> On Thu, 11 Jun 1998, Hamish Moffatt wrote:
> 
> > On Wed, Jun 10, 1998 at 09:39:01PM -0600, Jason Gunthorpe wrote:
> > > > I've no idea why my desktop hates it. Everything else about the machine 
> > > > is
> > > > perfect, and it's a custom-built clone rather than some IBM or Compaq
> > > > box, the sought with weird BIOSen.
> > > 
> > > What is your boot loader? I've only inspected the kernel default (ie dd
> > > if=bzImage of=/dev/fd0) no idea what lilo, grub, syslinux or loadlin do,
> > > but the end results must be the same.
> > 
> > Bog-standard lilo, latest version from hamm. The NT loader runs before
> > that but I doubt that makes a difference.
> 
> Tried booting from a floppy created with dd?

Same problem, if memory serves correctly. Will check it out asap.

Hamish
-- 
Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Jason Gunthorpe]

On Thu, 11 Jun 1998, Hamish Moffatt wrote:

> > Tried booting from a floppy created with dd?
> 
> Same problem, if memory serves correctly. Will check it out asap.

Upon reflection it occures to me that there are two other possibilities

1) The bios calls to access high memory make it so that the kernel routine
   to do  (page table setup?) reboots the machine
2) It does not get properly copied to the 1 meg location and reboots
   because it executes random memory during decompression.

You can eliminate #2 by putting a huge for loop (delay) in
arch/i386/boot/compressed/misc.c decompress_kernel (from memory)

If it actually does decompress the kernel then #1 is likely, perhaps talk
to the kernel people? When the line 'Uncompressing the kernel' is printed
the machine is running in protected mode.

Jason


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

APT 0.0.16

[Jason Gunthorpe]

APT 0.0.16 is available for both bo and hamm. Please let me know if there
are any bugs that got missed, I'm getting very few bug reports these days.

Thanks,
Jason


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: APT 0.0.16

[Brandon Mitchell]

On Wed, 10 Jun 1998, Jason Gunthorpe wrote:

> APT 0.0.16 is available for both bo and hamm. Please let me know if there
> are any bugs that got missed, I'm getting very few bug reports these days.

Just grabbed it after doing a dselect update and select with apt 15.  Went
back to dselect for an update and found:

/usr/lib/dpkg//methods/apt/update: line 3: 11448 Segmentation fault
(core dumped) apt-get update

update available list script returned error exit status 139.
Press RETURN to continue.

I will attach a core file and my status file in a seperate message Jason

Brandon

--+--
Brandon Mitchell <[EMAIL PROTECTED]> | Debian Testing Group Status
PGP Key:   finger -l [EMAIL PROTECTED] |  http://bhmit1.home.ml.org/deb/
Dijkstra probably hates me (Linus Torvalds, in kernel/sched.c)


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Security problem - inetd.conf has rsh/rlogin/rexec "ON" as a default

[Amos Shapira]

Hello,

The rsh/rlogin/ident/rexec services are active by default in the
inetd.conf file.  Even though I keep removing them (I delete their
lines altogether since that way it's much easier to notice a change)
they seem to keep popping up after updating any software related to
this file.

I'd like to suggest that these services will be "off" by default and
the user should be given a chance to stop the system before it
reactivates them.

I'm not on the list (finals period) so please CC to me any response to
this message.

Thanks,

--Amos

--Amos Shapira| "Of course Australia was marked for
133 Shlomo Ben-Yosef st.  |  glory, for its people had been chosen
Jerusalem 93 805  |  by the finest judges in England."
ISRAEL   [EMAIL PROTECTED]  | -- Anonymous


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Boot Dependancies - a weird wacky wonderful new idea

[Avery Pennarun]

On Wed, Jun 10, 1998 at 07:57:18PM -0700, Robert Woodcock wrote:

> Parallelized booting. What this means is we run multiple bootup scripts
> simultaneously. It's a *lot* faster on mid-to-higher-end machines, even
> with just one CPU - it'd be wickedly fast with SMP.
> 
> "Hey wait a second that won't work!!! What if the netstd_nfs script runs
> before the netbase script is done processing?"
> 
> Well, you're right, but I have another (slightly more original) idea that
> will make it work. Boot-time dependancies.

Parallelized booting is a good idea (I'm almost certain that _most_ of my
bootup time, and almost ALL of my shutdown time, is spent waiting for tasks
to decide they're ready) but boot-time dependencies are way too much work.

What's wrong with priority levels?  Programs start up in alphabetical order. 
I wish they would die in reverse-alphabetical order (then we could have
S99xdm and K99kdm, which would make the file-rc package look nicer) but
priority levels do exactly what you want -- they express boot-time
dependencies.

We can achieve a huge degree of parallelism simply by running all boot
scripts of each priority level in parallel.  That is, run all scripts at
level 01 (and wait to finish), then run all scripts at level 02, and so on. 
To see why this should be "parallel enough," look at the large number of
scripts running at the default level 20.

Also, the only guarantee we've ever made is that scripts are executed in
priority order, so running all scripts at level 20 simultaneously shouldn't
cause a problem.

The hardest thing would be keeping the log messages from getting tangled up. 
That shouldn't really be too hard for a C/C++ program to do.  I've done
something almost appropriate in my wvdial package (see class WvLog and
WvLogRcv).

If enough people dare me, I bet I could whip something like this up (using
the existing priority scheme) in an hour or two.

Have fun,

Avery

P.S. why isn't file-rc the standard?  It's _so_ much better!  And why can't
we kill things in reverse alphabetical order?


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: packaging kernel modules

[Gregory S. Stark]

Hamish Moffatt <[EMAIL PROTECTED]> writes:

> On Wed, Jun 10, 1998 at 10:41:41AM +0200, Yann Dirson wrote:
>
> > I think the various modules should be primarily packaged in source
> > form, just as the kernel is, and installed under /usr/src/modules/.
> 
> This sounds excellent. On one machine I am running 2.0.33
> and have the appropriate ntfs package installed, but it will not insert
> (many missing symbols), presumably because it is my own compilation
> of 2.0.33. Similarly I just upgraded another box to 2.0.34 and have
> installed ftape-3.04d from sources. It is presently much easier to work
> with sources to such kernel addons, imho.

I disagree. You're about to follow the same path that was followed for
kernel-source which has various awkward problems. Forcing .deb files into
handling source packages is a bad idea. Instead we should add an option to
dselect/apt to download and unpack the real source package in /usr/src.

If we compiled the standard kernel with CONFIG_MODVERSIONS then we can safely
install modules in /lib/modules or /lib/modules/2.0 instead of for a specific
version. This doesn't really handle conflicts between different incompatible
versions of a 2.0 kernel, but for modules like alsa would probably work fine.
Otherwise the user can download the source package and recompile.

greg




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

glibc and crypt

[Chris]

Hi all,

I took the bite the other day and moved my main systems over to glibc and
I am re-compiling some of my legacy programs.  The problem I've come up
against is some code that uses the crypt function from unistd.h.  It
complies fine on any bo boxes, but not on the hamm one.  Any ideas?  I'm
after a simple way to get it working without rewriting too much code :)

The call is like this:

blah = (char *) crypt (pass,pw_salt);


Thanks for any help,


Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#22942: Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)

[Gregory S. Stark]

Marco Pistore <[EMAIL PROTECTED]> writes:
> 
> Now, in hamm the binaries are only in libpaperg, since they are linked
> against libc6 libraries; package libpaper in hamm contains only the
> libraries. 

So, the original cause of the problem is that the binaries were in the library
package. The policy specifically prohibits that precisely because of these
problems. And you're proposing the libc6 versions keep doing the same thing
that caused the problem in the first place.

What I would suggest would be:

libpaper:   libc5 libraries only 
libpaperg:  libc6 libraries only 
libpaper-utils: both binaries, depends on libpaper|libpaperg
with wrapper scripts to choose the right ones somehow

This will at least avoid the problem in the future, as another version of the
library can be installed simultaneously without conflicting with the existing
libraries.

greg



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Steve Dunham]

Jason Gunthorpe <[EMAIL PROTECTED]> writes:

> On Thu, 11 Jun 1998, Hamish Moffatt wrote:
> 
> > > Tried booting from a floppy created with dd?
> > 
> > Same problem, if memory serves correctly. Will check it out asap.

> Upon reflection it occures to me that there are two other possibilities

> 1) The bios calls to access high memory make it so that the kernel routine
>to do  (page table setup?) reboots the machine
> 2) It does not get properly copied to the 1 meg location and reboots
>because it executes random memory during decompression.

I'm told problem is related to turning on the "A12 Gate" and the
cache.  It was never explained to me in detail, but it has something
to do with the cache having the wrong contents (or rather the wrong
tags on the contents) after the A12 line was set.  It was never clear
to me why they couldn't just clear the cache after turning on the A12
gate.  You could ask on the kernel list.

LILO, ldlinux.sys, and the built in boot block (dd) exibit the
problem.  Grub can boot them just fine.


Steve
[EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: glibc and crypt

[Maarten Boekhold]

On Thu, 11 Jun 1998, Chris wrote:

> 
> Hi all,
> 
> I took the bite the other day and moved my main systems over to glibc and
> I am re-compiling some of my legacy programs.  The problem I've come up
> against is some code that uses the crypt function from unistd.h.  It
> complies fine on any bo boxes, but not on the hamm one.  Any ideas?  I'm
> after a simple way to get it working without rewriting too much code :)
> 
> The call is like this:
> 
> blah = (char *) crypt (pass,pw_salt);

Link with -lcrypt.

Maarten

_
| TU Delft, The Netherlands, Faculty of Information Technology and Systems  |
|   Department of Electrical Engineering|
|   Computer Architecture and Digital Technique section |
|  [EMAIL PROTECTED] |
-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Volunteer(s) wanted to help with owner@bugs.debian.org

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: Also its been suggested that the BTS not delete bugs, but store them
: in some kind of long-term archive.   Full-text searching couldn't hurt
: either.  :-)

The approach we used at work is that bug closure causes the file to get moved
to a different directory... so, in effect, there's a database of open bugs
and a database of closed bugs.  Maybe not optimal, but simple to implement.

The biggest feature-creeps are that we take serious advantage of Apache's 
server-side include features, which cuts down drastically on the amount of
file-whacking in the database... and we don't batch processing, we do each
request as it arrives.  The combination allow us to have near-instant
gratification on bug status changes showing up on the web pages, without
driving the resource requirements on the server way up. 

Bdale


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: packaging kernel modules

[Hamish Moffatt]

On Thu, Jun 11, 1998 at 01:49:36AM -0400, Gregory S. Stark wrote:
> Hamish Moffatt <[EMAIL PROTECTED]> writes:
> > This sounds excellent. On one machine I am running 2.0.33
> > and have the appropriate ntfs package installed, but it will not insert
> > (many missing symbols), presumably because it is my own compilation
> > of 2.0.33. Similarly I just upgraded another box to 2.0.34 and have
> > installed ftape-3.04d from sources. It is presently much easier to work
> > with sources to such kernel addons, imho.
> 
> I disagree. You're about to follow the same path that was followed for
> kernel-source which has various awkward problems. Forcing .deb files into
> handling source packages is a bad idea. Instead we should add an option to
> dselect/apt to download and unpack the real source package in /usr/src.

Well, I don't really mind the details. I just want modules installed
in source form.

> If we compiled the standard kernel with CONFIG_MODVERSIONS then we can safely
> install modules in /lib/modules or /lib/modules/2.0 instead of for a specific
> version. This doesn't really handle conflicts between different incompatible
> versions of a 2.0 kernel, but for modules like alsa would probably work fine.
> Otherwise the user can download the source package and recompile.

Well, this sounds find, but I've never observed this to actually work.

[5:30pm] [EMAIL PROTECTED]:~# dpkg -s ntfs2.0.33
Package: ntfs2.0.33
Status: install ok installed

[5:30pm] [EMAIL PROTECTED]:~# modprobe ntfs
/lib/modules/2.0/fs/ntfs.o: unresolved symbol generic_file_mmap_R57ec6036
/lib/modules/2.0/fs/ntfs.o: unresolved symbol __wait_on_buffer_Rc98cf5d5
/lib/modules/2.0/fs/ntfs.o: unresolved symbol bread_Rb6301add
/lib/modules/2.0/fs/ntfs.o: unresolved symbol dcache_add_Rd60169b3
/lib/modules/2.0/fs/ntfs.o: unresolved symbol __iget_R917242df
/lib/modules/2.0/fs/ntfs.o: unresolved symbol unregister_filesystem_R76cc4714
/lib/modules/2.0/fs/ntfs.o: unresolved symbol __brelse_Rab34997d
/lib/modules/2.0/fs/ntfs.o: unresolved symbol wake_up_R2cd4af7c
/lib/modules/2.0/fs/ntfs.o: unresolved symbol refile_buffer_R52427ee9
/lib/modules/2.0/fs/ntfs.o: unresolved symbol register_filesystem_Rf8be2e1e
/lib/modules/2.0/fs/ntfs.o: unresolved symbol clear_inode_R352fa1d9
/lib/modules/2.0/fs/ntfs.o: unresolved symbol unlock_buffer_R2f24038f
/lib/modules/2.0/fs/ntfs.o: unresolved symbol set_writetime_Rd60ca02b
/lib/modules/2.0/fs/ntfs.o: unresolved symbol dcache_lookup_Ra14549bd
/lib/modules/2.0/fs/ntfs.o: unresolved symbol iput_R3bd220be
/lib/modules/2.0/fs/ntfs.o: unresolved symbol __wait_on_super_R650e2a59

I am using a custom kernel, with modversions enabled.

Hamish
-- 
Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: monitoring maintainers' vacations

[Philip Hands]

People could always put something in their .plan on master, so you could just 
finger them.

Cheers, Phil.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Volunteer(s) wanted to help with owner@bugs.debian.org

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Thu, 11 Jun 1998, Bdale Garbee wrote:

> [...] and we don't batch processing, we do each request as it arrives.

Yes! Please! [ Bug #14650: The bug system is a little bit slow ]

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNX+ooyqK7IlOjMLFAQFtHgP9FnnfwXD9WWEZs5ru/PEmaiqUEFXxpLlh
l++awXYL4O+QEKzoGOQIlf4mBO5p3AQ5hyZh/v+dmxAsJr+eJtE7MSmWvZa1kMmt
pQrDbFRc5N0sMAJ3ISrrGdE2fDwVLd42GFVqQBiWe/EUjRQFhra566wpo8kTEzDm
s0FLF6TFsIg=
=vaWc
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Boot Dependancies - a weird wacky wonderful new idea

[Philip Hands]

> Parallelized booting. What this means is we run multiple bootup scripts
> simultaneously. It's a *lot* faster on mid-to-higher-end machines, even
> with just one CPU - it'd be wickedly fast with SMP.

I like it.

This sounds like a job for make (which can run things in parallel)

It shouldn't be too much trouble to come up with a few make rules that (on an 
unmodified system) run all the rc scripts, one at a time, in the same order, 
as they would be run now (for backward compatibility).

Then, as you make scripts parallel-isable, you do something[1] so that make can 
pick up on the real dependencies (rather that the over-cautious default it 
would have used), and your done.

This way, new scripts on an old system work as normal.

Old scripts with a new paraliasble make based /etc/init.d/rc script work fine
too.

You can use make's load/job limiting options to tune the best number of things 
to run at once.

The only problem I see with this is making it survive things like file 
corruption in the Makefiles, but I guess corrupted init scripts are fairly bad 
news as it is, so that's not making thinks much worse.

Cheers, Phil.

[1] like make /etc/init.d/deps/[KS]packagename be makefile fragments that
get included into the master makefile.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: tools/ on ftp.debian.org

[Michael Dietrich]

> b) are there tools for m68k or alpha ?
linload, milo


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Philip Hands]

> I'm told problem is related to turning on the "A12 Gate" and the
> cache.  It was never explained to me in detail, but it has something
> to do with the cache having the wrong contents (or rather the wrong
> tags on the contents) after the A12 line was set.  It was never clear
> to me why they couldn't just clear the cache after turning on the A12
> gate.  You could ask on the kernel list.

That's what the kernel on the tecra disks does AFAIK, using a patch from:

  http://www.cck.uni-kl.de/misc/tecra710/

Unfotunately, this makes some other machines fail to boot (don't ask me why, 
that patch always seemed totally harmless to me).

Cheers, Phil.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: tools/ on ftp.debian.org

[Michael Dietrich]

On Wed, Jun 10, 1998 at 01:36:58PM +0200, Anselm Lingnau wrote:
> > unz512x3.exe is a self-unarching zip, and can be unpacked with Linux unzip
> > 
> > gzip124.exe is a self-unarching lharc file and can be unpacked with
> > Linux lha
> 
> It might be a good idea to add a note in the README to that effect.
> 
i don't like those archives: you don know about a virus in it and you
need 2 steps to get on that what you need (in fact you need a
writeable storage with enough space - not easy with a floppy boot
system and a cdrom). so: please extract those tools for dos!


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

prelim deb of emusic

[Brian Almeida]

While I'm awaiting the phone call to receive maintainer status (possibly 
tonight), I have put up a preliminary .deb of my package(eMusic).  It can be 
found at:
http://web.terminus.cicat.com/software/emusic_0.5-1_i386.deb
Any suggestions welcome. :)

Brian

-- 
Brian Almeida <[EMAIL PROTECTED]>
http://web.terminus.cicat.com
PGP Key: pub  1024/3A800C65 1998/04/20 Brian M. Almeida <[EMAIL PROTECTED]>


pgp6ScAmi0Foq.pgp
Description: PGP signature

Re: mkdosfs

[Michael Dietrich]

> > > who maintains the mkdosfs package 
> > There's no separate mkdosfs package anymore; it has been merged into
> > 'dosfstools' which is maintained by [EMAIL PROTECTED] .
> And which I'm fairly certain I ported, since I used it to create the boot
> partition on my alpha...
> 
same to me. but why didn you give it back? didn't you violate GPL then
;-)


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Base Set: Suggested additions & removals.

[Michael Dietrich]

> > >   Alright, the more I think about this, the more I think that James
> > >   is probably right. (NO flames, people can change there minds can't
> > >   they?) Mc doesn't belong in the base set.
> > i agree to this. neither does vi or emacs belong there, even if emacs
> > whould be an 30KB sized editor. 
> > > However I do think more attention should be paid to the user. (not
> > > alot more just some.)
> > THIS is the correct aproach. in the base system an editor is needed,
> > that everybody can use, not only those vi-nerds (like me). even emacs
> > is to difficult to use. i hate to say that, but i'd like to see an
> > editor like the dos-editor 'edit'. this editor can be used instantly
> > by nearly every computer user with a little expirience. and that's
> > what's needed.
> 
> I've a freind who wrote a editor like dos edit. However it has some rather
> nasty bugs Anyone here use Tico? ... I don't think we have a package
> for it, I don't even know what licence it's under, It was just sugested to
> me.
if there is a chance of getting the bugs out of it and it is GPLed i
would be interested to work on it.
> > > so here is what I propose: Lets rewrite the keybindings for Ae, to
> > > something that is much simpler. something akin to the keybindings on
> > > pico[1]. We can then set this alternative keybinding to be the
> > > default, and also include a vi and or standard keybindings, set.
> > > this should make everyone happy. IMHO. I'm working on the new
> > > keybindings right now... hopefully I'll have them done tonight, and
> > > in my home dir on master (ewigin). If anyone wants to help, Letme
> > > know.
> > i don't think, you can make a easy to use editor out of ae. somebody
> > threw 'le' in. what's that?
> 
> I don't know either, anymore... I'm kinda lost in the ae.rc file... very
> confusing...


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ircII is now free.

[Martin Schulze]

On Tue, Jun 09, 1998 at 07:46:47PM -0700, David Welton wrote:

> /*
>  * Copyright (c) 1990-1998 Michael Sandrof, Troy Rollo, Matthew R. Green
>  * All rights reserved.

I won't include the whole Licence but a pointer in a press release.

Regards,

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 / The good thing about standards is /
/ that there are so many to choose from. -- Andrew S. Tanenbaum /


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Michael Dietrich]

> > path without saying what that set path should be. So, why do the
> > vi users like _using_ vi? (Someone already said "it's standard"...
> > can I get real reasons now? :)
i'm faster with vi. that's all.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: tools/ on ftp.debian.org

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Thu, 11 Jun 1998, Michael Dietrich wrote:

> On Wed, Jun 10, 1998 at 01:36:58PM +0200, Anselm Lingnau wrote:
> > > unz512x3.exe is a self-unarching zip, and can be unpacked with Linux unzip
> > > 
> > > gzip124.exe is a self-unarching lharc file and can be unpacked with
> > > Linux lha
> > 
> > It might be a good idea to add a note in the README to that effect.
>
> i don't like those archives: you don know about a virus in it

If they are byte-by-byte identical to the ones info-zip and the 
FSF distributes, there is no reason to think they contain a virus.

It would be a good idea, however, to replace unz512x3.exe by a more
current version like unz532x3.exe.

> and you need 2 steps to get on that what you need (in fact you need a
> writeable storage with enough space - not easy with a floppy boot
> system and a cdrom).

As far as I know, unzip is there for people who want to use fips or
loadlin in their DOS systems, i.e. for people who a) has already DOS
installed and b) do not want to remove it from the hard disk.

Therefore it is *very* unlikely that you don't have "a writeable storage
with enough space".

> so: please extract those tools for dos!

I disagree. If we can put those files untouched, as distributed by the
authors, we should put them untouched.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNX/FHyqK7IlOjMLFAQE53gP8D7L275YmZvCnTHRaAHRWjfXoXtXNUdh2
MVGTBJY3D1emGOM8YXx7dSIRmY81Ogfgoxvk6T+Wq4xoWpQ1/FI0GLX6sxstpKUb
rYaKFxVECX8URuiZnqDZSmHui503n7wPeUfOr9Oz+1DLuGW+RRAqZpCXz9u95ZXe
N2RVz4aNGW4=
=Tmpu
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Official CDROM

[fog]

On Wed, Jun 10, 1998 at 03:19:00PM +0200, [EMAIL PROTECTED] wrote: 
> 
> On Wed, 10 Jun 1998, Andreas Jellinghaus wrote:
> 
> > a) 5 cd set : source, misc, and 3 binary cds. 
> > misc + binary will be enought for every architecture, so
> > distributors can sell cd sets of 2 cds (or 3 with source).
> > b) 4 cd set : highly integrated. 
> > it will not be possible to split the m68k or alpha part of,
> > but this will save us one cdrom.
> 
> I tend to favor the "highly integrated multi cd" solution. Reasons:

I tend to prefer the 5 cd set exaclty for reasons you gave here :)

> - Most of the overhead for cd vendors goes into things like order
>   registration, postage and packing.  The cost of a couple of silver discs
>   is quite negligable.  You can put up to 6 cd's in a single jewelbox.

So why don't put 5 disk that are better organized? After all 5 is
only 4 + 1.
 
> - The amount of debian-{alpha,mk68,sparc,mips,arm,what-next}-only cd sets
>   that vendors expect to ship will probably not be high at this moment.
>   This might cause them to not ship the other architectures or put a much
>   higher price tag on those cd sets.  Even if the alternative sets are
>   made by the ftp.cdrom.coms, Infomagics and whoever else forwards
>   their stuff into the retail channels, the cd sets still have to make it
>   to the individual "main street" pc- and bookshop's shelfs. 

With the 5 cd set they can choose. And smaller redistributors that simply
burn gold cds (as I do in italy, just 20 to 40 cds) can choose to exclude 
a couple of them the from the distribution.

> - Clearly showing support for many architectures is good Debian exposure.

And having 1 cd for every arch is much better (someone can think that
other archs are not well done if you mix things on multiple cd).

> - If I had a cd with Debian on it for an architecture that I don't
>   have at home, but of which I knew that there is such a machine at work
>   or school or whereever I can get to it, I will attempt to convince the
>   owner/administrator to try Debian.

True. I will buy the 5cd set.

> 
> 
> Instead of the two-cd's-without-source, I'd rather see a special
> lightweight _single_ Debian cd for i386 that carries:
> 
> - Ten different alternative kernels to boot off, suiting various hardware
>   needs.  This would be a big improvement over the current situation,
>   where people complain that RedHat/Slackware's floppy does boot and
>   Debian's does not.
> 
> - Only small parts of the main distribution and full source of the
>   included binaries.  The devel stuff needed to rebuild all those sources
>   should be included in the binary part of course.  Kernel source should
>   also be included.
> 
> - A decent on-line documentation tree that can be read with a webbrowser
>   on a Windoze computer before actually attempting to install Debian. 
> 
> - A tiny live-filesystem on the cd, think of no more than 50 to 100 
>   megabytes.
> 
>   - Has to be just enough to have a "skinny standard" linux running, to
> show your friends (or yourself) that it runs on your pc before going
> ahead and take repartitioning any harddisks.  
> A small step before the big leap.
> 
>   - Uses ramdisks to mount / and eg. /home on or alternatively: 
> * Can use parts of a dos filesystem to put umsdos filesystems on.  
>   A dos filesystem can also hold a swapfile.   
> * Can also be installed entirely to a umsdos filesystem on your 
>   dos filesystem. 
> The latter options would make it possible to try it a couple of times,
> keeping basic network setup and other required configuration like
> modules and passwords stored.   
> 
>   - Provides an excellent base system for installation! It has mc, emacs,
> vi, ae, gcc, lynx, useful network clients and, depending on the size
> that's available, a small webserver. Everybody can find his/her
> favorite "essentials" on it. 
> 
>   - Is also the ultimate rescue disk.
> 
> A cd like this, with approximately 250 meg binaries, 250 meg sources, 40
> meg documentation, 10 meg kernels and a 100 meg live filesystem would
> make an excellent "cover cd" for computer magazines.
> 
> Any takers?  I'd love to work with some people on a little project to have
> this working for 2.1.

Mmmhh. I am woking on that. What I dream is a bootable/livefs cdrom
that lets you play a little bit with linux and then guides you
through the installation process from the hd (re)partinioning to
the X11 configuration. 

Anyone knows about a FAT32 defrag program that runs under linux? 
Anyone ever tried to compile FIPS under linux? Ideas? 

--***
* Federico DI Gregorio ** GCS/S/>L d- s:>:+ a26 C++ UL++ P+++ L*+++>$ D *
*   <[EMAIL PROTECTED]>   ** W+>++ N+ o? !K w--->!$ O M- V-- PS+(+++) PE(--) 
*   Debian Developer   ** Y+(-)(+)(-)... PGP+ s+ 5- X+++ R*<+(+++) b+++ *
*  ** DI++ D G- e+++> h--- r

Re: RFC: monitoring maintainers' vacations

[Yann Dirson]

Philip Hands writes:
 > People could always put something in their .plan on master, so you could 
 > just 
 > finger them.

Problems with this is that it is yet another informal method, and it's
hardly automatizable - you'll have to finger manually... that does not
help much IMHO.

Wichert Akkerman writes:
 > Personally, I always install vacation when I'm away for an extended
 > period of time. Couldn't maintainers just install vacation on the
 > account on master? This way when someone mails them a reply
 > is automatically made stating the maintainer is away. More processing
 > could easily be added..
 > 
 > Of course, this only works for maintainers which use there debian.org-address
 > as their maintainer address, but I expect that people use other addresses
 > can install vacation locally.

Well, not all ISPs allow that...

Further more, that would only address the "warn sender" issue.  It
will still miss the "call for NMR" on deb-dev - not all submitters
will think about, or even want, to send additionnal mails, once they
have reported...

Further more, vacation seem to only reply when the user is in the
"To:" or "CC:" fields, ie. when he's in the *original* recipients,
which is usually not the case for a bug report, addressed to
"{submit,[EMAIL PROTECTED]"

Or do I miss something ?
-- 
Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
isp-email:   <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email:   <[EMAIL PROTECTED]> | more powerful, more stable !
http://www.mygale.org/~ydirson/ | Check 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Volunteer(s) wanted to help with owner@bugs.debian.org

[Yann Dirson]

Bdale Garbee writes:
 > My personal wish-list for the bug system is pretty short.  I would really 
 > like
 > it if the process of closing a bug recorded the version of the package that
 > supposedly fixed the bug.

That may not be so simple:  think of package dummy_1.2-3 in hamm, and
dummy_2.3-4 in slink only because of the freeze.  One bug is
discovered which affects both, and gets fixed in 1.2-4 and 2.3-5.
What will you record as fixing-version ?  1.2-4 is definitely wrong as
2.3-4 is buggy; 2.3-5 is highly suboptimal, and makes the info useless
:(

This reminds me of a recent suggestion of mine ("An idea for the BTS
(Was: Weeding out slink bug reports)", 
archive/latest/6227) to really add support for distributions in the
BTS.  Nobody seems interested in talking about that, though...

-- 
Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
isp-email:   <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email:   <[EMAIL PROTECTED]> | more powerful, more stable !
http://www.mygale.org/~ydirson/ | Check 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: packaging kernel modules

[Yann Dirson]

Jason Gunthorpe writes:
 > Hm, we should really talk to the kernel people.. but here is my thoughts,
 >   #1 - If person X compiles a module for kernel x.x.x and it doesn't work
 >on your compile of x.x.x then you need to recompile your kernel.
 >[General rule, most modules don't try to deduce what symbols are
 > available]

Er, why ?  Does this mean I cannot choose the exact kernel config I
will use, and what patches I apply ?

 > In the case of alsa I think it should compile for 2.0 and go into the 2.0/
 > modules directory that appears to be on my machine.

Hm, I quite skeptic.  We'll have to have eg. a try at loading the
2.0.33-compiled ones in a 2.0.34 kernel...

-- 
Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
isp-email:   <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email:   <[EMAIL PROTECTED]> | more powerful, more stable !
http://www.mygale.org/~ydirson/ | Check 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: packaging kernel modules

[Yann Dirson]

Wichert Akkerman writes:
 > Previously Yann Dirson wrote:
 > > It does not seem that we have currently any conventions regarding the
 > > packaging of kernel modules.  I just tried the new alsadriver from
 > > slink, and, for the same reason I could not use the packaged joystick
 > > driver, this one too is useless to me.
 > 
 > Can you try recompiling the source package and use that? And what
 > kernel version are you using? (own compile, kernel version, etc.)

I use my own compile of (upstream) 2.0.33, on an i486, which, guess
what, has no PCI bus - so I did not compile with PCI support.  The
problem is that "insmod snd" reports that it looks for some pci_*
symbols.  But I didn't try to compile alsa myself, so it may be that
alsa requires PCI support - I remember kgi snapshots pre-0.0.9
required PCI too.

 > > 2) These packages only provide compiled modules for some special
 > > kernel version.  Eg, alsa install its modules for 2.0.33; joystick
 > > used to do it for 1 version I don't remember, and after a bug report,
 > > finally included the driver for 2 kernel versions, which even did not
 > > solve my problem, for the above-mentionned reason.
 > 
 > This is always a horny problem, which is inherrent to changing kernel
 > interface. I've compiled the ALSA-packages on my own 2.0.33 kernel (somewhat
 > patched), but it should work on other 2.0.33 kernels AFAIK.

Not only.  As I understand it, the kernel defines some symbol names
that include a checksum on something (functions ?  see
/include/linux/modules/*.ver).  If the involved part of
the kernel has changed, the modules that were compiled against the old
version won't link against the new one.  At least that's what I
understood last time I checked.

This seems to mean that when you use a kernel that is compiled with
different patches, you can expect that some precompiled modules won't
link correctly - just try this between 2 sufficiently different kernel
versions (you'll need to "insmod -f" because a the version-string
change), like 2.0.33 and .34, and see how many modules of one you can
cause the other one to accept...

 > > kernel-package, which seem to be the tool to build a kernel the Right
 > > Way on a Debian system, provides a framework to also build the
 > > relevant modules from /usr/src/modules/, which can IMHO be used to
 > > solve these problems.
 > 
 > I have no idea how flexibable kernel-package is with respect to other
 > modules, or how the interface works. If there is a general interface I
 > would be happy to incorporate it in the alsa-packages. 

IIRC, put your modules into /usr/src/modules/, cd to the kernel tree
you want to compile modules for, and ask eg. "make-kpkg modules_image"

 > > I think the various modules should be primarily packaged in source
 > > form, just as the kernel is, and installed under /usr/src/modules/.
 > 
 > And packaged compiled for the standard kernel-image packages, so we
 > can use them on the bootdisks if wanted.

Er, yes, did I really forget to write that ? ;)

-- 
Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
isp-email:   <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email:   <[EMAIL PROTECTED]> | more powerful, more stable !
http://www.mygale.org/~ydirson/ | Check 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Michael Dietrich]

> If vi would fit on the rescue disk, do you think we would be discussing
> ae?
i think it's not a good idea to put vi there. this editor can be used
by a profi only and a prof can use any other editor too. a beginner
won't be able to use vi but the easy to use small editor. maybe ae is
bad, but it easier to use then vi and small. i wouldn discuss vi or
ae, i would like to look for a really easy to use editor.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian bugs: collecting information

[Branden Robinson]

Sorry about the belated reply.

For those who do not know, the URL for the X Strike Force (XSF) page is
.

I do my work on master.debian.org in /debian2/tmp/branden/; anyone with an
account on master is welcome to peruse the files there.

On Thu, Jun 04, 1998 at 08:57:18PM +0200, Richard Braakman wrote:
> Package: xbase
> Maintainer: Branden Robinson <[EMAIL PROTECTED]>
>   22329  Patch for #20685 prevents talk working
>   22422  xbase: xterm and rxvt sessions no longer logged

[HELP] The above two bugs are merged.  Please see the XSF page for more
information.

>   22668  TERM=xterm meaning has changed incompatibly

[STRATEGY] Coordinate with ncurses-base maintainer to use XFree86's xterm
entry for xterm, put our modified version into a new terminal type called
xterm-debian, and change XTerm's app-defaults file to use xterm-debian by
default.  See the XSF page for more information.

>   22877  xbase: xdm port, and X applications
>   22878  xbase: xdm port, and X applications

[HELP] The above two bugs are merged.  These have been forwarded upstream
but I haven't heard anything from XFree86 about them to date.  Fixing them
is beyond my knowledge.

>   22928  New upstream security fix release

[FIX] The patches have been applied (and they applied cleanly, except for
ones that we had already done ourselves and had forwarded to them), but a
build has not been done.

>   23002  Problem With Fresh Install

[HELP] I need some advice on this one.  This person is complaining that the
xbase-configure script (which is called by xbase's postinst) calls
xf86config instead of XF86Setup when XF86Setup cannot be used because the
font packages are in an unconfigured state.  Our xfnt packages no longer
ship the fonts.dir files, since they are created in the xfnt postinst's
anyway, and this provided me an easy check to see if it was worth calling
XF86Setup or not.

Essentially, this person is complaining that the postinst for some xfnt
packages isn't run before xbase's postinst.  However, it is not reasonable
to make xbase depend on any xfnt package.

To make things worse, XF86Setup isn't even *in* xbase, it's in
xserver-vga16, because it requires the VGA16 X server to run.

This is a poor design. xbase-configure would be more properly called
xserver-configure, and in slink when I jigsaw the upstream sources
differen tly there's going to be an xserver-common package where
xserver-configure, XF86Setup, et al. will go.  It would not prudent to
engineer such a radical change at this point.  What should I do in the
meantime?

> Package: xlib6g
> Maintainer: Branden Robinson <[EMAIL PROTECTED]>
>   23122  typo in debian/rules

[FIX] Already applied to the source tree, but no package has been built
yet.

Finally, #23274 has been reported against xlib6g since Richard sent his
mail.  It is release-critical, however I think I have already [FIXED]
it.  I'll find out when I do another build.

-- 
G. Branden Robinson |I've made up my mind.  Don't try to
Purdue University   |confuse me with the facts.
[EMAIL PROTECTED]  |-- Indiana Senator Earl Landgrebe
http://www.ecn.purdue.edu/~branden/ |


pgpho3IcHB1XR.pgp
Description: PGP signature

Re: Volunteer(s) wanted to help with owner@bugs.debian.org

[Andreas Jellinghaus]

In article <[EMAIL PROTECTED]> you write:
>Ian Jackson <[EMAIL PROTECTED]> wrote:
>> 3. Obviously additional development of the bug system would be good.
>> This can be done either by the person doing 2., or independently.
>> In any case the patches generated need to be sent upstream to me.
>
>I'm interested in taking a look at this. I don't want to promise
>anything until I'm reasonably certain I understand how you've laid out
>the code [I'm still stumped by dpkg, to the point where I'm not even
>sure how to form reasonable questions, but I think I know a fair bit
>about the mechanisms I'd expect in the bug system].
>
>Where should I start?

i don't think i can do much, but i'm willing to look at changes,
give comments, test etc. 
i'm diging in the bug system, as i try to install it on bugs.kde.org ...
(maybe it was not wise to ask "will i ever get an answer of my bug report ?").

andreas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: so what? Re: Debian development modem

[Andreas Jellinghaus]

ok for me.

> So, in detail:

> Every three months (fixed date) we copy the current `unstable' into
> `frozen'.  At this point `stable', `frozen' and `unstable' should all
> stay interoperable both in source and binary form.

alternative :
seperate place for new uploads and unstable, but well known packages.
package developers do uploads. they always go to the place for new packages.
"quality keepers" can promote a package from "the new place" to
"unstable". a sample guideline could be : this package has been in use for 10
days, and nobody complained about it, and there was no new upload of the
package.
this "unstable" will be frozen every 3 months.

also an old version shouldn't be thrown away automaticaly.

the additional step might save us some problems with "new xx is in, but new
libxx isn't", or "people found out that it's broken, but there was no new
upload since that".

the current testing scheme is :
a) one developer (or two or three) test a package
b) then all 300 developers test the package, because it's in unstable.

it would realy realy nice to have some group in the middle with ca. 30 people
or so.

too much time is spend by debian developers, because they need to be relative
up to date, but they get some broken packages and fail because of that.

> Bugfixes must be applied to frozen, and important ones to stable too.
> After one or two months of beta frozen should be stable enough to
> release.

not directly to stable. IMO the hamm/ archive and the cdroms should never
be changed after release. instead we should have an errate directory,
with a detailed explenation for every updated package (available as text and
html, so sgml could be used). 

> We also need to make automatic building a real possibility.

till end of juli i'm busy but then i can work on this. maybe earlier,
but don't count on that.

andreas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bootint big kernels was Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Dale Scheetz]

On Thu, 11 Jun 1998, Hamish Moffatt wrote:

> On Wed, Jun 10, 1998 at 09:17:20PM -0600, Jason Gunthorpe wrote:
> > When you boot the kernel it copies the Image from the disk to 0x1000
> > (about 64k). If the Image is beyond 600k then you have a problem because
> > it suddenly will not all fit in low memory.
> > 
> > A bzImage is more sinister. After it loads a few block in it makes some
> > bios calls to copy the blocks up to 1 meg where the 3rd stage boot loader
> > will run. After that it uncompresses the kernel to some location then 
> > copies it to it's proper placement at 1M. a zImage simply uncompresses the
> > kernel to 1M.
> > 
> > In theory, on a notebook the int calls are glitchy and crash the system.
> > 
> > If your kernel is > 600k you MUST use a bzImage and you MUST load it into
> 
> So is there any other advantage? 600k is pretty big for a default
> kernel, especially since we are making heavy use of modules. My custom 2.0.34
> is 300k odd, although obviously the Debian one needs a bunch of SCSI drivers.
> If we are < 600k, why use it when it is problematic?
> 
The problem is that the Debian installation kernel tries to be all things
to all people. As there are machines that boot from SCSI drives, it was
necessary to have all the scsi controlers "built in" to the kernel, hense
its large size.

We should recommend that everyone, once they have a standard system and
can build a kernel, should build a custom kernel for their machine as
early as possible.

Another solution is the one that slackware provides. They build a "bunch"
of kernels, each one for a specific hardware configuration (broad enought
to cover a range of hardware, and chosen to keep incopatibly drivers out
of the picture {like the wd9000 driver that plonks ethernet cards})

Waiting is,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Security problem - inetd.conf has rsh/rlogin/rexec "ON" as a default

[Scott Ellis]

On Thu, 11 Jun 1998, Amos Shapira wrote:

> The rsh/rlogin/ident/rexec services are active by default in the
> inetd.conf file.  Even though I keep removing them (I delete their
> lines altogether since that way it's much easier to notice a change)
> they seem to keep popping up after updating any software related to
> this file.

If you comment them out with a single "#", they won't be re-enabled by
updated packages.

> I'd like to suggest that these services will be "off" by default and
> the user should be given a chance to stop the system before it
> reactivates them.

Many people do administration remotely.  They would probably be very
disapointed to have their login services yanked out from under them.
They're easy enough to disable and only truely a security hole if you have
.rhosts or hosts.equivs files laying around.  Even then, tcpwrappers makes
them significantly harder to spoof than on a traditional UNIX environment.

> I'm not on the list (finals period) so please CC to me any response to
> this message.

CC sent.

-- 
Scott K. Ellis <[EMAIL PROTECTED]> http://www.gate.net/~storm/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Base Set: Suggested additions & removals.

[Dale Scheetz]

On Thu, 11 Jun 1998, Michael Dietrich wrote:

> > > > Alright, the more I think about this, the more I think that 
> > > > James
> > > > is probably right. (NO flames, people can change there minds 
> > > > can't
> > > > they?) Mc doesn't belong in the base set.
> > > i agree to this. neither does vi or emacs belong there, even if emacs
> > > whould be an 30KB sized editor. 
> > > > However I do think more attention should be paid to the user. (not
> > > > alot more just some.)
> > > THIS is the correct aproach. in the base system an editor is needed,
> > > that everybody can use, not only those vi-nerds (like me). even emacs
> > > is to difficult to use. i hate to say that, but i'd like to see an
> > > editor like the dos-editor 'edit'. this editor can be used instantly
> > > by nearly every computer user with a little expirience. and that's
> > > what's needed.
> > 
> > I've a freind who wrote a editor like dos edit. However it has some rather
> > nasty bugs Anyone here use Tico? ... I don't think we have a package
> > for it, I don't even know what licence it's under, It was just sugested to
> > me.
> if there is a chance of getting the bugs out of it and it is GPLed i
> would be interested to work on it.
> > > > so here is what I propose: Lets rewrite the keybindings for Ae, to
> > > > something that is much simpler. something akin to the keybindings on
> > > > pico[1]. We can then set this alternative keybinding to be the
> > > > default, and also include a vi and or standard keybindings, set.
> > > > this should make everyone happy. IMHO. I'm working on the new
> > > > keybindings right now... hopefully I'll have them done tonight, and
> > > > in my home dir on master (ewigin). If anyone wants to help, Letme
> > > > know.
> > > i don't think, you can make a easy to use editor out of ae. somebody
> > > threw 'le' in. what's that?
> > 
> > I don't know either, anymore... I'm kinda lost in the ae.rc file... very
> > confusing...
> 
Yes it is.

What is wrong with the current "emacs" keybindings for ae? They work on
any terminal. Before you put a lot of effort into changing the keybindings
on ae, take a look at the current ones and tell me what is wrong with
them. I have several weeks of work in the current solution and it works as
advertized. 

I have never understood why folks have problems with ae (except of course
when the keybindings were broken). The keys that you can press and have an
action take place are all listed on the screen. You can cut and paste,
type and delete. What more could you ask for in a quick and dirty editor?

BTW, for those who just can't deal with ae, sed is the alternative ;-)

Luck,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Release management - technical

[Andreas Jellinghaus]

>   Incoming -> unstable -> unreleased -> stable

100% agree.

some times unstable is so stable, that many people use it. this is bad,
if it's stable, it should have been released.
some times unstable is absolutelyy not useable, and it breaks my system
(grep bug, bash bug, new xxx without new libxxx situations ...).

i also don't like :
a) the package is checked by one or a few persons, before uploaded 
b) the package is checked by 300 people, because it's in unstable.

something in the middle with a small group (30) would be nice.
but how to manage that ? i don't know.

andreas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

mirroring policy

[James A . Treacy]

Philip Hands wrote:
> BTW Any chance of installing the latest rsync on va ?  The anonymous rsync
> stuff works well for me, and it would save the encryption overhead of using
> rsync over ssh.
>
Some background: the latest rsync allows anonymous connections. It also allows 
you to restrict who can connect anonymously.

I've discussed this with Jason and he's against it. He feels that it will be too
much administrative overhead to keep a list of acceptable mirrors. The reason
we would want to set up restrictions is to prevent just anyone from mirroring 
from
the primary Debian sites (va and master. It would be a good idea to minimize the
net load from mirroring so they can be used for other tasks).

Given the large number of mirrors (ftp and www) it would be a good idea if we 
set up
a more formal mirroring policy. My proposal would be to switch to anon rsync on
master which is restricted to 3 primary ftp and web mirrors (2 in the US and 1
in Europe for both ftp and web). All other mirrors would have to use one of
the primary mirrors.

As quite a number of people are currently using rsync to mirror, is it really 
worth
it to make a change? Even if we send messages to -devel beforehand I'm sure a 
number
of mirrors will break for a while. Additionally, links to va and master have 
been
quite stable for the last few months so net load has been less of a problem.
If anything, the primary reason for setting up anon rsync would be so we can get
rid of most of the mirror accounts from master. This is a good idea from both
security and administrative points of view.

Jay Treacy


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bootint big kernels was Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Michael Stone]

Quoting Dale Scheetz ([EMAIL PROTECTED]):
> Another solution is the one that slackware provides. They build a "bunch"
> of kernels, each one for a specific hardware configuration (broad enought
> to cover a range of hardware, and chosen to keep incopatibly drivers out
> of the picture {like the wd9000 driver that plonks ethernet cards})

And one of slackware's biggest flaws is the hoard or new users that
can't figure out which kernel to use.

-- 
Michael Stone, Sysadmin, ITRI PGP: key 1024/76556F95 from mit keyserver,
[EMAIL PROTECTED]finger, or email with "Subject: get pgp key" 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Wichert Akkerman]

Previously Dale Scheetz wrote:
> ae already does this, and provides a reasonably vi ish interface, just to
> satisfy those whose fingers are only programmed for vi.

Personally, I find ae's vi-compatibility even worse then normal ae: it
tricks me into thinking it's vi, but I can never resist using some
vi-magic which confuses ae and gives me horrible results.

On my own installation disks (for local network use only) I'm putting
vim, with almost all options turned off. This gives me a small vi
which works even better then the original vi :)

Wichert.
-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bootint big kernels

[Enrique Zanardi]

On Thu, Jun 11, 1998 at 09:41:03AM -0400, Dale Scheetz wrote:
> The problem is that the Debian installation kernel tries to be all things
> to all people. As there are machines that boot from SCSI drives, it was
> necessary to have all the scsi controlers "built in" to the kernel, hense
> its large size.
> 
> We should recommend that everyone, once they have a standard system and
> can build a kernel, should build a custom kernel for their machine as
> early as possible.
> 
> Another solution is the one that slackware provides. They build a "bunch"
> of kernels, each one for a specific hardware configuration (broad enought
> to cover a range of hardware, and chosen to keep incopatibly drivers out
> of the picture {like the wd9000 driver that plonks ethernet cards})

I'm working on a better solution that involves using initrd to
load the required controllers (built as loadable modules). I've tested
using initrd for lowmem installations and it works flawlessly (just have
a look at lowmem boot disk in boot-floppies_2.0.7 when I upload it next
weekend).

Using initrd, our default kernel may be reduced to half its current size,
as all those different controllers may be built as modules and only the
required ones will be loaded at boot time. That will save our users a few
hundred KBs of RAM, and will make building a custom kernel a not so
needed step.

When I have a "proof-of-concept" implementation, I plan to discuss the
details with Herbert Xu, our kernel maintainer, to see if we can adopt
this solution for slink.

--
Enrique Zanardi[EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Hamish Moffatt]

On Thu, Jun 11, 1998 at 04:15:33PM +0200, Michael Dietrich wrote:
> > If vi would fit on the rescue disk, do you think we would be discussing
> > ae?
> i think it's not a good idea to put vi there. this editor can be used
> by a profi only and a prof can use any other editor too. a beginner
> won't be able to use vi but the easy to use small editor. maybe ae is
> bad, but it easier to use then vi and small. i wouldn discuss vi or
> ae, i would like to look for a really easy to use editor.

Actually, a regular vi user might be slower with another editor than with
vi, if only in looking for features it doesn't have. I have a shocking
time using pico because most of the useful features of vi are missing,
for example.


Hamish
-- 
Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: tools/ on ftp.debian.org

[Hamish Moffatt]

On Thu, Jun 11, 1998 at 02:49:48PM +0200, Michael Dietrich wrote:
> On Wed, Jun 10, 1998 at 01:36:58PM +0200, Anselm Lingnau wrote:
> > > unz512x3.exe is a self-unarching zip, and can be unpacked with Linux unzip
> > > 
> > > gzip124.exe is a self-unarching lharc file and can be unpacked with
> > > Linux lha
> > 
> > It might be a good idea to add a note in the README to that effect.
> > 
> i don't like those archives: you don know about a virus in it and you
> need 2 steps to get on that what you need (in fact you need a
> writeable storage with enough space - not easy with a floppy boot
> system and a cdrom). so: please extract those tools for dos!

It is equally likely that the extracted programs will be infected too.
Your point regarding temporary space is a good one, but both unzip
and gzip require space to extract things to anyway.

Hamish
-- 
Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bootint big kernels

[Hamish Moffatt]

On Thu, Jun 11, 1998 at 03:13:37PM +0100, Enrique Zanardi wrote:
> Using initrd, our default kernel may be reduced to half its current size,
> as all those different controllers may be built as modules and only the
> required ones will be loaded at boot time. That will save our users a few
> hundred KBs of RAM, and will make building a custom kernel a not so
> needed step.

Can we have zImages instead of bzImages then? :-)


Hamish (with the weird desktop)
-- 
Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to package (several)

[Rafael Laboissiere]

> "BG" == Ben Gertzfield <[EMAIL PROTECTED]> writes:

BG> This package should be named "libparse-recdescent-perl" to go
BG> along with all the other Perl module packages' names
BG> (libmd5-perl, libdbd-mysql-perl, et cetera).

I agree completely and will adopt you suggestion.  BTW, I will be the
maintainer with the package having the longest name in Debian. Wow!

I forgot to ask in debian-devel in which section this package should go.
Looking for the sections of the *-perl packages in frozen's Packages.gz
file, yields:

libdbd-mysql-perl: contrib/interpreters
libdbi-perl: contrib/interpreters
dpkg-perl: devel
libcgi-perl: web
libcompress-zlib-perl: libs
libcurses-perl: libs
libdelimmatch-perl: text
libgtk-perl: interpreters
libio-stringy-perl: interpreters
liblockdev0-perl: interpreters
libmd5-perl: interpreters
libmime-base64-perl: libs
libmime-perl: mail
libnet-perl: interpreters
libterm-readkey-perl: libs
libtime-hires-perl: libs
libtime-period-perl: interpreters
libtimedate-perl: interpreters
libwww-perl: interpreters
libxbase-perl: interpreters
netcdf-perl: math
libgd-perl: non-free/graphics

Apparently there is not much logic in the choice of sections
(e.g. libmime-base64-perl & libmime-perl).  I am missing some other
"pure Perl" packages, like Manoj's pkg-order (in section misc).

In waiting the "Perl Module Packaging Policy for Debian", which section
should I choose for libparse-recdescent-perl? (That's a long name, eh?)

Another question: the upstream package provides documentation in POD
format.  Where should it go?  I first thought in putting under
/usr/lib/perl5/pod, but I guess that /usr/doc/libparse-recdescent-perl
would be more appropriate.


--
Rafael Laboissiere
Institut de la Communication Parlee | Email: [EMAIL PROTECTED]
UPRESS A CNRS 5009 / INPG   | Voice: +33 4.76.57.48.49
46, av. Felix Viallet   |   Fax: +33 4.76.57.47.10
F-38031 Grenoble CEDEX 1 France |   URL: http://www.icp.inpg.fr/~rafael

Rafael


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Security problem - inetd.conf has rsh/rlogin/rexec "ON" as a default

[Amos Shapira]

On Thu, June 11 1998, Scott Ellis <[EMAIL PROTECTED]> wrote:
|On Thu, 11 Jun 1998, Amos Shapira wrote:
|
|> The rsh/rlogin/ident/rexec services are active by default in the
|> inetd.conf file.  Even though I keep removing them (I delete their
|> lines altogether since that way it's much easier to notice a change)
|> they seem to keep popping up after updating any software related to
|> this file.
|
|If you comment them out with a single "#", they won't be re-enabled by
|updated packages.

OK, I'll get back to doing that.  I used to do that until I got fed up
with having to comment the lines in the first place and look for the
uncommented lines periodically, instead of just deleting all but 2-3
lines and being able to watch them at a glance.

|> I'd like to suggest that these services will be "off" by default and
|> the user should be given a chance to stop the system before it
|> reactivates them.
|
|Many people do administration remotely.  They would probably be very
|disapointed to have their login services yanked out from under them.

I do a lot of remote administration too (actually, almost exclusively)
using ssh.  I know that ssh is not freely distributable with debian
(due to the crypto limitations) but having these services opened as a
default, and being re-opened after closed, looks like a risk to me (I
mean - how many people are really aware of the risk?  How many would
bother to install ssh if they were aware of the risk and the (easy,
IMHO) secure alternative?).

|They're easy enough to disable and only truely a security hole if you have
|.rhosts or hosts.equivs files laying around.  Even then, tcpwrappers makes

They are easy enough to disable indeed, but it's another administative
point to keep looking at in case things changed.  Also the hosts.equiv
and .rhosts files are another administrative "trace point".  Not that
I don't have to watch these files anyway, but watching them and
finding them to be OK is much less alarming than watching them and see
that everything is activated.

|them significantly harder to spoof than on a traditional UNIX environment.

You can't trust the DNS these days, not until secure DNS becomes more
common.  Also all passwords and sessions passed across the network are
wide open to anyone on the net to read.  So a cracker can either:

1. hack the DNS or fake a reply when the wrappers or rshd try to
   reverse-map the host.

2. watch the first TCP packet passed from the client to the server -
   the password is right there as plain text.

I may sound paranoid and bitching, but I used to be relaxed about
these things ("who's gona care about some tiny ISP at the end of the
world, really?") until I was bitten hard by a cracker (he sounded like
the interviews with the Analyzer, maybe it was him).  Since then I
live and work under the assumption that the cracker is there, watching
every move I make on any machine and the net.  And finding that
rsh/rexec/rlogin where again enabled this morning on my home machine
didn't help much to my happiness.

|> I'm not on the list (finals period) so please CC to me any response to
|> this message.
|
|CC sent.

Thanks.

--Amos

--Amos Shapira| "Of course Australia was marked for
133 Shlomo Ben-Yosef st.  |  glory, for its people had been chosen
Jerusalem 93 805  |  by the finest judges in England."
ISRAEL[EMAIL PROTECTED] | -- Anonymous


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Base Set: Suggested additions & removals.

[Andreas Jellinghaus]

new installations are done by windows users, not by unix system admins.
at least 90% ... 
while ed, vi and emacs might be nice for old unix hackers,
joe is the right choice for old dos hackers.

i'm useing vim everyday, and i will rather use sed than ae or that mini vi.
joe would be acceptable, too.

andreas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bootint big kernels

[Enrique Zanardi]

On Fri, Jun 12, 1998 at 12:25:59AM +1000, Hamish Moffatt wrote:
> On Thu, Jun 11, 1998 at 03:13:37PM +0100, Enrique Zanardi wrote:
> > Using initrd, our default kernel may be reduced to half its current size,
> > as all those different controllers may be built as modules and only the
> > required ones will be loaded at boot time. That will save our users a few
> > hundred KBs of RAM, and will make building a custom kernel a not so
> > needed step.
> 
> Can we have zImages instead of bzImages then? :-)

Probably.
--
Enrique Zanardi[EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ssl browsers

[Luis Francisco Gonzalez]

Hi,
I wanted to know what ssl-enabled browsers we have in debian now. Also
does anybody know if ftps:// is a valid URL for ssl-enabled ftp?

Thanks,
Luis.
-- 
Luis Francisco Gonzalez <[EMAIL PROTECTED]>
PGP Fingerprint = F8 B1 13 DE 22 22 94 A1  14 BE 95 8E 49 39 78 76


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#22942: Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)

[Marco Pistore]

On 11 Jun 1998, Gregory S. Stark wrote:
> Marco Pistore <[EMAIL PROTECTED]> writes:
> > 
> > Now, in hamm the binaries are only in libpaperg, since they are linked
> > against libc6 libraries; package libpaper in hamm contains only the
> > libraries. 
> 
> So, the original cause of the problem is that the binaries were in the library
> package. The policy specifically prohibits that precisely because of these
> problems. And you're proposing the libc6 versions keep doing the same thing
> that caused the problem in the first place.
> 
> What I would suggest would be:
> 
> libpaper:   libc5 libraries only 
> libpaperg:  libc6 libraries only 
> libpaper-utils: both binaries, depends on libpaper|libpaperg
> with wrapper scripts to choose the right ones somehow
> 
> This will at least avoid the problem in the future, as another version of the
> library can be installed simultaneously without conflicting with the existing
> libraries.
> 
> greg

Yes, you are right.

However, if i split the package now, some packages in hamm should then
depend on libpaper-utils (rather than on libpaperg), and should be
reuploaded. I do not think that it is convenient to do this change during
a deep freeze. 

I'll split the package in slink.

Thanks,

Marco







--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Release management - technical

[LeRoy D. Cressy]

Ian Jackson wrote:
> 
> I think that in order to make sense of what's being said here we need
> to step back a bit, and think about abstractions rather than
> implementation.  Lots of people (myself included) have been posting
> rather detailed proposals.
> 
> Q. What are we trying to achieve ?
> 
> A. There are two possibilities that I can see
> - Timely and good-quality releases, or
> - Releases which meet some predefined set of goals.
> 
> I think we can only do one of these.  With hamm we're doing the
> latter; in the future I think we should do the former.
> 

One of the things that I see about the Debian distribution is that at
the
present time the span of time between the release of Bo and the release
of
Hamm was entirely too long.  Many users do not have the capacity to
maintain
a mirror of the current ``stable'' distribution and the current
``unstable''
distributions.  I for one install systems for people and I maintain a
mirror
of both the slink and the hamm distributions.  

The point of all this verbage, if a person wants an uptodate system he
either
has to go to someone that has a mirror of the current distributions, or
he has
to spend days downloading the files that he requires for a base system
and
the files for what he is using the system for.  With timely updates like
a CD release every 4 to 6 months, a new user could get a relatively up
to date
system from the CD.  

I realize that the releases will not be as stable with such a short turn
around.  But as Ian stated, most of the developers are currently running
the latest unstable version, while many of the users that get their
versions 
from a CD are still using Bo.  There is such a vast difference between
Bo
and Slink, That when someone asks me about a problem in Bo or how to
upgrade
from Bo to Hamm they either have to come to me or spend a huge amount of
time
downloading a hamm upgrade.

Summery:

I would like to see periodic CD releases of both the unstable
distribution
and the stable distribution.  This will enable new users to get the same
distribution that many of the developers are using, while at the same
time
enable those that require a stable, well tested system, to get the
latest of
that version.

Excuse the preaching and have a good day:-)
-- 
  0 0  L & R Associates
   "   Home Page:http://www.netaxs.com/~ldc/
___ooO ~ Ooo___

LeRoy D. Cressy  /\_/\  [EMAIL PROTECTED]
Computer Consulting ( o.o ) Phone (215) 535-4037
 > ^ <  Fax   (215) 535-4285


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Boot Dependancies - a weird wacky wonderful new idea

[Kai Henningsen]

[EMAIL PROTECTED] (Robert Woodcock)  wrote on 10.06.98 in <[EMAIL PROTECTED]>:

> * /etc/init.d/rc is modified to call a program that determines the order
>   the scripts should be run in, on the fly. I figure this won't be much
>   of a speed hit. Slrn can thread thousands of messages per second across
>   a localhost news connection on my machine, sorting 30 scripts shouldn't
>   take long either. Actually, we don't even need to thread, we can probably
>   get away with just checking on script exit (any script exit) whether
>   there's something else available to run or not - if there's nothing else
>   available but there's still stuff that wants to be run, we can just run
>   it anyway.

man tsort

This does what you need. It even gives you a file format:

before1 after1
before2 after2
...



MfG Kai


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bootint big kernels

[Dale Scheetz]

On Thu, 11 Jun 1998, Enrique Zanardi wrote:

> On Thu, Jun 11, 1998 at 09:41:03AM -0400, Dale Scheetz wrote:
> > The problem is that the Debian installation kernel tries to be all things
> > to all people. As there are machines that boot from SCSI drives, it was
> > necessary to have all the scsi controlers "built in" to the kernel, hense
> > its large size.
> > 
> > We should recommend that everyone, once they have a standard system and
> > can build a kernel, should build a custom kernel for their machine as
> > early as possible.
> > 
> > Another solution is the one that slackware provides. They build a "bunch"
> > of kernels, each one for a specific hardware configuration (broad enought
> > to cover a range of hardware, and chosen to keep incopatibly drivers out
> > of the picture {like the wd9000 driver that plonks ethernet cards})
> 
> I'm working on a better solution that involves using initrd to
> load the required controllers (built as loadable modules). I've tested
> using initrd for lowmem installations and it works flawlessly (just have
> a look at lowmem boot disk in boot-floppies_2.0.7 when I upload it next
> weekend).

I have wondered why we didn't try this once the kernel supported initrd.
To be honest I haven't figured out yet how to do the device selection,
other than going through a list of drivers, trying to insmod each one
until you are successful.

I would love to see your solution for this, even in whatever the current
state is.

> 
> Using initrd, our default kernel may be reduced to half its current size,
> as all those different controllers may be built as modules and only the
> required ones will be loaded at boot time. That will save our users a few
> hundred KBs of RAM, and will make building a custom kernel a not so
> needed step.
> 
Yes, this would be a great improvement over the current situation, making
the installation kernel appropriate for a system kernel with no
rebuilding.

> When I have a "proof-of-concept" implementation, I plan to discuss the
> details with Herbert Xu, our kernel maintainer, to see if we can adopt
> this solution for slink.
> 
This is wonderful Enrique, thanks for all your fine work on this package!

I look forward to seeing this,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian bugs: collecting information

[Raul Miller]

Branden Robinson <[EMAIL PROTECTED]> wrote:
> This is a poor design. xbase-configure would be more properly called
> xserver-configure, and in slink when I jigsaw the upstream sources
> differen tly there's going to be an xserver-common package where
> xserver-configure, XF86Setup, et al. will go.  It would not prudent to
> engineer such a radical change at this point.  What should I do in the
> meantime?

If it seems to be there, offer the user the option of using it, if it's
not, blot out a message about that when it's available it can be used.

-- 
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Editor choice (was: VI reasons)

[Andreas Jellinghaus]

vi knowledge is essential if you have to deal with old sco/bsd/whatever unix
boxes. but max 5% of debian users will have to do that.

the essential for choosing an editor is :
we want the lowest common divisor - an editor that can be used by everybody,
and is as small as possible.

while i like vi(m) a lot more use it everyday, and i wish i knew how to use
emacs, the only editor i can suggest is joe.

both, an old unix hacker who olny knows vi or an old unix programmer who
only knows emacs could repair some critical files in /etc with it.

i don't know how to use emacs, and emacs user maybe don't know vi.

useing joe is possible for everybody, includeing the newbie comeing from apple
or windows or dos or os2.

andreas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Andreas Jellinghaus]

> At a client's place with a broken SunOS 4 box? Need to fix the /usr
> partition and password file.  Chances are are you'll have to use vi.
> Similarly, BSD, SCO, etc, etc...

maybe you should learn edlin, it's the only editor available on computers
running msdos 2.11.

or how to use vms, maybe one day ...

stop this. if you ever have to work with , then you cna learn it.
but if you want to install debian gnu/linux, you don't want to learn how to
use sco/sunos/msdos 2.11/vms/whatever. you want a debian gnu/linux system.

> Then, by the same token, every debian system should have a vi-compatible
> editor so that you know if you go around to a client's place with a broken
> machine, down to the root partition and you have to save the database,
> that vi is around.

max compatibilities ?
new linux installations are done by 
a few people familiar with unix
a few people familiar with mac
a few people familiar with dos
a few people who never used a computer
very many people familiar with win95

so we should copy "notepad" ?

joe has enought help text, so anyone can do a "emergency edit session".
and for everything else, you can install your own editor.

hey: whenever i have to work at a linux machine, i fix it to the point where i
can install vim, and then i can use vim, my favorite editor.

but vim is too big, and i don't force people unfamliar with vi to use vim.

joe - hey for the worst case everyone can use it.

i can't say that about vi or emacs.

and ae is ugly ugly ugly ugly ugly.

> So on any future base system there should exist a '/bin/vi' (possibly a
> symlink) which invokes some binary (I don't mind which) in some kind of
> mode which emulates vi.

and the next guy will force us to install /bin/edlin ?

andreas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Andreas Jellinghaus]

i'm useing vim every day. i cannot even open or save a file in emacs, or your
it (hey, i tried !).

a working joe is better than a brain damaged vi or ae.

andreas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Andreas Jellinghaus]

(vi)
> It is the only editor that you can count on being there if all else fails
> and it's absence or replacement would be VERY notable to those who expect
> vi. 

editor.exe is the only editor that you can count on being there if all else
fails and it's absence or replacement would be VERY notable to those who
expect editor.exe

lets do a ratio of dos/win* users that will install linux,
and unix users that will install linux. you have lost.

hey, i'm useing linux for a long time, and i expect
joe to be there. 

vi would fit if we were talking about unix. but this is debian gnu/linux,
and not unix, and so it's not vi or edlin or emacs : it's joe.

everyone can use joe. it might be very frustrateing but it's possible.

i can't use emacs, and my neighbor can't use vi.
and even i as a 100% vim user rather like to use joe than a cut down vi where
lots of functionality is missing. 

> again, I've used vi on over 20 platforms each running various OS's over
> the past 12+ years.

no new linux user is supposed to do that.
should i go out and find someone who used edlin
and editor.exe in the last 12+ years ?

linux isn't a new unix, there is lots of spirit from the windows world.

> if all else fails.  When I got stuck in ae the first few times, I ended
> up running to another machine to make a disk with vi on it because I had
> more important things to think about (and repair) than to try to work
> around a strange editor.

 i'm  useing sed or stuff like this - it's better than ae or 
that broken vi (emulation ?). more often i create new files with echo.

> Like I said, overall, I think this issue is being discussed on a comfort
> level right now.  I think we should really be hashing out whether or not
> we want to cater to newbies (ae) or to experienced systems admins (vi).
> I'm for the latter, but that's only my opinion

i don't give a peny for experienced system admins.
we always find our way to repair a system up to the point where we can
install vim.deb ... 

and newbies who like ae ? i don't know anybody.
lets give the newbies a real editor, and we unix sysadmins can either use that
one too, or continue with our sed/echo/*** hacks.

> Also, why not just offer two different disks if possible?

why not create a cdrom with a live filesystem and all available editors on it?
the contrib cdrom is still pretty empty ...

andreas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Andreas Jellinghaus]

> If vi would fit on the rescue disk, do you think we would be discussing
> ae?

> To be able to do an install with the rescue disk the space priorities
> don't allow anything but ae in that environment. When you can get vi's
> binary size down to the footprint of ae, I will be glad to replace it.
> Until then all talk of superior usability are nothing but talk. It will
> not fit.

rescue disk ? if the system fails, you have to install the base system on your
swap partition, and than continue with that.
ok, in some very rare conditions you can't do that, and then you need an
editor. 

what about createing a bootable live-rescue-cdrom ?
does anybody know how to do that.

andreas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Raul Miller]

Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
> everyone can use joe. it might be very frustrateing but it's possible.

We already have that with ae.  Is Joe smaller than ae?

-- 
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Dale Scheetz]

On Thu, 11 Jun 1998, Wichert Akkerman wrote:

> Previously Dale Scheetz wrote:
> > ae already does this, and provides a reasonably vi ish interface, just to
> > satisfy those whose fingers are only programmed for vi.
> 
> Personally, I find ae's vi-compatibility even worse then normal ae: it
> tricks me into thinking it's vi, but I can never resist using some
> vi-magic which confuses ae and gives me horrible results.

I agree. I prefer to use ae as ae to keep this clear.

I use ae, vi, ed, sed, joe, and sometime emacs every day. I also work with
software on that other os, like pagemaker and word. These are all
different and similar and confusing. I am always typing ":wq" in
joe and "^k^x" in vi, both of which are non-destructive actions (in joe
you have to delete the characters you typed and in vi it laughs at you)

In ae, I always had to check the menu, until I put the emacs bindings in
place. Does vi recogize ^X^S? ;-)

> 
> On my own installation disks (for local network use only) I'm putting
> vim, with almost all options turned off. This gives me a small vi
> which works even better then the original vi :)
> 
Cool, we can always use a better vi ;-)

Waiting is,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Base Set: Suggested additions & removals.

[Kenneth . Scharf]

new installations are done by windows users, not by unix system admins.
at least 90% ...
while ed, vi and emacs might be nice for old unix hackers,
joe is the right choice for old dos hackers.

i'm useing vim everyday, and i will rather use sed than ae or that mini vi.
joe would be acceptable, too.

andreas

+++


Gosh I forgot about joe (havn't used it since I went from slackware to
debian.  Joe is a sortof clone of wordstar.  Wow, I used wordstar for some
time before getting wordperfect. (Now at work I'm stuck with MS word.
YUCK!  Always getting documents infected with viruses).

If ae is a mini set of vi (cursor keys, insert, delete, write commands
same) then I would not get lost.

Anyone remember DEC's teco?  Is there a free clone of that?  Teco's macro
language was so extensive that I heard of a mad decee who wrote a startrek
game in teco.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

WANTED: someone to create a livefilesystem

[Andreas Jellinghaus]

the "contrib" cdrom of the official cdset 
should contain a livefilesystem, only to repair an installed linux.

i want that filesystem to have all text editors (see the current discussion),
and every programm that might be usefull to repair a broken system
(fs utils, ftape utils, smb client, amanda, whatever you think is good).

i'm sorry, i don't have the time to do it myself. but i think this is an
important task, for more important than .
you have all assistance and help that i can give. i have some ideas how a 
live filesystem could work, but i never created one, so i don't know exactly.

andreas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

joilet fs for official cdrom

[Andreas Jellinghaus]

sad news : after i created cdrom images with -J (joilet) option,
the symlinks were broken : plain 2.0.33 sees them as files,
but 2.0.34pre (with joilet patch) understands them.

i guess, i will have to create the official cdroms without joilet fs
support.

comments ?

andreas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

stuff to create debian cdroms

[Andreas Jellinghaus]

now available on http://open.hands.com/~aj/

the mkhybrid file was placed there for bo systems which don't have
mkhybrid. it's staticaly linked. 

but with newest joilet extensions problem, we will not need it.

i will recreate the images now, so they will be availabe in an hour or so.
contact [EMAIL PROTECTED] how to get them ...

andreas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to package (several)

[Elie Rosenblum]

And thus spake Rafael Laboissiere, on Thu, Jun 11, 1998 at 04:20:59PM +0200:
> I forgot to ask in debian-devel in which section this package should go.

The description you gave of the package makes it sound like it should
go in devel with the other parser generators, but I haven't looked at
the module myself.

-- 
Elie Rosenblum That is not dead which can eternal lie,
And with strange aeons even death may die.
Developer / Mercenary / System Administrator - _The Necromicon_


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Andreas Jellinghaus]

On Thu 11 Jun 1998, Raul Miller wrote:
> Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
> > everyone can use joe. it might be very frustrateing but it's possible.
> 
> We already have that with ae.  Is Joe smaller than ae?

no. much bigger and much more useable IMO.

andreas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: joilet fs for official cdrom

[Luis Francisco Gonzalez]

Andreas Jellinghaus wrote:
> sad news : after i created cdrom images with -J (joilet) option,
> the symlinks were broken : plain 2.0.33 sees them as files,
> but 2.0.34pre (with joilet patch) understands them.
> 
> i guess, i will have to create the official cdroms without joilet fs
> support.
> 
> comments ?
I thought debian's 2.0.33 had the FAT32 patch. This is the same as the joilet
stuff AFAIK. Does this mean that you are using a non-standard kernel or am I
just totally wrong here?

Luis.
-- 
Luis Francisco Gonzalez <[EMAIL PROTECTED]>
PGP Fingerprint = F8 B1 13 DE 22 22 94 A1  14 BE 95 8E 49 39 78 76


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bootint big kernels

[Martin Alonso Soto Jacome]

Dale Scheetz <[EMAIL PROTECTED]> wrote:
> I have wondered why we didn't try this once the kernel supported initrd.
> To be honest I haven't figured out yet how to do the device selection,
> other than going through a list of drivers, trying to insmod each one
> until you are successful.

Wouldn't PCI and ISA PnP support help here?  Standard 2.0.x kernels support 
/proc/pci since a long time, so it should be possible to check the device 
names on /proc/pci against a table in order to load the apropriate modules.  
It should also be possible to deal with PnP just the same way, although I 
don't know what the status of the PnP support in the kernel is right now.

Regards,

M. S.


Martin A. Soto J.   Profesor
Departamento de Ingenieria de Sistemas y Computacion
Universidad de los Andes  [EMAIL PROTECTED]



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Nathan E Norman]

On Thu, 11 Jun 1998, Wichert Akkerman wrote:

: Previously Dale Scheetz wrote:
: > ae already does this, and provides a reasonably vi ish interface, just to
: > satisfy those whose fingers are only programmed for vi.
: 
: Personally, I find ae's vi-compatibility even worse then normal ae: it
: tricks me into thinking it's vi, but I can never resist using some
: vi-magic which confuses ae and gives me horrible results.

Seconded.  I've been training myself to type `ae' rather than `vi' when
using the rescue disk - i've screwed things up too many times thinking I
was actually using vi.

Dale, I don't mind `ae' - it works :)  But the vi mappings I don't like.
Realising this is another of those religious debates I'll stop now :)

--
Nathan Norman
MidcoNet - 410 South Phillips Avenue - Sioux Falls, SD  57104
mailto://[EMAIL PROTECTED]   http://www.midco.net
finger [EMAIL PROTECTED] for PGP Key: (0xA33B86E9)



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bootint big kernels

[Enrique Zanardi]

On Thu, Jun 11, 1998 at 11:45:56AM -0500, Martin Alonso Soto Jacome wrote:
> Dale Scheetz <[EMAIL PROTECTED]> wrote:
> > I have wondered why we didn't try this once the kernel supported initrd.
> > To be honest I haven't figured out yet how to do the device selection,
> > other than going through a list of drivers, trying to insmod each one
> > until you are successful.
> 
> Wouldn't PCI and ISA PnP support help here?  Standard 2.0.x kernels support 
> /proc/pci since a long time, so it should be possible to check the device 
> names on /proc/pci against a table in order to load the apropriate modules.  

That's what Red Hat does, and what I plan to implement for slink. It
doesn't work for ISA cards though, therefore I plan to implement a method
for manually selecting modules at install time as well (probably a
modified "modconf").

> It should also be possible to deal with PnP just the same way, 

Yes, but we will have to create the "device -> module" table from
scratch, as I don't know of anyone that maintains such a table.

> although I 
> don't know what the status of the PnP support in the kernel is right now.

None AFAIK. PnP devices are configured with user-space tools (pnpdump and
isapnp). 

--
Enrique Zanardi[EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: stuff to create debian cdroms

[Philip Hands]

> now available on http://open.hands.com/~aj/

or alternatively:

   http://www.uk.debian.org/~aj/

if the new CNAME is doing it's stuff.

> the mkhybrid file was placed there for bo systems which don't have
> mkhybrid. it's staticaly linked. 
> 
> but with newest joilet extensions problem, we will not need it.
> 
> i will recreate the images now, so they will be availabe in an hour or so.
> contact [EMAIL PROTECTED] how to get them ...

That's [EMAIL PROTECTED]

(the @open.hands.com address ends up being dumped in a holding area because
 of a kludge I had to inflict on myself when I moved my domain around)

Cheers, Phil.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Christopher C. Chimelis]

Andreas Jellinghaus wrote:
>
> editor.exe is the only editor that you can count on being there if all else
> fails and it's absence or replacement would be VERY notable to those who
> expect editor.exe
> lets do a ratio of dos/win* users that will install linux,
> and unix users that will install linux. you have lost.

Well, first off, editor.exe isn't there at all on DOS systems (edit for
later versions or edlin for earlier), but let's not get into that...it's
irrelevant right now.  It's up to you, I guess, as to what editor to
use.  I think it's pointless to argue about it.  I just think we can do
better than ae.  I don't personally care since I can use sed, cat, or
any other number of methods to fix my system if need be (I keep a static
vi laying around NFS).  *I* take precautions like that, so I don't need
stock rescue disks.  Therefore, I'm NOT going to argue about this very
hard at all.  I just figured I would voice an opinion to second one that
had been expressed before.

> hey, i'm useing linux for a long time, and i expect
> joe to be there.

Then put it thereI don't see why this has become such a difficult
issue.

> vi would fit if we were talking about unix. but this is debian gnu/linux,
> and not unix, and so it's not vi or edlin or emacs : it's joe.
> everyone can use joe. it might be very frustrateing but it's possible.
> i can't use emacs, and my neighbor can't use vi.
> and even i as a 100% vim user rather like to use joe than a cut down vi where
> lots of functionality is missing.

I feel your pain with emacs.  I learned it years ago and dropped it
almost as long ago.  I just hate hitting key combos to do things.  As
for joe, never used it, but would try it.  I've tried ae, though, and I
thought it was functional, but non-intuitive on any user level.

> no new linux user is supposed to do that.
> should i go out and find someone who used edlin
> and editor.exe in the last 12+ years ?
> linux isn't a new unix, there is lots of spirit from the windows world.

My point is that more and more Linux systems are being HEAVILY used in
the business world and therefore would normally have an experienced hand
there to repair the systems.  Very few Windows users who dual boot to
Linux would even bother trying to rescue their system...they would
simply reinstall (as Mr. Gates has trained them to do when things go
wrong).

>  i'm  useing sed or stuff like this - it's better than ae or
> that broken vi (emulation ?). more often i create new files with echo.

Agreed 1% :-)

> i don't give a peny for experienced system admins.
> we always find our way to repair a system up to the point where we can
> install vim.deb ...

Very true.  It's just handier.  Like I said before...it's just an
opinion...not me trying to convince you one way or another.

> and newbies who like ae ? i don't know anybody.
> lets give the newbies a real editor, and we unix sysadmins can either use that
> one too, or continue with our sed/echo/*** hacks.

Sounds good to me.  Anything's better than ae, IMO.

> why not create a cdrom with a live filesystem and all available editors on it?
> the contrib cdrom is still pretty empty ...

Not a bad idea, but 75% of my personal computers don't have CD-ROMs :-(
I would guess that most people do, so it's still a great idea (I'm not
saying that just because it doesn't suit me that it's not a good idea
that should be pursued).  I think we should find a way to provide a
floppy option, though, just in case.  I personally use either Zip disks
or a disk image that's loaded into a ramdisk and also mount an NFS
volume for access to some static binaries.

Then again, I'm just cool like that :-P

Hehehe...

Chris

> 
> andreas
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Intend to package ZenIRC

[Martin Schulze]

Howdy,

ZenIRC is a major mode for wasting time (quote).  It's an IRC
client within Emacs.

I'm considering stealing ideas for installing Emacs files from
the crypt++el package.

Regards,

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 / The good thing about standards is /
/ that there are so many to choose from. -- Andrew S. Tanenbaum /


pgptHHBNy1ml0.pgp
Description: PGP signature

RE: ISDN driver support

[Peter Hum]

> Hi,
> 
> My name is Peter Hum and I am a program manager at Eicon Technology.  We
> are currently in the process of porting our driver for our ISDN PRI/BRI
> adapter into Linux.  I would like to know we can have this driver
> integrated into your next release of the kernel.
> 
> Thanks
> 
> Peter Hum
> Program Manger
> Eicon Technology
> 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mirroring policy

[Philip Hands]

> As quite a number of people are currently using rsync to mirror, is it
> really worth it to make a change?

It's worth at least setting up annon rsync, because it means that the data 
does not get run through ssh at each end, thus saving CPU cycles and 10% (or 
more) of the bandwidth.

For restricting usage, the rsync server does allow challenge/response
authentication as well, so we could give the password to official mirrors, and 
that would be the end of the administration problem.

Cheers, Phil.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Official CDROM

[Philip Hands]

> With the 5 cd set they can choose. And smaller redistributors that simply
> burn gold cds (as I do in italy, just 20 to 40 cds) can choose to exclude 
> a couple of them the from the distribution.

The Official CD images are meant for the big CD vendors, so we don't have them 
doing a run of 1000 CD's which they didn't build correctly.  For you, it would 
be better to tweak the scripts to your own needs, build your own images from a 
local mirror, and burn them. (That's what I do)

> > A cd like this, with approximately 250 meg binaries, 250 meg sources, 40
> > meg documentation, 10 meg kernels and a 100 meg live filesystem would
> > make an excellent "cover cd" for computer magazines.
> > 
> > Any takers?  I'd love to work with some people on a little project to have
> > this working for 2.1.
> 
> Mmmhh. I am woking on that. What I dream is a bootable/livefs cdrom
> that lets you play a little bit with linux and then guides you
> through the installation process from the hd (re)partinioning to
> the X11 configuration. 

Let's see if we cannot fit it on www.uk.debian.org (where Andreas is currently 
building the 4CD set).  If people can come up with tweaks for the scripts, to 
build this Debian-Lite CD, we could just include it in the main makefile, and 
generate them all at the same time.

open.hands.com (what www.uk.debian.org is really called) is getting down to 
it's last gig. on the partition where the CD images sit, so I'm going to get 
another drive for it.  Once that's done we can have a whole load of 
alternative cuts of the Official CD generated there if people want them.

Cheers, Phil.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Boot Dependancies - a weird wacky wonderful new idea

[Yann Dirson]

Avery Pennarun writes:
 > What's wrong with priority levels?  Programs start up in alphabetical order. 
 > I wish they would die in reverse-alphabetical order (then we could have
 > S99xdm and K99kdm, which would make the file-rc package look nicer) but
 > priority levels do exactly what you want -- they express boot-time
 > dependencies.

No.  I'd say priorities are a higher-level abstraction than real
deps.  You loose a lot of information when translating real deps into
priorities, which can make it difficult in case of deps changes: one
dep disapearing may well stay unnoticed, and thus not paralelized; one
appearing may eventually cause trouble...

 > We can achieve a huge degree of parallelism simply by running all boot
 > scripts of each priority level in parallel.  That is, run all scripts at
 > level 01 (and wait to finish), then run all scripts at level 02, and so on. 
 > To see why this should be "parallel enough," look at the large number of
 > scripts running at the default level 20.

...which would mean that level 20 is nearly all that can be
parallelized ?  The only other duplicate priorities on my system are
2 S10 and 2 S50...  I guess there may be some unnecessary distinct
levels down there.

 > The hardest thing would be keeping the log messages from getting tangled up. 
 > That shouldn't really be too hard for a C/C++ program to do.  I've done
 > something almost appropriate in my wvdial package (see class WvLog and
 > WvLogRcv).

Miquel told me some time ago of a boot-logging daemon he plans, that
would save these boot messages.  Maybe we should just modify boot
sctipts to redirect their outputs individually through a bootlog
facility, not unlike syslog ?  That would just have to be done in "rc"
itself !

Philip Hands writes:
 > This sounds like a job for make (which can run things in parallel)

/bin/make ?  That would just be the 3rd largest binary there, after
bash and tar :(

 > [1] like make /etc/init.d/deps/[KS]packagename be makefile fragments that
 > get included into the master makefile.

sure "include /etc/init.d/deps/*" is an easy thing.

 > You can use make's load/job limiting options to tune the best number of 
 > things 
 > to run at once.

Yes.


Maybe we can just add a series of #ifdef in make sources to make a
/bin/boot-make that would have small footprint both in RAM and in / ?
But maybe it's not worth the time to do it ?

-- 
Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
isp-email:   <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email:   <[EMAIL PROTECTED]> | more powerful, more stable !
http://www.mygale.org/~ydirson/ | Check 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Remco Blaakmeer]

On Thu, 11 Jun 1998, Raul Miller wrote:

> Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
> > everyone can use joe. it might be very frustrateing but it's possible.
> 
> We already have that with ae.  Is Joe smaller than ae?

[EMAIL PROTECTED]:~]$ ll /bin/ae /usr/bin/joe 
-rwxr-xr-x   1 root root24076 May 23 22:21 /bin/ae*
-rwxr-xr-x   5 root root   174020 Apr 20 00:11 /usr/bin/joe*

Well, joe seems to be about seven times as big as ae, so that's out of the
question.

Remco


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Remco Blaakmeer]

On Thu, 11 Jun 1998, Wichert Akkerman wrote:

> Previously Dale Scheetz wrote:
> > ae already does this, and provides a reasonably vi ish interface, just to
> > satisfy those whose fingers are only programmed for vi.
> 
> Personally, I find ae's vi-compatibility even worse then normal ae: it
> tricks me into thinking it's vi, but I can never resist using some
> vi-magic which confuses ae and gives me horrible results.

As an elvis fan, I share those feelings.

> On my own installation disks (for local network use only) I'm putting
> vim, with almost all options turned off. This gives me a small vi
> which works even better then the original vi :)

Cool. How big is that? Could it be put into a package (just like
elvis-tiny)? We'd have yet another vi clone.

Remco


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: tools/ on ftp.debian.org

[Andreas Jellinghaus]

>i don't like those archives: you don know about a virus in it and you
>need 2 steps to get on that what you need (in fact you need a
>writeable storage with enough space - not easy with a floppy boot
>system and a cdrom). so: please extract those tools for dos!

in my Makefile to create a cdrom i do this : /debian/tools is partof the ftp
mirror, and contains the archives, while /tools contains directories with the
uncompressed binary files.

andreas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: APT 0.0.16

[Steve Dunham]

Paul Seelig <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] (Jason Gunthorpe) writes:
> 
> > APT 0.0.16 is available for both bo and hamm. Please let me know if there
> > are any bugs that got missed, I'm getting very few bug reports these days.

> It is running pretty fine, but there is one thing i personally find
> very disturbing about it.  When using apt to retrieve newer .deb
> packages from a Debian site it simply deletes the downloaded files
> after having installed them and doesn't bother asking first. :-(

That's just the "dselect" interface.  I'd suggest, after selecting
packages, that you go back to the command line and type:

  apt-get dselect-upgrade

(You might need a "-f" if you have dependency problems.)

I use the "apt-get" for everything but mass package selection.  (When
I want to add a single package I just do 

   apt-get install package_names_here

it fetches the package and all dependencies from the appropriate
servers and installs them.

> Whenever i download a .deb file i usually prefer to keep them around
> for possible future use, but apt is not very cooperative in this
> regard.  Sure, i could recreate the .deb files using dpkg-repack but i
> don't feel really comfortable with this option since it can't really
> recreate the original.

As I pointed out above this is actually a problem with the apt
"method" for dselect.  You should file a bug report against apt saying
that they should prompt before running "apt-get clean" in the apt
method of deselect and use the command line version until then.


I do have a feature request for apt: I would like to see a command
line interface to query the apt available cache.  At the very least it
should have something like "dpkg -l", listing all of the available
packages, with the one-line description and have another option like
"dpkg -s" that lists the detailed information for one package.


BTW, for people who are interested, if you carefully (with -p) untar
base2_0.tgz, chroot into it, install:

  apt, perl, libio-stringy-perl, libwww-perl, libmd5-perl, mailtools,
  and libmime-base64-perl.

(Note that it is libmime-base64-perl, not libmime-perl.)

Exit the chroot environment, tar it back up and you have an
"apt-enhanced" base set.  (You might also want to remove qftp, or
install libg++272 to resolve a broken dependency.)

The resulting file is 10688349 bytes long. (Verses 6866910 bytes for
the original tar file.)  There is some unncessary stuff from the perl
package, but this is good enough for NFS, hard drive, and CDROM
installs of the base.


Steve
[EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bootint big kernels

[Avery Pennarun]

On Thu, Jun 11, 1998 at 09:41:03AM -0400, Dale Scheetz wrote:

> The problem is that the Debian installation kernel tries to be all things
> to all people. As there are machines that boot from SCSI drives, it was
> necessary to have all the scsi controlers "built in" to the kernel, hense
> its large size.
> 
> We should recommend that everyone, once they have a standard system and
> can build a kernel, should build a custom kernel for their machine as
> early as possible.

This is, if I recall, exactly what initrd was made for.  Your bootloader
(eg. lilo) loads an initial ramdisk containing all the kernel modules you
might need.  An init script on the ramdisk loads the right modules (however
you choose to do that) and then exits; the kernel unmounts the ramdisk and
remounts the "real" rootdisk.

That way, you can have a kernel without _any_ disk drivers at all (even IDE)
and yet boot from any disk that has a kernel driver.  Works like a charm and
avoids all problems with conflicting drivers.

Unfortunately, I would expect it to have the same high-loading problems as
bzImage since a kernel+initrd would seldom fit in the low 640k.

Have fun,

Avery


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bootint big kernels

[Enrique Zanardi]

On Thu, Jun 11, 1998 at 10:02:21AM -0400, Avery Pennarun wrote:
> This is, if I recall, exactly what initrd was made for.  Your bootloader
> (eg. lilo) loads an initial ramdisk containing all the kernel modules you
> might need.  An init script on the ramdisk loads the right modules (however
> you choose to do that) and then exits; the kernel unmounts the ramdisk and
> remounts the "real" rootdisk.
> 
> That way, you can have a kernel without _any_ disk drivers at all (even IDE)
> and yet boot from any disk that has a kernel driver.  Works like a charm and
> avoids all problems with conflicting drivers.

IIRC, with kernel v2.0.33 one can't build the IDE driver as a module.

--
Enrique Zanardi[EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: joilet fs for official cdrom

[Ronald Lembcke]

> sad news : after i created cdrom images with -J (joilet) option,
> the symlinks were broken : plain 2.0.33 sees them as files,
> but 2.0.34pre (with joilet patch) understands them.
> 
> i guess, i will have to create the official cdroms without joilet fs
> support.
> 
> comments ?
I had the same problem with my selfburned hamm cd's... 
the debian-hamm kernel seems to prefere joliet over
rockridge with   mount -o nojoliet   the symlinks worked...

another problem with joliet... a bug in mkisofs and mkhybrid
(at least in the newest available versioin arround april 6th)

when you make a bootable cd with joliet _and_ rockridge
the information for the bios that it is a bootable cd
is written one sector too late... the cd won't be recognized
as bootable.

If someone can tell me the author's email address i could
report this bug... 

Roni (alias _crash)


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]