Re: Intent to package: eggdrop

[Remco Blaakmeer]

On Tue, 5 May 1998, Johnie Ingram wrote:

> 
> This software has served the #debian channel for over 9 months, and is GPL.
> >From the README:
> 
> Eggdrop is an IRC bot, written in C.  If you don't know what IRC is,
> this is probably not whatever you're looking for!  Eggdrop, being a
> bot, sits on a channel and takes protective measures: to keep the
> channel from being taken over (in the few ways that anything CAN),
> to recognize banished users or sites and reject them, to recognize
> priveledged users and let them gain ops, etc.

This has been discussed before, after you proposed to do this on 'Mon, 17
Nov 1997 07:34:31 -0500'. The outcome was that it might be too dangerous
to package a program that can do as much damage as an IRC bot can do when
it is improperly configured. You might want to check out the discussion at
http://www.nl.debian.org/Lists-Archives/debian-devel-9711/threads.html#00801

The consensus about this may have changed since then, so I'm not saying
you should not package it. However, think twice and discuss it on
debian-devel before you do so.

Remco


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

PGP

[The Gecko]

Ok... I can't seem to find a linux PGP program -- commercial, shareware,
freeware, open source, GPL, anything... can any one point me in the right
direction

--
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++> E? W+++$ N+(-) o? K- w+++$(--)
O M-- V- PS-- PE++ Y++ PGP++ t+ 5 X R+ !tv b
 DI+++ D++ G++>G+++ e h+ r* y+
--END GEEK CODE BLOCK--
--


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

Re: PGP

[Will Lowe]

On Tue, 5 May 1998, The Gecko wrote:

> Ok... I can't seem to find a linux PGP program -- commercial, shareware,
> freeware, open source, GPL, anything... can any one point me in the right
> direction

http://www.debian.org/doc/FAQ/debian-faq-5.html#ss5.11
Will


--
| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]   |
|   http://www.cis.udel.edu/~lowe/   |
|PGP Public Key:  http://www.cis.udel.edu/~lowe/index.html#pgpkey|
--
|   You think you're so smart,  but I've seen you naked  |
|  and I'll prob'ly see you naked again ...  |
| --The Barenaked Ladies,  "Blame It On Me"  |
--


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

Re: PGP

[LeRoy D. Cressy]

The Gecko wrote:
> 
> Ok... I can't seem to find a linux PGP program -- commercial, shareware,
> freeware, open source, GPL, anything... can any one point me in the right
> direction
> 

There is a list of sites that contain Debian files where to get
pgp and such programs located at:

http://www.debian.org/misc/README.non-US

These sites contain files that cannot be exported from the US, but
you can import them.  GO FIGURE???  
-- 
  0 0  L & R Associates
   "   Home Page:http://www.netaxs.com/~ldc/
___ooO ~ Ooo___

LeRoy D. Cressy  /\_/\  [EMAIL PROTECTED]
Computer Consulting ( o.o ) Phone (215) 535-4037
 > ^ <  Fax   (215) 535-4285


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

Debian volunteers needed for Atlanta Linux Showcase

[Robert Edmonds]

Volunteers are needed for October's ALS. I already have several possible
people that can man the booth. We need people around, or close to the
Atlanta area to be able to help man the booth (bring your screamer box,
etc.) and also less obvious donations. Redhat will be there with its
ubiquitious free CDs. We need LSL or someone to donate a couple hundred
CDs (attendance to ALS is expected to be 1000 or so), preferably a CD
manufacturer who can press them cheaply. We also need literature,
brochures, etc. we can pass out to people.

As ALS will be held on October 23 and 24, we'll hope to be passing out
*hamm* CDs... ;)

--
Robert S. Edmonds
-
Debian developerhttp://www.debian.org
Freshmeat staff member   http://freshmeat.net
[EMAIL PROTECTED] / http://www.smart1.net/edmonds
-


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

Re: [dpkg] Installing software as a non privileged user - A suggestion

[G John Lapeyre]

