ee-1.72-6

[Bill Mitchell]

Uploaded to pixar, announced to debian.devel

Date: 19 Dec 95 03:40 UT
Source: ee
Binary: ee 
Version: 1.72-6
Description: 
 ee: An "easy editor" for novices and compuphobics
Priority: Low
Changes: 
elf package
* rebuilt for elf
Files:
 -rw-r--r--   1 root root63763 Dec 18 19:40 ee-1.72-6.tar.gz
 -rw-r--r--   1 root root   20 Dec 18 19:40 ee-1.72-6.diff.gz
 -rw-r--r--   1 root root77847 Dec 18 19:40 ee-1.72-6.deb
 9185c2166b1339954a6222f0d8323511  ee-1.72-6.tar.gz
 07518f3439697caabd10a40520d52627  ee-1.72-6.diff.gz
 cbe5e1070d4b6bd6f34b48e8e48fed45  ee-1.72-6.deb

less-290-7

[Bill Mitchell]

Uploaded to pixar, announced to debian.devel

Date: 19 Dec 95 03:26 UT
Source: less
Binary: less 
Version: 290-7
Description: 
 less: A file pager program, similar to more(1)
Priority: Low
Changes: 
elf package
* added bugfix in #ifdef LINUX code in ch.c
Files:
 -rw-r--r--   1 root root   176255 Dec 18 19:26 less-290-7.tar.gz
 -rw-r--r--   1 root root10267 Dec 18 19:26 less-290-7.diff.gz
 -rw-r--r--   1 root root85113 Dec 18 19:26 less-290-7.deb
 887e8e3f5b2ea1795a41b77e4628779f  less-290-7.tar.gz
 f3b70e8d8aeaf4e2fcabd4858bc84023  less-290-7.diff.gz
 053077a2fb7268690ac5e9b6cd1cea45  less-290-7.deb

elvis-1.8pl4-21

[Bill Mitchell]

Uploaded to pixar, announced to debian.devel

Date: 19 Dec 95 04:02 UT
Source: elvis
Binary: elv-ctags elv-fmt elv-vi 
Version: 1.8pl4-21
Description: 
 elv-ctags: generate "tags" and (optionally) "refs" files
 elv-fmt: Adjust line-length for paragraphs of text
 elv-vi: elvis, ex, vi, view, input - The editor
Priority: Low
Changes: 
elf package
* rebuilt for elf
Files:
 -rw-r--r--   1 root root   275076 Dec 18 20:02 elvis-1.8pl4-21.tar.gz
 -rw-r--r--   1 root root13312 Dec 18 20:02 elvis-1.8pl4-21.diff.gz
 -rw-r--r--   1 root root 8137 Dec 18 20:01 elv-ctags-1.8pl4-21.deb
 -rw-r--r--   1 root root 4761 Dec 18 20:01 elv-fmt-1.8pl4-21.deb
 -rw-r--r--   1 root root   175895 Dec 18 20:01 elv-vi-1.8pl4-21.deb
 6f8c16350ba560e9feaf16b6673c56f1  elvis-1.8pl4-21.tar.gz
 e97b91c1a0ec3183cc15cc0c5c59a7a2  elvis-1.8pl4-21.diff.gz
 39cdacfe42aa6395bb90abb4d2ca5df1  elv-ctags-1.8pl4-21.deb
 b36cec574a80a1e108350a6efd845a53  elv-fmt-1.8pl4-21.deb
 61877311d81247047fdd5dc18d8155d0  elv-vi-1.8pl4-21.deb

Bug#2042: less-290-5

[Bill Mitchell]

On Mon, 18 Dec 1995, Dale Scheetz wrote:

>   less-290-5 has been patched for the /proc filesystem, except that when
>   you less a proc file, less eats the first character of the report.

Fixed in less-290-7, just uploaded to pixar.

ae-493-8

[Bill Mitchell]

Uploaded to pixar, announced to debian.devel

Date: 19 Dec 95 03:12 UT
Source: ae
Binary: ae 
Version: 493-8
Description: 
 ae: Anthony's Editor -- a tiny full-screen editor
Priority: Low
Changes: 
elf package
* use elf ncurses libs instead of aout curses libs
* change /etc/ae.rc to be terminfo based instead of termcap
Files:
 -rw-r--r--   1 root root37303 Dec 18 19:11 ae-493-8.tar.gz
 -rw-r--r--   1 root root16963 Dec 18 19:12 ae-493-8.diff.gz
 -rw-r--r--   1 root staff   81134 Dec 18 19:11 ae-493-8.deb
 551c89e91dcc9c432af5832cca542133  ae-493-8.tar.gz
 aa0c70ccfbd0996c4cccfec586809ef6  ae-493-8.diff.gz
 9902649a41e2ccb61bad247a00593c1d  ae-493-8.deb

ncurses slowness with elf elvis

[Bill Mitchell]

I don't know if this is an elf issue, an ncurses issue, an elvis
issue, or a non issue.  Ncurses seems most likely to me.

Among the packages I just uploaded is elv-vi-1.8pl4-21.deb.  The
only difference between this and the -20 package is that it was
built with the elf libs.  I notice that, on my slow 6.65 BogoMips
system, the screen flashes annoyingly when I hit the ESC key using
the -21 version.

[EMAIL PROTECTED] (Bill Mitchell)

git-4.3.7-5

[Bill Mitchell]

Uploaded to pixar, announced to debian.devel

Date: 19 Dec 95 03:39 UT
Source: git
Binary: git 
Version: 4.3.7-5
Description: 
 git: GNU Interactive Tools
Priority: Low
Changes: 
elf package
* rebuilt for elf
Files:
 -rw-r--r--   1 root root   298577 Dec 18 19:39 git-4.3.7-5.tar.gz
 -rw-r--r--   1 root root10683 Dec 18 19:39 git-4.3.7-5.diff.gz
 -rw-r--r--   1 root root   302232 Dec 18 19:38 git-4.3.7-5.deb
 2a3c1a7c13acdd57fa9d8ff6244cfcde  git-4.3.7-5.tar.gz
 ae820d5b499fb2a466a8dc2d8f479731  git-4.3.7-5.diff.gz
 a5bc934c563d88f0ed07717d665e7f94  git-4.3.7-5.deb

beav-140-5

[Bill Mitchell]

Uploaded to pixar, announced to debian.devel

Date: 19 Dec 95 03:17 UT
Source: beav
Binary: beav 
Version: 140-5
Description: 
 beav: Binary Editor And Viewer (beav)
Priority: Low
Changes: 
elf package
*  rebuilt for elf
Files:
 -rw-r--r--   1 root root   131135 Dec 18 19:17 beav-140-5.tar.gz
 -rw-r--r--   1 root root   20 Dec 18 19:17 beav-140-5.diff.gz
 -rw-r--r--   1 root root88366 Dec 18 19:16 beav-140-5.deb
 294a6f17e56aca571ef575fce33e9d28  beav-140-5.tar.gz
 daedd1849e559e0d63e80ef4cc8435fc  beav-140-5.diff.gz
 fb9d43f31941d784301154652dbc5303  beav-140-5.deb

Bug#2048: Broken pipe from dpkg to head

[Bill Mitchell]

PACKAGE: dpkg
VERSION: 1.0.7

Script started on Mon Dec 18 21:19:37 1995
root:work# dpkg --info less*deb | head -1
 old debian package, version 0.939000.
Broken pipe
root:work# dpkg --info less*deb >x
root:work# head -1 x
 old debian package, version 0.939000.
root:work# cat x | head -1
 old debian package, version 0.939000.
root:work# exit
Script done on Mon Dec 18 21:20:45 1995

[EMAIL PROTECTED] (Bill Mitchell)

