booting bzImage with chos

[Bruce Perens]

Chos is able to chain to a LILO boot block on a partition. It worked fine
chaining to /dev/hdd, for example. So you can boot bzImage kernels that
way until someone fixes "chos".

Nice program. I think it assumes that /boot is on the first drive,
doesn't it?

Thanks

Bruce
-- 
Bruce Perens K6BP   [EMAIL PROTECTED]   510-215-3502
Finger [EMAIL PROTECTED] for PGP public key.
PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6  1F 89 6A 76 95 24 87 B3 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Simple policy question...

[Alex Yukhimets]

> Okay, so say some random person who has installed Debian wants XEmacs 19.15
> because he needs some feature.  This seems like a reasonable request...  He
> could get it from the Hamm distribution, except that would mean he'd need
> libc6...and he doesn't want to do that, because he's heard that it will
> affect the stability of his system.
> 
> What then can he do besides compile it himself?  If the answer is only
> compile it himself...is there a way we can add a special update directory
> for 1.3, that will have later versions of programs, and people can
> optionally tell dselect to look there?
> 
> Or am I missing a big part of the picture?
> 
> Thanks,
> Sam

That is exactly what I posted on the list a few days ago. Unfotunately
there was the only response (from Brian White -- thanks). I proposed to
have "unsupported" directory with the updates of this kind which would not
officially belong to the Debian 1.3.* . 

The most solid ground not to switch to libc6 is not instability from the
user's point of view (may be libc6 is not that bad), but from the point of
view of developer who's using different kind of commercial developmental
suits. 

Unfortunately, as far as I can see, there is no clean way to
have both developmental trees (libc5 and libc6) on the same machine.
And what even more unfortunate, Debian's goal does not seem to have
a good "transformation period system", where ALL tricky points of two
libraries coexistence are resolved, but to switch EVERYTHING to libc6
as soon as possible. The only outcome of this would the loss of quite a
few serious developers for Debian's community.

Thank you,

Alex Y. 

-- 
   _   
 _( )_