This is a great idea.Sysadmins can't keep up with the needs of
an experienced user.
I am almost sure dpkg won't do this now.  There will be all sorts
of problems with locations of files. To make sure every package 
supports this would add complexity and burden.
We could have something that makes a best guess on how to install
it, with no burden on the maintainer to make sure it works.  
Developers will probably oppose this because it doesn't allow to
aspire to perfection.
But, in  a less than perfect world (this one) it would be a good
idea.
Now, ... who is going to write it


 Sudhakar Chandrasekharan wrote:

> I don't know if this has been discussed here before.
> 
> Is it possible for a non privileged user to use dpkg to install a package
> under the user's home directory?  I know this kind of installation is not
> perfect.  But sometimes it is helpful.  What are the pros and cons of this
> kind of an approach?

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


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

Re: [dpkg] Installing software as a non privileged user - A suggestion

[Jules Bean]

--On Tue, May 5, 1998 5:52 pm -0700 "G John Lapeyre"
<[EMAIL PROTECTED]> wrote: 

> 
> 
>   This is a great idea.Sysadmins can't keep up with the needs of
> an experienced user.
>   I am almost sure dpkg won't do this now.  There will be all sorts
> of problems with locations of files. To make sure every package 
> supports this would add complexity and burden.
>   We could have something that makes a best guess on how to install
> it, with no burden on the maintainer to make sure it works.  


You are going to have a big problem though.  Almost all programs have at
least one path hard-compiled into them (e.g. the location of their config
file in /etc) which is going to make them impossible for users to install.

Perhaps a more workable idea is to have some packages which users are more
likely to want (i.e. applications, not servers) also available as special
'non-root' debs...

Jules


/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka |   |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/



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

Re: Coming to closure on ae...

[Jules Bean]

--On Wed, May 6, 1998 1:45 am +0200 "Remco Blaakmeer"
<[EMAIL PROTECTED]> wrote: 

> On Tue, 5 May 1998, Carlos Barros wrote:
> 
>> On Wed, 6 May 1998, Anand Kumria wrote:
>> 
>>   > On Sat, 2 May 1998, Dale Scheetz wrote:
>>   > 
>>   > > There doesn't seem to be a "reliable" method for determining
whether or
>>   > > not you are in an xterm. Any method so far suggested has "natural" 
>>   > > configuration situations that break the method.
>>   > 
>>   >   How about just checking for the existance of the DISPLAY variable?
>>   > 
>> 
>> What about trying to connext to X server, and if an error, do it in
>> terminal mode.
> 
> That doesn't work properly when working from a console if you have access
> rights to a local X server. The same goes for testing the DISPLAY
> variable. The only other way I can come up with is checking the WINDOWID
> variable. Or look at how 'elvis' determines if it's running in X or not. I
> don't know how elvis checks for X, but it does this quite well.
> 

The original problem has been resolved, but there is an important point
here, I think.

As far as possible, we shouldn't be playing games like this.  It violates
the principle of least surprise (IMHO).

There are very few cases when an xterm should be handled differently from a
console.  If I unset DISPLAY in an xterm, I do it deliberately - I don't
want X to be used by programs.  If a clever program works out that X is
there and uses it anyway, I'm going to be annoyed.  Similarly, my vc
sessions won't normally have a DISPLAY set.  If they do, it's because I for
some reason want to use X with my apps started from a console.

I think an xterm should be exactly like a VC in almost every case I can
bring to mind.  Which is why this backspace/delete thing is so annoying...

Yours,

Jules


/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka |   |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/



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

Re: Apt is cool (yay!) - What about bo?

[Jason Gunthorpe]

On Tue, 5 May 1998, Joost Kooij wrote:

> I love the staus display too. It is a bit "jumpy" though, maybe you want
> to printf the numbers etc. in a fixed-size field. Oh, and an expected TOA
> per package would be a nice finishing touch (I'm getting carried away I
> guess ;-).

I was thinking of right aligning the ETA and CPS on the line, that would
help with alot of the jumping. I could use a 4 digit field for the current
size, but on large files that would not update very often..
What is a TOA? (ETA you mean?)
 