Bug#2047: grep segfaults when abused

[Bill Mitchell]

PACKAGE: grep
VERSION: 2.0-3

This might qualify as unwarranted abuse.  However, since I stumbled
across it, I thought I'd report it.

Script started on Mon Dec 18 21:15:01 1995
root:/root# grep trash /proc/kcore
Segmentation fault (core dumped)
root:/root# exit
Script done on Mon Dec 18 21:15:19 1995

/proc/kcore is 16MB on my system.  However, this doesn't seem to be
due to file size (I tried "cat /usr/bin/* | od | grep trash" and didn't
provoke a segfault).

[EMAIL PROTECTED] (Bill Mitchell)

why doesn't binutils-2.6-1 provide a shared library?

[Darren/Torin/Who Ever...]

Hopefully, this won't show my ignorance of binary objects off too badly.

Shouldn't binutils-2.6 provide a shared bfd library?

It used to in 2.5.2l.20-2?  I'm asking here instead of posting a bug
because I remember there being some  discussion about this a little
while back.

Also, why is it that I can do an 'nm libname.so' on some shared
libraries but not on others:

nm /lib/libdl.so.1 | wc -l
 43

nm /lib/libc.so.5 | wc -l
/lib/libc.so.5: no symbols
  0
nm -D /lib/libc.so.5 | wc -l
   1429

No, of course, you can get around this by using 'nm -D' but the
inconsistency is odd.  

It was interesting.  I had to do some shell programming to convince
Configure to collect the objects.  Do you know how hard it is to program
in shell when you've been designing and teaching Perl for the last 3
weeks?

Darren
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Do you have your clothes on? I probably don't. Take yours off. Feel better. @
@ Sysadmin, webweaver, postmaster for hire.  C and Perl programmer and tutor. @

ELF flex

[Robert Leslie]

I'm close to having an ELF version of bind ready, but I've found I need an ELF
version of flex (libfl.a) to finish.

Ian M., if you are maintaining flex, any chance of getting an ELF version
uploaded soon? If you'd rather not be bothered, perhaps I could even take the
package off your hands.

Feedback appreciated.

-- 
Robert Leslie
[EMAIL PROTECTED]

Bug#2049: bad depends in libdb1-dev 1.7.3-6

[Darren/Torin/Who Ever...]

Package: libdb1-dev
Version: 1.7.3-6

The control file has a bad depends in it:
grep '^Depends' libdb1-dev-control
Depends: libc5-dev (>5.2.16-1), libdb1 (1.85.2.x)

That final .x shouldn't be there.

Output from 'dpkg -i libdb1-dev-1.7.3-6.deb'
(Reading database ... 21499 files and directories currently installed.)
Preparing to replace libdb1-dev (using libdb1-dev-1.85.2-3.deb) ...
Unpacking replacement libdb1-dev ...
dpkg: dependency problems prevent configuration of libdb1-dev:
 libdb1-dev depends on libdb1 (1.85.2.x); however:
  Version of libdb1 on system is 1.85.2-3.
