Re[2]: Linux Kernel 1.3.47 Uploaded

1995-12-20 Thread ~hiTomPrice . Andrew . Howell . at
__ Reply Separator _ Subject: Re: Linux Kernel 1.3.47 Uploaded Author: mitchell@[EMAIL PROTECTED]@MAILGW at DECPostmaster Date:20/12/95 3:31 PM On Tue, 19 Dec 1995, Simon Shapiro wrote: 2. I'd like to throw away the 387

Re: Linux Kernel 1.3.47 Uploaded

1995-12-20 Thread Stephen Early
On Wed, 20 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. The kernel will not boot on systems that don't

Re: ALPHA release of apache-1.0.0-1 now available

1995-12-20 Thread Darren/Torin/Who Ever...
Chris Fearnley [EMAIL PROTECTED], in a magnificent manifestation of deity, wrote: 'Michael Alan Dorman wrote:' On Sun, 17 Dec 1995, Chris Fearnley wrote: This is a preliminary release. It seems to work, but I'm disatisfied with my handling of httpd configuration (basically there is none - you

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

1995-12-20 Thread Darren/Torin/Who Ever...
[EMAIL PROTECTED] (David Engel), in a magnificent manifestation of deity, wrote: 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++. Who's going

Bug#1951: perl is not exportable from the US

1995-12-20 Thread Darren/Torin/Who Ever...
Michael E. Deisher [EMAIL PROTECTED], in a magnificent manifestation of deity, wrote: Package: perl (elf-perl, actually) Version: 5.001 Revision: 5 Perl contains a working crypt function and thus cannot be legally exported from the US (someone correct me if I'm wrong). Probably, the crypt

Bug#1972: perl should suggest kernel sources

1995-12-20 Thread Darren/Torin/Who Ever...
Austin Donnelly [EMAIL PROTECTED], in a magnificent manifestation of deity, wrote: Package: perl Version: 5.001-4 Perl should suggest kernel sources, rather than grumble in postinst later. fixed. Darren [EMAIL PROTECTED] http://www.daft.com/~torin/[EMAIL PROTECTED] [EMAIL PROTECTED]

Re: Where are the bugs?

1995-12-20 Thread Martin Schulze
Good morning Ian! }Martin Schulze writes (Where are the bugs?): } I'm missing bugs. In fact on ftp.debian.org /debian/debian-bugs/text } only bugreports up to #1810 do exist. Where are newer ones? } }We're working on it. The US bugs mirror is broken atm - use the UK }site instead. No problem,

Bug#2054: no subject (file transmission)

1995-12-20 Thread Tuomas J Lukka
Package: latex,xdvik Version: 2e-4, 18f-4 LaTeX + Xdvi + dvips cannot do a umlauts. A simple latex file was made with some \a s in it and they did not show up on xdvi as a umlauts, they were missing altogether. Using debian 0.93R6, kernel 1.2.13, libc4.6.27 Tuomas

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

1995-12-20 Thread brian (b.c.) white
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

lib{db,gdbm,readline}: important bugfixes

1995-12-20 Thread J.H.M.Dassen
These packages fix nasty bugs with regard to upgrading. IMPORTANT: 1. prior to upgrading, remove the prerm scripts from the previous versions as follows: rm -f /var/lib/dpkg/info/lib{db1,gdbm1,readline2}.prerm 2. libgdbm1 breaks older perl and man packages, due to a soname error in a

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

1995-12-20 Thread David Engel
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++. Who's going to be the maintainer? I'd want to talk with them some about it. Siggy

lib{db,gdbm,readline}: some more fixes

1995-12-20 Thread J.H.M.Dassen
These packages fix nasty bugs with regard to upgrading; some other (minor) problems are fixed. IMPORTANT: 1. prior to upgrading, remove the prerm scripts from the previous versions as follows: rm -f /var/lib/dpkg/info/lib{db1,gdbm1,readline2}.prerm 2. libgdbm1 breaks older perl and man

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

1995-12-20 Thread Fernando Alegre
On Tue, 19 Dec 1995, Bruce Perens wrote: [...] 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

Bug#2055: Mirror: two problems using files for associative arrays

1995-12-20 Thread Michael Alan Dorman
Package: mirror Version: 2.8 Revision: 0 I'm sending this as a debian problem report and to the mirror list. The first, and less important issue is that due to a typo in the mirror.pl file, mirror stores temporary files in / when using associative arrays to store information about local and

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

1995-12-20 Thread Bill Mitchell
Fernando Alegre [EMAIL PROTECTED] said: [...] the whole sunsite and tsx archives, which store packages with an almost standard format. Even though they are not Debian packages right now, some (many?) could be in the future. And the debianized name should be as close to the upstream name

Reorganize Debian tree (was: Parsing package filenames)

1995-12-20 Thread Fernando Alegre
I was thinking about the parsing problem and I had a new idea, which I think would be the best solution. What I think is needed is a reorganization of the Debian tree so that under the root tree for the distribution we have: (root-tree)/Section/Standard Package name/files(binaries and sources)

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

1995-12-20 Thread brian (b.c.) white
A mostly-compatable compromise would seem to be: [...] Extension: May contain any printable chars. If the extension can contain dashes, once again it could cause parsing problems. Eliminating dashes (or dots, for that matter) here would again make it fit into a regular expression.

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

1995-12-20 Thread Siggy Brentrup
Darren == Darren/Torin/Who Ever [EMAIL PROTECTED] writes: Darren [EMAIL PROTECTED] (David Engel), in a magnificent manifestation of deity, wrote: It could. There is already some support for it in the Makefiles. I chose to leave it for the eventual maintainer to add since

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

1995-12-20 Thread Bill Mitchell
brian (b.c.) white [EMAIL PROTECTED] said: If the extension can contain dashes, once again it could cause parsing problems. Eliminating dashes (or dots, for that matter) here would again make it fit into a regular expression. Yup. Thanks for pointing that out. EXT should disallow dashes.

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

1995-12-20 Thread brian (b.c.) white
Yup. Thanks for pointing that out. EXT should disallow dashes. The following seems to (slowly) parse all packages in a fairly old available file which I have handy as is apparently intended by the debian package maintainer, with the exception of elisp-manual-19-2.4-1.tar.gz (is -19

Bug#2056: Mirror: two problems using files for associative arrays

1995-12-20 Thread Lee McLoughlin
Thanks for the patches. I'd already fixed up the big_tmp ones, I'd missed the unlink_dbm problem. I'll make sure they go into verion 2.0 -- -- Lee McLoughlin. Phone: +44 171 594 8388 Dept of Computing, Imperial College, Fax: +44 171 584 8301 180 Queens Gate,

gmp ELF release complete

1995-12-20 Thread Dale Scheetz
Having obtained the source for gmp-1.2.3 I have been able to create the required diff file. All files have now been uploaded to ftp.debian.org/debian/private/project/Incoming and are complete. Here is the .changes file: Date: 20 Dec 95 22:08 UT Source: gmp Binary: gmp Version: 1.3.2-2

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

1995-12-20 Thread Raul Miller
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. Also, a cheap

Bug#1995: run-parts on laptops

1995-12-20 Thread Raul Miller
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

Bug#1995: run-parts on laptops (fwd)

1995-12-20 Thread Miquel van Smoorenburg
You (Raul Miller) wrote: 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

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

1995-12-20 Thread Bruce Perens
Someone (David?) said: 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. From: Raul Miller [EMAIL PROTECTED] Also, a cheap workaround for any existing dependency problems would be