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
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 -
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.
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
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
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
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
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
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'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.
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
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
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
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
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
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
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
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
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.
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
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.
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
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:
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.
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
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.
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.
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
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
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
(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
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
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
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
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
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
[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
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
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
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
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
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
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
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
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
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.
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
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
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.
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
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
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
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
...
filenames have the form PKG-VER-REV.EXT
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
__ 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.
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
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
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
58 matches
Mail list logo
