Help Wanted: xinetd

Hi.. I am the new xinetd maintainer, and I am looking for someone that is somewhat experienced in writing perl scripts. What I need is for someone to write (or help me write) a new xinetd specific version of /usr/sbin/update-inetd. This is not a HUGE job, since one only needs to adopt the existi

Re: Bootint big kernels

Steve Dunham <[EMAIL PROTECTED]> wrote: > The only isapnp devices I know of are audio. Are there any SCSI or > enet devices? (If so a table would be necessary as they are discovered.) Yes, a lot of modern soundcards include an IDE controller, that is usually configured with PnP. Also, my curre

Re: xinetd and nmbd

On Wed, Jun 10, 1998 at 07:11:38PM -0400, Eloy A. Paris wrote: > Hi again Norbert, > > just one question: do you know if xinetd will continue to listen at > traffic in a service's port after it has already forked the server for > that service and wait=no? Hm it will not answer the request

Re: joilet fs for official cdrom

> >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? > > i don't know what [EMAIL PROTECTED] is useing (no symlinks at his machine), > but my own system is runnin

Re: Bootint big kernels

Enrique Zanardi <[EMAIL PROTECTED]> writes: > 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

Re: joilet fs for official cdrom

>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? i don't know what [EMAIL PROTECTED] is useing (no symlinks at his machine), but my own system is running 2.0.34pre1

Re: Bootint big kernels

Dale Scheetz <[EMAIL PROTECTED]> writes: > 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 d

Re: joilet fs for official cdrom

> 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

Re: Bootint big kernels

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

Re: Bootint big kernels

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 larg

Re: APT 0.0.16

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

Re: tools/ on ftp.debian.org

>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

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

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 > tric

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

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 ro

Re: Boot Dependancies - a weird wacky wonderful new idea

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 -

Re: Official CDROM

> 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

Re: mirroring policy

> 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 restri

RE: ISDN driver support

> 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 > > Pete

Intend to package ZenIRC

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 / /

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

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 l

Re: stuff to create debian cdroms

> 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

Re: Bootint big kernels

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

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

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 : tric

Re: Bootint big kernels

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 P

Re: joilet fs for official cdrom

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. > >

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

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

Re: Intent to package (several)

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 mo

stuff to create debian cdroms

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 [EMA

joilet fs for official cdrom

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

WANTED: someone to create a livefilesystem

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

Re: Base Set: Suggested additions & removals.

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.

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

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 > tric

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

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 PROTECTE

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

> 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.

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

(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 notabl

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

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.)

> 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 on

Editor choice (was: VI reasons)

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(

Re: Debian bugs: collecting information

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.

Re: Bootint big kernels

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 c

Re: Boot Dependancies - a weird wacky wonderful new idea

[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 a

Re: Release management - technical

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 ? >

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

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 t

ssl browsers

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

Re: Bootint big kernels

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 o

Re: Base Set: Suggested additions & removals.

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

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

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 n

Re: Intent to package (several)

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

Re: Bootint big kernels

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 > hundre

Re: tools/ on ftp.debian.org

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

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

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

Re: Bootint big kernels

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

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

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

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

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 wd9

mirroring policy

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

Re: Release management - technical

> 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 l

Re: Base Set: Suggested additions & removals.

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 agre

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

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

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

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 lo

Re: so what? Re: Debian development modem

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 know

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

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

Re: Debian bugs: collecting information

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

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

> 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

Re: RFC: packaging kernel modules

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 o

Re: RFC: packaging kernel modules

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 tr

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

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 i

Re: RFC: monitoring maintainers' vacations

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

Re: Official CDROM

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 s

Re: tools/ on ftp.debian.org

-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 unp

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

> > 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? Co

Re: ircII is now free.

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 PR

Re: Base Set: Suggested additions & removals.

> > > 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 size

Re: mkdosfs

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

prelim deb of emusic

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]>

Re: tools/ on ftp.debian.org

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

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

> 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 co

Re: tools/ on ftp.debian.org

> 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: Boot Dependancies - a weird wacky wonderful new idea

> 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

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

-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+ooyqK7

Re: RFC: monitoring maintainers' vacations

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: RFC: packaging kernel modules

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

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

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 dir

Re: glibc and crypt

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 b

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

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)

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

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 pol

glibc and crypt

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 a

Re: RFC: packaging kernel modules

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 a

Re: Boot Dependancies - a weird wacky wonderful new idea

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 wo

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

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 t

Re: APT 0.0.16

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 up

APT 0.0.16

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: VI reasons (was Re: Base Set: Suggested additions & removals.)

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

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

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

Rescue and Installation (was Re: VI reasons)

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

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

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 wei

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

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 i

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

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 o

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

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.ca

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

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

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

> 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 t

  1   2   >