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 PROTECT
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 an
> 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 f
> > 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 getti
__ 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
> ...
> > 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
> > separ
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 3
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
Saf
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 A
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 PR
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."
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 rea
...
> 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 EX
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 operati
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. He
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 war
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
[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
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
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 inte
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 a
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 installati
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 coll
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
[
"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 withou
[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
> 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
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 ov
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
> > > 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 lon
(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 versio
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 th
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 somethin
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
> B
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 poss
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
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.
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 (
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.
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
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 insta
>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. M
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 wh
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.
He
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
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 unde
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 fr
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 p
> 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.
> 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: devel
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
(R
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 cur
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.
Feedb
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
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
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 debia
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.
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
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
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
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
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 -
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/
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
64 matches
Mail list logo