( (o___
 |  _ 7  '''
  \(")  (O O)
  / \ \ +---oOO--(_)+
 |\ __/   <--   | Alexander Yukhimets   [EMAIL PROTECTED] |
 || |   http://pages.nyu.edu/~aqy6633/  |
 (   /  +-oOO---+
  \ /  |__|__|
   )   /(_  || ||
   |  (___)ooO Ooo
\___)


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: libc6 policy in unstable

[Scott K. Ellis]

-BEGIN PGP SIGNED MESSAGE-

On Fri, 13 Jun 1997, Brian White wrote:

> > > Do we also want to remove all libc5 dependant packages at some point?  I
> > > think this would be a good idea since otherwise things are going to get
> > > pretty messed up.  We might want to do all three immediately.
> > 
> > * all packages should be libc6 when "hamm" is frozen. (later?)
> 
> Yes, they should be.  When do we remove all the non-libc6 packages, though?

I'm not entirely certain I see why we need to remove libc5 packages from
the system for Debian 2.0.  While I agree that the primary packages should
really be glibc, I don't see how a few lib5 packages are going to hurt the
distribution, a.out stuff works fine here too.  I can see a program to do
non-maintainer uploads of glibc packages for orphaned packages and so
forth.

++
||  Your friends will know you better in the |
|   Scott K. Ellis   |   first minute you meet than your acquaintances   |
|   [EMAIL PROTECTED]   | will know you in a thousand years.|
||-- Illusions   |
++

-BEGIN PGP SIGNATURE-
Version: 2.6.3
Charset: noconv

iQCVAwUBM6IngaCk2fENdzpVAQH1GwP/Yap2DrDB3N0y0kA++Hn91OtmAI9irR5m
q4i6HCFu4B3uUyBwUEAqwI+PXEyFicWZf0yRohAyXyD0xTFRhuMu0ZRiTYVqdk8Q
k944IdY9QWad5ZDohqJLn8UKIEDfYJojz5QJanp5sFyyvAOdRKL+SbQB64Z2lkib
vVvbkWv4OWk=
=eQA7
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: booting bzImage with chos

[Erik B. Andersen]

> 
> Chos is able to chain to a LILO boot block on a partition. It worked fine
> chaining to /dev/hdd, for example. So you can boot bzImage kernels that
> way until someone fixes "chos".
> 
> Nice program. I think it assumes that /boot is on the first drive,
> doesn't it?
> 
>   Thanks
> 
>   Bruce

Yup.  I tried to use a kernel on my second hard drive one, and it gave a
error when I ran chos.  As long as it is on the first hard drive, you should
be fine.  I don't know what it would take to snag some functionality from
lilo and stick it into chos, but I guess since chos is now GPLed (YEA!!!)
some of us should probably take a look.  (sound of ftping source in 
background). 

 -Erik

--
Erik B. Andersen   Web:http://www.inconnect.com/~andersen/ 
   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: thread support

[Bruce Perens]

Regarding how to make your library re-entrant, you must have no global or
static variables that are not protected by mutexes. In general it is easy
to deal with this by passing your state structure as a pointer argument to
all of your functions rather than by using a global variable. I don't know
what state S-Lang is in with this respect - that might be your first concern.

Thanks

Bruce
-- 
Bruce Perens K6BP   [EMAIL PROTECTED]   510-215-3502
Finger [EMAIL PROTECTED] for PGP public key.
PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6  1F 89 6A 76 95 24 87 B3 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Perl Police (was Re: Bug#10405: package naming)

[Carey Evans]

Christian Schwarz <[EMAIL PROTECTED]> writes:

[snip]

> I just had a look at an (old) index file of CPAN. The ".tar.gz" of the
> modules have better names for us, for example: "Date-GetDate-2.00.tar.gz".
> This could easily be converted to "lib-date-getdate-perl_2.00.deb".

Sounds good.

[snip]

> Isn't CPAN split into "sections" (categories)? What about if we pack up
> all modules in a section into a .deb. This would get us (referring to my
> old index file):
>
>   lib-perl-core
>   lib-perl-development
>   lib-perl-os
...
[snip]

I don't agree with this.  There are a *lot* of modules on CPAN.  Do we
have the entire CTAN in Debian?  (Apart from non-free stuff like
lgrind.)

We should probably have more bundling than the packages currently
provide, but it will need a bit of work to do the classification.  I
am unlikely to want AppleII::ProDOS installed because I want
Compress::Zlib.

-- 
Carey Evans  <*>  [EMAIL PROTECTED]

   TVNZ: So you can see less of New Zealand on air.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Simple policy question...

[Sam Ockman]

Okay, so say some random person who has installed Debian wants XEmacs 19.15
because he needs some feature.  This seems like a reasonable request...  He
could get it from the Hamm distribution, except that would mean he'd need
libc6...and he doesn't want to do that, because he's heard that it will
affect the stability of his system.

What then can he do besides compile it himself?  If the answer is only
compile it himself...is there a way we can add a special update directory
for 1.3, that will have later versions of programs, and people can
optionally tell dselect to look there?

Or am I missing a big part of the picture?

Thanks,
Sam

Message from joost witteveen ([EMAIL PROTECTED]) on 6-13-97:
> > Okay, I know that before 1.3 was released, for a long time period the only
> > changes that were being accepted were updates that fixed bugs.  Updates that
> > only provided new features were not allowed.
> > 
> > Now that 1.3 has "shipped", are updates allowed to replace old packages, or
> > are replacment packages still only allowed that fix specific bugs?  (In
> > particular I'm wondering whether we will see Xemacs 19-15 and XFree 3.3 in
> > 1.3.)
> 
> Situation of 1.3 is still more-or-less unchaged: only really serious
> bugfixes can go in 1.3.1, after (we have been promised) two weeks
> of testing. 
> 
> XFree 3.3 has important security fixes, and there seems to be no other
> way to close the security holes currently in debian 1.3.0 than to include
> Xfree 3.3, so there is a chance that will be included. I'm much less
> sure about XEmacs 19.15 though, although I believe it also does fix
> stuff.



-- 
VA Research Linux Workstations| The VArServer 4000 File Server
  | Four 200Mhz Intel Pentium Pro CPUs
http://www.varesearch.com | 512MB 60ns EDO ECC/100 GB Raid-5
Sam Ockman - (415)934-3666, ext. 133  | Linux - $44,339


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Santiago Vila Doncel]

-BEGIN PGP SIGNED MESSAGE-

On Thu, 12 Jun 1997, SirDibos wrote:

> I second the motion.  Smail has been nothing but a headache for me.  I was
> *so* releived to get fetchpop working, so that I could bypass the need to
> pass my mail thru port 25 on my own machine for delivery.
> 
> pine + fetchpop + procmail serves all my email needs.  (Im not up 24/7, so
> its ok ;))
> 
> speaking of which.  if I packaged up fetchpop, could it get included in
> debian?  I much prefer it to fetchmail.  if only fetchmail had a -o or a
> localfolder option!  Also, fetchpop guides you thru creation of the
> appropriate config file the first time you run it.  *and* it pipes the
> stuff transparently thru procmail for you.  Which is a bonus, since it
> always screwed up when I tried cat /var/spool/mail/$USER |procmail, and
> didnt work at *all* when I just plain ran procmail by itself

Try fetchmail's `-m' option. For example:

#!/bin/sh
fetchmail -a myserver -m "$HOME/bin/my.processing.script"

Where $HOME/bin/my.processing.script is just:

#!/bin/sh
formail -Y -I Status: -s procmail

It works for me.

BTW: There will be a completely GPLed procmail in hamm soon. Could we make
it the "standard MDA" as well? :-) [ Red-Hat *already* does this ]

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBM6EUiiqK7IlOjMLFAQFJWQQAnH+j7HX7OVl2d6kVj0QGs0gK+jJFhC8x
6xdF/VIm1C/d+GHHD0WvVDY7Cs4bKpoY0noYntTrpYKq4fgblkIaAJa7erqugJCM
WGcQHvU8yTRob7L7L0CixHw0eZRbqFG5wCwBFW9ZAvmd/pfls0v7UTFgoEE0Vvk1
h5ajatk/jPE=
=xz+7
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: thread support

[Andy Mortimer]

On Jun 13, Helmut Geyer wrote
> Our aim for Debian 2.0 is to provide all libs as reentrant. It usually
> isn't enough just to compile it with -D_REENTRANT. You have to avoid
> static and global variables and do some mutex locking.

Can anybody point me to some more information about this? If I'm going to
need to change Giggle to be reentrant, I probably ought to start fairly
soon, especially since it does make fairly heavy use of one global data
structure. Even some simple example code would be very useful: which
libraries are currently reentrant?

Cheers,

&E

-- 
Andy Mortimer, [EMAIL PROTECTED]
http://www.poboxes.com/andy.mortimer
PGP public key available on key servers
--
It goes dark, it goes darker still; please stay.
But I watch like I'm made of stone, as you walk away.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: points on future installation disks development

[Tom Lees]

On 9 Jun 1997, Sven Rudolph wrote:

> My ideas on boot-floppies' future:
> 
> - rewrite dinstall in C - reasons:
>   - runtime improvements
> - don't run fdisk -l that often
>   - todo: make a libsfdisk from sfdisk
> - more complex datastructures (avoid using sed often)
>   - more complex input masks and consistent user interface
> - network configuration: everything in one screen

Can we add at some point a BOOTP/DHCP option to the network configuration,
to do it all automagically? This would be nice.

> - selecting base directory in one screen
> - use :
>   - ncurses and libdialog (from FreeBSD), or

ncurses may have licensing problems.

>   - slang (ncurses shouldn't be needed then, slang is said to have
> a curses emulation), or

Well, SLang does have a distinct set of programming advantages. However,
we'll need a libslang-pic package in this case. Yes, it does have a curses
emulation, but it's much better to use it in native mode.

>   - turbovision (licence OK?), or
>   - something else (suggestions welcome)



>   - easier i18n (see below)
> 
> - new features
>   - installation via serial terminal

Hmmm... nice idea. How about installation over a network, i.e. system
boots up, BOOTPs (or whatever) for IP info, then SysAdmin can telnet in
from a workstation to set it up.

> - for blind users
> - for automated testing

Impressive. Are we going to do this ever?

> - use lilo in order to drive the serial line early (or modify syslinux ?)
>   (what about GRUB ?)

Modifying SysLinux is a nice option. Although I do have TASM, and so can
modify the sources, does anyone know how well NASM (which we have in the
distribution, I notice) can handle these files?

>   - an extra command-mode installation ?

i.e. SysAdmin sticks a special-custom disk into a workstation, and comes
back later, and it is running a fully installed Debian? A lot of people
have expressed interest in this.

>   - installing base via ftp and smbfs (and from tape ?)

SMBFS is just another FS, easy enough to do. Also, we should add in
NCPFS (from NetWare server) there, probably. I had a thought about FTP and
- we could use wget. This would also enable us to use HTTP. The version on
my system is 88K, but I'm sure this can be reduced if we kick out some of 
the functionality (like all the intelligent stuff).

>   - mouse support ? (gpm, or derived from gpm)

Have a look at kmouse if you want an alternative to gpm. So far, this is
looking really good, but it doesn't yet support the variety of mice that
gpm does. I have some patches to make it run on 2.1 kernels, which I will 
be sending to the author pretty soon.

However, gpm is only 33K, plus libgpm at 109K (required for both gpm or
kmouse) would take up around 140K.

> - i18n plan
>   - i18n for C files: use GNUish standard method ? (is this gettext ?)

Yes, this is gettext.

>   - i18n for shell scripts (swapsetup) (is there a good way for doing this) 
> or rewrite them in C

Use the "gettext" command-line utility. Unfortunately, there seems to be
no documentation for it, but it is pretty simple to use. The gettext
command-line utility is, however, 17K, which could make it worth
rewriting nearly everything in C.

>   - i18n for busybox (is it worth the work and disk space ?)

Some of the more major parts of busybox (like ls) may be worth i18n.
However, I wouldn't do all of it.

>   - try to keep i18n and localization separated
> - how many locale data sets will fit on floppy root.bin ?

Autodetection of a CD-ROM can happen very early in the boot process, then
at least we can put all of the locale data sets in, e.g. /l10n on the
CD-ROM.

> - bigger root.bin for loadlin booting

This may be a problem for low-memory systems, though.

> - for floppies: make extra locale file that can be copied to Rescue Disk

Or, seeing as at least one of the floppies is a DOS disk, why not create
"locale data packs". Each one would have the appropriate locale and
translation info for one locale, and this could be copied onto that DOS
disk.

>   - assign versions to original and translated text in order to keep
> them in sync (and automatically find out when they aren't)

GetText can pretty much work this out itself, actually.

> 
> - localization
>   - translate text files

Which text files do we actually have ATM?

>   - translations for the i18n'ed parts

> - minors
>   - better 'make bootable': MBR isn't that self-explaining

I think we ought to also at least have the option of not using MBR. I for
one don't like it, and use LILO instead. Others I know use OS/2 Boot
Manager.

We should also have an option to install all the appropriate LoadLin
stuff into a DOS partition, and set it up properly.

> Related topic: I expect to have much less time for Debian for the
> remainder of this year. So I definitely need help here; especially for
> the UI part.

I will be willing to help.

-- 
Tom Lees <[EMAIL PROTECTED]> <[EMAIL PROTECT

Re: Some ideas about the text db

[Tom Lees]

On Sun, 8 Jun 1997, David Frey wrote:

> Hi Tom,

Hi.

> > Basically, we first have a "/default" directory, which every package
> > imports its default settings into.
> > 
> > User configuration is put under "/config", which means that the system
> > will first look under /config, then /default when a variable is requested.
> 
> I don't see the advantage of this scheme. Please explain why it is
> favorable to have 2 configuration trees.
> 
> If you wan't to have 2 trees, a better and easier approach is to have
> (standard Unix-way) a $HOME/.config/... and a /etc/config/... tree.

OK, a lot of people got confused on this one. I meant user as separate
from maintainer of the package. i.e. local sysadmin.

The point is so that defaults can easily be changed without affecting
locally set-up stuff.

> But the question is, whether you want to use the configuration database
> for all and everything (-> each user wants his/her own copy) 
> or just for system-related entries (one global /etc/config is enough).

I think all and everything, but that's my opinion. Most people seem to
think minimalist is better, but even then, a global /etc/config would
still benefit from this scheme.

The main advantages of all and everything are:-

* SysAdmin can install multiple "themes", and user may select separately
from sysadmin.

* User defaults may be updated, but global defaults will also be updated -
using .fvwmrc, etc., where it is the global file _OR_ the local file which
gets processed will be worked around cleanly.

* The database is much more extensible (much like the menu package).

IMHO, the config database should extend the system in the same way the
menu package does - i.e.:-

* It is not compulsory (but probably priority Important)
* It is customizable by the user
* Still fully backward-compatible - no "proprietary code" in programs (and
more importantly scripts), unless they are special Debian programs, e.g.
dpkg (not scripts).

-- 
Tom Lees <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>  http://www.lpsg.demon.co.uk/
PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Philip Hands]

> > > Both qmail (which proved insecure )
> > 
> > To what are you referring ?
> 
> Probably what was reported on the djb-qmail mailing list, where you
> start sending data, but no CR-LF, down the line and qmail malloc's
> some memory for it, then malloc's some more, and some more, etc.  I
> haven't heard of anything else.

As has been discussed ad nauseam on the djb-qmail mailing list, this is 
something that should be handled by ulimits, and is NOT a security bug 
(although it is arguably a documentation bug).

Next ;-)

Cheers, Phil.



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? 
e-mail to [EMAIL PROTECTED] .

Re: Simple policy question...

[joost witteveen]

> Okay, I know that before 1.3 was released, for a long time period the only
> changes that were being accepted were updates that fixed bugs.  Updates that
> only provided new features were not allowed.
> 
> Now that 1.3 has "shipped", are updates allowed to replace old packages, or
> are replacment packages still only allowed that fix specific bugs?  (In
> particular I'm wondering whether we will see Xemacs 19-15 and XFree 3.3 in
> 1.3.)

Situation of 1.3 is still more-or-less unchaged: only really serious
bugfixes can go in 1.3.1, after (we have been promised) two weeks
of testing. 

XFree 3.3 has important security fixes, and there seems to be no other
way to close the security holes currently in debian 1.3.0 than to include
Xfree 3.3, so there is a chance that will be included. I'm much less
sure about XEmacs 19.15 though, although I believe it also does fix
stuff.

-- 
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Proposed new virtual package: zcode-interpreter (long)

[Mark Baker]

In article <[EMAIL PROTECTED]>,
Charles Briscoe-Smith <[EMAIL PROTECTED]> writes:

> I've been putting together a few packages of Z-code stuff, following my
> previous posting, and want to use a virtual package,
> `zcode-interpreter'...  I'd like to put the appropriate man-page before
> you all for approval.  (It describes the use of the virtual package,
> among other things.)

I've packaged inform (the compiler), and an interpreter xzip (which uses
Charles' scripts).

> I haven't got a master account yet, so I can't upload them, but the

Nor have I, despite having applied for one (with a signed key) nearly three
weeks ago. :(

My packages are on ftp://mnb20.pet.cam.ac.uk/pub/debian

Re: Hamm: Exim + Chos standard?

[Mark Baker]

In article <[EMAIL PROTECTED]>,
Santiago Vila Doncel <[EMAIL PROTECTED]> writes:

> BTW: There will be a completely GPLed procmail in hamm soon. Could we make
> it the "standard MDA" as well? :-) [ Red-Hat *already* does this ]

Not if we adopt exim as the standard MTA: although exim works very well with
procmail, almost all the features of procmail are built in to exim so
forcing everyone to use procmail would seem a little silly.

Re: PING of Maintainer Address

[Brian White]

> >Just to be clear...  Are they obsolete (i.e. should be removed) or
> >are they orphaned (i.e. no longer supported)?
> 
> repair was a bug-reporting script I wrote a long time ago, it never
> really achieve all the functionality intended and is probably out of
> date with respect to the modern bug system.  I believe that there is
> another package for semi-automating bug reports anyway?  It's
> obsolete.

I've removed this from project/experimental.


> itimer is a package to provide interval timers for GNU Emacs.  Current
> versions of GNU Emacs have their own timer support, therefore I
> believe this is also obsolete.

I've removed this from hamm and will remove it from Bo when the next
release gets made.  (assuming I remember ;-)

  Brian
 ( [EMAIL PROTECTED] )

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


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Koules now only for X?????

[SirDibos]

On Fri, 13 Jun 1997, Mark Baker wrote:

> We need X versions too (I'm not going anywhere near svgalib or other console
> stuff, I've been forced to reboot too many times, which isn't very funny
> when I've also got other users logged in).

Umm.  My system is a home system.  Why were you running full console
games on a production system anyways?  My enemies are right, Unix isnt a
gaming system when its being used for production at the same time.
However, for a home system, its perfect for a game system.  Just dont mix
'em up, and you'll be fine. 

Using the games in X is a kludge at best, unless the games were designed
for X from the ground up.  But the intense games just *need* the full
console.

Everyone, if you want to play console games and have stability at the same
time, just pray that Linus will one day wake up, smell the coffee, and
sanction GGI.  It is as a gaming platform that Linux stands to see its
greatest growth.

Don Dibos

www.linuxos.com



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: thread support

[Mark Eichin]

debian's Xfree86 3.2 packages were not built reentrant.  I'm working
on the 3.3 libraries now, and once they're stable and working,  I'll
be adding other support to them.  (have you ever tried programming
with X and threads?  you probably want to only use Display* per-thread
anyhow...)
_Mark_ <[EMAIL PROTECTED]>
The Herd of Kittens
Debian X Maintainer


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Compiling with libc6

[joost witteveen]

> There are some maintainers that must keep their machines on the stable
> tree (and thus libc5) for various reasons.
> 
> Is there a machine somewhere these developers can log in to for the sole
> purpose of building release packages?

If nobody else comes forward, I'd be willing to do so.

My machine is connected to the internet via a 6kbyte/s link, so up/down
loading your (large) packages will not be very fast, but at least
it works.

Mail me if you want an account on my "unstable" machine.

-- 
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Koules now only for X?????

[Mark Baker]

In article <[EMAIL PROTECTED]>,
SirDibos <[EMAIL PROTECTED]> writes:

>> We need X versions too (I'm not going anywhere near svgalib or other console
>> stuff, I've been forced to reboot too many times, which isn't very funny
>> when I've also got other users logged in).
> 
> Umm.  My system is a home system.  Why were you running full console
> games on a production system anyways?

It's not a production system. It's my home system, but I provide various
services on it as well because I'm just such a nice guy :)

(I have a network connection in my college room... there are advantages to
being at uni)

> My enemies are right, Unix isnt a gaming system when its being used
> for production at the same time. However, for a home system, its perfect
> for a game system.  Just dont mix 'em up, and you'll be fine.

But I can mix X games with everything else, no problem. I can even play
quake without affecting anything else.

> Everyone, if you want to play console games and have stability at the same
> time, just pray that Linus will one day wake up, smell the coffee, and
> sanction GGI.

I agree that GGI looks interesting.

Re: mgetty-voice

[Christoph Lameter]

mgetty-voice was removed from the distribution because of the explicit
demand of the author. Please ask him before putting mgetty-voice back into
the distribution.

In article <[EMAIL PROTECTED]> you wrote:

: Greetings!  I've been reading here recently about the mgetty package
: looking for a new maintainer.  What's the status on this?  I'd like to
: suggest to the new maintainer to rebundle the vgetty extension, as the
: program is quite usable, IMHO, in spite of its being labeled as
: unstable by the author.  In addition, it provides functionality not
: seen in any other package of which I'm aware:  the automatic receipt
: of fax and voice messages over the same line.  If no one wishes to
: maintain it, I may consider doing so, but I'm still a bit new to the
: Debian packaging system.  I notice that there is a redhat package, by
: the way.  

: Keep up the good work on Debian!

: -- 
: [EMAIL PROTECTED]   Camm Maguire
: ==
: "The earth is one country, and mankind its citizens."  Baha'u'llah


: --
: TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
: [EMAIL PROTECTED] . 
: Trouble?  e-mail to [EMAIL PROTECTED] .



-- 
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
Please always CC me when replying to posts on mailing lists.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: mgetty-voice

[Rob Browning]

Camm Maguire <[EMAIL PROTECTED]> writes:

> Greetings!  I've been reading here recently about the mgetty package
> looking for a new maintainer.  What's the status on this?  I'd like to
> suggest to the new maintainer to rebundle the vgetty extension, as the
> program is quite usable, IMHO, in spite of its being labeled as
> unstable by the author.

A new maintainer has in fact taken over mgetty, and mgetty-voice is
back.  See the recent post to debian-changes listed below.

From: "\(Paul Haggart\)" <[EMAIL PROTECTED]>
Subject: Uploaded mgetty 1.1.7-1 (source i386 all) to master
To: debian-devel-changes@lists.debian.org
Cc: recipient list not shown: ;;@cs.utexas.edu
Date: 10 Jun 1997 06:49:45 -
Resent-From: debian-devel-changes@lists.debian.org
X-From-Line: [EMAIL PROTECTED] Tue Jun 10 02:04:23 1997
Received: from mailbox.cs.utexas.edu ([EMAIL PROTECTED] [192.168.1.2])
by nevermore.csres.utexas.edu (8.8.5/8.8.5) with ESMTP id CAA26912
for ; Tue, 10 Jun 1997 02:04:22 -0500
Received: from debian.novare.net (debian.novare.net [205.229.104.5])
by mail.cs.utexas.edu (8.8.5/8.8.5) with SMTP id BAA02951
for <[EMAIL PROTECTED]>; Tue, 10 Jun 1997 01:50:08 -0500 (CDT)
Received: (qmail 3225 invoked by uid 38); 10 Jun 1997 07:48:48 -
Resent-Date: 10 Jun 1997 07:48:48 -
Resent-Cc: recipient list not shown: ;
X-Envelope-Sender: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
X-dupload: 1.14
Resent-Message-ID: <"HmSmP3.0.An.URGdp"@debian>
X-Mailing-List:  archive/latest/1445
X-Loop: debian-devel-changes@lists.debian.org
Precedence: list
Resent-Sender: [EMAIL PROTECTED]
Lines: 53
Xref: nevermore.csres.utexas.edu debian-changes:2813

-BEGIN PGP SIGNED MESSAGE-

Format: 1.5
Date: Mon,  9 Jun 1997 18:22:44 -0400
Source: mgetty
Binary: mgetty-voice mgetty-fax mgetty-docs mgetty
Architecture: source i386 all
Version: 1.1.7-1
Distribution: unstable
Urgency: low
Maintainer: Paul Haggart <[EMAIL PROTECTED]>
Description: 
 mgetty - Smart Modem getty replacement
 mgetty-docs - Documentation Package for mgetty
 mgetty-fax - Faxing tools for mgetty.
 mgetty-voice - Voicemail handler for mgetty
Changes: 
 mgetty (1.1.7-1) unstable; urgency=low
 .
   * new maintainer
   * new upstream release
   * mgetty-voice added
   * policy.h, voice/include/paths.h: all log files generated by {m,v}getty
 are now located in /var/log/mgetty/*
   * policy.h: logging to syslog enabled
   * policy.h: mgetty uses /usr/sbin/sendmail instead of /usr/lib
Files: 
 c239ad80e4bf5208613b5767d21853a6 711 comm extra mgetty_1.1.7-1.dsc
 04caf85dcbc40aebef7b2a7aa1643f48 756054 comm extra mgetty_1.1.7.orig.tar.gz
 498ad76faebc21b575595b85409c5d63 22858 comm extra mgetty_1.1.7-1.diff.gz
 dc81e3c74c4cec76eb90c0c58bb97286 138200 comm extra mgetty-fax_1.1.7-1_i386.deb
 ace78cb40ecce9d1545ca710026d6e3a 191824 comm extra 
mgetty-voice_1.1.7-1_i386.deb
 c792e63dd490792e8090d42dc55bf48b 601298 comm extra mgetty-docs_1.1.7-1_all.deb
 af5c2a3819843f8b576773d21fe3f1f6 104396 comm extra mgetty_1.1.7-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: noconv
Comment: http://www.cybertap.com/phaggart/pgpkey.txt

iQCVAwUBM5z1t/x6jjXWExPpAQHJ3AQAzCFQxj/UTucMd9cy96jkWjGNzpNajFoU
6635Yo/hKkwHpXpHE1I82E+xjKxJh33x+m9zv3opiNSWxA0KE4b3FuNmgzwvfSow
PNi+boWuu45wj1UwnjPuTY1meO8dXkQwTB0JMHT7SFjOCWTzYKnfJE5YtweaCkwM
zWYQvCDSLrE=
=8t1x
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

-- 
Rob


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Simple policy question...

[Sam Ockman]

Okay, I know that before 1.3 was released, for a long time period the only
changes that were being accepted were updates that fixed bugs.  Updates that
only provided new features were not allowed.

Now that 1.3 has "shipped", are updates allowed to replace old packages, or
are replacment packages still only allowed that fix specific bugs?  (In
particular I'm wondering whether we will see Xemacs 19-15 and XFree 3.3 in
1.3.)

Thanks,
Sam

-- 
VA Research Linux Workstations| The VArServer 4000 File Server
  | Four 200Mhz Intel Pentium Pro CPUs
http://www.varesearch.com | 512MB 60ns EDO ECC/100 GB Raid-5
Sam Ockman - (415)934-3666, ext. 133  | Linux - $44,339


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Koules now only for X?????

[Mark Baker]

In article <[EMAIL PROTECTED]>,
SirDibos <[EMAIL PROTECTED]> writes:

> Why is Koules only available for X???  I *loved* the variety of console
> games that came with Debian.  Now one by one they are being X'ised from
> the distribution =(

We need X versions too (I'm not going anywhere near svgalib or other console
stuff, I've been forced to reboot too many times, which isn't very funny
when I've also got other users logged in).

I agree that having svgalib versions as well would be nice. Personally I'd
prefer to have separate packages rather than binaries that do both, although
the svgalibdummy package someone mentioned in another thread should help
here.

Re: Bug#10516: gs-aladdin: Depends on svgalib1 (>= 1.210-1) which does not allow svgalib-dummy to fulfill the dependency

[Roman Hodek]

I've missed the start of this discussion, but I'm the maintainer of
svgalib-dummy, and the issue of dependencies came up already several
times...

> Are there other people that would like the dependancy change
> 
> - Depends: svgalib1 (>= 1:1.2.10-2)
> + Depends: svgalib1 (>= 1:1.2.10-2)|svgadummy

This would indeed be a fix for the dependency stuff, but only for the
package that adds this |svgadummy. To fix the svgalib/svgalib-dummy
problems with way, every depending packages would have to be changed
similarily.

svgalib-dummy indeed has a "Provides: svgalib", but unfortunately this
doesn't have any effect... Since svgalib is a shared lib, all packages
depending on it depend on >= some version. And such versioned
dependencies can't be fulfilled by a Provides: :-((

This is not only a problem for svgalib-dummy (which can't really be
used as a proper substitute for svgalib due to this), but it has also
other implications: We'll never be able to replace or rename a shared
library package! Currently, packages that are to replace an older one
(renaming is a special case of this) have fields Replaces: and
Provides:. But this works only as long as no other package has a
*versioned* dependency on the package to be replaced.

I see this as a kind of shortcoming of the dependency checking: It
should be allowed to have versioned Provides: fields also (e.g.:
"Provides: svgalib1 (1:1.2.10-2)". With that, you also give the
version of the other package whose functionality is provided, and some
dependency (e.g. "Depends: svgalib1 (>= 1:1.2.10-1)") can be
fulfilled.

I don't know how difficult this would be to implement in dpkg, but it
would be a win not only for svgalib-dummy, but also for the future, in
case we'll need to replace a shlib package sometimes...

Roman


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: booting bzImage with chos

[Bruce Perens]

From: [EMAIL PROTECTED] (Erik B. Andersen)
> Yup.  I tried to use a kernel on my second hard drive one, and it gave a
> error when I ran chos.

However, it's able to chain to the second drive just fine . I think its
installer needs to be taught to figure out which BIOS drive /boot lives on,
and to make the first-stage loader get the second-stage from there.

Thanks

Bruce
-- 
Bruce Perens K6BP   [EMAIL PROTECTED]   510-215-3502
Finger [EMAIL PROTECTED] for PGP public key.
PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6  1F 89 6A 76 95 24 87 B3 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

thread support

[Guenter Geiger]

I am rather new to this list, so excuse me if this question has
already been dealt with. 


Will there be kernel level thread support for Debian ?

The Linuxthreads package from Xavier Leroy is a very good Thread
Library supporting Posix threads. In order to develop threaded
applications there should be some changes in different packages:

 - the libpthread0 packages comes without header files !
  
 - libraries should be compiled reentrant
 
This sounds like a big job, will it be worth it ?
According to the linuxthreads FAQ no distribution currently supports
reentrant libraries ( Xlib is very critical about that ) 

Guenter   


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Anyone using transparent proxying?

[Michael Meskes]

The title almost says it all. I just upgraded to pre-patch-2.0.31-2, but it
seems transparent proxying still doesn't work. My first rule says:

acc/r tcp  anywhere anywhere any -> www => tproxy

but still tproxy does not get the connection. I tried to trace it but it
appears the connection is not switched to port 81 at all.

Maybe someone had more luck...

Michael
-- 
Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH
[EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
[EMAIL PROTECTED]  | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!  | Fax: (+49) 2405/4670-10


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: libc6 policy in unstable

[Brian White]

> > Do we also want to remove all libc5 dependant packages at some point?  I
> > think this would be a good idea since otherwise things are going to get
> > pretty messed up.  We might want to do all three immediately.
> 
> * all packages should be libc6 when "hamm" is frozen. (later?)

Yes, they should be.  When do we remove all the non-libc6 packages, though?

  Brian
 ( [EMAIL PROTECTED] )

---
Debian GNU/Linux!  Search it at  http://insite.verisim.com/search/debian/simple



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Mark Baker]

In article <[EMAIL PROTECTED]>,
Christoph Lameter <[EMAIL PROTECTED]> writes:
> It might be good if we would replace smail in hamm with exim.

I agree entirely. Though we should keep smail for people who use smail
elsewhere and don't want to switch.

> - Exim is scalable from running from inetd to delivering hundredths of
>   thousands of messages a day

I thought you had problems on one of your list servers and switched to
zmailer instead?

> Also we might think about replacing lilo with chos as the standard boot
> loader from harddisk. lilo always is a difficulty for newbies, chos
> offers:
> 
> - Menudriven Boot Loader (Cryptic Prompt only on demand)

Can it still load straight into linux without any menus or prompts or
anything? If not, it shouldn't be the default IMO. (A nice menu that pops up
if you hold down shift or something would be nice though)

> - Simple configuration in passwd style file /etc/chos.conf

So it uses libext2 or whatever it's called to read directly from the
filesystem at boot time, or is it compiled into the boot sector in the same
way as lilo is?

Re: manpages missing (system calls)

[Nicolás Lichtmaier]

On Thu, 12 Jun 1997, Michael Meskes wrote:

> ls /usr/man/man2 says:
> 
> create_module.2.gz
> delete_module.2.gz
> get_kernel_syms.2.gz
> init_module.2.gz
> intro.2.gz
> modules.2.gz
> query_module.2.gz
> 
> where are the others?
> 
> I also miss the libc function manpages like fgets.

 Get the new package manpages-dev for Linux-development manpages.

-- 
Nicolás Lichtmaier.-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble?  e-mail to [EMAIL PROTECTED] .

locale errors

[Erv Walter]

-BEGIN PGP SIGNED MESSAGE-

The locale errors are getting extremely annoying.  What is the most
correct way to solve the problems.  unsetting LANG solves the problem,
but I can't find where it is getting set in the first place.  That's
not the most elegant solution anyway.  

My locale version is 2.0.4-1

The error (from perl) is:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = (unset),
LANG = "us"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Note: There are similar error from other programs (emacs, etc).  This
becomes particularly annoying when installing new packages (which
calls perl many times in a row).

Please tell me how to solve this problem

Thanks,
Erv
- --
  PGP Public Key: finger [EMAIL PROTECTED]
  PGP Fingerprint: A5 AB 25 7D 7A FD 4D FE  BE 21 47 60 0C DC 67 9E
 
 ==-- _ / /  \ 
 ---==---(_)__  __   __/ / /\ \   - [EMAIL PROTECTED]
 --==---/ / _ \/ // /\ \/ /   / /_/\ \ \- [EMAIL PROTECTED]   
 -=/_/_//_/\_,_/ /_/\_\  /__\ \ \ - [EMAIL PROTECTED]
 \_\/  

-BEGIN PGP SIGNATURE-
Version: 2.6.3
Charset: noconv

iQCVAwUBM6IM97kbWT/F2aV1AQFJJgP/blGNCDeXHqRrjtv6d1rWBGYcKvD1EDwR
R/bKbGfEp+R5cfQN18r9AldUyEN1fTom0pweiX8PLbb3En+SKFPl3xhd6vWB/axB
Nx1WjGHCg8Wp8ax/wnL1R72oLDbOlstTQ9Sy5CEQzOYebmlk3hhDODRHZhXmWjWV
hTo/kciAbBY=
=Onp9
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: inetd question

[Peter Tobias]

On Jun 13, Michael Meskes wrote:
> Thanks Peter.
> 
> I guess it's the ident service. So I try nowait.120 and see what
> happens.

Of course it is the ident service (that's what the error message of
inetd said). But the ident service is not a service that is used
alone. You have an application/service which is called as often
as the ident service. You should have a look at this application.
Your problem could also be an entry in hosts.allow or hosts.deny.
If you use a username ([EMAIL PROTECTED]) there the tcp_wrapper will do an
ident/auth lookup for that service (or for all services if the ALL
keyword has been used).

Using "nowait.120" is of course a solution but it is probably better
to find the application that is causing the problem.


Thanks,

Peter

-- 
Peter Tobias <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
PGP ID EFAA400D, fingerprint = 06 89 EB 2E 01 7C B4 02  04 62 89 6C 2F DD F1 3C 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Fixing X problems for 1.3.0...

[John Goerzen]

[EMAIL PROTECTED] (Kai Henningsen) writes:

> 3. 3.3 to stable
> 
>I really don't see why this should not happen in due time.

Agreed.

-- 
John Goerzen  | Running Debian GNU/Linux (www.debian.org)
Custom Programming| 
[EMAIL PROTECTED] | 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: PING of Maintainer Address

[Brian White]

> I've had these messages before, and followed the instructions for
> stating that I no longer maintain the packages in question.  But they
> still keep appearing.

These things tend to get overriden by the automated scripts.  


> Can somebody *please* sort this out, and tell me that they have done
> so?
> 
> (Both packages are, AFAIK, utterly obsolete and should not exist at
> all any more.)

Just to be clear...  Are they obsolete (i.e. should be removed) or are
they orphaned (i.e. no longer supported)?


> >According to the ftp://ftp.debian.org/debian/indices/Maintainers.gz file,
> >you maintain the following packages:
> >
> >itimer
> >repair

  Brian
 ( [EMAIL PROTECTED] )

---
No man dies except he who has not lived.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Christoph Lameter]

Sourcecode is available for chos and it has been GPLed by the author after
several people talked with him (among them me on behalf of Debian).

On Thu, 12 Jun 1997, SirDibos wrote:

>
>
>On Thu, 12 Jun 1997, SirDibos wrote:
>> > Also we might think about replacing lilo with chos as the standard boot
>> > loader from harddisk. lilo always is a difficulty for newbies, chos
>> > offers:
>> 
>> Sounds good to me.  I am an advocate of many solutions I hate to see
>> any software get dropped from the distribution.  Hell, I still think we
>> should have continued to include *both* anagram generating programs.
>>   Yup, I'd like to give chos a try.
>
>Whoa, hold on.  Apparently, source code isnt available for chos.  So, I
>take my words back.  By all means, lets keep it in the distribution, but
>by no means let it be the "primary" boot loader.
>
>Don Dibos
>
>
>
>

--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Kai Henningsen]

[EMAIL PROTECTED] (Alexander Koch)  wrote on 13.06.97 in <[EMAIL PROTECTED]>:

> Quoting Philip Hands ([EMAIL PROTECTED]):
> > Qmail is most definitely capable of UUCP (I use it here), and AFAIK bang
> > paths can be done with rmail.
>
> With what addition? Last time I really tried it, it was only working with
> some additions like rsmtp (as I mentioned, btw) and no bangs.
>
> Exim is (this news is also old) not capable of bang paths or uucp, just
> using rsmtp works fine, though it's not sure if it all works.

I seem to remember reading somewhere in the exim docs that some simple  
bang addresses are understood by exim. Not sure about that.

Anyway, bang addresses should really not be used, even with UUCP.

> If Exim comes with an rmail wrapper script, all is fine.
>
> > I'm not sure how you would deal with having to bangify addresses, but does
> > anyone still need to do this ?   If so then I suppose they should be using
> > a mail system that handles it.
>
> standard uucp needs it, rsmtp not really any more, a mailertable or
> pathalias- table (smail) is enough, somewhat.

Not quite. UUCP needs bang-specified envelopes; it doesn't care about  
what's in the RFC 822 headers.

Note also that you seldom need more than one UUCP hop these days.


MfG Kai


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

RE: inetd question

[Michael Meskes]

Thanks Peter.

I guess it's the ident service. So I try nowait.120 and see what
happens.

Michael

--
Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH
[EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
[EMAIL PROTECTED]  | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!  | Fax: (+49) 2405/4670-10

>-Original Message-
>From:  Peter Tobias [SMTP:[EMAIL PROTECTED]
>Sent:  Thursday, June 12, 1997 11:52 PM
>To:Michael Meskes
>Cc:Die Adresse des Empfängers ist unbekannt.
>Subject:   Re: inetd question
>
>On Jun 12, Michael Meskes wrote:
>> I get quite a lot of these messages:
>> 
>> inetd[153]: ident/tcp server failing (looping), service terminated 
>> 
>> How can I tell which service is the one that's asked for too often?
>
>Have you tried the -l (and maybe the -d) option of the identd?
>BTW: Never ever use the tcp_wrapper for the identd (you'll get a nice
>tcpd->identd->tcpd->... loop).
>
>You could also check (and count) the "connect" messages from the
>tcp_wrapper in /var/log/daemon.log.
>
>Another possibility would be to start inetd with the -d option.
>
>> I tried tcplogd but all tcp requests logged are to auth and www-proxy both
>> of which are not in /etc/inetd.conf. I don't know how auth is handled, is
>>it
>> an internal service? www-proxy was added by myself and points to a squid
>> daemon so inetd shouldn't get a hand on it, or does it?
>
>If squid receives a request from a local user and squid wants to check
>the identity it will call the local ident/auth service (which will be
>called by inetd).
>
>
>Thanks,
>
>Peter
>
>-- 
>Peter Tobias <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
><[EMAIL PROTECTED]>
>PGP ID EFAA400D, fingerprint = 06 89 EB 2E 01 7C B4 02  04 62 89 6C 2F DD F1
>3C 
>
>
>--
>TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
>[EMAIL PROTECTED] . 
>Trouble?  e-mail to [EMAIL PROTECTED] .
>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Carey Evans]

Philip Hands <[EMAIL PROTECTED]> writes:

> > Let me remind you of one thing...
> > 
> > Both qmail (which proved insecure )
> 
> To what are you referring ?

Probably what was reported on the djb-qmail mailing list, where you
start sending data, but no CR-LF, down the line and qmail malloc's
some memory for it, then malloc's some more, and some more, etc.  I
haven't heard of anything else.

[snip]

-- 
Carey Evans  <*>  [EMAIL PROTECTED]

   TVNZ: So you can see less of New Zealand on air.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Christoph Lameter]

On Thu, 12 Jun 1997, SirDibos wrote:

>speaking of which.  if I packaged up fetchpop, could it get included in
>debian?  I much prefer it to fetchmail.  if only fetchmail had a -o or a
>localfolder option!  Also, fetchpop guides you thru creation of the
>appropriate config file the first time you run it.  *and* it pipes the
>stuff transparently thru procmail for you.  Which is a bonus, since it
>always screwed up when I tried cat /var/spool/mail/$USER |procmail, and
>didnt work at *all* when I just plain ran procmail by itself

Package it up. No problem.

>Sounds good to me.  I am an advocate of many solutions I hate to see
>any software get dropped from the distribution.  Hell, I still think we
>should have continued to include *both* anagram generating programs.
>  Yup, I'd like to give chos a try.

You misunderstand whats going on here. Exim and Chos are part of the
Debian distribution. The issue is which packages are installed by default.
>

--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: thread support

[Helmut Geyer]

Guenter Geiger <[EMAIL PROTECTED]> writes:

> I am rather new to this list, so excuse me if this question has
> already been dealt with. 
> 
> 
> Will there be kernel level thread support for Debian ?
> 
> The Linuxthreads package from Xavier Leroy is a very good Thread
> Library supporting Posix threads. In order to develop threaded
> applications there should be some changes in different packages:
> 
>  - the libpthread0 packages comes without header files !
>   
>  - libraries should be compiled reentrant
>  
> This sounds like a big job, will it be worth it ?
> According to the linuxthreads FAQ no distribution currently supports
> reentrant libraries ( Xlib is very critical about that ) 
> 
The linuxthreads package is part of the libc6 packages, as it is an
add-on to glibc 2. As the new libraray handles threads much better
than libc5, you should base all work intended to do threading on
libc6. 

Our aim for Debian 2.0 is to provide all libs as reentrant. It usually
isn't enough just to compile it with -D_REENTRANT. You have to avoid
static and global variables and do some mutex locking.

XFree86 3.3. supports reentrant libraries when based on libc6.

Helmut (Debian libc maintainer)

-- 
Helmut Geyer[EMAIL PROTECTED]
public PGP key available :   finger [EMAIL PROTECTED]


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: libc6 policy in unstable

[Milan Zamazal]

> "BW" == Brian White <[EMAIL PROTECTED]> writes:

:: * July 15th: All libraries *must* be libc6.
:: * July 31th: All packages must be libc6.

What about:

* June 30th: Bug reports on all non-libc6 libraries.
* July 15th: All libraries libc6 compatible.
* July 31th: Bug reports on all libc5 packages, uploads of such
 packages no longer allowed.
* August 31th: libc5 packages removed.

BW: Do we also want to remove all libc5 dependant packages at some
BW: point?  I think this would be a good idea since otherwise
BW: things are going to get pretty messed up.

I agree.  We should avoid repeating situation, when we had a.out
packages in ELF system.

Milan Zamazal


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Proposed new virtual package: zcode-interpreter (long)

[Bruce Perens]

Charles Briscoe-Smith <[EMAIL PROTECTED]> writes:
> I haven't got a master account yet,

From: [EMAIL PROTECTED] (Mark Baker)
> Nor have I, despite having applied for one (with a signed key) nearly
> three weeks ago. :(

Oops. [EMAIL PROTECTED] mail is down this evening as is all
mail @debian.org . Please send directly to [EMAIL PROTECTED] and
[EMAIL PROTECTED] . They are the two security officers. They may
take some time because they have to verify that you are who you say
you are, but if it's been a long time it's fair to nudge them.

Thanks

Bruce
-- 
Bruce Perens K6BP   [EMAIL PROTECTED]   510-215-3502
Finger [EMAIL PROTECTED] for PGP public key.
PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6  1F 89 6A 76 95 24 87 B3 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: thread support

[Guenter Geiger]

Mark Eichin writes:
 > be adding other support to them.  (have you ever tried programming
 > with X and threads?  you probably want to only use Display* per-thread
 > anyhow...)

Yes, I've tried - that's how I came to this topic. 
The problem is with the global errno variable. As Xlib does a lot of
error checking using errno. After X encounters an error it checks what
kind of error ocurred with errno and deals with it.
It is possible that the "non X" thread resets the global errno
variable between these two steps -- 
Xlib signals unknown error ( with number 0 )  and exits.

Guenter
 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Kai Henningsen]

[EMAIL PROTECTED] (Mark Baker)  wrote on 13.06.97 in <[EMAIL PROTECTED]>:

> In article <[EMAIL PROTECTED]>,
>   Alexander Koch <[EMAIL PROTECTED]> writes:
>
> > Both qmail (which proved insecure ) and Exim are not
> > capable of UUCP or even bang paths! So a lot of those guys in countries
> > where phone costs are terrible (like in Germany) still use it and they
> > WILL have a problem then.
>
> Exim is not capable of bang paths, true, but not many people still use them.
> It _is_ capable of uucp so long as you use domain addressing. Admittedly it
> is not obvious how to set it up to do so.

Well, that just means we either include that in the eximconfig, or  
somewhere in /usr/doc/exim, doesn't it?

The way I understand the docs, exim should be quite able to do the very  
common case of a site with a permanent net connection feeding lots of UUCP  
leaf sites. True, if you need map handling, then you'll probably be better  
off with a different MTA (or maybe you can even hack that one into exim -  
I don't know if anybody has tried this).

Me, I won't weep a single tear for bang paths and map handling.


MfG Kai


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[SirDibos]

I second the motion.  Smail has been nothing but a headache for me.  I was
*so* releived to get fetchpop working, so that I could bypass the need to
pass my mail thru port 25 on my own machine for delivery.

pine + fetchpop + procmail serves all my email needs.  (Im not up 24/7, so
its ok ;))

speaking of which.  if I packaged up fetchpop, could it get included in
debian?  I much prefer it to fetchmail.  if only fetchmail had a -o or a
localfolder option!  Also, fetchpop guides you thru creation of the
appropriate config file the first time you run it.  *and* it pipes the
stuff transparently thru procmail for you.  Which is a bonus, since it
always screwed up when I tried cat /var/spool/mail/$USER |procmail, and
didnt work at *all* when I just plain ran procmail by itself


On Thu, 12 Jun 1997, Christoph Lameter wrote:

> It might be good if we would replace smail in hamm with exim. Exim should 
> be the standard mailer for hamm:

> Also we might think about replacing lilo with chos as the standard boot
> loader from harddisk. lilo always is a difficulty for newbies, chos
> offers:

Sounds good to me.  I am an advocate of many solutions I hate to see
any software get dropped from the distribution.  Hell, I still think we
should have continued to include *both* anagram generating programs.
  Yup, I'd like to give chos a try.

You developers out there does it make your job harder when there are
multiple packages that do the same thing in the distribution?  Lets hear
from you.

Don Dibos

www.linuxos.com



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Official CDs

[Bruce Perens]

The images moved to ftp://ftp.debian.org/OfficialCD . By leaving them in
/debian as I did yesterday, I messed up a number of mirror sites and made
life hard for system admins all over the globe.

No, one big file aside the chunks would use up to 1.3GB extra for two CDs!
Please use "mget" in FTP and get the 10MB chunks. Even monopolizing Pixar's
T1, I found that transfers of one 400MB file generally abort in the middle.

Thanks

Bruce
-- 
Bruce Perens K6BP   [EMAIL PROTECTED]   510-215-3502
Finger [EMAIL PROTECTED] for PGP public key.
PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6  1F 89 6A 76 95 24 87 B3 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: thread support

[Douglas L Stewart]

On Fri, 13 Jun 1997, Guenter Geiger wrote:

> I am rather new to this list, so excuse me if this question has
> already been dealt with. 
> 
> 
> Will there be kernel level thread support for Debian ?
> 
> The Linuxthreads package from Xavier Leroy is a very good Thread
> Library supporting Posix threads. In order to develop threaded
> applications there should be some changes in different packages:
> 
>  - the libpthread0 packages comes without header files !
>   
>  - libraries should be compiled reentrant
>  
> This sounds like a big job, will it be worth it ?
> According to the linuxthreads FAQ no distribution currently supports
> reentrant libraries ( Xlib is very critical about that ) 

The linux 2.0 and beyond kernels have kernel thread support.  Glibc is
reentrant and there is a posix threads addon (which is practically
mandatory) for glibc.  Since glibc (aka libc 6.x) will be the system libc
for Debian 2.0, there will definitely be kernel level thread support for
Debian.

It's just a matter of making sure all of the other libraries get thread
safe, which will get partially done I'm sure.  The ones that aren't, you
can work around it by just using them in a single thread usually.

Of course, thread support in the libraries is nice, but it will only
become really cool when applications are modified to make use of threads.
A multi-threaded gzip would be nice. ;-)

-douglas


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: mgetty-voice

[Rob Browning]

Sorry about the runaway mail headers in my previous article re-post.
Emacs was hiding them from me.

-- 
Rob


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

mgetty-voice

[Camm Maguire]

Greetings!  I've been reading here recently about the mgetty package
looking for a new maintainer.  What's the status on this?  I'd like to
suggest to the new maintainer to rebundle the vgetty extension, as the
program is quite usable, IMHO, in spite of its being labeled as
unstable by the author.  In addition, it provides functionality not
seen in any other package of which I'm aware:  the automatic receipt
of fax and voice messages over the same line.  If no one wishes to
maintain it, I may consider doing so, but I'm still a bit new to the
Debian packaging system.  I notice that there is a redhat package, by
the way.  

Keep up the good work on Debian!

-- 
[EMAIL PROTECTED] Camm Maguire
==
"The earth is one country, and mankind its citizens."  Baha'u'llah


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Official CDs

[Jaldhar H. Vyas]

I saw the images were briefly available on the ftp site today but now
they're gone again.  What happened?  When will they be back?

Also, may we have one big file alongside all the 10MB chunks?  For people
with access to fast connections, this will be a  little easier.  Another
useful thing might be md5sums of all the chunks and the resulting image so
we can be sure nothing's corrupt before burning a cd.

-- Jaldhar 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: inetd question

[Peter Tobias]

On Jun 12, Michael Meskes wrote:
> I get quite a lot of these messages:
> 
> inetd[153]: ident/tcp server failing (looping), service terminated 
> 
> How can I tell which service is the one that's asked for too often?

Have you tried the -l (and maybe the -d) option of the identd?
BTW: Never ever use the tcp_wrapper for the identd (you'll get a nice
tcpd->identd->tcpd->... loop).

You could also check (and count) the "connect" messages from the
tcp_wrapper in /var/log/daemon.log.

Another possibility would be to start inetd with the -d option.

> I tried tcplogd but all tcp requests logged are to auth and www-proxy both
> of which are not in /etc/inetd.conf. I don't know how auth is handled, is it
> an internal service? www-proxy was added by myself and points to a squid
> daemon so inetd shouldn't get a hand on it, or does it?

If squid receives a request from a local user and squid wants to check
the identity it will call the local ident/auth service (which will be
called by inetd).


Thanks,

Peter

-- 
Peter Tobias <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
PGP ID EFAA400D, fingerprint = 06 89 EB 2E 01 7C B4 02  04 62 89 6C 2F DD F1 3C 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Philip Hands]

> Let me remind you of one thing...
> 
> Both qmail (which proved insecure )

To what are you referring ?

> and Exim are not capable
> of UUCP or even bang paths!

Qmail is most definitely capable of UUCP (I use it here), and AFAIK bang paths 
can be done with rmail.

> So a lot of those guys in countries where phone
> costs are terrible (like in Germany) still use it and they WILL have a problem
> then.
>
> I consider this a big problem for many Europeans.

qmail with maildir2smtp provides an alternative (often better) solution to 
this problem.

I'm not sure how you would deal with having to bangify addresses, but does 
anyone still need to do this ?   If so then I suppose they should be using a 
mail system that handles it.

I just switched most of my systems to qmail, and have been really impressed 
with the elegant simplicity of the design.  Unfortunately, the documentation 
is lacking, so that new users tend not to find the easiest way of doing 
things. Also, if you are used to sendmail, then qmail seems to be missing some 
functionality, until you realise how easy it is to achieve the same results 
the qmail way.

I'm not suggesting that qmail should be our default mail system, because 
setting it up requires a depth of understanding that we should not expect of 
out users.  But if Exim and qmail both support Maildir, perhaps we could look 
at making that our default maildrop, because it is much more reliable than the 
other methods.

Cheers, Phil.



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: How do we encourage bug reports?

[Milan Zamazal]

One problem with reporting bugs I feel personally is what to do to
avoid repeating reports.  I use the following algorithm, when I
discover a bug:
1. I go through the list of pending bugs posted to bug list
   periodically, and check whether it could be reported.
2. I'm searching through my mail archive for bug server address and
   guide.
3. I request bug messages I've found in 1. from bug server to check if
   they reported my bug or not.
4. I wait several hours for answer (maybe because of slow connection
   somewhere -- because of various reasons I have from Middle Europe
   much more better connection to U.S. than to most European
   countries).
5. I forget that reported bug may be also corrected and closed in
   unstable.
6. If I think my bug is not reported yet, I send bug report.

This algorithm is very annoying and I think some steps could be
avoided (but I've no idea how).  I prefer e-mail interface over WWW
because of my slow connection.

Milan Zamazal


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[SirDibos]

On Thu, 12 Jun 1997, SirDibos wrote:
> > Also we might think about replacing lilo with chos as the standard boot
> > loader from harddisk. lilo always is a difficulty for newbies, chos
> > offers:
> 
> Sounds good to me.  I am an advocate of many solutions I hate to see
> any software get dropped from the distribution.  Hell, I still think we
> should have continued to include *both* anagram generating programs.
>   Yup, I'd like to give chos a try.

Whoa, hold on.  Apparently, source code isnt available for chos.  So, I
take my words back.  By all means, lets keep it in the distribution, but
by no means let it be the "primary" boot loader.

Don Dibos



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

standard command to play au files ?

[Andreas Jellinghaus]

is ther a good way to play au files ?
IIRC nas has a command, and the other poossibility is to cat FILE >
/dev/audio. 

nas has a /usr/bin/auplay or so. is there an other package, that has the
same command and uses it with /dev/audio directly ? i don't want to
care if nas is installed or the user is directly using audio ...

thanks for you hints.

regards, andreas


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Anyone using transparent proxying?

[Jason Gunthorpe]

On Fri, 13 Jun 1997, Michael Meskes wrote:

> The title almost says it all. I just upgraded to pre-patch-2.0.31-2, but it
> seems transparent proxying still doesn't work. My first rule says:
> 
> acc/r tcp  anywhere anywhere any -> www => tproxy
> 
> but still tproxy does not get the connection. I tried to trace it but it
> appears the connection is not switched to port 81 at all.

I had transparent proxying working with a Custom build of 2.0.27 if that
is any help.

I used:

ipfwadm -I -f
ipfwadm -I -p accept
ipfwadm -I -a accept -S 172.16.1.0/24 -D 172.16.1.60/0
ipfwadm -I -a accept -r 9000 -S 172.16.1.0/24 -D 0.0.0.0/0 -P tcp

Which routed all connections to port 9000 which was running my custom RA
tunnel program. I'm not sure both of the last lines are required though.

Since I don't use it anymore haven't tried it on any newer kernels.

Jason


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Simple policy question...

[Buddha Buck]

> Okay, so say some random person who has installed Debian wants XEmacs 19.15
> because he needs some feature.  This seems like a reasonable request...  He
> could get it from the Hamm distribution, except that would mean he'd need
> libc6...and he doesn't want to do that, because he's heard that it will
> affect the stability of his system.

Then that person needs to be corrected.  I don't know if libc6 will 
affect the stability of his system, but I do know that xemacs19 (the 
xemacs package in hamm currently) doesn't rely on libc6, but rather is 
still libc5.

I also know that installing libc6 will only affect programs that use 
libc6, not ones that use libc5.  I currently have libc4, libc5, and 
libc6 installed on my system.  I run programs that are compiled for all 
three libraries.  So far, no problems that can be traced to libc6.

What I would do, if I were he, is go into dselect, put everything on 
hold, point dselect at hamm, flag xemacs19 for install, then look at 
the dependancy conflicts dselect complains about.  If he wants 
xemacs19, then he can mark for install or upgrade any packages from 
hamm that xemacs19 requires.  I don't know if there are any, since 
xemacs19 is compiled against libc5, xlib6 (3.2), ncurses3.0, xpm4.7, 
zlib1, libjpeg6a, libdb1, libgdbm1, libpng1, all of which are, as far 
as I know, available in 1.2.

> 
> What then can he do besides compile it himself?  If the answer is only
> compile it himself...is there a way we can add a special update directory
> for 1.3, that will have later versions of programs, and people can
> optionally tell dselect to look there?

I don't know what you mean here...
> 
> Or am I missing a big part of the picture?
> 
> Thanks,
> Sam
> 
> Message from joost witteveen ([EMAIL PROTECTED]) on 6-13-97:
> > > Okay, I know that before 1.3 was released, for a long time period the only
> > > changes that were being accepted were updates that fixed bugs.  Updates 
> > > that
> > > only provided new features were not allowed.
> > > 
> > > Now that 1.3 has "shipped", are updates allowed to replace old packages, 
> > > or
> > > are replacment packages still only allowed that fix specific bugs?  (In
> > > particular I'm wondering whether we will see Xemacs 19-15 and XFree 3.3 in
> > > 1.3.)
> > 
> > Situation of 1.3 is still more-or-less unchaged: only really serious
> > bugfixes can go in 1.3.1, after (we have been promised) two weeks
> > of testing. 
> > 
> > XFree 3.3 has important security fixes, and there seems to be no other
> > way to close the security holes currently in debian 1.3.0 than to include
> > Xfree 3.3, so there is a chance that will be included. I'm much less
> > sure about XEmacs 19.15 though, although I believe it also does fix
> > stuff.
> 
> 
> 
> -- 
> VA Research Linux Workstations| The VArServer 4000 File Server
>   |   Four 200Mhz Intel Pentium Pro 
> CPUs
> http://www.varesearch.com | 512MB 60ns EDO ECC/100 GB Raid-5
> Sam Ockman - (415)934-3666, ext. 133  | Linux - $44,339
> 
> 
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> [EMAIL PROTECTED] . 
> Trouble?  e-mail to [EMAIL PROTECTED] .
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Perl Police (was Re: Bug#10405: package naming)

[Christian Schwarz]

[I CC: this to the mailing list since I think this is of public intrest.
Hope you don't mind] 

On Thu, 12 Jun 1997, Brian S. Julin wrote:

> On Thu, 12 Jun 1997, Christian Schwarz wrote:
> > What is your problem exactly? We could easily change our standard to
> > "cpan-xxx.deb", for example.
> 
> The problem is that perl module names take the form of 
> ([A-Za-z0-9_]+::)+.  That is, they can have both "_" and
> "::" in their names in addition to lower and uppercase
> alphanumerics.  If there was one module named Foo__Bar::
> and another module named Foo::Bar:: then both would be
> translated to perl-foo-bar- or perl-foo--bar-- depending on how you
> did it.  Now there don't appear to be any modules that 
> clash in this way, but that could change.  In addition since
> dpkg in not case sensitive, the module Foo:: would have the same
> package name as the module FOO::.  Fortunately, there are 
> conventions for module naming in perl that make such a clash
> unlikely to happen.  What I possibly could do because the 
> underscore character appears to be rarely used is 
> s/_/--/ and s/::/-/.  That way Foo__Bar:: becomes perl-foo--bar-
> and more common module names like Foo::Bar become perl-foo-bar-.
> Since there cannot be a "" in a module name I guess this 
> would work.  But having a trailing "::" would instantly clue perl
> users in that it was a perl package.  I'll work without
> the ":" though since it seems to be such a big deal.
> 
> We could override some module names but then there would have to be 
> a registry of overrided module names kept somewhere, or else
> when the MakeMaker utility was trying to figure out what debian-CPAN 
> packages depended on which others it would make mistakes, since it
> would be working from the module names.

I just had a look at an (old) index file of CPAN. The ".tar.gz" of the
modules have better names for us, for example: "Date-GetDate-2.00.tar.gz".
This could easily be converted to "lib-date-getdate-perl_2.00.deb".

> Another topic brought up by the maintainer of dpkg-ftp was
> that it would probably be best not to occlude the primary
> debian distribution with several hundred perl modules, but run
> a side-distribution instead.  He says he has added this feature
> to dpkg-ftp.

I agree that having each module in a single .deb is probably to much.
However, I think these modules are of general intrest. Such, we could
probably pack them up into a few larger .debs. (We have chosen the same
way for our new TeX packages before: we had lots of small packages before
but I think everyone is happy with the few larger .debs we have now.)

Isn't CPAN split into "sections" (categories)? What about if we pack up
all modules in a section into a .deb. This would get us (referring to my
old index file):
 
lib-perl-core
lib-perl-development
lib-perl-os
lib-perl-networking
lib-perl-types
lib-perl-database
lib-perl-ui
lib-perl-languages
lib-perl-files
lib-perl-strings
lib-perl-options
lib-perl-auth
lib-perl-www
...


Thanks,

Chris

--  Christian Schwarz
   [EMAIL PROTECTED], [EMAIL PROTECTED]
  [EMAIL PROTECTED], [EMAIL PROTECTED]
   
PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
  
 CS Software goes online! Visit our new home page at
 http://www.schwarz-online.com


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Helmut Geyer]

Christoph Lameter:
> 
> Also we might think about replacing lilo with chos as the standard boot
> loader from harddisk. lilo always is a difficulty for newbies, chos
> offers:
> 
> - Menudriven Boot Loader (Cryptic Prompt only on demand)
> - Highly Customizable Color Menus.
> - Simple configuration in passwd style file /etc/chos.conf
> 
But chos can't yet load bzImages. The usptream maintainer promised me to look
into it, so maybe it soon can. Until then, however, lilo should be the 
standard. Once it can, we max talk about it again.

Helmut

-- 
Helmut Geyer[EMAIL PROTECTED]
public PGP key available :   finger [EMAIL PROTECTED]


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

PING of Maintainer Address

[Richard Kettlewell]

I've had these messages before, and followed the instructions for
stating that I no longer maintain the packages in question.  But they
still keep appearing.

Can somebody *please* sort this out, and tell me that they have done
so?

(Both packages are, AFAIK, utterly obsolete and should not exist at
all any more.)

ttfn/rjk

Brian C. White writes:
>PING <[EMAIL PROTECTED]>
>
>This address is listed as a contact for one or more Debian packages.  I am
>just verifying that this address is functional.  If you have no idea what I
>am talking about, please let me know as the address is obviously incorrect.
>Otherwise, please just delete this mail.
>
>According to the ftp://ftp.debian.org/debian/indices/Maintainers.gz file,
>you maintain the following packages:
>
>itimer
>repair
>
>If you no longer maintain one or more of these packages, please send email
>to Philippe Troin <[EMAIL PROTECTED]>.  He keeps track of all orphaned 
>packages.
>
>  Brian
> ( [EMAIL PROTECTED] )


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Bruce Perens]

From: Christoph Lameter <[EMAIL PROTECTED]>
> Sourcecode is available for chos and it has been GPLed by the author after
> several people talked with him (among them me on behalf of Debian).

Hooray!

Is the GPL-ed version and its source in a Debian package yet?

Thanks

Bruce
-- 
Bruce Perens K6BP   [EMAIL PROTECTED]   510-215-3502
Finger [EMAIL PROTECTED] for PGP public key.
PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6  1F 89 6A 76 95 24 87 B3 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Unresolved symbols with ibmtr_cs PCMCIA module

[Stephen Zander]

Further in my attempts to setup up a Thinkpad 760CD...

When attempting to load the ibmtr_cs.o mdules under the standard
2.0.30 kernel, I get the folliowing unresolved symbols.

netif_rx_R9117ffb8
dev_alloc_skb_R24e337ab
dev_kfree_skb_R7a61ae71
dev_tint_Rcc72f6b2
unregister_netdev_Re5a9d51a
register_netdev_R70caa700
tr_setup_R787bcf6f
tr_type_trans_Rf1130552

Should I load another module to resolve these or is there
something else I'm missing?


Stephen
---
"Normality is a statistical illusion." -- me


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Joey Hess]

SirDibos:
> Whoa, hold on.  Apparently, source code isnt available for chos.  So, I
> take my words back.  By all means, lets keep it in the distribution, but
> by no means let it be the "primary" boot loader.

Actually, they're still both in there, and I still maintain wordplay, though
I don't even have it installed on my system anymore (dumped it for the
superior "an").

-- 
see shy jo


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: thread support

[Guenter Geiger]

Philippe Troin writes:
 > They're probably in libpthread0-dev !

 Sorry, I'm feeling rather guilty ..

 > 
 > >  - libraries should be compiled reentrant
 > 
 > Most of them are. I'm not sure about the X libraries.
 > 

 Does anybody know about the X libraries ? The linuxthreads-0.6
provide a patch by for compiling XFree3.2 reentrant. 

Guenter


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Kai Henningsen]

[EMAIL PROTECTED] (Christoph Lameter)  wrote on 12.06.97 in <[EMAIL PROTECTED]>:

> It might be good if we would replace smail in hamm with exim. Exim should
> be the standard mailer for hamm:
>
> - Exim is based on the same concepts as smail.
> - It is developed with newer concepts in mind
> - Exim is scalable from running from inetd to delivering hundredths of
>   thousands of messages a day
> - Exim has just one configuration file. eximconfig is the old smailconfig
>   script reworked. It is extremly easy to set up.
> - Active development is going on.
> - Support for a variety of mailbox formats including Maildir.
> - Has X interface
> - Well written documentation

Also, support for not doing relaying for third parties, which is highly  
appropriate in today's UCE-filled world. The last time I looked, sendmail  
could do it, too, but smail had severe problems in that area. Plus support  
for blocking specific mail several ways, also very useful.

> Also we might think about replacing lilo with chos as the standard boot
> loader from harddisk. lilo always is a difficulty for newbies, chos
> offers:
>
> - Menudriven Boot Loader (Cryptic Prompt only on demand)
> - Highly Customizable Color Menus.
> - Simple configuration in passwd style file /etc/chos.conf

If it's true that chos

+ can't hack bzimages
+ is not really free

then no way!

MfG Kai


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Nathan E Norman]

On Fri, 13 Jun 1997, Mark Baker wrote:

:
:In article <[EMAIL PROTECTED]>,
:   Alexander Koch <[EMAIL PROTECTED]> writes:
:
:> Both qmail (which proved insecure ) and Exim are not capable
:> of UUCP or even bang paths! So a lot of those guys in countries where phone
:> costs are terrible (like in Germany) still use it and they WILL have a 
problem
:> then.
:
:Exim is not capable of bang paths, true, but not many people still use them.
:It _is_ capable of uucp so long as you use domain addressing. Admittedly it
:is not obvious how to set it up to do so.
:
:In any case, I don't see anyone suggesting we get rid of smail or sendmail
:from the distribution entirely.

If you got rid of sendmail I think I'd be upset :)  I can see the
attractiveness of running a simpler mailer on a smaller site.  We have a
big site, and I understand sendmail (to some extent, anyway - enough to
be dangerous).  I personally like it.  I personally like a lot of things
that many people don't like, so I don't care if my pet packages are the
default ... I do wish I had a longer day so I could try some of these
things out.

Not that anyone necessarily has the time, but would it be worthwhile to
create some documents listing categories of packages, comparing and
contrasting the competing packages?  I know the package descriptions
provide this info to some extent, but I guess I'm thinking of a web page
that has a 'Mail Packages' link, or whatever ... following the link
shows you a list of what's available and how they compare ... if I had
the time I'd write something like this.  Right now I don't :/

--
  Nathan Norman:Hostmaster CFNI:[EMAIL PROTECTED]
finger [EMAIL PROTECTED] for PGP public key and other stuff
Key fingerprint = CE 03 10 AF 32 81 18 58  9D 32 C2 AB 93 6D C4 72
--



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: thread support

[Philippe Troin]

On Fri, 13 Jun 1997 11:11:18 GMT Guenter Geiger ([EMAIL PROTECTED]
) wrote:

> Will there be kernel level thread support for Debian ?

Yes !

> The Linuxthreads package from Xavier Leroy is a very good Thread
> Library supporting Posix threads. In order to develop threaded
> applications there should be some changes in different packages:
> 
>  - the libpthread0 packages comes without header files !

They're probably in libpthread0-dev !

>  - libraries should be compiled reentrant

Most of them are. I'm not sure about the X libraries.

Phil.



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: PING of Maintainer Address

[Richard Kettlewell]

>Just to be clear...  Are they obsolete (i.e. should be removed) or
>are they orphaned (i.e. no longer supported)?

repair was a bug-reporting script I wrote a long time ago, it never
really achieve all the functionality intended and is probably out of
date with respect to the modern bug system.  I believe that there is
another package for semi-automating bug reports anyway?  It's
obsolete.

itimer is a package to provide interval timers for GNU Emacs.  Current
versions of GNU Emacs have their own timer support, therefore I
believe this is also obsolete.

(FWIW I still use Debian at home and at work, and hope one day to be
able to contribute some more of my time to it.  But I don't have the
time at present.)

-- 
Richard Kettlewell, ElectricMail Ltd 
phone: +44 1223 501333 fax: +44 1223 501444
[EMAIL PROTECTED]  http://www.elmail.co.uk/~richard/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Mark Baker]

In article <[EMAIL PROTECTED]>,
Alexander Koch <[EMAIL PROTECTED]> writes:

> Both qmail (which proved insecure ) and Exim are not capable
> of UUCP or even bang paths! So a lot of those guys in countries where phone
> costs are terrible (like in Germany) still use it and they WILL have a problem
> then.

Exim is not capable of bang paths, true, but not many people still use them.
It _is_ capable of uucp so long as you use domain addressing. Admittedly it
is not obvious how to set it up to do so.

In any case, I don't see anyone suggesting we get rid of smail or sendmail
from the distribution entirely.

Hamm: Exim + Chos standard?

[Christoph Lameter]

It might be good if we would replace smail in hamm with exim. Exim should 
be the standard mailer for hamm:

- Exim is based on the same concepts as smail.
- It is developed with newer concepts in mind
- Exim is scalable from running from inetd to delivering hundredths of
  thousands of messages a day
- Exim has just one configuration file. eximconfig is the old smailconfig
  script reworked. It is extremly easy to set up.
- Active development is going on.
- Support for a variety of mailbox formats including Maildir.
- Has X interface
- Well written documentation

I really have not seen an easier to configure mailer and also I am
surprised about the scalability. I never understood exactly how to
configure smail, but exim no problem. I am running exim on most of my
Debian Servers.

Also we might think about replacing lilo with chos as the standard boot
loader from harddisk. lilo always is a difficulty for newbies, chos
offers:

- Menudriven Boot Loader (Cryptic Prompt only on demand)
- Highly Customizable Color Menus.
- Simple configuration in passwd style file /etc/chos.conf

--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: inetd question

[Michael Meskes]

You're right of course. I should have been more precise. There are two
other services involved:
squid as a standalone server and http-gw on the firewall and both call
ident for each www request.

That makes up for quite some traffic given that one www site is build by
a lot of www requests.

Thanks anyway, Peter.

Later
Michael
--
Dr. Michael Meskes, Projekt-Manager| topystem Systemhaus GmbH
[EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
[EMAIL PROTECTED]  | 52146 Wuerselen
Go SF49ers! Use Debian GNU/Linux!  | Tel: (+49) 2405/4670-44

>--
>Von:   Peter Tobias[SMTP:[EMAIL PROTECTED]
>Gesendet:  Freitag, 13. Juni 1997 12:53
>An:Michael Meskes
>Cc:Die Adresse des Empfängers ist unbekannt.
>Betreff:   Re: inetd question
>
>On Jun 13, Michael Meskes wrote:
>> Thanks Peter.
>> 
>> I guess it's the ident service. So I try nowait.120 and see what
>> happens.
>
>Of course it is the ident service (that's what the error message of
>inetd said). But the ident service is not a service that is used
>alone. You have an application/service which is called as often
>as the ident service. You should have a look at this application.
>Your problem could also be an entry in hosts.allow or hosts.deny.
>If you use a username ([EMAIL PROTECTED]) there the tcp_wrapper will do an
>ident/auth lookup for that service (or for all services if the ALL
>keyword has been used).
>
>Using "nowait.120" is of course a solution but it is probably better
>to find the application that is causing the problem.
>
>
>Thanks,
>
>Peter
>
>-- 
>Peter Tobias <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
><[EMAIL PROTECTED]>
>PGP ID EFAA400D, fingerprint = 06 89 EB 2E 01 7C B4 02  04 62 89 6C 2F DD F1
>3C 
>
>
>--
>TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
>[EMAIL PROTECTED] . 
>Trouble?  e-mail to [EMAIL PROTECTED] .
>
>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble?  e-mail to [EMAIL PROTECTED] .

Koules now only for X?????

[SirDibos]

How and why when and Where?

Why is Koules only available for X???  I *loved* the variety of console
games that came with Debian.  Now one by one they are being X'ised from
the distribution =(

Koules, Maelstrom, Abuse I can understand Abuse (altho that should be
available for the console again soon), but come on guys,  why Koules and
Maelstrom?

I only have a lowly 14" monitor, and video card with 1 meg of ram, and its
a 486.  To enjoy these games, I need the console version.  X just doesnt
cut it on my old machine.  Please?  Why the change?  I am appealing to
you, dont make me use X for my gaming.  It doesnt work, and just makes me
frustrated.

Don Dibos

www.linuxos.com



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Erik B. Andersen]

> 
> Also we might think about replacing lilo with chos as the standard boot
> loader from harddisk. lilo always is a difficulty for newbies, chos
> offers:
> 
> - Menudriven Boot Loader (Cryptic Prompt only on demand)
> - Highly Customizable Color Menus.
> - Simple configuration in passwd style file /etc/chos.conf
> 

I fully agree, except for one thing...  Last I looked, chos did not
include any source code, and was in non-free.  Has this changed?
If it has, I completely agree, it should be the standard.  It is
VERY easy to use, and works VERY well.  I like it.

 -Erik

--
Erik B. Andersen   Web:http://www.inconnect.com/~andersen/ 
   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Mark Baker]

In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Kai Henningsen) writes:

> I seem to remember reading somewhere in the exim docs that some simple  
> bang addresses are understood by exim. Not sure about that.

You can cope with host!user by using a rewrite rule, not anything much more
than that though.

Re: Simple policy question...

[Mark Baker]

In article <[EMAIL PROTECTED]>,
Alex Yukhimets <[EMAIL PROTECTED]> writes:

> The most solid ground not to switch to libc6 is not instability from the
> user's point of view (may be libc6 is not that bad), but from the point of
> view of developer who's using different kind of commercial developmental
> suits. 

No, that's a good reason not to install libc6 development stuff. It's not a
good reason to not install the libc6 runtime and programs that use it, which
is what we were talking about.

> Unfortunately, as far as I can see, there is no clean way to
> have both developmental trees (libc5 and libc6) on the same machine.

There cannot be a really good way, but I think they altdev packages are
about as good as possible.

Re: thread support

[Andy Mortimer]

On Jun 13, Bruce Perens wrote
> Regarding how to make your library re-entrant, you must have no global or
> static variables that are not protected by mutexes. In general it is easy
> to deal with this by passing your state structure as a pointer argument to
> all of your functions rather than by using a global variable.

Although how well this interacts with dynamically-loaded shared libraries
is anyone's guess; I suspect I may have to go the global-variable route
myself, which is why I was asking for examples/docs.

> I don't know what state S-Lang is in with this respect - that might be
> your first concern.

Without having looked at the source, I do know that it uses a fair few
global variables for various things, unfortunately.

Cheers,

&E

-- 
Andy Mortimer, [EMAIL PROTECTED]
http://www.poboxes.com/andy.mortimer
PGP public key available on key servers
--
Your face! I'll never see you this way again.
I captured it so perfectly, as if I knew you'd disappear away.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Installing XF86 3.3-1 crashed XEmacs 19.15-3

[Federico Di Gregorio]

Hi everybody,

last night i dftp-ized part of the 1.3 distribution to
upgrade my mixed 1.2/hamm linux box. All went well and this morning
i finished the upgrade in a few minutes by installing the packages
by hand (Debian IS the *better* linux distribution! :)

Then, to get better support for my gfx board I downloaded
the XF86 3.3-1 packages (base, svga-server, lib, fonts, extensions,
etc...) and installed them. Again all went well but... now XEmacs 19.15
crashes and does a core dump. I tryed to mail the maintainer 
(James LewisMoss <[EMAIL PROTECTED]>) but, apparently, the address is
wrong. (I'll cc a copy of this  mail to his address anyway...)

So... does have anybody an idea of what happened? Is James 
on this list? I dont want to submit an official bug if I simply missed
some point.

thanx,
Federico


PS - some more info about the crash follows.

--

/var/local/home/fog>xemacs

Fatal error (11).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.

... (some info about submitting bugs here)

Lisp backtrace follows:

  delete-device(#)
  frame-initialize()
  # bind (debugger debug-on-error command-line-args-left)
  command-line()
  # (unwind-protect ...)
  normal-top-level()
  # (condition-case ... . error)
  # (catch top-level ...)
Segmentation fault (core dumped)

--

/var/local/home/fog>dpkg -s xemacs19
Package: xemacs19
Installed-Size: 4422
Maintainer: James LewisMoss <[EMAIL PROTECTED]>
Architecture: i386
Source: xemacs
Version: 19.15-3
Replaces: xemacs
Provides: info-browser, mail-reader, news-reader, www-browser
Depends: compface (>= 89.11.11-4), elf-x11r6lib, libc5 (>= 5.4.0-0), libdb1, 
libgdbm1, libpng1 (>= 0.88), ncurses3.0, xlib6 (>= 3.2-0), xpm4.7 (>= 3.4g-0), 
zlib1 (>= 1.00), xemacs19-support, libjpeg6a
Suggests: xemacs19-supportel, xfntbig
Conflicts: xemacs, xemacs-widget
Size: 1616392


**
* Federico Di Gregorio   |  /  the number you dialled is *
* [EMAIL PROTECTED]   | / -1   imaginary... please, rotate*
*|/  the phone PI/2 and try again!   *
**



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

RFC: libc6 policy supplement 2nd try

[Helmut Geyer]

Here is a reworked proposal:

-=-=-=-=-=-=-=-=-=-=-= SNIP -=-=-=-=-=-=-=-=-=-=-=-=-=-

 Debian library policy supplement draft for libc5->libc6 migration

   This document is meant to tell what a Debian package providing a
   library should do to support both libc6 (glibc2) and libc5.
   Note that these requirements are for Debian 2.0 (codename hamm).

 Contents 
 1.  Run time packages
 2.  Development packages
 3.  Requirements on libraries for Debian 2.0
 4.  Requirements on compiler packages 

 1. Run time packages

A package providing a shared library has to support both C library
packages, libc5 and libc6 based libraries. This must be done using
two Debian packages, each depending on the correct C library
package.
The package naming convention currently suggests to name these
packages as follows [1]. Some packages (mostly from base) may use
locations in /lib. 

   based on  | package name | library location
   
 libc6   |   libfoo | /usr/lib/libfoo.so.
 libc5   |   libfoo-g   | /usr/lib/libc5-compat/libfoo.so. [2]

If a library runtime package contains files that are needed by
both versions of the library, a new package should be made for
just these files that both other packages depend on.

This package naming convention does _not_ apply if a package uses
different sonames for libc5 and libc6 based packages

There are two exceptions from this rule. The shared linker
ld-linux.so.1 and the C library files libc.so.5 and libm.so.5
should still be located in /lib, not in /lib/libc5-compat.

Packages based on X have to use /usr/X11R6 as prefix, not /usr. 
Note that the X libraries are designed to work with both C libraries.

  2.  Development packages

The Debian policy requires that all files needed for compiling/linking
other packages with the library are in a separate package, the
development package. Up to now this package simply was called
libfoo-dev. As packages based on libc5 and libc6 usually cannot
use the same development files there has to be a clear statement
how to separate these. So for now the following packages are
required:  

  based on  | package name| hierarchy locations
  ---
  libc6 | libfoo-dev  | /usr/{lib,include}
  libc5 | libfoo-g-altdev | /usr/i486-linuxlibc1/{lib,include}

   Note that the choice to base Debian 2.0 on libc6 fixed the fact
   that the main locations will be used for libc6 packages. The
   alternate locations are used for libc5 based packages.
   This decision does not necessarily mean that by default the
   compiler uses the libc6 packages, please read section 4 for more
   information. Using a four-way approach for library locations
   (standard and alternate locations for libc6 and libc5 based
   packages) will make Debian systems inconsistent with each other,
   something we should avoid at (nearly) all costs. 

  3.  Requirements on libraries for Debian 2.0

   Libraries (regardless of which library they're compiled against) need
   to have runtime dependencies on one of libc, libdl or libm to enable
   the shared linker to determin which library to use for a binary.

   In general we want libraries compiled for libc6 to be thread-safe.
   This means that the following changes must be made to the library
   packages:

- compile the library using -D_RENTRANT or -D_THREAD_SAFE
- there may be no permanent data residing in the library memory that
  can be different for different threads.
  this means in the first place no static or global variables that
  are not in some way protected from access by a different threads.
- all write access to files from a library must be both protected
  using some file locking mechanism in addition to using mutexes.
- library functions must be protected from being used at the same
  time by two threads sharing the same memory space. This is done
  using mutexes. 

   As these usually are all nontrivial changes to a library if it isn't
   thread-safe already (in which case just using -D_RENTRANT should 
   be used in addition to whatever the library uses to support threads),
   I suggest that noone starts doing this without getting in contact with
   the upstream maintainer(s).

   There will be a list available that lists all libraries part of
   Debian and their current status regarding compliance with these
   standard requirements. This list will be posted regularly to
   debian-devel by Helmut Geyer <[EMAIL PROTECTED]>.

  4.  Requirements on compiler packages

   The compiler and binutils packages have to provide working
   development environments for both C libraries. Basically (that is
   from the compiler standpoint) there is no real difference between
   the two environments, only some paths and auto

Re: Hamm: Exim + Chos standard?

[Heiko Schlittermann]

On Jun 12, Christoph Lameter wrote
: It might be good if we would replace smail in hamm with exim. Exim should 
: be the standard mailer for hamm:

... hmmm, ``never change a running system'', and smail _is_ running.
And I you're able to read some docs, it's possible to setup this
think quite easy.  Missing features will be found in every of the MTA's,
probably.

And the simple standard cases are handled by the smailconfig script.

(It's somewhat as with debmake -- sometime I tried it and found
me lost in _too_ many automatism ... never getting an idea what's going
on.)

Please, don't assume, this is a flame, you're probaly the Debian
maintainer producing the most output  but IMHO complex things should
be kept complex, from the early beginning!   (See Win-NT, everybody
cabably of moving a mouse now thinks that network/system-adminstration
is as easy as using Word or Excel, simply by clicking somewhere )



Heiko
--
email : [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
pgp   : A1 7D F6 7B 69 73 48 35  E1 DE 21 A7 A8 9A 77 92 
finger: [EMAIL PROTECTED][EMAIL PROTECTED]


pgpEv64aODKH0.pgp
Description: PGP signature

Mea Culpa -- didn't announce intentions.

[Ben Gertzfield]

Eep. I just got a little  excited there, and released my two Debian
packages already, without reading all of the policies first.

igor has told me that I'm supposed to announce my intentions
before packageing. Whoops.


Erm, well, does anybody mind if I package sirc and ching?

sirc is a Perl-based IRC client, and ching is a fortune-like
forgram that generates I Ching hexagrams.

Again, forgive me -- I don't want to face the wrath of Manoj :)

Sort of an ex-posto-facto announcement of intentions.

Yeah, that's the ticket.

-- 
Brought to you by the letters Y and F and the number 16.
"A Squeegee by any other name wouldn't sound as funny." -- fortune
Ben Gertzfield  Finger me for my public
PGP key. I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

locale errors

[Yann Dirson]

Erv Walter writes:
 > The locale errors are getting extremely annoying.  What is the most
 > correct way to solve the problems.  unsetting LANG solves the problem,
 > but I can't find where it is getting set in the first place.  That's
 > not the most elegant solution anyway.  
[...]
 > Note: There are similar error from other programs (emacs, etc).  This
 > becomes particularly annoying when installing new packages (which
 > calls perl many times in a row).

...and this is EXTREMELEY unpleasant when, using debian-changelog-mode
in emacs, "finalize-version" inserts these error messages from perl in
the buffer !!!
-- 
Yann Dirson

e-mail: [EMAIL PROTECTED]
http://monge.univ-mlv.fr/~dirson


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Rob Browning]

Nathan E Norman <[EMAIL PROTECTED]> writes:

> Not that anyone necessarily has the time, but would it be worthwhile to
> create some documents listing categories of packages, comparing and
> contrasting the competing packages?

Right.  I'm about to help someone set up a relatively busy mailserver,
and though I'm only familiar with sendmail, it'd be nice to know if
one of the others would be a better choice.

-- 
Rob


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: thread support

[Rob Browning]

Guenter Geiger <[EMAIL PROTECTED]> writes:

>  - libraries should be compiled reentrant

This has been on the list of things to do (for bo and now for hamm)
for a while.  It'll propagate eventually.

Note that just compiling with -D_REENTRANT doesn't mean that the
library is suddenly multi-thread safe, but it does mean that it won't
use any thread unsafe macros from stdio or other includes that respect
-D_REENTRANT, so that it should then be possible to use it safely by
using mutexes to make sure that no more than one thread is ever inside
the library.  I've had to do that here with X (3.2).

-- 
Rob


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: thread support

[Rob Browning]

Douglas L Stewart <[EMAIL PROTECTED]> writes:

> It's just a matter of making sure all of the other libraries get thread
> safe, which will get partially done I'm sure.  The ones that aren't, you
> can work around it by just using them in a single thread usually.

or often by just using a mutex to make sure that no more than one
thread is in the library at any one time.  Of course this can be
defeated by unsafe libraries that call each other internally.

-- 
Rob


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: thread support

[Rob Browning]

Mark Eichin <[EMAIL PROTECTED]> writes:

> debian's Xfree86 3.2 packages were not built reentrant.  I'm working
> on the 3.3 libraries now, and once they're stable and working,  I'll
> be adding other support to them.  (have you ever tried programming
> with X and threads?  you probably want to only use Display* per-thread
> anyhow...)

Well, it's really nice if you have several data displays (graphs,
progress meters, counters, etc) monitoring different sources of data
generated by separate threads to be able to allow the threads to
update their own displays when they're ready.  You can do this if you
use a big lock to keep multiple threads out of X at the same time.

Everyone should be a little wary of the synchronization primitives in
LinuxThreads.  I believe I determined that semaphores (and condition
variables) do not guarantee FIFO scheduling fairness (I guess I
expected them to, even though the POSIX standard doesn't require it).

I had to write C++ wrapper objects that use their own queues or I
tended to get starvation in situations where I really didn't expect
it.  On the up side, not having these guarantees allows them to make
the code more efficient.

-- 
Rob


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Mark Baker]

In article <[EMAIL PROTECTED]>,
Heiko Schlittermann <[EMAIL PROTECTED]> writes:

>: It might be good if we would replace smail in hamm with exim. Exim should 
>: be the standard mailer for hamm:
> 
> ... hmmm, ``never change a running system'', and smail _is_ running.

No-one's suggesting changing running systems. We're suggesting that future
installs of debian should use exim instead of smail. Currently both are in
debian and both work well, but smail is the default one, it's only the
default that will be changed.

Re: thread support

[Rob Browning]

Guenter Geiger <[EMAIL PROTECTED]> writes:

> Yes, I've tried - that's how I came to this topic. 
> The problem is with the global errno variable. As Xlib does a lot of
> error checking using errno. After X encounters an error it checks what
> kind of error ocurred with errno and deals with it.
> It is possible that the "non X" thread resets the global errno
> variable between these two steps -- 
> Xlib signals unknown error ( with number 0 )  and exits.

That's not the only thing.  For example, if you don't define
-D_REENTRANT when compiling the X libs, they pick up macros for stdio
that are not thread safe, and can cause segfaults when X tries to
print things.

-- 
Rob


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: thread support

[Rob Browning]

Andy Mortimer <[EMAIL PROTECTED]> writes:

> Although how well this interacts with dynamically-loaded shared libraries
> is anyone's guess;

What do you mean?

> I suspect I may have to go the global-variable route myself, which
> is why I was asking for examples/docs.

Bruce is right that in general the best thing is to avoid globals and
statics, and pass everything as an argument, but assuming you can't,
let's assume that your global data structure is called the_state.
Here's an example of a function safely modifying the data:

GState the_state;
pthread_pmutex_t the_state_guard;

void
some_function() {
  pthread_mutex_lock(&the_state_guard);
  
  /* do whatever with the_state.  No other thread that respects the mutex
 can touch it while you're in here.  They'll block until you
 unlock the mutex. */

  pthread_mutex_unlock(&the_state_guard);
}

int main(int argc, char **argv) {
  pthread_mutex_init(&the_state_guard, NULL);

  /* other stuff */

}

See "man pthread_mutex_init" and other pthread_* man pages in
libc6-doc.

-- 
Rob


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: RFC: libc6 policy supplement 2nd try

[Rob Browning]

Helmut Geyer <[EMAIL PROTECTED]> writes:

> - compile the library using -D_RENTRANT or -D_THREAD_SAFE

There was some talk about adding -D_REENTRANT to the list of flags
that are automatically included by gcc/g++.  I don't recall what the
resulting decision was, if there was one.

> - there may be no permanent data residing in the library memory that
>   can be different for different threads.
>   this means in the first place no static or global variables that
>   are not in some way protected from access by a different threads.
> - all write access to files from a library must be both protected
>   using some file locking mechanism in addition to using mutexes.
> - library functions must be protected from being used at the same
>   time by two threads sharing the same memory space. This is done
>   using mutexes. 

In the general case, I'm not sure it's realistic to expect *all*
libraries to be rewritten thread safe (though it would be nice).  At
the least, though, we should make certain that -D_REENTRANT is always
used, and that it's at least safe to call a given library function if
you make sure only one thread is in the library at a time.  That
should be easier to accomplish.

>There will be a list available that lists all libraries part of
>Debian and their current status regarding compliance with these
>standard requirements. This list will be posted regularly to
>debian-devel by Helmut Geyer <[EMAIL PROTECTED]>.

This is a good idea.

-- 
Rob


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: thread support

[Andy Mortimer]

On Jun 14, Rob Browning wrote
> 
> Andy Mortimer <[EMAIL PROTECTED]> writes:
> 
> > Although how well this interacts with dynamically-loaded shared libraries
> > is anyone's guess;
> 
> What do you mean?

I'm using libdl, to allow me to dynamically add and remove modules as I
go. But I don't really know enough about the implementation of threads
(or libdl!) to know how they're going to interact. I shall write a few
test progs probably today or tomorrow, but the basic question I want to
answer is: if I open a library in one thread, is it then always
accessible to all threads (presumably), and what happens to any global
variables in that library?

> > I suspect I may have to go the global-variable route myself, which
> > is why I was asking for examples/docs.

[snip example]
> See "man pthread_mutex_init" and other pthread_* man pages in
> libc6-doc.

Thankyou muchly; that should get me started!

&E

-- 
Andy Mortimer, [EMAIL PROTECTED]
http://www.poboxes.com/andy.mortimer
PGP public key available on key servers
--
To sleep: perchance to dream: ay, there's the rub;
For in that death of sleep what dreams may come
When we have shuffled off this mortal coil


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: thread support

[Rob Browning]

Andy Mortimer <[EMAIL PROTECTED]> writes:

> the basic question I want to answer is: if I open a library in one
> thread, is it then always accessible to all threads (presumably),
> and what happens to any global variables in that library?

Threading shoudln't have any affect on this.  All the threads share
the same address space, so anything one can "see" and manipulate, the
others can too.  In other words, minus sychronization and reentrancy
issues, if it works for one of the threads, it'll work for all of
them.

My impression is that these days every non-threaded Linux program can
be thought of structurally as a multi-threaded program with just a
single thread.

-- 
Rob


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Debian 1.3.1?

[Stoopid!!]

I wanted to get your Official 2 CD set, so I was checking out the prices
at www.cheapbytes.com, but I didn't see it.  They told me that they're
waiting for 1.3.1 because there's something wrong with 1.3.  Is that true?
If so, when will 1.3.1 be out, and how much does 1.3 cost?



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: libc6 policy in unstable

[joost witteveen]

> > Yes, they should be.  When do we remove all the non-libc6 packages, though?
> 
> I'm not entirely certain I see why we need to remove libc5 packages from
> the system for Debian 2.0.  While I agree that the primary packages should
> really be glibc, I don't see how a few lib5 packages are going to hurt the
> distribution

Well, they won't hurt much, but they would:

 - make memory usage less favourable (if you're running a mix of
   libc5/libc6 binaries, you'll have both in memory).
 - make Debian look less attractive (We wouldn't appear in the
   list of distributions that are fully libc6).

As more-or-less automatic compilation of packages is now possible,
we could always (at some point) just write a script and automatically
convert all remaining libc5 packages to libc6 -- the ones that don't
compile obviously have bugs in them, that can then be reported, thus
forcing the maintainer to do something about it. But I don't think there
will be many of those packages.


-- 
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: RFC: libc6 policy supplement 2nd try

[joost witteveen]

> packages as follows [1]. Some packages (mostly from base) may use
> locations in /lib. 
> 
>based on  | package name | library location
>
>  libc6   |   libfoo | /usr/lib/libfoo.so.
>  libc5   |   libfoo-g   | /usr/lib/libc5-compat/libfoo.so. [2]


Isn't that the other way around: the libc6 version with g, and the
libc5 version without? (This convention would ensure that somebody
with an old (from bo, libc5) libfoo and a new libfoo-g would have
the same library twice, and other libc6 packages couldn't just
depends: libfoo, cause there are now two libfoo's (a libc5 and a libc6 one).

>   based on  | package name| hierarchy locations
>   ---
>   libc6 | libfoo-dev  | /usr/{lib,include}
>   libc5 | libfoo-g-altdev | /usr/i486-linuxlibc1/{lib,include}

Here again, unless I'm really confused, the "g" is mixed up.



-- 
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: How do we encourage bug reports?

[Goswin Brederlow]

Lars Wirzenius wrote:
> 
> Milan Zamazal:
> 
> > One problem with reporting bugs I feel personally is what to do to
> > avoid repeating reports.
> 
> I think it is not the job of the person reporting a bug to worry about
> duplicate reports. Especially not if the person is an end-user and not
> a Debian developer.
> 
> 1. User discovers a bug.
> 2. User reports a bug.
> 
> Eager people will check the bug system before they repeat a bug,
> if only because they might find a solution quicker, if the bug
> has already been reported. However, in no way should we indicate
> that bug reporters are expected to do this.
> 
> --
> Please read  before mailing me.

I think it's allways a good idea to report bugs, even if you repeat
someone elses report. Most of the time you have different hardware and
setups and it makes it much easier to find bugs when you know if its a
problem specific to one hardware and setup or if it fails on a more
general base.

May the Source be with you.
Mrvn


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: libc6 policy in unstable

[Alex Yukhimets]

> > I'm not entirely certain I see why we need to remove libc5 packages from
> > the system for Debian 2.0.  While I agree that the primary packages should
> > really be glibc, I don't see how a few lib5 packages are going to hurt the
> > distribution
> 
> Well, they won't hurt much, but they would:
> 
>  - make memory usage less favourable (if you're running a mix of
>libc5/libc6 binaries, you'll have both in memory).
>  - make Debian look less attractive (We wouldn't appear in the
>list of distributions that are fully libc6).

Could you please point me to such a list?

Anyways, Debian just can't compete with commercial distributions which can
allow to suppose that they are self-contained. Debian is NOT. Unlike
RedHat (which has, for instance its "own" Motif and Metro-X), we can't
include ANY commercial product into the distribution.
They could recomplie them and have "fully libc6" distribution in a day.

There is a big world outside Debian, and the only way to compete is to
provide as much flexibility as possible. Yes, Debian must migrate to
libc6 ASAP, but it shouldn't just cut off the "conservative" part of the
users (they won't be back) and provide FULL choice for both environments.

Thanks.

Alex Y.

-- 
   _   
 _( )_
( (o___
 |  _ 7  '''
  \(")  (O O)
  / \ \ +---oOO--(_)+
 |\ __/   <--   | Alexander Yukhimets   [EMAIL PROTECTED] |
 || |   http://pages.nyu.edu/~aqy6633/  |
 (   /  +-oOO---+
  \ /  |__|__|
   )   /(_  || ||
   |  (___)ooO Ooo
\___)


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: libc6 policy in unstable

[joost witteveen]

> > > I'm not entirely certain I see why we need to remove libc5 packages from
> > > the system for Debian 2.0.  While I agree that the primary packages should
> > > really be glibc, I don't see how a few lib5 packages are going to hurt the
> > > distribution
> > 
> > Well, they won't hurt much, but they would:
> > 
> >  - make memory usage less favourable (if you're running a mix of
> >libc5/libc6 binaries, you'll have both in memory).
> >  - make Debian look less attractive (We wouldn't appear in the
> >list of distributions that are fully libc6).
> 
> Could you please point me to such a list?

Of cource, there isn't such a list now (as far as I know, at least I
guess that list would be empty now).

> Anyways, Debian just can't compete with commercial distributions which can
> allow to suppose that they are self-contained. Debian is NOT. Unlike
> RedHat (which has, for instance its "own" Motif and Metro-X), we can't
> include ANY commercial product into the distribution.

So, why does that mean we cannot compete?
What has self-contained to do with Motif?

Anyway, Lars just posted a script to auto-build the whole distribution,
and I really think with such scripts (presumably improved ones, but
the one from Lars apparently already works) we will get a self-contained
distribution rather soon.

> They could recomplie them and have "fully libc6" distribution in a day.

Wait and see what Lars will do.



-- 
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Hamm: Exim + Chos standard?

[Tim Sailer]

In your email to me, Rob Browning, you wrote:
> 
> Nathan E Norman <[EMAIL PROTECTED]> writes:
> 
> > Not that anyone necessarily has the time, but would it be worthwhile to
> > create some documents listing categories of packages, comparing and
> > contrasting the competing packages?
> 
> Right.  I'm about to help someone set up a relatively busy mailserver,
> and though I'm only familiar with sendmail, it'd be nice to know if
> one of the others would be a better choice.

Exim, at first gave me problems, but has proven to be just what I
needed. Virtual domains are a no-brainer, and,  if your machine
delivers a lot of mail to a single machine or domain at one time
(like a dialup going online 1/day), exim will tunnel all the mail
down the one connection instead of spawning off a separate process
for each one.

Tim

-- 
 (work) [EMAIL PROTECTED] / (home) [EMAIL PROTECTED] - http://www.buoy.com/~tps
   "Management decisions have no effect on the laws of physics."
  -- anon
** Disclaimer: My views/comments/beliefs, as strange as they are, are my own.**


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: libc6 policy in unstable

[Alex Yukhimets]

> Of cource, there isn't such a list now (as far as I know, at least I
> guess that list would be empty now).
> 
> > Anyways, Debian just can't compete with commercial distributions which can
> > allow to suppose that they are self-contained. Debian is NOT. Unlike
> > RedHat (which has, for instance its "own" Motif and Metro-X), we can't
> > include ANY commercial product into the distribution.
> 
> So, why does that mean we cannot compete?
> What has self-contained to do with Motif?

By self-contained I meant that *most* of the "users" of the particular 
distribution would not need to install anything from outside of it.
The nature of Debian implies that ALL commercial products, even the 
the most popular ones (like Motif) are outside of the distribution and has
to be purchased seperately. And once purchased, you can't just recompile
them with new library, you kinda stuck with them and expect that
distribution you've chosen (Debian) would still support you and provide
you with recent versions of other "free" developmental software. 

Thanks.

Alex Y.

> 
> Anyway, Lars just posted a script to auto-build the whole distribution,
> and I really think with such scripts (presumably improved ones, but
> the one from Lars apparently already works) we will get a self-contained
> distribution rather soon.
> 
> > They could recomplie them and have "fully libc6" distribution in a day.
> 
> Wait and see what Lars will do.
> 

-- 
   _   
 _( )_
( (o___
 |  _ 7  '''
  \(")  (O O)
  / \ \ +---oOO--(_)+
 |\ __/   <--   | Alexander Yukhimets   [EMAIL PROTECTED] |
 || |   http://pages.nyu.edu/~aqy6633/  |
 (   /  +-oOO---+
  \ /  |__|__|
   )   /(_  || ||
   |  (___)ooO Ooo
\___)


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .