Subject: orphaned bash and related packages ?

From: Ian Jackson <[email-masked]>
Date: Wed, 10 Jul 96 13:05 BST

The current Maintainers file says:

 bash                 [email-masked] (David P. Boswell)
 fileutils            [email-masked] (David P. Boswell)
 libreadline2         [email-masked] (David P. Boswell)
 libreadline2-dev     [email-masked] (David P. Boswell)
 shellutils           [email-masked] (David P. Boswell)
 textutils            [email-masked] (David P. Boswell)

David Boswell tells me that he had to drop out of the project due to
time pressure early this year, and so someone else should be
maintaining these packages.

I see that Erick Branderhorst <[email-masked]> has recently
released a new version of textutils.  Erick, are you doing any of the
others ?  If you're going to release them then there's no need to do
anything; the maintainers info will fix itself.

Ray Dassen asked me to add override file entries listing David Boswell
as the maintainer for libreadline and libreadline2.  This is obviously
wrong, if David says it is :-).  Who is maintaining libreadline, or
are they orphaned ?

The libreadline packages should probably be done by the bash
maintainer.

Ian.

---

From: [email-masked]
Date: Fri, 12 Jul 1996 08:34:54 +0200 (MET DST)

> anything; the maintainers info will fix itself.

I can take shellutils and fileutils.
 
> The libreadline packages should probably be done by the bash

Would someone else want to do this?

Erick

---

From: Ian Jackson <[email-masked]>
Date: Fri, 12 Jul 96 18:05 BST

[email-masked] writes ("Re: orphaned bash and related packages ?"):
...
> I can take shellutils and fileutils.

Right, I've modified the override file to reflect this.

> Would someone else want to do this?

Hello ?  We really do need a bash maintainer ...

Ian.

---

From: Michael Nonweiler <[email-masked]>
Date: Sun, 14 Jul 1996 01:43:57 +0100 (BST)

...
...

I'll take over "fileutils" if nobody complains.  I'll upload a new version
when we've sorted out the source package format.

I'll also make an attempt to sort out the colour ls silliness.

Michael.

--
Michael Nonweiler <[email-masked]>

---

From: Syrus Nemat-Nasser <[email-masked]>
Date: Sun, 14 Jul 1996 12:42:07 -0700 (PDT)

> I'll also make an attempt to sort out the colour ls silliness.

I'd appreciate it if you'd include the actual maintainer of the "silliness"
in your attempt.  Also, didn't someone else already offer to take over
fileutils?  In any case, color-ls is presently a separate and independent
package due to the requests of Ian J. and Bruce P. to do it that way.

Syrus.

----------------------------------------------------------
Syrus Nemat-Nasser <[email-masked]>    UCSD Physics Dept.

---

From: "Alexander E. Apke" <[email-masked]>
Date: Mon, 15 Jul 1996 01:34:08 -0500 (CDT)

> package due to the requests of Ian J. and Bruce P. to do it that way.

Color ls is now a part of filutils as of 3.13 which just came out
recently.  So, I believe we will not need a separate color-ls package.

						Alex Apke

---

From: [email-masked]
Date: Mon, 15 Jul 1996 09:21:52 +0200 (MET DST)

> Hello ?  We really do need a bash maintainer ...

Ok if nobody is going to take this I 'll do but only on the condition 
that I have to download the bash source once and upload it once and
after that only patches will be uploaded.  I have to do this packaging
stuff from home most of the time so I don't want to pay too much for
on line connections. 

So it would be nice if the new source format would accept this 
possibility and not make me too poor.

"Unix: 30 definitions of regular expressions living under one roof"
                                                                D.E. Knuth
Erick Branderhorst  http://www.iaehv.nl/users/branderh/

---

From: [email-masked]
Date: Mon, 15 Jul 1996 10:25:22 +0200 (MET DST)

> package due to the requests of Ian J. and Bruce P. to do it that way.

Yes, I (erick) did take the fileutils package and am working on it.

What do you folks want to be done with the color-ls thing.  AFAICS it seems
to be provided in the fileutils package.  I don't know if color support 
has been in fileutils but I presume that it wasn't.  Now that it is (with
3.13) we might remove the color-ls package?

control file should get
Conflicts: color-ls

I hope that no package exists out there what has a Depends on color-ls.

Would this solve the color-ls thing?

---

From: Guy Maor <[email-masked]>
Date: Mon, 15 Jul 1996 10:39:47 -0500 (CDT)

>  libreadline2-dev     [email-masked] (David P. Boswell)

I'd like to take these.  I had already started modifying libreadline to
test for a rl_shell variable instead of a SHELL define at runtime
instead of compiletime.  This fixes some Debian only bash bugs.  I'll
go ahead and finish it.

Anybody have a problem with my killing the librl package?  It's the
a.out libreadline package.

Guy

---

From: Ian Jackson <[email-masked]>
Date: Mon, 15 Jul 96 17:26 BST

Klee Dienes writes (in private email to me):
> I'd be willing to take bash and readline, if for no other reason than
> to fix the obnoxious line-wrapping bug that's been annoying me since
> 1992.

This may be an ncurses bug, but it's too late now :-).

> I probably wouldn't have any reason to put up a new release soon, so
> if no-one else steps up to grab it, feel free to add me to the
> overrides file.

OK, you're now the maintainer.  You'll probably find that there are a
number of bugs outstanding that could at least do with sending to the
FSF, upstream.

> possibility and not make me too poor.

The new source format will allow this, I think (at least, my current
plan for it will).  But since we're not there yet I think Klee should
take the package for now.

There'll be plenty for you to do later :-).  Thanks for the offer.