> One thing though: when I installed apt 0.8, it replaced deity (I
> had even forgotten that I still had that.) When I ran dselect and
> exited the select screen, it complained about apt and deity conflicting. I
> think deity should have been gone by then? (It showed up -*- in the
> conflict screen.) Maybe it is related to this:
>   /var/lib/dpkg/info/deity.postrm: [: --: binary operator expected

Yeah, very few people had installed the deity deb so this was never fixed,
you need to edit the postrm to fix the problem and then remove the deity
package.

Jason


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

Re: dpkg-http and proxy cache

[Drake Diedrich]

On Tue, May 05, 1998 at 08:25:44PM +0200, [EMAIL PROTECTED] wrote:
> 
> i have squid cache
> i have dpkg-http
> 
> there was a time, when it worked. i could do [U]pdate in dselect, and he
> used the version of Packages.gz in the Cache.
> i can check that he uses the cache, because if i stop the cache, he fails.
> i can check, that the cache caches the file with Netscape.
> 
> but i do not know, why dpkg-http doesn't take the cached version !

   It's probably a result of:
dpkg-http (0.13) unstable; urgency=low
  * Added Cache-Control headers to make Packages.gz very current (max_age=0)
and *.deb very cachable (max_stale=1 year)

  Starting with 0.13, dpkg-http requests the upstream site to compare the
age of the Packages.gz file, and download a new one only if necessary.
ftp doesn't handle dates very gracefully, and squid may be downloading a new
copy even when unnecessary.  Some possible fixes:
1) configure squid to hold onto stale objects longer.  (wrong)
2) point your squid at your ISP's web cache, and let them do the
   download every time.  (somebody else's problem)
3) modify dpkg-http to set different Cache-Control values. (wrong)
4) modify squid/ftpget to support timestamps on ftp sites. (right.  Hard.)
5) Modify LWP (used by dpkg-http) to handle If-Modified-Since gets from 
   an ftp site.  Stop using squid with dpkg-http.  (right. hard.)
6) Use an http: mirror and avoid the problem.

   On the other hand, Packages.gz does change frequently, and new versions
should be downloaded when available.  There's no cure if this is the
problem.  Take a look at /var/log/squid/access.log to see exactly what squid
did about each request.


--
Dr. Drake Diedrich, Research Officer - Computing, (02)6279-8302
John Curtin School of Medical Research, Australian National University 0200
Replies to other than [EMAIL PROTECTED] will be routed off-planet


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

apt and caching .deb's

[G John Lapeyre]

Apt downloads all the packages and then installs them.  Every RH
and Debian network method I've seen does this.  Is there a way to download
a package, install it and throw the deb away, to save disk space ?  
If I wait too long between upgrades, I run into big problems.

Otherwise apt is impressive.   When I show someone how it quietly
upgrades 100 packages, it impresses the hell out of them.

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


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

Re: apt and caching .deb's

[Jason Gunthorpe]

On Tue, 5 May 1998, G John Lapeyre wrote:

>   Apt downloads all the packages and then installs them.  Every RH
> and Debian network method I've seen does this.  Is there a way to download
> a package, install it and throw the deb away, to save disk space ?  
>   If I wait too long between upgrades, I run into big problems.

I have been thinking of a limiting option, set the size of your scratch
space and then it will pull back that many, install, erase, continue.

Long, long way off though.
 
Jason


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

Re: hamm

[James R. Van Zandt]

Bob Hilliard <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] writes:
>> Trying to upgrade via FTP to hamm would be too painfull at 28.8KB!
>
>Hi, 
> It depends on your pain threshold, I guess.  I thought that too,
>until I started the bo testihng program a little over a year ago.
>Since then I have updated from rex to bo, then bo to hamm, and am
>maintaining a hamm and slink mirror (i386 binary only), all over a
>28.8 link.

I maintain a hamm mirror at work.  According to my records, the
traffic to keep hamm up to date amounts to about 20 MB/day.

 - Jim Van Zandt


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

