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

[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
> a Provides: entry with the old package name.

I we can either rename existing packages, or use the double-dash. I don't
care which. We must, however, make a decision reasonably soon. One of the
biggest problems of Debian, and the one that still may cause it to fail,
is it's design-by-committee nature. If we are to argue this issue for three
weeks, we'd might as well quit now.

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

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

[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 situations
>where you would want cron to run when AC was available.
> 
> This sounds like a neat concept.  Run-levels are rather limitted, but
> this seems to fit in with existing uses of the concept.

It would be trivial to add runlevels 7, 8 and 9 to init-
I'll do that in the next release (just change a few checks here and
there).

-- 
  Miquel van| Cistron Internet Services   --Alphen aan den Rijn.
  Smoorenburg,  | mailto:[EMAIL PROTECTED]  http://www.cistron.nl/
[EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)

Bug#1995: run-parts on laptops

[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 cron to run when AC was available.

This sounds like a neat concept.  Run-levels are rather limitted, but
this seems to fit in with existing uses of the concept.

I don't suppose there's any sort of run-level registry anywhere?

--
Raul

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

[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 workaround for any existing dependency problems would be
a Provides: entry with the old package name.

-- 
Raul

gmp ELF release complete

[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
Description: 
 gmp: Multiprecision arithmetic library
Priority: Low
Changes: Built as ELF
Files:
 -rw-r--r--   1 root src317951 Dec 19 08:10 gmp-1.3.2-2.tar.gz
 -rw-r--r--   1 root src 11209 Dec 20 17:07 gmp-1.3.2-2.diff.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
 e7ca90a22fa12c481ea9cc87a6ff43c7  gmp-1.3.2-2.diff.gz
 a64b6ab7c1cf37af944ad7680cee  gmp-1.3.2-2.deb

Dwarf

  --

aka   Dale Scheetz   Phone:   1 (904) 877-0257
  Flexible Software  Fax: NONE 
  Black Creek Critters   e-mail:  [EMAIL PROTECTED]

 If you don't see what you want, just ask --

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

[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, London, SW7 2BZ, UK.Email: [EMAIL PROTECTED]

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

[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" part of Name or Veraion?)

19 is (I believe) part of the package name.

>  lrzsz-0.11.tar.gz(Revision? Should be lrzsz-0-11.tar.gz?)
>  ?bind-4.9.3-BETA24-1.tar.gz   (change to bind-4.9.3_BETA24-1.tar.gz?)

There is also "dpkg-1.0.5.deb" which has no revision.  It isn't strictly
neccessary and so has been left out.  In order to use this scheme, such
packages would have to include a dummy revision of "-0" or something.

>for FILE in $*
>do
>TOKENS=`echo $FILE | \
>sed -e 's/\(.*\)-\([^-]*\)-\([^.]*\)\.\([^-]*\)$/\1 \2 \3 \4/'`

You might want "[^.-]" here---

>PKG=`echo $TOKENS | cut -d' ' -f1`
>VER=`echo $TOKENS | cut -d' ' -f2`
>REV=`echo $TOKENS | cut -d' ' -f3`
>EXT=`echo $TOKENS | cut -d' ' -f4`
>echo "$PKG  $VER$REV$EXT"
>done

I don't see how to accelerate your regex, but you can accelerate the
loop by forking as few external process as possible.  eg:

Run sed only once:
for FILE in `sed -e '.' FileOfPackagesOnePerLine`
(be sure to put something besides spaces (like ",") between the different
pieces or each piece will pass through the loop)

Break the tokens up in one shot and use shell operators:
set pkg = ( `echo $file | sed -e 's|,| |g'` )
if ($#pkg != 3) then
echo "Error: bad file $file"
continue
endif
set nam = $pkg[1]
set ver = $pkg[2]
set rev = $pkg[3]
(the above is csh code...  sorry!)

Brian
 ( [EMAIL PROTECTED] )

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

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

[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.

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

  gopher-client-"2.1.1"-"2".tar.gz (spurious quotes)
  gopherd-"2.1.1"-"2".tar.gz   (spurious quotes)
  elisp-manual-19-2.4-1.tar.gz (is "-19" part of Name or Veraion?)
  lrzsz-0.11.tar.gz(Revision? Should be lrzsz-0-11.tar.gz?)
   bind-4.9.3-BETA24-1.tar.gz   (change to bind-4.9.3_BETA24-1.tar.gz?)

for FILE in $*
do
TOKENS=`echo $FILE | \
sed -e 's/\(.*\)-\([^-]*\)-\([^.]*\)\.\([^-]*\)$/\1 \2 \3 \4/'`
PKG=`echo $TOKENS | cut -d' ' -f1`
VER=`echo $TOKENS | cut -d' ' -f2`
REV=`echo $TOKENS | cut -d' ' -f3`
EXT=`echo $TOKENS | cut -d' ' -f4`
echo "$PKG  $VER$REV$EXT"
done

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

[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 it has packaging and support ramifications.  BTW, I
>> did the same for libg++.

I am about to maintain Debian's gcc & friend packages as soon I am
finished downloading to get David's packages, which I tried since he
announced their availability, but due to ba tranatlantic links I never
managed to get more than an MB and that at approx 100cps.

With the ALPHA-TEST tree now being available on european mirrors, I
expect to be up to speed sometime tomorrorw. 

Darren> Who's going to be the maintainer?  I'd want to talk with
Darren> them some about it.

While I'm open to suggestions, please give me a chance to look at
what's there before expecting me to comment on these issues.

>> 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.

Darren> Ick.  Would that be of the GNU package or of the linux shared 
library
Darren> specs (gcc folks).

Thanks
  Siggy

-- 
email: [EMAIL PROTECTED]   // programmer/*nix admin for hire
   [EMAIL PROTECTED] \\  Opinions are strictly my own,
voice: +49-251-8619-99\\  everything else is GPLed
Mime(RFC1521) encoded messages welcome \\  http://coming.soon/

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

[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.

Brian
 ( [EMAIL PROTECTED] )

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

Reorganize Debian tree (was: Parsing package filenames)

[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)///files(binaries and sources)

For example: /debian-1.1/base/bash/bash-1.14.4-3.deb
   bash-1-14.4-3.tar.gz
   bash-1.14.4-3.diff.gz
   bash-1.14.4-3.changes
   bash-1.14.4-3.README (if needed)

That way, there is absolutely no need to parse the version number, nor it 
is necessary to modify the file name, which in my opinion could even 
raise a concern about copyright infringements for some packages.
The mirrors interested in binaries only would discard packages not ending 
in ".deb". That's all they would need to parse. And since moving packages 
to their location is done manually anyway, the new arrangement would make 
it even easier for Ian Murdock (isn't it him?) to move them, because 
maintainers usually upload all those files together.

I think this solution is clean and easy for both archive maintainers and 
people who mirror it.

Maybe the revision number, which is Debian-specific, could be made 
mandatory so that debian binary packages would end in "\.\d+\.deb" 
instead of "\.deb". We really don't need to be able to parse the version 
number. We just need to know which package is provided by each file, and 
a good way to make it explicit is to place the file under a directory 
named after the standard package name that the file provides.

Is there a less expensive (in terms of work involved) or a clearer 
solution (which does not confuse people not familiar with Debian)?
I don't think so, but you could prove me wrong.

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

[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 as possible. 
> Adding a revision number between the package-and-version block and the 
> extension (almost always tar.gz or tgz) is OK, but touching something 
> within the package-and-version block (which was chosen by the original 
> author) seems to me as an intrusion.

That sounds like a very good point.  Also, most current packages probably
already conform to this.

One major difference between this and our current naming scheme is that
this leaves open the possibility of a non-'-' separator, or no separator
at all, between package and version, while we presently require a '-'.
Another major difference is that Version does not seem to be guaranteed
to be machine-parseable from package-and-version.

I think having the upstream version as a separate and identifiable
field is probably too deeply ingrained into our package handling
procedures to consider changing that at this point.

A mostly-compatable compromise would seem to be:

  Package-Version-Revision.Extension

  Package:   Retained unchanged.  May contain any printable chars.

 Maintainer makes a judgement regarding the separation
 of the upstream package and version fields.  If they're
 not separated by a '-' in the upstream package-and-version
 field, maintainer mangles the package-and-version field
 from upstream to debianize it as package-version.

  Version:   Debian package naming conventions forbid embedded '-'
 chars in version numbers.  Maintainer mangles the
 upstream version number as necessary to eliminate any
 of these.  Most packages should not need to have their
 upstream package-and-version field mangled, but some will.

  Revision:  Added by debian package maintainer.  Usually numeric,
 but may contain any printable chars except '.'.

  Extension: May contain any printable chars.

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

[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 remote filesets.

The fix is simple:  Look for the two instances of the string "$big_tmp"
and replace them with "$big_temp", which is the variable that should be
being used.

The second, and much more important issue, is that mirror doesn't always
correctly delete those dbm files.

Once #1 is corrected, mirror creates /var/tmp/(remote|local)_map.X using
dbmopen ( ).  Unfortunately, when it goes to get rid of it, it assumes
that there will be two files, one *.pag and one *.dir.  At least with my
copy of perl, this is an incorrect assumption --- the file name given is
the file name used (I think this means I'm using Berkeley db).

Here's a patch that should take care of both of these (though the patch
for problem #2 is still non-optimal, since it still assumes knowledge of
the file name, but I didn't see any other way to do it).

->8-
*** mirror.pl   Tue Oct 31 15:31:30 1995
--- /usr/lib/mirror/mirror.pl   Wed Dec 20 10:38:47 1995
***
*** 3228,3234 

&msg( "creating assocs ...\n" ) if $debug > 2;
foreach $map ( @assocs ){
!   eval "\$$map = \"\$big_tmp/$map.$$\"";
eval "dbmopen( $map, \$$map, 0644 )";
}
&msg( "creating assocs done\n" ) if $debug > 2;
--- 3228,3234 

&msg( "creating assocs ...\n" ) if $debug > 2;
foreach $map ( @assocs ){
!   eval "\$$map = \"\$big_temp/$map.$$\"";
eval "dbmopen( $map, \$$map, 0644 )";
}
&msg( "creating assocs done\n" ) if $debug > 2;
***
*** 3240,3246 

&msg( "deleting assocs ...\n" ) if $debug > 2;
foreach $map ( @assocs ){
!   eval "\$$map = \"\$big_tmp/$map.$$\"";
eval "dbmclose( $map )";
&unlink_dbm( eval "\$$map" );
eval "\%$map = ()";
--- 3240,3246 

&msg( "deleting assocs ...\n" ) if $debug > 2;
foreach $map ( @assocs ){
!   eval "\$$map = \"\$big_temp/$map.$$\"";
eval "dbmclose( $map )";
&unlink_dbm( eval "\$$map" );
eval "\%$map = ()";
***
*** 3251,3258 
  sub unlink_dbm
  {
local( $file ) = @_;
!   unlink "$file.pag";
!   unlink "$file.dir";
  }

  # Chop the tmp file up
--- 3251,3259 
  sub unlink_dbm
  {
local( $file ) = @_;
!   unlink "$file.pag" if -e "$file.pag";
!   unlink "$file.dir" if -e "$file.dir";
!   unlink "$file" if -e "$file";
  }

  # Chop the tmp file up
-8<-

Enjoy,

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

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

[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 something?

Yes, I think you are missing 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 as possible. 
Adding a revision number between the package-and-version block and the 
extension (almost always tar.gz or tgz) is OK, but touching something 
within the package-and-version block (which was chosen by the original 
author) seems to me as an intrusion.

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

[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 packages, due to a soname error in 
   a previous version. 

Feedback is appreciated at [EMAIL PROTECTED]

Greetings,
Ray


Date: 20 Dec 95 15:32 UT
Source: libdb
Binary: libdb1 libdb1-dev 
Version: 1.85.2-5
Description: 
 libdb1: the Berkeley database routines (runtime version).
 libdb1-dev: the Berkeley database routines (development files).
Priority: Low
Changes: 
 * Produce correct diffs. Noted by Rolf Russios <[EMAIL PROTECTED]>
Files:
 -rw-r--r--   1 root root   274143 Dec 20 16:32 libdb-1.85.2-5.tar.gz
 -rw-r--r--   1 root root  549 Dec 20 16:32 libdb-1.85.2-5.diff.gz
 -rw-r--r--   1 root root33640 Dec 20 16:31 libdb1-1.85.2-5.deb
 -rw-r--r--   1 root root   164863 Dec 20 16:32 libdb1-dev-1.85.2-5.deb
 2fa3c03e6aca13581118bb327c570004  libdb-1.85.2-5.tar.gz
 ff0e1fe76845ec376cd7c3d0b9c4b901  libdb-1.85.2-5.diff.gz
 0892f8f663329cf505cfb0439dff0277  libdb1-1.85.2-5.deb
 95b227c0547ef96e58b98b058e744202  libdb1-dev-1.85.2-5.deb


Date: 20 Dec 95 12:28 UT
Source: libgdbm
Binary: libgdbm1 libgdbm1-dev 
Version: 1.7.3-7
Description: 
 libgdbm1: GNU dbm database routines (runtime version).
 libgdbm1-dev: GNU dbm database routines (development files)
Priority: Low
Changes: 
 * Fixed serious problem with upgrades. Noted by David Engel <[EMAIL 
PROTECTED]>.
 * Added Section: field to devel control file.
 * Added orig target to debian.rules and modified diff target.
 * Fixed dependency.
 * Added conflicts for perl and man version that were linked with the wrong
   .so version.
Files:
 -rw-r--r--   1 root root83330 Dec 20 13:28 libgdbm-1.7.3-7.tar.gz
 -rw-r--r--   1 root root   20 Dec 20 13:28 libgdbm-1.7.3-7.diff.gz
 -rw-r--r--   1 root root13382 Dec 20 13:28 libgdbm1-1.7.3-7.deb
 -rw-r--r--   1 root root28332 Dec 20 13:28 libgdbm1-dev-1.7.3-7.deb
 f30fc3c48071a62ee53a05e56fe932af  libgdbm-1.7.3-7.tar.gz
 ba8892547f07e6a1a0d64210555ef57f  libgdbm-1.7.3-7.diff.gz
 799118306bf5a0181d4beb5a24afae93  libgdbm1-1.7.3-7.deb
 a7bdd31ba8db64fc8e3ee0cce21d0d5d  libgdbm1-dev-1.7.3-7.deb


Date: 20 Dec 95 15:18 UT
Source: libreadline
Binary: libreadline2 libreadline2-dev 
Version: 2.0-12
Description: 
 libreadline2: GNU readline and history libraries, runtime versions.
 libreadline2-dev: GNU readline and history libraries. Development versions.
Priority: Low
Changes: 
 * Fixed bug in debian.rules that caused a link not to be made;
   make correct diff. Noted by Rolf Rossius <[EMAIL PROTECTED]>
Files:
 -rw-r--r--   1 root root   408704 Dec 20 16:18 
libreadline-2.0-12.tar.gz
 -rw-r--r--   1 root root 4494 Dec 20 16:18 
libreadline-2.0-12.diff.gz
 -rw-r--r--   1 root root64525 Dec 20 16:18 libreadline2-2.0-12.deb
 -rw-r--r--   1 root root   113060 Dec 20 16:18 
libreadline2-dev-2.0-12.deb
 b02bea3b2eb591bffa55a26e9347dbfb  libreadline-2.0-12.tar.gz
 5c951990547da6515b3766c5b18f4766  libreadline-2.0-12.diff.gz
 aa61e48d127a62f3c6562fb87879a8d9  libreadline2-2.0-12.deb
 f9971c4bb5590af96015ff9619ff64f5  libreadline2-dev-2.0-12.deb
-- 
Cyberspace, a final frontier. These are the voyages of my messages, 
on a lightspeed mission to explore strange new systems and to boldly go
where no data has gone before. 

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

[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 Brentrup ([EMAIL PROTECTED]) has volunteered, but the last I
heard, he was still having network problems.

> >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.
> 
> Ick.  Would that be of the GNU package or of the linux shared library
> specs (gcc folks).

The GNU folks.

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

lib{db,gdbm,readline}: important bugfixes

[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 previous version. 

Feedback is appreciated at [EMAIL PROTECTED]

Greetings,
Ray

Date: 19 Dec 95 19:39 UT
Source: libdb
Binary: libdb1 libdb1-dev 
Version: 1.85.2-4
Description: 
 libdb1: the Berkeley database routines (runtime version).
 libdb1-dev: the Berkeley database routines (development files).
Priority: High
Changes: 
 * Fixed serious problem with upgrades. Noted by David Engel <[EMAIL 
PROTECTED]>.
 * Correct dependency for runtime version
 * Added Section: field to devel control file
 * Added orig rule to debian.rules; modified diff rule.
Files:
 -rw-r--r--   1 root root   274084 Dec 19 20:39 libdb-1.85.2-4.tar.gz
 -rw-r--r--   1 root root   20 Dec 19 20:39 libdb-1.85.2-4.diff.gz
 -rw-r--r--   1 root root33648 Dec 19 20:39 libdb1-1.85.2-4.deb
 -rw-r--r--   1 root root   164879 Dec 19 20:39 libdb1-dev-1.85.2-4.deb
 dd1470d6b0532f3d85b81ec6de105c58  libdb-1.85.2-4.tar.gz
 b2df81c6f67a744b0e3ebff3793a91bf  libdb-1.85.2-4.diff.gz
 f7d20d091291d5734693266bc6a4fe05  libdb1-1.85.2-4.deb
 ac0d629a22caf9743222b5799bd2377a  libdb1-dev-1.85.2-4.deb


Date: 20 Dec 95 12:28 UT
Source: libgdbm
Binary: libgdbm1 libgdbm1-dev 
Version: 1.7.3-7
Description: 
 libgdbm1: GNU dbm database routines (runtime version).
 libgdbm1-dev: GNU dbm database routines (development files)
Priority: Low
Changes: 
 * Fixed serious problem with upgrades. Noted by David Engel <[EMAIL 
PROTECTED]>.
 * Added Section: field to devel control file.
 * Added orig target to debian.rules and modified diff target.
 * Fixed dependency.
 * Added conflicts for perl and man version that were linked with the wrong
   .so version.
Files:
 -rw-r--r--   1 root root83330 Dec 20 13:28 libgdbm-1.7.3-7.tar.gz
 -rw-r--r--   1 root root   20 Dec 20 13:28 libgdbm-1.7.3-7.diff.gz
 -rw-r--r--   1 root root13382 Dec 20 13:28 libgdbm1-1.7.3-7.deb
 -rw-r--r--   1 root root28332 Dec 20 13:28 libgdbm1-dev-1.7.3-7.deb
 f30fc3c48071a62ee53a05e56fe932af  libgdbm-1.7.3-7.tar.gz
 ba8892547f07e6a1a0d64210555ef57f  libgdbm-1.7.3-7.diff.gz
 799118306bf5a0181d4beb5a24afae93  libgdbm1-1.7.3-7.deb
 a7bdd31ba8db64fc8e3ee0cce21d0d5d  libgdbm1-dev-1.7.3-7.deb

Date: 19 Dec 95 19:06 UT
Source: libreadline
Binary: libreadline2 libreadline2-dev 
Version: 2.0-11
Description: 
 libreadline2: GNU readline and history libraries, runtime versions.
 libreadline2-dev: GNU readline and history libraries. Development versions.
Priority: High
Changes: 
 * Fixed serious problem with upgrades. Noted by David Engel <[EMAIL 
PROTECTED]>.
 * Added Section: fields to control files. For the runtime version, this
   is base, since bash will be using it.
 * Added orig target to debian.rules; modified diff target.
 * Fixed dependency.
 * Libhistory.so now usable: produced with xmalloc and with .so.major link.
 * Fixed examples.
Files:
 -rw-r--r--   1 root root   408632 Dec 19 20:05 
libreadline-2.0-11.tar.gz
 -rw-r--r--   1 root root 4425 Dec 19 20:06 
libreadline-2.0-11.diff.gz
 -rw-r--r--   1 root root64531 Dec 19 20:05 libreadline2-2.0-11.deb
 -rw-r--r--   1 root root   113058 Dec 19 20:05 
libreadline2-dev-2.0-11.deb
 2262e24bedd885dd003c94d47b6f76a0  libreadline-2.0-11.tar.gz
 f1cc34c047cea2e0309630023385689f  libreadline-2.0-11.diff.gz
 97f8aec9eb9ecfcb8234bacadd84531e  libreadline2-2.0-11.deb
 5236543d0167dc2ca8b7a0abdea8deca  libreadline2-dev-2.0-11.deb
-- 
UNFAIR  Term applied to advantages enjoyed by other people which we tried 
to cheat them out of and didn't manage. See also DISHONESTY, SNEAKY, 
UNDERHAND and JUST LUCKY I GUESS. 
- The Hipcrime Vocab by Chad C. Mulligan  

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

[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 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.

I think he was trying to say that it would be better to alter a few
packages to conform to the "--.deb"
convention (with dashes in the packages-name an nowhere else) than
rename all existing files to have double-dashes (--) in them.
Personally, I agree.

Brian
 ( [EMAIL PROTECTED] )

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

Bug#2054: no subject (file transmission)

[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: Where are the bugs?

[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, but which site? I haven't found them on chiark. And I'm
not going to use WWW to access bug-reports, no I won't!

Regards,

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 / http://home.pages.de/~joey/
/  Ich glaube nur der Statistik, die ich selbst gefdlscht habe! /

Bug#1972: perl should suggest kernel sources

[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]> <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Bug#1951: perl is not exportable from the US

[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 capability should be removed so that we and people exporting
>Debian CDs are protected.  :-/

Not really.  It just uses crypt from libc.  This should either be closed
or redirected to libc.

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. @

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

[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 to be the maintainer?  I'd want to talk with them some about
it.

>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.

Ick.  Would that be of the GNU package or of the linux shared library
specs (gcc folks).

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. @

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

[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
>>> have to edit /etc/httpd/* by hand).
>>
>>Hmm.  That's what kept me from releasing mine.
>>Maybe we can decide what constitutes a resonable set of things to do at
>>install time?
>
>I like the idea of asking a set of questions in the postinst
>(similarly to cern-httpd).  There are too many options to simply
>impose on the user some default configuration.  Now, that I've got it
>compiled, I'm reading the User Guide!  I plan to design some
>specifications for the /usr/sbin/httpdconfig script (when I can code
>it is another story, indeed).

I've got many parts of an apache httpd config questionnaire done but
it's not complete and needs to be cleaned up.  I could probably do that
this weekend.  Would you be interested in looking at it afterwards?

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. @

Re: Linux Kernel 1.3.47 Uploaded

[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 have co-processors (eg. 
386, 486SX, ...) unless co-processor emulation is compiled in.

Steve Early
[EMAIL PROTECTED]

Re[2]: Linux Kernel 1.3.47 Uploaded

[~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 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?

No, every program compiled requires floating point as the crt.o (or 
something like that) does a floating point call, unless you hack that
and recompile all your programs you need floating point.

Note my email address is [EMAIL PROTECTED] (reply address is quite 
likely corrupt)

Andrew