Ian.

---

From: Syrus Nemat-Nasser <[email-masked]>
Date: Mon, 15 Jul 1996 09:49:35 -0700 (PDT)

> Would this solve the color-ls thing?

Yes, I think so.  My understanding is as follows:  Both Red Hat and Slackware
have included the fileutils 3.12 with the color-ls patch added.  Slackware defaults
to color enabled and Red Had defaults to no color.  I think we would have to do it
like Red Hat, but the question of how to get color will for sure become a FAQ unless
we documment it clearly.  When I first started building a color-ls package, I was
going to have it replace all of fileutils with my color-ls-patched version.  There
were some serious objections to this at the time, so I made my package install two
small binaries and two man pages, none of which had a conflict with any other files.

Since the upstream source for fileutils has now incorporated color, I think it
will be logical to kill my color-ls package for 1.2.  I expect we'll hear from a few
interested people before this discussion is over.

Syrus.

---

From: Ian Jackson <[email-masked]>
Date: Tue, 16 Jul 96 17:09 BST

> instead of compiletime.  This fixes some Debian only bash bugs.  I'll

You sound really keen - that's good.

I'd already said that Klee Dienes should do it, but if people don't
object I think Guy ought to.

The bash package (and libreadline2 too) are important for the
distribution, and it would be good to have a rather more experienced
maintainer.

Klee, and Dan: if you're still interested you could go through the bug
lists and find some packages with old bug reports and offer to take
them over or fix the bugs :-).

Alternatively Bruce says he wants to give his packages away:
    arrl-infoserv        Bruce Perens <[email-masked]>
    ash                  Bruce Perens <[email-masked]>
    ax25-kernel-source   Bruce Perens <[email-masked]>
    ax25-util            Bruce Perens <[email-masked]>
    base                 Bruce Perens <[email-masked]>
    boot-floppies        Bruce Perens <[email-masked]>
    bootdisk             Bruce Perens <[email-masked]>
    lilo                 Bruce Perens <[email-masked]>
    mbr                  Bruce Perens <[email-masked]>
    modconf              Bruce Perens <[email-masked]>
    pcb                  Bruce Perens <[email-masked]>
    rspfd                Bruce Perens <[email-masked]>
    syslinux             Bruce Perens <[email-masked]>
    x10                  Bruce Perens <[email-masked]>

Several of these are pretty easy, really.  Coordinate with Bruce, or
any existing maintainer, and debian-devel, to sort out what you're
doing.

When you've decided and have a package to upload let Bruce, Simon
Shapiro <[email-masked]> and Anders Chrigstrom <[email-masked]> know
so that they can give you an a/c on master and add you to
debian-private.

Thanks,
Ian.

---

From: Klee Dienes <[email-masked]>
Date: Tue, 16 Jul 1996 09:39:30 -0700

> object I think Guy ought to.

No objections here.   I can't compete with Guy's enthusiasm, and 
besides I'd rather be making new packages than maintaining old ones
any day.

---

From: Guy Maor <[email-masked]>
Date: Tue, 16 Jul 1996 12:30:17 -0500 (CDT)

Klee Dienes wrote:
> No objections here.   I can't compete with Guy's enthusiasm

?!?

I've always had a secret woody for bash.  Now I can go print up those
business cards I've been dreaming of, "Guy Maor, ENTHUSIASTIC bash
maintainer..."

Guy

---

From: Chris Fearnley <[email-masked]>
Date: Tue, 16 Jul 1996 17:12:06 -0400 (EDT)

[email-masked] wrote:'
>3.13) we might remove the color-ls package?

Is "ls" colored?  Probably it's best to have a /bin/ls and
/usr/bin/color-ls, so that scripts can us /bin/ls and pipe with it and
etc.  And interactive sessions can use color-ls.

>Conflicts: color-ls

And
Replaces: color-ls

>I hope that no package exists out there what has a Depends on color-ls.

If it's a problem we could even "Provides: color-ls" in the control
file.

-- 
Christopher J. Fearnley            |    Linux/Internet Consulting
[email-masked], [email-masked]       |    UNIX SIG Leader at PACS
http://www.netaxs.com/~cjf         |    (Philadelphia Area Computer Society)
ftp://ftp.netaxs.com/people/cjf    |    Design Science Revolutionary
"Dare to be Naive" -- Bucky Fuller |    Explorer in Universe

---

From: [email-masked]
Date: Tue, 16 Jul 96 23:39 EDT

Chris>  Is "ls" colored?  Probably it's best to have a /bin/ls and
  Chris> /usr/bin/color-ls, so that scripts can us /bin/ls and pipe with it
  Chris> and etc.  And interactive sessions can use color-ls.

Non-issue. The colour-ls only adds colour if there is a controlling
terminal. That 

--
Dirk Eddelb"uttel                             http://qed.econ.queensu.ca/~edd

---

From: Christian Hudon <[email-masked]>
Date: Wed, 17 Jul 1996 07:03:45 -0700 (PDT)

> >3.13) we might remove the color-ls package?

If color-ls is being folded into the fileutils, I say we do the same and
make the 'color-ls' package obsolete.

> etc.  And interactive sessions can use color-ls.

Hmm. We don't need the /usr/bin/color-ls link, do we?. Just put the color
ls as /usr/bin/ls and make it default to 'no color'. And provide a default
DIR_COLORS (or whatever file) that colors only when the output is sent to
a tty. That way both scripts and people will be happy.

> If it's a problem we could even "Provides: color-ls" in the control

None does. And anyhow, why would a package depend on color-ls? The 'color'
is useful for humans. For programs, doing a 'stat' is easier.

  Christian