Re: Apt is cool (yay!) - What about bo?

[Manoj Srivastava]

Hi,

I also experimented with a veruy wide xterm, and doscovered
 that apt truncates the status line ;-(  (I personally would not mind
 a wrapped line, or a long line, so I know what is going on rather
 than 'Waiting to coneect to blah.blah.blah.blah
 (122.122.122.122)'. Not that I am complaining, mind you.

manoj
-- 
 /* we have tried to make this normal case as abnormal as possible */
 --Larry Wall in cmd.c from the perl source code
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: Intent to package: eggdrop

[Manoj Srivastava]

Hi,

I guess we shold also remove rm. That program can be downright
 nasty in the hands of the uninitiated. What about mkfs? oh, man, the
 kind of damage _that_ does. Oh, you say that that can only harm the
 local machine? Well, we should take away all the MTA's then (is spam
 not 80% of all traffic now?). And all the mail user againts (quite
 dangerous in the hands of the uninitiated, and can reall mess up
 peoples mailboxes).

Since when have we refused to package things cause they are
 ``dangerous'' or not the right religion? Stopping egg drop is a bad
 precedent (it is not as if egg drop is not freely available at
 that). 

If you do not make mistakes, you can't learn that much
 either. 

>>"Remco" == Remco Blaakmeer <[EMAIL PROTECTED]> writes:

Remco> This has been discussed before, after you proposed to do this
Remco> on 'Mon, 17 Nov 1997 07:34:31 -0500'. The outcome was that it
Remco> might be too dangerous to package a program that can do as much
Remco> damage as an IRC bot can do when it is improperly
Remco> configured. You might want to check out the discussion at
Remco> 
http://www.nl.debian.org/Lists-Archives/debian-devel-9711/threads.html#00801

Remco> The consensus about this may have changed since then, so I'm
Remco> not saying you should not package it. However, think twice and
Remco> discuss it on debian-devel before you do so.

In this case, I think the consensus would not be achievable. I
 for one shall oppose any attempts to bann a package cause it may be
 to dangerous for our users. This is not an elite cabal. I see that
 netgod has already uploaded; if he backs out, take this as an intent
 to package eggdrop.

I apologize of this sounds confrontational; that was not my
 intent, but it has begun to sound that way (even to me ;-)

manoj


-- 
 New York is a jungle, they tell you.  You could go further, and say
 that New York is a jungle.  New York *is a jungle.* Beneath the
 columns of the old rain forest, made of melting macadam, the mean
 Limpopo of swamped Ninth Avenue bears an angry argosy of crocs and
 dragons, tiger fish, noise machines, sweating rainmakers.  On the
 corners stand witchdoctors and headhunters, babbling voodoo-men --
 the natives, the jungle-smart natives. And at night, under the
 equatorial overgrowth and heat-holding cloud cover, you hear the
 ragged parrot-hoot and monkeysqueak of the sirens, and then fires
 flower to ward off monsters.  Careful: the streets are sprung with
 pits and nets and traps.  Hire a guide.  Pack your snakebite gook and
 your blowdart serum.  Take it seriously.  You have to get a bit
 jungle-wise. Martin Amis, _Money_
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: Apt is cool (yay!) - What about bo?

[Jason Gunthorpe]

On 5 May 1998, Manoj Srivastava wrote:

>   I also experimented with a veruy wide xterm, and doscovered
>  that apt truncates the status line ;-(  (I personally would not mind
>  a wrapped line, or a long line, so I know what is going on rather
>  than 'Waiting to coneect to blah.blah.blah.blah
>  (122.122.122.122)'. Not that I am complaining, mind you.

I would like to put a nice simple check for screen size in there, right
now it limits to 78 chars end of story. I suppose I should look at the
slang source and see how it's done.

Without something like slang I can't wrap the line or anything fancy like
that.

Jason


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

Re: Bug#21969: debian-policy: needs clarification about Standards-Version

[Bill Leach]

Manoj, you are really 'hitting the nail on the head' with the 
stuff that you have written lately (and I will admit to not
necessarily recogniaing the significance of what you have 
written in the recent past)...

On Mon, May 04, 1998 at 01:01:17AM -0500, Manoj Srivastava wrote:
> Hi,
> >>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
> 
> Raul> Policy SHOULD be followed, in the general case. I'd even ...
[snip]
>   Well, at least that is a starting point.
> 
>   I would be willing to say that we leave determination of the
>  point when following policy is detrimental to the package to the
>  maintainers themselves; so Dale could decide that stripping the
>  binaries is detriental to his package.
> 
>   At thsi point, one should point this out to the maintainer
>  community at large (in case another person is in the same boat and
>  has not yet realized that policy is broken), and, since people are
>  human and may err, and the maintainer who originally thought the
>  policy is flawed may be wrong, and quite possibly the colective
>  intellect of the maintainer community may prove helpful.
> 
>   I think that we can't come up with a set of tests a priori to
>  determine how to determine when the rules ("Policy Document") are
>  flawed, and we trust the judgement of the develoers when they think
>  it is time to examine aspects of the Policy Documents.
> 
>   In any case, the Policy documents should be amended so that
>  the rest of the maintainers benefit from it as well.

This is the essence of what personally I did NOT see (or recognize) in
your earlier postings.

Any project, anywhere, under any development 'style' there is and will 
always be the possibillity that some either truely brilliant person or
'some idiot' will participate that 'will not'/or 'can not' contribute
to a joint effort project.  Some people have "ego's" that are so 
fragile that any suggestion that they might not be the 'source of all
wisdom' is 'time for war'.  That however, is NOT the case for the 
typical Debian developer.  'Hard headed', maybe... 'blind', No!

Indeed the current 'guidelines' are not want produced that 'debian
way' but rather are the codification of what the 'debian way' as it
exists(ed).

It is a mistake to think in terms of 'debian policy' as something
that 'is handed down from on high'.  It is not such a thing.  It should
be a 'living document' as I think Manoj has suggested.  It is also
at least just as important to remember that while inspiration might
be (even properly be) credited to one person the development itself is 
and has really always been the efforts of many.

As I read what Manoj is saying, it appears that Manoj is saying that
the deveolper community is responsible for debian policy in the same
fashion as they are responsible for their packages.  What a simple and
elegant concept!


-- 
best,
-bill
[EMAIL PROTECTED]
   [EMAIL PROTECTED]  [EMAIL PROTECTED]
from a 1996 Micro$loth ad campaign:
"The less you know about computers the more you want Micro$oft!"
 See!  They do get some things right!


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

Re: Debian volunteers needed for Atlanta Linux Showcase

[vaidhy]

Hi! 

I am at Atlanta and a potential developer. I am willing to man the booth


Please let me know !!!

Thanks,
Vaidhy

> From [EMAIL PROTECTED] Tue May  5 18:49:48 1998
> Return-Path: [EMAIL PROTECTED]
> Received: from murphy.debian.org (murphy.novare.net [205.229.104.6]) by 
> mail.wwdg.com (8.8.5/8.8.0) with SMTP id SAA12155 for <[EMAIL PROTECTED]>; 
> Tue, 5 May 1998 18:49:46 -0600
> Received: (qmail 12027 invoked by uid 38); 6 May 1998 00:49:31 -
> Resent-Date: 6 May 1998 00:49:31 -
> Resent-Cc: recipient.list.not.shown:;
> X-Envelope-Sender: [EMAIL PROTECTED]
> Received: (qmail 12006 invoked from network); 6 May 1998 00:49:27 -
> Received: from mx1.freewwweb.com ([EMAIL PROTECTED])
>   by murphy.novare.net with SMTP; 6 May 1998 00:49:27 -
> Received: from stu ([EMAIL PROTECTED] [209.64.214.134])
>   by mx1.freewwweb.com (8.8.5/8.8.5) with SMTP id UAA26211
>   for ; Tue, 5 May 1998 20:53:39 -0400 
> (EDT)
> Date: Tue, 5 May 1998 20:48:33 -0400 (EDT)
> From: Robert Edmonds <[EMAIL PROTECTED]>
> X-Sender: [EMAIL PROTECTED]
> To: debian-devel@lists.debian.org
> Subject: Debian volunteers needed for Atlanta Linux Showcase
> Message-ID: <[EMAIL PROTECTED]>
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> Resent-Message-ID: <"fCHbJD.A.07C.aO7T1"@murphy>
> Resent-From: debian-devel@lists.debian.org
> X-Mailing-List:  archive/latest/4211
> X-Loop: debian-devel@lists.debian.org
> Precedence: list
> Resent-Sender: [EMAIL PROTECTED]
> 
> Volunteers are needed for October's ALS. I already have several possible
> people that can man the booth. We need people around, or close to the
> Atlanta area to be able to help man the booth (bring your screamer box,
> etc.) and also less obvious donations. Redhat will be there with its
> ubiquitious free CDs. We need LSL or someone to donate a couple hundred
> CDs (attendance to ALS is expected to be 1000 or so), preferably a CD
> manufacturer who can press them cheaply. We also need literature,
> brochures, etc. we can pass out to people.
> 
> As ALS will be held on October 23 and 24, we'll hope to be passing out
> *hamm* CDs... ;)
> 
> --
> Robert S. Edmonds
> -
> Debian developerhttp://www.debian.org
> Freshmeat staff member   http://freshmeat.net
> [EMAIL PROTECTED] / http://www.smart1.net/edmonds
> -
> 
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 


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

Intent to package SAML (math)

[G John Lapeyre]

This is GPL'd, the package is nearly finished.

Description:
   SAML is a C library for symbolic calculations, accompanied
by some application programs (samuel, factorint, induce),
and Python bindings.
The library provides an object-oriented framework for
defining and handling mathematical types, and implements
the most common data types of computer algebra: integers,
reals, fractions, complex numbers, polynomials, tensors,
matrices, etc.
The application programs consist of an interactive symbolic
calculator (samuel), a programming language (induce) and
a program to factorize integers (factorint).


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


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

Re: Intent to package: eggdrop

[Remco Blaakmeer]

On 5 May 1998, Manoj Srivastava wrote:

> Hi,
> 
>   I guess we shold also remove rm. That program can be downright
>  nasty in the hands of the uninitiated. What about mkfs? oh, man, the
>  kind of damage _that_ does. Oh, you say that that can only harm the
>  local machine? Well, we should take away all the MTA's then (is spam
>  not 80% of all traffic now?). And all the mail user againts (quite
>  dangerous in the hands of the uninitiated, and can reall mess up
>  peoples mailboxes).
> 
>   Since when have we refused to package things cause they are
>  ``dangerous'' or not the right religion? Stopping egg drop is a bad
>  precedent (it is not as if egg drop is not freely available at
>  that). 
> 
>   If you do not make mistakes, you can't learn that much
>  either. 

I know why you are so cynical and you may be right. It was not me who
actively opposed to the packaging of eggdrop in the previous discussion
about this subject. But the result from that discussion was that eggdrop
wasn't packaged, so I asked for another discussion. I don't really have a
strong opinion in this case, so go ahead and package eggdrop if you like.

Remco


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

Re: Coming to closure on ae...

[Carlos Barros]

On Tue, 5 May 1998, Martin Schulze wrote:

  > On Tue, May 05, 1998 at 04:48:28PM +0300, Carlos Barros wrote:
  > > What about trying to connext to X server, and if an error, do it in
  > > terminal mode.
  > 
  > Which would result in opening X connections when working on the
  > console.  No, that's not funny, this already happened with urlview
  > here, not funny to wait for your browser/editor while it runs somewhere
  > on X.
  > 

Well...
if a connection is open, it means that the user has run the program
under X or did tell the program to connect to a X server or a stale
DISPLAY variable... and if that is not what the user want's is because
a user error, or does not like to use it under X even if he is under
X...  I still dont see your point...

---
if(XOpenDisplay())
xmode=true
else
xmode=false;
---
 That is what I propose.

Bye
Carlos Barros.


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

New APT version

[Jason Gunthorpe]

I have compiled a version of APT for rex/bo. It was built on my 486 that
runs some strange rex/bo mix and should work on every system from 1.2
onwards.

For completeness I built up a matching version for hamm.

http://www.debian.org/~jgg/apt_0.0.pre9-0.1_i386.deb
http://www.debian.org/~jgg/apt_0.0.pre9-1bo1_i386.deb

Scott will likely release an official .9 in a few days.

This version of apt is probably the most effective way to upgrade from
bo/rex. It has been tested in several bo upgrades and has undergone
simulated upgrades for 18 different configurations, including a few rex
systems. 

I will dump it into bo-unstable if I get a few reports of it working on
bo. It can be used to maintain a bo system and upgrade to bo-unstable, the
relevent source list entries are something like

deb http://llug.sep.bnl.gov/debian stable/binary-i386/
deb http://llug.sep.bnl.gov/debian bo-unstable/binary-i386/

(include both if using bo-unstable).

Thanks,
Jason



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

Re: Tiny libraries

[Carlos Barros]

On 5 May 1998, Ole J. Tetlie wrote:

  > I have a package that uses two very small libraries, shhmsg and shhopt.
  > I packaged the libs separately from the program that uses them, but it
  > has been suggested that I just incorporate them in the package that
  > uses them (snake4).
  > 
  > The libs are generally useful and they are distributed separately
  > from the author, so I still think it's a good idea to have them
  > as packages.
  > 
  > Any opinions?


My Opinion is that too much packages make too much complex the
instalation... Sometimes there must be those things, but remember how
much time you spent 'dselecting' packages. 
If there are other packages that need that library, all right do it.
The other thing is that the package also provide that library.

That is only a user opinion...

Bye
Carlos Barros.


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

Re: New APT version

[Joey Hess]

Jason Gunthorpe wrote:
> This version of apt is probably the most effective way to upgrade from
> bo/rex. It has been tested in several bo upgrades and has undergone
> simulated upgrades for 18 different configurations, including a few rex
> systems. 

This makes me wonder if we should think about dropping autoup as the
preferred way to upgrade to hamm, and switch to apt. On the one hand, autoup
has been tested pretty thouroghly and we shouldn't risk postponing debian
2.0 to work out bugs in apt. On the other hand, I've never seen autoup
as anything but a hack. Apt also lets people accomplish the entire bo ->
hamm upgrade from inside dselect, which is much cleaner.

-- 
see shy jo


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

Re: New APT version

[Jason Gunthorpe]

On Tue, 5 May 1998, Joey Hess wrote:

> Jason Gunthorpe wrote:
> > This version of apt is probably the most effective way to upgrade from
> > bo/rex. It has been tested in several bo upgrades and has undergone
> > simulated upgrades for 18 different configurations, including a few rex
> > systems. 
> 
> This makes me wonder if we should think about dropping autoup as the
> preferred way to upgrade to hamm, and switch to apt. On the one hand, autoup
> has been tested pretty thouroghly and we shouldn't risk postponing debian
> 2.0 to work out bugs in apt. On the other hand, I've never seen autoup
> as anything but a hack. Apt also lets people accomplish the entire bo ->
> hamm upgrade from inside dselect, which is much cleaner.

Well, not to belittle auto-up, but has it been kept up with the new
bo->hamm elements? Dpkg now depends on libstdc++ for instance. As far as
bugs in apt go, I have been running a beta for the past month on alot of
different machines and system and people. I have monitored about 5 bo
upgrades that apt didn't have any problem with (there were package bugs
though)

The very nice thing about apt is that it is highly deterministic in it's
ordering, if you do one upgrade you can be pretty sure that alot of other
similar ones will work correctly as well. I tried to do alot to make
things happen in a highly predictable and constant order.

Jason


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