dpkg: error processing libdb1-dev (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 libdb1-dev

Darren
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Do you have your clothes on? I probably don't. Take yours off. Feel better. @
@ Sysadmin, webweaver, postmaster for hire.  C and Perl programmer and tutor. @

Bug#2050: bad(?) depends in libgdbm1-dev 1.7.3-6

[Darren/Torin/Who Ever...]

Package: libgdbm1-dev
Version: 1.7.3-6

There's a problem with libgdbm1-dev since when I install the
corresponding shared library package, it should install also, right?  It
doesn't.  I can't tell if the following is a problem with dpkg or with
the Depends line:

dpkg -i libgdbm1-dev-1.7.3-6.deb
(Reading database ... 21499 files and directories currently installed.)
Preparing to replace libgdbm1-dev (using libgdbm1-dev-1.7.3-6.deb) ...
Unpacking replacement libgdbm1-dev ...
dpkg: dependency problems prevent configuration of libgdbm1-dev:
 libgdbm1-dev depends on libgdbm1 (1.7.3); however:
  Version of libgdbm1 on system is 1.7.3-6.
dpkg: error processing libgdbm1-dev (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 libgdbm1-dev

I have the correct version of libgdbm1, it seems that dpkg didn't
recognize the debian version number.

Darren
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Do you have your clothes on? I probably don't. Take yours off. Feel better. @
@ Sysadmin, webweaver, postmaster for hire.  C and Perl programmer and tutor. @

Bug#2049: bad depends in libdb1-dev 1.7.3-6

[J.H.M.Dassen]

> Package: libdb1-dev
> Version: 1.7.3-6
>
> The control file has a bad depends in it:
> grep '^Depends' libdb1-dev-control
> Depends: libc5-dev (>5.2.16-1), libdb1 (1.85.2.x)
>
> That final .x shouldn't be there.

Yes. Fixed in my working sources. I'll make a new release soon.

Ray
--
Obsig: developing a new sig

Bug#2050: bad(?) depends in libgdbm1-dev 1.7.3-6

[J.H.M.Dassen]

> Package: libgdbm1-dev
> Version: 1.7.3-6
>
> There's a problem with libgdbm1-dev since when I install the
> corresponding shared library package, it should install also, right?  It
> doesn't.  I can't tell if the following is a problem with dpkg or with
> the Depends line:

It's the depends line. It doesn't contain a debian revision number.
In my working sources it's fixed; >libgdbm1-1.7.3.

Expect a new release in a couple of days.

Ray
--
Obsig: developing a new sig

Bug#2048: Broken pipe from dpkg to head

[Richard Kettlewell]

However: 

[EMAIL PROTECTED]:richard$ ls -l | head -1
total 19792
Broken pipe
[EMAIL PROTECTED]:richard$

Bill Mitchell writes:
>
>PACKAGE: dpkg
>VERSION: 1.0.7
>
>Script started on Mon Dec 18 21:19:37 1995
>root:work# dpkg --info less*deb | head -1
> old debian package, version 0.939000.
>Broken pipe
>root:work# dpkg --info less*deb >x
>root:work# head -1 x
> old debian package, version 0.939000.
>root:work# cat x | head -1
> old debian package, version 0.939000.
>root:work# exit
>Script done on Mon Dec 18 21:20:45 1995

Re: Debian+umsdos (fwd)

[Richard Kettlewell]

Bruce Perens writes:
>From: Simon Shapiro <[EMAIL PROTECTED]>

>> And why do we want this brain dead file system (which even M$ does
>> not use for its own 1980 eras OS's) to boot a Unix O/S with?
>
>Because it is the lowest common denominator, and it would let people
>alter the bootstrap floppy from a non-Linux system before they booted
>it.  This is sometimes convenient. Since it's just the bootstrap
>floppy, we don't have to worry about supporting it as much as we
>would if we supported having the entire system on a umsdos disk. Some
>people are going to try that, I guess.

Actually I think it would be a good thing if we could support Debian
entirely over UMSDOS - being able to run Linux without having to mess
around repartitioning hard discs is going to make a lot of people a
lot more willing to try it.

-- 
Richard Kettlewell  [EMAIL PROTECTED]  http://www.elmail.co.uk/staff/richard/

psutils ELF package release

[Dale Scheetz]

As the new maintainer of psutils, I have rebuilt the package as ELF. No 
other modifications were made to the package.

As I have not yet obtained the upstream source, I have been unable to 
create a diff file for this package (I had to fake out dchanges with a 
fraud .diff.gz file). It is my understanding (please correct me if I am 
incorrect) that the .diff file is to reflect the difference between the 
debian source and the original upstream source so that the original 
source can be recreated from the debian source. Asside from the debian 
control files this source is the same as the previous version.

BTW, I got cut off in the middle of the file upload for 
psutils-1.13-5.tar.gz so this file is incomplete. If some person 'more 
powerful than myself' would delete this file from Incoming, I will try to 
upload it complete.

Here's the changes file:

Date: 18 Dec 95 23:00 UT
Source: psutils
Binary: psutils 
Version: 1.13-5
Description: 
 psutils: psutils - PostScript document handling utilities
Priority: Low
Changes: 
Files:
 -rw-r--r--   1 root src158171 Dec 18 17:54 psutils-1.13-5.tar.gz
 -rw-r--r--   1 root root57036 Dec 17 17:20 psutils-1.13-5.deb
 0a18e8f9db6208e9073903322de9799c  psutils-1.13-5.tar.gz
 921096a2d13bf044091d9dd084e2b22c  psutils-1.13-5.deb

Party On,

Dwarf

Rebuild libident as ELF

[Dale Scheetz]

As the new maintainer of the libident package, I have rebuilt it as ELF 
and uploaded the binary package and the source tar.gz to Incoming.

As with the other packages I have picked up, I have no upstream source, 
so couldn't create a diff file.

Here's the .changes file:

Date: 19 Dec 95 13:21 UT
Source: libident
Binary: libident 
Version: 0.16-2
Description: 
 libident: libident - simple RFC1413 client library
Priority: Low
Changes: 
Files:
 -rw-r--r--   1 root src 30682 Dec 19 08:13 libident-0.16-2.tar.gz
 -rw-r--r--   1 root root10956 Dec 17 17:50 libident-0.16-2.deb
 fb453aa128f45cfa7d2aea51cf5be24a  libident-0.16-2.tar.gz
 6b6bbdc105d0072760628c3d614fc27e  libident-0.16-2.deb

Party On,

Dwarf

Rebuild of gmp as ELF

[Dale Scheetz]

As the new maintainer of the gmp package, I have rebuilt it as ELF. No 
other changes have been made to this package.

As with the other packages I maintain, I have not yet obtained the 
upstream source, so there is no .diff file.

The source and binary packages have been uploaded to Incoming.

Here is the .changes file:

Date: 19 Dec 95 13:19 UT
Source: gmp
Binary: gmp 
Version: 1.3.2-2
Description: 
 gmp: Multiprecision arithmetic library
Priority: Low
Changes: 
Files:
 -rw-r--r--   1 root src317951 Dec 19 08:10 gmp-1.3.2-2.tar.gz
 -rw-r--r--   1 root root61451 Dec 17 18:06 gmp-1.3.2-2.deb
 20c80f8cb322cbf9b08b7662a130c500  gmp-1.3.2-2.tar.gz
 a64b6ab7c1cf37af944ad7680cee  gmp-1.3.2-2.deb

Party On,

Dwarf

Bug#2051: /etc/ntp.conf is an auto-handled conffile

[Ian Jackson]

Package: xntp
Version: 3.4x-2

The ntp.conf file is modified (correctly) by the postinst after
installation.  This causes a conffiles conflict when the package is
upgraded.

I suggest that the package not use dpkg to install the file, but
instead create it itself if it doesn't exist; any changes which need
to be made during upgrades would have to be done manually.

Ian.

-chiark:~/download> really dpkg -i xntp-3.4x-2.deb
(Reading database ... 17436 files and directories currently installed.)
Preparing to replace xntp (using xntp-3.4x-2.deb) ...
Unpacking replacement xntp ...
Setting up xntp ...

Configuration file `/etc/ntp.conf'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  Z : background this process to examine the situation
 The default action is to keep your current version.
*** ntp.conf (Y/I/N/O/Z) [default=N] ? y
Installing new version of config file /etc/ntp.conf ...
Please enter the address of your NTP server.
Just hit enter if you don't know it now, and you can edit
the server line in /etc/ntp.conf later.
> ntp0.csx.cam.ac.uk
starting /usr/sbin/xntpd ...

-chiark:~/download>

Re: New ftp method for dselect

[brian (b.c.) white]

>OK, so package file names don't parse easily.  Why couldn't the cross
>reference be included in the Packages file?  It's needed by dselect
>anyway.  Also, what about packages like ld.so where the file name
>doesn't match the package name (ldso)?  What am I missing?

You're not missing anything.  Months ago, I tried to get the filename
standardized so my "dftp" program could properly get version info from
the filename.  This eventually led nowhere.

1) Nobody wants to change the names of existing packages.  The "ldso"
maintainer flat-out refused to match the filename to the package name.
Having a daemon automatically rename packages was also discarded.

2) Some version-strings start with a letter so you can't use "-[0-0]"
to locate the start of the version, though I think this still matches
more names than most other methods.

3) Both version-strings and package-names may contain dashes so dashes
cannot be used to flawlessly determine where versions & revisions are.

4) Some packages (notably "dpkg") doesn't even have a revision number.
If the primary people involved won't standardize the name on their own
packages, don't count on it getting done.


As a concession, the filename of each packages has been put into the
"Packages" file at the top of each directory hierachy.  The
"Packages-Master" contains (I believe) all of the "stable" and
"contrib" packages.

The "expermental" hierarchy has no "Packages" file because Ian wishes
people not to be able to accidentally download from there.

Brian
 ( [EMAIL PROTECTED] )

---
In theory, theory and practice are the same.  In practice, they're not.

Re: install-info: # fixme: send to FSF ?

[Ian Jackson]

Karl Eichwalder writes (in email to me):
> have you tried to submit install-info already?  I think it's absolutly
> worth to do so.  Last days I have had some discussion with package
> maintainers of GNU software.  All these maintainers are asking me to ask
> the Texinfo maintainer to include install-info.
> 
> Since it is you program I guess it is appropriate to ask you first.
> Thanks for the good work!  Karl.

Go for it, tell them to take it.  It's GPL'd, so there's no copyright
problem.

There is one problem foor us - install-info is part of our base (being
part of dpkg), and we can't move it into texinfo because it's needed
to install lots of other stuff.

I'm not sure how we should resolve that.

Ian.

Re: New ftp method for dselect

[Ian Jackson]

Dirk Eddelbuettel writes (supercite undone - iwj):
>[Ian Jackson writes:]
> >  Right.  In order to avoid having to rename lots of packages or change
> > their version numbers I propose the following naming scheme for files
> > on the FTP site in the `binary' directory:
> >   --[-].deb
> > Note the two hyphens.
> 
> Could such a measure be announced 24 to 48 hours in advance, and ideally be
> complemented by a script that can be used for renaming the files on the local
> tree?

Yes, of course.

> Otherwise folks like me will have to refetch about 110 Megabytes of */binary/*
> stuff. Not that much fun over a phone line. Some people even have to pay for
> every bytes they get through their phone.

Indeed.

Ian.

Re: New ftp method for dselect

[Ian Jackson]

Bill Mitchell writes ("Re: New ftp method for dselect"):
> dchanges(1) seems to parse distribution filenames OK, though the
> parsing code is pretty ugly.  If it's broken, please let me know.

"Seems to do it OK" isn't good enough - we need something unambiguous
and predictable.

Ian.

Re: New ftp method for dselect

[Ian Jackson]

David Engel writes ("Re: New ftp method for dselect"):
> OK, so package file names don't parse easily.  Why couldn't the cross
> reference be included in the Packages file?  It's needed by dselect
> anyway.  Also, what about packages like ld.so where the file name
> doesn't match the package name (ldso)?  What am I missing?

There already is a cross-reference in the Packages file.  However, the
dselect ftp method needs to be able to recognise what a file is even
in the gap between the file being moved into view and the Packages
file being updated.

Otherwise it would have to download it `on spec'.

Ian.

Bug#1995: run-parts on laptops

[Ian Jackson]

Raul Miller writes ("Re: Bug#1995: run-parts on laptops"):
> I think there's a good answer to this question, but I doubt the above
> workaround to the current package implementation of cron will occur to
> very many people.

How about taking cron out of rc*.d ?

Ian.

Re: Incoming file permissions

[Ian Jackson]

Dale Miller writes ("Incoming file permissions"):
> I noticed that some but not all of the new packages
> that get uploaded to the Incoming directory don't have
> read permissions. Is there a reason for this? Are they
> uploaded that way? I like to install the latest and
> greatest as quick as possible. I know, that could be asking
> for trouble but that's me. I am particularily interested
> in the dmalloc package that just came out but couldn't
> get it for the past couple of days. If there is a reason
> why it is like that then no problem. I was jsut curious
> why only part of the packages were uploaded that way.

The packages that come via my system are uploaded using rcp rather
than anon-ftp, and so have more standard default permissions.

Ian.

Re: Bug#2048: Broken pipe from dpkg to head

[Ian Jackson]

Bill Mitchell writes ("Bug#2048: Broken pipe from dpkg to head"):
> root:work# dpkg --info less*deb | head -1
>  old debian package, version 0.939000.
> Broken pipe

Richard Kettlewell writes ("Bug#2048: Broken pipe from dpkg to head"):
> [EMAIL PROTECTED]:richard$ ls -l | head -1
> total 19792
> Broken pipe
> [EMAIL PROTECTED]:richard$

Quite.

I'm marking this as done.

RTFM bash(1).

Ian.

Re: Package Verification

[Ian Jackson]

brian white writes ("Re: Package Verification "):
> This is fine, but it doesn't help with verifying packages on
> non-Debian systems as is required by people who must do an actual FTP
> >from  another machine.  As for the format, feel free to alter it.  I
> figured I would be parsing this line out of the Packages file, anyway.
> As long as it has file size, there is at least some sort of
> verification that can be done regardless of the machine being used.

I suppose we could put the file size in the Packages file; it just
might get a bit cluttered with all of this information.  What do
people feel about this ?

Ian.

Re: psutils ELF package release

[Ian Jackson]

Dale Scheetz writes ("psutils ELF package release"):
> As I have not yet obtained the upstream source, I have been unable to 
> create a diff file for this package (I had to fake out dchanges with a 
> fraud .diff.gz file).

Do not upload the package without a diff.  It's incomplete.  Please
get the original source - the debian.README says where.

>   It is my understanding (please correct me if I am 
> incorrect) that the .diff file is to reflect the difference between the 
> debian source and the original upstream source so that the original 
> source can be recreated from the debian source. Asside from the debian 
> control files this source is the same as the previous version.

No, the .diff is to build the Debian package from the source, and to
see what changed.

Ian M.: please don't move any of these packages with fake diffs.

Ian.

Re: New ftp method for dselect

[brian (b.c.) white]

(Replying to my own message -- bad, I know...)


>3) Both version-strings and package-names may contain dashes so dashes
>cannot be used to flawlessly determine where versions & revisions are.

I looked into this more closely and it seems that most of the packages
that once had dashes in the version stings are now gone.  If neither
the version nor revision strings can have dashes, then counting "-"'s
will break up the filename without having rename all the packages with
"--" in them.

Exceptions:  (the ones I saw, anyway)
stable/binary/net/bind-4.9.3-BETA24-1.deb
debian-1.0/binary/net/bind-4.9.3-BETA26-2.deb

Of course, this requires all fields to be present (including "revision")
even if they are not strictly neccessary (eg. "dpkg").


>4) Some packages (notably "dpkg") doesn't even have a revision number.
>If the primary people involved won't standardize the name on their own
>packages, don't count on it getting done.

Hmmm...  Reading this again it seems rather harsh.  My appologies!  It
was not intended as such.

C932 Unix Guru  Brian
x37930, Lab-3, 3F18
---
In theory, theory and practice are the same.  In practice, they're not.

Re: New ftp method for dselect

[Bill Mitchell]

 Ian Jackson <[EMAIL PROTECTED]> said:

> Bill Mitchell writes ("Re: New ftp method for dselect"):
> > dchanges(1) seems to parse distribution filenames OK, though the
> > parsing code is pretty ugly.  If it's broken, please let me know.
> 
> "Seems to do it OK" isn't good enough - we need something unambiguous
> and predictable.

No argument from me about that.  In the meantime I'll try to work with
what we've got, per ftp.debian.org:/debian/project/standards/Guidelines.

Re: ncurses-1.9.8a ELF release

[Ian Jackson]

> > > Let's say I have a package named foo-n with a shared library in it
> > > named libfoo.so.x.y that, at least for the time being, must always be
> > > available by that name, even while dpkg is moving things around.  Now,
> > > at some point in the future, I know that libfoo.so.x.y whill no longer
> > > be needed for any number of reasons.  What I'd like to be able to do
> > > after dpkg is done upgrading foo-n with foo-m, removing foo-n
> > > completely or replacing foo-n with bar-p, is have libfoo.x.y deleted,
> > > if and only if, no remaining package claims to own libfoo.x.y.  Can
> > > this be done, and if so, how?
> > 
> > "Claims to own"?  Do you mean "claims to need" ?
> 
> No!  By "own", I mean that the file belongs to a package and shows
> up when running "dpkg -L" on that package.  I'm assuming that dpkg's
> normal dependency checking won't allow the package to be removed while
> others still depend on/need it.

Ah, right.  In that case, the answer is that dpkg does this already -
but it does it (removes the old libfoo.x.y) before th the postinst
runs.

Plain files are oonly in one package at once.

> > What I meant was that, supposing you upgrade libc5 from 5.0.9-1 to
> > 5.2.7-1, you find that the old package contains libc.so.5.0.9 and the
> > new libc.so.5.2.7.  The link needs to be changed to point at 5.2.9
> > when *both* files are available, surely, as otherwise it will point
> > into nowhere for a bit ?
> 
> Now I'm confused.  That part of my message was in reference to your
> comment on category 1 packages where you contradicted yourself.  Did
> you mean category 2 instead?  Here is the relevant section from your
> earlier message:

Yes, I did mean categoory 2 instead.

Is this getting any clearer ? :-/

Ian.

Re: Bug#2048: Broken pipe from dpkg to head

[Bill Mitchell]

Ian Jackson <[EMAIL PROTECTED]> said:

> RTFM bash(1).

Thanks for the pointer, Ian.  I'm sure that you thought that
it would be very helpful

Unanswered problem reports by maintainer

[iwj10]

The following problem reports have not yet been marked as `taken up' by a
message to [EMAIL PROTECTED] or or `forwarded' by a
message to [EMAIL PROTECTED]

The maintainer listed against each package is derived from the Maintainer
field of the package as found in the development tree; there is an override
file that can be amended to get the right results if you have taken over a
package and do not expect to issue a new version soon.

Variant versions of the Maintainer field for the same actual package
maintainer will be listed separately.
 Package  Ref   Subject

Nils Rennebarth <[EMAIL PROTECTED]> (1 bugs):
 gpm  1669  shutdown hangs on gpm -k until mouse is moved

Martin Schulze <[EMAIL PROTECTED]> (1 bugs):
 syslogd   786  syslogd gone awol

Dirk Eddelbuettel <[EMAIL PROTECTED]> (1 bugs):
 acct 1737  missing man pages for accouting commands

Erick Branderhorst <[EMAIL PROTECTED]> (1 bugs):
 xypic1998  xypic-3.2-3 requires nonexistant packages.

[EMAIL PROTECTED] (D.J. Gregor) (1 bugs):
 gnuplot  1991  gnuplot has no 'fig' or 'bfig' terminal

[EMAIL PROTECTED] (Andrew D. Fernandes) (1 bugs):
 motifnls 1964  motifnls desc should say how useful it is for Mosaic & Nets

[EMAIL PROTECTED] (Guy R. Thomas) (1 bugs):
 dld  1488  dld control file dsccription problem

Kenneth MacDonald <[EMAIL PROTECTED]> (1 bugs):
 linuxdoc-s   1830  version of doc behind linuxdoc package

Matt Porter <[EMAIL PROTECTED]> (1 bugs):
 lrzsz1635  revision should be package_revision

Robert Sanders <[EMAIL PROTECTED]> (2 bugs):
 strace   1205  strace doesn't compile with newer kernel sources
 strace   1539  strace source package does not compile

[EMAIL PROTECTED] (David H. Silber) (2 bugs):
 fortune  1118  fortune is setuid games ?!
 uucp 1265  Misc. uucp bugs

Kenny Wickstrom <[EMAIL PROTECTED]> (2 bugs):
 tin  1619  tin depends on inn | inewsinn | inews
 tin  1753  trn recommends, instead of depends

Robert Read <[EMAIL PROTECTED]> (2 bugs):
 ftape1615  ftape package contains only source
 ftape1983  ftape source has wrong permissions

(orphan) (2 bugs):
 inewsinn 1441  `inewsinn' should provide virtual package
 inewsinn 1752  inewsinn recommends trn

Michael Alan Dorman <[EMAIL PROTECTED]> (2 bugs):
 minicom  1661  minicom should use /etc for config files
 minicom  1679  Minicom has default lockfile in /var/spool/uucp

Christian Linhart <[EMAIL PROTECTED]> (2 bugs):
 tgif 1821  tgif should read /etc/papersize
 xarchie  1857  xarchie doesn't honour default archie server setting

[EMAIL PROTECTED] (Robinson, Jim) (3 bugs):
 ifrench  1233  Bad french.hash file in ifrench.deb
 igerman, w   1793  german.hash has wron magic number
 wenglish  416  perl doesn't flush output automatically

David Engel <[EMAIL PROTECTED]> (3 bugs):
 expect   1836  expect core dumps
 snmp 1820  snmp postinst backgrounds start-stop-daemon ?
 snmp 1824  snmpd not killed by pre/post-rm, ignored SIGTERM

Helmut Geyer, [EMAIL PROTECTED] (3 bugs):
 ghostview1225  ghostviewR6 bad name, depends on xbaseR6, ghostviewR5 exist
 ghostview1963  ghostview desc has errant space in it
 xxgdb1231  xxgdbR6 bad name, depends on xbaseR6, xxgdbR5 exists

Alvar Bray <[EMAIL PROTECTED]> (3 bugs):
 man  1805  man package problem
 man  1841  man_db problems
 man  1897  apropos not resilient to index.db corruption

[EMAIL PROTECTED] (D.J. Gregor) (3 bugs):
 workbone 1381  workbone postinst fails
 workbone 1973  workbone postinst needs rewording
 workbone 1984  dpkg won't install cdtool

Giuseppe Vacanti <[EMAIL PROTECTED]> (4 bugs):
 diald1611  Diald 0.10 man pages
 diald1613  diald: minor typo in config-script
 diald1941  diald man page
 diald1942  /etc/services and diald

[EMAIL PROTECTED] (Bill Mitchell) (4 bugs):
 ae   1945  permissions ae-493/debian.rules
 git  1848  git gets SIGV
 indent850  [indent] option mentioned in documentation not supported
 mtools   1355  mformat does not work

Andrew Howell <[EMAIL PROTECTED]> (6 bugs):
 ksmbfs   2045  smb[u]mount not suid root
 rxvt 1161  rxvt manual page differs from implementation
 samba1946  nmbd won't browse
 tcsh  820  tcsh builtin `echo' doesn't check write errors
 xntp 2051  /etc/ntp.conf is an auto-handled conffile
 xtron1703  xtron documentation

Peter Tobias <[EMAIL PROTECTED]> (7 bugs):
 lpr   902  lpr can't print a PostScript file ?!
 lpr  1061  /etc/printcap vs. /usr/man/man5/printcap.5
 lpr  1923  lpr not de-installing
 netstd   1925  rusers causes segmentation fault
 netstd   2015  nfsd places a high load on named
 wu-ftpd  1872  wu-ftpd in CPU loop
 xwpe 1866  xwpe should depend on xcompat

Mike Deisher <[EMAIL PROTECTED]> (7 bugs):
 auto-pgp,1672  non-free p

Re: New ftp method for dselect

[Robert Leslie]

> Exceptions:  (the ones I saw, anyway)
>   stable/binary/net/bind-4.9.3-BETA24-1.deb
>   debian-1.0/binary/net/bind-4.9.3-BETA26-2.deb

If there are no objections I think I will rename the next version of the bind
package to something like:

bind-4.9.3BETA26-3.*

Hopefully this will be kinder to software needing to parse package names.

-- 
Robert Leslie
[EMAIL PROTECTED]

Re: /etc/rc.d and RedHat compatibility

[Marc Ewing]

[EMAIL PROTECTED] (Bruce Perens) writes:
> Right now, you can't expect it to be trouble-free, because there is no
> package conflict mechanism on redhat

True, we don't yet have a mechanism whereby you can indicate that
package X conflicts with package Y, but if package X would overwrite
any files in package Y, you'd get an error (warning, really) installing
X, and you'd have to force it.  We're working on conflicts and
dependencies in rpm version 2.

Of course, none of this works if the two packages come from different
package systems.

> Make a backup first.

Absolutely.

-Marc

Parsing package filenames (was: Re: New ftp method for dselect)

[Bill Mitchell]

"brian (b.c.) white" <[EMAIL PROTECTED]> said:

> I looked into this more closely and it seems that most of the packages
> that once had dashes in the version stings are now gone.  If neither
> the version nor revision strings can have dashes, then counting "-"'s
> will break up the filename without having rename all the packages with
> "--" in them.
> 
> Exceptions:  (the ones I saw, anyway)
>   stable/binary/net/bind-4.9.3-BETA24-1.deb
>   debian-1.0/binary/net/bind-4.9.3-BETA26-2.deb

Also:
Package: cern-httpd
Package: elv-fmt
Package: auto-pgp
Package: linuxdoc-sgml
Package: ncurses-runtime
Package: electric-fence
Package: boot-floppies
Package: ax25-kernel-source
Package: gopher-client
Package: w3-el
Package: arrl-infoserv
Package: elv-vi
Package: emacs-el
Package: elisp-manual
Package: mt-st
Package: ax25-util
Package: mh-papers
Package: ncurses-developer
Package: pgp-i
Package: pgp-us
Package: wu-ftpd
Package: elv-ctags

Personally, I also think we'll be better off if we bite the bullet and
try to maintain as much backwards compatability as we can with current
package naming usage than if we fall into a pattern of blowing off
backwards compatability issues in the interest of implementor convenience.

I believe that the vast majority of packages currently follow these
conventions:

filenames have the form --.
e.g.:   ab-cd-1.23a-45678.tar.gz
Field Separators:- - .
Field Contents: ab-cd 1.23a 45678 tar.gz

Reading from right to left:
EXT is currently either .deb, .changes, .tar.gz, .diff.gz.
It might be restricted to alphanumerics and '.' chars.
'.' currently separates REV from EXT
REV typically is numeric only.  It might be restricted to
alphanumerics.  There's been some talk of some packages
not providing this field, but it might be made mandatory.
'-' currently separates EXT from VER
VER typically contains numerics, but alphas and '.' chars
are not uncommon.  I think there's only one case of a
'-' in VER:  bind-4.9.3-BETA24-1.  The current convention,
not always followed 100.00%, is that VER should track the
upstream maintainer's version number.  We might relax this
to the extent of restricting VER to not contain any '-' chars.
'-' chars in upstream version numbers could be transliterated
to '.' or '_'.
'-' currently separates VER from PKG
PKG typically contains alphanumerics.  In some cases, it contains
'-' chars.  It's typically taken from the upstream source code
author's name, which could contain any printable chars.  This
cannot be restricted without relaxing the (IMO sensible)
convention that debian package names track the upstream package
name.  (That convention isn't followed in all cases.  Exceptions
generally occur when the a debian package is a split or a join
of upstream packages, and where multiple binary packages are
produced from a single source package.)

Counting from the end towards the front of the typical package filename
string, the first '-' encountered separates REV from VER.  Take that as a
reference point.

 -  Counting to the right from that point, the first '.' encountered
separates REV from EXT.  Whitespace to the right of EXT delimits it.
 -  Counting to the left from that point, the first '-' encountered
separates PKG from VER  Whitespace to the left of PKG delimits it.

That's a bit messy, but maintaining backwards compatability is often
messy.  Blowing off backwards compatability whenever maintaining
it gets inconvenient is a tempting option, but not something which
should not become a habit (IMHO).

Bug#2052: find over NFS

[Robert Leslie]

Package: cron
Version: 3.0pl1-21

The `checksecurity' script should probably ignore NFS filesystems, or at least
NFS filesystems which are mounted nodev && (nosuid || noexec).

Otherwise this can have miserable effects esp. when the path to the NFS server
crosses 14.4Kbps links.

--
Robert Leslie
[EMAIL PROTECTED]

Re: Package Verification

[Bruce Perens]

From: Ian Jackson <[EMAIL PROTECTED]>
> I suppose we could put the file size in the Packages file; it just
> might get a bit cluttered with all of this information.  What do
> people feel about this ?

I think a field with the size _and_ MD5 checksum on the same line would
be helpful. We don't collect this information anywhere else, to my knowledge.

Thanks

Bruce
--
Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios

Re: m4 ELF release

[Dale Scheetz]

As per several requests, and with help finding the upstream source from 
Ray, I have been able to create and upload to 
ftp.debian.org/debian/private/project/Incoming the diff file for the m4 
release 1.4 R2. 
Although this is a trivial diff file, this fulfills all the requirements 
for installation in the development path.
As soon as I can get the upstream packages for my other responsibilities, 
I will upload those diff files as well.

YHS,

Dwarf

Re: Bug#2048: Broken pipe from dpkg to head

[Bruce Perens]

I think Ian means that if the downstream program exits before the
upstream program, you'll get this message. Head is going to do that,
it's a feature.

I would like to maintain our reputation for gentle answers, thus "RTFM"
should be avoided, and "RTFM a 138K document" should not be considered
an answer :-) .
--
Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios

Re: Parsing package filenames (was: Re: New ftp method for dselect)

[Bruce Perens]

From: Bill Mitchell <[EMAIL PROTECTED]>
> Personally, I also think we'll be better off if we bite the bullet and
> try to maintain as much backwards compatability as we can with current
> package naming usage than if we fall into a pattern of blowing off
> backwards compatability issues in the interest of implementor convenience.

What programs are we talking about being compatible with? Not dselect or
dpkg, which don't care about the filename. I'd hazard that dchanges would
be easy to fix. Dftp would ask for the feature, as would the dselect
FTP method.

Am I missing something?

Thanks

Bruce
--
Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios

Re: Package Verification

[Bill Mitchell]

Bruce said, regarding Packages file info:

> I think a field with the size _and_ MD5 checksum on the same line would
> be helpful. We don't collect this information anywhere else, to my knowledge.

The sum(1) checksum might also be useful.  I know that sum(1) has been
characterized here as "totally useless", but I think that was overstatement.
The sum(1) checksum might be useful for someone in a situation where the
sum(1) program is conveniently available and the md5sum(1) program is not.

Re: Parsing package filenames (was: Re: New ftp method for dselect)

[Bill Mitchell]

[EMAIL PROTECTED] (Bruce Perens) said:

> From: Bill Mitchell <[EMAIL PROTECTED]>
> > Personally, I also think we'll be better off if we bite the bullet and
> > try to maintain as much backwards compatability as we can with current
> > package naming usage than if we fall into a pattern of blowing off
> > backwards compatability issues in the interest of implementor convenience.
> 
> What programs are we talking about being compatible with? Not dselect or
> dpkg, which don't care about the filename. I'd hazard that dchanges would
> be easy to fix. Dftp would ask for the feature, as would the dselect
> FTP method.

Yes, dchanges should be easy to change if naming conventions change.

> Am I missing something?

I didn't have specific programs in mind, actually.  I was thinking
in the general sense.  In a slightly specific sense, a change in package
naming conventions which is not backwards compatable with current
naming conventions might have substantial impact on any 2nd-generation
mirrors (and those 1st-generation mirrors which don't make special
arrangements to mitigate the impact) and/or might impact anyone
who has implemented package-naming sensitive local scripts for
whatever local-concern reason, working from our published packaging
guidelines and/or from inspection of our package naming patterns.

Re: Package Verification

[Bruce Perens]

I'd rather avoid the sum(1) checksum, because there are two implementations
of sum(1), the BSD and SYSV, that output different checksums for the same
data. Too many people will get confused when they see the wrong sum.

Bruce

--
Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios

Re: Parsing package filenames (was: Re: New ftp method for dselect)

[Bruce Perens]

Bill:
> a change in package
> naming conventions which is not backwards compatable with current
> naming conventions might have substantial impact on any 2nd-generation
> mirrors (and those 1st-generation mirrors which don't make special
> arrangements to mitigate the impact)

Yes. Well, we can warn them and make the cut-over at a well-defined time.
However, I would prefer not to promote the feeling that the file arrangement
is cast in concrete because of the mirrors.

> and/or might impact anyone
> who has implemented package-naming sensitive local scripts for
> whatever local-concern reason, working from our published packaging
> guidelines and/or from inspection of our package naming patterns.

I don't think they'll have tremendous problems. It's good that Brian
White publishes his script - otherwise we'd have more different ones
than we have now.

My feeling is that the longer we leave the problem un-solved, the worse
it's going to get. A clear statement of what will change from Ian Murdock,
with a date upon which FTP access will be turned off while the change takes
place, would ease most of the problems we expect to see. Of course, any
other FTP changes should take place at the same time - renaming of trees,
etc.

Thanks

Bruce
--
Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios

Bug#1995: run-parts on laptops

[Raul Miller]

Raul Miller:
   > I think there's a good answer to this question, but I doubt the
   > above workaround to the current package implementation of cron
   > will occur to very many people.

Ian Jackson:
   How about taking cron out of rc*.d ?

Plausible.

Remember, this is a space-cramped laptop.  Here, I wind up paying for
about 70k of storage to get a 6.7k executable.  [This is more an
administrative annoyance factor than a space issue.]

More importantly, as these rc*.d/???cron files aren't conffiles, this
loses every time you do a dselect install with a new cron-*.deb file
accessible.

Perhaps it's time to make a way of registering changes to
non-conffiles as "local-conffiles" in /var/lib/dpkg/status?

--
Raul

Re: Debian+umsdos (fwd)

[Raul Miller]

Simon Shapiro:
   And why do we want this brain dead file system (which even M$ does
   not use for its own 1980 eras OS's) to boot a Unix O/S with?

Please note that we shouldn't drop a user base just because Microsoft
has stopped supporting them.

More to the point, while "DOS" is a lousy operating system, it does
all right as a program loader.  It's certainly fancier than lilo [if
not as distributable.]

-- 
Raul

Re: Parsing package filenames (was: Re: New ftp method for dselect)

[Jim Freeman]

...
> filenames have the form --.
> e.g.:   ab-cd-1.23a-45678.tar.gz
> Field Separators:- - .
> Field Contents: ab-cd 1.23a 45678 tar.gz
...
>  -  Counting to the right from that point, the first '.' encountered
> separates REV from EXT.  Whitespace to the right of EXT delimits it.
>  -  Counting to the left from that point, the first '-' encountered
> separates PKG from VER  Whitespace to the left of PKG delimits it.

FWIW, _all_ RedHat (i386) packages conform to the regular expression

sed "/^${PKG}-[^-]*-[^-]*\.i386\.rpm$/p"`
 PKG - VER - REV . EXT

Re: Debian+umsdos (fwd)

[Raul Miller]

Richard Kettlewell:
   Actually I think it would be a good thing if we could support
   Debian entirely over UMSDOS - being able to run Linux without
   having to mess around repartitioning hard discs is going to make a
   lot of people a lot more willing to try it.

Unfortunately, UMSDOS isn't ready for prime time.

I've got a laptop with debian installed on a single umsdos partition.
It works if you don't push it too hard, but:

(1) the directory space sometimes drifts out of sync with the
underlying msdos file system.  [This can be real bad when you lose the
proper name on ld.so].

(2) the readdir mechanism for a single entry is O(n) where n is the
number of preceeding entries in the directory.  For example, at one
point I had a /dev where (cd /dev; echo *) took over a minute,
practically all of which was in readdir().

The umsdos code is ugly (my opinion) -- which is probably a
contributing factor for (1).

Personally, I think that umsdos should get a timestamp at boot-up, and
stamp it's --LINUX-.--- files with this number so it can tell if it's
in sync with dos or not.  The current system has too many compromises
between robustness and performance, and never really does a good job
of getting into sync.

-- 
Raul

Bug#2053: libjpeg doesn't have .so link for compiling...

[Michael Alan Dorman]

Package: libjpeg
Version: 6
Revision: 1

In order to be able to link with the shared library version of libjpeg,
the package needs to include a link from /usr/lib/libjpeg.so to
/usr/lib/libjpeg.so.6.

Mike.
--
"I'm a dinosaur.  Somebody's digging my bones."

apache

[Miquel van Smoorenburg]

Hmm. I think I'll have to subscribe to debian-devel real soon now,
(but not on this address!) chances are this has been beaten to death already..

> Date: Sun, 17 Dec 1995 11:57:04 -0500 (EST)
> From: Michael Alan Dorman <[EMAIL PROTECTED]>
> To: Chris Fearnley <[EMAIL PROTECTED]>
>
> cc: [EMAIL PROTECTED], Debian Developers <[EMAIL PROTECTED]>
> Subject: Re: ALPHA release of apache-1.0.0-1 now available
>
> * Should we create a new user and/or group to control access to the 
> hierarchy of html files?  If so, why don't we make it "official" and get 
> Bruce to include in the base /etc/group and /etc/passwd files.

Doesn't cern-httpd do this? I think it creates a group called "www-data".

> * Where should we put the html hierarchy?  I mean, they could exist on 
> /usr, since it doesn't per se matter if they're read-only or not, but it 
> that "right"?  A lot of places use /home/html or some such---I personally 
> don't think this is appropriate, but someone please tell me I'm wrong.

Well, my views on this are:
o a /var/httpd/htdocs for the documents
  Remember apache can be a server for multiple domains. That's why
  we need a 2-level directory structure; you might get
  /var/httpd/htdocs-customer2
  /var/httpd/htdocs-customer3
  as "htdocs" base directory for other virtual domains.
o cgi-bin:  /usr/lib/httpd/cgi-bin
o icons:/usr/lib/httpd/icons
o maintenance scripts:  /usr/lib/httpd/crons (or maint, whatever)
  (I have some nice ones)
o logfiles: /var/log/httpd/
  again, preferably not in /var/log itself because there might be
  lots of virtual domains.
o where do htpasswd & friends go? /usr/bin ? /usr/lib/httpd/bin ?

> We might also want to coordinate with Ted Hajek who maintains the cern httpd.
> Also, you might want to rename the package to apache-httpd and the 
> related directories and files, or you need to conflict with cern-httpd.

Yes, the config file for cern should be renamed to /etc/cern-httpd.conf (or
something); I usually have both servers running, cern as a proxy and apache
for the real work.

--
+ Miquel van Smoorenburg   + Cistron Internet Services +  Living is a |
| [EMAIL PROTECTED] (SP5) | Independent Dutch ISP |   horizontal |
+ [EMAIL PROTECTED]   + http://www.cistron.nl/+  fall+

Bug#1995: run-parts on laptops

[Bruce Perens]

Is there any point in establishing an init runlevel for "undocked" operation -
that is, using a laptop away from AC power? Some laptops are capable of sensing
when they go on and off of AC and could change the run level on their own.
I can think of situations where you would want cron to run when AC was
available.

Thanks

Bruce
--
Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios

new Perl with new sonames

[Darren/Torin/Who Ever...]

There is a new Perl in ftp://ftp.debian.org/debian/private/project/Incoming/
that uses the sonames in libdb1 (libdb.so.1) and libgdbm1
(libgdbm.so.1).  It has the proper requires line so it won't let you
install without them.

This version of perl also includes some doc updates and includes the
Safeperl module.

Here's the changes file:

Date: 19 Dec 95 21:27 UT
Source: perl
Binary: perl 
Version: 5.002-3
Description: 
 perl: Larry Wall's Practical Extracting and Report Language.
Priority: Low
Changes: 
 Uses the new sonames from libgdbm1 and libdb1
Files:
 -rw-r--r--   1 torinstaff 1337253 Dec 19 12:47 perl-5.002-3.tar.gz
 -rw-r--r--   1 torinstaff   43803 Dec 19 12:46 perl-5.002-3.diff.gz
 -rw-r--r--   1 root root  1696021 Dec 19 10:27 perl-5.002-3.deb
 e4185a9b00e54df96207324a3615369f  perl-5.002-3.tar.gz
 c4c4efffd22e94fd608a88b86b0b3982  perl-5.002-3.diff.gz
 579c5adb57c1e8bc110076d80dd1ff91  perl-5.002-3.deb

Linux Kernel 1.3.47 Uploaded

[Simon Shapiro]

Hi to all,

I uploaded kernel 1.3.47 to ftp.debian.org in /debian/private/project/Incoming.
In addition to the .changes, I should also mention the following:

1.  Some of the compilation is different than what Bruce has done.  Let
me know where the smoke comes from.
2.  I'd like to throw away the 387 emulation for the compiled kernel. 
Anyone knows why I should keep it there?  I do not believe it to be
necessary for the installation, but i have been wrong before.
3.  There is no PCMCIA support.  If someone will help me in Debianizing
the package, I'll maintain it and distribute it with the kernel (same
package or separate? - Polite opinions please).
4.  Ditto for the MD package,
5.  Ditto for kerneld
6.  Ditto for userfs

In few short weeks I'll be adding even more support for the Debian
project.  Stay tuned,

1.3.48 will be coming later this week or next week.  Promises to fix the
SCSi race conditions, etc.

Date: 20 Dec 95 02:24 UT
Source: kernel-source
Binary: image includes source 
Version: 1.3.47-0
Description: 
 image: Linux kernel binary image.
 includes: Linux kernel headers.
 source: Linux kernel source.
 This is patch level 47 of Linux kernel version 1.3.  As this is my
first relese of a 
 Debian package, I am sure I could do better.  For example, the diff
file is messed up.
 Please let me know how I can improve it...
Priority: Low
Changes: 
 Includes md (Linux RAID support) 0.32 kernel code. The utilities needed are
 not included here.  If someone wants to help me package them, I'll maintain 
 the package.  I am using MD on a daily basis and it runs great!
 The apricot Ethernet driver is too buggy to even remotely compile.  It is
 disabled.  I contacted the author (?) but no answer yet.  Any volunteers to 
 fix it are welcome.
 The drivers/scsi/hosts.c is slightly different than Linus's.  I moved eata_dma
 to the top of the list, followed by BusLogic.  This way those of you who have
 these controllers (I have both in nomis) will have them take /dev/sda, etc.
 I encountered the following problems with this release:
 a.  Under load the SCSI system will bark but it appears harmless.
 b.  X looses the mouse (some buttons).  Switch to VC 1 and back will get you
 the buttons.
 c.  If you have all-SCSI disks but IDE CD-ROM, expect lilo to fail;  It will 
 appear normal but upon boot it will report error 0x00 and will refuse to 
 boot anything.  Work around?  Build a kernel without any IDE support, put
 it on a floppy, boot rom it with mount=/dev/sda1, run lilo and all will be
 well.  until the next kernel build/lilo.  Any takers?
Files:
 -rw-r--r--   1 Source   Source3627753 Dec 19 18:23
kernel-source-1.3.47-0.tar.gz
 -rw-r--r--   1 Source   Source 20 Dec 19 18:17
kernel-source-1.3.47-0.diff.gz
 -rw-r--r--   1 root root  1403071 Dec 15 20:43 image-1.3.47-0.deb
 -rw-r--r--   1 root root   470893 Dec 15 18:50 includes-1.3.47-0.deb
 -rw-r--r--   1 root root  3603358 Dec 15 18:50 source-1.3.47-0.deb
 185ebe3c08728e87852003549abf2deb  kernel-source-1.3.47-0.tar.gz
 7a83dd7ad504f27d539b938e7001f89a  kernel-source-1.3.47-0.diff.gz
 ad485341f80fc5ba41283d0bb7781016  image-1.3.47-0.deb
 9f532e8fd08cdf40bb6fe26add0acf86  includes-1.3.47-0.deb
 04947c1aa85fd06303664db21333c406  source-1.3.47-0.deb


Simon

P.S.  Please ignore the below address and flame [EMAIL PROTECTED]
  He receives and answers mail :-)


Simon Shapiro   Bullet Technologies, Inc.
[EMAIL PROTECTED]  13130 SW Haystack St.
(503) 524-6631  Beaverton, OR 97005

Re: Parsing package filenames (was: Re: New ftp method for dselect)

[David Engel]

> ...
> > filenames have the form --.
> > e.g.:   ab-cd-1.23a-45678.tar.gz
> > Field Separators:- - .
> > Field Contents: ab-cd 1.23a 45678 tar.gz
> ...
> >  -  Counting to the right from that point, the first '.' encountered
> > separates REV from EXT.  Whitespace to the right of EXT delimits it.
> >  -  Counting to the left from that point, the first '-' encountered
> > separates PKG from VER  Whitespace to the left of PKG delimits it.
> 
> FWIW, _all_ RedHat (i386) packages conform to the regular expression
> 
>   sed "/^${PKG}-[^-]*-[^-]*\.i386\.rpm$/p"`
>PKG - VER - REV . EXT

Since I don't really have anything invested in this debate, I'll throw
in my last two cents and shut up.  It seems to me that changing the
very few packages which don't already conform to such a naming scheme
would be much less disruptive than renaming every package.

David
-- 
David EngelOptical Data Systems, Inc.
[EMAIL PROTECTED]  1101 E. Arapaho Road
(214) 234-6400 Richardson, TX  75081

Re: Linux Kernel 1.3.47 Uploaded

[~hiTomPrice . Andrew . Howell . at]

__ Reply Separator _
Subject: Linux Kernel 1.3.47 Uploaded
Author:  "Shimon"@[EMAIL PROTECTED]@MAILGW at DECPostmaster
Date:20/12/95 1:05 PM


>Hi to all,

>I uploaded kernel 1.3.47 to ftp.debian.org in /debian/private/project/Incoming.
>In addition to the .changes, I should also mention the following:

>2.  I'd like to throw away the 387 emulation for the compiled kernel. 
>Anyone knows why I should keep it there?  I do not believe it to be 
>necessary for the installation, but i have been wrong before.

That would be very bad, anyone with a 386 that doesn't have a 387 
wouldn't be able to use the Kernel, that would include 2 of our debian 
boxes.

Andrew

Please note my reply address is quite likely corrupt. Please mail to 
[EMAIL PROTECTED] (CCMail gateways really suck)

Re: ncurses-1.9.8a ELF release

[David Engel]

> > Now I'm confused.  That part of my message was in reference to your
> > comment on category 1 packages where you contradicted yourself.  Did
> > you mean category 2 instead?  Here is the relevant section from your
> > earlier message:
> 
> Yes, I did mean categoory 2 instead.
> 
> Is this getting any clearer ? :-/

Slowly.  I've been trying to better understand how dpkg works and find
a way to do what I want with the current behaviour.  The only way I've
come up with is rather ugly and probably error prone so I haven't even
bother to hash it all out.  If you'll answer me a couple of questions,
I'll try to come up with a cleaner way that would only require a
minimum of changes to dpkg.  Here they are:

Can, and if so how, dpkg/dselect remove one package and replace it
with another in one invocation?

Does dpkg/dselect allow a package to be upgraded or replced with
another and then left in an unconfigured state?

Basically, what I'm concerned with is the time between an old
package's postrm script being called and any new package's postinst
being called.

David
-- 
David EngelOptical Data Systems, Inc.
[EMAIL PROTECTED]  1101 E. Arapaho Road
(214) 234-6400 Richardson, TX  75081

Re: why doesn't binutils-2.6-1 provide a shared library?

[David Engel]

> Shouldn't binutils-2.6 provide a shared bfd library?
> It used to in 2.5.2l.20-2?  I'm asking here instead of posting a bug
> because I remember there being some  discussion about this a little
> while back.

It could.  There is already some support for it in the Makefiles.  I
chose to leave it for the eventual maintainer to add since it has
packaging and support ramifications.  BTW, I did the same for libg++.

> Also, why is it that I can do an 'nm libname.so' on some shared
> libraries but not on others:

The -D option is now needed to list the dynamic symbols in a shared
library that can not be stripped.  You'll have to ask the binutils
developers why they did this.

David
-- 
David EngelOptical Data Systems, Inc.
[EMAIL PROTECTED]  1101 E. Arapaho Road
(214) 234-6400 Richardson, TX  75081

Re: Linux Kernel 1.3.47 Uploaded

[Bill Mitchell]

On Tue, 19 Dec 1995, Simon Shapiro wrote:

> 2.  I'd like to throw away the 387 emulation for the compiled kernel. 
> Anyone knows why I should keep it there?  I do not believe it to be
> necessary for the installation, but i have been wrong before.

I'm typing this on a machine with a bare 386 and no 387.  I note
that the Kernel HOWTO in /usr/doc says that, with this configuration,
the question about Kernel math emulation must be answered 'y'. Is
that now outdated?

Re: Debian+umsdos (fwd)

[Simon Shapiro]

OK!  I submit.  I was wrong.

FAT is great for loading and booting floppies.

I still maintain that it is a disaster for any serious OS as a storage
medium.  Even when we fake users and permissions.

I am stubborn in a way :-)



Simon

P.S.  Please ignore the below address and flame [EMAIL PROTECTED]
  He receives and answers mail :-)


Simon Shapiro   Bullet Technologies, Inc.
[EMAIL PROTECTED]  13130 SW Haystack St.
(503) 524-6631  Beaverton, OR 97005