1st unpacking, 2nd dependency checking

[Martin Schulze]

This might be an faq.

But occasionally I notices that dpkg first unpacks and installs
the files in a particular package and checks dependencies afterwards.

This means that wrong dependencies are discovered when it is
too late since the old version of the package is already
overwritten.

I'm sure there is a rationale for this, but what is it?

At least I would have expected that dpkg tests the dependency
of new packages and refuses to unpack them - unless one told
it to ignore dependencies.

Regards,

Joey

-- 
There are lies, statistics and benchmarks.

perl version depends

[Darren Stalder]

-BEGIN PGP SIGNED MESSAGE-

Is it possible for dpkg to have a depends line similar to:
Depends: perl (=5.005)
and have that include 5.005-\d+?  Or will I need to put a
Provides: perl5.005
in so that packages can depend on that?

(Note that I did say that this would break *all* debian installed
packages in the change release.)

Darren
- -- 
<[EMAIL PROTECTED]>  <[EMAIL PROTECTED]> <[EMAIL 
PROTECTED]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @
@Make a little hot-tub in your soul.  @

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNhv+B7QuaHP6LBjxAQHJHgP9F0dtrDOi/qOpkVPzSKq/EKius7A5r1Yu
seL2beyGI31U6DRm+/2gSlABRme+GnVPoMQTKHA+8dZgh3O3I+DoAqPEAn5DUz2j
SEsGqkS1Y2x7Ooa95DKAC+6pPNg8qy0omkhXqh9Z7ABUXPcVRLS6JqqAPs/rAHT6
I9OClbm5WzQ=
=dMOQ
-END PGP SIGNATURE-

Re: Perl policy for managing modules ?

[John Lapeyre]

On Wed, 7 Oct 1998, Raphael Hertzog wrote:

rhertz>I propose to make package install the modules in /usr/lib/perl5/debian
rhertz>and /usr/lib/perl5/debian/$arch. And the /usr/lib/perl5/$version would
rhertz>be a link to "debian", and /usr/lib/perl5/$arch/$version a link to 
rhertz>"../debian/$arch". So the current perl will always find the modules
rhertz>installed. And we'll have no problem for the transition to perl5.006 ...
rhertz>
rhertz>How to manage this in the source package for a CPAN module ? Here's
rhertz>what I would have to do for my own package (I tested it) :
rhertz>
rhertz>- use this line for creating the Makefile :
rhertz>  perl Makefile.PL INSTALLDIRS=perl 
LIB=`pwd`/debian/tmp/usr/lib/perl5/debian
rhertz>- and use "make pure_install" for installing files

Thats how I build my perl modules as well (and I guess others), so
it shouldn't be too much of a problem. (Acutally some of the more
complicated packages will need more changes.)
I can't think of a better solution. Re: packages with only perl
source, many will probably not be affected by an upgrade, and it seems
silly to require that they be rebuilt.
I posted a message on perl5-porters asking for advice.  We need to
set a policy quickly, as quite a bit of slink has just become unstable.
(Unfortunatley, I was using slink for daily science work. I don't have two
machines.)

John


John Lapeyre <[EMAIL PROTECTED]>
Tucson,AZ http://www.physics.arizona.edu/~lapeyre

Re: APT 0.1.6 is released!

[john]

Dale Scheetz writes:
> You can't ever remove A. Systems "pre-split" must always be upgradable to
> systems after the split.

They would still be upgradable: they'd just revert to what I understand to
be the present behavior: A vanishes.  But, ok.

> Doesn't necessarily mean that this isn't a workable idea, just that it
> will always have this baggage.

Doesn't seem like very objectionable baggage.  The packages would have
descriptions that makes it clear what they are, and there would never be
very many.

When I think about it more, I guess I would want to keep them around.  B
and C were together in A because someone once thought they belonged
together.  It is likely that others will think similarly, or just remember
'A' from bo and go looking for it in emperor.  This scheme gives them
what they expect.  Think of these as a type of 'superpackage'.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: Contacting authors

[Martin Schulze]

Joey Hess wrote:
> > Example: [EMAIL PROTECTED] would redirect the mail to
> > [EMAIL PROTECTED] who is the current developer of hypermail.
> 
> It seems like a good idea in general. The only 2 problems I can see are that
> we would have to keep track of authors changing their email addresses, and
> that some authors may not want this as an address that points to them (they
> may be concerned about spam going to it, for example).

We already have to keep track of authors changing their email addresses
since we have to put their name and address in the copyright file.

Re spam: I'd like to make it optional so it does not have to be
used but only should.  Each pkg. maintainer could negotiate with
the upstream author about this feature and not use it if the author
doesn't like that.

Regards,

Joey

-- 
There are lies, statistics and benchmarks.

Re: Web page updated + possible bug in perl_5.005-02.1/sgmlspm_1.03ii-8

[Marc A. Volovic]

BUG DESCRIPTION _AFTER_ nano-HOWTO info.
On Wed, Oct 07, 1998 at 04:03:31PM -0400, Christopher C Chimelis wrote:
> 
> FYI, the official Debian-Alpha port page has been updated
> (http://www.debian.org/ports/alpha).  It *should* have everything that we

nano-HOWTO updated to include everything on AlphaBIOS I've seen from
Guenther.

NON-AXP stuff follows (BUG DESCRITION):

There seems a possible problem with either perl_5.005 _or_
sgmlspm_1.03ii-8:

Symptom:

sgmlspl uses package SGMLS. That package is located in
/usr/lib/perl5, put there by sgmlspm. However, debiandoc2*
fail to locate SGMLS/*, looking under other directories (i.e.
/usr/lib/perl5/5.005, etc).

Since I do not know perl sell, I am not certain what is going on. Oh, I
rectified the problem by simply linking SGMLS into /usr/lib/perl5/5.005,
but that is hardly a solution.
-- 
---MAV

Marc A. Volovic   | Comfort, n: A feeling one gets from
[EMAIL PROTECTED]  |   contemplating discomfort in another.
http://www.bard.org.il/~marc  |   A. Bierce.

Re: Contacting authors

[Joey Hess]

Martin Schulze wrote:
> What do you think about it?
> 
> Example: [EMAIL PROTECTED] would redirect the mail to
> [EMAIL PROTECTED] who is the current developer of hypermail.

It seems like a good idea in general. The only 2 problems I can see are that
we would have to keep track of authors changing their email addresses, and
that some authors may not want this as an address that points to them (they
may be concerned about spam going to it, for example).

-- 
see shy jo

Re: Contacting authors

[Martin Schulze]

Martin Schulze wrote:
> tonight I was thinking about implementing @authors.debian.org which
> would enable a way for us to get in touch with the upstream authors of
> some piece of software without the need of looking into the copyright
> file or digging in the source if the maintainer forgot to add the
> authors email into that file.
> 
> What do you think about it?

[..]

> This would also need an adjustment for dpkg-source.

This is the change that's needed to pass the Author field through
the control file.

--- dpkg-source.origWed Oct  7 23:49:17 1998
+++ dpkg-source Wed Oct  7 23:57:25 1998
@@ -51,7 +51,7 @@
 
 $i = 100;
 grep ($fieldimps {$_} = $i--,
-  qw (Source Version Binary Maintainer Architecture Standards-Version));
+  qw (Source Version Binary Maintainer Author Architecture 
Standards-Version));
 
 while (@ARGV && $ARGV[0] =~ m/^-/) {
 $_=shift(@ARGV);
@@ -111,7 +111,7 @@
 if (s/^C //) {
 #print STDERR "G key >$_< value >$v<\n";
 if (m/^Source$/) { &setsourcepackage; }
-elsif (m/^Standards-Version$|^Maintainer$/) { $f{$_}= $v; }
+elsif (m/^Standards-Version$|^Maintainer$|^Author$/) { $f{$_}= $v; 
}
 elsif (s/^X[BC]*S[BC]*-//i) { $f{$_}= $v; }
 elsif (m/^(Section|Priority|Files)$/ || m/^X[BC]+-/i) { }
 else { &unknown('general section of control info file'); }

Regards,

Joey

-- 
There are lies, statistics and benchmarks.

Re: Contacting authors

[Martin Schulze]

Darren Benham wrote:
> Before packaging something, I check with the upstream author.  I know it's GPL
> but I like to be polite about it.  In one case, I had the upstream author make
> some "suggestions" and one of them was to make sure any and all mail about the
> package got sent to me.  I think he'd be an example of someone who doesn't 
> want
> a lot of email about his software...

Interesting, but since I'd like to have this field optional this
is no problem referring to my proposal.

Regards,

Joey

-- 
There are lies, statistics and benchmarks.

Re: Re: APT 0.1.6 is released!

[Jamey Sharp]

[EMAIL PROTECTED] wrote:
> > I think you need to install the new nfs-server package.
> 
> Yeah, I got bit by that too, and it took me a while to find that...
> maybe we need some sort of "transitional-recommends" field?  Something
> that is ignored if you are installing the package (to avoid causing
> even more pain to dselect users, or something), but noticed on an
> upgrade? (obviously it need more subtlety than that, but this might be
> a more useful distinction than we've had before for splitting
> packages...)
> 
> [it is *possible* that nfs-server wasn't even on the mirrors, maybe
> because it was new, when the netstd or netbase or whatever used to
> have it, dropped it; oh well, that's what "unstable" is all about...]

I upgraded to unstable yesterday, and had no problem. dselect automatically
selected nfs-server, telnetd, etc., so I didn't have to do any of that.

Does dselect automatically select anything in the base section and anything in
priorities Important and Standard? Or have those packages been selected for me
the way the new split ones from unstable were?

-Jamey


Get free e-mail and a permanent address at http://www.netaddress.com/?N=1

Re: Contacting authors

[Darren Benham]

Before packaging something, I check with the upstream author.  I know it's GPL
but I like to be polite about it.  In one case, I had the upstream author make
some "suggestions" and one of them was to make sure any and all mail about the
package got sent to me.  I think he'd be an example of someone who doesn't want
a lot of email about his software...

On 07-Oct-98 Martin Schulze wrote:
> Alexander Koch wrote:
>> Hi Joey.
>> 
>> > What do you think about it?
>> 
>> Will it produce more mail to the authors? Will *they* like it?
> 
> Which author doesn't like to be contacted wrt his software?
> 
> Besides, you can leave it out.
> 
> Regards,
> 
>   Joey
> 
> -- 
> There are lies, statistics and benchmarks.
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
> 

=
* http://benham.net/index.html  *
*  * -BEGIN GEEK CODE BLOCK- ---*
*Darren Benham * Version: 3.1   *
*  <[EMAIL PROTECTED]>  * GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++>*
*  * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS--   *
*   Debian Developer   * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++   *
*  <[EMAIL PROTECTED]>  * G++>G+++ e h+ r* y+*
*  * --END GEEK CODE BLOCK-- ---*
=

Re: Contacting authors

[Ben Pfaff]

David Welton <[EMAIL PROTECTED]> writes:

   So do we put Linus' address for the kernel packages?:P 

I would suggest [EMAIL PROTECTED] for kernel-source.

Re: An X version of dselect for slink

[Jamey Sharp]

[EMAIL PROTECTED] wrote:
> Since it seems obvious that apt WON'T be finished (GUI bit I mean)
> before freeze of slink, I have started writing an X clone of the Dselect
> tool.
> 
> Although to be ready by 16th will make it pretty much a hack, I think it
> is one worthy for this release (in much the same way as the
> preselections were earlier).

I have a very simple frontend to dselect in Tcl/Tk which simply replaces the
main menu of dselect... If anyone's interested, I could put it on my web
server, but probably both apt and gdselect are more advanced already.

> I will write it using GTK (I already have the basic framework done),
> development version 1.1 (for GtkCTrees, they are VERY useful for this).
> 
> I have a couple of questions:-
> 
> a) Does anyone else think this is a good idea?

Yup. (Otherwise I wouldn't have started my own similar project. )

> b) How will this integrate with the installation
> 
> Point b probably needs more expansion. What I mean is, if J Random Luser
> installs the basic system using the boot disks, it would be nice to
> start X, then this tool ASAP (basically, instead of Dselect). What needs
> to be done in terms of bootdisks and installation stuff to support this?
> (Presumably at least a question in the install "do you want to use a GUI
> install program or a TUI install program?").

I really like the idea of a full GUI install, but I have a use for running
Debian on 386s, so it'd be a pretty definite requirement (IMO) that dselect
stick around. (X wouldn't be pretty on a 386. )

> Dselect's functionality is fairly simple - I believe I can have it
> duplicated and fully tested (enough for my scrutiny) under X by freeze
> time, after which others can test it.

Sounds good to me.

> Some more random dselect/dpkg questions for slink:
> 
> Also, we need to deal with the dselect Install/Remove/Configure
> syndrome. We could easily put in my tool "Apply changes", which does all
> three (using same script interface). IMHO, we ought to switch completely
> to dpkg-mountable and apt (i.e. drop all existing default methods
> bar possibly dpkg-ftp and disks).

'apt-get dselect-upgrade' already does that. I'd go for dropping the Configure
and Remove options entirely from (g)dselect.

Also, apt supports mounted filesystems. It would be fairly simple to make it
be able to mount unmounted ones, I would think. (Just check /etc/mtab, and if
it's not there, mount it?) Therefore, I'd propose that this be purely a
frontend to apt.

Apt already has FTP support. Why keep using dpkg-ftp? And what is disks? Does
it handle multi-disk installs?

> What about multi-cd stuff? Should be integrated into mountable IMHO.

I think eveything ought to be integrated into apt.

> Can mountable handle an FS which isnt in /etc/fstab? If not,
> the bootdisks ought to as a bare minimum insert the installation
> medium (if CDROM) into /etc/fstab with options
> "noauto,noexec,nosuid,nodev,ro", and /floppy should be there too.

I don't see how mountable could handle anything not in /etc/fstab. But perhaps
the install routine should have an option for adding entries to /etc/fstab.
(Autodetection of which devices are what and should be mounted where would be
nearly impossible, I would think.)

-Jamey


Get free e-mail and a permanent address at http://www.netaddress.com/?N=1

Re: Contacting authors

[David Welton]

On Wed, Oct 07, 1998 at 10:37:49PM +0200, Martin Schulze wrote:
> Alexander Koch wrote:
> > Hi Joey.
> > 
> > > What do you think about it?
> > 
> > Will it produce more mail to the authors? Will *they* like it?
> 
> Which author doesn't like to be contacted wrt his software?

So do we put Linus' address for the kernel packages?:P 

Seems like a decent idea, but I think there are other things to do.
Your time though, if you really see the need, go for it:->

Ciao,
-- 
David Welton  http://www.efn.org/~davidw 

Debian GNU/Linux - www.debian.org

Re: Contacting authors

[Martin Schulze]

Alexander Koch wrote:
> Hi Joey.
> 
> > What do you think about it?
> 
> Will it produce more mail to the authors? Will *they* like it?

Which author doesn't like to be contacted wrt his software?

Besides, you can leave it out.

Regards,

Joey

-- 
There are lies, statistics and benchmarks.

Re: Contacting authors

[Martin Schulze]

Shaleh wrote:
> 
> On 07-Oct-98 Martin Schulze wrote:
> > Hi,
> > 
> > tonight I was thinking about implementing @authors.debian.org which
> > would enable a way for us to get in touch with the upstream authors of
> > some piece of software without the need of looking into the copyright
> > file or digging in the source if the maintainer forgot to add the
> > authors email into that file.
> > 
> > What do you think about it?
> 
> This sounds good in theory.  However numerous pieces of software have no
> defined author.  Enlightenment has two, which should be listed?

Either note the leading maintainer, write down both addresses, take
its development list or leave it out.  However the development list
might not be a good idea.  I haven't made my mind up.

> How about making the field optional, and if it is not present the mail gets
> forwarded to the developer?

An optional field would be ok.

If there is no author available the mail [c/w]ould be redirected
to the current maintainer.  This mechanism is already available
through packages.debian.org.

I't like to tag it at the same priority as using @debian.org as
the maintainer address.  Read: Please do it but if not nobody
would seriously complain.

Regards,

Joey

-- 
There are lies, statistics and benchmarks.

RE: Contacting authors

[Shaleh]

On 07-Oct-98 Martin Schulze wrote:
> Hi,
> 
> tonight I was thinking about implementing @authors.debian.org which
> would enable a way for us to get in touch with the upstream authors of
> some piece of software without the need of looking into the copyright
> file or digging in the source if the maintainer forgot to add the
> authors email into that file.
> 
> What do you think about it?

This sounds good in theory.  However numerous pieces of software have no
defined author.  Enlightenment has two, which should be listed?

How about making the field optional, and if it is not present the mail gets
forwarded to the developer?

Re: Contacting authors

[Alexander Koch]

Hi Joey.

> What do you think about it?

Will it produce more mail to the authors? Will *they* like it?
Besides that, it's at least useful.

Alexander

-- 
Alexander Koch - <>< - aka Efraim - PGP - 0xE7694969 - Hannover - Germany


pgpnc62DE5VwG.pgp
Description: PGP signature

Flagging squid bug as "important"

[Martin Schulze]

Hi,

I'd like to flag Bug#27444 severity "important" since it filled up
my disk to 100% for the fourth time two days ago.  This suxx and
since there is a patch provided it won't hold the release (except
nobody makes a new upload for it).

http://www.infodrom.north.de/Debian/Bugs/db/27/27444.html

Do I receive your objection or acceptance?

Regards,

Joey

-- 
There are lies, statistics and benchmarks.

Contacting authors

[Martin Schulze]

Hi,

tonight I was thinking about implementing @authors.debian.org which
would enable a way for us to get in touch with the upstream authors of
some piece of software without the need of looking into the copyright
file or digging in the source if the maintainer forgot to add the
authors email into that file.

What do you think about it?

Example: [EMAIL PROTECTED] would redirect the mail to
[EMAIL PROTECTED] who is the current developer of hypermail.

An easy way to implement this would be to simply add a line to the
source section of debian/control of each package like

Source: gtkfind
Section: x11
Priority: optional
Maintainer: Martin Schulze <[EMAIL PROTECTED]>
Author: Matt Grossman <[EMAIL PROTECTED]>< this one
Standards-Version: 2.4.0.0

Package: gtkfind
Architecture: any
Depends: ${shlibs:Depends}
Description: Graphical File Finder
 This package provides a graphical file finding program.

This would also need an adjustment for dpkg-source.

What do you think about this?

Regards,

Joey

-- 
There are lies, statistics and benchmarks.


pgpNU6K7p5bEo.pgp
Description: PGP signature

Re: exim really does need to be the standard MTA in slink

[Alexander Koch]

On Wed, 7 October 1998 12:12:10 -0700, Steve Lamb wrote:
> Just curious how you know this since when I telnet to their relay hosts
> they are very non-descript about what they run.

Exim-users.
And a certain news hierachy with some bofhish guys in it.
Did I mention psi.uk.com, btw?

Alexander

-- 
to hell with int(h)el(l)
Alexander Koch - <>< - aka Efraim - PGP - 0xE7694969 - Hannover - Germany

debian/rules and find

[Martin Schulze]

Hi,

this afternoon I occurred a serious problem where some of our
debian/rules file will fail.

xargs will *always* execute the command, even with no input.  This
means that all constructs like "find -name foo|xargs chmod g+w" will
fail as soon as find doesn't find any file.  As Joey pointed out this
is a documented feature.  I understand that there are situations where
this is a needed feature.

However in the process of creating .deb files this is not needed, even
worse it will stop the creation.  Instead we should use xargs -r or
--no-run-if-empty which won't execute the program on the command line
if there is no input.

So please check your debian/rules files for constructs like the
following:

   chmod g+w `find debian/tmp -name foo`

   find debian/tmp -name foo|xargs chmod g+w

the correct way to implement this would be

   find debian/tmp -name foo|xargs -r chmod g+w

Regards,

Joey

-- 
There are lies, statistics and benchmarks.

Re: How about using bzip2 as the standard *.deb compression format?

[Edward Betts]

On Tue, 06 Oct, 1998, Joseph Carter wrote:
> On Tue, Oct 06, 1998 at 03:50:01PM -0500, John Goerzen wrote:
> > This is silly.  dpkg/dselect are already insanely slow, even on my
> > P166 with 128 meg of RAM -- especially when reading database, etc.  If 
> > we slow down the installation so much more by using bzip2, then people 
> > will simply stop upgrading, or switch to other distributions because
> > it is so slow.  That is not acceptable.
> 
> Um, not all of us are using dselect/dpkg.  Most of us refuse to because it's
> insanely slow and generally braindead if you have a serious conflict.  I use
> dselect/apt myself.

surley you mean dselect/apt/dpkg?

-- 
linux: because a PC is a terrible thing to waste

Re: APT 0.1.6 is released!

[Dale Scheetz]

On 7 Oct 1998 [EMAIL PROTECTED] wrote:

> 
> How about this?
> 
> A_1.0-0.1 is going to split into B and C.  So you create a dummy A_1.0-0.2
> package which depends on B and C and upload it along with B and C.  Anyone
> who upgrades and has A will get it upgraded to A_1.0-0.2, which will pull in
> B and C.  No one else ever needs to know that A ever existed.  After a
> release or two you remove A from the distribution.

You can't ever remove A. Systems "pre-split" must always be upgradable to
systems after the split.

Doesn't necessarily mean that this isn't a workable idea, just that it
will always have this baggage.

Luck,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

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

Re: Finding a source package

[Joey Hess]

Guy Maor wrote:
> I'm suggesting that dpkg-scanpackages scan the dscs and put the
> section and version in the Source field, or perhaps add a new field
> Dsc which is simply the full path to the dsc, akin to the Filename
> field.  Then downloading the source for a package is simple.  The web
> pages would use this field too.

But .dsc's are pgp signed by thier creators. How would you edit them?

-- 
see shy jo

Re: APT 0.1.6 is released!

[john]

Mark W. Eichin wrote:
> Yeah, I got bit by that too, and it took me a while to find that...
> maybe we need some sort of "transitional-recommends" field?  Something
> that is ignored if you are installing the package (to avoid causing even
> more pain to dselect users, or something), but noticed on an upgrade?
> (obviously it need more subtlety than that, but this might be a more
> useful distinction than we've had before for splitting packages...)

How about this?

A_1.0-0.1 is going to split into B and C.  So you create a dummy A_1.0-0.2
package which depends on B and C and upload it along with B and C.  Anyone
who upgrades and has A will get it upgraded to A_1.0-0.2, which will pull in
B and C.  No one else ever needs to know that A ever existed.  After a
release or two you remove A from the distribution.
-- 
John HaslerThis posting is in the public domain.
[EMAIL PROTECTED]  Do with it what you will.
Dancing Horse Hill Make money from it if you can; I don't mind.
Elmwood, Wisconsin Do not send email advertisements to this address.

Re: bug in apt-get?

[Ben Gertzfield]

> "Michael" == Michael Meskes <[EMAIL PROTECTED]> writes:

Michael> When I run apt-get check I get: [EMAIL PROTECTED]:~$ sudo
Michael> apt-get check Updating package file cache...done Updating
Michael> package status cache...done Checking system
Michael> integrity...dependency error You might want to run
Michael> `apt-get -f install' to correct these.  Sorry, but the
Michael> following packages are broken - this means they have
Michael> unmet dependencies: libpgjava: Depends:jdk1.1-runtime
Michael> econfigedit: Depends:libgtk-perl [EMAIL PROTECTED]:~$

Michael> However, I do have jdk1.1 and libgnome-perl
Michael> installed. They provide the 'missing' packages. I tried
Michael> recreating apt's cache by removing
Michael> /var/cache/apt/pkgcache.bin and adding the file available
Michael> resp. status but nothing changed.

I'm pretty sure policy states that a package cannot depend wholly
on a virtual package; it has to depend on a real, preferred package,
*or* the virtual package, like so:;

Depends: jds1.1 | jdk1.1-runtime

Ben

-- 
Brought to you by the letters U and H and the number 19.
"Son, I am able," she said, "though you scare me." -- They Might Be Giants
Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.

Re: exim really does need to be the standard MTA in slink

[Steve Lamb]

On Wed, 7 Oct 1998 13:00:51 +0200, Paul Slootman wrote:

>I personally have confidence in Exim's quality in this regard.
>Demon (a large ISP in the UK and the Netherlands, www.demon.net)
>uses Exim as its customer-facing smtp interface, so I guess that they're
>convinced as well.

Just curious how you know this since when I telnet to their relay hosts
they are very non-descript about what they run.

[EMAIL PROTECTED]:/home/morpheus}telnet relay-1.mail.demon.net 25
Trying 194.217.242.51...
Connected to relay-1.mail.demon.net.
Escape character is '^]'.
220 relay-1.mail.demon.net Server SMTP (Complaints/bugs to: 
[EMAIL PROTECTED]
t)
^]
telnet> quit
Connection closed.
[EMAIL PROTECTED]:/home/morpheus}telnet 0 25
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
220 teleute.dyn.ml.org ESMTP Exim 2.04 #1 Wed, 7 Oct 1998 12:19:27 -0700
^]
telnet> quit
Connection closed.

-- 
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
 ICQ: 5107343  | main connection to the switchboard of souls.
---+-

Perl policy for managing modules ?

[Raphael Hertzog]

Hello,

I thought about the problem with directory used for installing perl
modules. Actually if we do nothing, we would have to recompile all
perl package for each perl5.00x release. That's because perl uses
now /usr/lib/perl5/$version (and perl5/$arch/$version) as path 
to search for modules. And actually I count 80 packages installing
perl modules so you see why another solution has to be found.

I propose to make package install the modules in /usr/lib/perl5/debian
and /usr/lib/perl5/debian/$arch. And the /usr/lib/perl5/$version would
be a link to "debian", and /usr/lib/perl5/$arch/$version a link to 
"../debian/$arch". So the current perl will always find the modules
installed. And we'll have no problem for the transition to perl5.006 ...

How to manage this in the source package for a CPAN module ? Here's
what I would have to do for my own package (I tested it) :

- use this line for creating the Makefile :
  perl Makefile.PL INSTALLDIRS=perl LIB=`pwd`/debian/tmp/usr/lib/perl5/debian
- and use "make pure_install" for installing files

What do you think about it ? Ok, it's a bit late for updating about 80 
packages but I'm sorry, I didn't know this new "perl feature".

In summary, what we would have to do is :
- modify all package with perl modules for installing them
  into /usr/lib/perl5/debian
- make them depend on perl >=5.005 (since the directory tree has changed)

Cheers,
-- 
Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/

Re: PERL: patch for glibc 2.1

[Dan Jacobowitz]

On Wed, Oct 07, 1998 at 01:34:42AM -0700, Darren/Torin/Who Ever... wrote:
> >I know what's going on with IPC, and I'm guessing the DBM test is failing
> >because of a bug in the libc.
> 
> So, what's going on with IPC?

IPC until very recently was completely hosed on powerpc.  We have hopes
that a new set of compiler and libc will resolve the issue - expect
progress reports in the next few days :)

Dan

Re: Top source

[Tom Lear]

On Wed, 7 Oct 1998, Peter Iannarelli wrote:

> Hello all:
> 
> What package hosts the top command?
dreamer:~% dpkg -S /usr/bin/top
procps: /usr/bin/top

> I want to see if I can get the thing going
> for multi-CPU systems.
I use it on multi-CPU systems.  What doesn't work about it?
- Tom

Re: Top source

[Martin Schulze]

Peter Iannarelli wrote:
> Hello all:
> 
> What package hosts the top command?

finlandia!joey(tty11):~> dpkg -S bin/top
procps: /usr/bin/top
netstd: /usr/bin/toport
finlandia!joey(tty11):~> dpkg -l procps
Desired=Unknown/Install/Remove/Purge
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ NameVersionDescription
+++-===-==-
ii  procps  1.2.7-2The /proc file system utilities.

Regards,

Joey

-- 
There are lies, statistics and benchmarks.

mpsql

[Michael Meskes]

Anyone using it? I noticed two days ago that the buttons are gone. Since I
updated mpsql and lesstif almost at the same time I'm not exactly sure what
happened, but have the feeling the change in lesstif caused this. Anyone
else experiencing this problem? Please tell me what happens on your system
and what version you use.

Michael
-- 
Dr. Michael Meskes  | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant   | business: [EMAIL PROTECTED] | Go Rhein Fire!
Mummert+Partner | private: [EMAIL PROTECTED] | Use Debian
Unternehmensberatung AG |  [EMAIL PROTECTED] | GNU/Linux!

bug in apt-get?

[Michael Meskes]

When I run apt-get check I get:

[EMAIL PROTECTED]:~$ sudo apt-get check
Updating package file cache...done
Updating package status cache...done
Checking system integrity...dependency error
You might want to run  `apt-get -f install' to correct these.
Sorry, but the following packages are broken - this means they have unmet
dependencies:
  libpgjava: Depends:jdk1.1-runtime
  econfigedit: Depends:libgtk-perl
[EMAIL PROTECTED]:~$

However, I do have jdk1.1 and libgnome-perl installed. They provide the
'missing' packages. I tried recreating apt's cache by removing
/var/cache/apt/pkgcache.bin and adding the file available resp. status but
nothing changed.

Michael

-- 
Dr. Michael Meskes  | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant   | business: [EMAIL PROTECTED] | Go Rhein Fire!
Mummert+Partner | private: [EMAIL PROTECTED] | Use Debian
Unternehmensberatung AG |  [EMAIL PROTECTED] | GNU/Linux!

Re: lyx?

[Michael Meskes]

On Wed, Oct 07, 1998 at 03:56:39AM +0200, Paul Seelig wrote:
> I've made by the way a quick'n'dirty updated package of the current
> lyx-0.12.1pre8 which already contains this LaTeX importing feature.
> Seems to be working very well with the LaTeX files i tried out so far:

Good to hear that. :-) 

>  ftp://ietpd1.sowi.uni-mainz.de/pub/debian/unofficial/{binary,source}
> 
> If you'd like to you could possibly use this as a base for a new lyx
> version for slink? I think it's definitely worth an update anyway.

I'm no longer responsible for lyx. I gave the package away when I changed
jobs as I simply no longer able to upload such a big package. So this should
go to the new maintainer.

Michael
-- 
Dr. Michael Meskes  | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant   | business: [EMAIL PROTECTED] | Go Rhein Fire!
Mummert+Partner | private: [EMAIL PROTECTED] | Use Debian
Unternehmensberatung AG |  [EMAIL PROTECTED] | GNU/Linux!

gmc problem

[Michael Meskes]

gmc doesn't work with the most up-to-date libraries. It was linked against
an older one no longer in the archive (btw the same holds for balsa). But
recompiling from source got me a binary that seg faults.

Michael
-- 
Dr. Michael Meskes  | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant   | business: [EMAIL PROTECTED] | Go Rhein Fire!
Mummert+Partner | private: [EMAIL PROTECTED] | Use Debian
Unternehmensberatung AG |  [EMAIL PROTECTED] | GNU/Linux!

Inten to package: iceconf

[Michael Meskes]

If no one else volunteers I take a look at it. It's a graphical
configuration tool for icewm.

Michael
-- 
Dr. Michael Meskes  | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant   | business: [EMAIL PROTECTED] | Go Rhein Fire!
Mummert+Partner | private: [EMAIL PROTECTED] | Use Debian
Unternehmensberatung AG |  [EMAIL PROTECTED] | GNU/Linux!

Top source

[Peter Iannarelli]

Hello all:

What package hosts the top command?
I want to see if I can get the thing going
for multi-CPU systems.


Peter

Re: Finding a source package

[Brederlow]

<[EMAIL PROTECTED]>(James A. Treacy) writes:

> Guy Maor wrote:

> First, due to NMU uploads to other architectures, the source version
> may not match the version: in the package you are looking for.
> This means you need to search the archive for the name of the .dsc
> file. There are about 75 version mismatches in slink (only 2 in hamm)
> so this is not a minor issue.

It actually is a big problem considering the GPL. Debian could
be asked for any source, for wich a binary is awaylable. That means,
to be on the save side, eigther old sources must be kept as long as
there are binaries of it, or binaries must be deleted when a newer
source is uploaded. The second of which is not aceptable at all.

Also all sources the package source depends on (like libs, tools, ...)
must be present in the version used to build a package, otherwise the
might not be rebuild from its source.

Having no source dependencies and no version tracking for binaries,
this is actually impossible to guranty without keeping all old
versions but source dependencies would help a lot in assuring that
sources are awailable as needed by the gpl. Together with the source
dependencies the upload scripts must be changed to delete source no
earlier then when the last package that depends on it is removed (or
updated to a newer version).

May the Source be with you.
Mrvn

Re: Better (inc. asynchronous) DNS client (stub resolver)

[Marc Singer]

On Wed, Oct 07, 1998 at 05:29:48PM +0100, Ian Jackson wrote:
> Mark W. Eichin writes ("Re: Better (inc. asynchronous) DNS client (stub 
> resolver)"):
> > You might look at the "ares" library (Asynchronous RESolver) that Greg
> > Hudson <[EMAIL PROTECTED]> wrote...  
> > athena-dist.mit.edu:/pub/ATHENA/ares/ares-0.3.0.tar.gz  
> > is the current version.  (At very least, compare notes with him...)
> 
> Thanks for the pointer.  At first, I saw your message and thought `oh
> no, all that wasted effort'.  But, I think my API is still an
> improvement because it provides a much more `cooked' interface.  Also,
> I'm not _too_ keen on the callback style of doing things, at least as
> a basic API.  You can always convert an event loop into a callback,
> but the other way round is hard.

Without looking at ares, I'd say that the form of your interface is
appropriate.  I'd have a hard time justifying this myself without a
lengthy exposition.  For anyone designing computer systems, I
recommend reading a paper by Butler Lampson...here is it...

  Butler W. Lampson.
"Hints for Computer System Design",
Proceedings of the 9th ACM Symposium on Operating Systems Principles,
October 1983, pp.33-48.

On reading this paper, I discovered all of the reasons for why I knew
that the M$ way is wrong.  I highly recommend this paper for its
taxonomy of software design and for the 'hints' on how to avoid the
mistakes we've already seen.

> 
> Ian.
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

Re: debian for non linux systems ...

[Marc Singer]

On Wed, Oct 07, 1998 at 12:28:38PM +0200, [EMAIL PROTECTED] wrote:
> Hello,
> 
> I remember some month ago there was a discution some time ago about debian for
> non entirely debian systems (i think it was a debian-solaris thing).
> 
> What happened to it ?
> 
> i was given a ultra sparc 1 with solaris 2.6 here at the university, and
> þerhaps i would like to work on such a thing. (not now, but i a month or 
> so...)
> 

I know that one of the biggest problems is that the dependency checks
rely on a database.  This comes up when you try to build a package on
a non-debian system.  There is a real knowledge gap between installed,
unqualified packages that came with the system and pedigreed debian
packages.  In addition, the configuration of the non-debian system may
be far from what debian packages expect.  Take a look at /etc/init.d.
I wasn't party to the original conversation, so I don't know where the
thread ran.  I expect that this feature is considered low priority
when compared to the mountain of things we need to do to make debian
grow. 

Re: Finding a source package

[James Troup]

[ Please don't Cc me on replies to a public mailing list ]

<[EMAIL PROTECTED]> (James A. Treacy) writes:

> > <[EMAIL PROTECTED]>(James A. Treacy) writes:
> > 
> > > Should apt have to download the dsc file for a package before it
> > > knows what the source files are?
> > 
> > Why on earth not?  If it's going to download the source, the .dsc file
> > is part of the source and has to be downloaded anyway.
>   
> It is clearly much more efficient if the .dsc files don't have to be
> retrieved.

Eh?  Have you ever used dpkg-source?  The .dsc files _have_ to be
retrieved because they're an essential part of the source package.

(In any event .dsc files are usually no more than several hundred
bytes; hardly worth making a polava over)

> > Then they have 2 options: 

[...]

> These are both hacks (in the bad sense of the word. Kluge is a better
  (Kludge even)
> word, but many people won't know it).

No; (1) is a kludge, (2) is a perfectly valid solution and poses no
real problems that I can see, as opposed to allowing multiple source
versions of the same package which poses lots of problems for little
or no gain.

[And I'm speaking as a porter; multiple source versions of the same
source and with the same name would give me the mother of all
headaches.]

-- 
James

Re: Better (inc. asynchronous) DNS client (stub resolver)

[Ian Jackson]

Mark W. Eichin writes ("Re: Better (inc. asynchronous) DNS client (stub 
resolver)"):
> You might look at the "ares" library (Asynchronous RESolver) that Greg
> Hudson <[EMAIL PROTECTED]> wrote...  
>   athena-dist.mit.edu:/pub/ATHENA/ares/ares-0.3.0.tar.gz  
> is the current version.  (At very least, compare notes with him...)

Thanks for the pointer.  At first, I saw your message and thought `oh
no, all that wasted effort'.  But, I think my API is still an
improvement because it provides a much more `cooked' interface.  Also,
I'm not _too_ keen on the callback style of doing things, at least as
a basic API.  You can always convert an event loop into a callback,
but the other way round is hard.

Ian.

Freeze and soon-to-be-freed package

[Gregor Hoffleit]

Since I've heard rumours about the slink freeze taking place soon:

Bobo by Digital Creations consists of three independent packages which 
recommend each other. Two of them (python-bobo, python-bobodtml)
already are in slink with a BSD style license. The license of the
third package, BoboPOS, will be fixed with the next release, which can 
be expected anytime between tomorrow and in two months.

Can I rest assured that this new package will be accepted for slink
even after the freeze ? Would it be better to upload the current
version to "non-free" and move it into "main" after the freeze ?

Gregor

Intent to package calamaris (was: wanted: calamaris)

[Philipp Frauenfelder]

Joey Hess:
> Calamaris is an analyzer for squid log files, that generates nice reports.
> http://www.detmold.netsurf.de/homepages/cord/tools/squid/calamaris/

I downloaded it and had a look at it. Seems not to be too 
complicated to me. How much do I have? :-)

The licence is GPL with this one added:

 (If you modify and want to publish it under the name 
 'Calamaris', please ask me. I don't want to confuse 
 the 'audience' with many different versions of the 
 same name and/or Version number.)

I think this is still DFSG free. I'll ask the author before I 
start packaging it.

Regards,
Philipp

Re: APT 0.1.6 is released!

[Martin Alonso Soto]

[EMAIL PROTECTED] (Mark W. Eichin) wrote:
> Yeah, I got bit by that too, and it took me a while to find that...
> maybe we need some sort of "transitional-recommends" field?  Something
> that is ignored if you are installing the package (to avoid causing
> even more pain to dselect users, or something), but noticed on an
> upgrade? (obviously it need more subtlety than that, but this might be
> a more useful distinction than we've had before for splitting
> packages...)

Package splitting has always been a problem with Debian.  I would suggest a 
different solution, namely an "upgrades" field included in the new packages.  
The idea is that if package A is split into packages B and C, both B and C 
should include a field

  upgrades: A

in their control file.  That way the upgrade procedure would now that in order 
to upgrade A, both B and C must be installed.  I think this idea works for 
package splitting as well as for package renaming, or combinations of them both.

Comments?

M. S.


Martin A. Soto J.   Profesor
Departamento de Ingenieria de Sistemas y Computacion
Universidad de los Andes  [EMAIL PROTECTED]

Re: Perl 5.005.02

[Wichert Akkerman]

Previously Bart Schuller wrote:
> This didn't catch vim-perl, which seems to have been statically linked
> to perl, but references the libraries of the current version so should
> be upgraded as well.

It is, since vim's configure couldn't find any shared-libraries for perl.
And from what I see I don't have any installed either.

I'll recompile vim tomorrow or tonight with the new perl.

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpGrDGUFdvgB.pgp
Description: PGP signature

Re: exim really does need to be the standard MTA in slink

[Paul Slootman]

On Tue 06 Oct 1998, Robert Woodcock wrote:
> 
> Just out of curiosity, what's the security track record on smail vs exim
> for the last two years? The standard MTA should have a chance of being
> secure from remote attacks for at least a year after release.

In the words of Philip Hazel (the Exim author):

  I'm not trying to hold up Exim as a great secure system. I have tried my
  best to make it secure within the limits of the way it operates, and to
  describe it as well as I can. The code is there for anyone to read. It
  is up to you to decide whether to run it or not. Of course I am pleased
  when people choose to run my code, but as I am not selling it, I do not 
  have to advertise or try to persuade anybody.

You can read the rest of the story at
http://www.mailbot.com/cgi-bin/archives/getln?eximusr&1998-09&00332 .

I personally have confidence in Exim's quality in this regard.
Demon (a large ISP in the UK and the Netherlands, www.demon.net)
uses Exim as its customer-facing smtp interface, so I guess that they're
convinced as well.


Paul Slootman
-- 
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software,   Enschede,   the Netherlands

Re: [TECH-CONTACTS] Debian

[luther]

On Tue, Oct 06, 1998 at 07:37:43PM -0700, Jim Pick wrote:
> 
> Andrew Howell <[EMAIL PROTECTED]> writes:
> 
> > On Tue, Oct 06, 1998 at 11:49:26PM +0800, Stephen Darragh wrote:
> > > Is there any way to get Debian to rebuild or repair a corrupted
> > > package information database (e.g. on beldin)?
> > 
> > Not that I know of unfortunately. I'll ask on debian-devel as this is
> > something I've wanted a few times as well.
> > 
> > Any ideas Debian guys? :)
> 
> Because the package database is just a bunch of text files, the
> package database is pretty easy to fix.  You can edit/delete files
> that are obviously corrupt (ie. /var/lib/dpkg/status), and use "dpkg
> -i" (possibly with --force- options) to reinstall any packages that
> are messed up.

it would be nice to have a automatic way of doing this, editing
/var/lib/dpkg/status by hand to add a line , a missing Packahge: package_name,
or other like this is not my idea of fun.

> Of course, it's probably a good idea to make a backup before messing
> around with such things.  :-)

another nice feature would be to automatically create the /var/lib/dpkg
hierarchy the first time you use dpkg, I remember having to fix it by hand when
creating a new debian root partition with :

dpkg --root=/newroot -i base/*.deb
  
but then it was some time ago, and i was just
learning dpkg then.

Friendly,

Sven LUTHER

Re: Perl 5.005.02

[Raphael Hertzog]

Le Tue, Oct 06, 1998 at 06:02:18PM -0700, John Lapeyre écrivait:
>   I downloaded the upstream source. It looks like the omission of
> /usr/lib/perl5 in @INC  was intentional.

You're right. But this does mean that all packages installing *.pm
files need to be updated. It does also mean that we will have the same 
problem with perl-5.006 ... we surely a need a better way to handle
this.

The INSTALL file suggest to keep /usr/bin/perl5.00404 so that
programs using old modules will still work. But in fact coexistence
for Debian is not as easy as that. The INSTALL file suppose that modules
are installed manually (eg. with perl -MCPAN -e shell) and that
when installing new modules, the older ones will stay in the old
directory. This is not the case for Debian because when upgrading
a package the old files are removed.

Any idea how to handle this properly ? Maybe we need a sort of perl
policy : package will have to install file under /usr/lib/perl5/debian
which would be a symlink to the current perl version ? But
this does not solve all problems... Better idea ?

Cheers,
-- 
Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/

Re: debian for non linux systems ...

[Martin Schulze]

[EMAIL PROTECTED] wrote:
> Hello,
> 
> I remember some month ago there was a discution some time ago about debian for
> non entirely debian systems (i think it was a debian-solaris thing).
> 
> What happened to it ?
> 
> i was given a ultra sparc 1 with solaris 2.6 here at the university, and
> þerhaps i would like to work on such a thing. (not now, but i a month or 
> so...)

You should grab the dpkg development snapshot from the cvs directory
or ~klee on master.

Regards,

Joey

-- 
There are lies, statistics and benchmarks.

Re: Et toujours dans la langue de chat qui meurt ...

[Samuel Tardieu]

> "Neale" == Neale Pickett <[EMAIL PROTECTED]> writes:

Neale> Translation: What a bad idea to have made only one page in
Neale> French!  I am getting very fed up with English.

Well, the second part sounds more like "English is really not easy for 
me", there was no aggressive tone.

  Sam
-- 
Samuel Tardieu -- [EMAIL PROTECTED]

guile

[Hamish Moffatt]

Unfortunately I know absolutely zero about guile, but need it to build
the latest geda. I'm told I need guile 1.3, which I find in the
package guile1.3, and then I installed libguile3. It wants to run
"build-guile" during configure; libguile3-dev supplies build-guile1.3
(without an alternatives link as is used for guile1.3 -> guile).
I'm told that build-guile has been renamed to guile-config lately too,
but that's not in the contents file.

What should I do?


thanks :-)

hamish

-- 
Hamish Moffatt VK3TYD  [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org

debian for non linux systems ...

[luther]

Hello,

I remember some month ago there was a discution some time ago about debian for
non entirely debian systems (i think it was a debian-solaris thing).

What happened to it ?

i was given a ultra sparc 1 with solaris 2.6 here at the university, and
þerhaps i would like to work on such a thing. (not now, but i a month or so...)

Friendly,

Sven LUTHER

Re: intent to package: gwave, gmos, gnetlist

[Hamish Moffatt]

On Tue, Oct 06, 1998 at 06:49:47PM +1000, Hamish Moffatt wrote:
> I intend to package gwave and gmos, which are to be part of the gEDA
> suite of EDA tools for Linux. gschemrc is already packaged in the
> geda package; it is a schematic capture (entry) program.
> 
> gwave is a waveform viewer which can view the output from some
> spice simualtors. gmos is a MOS transistor simulator.
> Neither of these two are distributed with geda yet, so the geda pkg might
> get renamed gschem at some stage.

The gmos author requests that I leave it until it's a bit more developed,
although he already has RPMs available. Still negotiating.


Hamish
-- 
Hamish Moffatt VK3TYD  [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org

Re: perl5.005 installation structure

[John Lapeyre]

On 7 Oct 1998, Darren/Torin/Who Ever... wrote:
torin>
torin>Yes, sorry I'm a bit slow; I'm working on buying a house.
torin>
torin>I do usually respond quicker to stuff in my inbox than just to list
torin>stuff.

Unacceptable! ;-)  I pulled perl 5.005 out of Incoming over 6 hrs.
ago.  (Actually, I am quite pleased to see responses so quickly :)   )

torin>/usr/lib/perl5 no longer contains *.pm files.  If you're using
torin>MakeMaker and/or pulling stuff from Config.pm, this shouldn't matter;
torin>stuff should just work.

Just wanted to make extra-special sure before I dig into my perl
packages, some of which need help bad in any  case.

John

John Lapeyre <[EMAIL PROTECTED]>
Tucson,AZ http://www.physics.arizona.edu/~lapeyre

Re: perl5.005 installation structure

[Bart Schuller]

On Wed, Oct 07, 1998 at 01:47:51AM -0700, John Lapeyre wrote:
>   Could you confirm or deny, that the /usr/lib/perl5 no longer
> contains *.pm files ? There seems to be some confusion, but on

If this is the case, then the list of packages that have to be changed
grows even larger: I suppose dpkg-perl for example installs into a
directory which is no longer searched by this version.

-- 
The idea is that the first face shown to people is one they can readily
accept - a more traditional logo. The lunacy element is only revealed
subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]

Re: perl5.005 installation structure

[Darren/Torin/Who Ever...]

-BEGIN PGP SIGNED MESSAGE-

John Lapeyre, in an immanent manifestation of deity, wrote:
>   Ah, ... you are reading now.

Yes, sorry I'm a bit slow; I'm working on buying a house.

I do usually respond quicker to stuff in my inbox than just to list
stuff.

>   Could you confirm or deny, that the /usr/lib/perl5 no longer
>contains *.pm files ? There seems to be some confusion, but on

/usr/lib/perl5 no longer contains *.pm files.  If you're using
MakeMaker and/or pulling stuff from Config.pm, this shouldn't matter;
stuff should just work.

Note the following from INSTALL:
>The directories searched by version 5.005 will be
>
>   Configure variable  Default value
>   $archlib/usr/local/lib/perl5/5.005/archname
>   $privlib/usr/local/lib/perl5/5.005
>   $sitearch   /usr/local/lib/perl5/site_perl/5.005/archname
>   $sitelib/usr/local/lib/perl5/site_perl/5.005

>investigation at perl.org, it looks like this is really the case.  Then
>people will not wait for a bug fix which won't come because its not a bug.
I'm hoping to get to debian-devel tonight but I might not.  I'll get to
it tomorrow (Wednesday) afternoon at the latest.

>btw. Looks like some really cool stuff in the new perl.

Yes.  A relatively minor but rather useful one is that perldoc -f now
paginates.

Darren
- -- 
<[EMAIL PROTECTED]>  <[EMAIL PROTECTED]> <[EMAIL 
PROTECTED]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @
@Make a little hot-tub in your soul.  @

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNhsy5I4wrq++1Ls5AQFsswP/QUktgtciNWeGYMFJxy4L5VrhjJ6BVcO5
l5oLAXUcfd2B0hkxDWvir9Cak6iFbtthFQR94iHdpwUuvTXVbxv++8Sdj7HdMwpd
9lVD8EmZVw+zr969UiONQepkDisGIKR4ij5aHYxcYhNv54tpXCj8WEbvuxyEJD1d
tNtkRmUYdO0=
=pUba
-END PGP SIGNATURE-

Re: what's after slink

[warp]

On Tue, Oct 06, 1998 at 11:20:45PM -0700, Chris Waters wrote:

> I think I'd almost rather switch to Red Hat than use the "Beeblebrox"
> release.  I mean, what's next?  Putting pictures of maintainer's pets on
> the Debian web page?  :-)

Let me get some nice pictures of my kitten, taz, she is a cute kitten..

Zephaniah E, Hull, AKA Mercury, <--- Not wanting to file this critical
bug report against APT.. :/

> -- 
> Chris Waters   [EMAIL PROTECTED] | I have a truly elegant proof of the
> or   [EMAIL PROTECTED] | above, but it is too long to fit into
> http://www.dsp.net/xtifr | this .signature file.
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 


pgpnKCiG7a35K.pgp
Description: PGP signature

perl5.005 installation structure

[John Lapeyre]

Ah, ... you are reading now.
Could you confirm or deny, that the /usr/lib/perl5 no longer
contains *.pm files ? There seems to be some confusion, but on
investigation at perl.org, it looks like this is really the case.  Then
people will not wait for a bug fix which won't come because its not a bug.
btw. Looks like some really cool stuff in the new perl.
John

John Lapeyre <[EMAIL PROTECTED]>
Tucson,AZ http://www.physics.arizona.edu/~lapeyre

Re: PERL: patch for glibc 2.1

[Darren/Torin/Who Ever...]

-BEGIN PGP SIGNED MESSAGE-

Matt McLean, in an immanent manifestation of deity, wrote:
>It's no longer needed. 5.00502 now has a configure test for union semun.

Cool.  I thought I had seen that but I figured that I'd leave it for
people that track that much closer.

>I know what's going on with IPC, and I'm guessing the DBM test is failing
>because of a bug in the libc.

So, what's going on with IPC?

Darren
- -- 
<[EMAIL PROTECTED]>  <[EMAIL PROTECTED]> <[EMAIL 
PROTECTED]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @
@Make a little hot-tub in your soul.  @

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNhsnoY4wrq++1Ls5AQEiUwQAmmmHl+IcJIBpouHZkbctimIHSvbMD+/s
bSyIvhtPsSTYNQ7DeTjGO6M6H+aGMhoV16mbEsqsgV2mnXYhgDXIihrZxWYtSdq1
hlg4LhAFhhF9EHYHNXL3n+kCUptzY+74upAdB1CQ50Ujkerfj7Sa7nbyMq4SvOmi
o2IF1zSjUQY=
=N1HO
-END PGP SIGNATURE-

Re: Upgrading to Debian 2.1

[Enrique Zanardi]

On Wed, Oct 07, 1998 at 02:24:46PM +1000, Herbert Xu wrote:
> Nicolás Lichtmaier <[EMAIL PROTECTED]> wrote:
> >
> > Package: nfs-server
> > Implied-by: netbase (< x.x)
> 
> >  This header would only be used by package selection UIs (like apt).
> 
> You can get the same info out of the Replaces header.

We need a few improvements:

- A way to tell dselect (or apt's UI) that a package B_y is just a new version 
  of an old package A_x. dselect should upgrade from A_x to B_y automatically,
  as it would do from A_x to A_x+1, without the user having to select B
  for install and A for purge.
  
- (This is just an extension of the previous idea). A way to tell dselect
  that an old package A_x has been splitted in several, B_y, C_z, ...
  dselect should upgrade from A_x to B_y, C_z, ... automatically. That
  means it should remove A_x and install B_y, C_z, ... (all of them)
  without the user having to select B, C, ... That way all the functionality
  of the previous package A remains after the upgrade (no surprise).
  After the upgrade, the user will be able to remove C_z or B_y if he 
  wants.
 
--
Enrique Zanardi[EMAIL PROTECTED]

Re: Finding a source package

[Guy Maor]

<[EMAIL PROTECTED]>(James A. Treacy) writes:

> It is clearly much more efficient if the .dsc files don't have to be
> retrieved.  This is simply a matter of policy though.

I guess you're talking about different things.  Of course that
package's dsc needs to be downloaded, but Jay fears that all the dsc
would have to be downloaded, perhaps as an index.

I'm suggesting that dpkg-scanpackages scan the dscs and put the
section and version in the Source field, or perhaps add a new field
Dsc which is simply the full path to the dsc, akin to the Filename
field.  Then downloading the source for a package is simple.  The web
pages would use this field too.

> I see no reason not to simply allow multiple versions of source into
> the archive.

It's not so much multiple versions of source in the archive that I
object to.  It's multiple versions of source.  The same source package
should build on all platforms.


Guy

Re: exim really does need to be the standard MTA in slink

[Guy Maor]

"Steve Lamb" <[EMAIL PROTECTED]> writes:

> Supposedly it is about ready to be released.

Using a newly written MTA as our default sounds like a poor idea.


Guy

Re: what's after slink

[Chris Waters]

Matthew Parry wrote:

> I like the Hitch Hikers idea:

I would like to go on record as being *strongly* opposed to the
Hitchhiker's Guide idea.  I really don't want to give the impression
that Debian is some sort of joke.  I also find it extremely unoriginal,
and rather puerile.  (I didn't even find the original all that funny,
though it had moments.)  Nearly anything else would be acceptable, but
let's show a little more maturity than this.  I suppose I should be
thankful that no one has suggested using names from Xanth or Goosebumps,
but great Ghu, surely we can do better.

I think I'd almost rather switch to Red Hat than use the "Beeblebrox"
release.  I mean, what's next?  Putting pictures of maintainer's pets on
the Debian web page?  :-)
-- 
Chris Waters   [EMAIL PROTECTED] | I have a truly elegant proof of the
or   [EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.

Re: what's after slink

[Guy Maor]

David Welton <[EMAIL PROTECTED]> writes:

> There is an ftp://ftp.debian.org/debian/dists/sid, with such recent
> things as debian-arm, so.. I think that's next:->

No, sid is the permanently unstable distribution, where architectures
that have yet to be released live.


Guy

Re: Libtool 1.2b static lib problems

[Ossama Othman]

Hi Gordon,

> The attached patch should work for you if you apply it to ltmain.sh.

The patch worked!  Thank you very much.  Will the patch go into the next
libtool release?  Are you still maintaining libtool?  Someone told me you
weren't.  I am just curious.

Thanks again for the patch!
-Ossama
__
Ossama Othman <[EMAIL PROTECTED]>
58 60 1A E8 7A 66 F4 44  74 9F 3C D4 EF BF 35 88  1024/8A04D15D 1998/08/26

Re: problem w/ the Java interface lib for PostgreSQL

[Ean R . Schuessler]

On Mon, Oct 05, 1998 at 08:03:04PM +0100, Oliver Elphick wrote:
> I'm trying to rebuild libpgjava to depend on jdk1.1.  Unfortunately, I'm
> getting segfaults when I run javac (from jdk1.1-dev), so I am currently
> unable to make a new version.

Another strange thing. When I try to use libpgjava for queries with a
TimeStamp I get a bad TimeStamp format exception. The strange thing is 
that the error only occurs if I use 1.1.6v4, 1.1.6v2 works fine.

I would file a bug against JDK but I haven't really figured out where
the problem is exactly. In java.sql.TimeStamp or something? ???

E

-- 
___
Ean SchuesslerFreak
Novare International Inc. Freak Central
--- Some or all of the above signature may be a joke

wanted: calamaris

[Joey Hess]

Calamaris is an analyzer for squid log files, that generates nice reports.
http://www.detmold.netsurf.de/homepages/cord/tools/squid/calamaris/

I don't have time to package it, though - any takers?

-- 
see shy jo

Re: Better (inc. asynchronous) DNS client (stub resolver)

[Mark W. Eichin]

You might look at the "ares" library (Asynchronous RESolver) that Greg
Hudson <[EMAIL PROTECTED]> wrote...  
athena-dist.mit.edu:/pub/ATHENA/ares/ares-0.3.0.tar.gz  
is the current version.  (At very least, compare notes with him...)

_Mark_ <[EMAIL PROTECTED]>
The Herd Of Kittens

Re: Upgrading to Debian 2.1

[Herbert Xu]

Nicolás Lichtmaier <[EMAIL PROTECTED]> wrote:
>
> Package: nfs-server
> Implied-by: netbase (< x.x)

>  This header would only be used by package selection UIs (like apt).

You can get the same info out of the Replaces header.

-- 
Debian GNU/Linux 2.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Live file system

[Steve Dunham]

Keita Maehara <[EMAIL PROTECTED]> writes:

> > I've been working on a CD specific install that basically delivers a
> > "standard" system with "cp -a" that could be used to also construct a
> > "live" file system. I'll let you know how it works out, if I can ever get
> > back to working on it.

> I've tried to make a live CD called Livian (Live Debian :-)) a few
> weeks ago (It is quite useless and I don't have enough time to improve
> it now though).

> I've untarred base2_0.tgz into a new directory and used dpkg's
> "--admindir" and "--root" options to create a filesystem without
> affecting the real filesystem. Instead of "cp -a", we can have a
> generic method that the live CD creators can make a image as they want
> (just like a new installation).

Actually, it is easiest to untar base2_0.tgz.  Cd into the directory
and do:  
  "chroot . bin/bash" 

Will give you a bash shell in an environment that thinks the current
directory is the root directory, then you can do:

  mount /proc /proc -t proc

and configure and install packages.

(I often use this technique to test glibc 2.1, or install Debian on a
different partition.  At one time I had a machine that was running Red
Hat and Debian at the same time - if you telneted in, you got Debian
and if you used ssh to connect you got Red Hat.)


Steve
[EMAIL PROTECTED]

Re: APT 0.1.6 is released!

[Mark W. Eichin]

> I think you need to install the new nfs-server package.

Yeah, I got bit by that too, and it took me a while to find that...
maybe we need some sort of "transitional-recommends" field?  Something
that is ignored if you are installing the package (to avoid causing
even more pain to dselect users, or something), but noticed on an
upgrade? (obviously it need more subtlety than that, but this might be
a more useful distinction than we've had before for splitting
packages...)

[it is *possible* that nfs-server wasn't even on the mirrors, maybe
because it was new, when the netstd or netbase or whatever used to
have it, dropped it; oh well, that's what "unstable" is all about...]

Re: what's after slink

[Dan Jacobowitz]

On Wed, Oct 07, 1998 at 09:34:46AM +1000, Hamish Moffatt wrote:
> Depends what image you want for the system. The HHGTTG was good,
> but I don't think it is worth naming the releases after it.
> I prefer the penguins.
> 
> BTW, wasn't it "Slartibartfast", one word?

Another vote for penguins.  Speaking of which, anyone want to call a
vote? :)

And yes, it is one word.

Dan

Re: Finding a source package

[treacy]

> <[EMAIL PROTECTED]>(James A. Treacy) writes:
> 
> > Should apt have to download the dsc file for a package before it
> > knows what the source files are?
> 
> Why on earth not?  If it's going to download the source, the .dsc file
> is part of the source and has to be downloaded anyway.
>  
It is clearly much more efficient if the .dsc files don't have to be retrieved.
This is simply a matter of policy though.

> > Suppose one port needs a wildly different version of a program
> > to have it work on that architecture.
> 
> Then they have 2 options: 
> 
> (1) Do dirty disgusting hacks like I did for binutils on m68k.  (Do a
> binary upload of the different version, ignore the source from
> then on [\begin{plug}trivially with quinn diff\end{plug}])[1]
> 
> (2) Upload a new source package with a different name, e.g. foo2.1 as
> opposed to foo or whatever.  (Already done for, e.g. glibc)
> 
These are both hacks (in the bad sense of the word. Kluge is a better
word, but many people won't know it). I see no reason not to simply allow
multiple versions of source into the archive.

Jay Treacy

Re: How about using bzip2 as the standard *.deb compression format?

[Joey Hess]

Joseph Carter wrote:
> I doubt it would compile on my 4 meg 486.
> 
> Nor would it run there.

I've ran X on 2 mb. (shoot me.. please.. ;-)

-- 
see shy jo

Re: [TECH-CONTACTS] Debian

[Jim Pick]

Andrew Howell <[EMAIL PROTECTED]> writes:

> On Tue, Oct 06, 1998 at 11:49:26PM +0800, Stephen Darragh wrote:
> > Is there any way to get Debian to rebuild or repair a corrupted
> > package information database (e.g. on beldin)?
> 
> Not that I know of unfortunately. I'll ask on debian-devel as this is
> something I've wanted a few times as well.
> 
> Any ideas Debian guys? :)

Because the package database is just a bunch of text files, the
package database is pretty easy to fix.  You can edit/delete files
that are obviously corrupt (ie. /var/lib/dpkg/status), and use "dpkg
-i" (possibly with --force- options) to reinstall any packages that
are messed up.

Of course, it's probably a good idea to make a backup before messing
around with such things.  :-)

Cheers,

 - Jim

Re: Better (inc. asynchronous) DNS client (stub resolver)

[Marc Singer]

> I'm halfway through implementation, but it occurred to me that some
> people might like to comment on my proposed API.  So, below you'll
> find a prototype of the header file.  You'll notice I haven't given it
> a proper software licence yet, but the library itself will be GPL'd.
> 
> If you have some requirement you don't think would be addressed by the
> API presented below let me know.  If you don't understand the API
> below then I'm afraid I can't help you atm - I haven't written the
> documentation yet.

It looks right to me.  I wonder why you called adns_interest such.
Isn't is a variant of select, perhaps a preselect?  I'm a fan of the
philosophy that if it looks like a mouse, smells like a mouse

BTW, I'm glad you're doing this.  The synchronous nature of libresolv
requires me to explain lots of things to my clients that I'd rather be
obviated by a proper library.

Re: lyx?

[Paul Seelig]

I've made by the way a quick'n'dirty updated package of the current
lyx-0.12.1pre8 which already contains this LaTeX importing feature.
Seems to be working very well with the LaTeX files i tried out so far:

 ftp://ietpd1.sowi.uni-mainz.de/pub/debian/unofficial/{binary,source}

If you'd like to you could possibly use this as a base for a new lyx
version for slink? I think it's definitely worth an update anyway.

 Cheers, P. *8^)
-- 
   - Paul Seelig <[EMAIL PROTECTED]> ---
   African Music Archive - Institute for Ethnology and Africa Studies
   Johannes Gutenberg-University   -  Forum 6  -  55099 Mainz/Germany
   --- http://www.uni-mainz.de/~pseelig -

Intent to package dadadodo

[Sudhakar Chandrasekharan]

[NOTE: Bcc-ing [EMAIL PROTECTED] because I don't want wnpp to be spammed
with any discussion about this]

For more info on the software see http://www.jwz.org/dadadodo/

Source: dadadodo
Section: text
Priority: optional
Maintainer: Sudhakar Chandrasekharan <[EMAIL PROTECTED]>
Description: Exterminates all rational thought
 Dadadodo is a program that analyses texts for word probabilities,
 and then generates random sentences based on that. Sometimes these 
 sentences are nonsense; but sometimes they cut right through to the 
 heart of the matter, and reveal hidden meanings. 

Copyright:
/* DadaDodo, Copyright (c) 1997, 1998 Jamie Zawinski <[EMAIL PROTECTED]>
 *
 * Permission to use, copy, modify, distribute, and sell this software
and its
 * documentation for any purpose is hereby granted without fee, provided
that
 * the above copyright notice appear in all copies and that both that
 * copyright notice and this permission notice appear in supporting
 * documentation.  No representations are made about the suitability of
this
 * software for any purpose.  It is provided "as is" without express or 
 * implied warranty.
 */

It seems like it is DFSG compliant to me.

S.
-- 
 "This barbecue will be hard, thankless work.  But I am sure you are
   up to it Marge." -- Homer J. Simpson
Sudhakar C13n   http://people.netscape.com/thaths/   Indentured Slave

Re: Live file system

[Joseph Carter]

On Tue, Oct 06, 1998 at 03:40:24PM -0400, Dale Scheetz wrote:
> > IIRC Dale Scheetz used to have one for bo (sorry if I'm wrong, Dale :)
> > 
> Well, not exactly. What I do is an imbedded file system that can be
> installed on a DOS/Windows/'95 file system as simple files and booted with
> a special patched kernel using the loop device. BTW, DiD is available in
> hamm as well as bo versions for anyone interested ;-)

The way I see to do this

You have boot files on the CD, like you would on a rescue floppy, in fact
you COULD have a rescue floppy, but that rescue floppy would have a much
simpler install function...  To install, just figure out where user wants
this stuff to be and create a Debian dir for them on the filesystem they
choose which will have an initrd and stuff, and then build them a ext2 image
with extra space for /, with /etc and /var and an empty /usr.

The initrd's job?  Mount the filesystem (probably msdos or vfat) and set up
the loopback fs so it'll be mounted as root.  The init stuff for the
loopback root of course mounts your cdrom someplace and makes /usr be what's
on the live filesystem..

You now have canned Debian in about 30-50 megs HD space.


The same technique could be used for a no-partitioning-needed installation
(someone posted a message about that, forget who)


Take that and add a way for the initrd to find the device containing the
loopback / image and you'll have the basis for Debian on things like Zip and
Superdisks that can be downloaded and unpacked to the disk and it'll set
itself up even as bootable, etc.

Why do that?  My rescue zip disk project, which I WILL get back to at some
point.  I had gotten as far as an idea of how to do the part you've
apparently done already---the / loopback deal---and was trying to figure out
a good way to find the image from the initrd..  Maybe some magic filenames
or something, I have no idea how best to do it actually.


pgpKD1RcTFl4f.pgp
Description: PGP signature

Better (inc. asynchronous) DNS client (stub resolver)

[Ian Jackson]

I didn't much like libresolv, so I decided I would write a stub
resolver.  In particular, it will make it much easier to make DNS
queries for various kinds of record and get the information you
actually wanted, and it will be useable asynchronously (ie in programs
with a select loop).

I'm halfway through implementation, but it occurred to me that some
people might like to comment on my proposed API.  So, below you'll
find a prototype of the header file.  You'll notice I haven't given it
a proper software licence yet, but the library itself will be GPL'd.

If you have some requirement you don't think would be addressed by the
API presented below let me know.  If you don't understand the API
below then I'm afraid I can't help you atm - I haven't written the
documentation yet.

/*
 * Copyright (C)1998 Ian Jackson.
 * This version provided for review and comment only.
 *
 * $Id: adns.h,v 1.18 1998/10/07 00:53:53 ian Exp $
 */

#ifndef ADNS_H_INCLUDED
#define ADNS_H_INCLUDED

#include 

#include 
#include 

typedef struct adns__state *adns_state;
typedef struct adns__query *adns_query;

typedef enum {
  adns_if_noenv=0x0001, /* do not look at environment */
  adns_if_noerrprint=   0x0002, /* never print output to stderr (_debug 
overrides) */
  adns_if_noserverwarn= 0x0004, /* do not warn to stderr about duff nameservers 
etc */
  adns_if_debug=0x0008, /* enable all output to stderr plus debug msgs 
*/
  adns_if_noautosys=0x0010, /* do not make syscalls at every opportunity */
} adns_initflags;

typedef enum {
  adns_qf_search= 0x0001, /* use the searchlist */
  adns_qf_usevc=  0x0002, /* use a virtual circuit (TCP connection) */
  adns_qf_anyquote=   0x0004,
  adns_qf_loosecname= 0x0008, /* allow refs to CNAMEs - without, get _s_cname */
  adns_qf_nocname=0x0010, /* don't follow CNAMEs, instead give _s_cname */
} adns_queryflags;

typedef enum {
  adns__rrt_typemask=  0x0,
  adns__qtf_deref= 0x1, /* dereference domains and perhaps produce 
extra data */
  adns__qtf_mail822=   0x2, /* make mailboxes be in RFC822 rcpt field 
format */
  adns__qtf_masterfmt= 0x8, /* convert RRs to master file format, return as 
str */
  
  adns_r_none=   0,
  
  adns_r_a=  1,
  adns_r_a_mf=  adns_r_a|adns__qtf_masterfmt,
  
  adns_r_ns_raw= 2,
  adns_r_ns=adns_r_ns_raw|adns__qtf_deref,
  adns_r_ns_mf= adns_r_ns_raw|adns__qtf_masterfmt,
  
  adns_r_cname=  5,
  adns_r_cname_mf=  adns_r_cname|adns__qtf_masterfmt,
  
  adns_r_soa_raw=6,
  adns_r_soa=   adns_r_soa_raw|adns__qtf_mail822, 
  adns_r_soa_mf=adns_r_soa_raw|adns__qtf_masterfmt,
  
  adns_r_null=  10,
  adns_r_null_mf=   adns_r_null|adns__qtf_masterfmt,
  
  adns_r_ptr_raw=   12,
  adns_r_ptr=   adns_r_ptr_raw|adns__qtf_deref,
  adns_r_ptr_mf=adns_r_ptr_raw|adns__qtf_masterfmt,
  
  adns_r_hinfo= 13,  
  adns_r_hinfo_mf=  adns_r_hinfo|adns__qtf_masterfmt,
  
  adns_r_mx_raw=15,
  adns_r_mx=adns_r_mx_raw|adns__qtf_deref,
  adns_r_mx_mf= adns_r_mx_raw|adns__qtf_masterfmt,
  
  adns_r_txt=   16,
  adns_r_txt_mf=adns_r_txt|adns__qtf_masterfmt,
  
  adns_r_rp_raw=17,
  adns_r_rp=adns_r_rp_raw|adns__qtf_mail822,
  adns_r_rp_mf= adns_r_rp_raw|adns__qtf_masterfmt
  
} adns_rrtype;

/* In queries without qtf_anyquote, all domains must have standard
 * legal syntax.  In queries _with_ qtf_anyquote, domains in the query
 * or response may contain any characters, quoted according to
 * RFC1035 5.1.  On input to adns, the char* is a pointer to the
 * interior of a " delimited string, except that " may appear in it,
 * and on output, the char* is a pointer to a string which would be
 * legal either inside or outside " delimiters, and any characters
 * not usually legal in domain names will be quoted as \X
 * (if the character is 33-126 except \ and ") or \DDD.
 *
 * _qtf_anyquote is ignored for _mf queries.
 *
 * Do not ask for _raw records containing mailboxes without
 * specifying _qf_anyquote.
 */

typedef enum {
  adns_s_ok,
  adns_s_timeout,
  adns_s_nolocalmem,
  adns_s_allservfail,
  adns_s_servfail,
  adns_s_notimplemented,
  adns_s_refused,
  adns_s_reasonunknown,
  adns_s_norecurse,
  adns_s_serverfaulty,
  adns_s_unknownreply,
  adns_s_max_tempfail= 99,
  adns_s_inconsistent, /* PTR gives domain whose A does not match */
  adns_s_cname, /* CNAME found where data eg A expected (not if _qf_loosecname) 
*/
  /* fixme: implement _s_cname */
  adns_s_max_remotemisconfig= 199,
  adns_s_nxdomain,
  adns_s_nodata,
  adns_s_invaliddomain,
  adns_s_domaintoolong,
} adns_status;

typedef struct {
  char *dm;
  adns_status astatus;
  int naddrs; /* temp fail => -1, perm f

Re: Perl 5.005.02

[John Lapeyre]

On Tue, 6 Oct 1998, Raphael Hertzog wrote:

rhertz>Well it doesn't work out of the box as I expected it. First the
rhertz>@INC isn't correct, it doesn't contain /usr/lib/perl5. Please
rhertz>Darren can you correct it ?

I downloaded the upstream source. It looks like the omission of
/usr/lib/perl5 in @INC  was intentional.

>From INSTALL:
=head1 Coexistence with earlier versions of perl5

WARNING:  The upgrade from 5.004_0x to 5.005 is going to be a bit
tricky.  See L<"Upgrading from 5.004 to 5.005">  below.

Re: How about using bzip2 as the standard *.deb compression format?

[Joseph Carter]

On Tue, Oct 06, 1998 at 03:50:01PM -0500, John Goerzen wrote:
> This is silly.  dpkg/dselect are already insanely slow, even on my
> P166 with 128 meg of RAM -- especially when reading database, etc.  If 
> we slow down the installation so much more by using bzip2, then people 
> will simply stop upgrading, or switch to other distributions because
> it is so slow.  That is not acceptable.

Um, not all of us are using dselect/dpkg.  Most of us refuse to because it's
insanely slow and generally braindead if you have a serious conflict.  I use
dselect/apt myself.


pgpNPlhjmG8xs.pgp
Description: PGP signature

Re: [TECH-CONTACTS] Debian

[Andrew Howell]

On Tue, Oct 06, 1998 at 11:49:26PM +0800, Stephen Darragh wrote:
> Is there any way to get Debian to rebuild or repair a corrupted
> package information database (e.g. on beldin)?

Not that I know of unfortunately. I'll ask on debian-devel as this is
something I've wanted a few times as well.

Any ideas Debian guys? :)

Andrew

-- 
Dehydration - 34%, Recollection of previous evening - 2%, embarrassment
factor - 91%.  Advise repair schedule:- off line for 36 hours, re-boot
startup disk, and replace head - wow, what a night!
-- Kryten in Red Dwarf `The Last Day'

Andrew Howell
Perth, Western Australia   [EMAIL PROTECTED]